What is the HiddenSSH IP Block List?

The HiddenSSH IP Block List is a live dataset of IP addresses identified through honeypot activity as engaging in brute force SSH attacks. It can be used to proactively block malicious SSH traffic.

How is the IP data collected?

The IPs are collected via HiddenSSH honeypots that monitor and log unauthorized SSH login attempts, credential sprays, and botnet behaviors.

Can I use this list with iptables or fail2ban?

Yes, the list is formatted to support integration with tools like iptables, fail2ban, firewalld, or even UFW. It's ideal for SSH intrusion prevention systems.

How often is the IP block list updated?

The block list is updated regularly with newly detected IPs and is made available as a downloadable CSV file with a daily timestamp in the filename.

HiddenSSH - Secure OpenSSH Hardening

IP Block List

SSH honeypot IPs

This section references IPs observed in SSH brute-force activity.

ssh honeypot ip lists for firewall blocking.

sshd exposure

Having sshd listening wide open, even with IP block lists is just plain stupid.
If you absolutely need public SSH access because users have constantly changing
IP addresses, set up a dedicated server or VPS as an SSH Proxy for users or administrators.

A; SSH Proxy needs a well maintained Firewall ssh block lists, fail2ban list.

NOTE: SSH Proxy has a static ip, but client has a dynamic, the SSH Proxy IP is whats gona show up on logs on the (server/router/vpc).

Allowed IPs

REJECTING ANY except (users IPs/IP blocks in reasonable ranges) <- People really need to pay attention to the last part.
If the block is larger then .255 IPs, dont add it.

It’s proper practice, avoiding attackers poking around in sshd socket.

Hardening/SSH Proxy

In an enterprise enviroment, having all dev,sysops, attached to there invidual IP. greatly increases the security
because an attacker would need access to the IP it self; and know what user name it belongs to.
This would be in the (server/VPC/Compute node/router) As defined in sshd_config:

AllowUsers user1@144.24.46.145

But in SSH Proxy Setup with wide open port, this would be used in stead.

AllowUsers user1@*

Wildcard means user1 can log in from any IP, but that only applies to user1.
This makes it statistically unlikely for an attacker to hit the right username, even if the socket is wide open.

With a dynamic IP but still in predictable range, this would be used in stead.

AllowUsers user1@144.24.46.*

This makes the SSH Proxy the weak link, but all servers, routers, and VPCs would have usernames attached to unique individual IP addresses.
Each user should only be allowed from their own unique IP (from the SSH Proxy/Own IP).

Firewall

Firewall Priority

Create iptables chains by priority, because rules are processed first-match-first-served.
This means that it reads from top to down, searches for the first match in the chains.
It’s non-trivial, in an (server box/server/instance/compute node), where limited amount of rules but strict rules are applied.
But in a (SSH Proxy/SSH Proxy Node) where the sshd is listening wide open, and massive amounts firewall lists are applied.
Its absolutely vital, seeing it makes big difference if you match it in 20th read from the array, rather then entry 20,500.
It keeps SSH latency manageable.

Note: Add your static IP, or a trusted subnet where your IP commonly changes. This allows the firewall SSH priority chain to match pre-approved critical locations first, reducing unnecessary latency compared to random Wi-Fi, unknown public IPs, or airport lounges you have never used before.

Extra caution: Some countries restrict or prohibit VPN use and may have very different rules around encryption. It is wise to todo (reverse DNS/IP resolution) of the SSH proxy IP, for example: proxy.company-name.net, to avoid confusion with local authorities.

Firewall Structure

Add core-ingress, and core-egress in INPUT and OUTPUT chains, as base services.
For rules like

-m conntrack --ctstate RELATED,ESTABLISHED -m comment --comment "core-ingress: allow established/related replies to connections destined for (IP)"

Add a priority chain near the top of the INPUT chain,
After that add priority chains for different services.
Then move into (traffic heavy rules/CPU Intensive rules) honeypot-ssh-ips, known-bad-ssh-attacks,
after that move into(local blocking chains/light size lists); into chains such as fail2ban-sshd-list.
Reasoning; otherwise honeypot IPs will hit the fail2ban trigger mechanism, but not the sshd it self, to avoid log flooding,
and not wasting CPU cycles on already processed IPs. (reference honeypot IPs)
It is important to keep sshd rules in the top as its considered a base service for remote management.

Note: fail2ban can ban IPs in many different applications, this text focuses on SSH only.

Firewall Chains Proper Naming Scheme

The common Fail2Ban convention is: f2b- so it becomes f2b-sshd (application+jail), and with dates f2b-sshd-20260428
But in the end, naming schemes are only important if multiple roots maintain firewall rules.
In private or small setups it would be more simpler to keep track of what is what, like adding banlist, month names, definations etc.. into the chain names.

Date Marking Chains

Good practice is to mark chains with dates, to simplify future mentainance. (brutforce IPs/honeypot collected IPs) Don't last bad for ever, attackers rotate IPs, botnets go down, etc.. for example: iptables-list-2026-01-01 and when compressed iptables-list-20260101.

Honeypot

Honeypot list

https://github.com/firehol/firehol/tree/master/html/ipsets

The repository contains collected data from SSH attack traffic, such as honeypot and brute-force attempts, and maintains an active IP block list.

https://lists.blocklist.de/lists/