Fritzbox und Portfreigaben

[junitiv]

Hallo,

ich habe mich heute versucht über mein Handy von unterwegs mit meinen Heimserver(ssh) zu verbinden.

Leider kam nur ein Fehler vom ssh Programm.

Eben habe ich denn Fehler gesucht.

Die Fritzbox hat einfach heute morgen um 06:00 Uhr die Portfreigaben entfernt. (Laut Protokoll) Für ipv4 und ipv6.

Code: Alles auswählen

Freigabe für Port 22 auf [ipv6] (raspberrypi) entfernt.

Freigabe für Port 22 auf 192.168.0.xxx(raspberrypi) entfernt.

Auf der Seite mit der Portfreigaben war die ssh verbindung noch drinne und der Hacken war gesetzt.

Wie kann das sein?

Gruß Junitiv

[BenutzerGa4gooPh]

Da würde ich mal das Passwort verlängern (*), jedwedes Management der FB aus WAN verbieten, automat. Updates ebenfalls.
Dann bleiben nur noch die Backdoors und Exploits für den Erhalt der Demokratie. Du bist doch demokratisch?

(*) Derzeit sind ungewöhnliche Sätze oder Wortgruppen in Mode.

Wie kann das sein?

Ausführlich Logs. Fritzbox mit ssh? Läuft wohl Linux drauf. Hosts im LAN einbeziehen.

[junitiv]

demokratisch? Logo

Aber wenn jemand in der FB war, sollte es doch im Protokoll sichtbar sein, oder???

[mat6937]

Die Fritzbox hat einfach heute morgen um 06:00 Uhr die Portfreigaben entfernt. (Laut Protokoll) Für ipv4 und ipv6.

Code: Alles auswählen

Freigabe für Port 22 auf [ipv6] (raspberrypi) entfernt.

Freigabe für Port 22 auf 192.168.0.xxx(raspberrypi) entfernt.

Nein, das hat die FritzBox nicht gemacht, auch wenn es im Log der FritzBox so steht.

Auf der Seite mit der Portfreigaben war die ssh verbindung noch drinne und der Hacken war gesetzt.

Wie kann das sein?

"war" oder "ist"?

Hast Du geprüft ob dein PI noch auf dem Port 22 lauscht?
Mach mal aus dem Internet, einen Portscan auf den TCP-Port 22 und die externe IPv4-Adresse deiner FritzBox.

[junitiv]

Der Hacken ist drinne und nachdem ich die Portfreigaben bearbeitet und gespeichert habe ist alles wieder möglich.

Hast Du geprüft ob dein PI noch auf dem Port 22 lauscht?
Mach mal aus dem Internet, einen Portscan auf den TCP-Port 22 und die externe IPv4-Adresse deiner FritzBox.

Vorher habe ich alles getestet:
Pi lauscht auf Port 22
Portscan sagt das der Port auf die externe IP zu ist.

[mat6937]

Vorher habe ich alles getestet:
Pi lauscht auf Port 22
Portscan sagt das der Port auf die externe IP zu ist.

Welche FritzBox, mit welcher Firmware und bei welchem Provider hast Du? Hat deine FritzBox heute morgen um 06:00 Uhr. ohne dein Zutun einen reboot gemacht?

Wenn meine FritzBox von sich aus rebootet, dann habe ich auch diese Eintragungen im Log der FritzBox. Diese Eintragungen haben aber keine Auswirkungen auf die Portfreigabe in der FritzBox. Man muss an der FritzBox nichts ändern.

[junitiv]

FRITZ!Box 6490 Cable (kdg)
Kabel/Vodafone
Version:06.66

Auch kein Reboot..

[mat6937]

Auch kein Reboot..

Ist das mit dem Port 22, die einzige Portfreigabe in deiner FritzBox?

