11
Sicherheitsmerkmale meines Root-Servers ausreichend?
Folgende Schutzmaßnahmen nutze ich bei meinen Servern:
Aktuellste Version (10.5) von Debian mit der aktuellsten Version von Plesk (Obsidian), beide werden regelmäßig geupdatet.
Der Root-Zugriff per SSH wurde deaktiviert, der Standardport von SSH auf einen anderen geändert.
Es gibt einen User mit einem willkürlichen Namen, über den später sudo ausgeführt werden kann.
Der Login mittels eines Passwortes ist nicht möglich, stattdessen wird ein public key benötigt.
Dieser Public Key ist mit einer 40-stelligen Passphrase aus Zahlen, Groß- und Kleinbuchstaben sowie Sonderzeichen verschlüsselt.
Der Root-User hat darüber hinaus extra ebenfalls nochmal ein 40-stelliges Passwort.
Fail2Ban wird eingesetzt und sperrt fehlgeschlagene Loginversuche für eine Stunde.
Es wird automatisch eine Benachrichtigung per Mail an mich bei jedem SSH Login versendet.
Serverintern werden Zugriffe auf den geänderten SSH Port von allen außer meiner IP Adresse blockiert.
Eine Firewall des Providers am Switch blockt ebenfalls alle Anfragen von anderen IPs als meiner auf den SSH Port bzw den Plesk Port.
Gibt es noch weitere Sicherheitsmechanismen, die sich lohnen einzubauen? Oder ist das erfahrungsgemäß ausreichend?
(Mir ist klar, dass die Firewall selbst schon reichen würde aber ich will lieber auf Nummer sicher gehen)
Aktuellste Version (10.5) von Debian mit der aktuellsten Version von Plesk (Obsidian), beide werden regelmäßig geupdatet.
Der Root-Zugriff per SSH wurde deaktiviert, der Standardport von SSH auf einen anderen geändert.
Es gibt einen User mit einem willkürlichen Namen, über den später sudo ausgeführt werden kann.
Der Login mittels eines Passwortes ist nicht möglich, stattdessen wird ein public key benötigt.
Dieser Public Key ist mit einer 40-stelligen Passphrase aus Zahlen, Groß- und Kleinbuchstaben sowie Sonderzeichen verschlüsselt.
Der Root-User hat darüber hinaus extra ebenfalls nochmal ein 40-stelliges Passwort.
Fail2Ban wird eingesetzt und sperrt fehlgeschlagene Loginversuche für eine Stunde.
Es wird automatisch eine Benachrichtigung per Mail an mich bei jedem SSH Login versendet.
Serverintern werden Zugriffe auf den geänderten SSH Port von allen außer meiner IP Adresse blockiert.
Eine Firewall des Providers am Switch blockt ebenfalls alle Anfragen von anderen IPs als meiner auf den SSH Port bzw den Plesk Port.
Gibt es noch weitere Sicherheitsmechanismen, die sich lohnen einzubauen? Oder ist das erfahrungsgemäß ausreichend?
(Mir ist klar, dass die Firewall selbst schon reichen würde aber ich will lieber auf Nummer sicher gehen)
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 602733
Url: https://administrator.de/contentid/602733
Printed on: April 25, 2024 at 04:04 o'clock
11 Comments
Latest comment
moin...
Serverintern werden Zugriffe auf den geänderten SSH Port von allen außer meiner IP Adresse blockiert.
Eine Firewall des Providers am Switch blockt ebenfalls alle Anfragen von anderen IPs als meiner auf den SSH Port bzw den Plesk Port.
Gibt es noch weitere Sicherheitsmechanismen, die sich lohnen einzubauen? Oder ist das erfahrungsgemäß ausreichend?
das reicht...
du kannst noch in Plesk ModSecurity einschalten, ist allerdings nix für anfänger.
Frank
Zitat von @rawb1t:
Folgende Schutzmaßnahmen nutze ich bei meinen Servern:
Aktuellste Version (10.5) von Debian mit der aktuellsten Version von Plesk (Obsidian), beide werden regelmäßig geupdatet.
Der Root-Zugriff per SSH wurde deaktiviert, der Standardport von SSH auf einen anderen geändert.
na ja, das macht keinen sinn... ist ja leicht rauszufinden mit einem portscanne...rFolgende Schutzmaßnahmen nutze ich bei meinen Servern:
Aktuellste Version (10.5) von Debian mit der aktuellsten Version von Plesk (Obsidian), beide werden regelmäßig geupdatet.
Der Root-Zugriff per SSH wurde deaktiviert, der Standardport von SSH auf einen anderen geändert.
Es gibt einen User mit einem willkürlichen Namen, über den später sudo ausgeführt werden kann.
Der Login mittels eines Passwortes ist nicht möglich, stattdessen wird ein public key benötigt.
Dieser Public Key ist mit einer 40-stelligen Passphrase aus Zahlen, Groß- und Kleinbuchstaben sowie Sonderzeichen verschlüsselt.
Der Root-User hat darüber hinaus extra ebenfalls nochmal ein 40-stelliges Passwort.
Fail2Ban wird eingesetzt und sperrt fehlgeschlagene Loginversuche für eine Stunde.
Es wird automatisch eine Benachrichtigung per Mail an mich bei jedem SSH Login versendet.
oh je... du spamst dich selber zu.Der Login mittels eines Passwortes ist nicht möglich, stattdessen wird ein public key benötigt.
Dieser Public Key ist mit einer 40-stelligen Passphrase aus Zahlen, Groß- und Kleinbuchstaben sowie Sonderzeichen verschlüsselt.
Der Root-User hat darüber hinaus extra ebenfalls nochmal ein 40-stelliges Passwort.
Fail2Ban wird eingesetzt und sperrt fehlgeschlagene Loginversuche für eine Stunde.
Es wird automatisch eine Benachrichtigung per Mail an mich bei jedem SSH Login versendet.
Serverintern werden Zugriffe auf den geänderten SSH Port von allen außer meiner IP Adresse blockiert.
Eine Firewall des Providers am Switch blockt ebenfalls alle Anfragen von anderen IPs als meiner auf den SSH Port bzw den Plesk Port.
Gibt es noch weitere Sicherheitsmechanismen, die sich lohnen einzubauen? Oder ist das erfahrungsgemäß ausreichend?
(Mir ist klar, dass die Firewall selbst schon reichen würde aber ich will lieber auf Nummer sicher gehen)
das mit auf Nummer sicher gehen wird nix, eine gehackte webseite später, durch ein CMS und die sache ist gelaufen...du kannst noch in Plesk ModSecurity einschalten, ist allerdings nix für anfänger.
Frank
Was die Absicherung vom OS angeht sieht das gut aus.
Die Frage ist aber ; was läuft auf dem Server?
Wenn du da einen Webserver hast, sollte dieser noch betrachtet werden.
Chroot jail so als Stichwort.
Ansonsten : Software aktuell halten
Die Frage ist aber ; was läuft auf dem Server?
Wenn du da einen Webserver hast, sollte dieser noch betrachtet werden.
Chroot jail so als Stichwort.
Ansonsten : Software aktuell halten
Nun - ich würde mal behaupten das du dir mit dem Passwort selbst ins Knie schiesst... mir wäre nicht EINE Person bekannt die sich das mal eben merken kann. Somit sind jetzt 2 Optionen da:
- Es wird irgendwo aufgeschrieben
- Es wird ein Passwort-Manager mit einem deutlich weniger komplexen Passwort genutzt (und dort dann gleich alles gespeichert)
Somit erhöht es die Sicherheit nur minimal - denn wenn ich an den private Key gekommen bin habe ich ja vermutlich schon Zugriff auf den Rechner bekommen wo der drauf ist (und somit eben auch auf den Passwort-Manager).
Es kommt jetzt eher darauf an was der Server tun soll... Wenns nur DEINER ist - ok, da mag das noch lustig sein. Wenn du aber Leute hast die da drauf arbeiten sollen dann wird das in kurzer Zeit dazu führen das sich eben andere Wege gesucht werden (u.a. Passwort direkt als txt-file auf dem Desktop) um den Kram halbwegs komfortabel zu machen. Dazu wird noch erzeugt das man sich - grad wenn man sich dann mal als Root angemeldet hat - eher nicht mehr abmeldet ("könnt ja sein das ich es in 5 min noch brauche") -> und es ist nur eine Frage der Zeit bis man mal im falschen Verzeichnis nen "rm -rf *" raushaut...
Von daher - in meinen Augen eher eine völlig sinnlose Maßnahme. SSH-Key-Login, ja, keine Frage. Root login deaktivieren - auch... Bei Passwörtern lieber etwas nutzen was man sich auch merken kann und was Anwender verwenden können...
Es ist aber eben auch ne Frage was der Server eben tun soll...
Edit: Ne Mail für jeden fehlgeschlagenen Versuch? Viel Spass damit... ich habe (mit Fail2Ban) in nen paar Stunden so 250 Login-Versuche, die sind nich mal ernst zu nehmen da idR. nen Root-Login versucht wird was gar nicht gehen kann... Ohne F2B hatte ich mehrere 1.000 pro Tag...
- Es wird irgendwo aufgeschrieben
- Es wird ein Passwort-Manager mit einem deutlich weniger komplexen Passwort genutzt (und dort dann gleich alles gespeichert)
Somit erhöht es die Sicherheit nur minimal - denn wenn ich an den private Key gekommen bin habe ich ja vermutlich schon Zugriff auf den Rechner bekommen wo der drauf ist (und somit eben auch auf den Passwort-Manager).
Es kommt jetzt eher darauf an was der Server tun soll... Wenns nur DEINER ist - ok, da mag das noch lustig sein. Wenn du aber Leute hast die da drauf arbeiten sollen dann wird das in kurzer Zeit dazu führen das sich eben andere Wege gesucht werden (u.a. Passwort direkt als txt-file auf dem Desktop) um den Kram halbwegs komfortabel zu machen. Dazu wird noch erzeugt das man sich - grad wenn man sich dann mal als Root angemeldet hat - eher nicht mehr abmeldet ("könnt ja sein das ich es in 5 min noch brauche") -> und es ist nur eine Frage der Zeit bis man mal im falschen Verzeichnis nen "rm -rf *" raushaut...
Von daher - in meinen Augen eher eine völlig sinnlose Maßnahme. SSH-Key-Login, ja, keine Frage. Root login deaktivieren - auch... Bei Passwörtern lieber etwas nutzen was man sich auch merken kann und was Anwender verwenden können...
Es ist aber eben auch ne Frage was der Server eben tun soll...
Edit: Ne Mail für jeden fehlgeschlagenen Versuch? Viel Spass damit... ich habe (mit Fail2Ban) in nen paar Stunden so 250 Login-Versuche, die sind nich mal ernst zu nehmen da idR. nen Root-Login versucht wird was gar nicht gehen kann... Ohne F2B hatte ich mehrere 1.000 pro Tag...
Denk mal über 2FA für den SSH Login nach. Ist relativ einfach umzusetzen.
1
Nur SSH und Plesk sind auf dem Server? Eher unwahrscheinlich.
Wer ist der Hoster?
Laufwerke verschlüsselt?
Wer ist der Hoster?
Laufwerke verschlüsselt?
1
Moin,
Du hast vergessen zu erwähnen, gegen was Du Dich absichern willst.
gegen jemanden, der sich über ssh auf Deiner Kiste anmelden will sind die o.g. Maßnahmen vermutlich ausreichend. (ssh Port ändern ist heutzutage so, als ob man sich die Augen zuhält, um sich vordem gefräßigen Plapperkäfer von Traal einem Kind zu verstecken. ).
Aber gegen Angreifer die Deine Webserver, Deine DB, Deine Wordpress, Deinen Mailserver, etc. mißbrauchen wollen, sind die obigen Maßnahmen überhaupt nicht geeignet.
Dazu wäre noch die frage, welche Mailinglisten du verfolgst, um im Falle eines Exploits sofort reagieren zu können und nicht erst, wenn die Maintainer Deiner Distribution den Bug gefixt haben? Oft sind die "Hacker" nämlich schneller als die Maintainer.
lks
Du hast vergessen zu erwähnen, gegen was Du Dich absichern willst.
gegen jemanden, der sich über ssh auf Deiner Kiste anmelden will sind die o.g. Maßnahmen vermutlich ausreichend. (ssh Port ändern ist heutzutage so, als ob man sich die Augen zuhält, um sich vor
Aber gegen Angreifer die Deine Webserver, Deine DB, Deine Wordpress, Deinen Mailserver, etc. mißbrauchen wollen, sind die obigen Maßnahmen überhaupt nicht geeignet.
Dazu wäre noch die frage, welche Mailinglisten du verfolgst, um im Falle eines Exploits sofort reagieren zu können und nicht erst, wenn die Maintainer Deiner Distribution den Bug gefixt haben? Oft sind die "Hacker" nämlich schneller als die Maintainer.
lks
Wie könnte ein SSH Port gefunden werden, wenn die interne Firewall alle Verbindungen zu diesem Port bereits abweist? Unterscheidet sich damit ja nicht von einem x-beliebiegen anderen Port, auf den nichts lauscht.
CMS verwende ich, genau aus diesem Grund, ohnehin nicht.
ModSecurity werd ich mir mal anschauen, danke !
ModSecurity werd ich mir mal anschauen, danke !
Ok - dann sage doch mal wo der zusatznutzen ist vom standard-port wegzugehen wenn eh nix rankommt...
Hallo,
ich arbeite relativ viel mit fail2ban
Gruß,
Jörg
ich arbeite relativ viel mit fail2ban
Gruß,
Jörg
Jap - ich auch... aber das bringt ja nur dann was wenn überhaupt sich jemand anmelden kann... wenn natürlich (was ja generell nich schlecht ist!) vorher ne Firewall schon dafür sorgt das nur 1-2 IPs überhaupt darauf zugreifen können dann ist das recht überflüssig... Ganz ehrlich: Nen Angriff der darauf abzielt erst meinen Rechner zu übernehmen, dann darüber den Root-Server zu holen usw.. -> der wird auch gut genug sein das er das 40-Zeichen-Passwort einfach per Keylogger mitnimmt...
Is halt irgendwann die Frage wieviel Sinn sowas macht... Klar - als Studienobjekt sicher lustig, aber für "real" ja dann irgendwann übertrieben... Ich kann mich auch im Panzer hinsetzen und nen Motorradhelm aufsetzen, nur ob sich das dann lohnt is die Frage...
Is halt irgendwann die Frage wieviel Sinn sowas macht... Klar - als Studienobjekt sicher lustig, aber für "real" ja dann irgendwann übertrieben... Ich kann mich auch im Panzer hinsetzen und nen Motorradhelm aufsetzen, nur ob sich das dann lohnt is die Frage...
