Raspberry 2 als NAS Server

[theSplit]

Um sich auf eine Sache zu konzentrieren:

Ab 11a geht es um den Key, der per PuttyGEN erstellt wurde, oder?

Ja, genau, der hier:

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

Das was in Public Key bei dir steht mußt du 1 zu 1 in [kw]authorized_keys[/kw] eintragen.

 

[drfuture]

Was heißt dann für dich *was laufen*?
Und bitte nach das von split nicht einfach und 1:1 nach sondern lese die Anleitungen der Befehle damit du verstehst was du da tust. Durch Kopieren lernt man meist nicht.

 

[theSplit]

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

Ich habs extra alles in einem Beitrag beigebogen, weil ich dachte wenn bei jedem Punkt noch 5 weitere Fragen aufkommen, kommt man schlichtweg nicht unbedingt weiter. Daher "all-in-one"

 

[drfuture]

Ja war auch nicht "gegen" dich. Ist ja in Ordnung, wichtig ist was man draus macht

 

[Michael2019]

Was heißt dann für dich *was laufen*?
Und bitte nach das von split nicht einfach und 1:1 nach sondern lese die Anleitungen der Befehle damit du verstehst was du da tust. Durch Kopieren lernt man meist nicht.

"Laufen" heißt, dass es unberechtigte Zugriffe gibt, die zwar durch Fail2Ban gebannt werden, aber die Zugriffe sind da, was ich nicht begreife. SSH Port ist deaktiviert (von außen).


Die meisten Befehle kenne ich, den Rest schaue ich.

 

[drfuture]

Von außen? Poste doch Mal die letzten Zeilen vom Log.

 

[Michael2019]

Ja, von außen. Wenn ich jetzt

$ nano /var/log/fail2ban.log

eingebe, bekomme ich seltsamerweise nur

[460]: INFO rollover performed on /var/log/fail2ban.log

als Ausagasbe. Aber bisher eben, dass es zwei Zugriffe gab mit der öffentl. IP (Brasilien, USA, China) und dann, dass sie gebannt wurden.

 

[Metal_Warrior]

@Michael2019: Weißt du eigentlich, was Fail2ban macht?

Ich hab langsam wieder mal so das Gefühl, dass wir jemandem ohne irgendeine Kenntnis und ohne Willen, sich die anzueignen, zeigen, wie er ein f*cking Serversystem ins Internet hängt, und dabei die Sicherheit seines Routers killt...

 

[Michael2019]

Wieso sollte ich das nicht wissen? In Fail2Ban werden nicht autorisierte Zugriffe geloggt und - je nach Einstellung - bei zwei (in meinen Fall) falschen Anmeldeversuchen für den Zeitraum x gebannt. Begreife aber nicht ganz, was das im Hinblick auf die Zugriffe für eine Rolle spielt. Brute-Force ist damit auch unwahrscheinlich.

Edit:

[/die Sicherheit seines Routers killt...QUOTE]

GANZ sicher nicht. Oder was lässt dich das vermuten?

 

[Metal_Warrior]

@Michael2019: Portforwarding umgeht für den entsprechenden Port die Firewall des Routers, killt damit die Sicherheit. Stellt man es nicht richtig ein, oder ist der Dienst dahinter schlecht administriert, wie in deinem Fall, wird das Netzwerk dadurch unsicher.

Und was dein Problem angeht: Wer schon grundsätzlich nicht weiß, was er da macht, und das dann auch noch mit wesentlich mehr Software macht, als notwendig ist, der muss sich nicht wundern, wenn nix funktioniert. Zumal der RPi 2 dafür bekannt ist, notorisch SD-Karten zu grillen.

Nochmal im Schnelldurchlauf von mir:

1. Zieh dir ein aktuelles Raspbian-Image
2. Schalte SSH frei
3. Lege einen neuen Nutzer an
4. Nagel SSH so zu, dass sich nur noch der neu angelegte User mit 4096bit-RSA, ECDSA oder ähnlich komplexen Keys anmelden kann (AllowUser, PasswordAuthentication no, UsePAM no, LoginGraceTime 2s)
5. Mach dann dein Portforwarding
6. Richte dann einen DynDNS-Namen und eine automatische Aktualisierung via ddclient ein
7. Ignoriere die 100 Anmeldeversuche pro Woche am SSH, die du automatisch bekommen wirst, sie sind sicherheitstechnisch irrelevant (Du wirst nicht gebruteforced bei KeyAuth only, und DDoS macht auch keine Sau)
8. FERTIG

 

