Is the network speed slowing down and the device connection abnormal?

Two days ago, our company suddenly had a network anomaly. At first, only a few computers could not open web pages, and no one paid attention. Everyone thought it was a temporary fluctuation. As a result, in just half an hour, the entire office network was almost paralyzed, and even the internal file server could not be connected.

It felt very strange at the time: the external network could be pinged, but the access was particularly slow, and the local printers, shared folders and other internal resources could not be connected at all. We started to check immediately.

My first reaction was to check the exit. The router and firewall were fine. Later, I checked the switch and found that the traffic in the LAN was abnormally high, with a large number of broadcast packets. Even more strange was that the bindings of many ports in the MAC address table were constantly changing, as if someone was plugging and unplugging network cables frantically. After further investigation, I found that the problem was with the ARP protocol.

The ARP workflow is as follows: PC1 wants to communicate with PC2 (knows IP, but not MAC)

Simply put, someone sent a large number of fake ARP response packets in the local area network, causing each device to write the wrong MAC address into its own cache. As a result, the entire network communication was chaotic, the traffic was full, and finally paralyzed.

Speaking of which, ARP (Address Resolution Protocol) is originally a very basic thing. Everyone in the local area network relies on it to find each other. But the problem is that the ARP protocol is inherently not designed with a security mechanism. Whoever sends a response, others will believe it. This time, a device (suspected to be infected with software or a misconfigured machine) continued to send fake ARP packets, messing up the local area network. As shown in the following figure:

ARP attacks are not new, but they are still quite annoying when they are encountered. Especially since our switches are a hybrid of Layer 2 and Layer 3, and ARP broadcasting is allowed to the entire VLAN by default. Once a problem occurs, the impact is very wide.

The solution is actually not particularly complicated:

Temporarily block the suspicious port to isolate the source of the problem


Check the ARP cache on key devices (gateways, servers) and clear it manually if necessary
Reload the static ARP table to fix the common IP-MAC relationship
Enable ARP protection on the switch, for example, limit a port to a maximum of a few MAC addresses, and automatically disconnect if more than a few MAC addresses are bound

After reviewing the incident, we found that the security configuration of the company's internal network was still a bit lax, especially the intranet. Everyone always thought that as long as there was a firewall, external attacks could not get in, and everything would be fine. As a result, problems occurred internally, and the impact was magnified all of a sudden.

This incident also reminded us of a very realistic problem: LAN security cannot rely on luck.

Although ARP attacks seem to be very "low-level" means, as long as the environment allows, the destructive power is no less than that of advanced intrusion techniques. Moreover, the implementation threshold is extremely low. Some network scanning and fishing tools have ARP spoofing functions themselves, and ordinary people can operate them after a little tutorial.

In the future, we plan to do several things to prevent similar problems:

Enable static ARP on core devices
Further divide VLAN to reduce broadcast domains
Enable ARP protection strategy for important intranet segments
Perform regular inspections of abnormal broadcasts and MAC address drift in the LAN
In general, security protection is not about waiting for problems to occur before remediation, but about laying a solid foundation on a daily basis. Even a small link like ARP, once something goes wrong, the consequences are far more serious than imagined.