(TCP/IP Internal) Auf der Suche nach Mr. Spock

[Philipp Hasenfratz]

Halihallo Forumer

Bisher hab ich mich nur als "Anwender" an TCP/IP getraut... Jetzt tät ich mich gerne etwas mit den Internas von Bit's und Bytes beschäftigen und versuche zu verstehen, wie das ganze im Background abläuft. Im Internet habe ich auch schon vieles Gefunden, aber einige Antworten konnte ich mir bisher noch nicht beantworten und hoffe auf eurer Wissen... Sorry, dass ich euch mit sovielen Fragen belagere.

Ich habe ein lokales Netzwerk mit ISDN. Damit kann ich von jedem Computer aus ins Internet ( soviel hab ich schon mitgekriegt ;) ). Der Gateway/Router ist 192.168.1.1. Wenn ich nun von meinem Computer auf eine Website gehe, kommuniziert mein Computer mit dem Gateway, der seinerseits mit der "offiziellen IP" mit dem Provider Kontakt aufnimmt; dieser löst nun die ZielURL auf und findet die IP des Remote-Routers des Netzwerkes, wo der Server liegt und leitet den Request dorthin weiter. Der Router des Zielnetzwerkes leitet den Request an den Server weiter, wo er bearbeitet wird und dann geht alles rückwarts... Im TCP/IP-Header befindet sich ja die IP des Computers, der den Request zuletzt gestartet hat... Aber wie gelangt nun das Packet wieder zu mir zurück? - Ich habe ja keine "offizielle" IP; wie weiss mein Router, von welchem Computer aus (bei mir lokal 192.168.1.34) der Request gestartet ist? - Der TCP/IP - Header enthält doch nur eine einzige IP und nicht der ganze Routing-Schwanz an IP's, oder?

Anhand der IP kann die Herkunft des Requests bis auf Städte aufgelöst werden (naja, stimmt nicht ganz); warum haben die Provider ein Interesse daran und tun das so? - Die IP's werden ja vom Privder dynamisch festgelegt.

3. Wenn ich über'n Router in's Netz gehe und dort meine "offizielle" IP ansehe; wie kann man über diese IP direkt auf meinen Computer zurückgreifen? - Mit anderen Worten: Wenn ich die offizielle IP meines Routers des Klasse-C Netzwerkes kenne, kann ich bzw. wie kann ich dann auf meinen Computer zugreifen? - Müsste man hierzu einen eigenen TCP/IP - Header hard-coden?

4. Was ist ein Provider im Sinne von Netzwerk? - Ist das nix anderes, als ein Netzwerk mit einem Router, der an einem Backbone angeschlossen ist und die Requests an "virtuelle" Clients weiterleitet, die im physikalischen Sinne nicht existieren (die Daten werden eifach kodiert über die Telefon-/Standleitung übertragen)?

5. Datenrouting
      Je nach Request, wird das Datenpacket über verschiedene Netzwerke weitergeleitet. Das bedingt, dass der Rückweg irgendwo festgehalten werden muss. Wo wird dieser gespeichert? - Der Request-Header enthält doch nur Platz für eine "Rücksprungs" - IP, oder?

Viele Grüsse

Philipp

[Thorsten Strausbach]

Halihallo Forumer

Hi

Ich habe ja keine "offizielle" IP; wie weiss mein Router, von welchem Computer aus (bei mir lokal 192.168.1.34) der Request gestartet ist? - Der TCP/IP - Header enthält doch nur eine einzige IP und nicht der ganze Routing-Schwanz an IP's, oder?

Nein.
Raus: aus dem privaten Netz per NAT (Network Adress Translation)
Rein: Session Table - Paket zurück an den Router, der weiss, wer im privaten Netz gefragt hat

Anhand der IP kann die Herkunft des Requests bis auf Städte aufgelöst werden (naja, stimmt nicht ganz); warum haben die Provider ein Interesse daran und tun das so? - Die IP's werden ja vom Privder dynamisch festgelegt.

3. Wenn ich über'n Router in's Netz gehe und dort meine "offizielle" IP ansehe; wie kann man über diese IP direkt auf meinen Computer zurückgreifen? - Mit anderen Worten: Wenn ich die offizielle IP meines Routers des Klasse-C Netzwerkes kenne, kann ich bzw. wie kann ich dann auf meinen Computer zugreifen? - Müsste man hierzu einen eigenen TCP/IP - Header hard-coden?

Richtig, dann müsste aber ein Anfragepaket gefaket sein. Andere Alternative: Der Router leitet eine Port-Anfrage auf einen Rechner im internen Netz weiter, weil diese (laut Router) für die Port-Anfrage zuständig ist. Wenn auf dem rechner der Port auch noch offen ist, ist man auf dem Rechner drauf. 3e Alternative: Der Router hat eine Schwachstelle (wurde gehackt) und behandelt die Anfrage als Anfrage aus dem eigenen Netz.

4. Was ist ein Provider im Sinne von Netzwerk? - Ist das nix anderes, als ein Netzwerk mit einem Router, der an einem Backbone angeschlossen ist und die Requests an "virtuelle" Clients weiterleitet, die im physikalischen Sinne nicht existieren (die Daten werden eifach kodiert über die Telefon-/Standleitung übertragen)?

So könnte man es sagen.

5. Datenrouting
      Je nach Request, wird das Datenpacket über verschiedene Netzwerke weitergeleitet. Das bedingt, dass der Rückweg irgendwo festgehalten werden muss. Wo wird dieser gespeichert? - Der Request-Header enthält doch nur Platz für eine "Rücksprungs" - IP, oder?

Nein, es wird nur festgehalten, welche offizielle IP-Adresse die Daten angefordert hat. Der Rückweg des Pakets ist zunächst offen und muss neu bestimmt werden, wenn die Anfrage verarbeitet wurde.

Schöne Grüße
Thorsten Strausbach (Agentur 4e)

[Philipp Hasenfratz]

Halihallo Forumer

Ich habe ja keine "offizielle" IP; wie weiss mein Router, von welchem Computer aus (bei mir lokal 192.168.1.34) der Request gestartet ist? - Der TCP/IP - Header enthält doch nur eine einzige IP und nicht der ganze Routing-Schwanz an IP's, oder?
Nein.
Raus: aus dem privaten Netz per NAT (Network Adress Translation)
Rein: Session Table - Paket zurück an den Router, der weiss, wer im privaten Netz gefragt hat

Hm. Was wird in dieser Session Table festgehalten? - Ich frage deshalb, da es ja möglich wäre, dass zwei Computer dieselbe IP kontakten => wer soll welche Antwort erhalten? - Man müsste zur eindeutigen Identifikation doch einen uniquen Wert mit dem Header versenden, der eindeutig einem und nur einem Rechner zugeteilt ist, oder?

3. Wenn ich über'n Router in's Netz gehe und dort meine "offizielle" IP ansehe; wie kann man über diese IP direkt auf meinen Computer zurückgreifen? - Mit anderen Worten: Wenn ich die offizielle IP meines Routers des Klasse-C Netzwerkes kenne, kann ich bzw. wie kann ich dann auf meinen Computer zugreifen? - Müsste man hierzu einen eigenen TCP/IP - Header hard-coden?
   Richtig, dann müsste aber ein Anfragepaket gefaket sein. Andere Alternative: Der Router leitet eine Port-Anfrage auf einen Rechner im internen Netz weiter, weil diese (laut Router) für die Port-Anfrage zuständig ist. Wenn auf dem rechner der Port auch noch offen ist, ist man auf dem Rechner drauf. 3e Alternative: Der Router hat eine Schwachstelle (wurde gehackt) und behandelt die Anfrage als Anfrage aus dem eigenen Netz.

Mit anderen Worten ist der lokale Computer von aussen nicht ohne grösseren Aufwand sichtbar. Requests können einfach raus, aber rein nur mit "Hacker-Aufwand"... OK. Scheint mir logisch.

4. Was ist ein Provider im Sinne von Netzwerk? - Ist das nix anderes, als ein Netzwerk mit einem Router, der an einem Backbone angeschlossen ist und die Requests an "virtuelle" Clients weiterleitet, die im physikalischen Sinne nicht existieren (die Daten werden eifach kodiert über die Telefon-/Standleitung übertragen)?
   So könnte man es sagen.

Was man mit gutem Menschenverstand so alles herleiten kann :-)

5. Datenrouting
      Je nach Request, wird das Datenpacket über verschiedene Netzwerke weitergeleitet. Das bedingt, dass der Rückweg irgendwo festgehalten werden muss. Wo wird dieser gespeichert? - Der Request-Header enthält doch nur Platz für eine "Rücksprungs" - IP, oder?

Nein, es wird nur festgehalten, welche offizielle IP-Adresse die Daten angefordert hat. Der Rückweg des Pakets ist zunächst offen und muss neu bestimmt werden, wenn die Anfrage verarbeitet wurde.

Oh, jetzt wo du's sagst, ist das ja logisch. Sonst wär das Netz ja nicht so "unzerstörbar". Es war ja genau gewollt, dass die Requests einfach "irgendwie" weitergeleitet werden und so über abermillionen von Wegen dann zurück zum eigentlichen Request-starter gelangen; dann können die Russen getrost einige Router zerstören, das Packet kommt doch irgendwie zurück ;-)
Das war ja auch so gewollt...

Viele Grüsse und herzlichen Dank für die informative Antwort

Philipp

[Andreas]

Hallo!

Mit anderen Worten ist der lokale Computer von aussen nicht ohne grösseren Aufwand sichtbar. Requests können einfach raus, aber rein nur mit "Hacker-Aufwand"... OK. Scheint mir logisch.

mit noch anderen Worten, wir müssen doch nicht alle auf Linux umstellen oder unsere Windows-Standardeinstellungen verändern, da man trotz der oft kritisierten ach so großen Sicherheitslücken bei MS keinen Zugriff auf einen Standard-Windows PC bekommt, solange amn nicht selbst ne Diskette nimmt und ein böses Remote-Programm installiert, oder sowas durch Würmer erledigen läßt - soweit richtig verstanden?

Grüße
Andreas

[Christian Kruse]

Hallo,

mit noch anderen Worten, wir müssen doch nicht alle auf
Linux umstellen oder unsere Windows-Standardeinstellungen
verändern, da man trotz der oft kritisierten ach so großen
Sicherheitslücken bei MS keinen Zugriff auf einen
Standard-Windows PC bekommt, solange amn nicht selbst ne
Diskette nimmt und ein böses Remote-Programm installiert,
oder sowas durch Würmer erledigen läßt - soweit richtig
verstanden?

Noe.
ActiveX oder aehnliches braucht nur indirekten Zugriff auf
deinen PC. Diese ganzen Content-Filtering-Loesungen bieten nur
eine truegerische "Sicherheit" und sind nur ein Tropfen auf den
heissen Stein.

Gruesse,
 CK

[Andreas]

Hallo!

Noe.
ActiveX oder aehnliches braucht nur indirekten Zugriff auf
deinen PC. Diese ganzen Content-Filtering-Loesungen bieten nur
eine truegerische "Sicherheit" und sind nur ein Tropfen auf den
heissen Stein.

Mit ActiveX habe ich mich noch nie richtig beschäftigt, aber es ist doch schon seit Jahren klar welche Sicherheitslücken das birgt! Ist es nicht so das die aktuelleren Versionen des IE standardmäßig nicht mehr ganz so angreifbar sind?

