12 trinn til en Linux Apache MySQL PHP webserverroten LAMP sikre

Hacking frekvensen har økt kraftig de siste månedene. Spesielt mye data å bli plukket opp av hacks på webservere. Selv Sony PSN hack tok fordel av en ikke oppdaterte sårbarhet i Apache Web Server. Derfor vil jeg samle action her, kan serveren egen litt tryggere mot angrep utenfra. Of course, dette også ikke gir 100% beskyttelse, men det er bedre å få skurkene i spillet litt vanskeligere. Noen av tiltakene krever bare en minimal installasjon og vedlikehold. Andre trenger mye tid og kunnskap til PHP å fange. Man bør alltid se etter kost-nytte-forhold i valg av sikkerhetstiltak. Det gir ingen mening å beskytte en liten, privat område som Federal Reserve Bank. Imidlertid har få konkrete endringer i systemet allerede en stor betyr mer sikkerhet. Og at du bør behandle selv før det er for sent ....

Alle tips og Codesnips referere til en aktuell Debian boks.

Første Brannmuren - når alt forby

De fleste Linux-distribusjoner i deres standard installasjoner åpne noen porter på utsiden som ikke er absolutt nødvendig. Denne situasjonen kan endre seg raskt, men selv når serveren
spille rundt og prøver ting. Plutselig media server lytter på Internett eller database
aksepterer tilkoblinger fra Internett. Derfor er det ikke galt å disiplinere seg selv og sette opp en meget restriktiv brannmur som i utgangspunktet forbyr Når alle tilkoblinger fra utsiden og tillater bare (selv) utvalgte forbindelser. Heldigvis er dette gjort raskt med iptables. På denne måten kan man ikke lenger yte tjenester for å gjøre tilgjengelig for verden som ikke har noen virksomhet der. Dessverre, du betaler en liten trøst - brannmuren må justeres hver gang når du ønsker å tilby nye tjenester. Likevel er innsatsen for liten og fordelene store.

 # / Bin / bash

 # Slett eksisterende tabeller
 iptables-F

# Alle eingehenden Verbindungen verbieten
 iptables-P INPUT DROP
 iptables-P FORWARD DROP

 # Tillat alle utgående
 iptables-P OUTPUT ACCEPT

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

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

 # Videre tjeneste (UDP) tillate, for eksempel spill Server
 iptables-A INPUT-j ACCEPT-p tcp - dport 4534 

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

 # Allerede etablerte tilkoblinger vil bli akseptert i havn
 # (Nødvendig for noen demoner)
 iptables-A INPUT-m state - state etablert, RELATERTE-j ACCEPT

Denne lille ryggrad kan vi bare fortsette å utvide og legge til sine egne tjenester. Ved arbeid på brannmur, bør du alltid gjøre avsetninger for saken som låser seg selv. Spesielt på eksterne servere som du ikke har fysisk tilgang, er det veldig irriterende å miste et mislykket egen tilgang til brannmuren regelen. For å unngå dette problemet ut av veien, kan man begynne å jobbe på brannmuren midlertidig bare en cron jobb som tilbakestiller brannmuren hvert femte minutt eller serveren på nytt. Reglene er senere testet og elsket, den cron vil bli deaktivert og de nye reglene forblir permanent aktiv.

For å finne ut mer om hvilke tjenester bare lytte til din egen server, kan du bruke netstat:

 # For TCP sockets:
 netstat-LPN | grep tcp

 # Tilsvarende for UDP:
 netstat-LPN | grep udp

For å teste om brannmuren virkelig fungerer, kan du portsøk din egen server fra en annen datamaskin. Det hele fungerte, skal vises i resultatet bare enda porter som er åpne:

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

 # For UDP:
 nmap-su-p1-65 535 meinserver.de

Second SSH logins forbud

