Port forwarding vanaf Fritzbox lijkt niet meer te werken

[DikkieDick]

We hebben 6 dagen internetstoring gehad. Dit is eindelijk vanochtend verholpen. Nou had/heb ik achter de Fritzbox nog een Deco mesh-routersysteem met eigen subnet. Daar draait op een raspberry pi4 pihole, homeassistant en nog wat spul en kan ik extern benaderen via https://hass.domein via een nginx-reverse-proxy op de pihole.
Zelfs vanochtend na herconfiguratie van de Deco-mesh (want die was na 6 dagen alle info kwijt) werkte het nog, maar ergens is er een bitje omgevallen en wil het niet meer werken. Opnieuw de Deco-mesh ingericht maar zonder succes. Ik raak een beetje lost. Met VPN kan ik wel naar mijn fritzbox, maar helaas (ook) niet meer via webssh naar mijn raspberry pi4.



En op mijn Deco-mesh-router gaan poort 80, 443 en 22 naar de Pi4.

Poorten op de Pi4 staan open, getuige tcping <ip-adres pi4> 80 etc.
Helaas geeft tcping 192.168.178.22 80 aan dat ze niet open zijn. en vanaf mijn fritzbox vpn kon ik naar 192.168.178.22 connecten via ssh en kwam dan mooi op mijn pi4 uit in het 10.x-netwerk.
Na uren zoeken ben ik lost. Wat zie ik hier over het hoofd?

[DikkieDick]

Hmm... ipv de pi4 van ssd te starten eens een keer van sd gestart (met oudere installatie) en toen leek ie het weer te doen. FF de 10 verschillen uitzoeken.

En nu (b)leek ik ook niet meer naar buiten te kunnen. De resolv.conf zag er anders uit. Dus deze maar ff aangepast zoals ie in de werkende situatie werkt, maar helaas is dit niet afdoende.

[DikkieDick]

Het probleem lijkt dus nu op de pi4 te zitten, want ik kan, gestart van SD, weer naar bv. https://pihile.domein. Dus gaat netjes door de poorten heen.

[FuaZe]

Telnet en SSH openzetten naar een Pi is niet echt aan te raden.

Maar, begin bij het begin:
Kun je vanuit de Pi 8.8.8.8 pingen?
Kun je vanuit de Pi google.nl pingen?
Kun je vanuit buiten via het externe IP adres verbinden?
Kun je vanuit buiten via je domein verbinden?

[DikkieDick]

Dat was het; dhcpcd.conf maar gepakt van de oude config en toen ging het goed. Enige veschil was dat ik een static-ip-address had gedefinieerd. Zelfde die de Deco mee geeft overigens. Stond er ook zo al in.

[DikkieDick]

FuaZe schreef op maandag 13 februari 2023 @ 18:00:
Telnet en SSH openzetten naar een Pi is niet echt aan te raden.

Maar, begin bij het begin:
Kun je vanuit de Pi 8.8.8.8 pingen?
Kun je vanuit de Pi google.nl pingen?
Kun je vanuit buiten via het externe IP adres verbinden?
Kun je vanuit buiten via je domein verbinden?

Idd. Dat lukte idd ook niet op d'1 of andere manier. Had de reactie hieronder al getypt maar was vergeten op verzenden te drukken. Het 'probleem' zat hem in dhcpcd.conf.

[jurroen]

FuaZe schreef op maandag 13 februari 2023 @ 18:00:
Telnet en SSH openzetten naar een Pi is niet echt aan te raden.

Telnet, okay - maar waarom SSH niet?

[FuaZe]

jurroen schreef op dinsdag 14 februari 2023 @ 10:06:
[...]


Telnet, okay - maar waarom SSH niet?

TL;DR, kleiner attack surface / Waarom wel?

Een Raspberry Pi had eerst altijd standaard wachtwoorden en SSH aan staan.
Vziw doen ze dat in de nieuwere images beter, maar als je een oude image installeert, kan dat problemen geven en over het algemeen wil je zo min mogelijk poorten open zetten.

Ook best een kans dat d'r constant geprobeerd wordt om in te loggen, is eigenlijk zonde van je bandbreedte en processorkracht.

En ja, je kunt het wel beveiligen met een SSH key (geen passphrase), maar ook dan moet je voorzichtig zijn dat je niet toch een van de users beschikbaar maakt via een wachtwoord op SSH.

[jurroen]

FuaZe schreef op dinsdag 14 februari 2023 @ 12:51:
[...]


TL;DR, kleiner attack surface / Waarom wel?

Een Raspberry Pi had eerst altijd standaard wachtwoorden en SSH aan staan.
Vziw doen ze dat in de nieuwere images beter, maar als je een oude image installeert, kan dat problemen geven en over het algemeen wil je zo min mogelijk poorten open zetten.

Ook best een kans dat d'r constant geprobeerd wordt om in te loggen, is eigenlijk zonde van je bandbreedte en processorkracht.

En ja, je kunt het wel beveiligen met een SSH key (geen passphrase), maar ook dan moet je voorzichtig zijn dat je niet toch een van de users beschikbaar maakt via een wachtwoord op SSH.

Als je een remote interface wilt, dan is SSH een van de veiligere manieren. Voorheen had Raspberry Pi OS inderdaad onveilige defaults (pi/raspberry), maar tegenwoordig moet je zelf een user aanmaken.

Portscanning/portknocking is natuurlijk wel een dingetje - maar eerder logs die daarvoor 'vervuild' raken. Dat vergt niet zoveel resources.

En last but not least: je kunt met 'PasswordAuthentication no' het prima uitzetten. Zeker als je dat combineert met een lage MaxAuthTries - en bijvoorbeeld met fail2ban op Raspberry Pi OS.

Zelf draai ik OpenBSD op de Pi, SSH op een andere poort. Anderen die het proberen op poort 22 krijgen gelijk een permaban, door middel van iblock.

[g1n0]

FuaZe schreef op dinsdag 14 februari 2023 @ 12:51:
[...]


TL;DR, kleiner attack surface / Waarom wel?

Een Raspberry Pi had eerst altijd standaard
…
bla bla bla
…
beschikbaar maakt via een wachtwoord op SSH.

Volledig met je eens, maar beargumentering kan ik me niet echt in vinden. (Mensen denken toch altijd alles goed beveiligd te hebben). Tevens is het beter om password authentication op openssh service-niveau uit te zetten ipv per user.

Wat als openssh ineens een vulnerability blijkt te hebben waardoor (bijvoorbeeld, echt een random voorbeeld) door een overflow een rce mogelijk is. Gewoon niet publiceren die poorten.
Als het echt moet, dan sws op een alternatieve poort en/of met een ip-whitelist.

[Voor 11% gewijzigd door g1n0 op 14-02-2023 22:59]

[g1n0]

Quote mezelf ipv edit, dom…

[Voor 114% gewijzigd door g1n0 op 14-02-2023 22:59]

[dion_b]

Idd, alternatieve poort is een erg simpele manier om de portscan-kiddies weg te houden. Iemand die het specifiek op jou gericht heeft zal snel zat vinden als je het op een hogere niet-common poort draait, maar de oeverloze loginpogingen - die gevaarlijk worden in geval van vulnerabilities - ben je dan wel kwijt.

IP whitelisting klinkt aantrekkelijk, maar past eigenlijk beter bij het internet een generatie terug toen (semi) vaste IP's de norm waren en inloggen vanaf een mobile device ongehoord. Ondertussen is het veel lastiger om goed bij te houden, wat grote risico meebrengt dat je geen toegang hebt als je het terecht nodig hebt en kleine risico dat een aanvaller dat wel heeft als je het breed genoeg opzet om welk werkbaar te zijn. Een robuuste authentication, liefst op basis van certificates, is een veel beter idee.

IP whitelisting is eigenlijk alleen zinnig in context van een jump host, waarbij je een enkele bak hebt met verregaande beveiliging die dient als interface voor buitenwereld. Vervolgens deny je rechtstreekse beheersverbindingen vanuit rest van de wereld en mag beheer alleen vanuit die beveiligde bak. Best-practice in corporate omgevingen, maar voor thuisgebruik van normale particulieren volstrekt overkill.