Dotaz: Proxy z 1 verejne IP na X neverejnych pri zachovani portu

[martin]

Příloha:

• schema.png (34452 bytů)

Ahoj,
potrebuji z Internetu pristupovat na nekolik pocitacu s neverejnou IP. Mam to vyresene OpenVPN tunelem z kazdeho PC na jeden centralni server s 1x verejnou IPv4.
Kdyz pak se pak pripojuji na jednotlive "schovane" PC, davam IPserveru:cisloPortu.

Na prikladu VNC (nejde mi jen o VNC, potrebuji zpristupnit asi 10 sluzeb na kazdem PC).

PC A TCP port 5900, na server IP.AD.RE.SA:5901,
PC B TCP port 5900, na server IP.AD.RE.SA:5902...

Rad bych na klientskem PC (ze ktereho se pripojuji) neuvadel cislo portu - tedy pouzivat vzdy defaultni.
Pro webserver to resim virtualhostem:

a.example.com:80 -> PC A TCP 80,
b.example.com:80 -> PC B TCP 80...

U webserveru je to jasne. Jak ale timto zpusobem poresit sluzby jako napr. VNC, RDP, SSH, ...?
Kdybych mel pro kazdy stroj na serveru jednu verejnou IPv4, tak by nebyl problem. Bohuzel server ma jen jednu.

Jedine reseni me napadlo pomoci iptables. Zkoumat domenu cile a podle ni smerovat do VPN:

iptables -t nat -A PREROUTING -d a.example.com -p tcp -m tcp --dport 22 -j DNAT --to-destination 192.168.100.1:22
iptables -t nat -A PREROUTING -d b.example.com -p tcp -m tcp --dport 22 -j DNAT --to-destination 192.168.100.2:22

Je to dobry napad? Znate nejake lepsi reseni?

Odpovědi

[Michal]

Jedine reseni me napadlo pomoci iptables. Zkoumat domenu cile a podle ni smerovat do VPN.

To asi neklapne protoze k iptables (resp. kernelu) se ta domena vubec nedostane. Prichozi paket uz obsahuje jen IP adresu, ktera - hadam - je stejna pro a.example.com i b.example.com.

Nemohl bys mit i ty klienty na VPN? Pak by byla prima viditelnost po privatnich adresach na ty servery a nemusel bys resit zadny NAT.

Nebo samozrejme IPv6 ;)

[martin]

To asi neklapne protoze k iptables (resp. kernelu) se ta domena vubec nedostane. Prichozi paket uz obsahuje jen IP adresu, ktera - hadam - je stejna pro a.example.com i b.example.com.

To prevent outgoing access to www.facebook.com, enter:
# iptables -A OUTPUT -p tcp -d 69.171.224.0/19 -j DROP
You can also use domain name, enter:
# iptables -A OUTPUT -p tcp -d www.facebook.com -j DROP
# iptables -A OUTPUT -p tcp -d facebook.com -j DROP

Nemohl bys mit i ty klienty na VPN? Pak by byla prima viditelnost po privatnich adresach na ty servery a nemusel bys resit zadny NAT. Nebo samozrejme IPv6 ;)

VPN pro klienty pouzit nemuzu. A IPv6 ma dost malo lidi. Jedine pouzivat teredo

[Radovan Garabik]

To prevent outgoing access to www.facebook.com, enter:
# iptables -A OUTPUT -p tcp -d 69.171.224.0/19 -j DROP
You can also use domain name, enter:
# iptables -A OUTPUT -p tcp -d www.facebook.com -j DROP
# iptables -A OUTPUT -p tcp -d facebook.com -j DROP

Tá doména je resolvovaná pri spustení iptables, takže v packete sa samozrejme porovnáva len IP adresa. Možno by sa to dalo parsovaním obsahu packetu, ale to samozrejme nebude fungovať pre SSH a je to v praxi nepoužiteľné riešenie...

