Portfreigabe > 60000 gefahrlos?

BFF schrieb:
Port auf nach aussen kann immer tödlich sein wenn das was hinter dem offenen Port verwundbar ist. Wie verwundbar kann/wird niemand Garantie geben.

Deshalb geht man auf Nummer sicher und tunnelt durch SSH. Ich helf meiner Mama per unverschlüsseltem VNC, wenn sie Probleme am PC hat. Dafür baue ich vorher eine SSH-Verbindung zum Raspberry Pi unter dem Tisch auf, authentifiziere mich per Zertifikat und tunnle dann den Port 5900 zu mir durch. Easy und sicher und eine einzige Portfreigabe reicht.
 
Avenger84 schrieb:
Also werden tatsächlich alle 65535 Ports permanent von Hackergruppen ihren Bots durchforstet
Das Ändern der Standardports gilt wie bereits erwähnt wurde als "Security by obscurity". Sicherlich finden auf Nicht-Standard-Ports weniger Attacken statt, weil viele Portscanner tatsächlich nur Standardports scannen, aber diese Attacken zielen ohnehin vorwiegend auf schlecht gesicherte Standard-Dienste ab, zB ssh mit root/root, root/admin, admin/admin o.ä.. und würden an einem gut gesicherten Dienst mit starkem Passwort oder gar zertifikatsbasierter Authentifizierung so oder so abprallen.

Ich versuch's mal mit einer Analogie, die das Prinzip vielleicht etwas anschaulicher darstellt:

Otto hat ein Haus an der Straße. Ständig kommen Passanten an seine Tür und drücken die Türklinke, um zu gucken ob er vielleicht die Tür offen gelassen hat - die 08/15 Portscanner. Wenn Otto blöd ist, lässt er seine Tür offen (Standard-Logins oder gar gänzlich ohne Passwort) und ständig kommt jemand rein. Otto ist aber gewissenhaft und schließt immer ab, sein ssh-Passwort ist also stark bzw. er authentifiziert sich mittels Zertifikat. Jetzt denkt sich Otto, dass er die Sicherheit erhöht, wenn er die Haustür vorne zumauert und stattdessen an die Seite baut, weil dann ja weniger Passanten an der Tür vorbeikommen. Letzteres stimmt auch, aber diese Passanten, die dann nicht mehr kommen, standen vor dem Umbau ja sowieso vor der verschlossenen Tür und sind schulterzuckend weitergegangen. Es drücken also einfach nur weniger Leute die Türklinke, aber es kommt nach wie vor niemand rein - nicht mehr und nicht weniger.
Nun kommt aber Ernie Einbrecher vorbei und will ins Haus. Vollkommen egal wo die Haustür sitzt, Ernie findet sie, setzt seine Brechstange an und versucht wirklich einzubrechen, so richtig - vollständiger Portscan inkl. service probes und anschließende Bruteforceattacken, etc. Ist die Tür nach wie vor abgeschlossen, kommt auch Ernie nicht rein, egal ob die Haustür vorne, an der Seite oder vermeintlich unzugänglich im 3. Stock ohne Treppe und Leiter sitzt. Und wenn er doch reinkommt, dann schafft er es unabhängig vom Port....


Ungeachtet des Ports ist daher nach wie vor die Sicherheit des Dienstes, der dort läuft, entscheidend. Alles andere - inklusive geändertem Port - sind bestenfalls Nebelkerzen, die Angreifer abhalten, die es sowieso nicht ernst meinen, Skriptkiddies, die einfach mal ausprobieren was bei einem Portscanner so rauskommt. Wenn überhaupt ist Security by obscurity daher nur eine zusätzliche Maßnahme, die aber lediglich eine trügerische Sicherheit bietet.
 
  • Gefällt mir
Reaktionen: Nilson und BFF
Raijin schrieb:
Ich versuch's mal mit einer Analogie, die das Prinzip vielleicht etwas anschaulicher darstellt:
Kann das Jemand mal an pinnen für später?

Raijin schrieb:
unabhängig vom Port....

Tut nix wirklich zu Sache.

vom Port -> von Tür?


Anyway.
Gut getippt. 👍
 
danke für die Antworten.
Das tunneln durch SSH hört sich sehr interessant an, könnte mir das Jemand erklären oder verlinken ?
SSH Passwort im RPi ausschalten und dann nur per Privat Key authentifizieren?
-> Privatkey weiß ich wie das geht, aber SSH Passwort abschalten nicht.
SSH Port wieder in 60.000er Bereich legen.
Dann komme ich ohne Passwort auf SSH, aber wie komme ich von da weiter? Das verstehe ich nicht.
 
  • Gefällt mir
Reaktionen: Avenger84
Es funktioniert echt super, vielen Dank.

in der /etc/ssh/sshd_config muss man
PasswordAuthentication no
einstellen - logisch.

Manche schreiben "UsePAM" muss auf no, während andere schreiben es reicht "ChallengeResponseAuthentication" auf no (default).

...Es reicht, wenn eins von beidem auf "no" gesetzt wird.

ChallengeResponseAuthentication ist dabei (so wie ich das verstanden habe) sozusagen die Oberklasse
und kann verschiedene Authentifizierungsmethoden beinhalten,
die in den sshd eingesetzt werden. (Z.B. auch ein One-Time-Pad oder sowas.)
PAM ist eines dieser Subsysteme.

Habe PAM auf yes gelassen und probiert ohne Privat Key rein zu kommen -> geht nicht.

ChallengeResponseAuthentication steht default auf no.
 
Zurück
Oben