Home > Uncategorized > Logging traffic at the iptables level and exclude multiple subnets that can’t be noted in CIDR

Logging traffic at the iptables level and exclude multiple subnets that can’t be noted in CIDR

ULOG and NFLOG are a better solution to this. LOG is useful for some minor stuff.

The LOG option in iptables is quite useful when dealing with packets traversing the stack.  For instance, I was attempting to sniff traffic with tcpdump that was sourced and destined for the bound local IP of the interface.  Of course, tcpdump didn’t see any of the packets because the network stack (in the kernel) was turning the packets back before they reached the place where tcpdump hooks into (low level).

Here is a good diagram that explains the linux kernel network stack, and here is a good diagram on how iptables works. You can correlate items on the iptables diagram to the kernel network stack diagram to understand how they interact. This is why tcpdump/pcap, which hooks into (unknown kernel level networking class) awaiting packets, does not see packets sourced and destined for the IP on the same interface.

Since I was curious if the packets were hitting the ipt_NETFLOW iptables module, all I really cared about was checking whether they arrived to iptables without issue.  LOG allowed me to do this, but I still had a problem.

I have two sites, both with subnets that are far away from each other, 192.168.10.0/24 and 192.168.100.0/24 (for instance).  I wished to exclude both sites’ traffic from a LOG option in iptables.  Seems pretty trivial when dealing with a rule set.  If you can’t drop the packets at rule 0, then drop it at rule 1, etc.  However, since the LOG option, well, logs, exclusions can not be done without dropping packets; which is not at all what I want to do.

In iptables, there are various ways to qualify packets, such as source/destination IP address, src/dst port, and a large variety of other things; the problem I faced is simple.  The source IP qualifier [what is really termed a “match”] (-s) and/or destination IP qualifier (-d), and/or the src/dst port qualifiers (–sport, –dport) do not take any parameter other than a single host description, such as CIDR notation.  There is no parsing of comma-separated lists for instance, and no clean way exclude multiple subnets or port ranges.  “Just add two statements in the same line,” you might think.  Wrong.  This fails.

So, quite simply, we can complement the -s, -d, –sport, –dport, with another qualifier.  The handy iprange or multiport match extensions.  I expect you can read the iptables man page, so I won’t go into great detail, but here is an example:

I want to LOG packets that arrive to iptables on INPUT, but exclude two subnets: 192.168.10.0/24 and 192.168.100.0/24.

-A INPUT -s ! 192.168.10.0/24 -m iprange ! --src-range 192.168.100.1-192.168.100.254 -j LOG

To note, I find it much easier to deal with the iptables config file directly than just adding random rules at the command-line. On CentOS/RHEL this lives at /etc/sysconfig/iptables. So just copy that file for backup, and merry editing.

P.S. I hate the term “supernet” and all of its verb tenses/forms.

Advertisements
  1. Sudhir
    March 1, 2012 at 12:49 am

    Thanks for sharing this info. I want exclude 3 subnets i.e. 10.0.0.0/8, 172.16.0.0/16, 192.168.0.0/24, i can exclude the first subnet using -s ! 10.0.0.0/8 and second subnet using using iprange ! –src-range 172.16.0.0/16, how do i exclude the third subnet ??

    • March 1, 2012 at 7:29 am

      That’s an interesting questions that I don’t have an answer to. To be honest, it seems like it would be a reasonable request for the developers. But I will look around later and see if I can find anything.

      • March 1, 2012 at 3:01 pm

        It seems the best thing to do is use a more robust mechanism: ULOG or NFLOG. ULOG sends packets to a user space daemon called ulogd. NFLOG “creates a fake device” which can be capped.

        [14:49] == branded [266b@gateway/web/freenode/ip.] has joined #Netfilter
        [14:49] -ChanServ- [#Netfilter] Observe the FAQ: http://tinyurl.com/myaqo6
        [14:51] {branded}  hello, is it possible to exclude two or more non-adjacent subnets from a LOG rule?  I figure out that two non-adjacent subnets can be excluded by using -s ! in combination with -m iprange ! --src-range
        [14:51] {branded}  but how do I exclude more than two?
        [14:52] {branded}  it seems that this condition (to handle more than a single subnet in with the -s or -m iprange --src-range) would be unique to LOG statements
        [14:52] {branded}  any assistance is appreciated
        [14:52] == darkbasic_ [~quassel@host37-245-static.119-2-b.business.telecomitalia.it] has joined #Netfilter
        [14:53] {comps}  "adjacent"?
        [14:53] == darkbasic [~quassel@host37-245-static.119-2-b.business.telecomitalia.it] has quit [Ping timeout: 246 seconds]
        [14:53] {comps}  how can a subnet be "adjacent" to another? like 1.2.1.0/24 and 1.2.2.0/24 ?
        [14:54] {branded}  -A INPUT -s ! 192.168.10.0/24 -m iprange ! --src-range 192.168.100.1-192.168.100.254 -j LOG
        [14:54] {branded}  or how a /22 could encompass the "addresses" of two /24
        [14:54] {comps}  well, you can make a new chain
        [14:54] {comps}  and o -s ip_you_dont_want -j RETURN
        [14:54] {comps}  with -j LOG at the bottom
        [14:54] {comps}  s/ o /  /
        [14:56] {branded}  I see, I'm not familiar enough with the syntax right now to understand what you mean by a CHAIN, but I suspect it's a single rule in the main chain, that can be made up of other rules?
        [14:56] {comps}  yes, kind of like a function
        [14:57] {comps}  see man iptables, -N parameter
        [14:57] {branded}  so the logging only takes place in the side chain only?
        [14:57] {branded}  this is what you recommend?
        [14:58] {branded}  Thanks I'll look into using a chain!
        [14:58] {comps}  I recommend not using a LOG for serious logging
        [14:59] {comps}  see ULOG and NFLOG
        [14:59] {branded}  which is a module?
        [14:59] {comps}  ?
        [14:59] {comps}  20:58 { comps}  see ULOG and NFLOG  {--- in  man iptables
        [14:59] {branded}  sorry, okay thanks for your recommendation
        [15:00] {branded}  wow this is great
        [15:00] {branded}  thanks
        [15:01] {comps}  pcap logging is what I consider useful
        [15:17] {branded} comps: which do you recommend?  Which is more reliable?  Have you used PF_RING?
        [15:20] {comps} well I just --nflog-group 123 and then use userspace to make a .pcap from it
        
  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: