• Hallo liebe Userinnen und User,

    nach bereits längeren Planungen und Vorbereitungen sind wir nun von vBulletin auf Xenforo umgestiegen. Die Umstellung musste leider aufgrund der Serverprobleme der letzten Tage notgedrungen vorverlegt werden. Das neue Forum ist soweit voll funktionsfähig, allerdings sind noch nicht alle der gewohnten Funktionen vorhanden. Nach Möglichkeit werden wir sie in den nächsten Wochen nachrüsten. Dafür sollte es nun einige der Probleme lösen, die wir in den letzten Tagen, Wochen und Monaten hatten. Auch der Server ist nun potenter als bei unserem alten Hoster, wodurch wir nun langfristig den Tank mit Bytes vollgetankt haben.

    Anfangs mag die neue Boardsoftware etwas ungewohnt sein, aber man findet sich recht schnell ein. Wir wissen, dass ihr alle Gewohnheitstiere seid, aber gebt dem neuen Board eine Chance.
    Sollte etwas der neuen oder auch gewohnten Funktionen unklar sein, könnt ihr den "Wo issn da der Button zu"-Thread im Feedback nutzen. Bugs meldet ihr bitte im Bugtracker, es wird sicher welche geben die uns noch nicht aufgefallen sind. Ich werde das dann versuchen, halbwegs im Startbeitrag übersichtlich zu halten, was an Arbeit noch aussteht.

    Neu ist, dass die Boardsoftware deutlich besser für Mobiltelefone und diverse Endgeräte geeignet ist und nun auch im mobilen Style alle Funktionen verfügbar sind. Am Desktop findet ihr oben rechts sowohl den Umschalter zwischen hellem und dunklem Style. Am Handy ist der Hell-/Dunkelschalter am Ende der Seite. Damit sollte zukünftig jeder sein Board so konfigurieren können, wie es ihm am liebsten ist.


    Die restlichen Funktionen sollten eigentlich soweit wie gewohnt funktionieren. Einfach mal ein wenig damit spielen oder bei Unklarheiten im Thread nachfragen. Viel Spaß im ngb 2.0.

Raspberry 2 als NAS Server

drfuture

Zeitreisender
Teammitglied

Registriert
14 Juli 2013
Beiträge
8.718
Ort
in der Zukunft
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

1998
Veteran Barkeeper

Registriert
3 Aug. 2014
Beiträge
28.557
@drfuture: 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" ;)
 

Michael2019

NGBler

Registriert
11 Mai 2019
Beiträge
178
  • Thread Starter Thread Starter
  • #165
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.
 
Zuletzt bearbeitet:

Michael2019

NGBler

Registriert
11 Mai 2019
Beiträge
178
  • Thread Starter Thread Starter
  • #167
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

Defender of Freedom
Teammitglied

Registriert
10 Aug. 2013
Beiträge
6.829
Ort
/dev/mapper/home
@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

NGBler

Registriert
11 Mai 2019
Beiträge
178
  • Thread Starter Thread Starter
  • #169
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?
 
Zuletzt bearbeitet:

Metal_Warrior

Defender of Freedom
Teammitglied

Registriert
10 Aug. 2013
Beiträge
6.829
Ort
/dev/mapper/home
@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

NGBler

Registriert
11 Mai 2019
Beiträge
178
  • Thread Starter Thread Starter
  • #171
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

Defender of Freedom
Teammitglied

Registriert
10 Aug. 2013
Beiträge
6.829
Ort
/dev/mapper/home
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

NGBler

Registriert
11 Mai 2019
Beiträge
178
  • Thread Starter Thread Starter
  • #173
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.


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

musv

Bekannter NGBler

Registriert
15 Juli 2013
Beiträge
3.453
Ort
/dev/null
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:
Code:
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

Defender of Freedom
Teammitglied

Registriert
10 Aug. 2013
Beiträge
6.829
Ort
/dev/mapper/home
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

NGBler

Registriert
11 Mai 2019
Beiträge
178
  • Thread Starter Thread Starter
  • #176
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 :D^^

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?
 
Zuletzt bearbeitet:
Oben