[Debian] Apache 2 server met PHP en MySQL beveiligen

[pinockio]

Voor mezelf (en mogelijk voor anderen) wil ik duidelijk krijgen hoe ik mijn Debian servertje zo optimaal mogelijk kan beveiligen.

Ik draai kernelversie 2.4.26-1-386 op Debian Sarge. Beveiligings- en andere updates doe ik eens in de ca. 2 weken (wellicht is dat te weinig). Momenteel is alles up to date.

De server staat achter een Speedtouch modem, met enkele poorten geforward. Poort 80 (intern) is geforward naar poort 800, omdat ik denk dat dat wel iets kan schelen voor wormen etc.

Verder draait er Apache 2.0.54, MySQL 4.0.24, PHP 4.3.10-16 en maak ik gebruik van Wordpress, Zenphoto, Zenpress (=Zenphoto plug-in voor Zenpress), awstats en webalizer (de laatste om wordt vervangen door awstats).

De site wordt bezocht door vrienden en familie, maar - ondanks dat het op een andere poort draait - weten webcrawlers 'm wel te vinden.

Hier: MySQL, ben ik gehacked? zag ik al een alarmerend verhaal over een gehackte Wordpress (2.0.2) installatie, dus ik wil eventuele problemen wel vóór zijn.

Ik heb in robots.txt alle crawlers de toegang tot / ontzegd, maar www.bloglines.com neemt toch zo nu een dan een kijkje. Misschien heeft iemand die ik ken mijn site toegevoegd om bijv. via rss nieuwe berichten te krijgen.

De volgende lagen van beveiliging heb ik bedacht:

Fysieke toegang
server staat in afgesloten bedrijfspand

OS:
Inloggen op console: mogelijk, met vrij moeilijke wachtwoorden

Webserver
- DOS: natuurlijk altijd mogelijk
- Inloggen en spam plaatsen in comments / op blog: alleen mogelijk na moderatie
- Misbruik van Wordpress om toegang tot het OS te krijgen: alleen mogelijk in het geval van security bugs van Apache, Wordpress en / of MySQL etc.

De volgende mogelijkheden voor (extra) veiligheidsmaatregelen heb ik bedacht:

Algemeen: natuurlijk blijven updaten

Wordpress: voor het plaatsen van comments een check inbouwen met een plaatje / nummer

OS: Encrypted file system gebruiken: vereist veel aanpassing, en mogelijk snellere CPU

Chroots gebruiken (ik denk niet dat default installs van Apache en MySQL dat doen op Debian)

Logs goed nakijken op verdachte entries

Verder zou ik hier natuurlijk kunnen beginnen:

http://www.debian.org/doc...ebian-howto/index.en.html
http://www.securityfocus.com/infocus/1786 of
http://www.petefreitag.com/item/505.cfm (dit is een handig overzicht over het beveiligen van Apache, waar ik al een aantal tips van heb opgevolgd)

Mis ik iets in dit overzicht (ongetwijfeld)?

[ Voor 1% gewijzigd door pinockio op 12-06-2006 16:16 . Reden: duidelijker ]

[DJ Buzzz]

Mocht je echt jezelf uit willen leven, dan zou je eens naar SELinux kunnen kijken http://www.nsa.gov/selinux/.

Verder heeft een encrypted filesystem niet echt veel nut als je voornamelijk je tegen aanvallen van buitenaf wilt weren. Tijdens het draaien van je machine moet namelijk je filesystem gewoon gemount staan en merk je dus niks van de encryptie. Deze beveiliging heeft alleen nut als beveiliging tegen het fysiek stelen van je systeem, zodat ze daarna niks met de data kunnen doen.

Verder blijft het belangrijkste om up to date te blijven qua software zoals Wordpress, dit zijn toch eigenlijk altijd de meest kwetsbare punten.

[DexterDee]

Mijn nederige mening is dat ik denk dat je met al je beveiligingsmaatregelen een beetje paranoia aan het worden bent. Niet om je te beledigen hoor, maar het is en blijft een "thuis"server. Ik neem niet aan dat er kritieke applicaties bijdraaien van grote ondernemingen of zo. Natuurlijk wil je niet dat je site met vakantiekiekjes gedefaced wordt of gehacked, maar sommige maatregelen gaan wel heel erg ver. Zo is het helemaal niet nodig om op poortje 800 te draaien. Een goede poortscanner ziet wel dat daar HTTP over gaat.

Ik heb zelf een Linux server (Centos 4.1) en update keurig alle security patches. Ik draai onder SELinux en ik zorg voor recente versies van alle software. Ik heb al jaren diverse servers permanent aan het internet hangen, en ben nog nooit gehacked. Ik krijg elke dag mooi een mailtje van LogWatch met alle verdachte activiteiten. Net zoals jou heb ik een aantal poorten geforward via NAT naar mijn machine. Natuurlijk zie ik elke dag SSH attacks en andere vreemde URL's. Maar er is er nog nooit iemand echt door de security gekomen. En aangezien mijn server geen 'high profile' bak is die heel snel is of anderzijds opvalt, zullen mensen minder snel moeite doen om dat ding binnen te komen. Er valt ook weinig op te halen. En mocht 'ie een keertje gehacked worden, dan heb ik eventjes pech gehad en heb ik wat werk om het te herstellen. Het is niet dat ik daardoor financieel in de problemen kom of anderzijds grote problemen krijg. Het feit dat een blog uitvalt of je vakantiekiekjes offline zijn is niet een situatie van leven of dood.

Zo lang de apache en mysql users geen rechten hebben op vitale delen van je operating system en je een sterk wachtwoord op alle SSH accounts hebt, heb je weinig te vrezen. Als er een exploit gevonden wordt in een van je OSS pakketjes, meteen updaten en klaar is kees. Root access is vrij moeilijk te verkrijgen en zoveel moeite (als het al gaat lukken) gaan ze echt niet doen als er niet duidelijk wat te halen valt. En als je verder van remote management applicaties als VNC afblijft dan heb je dat risico ook beperkt.

Mijn EUR 0,02

[Verwijderd]

Ik pak het op ongeveer dezelfde manier aan. Wil je meer weten over Selinux kun je kijken op http://www.mrleejohn.nl/LSM.htm . Verder kun je je uitleven met http://www.mrleejohn.nl/linux-security.htm .

Hav fun

[pinockio]

DexterDee schreef op maandag 12 juni 2006 @ 15:11:
Mijn nederige mening is dat ik denk dat je met al je beveiligingsmaatregelen een beetje paranoia aan het worden bent. Niet om je te beledigen hoor, maar het is en blijft een "thuis"server. Ik neem niet aan dat er kritieke applicaties bijdraaien van grote ondernemingen of zo. Natuurlijk wil je niet dat je site met vakantiekiekjes gedefaced wordt of gehacked, maar sommige maatregelen gaan wel heel erg ver. Zo is het helemaal niet nodig om op poortje 800 te draaien. Een goede poortscanner ziet wel dat daar HTTP over gaat.

Ik heb zelf een Linux server (Centos 4.1) en update keurig alle security patches. Ik draai onder SELinux en ik zorg voor recente versies van alle software. Ik heb al jaren diverse servers permanent aan het internet hangen, en ben nog nooit gehacked. Ik krijg elke dag mooi een mailtje van LogWatch met alle verdachte activiteiten. Net zoals jou heb ik een aantal poorten geforward via NAT naar mijn machine. Natuurlijk zie ik elke dag SSH attacks en andere vreemde URL's. Maar er is er nog nooit iemand echt door de security gekomen. En aangezien mijn server geen 'high profile' bak is die heel snel is of anderzijds opvalt, zullen mensen minder snel moeite doen om dat ding binnen te komen. Er valt ook weinig op te halen. En mocht 'ie een keertje gehacked worden, dan heb ik eventjes pech gehad en heb ik wat werk om het te herstellen. Het is niet dat ik daardoor financieel in de problemen kom of anderzijds grote problemen krijg. Het feit dat een blog uitvalt of je vakantiekiekjes offline zijn is niet een situatie van leven of dood.

