12 trin til en Linux Apache MySQL PHP web server roden LAMP sikkert

Hacking frekvensen er steget markant i de seneste måneder. Især en masse data, der skal samles op af hacks på web-servere. Selv Sonys PSN-hack benyttede sig af en unpatched sårbarhed i Apache Web Server. Derfor samler jeg aktion her, kan serveren eje en lidt mere sikker mod angreb udefra. Selvfølgelig også dette ikke giver 100% beskyttelse, men det er bedre at gøre de slemme fyre spillet lidt mere vanskeligt. Nogle af de foranstaltninger kræver kun en minimal installation og vedligeholdelse. Andre har brug for en masse tid og viden om PHP til fange. Man skal altid kigge efter cost-benefit-forholdet i udvælgelsen af ​​sikkerhedsforanstaltninger. Det giver ingen mening at beskytte en lille, privat site som Federal Reserve Bank. Men kun få konkrete ændringer i systemet i forvejen har et stort betyde mere sikkerhed. Og at du skal behandle endnu før det er for sent ....

Alle tips og Codesnips henvise til en nuværende Debian-boks.

Første Den firewall - Når alt forbyde

De fleste Linux-distributioner i deres standard installationer åbne nogen porte til det fri, som ikke er absolut nødvendige. Denne situation kan ændre sig hurtigt, men selv når serveren
fjolle rundt og prøver ting. Pludselig medierne serveren lytter på internettet eller i databasen
accepterer forbindelser fra internettet. Derfor er det ikke forkert at disciplinere sig selv og etablere en meget restriktiv firewall, der dybest set forbyder Når alle tilslutninger udefra og tillader kun (selv-) valgte forbindelser. Heldigvis sker det hurtigt med iptables. På denne måde kan man ikke længere udveksling af tjenesteydelser for at gøre tilgængelige for hele verden, der har noget at gøre der. Desværre, du betaler en lille trøst - firewallen skal justeres, hver gang du ønsker at tilbyde nye tjenester. Ikke desto mindre, indsatsen er lille og fordelene store.

 # / Bin / bash

 # Slet eksisterende tabeller
 iptables-F

 # Forbyd alle indgående forbindelser
 iptables-P INPUT DROP
 iptables-P FORWARD DROP

 # Tillad alle udgående
 iptables-P OUTPUT ACCEPT

 # Tillad SSH
 iptables-A INPUT-j ACCEPT-p tcp - dport 22 

 # Tillad HTTP
 iptables-A INPUT-j ACCEPT-p tcp - dport 80 

 # Desuden, service (UDP) tillader f.eks Game Server
 iptables-A INPUT-j ACCEPT-p tcp - dport 4534 

 # Tillad alle fra localhost.  (For selve serveren uhindret adgang til sine tjenester,
 # For eksempel PHP til den lokale database
 iptables-A INPUT-s 127.0.0.1-j ACCEPT

 # Allerede etablerede forbindelser vil blive accepteret i enhver havn
 # (Påkrævet for nogle dæmoner)
 iptables-A INPUT-m state - der er etableret, RELATEREDE-j ACCEPT

Denne lille backbone, vi kan blot fortsætte med at udvide og tilføje deres egne tjenester. Ved arbejde på firewall, bør du altid sikre bestemmelser for det tilfælde, der låser sig selv. Især på fjernservere, som du ikke har fysisk adgang, er det meget irriterende at miste et mislykket egen adgang til firewallen reglen. For at undgå dette problem ud af den måde, kan man begynde at arbejde på firewallen midlertidigt bare et cron job, der nulstiller firewall hvert par minutter eller serveren genstartes. Reglerne er senere afprøvet og elsket, det cronjob vil blive deaktiveret og de nye regler er permanent aktive.

For at finde ud af om hvilke services bare lytte til din egen server, kan du bruge netstat:

 # For TCP sockets:
 netstat-LPN | grep tcp

 # Tilsvarende for UDP:
 netstat-LPN | grep udp

For at teste, hvis firewallen virkelig virker, kan du port scanne din egen server fra en anden computer. Det hele fungerede ud, skal vises i resultatet kun de selv porte der er åbne:

 # For TCP:
 nmap-P1-65 535 meinserver.de

 # For UDP:
 nmap-SU-P1-65 535 meinserver.de

Anden SSH logins forbud

På sin egen rod server har ubegrænset SSH adgang. Dette er ganske smart, som du kan fra en SSH klient til serveren gange bare for at arbejde på det. Ulempen ved dette er, at kurset kan alle, der desværre har en eller anden måde overtaget deres egne adgangskoder. Det er meget sikrere at tillade SSH login kun med en gyldig nøgle-fil. Det er den offentlige nøgle af klienten til serveren og kopierede interaktiv login er slået fra ved at indtaste en adgangskode.

 # På klienten, skal du oprette en offentlig nøgle
 # Hvis angivet, når du genererer en adgangskode, er man nødt til
 # Log ind senere på nøglefilen og adgangskoden.  Ellers
 # Kun behov for nøglen.

 ssh-keygen-t rsa

 # Den genererede nøglen derefter kopiere til serveren

 ssh-copy-id-i ~ /. ssh / id_rsa.pub root@meinserver.de

 Juster derefter # sshd_config på serveren / etc / ssh /
 .
 .
 PasswordAuthentication ingen
 .
 .

 # Så starter nye SSH
 / Etc / init.d / ssh genstart

Selv her bør man tage forholdsregler for at ikke lukke ud, selv hvis noget ikke virker.
Den offentlige nøgle på en USB stick med tilhørende password i dit hoved gør det meget sværere for skurkene at få en shell.

Tredje SSH Bruteforcing forhindre denyhosts

Hvis rådgivning ikke er praktisk og et to opgive komfort password-baserede logins vil, kan du i det mindste forhindre den automatiske password satserne for angribere på serveren. En masse af bots på internettet hele dagen søger at gøre noget mere end at SSH-servere og afprøve i jeres forskellige adgangskoder. For en nogenlunde sikker adgangskode er ikke et stort problem, men der er en bedre fornemmelse, selv om det er muligt. Hertil kommer det også beskytter sine brugere, hvis der findes på serveren og brugerkonti. Her kan du ikke stole på, at brugerne bruger sikre passwords. denyhosts konstant kontrolleres på ssh logins og brugeren låser i en bestemt tid, som er trådt deres password forkert gentages. IP er af brugere midlertidigt gå ind i / etc / hosts.deny, så de ikke længere har adgang til, er mulig. Dette SSH Bruteforcing til en meget langvarig og ikke særlig lovende opgave.

 apt-get install denyhosts

 # Denyhosts virker lige efter installation.  Det kan være
 # I filen / etc / denyhosts.conf finjustere

4. Sortlister bruges til at blokere kendt problem IP-adresser

I forskellige Internet sortlister bevares, hvilken liste en lang række kriminelle / hakkede / spammy / svigagtige servere. Disse IP-lister kan indtastes direkte i firewall, så der fra kendte det ikke til betroede servere, ingen forbindelse er ikke længere muligt at din egen server. Så du kan reducere mængden af ​​spam på deres egen server, og også drastisk en ting eller script-kiddie lock-out, fordi hans russiske proxy pludselig holder op med at arbejde. Sådan gør du, at jeg har været i en anden blog artiklen beskrev eksempel på den sortliste over Infiltrated.net.

5. Må ikke bruge FTP til at arbejde på serveren

FTP er et levn fra bedre tider, hvor internettet var en lille landsby stadig tillid til. Mange administratorer af websites stadig bruge FTP til at overføre filer til serveren eller til at arbejde på dit eget websted. Desværre er det meget usikkert, da FTP overfører alle data usikrede. Passwords og data kan læses uden problemer på hvert hop mellem servere og klienter. Det er langt sikrere med sshfs. Gør det muligt at montere en mappe via SSH på den eksterne server lokale filsystem. Man kan derefter arbejde på serveren, som om han var på den lokale computer. Alle fil adgang til filer på serveren er helt gennemsigtig, så du kan også åbne programmet, en lokal grafisk billede på serveren, redigere og gemme igen. Mere komfort og sikkerhed uden megen anstrengelse.

 # Installer sshfs
 apt-get install sshfs

 # Opret mountpunkt på det lokale filsystem
 mkdir / media / myserver

 # Server til det lokale filsystem montere
 www-data@mein-server.de sshfs: / var / www / media / myserver

 # Nu mappen er / var / www på min lokale server under / media / myserver ledigt.

6. Installer opdateringer

En super sikkert system ikke vil hjælpe, hvis selve systemet er behæftet med fejl, og en kendt sårbarhed kan udnyttes. I de fleste tilfælde mangler disse sikkerhedsforanstaltninger hurtigt, ofte glemt, at regelmæssige opdateringer af systemet admins gøre. Om du skal aktivere automatiske opdateringer på Linux-servere eller ej, er et omstridt spørgsmål. Nogle vil aldrig gøre det, fordi det virker naturligt med en masse dårlige held kan være, at de opdateringer gør systemet ubrugeligt. Dette skete for mig i mere end 10 års arbejde på Debian-systemer, men aldrig og jeg sætter pris på fordelene ved rettidige og regelmæssige opdateringer, meget højere end den deraf følgende risiko.

 # Denne linje i / etc / crontab, opdaterer systemet ur hver dag kl 06:00
 0 6 * * * root apt-get update & & apt-get-y upgrade

Disse quick-and-dirty metode virkede for mig indtil videre altid godt. Jeg læste for nylig, at i Debian-pakken repository findes også uden opsyn-opgraderinger, som løser det problem nok noget mere elegant, men jeg er ikke blevet testet.

Selv med en fuldt automatiseret system opdateringer, er dette en ikke helt off the hook. Hvis en kernel opdatering er blevet leveret, er du nødt til at starte systemet igen med hånden, ellers vil ændringerne ikke bliver aktive.

Hvis man anvender ikke-PHP kode på serveren, så som et open source CMS eller et forum, er det absolut nødvendigt, selvfølgelig, også denne kode med nye versioner op til dato. Da Debian ikke opdaterer med ændringer af ansøgninger på disse regler dækker, er manuelt arbejde behov for her. I bedste fald læse den postlister af relevante produkter, der skal altid up to date.

7. PHP med open_basedir fængsle

Mange hacks baseret på det faktum, at en sårbarhed i PHP-kode bruges til at få adgang til filer i filsystemet adgang, som ikke hører til stedet, men selve systemet er derfor, du skal låse op PHP, så det read only i særligt udpegede mapper og skrive kan. Til dette. Php.ini den open_basedir konfigurationsindstilling PHP har mulighed til at sætte kun tilladt adgang til mapperne der. Filer såsom / etc / passwd er uden for rækkevidde. Vært for flere websteder på én server, skal du indstille open_basedir i hver VirtualHost konfiguration for hver side.

 # Global php.ini via:
 # / Etc/php5/apache2/php.ini
 open_basedir = / var / www /: / tmp /

 # Per stedet på de VirtualHost config:
 php_value open_basedir / var / www / site /: / tmp /

Wichtig ist zu prüfen ob wirklich alle Orte eingetragen wurden, auf die die Skripte normalerweise Zugriff haben müssen, ansonsten kann es sein, dass man auch legitime Funktionen der PHP-Applikation behindert.

8. Für Websites einen eigenen MySQL-Benutzer anlegen

Benutzt die eigene PHP-Applikation MySQL, sollte man unbedingt für die Apllikation einen eigenen MySQL-Benutzer anlegen und auf keinen Fall den MySQL-root-Benutzer für Zugriffe nutzen. Außerdem sollte man die Rechte des Benutzers so weit einschränken, dass wirklich nur noch Operationen erlaubt sind, die das PHP-Skript benötigt. CREATE TABLE und DROP TABLE werden zum Beispiel häufig bei SQL-Injections genutzt und werden in den meisten PHP-Applikationen nie benötigt. Hostet man mehrere Websites mit mehreren Datenbanken auf einem Server, sollte man für alle Datenbanken eigene Benutzer anlegen. So hat ein Angreifer nach einem erfolgreichen Angriff nur Zugriff auf eine der Datenbanken und nicht direkt auf alle. Wenn man nicht die Kommandozeile bemühen möchte, um die MySQL-Useraccounts zu verwalten, funktioniert das Usermanagement auch recht einfach mit PHPmyAdmin unter der Registerkarte "Rechte".

9. PHP Fehlermeldungen abschalten

PHP-Fehlermeldungen können einem Angreifer viel über den eigenen Server verraten: Verzeichnisstrukturen, Datenbankstrukturen, Konfigurationsfehler, etc. Außerdem sehen sie für den Benutzer sehr unprofessionell aus. Aus diesem Grund sollte man sie auf einem Live-Webserver grundsätzlich abschalten, da man sie ohnehin weiterhin in den Logs sehen kann.

