Mein allererster Server im World Wide Web - wie versaue ich es nicht?

DFFVB

Rear Admiral
Registriert
Dez. 2015
Beiträge
5.659
Hallo zusammen, zum Black Friday hab ich mir einen kleinen Webserver bei Netcup gegönnt (8/512).

Nun liest man ja häufig, dass Server gehackt werden, Normalsterbliche können die gar nicht absichern. Wer nicht einen Abschluss in Quantentheorie hat kann eh heimgehen. Gleichzeitig gibt's ja auch genug Server und auch Leute die die einsetzen und das klappt auch irgendwie. Ein Bekannter betreibt seinen seit Jahren gar ohne Firewall...

Daher hier mal meine Vorgehensweise:

  • Admin Passwort ändern
  • SSH härten
    • Public Key mit PIV auf einem Yubikey
    • Root und password no
    • Standard Port ändern
  • Ufw allow openssh
  • Ufw enable
  • Fail2ban
  • Logwatch

So dann ist die Kiste erstmal relativ dicht. Aber läuft noch nichts drauf. Geplant ist erstmal Plex mit einem anderen als dem Standard Port und 2FA.

Stellt sich die Frage nach einem Reverse Proxy. Lohnt das schon für einen Dienst?

Darüber hinaus würde ich gerne wissen wie dicht die Kiste ist. Wie finde ich das raus?

Ich dachte dabei an Honeypots. Theoretisch müssten die ja still bleiben, weil nichts reinkommt?
 
  • Gefällt mir
Reaktionen: 3!93D
Wenn du Login mit Zertifikat machst, brauchst du ja eigentlich keinen erlaubten Login mit Passwort.
Port ändern kann man machen, hilft aber eher die Logs sauber zu halten als echte Sicherheit zu bringen.
Port knocking wäre auch noch eine Möglichkeit die du dir anschauen könntest.

Bei Reverse Proxy ist die Frage, ob du der Software mehr vertraust als der eigentlichen Software die dahinter laufen soll. Du schließt halt ein mögliches Loch indem du ein potentielles anderes öffnest.
Kann man aber machen.

Was immer wichtig ist, ist die Software zu patchen. All die Vorsichtsmaßnahmen bringen nichts, wenn z.B. dein Plex oder Reverse Proxy eine Sicherheitslücke hat.
Möglichst alle Software mit eingeschränkten Usern laufen zu lassen wirst du ja sicher schon bedacht haben.
 
  • Gefällt mir
Reaktionen: DFFVB
DFFVB schrieb:
Ein Bekannter betreibt seinen seit Jahren gar ohne Firewall...
Geht ja auch ohne "Firewall". Eine Firewall (i.d.R. ist hier ja ein Paketfilter gemeint) braucht man ja nur, wenn man zwar einen Service gestartet hat der auf einem externen Interface lauscht aber dieser soll gar nicht von extern erreichbar sein.
Wenn man das nicht hat, weil man darauf achtet seine Dienste so zu konfigurieren, das die das nicht sinnloserweise machen, braucht man auch keine Ports abdichten.

Da sollte generell das Augenmerk hingehen. Server werden i.d.R. ja nicht "als solches" angegriffen, sondern ein Dienst der darauf läuft. Der muss sicher konfiguriert werden (und auch dafür sorgt, das Security-Patches zeitnah eingespielt werden) und idealerweise sogar noch "jailed" werden.

Bei SSH würde ich das Login auf jeden Fall mit 'nem Public-Key machen statt mit einem Passwort. Dann braucht man auch keine Sorge vor "Angreifer probiert alle Passwörter durch"-Szenarien zu haben.

Das die Passwörter die man sonst noch so hat, gute Passwörter (also insbesondere lang) und vorhandene geändert gehören, versteht sich ja von selbst.

Generell macht sich gut, wenn man das mal an einem heimischen Rechner (kann ja auch in einer VM sein durchspielt und ausprobiert, bevor man anfängt sich an ein offen im Internet stehenden Server auszuprobieren.
 
  • Gefällt mir
Reaktionen: DFFVB, h2f, Masamune2 und eine weitere Person
Wenn du keine Public Dienste anbieten willst, dann packe alles hinter ein VPN wie Wireguard.

DFFVB schrieb:
SSH härten - Ufw allow openssh

Kommt ein Exploit vorbei und übernimmst direkt den Dienst. Oder ist der öffentlich?

Ich würde ein VPN zum Server-Zugriff auch auf bekannte Netzbereiche/AS einschränken solange du nicht public Dienste im Internet anbieten willst.
 
  • Gefällt mir
Reaktionen: DHundt und madmax2010
Ich würde auch keine Administratorenkonten haben wollen, die wie Administratorenkonten heißen.
 
  • Gefällt mir
Reaktionen: DFFVB und aragorn92
DFFVB schrieb:
  • Admin Passwort ändern

Root Passwort, und ja, kann man machen

DFFVB schrieb:
  • SSH härten
    • Public Key mit PIV auf einem Yubikey
unnötiger Aufwand

DFFVB schrieb:
    • Root und password no

Richtig, wobei das mit nem richtigen Passwort auch nicht wirklich ein Problem ist.

DFFVB schrieb:
    • Standard Port ändern
Unnütz, hält nur Scriptkiddies ab und die Logs sauber. Zieht auch Anpassungen an UFW und Fail2ban nach sich.


DFFVB schrieb:
  • Ufw allow openssh

richtig


DFFVB schrieb:

richtig

DFFVB schrieb:
richtig

DFFVB schrieb:
kann man machen.

Was man noch machen sollte:

Regelmässige Updates von allen Sachen.
Regelmässige Backups
- Server neumachen ist einfacher als nach einem Eindringen versuchen das zu beheben

Nur das installieren, wovon man Ahnung. hat. ein offenes Emailrelay ist schnell versehentlich eingerichtet.
(Ich rate generell zu externen Mailservern und Smarthosts)

Nicht einfach blind Befehle aus Anleitungen kopieren.

Was mach machen kann:

SSH mit 2FA per TOTP (Google Auth, Aegis usw)

Ergänzung ()

DFFVB schrieb:
Lohnt das schon für einen Dienst?
Für Plex definitv, schon wegen SSL. Wobei ich persönlich Plex nie ins offene Internet hängen würde. Stichwort VPN
Ergänzung ()


DFFVB schrieb:
Wie finde ich das raus?
Gar nicht. Alles was Testen könnte, testet nur auf bekannte Sachen und die sind bei regelmässigen Updates meistens gefixt.

Mach dich nicht verrückt, wenn was passierst dann sperrt erstmal Netcup den Server, du machst den platt und spielst die Daten zurück.
Ergänzung ()


DFFVB schrieb:
Ich dachte dabei an Honeypots
lass es, vorallem macht man das nicht auf einem Produktivsystem. Du lässt damit wissentlich fremde Leute, öffnest Ports usw. Sowas macht man auf vom Rest abgeschotten Systemen oder VMs

Lass die Software des Honeypots einen Fehler haben.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: DFFVB
To be honest:
Keep it simple: Starkes Passwort, kein Root oder Admin als Benutzer verwenden und dann passt das schon. Wenn du extra Sicherheit willst MFA mittels Google einrichten, das ist mehr als genug. Alle Dienste die du anbinden willst, per Reverse Proxy. Alle Dienste die mehrere Container brauchen, in ein eigenes Docker Netzwerk schieben und bspw. nur das Frontend nach außen Exposen anstatt Backend und DB.
 
  • Gefällt mir
Reaktionen: DFFVB
Firewall braucht man im Allgemeinen nicht. netstat -lp sollte nur Dienste an der öffentlichen IP anzeigen, die auch wirklich öffentlich zugreifbar sein sollen, alle anderen gehören abgeschaltet.

Unattended-upgrades unbedingt anschalten.

Viel spannender als OpenSSH und nginx ist z.B. die Frage, wie genau Du Plex installieren und aktuell halten willst.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: DFFVB und Der_Picknicker
Erstmal besten Dank für die Rückmeldungen! Sehr hilfreich.
Über einen Reverse Proxy gehen die Meinungen ja auseinander. Ohne Prox muss ich mich darauf verlassen, dass die Plex-Anmeldeseite, keine Fehler enthält. Wenn ich mich hier über 2FA bzw. besser über einen Google Account der nur zu diesem Zweck da ist, anmelde, sollte da ja relativ sicher sein?

Wenn ich jetzt einen Reverse Proxy vorschalte wie genau erhöht sich die Sicherheit? Es ändert sich ja erstmal nur, dass ich per subdomain statt Port auf Plex zugreife? Wenn ich es ernst meine müsste ich ein IAM wie Authelia, Authentik zwischen Reverse und Plex schalte? Und dieses würde die Sicherheit nur dann erhöhen wenn es sicherer wäre als die Plex Anmeldemaske. Korrekt? Wenn man sich dafür entscheidet was empfehlt ihr? Ich finde Bunkerweb klingt ganz gut, weil halt auch ne WAF eingebaut ist.

Renegade334 schrieb:
Port ändern kann man machen, hilft aber eher die Logs sauber zu halten als echte Sicherheit zu bringen.

Ich hätte gedacht, wenn ich in einen höhren Bereich gehe, diese wenige in den Standard-Scripten der robots enthalten sind.

Renegade334 schrieb:
Port knocking wäre auch noch eine Möglichkeit die du dir anschauen könntest.

Gute Idee!

Renegade334 schrieb:
Möglichst alle Software mit eingeschränkten Usern laufen zu lassen wirst du ja sicher schon bedacht haben.

Mal blöd gefragt: Das ist doch unter Ubuntu standardmäßig der Fall? Wenn ich Services einrichten will, muss das ja immer per sudo erfolgen?

andy_m4 schrieb:
Bei SSH würde ich das Login auf jeden Fall mit 'nem Public-Key machen statt mit einem Passwort.

Genau, daher Password no in der ssd_config

Renegade334 schrieb:
Was immer wichtig ist, ist die Software zu patchen.

xammu schrieb:
Regelmässige Updates von allen Sachen.

Hier hatte ich die unattended upgrades im Auge, bzw. ab und an (1 Mal imMonat aufschalten und schauen). Ich weiß Updates können einem etwas zerhauen aber dafür hab ich ja Backups

xammu schrieb:
Regelmässige Backups

Dachte hier an Snapshots die Netcup anbietet. Sonst wohl am ehesten Borg? Kopia? Braucht man ja aber auch ein Ziel sprich anderen Speicher im Netz oder?

xammu schrieb:
offenes Emailrelay ist schnell versehentlich eingerichtet

Hast Du da Beispiele? Würde ich gerne vermeiden.
xammu schrieb:
Für Plex definitv, schon wegen SSL. Wobei ich persönlich Plex nie ins offene Internet hängen würde. Stichwort VPN

Guter Punkt - hab gesehen bei Plex kann man PKCS #12 Zertifikate hinterlegen. Warum würdest Du Plex nicht ins Netz hängen?

xammu schrieb:
lass es, vorallem macht man das nicht auf einem Produktivsystem.

Ist die Vorbereitung für ein Produktivsystem. Bis jetzt alles testing, weil ich Erfahrungen sammeln will. Danke nochmal für den Input
 
DFFVB schrieb:
Dachte hier an Snapshots die Netcup anbietet.
Die sind kein echtes Backup, sondern nur so ne Art Disaster Recovery.

Backup sind sie nicht (wirklich) weil a) nicht inkrementell (Netcup hält glaube ich nur einen Snapshot vor?) und b) nicht dezentral. Brennt Netcup ab oder klickst Du aus Versehen auf "Account löschen", ist alles weg. Und ja, es kommt schonmal vor, dass bei Providern auch mal Fehler wie "aus Versehen Accounts gelöscht" passieren.

Und ansonsten ja BorgBackup ist schonmal ganz gut. Mach das so, dass auch ein gehackter Server nicht alle Backups überschreiben kann (bei Borg ist das Stichwort "append-only").
 
  • Gefällt mir
Reaktionen: DFFVB
DFFVB schrieb:
Hast Du da Beispiele
leider nicht wirklich, da ich seit Jahren keinen eigenen Mailserver mehr betreibe. Der Aufwand ist mir zu hoch.
Akutell nutze ich meistens Netcup oder 1und1 Mailserver als Smarthost. Ankommende Mails landen bei Netcup.
 
DFFVB schrieb:
Die Frage ist ja, warum man überhaupt Plex ins Internet hängen will.
Also wenn es nur für Dich oder ein kleiner Personenkreis ist, dann kann man die Problematik auch einfach dadurch lösen, in dem man ein "VPN" davor hängt. Dann meldet man man sich auf dem VPN an und alles ist gut.
Das kann im einfachsten Fall das SSH sein, was Du ohnehin schon hast.

Vielleicht solltest Du mehr darüber reden, was Du eigentlich genau vor hast. Dann kann man viel gezielter drauf antworten. Ich glaube, das bringt mehr als über allgemeine Vorteile/Nachteile von Reverse Proxy und Co zu quatschen.
 
  • Gefällt mir
