Tunnel-Ersatz mit iptables

[SeeksTheMoon]

Helft mir mal bitte, ob folgender Gedanke klappen kann:

Hintergrund:
------------
Ein Bekannter von mir sitzt in einem LAN, das externe Zugriffe nur auf die Ports 443 und 80 gestattet.

Bei mir läuft auf einem Server ein apache und der belegt diese Ports. ssh ist für den Bekannten also nicht möglich, weil das ja auf dem Server auf 22 läuft.
Wir haben es mal über einen Tunnel versucht und das hat auch geklappt, aber das nimmt dem apachen einen Port weg. Wir wollen beides: ssh-Zugriff und dem apachen seinen Frieden (es sollen ja auch noch andere Leute auf den apachen zugreifen können)

Idee:
-----
Ich glaube, ich hab eine Möglichkeit gefunden, wie man ohne Tunneln auf ssh zugreifen kann (nämlich per iptables auf dem Server):

Der Bekannte startet bei sich seinen ssh-Client um auf meinen Server zu kommen, aber mit Zielport 80, wo eigentlich mein Apache läuft.
Seine TCP-Pakete kommen in diesem Fall von seinem Port 22 (richtig?).
Wenn ja, kann ich das doch bei mir umleiten:

iptables --table nat --append PREROUTING --protocol tcp --destination-port 80 --source-port 22 -jump DNAT --to localhost:22

Dieser Befehl leitet einkommende Pakete, die vom Senderport 22 kommen (also von seinem SSH-Client) und auf den lokalen 80er Port gehen (also den web-Server) auf den lokalen 22er um (also meinen sshd auf dem Server).

Würde das gehen?


Erweiterung:
------------
Das könnte man dann noch um seine IP- oder MAC-Adresse erweitern, oder mit Type of Service nur auf ssh-Anfragen beschränken, um es noch restriktiver zu machen.
Normale Anfragen auf Port 80 sollten nach wie vor klappen, z.B, per Webbrowser, aber alles von seinem ssh-Client sollte umgeleitet werden.


Stimmts?

[geronet]

>Seine TCP-Pakete kommen in diesem Fall von seinem Port 22 (richtig?)

Nein, der Zielport ist normalerweise 22. Der Sourceport ist meist > 1024.

Grüsse, Stefan

[SeeksTheMoon]

und ginge das mit Type of Service?
Ist sein ausgehender ssh-Port immer gleich?

[geronet]

Ich würd's eher mit seiner IP-Adresse machen. Mit TOS würde es vielleicht auch gehen.

[Temp]

coole Idee....

wenn ihr ne Erfoglsmeldung habt postet ihrs bitte????

Gruß Temp

[N.D.]

Hi!

Wieso macht Ihr das eigentlich so umständlich
Du könntest doch einfach auch den Zugriff auf den 22er Port nur von seiner IP / MAC gestatten.
Dann würde man sich diese Umleitung doch sparen können, oder?

Schönen Tag noch!

[Temp]

sonnst kommt man doch nicht aus dem firmennetzwerk raus.... zielport von dem muss port 80 sein.... denk ich jetzt mal

Gruß Temp

[Thomas]

Denke ich auch.

Da über Port 80 sowohl HTTP als auch SSH erreichbar sein soll (?) ist eine Filterung über die IP wohl auch nicht möglich.


Thomas.

[eddi5]

gibt es zu dem problem eine lösung,wäre sehr dankbar habe nämlich das gleiche....
mfg eddi5

[canis_lupus]

In der letzten c't gab es einen Artikel zum Portknocking. Ähnliches realisiert die Software SADoor.
Idee: Bevor man den Dienst nutzt "programmiert" man die Firewall durch eine Knocking-Sequenz um, z.B.

Ping mit einer bestimmten Paketlänge schaltet Forwarding ab (80->HTTP)
Ping mit einer normalen Paketlänge schaltet Forwarding ein (80->SSH)

[cane]

Ping mit einer bestimmten Paketlänge schaltet Forwarding ab (80->HTTP)
Ping mit einer normalen Paketlänge schaltet Forwarding ein (80->SSH)

Dann wird die Freischaltung ja bei jedem Ping aktiv...

Nicht so toll...

cane

[canis_lupus]

War als Beispiel gedacht. Wenn man das durchzieht, kann man sich ja die verrücktesten Kombinationen einfallen lassen.
Wenn ich mich recht erinnere, kann man mit SADoor nach allen IP/ICMP/TCP/UDP-Charakteristiken suchen.
Wen man das Script selbst schreibt (bsp. mit tcpdump) stehen einem ja alle Filtermöglichkeiten offen.
Man muss nur daran denken, das die Knockingsequenz relativ einfach zu erzeugen sein sollte und das die Pakete während des Transports verändert werden.

[cane]

Wen man das Script selbst schreibt (bsp. mit tcpdump) stehen einem ja alle Filtermöglichkeiten offen.
Man muss nur daran denken, das die Knockingsequenz relativ einfach zu erzeugen sein sollte und das die Pakete während des Transports verändert werden.

1. Man braucht das Script nicht selbst schreiben sondern kann den Client anpassen.

2. Wieso einfach zu erzeugen - je komplexer desto besser...

3. Inwiefern werden Pakete verändert - gibt es router die Flags entfernen?

cane

[canis_lupus]

cane[QUOTE]

1. Man braucht das Script nicht selbst schreiben sondern kann den Client anpassen.

Welchen Client?

cane

2. Wieso einfach zu erzeugen - je komplexer desto besser...

Hier muss man abwägen. Je komplexer desto besser ist schon richtig. Aber welche Kenntnisse und Möglichkeiten hat der Bekannte im anderen LAN?

cane

3. Inwiefern werden Pakete verändert - gibt es router die Flags entfernen?

Was ist z.B. mit der TTL oder IP-Optionen bzw. einer eventuelle Fragmentierung?

[cane]

Hier muss man abwägen. Je komplexer desto besser ist schon richtig. Aber welche Kenntnisse und Möglichkeiten hat der Bekannte im anderen LAN?

Du hast das Prinzip nicht verstanden - siehe nächster Punkt...

Welchen Client?

Schau Dir die Implementierungen im Downloadbereich von www.portknocking.org an. Es existieeren o.g. in Perl, C/C++, Java, Python und ein Bash Script... Es muß niemand "von Hand" Pakete bauen...

Was ist z.B. mit der TTL oder IP-Optionen bzw. einer eventuelle Fragmentierung?

Wer nach TTL filtert hat das Prinzip Routing nicht verstanden. Fragmentierung könnte Probleme geben aber es gibt ja genügend andere Flags...

mfg
cane