Why is packet-sniffing possible? - packet-sniffers

I can't wrap my head around how packet-sniffers can be used by anyone on the network.
I know very little about how networks work, but let me put it this way: suppose the mailman comes around delivering a package to my doorstep. Why is is that I'm able to rifle though all his other packages and look around? Shouldn't the mailman only hand me packages that are mine?

To quote William Pursell's comment, which he should have made an answer and should have expanded:
The mailman does not deliver the letter your doorstep. Instead, he opens your mail and shouts out: "this letter is for <name>. No-one else should listen" and then proceeds to read the letter out loud. –
In the original Ethernet network, there was a shared cable to which all hosts were attached; if a host wanted to send a message to another host, it would transmit the packet on the shared cable, with an Ethernet header with the destination Ethernet address of the other host. All hosts on the cable could, in theory, see the packet. (This was in an era where security was less of a concern; for cases where security was a concern, the packets were encrypted in a fashion that the other host could fairly easily decrypt but that other hosts would have to decrypt in some other more difficult fashion.)
In addition, a packet can be sent to the "broadcast" Ethernet address (all 1's) or a "multicast" Ethernet address (which several hosts are configured to handle); broadcast packets are intended for all hosts on the Ethernet to see, and multicast packets are intended for all hosts in the address's "multicast group" to see.
Normally, an Ethernet adapter would ignore packets that aren't sent to its Ethernet address, to the broadcast Ethernet address, or to a multicast address for which it's configured to receive packets. Most can, however, be put into "promiscuous" mode, where they pass all packets to the host; that mode is used for packet sniffers.
Most current Ethernets are "switched"; instead of a shared cable, there's an Ethernet switch, and hosts plug into the switch with a cable. Packets sent to a particular host's Ethernet address will only be sent out the switch port for that host (unless somebody's configured the hosts to have a "mirror port" on which all traffic is sent, or unless the switch hasn't yet determined which port is the port for that Ethernet address). Broadcast packets are sent to all ports, and multicast packets may be sent to all ports or, if the switch can determine that, to those ports that have adapters configured for the multicast address in question.
Wi-Fi networks are similar, but they're usually protected with encryption, as it's easier for somebody to bring in a laptop and put it into "monitor mode" to sniff on a given channel than it is for somebody to bring in a laptop, configure a switch to have a mirror port (or use some other mechanism to get access to the traffic), and plug the laptop into the appropriate port on the switch.

Generally speaking, with switches you are correct. However the person who owns the switch can intercept your traffic at will (in your example that would be the mail service). Also, sometimes the switch can be fooled into rerouting traffic (someone accepts the package on your behalf and then goes through it).
Furthermore, certain kinds of packets need to be broadcast. For instance ARP packets (where one computer is asking for the ethernet address of another computer specified by IP) get broadcast to all ethernet addresses and therefore can get sniffed.
Generally speaking man-in-the-middle requires someone in the connection chain to be compromised. For instance, your ISP or the company they buy transit from could create a man in the middle attack. (This is also why security in countries oppressive regimes is so difficult, they control the internet and therefore can sniff/man-in-the-middle attack whatever they please). This can also be done by compromising the DNS server you use to point you to a different site that can grab your data and forward your data (or a modified version thereof) on to the true site.
In the good 'ol days hubs were quite common (or even older, everyone shared a piece of coax). In this case it's more like the package gets dropped on the first door, the occupant looks to see if it's theirs, if not, passes it on, if so, copies what's inside and passes the package along. In other words, packet sniffing is actually quite easy.

Yes or more simple way packet sniffing not is good, while you login on the web page you normal use a secret password for verify this is you.
But in case we has a packet sniffer she/he can also see and read what you password is.
And laiter login in the web page as you.
Or in she/he can also modify you data on the road to do something other.
And in the case of internet, the normal way is more the one computer is use to
send a message from in this case Alice to Alice bank.
And in each of this computer ( right side of image ) is this possible
for the use to edit the message if the use want as in this image.
Eva is use for deliver the message to Alice Bank, but she can
can read the message/order and in some case edit this to get the bank
to think Alice want to transfer money to Eva instead of Bob.
In short for protect us against eva to modify the message we can use
hash-algorithm or cryptographer algorithm.

Related

What do you understand by ip based telecommunications?

What do you understand by ip based telecommunications? Does it includes CDMA, UMTS, LTE, HSPA, IP telephony?
Thank you.
Well, there is a lot of theory and information behind this, but, in a few words, ip based communications are those who uses the IP (Internet Protocol). This means:
The connected devices must have an IP number
The connected devices send and receive data as datagrams (also known as packets)
They might rely on bigger network approaches like TCP/IP stack or OSI model
So, everything with an IP number/address uses an IP based communication, and, as far as I know, CDMA, UMTS, LTE and HSPA don't use IP's to send data. They are more likely to be the infrastructure of telecommunications (layer 1 and 2 in OSI model, and Layer 1 in TCP/IP), they care about how to physically link devices in a network, and IP cares about how to use those links to send data through it.
I'd recommend you to read about TCP and OSI model

Ruby sending packet to a known MAC address

I like to send packet to a device with only MAC address associated to it and also connecting to my local LAN.
Is there anything in ruby / gem library that I can use to perform such task?
I want to do something like tcpreplay but in ruby instead. Thanks!
MACs are the addresses used on OSI layer 2, the package type you are using on this layer are e.g Ethernet frames. IP Sockets live on layer 3/4, thus if you are using an IP socket, you are sending IP packet.
So if you want to send something "to a MAC address", you need to send raw Ethernet frames which need to be understood on the other side. Given the really low level of this stuff, this is rarely what you really want to do.
Instead, you should try to get the proper IP addresses of the remote device in your local network (technically the broadcast domain) with either a broadcast/reply mechanism or with multicast (which is used e.g. by Bonjour). That way you can always use the much more supported IP layer. For that, your device needs to have an IP address of course. You can establish those with mechanisms like DHCP or address auto configuration for IPv6.
As for your question, I'm not aware of any library for Ruby to send raw Ethernet frames. But given you would need to invent a new protocol besides IP anyway (which is hard, really hard), sending the package is probably the least of your concerns.
I suppose there are a couple of approaches. You didn't say whether you wanted to send an IP packet of some kind, and if so you didn't say which IP protocol. (I can tell you want to send an ethernet frame but ... what encapsulated protocol?)
Anyway, you can open a SOCK_RAW with Ruby, something like:
Socket.open(Socket::PF_INET, Socket::SOCK_RAW, Socket::IPPROTO_RAW)
Another approach might be to just pick a link-local IP and then establish an IP/MAC mapping in your local ARP cache with something like:
system "arp -s host hw_addr"
Then you could communicate with it using more familiar socket ops using the link-local IP address.
You need to be root for all of these things.

What are the legitimate ways a client's IP address can change even though the user hasn't explicitly changed it?

If I have a UDP server repeatedly receiving requests from the same client machine, when might the client's incoming IP address change even though the user is actually still on the same machine and has not done anything deliberate to change her IP address?
I can think of two cases: (1) packets are coming in via proxy servers that use a pool of different IP addresses, and (2) the client machine is using a dynamically assigned IP address that has expired and been reassigned to a new IP address.
Are there any other cases?
Is it a mobile client? If so, it could change networks. For example -
A phone switching b/w 3G and wi-fi
A laptop changes wi-fi networks (this is infrequent though)

Find IP address of directly connected device

Is there a way to find out the IP address of a device that is directly connected to a specific ethernet interface? I.e. given one host, one wired ethernet connection and one second host connected to this wired connection, which layer or protocol below IP could be used to find this out.
I would also be comfortable with a Windows-only solution using some Windows-API function or callback.
(I know that the real way to do this would probably via DHCP, but this is about discovering a legacy device.)
Mmh ... there are many ways.
I answer another network discovery question, and I write a little getting started.
Some tcpip stacks reply to icmp broadcasts.
So you can try a PING to your network broadcast address.
For example, you have ip 192.168.1.1 and subnet 255.255.255.0
ping 192.168.1.255
stop the ping after 5 seconds
watch the devices replies : arp -a
Note : on step 3. you get the lists of the MAC-to-IP cached entries, so there are also the hosts in your subnet you exchange data to in the last minutes, even if they don't reply to icmp_get.
Note (2) : now I am on linux. I am not sure, but it can be windows doesn't reply to icm_get via broadcast.
Is it the only one device attached to your pc ?
Is it a router or another simple pc ?
To use DHCP, you'd have to run a DHCP server on the primary and a client on the secondary; the primary could then query the server to find out what address it handed out. Probably overkill.
I can't help you with Windows directly. On Unix, the "arp" command will tell you what IP addresses are known to be attached to the local ethernet segment. Windows will have this same information (since it's a core part of the IP/Ethernet interface) but I don't know how you get at it.
Of course, the networking stack will only know about the other host if it has previously seen traffic from it. You may have to first send a broadcast packet on the interface to elicit some sort of response and thus populate the local ARP table.
Windows 7 has the arp command within it.
arp -a should show you the static and dynamic type interfaces connected to your system.
Your Best Approach is to install Wireshark, reboot the device wait for the TCP/UDP stream , broadcasts will announce the IP address for both Ethernet ports
This is especially useful when the device connected does not have DHCP Client enabled, then you can go from there.
You can also get information from directly connected networking devices, such as network switches with LDWin, a portable and free Windows program published on github:
http://www.sysadmit.com/2016/11/windows-como-saber-la-ip-del-switch-al-que-estoy-conectado.html
LDWin supports the following methods of link discovery: CDP (Cisco Discovery Protocol) and LLDP (Link Layer Discovery Protocol).
You can obtain the model, management IP, VLAN identifier, Port identifier, firmware version, etc.

