Ulogd : taille des logs enorme !

Ulogd : taille des logs enorme ! - réseaux et sécurité - Linux et OS Alternatifs

Marsh Posté le 18-12-2006 à 21:09:03    

Bonjour,
 
j'utilise un firewall iptable pour décider qui peut avoir accès au net sur mon réseau de 300PC. Ulogd log tout ceux qui accèdent au net avec la ligne :
 

Code :
  1. $IPTABLES -A FORWARD -s $CHAMBRE -i $RINTERFACE -o $IINTERFACE -j ULOG --ulog-prefix "NAT :"


 
(dans un script bash).
 
Le problème c'est que la taille du fichier de log explose. Il atteint rapidement 2GO puis s'arrête de logguer !
 
J'ai mis un niveau de log égal à 5 (debug(1), info(3), notice(5), error(7) or fatal(8) )
 
Nous sommes considéré un peu comme un fai, donc nous devons garder légalement ces logs. Il y a t'il un moyen :

  • Soit de logguer moins mais en gardant un bon niveau pour rester dans la légalité
  • Soit d'augmenter la taille du fichier de log (j'imagine que c'est spécifique à ulog mais bon...)


Je me penche en solution de secours sur la rotation des logs, mais le disque dur va vite se remplir...
 
Merci

Reply

Marsh Posté le 18-12-2006 à 21:09:03   

Reply

Marsh Posté le 18-12-2006 à 21:52:52    

Si tu utilises cette regle la, tu vas logguer TOUS les paquets routés par ton firewall.
Pour TCP seul les paquets TCP SYN sont suffisants.
Pour UDP, c'est un peu plus compliqué.

 

En fait j'utiliserais le stateful et je ne logguerais que les paquets dans l'état NEW (ce qui marche pour UDP et TCP). Renforcé par les SYN TCP.
Par contre, ce ne sera pas bien dur de remplir tes logs en floodant ton firewall avec les paquets adéquats, paquets spoofés pour éviter qu'on remonte...


Message édité par l0ky le 18-12-2006 à 22:34:19
Reply

Marsh Posté le 18-12-2006 à 22:01:50    

Pour info, d'un point de vue légal, un FAI doit pouvoir déterminer qui utilise quelle adresse IP à quel moment et non pas qui va visiter quoi. Typiquement on va venir te voir en te posant la question :
  "qui a utilisé cette adresse IP de telle a telle heure ?"

 

Dans ce cas, tu es dans l'obligation de donner a la justice l'identité, de manière fiable, de l'individu. Dans ton cas, on dirait que tu fais du NAT. Donc, si on vient te voir, on te donnera la seule adresse publique à priori...

 

La justice pourrait éventuellement te donner l'adresse de la victime, ou de la destination du traffic incriminé (pas forcément une victime). Dans ce cas, a partir de tes log tu pourrais éventuellement remonté à celui que tu cherches à condition que :
 - une seule et bien UNE seule a envoyé du traffic vers cette adresse.
 - que cette personne soit bien celle a qui tu penses avoir affecté l'adresse.

 

J'espere pour toi que tu as mis en place d'autres mécanismes de sécu pour empécher que quelqu un utilise a tort et a travers n'importe quelle adresse IP...


Message édité par l0ky le 18-12-2006 à 22:08:05
Reply

Marsh Posté le 18-12-2006 à 23:02:49    

Hum je ne connaissais pas ces détails...
 
Pour te répondre rapidement au niveau sécu, j'utilise le doublet adresse MAC + IP pour autoriser les utilisateurs à accéder au net (système non dénué de faille mais bon les utilisateurs ne sont pas de très grands connaisseurs en informatique...).
 
Au vu de ce que tu dis, je suis obligé de logguer tout ce qui passe, car comme tu l'as vu je fais du NAT. Ainsi, tous les utilisateurs ont la même IP publique, et je doit pouvoir remonter les traces.

Citation :

En fait j'utiliserais le stateful et je ne logguerais que les paquets dans l'état NEW (ce qui marche pour UDP et TCP). Renforcé par les SYN TCP.


