Kuidas seadistada Dockeri, Nginxi ja Letsencryptiga lihtne ja turvaline vastupidine puhverserver

Sissejuhatus

Kas olete kunagi proovinud kodus mingit serverit seadistada? Kus peate iga teenuse jaoks uue sadama avama? Ja peate meeles pidama, milline port millisesse teenusesse läheb ja mis on teie kodu ip? See kindlasti töötab ja inimesed on seda teinud kõige kauem.

Kas poleks siiski tore sisestada plex.example.com ja teil oleks kohe juurdepääs oma meediumiserverile? Täpselt seda teeb teie jaoks vastupidine puhverserver ja kombineerides seda Dockeriga, on see lihtsam kui kunagi varem.

Eeldused

Docker ja Docker-Compose

Teil peaks olema Dockeri versioon 17.12.0+ ja Compose versioon 1.21.0+.

Domeen

Teil peaks olema seadistatud domeen ja sellega peaks olema seotud SSL-sertifikaat. Kui teil seda pole, järgige siin olevat juhendit, kuidas LetsEncryptiga tasuta saada.

Mida see artikkel hõlmab

Olen veendunud, et saan aru, mida teete. Oli aeg, kus järgisin juhendeid ja mul polnud aimugi, kuidas tõrkeid lahendada. Kui soovite seda teha just nii, siis siin on suurepärane juhend, mis käsitleb selle seadistamist. Kuigi minu artiklid on pikad, peaksite lõpuks mõistma, kuidas see kõik töötab.

Siit saate teada, mis on vastupidine puhverserver, kuidas seda seadistada ja kuidas seda turvata. Annan endast parima, et jagada teema jaotisteks, mis on jagatud päistega, nii et hüpake julgelt sektsioonist üle, kui soovite. Soovitan enne selle seadistamise alustamist kogu artikkel üks kord läbi lugeda.

Mis on vastupidine puhverserver?

Tavaline puhverserver

Alustame tavalise puhverserveri mõistest. Kuigi see on termin, mis on tehnikakogukonnas väga levinud, pole see ainus koht, mida seda kasutatakse. Puhverserver tähendab, et teave läheb enne asukohta jõudmist läbi kolmanda osapoole.

Oletame, et te ei soovi, et teenus teaks teie IP-d, võite kasutada puhverserverit. Puhverserver on spetsiaalselt selleks loodud server. Kui teie kasutatav puhverserver asub näiteks Amsterdamis, on välismaailmale kuvatav IP IP Amsterdami serverist. Ainult need, kes teavad teie IP-d, kontrollivad puhverserverit.

Tagurpidi puhverserver

Lihtsateks terminiteks jaotamiseks lisab puhverserver kihi maskeerimist. See on sama mõiste vastupidises puhverserveris, välja arvatud selle asemel, et maskeerida väljaminevaid ühendusi (pääsete juurde veebiserverile), maskeeritakse sissetulevad ühendused (inimesed, kes pääsevad juurde teie veebiserverile). Esitate lihtsalt sellise URL-i nagu example.com ja alati, kui inimesed sellele URL-ile juurde pääsevad, hoolitseb teie pöördproxy puhverserveri eest.

Oletame, et teie sisevõrgus on seadistatud kaks serverit. SERVER1 on 192.168.1.10 ja Server2 on 192.168.1.20. Praegu saadab teie vastupidine puhverserver saidilt example.com päringud Server1-le. Ühel päeval on teil veebilehel mõned värskendused. Selle asemel, et veebisait hoolduseks maha võtta, teete lihtsalt uue seadistuse Server2-s. Kui olete valmis, muudate lihtsalt ühe rea oma vastupidises puhverserveris ja nüüd saadetakse taotlused Server2-le. Eeldades, et vastupidine puhverserver on õigesti seadistatud, ei tohiks teil seisakuid olla.

Kuid ehk on vastupidise puhverserveri suurim eelis see, et teil võivad olla teenused, mis töötavad paljudes sadamates, kuid peate avama ainult vastavalt 80 ja 443, HTTP ja HTTPS. Kõik taotlused tulevad teie võrku nendes kahes pordis ja ülejäänud puhverserver hoolitseb ülejäänud osa eest. See kõik on mõttekas, kui hakkame puhverserverit seadistama.

Konteineri seadistamine

Mida teha

docker-compose.yaml:

version: '3' services: reverse: container_name: reverse hostname: reverse image: nginx ports: - 80:80 - 443:443 volumes: - :/etc/nginx - :/etc/ssl/private

Kõigepealt peaksite lisama uue teenuse oma dokkija koostamise faili. Võite seda nimetada nii, nagu soovite, antud juhul olen valinud vastupidise . Siin valisin lihtsalt pildiks nginxi , kuid tootmiskeskkonnas on tavaliselt soovitatav versioon välja anda juhul, kui tulevastes värskendustes on kunagi mingeid muudatusi.

Siis peaksite köitma kaks kausta. / etc / nginx on koht, kus kõik teie konfiguratsioonifailid on salvestatud, ja / etc / ssl / private on koht, kus teie SSL-sertifikaadid. On väga oluline, et teie konfiguratsioonikausta EI eksisteeriks hostil esmakordsel konteineri käivitamisel. Kui käivitate konteineri dokkeri koostamise kaudu, loob see kausta automaatselt ja täidab selle konteineri sisuga. Kui olete oma hostile loonud tühja konfiguratsioonikausta, ühendab see selle ja konteineris olev kaust on tühi.

Miks see töötab?

Selles osas pole palju. Enamasti on see nii, nagu alustaksite mõnda muud konteinerit dokk-komponeerimisega. Siin peaksite märkama, et olete siduvad pordid 80 ja 443. Siit tulevad kõik taotlused ja need edastatakse mis tahes teenusele, mille määrate.

Nginxi seadistamine

Mida teha

Nüüd peaks teie hostil olema konfiguratsioonikaust. Sellesse kataloogi vahetades peaksite nägema hulga erinevaid faile ja kausta nimega conf.d. Selles asuvad conf.dkõik teie konfiguratsioonifailid. Praegu on üks default.conffail, võite jätkata ja kustutada.

Ikka sees olles conf.dlooge kaks kausta: sites-availableja sites-enabled. Navigeerige sites-availableoma esimese konfiguratsioonifaili ja looge see. Siin seadistame Plexi kirje, kuid võite soovi korral kasutada mõnda muud teenust, mille olete seadistanud. Tegelikult pole vahet, kuidas faili nimetatakse, aga eelistan seda nimetada plex.conf.

Nüüd avage fail ja sisestage järgmine:

upstream plex { server plex:32400; } server { listen 80; server_name plex.example.com; location / { proxy_pass //plex; } }

Minge sites-enabledkataloogi ja sisestage järgmine käsk:

ln -s ../sites-available/plex.conf .

See loob sümboolse lingi teises kaustas olevale failile. Nüüd on jäänud ainult üks asi, see on nginx.conffaili muutmine konfiguratsioonikaustas. Kui avate faili, peaksite viimase reana nägema järgmist:

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

Muutke see järgmiseks:

include /etc/nginx/conf.d/sites-enabled/*.conf;

In order to get the reverse proxy to actually work, we need to reload the nginx service inside the container. From the host, run docker exec nginx -t. This will run a syntax checker against your configuration files. This should output that the syntax is ok. Now run docker exec nginx -s reload. This will send a signal to the nginx process that it should reload, and congratulations! You now have a running reverse proxy, and should be able to access your server at plex.example.com (assuming that you have forwarded port 80 to your host in your router).

Even though your reverse proxy is working, you are running on HTTP, which provides no encryption whatsoever. The next part will be how to secure your proxy, and get a perfect score on SSL Labs.

Why it Works

The Configuration File

As you can see, the plex.conf file consists of two parts. An upstream part and a server part. Let’s start with the server part. This is where you are defining the port receiving the incoming requests, what domain this configuration should match, and where it should be sent to.

The way this server is being set up, you should make a file for each service that you want to proxy requests to, so obviously you need some way to distinguish which file to receive each request. This is what the server-name directive does. Below that we have the location directive.

In our case we only need one location, however you can have as many location directives as you want. Imagine you have a website with a frontend and a backend. Depending on the infrastructure you’re using, you’ll have the frontend as one container and the backend as another container. You could then have location / {} which will send requests to the frontend, and location /api/ {} which will send requests to the backend. Suddenly you have multiple services running on a single memorable domain.

As for the upstream part, that can be used for load-balancing. If you’re interested in learning more about how that works, you can look at the official docs here. For our simple case, you just define the hostname or ip address of the service you want to proxy to, and what port is should be proxied to, and then refer to the upstream name in the location directive.

Hostname Vs. IP Address

To understand what a hostname is, let’s make an example. Say you are on your home network 192.168.1.0. You then set up a server on 192.168.1.10 and run Plex on it. You can now access Plex on 192.168.1.10:32400, as long as you are still on the same network. Another possibility is to give the server a hostname. In this case we’ll give it the hostname plex. Now you can access Plex by entering plex:32400 in your browser!

This same concept was introduced to docker-compose in version 3. If you look at the docker-compose file earlier in this article, you’ll notice that I gave it a hostname: reverse directive. Now all other containers can access my reverse proxy by its hostname. One thing that’s very important to note, is that the service name has to be the same as the hostname. This is something that the creators of docker-compose chose to impose.

Another really important thing to remember, is that by default docker containers are put on their own network. This means that you won’t be able to access your container by it’s hostname, if you’re sitting on your laptop on your host network. It is only the containers that are able to access each other through their hostname.

So to sum it up and make it really clear. In your docker-compose file, add the hostname directive to your services. Most of the time your containers will get a new IP every time you restart the container, so referring to it via hostname, means it doesn’t matter what IP your container is getting.

Sites-available & Sites-enabled

Why are we creating the sites-available and sites-enabled directories? This is not something of my creation. If you install Nginx on a server, you will see that it comes with these folders. However because Docker is built with microservices in mind, where one container should only ever do one thing, these folders are omitted in the container. We’re recreating them again, because of how we’re using the container.

And yes, you could definitely just make a sites-enabled folder, or directly host your configuration files in conf.d. Doing it this way, enables you to have passive configuration laying around. Say that you are doing maintenance, and don’t want to have the service active; you simply remove the symbolic link, and put it back when you want the service active again.

Symbolic Links

Symbolic links are a very powerful feature of the operating system. I had personally never used them before setting up an Nginx server, but since then I’ve been using them everywhere I can. Say you are working on 5 different projects, but all these projects use the same file in some way. You can either copy the file into every project, and refer to it directly, or you can place the file in one place, and in those 5 projects make symlinks to that file.

This gives two advantages: you take up 4 times less space than you otherwise would have, and then the most powerful of them all; change the file in one place, and it changes in all 5 projects at once! This was a bit of a sidestep, but I think it’s worth mentioning.

Securing Nginx Proxy

What to Do

Go to your config folder, and create 3 files and fill them with the following input:

common.conf:

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always; add_header X-Frame-Options SAMEORIGIN; add_header X-Content-Type-Options nosniff; add_header X-XSS-Protection "1; mode=block";

common_location.conf:

proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_set_header Host $host; proxy_set_header X-Forwarded-Host $host; proxy_set_header X-Forwarded-Port $server_port;

ssl.conf:

ssl_protocols TLSv1 TLSv1.1 TLSv1.2; ssl_ecdh_curve secp384r1; ssl_ciphers "ECDHE-RSA-AES256-GCM-SHA512:DHE-RSA-AES256-GCM-SHA512:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384 OLD_TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 OLD_TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256"; ssl_prefer_server_ciphers on; ssl_dhparam /etc/nginx/dhparams.pem; ssl_certificate /etc/ssl/private/fullchain.pem; ssl_certificate_key /etc/ssl/private/privkey.pem; ssl_session_timeout 10m; ssl_session_cache shared:SSL:10m; ssl_session_tickets off; ssl_stapling on; ssl_stapling_verify on;

Now open the plex.conf file, and change it to the following (notice lines 6, 9, 10 & 14):

upstream plex { server plex:32400; } server { listen 443 ssl; server_name plex.example.com; include common.conf; include /etc/nginx/ssl.conf; location / { proxy_pass //plex; include common_location.conf; } }

Now go back to the root of your config folder, and run the following command:

openssl dhparam -out dhparams.pem 4096

This will take a long time to complete, even up to an hour in some cases.

If you followed my article on getting a LetsEncrypt SSL Certificate, your certificates should be located in /etc/letsencrypt/live// .

When I helped a friend set this up on his system, we ran into some problems where it couldn’t open the files when they were located in that directory. Most likely the cause of some permissions problems. The easy solution to this is to make an SSL directory, like /certs, and then mount that to the Nginx container’s /etc/ssl/private folder. In the newly created folder, you should then make symbolic links, to the certs in your LetsEncrypt’s config folder.

When the openssl command is done running, you should run the docker exec nginx -t to make sure that all the syntax is correct, and then reload it by running docker exec nginx -s reload. At this point everything should be running, and you now have a working and perfectly secure reverse proxy!

Why it Works

Looking in the plex.conf file, there is only one major change, and that is what port the reverse proxy is listening on, and telling it that it’s an ssl connection. Then there are 3 places where we’re including the 3 other files we made. While SSL is kind of secure by itself, these other files make it even more secure. However if for some reason you don’t want to include these files, you need to move the ssl-certificate and ssl-certificate-keyinside the .conf file. These are required to have, in order for an HTTPS connection to work.

Common.conf

Looking in the common.conf file, we add 4 different headers. Headers are something that the server sends to the browser on every response. These headers tell the browser to act a certain way, and it is then up to the browser to enforce these headers.

Strict-Transport-Security (HSTS)

This header tells the browser that connections should be made over HTTPS. When this header has been added, the browser won’t let you make plain HTTP connection to the server, ensuring that all communication is secure.

X-Frame-Options

When specifying this header, you are specifying whether or not other sites can embed your content into their sites. This can help avoid clickjacking attacks.

X-Content-Type-Options

Say you have a site where users can upload files. There’s not enough validation on the files, so a user successfully uploads a php file to the server, where the server is expecting an image to be uploaded. The attacker may then be able to access the uploaded file. Now the server responds with an image, however the file’s MIME-type is text/plain. The browser will ‘sniff’ the file, and then render the php script, allowing the attacker to do RCE (Remote Code Execution).

With this header set to ‘nosniff’, the browser will not look at the file, and simply render it as whatever the server tells the browser that it is.

X-XSS-Protection

While this header was more necessary in older browsers, it’s so easy to add that you might as well. Some XSS (Cross-site Scripting) attacks can be very intelligent, while some are very rudimentary. This header will tell browsers to scan for the simple vulnerabilities and block them.

Common_location.conf

X-Real-IP

Because your servers are behind a reverse proxy, if you try to look at the requesting IP, you will always see the IP of the reverse proxy. This header is added so you can see which IP is actually requesting your service.

X-Forwarded-For

Sometimes a users request will go through multiple clients before it reaches your server. This header includes an array of all those clients.

X-Forwarded-Proto

This header will show what protocol is being used between client and server.

Host

This ensures that it’s possible to do a reverse DNS lookup on the domain name. It’s used when the server_name directive is different than what you are proxying to.

X-Forwarded-Host

Shows what the real host of the request is instead of the reverse proxy.

X-Forwarded-Port

Helps identify what port the client requested the server on.

Ssl.conf

SSL is a huge topic in and of itself, and too big to start explaining in this article. There are many great tutorials out there on how SSL handshakes work, and so on. If you want to look into this specific file, I suggest looking at the protocols and ciphers being used, and what difference they make.

Redirecting HTTP to HTTPS

The observant ones have maybe noticed that we are only ever listening on port 443 in this secure version. This would mean that anyone trying to access the site via //* would get through, but trying to connect through //* would just get an error. Luckily there’s a really easy fix to this. Make a redirect.conf file with the following contents:

server { listen 80; server_name _; return 301 //$host$request_uri; }

Now just make sure that it appears in your sites-enabled folder, and when you’ve reloaded the Nginx process in the container, all requests to port 80 will be redirected to port 443 (HTTPS).

Final Thoughts

Now that your site is up and running, you can head over to SSL Labs and run a test to see how secure your site is. At the time of writing this, you should get a perfect score. However there is a big thing to notice about that.

Turvalisuse ja mugavuse vahel on alati tasakaal. Sel juhul on kaal tugevalt turva poolel. Kui käivitate testi SSL-i laborites ja kerite alla, näete, et on mitu seadet, mis ei saa teie saidiga ühendust luua, kuna need ei toeta uusi standardeid.

Nii et pidage seda meeles, kui seda seadistate. Praegu juhin lihtsalt serverit kodus, kus ma ei pea muretsema, et paljud inimesed sellele juurde pääsevad. Kuid kui teete Facebookis skannimise, näete, et neil pole nii suurt skoori, kuid nende saidile pääseb juurde rohkem seadmeid.