Re: Log des connexions sortantes NATées

[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

Re: Log des connexions sortantes NATées

[Olivier]

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 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
>
>

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.

Re: Log des connexions sortantes NATées

[Thierry Bugier Pineau]

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).
> 

Re: Log des connexions sortantes NATées

[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

Re: Log des connexions sortantes NATées

[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).

Re: Log des connexions sortantes NATées

[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.

Re: Log des connexions sortantes NATées

[Stéphane Rivière]

> 1. En effet, le firewall est un simple script iptables.

C'est (imho) ce qu'il y a de mieux : clarté, franchise et simplicité :)

Et puis ça force à "maîtriser" (un bien grand mot pour moi) le routage
linux et netfiler/iptables (mouarf).

> 2. J'ai essayé de logguer à la main ce que je souhaitais mais dans le
> laps de temps imparti, je n'ai pas réussi à logguer ce que je voulais:
> 1 seule ligne par connexion avec l'IP source, l'IP NATée et l'IP de
> destination.
> J'avoue aussi être affolé par le nombre de connexions ouvertes par la
> simple navigation vers une page web.
> Faut-il tout conserver ?

Je ne connais pas le cahier des charges.

Pour une fonction "sarkozy" conforme à la loi de 2006, j'avais creusé à
l'époque et ma problématique était surtout d'associer un nom, une
personne, avec un trafic (que j'avais résumé aux URL rendues par SQUID).
Ca se règle simplement aujourd'hui avec un numéro de tel et un sms
renvoyant le code. A l'époque, c'était plus compliqué. Mais j'ai pas eu
de souci à l'usage, ça semblait coller (2 clients environ, sur l'île
d'Oléron, de 2007 à 2013).

Pour une fonction se limitant à un matériel d'un coté (donc une IP) et à
un trafic complet (si j'ai bien suivi), quelque soit le port, ça devient
honteux en terme de volume, et j'envisagerai de logguer directement dans
un flux compressé - avec seulement, hors de la compression, les clés de
recherches - heure, IP, etc...), le tout idéalement dans un babasse
gérant les BD temporelles (Postgresql fait ça).

Maintenant, ça me semble important à dev, je suppose qu'on devrait
trouver du 'tout fait'.

> Si oui, comment limiter la masse d'informations ?

Oui, effectivement, quand je bricole, j'introduis des limitations dans
les logs, histoire de ne pas être submergé...

Ta problématique est intéressante.

Je commencerais par bien fouiller le web anglophone, regarder comment
les "portails captifs WIFI" s'y prennent désormais pour ça (regarde
peut-être du coté de Alcazar, c'est un truc français que j'aurais bien
aimé avoir dispo à l'époque au lieu d'avoir à tout faire dans mon coin)...

> 3. C'est clair que les log de squid peuvent être précieux d'autant 
> qu'il existe plusieurs outils d'analyse des logs mais est-ce toujours
> pertinent avec https quand on ne contrôle pas la configuration des PC  ?
> Qu'en penses-tu ?

D'autant plus que si SQUID te sors des logs propres et exploitables
facilement, quid des autres trafics et protocoles...

Si tout doit être loggué, ça va être un projet à part entière, à moins
que tu ne trouves un "truc tout fait" (et ça m'intéresserait aussi)...

> PS: Pas de soucis de ma part pour que la réponse passe par la mailing
> list debian.

Je me suis fait avoir avec le reply/reply-to-list... Faut absolument que
je trouve comment contrer cette "fonctionnalité" de thunderbird (en
fonction des headers de telle ou telle liste, le "répondre" réponds à la
personne et non pas à la liste :)

-- 
Stéphane Rivière
Ile d'Oléron - France


0xD7F43200.asc
Description: application/pgp-keys

Log des connexions sortantes NATées

[Olivier]

Bonjour,

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)


Quand le PC établit une connexion avec une machine distante, sur Internet,
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 savoir 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 approche mais la
commande met un temps supérieur à 10s à s'exécuter (j'imaginai 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/