Mittels iptables eine destination IP Addresse ändern

as69 · 30 Okt. 2004

Hallo,
hätte da mal ne Frage:

Ist es theoretisch möglich, mit iptables IP packete so zu verändern,
daß bei connections auf einen bestimmten TCP port die destination IP durch eine andere geändert wird?
Ich habe im moment einen Linux Router (mit Debian 3.0), der einen Windows PC ins Internet bringt.
Soll also so ablaufen:

(Beispiel)
- Der PC will sich auf die Addresse 2.2.2.2 Tcp Port 4000 connecten
- iptables soll die Verbindung nun aber nicht an 2.2.2.2:4000 im Internet weiterleiten, sondern an die 2.2.2.3 Port 4000

Geht sowas? Wenn ja, wie :roll:

mfg
as69

Martin Breidenbach · 30 Okt. 2004

Mit DNAT.

Sowas macht man z.B. bei Squid als Transparent Proxy - alles was mit Ziel Port 80 rausgeht zum Proxy umleiten.

as69 · 30 Okt. 2004

Danke schonmal.
Hat mich schonmal ein bisschen weitergebracht.
Habe nun auf Netfilter.org folgendes Beispiel gefunden:

## Aendern der Zieladresse von Webtraffic auf 5.6.7.8 Port 8080
# iptables -t nat -A PREROUTING -p tcp --dport 80 -i eth1 \
-j DNAT --to 5.6.7.8:8080

Für mein Beispiel wäre das dann:

iptables -t nat -A PREROUTING -p tcp --dport 4000 -i eth0
-j DNAT --to <inter.net.ip.address>:4000

Ist das das, was du meintest?

Martin Breidenbach · 30 Okt. 2004

Ja, sowas meinte ich.

as69 · 30 Okt. 2004

Hm scheint noch nicht so ganz zu funktionieren.

Habe also folgendes gemacht:

Datei fwscript erstellt und nach dem booten und erfolgreichem einwählen ins Internet die Datei aufgerufen/ausgeführt. Folgendes steht da drin (ist erstmal nur für Testzwecke, daher keine Sicheheit eingebaut)

Code:

via-salsa:/home/as69# more /root/fwscript
#!/bin/sh

echo 1 > /proc/sys/net/ipv4/ip_forward


iptables -t nat -A POSTROUTING -o ppp0 -s 192.168.0.0/16 -j MASQUERADE

iptables -A FORWARD -i ppp0 -d 192.168.0.0/24 -j ACCEPT

iptables -A FORWARD -o ppp0 -p TCP --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

iptables -t nat -A PREROUTING -i ppp0 -p TCP --dport 4662 -j DNAT --to-destination 192.168.0.1
iptables -t nat -A PREROUTING -i ppp0 -p UDP --dport 5662 -j DNAT --to-destination 192.168.0.1
iptables -t nat -A PREROUTING -p tcp --dport 4000 -i eth0 -j DNAT --to 213.248.106.55:4000

Wenn ich nun mit dem entsprechenden Programm eine Verbindung aufbaue, dann setzt mir iptables dies jedoch (scheinbar?) nicht um.
Ich habe mal auf der ppp0 Schnittstelle einen tcpdump mitlaufen lassen:

Code:

via-salsa:/home/as69# cat sniffer1 | grep ".4000:"
21:17:30.592609 217.235.236.195.3432 > 213.248.106.88.4000: S 1960959428:1960959428(0) win 32767 <mss 1452,nop,wscale 0,nop,nop,sackOK> (DF)
21:17:30.693565 217.235.236.195.3432 > 213.248.106.88.4000: . ack 1 win 32767 (DF)
21:17:30.818500 217.235.236.195.3432 > 213.248.106.88.4000: P 1:30(29) ack 3 win 32765 (DF)
21:17:31.028389 217.235.236.195.3432 > 213.248.106.88.4000: . ack 12 win 32756 (DF)
21:17:31.597696 217.235.236.195.3432 > 213.248.106.88.4000: P 30:39(9) ack 12 win 32756 (DF)
21:17:31.695836 217.235.236.195.3432 > 213.248.106.88.4000: P 39:40(1) ack 12 win 32756 (DF)
21:17:31.844707 217.235.236.195.3432 > 213.248.106.88.4000: . ack 339 win 32429 (DF)
21:17:31.870070 217.235.236.195.3432 > 213.248.106.88.4000: . ack 1389 win 31379 (DF)
21:17:31.959680 217.235.236.195.3432 > 213.248.106.88.4000: . ack 2439 win 32767 (DF)
21:17:31.985811 217.235.236.195.3432 > 213.248.106.88.4000: . ack 3511 win 31695 (DF)
21:17:32.002376 217.235.236.195.3432 > 213.248.106.88.4000: . ack 4176 win 32767 (DF)
21:17:32.632887 217.235.236.195.3432 > 213.248.106.88.4000: . ack 4192 win 32751 (DF)
21:17:32.836036 217.235.236.195.3432 > 213.248.106.88.4000: . ack 4216 win 32727 (DF)
21:17:33.307335 217.235.236.195.3432 > 213.248.106.88.4000: . ack 4239 win 32704 (DF)
21:17:33.601649 217.235.236.195.3432 > 213.248.106.88.4000: . ack 4255 win 32688 (DF)
21:17:33.910101 217.235.236.195.3432 > 213.248.106.88.4000: . ack 4278 win 32665 (DF)
21:17:34.148499 217.235.236.195.3432 > 213.248.106.88.4000: . ack 4291 win 32652 (DF)
21:17:34.385613 217.235.236.195.3432 > 213.248.106.88.4000: . ack 4318 win 32625 (DF)
21:17:34.549629 217.235.236.195.3432 > 213.248.106.88.4000: . ack 4344 win 32599 (DF)
21:17:34.898523 217.235.236.195.3432 > 213.248.106.88.4000: . ack 4367 win 32576 (DF)
21:17:35.226623 217.235.236.195.3432 > 213.248.106.88.4000: . ack 4378 win 32565 (DF)
21:17:35.706580 217.235.236.195.3432 > 213.248.106.88.4000: . ack 4401 win 32542 (DF)
21:17:36.304740 217.235.236.195.3432 > 213.248.106.88.4000: . ack 4413 win 32530 (DF)
21:17:36.523526 217.235.236.195.3432 > 213.248.106.88.4000: . ack 4424 win 32519 (DF)
21:17:36.539092 217.235.236.195.3432 > 213.248.106.88.4000: P 40:49(9) ack 4424 win 32519 (DF)
21:17:36.785629 217.235.236.195.3432 > 213.248.106.88.4000: . ack 4443 win 32500 (DF)
via-salsa:/home/as69#

Hm...ich weiß jetzt nicht so recht woran es scheiter.
Komisch ist aber auch, wenn ich mir mittels iptables --list die aktiven Regeln anschaue, bekomm ich nur folgendes zu sehen:

Code:

via-salsa:/home/as69# iptables --list
Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination
ACCEPT     all  --  anywhere             192.168.0.0/24
TCPMSS     tcp  --  anywhere             anywhere           tcp flags:SYN,RST/SYN TCPMSS clamp to PMTU

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
via-salsa:/home/as69#

Müsste da bei output nicht auch was drinstehen??

mfg

Martin Breidenbach · 30 Okt. 2004

Die NAT-Regeln werden so nicht angezeigt. Da muß man eingeben:

iptables -t nat -L

Mach mal ne FORWARD Regel rein die das 'verbogene' auch durchläßt.

Aber was soll das Ganze eigentlich ?

Port 4000 ist Battlenet und die IP gehört Blizzard Entertainment.

Für Battlenet muß man doch nix verbiegen ?

Wobei mir einfällt ich müßte so langsam mal wieder meine Diablo II Accounts wiederbeleben sonst sind die wech...

as69 · 30 Okt. 2004

