Efter alla dessa goda tider med attack på attack, undrar jag nu hur
man smidigast och smartast går tilll väga för att säkra sin server.

Någon specifik lista man bör följa som standard på vad som skall göras?
Någon man anställer, välkänt bolag?
Vilka val finns vid backuper och dess lösningar runtom?

Vore av intresse att få veta lite mer då lite större sajter skall lanseras..

Skulle säga att största risken är på web, alltså dåligt kodade script av olika slag.

https://www.totalserversolutions.com/ Dessa gör det billigt till dig, har inte testat själv än men de rekommenderas av ThePlanet.com.

Japp! Dom gör det billigt och plantera in nya bakdörrar som du inte visste fanns..:-)

För alla som kör PHP kan jag bara säga PHPSUEXEC...finns inget skönare än att slippa alla fel konfigurerade kataloger och filer (men det står ju att katalogen/filen ska CHMODdas till 777....jaha, ska man ändra det efter installation....).

Andra saker som är användbart är:

csf - a full featured SPI (Stateful Packet Inspection) iptables firewall configuration application.

lfd - integrated with csf to block hacking attempts from your internet facing services and detects system intrusions/rootkits.

Rootkit Hunter - an essential tool in detecting possible root compromise and rootkit installation.

Chkrootkit - another essential tool in detecting possible root compromise and rootkit installation, it compliments rkhunter with a different detection approach.

mod_security - a security layer in apache that helps prevent exploitation of vulnerable web scripts. We will install and configure the optional cPanel mod_security module for Apache v1 and v2.

Host Spoof Protection - Helps prevent IP spoofing and DNS cache poisoning.

Name server configuration check - If the name server (bind) is running, check that it is functioning correctly and enable local DNS lookups.

Secure /tmp /var/tmp /dev/shm - remounted noexec and nosuid to add an additional layer of protection against web script hackers.

Delete unnecessary OS users - On a standard OS installation many user accounts are created that are not necessary and can therefore pose a security risk.

Disable open DNS recursion - Protection against abuse and poisoning of your local DNS cache if DNS server (bind) is running on the server.

Enhanced path protection - Help protect against clients and hackers browsing and accessing files outside of their account directories.

Remove SUID/GUID from binaries - On a standard OS installation many application binaries have SUID and GUID bits set that are not necessary and can therefore pose a security risk.

PHP hardening - Dynamic Library loading is disabled and commonly abused php functions disabled to help prevent hackers exploiting vulnerable PHP web scripts.

Libsafe for 2.4 kernels - Older OS's (e.g. FC1, RH9 and RH7.3) can benefit from libsafe that helps protect against hacker stack smashing techniques that can gain them root access.

Switch from proftpd to pure-ftpd - Pure-ftpd is considered more secure and lighter on server resources compared to proftpd on cPanel servers.

OpenSSH configuration check - is checked to ensure only SSHv2 protocol is enabled.

------------

Sen rekommenderar jag att stänga av all SSH för kunderna och regelbundet rotera portnummer för att undvika problem genom SSH.

Mailscanner kan vara användbart om man har problem med eposten också.

För mig som inte är så förtjust i SSH så kan jag rekommendera ConfigServer Explorer: allows you to browse your disk structure and directories and perform shell tasks from within WHM which can be very helpful if SSH fails for any reason.

Nice!
Tackar så mycket :)

Nej kör inte med phpsuexec eller andra moduler som låter php körs som cgi.
Igenom köra php som cgi kan användaren ändra precis all konfiguration för php(du kan ändra PHPRC variabel).
Du öppnar bara upp hål för användaren att ta sig in i ditt system om du kör php med cgi.
Vill du ha säkerhet kör med mod_php istället.

Hmmm...den får du nog förklara Markus...
PHPSUEXEC tar bort problemet med CHMOD problem och ger varje script permissions baserat på användaren istället för att köra som "nobody" vilket ger bättra skydd mot PHP angrepp mot osäkra skript och gör det fasligt mycket lättare att identifiera problematiska skript vid felsökning.

http://codylindley.com/Misc/74/server-secu...ec--textpattern

Har du lite information om vilken typ av problem som skulle kunna uppstå genom att köra PHPSUEXEC, så är jag intresserad. Gärna lite information om vad PHP_mod skulle åstakomma för ökad säkerhet också...Jag hittar bara lite artiklar om hur PHP_Mod är snabbare eller långsammare än till exempe mod_perl....

Visst phpsuexec ser till att alla script körs med uid/gid vilket blir mycke bekvämmare och see vem som laddat upp saker till /tmp etc.
Men när php är konfigurerat som CGI kan man ändra PHPRC(phprc pekar vart php.ini ska läsas ifrån detta kan du ändra att den läser en egen skapad php.ini under din home dir).
I detta fall kan du stänga av safe_mode öppna upp exec(),system(), stänga av openbase_dir osv.
Dock så har jag för mig att phpsuexec som standard låter dig använda egen skapade php.ini, vilket verkar helt idiotiskt användaren ska inte kunna ändra php konfigurationen.

Du kan te.x skafa dig skal access via php igenom detta.

Använder du mod_php använd openbase_dir för inte låta dom läsa andras filer. Slå på safe_mode stäng av alla funktioner som kan exekvera program mot servern.
Det finns enhel del patcher för öka säkerhet med mod_php.
http://www.hardened-php.net/

Om du verkligen måste köra php via cgi kolla upp mod_fcgid.

Den vanligaste säkerhetsbristen är väl ändå känd programvara, allt från apache till phpBB som inte använder sig av de senaste patcherna. En självklarhet såklart, men min erfarenhet är att många "glömmer" av.

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..

Där håller jag med väldigt mycket då jag personligen aldrig haft ett, synligt, intrång på någon av mina webbplatser och det beror också på att jag aldrig kör någon opensource applikation på mina webbservrar.

Varför ska vanliga users ens ha shellaccess?