Log des connexions sortantes NATées

Le
Olivier
--f40304378fd4e6af90054f2adcfc
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Bonjour,

Pour satisfaire à des obligations légales, j'ai pour mission de l=
ogguer des
connexions sortantes NATées.

L'installation est la suivante:
Machine distante <--Internet--> Routeur Debian <-- Réseau local --> PC=
(IP
privée)


Quand le PC établit une connexion avec une machine distante, sur Inter=
net,
quelque soit l'application (messagerie, navigation, ), il utilise la
fonction de NAT implémentée sur le routeur.
Sur le réseau local, il peut y avoir 200 PC connectés.

Comment logguer ces informations ?
Que conseillez-vous notamment pour réduire la masse potentielle
d'informations à conserver ?

Idéalement, j'aimerai pouvoir retrouver un PC simplement à partir=
des
adresses et ports publics utilisés en sortie.


Mes remarques:
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 savo=
ir si
le jeu en vaut la peine.

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 appro=
che mais la
commande met un temps supérieur à 10s à s'exécuter (j'i=
maginai la lancer
chaque minute et consigner le résultat dans un fichier).

Slts

[1]
https://home.regit.org/2014/02/logging-connection-tracking-event-with-ulogd=
/

--f40304378fd4e6af90054f2adcfc
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir="ltr"><div><div><div><div><div><div><div>Bonjour,<br><br></div>P=
our satisfaire à des obligations légales, j&#39;ai pour mission d=
e logguer des connexions sortantes NATées.<br></div><br>L&#39;installa=
tion est la suivante:<br></div>Machine distante &lt;--Internet--&gt; Routeu=
r Debian &lt;-- Réseau local --&gt; PC (IP privée)<br><br><br></d=
iv>Quand le PC établit une connexion avec une machine distante, sur In=
ternet, quelque soit l&#39;application (messagerie, navigation, ), il ut=
ilise la fonction de NAT implémentée sur le routeur.<br></div><di=
v>Sur le réseau local, il peut y avoir 200 PC connectés.<br></div=
><div><br></div>Comment logguer ces informations ?<br></div>Que conseillez-=
vous notamment pour réduire la masse potentielle d&#39;informations =
à conserver ?<br></div><br>Idéalement, j&#39;aimerai pouvoir retr=
ouver un PC simplement à partir des adresses et ports publics utilis=
és en sortie.<br><div><br><div><br></div><div>Mes remarques:<br>1. J&#=
39;ai lu ceci [1] mais la configuration d&#39;ulogd que je découvre, m=
e déconcerte. Avant de m&#39;investir dans son apprentissage, j&#39;ai=
merai savoir si le jeu en vaut la peine.<br><br></div><div>2. J&#39;ai auss=
i découvert le paquet netstat-nat et sa commande du même nom. Les=
infos affichées m&#39;ont l&#39;air très bien, en première =
approche mais la commande met un temps supérieur à 10s à s&#=
39;exécuter (j&#39;imaginai la lancer chaque minute et consigner le r=
ésultat dans un fichier).<br></div><div><br></div><div>Slts<br><br>[1]=
<a href="https://home.regit.org/2014/02/logging-connection-tracking-even=
t-with-ulogd/">https://home.regit.org/2014/02/logging-connection-tracking-e=
vent-with-ulogd/</a><br></div></div></div>

--f40304378fd4e6af90054f2adcfc--
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Pascal Hambourg
Le #26433412
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.
Pascal Hambourg
Le #26433411
Le 10/05/2017 à 20:48, Pascal Hambourg a écrit :
é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.

Oups, je voulais dire POSTROUTING (les deux fois).
Jean-Michel OLTRA
Le #26433420
Bonjour,
Le mercredi 10 mai 2017, Olivier a écrit...
Pour satisfaire à des obligations légales, j'ai pour mission de logguer des
connexions sortantes NATées.
L'installation est la suivante:
Machine distante <--Internet--> Routeur Debian <-- Réseau local --> PC (IP
privée)
Comment logguer ces informations ?
Que conseillez-vous notamment pour réduire la masse potentielle
d'informations à conserver ?

