PDA

Bekijk Volledige Versie : Server beveiliging / hardening.



X-Hosted
14/08/06, 13:28
Vanuit een aantal andere topics heb ik begrepen dat er wel animo is voor een topic met daarin 'het beveiligings verhaal' / hoe van een kale outta box server naar een veilige server, misschien handig als checklist voor andere beheerders of beheerders in wording.

Ik doe zelf altijd het volgende:

- Apache/Php/Mysql/ProFTPd/phpMyAdmin updaten (evt met behulp van http://www.directadmin.com/forum/showthread.php?s=&threadid=12099 en andere topics op DirectAdmin forum.)

- In DA onder administrator settings. automatische updates aanzetten, ip's laten blacklisten die meer dan 10x fout inloggen, elke minuut op vrije partition space checken en waarschuwen op 90% partitie usage

- Apache server status aan in httpd.conf, tevens ServerSignature Off

- SSH op een ander ip binden dan het 'normale' server ip, op andere port zetten, protocol naar 2 en permit root login uit.

- Spam Assassin aan

- Open DNS servers uit

- In /etc/hosts.deny, alles denyen voor SSH - in /etc/hosts.deny alleen mijn eigen IP en het IP van een windows server toegang geven tot SSH

- disable_functions in php.ini: exec,system,pcntl_exec,parse_ini_file,show_source, curl_exe,shell_exec,passthru,escapeshellarg,escape shellcmd,proc_close,proc_get_status,proc_nice,proc _open,proc_terminate,apache_note,apache_setenv,clo selog,debugger_off,debugger_on,define_syslog_varia bles,openlog,syslog

- /tmp met noexec mouten (via: http://forum.ev1servers.net/printthread.php?t=27771), echer.. via de manier in dit topic laat na reboot de tmp partitie /TMPmnt zich niet meer zien, niet 100% correct dus.

- wget down locken tot root (chmod 700 geven).

- YUM laten checken op updates.

Er zijn waarschijnlijk nog veel meer dingen, aanvullingen zijn dus van harte welkom... wellicht kan het een heel handig topic worden voor server owners.:)

systemdeveloper
14/08/06, 13:37
Ik doe meestal zoiets:

+ eventueel beginnen met de juiste 'perfect setup' van howtoforge.
+ je zooite chrooten
+ firewall bad-ass-kickin' maken
+ eventeel snortachtige dingen
+ je backups testen
+ free (of betaalde) remote securitycheck erop los laten (incl dos)
+ performancetest scriptjes draaien (om te checken of allen na 5000 hist of zo, oook nog goed draait)
+ hierna even kijken of de logrotate fatsoenlijk werkt en geen volle disk oplevert bij een ddos.

Dan vertrouw ik het nog niet eigenlijk, maar ja... je moet toch ooit online komen, niet ;)

CharlieRoot
14/08/06, 13:42
Ik zorg ook altijd dat als je telnet naar een poort je geen versie nummers tegenkomt.

Ik vind eth0.us altijd erg prettig om te lezen, erg nuttige topics enzo.

Jurian
14/08/06, 15:46
Nieuwe kernel compilen -> module support UIT, alleen er in stoppen wat die server nodig heeft, grsecurity patch er in en configureren naar wens.

Seriele kabel aansluiten op een andere server in de buurt + /etc/inittab en lilo.conf aanpassen zodat er vanaf de seriele console geboot en ingelogd kan worden bij problemen.

Naast wget ook lynx, links, ncftpget, ftp, ncftp en curl ontoegankelijk maken voor normale users.

/tmp naast noexec ook mounten met nodev

MySQL root password wijzigen

En heel belangrijk bij het ophangen in 't datacenter: rebooten en kijken of alles goed start, voor je 't datacenter weer verlaat! :)

mrleejohn
14/08/06, 16:05
Ik overweeg vanalles uit http://www.mrleejohn.nl/linux-security.htm

Digiover
14/08/06, 16:14
- SSH op een ander ip binden dan het 'normale' server ip, op andere port zetten, protocol naar 2 en permit root login uit.

[...]
- In /etc/hosts.deny, alles denyen voor SSH - in /etc/hosts.deny alleen mijn eigen IP en het IP van een windows server toegang geven tot SSH
Zoals bekend ben ik geen fan van ssh op een andere poort, maar dit is wel erg dubbel op, niet?
Naar mijn idee is het laatste (/etc/hosts.deny) afdoende, te samen met ssh 2 en permit root login uit.

Verder (nog niet in deze thread gezien):
- draai zo weinig mogelijk services op een server, alleen datgene wat je nodig hebt.

_arno_
14/08/06, 16:21
Zoals bekend ben ik geen fan van ssh op een andere poort, maar dit is wel erg dubbel op, niet?
Naar mijn idee is het laatste (/etc/hosts.deny) afdoende, te samen met ssh 2 en permit root login uit.

De meeste scanbots komen toch uit op de standard port van ssh, deze kunnen vast ook leaks vinden in sshd.
Als je ssh op een andere port zet mis je al heel veel van dit soort bots, en ben je iets minder snel gevoelig voor dit soort ongevallen.
Lijkt mij.

nopzolder
14/08/06, 16:57
Ik overweeg vanalles uit http://www.mrleejohn.nl/linux-security.htm


Deze staat nu in mijn favo's! erg handig

gjtje
14/08/06, 21:24
Als je die /tmp image in dev will plaatsen zul je udev er van moeten overtuigen dat die na een reboot ook terug moet komen, ofwel met een tar van /dev of door met een script deze opnieuw aan te maken.

home directories chmod 700 ;)

Digiover
15/08/06, 01:19
De meeste scanbots komen toch uit op de standard port van ssh, deze kunnen vast ook leaks vinden in sshd.
Als je ssh op een andere port zet mis je al heel veel van dit soort bots, en ben je iets minder snel gevoelig voor dit soort ongevallen.
Lijkt mij.
Zolang het IP adres van de betreffende bot niet in /etc/hosts.allow staat krijgt deze geen toegang, omdat in /etc/hosts.deny een ALL: ALL is opgenomen.

_arno_
15/08/06, 10:00
/etc/hosts.allow checkt hij toch pas op het moment dat je inlogd, dus je username pass invult?
Want in dat geval heb je nog wel vrijheid om dingen te kunnen vervelen.

Tenminste ik heb de illusie dat dit zo is ;)

coolvibe
15/08/06, 14:06
En als je Linux gebruikt dan is http://www.bastille-linux.org/ ook wel handig. Die pakt sowieso veel van de stappen die hierboven genoemd zijn mee.

mrleejohn
15/08/06, 14:11
Ik vind wel dat je een keer de moeite moet nemen om te doorgronden wat bastille eigenlijk allemaal doet. Heb je een enterprise-distro dan is dat spul allemaal ook wel gedaan.

coolvibe
15/08/06, 14:22
Ik vind wel dat je een keer de moeite moet nemen om te doorgronden wat bastille eigenlijk allemaal doet. Heb je een enterprise-distro dan is dat spul allemaal ook wel gedaan.

Dat sowieso. De eerste keer dat ik bastille draaide heb ik er zeker wel wat van opgestoken. Gelukkig vertelt bastille ook wat ie allemaal wil gaan doen, en waarom.

Digiover
15/08/06, 15:41
En als je Linux gebruikt dan is http://www.bastille-linux.org/ ook wel handig. Die pakt sowieso veel van de stappen die hierboven genoemd zijn mee.
Coolvibe... Toch niet... ? :)

Wido
15/08/06, 15:57
Ik denk dat ik hier nog wel wat leuks aan kan toevoegen.

Veel mensen draaien hun Apache's zoals ze worden geleverd door hun CP, dat is leuk, maar iedereen draait dan onder de zelfde gebruiker, dat is vaak "nobody", "apache" of "www-data".

Alle files die je nu aanmaakt via PHP worden dan van deze gebruiker, nu kan dus ook iedereen via PHP jouw file aanpassen.

Zoiets kan je proberen tegen te gaan met safemode of open_basedir, maar dat is echt allemaal schijnveiligheid, daarmee zit je echt niet veilig.

Een optie is te kiezen voor mod_ruid in combinatie met Apache 2.

Daarmee kan je iedere vhost onder zijn eigen gebruiker laten draaien, het voordeel hiervan is dat je elke directory op 700 kan zetten en elke file op 600. (Pas wel even de umask op je systeem aan zodat nieuwe files ook de juiste rechten krijgen).

Mocht er dan nu een deface plaats vinden via een lekke Joomla ofzo, dan is alleen die ene website getroffen, die gebruiker kan namelijk verder helemaal niets, hij kan geen enkele andere directory van een gebruiker in aangezien die allemaal op 700 staan.

Ook alle files die via PHP worden aangemaakt komen onder de eigen gebruiker.

Om nog veiliger te zitten leg je daar RSBAC nog eens overheen (www.rsbac.org), daarmee kan je vervolgens per gebruiker policy's maken, welke directory hij wel en niet in mag, elke directory hij "ls" mag doen en elke niet.

Zo kan je ook nog eens voorkomen dat die nasty bots iets doen als: find / -name 'index.php'; ze mogen namelijk helemaal niets behalve in hun eigen homedir spelen.

Zoiets opzetten (met RSBAC erbij) kost tijd, veel tijd, maar als je het eenmaal werkend hebt, dan heb je wel een superveilig systeem.

Wij draaien er nu al 2 jaar mee en hebben sindsdien nooit een deface gehad die verder kwam dan een homedir van die gebruiker. Wij gebruiken het ook op onze SSH-servers (alleen RSBAC) en daar hebben we ook nog nooit een security breach gehad.

Over RSBAC en mod_ruid is weinig te vinden, je zal dus veel zelf moeten uitzoeken. mod_ruid is niet zo moeilijk, maar RSBAC is flink doorbijten. Je kan overwegen om professional RSBAC support te nemen, kost je wat per maand, maar dan heb je je problemen wel stukken sneller opgelost.

Uiteraard kan je ook SELinux of GRSEC nemen, dat werkt het zelfde (naja, lijkt er op). Wij werken met RSBAC en dat bevalt ons prima.

Een echte howto is het niet, maar meer iets om over na te denken.

mrleejohn
15/08/06, 16:30
De nieuwere mac-systemen zijn toch selinux en apparmor. Met als basis LSM; zie http://www.mrleejohn.nl/LSM.htm

Wido
15/08/06, 16:50
De nieuwere mac-systemen zijn toch selinux en apparmor. Met als basis LSM; zie http://www.mrleejohn.nl/LSM.htmTot nu toe heeft RSBAC bij mij altijd voldaan, ik zie (nog) geen reden tot overstappen.

WebXtrA-RĂ¡mon
15/08/06, 17:09
De nieuwere mac-systemen zijn toch selinux en apparmor. Met als basis LSM; zie http://www.mrleejohn.nl/LSM.htm

Bij RSBAC geven ze een aantal redenen waarom ze niet gebruik maken van LSM:
http://www.rsbac.org/documentation/why_rsbac_does_not_use_lsm

coolvibe
15/08/06, 17:26
Coolvibe... Toch niet... ? :)

Ja die ja :)

Goldeneye
15/08/06, 17:27
Dit veranderen in de php.ini geef ook wat zekerheid:

allow_url_fopen = Off
register_globals = Off
enable_dl = Off
expose_php = Off
safe_mode = On

Wido
15/08/06, 17:30
De eerste 4 inderdaad, maar safe_mode is echt pure schijnveiligheid waar je alleen jezelf maar mee hebt.

Waarom denk je dat het er anders in PHP6 uit gaat?

mrleejohn
15/08/06, 17:31
Rsbac, grsecurity e.d. voldoen ook nog wel. Maar ik verwacht toch dat de toekomst voor selinux en apparmor zijn. Het e.e.a. van de oude hardening-mac-instellingen zitten standaard al in de enterprise-kernels.

t.bloo
16/08/06, 00:07
mod_ruid gebruik ik al jaren, maar dat is toch geen jail of chroot zoals je in een andere thread suggereerde? jailkit gebruik ik op onze ssh server. ik ben over zowel mod_ruid als jailkit tevreden.

Wido
16/08/06, 00:09
mod_ruid gebruik ik al jaren, maar dat is toch geen jail of chroot zoals je in een andere thread suggereerde? jailkit gebruik ik op onze ssh server. ik ben over zowel mod_ruid als jailkit tevreden.Nee, een echte jail of chroot kan je het noemen, maar met iets als RSBAC kom je aardig in de buurt.

Elke klant in een eigen chroot draaien gaat niet zo handig, maar een combinatie van mod_ruid en een extra security layer brengt je aardig op weg.

gjtje
16/08/06, 00:27
Er is nu ook een mpm in apache 2 welke hetzelfde doet als mod_ruid, itk.

guidob
16/08/06, 09:45
- disable_functions in php.ini: exec,system,pcntl_exec,parse_ini_file,show_source, curl_exe,shell_exec,passthru,escapeshellarg,escape shellcmd,proc_close,proc_get_status,proc_nice,proc _open,proc_terminate,apache_note,apache_setenv,clo selog,debugger_off,debugger_on,define_syslog_varia bles,openlog,syslog

Werken alle scripts nog wel als je dat allemaal uitschakeld?

Digiover
18/08/06, 16:15
/etc/hosts.allow checkt hij toch pas op het moment dat je inlogd, dus je username pass invult?
Want in dat geval heb je nog wel vrijheid om dingen te kunnen vervelen.

Tenminste ik heb de illusie dat dit zo is ;)
Fout, u gaat niet door voor de koelkast ;)

/etc/hosts.(allow|deny) zijn onderdeel van Wietse Venema's tcpwrapper / access control facility tcpd (http://www.die.net/doc/linux/man/man8/tcpd.8.html) en voeren op het moment van verbinding een rule uit (deny of allow). Hier zou je overigens ook D. J. Bernstein's tcpserver (ucspi-tcp package (http://cr.yp.to/ucspi-tcp.html)) voor kunnen gebruiken.
De betreffende daemon moet wel tcpwrapper ondersteuning hebben.

Iets wat ik jaren geleden al eens heb geschreven (en gejat van een LPI cursus) over Linux beveiliging:
http://www.dsinet.org/hackfaq/html/linux_beveiliging.html

Glenn
18/08/06, 16:36
Werken alle scripts nog wel als je dat allemaal uitschakeld?
Nee, niet alle scripts werken dan nog. Dat is namelijk ook de bedoeling ;)

Goed geschreven scripts zullen blijven werken. Malafide scripts niet, maar dat is juist de bedoeling.

Wido
18/08/06, 16:38
Nee, niet alle scripts werken dan nog. Dat is namelijk ook de bedoeling ;)

Goed geschreven scripts zullen blijven werken. Malafide scripts niet, maar dat is juist de bedoeling.
ik moet zeggen, ik gebruik exec(), system(), parse_ini_file() best wel vaak, dus mijn script is malafide?

Daarnaast is de DL functie nog veel linker, zie: http://nl2.php.net/dl

snaaps
20/08/06, 15:00
- /tmp met noexec mouten (via: http://forum.ev1servers.net/printthread.php?t=27771), echer.. via de manier in dit topic laat na reboot de tmp partitie /TMPmnt zich niet meer zien, niet 100% correct dus.


Beginnen met het aanmaken van aparte partities lijkt mij geen overbodige luxe.
/tmp
/home


Betreft disable_functions in php.ini, zou het een cool idee zijn dat je dit soort instellingen met flags in de costom httpd config zou kunnen regelen. (net zoals de safemode) echter volgens mij is dit helaas niet mogelijk.

Ik kan me voor stellen dat je klanten niet echt blij zijn met jouw disable functies.

WI-Hosting
20/08/06, 15:12
*heeft weer een extra bookmark erbij ;-)*

Ontopic: Als je mod_ruid draait, hebben de functies exec() etc. toch wel weer een stuk minder bedreiging. En stel een klant wilt exec() met een legitiem doel, hoe kan je zorgen dat bv alleen hij er gebruik van kan maken, of dat het gewoon een stuk veiliger is om niet in de disable_functions te stoppen.

Nielsvk
21/08/06, 20:18
Vanuit een aantal andere topics heb ik begrepen dat er wel animo is voor een topic met daarin 'het beveiligings verhaal' / hoe van een kale outta box server naar een veilige server, misschien handig als checklist voor andere beheerders of beheerders in wording.

Ik doe zelf altijd het volgende:

- Apache/Php/Mysql/ProFTPd/phpMyAdmin updaten (evt met behulp van http://www.directadmin.com/forum/showthread.php?s=&threadid=12099 en andere topics op DirectAdmin forum.)

- In DA onder administrator settings. automatische updates aanzetten, ip's laten blacklisten die meer dan 10x fout inloggen, elke minuut op vrije partition space checken en waarschuwen op 90% partitie usage

- Apache server status aan in httpd.conf, tevens ServerSignature Off

- SSH op een ander ip binden dan het 'normale' server ip, op andere port zetten, protocol naar 2 en permit root login uit.

- Spam Assassin aan

- Open DNS servers uit

- In /etc/hosts.deny, alles denyen voor SSH - in /etc/hosts.deny alleen mijn eigen IP en het IP van een windows server toegang geven tot SSH

- disable_functions in php.ini: exec,system,pcntl_exec,parse_ini_file,show_source, curl_exe,shell_exec,passthru,escapeshellarg,escape shellcmd,proc_close,proc_get_status,proc_nice,proc _open,proc_terminate,apache_note,apache_setenv,clo selog,debugger_off,debugger_on,define_syslog_varia bles,openlog,syslog

- /tmp met noexec mouten (via: http://forum.ev1servers.net/printthread.php?t=27771), echer.. via de manier in dit topic laat na reboot de tmp partitie /TMPmnt zich niet meer zien, niet 100% correct dus.

- wget down locken tot root (chmod 700 geven).

- YUM laten checken op updates.

Er zijn waarschijnlijk nog veel meer dingen, aanvullingen zijn dus van harte welkom... wellicht kan het een heel handig topic worden voor server owners.:)

Ik heb zelf geen ervaring met host.deny maar ik doe het gewoon via iptables met drop :) Ik kreeg laast van verschillende ips allemaal ssh bruteforces op de iptables gegooit en geen last meer van :)