På sin egen roten server har ubegrenset SSH tilgang. Dette er ganske hendig, som du kan fra alle SSH klient til serveren ganger bare for å arbeide med den. Ulempen med dette er at kurset kan alle som dessverre har en eller annen måte tatt over sitt eget passord. Det er mye tryggere å tillate SSH innlogginger bare med en gyldig nøkkel-fil. Det er den offentlige nøkkelen til klienten til serveren og kopierte interaktive innlogginger blir deaktivert ved å taste inn et passord.

 # På klienten lage en offentlig nøkkel
 # Hvis spesifisert ved generering av et passord, må man
 # Logg inn senere på tasten filen og passord.  Ellers
 # Trengs bare nøkkelen.

 ssh-keygen-t rsa

 # Den genererte nøkkelen deretter kopiere til serveren

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

 Deretter justere # sshd_config på server / etc / ssh /
 .
 .
 PasswordAuthentication no
 .
 .

 # Deretter starter ny Ssh
 / Etc / init.d / ssh restart

Også her bør man ta forholdsregler for å ikke stenge ute selv om noe ikke fungerer.
Den offentlige nøkkelen på en USB-pinne med tilhørende passord i hodet ditt gjør det mye vanskeligere for skurkene å få et skall.

Tredje SSH Bruteforcing hindre denyhosts

Hvis råd er ikke praktisk og en to forlate komforten av passord-basert innlogging vil, kan du i det minste hindre automatiserte passord priser av angripere på serveren. Mye av bots på internett hele dagen ute etter å gjøre noe mer enn å SSH servere og prøve ut i forskjellige passord. Med et rimelig sikkert passord er ikke et stort problem, men det er en bedre følelse, selv om det er mulig. I tillegg beskytter den også sine brukere, dersom eksisterer på serveren og brukerkontoene. Her kan du ikke stole på at brukerne bruker sikre passord. denyhosts stadig kontrolleres på ssh logins og bruker låser for en viss tid, som har skrevet inn passordet sitt feil gjentas. IP av brukere midlertidig gå inn i / etc / hosts.deny, slik at de ikke lenger har tilgang til er mulig. Dette SSH Bruteforcing til en svært lang og ikke veldig lovende oppgave.

 apt-get install denyhosts

 # Denyhosts fungerer rett etter installasjon.  Det kan være
 # I filen / etc / denyhosts.conf finjustere

Fjerde Svartelister brukes til å blokkere ut kjent problem IPs

I ulike Internett svartelister opprettholdes, hvilken liste et stort antall kriminelle / hakket / spammy / bedragersk servere. Disse IP-lister kan skrives direkte inn i brannmuren, slik at fra denne er kjent for å ikke klarerte servere noen sammenheng er ikke lenger mulig til din egen server. Så du kan redusere mengden av spam på sin egen server, og også drastisk en ting eller script-kiddie lock out, fordi hans russiske proxy plutselig slutter å fungere. Hvordan å gjøre at jeg har vært i en annen blogg artikkelen beskrev eksempel på svarteliste over Infiltrated.net.

Femte Ikke bruk FTP til å arbeide på serveren

FTP er en relikvie av bedre tider da Internett var en liten landsby fortsatt troverdige. Mange admins av nettsteder fortsatt bruke FTP til å overføre filer til serveren eller for å arbeide på ditt eget nettsted. Dessverre er dette svært usikkert, fordi FTP overfører alle data usikret. Passord og data kan leses uten problemer på hvert hop mellom servere og klienter. Det er mye tryggere med sshfs. Gjør det mulig å montere en katalog via SSH på den eksterne serveren lokale filsystem. Man kan da jobbe på serveren som om han var på den lokale datamaskinen. Alle fil tilgang til filer på serveren er helt gjennomsiktig, så du kan også åpne programmet, en lokal grafisk bilde på serveren, redigere og lagre igjen. Mer komfort og sikkerhet uten store anstrengelser.

 # Installer sshfs
 apt-get install sshfs

 # Opprett mountpoint på det lokale filsystemet
 mkdir / media / minserver

 # Server til det lokale filsystemet monteres
 www-data@mein-server.de sshfs: / var / www / media / minserver

 # Nå katalogen er / var / www på min lokale server under / media / minserver tilgjengelig

