Taken together, the criteria for banning for a given time over a given set of log files is called a jail, and there can be multiple jails. Multiple Jailhouse Blues ^įail2Ban isn’t just restricted to processing logs for one service. Some people may have wanted to only block SSH traffic from those hosts but in my view those hosts are bad actors and I am happy to drop all traffic from/to them. That blocks all traffic to/from that IP address. The “route” action simply inserts a blackhole route, as if you did this at the command line: Instead I sidestepped the problem by using the “route” action of Fail2Ban instead of the “iptables” action. I never did manage to come up with a way to control the firewall rules in Puppet but still allow Fail2Ban to add and remove its rules and chains, without there being modifications at every Puppet run. It was possible to tell it not to meddle with rules that it didn’t add, but it never did work completely correctly. At the time though, I was using the Puppetlabs firewall module and it really did not like seeing changes from outside itself. Now, it’s been many years since I moved on from Puppet so perhaps a way around this has been found there now. That worked great when the firewall rules were only managed in the config management, but Fail2Ban introduces firewall changes itself. First it was Puppet but these days it is Ansible. I’ve had all my hosts in configuration management for about 10 years now, and that includes the firewall setup. iptables Interaction With Configuration Management ^ By default, when Fail2Ban wants to block an IP address it will insert a rule and then when the block expires it will remove it again. It may cut down the log noise a little, but the advent of services that scan the entire Internet and then sell the results has meant that if you run an SSH daemon on any port, it will be found and be the subject of dictionary attacks. Putting SSH on a different port is not sufficient, by the way.
Also, even on the hosts that can have password authentication disabled, it is irritating to see the same IPs trying over and over. Sadly I have some hosts where some users require password authentication to be available from the public Internet.
Then, it does not matter how many times an attacker tries to guess passwords as they should never succeed.
Wherever possible, it is best to require public key and/or multi-factor authentication for SSH login. It is most commonly used to read logs from an SSH daemon in order to insert a firewall rule against hosts that repeatedly fail to log in.
0 kommentar(er)
