ARP Cache Poison behavior by Apple TV

Norton Anti-Virus reports blocking an ARP Cache Poison attack against my home network. The reported source of the attack is the MAC number of the Apple TV on the network.
Whether Norton is "reliable" is apparently contentious in the support community. Several authors suggest, with authority, disabling Norton or the particular attack profile.
Whether that makes sense depends on what the Apple TV is innocently doing to be profiled as a network attack.
Even when supposedly "asleep" the Apple TV is doing something that meets the profile of an ARP Cache Poison attack. It did it every 30 minutes today, nine times yesterday, about 30 times day before and etc.
And if it is a design feature of the device, why is the device still performing despite having the activity continously blocked? What is the purpose of this attack-like activity, assuming it is not an attack? If it is an attack, how does one erase the programming initiating the attacks and still have an Apple TV?

Short answer: it is a false positive. I don't know exactly what causes it but I would guess Apple's Bonjour protocol, which is why you see something every 30 minutes. That's just a blind guess, but seems to fit.
Realize that a report of ARP poisoning wouldn't be likely on a private LAN, unless you got infected somehow. No known malware like this for iOS devices (and much harder to insert one on AppleTV versus an iPhone or iPad.) There are legitimate cases where ARP spoofing is used. And even Cisco has instances where they say to ignore that warning:
CSCsm25943—The meaning of the following error message on the controller is not clear. This message does not necessarily imply that any actual "ARP poisoning" is occurring. Rather, this message appears when a WLAN is configured for DHCP Required and a client (after associating to this WLAN) transmits an ARP message without first using DHCP. The client is unable to send or receive any data traffic until it performs DHCP through the controller.
DTL-1-ARP_POISON_DETECTED: STA [00:01:02:0e:54:c4, 0.0.0.0] ARP (op 1) received with
invalid SPA 192.168.1.152/TPA 192.168.0.206
Workaround: Perform the following steps:
• Verify that the client eventually does perform DHCP without undergoing an unacceptable outage. If the outage before performing DHCP is acceptable, then you can ignore this message.
I'm not saying that Norton's message is the same as Cisco's. Just that Cisco states that the meaning of why the message appears is not clear and sometimes is acceptable. And Cisco is the world leader in networking technology so if they don't always know why you get an ARP poisoning warning....
I won't go into the politics of "Norton bad" or whatever, but based on my experience (bias) with Norton in it's various forms for over 10 years, IMHO you can ignore this. Hopefully you can configure Norton to selectively ignore this. If not, you may have to use a different security program. Me personally, I do not recommend any "security suites" because they cause exactly this kind of additional headache. Just a "plain" antivirus program. Windows has a built-in firewall and most people will be using a hardware firewall at the office or home so the firewall in the "security suite" is extraneous.

Similar Messages

ARP cache poisoning detection disabled

I recently checked all the messages in the console and found the following error message: Could not enable ARP cache poisoning detection. Your computer will not be protected. This message is logged every time I turn on the computer. I am assuming this problem started when I upgraded to Mac OS 10.5.6 since I have never seen this message before and it does not appear on my other machine that is still on Mac OS 10.5.5. Is anyone else getting this message?? Is there any way to resolve this issue so that my computer will be protected? Is Apple aware of this problem and is perhaps working on a fix??

Do a google search for *'ARP cache poisoning detection'* and read the various hits.

ARP Cache Poison reported in Norton AntiVirus for Mac

The MAC address from my new gen Apple TV is being tagged from Norton Antivirus as sending an ARP Cache Poison. Anything to care about, folks?

DNS cache poisoning affects certain versions of named and is used by miscreants to redirect access requests to sites they control. It's likely that the warning you're receiving is a false alarm, but it could be valid if either your computer or your ATV has been compromised.
Check Norton's web site or contact their technical support to be sure. It's not a warning I would simply ignore, as it would indicate a serious security breach if it's valid.

ARP cache poison

