The Bait and Switch Honeypot:
 An active and aggressive part of your network security infrastructure.

Project Team

Project Definition: The Bait and Switch Honeypot is a multifaceted attempt to take honeypots out of the shadows of the network security model and to make them an active participant in system defense. To do this, we are creating a system that reacts to hostile intrusion attempts by redirecting all hostile traffic to a honeypot that is partially mirroring your production system.  Once switched, the would-be hacker is unknowingly attacking your honeypot instead of the real data and your clients and/or users still safely accessing the real system. Life goes on, your data is safe, and you are learning about the bad guy as an added benefit. The system is based on snort, linux's iproute2, netfilter, and custom code for now. We plan on adding additional support in the future if possible.

Project Files:
Beta Release
How To Install and Use (html@Sourceforge)
          How to Install and Use  (
Rubicon Presentation on Aggressive Honeypots
    Other Project Links: 
    Bait and Switch Forums
    baitnswitch-users Mailing List


    News and Project Updates:

    04/17/03 - Jack Whitsitt (jofny)

    So - it's been ages since I've last updated this page. I've been alternatively too busy and too spent to do so until now. Rubicon happened - and it went over well, I think (a few mishaps, but aren't there always?).  Some items worth noting:
    • The presentation we gave at the conference is now up and available for your viewing pleasure. This supercedes the previous powerpoint available from this site.
    • The Justice Department has given us some additional credibility. "Instead, Salgado favors configurations where a hacker is invisibly rerouted to a honeypot after beginning an attack on a production machine. 'The closer the honeypot is to the production server, the less likely that it's going to have some of the legal issues that we're talking about,' he said, because the monitoring becomes part of the normal process of protecting the production machine."  The quote is from an article on Securityfocus' site.
    • Work on Bait and Switch is ongoing still, if a bit slower than previously. I have a lot of catching up to do on things I ignored while preparing for the con. There are some other people who you should be seeing updates from soon as the development of this tool moves from infancy to real deployment status.

    02/24/03 - Jack Whitsitt (jofny)

    Just a quick note on honeytokens (which have come up on the honeypots and focus-ids lists) - I think they are a really useful and interesting concept.  One of our next steps in this project is determining a good starting default snort configuration and I'd like to invite some discussion on how honeytokens might be applied via snort to Bait and Switch. This is for anyone currently on the Violating team as well as the world at large. Post something to the forums, visit us in #security (, email us, etc. 


    02/22/03 - Jack Whitsitt (jofny)


    So it's beta release day :) The final package is up, but largely unannounced. I've cleaned up the few bugs I knew about, added the blacklisting feature, tested and added features to electr0n's config script, and updated the documentation to the point where I think it's very useable and easy to understand.  

    I have also added a baitnswitch-users mailing list through sourceforge. Subscriptions requests can be made at:

    Please email me, subscribe to this list, or contact us through the forums at the sourceforge site if you are going to be using Bait and Switch, are interested in helping out, or have general comments.


    02/11/03 - Jack Whitsitt (jofny)

    I've released our final alpha package (5.3) before we go beta. There have been some huge switchcore and overall project improvements since the last update - I've just been too busy coding to get these news bits in fast enough. First off, for switchcore we now:
    • Run in 3 different threads: a main marking/DoS thread, an unmarking thread, and a logging thread. This allows us to keep unmarking while main blocks waiting for  new alert. It also protects us from slow disks while logging. 
    • Have logging code that is complete with the exception of one bug (truncates the final digit of the IP it's logging) 
    • Provide additional protection with Chk_net_dos . This is the second of the two DoS protection mechanisms. This one prevents too many IP's per time period to be rerouted. (The first, chk_mrk_dos, prevented unlimited auto rerouting of IP's)
    • Are able to configure variables from a user-configuration program without having to go into the sourcecode.
    While I was busy with switchcore, drolp (Jeff Ito) kindly contributed his time to porting the old spo_alert_shell output plugin for snort 1.8.6 (which I had hacked to use a FIFO pipe to talk to switchcore) snort 1.9.0. So now we can use current snort by issuing a patch command against the snort-1.9.0 tarball directory and then configuring snort. This also allows us to just include the patch for 1.9.0 with baitnswitch and drop the snort-1.8.6 tarball from our distribution package. This takes the size down from 9MB to 13k or so. Yay. :)
    Next (and related to the previous bullets) electr0n wrote a bash script for configuring the system without manually editing any source code or existing scripts. The new configure:
    • Takes in all local variables such as IP addresses, interface cards, etc
    • Automatically generates a routing script
    • Automatically adds the correct routing tables to a system
    • Allows users to specify DoS rate limiting settings
    • Patches the source for snort 1.9.0 with the Bait and Switch spo_alert_bns output     plugin
    • Configures the logging directory
    • Speicifes the name and location of the fifo file that switchcore and snort use to communicate.
    Next Steps to a beta release include: creating the blacklist system, recreating the documentation, adding some signal-based control to switchcore, adding site statistics to our we pages to verify that we really *are* just talking to ourselves here :) Also, looking ahead (not that far ahead) electr0n, Jason, and I are working on standardizing our rate limiting choices, data control systems, and testing standards. Jason's Hogwash code is on a separate track from ours (it has a different purpose, ultimately) but we're measuring the same things and giving the same speech.  More later - this update is way to long. 


    02/02/03 - Jack Whitsitt (jofny)

    I went ahead and added a new alpha release. This version of switchcore is daemonized, as most of the logging code finished, and the package directory structure was updated. 

    Also, our Sourceforge page was updated and made current. You can reach us at (in addition to the page) the following URL's:

    02/01/03 - Jack Whitsitt (jofny)


    There is enough working code to release my stuff as alpha for testing. 

    The documentation is at: 
    The files are at:
    Not everything has been implemented, but everything that has been implemented works. If you follow the instructions you should have a working Bait and Switch System.
    Notable things missing: 
    • Configuration files (have to edit source or scripts) 
    • Too-Many-IPs-per-timeperiod DoS limiting 
    • White/Blacklists
    • Logging

    Neat things that DO work now:

    • Correctly receives IP from IDS and marks source as bad
    • Schedules and correctly *removes* marking rule after an IP is good for awhile
    • Does not block while waiting for hostile IP's (this was a huge fix) 
    • Too many alerts from one source per time perdiod DoS protection 

    So - please - test this out! It should work fine :) :)

    01/22/03 - Jack Whitsitt (jofny)

    So...almost but not quite. No Beta release - all code is alpha quality and quite a few features are incomplete. I should have everything in CVS after the Violating Networks gathering in DC this weekend. However, the good news is that stuff is working, progressing, and moving far faster than I honestly expected it to. Perhaps 2 Mondays from now (Feb 3) should do the trick.

    01/12/03 - Jack Whitsitt (jofny)

    Beta release date estimate is one week from today (01/20/03). This comes from the fact that we now have code associated with the project. From work this weekend, we've zeroed in on four different release modules:

    • BNS Snort Output Plugin
    • SwitchCore
    • BNSRouting Configurator
    • Config/Rule Mgt Interface

    The output plugin is almost finished. I used anonpoets spo_alert_shell plugin (passes source ip of an alert to a shell command) and converted it to a FIFO named pipe output plugin. This lets me set up a program to listen on the other end for updates without dealing with disk access and program/script loading for every alert.

    The SwitchCore is going to take care of packet marking/unmarking and most of the DOS protection. After receiving a hostile ip candidate from snort, SwitchCore is going to maintain some soft of activity state and will use that to determine who has been marked bad for how long, who needs to be unmarked for being good, who gets blacklisted, etc. This is really the most complex bit and is the primary brain of B&S. Code is started and the marking/unmarking bit is done - just need to make it more intelligent.

    If SwitchCore is the brain of the B&S project, the BNS Routing Configurator is the heart. This module sets up the appropriate routing tables and iproute2 rules to handle the marked packets coming from SwitchCore and send them to the prod or honeynet machine without regard to dest_ip. Good or bad, everything flows through here. This piece makes me the happiest - it's elegant. What needs to happen for it is to have those rules scripted. Largely, I'm waiting on the final module (Config/Rule Mgt) to be done before I do that.

    The Config/Rule Management Interface is what will hopefully tie all these pieces together. There are certain differences between deployments that the end user is just going to have to select. I'd like to make this as easy as possible...we'll see how it goes. Also, there are some options in B&S to tweak as the end user sees fit. These include DOS protection thresholds, Blacklist thresholds, snort rule management, etc.

    Finally, we're including some honeypot configuration documentation pointing out suggested sources of information and best-practice repositories, as well as basic system readme's.

    Looking ahead, I strongly believe that we're going to be incorporating session state mirroring at the packet level. This will prevent tcp sessions from being disconnected when the switch occurs. There are pro's/con's to that, but I'm leaning towards the pro's. More discussion about this at a later date.

    12/30/02 - Jack Whitsitt (jofny)

    The iproute2/iptables combination is complete and sitting next to me - working like a charm. All that's left is the ugly process of making it repeatable and deployable as a package. A few people are working on that now - officially and unofficially. In other, related, news: electr0n, myself, and Anonpoet will be speaking at rubi-con about Aggressive Honeypots. We'll see how that goes. I'm looking forward to it, although it means that this thing needs to be all slick and tested by then. An upcoming project that I'm considering stems from the Bait n Switch conversations I've been having - namely some sort of concordance/collocation method to verify bad traffic. This would compare tcp sessions in much the same way that linguistic concordance works, or advanced virus statistical analysis. Haven't really checked if this has been tried much, or with success. {/stream of consciousness}

    Related Links
    Honeypots and Honeynets:
    The Honeynet Project
    Security Wizards - Honeynet

    Intrusion Detection Systems:
    Miscl Links Home
               Our Sourceforge Page
    rubi-con: We're speakers! (March 28-30 in Detroit)

    All files and project documentation are Copyright 2003, Jack Whitsitt and Alberto Gonzalez unless otherwise indicated.