Welche Ports benötigt die "Fritz!App Fon"?

[Fischers Freetz]

Welche Ports muss ich für diese App auf einer Firewall freigeben, die zwischen dem Androiden und der FritzBox steht, damit das Telefonieren übers Festnetz gelingt? Die SIP-Ports 5060 und 5061 sind klar, aber welche müssen es noch sein?

 

[koyaanisqatsi]

Für VoIP

Abend

voipcfg {
        dnsport = 7077;
        rtpport_start = 7078;
        sip_srcport = 5060;

Wobei:
dnsport = UDP
rtpport = 7078+32 (7078-7110) = UDP
sip_srcport = TCP/UDP
...ist.

 

[Fischers Freetz]

Danke.

Aber scheint noch was zu fehlen: obwohl ich die Ports 5060, 5061, und 7077 bis 7010 in beide Richtungen für TCP+UDP freigegeben habe, kommt die Android-App nicht an die FB.

 

[PeterPawn]

aber welche müssen es noch sein?

Wenn es dieselben sind wie bei der iOS-Version, brauchst Du zusätzlich noch:

49000 - TR-064 für die "Abfrage" der Schnittstellendefinitionen
49443 - TR-064 über SSL für Anmeldung und Abfrage von Einstellungen
80 - HTTP für die Abfrage des Telefonbuchs oder der Anrufliste, das werfe ich immer durcheinander; eines von beiden gibt es offenbar über TR-064 nicht als Schnittstelle, daher wird da auf HTTP (inkl. potentieller Sicherheitslücke durch Übermittlung der SID im Klartext) zurückgegriffen

Ich gehe dabei davon aus, daß Du in Deinem LAN noch eine Firewall hast, die Du jetzt konfigurieren willst.

Von außen (wo es bei der FB selbst aber ohnehin nicht geht) wäre das auch eine schlechte Idee ...

Wie Du auf 5061 kommst, verstehe ich allerdings nicht so richtig.

 

[koyaanisqatsi]

Abend

Falls SIPS Unterstütztung, dann Port 5061.
Da seh ich aber noch Jahrzehntelang kein Land in Sicht.
Genauso für SRTP und ZRTP. Wer will sowas schon.
NSA & GCHQ jedenfalls nicht.

 

[Fischers Freetz]

Mist! Wenn ich Port 80 erlauben muss, kann ich die Zugriffsregel sowieso gleich kippen. Ich will eigentlich verhindern, daß mein Androide etwas anderes als telefonieren an/mit der FB machen kann. Und gerade die Möglichkeit zur Anmeldung an der Web-Oberfläche auf Port 80 ist mir ein Dorn um Auge. Es gibt leider keine Möglichkeit in der FB, Anmeldungen über die Web-Oberfläche auf Clients zu beschränken, die per LAN verbunden sind. Oder habe ich da etwas übersehen?

 

[koyaanisqatsi]

Benutzer ohne Konfigurationsrechte anlegen

...mal versuchen.

 

[PeterPawn]

Wenn ich Port 80 erlauben muss

Telefonieren an sich funktioniert wahrscheinlich auch ohne Port 80 ... wie gesagt, ich weiß nicht mehr genau, ob darüber die Anrufliste oder das Telefonbuch ausgelesen wird.

Wobei die Möglichkeiten einer "vagabundierenden App" an Port 49000/49443 sogar noch weiter gehen, als es das pure GUI erlaubt ...

Es gibt leider keine Möglichkeit in der FB, Anmeldungen über die Web-Oberfläche auf Clients zu beschränken, die per LAN verbunden sind. Oder habe ich da etwas übersehen?

Das wäre doch mal ein sinnvoller Vorschlag in der "Wunschliste" an AVM. Die - optionale - logische Trennung von WLAN und LAN (getrennte Adressen oder sogar VLANs) bzw. im Idealfall sogar die Möglichkeit, das WLAN mit einem einzelnen LAN-Port als "abgetrennten Access-Point" zu betreiben, also den WLAN-Verkehr nicht über "dev dsl", sondern über einen einzelnen zugewiesenen LAN-Port oder eine VLAN-ID zu "bridgen".

 

[Fischers Freetz]

Wobei die Möglichkeiten einer "vagabundierenden App" an Port 49000/49443 sogar noch weiter gehen, als es das pure GUI erlaubt ...

Hört sich eher so an, als wenn man lieber gar keinen SIP-Client benutze sollte.

Obwohl, wenn ich darüber richtig nachdenke: der Missbrauch dieser Ports muss ja noch nicht mal vom SIP-Client veranstaltet werden. Da reicht es doch sogar, daß das Telefon nur per WLAN mit der FB verbunden ist.

 

[PeterPawn]

OT:

Da reicht es doch sogar, daß das Telefon nur per WLAN mit der FB verbunden ist.

Der Android-Client (egal ob gerootet oder nicht, es wird auf einen gerooteten Gerät allerdings leichter sein) ist genau in demselben Umfang angreifbar (und kann damit als Anchor für einen Angriff im LAN verwendet werden), wie jedes andere Gerät (vom iPhone mit Jailbreak bis zum verwundbaren NAS mit "alter" Software) auch. Solange die Leute wirklich jeden Mist glauben, was ihnen die neue App alles bringen soll ... solange wird es auch immer wieder Angriffe über solche Geräte geben. Selbst in Apps, die erst durch die wesentlich strengeren Apple-Kontrollen mußten, bevor sie jeder laden durfte, wurde schon Schadcode "versteckt".

Ein SIP-Telefon "mit Schnur" (z.B. SNOM oder Grandstream) kann aber ebenso zum "Feind" im internen Netz werden, wie ein Drucker (das mit dem Doom auf dem Drucker fand ich durchaus spaßig: http://heise.de/-2392014) oder sogar ein AVM WLAN-Repeater oder ein DVB-Recorder mit Enigma2.

Daraus den Schluß abzuleiten, das wäre ohnehin alles zu gefährlich, ist - trotz meiner eigenen kritischen Sicht auf mögliche Sicherheitsprobleme - wohl auch nicht der richtige Weg ...

Wenn das Android-Handy so "gefährlich" ist, dann greift es eben nicht die FRITZ!Box, sondern irgendein anderes spannendes Gerät in der Nachbarschaft (aus Netzwerksicht) an.

Da hilft dann eben kein Abschalten, nur der sichere und bewußte Umgang mit neu zu installierender Software auf allen Geräten.

 

[andiling]

Die Fon App ist ein bisschen anders als ein Sip Client, daher würde ich beides bzgl. benötigter Protfreigaben nicht in einen Topf werfen. Reine Sip Clients sind da weniger anspruchsvoll und beschränken sich auf VoIP.

 

[Fischers Freetz]

PeterPawn: klar, das sind Dinge, die mir alle bekannt sind. Meine Anmerkung galt eher der Tatsache, daß sich die FritzBox anscheinend sehr einfach von internen Anwendungen ansprechen und abfragen lässt, und das auch noch auf sehr vielen Ports und alles im Klartext.

 

[PeterPawn]

daß sich die FritzBox anscheinend sehr einfach von internen Anwendungen ansprechen und abfragen lässt, und das auch noch auf sehr vielen Ports und alles im Klartext.

Na ja, da ist die FRITZ!App Fon eigentlich eher ein positives Beispiel. Bis auf den einen Ausreißer beim Zugriff auf Telefonbuch/Anrufliste erfolgt dort die Kommunikation (zumindest bei der iOS-Variante, aber vermutlich auch im Android) vorbildlich verschlüsselt und ein interner Angreifer hat mehr Chancen, wenn er die Kommunikation eines beliebigen Browsers mit der Box belauscht. Die App ist da - obwohl offiziell nur für den Zugriff von innen konzipiert - nachgerade vorbildlich (den Ausrutscher mal außer acht gelassen, ältere Firmware kann nach innen auch kein HTTPS ohne daß man es nach außen auch freigegeben hat - das entschuldigt den Ausrutscher nicht, erklärt ihn aber).

 

[Fischers Freetz]

... (den Ausrutscher mal außer acht gelassen, ältere Firmware kann nach innen auch kein HTTPS ohne daß man es nach außen auch freigegeben hat - das entschuldigt den Ausrutscher nicht, erklärt ihn aber).

Das ist ja zum Glück geändert worden: in dem FritzOS 6.2 ist es möglich, die FB über https://fritz.box/ anzusprechen, ohne gleichzeitig die Anmeldung per Internet aktivieren zu müssen. Leider gibt es aber immer noch keine Möglichkeit, die Anmeldung auf Port 80, also ohne SSL, zu deaktivieren. Zumindest nicht über die Weboberfläche. Dazu müsste man vielleicht mal per telnet auf der FB schauen, ob man dem Webserver einfach den Port wegnehmen kann.

 

[koyaanisqatsi]

Moin

Ja, das geht.
Hab ich auch so gemacht...
nvi /var/flash/ar7.cfg

websrv {
        port = "[color="red"]12345[/color]";
        https_port = "";
        read_timeout = 15m;
        request_timeout = 30s;
        keepalive_timeout = 5m;
        nokeepalive = "*";
        errordir = "/usr/www/html/errors";
        webdir = "/usr/www";
        cgidir = "cgi-bin";
        indexfn = "index.var", "index.htm", "index.html";
        users_only_for_https = yes;
        cors_allow_origins = "*.avm.de";
        cors_allow_headers = "SOAPACTION", "Content-Type", "Origin";
        cors_allow_methods = "GET", "POST", "OPTIONS";
        cors_max_age = 1d;
}

...ändern, speichern und sofort reboot.

 

[PeterPawn]

Das ist ja zum Glück geändert worden:

Richtig ... aber erst ab 06.20 und die App unterstützt auch frühere Firmware-Versionen. Außerdem ist leider immer noch eine Kopplung zwischen dem extern und dem intern verwendeten HTTPS-Port vorhanden, d.h. wer extern den Port verbiegt, um die Box bei irgendwelchen Portscans nicht zu exponieren, muß im Moment auch intern mit diesem abweichenden Port leben, was das Hantieren mit einer HTTPS-URL für den internen Zugriff auch unnötig kompliziert.

Abschalten läßt sich der HTTP-Zugriff per se nicht, man kann aber durch Änderungen in der Datei "/usr/www/html/index.lua" ein HTTP-Redirect auf eine HTTPS-Verbindung bewirken, dabei kann man dann auch gleich noch den u.U. geänderten Port mit übermitteln.

Alternativ kann man den HTTP-Port 80 in der ar7.cfg ändern. Das wirkt sich dann aber auch auf die Apps aus, da es m.W. keine Möglichkeit gibt (auch nicht per TR-064), den aktuell verwendeten HTTP-Port zu ermitteln.

 

[Fischers Freetz]

websrv {
        port = "[color="red"]12345[/color]";
        https_port = "";

Hast Du Dich da jetzt vertan, meinst Du vielleicht umgekehrt? Der Port für https soll doch nicht leer sein, sondern der normale Port.

 

[Fischers Freetz]

Alternativ kann man den HTTP-Port 80 in der ar7.cfg ändern. Das wirkt sich dann aber auch auf die Apps aus, da es m.W. keine Möglichkeit gibt (auch nicht per TR-064), den aktuell verwendeten HTTP-Port zu ermitteln.

Welche Anwendungen benötigen denn zwingend unverschlüsselten Zugang zu Port 80 und können verschlüsselt auf Port 443 zugreifen?

 

[koyaanisqatsi]

Nee, das ist schon richtig so.
Den Fernzugang brauch ich nicht. Ich komme auch ohne extra Freigaben ins "Heimnetz" (mit Proxy).
Denn der HTTP Port ist so (relativ) sicher vor XSS Attacken.
Bei mir gibt es auch keine 169.254.1.1 (Notfallip) mehr.
Und Apps benutz ich nicht, denn ein App kann ein anderes App auspionieren.
Oder gleich den ganzen Verkehr an "Irgendjemanden" übermitteln.
Und: Mit einem busybox httpd auf der Box kann ich mit CGI Skripten das Webinterface, NAS und MY!Fritz umschalten.
Das ist extrem simpel.

So schaltet man das Webinterface auf etwas harmloses um...
cat cgi-bin/chgwif.cgi

#!/bin/sh
echo 'Content-Type: text/plain
'
/var/media/NEW_LINK/scripts/rc.changewebif ${QUERY_STRING}
if [ ${QUERY_STRING} == 'status' ]
then
echo 'Status der gesetzten Softlinks'
else
echo 'Webinterface umgeschaltet'
fi
#EOF

cat scripts/rc.changewebif

#!/bin/sh
case $1 in
status) ls -la /var/html* ;;
*) if [ -x  /var/html/cgi-bin/index.cgi ]
then
rm /var/html
ln -sf /usr/www/avm /var/html
echo 'AVM'
else
rm /var/html
ln -sf /var/media/NEW_LINK /var/html
echo 'USB'
fi
;;
esac
#EOF

/cgi-bin/chgwif.cgi?status

lrwxrwxrwx    1 root     root            19 Sep 24 11:51 /var/html -> /var/media/NEW_LINK
lrwxrwxrwx    1 root     root            19 Sep 24 11:50 /var/html.myfritz -> /var/media/NEW_LINK
lrwxrwxrwx    1 root     root            19 Sep 24 11:50 /var/html.nas -> /var/media/NEW_LINK
lrwxrwxrwx    1 root     root            19 Sep 24 11:02 /var/htmltext.db -> /etc/htmltext_de.db
Status der gesetzten Softlinks

Dabei ist es dann auch egal, ob mit HTTP oder HTTPS zugegriffen wird.
Das gilt für beide.

 

[PeterPawn]

Welche Anwendungen benötigen denn zwingend unverschlüsselten Zugang zu Port 80 und können verschlüsselt auf Port 443 zugreifen?

Wir reden offenbar aneinander vorbei.

Den unverschlüsselten Zugang benötigt z.B. eben die FRITZ!App Fon, die greift von sich aus nicht auf die HTTPS-Verbindung zurück, obwohl sie es nach einem Redirect wohl auch beherrscht (das scheint aber vom "Vertrauen" des zugrunde liegenden Betriebssystems in das Zertifikat der Box abhängig zu sein).

Den unverschlüsselten Zugang kann man so z.B. für Browser, die durch einfache Eingabe von "fritz.box" auf die Startseite der FRITZ!Box zugreifen wollen, auf eine gesicherte Verbindung umleiten.

Einem Zugriff per "deep link" auf dem unverschlüsselten HTTP-Port kann man nur durch Änderung dieses Ports entgegen wirken, das beeinflußt dann eben auch andere "Clients", egal ob das nun Apps sind oder nur ein ganz normaler Browser. Ich kenne jedenfalls keine Möglichkeit, den aktuell verwendeten HTTP-Port ohne Portscan zu ermitteln, also hängt man mit einer solchen Änderung alle "normalen" Clients auch ab.
Wenn man die in Frage kommenden "deep links" kennt und auch dort entsprechende Redirect-Seiten hinterlegt, kann man aber auch diese Zugriffe "umlenken", solange der Client anstelle einer HTTP-URL auch eine HTTPS-URL akzeptiert.

Die von Dir offenbar als funktionierend erachtete Änderung des HTTP-Ports auf "leer" funktioniert m.W. nicht. Zwar wird dadurch wirklich kein HTTP-Server gestartet (der ctlmgr scheitert an der falschen Konfiguration), aber eben auch kein HTTPS-Server. Man kann also durch die Angabe eines leeren Ports zwar den kompletten HTTP(S)-Server der Box stilllegen (das gilt dann auch für NAS und myFritz), aber den HTTP-Port einzeln zu "töten" funktioniert nach meiner Erfahrung nicht.

Ich benutze (bei eigener erweiterter Busybox) bei mir den httpd der Busybox auf Port 80 zur Umleitung aller Zugriffe auf die Startseite des AVM-GUI auf eine HTTPS-Verbindung und habe dazu den HTTP-Server des ctlmgr auf einen anderen Port "verbogen".