Seit neuem keine Portfreigabe mehr möglich.

In vielen Netzen von Unitymedia sind Internet und Telefonie bereits verfügbar.
Forumsregeln
  • 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.
Antworten
phil402
Kabelneuling
Beiträge: 23
Registriert: 27.10.2011, 21:58

Seit neuem keine Portfreigabe mehr möglich.

Beitrag von phil402 » 20.05.2014, 11:29

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!

phil402
Kabelneuling
Beiträge: 23
Registriert: 27.10.2011, 21:58

Re: Seit neuem keine Portfreigabe mehr möglich.

Beitrag von phil402 » 22.06.2014, 13:19

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?

tq1199
Glasfaserstrecke
Beiträge: 1486
Registriert: 07.02.2014, 09:05

Re: Seit neuem keine Portfreigabe mehr möglich.

Beitrag von tq1199 » 23.06.2014, 09:27

phil402 hat geschrieben: 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?
Office Internet & Phone 50, AVM FRITZ!Box 6360 Cable (kbw) - FRITZ!OS 06.52 - , an Arris-CMTS, zusätzlich eine feste (statische, nicht per DHCP) IPv4-Adresse für meinen Server, am Bridge-Anschluss (kein Bridge-Modus, FB6360-cable wird ohne feste IPv4-Adresse als Router verwendet.)
Konfigurationsdatei der FritzBox: b2b-staticip1_50000_5000_ipv4_sip_wifi-on.bin
NTP_Provider_Interface_Spec_Unitymedia

AVM - IPv6 technical note

phil402
Kabelneuling
Beiträge: 23
Registriert: 27.10.2011, 21:58

Re: Seit neuem keine Portfreigabe mehr möglich.

Beitrag von phil402 » 23.06.2014, 10:58

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.

tq1199
Glasfaserstrecke
Beiträge: 1486
Registriert: 07.02.2014, 09:05

Re: Seit neuem keine Portfreigabe mehr möglich.

Beitrag von tq1199 » 23.06.2014, 13:03

phil402 hat geschrieben: 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?
phil402 hat geschrieben: Gestern ist mir aufgefallen, dass keine meiner Portweiterleitungen mehr funktioniert.
Benutzt Du zum testen deiner Portweiterleitungen, evtl. auch die Dienste/Einrichtungen eins ddns-Providers?
Office Internet & Phone 50, AVM FRITZ!Box 6360 Cable (kbw) - FRITZ!OS 06.52 - , an Arris-CMTS, zusätzlich eine feste (statische, nicht per DHCP) IPv4-Adresse für meinen Server, am Bridge-Anschluss (kein Bridge-Modus, FB6360-cable wird ohne feste IPv4-Adresse als Router verwendet.)
Konfigurationsdatei der FritzBox: b2b-staticip1_50000_5000_ipv4_sip_wifi-on.bin
NTP_Provider_Interface_Spec_Unitymedia

AVM - IPv6 technical note

phil402
Kabelneuling
Beiträge: 23
Registriert: 27.10.2011, 21:58

Re: Seit neuem keine Portfreigabe mehr möglich.

Beitrag von phil402 » 23.06.2014, 15:33

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:

Knifte
Glasfaserstrecke
Beiträge: 2464
Registriert: 18.04.2009, 21:19
Wohnort: Kreis Kleve

Re: Seit neuem keine Portfreigabe mehr möglich.

Beitrag von Knifte » 23.06.2014, 16:20

Träum weiter.
Viele Grüße

Knifte
jetzt:Bildvorher:Bild
UM 2play Premium 150.000 mit dem Cisco EPC 3208-Modem - ASUS RT-AC66U-Router - FritzBox 7490 - FritzFon C4

phil402
Kabelneuling
Beiträge: 23
Registriert: 27.10.2011, 21:58

Re: Seit neuem keine Portfreigabe mehr möglich.

Beitrag von phil402 » 23.06.2014, 18:14

Knifte hat geschrieben:Träum weiter.
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?

tq1199
Glasfaserstrecke
Beiträge: 1486
Registriert: 07.02.2014, 09:05

Re: Seit neuem keine Portfreigabe mehr möglich.

Beitrag von tq1199 » 23.06.2014, 23:53

phil402 hat geschrieben: ..., 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
Office Internet & Phone 50, AVM FRITZ!Box 6360 Cable (kbw) - FRITZ!OS 06.52 - , an Arris-CMTS, zusätzlich eine feste (statische, nicht per DHCP) IPv4-Adresse für meinen Server, am Bridge-Anschluss (kein Bridge-Modus, FB6360-cable wird ohne feste IPv4-Adresse als Router verwendet.)
Konfigurationsdatei der FritzBox: b2b-staticip1_50000_5000_ipv4_sip_wifi-on.bin
NTP_Provider_Interface_Spec_Unitymedia

AVM - IPv6 technical note

Benutzeravatar
SpaceRat
Glasfaserstrecke
Beiträge: 2466
Registriert: 08.05.2010, 01:30
Wohnort: Kreis Aachen
Kontaktdaten:

Re: Seit neuem keine Portfreigabe mehr möglich.

Beitrag von SpaceRat » 24.06.2014, 01:49

phil402 hat geschrieben: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.

Benutzeravatar
SpaceRat
Glasfaserstrecke
Beiträge: 2466
Registriert: 08.05.2010, 01:30
Wohnort: Kreis Aachen
Kontaktdaten:

Re: Seit neuem keine Portfreigabe mehr möglich.

Beitrag von SpaceRat » 24.06.2014, 01:51

phil402 hat geschrieben:
tq1199 hat geschrieben:Wie sind die ersten 3 Zeichen der IPv4-Adresse aus dem TC7200?
Sagt das irgendwas aus?
Nicht das Geringste.
Zuletzt geändert von SpaceRat am 24.06.2014, 09:25, insgesamt 1-mal geändert.

tq1199
Glasfaserstrecke
Beiträge: 1486
Registriert: 07.02.2014, 09:05

Re: Seit neuem keine Portfreigabe mehr möglich.

Beitrag von tq1199 » 24.06.2014, 09:08

phil402 hat geschrieben: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.
Office Internet & Phone 50, AVM FRITZ!Box 6360 Cable (kbw) - FRITZ!OS 06.52 - , an Arris-CMTS, zusätzlich eine feste (statische, nicht per DHCP) IPv4-Adresse für meinen Server, am Bridge-Anschluss (kein Bridge-Modus, FB6360-cable wird ohne feste IPv4-Adresse als Router verwendet.)
Konfigurationsdatei der FritzBox: b2b-staticip1_50000_5000_ipv4_sip_wifi-on.bin
NTP_Provider_Interface_Spec_Unitymedia

AVM - IPv6 technical note

Benutzeravatar
SpaceRat
Glasfaserstrecke
Beiträge: 2466
Registriert: 08.05.2010, 01:30
Wohnort: Kreis Aachen
Kontaktdaten:

Re: Seit neuem keine Portfreigabe mehr möglich.

Beitrag von SpaceRat » 24.06.2014, 09:24

tq1199 hat geschrieben:
phil402 hat geschrieben: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 :)
Receiver/TV:
  • Vu+ Duo² 4xS2+2xC / OpenATV 6.1@Samsung 50" Plasma
  • AX Quadbox HD2400 2xS2+2xC / OpenATV 6.1@Samsung 32" TFT
  • 2xVu+ Solo² / OpenATV 6.1
  • DVBSky S2-Twin PCIe@SyncMaster T240HD (PC)
  • TechniSat SkyStar HD2@17" (2.PC)
Pay-TV: Schwarzfunk, Redlight Elite Superchic, SCT 10, HD-, Sky
Fon: VF Komfort-Classic (ISDN), 2xFritz!Fon C4+Siedle DoorCom Analog@F!B 7390
Internet: UM 1play 100 / Cisco EPC3212+Linksys WRT1900ACS / IPv4 (UM) + IPv6 (HE)
Bild

phil402
Kabelneuling
Beiträge: 23
Registriert: 27.10.2011, 21:58

Re: Seit neuem keine Portfreigabe mehr möglich.

Beitrag von phil402 » 24.06.2014, 12:10

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
Glasfaserstrecke
Beiträge: 1486
Registriert: 07.02.2014, 09:05

Re: Seit neuem keine Portfreigabe mehr möglich.

Beitrag von tq1199 » 24.06.2014, 12:46

phil402 hat geschrieben: 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
Office Internet & Phone 50, AVM FRITZ!Box 6360 Cable (kbw) - FRITZ!OS 06.52 - , an Arris-CMTS, zusätzlich eine feste (statische, nicht per DHCP) IPv4-Adresse für meinen Server, am Bridge-Anschluss (kein Bridge-Modus, FB6360-cable wird ohne feste IPv4-Adresse als Router verwendet.)
Konfigurationsdatei der FritzBox: b2b-staticip1_50000_5000_ipv4_sip_wifi-on.bin
NTP_Provider_Interface_Spec_Unitymedia

AVM - IPv6 technical note

phil402
Kabelneuling
Beiträge: 23
Registriert: 27.10.2011, 21:58

Re: Seit neuem keine Portfreigabe mehr möglich.

Beitrag von phil402 » 24.06.2014, 16:39

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?