Zo lang de apache en mysql users geen rechten hebben op vitale delen van je operating system en je een sterk wachtwoord op alle SSH accounts hebt, heb je weinig te vrezen. Als er een exploit gevonden wordt in een van je OSS pakketjes, meteen updaten en klaar is kees. Root access is vrij moeilijk te verkrijgen en zoveel moeite (als het al gaat lukken) gaan ze echt niet doen als er niet duidelijk wat te halen valt. En als je verder van remote management applicaties als VNC afblijft dan heb je dat risico ook beperkt.

Mijn EUR 0,02

Hier staan een aantal goede tips in. Overigens heb ik niet alles wat er op die box aangesloten is genoemd; hij werkt o.a. ook als VPN-server via OpenVPN en er staat nogal wat persoonlijke en bedrijfsdata op. Twee servers draaien (VPN / fileserver plus webserver) is voorlopig een beetje teveel van het goede, vandaar dat ik gewoon niet wil dat die server gehackt wordt... En het is al vrij lang geleden dat ik een webserver heb beheerd, vandaar dat ik even de basics van de beveiliging wil checken.

[nero355]

DexterDee schreef op maandag 12 juni 2006 @ 15:11:
Niet om je te beledigen hoor, maar het is en blijft een "thuis"server.

Ik denk dat er een redelijk aantal Tweakers is dat eerst hun server thuis neerzet voor een bepaalde periode om te kijken of die het wel overleefd in zijn eentje kwa security om hem vervolgens ergens in een datacenter neer te zetten i.c.m. met een co-locating pakket

Dan wil je niet dat je server al na 1 week gehackt/cracked is en een Warez/SPAM/DDoS slachtoffer wordt !!

[DexterDee]

nero355 schreef op maandag 12 juni 2006 @ 15:34:
[...]

Ik denk dat er een redelijk aantal Tweakers is dat eerst hun server thuis neerzet voor een bepaalde periode om te kijken of die het wel overleefd in zijn eentje kwa security om hem vervolgens ergens in een datacenter neer te zetten i.c.m. met een co-locating pakket

Dan wil je niet dat je server al na 1 week gehackt/cracked is en een Warez/SPAM/DDoS slachtoffer wordt !!

Begrijp me niet verkeerd, achteloos met security omgaan is niet datgene wat ik hier probeer te promoten. Ik heb wel een aantal jaren ervaring als het komt op (dedicated) serverhosting en installeren en beheren ervan. Gezien de beveiligingsopties die de TS opnoemt denk ik dat hij al meer beveiligd is dan menig andere low profile webserver en naar mijn mening ruim voldoende. Ik vind het daarom vrij onnodig om hierin NOG verder te gaan en bijvoorbeeld de webserver op poortje 800 te gaan draaien. SELinux is op zich ook een goede extra beveiliging, maar vrij moeilijk te realiseren als je het nog niet draait. Het grijpt namelijk behoorlijk in op je OS. Beter zou zijn om dan een (enterprise) server distro te draaien waar veel van deze veiligheidsfeatures al in zitten (zoals Red Hat Enterprise Linux 4 of CentOS 4.1)

[nero355]

DexterDee schreef op maandag 12 juni 2006 @ 16:03:
Begrijp me niet verkeerd, achteloos met security omgaan is niet datgene wat ik hier probeer te promoten.

Zo vatte ik het ook niet op.

Ik heb wel een aantal jaren ervaring als het komt op (dedicated) serverhosting en installeren en beheren ervan. Gezien de beveiligingsopties die de TS opnoemt denk ik dat hij al meer beveiligd is dan menig andere low profile webserver en naar mijn mening ruim voldoende. Ik vind het daarom vrij onnodig om hierin NOG verder te gaan en bijvoorbeeld de webserver op poortje 800 te gaan draaien.

