32

Try installing fail2ban from EPEL. It's packaged for CentOS 7 and you'll get updates as they are released. Installing the rpm form another repo may work (it did in this case) but is not the best way of doing things. First of all, install the EPEL repository by issuing the following (as root): yum install epel-release The above should install EPEL and ...


15

Updated answer As of version 0.10.0 fail2ban-client features the unban command that can be used in two ways: unban --all unbans all IP addresses (in all jails and database) unban <IP> ... <IP> unbans <IP> (in all jails and ...


12

See whitelisting on the fail2ban website: # This will ignore connection coming from common private networks. # Note that local connections can come from other than just 127.0.0.1, so # this needs CIDR range too. ignoreip = 127.0.0.0/8 10.0.0.0/8 172.16.0.0/12 192.168.0.0/16 Another reference here: First, find ignoreip. It's always important for you to ...


8

First off. This is (perhaps) not an answer but perhaps better then a comment (and a bit long for it). Time stamps Find your statement: Actually, it can scan files without any time on any line and it will still work. conflicting with the documentation. What do you mean by work? The manual#filters (v 0.8) states: If you're creating your own failregex ...


8

The best way to unban all IPs, is to set the bantime to 1 second, then all the IP will be freed right away. fail2ban-client set JailName bantime 1 After that you can set the proper ban time back. It's better to let fail2ban to do the unban for you. Don't manually edit iptables yourself.


8

fail2ban can be configured for permanent bans by setting bantine to -1 In jail.conf bantime = -1 These will be lost on a reboot, but that's not necessarily a bad thing because so many attempts will be transient from pwned home machines in a botnet... If you want persistence, then https://arno0x0x.wordpress.com/2015/12/30/fail2ban-permanent-persistent-...


6

For systemd systems: You have to specify the backend in /etc/fail2ban/jail.conf to use systemd as follows: backend = systemd Then restart fail2ban: systemctl restart fail2ban Edit: I'm a heavy CentOS/RHEL/Fedora guy so you may have to adapt what I say a bit. As far as this answer, you may have to update the fail2ban package to a version that supports ...


5

If you take a look at this tutorial it states you'll see a timeout which is consistent with what you're seeing, titled: Fail2ban - Rackspace Knowledge Center. excerpts Let's test fail2ban to make sure it behaves the way we want it to. We'll do that by failing a few ssh logins. We'll use two machines: The server we want to protect and another machine ...


5

The first printf is to append the character # to each line of the input file which in awk is represented by $0 and then the modified line (with # added before) is printed out to the console using the print clause. You could just ignore one and run it on the command line to see which one does what. seq 1 5 | awk '{ printf "# "; print; }' # 1 # 2 # 3 # 4 # ...


4

Thank to Joel comment here is the solution I currently use. To /etc/fail2ban/jail.conf this is added to the end: [urlscanners] enabled = true port = http,https filter = urlscanners logpath = /var/log/apache*/*error.log maxretry = 1 bantime = 86400 File /etc/fail2ban/filter.d/urlscanners.conf is like this: #block port scanners [Definition] ...


4

Here's how I did this.. I added this to jail.local: [manban] enabled = true filter = manban action = iptables[name=HTTP, port="80,443,110,995,25,465,143,585,993,587,21,22", protocol=tcp] logpath = /var/log/manban.log maxretry = 1 # 1 month bantime = 2592000 findtime = 3600 Then I added the file /etc/fail2ban/filter.d/manban.conf: [Definition] ...


3

You should try setting port = ssh to the port you really use. (I assume that even with running ssh on a non-standard port, you're not changing the value in /etc/services, and you probably shouldn't do that anyway.)


3

If you take a look at the rules that are included with fail2ban you'll notice that they use these variables to make things neater and more parameterized. For example in the included jail.conf they've used them to make general action rules that they can then use when defining the various jails. Example Here are some basic variables at the top. # ...


3

I will attempt to specifically answer question 3 here as it appears you have found the configuration part of fail2ban which answers questions 1 and 2. If want to beef up security on SSH I recommend the following. Make sure that strict mode is set to true Disable root logins Change your SSH port Disable password logins Use port knocking To answer your ...


3

OK, abort mission. I'm the stupid one.. Got a Typo in my parameters... it is actually smtp_auth.conf not smtp-auth.conf Sorry! Close this one and burry it deep -.-'


3

The location of the log depends on your syslog implementation and configuration. /var/log/messages is the most common place. Note that troubleshooting fail2ban is not an easy task unless you make a good effort in understanding how it works.


3

If you want your Fail2ban to write logs to: /var/log/fail2ban.log Open the /etc/fail2ban/fail2ban.conf file Change the line: logtarget = SYSLOG to logtarget = /var/log/fail2ban.log restart fail2ban service Fail2ban will start writing logs to the /var/log/fail2ban.log file.


3

Looks like your iptables configuration does not include a filter chain named f2b-sshd. First, a mini-primer on iptables. iptables is both a command and the name of the Linux firewall subsystem. The command is used to set up firewall rules in RAM. The iptables firewall rules are arranged first into tables: there is the default filter table, but also nat, ...


3

It's hard to "protect" against DDoS attacks, but one can mitigate them by avoiding useless costly computation. fail2ban can limit the number of attempts that each participant in the DDoS attack can do. Once blacklisted, attempts will be blocked before starting any costly cryptography. Instead of letting your SSH server perform useless computations, the ...


2

/etc/default The directory /etc/default is never used on any Red Hat based distros. That's a Debian/Ubuntu-ism. For Centos 7 you can take a look at the packages that were installed that relate to fail2ban like so: $ rpm -aq|grep fail fail2ban-server-0.9-9.el7.noarch fail2ban-sendmail-0.9-9.el7.noarch fail2ban-firewalld-0.9-9.el7.noarch fail2ban-systemd-0.9-...


2

A few points: 1) fail2ban is just logic for modifying the system configuration so it doesn't really consume any bandwidth itself. 2) 60KB over the course of several minutes isn't that much bandwidth at all. 3) The 60KB of bandwidth you're looking at is for network traffic that matched the failed event. There's nothing you can do to lessen the traffic ...


2

fail2ban uses iptables to block (assuming you're using the default iptables-multiport "action" in f2b). iptables is just part of Linux, so isn't something you need to install. By Ubuntu defaults, if you look in /etc/fail2ban/jail.conf, you should see something like this: [ssh] enabled = true port = ssh filter = sshd logpath = /var/log/auth.log ...


2

What I would do is the following: First thing is to copy all action.d/sendmail-*.conf files to action.d/msmtp-*.conf files: for FILE in /etc/fail2ban/action.d/sendmail*.conf; do cp "$FILE" "${FILE/sendmail/msmtp}"; done Next step is to change the occurrences of before = sendmail to before = msmtp in the action.d/msmtp-*.conf files: sed -i 's/before = ...


2

You are absolutely sure in the a pure config as proxypass fail2ban won't work here because of several reasons. fail2ban actually works looking at logs, and blocking failed authenticated tries ; you have none as the one doing the authentication as the authentications logs are on the backend. fail2ban as a serie of definitions for known protocols; it maybe ...


2

Connect operation and login operation are not the same stuff. Some bots in the internet can just check if your FTP server is alive and disconnect without even trying to login (sometimes in the loop like in your case). That's normal. There is no issue here. You can try it on your own. Simply execute: $ telnet whatever-domain.com 21 Trying 999.9.9.9... ...


2

You'll need fail2ban version 0.9.0 which can support systemd, while Debian Jessie has 0.8.3 in the repository. Try downloading and installing from sources, or look for the alternative repos. Regards.


2

1. stopping the service will clean all rules added by fail2ban service fail2ban stop 2. if you do not have any other iptables rules, you can flush it iptables -F be careful: this will erase any other rules in your iptables.


2

Save iptable config to file $ iptables-save > iptables.conf Edit it with any editor you like Than load config back to iptables $ iptables-restore < iptables.conf Do not forget to store configuration inside iptables so it will be picked up on reboot $ service iptables save iptables: Saving firewall rules to /etc/sysconfig/iptables:[ OK ]


2

The latest fail2ban-client (0.10) has a unban -all command. Jails can also be individually "restarted", effectively clearing the bans. If you have an older version, this trick might work for automatic temporary bans: delete the jail which contains the ban then restart fail2ban so that the (now empty) jail would be recreated. $ fail2ban-client stop sshd ...


2

It's not clear what your actual problem is. Port 3306 is MySQL, is the attacker trying to break into your database? If the DB should not be accessible from outside, you should perhaps drop all connection requests from outside (I normally consider sending any reply packets to an attacker an unnecessary courtesy...) If the attacker somehow consumes your ...


Only top voted, non community-wiki answers of a minimum length are eligible