Forum |  HardWare.fr | News | Articles | PC | S'identifier | S'inscrire | Shop Recherche
1753 connectés 

  FORUM HardWare.fr
  Linux et OS Alternatifs
  réseaux et sécurité

  Ulogd : taille des logs enorme !

 


 Mot :   Pseudo :  
 
Bas de page
Auteur Sujet :

Ulogd : taille des logs enorme !

n°871966
sonick
Posté le 18-12-2006 à 21:09:03  profilanswer
 

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

mood
Publicité
Posté le 18-12-2006 à 21:09:03  profilanswer
 

n°871973
l0ky
Posté le 18-12-2006 à 21:52:52  profilanswer
 

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
n°871975
l0ky
Posté le 18-12-2006 à 22:01:50  profilanswer
 

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
n°871990
sonick
Posté le 18-12-2006 à 23:02:49  profilanswer
 

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
n°871996
sonick
Posté le 18-12-2006 à 23:19:47  profilanswer
 

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 ?

n°872032
darkpengui​n
Posté le 19-12-2006 à 08:36:03  profilanswer
 

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

n°872033
l0ky
Posté le 19-12-2006 à 08:37:01  profilanswer
 

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
n°872041
Taz
bisounours-codeur
Posté le 19-12-2006 à 09:13:06  profilanswer
 
n°872045
l0ky
Posté le 19-12-2006 à 09:25:06  profilanswer
 

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
n°872073
sonick
Posté le 19-12-2006 à 11:46:13  profilanswer
 

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 !

mood
Publicité
Posté le 19-12-2006 à 11:46:13  profilanswer
 

n°872080
sonick
Posté le 19-12-2006 à 12:06:46  profilanswer
 

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

n°872086
Taz
bisounours-codeur
Posté le 19-12-2006 à 12:28:52  profilanswer
 

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

n°872095
sonick
Posté le 19-12-2006 à 12:43:07  profilanswer
 

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

n°872098
Taz
bisounours-codeur
Posté le 19-12-2006 à 12:47:47  profilanswer
 

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 ...

n°872099
ory
Posté le 19-12-2006 à 12:51:59  profilanswer
 

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.

n°872104
sonick
Posté le 19-12-2006 à 13:07:28  profilanswer
 

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é

n°872105
l0ky
Posté le 19-12-2006 à 13:09:49  profilanswer
 

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]

n°872107
sonick
Posté le 19-12-2006 à 13:12:26  profilanswer
 

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


Aller à :
Ajouter une réponse
  FORUM HardWare.fr
  Linux et OS Alternatifs
  réseaux et sécurité

  Ulogd : taille des logs enorme !

 

Sujets relatifs
Taille d'un fichierGRUB : modifier la taille du cadre du menu
Quel soft pour analyser mes logs SquidTaille des paquets debian ?
Quelle taille de partition pour MAC OS X intel ?Lister les fichiers d'un répertoire d'une taille définie
NIS / Quota Taille Fichiers / Solaris - LinuxAnalyse de logs
connaitre la taille d'un dossier[ENORME FAILLE] Debian et Suse
Plus de sujets relatifs à : Ulogd : taille des logs enorme !


Copyright © 1997-2022 Hardware.fr SARL (Signaler un contenu illicite / Données personnelles) / Groupe LDLC / Shop HFR