Has anyone tried getting back at SSH scanner brats?

F

fonz

SSH servers connected to the Internet usually get "scanned" several times a day by script kitties, especially when sshd listens on the default port 22. Does anyone have any experience with running a honeypot or a tarpit, or perhaps with some other means of retaliation (or having a little fun with them)?

Edit: by "retaliation" I essentially mean having a bit of fun with the little buggers, not actively attacking back.
 
Ask yourself a couple of questions:
  • Can I trust the source addresses in the incoming packets of the scan attacks?
  • If I launch any kind of active counter attack will I be breaking some law?
 
Yes. I must admit, I'm guilty of retaliation. But a word to the wise: if you do choose the path of retaliation, do know, that you will only gain more attackers. Having said that, I did so, knowing I would be faced with more attacks, and had to schedule a time when I felt I could deal with the aftermath of additional hostile traffic. My choice of action, was the use of hosts.allow(5), spawning a script, whenever an attempt to use SSH was initiated by an unauthorized user/host. In short; the script flooded their host. But not in a traditional way. It rendered their host useless. Pulling their plug (Ether) was their only way out; short side of the reset button. <evil grin>

--chris

P.S. also works well for WWW services, but triggered by a different means (not hosts.allow(5)).
 
kpa said:
Ask yourself a couple of questions:
  • Can I trust the source addresses in the incoming packets of the scan attacks?
  • If I launch any kind of active counter attack will I be breaking some law?
Click to expand...
Point taken. But that wasn't entirely what I meant.

For starters, this brat is trying to break into MY house computer, where I have every right in the world to run a honeypot or tarpit. Don't like it? Don't trespass. It's as simple as that.

Active retaliation, such as hitting him back with a DoS attack or something, is usually not a very smart thing to do indeed for legal reasons and/or spoofing (which could easily make you the aggressor against an innocent party), that I agree with, but I was actually thinking more along the lines of a funny shell or something: a shell (or actually a program posing as a shell) that looks like a root shell but in actuality doesn't do a damn thing except making fun of any attacker and the things he (thinks he) is trying to do. Imagine this kind of session if you will:
Code: 
Welcome to foo.bar.org.
FreeBSD 1.0.1/amd64

# [CMD]ls[/CMD]
Really? You just got in and this is the first thing you come up with?
# [CMD]whoami[/CMD]
Ask your parents. How the hell am I supposed to know?
# [CMD]ps aux[/CMD]
I didn't hear the magic word. Try again.
# [CMD]exit[/CMD]
Thanks for playing, kiddo. Now brush your teeth, kiss your mommy goodnight and go to bed.

Connection closed by peer.
Or even a jail that allows root logins with no password, but the root privileges are immediately dropped upon login and the entire session is recorded just to see what this pesky little kid is trying to do.

In short: I'm thinking more along the lines of honeypotting/tarpitting, which I have every possible right to do, and maybe have some fun with the little buggers while I'm at it.
 
kpa said:
Are you aware that the source addresses can be spoofed? That is something everyone working with networking and firewalls should understand.
Click to expand...

Yes. Keenly. I have assisted several times with ISP's attempting to track down IP floods directed at me, that were "deflected" off of the IP range they were RP for. And I am proud to say the perpetrators were caught in every case. :)

--chris
 
fonz said:
Point taken. But that wasn't entirely what I meant.

For starters, this brat is trying to break into MY house computer, where I have every right in the world to run a honeypot or tarpit. Don't like it? Don't trespass. It's as simple as that.

Active retaliation, such as hitting him back with a DoS attack or something, is usually not a very smart thing to do indeed for legal reasons and/or spoofing (which could easily make you the aggressor against an innocent party), that I agree with, but I was actually thinking more along the lines of a funny shell or something: a shell (or actually a program posing as a shell) that looks like a root shell but in actuality doesn't do a damn thing except making fun of any attacker and the things he (thinks he) is trying to do. Imagine this kind of session if you will:
Code: 
Welcome to foo.bar.org.
FreeBSD 1.0.1/amd64

# [CMD]ls[/CMD]
Really? You just got in and this is the first thing you come up with?
# [CMD]whoami[/CMD]
Ask your parents. How the hell am I supposed to know?
# [CMD]ps aux[/CMD]
I didn't hear the magic word. Try again.
# [CMD]exit[/CMD]
Thanks for playing, kiddo. Now brush your teeth, kiss your mommy goodnight and go to bed.

Connection closed by peer.
Or even a jail that allows root logins with no password, but the root privileges are immediately dropped upon login and the entire session is recorded just to see what this pesky little kid is trying to do.

In short: I'm thinking more along the lines of honeypotting/tarpitting, which I have every possible right to do, and maybe have some fun with the little buggers while I'm at it.
Click to expand...

