Forum Linux.debian/ubuntu Ce matin postgresql ne démarrait plus (Squeeze)

Posté par .
Tags :
1
10
déc.
2012

J'ai trouvé le coupable : Snort.

Snort m'a rempli /var/log/snort de fichiers du genre "tcpdump.log.133323568656" ce qui a saturé les inodes de /var

Dans logrotate.conf j'ai ça :

/var/log/snort/* {
    daily
    create 0640 snort adm
    rotate 2
}

(c'était à weekly et rotate 3, je viens de changer)

et dans /etc/logrotate.d/snort j'ai ça :

/var/log/snort/portscan.log /var/log/snort/alert /var/log/snort/portscan2.log {
    daily
    rotate 7
    compress
    missingok
    notifempty
    create 0640 snort adm
    sharedscripts
    postrotate
        if [ -x /usr/sbin/invoke-rc.d ]; then \
            invoke-rc.d snort restart > /dev/null; \
        else \
            /etc/init.d/snort restart > /dev/null; \
        fi;
    endscript
}

Pour récupérer mes inodes je suis en train d'exécuter un find de bourrin pour virer ces fichiers (j'ai coupé snort bien sûr).

Ma question, comment dois-je configurer snort ou logrotate pour que ça ne se reproduise plus ?

Question subsidiaire, dans le cas d'un FS qui n'as plus d'inode libre, quelle est votre méthode pour trouver où c'est-y qu'ils sont les plein de fichiers ?

Parce que là j'ai trouvé par hasard. Après avoir augmenté la taille de mon FS j'ai lancé un logrotate (vu que j'avais changé le paramètre rotate pour /var/log/snort) qui a planté en listant ces dump TCP dans le répertoire /var/log/snort.

  • # partition /var/log

    Posté par (page perso) . Évalué à 3.

    Snort m'a rempli /var/log/snort de fichiers du genre "tcpdump.log.133323568656" ce qui a saturé les inodes de /var

    D'où l'intérêt d'avoir une partition /var/log séparée.

    Question subsidiaire, dans le cas d'un FS qui n'as plus d'inode libre, quelle est votre méthode pour trouver où c'est-y qu'ils sont les plein de fichiers ?

    à l'arrache :

    find /chemin/du/point/de/montage
    
    

    Et tu regarde ce qui défile à l'écran : si un répertoire revient super souvent, alors c'est là
    :D

    https://www.domotego.com/ | https://www.maccagnoni.eu/ | https://www.smm-informatique.fr/

    • [^] # Re: partition /var/log

      Posté par . Évalué à 3.

      Snort m'a rempli /var/log/snort de fichiers du genre "tcpdump.log.133323568656" ce qui a saturé les
      inodes de /var

      D'où l'intérêt d'avoir une partition /var/log séparée.

      J'ai une partition /var séparée. Même si le rootfs était pas saturé (heureusement, ssh continue de fonctionner) un /var avec plus un seul inode de libre ça fout le bordel.

      J'ai /var/lock et /var/run sur des tmpfs également.

      find /chemin/du/point/de/montage
      Et tu regarde ce qui défile à l'écran : si un répertoire revient super souvent, alors c'est là

      Ouai, pas con…

      • [^] # Re: partition /var/log

        Posté par (page perso) . Évalué à 3.

        Et tu regarde ce qui défile à l'écran : si un répertoire revient super souvent, alors c'est là
        Ouai, pas con…

        Autant éviter d'y aller à la louche et demander au système de compter à la volée :

        find ./ -type f -o type d | cut -d '/' -f 1-2 | uniq -c

        Fuse : j'en Use et Abuse !

        • [^] # Re: partition /var/log

          Posté par (page perso) . Évalué à 4.

          Je dirais même

              find ./ -type f -o -type d | cut -d '/' -f 1-2 | uniq -c | sort -g
          
          
          • [^] # Re: partition /var/log

            Posté par (page perso) . Évalué à 2. Dernière modification le 10/12/12 à 19:08.

            Certes…

            Sauf qu'en collant le sort à la fin tu perd les trois petits mots pas anodins du tout "à la volée" !
            Tu es obligé d'attendre que tout le fs soit parcouru pour qu'un résultat soit affiché…

            Alors qu'en ne le mettant pas, tu peux aller regarder un gros répertoire qui vient de sortir, commencer à faire du ménage, hop un autre gros répertoire viens de sortir, tu regardes, hop un autre énorme…. etc….

            => tu n'es pas inactif pendant des plombes ( les Terra en nfs malgré le fiberchannel ça prend du temps ) ,

            => tu restaures le service plus rapidement…

            Enfin moi je dis ça, je dis rien einh ! ^_^

            Fuse : j'en Use et Abuse !

  • # Script ou Setup

    Posté par (page perso) . Évalué à 2. Dernière modification le 10/12/12 à 14:07.

    Hello,

    A mon sens logrotate n'est pas la bonne approche dans ce cas, car compresser ne libèrera pas d'inode, et la purge n'est pas une manière pertinente car tu peux très bien te retrouver avec un cas ou tu devras baisser la purge à journalière ( donc autant ne plus logger ) voir un cas ou une purge journalière n'est pas suffisante

    Trois approches possibles pour moi :

    1) Script
    Tu ponds un script qui journalièrement :
    - crée un répertoire YYYYMMDD-1
    - move les fichiers de la veille dedans
    - tar.gz le répertoire
    Cela suppose que tu n'auras jamais le cas de débordement de ta capacité en une journée.

    2) Setup FS
    - tu crée une partition avec la terre d'inode, la monte sur /var/log/snort et hop !
    Cela suppose d'avoir une partition de libre, ou pouvoir en libérer une.

    3) Setup Snort
    - il est possible de logger ce bordel en base mysql, je te renvoi sur le net pour trouver la conf qui va bien

    Enfin pour finir, pour trouver ce qui bouffe en i-node personellement j'y vais à coup de $>find ./-type f | cut -d '/' -f 1-2 | uniq -c en considérant que ce ne sont pas les répertoires se multiplient.
    Hélas il n'y a pas d'option 'i-node' sur la commande $>du

    Fuse : j'en Use et Abuse !

    • [^] # Re: Script ou Setup

      Posté par . Évalué à 3.

      Merci pour ton commentaire.

      Je vais attendre quelques jours en surveillant comment se remplit /var/log/snort puis je vais faire un script, plus simple que celui proposé, à savoir virer les dumps plus vieux que X jours.

      Si je comprends bien, le fait de ne plus avoir ces dumps m'empêchera de pouvoir analyser une éventuelle attaque mais n'empêchera pas snort de fonctionner. Il s'agit d'un serveur de test, aucunement critique. Mais je garde ton idée de zipper les vieux dumps si jamais j'en ai besoin.

      Merci encore.

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.