I'm making application that can detact arp spoofing :]
My idea is that if there is attacker in subnet, and he tried to MITM using arp poisoning, then I exec traceroute to default gateway(or changed arp cache entry, whatever).
Cuz all my packets go through attacker's PC, so traceroute will show up some sign.
Is there any problem in my idea? Is it proper? or not?
The proper way to detect arp spoofing is with software like arpwatch.
arpwatch will see that two machines are fighting over the same IP address and notify you.
Nov 10 15:59:34 debian arpwatch: changed station 192.168.1.2 0:17:9a:b:f6:f6
(0:17:9a:a:f6:44)
If you see entries like this for your IP address, then start looking for the switchport that sources the hostile mac-address in question.
As a general answer to your question, traceroute is the wrong way to detect this. Just monitor ARPs and maintain a table of mac-address to IP mappings.
Related
AFAIK when i turn on my modem, it says: "Hi ISP, i need an IP".
Then, my ISP give it an IP.
How does my ISP identify my modem? by last IP, key, or what?
After i have an IP, i can navigate, but after some hours my modem changes its IP.
2) How is that change done?
I mean, my ISP says: "Hi user modem, there is your new IP"
It gets even funnier if when i turn on my modem, some other modem has the last IP my modem had.
There is a collision. So, my ISP would give my modem another IP, wont it?
I know im talking about technical stuff, but i would like you to explain me in your own words in order not to make it cumbersome.
If technical references arise, maybe just name the concept or leave a link. It would be enough for me.
Thanks you all!
By posting under the tag „dhcp“, you are obviously already assuming that the DHCP protocol is the answer to your questions:
The DHCP Protocol allows the DHCP Server (your ISP) to identify the DHCP client (your modem) by a multitude of information. The most important one is usually the MAC address of your modem. The last IP is also transmitted from client to server along with proprietary information such as the client identifier and others.
The server supplies the IP address along with a lease time. The client will renew the IP address with the DHCP server when the lease time is about to expire. The server decides in the renewal process triggered by the client if the same IP is ok to use further or not.
Restart is not much different from renewal. The DHCP protocol is for that purpose equipped with a broadcast feature so the collision does not really happen, because the client (modem) will ask for an IP address before it uses the old IP.
It is possible that modem and ISP do not use DHCP but the mechanism is probably similar. DHCP is specified in RFC 2131.
If I connect a device via ethernet onto a switch, and do not receive an IP address via DHCP, how do I determine what the correct settings for that network should be, i.e. how do I choose a static IP address, subnet mask and gateway?
The specifics in my case are that I have an NVR with an 8 port POE switch that has 3 cameras plugged into it. I plugged my Windows 10 PC into the switch, expecting to be issued an IP address from the NVR via DHCP, but my PC was not given an IP. Perhaps the NVR assigns IPs via BOOTP? I want to get onto the network, probably by assigning a static IP that's not already used, then determine the IPs of the cameras so I can stream video from them directly using VLC.
Can I use tcpdump? There should be plenty of traffic from the cameras to the NVR.
how do I choose a static IP address, subnet mask and gateway?
The short answer - this should be done by your network administrator. If you are the network administrator - you should. But seems that you are connecting to the network you know nothing about.. Anyway here are some points that perhaps can help you.
There is a special thing called ARP Duplicate Address Detection (DAD). In Linux you can check if the particular IP is occupied in your broadcast segment with help of arping utility. From MAN page:
-D
Duplicate address detection mode (DAD). See RFC2131, 4.4.1.
Returns 0, if DAD succeeded i.e. no replies are received.
So if IP address is occupied you will see something like:
-bash-4.4# arping -D 10.0.99.99 -I eth0
ARPING 10.0.99.99 from 0.0.0.0 eth0
Unicast reply from 10.0.99.99 [DE:AD:BE:EF:00:8D] 1.274ms
Sent 1 probes (1 broadcast(s))
Received 1 response(s)
If this IP address is vacant, you'll see no responses. Read about ARP ping in Windows.
Also you can inspect the network through the tcpdump (to see some IP addressing info at least in broadcast packets), nmap and some other scanning utilities, but this topic is too broad (and at the same time it's well disclosed on the Internet). Btw you have to consider network architecture difficulties: vlan and so on.
If i send ARP request sent to a find the MAC address of a machine in a LAN. But among the group of hosts in the LAN, two hosts having the same IP address, then how the ARP reply works.
The same situation with the RARP, if the two machines inside the LAN with same MAC address. If i send RARP request to find IP address, then how the RARP reply works.
If it receives 2 different ARP or RARP responses, it knows something wrong.
Further reading: gratuitous ARP.
Primarily IP address is unique within a network and MAC is unique globally and so there should not be any confusion.
But incase if multiple devices have same IP or MAC then (probably) the first ARP or RARP will be accepted as valid response. Because once a request is obtained the information is written in to kernels ARP cache and so for subsequent needs the cache will be used (till the cache expires).
I'm trying to get Age of Empires II (AoE2) to work on my LAN. AoE2 is notorious for it's connectivity problems on modern systems, probably because it used a now deprecated network framework called DirectPlay (in DX9) and the code probably wasn't robust back in the day either.
When I host a LAN game on a computer (win7) for AoE2, Wireshark shows my computer sending a couple packets via SSDP protocol to the multicast address 239.255.255.250. This actually goes to my router (for forwarding I assume) and my router returns a packet using ICMP protocol that says "Destination unreachable (Port unreachable)". Because nothing is forwarded to the other computers on the network, they can't see the game that the host has created.
I think I need to get the application/windows7 to send the packet as something like a broadcast, or I need to get the router to broadcast packets going to that multicast address. Does anyone have thoughts or suggestions on how to do this?
My router/gateway is running DD-WRT firmware v24-sp2.
My first guess is you're using wifi, by default most systems disable multicast on wifi because it can have a detrimental effect on the time slicing that wifi uses. however for just a couple machines it shouldn't be an issue.
here's how to disable multicasting but it should point you in the right direction for enabling it: ddwrt multicast
Secondly make sure they are all in the same VLAN a VLAN is defined as a "broadcast domain" meaning machines on separate VLANs will NEVER get broadcast or multicast from other VLANs without some trickery.
Lastly make sure you've enabled multicasting between LAN ports I believe the option is "multicast forward"
Edit: Just a few things to add to the list in case others have this issue. Broadcasting doesn't exist in ipv6, also a machine running ipv6 MAY NOT see broadcasts from a machine on ipv4 and a machine on ipv4 WILL NOT see multicasts to an ipv6 multi-cast address.
Have you tried LogMeIn Hamachi?
Is not a LAN client itself but it creates a fake Online-LAN and gives you a working IP that will allow you to play with who have it.
I'm looking for some Linux code to find an IP address from an Ethernet address. I suppose I have to do some inverse ARP trickery but I don't find any example...
http://compnetworking.about.com/od/networkprotocolsip/f/convertipmacadd.htm
Try sending an IP broadcast (e.g. ping 192.168.1.255 if your subnet is 192.168.1.0/24) to prime your ARP cache, followed by arp -a to spit it all out.
For computers that you have communicated with, you can look at their arp entry. This is available in text format in /proc/net/arp for example. Finding an IP address for a MAC that you know but haven't communicated with is significantly more difficult. The closest match, protocol-wise, would be RARP but that's hardly ever in use so your are not likely to get a response.
You can always scan your local subnet to make sure you get a full view in your arp table. See for example fping for an efficient way to do this. Note that hosts don't actually need to respond to the pings in question to appear in the ARP table, so this is useful even in the presence of local firewalls etc.
Take a look at Thomas Habet's Arping. I've not tried it, but the basic idea is to send an ICMP Ping network packet to the MAC address in question using a broadcast destination IP address in the IP header. Only the host with the specified MAC address will reply and the reply will (usually) contain its IP address. It won't always work but it might be good enough for you. See the project readme for limitations.