Przewodnik dotyczący wzmacniania i zabezpieczania serwera WWW Apache

Praktyczny przewodnik po zabezpieczeniu i wzmocnieniu serwera HTTP Apache.

Serwer WWW to kluczowa część aplikacji internetowych. Apache Web Server jest często umieszczany na obrzeżach sieci, dlatego staje się jedną z najbardziej podatnych na ataki usług.

Posiadanie domyślnej konfiguracji dostarcza wielu poufnych informacji, które mogą pomóc hakerowi przygotować się do ataku na aplikacje. Większość ataków na aplikacje internetowe to ataki XSS, Info Leakage, Session Management i SQL Injection, które są spowodowane słabym kodem programistycznym i brakiem oczyszczenia infrastruktury aplikacji internetowych.

Interesujące badania przeprowadzone przez Positive Technologies pokazują, że 52% przeskanowanych aplikacji miało wysokie podatności.

W tym artykule omówię niektóre z najlepszych praktyk zabezpieczania serwera HTTP Apache na platformie Linux.

Poniższe są testowane na wersji Apache 2.4.x.

• Zakłada się, że zainstalowałeś Apache na platformie UNIX. Jeśli nie, możesz przejść do instrukcji instalacji.
• W tym przewodniku będę nazywał katalog instalacyjny Apache /opt/apache jako $Web_Server.
• Zaleca się wykonanie kopii zapasowej istniejącego pliku konfiguracyjnego przed jakąkolwiek modyfikacją.

Publiczność

Jest to przeznaczone dla administratora oprogramowania pośredniego, wsparcia aplikacji, analityka systemu lub każdego, kto pracuje lub chce poznać wytyczne dotyczące wzmacniania i bezpieczeństwa.

Wymagana jest dobra znajomość serwera Apache Web Server i polecenia UNIX.

Uwagi

Potrzebujesz narzędzia do badania nagłówków HTTP w celu weryfikacji implementacji. Można to zrobić na dwa sposoby.

1. Użyj wbudowanych w przeglądarkę narzędzi programistycznych, aby sprawdzić nagłówki HTTP. Zwykle znajduje się w zakładce Sieć
2. Użyj internetowego narzędzia do sprawdzania nagłówków odpowiedzi HTTP

Usuń baner wersji serwera

Powiedziałbym, że jest to jedna z pierwszych rzeczy do rozważenia, ponieważ nie chcesz ujawniać, jakiej wersji serwera WWW używasz. Ujawnianie wersji oznacza, że ​​pomagasz hakerowi przyspieszyć proces rozpoznania.

Domyślna konfiguracja ujawni wersję Apache i typ systemu operacyjnego, jak pokazano poniżej.

• Przejdź do folderu $Web_Server/conf
• Zmodyfikuj httpd.conf za pomocą edytora vi
• Dodaj następującą dyrektywę i zapisz httpd.conf

 ServerTokens Prod ServerSignature Off

• Uruchom ponownie Apache

ServerSignature usunie informacje o wersji ze strony wygenerowanej przez Apache.

ServerTokens zmieni nagłówek tylko na produkcyjny, tj. Apache

Jak widać poniżej, informacje o wersji i systemie operacyjnym zniknęły.

Wyłącz wyświetlanie katalogu w przeglądarce

Wyłącz wyświetlanie katalogów w przeglądarce, aby odwiedzający nie widział, jakie wszystkie pliki i foldery masz w katalogu głównym lub podkatalogu.

Sprawdźmy, jak to wygląda w ustawieniach domyślnych.

• Przejdź do katalogu $Web_Server/htdocs
• Utwórz folder i kilka plików w nim

 # mkdir test # touch hi # touch hello

Teraz spróbujmy uzyskać dostęp do Apache przez http://localhost/test

Jak widać, pokazuje, jakie masz wszystkie pliki/foldery i jestem pewien, że nie chcesz tego ujawniać.

• Przejdź do katalogu $Web_Server/conf
• Otwórz httpd.conf za pomocą vi
• Wyszukaj katalog i zmień dyrektywę Options na None lub –Indexes

 <Directory /opt/apache/htdocs> Options -Indexes </Directory>

(lub)

 <Directory /opt/apache/htdocs> Options None </Directory>

• Uruchom ponownie Apache

Uwaga : jeśli masz wiele dyrektyw Directory w swoim środowisku, powinieneś rozważyć zrobienie tego samego dla wszystkich.