Tja een andere poort voor een webserver is een beetje overbodig ja, maar wat waren zo'n beetje de security maatregelen bij dat hosting bedrijf waar je hebt gewerkt ??

SELinux is op zich ook een goede extra beveiliging, maar vrij moeilijk te realiseren als je het nog niet draait. Het grijpt namelijk behoorlijk in op je OS. Beter zou zijn om dan een (enterprise) server distro te draaien waar veel van deze veiligheidsfeatures al in zitten (zoals Red Hat Enterprise Linux 4 of CentOS 4.1)

Ik ben tot nu toe alleen met FreeBSD echt bezig geweest en eerlijk gezegd kwam ik niet verder dan gewoon root toegang via SSH disablen en ervoor zorgen dat Apache onder zijn eigen user draait net als MySQL die tevens niet van buiten bereikbaar mag zijn en een wachtwoord moet hebben.

Firewall moet ik nog een keer aandacht aan besteden tevens misschien Sendmail door Postfix vervangen, maar Sendmail is weer zo "lekker makkelijk"

Geen idee wat ik nog meer zou moeten doen

_{OK OK Ik zou alles in een Jail kunnen draaien, maar als alles redelijk dichtzit en het is geen shared hosting lijkt het me niet echt noodzakelijk of wel ??
Eerst een normale opstelling 100% onder de knie hebben leek me belangrijker.}

[DexterDee]

De setup van de TS is niet echt te vergelijken met een "normale" co-hosted server, omdat deze achter een (ADSL) modem hangt met NAT. Het gebruik van NAT beperkt enigszins de functionaliteit maar biedt daarintegen weer een betere beveiliging, omdat alleen de gebruikte poorten opengezet zijn. Dit maakt het draaien van een firewall niet persé noodzakelijk meer.

Maatregelen zoals jailing etc. zijn echt véél te arbeidsintensief voor een hobbyserver en vergen een degelijke voorbereiding en goede kennis van zaken. Ik werk ook wel in enterprise omgevingen met webhosting, maar daar komen hele andere requirements om de hoek kijken die voor dit type servers helemaal niet interessant zijn. Meestal heb je een aantal subnetten, zoals de DMZ en SSN waartussen firewalls draaien met strikte rulesets. Low level bescherming zoals stateful packet inspection en gefragenteerde UDP pakketten stellen weer extra eisen aan applicaties die naar buiten moeten luisteren. Bovendien kun je SSH sessies beschermen door in te loggen met een private key en de reguliere password optie te disablen. Alle reguliere protocollen zonder strong encryption moeten uitgeschakeld worden. Dus bijvoorbeeld geen FTP maar SFTP via SSH2 en alle hashes omzetten van MD5 naar AES-hash ter voorkoming van rainbow table attacks.

Voor een "thuis"server (co-located hobbyserver) is dit echter allemaal een aantal stappen te ver. Door de voordehand liggende toegangspoorten redelijk dicht te timmeren (SSH met een goed wachtwoord, root disablen) en daemons onder een eigen restricted account te draaien (zonder toegang op gevoelige informatie) kom je al een heel eind. Door alle beschikbare security patches snel uit te voeren en software up-to-date te houden voorkom je misbruik door exploits. Uiteraard moet je ook zorgen dat je server geen open relay host is. Meer hoef je niet te doen om dit soort servers te beveiligen, maar het kan wel. Als je het leuk vindt kun je je natuurlijk uitleven op dingen als SELinux (alhoewel ik heel veel mensen, ook admins, ken die dit onmiddelijk uitzetten op een server). Ik heb zelf SELinux aan staan alleen omdat dit standaard aan stond op mijn installatie

[Verwijderd]

SeLinux is nu voor velen te lastig.... zit te veel in de weg. Maar het geeft wel aan waar we naartoe gaan. AppArmor is weer een stukje vriendelijker. Persoonlijk hoop ik dat het standaard gaat worden. En met audit2allow is het voor een beetje console-wizzard te behappen.

Maar idd.... uptodate zijn en je services met verstand gebruiken staat voorop en is in de meeste gevallen voldoende.