Verirrte TCP Packete

HornOx

HornOx

Registered User
Hallo,
ich hab mal etwas mit tcpdump gespielt und dabei ein paar verirrte TCP Packete aufgeschnappt:
Code: 
devmode:~# tcpdump -n 'tcp and not net xxx.xxx.188.219'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
22:37:14.891680 IP xxx.xxx.40.51.1150 > xxx.xxx.186.158.80: . ack 3671887679 win 8760
22:37:47.899405 IP xxx.xxx.11.212.1934 > xxx.xxx.186.228.11815: . ack 2435773594 win 17424
22:38:18.466041 IP xxx.xxx.75.42.1290 > xxx.xxx.184.105.1433: S 4218406981:4218406981(0) win 65535 <mss 1460,nop,nop,sackOK>
22:39:13.631372 IP xxx.xxx.61.194.56206 > xxx.xxx.186.138.80: S 2234507446:2234507446(0) win 16384 <mss 1402,nop,nop,sackOK>
22:39:30.067676 IP xxx.xxx.16.194.58670 > xxx.xxx.186.169.80: . ack 3415471323 win 65535
22:39:35.186652 IP xxx.xxx.75.42.1714 > xxx.xxx.186.16.1433: S 3808495190:3808495190(0) win 65535 <mss 1460,nop,nop,sackOK>
22:39:38.106993 IP xxx.xxx.75.42.1714 > xxx.xxx.186.16.1433: S 3808495190:3808495190(0) win 65535 <mss 1460,nop,nop,sackOK>
22:39:42.397060 IP xxx.xxx.65.101.37971 > xxx.xxx.186.234.80: S 2692641015:2692641015(0) win 5720 <mss 1430,sackOK,timestamp 422088791 0,nop,wscale 0>
22:39:44.142870 IP xxx.xxx.75.42.1714 > xxx.xxx.186.16.1433: S 3808495190:3808495190(0) win 65535 <mss 1460,nop,nop,sackOK>
22:39:47.956454 IP xxx.xxx.84.35.52487 > xxx.xxx.186.16.110: S 2514195133:2514195133(0) win 65535 <mss 1372,nop,wscale 0,nop,nop,timestamp 1532504349 0>
22:39:56.390254 IP xxx.xxx.75.42.1881 > xxx.xxx.186.183.1433: S 3140948615:3140948615(0) win 65535 <mss 1460,nop,nop,sackOK>
22:40:50.553156 IP xxx.xxx.49.90.25332 > xxx.xxx.186.47.25: S 3025205148:3025205148(0) win 16384 <mss 1452,nop,nop,sackOK>
22:40:56.942608 IP xxx.xxx.69.252.4889 > xxx.xxx.186.145.80: P 3234508614:3234509411(797) ack 374976544 win 17424
22:41:09.407502 IP xxx.xxx.136.87.3189 > xxx.xxx.186.192.80: . ack 1427081740 win 32767
22:41:09.422914 IP xxx.xxx.136.87.3189 > xxx.xxx.186.192.80: P 0:302(302) ack 1 win 32767
22:41:29.923096 IP xxx.xxx.65.203.61319 > xxx.xxx.186.101.80: . ack 1156142975 win 34032 <nop,nop,timestamp 656381707 978729806>
22:41:29.923430 IP xxx.xxx.65.203.61319 > xxx.xxx.186.101.80: . ack 2837 win 34032 <nop,nop,timestamp 656381707 978729806>
22:41:29.923609 IP xxx.xxx.65.203.61319 > xxx.xxx.186.101.80: . ack 5673 win 34032 <nop,nop,timestamp 656381707 978729806>
22:41:29.923854 IP xxx.xxx.65.203.61319 > xxx.xxx.186.101.80: . ack 8509 win 34032 <nop,nop,timestamp 656381707 978729806>
22:41:29.924038 IP xxx.xxx.65.203.61319 > xxx.xxx.186.101.80: . ack 11345 win 34032 <nop,nop,timestamp 656381707 978729806>
22:41:29.924351 IP xxx.xxx.65.203.61319 > xxx.xxx.186.101.80: . ack 14181 win 34032 <nop,nop,timestamp 656381707 978729807>
22:41:29.924882 IP xxx.xxx.65.203.61319 > xxx.xxx.186.101.80: . ack 17017 win 34032 <nop,nop,timestamp 656381707 978729807>
22:41:29.925220 IP xxx.xxx.65.203.61319 > xxx.xxx.186.101.80: . ack 19853 win 34032 <nop,nop,timestamp 656381707 978729807>
22:41:29.925482 IP xxx.xxx.65.203.61319 > xxx.xxx.186.101.80: . ack 22497 win 34032 <nop,nop,timestamp 656381707 978729807>
22:41:30.866881 IP xxx.xxx.65.203.35998 > xxx.xxx.186.101.80: S 2798281784:2798281784(0) win 5720 <mss 1430,sackOK,timestamp 656381802 0,nop,wscale 0>
22:41:46.183615 IP xxx.xxx.152.198.2739 > xxx.xxx.186.18.80: S 482200217:482200217(0) win 17280 <mss 1460,nop,nop,sackOK>
22:41:50.944565 IP xxx.xxx.244.116.2330 > xxx.xxx.186.60.80: . ack 1058522916 win 17520
22:42:00.038973 IP xxx.xxx.16.229.2102 > xxx.xxx.184.22.80: . ack 1379005665 win 65346
22:42:00.103509 IP xxx.xxx.61.213.4815 > xxx.xxx.184.22.80: F 4047306608:4047306608(0) ack 1405075554 win 65126
22:42:11.819415 IP xxx.xxx.188.74.60484 > xxx.xxx.186.95.80: S 1520594073:1520594073(0) win 65535 <mss 1460,nop,nop,sackOK>
22:42:38.906095 IP xxx.xxx.48.41.8329 > xxx.xxx.186.66.80: . ack 2860989298 win 65535
22:43:10.839333 IP xxx.xxx.141.101.40916 > xxx.xxx.186.134.25: S 1812996930:1812996930(0) win 5840 <mss 1460,sackOK,timestamp 1304413464 0,nop,wscale 0>
22:43:44.914464 IP xxx.xxx.157.37.49193 > xxx.xxx.186.185.80: . ack 2917817239 win 16896
22:43:44.950655 IP xxx.xxx.157.37.49193 > xxx.xxx.186.185.80: . ack 2817 win 16896
22:43:44.963915 IP xxx.xxx.157.37.49193 > xxx.xxx.186.185.80: . ack 3911 win 15802
22:43:45.020552 IP xxx.xxx.157.37.49193 > xxx.xxx.186.185.80: P 0:669(669) ack 3911 win 15802
22:45:24.966033 IP xxx.xxx.65.244.55960 > xxx.xxx.186.220.1352: S 2788682889:2788682889(0) win 5840 <mss 1406,sackOK,timestamp 1566943040 0,nop,wscale 2>
22:45:56.686709 IP xxx.xxx.152.161.62995 > xxx.xxx.186.235.445: S 2473129735:2473129735(0) win 16384 <mss 1452,nop,nop,sackOK>
22:45:56.949584 IP xxx.xxx.111.171.61662 > xxx.xxx.184.21.80: . ack 3078846049 win 63413
22:45:58.592753 IP xxx.xxx.124.92.61044 > xxx.xxx.184.21.80: R 1919245425:1919245425(0) win 0
22:45:58.597775 IP xxx.xxx.124.92.61043 > xxx.xxx.184.21.80: R 1919161088:1919161088(0) win 0

41 packets captured
41 packets received by filter
0 packets dropped by kernel
Alle Ziel IPs sind zwar im Netz meines Providers aber gehören nicht mir. Die meisten Packete beinhalten keinen "verwertbaren" Informationen aber ich hab auch schon unverschlüsselte POP3, SMTP, HTTP mit Cookies und MySQL Packete gesehen weshalb man mit den richtigen Filtern vermutlich bald Passwörter, private Daten o.ä. finden könnte. Das ich fremde IP Packete zugeschickt bekomme stört mich eigentlich nicht wirklich aber es ist sehr wahrscheinlich das auch diverse IP Packete die für meinen Server bestimmt sind an fremde Server geschickt werden :(
Ist das normales Hintergrundrauschen bei einem Serverprovider im "günstigen Preissegment" oder soll ich ein Ticket schreiben?
Was verursacht die Querschläger? Irgendwie kann ich mir schlecht vorstellen das ein Router oder Switch wirklich von Zeit zu Zeit Packete an die falsche IP Addressen liefert!?
Abgesehen von dem promiscuous Modus bei meiner Netzwerkkarte hab ich nicht's gemacht, AFAIK sollte passives Mitloggen ohne ARP-Spoofing oder ähnliches noch legal sein.
 
Last edited by a moderator:
Bei Hubs sollten es viel mehr Packete/Zeit. 41 Packete in 8 Minuten(siehe Logs oben) können eigentlich nur "Unfälle" sein.
 
Der Support von meinem Server Provider (ja, es ist S4Y) hat mir, mit einem (von mir nicht nachvollziehbaren:() Hinweis auf nicht näher genannte Passagen vom Bürgerlichen Gesetzbuch, verboten im promiscuous Modus zu sniffen. Er hat bestätigt das Packete gebroadcastet werden. Er hat _nicht_ gesagt das er das verschicken von Datenpacketen an Server für die sie nicht bestimmt sind für problematisch halten würde oder das sich das irgendwann ändern würde (das wären die Aussagen die ich mir vom Support gewünscht hätte).
Es ist AFAIK für einen Provider sehr schwer Indizien oder gar Beweise für einen aktivierten promiscuous Modus bei einer Netzwerkkarte zu finden (es sei den sie haben root Zugriff auf den Rechner), S4Y kann also meines Wissens nach nicht verhindern das Unbefugte meinen Traffic mitlesen. tcpdump hat damals Traffic von 4 /24 Netzen empfangen, das heißt im schlimsten Fall sind das ~1000 Leute die mitlauschen könnten.
Ich verwende soweit wie möglich verschlüsselte Protokolle (ssh,sftp und pop3/smtp over ssl), aber ich kann nicht ausschließen das ein fremder Mailserver mir Mails mit unverschlüsseltem schickt (zumindest sollange ich die Mail empfangen will). Auch mein Forum werde ich wegen des sonst zu erwartenden Leistungseinbruchs nicht auf https umzustellen, nur für den Foren Admin Account bastel ich mir eine Sonderlösung. Jetzt schreibe ich erstmal die (nicht fristlose) Kündigung meines Servers.


btw, verwendet das von S4Y vorinstallierte Confixx und Plesk eigentlich http oder https?
[edit]Hab noch was gefunden: http://www.heise.de/ct/05/02/042/default.shtml [/edit]
 
Auch ein Switch arbeitet mal als Hub, entweder wenn er die MAC Adresse noch nicht gelernt hat (oder der Eintrag im ARP Cache veraltet ist) an den entsprechenden Ports, oder wenn er einfach überfordert ist schmeißt er kurzzeitig die Pakete an alle Ports raus weil es schneller ist als Store-and-Forward oder Cut-through ist(Das macht er solange bis sein Cache wieder leer ist und die Auslastung ok...).

Stichwort Failopen.
 
Last edited by a moderator:
Ja, sorry ;) Kommt auf den Switch an, ob Layer2 oder Layer3 Switch ... Aber mit dem umgangssprachlichen Switch (Layer2) da haste vollkommen Recht, da sind wir auf Schicht 2 da gibts keine IPs also auch kein Arp.
 
Laut dem Test aus der aktuellen CT sind zumindest die vServer im moment nicht dafür anfällig.
 
Auch ein Switch arbeitet mal als Hub, entweder wenn er die MAC Adresse noch nicht gelernt hat[...]
Click to expand...
Die Packete sind IMHO zu zufällig als das sie sich damit erklären lassen (zumindest wenn man davon ausgeht das Root Server nicht ständig neu gebootet bzw neu angeschlossen werden.) S4Y hat eine Mindestvertragslaufzeit von 12 Monaten, da sollte statisches Routing ein zumutbarer Mehraufwand sein.
oder wenn er einfach überfordert ist schmeißt er kurzzeitig die Pakete an alle Ports raus weil es schneller ist als Store-and-Forward oder Cut-through ist [...]Stichwort Failopen.
Click to expand...
Dann müßten aber schübeweise Packete eintreffen was laut Logs nicht der Fall ist.
 
Wenn der Cache der Switches defekt ist oder überfüllt, passiert das einfach das der Switch in den Hub Modus wechselt, sonst müsste er ja seine Tätigkeit einstellen. S4Y hat ja schon 2004 mal das Problem gehabt und C´t hat darüber berichtet. Naja, wundern würde es mich nicht wenn nichts passiert wäre. Wenn DAS wirlich deren "Rechenzentrum" ist, dann weiß ich wer in Ebay die ganzen Rechner aufkauft ;)
 
You must log in or register to reply here.
Back
Top