iptables log understanding help
 

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

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?

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

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.

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.

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.

Thanks for the reply, very enlightening!

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...

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:

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?

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: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:
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").

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

coming third in the chain?

I also normally use Do I still need the first of your rules?

Also, examing my logs I see packets like (my gateway is 192.168.1.254)

but also

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

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.

Correct.

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.

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?).

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.

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.

If I still wanted to keep my

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?

Also, how about the log

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

(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

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?