|
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
- Download
-
- Documentation
- How
To Install and Use (html@Sourceforge)
-
How
to Install and Use (pdf@violating.us)
-
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 (irc.freenode.net),
email us, etc.
-
02/22/03 - Jack Whitsitt (jofny)
BETA RELEASE
-
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)...to 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 violating.us page) the following URL's:
-
02/01/03 - Jack Whitsitt (jofny)
ALPHA RELEASE
-
There is enough working code to release my stuff as alpha for testing.
- The documentation is at: https://sourceforge.net/docman/?group_id=64718
- The files are at: https://sourceforge.net/project/showfiles.php?group_id=64718
-
- 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
Honeypots.net
- Security
Wizards - Honeynet
Intrusion Detection Systems:
Snort
- Hogwash
- Miscl Links
- Violating.us Home
-
Our
Sourceforge Page
- de-css.us
- please.de-css.us
- c4i.org
- 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. |
|