Linux (web)server beveiliging, best practices

[Ijstheefles]

Goededag allemaal,

Het leek me een goed idee om een topic te maken over de best-practises van linux beveiliging.

Ik heb het hier voornamelijk over beveiliging van de server die een website host, al zijn andere zaken zoals chrooten van ftp users bijvoorbeeld ook welkom.

Natuurlijk ben ik me er van bewust dat google hierbij kan helpen, maar een collectiepunt hier op tweakers leek me geen slecht idee!

Om een start te bieden, hier wat generieke dingen die ik zo kan bedenken:

• Minimaal eens per week laatste updates installeren
• Indien je een webserver draait, zorg dat deze onder de individuele users draaien van de individuele websites
• Gebruik verschillende database wachtwoorden voor verschillende taken. 1 voor de front-end voor alle selects. 1 voor de iets meer mogende gebruiker (ook updates b.v.), etc.
• Chroot je ftp gebruikers in hun home directory. (ftp is hiervoor het makkelijkst, al is deze ook vrij onveilig)

Hoor graag meer tips voor in de lijst!

[edit]
Ik zal alle tips in de lijst zetten, wordt alleen dit weekend vrees ik. Beetje druk op 't moment. Toch bedankt voor de reacties tot nu toe !

[ Voor 7% gewijzigd door Ijstheefles op 19-01-2012 22:05 . Reden: Kleine update ]

[--WaaZaa--]

• Standaard alle poorten dicht zetten, alleen diegene open zetten die je nodig hebt.
• Vergeet ipv6 niet. Zet met ip6tables altijd ook alles dicht, ook al gebruik je het (nog) niet. Mocht er ineens een ipv6 router bij komen die RA's uitstuurt, heb je grote kans dat je server ineens v6 adres heeft.
• SSH login root dicht zetten
• Doe een minimale install, installeer alleen packages die je nodig hebt.
• Laat bruteforcers geblokkeerd worden door een (tijdelijke) ip ban, met bijvoorbeeld fail2ban.

[Koffie]

Zonder enige onderbouwing heb je eigenlijk niets aan deze punten.
Waarom zou ik minimaal eens per week updates moeten installeren We garandeert mij dat ik daar niet meer stuk mee maak dan ik beveilig?

Move PNS > NOS

[Miepermans]

Misschien is het tof, om bij het aandragen van security punten ook even een link te plaatsen naar een implementatie Guide, Ikzelf ben namelijk redelijk ver met firewallen, maar het chroot laten draaien van multiple apache lukt me niet.

Dit komt echter omdat ik geen goede gids heb gevonden tot op heden over hoe je dit moet doen. Als we mekaar zo kunnen helpen ?

Ik ga dit topic wel bookmarken, want ik denk dat iedereen van elkaar kan en zou moeten leren!

[Thralas]

--WaaZaa-- schreef op woensdag 18 januari 2012 @ 10:21:
SSH login root dicht zetten

Mwah, dat vind ik altijd zo'n schijnmaatregel; als je rootwachtwoord in een dictionary staat ben je sowieso onhandig bezig. Daarnaast, simpelweg pubkey auth vereisen:

PermitRootLogin without-password

Of nog liever password authentication in z'n geheel disablen:

PasswordAuthentication no

In 't algemeen kun je verder nog overwegen FTP helemaal niet aan te bieden en sftp te gebruiken, dat is secure by default.

[ Voor 12% gewijzigd door Thralas op 18-01-2012 15:19 ]

[MAX3400]

Tja, wat is veilig en wie is de doelgroep die de server beheert en wie is de doelgroep die de server benadert (bijvoorbeeld een website).

- moet je dan elke dag je password veranderen?
- verandert wekelijks een SSL-certificaat?
- welke http-daemon hebben we het over?
- wie garandeert (na wat recente issues) dat de kernel geen backdoors/issues heeft?

Kan nog wel even doorgaan met basis-zaken die in de gemiddelde RTFM-configuratie van apache, nginx of lighttpd al worden besproken; laat staan als je beter/dieper gaat inzoomen op het gebruik van de webserver.

/edit: ook zal er een aanzienlijk verschil zijn tussen dedicated, shared, VPS, cloud of andersoortige aanbieders waar je uiteindelijk een webservice op basis van Linux gaat/laat hosten.

