Portfreigabe an Raspberry für Zugriff von außerhalb. DynDNS vorhanden

[HanZ]

Hallo zusammen,

ich habe nun schon länger eine eigene Domain die via DynDNS von selfhost.de auf meine Synology zeigt.

Ich wollte nun noch meinen Raspberry von außerhalb zugänglich machen, insbesondere um meinen 3D-Drucker von unterwegs abschalten zu können via Funksteckdose. Das ganze läuft über ein Webinterface via lighttpd.

Dafür habe ich nun einen Port (zufällig gewählt, :1411) an Port 80 meines Raspberrys freigegeben.

You do not have permission to view link please Anmelden or Registrieren

Ich gehe nun eigentlich davon aus, dass wenn ich DOMAIN.de:1411 aufrufe, ich auf das Webinterface meines Raspberrys komme. Passiert aber nicht.

Wo ist mein (Gedanken-)Fehler?

Ansonsten sind für die Synology noch 80 an 80, 443 an 443, 5000 - 5001 an 5000 - 5001, 32400 an 32400 und 1194 an 1194 freigeben.

Liebe Grüße
HanZ

 

[alter_Bekannter]

Hast du es schon von außerhalb des Netzwerks versucht?

Außerdem solltest du generell noch weitere Freigaben versuchen. Die System auf Consumer Routern sind mehr als bekannt dafür einfach Scheisse zu sein.

 

[HanZ]

Habe mal schnell von außerhalb getestet, ohne Erfolg. Am Pi selbst muss ich ja nichts mehr einstellen oder?

Könnte es Probleme mit https/SSL geben? Das Zertifikat hierfür liegt auf der Synology.

 

[alter_Bekannter]

Des Standardport für Https ist 443. Außerdem könnte es sein das dein Webinterface nur auf bestimmte Hostnamen hört. Das wäre am Pi noch zu prüfen.

 

[HanZ]

Wie prüfe ich das am Pi?

Port 443 ist wie oben beschrieben auf die Synology freigegeben. Ich will am Pi aber überhaupt kein SSL nutzen.

 

[alter_Bekannter]

Logs und Configfile/Doku vom Webinterface.

 

[sia]

Was für ein Router ist es denn?

Security by obscurity ist btw mist.

 

[alter_Bekannter]

Jupp, wer daran wirklich interessiert ist kann die Range in der du zu finden bist schnell hinreichend einschränken. Ich bezweifle das es im deutschpsrachigen Rum mehr als ein paar hundert Millionen Adressen für Verbraucher Anschlüsse gibt. Allerdings gibts noch andere Gründe die Adresse nicht hier zu posten.

 

[HanZ]

Es handelt sich um eine FRITZ!Box 7490.

Auf was genau bezieht sich das "Security by obscurity"?

 

[KePa]

Auf dem Pi:

1. sudo apt-get install tcpdump (falls noch nicht installiert)
2. sudo tcpdump -n tcp port 80
3. Während Schritt 2 läuft: Verbindungsversuch von ausserhalb durchführen

Sollte das NAT der Fritzbox funktionieren, sollten Anfragen auf der PI Konsole sichtbar werden. Solltest du den Log hier posten, würde ich dir empfehlen zumindest die öffentliche IP Adresse darin unkenntlich zu machen.

 

[musv]

Ich gehe nun eigentlich davon aus, dass wenn ich DOMAIN.de:1411 aufrufe, ich auf das Webinterface meines Raspberrys komme. Passiert aber nicht. Wo ist mein (Gedanken-)Fehler?

Ist eigentlich korrekt so. Punkte, die du kontrollieren solltest:

• Kannst du über dieselbe Adresse + anderen Port die Fritzboxoberfläche erreichen? D.h. zeigt DynDNS auf Deine IP?
• Stimmt die heimnetzinterne IP des PI mit der Freigabe in der Fritzbox überein? Das Problem dabei ist DHCP. Du kannst nicht davon ausgehen, dass die Fritzbox dem PI bei jedem Neustart dieselbe IP zuweist. Ich benutz deshalb sogar statische IPs für alle dauerhaften Geräte und DHCP nur für Gäste.
• Hast du bei der Anwendung auch HTTP-Server ausgewählt?

Ob du innerhalb oder außerhalb des Netzes bist, ist eigentlich egal zum testen. Wenn du die DynDNS-Adresse aufrufst, wirkt das so, als wärst du außerhalb. Auch brauchst du für HTTP kein Zertifikat.

Auf was genau bezieht sich das "Security by obscurity"?

Soll heißen, dass du Dir durch die Portänderung einen Sicherheitsgewinn versprichst, der in Wahrheit aber keiner ist. Versucht Dich irgendjemand zu hacken, dann bekommt er mit einem Portscanner problemlos auch den veränderten Port raus.

In der Realität bringt der veränderte Port aber tatsächlich etwas. Ich verwende die Methode für meinen Notfall-SSH-Zugang. Als ich den früher auf den Standardport hatte, konnte ich 3-4x pro Tag diverse Wörterbuchattacken im Log beobachten. Durch den veränderten Port sind diese Angriffe auf 0 runtergegangen. Liegt einfach daran, dass die meisten Hackerscripte vermutlich das große weite Netz nur auf den Standardports abscannen. Alles andere ist zu aufwändig.

Trotzdem solltest du natürlich wenigstens ein Login+Passwort als Zugriffsschutz einrichten auf dem Lighttpd, um

You do not have permission to view link please Anmelden or Registrieren

anderer Leute zu unterbinden.

 

[HanZ]

You do not have permission to view link please Anmelden or Registrieren

Also so wie es aussieht, kommt eine Anfrage an. Nach jedem erneuten Aufruf im Browser kamen weitere Zeilen hinzu. Kannst du da was rauslesen?

Spoiler

[src=bash]sudo tcpdump -n tcp port 80
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
12:29:37.098481 IP 77.177.XXX.XX.60668 > 192.168.1.12.80: Flags , seq 2230323 094, win 8192, options [mss 1452,nop,wscale 8,nop,nop,sackOK], length 0
12:29:37.098775 IP 192.168.1.12.80 > 77.177.XXX.XX.60668: Flags [S.], seq 673101 900, ack 2230323095, win 29200, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
12:29:37.100211 IP 77.177.XXX.XX.60668 > 192.168.1.12.80: Flags [.], ack 1, win 260, length 0
12:29:37.100852 IP 77.177.XXX.XX.60668 > 192.168.1.12.80: Flags [P.], seq 1:199, ack 1, win 260, length 198: HTTP
12:29:37.101128 IP 192.168.1.12.80 > 77.177.XXX.XX.60668: Flags [.], ack 199, wi n 237, length 0
12:30:07.101410 IP 77.177.XXX.XX.60668 > 192.168.1.12.80: Flags [F.], seq 199, ack 1, win 260, length 0
12:30:07.101820 IP 192.168.1.12.80 > 77.177.XXX.XX.60668: Flags [F.], seq 1, ack 200, win 237, length 0
12:30:07.103294 IP 77.177.XXX.XX.60668 > 192.168.1.12.80: Flags [.], ack 2, win 260, length 0
12:30:07.103726 IP 77.177.XXX.XX.60669 > 192.168.1.12.80: Flags , seq 283973473, win 8192, options [mss 1452,nop ,wscale 8,nop,nop,sackOK], length 0
12:30:07.104102 IP 192.168.1.12.80 > 77.177.XXX.XX.60669: Flags [S.], seq 1359865903, ack 283973474, win 29200, opt ions [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
12:30:07.106343 IP 77.177.XXX.XX.60669 > 192.168.1.12.80: Flags [.], ack 1, win 260, length 0
12:30:07.106345 IP 77.177.XXX.XX.60669 > 192.168.1.12.80: Flags [P.], seq 1:199, ack 1, win 260, length 198: HTTP
12:30:07.106908 IP 192.168.1.12.80 > 77.177.XXX.XX.60669: Flags [.], ack 199, win 237, length 0
12:30:17.082642 IP 77.177.XXX.XX.60670 > 192.168.1.12.80: Flags , seq 3333034325, win 8192, options [mss 1452,nop,wscale 8,nop,nop,sackOK], length 0
12:30:17.082978 IP 192.168.1.12.80 > 77.177.XXX.XX.60670: Flags [S.], seq 1881524004, ack 3333034326, win 29200, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
12:30:17.084968 IP 77.177.XXX.XX.60670 > 192.168.1.12.80: Flags [.], ack 1, win 260, length 0
12:30:17.084970 IP 77.177.XXX.XX.60670 > 192.168.1.12.80: Flags [P.], seq 1:199, ack 1, win 260, length 198: HTTP
12:30:17.085541 IP 192.168.1.12.80 > 77.177.XXX.XX.60670: Flags [.], ack 199, win 237, length 0
^C
18 packets captured
18 packets received by filter
0 packets dropped by kernel[/src]

Kannst du über dieselbe Adresse + anderen Port die Fritzboxoberfläche erreichen? D.h. zeigt DynDNS auf Deine IP?

Wie soll ich denn die FRITZ!Box-Oberfläche erreichen? Hat die auch einen freigegebenen Port? DynDNS, also meine IP zeigt mit Port 80 auf meine Synology, dort kommt also das Verzeichnis /volume1/web zu Ansicht, wenn das die Frage beantwortet? Wenn nicht, habe ich sie nicht genau verstanden.

Stimmt die heimnetzinterne IP des PI mit der Freigabe in der Fritzbox überein?

Ja, der Pi hat die feste IP 192.168.1.12 bekommen.

Hast du bei der Anwendung auch HTTP-Server ausgewählt?

Auch das verstehe ich nicht genau. Ob im Browser als Protokoll http: aufgerufen wurde?

Soll heißen, dass du Dir durch die Portänderung einen Sicherheitsgewinn versprichst, der in Wahrheit aber keiner ist.

Das war gar nicht mal unbedingt als Sicherheitsgewinn gedacht, sondern weil der Standardport, also DOMAIN.TLD, ja auf meine Synology zeigt. Um auf meinen Pi zu kommen, dachte ich zumindest, müsste ich dann über einen anderen Port gehen. Und 1411 war halt ne Zahl die ich mir gut merken konnte. Falscher Gedanke?

Trotzdem solltest du natürlich wenigstens ein Login+Passwort als Zugriffsschutz einrichten auf dem Lighttpd

Das ist klar, hatte eh geplant das dann per .htaccess zu limitieren.

 

[musv]

Wie soll ich denn die FRITZ!Box-Oberfläche erreichen? Hat die auch einen freigegebenen Port? DynDNS, also meine IP zeigt mit Port 80 auf meine Synology, dort kommt also das Verzeichnis /volume1/web zu Ansicht, wenn das die Frage beantwortet? Wenn nicht, habe ich sie nicht genau verstanden.

Wenn auf Port 80 die Synology erscheint, dann scheint das schon mal zu klappen.

Auf die Fritzbox kannst du selbstverständlich auch über die DynDNS-Adresse kommen:
Internet → Freigaben → FRITZ!Box-Dienste

Ja, der Pi hat die feste IP 192.168.1.12 bekommen.

Wie gesagt, DHCP ändert das bei einem Neustart des PI (oder der Fritzbox) auch gern mal und dann zeigt Deine Freigabe ins Leere.

Auch das verstehe ich nicht genau. Ob im Browser als Protokoll http: aufgerufen wurde?

Wenn du eine Freigabe anlegst (der Dialog vor Deinem Screenshot) kannst du die Anwendung auswählen. Und da wird Dir angeboten:

• HTTP-Server
• HTTPS-Server

Im Grunde genommen gibt Dir die Drop-Downlist nur die Ports vor. Weiß aber nicht, ob das noch irgendwas mit den Zertifikaten bei HTTPS macht.

 

[KePa]

Na die Portfreigabe ansich scheint ja zu gehen, sonst würde der TCP Handshake nicht zustande kommen:

12:29:37.098481 IP 77.177.XXX.XX.60668 > 192.168.1.12.80: Flags , seq 2230323
12:29:37.098775 IP 192.168.1.12.80 > 77.177.XXX.XX.60668: Flags [S.], seq 673101
12:29:37.100211 IP 77.177.XXX.XX.60668 > 192.168.1.12.80: Flags [.], ack 1, win

Interessant wird es dann aber bei den nächsten Paketen und hier vermute ich den Fehler beim Pi, genauer gesagt beim Webserver.

Nach dem TCP Handshake kommt der HTTP Request:

12:29:37.100852 IP 77.177.XXX.XX.60668 > 192.168.1.12.80: Flags [P.], seq 1:199, ack 1, win 260, length 198: HTTP

Dieser wird vom Pi auf TCP Ebene akzeptiert:

12:29:37.101128 IP 192.168.1.12.80 > 77.177.XXX.XX.60668: Flags [.], ack 199, win 237, length 0

Was hier dann aber fehlt ist eine weitere Rückantwort des Pi auf HTTP Ebene. Etwa ein HTTP/1.1 200 oder anderes.
Beispiel:

You do not have permission to view link please Anmelden or Registrieren

Nach obrigen Paket kommt erst eine halbe Minute später das nächste Paket des anfragenden Clients welches die Sitzung schliesst, da die HTTP Anfrage offensichtlich in ein Timeout gelaufen ist:

12:30:07.101410 IP 77.177.XXX.XX.60668 > 192.168.1.12.80: Flags [F.], seq 199, ack 1, win 260, length 0

 

[HanZ]

Auf die Fritzbox kannst du selbstverständlich auch über die DynDNS-Adresse kommen:
Internet → Freigaben → FRITZ!Box-Dienste

Also über eine aktivierte Option und Aufruf der IP mit dem vorgegebenen Port der FB scheint es nicht zu klappen...

Wie gesagt, DHCP ändert das bei einem Neustart des PI (oder der Fritzbox) auch gern mal und dann zeigt Deine Freigabe ins Leere.

Wenn ich der FRITZ!Box sage, "Diesem Netzwerkgerät immer die gleiche IPv4-Adresse zuweisen." sollte das doch schon verstanden werden oder?

Wenn du eine Freigabe anlegst (der Dialog vor Deinem Screenshot) kannst du die Anwendung auswählen. Und da wird Dir angeboten:

• HTTP-Server
• HTTPS-Server

Im Grunde genommen gibt Dir die Drop-Downlist nur die Ports vor. Weiß aber nicht, ob das noch irgendwas mit den Zertifikaten bei HTTPS macht.

Hm, so wie es aussieht gibt es nur die Ports vor.

@KePa: Könnte es was damit zu tun haben, dass ich auf dem Pi noch Pi-Hole laufen lasse?

 

[KePa]

Wenn ich der FRITZ!Box sage, "Diesem Netzwerkgerät immer die gleiche IPv4-Adresse zuweisen." sollte das doch schon verstanden werden oder?

Richtig. Damit setzt du eine DHCP Reservation.

Hm, so wie es aussieht gibt es nur die Ports vor.

Das sehe ich auch so und denke nicht, dass die Fritzbox hier auf Applikationsebene anhand der Definition blockieren würde. Auf meiner Fritzbox kann ich nicht einmal einen benutzerdefinierten Port, sondern lediglich "HTTP Webserver" wählen. Wenn ich die Regel dann abspeicher, taucht sie in der Übersicht trotzdem nur mit "TCP Port 80" auf. Meiner Meinung nach sind diese Definitionen nur Templates.

Zudem geht der HTTP Request von aussen nach innen ja durch.

KePa: Könnte es was damit zu tun haben, dass ich auf dem Pi noch Pi-Hole laufen lasse?

Das kann ich nicht sagen. Wenn ich das richtig verstehe ist Pi-Hole lediglich ein DNS Server mit einer Blacklist an Namen, die nicht aufgelöst werden. Bedeutet per se nicht, dass dessen Webinterface nicht stören könnte. Hast du vielleicht die Möglichkeit den Pi auf einer separaten Micro SD neu zu installieren, lediglich mit dem Service, den du erreichbar machen möchtest? Somit könntest du andere Applikationen als Faktor ausschliessen.

 

[HanZ]

Ja, ich habe noch eine 8 GB Karte. Werde mal installieren und berichten. Dann lieber Apache oder auch lighttpd nutzen (Nutze lighttpd nur, weil Pi-Hole das nutzt)?

--- [2017-04-30 16:07 CEST] Automatisch zusammengeführter Beitrag ---

Hat nichts daran geändert, ohne Erfolg. Ich habe nun aber über Weaved eine Lösung gefunden, auf den Pi zu kommen. Mit lighttpd gibt es keine Möglichkeit eines htaccess Passwortschuzes wenn ich das richtig sehe?

--- [2017-05-01 11:22 CEST] Automatisch zusammengeführter Beitrag ---

Hallo zusammen,

neue Erkenntniss:

Wenn ich nicht

DOMAIN.TLD:1411

sondern

IP:1411

aufrufe, klappt alles ohne Probleme. Wo gehe ich nun weiter vor? Liegt das dann am DynDNS-Provider (selfhost?)

lg
HanZ

 

[KePa]

Sofern deine DynDNS auf dieselbe IP Adresse zeigt, die du alternativ im Browser eingibst, ist mit der DynDNS alles in Ordnung. Ich nehme an, dass das auch der Fall ist, sonst hätten wir oberes Ergebnis nicht erhalten. Denkbar ist, dass der Webserver prüft was die angefragte Domain (DOMAIN.de) ist (diese wird im HTTP Request übermittelt, siehe unten) und dementsprechend die Antwort verweigert, weil sie vielleicht nicht auf dem Webserver konfiguriert ist. Ein Webserver kann anhand dieser Information u. a. auch entscheiden welche Website er dir zur Verfügung stellt.

You do not have permission to view link please Anmelden or Registrieren

Vielleicht findest du was, wenn du gezielt zum Thema lighttpd + public domain suchst?

 

[HanZ]

Hey KePa,

das Problem hat sich inzwischen gelöst. Ich habe mit dem Support von selfhost.de geschrieben (die hatten sogar am 1. Mai freiwilligen Support). Dort wurde mir gesagt, dass Domain:Port ohne Probleme aufrufbar wäre.
Ich habe dann festgestellt, dass Firefox auf Android aus welchen Gründen auch immer, Probleme hatte von außen drauf zuzugreifen. Nach einer Mobilfunknetzwerkfreigabe und Zugriff über Laptop ging alles. Vermutlich also irgendein DNS-Rebind-Schutz? Wobei ich in der FRITZ!Box meine Domain dafür freigegeben habe.

Pi-hole habe ich jetzt auch mal deaktiviert, denn da gab es weitere seltsame Probleme. Erstens kam bei einem nslookup komische Daten

[src=bash]Server: raspberry pi
Address: 192.168.1.12

Nicht autorisierende Antwort:
Name: DOMAIN.TLD.fritz.box
Address: 127.0.53.53
[/src]

und zweitens kam bei vielen Webseiten ein Hinweis, dass ich doch meine Lohin-Daten (à la .htaccess) eingeben muss. Manchmal sogar mehrere. Sehr seltsames Problem?!