i hope that this is the correct forum, apologies if it is not.
I constantly get a Norton "vulnerability blocked" notification because of ARP cache poison. I am assuming that this is a function of my OS, if not I will contact Symantec. Does anyone know how to get rid of this annoyance short of disabling Norton?

Remove Norton. It's a known troublemaker on Macs and there's very little for it to find - no viruses and only a few easy-to-avoid trojans. See my [Mac Virus guide|http://www.reedcorner.net/thomas/guides/macvirus> for more information.
If you're worried about your security on the network against hackers, make sure your machine is hidden behind a router. If you're using a wireless network, you're already hidden behind a router, but make sure you're using WPA encryption on that network with a good password.

ARP cache poisoning error

Hi all,
I've googled and searched these discussions, but I can't find any pertinent info on this topic, so here's my question...
While looking into another issue, I noticed that my system.log had logged an error that concerned me:
*"Aug 4 12:03:52 localhost kernel[0]: Could not enable ARP cache poisoning detection. Your computer will not be protected."*
This message appears to only be logged on startup, and has been logged numerous times.
Does anyone know why this protection is disabled, and how I can re-enable it, if that's even possible (or necessary)?
Thanks!

Do a google search for *'ARP cache poisoning detection'* and read the various hits.

Kernal message: Could not enable ARP cache poisoning detection.

Looking at system files in Console, for another issue, I came across this kernal message, which occurs at start-up: "*Could not enable ARP cache poisoning detection. Your computer will not be protected*."
It's an intel Mac Mini running Leopard ( 10.5.8 ). I have Norton Antivirus for Mac 11 installed (I know, I know), which has ARP cache poisoning turned on in its "vulnerability protection" prefs. I've gotten no warnings of attacks from Norton, just this Kernal message at start-up. I've seen this issue on a couple of other threads with no answer or solution (except advice to Google it... duh!), already archived and accepting no new posts... so no help there.
Is this ARP cache poisoning detection part of the OS, and if so, why is it not being enabled? Is there a way to enable it? Could the kernal message be telling me that the Norton protection is bugged and not working, or would it be OS related. The mini is a wired connection (ethernet), and there's one other laptop (macbook 10.4.11) using the modem/router ( Actiontec GT 701-wg) via wireless airport. I haven't seen this message on the laptop in console or system logs, but haven't looked hard.
Someone, please respond with a knowledgeable answer, for me and for others who've asked here and on other forums with no helpful public answers given.

Doing a "erase and install" of Leopard, thus dumping Norton AV 11, and then installing Snow Leopard... I haven't seen this Kernal message come up again, yet. I'll assume it was some buggy Norton related thing that cropped up after an OS update, but who knows. I'll leave the question open for a bit, in case anyone else has had this issue and found a reason or solution, and wants to share.

ARP cache

Hi !
My MacBook (466) kernel said (console):
"could not enable ARP cache poisoning detection..."
Do you know what the reason is and how to solve it ?
Best regards;
lachala

No it isn't the same and each are cleared independently. The arp cache is a layer3 database and used for a completely different purpose than the mac-address-table albeit complimentary. The arp cache provides the sending ip host with the mac address of the destination host and the sender builds the l2 frame with this info. Then when the frame gets to the switch, the switch benefits by having the mac address in the mac-address-table table so that it knows which specif port to forward the frame to instead of sending it out all ports the way a hub would.
HTH pls rate!

IPMP / ARP Cache oddity - Solaris to Windows comm errors

First - a qualification - I'm not an Solaris admin, so feel free to call me out for any blatant errors..
I've got several Solaris 10 servers that are having intermittent network communication issues with Windows 2003 servers on the same subnet. All Solaris boxes are using two NICs and IPMP for their connections to the "primary" network. For example, one server (hostname bugbear) has two adapters ce0 and ce9:
# ifconfig -a
ce0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
        inet 16.106.64.227 netmask fffff800 broadcast 16.106.71.255
        groupname shared0
ce9: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 4
        inet 0.0.0.0 netmask ff000000 broadcast 0.255.255.255
        groupname shared0
# cat /etc/hostname.ce0
bugbear netmask + broadcast + group shared0 up
# cat /etc/hostname.ce9
group shared0 upIf I look at the arp cache, (almost) every other server it talks to shows up twice - an entry for each of the NIC devices:
# arp -a
Net to Media Table: IPv4
Device   IP Address               Mask      Flags      Phys Addr
ce9    win2k3box.city.acme.com 255.255.255.255 o        00:50:56:ae:13:58
ce0    win2k3box.city.acme.com 255.255.255.255 o        00:50:56:ae:13:58I guess that's as expected - again, I'm not a Solaris expert.
Finally, here's the issue I've found. For any other UNIX/Solaris hosts listed in the arp cache, my server can ping/FTP/whatever to the other - no problem. Sometimes the ce0 interface is listed first in the output for the target server, sometimes the ce9 interface is listed first. Doesn't matter - my server can talk to the other just fine.
HOWEVER - for Windows servers, the order of entry in the arp cache seems to have relevance. If the ce9 interface is listed first, I can't ping, can't FTP, can't connect to the other server. If the ce0 interface is listed first, then everything works fine.
Eventually the arp cache entries age out and get deleted. Usually then my server can talk to the Windows server again. I also found that if I delete both arp cache entries for the target Windows server, my server can talk to it again (arp cache gets rebuilt with the ce0 interface). If left alone, the behavior seems to be that my server can talk to a Windows target for an hour or two, then it can't for another hour or two, then the cycle repeats.
NOTE - The mac address in the arp cache is not getting poisoned, as with the Broadcom windows driver issue that hit some folks (myself included). All the mac addresses for the servers in the arp cache are consistent as best I can tell, so that's not the problem.
Any input/suggestions greatly appreciated.

Here are the codes:
In the initializing stage,
     try {
          this.serialPort = (SerialPort) portId.open("SimpleReadApp", 2000);
     } catch (PortInUseException e) {
         e.printStackTrace();
     this.serialPort.notifyOnDataAvailable(false);
     try {
        this.serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE);
        this.serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_NONE);
        this.serialPort.enableReceiveTimeout(10);
//this.serialPort.disableReceiveTimeout();
//this.serialPort.enableReceiveThreshold(0);
        this.serialPort.enableReceiveThreshold(1*1024*1024);
        if (this.serialPort.getInputStream() != null)
                this.inputStream = this.serialPort.getInputStream();
        else
                System.out.print("can not get inpustream!\n");
      } catch (Exception e) {
              e.printStackTrace();
      }Then in the reading stage, we have:
    byte[] readBuffer = new byte[1 * 1024 * 10];
    while (true) {
          try {
               int numBytes = inputStream.read(readBuffer);
               System.out.print("There are " + numBytes + " bytes having been read.");
          } catch (Exception e) {
              e.printStackTrace();
          }The above codes do not have any problem using COMM API 2.0 on Windows. Or COMM API 3.0 on Solaris. But, on RedHat, it can run out of memory very quickly.
Edited by: EJP on 13/05/2011 11:27: added { code } tags. Please use them.

ARP cache not adding MAC address

Hi,
We have a network in the company where visitors\customers can connect their PCs to pick up a IP address & access the internet via our cluster of Checkpoint firewalls. The problem we are having is that whenever somebody with a Mac tries to use this network they cannot access the internet although it works fine for all Windows based PCs. So to investigate I got hold of a IBook & made the following observations.
The gateway provided by the DHCP servers is a IP address (192.168.48.203) on a multicast mac address that represents both of the firewalls, which in turn have a physical address of 192.168.48.201 & 192.168.48.202 respectively. This is done to provide redundancy.
What happens on the IBook is that it picks up a DHCP address as well as the DNS & gateway address as supplied by the DHCP server, but then when you try to access the internet you have no joy. If you check the arp table you will then notice that the table have not been updated with the mac address of the 192.168.48.203 gateway. If you then manualy add the mac address of 192.168.48.203, using arp -s, it works fine or if you staticaly configure the IP address settings to use either 192.168.48.201 or 202 as gateways (which have unicast mac addresses) it also solves the problem & immediately updates the arp cache with the mac addresses of either of these two interfaces depending on which one you are using.
We put a sniffer on the network & could see that the mac address for 192.168.48.203 is being passed on to the IBook but for some reason it just does not update the arp cache with this details. Also tried this on some of the other networks we are running that uses the same concept & the same thing happens. As I mentioned no Windows hosts are having this problem & immediately updates their arp details to include the mac address of the .203 address.
On a Mac after obataining a DHCP address & running "netstat -r" you get the following:
Internet:
Destination Gateway Flags Refs Use Netif Expire
default 192.168.48.203 UGSc 5 5 en1
127 localhost UCS 0 0 lo0
localhost localhost UH 9 2477 lo0
169.254 link#5 UCS 0 0 en1
192.168.48/22 link#5 UCS 1 0 en1
192.168.48.203 link#5 UHRLW 4 30 en1
192.168.51.1 localhost UHS 0 1 lo0
Then after adding the mac address manualy it looks as follows & works fine:
Internet:
Destination Gateway Flags Refs Use Netif Expire
default 192.168.48.203 UGSc 26 6 en1
127 localhost UCS 0 0 lo0
localhost localhost UH 9 12353 lo0
169.254 link#5 UCS 0 0 en1
192.168.48/22 link#5 UCS 0 0 en1
192.168.48.203 1:0:5e:7c:0:48 UHLS 26 28 en1
192.168.51.1 localhost UHS
Any ideas why this is happening ?
Regards
IBook G4 Mac OS X (10.4.3)

Hi,
I am facing exactly the same problem here with an iMac G5. I have called the apple support and the conclusion was that they have no clue for that and we should wait for an update that will hopefully resolve this.
I was also aksing them if there was a way in the mac to set a static mac address for the gateway in the macintosh so I don't have to run the terminal and type the arp -s every time I start up. They said it is out of the kind of support they can provide... Do you have an idea on how to add a static ARP entry in the table ?
Thank you.

Force mapping to a specific MAC address a multicast IP address in ARP cache table with netsh

Hi all,
I would like to know if there is any solution (netsh option, registry entry, whatever...) to force mapping a given MAC address to a multicast IP address (224.x.y.z) in my ARP cache table.
I am doing the following:
netsh.exe interface ip add neighbors "Ethernet" "224.224.xxx.yyy"
"00-80-EE-UU-VV-WW"
But the entry in the ARP table is substitued by the calculated multicast MAC@ corresponding to my multicast IP@ :
netsh.exe interface ip show neighbors "Ethernet"
Interface 12 : Ethernet
Internet Address
Physical Address Type
224.0.0.22
01-00-5e-XX-YY-ZZ
static
224.224.yyy.zzz
01-00-5e-UU-VV-WW
static
(For information, calculation of the Multicast MAC Address is described in RFC1112§6.4 -> The MAC@ equals 01-00-5e + the last 23 digits of the multicast MAC Address)
My problem is that I'm not using an Ethernet network but an AFDX (used on Airbus A380, Boeing 787 Dreamliner, by the NASA...). This network topology is a deterministic Ethernet. The network must know accurately where each network packet is going. Thus...
the multicast MAC@ cannot be accepted and packet destinated to that MAC@ are not going anywhere.
So, I must match accurately my multicast IP@ to my MAC@ (00-80...).
It used to work with Windows XP (which was not doing any "magical" MAC@ substitution on multicast IP@), but since Windows Vista, netsh is doing the substitution described above. Is there any way to disable this substitution or force my IP
to MAC mapping in ARP table? And of course, I'm not using XP anymore ;)... but a tablet with Windows 8.1.
Thanks for any help.
Cheers,
Olivier.

Hi,
The article you pointed me to is just an explanation of what I said in my original post : "Multicast MAC Address is described in RFC1112§6.4".
But, as I said in my original post, this is true ONLY for Ethernet network. And I am NOT on an Ethernet network.
So MAC address automatic calculation for my IP address done by Windows/netsh/arp is wrong in my case. The calculation Windows is doing is correct ONLY for Ethernet network. Since I am not on Ethernet, I don't want these calculations, and I'm looking for
a solution to disable them.
So, the underlying question is : "Is Microsoft/netsh/arp able to handle other network's type than Ethernet ?"
Thanks,
Olivier Dupré.

Clear arp-cache to ping

I have an SMS server on my network that is unreachable from vlans other that its own. This happened after we pushed out tumbleweed via SMS. Now, in order to ping the server I must issue a clear arp-cache in the core switch, this only last for about 1 min and then the SMS server is unreachable again. Any help would be great.

Thanks Dabels,
I have had this problem as well, it turned out to be a pix.
Proxy-arp is enabled by default on all interfaces and its not apparent in the config when its on or off. Its configured as a sysopt and therefore, it often gets overlooked.
Agree with everything you say, check the mac in the arp table of the server when your pings are failing, then trace the MAC you find there which corresponds to the ip address of the router.
Or check the arp entry in the router (again when its failing) and verify the MAC is the SMS server, it may just turn out to be a router or a pix or even....another server which is routing between a pair of NIC's, such as a unix box or a windows server.
Let us know how you get on.
Cheers
Shaun

What is a ARP cache and how do I clear this cache?

Each time I try to repair my internet connection it states, "unable to complete the repair because it was unable to clear the ARP cache. I do not know or am unable to find in any help file where or what this cache is. Assistance with this would be appreciated greatly. thank you

See:
* http://www.mydigitallife.info/2007/06/20/clear-delete-and-refresh-arp-cache-entry/

ARP cache entry of a switch

Hello...
I came across a particular question that got me a bit confused.
Please see attached for the network topology. Question: After HostA pings HostB, which entry will be in the ARP cache of HostA to support this
transmission?
a) Interface address: 192.168.4.7; MAC: 000f.2480.8916
b) Interface address: 192.168.4.7; MAC: 0010.5a0c.feae
c) Interface address: 192.168.6.1; MAC: 0010.5a0c.feae
e) Interface address: 192.168.6.1; MAC: 000f.2480.8916
c) Interface address: 192.168.6.2; MAC: 0010.5a0c.feae
e) Interface address: 192.168.6.2; MAC: 000f.2485.8918
The correct answer is D.
From my understanding, the source and destination IP doesn't change. If this is the case, why is the IP in the ARP cache not that of hostB?

