![Cum se utilizează Skype pe Android - Un ghid pentru începători](/f/d3069f75b8f22c5deaf9f8e9bafb9e4a.png?width=100&height=100)
Pe baza lucrurilor minunate despre care ai auzit Nginx, poate ai decis să încerci. Poate că ți-a plăcut atât de mult încât te gândești să înlocuiești instalările tale Apache cu Nginx după ce ai parcurs câteva dintre articolele pe tema pe care le-am publicat pe acest site.
Dacă da, sunt sigur că veți întâmpina acest ghid cu brațele deschise, deoarece vom acoperi 12 sfaturi pentru a crește securitatea Nginx servere (de la menținerea actualizată a Nginx până la utilizarea TLS și redirecționarea HTTP către HTTPS) și veți observa că unele dintre ele sunt foarte asemănătoare cu ceea ce ați face cu Apache.
Nu ratați:
13 Sfaturi pentru securitate și întărire a serverului web Apache
25 Trucuri Apache Htaccess pentru securizarea serverului web Apache
În acest ghid vom folosi următorul mediu:
Având în vedere acest lucru, să începem.
În momentul redactării acestui articol, cele mai recente versiuni Nginx din CentOS (în EPEL) și depozitele Debian sunt 1.6.3 și 1.6.2-5, respectiv.
Nu ratați:Instalați cea mai recentă versiune stabilă de Nginx din depozite și sursă
Deși instalarea software-ului din depozite este mai ușoară decât compilarea programului din codul sursă, această ultimă opțiune are două avantaje: 1) vă permite să construiți module suplimentare în Nginx (cum ar fi mod_security) și 2) va furniza întotdeauna o versiune mai nouă decât depozitele (1.9.9 de astăzi). Notele de lansare sunt întotdeauna disponibile pe site-ul web Nginx.
Nu ratați:
Protejați Apache împotriva Forței Brute și a atacurilor DDoS folosind Mod_Security și Mod_Evasive
Pentru a elimina în mod explicit modulele din Nginx în timp ce instalați de la sursă, faceți:
# ./configure --without-module1 --without-module2 --without-module3.
De exemplu:
# ./configure --without-http_dav_module --withouthttp_spdy_module
După cum probabil veți ghici, eliminarea modulelor dintr-o instalare anterioară Nginx de la sursă necesită efectuarea din nou a compilării.
Un cuvânt de precauție: Directivele de configurare sunt furnizate de module. Asigurați-vă că nu dezactivați un modul care conține o directivă de care veți avea nevoie pe drum! Ar trebui să verificați documente nginx pentru lista directivelor disponibile în fiecare modul înainte de a lua o decizie privind dezactivarea modulelor.
server_tokens
directiva îi spune lui Nginx să afișeze versiunea sa curentă pe paginile de eroare. Acest lucru nu este de dorit, deoarece nu doriți să partajați aceste informații lumii pentru a preveni atacurile la serverul dvs. web cauzate de vulnerabilități cunoscute în acea versiune specifică.
Pentru a dezactiva server_tokens
directivă, setați dacă este dezactivat în interiorul unui bloc de server:
server {asculta 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; rădăcină /var/www/tecmintlovesnginx.com/public_html; index index.html index.htm; }
Reporniți nginx și verificați modificările:
Un agent de utilizator HTTP este un software care este utilizat pentru negocierea conținutului împotriva unui server web. Aceasta include, de asemenea, roboți malware și crawler-uri care pot ajunge să afecteze performanța serverului dvs. web prin risipirea resurselor sistemului.
Pentru a menține mai ușor lista agenților de utilizatori nedoriti, creați un fișier (/etc/nginx/blockuseragents.rules
de exemplu) cu următorul conținut:
map $ http_user_agent $ blockedagent {implicit 0; ~ * rău intenționat 1; ~ * bot 1; ~ * spate 1; ~ * crawler 1; ~ * bandit 1; }
Apoi, plasați următoarea linie înainte de definiția blocului de server:
include /etc/nginx/blockuseragents.rules;
Și o instrucțiune if pentru a returna un răspuns 403 dacă șirul agentului utilizator se află în lista neagră definită mai sus:
Reporniți nginx și toți agenții de utilizator al căror șir se potrivește cu cel de mai sus vor fi blocați accesul la serverul dvs. web. A inlocui 192.168.0.25 cu adresa IP a serverului dvs. și nu ezitați să alegeți un șir diferit pentru --agent utilizator
inchide wget:
# wget http://192.168.0.25/index.html. # wget --user-agent "Sunt un bandit haha" http://192.168.0.25/index.html
Cunoscute și sub numele de verbe, metodele HTTP indică acțiunea dorită care trebuie întreprinsă asupra unei resurse deservite de Nginx. Pentru site-urile și aplicațiile web obișnuite, ar trebui să permiteți numai OBȚINE, POST, și CAP și dezactivează toate celelalte.
Pentru aceasta, plasați următoarele linii într-un bloc server. A 444 Răspunsul HTTP înseamnă un răspuns gol și este adesea folosit în Nginx pentru a păcăli atacurile malware:
if ($ request_method! ~ ^ (GET | HEAD | POST) $) {return 444; }
Pentru a testa, utilizați răsuci a trimite un ȘTERGE solicitați și comparați ieșirea cu atunci când trimiteți un mesaj obișnuit OBȚINE:
# curl -X DELETE http://192.168.0.25/index.html. # curl -X POST http://192.168.0.25/index.html
Pentru a preveni atacurile de depășire a bufferului împotriva serverului dvs. web Nginx, setați următoarele directive într-un fișier separat (creați un fișier nou numit /etc/nginx/conf.d/buffer.conf
, de exemplu):
client_body_buffer_size 1k; client_header_buffer_size 1k; client_max_body_size 1k; large_client_header_buffers 2 1k;
Directivele de mai sus se vor asigura că solicitările făcute către serverul dvs. web nu vor provoca o depășire a bufferului în sistemul dvs. Încă o dată, consultați documentele pentru detalii suplimentare despre ceea ce face fiecare dintre ele.
Apoi adăugați o directivă include în fișierul de configurare:
include /etc/nginx/conf.d/*.conf;
Pentru a limita conexiunile prin IP, utilizați limit_conn_zone
(într-un context http sau cel puțin în afara blocului server) și limit_conn (într-un http, bloc server sau context de locație) directive.
Cu toate acestea, rețineți că nu toate conexiunile sunt numărate - ci au fost citite doar cele care au o cerere procesată de server și întregul său antet de cerere.
De exemplu, să setăm numărul maxim de conexiuni la 1
(da, este o exagerare, dar va face treaba foarte bine în acest caz) într-o zonă numită addr (puteți seta acest lucru la orice nume doriți):
limit_conn_zone $ binary_remote_addr zone = addr: 5m; limit_conn addr 1;
Un test simplu cu Apache Benchmark (Efectuați încărcarea Nginx) Unde 10
conexiunile totale se fac cu 2
solicitările simultane ne vor ajuta să demonstrăm ideea noastră:
# ab -n 10 -c 2 http://192.168.0.25/index.html.
Consultați următorul sfat pentru detalii suplimentare.
După ce ați efectuat testul descris în sfatul anterior, verificați jurnalul de erori care este definit pentru blocul de server:
Poate doriți să utilizați grep pentru a filtra jurnalele pentru solicitările eșuate făcute către adăugazona r definită în SFAT # 7:
# grep addr /var/www/logs/tecmintlovesnginx.error.log --color = auto.
De asemenea, puteți filtra jurnalul de acces pentru informații de interes, cum ar fi:
Și luați măsurile adecvate dacă detectați orice activitate neobișnuită sau nedorită.
Hotlinkingul imaginilor se întâmplă atunci când o persoană afișează pe un alt site o imagine găzduită pe a ta. Acest lucru determină o creștere a utilizării lățimii de bandă (pe care o plătiți) în timp ce cealaltă persoană afișează fericit imaginea ca și cum ar fi proprietatea sa. Cu alte cuvinte, este o dublă pierdere pentru dvs.
De exemplu, să presupunem că aveți un subdirector numit img
în interiorul blocului serverului dvs. unde stocați toate imaginile utilizate în acea gazdă virtuală. Pentru a împiedica alte site-uri să vă utilizeze imaginile, va trebui să inserați următorul bloc de locație în definiția gazdei dvs. virtuale:
location / img / {valid_referers none blocat 192.168.0.25; if ($ invalid_referer) {return 403; } }
Apoi modificați fișierul index.html
fișier în fiecare gazdă virtuală după cum urmează:
192.168.0.26 |
192.168.0.25 |
Nginx înseamnă putere!![]() |
Tecmint îl iubește pe Nginx!![]() |
Acum navigați la fiecare site și, după cum puteți vedea, imaginea este afișată corect în 192.168.0.25 dar este înlocuit cu un 403 răspuns în 192.168.0.26:
Rețineți că acest sfat depinde de browserul de la distanță care trimite câmpul Referer.
Ori de câte ori este posibil, faceți tot ce este necesar pentru a evita SSL în oricare dintre versiunile și utilizarea sa TLS in schimb. Următoarele ssl_protocols
ar trebui să fie plasat într-un server sau context http în fișierul dvs. gazdă virtual sau este un fișier separat printr-o directivă include (unii oameni folosesc un fișier numit ssl.conf
, dar depinde în totalitate de dvs.):
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
De exemplu:
În primul rând, generați o cheie și un certificat. Simțiți-vă liber să utilizați un alt tip de criptare dacă doriți:
# 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.
Apoi adăugați următoarele rânduri într-un bloc de server separat în pregătirea următorului sfat (http -> https
redirecționare) și mutați directivele legate de SSL și în noul bloc:
server {asculta 192.168.0.25:443 ssl; server_tokens off; server_name tecmintlovesnginx.com www.tecmintlovesnginx.com; rădăcină /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; }
În următorul sfat vom verifica modul în care site-ul nostru utilizează acum un certificat auto-semnat și TLS.
Adăugați următoarea linie la primul bloc de server:
returnează 301 https://$server_name$request_uri;
Directiva de mai sus va returna un 301 Răspuns (mutat definitiv), care este utilizat pentru redirecționarea URL permanentă ori de câte ori este făcută o solicitare către portul 80 al gazdei dvs. virtuale și va redirecționa cererea către blocul de server pe care l-am adăugat în precedent bacsis.
Imaginea de mai jos arată redirecționarea și confirmă faptul că folosim TLS 1.2 și AES-256 pentru criptare:
În acest articol am împărtășit câteva sfaturi pentru a vă securiza serverul web Nginx. Ne-ar plăcea să aflăm ce părere aveți și, dacă aveți alte sfaturi cu care ați dori să împărtășiți restul comunității, nu ezitați să ne anunțați trimițându-ne o notă folosind formularul de comentarii de mai jos.