Est ce que ce système permet de remonter les traces ?
Si oui, je ne suis pas très familier avec iptables donc si tu pouvais me donner quelques pistes pour mettre ça en place pour remplacer ma ligne ce serait sympa ! (j'ai récupéré ce script de mon prédécesseur)
 
Ca ne fait que quelques heures que j'ai renouvelé les logs et je suis déjà à près d'1GO de log !!!


Message édité par sonick le 18-12-2006 à 23:04:05
Reply

Marsh Posté le 18-12-2006 à 23:19:47    

Une ligne du type :

Code :
  1. $IPTABLES -A FORWARD -s $CHAMBRE -i $RINTERFACE -o $IINTERFACE -m state --state NEW -j ULOG --ulog-prefix "NAT :";


serait-elle valable ?

Reply

Marsh Posté le 19-12-2006 à 08:36:03    

sonick a écrit :

Une ligne du type :

Code :
  1. $IPTABLES -A FORWARD -s $CHAMBRE -i $RINTERFACE -o $IINTERFACE -m state --state NEW -j ULOG --ulog-prefix "NAT :";


serait-elle valable ?


 
a priori, oui, mais je suis pas un pro d'iptables, faut attendre la réponse des experts :jap:  
 
idem pour les SYN TCP, ça doit être du côté de -p tcp --syn (à confirmer) pour les initialisations de connection

Reply

Marsh Posté le 19-12-2006 à 08:37:01    

sonick a écrit :

Une ligne du type :

Code :
  1. $IPTABLES -A FORWARD -s $CHAMBRE -i $RINTERFACE -o $IINTERFACE -m state --state NEW -j ULOG --ulog-prefix "NAT :";


serait-elle valable ?


oui, mais ca dépend ou tu la places dans ton script...


Message édité par l0ky le 19-12-2006 à 08:37:07
Reply

Marsh Posté le 19-12-2006 à 09:13:06    

Reply

Marsh Posté le 19-12-2006 à 09:25:06    

Taz a écrit :

logrotate :o


Relis le sujet au lieu de lire en travers [:neriki]
Il loggue trop, beaucoup trop. Autant réduire ce qu'il loggue au strict nécessaire. Si tu lui fous un logrotate, son fichier va se remplir jusqu'a atteindre une limite de 2Go en attendant la prochaine exécution de logrotate et donc perdre une certaine quantité d'info.

 

Celà étant, un logrotate créant un fichier de log par jour, compressé en bzip2 te fera gagner beaucoup de place étant donné que les logs générés par ulogd sont fortement compressable (très structuré).

Message cité 1 fois
Message édité par l0ky le 19-12-2006 à 09:28:52
Reply

Marsh Posté le 19-12-2006 à 11:46:13    

Citation :

oui, mais ca dépend ou tu la places dans ton script...


 
Peut tu développer un peu plus stp ? Je n'ai que remplacé ma ligne par celle que je viens de donner...
J'ai aussi mis en place un logrotate mais bon le remplissage est tellement rapide qu'il est sûr qu'il faut réduire les logs !

Reply

Marsh Posté le 19-12-2006 à 11:46:13   

Reply

Marsh Posté le 19-12-2006 à 12:06:46    

Effectivement, la compression est efficace : je passe de 2GO à 120MO !
Je pense que je tient le bon bout !

Reply

Marsh Posté le 19-12-2006 à 12:28:52    

l0ky a écrit :

Relis le sujet au lieu de lire en travers [:neriki]
Il loggue trop, beaucoup trop. Autant réduire ce qu'il loggue au strict nécessaire. Si tu lui fous un logrotate, son fichier va se remplir jusqu'a atteindre une limite de 2Go en attendant la prochaine exécution de logrotate et donc perdre une certaine quantité d'info.

Sauf si tu sais configurer logrotate :o
 
Et après c'est à lui de décider s'il log trop. Logger les SYN ça ne log que les tentative de connexions, rien d'autre. Aucune volumétrie.
 
Peut-être serait-il judicieux de mettre en place un proxy transparent qui lui fournira des logs intelligibles pour les accès HTTP/FTP

Reply

Marsh Posté le 19-12-2006 à 12:43:07    

Taz: le but est de garder le minimum pour la légalité, rien de plus. J'ai bien configuré logrotate, mais il n'agit pas sur le volume de log

Reply

Marsh Posté le 19-12-2006 à 12:47:47    

c'est inexploitable des logs de firewalls. Si tu vois un SYN vers google, ça te ne dit pas si le gars a fait des recherche sur des trucs pédophiles ...

Reply

Marsh Posté le 19-12-2006 à 12:51:59    

sonick a écrit :

Taz: le but est de garder le minimum pour la légalité, rien de plus. J'ai bien configuré logrotate, mais il n'agit pas sur le volume de log


 
ce qu'il essaye peut-être de te dire c'est que logguer des paquets au niveau transport pour apprécier des connexions applicatives (http, ftp, ...), n'est pas adapté du tout sans un important travail derrière.
 
Par exemple si tu loggue les SYN, comment veux-tu faire la différence entre une tentative de connexion réussie et une autre qui s'est arreté à ce niveau du handshake ?
 
D'autant plus qu'avec les virtualhosts qui sont largement employés, une IP peut correspondre à plusieurs sites, et dans l'exemple simplifié où un hébergeur ne dispose que d'une IP publique, tu ne pourras pas savoir quel site à été consulté chez lui.
 
Alors qu'avec un proxy transparent comme le suggère Taz, c'est bien mieux adapté. Tu peux faire avec les paquets, mais attends-toi à devoir pondre un sacré script pour l'analyse.
 
Et je suis sûr qu'il y a d'autres problèmes de ce genre.

Reply

Marsh Posté le 19-12-2006 à 13:07:28    

Surement, mais n'étant pas responsable directement de la sécurité (j'ai un ingé réseau au dessus de moi), je ne m'occupe que du log provenant de ma résidence. L'ingé lui regarde plus en détail la sécurité

Reply

Marsh Posté le 19-12-2006 à 13:09:49    

Ce qui est demandé n'est pas de controler ce que fait le gars sur le web, mais de garder une traces des connexions IP. S'il veut tracer les sites web visiter il fout un proxy avec squid (eventuellement squidgard) avec authentification obligatoire et le tour sera jouer.
 
D'un point de vue légal, sa seule obligation est de pouvoir donner l'identité d'une personne à partir d'une adresse IP et d'une heure. Les logs d'iptables sont suffisant pour déterminer quelle adresse a contacter quel serveur. Suivant sont architecture, sa politique d'attribution d'adresse et les autres s mécanismes de sécurité (en particulier antispoofing) c'est plus ou moins satisfaisant. Certes ce n'est pas la panacées.
 
 
A première il fournit une connectivité IP. Il pourrait tres bien modifier son offre pour limiter l'acces au web, filtrer par un squidgard  + accès pop/smtp. [:spamafote]

Reply

Marsh Posté le 19-12-2006 à 13:12:26    

En fait le filtrage est effectué plus haut, par l'ingé. Perso avec ma passerelle je ne fait que relayer les requêtes en gardant un log

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed