Wyszukiwanie w witrynie

Kompletny przewodnik po zabezpieczeniu, wzmocnieniu i poprawie wydajności serwera internetowego Nginx


Bazując na wspaniałych rzeczach, które słyszałeś o Nginx, być może zdecydowałeś się spróbować. Być może spodobało Ci się to tak bardzo, że rozważasz wymianę instalacji Apache na Nginx po przejrzeniu niektórych artykułów na ten temat, które opublikowaliśmy na tej stronie.

Jeśli tak, jestem pewien, że przyjmiesz ten przewodnik z otwartymi ramionami, ponieważ omówimy 12 wskazówek, jak zwiększyć bezpieczeństwo Twoich serwerów Nginx (od aktualizowania Nginx aż do używając TLS i przekierowując HTTP na HTTPS), a zauważysz, że niektóre z nich są bardzo podobne do tego, co zrobiłbyś z Apache.

Nie przegap:

13 wskazówek dotyczących bezpieczeństwa i wzmacniania serwera WWW Apache

25 sztuczek Apache Htaccess pozwalających zabezpieczyć serwer WWW Apache

Środowisko testowe Nginx

W tym przewodniku będziemy używać następującego środowiska:

  1. Debian GNU/Linux 8.1 (jessie).
  2. Adres IP: 192.168.0.25 (tecmintlovesnginx.com) i 192.168.0.26 (nginxmeanspower.com), zgodnie z opisem w wirtualnym rozwiązaniu opartym na IP sekcja gospodarzy pod adresem

    1. „Jak skonfigurować wirtualne hosty oparte na nazwach i IP (bloki serwerów) za pomocą Nginx”
  3. Wersja Nginx: nginx/1.6.2.
  4. Dla Twojej wygody, oto ostateczny plik konfiguracyjny (link Pastebin).

Mając to na uwadze, zacznijmy.

WSKAZÓWKA nr 1: Aktualizuj Nginx

W chwili pisania tego tekstu najnowsze wersje Nginx w CentOS (w EPEL) i repozytoriach Debiana to 1.6.3 i 1.6.2-5, odpowiednio.

Nie przegap: zainstaluj najnowszą stabilną wersję Nginx z repozytoriów i źródeł

Choć instalacja oprogramowania z repozytoriów jest łatwiejsza niż kompilacja programu z kodu źródłowego, ta ostatnia opcja ma dwie zalety: 1) pozwala na wbudowanie w Nginx dodatkowych modułów (takich jak mod_security), oraz 2) zawsze udostępni nowszą wersję niż repozytoria (1.9.9 na dzień dzisiejszy). Informacje o wydaniu są zawsze dostępne na stronie internetowej Nginx.

Nie przegap:

Chroń Apache przed atakami Brute Force i DDoS za pomocą Mod_Security i Mod_Evasive

WSKAZÓWKA nr 2: Usuń niepotrzebne moduły w Nginx

Aby jawnie usunąć moduły z Nginx podczas instalacji ze źródła, wykonaj:

./configure --without-module1 --without-module2 --without-module3

Na przykład:

./configure  --without-http_dav_module --withouthttp_spdy_module 

Jak zapewne się domyślasz, usunięcie modułów z poprzedniej instalacji Nginx ze źródła wymaga ponownego wykonania kompilacji.

Uwaga: dyrektywy konfiguracyjne są dostarczane przez moduły. Upewnij się, że nie wyłączyłeś modułu zawierającego dyrektywę, której będziesz potrzebować w przyszłości! Powinieneś sprawdzić dokumentację nginx pod kątem listy dyrektyw dostępnych w każdym module przed podjęciem decyzji o wyłączeniu modułów.

WSKAZÓWKA nr 3: Wyłącz dyrektywę server_tokens w Nginx

Dyrektywa server_tokens mówi Nginxowi, aby wyświetlał swoją aktualną wersję na stronach błędów. Nie jest to pożądane, ponieważ nie chcesz udostępniać tych informacji całemu światu, aby zapobiec atakom na Twój serwer WWW spowodowanym znanymi lukami w zabezpieczeniach tej konkretnej wersji.

Aby wyłączyć dyrektywę server_tokens, ustaw opcję if na wyłączoną w bloku serwera:

server {
    listen       192.168.0.25:80;
    server_tokens        off;
    server_name  tecmintlovesnginx.com www.tecmintlovesnginx.com;
    access_log  /var/www/logs/tecmintlovesnginx.access.log;
    error_log  /var/www/logs/tecmintlovesnginx.error.log error;
        root   /var/www/tecmintlovesnginx.com/public_html;
        index  index.html index.htm;
}

Uruchom ponownie Nginx i sprawdź zmiany:

WSKAZÓWKA nr 4: Odmawiaj agentom użytkownika HTTP w Nginx

Klient użytkownika HTTP to oprogramowanie używane do negocjacji treści z serwerem internetowym. Dotyczy to również botów i robotów indeksujących złośliwe oprogramowanie, które mogą mieć wpływ na wydajność serwera internetowego poprzez marnowanie zasobów systemowych.

