Fórum Root.cz
Hlavní témata => Server => Téma založeno: darebacik 16. 03. 2021, 10:23:12
-
Momentalne fungujem za NAT z jednym apache serverom. Mam forward portov 443 a 80 na lokalnu IP 192.168.1.10 kde je server. Apache mam nakonfigurovany na 4 vhosty.
Teraz chcem otestovat nginx, ktory testujem na 192.168.1.11, ale neviem ako nastavit pravidlo. Ked to budem znova smerovat na 80 (resp. 443), tak ako bude paket vediet ci ma ist na 192.168.1.10, alebo na 192.168.1.11 ?
-
Nijak, nejde to. Potrebujete ipv6, reverzni proxy, nebo jine porty.
-
Běžný firewall (ne aplikační) nevidí do obsahu komunikace. Vidí jen IP adresu a port. Takže musíte komunikaci přesměrovat na reverzní proxy server – ten už vidí dovnitř komunikace a na základě požadovaného názvu serveru přesměruje komunikaci na správný cílový server. Jako reverzní proxy se dá použít třeba nginx.
-
Reverzna proxy ak to ma byt natrvalo takto.
-
Chcel by som nahradit apache, nginixom (asi by som nevyuzil reverzny proxy ako nginix pred apachom, lebo mam len maly domaci servrik). A asi by bolo narocne pre mna riesit docasny reverzny proxy. To ze bezia obidva naraz je len docasne riesenie pocas testovania. V normalnej prevadzke bude vzdy len jeden. Ak sa osvedci nginix, tak apache zrusim.
Podla toho co som zistoval, tak LEMP (z php-fpm) by mal vediet teoreticky nahradit LAMP.
-
Pro trvalé řešení ta zmíněná reverzní proxy (jde použít cokoliv - haproxy, nginx, ... i v tom apache to jde udělat). Pokud je to jen na hraní a pokus a v roli toho NATu mám Mikrotika, tak pro HTTP umí dělat reverzní proxinu (ale nehodí se to pro nasazení do ostra) a pro HTTPS umí směrovat na základě požadavku TLS host (SNI).
-
Když je to jen dočasné, nestačilo by jen přesměrovat na ten testovací server jiné porty té veřejné adresy? Pak by adresa testovacího serveru zvenku byla x.x.x.x:8080.
-
Pro trvalé řešení ta zmíněná reverzní proxy (jde použít cokoliv - haproxy, nginx, ... i v tom apache to jde udělat). Pokud je to jen na hraní a pokus a v roli toho NATu mám Mikrotika, tak pro HTTP umí dělat reverzní proxinu (ale nehodí se to pro nasazení do ostra) a pro HTTPS umí směrovat na základě požadavku TLS host (SNI).
S tím směrováním HTTPS na Mikrotiku máte zkušenost? Je to totiž teoreticky blbost. Informaci ze SNI máte až v několikátém paketu již navázaného spojení a to už je pozdě na nějaké směrování. Jinými slovy - firewallem to řešit nelze.
-
Pro trvalé řešení ta zmíněná reverzní proxy (jde použít cokoliv - haproxy, nginx, ... i v tom apache to jde udělat). Pokud je to jen na hraní a pokus a v roli toho NATu mám Mikrotika, tak pro HTTP umí dělat reverzní proxinu (ale nehodí se to pro nasazení do ostra) a pro HTTPS umí směrovat na základě požadavku TLS host (SNI).
Nemam mk, ale pfsense. Tam je moznost squid, alebo haproxy, tak sa s tym skusim pohrat.
Když je to jen dočasné, nestačilo by jen přesměrovat na ten testovací server jiné porty té veřejné adresy? Pak by adresa testovacího serveru zvenku byla x.x.x.x:8080.
Ano je to moznost, ale obavam sa aby neboli problemy napr. pri generovani crt od letsencrypt a pod .... radsej to chcem testovat na 80 a potom 443
-
Jen taková drobná poznámečka:
Kdyby se na implementaci hošani od webových prohlížečů nevys*ali, bývalo se to dalo řešit uvedením portů v záznamech SRV DNS.
-
Jen taková drobná poznámečka:
Kdyby se na implementaci hošani od webových prohlížečů nevys*ali, bývalo se to dalo řešit uvedením portů v záznamech SRV DNS.
I pak bych to na produkční weby asi používat nechtěl, protože jsou různé omezené sítě, kde jsou povolené jenom „běžné“ odchozí porty, a BFU tímto způsobenou nedostupnost webu nechce a neumí řešit. Pokud je to hobby/pro odborníky, pak samozřejmě OK (ale pak klidně může odkazovat jako https://muj.web.tld:1443/).
-
...Pokud je to hobby/pro odborníky, pak samozřejmě OK...
Tak když si dělám server, tak vím, co a proč tam mám otevřené. A vůbec jde o obecnost.
...ale pak klidně může odkazovat jako https://muj.web.tld:1443/...
Tak to je přesně případ, jak dělat ve věcech větší bordel, než je. A to nemluvím o dalších přínosech záznamu SRV jako rozdělování zátěže či více služeb pod stejným doménovým názvem.
-
Tak když si dělám server, tak vím, co a proč tam mám otevřené.
Já mluvil o portech u uživatele. Že se uživatel nebude schopen připojit jinam než na 80 a 443.
-
Jen taková drobná poznámečka:
Kdyby se na implementaci hošani od webových prohlížečů nevys*ali, bývalo se to dalo řešit uvedením portů v záznamech SRV DNS.
No, už se vaří lepší náhrada s avizovanou podporou významnějších prohlížečů (Chrom*, Firefox, Apple): https://tools.ietf.org/id/draft-ietf-dnsop-svcb-https-02.html
-
Jen taková drobná poznámečka:
Kdyby se na implementaci hošani od webových prohlížečů nevys*ali, bývalo se to dalo řešit uvedením portů v záznamech SRV DNS.
No, už se vaří lepší náhrada s avizovanou podporou významnějších prohlížečů (Chrom*, Firefox, Apple): https://tools.ietf.org/id/draft-ietf-dnsop-svcb-https-02.html
To je hezky, a jak si s tim poradi firewally?
-
No, už se vaří lepší náhrada s avizovanou podporou významnějších prohlížečů (Chrom*, Firefox, Apple): https://tools.ietf.org/id/draft-ietf-dnsop-svcb-https-02.html
To je hezky, a jak si s tim poradi firewally?
S používáním nestandardních portů? Zatím z té mnohaměsíční diskuse okolo daného draftu nevypadá, že by zrovna tu změnu portů chtěl někdo výrazně využívat, takže tady nečekám moc rozdíl oproti současnému stavu. Objevil se i názor tuhle část vyhodit, ale teď už nejspíš zůstane. (už se dost odkláníme od původního tématu)
-
To je hezky, a jak si s tim poradi firewally?
Tak port 80 a 443 mejsou nějaká magická nezměnitelná konstanta, pokud budeš poskytovat web na jiném než defaultním portu, tak si ten port budeš muset samozřejmě otevřít..
-
Tak port 80 a 443 mejsou nějaká magická nezměnitelná konstanta, pokud budeš poskytovat web na jiném než defaultním portu, tak si ten port budeš muset samozřejmě otevřít..
Samozřejmě nebyl myšlen firewall na straně serveru, ale na straně klienta. A tam by ve spoustě sítí samozřejmě problém byl.
-
Když já nikdy nepochopil, čím má zákaz portů mimo 443 a 80 pomoci zabezpečení... Dokud nedělám inspekci L7, kterou mohu dělat na všech portech je úplně jedno, jestli to teče ven na 443 nebo 8080. Přijde mi, že je to takové pseudozabezpečení, které s námi zůstalo od velkých společností z osmdesátek jako best practice, aniž by se nad tím někdo skutečně zamýšlel.
Je to v jednom pytli s vynucováním nového hesla každé tři měsíce a pamětí AD 50 hesel zpět.
Tak port 80 a 443 mejsou nějaká magická nezměnitelná konstanta, pokud budeš poskytovat web na jiném než defaultním portu, tak si ten port budeš muset samozřejmě otevřít..
Samozřejmě nebyl myšlen firewall na straně serveru, ale na straně klienta. A tam by ve spoustě sítí samozřejmě problém byl.
-
Když já nikdy nepochopil, čím má zákaz portů mimo 443 a 80 pomoci zabezpečení...
Ono jde spíš o to, že se tím omezí provoz, o kterém nic nevíte. Ale že je to k ničemu, s tím souhlasím.
-
Když já nikdy nepochopil, čím má zákaz portů mimo 443 a 80 pomoci zabezpečení...
Bývá zvykem BFUčkům zakázat 25, 139 a 445, aby jejich zavirované počítače nemohly posílat spam a útočit na další cizí nezáplatovaná Windows. Ale jinak souhlasím, že obecný zákaz je celkem k ničemu a je to hlavně opruz pro uživatele -- ale já (ani nikdo další) jsme nehodnotili, k čemu to je, ale že se to děje, nic s tím nenaděláme, a pokud chceme mít široce dostupnou službu, tak musí běžet na 443.
-
Drive to melo smysl - na 443 byl jen https, dnes je to bordel - dnes tam muze byt i ssh.
Kazdopadne jeden vliv je i sniffovani provozu - zkuste hledat problem pres vsechny porty vs port pro dany typ sluzby. Nemluve o standarizaci - kdyby si kazdy vymyslel port pro https, tak by za chvili odchozi firewally ztratily smysl.
-
Nejak sa to tu zvrhlo.
Zatial sa mi podarilo nastavit haproxy na pfsense a zda sa, ze to celkom funguje. Takze aspon nemusim pouzivat exoticke porty. A ani neviem ci by certbot fungoval na inom ako standardnom porte
-
Nejak sa to tu zvrhlo.
Zatial sa mi podarilo nastavit haproxy na pfsense a zda sa, ze to celkom funguje. Takze aspon nemusim pouzivat exoticke porty. A ani neviem ci by certbot fungoval na inom ako standardnom porte
Nefungoval. Pri http overovani overuje textovy retezec na http(s)://, takze ocekava port 80(443)...
-
A ani neviem ci by certbot fungoval na inom ako standardnom porte
Nefungovalo by to. Nejde ani tak o certbot ale o ACME protokol – ten ověřuje buď metodou http-01 na portu 80 nebo metodou tls-alpn-01 na portu 443. (A nebo přes DNS.) Je to z důvodu bezpečnosti – na počítači, kde běží webový server, mohou být jiné uživatelské účty, které by mohly na vysokém portu spustit svůj proces, který by provedl validaci a získal by certifikát pro danou doménu. Právo získat certifikát ale má mít jen správce webového serveru a správce DNS serveru, nikdo jiný.
-
Nejak sa to tu zvrhlo.
Zatial sa mi podarilo nastavit haproxy na pfsense a zda sa, ze to celkom funguje. Takze aspon nemusim pouzivat exoticke porty. A ani neviem ci by certbot fungoval na inom ako standardnom porte
Pokud máš PfSense tak haproxy je nejideálnější cesta ;-)
-
Zaujmalo by ma este ako je to s certifikatmi od letsencrypt. Ako som uz napisal, (je to len test, nebudem to tak prevadzkovat, bude to len docasne, ale zaujma ma to) za jednou verejnou IP mam 2 web servery na 192.168.1.10 a 192.168.1.11. Ked som nastavil haproxy, tak vsetka komunikacia prichadza na haproxy. Je mozne vytvorit 1 certifikat na haproxy a na vsetkych ostatnych domenach (serveroch) ho uz nemusim pouzivat ?
Alebo na haproxy certifikat nedavat a ponechat ho na ostatnych domenach/serveroch ?
-
Zaujmalo by ma este ako je to s certifikatmi od letsencrypt. Ako som uz napisal, (je to len test, nebudem to tak prevadzkovat, bude to len docasne, ale zaujma ma to) za jednou verejnou IP mam 2 web servery na 192.168.1.10 a 192.168.1.11. Ked som nastavil haproxy, tak vsetka komunikacia prichadza na haproxy. Je mozne vytvorit 1 certifikat na haproxy a na vsetkych ostatnych domenach (serveroch) ho uz nemusim pouzivat ?
Alebo na haproxy certifikat nedavat a ponechat ho na ostatnych domenach/serveroch ?
Certifikát/certifikáty budou na HAproxy – tam se musí komunikace od klienta dešifrovat, zjistit, s jakým cílovým serverem chce klient komunikovat, a podle toho se naváže spojení se správným cílovým serverem. Toto spojení už nemusí být šifrované (třeba pokud je cílový server na stejném počítači nebo v bezpečné síti).
Dnes už by díky SNI nebylo nutné mít certifikát na HAproxy ale až na cílových serverech, HAproxy by pak do komunikace vůbec neviděla. Ale je to méně časté řešení. Navíc HAproxy pak nemůže třeba dělat čištění provozu, protože nevidí dovnitř šifrované komunikace.