Hi Rajtilak,
What switch are you using?
If it is a small business switch, ie SG200, SG300 etc do you use the CLI or GUI?
From CLI:
From Web GUI:
go to IP Configuration -> ARP then click add:
Remember to save your config changes. Hope that helps.
Best,
David
Please rate helpful posts and identify correct answers.

ARP cache needs clearing constantly

I help manage a WISP network which has a Cisco 3750 at its core and a couple of Cisco 7200 routers to two separate ISPs. We have configured public and private VLANs. The infrastructure is based on point to multipoint links with cisco SG300 switches at each main location. I have a problem where devices are not contactable until the ARP cache on the router is cleared or they are pinged from a device on the local LAN. It seems that as soon as the switch times out the address from the CAM tables, it will not respond until the ARP cache is cleared. A simple example is this.
router 10.201.1.1 --- Core switch --- switch 10.201.2.254 --- AP 10.201.2.55 --- CP 10.201.2.37 --- Customer x.x.102.37
All devices remain active up to the AP. The CP and customer will drop off the network randomly. I would expect the traffic to refresh the CAM table as per normal. The ARP cache on the router shows the exact same information before and after clearing so there is no spoofing or eroneous info there. This is not an isolated case, it is exactly the same across all of the other devices in the setup.
This has only become apparant since moving the devices to being managed in VLAN 201. prior to that, the client had everything (over 3000) devices in VLAN 1 with public IPs along side Private. Obviously a problem.
Anyone seen this sort of problem and able to offer any tips, ideas or suggestions? I am all out of ideas.
Thanks.
Marty

