12 tiltak til en Linux Apache MySQL PHP webserverroten LAMP sikre

Hyppigheten av hacking har økt dramatisk de siste månedene. Spesielt mye data å bli plukket opp av hacks på webservere. Selv Sony PSN hack tok fordel av en unpatched sårbarhet i Apache Web Server. Så her er jeg heve tiltak som serveren kan eie litt tryggere mot angrep utenfra. Selvfølgelig, dette også gir ikke 100% beskyttelse, men det er bedre å gjøre skurkene spillet litt vanskeligere. Noen av tiltakene krever bare en minimal installasjon og vedlikehold. Andre trenger mye tid og kunnskap om PHP til fange. Du bør alltid ta hensyn til kost-nytte-forholdet 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 bety mer sikkerhet. Og at du bør behandle selv før det er for sent ....

Alle tips og Codesnips henvise til en aktuell Debian boks.

Første Brannmuren - forby Når alt

De fleste Linux-distribusjoner i sine 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, er selv medieserveren lytter på Internett eller database
aksepterer tilkoblinger fra Internett. Derfor er det ikke galt å disiplinere seg selv og sette på en svært restriktiv brannmur som i utgangspunktet forbyr Når alle tilkoblinger utenfra og lar bare (selv) utvalgte forbindelser. Heldigvis er dette gjort raskt med iptables. På denne måten kan en ikke lenger tilby tjenester for å gjøre tilgjengelig for hele 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 liten og fordelene store.

 # / Bin / bash

 # Slett eksisterende tabeller
 iptables-F

 # Forby alle innkommende tilkoblinger
 iptables-P INPUT DROP
 iptables-P FORWARD DROP

 # Tillat all utgående
 iptables-P OUTPUT ACCEPT

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

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

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

 # Tillat alt fra localhost.  (Hvis du vil tillate uhindret adgang til selve serveren, dets tjenester,
 # For eksempel PHP på den lokale databasen
 iptables-A INPUT-s 127.0.0.1-j ACCEPT

 # Allerede etablert forbindelser vil bli akseptert på hver port
 # (Kreves for enkelte daemoner)
 iptables-A INPUT-m state - stat som har etablert, RELATED-j ACCEPT

Denne lille backbone vi kan bare fortsette å utvide og legge til sine egne tjenester. Ved arbeid på brannmuren, bør du alltid legge til rette for saken som låser seg selv. Spesielt for eksterne servere som du ikke har fysisk tilgang, er det veldig irriterende å tape ved et mislykket brannmurregel sin egen tilgang. For å unngå dette problemet ute av veien, kan du forlater arbeidet for å starte på brannmuren midlertidig bare en cron jobb som tilbakestiller brannmuren med få minutters mellomrom eller serveren starter på nytt. Er reglene senere testet og elsket, den cronjob vil bli deaktivert og de nye reglene forblir permanent aktiv.

For å finne ut hvilke tjenester er like rundt lytter 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 port skanne din egen server fra en annen datamaskin. Alt fungerte, og det bør resultere i kun de selv porter som er åpne:

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

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

Andre SSH pålogginger forbud

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

 # På klienten opprette en offentlig nøkkel
 # Hvis spesifisert når du genererer passord, må man
 # Loggfil senere nøkkelen og passordet.  Ellers
 # Trengs bare nøkkelen.

 ssh-keygen-t rsa

 # Kopier den genererte nøkkelen til serveren

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

 # Nå justerer sshd_config på server / etc / ssh /
 .
 .
 PasswordAuthentication no
 .
 .

 # Deretter starter igjen RearBBpos
 / Etc / init.d / ssh start

Selv 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 svindlerne å få et skall.

Tredje SSH Bruteforcing forhindre denyhosts

Hvis råd er ikke praktisk 2 og du ikke gi opp den praktiske passord-baserte pålogginger vil, kan du i det minste hindre at de automatiske priser av angripere på serveren. Mye av roboter på internett hele dagen ute etter å gjøre noe mer enn å SSH servere og prøve ut i dine forskjellige passord. Med et rimelig sikkert passord er ikke et stort problem, men det er en bedre følelse, ikke engang om det er mulig. I tillegg beskytter den også sine brukere, hvis det er på serveren og bruker kontoer. Her kan du ikke stole på brukerne til å bruke sikre passord. denyhosts stadig anmeldt og ssh innlogginger på brukerens låser en stund som har skrevet sine passordet 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 meget lang og ikke veldig lovende oppgave.

 apt-get install denyhosts

 Nr Denyhosts fungerer rett etter installasjonen.  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 / uredelig servere. Disse IP-listene kan skrives direkte inn i brannmuren, slik at dette er kjent for ikke å klarerte datamaskiner ikke kan koble det hele tatt til sin egen server. Så du kan redusere mengden av spam på sin egen server dramatisk og det ene eller det andre script kiddie låse ut, 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 å fungere på server

FTP er en relikvie av bedre tider da internett var en liten landsby fortsatt klarert. Mange administratorer av nettsteder fortsatt bruke FTP til å overføre filer til serveren eller å arbeide på sin egen hjemmeside. Dessverre er dette svært usikkert, ettersom FTP overfører alle data usikret. Passord og data kan leses uten problemer på hvert hopp mellom servere og klienter. Mye tryggere å gå med sshfs. Lar deg montere en katalog via ssh på den eksterne serveren lokale filsystem. Du kan deretter arbeide på serveren som om han var på den lokale datamaskinen. All fil tilgang til filer på serveren er helt gjennomsiktig, slik at du kan åpne med den lokale grafikk program for å redigere et bilde på serveren direkte, og deretter lagre. 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 mount
 sshfs www-data@mein-server.de :/ 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 hvis selve systemet er feil, og en kjent sårbarhet kan utnyttes. I de fleste tilfeller, stengt disse sårbarhetene raskt, men ofte glemt admin regelmessige oppdateringer av systemet å gjøre. Enten må du aktivere automatiske oppdateringer på Linux-servere eller ikke er en omstridt sak. Noen vil aldri gjøre, fordi det naturlig med mye uflaks kan være at oppdateringene gjøre systemet ubrukelig. Dette skjedde med meg i over 10 år med arbeid på Debian-systemer, men aldri og jeg setter pris på fordelene med tidsriktige og jevnlige oppdateringer, mye høyere enn den resulterende risiko.

 # Denne linjen i / etc / crontab, oppdateres systemklokken hver dag klokken 6
 0 6 *** root apt-get update && apt-get-y oppgradering

Disse rask og skitten metoden fungerte for meg så langt alltid bra. Jeg leste nylig at i Debian depotet og pakken ubetjente-oppgraderinger eksisterer som løser problemet sannsynligvis mer elegant, men jeg har ikke blitt testet.

Selv med disse vollautomtischen systemoppdateringer er det ikke helt av kroken. Hvis en kernel oppdatering har blitt levert, må du starte systemet igjen for hånd, ellers vil ikke endringene være aktiv.

Hvis vi bruker tredjeparts PHP-kode på serveren, for eksempel en åpen kildekode CMS eller et forum, er det selvsagt helt nødvendig og denne koden med nye versjoner oppdatert. Siden Debian ikke oppdaterer sine endringer i disse programmene i reglene dekker dette manuelt arbeid er nødvendig. Den beste måten å lese postlister med tilsvarende produkter for å være alltid oppdatert.

Syvende PHP med open_basedir fengsle

Mange hacks basert på det faktum at en sårbarhet i PHP-koden brukes for å få tilgang til filer i filsystemet tilgang som ikke hører til området, men selve systemet er derfor du bør låse opp PHP slik at den leser bare i spesielt utpekte kataloger og skrive tillatt. For dette, php.ini den open_basedir konfigurasjonsvalget. PHP har mulighet til å sette bare adgang til kataloger der. Filer som / etc / passwd er ute av rekkevidde. Hosting flere nettsteder på en server, bør du stille open_basedir i hver virtuell vert konfigurasjon på 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 funksjonshemmede og legitime funksjoner i PHP-programmet.

Åttende Lag dine egne websider for MySQL-brukere

Bruk din egen PHP-MySQL-programmet, bør du absolutt lage for Apllikation egen MySQL bruker og under ingen omstendigheter bruke MySQL root bruker forespørsler. Du bør også begrense brukerens rettigheter så langt at det egentlig bare operasjoner er tillatt, noe som krever PHP script. CREATE TABLE og DROP TABLE er som vanlig i SQL-injeksjoner og brukes i de fleste PHP-applikasjoner aldri nødvendig. Det vert flere nettsteder med flere databaser på en server, bør du lage dine egne databaser for alle brukere. Dermed, etter et vellykket angrep, har en angriper bare tilgang til en av databasene og ikke direkte i det hele tatt. Hvis du ikke ønsker å prøve kommandolinjen for å administrere MySQL brukerkontoer, brukergrupper lederfunksjoner også ganske enkelt med phpMyAdmin under fliken "rettigheter".

Niende PHP feilmeldinger off

PHP feilmeldinger en angriper kan avsløre mye om din egen server: katalogen 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, alltid slå av fordi du bare kommer til å fortsette å se på 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 Mål for SQL-injeksjon grense med ModSecurity

SQL-injeksjoner er den mest brukte metoden for angrep på webservere. Tilgjengelig direkte via web-applikasjon, og den møter en nettleser for å utføre dem. Her blir overført av brukeren variablene bygget SQL spørringer sendt til rettighetene til databasen bruker all sin database på vil slette lese eller redigere dem. En ekte ekte beskyttelse mot SQL-injeksjon eksisterer bare dersom PHP-koden ble skrevet området i forhold til disse angrepene. Hver variabel fra brukerundersøkelser, som kan komme inn i en SQL-spørring, må den testes og rømte. PHP tilbyr funksjonen real_mysql_escape_string ().

Hvis du er usikker på om koden er ren, kan mod_security for Apache hjelpe avverge en stor mengde av disse angrepene uansett. mod_security konstant gjennomgang alle forespørsler til webserveren og reagerer på pre-mønster som mange SQL-injeksjon angrep kan være blokkert. Dessverre fungerer bare bra med mod_security manuell innsats. Ofte etter en fersk installasjon mod_security blokker også nødvendig (vanlig) funksjonene i 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 kanskje ikke engang vil blokkere funksjoner. Hvis ja, så filteret listen som skal justeres for å forsvinne slik at falskt positive.

Konfigurasjonen av mod_security er noe komplisert og er utenfor rammen av denne artikkelen, men det finnes tonnevis av gode tutorials på Internett mod_security.

11. ID sjekk - 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 peker til 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 eventuell aggressor vil motta minst én gang før om eigesetzten webserveren og versjonen nivå. Signaturen serveren er slått av raskt:

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

12. Ikke bruk deaktivere apache moduler

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

Kan fjernes nesten alltid:

mod_cgi

Brukes for å kjøre CGI-scripts. Denne teknikken går tilbake til begynnelsen av det Web og var stamfar til moderne skriptspråk for å tillate dynamiske websider. mod_cgi er unødvendig for 99% av PHP og har en defekt Apache config er en potensiell sikkerhetsrisiko hull

 a2dismod cgi

mod_status

Lar nettlesere å lese status informasjon på Apache. Det blir nesten aldri brukt til "normale" 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, fordi den hele katalogtrær på webserveren kan være eksternt synlige.

 a2dismod automatiske indeksen