Reaktionen: konkretor, RedPanda05 und JumpingCat
DFFVB schrieb:
Mal blöd gefragt: Das ist doch unter Ubuntu standardmäßig der Fall? Wenn ich Services einrichten will, muss das ja immer per sudo erfolgen?
Müsste nachschauen wie es bei Ubuntu ist, aber wenn du etwas mit sudo installierst, hat es die Möglichkeit sich als root zu hinterlegen.
Wenn die Services am Ende mit einem extra User der keine sudo Rechte oder direkt root hat laufen, sollte das ok sein.
Gute Software sichert, falls die überhaupt einen Service Account benötigt, den dann mit nologin und ähnlichem ab, damit da weniger passieren kann.

Für ein offenes Mail Relay reicht leider schon eine PHP Lücke, mit der jemand einen PHP Mailer installiert.
Da geht es nicht einmal unbedingt um ein vollwertiges Relay, aber wenn du einen eigenen Mail Dienst anbietest, dann kann dein Host zur Spamschleuder werden.

Netcup hat aber in den meisten Paketen bereits einen managed Mail Service. Dann reicht es da passend Adressen anzulegen und den Mail Host zu hinterlegen (z.B. für Backup Meldungen oder Kontaktformular).
Dabei kann bei einer Lücke natürlich auch der Zugang dafür entwendet werden, aber Spam bekommt netcup eher mit als du :)
 
  • Gefällt mir
Reaktionen: DFFVB
Renegade334 schrieb:
Für ein offenes Mail Relay reicht leider schon eine PHP Lücke, mit der jemand einen PHP Mailer installiert.
Wenn man eine "PHP Lücke" hat (da ist wohl eher "eine PHP-Serveranwendung mit Sicherheitslücke installiert" gemeint?), ist die Möglichkeit, dass jemand einen Mailer installiert, wohl das kleinste Problem. :)

Mit "offenes Mail-Relay" meint man normalerweise eher, dass der Rechner über SMTP Mails an beliebige Domains annimmt und weiterschickt. Das war in den 1990ern vielleicht noch ein Problem, aber inzwischen sind die MTAs alle per Default anders konfiguriert (und nehmen nur Mails für sich selbst an).
 
GrumpyCat schrieb:
Wenn man eine "PHP Lücke" hat (da ist wohl eher "eine PHP-Serveranwendung mit Sicherheitslücke installiert" gemeint?), ist die Möglichkeit, dass jemand einen Mailer installiert, wohl das kleinste Problem. :)
Kann auch durch Fehlkonfiguration passieren (Upload in aufrufbare Verzeichnisse die nicht immer auf +X achten). Gab es früher häufiger bei irgendwelchen CMS.

Das zweite ist, was ich mit vollwertigem Relay meinte :)
Auch das kommt selbst bei Firmen gerne noch vor, dass da einer an der Config was ändert und z.B. die Firewall extern Mails annimmt und verteilt.
Da schreibt einen dann sogar die Telekom an, wenn man es zu sehr versaut. Die suchen auch proaktiv nach offenen Relays.
 
Renegade334 schrieb:
Müsste nachschauen wie es bei Ubuntu ist, aber wenn du etwas mit sudo installierst, hat es die Möglichkeit sich als root zu hinterlegen.

Ja wäre nett, wenn Du Dir das mal anschaust. Ich frag mich halt, wenn ich bspw. diese Anleitung https://www.howtoforge.de/anleitung/so-installierst-du-plex-media-server-unter-debian-12/ befolge. Dann muss ich mit sudo installieren. Das hieße, wenn ich dich richtig verstehe, ich müsste die Anwendung darauf prüfen, ob sie sich per sudo root Rechte verschafft?
 
Wo ist der konkrete Nachteil die native Version von Plex zu installieren?
 
So wie das im Howtoforge beschrieben wird (auf Basis der apt-sourcen direkt von den Plex-Autoren) gehört das.

Per Docker kann man installieren, wenn man Bock auf einen weiteren Layer Unwägbarkeiten und Gerümpel hat, von dem keiner weiß, wie aktuell es ist, schließlich holt man sich damit mehr oder weniger eine Parallelinstallation eines weiteren Betriebssystems ins Haus. Aber schnell installiert und bequem ist's so natürlich.
 
  • Gefällt mir
Reaktionen: Renegade334, dx1 und DFFVB
Zurück
Oben