Komische Netzwerkkommunikation in den Logs

F

Fluffy

Guest
Hi!
Ich habe Logging in den IPTables angeschaltet, und habe dafür bitmunchers Vorlange genommen(danke dafür ;) ).

Wenn ich nun einige Seiten besuche, zB Google(aber auch ein oder 2 andere Seiten)
Dann bekomme ich mehrfache Logeinträge die man mittels dmesg -e --follow gut verfolgen kann.

Ich glaube nicht das da was ernsthafters hintersteckt, ausgehend von den src-ports, aber ich Verstehe auch nicht was genau dort vorfällt.
IMHO schließt mein Browser(FF) die Verbindung und der Server will i.w. senden, und da diese Antworten nicht mehr Aktuell sind, wird die Verbindung geblockt, da sie keinen Bezug mehr hat.
Aber , wie gesagt, rate ich damit.

[Jun23 21:02] FIREWALL REJECT IN=wlp3s0 OUT= MAC=e6:94:3a:63:10:b8:08:bd:43:8f:e5:44:08:00 SRC=64.233.189.95 DST=192.168.0.11 LEN=40 TOS=0x00 PREC=0x00 TTL=43 ID=30588 PROTO=TCP SPT=443 DPT=40905 WINDOW=0 RES=0x00 RST URGP=0
[ +0.000042] FIREWALL REJECT IN=wlp3s0 OUT= MAC=e6:94:3a:63:10:b8:08:bd:43:8f:e5:44:08:00 SRC=64.233.189.95 DST=192.168.0.11 LEN=40 TOS=0x00 PREC=0x00 TTL=43 ID=30589 PROTO=TCP SPT=443 DPT=40905 WINDOW=0 RES=0x00 RST URGP=0

Freu mich über Input.
Gruß

Fluffy
 
Ohne den Inhalt der Pakete zu kennen, ist es schwierig zu diesen was zu sagen. Mit dem NFLOG-Target sollte es möglich sein auch die gedroppten Pakete zu sehen:

Code: 
iptables -A INPUT -j NFLOG # bei Bedarf hier noch weitere Parameter für Source, Protokoll etc. anfügen

Die so geloggten Pakete kannst du dann mittels tcpdump anschauen.

Code: 
tcpdump -i nflog
 
Hallo über nflog habe ich in den iptable-manpages was gefunden, aber nicht bei tcpdump.
Kann es sein das das ein wenig dokumentiertes feature ist und wo finde ich zusätzliche Dokumentation?(hab nämlich nix über die flags fürs zusätzliche logging gefunden oder was FLAGS[R] bedeutet obwohl ich glaube das das TCP Rst ist)

Hier die Ausgabe von tcpdump -i nflog -vv

Code: 
20:50:23.418703 IP (tos 0x0, ttl 57, id 46277, offset 0, flags [DF], proto TCP (6), length 40)
    141.101.114.110.http > qs.34986: Flags [.], cksum 0x57d3 (correct), seq 599088194, ack 3792874513, win 30, length 0
20:50:35.528915 IP (tos 0x0, ttl 57, id 49697, offset 0, flags [DF], proto TCP (6), length 40)
    141.101.114.110.http > qs.34987: Flags [.], cksum 0x40b7 (correct), seq 3054861874, ack 2875934083, win 30, length 0
20:50:35.528929 IP (tos 0x0, ttl 50, id 35855, offset 0, flags [DF], proto TCP (6), length 40)
    72.21.91.8.http > qs.34535: Flags [R], cksum 0x802c (correct), seq 3212674280, win 0, length 0
20:50:42.275673 IP (tos 0xc0, ttl 56, id 0, offset 0, flags [DF], proto TCP (6), length 40)
    68.232.44.121.http > qs.34593: Flags [R], cksum 0x0f46 (correct), seq 2661173296, win 0, length 0
20:50:45.594369 IP (tos 0x0, ttl 46, id 21472, offset 0, flags [DF], proto TCP (6), length 40)
    li1016-182.members.linode.com.https > qs.33169: Flags [R], cksum 0x0d13 (correct), seq 4210945970, win 0, length 0
20:50:48.334502 IP (tos 0x0, ttl 45, id 0, offset 0, flags [DF], proto TCP (6), length 40)
    5.77.52.12.http > qs.37758: Flags [R], cksum 0x6d7f (correct), seq 930774214, win 0, length 0
20:50:53.433289 IP (tos 0x0, ttl 45, id 0, offset 0, flags [DF], proto TCP (6), length 40)
    5.77.52.12.http > qs.37760: Flags [R], cksum 0x6a4e (correct), seq 3988441524, win 0, length 0
20:50:53.433306 IP (tos 0x0, ttl 45, id 0, offset 0, flags [DF], proto TCP (6), length 40)
    5.77.52.12.http > qs.37757: Flags [R], cksum 0xa455 (correct), seq 226979812, win 0, length 0
20:50:53.433317 IP (tos 0x0, ttl 45, id 0, offset 0, flags [DF], proto TCP (6), length 40)
    5.77.52.12.http > qs.37759: Flags [R], cksum 0xf257 (correct), seq 238559535, win 0, length 0
20:50:53.433328 IP (tos 0x0, ttl 45, id 0, offset 0, flags [DF], proto TCP (6), length 40)
    5.77.52.12.http > qs.37756: Flags [R], cksum 0xc17f (correct), seq 4226376792, win 0, length 0

Code: 
FIREWALL REJECT IN=wlp3s0 OUT= MAC=e6:7d:be:f0:e1:16:08:bd:43:8f:e5:44:08:00 SRC=141.101.114.110 DST=192.168.0.81 LEN=40 TOS=0x00 PREC=0x00 TTL=57 ID=46277 DF PROTO=TCP SPT=80 DPT=34986 WINDOW=30 RES=0x00 ACK URGP=0 
[  +0.000023] FIREWALL REJECT IN=wlp3s0 OUT= MAC=e6:7d:be:f0:e1:16:08:bd:43:8f:e5:44:08:00 SRC=141.101.114.110 DST=192.168.0.81 LEN=40 TOS=0x00 PREC=0x00 TTL=57 ID=49697 DF PROTO=TCP SPT=80 DPT=34987 WINDOW=30 RES=0x00 ACK URGP=0 
[  +0.141143] FIREWALL REJECT IN=wlp3s0 OUT= MAC=e6:7d:be:f0:e1:16:08:bd:43:8f:e5:44:08:00 SRC=72.21.91.8 DST=192.168.0.81 LEN=40 TOS=0x00 PREC=0x00 TTL=50 ID=35855 DF PROTO=TCP SPT=80 DPT=34535 WINDOW=0 RES=0x00 RST URGP=0 
[  +6.098635] FIREWALL REJECT IN=wlp3s0 OUT= MAC=e6:7d:be:f0:e1:16:08:bd:43:8f:e5:44:08:00 SRC=68.232.44.121 DST=192.168.0.81 LEN=40 TOS=0x00 PREC=0xC0 TTL=56 ID=0 DF PROTO=TCP SPT=80 DPT=34593 WINDOW=0 RES=0x00 RST URGP=0 
[  +0.858385] FIREWALL REJECT IN=wlp3s0 OUT= MAC=e6:7d:be:f0:e1:16:08:bd:43:8f:e5:44:08:00 SRC=45.33.70.182 DST=192.168.0.81 LEN=40 TOS=0x00 PREC=0x00 TTL=46 ID=21472 DF PROTO=TCP SPT=443 DPT=33169 WINDOW=0 RES=0x00 RST URGP=0 
[  +4.849436] FIREWALL REJECT IN=wlp3s0 OUT= MAC=e6:7d:be:f0:e1:16:08:bd:43:8f:e5:44:08:00 SRC=5.77.52.12 DST=192.168.0.81 LEN=40 TOS=0x00 PREC=0x00 TTL=45 ID=0 DF PROTO=TCP SPT=80 DPT=37758 WINDOW=0 RES=0x00 RST URGP=0 
[  +0.000101] FIREWALL REJECT IN=wlp3s0 OUT= MAC=e6:7d:be:f0:e1:16:08:bd:43:8f:e5:44:08:00 SRC=5.77.52.12 DST=192.168.0.81 LEN=40 TOS=0x00 PREC=0x00 TTL=45 ID=0 DF PROTO=TCP SPT=80 DPT=37760 WINDOW=0 RES=0x00 RST URGP=0 
[  +0.000037] FIREWALL REJECT IN=wlp3s0 OUT= MAC=e6:7d:be:f0:e1:16:08:bd:43:8f:e5:44:08:00 SRC=5.77.52.12 DST=192.168.0.81 LEN=40 TOS=0x00 PREC=0x00 TTL=45 ID=0 DF PROTO=TCP SPT=80 DPT=37757 WINDOW=0 RES=0x00 RST URGP=0


Wie man sehen kann tritt das auch bei anderen Websiten auf.
Gruß

Fluffy
 
Setze mal bitte -A als Flag. Damit solltest du den Paket-Inhalt als ASCII ausgegeben bekommen, wodurch man wesentlich eher sehen kann was dort übertragen wird. Alternativ -XX um Hex und ASCII angezeigt zu bekommen. Macht natürlich nur bei den HTTP-Paketen Sinn. Bei HTTPS wirst du nur kryptischen Inhalt haben.
 
Hmm hab es gerade eben nur mit https hinbekommen.
Aber dank deiner Hilfe sehe ich mich bestätigt, das es an der instabilen Verbindung hier liegt.
Denn die HTTPS-Packete haben, wenn auch verschlüsselt, augenscheinlich den gleichen Inhalt, zumindest wird er so in Ascii abgebildet, und das zusammen mit der Sequenznummer zeugt von einer Wiederholung.


Code: 
19:18:08.779730 IP syd09s01-in-f129.1e100.net.https > k0V.48909: Flags [R], seq 2455375294, win 0, length 0
E..('...5....:.....^.....Z......P....<..
19:18:10.297122 IP syd09s01-in-f129.1e100.net.https > k0V.48909: Flags [R], seq 2455375294, win 0, length 0
E..('...5....:.....^.....Z......P....<..
19:25:45.839700 IP syd09s01-in-f142.1e100.net.https > k0V.43926: Flags [R], seq 2284622709, win 0, length 0
E..(....6.eW.:.....a.....,.u....P...q...
19:25:54.333031 IP syd09s01-in-f142.1e100.net.https > k0V.43926: Flags [R], seq 2284622709, win 0, length 0
E..(....6.eV.:.....a.....,.u....P...q...

Liebe Grüße

Fluffy
 
Um antworten zu können musst du eingeloggt sein.
Zurück
Oben