Re:Configuring a High Interactivity SSH HoneyPot
by perlgeek on Monday November 28, 2016 @05:54AM
(#13054657)
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.
Re:Configuring a High Interactivity SSH HoneyPot
by jlgaddis on Monday November 28, 2016 @09:17PM
(#13060189)
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.
Re:Configuring a High Interactivity SSH HoneyPot
by joantune on Monday November 28, 2016 @05:52AM
(#13054647)
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 :(
Re:Configuring a High Interactivity SSH HoneyPot
by bcook on Monday November 28, 2016 @05:34AM
(#13054587)
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.
Re:Configuring a High Interactivity SSH HoneyPot
by esseti on Monday November 28, 2016 @05:39AM
(#13054604)
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.
Re:Configuring a High Interactivity SSH HoneyPot
by duck2 on Monday November 28, 2016 @06:00AM
(#13054678)
> 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.
Re:Configuring a High Interactivity SSH HoneyPot
by robputt796 on Monday November 28, 2016 @06:05AM
(#13054692)
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.
Re:Configuring a High Interactivity SSH HoneyPot
by 010001001010 on Monday November 28, 2016 @06:58AM
(#13054851)
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).
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.
We managed to get close to that, but we didn't get the session keys part :(
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?
Disclaimer: I am a wanna-be security hobbiest, at best.
You have nothing to lose. But please don't start mindlessly executing the various payloads people/bots will leave at this box.
Beacuse life thought me to never think that you are smarter than others.
This got me thinking about setting all my hostnames to "honeypot" and randomly printing fake HonSSH logs in all SSH connections.
Security by... mimicking?
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).