Teraz spróbujmy uzyskać dostęp do Apache przez http://localhost/test

Jak widać, wyświetla zabroniony błąd zamiast pokazywać listę folderów testowych.

Etag

Umożliwia zdalnym atakującym uzyskanie poufnych informacji, takich jak numer węzła, wieloczęściowa granica MIME i proces potomny za pośrednictwem nagłówka Etag.

Aby zapobiec tej luce, zaimplementujmy ją jak poniżej. Jest to wymagane, aby naprawić zgodność z PCI.

• Przejdź do katalogu $Web_Server/conf
• Dodaj następującą dyrektywę i zapisz httpd.conf

 FileETag None

• Uruchom ponownie Apache

Uruchom Apache z konta nieuprzywilejowanego

Domyślna instalacja działa jako none lub demon. Korzystanie z oddzielnego nieuprzywilejowanego użytkownika dla Apache jest dobre.

Chodzi o to, aby chronić inne działające usługi w przypadku jakiejkolwiek luki w zabezpieczeniach.

• Utwórz użytkownika i grupę o nazwie Apache

 # groupadd apache # useradd –G apache apache

• Zmień własność katalogu instalacyjnego Apache na nowo utworzonego użytkownika bez uprawnień

 # chown –R apache:apache /opt/apache

• Przejdź do $Web_Server/conf
• Zmodyfikuj httpd.conf za pomocą vi
• Wyszukaj Dyrektywę użytkowników i grup i zmień jako Apache dla kont nieuprzywilejowanych

 User apache Group apache

• Zapisz httpd.conf
• Uruchom ponownie Apache

grep do uruchomienia procesu http i upewnij się, że działa z użytkownikiem Apache

 # ps –ef |grep http

Powinieneś zobaczyć, że jeden proces działa z rootem. Dzieje się tak, ponieważ Apache nasłuchuje na porcie 80 i musi być uruchomiony z rootem.

Chroń uprawnienia do katalogu plików binarnych i konfiguracji

Domyślnie uprawnienia do plików binarnych i konfiguracji to 755, co oznacza, że ​​każdy użytkownik na serwerze może przeglądać konfigurację. Możesz uniemożliwić innemu użytkownikowi dostęp do folderu conf i bin.

• Przejdź do katalogu $Web_Server
• Zmień uprawnienia folderu bin i conf

 # chmod –R 750 bin conf

Ochrona ustawień systemu

W domyślnej instalacji użytkownicy mogą nadpisać konfigurację Apache za pomocą .htaccess. Jeśli chcesz uniemożliwić użytkownikom zmianę ustawień serwera Apache, możesz dodać AllowOverride do None , jak pokazano poniżej.

Należy to zrobić na poziomie głównym.

• Przejdź do katalogu $Web_Server/conf
• Otwórz httpd.conf za pomocą vi
• Wyszukaj katalog na poziomie głównym

 <Directory /> Options -Indexes AllowOverride None </Directory>

• Zapisz httpd.conf
• Uruchom ponownie Apache

Metody żądania HTTP

Protokół HTTP 1.1 obsługuje wiele metod żądań, które mogą nie być wymagane, a niektóre z nich wiążą się z potencjalnym ryzykiem.

Zazwyczaj możesz potrzebować metod żądania GET, HEAD, POST w aplikacji internetowej, które można skonfigurować w odpowiedniej dyrektywie Directory.

Domyślna konfiguracja obsługuje metody OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, CONNECT w protokole HTTP 1.1.

• Przejdź do katalogu $Web_Server/conf
• Otwórz httpd.conf za pomocą vi
• Wyszukaj katalog i dodaj następujące

 <LimitExcept GET POST HEAD> deny from all </LimitExcept>

• Uruchom ponownie Apache

Wyłącz śledzenie żądania HTTP

Domyślnie metoda śledzenia jest włączona na serwerze WWW Apache.

Włączenie tej opcji może umożliwić atak Cross Site Tracing i potencjalnie dać hakerowi możliwość kradzieży informacji o plikach cookie. Zobaczmy jak to wygląda w domyślnej konfiguracji.

• Zrób adres IP serwera telnet z portem nasłuchiwania
• Złóż wniosek TRACE, jak pokazano poniżej

 #telnet localhost 80 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. TRACE / HTTP/1.1 Host: test HTTP/1.1 200 OK Date: Sat, 31 Aug 2013 02:13:24 GMT Server: Apache Transfer-Encoding: chunked Content-Type: message/http 20 TRACE / HTTP/1.1 Host: test 0 Connection closed by foreign host. #