Grundsätzlich ist es aber definitiv sicher das man irgendeinen Win-PC dessen IP Adresse man kennt nicht irgendwie(ohne Umweg über Web-Server) direkt "ansprechen" kann, oder? Ich meine man hört immer von den vielen Sicherheitslücken, beziehen die sich alle nur auf IE/Outlook? Ich dachte Windows selbst wäre so unsicher, auch von wegen NetBios...UDP...!

Grüße
Andreas

[Henryk Plötz]

Moin,

Grundsätzlich ist es aber definitiv sicher das man irgendeinen Win-PC dessen IP Adresse man kennt nicht irgendwie(ohne Umweg über Web-Server) direkt "ansprechen" kann, oder? Ich meine man hört immer von den vielen Sicherheitslücken, beziehen die sich alle nur auf IE/Outlook? Ich dachte Windows selbst wäre so unsicher, auch von wegen NetBios...UDP...!

Ja, der Windowsrechner ist nur (relativ) sicher gegen remote-Lücken, wenn du _alle_ Dienste (insbesondere den Datei und Druckerfreigabedienst) von dem externen  Interface entbindest. Das ist a) schwierig genug (vor allem mit modernen Windowsvarianten wo sich Gott und die Welt als Dienst anbieten) und b) keine Garantie für Erfolg: In der Vergangenheit haben sich auch Fehler im TCP/IP-Netzwerkcode selbst gezeigt, etwa die Sache mit den OOB-Paketen.

--
Henryk Plötz
Grüße aus Berlin

* Help Microsoft combat software piracy: Give Linux to a friend today! *

[Andreas]

Hi!

Ja, der Windowsrechner ist nur (relativ) sicher gegen remote-Lücken, wenn du _alle_ Dienste (insbesondere den Datei und Druckerfreigabedienst) von dem externen  Interface entbindest.

Aber ich rede jetzt von Standardeinstellungen von win98, winNT, win2K und winXP, ich weiß, das ist alles verschieden, aber standardmößig sollten doch keien Remote-Dienste aktiviert sein, oder? Nur wenn man anfängt den IIS anzuschmeißen bekommt man Probleme!
Denn wenn ich mich selbst scanne habe ich keine offenen Ports! Also kann ich auch nicht verwundbar sein!

Grüße
Andreas

[Henryk Plötz]

Moin,

Aber ich rede jetzt von Standardeinstellungen von win98, winNT, win2K und winXP, ich weiß, das ist alles verschieden, aber standardmößig sollten doch keien Remote-Dienste aktiviert sein, oder?

Jein. Bei Win98 ist iirc nichts defaultmäßig aktiv, es sei denn du benutzt bereits die Dateifreigabe.

Bei den anderen Betriebssystemen werden soweit ich weiss allerdings standardmäßig allerlei Dinge aktiviert. Vom Taskplaner über die Computerverwaltung bis hin zu Universal Plug-and-Play. Natürlich ist nicht alles auf allen Installationen in Betrieb.

--
Henryk Plötz
Grüße aus Berlin

* Help Microsoft combat software piracy: Give Linux to a friend today! *

[Sven Rautenberg]

Aloha!

Mit ActiveX habe ich mich noch nie richtig beschäftigt, aber es ist doch schon seit Jahren klar welche Sicherheitslücken das birgt! Ist es nicht so das die aktuelleren Versionen des IE standardmäßig nicht mehr ganz so angreifbar sind?

Nö. ActiveX ist unsicher. Und zwar aufgrund des Designs. Da kann man nicht nachbessern. Und wenn du ActiveX sicherer machen willst, stören dich relativ häufig irgendwelche dummen Nachfragen, weil z.B. eine Website Flash benutzt (der IE-Plugin ist ein installiertes ActiveX), oder gewisse Dinge gehen gar nicht mehr. Und dummerweise ist auch auf die Signierung durch Microsoft kein 100% Verlaß - die prüfen nämlich nicht, ob das ActiveX irgendwas böses macht - und selbst das könnte man vermutlich relativ gut verstecken.

Grundsätzlich ist es aber definitiv sicher das man irgendeinen Win-PC dessen IP Adresse man kennt nicht irgendwie(ohne Umweg über Web-Server) direkt "ansprechen" kann, oder? Ich meine man hört immer von den vielen Sicherheitslücken, beziehen die sich alle nur auf IE/Outlook? Ich dachte Windows selbst wäre so unsicher, auch von wegen NetBios...UDP...!

Offene Ports sind böse. Windows ME hat per Default Port 5000 offen, wäre also angreifbar.

Personal Firewalls helfen auch nicht unbedingt weiter - sie machen einen nicht "unsichtbar", sondern geben nur ein falsches Gefühl der Sicherheit.

- Sven Rautenberg

[Christian Kruse]

Hoi,

Hm. Was wird in dieser Session Table festgehalten? - Ich
frage deshalb, da es ja möglich wäre, dass zwei Computer
dieselbe IP kontakten => wer soll welche Antwort erhalten?

Eine Verbindung wird ueber mehrere Merkmale erkannt, z. B.
die Kombination aus Remote- und lokalem Port oder ueber die
TCP-Sequenz-Nummern.

• Man müsste zur eindeutigen Identifikation doch einen
  uniquen Wert mit dem Header versenden, der eindeutig einem
  und nur einem Rechner zugeteilt ist, oder?

Ja: die Kombination lokaler und Remote-Port.

Mit anderen Worten ist der lokale Computer von aussen
nicht ohne grösseren Aufwand sichtbar. Requests können
einfach raus, aber rein nur mit "Hacker-Aufwand"... OK.
Scheint mir logisch.

Doch: wenn du in der einen Sekunde mit einem IE surfst und
in der naechsten mit einem Linux-Mozilla, ist ziemlich
sicher, dass da ein Proxy oder Router zwischenhaengt ;)

Gruesse,
 CK

[Philipp Hasenfratz]

Halihallo Christian

Hm. Was wird in dieser Session Table festgehalten? - Ich
frage deshalb, da es ja möglich wäre, dass zwei Computer
dieselbe IP kontakten => wer soll welche Antwort erhalten?

Eine Verbindung wird ueber mehrere Merkmale erkannt, z. B.
die Kombination aus Remote- und lokalem Port oder ueber die
TCP-Sequenz-Nummern.

Ports sind beschränkt. Was, wenn die Anzahl ausstehender Requests die Anzahl der Ports (bzw. uniquen Werten) überschreitet? - Natürlich ist es unwahrscheinlich, dass mehr als 65536 Requests ausstehend sind, aber nur mal der Diskussionswillen. Wird dann der unique-Wert durch die TCP-Sequenz-Nummern erweitert und so die möglichen Kombinationen erweitert?

Mit anderen Worten ist der lokale Computer von aussen
nicht ohne grösseren Aufwand sichtbar. Requests können
einfach raus, aber rein nur mit "Hacker-Aufwand"... OK.
Scheint mir logisch.

Doch: wenn du in der einen Sekunde mit einem IE surfst und
in der naechsten mit einem Linux-Mozilla, ist ziemlich
sicher, dass da ein Proxy oder Router zwischenhaengt ;)

'tschuldige die Begriffsstuzigkeit, aber das bedarf einer kleinen Erklärung - ?? ;)

Viele Grüsse

Philipp

[Christian Kruse]

Hallo Philipp,

Ports sind beschränkt.

Verbindungen auch :)

Was, wenn die Anzahl ausstehender Requests die Anzahl der
Ports (bzw. uniquen Werten) überschreitet?

Connection refused.
Aber du solltest dir darueber klar sein, dass 10 Requests
auf einen HTTP-Server nur einen Port belegen (im Normalfall
Port 80). Lediglich auf dem Client muss pro Verbindung ein
neuer Port alloziiert werden.

'tschuldige die Begriffsstuzigkeit, aber das bedarf einer
kleinen Erklärung - ?? ;)

Naja, NAT-Gateways werden im Normalfall nur in Netzwerken von
mehr als einem PC eingesetzt. Und wenn jetzt der eine mit
einem Win-PC und IE surft und der andere gleichzeitig mit
einem UNIX-PC und einem UNIX-Mozilla, dann faellt das doch
schon auf :)

Gruesse,
 CK

[Sven Rautenberg]

Aloha!

Naja, NAT-Gateways werden im Normalfall nur in Netzwerken von
mehr als einem PC eingesetzt. Und wenn jetzt der eine mit
einem Win-PC und IE surft und der andere gleichzeitig mit
einem UNIX-PC und einem UNIX-Mozilla, dann faellt das doch
schon auf :)

Genauso "fällt es auf", wenn der aus dem Netz erreichbare Rechner laut nmap ein Linux-PC sein soll, die Requests an Webserver aber von einem Windows-IE kommen sollen.

Und natürlich dürfte es auffallen, wenn dieser im Netz hängende Rechner für die Requests immer nur hohe Portnummern ab 60.000 benutzt - das ist nämlich die Default-Einstellung für Linux-Masquerding. :)

Fazit: Man kann relativ leicht herausfinden, mit was jemand ins Netz geht, bzw. den NAT-Router feststellen, wenn man nur genau genug den Traffic anschaut. Allerdings könnte da der Datenschutz dagegen sein, da es sich durchaus um persönliche Daten handelt, die der Provider nur zu übermitteln, aber nicht auf verdächtige Inhalte zu durchleuchten hat.

- Sven Rautenberg

[Andreas]

Hi Phillipp!

Sehr interessante Fragen ;-)

Wenn ich nicht irre hat der Router intern Routing-Tabellen gespeichert, der Server bekommt nur die offizielle IP mit, also geht die Anfrage zurück an den Router, der "schaut" in seiner Tabelle nach und sendet die Pakete entsprechend intern weiter. Aber wenn jetzt 2 Clients dieselbe Webseite öffnen, weiß ich nicht mehr, wie der Router das noch unterscheiden will, es ist ja nicht sicher das von der einen Adresse dieselben Daten an beide Clients kommen! Außerdem müßte der Browser dann JEDEN Request loggen, braucht etwas mehr Platz als so ein Router haben sollte, oder?

Anhand der IP kann die Herkunft des Requests bis auf Städte aufgelöst werden (naja, stimmt nicht ganz); warum haben die Provider ein Interesse daran und tun das so? - Die IP's werden ja vom Privder dynamisch festgelegt.

anhand der IP? Soweit ich weiß nur anhand des letzten Provider-Routers, die aus irgendwelchen Gründen Ihre großen Router nach den Orten der Einwahlknoten benennen, halt als irgendwelche Kürzel.
Interessant hierzu:
http://www.heise.de/ix/artikel/2002/08/090/
http://jan.kneschke.de/projects/localizer/(unten ist ein Test, bei mir sehr genau!)
http://jan.kneschke.de/projects/geograph/ Mit einer internen DB wird dann halt dem Kürzel eine Stadtname zugewiesen.

Vom Rest habe leider noch weniger Ahnung ;-)

Grüße
Andreas

[Philipp Hasenfratz]

Halihallo Andreas

Sehr interessante Fragen ;-)

jaja, dachte mir, dass du diese interessant findest :-)

Wenn ich nicht irre hat der Router intern Routing-Tabellen gespeichert, der Server bekommt nur die offizielle IP mit, also geht die Anfrage zurück an den Router, der "schaut" in seiner Tabelle nach und sendet die Pakete entsprechend intern weiter. Aber wenn jetzt 2 Clients dieselbe Webseite öffnen, weiß ich nicht mehr, wie der Router das noch unterscheiden will, es ist ja nicht sicher das von der einen Adresse dieselben Daten an beide Clients kommen! Außerdem müßte der Browser dann JEDEN Request loggen, braucht etwas mehr Platz als so ein Router haben sollte, oder?