[Michael2019]

Portforwarding umgeht für den entsprechenden Port die Firewall des Routers, killt damit die Sicherheit

Das ist logisch, sonst würde man ja kein Gerät erreichen. Aber ich habe nur den Port 443 am Pi offen, sonst nichts. Also KEIN SSH (22).

[Zumal der RPi 2 dafür bekannt ist, notorisch SD-Karten zu grillen.

Der lief schon Monate - ohne Probleme. Aber egal, das ist was andere.

Aber wieso soll ich nun wieder alles nu machen? Wenn ich den anderen Benutzer anlege, wie von thesplit erläutert, reicht das nicht?

Nagel SSH so zu, dass sich nur noch der neu angelegte User mit 4096bit-RSA, ECDSA oder ähnlich komplexen Keys anmelden kann (AllowUser, PasswordAuthentication no, UsePAM no, LoginGraceTime 2s)

Da habe ich ja vor und werde ich machen.

[/automatische Aktualisierung via ddclient einQUOTE]

DDNS wird bereits über ein anderes System aktualisiert (gleicher DDNS Name).

Ignoriere die 100 Anmeldeversuche pro Woche am SSH, die du automatisch bekommen wirst

Warum eigentlich? Also wieso gibt es bei SSH soviele Verssuche, aber z.B. bei Nextcloud keinen?

 

[Metal_Warrior]

Das ist logisch, sonst würde man ja kein Gerät erreichen. Aber ich habe nur den Port 443 am Pi offen, sonst nichts. Also KEIN SSH (22).

Dann kannst du ihn von extern nicht per SSH erreichen, und wenn du hausintern deine Verbindung über DynDNS auflöst, kommt es auf den Router an, wie clever oder doof der ist, ob er die externe IP als intern erkennt und ohne den Umweg nach draußen deinen Server kontaktiert. Das bedeutet: Ob du eine Verbindung zum SSH-Server kriegst, ist eher Glücksspiel. Und wenn SSH eh nicht von außen erreichbar ist, warum schaltest du dann Fail2ban vor? Das macht gar keinen Sinn.

Aber wieso soll ich nun wieder alles nu machen? Wenn ich den anderen Benutzer anlege, wie von thesplit erläutert, reicht das nicht?

Weil du komische Fehler hast, wir ständig dein Setup raten müssen und mittlerweile keiner mehr bei deinen Problembeschreibungen durchsteigt. Ergo: Nochmal von vorn, und zwar gescheit mit allen Configs und allen Einstellungen hier gepostet. Dann kann man auch helfen.

Warum eigentlich? Also wieso gibt es bei SSH soviele Verssuche, aber z.B. bei Nextcloud keinen?

Weil SSH ein Steuerungsdienst ist, und das als Angriffsziel sehr lohnend ist, wohingegen NextCloud (also der Apache) keine Rechte auf einem System hat und damit relativ uninteressant ist. Was nicht heißt, dass SSH weniger sicher oder NextCloud sicherer ist, eher das Gegenteil. Bei SSH verkacken nur öfter mal die User, und die Admins, indem sie schwache Passwörter zulassen. Daher hab ich dir auch geschrieben, was du einstellen musst, um BruteForcing von vornherein zu unterbinden.

 

[Michael2019]

Dann kannst du ihn von extern nicht per SSH erreichen

Das brauche ich aktuell auch nicht, daher kein Portforwarding.

Und wenn SSH eh nicht von außen erreichbar ist, warum schaltest du dann Fail2ban vor? Das macht gar keinen Sinn.

Am Anfang wollte ich es so, dass SSH von außen erreichbar ist. Dann habe ich aber gedacht, wieso ein Sicherheitsrisiko für einen Dienst, den ich - aktuell - von außen nicht brauche? Fail2Ban konfiguriert zu haben, ist aber kein Fehler. Denn wenn ich von außen auf SSH muss und die Ports weiterleite, dann ist bereits alles konifguriert - also so gesehen macht es Sinn

Weil du komische Fehler hast, wir ständig dein Setup raten müssen und mittlerweile keiner mehr bei deinen Problembeschreibungen durchsteigt. Ergo: Nochmal von vorn, und zwar gescheit mit allen Configs und allen Einstellungen hier gepostet. Dann kann man auch helfen.

Also ich kann es schon nochmal machen, kein Problem. Habe mir eine 128 GB Karte besorgt, die ist drin, hatte die andere kopiert und dann auf die 128er geschrieben. Aber kann auch direkt auf die neue schreiben. Die Nextcloud Install dauert halt echt recht lange.

Weil SSH ein Steuerungsdienst ist, und das als Angriffsziel sehr lohnend ist, wohingegen NextCloud (also der Apache) keine Rechte auf einem System hat und damit relativ uninteressant ist.

Ja, klar, aber einen Server mit Daten anzugreifen muss ja auch nicht uninteressant sein. Aber klar, was du meinst.

Daher hab ich dir auch geschrieben, was du einstellen musst, um BruteForcing von vornherein zu unterbinden.

Ja, werde ich auch machen.

mit 4096bit-RSA

Kann ich bei PuttyGen das einfach durch 2048 austauschen? Und 8192bit sollte nicht nötig sein, oder?

 

[musv]

Ich hätte noch einen zusätzlichen Tipp:

Ich hab das Portforwarding so konfiguriert, dass von extern Port 222 auf intern 22 weitergeleitet wird. Das erhöht jetzt technisch nicht die Sicherheit, sperrt aber vermutlich 95% der Scan-Scripte aus, da die nur nach Port 22 das große weite Netz abgrasen. Zumindest sehe ich nur äußerst selten irgendwelche Brute-Force-Attacken. Fail2Ban nutze ich hingegen gar nicht.

[Update]
Ok, ich muss mir widersprechen. Anscheinend werd ich doch ca. 2x pro Woche attackiert:

Spoiler

Jan 11 09:35:01 nas sshd[201]: Could not get shadow information for NOUSER
Jan 11 09:35:01 nas sshd[201]: Failed password for invalid user wordpress from 185.143.223.135 port 51761 ssh2
Jan 11 09:35:01 nas sshd[201]: Connection closed by invalid user wordpress 185.143.223.135 port 51761 [preauth]
Jan 11 09:35:02 nas sshd[201]: Failed password for git from 185.143.223.135 port 51876 ssh2
Jan 11 09:35:02 nas sshd[201]: Connection closed by authenticating user git 185.143.223.135 port 51876 [preauth]
Jan 11 09:35:02 nas sshd[201]: Invalid user www-data from 185.143.223.135 port 51946
Jan 11 09:35:06 nas sshd[201]: Could not get shadow information for NOUSER
Jan 11 09:35:06 nas sshd[201]: Failed password for invalid user www-data from 185.143.223.135 port 51946 ssh2
Jan 11 09:35:06 nas sshd[201]: Connection closed by invalid user www-data 185.143.223.135 port 51946 [preauth]
Jan 11 09:35:07 nas sshd[201]: Failed password for root from 185.143.223.135 port 53565 ssh2
Jan 11 09:35:07 nas sshd[201]: Connection closed by authenticating user root 185.143.223.135 port 53565 [preauth]
Jan 11 09:35:07 nas sshd[201]: Invalid user vnc from 185.143.223.135 port 53700
Jan 11 09:35:07 nas sshd[201]: Could not get shadow information for NOUSER
Jan 11 09:35:07 nas sshd[201]: Failed password for invalid user vnc from 185.143.223.135 port 53700 ssh2
Jan 11 09:35:07 nas sshd[201]: Connection closed by invalid user vnc 185.143.223.135 port 53700 [preauth]
Jan 11 09:35:12 nas sshd[201]: Invalid user cisco from 185.143.223.135 port 54960
Jan 11 09:35:12 nas sshd[201]: Could not get shadow information for NOUSER
Jan 11 09:35:12 nas sshd[201]: Failed password for invalid user cisco from 185.143.223.135 port 54960 ssh2
Jan 11 09:35:12 nas sshd[201]: Connection closed by invalid user cisco 185.143.223.135 port 54960 [preauth]
Jan 11 09:35:12 nas sshd[201]: Invalid user PlcmSpIp from 185.143.223.135 port 55073
Jan 11 09:35:12 nas sshd[201]: Could not get shadow information for NOUSER
Jan 11 09:35:12 nas sshd[201]: Failed password for invalid user PlcmSpIp from 185.143.223.135 port 55073 ssh2
Jan 11 09:35:12 nas sshd[201]: Connection closed by invalid user PlcmSpIp 185.143.223.135 port 55073 [preauth]
Jan 11 09:35:13 nas sshd[201]: Failed password for root from 185.143.223.135 port 55170 ssh2
Jan 11 09:35:13 nas sshd[201]: Connection closed by authenticating user root 185.143.223.135 port 55170 [preauth]

 

[Metal_Warrior]

Fail2Ban konfiguriert zu haben, ist aber kein Fehler.

Na, wenn du meinst... Ich habs nicht, leite Port 22 direkt durch zum Server und hab auch keine Probleme, weil ich Passwörter nicht zulasse. Damit brechen die meisten Scripte sofort ab.

Ja, klar, aber einen Server mit Daten anzugreifen muss ja auch nicht uninteressant sein. Aber klar, was du meinst.

Die Daten, die sich hinter einer Nextcloud verbergen, sind für 99,999% der Angreifer nutzlos. Und du bist ein zu kleiner Fisch, um einen gezielten Angriff rechzufertigen.

Kann ich bei PuttyGen das einfach durch 2048 austauschen? Und 8192bit sollte nicht nötig sein, oder?

Ich hab nicht 4096bit geschrieben, weil ich ne Rechenschwäche hab. 2048bit ist next-to-broken, also nicht mehr für neue Keys zu verwenden. 8192bit wird AFAIK nicht von allen Systemen unterstützt, wobei ich mir bei SSH da grad nicht sicher bin, insofern kannst du auch gern 8192 nehmen, aber nicht unter 4096, was RSA angeht.

Zu musvs Tipp mit dem anderen Port: Das ist eine Unsitte, die ich hier als Tipp ehrlich gesagt nicht sehen will. Es gibt einen guten Grund, warum die Ports in den unteren Bereichen IANA-registriert sind, und klar kann man Angreifer dadurch etwas verwirren, aber man wiegt sich hier in falscher Sicherheit und macht das Debuggen für andere Leute schwieriger. Außerdem hab ich diesbezüglich ein Trauma mit meiner Kundschaft, die das auch für ne clevere Idee hält und oft genug dann in die Scheiße greift, spätestens beim Firewalling, also NEIN, keinen anderen Port hijacken!

 

[Michael2019]

Na, wenn du meinst... Ich habs nicht, leite Port 22 direkt durch zum Server und hab auch keine Probleme, weil ich Passwörter nicht zulasse. Damit brechen die meisten Scripte sofort ab.

Naja, da ich ja gemäß Anleitung auch Fail2Ban gemacht habe, denke ich, lasse ich es.

sind für 99,999% der Angreifer nutzlos.

Vermutlich, ja, aber nicht sicher ^^

Ich hab nicht 4096bit geschrieben, weil ich ne Rechenschwäche hab.

Denke ich mir Ich werde das so machen.

Zu musvs Tipp mit dem anderen Port: Das ist eine Unsitte, die ich hier als Tipp ehrlich gesagt nicht sehen will.

Ich wusste, dass du das bemäglen wirst Von musv war es aber ja gut gemeint. Ich lasse den Port 22, da ich, wie gesgat, ohnehin den Port nicht ständig offen haben will.


Edit:

Soll ich auch eine Passphrase erstellen?

 

[drfuture]

Ja das Zertifikat muss durch ein Passwort geschützt werden

 

[Michael2019]

Danke, dann werde ich eine Passphrase setzen.