someone screwing with ARP

hi all!
My software firewall has been recently notifying me:

Quote:

---

Unsolicited incoming ARP reply detected, this is a kind of MAC spoofing that may consequently do harm to your computer.

Packet data is shown in the right window.

---

If any advanced programmers (assembly) would like to see the packet data let me know here and I can PM it to you. I would rather not post it in public being as it may contain IPs. However if you think you can decode it and tell me a little about it, it would be GREATLY appreciated. my network security skills are not what I would consider "newbie", but I posted this here as I could not find another forum to suit it (if there is, moderators feel free to move).

I am new to ARP. I have been doing some recent reading on the net about it and found that it is a weak spot as it requires no authentication. It is used as a classic man-in-the-middle attack, where an attacker can make your PC think that they are connecting to a trusted network (your ISP) when really you may also be connecting to another PC who could be sniffing packets travelling from your PC to the ISP's server. This can be used to reveal stuff like usernames and passwords travelling through the network.

My firewall clearly cannot stop this (even though I have "anti-IP spoofing" enabled, I am not sure if this applies to the same thing), and I am sure there are no firewalls capable of it. So I am just wondering. Is there any way to stop this? I have recently found that almost every time I turn on my modem (start a new PPPoE session) that my IP changes. I think this would help greatly. But what I am asking is there anyway that I can tell if someone is "mac spoofing" and stop it?

also another short question. I am trying to use netstat.exe to check for any unknown connections. I go to Start > Run and type "netstat.exe". The netstat window pops up and closes so fast that I can't read it. Is there any way that I can make the netstat window keep from closing so quick so that I can look over my current connections?

anyone who can please answer one or both of these questions it would be GREATLY appreciated.

thanks alot in advance! :D


- ryan

I can't offer you much relating to you main problem, but until someone else comes along, if you open your dos prompt (programs > accessories > dos prompt) and type 'netstat - ano' (less quotes) you will get what you want.

You might consider trying TCPview. It does basically the same thing as netstat but it is windows based, easier to use, and provides more information, like files associated with open connections.

thanks for the reply hesperus!

I will try TCPView as it sounds a little more like what I want (a little more specific on associated files). However I highly doubt that I am backdoored, would like to check anyways (just incase its rootkitted or something).


- ryan

Hi

1. Your firewall is detecting the attempt to poison the ARP cache, preventing it and notifying you. It seems to be doing this adequately so I don't think there is immediate cause for concern.

2. I am slightly puzzled about how your ISP is allowing this. You should have a private Class C IP address supplied by DHCP on connection with your ISP with a /32 subnet mask making your IP address the network, host and broadcast address and preventing sniffing of the link. ARP poisoning can only happen on the same network segment and essentially with this set up or even with /31 bit setup, you should have a subnet to yourself. Maybe I have misunderstood somewhere - anyone wish to enlighten me.

3. Therefore, the only way I think it might be possible would be if you had wireless enabled somewhere and the person was attempting to cause your machine to drop off the link and use your connection for themselves. Are you using a wireless router/ADSL modem for example.

4. An assembly language programmer is not what you need to read the data packet. Rather someone with a halfway decent knowledge of the workings of the protocol stack should be able to tell you exactly what is going on.

5. There is no need to be coy about sending the data packet as your IP address will be in the private range will change every time and the ISP server's IP address is public knowledge.

6. I agree that either netstat -noa or tcpview will give you information about unknown connections although I think Ethereal might be more revealing in allowing you to sniff traffic and drill down to check out what is happening.

7. It is up to your ISP (normally anyway) to stop this kind of thing not you. You might consider reporting the attempts.

Quote:

---

Originally posted here by tenzenryu


2. I am slightly puzzled about how your ISP is allowing this. You should have a private Class C IP address supplied by DHCP on connection with your ISP with a /32 subnet mask making your IP address the network, host and broadcast address and preventing sniffing of the link. ARP poisoning can only happen on the same network segment and essentially with this set up or even with /31 bit setup, you should have a subnet to yourself. Maybe I have misunderstood somewhere - anyone wish to enlighten me.

5. There is no need to be coy about sending the data packet as your IP address will be in the private range will change every time and the ISP server's IP address is public kn.....

---

Many/most people don't have a private address and many/most adresses won't change without a different mac address.


I would not worry to hard about the "ooga booga your being attacked" crap from your firewall its just telling you its doing its job and justifying its existance by telling you. If you are worried still email your logs to your isp and forget about it, all sorts of crap goes on day in day out and 99.999999% is harmless unless your running an unpatched os.

thanks for your replies!

so you think that this is nothing to worry about?

also do you think it is worth notifying my ISP of this? or should I not worry about it?

I am not on any wireless network. I am not running an unpatched OS.

