Seit neuem keine Portfreigabe mehr möglich.

[SpaceRat]

Wie sind die ersten 3 Zeichen der IPv4-Adresse aus dem TC7200?

Sagt das irgendwas aus?

Nicht das Geringste.

[tq1199]

Die Ip Adresse lautet:

178.202.xxx.xx

Sagt das irgendwas aus?

Ja, dass Du eine IPv4-Adresse hast, die über das Internet geroutet wird.

[SpaceRat]

Sagt das irgendwas aus?

Ja, dass Du eine IPv4-Adresse hast, die über das Internet geroutet wird.

Ok, das stimmt.
Bringt ihn aber nicht weiter.

Die entscheidende Information wäre nämlich, ob er evtl. doch DS-lite hat.
Bei einer IP mit 178 am Anfang ist das weniger wahrscheinlich, aber nicht ausgeschlossen.

Der Nummernbereich der verwendeten IPv4 ist so oder so aus dem öffentlichen Bereich und wird dementsprechend auch immer über das Internet geroutet -> Nullinformation.
Die bisher geposteten IPv4-Adressen von DS-lite-Kunden stammten zwar alle oder fast alle aus dem Bereich 37.x.y.z, allerdings bekommen auch IPv4-only-Kunden durchaus IP-Adressen aus diesem Bereich zugewiesen¹, es hat also keine Aussagekraft.
Umgekehrt kann Unitymedia/KBW jederzeit ein AFTR-Gateway mit Adressen aus irgendeinem anderen Bereich füttern oder hat es vielleicht sogar schon getan. Immerhin ist das Thema DS-lite weitgehend durch und wird daher hier erstens weniger und zweitens auf einer völlig anderen Ebene diskutiert als noch vor 1 Jahr, aktuelle "Sammlungen" von IPv4-Adressen von DS-lite-Kunden haben wir also nicht. Also hat auch eine IPv4 != 37.x.y.z keinerlei Aussagekraft mehr.

Die einzige Methode, wie man einen DS-lite-Anschluß zuverlässig erkennen kann, ist und bleibt ein Hinweis auf die Verwendung eines AFTR-Gateways in der Oberfläche des DK7200, des Cisco EPC3208G oder der Fritz!Box 63x0.


¹Meine aktuelle IPv4 z.B.:
Internet, IPv4 verbunden seit 23.06.2014, 09:34 Uhr, Unitymedia, IP-Adresse: 37.201.xxx.230
Und ja, ich wüßte definitiv, wenn das DS-lite wäre

[phil402]

Okay, besten Dank für die Infos.
Ich könnte zwar schwören, dass ich früher Ports getestet habe, ohne das Fenster zu öffnen, aber scheinbar liege ich da falsch oder ich hatte zufällig immer den Dienst am Laufen.

Ich habe kein DS-Lite und nach mehrmaligem resetten des DK7200 können Leute auch wieder durch mein Fenster schauen, wenn ich dem Router sage, dass die Rolladen oben sein sollen. Ich denke, dass die Funktionalität des DMZ-Hosts beeinträchtigt war.
(Die derzeitige Konfiguration überbrückt den DK7200 mit der DMZ-Funktionalität, sodass der TP-Link dahinter für alles weitere zuständig ist)

Nichts desto trotz kommt heute ein Techniker, da irgendetwas mit meinen Modemwerten nicht zu stimmen scheint. (Eigentlich habe ich zu jeder Tageszeit den max. Down und Upstream und einen guten ping). Mal abwarten, was der gute Herr gleich sagt.

Eine Frage an Spacerat noch: Deiner Erklärung nach gehört die Windowsfirewall dann auch zu den unnützten Consumerfirewalls, richtig? Kann ich die ruhigen Gewissens abschalten und den Router die Arbeit machen lassen? (Im Router habe ich eine SPI-Firewall aktiviert)

[tq1199]

Ich könnte zwar schwören, dass ich früher Ports getestet habe, ohne das Fenster zu öffnen, ...

Mit den entsprechenden tools ist das auch möglich. Z. B. mit tcpdump (oder gleichwertig) kann man feststellen ob z. B. eine FB6360 den dort konfigurierten Port 3333 korrekt weiterleitet, obwohl auf dem Port 3333 (... am Gerät hinter der FB6360, wo tcpdump aktiv ist) nicht gelauscht wird. Im Internet sehe ich das aber nicht:
Im Internet:

~ $ sudo nmap -sS 37.###.###.### -p3333,3334

Starting Nmap 6.00 ( http://nmap.org ) at 2014-06-24 12:27 CEST
Nmap scan report for HSI-KBW-37-###-###-###.hsi14.kabel-badenwuerttemberg.de (37.###.###.###)
Host is up (0.021s latency).
PORT STATE SERVICE
3333/tcp filtered dec-notes
3334/tcp filtered directv-web

Gerät hinter der FB6360:

:~$ sudo tcpdump -vvveni any port 3333 or port 3334

12:27:22.259905 In 9c:##:##:##:##:## ethertype IPv4 (0x0800), length 60: (tos 0x3,CE, ttl 57, id 25062, offset 0, flags [none], proto TCP (6), length 44)
46.###.###.###.40697 > 192.168.178.21.3333: Flags [S], cksum 0x75cd (correct), seq 1060094683, win 1024, options [mss 1460], length 0

[phil402]

Okay, dann hatte ich noch weniger Ahnung davon als ich dachte

Nochmal die Frage: Brauche ich die Windows Firewall, wenn im Router SPI-Firewall aktiv ist?

[failure404]

Nochmal die Frage: Brauche ich die Windows Firewall, wenn im Router SPI-Firewall aktiv ist?

Besser ist das.
SPI Firewall = First line of defense
Win Firewall = Second line of defense
Man kann die beiden auch nicht wirklich miteinander vergleichen, da beide völlig unterschiedlich arbeiten.

[magentis]

Nochmal die Frage: Brauche ich die Windows Firewall, wenn im Router SPI-Firewall aktiv ist?

Besser ist das.
SPI Firewall = First line of defense
Win Firewall = Second line of defense
Man kann die beiden auch nicht wirklich miteinander vergleichen, da beide völlig unterschiedlich arbeiten.

Vorallem kann die Windows Firewall auch den I-Net Verkehr nach draussen unterbinden wenn man möchte. Ist zwar auch kein 100%iger Schutz, aber besser als wenn alles ungehindert von drinnen nach draussen kann.

[tq1199]

Nochmal die Frage: Brauche ich die Windows Firewall, wenn im Router SPI-Firewall aktiv ist?

Ich benutze den Paketfilter nur für das (W)LAN, um z. B. den Rechner vor der FritzBox und die FritzBox aus dem bzw. via (W)LAN zu schützen. Z. B. versucht meine FB6360, sporadisch mit der Notfall-IP 169.254.1.1 und dem Port 8181 auf meinen Rechner zuzugreifen. Keine Ahnung warum das so ist:

Code: Alles auswählen

...
13:26:14.695186  In 9c:c#:##:##:##:53 ethertype IPv4 (0x0800), length 68: (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 52)
    169.254.1.1.8181 > 127.0.0.1.56311: Flags [S.], cksum 0x1dc7 (incorrect -> 0x1184), seq 2087414202, ack 1102117100, win 5840, options [mss 1460,nop,nop,sackOK,nop,wscale 4], length 0
13:26:31.328437  In 9c:c#:##:##:##:53 ethertype IPv4 (0x0800), length 68: (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 52)
    169.254.1.1.8181 > 127.0.0.1.56360: Flags [S.], cksum 0x5ce9 (incorrect -> 0x50a6), seq 2357294800, ack 3206946551, win 5840, options [mss 1460,nop,nop,sackOK,nop,wscale 4], length 0
13:29:16.105914  In 9c:c#:##:##:##:53 ethertype IPv4 (0x0800), length 68: (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 52)
    169.254.1.1.8181 > 127.0.0.1.56510: Flags [S.], cksum 0x568f (incorrect -> 0x4a4c), seq 653474412, ack 2774392950, win 5840, options [mss 1460,nop,nop,sackOK,nop,wscale 4], length 0
15:07:02.669128  In 00:00:00:00:00:00 ethertype IPv4 (0x0800), length 78: (tos 0x0, ttl 77, id 30131, offset 0, flags [DF], proto UDP (17), length 62)
    127.0.0.1.8181 > 127.0.0.1.53: [bad udp cksum 0xfe3d -> 0x7e9f!] 57199+ A? forum.kabelbw.de. (34)
15:07:02.669179  In 00:00:00:00:00:00 ethertype IPv4 (0x0800), length 94: (tos 0x0, ttl 64, id 54694, offset 0, flags [none], proto UDP (17), length 78)
    127.0.0.1.53 > 127.0.0.1.8181: [udp sum ok] 57199 q: A? forum.kabelbw.de. 1/0/0 forum.kabelbw.de. [1m] A 82.212.63.100 (50)
15:07:02.669353  In 00:00:00:00:00:00 ethertype IPv4 (0x0800), length 94: (tos 0x0, ttl 77, id 30132, offset 0, flags [DF], proto UDP (17), length 78)
    127.0.0.1.53 > 127.0.0.1.8181: [bad udp cksum 0xfe4d -> 0xaa4e!] 57199 q: A? forum.kabelbw.de. 1/0/0 forum.kabelbw.de. [5m56s] A 82.212.63.100 (50)
15:09:46.633685  In 9c:c#:##:##:##:53 ethertype IPv4 (0x0800), length 68: (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 52)
    169.254.1.1.8181 > 127.0.0.1.34302: Flags [S.], cksum 0x2677 (incorrect -> 0x1a34), seq 718329851, ack 2923281666, win 5840, options [mss 1460,nop,nop,sackOK,nop,wscale 4], length 0
15:09:46.849976  In 9c:c#:##:##:##:53 ethertype IPv4 (0x0800), length 1413: (tos 0x0, ttl 64, id 32200, offset 0, flags [DF], proto TCP (6), length 1397)
    169.254.1.1.8181 > 192.168.178.21.34302: Flags [P.], cksum 0xc3a2 (correct), seq 718332772:718334129, ack 2923282054, win 432, length 1357
15:09:47.267977  In 9c:c#:##:##:##:53 ethertype IPv4 (0x0800), length 1413: (tos 0x0, ttl 64, id 32201, offset 0, flags [DF], proto TCP (6), length 1397)
    169.254.1.1.8181 > 192.168.178.21.34302: Flags [P.], cksum 0xc3a2 (correct), seq 0:1357, ack 1, win 432, length 1357
15:09:48.107792  In 9c:c#:##:##:##:53 ethertype IPv4 (0x0800), length 1413: (tos 0x0, ttl 64, id 32202, offset 0, flags [DF], proto TCP (6), length 1397)
    169.254.1.1.8181 > 192.168.178.21.34302: Flags [P.], cksum 0xc3a2 (correct), seq 0:1357, ack 1, win 432, length 1357
15:09:49.788423  In 9c:c#:##:##:##:53 ethertype IPv4 (0x0800), length 1413: (tos 0x0, ttl 64, id 32203, offset 0, flags [DF], proto TCP (6), length 1397)
    169.254.1.1.8181 > 192.168.178.21.34302: Flags [P.], cksum 0xc3a2 (correct), seq 0:1357, ack 1, win 432, length 1357
15:09:53.147742  In 9c:c#:##:##:##:53 ethertype IPv4 (0x0800), length 1413: (tos 0x0, ttl 64, id 32204, offset 0, flags [DF], proto TCP (6), length 1397)
    169.254.1.1.8181 > 192.168.178.21.34302: Flags [P.], cksum 0xc3a2 (correct), seq 0:1357, ack 1, win 432, length 1357
15:09:59.198478  In 9c:c#:##:##:##:53 ethertype IPv4 (0x0800), length 68: (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 52)
    169.254.1.1.8181 > 127.0.0.1.34322: Flags [S.], cksum 0xb23c (incorrect -> 0xa5f9), seq 921080337, ack 1121834589, win 5840, options [mss 1460,nop,nop,sackOK,nop,wscale 4], length 0
15:09:59.418345  In 9c:c#:##:##:##:53 ethertype IPv4 (0x0800), length 1516: (tos 0x0, ttl 64, id 15675, offset 0, flags [DF], proto TCP (6), length 1500)
    169.254.1.1.8181 > 192.168.178.21.34322: Flags [.], cksum 0x78ab (correct), seq 921081798:921083258, ack 1121834951, win 432, length 1460
15:09:59.838315  In 9c:c#:##:##:##:53 ethertype IPv4 (0x0800), length 1516: (tos 0x0, ttl 64, id 15676, offset 0, flags [DF], proto TCP (6), length 1500)
    169.254.1.1.8181 > 192.168.178.21.34322: Flags [.], cksum 0x78ab (correct), seq 0:1460, ack 1, win 432, length 1460
15:09:59.869596  In 9c:c#:##:##:##:53 ethertype IPv4 (0x0800), length 1413: (tos 0x0, ttl 64, id 32205, offset 0, flags [DF], proto TCP (6), length 1397)
    169.254.1.1.8181 > 192.168.178.21.34302: Flags [P.], cksum 0xc3a2 (correct), seq 0:1357, ack 1, win 432, length 1357
15:10:00.679146  In 9c:c#:##:##:##:53 ethertype IPv4 (0x0800), length 1516: (tos 0x0, ttl 64, id 15677, offset 0, flags [DF], proto TCP (6), length 1500)
    169.254.1.1.8181 > 192.168.178.21.34322: Flags [.], cksum 0x78ab (correct), seq 0:1460, ack 1, win 432, length 1460
15:10:02.358169  In 9c:c#:##:##:##:53 ethertype IPv4 (0x0800), length 1516: (tos 0x0, ttl 64, id 15678, offset 0, flags [DF], proto TCP (6), length 1500)
    169.254.1.1.8181 > 192.168.178.21.34322: Flags [.], cksum 0x78ab (correct), seq 0:1460, ack 1, win 432, length 1460
15:10:05.717800  In 9c:c#:##:##:##:53 ethertype IPv4 (0x0800), length 1516: (tos 0x0, ttl 64, id 15679, offset 0, flags [DF], proto TCP (6), length 1500)
    169.254.1.1.8181 > 192.168.178.21.34322: Flags [.], cksum 0x78ab (correct), seq 0:1460, ack 1, win 432, length 1460
15:10:12.440530  In 9c:c#:##:##:##:53 ethertype IPv4 (0x0800), length 1516: (tos 0x0, ttl 64, id 15680, offset 0, flags [DF], proto TCP (6), length 1500)
    169.254.1.1.8181 > 192.168.178.21.34322: Flags [.], cksum 0x78ab (correct), seq 0:1460, ack 1, win 432, length 1460
15:10:13.309065  In 9c:c#:##:##:##:53 ethertype IPv4 (0x0800), length 1413: (tos 0x0, ttl 64, id 32206, offset 0, flags [DF], proto TCP (6), length 1397)
    169.254.1.1.8181 > 192.168.178.21.34302: Flags [P.], cksum 0xc3a2 (correct), seq 0:1357, ack 1, win 432, length 1357
15:10:25.879117  In 9c:c#:##:##:##:53 ethertype IPv4 (0x0800), length 1516: (tos 0x0, ttl 64, id 15681, offset 0, flags [DF], proto TCP (6), length 1500)
    169.254.1.1.8181 > 192.168.178.21.34322: Flags [.], cksum 0x78ab (correct), seq 0:1460, ack 1, win 432, length 1460
15:10:40.190271  In 9c:c#:##:##:##:53 ethertype IPv4 (0x0800), length 1413: (tos 0x0, ttl 64, id 32207, offset 0, flags [DF], proto TCP (6), length 1397)
    169.254.1.1.8181 > 192.168.178.21.34302: Flags [P.], cksum 0xc3a2 (correct), seq 0:1357, ack 1, win 432, length 1357
15:10:40.503277  In 9c:c#:##:##:##:53 ethertype IPv4 (0x0800), length 68: (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 52)
    169.254.1.1.8181 > 127.0.0.1.34336: Flags [S.], cksum 0x6e60 (incorrect -> 0x621d), seq 1570755660, ack 1650954669, win 5840, options [mss 1460,nop,nop,sackOK,nop,wscale 4], length 0
15:10:40.729071  In 9c:c#:##:##:##:53 ethertype IPv4 (0x0800), length 56: (tos 0x0, ttl 64, id 27402, offset 0, flags [DF], proto TCP (6), length 40)
    169.254.1.1.8181 > 192.168.178.21.34336: Flags [F.], cksum 0xb22f (correct), seq 1570759938, ack 1650955031, win 432, length 0
15:10:41.147866  In 9c:c#:##:##:##:53 ethertype IPv4 (0x0800), length 56: (tos 0x0, ttl 64, id 27403, offset 0, flags [DF], proto TCP (6), length 40)
    169.254.1.1.8181 > 192.168.178.21.34336: Flags [F.], cksum 0xb22f (correct), seq 0, ack 1, win 432, length 0
15:10:41.987881  In 9c:c#:##:##:##:53 ethertype IPv4 (0x0800), length 56: (tos 0x0, ttl 64, id 27404, offset 0, flags [DF], proto TCP (6), length 40)
    169.254.1.1.8181 > 192.168.178.21.34336: Flags [F.], cksum 0xb22f (correct), seq 0, ack 1, win 432, length 0
15:10:43.666929  In 9c:c#:##:##:##:53 ethertype IPv4 (0x0800), length 56: (tos 0x0, ttl 64, id 27405, offset 0, flags [DF], proto TCP (6), length 40)
    169.254.1.1.8181 > 192.168.178.21.34336: Flags [F.], cksum 0xb22f (correct), seq 0, ack 1, win 432, length 0
15:10:45.292026  In 9c:c#:##:##:##:53 ethertype IPv4 (0x0800), length 68: (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 52)
    169.254.1.1.8181 > 127.0.0.1.34348: Flags [S.], cksum 0x18e2 (incorrect -> 0x0c9f), seq 1645834109, ack 311007059, win 5840, options [mss 1460,nop,nop,sackOK,nop,wscale 4], length 0
15:10:45.507776  In 9c:c#:##:##:##:53 ethertype IPv4 (0x0800), length 1516: (tos 0x0, ttl 64, id 44636, offset 0, flags [DF], proto TCP (6), length 1500)
    169.254.1.1.8181 > 192.168.178.21.34348: Flags [.], cksum 0xdf50 (correct), seq 1645835570:1645837030, ack 311007421, win 432, length 1460
15:10:45.928551  In 9c:c#:##:##:##:53 ethertype IPv4 (0x0800), length 1516: (tos 0x0, ttl 64, id 44637, offset 0, flags [DF], proto TCP (6), length 1500)
    169.254.1.1.8181 > 192.168.178.21.34348: Flags [.], cksum 0xdf50 (correct), seq 0:1460, ack 1, win 432, length 1460
15:10:46.768380  In 9c:c#:##:##:##:53 ethertype IPv4 (0x0800), length 1516: (tos 0x0, ttl 64, id 44638, offset 0, flags [DF], proto TCP (6), length 1500)
    169.254.1.1.8181 > 192.168.178.21.34348: Flags [.], cksum 0xdf50 (correct), seq 0:1460, ack 1, win 432, length 1460
15:10:47.027392  In 9c:c#:##:##:##:53 ethertype IPv4 (0x0800), length 56: (tos 0x0, ttl 64, id 27406, offset 0, flags [DF], proto TCP (6), length 40)
    169.254.1.1.8181 > 192.168.178.21.34336: Flags [F.], cksum 0xb22f (correct), seq 0, ack 1, win 432, length 0
15:10:48.448250  In 9c:c#:##:##:##:53 ethertype IPv4 (0x0800), length 1516: (tos 0x0, ttl 64, id 44639, offset 0, flags [DF], proto TCP (6), length 1500)
    169.254.1.1.8181 > 192.168.178.21.34348: Flags [.], cksum 0xdf50 (correct), seq 0:1460, ack 1, win 432, length 1460
15:10:51.809242  In 9c:c#:##:##:##:53 ethertype IPv4 (0x0800), length 1516: (tos 0x0, ttl 64, id 44640, offset 0, flags [DF], proto TCP (6), length 1500)
    169.254.1.1.8181 > 192.168.178.21.34348: Flags [.], cksum 0xdf50 (correct), seq 0:1460, ack 1, win 432, length 1460
15:10:52.757870  In 9c:c#:##:##:##:53 ethertype IPv4 (0x0800), length 1516: (tos 0x0, ttl 64, id 15682, offset 0, flags [DF], proto TCP (6), length 1500)
    169.254.1.1.8181 > 192.168.178.21.34322: Flags [.], cksum 0x78ab (correct), seq 0:1460, ack 1, win 432, length 1460
15:10:53.747382  In 9c:c#:##:##:##:53 ethertype IPv4 (0x0800), length 56: (tos 0x0, ttl 64, id 27407, offset 0, flags [DF], proto TCP (6), length 40)
    169.254.1.1.8181 > 192.168.178.21.34336: Flags [F.], cksum 0xb22f (correct), seq 0, ack 1, win 432, length 0
15:10:58.531243  In 9c:c#:##:##:##:53 ethertype IPv4 (0x0800), length 1516: (tos 0x0, ttl 64, id 44641, offset 0, flags [DF], proto TCP (6), length 1500)
    169.254.1.1.8181 > 192.168.178.21.34348: Flags [.], cksum 0xdf50 (correct), seq 0:1460, ack 1, win 432, length 1460
15:11:05.598760  In 9c:c#:##:##:##:53 ethertype IPv4 (0x0800), length 68: (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 52)
    169.254.1.1.8181 > 127.0.0.1.34365: Flags [S.], cksum 0x9825 (incorrect -> 0x8be2), seq 1961667940, ack 577222502, win 5840, options [mss 1460,nop,nop,sackOK,nop,wscale 4], length 0
15:11:07.193288  In 9c:c#:##:##:##:53 ethertype IPv4 (0x0800), length 56: (tos 0x0, ttl 64, id 27408, offset 0, flags [DF], proto TCP (6), length 40)
    169.254.1.1.8181 > 192.168.178.21.34336: Flags [F.], cksum 0xb22f (correct), seq 0, ack 1, win 432, length 0
15:11:11.969374  In 9c:c#:##:##:##:53 ethertype IPv4 (0x0800), length 1516: (tos 0x0, ttl 64, id 44642, offset 0, flags [DF], proto TCP (6), length 1500)
    169.254.1.1.8181 > 192.168.178.21.34348: Flags [.], cksum 0xdf50 (correct), seq 0:1460, ack 1, win 432, length 1460
15:11:13.637075  In 9c:c#:##:##:##:53 ethertype IPv4 (0x0800), length 68: (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 52)
    169.254.1.1.8181 > 127.0.0.1.34381: Flags [S.], cksum 0x88cf (incorrect -> 0x7c8c), seq 2080486648, ack 3192003624, win 5840, options [mss 1460,nop,nop,sackOK,nop,wscale 4], length 0
15:11:13.848121  In 9c:c#:##:##:##:53 ethertype IPv4 (0x0800), length 1516: (tos 0x0, ttl 64, id 30920, offset 0, flags [DF], proto TCP (6), length 1500)
    169.254.1.1.8181 > 192.168.178.21.34381: Flags [.], cksum 0x4f3e (correct), seq 2080488109:2080489569, ack 3192003986, win 432, length 1460
15:11:14.268812  In 9c:c#:##:##:##:53 ethertype IPv4 (0x0800), length 1516: (tos 0x0, ttl 64, id 30921, offset 0, flags [DF], proto TCP (6), length 1500)
    169.254.1.1.8181 > 192.168.178.21.34381: Flags [.], cksum 0x4f3e (correct), seq 0:1460, ack 1, win 432, length 1460
15:11:15.110595  In 9c:c#:##:##:##:53 ethertype IPv4 (0x0800), length 1516: (tos 0x0, ttl 64, id 30922, offset 0, flags [DF], proto TCP (6), length 1500)
    169.254.1.1.8181 > 192.168.178.21.34381: Flags [.], cksum 0x4f3e (correct), seq 0:1460, ack 1, win 432, length 1460
15:11:16.787787  In 9c:c#:##:##:##:53 ethertype IPv4 (0x0800), length 1516: (tos 0x0, ttl 64, id 30923, offset 0, flags [DF], proto TCP (6), length 1500)
    169.254.1.1.8181 > 192.168.178.21.34381: Flags [.], cksum 0x4f3e (correct), seq 0:1460, ack 1, win 432, length 1460
15:11:20.150693  In 9c:c#:##:##:##:53 ethertype IPv4 (0x0800), length 1516: (tos 0x0, ttl 64, id 30924, offset 0, flags [DF], proto TCP (6), length 1500)
    169.254.1.1.8181 > 192.168.178.21.34381: Flags [.], cksum 0x4f3e (correct), seq 0:1460, ack 1, win 432, length 1460
15:11:26.869144  In 9c:c#:##:##:##:53 ethertype IPv4 (0x0800), length 1516: (tos 0x0, ttl 64, id 30925, offset 0, flags [DF], proto TCP (6), length 1500)
    169.254.1.1.8181 > 192.168.178.21.34381: Flags [.], cksum 0x4f3e (correct), seq 0:1460, ack 1, win 432, length 1460
15:11:34.067444  In 9c:c#:##:##:##:53 ethertype IPv4 (0x0800), length 56: (tos 0x0, ttl 64, id 27409, offset 0, flags [DF], proto TCP (6), length 40)
    169.254.1.1.8181 > 192.168.178.21.34336: Flags [F.], cksum 0xb22f (correct), seq 0, ack 1, win 432, length 0
15:11:38.847858  In 9c:c#:##:##:##:53 ethertype IPv4 (0x0800), length 1516: (tos 0x0, ttl 64, id 44643, offset 0, flags [DF], proto TCP (6), length 1500)
    169.254.1.1.8181 > 192.168.178.21.34348: Flags [.], cksum 0xdf50 (correct), seq 0:1460, ack 1, win 432, length 1460
15:11:40.311270  In 9c:c#:##:##:##:53 ethertype IPv4 (0x0800), length 1516: (tos 0x0, ttl 64, id 30926, offset 0, flags [DF], proto TCP (6), length 1500)
    169.254.1.1.8181 > 192.168.178.21.34381: Flags [.], cksum 0x4f3e (correct), seq 0:1460, ack 1, win 432, length 1460
15:12:07.188105  In 9c:c#:##:##:##:53 ethertype IPv4 (0x0800), length 1516: (tos 0x0, ttl 64, id 30927, offset 0, flags [DF], proto TCP (6), length 1500)
    169.254.1.1.8181 > 192.168.178.21.34381: Flags [.], cksum 0x4f3e (correct), seq 0:1460, ack 1, win 432, length 1460
...

[SpaceRat]

Eine Frage an Spacerat noch: Deiner Erklärung nach gehört die Windowsfirewall dann auch zu den unnützten Consumerfirewalls, richtig? Kann ich die ruhigen Gewissens abschalten und den Router die Arbeit machen lassen? (Im Router habe ich eine SPI-Firewall aktiviert)

Ich würde sie anlassen.

Wenn irgendwann doch mal etwas passiert, dann schützt Dich eine aktuelle Firewall und ein aktueller Virenscanner zumindest vor deutschen Amtsrichterlein, die ihr Computer-Fachwissen aus der Computer BLÖD beziehen und dem Benutzer abverlangen, eine "aktuelle Firewall und einen aktuellen Virenscanner" zu benutzen.

[SpaceRat]

Vorallem kann die Windows Firewall auch den I-Net Verkehr nach draussen unterbinden wenn man möchte. Ist zwar auch kein 100%iger Schutz, aber besser als wenn alles ungehindert von drinnen nach draussen kann.

Es ist so gesehen gar kein Schutz oder sogar ein Schaden.

Erstens fragt die Windows-Firewall bei der Benutzung eines Programms, welches auf das Internet zugreift, einfach nur den Benutzer, ob dieses Programm das dürfen soll oder nicht, was der Benutzer immer dann zulassen wird, wenn er das Programm absichtlich gestartet hat und mit einer Internet-Nutzung rechnet.
So dumme Schadsoftware-Programmierer kann es aber gar nicht geben, daß diese ihren Schadcode in anderen als solchen Programmen verstecken würden.

Perfekt für diesen Zweck geeignet sind "Nachlade-Installer", die sich einem in Massen beim Suchen im Netz aufdrängen, egal wonach man sucht:
Im ersten Schritt erlaubt der Benutzer dem Programm, das zu installierende Programm (eigentlich die Backdoor) aus dem Netz nachzuladen und im zweiten gibt er über die UAC dem vorgeblichen Installationsprogramm Administratorenrechte für die Installation (Eigentlich zum weiteren Durchlöchern der Firewall und dem Installieren des Schadcodes).

Zweitens ist es für eine Schadsoftware meistens gar nicht nötig die Windows-Firewall zu ändern, da bestimmte Komponenten per default mit der Außenwelt kommunizieren dürfen und diese Komponenten für alle bösartigen Zwecke mehr als ausreichend sind.

Soweit zum fehlenden Schutz.

Nun zum Schaden:
Vor beiden Fällen kann einen keine Personal Firewall der Welt schützen, sondern nur Brain 1.0.
Mit installiertem und aktivem Brain 1.0 würde man überhaupt keine Software auf dem PC ausführen der man nicht vertraut, anstatt sich darauf zu verlassen, daß ein Trojaner brav anfragen wird, ob er auf's Internet zugreifen darf.
Das Hauptfeature von "Personal Firewall"- und Antivirus-"Lösungen" ist es aber, die Warnschwelle von brain 1.0 herabzusetzen ("Ich bin ja geschützt.").

Der nicht vorhandene Schutz durch eine PFW, kombiniert mit der zumindest teilweisen Deaktivierung des vorhandenen Schutzes durch Brain 1.0, bedingt zwingend eine Schadwirkung solcher Software, da das Schutzniveau immer unterhalb dessen von Brain 1.0 liegt.

Richtige (externe) Firewalls, möglichst mit DPI (Deep Packet Inspection), sind etwas völlig anderes:
Da sie auf einem anderen Gerät laufen, sind sie immun gegen die Kompromittierung des zu schützenden Gerätes. Selbst wenn der Benutzer es dem Programm "Botnet-Client" erlaubt, die Firewall zu öffnen und sich mit Adminrechten zu installieren (Was er tun wird, da sich das Programm nicht "Botnet-Client" sondern z.B. "Firefox-Slim-Installer" nennen wird), kann eine solche externe Firewall einen Schutz bieten, da es durch DPI z.B. IRC-Traffic (Der einigen Botnet-Clients zugrunde liegt) erkennen und filtern kann.
Aber selbst dieser Schutz läuft ins Leere, wenn der Benutzer auch regulär IRC benutzen möchte, das ist ja nicht per se böse. Dann wird er nämlich der externen Firewall sagen müssen, daß diese IRC-Traffic nicht filtern darf.

Dort, wo effektiver Schutz allein durch technische Ausrüstung erreicht werden muß (z.B. in Firmennetzen), ist diese Ausrüstung auch immer denkbar restriktiv eingestellt und nicht durch den Benutzer beeinflußbar.

[SpaceRat]

Nur zur Klarstellung:

Meine obige Erläuterung der technischen Fakten stellt keinen Appell dar, die Windows-Firewall und/oder Windows Security Essentials o.ä. zu deaktivieren.

Es ist zwar eine Tatsache, daß beide - genauso wie auch jede käuflich zu erwerbende "Security-Suite" - keinerlei technische Schutzwirkung haben, sie haben aber wohl eine juristische.

Vgl. Landgericht Köln, Az.: 9 S 195/07:
...
Da die Parteien nicht vertraglich verbunden sind, galt für den Kläger nur die allgemeine Pflicht, diejenige Sorgfalt anzuwenden, die von einem verständigen Menschen erwartet werden kann, um sich vor Schaden zu schützen.
[Anm. von mir: Die Richter sahen dabei Ihr offenkundig aus der Computer BLÖD stammendes "Wissen" als Maßstab an.]
...
Für den konkreten Fall des Online-Bankings kann man von einem verständigen, technisch durchschnittlich begabten Anwender fordern, dass er eine aktuelle Virenschutzsoftware und eine Firewall verwendet und regelmäßig Sicherheitsupdates für sein Betriebssystem und die verwendete Software einspielt.

Das BSI (Bundesamt für Sicherheit in der Informationstechnik) hat übrigens in diesem Zusammenhang auch seine Warnung vor Personal Firewalls relativiert:
Über Sinn und Unsinn von Personal Firewalls streiten sich die Fachleute noch immer. Denn Desktop Firewalls – wie sie auch genannt werden – sind, wenn man sich an die wichtigsten Grundregeln zum sicheren Surfen hält, fast überflüssig. Wichtig ist, dass das Betriebssystem, der Browser, der E-Mail-Client und die Anwendungen so sicher wie möglich konfiguriert sind. Solange das der Fall ist, Sie nichts aus unsicheren Quellen herunterladen und auch sonst vorsichtig im Internet unterwegs sind, stellt eine Personal Firewall nicht unbedingt einen zusätzlichen Schutz dar.

Generell gilt: IT-Sicherheit kann nicht durch eine einzelne Software erreicht werden, sondern ist immer nur durch ein Zusammenspiel von verschiedenen Faktoren möglich.

Gegenüber früheren Fassungen wurden sinngemäß inhaltlich der erste Satz "Über Sinn und Unsinn von Personal Firewalls streiten sich die Fachleute noch immer." und das Wort "fast" vor überflüssig ergänzt sowie "keinen Schutz" durch "nicht unbedingt einen zusätzlichen Schutz" ersetzt sowie die Passage zur zusätzlichen Gefährdung durch trügerische Sicherheit gestrichen.

Nach wie vor wird ersichtlich, daß von Personal Firewalls nicht viel zu halten ist, jedoch wurde die kategorische Ablehnung aufgeweicht, denn wenn sich ein Richterlein lieber auf sein eigenes Unwissen beruft als der Beurteilung durch das BSI zu folgen, kann man als Kläger oder Beklagter nicht viel dagegen tun.

[magentis]

@ SpaceRat

Sicherlich werd ich dir mit Brain 1.0 nicht widersprechen. Trotzdem ist es praktisch, wenn so manches Programm eine eigen Anfrage startet um ins Netz zu kommen. Und damit Jan, Mann und Co nicht einfach eine Info bekommen, kann eine Personal Firewall schon einiges verhindern. Natürlich alles unter dem Gesichtspunkt, 100%igen Schutz gibt es nicht, vorallem als Privatanwender (bessere Systheme zu kostspielig) und man wird auf einer Art ja durch den Gesetzgeber dazu gezwungen, wie schon von dir aufgeführt.