Top-Themen

AppleEntwicklungHardwareInternetLinuxMicrosoftMultimediaNetzwerkeOff TopicSicherheitSonstige SystemeVirtualisierungWeiterbildungZusammenarbeit

Aktuelle Themen

Administrator.de FeedbackApache ServerAppleAssemblerAudioAusbildungAuslandBackupBasicBatch & ShellBenchmarksBibliotheken & ToolkitsBlogsCloud-DiensteClusterCMSCPU, RAM, MainboardsCSSC und C++DatenbankenDatenschutzDebianDigitiales FernsehenDNSDrucker und ScannerDSL, VDSLE-BooksE-BusinessE-MailEntwicklungErkennung und -AbwehrExchange ServerFestplatten, SSD, RaidFirewallFlatratesGoogle AndroidGrafikGrafikkarten & MonitoreGroupwareHardwareHosting & HousingHTMLHumor (lol)Hyper-VIconsIDE & EditorenInformationsdiensteInstallationInstant MessagingInternetInternet DomäneniOSISDN & AnaloganschlüsseiTunesJavaJavaScriptKiXtartKVMLAN, WAN, WirelessLinuxLinux DesktopLinux NetzwerkLinux ToolsLinux UserverwaltungLizenzierungMac OS XMicrosoftMicrosoft OfficeMikroTik RouterOSMonitoringMultimediaMultimedia & ZubehörNetzwerkeNetzwerkgrundlagenNetzwerkmanagementNetzwerkprotokolleNotebook & ZubehörNovell NetwareOff TopicOpenOffice, LibreOfficeOutlook & MailPapierkorbPascal und DelphiPeripheriegerätePerlPHPPythonRechtliche FragenRedHat, CentOS, FedoraRouter & RoutingSambaSAN, NAS, DASSchriftartenSchulung & TrainingSEOServerServer-HardwareSicherheitSicherheits-ToolsSicherheitsgrundlagenSolarisSonstige SystemeSoziale NetzwerkeSpeicherkartenStudentenjobs & PraktikumSuche ProjektpartnerSuseSwitche und HubsTipps & TricksTK-Netze & GeräteUbuntuUMTS, EDGE & GPRSUtilitiesVB for ApplicationsVerschlüsselung & ZertifikateVideo & StreamingViren und TrojanerVirtualisierungVisual StudioVmwareVoice over IPWebbrowserWebentwicklungWeiterbildungWindows 7Windows 8Windows 10Windows InstallationWindows MobileWindows NetzwerkWindows ServerWindows SystemdateienWindows ToolsWindows UpdateWindows UserverwaltungWindows VistaWindows XPXenserverXMLZusammenarbeit
GELÖST

FRITZ!Box 6490 Cable (kdg) - trendnet IP-Cams nicht mehr erreichbar

Frage Netzwerke

Mitglied: ollip2016

ollip2016 (Level 1) - Jetzt verbinden

20.03.2017, aktualisiert 15:42 Uhr, 291 Aufrufe, 14 Kommentare

Hallo,

ich habe eine Problematik, bei der ich aktuell nicht weiter weis.
Als IT-Systemelektroniker und langjähriger IT-Systemadministrator mit tiefgreifenden Netzwerkkenntnissen, ist man tatsächlich irgendwann mal mit seinem Latein am Ende.

Folgende Konfiguration habe ich Vor-Ort:
- FRITZ!Box 6490 Cable (kdg) [FRITZ!OS:06.50]
- 3x Trendnet TV-IP310PI (per Kabel angebunden)
- 1x D-Link DCS-942L (W-LAN Cam)
- TP-Link TL-SG1008P (8-Port Gigabit POE Switch)

ip-cam_switch_config - Klicke auf das Bild, um es zu vergrößern

Die Verkabelung ist gem. dem Bild vorgenommen worde. Cat.6 Verlegekabel, Cat.6 Patchpanels, Cat.6 Patchkabel, Gibabit Switche usw.
Die Cams sind entsprechend an dem POE Switch an den POE-Ports angeschlossen.

Die ganze Netzwerkverkabelung wurde mit einem Fluke Tool durchgemessen, alles top.

Die Cams wurden von den IP-Adressen wie folgt konfiguriert :

Cam1: 192.168.xxx.40 Port: 8081
Cam2: 192.168.xxx.41 Port: 8082
Cam3: 192.168.xxx.42 Port: 8083
Cam4: 192.168.xxx.43 Port: 8084

auf der FritzBox wurde entsprechend eine Portforwarding für die Ports 8081,8082,8083,8084 auf den jeweiligen IPs vorgenommen.
DynDns Account eingerichtet.

Die Cams sind nun quasi über

https://xxxxx.dnydns.tv:8081
https://xxxxx.dnydns.tv:8082
https://xxxxx.dnydns.tv:8083
https://xxxxx.dnydns.tv:8084

aus dem Internet zu erreichen.

Nun das Problem:
Nach einer gewissen Zeit (varriert zwischen 2-12h) sind NUR die Trendnet Cams nicht mehr erreichbar!!!!! Die D-Link WebCam funktioniert ohne Probleme.
Starte ich aber die FritzBox NEU, funktioniert wieder alles bis es halt wieder nach der o.g. varrierenden Zeit von 2-12h wieder nicht funktioniert.

was ich schon gecheckt habe....
- anderen POE switch KEINE Veränderung
- 3 x POE Injektor (TP-Link) KEINE Veränderung
- neue Patchkabel (sowohl an den Cams, als auch von Switch zu Patchpanel und von Patchpanel an Switch) KEINE Veränderung
- aktuelle Firmware auf allen Netzwerkkomponenten (aktiv) aufgespielt (auch auf die IPCams)

Wiegesagt, da die Netzwerkverbindungen alle durchgemessen sind und da alles ok ist, kann ich das schon mal 100% ausschließen.
Switche würde ich auch aussschließen....

So.... feuer frei.....was habt ihr noch für Ideen.

Sorry noch für die reudige Zeichnung....musste mir mit Word behelfen, habe gerade kein Visio aufm PC

Lg ollip2016


Mitglied: Lochkartenstanzer
LÖSUNG 20.03.2017, aktualisiert um 10:55 Uhr
Moin,

  • Hast du mal mit dem sniffer geschaut, ob die Fritzbox die Pakete zu den Trendnets weiterleitet oder nicht?

  • Hast du mal von der Fritzbox aus die Trendnets gepingt?

Und zu guter letzt:

  • Trendnet baut wundervolle İoT-Bots. Wenn Du die mit dem nackten Arsch ins İnternet hängst, ist das wie ein gloryhole auf dem Bahnhofsklo.

Du solltest umgehend die Portweiterleitungen zu den Kameras rausnehmen und stattdessen den ipsec-Tunnel der Fritzbox nutzen.

Meine Kristallkugel sagt nämlich, daß Du dem.İoT mehrere Bots spendiert hast.

lks

PS: https://www.google.de/amp/s/www.golem.de/news/mirai-iot-botnet-ip-kamera ...
Bitte warten ..
Mitglied: aqui
LÖSUNG 20.03.2017, aktualisiert um 11:00 Uhr
Hast du dir mal mit einem Wireshark Trace und einem Mirrorport am Switch angesehen was genau passiert wenn die Trendnet Cams nicht mehr erreichbar sind ?
Forwardet die FritzBox dann überhaupt noch IP Pakete von extern auf die Cams ?
Das wäre essentiell zu wissen um das Problem dann bei der FB oder den Cams suchen zu müssen bzw. eingrenzen zu können.
KDG ist auch immer mit Vorsicht zu geniessen, da die fast immer DS-Lite Anschlüsse mit CGN (Carrier Grade NAT) verwenden wo IP Forwarding generell unmöglich ist. Das kanns aber bei dir natürlich nicht sein, denn ansonsten würde gar nix klappen. Vermutlich hast du eine öffentliche IP hier beantragt oder Glück das du eine bekommst.

Die Wahl der Ports ist auch nicht gerade glücklich bzw. intelligent. Als kundiger Netzwerker solltest du eigentlich wissen das man fest vergebene IANA Ports niemals nutzen sollte, da das ggf. mit entsprechendem Traffic im Provider bzw. Internet Backbone kollidieren kann:
https://www.iana.org/assignments/service-names-port-numbers/service-name ...
Sinnvoller wären daher die extra dafür vorgesehenen sog. Ephemeral Ports
https://en.wikipedia.org/wiki/Ephemeral_port
von 49152 bis 65535 zu verwenden.
Nicht das du damit standardkonformer bist, es schützt dich und die FritzBox obendrein auch besser vor den obligatorischen Port Scanner Angriffen im Sekundentakt, die natürlich auch diese hauptsächlich für Caches benutzte Port Range immer mit scannen. Auch das weiss man als langjähriger Netzwerker.
Insofern war diese Wahl nicht gerade intelligent. Besser: //
Cam1: 192.168.xxx.41 Port: 58081
Cam2: 192.168.xxx.42 Port: 58082
Cam3: 192.168.xxx.43 Port: 58083
Cam4: 192.168.xxx.44 Port: 58084
Hat zudem auch noch eine logische Zuordnung der CAM Nummer und IP Adresse zum Port was für Laien nachher besser zu merken ist
Bitte warten ..
Mitglied: Lochkartenstanzer
LÖSUNG 20.03.2017 um 10:58 Uhr
Zitat von aqui:

Besser: //
Cam1: 192.168.xxx.41 Port: 58081
Cam2: 192.168.xxx.42 Port: 58082
Cam3: 192.168.xxx.43 Port: 58083
Cam4: 192.168.xxx.44 Port: 58084


Also da hätte ich jetzt 57041...57044 genommen.

Aber Mirai und Co. werden da trotzdem keinen Tag brauchen, um die wiederzufinden.

lks
Bitte warten ..
Mitglied: aqui
LÖSUNG 20.03.2017, aktualisiert um 11:08 Uhr
Aber Mirai und Co. werden da trotzdem keinen Tag brauchen, um die wiederzufinden.
Ja, letztlich hast du natürlich recht. Aber wenigstens eine kleine Verschleierung die einen Angriff etwas erschwert.
Auf diesen fatalen und grundlegenden Designfehler das der TO die Kameradaten vollkommen ungeschützt durchs Internet und für die gesamte Welt sichtbar schiebt mal gar nicht zu reden.
Das können personenbezogene Daten sein so das sich der TO mit so einem Konzept ggf. sogar strafbar macht nach IT Recht in D. Aber das ist jetzt einen ganz andere Story.... Durch den vollkommen ungeschützten Transfer der Daten ist das ja sehr einfach nachweisbar.
Die sinnvollste Lösung wäre ein VPN auf der FritzBox gewesen ! Damit wäre das Netzwerk geschützt, die FritzBox nicht durch Port Forwarding Löcher gefährtet und auch die Kameradaten sicher geschützt und nur für die Augen bestimmt die es sehen sollen.
Ob das Prädikat "langjähriger IT-Systemadministrator mit tiefgreifenden Netzwerkkenntnissen" dann wirklich stimmt ist fraglich. Wie immer aber relativ von der jeweiligen Sichtweise betrachtet. Aber ganz anderes Thema....
Netzwerker Fazit: Wireshark ist wie immer dein Freund hier
Bitte warten ..
Mitglied: Dobby
LÖSUNG 20.03.2017 um 11:29 Uhr
Hallo zusammen,

also ich denke an den Patchpanelen sind doch immer die Netzwerkdosen dran auf der einen Seite und von der anderen Seite werden
diese Ports dann eben auf einen Switch gepatched, oder? Und warum sind die beiden Patchpanel untereinander mit Patchkabeln
verbunden worden? Ich denke man sollte die beiden Switche untereinander verbinden bzw. miteinander verbinden und nicht die
Patchpanel!

So.... feuer frei.....was habt ihr noch für Ideen.
Das wars schon, verbinde die Switche untereinander und nicht die Patchpanel und dann sollte es funktionieren.

Nun das Problem:
Nach einer gewissen Zeit (varriert zwischen 2-12h) sind NUR die Trendnet Cams nicht mehr erreichbar!!!!! Die D-Link WebCam
funktioniert ohne Probleme.
Die D-Link Webcam ist via USB an der AVM FB dran richtig!? Dann ist das wohl eher wegen der 24h ISP Zwangstrennung und die
per USB angeschlossene Webcam ist davon nicht betroffen, nach meiner Schätzung. Warum wählt man sich nicht einfach via AVM
Android oder iOS VPN APP (Fritz!Fernzugang) ein und hat dann auf alle angeschlossenen Geräte Zugriff, also von außen Zugriff
via VPN! Warum Ports freigeben und dann kann das gesamte Internet über die Kameras mit zuschauen was da "abgeht"?

Starte ich aber die FritzBox NEU, funktioniert wieder alles bis es halt wieder nach der o.g. varrierenden Zeit von 2-12h
wieder nicht funktioniert.
Zwangstrennung des ISP? Oder macht der DynDNS Dienst dort nicht mehr mit bzw. Probleme!?

Gruß
Dobby
Bitte warten ..
Mitglied: aqui
LÖSUNG 20.03.2017, aktualisiert um 11:50 Uhr
Und warum sind die beiden Patchpanel untereinander mit Patchkabeln verbunden worden?
Das wäre in der Tat Quatsch ist aber vermutlich ein Zeichnungsfehler und soll wohl nur verdeutlichen das der eine Switch über das Patchpanel aufs andere Panel zum dortigen Switch durchgepatcht ist. Was dann natürlich absolut OK ist.

Da es ja temporär alles klappt zeigt das die physische Infrastruktur soweit ja unstrittig und richtig ist, da mit der D-Link Cam ja alles sauber funktioniert
Das sieht mehr nach einen Forwarding Bug aus in Router oder Kamera. Ggf. die auch die TCP Portproblematik.
Das müsste der TO aber mal mit dem Kabelhai klären.
Auch bleibt die Frage offen warum er die Ports auf den Kameras selber umgestellt hat. Das ist eigentlich vollkommen überflüssig, denn die FritzBox supportet ja auch IP Port Translation, so das man intern immer mit dem Standardport TCP 80 auf den Cams arbeiten kann OHNE die verbiegen zu müssen.
Man macht dann entsprechend Port Translation auf dem Router ala:
Incoming TCP 58081 -> auf lokal TCP 80 IP: 192.168.178.41
Incoming TCP 58082 -> auf lokal TCP 80 IP: 192.168.178.42

usw.
Möglich auch das die Kameras einen FW Bug haben wenn sie mit fremden TCP Ports arbeiten. Bei billiger und oft schlampig programmierter China Ware wie der obigen sollte man sowas immer auf dem Radar haben.
Das würde der Wireshark aber auch sofort aufdecken !

TO hat den Thread ja jetzt selber auf gelöst geklickt. Problem hat er dann ja vermutlich gefixt. Wäre in einem Forum ja immer mal interessant zu erfahren was es denn letztlich war ?!
Bitte warten ..
Mitglied: ollip2016
20.03.2017, aktualisiert um 12:49 Uhr
Vielen Dank an aqui und Lochkartenstanzer .
Da das ganze in der Konfiguration nur Geländeabschnitte um ein privates Einfamilienhaus sichtbar macht, ohne das hier ein Nachbarhaus oder andere öffentliche Bereiche sichtbar sind, sehe ich da ganze in Bezug auf den Schutz personenbezogener Daten als unkritisch an.

Das mit der Nutzung der Netzwerkports (gem. IANA) ist mir selbstverständlich bewusst.

Der Angreifbarkeit von IPCams war ich mir zwar bewusst, aber das dass so krass ist, wie in dem Artikel "Mirai-IoT-Botnet" beschrieben ist, war mir nicht bewusst.

@aqui: danke für die Kommentierung von "langjähriger IT-Systemadministrator mit tiefgreifenden Netzwerkkenntnissen".... :D
Bitte warten ..
Mitglied: ollip2016
20.03.2017, aktualisiert um 12:51 Uhr
@Dobby:
wie schon von aqui geschrieben, ist die Zeichnung vielleicht etwas irreführend.
klar sind die switche miteinander verbunden.
port 12 kamera-panel ist mit cat.6 verlegekabel mit dem Port 32 des hauptpatchpanels verbunden.
von port 12 geht dann ein patchkabel auf den kamera switch, von port 32 ein patchkabel auf en 16 port hauptswitch.
somit wird hier nur die verbindung hergestellt.

im außenbereich liegt das cat.6 verlegekabel in einer Aufputzverteilerdose und ist darin mit einem Cat.6 Keystone aufgelegt....im Keystone steckt dann ein kurzes Patchkabel von 0,5m und verbindet dann die "Festverkabelung" mit dem RJ45 plug der IPCam.

Das Problem ist noch nicht gelöst, kann ich erst im laufe der woche umsetzen/ausprobieren, da ich auf der Arbeit bin.
War mir der Funktion des "zur Lösung beigetragen" Buttons nicht vollumfänglich bewusst.
Bitte warten ..
Mitglied: Lochkartenstanzer
LÖSUNG 20.03.2017 um 12:52 Uhr
Zitat von ollip2016:

Das Problem ist noch nicht gelöst, kann ich erst im laufe der woche umsetzen/ausprobieren, da ich auf der Arbeit bin.

Sniffen mit der fritzbox
Bitte warten ..
Mitglied: ollip2016
20.03.2017 um 12:54 Uhr
Die D-Link Cam ist per WLAN verbunden.

Das mit dem VPNaccess ist richtig, werde ich auch so umsetzen.

Zwangstrennung nach 24h gibt es im Kabelnetz nicht, das gibt es nur bei DSL.

Der DynDns Service ist ja für solch ein Scenario gedacht, dass quasi nach 24h bei der DSL Zwangstrennung die IP wieder einem "Namen" zugeordnet wird.
Bitte warten ..
Mitglied: aqui
LÖSUNG 20.03.2017, aktualisiert um 13:01 Uhr
aber das dass so krass ist, wie in dem Artikel "Mirai-IoT-Botnet" beschrieben ist, war mir nicht bewusst.
Viele Laien unterschätzen das wie man auch hier in einem Administratorforum täglich lesen kann.
Man kann nur jedem einmal empfehlen einen Sniffer auf seinen DSL, Kabel oder Internet Port zu aktivieren.
Das öffnet einem ganz schnell die Augen was da im Sekundentakt weltweit reinprasselt. Irgendwo auf der Welt sind immer Port Scanner und Script Kiddies am Werk...Botnetze sowieso.
Aber auch das weiss man natürlich alles als "langjähriger IT-Systemadministrator mit tiefgreifenden Netzwerkkenntnissen" da ist man ja nicht mehr blauäugig oder sollte es wenigstens nicht mehr sein, oder ?
Bitte warten ..
Mitglied: ollip2016
20.03.2017 um 13:16 Uhr
die genannte Thematik ist mir selbstverständlich mehr als geläufig bzw. present.
Habe die Thematik aber in Bezug auf IPCams ehrlich gesagt etwas blauäugig behandelt, das muss ich zugeben.
Ich möchte mich hier auch nicht mit meiner Berufserfahrung brüsten, jeder ist ja unterschiedlich versiert, ja nach Erfahrung und womit er am meisten gearbeitet hat.

Aber schonmal vielen Dank für deine hier zur Verfügung gestellte Expertise, die bringt mich schon in dem ein oder anderen Bereich um einiges weiter.
Bitte warten ..
Mitglied: ollip2016
28.03.2017 um 13:49 Uhr
Vielen Dank für die ganzen Beiträge.

Ich habe nun die Konfiguration dementsprechend geändert, indem ich alle Portweiterleitungen aufgehoben habe, die Ports auch jeweils wieder auf den Standard-Port 80 zurückgesetzt habe und einen VPNconnect eingerichtet habe.

Damit funktionieren jetzt die Kameras alle einwandfrei und ohne Probleme, ohne einfrieren der Cams nach wenigen Stunden.

Danke nochmals für eure Hilfe.
Bitte warten ..
Mitglied: windowsboy
06.04.2017 um 20:44 Uhr
Zitat von Lochkartenstanzer:


* Trendnet baut wundervolle İoT-Bots. Wenn Du die mit dem nackten Arsch ins İnternet hängst, ist das wie ein gloryhole auf dem Bahnhofsklo.

Meine Kristallkugel sagt nämlich, daß Du dem.İoT mehrere Bots spendiert hast.


Dann gibst bestimmt bald auch das alt Bekannte Schlangenöl für Waschmaschinen, Trockner, Geschirrspüler, Glotzen!
Bitte warten ..
Ähnliche Inhalte
Netzwerkmanagement
gelöst Fritz!Box 6490 Cable source IP based routing (8)

Frage von ketanest112 zum Thema Netzwerkmanagement ...

Router & Routing
gelöst Fritz!Box 6490 Cable hängt in Dauerreboot Schleife (5)

Frage von ketanest112 zum Thema Router & Routing ...

Neue Wissensbeiträge
Drucker und Scanner

Samsung SL-M4025ND, firmware update und (kompatible) Tonerkassetten

(1)

Erfahrungsbericht von markus-1969 zum Thema Drucker und Scanner ...

Router & Routing

PfSense auf Supermicro Intel Xeon D-15x8 SoC Bare Bone

Tipp von Dobby zum Thema Router & Routing ...

Windows Server

Exchange 2010 auf Windows Server 2016 und AD

(2)

Tipp von Herbrich19 zum Thema Windows Server ...

KVM

How to: Libvirt Port forwarding

(2)

Anleitung von fundave3 zum Thema KVM ...

Heiß diskutierte Inhalte
Netzwerkprotokolle
PC erhalten nicht immer eine gültige IP (29)

Frage von Lieberwolf zum Thema Netzwerkprotokolle ...

Windows Systemdateien
Windows 7 und 10 herunterfahren Knopf mit Script belegen (21)

Frage von c-o-o-p-e-r92 zum Thema Windows Systemdateien ...

Router & Routing
über Vmware auf eine FritzBox mit IPv6 per VPN (16)

Frage von Zockervogel zum Thema Router & Routing ...