Server besser absichern

Hinweis: In dem Thema Server besser absichern gibt es 27 Antworten auf 3 Seiten. Der letzte Beitrag () befindet sich auf der letzten Seite.
  • Die haben wir, trotz hohem SSH- Port und allen anderen Mechanismen.
    Für SSH ist damit auch ziemlich Ruhe im Karton.


    Hauptsächlich rühren diese Versuche von Spammern her, die unbedingt unseren mit DMARC/DKIM und STARTTLS gesicherten Mailserver mistbrauchen®™ wollen.
    (Einige User maulen schon, weil die Spamabwehr Dropbox, Telekomiker und Konsorten gleich als Spammer ausschliesst. Ich folge dem guten Linuxgrundsatz: No news are good news.)


    Dennoch sollte man das nicht unterschätzen.
    Gefährlich sind die, die sich Zeit lassen und über Wochen hinweg sehr sparsam die Ports proben.
    Die sind schwierig zu erwischen und erst recht kaum zu bannen. Da müsste man schon jeden Tag einen guten Mann hinstellen, der nur Logs analysiert.
    Die können einfach mehr und gehen das Hacken sehr systematisch und mit viel Know- How an.

  • Moin zusammen,


    Berichtigung, die wirklich guten Hacker wird man da kaum erwischen, da gebe ich Dir Recht. In der Regel sind die den Sysadmins eh meistens leider um 1-2 Schritte voraus.
    Nur so ist es auch zu erklären, dass sich (vorzugsweise in Amiland) die großen Firmen 1 bis X solcher Menschen 'leisten' um die eigene IT-Sicherheit zu checken und zu gewährleisten .... selbstredend können sich diese Herrschaften ihre Gehaltsschecks dann selber ausstellen .... will sagen die werden mehr als nur großzügig bezahlt.


    Was diese hohen Attackraten aber angeht, c'me on, das sind doch zu über 95% Scriptkiddies, die noch an der Muttermilch saugen und im Netz irgendwelche 'coolen' Tools gefunden haben mit denen sie ohne Sinn und Verstand rumspielen.


    Da langt wie Du auch schon mehrfach erwähnt hast, ssh auf anderen Port, Passwort Login komplett untersagen, fail2ban und psad in Personalunion vollkommen aus um gut Ruhe im Karton zu haben.

    Viele Grüße,
    T.

    Für den Inhalt des Beitrages 128664 haftet ausdrücklich der jeweilige Autor: Tamerlain

  • Herzlichen Dank erstmal für den vielen Input und den damit verbundenen Aufwand für meine "Probleme" :thumbup:


    Anstatt jetzt jeden zu zitieren, würde ich das gesammelte Wissen mal in einer flachen Liste zusammenfassen:

    • SSH root Zugriff via Schlüssel wieder erlauben (erleichtert vor allem auch die Bedienung mit WinSCP und ich kann meinen unprivilegierten Benutzer wieder aus der sudoers austragen)
    • fail2ban einsetzen, jedoch vorher die Dokumentation studieren
    • iptables IP-Blocks wieder entfernen (siehe Punkt fail2ban). Übrigens: Die waren nicht IP-Adressbasierend, sondern IP-Bereichsbasierend mithilfe von Subnetzmasken.
    • psad und ufw einsetzen, jedoch vorher die Dokumentation studieren
    • Finger weg von Intrusion Detection und Applicaction Layer Firewalls, wenn man nicht 100 prozentig weis was man tut. Was aktuell bei mir noch nicht der Fall ist. RegEx verstehe ich zwar, kann ich aber noch nicht auswending beten. Vorallem ist mir der Dialekt von grep noch schleierhaft, mit den Dialekten von PCRE, Java und C# komme ich allerdings gut klar. mod_rewrite vom Apache Webserver auch nur bedingt was das Thema RegEx anbelangt.
    • lieber auf einen USB Stick mit cryfs setzen, als einen Hardware Wallet anzuschaffen. Vor allem wegen dem eigenen Lerneffekt.
    • Quantenrechner sind noch nicht wirklich im "hier und jetzt" angekommen, von daher noch keine ausschlaggebende Gefahr für das SSH Protokoll ohne Zweifaktor-Autorisierung
    • Ein eigens VPN aufbauen für das Authentifizierungs- und Autorisierungsmanagement hört sich gut an, allerdings bin ich davon vom Know-How her noch weit entfernt.
    • SSH Port jenseits der well-known Ports legen, um Ressourcen einzusparen (nicht wegen der Sicherheit)

    Was ich noch zusätzlich einsetzen würde zu der oben genannten Software:

    • ClamAV im Cronjob mit Bericht via E-Mail
    • rkhunter im Cronjob mit Bericht via E-Mail
    • eventuell noch ein Monotoring System wie Nagios oder den ELK (Elasticsearch, Logstash und Kibana) Stack zur komfortableren Analyse von Logfiles, sowie wegen der Dienst-Gesundheitsstatus.


    Eine Frage noch: Würde es anstatt cryfs auch Truecrypt tun? Truecrypt wurde doch nur auf Nachdruck der amerikanischen Geheimdienste als "nicht sicher" deklariert. Außerdem würde ich cryfs vornehmlich unter Windows einsetzen und der Windows Support ist noch in der Beta Phase. Denn ich habe immer noch die gleiche Ausgangslage wie vor Jahren: Einen PC mit Software RAID und Hybrid Festplatten, deswegen kein Linux im DualBoot. Ich setze stattdessen eher auf Hypervisor, man merkt dort kaum einen Unterschied mehr zum "echten" Linux.
    Könnte man cryfs heute schon unter Windows mittels Cygwin einsetzen? Ich überlege eh von "Git Bash for Windows" hin zu Cygwin zu migrieren.


    Aktuell habe ich alle meine Passwörter und SSH Key Files in KeePass Passwort Container abgelegt. Der ist auch Cross Platform kompatibel über das .NET Core Framework. Wem .NET nicht gefällt, der kann sich auch einer inoffiziellen Portierung bedienen. So hatte ich zum Beispiel schon KeePassX auf Mac OS X eingesetzt. Wirklich eine durchgängige Lösung ist KeePass allerdings nicht, besonders weil man für PuTTY, openSSH & Co. die Schlüssel noch außerhalb des verschlüsselten Containers auf der Festplatte irgendwo ablegen muss.


    Was ich mit Hardware Wallets meinte: Das sind "Geldbeutel" für Kryptowährungen in Hardware-Form. Denen sagt man etwas mehr Sicherheit zu als die reine Software seitige Verschlüsselung. Vor allem auch deswegen, weil der private Schlüsselteil nur auf diesem USB Stick liegt, und eben nicht wie bei Software Verschlüsselung üblich, irgendwo auf der Festplatte. Diese Wallets kann man nicht nur ausschließlich für Kryptowährungen nutzen, sondern ebenfalls für Zweifaktor-Autorisierungen. In Bezug auf letzteres halte ich das aktuell für den State-of-the-art, denn alternative Zweifaktor-Autorisierungen funktionieren nur via E-Mail, SMS oder den Google Authentifikator. Gerne könnt ihr mich in diesem Punkt eines Besseren belehren, falls ich nicht den nötigen Kenntnisstand besitzen sollte. Ansonsten natürlich auch... :whistling:;)


    PS: Den Rat komplett den Server abzuschalten und eher Platform-as-a-Service zu benutzen habe ich verstanden und beherzigt. Allerdings, finde ich, lernt man solche Fähigkeiten nur durch selber machen, "learning by doing" quasi. Außerdem bin ich mir sicher, dass sich im Netz noch viel unsichere Server tummeln als meiner (Stichwort Agenturen). Wie auch immer, man sollte sich kein Beispiel an den Schlechten nehmen, sondern eher an den Guten. In diesem Sinne halte ich "learning by doing" als den einzigen gangbaren Weg, mein Know-How auf den benötigten Stand zu bringen.

    Diese Signatur ist derzeit nicht verfügbar.

    Für den Inhalt des Beitrages 128666 haftet ausdrücklich der jeweilige Autor: derwunner

  • Moin zusammen,


    beim rootkey bitte die *starke* Passphrase nicht vergessen!! Desweiteren kann man mit from arbeiten, um rootaccess nur von bestimmten Adressen7Adressbereichen zuzulassen.
    unprivilegierter User mit sudorecht würde ich _grundsärtlich_ einrichten .... auch den Root kann man sich mal zerschnippeln .... wenn dann gar kein Zugriff mehr möglich ist eiweiwei.


    USB Stick mit Passwörtern drauf und wenn 100x gecrypted - NEVER EVER .... getreu dem Motto, was haben Regenschirme, Geburtstage und USB Sticks gemeinsam ..... sie werden vergessen!


    Hier ist _immer_ auf einen KeySafe zu setzen, dessen Keydatenbank verschlüsselt auf dem/den Rechnern liegt mit denen man arbeitet und _zusätzlich_ auf einem Speichermedium im realen Safe/Bankschliessfach, falls es die DB mal schnetzelt.


    Es gibt im Übrigen auch KeySafes, die Plattform übergreifend arbeiten, sprich unter Win, Linux, Android etc. z.B. vom 'Russen' die. Die hat meines Wissens leider noch kein Browser Plugin, aber das ist verschmerzbar glaube ich.


    Was die ssh-Keys angeht .... nun, die kann man fein sauber auf ner verschlüsselten Partition auf der Platte ablegen. Die muss man natürlich entschperren, wenn man mit den Keys arbeiten will. Auch diese selbstredend als Sicherungskopie auf nen Speichermedium in den Safe/Bankschliessfach.

    Viele Grüße,
    T.

    Für den Inhalt des Beitrages 128668 haftet ausdrücklich der jeweilige Autor: Tamerlain

  • ufw ist ein Frontend zu iptables.
    iptables macht weiterhin die Arbeit. ufw macht nur das Erstellen eigener Regeln einfacher und somit sicherer.


    cryfs verschlüsselt auch die Spasswörter. Insofern schenken sich die verschiedenen Lösungen nichts.
    selbstverständlich kannst du Truecrypt nehmen.
    Aber cryfs kann halt ein paar modernere Verschlüsselungsverfahren.
    Ich denke zwar schon, dass die möglichen Verschlüsselungen von cryfs "besser" sind, aber ich kenne auf der anderen Seite Truecrypt nicht.
    Das müsste man sich mal sorgfältig angucken.


    Ob nun Hardware Wallet, oder selbst gebasteltes USB Wallet:
    Wer das verliert, hat halt verloren.
    Das ist für mich kein Argument.


    VPN solltest du dir schleunigst angucken.
    Das ist nicht so schwer. Die bieten auf ihrer Seite eine hervorragende Doku. Arbeite die durch und du hast ein VPN.


    Sonst ist deine Zusammenfassung korrekt.


    rkhunter solltest du auf einer jungfräulichen Installation aufrufen.
    Es erstellt von wichtigen Dateien und 'Programmen Fingerabdrücke und speichert die in seiner Datenbank.
    Das macht nur Sinn, wenn du wirklich von einer sauberen, möglichst jungfräulichen Installations ausgehst.
    (Oder du bist dir __wirklich__ sicher, dass deine Installation __wirklich__ sauber ist.


    Es gibt natürlich auch open source 2Faktor Systeme.
    Setze einfach eines mal auf.
    Dann kannst du gleich deinen USB Stick als zweiten Faktor einsetzen.
    Damit hättest du deinen eigenen Yubi Key, der noch den Vorteil hätte, dass ihn nicht schon alle Hacker in den Fingern haben.


    Und das alles selber machen und lernen ist immer der beste Weg.
    Finde ich sehr gut.

  • Truecrypt war mal sehr gut, wie gesagt war! Es wird, seit 2012 glaube ich, nicht mehr weiterentwickelt! Der Nachfolger von Truecrypt ist Veracrypt und läuft wie Truecrypt sowohl unter Linux als auch unter Windows!

    Für den Inhalt des Beitrages 128673 haftet ausdrücklich der jeweilige Autor: Z_O_O_M

  • Ich wollte gerade mal mit psad anfangen. Laut zypper gibt es das nicht in den Repos, eine online Suche ergab das: openSUSE Software
    Bevor ich jetzt anfange das installer Perl Skript vom Anbieter zu installieren wie hier beschrieben, würde ich gerne mal wissen, ob es andere Möglichkeiten auch gibt?


    Noch eine Frage: Inwieweit arbeitet die ufw mit der SuSEFirewall2 zusammen?

    Diese Signatur ist derzeit nicht verfügbar.

    Für den Inhalt des Beitrages 128680 haftet ausdrücklich der jeweilige Autor: derwunner

  • moin zusammen,


    psad ist klasse.
    Die neueste Version gibbet auch ned für Debian in der Distri ... na und ... beim Hersteller vorbei, neuestes Paket besorgen, Installscript laufen lassen, konfigurieren und gut is.


    Das neueste Paket muss man auch haben, denn die älteren Pakete wollen nicht mit der Firewall ... warum auch immer. Das 2.4.6er packt das ganz wunderbar.


    Unter SuSE ist das auch nix Anderes .... Paket holen und installieren.
    Wenn Du nen bissi wurschteln willst, kannste das tar auspacken und ein RPM Paket draus basteln. Der ewige Dank der Leute wird Dir sicher sein :thumbup:

    Viele Grüße,
    T.

    Für den Inhalt des Beitrages 128683 haftet ausdrücklich der jeweilige Autor: Tamerlain

  • Beim Versuch es manuell zu installieren erhalte ich folgenden, für mich nichts-sagenden Fehler:


    Code
    ~/psad/psad-2.4.6 # ./install.pl
    [*] systemd init directory /lib/systemd/system does not exist, use --systemd-init-dir <path> at ./install.pl line 256.

    systemd ist doch als Init System installiert, deswegen verstehe ich die Fehlermeldung nicht. Laut Google liegt das bei anderen Distris an irgendwelchen Konfigurationsdateien.

    Diese Signatur ist derzeit nicht verfügbar.

    Für den Inhalt des Beitrages 128691 haftet ausdrücklich der jeweilige Autor: derwunner

  • openSUSE folgt der LSB (LinuxStandardBase) und damit dem FHS (FileHierarchyStandard) möglichst genau.


    Probiere es mal mit angehängtem --systemd-init-dir /var/lib/systemd/system
    (ggf. das system am Ende weglassen)