127
Neuer User
- Mitglied seit
- 15 Sep 2019
- Beiträge
- 168
- Punkte für Reaktionen
- 13
- Punkte
- 18
Zugriffsversuche von aussen auf die Box
- Ersteller Typograf_Reaload
- Erstellt am
-
- Schlagworte
- hackversuch zugriffsaktivitäten
- Mitglied seit
- 17 Aug 2004
- Beiträge
- 23,172
- Punkte für Reaktionen
- 1,055
- Punkte
- 113
Das ist richtig, hilf aber nicht beim gezielten Versuch, eine bestimmte Box zu "übernehmen".
Die Liste der dem Provider zugewiesenen IP-Bereiche ist nur gut für gießkannenartiges Testen aller möglichen erreichbaren Boxen.
Die Liste der dem Provider zugewiesenen IP-Bereiche ist nur gut für gießkannenartiges Testen aller möglichen erreichbaren Boxen.
alexandi
Aktives Mitglied
- Mitglied seit
- 11 Jun 2009
- Beiträge
- 2,690
- Punkte für Reaktionen
- 581
- Punkte
- 113
Mir ist eigentlich egal, wieviel fremde Zugruffsversuche auf meine stattfinden.
Non-Standard-Benutzername und sicheres Passwort ist das A und O
Non-Standard-Benutzername und sicheres Passwort ist das A und O
Micha0815
IPPF-Promi
- Mitglied seit
- 25 Feb 2008
- Beiträge
- 5,352
- Punkte für Reaktionen
- 467
- Punkte
- 83
Also wenn ich hier lokal einen pinger allein in den letzten beiden Blöcken durchlaufen lasse ala bruteforce, ist meine HW schon längere Zeit beschäftigt. Müssten zu jeder IP auchnoch die ports gescannt werden, dürfte das 24h-Fenster imho etwas knapp werden.
Hier erkenne ich z.B. 89.244.xxx.yyy/89.247.xxx.yyy/88.160.xxx.yyy was dann doch etwas auseinanderliegt und real täglich wechselt bei 1und1.
Mir ist daher schleierhaft, wie ein Angreifer in so kurzer Zeit unsere Box über die wechselnde IP via Bruteforce "intelligent" inkl. Port wiedererkennen könnte OHNE Kenntnis der Dyndns-Adresse.
LG
Nachtrag:
Naja, wenn jmd. nachts mal ebend an Deiner Haustür/Wohnungstür div. Schlüssel im Schloss ausprobiert, wirst Du sicherlich nicht mit einem zufriedenen Grunzer weiterschlafen, sondern eher mal bei der 110/112-Fraktion nach Unterstützung nachfragen
Zuletzt bearbeitet:
- Mitglied seit
- 17 Aug 2004
- Beiträge
- 23,172
- Punkte für Reaktionen
- 1,055
- Punkte
- 113
Sicherlich erhöht das die Einbruchssicherheit im Vergleich zu Standarduser/passwort (erheblich). Ein weiterer Baustein wäre der Nicht-Standard-Port. Das alles ist aber noch herauszufinden.
Unter dem Strich ist das alles aber nur der Kategorie "Security by obscurity" zuzuordnen.
Nur noch via lokalem Login auf die Box zugreifen, ist aber eine ganz andere Liga. Daher rate ich jedem, wenn irgendwie möglich, immer zu einer VPN-Lösung, wenn man von außen auf die Box will/muss.
Was soll sie Feuerwehr denn machen?sondern eher mal bei der ... 112-Fraktion nach Unterstützung nachfragen
Den mit dem Schlauch höher hängen oder mit 10 Bar von der Straße fegen?
Zuletzt bearbeitet:
frank_m24
IPPF-Urgestein
- Mitglied seit
- 20 Aug 2005
- Beiträge
- 20,448
- Punkte für Reaktionen
- 619
- Punkte
- 113
Wer sagt denn, dass die die Box intelligent wiedererkennen? Das ist pures Brute Force. Auf den IPs werden einige wenige Ports gezielt angesprochen und dann werden Zugangsdaten durchprobiert. Von einem potenten Server kannst du 40k - 50k Requests gleichzeitig absetzen (die Anzahl der Clients Ports begrenzt das ganze). Deine Adressbereiche oben bilden ca. 290.000 Adressen ab, dazu vielleicht 3 Ports pro Adresse, das macht nicht mal 1 Mio Zugriffe: Vielleicht eine Stunde, mehr nicht, und sie wissen auf welcher IP welche Ports offen sind und können sich in aller Ruhe an das Durchtesten der Zugangsdaten machen.
Im Gegensatz dazu: Wie sollen sie denn eure dyndns Adresse in Erfahrung bringen?
//Nachtrag; Ich hab gerade mal nachgesehen, ein Check mit nmap, ob port 443 auf meiner Fritzbox offen ist, braucht von meinem vServer aus keine 50 ms. Bei 40k gleichzeitigen Requests kannst du also alle 50 ms 40.000 Zugriffe testen, das macht gerade mal 1,25 Sekunden für 1 Mio Zugriffe. Ok, in der Praxis wird es nicht ganz so schnell gehen, aber die Anzahl der Zugriffe ist eine Kleinigkeit. Da die Angriffe ja gezielt auf Fritzboxen abzielen, suche sie sich die Subnetze der deutschen Provider raus und scannen die auf den gängigen Ports ab. Anschließend werden dann zufällige Zugangsdaten durchprobiert, die bei irgendwelchen Hacks erbeutet wurden.
Zuletzt bearbeitet:
koyaanisqatsi
IPPF-Urgestein
- Mitglied seit
- 24 Jan 2013
- Beiträge
- 14,210
- Punkte für Reaktionen
- 590
- Punkte
- 113
Suchmaschinen mit site: Parameter und nur einen Domainnamen angeben.
Willste kryptische myfritz.net Domain Logins? - Dann: site:myfritz.net login
...weil, irgendwann kommt der Suchmaschinen Bot und indiziert die, garantiert.
...und dann sind auch die nicht Standardports dabei.
Außerdem wollen die meisten ja auch gefunden werden
frank_m24
IPPF-Urgestein
- Mitglied seit
- 20 Aug 2005
- Beiträge
- 20,448
- Punkte für Reaktionen
- 619
- Punkte
- 113
Die Liste wäre aber sehr unvollständig, denn die Suchmaschinen finden Domains ja auch nicht nach dem Zufallsprinzip, und die subdomains auf myfritz oder dyndns werden ja nicht veröffentlicht. Das sind also alles nur Domains, die über CNAMEs bekannt gemacht wurden. Du kannst ja mal versuchen, deine myfritz oder dyndns Domains bei google zu finden.
kleinkariert
Aktives Mitglied
- Mitglied seit
- 21 Mai 2019
- Beiträge
- 2,310
- Punkte für Reaktionen
- 389
- Punkte
- 83
Man wartet darauf, dass hier jemand "0.04.22 10:56:13 Anmeldung des Benutzers [email protected]" zitiert.
Damit wäre Punkt 1 aus dem manual for social engineering schon mal erledigt.
Alles läuft etwa wie Schiffeversenken oder die super Abmeldelinks für nie bestellte Newsletter.
Damit wäre Punkt 1 aus dem manual for social engineering schon mal erledigt.
Alles läuft etwa wie Schiffeversenken oder die super Abmeldelinks für nie bestellte Newsletter.
PeterPawn
IPPF-Urgestein
- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,300
- Punkte für Reaktionen
- 1,761
- Punkte
- 113
Man muß da einiges sauberer auseinanderhalten, als das (nach meinem Verständnis) bisher hier erfolgt ist.
Denn die Tatsache, DASS ein nach außen offener Port für den Zugriff auf die Benutzeroberfläche der Box nur unter Benutzung von TLS-gesicherten Verbindungen möglich ist, ist Fluch und Segen zugleich (und EINEN Tod muß man nun mal sterben).
Wer möchte, kann ja mal seiner FRITZ!Box von der WAN-Seite nicht nur mit
Kurzer Einschub zur "Theorie" von TLS und verschlüsselten Verbindungen:
Basis so einer TLS-Verbindung (mit "authentifiziertem Server" (per "Zertifikat") und "anonymous client" -> HTTP-Browser bzw. eben "tool" zum Testen von TLS-Verbindungen) ist eine Möglichkeit, das Gegenüber zu identifizieren (hier also den Server, die FRITZ!Box) und daher hat der/die für die Verschlüsselung von Daten (hier erst mal nur für den Austausch von "Zahlen", mit denen dann später die "richtigen" Daten verschlüsselt werden) einen privaten und einen öffentlichen Schlüssel.
Die Theorie dabei ist es, daß mit dem einen Schlüssel codierte Daten nur mit dem anderen Teil wieder decodiert werden können ... wenn man also etwas mit dem öffentlichen Schlüssel des Servers "verschleiert" hat, kann das nur mit dem privaten Schlüssel wieder "entschleiert" werden ("ver- und entschleiert" sind eigentlich nicht korrekt, aber im Deutschen gibt es bei diesem Thema einfach zuviel "schlüssel" als Wortstamm mit durchaus unterschiedlichen Bedeutungen *) und umgekehrt. Daher WEISS man dann auch, daß Daten, die sich mit dem öffentlichen Schlüssel decodieren lassen, mit dem richtigen privaten Schlüssel codiert wurden und da der private Schlüssel - wie der Name schon besagt - NICHT in der Öffentlichkeit bekannt sein DARF, weiß man dann auch automatisch, daß sie "vom Richtigen" stammen müssen.
Der öffentliche Schlüssel kann (nein: MUSS) hingegen bekannt sein und genau der ist es auch, der in einem X.509-Zertifikat "beglaubigt" wird, wobei gleichzeitig in so einem Zertifikat noch enthalten ist, FÜR WEN das eigentlich ausgestellt wurde und wer das damit (plausibel) "vorzeigen" könnte, um seine Identität zu sichern (quasi ein "Ausweis" für Websites). Manchmal - wenn's paßt bzw. es keine andere Möglichkeit gibt - geht die FRITZ!Box auch hin und bastelt sich mit ihrem Stempelkasten einen eigenen "Ausweis", den man aber schon auf den ersten Blick als "Fälschung" entlarven kann, weil sie gleichzeitig auch noch der "Aussteller" dafür ist ... das ist dann ein "self-signed certificate" und überall dort anzutreffen, wo der Server, für den dieser "öffentliche Schlüssel" beglaubigt werden soll, einen "nicht verifizierten Namen" verwendet - wie z.B. das
Da JEDE FRITZ!Box der Ansicht ist, so zu heißen und gleichzeitig auch JEDE FRITZ!Box erst einmal ihr eigenes "Schlüsselpaar" generiert (also einen "privaten" und einen "öffentlichen" Teil, wobei der öffentliche Part auch gleichzeitig im privaten Key enthalten ist), gäbe es dann ja für den Hostnamen
* - Verschlüsseln, Entschlüsseln, private und öffentliche Schlüssel, etc. - im Englischen ist das mit "key" (für "den Schlüssel" und "encryption / decryption" (fürs Ver- und Entschlüsseln) nicht ganz so ähnlich.
Aber das nur kurz zur Theorie ... wie sieht das jetzt in der Praxis aus?
Dafür kann man z.B. das CLI-Tool aus dem OpenSSL-Paket nehmen, das gibt es praktisch in FAST JEDER Linux-Installation (auch AVM hat - etwas "abgerüstete" - Versionen in der Firmware, mit der genau die oben erwähnten, selbst "unterschriebenen" Zertifikate erstellt werden) und auch eine Windows-Version müßte irgendwo verfügbar sein, wenn jemand kein (eigenes) Linux hat (andere OS lasse ich mal außen vor, aber auch die angebissene Ananas kann da mitspielen und andere *nix-Systeme, etc.) - wichtig ist nur, daß man ein "ausgewachsenes" Binary für die eigene Shell hat.
Damit kann man dann auch Kontakt mit (der WAN-Schnittstelle) der eigenen FRITZ!Box aufnehmen, WENN man den Zugriff auf das AVM-GUI von dieser "Seite" des Routers aufgemacht hat. Das verwendete Kommando dient dann eigentlich dazu, da einen "Mantel" um zu übertragende Daten zu legen, indem diese in einem aufgebauten Tunnel (das ist die TLS-gesicherte Verbindung) gesendet werden. Da hier das Ziel aber keine echte Kommunikation ist, wird einfach eine leere Zeile gesendet und die Verbindung danach wieder geschlossen (das ist das
Mit dem Parameter
Die Option
, kann ein weiterer Aufruf des OpenSSL-Programms verwendet werden, um die im Zertifikat beglaubigten Adressen anzeigen zu lassen - das ist (später) der dritte Aufruf in der Pipeline:
Das ist also die "unverarbeitete" Ausgabe - beim Zugriff auf den AVM-Server (und nicht auf (m)eine FRITZ!Box, obwohl das Prinzip dasselbe bleibt). Hängen wir jetzt noch das "Dekodieren" des ersten Zertifikats mit in die Pipeline:
Für welche "Eigenschaften" des sich ausweisenden Servers ein Zertifikat ausgestellt wurde, steht entweder in seinem "common name" (CN) oder in den "erweiterten Attributen" als "X509v3 Subject Alternative Name" ... jeder Eintrag an einer dieser beiden Stellen kann ein DNS-Name oder auch eine IP-Adresse sein (bei einem Server, es gäbe weitere Properties für andere Zwecke).
Und jetzt kann das jeder, der neugierig geworden sein sollte, ja mal mit seiner FRITZ!Box machen und dabei sowohl deren "externe" Schnittstelle (da geht NUR HTTPS, ggf. mit abweichendem Port) und auch die "interne" Schnittstelle (da geht zwar auch HTTP ohne TLS (hoffentlich nur "noch", weil AVM das auch bald in Angriff nimmt), aber dafür hängt der TLS-Server da auch wieder am Standardport 443) befragen.
Ich kann hier natürlich nur meine eigenen Ergebnisse zusammenfassen (getestet gegen eine 7590 im LAN, mit öffentlicher IPv6, MyFRITZ!-Account und IPv4 (für die WAN-Schnittstelle) vom "echten" Gateway (Firmware 07.39-irgendwas) und gegen eine 7580 an einem DualStack-DSL-Anschluß von 1&1, Firmware 07.29), aber die dürften bei anderen auch nicht anders aussehen.
Die 7580 weist sich (obwohl sie sogar ein LE-Zertifikat für ihre Subdomain in
Spätestens das sollte dann auch die Frage beantworten können, wie GENAU ein "Angreifer" jetzt an die (ach so geheimen - und das ist nicht "böse" gemeint, denn auch wenn @frank_m24 hier im Moment zwar der Einzige ist, der das Ermitteln dieser Daten als Problem sieht, man findet diese Argumentation ja durchaus öfter) DNS-Namen kommen könnte, die ja - gerade beim MyFRITZ!-Namen - sonst niemand kennen würde und die nur schwer "zu erraten" sind.
Wie sich jeder selbst überzeugen kann, geht die FRITZ!Box aber ihrerseits mit diesen Informationen sehr großzügig um und daher ist es - wenn man erst mal eine FRITZ!Box "identifiziert" hat ... und dann ändert sich i.d.R. auch nur noch ihre IP-Adresse und nicht mehr die Port-Nummer - nicht wirklich schwer, diese Geräte auch mit "smart attacks" anzugehen, wenn man erst einmal den MyFRITZ!-Namen erfahren hat. Dann findet man die (sofern der Dienst weiterhin benutzt wird und an dem MyFRITZ!-Dienst an sich hängen eben noch viele andere Funktionen, künftig wohl auch die TTS für die Anrufer-Informationen) auch einigermaßen problemlos wieder in den Weiten des Internets ... zumindest so lange, wie sie einen Port offen haben.
Stellt sich aber immer noch die Frage, wie genau das jetzt zum Problem werden sollte. Die Tatsache, daß da im FRITZ!OS jetzt solche "Anmeldeversuche" protokolliert werden, heißt ja noch lange nicht, daß es solche Versuche früher, als die eben noch NICHT protokolliert wurden, nicht gegeben hätte. Eigentlich müßte sich jeder FRITZ!Box-Besitzer sogar diebisch freuen, daß da wieder ein Angreifer an den Sicherheitsmechanismen "seiner" FRITZ!Box gescheitert ist und eben NICHT in die Box gelangen konnte.
Mal abgesehen davon, daß es auch zum kleinen Einmaleins für "Administratoren" gehört, tatsächlich nur die Dienste auch für den Zugriff aus dem Internet freizugeben, die auch wirklich benötigt werden ... was bringt es denn, wenn man jetzt einfach alles nur noch "per VPN" in das LAN gelangen läßt? Zumindest was "eingehende Verbindungen" anbelangt, denn ausgehend wird ja nur das überwacht, was in der "Filterung" (aka Kindersicherung) hängen bleiben soll - und das ist auch primär eine Filterung auf IP-Adressen und HTML-Inhalte und nur selten eine Überwachung weiterer Ports. Wie sichert dann aber die Tatsache, daß da der HTTPS-Port "nach außen" (egal ob auf 443 oder irgendeinem anderen, zufälligen Port) geschlossen bleibt, gegen genau den gleichen "Angriff" von innen, bei dem dann halt IRGENDEIN Gerät im LAN, auf das der Angreifer Zugriff erlangen konnte, als "relay" genutzt wird?
Und da gibt es (mittlerweile) in praktisch jedem Haushalt deutlich mehr Geräte mit deutlich geringeren Sicherheitsvorkehrungen als in einer FRITZ!Box ... die "Aufzählung" solcher Geräte habe ich schon mehrfach vorgenommen und sie wird praktisch mit jeder Woche länger (und mit jedem Gerät, was vom Hersteller nicht mehr mit Updates versorgt, aber dennoch weiterhin genutzt wird, auch wieder "gefährlicher").
Der einzig plausible UND sichere Weg ist es also, die ANMELDUNG an diesen Diensten (sowohl von innen als auch von außen) so sicher zu gestalten, daß sich der Angreifer DARAN dann die Zähne ausbeißt (und das wirkt dann automatisch für ALLE Angriffsversuche) ... das konnte man aber bisher in diesem Thread nur einmal lesen (in #23) und man kann nur hoffen, daß es von niemand anderem erwähnt wurde, WEIL es so selbstverständlich sein sollte.
Wenn aber der Dienst (hier halt die Anmeldung am FRITZ!OS-GUI - das ist ja auch nicht nur das "Admin-Interface", sondern ebenso das MyFRITZ!-GUI und das FRITZ!NAS) ausreichend sicher ist, daß er nach innen gegen Angriffe absichert, wieso sollte er das nach außen dann irgendwie "schlechter" umsetzen? Es war ja bisher sogar so, daß der Dienst bei AVM "von außen" BESSER abgesichert war, weil die Anmeldemaske "von innen" auch gleich noch die Benutzernamen für die Administrator-Konten mit ausspuckt (in der nächsten Version wird man das ja glücklicherweise deaktivieren können), womit die eine Hälfte des "Rätsels" aus Benutzername und Kennwort schon gelöst wäre.
Ja, eine VPN-Verbindung KANN eine Lösung sein ... aber auch längst nicht für alles. Es gibt sogar Anwendungsfälle, wo sie geradezu kontraindiziert wäre. Ein Beispiel wäre eine Dateifreigabe für einen Dritten (diese Funktion gibt es ja auch im FRITZ!OS - sogar mit Beschränkung der Anzahl möglicher Abrufe), weil meinetwegen ein (nicht für die Öffentlichkeit bestimmter, also auch nicht über irgendwelche "File-Sharer" bereitzustellender) Anhang per E-Mail nicht verschickt werden konnte.
Dafür will man sicherlich demjenigen, der auf diese Datei zugreifen will, jetzt nicht gleich eine VPN-Verbindung einrichten, die ihm dann auch (ohne zusätzliche Maßnahmen und eigentlich auch nicht ohne zusätzliche Hardware bzw. in die "Lösung" zu integrierende Clients im LAN, wenn man mit "Port- oder Geräteisolation" arbeiten wollte, was AVM m.W. aber auch nur bei LAN-LAN-Kopplung unterstützt ... und wenn das anders sein sollte, ist es immer noch "außerhalb der betrachteten Aufgabenstellung") wieder den Zugriff auf das GESAMTE LAN bietet. Wie gesagt, nur EIN Beispiel ... es gibt garantiert noch weitere (auch durchaus plausible).
Was ist es dann doch für eine Erleichterung zu wissen, DASS das AVM-GUI auch dann sicher ist (einigermaßen zumindest, solange niemand das Gegenteil beweisen kann), wenn man den externen Zugriff auf das GUI zuläßt. Solange da dann nicht steht: "Anmeldung des Benutzers xyz von der externen IP-Adresse ... erfolgreich (Anm.: editiert, fehlte)" und man sicher weiß, daß man das nicht selbst war. "Unbekannte" Benutzernamen sollte es da ja per se nicht geben und eine "saubere" Umsetzung eines Berechtigungskonzepts (durch den Administrator) sorgt auch dafür, daß da nicht wirklich JEDES Familienmitglied gleich auch noch einen Admin-Account hat - DAS verringert dann auch wieder die Angriffsfläche (und auch in meinen Augen sinnvoll), während ein "nur mit VPN" per se soo viele Anwendungsfälle ausschließt (inkl. der meisten AVM-eigenen Apps für Android und iOS - und es ist nun mal ein Fakt, daß es Leute gibt, welche die auch benutzen WOLLEN), daß man damit die Box selbst kastriert.
Und das alles nur aus der Angst heraus, es könnte da irgendein Sicherheitsproblem in der Anmeldung an der Oberfläche geben? Wer sagt denn eigentlich, daß ein solches Problem bei der VPN-Benutzung NICHT auftreten kann?
Weil VPNs per se "sicher" sind? Ich empfehle da einfach mal den Blick in die "CVE-Liste" (was das ist, findet jeder selbst heraus): https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=VPN
Ich verstehe ja noch, wenn jemand nicht UNNÖTIGE Ports nach außen öffnen will - DAS wäre tatsächlich dämlich. Aber man muß auch Augenmaß wahren bei der eigenen Sicherheit - und sollte sich auf die tatsächlichen Gefahren konzentrieren. Wenn IRGENDJEMAND auf einem Gerät innerhalb des (W)LANs eine Nachricht mit einer Malware so öffnet, daß diese auch gestartet wird (von Lücken in PDF-Readern bis zu aktivierten Makros in Office-Dokumenten (egal in welchem Office-Paket) oder auch Lücken in Web-Browsern, durch die Schadcode (mit Zugriff auf das System) eingeschleust werden kann), dann ist das VIEL gefährlicher als ein vergeblicher(!) Anmeldeversuch in einem sauber implementierten Login-Formular.
DAS ist auch heute noch der bevorzugte und am häufigsten erfolgreiche Angriff - irgendwelche "automatisch auszunutzenden Lücken" (als "0days") sprechen sich viel zu schnell herum, werden als "Thema" viel zu groß (Beispiel: https://www.google.com/search?q=apple+0day) und damit auch häufig schneller gefixt, als ein (systematisch arbeitender) Angreifer damit etwas anfangen kann. Ein Vorgehen über selbst geschaffene "relays" INNERHALB eines fremden Netzes ist auch nichts wirklich Neues ... das ist seit (mind.) 15 Jahren immer wieder ein Thema (als RAT - Remote Access Trojans) und schon 2011 gab es ein paar sehr interessante Einblicke, WIE solche Angreifer dann wirklich arbeiten (Stichwort für die eigenen Internetsuche: "Operation Shady RAT").
Was will ich damit zum Ausdruck bringen? Braucht man sich gar nicht mehr um die Sicherheit seines "Edge-Routers" zu sorgen? Natürlich ist es das NICHT ... nur bringt es eben auch nichts, wenn man sich gegen die 1% der "unwahrscheinlichen Angriffe" absichert und dann schlägt es auf eine Art und Weise ein, wie das bei jedem fünften Angriff (das wären dann 20%) der Fall ist. Wer sich - NUR um einem einzigen geöffneten Port in "seiner Firewall" aus dem Weg zu gehen - weitere Komplexität in sein Netzwerk holt, der holt sich damit auch (automatisch) weitere Stellen für potentielle Angriffe ins Boot.
Als "Milchmädchenrechnung" könnte man sogar so weit gehen, daß man mit einem (unnötigen) VPN (ich nehme mal IPSec, WEIL das mit mehr offenen Ports arbeitet, als WireGuard) zwar einen offenen Port vermeidet (mit EINER Implementierung für die Account-Sicherheit), dafür aber drei andere Ports öffnen muß (UDP 500 / ESP - wobei ESP NICHT portbasiert ist, dafür muß da dann ALLES durchgelassen werden, wo IP-Adresse und Protokollnummer stimmen - und UDP 4500 für IPSec mit NAT-T) und die MÜSSEN auch alle drei zunächst mal auf unterschiedliche Art mit den empfangenen Daten umgehen, weil das jeweils etwas andere Formate sind, bis die Verarbeitung dann wieder zusammengeführt werden kann. Das sind dann auch dreimal soviele mögliche "Code-Flows", in denen entsprechende Fehler auftreten können.
Dennoch wird es einem eben auch ein VPN NICHT abnehmen, daß man die restlichen Dienste AUCH VON INNEN so absichern muß, daß auch ein Angreifer von DIESER Seite der "Firewall" absehbar keinen Erfolg haben wird. WENN man das also mit begrenzten Ressourcen "reviewen" wollte (also einer Untersuchung der Sicherheit unterzieht), dann wäre es doch viel logischer, wenn man ZUERST mal die fraglichen Dienste SELBST so absichert, daß weder ein externer NOCH ein interner Angreifer da etwas erreichen kann. Leider vergessen das aber viele (auch viele Profis) in ihrer "Planung" zu berücksichtigen - am Ende "freuen" sich dann wieder die Angreifer.
Wer noch ein Beispiel dafür haben will, WIE Angreifer in "berühmten Fällen" vorgegangen sind, der kann ja mal nach dem "Bundestags-Hack" suchen: https://www.heise.de/newsticker/mel...ags-wohl-heftiger-als-angenommen-2657344.html - das war (zumindest nach dem, was "man so hört und liest") auch kein offener Port für einen Dienst mit einer schwachen Absicherung gegen unberechtigte Logins, was da zum erfolgreichen Angriff wurde.
Irgendwie sind viele nach der "webcm"-Lücke in der AVM-Firmware in eine Art "Schock" gefallen (teils zu Recht, häufig aber auch etwas übertrieben) und trauen nun der Firmware nicht mehr so richtig über den Weg ... ich persönlich finde das ausgesprochen schade, auch WEIL ich die Firmware von AVM (nach einigen Korrekturen in den vergangenen Jahren, nicht nur in der Firmware, sondern (in Maßen und eigentlich in viel zu geringem Umfang) auch in der "Fehlerkultur" bei AVM) für eine der sichersten für "Consumer-Router" halte und das auch, OBWOHL sie viele Features bietet, die man bei anderen Modellen (für dieselbe Zielgruppe) so nicht findet.
Klar, man KANN sich im LAN seinen eigenen WireGuard-Server aufsetzen und man kann vielleicht in künftigen FRITZ!OS-Versionen auch gleich WireGuard benutzen (das wird auch wieder nicht für JEDEN AVM-Router gelten, der in freier Wildbahn noch mit FRITZ!OS 07.2x arbeitet und eben KEIN Update auf 07.50 (so soll das ja angeblich dann heißen) mehr erhalten wird) - nur ist das dann eben auch keine Lösung für JEDERMAN und ich glaube kaum, daß AVM tatsächlich als "Zielgruppe" diejenigen fest im Blick hat, die dann lieber eine solche Lösung selbst umsetzen ... dafür hat das FRITZ!OS dann wieder viel zuwenig Einstellmöglichkeiten für solche "Bastler".
Diesem "Rest" an FRITZ!Box-Benutzern sollte man aber (meine Meinung) nur dann auch ANGST machen, daß sie ständig "angegriffen" werden, wenn man das dann selbst RICHTIG einordnet. Denn was wäre denn die Alternative, wenn AVM diese Meldungen NICHT anzeigt?
Über den FTP-Server konnte man über Jahre auch gezielte Brute-Force-Attacken auf einen Account fahren, weil es einen Weg gab, die exponentielle Steigerung der "penalty" in Form einer zu wartenden Zeit vor dem nächsten Login-Versuch zu umgehen - dafür brauchte es nur einen anderen Account, mit dem man sich anmelden konnte. Wenn da also der Filius (oder auch die Filia, das ist kein ausschließlich "männliches" Problem) Zugriff auf den NAS-Speicher hatte (als "berechtigter User"), dann konnte er mit diesem Account eine fröhliche Hetzjagd auf das elterliche Konto in der FRITZ!Box starten und zwar OHNE jegliche Protokollierung dieses Vorgehens und auch noch sehr effektiv (weil ein FTP-Login obendrein sehr schnell geht), wenn er einfach alle zwei, drei Fehlversuche wieder ein gültiges Login mit dem eigenen Account machte.
Das ist also ein weiteres Beispiel für einen "internen Angreifer" und längst nicht jeder "insider threat" basiert auf einem unvorsichtigen Insider (das wäre der Trojaner über die E-Mail), denn auch jemand, der gerne seine zeitlichen Limitierungen für die Internet-Nutzung übergehen würde, ist - in diesem Kontext - ein "böswilliger" Insider, der obendrein in den allermeisten Fällen auch noch deutlich mehr Infos über sein "Angriffsziel" hat (meinetwegen kennt er den Benutzernamen für das Admin-Konto und alle Geburtstage der gesamten Familie samt Initialen und selbst den Namen des Familienhundes), als irgendein "externer" Angreifer, der sich erst "vorarbeiten" muß.
Langer Rede kurzes Fazit:
Man macht nur das auf, was man auch braucht ... dann aber bitte auch so, daß es Sinn ergibt und nicht von Beginn an durch die "Festlegung" auf ein bestimmtes Vorgehen (um wieder festzustellen, daß auch ein VPN nicht IMMER eine Lösung ist). Wenn ich "Angst" habe, daß ein "angebotener Dienst" nicht sicher genug für "das Internet" ist, dann sollte ich den auch nicht aus dem internen Netz heraus nutzen können - viel zu schnell hat ein (echter) Angreifer den dann halt auf einem anderen Weg erreicht. Und sei es, weil erst die VPN-Verbindung vom Smartphone dem Angreifer (in Gestalt einer App auf dem Gerät) den Zugriff auf das GESAMTE interne Netz ermöglichte, während der eigentlich freizugebende Dienst gerade mal das Abrufen irgendeiner Datei vom NAS ermöglicht hätte.
Denn die Tatsache, DASS ein nach außen offener Port für den Zugriff auf die Benutzeroberfläche der Box nur unter Benutzung von TLS-gesicherten Verbindungen möglich ist, ist Fluch und Segen zugleich (und EINEN Tod muß man nun mal sterben).
Wer möchte, kann ja mal seiner FRITZ!Box von der WAN-Seite nicht nur mit
ping oder ähnlichen "Spielereien" auf die Finger schauen, sondern dabei Tools "für Erwachsene" (und das schließt "erwachsene 'Hacker'" mit ein, im Gegensatz zu "Skript-Kids", wobei die mittlerweile auch fast ausgestorben sind, eben WEIL die echten Gauner ihre Frameworks inzwischen lieber selbst "monetarisieren", anstatt sie Kindern zum Spielen zu überlassen) verwendet, dann klärt sich so manches "Mysterium" um Domain-Namen und "intelligentes" (oder "smartes") Scannen auch recht schnell von selbst.Kurzer Einschub zur "Theorie" von TLS und verschlüsselten Verbindungen:
Basis so einer TLS-Verbindung (mit "authentifiziertem Server" (per "Zertifikat") und "anonymous client" -> HTTP-Browser bzw. eben "tool" zum Testen von TLS-Verbindungen) ist eine Möglichkeit, das Gegenüber zu identifizieren (hier also den Server, die FRITZ!Box) und daher hat der/die für die Verschlüsselung von Daten (hier erst mal nur für den Austausch von "Zahlen", mit denen dann später die "richtigen" Daten verschlüsselt werden) einen privaten und einen öffentlichen Schlüssel.
Die Theorie dabei ist es, daß mit dem einen Schlüssel codierte Daten nur mit dem anderen Teil wieder decodiert werden können ... wenn man also etwas mit dem öffentlichen Schlüssel des Servers "verschleiert" hat, kann das nur mit dem privaten Schlüssel wieder "entschleiert" werden ("ver- und entschleiert" sind eigentlich nicht korrekt, aber im Deutschen gibt es bei diesem Thema einfach zuviel "schlüssel" als Wortstamm mit durchaus unterschiedlichen Bedeutungen *) und umgekehrt. Daher WEISS man dann auch, daß Daten, die sich mit dem öffentlichen Schlüssel decodieren lassen, mit dem richtigen privaten Schlüssel codiert wurden und da der private Schlüssel - wie der Name schon besagt - NICHT in der Öffentlichkeit bekannt sein DARF, weiß man dann auch automatisch, daß sie "vom Richtigen" stammen müssen.
Der öffentliche Schlüssel kann (nein: MUSS) hingegen bekannt sein und genau der ist es auch, der in einem X.509-Zertifikat "beglaubigt" wird, wobei gleichzeitig in so einem Zertifikat noch enthalten ist, FÜR WEN das eigentlich ausgestellt wurde und wer das damit (plausibel) "vorzeigen" könnte, um seine Identität zu sichern (quasi ein "Ausweis" für Websites). Manchmal - wenn's paßt bzw. es keine andere Möglichkeit gibt - geht die FRITZ!Box auch hin und bastelt sich mit ihrem Stempelkasten einen eigenen "Ausweis", den man aber schon auf den ersten Blick als "Fälschung" entlarven kann, weil sie gleichzeitig auch noch der "Aussteller" dafür ist ... das ist dann ein "self-signed certificate" und überall dort anzutreffen, wo der Server, für den dieser "öffentliche Schlüssel" beglaubigt werden soll, einen "nicht verifizierten Namen" verwendet - wie z.B. das
fritz.box bei den AVM-Geräten.Da JEDE FRITZ!Box der Ansicht ist, so zu heißen und gleichzeitig auch JEDE FRITZ!Box erst einmal ihr eigenes "Schlüsselpaar" generiert (also einen "privaten" und einen "öffentlichen" Teil, wobei der öffentliche Part auch gleichzeitig im privaten Key enthalten ist), gäbe es dann ja für den Hostnamen
fritz.box soviele unterschiedliche Schlüssel und dafür ausgestellte Zertifikate, wie es Geräte gibt. Daß so etwas nicht funktionieren KANN, wenn man dafür "ordentlich ausgestellte Zertifikate" einer öffentlichen Zertifizierungsstelle benutzen würde, sollte einleuchtend sein - daher arbeitet die Box eben selbst auch mit diesen "self-signed certificates" ... wobei man die als Besitzer auch durch eigene Zertifikate ersetzen kann und wer diese dann "ausgestellt" hat, entscheidet man selbst.* - Verschlüsseln, Entschlüsseln, private und öffentliche Schlüssel, etc. - im Englischen ist das mit "key" (für "den Schlüssel" und "encryption / decryption" (fürs Ver- und Entschlüsseln) nicht ganz so ähnlich.
Aber das nur kurz zur Theorie ... wie sieht das jetzt in der Praxis aus?
Dafür kann man z.B. das CLI-Tool aus dem OpenSSL-Paket nehmen, das gibt es praktisch in FAST JEDER Linux-Installation (auch AVM hat - etwas "abgerüstete" - Versionen in der Firmware, mit der genau die oben erwähnten, selbst "unterschriebenen" Zertifikate erstellt werden) und auch eine Windows-Version müßte irgendwo verfügbar sein, wenn jemand kein (eigenes) Linux hat (andere OS lasse ich mal außen vor, aber auch die angebissene Ananas kann da mitspielen und andere *nix-Systeme, etc.) - wichtig ist nur, daß man ein "ausgewachsenes" Binary für die eigene Shell hat.
Damit kann man dann auch Kontakt mit (der WAN-Schnittstelle) der eigenen FRITZ!Box aufnehmen, WENN man den Zugriff auf das AVM-GUI von dieser "Seite" des Routers aufgemacht hat. Das verwendete Kommando dient dann eigentlich dazu, da einen "Mantel" um zu übertragende Daten zu legen, indem diese in einem aufgebauten Tunnel (das ist die TLS-gesicherte Verbindung) gesendet werden. Da hier das Ziel aber keine echte Kommunikation ist, wird einfach eine leere Zeile gesendet und die Verbindung danach wieder geschlossen (das ist das
echo am Beginn).Mit dem Parameter
-connect <hostname>:<port> kann man dann erst einmal festlegen, welche IP-Adresse und welchen Port das Ziel benutzt - das hat noch nichts zwingend mit einem "Server-Namen" zu tun, denn dafür gibt es einen gesonderten Parameter (eben -servername <name>), aus dem dann eine SNI (Server Name Indication) für den angesprochenen Server erzeugt wird, anhand welcher dieser dann entscheiden kann, WELCHES Zertifikat er für DIESEN Server-Namen verwenden will, wenn er mehrere Zertifikate (für unterschiedliche DNS-Namen (bzw. Server-Namen, das ist dann synonym in diesem Kontext) oder auch für ein und denselben Namen) haben sollte.Die Option
-showcerts zeigt dann die vom Server angebotenen Zertifikate an, wobei meistens mehr als eines übertragen wird, weil der Server i.d.R. auch alle Zertifikate der CAs (das sind die "Zertifizierungsstellen", die sein eigenes Zertifikat beglaubigt/unterschrieben haben) mit überträgt. Das erste Zertifikat in dieser Liste sollte aber immer das des Servers selbst sein und das kann man sich zunutze machen bei der Auswertung. Da diese Zertifikate dann mit entsprechenden Markierungen übertragen werden:
Rich (BBCode):
-----BEGIN CERTIFICATE-----
MIIFYDCCBEigAwIBAgIQQAF3ITfU6UK47naqPGQKtzANBgkqhkiG9w0BAQsFADA/
MSQwIgYDVQQKExtEaWdpdGFsIFNpZ25hdHVyZSBUcnVzdCBDby4xFzAVBgNVBAMT
DkRTVCBSb290IENBIFgzMB4XDTIxMDEyMDE5MTQwM1oXDTI0MDkzMDE4MTQwM1ow
TzELMAkGA1UEBhMCVVMxKTAnBgNVBAoTIEludGVybmV0IFNlY3VyaXR5IFJlc2Vh
cmNoIEdyb3VwMRUwEwYDVQQDEwxJU1JHIFJvb3QgWDEwggIiMA0GCSqGSIb3DQEB
AQUAA4ICDwAwggIKAoICAQCt6CRz9BQ385ueK1coHIe+3LffOJCMbjzmV6B493XC
ov71am72AE8o295ohmxEk7axY/0UEmu/H9LqMZshftEzPLpI9d1537O4/xLxIZpL
wYqGcWlKZmZsj348cL+tKSIG8+TA5oCu4kuPt5l+lAOf00eXfJlII1PoOK5PCm+D
LtFJV4yAdLbaL9A4jXsDcCEbdfIwPPqPrt3aY6vrFk/CjhFLfs8L6P+1dy70sntK
4EwSJQxwjQMpoOFTJOwT2e4ZvxCzSow/iaNhUd6shweU9GNx7C7ib1uYgeGJXDR5
bHbvO5BieebbpJovJsXQEOEO3tkQjhb7t/eo98flAgeYjzYIlefiN5YNNnWe+w5y
sR2bvAP5SQXYgd0FtCrWQemsAXaVCg/Y39W9Eh81LygXbNKYwagJZHduRze6zqxZ
Xmidf3LWicUGQSk+WT7dJvUkyRGnWqNMQB9GoZm1pzpRboY7nn1ypxIFeFntPlF4
FQsDj43QLwWyPntKHEtzBRL8xurgUBN8Q5N0s8p0544fAQjQMNRbcTa0B7rBMDBc
SLeCO5imfWCKoqMpgsy6vYMEG6KDA0Gh1gXxG8K28Kh8hjtGqEgqiNx2mna/H2ql
PRmP6zjzZN7IKw0KKP/32+IVQtQi0Cdd4Xn+GOdwiK1O5tmLOsbdJ1Fu/7xk9TND
TwIDAQABo4IBRjCCAUIwDwYDVR0TAQH/BAUwAwEB/zAOBgNVHQ8BAf8EBAMCAQYw
SwYIKwYBBQUHAQEEPzA9MDsGCCsGAQUFBzAChi9odHRwOi8vYXBwcy5pZGVudHJ1
c3QuY29tL3Jvb3RzL2RzdHJvb3RjYXgzLnA3YzAfBgNVHSMEGDAWgBTEp7Gkeyxx
+tvhS5B1/8QVYIWJEDBUBgNVHSAETTBLMAgGBmeBDAECATA/BgsrBgEEAYLfEwEB
ATAwMC4GCCsGAQUFBwIBFiJodHRwOi8vY3BzLnJvb3QteDEubGV0c2VuY3J5cHQu
b3JnMDwGA1UdHwQ1MDMwMaAvoC2GK2h0dHA6Ly9jcmwuaWRlbnRydXN0LmNvbS9E
U1RST09UQ0FYM0NSTC5jcmwwHQYDVR0OBBYEFHm0WeZ7tuXkAXOACIjIGlj26Ztu
MA0GCSqGSIb3DQEBCwUAA4IBAQAKcwBslm7/DlLQrt2M51oGrS+o44+/yQoDFVDC
5WxCu2+b9LRPwkSICHXM6webFGJueN7sJ7o5XPWioW5WlHAQU7G75K/QosMrAdSW
9MUgNTP52GE24HGNtLi1qoJFlcDyqSMo59ahy2cI2qBDLKobkx/J3vWraV0T9VuG
WCLKTVXkcGdtwlfFRjlBz4pYg1htmf5X6DYO8A4jqv2Il9DjXA6USbW1FzXSLr9O
he8Y4IWS6wY7bCkjCWDcRQJMEhg76fsO3txE+FiYruq9RUWhiF1myv4Q6W+CyBFC
Dfvp7OOGAN6dEOM4+qR9sdjoSYKEBpsr6GtPAQw4dy753ec5
-----END CERTIFICATE-----
Rich (BBCode):
peh@vidar:/tmp/7590> dig www.avm.de a
; <<>> DiG 9.16.25 <<>> www.avm.de a
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63992
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: af5fb530d8f585330100000062543f9f8c7278d63173ffda (good)
;; QUESTION SECTION:
;www.avm.de. IN A
;; ANSWER SECTION:
www.avm.de. 3515 IN A 212.42.244.122
;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mon Apr 11 16:47:59 CEST 2022
;; MSG SIZE rcvd: 83
peh@vidar:/tmp/7590> echo | openssl s_client -showcerts -connect 212.42.244.122:443
CONNECTED(00000003)
Can't use SSL_get_servername
depth=2 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global Root CA
verify return:1
depth=1 C = US, O = DigiCert Inc, CN = DigiCert TLS RSA SHA256 2020 CA1
verify return:1
depth=0 C = DE, L = Berlin, O = AVM Computersysteme Vertriebs GmbH, CN = *.avm.de
verify return:1
---
Certificate chain
0 s:C = DE, L = Berlin, O = AVM Computersysteme Vertriebs GmbH, CN = *.avm.de
i:C = US, O = DigiCert Inc, CN = DigiCert TLS RSA SHA256 2020 CA1
-----BEGIN CERTIFICATE-----
MIIGqjCCBZKgAwIBAgIQDlRAblYYp9PSEqZSKkMlTjANBgkqhkiG9w0BAQsFADBP
MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMSkwJwYDVQQDEyBE
aWdpQ2VydCBUTFMgUlNBIFNIQTI1NiAyMDIwIENBMTAeFw0yMjAyMjIwMDAwMDBa
Fw0yMzAzMjUyMzU5NTlaMF4xCzAJBgNVBAYTAkRFMQ8wDQYDVQQHEwZCZXJsaW4x
KzApBgNVBAoTIkFWTSBDb21wdXRlcnN5c3RlbWUgVmVydHJpZWJzIEdtYkgxETAP
BgNVBAMMCCouYXZtLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA
uLSj6eXEyD7YXZuRRylnO05G0duK9z2NciWMwc0ciYjIA/CsPIgX34RirhG2OBUx
BBRoNY1W99TzBAL035LYVu/k7Eaj3cmg52twslyjY/dewj4UvXmC6g4fhXvAr+BG
dwETmKEDrL5iVPPWmLwgtgP4GDyU1lgSCJFrYwsZlm0G7IURJLpdJpUbZP88gNqn
DolODueh0fmmQGTv2NrSuoWAAZNdPz3euobVycG6lRzSH4FTTWD29bVUeKJCDkQq
jz/PeJSq4ojLtcsDTH8SAUJC4J/BGtxNCkUfOZxHX9ojO5A7e3W1L2GJEq2d7iS/
eKInEG1xw5NZIhOmqmlEwQIDAQABo4IDcTCCA20wHwYDVR0jBBgwFoAUt2ui6qiq
hIx56rTaD5iyxZV2ufQwHQYDVR0OBBYEFC4M2uFmkOF6xuo2u+sBKQSoP2zyMBsG
A1UdEQQUMBKCCCouYXZtLmRlggZhdm0uZGUwDgYDVR0PAQH/BAQDAgWgMB0GA1Ud
JQQWMBQGCCsGAQUFBwMBBggrBgEFBQcDAjCBjwYDVR0fBIGHMIGEMECgPqA8hjpo
dHRwOi8vY3JsMy5kaWdpY2VydC5jb20vRGlnaUNlcnRUTFNSU0FTSEEyNTYyMDIw
Q0ExLTQuY3JsMECgPqA8hjpodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNl
cnRUTFNSU0FTSEEyNTYyMDIwQ0ExLTQuY3JsMD4GA1UdIAQ3MDUwMwYGZ4EMAQIC
MCkwJwYIKwYBBQUHAgEWG2h0dHA6Ly93d3cuZGlnaWNlcnQuY29tL0NQUzB/Bggr
BgEFBQcBAQRzMHEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNv
bTBJBggrBgEFBQcwAoY9aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0RpZ2lD
ZXJ0VExTUlNBU0hBMjU2MjAyMENBMS0xLmNydDAJBgNVHRMEAjAAMIIBfwYKKwYB
BAHWeQIEAgSCAW8EggFrAWkAdwDoPtDaPvUGNTLnVyi8iWvJA9PL0RFr7Otp4Xd9
bQa9bgAAAX8iKpntAAAEAwBIMEYCIQCiEo7UxxJ0VYzx4UbF5A9KtPxTMQbpmaVH
QnMWoMjKUQIhALzoxcNd6BLaNWalpSh869ENqNJYo4n0e1WUBf+5FJmuAHcANc8Z
G7+xbFe/D61MbULLu7YnICZR6j/hKu+oA8M71kwAAAF/IiqaNAAABAMASDBGAiEA
wQcuOWRE0PO2sdQHGCDNiIRA8W963nc6g84MLz0VNjUCIQD90snNX7NhjDVq5DPx
mT2ZyBde7+vBKxF7hj1aZoV0HAB1ALNzdwfhhFD4Y4bWBancEQlKeS2xZwwLh9zw
Aw55NqWaAAABfyIqml4AAAQDAEYwRAIgc1lQy4c/3mK/w6QqGlsIte1TB/qEpnE0
w0jqLm46zi4CIBtGPVbqONqxajhAdCByoBlev8YNfli9kaE3rY4FTuHmMA0GCSqG
SIb3DQEBCwUAA4IBAQAlrfFZNv/WRlRhZ5/kta/BZ7nWShEa1iSn2c/1UvpY43n0
dndVk5jzfTd4BERlrh/LpSip/G9n+KH7HW2LkQa6GT4TB2+pfaMscuPoW5Lt6GGu
jbtGmTDML0+E2sYds2LpNp60RPAuYifi2gWlFQWt8otzLOZx7qKH4WD2x5Nxzjgf
nB7PLN8N5kTJFcDByRhGLRUjHY0WnpzLtaPypV4wk8LJg1VApb07S9rXVuzdRmqA
QxcXNncXds7c8kpoeJtO77M1vojF+zHW2OcwglYdkw8fANgSgUwPdpJQsC0IIIVy
Rwcdo2nBmeE5cW1VGf9Mc17uuIUlCnYXofjZss5G
-----END CERTIFICATE-----
1 s:C = US, O = DigiCert Inc, CN = DigiCert TLS RSA SHA256 2020 CA1
i:C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global Root CA
-----BEGIN CERTIFICATE-----
MIIEvjCCA6agAwIBAgIQBtjZBNVYQ0b2ii+nVCJ+xDANBgkqhkiG9w0BAQsFADBh
MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3
d3cuZGlnaWNlcnQuY29tMSAwHgYDVQQDExdEaWdpQ2VydCBHbG9iYWwgUm9vdCBD
QTAeFw0yMTA0MTQwMDAwMDBaFw0zMTA0MTMyMzU5NTlaME8xCzAJBgNVBAYTAlVT
MRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxKTAnBgNVBAMTIERpZ2lDZXJ0IFRMUyBS
U0EgU0hBMjU2IDIwMjAgQ0ExMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC
AQEAwUuzZUdwvN1PWNvsnO3DZuUfMRNUrUpmRh8sCuxkB+Uu3Ny5CiDt3+PE0J6a
qXodgojlEVbbHp9YwlHnLDQNLtKS4VbL8Xlfs7uHyiUDe5pSQWYQYE9XE0nw6Ddn
g9/n00tnTCJRpt8OmRDtV1F0JuJ9x8piLhMbfyOIJVNvwTRYAIuE//i+p1hJInuW
raKImxW8oHzf6VGo1bDtN+I2tIJLYrVJmuzHZ9bjPvXj1hJeRPG/cUJ9WIQDgLGB
Afr5yjK7tI4nhyfFK3TUqNaX3sNk+crOU6JWvHgXjkkDKa77SU+kFbnO8lwZV21r
eacroicgE7XQPUDTITAHk+qZ9QIDAQABo4IBgjCCAX4wEgYDVR0TAQH/BAgwBgEB
/wIBADAdBgNVHQ4EFgQUt2ui6qiqhIx56rTaD5iyxZV2ufQwHwYDVR0jBBgwFoAU
A95QNVbRTLtm8KPiGxvDl7I90VUwDgYDVR0PAQH/BAQDAgGGMB0GA1UdJQQWMBQG
CCsGAQUFBwMBBggrBgEFBQcDAjB2BggrBgEFBQcBAQRqMGgwJAYIKwYBBQUHMAGG
GGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBABggrBgEFBQcwAoY0aHR0cDovL2Nh
Y2VydHMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0R2xvYmFsUm9vdENBLmNydDBCBgNV
HR8EOzA5MDegNaAzhjFodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vRGlnaUNlcnRH
bG9iYWxSb290Q0EuY3JsMD0GA1UdIAQ2MDQwCwYJYIZIAYb9bAIBMAcGBWeBDAEB
MAgGBmeBDAECATAIBgZngQwBAgIwCAYGZ4EMAQIDMA0GCSqGSIb3DQEBCwUAA4IB
AQCAMs5eC91uWg0Kr+HWhMvAjvqFcO3aXbMM9yt1QP6FCvrzMXi3cEsaiVi6gL3z
ax3pfs8LulicWdSQ0/1s/dCYbbdxglvPbQtaCdB73sRD2Cqk3p5BJl+7j5nL3a7h
qG+fh/50tx8bIKuxT8b1Z11dmzzp/2n3YWzW2fP9NsarA4h20ksudYbj/NhVfSbC
EXffPgK2fPOre3qGNm+499iTcc+G33Mw+nur7SpZyEKEOxEXGlLzyQ4UfaJbcme6
ce1XR2bFuAJKZTRei9AqPCCcUZlM51Ke92sRKw2Sfh3oius2FkOH6ipjv3U/697E
A7sKPPcw7+uvTPyLNhBzPvOk
-----END CERTIFICATE-----
---
Server certificate
subject=C = DE, L = Berlin, O = AVM Computersysteme Vertriebs GmbH, CN = *.avm.de
issuer=C = US, O = DigiCert Inc, CN = DigiCert TLS RSA SHA256 2020 CA1
---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 3489 bytes and written 381 bytes
Verification: OK
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 2048 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---
DONE
peh@vidar:/tmp/7590>
Rich (BBCode):
peh@vidar:/tmp/7590> echo | openssl s_client -showcerts -connect 212.42.244.122:443 -servername www.avm.de | openssl x509 -noout -text
Can't use SSL_get_servername
depth=2 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global Root CA
verify return:1
depth=1 C = US, O = DigiCert Inc, CN = DigiCert TLS RSA SHA256 2020 CA1
verify return:1
depth=0 C = DE, L = Berlin, O = AVM Computersysteme Vertriebs GmbH, CN = *.avm.de
verify return:1
DONE
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
0e:54:40:6e:56:18:a7:d3:d2:12:a6:52:2a:43:25:4e
Signature Algorithm: sha256WithRSAEncryption
Issuer: C = US, O = DigiCert Inc, CN = DigiCert TLS RSA SHA256 2020 CA1
Validity
Not Before: Feb 22 00:00:00 2022 GMT
Not After : Mar 25 23:59:59 2023 GMT
Subject: C = DE, L = Berlin, O = AVM Computersysteme Vertriebs GmbH, CN = *.avm.de
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public-Key: (2048 bit)
Modulus:
00:b8:b4:a3:e9:e5:c4:c8:3e:d8:5d:9b:91:47:29:
67:3b:4e:46:d1:db:8a:f7:3d:8d:72:25:8c:c1:cd:
1c:89:88:c8:03:f0:ac:3c:88:17:df:84:62:ae:11:
b6:38:15:31:04:14:68:35:8d:56:f7:d4:f3:04:02:
f4:df:92:d8:56:ef:e4:ec:46:a3:dd:c9:a0:e7:6b:
70:b2:5c:a3:63:f7:5e:c2:3e:14:bd:79:82:ea:0e:
1f:85:7b:c0:af:e0:46:77:01:13:98:a1:03:ac:be:
62:54:f3:d6:98:bc:20:b6:03:f8:18:3c:94:d6:58:
12:08:91:6b:63:0b:19:96:6d:06:ec:85:11:24:ba:
5d:26:95:1b:64:ff:3c:80:da:a7:0e:89:4e:0e:e7:
a1:d1:f9:a6:40:64:ef:d8:da:d2:ba:85:80:01:93:
5d:3f:3d:de:ba:86:d5:c9:c1:ba:95:1c:d2:1f:81:
53:4d:60:f6:f5:b5:54:78:a2:42:0e:44:2a:8f:3f:
cf:78:94:aa:e2:88:cb:b5:cb:03:4c:7f:12:01:42:
42:e0:9f:c1:1a:dc:4d:0a:45:1f:39:9c:47:5f:da:
23:3b:90:3b:7b:75:b5:2f:61:89:12:ad:9d:ee:24:
bf:78:a2:27:10:6d:71:c3:93:59:22:13:a6:aa:69:
44:c1
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Authority Key Identifier:
keyid:B7:6B:A2:EA:A8:AA:84:8C:79:EA:B4:DA:0F:98:B2:C5:95:76:B9:F4
X509v3 Subject Key Identifier:
2E:0C:DA:E1:66:90:E1:7A:C6:EA:36:BB:EB:01:29:04:A8:3F:6C:F2
X509v3 Subject Alternative Name:
DNS:*.avm.de, DNS:avm.de
X509v3 Key Usage: critical
Digital Signature, Key Encipherment
X509v3 Extended Key Usage:
TLS Web Server Authentication, TLS Web Client Authentication
X509v3 CRL Distribution Points:
Full Name:
URI:http://crl3.digicert.com/DigiCertTLSRSASHA2562020CA1-4.crl
Full Name:
URI:http://crl4.digicert.com/DigiCertTLSRSASHA2562020CA1-4.crl
X509v3 Certificate Policies:
Policy: 2.23.140.1.2.2
CPS: http://www.digicert.com/CPS
Authority Information Access:
OCSP - URI:http://ocsp.digicert.com
CA Issuers - URI:http://cacerts.digicert.com/DigiCertTLSRSASHA2562020CA1-1.crt
X509v3 Basic Constraints:
CA:FALSE
CT Precertificate SCTs:
Signed Certificate Timestamp:
Version : v1 (0x0)
Log ID : E8:3E:D0:DA:3E:F5:06:35:32:E7:57:28:BC:89:6B:C9:
03:D3:CB:D1:11:6B:EC:EB:69:E1:77:7D:6D:06:BD:6E
Timestamp : Feb 22 16:01:31.629 2022 GMT
Extensions: none
Signature : ecdsa-with-SHA256
30:46:02:21:00:A2:12:8E:D4:C7:12:74:55:8C:F1:E1:
46:C5:E4:0F:4A:B4:FC:53:31:06:E9:99:A5:47:42:73:
16:A0:C8:CA:51:02:21:00:BC:E8:C5:C3:5D:E8:12:DA:
35:66:A5:A5:28:7C:EB:D1:0D:A8:D2:58:A3:89:F4:7B:
55:94:05:FF:B9:14:99:AE
Signed Certificate Timestamp:
Version : v1 (0x0)
Log ID : 35:CF:19:1B:BF:B1:6C:57:BF:0F:AD:4C:6D:42:CB:BB:
B6:27:20:26:51:EA:3F:E1:2A:EF:A8:03:C3:3B:D6:4C
Timestamp : Feb 22 16:01:31.700 2022 GMT
Extensions: none
Signature : ecdsa-with-SHA256
30:46:02:21:00:C1:07:2E:39:64:44:D0:F3:B6:B1:D4:
07:18:20:CD:88:84:40:F1:6F:7A:DE:77:3A:83:CE:0C:
2F:3D:15:36:35:02:21:00:FD:D2:C9:CD:5F:B3:61:8C:
35:6A:E4:33:F1:99:3D:99:C8:17:5E:EF:EB:C1:2B:11:
7B:86:3D:5A:66:85:74:1C
Signed Certificate Timestamp:
Version : v1 (0x0)
Log ID : B3:73:77:07:E1:84:50:F8:63:86:D6:05:A9:DC:11:09:
4A:79:2D:B1:67:0C:0B:87:DC:F0:03:0E:79:36:A5:9A
Timestamp : Feb 22 16:01:31.742 2022 GMT
Extensions: none
Signature : ecdsa-with-SHA256
30:44:02:20:73:59:50:CB:87:3F:DE:62:BF:C3:A4:2A:
1A:5B:08:B5:ED:53:07:FA:84:A6:71:34:C3:48:EA:2E:
6E:3A:CE:2E:02:20:1B:46:3D:56:EA:38:DA:B1:6A:38:
40:74:20:72:A0:19:5E:BF:C6:0D:7E:58:BD:91:A1:37:
AD:8E:05:4E:E1:E6
Signature Algorithm: sha256WithRSAEncryption
25:ad:f1:59:36:ff:d6:46:54:61:67:9f:e4:b5:af:c1:67:b9:
d6:4a:11:1a:d6:24:a7:d9:cf:f5:52:fa:58:e3:79:f4:76:77:
55:93:98:f3:7d:37:78:04:44:65:ae:1f:cb:a5:28:a9:fc:6f:
67:f8:a1:fb:1d:6d:8b:91:06:ba:19:3e:13:07:6f:a9:7d:a3:
2c:72:e3:e8:5b:92:ed:e8:61:ae:8d:bb:46:99:30:cc:2f:4f:
84:da:c6:1d:b3:62:e9:36:9e:b4:44:f0:2e:62:27:e2:da:05:
a5:15:05:ad:f2:8b:73:2c:e6:71:ee:a2:87:e1:60:f6:c7:93:
71:ce:38:1f:9c:1e:cf:2c:df:0d:e6:44:c9:15:c0:c1:c9:18:
46:2d:15:23:1d:8d:16:9e:9c:cb:b5:a3:f2:a5:5e:30:93:c2:
c9:83:55:40:a5:bd:3b:4b:da:d7:56:ec:dd:46:6a:80:43:17:
17:36:77:17:76:ce:dc:f2:4a:68:78:9b:4e:ef:b3:35:be:88:
c5:fb:31:d6:d8:e7:30:82:56:1d:93:0f:1f:00:d8:12:81:4c:
0f:76:92:50:b0:2d:08:20:85:72:47:07:1d:a3:69:c1:99:e1:
39:71:6d:55:19:ff:4c:73:5e:ee:b8:85:25:0a:76:17:a1:f8:
d9:b2:ce:46
peh@vidar:/tmp/7590>Und jetzt kann das jeder, der neugierig geworden sein sollte, ja mal mit seiner FRITZ!Box machen und dabei sowohl deren "externe" Schnittstelle (da geht NUR HTTPS, ggf. mit abweichendem Port) und auch die "interne" Schnittstelle (da geht zwar auch HTTP ohne TLS (hoffentlich nur "noch", weil AVM das auch bald in Angriff nimmt), aber dafür hängt der TLS-Server da auch wieder am Standardport 443) befragen.
Ich kann hier natürlich nur meine eigenen Ergebnisse zusammenfassen (getestet gegen eine 7590 im LAN, mit öffentlicher IPv6, MyFRITZ!-Account und IPv4 (für die WAN-Schnittstelle) vom "echten" Gateway (Firmware 07.39-irgendwas) und gegen eine 7580 an einem DualStack-DSL-Anschluß von 1&1, Firmware 07.29), aber die dürften bei anderen auch nicht anders aussehen.
Die 7580 weist sich (obwohl sie sogar ein LE-Zertifikat für ihre Subdomain in
myfritz.net hat) bei allen Server-Namen (Parameter -servername ist dann entsprechend zu setzen) mit demselben Zertifikat aus - sowohl "intern" als auch "extern" und NUR die Angabe des MyFRITZ!-Namens in der SNI führt dazu, daß sie auch tatsächlich das LE-Zertifikat verwendet. In dem (self-signed) Zertifikat, das nicht von LE stammt, sind enthalten: Im "subject" als CN der DynDNS-Name, den die Box erhalten hat (zusätzlich zum MyFRITZ!-Namen) und in den "alternative names": DNS:<dyndns_name>, DNS:<myfritz-subdomain>.myfritz.net, DNS:fritz.box, DNS:www.fritz.box, DNS:myfritz.box, DNS:www.myfritz.box, DNS:<fritzbox-name>, DNS:fritz.nas, DNS:www.fritz.nasSpätestens das sollte dann auch die Frage beantworten können, wie GENAU ein "Angreifer" jetzt an die (ach so geheimen - und das ist nicht "böse" gemeint, denn auch wenn @frank_m24 hier im Moment zwar der Einzige ist, der das Ermitteln dieser Daten als Problem sieht, man findet diese Argumentation ja durchaus öfter) DNS-Namen kommen könnte, die ja - gerade beim MyFRITZ!-Namen - sonst niemand kennen würde und die nur schwer "zu erraten" sind.
Wie sich jeder selbst überzeugen kann, geht die FRITZ!Box aber ihrerseits mit diesen Informationen sehr großzügig um und daher ist es - wenn man erst mal eine FRITZ!Box "identifiziert" hat ... und dann ändert sich i.d.R. auch nur noch ihre IP-Adresse und nicht mehr die Port-Nummer - nicht wirklich schwer, diese Geräte auch mit "smart attacks" anzugehen, wenn man erst einmal den MyFRITZ!-Namen erfahren hat. Dann findet man die (sofern der Dienst weiterhin benutzt wird und an dem MyFRITZ!-Dienst an sich hängen eben noch viele andere Funktionen, künftig wohl auch die TTS für die Anrufer-Informationen) auch einigermaßen problemlos wieder in den Weiten des Internets ... zumindest so lange, wie sie einen Port offen haben.
Stellt sich aber immer noch die Frage, wie genau das jetzt zum Problem werden sollte. Die Tatsache, daß da im FRITZ!OS jetzt solche "Anmeldeversuche" protokolliert werden, heißt ja noch lange nicht, daß es solche Versuche früher, als die eben noch NICHT protokolliert wurden, nicht gegeben hätte. Eigentlich müßte sich jeder FRITZ!Box-Besitzer sogar diebisch freuen, daß da wieder ein Angreifer an den Sicherheitsmechanismen "seiner" FRITZ!Box gescheitert ist und eben NICHT in die Box gelangen konnte.
Mal abgesehen davon, daß es auch zum kleinen Einmaleins für "Administratoren" gehört, tatsächlich nur die Dienste auch für den Zugriff aus dem Internet freizugeben, die auch wirklich benötigt werden ... was bringt es denn, wenn man jetzt einfach alles nur noch "per VPN" in das LAN gelangen läßt? Zumindest was "eingehende Verbindungen" anbelangt, denn ausgehend wird ja nur das überwacht, was in der "Filterung" (aka Kindersicherung) hängen bleiben soll - und das ist auch primär eine Filterung auf IP-Adressen und HTML-Inhalte und nur selten eine Überwachung weiterer Ports. Wie sichert dann aber die Tatsache, daß da der HTTPS-Port "nach außen" (egal ob auf 443 oder irgendeinem anderen, zufälligen Port) geschlossen bleibt, gegen genau den gleichen "Angriff" von innen, bei dem dann halt IRGENDEIN Gerät im LAN, auf das der Angreifer Zugriff erlangen konnte, als "relay" genutzt wird?
Und da gibt es (mittlerweile) in praktisch jedem Haushalt deutlich mehr Geräte mit deutlich geringeren Sicherheitsvorkehrungen als in einer FRITZ!Box ... die "Aufzählung" solcher Geräte habe ich schon mehrfach vorgenommen und sie wird praktisch mit jeder Woche länger (und mit jedem Gerät, was vom Hersteller nicht mehr mit Updates versorgt, aber dennoch weiterhin genutzt wird, auch wieder "gefährlicher").
Der einzig plausible UND sichere Weg ist es also, die ANMELDUNG an diesen Diensten (sowohl von innen als auch von außen) so sicher zu gestalten, daß sich der Angreifer DARAN dann die Zähne ausbeißt (und das wirkt dann automatisch für ALLE Angriffsversuche) ... das konnte man aber bisher in diesem Thread nur einmal lesen (in #23) und man kann nur hoffen, daß es von niemand anderem erwähnt wurde, WEIL es so selbstverständlich sein sollte.
Wenn aber der Dienst (hier halt die Anmeldung am FRITZ!OS-GUI - das ist ja auch nicht nur das "Admin-Interface", sondern ebenso das MyFRITZ!-GUI und das FRITZ!NAS) ausreichend sicher ist, daß er nach innen gegen Angriffe absichert, wieso sollte er das nach außen dann irgendwie "schlechter" umsetzen? Es war ja bisher sogar so, daß der Dienst bei AVM "von außen" BESSER abgesichert war, weil die Anmeldemaske "von innen" auch gleich noch die Benutzernamen für die Administrator-Konten mit ausspuckt (in der nächsten Version wird man das ja glücklicherweise deaktivieren können), womit die eine Hälfte des "Rätsels" aus Benutzername und Kennwort schon gelöst wäre.
Ja, eine VPN-Verbindung KANN eine Lösung sein ... aber auch längst nicht für alles. Es gibt sogar Anwendungsfälle, wo sie geradezu kontraindiziert wäre. Ein Beispiel wäre eine Dateifreigabe für einen Dritten (diese Funktion gibt es ja auch im FRITZ!OS - sogar mit Beschränkung der Anzahl möglicher Abrufe), weil meinetwegen ein (nicht für die Öffentlichkeit bestimmter, also auch nicht über irgendwelche "File-Sharer" bereitzustellender) Anhang per E-Mail nicht verschickt werden konnte.
Dafür will man sicherlich demjenigen, der auf diese Datei zugreifen will, jetzt nicht gleich eine VPN-Verbindung einrichten, die ihm dann auch (ohne zusätzliche Maßnahmen und eigentlich auch nicht ohne zusätzliche Hardware bzw. in die "Lösung" zu integrierende Clients im LAN, wenn man mit "Port- oder Geräteisolation" arbeiten wollte, was AVM m.W. aber auch nur bei LAN-LAN-Kopplung unterstützt ... und wenn das anders sein sollte, ist es immer noch "außerhalb der betrachteten Aufgabenstellung") wieder den Zugriff auf das GESAMTE LAN bietet. Wie gesagt, nur EIN Beispiel ... es gibt garantiert noch weitere (auch durchaus plausible).
Was ist es dann doch für eine Erleichterung zu wissen, DASS das AVM-GUI auch dann sicher ist (einigermaßen zumindest, solange niemand das Gegenteil beweisen kann), wenn man den externen Zugriff auf das GUI zuläßt. Solange da dann nicht steht: "Anmeldung des Benutzers xyz von der externen IP-Adresse ... erfolgreich (Anm.: editiert, fehlte)" und man sicher weiß, daß man das nicht selbst war. "Unbekannte" Benutzernamen sollte es da ja per se nicht geben und eine "saubere" Umsetzung eines Berechtigungskonzepts (durch den Administrator) sorgt auch dafür, daß da nicht wirklich JEDES Familienmitglied gleich auch noch einen Admin-Account hat - DAS verringert dann auch wieder die Angriffsfläche (und auch in meinen Augen sinnvoll), während ein "nur mit VPN" per se soo viele Anwendungsfälle ausschließt (inkl. der meisten AVM-eigenen Apps für Android und iOS - und es ist nun mal ein Fakt, daß es Leute gibt, welche die auch benutzen WOLLEN), daß man damit die Box selbst kastriert.
Und das alles nur aus der Angst heraus, es könnte da irgendein Sicherheitsproblem in der Anmeldung an der Oberfläche geben? Wer sagt denn eigentlich, daß ein solches Problem bei der VPN-Benutzung NICHT auftreten kann?
Weil VPNs per se "sicher" sind? Ich empfehle da einfach mal den Blick in die "CVE-Liste" (was das ist, findet jeder selbst heraus): https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=VPN
Ich verstehe ja noch, wenn jemand nicht UNNÖTIGE Ports nach außen öffnen will - DAS wäre tatsächlich dämlich. Aber man muß auch Augenmaß wahren bei der eigenen Sicherheit - und sollte sich auf die tatsächlichen Gefahren konzentrieren. Wenn IRGENDJEMAND auf einem Gerät innerhalb des (W)LANs eine Nachricht mit einer Malware so öffnet, daß diese auch gestartet wird (von Lücken in PDF-Readern bis zu aktivierten Makros in Office-Dokumenten (egal in welchem Office-Paket) oder auch Lücken in Web-Browsern, durch die Schadcode (mit Zugriff auf das System) eingeschleust werden kann), dann ist das VIEL gefährlicher als ein vergeblicher(!) Anmeldeversuch in einem sauber implementierten Login-Formular.
DAS ist auch heute noch der bevorzugte und am häufigsten erfolgreiche Angriff - irgendwelche "automatisch auszunutzenden Lücken" (als "0days") sprechen sich viel zu schnell herum, werden als "Thema" viel zu groß (Beispiel: https://www.google.com/search?q=apple+0day) und damit auch häufig schneller gefixt, als ein (systematisch arbeitender) Angreifer damit etwas anfangen kann. Ein Vorgehen über selbst geschaffene "relays" INNERHALB eines fremden Netzes ist auch nichts wirklich Neues ... das ist seit (mind.) 15 Jahren immer wieder ein Thema (als RAT - Remote Access Trojans) und schon 2011 gab es ein paar sehr interessante Einblicke, WIE solche Angreifer dann wirklich arbeiten (Stichwort für die eigenen Internetsuche: "Operation Shady RAT").
Was will ich damit zum Ausdruck bringen? Braucht man sich gar nicht mehr um die Sicherheit seines "Edge-Routers" zu sorgen? Natürlich ist es das NICHT ... nur bringt es eben auch nichts, wenn man sich gegen die 1% der "unwahrscheinlichen Angriffe" absichert und dann schlägt es auf eine Art und Weise ein, wie das bei jedem fünften Angriff (das wären dann 20%) der Fall ist. Wer sich - NUR um einem einzigen geöffneten Port in "seiner Firewall" aus dem Weg zu gehen - weitere Komplexität in sein Netzwerk holt, der holt sich damit auch (automatisch) weitere Stellen für potentielle Angriffe ins Boot.
Als "Milchmädchenrechnung" könnte man sogar so weit gehen, daß man mit einem (unnötigen) VPN (ich nehme mal IPSec, WEIL das mit mehr offenen Ports arbeitet, als WireGuard) zwar einen offenen Port vermeidet (mit EINER Implementierung für die Account-Sicherheit), dafür aber drei andere Ports öffnen muß (UDP 500 / ESP - wobei ESP NICHT portbasiert ist, dafür muß da dann ALLES durchgelassen werden, wo IP-Adresse und Protokollnummer stimmen - und UDP 4500 für IPSec mit NAT-T) und die MÜSSEN auch alle drei zunächst mal auf unterschiedliche Art mit den empfangenen Daten umgehen, weil das jeweils etwas andere Formate sind, bis die Verarbeitung dann wieder zusammengeführt werden kann. Das sind dann auch dreimal soviele mögliche "Code-Flows", in denen entsprechende Fehler auftreten können.
Dennoch wird es einem eben auch ein VPN NICHT abnehmen, daß man die restlichen Dienste AUCH VON INNEN so absichern muß, daß auch ein Angreifer von DIESER Seite der "Firewall" absehbar keinen Erfolg haben wird. WENN man das also mit begrenzten Ressourcen "reviewen" wollte (also einer Untersuchung der Sicherheit unterzieht), dann wäre es doch viel logischer, wenn man ZUERST mal die fraglichen Dienste SELBST so absichert, daß weder ein externer NOCH ein interner Angreifer da etwas erreichen kann. Leider vergessen das aber viele (auch viele Profis) in ihrer "Planung" zu berücksichtigen - am Ende "freuen" sich dann wieder die Angreifer.
Wer noch ein Beispiel dafür haben will, WIE Angreifer in "berühmten Fällen" vorgegangen sind, der kann ja mal nach dem "Bundestags-Hack" suchen: https://www.heise.de/newsticker/mel...ags-wohl-heftiger-als-angenommen-2657344.html - das war (zumindest nach dem, was "man so hört und liest") auch kein offener Port für einen Dienst mit einer schwachen Absicherung gegen unberechtigte Logins, was da zum erfolgreichen Angriff wurde.
Irgendwie sind viele nach der "webcm"-Lücke in der AVM-Firmware in eine Art "Schock" gefallen (teils zu Recht, häufig aber auch etwas übertrieben) und trauen nun der Firmware nicht mehr so richtig über den Weg ... ich persönlich finde das ausgesprochen schade, auch WEIL ich die Firmware von AVM (nach einigen Korrekturen in den vergangenen Jahren, nicht nur in der Firmware, sondern (in Maßen und eigentlich in viel zu geringem Umfang) auch in der "Fehlerkultur" bei AVM) für eine der sichersten für "Consumer-Router" halte und das auch, OBWOHL sie viele Features bietet, die man bei anderen Modellen (für dieselbe Zielgruppe) so nicht findet.
Klar, man KANN sich im LAN seinen eigenen WireGuard-Server aufsetzen und man kann vielleicht in künftigen FRITZ!OS-Versionen auch gleich WireGuard benutzen (das wird auch wieder nicht für JEDEN AVM-Router gelten, der in freier Wildbahn noch mit FRITZ!OS 07.2x arbeitet und eben KEIN Update auf 07.50 (so soll das ja angeblich dann heißen) mehr erhalten wird) - nur ist das dann eben auch keine Lösung für JEDERMAN und ich glaube kaum, daß AVM tatsächlich als "Zielgruppe" diejenigen fest im Blick hat, die dann lieber eine solche Lösung selbst umsetzen ... dafür hat das FRITZ!OS dann wieder viel zuwenig Einstellmöglichkeiten für solche "Bastler".
Diesem "Rest" an FRITZ!Box-Benutzern sollte man aber (meine Meinung) nur dann auch ANGST machen, daß sie ständig "angegriffen" werden, wenn man das dann selbst RICHTIG einordnet. Denn was wäre denn die Alternative, wenn AVM diese Meldungen NICHT anzeigt?
Über den FTP-Server konnte man über Jahre auch gezielte Brute-Force-Attacken auf einen Account fahren, weil es einen Weg gab, die exponentielle Steigerung der "penalty" in Form einer zu wartenden Zeit vor dem nächsten Login-Versuch zu umgehen - dafür brauchte es nur einen anderen Account, mit dem man sich anmelden konnte. Wenn da also der Filius (oder auch die Filia, das ist kein ausschließlich "männliches" Problem) Zugriff auf den NAS-Speicher hatte (als "berechtigter User"), dann konnte er mit diesem Account eine fröhliche Hetzjagd auf das elterliche Konto in der FRITZ!Box starten und zwar OHNE jegliche Protokollierung dieses Vorgehens und auch noch sehr effektiv (weil ein FTP-Login obendrein sehr schnell geht), wenn er einfach alle zwei, drei Fehlversuche wieder ein gültiges Login mit dem eigenen Account machte.
Das ist also ein weiteres Beispiel für einen "internen Angreifer" und längst nicht jeder "insider threat" basiert auf einem unvorsichtigen Insider (das wäre der Trojaner über die E-Mail), denn auch jemand, der gerne seine zeitlichen Limitierungen für die Internet-Nutzung übergehen würde, ist - in diesem Kontext - ein "böswilliger" Insider, der obendrein in den allermeisten Fällen auch noch deutlich mehr Infos über sein "Angriffsziel" hat (meinetwegen kennt er den Benutzernamen für das Admin-Konto und alle Geburtstage der gesamten Familie samt Initialen und selbst den Namen des Familienhundes), als irgendein "externer" Angreifer, der sich erst "vorarbeiten" muß.
Langer Rede kurzes Fazit:
Man macht nur das auf, was man auch braucht ... dann aber bitte auch so, daß es Sinn ergibt und nicht von Beginn an durch die "Festlegung" auf ein bestimmtes Vorgehen (um wieder festzustellen, daß auch ein VPN nicht IMMER eine Lösung ist). Wenn ich "Angst" habe, daß ein "angebotener Dienst" nicht sicher genug für "das Internet" ist, dann sollte ich den auch nicht aus dem internen Netz heraus nutzen können - viel zu schnell hat ein (echter) Angreifer den dann halt auf einem anderen Weg erreicht. Und sei es, weil erst die VPN-Verbindung vom Smartphone dem Angreifer (in Gestalt einer App auf dem Gerät) den Zugriff auf das GESAMTE interne Netz ermöglichte, während der eigentlich freizugebende Dienst gerade mal das Abrufen irgendeiner Datei vom NAS ermöglicht hätte.
Zuletzt bearbeitet:
Um mal auf das Thema zurückzukommen ...
Meine Box schickt mir seit ein paar Tagen in unregerlmäßigen Abständen "Supportdaten"-Mails. Wenn ich in die Ereignisliste schaue, seh' ich gefühlt Tausende Einträge, daß jemand oder etwas auf die SMB-Funktion zugreifen will und entweder an falschem Kennwort oder nicht existierendem Benutzer scheitert.
Die IPv6-Adressen passen zwar auf meinen Präfix, aber die letzten Stellen sind keinem Gerät in meinem Netz zugeordnet, was eine Möglichkeit (oder einen Grund) hat, auf die Dateifreigaben meiner Box zuzugreifen.
Es ist schade, daß die Netzwerkübersicht nur IPv4-Adressen anzeigt, das Log aber beinahe ausschließlich IPv6-Adressen protokolliert.
Daraus ergeben sich nun Fragen:
- Können Fremde *von außen* auf den SMB-Dienst zugreifen?
- Falls ja: Kann das mit einfachen Einstellungen unterbunden werden?
- Falls nein: Welche Geräte (außer PCs mit Samba-Clients) könnten da noch versuchen, ohne gesonderte Aufforderung bzw. Anmeldung auf die Dateifreigaben der Box zuzugreifen?
- Gibt's eine Möglichkeit, die Netzwerkübersicht mit IPv6-Adressen anzuzeigen? Ich möchte IPv6 ungern deaktivieren (um ein Log mit IPv4-Adressen zu kriegen), da mein Provider IPv6-basiertes DSLite verwendet.
Meine Box schickt mir seit ein paar Tagen in unregerlmäßigen Abständen "Supportdaten"-Mails. Wenn ich in die Ereignisliste schaue, seh' ich gefühlt Tausende Einträge, daß jemand oder etwas auf die SMB-Funktion zugreifen will und entweder an falschem Kennwort oder nicht existierendem Benutzer scheitert.
Die IPv6-Adressen passen zwar auf meinen Präfix, aber die letzten Stellen sind keinem Gerät in meinem Netz zugeordnet, was eine Möglichkeit (oder einen Grund) hat, auf die Dateifreigaben meiner Box zuzugreifen.
Es ist schade, daß die Netzwerkübersicht nur IPv4-Adressen anzeigt, das Log aber beinahe ausschließlich IPv6-Adressen protokolliert.
Daraus ergeben sich nun Fragen:
- Können Fremde *von außen* auf den SMB-Dienst zugreifen?
- Falls ja: Kann das mit einfachen Einstellungen unterbunden werden?
- Falls nein: Welche Geräte (außer PCs mit Samba-Clients) könnten da noch versuchen, ohne gesonderte Aufforderung bzw. Anmeldung auf die Dateifreigaben der Box zuzugreifen?
- Gibt's eine Möglichkeit, die Netzwerkübersicht mit IPv6-Adressen anzuzeigen? Ich möchte IPv6 ungern deaktivieren (um ein Log mit IPv4-Adressen zu kriegen), da mein Provider IPv6-basiertes DSLite verwendet.
PeterPawn
IPPF-Urgestein
- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,300
- Punkte für Reaktionen
- 1,761
- Punkte
- 113
Wieso soll das mehr zum Thema gehören (als der generelle Umgang mit solchen Benachrichtigungen und wie andere eine FRITZ!Box "finden" könnten), wenn Du noch nicht mal sicher weißt, ob bei Dir diese Versuche nun von innen oder von außen kommen?
Ist nicht meine These, daß man die Box aus "beiden Richtungen" genauso schützen muß, fast schon dadurch bewiesen, daß da bei Dir ein Dienst "angegriffen" wird, der bei korrekter Konfiguration der Box (und korrekt arbeitender Firmware) gar nicht aus dem Internet ansprechbar sein sollte? https://service.avm.de/help/de/FRITZ-Box-7590/021/hilfe_internet_filter_listen
Vielleicht setzt Du Dich ja mal mit IPv6 und speziell mit dem RFC 8981 (https://datatracker.ietf.org/doc/rfc8981/) auseinander - dann kriegst Du eine Idee, woher da "unbekannte" IIDs (Interface-ID bei IPv6) kommen KÖNNTEN.
Und bei SMB-Diensten ist es auch nicht wirklich ungewöhnlich, wenn da jemand versucht, mit "Gastrechten" auf eine Freigabe zuzugreifen (auch wenn AVM da mittlerweile kein Samba mehr verwendet, macht die andere Server-Software auch nichts anderes) - das kann praktisch jeder Client im LAN sein, der SMB "spricht" und seinerseits das LAN durchsucht (dazu reicht ein Verbindungsversuch mit einem wohlbekannten TCP-Port) und ggf. macht sich die FRITZ!Box sogar selbst per mDNS anheischig für die Nutzung ihrer SMB-Freigaben (müßte man erst mal mit einem Mitschnitt prüfen, um es auszuschließen).
Kandidaten für derartige Zugriffsversuche sind speziell Settop-Boxen mit DLNA-Funktionen (Enigma2-basierte besonders gerne), Mediaplayer auf irgendwelchen Geräten (von Smartphones, Tablets bis zum neuen Smart-TV ... oder auch eine Kloschüssel mit eingebautem Media-Player) und so weiter ... wenn man sich einfach mal in den Support-Daten die "neighbors" ansieht, sollte da (zumindest mit etwas Glück) auch eine Zuordnung zwischen IPv6- und MAC-Adresse möglich sein, wobei das auch per GUI zu finden sein sollte.
Denn beim letzten Punkt KÖNNTE dann wieder die Online-Hilfe "helfen" (vermutlich heißt die deshalb auch so) ... wobei sich mit der Firmware 07.28-91964 (Inhouse) für Deine 7490 sicherlich nicht sooo viele Leute noch auskennen, die Dir dann Hinweise geben können, wie man IPv6-Adressen auch in der "Übersicht" (des Netzwerks) angezeigt bekommt.
Ich wüßte jedenfalls keine "Einstellung" dafür (nicht mal in den neuesten Labor-Versionen) - was sicherlich auch daran liegt, daß es tatsächlich KEINE 1:1-Zuordnung EINER IPv6-Adresse zu einem Client gibt (denn die Nutzung von IIDs nach RFC 8981 ist Sache des Clients selbst und keine "generelle Regelung" durch den Router/DHCPv6-Server) - in aller Regel haben IPv6-Clients sogar neben öffentlichen IPv6-Adressen auch noch weitere, die dann nur "link-local" zu verwenden sind.
Nach der Lektüre des o.g. RFC weißt Du ja, daß JEDER IPv6-Client auch unterschiedliche IIDs für seine Adresse verwenden kann ... da sähe eine "Tabelle" dann sicherlich komisch aus und so muß man wohl bei JEDEM Client mit IPv6-Support dann in die "Details" sehen (за карандашом), wo sich auch die "Listen" der bekannten IPv6-Adressen für diesen Client finden lassen sollten.
Daß es zu jedem Gerät "за карандашом" die Detailanzeige mit allen IPv6-Adressen gibt weiß ich - bei (aktuell) einem Dutzend Geräten ist das aber mühselig, deswegen die Frage, ob man in der Netzwerkübersicht auch IPv6 anzeigen lassen kann - nein, geht nicht, nur MAC- und IPv4-Adresse.
Selbst wenn dadurch jeder Eintrag dicker dargestellt werden würde (bspw. hat mein PC aktuell 15 IPv6-Adressen) - es wäre alles auf einer Seite und somit wäre Strg-F für "Seite durchsuchen" möglich.
Der Hinweis auf DLNA-Geräte (aka MediaPlayer) hilft - ich habe außer der 7490 noch ein Internet-Radio im Netzwerk, welches aber meist auf StandBy ist. Eventuell ist das doch nicht sooo "StandBy" wie es sein sollte.
Außerdem gibt's noch eine 7390, die als DECT-Repeater und LAN-Switch arbeitet. Bei der ist der MediaServer aber nicht aktiv.
Wie auch immer - der SMB-Zugriff scheint mein PC zu sein. In den Windows-Anmelde-Informationen habe ich selbige für die FritzBox aktualisiert und seitdem fehlt der Hinweis "gescheitert (falsches Kennwort)".
Was ich nicht verstehe ist, wieso derselbe PC mit einer anderen IPv6-Adresse versucht sich an der Benutzeroberfläche anzumelden, was wegen falschem Kennwort scheitert ...
Für andere, die vor demselben Problem stehen wie ich und mit einer IPv6-Adresse aus dem Ereignisprotokoll versuchen ein Gerät zu ermitteln:
Start -> Ausführen -> CMD -> "Ping -a -6 [IPv6-Adresse]" [Enter]
Resultat ist die Adressenausgabe der Gegenstelle (in meinem Fall "HSishi-PC.fritz.box") mit der Paketlaufzeit.
Falls sich jmd wundert wegen "Start - Ausführen": Ich nutze "Classic Start Menu" (-> www.classicshell.net ).
koyaanisqatsi
IPPF-Urgestein
- Mitglied seit
- 24 Jan 2013
- Beiträge
- 14,210
- Punkte für Reaktionen
- 590
- Punkte
- 113
Also hier muss ich aber mal ergänzen, dass ich diese Zugriffsversuche auch schon unter den Ereignissen gesehen habe und zwar erst NACHDEM ich meine Box bei MyFritz registriert habe. Da diese Meldungen immer mehr wurden habe ich den Zugriff deaktiviert und sofort keine Meldungen dieser Art mehr. Also muss es ja doch mit MyFritz zusammenhängen.
Kann es sein, dass einfach nur eine Menge kryptischer Zeichenfolgen vor dem Myfritz.net generiert werden?
Wäre ähnlich zu einer Wörterbuch-Atacke, oder?
Auch bei einem abweichenden Port verzeichne ich solche Versuche. Bei meinem Vater ist es ähnlich.
Wäre ähnlich zu einer Wörterbuch-Atacke, oder?
Auch bei einem abweichenden Port verzeichne ich solche Versuche. Bei meinem Vater ist es ähnlich.
frank_m24
IPPF-Urgestein
- Mitglied seit
- 20 Aug 2005
- Beiträge
- 20,448
- Punkte für Reaktionen
- 619
- Punkte
- 113
Du hast die myFritz Freigabe entfernt? Dabei hast du dann natürlich auch den Port geschlossen.
Da ist es dann aber einfacher, die IPs abzuscannen, das sind nämlich erheblich weniger Möglichkeiten.
Ich hab diese Einträge auch schon auf zahlreichen Boxen gesehen, für die es noch nie einen myfritz oder dyndns Account gegeben hat. Vergesst irgendeinen Zusammenhang damit.
Ich mache mir da auch keine Sorgen.
Die verwendeten Nutzernamen waren nicht einmal annähernd in der Nähe
Die verwendeten Nutzernamen waren nicht einmal annähernd in der Nähe
Neueste Beiträge
-
[Frage] Zweite Fritz!Box mit eigenem Wlan mit Pi-Hole
- Letzte: antonvm
-
Firmware-Releases Fritz!FON 4.xx ab Fritz!OS 7 (Labor/Beta/Inhaus)
- Letzte: Feuerwehr2
-
Fritz!Fax will nicht mehr nach Fritz!Box-Wechsel
- Letzte: NanoBot
-
[Sammlung] Apps zur Steuerung von AVM-Smart Home- Letzte: Ralf-Fritz
-
MyFRITZ!Net oder anderer DynDNS-Anbieter
- Letzte: antonvm
