SSH a 443-as porton webszerver mellett.

A mai nap kicsit témázgattunk a discord szerverünkön arról, hogy milyen porton kellene használni az SSH-t és, hogy érdemes-e valamilyen magas porta konfigurálni. Erre én bevágtam, hogy nekem a 443-on van és még webszerver is fut mellette probléma nélkül. Persze erre jött az értetlenkedés, hogy HÁT DE A 443 A HTTPS PORT, ja és akkor mivan? Szóval most itt megpróbálom elmagyarázni miért lehetséges ez és, hogyan lehet megvalósítani.

Nem véletlen a 443-as portra konfiguráljuk be és nem a 80-ra, ennek az az oka, hogy a HTTPS biztonságos TLS kapcsolatot használ. Az egész megoldásnak pedig igazából a TLS a kulcsa. Nagyon egyszerű igazából a logika mögötte, amennyiben TLS kérés érkezik a 443-as portra, akkor a webszerver felé routeoljuk a forgalmat, ha nem, akkor pedig az SSH felé.

Na de akkor nézzük azt az nginx konfigurációs file-t.

stream {
		upstream web {
			server 127.0.0.1:4443;
		}

		upstream ssh {
			server 127.0.0.1:22;
		}
            
 		map $ssl_preread_protocol $upstream {
			default ssh;
			"TLSv1.2" web;
			"TLSv1.3" web;
		}

		server {
			listen 443:
			ssl_preread on;

			proxy_pass $upstream;
		}
}

Most a szemfülesek biztos észrevették, hogy a web-et valamiért a 4443-as portra proxyzzuk. Ez talán a legnagyobb hátulütője az egésznek, hogy a site konfigurációkban most már nem használhatjuk a 443-as portot mivel azon már listenel egyszer az nginx. De ettől azért nem kell sírva fakadni, csak ki kell cserélni a portot valami másra és ezzel a konfigurációval ugyan úgy tökéletesen menni fognak a weblapok továbbra is. A 4443 nem szükséges, lehet bármi más port ami szabad a hoszt-on, ez csak az én személyes preferenciám.

Mint látható a konfigurációban az 1.2-nél régebbi TLS verziókat nem írtam bele, szimplán azért mert 2022 van és szükségtelen, de ha neked véletlen mégis szükséged lenne a régebbi verziókra akkor írd hozzá őket: "TLSv1.0" web;, "TLSv1.1" web;. Igen, ez azt okozza, hogy a régebbi TLS verziójú kapcsolatokat is az SSH felé fogja proxyzni az nginx, de mivel az SSH okos ezért nem okoz neki gondot :)

Mivel szeretnénk, hogy ennek az egésznek értelme is legyen érdemes tűzfallal blokkolni a 22-es portot vagy pedig átírni az SSH konfigurációban, hogy csak a 127.0.0.1-ről engedje a kapcsolatokat.

Most pedig mentsük el a konfigurációt és töltsük újra az nginx-et: nginx -s reload

Hátulütők

Mivel az nginx proxyzza a forgalmat ezért az ssh logokban minden csatlakozás és próbálkozás úgy fog tűnni mintha a 127.0.0.1-ről jött volna. Ez akkor jelent problémát, ha fail2ban-t használunk mivel sok hibás próbálkozás esetén egyszerűen megfogja és kibannolja a 127.0.0.1-es ipcímet amivel nem csak a támadót hatástalanítja, hanem mindenkit, beleértve magunkat is. Erre az a megoldás, hogy ne használjuk jelszavas hitelesítést, használjuk helyette kulcspárokat és így már a fail2ban-ra sem lesz szükség.

Bővebben az SSH biztonságról: https://bitlords.net/ssh-biztonsag-5-lepesben/ (a 2.-at nyugodtan kihagyhatod, ha a fentebb említett módszert használod.)

Sajnos van még egy hátulütője ennek az egésznek, mégpedig az, hogy ha az nginx valamiért meghal és nem tud elindulni akkor az SSH hozzáférésünket is elveszítettük. Erre nem nagyon van megoldás, egyszerűen figyeljünk oda és minden változtatás után használjuk az nginx -t parancsot, hogy ellenőrizzük a konfigurációt.

Végszó

Én nagyon remélem, hogy tetszett a cikk és hasznosnak találtad, amennyiben így van passzolj egy megosztást és lépj be discord szerverünkre! Písz és puszi! ✌️