Hehe genau 8)
Also auch ein D2-Zocker.
Vermutlich wirst du mich gleich dafür hassen und mir nicht mehr weiterhelfen aber:

Es gibt ja seit dem 1.10er Patch den Diablo Clone, der den Vernichtikus droppt. Nun haben sich einige Leute dazu aufgemacht,
alle Server, die "hot" sind (also auf denen SOJ's verkauft werden/wurden) in ein Forum zu posten.
Man kann mittels netstat -n den Server herausfinden, auf welchen man connected ist. Und zwar bei jedem neuen Spiel daß man erstellt, kommt man per round-robin auf nen anderen Server (so vermute ich das mal).
was ich nun machen möchte:
Ich suche mir in den Foren nen Sever raus der Hot ist, trage den in meine Nat Tabelle ein (also daß mein PC dann IMMER auf diesen Server geht, anstatt auf einen, der per Round Robin ausgewählt wurde)...nunja, wo hier der Vorteil liegt dürfte klar sein

==> man muß nicht 200 games erstellen bis man mal auf so nem Server ist.

Martin Breidenbach · 30 Okt. 2004

Grmpf...

as69 · 30 Okt. 2004

Martin Breidenbach schrieb:
Die NAT-Regeln werden so nicht angezeigt. Da muß man eingeben:

iptables -t nat -L

OK, also mit iptables -t nat -L seh ich jetzt den Eintrag.

Martin Breidenbach schrieb:
Mach mal ne FORWARD Regel rein die das 'verbogene' auch durchläßt.
....................

Aber: Das versteh ich jetzt nicht so ganz?
Wie meinst du das?
Es soll ja folgendes gemacht werden:

1) Nat'te die 192.168.0.x Addressen auf die IP des ppp0
2) Verändere die ZIEL-IP-Addresse, wenn ein packet auf tcp port 4000 zugreifen möchte. Er lässt die "normale" Addresse auch durch, mir scheint es im moment so zu sein, daß er die Addresse gar nicht umsetzt (siehe tcpdump auszug weiter oben)

Mal kurz zum Vertändnis, ob ich des auch gerafft habe:

Code:

echo 1 > /proc/sys/net/ipv4/ip_forward

==> Hier wird das Routing an sich aktiviert

Code:

iptables -t nat -A POSTROUTING -o ppp0 -s 192.168.0.0/16 -j MASQUERADE

==> Schaltet NAT ein, und zwar alles was im Bereich 192.168.0.0/16 liegt wird auf die IP des ppp0 genattet

Code:

iptables -A FORWARD -i ppp0 -d 192.168.0.0/24 -j ACCEPT

==> Alles was von "draussen" reinkommt, ist erlaubt (oha...)

Code:

iptables -A FORWARD -o ppp0 -p TCP --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

==> Dies scheint wohl ne Anpassung ans DSL (PPPoE) zu sein

Code:

iptables -t nat -A PREROUTING -i ppp0 -p TCP --dport 4662 -j DNAT --to-destination 192.168.0.1
iptables -t nat -A PREROUTING -i ppp0 -p UDP --dport 5662 -j DNAT --to-destination 192.168.0.1

==> Könnt ich auch weglassen, ist halt aus dem Beispiel => Leitet Anfragen auf die Ports 4662 und 5662 an meinen Windows Rechner weiter

Code:

iptables -t nat -A PREROUTING -p TCP --dport 4000 -i eth0 -j DNAT --to 213.248.106.55:4000

==> Ja, des wäre halt des, um was es geht...

Wo/wie/warum muß ich da jetzt noch ne forward-regel für das "verbogene" einrichten?

P.S. mir gehts nicht darum, dann jeden Tag 10 Stunden im Bnet zu verbringen und da Clonehunting zu machen...nein, es geht mir nur ums Prinzip...ob es theoretisch möglich ist...(und praktisch natürlich auch *g*).
Hatte doch noch nie des Vergnügen mit dem Clone

[/code]

gaw · 31 Okt. 2004

Was Martin meint, ist das das Destination NAT allein nicht ausreicht, du musst in der FORWARD Chain auch noch festlegen, dass der Zugang vom Rechner zu deinem Spieleserver erlaubt ist.
Im einfachsten Fall ohne statefull inspection sieht das etwa so aus:

Code:

/usr/sbin/iptables -A FORWARD -o ppp0 -p TCP --dport 4662 -j ACCEPT

Besser wäre aber ein Regelpaar, so etwas wie:

Code:

/usr/sbin/iptables -A FORWARD -o ppp0 -s 192.168.0.1 -d $IP_SPIELESERVER -p TCP --sport 1024:65535 --dport 4662 \ 
-m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
/usr/sbin/iptables -A FORWARD -i ppp0 -d 192.168.0.1 -s $IP_SPIELESERVER -p TCP --sport 4662 --dport 1024:65535 \ 
-m state --state ESTABLISHED,RELATED -j ACCEPT

Gesetzt den Fall dein Spielerechner hat die IP 192.168.0.1. Vorausgesetzt auch, dass battlenet nur über ein Socket aus definierten Port und einem zweiten freien Port verläuft, wie bei den meisten TCP oder UDP-Verbindungen üblich. Es gibt aber auch Spiele, in denen beide Ports eines Sockets festgelegt sind, ich kenne battlenet nicht. So etwas lässt sich aber leicht anpassen.

Du solltest aber deine Firewall einer dringenden Revision unterziehen. Die ist bei deiner oha Regel keine -wall mehr sondern bestenfalls eine Ruine mit ein paar Stützpfeilern als kümmerliche Reste.

mfG
gaw

as69 · 31 Okt. 2004

gaw schrieb:
Du solltest aber deine Firewall einer dringenden Revision unterziehen. Die ist bei deiner oha Regel keine -wall mehr sondern bestenfalls eine Ruine mit ein paar Stützpfeilern als kümmerliche Reste.

mfG
gaw

Hi estmal und danke auch für die Antwort.
Nun ja, im oment ist das ganze ja noch gar keine Firewall, es wird ja nichts geblockt etc. Im moment ist es ein einfacher Router, der Nat macht. Habs ja gestern erst aufgesetzt, nachdem ich endlich eine Distribution (Debian 3.0r2) gefunden habe, die mein Via Nehemia System ordentlich unterstützt...hatte es dummerweise immer mit RedHat 9.0 und Suse 9.0 und 9.1 versucht, die jedoch den Kernel scheinbar zu stark an die neuen CPU's angepasst haben und die Nehemia CPU sich da wohl etwas komisch benimmt (sprich: Gibt sich als 686 CPU aus, obwohl sie mehr oder weniger ne Mischung aus 486/586 ist). Bisher ging ich nur über DFÜ Verbindung im Windows ins Internet...das Windows System ist aber schon einigermassen abgesichert (Dienste deaktiviert, keine Freigaben, Virenscanner, Mozilla statt IE (also nix mit ActiceX), aufpassen wo man hinklickt beim surfen etc...).

Werde mal deinen Vorschlag ausprobieren.
Kann man eigentlich iptables irgendwie "debuggen" oder so?
Also daß ich z.b. sehe, welche Regeln matchen, wenn ein packet daherkommt?

mfg

gaw · 31 Okt. 2004

iptables -L ist eine Möglichkeit. Ich mache es anders. Abgelehnte Pakete werden in eine eigene Kette umgeleitet bevor sie verworfen werden. Dort werden Adressen und Portnummer der verworfenen Pakete geloggt. Das ganze solltest du ziemlich zu Anfang eines Iptables-Skript setzen, nachdem alle vorherigen Regeln verworfen wurden:

Code:

# Hier wird die Firewall initialisiert Variabeln festgelegt usw.
....
....
# Hier wird eine neue Kette TRASH erzeugt
/usr/sbin/iptables -N TRASH
# Vorher alles nach drop was nicht geloggt werden soll zum Beispiel:
/usr/sbin/iptables -A TRASH -p TCP --dport 445 -j DROP

# Anschließend ausführen wie die Pakete geloggt werden sollen
/usr/sbin/iptables -A TRASH -p ICMP -j LOG --log-prefix "Abgelehnte-ICMP-Pakete "
/usr/sbin/iptables -A TRASH -p UDP  -j LOG --log-prefix "Abgelehnte-UDP-Pakete "
/usr/sbin/iptables -A TRASH -p TCP  -j LOG --log-prefix "Abgelehnte-TCP-Pakete "
/usr/sbin/iptables -A TRASH -j DROP

# Hier kommen die anderen Regeln nach dem Prinzip es darf nur durch was erlaubt wird 
...
...
# und zum Schluss wird alles nach Trash geschickt was nicht erlaubt wurde
/usr/sbin/iptables -A INPUT   -j TRASH
/usr/sbin/iptables -A FORWARD -j TRASH
/usr/sbin/iptables -A OUTPUT  -j TRASH

Das ganze funktioniert zuverlässig wenn du alles was du sonst mit drop ins Datennirwana sendest nun einfach in die Kette TRASH verfrachtest. Je nach syslogd Einstellung lässt sich dann mit

tail -f /var/log/messages

der Paketfilter während der Arbeit beobachten. Im xterm erscheint dann folgendes Bild:

Code:

Oct 31 15:30:56 duron kernel: Abgelehnte-TCP-Pakete IN=ppp0 OUT= MAC= SRC=212.212.212.212 DST=123.123.123.123 LEN=48 TOS=0x00 PREC=0x00 TTL=118 ID=56303 DF PROTO=TCP SPT=2898 DPT=5554 WINDOW=16384 RES=0x00 SYN URGP=0
Oct 31 15:30:59 duron kernel: Abgelehnte-TCP-Pakete IN=ppp0 OUT= MAC= SRC=218.65.78.197 DST=123.123.123.123 LEN=48 TOS=0x00 PREC=0x00 TTL=118 ID=57142 DF PROTO=TCP SPT=3695 DPT=9898 WINDOW=16384 RES=0x00 SYN URGP=0
Oct 31 15:31:47 duron kernel: Abgelehnte-TCP-Pakete IN=ppp0 OUT= MAC= SRC=234.234.234.234 DST=123.123.123.123 LEN=48 TOS=0x00 PREC=0x00 TTL=116 ID=42461 DF PROTO=TCP SPT=2074 DPT=2745 WINDOW=8760 RES=0x00 SYN URGP=0
Oct 31 15:31:50 duron kernel: Abgelehnte-TCP-Pakete IN=ppp0 OUT= MAC= SRC=234.234.234.234 DST=123.123.123.123 LEN=48 TOS=0x00 PREC=0x00 TTL=116 ID=42631 DF PROTO=TCP SPT=2074 DPT=2745 WINDOW=8760 RES=0x00 SYN URGP=0
Oct 31 15:31:56 duron kernel: Abgelehnte-TCP-Pakete IN=ppp0 OUT= MAC= SRC=234.234.234.234 DST=123.123.123.123 LEN=48 TOS=0x00 PREC=0x00 TTL=116 ID=42949 DF PROTO=TCP SPT=2074 DPT=2745 WINDOW=8760 RES=0x00 SYN URGP=0

(Die Adressen 123.123.123.123, 212.212.212.212 und 234.234.234.234 wurden von mir anstand der Originaladressen eingesetzt worden, alles andere ist original. 123.123.123.123 steht für die Adresse vom Provider, die anderen beiden waren gültige Internetadressen die mir nicht bekannt waren)

Durch Ctrl-C kommt man von tail -f zrück auf die shell des xterminals.
Das Beobachten Paket für Paket was iptables gerade ablehnt, kann faszinierend werden, zum Beispiel wenn du gerade eine frische IP vom ISP bekommen hast. Mitunter war der vorher in emule und du wirst auf einmal mit Anfragen regelrecht bombardiert, weil irgendwo ein Client es noch nicht wahrhaben will, das sein download bei 99,9% abgeschossen wurde.

Wenn alles läuft, nehm ich bestimmte Pakete aus dem Loggin heraus, wie Broadcastabfragen aus dem LAN u.a. einfach damit die Logdateien nicht zu sehr anwachsen. Viel Spaß beim Nachbauen

mfg
gaw

as69 · 31 Okt. 2004

Oh man, bin ich :shock:
Vor lauter natting etc. gar nicht den eigentlichen Fehler gesehen:

wenn man folgendes hat:

Code:

via-salsa:~# ifconfig
eth0      Link encap:Ethernet  HWaddr 00:50:22:B5:27:25
          inet addr:192.168.1.1  Bcast:192.168.1.255  Mask:255.255.255.0
         .......

eth1      Link encap:Ethernet  HWaddr 00:40:63:C4:B1:41
          inet addr:192.168.0.10  Bcast:192.168.0.255  Mask:255.255.255.0
         ........

und der PC auch im 192.168.0.x/24 Netz hängt, dann sollte man nicht folgendes machen:

Code:

iptables -t nat -A PREROUTING -p TCP --dport 4000 -i eth0 -j DNAT --to 213.248.106.55:4000

sondern:

Code:

iptables -t nat -A PREROUTING -p TCP --dport 4000 -i eth1 -j DNAT --to 213.248.106.55:4000

*mitdemkopfgegendiewandschlag*

Naja, das Natting funktioniert jetzt, jedoch hat Blizzard dies wohl intern schon schön brav abgesichert...jedenfalls kann ich kein Game erstellen, wenn die Regel aktiv ist..die Server merken sich also scheinbar schon irgendwie, auf welchen Server man ein Spiel erstellt...

Wenigstens weiß ich jetzt, wie's geht! (auch wenn der Zweck, für den es gedacht war, nicht erfüllt wird)

danke an alle!!

mfg
as69

as69 · 31 Okt. 2004

gaw schrieb:
iptables -L ist eine Möglichkeit. Ich mache es anders. Abgelehnte Pakete werden in eine eigene Kette umgeleitet bevor sie verworfen werden. Dort werden Adressen und Portnummer der verworfenen Pakete geloggt. Das ganze solltest du ziemlich zu Anfang eines Iptables-Skript setzen, nachdem alle vorherigen Regeln verworfen wurden:

Code:

....

Das ganze funktioniert zuverlässig wenn du alles was du sonst mit drop ins Datennirwana sendest nun einfach in die Kette TRASH verfrachtest. Je nach syslogd Einstellung lässt sich dann mit tail -f /var/log/messages der Paketfilter bei der Arbeit beobachten. Du siehst Paket für Paket was er ablehnt, das kann faszinierend werden wenn du gerade eine frische IP vom ISP bekommen hast. Mitunter war der vorher in emule und du wirst auf einmal mit Anfragen regelrecht bombardiert, weil irgendwo ein Client es noch nicht wahrhaben will, das sein download bei 99,9% abgeschossen wurde.

Wenn alles läuft, nehm ich bestimmte Pakete aus dem Loggin heraus, wie Broadcastabfragen aus dem LAN u.a. einfach damit die Logdateien nicht zu sehr anwachsen.

mfg
gaw

Dankeschön noch für diesen Tip....sowas werde ich dann auch einrichten, um zu sehen, wer versucht, bei mir auf die Windows-Filesharing Ports (135-137 glaub ich) zuzugreifen...

Mittels iptables eine destination IP Addresse ändern

as69

Newbie

Martin Breidenbach

Ultimate Guru

as69

Newbie

Martin Breidenbach

Ultimate Guru

as69

Newbie

Martin Breidenbach

Ultimate Guru

as69

Newbie

Martin Breidenbach

Ultimate Guru

as69

Newbie

gaw

Hacker

as69

Newbie

gaw

Hacker

as69

Newbie

as69

Newbie