12 środków do Apache PHP MySQL Linux web server LAMP korzeni zabezpieczyć

Częstotliwości hakowania dramatycznie wzrosła w ostatnich miesiącach. Szczególnie wiele danych do odebrania przez hacków na serwerach internetowych. Nawet Sony PSN Hack wykorzystał niezałataną lukę w zabezpieczeniach serwera WWW Apache. Więc tutaj jestem podnoszenie środki, że serwer może posiadać trochę bezpieczniejsze przed atakami z zewnątrz. Oczywiście, to również nie zapewnia 100% ochronę, ale lepiej jest zrobić złych facetów w grę nieco trudniejsze. Niektóre z tych środków wymaga jedynie minimalnej instalację i konserwację. Inni potrzebują dużo czasu i wiedzy o PHP złapać. Należy zawsze zwracać uwagę na stosunek kosztów i korzyści w wyborze środków bezpieczeństwa. Nie ma sensu, aby chronić małe, prywatne witryny, takie jak Federal Reserve Bank. Jednak kilka specyficznych zmian w systemie ma już dużą oznacza większe bezpieczeństwo. I że należy leczyć nawet zanim będzie za późno ....

Wszystkie porady i Codesnips odnoszą się do bieżącego pola Debiana.

Pierwszy Firewall - zakazać Gdy wszystko

Większość dystrybucji Linuksa w ich instalacji domyślnych otwierać żadnych portów na zewnątrz, które nie są absolutnie konieczne. Ta sytuacja może się szybko zmienić, jednak nawet wtedy, gdy serwer
zabawy i próbuje rzeczy. Nagle, nawet media serwer nasłuchuje w Internecie lub bazy danych
akceptuje połączenia z Internetem. Dlatego też nie jest źle, aby zdyscyplinować się i położyć na bardzo restrykcyjną zaporą ogniową, że w zasadzie zakazuje Gdy wszystkie połączenia z zewnątrz i pozwala tylko (auto) wybranych związków. Na szczęście robi się to szybko z iptables. W ten sposób nie można już świadczyć usługi udostępnić światu, że nie mają tam działalności handlowej. Niestety, musisz zapłacić trochę komfortu - zapora musi być dostosowana za każdym razem, gdy chcesz zaoferować nowe usługi. Niemniej jednak, wysiłek jest niewielki, a korzyści duże.

 # / Bin / bash

 # Usuń istniejące tabele
 iptables-F

 # Zezwalaj wszystkie połączenia przychodzące
 iptables-P INPUT DROP
 iptables-P FORWARD DROP

 # Zezwalaj na wszystkie wychodzące
 iptables-P OUTPUT ACCEPT

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

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

 # Dodatkowe usługi (UDP) umożliwiają, na przykład serwer gry
 iptables-A INPUT-j ACCEPT-p tcp - dport 4534 

 # Zezwalaj na wszystko z localhost.  (Aby umożliwić niezakłócony dostęp do samego serwera, jej usług,
 # Na przykład, PHP na lokalnej bazie danych
 iptables-A INPUT-s 127.0.0.1-j ACCEPT

 # Już nawiązanych połączeniach będą przyjmowane w każdym porcie
 # (Wymagane przez niektóre demony)
 iptables-A INPUT-m state - state ESTABLISHED, RELATED-j ACCEPT

Ten mały szkielet możemy po prostu nadal rozwijać i dodawać własne usługi. Podczas pracy na zaporze, należy zawsze zawierać postanowienia dotyczące wypadku, który blokuje sam. Specjalnie dla zdalnych serwerach, do których nie mają fizycznego dostępu, to jest bardzo denerwujące stracić przez nieudanej reguły zapory własny dostęp. W celu uniknięcia tego problemu z drogi, możesz zostawić pracę, aby rozpocząć na zaporze chwilowo tylko crona który resetuje firewall co kilka minut lub ponownym uruchomieniu serwera. Są zasady później testowany i kochane, cronjob zostanie wyłączony, a nowe zasady pozostają stale aktywne.

Aby dowiedzieć się, które usługi są tuż słuchania własnego serwera, możesz użyć netstat:

 # Dla gniazd TCP:
 netstat-LPN | grep tcp

 # Podobnie dla UDP:
 netstat-LPN | grep udp

Aby sprawdzić, czy zapora naprawdę działa, możesz skanowania portów własnego serwera z innego komputera. Wszystko opracowane i powinno skutkować tylko porty a nawet otwartych:

 # Dla protokołu TCP:
 nmap-P1-65 535 meinserver.de

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

Drugi SSH logowanie zakaz

Na swoim serwerze głównym masz pełny dostęp SSH. Jest to całkiem przydatne, jak można z dowolnego klienta SSH do czasów serwerów tylko do pracy na nim. Minusem jest to, że kurs może każdy, kto niestety jest w jakiś sposób przejęta własnych haseł. To o wiele bezpieczniejsze, aby umożliwić logowanie SSH tylko z ważnego pliku klucza. Dlatego klucz publiczny klienta do serwera i kopiowane identyfikatory logowania interaktywnych są wyłączone poprzez wprowadzenie hasła.

 # Na kliencie utwórz klucz publiczny
 # Jeśli określone podczas generowania hasła, trzeba
 # Plik dziennika później, klucz i hasło.  Inaczej
 # Potrzebne tylko klucz.

 ssh-keygen-t rsa

 # Skopiuj wygenerowany klucz do serwera

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

 # Teraz dostosować sshd_config na serwerze plik / etc / ssh /
 .
 .
 PasswordAuthentication nie
 .
 .

 # Następnie uruchom ponownie RearBBpos
 / Etc / init.d / ssh restart

Nawet tu trzeba uważać, aby nie odciąć nawet jeśli coś nie działa.
Klucz publiczny na USB z odpowiednim hasłem w głowie sprawia, że ​​znacznie trudniej złych facetów, aby uzyskać powłokę.

Trzeci SSH Bruteforcing zapobiec denyhosts

Jeśli rada nie jest praktyczne 2 i nie rezygnować z wygody hasło oparte loginy chcesz, możesz przynajmniej zapobiec zautomatyzowane stawki hasło napastników na serwerze. Wiele botów w internecie cały dzień chce zrobić nic więcej niż na serwery SSH i wypróbować w swoich różnych haseł. Hasłem rozsądnie bezpiecznym nie jest duży problem, ale nie ma lepszego uczucia, nawet jeśli to tylko możliwe. Poza tym chroni swoich użytkowników, czy są na serwerze i użytkownik konta. Tu nie można polegać na użytkownikach używać bezpiecznych haseł. denyhosts stale przeglądane i ssh logowanie na użytkownika blokuje na chwilę, którzy podali swoje hasło powtarzane. Adresów IP użytkowników chwilowo przejść do / etc / hosts.deny, tak że nie mają już dostęp do jest możliwe. To SSH Bruteforcing do zadania bardzo długie i nie bardzo obiecujące.

 apt-get install denyhosts

 Denyhosts Miejsce działa zaraz po instalacji.  To może być
 # W pliku / etc / denyhosts.conf dostrajać

4-ty Czarne listy służy do blokowania znanych adresów IP problem

W różne czarne listy internetowe są utrzymywane, co lista dużą liczbę serwerów karnych / posiekane / spamerski / oszustwa. Te IP listy mogą być wprowadzane bezpośrednio do zapory, tak że z tego znana jest nie do zaufanych komputerów nie może się połączyć w ogóle z własnym serwerze. Więc można zmniejszyć ilość spamu na własnym serwerze dramatycznie i jeden lub drugi dzieciak skrypt zablokować, ponieważ jego rosyjski pełnomocnik nagle przestaje działać. Jak zrobić, że byłem w innym artykule blogu opisane na przykładzie czarnej listy Infiltrated.net.

+5-sze Nie należy używać protokołu FTP do pracy na serwerze

FTP jest reliktem z lepszych czasach, gdy Internet był małą wioską nadal ufać. Wielu administratorów stron internetowych nadal korzystać z FTP do przesyłania plików na serwer lub do pracy na własnej stronie internetowej. Niestety, jest to bardzo niepewne, ponieważ FTP przesyła wszystkie dane zabezpieczone. Hasła i dane można odczytać bez żadnych problemów na każdym przeskoku między serwerami i klientami. Znacznie bezpieczniej jest iść z sshfs. Pozwala zamontować katalog przez SSH na zdalnym serwerze lokalnym systemie plików. Następnie można pracować na serwerze tak, jakby był na komputerze lokalnym. Wszystko dostęp do plików do plików na serwerze są całkowicie przejrzysty, dzięki czemu można otwierać w lokalnym programie graficznym do edycji obrazu bezpośrednio na serwerze, a następnie zapisać. Więcej komfortu i bezpieczeństwa bez większego wysiłku.

 # Instalacja sshfs
 apt-get install sshfs

 # Stwórz punkt montowania na lokalnym systemie plików
 mkdir / media / myserver

 # Server do lokalnego montażu systemu plików
 sshfs www-data@mein-server.de :/ var / www / media / myserver

 # Teraz katalogiem jest / var / www na moim lokalnym serwerze w / media / Mój_serwer dostępnych

6-gi Zainstaluj aktualizacje

Super bezpieczny system nie pomoże, jeśli sam system jest wadliwy i znany Luka może zostać wykorzystana. W większości przypadków te luki zamknięty szybko, ale często zapomina admin regularne aktualizacje systemu do podejmowania. Czy należy włączyć automatyczne aktualizacje na serwerach Linux, czy nie jest kwestią sporną. Niektórzy nigdy nie robić, bo to oczywiście z dużo pecha może być, że aktualizacje sprawiają, że system nadaje się do użytku. Stało się tak do mnie w ciągu 10 lat pracy w systemach Debiana, ale nigdy i doceniam zalety aktualizacjach terminowe i prawidłowe, dużo wyższe niż ryzyko wynikające.

 # Ta linia w / etc / crontab, aktualizacje zegara systemowego codziennie o 6 rano
 0 6 *** korzeń apt-get update && apt-get-y uaktualnienie

Są szybkie i brzydka metoda pracował dla mnie do tej pory zawsze dobrze. Niedawno przeczytałem, że w repozytorium Debiana i pakiet uaktualnień nienadzorowanej istnieje, że rozwiązuje problem prawdopodobnie bardziej elegancki, ale nie były testowane.

Nawet z tych aktualizacji vollautomtischen system nie jest całkowicie wyłączony z hakiem. Jeśli aktualizacja jądra została dostarczona, musisz uruchomić system ponownie ręcznie, w przeciwnym razie zmiany nie będą aktywne.

Jeśli użyjemy innej kodu PHP na serwerze, taki jak open source CMS lub forum, to oczywiście jest to absolutnie konieczne i to w nowych wersjach na bieżąco. Ponieważ Debian nie aktualizuje swoje zmiany do tych zastosowań w zakresie przepisów dotyczących tej pracy ręcznej jest wymagane. Najlepszym sposobem, aby przeczytać list adresowych z odpowiednich produktów, aby być zawsze na bieżąco.

+7-gi PHP za pomocą open_basedir uwięzić

Wiele hacki na podstawie faktu, że luka w kodzie PHP jest używane do dostępu do plików w dostępu do systemu plików, które nie należą do serwisu, ale sam system Dlatego należy zamknąć PHP tak, że tylko do odczytu w specjalnie wyznaczonych katalogów i zapisu dozwolone. Do tego php.ini opcja konfiguracja open_basedir. PHP ma możliwość umieścić tylko zezwolił na dostęp do katalogów tam. Pliki, takie jak / etc / passwd są poza zasięgiem. Obsługa wielu witryn na jednym serwerze należy ustawić open_basedir w każdej wirtualnej konfiguracji hosta z każdej strony.

 # Globalny php.ini przez:
 # / Etc/php5/apache2/php.ini
 open_basedir = / var / www / :/ tmp /

 # Dla każdej witryny w konfiguracji VirtualHost:
 php_value open_basedir / var / www / site / :/ tmp /

Ważne jest, aby rozważyć, czy wszystkie strony zostały dodane do skryptów zwykle muszą mieć dostęp, w przeciwnym wypadku może się okazać, że jesteś osobą niepełnosprawną i uzasadnione funkcje aplikacji PHP.

8-sza Tworzenie własnych stron internetowych dla użytkowników MySQL

Użyj własnego PHP-MySQL aplikacji, należy bezwzględnie stworzyć dla Apllikation własnym użytkownik MySQL iw żadnym wypadku nie używać wniosków MySQL użytkownika root. Należy również ograniczyć uprawnienia użytkownika tak daleko, że naprawdę tylko te działania są dozwolone, która wymaga skryptu PHP. CREATE TABLE i DROP TABLE są powszechne w iniekcji SQL i używany w większości aplikacji PHP nie potrzebuje. Znajduje się na niej wiele stron internetowych z wielu baz danych na serwerze, należy tworzyć własne bazy danych dla wszystkich użytkowników. Tak więc, po udanym ataku, atakujący ma dostęp tylko do jednej z baz danych, a nie bezpośrednio w ogóle. Jeśli nie chcesz spróbować z linii poleceń do zarządzania kontami użytkowników, MySQL użytkownika zarządzanie funkcjonuje również dość łatwo z phpMyAdmin w zakładce "praw".

9-ga Komunikaty o błędach PHP off

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-cia 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