??? :-(

Anhand der IP kann die Herkunft des Requests bis auf Städte aufgelöst werden (naja, stimmt nicht ganz); warum haben die Provider ein Interesse daran und tun das so? - Die IP's werden ja vom Privder dynamisch festgelegt.
anhand der IP? Soweit ich weiß nur anhand des letzten Provider-Routers,

Äm. ja, sorry.

die aus irgendwelchen Gründen Ihre großen Router nach den Orten der Einwahlknoten benennen, halt als irgendwelche Kürzel.

Hm. Frage mich nur, warum? - Aber Hauptsache sie tun's... Hatte mich nur gewundert, dass es "_alle_?" so machen.

http://www.heise.de/ix/artikel/2002/08/090/
http://jan.kneschke.de/projects/localizer/(unten ist ein Test, bei mir sehr genau!)
http://jan.kneschke.de/projects/geograph/ Mit einer internen DB wird dann halt dem Kürzel eine Stadtname zugewiesen.

THX. Die letzten beide hatte ich schon mal besucht und hatte mich fasziniert... Ist ja für die Bannerwerbung ganz interessant... Städtetargeting... Also der aus Zürch bekommt diesen, der aus Basel jenen Banner zu sehen, o. ä...

Viele Grüsse

Philipp

[Sven Rautenberg]

Aloha!

Wenn ich nicht irre hat der Router intern Routing-Tabellen gespeichert, der Server bekommt nur die offizielle IP mit, also geht die Anfrage zurück an den Router, der "schaut" in seiner Tabelle nach und sendet die Pakete entsprechend intern weiter. Aber wenn jetzt 2 Clients dieselbe Webseite öffnen, weiß ich nicht mehr, wie der Router das noch unterscheiden will, es ist ja nicht sicher das von der einen Adresse dieselben Daten an beide Clients kommen! Außerdem müßte der Browser dann JEDEN Request loggen, braucht etwas mehr Platz als so ein Router haben sollte, oder?

Bei echtem NAT (Network Adress Translation) hat der Router mehrere IP-Adressen zur verfügung und ersetzt z.B. die interne IP eines Rechners komplett durch eine neue externe IP. Damit können natürlich nicht mehr Rechner gleichzeitig online sein, wie externe IPs existieren. Da aber in diesem Fall nur eine einzige IP vorliegt, ist das Beispiel ohnehin unzutreffend.

Beim Masquerading führt der Router eine Tabelle, in der er verzeichnet, welche Requests von internen Rechnern er erhalten hat. Diese Requests leitet er als eigene Requests ins Internet - und zwar auf einem bestimmten Port. Die Antwort des Requests leitet er dann komplett an den internen Rechner zurück. Das klappt sowohl für einmalige Datenübermittlungen wie bei HTTP, als auch bei fortwährenden Verbindungen wie bei IRC.

Echtes FTP ist damit übrigens nicht direkt möglich, da bei FTP auch vom Server her Verbindungen zum Client aufgebaut werden, wenn z.B. Dateien runtergeladen werden sollen. Dafür gibt es passives FTP, bei dem der Client auf Anweisung vom Server weitere Verbindungen aufbaut, und natürlich Module für das Masquerading, welches die FTP-Verbindung analysiert und entsprechend eingehende Verbindungen ermöglicht. Ebenso sind die ganzen Filesharing-Dienste nur eingeschränkt benutzbar, da eingehende Verbindungen eben nicht standardmäßig möglich sind.

- Sven Rautenberg

[Henryk Plötz]

Moin,

Bisher hab ich mich nur als "Anwender" an TCP/IP getraut... Jetzt tät ich mich gerne etwas mit den Internas von Bit's und Bytes beschäftigen und versuche zu verstehen, wie das ganze im Background abläuft

Kleiner Tipp am Rande: Besorg dir Ethereal. Das ist der Netzwerksniffer meiner Wahl und prima zum Lernen und Rumstöbern geeignet. Gibt es notfalls auch für Windows.

Aber wie gelangt nun das Packet wieder zu mir zurück?

Ganz einfach: Du hast keinen Router, sondern ein Masquerading-Gateway. Ein Router würde nur Pakete zwischen zwei (oder mehr) Netzen austauschen und lässt dabei Ziel- und Absenderaddresse intakt (eigentlich ändert er so gut wie gar nichts ausser der TTL). Du verwendest aber Masquerading - manchmal auch 1:n NAT (Network Address Translation) oder PAT (das P steht für Port) genannt. Wenn dein Rechner also ein Paket nach draussen schicken will, schickt er es zuerst an dein Gateway (ist in den Einstellungen als Router eingetragen, und verhält sich nach innen auch genauso). Das ersetzt dann die Absenderaddresse (die ja aus einem der für privaten Gebrauch reservierten Netze kommt) durch seine eigene (öffentliche) Addresse und tauscht gleichzeitig den Absenderport aus und ersetzt ihn durch irgendwas hohes. Diese Ersetzung merkt es sich und hat immer eine Tabelle in der drin steht, von welchem Rechner innen ein Paket ursprünglich kam und an welchen Rechner:Port von welcher ersetzten Portnummer er es geschickt hat. Wenn der Rechner draussen nun antwortet, schickt er die Antwort an die geänderte Portnummer auf deinem Gateway. Das schaut dann in seiner Tabelle nach und kann das Antwortpaket an den ursprünglichen Absender (nachdem es die Portnummern und Addressen wieder gradegebogen hat) zurückschicken.

Anhand der IP kann die Herkunft des Requests bis auf Städte aufgelöst werden (naja, stimmt nicht ganz); warum haben die Provider ein Interesse daran und tun das so?

Ja, aber trotzdem müssen die Pakete ja auch dorthin geroutet werden. Prinzipiell wäre es kein Problem zu jeder der dynamisch vergebenen IP-Addressen zu vermerken wo der eingewählte User sitzt und dann den Verkehrt dorthin zu leiten. Praktisch ist das aber aufwändig, weil die Routingtabellen dann riesig werden und ständig geändert werden müssten. Also gibt man einfach jedem Einwahlknoten (evt. auch weiträumiger) eine Menge IP-Addressen und routet einfach allen Verkehr auf diese Addressen an den entsprechenden Knoten. Der kann sie dann an den eingewählten Kunden weiterleiten.

3. Wenn ich über'n Router in's Netz gehe und dort meine "offizielle" IP ansehe; wie kann man über diese IP direkt auf meinen Computer zurückgreifen?

Ja, du musst dazu nur auf dem Masquerading-Gateway ein Portforwarding einrichten. Dann erkennt es alle Verbindungsversuche auf den eingestellten Port und leitet sie an einen beliebigen von dir festgelegten Rechner im internen Netz weiter. (Das geht natürlich mit dem Windows-ICS soweit ich weiss nicht.)

4. Was ist ein Provider im Sinne von Netzwerk? - Ist das nix anderes, als ein Netzwerk mit einem Router, der an einem Backbone angeschlossen ist und die Requests an "virtuelle" Clients weiterleitet, die im physikalischen Sinne nicht existieren?

Den zweiten Teil verstehe ich nicht, aber der erste kommt mir richtig vor.

5. Datenrouting
      Je nach Request, wird das Datenpacket über verschiedene Netzwerke weitergeleitet. Das bedingt, dass der Rückweg irgendwo festgehalten werden muss.

Nein, IP kann ausdrücklich asymmetrisch routen. Jeder ans Internet angeschlossene Rechner hat eine Routingtabelle die ihm sagt, wo er Pakete hinschicken muss, wenn sie an eine bestimmte Zieladdresse sollen. (Im Extremfall ist das nur die default-Route, also "Schicke alle Pakete die nicht für dich selbst sind an XYZ, der weiss dann schon was er damit machen soll.") Der Weg den ein Paket von A nach B nimmt ist aber von vorneherein nicht bekannt, bloß dass das Netz sein bestes tun wird, um das Paket dorthin zu bringen. Es ist durchaus möglich, dass jedes Paket einer logischen Verbindung einen anderen Pfad nimmt. Daraus schöpft 'das Netz' seine vielbeschworene Fehlertoleranz: Wenn ein Pfad kaputt ist, nimmt es einfach einen anderen. Die Kernrouter die den Hauptverkehr des Internets transportieren, unterhalten sich ständig untereinander und sagen sich wohin sie Pakete routen können. Ausserdem wird dabei die Laufzeit und die Länge des Weges berücksichtigt und die Routingtabellen dementsprechend angepasst. (Ich hab mich damit auch noch nicht beschäftigt, google einfach mal nach BGP.)

--
Henryk Plötz
Grüße aus Berlin

* Help Microsoft combat software piracy: Give Linux to a friend today! *

[Philipp Hasenfratz]

Halihallo Henryk

Bisher hab ich mich nur als "Anwender" an TCP/IP getraut... Jetzt tät ich mich gerne etwas mit den Internas von Bit's und Bytes beschäftigen und versuche zu verstehen, wie das ganze im Background abläuft

Kleiner Tipp am Rande: Besorg dir Ethereal. Das ist der Netzwerksniffer meiner Wahl und prima zum Lernen und Rumstöbern geeignet. Gibt es notfalls auch für Windows.

Danke für'n Tipp.

Aber wie gelangt nun das Packet wieder zu mir zurück?

Ganz einfach: Du hast keinen Router, sondern ein Masquerading-Gateway. Ein Router würde nur Pakete zwischen zwei (oder mehr) Netzen austauschen und lässt dabei Ziel- und Absenderaddresse intakt (eigentlich ändert er so gut wie gar nichts ausser der TTL). Du verwendest aber Masquerading - manchmal auch 1:n NAT (Network Address Translation) oder PAT (das P steht für Port) genannt. Wenn dein Rechner also ein Paket nach draussen schicken will, schickt er es zuerst an dein Gateway (ist in den Einstellungen als Router eingetragen, und verhält sich nach innen auch genauso). Das ersetzt dann die Absenderaddresse (die ja aus einem der für privaten Gebrauch reservierten Netze kommt) durch seine eigene (öffentliche) Addresse und tauscht gleichzeitig den Absenderport aus und ersetzt ihn durch irgendwas hohes. Diese Ersetzung merkt es sich und hat immer eine Tabelle in der drin steht, von welchem Rechner innen ein Paket ursprünglich kam und an welchen Rechner:Port von welcher ersetzten Portnummer er es geschickt hat.

Aha, so läuft das. Aber Ports sind "nur" deren 65536 vorhanden. Was, wenn mehr Requests ausstehend sind? - Werden dann einfach unterschiedliche Request-IP's zum selben Port geletet, wodurch dann wiederum die "Ziel-IP:Port" Kombination unique wäre? - Klar, das kommt selten vor, aber für's Verständnis wär's trotzdem interessant.

Anhand der IP kann die Herkunft des Requests bis auf Städte aufgelöst werden (naja, stimmt nicht ganz); warum haben die Provider ein Interesse daran und tun das so?

Ja, aber trotzdem müssen die Pakete ja auch dorthin geroutet werden. Prinzipiell wäre es kein Problem zu jeder der dynamisch vergebenen IP-Addressen zu vermerken wo der eingewählte User sitzt und dann den Verkehrt dorthin zu leiten. Praktisch ist das aber aufwändig, weil die Routingtabellen dann riesig werden und ständig geändert werden müssten. Also gibt man einfach jedem Einwahlknoten (evt. auch weiträumiger) eine Menge IP-Addressen und routet einfach allen Verkehr auf diese Addressen an den entsprechenden Knoten. Der kann sie dann an den eingewählten Kunden weiterleiten.

Ach so, dann ergibt das ja sogar Sinn. Dachte, das sei nur eine "pseudo-standardisierung", um der Informationswillen. Aber jetzt ist's klar. Somit kann viel Traffic eingespart werden.

3. Wenn ich über'n Router in's Netz gehe und dort meine "offizielle" IP ansehe; wie kann man über diese IP direkt auf meinen Computer zurückgreifen?

Ja, du musst dazu nur auf dem Masquerading-Gateway ein Portforwarding einrichten. Dann erkennt es alle Verbindungsversuche auf den eingestellten Port und leitet sie an einen beliebigen von dir festgelegten Rechner im internen Netz weiter. (Das geht natürlich mit dem Windows-ICS soweit ich weiss nicht.)

Das ist klar. Aber ohne Portforwarding ist dies nicht zu machen, oder? - bzw. nicht ohne den genannten Aufwand.

4. Was ist ein Provider im Sinne von Netzwerk? - Ist das nix anderes, als ein Netzwerk mit einem Router, der an einem Backbone angeschlossen ist und die Requests an "virtuelle" Clients weiterleitet, die im physikalischen Sinne nicht existieren?

Den zweiten Teil verstehe ich nicht, aber der erste kommt mir richtig vor.

den zweiten Teil? - Der "Client-PC" ist ja nicht im Rechenzentrum des Providers, sondern steht am Ende einer Telefonleitung/Stand-. Deshalb muss ja das Datenpacket über diesen übermittelt werden.

5. Datenrouting
      Je nach Request, wird das Datenpacket über verschiedene Netzwerke weitergeleitet. Das bedingt, dass der Rückweg irgendwo festgehalten werden muss.

Nein, IP kann ausdrücklich asymmetrisch routen. Jeder ans Internet angeschlossene Rechner hat eine Routingtabelle die ihm sagt, wo er Pakete hinschicken muss, wenn sie an eine bestimmte Zieladdresse sollen. (Im Extremfall ist das nur die default-Route, also "Schicke alle Pakete die nicht für dich selbst sind an XYZ, der weiss dann schon was er damit machen soll.") Der Weg den ein Paket von A nach B nimmt ist aber von vorneherein nicht bekannt, bloß dass das Netz sein bestes tun wird, um das Paket dorthin zu bringen. Es ist durchaus möglich, dass jedes Paket einer logischen Verbindung einen anderen Pfad nimmt. Daraus schöpft 'das Netz' seine vielbeschworene Fehlertoleranz: Wenn ein Pfad kaputt ist, nimmt es einfach einen anderen. Die Kernrouter die den Hauptverkehr des Internets transportieren, unterhalten sich ständig untereinander und sagen sich wohin sie Pakete routen können. Ausserdem wird dabei die Laufzeit und die Länge des Weges berücksichtigt und die Routingtabellen dementsprechend angepasst. (Ich hab mich damit auch noch nicht beschäftigt, google einfach mal nach BGP.)

Ja, besten Dank für die Erleuterung.

Vielen Dank für die Informationen

Philipp

[Henryk Plötz]

Moin,

Aha, so läuft das. Aber Ports sind "nur" deren 65536 vorhanden. Was, wenn mehr Requests ausstehend sind? - Werden dann einfach unterschiedliche Request-IP's zum selben Port geletet, wodurch dann wiederum die "Ziel-IP:Port" Kombination unique wäre? - Klar, das kommt selten vor, aber für's Verständnis wär's trotzdem interessant.

Gar nichts, soviele gleichzeitige Sessions sind einfach nicht erlaubt. Ich glaube sogar dass da noch ein einstellbares Limit ist, dass wesentlich tiefer liegt (iirc etwa bei der Hälfte, zumindest auf Linux-Systemen). Das ist übrigens noch ganz schön viel: Der 'Router' in meiner ehemaligen Schule war so ein Hardware-Teil (wenn du mich fragst, war das rausgeworfenes Geld). Der hatte sein Limit irgendwo im dreistelligen Bereich, und ja, es hat die Internetverbindung spürbar behindert.
Bei all den Systemen ist natürlich ein Timeout vorhanden, so daß Verbindungen die geschlossen sind nach kurzer Zeit aus der Tabelle verschwinden und Verbindungen über die lange keine Daten mehr kamen auch aussortiert werden. Zumindest bei letzterem liegt die Default-Einstellung (wieder bei Linux-Systemen) aber iirc ziemlich hoch, so ca. 1 Tag.

Das ist klar. Aber ohne Portforwarding ist dies nicht zu machen, oder? - bzw. nicht ohne den genannten Aufwand.

Ohne Portforwarding ist das gar nicht zu machen.

den zweiten Teil? - Der "Client-PC" ist ja nicht im Rechenzentrum des Providers, sondern steht am Ende einer Telefonleitung/Stand-. Deshalb muss ja das Datenpacket über diesen übermittelt werden.

Ahso meinst du das. Noe da gibts keinen Unterschied, PPP ist dann halt auch nur ein Übertragungsmedium wie jedes andere (etwa Ethernet). Beim Provider steht dann halt ein Router mit ganz vielen Einwahlschnittstellen und der tut dann, was Router nunmal so tun: Er routet die Pakete zu dir. Ob da eine Modemverbindung, Ethernet oder Brieftauben (http://www.ietf.org/rfc/rfc1149.txt ;) dazwischenliegen, ist dem Internetprotokoll völlig egal.

--
Henryk Plötz
Grüße aus Berlin

* Help Microsoft combat software piracy: Give Linux to a friend today! *

[Christian Kruse]

Hoi,

Gar nichts,

Doch: connection refused :)

Ich glaube sogar dass da noch ein einstellbares Limit ist,
dass wesentlich tiefer liegt (iirc etwa bei der Hälfte,
zumindest auf Linux-Systemen).

Davon habe ich noch nichts gehoert. Literatur?

Bei all den Systemen ist natürlich ein Timeout vorhanden,
so daß Verbindungen die geschlossen sind nach kurzer Zeit
aus der Tabelle verschwinden und Verbindungen über die
lange keine Daten mehr kamen auch aussortiert werden.
Zumindest bei letzterem liegt die Default-Einstellung
(wieder bei Linux-Systemen) aber iirc ziemlich hoch, so
ca. 1 Tag.

Quatsch. Der Default-Timeout fuer TCP/IP-Verbindungen ist
180 Sekunden (3 Minuten) bei allen mir bekannten
Implementationen.

Gruesse,
 CK

[Sven Rautenberg]

Aloha!

Bei all den Systemen ist natürlich ein Timeout vorhanden,
so daß Verbindungen die geschlossen sind nach kurzer Zeit
aus der Tabelle verschwinden und Verbindungen über die
lange keine Daten mehr kamen auch aussortiert werden.
Zumindest bei letzterem liegt die Default-Einstellung
(wieder bei Linux-Systemen) aber iirc ziemlich hoch, so
ca. 1 Tag.

Quatsch. Der Default-Timeout fuer TCP/IP-Verbindungen ist
180 Sekunden (3 Minuten) bei allen mir bekannten
Implementationen.

Naja, was man so Quatsch nennt...

Der Timeout vom Linux-Masqerading ist unterschiedlich und hängt davon ab. :) Genauer gesagt gibt es drei Timeoutwerte (und meine Einstellungen in Klammern):

