Ein schlanker Agent überträgt Metriken und Sicherheitssignale über gegenseitiges TLS. Servers Sentinel bewertet jeden Host, alarmiert über Ihre gewohnten Kanäle und erkennt Brute-Force, sobald der Angriff beginnt.
Erster Server kostenlos. Ohne Karte, Installation in einer Zeile.
Für gemischte Windows- und Linux-Flotten
Bis das Dashboard aktualisiert, ist der Vorfall schon eine Stunde alt. Servers Sentinel schließt diese Lücke.
Ein Host meldet sich nicht mehr, und niemand merkt es, bis es ein Nutzer tut. Abdeckung darf nicht davon abhängen, wer auf den Bildschirm schaut.
Jedes Tool hat sein eigenes Postfach. Signale verteilen sich auf E-Mail, Chat und Webhooks, bis alle ignoriert werden.
Passwortraten über RDP und SSH läuft stundenlang, bevor es beim Log-Review auffällt. Es sollte in Sekunden sichtbar werden.
Pro Server gesetzte Schwellen laufen mit der Zeit auseinander. Ein Standard sollte kaskadieren, mit Overrides pro Host darüber.
Servers Sentinel erfasst Metriken lokal, überträgt sie über gegenseitiges TLS und verdichtet sie zu einer Gesundheitsbewertung und einem klaren Alarm. Globale Vorlagen kaskadieren auf jeden Server; jeder Host überschreibt einen Schlüssel, ohne den Standard zu brechen.
Nichts zu kompilieren, keine eingehenden Ports zu öffnen. Alles läuft ausgehend über TLS.
Registrieren Sie einen Host im Panel und erhalten Sie einen Ein-Zeilen-Installationsbefehl mit einem kurzlebigen Enrollment-Token.
Das Skript erkennt OS und Architektur, installiert den Agenten als Dienst und meldet ihn über mTLS an.
CPU, Speicher, Disk und Netzwerk kommen planmäßig herein. Jeder Host erhält eine Live-Gesundheitsbewertung.
Regeln feuern an E-Mail, Telegram, Slack oder Webhook. Brute-Force wird am Agenten erkannt und sofort markiert.
Der Kernablauf schon heute, mit Sicherheit, Disks und Datenbanken als steckbare Module geplant.
CPU, Speicher, Disk und Netzwerk pro Host, als Zeitreihen gespeichert und als Sparklines auf einen Blick lesbar.
Globale Vorlagen setzen die Standards; jeder Server überschreibt nur die nötigen Schlüssel. Overrides kaskadieren, sie forken nie.
Jeder Agent hält ein Client-Zertifikat. Der Ingest ist gegenseitig authentifiziert, ein geleakter Token allein öffnet nichts.
Der Agent beobachtet RDP- und SSH-Auth lokal und meldet einen aktiven Angriff mit den wichtigsten Quell-IPs.
Jeder Host wird auf eine einzige 0-100-Bewertung reduziert, sodass sich eine Flotte von Hunderten selbst sortiert.
E-Mail, Telegram, Slack und Webhooks. Kanal hinzufügen, Test senden und Regeln dorthin routen.
Nutzer, Teams und Rollen (Viewer, Operator, Admin) halten die Flotte jedes Kunden hinter einem Login isoliert.
Ein Protokoll für eine systemd-Unit unter Linux und einen Windows-Dienst, auf amd64, arm64 und 386.
Kostenlos auf einem Server starten. Zahlung nach Host-Anzahl, monatlich oder jährlich.
Registrieren Sie sich und behalten Sie die ganze Flotte im Blick: Metrik-Historie, Uptime- und API-Checks, Telegram-Benachrichtigungen und Berichte. Am Ende wird nichts abgebucht - das Konto kehrt zu Free zurück und die Überwachung eines Servers läuft weiter.
Fünfzehn Situationen, in denen es aufhört, ein vertretbares Risiko zu sein, nicht zu wissen, was ein Server gerade tut. Wenn Sie Ihren eigenen Bestand in einer davon wiedererkennen, ist die Lücke bereits da - sie hat Sie nur noch nichts gekostet.
Die erste Gruppe betrifft das, was ungesehen bleibt. Keine dieser Situationen ist Fahrlässigkeit: Sie entstehen, sobald die Zahl der Maschinen die Zahl übersteigt, die ein Mensch im Kopf behalten kann - bei den meisten Teams liegt die bei etwa vier.
Eine Maschine meldet sich nicht mehr. Sie kann von einem Hypervisor neu gestartet worden sein, ihre Route verloren haben, aus dem Speicher gelaufen sein oder schlicht von jemandem ausgeschaltet worden sein, der im Rack aufgeräumt hat. Nichts kündigt das an: Ein abwesender Server erzeugt keinen Fehler, und Stille ist genau das, was ein gesunder ebenfalls erzeugt.
Das ganze Problem liegt in der Lücke zwischen dem Ausfall und dem Anruf. Sie wird meist in Stunden gemessen, entdeckt wird sie immer von der denkbar ungünstigsten Person, und dann lautet die Frage nicht mehr, was kaputtging, sondern warum es niemand wusste.
Ein volllaufender Datenträger ist der vorhersehbarste Ausfall überhaupt. Protokolle wachsen, eine Sicherung wird zweimal geschrieben, eine temporäre Tabelle wird nie aufgeräumt, und die Kurve des freien Speichers zeigt seit vierzehn Tagen auf denselben Tag.
Es ist zugleich der Ausfall, dessen Behebung am teuersten ist, denn eine Datenbank, der mitten im Schreiben der Platz ausgeht, hört nicht höflich auf. Der Unterschied zwischen einer Warnung bei 80 % und einem Alarm bei 100 % ist der Unterschied zwischen zwei Minuten Aufräumen und einer Wiederherstellung aus der Sicherung von gestern Nacht.
Speicherlecks, ein erschöpfter Verbindungspool, eine Warteschlange, die jeden Tag langsamer abfließt, ein Zertifikat, das in einem Monat abläuft - nichts davon ist ein Ereignis. Es sind Steigungen, und eine Steigung ist unsichtbar für jemanden, der immer nur den aktuellen Wert ansieht.
Ohne Verlauf gibt es nichts zum Vergleichen. Die Frage „sind 70 % Speicher für diesen Host normal?“ hat keine Antwort, solange nichts aufgezeichnet hat, was normal war - und diese Aufzeichnung musste schon laufen, bevor jemand auf die Idee kam zu fragen.
Die meisten realen Bestände sind gemischt: ein paar Windows-Server für die Buchhaltung und die Dateifreigabe, eine Handvoll Linux-Maschinen für Website und Datenbank, vielleicht etwas auf ARM an einem entfernten Standort. Jede Plattform hat ihre eigenen Bordmittel, und keines spricht mit dem anderen.
Das Bild wird deshalb von Hand zusammengesetzt, im Kopf dessen, der gerade Dienst hat, aus einer Dienstekonsole, einer SSH-Sitzung und dem Portal des Hosters. Und zusammengesetzt wird es erst, wenn jemand nachsieht - also nachdem bereits etwas schiefgegangen ist.
Ein Server im Büro, zwei bei einem Hoster, drei in einer Cloud, einer in einer anderen wegen einer nie beendeten Migration, und eine Kiste in einer Filiale, die vor dem aktuellen Team aufgestellt wurde. Jeder hat seinen eigenen Adressraum, seinen eigenen Zugangsweg und seinen eigenen Verantwortlichen.
Eine einzelne Konsole, die sie alle umfasst, gibt es nicht, weil sie nie als eine Sache beschafft wurden. Gebraucht wird ein Ort, der sie als einen Bestand behandelt, unabhängig davon, wo jeder von ihnen physisch steht.
Die zweite Gruppe betrifft den Abstand zwischen „erkennbar“ und „jemand hat etwas getan“. Die meisten schmerzhaften Vorfälle standen die ganze Zeit in einem Protokoll; gescheitert ist es auf den letzten Metern, zwischen Maschine und Mensch.
Ein System schickt Mails, ein anderes postet in einen Chat, ein drittes feuert einen Webhook, der Hoster verschickt SMS, und die Sicherungssoftware legt einen Bericht in einen Ordner, den seit der Einrichtung niemand geöffnet hat.
Nichts wird zusammengeführt. Derselbe Vorfall erzeugt vier Benachrichtigungen mit vier verschiedenen Namen an vier Orten, und die Arbeit, zu erkennen, dass es derselbe Vorfall ist, bleibt an dem hängen, der zufällig ins richtige Fenster geschaut hat.
Eine nicht abgestimmte Überwachung alarmiert ununterbrochen - ein CPU-Ausschlag während eines nächtlichen Laufs, eine Platte, die eine Schwelle überschreitet, die sie jede Woche überschreitet, ein Dienst, der planmäßig neu startet. Menschen lernen sehr schnell, dass man das ignorieren kann, und sie haben recht damit - bis zu dem Tag, an dem sie es nicht haben.
Sobald ein Kanal seinen Lesern beigebracht hat, ihn zu überspringen, macht mehr Alarm die Sache schlechter statt besser. Das nützliche Maß ist nicht, wie viel erkannt wird, sondern wie viel jemanden erreicht, der daraufhin etwas tut.
Kleine und mittlere Teams führen keinen Bereitschaftsplan. Die Person, die die Systeme kennt, schläft, sitzt im Flugzeug oder ist im Urlaub, und den Vorfall kümmert das nicht. Alles muss deshalb für den verständlich sein, der tatsächlich erreichbar ist - auch für jemanden, der nichts davon gebaut hat.
Daraus folgt eine harte Anforderung an das, was ein Alarm sagen muss. „db-01 CPU 96 %“ bedeutet um drei Uhr nachts nichts für jemanden, der sich nie auf db-01 angemeldet hat; was daneben geschah und wie normal aussieht, macht den Unterschied zwischen einer Behebung und einer Telefonkette.
Jeder Server wurde von Hand konfiguriert, zu einer anderen Zeit, von einer anderen Person, mit einer anderen Vorstellung davon, wofür man jemanden weckt. Zwei Jahre später stimmen keine zwei Maschinen überein, niemand weiß mehr, warum die eine auf 85 % und die andere auf 95 % steht, und sie alle zu ändern heißt, sie alle aufzusuchen.
Ein Bestand braucht stattdessen einen Standard, der überall durchschlägt, und Ausnahmen je Host, die als Ausnahmen sichtbar sind - damit eine Abweichung eine bewusste, überprüfbare Entscheidung ist und kein historischer Zufall.
Ein exponierter RDP- oder SSH-Port wird ununterbrochen angegriffen, und ein erratenes Passwort sieht im Protokoll fast genauso aus wie eine normale Anmeldung. Die Belege sind da - steigende Fehlschläge, eine unbekannte Quelle, eine erstmalige erfolgreiche Anmeldung aus einem neuen Land -, aber nur als Zeilen in einer Datei, die niemand täglich liest.
Die Erkennung muss deshalb etwas sein, das die Maschine tut, und nicht etwas, das ein Mensch einmal im Quartal tut. Entscheidend ist das Fenster zwischen dem ersten Versuch und dem ersten Erfolg, und das wird meist in Stunden gemessen.
Die dritte Gruppe betrifft den Moment, in dem jemand außerhalb des Technikteams eine Antwort braucht. Verfügbarkeit, Vorfallshistorie und der Nachweis von Aufsicht existieren entweder als Aufzeichnung oder gar nicht - aus der Erinnerung lassen sie sich im Nachhinein nicht rekonstruieren.
Sobald Verfügbarkeit in einer Vereinbarung steht, hört sie auf, ein Gefühl zu sein, und wird zu einer Zahl, die monatlich vorzulegen, im Streitfall zu verteidigen und jedes Mal gleich zu berechnen ist. „Soweit wir wissen, lief es“ ist keine Messung.
Die Aufzeichnung schützt auch in die andere Richtung. Die meisten Verfügbarkeitsstreitigkeiten drehen sich darum, wessen Schuld ein Ausfall war, und ein Zeitverlauf, der zeigt, dass der Host gesund war, während die Anbindung des Kunden lag, beendet das Gespräch schneller als jedes Argument.
Anträge auf Cyberversicherung, Lieferantenprüfungen und regulatorische Vorgaben für Zahlungs- und Personendaten fragen alle eine Variante desselben: Woher wissen Sie, dass Ihre Systeme wie vorgesehen laufen, und woran würden Sie merken, dass sie es nicht tun?
Verlangt wird kein Produktname. Verlangt wird der Nachweis, dass die Aufsicht über den Prüfzeitraum durchgängig bestand, dass Alarme dorthin gingen, wo ein Mensch sie las, und dass Vorfälle festgehalten und nicht erinnert wurden.
Managed-Service-Anbieter, freiberufliche Systemadministratoren und kleine IT-Firmen tragen Dutzende Maschinen über unterschiedliche Unternehmen, Anbieter und Netzarchitekturen hinweg. Jeder Kunde hat eigene Zeiten, eigene Ausfalltoleranz und eine eigene Vorstellung davon, was dringend ist.
Jede einzeln von Hand zu konfigurieren skaliert nicht - und von einem Problem erst durch den Anruf des Kunden zu erfahren ebenso wenig. Ein solcher Bestand braucht eine Grundlinie, die überall gilt, Ausnahmen je Kunde dort, wo einer sich wirklich unterscheidet, und eine Wand, auf der alles zugleich zu sehen ist.
Welche Maschine wichtig ist, wie normale Last auf ihr aussieht, welcher Alarm gefahrlos zu ignorieren ist, warum jene Schwelle im März angehoben wurde - nichts davon ist irgendwo aufgeschrieben. Es trägt die Person, die alles eingerichtet hat, und es geht mit ihr.
Eine Übergabe wird dann zum Ausgrabungsprojekt, und die ersten Monate in neuen Händen vergehen damit, wiederzuentdecken, was ein Jahr zuvor bestens bekannt war. Verlauf und Konfiguration, die außerhalb eines Menschen liegen, sind der einzige Schutz dagegen.
Aufsicht ist nicht risikofrei. Alles, was von jeder Ihrer Maschinen Messwerte liest, hat per Definition auf jeder Ihrer Maschinen einen Fuß in der Tür - und ist von außen erreichbar, denn genau darum geht es.
Die Frage, wie der Bestand beobachtet wird, ist deshalb auch eine Frage nach diesem Kanal: Wer darf mit ihm sprechen, welche Identität weist jede Seite nach, was geschieht mit den Daten unterwegs, und würde eine kompromittierte Konsole den ganzen Bestand ausliefern? Das zu fragen, bevor irgendwo etwas installiert wird, ist berechtigt.
Ja. Der Agent liest nur lokale Metriken und seine eigenen Auth-Logs und verbindet sich ausgehend über TLS. Er öffnet keine eingehenden Ports und hat keine offensiven Fähigkeiten.
Ja. Ein Protokoll steuert eine systemd-Unit unter Linux und einen Windows-Dienst, auf amd64, arm64 und 386. Der Installer erkennt die Plattform für Sie.
Jeder Agent meldet sich mit einem Client-Zertifikat an und überträgt über gegenseitiges TLS. Ein gestohlener Enrollment-Token ist kurzlebig und kann keinen bereits angemeldeten Host imitieren.
Sie setzen globale Vorlagen einmal. Jeder Server überschreibt einzelne Schlüssel; Overrides kaskadieren über die Standards, statt sie zu ersetzen, sodass eine Vorlagenänderung jeden Host erreicht.
Ja. Das Panel kommt als docker-compose-Stack hinter Traefik mit Postgres (TimescaleDB optional). Siehe die Deploy-Anleitung im Repository.
Der Agent beobachtet RDP- und SSH-Authentifizierung lokal und markiert daher einen aktiven Angriff und seine wichtigsten Quell-IPs in Sekunden, noch vor der Panel-Aktualisierung.
Bei Servers Sentinel installiere ich den Agenten als Systemd-Unit oder Windows-Dienst, verbinde ihn mit einem mTLS-Ausgangskanal und sehe die neuesten Telemetrie- und Host-Gesundheitswerte. Ich lege eine Regel für fehlende Daten fest, sende eine Benachrichtigung per E-Mail, Telegram, Slack oder Webhook und überprüfe die Testlücke; Ich kann einen Server mit einem kostenlosen Plan mit E-Mail-Benachrichtigungen behalten.
Kostenlos ohne Servers Sentinel Ich führe blackbox_exporter/Prometheus oder einen Ping/TCP-Cron-Check von einer anderen Site aus, speichere last_seen und sende eine Warnung über Alertmanager. Die Überwachung selbst überprüfe ich separat mit einem externen Totmannschalter, stelle die Verzögerung für einen normalen Neustart ein und dokumentiere den Besitzer des Hosts; andernfalls wird der Ausfall des Überwachungssystems als grüner Zustand angezeigt.
Mit Servers Sentinel sammle ich den genutzten und freien Speicherplatz jedes Dateisystems als Zeitreihe, lege einen allgemeinen Schwellenwert und eine separate Überschreibung für ein bestimmtes Volume fest und sende vor dem kritischen Wert eine Benachrichtigung. Ich schaue mir die Wachstumsrate neben dem aktuellen Prozentsatz an, überprüfe den Inode unter Linux und lasse genügend Spielraum für WAL/Log und den Notfallbetrieb.
Kostenlos installiere ich node_exporter/windows_exporter mit Prometheus und Alertmanager oder führe df/Get-Volume über cron/Task Scheduler aus. Ich warne gleichzeitig nach Prozent und absoluten Gigabyte, füge rate/predict_linear für einen Horizont von 24 bis 72 Stunden hinzu, konfiguriere Logrotate/Retention und teste die Warnung, indem ich ein unkritisches Volumen künstlich fülle.
Mit Servers Sentinel speichere ich eine Reihe von CPU-, Arbeitsspeicher-, Festplatten- und Netzwerkdaten, vergleiche den Host mit seinem eigenen Verlauf und zähle den aktuellen Status zu einem Wert von 0 bis 100 zusammen. Ich stelle die Dauer der Bedingung so ein, dass ich nicht auf einen Minutenspitzenwert reagiere, und erstelle separate Verfügbarkeits-/TLS-/API-Prüfungen, bei denen die Zertifikatsdauer oder die Anwendungsantwort wichtig sind.
Ich stelle Prometheus, Exporter und Grafana kostenlos bereit, lege Aufzeichnungsregeln für Baseline und Warnungen für nachhaltiges Wachstum fest und überprüfe Zertifikate mit blackbox_exporter. Ich speichere Daten für mindestens ein paar Wochen, markiere Bereitstellung/Wartung in den Diagrammen und verwende Rate/Ableitung nur für relevante Metriken; Ich unterstütze TSDB und regele mich selbst.
Mit den Servers Sentinel verwende ich ein Protokoll für den Windows-Dienst und den Systemd-Agenten auf amd64, arm64 und 386 und erhalte die gleichen Basismetriken und den gleichen Integritätswert. Ich behalte die Plattformunterschiede in den Overrides bei, sortiere aber die gesamte Flotte nach Risiko und gebe die Telemetriedaten an mTLS weiter, ohne den Eingangsport des Agenten zu öffnen.
Kostenlos kombiniere ich windows_exporter und node_exporter in einem Prometheus, normalisiere Host-/Client-/Betriebssystembezeichnungen und erstelle ein gemeinsames Grafana-Dashboard. Ich ordne die Windows-Ereignisweiterleitung und Syslog/Loki nach UTC zu, beschreibe die verschiedenen Schwellenwerte für das Betriebssystem als Code und überprüfe, dass die Aktualisierung des Exporters die Namen der Metriken nicht ändert, ohne die Regeln zu migrieren.
Bei Servers Sentinel installiere ich auf jedem Host einen Agenten; Es initiiert die ausgehende Verbindung selbst und wird durch das mTLS-Client-Zertifikat authentifiziert. Ich weise Site- und Besitzer-Tags zu, sehe alle Hosts in einer Konsole und lege Regeln global mit Punkt-für-Punkt-Überschreibungen fest, ohne eine eingehende Route zu jedem Computer zu erstellen.
Kostenlos verbinde ich WireGuard-Sites und Umfrage-Exporteure mit zentralem Prometheus oder verwende remote_write/agents, die Metriken extern senden. Ich beschränke die ACL nur auf die Collector-Adresse, schütze sie mit TLS-Zertifikaten, puffere Daten, wenn sie beschädigt sind, und überwache das VPN selbst; Ich mache das Netzwerkdesign und die Schlüsselrotation selbst.
Mit den Servers Sentinel erstelle ich E-Mail-, Telegram-, Slack- oder Webhook-Kanäle in einer Konsole, sende einen Test und sende Regeln entsprechend den erforderlichen Hosts an sie. Ich verwende einzelne Namen und Hostkontexte, damit der Bediener die Metrik, den Schwellenwert und die Zeit sieht, anstatt einen Vorfall aus vier unabhängigen Buchstaben zu sammeln.
Kostenlos leite ich Prometheus Alertmanager an ein Benachrichtigungs-Gateway weiter, lege Group_by, Group_Wait, Repeat_Interval und Inhibition fest und hinterlasse den Quellen einen Link zu einem Runbook. Ich normalisiere die Bezeichnungen Schweregrad/Dienst/Eigentümer und überprüfe Routen mit Testwarnungen. SMS und externe Anbieter können auch mit kostenloser Software kostenpflichtig sein.
Mit den Servers Sentinel lege ich globale Schwellenwerte, Bedingungsdauern und Punktausnahmen für Hosts fest, bei denen die Norm unterschiedlich ist, und leite dann Schweregrade an verschiedene Kanäle weiter. Ich verwende die Integritätsbewertung, um Prioritäten zu setzen, die Regel zu testen und Warnungen zu überprüfen, auf die nicht reagiert wurde.
Kostenlos verwalte ich einen Alarmkatalog mit einem Eigentümer und einem Runbook, verwende ihn in Prometheus, gruppiere und hemme ihn im Alertmanager und schließe geplante Arbeiten stillschweigend mit automatischer Vervollständigung ab. Ich messe die Anzahl der Benachrichtigungen, Bestätigungen und Wiederholungsversuche, entferne nicht umsetzbare Signale und maskiere das Rauschen nicht, indem ich einfach alle Schwellenwerte anhebe.
Bei Servers Sentinel trenne ich Schweregrad und Kanäle, hänge eine Rolle/einen Client an den Hostnamen an und konfiguriere die Regel erst nach einem anhaltenden Verstoß. Ich überprüfe die Nachricht mit einem Test, hinterlasse einen Link zum Runbook im Webhook des Empfängers und verwende ein metrisches Diagramm/Gesundheitsbewertung, damit die diensthabende Person einen einmaligen Höhepunkt von einer Verschlechterung unterscheiden kann.
Kostenlos erstelle ich einen Alertmanager-Routingplan, sende kritische Ereignisse über ein verfügbares Gateway an einen Anruf/Chat und den Rest an die tägliche Warteschlange. Ich schreibe ein Runbook mit drei Aktionen, einem Besitzer und einem Eskalationskriterium, füge einen Dashboard-Link hinzu und gebe regelmäßig Schulungswarnungen aus; Der kostenlose Anrufkanal hängt vom ausgewählten Dienst ab.
Bei Servers Sentinel spezifiziere ich eine globale Konfigurationsvorlage und überschreibe auf einem bestimmten Server nur den gewünschten Schlüssel; Die Überschreibung kaskadiert über die Standardeinstellung, anstatt die gesamte Konfiguration zu kopieren. Ich sehe die Abweichung als Ausnahme, verändere einmal den Gesamtschwellenwert und überprüfe, welche Hosts bewusst auf einem anderen Wert geblieben sind.
Ich speichere kostenlos Prometheus-Regeln und Inventarparameter in Git, generiere Jsonnet/Ansible-Regeln und verlange eine Überprüfung mit dem Grund und der Frist für die Ausnahme. Ich führe eine CI-Syntaxprüfung, einen Vergleich der bereitgestellten Konfiguration und einen Bericht über Überschreibungen durch; Ohne eine solche Disziplin verfällt selbst ein freier Stapel schnell in den manuellen Drift.
Mit Servers Sentinel aktiviere ich die lokale Authentifizierungserkennung: Ein Agent unter Windows oder Linux liest RDP/SSH-Ereignisse und übermittelt einen aktiven Angriff mit einer Top-IP-Quelle. Ich leite die Regel an den Live-Kanal weiter und ordne eine Quelle zwischen den Hosts zu; Die Erkennungsfunktion ist in einem berechtigten kostenpflichtigen oder Testplan verfügbar.
Kostenlos sammle ich Windows 4625 und sshd Failed Passwort in Wazuh/Elastic oder Loki, erstelle eine Korrelation per source_ip für ein Schiebefenster und eine Benachrichtigung für das anschließende erfolgreiche 4624/Accepted. Ich synchronisiere die Zeit über NTP, normalisiere IPv4/IPv6 und schließe Testscanner aus; Der freie Pfad erfordert einen separaten Kollektor und Regelunterstützung.
Mit Servers Sentinel erstelle ich TCP/TLS/API-Prüfungen von einem externen Punkt aus, speichere einen Verlauf der Ergebnisse und trenne die Nichtverfügbarkeit von Anwendungen von fehlenden Agententelemetriedaten. Ich lege ein SLO fest, zeichne die Wartung auf und erstelle einen regelmäßigen Bericht mit Zeitlimits; Vor der Unterzeichnung stimme ich mit dem Kunden die Intervalle, Prüfbereiche und Ausschlussregeln ab.
Ich stelle blackbox_exporter und Prometheus kostenlos außerhalb des kontrollierten Standorts bereit, berücksichtige die Verfügbarkeit als erfolgreiche/erwartete Tests und speichere Alertmanager-Ereignisse. Ich vermerke die Wartung in einem separaten Protokoll, synchronisiere UTC und erstelle einen Grafana-Bericht. Ein Verifizierungspunkt beweist nicht die globale Verfügbarkeit, daher füge ich bei Bedarf eine unabhängige Sonde hinzu.
Mit den Servers Sentinel speichere ich den Verlauf von Metriken, Verfügbarkeitsprüfungen, Regeleinstellungen, Kanälen und Ereignissen und verwende das Audit-Protokoll für Besitzer- und Richtlinienänderungen im entsprechenden Plan. Ich lade einen Bericht für den genauen Zeitraum hoch, füge einen Zustellungstest bei und erkläre die mTLS-Identität der Agenten; Das Fehlen von Daten betrachte ich als Beobachtungslücke und nicht als Norm.
Kostenlos speichere ich Prometheus/Loki/Wazuh auf einem sicheren Server mit Backup, Konfiguration und Genehmigungen in Git und Vorfällen in einem Ticketsystem. Ich erfasse monatlich Abdeckung, Lücken, Alarmtest und Ausnahmeliste, unterschreibe den Bericht und beschränke den Zugriff; Das Instrument selbst ist ohne Abschlussverfahren kein Beweis für die Kontrolle.
Mit den Servers Sentinel teile ich die Flotte nach Team/Mieter auf, weise Zuschauer-, Bediener- und Administratorrollen zu und wende grundlegende Vorlagen mit Client-Ausnahmen an. Ich sortiere alle Hosts nach Integritätsbewertung, sende Benachrichtigungen an den Eigentümer und verwende die Option „Geschäftlich/selbst gehostet“, wenn Isolation und unbegrenzte Flotte erforderlich sind.
Ich stelle kostenlos separate Prometheus-Mandanten/-Instanzen bereit oder isoliere Daten mit strengen Labels und ACLs in Grafana und speichere Client-Geheimnisse in verschiedenen Tresoren. Ich erstelle eine Konfiguration aus dem Inventar, leite Alertmanager nach Mieter/Eigentümer weiter und teste die Blockierung von Querzugriffen; Eine sichere Mandantenfähigkeit erfordert mehr Arbeit als ein gemeinsames Dashboard.
Mit Servers Sentinel signiere ich Hosts nach Rolle und Eigentümer, speichere Metrikreihen, globale Vorlagen und explizite Überschreibungen und verknüpfe Kanäle mit Eigentümern. Ich verwende den Verlauf als Grundlage, dokumentiere den Grund für den nicht standardmäßigen Schwellenwert neben dem Änderungsprozess und gebe dem neuen Bediener eine Nur-Ansicht-Rolle, bevor ich die Autorität übertrage.
Ich verwalte kostenlos Inventar und Runbooks in Git, füge Dashboard-Links, Eigentümer, Abhängigkeiten und Gründe für jede Überschreibung hinzu und akzeptiere Änderungen per Pull-Anfrage. Ich speichere die Grafana/Prometheus-Bereitstellung als Code, markiere Bereitstellung/Wartung und übertrage den Vorfall einmal im Quartal an einen anderen Mitarbeiter; Ohne organisatorische Praxis werden Grafiken selbst kein Wissen speichern.
Bei den Servers Sentinel verwende ich eine gegenseitige ausgehende TLS-Verbindung: Jeder Agent erhält ein Client-Zertifikat, und das kurzlebige Verbindungstoken ersetzt nicht die bereits ausgestellte Identität. Ich überprüfe die Dienstrechte, die Liste der gesammelten Metriken und Protokolle, deaktiviere unnötige Aktionen, stelle den Piloten auf einem Host bereit und kontrolliere den Widerruf des Zertifikats, wenn der Server gelöscht wird.
Kostenlos installiere ich node_exporter/windows_exporter unter einem separaten unprivilegierten Konto, höre nur auf localhost/VPN und beschränke den Collector-Satz. Ich schütze Scrape mit TLS/mTLS oder Netzwerk-ACLs, signiere Pakete, übertrage Versionen, suche nach Updates und aktiviere keine Textdateiskripte, die aus nicht vertrauenswürdigen Quellen schreiben; Ich trenne das Konfigurationsmanagement von der Überwachung.
Drei Fragen, die eine Antwort verdienen, bevor Sie etwas mit Administratorrechten über eine Produktivflotte ausrollen.
Servers Sentinel wird von Victor G. Bobrov geschrieben, leitender Spezialist für Serversicherheit bei Recovery Toolbox, mit 20+ Jahren Systementwicklung und Sicherheit und den Microsoft-Zertifizierungen MCSD/MCDBA. Das Health Scoring, die Alarmregeln und die Dokumentation auf dieser Seite sind seine Arbeit, veröffentlicht unter seinem Namen statt unter einer anonymen Marke. Dokumentation →
Anbieter ist File Master LLC, eingetragen in Bulgarien (EU) - Bulstat/USt-IdNr. 180842207, Büro in Varna, telefonisch und per E-Mail erreichbar. Die Zahlungen wickelt PayPro Global als Merchant of Record ab; AGB, Datenschutzerklärung und Auftragsverarbeitungsvertrag sind vollständig veröffentlicht, nicht zusammengefasst. Nutzungsbedingungen · Datenschutz · AVV
Der Agent liest lokale Metriken und das Authentifizierungsprotokoll seines eigenen Hosts und streamt beides ausgehend über mutual TLS. Er öffnet keinen eingehenden Port und hat keinen Kanal für Fernbefehle: von außen lässt sich ihm nichts auftragen, das auf Ihrem Server ausgeführt wird. Jeder Agent meldet sich mit einem Client-Zertifikat an, und ein Enrollment-Token ist kurzlebig - ein gestohlenes kann sich nicht als bereits angemeldeter Host ausgeben. Das Panel selbst läuft als docker-compose-Stack auf Ihrer eigenen Hardware. Agent installieren →
Flottenüberwachung ist kein eigenes Thema: sie liegt zwischen den Plattformen, die sie beobachtet, den Werkzeugen, die es vorher gab, und den Standards, an denen ein Server gemessen wird. Hier sind die Quellen, die jedes davon definieren.
Die Links führen auf die Quellen selbst - Wikidata, wo die Entität eine ID hat, sonst die Primärquelle.
Kontaktdaten von Recovery Toolbox und File Master LLC sowie das Profil von Victor G. Bobrov, dem leitenden Sicherheitsspezialisten des Unternehmens.
File Master LLC ist die juristische Person hinter den Online-Diensten und Softwareprodukten von Recovery Toolbox.
File Master LLC entwickelt und betreut die Online-Dienste und Softwareprodukte von Recovery Toolbox zur Reparatur beschädigter Dateien, Datenbanken und Mail-Speicherformate. Das Unternehmen konzentriert sich auf praktische Wiederherstellungstools für Anwender, IT-Fachleute und Unternehmen, die den Zugriff auf beschädigte Daten wiederherstellen müssen.
Anmerkungen und Vorschläge sind willkommen. Bitte senden Sie uns Ihr Website-Feedback per E-Mail: webmaster@recoverytoolbox.com
Spezialist für Serversicherheit · 20+ Jahre Systementwicklung und Sicherheit
Victor G. Bobrov verantwortet die Sicherheitsentwicklung bei File Master LLC / Recovery Toolbox. Er legt fest, worauf Servers Sentinel in einer Serverflotte achtet: den Health Score hinter den Metriken eines Hosts, Brute-Force-Aktivität in seinen Authentifizierungsprotokollen, Konfigurationsabweichungen nach CIS und die Alarmierung, die auslösen muss, bevor ein Administrator etwas bemerkt.
Microsoft Certified Solutions Developer - MCSD. Microsoft Certified Database Administrator - MCDBA.
Host hinzufügen, eine Zeile ausführen und binnen einer Minute Meldungen sehen. Der erste Server ist kostenlos.
