Solution to ARP spoofing on 3560 and 2960 switches please

Run a sniffer, and disable any port with a machine that is responding to an ARP for the gateway address until that machine is fully remediated.

You might want to take a look at port security - i.e enfroce 1 MAC address per end-user port

Also look at see if the 2960 support the mac-move notification feature along with perhaps the mac-address secure feature

Hi,

This is what I have been doing since the problem arouse. But in a network like ours, with tens of buildings/subnets and thousands of users, I'll need around 25-30 network specialist to monitor and cure all the infections 7/24.

I hope there is a better and practical aprroach.

Thanks for the answer anyway.

Perhaps you might want to investigate Network Admission Control

Not sure NAC or mac filtering will help here. I would presume these are end-user workstations, that have a legitimate need to be on the network, on that port. Sure they can authenticate, or you can filter by port, but I don't get the impression this is rogue machines being tossed on the network. It sounds like this is user stations that have been compromised. Arp is a required portion of layer 3 networking, and you can't stop a box from arping or else it will stop working on the local network. I'm not sure if arp inspection fixes the issue (never used it), but if its not available on your lower end hardware, then you probably don't have any other options. You need to begin pushing these boxes to specific vlans where remission and patching can take place, and fixing the issue one at a time. I am not aware of a network solution to this desktop support problem given your hardware. Perhaps you could put a static mac address for the gateway on each box, but never thought about that before. But this just addresses the symptoms and not the issue, which is boxes that need to be repaired and secured.

I do not think there is any one silver bullet for this issue but deploying a number of the suggstions will certainly help to reduce impact

The only way to mitigate something like this is to make sure that you have virus protection software running on EVERY single computer.

You should also investigate using "DHCP snooping" to prevent rouge DHCP servers.

Sanal Kisi schrieb:

You will certainly need at least that many support staff if you let those infected clients freely roam your network. Isolating them automatically is your best bet, workload-wise.

If you don't have the staff for monitoring who's being blocked, don't worry, the affected users will let you know. :-) And if you don't have the staff for cleaning infected clients quickly, it's all the more important to have them off the net until they are dealt with, because otherwise they will go on infecting other clients (or worse), which increases your staff's workload even more.

HTH T.

Port Security may not address this specific issue. Although I haven't confirmed it, I suspect the infected system will send the ARP packets with its own MAC address in the frame, and only alter the "Sender MAC Address" in the ARP header. If this were the case, a Port Security violation would probably not be triggered.

Perhaps you could use a logon script that installs a permanent ARP entry on the PCs. The logon script would be centrally managed on the Server, and could quickly be amended if a default gateway was replaced (i.e.: change to the gateway MAC).

ARPs containing bogus MAC/IP mappings for the default gateway would then be ignored by the PCs.

Best Regards, News Reader

If the issue is as you describe and the spoofed ARP packets are restricted to falsely announcing the address of the default gateway then I would have though that Private VLANs would assist here? If there is no requirement for PC's to talk to each other (or directly to same VLAN printers etc) then it would seem a possibility.

If on the other hand the rouge devices are spoofing all ARPs then it would not fix it.

Hmmmm.

As already discussed this is not easily fixable from the network side however if there is no other option you could consider the following.

On the router use static ARPs. If equipment is not being moved about it might be the best solution for you. While this issue is resolved on the PCs. This means that the router has the correct ARP entries.

On the 2960s use Private VLANs (Edge). This will prevent the PCs ARPing to each other.

I have not though this all through but maybe it will give you an idea?

There are a variety of ways to approach this. Most will have cost, and it is down to you to work out what is the cheapest way of doing it.

You may wish to employ them in combination.

The first thing to remember is that the users are running infected devices on the network. Do you have a policy about that? If not you need a security policy. Make breach of the policy a disciplinary event, and fire a few people. Once a few people have been fired for breaches of the security policy, you may well find that the number of infected machines reduces somewhat. A good policy will provide help to users in running AV software as well as just threatening to fire them.

It may well be cheaper to replace all switches with 3560s to get the DHCP snooping feature than to throw the manpower at it.

Set up span ports and have some form of sniffer running capturing arp responses/gratuitous arps. That can help identify rogue devices. You still have to locate them and look at what to do with them.

Private VLANs may help - they will allow devices to talk to the router but nowhere else.

Smaller VLANs will contain any incidents. If you are using a /28 any rogue device has far fewer devices to interfere with than on a /22.

Hi,

relating to this problem, I found out that our 2960's have the command "ip arp gratuitous", which I though might help us reach the solution.

To my surprise, I found NO information in any of the 2960 documentations including the command references, within cisco.com.

Any help available ?

You're not focusing on the root cause.

You're looking for a "pill" to resolve all your issues.

Best Regards, News Reader

Hi,

you might try XArp2 to m> Hi,