Sicherheit, Delegation von Aufgaben
TS
- datensicherung
- sicherheit
- webserver
Hello,
ich beziehe mich nochmal auf einen Thread vom 25.03.2023 (siehe "problematische Seite").
Darin hat Labertante mir vorgeworfen, ich hätte mehr Zeit auf die Paranoia bezüglich der unerlaubten Zugriffe auf den Rootserver, als auf die Datensicherung gelegt.
Fakt war leider, dass wir bezüglich der Datensicherung davon ausgehen mussten, dass Antagus/Vautron (unser Provider) das tägliche Geschäft erledigt und wir nur Monats-Vollsicherungen herunterladen würden...
Es ist also durchaus wichtig, wie genau man die Delegation von Aufgaben überprüfen kann und dies auch durchführt.
[Edit 2023-03-29 2104]
Dafür ist
In diesem Zusammenhang habe ich nach einem sehr guten Tipp von Raketen-Jörg schon vor langer Zeit zusätzlich zu fail2ban
das Filter recidive
und außerdem eine Loginkontrolle per eMail eingerichtet. Alles hat prima gearbeitet, bis der Provider eines Tages, als das System (vermutlich wegen einer sterbenden Platte) sehr langsam wurde, tätig werden musste.
Damals haben sie mir Die Einzelplatte durch ein (inzwischen billiges) RAID ersetzt mit direkter Spiegelung. Außerdem hat der Mitarbeiter im Service einen Großteil der permanenten IP-Sperren ausgelagert in eine Blacklist von IPSET.
Leider wurde die dann nach Hinzufügungen nicht regelmäßig gesichert, so wie ich das vorher von iptables gewohnt war. Der Service hatte versäumt, uns über die hinzugefügten Kompenenten und die Notwedigkeit, nun auch das aktuelle IPSET zu sichern, zu informieren.
Nach einem hosterinternen Absturz (Vermutung) und Reboot ist deshalb nicht alles wieder dicht gemacht worden und die Kiste hat ganz schnell gestanden. Das geben sie freilich nicht zu, sondern werden pampig.
Da kommen wir aber der eigentlichen Fragestellung auch langsam näher.
In welcher Reihenfolge und in welchen Startdateien müssen die Komponenten
beim Booten aktiviert, bzw. beim Shutdown gesichert werden?
Inzwischen verteilt sich das über das ganze System:
Das System ist leider schon älter.
Glück Auf
Tom vom Berg
In welcher Reihenfolge und in welchen Startdateien müssen die Komponenten
- iptables
- fail2ban
- ipset
Nur fail2ban
ist ein Dienst. ipset
ist eines der zahlreichen Steuerprogramme für iptables
. Alternativen sind firwallcmd
(a.k.a. firewalld
), wird z.B. von Red-Hat benutzt) oder ufw
(wird z.B. von Red-Hat benutzt)
iptables
ist genau genommen auch ein Steuerprogramm für die Kernelfirewall./etc/
gespeichert und bei einem Neustart wieder eingelesen werden, die stehen nämlich sonst nur im RAM.failtoban
ist also ein Dienst, der entsprechend gemachter Einstellungen Ausgaben aus Logfiles „abgreift“, mit regulären Ausdrücken untersucht und bei einer konfigurierbaren Anzahl von Treffern mittels iptables
, ufw
oder firewall-cmd
und/oder Geschwistern die Kernelfirewall mit Informationen über zu blockierenden Datenverkehr versorgt und sich merkt, wann er via der selben Befehlsfamilie der Kernelfirewall mitteilen soll, dass diese diesen Datenverkehr nicht mehr blockieren soll.
Das zu konfigurieren ist absolut kein Spaß, da muss viel abgestimmt werden - und in der Regel machen das die Maintainer der Pakete, also der Linux-Distributor. Dem Admin bleibt hier Feinarbeit.
Auch das Apache-Modul „recidive“ steuert in Abhängigkeit von gesetzten Regeln die Firewall und kann dazu iptables
, firewall-cmd
oder ufw
benutzen.
Das System ist leider schon älter.
Und an dieser Stelle geht es los. Die erste Frage wäre die, welches System das denn wohl sei. Du erwähnst nämlich unten etliche Ordner und Dateien (/etc/rc[1..6].d
, /etc/rc.local
), welche darauf hindeuten, dass der alte initd
benutzt wird, um die Dienste zu steuern.
Das ist aber anno 2023 und auch schon seit Jahren „eher selten“. Bei mir steht z.B. in /etc/rc.local:
By default this script does nothing.
Der „gute alte initd
“ aus „System V“ (einem Unix aus dem vorigen Jahrtausend) wurde nämlich aus vielen guten Gründen abgelöst und hier stellt sich im Hinblick auf Dein „Das System ist leider schon älter.“ die alles entscheidende Frage „Durch was?“. Es gab nämlich mehrere Kandidaten, die von verschiedenen Distributionen in verschiedenen Versionen benutzt wurden. Darüber hinaus aktivieren manche Systeme (Debian, Ubuntu, ...) installierte Dienste automatisch, andere (Red Hat und Co.) tun das nicht.
Was hast Du da also und gibt es einen Ordner /etc/systemd
?
Und was ist eigentlich Deine konkrete Frage?
Inzwischen verteilt sich das über das ganze System:
- /etc/profiles.d
- /etc/rc[1..6].d
- /etc/networks/interfaces
- /etc/rc.local
Ja. Das ist so (Es sind sehr viel mehr Dateien beteiligt!) und unter Windows nicht viel anders. Nur hast Du da eine besch... auf mehrere Dateien und den Arbeitsspeicher verteilte binäre Datenbank, in welche Du imaginäre „D-Worte“ eintragen und das System neu starten sollst, statt gut erläuterte und kommentierte Textdateien zu bearbeiten und dann einen Dienst neu zu starten oder ihm (z.B. via sudo systemctl $AKTION $DIENST
) zu sagen, er möge mal seine Config neu lesen.
Du erwähnst nämlich unten etliche Ordner und Dateien (
/etc/rc[1..6].d
,/etc/rc.local
), welche darauf hindeuten, dass der alte initd benutzt wird, um die Dienste zu steuern.
Diese Ordner sind (eigentlich) seit Jahren nur noch aus Gründen der Rückwärtskompatibilität vorhanden und werden kaum noch benutzt. Die Skripte (bzw. Links auf die Skripte) darin rufen regelmäßig systemctl
auf.
Hello,
Auch das Apache-Modul „recidive“ steuert in Abhängigkeit von gesetzten Regeln die Firewall und kann dazu
iptables
,firewall-cmd
oderufw
benutzen.
Gibt es das auch als Apache-Modul?
Ich habe hier eigentlich das Filter Recidive
für fail2ban
im Hirn gehabt. Und das arbeitet super.
Das System ist leider schon älter.
Ich werde die Nutzer auf diesem System erst zum Jahresende zum Umzug auf das neue(re) System drängen können.
Das ist aber anno 2023 und auch schon seit Jahren „eher selten“. Bei mir steht z.B. in /etc/rc.local:
By default this script does nothing.
Das ist bei mir nicht anders, aber für "schnelle Eingriffe" funktuiniert das noch.
Was hast Du da also und gibt es einen Ordner
/etc/systemd
?
Es gibt/etc/systemd/
, aber das Directory ist nahezu leer.
root@myhost:/etc# cd systemd
root@myhost:/etc/systemd# tree .
.
└── system
├── multi-user.target.wants
│ └── rsyslog.service -> /lib/systemd/system/rsyslog.service
├── sockets.target.wants
│ └── acpid.socket -> /lib/systemd/system/acpid.socket
└── syslog.service -> /lib/systemd/system/rsyslog.service
Ich würde diese Aufgaben gerne wieder delegieren. Leider ist unsere IT-Frau Anfang 2020 an einer schweren Lungenerkrankung (mans sagt "Pre-Corona") gestorben.
Mich selber hatte es ja schon Q3-2019 schwer erwischt, aber ich habe es überlebt.
Jetzt muss ich mich mit dem ganzen Sch... wieder selber beschäftigen, obwohl ich da seit ca. 2007 nur noch widerwillig reingucke.
Glück Auf
Tom vom Berg
Auch das Apache-Modul „recidive“ steuert in Abhängigkeit von gesetzten Regeln die Firewall und kann dazu
iptables
,firewall-cmd
oderufw
benutzen.Gibt es das auch als Apache-Modul?
Ich habe hier eigentlich das Filter
Recidive
fürfail2ban
im Hirn gehabt. Und das arbeitet super.
Ja. Aber da ist mir ein Fehler unterlaufen: recidive
heißt es in fail2ban das sehr viel direkter (ohne Umweg über Logfiles) arbeitende Apache-Modul heißt evasive
.
Und das arbeitet super.
Schwer das zu behaupten, weil mod_evasive
technisch bedingt sehr viel schneller reagieren kann.
root@myhost:/etc# cd systemd root@myhost:/etc/systemd# tree . . └── system ├── multi-user.target.wants │ └── rsyslog.service -> /lib/systemd/system/rsyslog.service ├── sockets.target.wants │ └── acpid.socket -> /lib/systemd/system/acpid.socket └── syslog.service -> /lib/systemd/system/rsyslog.service
Hm. Das sieht so aus, als wäre systemd vorhanden, würde aber nicht wirklich benutzt. Wer oder was macht sowas?
Zeig mal die Ausgabe von
lsb_release -a
oder, falls es den Befehl bei dieser Distribution nicht gibt,
cat $(ls /etc/*_version* 2> /dev/null) $(ls /etc/*_release* 2> /dev/null)
Zeig mal die Ausgabe von
lsb_release -a
oder, falls es den Befehl bei dieser Distribution nicht gibt,
cat $(ls /etc/*_version* 2> /dev/null) $(ls /etc/*_release* 2> /dev/null)
Hierauf wird wohl keine Antwort erfolgen. Die Erklärung dazu hat Tom ja schon mittels "Das System ist leider schon älter" implizit geliefert. Hauptsache fail2ban läuft toll. LOL.
Zeig mal die Ausgabe von
lsb_release -a
oder, falls es den Befehl bei dieser Distribution nicht gibt,
cat $(ls /etc/*_version* 2> /dev/null) $(ls /etc/*_release* 2> /dev/null)
Hierauf wird wohl keine Antwort erfolgen.
Sicher wolltest Du eigentlich notieren, dass Dir die Frage wichtig und zielführend erscheint. Es liegt in der Natur des Menschen, dass eine Person, die sich durch Sätze wie „Hauptsache fail2ban läuft toll.“ verständlicherweise persönlich angegriffen sieht, solche Fragen auch mal übersieht.
Ich selbst bin inzwischen bei der Frage angelangt, ob und welches „phantastische“ Verwaltungstool installiert ist. Grund: Diese erscheinen bequem, verändern Systeme manchmal ganz erheblich (Für mich: Bis zur Unbrauchbarkeit.) Vorliegend ist nicht nur Froxlor ein „Kandidat“:
Und ich mag nichts, aber auch gar nichts von diesen „phantastischen“ Tools.
Zeig mal die Ausgabe von
lsb_release -a
oder, falls es den Befehl bei dieser Distribution nicht gibt,
cat $(ls /etc/*_version* 2> /dev/null) $(ls /etc/*_release* 2> /dev/null)
Hierauf wird wohl keine Antwort erfolgen.
Sicher wolltest Du eigentlich notieren, dass Dir die Frage wichtig und zielführend erscheint.
Yep, die Frage ist relevant. Das weiß auch Tom und er wird die Frage deshalb geflissentlich ignorieren, weil er weiß, wie lächerlich der ganze Thread mit einer ehrlichen Antwort würde.
Darin hat Labertante mir vorgeworfen, ich hätte mehr Zeit auf die Paranoia bezüglich der unerlaubten Zugriffe auf den Rootserver, als auf die Datensicherung gelegt.
„Labertante“ hat Dich danach gefragt und Du hast die Fragestellung mit „vermutlich ja“ bestätigt.
Jetzt hängst Du Dich erneut an allerlei Zeugs wie fail2ban & Co auf…
Mensch, jetzt setz Dir endlich ein System auf, was im Fall der Fälle wieder möglichst schnell und mit möglichst wenig Datenverlust wieder online gebracht werden kann. Spiel das durch, teste es… Wechsel bei Bedarf den Provider, falls der doof ist…
Das ganze andere Zeugs ist nicht unwichtig, aber im Vergleich zum Failover komplett nachrangig.
Hello,
Darin hat Labertante mir vorgeworfen, ich hätte mehr Zeit auf die Paranoia bezüglich der unerlaubten Zugriffe auf den Rootserver, als auf die Datensicherung gelegt.
„Labertante“ hat Dich danach gefragt und Du hast die Fragestellung mit „vermutlich ja“ bestätigt.
Den Vorwurf als solchen habe ich auch nicht bemängelt.
Ich bemängele bei deinen Postings nur immer wieder, dass sie immer nur nörgeln, aber keine konkreten Verbesserungsvorschläge liefern.
Deshalb mein Eindruck von Dir: "Labertante".
Aber Du hast mir die Bezeichnung erlaubt, also weißt Du eigentlich von deinem Fehlverhalten.
Das kannst Du aber ändern und dann als "@Mitleser 2.01" auch Relevanzpunkte sammeln.
Das würde auch meinen Respekt vor Dir verbessern helfen.
Glück Auf
Tom vom Berg
Hello,
Das ganze andere Zeugs ist nicht unwichtig, aber im Vergleich zum Failover komplett nachrangig.
"Das ganze andere Zeugs" ist überhaupt das Wichtigste!
Ohne tiefere Kenntnisse darüber kann ich auch keinen neuen Provider und seine Fähigkeiten beurteilen. Aber das sollte Dir klar sein.
Ich frage hier deshalb selten nach Medizin zur Betäubung der Probleme, sondern meistens nach dem tieferen Verständnis für die Ursachen und Zusammenhänge.
Aber dein eben eingeschlagener Weg ist schon gut für ein Wissensforum. Gehe ihn weiter. Echte Tipps zum Thema, auch wenn sie nicht immer genau treffen, sind wichtiger, als Labergesülze zur Person der Poster.
Und den Medizin-Junkies, die Dir hier Pluspunkte vergeben für inhaltslose Angriffe auf mich, anstatt den fachlichen Erkenntnisgewinn deines Postings zu bewerten, kann ich nur sagen:
Sechs, setzen, Thema verfehlt!
Ich nehme derartige Angriffe schon lange nicht mehr ernst, aber sie bringen dieses Forum und den erhofften Erkenntnisgewinn nicht weiter. Versteht Ihr das gar nicht?
Glück Auf
Tom vom Berg
Das ganze andere Zeugs ist nicht unwichtig, aber im Vergleich zum Failover komplett nachrangig.
"Das ganze andere Zeugs" ist überhaupt das Wichtigste!
Deine Einschätzung.
Ohne tiefere Kenntnisse darüber kann ich auch keinen neuen Provider und seine Fähigkeiten beurteilen.
Wenn Du ein sauber konfiguriertes fail2ban für wichtiger erachtest als ein funktionales Backup: OK, Deine Einschätzung. Nebenbei: auch das Thema der Config DEINES fail2ban gehört in DEIN Backup.
Womöglich gefällt Dir Dein Provider in X Jahren ja nicht mehr und Du möchtest wechseln. Nur, wenn Du alles selbst beisammen hast, kannst Du das schmerzlos tun. Potentiell noch einfacher wird ein etwaiger Wechsel, indem Du DNS und Hosting trennst. Aber das sollte Dir ja klar sein, nicht wahr?
Aber das sollte Dir klar sein.
Wenn ich Deine Postings so lese, wird mir immer wieder so einiges klar.
Letztlich haben wir hier schlicht unterschiedliche Einschätzungen. Rakenwilli's Meinung hierzu würde mich durchaus interessieren. Andere selbstverständlich auch, aber er ist hier nun einmal offensichtlich der fitteste im Thema - zumindest derer, die sich hier auch äußern.
Ich frage hier deshalb selten nach Medizin zur Betäubung der Probleme, sondern meistens nach dem tieferen Verständnis für die Ursachen und Zusammenhänge.
Aber dein eben eingeschlagener Weg ist schon gut für ein Wissensforum. Gehe ihn weiter. Echte Tipps zum Thema, auch wenn sie nicht immer genau treffen, sind wichtiger, als Labergesülze zur Person der Poster.
Und den Medizin-Junkies, die Dir hier Pluspunkte vergeben für inhaltslose Angriffe auf mich, anstatt den fachlichen Erkenntnisgewinn deines Postings zu bewerten, kann ich nur sagen:
Sechs, setzen, Thema verfehlt!
Ich nehme derartige Angriffe schon lange nicht mehr ernst, aber sie bringen dieses Forum und den erhofften Erkenntnisgewinn nicht weiter. Versteht Ihr das gar nicht?
So schwurbelt er mal wieder daher, der Herr.
Letztlich haben wir hier schlicht unterschiedliche Einschätzungen. Rakenwilli's Meinung hierzu würde mich durchaus interessieren.
Etwa die zum Abgleiten der Diskussion? Oder die zum Serverwechsel?
Der angedachte Serverwechsel ist keine triviale Sache, will gut überlegt und geplant sein, Besonderheiten des Herkunftservers und des neuen Servers (da wird statt dem puren Linux oft tief ins System eingreifende und die bekannten Konfigurationswege zerstörendes, „phantastisches“ Zeug installiert) müssen bekannt sein, geprüft oder eruiert werden. Das ist keine 20-Minuten-Nummer.
Tom hat ja selbst geschrieben, dass er jemanden sucht, der sich darum kümmert. Ich kann das aber nicht ernsthaft anbieten, weil ich als Dozent, Trainer, Seminarleiter (oder wie auch immer ich gerade bezeichnet werde) teilweise wochenlang in Trainings oder Seminaren stecke und mir mein Urlaub ziemlich heilig ist, meine Response-Zeiten wären fürchterhafterlich volatil (was Spannungen voraussehen lässt) und ich bräuchte dann wohl auch eine Betriebshaftpflicht.
Was das Abgleiten der Diskussion betrifft bin ich selbst “nicht frei von Fehl und Tadel“, also kein Kandidat für bewertende Antworten, sehe es also so, dass jeder selbst wissen muss, ob er auf alles antworten will oder muss.
Letztlich haben wir hier schlicht unterschiedliche Einschätzungen. Rakenwilli's Meinung hierzu würde mich durchaus interessieren.
Etwa die zum Abgleiten der Diskussion? Oder die zum Serverwechsel?
Nee, ganz konkret am Punkt: Was ist Deiner Einschätzung nach wichtiger: Sauberes Backup oder "das andere Gedöns" wie z.B. fail2ban?
Letztlich haben wir hier schlicht unterschiedliche Einschätzungen. Rakenwilli's Meinung hierzu würde mich durchaus interessieren.
Etwa die zum Abgleiten der Diskussion? Oder die zum Serverwechsel?
Nee, ganz konkret am Punkt: Was ist Deiner Einschätzung nach wichtiger: Sauberes Backup oder "das andere Gedöns" wie z.B. fail2ban?
Wie Tom schrieb, gab es ja Backups. Die waren alsdann aber unvollständig. Ich will, kann (mangels objektiver Informationen) und werde also nicht darüber richten, ob das ein Fehler (in der Kommunikation) des Hosters oder von Tom bzw. dessen beauftragter Person ist.
Ich weiß nur: Das Kind ist im Wasser und muss raus.
Situativ betrachtet kann das eine oder das andere gerade wichtiger erscheinen.
Jetzt nur noch bitte einmal konkret am Beispiel fail2ban.
Warum zum Henker soll das gegenüber einem sauberem Backup Priorität haben können? Leuchtet mir als Halbwissendem im Thema inhaltlich nicht ein.
Situativ betrachtet kann das eine oder das andere gerade wichtiger erscheinen. Jetzt nur noch bitte einmal konkret am Beispiel fail2ban.
Was nützt das Backup, wenn sich ein Angreifer unbemerkt im System einnistet und ggf. Backups zerstört?
Freilich kannst Du noch Offline-Backus haben, die sind aber technisch zwingend immer etwas veraltet.
Situativ betrachtet kann das eine oder das andere gerade wichtiger erscheinen. Jetzt nur noch bitte einmal konkret am Beispiel fail2ban.
Was nützt das Backup, wenn sich ein Angreifer unbemerkt im System einnistet und ggf. Backups zerstört?
Jetzt verwirrst Du mich. Selbstverständlich liegen Backups stets außerhalb des vermeintlich kompromittierten Systems? Selbstverständlich werden Backups voll und inkrementell erzeugt?
Situativ betrachtet kann das eine oder das andere gerade wichtiger erscheinen. Jetzt nur noch bitte einmal konkret am Beispiel fail2ban.
Was nützt das Backup, wenn sich ein Angreifer unbemerkt im System einnistet und ggf. Backups zerstört?
Jetzt verwirrst Du mich. Selbstverständlich liegen Backups stets außerhalb des vermeintlich kompromittierten Systems? Selbstverständlich werden Backups voll und inkrementell erzeugt?
Dein „Selbstverständlich“ ist gar nicht mehr so „selbstverständlich“, wenn Du den Begriff des „Systems“ auf die Serverfarm (hier mindestens der eigentliche Datenserver und ein NAS mit den Backups) ausdehnst. Du kannst Zugangsdaten des Backupservers auf dem eigentlichen Server speichern (ich nenn das mal „aktives Backup“, weil dann der Datenserver die Daten sendet) oder auf dem Backupserver Zugangsdaten für den Datenserver (nenn ich „passives Backup“, weil der Backupserver dann die Daten z.B. via sshfs holt und dazu Berechtigungen - womöglich teilweise sogar zum Stoppen und Starten von Diensten - braucht). Beides eröffnet mindestens einen Angriffsvektor.
Wenn Du Vertraulichkeit, Verfügbarkeit und Integrität der Daten bzw. des Gesamtsystems sicher stellen musst kannst Du nicht einem Punkt (hier Verfügbarkeit durch Backups) einen derartigen Vorrang einräumen.
Selbstverständlich werden Backups voll und inkrementell erzeugt?
Die Begriffe „voll“ und „inkrementell“ sind hinsichtlich Backups auf modernen Betriebs- und Dateisystemen längst „verwischt“. Stichworte: zfs, btrfs, rsync.
Ich möchte gerne vom vermutlichen Profi jetzt mal lesen, warum fail2ban so prioritär relevant sein soll.
Meine Güte, wenn ich nen Server am Wickel hab, dann hinterleg ich meinen Key und deaktiviere das User/Secret-Auth und fertig erstmal.
Dann installier ich mein Zeug, mach dieses und jenes... Bestenfalls mache ich das alles nicht händisch, sondern automatisiert.
Jedes einzelne doofe Zeug, was ich dann so draufknalle, hat wiederum seine Pitfalls, jau.
Was ich aber zu aller, allererst im Blick hab: BACKUP BACKUP BACKUP.
Wenn ich dann auch noch meine, dass mich mod_evasive, fail2ban und was auch sonst noch für ein Gedöns weiterbringen: bitte gerne, hau rein.
Ich möchte gerne vom vermutlichen Profi
Und ich möchte diese Unterhaltung mit Dir nicht fortsetzen, weil mir Dein „Ton“ nicht gefällt.
Ich möchte gerne vom vermutlichen Profi
Und ich möchte diese Unterhaltung mit Dir nicht fortsetzen, weil mir Dein „Ton“ nicht gefällt.
Ich hätte auch Raketenwurst schreiben können, also nicht rumnölen, ja!
Das ganze andere Zeugs ist nicht unwichtig, aber im Vergleich zum Failover komplett nachrangig.
"Das ganze andere Zeugs" ist überhaupt das Wichtigste!
Ohne tiefere Kenntnisse darüber kann ich auch keinen neuen Provider und seine Fähigkeiten beurteilen. Aber das sollte Dir klar sein.
Du bist doch augenscheinlich schon als root auf Deinen Teilen unterwegs, richtig?
Dann bist Du für Dein System grundsätzlich erstmal selbst verantwortlich. Auch fürs Backup. Man bucht Storage dazu und gut ist. Hetzner z.B. bietet da super Hilfestellung zur Einrichtung.
Aber was wo und wie Du Dein Backup baust, ist letztlich Deine Verantwortung.
Genauso, wie die essentielle Kontrolle, zu checken, ob das Backup auch das liefert, was man erwartet.
Das muss man erstmal verinnerlichen, der ganze andere Technikkram kommt danach.