Jak widać na powyższym żądaniu TRACE, odpowiedział on na moje zapytanie. Wyłączmy go i przetestujmy.

• Przejdź do katalogu $Web_Server/conf
• Dodaj następującą dyrektywę i zapisz httpd.conf

 TraceEnable off

• Uruchom ponownie Apache

Wykonaj IP serwera telnet z portem nasłuchu i wyślij żądanie TRACE , jak pokazano poniżej

 #telnet localhost 80 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. TRACE / HTTP/1.1 Host: test HTTP/1.1 405 Method Not Allowed Date: Sat, 31 Aug 2013 02:18:27 GMT Server: Apache Allow:Content-Length: 223Content-Type: text/html; charset=iso-8859-1 <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <html><head> <title>405 Method Not Allowed</title> </head><body> <h1>Method Not Allowed</h1> <p>The requested method TRACE is not allowed for the URL /.</p> </body></html> Connection closed by foreign host. #

Jak widać na powyższym żądaniu TRACE, moje żądanie zostało zablokowane za pomocą metody HTTP 405 niedozwolonej.

Teraz ten serwer WWW nie pozwala na żądania TRACE i pomoc w blokowaniu ataku Cross Site Tracing.

Ustaw plik cookie z HttpOnly i flagą Secure

Większość typowych ataków Cross Site Scripting można złagodzić za pomocą flagi HttpOnly i Secure w pliku cookie. Bez HttpOnly i Secure można ukraść lub manipulować sesją aplikacji internetowej i plikami cookie, co jest niebezpieczne.

• Upewnij się, że mod_headers.so jest włączony w twoim httpd.conf
• Przejdź do katalogu $Web_Server/conf
• Dodaj następującą dyrektywę i zapisz httpd.conf

 Header edit Set-Cookie ^(.*)$ $1;HttpOnly;Secure

• Uruchom ponownie Apache

Clickjacking Attack

Clickjacking to dobrze znana luka w zabezpieczeniach aplikacji internetowych.

• Upewnij się, że mod_headers.so jest włączony w twoim httpd.conf
• Przejdź do katalogu $Web_Server/conf
• Dodaj następującą dyrektywę i zapisz httpd.conf

 Header always append X-Frame-Options SAMEORIGIN

• Uruchom ponownie Apache

X-Frame-Options obsługuje również dwie dodatkowe opcje, które wyjaśniłem tutaj.

Uwzględnij po stronie serwera

Dołączanie po stronie serwera (SSI) wiąże się z ryzykiem zwiększenia obciążenia serwera. Jeśli współdzieliłeś środowisko i aplikacje internetowe o dużym natężeniu ruchu, powinieneś rozważyć wyłączenie SSI poprzez dodanie dyrektywy include in Options.

Atak SSI umożliwia wykorzystanie aplikacji internetowej poprzez wstrzykiwanie skryptów na stronach HTML lub zdalne wykonywanie kodów.

• Przejdź do katalogu $Web_Server/conf
• Otwórz httpd.conf za pomocą vi
• Wyszukaj katalog i dodaj Uwzględnij w dyrektywie Opcje

 <Directory /opt/apache/htdocs> Options –Indexes -Includes Order allow,denyAllow from all </Directory>

• Uruchom ponownie Apache

Uwaga: jeśli masz wiele dyrektyw Directory w swoim środowisku, powinieneś rozważyć zrobienie tego samego dla wszystkich.

Ochrona X-XSS

W wielu przeglądarkach można ominąć ochronę Cross Site Scripting (XSS). Możesz zastosować tę ochronę dla aplikacji internetowej, jeśli została wyłączona przez użytkownika. Jest to używane przez większość gigantycznych firm internetowych, takich jak Facebook, Twitter, Google itp.

• Przejdź do katalogu $Web_Server/conf
• Otwórz httpd.conf za pomocą vi i dodaj następującą dyrektywę Header

 Header set X-XSS-Protection "1; mode=block"

• Uruchom ponownie Apache

Jak widać, XSS-Protection jest wstrzykiwany w nagłówek odpowiedzi.

Wyłącz protokół HTTP 1.0

Kiedy mówimy o bezpieczeństwie, powinniśmy chronić tyle, ile możemy. Dlaczego więc używamy starszej wersji protokołu HTTP, wyłączmy je również?

HTTP 1.0 ma lukę w zabezpieczeniach związaną z przejmowaniem sesji. Możemy to wyłączyć za pomocą modułu mod_rewrite.

• Upewnij się, że ładujesz moduł mod_rewrite w pliku httpd.conf
• Włącz dyrektywę RewriteEngine jak poniżej i dodaj warunek Rewrite, aby zezwolić tylko na HTTP 1.1

 RewriteEngine On RewriteCond %{THE_REQUEST} !HTTP/1.1$ RewriteRule .* - [F]

Konfiguracja wartości limitu czasu

Domyślnie wartość limitu czasu Apache wynosi 300 sekund, co może paść ofiarą ataku Slow Loris i DoS. Aby to złagodzić, możesz obniżyć wartość limitu czasu do może 60 sekund.

• Przejdź do katalogu $Web_Server/conf
• Otwórz httpd.conf za pomocą vi
• Dodaj następujące elementy w httpd.conf

 Timeout 60

SSL

Posiadanie SSL to dodatkowa warstwa bezpieczeństwa, którą dodajesz do aplikacji internetowej. Jednak domyślna konfiguracja SSL prowadzi do pewnych luk w zabezpieczeniach i należy rozważyć modyfikację tych konfiguracji.

Klucz SSL

Naruszenie klucza SSL jest trudne, ale nie niemożliwe. To tylko kwestia mocy obliczeniowej i czasu.

Jak zapewne wiesz, używając komputera z ery 2009, który pęka przez około 73 dni, możesz odtworzyć 512-bitowy klucz.

Więc im większa długość klucza, tym bardziej skomplikowane staje się złamanie klucza SSL. Większość gigantycznych firm internetowych używa klucza 2048-bitowego, jak poniżej, dlaczego więc tego nie zrobimy?

• Outlook.com
• Microsoft.com
• Live.com
• Skype.com
• Apple.com
• Yahoo.com
• Bing.com
• Hotmail.com
• Twitter.com

Możesz użyć OpenSSL do wygenerowania CSR z 2048 bitami, jak poniżej.

 openssl req -out geekflare.csr -newkey rsa:2048 -nodes -keyout geekflare.key

Wygeneruje CSR, który będziesz musiał wysłać do urzędu certyfikacji, aby go podpisać. Po otrzymaniu podpisanego pliku certyfikatu możesz dodać je w pliku httpd-ssl.conf

 SSLCertificateFile #Certificate signed by authority SSLCertificateChainFile #Certificate signer given by authority SSLCertificateKeyFile #Key file which you generated above

• Uruchom ponownie serwer WWW Apache i spróbuj uzyskać dostęp do adresu URL za pomocą https

Szyfr SSL

SSL Cipher to algorytm szyfrowania, który jest używany jako klucz między dwoma komputerami w Internecie. Szyfrowanie danych to proces przekształcania zwykłego tekstu w tajne zaszyfrowane kody.

W oparciu o konfigurację SSL Cipher serwera WWW szyfrowanie danych będzie miało miejsce. Dlatego ważne jest, aby skonfigurować szyfr SSL, który jest silniejszy i nie jest podatny na ataki.

• Przejdź do folderu $Web_Server/conf/extra
• Zmodyfikuj dyrektywę SSLCipherSuite w httpd-ssl.conf jak poniżej, aby zaakceptować tylko wyższe algorytmy szyfrowania

 SSLCipherSuite HIGH:!MEDIUM:!aNULL:!MD5:!RC4

• Zapisz plik konfiguracyjny i zrestartuj serwer Apache

Uwaga: jeśli w raporcie z audytu SSL masz wiele słabych szyfrów, możesz je szybko odrzucić, dodając ! na początku.

Wyłącz SSL v2 i v3

SSL v2 i v3 mają wiele luk w zabezpieczeniach, a jeśli pracujesz nad testami penetracyjnymi lub zgodnością z PCI, oczekuje się, że zamkniesz wykrywanie zabezpieczeń, aby wyłączyć SSL v2/v3.

Każda komunikacja SSL v2/v3 może być podatna na atak Man-in-The-Middle, który może umożliwić manipulację lub ujawnienie danych.

Zaimplementujmy serwer WWW Apache, aby akceptował tylko najnowsze TLS i odrzucał żądania połączenia SSL v2/v3.

• Przejdź do folderu $Web_Server/conf/extra
• Zmodyfikuj dyrektywę SSLProtocol w httpd-ssl.conf jak poniżej, aby akceptować tylko TLS 1.2+

 SSLProtocol –ALL +TLSv1.2

