Server Sicherheit

  • Um mal ehrlich zu sein habe ich 0. Sicherheitsvorkehrungen getroffen, ich habe dasselbe passwort für root und hauptnutzer und sudo geht ohne passwort, mir ist trotzdem nie was passiert

  • Hay,

    Um mal ehrlich zu sein habe ich 0. Sicherheitsvorkehrungen getroffen, ich habe dasselbe passwort für root und hauptnutzer und sudo geht ohne passwort, mir ist trotzdem nie was passiert

    Den meisten Leuten passiert es auch nur so lange nicht, bis es halt mal passiert (so wie z.B. auf der Titanic... Kapitän: Huch, ein Eisberg? Noch nie passiert. Zu wenige Boote? Haben noch nie mehr gebraucht! Schiff sinkt? Noch nie passiert) ... einmal reicht :D


    CU, Peter

  • Hay,

    Den meisten Leuten passiert es auch nur so lange nicht, bis es halt mal passiert (so wie z.B. auf der Titanic... Kapitän: Huch, ein Eisberg? Noch nie passiert. Zu wenige Boote? Haben noch nie mehr gebraucht! Schiff sinkt? Noch nie passiert) ... einmal reicht :D


    CU, Peter

    Naja hoste ja nur meine Websiten darauf, viel privates ist da ja auch nicht, außerdem kann ich ja dank des SCP alles sehr schnell neuinstallieren

  • Um mal ehrlich zu sein habe ich 0. Sicherheitsvorkehrungen getroffen, ich habe dasselbe passwort für root und hauptnutzer und sudo geht ohne passwort, mir ist trotzdem nie was passiert

    Mir ist es passiert. Und zwar in der ersten Nacht nachdem ich mein erstes Linux installiert habe. Seither gehören gewisse Schritte zum Standard.


    Seither gab es nichts mehr dergleichen aber zweimal die Weiterleitung einer Mail vom Bundesamt für Sicherheit in der Informationstechnik (BSI) wegen einem offenen Port für Netbios und einem offenen DNS Resolver. Beide Probleme hatte ich entdeckt und schon gelöst, bevor die Mail vom Provider an mich weitergeleitet wurde.


    In der Regel weiss ich sehr genau, was auf meinen Systemen installiert ist. Trotzdem mache ich, insbesondere nach der Installation neuer Software, immer wieder mal einen Check der Ports. Im Falle des Netbios-Vorfalls war es so, dass eine Backup-Software, die ich installierte, Python und CIFS mitinstallierte. Das war mir nicht bewusst. Ich habe es aber bei einem netstat nach der Installation bemerkt und sofort behoben.


    Ich verzichte aber auf komplizierte iptables und Firewall Konstrukte, die höchstens ein Experte versteht, wenn es eine UFW auch tut. Zu verstehen, warum etwas ist, wie es ist, ist mir eh immer wichtig. Ansonsten komme ich spätestens kurz nach der Installation nur mit Keys auf meine externen Systeme und die Keys sind auch noch Passwort-geschützt.

  • Naja hoste ja nur meine Websiten darauf, viel privates ist da ja auch nicht, außerdem kann ich ja dank des SCP alles sehr schnell neuinstallieren

    Und auf die Idee, dass Dein Server gekapert und für andere Dinge missbraucht werden kann kommst du nicht, oder?

    Ich habe hier regelmäßig Zugriffe auf nicht existierende Verzeichnisse, die mal eben "testen" ob mein Webauftritt verwundbar ist.
    Komischerweise kommen viele Zugriffe von IP-Adressen, auf denen normale Webseiten laufen wie z.b. die einer freiwilligen Feuerwehr oder eines Herstellers von Dichtungsringen.

    Nur weil Du Dich sicher fühlst, muss es nicht der Fall sein.

  • Und auf die Idee, dass Dein Server gekapert und für andere Dinge missbraucht werden kann kommst du nicht, oder?

    Ich habe hier regelmäßig Zugriffe auf nicht existierende Verzeichnisse, die mal eben "testen" ob mein Webauftritt verwundbar ist.
    Komischerweise kommen viele Zugriffe von IP-Adressen, auf denen normale Webseiten laufen wie z.b. die einer freiwilligen Feuerwehr oder eines Herstellers von Dichtungsringen.

    Nur weil Du Dich sicher fühlst, muss es nicht der Fall sein.


    Das kann ich so auch von mir bestätigen, solche Zugriffe habe ich z.B. auch - und davon nicht zu wenig.


    Damals als ich bei einem anderen Hoster meinen ersten vServer hatte, hab ich mir zu dem Thema auch nichts gedacht. Dann hab ich nach etlicher Zeit zufällig mal in die Logs geschaut, und gesehen, dass diverse Leute aus u.A. Russland, den USA und div. asiatischen Ländern (soweit die IP zurückzuverfolgen war) mein root Passwort per Bruteforce geknackt hatten. (PermitRootLogin = yes, fail2ban = Gesundheit?, SSH Port = 22, Passwortstärke = Kartoffel)

    Zum Glück ist nichts passiert, aber ich glaube das wäre nur eine Frage der Zeit gewesen. Heute sichere ich meine Server vernünftig ab, damit ist die Wahrscheinlichkeit sehr gering, dass etwas passiert.
    Es geht weniger darum sich selbst zu schützen, sondern andere zu schützen. So ein Server kann schnell zu einer Waffe im Internet werden, wenn die falschen Leute Zugriff darauf haben.


    Also: lieber vorbeugen, als nach hinten umfallen. ;)

  • Kann ich so bestätigen. Bei mir ist zwar noch nichts passiert, aber ich erinnere mich gerade an die Kisten von DigitalOcean und Linode. Es dauert keine 30sec nachdem die Kiste online ist und es komme die ersten Login Versuche aus China und Russland. Musste zwischenzeitlich sogar mal die Mail Settings für Fail2Ban ändern, da ich eines Morgens knapp 500 Mail reports hatte mit gebannten IPs und whois Records. 90% davon von chinesischen Schulen und Hochschulen...

  • Es geht weniger darum sich selbst zu schützen, sondern andere zu schützen.

    Man bedenke hier zudem, dass wenn andere erstmal betroffen sind und ggf. einen Schaden davon tragen, das ganze wieder auf einen selber zurückfällt. Es ist immer noch der eigene Rootserver für dessen Absicherung man selber verantwortlich ist. Geht etwas schief, haftet man.

    außerdem kann ich ja dank des SCP alles sehr schnell neuinstallieren

    Du solltest eher daran denken, was dein Server (unter der Kontrolle des Angreifers) eventuell woanders an Schaden angerichtet hat. Wie oben beschrieben bist du für diesen verantwortlich, das kann mitunter rechtliche Konsequenzen einschließen.

    Außerdem: In der Zeit, in der du einmal den Server neuinstallierst, kannst du genau so gut die wichtigsten Sicherheitsvorkehrungen treffen, das musst du dann auch nur einmal.


    Es mag eventuell ein wenig zeitaufwändig sein (wenn man sich nicht dumm anstellt, ist es das nicht), aber man sollte sich lieber jetzt mit der Absicherung seines Servers befassen, als später mit den Konsquenzen. Ist angenehmer.

  • Falls du eine findest, wäre es nett wenn du sie hier teilen würdest. Danke! :)

    Natürlich. Auf Anhieb habe ich leider nur die drop liste von spamhaus.org gefunden. Man muss bei IPv6 halt möglichst immer ganze Adressräume sperren. Wenn ich über mehr stolpere teile ich es :thumbup:.

    Um mal ehrlich zu sein habe ich 0. Sicherheitsvorkehrungen getroffen, ich habe dasselbe passwort für root und hauptnutzer und sudo geht ohne passwort, mir ist trotzdem nie was passiert

    Bei meinem Raspberry zu Hause, den man nicht von extern erreichen kann, ja. Aber ein Server im Netz... das ist mir zu heikel und mir geht es dabei nicht um den Verlust von Daten sondern eher darum, für welche illegalen Zwecke man den Server nutzen könnte, der auf >meinen< Namen registriert ist.


    Wie 03simon10 schon geschrieben hat, es ist keine Arbeit alles einzurichten. Ich würde allerdings hinzufügen "wenn man erst einmal verstanden hat, welche Schritte was bewirken und wieso nötig sind".

  • Man muss bei IPv6 halt möglichst immer ganze Adressräume sperren

    das ist dem Umstand geschuldet, daß man als kleinsten zu vergebenden Bereich einen /64-Prefix bekommt;

    daher sperrt man bei IPv6 auch ganze /64-Netze und keine einzelnen IPv6-Adressen;

  • Da wir gerade beim Thema sind. Ist eigentlich noch nie jemandem aufgefallen, dass die /etc/ssh/sshd_config von Ubuntu 18.04 Minimal Installation aus den netcup Images leicht zerschrottet ist? PermitRootLogin yes und PasswordAuthentication yes kommen zweimal vor.

  • Ich möchte euch gerne noch einmal um Hilfe zu zwei Themen bitten.

    Meine erste Frage gehört evtl. nicht unbedingt in diesen Thread aber dennoch: Ich prüfe immer mal wieder meinen Traffic in /proc/net/dev und die Menge an eingehenden Daten kommt mir sehr komisch vor. Teilweise nach 1 Tag Uptime habe ich 300Mb, obwohl der Server selbst eigentlich nichts tun sollte. Der ausgehende Traffic sieht normal aus (wie von mir erwartet, äußerst gering).

    Wenn ich mit nethogs auf eth0 schaue kommt immer mal wieder ein Zugriff aber hierbei handelt es sich lediglich um 10-12 Byte. Mir ist zwar klar, dass das Aktualisierungsinverval alles etwas schwammig macht aber trotzdem finde ich es seltsam. Das kann doch nicht normal sein, oder?

    Auch unverständlich ist für mich zur Zeit wieso hier Verbindungen mit mir als Quelle zu fremden IPs aufgelistet werden, wenn diese auf offene Ports prüfen. Durch einen Selbsttest habe ich bestätigen können, dass der Port zwar dicht ist, aber nethog es einfach "so" darstellt, als ob es von mir kommt. Auch dachte ich, dass nftables das filtern sollte, bevor überhaupt irgendein anderes Programm etwas davon mitbekommt, aber nun gut, da fehlt mir wohl einfach noch das Verständnis im Detail.


    Zu meiner zweiten Frage:

    Ich schränke aktuell in der Firewall keine ICMP Pakete ein. Ich bin jetzt über die Info gestolpert, dass das gar nicht mal so gut ist, da man bei icmpv6 scheinbar einem Server einfach mitteilen kann, dass man selbst der kürzeste Weg zu einem anderen Knoten ist?! (Habe ich das echt richtig verstanden? Das wäre ja easy mitm by design?!). Meine Idee, erstmal nur die für Probleme relevanten (destination-unreachable, time-exceeded, parameter-problem und packet-too-big) zu erlauben, klappt für ipv6 leider nicht so gut, anschließend funktioniert ssh nicht mehr. Müssen hier bestimmte weitere Types erlaubt werden?. Dazu findet man auch Vorschläge in RFCs bzgl. der (notwendigen?) Neighbor discovery aber um ehrlich zu sein, klingt die Beschreibung dieser Types danach als ob der oben von mir genannte Fall eintreten kann. Würdet ihr mir dabei helfen und vllt. kurz erläutern, wie ihr icmpv6 absichert? Ich muss gestehen damit tue ich mir gerade schwer.

  • ICMP Pakete

    Ich schicke Dir einfach einmal Lektüre:

    Zu ICMP und Neighbour Discovery: https://de.wikipedia.org/wiki/…ery_Protocol#ICMPv6-Typen

    ICMPv6 - Typen: https://de.wikipedia.org/wiki/ICMPv6


    Was Du nicht möchtest, ist, dass Dein Host als Router fungiert. NDP Types 133,134,137 werden Dich daher besonders interessieren.

    Neben diesen kann akzeptiert auch der Linux-Kernel via /proc/sys/net/ipv6/conf/[interfacename] gewisse Einstellungen, sodass es nicht nötig sein wird, das über die Firewall zu lösen - außer für etwaige weitere Hosts.

  • Wenn ich mit nethogs auf eth0 schaue kommt immer mal wieder ein Zugriff aber hierbei handelt es sich lediglich um 10-12 Byte. Mir ist zwar klar, dass das Aktualisierungsinverval alles etwas schwammig macht aber trotzdem finde ich es seltsam. Das kann doch nicht normal sein, oder?

    Kommt natürlich darauf an, was du als Policy gewählt hast. Bei einem Drop sollte hier nichts auftauchen. Bei einem Reject kommt natürlich kein TCP Handshake zustande, allerdings wird ein ICMP Paket hinterhergeschickt mit dem Inhalt: Port is unreachable. tcpdump zeigt dir hier genauere Einblicke tcpdump -nni ens3 icmp




    Auch dachte ich, dass nftables das filtern sollte, bevor überhaupt irgendein anderes Programm etwas davon mitbekommt, aber nun gut, da fehlt mir wohl einfach noch das Verständnis im Detail.

    Die Programme bekommen davon nichts mit, aber sämtliche Kommunikation landet beim Kernel, der dann eben das Routing übernimmt oder an die Programme weiter vermittelt. Wenn du allerdings beim Kernel schnorcheln willst, schickt er dir die Duplikate der Pakete bevor sie die Kernelfirewall erreichen.

  • Erstmal Danke für eure Antworten ;).

    Was Du nicht möchtest, ist, dass Dein Host als Router fungiert. NDP Types 133,134,137 werden Dich daher besonders interessieren.

    Neben diesen kann akzeptiert auch der Linux-Kernel via /proc/sys/net/ipv6/conf/[interfacename] gewisse Einstellungen, sodass es nicht nötig sein wird, das über die Firewall zu lösen - außer für etwaige weitere Hosts.

    Ich möchte die Konfiguration(en) so wenig wie möglich verteilen, sollte also nichts gegen nftables-Regeln sprechen bevorzuge ich das aktuell :). Aber zurück zum Thema:

    Ich habe mir mal eine Konfiguration erstellt von der ich denke, dass es so passen sollte, es wäre super, wenn du mal drüber schaust. Mein Verständnis schreibe ich darunter, das darf natürlich gerne korrigiert werden :).

    Im Input erlaube ich die icmpv6 "Problem"-Pakete und stark limitiert ping/echo. Und ich erlaube neighbor- advert & -solicit, sowieso redirects und router adverts, solange das hoplimit noch 255 ist (soweit ich das verstehe bedeutet es, dass diese Pakete noch keinen Router passiert haben, und somit von meinem ersten Anlaufpunkt (Netcup Gateway?!) kommen und vertrauenswürdig sind). Alles andere wird gedropt.

    Im Output erlaube ich alles außer: router-advert und redirect wird immer gedroppt, da ich sonst als router agieren würde. neighbor-solicit & -advert und router-solicit droppe ich, wenn das hoplimit ungleich 255 ist, da sonst die Pakete bereits einen Router passiert hatten (und nicht ... auf meinem Mist gewachsen sind?!). Wenn das hoplimit 255 ist, ist es eine valide Anfrage/Antwort, die mein Server macht.


    Ist das so in Ordnung und kann ich das so bedenkenlos lassen?


    [...] Bei einem Drop sollte hier nichts auftauchen. [...] tcpdump zeigt dir hier genauere Einblicke tcpdump -nni ens3 icmp


    Die Programme bekommen davon nichts mit, [...]. Wenn du allerdings beim Kernel schnorcheln willst, schickt er dir die Duplikate der Pakete bevor sie die Kernelfirewall erreichen.

    Ich habe drop als default policy. Allerdings verstehe ich das mit der Kopie und ich vermute jetzt einfach mal solche Sniffer (wie z.B. nethogs) holen einfach alle Pakete beim Kernel ab; anders kann ich es mir zumindest aktuell nicht erklären.

    Mit tcpdump sieht es (für mich) soweit okay aus. Ich bekomme hauptsächlich neighor-solicitations mit und diese kommen auch immer von einer fe80 Adresse und gehen zu ff02... Sieht für mich als Laien erstmal nicht verdächtig aus. Das habe ich allerdings erst überprüft nachdem ich oben genannte Änderungen vorgenommen habe.

    Es bestätigt auch meine Vermutung, dass die Anzeige in nethogs (Verbindungen gehen von mir aus) einfach nicht stimmt, mit tcpdump sehe ich gut, dass zwar Pakete ankommen aber auf den geblockten Ports nichts raus geht.


    So richtig erklären kann ich mir aber den hohen eingehenden Traffic auch mit Hilfe von tcpdump nocht nicht. (Natürlich habe ich den Filter angepasst :).)