Active-FTP Nat
Norbert Jahn
ich habe mal den Test unter http://www.bedatec.de/ftpnat gemacht und mir
die technischen Details durchgelesen.
Was ich noch nicht verstehe:
Inwiefern ist das ein Problem von Active(!)-FTP? Ich weiss, dass in
diesem Fall die Daten-Verbindung vom FTP-Server ausgeht.
Aber wenn ich ein Java-Applet laufen lasse, dass einen FTP-Client
simuliert, könnte doch auch ein passive-ftp genügen.. der Port ist doch
so oder so anschließend offen. Und von innen den Port zu öffnen, ist ja
auch einfacher... von innen raus lassen die meisten dsl-router mit nat
doch meist alles..
Bin dankbar für jede Erleuchtung dazu!
Grüße,
Norbert
Lutz Donnerhacke
> Was ich noch nicht verstehe:
> Inwiefern ist das ein Problem von Active(!)-FTP? Ich weiss, dass in
> diesem Fall die Daten-Verbindung vom FTP-Server ausgeht.
Bei aktivem FTP wird die Datenverbindung von außen zu Dir aufgebaut,
bei passivem FTP wird die Datenverbindung von Dir nach außen aufgebaut.
Norbert Jahn
> bei passivem FTP wird die Datenverbindung von Dir nach außen aufgebaut.
Wie ich schrieb: Das weiss ich bereits.
Warum gibt es da eine Sicherheitslücke wie auf der Webseite geschildert
nur bei Active-FTP. Auch bei Passive-FTP ist der Port dann doch
irgendwann offen... das geschilderte Applet kann den Port mittels
passive-FTP doch auch von innen auf machen.
Der Port ist so oder so offen und bietet Angriffsfläche!
Norbert
Juergen Ilse
Norbert Jahn <nj...@gmx.de> wrote:
> ich habe mal den Test unter http://www.bedatec.de/ftpnat gemacht und mir
> die technischen Details durchgelesen.
> Was ich noch nicht verstehe:
> Inwiefern ist das ein Problem von Active(!)-FTP? Ich weiss, dass in
> diesem Fall die Daten-Verbindung vom FTP-Server ausgeht.
Ja. Die NAT-Engine im Router / inder Firewall /... liest einen TCP-Datenstrom
mit, den sie fuer einen Datenstrom einer FTP-Controlconnection haelt. Wenn das
was da drueber laeuft als entsprechendes "PORT" Kommando interpretiert wird,
wird daraufhin fuer die vermeintlich anstehende FTP-Datenconnection ein Loch
in den Paketfilter gebohrt. Soweit so gut, was aber, wenn der mitgelesene
Datenstrom gar kein Datenstrom einer FTP-Controlconnection war? Dann wird
ein Loch in den Paketfilter gebohrt und ein passendes Portforwarding einge-
richtet, obwohl gar keine FTP-Datenconnection ansteht, und der vermeintliche
FTP-Server kann auf diesem Port durch Firewall und NAT-Engine zum dahinter
stehenden Rechner durchdringen. Wenn dieser nun "zufaellig" auf diesem Port
auch einen Dienst laufen hat, ist dieser Dienst mit diesem Trick ggfs. trotz
NAT und Firewall erreichbar ...
Ich hoffe, es war einigermassen verstaendlich.
> Aber wenn ich ein Java-Applet laufen lasse, dass einen FTP-Client
> simuliert, könnte doch auch ein passive-ftp genügen.. der Port ist doch
> so oder so anschließend offen.
Nein. Fuer einen vom Client zum Server aufgebaute TCP-Connection muss auf
dem Client kein "listenig socket" aufgemacht werden (und wird i.d.R. auch
nicht).
> Und von innen den Port zu öffnen, ist ja auch einfacher...
Dank der Sicherheitsrichtlinien fuer die "Sandbox-Umgebung" in der das
Applet laeuft, kann es IIRC nicht unbedingt einen "listenig socket"
oeffnen und ebensowenig TCP-Verbindungen zu anderen Hosts als dem, von
dem es geladen wurde, aufmachen. Durch das simulieren einer FTP-Connection
(moeglicherweise koennte so etwas auch mit anderen Protokollen funktionieren,
die bei NAT auf einen "NAT-Helper" angewiesen sind, FTP ist nur das promi-
nenteste Beispiel, dass auch nahezu ueberall beruecksichtigt wird) kann
der NAT-Router ausgetrickst werden, doch "Portforwardings" zu installieren,
die vom Anwender weder benoetigt noch erwuenscht sind (aber einem poten-
tiellen Angreifer bei seinen Plaenen helfen koennten).
> von innen raus lassen die meisten dsl-router mit nat doch meist alles..
Ein Java-Applet unterliegt noch ziemlichen Einschraenkungen und kann
(im Gegensatz zu eienr von der lokalen Platte gestarteten Java-Applikation)
nicht alles im Netz machen: es laeuft in einer i.d.R. doch sehr restriktiven
Sandbox-Umgebung.
Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)
--
Ein Domainname (auch wenn er Teil einer Mailadresse ist) ist nur ein Name,
nicht mehr und nicht weniger ...
Andreas Beck
> ich habe mal den Test unter http://www.bedatec.de/ftpnat gemacht und mir
> die technischen Details durchgelesen.
> Was ich noch nicht verstehe:
> Inwiefern ist das ein Problem von Active(!)-FTP? Ich weiss, dass in
> diesem Fall die Daten-Verbindung vom FTP-Server ausgeht.
Und damit genau der Fall auftritt, den die sog. "Firewall" der Router
angeblich verhindern soll: Eine Verbindung von außen zu einem
ungeschützen Dienst.
> Aber wenn ich ein Java-Applet laufen lasse, dass einen FTP-Client
> simuliert, könnte doch auch ein passive-ftp genügen..
Wozu? Zum Angriff auf einen Dienst auf dem Client, der das Applet fährt?
Es geht hier wohlgemerkt nicht um "nach Hause telefonieren" o.ä. es geht
darum, ein wunschgemäßes Loch in die "Firewall" von NAT-Boxen stanzen zu
können. Und darüber dann einen Dienst anzugreifen.
CU, Andy
Florian Weimer
>> Bei aktivem FTP wird die Datenverbindung von außen zu Dir aufgebaut,
>> bei passivem FTP wird die Datenverbindung von Dir nach außen aufgebaut.
>
> Wie ich schrieb: Das weiss ich bereits.
>
> Warum gibt es da eine Sicherheitslücke wie auf der Webseite
> geschildert nur bei Active-FTP.
Die Sandbox läßt i.d.R. das Binden auf spezifische Quellports gar nicht
zu. Auch das Betriebssystem verhindert dies, wenn dort schon ein Dienst
läuft (und nur dieser Fall ist für einen Angriff interessant).
Rainer Zocholl
>Hallo,
>Norbert Jahn <nj...@gmx.de> wrote:
>> ich habe mal den Test unter http://www.bedatec.de/ftpnat gemacht und
>> mir die technischen Details durchgelesen.
>> Was ich noch nicht verstehe:
>> Inwiefern ist das ein Problem von Active(!)-FTP? Ich weiss, dass in
>> diesem Fall die Daten-Verbindung vom FTP-Server ausgeht.
>Ja. Die NAT-Engine im Router / inder Firewall /... liest einen
>TCP-Datenstrom mit, den sie fuer einen Datenstrom einer
>FTP-Controlconnection haelt. Wenn das was da drueber laeuft als
>entsprechendes "PORT" Kommando interpretiert wird, wird daraufhin fuer
>die vermeintlich anstehende FTP-Datenconnection ein Loch in den
>Paketfilter gebohrt. Soweit so gut, was aber, wenn der mitgelesene
>Datenstrom gar kein Datenstrom einer FTP-Controlconnection war? Dann
>wird ein Loch in den Paketfilter gebohrt und ein passendes
>Portforwarding einge- richtet, obwohl gar keine FTP-Datenconnection
>ansteht, und der vermeintliche FTP-Server kann auf diesem Port durch
>Firewall und NAT-Engine zum dahinter stehenden Rechner durchdringen.
>Wenn dieser nun "zufaellig" auf diesem Port auch einen Dienst laufen
>hat, ist dieser Dienst mit diesem Trick ggfs. trotz NAT und Firewall
>erreichbar ...
>Ich hoffe, es war einigermassen verstaendlich.
Wie ist das aber "anderrum", mit einem (passive) FTP server?
Der MUSS doch zulassen das ein Client einen Connect auf
einen von ihm spezifizierten Port machen kann?
Aber auch ein FTP server steht heute nicht unbedingt ohne NAT im Netz.
Natürlich kann (und wird) man den Portfilter/Ftpd-mapper anweisen nur
Port 3000...3500 dafür zu erlauben und die auch dem FTP sever miteilen
und darauf achten das in dem Bereich nicht "ausversehen" der IRCD läuft.
Aber das würde doch auch beim FTP-Client im aktive mode gehen?
Dann müsste der FTP-Admin seinen Server ja nicht soweit aufereissen.
Anyway:
WebDAV rulez.
Rainer
Bernd Eckenfels
> Wie ist das aber "anderrum", mit einem (passive) FTP server?
Das ist genau das Problem, entweder der Client oder der Server hat das
Problem. Bei Anonymen und vielbenutzten Servern ist die Entscheidung es dem
User einfach zu machen einfach, in andern Fällen ist das weniger einfach.
Aber man kann auch einfach komplett auf FTP verzichten.
> Der MUSS doch zulassen das ein Client einen Connect auf
> einen von ihm spezifizierten Port machen kann?
Ja und vor allem darf er dabei nicht auf den ftp-data port bestehen als
Absender Port.
Gruss
Bernd
Thomas Wildgruber
> [...]
> Natürlich kann (und wird) man den Portfilter/Ftpd-mapper anweisen nur
> Port 3000...3500 dafür zu erlauben und die auch dem FTP sever miteilen
> und darauf achten das in dem Bereich nicht "ausversehen" der IRCD läuft.
>
> Aber das würde doch auch beim FTP-Client im aktive mode gehen?
Aber der Paketfilter des Netzes, in dem der Client steht, müsste jedes mal
den Port zum Client forwarden. Dazu müsste aber die Firewall hinter der der
Client steht erkennen, dass es sich bei dem Verbindungsaufbau um eine
bereits bestehende FTP Session handelt. Das Stateful Inspection Modul
könnte/müsste dann für diese Verbindung dynamisch den Port öffnen, und zum
Client weiterleiten. Nicht jeder Paketfilter kann das, die ganze
Angelegenheit wäre somit sehr unzuverlässig.
> Dann müsste der FTP-Admin seinen Server ja nicht soweit aufereissen.
Je nachdem wie stark der Server beansprucht ist, kann er mehr oder weniger
(High) Ports definieren, vor allem aber kann er sich beser auf _seinen_ FTP
Server einstellen, wie der Firewalladmin bei dem der Client steht.
Bye Tom
--
"When you go with this speed of living, with 9.000 Miles per hour, you
cannot stop in a minute" (Björk, after she come to blows with a journalist,
1996 in Bangkok)
Norbert Jahn
> auch einen Dienst laufen hat, ist dieser Dienst mit diesem Trick ggfs. trotz
> NAT und Firewall erreichbar ...
Aha, eine Frage dazu: Wer legt denn den FTP-Data-Port auf meinem
Client-Rechner fest? Macht das immer mein OS, oder gibt es hier einen
Unterschied zwischen Active- und Passive-FTP?
Vielen Dank,
Norbert
Andreas Beck
>> Wenn dieser nun "zufaellig" auf diesem Port
>> auch einen Dienst laufen hat, ist dieser Dienst mit diesem Trick ggfs. trotz
>> NAT und Firewall erreichbar ...
> Aha, eine Frage dazu: Wer legt denn den FTP-Data-Port auf meinem
> Client-Rechner fest?
Der Client, wer sonst?
> Macht das immer mein OS,
Das hat in der Regel anderes zu tun, als sich um ein spezifisches
Protokoll auf Anwendungsebene zu kümmern. Modulo der üblichen "gib mir
einen zufälligen freien Port"-Methode.
> oder gibt es hier einen Unterschied zwischen Active- und Passive-FTP?
Natürlich. Bei active sagt der Client dem Server:
Ok, die Daten für den folgenden Request hätte ich gerne an die IP bla,
Port blubb zugestellt. Dort sollte ein "normaler" Client dann natürlich
auch lauschen. Für den FTP-NAT-Trick ist das aber gerade der Gag, dass
dort schon jemand anderes lauscht, den man durch das NAT geschützt
glaubte.
Bei passive teilt einem der Server eine IP und einen Port mit, auf dem
er selbst auf einen weiteren connect() lauscht. Das ist für den Client
dann nicht weiter gefährlich, weil man dazu nichts an der NAT-Zurodnung
rumpfuschen muss, weil rausgehende Verbindungen ja "einfach so"
funktionieren.
Auf der Serverseite ist es natürlich ggf. genau umgekehrt. Allerdings
kriegt man den Server zumeist nicht dazu, seltsame PASV-Antworten zu
generieren.
CU, Andy
Bernd Eckenfels
> Aha, eine Frage dazu: Wer legt denn den FTP-Data-Port auf meinem
> Client-Rechner fest? Macht das immer mein OS, oder gibt es hier einen
> Unterschied zwischen Active- und Passive-FTP?
Der Source Port wird normalerweise zufällig vergeben, bei FTP Servern gibt
es eine Verpflichtng, dass die Data Connection vom Port 20 kommen muss.
Diese Einschränkung wird aber inzwischen aufgelockert, weil nicht alle FTP
Server als Root laufen wollen.
Gruss
Bernd
Norbert Jahn
> Port blubb zugestellt. Dort sollte ein "normaler" Client dann natürlich
> auch lauschen. Für den FTP-NAT-Trick ist das aber gerade der Gag, dass
> dort schon jemand anderes lauscht, den man durch das NAT geschützt
> glaubte.
>
> Bei passive teilt einem der Server eine IP und einen Port mit, auf dem
> er selbst auf einen weiteren connect() lauscht. Das ist für den Client
> dann nicht weiter gefährlich, weil man dazu nichts an der NAT-Zurodnung
> rumpfuschen muss, weil rausgehende Verbindungen ja "einfach so"
> funktionieren.
Ahh, Moment.. ich glaube ich hab's gleich :-)
Wenn ich's recht kapiere:
Beim Active-FTP kann ich (oder das böse Applet) einen Befehl absetzen,
der z.B. Port 137 (Netbios) für den Daten-Kanal angibt. Darauf ist der
im NAT dann offen.
Beim Passive-FTP geht das nicht, weil ich vom Quellport 137 eine
Verbindung öffnen müsste, und das OS, der Stack, o.ä. das nicht zulässt,
weil bereits vergeben..
Stimmt das so? Mein Verständnisproblem lag ja darin, warum das bei
Active geht, und bei Passive nicht.
Vielen Dank!!!
Norbert
Bernd Eckenfels
> Beim Active-FTP kann ich (oder das böse Applet) einen Befehl absetzen,
> der z.B. Port 137 (Netbios) für den Daten-Kanal angibt. Darauf ist der
> im NAT dann offen.
Ja, wobei gute NAT-Helper keinen Port <1024 zulassen. Und bei schlechten ist
nicht mal ein Applet nötig, da reicht es ein HTML Form an Port 21 zu
"posten".
> Beim Passive-FTP geht das nicht, weil ich vom Quellport 137 eine
> Verbindung öffnen müsste, und das OS, der Stack, o.ä. das nicht zulässt,
> weil bereits vergeben..
Beim PASV geht es nicht weil beim PASV garkeine Verbindung eingehend
durchgelassen wird.
Gruss
Bernd
Norbert Jahn
Wow, das ist krass.. dass das so einfach gehen kann, war mir noch nicht
bewusst.
> Beim PASV geht es nicht weil beim PASV garkeine Verbindung eingehend
> durchgelassen wird.
Ja schon klar, aber das Applet könnte ja die Verbindung von innen
aufbauen. Auch dann wäre der Port im NAT offen.
Aber (und genau das ist mein Punkt): Die Verbindung von innen heraus
aufgebaut wäre nicht auf einem Client-Port möglich, wo bereits ein
Netbios-Dienst lauscht..
Oder ist es doch möglich eine Verbindung vom Client-Port 137 aufzubauen,
obwohl dort bereits eine andere Applikation lauscht. Falls nein, wer
verhindert das Aussenden eines IP-Packets, wo im Quellport 137 steht?
OS, Stack, o.ä.?
Grüße,
Norbert
Juergen P. Meier
>> Ok, die Daten für den folgenden Request hätte ich gerne an die IP bla,
>> Port blubb zugestellt. Dort sollte ein "normaler" Client dann natürlich
>> auch lauschen. Für den FTP-NAT-Trick ist das aber gerade der Gag, dass
>> dort schon jemand anderes lauscht, den man durch das NAT geschützt
>> glaubte.
>>
>> Bei passive teilt einem der Server eine IP und einen Port mit, auf dem
>> er selbst auf einen weiteren connect() lauscht. Das ist für den Client
>> dann nicht weiter gefährlich, weil man dazu nichts an der NAT-Zurodnung
>> rumpfuschen muss, weil rausgehende Verbindungen ja "einfach so"
>> funktionieren.
>
> Ahh, Moment.. ich glaube ich hab's gleich :-)
>
> Wenn ich's recht kapiere:
> Beim Active-FTP kann ich (oder das böse Applet) einen Befehl absetzen,
> der z.B. Port 137 (Netbios) für den Daten-Kanal angibt. Darauf ist der
> im NAT dann offen.
Soweit richtig. Relevant ist hier: der Port wird fuer einen
Verbindungsaufbau /von/ draussen nach drinnen freigeschaltet.
> Beim Passive-FTP geht das nicht, weil ich vom Quellport 137 eine
> Verbindung öffnen müsste, und das OS, der Stack, o.ä. das nicht zulässt,
> weil bereits vergeben..
Natuerlich koenntest du als lokalen Quellport auch 137 verwenden (so
es der Stack erlaubt). Da diese verbindung aber von innen nach aussen
aufgemacht wird, gibt es dennoch keine moeglichkeit, fuer jemanden
eine TCP Verbindung von aussen nach innen aufzumachen.
Paketfilter unterscheiden in der Richtung des Verbindungsaufbaus.
> Stimmt das so? Mein Verständnisproblem lag ja darin, warum das bei
> Active geht, und bei Passive nicht.
Weil Active-FTP eine TCP Verbindung vom Server (aussen) zum Client
(innen) vorsieht, passive hingegen nicht (alles ist von innen nach
aussen).
Aehnlich problematisch sind alle in dieser Hinsicht aehnlichen
Protokolle wie H.323, SIP, SOAP etc.
Juergen
--
Juergen P. Meier - "This World is about to be Destroyed!"
end
If you think technology can solve your problems you don't understand
technology and you don't understand your problems. (Bruce Schneier)
Andreas Beck
> Ja schon klar, aber das Applet könnte ja die Verbindung von innen
> aufbauen. Auch dann wäre der Port im NAT offen.
Das wäre eine relativ bizarre Konstruktion, zumindest bei TCP-Services.
Man müßte zunächst via SYN-Sequenz die Verbindung outbound aufmachen und
dann aber in der Antwort nochmal ne SYN senden, weil ja eigentlich der
lauschende Dienst auf dem Client angesprochen werden soll.
Das dürfte von besseren Statemachines in den NAT-Filtern verhindert
werden.
Bei UDP wäre es in der Regel problemlos.
> Aber (und genau das ist mein Punkt): Die Verbindung von innen heraus
> aufgebaut wäre nicht auf einem Client-Port möglich, wo bereits ein
> Netbios-Dienst lauscht..
Ja. Weil man mit normalen Userrechten kein solches Paket erzeugen kann.
Könnte man das, braucht man auch keinen speziellen FTP-Helper.
Vorstellbar ist aber z.B., dass man ein solches Paket aussendet _bevor_
der Dienst startet.
> Oder ist es doch möglich eine Verbindung vom Client-Port 137 aufzubauen,
> obwohl dort bereits eine andere Applikation lauscht. Falls nein, wer
> verhindert das Aussenden eines IP-Packets, wo im Quellport 137 steht?
> OS, Stack, o.ä.?
Das API zu den Netzwerkfunktionen, das mit Userrechten ansprechbar ist
erlaubt keine Doppelvergabe von Ports. Mit genug Rechten kann man
natürlich ein passendes Paket aussenden. Das ist dann aber schon
witzfrei, weil man den Rechner ja schon kontrolliert.
CU, Andy
Andreas Beck
> Norbert Jahn <nj...@gmx.de>:
>> Beim Passive-FTP geht das nicht, weil ich vom Quellport 137 eine
>> Verbindung öffnen müsste, und das OS, der Stack, o.ä. das nicht zulässt,
>> weil bereits vergeben..
> Natuerlich koenntest du als lokalen Quellport auch 137 verwenden (so
> es der Stack erlaubt). Da diese verbindung aber von innen nach aussen
> aufgemacht wird, gibt es dennoch keine moeglichkeit, fuer jemanden
> eine TCP Verbindung von aussen nach innen aufzumachen.
>
> Paketfilter unterscheiden in der Richtung des Verbindungsaufbaus.
Vernünftige schon. Hat das eigentlich mal jemand ausführlich getestet?
Ich habe Zweifel, ob die üblichen "Hauptsache funzt"-Implementierungen
in kleinen NAT-Boxen das korrekt machen.
UDP ginge auf jeden Fall. AFAIK ist das ja auch das, was bei SIP etc.
als "Firewall-Hole-Punching" bezeichnet wird.
Allerdings ist das Szenario nicht sonderlich wichtig. Auf den
Zielrechnern läuft dann schon Code mit ziemlich viel Rechten. Da braucht
man nicht noch andere Dienste angreifen bzw. kann das lokal machen.
> Aehnlich problematisch sind alle in dieser Hinsicht aehnlichen
> Protokolle wie H.323, SIP, SOAP etc.
Ack. Sollte man auch mal nen passenden Test zu verbrechen. "Call me to
get 0wn3d ...!ELF"
CU, Andy
Norbert Jahn
> aufgemacht wird, gibt es dennoch keine moeglichkeit, fuer jemanden
> eine TCP Verbindung von aussen nach innen aufzumachen.
>
> Paketfilter unterscheiden in der Richtung des Verbindungsaufbaus.
Oh, das wusste ich nicht.
Aber wie schaut es aus, wenn die Attacke als Response auf einen Request
von mir kommt?
1. Ich gehe auf eine Webseite, auf der sich ein böswilliges Applett
befindet, und nun ausgeführt wird.
2. Das Applett täuscht Passive-FTP vor, öffnet eine Command-Verbindung
vom lokalen Port 137 zum Server auf Port 21.
3. Der böse Server teilt seinen offenen FTP-Port 3267 mit.
4. Das Applett öffnet lokal einen Port und baut zum Server eine
Data-Verbindung auf 3267 auf.
Jetzt könnte doch ein Response-Paket reinkommen, das einen Dienst auf
meinem PC angreift, oder?
Verwirrt,
Norbert
Norbert Jahn
> dann aber in der Antwort nochmal ne SYN senden, weil ja eigentlich der
> lauschende Dienst auf dem Client angesprochen werden soll.
Ah moment, das heisst, die Response auf meinen ausgehenden SYN würde nur
wieder an das Applet gehen, und der NetBIOS-Dienst könnte nicht
angesprochen und somit angegriffen werden??
Ist es das, warum PASV sicherer ist?
Danke,
Norbert
PS: Wenn es so ist, dann warum? Hat der Stack nach meinem ausgehenden
SYN einen Session-Eintrag, der das böse Rückpaket wieder nur an den
Browser (wo das Applet läuft) zulässt?
Juergen P. Meier
> Juergen P. Meier wrote:
>> Norbert Jahn <nj...@gmx.de>:
>>> Beim Passive-FTP geht das nicht, weil ich vom Quellport 137 eine
>>> Verbindung öffnen müsste, und das OS, der Stack, o.ä. das nicht zulässt,
>>> weil bereits vergeben..
>> Natuerlich koenntest du als lokalen Quellport auch 137 verwenden (so
>> es der Stack erlaubt). Da diese verbindung aber von innen nach aussen
>> aufgemacht wird, gibt es dennoch keine moeglichkeit, fuer jemanden
>> eine TCP Verbindung von aussen nach innen aufzumachen.
>>
>> Paketfilter unterscheiden in der Richtung des Verbindungsaufbaus.
>
> Vernünftige schon. Hat das eigentlich mal jemand ausführlich getestet?
Bei vernuenftigen, ja.
> Ich habe Zweifel, ob die üblichen "Hauptsache funzt"-Implementierungen
> in kleinen NAT-Boxen das korrekt machen.
Die leiten ja schon beliebige Ports weiter, wenn man sie nur anschaut.
Von UnPNP gar nicht erst zu reden, das teilweise sogar von aussen
erreichbar ist. Fernsteuerung remote, klasse Idee.
> UDP ginge auf jeden Fall. AFAIK ist das ja auch das, was bei SIP etc.
> als "Firewall-Hole-Punching" bezeichnet wird.
Ja. Man sendet in der erlaubten Richtung ein UDP paket, um den
Rueckweg mit verdrehten Ports freizuschalten. UDP ist halt doch nicht
Verbindungsorientiert.
Juergen P. Meier
>> Da diese verbindung aber von innen nach aussen
>> aufgemacht wird, gibt es dennoch keine moeglichkeit, fuer jemanden
>> eine TCP Verbindung von aussen nach innen aufzumachen.
>>
>> Paketfilter unterscheiden in der Richtung des Verbindungsaufbaus.
>
> Oh, das wusste ich nicht.
> Aber wie schaut es aus, wenn die Attacke als Response auf einen Request
> von mir kommt?
Bei TCP geht das nicht.
Nur bei UDP, und damit scheidet FTP als Methode des Hole-Punchings
aus, denn damit lassen sich nur TCP ports freischalten.
> 1. Ich gehe auf eine Webseite, auf der sich ein böswilliges Applett
> befindet, und nun ausgeführt wird.
> 2. Das Applett täuscht Passive-FTP vor, öffnet eine Command-Verbindung
> vom lokalen Port 137 zum Server auf Port 21.
Und das wars auch schon. Es ist nicht moeglich, dann vom Server eine
TCP Verbindung zum lokal auf port 137 laufenden Dienst aufzumachen,
weil das eine neue TCP Verbindung ist, und der Paketfilter das SYN
Paket ablehnt. Er erlaubt nur ACK-Pakete, und mit denen kannst du
keine neue Ports aufmachen.
Norbert Jahn
> TCP Verbindung zum lokal auf port 137 laufenden Dienst aufzumachen,
> weil das eine neue TCP Verbindung ist, und der Paketfilter das SYN
> Paket ablehnt. Er erlaubt nur ACK-Pakete, und mit denen kannst du
> keine neue Ports aufmachen.
Aha, um einen laufenden Dienst anzusprechen ist es also nötig, eine
eigenständige Verbindung zu ihm aufzubauen. Das hieße, der Dienst
reagiert nur auf einen von extern kommenden SYN. Richtig? Ich glaube,
das war meine Denklücke.
Danke für die Erklärung!!
Ist es zudem auch noch so, dass Rückpakete wirklich nur an den
Browser-Prozess gereicht würden (wo das Applet läuft)? Welche Komponente
sorgt dafür? Ein Eintrag in die Sessiontabelle irgendwo beim Stack, der
die Verbindung dem Browser zuordnet?
Grüße,
Norbert
Juergen P. Meier
>> Und das wars auch schon. Es ist nicht moeglich, dann vom Server eine
>> TCP Verbindung zum lokal auf port 137 laufenden Dienst aufzumachen,
>> weil das eine neue TCP Verbindung ist, und der Paketfilter das SYN
>> Paket ablehnt. Er erlaubt nur ACK-Pakete, und mit denen kannst du
>> keine neue Ports aufmachen.
>
> Aha, um einen laufenden Dienst anzusprechen ist es also nötig, eine
> eigenständige Verbindung zu ihm aufzubauen. Das hieße, der Dienst
> reagiert nur auf einen von extern kommenden SYN. Richtig? Ich glaube,
Ja. Genauer reagiert der IP Stack auf ein SYN, und macht nach
erfolgtem 3-Wege Handshake die Verbindung zum Dienst auf.
> das war meine Denklücke.
> Danke für die Erklärung!!
> Ist es zudem auch noch so, dass Rückpakete wirklich nur an den
> Browser-Prozess gereicht würden (wo das Applet läuft)? Welche Komponente
Ja.
> sorgt dafür? Ein Eintrag in die Sessiontabelle irgendwo beim Stack, der
> die Verbindung dem Browser zuordnet?
Der TCP/IP Stack macht das, es ist Grundlage seiner Funktoin.
Bernd Eckenfels
> Ist es zudem auch noch so, dass Rückpakete wirklich nur an den
> Browser-Prozess gereicht würden (wo das Applet läuft)? Welche Komponente
> sorgt dafür? Ein Eintrag in die Sessiontabelle irgendwo beim Stack, der
> die Verbindung dem Browser zuordnet?
Ja, anhand des eindeutigen tupels source-ip/port+destination-ip/port (das
bei Rückpaketen vertauscht ist) findet der kernel in der tabelle die du mit
netstat sehen kannst den socket, also letzteendes die prozesse die den
filedescriptor offen haben.
Gruss
Bernd
y
Juergen Ilse
Norbert Jahn <nj...@gmx.de> wrote:
>> da reicht es ein HTML Form an Port 21 zu "posten"
> Wow, das ist krass.. dass das so einfach gehen kann, war mir noch nicht
> bewusst.
>> Beim PASV geht es nicht weil beim PASV garkeine Verbindung eingehend
>> durchgelassen wird.
> Ja schon klar, aber das Applet könnte ja die Verbindung von innen
> aufbauen. Auch dann wäre der Port im NAT offen.
... und was waere darueber erreichbar (ausser dem Applet selbst)?
Eben, eigentlich nichts (wobei das Applet auf lokaler Seite noch nicht
einemal einen Port fuer die Connection binden koennte, auf dem bereits
lokal ein Server lauscht).
> Aber (und genau das ist mein Punkt): Die Verbindung von innen heraus
> aufgebaut wäre nicht auf einem Client-Port möglich, wo bereits ein
> Netbios-Dienst lauscht..
So ist es.
> Oder ist es doch möglich eine Verbindung vom Client-Port 137 aufzubauen,
> obwohl dort bereits eine andere Applikation lauscht. Falls nein, wer
> verhindert das Aussenden eines IP-Packets, wo im Quellport 137 steht?
Man muesste dazu ein "handgeneriertes Paket" ueber einen "RAW-Socket"
schleusen, und das duerfte von dem Applet aus gar nicht und von einem
lokal laufenden "vollwertigen Programm" nur mit root-Rechten gehen ...
(bzw. bei Windows "System-Rechten" oder so ...).
Erhard Schwenk
> Norbert Jahn <nj...@gmx.de>:
>>> Da diese verbindung aber von innen nach aussen
>>> aufgemacht wird, gibt es dennoch keine moeglichkeit, fuer jemanden
>>> eine TCP Verbindung von aussen nach innen aufzumachen.
>>>
>>> Paketfilter unterscheiden in der Richtung des Verbindungsaufbaus.
>> Oh, das wusste ich nicht.
>> Aber wie schaut es aus, wenn die Attacke als Response auf einen Request
>> von mir kommt?
>
> Bei TCP geht das nicht.
>
> Nur bei UDP, und damit scheidet FTP als Methode des Hole-Punchings
> aus, denn damit lassen sich nur TCP ports freischalten.
kaputte NAT-Implementierungen könnten allerdings das Protokoll
ignorieren und aus "Optimierungsgründen" Ports immer für TCP und UDP
freischalten.
--
Erhard Schwenk
Akkordeonjugend Baden-Württemberg - http://www.akkordeonjugend.de/
APAYA running System - http://www.apaya.net/