Forum Linux.général Recherche de solutions pour surveiller la "sur"utilisation d'un port destination/service

Posté par  .
Étiquettes : aucune
2
12
avr.
2012

Bonjour,

Ayant des machines virtuelles à administrer je me suis retrouvé parfois avec des spammeurs qui utilisaient mes machines pour spammer la planète entière.

Ces utilisateurs étant root sur leur VM je ne peux pas installer de programme local pour surveiller l'utilisation du mail.

J'aimerai donc, grace à du port-mirroring au niveau des switchs pouvoir et une solution libre:

Au mieux:

-> Surveiller en temps reel le nombre d email envoyés depuis chaque VM et au dela de "n" mails m'envoyer un email pour m'avertir, voir bloquer la connexion (plus difficil car cette machine de "control" ne serait pas le routeur/firewall).

Au pire:

-> Disposer de statistiques du type:

IP_SRC = XXXX connections ce jour vers le port 25.

Je pensais faire un script basé sur du tcpdump avec des filtres et du sort…
(si par exemple il detecte un nombre trop élevé, hop email!)
Mais si quelqu'un avait une meilleure idée ce serait top!

Merci pour votre aide.

  • # Netflow ...

    Posté par  . Évalué à 3.

    Netflow pourrait-il ètre une piste ?

    Il faudrait alors que le linux s envoit des data netflow a lui meme sur un collector… une idée ?

    • [^] # Re: Netflow ...

      Posté par  . Évalué à 1. Dernière modification le 12 avril 2012 à 21:36.

      compliqué mais probablement une solution egalement

  • # Bonjour

    Posté par  . Évalué à 0.

    Tu n'as pas précisé quelle solution de virtualisation tu utilises (KVM, VirtualBox, VMware, … ?).

    Je pense que toutes ces solutions propose plusieurs modes pour la réseau des systèmes invités : NAT ? bridge ? Je pense que ça aiderait si tu donnais plus de détails.

  • # Plus simple

    Posté par  . Évalué à 3.

    Je pensais faire un script basé sur du tcpdump avec des filtres et du sort…

    iptables permet d'enregistrer des logs. Couplé à rsyslog et à des scripts de filtre/tri, tu peux obtenir facilement des données précises (régularité des envois, nombre de serveurs différents contactés)..

    Le seul avantage que je vois à tcpdump c'est de pouvoir intercepter, en plus, l'adresse @mail de destination (et pas seulement l'IP du MX de destination), et d'avoir un critère de filtre/tri supplémentaire par rapport à iptables. Et encore, c'est uniquement si les gens n'utilisent pas SSL.

    THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.

  • # une piste

    Posté par  (site web personnel) . Évalué à 1.

    Iptables:
    - matcher state NEW
    - -m limit
    - …

    Système - Réseau - Sécurité Open Source - Ouvert à de nouvelles opportunités

  • # oui mais...

    Posté par  . Évalué à 2.

    Tout cela est vraiment intéressant !

    J ai eu également l'idée d iptable qui me parait pas mal du tout.
    Mais cela va t il fonctionner sur une carte réseau qui ne route pas le traffic mais le sniff uniquement (vu que je seai sur un port mirroré d un switch), je demande ça car il ne me semble pas que limit+ACCEPT fonctionne je me trompe ?

    Concernant l archi la solution est basée sur CitrixXen pour la virtualisation avec des IP publiques (et un FW Cisco ASA devant)

    Seulement comme je suis curieux je me demandais aussi:

    Vu qu'il existe des solution antispam qui fonctionne sur un mode de "relais filtrant"

    Connaissez vous une solution qui me permettrait d analyser via les packets sniffés le contenu afin qui si celui ci est douteux et nombreux je sois egalement averti, comme un SpamAssassin mais au niveau réseau ? je rêve peut être mais techniquement ça me parait pas déconnant…

    Merci à vous!

    • [^] # Re: oui mais...

      Posté par  . Évalué à 2.

      Connaissez vous une solution qui me permettrait d analyser via les packets sniffés le contenu afin qui si celui ci est douteux et nombreux je sois egalement averti, comme un SpamAssassin mais au niveau réseau ? je rêve peut être mais techniquement ça me parait pas déconnant…

      ca se passe sur TON parefeu (ou celui de ton serveur hote, celui qui heberge les VMs)
      tu peux tres bien avoir toutes les IPs publiques qui arrivent sur 1 serveur

      ce serveur fait du NAT 1:1 (une IP Publique = une IP Privée VM)
      il peut donc avoir iptables qui compte les paquets et te fait du reporting.

      tu peux aussi demander à ton FW Cisco ASA de le faire pour toi, c'est quand meme son metier, de filtrer ce qui circule, voire de limiter les flows

      tout ca sans t'embarquer dans l'analyse d'un port mirroir

    • [^] # Re: oui mais...

      Posté par  . Évalué à 4.

      je rêve peut être mais techniquement ça me parait pas déconnant…

      Non, mais c'est plutôt sur le plan éthique et légal qu'il faut peut-être se poser des questions. À priori, je dirais que mesurer la volumétrie de mails et lever une alerte sur un gros volume ça n'est pas très intrusif, mais si tu commences à traiter les données dans le mail, c'est déjà plus limite. Le strict minimum serait de prévenir les utilisateurs, de te renseigner sur les contraintes légales..

      Selon le contexte (spammeurs volontaires, débutants vérolés..) tu peux peut-être articuler une réponse juridique ou contractuelle à ton problème, en lien avec la solution technique. Par exemple, prévenir qu'au delà de XXX mails par jour, ils sont analysés par un antispam, et que tu te réserves le droit de les lire si l'antispam est positif, et de couper le serveur si c'est du vrai spam.

      Parce que là, une fois ton détecteur en place, tu vas faire quoi ? Mettons que l'antispam se déclenche, tu lis les mails pour vérifier, et hop, ce sont des mails à caractère médical et confidentiel (avec les mots pénis et viagra dedans, qui ont déclenché l'antispam), ou bien une plateforme de rencontre en ligne avec des mails érotiques et très confidentiels entre utilisateurs.. là, je pense que tu serais largement en dehors des clous du point de vue de la loi. Et tout automatiser, par exemple, couper le serveur au delà d'un certain volume de (faux) positifs, ce n'est guère mieux.

      THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.

  • # Monitoring

    Posté par  (site web personnel) . Évalué à 1.

    Tu as ntop qui est plutot pas mal pour analyser le trafic applicatif d'un réseau

Suivre le flux des commentaires

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