# Global per php.ini:
# /etc/php5/apache2/php.ini
display_errors = Off

# Per Site in der VirtualHost Config:
php_flag display_errors Off

# Fehlermeldungen trotzdem lesen:
cat /var/log/apache2/error.log | grep PHP

10. Angriffsfläche für SQL-Injections einschränken mit modSecurity

SQL-injections sind die wohl am häufigsten genutzte Angriffsmethode auf Webserver. Der Zugriff erfolgt direkt über die Webapplikation und es genügt ein Browser um sie durchzuführen. Dabei werden über vom User übermittelte Variablen geschickt SQL-Abfragen eingebaut, die mit den Rechten des Datenbankbenutzers alles an der eigenen Datenbank nach belieben auslesen, löschen oder bearbeiten können. Ein wirklicher echter Schutz gegen SQL-Injections besteht nur, wenn der PHP-Code der Site im Hinblick auf diese Angriffe geschrieben wurde. Jede Variable aus Benutzereingaben, die in eine SQL-Abfrage gelangen könnte, muss geprüft und escaped werden. PHP bietet dafür die Funktion real_mysql_escape_string().

Ist man nicht sicher, ob der Code sauber ist, kann mod_security für den Apache helfen eine große Menge dieser Angriffe trotzdem abzuwehren. mod_security überprüft ständig alle Requests an den Webserver und reagiert auf vorgefertigte Muster mit denen viele SQL-Injection-Angriffe abgewehrt werden können. Leider funktioniert auch mod_security nur gut mit manuellem Aufwand. Oft blockt mod_security nach einer frischen Installation auch gewünschte (normale) Funktionen des eigenen PHP-Codes, so dass einem nichts anderes übrig bleibt, als die komplette Applikation nach der Installation einmal durchzutesten. Nur so findet man heraus, ob mod_security nicht eventuell auch gewünscht Funktionen blockt. Ist das der Fall, muss die Filterliste angepasst werden, so dass die false-positives verschwinden.

Die Konfiguration von mod_security ist etwas komplizierter und würde den Umfang dieses Artikels sprengen, es gibt aber massenweise gute Tutorials zu mod_security im Internet.

11. Ausweiskontrolle - Der Apache sagt nicht mehr, wer er ist
Dies ist keine wirklich wirkungsvolle Methode gegen einen Hack, sie macht es automatisierten Skripten, die nach Server-Versionen suchen aber etwas schwerer. Normalerweise zeigt der Apache auf Seiten mit Fehlermeldungen (zB 404 Not Found) seine Serversignatur.

Apache/2.2.16 (Debian) Server at www.daniel-ritter.de Port 80

So erhalten potentielle Angreifer zumindest schon einmal Informationen über den eigesetzten Webserver und den Versionsstand. Die Serversignatur ist schnell ausgeschaltet:

#/etc/apache2/conf.d/security
ServerSignature Off

12. Nicht benutze Apache-Module deaktivieren

Per default hat der Apache einige Module geladen, die fast nie benötigt werden. Unter Debian findet man die geladenen Module
als Softlinks in /etc/apache2/mods-enabled.

Fast immer entfernt werden können:

mod_cgi

Dient dem ausführen von CGI-Skripten. Diese Technik stammt noch aus den Urzeiten des Web und war der Vorvater der modernen Skriptsprachen um dynamische Webseiten zu ermöglichen. mod_cgi ist auf 99% der PHP-Websites unnötig und bei einer fehlerhaften Apache-Config eine potentielle Sicherheitslücke

a2dismod cgi

mod_status

Ermöglicht es Browsern Statusinformationen über den Apache auszulesen. Es wird so gut wie nie für "normale" Sites genutzt, bietet Angreifern aber Statusinformationen über den Apache.

a2dismod status

mod_autoindex

mod_autoindex sorgt dafür, dass Verzeichnisse auf dem Webserver aufgelistet werden können, wenn es keine gültige Index-Seite in dem entsprechenden Verzeichnis gibt. Falls diese Funktionalität nicht erwünscht ist, sollte man sie abschalten, da durch sie ganze Verzeichnisbäume auf dem Webserver nach aussen sichtbar werden können.

a2dismod autoindex