is<\/em> available from CentOS:<\/p>\n\n\n\nsudo yum install epel-release\n<\/code><\/pre>\n\n\n\nYou will be prompted to continue—press y<\/strong>, followed by Enter<\/strong>:<\/p>\n\n\n\nyum promptTransaction Summary\n============================================================================\nInstall 1 Package\n\nTotal download size: 14 k\nInstalled size: 24 k\nIs this ok [y\/d\/N]: y\n<\/code><\/pre>\n\n\n\nNow we should be able to install the fail2ban<\/code> package:<\/p>\n\n\n\nsudo yum install fail2ban\n<\/code><\/pre>\n\n\n\nAgain, press y<\/strong> and Enter<\/strong> when prompted to continue.<\/p>\n\n\n\nOnce the installation has finished, use systemctl<\/code> to enable the fail2ban<\/code> service:<\/p>\n\n\n\nsudo systemctl enable fail2ban\n<\/code><\/pre>\n\n\n\nThe Fail2ban service keeps its configuration files in the \/etc\/fail2ban<\/code> directory. There, you can find a file with default values called jail.conf<\/code>.\n Since this file may be overwritten by package upgrades, we shouldn’t \nedit it in-place. Instead, we’ll write a new file called jail.local<\/code>. Any values defined in jail.local<\/code> will override those in jail.conf<\/code>.<\/p>\n\n\n\njail.conf<\/code> contains a [DEFAULT]<\/code> section, followed by sections for individual services. jail.local<\/code> may override any of these values. Additionally, files in \/etc\/fail2ban\/jail.d\/<\/code> can be used to override settings in both of these files. Files are applied in the following order:<\/p>\n\n\n\n\/etc\/fail2ban\/jail.conf<\/code><\/li>\/etc\/fail2ban\/jail.d\/*.conf<\/code>, alphabetically<\/li>\/etc\/fail2ban\/jail.local<\/code><\/li>\/etc\/fail2ban\/jail.d\/*.local<\/code>, alphabetically<\/li><\/ol>\n\n\n\nAny file may contain a [DEFAULT]<\/code> section, executed \nfirst, and may also contain sections for individual jails. The last \nvavalue set for a given parameter takes precedence.<\/p>\n\n\n\nLet’s begin by writing a very simple version of jail.local<\/code>. Open a new file using nano<\/code> (or your editor of choice):<\/p>\n\n\n\nsudo nano \/etc\/fail2ban\/jail.local\n<\/code><\/pre>\n\n\n\nPaste the following:\n\/etc\/fail2ban\/jail.local<\/p>\n\n\n\n
[DEFAULT]\n# Ban hosts for one hour:\nbantime = 3600\n\n# Override \/etc\/fail2ban\/jail.d\/00-firewalld.conf:\nbanaction = iptables-multiport\n\n<\/code><\/pre>\n\n\n[sshd]<\/p>\n\n\n\n
\nenabled = true\n\n<\/p>\n\n\n\n
This overrides three settings: It sets a new default bantime<\/code> for all services, makes sure we’re using iptables<\/code> for firewall configuration, and enables the sshd<\/code> jail.<\/p>\n\n\n\nExit and save the new file (in nano<\/code>, press Ctrl-X<\/strong> to exit, y<\/strong> to save, and Enter<\/strong> to confirm the filename). Now we can restart the fail2ban<\/code> service using systemctl<\/code>:<\/p>\n\n\n\nsudo systemctl restart fail2ban\n<\/code><\/pre>\n\n\n\nThe systemctl<\/code> command should finish without any output. In order to check that the service is running, we can use fail2ban-client<\/code>:<\/p>\n\n\n\nsudo fail2ban-client status\n<\/code><\/pre>\n\n\n\nOutputStatus\n|- Number of jail: 1\n`- Jail list: sshd\n<\/code><\/pre>\n\n\n\nYou can also get more detailed information about a specific jail:<\/p>\n\n\n\n
sudo fail2ban-client status sshd\n<\/code><\/pre>\n\n\n\nExplore Available Settings<\/h2>\n\n\n\n
The version of jail.local<\/code> we defined above is a good start, but you may want to adjust a number of other settings. Open jail.conf<\/code>,\n and we’ll examine some of the defaults. If you decide to change any of\n these values, remember that they should be copied to the appropriate \nsection of jail.local<\/code> and adjusted there, rather than modified in-place.<\/p>\n\n\n\nsudo nano \/etc\/fail2ban\/jail.conf\n<\/code><\/pre>\n\n\n\nDefault Settings for All Jails<\/h3>\n\n\n\n
First, scroll through the [DEFAULT]<\/code> section.<\/p>\n\n\n\nignoreip = 127.0.0.1\/8\n<\/code><\/pre>\n\n\n\nYou can adjust the source addresses that Fail2ban ignores by adding a value to the ignoreip<\/code>\n parameter. Currently, it is configured not to ban any traffic coming \nfrom the local machine. You can include additional addresses to ignore \nby appending them to the end of the parameter, separated by a space.<\/p>\n\n\n\nbantime = 600\n<\/code><\/pre>\n\n\n\nThe bantime<\/code> parameter sets the length of time that a \nclient will be banned when they have failed to authenticate correctly. \nThis is measured in seconds. By default, this is set to 600 seconds, or\n 10 minutes.<\/p>\n\n\n\nfindtime = 600\nmaxretry = 3\n<\/code><\/pre>\n\n\n\nThe next two parameters that you want to pay attention to are findtime<\/code> and maxretry<\/code>. These work together to establish the conditions under which a client should be banned.<\/p>\n\n\n\nThe maxretry<\/code> variable sets the number of tries a client has to authenticate within a window of time defined by findtime<\/code>,\n before being banned. With the default settings, Fail2ban will ban a \nclient that unsuccessfully attempts to log in 3 times within a 10 minute\n window.<\/p>\n\n\n\ndestemail = root@localhost\nsendername = Fail2Ban\nmta = sendmail\n<\/code><\/pre>\n\n\n\nIf you wish to configure email alerts, you may need to override the destemail<\/code>, sendername<\/code>, and mta<\/code> settings. The destemail<\/code> parameter sets the email address that should receive ban messages. The sendername<\/code> sets the value of the “From” field in the email. The mta<\/code> parameter configures what mail service will be used to send mail.<\/p>\n\n\n\naction = $(action_)s\n<\/code><\/pre>\n\n\n\nThis parameter configures the action that Fail2ban takes when it wants to institute a ban. The value action_<\/code>\n is defined in the file shortly before this parameter. The default \naction is to simply configure the firewall to reject traffic from the \noffending host until the ban time elapses.<\/p>\n\n\n\nIf you would like to configure email alerts, you can override this value from action_<\/code> to action_mw<\/code>. If you want the email to include the relevant log lines, you can change it to action_mwl<\/code>. You’ll want to make sure you have the appropriate mail settings configured if you choose to use mail alerts.<\/p>\n\n\n\nSettings for Individual Jails<\/h3>\n\n\n\n
After [DEFAULT]<\/code>, we’ll encounter sections configuring individual jails for different services. These will typically include a port<\/code> to be banned and a logpath<\/code> to monitor for malicious access attempts. For example, the SSH jail we already enabled in jail.local<\/code> has the following settings:\n\/etc\/fail2ban\/jail.local<\/p>\n\n\n\n[sshd]\n\nport = ssh\nlogpath = %(sshd_log)s\n<\/code><\/pre>\n\n\n\nIn this case, ssh<\/code> is a pre-defined variable for the standard SSH port, and %(sshd_log)s<\/code> uses a value defined elsewhere in Fail2ban’s standard configuration (this helps keep jail.conf<\/code> portable between different operating systems).<\/p>\n\n\n\nAnother setting you may encounter is the filter<\/code> that will be used to decide whether a line in a log indicates a failed authentication.<\/p>\n\n\n\nThe filter<\/code> value is actually a reference to a file located in the \/etc\/fail2ban\/filter.d<\/code> directory, with its .conf<\/code>\n extension removed. This file contains the regular expressions that \ndetermine whether a line in the log is bad. We won’t be covering this \nfile in-depth in this guide, because it is fairly complex and the \npredefined settings match appropriate lines well.<\/p>\n\n\n\nHowever, you can see what kind of filters are available by looking into that directory:<\/p>\n\n\n\n
ls \/etc\/fail2ban\/filter.d\n<\/code><\/pre>\n\n\n\nIf you see a file that looks to be related to a service you are \nusing, you should open it with a text editor. Most of the files are \nfairly well commented and you should be able to tell what type of \ncondition the script was designed to guard against. Most of these \nfilters have appropriate (disabled) sections in jail.conf<\/code> that we can enable in jail.local<\/code> if desired.<\/p>\n\n\n\nFor instance, pretend that we are serving a website using Nginx and \nrealize that a password-protected portion of our site is getting slammed\n with login attempts. We can tell Fail2ban to use the nginx-http-auth.conf<\/code> file to check for this condition within the \/var\/log\/nginx\/error.log<\/code> file.<\/p>\n\n\n\nThis is actually already set up in a section called [nginx-http-auth]<\/code> in our \/etc\/fail2ban\/jail.conf<\/code> file. We would just need to add an enabled<\/code> parameter for the nginx-http-auth<\/code> jail to jail.local<\/code>:\n\/etc\/fail2ban\/jail.local<\/p>\n\n\n\n[DEFAULT]\n# Ban hosts for one hour:\nbantime = 3600\n\n# Override \/etc\/fail2ban\/jail.d\/00-firewalld.conf:\nbanaction = iptables-multiport\n\n<\/code><\/pre>\n\n\n[sshd]<\/p>\n\n\n\n
\nenabled = true\n\n[nginx-http-auth]\nenabled = true\n\n<\/p>\n\n\n\n
And restart the fail2ban<\/code> service:<\/p>\n\n\n\nsudo systemctl restart fail2ban\n<\/code><\/pre>\n\n\n\nMonitor Fail2ban Logs and Firewall Configuration<\/h2>\n\n\n\n
It’s important to know that a service like Fail2ban is working as-intended. Start by using systemctl<\/code> to check the status of the service:<\/p>\n\n\n\nsudo systemctl status fail2ban\n<\/code><\/pre>\n\n\n\nIf something seems amiss here, you can troubleshoot by checking logs for the fail2ban<\/code> unit since the last boot:<\/p>\n\n\n\nsudo journalctl -b -u fail2ban\n<\/code><\/pre>\n\n\n\nNext, use fail2ban-client<\/code> to query the overall status of fail2ban-server<\/code>, or any individual jail:<\/p>\n\n\n\nsudo fail2ban-client status\nsudo fail2ban-client status jail_name\n<\/code><\/pre>\n\n\n\nFollow Fail2ban’s log for a record of recent actions (press Ctrl-C<\/strong> to exit):<\/p>\n\n\n\nsudo tail -F \/var\/log\/fail2ban.log\n<\/code><\/pre>\n\n\n\nList the current rules configured for iptables:<\/p>\n\n\n\n
sudo iptables -L\n<\/code><\/pre>\n\n\n\nShow iptables rules in a format that reflects the commands necessary to enable each rule:<\/p>\n\n\n\n
sudo iptables -S\n<\/code><\/pre>\n\n\n\nConclusion<\/h2>\n\n\n\n
You should now be able to configure some basic banning policies for \nyour services. Fail2ban is very easy to set up, and is a great way to \nprotect any kind of service that uses authentication.<\/p>\n","protected":false},"excerpt":{"rendered":"
While Fail2ban is not available in the official CentOS package repository, it is packaged for the EPEL project. EPEL, standing for Extra Packages for Enterprise Linux, can be installed with a release package that is available from CentOS: You will be prompted to continue—press y, followed by Enter: Now we should be able to install […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[2],"tags":[],"class_list":["post-13","post","type-post","status-publish","format-standard","hentry","category-linux"],"_links":{"self":[{"href":"https:\/\/untanux.lt\/index.php?rest_route=\/wp\/v2\/posts\/13","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/untanux.lt\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/untanux.lt\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/untanux.lt\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/untanux.lt\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=13"}],"version-history":[{"count":0,"href":"https:\/\/untanux.lt\/index.php?rest_route=\/wp\/v2\/posts\/13\/revisions"}],"wp:attachment":[{"href":"https:\/\/untanux.lt\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=13"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/untanux.lt\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=13"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/untanux.lt\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=13"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}