[Info] FRITZ!Box 7490 Labor-Firmware Version 113.06.36-31656 vom 23.10.2015

VOIP-Error bei Internet-Zugang via USB-Tethering fixed

hallo Mopedmeister und andere USB-Tethering Nutzer,
habe soeben FW 06.36-31656 mit Internet-Zugang via USB-Tethering und VOIP getestet.

Ergebnis: Bug aus 06.36-31504 und 06.36-31540 ist gefixt. Habe für Test ein Android-Smartphone mit USB-Tethering verwendet, Internet-Telefonie läuft nun mit Inbound- und Outbound-Audio-Stream problemlos.
Code:
# /bin/showvoipdstat
ua0 ([email protected], sipiface=internet): registered ok 0  -- reachability 100 % (overinternet)
0: RX: 369440 bytes, 2309 pkts, TX: 312000 bytes, 1300 pkts, Lost packets: 5
0: Outgoing Calls: 3 attempted, 2 answered, 2 connected, 1 failed
0: Incoming Calls: 0 received, 0 answered, 0 connected, 0 failed
0: Overall Calls: 0 dropped, Total Call Time = 0:01
0: Direct Loopback: 0 connected, 0 failed
Codec list: G722/8000/1, PCMA/8000/1, PCMU/8000/1, G726-32/8000/1, G726-40/8000/1, G726-24/8000/1, iLBC/8000/1, PCMA/16000/1, PCMU/16000/1, CLEARMODE/8000/1
SIP Clients:
VOIP Journal  (last 10 entries):
23.10.2015 21:50 --> Gateway     212.9.44.245:29362      Setup: 6785 ms, Dur: 0:01
  | TX: G.711 Pkt: 1136 Lost: 0.4% DL: 16 (13), JI: 5 (5), Burst: --
  | RX: G.711 Pkt: 1804 Lost: 0.0% DL: 16 (13), JI: 19 (19), Burst: 0 (0%)
  | DQ: ms=34060, minDelay=60, maxDelay=76, meanDelay=28, DropSilenceSamples=920, DropSamples=0, PlcSamples=1200, JitterSamples=8
23.10.2015 21:50 --> Gateway     212.9.44.245:29338      Setup: 394 ms, Dur: 0:01
  | TX: G.711 Pkt: 82 Lost: 0.0% DL: 0 (0), JI: 0 (0), Burst: --
  | RX: G.711 Pkt: 227 Lost: 0.0% DL: 0 (0), JI: 19 (18), Burst: 0 (0%)
  | DQ: ms=2368, minDelay=4, maxDelay=4, meanDelay=2, DropSilenceSamples=0, DropSamples=0, PlcSamples=32, JitterSamples=10
23.10.2015 21:50 --> Gateway    217.10.77.242:21342      Setup: 151 ms, Dur: 0:01
  | TX: G.711 Pkt: 82 Lost: 0.0% DL: 16 (16), JI: 3 (3), Burst: --
  | RX: G.711 Pkt: 278 Lost: 0.0% DL: 16 (16), JI: 19 (18), Burst: 0 (0%)
  | DQ: ms=2388, minDelay=36, maxDelay=44, meanDelay=20, DropSilenceSamples=0, DropSamples=0, PlcSamples=320, JitterSamples=18

Danke AVM-Team, weiter so!

Gruß
Splenditnet

EDIT: Textkorrektur eingepflegt
 
Zuletzt bearbeitet:
Hallo splenditnet,

das klingt ja sehr gut! Ich hatte heute Abend auch schon überlegt, ob sich der Hinweis auf den Fix zur sporadisch gestörten Telefonie im Changelog auf unser Problem beziehen könnte und scheinbar ist es wohl wirklich so :) Ich werde es gleich aber auch nochmal ausprobieren und dann hier berichten.

Ergebnis Test mit E3372:
Juchu, die VOIP Telefonie funktioniert auch mit meinem E3372, auf dem eine Highlink Firmware installiert ist, wieder :)

Vielen Dank an AVM, aber vor allem auch an dich Splenditnet!

Gruß
Mopedmeister
 
Zuletzt bearbeitet:
Durch den 1und1-Startcode automatisiert eingerichtete VoIP-Rufnummern weisen unter Telefonie > Eigene Rufnummern > Rufnummern als Anbieter "sip.1und1.de" auf, nachträglich manuell hinzugefügte Rufnummern "1und1.de" - bis hierhin ist der Fehler nur kosmetischer Natur.
Möchte man allerdings den Eintrag zu einer Internetrufnummer bearbeiten, dann erscheint die komplette Eingabemaske leer; die vorhandenen Daten werden nicht in die Textfelder geladen. Im 320px-Viewport (zum Beispiel auf vielen Smartphones) verrutschen auch die Textfelder im Layout.

Unter Internet > DSL-Informationen > Störsicherheit lassen sich die Regler im 320px-Viewport nicht bedienen.

Dass die WLAN-Stabilität erhöht wurde zeigt auf jeden Fall, dass hier noch ordentlich Optimierungsbedarf vorherrscht(e). Diese Laborversion ist jedenfalls die erste, bei der die Datenraten zu meinem FRITZ!WLAN Repeater DVB-C unter WLAN > Funknetz säuberlich getrennt in beide Frequenzbänder angezeigt werden.
Zudem sind die Datenraten erfreulich hoch: 975/975 Mbit/s im 5GHz-Netz und 449/214 Mbit/s im 2,4GHz-Netz durch zwei Wände in den Nebenraum erreichte bisher noch keine FRITZ!OS-Kombi. Es wird zudem die volle Bandbreite mit 40 bzw. 80 MHz ausgenutzt, das war in den Vorversionen meist anders.

Unter Heimnetz > Heimnetzübersicht > Alle Geräte fehlt meiner Meinung nach noch ein Button, um eine sofortige Update-Prüfung aller unterstützen Geräte anzustoßen. "Software aktuell" erscheint immer erst nach und nach mit großer Verzögerung von zwei bis drei Minuten bei allen unterstützen Geräten, man sollte zumindest diesen Ladeprozess darstellen - damit der User weiß: Hier lädt die Box gerade noch etwas nach.
Nach wie vor merkwürdig ist bei diesem Punkt, dass auch für meine beiden Gigaset-Geräte "Software aktuell" angezeigt wird, obwohl im DECT-Monitor als Software lediglich "0.00" aufgeführt wird - und ich bezweifle stark, dass die mehrere Jahre alten Geräte A400 und C47H updatefähig sind.

Unter System > Tasten und LEDs lassen sich die LEDs der Box leider nicht offiziell in den Nachtmodus schalten - gibt's diese Funktion noch als 'hidden feature'?

Schönes We,
tester25
 
...
DSLAM <-> "WAN<-7490->LANx" <-> "Firewall mit PPPoE" <-> "LANy<-7490->Rest der Anschlüsse"
Dann müßte das PPPoE-PT aber zumindest auf (einen einzelnen?) LAN-Port(s) beschränkt werden (bisher war das m.W. immer die komplette Bridge, aber bei einer VR9-Box gab es das offiziell wohl auch gar nicht mehr), ansonsten ist nur noch die unterschiedliche Kapselung der Pakete der einzige "Schutz" für die Trennung von WAN und LAN.

Das würde m.E. eine "richtige Firewall" etwas konterkarieren ... auch müßte ja dann die FRITZ!Box auf der einen Seite als "WAN-Bridge" arbeiten und gleichzeitig eine (getrennte) (W)LAN-Bridge betreiben, wobei das bisher als WAN genutzte "dsl"-Interface (braucht es u.a. für VPN) in dieser Konfiguration ja dann gar nicht existiert bzw. mir die Phantasie fehlt, wo das "andocken" sollte...

Ähm, wieso sollte das kein Schutz sein? PPPoE nutzt zwar Ethernet, aber nicht das IP-Protokoll, sondern eben das Point-to-Point-Protokoll. Ein Router, der das DSL-Modem der FBF via PPPoE nutzt, hat mit dem IP-Stack auf der Box gar nichts zu tun. Insofern kann hier auch nicht die Sicherheit kompromitiert werden; ein Angriff wäre allenfalls durch physikalischen Eingriff am DSLAM denkbar aber unpraktikabel. Insofern kann ein Router durchaus einfach mit zwei Kabeln angeschlossen werden, einer am WAN-Port des Routers, einer am LAN-Port. Die FBF kann dabei als reiner IP-Client konfiguriert werden. Die FBF kann via IP nur über den Router ins Internet, eine eigene öffrntliche IP gibt es ja nicht.

Spannend ist das vor allem, wenn man richtige Router/Firewalls wie pfSense einsetzen möchte. Die Fritzbox steht als WLAN-AP und Telephoniebasis, Druckserver und ggf. NAS (was fortgeschrittene Nutzer, wozu die pfSense-Nutzer eher nicht nutzen) weiter zur Verfügung.
Neben den besseren Routing/Firewallfunktionen von pfSense ist dieser z.B. zur Anonymisierung ganz nützlich. Dafür habe ich einen pfSense, der alle Verbindungen ins Internet über Cyberghost routet. Ausgenommen Telephonie und bestimmte bekannte Websites. Das schützt einen davor, in Störerhaftung genommen zu werden, wenn man sein Internet Gästen zur Verfügung stellt. In Wohngemeinschaften halte ich das beispielsweise für ein Must-to-Have.
Allerdings ging das meines Wissens schon vorher, wenn die FBF keine eigenen Zugangsdaten eingerichtet hatte. sondern als IP-Client lief.
Möglicherweise ist PPPoE-Passtrough aber erforderlich, wenn eine 2.PVC eingerichtet ist - also die FBF direkt die Internettelephonie machen soll, aber die 1.PVC gar nicht in der Fritzbox eingerichtet wird. Oder umgekehrt, um eine 2.PVC hinter der FBF aufzubauen. Bin gespannt, was sich da noch ergibt.

VLAN-Unterstützung wäre natürlich interessant für die kleineren Boxen mit nur einem LAN-Port. Außerdem wünsche ich mir einen Gastzugang auf VLAN, damit dieser auch im IP-Client-Modus funktioniert.
 
Zuletzt bearbeitet:
@tester25
Leider funktioniert der LED-Nachtmodus seit ein paar Labors auch mit der Angabe ...?sid=xxxxxxx nicht mehr. Fehlt mir persönlich auch sehr. Hab deswegen auch schon AVM gebeten, ihn wenigstens in die "Erweiterte Ansicht" aufzunehmen. In anderen Ländern - z.B. Frankreichs SFR-Boxen - war das vor Jahren selbstverständliches Feature.
 
Insofern kann hier auch nicht die Sicherheit kompromitiert werden; ein Angriff wäre allenfalls durch physikalischen Eingriff am DSLAM denkbar aber unpraktikabel.
Wieso sehen in dieser "Schaltung" nicht alle an der FRITZ!Box angeschlossenen Geräte alle PPPoE-Pakete ebenfalls? Selbst wenn hier auf L2 dann Pakete mit unterschiedlichem L3-Protokoll unterwegs sind, hat meines Erachtens jeder mit einem LAN-Kabel angeschlossene Client in dieser Konfiguration die Möglichkeit bzw. bei entsprechender Aggressivität die Chance, die Pakete auf L2 auf sich umzuleiten, aufzuzeichnen und ggf. sogar selbstgestrickte PPPoE-Pakete auf L2 zu versenden ... das ist ja im Prinzip das PPPoE-Passthrough, das wäre dann ja nicht automatisch auf einen einzelnen Client - die gewünschte Firewall - beschränkt, wenn alle (LAN-)Ports mit der WAN-Bridge kommunizieren könnten.

