up vote 0 down vote favorite
share [g+] share [fb]

I am trying to allow snmp traps to be sent to a remote machine for cacti graphing. This is what I have now, but it's not working:

Chain INPUT (policy DROP)
ACCEPT     udp  --  0.0.0.0/0            x.x.x.x      udp dpt:161
ACCEPT     udp  --  0.0.0.0/0            x.x.x.x      udp dpt:162
ACCEPT     udp  --  0.0.0.0/0            x.x.x.x      udp spts:1023:2999

The last line is something someone suggested but it didn't help. I thought this would be simple, and I've done lots of googling, but I've run into a wall.

Thanks for any pointers!

EDIT: Here is the output of iptables -L -n -v:

Chain INPUT (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 ACCEPT     udp  --  *      *       0.0.0.0/0            184.105.134.14      udp spts:1023:2999 
    0     0 ACCEPT     udp  --  *      *       0.0.0.0/0            184.105.135.57      udp spts:1023:2999 
    0     0 ACCEPT     udp  --  *      *       0.0.0.0/0            184.105.135.57      udp dpt:161 
    0     0 ACCEPT     udp  --  *      *       0.0.0.0/0            184.105.134.14      udp dpt:161 
 2678  195K fail2ban-SSH  tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:22 
 2585  188K fail2ban-ssh  tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:22 
37790 5151K ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0           
    0     0 REJECT     all  --  *      *       67.210.96.146        0.0.0.0/0           reject-with icmp-port-unreachable 
 2585  188K ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:22 
   27  8856 DROP       udp  --  *      *       0.0.0.0/0            0.0.0.0/0           udp dpt:67 
    0     0 DROP       udp  --  *      *       0.0.0.0/0            0.0.0.0/0           udp dpt:68 
 229K   77M ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED 
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           state NEW tcp dpt:20 
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           state NEW tcp dpt:21 
 5096  256K ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           state NEW tcp dpt:25 
  695 44360 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           state NEW tcp dpt:53 
  125  6648 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           state NEW tcp dpt:80 
    4   160 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           state NEW tcp dpt:123 
   10   600 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           state NEW tcp dpt:443 
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           state NEW tcp dpt:514 
   63  3780 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           state NEW tcp dpt:110 
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           state NEW tcp dpt:143 
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           state NEW tcp dpt:220 
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           state NEW tcp dpt:993 
    0     0 ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0           state NEW udp dpt:143 
    0     0 ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0           state NEW udp dpt:220 
    0     0 ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0           state NEW udp dpt:993 
    3   144 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           state NEW tcp dpt:995 
   50  3088 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           state NEW tcp dpt:587 
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           state NEW tcp dpt:873 
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           state NEW tcp dpt:5038 
    1    40 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           state NEW tcp dpts:32768:65535 
    0     0 ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0           state NEW udp dpt:20 
    0     0 ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0           state NEW udp dpt:21 
20839 1442K ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0           state NEW udp dpt:53 
86707 6588K ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0           state NEW udp dpt:123 
    1    48 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           state NEW tcp dpt:10000 
 4244  619K ACCEPT     icmp --  *      *       0.0.0.0/0            0.0.0.0/0           state NEW 
18386 1220K LOGDROP    all  --  *      *       0.0.0.0/0            0.0.0.0/0           

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED 

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 ACCEPT     udp  --  *      *       0.0.0.0/0            184.105.134.14      udp dpt:161 
    0     0 ACCEPT     udp  --  *      *       0.0.0.0/0            184.105.134.14      udp dpt:162 
    0     0 ACCEPT     udp  --  *      *       0.0.0.0/0            184.105.135.57      udp dpt:161 
    0     0 ACCEPT     udp  --  *      *       0.0.0.0/0            184.105.135.57      udp dpt:162 
37790 5151K ACCEPT     all  --  *      lo      0.0.0.0/0            0.0.0.0/0           
 279K   82M ACCEPT     all  --  *      eth0    0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED 
29306 2262K ACCEPT     all  --  *      eth0    0.0.0.0/0            0.0.0.0/0           

Chain LOGDROP (1 references)
 pkts bytes target     prot opt in     out     source               destination         
18386 1220K LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0           LOG flags 0 level 4 prefix `\'*IPT*\'' 
18386 1220K DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0           

Chain fail2ban-SSH (1 references)
 pkts bytes target     prot opt in     out     source               destination         
 2585  188K RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0           

Chain fail2ban-ssh (1 references)
 pkts bytes target     prot opt in     out     source               destination         
 2585  188K RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0
link|improve this question
0% accept rate
Have you verified that the remote machine's firewall is allowing the traffic IN? Also, what rules are in your OUTPUT Chain? I noticed that you are listing the INPUT Chain. Is this on the system that is sending traps? You need to open ports in the OUTPUT Chain to do that. – JeffG Mar 1 '11 at 21:40
Are you trying to have the local machine push data to the remote machine running Cacti? Alternately, are you trying to let the machine running Cacti pull data from the local machine? – sciurus Mar 1 '11 at 22:00
It works fine if I shut down iptables, so their firewall doesn't appear to be the issue. Yes, traps are coming from this machine. So I see that my brain was backwards. Would you just add the same lines to the OUTPUT chain? – danielj Mar 1 '11 at 22:05
Could we see the whole of your running firewall, ie the output of iptables -L -n -v? If you're not allowing all OUTPUT traffic automatically, then yes, I think that putting the second of those rules will allow SNMP traps to be sent out from the machine. – MadHatter Mar 1 '11 at 22:22
Ok, I edited my original question to add the output. You can see I added the lines to OUTPUT. But that did not fix the problem. – danielj Mar 1 '11 at 22:33
show 3 more comments
feedback

2 Answers

up vote 2 down vote

As I understand your question you want this machine (the one, on which we fight with iptables) be able to sent traps to a remote server, right?

In that case, the interesting part is the OUTPUT chain, as it is, what regulates fate of packets originating in the box.

Debug step one: shut down iptables and verify that trap sending works. If it doesn't the problem is not with firewall configuration of the SNMP trap source. Do not proceed to step two until you have things working with iptables stopped.

Debug step two: grep -i /etc/services shows a plethora of entries for various SNMP-related things. You may either read the documentation and find out, on which ports your software communicates, or get ingenious. Assuming the latter add a line at the end of the OUTPUT chain configuration, that sends everything to LOGDROP chain. Then start iptables, verify that the rule is there in the OUTPUT chain and make a trap to be sent. Then take a look inside your /var/log/messages and you'll see an entry generated by the LOGDROP, which will tell you, that a packet from the local machine to the remote machine using protocol UDP, destined to port XXX has been dropped. Bingo!

Debug step three. Add to the OUTPUT chain rules (above the LOGDROP entry) a line, that ACCEPTs outgoing UDP packets (-p udp) to the remote server (-d <IP_ADDRESS>) on port XXX (--dport XXX) determined in Debug step three. Verify (iptables -L -n -v), that the rule is there. Make a trap to be sent and see it arrive safely at the destination. If it does not arrive, your software may communicate on more than one port, but then GOTO Debug step two. In the pathological case that you should determine large (dozens, hundreds...) ports being used by the software, and if your security policy permits that, you may just allow all (or all UDP) outgoing traffic from this box to the remote machine.

Profit ;)

link|improve this answer
Thank you, @pawel. Step one works fine. Can you look at my OUTPUT section in the question? It seems to me that is allowing all traffic by being an ACCEPT policy and not having any denies. Which I realize makes it useless and redundant, but we realized yesterday that was the case and didn't want to make it more restrictive while we are trying to figure this out. Thanks. – danielj Mar 2 '11 at 17:22
@user72687 You are welcome :). You are right, that your OUTPUT chain allows all and any packets to be sent by the box, so it's equivalent to no rules and ACCEPT policy. However, it is not useless, as it serves to let the machine do (part of) its job, i.e. send packets to somewhere. Once you have the system working you may tighten the rules according to your security policy. – Paweł Brodacki Mar 4 '11 at 6:25
feedback
up vote 1 down vote

I removed the specific ip addresses from the INPUT rules and just opened 161 and 162 udp to the world, and it works now. So that tells me that the guy that is supposed to receive the traps gave me the wrong ip addresses for his machines. D'oh! Thank you, everyone, for your attempts to help solve a problem with a variable I hadn't accounted for.

Daniel

link|improve this answer
feedback

Your Answer

 
or
required, but never shown
discard

Not the answer you're looking for? Browse other questions tagged or ask your own question.