Sjette Installer oppdateringer

En super sikkert system vil ikke hjelpe dersom selve systemet er feil og en kjent sårbarhet kan utnyttes. I de fleste tilfeller mangler disse sikkerhetsoppdateringene raskt, ofte glemt, men til regelmessige oppdateringer av systemet admins gjør. Enten må du aktivere automatiske oppdateringer på Linux-servere eller ikke er et omstridt tema. Noen vil aldri gjøre det fordi det virker naturlig med mye uflaks kan være at oppdateringene gjør systemet ubrukelig. Dette skjedde med meg i over 10 år med arbeid på Debian-systemer, men aldri og jeg setter pris på fordelene med rettidig og regelmessige oppdateringer, mye høyere enn den resulterende risiko.

 # Denne linjen i / etc / crontab, oppdateringer systemklokken hver dag kl 6 am
 0 6 * rot apt-get update & & apt-get-y oppgradering

Disse rask og skitne metoden fungerte for meg så langt alltid bra. Jeg leste nylig at i Debian pakken repository også finnes ubetjent-oppgraderinger, som løser problemet sannsynligvis noe mer elegant, men jeg har ikke blitt testet.

Selv med et helautomatisk system oppdateringer, dette er en ikke helt av kroken. Hvis en kernel oppdatering har blitt levert, må du starte systemet igjen for hånd, ellers vil endringene ikke vil bli aktive.

Hvis man bruker ikke-PHP-kode på serveren, for eksempel en åpen kildekode CMS eller et forum, er det absolutt nødvendig, selvfølgelig, også denne koden med nye versjoner oppdatert. Siden Debian ikke oppdaterer med endringer i programmer i disse reglene dekker, er manuelt arbeid som trengs her. I beste fall, du leste den postlister av relevante produkter som skal alltid oppdatert.

Syvende PHP med open_basedir fengsle

Mange hacks basert på det faktum at et sikkerhetsproblem i PHP-koden er brukt for å få tilgang til filer i filsystemet tilgang som ikke tilhører stedet, men systemet i seg selv er hvorfor du bør låse opp PHP slik at den kun kan lese i spesielt utpekte kataloger og skrive kan. For dette, php.ini den open_basedir konfigurasjon alternativet. PHP har mulighet til å sette bare lov tilgang til kataloger der. Filer som / etc / passwd er utenfor rekkevidde. Hosting flere nettsider på én server, bør du stille open_basedir i hvert VirtualHost konfigurasjon for hver side.

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

 # Per nettstedet i virtuellverten config:
 php_value open_basedir / var / www / site /: / tmp /

Det er viktig å vurdere om alle nettsteder har blitt lagt til skriptene vanligvis trenger å ha tilgang, ellers kan det være at du er ufør og legitime funksjoner i PHP-programmet.

Åttende Lag dine egne websider for MySQL-brukere

Bruker sin egen PHP-MySQL program, bør du absolutt lage for Apllikation en egen MySQL bruker og ikke under noen omstendigheter bruke MySQL rotbrukeren forespørsler. Du bør også begrense brukerens rettigheter så langt som egentlig bare operasjoner er tillatt, noe som krever PHP script. CREATE TABLE og DROP TABLE er som vanlig i SQL-injeksjoner er brukt og i de fleste PHP-applikasjoner aldri nødvendig. Hostet man mehrere Websites mit mehreren Datenbanken auf einem Server, sollte man für alle Datenbanken eigene Benutzer anlegen. Dermed, etter et vellykket angrep, har en angriper bare tilgang til en av databaser og ikke direkte i det hele tatt. Hvis du ikke ønsker å prøve kommandolinjen for å administrere MySQL brukerkontoer, brukeradministrasjon fungerer også ganske lett med phpMyAdmin under fanen "rettigheter".

