LinuxQuestions.org
Welcome to the most active Linux Forum on the web.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Security
User Name
Password
Linux - Security This forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.

Notices

Reply
 
Search this Thread
Old 07-07-2013, 02:05 PM   #1
Azrael84
Member
 
Registered: Nov 2012
Posts: 55

Rep: Reputation: Disabled
iptables log understanding help


I have a couple of logs I don't quite understand

Code:
[21617.117590] netfilter:in dropped: IN=eth1 OUT= MAC=c4:17:fe:65:51:f8:00:26:44:59:a6:10:08:00 SRC=192.168.1.254 DST=192.168.1.79 LEN=352 TOS=0x00 PREC=0x00 TTL=64 ID=7198 PROTO=UDP SPT=1900 DPT=47286 LEN=332
So this is incoming from the router to my network address...what is the purpose of the packet? is it an issue that I'm dropping it?

Code:
[21896.728247] netfilter:in dropped: IN=eth1 OUT= MAC= SRC=192.168.1.79 DST=192.168.1.255 LEN=72 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=57621 DPT=57621 LEN=52
From google, I believe this is Spotify broadcasting its existence across the network to find other clients. What I wonder if how it can have a SRC IP matching my IP yet also be an incoming packet to my PC? Is this just because it is broadcast so everyone on the network recieves it, even the original sender??

Lastly, for a home PC running Ubuntu 12.04 behind a router, should I have iptables rules that allow all local network address? or would this cause a problem because of spoofed/bogus packets (i.e. packets pretending to be local but coming from the internet). Is there a rule in iptables that could guard against spoofed packets yet allowing me to accept the genuine local traffic?

Thanks
 
Old 07-07-2013, 04:05 PM   #2
Ser Olmy
Senior Member
 
Registered: Jan 2012
Distribution: Slackware
Posts: 1,956

Rep: Reputation: Disabled
Quote:
Originally Posted by Azrael84 View Post
Code:
[21617.117590] netfilter:in dropped: IN=eth1 OUT= MAC=c4:17:fe:65:51:f8:00:26:44:59:a6:10:08:00 SRC=192.168.1.254 DST=192.168.1.79 LEN=352 TOS=0x00 PREC=0x00 TTL=64 ID=7198 PROTO=UDP SPT=1900 DPT=47286 LEN=332
So this is incoming from the router to my network address...what is the purpose of the packet? is it an issue that I'm dropping it?
Traffic from UDP port 1900 is most likely related to the "Universal Plug and Play" function in your router. The destination port seems to be a random high port, so it's probably replying to an earlier request from your system, but one that has timed out with the iptables connection tracker.

Quote:
Originally Posted by Azrael84 View Post
Code:
[21896.728247] netfilter:in dropped: IN=eth1 OUT= MAC= SRC=192.168.1.79 DST=192.168.1.255 LEN=72 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=57621 DPT=57621 LEN=52
From google, I believe this is Spotify broadcasting its existence across the network to find other clients. What I wonder if how it can have a SRC IP matching my IP yet also be an incoming packet to my PC? Is this just because it is broadcast so everyone on the network recieves it, even the original sender??
Yes, that's exactly what's happening. Note that there's no MAC address involved, so this happens entirely within the local IP stack on the host. A switch will not send a broadcast (or indeed any frame) to the port from which it originated.

Quote:
Originally Posted by Azrael84 View Post
Lastly, for a home PC running Ubuntu 12.04 behind a router, should I have iptables rules that allow all local network address? or would this cause a problem because of spoofed/bogus packets (i.e. packets pretending to be local but coming from the internet). Is there a rule in iptables that could guard against spoofed packets yet allowing me to accept the genuine local traffic?
To protect hosts on your LAN from packets with a spoofed source address, you should have your router do ingress filtering/reverse path verification. If that's not possible, a DROP rule matching all local addresses (except your router) and the MAC address of your router should do the trick. You would probably have to implement that as two rules; one allowing your router to communicate using its own address, and one dropping any spoofed packets coming from the router.
 
Old 07-07-2013, 04:31 PM   #3
Azrael84
Member
 
Registered: Nov 2012
Posts: 55

Original Poster
Rep: Reputation: Disabled
Thanks for the reply, very enlightening!

Quote:
To protect hosts on your LAN from packets with a spoofed source address, you should have your router do ingress filtering/reverse path verification.
Not sure if it's possible or not, I can't see such options in the router settings, but maybe it's there by default...

Code:
 a DROP rule matching all local addresses (except your router) and the MAC address of your router should do the trick. You would probably have to implement that as two rules; one allowing your router to communicate using its own address, and one dropping any spoofed packets coming from the router.
I'd be interested in knowing roughly what this would look like for educational purposes if you wouldn't mind spelling it out? I found this on another website:

Code:
SPOOF_IPS="0.0.0.0/8 127.0.0.0/8 10.0.0.0/8 172.16.0.0/12 192.168.0.0/16 224.0$
for ip in $SPOOF_IPS
do
 iptables -A INPUT -i eth1  -s $ip -j DROP
 iptables -A OUTPUT -o eth1 -s $ip -j DROP
done
where eth1 is the wireless laptop network card that I connect through. However, it kills my internet connection....probably not surprisingly since my internal IP is 192.168.1.79 so the output rule stops me connecting to anything.....Maybe this rule-set was meant for webservers or something?

I could change it by scrapping OUTPUT bit altogether perhaps and maybe having an accept rule for the INPUT from the router IP higher up in the chain?

Last edited by Azrael84; 07-07-2013 at 04:34 PM.
 
Old 07-07-2013, 05:07 PM   #4
Ser Olmy
Senior Member
 
Registered: Jan 2012
Distribution: Slackware
Posts: 1,956

Rep: Reputation: Disabled
Quote:
Originally Posted by Azrael84 View Post
I'd be interested in knowing roughly what this would look like for educational purposes if you wouldn't mind spelling it out?
Well, assume a local IP network of 192.168.1.0/24 with 192.168.1.1 as the gateway (router).

If the MAC address of 192.168.1.1 is 00:11:22:33:44:55, any ethernet frame containing a packet originating from the Internet would have that MAC address in the source address field. We should NEVER see a packet from the local network in a frame with that MAC address in the source address field, except for packets coming from the router itself.

The rule allowing frames with packets from the router would look something like this:
Code:
iptables -A INPUT -s 192.168.1.1/32 -m mac --mac-source 00:11:22:33:44:55 -m state --state ESTABLISHED,RELATED -j ACCEPT
As you can see, I've restricted it to match ESTABLISHED and RELATED traffic, which will allow return traffic from the Internet as well as remote management of the router itself.

It will however block any connections initiated by the router itself, including SNMP traps and remote logging, AND any traffic from the Internet to local hosts through forwarded ports, as they match the NEW state. Additional rules would have to be created to allow any such traffic.

With this rule in place, a general rule blocking spoofed traffic can be added:
Code:
iptables -A INPUT -s 192.168.1.0/24 -m mac --mac-source 00:11:22:33:44:55 -j DROP
Quote:
Originally Posted by Azrael84 View Post
I found this on another website:

Code:
SPOOF_IPS="0.0.0.0/8 127.0.0.0/8 10.0.0.0/8 172.16.0.0/12 192.168.0.0/16 224.0$
for ip in $SPOOF_IPS
do
 iptables -A INPUT -i eth1  -s $ip -j DROP
 iptables -A OUTPUT -o eth1 -s $ip -j DROP
done
where eth1 is the wireless laptop network card that I connect through. However, it kills my internet connection....probably not surprisingly since my internal IP is 192.168.1.79 so the output rule stops me connecting to anything.....Maybe this rule-set was meant for webservers or something?
It was probably meant for a system handling only non-NATed Internet traffic, hence the wholesale blocking of the entire RFC 1918 (private) IP range. I believe blocking the 0.0.0.0/8 and 127.0.0.0/8 networks is redundant, as the IP stack already treats addresses in these networks as invalid ("martians").
 
Old 07-07-2013, 05:56 PM   #5
Azrael84
Member
 
Registered: Nov 2012
Posts: 55

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by Ser Olmy View Post
Well, assume a local IP network of 192.168.1.0/24 with 192.168.1.1 as the gateway (router).

If the MAC address of 192.168.1.1 is 00:11:22:33:44:55, any ethernet frame containing a packet originating from the Internet would have that MAC address in the source address field. We should NEVER see a packet from the local network in a frame with that MAC address in the source address field, except for packets coming from the router itself.

The rule allowing frames with packets from the router would look something like this:

Code:
iptables -A INPUT -s 192.168.1.1/32 -m mac --mac-source 00:11:22:33:44:55 -m state --state ESTABLISHED,RELATED -j ACCEPT
As you can see, I've restricted it to match ESTABLISHED and RELATED traffic, which will allow return traffic from the Internet as well as remote management of the router itself.

It will however block any connections initiated by the router itself, including SNMP traps and remote logging, AND any traffic from the Internet to local hosts through forwarded ports, as they match the NEW state. Additional rules would have to be created to allow any such traffic.


With this rule in place, a general rule blocking spoofed traffic can be added:
Code:
iptables -A INPUT -s 192.168.1.0/24 -m mac --mac-source 00:11:22:33:44:55 -j DROP
Why not just allow NEW connections from router too? (since we believe it's the router not spoofed?). Will the lack of SNMP cause issues?

Given that my default INPUT policy is DROP do I need a third rule to actually allow the 192.168.1.0/24 packets which don't have the router mac address? i.e. just

Code:
iptables -A INPUT -s 192.168.1.0/24  -j ACCEPT
coming third in the chain?

I also normally use
Code:
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
Do I still need the first of your rules?
 
Old 07-07-2013, 06:06 PM   #6
Azrael84
Member
 
Registered: Nov 2012
Posts: 55

Original Poster
Rep: Reputation: Disabled
Also, examing my logs I see packets like (my gateway is 192.168.1.254)

Code:
[29628.831435] netfilter:in dropped: IN=eth1 OUT= MAC=c4:17:fe:65:51:f8:00:26:44:59:a6:10:08:00 SRC=192.168.1.254 DST=192.168.1.79 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=9768 PROTO=TCP SPT=80 DPT=52239 WINDOW=4096 RES=0x00 ACK URGP=0
but also

Code:
[22687.367153] netfilter:in dropped: IN=eth1 OUT= MAC=01:00:5e:7f:ff:fa:00:26:44:59:a6:10:08:00 SRC=192.168.1.254 DST=239.255.255.250 LEN=319 TOS=0x00 PREC=0x00 TTL=1 ID=7380 PROTO=UDP SPT=1834 DPT=1900 LEN=299
How can both come from the router SRC=192.168.1.254, yet have different MAC addresses?

EDIT: Actually I see I realize now MAC=dest mac : src mac: payload

Last edited by Azrael84; 07-07-2013 at 06:15 PM.
 
Old 07-07-2013, 06:16 PM   #7
Ser Olmy
Senior Member
 
Registered: Jan 2012
Distribution: Slackware
Posts: 1,956

Rep: Reputation: Disabled
Quote:
Originally Posted by Azrael84 View Post
Why not just allow NEW connections from router too? (since we believe it's the router not spoofed?). Will the lack of SNMP cause issues?
No particular reason, I just generally follow the principle that everything should be blocked except services that are needed.

If you haven't configured your router to send SNMP traps to a trap receiver, blocking SNMP traps will have no undesired effects.

Quote:
Originally Posted by Azrael84 View Post
Given that my default INPUT policy is DROP do I need a third rule to actually allow the 192.168.1.0/24 packets which don't have the router mac address? i.e. just

Code:
iptables -A INPUT -s 192.168.1.0/24  -j ACCEPT
coming third in the chain?
Correct.

Quote:
Originally Posted by Azrael84 View Post
I also normally use
Code:
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
Do I still need the first of your rules?
The match criteria in your rule is a superset of my first rule, as they will allow any packet that is deemed part of an existing connection, regardless of MAC address. With your rule, you're still theoretically vulnerable to session hijacking attempts using spoofed addresses.
 
Old 07-07-2013, 06:54 PM   #8
Azrael84
Member
 
Registered: Nov 2012
Posts: 55

Original Poster
Rep: Reputation: Disabled
Thanks again. You've been very very helpful..

I've read elsewhere the suggestion of just doing

iptables -I INPUT -i eth0 -s 192.168.0.0/16 -j DROP
iptables -I FORWARD -i eth0 -s 192.168.0.0/16 -j DROP

aside from the obvious problems (not allowing router etc), selecting via
the interface just wouldn't work right? For me eth1 is wireless card, and I think
eth0 is just a wired network card....so everything is going to come through eth1 interface??
(Again I don't know if these rules are for webservers/routers or something else where one interface is outward facing
and the other faces the LAN?).
 
Old 07-07-2013, 07:21 PM   #9
Ser Olmy
Senior Member
 
Registered: Jan 2012
Distribution: Slackware
Posts: 1,956

Rep: Reputation: Disabled
Quote:
Originally Posted by Azrael84 View Post
I've read elsewhere the suggestion of just doing

iptables -I INPUT -i eth0 -s 192.168.0.0/16 -j DROP
iptables -I FORWARD -i eth0 -s 192.168.0.0/16 -j DROP

aside from the obvious problems (not allowing router etc), selecting via
the interface just wouldn't work right? For me eth1 is wireless card, and I think
eth0 is just a wired network card....so everything is going to come through eth1 interface??
Right. The interface selector will work fine on any system, it's just that is doesn't make much sense to use it unless there's actually more than one active interface.

Quote:
Originally Posted by Azrael84 View Post
(Again I don't know if these rules are for webservers/routers or something else where one interface is outward facing
and the other faces the LAN?).
The use of the FORWARD chain is a giveaway. That chain only processes packets that have a destination (IP) address not matching any local address, and that means we're talking about a router.
 
Old 07-07-2013, 07:40 PM   #10
Azrael84
Member
 
Registered: Nov 2012
Posts: 55

Original Poster
Rep: Reputation: Disabled
If I still wanted to keep my

Code:
 iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
rule (I use it for other things)...would it be fine so long as your three rules came before it?
That way all the packets with internal IP yet external (router) macs would have been dropped already
...established/related or otherwise.

Or does conntrack not work in the chain like that?
 
Old 07-08-2013, 05:48 AM   #11
Azrael84
Member
 
Registered: Nov 2012
Posts: 55

Original Poster
Rep: Reputation: Disabled
Also, how about the log

Code:
netfilter:in dropped: IN=eth1 OUT= MAC=c4:17:fe:65:51:f8:00:26:44:59:a6:10:08:00 SRC=192.168.1.254 DST=192.168.1.79 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=9768 PROTO=TCP SPT=80 DPT=52239 WINDOW=4096 RES=0x00 ACK URGP=0
This is from router to me getting dropped...is it just another instance of a previously established connection getting timed out by conntrack so now dropped?

My logs are clogged with such things like

Code:
netfilter:in dropped: IN=eth1 OUT= MAC=c4:17:fe:65:51:f8:00:26:44:59:a6:10:08:00 SRC=108.160.162.35 DST=192.168.1.79 LEN=218 TOS=0x00 PREC=0x00 TTL=51 ID=40991 DF PROTO=TCP SPT=80 DPT=46121 WINDOW=31 RES=0x00 ACK PSH URGP=0
(i.e. dropbox in this case) ... again just a timed out conntrack from a previous connection? (I get reems of this stuff clogging up the logs each day. Google/Akamai etc).

Finally, is there anyway I could get Skype and other things to work without using conntrack?

I know for http (https replacing with 443) I could just do

Code:
iptables -A OUTPUT  -p tcp --dport 80 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A INPUT  -p tcp --sport 80 -m state --state ESTABLISHED -j ACCEPT
and similarly probably for DNS/WHOIS etc, rather than the lazy way of using conntrack....but I'm not sure for Skype/bittorrent/spotify, don't they pick random high ports?
 
  


Reply

Tags
iptables


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
I Need Help Understanding IPTables Bhuvana77 Linux - Networking 3 07-22-2010 06:25 AM
understanding auth.log mrmnemo Linux - Newbie 3 04-28-2010 06:42 PM
Understanding auth.log aspedisca Linux - Security 6 01-11-2009 12:03 AM
Need help understanding log entries rbees Linux - Newbie 4 12-14-2008 01:32 PM
Understanding iptables Buckyjunior Linux - Networking 3 03-07-2004 06:18 AM


All times are GMT -5. The time now is 01:45 PM.

Main Menu
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration