Can someone tell me how exactly works "test ICMP"? (One of methods to detect sniffing in local network)
Sniffing detection is basically detecting if there are any sniffers in your network. The main feature of sniffers that is used to detect them is that they place the network card in promiscuous mode, listening for all traffic. Typically, a sniffer is placed on a machine with a full TCP/IP stack which will be affected by this mode.
ICMP is the protocol behind the ping command. To ping a machine, you send an ICMP Echo request packet to it and wait for an ICMP response one. Usually, the ICMP request is embedded in an Ethernet packet to be delivered across the network. A standard Ethernet packet would include the MAC address of the addressed network card, as well as the IP address of that machine in the embedded ICMP packet. The packet would be detected by the appropriate card and that machine would respond to the ping. This is the standard process.
Now let's see what happens if we sent a ping packet (ICMP Echo request one) with the IP address of the suspected sniffer address but with a different, faulty MAC address in the Ethernet envelope.
If the network card in the sniffer machine is not on promiscuous mode, then the packet will not be received by that machine. Naturally, the machine wouldn't respond. The ping attempt would fail.
If the network card in the sniffer machine is on promiscuous mode, then the machine will see all packets in the network. The TCP/IP stack on that machine would thus accept the ping packet by identifying the received packet IP address. The stack would thus send a response. The ping attempt would succeed.
Similar to other methods of detection, this has false positives as well as false negatives. The sniffer machine may be instructed to ignore all ICMP requests. Detecting promiscuous mode is not exactly detecting sniffers, though it is a very significant clue.
Related
I'm writting a simple network sniffer that should be able to reconstruct network structure.
When an interface has set up a DHCP, I can easily read interface settings such as client IP address, subnet mask, DNS server etc. by catching a DHCP packet and analysing it.
When an interface has a static IP, I'm catching ARP Announcement packet to get static IP address and then ARP request from the gateway, to get geteway IP address. I'm also saving MAC addresses.
My problem is: how to get subnet mask from one or more static IPs in the network and the gateway address. Or by caching some packets. I didn't see packets that could have such informations.
I also need DNS address, but it's less important.
The program should work in OpenWRT (C++).
My problem is: how to get subnet mask from one or more static IPs in the network and the gateway address.
Possibly, you can't.
If the sniffed network uses DHCP then you can monitor the DHCP requests (which should be broadcast) for their subnet mask and router fields which mirror the server's offer.
Without DHCP, all you can do is take an educated guess. If your passive sniffer registers broadcasts from addresses 192.168.1.1 through 192.168.1.29, you know that the prefix length is at most /27. It could also be anything shorter, down to /16, with potential addresses being (currently) absent or silent. The prefix could be even short than /16 if the network admin is ignoring RFC 1918. With public addresses you're mostly on your own.
If you can scan actively you could send ARP requests and see which ones get answered - you'd also see nodes that don't originate any traffic/broadcasts.
The gateway is also just a guess. In a network with mostly Internet-bound traffic, the default gateway is most likely the one being ARPed most often. If the network traffic is mostly server-centric, ARP requests for their addresses outnumber the ones for any gateway.
Your sniffer is severely limited when it is just attached to a switch and listening to broadcast packets only. If the sniffer manages to listen to all traffic on the network (via a monitoring/mirroring switch port) then you can easily identify the gateway by its MAC address that packets for arbitrary IP addresses is sent to and vice versa.
As above, if you can actively send probe packets you could test the gateway(s) with packets that they accept (and hopefully forward) and which ones they reject.
Consider the following:
I have a device which sends UDP messages to another device, both on the same switch. The UDP messages are not sent as a broadcast. Now I want to listen to these UDP messages with a third device, also connected to the same switch.
Now I've to choose the right switch and I'm not sure if I missed something:
Is it correct that the UDP messages anyway are sent troughout all ports of the switch since a Layer2 switch doesn't know anything about addresses. Or in other words: Can I use any Layer2 switch, managed or unmanaged, as long as all devices are in the same subnet?
Thanks for your help!
Simon
I think you're misunderstanding how works layer 2 in the TCP/IP model.
If a UDP datagram is sent to a specific machine on the network, it's layer 2 address should be the destination's MAC address and the switch will send it only to this machine as long as he's got the mac address in his CAM table (MAC address <-> physical port association) which should be the case as long as the machine is active on the network.
If you want to intercept packets between two machines, you can either mirror the physical port on the switch to copy informations received by this port, or make a ARP cache poison attack on the local network which will allow you to receive all traffic from one machine to another, also known as MITM attack (man in the middle) which is quite easy to produce on a linux machine.
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'm new to the networking world and I'm using Wireshark to learn stuffs about the network.
I was hanging around in Wireshark while I was using my VPN for circumventing the internet filter (living in a dictatorship country).
While I was using the VPN I see packets that their source or destination IP was neither my IP nor VPN server IP.
I considered two things about my problem:
1- I know my VPN uses its VPN server to send my whole packets to that server then forward them to my deserved destination, then take the response and send it to my client (is that correct?).
2- In Wireshark, I just can see the packets that their either source or destination address is my IP address.
My packets before using VPN:
As you can see, their either source or destination IP is my IP (192.168.1.101).
After using VPN, VPN:
Wireshark:
I tried filtering packets with my IP like this ip.addr == 192.168.1.101 to see only the packets that their either source or destination IP was my private IP, and guess what? nothing was changed. Why did this happen? Wasn't that supposed to filter my packets?
I also checked those packets' MAC and compared them with my MAC, and they were identical.
So my main question is why these kinds of wandering packets were showed by Wireshark? Is my VPN client insecure and trying to sending my data to other places? Or I'm wrong about how my VPN works?
Also, I appreciate it If somebody tells me more explanation about how my VPN or Wireshark works so that I have these types of packets in my Wireshark.
First of all your considerations, point no.1 is right, that's how a typical VPN works and point no.2 is wrong.
Wireshark can capture any packet (any source IP or destination IP) flowing in and out of a network adapter technically known as NIC card. NIC cards are the way through which you can connect to a network (Internet). A quick brief of NIC over here
A typical VPN client software would form a virtual NIC to encrypt and send your traffic through it. A quick brief of VPNs over here
So, to see the required traffic in Wireshark, you must capture traffic from an appropriate interface (NIC card). The answer over here might be helpful.
I connected two machines via a network cable. I need to get an ARP request data via Wireshark. When I pinged the IP of the other machine, I get the ARP request on Wireshark. But, it is not broadcasting a message. It targets pinged IP address directly. I think a LAN with only two machines does not need to do a broadcast. Am I right? Can any one explain this to me?
Always in ARP packet, MAC address will be broadcast not IP. As it is used to learn MAC address of other host whose IP address is known, ARP packet needs to have valid IP address rather than broadcast IP. You can check ARP packet example at below path:
http://wiki.wireshark.org/AddressResolutionProtocol
Hope this clears your doubt.