Every server with port 22 open gets hammered by bots trying to brute-force SSH. I built a honeypot that accepts every connection, records the credentials they try, and displays it all on a live dashboard with a 3D globe.
Some fun things you'll notice:
- Bots try the same passwords everywhere — "admin", "123456", "password" are the classics. Yes, you'll see the Spaceballs password in the top 10.
- Certain countries and ISPs dominate the leaderboards
- Attacks come in waves — sometimes nothing for a minute, then a burst of 50 from one IP cycling through a wordlist
- There's a knock-knock joke panel because I couldn't resist
Originally inspired by my kids asking "who keeps trying to log into your computer?" when they saw me tailing SSH logs.
The stack is Python (FastAPI + paramiko for the honeypot), Redis pub/sub for real-time updates, SQLite for stats, and globe.gl for the visualization. WebSocket pushes every knock to your browser as it happens.
The whole thing runs on a $6.75/year VPS. The domain costs more than the server.
Beautiful. Have you considered adding a "replay certain timeline" feature so that users get the feel of the throughput and emergence much like Gource [1] did for git?
Do you have any insight on SSH servers that only allow login with public key authentication? Do bots leave immediately when they see that they can't use passwords?
If the bot sees no login / password sequence, there’s no way for it to brute force credentials. If the server only takes ssh keys, that will cause an immediate disconnect. Which is why this setting is best practice when setting up a server when practical: PasswordAuthentication no.
My $6.75 per year VPS was a Black Friday sale from Dedirock on https://lowendtalk.com. Some of the Black Friday sales are still being honored. The site https://cheapvpsbox.com/ has a nice search engine for cheap VPS sales.
I recommend a dedicated $40 hetzner or OVH box and just keep all your projects on that. They're pretty powerful. I was spending a lot on a bunch of $5 linodes until recently and you have to keep them upgraded etc...
Very nice! I am looking forward to many people running this. Perhaps people could add their URL in a ./contrib directory or something to that effect? I might set this up when I get back from the feed store.
Nice idea. The original VPS is in Los Angeles, but I installed the app more recently on VPS's in London, Tokyo, and Amsterdam. I've been noticing some interesting regional differences, but it may just be smaller sample of knocks for those sites so far. I'll set up that contrib directory so that we can share our dashboards. I would be interested in looking at others' dashboards to suss out patterns.
I'm curious, how do you think this helps you answer the question? Proxies are incredibly easy to come by these days, rotation makes it hard to identify what's behind it all.
That’s a valid point. We can easily see where the attack is coming from but not who or which botnet. Some of these can be inferred by the pattern of usernames and passwords attempted, and the ISPs. Someone suggested that I collect the client SSH signature as well, which would help. But you’re right, we don’t know who is behind the attacks.
And I remember more than a decade ago I went down the rabbit hole hunting these bots and indeed, I found Netherlands was always the king of hill when it comes to bots, followed by US, Netherlands still there I see.
One of my favorite visualizations for this is to switch to the globe view and choose the “HEAT” style for a 3D heatmap superimposed on the globe. Green means few hits, and red signifies lots of hits.
The Netherlands is so small that it’s tough to see though!
Cool site, I think the fact that bots WILL try to get access to your server as soon as it's publicly available should be mentioned more in basic tutorials etc... I remember panicing when I had set up my first webserver as a teenager and was checking the nginx logs out of curiosity, I thought this was a real threat to the security of the server and almost shut it down lol.
I currently accept and then close/drop the connection "unclean" (no FIN or RST packet). I do this in hopes that the offender will waste some resources (time) thinking it is still connected while I spend minimal resources.
My reasoning is that if enough servers implement such measures it will become very costly for the offenders to scan.
Perhaps I can also add some logging to build a IP blacklist as described below.
Do you publish a list of the 'knocking' IP addresses anywhere? (abuseipdb.com was mentioned, maybe I need to just pay for their service for their 100k blocklist)
(I've mentioned this before on related HN threads) I've got a setup whereby any incoming connections to ports behind which I don't have a service running get logged, and periodically the log is filtered and the IP addresses extracted and added to a block list.
My theory is that, if there's traffic coming into a port behind which there's no service (and therefore there's absolutely no good reason for this traffic to exist), then it must be malicious. If it's malicious, then I have no reason to trust any data coming from that IP address.
Most IP addresses age out of the logs after 12 months. I also have lists of common internet scanners that I've got from my own curation of the logs plus other similar projects of others. I'm just protecting my little homelab, so I don't care whether I'm blocking an infected computers, computers running proxies, or blocking large swathes of the internet via ASN blocks. What I have setup is a pickaxe, where a lot of people really need a scalpel. Don't apply blindly!
(But I do think that if there was more aggressive blocking of the malicious traffic on the internet, then there would be more motivation for providers to at least attempt to minimise facilitating it - I admit that there is a fine line, and opinions on what is and is not malicious are subjective)
I'm reporting the bots that have visited to abuseipdb once per day, but yeah, there should be a free alternative. You aren’t the first person to have asked for this.
It would be trivial to write out a file that people can grab for free. What do you think would make the most sense? Plain text file, one ip per line, of offending ip’s within the last month? Or year? Or a .csv with the dates included? Generally I’m a big fan of simplicity.
Plain text file one IP address per line works for me. Simplicity for the win.
Within the last month is probably enough. If I was consuming it, I'd add each monthly list to a database so I can build up my own 12-month (or whatever time frame suits me) list over time.
Or, publish one list for the last month and one list for the last 12 months.
Some of the passwords definitely come from leaks, but adding 123 or 2026! to the end of a frequent username is a surprisingly common pattern. Lots of suffix variants: 123!, 2025, 2025!, @2025, @123, etc. In fact, the Trivia pane of knock-knock.net points out when the password is just the username plus a suffix.
This is very interesting to me, would most of these bots be running on servers that have already been compromised? If that's the case, is the Netherlands/Digital Ocean the most common combo as it's what most normal people use, or is there some other reason bots favour it?
Many/most of these are servers that have been compromised. DigitalOcean is certainly one of the biggest ISPs/providers; however, I’m betting that if you looked at ratio of knocks per ASN IPs registered, DigitalOcean would still be at the top. I’ll look into that.
Providers can shut down abusive IPs. I run a script every night to report attacks to abuseIPDB.com (included in the extras folder on the knock-knock GitHub repository). Some providers just don’t care.
And they should be shunned by everyone. We should all be naming and shaming such providers and those of us with any conscience at all will avoid using them. This is the only way to stop the tsunami of bad actors.
I wanted to ssh hello-hacker-news@knock-knock.net, but sadly it doesn't work because the site is hosted behind Cloudflare. You'd have to work out the true server IP address which is not easy to do.
Sadly? Intentionally! The IP is hiding behind Cloudflare mainly to make it much harder for the bots to figure it out. Blocking you from messing with the stats is just icing on the cake. :-)
I don't think hosting the site behind Cloudflare will affect the number of SSH brute-force attempts, these bots are just brute-forcing the entire IPv4 space aren't they?
Very interesting that DigitalOcean is by far the largest source.
Other (more responsible) VPS providers, e.g. Linode, actively block machines from which they detect a lot of abuse traffic. Wonder why DO doesn't do the same.
Something I've thought about is how does a VPS provider prevent this kind of thing?
Most of this kind of traffic goes by completely unknown and therefore unreported, so 'VPS host X' has no case to answer, to some degree.
If malicious traffic gets reported and 'VPS Host X' takes action and either contacts the operator of the VPS or shuts down the VPS following a traffic investigation, then the operator of the VPS creates another one on 'VPS Host X' or 'VPS Host Y'.
(all questions are rhetorical, not directed at parent)
Should VPS Hosts, by policy, block outgoing connections to port 22? Where is the line drawn for default blocking policies? Block everything and force the operator to configure a firewall to specify which ports the VPS can connect outwards to (or all ports)? At some point there will be friction that discourages customers and affects sales / profits, and therefore a disincentive to try to clean things up.
Secondary effects, more aggressive blocking of malicious traffic could potentially allow for some/more/better reputational differentiation between VPS hosts to offset loss of customers due to better security friction.
I doubt there's any legislation coming anytime soon to enforce a certain level of internet hygiene.
You're assuming the owner rented the VPS to run the but but it's more likely intended for something else and is infected with malware / some intern being cute. After all there are cheaper plans than DO.
The attempts started almost immediately, but they certainly accelerated over the course of the first few days. Initially, I think it was less than 1 knock per minute, but now it’s over 8. As a comparison, I set up https://amsterdam.knock-knock.net yesterday, and it is now at 2.9 knocks per minute.
The bots though scan through all the IPs on the internet, but perhaps they bias certain IPs (local / faster response? On the bots provider network?). Will be interesting to watch this over time.
If you are on the desktop, you should be able to scroll sideways either by choosing a menu icon at the top, or by clicking on a panel (which will rotate the panels to the left). On the phone you can visit a panel by choosing the icon from the rotating carousel at the bottom, or by swiping the panels to the left or right.
Now I want to see one where you let any login work but dump them at a fake shell that logs the commands sent. I’m curious what they do. Could even crowd source a mapping of command string matches to example output.
This is great. I run a server for my blog and can confirm idiotic bots continually hammer port 22. Sometimes I check my SSH logs just to see what is going on but I’ve never detected anything cleverer than trying common username/pw combinations.
It seems a little pointless, surely every server actually accepting SSH passwords has been 0wned year ago.
Even on a random port (well I picked port ___22) I get random SSH attempts.
My solution is convoluted: On my NAS I have a PHP form that accepts a password, when it's correct, set a flag (in the form of touching a file), and every minute a cronjob runs a bash script to check for the existence of the file: if it exists, then run a python script to talk UPnP to my home router to tell it to forward port ___22 to my NAS' port 22.
Hmm, probably running a VPN server, like WireGuard, makes more sense..
I have gotten what looks like SSH, TLS, HTTP, and other things, on various ports.
Another possible way would be port knocking. (I had previously set up port knocking on my HTTP server, but there seems to be a bug in the kernel (or in some driver) that prevents it from working correctly, so now the HTTP is not available. Using port knocking to restrict access to HTTP is probably not common, and might prevent your solution from being used if the form uses HTTP.)
I know, at some level, it seems crazy that the bots are spending so much time on this. However, there are plenty of machines on the Internet, and presumably most of these bots' machines were captured using this same technique.
OP here.
site: https://knock-knock.net
Every server with port 22 open gets hammered by bots trying to brute-force SSH. I built a honeypot that accepts every connection, records the credentials they try, and displays it all on a live dashboard with a 3D globe.
Some fun things you'll notice:
- Bots try the same passwords everywhere — "admin", "123456", "password" are the classics. Yes, you'll see the Spaceballs password in the top 10.
- Certain countries and ISPs dominate the leaderboards
- Attacks come in waves — sometimes nothing for a minute, then a burst of 50 from one IP cycling through a wordlist
- There's a knock-knock joke panel because I couldn't resist
Originally inspired by my kids asking "who keeps trying to log into your computer?" when they saw me tailing SSH logs.
The stack is Python (FastAPI + paramiko for the honeypot), Redis pub/sub for real-time updates, SQLite for stats, and globe.gl for the visualization. WebSocket pushes every knock to your browser as it happens.
The whole thing runs on a $6.75/year VPS. The domain costs more than the server.
Source: https://github.com/djkurlander/knock-knock
Beautiful. Have you considered adding a "replay certain timeline" feature so that users get the feel of the throughput and emergence much like Gource [1] did for git?
[1] https://gource.io/
Do you have any insight on SSH servers that only allow login with public key authentication? Do bots leave immediately when they see that they can't use passwords?
If the bot sees no login / password sequence, there’s no way for it to brute force credentials. If the server only takes ssh keys, that will cause an immediate disconnect. Which is why this setting is best practice when setting up a server when practical: PasswordAuthentication no.
2 replies →
This is neat. What VPS service do you use? I am trying to replace my tendency to spin up small EC2 instances just to deploy a simple web app.
My $6.75 per year VPS was a Black Friday sale from Dedirock on https://lowendtalk.com. Some of the Black Friday sales are still being honored. The site https://cheapvpsbox.com/ has a nice search engine for cheap VPS sales.
1 reply →
I recommend a dedicated $40 hetzner or OVH box and just keep all your projects on that. They're pretty powerful. I was spending a lot on a bunch of $5 linodes until recently and you have to keep them upgraded etc...
how deep are your WebApps? Cloudflare pages and workers have a generous free tier, depending on what you're doing.
Cool project
But also wanted to let you know about
https://objective-see.org/products/knockknock.html
And knockd: https://wiki.archlinux.org/title/Port_knocking
Common name in case you wanted to differentiate yourself a bit
I was aware of port knocking, but not the Mac malware scanner with the similar name. Good to know!
1 reply →
Very nice! I am looking forward to many people running this. Perhaps people could add their URL in a ./contrib directory or something to that effect? I might set this up when I get back from the feed store.
Nice idea. The original VPS is in Los Angeles, but I installed the app more recently on VPS's in London, Tokyo, and Amsterdam. I've been noticing some interesting regional differences, but it may just be smaller sample of knocks for those sites so far. I'll set up that contrib directory so that we can share our dashboards. I would be interested in looking at others' dashboards to suss out patterns.
5 replies →
> who keeps trying to log into your computer?
I'm curious, how do you think this helps you answer the question? Proxies are incredibly easy to come by these days, rotation makes it hard to identify what's behind it all.
That’s a valid point. We can easily see where the attack is coming from but not who or which botnet. Some of these can be inferred by the pattern of usernames and passwords attempted, and the ISPs. Someone suggested that I collect the client SSH signature as well, which would help. But you’re right, we don’t know who is behind the attacks.
4 replies →
Wow that's fucking beautiful, man. That's beautiful. Wow, I love that!
What $6.75/year VPS do you have?
Was gonna ask the same question. nearlyfreespeech perhaps? They're quite cheap. Haven't seen any other providers at a similar price point.
1 reply →
Awesome, I loved it thanks for sharing it.
And I remember more than a decade ago I went down the rabbit hole hunting these bots and indeed, I found Netherlands was always the king of hill when it comes to bots, followed by US, Netherlands still there I see.
Some things never change.
One of my favorite visualizations for this is to switch to the globe view and choose the “HEAT” style for a 3D heatmap superimposed on the globe. Green means few hits, and red signifies lots of hits. The Netherlands is so small that it’s tough to see though!
Well done, OP.
Cool site, I think the fact that bots WILL try to get access to your server as soon as it's publicly available should be mentioned more in basic tutorials etc... I remember panicing when I had set up my first webserver as a teenager and was checking the nginx logs out of curiosity, I thought this was a real threat to the security of the server and almost shut it down lol.
Personally, I just move SSH to a random high port on each of my public servers. Works like magic, no more log noise.
Great visualization!
I currently accept and then close/drop the connection "unclean" (no FIN or RST packet). I do this in hopes that the offender will waste some resources (time) thinking it is still connected while I spend minimal resources.
My reasoning is that if enough servers implement such measures it will become very costly for the offenders to scan.
Perhaps I can also add some logging to build a IP blacklist as described below.
Nice, are you using something like this?
Unfortunately this is still trivial to work around with a read timeout.
This is great.
Do you publish a list of the 'knocking' IP addresses anywhere? (abuseipdb.com was mentioned, maybe I need to just pay for their service for their 100k blocklist)
(I've mentioned this before on related HN threads) I've got a setup whereby any incoming connections to ports behind which I don't have a service running get logged, and periodically the log is filtered and the IP addresses extracted and added to a block list.
My theory is that, if there's traffic coming into a port behind which there's no service (and therefore there's absolutely no good reason for this traffic to exist), then it must be malicious. If it's malicious, then I have no reason to trust any data coming from that IP address.
This is based on OPNSense firewall rules and logs and is documented haphazardly here: https://github.com/UninvitedActivity/UninvitedActivity
Most IP addresses age out of the logs after 12 months. I also have lists of common internet scanners that I've got from my own curation of the logs plus other similar projects of others. I'm just protecting my little homelab, so I don't care whether I'm blocking an infected computers, computers running proxies, or blocking large swathes of the internet via ASN blocks. What I have setup is a pickaxe, where a lot of people really need a scalpel. Don't apply blindly!
(But I do think that if there was more aggressive blocking of the malicious traffic on the internet, then there would be more motivation for providers to at least attempt to minimise facilitating it - I admit that there is a fine line, and opinions on what is and is not malicious are subjective)
I'm reporting the bots that have visited to abuseipdb once per day, but yeah, there should be a free alternative. You aren’t the first person to have asked for this.
It would be trivial to write out a file that people can grab for free. What do you think would make the most sense? Plain text file, one ip per line, of offending ip’s within the last month? Or year? Or a .csv with the dates included? Generally I’m a big fan of simplicity.
Plain text file one IP address per line works for me. Simplicity for the win.
Within the last month is probably enough. If I was consuming it, I'd add each monthly list to a database so I can build up my own 12-month (or whatever time frame suits me) list over time.
Or, publish one list for the last month and one list for the last 12 months.
Keep up the great work!
1 reply →
If you are using fail2ban, is the amount of hits been reduced? Or you can see them anyway in the logs?
>user: claude password: claude2026!
>user: claude password: claude123
I wonder if these have come from leaks or if someone has a script that generates the top ~xx most likely passwords based off the username.
Some of the passwords definitely come from leaks, but adding 123 or 2026! to the end of a frequent username is a surprisingly common pattern. Lots of suffix variants: 123!, 2025, 2025!, @2025, @123, etc. In fact, the Trivia pane of knock-knock.net points out when the password is just the username plus a suffix.
This is very interesting to me, would most of these bots be running on servers that have already been compromised? If that's the case, is the Netherlands/Digital Ocean the most common combo as it's what most normal people use, or is there some other reason bots favour it?
Many/most of these are servers that have been compromised. DigitalOcean is certainly one of the biggest ISPs/providers; however, I’m betting that if you looked at ratio of knocks per ASN IPs registered, DigitalOcean would still be at the top. I’ll look into that.
Providers can shut down abusive IPs. I run a script every night to report attacks to abuseIPDB.com (included in the extras folder on the knock-knock GitHub repository). Some providers just don’t care.
Is this hosted on DigitalOcean, say in The Netherlands? Could it be that spam traffic within the same datacenter bypasses their detection?
> Some providers just don’t care.
And they should be shunned by everyone. We should all be naming and shaming such providers and those of us with any conscience at all will avoid using them. This is the only way to stop the tsunami of bad actors.
2 replies →
I wanted to ssh hello-hacker-news@knock-knock.net, but sadly it doesn't work because the site is hosted behind Cloudflare. You'd have to work out the true server IP address which is not easy to do.
Sadly? Intentionally! The IP is hiding behind Cloudflare mainly to make it much harder for the bots to figure it out. Blocking you from messing with the stats is just icing on the cake. :-)
I don't think hosting the site behind Cloudflare will affect the number of SSH brute-force attempts, these bots are just brute-forcing the entire IPv4 space aren't they?
2 replies →
Very interesting that DigitalOcean is by far the largest source.
Other (more responsible) VPS providers, e.g. Linode, actively block machines from which they detect a lot of abuse traffic. Wonder why DO doesn't do the same.
Hetzner would have blocked some of those pretty quickly. Especially the top 2-3 IPs that seem to have thousands of attempts.
This is great, now I can greatly refine my dictionary for trying to brute force knock-knock.net.
!!!
Good luck trying to log in via port 22. The real ssh port is located elsewhere and doesn't accept passwords. :-)
…but if it did accept a password it would be 12345.
Seems like DO sure has a bot problem. I wonder what percentage of their business is less-scrupulous actors.
Something I've thought about is how does a VPS provider prevent this kind of thing?
Most of this kind of traffic goes by completely unknown and therefore unreported, so 'VPS host X' has no case to answer, to some degree.
If malicious traffic gets reported and 'VPS Host X' takes action and either contacts the operator of the VPS or shuts down the VPS following a traffic investigation, then the operator of the VPS creates another one on 'VPS Host X' or 'VPS Host Y'.
(all questions are rhetorical, not directed at parent) Should VPS Hosts, by policy, block outgoing connections to port 22? Where is the line drawn for default blocking policies? Block everything and force the operator to configure a firewall to specify which ports the VPS can connect outwards to (or all ports)? At some point there will be friction that discourages customers and affects sales / profits, and therefore a disincentive to try to clean things up.
Secondary effects, more aggressive blocking of malicious traffic could potentially allow for some/more/better reputational differentiation between VPS hosts to offset loss of customers due to better security friction.
I doubt there's any legislation coming anytime soon to enforce a certain level of internet hygiene.
There is no such thing as a "good reputation" datacenter ip. They should all get blocked by anyone who cares about bots.
You're assuming the owner rented the VPS to run the but but it's more likely intended for something else and is infected with malware / some intern being cute. After all there are cheaper plans than DO.
> it's more likely intended for something else and is infected with malware / some intern being cute
Nah, DO offers free credits so threat actors just keep abusing that, it's really easy to make (or buy) tons of fresh trial accounts.
This is fascinating! Did the attempts start as soon as you started up the server, or did it take a little while to get going?
The attempts started almost immediately, but they certainly accelerated over the course of the first few days. Initially, I think it was less than 1 knock per minute, but now it’s over 8. As a comparison, I set up https://amsterdam.knock-knock.net yesterday, and it is now at 2.9 knocks per minute.
The bots though scan through all the IPs on the internet, but perhaps they bias certain IPs (local / faster response? On the bots provider network?). Will be interesting to watch this over time.
Very fun site. Cool idea indeed. I think it's a neat piece of art. I wish I could scroll sideways, though. The page got cut off for me.
If you are on the desktop, you should be able to scroll sideways either by choosing a menu icon at the top, or by clicking on a panel (which will rotate the panels to the left). On the phone you can visit a panel by choosing the icon from the rotating carousel at the bottom, or by swiping the panels to the left or right.
Now I want to see one where you let any login work but dump them at a fake shell that logs the commands sent. I’m curious what they do. Could even crowd source a mapping of command string matches to example output.
This is great. I run a server for my blog and can confirm idiotic bots continually hammer port 22. Sometimes I check my SSH logs just to see what is going on but I’ve never detected anything cleverer than trying common username/pw combinations.
It seems a little pointless, surely every server actually accepting SSH passwords has been 0wned year ago.
Even on a random port (well I picked port ___22) I get random SSH attempts.
My solution is convoluted: On my NAS I have a PHP form that accepts a password, when it's correct, set a flag (in the form of touching a file), and every minute a cronjob runs a bash script to check for the existence of the file: if it exists, then run a python script to talk UPnP to my home router to tell it to forward port ___22 to my NAS' port 22.
Hmm, probably running a VPN server, like WireGuard, makes more sense..
I have gotten what looks like SSH, TLS, HTTP, and other things, on various ports.
Another possible way would be port knocking. (I had previously set up port knocking on my HTTP server, but there seems to be a bug in the kernel (or in some driver) that prevents it from working correctly, so now the HTTP is not available. Using port knocking to restrict access to HTTP is probably not common, and might prevent your solution from being used if the form uses HTTP.)
I just disable SSH passwords and force using a certificate, which should be immune to bots barring some horrible unknown flaw in the ssh daemon.
Running over a VPN service would have the much the same effect.
I know, at some level, it seems crazy that the bots are spending so much time on this. However, there are plenty of machines on the Internet, and presumably most of these bots' machines were captured using this same technique.