Wenn Du dir sicher bist, dass die FB keinen reboot gemacht hat, bleibt noch die Portfreigabe mit UPnP oder PCP durch ein Gerät in deinem (W)LAN. Hast Du ein Gerät in deinem (W)LAN so konfiguriert, dass es diesen Port freigeben kann? Wenn Du das nicht willst, dann evtl. auch das UPnP in deiner FritzBox deaktivieren.

Siehe auch: https://avm.de/service/fritzbox/fritzbo ... inrichten/

[junitiv]

Ist das mit dem Port 22, die einzige Portfreigabe in deiner FritzBox?

Derzeit ja

Kein Gerät ist so konfiguriert und UPnP ist jetzt aus.

[mat6937]

Kein Gerät ist so konfiguriert und UPnP ist jetzt aus.

Naja, manchmal weiß man das auch nicht so genau, bei den Smartphones und Tablets, etc.

Ist das UPnP erst jetzt aus oder war es schon immer aus?

[TomL]

In der Fritte muss nicht nur der Port freigegeben werden, es muss auch eine Weiterleitung auf den PI und dessen Port 22 eingerichtet werden.

BTW... ein paar Anmerkungen:
1. Ich würde auf der Fritte nicht Port 22 freigeben, sondern einen Port >55000 und dann nur die Weiterleitung auf Port 22 des Pi einrichten
2. Damit der Pi kein Honeypot für Angreifer aus dem Web wird, solltest Du unbedingt den User "pi" entfernen
3. Aus gleichem Grund sollte sich auch "root" nicht via ssh anmelden dürfen
4. Die Anmeldung eines einzelnen bestimmten Users sollte grundsätzlich nicht via PWD erlaubt sein, sondern nur via Keyfile, welches selber auch nur mit Password verwendet werden kann.

Die Freigabe eines Ports >55000 reduziert gravierend das Rauschen durch weltweite Angreifer, was Du auf Port 22 defintiv haben wirst. Die Bestimmung von Port 22 ist bekannt, irgendein anderer und so hoher Port kann alles oder nichts sein. Ohne konkrete Sicherungsmaßnahmen würde ich keine Wette annehmen, dass der RPi nicht binnen 24 Stunden gehackt ist.

j.m.2.c.

[mat6937]

Auch kein Reboot..

BTW: Das mit dem Log-Eintrag der FritzBox kann auch passieren, wenn die FritzBox lediglich ein Disconnect oder Reconnect macht oder dein Provider Wartungsarbeiten durchführt (... und die FritzBox temporär keinen Internetzugang hat). Ein reboot der FB ist da auch nicht erforderlich.

EDIT:

Siehe auch diesen Thread im IPPF: https://www.ip-phone-forum.de/threads/f ... st-2178590

[mat6937]

..., irgendein anderer und so hoher Port kann alles oder nichts sein. ...

BTW: Wenn man mal einen lauschenden Port gefunden hat, ist es ganz einfach festzustellen, ob an diesem Port ein ssh-Server (sshd) lauscht. Z. B. mit dem tool scanssh:

Description-de: Sammelt SSH-Server-Versionen für ein ganzen Netzwerk
Der scanssh-Protokoll-Scanner überprüft eine Liste von Adressen und
Netzwerken auf aktive SSH-Protokoll-Server und ihre Versionsnummern.
Version 2.0 fügt Unterstützung für das Prüfen beliebiger Ports und
insbesondere offener Proxies hinzu. Der scanssh-Protokoll-Scanner
unterstützt zufällige IP-Adressen-Auswahl von großen Netzwerkbereichen und
ist nützlich für die Sammlung von Statistiken über den Einsatz von SSH-
Protokoll-Servern in einer Firma oder dem gesamten Internet.

Code: Alles auswählen

:~$ scanssh -s ssh -n 22 -i wlan1 213.9#.##.##
213.9#.##.##:22 SSH-2.0-OpenSSH_7.2p2 Ubuntu-4ubuntu2.4
Effective host scan rate: 4.88 hosts/s

[BenutzerGa4gooPh]

Offenbar führt die Fritzbox keine vernünftigen Logs.

Das mit dem Log-Eintrag der FritzBox kann auch passieren, wenn die FritzBox lediglich ein Disconnect oder Reconnect macht oder dein Provider Wartungsarbeiten durchführt (... und die FritzBox temporär keinen Internetzugang hat). Ein reboot der FB ist da auch nicht erforderlich.

Sieht man da nicht, dass vorher das WAN-IF down geht, die Dis-/Reconnects, evt. IP-Umadressierung? Reihenfolge aller relevanten Ereignisse? Muss ja nicht per GUI sein. SSH-Zugang aus LAN auf FB möglich?

Wenn meine FritzBox von sich aus rebootet, dann habe ich auch diese Eintragungen im Log der FritzBox.

Wieso rebootet die "von sich aus" und wie oft?

@TO:

FRITZ!Box 6490 Cable (kdg)
Kabel/Vodafone

Ein eigener oder fremder Managementzugang aus WAN ("Wartung", TR-069, Umkonfiguration, Automat. Updates etc.) ist keinesfalls sicher und Fremdmanagement nur für unbedarfte User sinnvoll. Updates sind in Eigenregie zu tun!
https://blog.thesen.eu/tr-069-bei-gebra ... ktivieren/
http://www.goebel-consult.de/blog/tr-06 ... nis-prufen
Damit wären nur die ausführlichen Linux-Logs des durch Portforwarding öffentlich erreichbaren Raspis zu berücksichtigen.
SSH-Logs z. B. https://unix.stackexchange.com/question ... s-attempts
Auf den Raspi geforwardete Ports natürlich sichern.
(Miserable Logs der FB sind sicherheitstechnisch nicht hilfreich, aber hoffentlich nicht mehr so wesentlich. Unregelmäßigkeiten im LAN erkennt man natürlich weniger oder nicht.)
Google hilft dir vielleicht, die FB des Providers zu "entbranden", AVM-Firmware zu installieren. Die Zugangsdaten kann man ja vom Provider erhalten oder "abschreiben" mit Copy+Paste.

OT: Haken vs. Hacken bitte mal im Duden nachschlagen.

[mat6937]

Offenbar führt die Fritzbox keine vernünftigen Logs.

Ja, genau so ist es.

Sieht man da nicht, dass vorher das WAN-IF down geht, die Dis-/Reconnects, evt. IP-Umadressierung? Reihenfolge aller relevanten Ereignisse? Muss ja nicht per GUI sein. SSH-Zugang aus LAN auf FB möglich?

Doch das sieht man schon. Das Problem ist, dass wenn der Kabel-Provider meistens nachts oder am frühen morgen Wartungsarbeiten durchführt und die FritzBox in diesem Zeitraum dann ja keinen Internetzugang hat, die 24/7-Clients (wie z. B. der PI) an der FritzBox-cable ihre default route "verlieren" (da ja ein brauchbares gateway nicht zur Verfügung steht). Wenn danach die FritzBox-cable wieder Internet-Zugang hat, konfiguriert/erstellt der PI (als 24/7-Client) i. d. R diese default route nicht von sich aus wieder her. D. h. man sollte den PI so "optimieren" (Scripte, cronjobs, etc.), dass dieser "ständig" seinen Internet-Zugang prüft/testet und bei Bedarf (d. h. wenn nicht mehr vorhanden) die default route setzt/konfiguriert. Denn wenn der 24/7-Client das nicht tut, ist er trotz Portfreigabe und Abschluss der Wartungsarbeiten, aus dem Internet nicht erreichbar.

Wieso rebootet die "von sich aus" und wie oft?

Meine FritzBox rebootet ganz selten und das z. B. dann, wenn der Kabel-Provider aus nur ihm bekannten Gründen, diesen reboot/Neustart der FB initiiert.