Po zakończeniu konfiguracji SSL dobrym pomysłem jest przetestowanie aplikacji internetowej za pomocą narzędzia online SSL/TLS Certificate, aby znaleźć wszelkie błędy konfiguracji.

Bezpieczeństwo modów

Mod Security to zapora aplikacji internetowych typu open source, której można używać z Apache.

Jest dostępny jako moduł, który musisz skompilować i zainstalować. Jeśli nie stać Cię na komercyjną zaporę sieciową dla aplikacji internetowych, będzie to doskonały wybór.

Aby zapewnić ogólną ochronę aplikacji internetowych, Zasady podstawowe wykorzystują następujące techniki:

• Ochrona HTTP – wykrywanie naruszeń protokołu HTTP i lokalnie zdefiniowanej polityki użytkowania
• Wyszukiwanie w czasie rzeczywistym na czarnej liście – wykorzystuje reputację IP innej firmy
• Wykrywanie złośliwego oprogramowania opartego na sieci Web — identyfikuje złośliwe treści internetowe, sprawdzając je w interfejsie Google Safe Browsing API.
• Zabezpieczenia HTTP Denial of Service – ochrona przed HTTP Flooding i powolnymi atakami HTTP DoS.
• Ochrona przed powszechnymi atakami internetowymi – wykrywanie typowych ataków na zabezpieczenia aplikacji internetowych
• Wykrywanie automatyzacji — wykrywanie botów, robotów indeksujących, skanerów i innej złośliwej aktywności na powierzchni
• Integracja ze skanowaniem antywirusowym w celu przesłania plików — identyfikuje złośliwe pliki przesyłane za pośrednictwem aplikacji internetowej.
• Śledzenie wrażliwych danych – śledzi użycie karty kredytowej i blokuje wycieki.
• Ochrona przed trojanami — wykrywanie dostępu do koni trojańskich.
• Identyfikacja defektów aplikacji – alerty o błędnych konfiguracjach aplikacji.
• Wykrywanie i ukrywanie błędów — ukrywanie komunikatów o błędach wysyłanych przez serwer.

Pobieranie i instalacja

Na serwerze, na którym chcesz używać Mod Security z Apache, muszą być zainstalowane następujące wymagania wstępne. Jeśli którykolwiek z nich nie istnieje, kompilacja Mod Security nie powiedzie się. Możesz użyć yum install na Linuksie lub Centos, aby zainstalować te pakiety.

• Apache 2.x lub nowszy
• pakiet libpcre
• pakiet libxml2
• pakiet libula
• pakiet libcurl
• pakiet libapr i libapr-util
• moduł mod_unique_id dołączony do serwera WWW Apache

Teraz pobierzmy najnowszą stabilną wersję Mod Security 2.7.5 stąd

• Przenieś pobrany plik do /opt/apache
• Rozpakuj modsecurity-apache_2.7.5.tar.gz

 # gunzip –c modsecurity-apache_2.7.5.tar.gz | tar xvf –

• Przejdź do wyodrębnionego folderu modsecurity-apache_2.7.5

 # cd modsecurity-apache_2.7.5

• Uruchom skrypt konfiguracyjny zawierający ścieżkę apxs do istniejącego Apache

 # ./configure –with-apxs=/opt/apache/bin/apxs

• Skompiluj i zainstaluj za pomocą skryptu make

 # make # make install

• Po zakończeniu instalacji zobaczysz mod_security2.so w folderze modułów w /opt/apache

Na tym kończy się, że zainstalowałeś moduł Mod Security na istniejącym serwerze WWW Apache.

Konfiguracja

Aby korzystać z funkcji bezpieczeństwa Mod z Apache, musimy załadować moduł bezpieczeństwa mod w httpd.conf. Moduł mod_unique_id jest warunkiem wstępnym dla Mod Security.

Ten moduł zapewnia zmienną środowiskową z unikalnym identyfikatorem dla każdego żądania, która jest śledzona i używana przez Mod Security.

• Dodaj następujący wiersz, aby załadować moduł dla Mod Security w httpd.conf i zapisać plik konfiguracyjny

 LoadModule unique_id_module modules/mod_unique_id.so LoadModule security2_module modules/mod_security2.so

• Zrestartuj serwer WWW Apache

Mod Security jest teraz zainstalowany!

Następną rzeczą, którą musisz zrobić, to zainstalować podstawową regułę Mod Security, aby w pełni wykorzystać jej funkcję.

Najnowszą regułę podstawową można pobrać, klikając łącze, które jest bezpłatne. https://github.com/SpiderLabs/owasp-modsecurity-crs/zipball/master

• Skopiuj pobrany plik zip reguły podstawowej do folderu /opt/apache/conf
• Rozpakuj plik zasad podstawowych
• Możesz zmienić nazwę folderu na krótką i łatwą do zapamiętania. W tym przykładzie zmienię nazwę na crs.
• Przejdź do folderu crs i zmień nazwę modsecurity_crs10_setup.conf.example na modsecurity_crs10_setup.conf

Teraz włączmy te reguły, aby działały z serwerem WWW Apache.

• Dodaj następujące elementy w httpd.conf

 <IfModule security2_module> Include conf/crs/modsecurity_crs_10_setup.confInclude conf/crs/base_rules/*.conf </IfModule>

W powyższej konfiguracji ładujemy główny plik konfiguracyjny Mod Security modsecurity_crs_10_setup.conf oraz podstawowe reguły base_rules/*.conf dostarczone przez Mod Security Core Rules w celu ochrony aplikacji internetowych.

• Zrestartuj serwer WWW Apache

Pomyślnie skonfigurowałeś Mod Security z Apache!

Bardzo dobrze. Teraz serwer WWW Apache jest chroniony przez zaporę sieciową aplikacji sieciowej Mod Security.

Pierwsze kroki

Zacznijmy od niektórych krytycznych konfiguracji w Mod Security, aby wzmocnić i zabezpieczyć aplikacje internetowe.

W tej sekcji dokonamy wszystkich modyfikacji konfiguracji w /opt/apache/conf/crs/modsecurity_crs_10_setup.conf.

Jako przykład w tej sekcji będziemy odnosić się do /opt/apache/conf/crs/modsecurity_crs_10_setup.conf jako setup.conf.

Ważne jest, aby zrozumieć, jakie reguły OWASP są udostępniane za darmo. OWASP udostępnia dwa rodzaje reguł.

Zasady podstawowe – te zasady są mocno przetestowane i prawdopodobnie współczynnik fałszywych alarmów jest mniejszy.

Reguły eksperymentalne – te reguły służą do celów eksperymentalnych i możesz mieć wysoki fałszywy alarm. Ważne jest, aby skonfigurować, przetestować i wdrożyć w UAT przed użyciem ich w środowisku produkcyjnym.

Reguły opcjonalne — te reguły opcjonalne mogą nie być odpowiednie dla całego środowiska. W zależności od wymagań możesz ich używać.

Jeśli szukasz ochrony CSRF, śledzenia użytkowników, przechwytywania sesji itp., możesz rozważyć użycie opcjonalnych reguł. Mamy podstawowe, opcjonalne i eksperymentalne reguły po rozpakowaniu ściągniętego pliku crs zip ze strony pobierania OWASP.

Ten plik konfiguracyjny reguł jest dostępny w folderze crs/base_rules, crs/optional_rules i crs/experimental_rules. Zapoznajmy się z niektórymi podstawowymi zasadami.

• modsecurity_crs_20_protocol_violations.conf: Ta reguła chroni przed lukami w protokole, takimi jak dzielenie odpowiedzi, przemyt żądań, używanie niedozwolonego protokołu (HTTP 1.0).
• modsecurity_crs_21_protocol_anomalies.conf: Ma to na celu ochronę przed żądaniem, którego brakuje w nagłówku Host, Accept, User-Agent.
• modsecurity_crs_23_request_limits.conf: Ta reguła zależy od konkretnej aplikacji, takiej jak rozmiar żądania, rozmiar przesyłanego pliku, długość parametru itp.
• modsecurity_crs_30_http_policy.conf:Służy do konfigurowania i ochrony dozwolonych lub niedozwolonych metod, takich jak CONNECT, TRACE, PUT, DELETE itp.
• modsecurity_crs_35_bad_robots.conf:Wykryj złośliwe roboty
• modsecurity_crs_40_generic_attacks.conf: Ma to na celu ochronę przed wstrzyknięciem poleceń systemu operacyjnego, zdalnym włączeniem plików itp.
• modsecurity_crs_41_sql_injection_attacks.conf: Ta reguła chroni SQL i ślepe żądania SQL inject.
• modsecurity_crs_41_xss_attacks.conf:Ochrona przed żądaniem Cross-Site Scripting.
• modsecurity_crs_42_tight_security.conf:Wykrywanie i ochrona przechodzenia przez katalogi.
• modsecurity_crs_45_trojans.conf: Ta reguła do wykrywania ogólnych danych wyjściowych zarządzania plikami, przesyłania strony backdoora HTTP, znanej sygnatury.
• modsecurity_crs_47_common_exceptions.conf:Jest to używane jako mechanizm wyjątków do usuwania powszechnych fałszywych alarmów, które można napotkać jako kiepskie połączenie wewnętrzne Apache, pinger SSL itp.

Logowanie

Rejestrowanie jest jedną z pierwszych rzeczy, które należy skonfigurować, dzięki czemu można utworzyć dzienniki dotyczące tego, co robi Mod Security. Dostępne są dwa rodzaje logowania; Dziennik debugowania i audytu.

Dziennik debugowania: ma to na celu zduplikowanie błędu Apache, ostrzeżeń i komunikatów informacyjnych z dziennika błędów.

Dziennik audytu: służy do zapisywania dzienników transakcji, które są oznaczone regułą Mod Security Mod Security zapewnia elastyczność w konfiguracji rejestrowania audytu, debugowania lub obu.

Domyślnie konfiguracja zapisze oba logi. Możesz jednak zmienić w zależności od swoich wymagań. Dziennik jest kontrolowany w dyrektywie SecDefaultAction . Spójrzmy na domyślną konfigurację logowania w setup.conf

 SecDefaultAction “phase:1,deny,log”

Aby zalogować Debug, Audit log – użyj „log” Aby zalogować tylko dziennik audytu – użyj „nolog,auditlog” Aby zalogować tylko dziennik debugowania – użyj „log,noauditlog” Możesz określić lokalizację dziennika audytu, która ma być przechowywana, kontrolowana przez SecAuditLog dyrektywa.

Zapiszmy dziennik audytu w /opt/apache/logs/modsec_audit.log, dodając jak pokazano poniżej.

• Dodaj dyrektywę SecAuditLog w setup.conf i zrestartuj serwer Apache Web Server

 SecAuditLog /opt/apache/logs/modsec_audit.log

• Po ponownym uruchomieniu powinieneś zobaczyć wygenerowanie modsec_audit.log

Włącz mechanizm reguł

Domyślnie reguła silnika jest wyłączona, co oznacza, że ​​jeśli nie włączysz silnika reguł, nie wykorzystujesz wszystkich zalet Mod Security.

Włączanie lub wyłączanie Rule Engine jest kontrolowane przez dyrektywę SecRuleEngine .

• Dodaj dyrektywę SecRuleEngine w setup.conf i zrestartuj serwer Apache Web Server

 SecRuleEngine On

SecRuleEngine ma trzy wartości:

• On – aby włączyć Rule Engine
• Off – aby wyłączyć Rule Engine
• DetectionOnly – włącz Rule Engine, ale nigdy nie wykonuje żadnych akcji, takich jak blokowanie, odrzucanie, upuszczanie, zezwalanie, proxy lub przekierowanie

Po uruchomieniu Rule Engine – Mod Security jest gotowy do ochrony za pomocą niektórych popularnych typów ataków.

Wspólna ochrona przed typami ataków

Teraz serwer WWW jest gotowy do ochrony za pomocą popularnych typów ataków, takich jak XSS, SQL Injection, Protocol Violation, itp., ponieważ zainstalowaliśmy Core Rule i włączyliśmy Rule Engine. Przetestujmy kilka z nich.

Atak XSS

• Otwórz Firefoksa i uzyskaj dostęp do swojej aplikacji i umieść tag <script> na końcu lub adres URL
• Monitoruj modsec_audit.log w folderze apache/logs

Zauważysz, że Mod Security blokuje żądanie, ponieważ zawiera tag <script>, który jest źródłem ataku XSS.

Atak Directory Traversal: - Ataki Directory Traversal mogą spowodować wiele szkód, wykorzystując te luki i uzyskując dostęp do pliku związanego z systemem. Np. – /etc/passwd, .htaccess itp.

• Otwórz Firefoksa i uzyskaj dostęp do swojej aplikacji za pomocą przechodzenia katalogów
• Monitoruj modsec_audit.log w folderze apache/logs

 http://localhost/?../.../boot

• Zauważysz, że Mod Security blokuje żądanie, ponieważ zawiera przechodzenie przez katalog.

Zmień baner serwera

Wcześniej w tym przewodniku dowiedziałeś się, jak usunąć Apache i typ systemu operacyjnego, pomoc w wersji dyrektywy ServerTokens.

Pójdźmy o krok do przodu, co powiesz na zachowanie dowolnej nazwy serwera? Jest to możliwe dzięki dyrektywie SecServerSignature w Mod Security. Widzisz, to interesujące.

Uwaga: aby użyć Mod Security do manipulowania banerem serwera z nagłówka, musisz ustawić ServerTokesn na Full w httpd.conf serwera WWW Apache.

• Dodaj dyrektywę SecServerSignature z wybraną nazwą serwera w pliku setup.conf i zrestartuj serwer Apache Web Server

 SecServerSignature YourServerName

Były:

 [/opt/apache/conf/crs] #grep SecServer modsecurity_crs_10_setup.conf SecServerSignature geekflare.com [/opt/apache/conf/crs] #

Konfiguracja ogólna

Przyjrzyjmy się niektórym z ogólnych konfiguracji jako najlepszych praktyk.

Skonfiguruj słuchanie

Gdy masz wiele interfejsów i adresów IP na jednym serwerze, zaleca się skonfigurowanie dyrektywy Listen z bezwzględnym adresem IP i numerem portu.

Gdy zostawisz konfigurację Apache na Listen na wszystkich IP z jakimś numerem portu, może to spowodować problem z przekazywaniem żądania HTTP do innego serwera WWW. Jest to dość powszechne we wspólnym środowisku.

• Skonfiguruj dyrektywę Listen w httpd.conf z bezwzględnym adresem IP i portem, jak pokazano poniżej

 Listen 10.10.10.1:80

Logowanie dostępu

Niezbędne jest prawidłowe skonfigurowanie dziennika dostępu na serwerze WWW. Jednym z ważnych parametrów do przechwycenia w dzienniku jest czas obsługi żądania, identyfikator sesji.

Domyślnie Apache nie jest skonfigurowany do przechwytywania tych danych. Musisz skonfigurować je ręcznie w następujący sposób.

• Aby uchwycić czas potrzebny na obsłużenie żądania i identyfikatora sesji w dzienniku dostępu
• Dodaj %T i %sessionID w httpd.conf zgodnie z dyrektywą LogFormat

 LogFormat "%h %l %u %t "%{sessionID}C" "%r" %>s %b %T" common

Możesz odwiedzić http://httpd.apache.org/docs/2.2/mod/mod_log_config.html po pełną listę parametrów obsługiwanych przez dyrektywę LogFormat w Apache Web Server.

Wyłącz ładowanie niechcianych modułów

Jeśli skompilowałeś i zainstalowałeś wszystkie moduły, istnieje duże prawdopodobieństwo, że w Apache będzie załadowanych wiele modułów, które mogą nie być wymagane.

Najlepszą praktyką jest skonfigurowanie Apache z wymaganymi modułami w aplikacjach internetowych. Następujące moduły mają problemy z bezpieczeństwem i możesz być zainteresowany wyłączeniem w httpd.conf serwera Apache Web Server.

WebDAV (Web-based Distributed Authoring and Versioning) Ten moduł umożliwia zdalnym klientom manipulowanie plikami na serwerze i poddawanie się różnym atakom typu „odmowa usługi”. Aby wyłączyć obserwowanie komentarzy w httpd.conf

 #LoadModule dav_module modules/mod_dav.so #LoadModule dav_fs_module modules/mod_dav_fs.so #Include conf/extra/httpd-dav.conf

Moduł Info Moduł mod_info może ujawnić poufne informacje za pomocą .htaccess po załadowaniu tego modułu. Aby wyłączyć obserwowanie komentarzy w httpd.conf

 #LoadModule info_module modules/mod_info.so

Odniesienie: Nie byłoby to możliwe bez wskazówek z następującego linku:

• http://httpd.apache.org/docs/2.4/
• http://www.modsecurity.org/documentation/
• https://www.owasp.org/index.php/Category:OWASP_ModSecurity_Core_Rule_Set_Project

To były niektóre z najlepszych praktyk, których możesz użyć do zabezpieczenia serwera WWW Apache.

Sprawdź ten link, jeśli chcesz zaimplementować niestandardową stronę błędu w Apache.

Jeśli jesteś nowy w Apache HTTP, polecam wzięcie udziału w kursie administrowania Apache HTTP.