A good choice for course of attack. My favorite is echo(1), or bin/echo in combination with "twist". Simply always responding with OK can really frustrate (and confuse) a script-kiddy/hacker. :)

--chris

P.S. My "flood" retaliation was closely monitored, and I already had list of known IP's. So retaliation was never directed at innocent victims.
 
fonz said:
Does anyone have any experience with running a honeypot or a tarpit, or perhaps with some other means of retaliation (or having a little fun with them)?
Click to expand...
Some experience, though dated. From several years ago when I was still using Solaris 10/x86. Slightly offtopic: Solaris provided a feature called zones which I assume are comparable (to some extend anyway) to the Jails of FreeBSD. Basically an extra kernel thread which fully separated itself and provided a whole new userland. And thanks to features such as DTrace and Auditing I felt pretty confident to set up a honey pot of some sorts.

Basically re-routing every request for port 22 (tcp/udp) to the zone and setting up the zone with a root password you can find back literally in one of the many password dictionaries (for example the one provided with security/cracklib (just discovered it's also included with FreeBSD): /usr/local/share/cracklib).

My experiences are dated, but there are a few points I came to learn over the years. The most important one; no matter how sad it is: it's more than often a waste of time & energy to report weird sources and hacking attempts.

I traced back several IP addresses and domains and alerted several hostmaster, network managers and datacentre administrators. Needless to say with full network logs showing both their connection attempts (not merely related to SSH) and in the case of my "dogma zone" (the zones name was dogma, directly picked up from "Central Dogma"; a term used in the Neon Genesis Evangelion anime series) also full auditing logs. Sometimes you got an automated reply, sometimes people actually answered you, but in most cases the source IP would remain active and keep hitting your firewall.

Needless to say but I gave up on that.

Point two: Don't make it too obvious. Back then the .ro netblocks became very notorious, almost comparable to what .cn is now (maybe even more so), so obviously you shouldn't merely allow everyone access. At least block some well known sources of nastyness, that makes it look more real and makes your box look more appealing as well. Surely if you have something to protect then it must be somewhat good, no?

Point three: Don't bother with all the pre-made honeypot stuff. It may do its job and work to some extend, but I always compare it to using pre-made captchas: because they're well known they're also relatively easy to recognize and that only limits (or hinders) the results. For that reason I always use captcha routines I wrote myself; the major spammers don't know this routine, its hardly feasible for them to program around a routine so sparsely used and all of a sudden you find yourself pretty much protected from spam.

Last but certainly not least: it can be quite some fun, but whatever you do make sure that you know what the heck you're doing. Don't take shortcuts, because in the end you're taking somewhat of a risk with all this.

If you're not going to see it all the way through then it might be best not to bother with this stuff in the first place. But yeah; it can be really funny.

Its been ages, but I used my setup to collect sources of rootkits. So when someone got in and tried using wget or curl (sometimes even ftp) to grab his "l33t" hackertools it would actually give him an environment which logged everything, and put a rather nice virtual throttle on the whole thing. You know; making it look as if the download got in at speeds between 100b/second and 1kb/second ;) And when it finally arrived they got a renamed copy of nmap (the sourcecode package).

I actually need to laugh out loud when thinking back at re-reading the logs and audits I got. Some even tried to compile that stuff, you could almost imagine the surprised look on their faces :p

Final point: Realize that you are taking risks. I wouldn't do this on a home network or something, because if you piss people off big enough then you'll always risk them DDoSSing the living daylights out of you.

I don't know about you, but that's not something I'm really into any more these days. In fact, getting tired of crap like that was why I eventually stopped frequenting my, at that time, favourite IRC network / channel; due to the nastiness happening from time to time. To me it felt like I was wasting my time working around all that stuff, while I could be doing much nicer stuff. (having a dynamic IP address besides your more static IP address really helps in those cases).

That about covers my experiences. It can be fun, but you'd better think this through up front before diving into this.
 
Just drop port 22 at the edge and move on.

Just because someone else is probing your network it doesn't give you any justification to start probing or attacking back. The scan may well be coming from a compromised machine or bounced off a proxy anyway, and all you'll do by retaliating is further inconveniencing the victim in the middle.

All tarpitting will do is consume resources on your equipment (and waste your time setting it up) - the script kiddie running his attack from a botnet (or other machine(s) he doesn't legally own) won't really care.

Unless you're doing actual exploit research, in which case - well, your time is your own...
 
kpa said:
Are you aware that the source addresses can be spoofed? That is something everyone working with networking and firewalls should understand.
Click to expand...

Although true, spoofing a full TCP connection is very difficult to do in a lab environment, it's next to impossible to do over the Internet. Look up "blind-spoofing" and "sequence numbers". You can spoof the initial TCP SYN packet but this won't help much, you certainly won't be able to get a working three-way handshake. Not reliably anyway. In this respect UDP and ICMP are a lot easier to spoof.

That said, hosts that are running an SSH brute-force attack against your server are usually the victims of malware themselves. Most of the time the owner doesn't even know his server is doing it.

I tend to look up the abuse email address for that range and send them a few bits from my logs. The ISP will then contact the owner and hopefully get them to clean up.
 
I know that urge to respond with a length of 2x4 to these kiddies. Wrapped with barbed wire, nailed on with rusty old nails. But that is allowed to desire but forbidden to actually do.

Well, what a friend did in his company was keeping those busy.

He had port 22 connected to a VM which ran a somewhat patched system with a random root password. Every half hour the machine was shut down, all changes reverted (but logged) in the image, the passwords changed again to new randoms in the password files (loopback mount), and then restarted.

What happend is that kiddies got in, were able to waste some % of cpu and be kicked out soon after. And after they tried again, all passwords were changed, any backdoor is gone, everything is more or less as before. Which could mean that the intruder now is in the center of a microscope, being closely watched and tracked back. He said that reading the connection showed some intruders knocking again, breaking in again by the ways they used before, saw the cleanup and made a hasty retreat.

But maybe using eliza as a shell would also help some of the s-kiddies along :)
 
I guess this is more of a passive approach and not retaliatory, but I just recently started using net/kippo on an isolated spare box with an ipfw rule redirecting port 22 traffic to it. Kippo is a tar pit that runs as a kind of virtual machine. The really cool thing is that it also gives real-time logs of the sessions.

I set it up with a trivial root password and just let it run. Using Kippo's playlog script, the output of the logs can be very interesting/entertaining, not to mention pretty informative as to what tools the kiddies are using when they are able to successfully log into a box.
 
Thanks everyone for the responses.

First things first: perhaps I shouldn't have used the word retaliate in this context. I have no intention to actively strike back with e.g. a DoS attack or something, for obvious reasons. I intended the word retaliation to mean poking some fun at the kiddies.

I'll definitely have a look at net/kippo, as suggested by @pboehmer. And I've been thinking for a while about writing some sort of ELIZA-esque joke shell. Unfortunately AI isn't my strong suit, but over time I might still be able to come up with something entertaining.
 
Last edited by a moderator:
@fonz

Great topic! Thanks for starting the thread. I'm surprised it (or similar) wasn't started sooner.

--chris
 
Last edited by a moderator:
Those of you running honeypots - is your employer aware you are burning resources on this? Obviously only applicable if you are in a business environment...

Just curious, because running a honeypot is not "free" (processing - and thus power/AC, storage, admin overhead, security risk if they break out of your honeypot, etc.) and in terms of productivity output there is what exactly?
 
It always depends on argumentation and, of course, powerpoint.

When you as an admin are sure that the honeypot is, so to speak, standing in the middle of molten tungsten (which is not easy to melt because its melting point is high enough to vaporize iron), then you need to make sure this can be understood by management. Someone breaking out of the pot has no chance to do anything. Make that sure, make sure they understand. Then you need to deliver the numbers that show, by keeping them busy in their pot, they cause no harm and consume resources worth X. When not contained, they consume Y. Having the cleanup costs from the last break-in around comes in handy at this point. Make all this into a presentation, and then you can push it to management.

That's for honeypots. And it is not easy, I'd wager. But if you label it as intruder detection and attacker-slow-down service unit, you may be better off. When asked to shut it down you ask for a written order to lower the security level of the network by removing the intuder detection. Or, as those two monks found out when walking the gardens in prayer: One of them lights a pipe, the other one asks if he is allowed to smoke while praying. The bishop had denied to him the permission to smoke during the prayer times. The other responds that he asked the bishop if he was permitted to pray when he smokes a pipe, to which the bishop gave his permission.

So in the end, it's often a question what we call something. After all, connecting unpatched machines of any OS to the network is running honeypots also, is it not? Well, kind of, at least.
 
Sure, it's a tarpit and slows down attacks, but seriously - is there any benefit to the company? If you have a botnet attempting to compromise your network, you'll maybe take a node or two out of the attempt and the rest of the botnet will attempt to compromise your non-honeypot machines as per normal.

I.e., it doesn't prevent a compromise attempt on production, and costs resources to implement. Whilst it might be amusing for the admin, I just don't see the business case?

Again, I can understand if your business is in the networking space, as you can use it for attack analysis, but if your company doesn't do that as part of its operations then I just don't see the point.
 
Re-reading my previous post, I think I might have given the wrong impression about using net/kippo as a defensive tactic for scanning, that definitely was not my intent. I use it purely for educational reasons and mentioned it as just another tool in the toolbox. In fact, just about all of the successful "break-ins" resulted in the attempted installation of an IRC server (command and control?). But maybe, someday, I'll record someone trying to install a 0-day, who knows?

As far as any benefits in a typical business environment, nothing realistic that I can think of.
 
You must log in or register to reply here.
Back
Top