Både ja och nej....brister i skripten är bara en del av problemet och du kan säkra dig mot problem av den sorten även om det inte är hundraprocentigt. Till exempel så utnyttjas ofta säkerhetsbrister på grund av CHMOD (rättigheter) där många skript kräver 777 rättigheter, vilket ger alla tillgång till katalogen eller filen. Detta i kombination med cross-site scripting är dom vanligaste orskerna till att ett konto blir hackat.

När man väl har kommit in på en server kan man göra mängder av bus, som till exempel att ladda upp virus och otäcka program som i stort sett ger tillgång till hela servern. Dessa göms djupt i en användares konto och används sedan för Spoofing och som plattform för att hacka andra konton.

--------

Markus, jag har lite feber och bihåleinformation och lillen är mer än lovligt kinkig med öroninfektion (Yay...), så skulle du kunna beskriva vad mod_php gör egentligen? Jag hittar ingen bra beskrivning på den verkar det som...

Jag förstår vad du syftar på med att man kan göra olika saker i php.ini, men om inte minnet sviker mig finns det sätt att säkra det...Osäker på om SetEnv PHPRC fungerar...Jag är inte världens säkerhetsguru :)

Genom att sätta open_basedir stoppar man dom flesta attacker som sträcker sig utanför användarens katalog. (dock måste man vara noga att köra dom nyaste PHP versionerna)

.. och framför allt ett aktivt säkerhetstänkande med admins som håller sig uppdaterade på säkerhetshål, trender, uppdateringar och nya lösningar för att hålla sin verksamhet så säker som det bara går. Jag har träffat många som mest rycker på axlarna när man börjar prata om säkerhet och säger "Varför skulle de vilja hacka oss?"

Vad jag har läst om mod_php så verkar det vara ett alternativ som är ostabilt och kräver väldigt mycket av andra moduler, som open_basedir för att vara någorlunda effektivt. Problematiken med användare (mod_php kör ju fortfarande alla användare som nobody) som då leder till problematiken med öppna skript för att ge rättigheter för olika skript som då kräver 777 permissions, vilket vi vet är riktigt illa. Det gör även felsökning för att hitta problematiska skript svårare och överlag kan jag inte säga att jag hittar några fördelar med mod_php över PHPSUEXEC.

Däremot hittar jag en del varningar om brister i mod_php och mängder av patchar och annat skoj, vilket verkar lite jobbigt och inte riktigt som den säkra lösningen jag letar efter.

Vad det gäller Markus varning om att man kan ändra PHPRC genom PHPSUEXEC har jag inte lyckas skrapa fram någon sådan uppgift än...om någon hittar det vänligen säg till eftersom det verkar oroväckande.

Jag tycker det finns tre viktiga delar:

1) Installera bara det du behöver. Ska du inte använda databaser, installera ingen databasserver etc. Det stora problemet med windows-servrar innan 2003 var att en standardinstallation drog in en massa som aldrig användes och startade upp det automatiskt. Behöver du en newsserver? Om inte, så installera ingen.

2) Brandvägg. Börja med att spärra allt. Var så restrektiv du kan och öppna bara det som verkligen behöver vara öppet. Ska trafik bara gå till ett visst nät, så tillåt det bara till det nätet.

3) Patcha regelbundet. Kanske kan det vara värt att låta det ske helt automatiskt, men följd upp med jämna mellanrum.

PHPSUEXEC utvecklas väl inte ens längre? Är det inte suPHP som gäller numera?

suPHP är ett alternativ till PHPSUEXEC och om PHPSUEXEC utvecklas eller inte är lite ovisst...en del säger att utvecklaren försvunnit och andra att han skriver om från scratch, så vilket som gäller är svårt att säga. Däremot så stöder Cpanel fortfarande PHPSUEXEC, så för Cpanel freaken är det bara att tuta på :)

suPHP verkar inte så aktiv heller...enligt hemsidan så verkar det inte ha hänt någonting sedan november förra året...

mod_php? open_basedir ingår i modulen libphp, men det är nog den du menar.
Jag tycker det fungerar utmärkt och är dessutom mkt enkelt, så länge man håller PHPn uppdaterad ger det också bra säkerhet.

Nu var det ett tag sedan jag läste på och testade att labba med suPHP. Men jag har precis för mig att om man satte i vhost configen SetEnv PHPRC variablem till /home/user/hiddendir/php.ini så läses filen bara därifrån och att den inte går att ändra från något annat ställe, rätta mig om jag har fel. Jag har för mig att php först läser från ovan config, sedan från katalogen som php skriptet ligger i och sedan default från /etc/php.ini.

Hur sätter man detta i php annars då? Är inte säker på att man kan ändra detta från php eftersom php körs via cgi.
Någon som vet om detta är ett hål eller inte?

Annat tips är att kontrollera vilka som kör wget, curl, lynx- dump mfl. varför ska vanliga users kunna köra dessa program på en webbserver????
chmod 700 och root.root så slipper man massor av problem..