
Learn from your attackers – SSH HoneyPot - robputt
https://www.robertputt.co.uk/learn-from-your-attackers-ssh-honeypot.html
======
linsomniac
Aside: I used to run a small ISP, a 200-300 dedicated+virtual machines. We set
up our router to alert us if outbound SSH connections from a host went above a
certain threshold, which was a super reliable way of detecting if a host was
compromised. I think we had a near 100% success rate, because once a host is
compromised they use it to start trying to compromise other hosts.

But, we also had every customer on a VLAN, limited to only being able to send
traffic from their IPs, and also blocking incoming and outgoing bogon traffic.

Years ago I attended a presentation by Evi Nemeth (RIP) related to CAIDA and
one thing they found in auditing "backbone" traffic was that some huge
percentage of it was bogon traffic (I don't recall the exact number, but lets
say 10% +/\- 6%). Nobody wanted to filter that traffic because the pipes were
less expensive than the routers to handle filtering packets at high pps rates.

~~~
fujiters
You'll never really know your success rate though. You could have had machines
compromised for years with small amounts of traffic.

~~~
tobltobs
I guess he doesn't mean that he detected all infected machines but that near
100% of machines which triggered the alarm were indeed infected.

~~~
antoinealb
That's a bad metric though. You could miss a lot of infected hosts.

~~~
marcosdumay
That is the single most important metric when you want to create an alert.

------
X86BSD
I've been using something similar for a while now. I use pam_jail on freebsd
to drop the ankle biters using common ssh login attempts like test, ubuntu,
oracle etc into a FreeBSD jail where I watch what the do and get a copy of all
their tools. I rate limit the outgoing traffic from that jail to something
painfully slow to prevent them from causing any major issues. But being able
to fire up 'watch' on freebsd and snoop the tty they are on in the jail is
awesome for forensics.

It's secure, they can't break out of the jail.

It's rate limited to prevent them causing much damage to anyone.

It's easy to observe every thing they type and do in the jail from the host.

~~~
corybrown
What have you seen them do?

~~~
ConfucianNardin
Might have changed by now, but what they used to do was usually:

* Download a large file (e.g. XP SP3) from Microsofts servers to test bandwidth * Download IP scanners and trying to run them (in order to find new hosts to attack) * Download botnet code that connects to some C2 server

Tools they download were often downloaded as source, which they then tried to
compile in order to run it.

Searching for e.g. 'youtube kippo' will get you videos of honeypot sessions.

------
YouKnowBetter
I just harden my sshd config based on [https://github.com/arthepsy/ssh-
audit](https://github.com/arthepsy/ssh-audit) and ALL bots will fail since
they do not support the more current config os key-exchange, host-key,
encryption and message authentication code algorithms.

To make it even more interesting: one can actually see which bot is trying by
the way they fail to handshake.

I like a litte noice on my ports so leave ssh on its default port, accept
authentication only with a certificate and be done. Works like a charm. And
yes it makes my sshd stand out like a sour thumb since 99.9% (guestimation) of
you folks don't tighten up your ssh configs :)

------
otakucode
If one were to run a honeypot like this and take every IP which connects and
attempts a login and immediately ban it from your network, then if more than
1% of the IP range they are in has been banned, ban the entire range... what
would the expected outcome be for a typical residential user?

~~~
merb
in my first years I've setup a ssh server behind a nat'd network and installed
fail2ban. the outcome was that nobody could access the ssh server... probably
the same thing would happen, on ssh I've seen so many login attemts even on
the smallest VPS I've ever gotten, it's just ridicoulus and important to use
non password authentication with ssh (i.e. rsa keys probably 4096b).

~~~
logicallee
EDIT:

I'm withdrawing the question per the accepted answer below.

-

original comment:

>it's just ridiculous and important to use non password authentication with
ssh

Does this follow from the assumption (that you did not state) "since I won't
bother to create a high-entropy password"?

Granted its a fairly safe assumption if you're not trying too hard but SSH
supports passwords of arbitrary length so I'm curious if there's any other
reason, besides not taking the time to create a high-entropy password.

\-----

Accepted answer below (esp "Because your users cannot be trusted. I run
servers which coworkers, all developers, get access to.")

~~~
tokenizerrr
Because your users cannot be trusted. I run servers which coworkers, all
developers, get access to. It's either ssh keys or 2 factor authentication
because most don't give a fuck about security and will insist using garbage
passwords if not prevented from doing so (and then they will complain), even
though the use of a password manager is mandatory.

~~~
jlgaddis
> _... will insist using garbage passwords if not prevented from doing so ..._
    
    
      /etc/security/pwquality.conf
    

is how I prevent co-workers from doing so (on RHEL and derivatives).

~~~
tokenizerrr
Good to know. We do our user provisioning through an internal portal which
enforces everything. The ssh servers als gets configured to disable password
login so the only thing passwords are used for is sudo. All web stuff is
behind a SSO gateway with password+2fa.

------
knoxa2511
Reminds me of this Fishing for Hackers post [https://sysdig.com/blog/fishing-
for-hackers/](https://sysdig.com/blog/fishing-for-hackers/)

------
smokescreentech
Great post. Honeypots behind the firewall are also a great way to pick up
lateral movement and privilege escalation.

There's a ton of useful open-source tooling one can play with in the space.
Here's a list:

\- [https://www.smokescreen.io/practical-honeypots-a-list-of-
ope...](https://www.smokescreen.io/practical-honeypots-a-list-of-open-source-
deception-tools-that-detect-threats-for-free/)

Most of the projects are also small enough that you can easily contribute back
to them especially in terms of reducing the ability to fingerprint the
honeypots.

Somewhat timely, The Grugq just wrote up a nice article on Counterintelligence
for Cyber Defence:

\- [https://medium.com/@thegrugq/counterintelligence-for-
cyber-d...](https://medium.com/@thegrugq/counterintelligence-for-cyber-
defence-97d33503064d)

------
throwaway613834
Question: I've had an SSH server open to the world for months on a nonstandard
port. I've _never_ gotten any attacks logged on fail2ban, to the point where I
suspect fail2ban is either not logging the attacks or not operating
correctly... even though it logs every login I'm aware of just fine, so it
really seems like there really haven't been any attacks. I find this so
unlikely. Is this normal? Does no one scan high ports ever? Are there any more
plausible explanations?

~~~
tombrossman
Is this server running a recent version of Ubuntu and using systemd? Also,
have you verified that fail2ban actually blocks you by intentionally making
bad login attempts to trigger a ban? I do this with every new machine and
never assume it works until I can trigger it on demand. (test using a VPN or
set a very short bantime so you don't lock yourself out)

I ask because systemd may not be writing the failed login attempts to the log
file fail2ban monitors, which means fail2ban may not be responding to attacks.
I don't recall exactly how I resolved this, but I think I had to set "backend
= systemd" in my jail.local under the [DEFAULT] section header.

~~~
throwaway613834
Oh wow, thanks a ton for mentioning this. It's Ubuntu indeed but I seem to
have sysvinit rather than systemd from what I can tell. I have no idea how to
actually test it in a way that ensures I will trigger it though (since I don't
really have other setups that I can test the same method on and ensure I'm
doing it correctly). What do I have to do to trigger it? Just fail a bunch of
SSH logins in a row? (I have ssh, dropbear, pam-generic, and ssh-ddos
enabled.)

~~~
tombrossman
> What do I have to do to trigger it? Just fail a bunch of SSH logins in a
> row?

Yes, that's what I do. If you have SSH login via password disabled (you
should) then just temporarily move your private key(s) out of your ~/.ssh
directory and try logging in a few times. "ssh user@machine && ssh
user@machine && ssh user@machine" will do it if you have a ban set for three
failed attempts. If it's working, your target machine should no longer respond
at all, and connections will time out. If it's a web server the site should be
unreachable with your web browser until after the bantime passes.

~~~
throwaway613834
Ack, I figured it out. The ban does get triggered, but it doesn't succeed
because iptables doesn't work on my system -- some module isn't properly
compiled for the kernel. Thanks for helping me figure this out!

~~~
tombrossman
No problem, and this is a good reminder to test critical systems periodically.
Same goes for backups! Good luck.

------
spc476
Over a decade ago, I set up a tarpit [1] (I worked at a small web hosting
company) on an unused machine to catch network scans. I had the idea of using
the information gleaned from that to block IP addresses at the router level,
but never did get around to it.

[1]
[http://boston.conman.org/2006/01/07.1](http://boston.conman.org/2006/01/07.1)

------
Myrth
I almost closed the page on mobile because I thought it's empty or broken...

~~~
ryanlol
It's not any less broken on desktops.

------
shpx
[https://xkcd.com/350/](https://xkcd.com/350/)

~~~
shpx
Previous discussion
[https://news.ycombinator.com/item?id=11040512](https://news.ycombinator.com/item?id=11040512)

