kernel32.dll will Internetverbindung

[Sven Rautenberg]

Moin!

Local Address :  192.168.2.101

Na klasse da ham wer schon einen anfang :-)
Daraus lässt sich folgern das hier ein DHCP-server läuft der Ips im Bereich
von 192.168.2.100 bis 192.168.2.xxx verteilt

Das läßt sich nicht "folgern", sondern das ist schlicht geraten - sowohl die Existenz des DHCP-Servers, als auch der IP-Bereich, den er eventuell zu vergeben hat.

Und darüber hinaus würde es auch nichts ändern, wenn man wüßte, dass die IP per DHCP vergeben würde, oder statisch: So oder so wäre dieser Rechner aus dem Internet sowieso nicht erreichbar unter dieser IP.

Destination:  00-12-bf-4f-1d-6e
Source:  00-0c-f6-16-3c-ce

es kommt noch besser :-)
Das is die Mac-Adresse! Ich hoffe nur das Du DIR bewusst bist , das diese weltweit einmalig ist und Dein Recćhner, bzw, Deine Netzwerkare daran eindeutig erkennbar ist.

Richtig, die MAC-Adresse _sollte_ weltweit einmalig sein. Es gibt aber dumme Zufälle, bei denen eine MAC-Adresse nicht nur zweimal an eine Netzwerkkarte vergeben wird, sondern diese zwei Netzwerkkarten dann auch noch im gleichen Netzwerk zusammengeschlossen werden - und für sehr interessante Netzwerkfehler sorgen können. Ist alles in der Realität schon vorgekommen.

Darüber hinaus: Die MAC-Adresse wird ohnehin nur im lokalen Netzwerksegment verbreitet, einen Router überwindet sie nicht - jedenfalls nicht aufgrund des Ethernet- oder TCP/IP-Protokolls (wenn ein Programm die MAC-Adresse ausliest und versendet, ist das was anderes, darum gehts hier aber nicht).

Du würdest also weder die MAC-Adresse sehen können, noch aktiv nach ihr suchen.

Internet Control Message Protocol
Type: 11 (Time Exceeded for Datagram)
Code: 1 (Fragment Reassembly Timer Expired - from host)
Data (32 bytes)

wie schön hier ham wer dann auch noch den Packetaufbau :-)

Ja, ein ganz langweiliges ICMP-Paket.

und somit alles zusammen um jede Firewall hübsch zu umgehen:-)

Das sehe ich anders. Erstens: Diese Daten betreffen Pakete, die der betroffene Computer _senden_ wollte, nicht empfangen. Zweitens: Diese Pakete werden zur Zeit gefiltert, sie verlassen den Rechner also nicht. Und drittens: Woher kennst du die Konfiguration der Eingangsregeln, um diese zu umgehen? Die Ausgangsregeln sind ja erstmal irrelevant und werden in der Regel zur Erlangung von Root-Rechten nicht unbedingt benötigt.

Wie Sven schon richtig bemerkt hat is es durchaus möglich was böses z.B. in die zweite Schicht (Session_layer) der OSI-schichten einzubauen.

Das ist mir gar nicht aufgefallen, dass ich sowas bemerkt hätte.

Abgesehen davon darfst du in Zusammenhang mit TCP/IP das OSI-Modell gerne ad acta legen, da es nicht ganz zutreffend ist. Es hat akademischen Wert, aber wenn es um konkrete Protokolle mit konkreten Hacks für Angriffe geht, argumentiert man doch lieber mit den konkreten Schichten dieses Protokolls.

Das gilt insbesondere dann, wenn man mit der Numerierung und Bezeichnung der Schichten durcheinanderkommt. Laut OSI-Modell ist Schicht 2 die Sicherungsschicht (data link), der "Session Layer" wäre Schicht 5. Und beide Schichten sind für deine Argumentation unzugänglich, weil die Schicht 2 in einem TCP/IP-Netzwerk der untersten Schicht, hier "Ethernet" entspricht, und die Schicht 5 der obersten Schicht, nämlich den höchsten Protokollen HTTP, FTP, und so weiter.

Eine für einen Angreifer aus dem Internet zugängliche Schicht wäre ab der zweiten Schicht (OSI-Schicht 3: "Vermittlung - network layer") anzusiedeln: IP-Protokoll, ICMP, IGMP. Durch Feintuning passender Datenpakete läßt sich so manches Programm und Firewall in interessanter Weise "neugestalten".

In Schicht 3 (OSI-Schicht 4: "Transport - transport layer") mit TCP, UDP, wäre ebenfalls ein Ansatzpunkt für Manipulationen.

Und Schicht 4 (OSI-Schichten 5 bis 7: "session, presentation and application layer") mit den bekannten Protokollen wäre im Grundsatz auch noch manipulierbar, daran wird sich eine paketfilternde Firewall aber nicht stören.

Binary dump of the packet:
0000:  00 12 BF 4F 1D 6E 00 0C : F6 16 3C CE 08 00 45 00 | ...O.n....<...E.
Hilfreich? Ich denke doch eher nicht, oder?

Doch absolut Hilfreich für jeden der was davon versteht und ohne sich über Die verwendete Firewall gedanken zu machen Dir böses will :_(

Ich glaube kaum, dass der Dump eines ICMP-Paketes, das automatisch vom Betriebssystem generiert wurde, und dessen Inhalt in Textform schon ausführlich oben ausgebreitet wurde, noch irgendeine geheime und vor allem nutzbare Botschaft enthalten könnte.

Unter dem Strich: Dein Beitrag war eigentlich absolut nicht hilfreich. Weder wurden handfeste, zutreffende Aussagen getroffen, noch sonst irgendein Beweis für deine Andeutungen hinsichtlich der Brisanz der veröffentlichten Information angetreten. In Netzwerkdingen mußt du noch hinzulernen.

- Sven Rautenberg