How easy is it for someone to fool a machine into thinking they have the address 127.0.0.1?
I''m using the IP address as a way of detected when a connection is coming from the same machine - allowing me to send messages directly to a location in memory rather than using the networking system - but I want to know how secure it is. If it''s not secure, someone could send a message persuading the game to write stuff to an arbitrary location in memory (thus compromising security).
Superpig
- saving pigs from untimely fates, and when he''s not doing that, runs The Binary Refinery.
Enginuity1 | Enginuity2 | Enginuity3
Fake localhost?
If your using TCP sockets then it should be impossible to fool it because the client and server have to have a connection in which messages are sent back to the clients address to confirm the connection.. not sure if UDP would be safe though
It''s technically possible. I don''t think you can reassign the loopback on Windows, but on Unix/Linux its trivial. It''ll probably break a ton of software, but assuming you can get pasted that barrier, you can change you loopback and give you ip the 127.0.0.1 address.
Even without those steps, it someone could access network resources, they could spoof the address locally, or even setup up a local proxy or redirect on your box and appear to come from the local machine.
Also, if someone can figure how you "verify" the sender, then they could pretend to be you host.
I wouldn''t rely on just the loopback address for verification of source. You should look at some other message passing system if you can. Or use Unix sockets instead of Network sockets to send the data in a socket sort of way.
Interim
Even without those steps, it someone could access network resources, they could spoof the address locally, or even setup up a local proxy or redirect on your box and appear to come from the local machine.
Also, if someone can figure how you "verify" the sender, then they could pretend to be you host.
I wouldn''t rely on just the loopback address for verification of source. You should look at some other message passing system if you can. Or use Unix sockets instead of Network sockets to send the data in a socket sort of way.
Interim
Bind the code that handles that part of your code to your loopback device. Have your same-box client talk to the loopback device specifically for said functionality.
Regardless if someone else changes a real interface to that of 127.0.0.1 or *tries* to route data to the machine in question with the source ip of 127.0.0.1, your loopback device will never see that data if you have things set up normally. It''s a kernel-specific implementation issue.
Even that said, most OSes also have the ability to set strict destination multi-homing ( or insert term of the day for whatever your kernel calls it ). Essentially, not allowing data to be routed from one interface and out another interface and other interface-related policies ( without firewalling per se and I''m not referring to ip forwarding specifically ).
You can also implement a form of authentication on top of that, not solely relying on the loopback address being the only identifying quality.
.zfod
Author
Hmm. But if a machine assigned itself the actual IP address of 127.0.0.1, would it still be able to send packets across the internet? I thought routers were meant to ignore that address or something.
I think what I''ll do is have a random number stored somewhere on the machine (or even in memory - the client/server modules should be in the same address space otherwise it doesn''t work), have the client attach that number to its message, and then have the server check that number to ensure that the client actually is able to access local memory (i.e. is on the same machine).
That would even protect against someone logging onto the machine (SSH or something) and crafting a program to send a packet through the loopback (thus having an OK address), because they wouldn''t be able to get at the random number in memory (unless they had *extreme* inside knowledge of the app, and if they did, I probably couldn''t stop them).
Superpig
- saving pigs from untimely fates, and when he''s not doing that, runs The Binary Refinery.
Enginuity1 | Enginuity2 | Enginuity3
I think what I''ll do is have a random number stored somewhere on the machine (or even in memory - the client/server modules should be in the same address space otherwise it doesn''t work), have the client attach that number to its message, and then have the server check that number to ensure that the client actually is able to access local memory (i.e. is on the same machine).
That would even protect against someone logging onto the machine (SSH or something) and crafting a program to send a packet through the loopback (thus having an OK address), because they wouldn''t be able to get at the random number in memory (unless they had *extreme* inside knowledge of the app, and if they did, I probably couldn''t stop them).
Superpig
- saving pigs from untimely fates, and when he''s not doing that, runs The Binary Refinery.
Enginuity1 | Enginuity2 | Enginuity3
Never completely assume that 127.0.0.1 or any reserved address space could not be routed to you.. different router configuration and OSes handle this in various ways. One should think that reserved/RFC 1918 networks ( deemed unrouteable ) shouldn''t reach your doorstep either, but they do because of these different implementations and policies ( mostly because ISPs can''t incur the cost of an ACL hit on their backbone routers to enforce the policy accurately ).
However what I''m saying is that if you have a vanilla/sane setup you can reasonably assume that you will have a loopback device that never touches the lower layers of the stack, nor will your host accept data destined to 127.0.0.1 via an interface with a valid IP address ( again, assuming a sane setup ).
Even if a rogue host on your LAN decides to try and play games and route data to your critical process running on your box''s 127.0.0.1 addressed loopback device, if you have a sane setup nothing will occur. The only way to reach the loopback device in any sane implementation is local to the host itself because the loopback device is not meant to dip into the lower layers of the network stack.
Again, only bind this privileged functionality to your loopback device and not any publicly addressable interface. Use extra methods of authentication if you deem it necessary.
.zfod
As zfod said, using the localhost IP usually doesn''t touch network hardware. It''s very, very fast. Why bother writing to memory when you can simplify your code by just treating localhost like any other IP and using a socket?
--------------------
You are not a real programmer until you end all your sentences with semicolons; (c) 2000 ROAD Programming
You are unique. Just like everybody else.
"Mechanical engineers design weapons; civil engineers design targets."
"Sensitivity is adjustable, so you can set it to detect elephants and other small creatures." -- Product Description for a vibration sensor
--------------------
You are not a real programmer until you end all your sentences with semicolons; (c) 2000 ROAD Programming
You are unique. Just like everybody else.
"Mechanical engineers design weapons; civil engineers design targets."
"Sensitivity is adjustable, so you can set it to detect elephants and other small creatures." -- Product Description for a vibration sensor
Even if somone did fake their ip as 127.0.0.1 and even if it was routed... when your machine recieved the connection it would try to send the handshake (talking about TCP) back to the hosts ip (127.0.0.1) and it would only get as far as the machine that the host knew as 127.0.0.1 (ie it self) and so would never be able to complete the handshake and connect let alone send data
Author
quote:Original post by Yanroy
As zfod said, using the localhost IP usually doesn't touch network hardware. It's very, very fast. Why bother writing to memory when you can simplify your code by just treating localhost like any other IP and using a socket?
Hmm, is it really that fast? I thought I was skipping a fair amount of networking subsystem by going directly through memory; though it has led to a large amount of abstraction and stuff having to happen, certainly.
Superpig
- saving pigs from untimely fates, and when he's not doing that, runs The Binary Refinery.
Enginuity1 | Enginuity2 | Enginuity3
[edited by - Superpig on August 1, 2003 9:11:52 AM]
You''re not protected against ''localhost spoofing''; so it''s not a safe way of detecting the local machine.
On a unix box, you can install ''ipfilter'' and set it to filter out incoming messages from ''localhost'', but this is not free in terms of performance. You can also trick the RP as well; put this in your rc.local (found in /etc/rc.d/) :
" echo 1 > /proc/sys/net/ipv4/conf/all/rp_filter "
On Windows, I honestly don''t know how that would be handled without incurring some very noticeable overhead (i.e. by filtering using a RAW socket).
-cb
On a unix box, you can install ''ipfilter'' and set it to filter out incoming messages from ''localhost'', but this is not free in terms of performance. You can also trick the RP as well; put this in your rc.local (found in /etc/rc.d/) :
" echo 1 > /proc/sys/net/ipv4/conf/all/rp_filter "
On Windows, I honestly don''t know how that would be handled without incurring some very noticeable overhead (i.e. by filtering using a RAW socket).
-cb
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
