DDoS on LAN: How to Defend?

Question

DDos on a wired network has to be extremely rare, since the intruder has to be physically connected to the network. However, let's say that it still managed to happen. How would you be able to defend against it on a LAN? I'm curious as to how this is possible. I'm interested in exploring this further in my lab tomorrow because I should have some free time.

Answer 1

Much depends on what kind of attacks and on the network infrastructure.

"Smart" switches may be programmed to ignore, report, filter, or counteract some kinds of rogue traffic (ICMP amplification, ARP spoofing, IP/MAC forging) and sometimes also traffic in excess of a set threshold. If you have control of such switches, you can nip a (D)DoS in the bud or at least buy time in which the normal operations aren't too noticeably affected.

In case of a DDoS (as opposed to other sources of traffic excess), the business is more serious because you've also to deal with a potentially unknown primary attack vector (just how did they get infected? Can they get reinfected?) and a possibly large number of compromised machines.

If the DDoS-related traffic is recognizable, or sufficiently different from other traffic, you can try blacklisting it, or whitelisting the "clean" traffic; for example TCP connections to random ports can be alleviated by only allowing traffic to WKS and used ports and addresses.

If the traffic is more "tuned", e.g. rogue requests against internal authenticator services or the company Intranet server or email gateway, then you're out of luck, as you can't lock these services out.

You can still set up a limited defense by setting traffic rates on switch ports, or sometimes by forcing ports to go to 10M speed. On some servers, you can employ defensive tricks such as tarpitting in order to bog down the infected machines (or, with lots of luck, only the infection processes on those machines).

You might have to disconnect (even physically, i.e., turn off the switch) the more affected LAN segments and reconnect them after on site cleaning, which can be a disruptive and time-consuming proposition.

As a proactive measure, you may want to institute some kind of surveillance to detect abrupt bursts of traffic (which may point to a DDoS being tested or set-up) or unusual traffic patterns (e.g. a machine trying to contact other machines on unexpected ports, which could well be any port at all if employees' machines aren't expected to run server processes, or machines outside the network bypassing the approved proxy protocols). The latter could indicate a machine gone rogue and attempting to contact its command-and-control network, or doing so by mistake (e.g. a DDoS code reworked to run on an Intranet, but still running leftover subroutines for the wider world).

You might also want to look into honeypots, distributed honeypots and NIDS. In an Intranet, also honeytokens.

Open Source

To address Polynomial's concerns, I might add that the links above are supplied more in the way of examples: "smart" (more or less fully managed) switches are expensive gadgets and are not usually seen in SOHO deployments. Details and online manuals are then available only from names such as Cisco, HP, Netgear and so on.

So the "reaction" part of my answer above is unfortunately limited to "hefty" systems, while the majority of home users and small businesses will have to do with locating the culprits with ping or ARP queries and disconnecting them with a yank or a suitable LART; they have few other choices.

Nonetheless, there have been attempts to create Open Source solutions such as LISA or Open Source on commodity hardware solutions (MikroTik). Being designed for smaller networks, you won't find a RouterOS-running 48-port switch -- but you can get a 12 port design for USD 400 that has most, if not all, the capabilities of high end gadgets with twice or three times the cost per port.

From a professional point of view, though, I would not recommend those products unless I was also ready and willing to support them for a suitable amount of time (or unless I were to install them for my own use).

There are also projects employing commodity PC hardware together with multiport Ethernet PCI cards (e.g. this one that does hardware switching; others use different setups) that can achieve even better operation than corporate appliances thanks to superior flexibility - use the Source, Luke - or thanks to having a big ol' hard disk inside that can do lotsa caching. Of course, these setups are less reliable: hard disks fail much more often than FPGA fanless chips. The costs also, when all is said and done, aren't that smaller; but sometimes the added capabilities are worth it.

On the software side, most of the goodies are already Open Source. Snort can do NIDS as well as honeypotting and honeytokening, and while the already mentioned Nagios supplies commercial solutions, the core product is Open Source. At a less demanding level and not really germane to the question (even if there are automations for it), but still worth looking at, is Cacti. Others propose Zabbix, that has several interesting alert features (talking of being proactive, anomalies often pre-date failures by long enough to prevent the actual failure from occurring, or at least from doing serious harm).

Answer 2

The most obvious way is to locate the source of the attack and pull the cable. This shouldn't be too hard, since switches can report the amount of traffic they're handling in various ways (e.g. SNMP).

In terms of prevention, you'd take the same steps as you would on the internet - install rules that block IPs that send large numbers of SYN packets. Whilst this is still likely to make the first switch run slow, it segments the attack off from the rest of the network.

Answer 3

Locate the DDoS source and unplug the infected computer's LAN cable. If it's just some kid/friend playing with you then also lock his local account for a few days.