Pour quelque chose de similaire, des routeurs Wifi sous base OpenWRT, je
loggue les paquets en PREROUTING qui ont le bit syn mis (--syn) (mais
uniquement, pour nos besoins, sur les ports 80 et 443). Le syslog du routeur
envoie sur le syslog d'un serveur Debian, qui enregistre les logs du routeur
dans un fichier dédié. Après rotation des logs, j'ai un analyseur maison qui
enregistre le port de destination, l'ip de destination, les adresses mac
source et entrée routeur (on a plusieurs routeurs). Une tâche ultérieure
fait la résolution de nom sur l'ip de destination et complète la donnée. Les
enregistrements sont stockés dans une base Postgresql. Au cours de l'analyse
un filtre saute les enregistrements identiques qui sont distants de moins de
N secondes (N=1 pour l'instant).
--
jm
Thierry Bugier Pineau
Le #26433427
--=-qYAJyx+n516O8HW+/Q2q
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Bonjour
Par pure curiosité technique, combien y a t il d'utilisateurs dans le
réseau concerné et quel volume de données transite entre un routeur et
le serveur syslog ?
Pour avoir utilisé OpenWRT des routeurs grand public (netgear) et
trouvé que c'est un peu poussif comme matériel, je me demande aussi
quel type de routeur vous utilisez.
En tout cas l'infrastructure me parait intéressante et l'exemple
excellent pour démontrer l'utilité d'un serveur syslog.
Le jeudi 11 mai 2017 à 11:45 +0200, Jean-Michel OLTRA a écrit :
    Bonjour,
Le mercredi 10 mai 2017, Olivier a écrit...
Pour satisfaire à des obligations légales, j'ai pour mission de
logguer des
connexions sortantes NATées.
L'installation est la suivante:
Machine distante <--Internet--> Routeur Debian <-- Réseau local -->
PC (IP
privée)
Comment logguer ces informations ?
Que conseillez-vous notamment pour réduire la masse potentielle
d'informations à conserver ?

Pour quelque chose de similaire, des routeurs Wifi sous base OpenWRT,
je
loggue les paquets en PREROUTING qui ont le bit syn mis (--syn) (mais
uniquement, pour nos besoins, sur les ports 80 et 443). Le syslog du
routeur
envoie sur le syslog d'un serveur Debian, qui enregistre les logs du
routeur
dans un fichier dédié. Après rotation des logs, j'ai un analyseur
maison qui
enregistre le port de destination, l'ip de destination, les adresses
mac
source et entrée routeur (on a plusieurs routeurs). Une tâche
ultérieure
fait la résolution de nom sur l'ip de destination et complète la
donnée. Les
enregistrements sont stockés dans une base Postgresql. Au cours de
l'analyse
un filtre saute les enregistrements identiques qui sont distants de
moins de
N secondes (N=1 pour l'instant).

--=-qYAJyx+n516O8HW+/Q2q
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: 8bit
Le mercredi 10 mai 2017, Olivier a écrit...
<blockquote type="cite">
Pour satisfaire à des obligations légales, j'ai pour mission de logguer des
connexions sortantes NATées.

<blockquote type="cite">
L'installation est la suivante:
Machine distante &lt;--Internet--&gt; Routeur Debian &lt;-- Réseau local --&gt; PC (IP
privée)

<blockquote type="cite">
Comment logguer ces informations ?
Que conseillez-vous notamment pour réduire la masse potentielle
d'informations à conserver ?

Pour quelque chose de similaire, des routeurs Wifi sous base OpenWRT, je
loggue les paquets en PREROUTING qui ont le bit syn mis (--syn) (mais
uniquement, pour nos besoins, sur les ports 80 et 443). Le syslog du routeur
envoie sur le syslog d'un serveur Debian, qui enregistre les logs du routeur
dans un fichier dédié. Après rotation des logs, j'ai un analyseur maison qui
enregistre le port de destination, l'ip de destination, les adresses mac
source et entrée routeur (on a plusieurs routeurs). Une tâche ultérieure
fait la résolution de nom sur l'ip de destination et complète la donnée. Les
enregistrements sont stockés dans une base Postgresql. Au cours de l'analyse
un filtre saute les enregistrements identiques qui sont distants de moins de
N secondes (N=1 pour l'instant).
</pre></body></html>
--=-qYAJyx+n516O8HW+/Q2q--
Olivier
Le #26433433
--001a113e6e38a9887d054f42493c
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Le 11 mai 2017 à 11:45, Jean-Michel OLTRA
Bonjour,
Le mercredi 10 mai 2017, Olivier a écrit...
Pour satisfaire à des obligations légales, j'ai pour mission de logguer

des
connexions sortantes NATées.

L'installation est la suivante:
Machine distante <--Internet--> Routeur Debian <-- Réseau local -- > PC

(IP
privée)

Comment logguer ces informations ?
Que conseillez-vous notamment pour réduire la masse potentielle
d'informations à conserver ?

Pour quelque chose de similaire, des routeurs Wifi sous base OpenWRT, je
loggue les paquets en PREROUTING qui ont le bit syn mis (--syn) (mais
uniquement, pour nos besoins, sur les ports 80 et 443). Le syslog du
routeur
envoie sur le syslog d'un serveur Debian, qui enregistre les logs du
routeur
dans un fichier dédié. Après rotation des logs, j'ai un an alyseur maison
qui
enregistre le port de destination, l'ip de destination, les adresses mac
source et entrée routeur (on a plusieurs routeurs). Une tâche u ltérieure
fait la résolution de nom sur l'ip de destination et complète l a donnée.
Les
enregistrements sont stockés dans une base Postgresql. Au cours de
l'analyse
un filtre saute les enregistrements identiques qui sont distants de moins
de
N secondes (N=1 pour l'instant).
--
jm


Pour poursuivre dans le même sens, j'avais imaginé l'arsenal File beat,
Elasticsearch, Logstash, Kibana pour centraliser les logs et faciliter leur
analyse sur un serveur central.
Filebeat est-il compatible avec OpenWRT ?
Je ne sais pas mais une fonction intéressante de Filebeat est
théoriquement, sa capacité à limiter sa propre bande passant e et à survivre
à des pertes de connexion.
Filebeat lui-même ne semble pas exiger des ressources importantes.
--001a113e6e38a9887d054f42493c
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
    Bonjour,<br>
<br>
<br>
Le mercredi 10 mai 2017, Olivier a écrit...<br>
<span class=""><br>
<br>
&gt; Pour satisfaire à des obligations légales, j&#39;ai pour mis sion de logguer des<br>
&gt; connexions sortantes NATées.<br>
<br>
&gt; L&#39;installation est la suivante:<br>
&gt; Machine distante &lt;--Internet--&gt; Routeur Debian &lt;-- Résea u local --&gt; PC (IP<br>
&gt; privée)<br>
<br>
</span><span class="">&gt; Comment logguer ces informations ?<br>
&gt; Que conseillez-vous notamment pour réduire la masse potentielle<b r>
&gt; d&#39;informations à conserver ?<br>
<br>
</span>Pour quelque chose de similaire, des routeurs Wifi sous base OpenWRT , je<br>
loggue les paquets en PREROUTING qui ont le bit syn mis (--syn) (mais<br>
uniquement, pour nos besoins, sur les ports 80 et 443). Le syslog du routeu r<br>
envoie sur le syslog d&#39;un serveur Debian, qui enregistre les logs du ro uteur<br>
dans un fichier dédié. Après rotation des logs, j&#39;ai un analyseur maison qui<br>
enregistre le port de destination, l&#39;ip de destination, les adresses ma c<br>
source et entrée routeur (on a plusieurs routeurs). Une tâche ult érieure<br>
fait la résolution de nom sur l&#39;ip de destination et complète la donnée. Les<br>
enregistrements sont stockés dans une base Postgresql. Au cours de l&# 39;analyse<br>
un filtre saute les enregistrements identiques qui sont distants de moins d e<br>
N secondes (N=1 pour l&#39;instant).<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
jm<br>
<br>
--001a113e6e38a9887d054f42493c--
Jean-Michel OLTRA
Le #26433451
Bonjour,
Le jeudi 11 mai 2017, Olivier a écrit...

Pour poursuivre dans le même sens, j'avais imaginé l'arsenal Filebeat,
Elasticsearch, Logstash, Kibana pour centraliser les logs et faciliter leur
analyse sur un serveur central.
Filebeat est-il compatible avec OpenWRT ?
je ne sais pas mais une fonction intéressante de filebeat est
théoriquement, sa capacité à limiter sa propre bande passante et à survivre
à des pertes de connexion.
filebeat lui-même ne semble pas exiger des ressources importantes.

Je ne sais pas si c'est compatible.
Et, pour répondre également à un précédent post, que j'ai malheureusement
détruit (maudite touche d…) :
- Nos routeurs sont une base OpenWRT. Ce sont en réalité des routeurs
Open Mesh. Ceux qui sont en place ne sont pas les plus puissants. Il n'est
pas possible d'installer quoique ce soit sur ces machines, c'est un peu le
problème. A moins de remplacer le micro-code, je crois. Habitant en
France, j'ai encore de la chance de pouvoir y accéder en ssh, ce n'est pas
le cas des routeurs qui sont distribués par cette boite aux US (question
de législation concernant les modifications sur les AP, il me semble).
- Il n'y a pas trop d'utilisateurs en ligne par routeur pour le moment. Le
problème ne serait pas le nombre d'utilisateurs, mais plutôt leur facilité
à générer des requêtes !. Mon dernier fichier de log fait 4300 lignes,
pour principalement un routeur. Ce n'est pas énorme. Côté serveur (OVH) le
flux n'est pas un souci et le traitement du fichier non plus.
- Effectivement, nous avons trouvé que, sur ces routeurs, l'importance du
flux de logs pouvait poser un problème de BP. Surtout que ça loggue tout
un tas de trucs qui nous sont inutiles, et qu'il n'est pas possible de
tout supprimer. Vivent les systèmes fermés !
--
jm
Publicité
Poster une réponse
Anonyme