Niende PHP feilmeldinger off

PHP feilmeldinger, kan en angriper avsløre mye om din egen server: katalog strukturer, database strukturer, konfigurasjon feil, etc. De ser også for brukeren svært uprofesjonelt. Av denne grunn bør de være på en live web server off utgangspunktet, siden du bare kommer til å fortsette å se i loggene.

 # Global php.ini via:
 # / Etc/php5/apache2/php.ini
 display_errors = Off

 # Per nettstedet i virtuellverten config:
 php_flag display_errors Off

 # Feilmeldinger lese det likevel:
 cat / var/log/apache2/error.log | grep php

10nde Target for SQL-injeksjon grense med ModSecurity

SQL-injeksjoner er de mest brukte metoden for angrep på webservere. Nås direkte via web-applikasjon og den møter en nettleser til å utføre dem. Her er overført av brukeren variablene bygget sende SQL-spørringer til databasen med rettighetene til brukeren eget alt i databasen vil slette lese eller redigere dem. En ekte ekte beskyttelse mot SQL-injeksjon eksisterer bare dersom PHP-kode ble skrevet nettstedet i forhold til disse angrepene. Jede Variable aus Benutzereingaben, die in eine SQL-Abfrage gelangen könnte, muss geprüft und escaped werden. PHP tilbyr funksjonen real_mysql_escape_string ().

Hvis du ikke er sikker på om koden er ren, kan mod_security for Apache hjelpe en stor mengde replay angrep uansett. mod_security sjekker konstant alle forespørsler til webserveren og svarer på dem pre-laget mønstre med mange SQL-injeksjon angrep kan være blokkert. Dessverre mod_security fungerer godt bare med en manuell innsats. Ofte etter en fersk installasjon mod_security blokker også ønsket (normal) funksjonene til PHP kode, slik at man har ingen andre valg, som fullstendig søknad for å teste ut anlegget igjen. Først da finner man ut om mod_security umulig å blokkere funksjoner ønsket. Er dette tilfellet, filtrere listen som skal justeres for å forsvinne slik at falske positive.

Konfigurasjonen av mod_security er noe komplisert og er utenfor omfanget av denne artikkelen, men det er tonnevis av gode tutorials på internett mod_security.

11. Passkontroll - Apache vet ikke hvem han er
Dette er ikke egentlig effektiv metode mot en hack, gjør det automatiske skript som leter etter server-versjoner, men litt tyngre. Vanligvis Apache viser på sider med feilmeldinger (f.eks 404 Not Found) sin server signatur.

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

Det eliminerer eventuelle aggressive vil motta informasjon minst en gang før på webserveren er herved etablert og den versjonen nivå. Serveren signaturen er slått av raskt:

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

12. Ikke deaktiver bruk Apache-moduler

Som standard har Apache lastet noen moduler, som er nesten aldri nødvendig. På Debian finner du lastet modulene
som en myk kobling i / etc/apache2/mods-enabled.

Kan fjernes nesten alltid:

mod_cgi

Brukes til å kjøre CGI skript. Denne teknikken går tilbake til begynnelsen av det Web og var stamfaren til moderne skriptspråk å gi mulighet for dynamiske websider. mod_cgi er unødvendig for 99% av PHP nettsteder og en defekt Apache Config er en potensiell sikkerhetsrisiko hull

 a2dismod cgi

mod_status

Lar nettlesere å lese status informasjon på Apache. Det er nesten aldri brukt til "normal" områder, gir status informasjon om angriperne, men Apache.

 a2dismod status

mod_autoindex

mod_autoindex sikrer at kataloger kan være oppført på web server, hvis det ikke er en gyldig index side i den aktuelle katalogen. Hvis denne funksjonaliteten ikke er ønskelig, bør du deaktivere den, siden den hele katalogen trær på serveren kan være eksternt synlige.

 a2dismod AutoIndex