Je ne connaissais pas https://reaction.ppom.me/ dont il parle dans les questions/réponses.
C'est vrai que fail2ban consomme énormément même quand on n'a très peu de services à surveiller alors qu'un simple petit suivi de journalctl... Ca me donne une idée...
La doc et le tutorial de ce programme est très pédagogique.
La consommation relevée de fail2ban sur mon serveur est laaaargement en dessous de ce que provoquait régulièrement les scans de vulnérabilité. Et comme ils étaient hyper-fréquents, 50Mo de RAM et 3% de CPU sont largement acceptables, ça équivaut à bien moins qu'un threat Apache et PHP.
Je changerais un jour, mais dans l'immédiat fail2ban fait le job, et sans m'être pris la tête, donc malgré ses imperfections, il joue parfaitement son job.
# Reaction
Posté par wilk (site web personnel, Mastodon) . Évalué à 4 (+2/-0).
Je ne connaissais pas https://reaction.ppom.me/ dont il parle dans les questions/réponses.
C'est vrai que fail2ban consomme énormément même quand on n'a très peu de services à surveiller alors qu'un simple petit suivi de journalctl... Ca me donne une idée...
La doc et le tutorial de ce programme est très pédagogique.
[^] # Re: Reaction
Posté par Da Scritch (site web personnel, Mastodon) . Évalué à 3 (+1/-0).
Hello Wilk et merci.
La consommation relevée de fail2ban sur mon serveur est laaaargement en dessous de ce que provoquait régulièrement les scans de vulnérabilité. Et comme ils étaient hyper-fréquents, 50Mo de RAM et 3% de CPU sont largement acceptables, ça équivaut à bien moins qu'un threat Apache et PHP.
Je changerais un jour, mais dans l'immédiat fail2ban fait le job, et sans m'être pris la tête, donc malgré ses imperfections, il joue parfaitement son job.
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.