Win32 sockets - Forcing ip packets to leave physical interfaces when sending to other local interfaces

Summary: I'm trying to create sockets to pass data between two physical interfaces that exist on the same machine, and Win32 sockets always forwards the traffic directly in the kernel instead of pushing through the physical interfaces. Is there any way to disable this behavior, perhaps through device settings, registry tweaks, routing table shenanigans, or socket options? We're using Windows XP SP3.
Some background. I'm attempting to build some completely automated IP tests to exercise our custom IPv4 equipment. We have a large lab of Windows XP machines, and individual physical ethernet interfaces for each device we're connecting to. Our devices are effectively ethernet routers each with their own IPs.
We need to send data out our lab machines, through our devices, then back into the same computer. We will be sending Unicast and Multicast UDP, TCP, and broadcast IP traffic through the devices.
We want (and likely need) the traffic to originate on the same machine it is destined to.
To do this, we configure two separate NICs each with their own IP on their own subnet, for instance NIC #1 with 10.0.0.1/24 and NIC #2 with 10.0.1.1/24. Our devices then act like simple passthrough routers, and have two interfaces, one on the 10.0.0.0/24 subnet, one on the 10.0.1.0/24 subnet, which they just forward packets back and forth from.
To generate our data, we'd like to be able to use Win32 sockets, since it is well-understood, well-supported, what our customers are using, and would probably be the most rapid approach. Packet injection is probably feasible for UDP and broadcast IP, but very likely not so for TCP. I'd entertain ideas that used packet injection, but would strongly prefer standard Win32 sockets.
As stated in the summary, the packets never leave the machine. I've googled like a madman and I've not found much. Any ideas?
Use Windows' command-line ROUTE utility. You can configure it so any IP packet sent to a specific IP address on a specific Subnet gets sent to another IP/device. For example:
route ADD <NIC_1_IP> MASK <NIC_1_SUBNET> <DEVICE_IP_CONNECTED_TO_NIC_2> METRIC 1
route ADD <NIC_2_IP> MASK <NIC_2_SUBNET> <DEVICE_IP_CONNECTED_TO_NIC_1> METRIC 1
Alternatively, if you know the index numbers of the NIC interfaces, you can specify them instead:
route ADD <NIC_1_IP> MASK <NIC_1_SUBNET> METRIC 1 IF <NIC_2_INTF>
route ADD <NIC_2_IP> MASK <NIC_2_SUBNET> METRIC 1 IF <NIC_1_INTF>
This way, whenever a packet is sent to NIC #1's IP, the packet goes to the device connected to NIC #2, which will then pass it on to NIC #1. And vice versa for packets sent to NIC #2's IP.
For instance, this is a useful technique for allowing WireShark to capture local IP traffic if the PC is connected to a network with a router. Packets from one local IP/Port to another local IP/Port can be bounced off the router back to the PC so they travel through physical interfaces that WireShark can monitor (WireShark will see duplicate copies of each local packet - one outbound and one inbound - but you can filter out the duplicates).
Winsock is always going to bring the packet data up into the kernel space and deal with it there. Thats the whole point to a generic API is that any device is dealt with at the same "layer". If you want to stick with Winsock, I don't believe you can (or would want to) work around this behavior.
You can remove some of the buffer copying with TransmitPackets or TransmitFile, but not between two device interfaces.
That being said, are you having a performance issue with the additional buffer coping that Winsock performs? Security concerns?
How about running the endpoints of your tester inside of distinct virtual machines? Then you need only a single piece of hardware, but you'll have separate TCP/IP stacks that don't know each other are local (and most VM solutions pass the packet straight through the host unchanged, I don't think the host is going to grab the packet and send it straight to another VM unless you configure bridging between VMs... but you'll bind each VM to a different physical network adapter).

Resources