Server administrieren - wo fange ich an?

  • Für manche Sever nutze ich keine keys. Und zwar für die, auf die von allen möglichen verschiedenen Rechnern aus zugegriffen werden muss und das auch noch von mehr als einem Admin. Langes, aber leicht zu merkendes Passwort und gut ist. :)

  • Wenn ich einen Zugriff auf all meine Server via SSH nur für eine IP erlaube (VPN Server), bringt mir ein SSH-Key dann noch irgendeinen Vorteil, oder kann ich mir das sorgenfrei sparen?

    IMHO ist Sicherheit etwas, dass aus vielen verschiedenen großen und kleinen Dingen zusammengesetzt ist, die alle zum Ziel haben, verschiedene Risiken zu minimieren. Wenn man jetzt anfängt, einzelne Dinge wegzulassen, weil andere „bessere“ Dinge sie vermeintlich überflüssig machen, verschenkt man Securitypotential. Ich tippe lieber einmal das Passwort für mein Keyfile.

  • durch den unverschlüsselten key gewinne ich ja bequemlichkeit.

    soetwas würde ich niemals weglassen und auf meinen ssh-servern ist eh' nur key-login erlaubt.

    »Hauptsache BogoMIPS!«

    Fleischfresser

    »Sämtliche Cyberrisikomanagementmaßnahmen wurden übererfüllt!«

    Edited once, last by Olivetti: jessas, ich muss öfter mal ctrl-r drücken. der thread ist ja schon wieder alt. ().

  • Ist meiner Meinung nach immer eine Abwägung zwischen Bequemlichkeit und Sicherheit.

    Ich verwende grundsätzlich nur Keys mit Passwort, dann muss ich mir weniger Gedanken machen, ob ein Server nur via Hop oder evtl. doch direkt erreichbar ist.

    Passworte sind eher die Ausnahme, z.b. bei Test-Systemen oder für unprivilegierte User (ohne sudo etc.)


    Allerdings muss ich zugeben, dass ich mit passwortgeschützten Keys gerade bei automatisierten Aufgaben (Ansible, cron, ...) so meine Probleme habe.

    RS 2000 G11 | VPS 1000 G11 | VPS 500 G8 Plus | RS X-Mas 2016 🎄 | VPS A Ostern 2017 | VPS [piko|nano|mikro] G11s | RS Cyber Quack 💗 | WH Expert Special 2018

  • Allerdings muss ich zugeben, dass ich mit passwortgeschützten Keys gerade bei automatisierten Aufgaben (Ansible, cron, ...) so meine Probleme habe.

    Ich würde dir raten, nicht den Key selbst zu verschlüsseln sondern lieber den Private Key in einem Passwort Manager zu hinterlegen. Viele Passwort Manager z.B. 1password haben einen SSH-Agent mit an Board. So hat man jederzeit den Private Key an einem sicheren Ort, gleichzeitig kann man sich ganz bequem zu den Servern verbinden. Auch bieten viele Passwort Manager CLI Tools an, um eben Automatisierungen zu ermöglichen.

  • Meine SSH-Server sind nur über ein VPN erreichbar. Zusätzlich habe ich noch einen Jump-Host.

    Ich verwende ausschließlich SSH-Keys mit Passwort. Die speichere ich in meinem User-Keyring.


    Ansible nutzt den Keyring, so dass ich problemlos automatisieren kann, trotz Password.

  • Hallo zusammen,


    ich habe bei einem meiner Server angefangen bei Neuinstallationen nicht mehr den Apache2 zu verwenden, sondern nginx.


    Des Weiteren zeigt es mir die eine Apache2 Startseite ein und nicht die von nginx.


    Dabei ist apache2 gar nicht installiert.


    Installiert ist certbot letsencrypt php8.3 sury

    Ich bin der Anfang, das Ende, die Eine, die Viele ist.

    Ich bin die Borg.

  • Hat sich erledigt.

    Das Problem saß vor dem Computer. :whistling:

    Ich bin der Anfang, das Ende, die Eine, die Viele ist.

    Ich bin die Borg.

    Happy Duck 4
  • Ich spiele gerade mit dem Gedanken, ein paar meiner Server innerhalb „meines Verbunds“ einzuschließen, also jeglichen Zugriff zu verbieten, mit Ausnahme von den „eigenen“ IPs. Das macht für mich vor allem für das Monitoring sowie meinen Docker Sinn.

    Spricht da etwas dagegen? Wie stelle ich sicher, dass z. B. unattended-upgrades oder natürlich auch ein manuelles apt update etc. nach wie vor funktioniert? Wie kann ich den Servern erlauben, weiterhin Nachrichten via TelegramBot zu versenden?

    [RS] 2000 G11 | 1000 G11 | 2x Cyber Quack | Vincent van Bot

    [VPS] 2000 ARM G11 | 1000 G9 | mikro G11s | 4x nano G11s
    [WH] 8000 SE | 4000 SE | 2000 SE

  • Das kommt darauf an wie scharf du das Ganze betreiben willst, zumal (zumindest ich) deine Systeme und deren Kommunikationsbeziehungen nicht kenne^^


    Also zunächst rein generisch:

    Ein Anfang wäre es, der/die Firewall(s) auf "DENY incoming" zu setzen (keine eingehenden Verbindungen erlaubt). Per Whistelisting dann die eigenen IPs + nötige Ports,etc. erlauben.

    Im Ergebnis lässt dein Server nun keine eingehenden Kommunikationsbezeihungen außer von den erlaubten IPs und zu den konfigurierten Ports zu.


    Ausgehend kann man das Ganze natürlich auch beliebig komplex konfigurieren, aber ein "ALLOW outgoing" (ausgehende Verbindungen vom Server sind erlaubt) sollte ahS erstmal absolut OK sein.


    Im Gesamtergebnis können nur noch deine eigenen IPs über von dir definierte Ports mit dem Server sprechen. Ausgehend würden hier zunächst keine Einschränkungen herrschen, womit auch ein "apt update",etc. weiterhin as usual funktioniert.

    Wenn dein "apt update" eine Verbindung zu bspw. den Debian-Repo-Servern aufbaut, ist die anschließende und zugehörige eingehende Verbindung zulässig. Hier muss also nichts zusätzlich bei eingehenden Verbindungen konfiguriert werden.


    Das ist jetzt aber (wie genannt) absolut generisch ohne Round-About...würde aber so funktionieren.


    -----------------------


    Ich betreibe bspw. diverse Services in einem "Backend". D.h. hier befinden sich mehrere Services innerhalb eines privaten IPv4-Netzes und einem zusätzlichen IPv6-Subnetz (ich nutze Proxmox, daher das zusätzliche Subnetz...sonst ist das bei Netcup mit IPv6 leider nur ein rumgesch*sse)


    Als "Gatekeeper" terminieren alle eingehenden Verbindungen immer auf einem vorgeschalteten Reverse-Proxy (nginx), der das Ganze dann in mein "Backend" zum entsprechenden Service weiterschubst. Meine Services selber lassen Ausnahmslos nur eingehenden IP-Verkehr aus diesem genannten, privaten IPv4-Netz sowie nur meinem eigenem zusätzlichen IPv6-Subnetz zu. D.h. von "außen" kommt keiner an die Services.

    Auch alle meine DNS-Records terminieren alle auf dem Reverse-Proxy.


    Bildlich gesehen eine "Bubble" mit allen meinen Services und einem Reverse-Proxy obendrauf. Intern können die miteinander sprechen wie sie wollen...von außen geht`s nur über den Revers-Proxy rein.

    Das Ganze könnte man eingehend am Reverse-Proxy jetzt natürlich (wie in deiner Idee) noch auf bestimmte IPs festnageln..


    Da gibt es auch andere Lösungen, aber in meinem Fall war das für mich die zweckmäßigste.

  • Spricht da etwas dagegen? Wie stelle ich sicher, dass z. B. unattended-upgrades oder natürlich auch ein manuelles apt update etc. nach wie vor funktioniert? Wie kann ich den Servern erlauben, weiterhin Nachrichten via TelegramBot zu versenden?

    Port 80 und 443 TCP und 53 UDP ausgehend erlauben. Damit funktionieren APT, Telegram Bot und DNS noch sauber.