GNU/Linux, Seguridad

Debugging iptables

by  •  • 0 Comments

Today I had to debug iptables while reviewing a customer issue, which basically had problems with a VPN that allowed traffic from the client to the server, but not to any other machine in the server network.
A quick look at tcpdump and kern.log showed that the issue was in iptables configuration, but…which rule was the culprit?

I have normally debugged iptables by looking at the whle set of rules, and when this is not possible due to a large amount of rules and chains, then isolating traffic and looking at the packet /bytes counters (iptables -L chain -n -v)

But at this point I could not isolate traffic, and decided to look for information, as there had to be anotehr way of finding which rule was causing this. Finally I found this article

In my cause, I just had to(I had not to load modules as it was done per default):

  1. Add a rule for send traffic to raw table and TRACE target
  2. Generate some traffic for seeing the rules navigation
  3. tail -f kern.log (I grepped the MAC for seeing only affected ones)

Then I could see something like this:

Apr 22 12:58:06 foobar kernel: [967185.974770] TRACE: filter:fdns:return:5 IN=tap0 
OUT=eth0 MAC=00:11:22:33:44:55:66:77:88:99:AA:BB:CC:DD SRC=192.168.161.2
 DST=192.168.2.250 LEN=84 TOS=0x00 PREC=0x00 TTL=63 ID=0 DF PROTO=ICMP TYPE=8 CODE=0 ID=14245 SEQ=2066 MARK=0x1
Apr 22 12:58:06 foobar kernel: [967185.974783] TRACE: filter:FORWARD:rule:9 IN=tap0
 OUT=eth0 MAC=00:11:22:33:44:55:66:77:88:99:AA:BB:CC:DD SRC=192.168.161.2
 DST=192.168.2.250 LEN=84 TOS=0x00 PREC=0x00 TTL=63 ID=0 DF PROTO=ICMP TYPE=8 CODE=0 ID=14245 SEQ=2066 MARK=0x1
Apr 22 12:58:06 foobar kernel: [967185.974796] TRACE: filter:fobjects:return:1 IN=tap0 
OUT=eth0 MAC=00:11:22:33:44:55:66:77:88:99:AA:BB:CC:DD SRC=192.168.161.2
 DST=192.168.2.250 LEN=84 TOS=0x00 PREC=0x00 TTL=63 ID=0 DF PROTO=ICMP TYPE=8 CODE=0 ID=14245 SEQ=2066 MARK=0x1
Apr 22 12:58:06 foobar kernel: [967185.974809] TRACE: filter:FORWARD:rule:10 IN=tap0 
OUT=eth0 MAC=00:11:22:33:44:55:66:77:88:99:AA:BB:CC:DD SRC=192.168.161.2
 DST=192.168.2.250 LEN=84 TOS=0x00 PREC=0x00 TTL=63 ID=0 DF PROTO=ICMP TYPE=8 CODE=0 ID=14245 SEQ=2066 MARK=0x1
Apr 22 12:58:06 foobar kernel: [967185.974823] TRACE: filter:fglobal:rule:2 IN=tap0
 OUT=eth0 MAC=00:11:22:33:44:55:66:77:88:99:AA:BB:CC:DD SRC=192.168.161.2
 DST=192.168.2.250 LEN=84 TOS=0x00 PREC=0x00 TTL=63 ID=0 DF PROTO=ICMP TYPE=8 CODE=0 ID=14245 SEQ=2066 MARK=0x1
Apr 22 12:58:06 foobar kernel: [967185.974836] TRACE: filter:drop:rule:1 IN=tap0
 OUT=eth0 MAC=00:11:22:33:44:55:66:77:88:99:AA:BB:CC:DD SRC=192.168.161.2
 DST=192.168.2.250 LEN=84 TOS=0x00 PREC=0x00 TTL=63 ID=0 DF PROTO=ICMP TYPE=8 CODE=0 ID=14245 SEQ=2066 MARK=0x1

So I could see straight forward which rule (the second in fglobal here) I had to look at in order to see why traffic was being blocked

Deja un comentario