Just to add to this. I have read a lot of information about HSRP and having to synce CAM and ARP tables. I am not using HSRP and in this case, the second 7200 router is connected to a different ISP and operates completely separately.
In light of the information on HSRP. I have reduced the ARP timer for the two VLANs to 240 seconds, which being less than the CAM timer of 300 seconds means that the CAM table always remains up to date. I see this as a work around because it will obviously lead to a large amount of ARP traffic but it does seem to fix this problem. I am not sure why when the CAM table loses the MAC address, fresh traffic doesn't reach the switch and trigger the update of the CAM table. It seems like the traffic is not being sent to the right place.

ARP cache error

We have a SBS 2003 server running with a standard dual network configuration. One card for accessing the internet and the other card to connect the server to the local network.
We frequently lose our internet connection for an unknown reason (although the other card is fine and all client computers are still able to access the server -- they just loose internet access.)
We also receive the 'Clearing the ARP Cache' error message when trying to repair the connection.
However, instead of rebooting the server, we simply go into the Network Connections, locate the card that is for the internet connection, right-click and choose 'Disable', and then after it is disabled, right-click and choose 'Enable'.

Hi,
Before going further, would you please let me know if you have configured RRAS on your server? Based on your description, the problem can be caused if you are using RRAS as your basic firewall/NAT.
Please try the following suggestions to see if the problem can be resolved.
1. Firstly, we should make sure whether the network setting is correctly and properly configured. Please re-run CEICW Wizard on the SBS Server, it helps us automatically configure the network
settings, you can refer to this step-by-step article to finish the wizard:
How to configure Internet access in Windows Small Business Server 2003
http://support.microsoft.com/kb/825763/en-us
2. Please double check if you have correctly configured your DNS settings.
a. Leave the Default Gateway of the internal NIC blank on the SBS Server.
b. Configure both the internal NIC and the external NIC to use the internal DNS Service as the DNS Server.
c. On the DNS Server, create the DNS Forwarder to forward the external DNS resolution requests to the ISP's DNS
d. On the DNS Server, delete any public IP that is being registered in the local DNS.
3. Type "arp -d *" (without the quotation mark) from the command prompt. Then try repairing the network card again. If error still occurs, please turn to step 4.
4. Try turning off the "Routing and Remote Access" service, it can cause this problem.
a. Click Start->Run, type "services.msc", go and find "Routing & Remote Access", right click it and choose Properties.
b. Set start-up type to disabled and stop the service.
c. Then restart the computer which is mandatory in this case.
d. Try repairing the network card again, any luck?
If the problem persists, please help me gather the following information:
1. Does everything work normally before? If so, what changes have you made to the server/clients before the problem occurred?
2. Make sure that you uncheck "register this connections in DNS" check box from external NIC.
3. Confirm the connection binding order.
a. Please open Control Panel -> network connections.
b. Click Advanced -> Advanced settings
c. In the adapters and bindings tab, make sure that the internal adapter is on the top.
For your information:
A Description of the Repair Option on a Local Area Network or High-Speed Internet Connection
https://support.microsoft.com/kb/289256/en-us
Hope it helps.
Best Regards,
Andy Qi
Andy Qi
TechNet Community Support

ARP Cache Poison behavior by Apple TV

Similar Messages

Maybe you are looking for