érdekes iptables kérdés

Linux-haladó

Sziasztok!
A következő érdekes kérdésre keresek választ/megoldást:
Adott egy szerver, aminek xyz portja mindenhonnan elérhető, bizonyos szolgáltatás fut rajta.
Namost: én ezt a bizonyos szolgáltatást otthonról nem akarom használni, helyette viszont szeretném elérni ennek a portnak a közreműködésével az ssh-t.
Megoldható-e az valahogyan iptablessel, hogy a csonkasanyi.otthonigepe.hu gépről xyz portra érkező kéréseket az sshra irányítsam, minden más helyről az xyz-re érkező kérést az alapértelmezett szolgáltatás fogadjon.

Én valami olyasmire gondoltam, hogy:
iptables -A INPUT -s csonkasanyi.otthonigepe.hu -p tcp --dport xyz -j REDIRECT --to-port ssh
Viszont ebben a formában nem működik...

Megoldható ez egyáltalán? Ha igen, mi a helyes parancs?

Thx, Sanyi

  • 1407 megtekintés

( stra | 2008. 05. 06., k – 13:35 )

man iptables:
REDIRECT
This target is only valid in the nat table, in the PREROUTING and OUTPUT chains

Ezért hát:


iptables -t nat -A PREROUTING -p tcp -s csonkasanyi.otthonigepe.hu --dport xyz -j REDIRECT --to-port 22

Vagy egy másik alternatíva:


iptables -t nat -A PREROUTING -i eth0 -p tcp -s csonkasanyi.otthonigepe.hu -d szerver --dport xyz -j DNAT --to-destination szerver:22

ha nem fix ip-címed van, akkor csak addig jó, amíg az otthoni router nem kap újat.

a csonkasanyi.otthonigepe.hu iptables-be való befűzésekor fennálló ip-cím lesz érvényes "kiszolgáló restart"-ig

erre külön kell befűzni a szabályt, és lehetőleg "démonizálva" frissíteni mikor "host csonkasanyi.otthonigepe.hu" eredménye megváltozik.

Kipróbáltam, mindkét fenti sor működik, ... ha a 80 as portra irányítom az xyz portot!
De az ssh-t valamiért nem tudom elérni! :-( Ha win alól "telnet szerver xyz" parancsot kiadom, akkor nem tud kapcsolódni. Valami ötlet?

A dinamikus iphez van egy no-ip.hu regisztráció, tudtommal ez elég, ha fut a kliens...

Az eredeti irasodbol (szamomra) az derul ki, hogy az xyz port-od elerheto akarhonnan a 22 pedig nem...
Tehat, ha ez igaz, akkor az inputban megadott -s otthonigeped -p tcp --dport 22 -j ACCEPT szabalyal kiegeszitve elerheted, hogy az othonigepedrol az xyz porton elerd az ssh-d es csak az otthonigepedrol.
Ha a 22-es port elerheto barhonnan, akkor csak a fenti szabalyt hasznalva elerheted a kivant mukodes.
Tovabba fontolora veheted a knockd progi hasznalatat is.

Pontosan!
Az xyz bárhonnan elérhető, a 22 pedig nem!
Épp ez a problémám, hogy ha a 

-s otthonigeped -p tcp --dport 22 -j ACCEPT

sort beírom az inputba, akkor felesleges a REDIRECT/DNAT szabály, hiszen akkor direktben elérhetem az ssh-t. 

-s otthonigeped -p tcp --dport 22 -j ACCEPT

Ezt nem akartam beírni, hanem az xyz-t akartam otthonról ssh-ra használni (amelett, hogy NEM otthonról egy alapértelmezett szolgáltatás van rajta, tehát az nem megoldás, hogy az ssh-t átteszem az xyz-re).

Amit még próbáltam: 

iptables -t nat -A PREROUTING -s csonkasanyi.otthonigepe.hu -p tcp -i eth1 --dport xyz -j DNAT --to-destination 192.168.1.1:22

, ahol 192.168.1.1 a szerver belső lába. De sajnos ez sem ment, pedig a belső hálón mindet szabad!

Az alábbi esetek lehetségesek:

1.) Alaphelyzet: XYZ porton futó szolgáltatás mindenhonnan elérhető, SSH sehonnan.
Feladat: Az SSH-t el kell érni egy gépről.
2.) Alaphelyzet: XYZ porton futó szolgáltatás és az SSH is mindenhonnan elérhető.
Feladat: nincs
3.) Alaphelyzet: XYZ porton futó szolgáltatás sehonnan sem érhető el, SSH mindehonnan.
Feladat: nincs
4.) Alaphelyzet: XYZ porton futó szolgáltatás és az SSH sem érhető el sehonnan sem.
Feladat: Az SSH-t el kell érni egy gépről.

A lehetséges megoldások:

1.) A 2. és 3. esetben nem kell csinálni semmit.
2.) Az 1. és 4. ponthoz: a szerverre az XYZ portra és az SSH-ra akármilyen módon érkező forgalom mindenképpen az INPUT láncba kerül, mivel helyi forgalom, nem átmenő. Ez sok helyen olvasható, de a manban is leírták.
man iptables:
filter: It contains the built-in chains INPUT (for packets destined to local sockets), FORWARD (for packets being routed through the box), and OUTPUT (for locally-generated packets).
2.a) beengeded arról az egy IP-ről az SSH portra
2.b) NAT-olsz és beengeded arról az egy IP-ről az SSH portra.

Látszik, hogy a 2.b-nek nem sok értelme van, működik, de felesleges. Ezt te is leírtad:
"...akkor felesleges a REDIRECT/DNAT szabály..."

A kérdések feléd:
1.) Pontosítani kellene, hogy miként képzeled el a kívánt működést, és a te szempontodból miben lenne más a 2.a és a 2.b eset.
2.) "Ezt nem akartam beírni, hanem az xyz-t akartam otthonról ssh-ra használni"
Ez miért jó? Miért nem jó az, hogy az SSH-t csak és kizárólag otthonról éred el, máshonnan nem, függetlenül az XYZ pottól és az azon futó szolgáltatástól? Ha tudnánk az okokat, jobban tudnánk segíteni.

"... az nem megoldás, hogy az ssh-t átteszem az xyz-re)"
Nem is kell.

"... hogy a csonkasanyi.otthonigepe.hu gépről xyz portra érkező kéréseket az sshra irányítsam, minden más helyről az xyz-re érkező kérést az alapértelmezett szolgáltatás fogadjon.
Én valami olyasmire gondoltam, hogy: ..."
Ez a topikfelvetés a 2.b esetet fedi le. A pontosított NAT parancssort fent már leírtuk.

1. ha az ssh-t ki kell nyitnom az otthoni ipmre (akár xyz-n keresztül, akár direktben), akkor nekem is triviális, abban bíztam, tudtok olyan szabályt, amihez elég, ha az xyz nyitva van, az ssh zárva.
Ezek szerint az sem járható, ha a szerver külső lábának xyz portjára érkező forgalmat a belső láb ssh portjára irányítom. Bentről ugyanis minden szabad.

2. ha az iptables nem tudja kezelni, hogy a csonkasanyi.otthonigepe.hu címhez holnap már más ip cím tartozik, akkor nem is tudom beállítani, hogy az ssh csak az xxx.yyy.zzz.www címről legyen elérhető (hiszen az minden nap más és más lehet)

1.) "amihez elég, ha az xyz nyitva van, az ssh zárva."
Az a fő kérdés, hogy mi a személyes ellenvetésed az INPUT chain egy hostra történő kinyitásával kapcsolatban.
a) hogy a tűzfalon a külső interfészen kinyitsz egy portot 1 hostra
b) hogy a külső interfészen jelenleg nem hallgat, de hallgathat az SSH
c) hogy a külső interfészen nem hallgathat az SSH
d) egyéb

A válaszod megfogalmazásához egy kis áttekintés.

"az sem járható, ha a szerver külső lábának xyz portjára érkező forgalmat a belső láb ssh portjára irányítom."
man iptables:
It redirects the packet to the machine itself by changing the destination IP to the primary address of the incoming interface (locally-generated packets are mapped to the 127.0.0.1 address).

Tehát a REDIRECT target erre nem jó, de a DNAT igen. Az első hozzászólásban szereplő példán annyit kell módosítani, hogy belső IP legyen megadva a --to-destination után. Ettől még az előbb linkelt ábrán látszik, hogy az INPUT láncban a külső interfészen ugyanúgy be kell engedni.

És ezen kívül van még egy lehetőséged, ez pedig a ROUTE target a --iif opcióval (bővebben itt), viszont nem biztos hogy az adott rendszer illetve kernel alatt elsőre működik, mivel:

man iptables:
(Please note: This target requires kernel support that might not be available in official Linux kernel sources or Debian’s packaged Linux kernel sources. And if support for this target is available for the specific Linux kernel source version, that support might not be enabled in the current Linux kernel binary.)

2.) "hiszen az minden nap más és más lehet"
Pontosan. Viszont ha a tűzfalscriptet a dinamikus hostneved TTL-jének megfelelő vagy akörüli gyakorisággal futtatod, akkor menni fog. Ezt természetesen külön chainben célszerű megtenni, és így más fontos funkciót nem akadályoz az SSH-t elérő kliens IP-jének változtatása, mindentől függetlenül feltölthető és törölhető a chain teljes tartalma.

3.) Ha az iptables/netfilter által jelenleg nyújtott megoldás nem megfelelő, akkor még mindig összerakhatsz egy VPN-t.