5 ms·

Configuring a High Interactivity SSH HoneyPot

139 points by robputt796 10y ago

TheSpiceIsLife 10y ago
Congratulations you now have an SSH Honey Pot listening on the internet I've often thought about doing this, but it seems like a wildly bad idea for someone like me who doesn't work in the field. Anyone here who isn't a security expert tried this? How did it go?
- bcook 10y ago
  I ran an SSH honeypot and every connection showed me something interesting; username/pass, shell commands, source host, whether it was automated or being typed by someone, which hosts they used for file downloads. This was maybe 10 years ago though... the internet seems to be much more serious and less curious nowadays. Disclaimer: I am a wanna-be security hobbiest, at best.
- iraklism 10y ago
  Spin up a VPS install a honeypot and observe. You have nothing to lose. But please don't start mindlessly executing the various payloads people/bots will leave at this box.
  - jfindley 10y ago
    Be careful doing this - this may well be against the ToS of your VPS service.
esseti 10y ago
that's intresting, but i would probably put this honeypot on a cheap DigitalOcean instance or anywhere far from production/test enviroment (would be intresting if this is part of the tutorial, such as redirect to another ip onece successfully logged in in the ssh, don't know if it's possible). Beacuse life thought me to never think that you are smarter than others.
joantune 10y ago
Once upon a time, for the IT Security course, we decided to change SSH so that at any 3rd attempt it would allow an attacker in, stopped allowing other attackers in, and at the same time that we tried to have a kernel module that intercepted ICMP Echo's and gave the SSH session keys in it's reply (inspired on something similar on Phrack). We managed to get close to that, but we didn't get the session keys part :(
perlgeek 10y ago
It might be more interesting to run a honeypot inside your infrastructure, to detect intrusions into your network. The problem with honeypots is that they generally only attract very generic attacks, so they are only interesting for people who want to research the current attack landscape. Targeted attacks only go for valuable resources, so you'd have to make your honeypot looks valuable. So if you have an SSH honeypot inside your network, use 'git' or 'scm' or so as part of the hostname, and hope that people will think they can find source code there. By putting a honeypot inside your network, you tune out the noise of generic, automated attacks. So you get a much higher signal/noise ratio.
- jlgaddis 10y ago
  On a similar note, at a previous job (.edu) we had an intrusion detection system that sat just inside the firewalls that only watched outbound traffic. Overall, we received much more valuable (read: actionable) data from it than the external monitoring systems.
duck2 10y ago
> It is likely with these tell-tale signs and strange configuration not many hackers will stumble across the host, and if they do they’ll probably quit our right away. This got me thinking about setting all my hostnames to "honeypot" and randomly printing fake HonSSH logs in all SSH connections. Security by... mimicking?
- robputt796 10y ago
  Not sure if this is a good idea or not, security by obscurity never really fools anyone in my opinion... Anyway I think that the HonSSH logs are not visible to the attacker, they are on the man in the middle node so hence the hacker doesn't get to see them, for the most part it looks very very similar to a legitimate SSH connection.
  - 010001001010 10y ago
    I'd agree this probably isn't a great idea, -- it may attract unnecessary attention which would have not already been there. If an attack is automated (where it may not consider the hostname at all) it will have no effect. If it is a targeted attack, the attacker will most likely be well versed in the behaviour of default honeypots. As such if you're machine behaves differently (as it almost always will) the attacker will not be deterred. One example of this includes response time of a failed SSH login -- a HP might reply sub-seconds faster than a real system (especially true in industrial environments).
deleted 10y ago
[deleted]

139 points by robputt796 10y ago

Congratulations you now have an SSH Honey Pot listening on the internet I've often thought about doing this, but it seems like a wildly bad idea for someone like me who doesn't work in the field. Anyone here who isn't a security expert tried this? How did it go?

bcook 10y ago
I ran an SSH honeypot and every connection showed me something interesting; username/pass, shell commands, source host, whether it was automated or being typed by someone, which hosts they used for file downloads. This was maybe 10 years ago though... the internet seems to be much more serious and less curious nowadays. Disclaimer: I am a wanna-be security hobbiest, at best.
iraklism 10y ago
Spin up a VPS install a honeypot and observe. You have nothing to lose. But please don't start mindlessly executing the various payloads people/bots will leave at this box.
- jfindley 10y ago
  Be careful doing this - this may well be against the ToS of your VPS service.

esseti 10y ago

that's intresting, but i would probably put this honeypot on a cheap DigitalOcean instance or anywhere far from production/test enviroment (would be intresting if this is part of the tutorial, such as redirect to another ip onece successfully logged in in the ssh, don't know if it's possible). Beacuse life thought me to never think that you are smarter than others.

joantune 10y ago

Once upon a time, for the IT Security course, we decided to change SSH so that at any 3rd attempt it would allow an attacker in, stopped allowing other attackers in, and at the same time that we tried to have a kernel module that intercepted ICMP Echo's and gave the SSH session keys in it's reply (inspired on something similar on Phrack). We managed to get close to that, but we didn't get the session keys part :(

perlgeek 10y ago

It might be more interesting to run a honeypot inside your infrastructure, to detect intrusions into your network. The problem with honeypots is that they generally only attract very generic attacks, so they are only interesting for people who want to research the current attack landscape. Targeted attacks only go for valuable resources, so you'd have to make your honeypot looks valuable. So if you have an SSH honeypot inside your network, use 'git' or 'scm' or so as part of the hostname, and hope that people will think they can find source code there. By putting a honeypot inside your network, you tune out the noise of generic, automated attacks. So you get a much higher signal/noise ratio.

jlgaddis 10y ago
On a similar note, at a previous job (.edu) we had an intrusion detection system that sat just inside the firewalls that only watched outbound traffic. Overall, we received much more valuable (read: actionable) data from it than the external monitoring systems.

duck2 10y ago

> It is likely with these tell-tale signs and strange configuration not many hackers will stumble across the host, and if they do they’ll probably quit our right away. This got me thinking about setting all my hostnames to "honeypot" and randomly printing fake HonSSH logs in all SSH connections. Security by... mimicking?

robputt796 10y ago
Not sure if this is a good idea or not, security by obscurity never really fools anyone in my opinion... Anyway I think that the HonSSH logs are not visible to the attacker, they are on the man in the middle node so hence the hacker doesn't get to see them, for the most part it looks very very similar to a legitimate SSH connection.
- 010001001010 10y ago
  I'd agree this probably isn't a great idea, -- it may attract unnecessary attention which would have not already been there. If an attack is automated (where it may not consider the hostname at all) it will have no effect. If it is a targeted attack, the attacker will most likely be well versed in the behaviour of default honeypots. As such if you're machine behaves differently (as it almost always will) the attacker will not be deterred. One example of this includes response time of a failed SSH login -- a HP might reply sub-seconds faster than a real system (especially true in industrial environments).

deleted 10y ago

[deleted]