Nyz: /* TL;DR - Configuring fail2ban from a fresh install */

2016-06-06T19:07:45Z

TL;DR - Configuring fail2ban from a fresh install

← Older revision		Revision as of 19:07, 6 June 2016
Line 55:		Line 55:
	==TL;DR - Configuring fail2ban from a fresh install==		==TL;DR - Configuring fail2ban from a fresh install==

	# ~~Copy any pre-written jails out of jail.conf and into an appropriately named jail.d/*.conf file~~		# Add "enable = true" to each relevant entry in jail.conf.
	~~# add~~ "enable = true" to each jail.d/ conf ~~file~~.
	# (Optional) Edit fail2ban.conf and change logtarget to /var/log/fail2ban.log, if you want fail2ban to log to it's own file rather than syslog.		# (Optional) Edit fail2ban.conf and change logtarget to /var/log/fail2ban.log, if you want fail2ban to log to it's own file rather than syslog.
	# ~~Create the file jail~~.~~d/customisation.local~~, ~~add~~ the line "ignoreip = $trustedIPs". This is critical, to prevent locking yourself out.		# Edit fail2ban.conf, change the line "ignoreip = $trustedIPs". This is critical, to prevent locking yourself out.
	# /etc/init.d/fail2ban start		# /etc/init.d/fail2ban start

Nyz: Created page with "{{howto_header}} Fail2ban is a package available in the EPEL repository. It provides a mechanism to ban access via iptables to any service that have log files available to be..."

2016-06-02T21:11:25Z

Created page with "{{howto_header}} Fail2ban is a package available in the EPEL repository. It provides a mechanism to ban access via iptables to any service that have log files available to be..."

Páàjì titun

{{howto_header}}

Fail2ban is a package available in the EPEL repository. It provides a mechanism to ban access via iptables to any service that have log files available to be grepped.

The advantage of using Fail2ban over no intrusion prevention is that brute force or denial-of-service attacks are more easily countered, and are done so in an automated fashion. The advantages of fail2ban over a solution such as denyhosts is twofold:
# It uses iptables rather than the /etc/hosts.deny file, which allows for a broader level of scripting for response actions, as well as more flexibility in ban listing
# fail2ban can look at a large number of different logfiles for various services, from SQL databases and httpd-secure, to ssh and whatever else you might have. Denyhosts is solely focused on ssh.

=Installation=

Easy peasy on any Centos/RHEL 6.x machine.

yum install epel-release && yum clean all

then

yum install fail2ban

=Configuration=

The typical fail2ban installation tree looks something like this:

(source: http://www.fail2ban.org/wiki/index.php/MANUAL_0_8#Configuration)
/etc/fail2ban/
├── action.d
│ ├── dummy.conf
│ ├── hostsdeny.conf
│ ├── iptables.conf
│ ├── mail-whois.conf
│ ├── mail.conf
│ └── shorewall.conf
├── fail2ban.conf
├── fail2ban.local
├── filter.d
│ ├── apache-auth.conf
│ ├── apache-noscript.conf
│ ├── couriersmtp.conf
│ ├── postfix.conf
│ ├── proftpd.conf
│ ├── qmail.conf
│ ├── sasl.conf
│ ├── sshd.conf
│ └── vsftpd.conf
├── jail.conf
└── jail.local

NOTE: fail2ban by default looks for and uses '.local' files over '.conf' files in /etc/fail2ban/. It assumes that if a .local exists, that .conf is used as the 'default' file provided by the rpm, and is being retained for reference. If no '.local' exists, .conf is used.

Key files to note are:
* fail2ban.local - General settings
* jail.local - 'Jail' settings, where services to be monitored are enabled
* filter.d/ - Contains the files which define the regex calls to run on target logfiles. Any jail must have a corrosponding file here.
* jail.d/ - A folder for jail settings, an alternative and frankly better method than managing a jail.local file.

==TL;DR - Configuring fail2ban from a fresh install==

# Copy any pre-written jails out of jail.conf and into an appropriately named jail.d/*.conf file
# add "enable = true" to each jail.d/ conf file.
# (Optional) Edit fail2ban.conf and change logtarget to /var/log/fail2ban.log, if you want fail2ban to log to it's own file rather than syslog.
# Create the file jail.d/customisation.local, add the line "ignoreip = $trustedIPs". This is critical, to prevent locking yourself out.
# /etc/init.d/fail2ban start

=Management=

==Frequently Used Commands==

Fail2ban management can be done entirely via textfiles (namely your logfiles and iptables), but life is made infinitely easier by using the built in commands.

These commands are:
* fail2ban-client
* fail2ban-server
And, though not part of the fail2ban package, a primary method of looking at what IPs have currently been banned:
* iptables -L

==What's been banned?==

For the most part, fail2ban operates through denying access from an ip via iptables. It does this through a series of chained iptables rulesets, one per active jail.
Conceptually, the logic looks something like:
Incoming packets
└── jail 1
└── bans from jail1 get dropped, else return to main chain
└── jail 2
└── drop any more bans, then return
└── the rest of your iptables setup.

Note: But what about IPs we trust? Fail2ban can be set up to IGNORE trusted IPs. Those IPs, CIDR addresses, URLs, etc, will /never/ be jailed.

The actual iptables rules are beyond the scope of a howto document, and are covered in the fail2ban documentation found at TODO

So, how do we see what's actually been banned? The simplest method is simply to run "iptables -L".
Scroll through the various jales, and you'll see any banned hosts listed there.

==Managing bans==

Unbanning IPs (say, if you forgot your password) can be managed through the fail2ban-client command

fail2ban-client set <jail> unbanip x.x.x.x

HOWTO fail2ban - Revision history

Nyz: /* TL;DR - Configuring fail2ban from a fresh install */

Nyz: Created page with "{{howto_header}} Fail2ban is a package available in the EPEL repository. It provides a mechanism to ban access via iptables to any service that have log files available to be..."