Asi by som sa pozrel na DNS SRV record - nepoužívajú to všetky služby, ale aspoň niektoré by to vyriešilo.

Ja na to tiež používam IPv6 - VPN má IPv6 adresy a tam už nie je problém. A automaticky to vyrieši aj IPv6 pripojenie klientov - OpenVPN počúva na IPv4, po pripojení klient dostane IPv6 adresu.

[Michal]

To prevent outgoing access to www.facebook.com, enter:
# iptables -A OUTPUT -p tcp -d 69.171.224.0/19 -j DROP
# iptables -A OUTPUT -p tcp -d www.facebook.com -j DROP

Tohle sice vypada jako ze iptables rozumi domenovym jmenum ale ve skutecnosti te jen chteji zmast (a dari se jim to).

1. Zaprve je potreba vedet ze filtrovani packetu probiha primo v jadre a ten prikaz iptables jen strka do jadra pravidla s filtrama. To je vsechno co dela, je to takovej sroubovak na utahovani jaderneho firewallu.
    
2. Zadruhe je potreba vedet ze v obou pripadech, at tedy zadas -d 4.2.2.1 nebo -d a.resolvers.level3.net se do jadra dostane jen ta prelozena IP adresa, tedy 4.2.2.1. Jiste, muzes zadat domenove jmeno, ale jedine co se stane je ze iptables prikaz to prelozi na IP a strci do jadra tu IP. Takze tak.
    
3. No a posledni vec je ze v prichozim packetu od klienta na server je v naproste vetsine pripadu jen cilova IP adresa a port. Vyjimkou je HTTP a HTTPS kde je hluboko uvnitr toho packetu pribaleno i jmeno webu o ktery ma klient zajem, ale to je fakt vyjimka (a v pripade HTTPS navic s dost komplikacema).

Takze v naproste vetsine pripadu bude mit server k dispozici jen zdrojovou a cilovou IP adresu a port a bude se muset rozhodnout podle toho kam ten packet poslat. Obavam se ze bez ruznych portu pro ruzne vnitrni servery se neobejdes. Pokud ti tak moc vadi ten port zadavat rucne muzes si treba v pripade SSH udelat ~/.ssh/config:

Host a.example.com
        HostName                tvuj-server.example.com
        Port                    2201

Host b.example.com
        HostName                tvuj-server.example.com
        Port                    2202

Pak muzes dat ssh a.example.com a dostanes se na tvuj-server:2201 odkud se to forwarduje na a.example.com:22. Pokud nechces mit VPN i pro klienty tak ze obavam ze nic lepsiho se vymyslet neda.

[rADOn]

U webserver to funguje protoze se hostname posila uvnitr http requestu. Jinde ti to fungovat nebude a nemuze, ostatne ani https nebude. IMO jediny zpusob jak to udelat je mit na tom centralnim serveru nekolik ip a smerovat to podle nich.

[martin]

HTTPS s SNI by snad fungovat melo.

Vic IP nemam

Proc to nejde? Iptables prece dokaze poznat domenove jmeno a podle neho pak muze delat DNAT do VPN. Jenom by prestalo fungovat ssh na ip adresu serveru. To bych prezil - stejne kazdy pouziva domenova jmena.

[darkenik]

pretoze iptables nepracuje s dns menami ale si ich automaticky prelozi na ip adresy

takze ak

a.example.com a b.example.com bolo DNS meno pre tvoju verejnu ip serva dajme tomu 88.88.88.88

tak z pravidiel iptables -t nat -A PREROUTING -d a.example.com -p tcp -m tcp --dport 22 -j DNAT --to-destination 192.168.100.1:22 iptables -t nat -A PREROUTING -d b.example.com -p tcp -m tcp --dport 22 -j DNAT --to-destination 192.168.100.2:22

by sa stalo

iptables -t nat -A PREROUTING -d 88.88.88.88 -p -m tcp --dport 22 -j DNAT --to-destination 192.168.100.1:22 iptables -t nat -A PREROUTING -d 88.88.88.88 -p -m tcp --dport 22 -j DNAT --to-destination 192.168.100.2:22

[rADOn]

Ach ty zaklady ip protokolu

iptables domenove jmeno poznat nedokaze a nemuze, protoze v hlavicce ip paketu jsou jen adresy. Kdyz zadas jmeno do pravidla, tak se zase prelozi na adresu a ta se porovnava.

[Jendа]

Proc to nejde? Iptables prece dokaze poznat domenove jmeno a podle neho pak muze delat DNAT do VPN.

Tak si to zkusíme: jsem klient, připojil jsem se k tvému serveru (kde se dělá ten NAT) a říkám:

CONNECT

Co mi odpovíš?

[Milan Roubal]

no zaridit se to teoreticky da. Do DNS ci hosts souboru zapsat vymyslene adresy (v pripade dobre konfigurace to dokonce muzou byt i stejne adresy, jako maji ty skutecne stanice):

a.example.com XXX.XXX.XXX.1
b.example.com XXX.XXX.XXX.2

pak na tom klientovi rozbehnout preklad, ze XXX.XXX.XXX.1 s portem 5900 je ta IPv4 adresa s portem 5901, XXX.XXX.XXX.2 s portem 5900 je ta IPv4 adresa s portem 5902, etc... Potom na tom serveru s IPv4 nastavit zase rozdeleni tech sluzeb na jednotlive ovladane stanice.

[martin]

To se mi libi! Slo by pouzit nasledujici reseni? :

U domeny nastavim DNS zaznam na server *.example.com.

Do /etc/hosts dam:

a.example.com 127.10.0.1
b.example.com 127.10.0.2

a pomoci iptables udelam DNAT:

iptables -t nat -A PREROUTING -i inet0 -d 127.10.0.1 -p tcp --dport 22 -j DNAT --to-destination 192.168.100.1:22
iptables -A FORWARD -i inet0 -p tcp --dport 22 -d 192.168.100.1 -j ACCEPT

iptables -t nat -A PREROUTING -i inet0 -d 127.10.0.2 -p tcp --dport 22 -j DNAT --to-destination 192.168.100.2:22
iptables -A FORWARD -i inet0 -p tcp --dport 22 -d 192.168.100.2 -j ACCEPT

Je to realne? Muze to fungovat?

[Jendа]

iptables -t nat -A PREROUTING -i inet0 -d 127.10.0.1 -p tcp --dport 22 -j DNAT --to-destination 192.168.100.1:22
iptables -t nat -A PREROUTING -i inet0 -d 127.10.0.2 -p tcp --dport 22 -j DNAT --to-destination 192.168.100.2:22

Počkej, kam že chceš dát tahle pravidla?

• Na klienta těžko, nezná 192.168.100.1
• Na server těžko, má jenom jednu IP

[Milan Roubal]

takhle napsane je to urcite spatne. Spise neco takoveho na te masine, odkud se bude pripojovat

Do /etc/hosts dam:

a.example.com 192.168.100.1
b.example.com 192.168.100.2

a pomoci iptables udelam DNAT:

iptables -t nat -A PREROUTING -i inet0 -d 192.168.100.1 -p tcp --dport 22 -j DNAT --to-destination IP.V4.VER.ADD:8022

iptables -t nat -A PREROUTING -i inet0 -d 192.168.100.2 -p tcp --dport 22 -j DNAT --to-destination IP.V4.VER.ADD:8023

A pak na serveru s adresou IP.V4.VER.ADD smerovat port 8022 na 192.168.100.1 port 22 a port 8023 smerovat na 192.168.100.2 port 22

[lertimir]

No ale to je možné, jen pokud to je v podstatě v lokální síti. Routerům v internetu se informace o tom, že 192.168.100.1 mají směrovat na jeho stroj předat nedá. (A pokud by dala byl by pěkný binec.)

[Milan Roubal]

nikoliv :) Z jeho masiny po aplikovani toho pravidla nakonec odejde paket s verejnou adresou na verejnou adresu serveru na port 8022. O to se postara ten prvni preklad. Pak ten paket dorazi na ten server s verejnou adresou a ten se zase postara o druhy preklad na tu lokalni adresu.

[lertimir]

Jo já přehlédl to "na odesilateli". Takhle to samozřejmě fungovat bude, ale to není zpřístupnění obecných služeb. V jistém směru je to jako vytvoření virtuální sítě (i když ne "private").

[Milan Roubal]

Mimochodem pokud uz jsou klienti pripojeni pres nejake OpenVPN pripojeni k tomu serveru, tak by melo stacit se pripojit take pres openVPN k tomu serveru z venku a nastavit korektne routovani. Pak ani ten dvojity preklad nemusi byt treba.

[Jendа]

Taková pakárna jenom kvůli tomu, abych nemusel zadávat port? OMG.

[martin]

Presne tak. Nechci zadavat port.

Existuje nejake funkci reseni?

HTTP poresim na jednom portu virtualhostem - to neni problem.

Jak s HTTPS? Da se pri pouziti SNI take nastavit virtualhost na jednom portu?

Pro ostatni sluzby tedy budu asi zadavat cislo portu...

A hlavne prenos souboru. Umi nejaky protokol napr. FTPS, SFTP, FTP pouzit neco jako virtualhost? Jediny co me napada je WebDAV (https) ale jeho podpora je proti ostatnim nic moc.

[Jendа]

Presne tak. Nechci zadavat port.

No když ti to za to stojí, tak zkus, co napsal předřečník.

Jak s HTTPS? Da se pri pouziti SNI take nastavit virtualhost na jednom portu?

Blbě, TLS by se muselo zakončovat už na té proxy/natujícím routeru.

A hlavne prenos souboru. Umi nejaky protokol napr. FTPS, SFTP, FTP pouzit neco jako virtualhost?

Ne.

[lertimir]

Místo diskutování si přece stačí přečíst základy TCP/IP. Konkrétně, co je v hlavičkách. A v IP hlavičce jsou jen IP adresy (a technické udaje jako fragmentace nebo TTL) a v TCP jsou jen porty (a řízení spojení SN, ACK a window). Pokud chce jakýkoliv protokol reagovat na více doménových jmen pro stejnou IP adresu, musí si informace o jméně přenést sám. HTTP to má v položce Host:. Staré protokoly nikoliv. FTP a osvozeniny nic takového neumožňují.

[rADOn]

Presne tak. Nechci zadavat port.

Ty se asi hodne nudis Jako cviceni sitovani je to bezvadny, ale jinak dost prasarna. Pokud se uz musis hrabat ve smerovani na klientech, tak to uz tam rovnou muzes dat taky nejakou tu vpnku.

Pokud opravdu nechces port jen _zadavat_, ssh umoznuje dat port do konfiguraku pro ruzne hosty ruzne, totez se pak aplikuje na scp. A co nejde silou, jde jeste vetsi silou pomoci shell aliasu nebo inputrc.

[tomas789]

Uz z principu toto samozrejme mozne neni. Projdeme to pekne od spodu po vrstvach sitove komunikace. Predpokladejme, ze na ten smerovac prijde nejaky paket. Co se deje na jednotlivych vrstvach?

L1 - Fyzicka - Tedy nic nemuzu. Tady se mi jen posilaji logicke informace po mediu (napr. kabelu). Tato vrstva neinterpretuje zadnym zpusobem data. Pouze je predava dale.

L2 - Linkova - Zde se jiz adresuje. Takzvanymy MAC adresamy. Tyto adresy jsou ale platne pouze na jedne lince. Coz je typicky nejaky kabel. Takze pokud nejsou vychozi i cilovy stroj na jedne lince (jeden kabel, jedna wifi sit) tak tyto adresy pouzit nemuzete (a vy jste na internetu a to samozrejme neni jeden kabel obecne)

L3 - Sitova - Tady adresujeme IP adresami (pokud se jedna o sit na bazi IP). Vy mate pouze jedinou IP adresu, takze ani na tomto miste nemuzete jednotlive pakety "zaskatulkovat"

L4 - Transportni - Tady je moznost rozlisit pakety podle cisla portu. To je obecne prijatelna moznost, ale byla vyloucena.

V tuto chvili tedy neni moznost, jak pakety rozlisit. Dale nasleduje uz pouze aplikacni vrstva, tedy cilova stanice onoho paketu. Ted chcete aby system nejak poznal, ze to ma podstrcit jinym aplikacim (nehlede na to, ze jsou na jinych strojich, to neni relevantni). Ted je jiz na to pozde. Pokud se podivate nazpet v rozpise, jedine dve moznosti (prijatelne na internetu obedce) jsou IP adresa nebo cislo portu.

Jeste bych chtel uvest na pravou miru jednu dezinterpretaci ktere myslim jste se dopustil. DNS preklada domenova jmena na IP adresy (zejmena). To co jste predpokladal vy bylo, ze prelozim DOMENA -> IP. Tedy nekolik domen na jednu IP adresu. Pak po routeru ale chcete, aby zobrazil IP -> DOMENA kde IP je jedna, ale DOMENA ty jsou tri. Z matematickeho hlediska tento zpetny preklad neni funkce a nelze tedy provest. (to plyne z toho, ze prvni preklad DOMENA -> IP neni prosta funkce, rozmyslete si to, je to zajimava skutecnost ktera prida na celkovem prehledu)

HTTP umi vami pozadovanou vec proto, ze v samotnem obsahu "PAYLOAD" obsahuje dalsi skatulkovani (HTTP hlavicku nesouci jmeno serveru). Ta nutne neni zadnou validni domenou. Muze to byt i libovolny jiny retezec. Pak pouze staci, aby byl paket spravne dorucen a vas server vam odpovi napriklad na dotaz na google.com nebo cokoliv jineho. Pokud tedy najdete dalsi protokol se stejnou schopnosti (nebo ji podobnou v kontextu onoho protokolu), muzete podobnou vec aplikovat. V opacnem pripade mate smulu.

Dalsi moznost je pouzit nejake na miru usite reseni, ktere routeru oznami informaci stylu "ted budou prichazet data pro pocitac A". To lze realizovat napriklad port-knockingem, ruznymy ICMP, IGMP zpravami a podobne. Spolehlivost je ale pochybna (ICMP, IGMP funguje nespojovane, nespolehlive, takze paket rikajici komu maji data dojit muze dorazit az po samotnych datech. co s nimi v mezicase udela ale router a jak to vubec pozna ze nekdy takovou zpravu vubec obdrzi? hint: nepozna ) K mizerne spolehlivosti pripojme jeste nulovou prenositelnost (nula je tu doslova, kdo podobny "trik" nezna, nemuze na to zareagovat). Jeste si dovolim poznamenat, ze tato technika lze pouzit pro vytvoreni temer nepostrehnutelnych backdoors (tady je to naopak nedocenitelny pomocnik).

[Marek]

Přesně tohle se řešilo v milonech diskusí, k čemu je IPv6 a tohle byl jeden z příkladů. Výsledek: Kdo má IPv6, nemusí zadávat port. Kdo ho nemá, musí zadávat port. Jiná cesta prostě není, možná nějaká proxy typu SOCKS, jestli se to ještě používá. Ale pochybuju jestli to půjde.

[pavlix]

SOCKS je sice podstatně schopnější než NAT, jenže pořád musíš počítat jen s těmi veřejnými adresami, které máš.