OffensiveCountermeasures

Hacking back in degrees

Ways to mess with attackers heads.

Views: 292

Reply to This

Replies to This Discussion

Not sure if it should go here or perhaps under honeypots but I have been working on my own python attack / defense framework. It runs from a threaded queue and and pulls in functionality from plugins which can all communicated. Anywho, one of them watches for failed ssh login attempts and then after X failed attempts adds in rules in iptables to nat them to a running instance of kojoney which is an ssh honeypot.

It's really quite interesting to watch attacks live. I can't help but smile the whole time during the attack.

nmcbride
nmcbride: That sounds really cool. I'd love to hear more about how you set this up.
Sure!

So in a nut shell it works like this.

My parent daemon program launches and spawns (15 by default) threads that sit and watch a queue. Then the daemon loads all available plugins. Any that should be autoran it goes ahead and starts. I have two plugins for ssh that I change out as I feel like. Both work similiarly. Basically they sit and read my auth log using a regular expression looking for failed ssh attempts. Much like fail2ban does. When it see's 3 from the same IP, one plugin just puts a rule into iptables to block that IP for X amount of seconds. The other puts rules into iptables to nat all traffic from that ip address on port 22 to another port that I have the ssh honeypot running on. I setup the honey pot to use my ssh keys so the 'hacker' doesn't get alerted when I switch them on the fly. After the switch the honeypot takes over. When a rules is added into iptables a callback is setup to automatically remove that rule after a certian time period.

All the plugins are aware of each other so I can setup to do more actually. For instance when an ip fails a login 3 times I can trigger any number of other plugins as actions say perhaps one to do an nmap scan back on the ip, or one to pull whois information, or one to post it to irc, twitter, email to my phone, etc or one to send the ip to all my other computers running the daemon so they can just go and block it now. The sky is the limit.

But it's fun to watch and see my program react.

nmcbride

 

One the topic of ways to mess with attackers.

 

Ethan Robish, one of our hard working interns, has the unfortunate position of writing python scripts that we request.  Lately, Paul and I have been working hard to come up with ways to make life harder for attackers.

 

So, we had Ethan write a script that is a simple web server that serves up four random links, if you refresh it serves up four more.  If you click on a link, it serves up 4 more. 

 

Why?

 

Run a web crawler at it.

 

It is simple:

# python spidertrap.py

 

Then.. 

 

$ wget -r 127.0.0.1

 

 

There are a number of reasons we did this.  First, Ethan rocks.  Second, many tester simply run their automated tools over night.  This would lead to a very nasty surprise.  Finally, if someone was crawling a section of your site and they tripped on this you could generate an alert when it happens. 

 

We also found some very interesting behaviors when we ran a number of commercial scanners against it.  Some look for a 404 message and kill the session when it is not found (well done w3af) and other simply freeze.  Also, we discovered a number of situations where if you tried to kill the crawl, it killed the whole session.

 

As with any of the tools we release  we encourage you to  use caution.  I have yet to see exactly how google bot would react.  I assume they are smart about these types of things.  But angering the google gods may not go well.  Rather, I recommend running it on an internal network segment. 

 

Attachments:

Thanks for sharing John.  I'll build this into a plugin for my daemon. :D

 

P.S. - The hard drive I had the rainbow tables on aparently was mis-handled on my way home from the conference and wasn't working when I got home.  How annoying is that!

 

~Nate

 

strandjs said:

 

One the topic of ways to mess with attackers.

 

Ethan Robish, one of our hard working interns, has the unfortunate position of writing python scripts that we request.  Lately, Paul and I have been working hard to come up with ways to make life harder for attackers.

 

So, we had Ethan write a script that is a simple web server that serves up four random links, if you refresh it serves up four more.  If you click on a link, it serves up 4 more. 

 

Why?

 

Run a web crawler at it.

 

It is simple:

# python spidertrap.py

 

Then.. 

 

$ wget -r 127.0.0.1

 

 

There are a number of reasons we did this.  First, Ethan rocks.  Second, many tester simply run their automated tools over night.  This would lead to a very nasty surprise.  Finally, if someone was crawling a section of your site and they tripped on this you could generate an alert when it happens. 

 

We also found some very interesting behaviors when we ran a number of commercial scanners against it.  Some look for a 404 message and kill the session when it is not found (well done w3af) and other simply freeze.  Also, we discovered a number of situations where if you tried to kill the crawl, it killed the whole session.

 

As with any of the tools we release  we encourage you to  use caution.  I have yet to see exactly how google bot would react.  I assume they are smart about these types of things.  But angering the google gods may not go well.  Rather, I recommend running it on an internal network segment. 

 

One other quick comment, my distro and I'm sure some others have switched to python3.  I edited spidertrap.py and made it work for python3.  Maybe someone other than myself will find it useful.

 

~Nate

Attachments:

Do you have a working version of the framework you can share?

 

I would love to see it.

 

John

nmcbride said:

One other quick comment, my distro and I'm sure some others have switched to python3.  I edited spidertrap.py and made it work for python3.  Maybe someone other than myself will find it useful.

 

~Nate

Reply to Discussion

RSS

© 2013   Created by strandjs.   Powered by

Badges  |  Report an Issue  |  Terms of Service