Nginx reverse proxy i HTTPS: sigurna objava aplikacija

Kada nekoliko web aplikacija radi na jednom Linux poslužitelju, reverse proxy omogućuje da se promet usmjeri prema pravom internom servisu. Nginx je jedan od popularnih alata za tu zadaću. Uz pravilno postavljen HTTPS može pojednostavniti objavu aplikacija, ali zahtijeva pažnju oko prosljeđivanja zaglavlja i mrežnih ograničenja.

Što radi reverse proxy?

Korisnik otvara javnu adresu, primjerice portal.example.com. Nginx prihvaća zahtjev i prosljeđuje ga internom Django aplikacijskom serveru koji možda sluša na lokalnoj adresi ili privatnom portu. Korisnik pritom ne mora znati detalje unutarnje infrastrukture.

Jedan proxy može usmjeravati više domena na različite servise, obrađivati TLS i posluživati statičke datoteke. Time se smanjuje potreba za izravnim izlaganjem svakog pojedinog aplikacijskog porta internetu.

Osnovni primjer konfiguracije

server {
    listen 443 ssl;
    server_name portal.example.com;
    ssl_certificate /etc/letsencrypt/live/portal.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/portal.example.com/privkey.pem;

    location / {
        proxy_pass http://127.0.0.1:8000;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

Primjer je ilustrativan i nije potpuna produkcijska konfiguracija. Potrebno je posebno postaviti preusmjeravanje HTTP-a na HTTPS, sigurnosne politike, obradu statičkih datoteka, vremenska ograničenja i odgovarajuća pravila vatrozida.

TLS i povjerenje između slojeva

Certifikat mora odgovarati domeni i biti redovito obnavljan. Pristup aplikacijskom serveru treba ograničiti na proxy, primjerice slušanjem samo na 127.0.0.1 ili privatnoj mreži. Ako Django koristi zaglavlja X-Forwarded-*, konfiguracija mora pouzdano razlikovati vrijednosti koje je postavio proxy od onih koje bi mogao podmetnuti klijent.

Kod Django postavke SECURE_PROXY_SSL_HEADER posebno je važna sigurnost lanca povjerenja. Ne uključujte je naslijepo ako klijent može samostalno pristupiti aplikaciji s proizvoljnim zaglavljima. Podesite i dozvoljene hostove te sigurne session i CSRF kolačiće.

Monitoring i održavanje

Pratite isteke certifikata, status aplikacijskih procesa, odgovore 5xx i trajanje zahtjeva. Proxy logovi pomažu utvrditi je li problem u mreži, aplikaciji ili vanjskom servisu. Nemojte bilježiti nepotrebne osjetljive podatke u URL-ovima i logovima.

Prije promjene konfiguracije provjerite sintaksu pomoću nginx -t, a zatim kontrolirano ponovno učitajte konfiguraciju. Čuvajte verzioniranu konfiguraciju i mogućnost brzog povrata.

Što proxy ne rješava?

Reverse proxy ne popravlja pogreške u aplikacijskim ovlastima, loše SQL upite ni nedostatak backupa. On je važan ulazni sloj infrastrukture koji treba biti usklađen sa sigurnosnim i operativnim planom cijelog sustava.

Najčešća pogreška pri postavljanju proxyja

Administrator pravilno konfigurira HTTPS na Nginxu, ali aplikacijski servis ostavi javno dostupan na drugom portu. Korisnik ili napadač tada može zaobići proxy i njegove provjere. Zato treba provjeriti stvarni mrežni pristup: aplikacija neka sluša lokalno ili na privatnoj mreži, a javni firewall neka dopušta samo nužne portove. Isto vrijedi za administracijske servise i bazu podataka.

Druga pogreška je nekontrolirano povjerenje u zaglavlja o izvornom protokolu. Ako aplikacija vjeruje proizvoljnom X-Forwarded-Proto od klijenta, može pogrešno zaključiti koristi li se sigurna veza. Takve postavke treba uskladiti s konkretnom mrežnom topologijom.

Česta pitanja

Mora li Nginx biti na istom serveru? Ne. Može biti zaseban proxy, uz odgovarajuću zaštitu veze prema aplikaciji.

Zamjenjuje li certifikat sigurnosne provjere? Ne. HTTPS štiti prijenos, ali ne ispravlja probleme prava pristupa.

Kako provjeriti novu konfiguraciju? Testirajte sintaksu, provjerite pristup domenama, interne portove i zapis pogrešaka prije konačnog puštanja u rad.

Provjera Nginx reverse proxy konfiguracije

Kod javno dostupne aplikacije prvi sloj zaštite obično se nalazi na mrežnoj granici. Reverse proxy treba provjeriti zajedno s aplikacijskim serverom i firewallom. Pogrešna konfiguracija može dovesti do javno dostupnih internih portova ili pogrešnog prepoznavanja protokola kojim je korisnik pristupio sustavu.

• Je li prema internetu izložen samo potreban HTTPS ulaz, dok aplikacijski proces i baza koriste lokalnu ili privatnu mrežu?
• Jesu li TLS certifikati valjani, obnova automatizirana i postoji li upozorenje prije njihova isteka?
• Može li korisnik zaobići Nginx i izravno pristupiti aplikacijskom portu s proizvoljnim zahtjevima i zaglavljima?
• Vjeruje li Django samo odgovarajućem proxyju pri obradi X-Forwarded-* zaglavlja i određivanju sigurnog protokola?
• Jesu li postavljena razumna ograničenja veličine zahtjeva, vremenskih ograničenja i zapisivanja osjetljivih podataka?
• Može li se prethodna konfiguracija brzo vratiti te provjerava li administrator sintaksu prije učitavanja promjene?

Tek kada javni i interni sloj rade usklađeno, reverse proxy ispunjava svoju operativnu i sigurnosnu svrhu.

Nakon promjene proxy konfiguracije korisno je testirati i pogrešna zaglavlja Host te neobične URL zahtjeve. Time se može otkriti nepravilno usmjeravanje na pogrešnu aplikaciju. Posebno provjerite očekivane redirekcije s HTTP-a na HTTPS i ponašanje svih korištenih poddomena.

Prije svake veće promjene napravite kratku inventuru postojećih web aplikacija, njihovih domena i internih portova. U složenijim okruženjima jedan pogrešan server_name ili proxy_pass može usmjeriti zahtjeve pogrešnom sustavu. Jednostavna dokumentacija tih veza čini naredne nadogradnje sigurnijima.