failure404
Kabelneuling
Beiträge: 29
Registriert: 18.06.2014, 21:21

Re: Seit neuem keine Portfreigabe mehr möglich.

Beitrag von failure404 » 24.06.2014, 20:31

phil402 hat geschrieben: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
Übergeordneter Verstärkerpunkt
Beiträge: 575
Registriert: 15.03.2013, 09:00

Re: Seit neuem keine Portfreigabe mehr möglich.

Beitrag von magentis » 24.06.2014, 20:34

failure404 hat geschrieben:
phil402 hat geschrieben: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.
3Play Premium 100
DigitalTV Allstars + HD Option
Echostar Recorder
Cisco EPC 3208
Firmwarename: e3200-E10-5-v302r125562-130611c_upc.bin Jun 19 17:34:31 2013
Config-File: generic_100000_5000_ipv4_ncs_wifi-on.bin
Asus RT-N66U
Samsung UE40F6500
Sky Buli + Sport HD auf Sky Recorder
Synology DS213+

Die Moral von der Geschicht, traue keinen Versprechungen der UM-Hotliner.

tq1199
Glasfaserstrecke
Beiträge: 1486
Registriert: 07.02.2014, 09:05

Re: Seit neuem keine Portfreigabe mehr möglich.

Beitrag von tq1199 » 24.06.2014, 22:10

phil402 hat geschrieben: 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
...
Office Internet & Phone 50, AVM FRITZ!Box 6360 Cable (kbw) - FRITZ!OS 06.52 - , an Arris-CMTS, zusätzlich eine feste (statische, nicht per DHCP) IPv4-Adresse für meinen Server, am Bridge-Anschluss (kein Bridge-Modus, FB6360-cable wird ohne feste IPv4-Adresse als Router verwendet.)
Konfigurationsdatei der FritzBox: b2b-staticip1_50000_5000_ipv4_sip_wifi-on.bin
NTP_Provider_Interface_Spec_Unitymedia

AVM - IPv6 technical note

Benutzeravatar
SpaceRat
Glasfaserstrecke
Beiträge: 2466
Registriert: 08.05.2010, 01:30
Wohnort: Kreis Aachen
Kontaktdaten:

Re: Seit neuem keine Portfreigabe mehr möglich.

Beitrag von SpaceRat » 25.06.2014, 03:12

phil402 hat geschrieben: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.

Benutzeravatar
SpaceRat
Glasfaserstrecke
Beiträge: 2466
Registriert: 08.05.2010, 01:30
Wohnort: Kreis Aachen
Kontaktdaten:

Re: Seit neuem keine Portfreigabe mehr möglich.

Beitrag von SpaceRat » 25.06.2014, 09:26

magentis hat geschrieben: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.
Receiver/TV:
  • Vu+ Duo² 4xS2+2xC / OpenATV 6.1@Samsung 50" Plasma
  • AX Quadbox HD2400 2xS2+2xC / OpenATV 6.1@Samsung 32" TFT
  • 2xVu+ Solo² / OpenATV 6.1
  • DVBSky S2-Twin PCIe@SyncMaster T240HD (PC)
  • TechniSat SkyStar HD2@17" (2.PC)
Pay-TV: Schwarzfunk, Redlight Elite Superchic, SCT 10, HD-, Sky
Fon: VF Komfort-Classic (ISDN), 2xFritz!Fon C4+Siedle DoorCom Analog@F!B 7390
Internet: UM 1play 100 / Cisco EPC3212+Linksys WRT1900ACS / IPv4 (UM) + IPv6 (HE)
Bild

Benutzeravatar
SpaceRat
Glasfaserstrecke
Beiträge: 2466
Registriert: 08.05.2010, 01:30
Wohnort: Kreis Aachen
Kontaktdaten:

Re: Seit neuem keine Portfreigabe mehr möglich.

Beitrag von SpaceRat » 25.06.2014, 09:55

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
Übergeordneter Verstärkerpunkt
Beiträge: 575
Registriert: 15.03.2013, 09:00

Re: Seit neuem keine Portfreigabe mehr möglich.

Beitrag von magentis » 25.06.2014, 12:50

@ 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.
3Play Premium 100
DigitalTV Allstars + HD Option
Echostar Recorder
Cisco EPC 3208
Firmwarename: e3200-E10-5-v302r125562-130611c_upc.bin Jun 19 17:34:31 2013
Config-File: generic_100000_5000_ipv4_ncs_wifi-on.bin
Asus RT-N66U
Samsung UE40F6500
Sky Buli + Sport HD auf Sky Recorder
Synology DS213+

Die Moral von der Geschicht, traue keinen Versprechungen der UM-Hotliner.

Antworten

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 10 Gäste