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.
I've been searching the web on this argument but all it talks about is UDP. I have no doubt that a UDP packet can have a fake localhost source address. But what happens with TCP? I think a SYN packet can arrive with a fake localhost source address, but then the SYN ACK will be sent to localhost and never received by the attacker. Am I right?
If I write a servlet that checks wether the remote address is 127.0.0.1, would it be vulnerable?
I've been searching the web on this argument but all it talks about is UDP. I have no doubt that a UDP packet can have a fake localhost source address. But what happens with TCP? I think a SYN packet can arrive with a fake localhost source address, but then the SYN ACK will be sent to localhost and never received by the attacker. Am I right?
If I write a servlet that checks wether the remote address is 127.0.0.1, would it be vulnerable?
The ARP table for Linux does not have the lo interface entry and hence it will not allow you to spoof the entry for "lo" interface (lo is the internal loopback interface, which is virtual).
Well, I can tell you this much at least: If I spoof a SYN packet with source IP 127.0.0.1 sending it from my laptop to my desktop via Wi-Fi, I can see the packet arrive at my desktop (using tcpdump). I can NOT, however, log the packet with Netfilter/iptables on the desktop for some reason. EDIT: I'll check if I can see the any ACK get generated on the desktop when I get back, gotta go out to take care of something. Will be back later today.
Okay I was able to look at this a bit more. I don't really have much new information to share, though. I can confirm that the spoofed packet (source address 127.0.0.1) isn't causing a SYN/ACK to be generated on the target machine. I checked the NIC and loopback on the target using tcpdump. The spoofed packet is clearly visible to tcpdump on the target machine, yet it doesn't show-up in the iptables logs. Can anyone shed some light as to what is happening to the spoofed packet? Why doesn't it reach Netfilter? Why doesn't it generate a SYN/ACK?
FWIW, the target machine I tested with is running Linux 2.6.22.
Quote:
Originally Posted by irey
then the SYN ACK will be sent to localhost [...] Am I right?
I don't have the complete picture yet, but (as you can see above) my tests show the answer to this question is: NO.
I'm not surprised. It appears that the IP layer is smart enough to realise that the packet is spoofed since obviously the localhost address shouldn't be received on eth0 or any interface other than lo. Maybe tcpdump is working on the ethernet layer so it sees the packet before it is discarded.
Anyway your reply shows that it is secure. If the SYN ACK hasn't been generated then the connection hasn't beene stablished and any following packets will be discarded.
I was fearing that a potential attacker could send the SYN, ignore the never-received-SYN-ACK and finally send an ACK and a HTTP request. Since the connection hasn't been established, his attack won't work.
I don't know how you tested it, but I don't want to learn. Thanks for your reply.
Some internet searching showed me that your test fake packet was detected by the "reverse path filtering", a kernel feature that drops packets received on a wrong interface. It may be configured through some sysctl variables:
Some internet searching showed me that your test fake packet was detected by the "reverse path filtering", a kernel feature that drops packets received on a wrong interface. It may be configured through some sysctl variables:
net/ipv4/route.c:1769
if (MULTICAST(saddr) || BADCLASS(saddr) || LOOPBACK(saddr))
goto martian_source;
This is ip_route_input_slow(), which is called after a packet is received. There is also a comment at the beggining of this function saying that spoofing attacks are prevented here (I guess the rp_filter stuff applies to external IP addresses only, not 127.0.0.1).
By taking a look at the martian_source tag I see that the strange packet may be logged at warning level. However you may not see it in your kernel logs since it depends on many conditions, including kernel config.
Now I feel more than safe that my servlet won't be called from the outside world. Thanks!
Hi there. Just following up on this (sorry for the delay).
Based on your previous post, I enabled martian logging and re-tested.
To enable martian logging I did a (on the target):
Code:
echo 1 > /proc/sys/net/ipv4/conf/all/log_martians
The spoofed packet now gets logged (regardless of whether the port it hits has something listening on it or not).
This is what /var/log/syslog looks like upon packet arrival:
Code:
Dec 8 20:18:12 labrat kernel: [ 2449.241998] martian source 192.168.1.101 from 127.0.0.1, on dev eth0
Dec 8 20:18:12 labrat kernel: [ 2449.242011] ll header: 03:0E:94:bc:8c:03:03:e8:e5:b3:c8:bf:08:00
So I confirm Linux seems to properly deal with spoofed packets having a 127.0.0.1 source address.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.