Aby łatwiej zarządzać listą niepożądanych programów użytkownika, utwórz plik (na przykład /etc/nginx/blockuseragents.rules) o następującej zawartości:

map $http_user_agent $blockedagent {
        default         0;
        ~*malicious     1;
        ~*bot           1;
        ~*backdoor      1;
        ~*crawler       1;
        ~*bandit        1;
}

Następnie umieść następujący wiersz przed definicją bloku serwera:

include /etc/nginx/blockuseragents.rules;

Oraz instrukcja if zwracająca odpowiedź 403, jeśli ciąg agenta użytkownika znajduje się na czarnej liście zdefiniowanej powyżej:

Uruchom ponownie Nginx, a wszystkie programy użytkownika, których ciąg znaków pasuje do powyższego, zostaną zablokowane przed dostępem do Twojego serwera WWW. Zastąp 192.168.0.25 adresem IP swojego serwera i możesz wybrać inny ciąg dla przełącznika -user-agent w wget:

wget http://192.168.0.25/index.html
wget --user-agent "I am a bandit haha" http://192.168.0.25/index.html 

WSKAZÓWKA nr 5: Wyłącz niechciane metody HTTP w Nginx

Metody HTTP, zwane także czasownikami, wskazują żądaną akcję, jaką należy podjąć na zasobie obsługiwanym przez Nginx. W przypadku popularnych witryn internetowych i aplikacji należy zezwolić tylko na GET, POST i HEAD, a wszystkie pozostałe wyłączyć.

Aby to zrobić, umieść następujące wiersze w bloku serwera. Odpowiedź HTTP 444 oznacza pustą odpowiedź i jest często używana w Nginx do oszukiwania ataków złośliwego oprogramowania:

if ($request_method !~ ^(GET|HEAD|POST)$) {
   return 444;
}

Aby przetestować, użyj curl, aby wysłać żądanie DELETE i porównać wynik z wysyłaniem zwykłego GET:

curl -X DELETE http://192.168.0.25/index.html
curl -X POST http://192.168.0.25/index.html 

WSKAZÓWKA #6: Ustaw ograniczenia rozmiaru bufora w Nginx

Aby zapobiec atakom związanym z przepełnieniem bufora na serwer WWW Nginx, ustaw następujące dyrektywy w osobnym pliku (na przykład utwórz nowy plik o nazwie /etc/nginx/conf.d/buffer.conf):

client_body_buffer_size  1k;
client_header_buffer_size 1k;
client_max_body_size 1k;
large_client_header_buffers 2 1k;

Powyższe dyrektywy zapewnią, że żądania kierowane do Twojego serwera WWW nie spowodują przepełnienia bufora w Twoim systemie. Jeszcze raz zapoznaj się z dokumentacją, aby uzyskać więcej informacji na temat działania każdego z nich.

Następnie dodaj dyrektywę dołączania do pliku konfiguracyjnego:

include /etc/nginx/conf.d/*.conf;

WSKAZÓWKA #7: Ogranicz liczbę połączeń według adresu IP w Nginx

Aby ograniczyć połączenia według adresu IP, użyj dyrektyw limit_conn_zone (w kontekście http lub przynajmniej poza blokiem serwera) i limit_conn (w kontekście http, bloku serwera lub lokalizacji).

Należy jednak pamiętać, że nie wszystkie połączenia są liczone – a jedynie te, których żądanie zostało przetworzone przez serwer i został odczytany cały jego nagłówek żądania.

Na przykład ustawmy maksymalną liczbę połączeń na 1 (tak, to przesada, ale w tym przypadku zrobi to dobrze) w strefie o nazwie adres (możesz ustawić to na dowolną wartość imię, jakie chcesz):

limit_conn_zone $binary_remote_addr zone=addr:5m;
limit_conn addr 1;

Prosty test z Apache Benchmark (Perform Nginx Load), w którym nawiązano łącznie 10 połączeń przy 2 równoczesnych żądaniach, pomoże nam wykazać, co mamy na myśli:

ab -n 10 -c 2 http://192.168.0.25/index.html

Dalsze szczegóły znajdziesz w następnej wskazówce.

WSKAZÓWKA nr 8: Skonfiguruj dzienniki monitora dla Nginx

Po wykonaniu testu opisanego w poprzedniej wskazówce sprawdź dziennik błędów zdefiniowany dla bloku serwera:

Możesz użyć grep do filtrowania dzienników nieudanych żądań wysłanych do strefy addr zdefiniowanej w WSKAZÓWCE nr 7:

grep addr /var/www/logs/tecmintlovesnginx.error.log --color=auto

Podobnie możesz filtrować dziennik dostępu pod kątem interesujących Cię informacji, takich jak:

  1. IP klienta
  2. Typ przeglądarki
  3. Typ żądania HTTP
  4. Zażądano zasobu
  5. Blok serwera odpowiadający na żądanie (przydatne, jeśli do tego samego pliku loguje się kilka wirtualnych hostów).

Podejmij odpowiednie działania, jeśli wykryjesz jakąkolwiek nietypową lub niepożądaną aktywność.

WSKAZÓWKA nr 9: Zapobiegaj hotlinkowaniu obrazów w Nginx

Hotlinkowanie obrazów ma miejsce, gdy dana osoba wyświetla w innej witrynie obraz umieszczony na Twoim serwerze. Powoduje to zwiększenie wykorzystania Twojego pasma (za co płacisz), podczas gdy druga osoba z radością wyświetla obraz tak, jakby był jej własnością. Innymi słowy, jest to dla Ciebie podwójna strata.

Załóżmy na przykład, że masz podkatalog o nazwie img w bloku serwera, w którym przechowujesz wszystkie obrazy używane na tym wirtualnym hoście. Aby uniemożliwić innym witrynom korzystanie z Twoich obrazów, musisz wstawić następujący blok lokalizacji do definicji hosta wirtualnego:

location /img/ {
  valid_referers none blocked 192.168.0.25;
   if ($invalid_referer) {
     return   403;
   }
}

Następnie zmodyfikuj plik index.html na każdym hoście wirtualnym w następujący sposób:

192.168.0.26 192.168.0.25
<!DOCTYPE html>
<html>
<head>
<meta charset=”utf-8″>
<title>Nginx means power</title>
</head>
<body>
<h1>Nginx means power!</h1>
<img src=”http://192.168.0.25/img/nginx.png” />
</body>
</html>
<!DOCTYPE html>
<html>
<head>
<meta charset=”utf-8″>
<title>Tecmint loves Nginx</title>
</head>
<body>
<h1>Tecmint loves Nginx!</h1>
<img src=”img/nginx.png” />
</body>
</html>

Teraz przejdź do każdej witryny i jak widzisz, obraz jest poprawnie wyświetlany w 192.168.0.25, ale zostaje zastąpiony odpowiedzią 403 w 192.168.0.26 mocny>:

Pamiętaj, że ta wskazówka zależy od tego, czy zdalna przeglądarka wysyła pole Referer.

WSKAZÓWKA #10: Wyłącz SSL i włącz TLS tylko w Nginx

Jeśli to możliwe, zrób wszystko, aby uniknąć SSL w którejkolwiek z jego wersji i zamiast tego używaj TLS. Poniższe ssl_protocols należy umieścić w kontekście serwera lub http w pliku hosta wirtualnego lub stanowić oddzielny plik zgodnie z dyrektywą dołączania (niektóre osoby używają pliku o nazwie ssl.conf , ale to zależy wyłącznie od Ciebie):

ssl_protocols       TLSv1 TLSv1.1 TLSv1.2;

Na przykład:

WSKAZÓWKA #11: Utwórz certyfikaty w Nginx

Najpierw wygeneruj klucz i certyfikat. Jeśli chcesz, możesz użyć innego rodzaju szyfrowania:

openssl genrsa -aes256 -out tecmintlovesnginx.key 1024
openssl req -new -key tecmintlovesnginx.key -out tecmintlovesnginx.csr
cp tecmintlovesnginx.key tecmintlovesnginx.key.org
openssl rsa -in tecmintlovesnginx.key.org -out tecmintlovesnginx.key
openssl x509 -req -days 365 -in tecmintlovesnginx.csr -signkey tecmintlovesnginx.key -out tecmintlovesnginx.crt

Następnie dodaj następujące wiersze w oddzielnym bloku serwera, przygotowując się na następną wskazówkę (przekierowanie http --> https) i przenieś również dyrektywy związane z SSL do nowego bloku:

server {
    listen 192.168.0.25:443 ssl;
    server_tokens off;
    server_name  tecmintlovesnginx.com www.tecmintlovesnginx.com;
    root   /var/www/tecmintlovesnginx.com/public_html;
    ssl_certificate /etc/nginx/sites-enabled/certs/tecmintlovesnginx.crt;
    ssl_certificate_key /etc/nginx/sites-enabled/certs/tecmintlovesnginx.key;
    ssl_protocols       TLSv1 TLSv1.1 TLSv1.2;
}

W następnej wskazówce sprawdzimy, w jaki sposób nasza witryna korzysta teraz z certyfikatu z podpisem własnym i protokołu TLS.

WSKAZÓWKA #12: Przekieruj ruch HTTP do HTTPS w Nginx

Dodaj następujący wiersz do pierwszego bloku serwera:

return 301 https://$server_name$request_uri;

Powyższa dyrektywa zwróci odpowiedź 301 (przeniesiona na stałe), która służy do stałego przekierowania adresu URL za każdym razem, gdy zostanie wysłane żądanie do portu 80 Twojego wirtualnego hosta i przekieruje żądanie do bloku serwera, który dodane w poprzedniej wskazówce.

Poniższy obrazek przedstawia przekierowanie i potwierdza fakt, że do szyfrowania używamy TLS 1.2 i AES-256:

Streszczenie

W tym artykule udostępniliśmy kilka wskazówek, jak zabezpieczyć serwer WWW Nginx. Chcielibyśmy usłyszeć, co myślisz, a jeśli masz inne wskazówki, którymi chciałbyś podzielić się z resztą społeczności, daj nam znać, wysyłając nam notatkę, korzystając z poniższego formularza komentarza.