Linux - SecurityThis forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
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?
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.
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
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.
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?
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
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").
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
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
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
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.
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?).
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
(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.
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?
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?
(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?
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.