Un agent léger transmet métriques et signaux de sécurité via TLS mutuel. Servers Sentinel note chaque hôte, alerte sur vos canaux habituels et signale les attaques par force brute dès qu'elles commencent.
Premier serveur gratuit. Sans carte, installation en une ligne.
Pensé pour les parcs mixtes Windows et Linux
Le temps que le tableau de bord se rafraîchisse, l'incident a déjà une heure. Servers Sentinel comble cet écart.
Un hôte cesse de remonter et personne ne le remarque avant un utilisateur. La couverture ne doit pas dépendre de qui regarde l'écran.
Chaque outil a sa propre boîte. Les signaux se dispersent entre e-mail, chat et webhooks jusqu'à être tous ignorés.
Le devinage de mots de passe RDP et SSH tourne des heures avant d'apparaître à la revue des journaux. Il devrait remonter en secondes.
Des seuils réglés par serveur se désynchronisent avec le temps. Un défaut devrait cascader, avec des surcharges par hôte au-dessus.
Servers Sentinel collecte les métriques localement, les transmet via TLS mutuel et les condense en une note de santé et une alerte claire. Les modèles globaux cascadent vers chaque serveur ; tout hôte surcharge une clé sans casser le défaut.
Rien à compiler, aucun port entrant à ouvrir. Tout part en sortant via TLS.
Enregistrez un hôte dans le panneau et obtenez une commande d'installation en une ligne avec un jeton d'enrôlement éphémère.
Le script détecte l'OS et l'architecture, installe l'agent en service et l'enrôle via mTLS.
CPU, mémoire, disque et réseau arrivent selon un rythme. Chaque hôte reçoit une note de santé en direct.
Les règles déclenchent vers e-mail, Telegram, Slack ou webhook. La force brute est détectée sur l'agent et signalée aussitôt.
La boucle centrale dès aujourd'hui, avec sécurité, disques et bases pensés comme modules enfichables.
CPU, mémoire, disque et réseau par hôte, stockés en séries temporelles et tracés en sparklines lisibles d'un coup d'œil.
Les modèles globaux fixent les défauts ; chaque serveur ne surcharge que les clés utiles. Les surcharges cascadent, elles ne bifurquent jamais.
Chaque agent détient un certificat client. L'ingestion est mutuellement authentifiée : un jeton fuité seul n'ouvre rien.
L'agent surveille l'auth RDP et SSH localement et signale une attaque active avec les principales IP sources.
Chaque hôte est réduit à une seule note 0-100, si bien qu'un parc de centaines se trie de lui-même.
E-mail, Telegram, Slack et webhooks. Ajoutez un canal, envoyez un test et routez-y des règles.
Utilisateurs, équipes et rôles (lecteur, opérateur, admin) isolent le parc de chaque client derrière un seul accès.
Un protocole pour une unité systemd sous Linux et un service Windows, sur amd64, arm64 et 386.
Démarrez gratuitement sur un serveur. Payez au nombre d'hôtes, au mois ou à l'année.
Inscrivez-vous et surveillez tout votre parc : historique des métriques, contrôles de disponibilité et d'API, alertes Telegram et rapports. À la fin, rien n'est prélevé - le compte revient à Free et la surveillance d'un serveur continue.
Quinze situations dans lesquelles ne pas savoir ce que fait un serveur cesse d'être un risque acceptable. Si vous reconnaissez votre propre parc dans l'une d'elles, la faille est déjà là - elle ne vous a simplement encore rien coûté.
Le premier groupe porte sur ce qui passe inaperçu. Aucune de ces situations ne relève de la négligence : elles apparaissent dès que le nombre de machines dépasse celui qu'une personne peut garder en tête, soit environ quatre pour la plupart des équipes.
Une machine cesse de répondre. Elle a pu être redémarrée par un hyperviseur, perdre sa route, manquer de mémoire, ou simplement être éteinte par quelqu'un qui rangeait une baie. Rien ne l'annonce : un serveur absent ne produit aucune erreur, et le silence est exactement ce que produit aussi un serveur en bonne santé.
Tout le problème tient dans l'écart entre la panne et l'appel. Il se mesure en heures, il est toujours découvert par la personne la moins bien placée, et à ce moment-là la question n'est plus ce qui a cassé, mais pourquoi personne ne le savait.
La saturation d'un disque est la panne la plus prévisible qui soit. Les journaux grossissent, une sauvegarde est écrite deux fois, une table temporaire n'est jamais nettoyée, et la courbe d'espace libre pointe depuis quinze jours sur le même jour.
C'est aussi la panne dont la réparation coûte le plus cher, car une base de données à court d'espace en pleine écriture ne s'arrête pas poliment. La différence entre une alerte à 80 % et une astreinte à 100 %, c'est la différence entre deux minutes de ménage et une restauration depuis la sauvegarde d'hier soir.
Fuites de mémoire, épuisement d'un pool de connexions, file d'attente qui se vide un peu plus lentement chaque jour, certificat à un mois de l'expiration : rien de tout cela n'est un événement. Ce sont des pentes, et une pente est invisible pour qui ne regarde jamais que la valeur du moment.
Sans historique, il n'y a rien à quoi comparer. « 70 % de mémoire, est-ce normal pour cet hôte ? » n'a pas de réponse si rien n'a enregistré ce qu'était la normale - et cet enregistrement devait déjà tourner avant que quiconque songe à poser la question.
La plupart des parcs réels sont mixtes : deux ou trois serveurs Windows pour la comptabilité et le partage de fichiers, une poignée de machines Linux pour le site et la base, peut-être quelque chose en ARM sur un site distant. Chaque plateforme a ses propres outils natifs, et aucun ne parle aux autres.
Le tableau est donc assemblé à la main, dans la tête de celui qui est d'astreinte, à partir d'une console de services, d'une session SSH et du panneau de l'hébergeur. Et il n'est assemblé que lorsque quelqu'un va voir - c'est-à-dire après que quelque chose a déjà mal tourné.
Un serveur au bureau, deux chez un hébergeur, trois dans un cloud, un dans un autre à cause d'une migration jamais terminée, et une machine dans une agence installée avant l'arrivée de l'équipe actuelle. Chacun a son espace d'adressage, son chemin d'accès et son responsable.
Aucune console unique ne les couvre, parce qu'ils n'ont jamais été achetés comme un seul ensemble. Ce qu'il faut, c'est un endroit qui les traite comme un seul parc, quel que soit l'endroit où chacun se trouve physiquement.
Le deuxième groupe porte sur la distance entre « c'était détectable » et « quelqu'un a agi ». La plupart des incidents douloureux étaient visibles dans un journal depuis le début ; l'échec s'est produit sur les derniers mètres, entre la machine et un être humain.
Un système envoie des courriels, un autre publie dans un canal de discussion, un troisième déclenche un webhook, l'hébergeur envoie des SMS, et le logiciel de sauvegarde dépose un rapport dans un dossier que personne n'a ouvert depuis son installation.
Rien ne se recoupe. Le même incident produit quatre notifications sous quatre noms différents, à quatre endroits, et le travail consistant à comprendre qu'il s'agit du même incident revient à celui qui regardait par hasard la bonne fenêtre.
Une supervision non réglée alerte en continu : un pic processeur pendant une tâche nocturne, un disque qui franchit un seuil qu'il franchit chaque semaine, un service qui redémarre comme prévu. Les gens apprennent très vite que cela peut être ignoré, et ils ont raison jusqu'au jour où ils ont tort.
Une fois qu'un canal a appris à ses lecteurs à le sauter, ajouter des alertes empire les choses au lieu de les améliorer. La mesure utile n'est pas la quantité détectée, mais la quantité qui atteint quelqu'un qui agit ensuite.
Les petites et moyennes équipes n'ont pas de tour de garde. La personne qui connaît les systèmes dort, est dans un avion ou en vacances, et l'incident s'en moque. Tout doit donc être compréhensible par celui qui est réellement disponible - y compris quelqu'un qui n'a rien construit de tout cela.
Cela impose une exigence forte à ce qu'une alerte doit dire. « db-01 CPU 96 % » ne signifie rien à trois heures du matin pour quelqu'un qui ne s'est jamais connecté à db-01 ; ce qui s'est passé autour et à quoi ressemble la normale font la différence entre une réparation et une chaîne d'appels.
Chaque serveur a été configuré à la main, à une époque différente, par une personne différente, avec une idée différente de ce qui justifie de réveiller quelqu'un. Deux ans plus tard, aucune machine ne s'accorde avec une autre, personne ne se rappelle pourquoi l'une est à 85 % et l'autre à 95 %, et les changer toutes signifie toutes les visiter.
Un parc a besoin d'autre chose : une valeur par défaut qui se propage partout, et des dérogations par hôte visibles comme telles - pour qu'un écart soit une décision délibérée que l'on peut réexaminer, et non un accident d'histoire.
Un port RDP ou SSH exposé est attaqué en permanence, et un mot de passe deviné ressemble, dans le journal, presque exactement à une connexion normale. Les indices sont là - une hausse des échecs, une source inconnue, une première connexion réussie depuis un nouveau pays - mais seulement sous forme de lignes dans un fichier que personne ne lit chaque jour.
La détection doit donc être quelque chose que fait la machine, et non une personne une fois par trimestre. La fenêtre qui compte est celle entre la première tentative et la première réussite, et elle se mesure généralement en heures.
Le troisième groupe porte sur le moment où quelqu'un hors de l'équipe technique a besoin d'une réponse. La disponibilité, l'historique des incidents et la preuve d'une surveillance existent soit sous forme d'enregistrement, soit pas du tout : on ne les reconstitue pas après coup de mémoire.
Dès que la disponibilité est inscrite dans un accord, elle cesse d'être une impression et devient un chiffre qu'il faut produire chaque mois, défendre en cas de litige et calculer de la même façon à chaque fois. « À notre connaissance, ça tournait » n'est pas une mesure.
L'enregistrement protège aussi dans l'autre sens. La plupart des litiges de disponibilité portent sur la responsabilité d'une panne, et une chronologie montrant que l'hôte était en bonne santé pendant que le lien du client était coupé met fin à la discussion plus vite que n'importe quel argument.
Les demandes de cyberassurance, les évaluations fournisseurs et les cadres réglementaires sur les données de paiement et à caractère personnel posent tous une variante de la même question : comment savez-vous que vos systèmes fonctionnent comme prévu, et comment sauriez-vous qu'ils ne le font plus ?
Ce qui est attendu n'est pas un nom d'outil. C'est la preuve que la surveillance a été continue sur la période examinée, que les alertes sont parties vers un endroit où une personne les lisait, et que les incidents ont été consignés plutôt que mémorisés.
Les infogéreurs, les administrateurs système indépendants et les petites sociétés informatiques portent des dizaines de machines chez des entreprises, des hébergeurs et des architectures réseau différents. Chaque client a ses horaires, sa tolérance à l'interruption et sa propre idée de ce qui est urgent.
Les configurer une à une à la main ne passe pas à l'échelle - pas plus que découvrir un problème au moment où le client téléphone. Un tel parc a besoin d'une base commune appliquée partout, d'exceptions par client là où l'un diffère réellement, et d'un mur unique où tout se voit d'un coup.
Quelle machine compte, à quoi ressemble une charge normale dessus, quelle alerte peut être ignorée sans danger, pourquoi ce seuil a été relevé en mars : rien de tout cela n'est écrit nulle part. C'est porté par la personne qui a tout installé, et cela s'en va avec elle.
Une passation devient alors un chantier d'archéologie, et les premiers mois entre de nouvelles mains passent à redécouvrir ce que l'on savait parfaitement un an plus tôt. Un historique et une configuration qui vivent en dehors d'une personne sont la seule défense contre cela.
La surveillance n'est pas sans risque. Tout ce qui lit des métriques sur chacune de vos machines dispose, par définition, d'un pied sur chacune de vos machines - et reste joignable depuis l'extérieur, puisque c'est tout l'intérêt.
La question de savoir comment le parc est surveillé est donc aussi une question sur ce canal : qui peut lui parler, quelle identité chaque partie prouve, ce qu'il advient des données en transit, et si une console compromise livrerait le parc entier. Il est légitime de la poser avant d'installer quoi que ce soit où que ce soit.
Oui. L'agent ne lit que les métriques locales et ses propres journaux d'auth, et se connecte en sortant via TLS. Il n'ouvre aucun port entrant et n'a aucune capacité offensive.
Oui. Un protocole pilote une unité systemd sous Linux et un service Windows, sur amd64, arm64 et 386. L'installeur détecte la plateforme pour vous.
Chaque agent s'enrôle avec un certificat client et transmet via TLS mutuel. Un jeton d'enrôlement volé est éphémère et ne peut usurper un hôte déjà enrôlé.
Vous définissez les modèles globaux une fois. Chaque serveur surcharge des clés individuelles ; les surcharges cascadent par-dessus les défauts au lieu de les remplacer, si bien qu'un changement de modèle atteint chaque hôte.
Oui. Le panneau se livre en stack docker-compose derrière Traefik avec Postgres (TimescaleDB en option). Voir le guide de déploiement dans le dépôt.
L'agent surveille l'authentification RDP et SSH localement, il signale donc une attaque active et ses principales IP sources en secondes, avant même le rafraîchissement du panneau.
Avec les Servers Sentinel, j'installe l'agent en tant qu'unité système ou service Windows, je le connecte à un canal sortant mTLS et je consulte la dernière télémétrie et le score de santé de l'hôte. Je définis une règle pour les données manquantes, j'envoie une notification par courrier, Telegram, Slack ou webhook et je vérifie l'écart de test ; Je peux conserver un serveur avec un forfait gratuit avec des notifications par e-mail.
Gratuit sans Servers Sentinel J'exécute blackbox_exporter/Prometheus ou une vérification cron ping/TCP depuis un autre site, je stocke last_seen et j'envoie une alerte via Alertmanager. Je vérifie séparément la surveillance elle-même avec un interrupteur homme mort externe, je règle le délai pour un redémarrage normal et je documente le propriétaire de l'hôte ; sinon, la perte du système de surveillance apparaît comme un état vert.
Avec les Servers Sentinel, je collecte l'espace utilisé et libre de chaque système de fichiers sous forme de série chronologique, je définis un seuil général et un remplacement distinct pour un volume spécifique, et j'envoie une notification avant la valeur critique. Je regarde le taux de croissance à côté du pourcentage actuel, vérifie l'inode sous Linux et laisse suffisamment de marge pour les WAL/log et les opérations d'urgence.
Gratuitement, j'installe node_exporter/windows_exporter avec Prometheus et Alertmanager ou j'exécute df/Get-Volume via cron/Task Scheduler. J'avertis en pourcentage et en gigaoctets absolus en même temps, j'ajoute rate/predict_linear pour un horizon de 24 à 72 heures, je configure la rotation/rétention et je teste l'alerte en remplissant artificiellement un volume non critique.
Avec les Servers Sentinel, je stocke une série de processeurs, de mémoire, de disque et de réseau, compare l'hôte à son propre historique et regroupe l'état actuel dans un score de 0 à 100. Je définis la durée de la condition afin de ne pas réagir à un pic d'une minute et je crée des contrôles de disponibilité/TLS/API distincts où la durée du certificat ou la réponse de l'application est importante.
Je déploie Prometheus, Exporters et Grafana gratuitement, je définis des règles d'enregistrement pour la ligne de base et des alertes pour une croissance durable, et je vérifie les certificats avec blackbox_exporter. Je stocke au moins quelques semaines de données, marque le déploiement/maintenance sur les graphiques et n'utilise le taux/dérivation que pour les métriques pertinentes ; Je soutiens TSDB et je règle moi-même.
Avec les Servers Sentinel, j'utilise un protocole pour le service Windows et l'agent systemd sur amd64, arm64 et 386, j'obtiens les mêmes métriques de base et le même score de santé. Je conserve les différences de plate-forme dans les remplacements, mais je trie l'ensemble de la flotte par risque et je transmets la télémétrie à mTLS sans ouvrir le port entrant de l'agent.
Gratuitement, je combine windows_exporter et node_exporter dans un seul Prometheus, je normalise les étiquettes hôte/client/os et je crée un tableau de bord Grafana commun. Je mappe le transfert d'événements Windows et syslog/Loki par UTC, décris les différents seuils du système d'exploitation sous forme de code et vérifie que la mise à jour de l'exportateur ne modifie pas les noms des métriques sans migrer les règles.
Avec les Servers Sentinel j'installe un agent sur chaque hôte ; il initie lui-même la connexion sortante et est authentifié par le certificat client mTLS. J'attribue des balises de site et de propriétaire, je vois tous les hôtes dans une seule console et je définis des règles globalement avec des remplacements point par point, sans créer de route entrante vers chaque machine.
Gratuitement, je connecte les sites WireGuard et interroge les exportateurs avec le centre Prometheus ou j'utilise remote_write/agents qui envoient des métriques en externe. Je limite l'ACL à l'adresse du collecteur uniquement, je protège avec des certificats TLS, je mets en mémoire tampon les données en cas de rupture et je surveille le VPN lui-même ; Je fais moi-même la conception du réseau et la rotation des clés.
Avec les Servers Sentinel, je crée des canaux de messagerie, Telegram, Slack ou webhook dans une seule console, j'envoie un test et je leur envoie des règles en fonction des hôtes requis. J'utilise des noms uniques et un contexte d'hôte afin que l'opérateur voie la métrique, le seuil et l'heure, plutôt que de collecter un incident à partir de quatre lettres indépendantes.
Gratuitement, j'achemine Prometheus Alertmanager vers une passerelle de notification, je définis group_by, group_wait, repeat_interval et inhibition, et je laisse aux sources un lien vers un runbook. Je normalise les étiquettes gravité/service/propriétaire et vérifie les itinéraires avec des alertes de test ; Les SMS et les fournisseurs externes peuvent toujours être facturés, même avec des logiciels gratuits.
Avec les Servers Sentinel, je définis des seuils globaux, des durées de conditions et des exceptions ponctuelles pour les hôtes dont la norme est différente, puis j'achemine les niveaux de gravité vers différents canaux. J'utilise le score d'intégrité pour prioriser, tester la règle et examiner les alertes qui n'ont pas été mises en œuvre.
Gratuitement, je gère un catalogue d'alertes avec un propriétaire et un runbook, que j'utilise dans Prometheus, le regroupement et l'inhibition dans Alertmanager, et je clôture le travail planifié avec silence avec achèvement automatique. Je mesure le nombre de notifications, d'accusés de réception et de tentatives, supprime les signaux non exploitables et ne masque pas le bruit en augmentant simplement tous les seuils.
Avec les Servers Sentinel, je sépare la gravité et les canaux, j'ajoute un rôle/client au nom d'hôte et je ne configure la règle qu'après une violation persistante. Je vérifie le message avec un test, laisse un lien vers le runbook dans le webhook du destinataire et utilise un graphique métrique/une évaluation de la santé afin que la personne de service puisse distinguer un pic ponctuel d'une dégradation.
Gratuitement, je crée un calendrier de routage Alertmanager, j'envoie les événements critiques à un appel/chat via une passerelle disponible et le reste à la file d'attente quotidienne. J'écris un runbook de trois actions, un propriétaire et un critère d'escalade, j'ajoute un lien vers un tableau de bord et émets régulièrement des alertes de formation ; Le canal d'appel gratuit dépend du service sélectionné.
Avec les Servers Sentinel, je définis un modèle de configuration global et, sur un serveur spécifique, je remplace uniquement la clé souhaitée ; le remplacement se superpose à la valeur par défaut plutôt que de copier l'intégralité de la configuration. Je considère l'écart comme une exception, je modifie une fois le seuil global et je vérifie quels hôtes sont délibérément restés à une valeur différente.
Gratuitement, je stocke les règles Prometheus et les paramètres d'inventaire dans Git, je génère des règles Jsonnet/Ansible et j'exige une révision avec la raison et la date limite de l'exception. J'exécute une vérification de la syntaxe CI, une différence de la configuration déployée et un rapport sur les remplacements ; sans une telle discipline, même une pile libre revient rapidement à la dérive manuelle.
Avec les Servers Sentinel, j'active la détection d'authentification locale : un agent sous Windows ou Linux lit les événements RDP/SSH et transmet une attaque active avec une source IP supérieure. J'achemine la règle vers le canal en direct et je fais correspondre une source entre les hôtes ; La fonction de détection est disponible sur un forfait payant ou d'essai éligible.
Gratuitement, je collecte le mot de passe Windows 4625 et sshd Failed dans Wazuh/Elastic ou Loki, crée une corrélation par source_ip pour une fenêtre coulissante et une alerte pour le 4624/Accepté réussi ultérieur. Je synchronise l'heure via NTP, normalise IPv4/IPv6 et exclus les scanners de test ; le chemin libre nécessite un collecteur séparé et une prise en charge des règles.
Avec les Servers Sentinel, je crée des contrôles TCP/TLS/API à partir d'un point externe, stocke un historique des résultats et sépare l'indisponibilité des applications de la télémétrie des agents manquants. Je fixe un SLO, enregistre la maintenance et génère un rapport périodique avec des limites de temps ; Avant de signer, je suis d'accord avec le client sur l'intervalle, les régions d'inspection et les règles d'exclusion.
Gratuitement, je déploie blackbox_exporter et Prometheus en dehors du site contrôlé, considère la disponibilité comme des sondes réussies/attendues et stocke les événements Alertmanager. Je note la maintenance dans un journal séparé, synchronise UTC et génère un rapport Grafana ; un seul point de vérification ne prouve pas la disponibilité globale, donc si besoin j'ajoute une sonde indépendante.
Avec les Servers Sentinel, j'enregistre l'historique des métriques, des contrôles de disponibilité, des paramètres de règles, des canaux et des événements, et j'utilise le journal d'audit pour les modifications de propriétaire et de politique sur le plan approprié. Je télécharge un rapport pour la période exacte, joins un test de livraison et explique l'identité mTLS des agents ; Je considère l’absence de données comme une lacune dans l’observation et non comme la norme.
Gratuitement, je stocke Prometheus/Loki/Wazuh sur un serveur sécurisé avec sauvegarde, configuration et approbations dans Git, et incidents dans un système de tickets. J'enregistre mensuellement la couverture, les lacunes, le test d'alerte et la liste des exceptions, signe le rapport et limite les accès ; l'instrument lui-même, sans procédure de fermeture, ne constitue pas une preuve de contrôle.
Avec les Servers Sentinel, je divise la flotte par équipe/locataire, j'attribue des rôles de spectateur, d'opérateur et d'administrateur et j'applique des modèles de base avec des exceptions client. Je trie tous les hôtes par score de santé, j'envoie des notifications au propriétaire et j'utilise l'option Business/auto-hébergé là où l'isolement et une flotte illimitée sont nécessaires.
Gratuitement, je déploie des locations/instances Prometheus distinctes ou j'isole des données avec des étiquettes et des ACL strictes dans Grafana, en stockant les secrets client dans différents coffres-forts. Je génère une configuration à partir de l'inventaire, achemine Alertmanager par locataire/propriétaire et teste le blocage des accès croisés ; la multilocation sécurisée nécessite plus de travail qu’un seul tableau de bord partagé.
Avec les Servers Sentinel, je signe les hôtes par rôle et propriétaire, stocke des séries de métriques, des modèles globaux et des remplacements explicites, et associe des canaux aux propriétaires. J'utilise l'historique comme référence, documente la raison du seuil non standard à côté du processus de modification et donne au nouvel opérateur un rôle d'affichage uniquement avant de transférer l'autorité.
Gratuitement, je gère l'inventaire et les runbooks dans Git, j'ajoute des liens de tableau de bord, le propriétaire, les dépendances et la justification de chaque remplacement, et j'accepte les modifications via une pull request. Je stocke le provisionnement Grafana/Prometheus sous forme de code, marque le déploiement/maintenance et transfère l'incident à un autre employé une fois par trimestre ; Sans pratique organisationnelle, les graphiques eux-mêmes ne retiendront pas les connaissances.
Avec les Servers Sentinel, j'utilise une connexion sortante TLS mutuelle : chaque agent reçoit un certificat client, et le jeton de connexion éphémère ne remplace pas l'identité déjà émise. Je vérifie les droits du service, la liste des métriques et des logs collectés, désactive les actions inutiles, déploie le pilote sur un hôte et contrôle la révocation du certificat lorsque le serveur est supprimé.
Gratuitement, j'installe node_exporter/windows_exporter sous un compte distinct non privilégié, j'écoute uniquement localhost/VPN et je limite l'ensemble des collecteurs. Je protège le scrape avec TLS/mTLS ou les ACL réseau, signe les paquets, valide les versions, recherche les mises à jour et n'active pas les scripts de fichiers texte qui écrivent à partir de sources non fiables ; Je sépare la gestion de la configuration de la surveillance.
Trois questions qui méritent une réponse avant de déployer quoi que ce soit avec des droits d'administrateur sur un parc de production.
Servers Sentinel est écrit par Victor G. Bobrov, spécialiste principal de la sécurité des serveurs chez Recovery Toolbox : 20+ ans en ingénierie système et sécurité, certifications Microsoft MCSD/MCDBA. Le score de santé, les règles d'alerte et la documentation de ce site sont son travail, publiés sous son nom et non sous une marque anonyme. Documentation →
L'éditeur est File Master LLC, société enregistrée en Bulgarie (UE) - Bulstat/TVA 180842207, bureau à Varna, joignable par téléphone et par e-mail. Les paiements sont traités par PayPro Global en tant que marchand officiel ; les conditions, la politique de confidentialité et l'accord de traitement des données sont publiés intégralement, pas résumés. Conditions d'utilisation · Confidentialité · DPA
L'agent lit les métriques locales et le journal d'authentification de son propre hôte, et les transmet vers l'extérieur en TLS mutuel. Il n'ouvre aucun port entrant et n'a aucun canal de commande à distance : rien ne peut lui être ordonné depuis l'extérieur pour s'exécuter sur votre serveur. Chaque agent s'enrôle avec un certificat client, et un jeton d'enrôlement est de courte durée - un jeton volé ne peut pas usurper un hôte déjà enrôlé. Le panneau lui-même se déploie en docker-compose sur votre propre matériel. Installer l'agent →
La supervision de parc n'est pas un sujet en soi : elle se situe entre les plateformes qu'elle observe, les outils qui l'ont précédée et les normes selon lesquelles un serveur est évalué. Voici les sources qui définissent chacun d'eux.
Les liens pointent vers les sources elles-mêmes : Wikidata lorsque l'entité a un identifiant, la source primaire sinon.
Coordonnées de Recovery Toolbox et de File Master LLC, ainsi que le profil de Victor G. Bobrov, spécialiste sécurité principal de l'entreprise.
File Master LLC est l'entité juridique derrière les services en ligne et les logiciels de Recovery Toolbox.
File Master LLC développe et maintient les services en ligne et les logiciels Recovery Toolbox pour réparer les fichiers, bases de données et formats de messagerie endommagés. L'entreprise se concentre sur des outils de récupération pratiques pour les utilisateurs, les informaticiens et les entreprises qui doivent restaurer l'accès à des données corrompues.
Vos commentaires et suggestions sont les bienvenus. Merci de nous envoyer votre avis sur le site web par e-mail : webmaster@recoverytoolbox.com
Spécialiste de la sécurité des serveurs · 20+ ans en ingénierie système et sécurité
Victor G. Bobrov dirige l'ingénierie de sécurité chez File Master LLC / Recovery Toolbox. Il définit ce que Servers Sentinel surveille sur un parc : le score de santé derrière les métriques d'un hôte, l'activité de force brute dans ses journaux d'authentification, la dérive de configuration au regard des CIS, et les alertes qui doivent partir avant qu'un administrateur ne remarque quoi que ce soit.
Microsoft Certified Solutions Developer - MCSD. Microsoft Certified Database Administrator - MCDBA.
Ajoutez un hôte, lancez une ligne et voyez-le remonter en une minute. Le premier serveur est gratuit.