I still do have the packet data, so if anyone who could take a look and tell me what appears to be happening, it would still be greatly appreciated (just drop me a PM or post a reply here and I will PM to you). This has happened several times, but does not happen all of the time and the packet data appears to be the same each time (I am guessing it is only happening when I am connected through one IP that someone is aware of and that explains why it is not always happening, my IP is changing).


- ryan

Hi,

re: Private Addresses - sorry that's true most people have temporary addresses rather than private range addresses. My bad.

Also, I am wondering if it the logical subnet or the physical network segment which allows arp poisoning to take place. If it's the former, the subnet masking should have taken care of it. The latter would not be dealt with so easily I guess.

The reason for ARP poisoning to attempt either a man in the middle attack or else to overload the switch with ARP requests to throw it into promiscuous mode making network sniffing easy.

But this kind of stuff does go on all the time and as long as your firewall is reacting appropriately to it and you are patched and signatured to the hilt 99.999999 % of the time you shouldn't have to worry.

Quote:

---

ARP poisoning can only happen on the same network segment and essentially with this set up or even with /31 bit setup, you should have a subnet to yourself.

---

The upshot is that if you are not on a LAN and don't use wireless, this could not be an attack because you are the only one within the limits of MAC functionality.

Quote:

---

MAC addresses are not routable, either; in other words, Internet protocols will not accept a MAC address as a destination (for one thing, it's two bytes longer than an IP address). The MAC concept doesn't scale. So you only utilize MAC addresses locally, not across a router.

---

http://www.watchguard.com/infocenter...ial/135250.asp

This site has a good, clear overview of MACs, NICs and ARP.

The message is probably being generated because of a glitch in the data flow. Somehow your firewall is forgetting the first half of the communication -- it gets the reply but loses the request. Do a google search for the the notice and you'll see its fairly common, especially with Sygate.

ah so you think this might not even be an attack? I am not on any wireless network. a wired router. would rather not have wireless due to reliability (dead spots) and security.

and yes I am using Sygate Pro.

what you just said hesperus seems to make alot of sense. the fact that I am not running a very big amount of RAM, could explain why the firewall is "forgetting" the request. the firewall is simply notifying me of something happening that doesn't seem right, an "incoming" reply to a forgotten request. basically what appears to it as an unknown incoming packet (could be anything, but its host address is my router's IP so the firewall thinks it is a wireless router and someone outside is trying to poison the ARP by sending packets to it). I could see if it was an OUTGOING reply to an unknown request, than I should probably be a little more worried. like I said it simply could have to do with not a great amount of free resources, where something else overwrites the request in memory (being as there is not a great deal of it). and being as its host address is my routers, it assumes that someone is attempting to poison the ARP through what appears to it as a wireless network.

I think I have it clear now and this is probably what is happening. even if not, I don't think it is much to worry about.

thanks alot to those who helped!! :D



- ryan

When I netstat.exe -ano and then netstat.exe -a this is what I see (edited slightly):

TCP sympatico:1025 LISTENING
TCP sympatico:1029 LISTENING
TCP sympatico:1047 LISTENING <-
TCP sympatico:137 LISTENING
TCP sympatico:138 LISTENING
TCP sympatico:nbsession LISTENING
TCP sympatico:1181 63.146.109.212:80 LISTENING <- Guessing this is IE open for this site?
UDP sympatico:1025
UDP sympatico:1029
UDP sympatico:1047 <-
UDP sympatico:nbname
UDP sympatico:nbdatagram

The suspicion I have here is on port 1047. just before doing this netstat, I found another "LISTENING" port on TCP 1029 (same positions in netstat list as 1047 is now, both TCP and UDP). I opened up my personal firewall and blocked TCP and UDP incoming/outgoing 1029. tested to see if I could use the net and it worked fine. now I see TCP and UDP 1047, which was never there. just like last night, when I blocked TCP and UDP incoming/outgoing 1039, and then 1029 suddenly appeared today. every time I block these ports I can still use the net fine (could be because they are opening different ports too :confused: ). I tried TCPView but it seems to be giving me the same thing as netstat.

also thought I'd note TCP and UDP ports 137, 138, 139 have been blocked for months now. was told by someone here (I think?) that these ports were being used for a spreading exploit at the time or something like that.

I am just wondering. does this appear to be normal behaviour? a port blocked simply opens another? would just like to hear you guys opinions on this. does this seem normal?

any help would be greatly appreciated.


- ryan

Dowload TCPview and Process Explorer. Use TCPview to see what process is using the port. Note the pid (process id, next to the .exe). Open Process Explorer, look for the pid, and it will give you specific details about the what is going on at that port.

This is a much better way to get a handle on it. You can block ports till your blue in the face, but until you know what process/es is/are using them you won't know if its legit. Chances are they are system processes.

See this very good tutorial by sec_ware to figure out what system processes you can do without and how to turn them off.