Articles précédents : Articles
- [3] Concours distributed.net, les PS2 sous linux mobilisées !
- [15] RedHat Linux 7.2 pour Alpha
- [11] Problème de filesystem - newsletter réinitialisée
- [35] IBM réinvente la carte perforée
- [5] Creative Commons : la FSF de la création culturelle ?
- [34] L'ART ne veut pas de réseau libre !
- [3] Pétition contre l'application de l'EUCD en Belgique
- [21] Un nouvel OS pour Palm: version 5
- [19] QuickTime 6 ... un standard !
- [32] Les données à suivre pour Europol
Liens connexes
- Le site de firelogd (1285 hits)
- L'article dans ZDNet Australie (512 hits)
Dépêche modérée par
Articles : Supervision de pare-feu avec firelogd
Posté par DAGAN Alexandre (page perso, ). Modéré le 13 juin 2002.
Le programme firelogd peut grandement faciliter la tâche en permettant l'envoi de messages électroniques à l'administrateur résumant les entrées importantes des fichiers de log.
ZDNet Australie nous en dit un peu plus dans un article dédié à firelogd.
NdR : Après ce sera toujours à l'admin de faire le travail :)
![[en]](../../../images/en.png)
Le site de firelogd (1285 hits)-
L'article dans ZDNet Australie (512 hits)
> Lire les commentaires (9 commentaires, moyenne: 12,1).
Ne pas oublier syslog-ng et fwlogwatch...
Le premier : http://www.balabit.hu/en/downloads/syslog-ng/(...) remplace syslog et permet de trier les logs avec des expressions régulières (et pas seulement par priorité comme pour syslog). On peut donc "facilement" regrouper tous les logs orientés sécurité dans un log à part...
Le second : http://cert.uni-stuttgart.de/projects/fwlogwatch/(...)
permet de filtrer les logs ipchains/iptables/ipfilter/snort et d'autres, de générer du HTML ou du texte brut, d'envoyer des e-mails, etc...
Même si c'est à l'admin de faire le boulot, il vaut mieux être bien équippé.
DaFrog.
J'comprends rien à l'informatique...
Superviser un pare-feu sous Linux peut devenir un véritable challenge à cause de la nature "textuelle" de l'OS
Depuis quand la nature "textuelle" d'un outil rend sa supervision plus compliquée que celle d'un outil avec une jolie interface ? Autant que je sache, il est plus facile d'extraire des informations d'une chaîne de caractères que d'une image...
-
[^]Re: tu comprends rien à l'informatique...
Posté par Victor Vuillard () le 13/06/2002 à 10:18. (lien). Évalué à 14.ben j'ai pas testé firelogd mais si t'as un truc qui te dit "il y a un scan de tel pc vers tel pc du port tant à tant" c'est qd meme mieux que d'avoir qqes centaines de lignes de logs pour chaque port...
enfin, c'est juste une idée !
ceci dit les résumés peuvent aussi bien se retrouver dans une interface graphique ou dans un autre fichier de log...-
[^]Re: je ne comprends rien à l'informatique et en plus on me prend pour un c
Posté par pas_moi () le 13/06/2002 à 10:42. (lien). Évalué à 24.il y a un scan de tel pc vers tel pc du port tant à tant
Et tu as forcément besoin d'une interface graphique pour pouvoir afficher ce message?
Les fichiers de log sont fait pour être lus soit par des admins courageux/balaiz/dino, soit par des outils d'analyse, et je ne vois pas en quoi ces outils devraient toujours avoir une interface graphique...-
[^]Re: je ne comprends rien à l'informatique et en plus on me prend pour un c
Posté par Victor Vuillard () le 13/06/2002 à 16:29. (lien). Évalué à 0.ben lis jusqu'au bout, c'est exactement ce que je disais....
:-P-
[^]Re: je ne comprends rien à l'informatique et en plus on me prend pour un c
Posté par pas_moi () le 13/06/2002 à 23:15. (lien). Évalué à 4.Quand je lis jusqu'au bout, je vois «dans une interface graphique ou dans un autre fichier de log»; si on considère qu'une interface graphique peut s'envisager en mode texte (il y a de très bons analyseurs/sniffeurs en console) alors je suis d'accord avec ta phrase; mais je ne parlais pas de savoir si c'est mieux d'utiliser une interface graphique ou texte pour afficher les résultats de la supervision. Tout le monde est d'accord: c'est plus simple de faire quelque chose de beau en graphique (je n'ai pas dit "mieux", juste "beau").
Dans la news, il est quand même écrit que le fait que Linux préfère les caractères aux pixels est un obstacle à la supervision!!! Soit c'est un troll qui s'est glissé là en passant, soit c'est une grosse bêtise, mais dans les deux cas ça n'a rien à faire dans une news DLFP.
-
-
-
il y a aussi swatch...
swatch utilise des regexp et peut déclencher des actions en conséquences.
http://www.oit.ucsb.edu/~eta/swatch/(...)
Corrélation multi-logs
On commence à voir des produits (proprios :( ) pointer le bout de leur nez en ce qui concerne la corrélation de logs multi-sources. C'est une techno qui a le vent en poupe (la preuve ? j'en cherche un :) ).
Quand on se trimballe après centralisation des kilo-logs de firewall + [nh]ids + syslog + scanner d'intégrité + ..., on arrive à un point où l'on ne peut plus traiter avec son p'tit cerveau d'humanoïde limité. Un traitement de logs digne de ce nom ne se résume pas à des regexp et un coup de gnuplot : ça serait trop simple. Les moteurs de corrélation sont faits pour tirer le meilleur parti des logs, comme un datawarehouse pour des données, ou un compilo pour des sources.
Je me contentais effectivement de swatch auparavant, mais là, c'est plus suffisant ...
Cette page a été générée par Templeet en 0.0832s (dont 0.0185 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Faire un don !
Cette discussion est archivée, il n'est plus possible de laisser des commentaires.
Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.