1. Timeout für bestehende TCP-Verbindungen.   (7200 sec = 2 Std)
2. Timeout für geschlossene TCP-Verbindungen  (10 sec)
3. Timeout für UDP                            (60 sec)

- Sven Rautenberg

[Henryk Plötz]

Moin,

Doch: connection refused :)

Naja, das ist bloß eine andere Formulierung von 'gar nichts' (in Bezug auf die Datenübertragung gemeint) ;)

Davon habe ich noch nichts gehoert. Literatur?

Ist schon ein bisschen her, also wahrscheinlich flasch.

Quatsch. Der Default-Timeout fuer TCP/IP-Verbindungen ist
180 Sekunden (3 Minuten) bei allen mir bekannten
Implementationen.

Ok, hab nachgesehn. Zumindest bei ipchains (also Linux 2.2) ist der default für alle Verbindungstypen 15min. Das Howto empfiehlt für TCP-Verbindungen nach dem Schliessen (also fin) 10s und sonst 2h.

Der eine Tag Timeout kam von woanders und hat sich verlaufen.

--
Henryk Plötz
Grüße aus Berlin

* Help Microsoft combat software piracy: Give Linux to a friend today! *

[Philipp Hasenfratz]

Halihallo Forumer

Also: Requests werden in der Tabelle mit Ports wiedererkannt und an den richtigen Client-PC weitergeleitet. Nun habe ich mir was ausgedacht:

Ein Router kann angezapft werden und an jeden Port ein gefaktes Packet mit dem Flag "Response" gesendet werden, was dann zum Client weitergeleitet wird. Somit könnte man ja den Client völlig zumüllen, oder? - Man muss halt nur schneller sein, als die richtige Response.

etwas weitergedacht...
vielleicht wäre es möglich alle Requests auf eine bestimmte URL abzufangen und durch gefakte Responses zu fälschen. Man könnte eine Passwort-Eingabe-Seite abfangen und durch die eine eigene ersetzen, dessen Lyout der eigentlichen entspricht, jedoch das übermitteln der Formulardaten an ein eigenes Script weiterleitet, wo das Passwort gespeichert wird. Dann die Meldung: "Passwort falsch"; dann wird der User an die richtige URL weitergeleitet und dort macht er das selbe nochmal und kommt an die richtige Stelle. Er wundert sich kurz und ich habe sein Passwort...

Ich möchte hier keine Hacker-Techniken vermitteln; war nur so'n Gedankengang. Wär sowas möglich? - Wenn ja, dann nicht darauf antworten, wenn nein, warum nicht? - OK. Dass es sehr, sehr kompliziert wäre ist mir bewusst, besonders, weil ein HTTP-Request mehrere Datenpackete erfordert und man die Requests sicher nicht einfach abfangen kann. Besonders die Synchronisation (bzw. die Geschwindigkeit, dass man die "richtigen" Responses unterdrückt) ist sehr schwierig.

Tja, vielleicht habe ich einfach zuviele schlechte Filme gesehen :-))

Viele Grüsse

Philipp

[Henryk Plötz]

Moin,

Ein Router kann angezapft werden und an jeden Port ein gefaktes Packet mit dem Flag "Response" gesendet werden, was dann zum Client weitergeleitet wird. Somit könnte man ja den Client völlig zumüllen, oder? - Man muss halt nur schneller sein, als die richtige Response.

Noch nicht mal. Wenn es sich um eine TCP-Verbindung handelt, ist die Reihenfolge und die Flags der Pakete egal, um weitergeleitet zu werden. (Naja fast, Pakete mit RST bzw FIN beenden die Verbindung.)

vielleicht wäre es möglich alle Requests auf eine bestimmte URL abzufangen und durch gefakte Responses zu fälschen.

Nicht wirklich, zumindest nicht von ausserhalb. Um das tun zu können, musst du auf dem Pfad zwischen Browser und Server sitzen. TCP hat nämlich eine Sicherung dagegen: Die Sequenznummern. Pakete werden nur als gültig für die Verbindung betrachtet, wenn sie die richtige Sequenznummer tragen. Um ein gefälschtes Paket zu erstellen, dass in die Verbindung eingeht, musst du demnach die Verbindung abhören können und dann kommt das Passwort eh raus, es sei denn du verwendest SSL und dann geht das einfache Einschleusen von Pakete nicht. Eine Einschränkung: Einige Betriebssysteme (zum Beispiel die billig-Windowsvarianten) haben Probleme mit ihrem Sequenznummern, da könnte man evt. auch ohne sniffen die aktuelle Sequenznummer zumindest in einem gewissen Bereich erraten.

