• Kunden aus Hessen und Nordrhein-Westfalen können über die Rufnummer 0221 / 466 191 00 Hilfe bei allen Problemen in Anspruch nehmen.
    Kunden aus Baden-Württemberg können über die Rufnummer 0711 / 54 888 150 Hilfe bei allen Problemen in Anspruch nehmen.

Unitymedia Seit neuem keine Portfreigabe mehr möglich.

Diskutiere Seit neuem keine Portfreigabe mehr möglich. im Internet und Telefon über das TV-Kabelnetz Forum im Bereich Internet und Telefon; Hallo, kurz zu meiner Situation: -Nov. 2013 auf 100Mbit gewechselt. Bin aber schon langjähriger Kunde und wurde von DS Lite verschont. Ich hatte...
  • Seit neuem keine Portfreigabe mehr möglich. Beitrag #1

phil402

Beiträge
23
Punkte Reaktionen
0
Hallo,

kurz zu meiner Situation:

-Nov. 2013 auf 100Mbit gewechselt. Bin aber schon langjähriger Kunde und wurde von DS Lite verschont. Ich hatte damals also keine ipv6 Adresse und konnte daher ipv4 Portfreigaben realisieren.
-Ich habe im TC7200 (/DK7200) [192.168.0.1] den DHCP deaktiviert und den DMZ Host auf 192.168.0.2 eingestellt. In meinem TP-Link Router ist eine Static-Ip [192.168.0.2] mit dem Gateway 192.168.0.1 eingestellt. Das hat auch bisher so funktioniert. Die Portfreigaben konnte ich dann ganz normal im TP-Link Router durchführen.

Gestern ist mir aufgefallen, dass keine meiner Portweiterleitungen mehr funktioniert. Erster Schock "Die Schweine haben mir doch etwa nicht über Nacht DS-Lite geschaltet?". Im DK7200 wird mir nur eine ipv4 Adresse, keine IPv6 Adresse angezeigt. Auch diverse Website-Tests bestätigen mir, dass ich keine ipv6 Adresse habe (auch ohne meinen Router dazwischen).

Habe dann meinen Router abgeklemmt und meinem PC die Static IP [192.168.0.2] gegeben. obwohl ich ja jetzt als DMZ gelte, kann ich keine Ports freischalten. Firewalls sind alle aus. Auch eine manuelle Freigabe der Ports im DK7200 brachte keinen Erfolg.

Habe ich etwas verpasst? Ist das Drecknikotzlor jetzt völlig durch? Bitte um Ratschläge

Vielen Dank!
 
  • Seit neuem keine Portfreigabe mehr möglich. Beitrag #2
Hey,

sry, dass ich das Thema nochmal pushe. Aber weiß jemand inzwischen vllt. etwas neues dazu?

Ich kann einfach keine Ports mehr freischalten. Hat Unitymedia jetzt die DMZ FUnktion im TC7200 geblockt?
 
  • Seit neuem keine Portfreigabe mehr möglich. Beitrag #3
Gestern ist mir aufgefallen, dass keine meiner Portweiterleitungen mehr funktioniert.... Im DK7200 wird mir nur eine ipv4 Adresse, ...
Wie sind die ersten 3 Zeichen der IPv4-Adresse aus dem TC7200?
 
  • Seit neuem keine Portfreigabe mehr möglich. Beitrag #4
Die Ip Adresse lautet:

178.202.xxx.xx

Sagt das irgendwas aus?

Die IP Adresse meines Bruders (er Düsseldorf und ich Duisburg) lautet

178.201.xxx.xxx

Und er kann weiterhin Ports nach belieben freigeben.

edit: habe gerade mit der Hotline gesprochen (der Herr war auch etwas jünger) und mir wurde gesagt, dass ich eine Fritbox (Telefonkomfort für 5€ im Monat) brauche weil der TC7200 scheiße ist.

ICH glaube, dass Unitymedia im TC7200 die Portweiterleitung und die DMZ Funktion nutzlos gemacht hat (ähnlich die "Bridge" Funktion). Wenn ich das auf die Spitze treiben will, dann haben die das gemacht, weil die wollen, dass ich die 5€ monatlich zahle.

Der Herr hat mir auch besätigt, dass ich kein DS Lite oder ähnliches habe, sondern meine ganz eigene ipv4.

edit2: ein 2. Herr an der Service Hotline hat jetzt eine Störungsmeldung aufgenommen, nachdem ein kompletter Reset keine Besserung gebracht hat. Ich erwarte nicht all zu viel. Aber immerhin hat er das Problem verstanden und nicht versucht mir eine Fritzbox zu verkaufen.
 
  • Seit neuem keine Portfreigabe mehr möglich. Beitrag #5
Die IP Adresse meines Bruders (er Düsseldorf und ich Duisburg) lautet
178.201.xxx.xxx
Und er kann weiterhin Ports nach belieben freigeben.
Welche Hardware (KabelGateway, KabelModem, Router, ...) hat dein Bruder, von Unitymedia?
Gestern ist mir aufgefallen, dass keine meiner Portweiterleitungen mehr funktioniert.
Benutzt Du zum testen deiner Portweiterleitungen, evtl. auch die Dienste/Einrichtungen eins ddns-Providers?
 
  • Seit neuem keine Portfreigabe mehr möglich. Beitrag #6
Hey,

mein Bruder hat mit seiner 32Mbit Leitung noch das alte Motorola Modem (dahinter einen billigen Netgear Router).

Zum Testen der Weiterleitung nutze ich momentan online-tools wie zB canyouseemee.org zb.


edit: Eine Kabelfirma hat mich gerade kontaktiert und heute oder morgen kommt ein Techniker. Ich weiß zwar nicht, wie der Techniker das beheben will aber wenn ich glück habe, hat er vor das Drecknikotzlor zu verbrennen und mir kostenlos eine Fritzbox zu überlassen :lovingeyes:
 
  • Seit neuem keine Portfreigabe mehr möglich. Beitrag #7
Träum weiter.
 
  • Seit neuem keine Portfreigabe mehr möglich. Beitrag #8

Mach mir ruhig meine Träume kaputt. Danke!

Irgendwie, habe ich es mittlerweile geschafft, das ich gewisse Ports freischalten kann.
Also zB bin ich in einem Spiel, in dass sich andere Spieler direkt über meine IP einklinken können. Dabei wird der Port 7777 genutzt.
Gestern konnte sich keiner mit mir verbinden.
Heute können sich die Leute einklinken und solange ich das Spiel hoste, wird der Port als offen erkannt.

Ich GLAUBE, dass vorher irgendwie der nicht genutzt Tunngle Netzwerk-Adapter die Connection verhindert hat. Seit dem ich diesen aktiviert habe, können die Leute connecten.

Jemand eine Idee, warum die Ports nur offen sind, wenn ein Service sie nutzt und ein PortCheck immer als closed erkannt wird?
 
  • Seit neuem keine Portfreigabe mehr möglich. Beitrag #9
..., warum die Ports nur offen sind, wenn ein Service sie nutzt und ein PortCheck immer als closed erkannt wird?
Die Ports sind dann offen, wenn an diesen Ports gelauscht wird. Siehe z. B. auch: http://wiki.ubuntuusers.de/Offene_Ports
 
  • Seit neuem keine Portfreigabe mehr möglich. Beitrag #10
Jemand eine Idee, warum die Ports nur offen sind, wenn ein Service sie nutzt und ein PortCheck immer als closed erkannt wird?
Ja:
Wo nichts ist, kann man auch nichts finden.

Stelle Dir laufende Dienste einfach als Fenster vor und in der (Router-)Firewall geöffnete Ports als hochgezogene Rollade davor.
Wenn Du das Fenster zumauerst (Den Dienst schließt) dann kannst Du auch dann nicht durch's nicht mehr vorhandene Fenster gucken, wenn die Rollade geöffnet ist.

