I have developed a small script to show where attackers on Fail2Ban come from. If you are interested, I might be interested in posting it on github. The setup is actually not hard. It runs twice an hour via a cronjob and writes its cache into a folder on the server. Also Bans are being observed incrementally, to save CPU power.
You can view it here:
Any feedback is appreciated.
Looks amazing I want it! Jetzt!
Nicely done!
I am working on it live. Sorry, sometimes there is bugs breaking the display of the data… 
Here is a screenshot of the full dashboard in case it is down…
Looks great.
Thank you, I am interested in feedback what you guys need in day to day server security audits. I am thinking about implementing a Brute Force attack warning system which will send out E-Mails in case an attack is detected. If someone here has been struggling with such attacks I would like to know what they would like to see as options here. What kind of volume is crashing servers, how it could be prevented by automatically raising Fail2Ban parameters or shutting down countries (or implementing another form of check or slowdown) from which current attacks originate during a brute force attack.
The script should help admins understand how attack volume affects their servers. Right now there is a lot left to improve. It looks nice, but the functionality is pretty basic.
Good idea and good job. I’m interested. You can posting it on github ?
One think I like is that I could potential use the IP lists (csv, json) for my pfSense router to block IPs at the router.
Regarding your pfsense router you might be better off using a public database (1000 queries a day):
Integrating AbuseIPDB with pfSense allows your firewall to automatically block known malicious actors using the pfBlockerNG package. This setup creates a dynamic defense layer by pulling real-time threat intelligence directly into your routing rules.
pfBlockerNG-devel, and install it.https://api.abuseipdb.comDeny Both under List Action to block all traffic to/from these IPs.For advanced users, you can find further API parameters and documentation on the AbuseIPDB API v2 page. If you encounter memory issues with large lists, check the Netgate Hardware Troubleshooting guide.
thanks for the notes above.
The reason for grabbing the IPs from the “Fail2Ban Shield” is because then I can take locally flagged IP addresses from my web server and block them for my whole network, this will be in addition to all of the other block lists I have 1.4 million IP and 790,000 Domains 
Hey there @desisn.com
Nice project! The map and IP details are solid - I see you’re already pulling ISP, ASN, and rDNS which is great. The Shodan scanner showing up in your data is a good example of why that context matters. The service filtering is nice too.
Since you already have the ASN and ISP data, adding a simple category tag like “VPN”, “Hosting/Cloud”, “Residential”, or “Known Scanner” next to each IP would make it easier to spot patterns at a glance. The rDNS often gives this away already (like the Shodan example), but a quick visual indicator could help.
For mail-related bans, if possible, would be useful to include the client user-agent in the IP Details section when available. Dovecot and Postfix often log what mail client or script the attacker is using, and that can reveal a lot about whether it’s an automated tool or botnet versus someone manually poking around.
For alerts, a threshold-based notification when ban velocity spikes would be handy. You’ve already got the trend analysis in place, so tying an email or webhook to that wouldn’t be a big leap.
Would love to see this on GitHub!
Nice work !! 
Ok, I will try to implement your suggestions. Before I upload to GitHub I will do some more beta testing and try to improve functionality.
For example, add options to hide some modules, make sure all relevant Jails are shown. Make the script work on as many server configs and operating systems as possible. Add brute force warning E-Mail, make it possible for users to manually set limits or let the script decide whether a warning is sent out. Maybe let the script analyze server info like CPU, available RAM and factor this into the calculation.
I do not have any experiences with real brute force attacks though, so server admins that have had problems with them, could help me by telling me what information would be useful in case an attack occurs, how they are trying to stop the flood of requests and so on.
Yeah, glad to hear you’re expanding it!
Recent experience:
We had to deal with distributed SMTP AUTH attacks where hundreds of IPs hammering our servers simultaneously, each trying common addresses like “noreply@” or “sales@”. Each IP only fails a few times so they kinda stay under ban thresholds, but together they create a DDoS situation that servers get so overwhelmed legitimate mail slows to a crawl or stops entirely.
We’ve had to disable catch-all addresses and non-existent user bounces just to mitigate these attacks. Detecting patterns across IP ranges or subnets would be really valuable for catching coordinated attacks where no single IP looks suspicious on its own.
In one case we ended up rate-limiting at the edge router - tiered packet limits per second with bursts, adding offenders to a destination address list, and eventually just dropping packets at the DC level. That worked out great.
Yes !!! I Want to install
Ok, this is exactly the real usage experience I am looking for.I am just hosting low volume servers myself, except in rare occassions where clients are bigger and then have their own infrastructure and sys admins. I have never had any major problems besides some CMSes that got “hacked” by some unprofessional scripts for SEO spam. So these attacks could be prevented or at least give an early warning to the sys admins or owners of the site by having a pretty simple detection via this dashboard.
So I will try to create a warning via Mail option, that sends out as soon as an attack gets detected with parameters that have an automatic setting, but can be tuned manually.
I think you would benefit from incorporating abuseipdb and also reporting your abuses to abuseipdb. I use abuseipdb for statistical blocking and I report abuses using the free API. I never run out of capacity. Abuseipdb takes all the data from users to compute the threat. You could add to that with your data collection. I found that once I incorporate the data the threats almost disappeared to manageable daily level. The offending IPs are removed after a period of time if new reports are not received. There is no point holding IP blocks for much more than 4-6 weeks therefore having a revolving list that is perishable keeps the data relevant. You can also download their known IP abuse list (if you want to be proactive) and simply block the highest known abusers without waiting for an attack. I don’t do that because combining your type of collection with Abuseipdb has made the attacks almost negligible now. Nice job.