Besonders die Synchronisation (bzw. die Geschwindigkeit, dass man die "richtigen" Responses unterdrückt) ist sehr schwierig.

Ahja, das ist ein weiteres Problem. Wenn du bei diesen Injection-Attacken (unabhängig davon, ob Masquerading dazwischen ist oder nicht) nicht vorsichtig bist, fängst du dir unter Umständen eklige Probleme ein, wie einen ACK-Sturm.

--
Henryk Plötz
Grüße aus Berlin

* Help Microsoft combat software piracy: Give Linux to a friend today! *

[Andreas]

Hallo!

Noch nicht mal. Wenn es sich um eine TCP-Verbindung handelt, ist die Reihenfolge und die Flags der Pakete egal, um weitergeleitet zu werden. (Naja fast, Pakete mit RST bzw FIN beenden die Verbindung.)

Aber der Router sollte doch nur was weiterleiten, wenn er auf irgendwas wartet, oder? Oder sendet er alles was auf einen bestimmten Port geht an den Client, der als letzter diesen Port benutzt hat?

vielleicht wäre es möglich alle Requests auf eine bestimmte URL abzufangen und durch gefakte Responses zu fälschen.

Nicht wirklich, zumindest nicht von ausserhalb. Um das tun zu können, musst du auf dem Pfad zwischen Browser und Server sitzen. TCP hat nämlich eine Sicherung dagegen: Die Sequenznummern. Pakete werden nur als gültig für die Verbindung betrachtet, wenn sie die richtige Sequenznummer tragen. Um ein gefälschtes Paket zu erstellen, dass in die Verbindung eingeht, musst du demnach die Verbindung abhören können und dann kommt das Passwort eh raus, es sei denn du verwendest SSL und dann geht das einfache Einschleusen von Pakete nicht. Eine Einschränkung: Einige Betriebssysteme (zum Beispiel die billig-Windowsvarianten) haben Probleme mit ihrem Sequenznummern, da könnte man evt. auch ohne sniffen die aktuelle Sequenznummer zumindest in einem gewissen Bereich erraten.

Aber was hat man davon dem Windows Rechner irgendein sinnloses Paket zu schicken? Woher weiß man was der damit macht und das er überhaupt was damit macht? Wartet er nicht auf vorher bestimmten Ports auf eine Antwort auf ein Request, udsn wenn die da ist ist der Port wieder zu? Udn seklbst wenn er eine falsache Antwort bekommt, was könnte das für Konsequerenzen haben? Nur das man böse activeX oder Javascripte ausführt? Oder könnte mein Win-PC vor größere Probleme gestellt werden?

Besonders die Synchronisation (bzw. die Geschwindigkeit, dass man die "richtigen" Responses unterdrückt) ist sehr schwierig.

Meinst Du mit "richtig" jetzt die vom original-server an den deer Request ginbg? Aber wie  willst Du die unterdrücken? Das setzt wieder  voraus das der gesamte Traffic dieses Client über Deinen Rechner läuft!

Ahja, das ist ein weiteres Problem. Wenn du bei diesen Injection-Attacken (unabhängig davon, ob Masquerading dazwischen ist oder nicht) nicht vorsichtig bist, fängst du dir unter Umständen eklige Probleme ein, wie einen ACK-Sturm.

Was heißt das? Das Du viele Pakete an den Rechner schickst und der jedesmal ein Ack sendet? Aber das kann doch nicht schlimmer sein als das was D mit Deinen Paketen anrichtest, oder? Kann man nicht eine falsche "absenderIP" angeben und so die "Stürme" einem anderen Server zukommen lassen? ;-)
Aber dazu müßte man ja den TCP Header manipulieren, kann das auch PERL, oder geht sowas nur mit C?

Viele Grüße
Andreas

[Christian Kruse]

Hoi,

Aber der Router sollte doch nur was weiterleiten, wenn er
auf irgendwas wartet, oder? Oder sendet er alles was auf
einen bestimmten Port geht an den Client, der als letzter
diesen Port benutzt hat?

Nein, er muss schon auf Pakete einer Verbindung warten.

Aber was hat man davon dem Windows Rechner irgendein
sinnloses Paket zu schicken?

Nun, man kann uU so Exploits ausnutzen und Aktionen auf dem
PC hervorrufen. Ueber das Filesharing-Protokoll z. B.

Woher weiß man was der damit macht und das er überhaupt
was damit macht?

Gar nicht.

Wartet er nicht auf vorher bestimmten Ports auf eine
Antwort auf ein Request, udsn wenn die da ist ist der Port
wieder zu?

Ja. Aber selbst auf Windows-Kisten kann man Server-Prozesse
implementieren, die dauerhaft auf einem Port lauschen.

Udn seklbst wenn er eine falsache Antwort bekommt, was
könnte das für Konsequerenzen haben?

Gar nix im guenstigensten Fall, Bluescreens und/oder
Fremdzugriffe im unguenstigsten Fall.

Nur das man böse activeX oder Javascripte ausführt?

Das hat mit TCP/IP nix zu tun :)

Oder könnte mein Win-PC vor größere Probleme gestellt
werden?

Wie gesagt, die fehlerhafte Implementation von TCP/IP in
einigen Win-Versionen kann Probleme machen. "Exploit" sei
mal als Stichwort genannt.

Ahja, das ist ein weiteres Problem. Wenn du bei diesen
Injection-Attacken (unabhängig davon, ob Masquerading
dazwischen ist oder nicht) nicht vorsichtig bist,
fängst du dir unter Umständen eklige Probleme ein, wie
einen ACK-Sturm.

Was heißt das?

Das ganz viele Pakete mit dem ACK-Flag geschickt werden.

Das Du viele Pakete an den Rechner schickst und der
jedesmal ein Ack sendet?

Das oder umgekehrt :)

Aber das kann doch nicht schlimmer sein als das was D mit
Deinen Paketen anrichtest, oder?

D?
Es belastet den Rechner. Ein NAT-Daemon muesste bei jedem
ACK-Paket einen Lookup in seinen Tabellen machen.

Kann man nicht eine falsche "absenderIP" angeben und so
die "Stürme" einem anderen Server zukommen lassen? ;-)

Ja. Diese Technik nennt sich 'IP-Spoofing'.

Aber dazu müßte man ja den TCP Header manipulieren, kann
das auch PERL, oder geht sowas nur mit C?

Das geht gar nicht so ohne weiteres. Dazu muss man das
richtige Betriebssystem haben: es muss 'Raw Sockets'
unterstuetzen. Da gibt es auch ein Perl-Modul:

http://search.cpan.org/search?dist=Net-RawIP

Gruesse,
 CK

[Sven Rautenberg]

Aloha!

Aber dazu müßte man ja den TCP Header manipulieren, kann
das auch PERL, oder geht sowas nur mit C?

Das geht gar nicht so ohne weiteres. Dazu muss man das
richtige Betriebssystem haben: es muss 'Raw Sockets'
unterstuetzen. Da gibt es auch ein Perl-Modul:

Naja, seit Windows XP kann auch dieses Betriebssystem Raw Sockets anbieten - was sicherlich in diversen Cracker-Kreisen schon wohlwollend aufgenommen wurde - oder absolut uninteressant ist, weil die ohnehin kein IP-Spoofing brauchen, indem sie einfach Fremdrechner für sich arbeiten lassen, deren Besitzer vollkommen ahnungslos sind.

- Sven Rautenberg

[Andreas]

Hi!

Naja, seit Windows XP kann auch dieses Betriebssystem Raw Sockets anbieten - was sicherlich in diversen Cracker-Kreisen schon wohlwollend aufgenommen wurde - oder absolut uninteressant ist, weil die ohnehin kein IP-Spoofing brauchen, indem sie einfach Fremdrechner für sich arbeiten lassen, deren Besitzer vollkommen ahnungslos sind.

Das ist ja schon wieder so ne Sache. Muß sich das ein möchte-gern Admin wie ich so virstellen, das die irgenwelche Serverprogramme auf wildfremden Rechnern installieren, nur  mal so als Beispiel(ist natürlich was anderes) Apache/PHP, und arbeiten dann vergleichbar wie ich von meinem Webserver aus mit fsockopen()...?

Grüße
Andreas

[Sven Rautenberg]

Aloha!

Das ist ja schon wieder so ne Sache. Muß sich das ein möchte-gern Admin wie ich so virstellen, das die irgenwelche Serverprogramme auf wildfremden Rechnern installieren, nur  mal so als Beispiel(ist natürlich was anderes) Apache/PHP, und arbeiten dann vergleichbar wie ich von meinem Webserver aus mit fsockopen()...?

Das mußt du dir im Prinzip genau so vorstellen.

Denk dir ein Programm, welches als Mail verschickt wird und von DAUs massenhaft angeklickt wird (irgendwer ist immer zu doof dazu, NICHT zu klicken). Nimm weiter an, dieses Programm tut sogar etwas erheiterndes - hat also den wirklichen Mega-Witz geladen, so dass das ganze Büro lacht und drei Tage unterm Tisch liegt. Das wird doch massenweise weitergeleitet.

Wenn jetzt dieses Witz-Programm eine kleine, unscheinbare Installationsroutine hat, die ein kleines Programm installiert, welches sich zum Beispiel zum Flooden von IP-Adressen mit PINGs eignet, und dieses Programm sich immer dann, wenn der Rechner eingeschaltet ist, selbständig in einem IRC-Kanal meldet und von dort seine Befehle kriegt, dann ist das von den Opfern ziemlich schwierig zurückzuverfolgen. Jedenfalls von den Opfern, die geflooded werden.

Wenn du der englischen Sprache mächtig bist, lies dir einfach die zwei Berichte auf grc.com durch - sehr aufschlußreich (und sehr lang, aber IMO interessant geschrieben):
http://grc.com/dos/intro.htm
http://grc.com/dos/drdos.htm

- Sven Rautenberg

[Andreas]

Hallo!

Das mußt du dir im Prinzip genau so vorstellen.

Denk dir ein Programm, welches als Mail verschickt wird und von DAUs massenhaft angeklickt wird (irgendwer ist immer zu doof dazu, NICHT zu klicken). Nimm weiter an, dieses Programm tut sogar etwas erheiterndes - hat also den wirklichen Mega-Witz geladen, so dass das ganze Büro lacht und drei Tage unterm Tisch liegt. Das wird doch massenweise weitergeleitet.

Wenn jetzt dieses Witz-Programm eine kleine, unscheinbare Installationsroutine hat, die ein kleines Programm installiert, welches sich zum Beispiel zum Flooden von IP-Adressen mit PINGs eignet, und dieses Programm sich immer dann, wenn der Rechner eingeschaltet ist, selbständig in einem IRC-Kanal meldet und von dort seine Befehle kriegt, dann ist das von den Opfern ziemlich schwierig zurückzuverfolgen. Jedenfalls von den Opfern, die geflooded werden.

