Mer än 50 % av trafiken över hela världen betjänas av Apache- och Nginx-paketteknik– webbservrar som har en öppen källa. Nginx är fronten, Apache är baksidan. Nginx är den första som accepterar användarförfrågningar och utfärdar det nödvändiga innehållet på dem - bilder, filer, skript. Heavy Apache sysslar i sin tur inte med detta, utan hanterar dynamik. Nginx proxyförfrågningar och returnerande svar. Detta paket är bra för stora webbplatser som besöks av många användare. För små webbplatser kommer detta paket inte att öka prestandan. Apache och Nginx minskar belastningen på servern i allmänhet, på grund av det faktum 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 delar många av samma funktioner. Var och en av webbservrarna har sina egna fördelar och dess användning beror på uppgiften. I den här artikeln Låt oss överväga varje teknik beroende på omfattningen. Artikeln kommer att vara användbar för ägare av virtuella och dedikerade fysiska servrar.

Funktionell och snabb Nginx släpptes 2004 och efter denna release började den bli populär. På grund av dess lätthet och skalbarhet fungerar den bra på vilken hårdvara som helst. Nginx används på två sätt: som en webbserver eller som en 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 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 över hela världen (till exempel Rambler, Yandex, Mail, Begun, WordPress.com, vk.com, Facebook, Rutracker.org), men Nginx är sämre än Apache i termer av popularitet. Varför är Apache så populär?

Apache webbserver – plattformsoberoende programvara som grundades 1995. Tack vare den stora dokumentationen och goda integrationen med programvara från tredje part har Apache blivit mycket populärt. Stöder följande operativsystem - 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 ger 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 behöver kraftfull kryptografiskt skydd data;
• möjligheten att skapa anpassade kataloger för webbplatsen;
• möjlighet att konfigurera virtuella värdar, med vilken du kan skapa flera virtuella på en fysisk server;
• håller register över vad som händer på din server;
• aktiva Respons med utvecklare och snabb lösning av fel i programvaran.

Men trots alla fördelar Apache webbserver något svårt att installera och använda, så inte alla nybörjare kommer att kunna hantera det. Men om ditt projekt behöver exakt denna programvara, kommer du att göra det rätt val till förmån för Apache.

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

Efter att ha läst för- och nackdelarna med Apache och Nginx kan du välja användbar lösning för din webbplats, beroende på vilka mål du eftersträvar. Men du kan behöva Apache + Nginx-paketet för prestation bästa resultat. Till exempel använder de ofta Nginx framför Apache som en omvänd proxy. Denna kombination gör att du kan hantera många konkurrenskraftiga förfrågningar. och sortera dem. De förfrågningar som ligger utanför Nginx makt skickas till Apache, vilket minskar belastningen på den senare. Feltoleransen ökar i detta fall. Innan du väljer en webbserver måste du genomföra obligatoriska tester av varje lösnings prestanda och kapacitet.

Om all teknik som stöds av HyperHost-hosting, mer detaljerat på.

Den här artikeln skapades för allmän bekantskap med möjligheterna med webblänkar. Apache-servrar och Nginx. 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. Även hos oss kan du alltid med gratis administration. Är allt teknisk support hosters är samma? Om funktionerna i gratis och betald administration i en speciell .

17249 gånger 10 gånger visats idag

14 augusti 2009 klockan 19:29

Konfigurera nginx

• Nginx

Ämne korrekt inställning nginx är väldigt stort, och jag är rädd att det inte passar in i ramen för en artikel om Habré. I den här texten har jag försökt beskriva övergripande struktur config, mer intressanta små saker och detaljer kanske kommer senare. :)

En bra utgångspunkt för att ställa in nginx är konfigurationen som följer med distributionen, men många av funktionerna på denna server nämns inte ens i den. Betydligt mer detaljerat exempel tillgänglig på Igor Sysoevs webbplats: sysoev.ru/nginx/docs/example.html . Men låt oss försöka bygga vår konfiguration från grunden, med en bro och poeter. :)

Låt oss börja med Allmänna Inställningar. Först anger vi användaren på uppdrag av vilken nginx kommer att köras (det fungerar inte bra som root, alla vet :))

Låt oss nu berätta för nginx hur många arbetsprocesser som ska skapas. Vanligtvis, bra val det finns ett antal processer lika med antalet processorkärnor på din server, men det är värt att experimentera med den här inställningen. Om en hög belastning förväntas HDD, kan du göra en process för varje fysisk hårddisk, eftersom allt arbete fortfarande begränsas av dess prestanda.

Arbetarprocesser 2;

Låt oss ange var felloggar ska skrivas. Sedan för individen virtuella servrar, kan denna parameter åsidosättas, så att endast "globala" fel kommer att skickas till denna logg, till exempel de som är relaterade till starten av servern.

Error_log /spool/logs/nginx/nginx.error_log meddelande; # aviseringsnivå "notice" kan naturligtvis ändras

Nu kommer det mycket intressanta avsnittet "händelser". Den kan ställas in högsta belopp anslutningar som en arbetsprocess kommer att bearbeta samtidigt, och metoden som kommer att användas för att ta emot asynkrona händelsemeddelanden i operativsystemet. Naturligtvis kan du bara välja de metoder som är tillgängliga på ditt operativsystem och som ingick vid sammanställningen.

Dessa inställningar kan ha en betydande inverkan på din servers prestanda. De måste väljas individuellt, beroende på operativsystem och hårdvara. Jag kan bara ge några allmänna regler.

Eventmoduler:
- select och poll är vanligtvis långsammare och belastar processorn ganska hårt, men de är tillgängliga nästan överallt och fungerar nästan alltid;
- kqueue och epoll är mer effektiva, men endast tillgängliga på FreeBSD respektive Linux 2.6;
- rtsig - snygg effektiv metod, och stöds även av mycket gamla Linux, men kan orsaka problem när stora nummer anslutningar;
- /dev/poll - så vitt jag vet fungerar det i en lite mer exotiska system, som Solaris, och är ganska effektiv i det;

worker_connections parameter:
- Det totala maximala antalet klienter som serveras kommer att vara lika med worker_processes * worker_connections;
– Kan ibland jobba i positiva sidanäven de mest extrema värdena, som 128 processer, 128 anslutningar per process eller 1 process, men med worker_connections=16384. I det senare fallet kommer du dock troligen att behöva ställa in operativsystemet.

Evenemang (
worker_connections 2048;
använd kqueue; # Vi har BSD :)
}

Nästa avsnitt är det största och innehåller det mest intressanta. Detta är en beskrivning av virtuella servrar och några parametrar som är gemensamma för dem alla. Jag kommer att sänka standardinställningar, som finns i varje konfiguration, till exempel sökvägar till loggar.

http(
# All kod nedan kommer att finnas i detta avsnitt %)
# ...
}

Inom detta avsnitt kan det finnas några ganska intressanta parametrar.

Sendfile-systemanropet är relativt nytt för Linux. Det låter dig skicka data till nätverket och kringgå steget att kopiera det till applikationens adressutrymme. I många fall förbättrar detta serverns prestanda avsevärt, så det är en bra idé att alltid ha alternativet sendfile aktiverat.

Parametern keepalive_timeout är ansvarig för maximal tid upprätthålla en Keepalive-anslutning, om användaren inte begär något på den. Tänk på hur förfrågningar skickas på din webbplats och fixa den här inställningen. För sajter som aktivt använder AJAX är det bättre att hålla anslutningen längre, för statiska sidor som användare kommer att läsa under lång tid är det bättre att koppla bort anslutningen tidigt. Tänk på att genom att upprätthålla en inaktiv keepalive-anslutning upptar du en anslutning som skulle kunna användas på annat sätt. :)

keepalive_timeout 15;

Separat är det värt att markera nginx proxyinställningarna. Oftast används nginx just som en proxyserver, så de är ganska viktiga. I synnerhet är det vettigt att ställa in buffertstorleken för proxybegäranden inte mindre än den förväntade storleken på svaret från backend-servern. Med långsamma (eller omvänt mycket snabba) backends är det vettigt att ändra timeouts för att vänta på svar från backend. Kom ihåg att ju längre dessa timeouts är, desto längre kommer din användare att vänta på ett svar, med backend-bromsar.

proxy_buffertar 8 64k;
proxy_intercept_errors på;
proxy_connect_timeout 1s;
proxy_read_timeout 3s;
proxy_send_timeout 3s;

Litet knep. Om nginx betjänar mer än en virtuell värd, är det vettigt att skapa en "virtuell standardvärd" som kommer att behandla förfrågningar i de fall servern inte kan hitta ett annat alternativ för värdhuvudet i klientförfrågan.

# virtuell standardvärd
server(
lyssna 80 standard;
servernamnlokalvärd;
förneka alla;
}

En (eller flera) "server"-sektioner kan följa. Var och en av dem beskriver en virtuell värd (oftast namnbaserad). För ägare av många webbplatser på samma värd, eller för värdar, kan det finnas något här, till exempel direktivet