[ Voor 14% gewijzigd door MAX3400 op 18-01-2012 15:23 ]

[jelly]

• Server hardenen, door sysctl.conf
• SFTP > FTPS
• Firewall opzetten, eventueel alleen SSH'en van bepaalde IP's, bij 5 SSH attempts per minuut verkeer droppen. SSHD_config AllowUsers gebruiker
• indien PHP, PHP-suhosin http://www.hardened-php.net/

[ajvdvegt]

Ik moest denken aan deze HOWTO die hier ooit is gepost: [Mini Howto] Chroot SFTP met Public/Private Keys.

[Anoniem: 26306]

Er is geen standaardmanier en er is geen complete set algemene best practices.
Beveiliging is altijd afhankelijk van de hoeveelheid gebruiksgemak.

Oplossingen als fail2ban zijn een verschrikking. Public key authentication is in wezen niet veel anders dan authenticatie met een achterlijk moeilijk wachtwoord.

Je stelt bepaalde voorwaarden en vervolgens ga je op zoek naar oplossingen die zorgen dat het nog net bruikbaar en misschien zelfs eventueel net aan gebruikersvriendelijk is.

[Roconda]

Dingen die ik meestal doe bij linux servers:

• Kernel patchen met grsec -> grsecurity.org
• Iptables: Poorten dichtgooien(enkel white listening), INVALID packets droppen, blackhole filteren etc
• Onnodige users/groups weggooien
• Als het kan chroot draaien
• Zo min mogelijk services draaien
• Zo min mogelijk software installeren(less = better)
• Geen execute en write rechten geven op onnodige binairies ( chmod o= /usr/bin/wget, etc )
• Zo veel mogelijk version tokens uitzetten ( apache, nginx, lighthttp, php.. )

Bij services die je extern wilt draaien is het ook handig om te kijken naar de security history. Het is bijvoorbeeld verstandiger om voor vsftpd of pureftpd te kiezen dan proftpd. Installeer ook geen tools als webmin, kan je geen server beheren, doe het dan vooral ook niet!

Owja, vergeet ook niet zo nu en dan in te loggen en te kijken vreemde: processen, gebruikers en bestanden. Lees ook je syslog na en vergeet niet om de local mail van root te lezen.

[Anoniem: 26306]

Roconda schreef op donderdag 19 januari 2012 @ 17:58:

Owja, vergeet ook niet zo nu en dan in te loggen en te kijken vreemde: processen, gebruikers en bestanden. Lees ook je syslog na en vergeet niet om de local mail van root te lezen.

IDS

[Joseph]

Ik plaats mijn vraagtekens bij IDS. Het is zelf een zo groot en complex beest, dat ik bijna de indruk heb dat er in IDS zélf wel eens vele exploits kunnen zitten.

Er zijn mensen die het gebruik ervan afraden.

[Roconda]

Mijn ervaring met het gebruik van een IDS is dat het veelal zorgt voor False Positives. Het is aardig wat werk om een IDS goed te configureren voor de juiste configuratie(kosten/baten).

Ben persoonlijk meer een voorstander van een centrale syslog server.

[Sando]

Bookmarked. Zonder te lezen even mijn eigen kladblok plakken:

• fail2ban
  • http://www.fail2ban.org/
  • 10 minute ban voor mislukte logins.
• faillog -u root
  • Check voor pogingen tot logins
• Denyhosts
  • http://denyhosts.sourceforge.net/
  • Blockt ip's na x mislukte logins.
  • Whitelist: [url]/etc/hosts.allow[/url]
• root login uitzetten in sshd
  • [url]/etc/ssh/sshd_config[/url]
    • permitrootlogin=no
  • Handig alternatief:
    • permitrootlogin without-password
• Port Knocking
  • Paranoide oplossing, misschien handig als je wikileaks host
  • http://en.wikipedia.org/wiki/Port_knocking
• psad
  • Intrusion Detection and Log Analysis with iptables
• fwsnort
  • Intrusion Detection
• ssh guard
  • http://www.sshguard.net/
• Nagios
  • http://www.nagios.org/
  • Advanced log monitoring