sf3978
IPPF-Promi
- Mitglied seit
- 2 Dez 2007
- Beiträge
- 8,014
- Punkte für Reaktionen
- 28
- Punkte
- 48
Evtl. mit tcpdump, ping, traceroute, ... versuchen festzustellen, wie die Datenpakete von der Testbox ins restliche LAN kommen.
- Status
Oder einfach den FritzHonigtopf an LAN 4 ins Gastnetz verbannen. Portweiterleitung ins Gastnetz sollte auch gehen.
Honigtöpfe usw.
Lohnt sich der Aufwand noch? Wenn jetzt zu den 20% aus der BSI-Meldung noch die Zwangsupgedateten der Kabelprovider kommen, dürften Angriffsversuche nicht mehr so lukrativ sein. Hinzu kommt noch, dass der Rest wahrscheinlich den https-Port nicht offen hat.
Und wie soll ein Versuch eines Trittbrettfahrers (dürften in der absoluten Mehrheit sein) von einem wirkungsvollen Angriff unterschieden werden?
Marcus
Lohnt sich der Aufwand noch? Wenn jetzt zu den 20% aus der BSI-Meldung noch die Zwangsupgedateten der Kabelprovider kommen, dürften Angriffsversuche nicht mehr so lukrativ sein. Hinzu kommt noch, dass der Rest wahrscheinlich den https-Port nicht offen hat.
Und wie soll ein Versuch eines Trittbrettfahrers (dürften in der absoluten Mehrheit sein) von einem wirkungsvollen Angriff unterschieden werden?
Marcus
Zum Thema "Lohnt sich der Aufwand noch" ein paar Logs von heute:
Grüße,
JD.
Code:
Feb 14 08:54:49 fritz kern.warn kernel: [IPT] DENY-FRITZ-ACCESS IN=dsl OUT= MAC= SRC=217.82.128.71 DST=192.168.178.1 LEN=48 TOS=0x00 PREC=0x00 TTL=119 ID=27848 DF PROTO=TCP SPT=4346 DPT=443 WINDOW=65535 RES=0x00 SYN URGP=0
Feb 14 08:54:49 fritz kern.warn kernel: [IPT] DENY-FRITZ-ACCESS IN=dsl OUT= MAC= SRC=217.82.128.71 DST=192.168.178.1 LEN=48 TOS=0x00 PREC=0x00 TTL=119 ID=27863 DF PROTO=TCP SPT=4350 DPT=80 WINDOW=65535 RES=0x00 SYN URGP=0
Feb 14 08:54:52 fritz kern.warn kernel: [IPT] DENY-FRITZ-ACCESS IN=dsl OUT= MAC= SRC=217.82.128.71 DST=192.168.178.1 LEN=48 TOS=0x00 PREC=0x00 TTL=119 ID=27886 DF PROTO=TCP SPT=4346 DPT=443 WINDOW=65535 RES=0x00 SYN URGP=0
Feb 14 08:54:52 fritz kern.warn kernel: [IPT] DENY-FRITZ-ACCESS IN=dsl OUT= MAC= SRC=217.82.128.71 DST=192.168.178.1 LEN=48 TOS=0x00 PREC=0x00 TTL=119 ID=27890 DF PROTO=TCP SPT=4350 DPT=80 WINDOW=65535 RES=0x00 SYN URGP=0
Feb 14 08:54:58 fritz kern.warn kernel: [IPT] DENY-FRITZ-ACCESS IN=dsl OUT= MAC= SRC=217.82.128.71 DST=192.168.178.1 LEN=48 TOS=0x00 PREC=0x00 TTL=119 ID=27935 DF PROTO=TCP SPT=4346 DPT=443 WINDOW=65535 RES=0x00 SYN URGP=0
Feb 14 08:54:58 fritz kern.warn kernel: [IPT] DENY-FRITZ-ACCESS IN=dsl OUT= MAC= SRC=217.82.128.71 DST=192.168.178.1 LEN=48 TOS=0x00 PREC=0x00 TTL=119 ID=27938 DF PROTO=TCP SPT=4350 DPT=80 WINDOW=65535 RES=0x00 SYN URGP=0
Feb 14 08:55:10 fritz kern.warn kernel: [IPT] DENY-FRITZ-ACCESS IN=dsl OUT= MAC= SRC=217.82.128.71 DST=192.168.178.1 LEN=48 TOS=0x00 PREC=0x00 TTL=119 ID=27974 DF PROTO=TCP SPT=4355 DPT=80 WINDOW=65535 RES=0x00 SYN URGP=0
Feb 14 08:55:13 fritz kern.warn kernel: [IPT] DENY-FRITZ-ACCESS IN=dsl OUT= MAC= SRC=217.82.128.71 DST=192.168.178.1 LEN=48 TOS=0x00 PREC=0x00 TTL=119 ID=27994 DF PROTO=TCP SPT=4355 DPT=80 WINDOW=65535 RES=0x00 SYN URGP=0
Feb 14 08:55:19 fritz kern.warn kernel: [IPT] DENY-FRITZ-ACCESS IN=dsl OUT= MAC= SRC=217.82.128.71 DST=192.168.178.1 LEN=48 TOS=0x00 PREC=0x00 TTL=119 ID=27996 DF PROTO=TCP SPT=4355 DPT=80 WINDOW=65535 RES=0x00 SYN URGP=0
Feb 14 09:32:10 fritz kern.warn kernel: [IPT] DENY-FRITZ-ACCESS IN=dsl OUT= MAC= SRC=79.216.179.202 DST=192.168.178.1 LEN=64 TOS=0x00 PREC=0x00 TTL=55 ID=55718 DF PROTO=TCP SPT=50238 DPT=443 WINDOW=65535 RES=0x00 SYN URGP=0
Feb 14 09:32:10 fritz kern.warn kernel: [IPT] DENY-FRITZ-ACCESS IN=dsl OUT= MAC= SRC=79.216.179.202 DST=192.168.178.1 LEN=64 TOS=0x00 PREC=0x00 TTL=55 ID=41405 DF PROTO=TCP SPT=50239 DPT=80 WINDOW=65535 RES=0x00 SYN URGP=0
Feb 14 09:32:11 fritz kern.warn kernel: [IPT] DENY-FRITZ-ACCESS IN=dsl OUT= MAC= SRC=79.216.179.202 DST=192.168.178.1 LEN=64 TOS=0x00 PREC=0x00 TTL=55 ID=35573 DF PROTO=TCP SPT=50239 DPT=80 WINDOW=65535 RES=0x00 SYN URGP=0
Feb 14 09:32:11 fritz kern.warn kernel: [IPT] DENY-FRITZ-ACCESS IN=dsl OUT= MAC= SRC=79.216.179.202 DST=192.168.178.1 LEN=64 TOS=0x00 PREC=0x00 TTL=55 ID=23210 DF PROTO=TCP SPT=50238 DPT=443 WINDOW=65535 RES=0x00 SYN URGP=0
Feb 14 09:32:12 fritz kern.warn kernel: [IPT] DENY-FRITZ-ACCESS IN=dsl OUT= MAC= SRC=79.216.179.202 DST=192.168.178.1 LEN=64 TOS=0x00 PREC=0x00 TTL=55 ID=4561 DF PROTO=TCP SPT=50239 DPT=80 WINDOW=65535 RES=0x00 SYN URGP=0
Feb 14 09:32:12 fritz kern.warn kernel: [IPT] DENY-FRITZ-ACCESS IN=dsl OUT= MAC= SRC=79.216.179.202 DST=192.168.178.1 LEN=64 TOS=0x00 PREC=0x00 TTL=55 ID=65170 DF PROTO=TCP SPT=50238 DPT=443 WINDOW=65535 RES=0x00 SYN URGP=0
Feb 14 09:32:13 fritz kern.warn kernel: [IPT] DENY-FRITZ-ACCESS IN=dsl OUT= MAC= SRC=79.216.179.202 DST=192.168.178.1 LEN=64 TOS=0x00 PREC=0x00 TTL=55 ID=51169 DF PROTO=TCP SPT=50239 DPT=80 WINDOW=65535 RES=0x00 SYN URGP=0
Feb 14 09:32:13 fritz kern.warn kernel: [IPT] DENY-FRITZ-ACCESS IN=dsl OUT= MAC= SRC=79.216.179.202 DST=192.168.178.1 LEN=64 TOS=0x00 PREC=0x00 TTL=55 ID=59843 DF PROTO=TCP SPT=50238 DPT=443 WINDOW=65535 RES=0x00 SYN URGP=0
Feb 14 09:32:14 fritz kern.warn kernel: [IPT] DENY-FRITZ-ACCESS IN=dsl OUT= MAC= SRC=79.216.179.202 DST=192.168.178.1 LEN=64 TOS=0x00 PREC=0x00 TTL=55 ID=53933 DF PROTO=TCP SPT=50239 DPT=80 WINDOW=65535 RES=0x00 SYN URGP=0
Feb 14 09:32:14 fritz kern.warn kernel: [IPT] DENY-FRITZ-ACCESS IN=dsl OUT= MAC= SRC=79.216.179.202 DST=192.168.178.1 LEN=64 TOS=0x00 PREC=0x00 TTL=55 ID=19938 DF PROTO=TCP SPT=50238 DPT=443 WINDOW=65535 RES=0x00 SYN URGP=0
Feb 14 09:32:15 fritz kern.warn kernel: [IPT] DENY-FRITZ-ACCESS IN=dsl OUT= MAC= SRC=79.216.179.202 DST=192.168.178.1 LEN=64 TOS=0x00 PREC=0x00 TTL=55 ID=63935 DF PROTO=TCP SPT=50239 DPT=80 WINDOW=65535 RES=0x00 SYN URGP=0
Feb 14 09:32:15 fritz kern.warn kernel: [IPT] DENY-FRITZ-ACCESS IN=dsl OUT= MAC= SRC=79.216.179.202 DST=192.168.178.1 LEN=64 TOS=0x00 PREC=0x00 TTL=55 ID=63907 DF PROTO=TCP SPT=50238 DPT=443 WINDOW=65535 RES=0x00 SYN URGP=0Grüße,
JD.
Dass irgendwer irgendwelche Daten irgendwie sendet. Also eher wenig bis nichts. Besonders wenn man bei der Schwachstelle keine Logindaten braucht.
Bei dem ganzen Abweichungen zum Thema fällt es auch ned mehr auf.
Bei dem ganzen Abweichungen zum Thema fällt es auch ned mehr auf.
Zunächst mal nichts Besonderes ... solange ich (noch) nicht den https-Request auf Port 443 aufzeichnen kann bzw. dieser nix Besonderes hergibt.
Allerdings paßt das Muster (eine IP, viele abwechselnde Versuche auf Port 80 [Identifizierung der Box] und Port 443 [Ausnutzen der Lücke]) zu denen der vorangegangen Tage. Und ich meine, mich auch an die IPs erinnern zu können.
Entscheidend ist (zumindest für meine Box) die Statistik (wie ich bereits mehrfach schrieb): Die massive Kombination von Versuchen auf Port 80 und Port 443 von einer IP kannte ich vor dem 28.01. nicht. Die Frequenz wird seitdem stetig kleiner, aber die Muster bleiben.
Allerdings paßt das Muster (eine IP, viele abwechselnde Versuche auf Port 80 [Identifizierung der Box] und Port 443 [Ausnutzen der Lücke]) zu denen der vorangegangen Tage. Und ich meine, mich auch an die IPs erinnern zu können.
Entscheidend ist (zumindest für meine Box) die Statistik (wie ich bereits mehrfach schrieb): Die massive Kombination von Versuchen auf Port 80 und Port 443 von einer IP kannte ich vor dem 28.01. nicht. Die Frequenz wird seitdem stetig kleiner, aber die Muster bleiben.
Zuletzt bearbeitet:
Ideal wäre noch ein zwischengeschalteter Router oder eine eigene Netzwerkkarte am Linux Router.
Iptables auf der Box ist auch eine gute Lösung, solange man davon ausgeht, dass der Angreifer diese nicht abschalten kann. In diesem Fall würde ich davon ausgehen, da es dem Angreifer nicht darum geht, mit viel Aufwand an diese eine Box zu kommen, sondern mit einfachen Mitteln aus einer großen Anzahl von Boxen die zu finden, wo er etwas tun kann.
Außerdem wäre es sinnvoll, die Box auf eine IP-Adresse aus einem anderen Netzwerk zu konfigurieren als das restliche interne Netzwerk. Das ist zwar auch nicht absolut sicher, macht es dem Angreifer aber auch nochmal schwerer. Am Router muss man dann dementsprechend zwei interne Adressen konfigurieren.
Iptables auf der Box ist auch eine gute Lösung, solange man davon ausgeht, dass der Angreifer diese nicht abschalten kann. In diesem Fall würde ich davon ausgehen, da es dem Angreifer nicht darum geht, mit viel Aufwand an diese eine Box zu kommen, sondern mit einfachen Mitteln aus einer großen Anzahl von Boxen die zu finden, wo er etwas tun kann.
Außerdem wäre es sinnvoll, die Box auf eine IP-Adresse aus einem anderen Netzwerk zu konfigurieren als das restliche interne Netzwerk. Das ist zwar auch nicht absolut sicher, macht es dem Angreifer aber auch nochmal schwerer. Am Router muss man dann dementsprechend zwei interne Adressen konfigurieren.
@ RalfFriedl:
Könnte es sein, daß es
heißen müßte ?
Könnte es sein, daß es
Code:
openssl s_server -accept 443 [B]-debug[/B] -cert cert.pem -key key.pem &> /tmp/$(date +%Y%m%d-%H%M%S).logDebug zeigt nur zusätzliche Angaben zur Verschlüsselung. Ich habe es mal ausprobiert, ohne eine Eingabe bricht der Server die Verbindung sofort ab.
Aber so sollte es funktionieren:
Am Besten auch mal ausprobieren mit
Wget zeigt dann den Fehler 501 vom Server an, und der Server sollte etwas in der Art protokollieren:
@HabNeFritzbox
Gastzugang habe ich schon gehört, aber noch nicht verwendet. Sollte aber passen.
Aber so sollte es funktionieren:
Code:
echo HTTP/1.1 501 Server Error | openssl s_server -accept 443 -cert cert.pem -key key.pem &> /tmp/$(date +%Y%m%d-%H%M%S).log
Code:
wget -O /dev/null --no-check-certificate https://127.0.0.1/
Code:
GET /test HTTP/1.1
User-Agent: Wget/ (linux-gnu)
Accept: */*
Host: 127.0.0.1
Connection: Keep-Alive@HabNeFritzbox
Gastzugang habe ich schon gehört, aber noch nicht verwendet. Sollte aber passen.
@ RalfFriedl: Okay, danke für die Tips. Ich werde das probieren.
@ HabeNeFritzbox: Gastzugang ist unbrauchbar, weil man aus dem eigentlichen Heimnetz die Testbox nicht mehr "sieht", insbesondere keinerlei Zugriff z.B. per SSH hat.
@ HabeNeFritzbox: Gastzugang ist unbrauchbar, weil man aus dem eigentlichen Heimnetz die Testbox nicht mehr "sieht", insbesondere keinerlei Zugriff z.B. per SSH hat.
robot_rap
Aktives Mitglied
- Mitglied seit
- 19 Okt 2004
- Beiträge
- 2,128
- Punkte für Reaktionen
- 8
- Punkte
- 38
Zumindest auf meiner Box (7390, 06.03) ist die key.pem mit einem Passwort geschützt, sodass ein Entschlüsseln des SSH-Traffics mit Wireshark nicht funktioniert. Wer kennt das Passwort für die websrv_ssl_key.pem?
SSH läuft eh nicht mit Standard Mitteln und müsste erst erweitert werden. Gastzugang hat doch gerade den Zweck, dass man nicht ins Heimnetz oder umgedreht kommt. Daher dann auch wenn noch ne Freigabe dafür anlegen.
Gastzugang ist sicherer und einfacher, also extra noch 3. Router zwischen und 2. LAN Karte und ähnliches.
Ändert Thema am besten noch um, aktuell passt ja eher "Wie richte ich Weiterleitung ein?" oder "Wie richte ich openSSL ein?" oder "Wie tausche ich Zertifikat aus" oder "Wem Gehört IP xy?"
Gastzugang ist sicherer und einfacher, also extra noch 3. Router zwischen und 2. LAN Karte und ähnliches.
Ändert Thema am besten noch um, aktuell passt ja eher "Wie richte ich Weiterleitung ein?" oder "Wie richte ich openSSL ein?" oder "Wie tausche ich Zertifikat aus" oder "Wem Gehört IP xy?"
Zuletzt bearbeitet von einem Moderator:
Ich habe die genauen Details zur AVM-Sicherheitslücke aufgeklärt, Shellcode dazu geschrieben und vor gut einer Stunde der heise.de-Redaktion übermittelt. Sie wissen nun genauestens Bescheid und werden es hoffentlich bald einen Artikel dazu schreiben.
Die Lücke werde ich nicht preisgeben, auf Ratespielchen lasse ich mich auch nicht ein.
Ursächlich war jedenfalls eine mangelnde Inputvalidierung in einem "von außen" erreichbaren Dienst, über die man man Shell-Befehle absetzen konnte.
Wer der Meinung ist, dass ich Lüge, der notiere sich bitte folgenden SHA-256 Hash.
Die Lücke werde ich nicht preisgeben, auf Ratespielchen lasse ich mich auch nicht ein.
Ursächlich war jedenfalls eine mangelnde Inputvalidierung in einem "von außen" erreichbaren Dienst, über die man man Shell-Befehle absetzen konnte.
Wer der Meinung ist, dass ich Lüge, der notiere sich bitte folgenden SHA-256 Hash.
Code:
8492a4ef22a5d8c50b7e6782cd1c37a5f127d51cb3a11da3c857875c8d42ac7eEtwas mehr Infos kannst ruhig beschreiben dazu. Sonst bringt die Info auch keinem etwas.
Wie von mir schon mal vermutet konnte direkt die php Datei ausgeführt werden und andere Variablen gesetzt werden womit man auf andere Verzeichnisse kommt?
Muss ja keine genau Anleitung sein, aber Dienst oder grob kann man es doch beschreiben.
Wie von mir schon mal vermutet konnte direkt die php Datei ausgeführt werden und andere Variablen gesetzt werden womit man auf andere Verzeichnisse kommt?
Muss ja keine genau Anleitung sein, aber Dienst oder grob kann man es doch beschreiben.
Nein, PHP-Dateien habe ich überhaupt noch nie auf einer FB gesehen (habe aber auch nur eine 7270). Zumindest so viel kann ich noch verraten: Modelle, bei denen die Fernwartung über htaccess abgesichert ist (z.B. 7112), scheinen nicht betroffen zu sein.
Moin,
wenn ich die FW 5.50 und höher auf meine 7270v2 aufspiele funktioniert die nicht mehr in dem Umfang wie ich sie brauche...
Also auch keine Lösung. Die FW 5.50 und höher ist Müll, bleibt mir nur den Fernzugriff abzuschalten - kann ich mit leben
Viele grüße Hinckley
wenn ich die FW 5.50 und höher auf meine 7270v2 aufspiele funktioniert die nicht mehr in dem Umfang wie ich sie brauche...
Also auch keine Lösung. Die FW 5.50 und höher ist Müll, bleibt mir nur den Fernzugriff abzuschalten - kann ich mit leben
Viele grüße Hinckley
- Status
Neueste Beiträge
-
[Problem] Gerätenamen beim Fritz Repeater 1200AX- Letzte: Brown
-
[Gelöst] FritzBox 7390: v84.06.20_AT-CH vom 29.10. // GUI-Sprachpaket buggy?- Letzte: Gildehauser
-
[Sammlung] Die interessantesten Thread-Inhalte
- Letzte: KunterBunter
-
Fragen zu Vorlagen bzw. Zeitschaltung bei DECT302
- Letzte: Sojus
-
Suche Telefonanlage für kleine Kanzlei
- Letzte: crackerwilli