Aber es gibt auch (viele) andere Fälle (bei Z. B. UM): https://www.unitymediaforum.de/viewtopi ... 90&t=36715

..., die FB des Providers zu "entbranden", AVM-Firmware zu installieren. ...

BTW: Die FB des Kabel-Providers (d. h. die Firmware) darf man (i. d. R.) nicht modifizieren. Aber man kann sich z. Zt. eine (eigene) FritzBox-cable kaufen und diese vom Kabel-Provider provisionieren lassen.

[BenutzerGa4gooPh]

Das Problem ist, dass wenn der Kabel-Provider meistens nachts oder am frühen morgen Wartungsarbeiten durchführt ...

Hallo mat6937, danke für deine Erläuterungen!

OT (oder auch nicht):
Ich schätze dich als Netzwerkexperten sehr (ohne Ironie und besser als ich), deshalb persönliche Frage: Du selber betreibst nicht (nur) eine FB des Providers, eigener Router oder Firewall dahinter? Oder weißt du das alles von anderen, von Kunden, Freunden etc ?
Darf man/frau fragen, welcher Router, welche Firewall (-Distri)?
(Persönlich halte ich die Konstellation Providerrouter + eigener Router/FW für die beste Variante: Eindeutige Leistungsgrenzen und Testmöglichkeiten.)

Edit: Wort vergessen. Und danke an mat6937 für AW unten.

[mat6937]

Du selber betreibst nicht (nur) eine FB des Providers, eigener Router oder Firewall dahinter? Oder weißt du das alles von anderen, von Kunden, Freunden etc ?

Nein, das ist nur Hobby. Ich mache das nicht beruflich. Ja, Freunden helfe ich manchmal.

Ich hatte bis 2007 einen Internetanschluss bei der Telekom. Von 2007 bis 2012 bei KabelBW ein transparentes Kabelmoden und eine FreeBSD-Firewall. Seit 2013 bei Unitymedia eine (Zwangs-)FritzBox-cable 6360 (Business-Tarif) mit einer zusätzlichen statischen IPv4-Adresse (Bridge-Anschluss), an der direkt (d. h. ohne vorgeschaltete Firewall) im Internet ein Linux-Server (24/7) angeschlossen ist. An den LAN-Anschlüssen der FB6360 habe ich noch 2 PI's (24/7, mit raspbian) die auch aus dem Internet erreichbar sind. Diese Konstellation (mit Redundanz) nutze ich als "Skat"-, jabber-, irc-, OpenVPN-, ssh- und VoIP-Server. Laptops und Desktop mit diversen Linux-Distributionen (kein Windows z. Zt.). IPv6 nutze ich z. Zt. mit 6in4-Tunnel (... da es mit dem Business-Tarif bei UM z. Zt. noch kein Dual-Stack gibt).

[TomL]

BTW: Wenn man mal einen lauschenden Port gefunden hat, ist es ganz einfach festzustellen, ob an diesem Port ein ssh-Server (sshd) lauscht. Z. B. mit dem tool scanssh:

Ja, stimmt... technisch betrachtet kann man dem nicht widersprechen. Nur wenn ich meine eigenen Beobachtungen hinzunehme, bekommt diese technische Tatsache eine etwas geringere Gewichtung.... es ist ein bisschen so, wie die Aussage "Wenn Du in der Wüste ein Taxi findest, fährst Du einfach zur nächsten Oase und entgehst damit dem Verdursten" Was ich damit sagen will... es finden durchaus auch Scans auf die freien Ports ab 49152 statt, das steht aber in keinem Verhältnis mit der permanenten direkten Ballerei auf Port 22. Deswegen hatte ich ja auch gesagt, man reduziert damit lediglich das Rauschen auf der internen Leitung. Viel wichtiger sind imho die anderen Maßnahmen, kein User PI, kein root-Zugang, kein PWD-Zugang.... sonst wird das nämlich wirklich ein Honeypot, der nicht mal die ersten 24 Stunden als freier PI überlebt

[TomL]

(Persönlich halte ich die Konstellation Providerrouter + eigener Router/FW für die beste Variante: Eindeutige Leistungsgrenzen und Testmöglichkeiten.

Wie hast Du die angeblichen Schwächen des Provider-Routers bestätigt und wie hast Du infolgedessen bestätigt, dass der 2. (innere) Router diese Schwächen nicht hat, und was viel wichtiger ist, das er nicht noch zusätzlich weitere (möglicherweise unbekannte/unentdeckte) Schwächen hat, die durch unsachgemäßes Customizing entstanden sind?

[BenutzerGa4gooPh]

Wie hast Du die angeblichen Schwächen des Provider-Routers bestätigt[?]

Fremde Managementhoheit (Provider). Daraus folgt: Teil des "bösen" WAN/Internet.

... und wie hast Du infolgedessen bestätigt, dass der 2. (innere) Router diese Schwächen nicht hat[?]

https://tools.cisco.com/security/center ... nListing.x Ähnliches von AVM?
Des Weiteren kein Managementzugang aus WAN, ausschliesslich meine Managementhoheit (SSH nur von bestimmten Rechnern im LAN), ausführliche Logs, individuelle Konfiguration meinem Netz und meinem Traffic angepasst: Interzonen-Traffic reguliert (und Drops geloggt) mittels LAN-Segmentierung durch VLANs und Sicherheitszonen (WAN, untrusted, trusted, WLAN, Router-Self-Zone) sowie nur bestimmte Geräte (IPs + MACs) zugelassenen. Einsatz professioneller Firewall-Software mit regelmäßigen Updates und proaktiver Fehlersuche/Beseitigung/Bugtracker/Dokumentation des Herstellers. Noch individuelle Feinheiten wie indivduell getestete Thresholds und Logging bei Überschreitung, Maximum neue Sessions/s, halboffene Sessions etc.

Open-Source-Firewalls können Dritte auf Backdoors und Fehler prüfen, ich kann und will es nicht. Meinem Autohersteller vertraue ich auch - und da hängt sogar mein Leben dran. Da mein Zeug nicht hochwichtig ist, Router/FWs/Netzwerke Hobby sind, probiere ich Verschiedenes, derzeit läuft Cisco IOS, PFSense oder OPNSense auf professionellem Thin Client in Vorbereitung. PFSense hatte ich früher schon mal auf einer China-Büchse.

und was viel wichtiger ist, dass er nicht noch zusätzlich weitere (möglicherweise unbekannte/unentdeckte) Schwächen hat, die durch unsachgemäßes Customizing entstanden sind?

Intensives Literaturstudium bezüglich Firewalling, Übersichtlichkeit der Regeln durch Firmware-Hersteller: Nutzung durch Experten vorgefertigter, gehärteter, spezieller "Distributionen" (z. B. PFSense, OPNSense, Cisco). Unterstützung durch GUI bzw. Konfigs in 1 Datei, nicht "verstreuselt". Eigene Abschlusstests / "Qualitätskontrolle" mit Werkzeugen wie nmap. Am meisten gelernt habe ich bei Cisco mit hervorragender Dokumentation, z. B.:
https://www.cisco.com/c/en/us/support/d ... guide.html
https://www.cisco.com/c/en/us/td/docs/i ... ol-fw.html
(Zone self / Router unbedingt beachten, regeln!)

@TO: Sorry für OT.

[TomL]

Entschuldige Jana... ich habe jetzt erst registriert, dass ich Dir diese Frage gestellt habe...ein Versehen. Als ich das geschrieben habe, hatte ich gedacht, ich frage das den TO. Ist wohl heute nicht mein Tag... bin vom ungewohnten körperlichen Arbeiten etwas müde... sorry... und das Du das hinkriegst, glaub ich einfach mal.