« The HoneyTank: a scalable approach to collect malicious Internet traffic | Main | Learning to Detect New and Unknown Malicious Programs »

Packetfence - GPL Worm Defense Tool

Packetfence is the name of a new worm defense tool designed for LAN security. Based on the overview, Packetfence looks like it can work in either of two ways. The "Layer 2" approach uses ARP poisoning to stop worm infected hosts from spreading any further. Using it as an inline bridge in the "Layer 3" mode you can basically use it like you would use the Snort plugin Snort-inline (now a part of the main Snort branch). From their website:

PacketFence provides interior worm mitigation and policy enforcement capabilities. PacketFence be placed strategically throughout the enterprise to compartmentalize networks that may present a threat to valuable resources: VPN concentrators, client and guest networks, extranet connectivity points, etc. PacketFence is designed to operate in heterogeneous where users are either unable or unwilling, without assistance, to secure their systems properly.

Looking at the pieces that you assemble (which are all open source), it looks like you have to keep your Snort installation updated to detect worm hosts, so reacting to new worms will always be slowed down a bit due to the time it takes to generate signatures. Secondly, by using ARP poisoning you effectively shut off all communications from those hosts, which can be an undesirable situation. Also, some low-cost switches don't react well to ARP poisoning, so you can cause more damage than good if you're not careful.

January 25, 2005 in tools | Permalink
Tell others: digg submit | del.icio.us this | Reddit

Comments

Thanks for the link! It looks like your link the overview isn't working properly, though.

I wanted to expand on the ARP poisoning comments in the original posting. We poison the ARP cache of the client with the MAC of the PacketFence system, so client communication isn't entirely disrupted - we can control it as if we were an inline device (since, at that point, we effectively *are* an inline device). The remediation content can be served up via IPTables passthroughs or proxied via Apache's built-in proxying functionality and mod_proxy_html to rewrite links.

We have not run into any issues with low-cost switches, although most of our test environment is made up of Cisco Catalysts. Could you expand a bit on that?

thanks!
Dave LaPorte

Posted by: David LaPorte | Jan 26, 2005 11:20:25 PM

fixed the link.

i've seen very low cost 10/100 switches (often without any management) do the following things in response to ARP poisoning: freeze, reset, or foreward everyone all traffic. poor design and poor coding on their part, yes, but a real concern nonetheless. i haven't seen a catalyst do this, but they're significantly more robust.

Posted by: jose | Jan 27, 2005 10:11:31 AM

I could see how bad things could happen if the frame src/dst was modified or if dst=ff:ff:ff:ff:ff:ff, but we've intentionally tried to avoid these issues by only spoofing the ARP data (while leaving the ethernet frame alone) and unicasting to unregistered/infected clients rather than broadcasting. To the switch, it should just appear as another frame.

Dave

Posted by: David LaPorte | Jan 27, 2005 5:02:32 PM

The comments to this entry are closed.