warum pingt mich data.univie.ac.at an?

weilst ein eierbär bist und die das genau wissen

lol, warum regst dich so auf? ich denke die antwort von masdah ist eher spaßig zu nehmen, da deine frage eher in die kategorie "weiß niemand" fällt. oder brauchst du noch extra sarkasmus-tags um beleidigungen von belustigungen zu trennen? :p

also: nachdem dir offensichtlich deine firewall diesen icmp echo request präsentiert hat, weißt du ja dass es auch sonst genug in der leitung rauscht. vielleicht ist die source ip dieses pakets auch gespooft? Anyway, was soll man dir antworten?

Hast du vielleicht irgendwas mit dem VPN der Uni am Hut? Ich könnte mir vorstellen, das so ein regelmäßiger Ping ein is-alive Mechanismus ist.

Das übliche Datenpaket welches man hereinbekommt besteht aus 3 (oder mehr) Teilen: Den MAC-Abschnitt, da steht Info über die NW-Karte drin und welches "Ethertype" folgt. Steht dort IP, kommt eben der IP-Abschnitt, da steht unter anderem die Source und Destination IP drin, sowie das Protokoll des Payloads (TCP, UDP, ICMP, etc).

Bei üblicher Programmierung bestimmt man nur den Inhalt des Payloads. Wenn man hingegen RAW-Sockets verwendet, kann (muss) man auch die ersten zwei Abschnitte ausprogrammieren (was normalerweise das OS erledigen würde). Und da steht es einem frei reinzuschreiben, was man will.

Du siehst, die beiden Spoofing Varianten haben mit dem selben Prinzip zu tun. Obwohl MAC-Spoofing eher für den lokalen Gebrauch gut ist (Modem austricksen) kann man mit IP-Spoofing einiges anstellen (DDoS).

Das Chello Student könnte schon was damit zu tun haben. Da ich außerhalb von Wien wohne und (zum Glück :verycool: ) kein Chello habe, kann ich nur mein Halbwissen weitergeben, *schnell gegoogelt und gefunden* oder lies dir http://www.zid.tuwien.ac.at/zidline/zl04/chellosc.html, Punkt Technisches durch.

Socket: http://en.wikipedia.org/wiki/Socket, http://www.webopedia.com/TERM/s/socket.html

Deine Interpretation ist vollkommen korrekt. Mit üblicher Programmierung meine ich die Befehle zum erstellen und kommunizieren über einen Socket (socket(), bind(), send(), sendto(), ...). Bei den RAW-Sockets schreibt man sich zusätzlich die Datenstrukturen für zB IP, füllt diese und schickt dann alles los. Google sollte dir bei Code-Beispielen weiterhelfen.

Hier noch eine anschauliche Erklärung: http://www.cs.huji.ac.il/support/docs/tcp/section3.2.html

Ich denke den Rest schaffst du allein

Zitat von flotschie

Normale Betriebssysteme "füllen" die ersten beiden Abschnitte des Datenpaketes, Mac Adresse & IP adresse automatisch aus. Verwendet man RAW Sockets müssen oder können diese Werte vom User vergeben werden.

Korrekt. Braucht man zB, um ein IP-Protkoll zu implementieren, das vom Kernel nicht zur Verfügung gestellt wird (traceroute und GRE fallen mir so auf die schnelle ein).

Zitat

--> Wie macht man das? Programmiert man sich dann sozusagen sein eigenes Paket zusammen, wenn ja wie geht das?

Unter UNIX muss man einfach einen socket aufmachen, mit RAW als parameter, und dann schreibt man dort mittels write() jedes Paket (incl. Header) raus. Braucht root-Permissions. Unter Windows muss man meines wissens nach im Kernel sein, um das machen zu können.

Zitat von flotschie

hal: ...und im windows kernel hat glaub ich keiner was verloren oder :-))?

Sag das nicht... das tolle Security-Konzept von Windows verlangt es, dass sämtliche Treiber (von Grafikkarte über Drucker bis Digitalkamera) im Kernel selber fuhrwerken. Das macht einen großen Teil der berüchtigten Instabilität aus (wenn ein einziger Treiber cräsht ist das komplette System weg).

RAW-Sockets: Es reichen Administrator Rechte unter Windows, man braucht kein Kernel-Modul.

Folgendes ist noch bei Kernel vs. Userland zu erwähnen: Die damals erste Entscheidung bei MS war bei der Entwicklung von NT 4, das Grafik-Subsystem in den Kernel zu verlagern, vor allem wegen des Geschwindigkeitsaspekts. Das MS damit die Kontrolle über die Stabilität aus der Hand gibt, hat man so gerechtfertigt dass Treiberhersteller ihre Software bei MS einer Qualitätsprüfung unterziehen und signieren lassen sollen. Vermutlich gegen Gebühr und damit nur für große Firmen geeignet.

traceroute: ist rein technisch kein eigenes Protokoll, sondern nur ICMP Echo Requests mit bei 1 beginnenden und fortlaufend inkrementierten TTL, sodass jeweils der Router mit abgelaufenen TTL eine Meldung zurückgibt. Da man dafür dennoch RAW-Sockets Zugriff braucht, passt es als Beispiel.

Zitat von Dave2003

traceroute: ist rein technisch kein eigenes Protokoll, sondern nur ICMP Echo Requests mit bei 1 beginnenden und fortlaufend inkrementierten TTL, sodass jeweils der Router mit abgelaufenen TTL eine Meldung zurückgibt. Da man dafür dennoch RAW-Sockets Zugriff braucht, passt es als Beispiel.

du meinst tracert, die "windows" version von traceroute, hehe... die gängigen Implementationen von traceroute versenden nämlich UDP pakete mit von 1 ansteigender TTL und listen die erhaltenen Unreachable/Time exceeded icmp messages. als port wird immer was hohes verwendet, also jenseits der 30000. bei vielen varianten von traceroute kann man sogar die source ip addresse angeben (natürlich nur als superuser) und natürlich auch source und destination port...

hmm, grad nachgesehen, tatsächlich.
wie konnte mir das nur entgehen?

Zitat von Dave2003

wie konnte mir das nur entgehen?

mach dir nichts draus, das scheint ein verbreiteter Glaube zu sein: ich hab mich während des Studium schon mindestens 4x (an die kann ich mich erinnern) mit anderen Studenten darüber "gestritten", und geglaubt wurde mir immer erst nach einem gemeinsamen "man traceroute" in einem ZID-Raum