Can any data exchanged on a local machine using the loopback IP 127.0.0.1 (localhost) be packet sniffed if the PC is also connected to a network (wireless or landline)?
Would like to know if the loopback, as a means of interprocess communication for locally running processes, can be regarded as a secure means of exchanging data (i.e., not privy to ease-dropping by anyone that resides externally on the network with a packet sniffer program).
This question is being asked in respect to all the pertinent OS platforms:
Win2K/WinXP
Vista
Windows 7
Mac OS X
Linux
Yes, this is secure.
As VBNight stated, the traffic never hits the wire or air.
But, you can actually sniff localhost traffic on your local machine. For example on my linux box I did the following:
sudo tcpdump -i lo
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on lo, link-type EN10MB (Ethernet), capture size 96 bytes
15:29:58.056585 IP localhost.56010 > localhost.16001: S 3572335637:3572335637(0) win 32792 <mss 16396,sackOK,timestamp 132126218 0,nop,wscale 6>
15:29:58.056604 IP localhost.16001 > localhost.56010: R 0:0(0) ack 3572335638 win 0
15:29:59.026016 IP localhost.41664 > localhost.41664: UDP, length 1
15:29:59.026346 IP localhost.41664 > localhost.41664: UDP, length 1
15:29:59.126838 IP localhost.41664 > localhost.41664: UDP, length 1
15:29:59.127486 IP localhost.41664 > localhost.41664: UDP, length 1
So, you can use it to sniff your own traffic/IPC messages, but nobody else can see it on the network.
This is a very common case in systems to use a protocol like TCP or UDP for local IPC over the lo interface.
It should be safe from packet sniffing off the network because the traffic never goes on the wire (or airwaves).
A process on that local machine could sniff the packets tho.
You can use RawCap (a raw socket sniffer) to sniff localhost traffic in Windows. RawCap will create a pcap file that you can load into Wireshark, NetworkMiner or whatever you'd like.
You'll find more info on this StackOverflow thread:
Sniffer for localhost (Windows OS)
I'm pretty sure that popular packet sniffers can't sniff the loopback interface (a cause of much grief and annoyance when debugging stuff on localhost).
The loopback interface can be regarded as secure with respect to the external network. It isn't secure within the same host.
The answers so far are correct, but I will phrase it a different way. It is possible to sniff the loopback adapter communications on the localhost itself, but it usually requires special drivers depending on the operating system. Loopback communications is safe from external sniffers though.
I have had cases where I needed to sniff loopback communications and it was not easy to setup, but it was possible (at least on Windows and I would bet so with Linux as well).
Related
I am sending packets to a Windows network card (eth1) using the Linux sendto() function and a RAW socket (socket(AF_INET, SOCK_RAW, IPPROTO_RAW);). However, although the packets are addressed to the IP address of the network card, the host OS appears to "ignore" the packets.
For example, the network card has IP 192.168.1.2, and my userspace application sends a network packet containing a ping addressed to 192.168.1.2. I can observe in Wireshark the ping arrive on the network device at 192.168.1.2, however no reply is generated. The TTL on the ping is non-zero, so I'm lost as to why the host OS would appear to "ignore" packets destined for it.
Equivalently, if I create a UDP socket and bind it listening to 192.168.1.2 on port 5050, and then send a userspace UDP packet addressed to 192.168.1.2 on port 5050, the packet is never delivered to the port.
What would cause a packet to be ignored by the network card that receives it?
Is there any socket flag needed if I'm sending packets in from userspace (over a custom IP tunnel) to force processing of the packets, as if they came from a router?
The issue turned out to be the native windows firewall, disabling the firewall fixed this issue.
In addition, if republishing network packets on a network device, if a single device (mac addr) is publishing multiple ip packets from various source ips, windows may filter out packets with the assumption that mac<->ip is a unique 1:1 mapping.
I am trying to capture traffic to 127.0.0.1 on a Windows 10 computer with Wireshark. I have installed NPCap but it does not appear to be capturing that tr5affic.
Looking at the interface options in Wireshark for the loopback adapter I see it has IPV4 address of 0.0.0.0. Is this correct and if so, how do I capture the localhost traffic.
Thanks,
Sid
It seems the way to capture localhost traffic for use with Wireshark is to use "RawCap" and then examine the captured data in WireShark.
RawCap.exe may be downloaded from here -> http://www.netresec.com/?page=RawCap
Sid
Wireshark used to be installed with Winpcap behind the scenes, but Winpcap, to my knowledge, never supported packet capture over localhost. And of course, Winpcap has not been updated since 2013 IIRC.
Npcap, which is the supported replacement for Winpcap, does support localhost packet capture. And since Wireshark now delivers Npcap instead of Winpcap, it is capable of capturing and displaying packets captured on localhost.
To use the functionality, open Wireshark. At the bottom of the opening screen, there should be an "Adapter for loopback traffic capture." Double-click that, and you're off!
Two quick points.
I'm using Wireshark v3.2.7.
Packets captured off the loopback adapter do not start with an Ethernet frame, for example. They start with what Wireshark calls a Null/Loopback header. It is a 4-byte header that typically has a value of 2 in big-endian order. Read more here.
HTH
Running on a Linux system, getting UDP packets from another computer address to let's say 192.168.0.2 from another address let's say 192.168.166.66, I can see the UDP packets coming in with tcpdump. However, if I use netcat I don't actually receive the packets.
If I create an interface on 192.168.166.XXX network, then netcat is able to receive the packets no problem.
What basic networking concept am I missing? Why do I need to have an interface on the network of the sending IP when I can see with tcpdump that they are being delivered correctly?
tcpdump per default puts the interface into promiscious mode, which lets you see all the packets arriving at your network interface. But, your operating system only processes packets destined for the local system, e.g. either having the local or a broadcast address as destination.
The final solution to this problem was to disable Reverse Path Forwarding (RPF) on the interface. There are security implications here, but after careful review this was the correct path forward in this particular case.
RPF was turned off by modifying /etc/sysctl.conf:
net.ipv4.conf.eth0.rp_filter=0
Some more information on RPF:
Wikipedia - Reverse path forwarding
Linux kernel rp_filter settings
Im not too sure why this wont work. My application works fine if the client and server are ran on the same PC hence the 127.0.0.1 but it wont connect to my other laptop using IP 82.41.108.125 which is the IP of that device.
Any reason why this is happening?
Your firewall could quite possibly be blocking the port assuming all of your coding is working fine - try opening up the port number you're running the application on (in the client/server comptuers' firewall options).
Some additional information that should shed some light on things
Networked devices use ARP (Address Resolution Protocol) and RARP (Reverse Address Resolution Protocol) to map IPs to link layer (MAC) addresses and back. Your network interface card (the thing that plugs into your ethernet cable) will have a unique MAC address on both computers. Each PC has an IP configured for it which is used by higher level protocols (those in the Network Layer).
Computer A will know computer B's IP address (and it will be different from computer A's) if your program works correctly. When computer A goes to send to comptuer B, assuming they're directly connected and not going through a router or something in between, computer A's link layer will need to translate that IP for comptuer B into a MAC address it can use. It does this by sending out a broadcast to all network PCs on the same sub network asking "Hey, is this your IP!?" essentially. The one that has an IP matching the broadcasted one yes, "Yes, it's mine - and here's my MAC address so you can talk directly to me."
So, if two computers have the same IP this all goes to hell :) don't do it - give them unique IPs and make sure that comptuer A transmits to the same UDP port and IP that computer B is listening on as well. communications work in {IP, Port} pairs - its like a telephone number and area code.
Also...
As said by EJP - UDP is a connectionless protocol - computer A just sends to computer B and hopes that computer B is listening correctly. If computer B wasn't listening or was but wasn't in the right state to process the data, the data will simply be dropped and lost. Computer A will not know that this happened. If you want reliable communications where it will keep trying and you will have assurance that compuer B received computer A's data then use TCP instead - it does a 3 way handshake to establish a connection and uses acknowledgements to ensure data is retransmitted when it doesn't reach the other end.
It could be that you're listening on localhost (127.0.0.1) and don't accept other traffic. Use a wildcard address.
Check on the server with netstat -npu.
If that's not the case then it's probably firewall issue, verify with tcpdump or wireshark.
Check firewall on your laptop... Most of the time that acts as spoilsport.
we have little network devices which are shipped with IP address 0.0.0.1 to ensure that they never collide with any other device in their new environment (thus none of the 10.x.x.x, 172.16.x.x or 192.168.x.x ranges) until configuration. DHCP is no solution since there might be no DHCP server in the field.
The devices would listen to UDP broadcasts and answer with broadcasts until they are given their new IP address this way.
This worked fine with Windows XP - but sucks with Windows 7: the config program does not receive the answer packets from the devices which still have 0.0.0.1. Wireshark sees the packets, then they are dumped by the system.
Question: Is there any reason (RFC?) that actually prohibits using this address in a local environment? Or is it just MS that was overcautious? Where can I read why they treat this address "invalid"? Which ranges are really "invalid" now, too?
Any idea of a workaround on the PC side (Win 7)?
I know that it is not recommended to use 0.xxx addresses for work places, but for this very reason - having a not-used address - it works perfectly.
Edit: there is a device out there called "Netburner" which might have faced the similar issue, according to their forum. See: http://forum.embeddedethernet.com/viewtopic.php?f=5&t=612&p=2198 Does - by coincidence - anybody know some background information?
It sounds as if your configuration application is listening for broadcast packets on all network interfaces and expecting to receive packets from foreign subnets.
That should not work - the OS should only pass-on broadcast packets from the subnets each network interface is on, not from all subnets on the same physical (e.g. Ethernet) segment. I am reasonably certain that doing otherwise is broken behaviour WRT the IP protocol.
The are two ways to deal with this:
Make sure that your network interface has an IP address in the target subnet. You can have more than one IP addresses for each network card, so that should not interfere with normal network operations.
Configure or modify you application to use raw sockets, like Wireshark. Keep in mind, however, that this overrides all normal checks and balances and should be avoided, since it can cause behaviour that is almost impossible to diagnose - which is why it is frowned upon by meny network administrators.
Can you you add new routing table entries to Windows machines easily? Windows has to know which interface to use when routing a broadcast packet to the 0.0.0.x network.
The Unix machines I'm familiar with have a routing table that maps network/netmask entries to either gateways or interfaces (if the network is a local network). The local network (192.168.0.0/16 for my home network) gets sent to interface eth0. Everything else 0.0.0.0/0 gets sent to a specific gateway machine 192.168.0.1.
If my machine sent a UDP broadcast message to network 0.0.0.0/24 (in other words, UDP broadcast sent to 0.0.0.255, then my machine would forward the packet to the gateway machine (which it can look up via arp). The switches in the middle wouldn't propagate the packet to other network devices, because the MAC address is set.
If my machine had another routing entry for 0.0.0.0/24 to the local interface, then my machine would send the packet on the wire using an ethernet broadcast group, and the switches would forward the packet to all connections. (Yay! Just like hubs in the 90s! :)
So I figure you need to add a routing entry for 0.0.0.0/24 to your client machines, so that they can properly address the broadcast packet.