Re: Où est passé sux ?

[kaliderus]

Me semble bien qu'il y a encore de quoi travailler :
http://fgouget.free.fr/sux/sux

Je vais voir ce qu'on peut en faire...

A+


Le 10 mai 2017 à 22:48,   a écrit :
> On Wednesday 10 May 2017 22:38:54 kaliderus wrote:
>> J'utilisais il y a quelques années sux (package du même nom), mais il
>> a disparu de jessie, comment se fait-ce ?
>> C'était bien pratique.
>> Est-ce qu'il existe un outil de remplacement ou bien ?
>
> Sux ne semble plus maintenu ou du moins sous Debian :
>
> www.kubuntuforums.net/showthread.php?t=66532
>
> Dommage, car bien des Linuxiens le regrette.
>
> André
>

Re: Où est passé sux ?

[andre_debian]

On Wednesday 10 May 2017 22:38:54 kaliderus wrote:
> J'utilisais il y a quelques années sux (package du même nom), mais il
> a disparu de jessie, comment se fait-ce ?
> C'était bien pratique.
> Est-ce qu'il existe un outil de remplacement ou bien ?

Sux ne semble plus maintenu ou du moins sous Debian :

www.kubuntuforums.net/showthread.php?t=66532

Dommage, car bien des Linuxiens le regrette.

André

Re: Où est passé sux ?

[humbert . olivier . 1]

> J'utilisais il y a quelques années sux (package du même nom), mais il
> a disparu de jessie, comment se fait-ce ?

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=726544

> C'était bien pratique.
> Est-ce qu'il existe un outil de remplacement ou bien ?

no sé.

Où est passé sux ?

[kaliderus]

Bonsoir,

J'utilisais il y a quelques années sux (package du même nom), mais il
a disparu de jessie, comment se fait-ce ?
C'était bien pratique.
Est-ce qu'il existe un outil de remplacement ou bien ?

Merci.

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

Re: Configuration Postfix / Dovecot

[Thierry Bugier Pineau]

Bonjour

> "Configurer un_serveur_email_privé" dit le lien :
> il s'agit d'un serveur de messagerie pro.
> Ainsi la ligne de "main.cf" :
> mynetworks = 127.0.0.0/8 ...
> Faut-il ajouter l'IP internet du serveur ?
Non. Ce paramètre n'a pas de sens tout seul, mais globalement l'idée
est que personne ne puisse envoyer de mails vers des domaines
"extérieurs" sans avoir été authentifié. Y compris dans le LAN.
L'exception est ici localhost : le serveur lui-même. Il faudrait que je
voie si je peux vider complètement ce paramètre; ce serait encore un
peu plus sûr.

Plus d'infos ici : http://www.postfix.org/postconf.5.html#mynetworks

D'une manière générale, je trouve la doc de Postfix pas trop mal, je
conseille de la consulter dès qu'un a une petite question sur un
paramètre.

> Le serveur Postfix utilise MySQL

Mes notes concernent un usage personnel de Postfix / Dovecot. Un
annuaire LDAP est exagéré dans ce cas, mais j'aime la possibilité de
l'utiliser avec à peu près tout ce qui manipule des comptes
utilisateur. 

En revanche dans une entreprise, un LDAP est à mon avis un "must have"
à partir de 5 / 10 utilisateurs. J'ai choisi Samba pour sa capacité à
gérer des machines sous Windows, justement parce que je m'intéresse à
l'interopérabilité des deux mondes, et aussi pour en savoir plus sur
l'administration d'infrastructures plus complètes / complexes, comme
celles qu'on trouve en milieu professionnel (et il y a des niveaux de
complexité bien supérieurs à ce que je soumets sur mon wiki). Je ferai
certainement une coche de reverse proxy, et de redondance d'ailleurs
(pour la tolérance de panne).

Le mercredi 10 mai 2017 à 15:08 +0200, andre_deb...@numericable.fr a
écrit :
> On Tuesday 09 May 2017 23:43:49 Thierry Bugier Pineau wrote:
> > Ce message est d'abord pour André, à qui j'ai promis il y a
> quelques
> > semaines mes notes sur la configuration Postfix / Dovecot  sur la
> > partie chiffrement SSL.
> > https://howto-it.dethegeek.eu.org/index.php?title=Postfix_-_Configu
> rer_
> > un_serveur_email_privé
> 
> Thierry,
> 
> Tout d'abord, grand merci d'avoir pensé à moi,
> je vais lire cette doc attentivement.
> 
> "Configurer un_serveur_email_privé" dit le lien :
> il s'agit d'un serveur de messagerie pro.
> Ainsi la ligne de "main.cf" :
> mynetworks = 127.0.0.0/8 ...
> Faut-il ajouter l'IP internet du serveur ?
> 
> > Mes notes me paraissent assez complètes pour résoudre la
> configuration
> > du chiffrement. Cela dit ça reste encore très brut. Il faut
> rajouter
> > des explications presque partout, et que je reconstruise tout de
> bout
> > en bout pour trouver les coquilles.
> > Il me reste à configurer / documenter spamassassin, très
> certainement
> > un webmail comme Roundcube et améliorer l'exploitation du protocole
> > LDAP.
> > Certains demanderont pourquoi utiliser LDAP. Trois raisons basiques
> :
> > - parce qu'on peut
> > - parce que LDAP me permet d'unifier les comptes utilisateur
> > - parce que c'est plus drôle
> > Du coup ce tuto me parait intéressant (ou différent) car la plupart
> des
> > documentations que j'aie pu trouver s'appuient sur des comptes dans
> un
> > fichier plat de Postfix ou dans une base MySQL.
> 
> Le serveur Postfix utilise MySQL
> 
> > A tous les autres lecteurs de cette liste, je suis preneur des
> > observations, commentaires; ou contributions (puisque c'est un
> wiki).
> 
> À bientôt des résultats,
> 
> Bonne journée.
> 
> André
>  
> 
> 

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/