Sobald Du das verstanden hast, hast Du auch kapiert, wieso Personal Firewalls die nutzlosesten Programme auf Gottes weitem Planeten sind:
Kein Mensch würde eine Rollade, geschweige denn zwei hintereinander, vor eine Hauswand montieren, sondern nur je eine und das auch nur vor den Fenstern. Die "Personal Firewall" (Die auf dem PC) ist aber genau das, die zweite Rollade (Zusätzlich zu der im Router) vor einer Hauswand (Kein Dienst = kein Fenster).

Deshalb sind erfahrene Benutzer ja auch immer so begeistert, wenn sie beim Internet-Anbieterwechsel immer eine Zwangs-Rollade zu 4 EUR/mtl. auf's Auge gedrückt bekommen, die sie erst separat kündigen müssen.
Wenigstens diese Abzocke hat Unitymedia aber zwischenzeitlich eingestellt, inzwischen darf man den Softwaremüll direkt bei der Bestellung abwählen.
 
  • Seit neuem keine Portfreigabe mehr möglich. Beitrag #12
  • Seit neuem keine Portfreigabe mehr möglich. Beitrag #13
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 :)
 
  • Seit neuem keine Portfreigabe mehr möglich. Beitrag #14
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)
 
  • Seit neuem keine Portfreigabe mehr möglich. Beitrag #15
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
 
  • Seit neuem keine Portfreigabe mehr möglich. Beitrag #16
Okay, dann hatte ich noch weniger Ahnung davon als ich dachte :D

Nochmal die Frage: Brauche ich die Windows Firewall, wenn im Router SPI-Firewall aktiv ist?
 
  • Seit neuem keine Portfreigabe mehr möglich. Beitrag #17
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.
 
  • Seit neuem keine Portfreigabe mehr möglich. Beitrag #18
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.
 
  • Seit neuem keine Portfreigabe mehr möglich. Beitrag #19
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:
<i>
</i>...
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
...
 
  • Seit neuem keine Portfreigabe mehr möglich. Beitrag #20
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.
 
  • Seit neuem keine Portfreigabe mehr möglich. Beitrag #21
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 .
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.
 
  • Seit neuem keine Portfreigabe mehr möglich. Beitrag #22
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 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.
 
  • Seit neuem keine Portfreigabe mehr möglich. Beitrag #23
@ 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.
 
Thema:

Seit neuem keine Portfreigabe mehr möglich.

Seit neuem keine Portfreigabe mehr möglich. - Ähnliche Themen

Unitymedia manche Websiten lassen sich nicht laden: Hallo zusammen, ich habe seit einiger Zeit ein Problem, das mindestens alle 2-3 Tage auftaucht. Dabei sind manche Websiten plötzlich nicht mehr...
Unitymedia Connect Box ohne Bridge-Funktion als (Beinahe-)Bridge: Es gibt ja Gerüchte, dass bei der Connect Box demnächst die Bridge-Funktion freigeschaltet werden soll. Bis das soweit ist, oder falls das doch...
Unitymedia WLAN Probleme mit der Connect-Box: Hallo Leute, ich brauche Eure Hilfe, denn ich weiß nicht mehr weiter. Unitymedia ignoriert meine Anfragen auch komplett oder kann mir nicht...
Unitymedia IPv6 Freigabe Fritzbox 07.02: Hallo zusammen, ich habe in den letzten Stunden schon diverse Posts und hilfreiche Themen hier im Forum gelesen, finde aber keine Lösung. Ich...
Unitymedia FAQ: Neuer Tarif Vodafone CableMax 1000 (Zusammenfassung Thread "Neuer Tarif ab 17.02 Vodafone GigaCable MAX"): Hallo Gemeinde, basierend auf den nun mehr als 70 Seiten im Vodafone CableMax 1000 Thread habe ich mit Hilfe anderer User hier ein FAQ erstellt...
Oben