Skip navigation

Trapping Worms in a Honeypot

Is Nimda still attacking your network now and then? My Intrusion Detection System (IDS) continues to catch related intrusion attempts (two more as I write this editorial) even though weeks have passed since corrective measures came out. Many Microsoft IIS administrators still haven't plugged the holes in their systems. The attacks consume my bandwidth and cause log files to grow to unruly proportions. However, 2 weeks ago I found an interesting tool, called LaBrea, that can help slow the spread of worms on Windows NT and UNIX systems.

Tom Liston, LaBrea's creator, calls the tool a tar pit or a sticky honeypot because it's a lure that lets almost no intruder escape. When a robot intruder (such as a worm) connects, a LaBrea system traps that connection indefinitely by manipulating the TCP session parameters. Liston says, "The LaBrea server software allows a normal three-way handshake in response to a connect attempt. During the handshake, the server sets a small (5 byte) TCP window. When the client sends its first 5 bytes of data, the server responds with a TCP window of 0 (wait). The client then shifts into the persist state, where it sends what are called window probe packets at intervals that increase to a maximum of 4 minutes for an NT stack. The LaBrea server answers these probes to hold the client in the persist state. At this point, a connection can be maintained with a throughput of approximately 1215 bytes per hour. All of this can be done without maintaining any 'state' on the connections."

So using LaBrea slows the spread of worms. For example, to propagate, the Code Red worm spawns about 100 threads. Each thread scans IP addresses in rapid succession, looking for vulnerable hosts to infect—the potential to spread rapidly is enormous. But by capturing some of those threads as they attempt to infect your network, the LaBrea tool reduces the spread of the worm exponentially—a neat idea that really works! Be sure to look at LaBrea, but be aware that it runs only on NT and UNIX. Liston says he must address problems with the Windows 2000 TCP/IP stack before he can make the tool run on that platform.

Speaking of computer attacks, the results are in on a survey that InfoSecurity Magazine conducted in late July and early August 2001. The 2545 participants include security professionals involved in government, consulting, manufacturing and reselling, banking and finance, medical and healthcare, military, and education. One interesting finding is that the number of people who reported attacks against their Web servers has doubled since 2000—roughly half of those polled reported such attacks. The survey also tracks a 33 percent increase in the number of entities suffering buffer-overflow attacks, and almost 90 percent of the respondents suffered some type of infection by malicious code such as a virus, worm, or Trojan horse. The survey has lots of other interesting facts and figures—be sure to stop by and take a look:

I ran across an interesting document last week, "Best Practices for Secure Development," written by Razvan Peteanu. The 72-page paper, arranged in 12 sections, covers various topics including common mistakes, security in a project lifecycle, principles, services, authorization, technologies, languages, platforms, distributed systems, and tools. The document is a great top-level overview of those focus areas rather than an intricate guide. Nevertheless, it's full of useful advice and interesting anecdotes.

Hide comments

Comments

  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.
Publish