As I understand it, fail2ban reads logs and updates the firewall when it detects undesired activity. If this is how it works, why do I have a couple specific IP’s just hammering my box (evident from the logs) without being intercepted by the firewall first?
May 20 17:43:06 box postfix/submission/smtpd[13831]: connect from unknown[80.244.11.122]
May 20 17:43:07 box postfix/submission/smtpd[13848]: connect from unknown[80.244.11.121]
May 20 17:43:09 box postfix/submission/smtpd[13831]: warning: unknown[80.244.11.122]: SASL LOGIN authentication failed: UGFzc3dvcmQ6
May 20 17:43:09 box postfix/submission/smtpd[13831]: lost connection after AUTH from unknown[80.244.11.122]
May 20 17:43:09 box postfix/submission/smtpd[13831]: disconnect from unknown[80.244.11.122] ehlo=1 auth=0/1 rset=1 commands=2/3
May 20 17:43:10 box postfix/submission/smtpd[13848]: warning: unknown[80.244.11.121]: SASL LOGIN authentication failed: UGFzc3dvcmQ6
May 20 17:43:10 box postfix/submission/smtpd[13848]: lost connection after AUTH from unknown[80.244.11.121]
May 20 17:43:10 box postfix/submission/smtpd[13848]: disconnect from unknown[80.244.11.121] ehlo=1 auth=0/1 rset=1 commands=2/3
May 20 17:43:35 box postfix/submission/smtpd[13831]: connect from unknown[80.244.11.143]
May 20 17:43:37 box postfix/submission/smtpd[13831]: warning: unknown[80.244.11.143]: SASL LOGIN authentication failed: UGFzc3dvcmQ6
May 20 17:43:37 box postfix/submission/smtpd[13831]: lost connection after AUTH from unknown[80.244.11.143]
May 20 17:43:37 box postfix/submission/smtpd[13831]: disconnect from unknown[80.244.11.143] ehlo=1 auth=0/1 rset=1 commands=2/3
They are banging on my box as well. They even flooded my logs and I had to pay extra at my cloud provider just for logging the Virtual Cloud Network. You are viewing the mail.log there and this is just normal behavior for mail servers. If your cloud provider provides logs for your network, turn it off as they may charge you extra as the logs become larger and larger.
So you just get used to it.
Fail2Ban implements Jails, Filters and Actions and it does ban repetitive fake login attempts.
Fail2ban regularly scans log files for specific entries and bans addresses when it sees a certain number of that specific entry within a certain time. There are a lot of “bad actors” out there, and it is not unknown for bad actors to get past the MIAB fail2ban setup. Personally, I have permanently banned a small number of addresses, and have made the fail2ban rules a little more aggressive.
You can adjust the existing log file tests, or add your own. The grep patterns for the specific log entries are in /etc/fail2ban/filter.d/. These patterns are controlled by files in /etc/fail2ban/jail.d/.
You’ll need to do some man page reading (perhaps look at https://www.fail2ban.org/). And make sure you are very comfortable with grep regular expressions.
Be sure to take a copy of the config files before you tweak anything.
Note: Almost anything you change will be overwritten by the next MIAB update, so keep accurate notes and be prepared to redo your changes with each update. (Many parts of MIAB allow “local” config which persists over updates, but not fail2ban )
It’s not just on SMTP, they hit any open port in every way they can. It’s literally people with warehouses full of computer and massive bandwidth that’s for example standing idle because it’s a hot disaster recovery facility for a major corporation or something like that. They keep their computers and themselves entertained or gainfully employed by scanning every port on every possible IP where they can get a response from. Why - distributed bute force attach. They’re literally looking for keys and passwords that work. When they find one they can make a connection between the original text and the encrypted key, because the main feature of key encryption is that it cannot be reversed. So it doesn’t matter if where they get int with a password or key has nothing worth stealing. All they want is a list of keys and passwords that are in use. The other side of their “businesses” then take those lists and sell them to people wanting to break into places because they focus on being able to see the keys in their encrypted form so when they have a better chance of looking up what the actual key or password is.
Having said that, the fundamental shortcoming of fail2ban is that it’s looking at a single endpoint, so it’s scope is limited. There are service out there that pool fail2ban type information that will sell you a list of IPs that have been found to behave in suspicious behaviour. It’s an arms race, but you are welcome to participate.
What intrigues me about this is that there are such obvious things one can do to root out the problem once and for all but there doesn’t seem to be the requisite political will to get it done. I suspect that misbehaving internet citizens and the cyber security industry that’s tasked with dealing with the problem is keeping so many people gainfully employed that nobody can actually afford for the problems to get solved.
Just came here with the same question about the same ip’s. In fail2ban logs the ip’s are “found” but a ban is never triggered because it seems to be adeptly navigating around them. These are the rules triggered: [miab-postfix465], [miab-postfix586] and [postfix-sasl]. I added a ufw rule for now (sudo ufw insert 1 deny from 80.244.11.0/24 to any) but wondering if anyone has suggested and update to fail2ban rules ?
That’s the down-side of fail2ban. I see similar - I occasionally see obvious scans from subnets that get around fail2ban by only trying (say) 5 attempts from each host. This is obviously commercial hacking be cause someone paid for a significant block of servers with on the same subnet! Because fail2ban doesn’t understand subnets, them bad-guys still scan your box.
But if your box has reasonable security (good passwords) the scans are wasting as much of their time as they are of yours. Just make sure you enforce good password discipline on your users. if you’ve got users with admin/admin or john/password it comes back to you - and that’s mostly the kind of stuff these bad-huys scan for
(Perhaps rather than an outright ban, fail2ban could make connections from malicious hosts slower and slower, wasting more and more of their server time?)
Similarly, fail2ban won’t necessarily protect against large botnets, because they are comprised of many are individual hosts and blocking one doesn’t affect the others.
Sometimes I get narky and manually block a subnet - other times I let them bad-guys waste their server time!
Fail2Ban was never intended to block large IP ranges or even entire regions. There are other tools that can do that, such as Crowdsec. The goal of Fail2Ban is to reduce and/or slow down the number of possible login attempts from single IPs or maybe also small IP ranges.
If you use strong passwords, no one will be able to log into your accounts using simple brute force attacks, even if the attackers use multiple IP addresses. These simple bruteforce scripts will not be able to guess a secure password, and in most cases not even the correct username, even if they use a 1000 IP addresses and thus could reach 5000 attempts per bantime.
They are also not specifically targeting you, they are simply probing mail servers they find on the Internet for open relays or accounts like admin@domain.tld:password, and if they find one, they will likely use it to send spam.
So again, if you use strong passwords and don’t have an open relay, you’ll be fine and can basically just ignore the noise these bots create. However, it might make sense to increase the bantime in order to reduce the noise at least to some extent.
Yes, that might help reduce the noise as well, but I would not go larger than /24, because if you block IP ranges that are too large, you might also block legitimate IPs, and more importantly, Fail2ban might run into performance issues if too many IPs are blocked at the same time.
Btw. the latter should also be considered when increasing the bantime. I have set it to 1 week on all my public servers, and haven’t had any issues so far, but I only did that for SSH, and I don’t block IP ranges, only individual IPs.
I have two ways on top of what Mailinabox offers to handle “bad” ips:
I found a tool on github that scans the fail2ban log. If multiple ips from the same subnet are triggering fail2ban rules, the tool automatically blocks the whole subnet. E.g. a /29 to block 8 ips
I use blocklists from e.g. firehol_level1 to block all incoming traffic from ips on that list.
Because of the tools, I have no manual work on this. This together makes for a very quiet fail2ban log. I have about 500 entries in the log which is a lot less than before.
Mmm, I have no good write up, might take a while. I also think it would be good if you know what you are doing, so I provide a rough guide
DISCLAIMER: Just to be clear, I’m not going to support anyone if they break their system using anything mentioned in this post! Use at your own risk, might eat all your cookies. I might answer small questions if you ask nicely though
I’ve not encountered any issues as far as I’ve seen. But carefully considering what you do is recommended. I like this stuff as I’m forced to dive into it and really understand what I’m doing and not just blindly installing a script from random guy on the internet. (yes, I see the irony having just dumped a link to a script in my post above )
)
)