Pour satisfaire =C3=A0 des obligations l=C3=A9gales, j'ai pour mission de l=
ogguer des
connexions sortantes NAT=C3=A9es.
L'installation est la suivante:
Machine distante <--Internet--> Routeur Debian <-- R=C3=A9seau local --> PC=
(IP
priv=C3=A9e)
Quand le PC =C3=A9tablit une connexion avec une machine distante, sur Inter=
net,
quelque soit l'application (messagerie, navigation, ...), il utilise la
fonction de NAT impl=C3=A9ment=C3=A9e sur le routeur.
Sur le r=C3=A9seau local, il peut y avoir 200 PC connect=C3=A9s.
Comment logguer ces informations ?
Que conseillez-vous notamment pour r=C3=A9duire la masse potentielle
d'informations =C3=A0 conserver ?
Id=C3=A9alement, j'aimerai pouvoir retrouver un PC simplement =C3=A0 partir=
des
adresses et ports publics utilis=C3=A9s en sortie.
Mes remarques:
1. J'ai lu ceci [1] mais la configuration d'ulogd que je d=C3=A9couvre, me
d=C3=A9concerte. Avant de m'investir dans son apprentissage, j'aimerai savo=
ir si
le jeu en vaut la peine.
2. J'ai aussi d=C3=A9couvert le paquet netstat-nat et sa commande du m=C3=
=AAme nom.
Les infos affich=C3=A9es m'ont l'air tr=C3=A8s bien, en premi=C3=A8re appro=
che mais la
commande met un temps sup=C3=A9rieur =C3=A0 10s =C3=A0 s'ex=C3=A9cuter (j'i=
maginai la lancer
chaque minute et consigner le r=C3=A9sultat dans un fichier).
<div dir=3D"ltr"><div><div><div><div><div><div><div>Bonjour,<br><br></div>P=
our satisfaire =C3=A0 des obligations l=C3=A9gales, j'ai pour mission d=
e logguer des connexions sortantes NAT=C3=A9es.<br></div><br>L'installa=
tion est la suivante:<br></div>Machine distante <--Internet--> Routeu=
r Debian <-- R=C3=A9seau local --> PC (IP priv=C3=A9e)<br><br><br></d=
iv>Quand le PC =C3=A9tablit une connexion avec une machine distante, sur In=
ternet, quelque soit l'application (messagerie, navigation, ...), il ut=
ilise la fonction de NAT impl=C3=A9ment=C3=A9e sur le routeur.<br></div><di=
v>Sur le r=C3=A9seau local, il peut y avoir 200 PC connect=C3=A9s.<br></div=
><div><br></div>Comment logguer ces informations ?<br></div>Que conseillez-=
vous notamment pour r=C3=A9duire la masse potentielle d'informations =
=C3=A0 conserver ?<br></div><br>Id=C3=A9alement, j'aimerai pouvoir retr=
ouver un PC simplement =C3=A0 partir des adresses et ports publics utilis=
=C3=A9s en sortie.<br><div><br><div><br></div><div>Mes remarques:<br>1. J&#=
39;ai lu ceci [1] mais la configuration d'ulogd que je d=C3=A9couvre, m=
e d=C3=A9concerte. Avant de m'investir dans son apprentissage, j'ai=
merai savoir si le jeu en vaut la peine.<br><br></div><div>2. J'ai auss=
i d=C3=A9couvert le paquet netstat-nat et sa commande du m=C3=AAme nom. Les=
infos affich=C3=A9es m'ont l'air tr=C3=A8s bien, en premi=C3=A8re =
approche mais la commande met un temps sup=C3=A9rieur =C3=A0 10s =C3=A0 s&#=
39;ex=C3=A9cuter (j'imaginai la lancer chaque minute et consigner le r=
=C3=A9sultat dans un fichier).<br></div><div><br></div><div>Slts<br><br>[1]=
<a href=3D"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>
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Pascal Hambourg
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.
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.
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 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).
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).
é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
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
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).
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
--001a113e6e38a9887d054f42493c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Le 11 mai 2017 à 11:45, 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 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 <div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quo te">Le 11 mai 2017 à 11:45, Jean-Michel OLTRA <span dir="ltr"><<a href="mailto:" target="_blank"> e.net</a>></span> a écrit :<br><blockquote class="gmail_quote" st yle="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br> Bonjour,<br> <br> <br> Le mercredi 10 mai 2017, Olivier a écrit...<br> <span class=""><br> <br> > Pour satisfaire à des obligations légales, j'ai pour mis sion de logguer des<br> > connexions sortantes NATées.<br> <br> > L'installation est la suivante:<br> > Machine distante <--Internet--> Routeur Debian <-- Résea u local --> PC (IP<br> > privée)<br> <br> </span><span class="">> Comment logguer ces informations ?<br> > Que conseillez-vous notamment pour réduire la masse potentielle<b r> > d'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'un serveur Debian, qui enregistre les logs du ro uteur<br> dans un fichier dédié. Après rotation des logs, j'ai un analyseur maison qui<br> enregistre le port de destination, l'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'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'instant).<br> <span class="HOEnZb"><font color="#888888"><br> --<br> jm<br> <br> </font></span></div><br><br></div><div class="gmail_extra">P our poursuivre dans le même sens, j'avais imaginé l'arsen al Filebeat, Elasticsearch, Logstash, Kibana pour centraliser les logs et f aciliter leur analyse sur un serveur central.<br></div><div class="gmail_ extra">Filebeat est-il compatible avec OpenWRT ?<br>Je ne sais pas mais une fonction intéressante de Filebeat est théoriquement, sa capacit é à limiter sa propre bande passante et à survivre à de s pertes de connexion.<br></div><div class="gmail_extra">Filebeat lui-m ême ne semble pas exiger des ressources importantes.<br></div><div cla ss="gmail_extra"><br></div></div> --001a113e6e38a9887d054f42493c--
Le 11 mai 2017 à 11:45, Jean-Michel OLTRA <jm.oltra@espinasse.net> 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 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.
<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quo te">Le 11 mai 2017 à 11:45, Jean-Michel OLTRA <span dir="ltr"><<a href="mailto:jm.oltra@espinasse.net" target="_blank">jm.oltra@espinass e.net</a>></span> a écrit :<br><blockquote class="gmail_quote" st yle="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
Bonjour,<br>
<br>
<br>
Le mercredi 10 mai 2017, Olivier a écrit...<br>
<span class=""><br>
<br>
> Pour satisfaire à des obligations légales, j'ai pour mis sion de logguer des<br>
> connexions sortantes NATées.<br>
<br>
> L'installation est la suivante:<br>
> Machine distante <--Internet--> Routeur Debian <-- Résea u local --> PC (IP<br>
> privée)<br>
<br>
</span><span class="">> Comment logguer ces informations ?<br>
> Que conseillez-vous notamment pour réduire la masse potentielle<b r>
> d'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'un serveur Debian, qui enregistre les logs du ro uteur<br>
dans un fichier dédié. Après rotation des logs, j'ai un analyseur maison qui<br>
enregistre le port de destination, l'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'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'instant).<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
jm<br>
<br>
</font></span></blockquote></div><br><br></div><div class="gmail_extra">P our poursuivre dans le même sens, j'avais imaginé l'arsen al Filebeat, Elasticsearch, Logstash, Kibana pour centraliser les logs et f aciliter leur analyse sur un serveur central.<br></div><div class="gmail_ extra">Filebeat est-il compatible avec OpenWRT ?<br>Je ne sais pas mais une fonction intéressante de Filebeat est théoriquement, sa capacit é à limiter sa propre bande passante et à survivre à de s pertes de connexion.<br></div><div class="gmail_extra">Filebeat lui-m ême ne semble pas exiger des ressources importantes.<br></div><div cla ss="gmail_extra"><br></div></div>
--001a113e6e38a9887d054f42493c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Le 11 mai 2017 à 11:45, 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 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 <div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quo te">Le 11 mai 2017 à 11:45, Jean-Michel OLTRA <span dir="ltr"><<a href="mailto:" target="_blank"> e.net</a>></span> a écrit :<br><blockquote class="gmail_quote" st yle="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br> Bonjour,<br> <br> <br> Le mercredi 10 mai 2017, Olivier a écrit...<br> <span class=""><br> <br> > Pour satisfaire à des obligations légales, j'ai pour mis sion de logguer des<br> > connexions sortantes NATées.<br> <br> > L'installation est la suivante:<br> > Machine distante <--Internet--> Routeur Debian <-- Résea u local --> PC (IP<br> > privée)<br> <br> </span><span class="">> Comment logguer ces informations ?<br> > Que conseillez-vous notamment pour réduire la masse potentielle<b r> > d'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'un serveur Debian, qui enregistre les logs du ro uteur<br> dans un fichier dédié. Après rotation des logs, j'ai un analyseur maison qui<br> enregistre le port de destination, l'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'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'instant).<br> <span class="HOEnZb"><font color="#888888"><br> --<br> jm<br> <br> </font></span></div><br><br></div><div class="gmail_extra">P our poursuivre dans le même sens, j'avais imaginé l'arsen al Filebeat, Elasticsearch, Logstash, Kibana pour centraliser les logs et f aciliter leur analyse sur un serveur central.<br></div><div class="gmail_ extra">Filebeat est-il compatible avec OpenWRT ?<br>Je ne sais pas mais une fonction intéressante de Filebeat est théoriquement, sa capacit é à limiter sa propre bande passante et à survivre à de s pertes de connexion.<br></div><div class="gmail_extra">Filebeat lui-m ême ne semble pas exiger des ressources importantes.<br></div><div cla ss="gmail_extra"><br></div></div> --001a113e6e38a9887d054f42493c--
Jean-Michel OLTRA
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
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 !
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
