vermin.eu.org

Specjalista IT na tru^Hopie

Entries Comments



Przerzucanie portów na iptables, z haczykiem

22 December, 2006 (04:56) | bezpieczeństwo, linux | By: vermin

Sprawa wydawałaby się bananalna. Pakiety wchodzą z internetu (interfejs zewnętrzny, zewnętrzny IP) do routera i mają trafić do jakiegoś komputera w sieci. Router robi jakąś maskaradę sieci wewnętrznej. Ponieważ chcemy przejąć w tejże sieci wewnętrznej pulpit, powiedzmy, że to będzie WXP Pro, czyli interesuje nas port 3389. Zakładamy, że port na który wchodzą pakiety, to port 33089
OK - czyli do tej pory mamy:

  • zewnętrzny IP routera (np. 193.213.32.4),
  • wewnętrzny IP/sieć routera (np. 172.16.34.1/16),
  • port routera: 33089
  • adres WXP (np. 172.16.34.56),
  • port WXP: 3389
  • swój adres: 83.24.240.244

Sprawa banalna, opisana wszędzie, wystarczy wykonać dwa polecenia:

  • /sbin/iptables -A PREROUTING -t nat -s 83.24.240.244 -d 193.213.32.4 –dport 33089 -j DNAT –to-destination 172.16.34.56:3389
  • /sbin/iptables -A FORWARD -d 172.16.34.56 -p tcp –dport 3389 -j ACCEPT

Pierwsza z reguł mówi, że kazdy pakiet wchodzący z sieci zewnętrznej, kierowany na IP 193.213.32.4, port 33089 powinien być przekierowywany na maszynę o IP 172.16.34.56 i port 3389. Jest to reguła sprawdzana zanim zostanie podjęta jakakolwiek decyzja o routingu. Pakiety wpadają sobie do firewalla, podejmowana jest decyzja o routingu, ponieważ sieć docelowa jest wśród tych, które firewall osbługuje, to wrzuca pakiet do łańcucha forward, stąd konieczność (reguła 2) umożliwienia takiego właśnie ruchu.

Banalna sprawa, nieprawdaż? Gdzie ten haczyk? Cóż, wszystko działa oprócz tego, że TU nie działa. Otóż komputer kliencki ma swojego firewalla, który to spryciarz dopuszcza tylko połączenia z sieci wewnętrznej, (co łatwo sprawdzić, bo odrzuca połączenia z zewnątrz, a telnet na port działa). Zastosowany tu DNAT niestety nie tłumaczy adresu źródłowego na adres lokalny i pozostawia 83.24.240.244, co klient od razu ubija - pojawia się konieczność szukania zagrody, znaczy obejścia.
W tym momencie szkoły są dwie: falenicka i otwocka. Albo nie mamy czasu, olewamy sprawę, komfigurujemy tunel i voila, jesteśmy w środku i mamy dostęp do maszyny, albo nie mamy czasu, niemniej pokombinujemy z iptables. Pierwsza rzecz, która się nasuwa, to przeróbka pakietu. Niestety tablica mangle nie do tego została stworzona, żeby przerabiać takie cuda, więc nie tam. Są polecenia conntracka zamiany adresów, ale one raczej nie mają tu zastosowania. Rozwiązanie sprawy leży znów w NATce. Tym razem jednak na wyjściu.

  • iptables -A POSTROUTING -t nat -s 83.24.240.244 -d 172.16.34.56 -p tcp –dport 3389 -j SNAT –to 172.16.34.1

Cóż to robi? Bada pakiet już wychodżacy z routera i jeśli spełnia on warunki źródła, celu, portu… to robi NAT (zwany popularnie maskaradą) zamianiejąc jak to w nacie bywa adresy źródła (-s), ukrywając je za adresem bramy. Nie ukrywam, że przez dłuższą chwilę nie przyszło mi do głowy, że to może być tak banalne (przecież to zwykły NAT, tylko na opak), niemniej szybka, nocna lektura dokumentacji pozwala na usprawnienie procesów myślowych.

Jedyne co mnie zastanawia, to fakt, że zawsze najlepsze (czytaj: działające w zadowalający sposób. ok, po prostu działające) rozwiązanie człowiek znajduje na końcu. Może dlatego, że dalej nie szuka?

Write a comment