Problème traps SNMP avec un firewall

Support Debian
#1

Bonjour,

Je possède un serveur Debian 6.0 avec Centreon/Nagios 3 dessus.

J’ai créé un firewall iptables (/etc/firewall/main => mon fichier de conf iptables).

J’échange des informations SNMP et SNMP traps de nagios vers Centreon en passant par le firewall (en local car tout est sur la même machine).
Lorsque je génère une trap SNMP, je la reçoi bien dans /var/log/snmptt.log bien interprétée par centTrapHandler qui permet de traduire ma trap et l’OID.
Mes trap s’affichent dans l’interface web de Centreon sans firewall, en revanche lorsque le firewall tourne, j’ai toujours mes traps qui arrivent dans snmptt.log mais je ne peux pas les voir sur l’interface web de Centreon.

Mon firewall est configuré comme ceci :
#SNMP
$IPTABLES -A INPUT -p udp --dport 161 -j ACCEPT
$IPTABLES -A OUTPUT -p udp --sport 161 -j ACCEPT

#SNMP TRAPS
$IPTABLES -A INPUT -p udp --dport 162 -j ACCEPT
$IPTABLES -A OUTPUT -p udp --sport 162 -j ACCEPT

Donc ne recevant pas les trap sur l’interface web de Centreon je ne reçois donc pas non plus les alertes sms et mail.

Sur certain forum j’ai entendu parlé de :
Citation "
Autoriser les équipements à envoyer des traps SNMP vers les collecteurs :

vi /etc/sysconfig/iptables

Avant la ligne

-A RH-Firewall-1-INPUT -j REJECT --reject-with icmp-host-prohibited
copiez la ligne :

-A RH-Firewall-1-INPUT -p udp -m udp --dport 162 -j ACCEPT

"
Lorsque je test ces lignes cela me met lorsque je lance mon firewall (/etc/init.d/firewall start) => no chain/target/match by that name.

Peut on m’aider ?

Merci d’avance

Cordialement

#2

Up

svp :s

#3

=> t’as accepté le loopback entrant et sortant dans ton firewall ?

=> c’est pas –sport ?

#4

Merci pour ta réponse

=> t’as accepté le loopback entrant et sortant dans ton firewall ?[/quote]

Oui j’ai bien accepté le loopback :
$IPTABLES -A INPUT -i lo -j ACCEPT
$IPTABLES -A OUTPUT -o lo -j ACCEPT

=> c’est pas –sport ?[/quote]

En effet j’ai modifié, une erreur de saisi sur le forum de ma part

Et bien j’ai repris le même sens de configuration que le SNMP. Le SNMP fonctionne donc les traps SNMP fonctionnent sur le même principe normalement.
Car mes requêtes SNMP passent bien avec le firewall actif en INPUT --sport et OUTPUT --dport donc j’ai repris ma configuration pour les traps, ça devrai passer.

Merci

#5

Ducou ma question serai comment transitent les traps SNMP de snmptt.log vers Centreon ?

Je sais que cela passe sur centTrapHandler et ducou es ce qu’il n’y aurai pas un autre port que le 162 d’utiliser ?
Car c’est cette transition qui ne se fait pas.

La trap arrive bien dans snmptt.log et pas plus loin.

J’ai du mal à voir le problème.
Si quelqu’un sais, je serai le plus heureux.

#6

=>Normalement si tout est en local et si tu as autorisé le loopback, t’as même pas besoin d’écrire des règles supplémentaires, parce que la requête est émis par la machine locale vers la machine locale elle-même (donc le loopback INPUT suffit), et la réponse est renvoyé par la machine locale vers la machine locale elle-même (donc le loopback OUTPUT suffit).

#7

Oui en effet, mais mes traps passent quand même car elles arrivent bien dasn le fichier snmptt.log . Le reel soucis est entre snmptt.log et l’interface centreon.

Je testerai demain de supprimer la règle de SNMP trap, donc la règle INPUT/OUTPUT en loopback devrai prendre sa place. Mais je pense que le problème sera toujours présent car dans tous les cas même si ma règle sur SNMP trap sert à rien, elle autorise en plus du loopback. C’est pas cette règle qui doit poser problème.

J’espere trouver la réponse a ce problème car je tourne en rond :s

Merci

#8

Toujours le même problème ce matin :s

Mes traps SNMP passent bien sur snmptt.log mais pas au dela. Impossible d’avoir l’affichage de mes traps SNMP sur l’interface centreon.

Que puis-je faire de plus que d’autoriser le trafic local,snmp et snmp trap en entré/sortie ?

Y’a t-il un autre port utilisé entre snmptt.log (centTrapHandler) et Centreon ?

Ma configuration est toujours la même qu’au dessus.

Help

Merci

#9

Tu pourrais ajouter des règles LOG pour tracer les paquets bloqués juste avant les règles DROP/REJECT et en fin de chaînes si policy à DROP.

Note : Un jeu de règles est un tout, et quelques règles iptables isolées de leur contexte ne permettent pas de prédire le résultat.

#10

Alors mon soucis aussi c’est que je suis quand même assez novice dans le domaine iptables. Ducou j’ai regardé les doc sur LOG et je ne vois pas trop ce que ça fait et comment le mettre en place.

Avant
$IPTABLES -P INPUT DROP
$IPTABLES -P OUTPUT DROP
$IPTABLES -P FORWARD ACCEPT

???

Mon contexte c’est Centreon et les traps SNMP, je ne suis pas en dehors de mon contexte. Je pense que mon soucis provient de SentTrapHandler non ? Car c’est lui qui fait la transition entre snmptt.log et l’interface de Centreon, c’est ici que ça bloque quand le parefeu est actif.

Merci pour ta réponse

Cordialement
Bon week end

#11

[quote=“flyght”]Avant
$IPTABLES -P INPUT DROP
$IPTABLES -P OUTPUT DROP
$IPTABLES -P FORWARD ACCEPT
???[/quote]
Non. Ces commandes définissent les politiques par défaut des chaînes, pas des règles.

Le contexte dont je parlais est le jeu de règles iptables complet tel qu’affiché par iptables-save.

#12

Et comment utilise-t-on LOG ? Car ce n’est pas très explicite ce qu’il y a sur internet :confused: . Je n’arrive pas bien à voir ce que ça fait.

Je vois ce que iptables-save fait appraitre, c’est tout ce que j’ai mis dans mon fichier.

Merci

Cordialement

#13

man iptables est ton ami.

iptables -A <chaîne> [conditions] -j LOG -log-prefix "prefixe "A chaque paquet vu par la règle et correspondant aux conditions, une ligne avec le préfixe spécifié et les caractéristiques du paquet sera ajoutée dans les logs du noyau consultables avec dmesg ou dans /var/log/kern.log.

#14

Bonjour à tous,

J’ai résolu mon soucis. Je pense que personne aurai forcement trouvé, c’est un détail microscopique dans un décors énorme…

Ma solution, pour ceux à qui cela arrive :

J’ai modifié le type de socket de la NDO, je l’ai passé de unixsocket à tcpsocket et mes traps SNMP passent avec le firewall. (Dans configuration, Centreon, dnodb2.cfg et dans ndodb.cfg)

Ne me demandé pas pourquoi moi même je n’est pas tellement compris.

Car en fait unixsocket correspond à une installation de nagios et centreon sur une seule machine.
Et tcpsocket correspond à une installation ou Nagios et centreon sont sur plusieurs machines.

Voila merci pour tout quand meme :slightly_smiling:

#15

=>merci aussi à toi pour avoir partager la solution :smiley:

#16

iptables n’a aucune incidence sur les sockets Unix, ce n’est pas lui qui bloquait la communication.

#17

Et bien je n’est fait aucune autre modification que ceci donc …

Merci pour vos réponses en tout cas.

SUJET RESOLU