Mit der "konterkarierten Firewall" wollte ich nur darauf hinaus, daß dann - solange der Switch nicht gezielt einen einzelnen Port zum WAN (das wäre ja der "Modemport" des Lantiq-7-Port-Switches) bridged - der komplette Rest des LANs an der FRITZ!Box weiterhin vollständigen Zugriff auf die Pakete von der WAN-Seite hat (oder zumindest theoretisch haben könnte), ggf. eben auch LAN-Clients, die auf der LAN-Seite eigentlich sogar untereinander isoliert sind (auf L3 und darüber). Auf diesem "Umweg" kann dann ein Client wieder den Netzwerkverkehr belauschen, der - mal nur als Beispiel - ansonsten von einem anderen Client, der mit seinem "Gateway" nur über einen GRE-Tunnel mit Verschlüsselung kommuniziert, damit eben niemand im Netz ihn "abhören" kann, versteckt würde.

Die Punkt-zu-Punkt-Verschlüsselung in einem Windows-Netzwerk mit einem gemeinsamen Forefront TMG (das wäre dann der PPPoE-Client) wäre ein weiteres Beispiel, wo die LAN-Kommunikation hinreichend gesichert abläuft, aber der dann mögliche Zugriff auf den WAN-Verkehr des FTMG das Ganze wieder aushebeln würde.

Nun mag man ja unterschiedliche Vorstellungen vom Einsatzzweck der Filter so einer Firewall haben (eingehend, ausgehend, mixed), aber schon wenn dann Pakete (von anderen LAN-Clients) auf L2 "an der Firewall vorbei" wandern können, ist das m.E. nicht Sinn der Sache. Die könnten dann ja auch einfach anstelle der Firewall eine (weitere) PPPoE-Verbindung aufbauen ... vielleicht wird das der neue Trend beim "nach Hause telefonieren" anstatt den eigenen Datenverkehr in TLS-Verbindungen auf dem HTTPS-Port zu verstecken.

Ob da bei einer FRITZ!Box jetzt die MAC-Address-Table des Switches oder das Bridgen über die Software den Vorrang hätten (ich würde die Bridge auf L2 und nicht auf L3 sehen, damit macht dann auch die Frage, ob das PPP oder IP pur ist, nichts mehr aus) und wie kompliziert und unmöglich es wäre, L2-Pakete abzugreifen, die nicht an die eigene MAC-Adresse gehen sollen, kann ich im Moment nicht sauber einschätzen.

Aber wenn ich mal die These aufstellen darf, daß ja der PPPoE-Client auf der LAN-Seite der FRITZ!Box für die Übertragung zur WAN-Bridge resp. Richtung Internet ein Paket auf L2 mit der MAC-Adresse des DSLAM senden muß (hat der CPU-Port des 7-Port-Switches eine eigene MAC-Adresse?), dann geht das ja in jedem Falle an einem LAN-Port dieses 7-Port-Switches ein. Schickt jetzt so ein Switch die Daten tatsächlich auf direktem Weg an den Port, an dem das Modem hängt? Denkbar wäre das sicherlich und dann spielt auch die LAN-Bridge in Software keine wirkliche Rolle, aber wie sieht das dann auf dem Rückweg aus?

Oder hat am Ende das (integrierte) Modem eine eigene MAC-Adresse, dann wäre natürlich dieses Modem das (Zwischen-)Ziel der L2-Pakete. Würde ich eher nicht annehmen, in einem Packetdump (eines "full routers") sind ja Pakete an MAC-Adressen zu sehen, die zum DSLAM gehören. Da das wohl noch "vor" dem Modem ist, wo die Daten für einen Dump ausgeleitet werden, müssten die von der Box kommen und nicht vom Modem.

Damit kommt dann auf dem Rückweg ein PPP-Paket vom DSLAM am Modemport des FRITZ!Box-Switches an, welche MAC-Adresse trägt das jetzt als Ziel? Ist der Switch jetzt so programmiert (im "WAN-Bridge-Modus"), daß der das Paket direkt an den Port weiterleitet, an dem der Rechner hängt, für den das Paket lt. MAC-Adresse gedacht ist und ist das dann tatsächlich der "PPPoE-Client"? Ich weiß es nicht sicher ... würde aber schon aus diesem Grund so eine Konstruktion nicht aufbauen, denn das Paket könnte auch ganz normal vom Modemport zum CPU-Port weitergeleitet werden und dort dann vom System an die LAN-Bridge ausgegeben werden, wenn die wirklich weiter existiert.

Ob da ein "geswitchtes Netzwerk" seine Vorteile ausspielt oder ob da die Software-Bridge des Systems gewinnt und solche Pakete auf alle (LAN-)Ports dupliziert werden, weiß ich schlicht nicht ... ich würde vorsichtshalber den "worst case" annehmen und das hieße für mich, daß eine Konfiguration einer WAN-Bridge vom integrierten DSL-Modem der FRITZ!Box zu einem beliebigen LAN-Port, der sich mit anderen LAN-Ports in einem gemeinsamen "brinterface" aus der ar7.cfg befindet, nicht dafür sorgen kann, daß die eingehenden PPPoE-Pakete für einen Netzwerk-Client nicht von anderen LAN-Clients abgefangen oder mitgelesen werden können.

Den qualitativen Unterschied zu einem "gewöhnlichen Angriff" im LAN, dem natürlich jedes Gerät in einem LAN auch ausgesetzt wäre, habe ich versucht oben zu verdeutlichen (so wie ich ihn sehe) - die LAN-Kommunikation kann ich verschlüsseln, dank gemeinsamer Kenntnisse benötigter Schlüssel-"Rohstoffe" (egal ob Zertifikate, PSK, Kerberos, usw.) ... das ist mir bei der WAN-Kommunikation in aller Regel nicht möglich (zum BRAS des Providers), weil es an diesem "shared secret" mangelt.

Ist diese Kommunikation also offen und kann ein LAN-Client den Switch ausreichend verwirren (welche Möglichkeiten da bereits ettercap bietet, kann jeder nachlesen - falls das Spoofen auf L2 überhaupt notwendig sein sollte), dann kann er den eigentlich für die WAN-Bridge gedachten Verkehr auf sich umleiten und ihn nach Belieben manipulieren. Das passiert bei einer sauberen Trennung der "Verkehrswege" eben nicht, wäre sicherlich auch bei entsprechender Programmierung der Settings-Register des Switches in der FRITZ!Box denkbar, würde aber eben nicht dazu passen, daß da der PPPoE-Client für den BRAS an irgendeinem beliebigen Port von den vieren auf der LAN-Seite zu finden sein kann.

Beim Rest stimme ich Dir schon zu ... aber das bringt (nach meinem begrenzten Verständnis, das ist so viel CS, daß man teilweise ja auch raten muß und sich das mit den Grundprinzipien des Netzwerkens erklären muß, da kann man auch mal etwas übersehen, ich lasse mich also gerne überzeugen, wo mein Denkfehler liegt) eben auch nur dann einen Sicherheitsgewinn, wenn da ganz klar ist, wer Koch (WAN) und wer Kellner (LAN) ist. Wenn der Traffic "gemischt" wird, spielt die unterschiedliche Kapselung der Nutzlast keine Rolle mehr, solange da nicht noch etwas verschlüsselt wird.

Das mit der Verkabelung der FRITZ!Box habe ich aber auch nicht richtig verstanden:
Insofern kann ein Router durchaus einfach mit zwei Kabeln angeschlossen werden, einer am WAN-Port des Routers, einer am LAN-Port.
Hier meinst Du hoffentlich dasselbe wie ich ... in meinem ersten Beitrag dazu habe ich die Ports an der FRITZ!Box "LANx" und "LANy" genannt. Nach meinem Verständnis wäre dann der WAN-Port der FRITZ!Box mit der TAE-Dose verbunden, der WAN-Port der Firewall meinetwegen mit LAN2 der FRITZ!Box und der LAN-Port der Firewall mit LAN4. Nur als Beispiel, die FRITZ!Box hat natürlich dann auf LAN4 kein Gastnetz aktiviert, es könnte auch jeder beliebige LAN-Port der FRITZ!Box sein, ggf. sogar noch ein Switch zwischen der FRITZ!Box und der Firewall, wo dann an der FRITZ!Box nur ein einzelner LAN-Port belegt wäre von diesem Switch, die Firewall wäre dann ihrerseits mit beiden Kabeln an diesem Switch angeschlossen. Die synonyme Verwendung von "Firewall" und "Router" unterstelle ich hier auch. Und genau in dieser Konstellation wäre dann wieder die Trennung des Verkehrs zwischen LAN und WAN der Firewall nur noch durch unterschiedliche L3-Protokolle gewährleistet, auf L2 ist das "eine Brühe" (im Rahmen des Üblichen innerhalb eines geswitchten Netzwerks), die mit bekannten Angriffen auf L2 wieder konfrontiert wäre. Meine Überzeugung ... Feuer frei für Gegenargumente oder abweichende Thesen.

EDIT:
VLANs bieten dann natürlich diese Trennung auf L2 theoretisch schon wieder, wobei auch da eine solche Trennung in der FRITZ!Box ja nichts bringt, wenn sowohl der Modem-Port des 7PS (ich hab' die Nase voll vom Ausschreiben) als auch alle vier LAN-Ports zu derselben VLAN-ID gehören (nehmen wir die 7 vom Telekom-VDSL), weil nicht vorher geklärt ist, wo der PPPoE-Client (es muß ja auch nicht zwingend ein einzelner sein) angeschlossen ist. Mit diesen VLANs kann man dann eben ein gemeinsames Ethernet-Kabel wie zwei getrennte Kabel behandeln (nicht als Erklärung für Andre, mehr im Allgemeinen), dazu braucht es aber an beiden Kabelenden ein Gerät (einen VLAN-fähigen Switch), der das irgendwann wieder auf zwei physikalische Kabel auftrennt - auch ist das nicht auf zwei "virtuelle Kabel" beschränkt, so ein VLAN-Tag kann knapp 4100 unterschiedliche Werte annehmen.
 
Zuletzt bearbeitet:
Eine Firewall schützt eigentlich vor Angriffen von außen nach innen, nicht umgekehrt.
Das Abhören der PPPoE-Pakete vom internen LAN ist natürlich grundsätzlich möglich - aber nicht ganz einfach und bringt auch wenig, wenn man schon drinnen ist, was will man da noch die Außenanbindung hacken.
Umgekehrt ist der Zugriff von außen nach innen aber kaum machbar - schließlich hat das DSL-Modem keine IP, kann also aus dem Internet nicht erreicht werden. Auch an der WAN-Schnittstelle des Routers selbst liegt keine IP anm das IP-Protokoll ist hier ja nicht aktiv. Ein Angriff würde voraussetzen, dass jemand auf der DSL-Leitung statt einer mit PointToPoint Protokoll gekapselten Datenübertragung eine mit IP-Protokoll einspeist.
Das müsste tatsächlich funktionieren, wenn man einen eigenen DSLAM verwendet und statt des ProviderDSLAMs an der Kupferleitung anklemmt. Ich habe jedenfalls einen DSLAM rumstehen (wollte ich am Zweitwohnsitz zur Netzunterverteilung einsetzen) der alternativ zu PPP auch DHCP unterstützt.
Praktisch setzt das aber physikalischen Zugriff auf die DSL-Leitung voraus und ist damit kein Fernangriff. Also muss tatsächlich "was zu holen sein". Im Privatbereich kommt man da einfacher an die Daten, indem man durchs Fenster einsteigt und die Festplatten klaut...
 
Da haben wir eben unterschiedliche Vorstellungen, wofür eine Firewall (meinetwegen auch ein "Zwangsproxy" als einziges Outbound-Gateway) dienen kann und soll, aber es gibt ja sogar hier im Forum Leute, die jede ausgehende (FTP-)Verbindung noch überwachen (eigentlich sogar verhindern) wollen.

Ich hatte aber (dachte ich jedenfalls) schon im ersten Beitrag klargestellt, daß ich nur das "Zusammenwerfen" des Traffics von der WAN- und der LAN-Seite so einer Firewall für nicht tragbar halte und das eben aus prinzipiellen Erwägungen. Wer eine "bessere Firewall" braucht (ich könnte jetzt polemisch schreiben, daß die auch nicht mehr als CT von innen nach außen und entweder Forwarding von außen nach innen oder auch nicht macht und dabei die anderen Möglichkeiten (Shaping für Inbound, IDS, IPS) so eines Gerätes ignorieren), der sollte auch sicherstellen, daß diese ihm am Ende etwas bringt.

Den Gegenentwurf zu PPPoE-PT i.V.m. derselben FRITZ!Box als IP-Client im LAN habe ich ja schon vorher aufgemacht, mit einem "richtigen Modem", einer pfSense (wenn Du denn so eine Installation bevorzugst) und einer FRITZ!Box dahinter im IP-Client-Mode tritt dieses "L2-Gemenge" gar nicht erst auf (nicht mal theoretisch) und der Mehraufwand hält sich (meines Erachtens, auch das hatte ich ja schon geschrieben) in überschaubaren Grenzen bei gleichzeitig minimierten Unklarheiten (um nicht von Risiken zu sprechen, das bewerten wir offensichtlich unterschiedlich).

Das Beispiel mit dem Windows-Netzwerk (die Punkt-zu-Punkt-Verschlüsselung ist ja in einer Domäne schnell aktiviert) halte ich trotzdem für relevant ... wenn der Traffic der Clients untereinander nicht abhörbar ist wegen zusätzlicher Sicherungsmaßnahmen, dann macht es keinen Sinn, wenn dieser Traffic hinter einem PPPoE-Gateway zum DSL wieder "sichtbar" wird und ich als derselbe Client, vor dem das im LAN versteckt wurde, darauf wieder zugreifen kann.

Da geht es mir auch weniger um die realen Gefahren, als mehr um das prinzipielle "no go" einer solchen Lösung, die an die Stelle einer physischen Trennung (wie gesagt, VLAN lasse ich da noch gelten, auch wenn das eigentlich nur "logisch" ist) zweier solcher Bereiche nur die Trennung auf der Basis unterschiedlicher Protokolle setzt, wo am Ende nur eine einzelne Konfigurationseinstellung (oder nicht einmal eine solche) den Verkehr voneinander trennt.

Auch das Argument "Wenn ich schon drin bin, interessiert die Außenanbindung nicht mehr wirklich." kann ich so nicht nachvollziehen. Ein übernommenes Gerät im LAN bedeutet ja noch lange nicht, daß man auch Zugriff auf vertrauliche Daten auf anderen LAN-Clients hat.

Tauchen solche Daten dann aber in der "Außenkommunikation" auf und ich kann sie dort mitlesen, ist das "information disclosure" und etwas, was eine ordentliche Trennung zwischen WAN- und LAN-Traffic vermieden hätte, weil mein LAN-Client den WAN-Traffic gar nicht erst zu Gesicht bekommt.

Nehmen wir als Beispiel mal die Credentials für eine DynDNS-Anmeldung einer FRITZ!Box (auch eine solche könnte ja problemlos der PPPoE-Client bei diesem Passthrough sein), die sind bei HTTP-URLs nur mit "basic auth" "geschützt" (also gar nicht, ist ja nur Base64) und diese kann ich von einem LAN-Client unter meiner Kontrolle noch lange nicht irgendwo auftreiben lassen, weil dabei der eine Endpunkt eben der PPPoE-Client selbst ist.

Was kann ich damit anfangen? Ich könnte zum Beispiel versuchen, andere Clients anstatt auf den richtigen Server auf meinen eigenen irgendwo im Netz zu locken und dabei Credentials zu erbeuten, die mir dann wieder den Zugriff auf den PPPoE-Client selbst (also die Firewall/den Router als zentrale Schnittstelle des LANs) ermöglichen ... wie gesagt, waren jetzt nur die Daten, die mir als erstes einfielen und die sowohl unverschlüsselt auf der WAN-Seite sind als auch nicht ohne weiteres aus dem LAN ermittelt werden können, selbst wenn man sich da frei tummeln kann.

Das mit dem "Festplatten-Diebstahl" ist tatsächlich eine Lösung, aber auch der denkbar geringste Schaden, den Du damit anrichtest. Das bekomme ich nämlich mit (jedenfalls sollte man das unterstellen können) und damit weiß ich um die Gefahr und das Ergebnis.

Ein eingeschleuster "Lauscher", der mich und meine Daten über einen längeren Zeitraum ausspioniert, richtet einen ungleich größeren Schaden an (auch weil ich das viel schlechter abgrenzen und die Auswirkungen nicht korrekt einschätzen kann) und selbst wenn wahrscheinlich kein Privatmann sich für so wichtig hält, daß er das Ziel solcher Angriffe sein könnte, unterschätzen viele da die Gefahren total und denken immer noch, da müsse jemand hingehen und ganz gezielt sie angreifen.

Das wäre schon aufgrund des (hoffentlich) krassen Mißverhältnisses zwischen Wölfen und Schafen ein eher hoffnungsloses Unterfangen für die Wölfe - leider geht das weitgehend automatisiert und wenn man von einem Bot-Netz mit 100.000 Rechnern liest, kann sich niemand diese Dimension so richtig vorstellen, aber es wird hoffentlich auch niemand annehmen, daß da 10.000 Leute sitzen, die jeweils 10 fremde Rechner steuern, ja nicht einmal 1.000 Leute, die jeweils 100 Rechner im Griff haben. Dieses "es gibt einfachere Wege" und "ich bin es gar nicht wert angegriffen zu werden" ist schon vielen auf die Füße gefallen ... ein Lösegeld-Trojaner guckt sich nicht erst an, wer da vor dem Rechner sitzt, bevor er mit einer Verschlüsselung beginnt. Setzt an die Stelle der 100.000 Rechner einfach 100.000 Internet-Gateways in privaten Haushalten und wir sind wieder beim Thema der Router- und Netzwerksicherheit.
 
1. Die "Rechner", die im internen Netz mitlauschen könnten, sind die Fritzbox und der extra Router. Halbwegs vernünftige Switches senden die Pakete nicht wild umher (das war bei den alten Hubs noch oft so), wenn die Route zwischen Quell- und ZielMAC bekannt ist. Was ja, wenn der zusätzliche Router an die FBF angeschlossen ist, der Fall ist. Wenn eines der beiden Geräte kompromitiert ist, hat man eh ein Problem.
2. DNS - und DynDNS - macht der Router mit der externen IP. DNS und DynDNS in einer FBF gibts im ClientModus nicht.
3. Punkt2Punkt-Verschlüsselung mit Domainserver setzt einen Domainserver voraus. Im Heimbereich und in WGs eher untypisch.
4. Die zweitgrößte Sicherheitslücke im LAN sind WLAN-AP (die größte sind die User). Soll die FBF als WLAN-AP dienen, sollte pFSense eh auch als Firewall zwischen FBF und verkabeltem LAN dienen.
5. Ein Kompromitieren des internen Netzwerks hat überhaupt nichts mit PPPoE-PT zu tun.
6. Die "Doppelverbindung" zwischen FBF und pfSense auszunutzen, geht gerade nicht automatisch.

Natürlich ist ein extra DSL-Modem durchaus sinnvoll. Nutze ich ja auch. Ich glaube aber nicht, dass z.B. eine WG das zwingend bräuchte.
Das war ja der Anwendungsfall, bei dem ich die Ergänzung einer FBF um einen "Zwangsproxy" für sinnvoll halte: Wenn es hauptsächlich darum geht, den Internetzugang wg. möglicher Störerhaftung des Anschlussinhabers zu anonymisieren. Sei es mit einem kleinen OpenWRT, sei es mit pfSense (z.B. auf einem ThinClient). WLAN und Telephonie der FBF zu nutzen macht Sinn (schon wegen der eingebauten DECT-Basis); Sicherheit ist ansonsten mangels Admins für alle Rechner in einer WG eh jedermanns eigene Sache.
 
Das mit der Verkabelung der FRITZ!Box habe ich aber auch nicht richtig verstanden:

Hier meinst Du hoffentlich dasselbe wie ich ... in meinem ersten Beitrag dazu habe ich die Ports an der FRITZ!Box "LANx" und "LANy" genannt. Nach meinem Verständnis wäre dann der WAN-Port der FRITZ!Box mit der TAE-Dose verbunden, der WAN-Port der Firewall meinetwegen mit LAN2 der FRITZ!Box und der LAN-Port der Firewall mit LAN4.....

Bei der "damaligen" Implementierung von PPPoE-PT konnten ein (oder mehrere) Gerät(e) mit eigenen Zugangsdaten (z.B. PC mit extra Einwahldaten und Cfos-Treiber o.ä.) eine eigene PPP-Verbindung durch die FritzBox aufbauen.
Die FritzBox hat diese Verbindung einfach durchgereicht, der entsprechende Client war also quasi "nackig" im Internet, musste also zwingend seperat abgesichert werden im Gegensatz zu einem PC im "normalen" (firewallgesicherten) LAN.

Edit: Wenn ich mich recht erinnere hatte der per PPPoE-PT verbundene Rechner dann auch eine eigene öffentliche IP.
 
Zuletzt bearbeitet:
Zur Vorschaltseite (Zustimmung der Nutzungsbedingungen usw.) des WLAN-Gastzugangs: Grundsätzlich begrüße ich diese Funktion sehr, da die Gäste unserer Ferienwohnung unseren Gastzugang gern und häufig nutzen, aber ist das eigentlich schon zu Ende gedacht? Um Nutzungsbedingungen zu akzeptieren, sollte man diese ja erstmal lesen können. Genau der Punkt fehlt aber, wenn ich das richtig gesehen habe. Jemand ne Idee?
 
Zuletzt bearbeitet:
Hallo,
ich möchte mal die Frage von stefano69 (#16) wiederholen:

Kann man denn jetzt diese Labor installieren oder nicht?

Gruß
 
Da ich bei der letzten auch 3x einen Abbruch hatte,habe ich diesmal via Autoupdate der Box die Verantwortung überlassen und muss sagen, hat sie heute früh gut hin bekommen:rolleyes: Kann bis jetzt auch noch keinen Punkt kritisiere, WLAN ist wieder besser als in der letzten Labor, sogar ins 5GHz kommen die Geräte rein (Autokanal)
 
Hallo,
Update soeben von 06.30 auf 113.06.36-31656 BETA über Image-Datei völlig problemlos durchgeführt.

Leitungskapazität kbit/s 67034 24638
Aktuelle Datenrate kbit/s 51392 10046

Das sind die selben Werte wie vorher.

Bis jetzt nur folgenden neuen Fehler gefunden in WLAN-Funknetz-Bekannte WLAN-Geräte " Diesem Netzwerkgerät immer die gleiche IPv4-Adresse zuweisen" bleibt immer *nicht* ausgewählt.
 
1. Die "Rechner", die im internen Netz mitlauschen könnten, sind die Fritzbox und der extra Router. Halbwegs vernünftige Switches senden die Pakete nicht wild umher (das war bei den alten Hubs noch oft so), wenn die Route zwischen Quell- und ZielMAC bekannt ist.
Ich weiß nicht, ob Du jetzt absichtlich selektiv liest oder ich wirklich so unklar schreibe - lang ist es sicherlich jedesmal, weil ich versuche zu begründen. Daß ein Switch ein Paket in der Regel nur an den Port sendet, an dem nach seiner MAC-Address-Table der Client zu fnden sein sollte, habe ich selbst bereits geschrieben, das ist auch das, was ich meinte, wenn ich von "geswitchten Netzwerken" schrieb. Daß auf diese ebenfalls Angriffe möglich sind (Port Stealing), ist bekannt und ich habe für eine Erläuterung, was das ist und wie das geht, auf ettercap verwiesen.

Andre schrieb:
2. DNS - und DynDNS - macht der Router mit der externen IP. DNS und DynDNS in einer FBF gibts im ClientModus nicht.
Auch hier wieder ... ich schrieb ja ausdrücklich bei diesem Beispiel:
PeterPawn schrieb:
Nehmen wir als Beispiel mal die Credentials für eine DynDNS-Anmeldung einer FRITZ!Box (auch eine solche könnte ja problemlos der PPPoE-Client bei diesem Passthrough sein), [...]
und als PPPoE-Client für das PPPoE-PT einer FRITZ!Box wäre diese zweite(!) FRITZ!Box natürlich ein Router und würde nicht ihrerseits ebenfalls im Client-Mode betrieben.

3. Punkt2Punkt-Verschlüsselung mit Domainserver setzt einen Domainserver voraus. Im Heimbereich und in WGs eher untypisch.
Ich diskutiere ja gerne, aber dann müssen die Diskutanten auch über dasselbe Thema streiten. Ich wollte die generelle Notwendigkeit einer sauberen Trennung verteidigen und nicht mit "typischen Nutzungsszenarien" und deren Wahrscheinlichkeit konfrontiert werden. Die für mich entscheidende Frage ist, ob es möglich wäre, Du stellst immer wieder darauf ab, daß es auch andere alternative Möglichkeiten gäbe oder die von mir skizzierten Szenarien unwahrscheinlich wären. Zu einer solchen Wahrscheinlichkeit habe ich aber gar nichts geschrieben, nur zu einer solchen Möglichkeit. Nun kann man das ja als Paranoia ansehen, aber eine sichere Konfiguration erfordert in meinen Augen auch den Ausschluß solcher Möglichkeiten (soweit es technisch machbar und zumutbar ist), denn auch ein Lotto-Gewinn ist per se nicht wahrscheinlich, trotzdem sehnt ihn jeder Spielteilnehmer herbei ... bei einem Angriff auf die eigene Infrastruktur ist das merkwürdigerweise anders herum.

Auch 4. beschreibt wieder nur eine Alternative, die ich weder bestreite noch vor der ich die Augen verschließe. Warum diese meine Argumente in dieser Diskussion allerdings entkräften soll, verstehe ich wieder nicht ... damit wird eine andere Möglichkeit ja erneut nicht aus der Welt geschafft.

5. Ein Kompromitieren des internen Netzwerks hat überhaupt nichts mit PPPoE-PT zu tun.
Wenn ich das behauptet hätte ... ich beschreibe einen Zugriff auf die PPPoE-Daten aus einem ohnehin schon kompromittierten LAN heraus und habe Dir ein Beispiel gegeben (anstatt es nur zu behaupten), welche Daten davon betroffen sein könnten, die man bei einer "einfachen Kompromittierung" im LAN nicht ermitteln kann (weil man keinen Zugriff auf Ethernet-Pakete der WAN-Seite hätte) und was man mit diesen Daten dann anfangen könnte.

6. Die "Doppelverbindung" zwischen FBF und pfSense auszunutzen, geht gerade nicht automatisch.
Da ich nicht sehe, auf welchen Weg sich das beziehen soll (ich habe drei verschiedene Gefahren aus "Paketsicht" versucht zu beschreiben, mit unterschiedlichen Auswirkungen), kann ich dem nicht widersprechen, weil es sowohl richtig als auch falsch sein könnte, je nach Kontext (und nach meinem Verständnis, aber wir schreiben wohl ohnehin aneinander vorbei).

Das war ja der Anwendungsfall, bei dem ich die Ergänzung einer FBF um einen "Zwangsproxy" für sinnvoll halte: Wenn es hauptsächlich darum geht, den Internetzugang wg. möglicher Störerhaftung des Anschlussinhabers zu anonymisieren.
Wenn das ein Plädoyer für einen "Zwangsproxy" als weitere Aufgabe eines solchen zusätzlichen Gerätes ist, der natürlich dann an derselben Stelle wie eine Firewall für eingehenden Verkehr sitzen würde (nur die andere Richtung reguliert), sehe ich einen Widerspruch zu vorher, wo eine Firewall von außen nach innen schützen sollte. Macht sie natürlich im Prinzip auch nur, hier habe ich sträflicherweise genauso wie Du nicht zwischen der "Firewall-Funktion" für eingehenden Netzwerkverkehr und der Bezeichnung des zusätzlichen Netzwerk-Gerätes als "Firewall" unterschieden - wenn das Verwirrung gestiftet haben sollte, tut es mir leid.

Könnte nun ein "böswilliger WG-Bewohner" (das kann auch der kleine Japaner im Internet-Radio sein, der da immer die Knöpfe an der Jukebox drückt für den nächsten Titel) denn nun nach Deiner Meinung an einem solchen Zwangsproxy vorbei eine Verbindung aufbauen oder nicht, unabhängig davon, wie wahrscheinlich das ist? Würde der alternative Aufbau (gesondertes Modem) diesen Verbindungsaufbau unterdrücken können?

Kannst Du Dir einen modularisierten Angriff vorstellen, bei dem anhand der Feststellung, daß sich im erreichbaren Netzwerk eines kontrollierten Relays (meinetwegen auch "Zombies") auch PPPoE-Pakete "tummeln", ein passendes PPPoE-Modul zum Einsatz kommt, zumal einige Provider ja mit "Standard-Credentials" bei einer solchen PPPoE-Anmeldung arbeiten und "doppelte Verbindungen" auf anderem Weg vermeiden, z.B. indem sie ihrerseits eine ältere "Verbindung" einfach kappen? Das wäre schon ein DoS-Szenario für den "eigenen Anschluß" (also den gewünschten PPPoE-Partner), bei UDP-Verkehr und der "Übernahme" der IP-Adresse der vorhergehenden PPPoE-Anmeldung (wenn ein Provider so etwas machen sollte, da ändert sich dann aus Providersicht nur die MAC-Adresse des PPPoE-Gegenparts) hätte man so zumindest schon mal die (ggf. auch nur die "verspäteten") Antwort-Pakete auf bereits vorher erfolgte ausgehende UDP-Anfragen (denen ist es egal, ob das derselbe PPPoE-Gespächspartner ist, die haben eine IP-Adresse als Ziel) und könnte diese (als vorsichtiger Mensch sage ich vermutlich) schon mal manipulieren, bevor man sie ins LAN entläßt. Das beträfe u.a. auch DNS-Verkehr ...

Und dabei stelle ich jetzt wieder nicht die Frage, wie wahrscheinlich ein solches Szenario ist und ob es nicht viel einfacher wäre, dem Benutzer im Netz eine gefälschte IP-Adresse über einen passenden Link in einer Spam-Mail unterzuschieben. Mir geht es nur darum, ob Du dieses Szenario für denkbar hältst und es technisch realisierbar wäre. Der Rest ist dann einfach wieder Ansichtssache und eine Frage der persönlichen Bewertung. Ich nehme auch nicht an, daß ich morgen vom Blitz getroffen oder vom Bus überfahren werde, trotzdem passiert das mit einiger Wahrscheinlichkeit auch morgen jemandem auf der Welt - sicherlich nicht 100.000 Leuten auf einmal, aber wenn man einer der Betroffenen ist, ist einem die Häufigkeit oder wie unwahrscheinlich das am Ende war, egal ... vor allem dann, wenn man es hätte vermeiden können (anderer Aufbau).

Wenn ich zur Diskussion herausfordere (so etwas macht mir zugegebenermaßen auch Spaß), dann müssen wir aber auch über dasselbe Thema "streiten" und nicht aneinander vorbeireden. Auch das ist denkbar, dann brauchen wir aber nicht mehr auf die Argumente des anderen eingehen (und diese falsch interpretieren, auch wenn ich Dir da keine Absicht unterstellen will, ist es m.E. mehrfach so, daß Du mich da auf das Heftigste mißverstanden und das dann auch falsch wiedergegeben hast als meine Argumentation), dann führt eben jeder seinen eigenen Monolog.
 
Hallo,
Update soeben von 06.30 auf 113.06.36-31656 BETA über Image-Datei völlig problemlos durchgeführt.
...
Von der letzten offiziellen Firmware mag es funktionieren.
Von der letzten Labor aber immer noch nicht!
 
Bei mir hat es ohne Probleme geklappt!!
 
Gerade eben per Updatefunktion der Box die Laborversion installiert. Hat ohne Probleme gaklappt.
 
Au wei, so viele ultra-lange Monsterbeiträge, die mit dieser Labor-Firmware rein gar nichts zu tun haben....

Bei mir ließ sich das Update problemlos einspielen, jedoch habe ich den Eindruck, daß sich die WLAN Clients im 5 GHz Band nur noch ungerne mit der Box verbinden. Das war vor kurzem noch besser. Hat noch jemand diese Probleme?
 
Au wei, so viele ultra-lange Monsterbeiträge, die mit dieser Labor-Firmware rein gar nichts zu tun haben....

Bei mir ließ sich das Update problemlos einspielen, jedoch habe ich den Eindruck, daß sich die WLAN Clients im 5 GHz Band nur noch ungerne mit der Box verbinden. Das war vor kurzem noch besser. Hat noch jemand diese Probleme?

kann auch nicht mehr funktionieren, da die Box mir das 5ghz Netz wieder so benannt hat wie das 2,4 ghz Band.
Schaue mal nach ob`s bei dir auch so ist.
 
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.