Naja, man kennt das ja von den Trojanern, da braucht es überhaupt keiner installationsroutine, wenn die exe gestartet wird wird unbemerkt alles mögliche installiert, und mehr so nebenbei irgend ein witz-programm gestartet. Aber was ist jetzt der Unterschied zu trojanern? Trojaner ermöglichen es normalerweise ja nur auf eben diesen einen Remote-Rechner zuzugreifen und alles mögliche anzustellen. Aber besagte Tools funktionieren ja anders! Naja, ist ein anderes Level(zum Glück!).
Aber von wegen Installation, funktioniert das nicht auch genauso wie die Würmer, die sich schon beim öffnen einer mail ausführen, oder geht das nicht mit solchen Programen? Ist ja ein Unterschied ob ein Programm installiert wird, oder per Windows-Scripting irgendwelche befehle ausgeführt werden. Habe auch gehört das es unter Win sogar möglich ist ein .exe als z.B. .mpg zu benennen, den "header" zu verändern und Win behandelt das als .exe, oder es ist eine exe und win zeigt im Explorerr immer .mpg an, weiß auch nicht mehr genau wie das war.

Wenn du der englischen Sprache mächtig bist, lies dir einfach die zwei Berichte auf grc.com durch - sehr aufschlußreich (und sehr lang, aber IMO interessant geschrieben):
http://grc.com/dos/intro.htm
http://grc.com/dos/drdos.htm

Danke Dir!

Grüße
Andreas

[Philipp Hasenfratz]

Hallihallo Andreas

Das mußt du dir im Prinzip genau so vorstellen.

Wenn jetzt dieses Witz-Programm eine kleine, unscheinbare Installationsroutine hat, die ein kleines Programm installiert, welches sich zum Beispiel zum Flooden von IP-Adressen mit PINGs eignet, und dieses Programm sich immer dann, wenn der Rechner eingeschaltet ist, selbständig in einem IRC-Kanal meldet und von dort seine Befehle kriegt, dann ist das von den Opfern ziemlich schwierig zurückzuverfolgen. Jedenfalls von den Opfern, die geflooded werden.
Naja, man kennt das ja von den Trojanern, da braucht es überhaupt keiner installationsroutine, wenn die exe gestartet wird wird unbemerkt alles mögliche installiert,

Das meinte Sven mit der Installationsroutine ;-)
Und das, wovon wir hier sprechen, sind auch Trojaner; einfach etwas "TCP/IP nähere".

Aber von wegen Installation, funktioniert das nicht auch genauso wie die Würmer, die sich schon beim öffnen einer mail ausführen, oder geht das nicht mit solchen Programen?

Die Würmer von denen du sprichst, basieren meist auf Scriptsprachen, wie z. B. VBS. Aber um sich als Service in das System einzusetzen, bedarf es schon einer .exe => das ist auch ein Problem... Die genannten Programme laufen meist nur auf einer Plattform...

Ist ja ein Unterschied ob ein Programm installiert wird, oder per Windows-Scripting irgendwelche befehle ausgeführt werden. Habe auch gehört das es unter Win sogar möglich ist ein .exe als z.B. .mpg zu benennen, den "header" zu verändern und Win behandelt das als .exe, oder es ist eine exe und win zeigt im Explorerr immer .mpg an, weiß auch nicht mehr genau wie das war.

Naja, das hat nur was mit Outlook bzw. Explorer zu tun.

Viele Grüsse

Philipp

[Andreas]

Hallo!

Oder könnte mein Win-PC vor größere Probleme gestellt
werden?

Wie gesagt, die fehlerhafte Implementation von TCP/IP in
einigen Win-Versionen kann Probleme machen. "Exploit" sei
mal als Stichwort genannt.

Ja, das ist mir wohl bekannt, aber da habe ich ja nicht viel von denn
a) werden die meisten Exploits erst gar nicht genau veröffentlicht
b) fast nur als c Quelltext der noch kompiliert werden muß, und dich kann kaum PHP ;-)
c) sollen die ganz schlauen Exploit-Entdecker absichtlich Fehler in den Code einbauen, die DAUs wie ich nicht finden ;-)

Naja, da habe ich tolle Codes gesehen die noch viel tollere Sachen können, aber leider nur in der Theorie ;-)

Grüße
Andreas

[Henryk Plötz]

Moin,

Hallo!

(Du redest wie immer ein wenig konfus -IMHO-, also antwortet ich nur da wo ich dich verstehe)

Aber was hat man davon dem Windows Rechner irgendein sinnloses Paket zu schicken?

Es ging hier darum ein Paket in eine bestehende Verbindung einzuschleusen. BTW: Ich muss meine Aussage verdeutlichen: Die Probleme mit den Sequenznummern kann man dafür natürlich nur dafür nutzen, wenn beide Rechner derartig schwache Sequenznummern haben.

Aber wie  willst Du die unterdrücken? Das setzt wieder  voraus das der gesamte Traffic dieses Client über Deinen Rechner läuft!

Jein. Ein gut zugestelltes RST kann den anderen Rechner an einen Verbindungsabbruch glauben lassen. Wenn es im LAN ist, kann man ausserdem mit einem eventuell vorhandenen Switch ein bisschen Spaß haben. Ausserdem kann man die Sequenznummern desynchronisieren (natürlich nur wenn die falsche Antwort als erste eintrifft), so dass der Empfänger anschließend legitime Pakete verwirft.

Was heißt das? Das Du viele Pakete an den Rechner schickst und der jedesmal ein Ack sendet?

Nein, mit ACK-Sturm ist was anderes gemeint, was unter Umständen passiert, wenn du die Sequenznummern desynchronisierst (an die Details kann ich mich nicht mehr ganz genau erinnern): TCP verwaltet in beiden Richtungen Sequenznummern die beim Zusammenfügen der Pakete in die richtige Reihenfolge und beim Bestätigen des Paketempfangs benutzt werden (und daher implizit auch um sicherzustellen, dass keine Pakete einfach so in die Verbindung eingeschleust können). Wenn du nun die Sequenznummern auf eine bestimmte Art und Weise desynchronisierst, passiert es, dass die beiden Hosts sich haufenweise Kontrollnachrichten zuschicken, in der Art von
Host1:"Ich habe A empfangen, und X gesendet"
Host2:"Ich habe Y empfangen, und B gesendet"

Dabei wird aber die erste Nachricht von Host2 ignoriert weil sie eine falche Sequenznummer trägt (die Window-Size spielt da auch noch irgendeine Rolle) und mit der zweiten Nachricht beantwortet, um die Verbindung wieder zu synchronisieren. Diese Nachricht wird dann von Host1 ignoriert weil sie eine falsche Sequenznummer trägt und mit der ersten Nachricht beantwortet. Ad infinitum... (bzw. bis zum Timeout).

--
Henryk Plötz
Grüße aus Berlin

* Help Microsoft combat software piracy: Give Linux to a friend today! *

[Andreas]

Hi!

Ich glaube Du mußt Dir keine Sorgen machen das sich jetzt alle hier hinsetzen und solche Sachen probieren. Diejenigen hier die evtl. dazu in der Lage wären werden das wohl gewußt haben, das problem ist Du mußt erstmal zwischen die interessante Seite und die User kommen, das ist wahrscheinlich nicht so einfach wie es sich anhört!

Also: Requests werden in der Tabelle mit Ports wiedererkannt und an den richtigen Client-PC weitergeleitet. Nun habe ich mir was ausgedacht:

Ein Router kann angezapft werden

auchg das ist garabtiert nicht so einfach und bei den meisten (einfachen) Routern wahrscheinlich unmöglich!

vielleicht wäre es möglich alle Requests auf eine bestimmte URL abzufangen und durch gefakte Responses zu fälschen. Man könnte eine Passwort-Eingabe-Seite abfangen und durch die eine eigene ersetzen, dessen Lyout der eigentlichen entspricht, jedoch das übermitteln der Formulardaten an ein eigenes Script weiterleitet, wo das Passwort gespeichert wird. Dann die Meldung: "Passwort falsch"; dann wird der User an die richtige URL weitergeleitet und dort macht er das selbe nochmal und kommt an die richtige Stelle. Er wundert sich kurz und ich habe sein Passwort...

Sowas wie http://www.odem.org/insert_coin/, nur ist das problem Du mußt vorher die Clients manipulieren damit Sie über deinen Proxy gehen, und da schließt sich der Kreis ;-)

Tja, vielleicht habe ich einfach zuviele schlechte Filme gesehen :-))

Warum schlecht? Ich bin leidenschaftlicher Matrix-Fan - freue mich schon auf die Fortsetzung ;-)

Grüße
Andreas

[Philipp Hasenfratz]

Halihallo

Ich glaube Du mußt Dir keine Sorgen machen das sich jetzt alle hier hinsetzen und solche Sachen probieren. Diejenigen hier die evtl. dazu in der Lage wären werden das wohl gewußt haben, das problem ist Du mußt erstmal zwischen die interessante Seite und die User kommen, das ist wahrscheinlich nicht so einfach wie es sich anhört!

Yo, das ist wohl wahr ;)

vielleicht wäre es möglich alle Requests auf eine bestimmte URL abzufangen und durch gefakte Responses zu fälschen. Man könnte eine Passwort-Eingabe-Seite abfangen und durch die eine eigene ersetzen, dessen Lyout der eigentlichen entspricht, jedoch das übermitteln der Formulardaten an ein eigenes Script weiterleitet, wo das Passwort gespeichert wird. Dann die Meldung: "Passwort falsch"; dann wird der User an die richtige URL weitergeleitet und dort macht er das selbe nochmal und kommt an die richtige Stelle. Er wundert sich kurz und ich habe sein Passwort...
Sowas wie http://www.odem.org/insert_coin/, nur ist das problem Du mußt vorher die Clients manipulieren damit Sie über deinen Proxy gehen, und da schließt sich der Kreis ;-)

Noe. Das wär ja vergleichsweise leicht :-)
Ich dachte eher daran, dass der Client gar nix ändern muss, sondern das das ganze Spiel auf TCP/IP Ebene abläuft. Aber eben: unrealisierbar.

Tja, vielleicht habe ich einfach zuviele schlechte Filme gesehen :-))
Warum schlecht? Ich bin leidenschaftlicher Matrix-Fan - freue mich schon auf die Fortsetzung ;-)

Yo. Ich auch ;-)

Viele Grüsse

Philipp

[Philipp Hasenfratz]

Halihallo Forumer

War heute wiedermal höchst lehrreich für mich.
Ich möchte mich bei allen für die höchst interessanten Beiträge bedanken. Ich glaube, ich beginne langsam zu verstehen, womit ich tagtäglich arbeite ;-))

's ist eigentlich eine Ironie. Ich mag keine Leute, die behaupten, dass sie was von SOAP-Services verstehen, nur weil sie irgendwas in der Richtung mit .NET gemacht haben; oder solche die behaupten programmieren zu können, nur weil sie eine HTML Seite mit Frontpage erstellt haben. Aber eigentlich bin ich ja nicht anders. Ich schimpfe mich Programmierer, hauptsächlich für Internet und hab keinen Schimmer von TCP/IP...

Schande über mein Haupt! - Aber ich versuche mich dahingehend zu verbessern. Und man sagt ja immer: Selbsterkenntnis ist der beste Weg zur Besserung...

in diesem Sinne...

Viele Grüsse

Philipp

[Philipp Hasenfratz]

Halihallo Forumer

und nochmals zwei Fragen ;)

Wie funktioniert dann traceroute intern?
Man müsste doch den TCP/IP Stack abhören, die IP:PORT vom ersten Router abhören, diesen nach der Follow-up-Response-IP:PORT abfragen und so den ganzen Weg tracen, oder? - Ich habe noch keine Vorstellung darüber, wie dies machbar ist. Dass man die Geographische Position herausfinden kann ist klar, u. a. durch DNS-LOC oder die IP-Range der "Core"-Router.

raw-sockets:
Bisher sind mir raw-sockets etwas "unheimlich", da sie für DoS-Attacken anscheinend (nach dem Link von Sven) sehr beliebt sind. Durch diese wird ja das IP-Spoofing erst ermöglicht. Also warum wurden diese überhaupt ins Leben berufen, wenn sie doch "meist" nur negative Auswirkungen haben. Oder bieten diese raw-sockets einen Vorteil, den ich nocht nicht sehe?

Viele Grüsse

Philipp

[Peter Kaufmann]

Hallo Philipp,

Wie funktioniert dann traceroute intern?

Das klassische Traceroute benutzt als Protokoll ICMP. Teil eines  solchen Datenpaketes ist das Feld TTL (time to live), daß mit einem positiven Wert (z.B. 30) initialisiert wird. Wenn das Paket nun von Router zu Router weitergereicht wird veringert jeder Router das Feld TTL (zumeist) um eins. Wenn TTL schließlich auf 0 oder 1 steht, sendet der Betreffende Router das Signal "time exceeded" an die ursprüngliche IP zurück. Teil diese "time exceeded" ist auch die IP des betreffenden Routers.
traceroute testet nun einfach mit allen möglichen TTL Werten die komplette Route hin zu einem target durch.
In letzter Zeit ist es leider üblich geworden, daß viele Router/Server ein Packet mit einem "abgelaufenen" TTL komentarlos wegwerfen, deswegen gibt es neuere Traceroute Impementierungen, die UDP Packete an irgendwelche nicht genutzten (hohen) Portnummern versendet und die Fehlermeldung auswerten (das grundlegenede Prinzip ist aber das gleiche, man umgeht aber auf diese Weise einige Firewall Regeln).

Grüße Peter

[Philipp Hasenfratz]

Halihallo

Wie funktioniert dann traceroute intern?

Das klassische Traceroute benutzt als Protokoll ICMP. Teil eines  solchen Datenpaketes ist das Feld TTL (time to live), daß mit einem positiven Wert (z.B. 30) initialisiert wird. Wenn das Paket nun von Router zu Router weitergereicht wird veringert jeder Router das Feld TTL (zumeist) um eins. Wenn TTL schließlich auf 0 oder 1 steht, sendet der Betreffende Router das Signal "time exceeded" an die ursprüngliche IP zurück. Teil diese "time exceeded" ist auch die IP des betreffenden Routers.
traceroute testet nun einfach mit allen möglichen TTL Werten die komplette Route hin zu einem target durch.
In letzter Zeit ist es leider üblich geworden, daß viele Router/Server ein Packet mit einem "abgelaufenen" TTL komentarlos wegwerfen, deswegen gibt es neuere Traceroute Impementierungen, die UDP Packete an irgendwelche nicht genutzten (hohen) Portnummern versendet und die Fehlermeldung auswerten (das grundlegenede Prinzip ist aber das gleiche, man umgeht aber auf diese Weise einige Firewall Regeln).

Aha. Dachte mir schon, dass man hierzu solche Tricks verwenden muss. Aber halt... Jedes Packet sucht sich seinen eigenen Weg, also dürfte doch traceroute gar nicht funktionieren, da es ja jedesmal ein anderes Packet mit anderer TTL absendet; jedoch dieses Packet muss nicht den selben Weg gehen, wie das Vorgängerpacket. Oder hab ich da was falsch verstanden?

Besten Dank für die interessante Info

Philipp

[Philipp Hasenfratz]

Halihallo

Wie funktioniert dann traceroute intern?

Das klassische Traceroute benutzt als Protokoll ICMP. Teil eines  solchen Datenpaketes ist das Feld TTL (time to live), daß mit einem positiven Wert (z.B. 30) initialisiert wird. Wenn das Paket nun von Router zu Router weitergereicht wird veringert jeder Router das Feld TTL (zumeist) um eins. Wenn TTL schließlich auf 0 oder 1 steht, sendet der Betreffende Router das Signal "time exceeded" an die ursprüngliche IP zurück. Teil diese "time exceeded" ist auch die IP des betreffenden Routers.
traceroute testet nun einfach mit allen möglichen TTL Werten die komplette Route hin zu einem target durch.
In letzter Zeit ist es leider üblich geworden, daß viele Router/Server ein Packet mit einem "abgelaufenen" TTL komentarlos wegwerfen, deswegen gibt es neuere Traceroute Impementierungen, die UDP Packete an irgendwelche nicht genutzten (hohen) Portnummern versendet und die Fehlermeldung auswerten (das grundlegenede Prinzip ist aber das gleiche, man umgeht aber auf diese Weise einige Firewall Regeln).

Aha. Dachte mir schon, dass man hierzu solche Tricks verwenden muss. Aber halt... Jedes Packet sucht sich seinen eigenen Weg, also dürfte doch traceroute gar nicht funktionieren, da es ja jedesmal ein anderes Packet mit anderer TTL absendet; jedoch dieses Packet muss nicht den selben Weg gehen, wie das Vorgängerpacket. Oder hab ich da was falsch verstanden?

Upsa. Hab wohl etwas zu weit gedacht. Die Datenpackete suchen sich zwar schon selber ihren Weg (bzw. werden einfach "irgendwie" weitergeleitet), aber die grossen Schritte sind ja durch die "geographische Weiterleitung" durch die Core-Router vorbestimmt. Man will ja den "geographischen Weg" der Autobahn wissen und interessiert sich nicht für kleine Umleitungen über Nebenstrassen...

Viele Grüsse

Philipp

[Henryk Plötz]

Moin,

Jedes Packet sucht sich seinen eigenen Weg, also dürfte doch traceroute gar nicht funktionieren, da es ja jedesmal ein anderes Packet mit anderer TTL absendet; jedoch dieses Packet muss nicht den selben Weg gehen, wie das Vorgängerpacket.

Ja, prinzipiell kann jedes Paket einen anderen Weg nehmen. Praktisch tun sie das in vielen Fällen nicht, weil sich die Routen nicht so schnell ändern. (Zumindest nicht in dem Zeitbereich den du mit Traceroute beobachtest.)

--
Henryk Plötz
Grüße aus Berlin

* Help Microsoft combat software piracy: Give Linux to a friend today! *

[Sven Rautenberg]

Aloha!

raw-sockets:
Bisher sind mir raw-sockets etwas "unheimlich", da sie für DoS-Attacken anscheinend (nach dem Link von Sven) sehr beliebt sind. Durch diese wird ja das IP-Spoofing erst ermöglicht. Also warum wurden diese überhaupt ins Leben berufen, wenn sie doch "meist" nur negative Auswirkungen haben. Oder bieten diese raw-sockets einen Vorteil, den ich nocht nicht sehe?

Ganz grundsätzlich gibt es keinen Schutz vor IP-Spoofing. Da der Spoofer ja vermutlich die Herrschaft über seine Hardware hat, könnte er sich auch selbst einen Netzwerkkartentreiber schreiben, und einen TCP/IP-Stack, und dann eigene IP-Pakete in das Netz schicken - völlig frei definierbar.

Raw Sockets sind einfach eine Erleichterung für einen sehr kleinen Teil der Admin-Bevölkerung. Im Prinzip braucht sie im täglichen Leben niemand. Sie sind vermutlich implementiert, weil in der Anfangszeit des Netzes so Experimente mit eigenen Protokollen leichter durchzuführen waren. Windows hatte lange Zeit keine Raw Sockets, und damit nur eingeschränkte Spoofing-Fähigkeiten. Das hat aber niemanden gestört oder daran gehindert, fremde Windows-Rechner für seine Zwecke einzusetzen. Man muß eine IP nicht spoofen, wenn man eine DDoS-Attacke startet. :)

Das Netz vor Spoofing schützen können nur die Access-Provider. Warum lassen die ein IP-Paket aus ihrem Netzwerk heraus, welches laut IP-Adresse gar nicht aus ihrem Netzwerk kommen kann? Wer sich z.B. per Modem einwählt, erhält eine einzige öffentliche IP-Adresse zugeteilt. Regulärer Datenverkehr kann nur diese eine IP-Adresse als Absender haben, und nichts anderes. Wird eine falsche IP-Adresse vorgegaukelt, ist mit 99,999% Sicherheit irgendwas faul, denn es ist nicht davon auszugehen, dass sich hinter dem Modem ein Router befinden, der seinerseits Zugang wieder zum Internet vermittelt und so Pakete mit fremden IP-Adressen durchschleust. In der Regel ist eine Modem-Verbindung eine Sackgasse.

- Sven Rautenberg

[Philipp Hasenfratz]

Aloha!

Halihallöle ;-)

raw-sockets:
Bisher sind mir raw-sockets etwas "unheimlich", da sie für DoS-Attacken anscheinend (nach dem Link von Sven) sehr beliebt sind. Durch diese wird ja das IP-Spoofing erst ermöglicht. Also warum wurden diese überhaupt ins Leben berufen, wenn sie doch "meist" nur negative Auswirkungen haben. Oder bieten diese raw-sockets einen Vorteil, den ich nocht nicht sehe?

Ganz grundsätzlich gibt es keinen Schutz vor IP-Spoofing. Da der Spoofer ja vermutlich die Herrschaft über seine Hardware hat, könnte er sich auch selbst einen Netzwerkkartentreiber schreiben, und einen TCP/IP-Stack, und dann eigene IP-Pakete in das Netz schicken - völlig frei definierbar.

Yo. Hab ich auch schon gedacht ;-)
Wenn ich die Dokus richtig verstehe, gibt's eine Ethernet-ID, die mit einer IP korrespondiert. Man könnte doch diese Ethernet-ID anzapfen und darüber die eigene (irgendeine) IP senden. Sollte mit C oder Assembler "einfach" machbar sein. Die Netzwerkkarte überprüft ja nicht, was gesendet wird (schätze ich). Man müsste einfach einen eigenen TCP/IP Layer basteln, der die Netzwerkkarte anzapft, dann hat man freie Hand...

Raw Sockets sind einfach eine Erleichterung für einen sehr kleinen Teil der Admin-Bevölkerung. Im Prinzip braucht sie im täglichen Leben niemand. Sie sind vermutlich implementiert, weil in der Anfangszeit des Netzes so Experimente mit eigenen Protokollen leichter durchzuführen waren. Windows hatte lange Zeit keine Raw Sockets, und damit nur eingeschränkte Spoofing-Fähigkeiten. Das hat aber niemanden gestört oder daran gehindert, fremde Windows-Rechner für seine Zwecke einzusetzen. Man muß eine IP nicht spoofen, wenn man eine DDoS-Attacke startet. :)

Yup. Soweit hab ich's schon begriffen ;-)

Das Netz vor Spoofing schützen können nur die Access-Provider. Warum lassen die ein IP-Paket aus ihrem Netzwerk heraus, welches laut IP-Adresse gar nicht aus ihrem Netzwerk kommen kann? Wer sich z.B. per Modem einwählt, erhält eine einzige öffentliche IP-Adresse zugeteilt. Regulärer Datenverkehr kann nur diese eine IP-Adresse als Absender haben, und nichts anderes. Wird eine falsche IP-Adresse vorgegaukelt, ist mit 99,999% Sicherheit irgendwas faul, denn es ist nicht davon auszugehen, dass sich hinter dem Modem ein Router befinden, der seinerseits Zugang wieder zum Internet vermittelt und so Pakete mit fremden IP-Adressen durchschleust. In der Regel ist eine Modem-Verbindung eine Sackgasse.

Eine Sackgasse für den Spoofer meinst du, oder? - Also ein Spoofing-Versuch scheitert, da der Access-Provider das Datenpacket gleich verschluckt.

Viele Grüsse

Philipp

PS: was hat den .de für einen Image-MIME??? ;-)

[Henryk Plötz]

Moin,

Wenn ich die Dokus richtig verstehe, gibt's eine Ethernet-ID, die mit einer IP korrespondiert.

Höh? Das einzige was mir zu "Ethernet-ID" einfällt, wäre die weltweit eindeutige MAC-Addresse jeder Netzwerkkarte. Die kannst du aber für gar nichts benutzen, weil sie nur innerhalb eines Ethernet-Segments eine Rolle spielt und nicht über Router hinweg weitergegeben wird.
(Naja, ein paar Microsoft-Produkte sind ins Gerede gekommen, weil sie die MAC-Addresse in die GUID eingebaut, und diese dann in jedes erstellte Dokument eingefügt haben.)

Eine Sackgasse für den Spoofer meinst du, oder? - Also ein Spoofing-Versuch scheitert, da der Access-Provider das Datenpacket gleich verschluckt.

Ja, nur leider tut das kaum ein (kein?) Provider.

--
Henryk Plötz
Grüße aus Berlin

* Help Microsoft combat software piracy: Give Linux to a friend today! *

[Philipp Hasenfratz]

Halihallöle

Wenn ich die Dokus richtig verstehe, gibt's eine Ethernet-ID, die mit einer IP korrespondiert.

Höh? Das einzige was mir zu "Ethernet-ID" einfällt, wäre die weltweit eindeutige MAC-Addresse jeder Netzwerkkarte. Die kannst du aber für gar nichts benutzen, weil sie nur innerhalb eines Ethernet-Segments eine Rolle spielt und nicht über Router hinweg weitergegeben wird.

Oh, da hab ich wohl was missverstanden. Es wurde hier nie explizit erwähnt, aber in einer Doku stands geschrieben; den betreffenden Teil hab ich nur überflogen, da er weniger mit meinem "primären" Interesse zu tun hatte, sondern schon sehr tief in der Hardware "ist". Ich dachte, dass die IP (lokal wie du sagst) in eine Ethernet-Adresse kodiert wird, sodass dann die Netzwerkkarten miteinander sprechen; OK, jetzt ist's klar.

(Naja, ein paar Microsoft-Produkte sind ins Gerede gekommen, weil sie die MAC-Addresse in die GUID eingebaut, und diese dann in jedes erstellte Dokument eingefügt haben.)

Ach her je... Kann ich mir gut vorstellen... M$

Viele Grüsse

Philipp

[Henryk Plötz]

Moin,

Wie funktioniert dann traceroute intern?

Es schickt Pakete (zum Beispiel ICMP oder UDP-Pakete) raus und verändert dabei die TTL. Die TTL wird jedesmal, wenn das Paket an einem Router vorbeikommt um eins verringert und wenn sie Null erreicht wird das Paket weggeschmissen (dadurch wird verhindert, dass unzustellbare Pakete bis zum St. Nimmerleinstag herumgeistern). Außerdem sendet der Router (soweit ich weiss, nur wenn er will) eine Fehlermeldung raus und die wird dann von traceroute abgefangen. Damit hat es hoffentlich die IP-Addresse jedes Routers auf dem Weg. Dann kann es (ist zumindest die Standardeinstellung) die IP-Addresse in einem DNS-Namen verwandeln und zeigt dir damit den Weg an. Außerdem gibt es in der Regel noch die Zeiten bis zur Rückkehr der einzelnen Pakete an: Damit kannst du erkennen, wenn es irgendwo stockt. Wenn die Zeit zwischen zwei Routern plötzlich nach oben springt, hast du in der Regel eine grade sehr stark belastete Verbindung gefunden.

Dass man die Geographische Position herausfinden kann ist klar, u. a. durch DNS-LOC oder die IP-Range der "Core"-Router.

Naja, das ist aber eher auch Voodoo. (So ähnlich wie Quelltext verstecken)

raw-sockets:
Bisher sind mir raw-sockets etwas "unheimlich", da sie für DoS-Attacken anscheinend (nach dem Link von Sven) sehr beliebt sind.

Ich hatte sowas schon geahnt. Prinzipiell solltest du alles was Gibson sagt mit extremer Vorsicht genießen. Wann immer man auch grc.com linkt, sollte auch ein Link auf http://grcsucks.com/ dabei sein. Die Seite solltest du dir auch noch durchlesen, und dann am besten noch ein paar Recherchen im Usenet anstellen, um dir deine Meinung bilden zu können.

--
Henryk Plötz
Grüße aus Berlin

* Help Microsoft combat software piracy: Give Linux to a friend today! *

[Philipp Hasenfratz]

Halihallo Henryk

Wie funktioniert dann traceroute intern?

Es schickt Pakete (zum Beispiel ICMP oder UDP-Pakete) raus und verändert dabei die TTL. Die TTL wird jedesmal, wenn das Paket an einem Router vorbeikommt um eins verringert und wenn sie Null erreicht wird das Paket weggeschmissen (dadurch wird verhindert, dass unzustellbare Pakete bis zum St. Nimmerleinstag herumgeistern). Außerdem sendet der Router (soweit ich weiss, nur wenn er will) eine Fehlermeldung raus und die wird dann von traceroute abgefangen. Damit hat es hoffentlich die IP-Addresse jedes Routers auf dem Weg. Dann kann es (ist zumindest die Standardeinstellung) die IP-Addresse in einem DNS-Namen verwandeln und zeigt dir damit den Weg an. Außerdem gibt es in der Regel noch die Zeiten bis zur Rückkehr der einzelnen Pakete an: Damit kannst du erkennen, wenn es irgendwo stockt. Wenn die Zeit zwischen zwei Routern plötzlich nach oben springt, hast du in der Regel eine grade sehr stark belastete Verbindung gefunden.

Oder an eine Verbindung mit schwacher Anbindung. OK. Soweit ist mir jetzt auch traceroute ein Begriff. Schade, dass man das nicht mit Perl machen kann (ohne auf externe Programme zuzugreifen).

Dass man die Geographische Position herausfinden kann ist klar, u. a. durch DNS-LOC oder die IP-Range der "Core"-Router.

Naja, das ist aber eher auch Voodoo. (So ähnlich wie Quelltext verstecken)

Soweit ich gelesen hab, ist das auch nur ein "Experiment"; sozusagen eine nette Nebendienstleistung, die noch nicht von allen Systemen implementiert ist.

raw-sockets:
Bisher sind mir raw-sockets etwas "unheimlich", da sie für DoS-Attacken anscheinend (nach dem Link von Sven) sehr beliebt sind.

Ich hatte sowas schon geahnt. Prinzipiell solltest du alles was Gibson sagt mit extremer Vorsicht genießen. Wann immer man auch grc.com linkt, sollte auch ein Link auf http://grcsucks.com/ dabei sein. Die Seite solltest du dir auch noch durchlesen, und dann am besten noch ein paar Recherchen im Usenet anstellen, um dir deine Meinung bilden zu können.

Oh, Schock... Ei, ei, ich war schon auf dem Weg diesen Gibson zu verherrlichen ;-)
Naja, gut, ich geniesse es mit Vorsicht; obwohl mir vieles, was er sagt einleuchtet (aber das will er ja erreichen). Aber ich bin also etwas vorsichtiger.

Viele Grüsse und Danke

Philipp

[Henryk Plötz]

Moin,

Oder an eine Verbindung mit schwacher Anbindung. OK. Soweit ist mir jetzt auch traceroute ein Begriff. Schade, dass man das nicht mit Perl machen kann (ohne auf externe Programme zuzugreifen).

Oh man kann. Es gibt zumindest Module dafür: (ohne jetzt von Perl Ahnung zu haben) such mal nach pcap und libnet. (Und ich möchte wetten, dass irgendjemand bestimmt auch ein traceroute-Modul geschrieben hat.)

--
Henryk Plötz
Grüße aus Berlin

* Help Microsoft combat software piracy: Give Linux to a friend today! *

[Philipp Hasenfratz]

Halihallo Henryk

Oder an eine Verbindung mit schwacher Anbindung. OK. Soweit ist mir jetzt auch traceroute ein Begriff. Schade, dass man das nicht mit Perl machen kann (ohne auf externe Programme zuzugreifen).

Oh man kann. Es gibt zumindest Module dafür: (ohne jetzt von Perl Ahnung zu haben) such mal nach pcap und libnet. (Und ich möchte wetten, dass irgendjemand bestimmt auch ein traceroute-Modul geschrieben hat.)

Nun, ein traceroute-Modul hab ich zwar noch nicht gefunden, dafür die Module, die diesen low-level-access zulassen (auf TCP/IP-Packet Ebene). Aber ein traceroute-Modul brauche ich ja eigentlich gar nicht. Hätte mich nur interessiert.

Vielen Dank nochmals

Philipp

[Philipp Hasenfratz]

Halihallo

Oder an eine Verbindung mit schwacher Anbindung. OK. Soweit ist mir jetzt auch traceroute ein Begriff. Schade, dass man das nicht mit Perl machen kann (ohne auf externe Programme zuzugreifen).

Oh man kann. Es gibt zumindest Module dafür: (ohne jetzt von Perl Ahnung zu haben) such mal nach pcap und libnet. (Und ich möchte wetten, dass irgendjemand bestimmt auch ein traceroute-Modul geschrieben hat.)

Nun, ein traceroute-Modul hab ich zwar noch nicht gefunden, dafür die Module, die diesen low-level-access zulassen (auf TCP/IP-Packet Ebene). Aber ein traceroute-Modul brauche ich ja eigentlich gar nicht. Hätte mich nur interessiert.

[http://search.cpan.org/doc/HAG/Net-Traceroute-1.05/Traceroute.pm]

upsa :-)

viele Grüsse

Philipp

[Philipp Hasenfratz]

Halihallo

Oder an eine Verbindung mit schwacher Anbindung. OK. Soweit ist mir jetzt auch traceroute ein Begriff. Schade, dass man das nicht mit Perl machen kann (ohne auf externe Programme zuzugreifen).

Oh man kann. Es gibt zumindest Module dafür: (ohne jetzt von Perl Ahnung zu haben) such mal nach pcap und libnet. (Und ich möchte wetten, dass irgendjemand bestimmt auch ein traceroute-Modul geschrieben hat.)

Nun, ein traceroute-Modul hab ich zwar noch nicht gefunden, dafür die Module, die diesen low-level-access zulassen (auf TCP/IP-Packet Ebene). Aber ein traceroute-Modul brauche ich ja eigentlich gar nicht. Hätte mich nur interessiert.

[http://search.cpan.org/doc/HAG/Net-Traceroute-1.05/Traceroute.pm]

http://search.cpan.org/doc/HAG/Net-Traceroute-1.05/Traceroute.pm

so, zudem Funktioniert das Modul nicht auf allen OS, da es, wie ich es eben nicht haben wollte, auf externe tracer zugreift... Entschuldigung, dass ich mir beim schreiben des letzten Postings nicht etwas mehr überlegt habe, bzw. die Doku erst angeschaut habe... Aber wie gesagt: Ich brauche das Modul gar nicht, es hätte mich nur interessiert, wie's programmiert ist. Ich bin mir sicher, dass ich auch mit googlen noch auf ein "richtiges" Traceroute-Modul stossen würde, wenn ich es bräuchte.

Viele Grüsse

Philipp