Konfigurera nginx att arbeta med var. Nginx: konfiguration och installation. Om dagens hjälte

Nginx är en populär och kraftfull webbserver och omvänd proxy.

Nginx har många fördelar, men dess inställningar är ganska komplexa och inte alltid tydliga för nybörjare. Denna manual hjälper dig att förstå de grundläggande parametrarna, syntaxen och konfigurationsfilerna för Nginx.

Notera: Denna handledning gjordes på Ubuntu 12.04.

Nginx kataloghierarki

Nginx lagrar konfigurationsfiler i katalogen /etc/nginx.

Denna katalog innehåller flera fler kataloger och modulära konfigurationsfiler.

cd /etc/nginx
ls -F

conf.d/ koi-win naxsi.rules scgi_params uwsgi_params
fastcgi_params mime.types nginx.conf sites-available/win-utf
koi-utf naxsi_core.rules proxy_params sites-enabled/

Apache-användare är redan bekanta med katalogerna med webbplatser som är tillgängliga och webbplatsaktiverade. Dessa kataloger definierar platskonfigurationer. Filer skapas och lagras vanligtvis på webbplatser som är tillgängliga; webbplatsaktiverade lagrar endast konfigurationer av aktiverade webbplatser. För att göra detta måste du skapa en symbolisk länk från webbplatser som är tillgängliga till webbplatser aktiverade.

Mappen conf.d kan också användas för att lagra konfigurationer. Varje fil med filtillägget .conf kommer att läsas när Nginx startar. Syntaxen för sådana filer bör inte innehålla fel.

Nästan alla återstående filer lagras i /etc/nginx, som innehåller konfigurationsinformation för specifika processer eller ytterligare komponenter.

Den huvudsakliga Nginx-konfigurationsfilen är nginx.conf.

nginx.conf filen

Filen nginx.conf läser motsvarande konfigurationsfiler och kombinerar dem till en enda konfigurationsfil när servern startar.

Öppna filen:

sudo nano /etc/nginx/nginx.conf

användare www-data;
arbetarprocesser 4;
pid /var/run/nginx.pid;
evenemang (
worker_connections 768;
#multi_acceptera på;
}
http (
. . .

De första raderna ger allmän information om Nginx. Linjeanvändaren www-data anger den användare som servern startas med.

Pid-direktivet anger var process-PID:n kommer att lagras för internt bruk. Raden worker_processes bestämmer antalet processer som Nginx kan stödja samtidigt.

Du kan också ange loggar i den här delen av filen (till exempel definieras felloggen med direktivet error_log).

Bakom allmän information om servern följer händelseavsnittet. Den hanterar hanteringen av Nginx-anslutningar. Det följs av http-blocket. Innan vi fortsätter med webbserverkonfigurationer måste vi förstå hur Nginx-konfigurationsfilen är formaterad.

Nginx konfigurationsfilstruktur

Nginx-konfigurationsfilen är uppdelad i block.

Det första blocket är händelser, följt av http och den huvudsakliga hierarkin av konfigurationer börjar.

Konfigurationsdetaljerna för ett http-block är skiktade med hjälp av slutna block som ärver egenskaper från blocket där de finns. http-blocket lagrar det mesta vanliga konfigurationer Nginx, som är uppdelade i serverblock, som i sin tur är uppdelade i platsblock.

När du konfigurerar Nginx är det viktigt att komma ihåg följande regel: ju högre konfigurationsnivån är, desto fler block ärver denna konfiguration; ju lägre konfigurationsnivå, desto mer "individuell" är den. Det vill säga, om X-parametern måste användas i varje serverblock, måste en sådan parameter placeras i http-blocket.

Om du tittar noga på filen kommer du att märka att den innehåller många alternativ som bestämmer programmets beteende som helhet.

Till exempel, för att konfigurera filkomprimering, måste du ställa in följande parametrar:

gzip på;
gzip_disable "msie6";

Detta kommer att aktivera gzip-stöd för att komprimera data som skickas till klienten och inaktivera gzip för Internet Explorer 6 (eftersom den här webbläsaren inte stöder datakomprimering).

Om någon parameter ska ha annan betydelse i flera serverblock, då kan en sådan parameter ställas in högsta nivån och sedan åsidosätta det i själva serverblocken. Som ett resultat kommer Nginx att köra parametern på lägsta nivån.

Denna nivå av konfigurationer undviker behovet av att hantera flera identiska filer. Dessutom, om du har glömt att definiera parametrar på lägsta nivån, kommer Nginx helt enkelt att implementera standardalternativen.

http-blocket i filen nginx.conf slutar så här:

inkludera /etc/nginx/conf.d/*.conf;
inkluderar /etc/nginx/sites-enabled/*;

Detta innebär att server- och platsblocken, som definierar inställningar för specifika webbplatser och webbadresser, kommer att lagras utanför denna fil.

Detta möjliggör en modulär konfigurationsarkitektur där nya filer kan skapas för att betjäna nya webbplatser. Det låter dig också gruppera liknande filer.

Stäng filen nginx.conf. Nu måste du studera inställningarna för enskilda webbplatser.

Nginx virtuella block

Serverblock i Nginx är analoga med Apaches virtuella värdar (men för enkelhetens skull kallas de även virtuella värdar). I huvudsak är serverblock specifikationer separata webbplatser på samma server.

I katalogen som är tillgängliga för webbplatser kan du hitta standardserverblockfilen som följer med servern. Denna fil innehåller all nödvändig information för att underhålla webbplatsen.

cd-sajter-tillgängliga
sudo nano standard

root /usr/share/nginx/www;
index index.html index.htm;
servernamn lokalvärd;
plats/(

}
plats /doc/ (

alias /usr/share/doc/;
autoindex på;
tillåt 127.0.0.1;
förneka alla;

Standardfilen är mycket väl kommenterad, men i exemplet ovan har kommentarerna utelämnats för enkelhetens skull och bekvämligheten.

Serverblocket innehåller alla inställningar placerade mellan de lockiga hängslen:

server(
. . .
}

Detta block placeras i filen nginx.conf nära slutet av http-blocket med hjälp av direktivet include.

Rotdirektivet anger i vilken katalog webbplatsens innehåll kommer att lagras. Nginx kommer att leta i den här katalogen efter filer som efterfrågas av användaren. Som standard är detta /usr/share/nginx/www.

Observera: alla rader slutar med semikolon. Det är så Nginx skiljer ett direktiv från ett annat. Om det inte finns något semikolon kommer Nginx att läsa de två direktiven (eller flera direktiv) som ett direktiv med ytterligare argument.

Indexdirektivet anger vilka filer som ska användas som index. Webbservern kommer att kontrollera filerna i den ordning de är listade. Om ingen sida begärdes kommer serverblocket att hitta och returnera filen index.html. Om den inte kan hitta den filen kommer den att försöka bearbeta index.htm.

server_name-direktivet

Direktivet server_name innehåller en lista över domännamn som kommer att betjänas av detta serverblock. Antalet domäner är obegränsat; domäner i listan ska separeras med mellanslag.

En asterisk (*) i början eller slutet av en domän anger ett namn med en mask, där asterisken matchar en del (eller flera delar) av namnet. Till exempel skulle namnet *.example.com matcha namnen forum.example.com och www.animals.example.com.

Om den begärda webbadressen matchar mer än ett server_name-direktiv kommer den först att svara med den som matchar exakt.

Om adressen inte hittar några matchningar kommer den att leta efter mest långt namn med en mask som slutar med en asterisk. Om den inte hittar ett sådant namn kommer den att returnera den första matchningen med reguljära uttryck.

Servernamn som använder reguljära uttryck börjar med en tilde (~). Tyvärr, det här ämnet ligger utanför ramen för denna artikel.

Plats block

Platsen / raden indikerar att direktiven inom parentes kommer att gälla för alla begärda resurser som inte matchar några andra platsblock.

Sådana block kan innehålla en uri-sökväg (till exempel /doc/). För att upprätta en fullständig matchning mellan plats och uri, används symbolen =. Tecknet ~ matchar reguljära uttryck.

En tilde aktiverar skiftlägeskänsligt läge, medan en tilde med en asterisk aktiverar skiftlägesokänsligt läge.

Om begäran helt matchar platsblocket, stoppar servern sökningen och använder ett sådant block. Om servern inte hittar ett helt matchande platsblock jämför den URI:n med parametrarna för platsdirektiven. Nginx kommer att välja ett block som använder teckenkombinationen ^~ och som matchar URI:n.

Om alternativet ^~ inte används kommer Nginx att välja den närmaste matchningen och utföra en sökning med reguljära uttryck för att försöka matcha ett av de tillgängliga mönstren. Hittar han ett sådant uttryck använder han det. Om det inte finns något sådant uttryck använder servern den tidigare hittade URI-matchningen.

Som en sista notering föredrar Nginx exakta matchningar. Om det inte finns några sådana matchningar, letar den efter vanligt uttryck och sedan söker efter URI. För att ändra sökprioriteten för en URI, använd teckenkombinationen ^~.

try_files-direktivet

Try_files-direktivet är mycket användbart verktyg, som söker efter filer i en given ordning och använder den första filen som hittas för att behandla begäran.

Detta gör att du kan använda ytterligare parametrar bestämma hur Nginx ska betjäna förfrågningar.

Standardkonfigurationsfilen har raden:

try_files $uri $uri/ /index.html;

Detta betyder att när en begäran tas emot som betjänas av ett platsblock, kommer Nginx först att försöka tjäna uri:n som en fil (detta beteende specificeras av variabeln $uri).

Om servern inte hittar en matchning för variabeln $uri kommer den att försöka använda uri som en katalog.

Med hjälp av ett efterföljande snedstreck kontrollerar servern om det finns en katalog, till exempel $uri/.

Om ingen fil eller katalog hittas, kör Nginx standardfilen (i I detta fall detta är index.html i rotkatalogen för serverblocket). Varje try_files-direktiv använder den sista parametern som en reserv, så filen måste finnas i systemet.

Om webbservern inte hittar en matchning i föregående parametrar kan den returnera en felsida. För att göra detta, använd likhetstecknet och felkoden.

Till exempel, om platsen/blocket inte kan hitta den begärda resursen, kan det returnera ett 404-fel istället för en index.html-fil:

try_files $uri $uri/ =404;

För att göra detta måste du sätta ett likhetstecken och ställa in felkoden som sista parameter (=404).

Extra tillval

Aliasdirektivet tillåter Nginx att servera platsblocksidor utanför en given katalog (till exempel utanför roten).

Till exempel kommer filer som begärs från /doc/ att betjänas från /usr/share/doc/.

Autoindex on-direktivet låter dig aktivera listning av Nginx-kataloger för ett givet platsdirektiv.

Tillåt och neka raderna styr åtkomst till kataloger.

Slutsats

Nginx webbserver är funktionsrik och mycket kraftfull, men dess terminologi och alternativ kan vara förvirrande.

När du väl förstår Nginx-konfigurationer och lär dig hur du arbetar med dem kommer du att få alla fördelar med detta kraftfulla och lätta verktyg.

Mer än 50 % av trafiken över hela världen betjänas av Apache- och Nginx-teknik– webbservrar som är öppen källkod. Nginx utför frontend-funktionen, Apache utför backend-funktionen. Nginx är den första som accepterar användarförfrågningar och svarar på dem med det nödvändiga innehållet - bilder, filer, skript. Heavy Apache i sin tur sysslar inte med detta, utan bearbetar dynamiken. Nginx proxy-förfrågningar och retursvar. Denna kombination är bra för stora webbplatser som besöks av många användare. För små webbplatser kommer denna kombination inte att öka produktiviteten. Apache och Nginx minskar belastningen på servern i allmänhet på grund av att Nginx hanterar statiskt innehåll, medan Apache hanterar dynamiskt innehåll.

Apache och Nginx bör inte betraktas som utbytbara teknologier, även om de har många liknande funktioner. Varje webbserver har sina egna fördelar och dess användning beror på uppgiften. I den här artikeln Låt oss titta på varje teknik beroende på tillämpningsomfånget. Artikeln kommer att vara användbar för ägare av virtuella och dedikerade fysiska servrar.

Funktionellt och snabbt, Nginx släpptes 2004 och efter denna utgåva började det bli populärt. På grund av sin lätta vikt och skalbarhet fungerar den bra på vilken hårdvara som helst. Nginx används på två sätt: som webbserver eller som proxy.

Vad gör Nginx som webbserver?

• skapar automatiskt cache-beskrivningar och fillistor, serverar indexfiler och statiska frågor;
• accelererar feltolerans, proxy och lastbalansering;
• cachar med FastCGI och snabbar upp proxysändning;
• stöder SSL;
• stöder Perl;
• har filter och modularitet;
• autentiserar HTTP och filtrerar SSL.

Som en Nginx-proxy:

• fullständigt tillhandahållande av StartTLS och SSL;
• enkel autentisering (ANVÄNDARE/PASS, LOGIN);
• använder en extern HTTP-server för att omdirigera till POP3/IMAP-backend.

Som du kan se utför Nginx många funktioner utan att överbelasta systemet. Enligt officiella uppgifter används tekniken av mer än 56 miljoner sajter runt om i världen (till exempel Rambler, Yandex, Mail, Begun, WordPress.com, vk.com, Facebook, Rutracker.org), men Nginx är sämre än Apache i popularitet. Varför är Apache så populär?

Apache webbserver – plattformsoberoende programvara, som skapades 1995. Tack vare omfattande dokumentation och bra integration med tredjepartsmjukvara har Apache vunnit enorm popularitet. Stöder följande OS - Linux, BSD, Mac OS, Microsoft Windows, Novell NetWare, BeOS. .

Fördelar med Apache webbserver:

• Stöd programmeringsspråk PHP, Python, Ruby, Perl, ASP, Tcl;
• enkel anslutning av externa moduler;
• tekniskt stöd CGI och FastCGI;
• förekomsten av mekanismer som säkerställer säkerhet och differentiering av dataåtkomst;
• möjligheten att använda en DBMS för användarverifiering;
• flexibel och pålitlig systemkonfiguration;
• lämplig för applikationer som kräver kraftfull kryptografiskt skydd data;
• möjligheten att skapa anpassade kataloger för webbplatsen;
• möjlighet att konfigurera virtuella värdar, med hjälp av vilken du kan skapa flera virtuella på en fysisk server;
• håller loggar över vad som händer på din server;
• aktiva Respons med utvecklare och snabb lösning av programvarufel.

Men trots alla fördelar med Apache-webbservern är den lite svår att konfigurera och använda, så inte alla nybörjare kommer att klara av det. Men om ditt projekt behöver just den här programvaran, kommer du att göra det rätt val till förmån för Apache.

Vill du säkra PHP fungerar på servern? Mer information om detta.

Efter att ha känt till för- och nackdelarna med Apache och Nginx kan du välja användbara lösningar för din webbplats, beroende på vilka mål du eftersträvar. Men Kanske behöver du kombinationen Apache+Nginx för prestation bästa resultat. Till exempel, Nginx används ofta framför Apache som en omvänd proxy. Denna kombination gör att du kan hantera många konkurrenskraftiga förfrågningar och sorterar dem. De förfrågningar som Nginx inte kan hantera skickas till Apache, vilket minskar belastningen på den senare. I detta fall ökar feltoleransen. Innan du väljer en webbserver måste du genomföra obligatoriska tester av varje lösnings prestanda och kapacitet.

För mer information om all teknik som stöds av HyperHost-hosting, besök.

Den här artikeln skapades för allmän bekantskap med möjligheterna att kombinera Apache- och Nginx-webbservrar. Ännu mer information i .

Om du behöver vår hjälp, vänligen kontakta oss!

Vi svarar gärna på alla dina frågor om att sätta upp webbservrar. Du kan också alltid få gratis administration av oss. Är all teknisk support hos värdar densamma? Om funktionerna i gratis och betald administration i en speciell.

17248 gånger 9 visade gånger idag

Nginx är en webbserver och e-postproxy som har varit allmänt tillgänglig sedan 2004. Utvecklingen av projektet började 2002 på ryska låter namnet som motor-ex. Som skapandet av den berömda programmeraren Igor Sysoev var Nginx ursprungligen avsedd för företaget Rambler. Den är designad för operativsystem som tillhör den Unix-liknande gruppen. Sammansättningen har framgångsrikt testats på OpenBSD, FreeBSD, Linux, Mac OS X, Solaris. På Microsoft Windows-plattformen började Nginx arbeta med tillkomsten av den binära monteringsversionen 0.7.52.

Statistik för mars 2011 visar att antalet webbplatser som betjänas av Nginx redan har passerat 22 miljoner-gränsen. Idag används Nginx av så välkända projekt som Rambler, Begun, Yandex, SourceForge.net, WordPress.com, vkontakte.ru och andra. Tillsammans med lighttpd används Nginx för att servera statiskt innehåll som genereras av en "obekväm" webbapplikation som fungerar "under auktoritet" av en annan webbserver.
Men innan du går in i djungeln av Nginx funktionella funktioner, skulle det vara användbart att komma ihåg vad en webbserver är i allmänhet och en proxyserver i synnerhet.

Webbserver och proxyserver

webbserverär en server som accepterar HTTP-förfrågningar från webbläsare och andra klienter och utfärdar HTTP-svar till dem. De senare brukar vara representerade HTML-sida, mediaström, bild, fil, annan data. En webbserver avser både programvara som utför webbserverfunktioner och hårdvara. Utbytet av data och begärd information sker via HTTP-protokollet.

Lägg till i lista ytterligare funktioner webbservrar inkluderar: auktorisering och autentisering av användare, loggning av deras åtkomst till resurser, HTTPS-stöd för säker kommunikation med klienter och andra. Den mest använda webbservern på Unix-liknande operativsystem är Apache. Nginx upptar för närvarande tredje plats i listan över klientpreferenser.

Proxyserver låter kunderna hantera sökfrågor till nättjänster i indirekt form. Det vill säga, det är en server som är specialiserad på att omdirigera klientförfrågningar till andra servrar. Genom att ansluta till en proxyserver och begära en resurs som finns på en annan server har klienten möjlighet att upprätthålla anonymitet och skydda datorn från nätverksattacker. Proxyservern tillhandahåller den begärda informationen till klienten antingen från sin egen cache (om det finns en) eller genom att ta emot den från den angivna servern. I vissa fall (för att uppnå ovanstående mål) kan serversvaret, som klientförfrågan, modifieras av proxyservern.

Mest en enkel proxyserver anses nätverksadressöversättare eller NAT. År 2000 byggdes proxy NAT in Windows distribution. Proxyservrar har, precis som alla företeelser, två sidor av myntet, det vill säga de kan användas på både gott och ont. Till exempel, med deras hjälp döljer de som fruktar sanktioner för sina olämpliga handlingar online sina IP-adresser...

Nginx funktionsområde:

• serverunderhåll av indexfiler, statiska frågor, generering av cache-deskriptorer öppna filer, fillista;
• accelererad proxy, elementär lastfördelning, feltolerans;
• cachingstöd under accelererad proxy och FastCGI;
• stöd för FastCGI (accelererad) och memcachade servrar;
• modularitet, filter, inklusive återuppta (byte-intervall) och komprimering (gzip);
• HTTP-autentisering, chunkade svar, SSI-filter;
• parallell exekvering av flera delfrågor på en sida som bearbetas genom FastCGI eller en proxy i SSI-filtret;
• StartTLS och SSL-stöd;
• förmåga att stödja inbyggd Perl;
• enkel autentisering (ANVÄNDARE/PASS, LOGIN);
• serveromdirigering (IMAP/POP3-proxy) av användaren till IMAP/POP3-backend med extern server autentisering (HTTP).

För dem som inte är bekanta med den här terminologin kan beskrivningen av Nginx-funktionalitet verka väldigt vag. Men när vi pratar om specifika sätt att använda den här webbservern kommer den gradvis att börja försvinna.

Arkitektur och konfiguration

Arbetsprocesser i Nginx betjänar samtidigt många anslutningar och förser dem med OS-anrop ( operativ system) epoll (Linux), välj och kkö (FreeBSD). Uppgifter som tas emot från klienten behandlas genom ändlig tillståndsmaskin. Den analyserade begäran behandlas av en kedja av moduler som specificeras av konfigurationen. Svaret till klienten genereras i buffertar, som kan peka på en del av en fil eller lagra data i minnet. Sekvensen för dataöverföring till klienten bestäms av kedjorna i vilka buffertarna är grupperade.

Strukturellt är Nginx HTTP-servern uppdelad i virtuella servrar, som i sin tur är uppdelade i platser. Virtuell server eller direktiv kan du ange portar och adresser för att ta emot anslutningar. För plats kan du ange en exakt URI, del av en URI eller ett reguljärt uttryck för operativ ledning Minnet är poolat, vilket är en sekvens av förvalda minnesblock. Ett block, initialt tilldelat för poolen, har en längd från 1 till 16 kilobyte. Det är uppdelat i områden – ockuperade och obesatta. När den senare fylls säkerställs tilldelningen av ett nytt objekt genom bildandet av ett nytt block.

Geografisk klassificering av klienter efter deras IP-adress utförs i Nginx med hjälp av en speciell modul. Radix-trädsystemet låter dig snabbt arbeta med IP-adresser och upptar ett minimum av minne.

Fördelarna med Nginx

Nginx anses vara väldigt snabbt HTTP-server. Istället för Apache eller tillsammans med den används Nginx för att påskynda förfrågningsbehandlingen och minska belastningen på servern. Faktum är att de flesta användare inte behöver de enorma möjligheter som finns i Apaches modulära arkitektur. Att betala för denna outnyttjade funktionalitet kostar en betydande kostnad. systemresurser. Vanliga webbplatser kännetecknas som regel av en tydlig "dominans" av statiska filer (bilder, stilfiler, JavaScript), snarare än skript. Ingen speciell funktionalitet krävs för att överföra dessa filer till en resursbesökare, eftersom uppgiften är mycket enkel. Detta innebär att webbservern för att behandla sådana förfrågningar måste vara enkel och lätt, som Nginx.

Sätt att använda Nginx

På separat port/IP. Om resursen är mättad med bilder eller filer för nedladdning kan Nginx konfigureras på en separat port eller IP och distribuera statiskt innehåll genom den. För att göra detta måste du dock mixtra lite med att ändra länkar på sajten. På stora mängder förfrågningar till statiska filer, är det vettigt att ha en separat server och installera Nginx på den.

Accelererad proxy. Med det här alternativet går alla besöksförfrågningar först till Nginx. Begäran om statiska filer (till exempel bilder, enkel HTML, JavaScript eller CSS-fil) Nginx bearbetar den oberoende. Om en användare kommer åt ett visst skript kommer han att omdirigera begäran till Apache-avdelningen. Det finns ingen anledning att göra några transformationer med webbplatskoden.

Om kanalen från servern till besökaren och vice versa är långsam kan denna användning av Nginx ge ytterligare effekt. Nginx skickar begäran från besökaren till Apache för bearbetning. Efter att ha bearbetat begäran vidarebefordrar Apache sidan till Nginx och avslutar anslutningen med en känsla av prestation. Nginx kan nu skicka en sida till en användare så länge som önskas, praktiskt taget utan att förbruka systemresurser. Arbetet med Apache i dess ställe skulle åtföljas av en orimligt hög belastning på minnet när den kördes nästan tomgång. Förresten, det här användningsfallet för Nginx har ett annat namn: "frontend till Apache".

Nginx plus FastCGI. Apache kanske inte behövs alls om tolken av språket som webbplatsens skript är skrivna på stöder FastCGI-teknik. Sådana språk inkluderar till exempel PHP, Perl och ett antal andra. I det här fallet kan du dock behöva ändra skriptkoderna.

Det finns många detaljerade material om hur man installerar och konfigurerar Nginx på Internet. Du kan lära dig mer om Nginx på webbplatsen för dess utvecklare Igor Sysoev.

En dedikerad Nginx-baserad webbserver är ett utmärkt sätt att förbättra prestandan på webbplatser. Den har helt enkelt ingen motsvarighet i hastigheten för att bearbeta statiskt innehåll: den klarar enkelt flera tusen samtidiga anslutningar och kan enkelt optimeras och skräddarsys för alla konfigurationer. Dock? Nginx fungerar som gränssnittet för Apache och visar sig vara den mest sårbara punkten i hela webbinfrastrukturen, så särskild uppmärksamhet måste ägnas åt nginx-säkerhet.

Den här artikeln är ett slags utbildningsprogram, eller, om du vill, en sammanfattning av alla tekniker för att förbättra nginx-säkerheten. Den kommer inte att innehålla teori, en beskrivning av grunderna för att sätta upp en webbserver och annat ludd. Istället får du en heltäckande praktiskt material, som beskriver alla grundläggande steg som måste tas för att få en riktigt säker webbserver.

Installation

Paketet nginx är tillgängligt i förkompilerad form för alla distributioner. Men genom att bygga servern själv kan du göra den mer kompakt och pålitlig, och du kommer också att ha möjlighet att ändra webbserverns hälsningsrad för att avskräcka från dumma skriptbarn.

Ändra webbserverns hälsningsrad

Ladda ner nginx-källorna, öppna filen src/http/ngx_http_header_filter_module.c och hitta följande två rader:

static char ngx_http_server_string = "Server: nginx" CRLF;
static char ngx_http_server_full_string = "Server: " NGINX_VER CRLF;

Byt ut dem mot något sånt här:

static char ngx_http_server_string = "Server: ][ Webbserver"CRLF;
static char ngx_http_server_full_string = "Server: ][ webbserver" CRLF;

Ta bort alla nginx-moduler du inte använder

Vissa nginx-moduler ansluter till webbservern direkt under kompileringen, och någon av dem är fylld med potentiell fara. Kanske kommer en sårbarhet att hittas i en av dem i framtiden, och din server kommer att vara i fara. Genom att inaktivera onödiga moduler kan du avsevärt minska risken för att denna situation ska inträffa.

Bygg med följande kommandon:

# ./configure --without-http_autoindex_module --without-http_ssi_module
# göra
# gör installationen

På så sätt kommer du att få nginx med modulerna SSI (Server Side Includes) och Autoindex inaktiverade i förväg (och i de flesta fall värdelösa). För att ta reda på vilka moduler som säkert kan tas bort från webbservern, kör konfigureringsskriptet med flaggan "-hjälp".

Låt oss dissekera nginx.conf

Efter installationen bör nginx konfigureras. Det fanns redan material som beskrev denna process på tidningens sidor, men vi kommer att hålla oss till ämnet för artikeln och prata om sätt att öka serversäkerheten.

Inaktivera visning av serverversionen på alla felsidor

Lägg till raden "server_tokens off" i filen nginx.conf. Detta kommer att tvinga nginx att dölja information om typen och versionen av webbservern på sidor som genereras som svar på en felaktig klientförfrågan.

Ställ in skydd mot stackstörningar

Lägg till i serversektionen följande rader:

# vi /etc/nginx/nginx.conf

# Maximal storlek buffert för att lagra huvuddelen av klientförfrågan
client_body_buffer_size 1K;
# Maximal buffertstorlek för lagring av klientförfrågningshuvuden
client_header_buffer_size 1k;
# Den maximala storleken på klientbegäran, specificerad i rubrikfältet Content-Length. Om servern måste stödja filuppladdningar måste detta värde ökas
client_max_body_size 1k;
# Antal och storlek på buffertar för att läsa huvudet för stora klientförfrågningar
large_client_header_buffers 2 1k;

Var uppmärksam på direktivet large_client_header_buffers. Som standard allokerar nginx fyra buffertar för att lagra URI-strängen, vars storlek är lika med storleken på en minnessida (för x86 är detta 4 KB). Buffertar frigörs varje gång anslutningen går in i håll vid liv efter att ha bearbetat en begäran. Två buffertar på 1 KB kan lagra URI:er som bara är 2 KB långa, vilket hjälper till att bekämpa bots och DoS-attacker.

För att förbättra prestandan, lägg till följande rader:

# vi /etc/nginx/nginx.conf

# Timeout vid läsning av klientförfrågans text
client_body_timeout 10;
# Timeout vid läsning av klientbegärans rubrik
client_header_timeout 10;
# Timeout efter vilken keep-alive-anslutningen med klienten inte kommer att stängas från serversidan
keepalive_timeout 5 5;
# Timeout när svar skickas till klienten
send_timeout 10;

Kontrollera antalet samtidiga anslutningar

För att skydda webbservern från överbelastning och försök att utföra en DoS-attack, lägg till följande rader i konfigurationen:

# vi /etc/nginx/nginx.conf

# Vi beskriver zonen (slimits) där sessionstillstånden kommer att lagras. En 1 MB-zon kan lagra cirka 32000 tillstånd, vi ställer in dess storlek till 5 MB
limit_zone slimits $binary_remote_addr 5m;
# Ställ in det maximala antalet samtidiga anslutningar för en session. I huvudsak anger detta nummer det maximala antalet anslutningar från en IP
limit_conn slimits 5;

Det första direktivet bör finnas i HTTP-sektionen, det andra i platsavsnittet. När antalet anslutningar överskrider gränserna kommer klienten att få meddelandet "Tjänst ej tillgänglig" med kod 503.

Tillåt endast anslutningar till din domän

Hackare kan använda bots för att skanna undernät och hitta sårbara webbservrar. Vanligtvis går bots helt enkelt genom IP-adressområden och letar efter öppna 80 portar och skickar en HEAD-begäran för att få information om webbservern (eller startsida). Du kan enkelt förhindra en sådan genomsökning genom att förbjuda åtkomst till servern via IP-adress (lägg till i platsundersektionen):

# vi /etc/nginx/nginx.conf

if ($host !~ ^(host.com|www.host.com)$) (
retur 444;
}

Begränsa antalet tillgängliga metoder för åtkomst till webbservern

Vissa bots använder olika metoder anropar servern för att försöka fastställa dess typ och/eller penetration, men RFC 2616 anger tydligt att webbservern inte behöver implementera dem alla, och metoder som inte stöds kanske helt enkelt inte bearbetas. Idag är det bara metoderna GET (dokumentbegäran), HEAD (serverhuvudbegäran) och POST (dokumentpubliceringsbegäran) som används, så alla andra kan smärtfritt inaktiveras genom att placera följande rader i serverdelen av konfigurationsfilen:

# vi /etc/nginx/nginx.conf

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

Stäng av botarna

Ett annat sätt att blockera bots, skannrar och andra onda andar är baserat på att bestämma typen av klient (user-agent). Det är inte särskilt effektivt, eftersom de flesta bots riktar sig till helt legitima webbläsare, men i vissa fall är det fortfarande användbart:

# vi /etc/nginx/nginx.conf

# Blockera nedladdningshanterare
if ($http_user_agent ~* LWP::Simple|BBBike|wget) (
retur 403;
}
# Blockera vissa typer av bots
if ($http_user_agent ~* msnbot|scrapbot) (
retur 403;
}

Blockera hänvisningsskräppost

Om din webbplats publicerar webbloggar i en allmänt tillgänglig form kan du lätt bli offer för hänvisningsskräppost (när skräppostrobotar kontaktar din server, vilket anger hänvisare i rubriken - adressen till den annonserade webbplatsen). Denna typ av spam kan lätt förstöra en webbplatss SEO-betyg, så den måste blockeras obligatorisk. Ett sätt att göra detta är att svartlista de vanligaste orden som finns i adresserna till annonserade webbplatser.

# vi /etc/nginx/nginx.conf

# Serversektion
if ($http_referer ~* (brudar|till salu|tjej|smycken|kärlek|nudit|ekologisk|poker|porr|sex|tonåring))
{
retur 403;
}

Blockera hotlink

En hotlink är inkluderingen av en bild (eller annat innehåll) från en annan webbplats på en sida. I grund och botten är detta stöld, eftersom bilden som du spenderade mer än en timme av din fritid på inte bara används fritt av andra, utan skapar också en belastning på din webbserver utan att ta besökare till den. För att bekämpa hotlinks räcker det att se till att bilder skickas till klienten endast om han begärde dem medan han redan var på webbplatsen (med andra ord, referens request header bör innehålla namnet på din webbplats). Lägg till följande rader i serverdelen av nginx.conf-konfigurationsfilen (host.com är adressen till din webbplats):

# vi /etc/nginx/nginx.conf

plats /bilder/ (
valid_referers inga blockerade www.host.com host.com;
if ($invalid_referer) (
retur 403;
}
}

Som ett alternativ kan du konfigurera servern att returnera en speciell banner med ett meddelande om stöld istället för den efterfrågade bilden. För att göra detta, ersätt raden "retur 403" med raden:

skriv om ^/images/uploads.*\.(gif|jpg|jpeg|png)$ http://www.host.com/banned.jpg sist

Skydda viktiga kataloger från främlingar

Precis som alla andra webbservrar låter nginx dig reglera åtkomst till kataloger baserat på IP-adresser och lösenord. Denna funktion kan användas för att blockera vissa delar av webbplatsen från nyfikna ögon. Till exempel att ta bort URI från världen utanför:

# vi /etc/nginx/nginx.conf

plats /uppladdningar/ (
# Tillåt endast åtkomst till maskiner på det lokala nätverket
tillåta 192.168.1.0/24;
# Låt oss döda alla andra
förneka alla;
}

Nu kommer endast lokala nätverksanvändare att ha tillgång till dokument i uppladdningskatalogen. För att ställa in ett lösenord måste du göra mer komplexa handlingar. Först måste du skapa en lösenordsfil som är privat för nginx och lägga till de nödvändiga användarna till den (som ett exempel, låt oss lägga till användaradmin):

# mkdir /etc/nginx/.htpasswd
# htpasswd -c /etc/nginx/.htpasswd/passwd admin

# vi /etc/nginx/nginx.conf

plats /admin/ (
auth_basic "Begränsad";
auth_basic_user_file /etc/nginx/.htpasswd/passwd;
}

Nya användare kan läggas till med följande kommando:

# htpasswd -s /etc/nginx/.htpasswd/passwd användare

Använd SSL

Om din webbplats fungerar med privat användardata, såsom kreditkortsnummer, lösenord från andra tjänster eller ger åtkomst till andra viktig information, som kan vara en välsmakande bit för tredje part, ta hand om kryptering. Nginx fungerar bra med SSL, och denna funktion bör inte försummas.

För att ställa in SSL-kryptering med nginx, följ bara några steg: enkla steg. Först måste du skapa ett certifikat med följande kommandosekvens:

# cd /etc/nginx
# openssl genrsa -des3 -out server.key 1024
# openssl req -ny -nyckel server.nyckel -out server.csr
# cp server.nyckel server.nyckel.org
# openssl rsa -in server.key.org -out server.key
# openssl x509 -req -days 365 -in server.csr -signkey server.key -out server.crt

Beskriv sedan certifikatet i nginx-konfigurationsfilen:

# vi /etc/nginx/nginx.conf

server(
servernamn host.com;
lyssna 443;
ssl på;
ssl_certifikat /etc/nginx/server.crt;
ssl_certifikatnyckel /etc/nginx/server.key;
access_log /etc/nginx/logs/ssl.access.log;
error_log /etc/nginx/logs/ssl.error.log;
}

Efter detta kan du starta om webbservern:

# /etc/init.d/nginx ladda om

Utan stöd från själva webbplatsen är det naturligtvis meningslöst att göra detta.

andra metoder

Ställ in rätt värden för systemvariabler

Öppna filen /etc/sysctl.conf och placera följande rader i den:

# vi /etc/sysctl.conf

# Skydd mot smurfattacker
net.ipv4.icmp_echo_ignore_broadcasts = 1
# Skydd mot ogiltiga ICMP-meddelanden
net.ipv4.icmp_ignore_bogus_error_responses = 1
# Skydd mot SYN översvämning
net.ipv4.tcp_syncookies = 1
# Inaktivera källdirigering
net.ipv4.conf.all.accept_source_route = 0
net.ipv4.conf.default.accept_source_route = 0
# Skydd mot spoofing
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1
# Vi är ingen router
net.ipv4.ip_forward = 0
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.default.send_redirects = 0
# Aktivera ExecShield
kernel.exec-shield = 1
kernel.randomize_va_space = 1
# Utöka utbudet av tillgängliga portar
net.ipv4.ip_local_port_range = 2000 65000
# Öka den maximala storleken på TCP-buffertar
net.ipv4.tcp_rmem = 4096 87380 8388608
net.ipv4.tcp_wmem = 4096 87380 8388608
net.core.rmem_max = 8388608
net.core.wmem_max = 8388608
net.core.netdev_max_backlog = 5000
net.ipv4.tcp_window_scaling = 1

Placera webbserverns rotkatalog på en dedikerad partition

Genom att placera rotkatalogen för webbservern i en dedikerad partition och förbjuda placeringen av körbara filer och enhetsfiler kommer du att skydda resten av systemet från alla som kan få åtkomst till roten på webbservern. I det här fallet bör posten i filen /etc/fstab se ut ungefär så här:

/dev/sda5 /nginx ext4 standardinställningar,nosuid,noexec,nodev 1 2

Placera nginx i en chroot/fängelsemiljö

Alla moderna *nix-system låter dig låsa applikationen i en isolerad exekveringsmiljö. I Linux kan du använda KVM-, Xen-, OpenVZ- och VServer-teknologier för detta, i FreeBSD - Jail, i Solaris - Zones. Om ingen av dessa tekniker är tillgängliga kan du lägga nginx i en klassisk chroot, som, även om den är mycket ömtålig, kan stoppa de flesta hackare.

Installera SELinux-regler för att skydda nginx

Ett bra alternativ isolerade miljöer föreställningar är lokala system intrångsdetektering och förebyggande verktyg som SELinux eller AppArmor. Om de är korrekt konfigurerade kan de förhindra försök att hacka webbservern. Som standard är ingen av dem konfigurerad att fungera tillsammans med nginx, dock inom ramen för projektet SELinuxNginx(http://sf.net/projects/selinuxnginx/) regler för SELinux har skapats som alla kan använda. Allt som återstår är att ladda ner och installera:

# tar -zxvf se-ngix_1_0_10.tar.gz
# cd se-ngix_1_0_10/nginx
# göra
# /usr/sbin/semodule -i nginx.pp

Brandväggsinstallation

Vanligtvis är nginx installerat på dedikerade maskiner redo för hög belastning, så det är ofta den enda nätverkstjänsten som körs på servern. För att säkra servern räcker det med att skapa en mycket liten uppsättning regler som öppnar portarna 80, 110 och 143 (om, så klart, nginx också ska fungera som en IMAP/POP3-proxy) och stänga allt annat från omvärlden .

Begränsa antalet anslutningar med en brandvägg

För en lätt laddad webbplats är det en bra idé att begränsa antalet anslutningsförsök från en enda IP-adress per minut. Detta kan skydda dig från vissa typer av DoS-attacker och brute force. På Linux kan detta göras med standardmodulen iptables/netfilter:

# iptables -A INPUT -p tcp --dport 80 -i eth0 \
-m stat --stat NYTT -m senaste --set
# iptables -A INPUT -p tcp --dport 80 -i eth0 \
-m state --state NYTT -m senaste --uppdatering \
--sekunder 60 --hitcount 15 -j DROP

Reglerna minskar gränsen för antalet anslutningar från en IP per minut till 15. Detsamma kan göras med pf:

# vi /etc/pf.conf

webserver_ip="1.1.1.1"
tabell envisas
blockera snabbt från
skicka in $ext_if proto tcp till $webserver_ip \
port www-flaggor S/SA behåll tillstånd \
(max-src-conn-100, max-src-conn-rate 15/60,\
överbelastning spola)

Utöver gränsen för antalet sekventiella anslutningar (15 per minut), sätter denna regel en ytterligare gräns för antalet samtidiga anslutningar lika med 100.

PHP-inställning

Om du använder nginx i kombination med PHP, glöm inte att konfigurera det också. Så här ska konfigurationsfilen /etc/php/php.ini för den säkra servern se ut:

# vi /etc/php/php.ini

# Inaktivera farliga funktioner
disable_functions = phpinfo, system, mail, exec
# Maximal körningstid för skript
max_execution_time = 30
# Maximal tid som skriptet kan ägna åt att bearbeta förfrågningsdata
max_input_time = 60
# Maximal mängd minne som allokerats till varje skript
memory_limit = 8M
# Maximal storlek på data som skickas till skriptet med POST-metoden
post_max_size = 8M
# Maximal storlek på uppladdade filer
upload_max_filesize = 2M
# Visa inte PHP-skriptfel för användare
display_errors = Av
# Aktivera felsäkert läge
safe_mode = På
# Aktivera SQL felsäkert läge
sql.safe_mode = På
# Tillåt att externa kommandon endast körs i den här katalogen
safe_mode_exec_dir = /sökväg/till/skyddad/katalog
# Skydda mot informationsläckage om PHP
expose_php = Av
# Vi för loggar
log_errors = På
# Förhindra att fjärrfiler öppnas
allow_url_fopen = Av

Slutsatser

Genom att tillämpa rekommendationerna som beskrivs i den här artikeln får du en mycket säkrare webbserver. Men kom ihåg att inte alla tekniker passar din konfiguration. Till exempel kan brute force-skydd baserat på att minska storleken på buffertar som allokeras av nginx för bearbetning av klientförfrågningar leda till en minskning av prestanda och i vissa fall till misslyckanden i bearbetningsförfrågningar. Att begränsa antalet anslutningar kommer att allvarligt påverka prestandan för även en måttligt laddad webbplats, men kommer att vara fördelaktigt om sidan har låg trafik. Kontrollera alltid hur ändringarna du gör påverkar webbsidans prestanda och allmänna hälsa.

Om dagens hjälte

Nginx är en av de mest kraftfulla och populära webbservrarna i världen. Enligt Netcraft används den för att stödja mer än 12 miljoner webbplatser runt om i världen, inklusive mastodonter som Rambler, Yandex, Begun, WordPress.com, Wrike, vkontakte.ru, megashara.com, Librusec och Taba.ru. Kompetent arkitektur baserad på multiplexeringsanslutningar med hjälp av systemsamtal select, epoll (Linux), kqueue (FreeBSD) och en minneshanteringsmekanism baserad på pooler (små buffertar från 1 till 16 KB), gör att nginx inte sjunker ens under mycket höga belastningar, tål över 10 000 samtidiga anslutningar (den s.k. C10K problem). Ursprungligen skriven av Igor Sysoev för Rambler och öppnade 2004 under en BSD-liknande licens.

I kontakt med