Inkludera /spool/users/nginx/*.conf;

Resten kommer sannolikt att beskriva sin virtuella värd direkt i huvudkonfigurationen.

Server(
lyssna 80;

# Observera att flera namn kan anges i server_name-direktivet samtidigt.
servernamn minserver.ru minserver.com;
access_log /spool/logs/nginx/myserver.access_log tidsinställd;
error_log /spool/logs/nginx/myserver.error_log varning;
# ...

Ställ in kodningen för returen som standard.

Charset utf-8;

Och låt oss säga att vi inte vill acceptera förfrågningar från klienter som är längre än 1 megabyte.

Client_max_body_size 1m;

Låt oss aktivera SSI för servern och be att inte reservera mer än 1 kilobyte för SSI-variabler.

Si på;
ssi_value_length 1024;

Och slutligen kommer vi att beskriva två platser, varav en kommer att leda till backend, till Apache som körs på port 9999, och den andra för att ge statiska bilder från den lokala filsystem. För två platser är detta lite meningsfullt, men för fler av dem är det också vettigt att omedelbart definiera en variabel som lagrar serverns rotkatalog och sedan använda den i platsbeskrivningar.

Hej kära Habrahabr-användare. Min berättelse kommer att handla om hur man skapar förutsättningar för lokala webbutvecklingsprojekt i operativ system Ubuntu 16.04.1LTS.

I den här artikeln vill jag skingra och förklara eventuella svårigheter relaterat till att installera och konfigurera programvara som krävs för modern webbutveckling, som kan mötas av nybörjare och inte bara.

Teknik som kommer att användas i artikeln: nginx, php-fpm.

Innan jag börjar berättelsen vill jag notera att jag gjorde alla dessa åtgärder på ett "bart" system.
Jag kommer att arbeta med aptitude package manager. Jag rekommenderar också att du uppdaterar paketindexet och själva paketen innan du installerar programvaran. I den här artikeln kommer vi att göra dessa steg tillsammans.

Gå!

Installerar pakethanteraren fallenhet, uppdatera index och paket

Installera:

sudo apt installera aptitude
Vi uppdaterar indexet.

sudo aptitude uppdatering
Uppdatera paket (kommandot kommer att uppdatera alla paket för vilka det finns nya versioner, om det är nödvändigt att ta bort paket kommer det att utföras).

sudo aptitude full uppgradering

Installation och inställning nginx(version >= 1.10.0)

Vi installerar.

sudo aptitude installera nginx
Vi lanserar.

Sudo service nginx start
Vi kontrollerar versionen för att säkerställa att vi inte installerade den gamla, det vill säga under 1.10.0.

Vi har gjort installationen och lanseringen, låt oss nu gå till katalogen där vår nginx är installerad och titta på dess struktur. Nginx-katalogen finns i denna sökväg:

cd /etc/nginx/
Du kan se innehållet i katalogen med kommandot ls, med flaggorna -la kommer det att vara bekvämare att se innehållet i katalogen (i själva verket kan detta kommando med specifika flaggor beskrivas mer detaljerat och mer exakt, men vi har ett annat ämne idag).

Ls-la
Vi är intresserade av det här ögonblicket de två katalogerna du ser på skärmdumpen. Dessa är kataloger som är tillgängliga för webbplatser och kataloger som är aktiverade för webbplatser.

Låt oss gå in i katalogen som är tillgängliga för webbplatser och börja konfigurera vår virtuella värd (webbplats).

cd /etc/nginx/sites-available
Innan vi börjar skapa en konfigurationsfil, låt oss kontrollera vad som finns i vår denna katalog. I mitt fall är katalogen inte tom, den innehåller redan konfigurationsfiler, jag raderade dem för att inte vilseleda dig.

Viktig utvikning

När nginx-installationer"from scratch", nämligen "from scratch", sedan när du tar bort nginx med kommandot
sudo apt-get remove nginx eller sudo apt remove nginx konfigurationsfiler finns kvar, och om du plötsligt inte förstår varför nginx inte fungerar och vill installera om det (vanligtvis tar nybörjare till detta Linux-användare), sedan efter ominstallation kommer det inte att fungera korrekt, på grund av att de gamla konfigurationsfilerna (de raderas inte efter borttagning med kommandot remove) innehåller felaktiga inställningar, de måste tas bort eller konfigureras korrekt, först då kommer nginx arbete.

Jag rekommenderar att du tar bort med kommandot sudo apt-get purge nginx eller sudo apt purge nginx . Om du använder pakethanterare aptitude, sedan tar sudo aptitude purge nginx bort hela paketet, inklusive alla beroenden och konfigurationsfiler.

Det kommer att finnas en fil i den här katalogen som standard, som kallas standard. Den kommer att innehålla en konfigurationsfil med ett exempel, med kommentarer, du kan studera den när du vill, eller så kan du radera den helt (du kan alltid hänvisa till officiell dokumentation).

Ls-la

Låt oss skapa vår egen konfigurationsfil som matchar domännamnet på vår lokala webbplats (eller den riktiga, om du redan vet dess namn). Detta är bekvämt, i framtiden, när det kommer att finnas många konfigurationsfiler, kommer detta att rädda dig från förvirring i dem. Hos mig kommer den här filen att heta project.local.

Sudo touch project.local
Låt oss se vad som hände.

Låt oss nu öppna det i editorn, jag öppnar det i nano.

Sudo nano project.local
Vi ser att det är tomt. Låt oss nu gå vidare till bildandet av vår fil. Du måste ta med konfigurationen till formuläret enligt nedan. Jag kommer bara att beskriva de viktiga direktiven i denna fil, jag kommer inte att beskriva resten, eftersom detta inte är viktigt för tillfället, trots allt har vi ett ämne grundinställning. Dessa "hill"-inställningar räcker för att utveckla projekt lokalt, inte bara små utan också ganska stora. I de följande artiklarna kommer jag att beskriva varje direktiv som används separat (det är så här raderna kallas, till exempel server_name) i denna fil.

Se kommentarerna direkt konfigurationsfil.

Server (lyssna 80; # port lyssnar på nginx servernamn project.local; # Domän namn relaterad till strömmen virtuell värd root /home/stavanger/code/project.local; # katalogen som projektet ligger i, sökvägen till startpunktsindex index.php; # add_header Access-Control-Allow-Origin *; # servera statiska filer direkt plats ~* \.(jpg|jpeg|gif|css|png|js|ico|html)$ ( access_log off; expires max; log_not_found off; ) plats / ( # add_header Access-Control-Allow- Ursprung *; try_files $uri $uri/ /index.php?$query_string; ) plats ~* \.php$ ( try_files $uri = 404; fastcgi_split_path_info ^(.+\.php)(/.+)$; fastcgi_pass unix :/var/run/php/php7.0-fpm.sock; # connect php-fpm socket fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; inkludera fastcgi_params; ) plats ~ /\.ht (neka alla; ) )
Vi sparar filen. Nu måste vi kolla om det finns några fel i den. Vi kan göra det här som ett team.

Sudo nginx -t
Om vi ​​ser sådan information som i skärmdumpen, då är allt korrekt med oss, vi kan fortsätta konfigureringen. Om du får några fel är det värt att dubbelkolla konfigurationsfilen.

Nu måste vi aktivera konfigurationsfilen, i katalogen /etc/nginx/sites-enabled/ måste vi skapa en symbolisk länk (symbolsk länk). Om du hade nginx installerat från början, så har den här katalogen en symbollänk till standardfilen, som beskrevs ovan, du kan ta bort den om du inte behöver den. Vi går vidare till den nödvändiga katalogen.

cd /etc/nginx/sites-enabled/
Vi är nu i rätt katalog. Låt oss skapa vår symbollänk. För att skapa, använd kommandot ln med flaggan -s, så kommer vi att ange sökvägen till vår project.local config.

sudo ln -s /etc/nginx/sites-available/project.local
Låt oss titta på vår skapade symbollänk.

För att vara säker på att vi fortfarande gör allt rätt kommer vi att köra kommandot igen.

Fil värdar

Den här filen finns i /etc/hosts. Närvaron av poster i den låter dig köra nginx med localhost som domän. I den här filen kan du tilldela alternativa alias, till exempel för vårt projekt project.local kommer vi att tilldela domänen project.local.

Öppna filen i nanoredigeraren.

sudo nano /etc/hosts
Du kommer att ha annan information i den här filen, ignorera den. Du behöver bara lägga till en rad som i min skärmdump.

Installation php-fpm (>=7.0)

sudo aptitude installera php-fpm
Kontroll installerad version, för säkerhets skull, även om i Ubuntu 16.04.1 finns 7.0-versionen i förråden.

php-fpm7.0 -v

Vi ser till att allt är okej. Låt oss börja php-fpm.

sudo tjänst php7.0-fpm start
Om du redigerar inställningarna, glöm inte att starta om demonen. Det gör det. Men vi kommer inte att behöva det.

sudo service php7.0-fpm omstart
Detta slutför installationen och konfigurationen av php-fpm. Det är sant, det är allt. Detta är inte magiskt, sökvägen till php-fpm-socket har redan specificerats i konfigurationsfilen. Naturligtvis kan du behöva några php-tillägg för utveckling av personliga projekt, men du kan leverera dem efter behov.

Låt oss nu gå till katalogen med vårt projekt, jag har det på den här vägen.

Cd /home/stavanger/code/project.local
Låt oss gå upp till katalogen ovan och göra behörigheter 777 (det vill säga, vi kommer att göra det fullständiga rättigheter katalog med vårt projekt project.local). I framtiden kommer detta att rädda oss från onödiga problem.

Cd .. sudo chmod -R 777 project.local
Detta slutför mjukvaruinstallationen, låt oss skapa testfil i vår arbetskatalog project.local och se till att allt fungerar. Jag kommer att skapa en index.php-fil med detta innehåll.

Vi går till webbläsaren och ser att allt fungerar bra för oss! PHP-tolk ingår.

Med vänlig hälsning till läsarna, Stavanger.

En dedikerad nginx-baserad webbserver är ett utmärkt sätt att förbättra prestandan på webbplatser. När det gäller bearbetningshastighet för statiskt innehåll har den helt enkelt ingen motsvarighet: den tål lätt flera tusen samtidiga anslutningar och kan enkelt optimeras och anpassas till vilken konfiguration som helst. Men? nginx fungerar som en front-end för Apache och är den mest sårbara punkten i hela webbinfrastrukturen, så säkerheten för nginx måste ägnas särskild uppmärksamhet.

Den här artikeln är ett slags utbildningsprogram, eller, om du vill, en sammanfattning av alla tekniker för att förbättra säkerheten för nginx. Den kommer inte att innehålla teori, beskrivningar av grunderna för att sätta upp en webbserver och annat vatten. Istället får du en omfattande instruktionsguide som beskriver alla grundläggande steg du behöver ta för att få en riktigt säker webbserver.

Installation

Paketet nginx är tillgängligt förkompilerat för alla distributioner. Men genom att bygga servern själv kan du göra den mer kompakt och tillförlitlig, och du kan också ändra webbserverns hej-sträng för att avskräcka ointelligenta skriptbarn.

Ändra webbserverns Hello String

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 av nginx-modulerna ansluter till webbservern direkt vid kompileringstillfället, och någon av dem är potentiellt farlig. 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 en sådan situation.

Bygg med följande kommandon:

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

Så du kommer att få nginx med förinaktiverade (och i de flesta fall värdelösa) SSI (Server Side Includes) och Autoindex-moduler. För att ta reda på vilka moduler som säkert kan släppas från webbservern, kör konfigureringsskriptet med flaggan '-hjälp'.

Dissekera nginx.conf

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

Inaktivera serverversionsvisning på alla felsidor

Lägg till raden "server_tokens off" till filen nginx.conf. Detta kommer att få nginx att dölja typ och versionsinformation för webbservern på sidor som genereras som svar på en felaktig klientförfrågan.

Sätt upp stackfallskydd

Lägg till följande rader i serversektionen:

#vi /etc/nginx/nginx.conf

# Maximal buffertstorlek för att lagra klientbegäran
client_body_buffer_size 1K;
# Maximal buffertstorlek för lagring av klientförfrågningshuvuden
client_header_buffer_size 1k;
# Maximal storlek 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 en stor klientbegärans huvud
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, som var och en är storleken på en minnessida (för x86 är detta 4 KB). Buffertarna släpps varje gång anslutningen går till håll-live-tillståndet i slutet av en begäran. Två 1Kb-buffertar kan bara lagra 2Kb-URI, 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 av servern
keepalive_timeout 5 5;
# Timeout när ett 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

# Beskriv 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. Faktum är att detta nummer anger det maximala antalet anslutningar från en IP
limit_conn slimits 5;

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

Tillåt endast anslutningar till din domän

Angripare kan använda bots för att skanna undernät och hitta sårbara webbservrar. Vanligtvis går bots helt enkelt igenom IP-adressintervall och letar efter öppna 80 portar och skickar en HEAD-förfrågan om information om webbservern (eller hemsidan). Du kan enkelt förhindra en sådan genomsökning genom att inaktivera å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 för att kontakta servern för att försöka fastställa dess typ och/eller penetration, men RFC 2616 gör det klart att en webbserver inte krävs för att implementera dem alla, och metoder som inte stöds kanske helt enkelt inte hanteras. Idag är det bara metoderna GET (dokumentbegäran), HEAD (serverhuvudbegäran) och POST (dokumentbegäran) som används, så alla andra kan säkert inaktiveras genom att sätta följande rader i serverdelen av konfigurationsfilen:

#vi /etc/nginx/nginx.conf

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

Skicka iväg bots

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 klipper ner under helt legitima webbläsare, men i vissa fall är det fortfarande användbart:

#vi /etc/nginx/nginx.conf

# Blockerar 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 offentlig vy kan du lätt bli ett offer för hänvisningsskräppost (när skräppostrobotar kontaktar din server och anger adressen till den annonserade webbplatsen i hänvisningshuvudet). Denna typ av spam kan lätt förstöra en webbplatss SEO-rankning, så den måste blockeras utan att misslyckas. 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. Det är i grunden stöld, eftersom en bild som du har slösat bort timmar av din fritid på inte bara delas fritt av andra, utan belastar också din webbserver utan att föra besökare till den. För att bekämpa hotlinks räcker det att se till att bilderna ges 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;
}
}

Alternativt kan du ställa in servern att visa upp en anpassad stöldbanner istället för den begärda 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 kontrollera åtkomst till kataloger baserat på IP-adresser och lösenord. Den här funktionen kan användas för att stänga vissa delar av webbplatsen från nyfikna ögon. Till exempel, för att ta bort en URI från omvärlden:

#vi /etc/nginx/nginx.conf

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

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

# 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 arbetar med privata användardata, såsom kreditkortsnummer, lösenord för andra tjänster, eller ger tillgång till annan viktig information som kan bli en god 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 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.key server.key.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 det kan du starta om webbservern:

# /etc/init.d/nginx ladda om

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

andra metoder

Ställ in rätt systemvariabler

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

#vi /etc/sysctl.conf

# Skydd mot smurfattacker
net.ipv4.icmp_echo_ignore_broadcasts = 1
# Skydd mot dåliga ICMP-meddelanden
net.ipv4.icmp_ignore_bogus_error_responses = 1
# SYN översvämningsskydd
net.ipv4.tcp_synccookies=1
# Inaktivera källdirigering
net.ipv4.conf.all.accept_source_route = 0
net.ipv4.conf.default.accept_source_route = 0
# Spoofing skydd
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 rotkatalogen för webbservern på en dedikerad partition

Genom att placera webbserverns rotkatalog på en dedikerad partition och inte tillåta att körbara filer och enhetsfiler placeras på den, skyddar du resten av systemet från alla som kan få tillgång till webbserverns rot. Posten i filen /etc/fstab bör 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ö. På Linux kan du använda KVM-, Xen-, OpenVZ- och VServer-teknologier för detta, på FreeBSD - Jail, på Solaris - Zones. Om ingen av dessa teknologier är tillgängliga kan du lägga nginx i en klassisk chroot, som, även om den är mycket ömtålig, kommer att stoppa de flesta kex.

Ställ in SELinux-regler för att säkra nginx

Ett bra alternativ till körtider i sandlåde är lokal intrångsdetektering och förebyggande system som SELinux eller AppArmor. Rätt konfigurerade kan de förhindra försök att hacka sig in på webbservern. Som standard är ingen av dem konfigurerad att fungera tillsammans med nginx, dock inom projektet SELinuxNginx(http://sf.net/projects/selinuxnginx/) regler för SELinux har skapats som alla kan använda. Det återstår bara 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äggsinställningar

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 (såvida inte nginx naturligtvis 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 webbplats som inte är särskilt upptagen är det en bra idé att begränsa antalet anslutningsförsök per minut från samma IP-adress. 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 state --state 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 skär ner gränsen för antalet anslutningar från en IP per minut till 15. Du kan göra samma sak 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-rate 100, max-src-conn-rate 15/60, \
överbelastning spola)

Utöver gränsen för antalet på varandra följande 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 ställa in det också. Så här ska /etc/php/php.ini-konfigurationsfilen 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
# Den maximala tid som skriptet kan spendera på att bearbeta förfrågningsdata
max_input_time = 60
# Maximal mängd minne som allokerats till varje skript
memory_limit = 8M
# Den maximala storleken 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
# Skyddar mot läckage av information om PHP
expose_php = Av
# Loggning
log_errors = På
# Förhindra att fjärrfiler öppnas
allow_url_fopen = Av

Slutsatser

Genom att tillämpa rekommendationerna som beskrivs i 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å buffertarna som allokeras av nginx för att bearbeta klientförfrågningar leda till sämre prestanda och i vissa fall till misslyckanden i bearbetningsförfrågningar. Att begränsa antalet anslutningar kommer att skada prestandan för även en måttligt laddad webbplats, men kommer att vara fördelaktigt om sidan har ett lågt trafikflöde. Kontrollera alltid hur dina ändringar påverkar webbsidans prestanda och allmänna hälsa.

Om dagens hjälte

Nginx är en av de snabbaste och mest populära webbservrarna i världen. Enligt Netcraft används den för att driva över 12 miljoner webbplatser världen över, inklusive mastodonter som Rambler, Yandex, Begun, WordPress.com, Wrike, vkontakte.ru, megashara.com, Librusek och Taba.ru. En smart arkitektur baserad på anslutningsmultiplex med hjälp av select, epoll (Linux), kqueue (FreeBSD) systemanrop och en poolbaserad minneshanteringsmekanism (små buffertar från 1 till 16 KB) gör att nginx inte sjunker även under mycket höga belastningar, klarar över 10 000 samtidiga anslutningar (så kallat C10K-problem). Ursprungligen skriven av Igor Sysoev för Rambler och släpptes 2004 under en BSD-liknande licens.

I kontakt med

För tillfället har två webbservrar vunnit mest popularitet. Dessa är Apache och Ngnix. Var och en av dem har sina för- och nackdelar. Apache utvecklades redan 1995 och alla tänkbara användarbehov togs inte hänsyn till under utvecklingen, den förbrukar mycket minne och systemresurser, men den är lätt att konfigurera. Nginx utvecklades lite senare under 2002, och tog redan hänsyn till Apaches fel och fokuserade på maximal prestanda.

Vi kommer inte att fördjupa oss i för- och nackdelarna med dessa två webbservrar i detalj. Var och en av dem har sitt eget användningsområde. Denna handledning kommer att täcka installationen av Nginx Ubuntu 16.04. Även om jag kommer att prata om Ubuntu 16.04, kommer stegen att fungera för andra distributioner också. Nginx-inställningen är densamma överallt, bara installationskommandot är annorlunda.

Det första steget är att installera själva webbservern i systemet. Programmet finns i de officiella arkiven, men dess version är redan lite föråldrad, så om du vill ha den senaste versionen måste du lägga till PPA:

sudo apt-add-repository ppa:nginx/stable

Nu är version 1.10.0 tillgänglig i de officiella arkiven, och 1.10.1 är redan tillgänglig i den stabila PPA. Om du inte behöver en version kan du klara dig utan PPA. Uppdatera sedan paketlistorna från arkiven:

Och installera ngix:

sudo apt installera nginx

När installationen av Nginx-servern är klar, lägg till programmet till start så att det startar automatiskt:

sudo systemctl aktivera nginx

Om du öppnar en webbläsare just nu kommer du att se nginx köra, men vi måste fortfarande konfigurera den.

Konfigurera Nginx Ubuntu

Att ställa in Nginx Ubuntu är mycket mer komplicerat än Apache. Här kommer vi inte att överväga alla alternativ och funktioner i programmet, men vi kommer bara att prata om de viktigaste. Det finns olika konfigurationer där Nginx används som proxyserver och Apache är huvudservern, men vi kommer inte att vara intresserade av detta. Vi måste installera Nginx som en fristående webbserver.

Nginx-inställningarna är väldigt olika här, det finns bara en huvudkonfigurationsfil och filer för virtuella värdar. Konfiguration från varje katalog, som i Apache, stöds inte.

• /etc/nginx/nginx.conf- huvudkonfigurationsfil
• /etc/nginx/sites-available/*- Konfigurationsfiler för virtuella värdar, med andra ord för varje plats.
• /etc/nginx/sites-enabled/*- Konfigurationsfiler för aktiverade webbplatser.

Egentligen läses konfigurationsfilerna för virtuella värdar bara från den webbplatsaktiverade katalogen, men den innehåller länkar till tillgängliga webbplatser. Ett sådant system uppfanns för att göra det möjligt att tillfälligt inaktivera vissa webbplatser utan att radera deras konfiguration. Alla andra filer innehåller endast variabeldeklarationer och standardinställningar som inte behöver ändras. När det gäller nginx.conf är alla filer från sites-enables inkluderade i den, och därför kan de innehålla exakt samma instruktioner. Låt oss nu titta på huvudkonfigurationsfilen:

sudo vi /etc/nginx/nginx.conf

Som du kan se är filen uppdelad i sektioner. Den allmänna strukturen är:

globala alternativ
evenemang()
http(
server(
plats()
}
server()
}
post()

• globala alternativ ansvarig för driften av hela programmet.
• evenemang- det här avsnittet innehåller inställningar för att arbeta med nätverket.
• http- innehåller webbserverinställningar. Bör innehålla en serversektion för att finjustera varje webbplats.
• server- det här avsnittet innehåller inställningarna för varje webbplats som finns på webbservern.
• plats- Platssektionen kan endast placeras inuti serversektionen och innehåller endast inställningar för en specifik begäran.
• post- innehåller proxyinställningar för e-post.

Innan vi går vidare till alternativen måste vi säga några fler ord om syntaxen för raden i konfigurationsfilen. Det ser ut så här:

parametervärde extra_värde...;

Raden måste nödvändigtvis sluta med ";", och alla öppna parenteser ( måste vara stängda.

Nu när du har utforskat den globala strukturen lite, är det dags att titta på själva parametrarna. Det finns inte så många globala alternativ:

• användare- användaren för vilken programmet kommer att köras.
• arbetarprocesser- ställer in hur många processer du behöver köra för att parallellisera programmet, du behöver inte köra fler processer än du har kärnor. Du kan ställa in parametern bil och sedan kommer programmet att bestämma detta nummer själv.
• pid= program pid-fil.
• worker_rlimit_nofile- indikerar det maximala antalet filer som programmet kan öppna. Beräknat som worker_processes * worker_connections* 2.

Vi är klara med de globala alternativen, det fanns inte så många av dem och de är inte så intressanta. Mycket mer intressant när det gäller att optimera alternativet från evenemangssektionen:

• worker_connections- antalet anslutningar som programmet kan bearbeta samtidigt på en process. Om vi ​​multiplicerar worker_process med denna parameter kommer vi att få det maximala antalet användare som kan ansluta till servern samtidigt. Det rekommenderas att ställa in värdet från 1024 till 4048.
• multi_accept- tillåt att ta emot många anslutningar samtidigt, ställ in parametern på eller av.
• använda sig av- ett sätt att arbeta med nätverksstacken. Standard är poll, men på Linux är det mer effektivt att använda epoll.

• skicka Fil- använd sändningsmetoden för sendfildata. på värde.
• tcp_nodelay, tcp_nopush- skicka rubriker och början av filen i ett paket. på värde.
• keepalive_timeout- timeout för att vänta innan Keepalive-anslutningen avslutas, standard är 65, men kan reduceras till 10 sekunder.
• keepalive_requests- Det maximala antalet keepalive-anslutningar från en klient, 100 rekommenderas.
• reset_timedout_connection- koppla från anslutningar efter timeout. på värde.
• open_file_cache- cacheinformation om öppna filer. Konfigurationsraden ser ut så här: open_file_cache max=200000 inactive=20s; max - det maximala antalet filer i cachen, cachningstid.
• open_file_cache_valid- indikerar efter vilken tid det är nödvändigt att radera information från cachen. Till exempel: open_file_cache_valid 30s;
• open_file_cache_min_uses- cacheinformation om filer som har öppnats minst det angivna antalet gånger.
• open_file_cache_errors- cacheinformation om saknade filer, värde på.

Huvudparametrarna har beaktats. Dessa inställningar hjälper dig att få mer prestanda från nginx. Vi kommer att överväga server- och platssektionerna i den virtuella värdkonfigurationen.

Konfigurera Gzip-komprimering

Innehållskomprimering är nödvändig för att minska storleken på data som laddas ner av webbläsaren. Detta påskyndar laddningen av webbplatsen, men lägger till ytterligare belastning på serverns processor. För att aktivera komprimering i http-sektionen måste du lägga till parametern:

Detta direktiv kan också användas i serversektionen, i vilket fall det bara fungerar för den angivna virtuella domänen. Konfigurera sedan komprimeringsinställningarna konfigureras med hjälp av följande alternativ:

• gzip_min_length- minsta sidlängd i byte vid vilken komprimering ska användas, till exempel 1000 (1 kb)
• gzip_proxied- om det är nödvändigt att komprimera fullmaktsförfrågningar, någon säger att allt ska komprimeras.
• gzip_typer- filtyper som ska komprimeras, till exempel: text/vanligt program/xml-program/x-javascript text/javascript text/css text/json;
• gzip_disable "msie6"- i IE 6 stöds inte komprimering, så inaktivera den.
• gzip_comp_level- komprimeringsnivå, alternativ från 1 till 10. 1 - minimum, 10 - maximal komprimering.

Konfigurera virtuella värdar

Som du vet kan en server vara värd för flera webbplatser. Alla förfrågningar kommer till serverns ip, och nginx bestämmer redan vilket innehåll som behöver returneras baserat på domänen. För att nginx ska veta vilken domän den tillhör måste du konfigurera virtuella värdar. Varje värd placeras vanligtvis i en separat fil. Värdkonfigurationen finns i serversektionen, men eftersom alla filer från webbplatser som är aktiverade importeras till http-sektionen, bryts inte logiken i konfigurationsfilstrukturen.

Tänk på en exempelinställning:

vi /etc/nginx/sites-enabled/site.conf

• lyssna 80- anger att vänta på en anslutning på port 80, kan också innehålla alternativet standardserver, vilket innebär att denna domän kommer att öppnas om domänen inte angavs i begäran.
• root /var/www/html- katalogen där webbplatsfilerna finns.
• index index.html- sidan som öppnas som standard.
• server namn- webbplatsens domännamn.
• access_log- en fil för att skriva en logg över förfrågningar till servern, kan användas både globalt i http-sektionen och för en specifik filtyp på platsen.
• felloggen- webbserverfellogg, kan ta en extra parameter som anger detaljerna i loggen. warn - maximum, crit - endast kritiska fel.

Dessa är alla grundläggande inställningar för den virtuella värden, varefter den redan kommer att fungera. Men det finns också en platssektion som låter dig konfigurera serverbeteendet för vissa kataloger och filer. Syntaxen för plats är:

platsadress()

Adressen kan antingen vara en direkt fråga i förhållande till serverroten eller reguljära uttryck. För att använda reguljära uttryck föregås det av tecknet "~". Låt oss titta på exempel nedan, men låt oss nu titta på möjliga direktiv:

• tillåta- tillåt åtkomst till platsen för användare, alla - alla, du kan också ange ip eller subnät.
• förneka- neka tillgång till platsen, alla - för alla.
• prova filer- försöker öppna filer i en viss ordning, öppnar den första filen som hittas. Till exempel denna konstruktion: $uri $uri/index.html $uri.html =404; försöker först öppna $uri, sedan index.html, om $uri.html inte hittas, och sedan, om ingen av de prepositionerade filerna existerar, ger ett 404-fel.
• löper ut- ställer in tiden för webbläsaren att cache det givna elementet, till exempel 1d - en dag, 2h - två timmar, 30s - 30 sekunder.

Utöver dessa huvuddirektiv kan andra användas här. Se den officiella dokumentationen för mer information. Låt oss titta på ett par exempel:

Logga inte favicon:

plats = /favicon.ico (
log_not_found off;
access_logoff;
}

Neka åtkomst till filer som börjar med en punkt:

plats ~ /\. (
förneka alla;
}

Cachelagra vanliga filer i 90 dagar:

plats ~* ^.+\.(ogg|ogv|svg|svgz|eot|otf|woff|mp4|ttf|rss|atom|jpg|jpeg|gif|png|ico|zip|tgz|gz|rar|bz2 |doc|xls|exe|ppt|tar|midi|wav|bmp|rtf)$ (
access_logoff; log_not_found off; går ut 90d;