[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Log des connexions sortantes NATées



Le 10/05/2017 à 14:46, Olivier a écrit :

1. J'ai lu ceci [1] mais la configuration d'ulogd que je découvre, me
déconcerte. Avant de m'investir dans son apprentissage, j'aimerai savoir si
le jeu en vaut la peine.

Je ne savais pas qu'ulogd permettait de logger les événement de conntrack. J'aurais plutôt pensé à utiliser conntrackd pour cela.

Une solution plus simple mais sous-optimale consiste à logger les paquets avec la cible LOG d'iptables dans une chaîne POSTROUTING juste avant qu'ils soient traités par une règle SNAT/MASQUERADE. Il faut prendre au moins les paquets créant une nouvelle connexion (facile, ce sont les seuls qui passent dans les chaînes de la table "nat") et éventuellement les paquets non ICMP qui ont l'état RELATED (connexions de données FTP...), qui ne passent pas dans la table "nat" mais qui traversent la chaîne PREROUTING de la table "mangle" juste avant. En toute rigueur si on prend ces paquets il faudrait aussi prendre ceux de même type qui proviennent de l'extérieur, toujours dans la chaîne mangle/PREROUTING mais sur l'interface interne.

L'inconvénient, c'est que les logs ne contiennent pas l'adresse source ni le port source à la sortie du routeur. Pour l'adresse source, ce n'est pas gênant sauf si le routeur en a plusieurs possibles. Pour le port source, par défaut SNAT et MASQUERADE s'efforcent de ne pas le modifier (sauf en cas de nécessité pour éviter un conflit avec une autre connexion d'un autre poste qui utilise déjà ce port source vers la même adresse destination et le même port destination).

2. J'ai aussi découvert le paquet netstat-nat et sa commande du même nom.
Les infos affichées m'ont l'air très bien, en première approche mais la
commande met un temps supérieur à 10s à s'exécuter

Probablement une ou plusieurs résolutions DNS inverses qui finissent en time-out. Il doit y avoir une option (-n ?) pour désactiver la résolution de nom.

(j'imaginai la lancer
chaque minute et consigner le résultat dans un fichier).

C'est beaucoup trop espacé. Une connexion peut durer bien moins longtemps que ça et passer entre deux exécutions.


Reply to: