sluiten

Uitnodiging online gebruikerstest

We zijn op zoek naar deelnemers voor een leuke online gebruikerstest. Voor de test zoeken we gebruikers die veel gebruik maken van Pricewatch en het forum. Het interview duurt ongeveer 45 minuten en voor je deelname krijg je €40,- vergoeding.

Heb je op vrijdag 14 april tijd om mee te doen (tussen 9:00 en 17:00)? Meld je dan aan en wellicht zien we je snel!

Aanmelden

Toon posts:

Port forwarding vanaf Fritzbox lijkt niet meer te werken

Pagina: 1
Acties:

  • DikkieDick
  • Registratie: Maart 2004
  • Laatst online: 15-03 13:45
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
  • Registratie: Maart 2004
  • Laatst online: 15-03 13:45
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
  • Registratie: Maart 2004
  • Laatst online: 15-03 13:45
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
  • Registratie: April 2014
  • Laatst online: 07:01
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
  • Registratie: Maart 2004
  • Laatst online: 15-03 13:45
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
  • Registratie: Maart 2004
  • Laatst online: 15-03 13:45
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
  • Registratie: Mei 2012
  • Laatst online: 08:07

jurroen

Security en privacy geek

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
  • Registratie: April 2014
  • Laatst online: 07:01
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
  • Registratie: Mei 2012
  • Laatst online: 08:07

jurroen

Security en privacy geek

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
  • Registratie: Maart 2016
  • Niet online
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
  • Registratie: Maart 2016
  • Niet online
Quote mezelf ipv edit, dom…

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


  • dion_b
  • Registratie: September 2000
  • Laatst online: 10:06

dion_b

Moderator Harde Waren

say Baah

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.

Soittakaa Paranoid!

Pagina: 1


Tweakers maakt gebruik van cookies

Tweakers plaatst functionele en analytische cookies voor het functioneren van de website en het verbeteren van de website-ervaring. Deze cookies zijn noodzakelijk. Om op Tweakers relevantere advertenties te tonen en om ingesloten content van derden te tonen (bijvoorbeeld video's), vragen we je toestemming. Via ingesloten content kunnen derde partijen diensten leveren en verbeteren, bezoekersstatistieken bijhouden, gepersonaliseerde content tonen, gerichte advertenties tonen en gebruikersprofielen opbouwen. Hiervoor worden apparaatgegevens, IP-adres, geolocatie en surfgedrag vastgelegd.

Meer informatie vind je in ons cookiebeleid.

Sluiten

Toestemming beheren

Hieronder kun je per doeleinde of partij toestemming geven of intrekken. Meer informatie vind je in ons cookiebeleid.

Functioneel en analytisch

Deze cookies zijn noodzakelijk voor het functioneren van de website en het verbeteren van de website-ervaring. Klik op het informatie-icoon voor meer informatie. Meer details

janee

    Relevantere advertenties

    Dit beperkt het aantal keer dat dezelfde advertentie getoond wordt (frequency capping) en maakt het mogelijk om binnen Tweakers contextuele advertenties te tonen op basis van pagina's die je hebt bezocht. Meer details

    Tweakers genereert een willekeurige unieke code als identifier. Deze data wordt niet gedeeld met adverteerders of andere derde partijen en je kunt niet buiten Tweakers gevolgd worden. Indien je bent ingelogd, wordt deze identifier gekoppeld aan je account. Indien je niet bent ingelogd, wordt deze identifier gekoppeld aan je sessie die maximaal 4 maanden actief blijft. Je kunt deze toestemming te allen tijde intrekken.

    Ingesloten content van derden

    Deze cookies kunnen door derde partijen geplaatst worden via ingesloten content. Klik op het informatie-icoon voor meer informatie over de verwerkingsdoeleinden. Meer details

    janee