Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

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.

share|improve this question
add comment

3 Answers 3

up vote 1 down vote accepted

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, 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 *re*infected?) 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).

share|improve this answer
    
Good answer, but the abundance of corporate / product links makes me queasy. Could you look for some more neutral sources? –  Polynomial Nov 5 '12 at 9:15
add comment

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.

share|improve this answer
    
thanks! I will have to try this. –  SwaroopGiwali Nov 5 '12 at 7:30
    
If its a DDoS it won't be one source (isn't that what the first D is for?), and there s a great ICMP echo request attack called a smurf attack where you fire ICMP echo requests at the broadcast address with a forged IP address of target machine in the from field and let the whole subnet do the work. –  ewanm89 Nov 5 '12 at 9:02
1  
@ewanm89 Sure, but a DDoS on LAN doesn't really make much sense anyway. I was considering a scenario where someone infects all machines in a single office room, which would (likely) be connected to a single switch. My advice works for multiple geographically distributed attackers too, since you can just look at which switches are receiving spurious traffic. That covers the smurf attack too. –  Polynomial Nov 5 '12 at 9:14
    
yeah, or just firewall block echo-request to broadcast address. –  ewanm89 Nov 5 '12 at 12:19
add comment

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.

share|improve this answer
    
haha. I guess that is the simple solution! I was thinking more of possible defense mechanisms though. –  SwaroopGiwali Nov 5 '12 at 7:30
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.