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 give you access to many new packages. One of those packages is fail2ban
, therefore install it by running:
yum install fail2ban
By default there are no jails configured, therefore to configure a basic sshd
jail:
Create/edit the file /etc/fail2ban/jail.local
and add:
[sshd]
enabled = true
Start it with:
systemctl start fail2ban
Make it start at boot time:
systemctl enable fail2ban
There used to be a known bug where SELinux would block fail2ban
from accessing the log files it needed to do its job. This seems to be fixed in the most recent version of CentOS 7; you shouldn't need to make the changes below.
If you do have this issue, symptoms are nothing appearing in the logs and nothing appearing as failed or blocked in the output of fail2ban-client status sshd
.
To check for SELinux error, read the journals with:
journalctl -lfu fail2ban
Watch them for messages such as:
SELinux is preventing /usr/bin/python2.7 from getattr access on the file .
***** Plugin catchall (100. confidence) suggests **************************
If you believe that python2.7 should be allowed getattr access on the file by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# grep fail2ban-server /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp
Therefore do as suggested and run:
grep fail2ban-server /var/log/audit/audit.log | audit2allow -M mypol
semodule -i mypol.pp
Then, to be safe, restart fail2ban
:
systemctl restart fail2ban
You may even have to repeat the process above until no more error messages appear in the log.
If your server is on the internet then monitor fail2ban-client status sshd
. It will soon start to show failed and banned counts if you've caught all the SELinux issues.
Note that you will have to keep an eye on your SELinux policy updates. If a selinux-policy
package update appears, it may overwrite the above and you may need to run the above commands again. You'll know if this is the case as fail2ban
will stop working again!
Short version: look at the in use clnt
+pers
pages in the svmon -G
output (unit is 4k pages) if you want to know all file cache, or look at vmstat -v
and look at "file pages" for file cache excluding executables (same unit).
You should check out the following article if you want a good overview of what's going on: Overview of AIX page replacement.
For an extremely short summary, memory in AIX is classified in two ways:
svmon -G
(btw, svmon -G -O unit=MB
is a bit friendlier) gives you the work versus permanent pages. The work
column is, well, work memory. You get the permanent memory by adding up the pers
(JFS) and clnt
(JFS2) columns.
In your case, you've got about 730MB of permanent pages, that are backed by your filesystems (186151*4k pages).
Now the topas
top-right "widget" FileSystemCache (numperm)
shows something slightly different, and you'd get that same data with vmstat -v
: that's only non-computational permanent pages. i.e. same thing as above, but excluding pages for executables.
In your case, that's about 350MB (2.2% of 16G).
Either way, that's really not much cache.
Best Answer
/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 tofail2ban
like so:Contents of fail2ban-server
The
fail2ban-server
contains the service file for Systemd.Systemd service file
The contents of the Systemd service file:
So one could add the extra options to this file, as a quick and dirty way to confirm if they're working.
Long term fixes
To make them permanent, I'd add the options in a more "official" way so that updates to the
fail2ban
package do not overwrite the modifications to this file. This can be accomplished by adding a customized version of thefail2ban.service
file in this directory:NOTE: A file in this directory,
/etc/systemd/system
always overrides the default.service
file.However doing it this way have caveats, one being that if a service file is present here when
Excerptfail2ban
were to be updated viayum
it would cause the service to be disabled, until you manually reenabled it. So instead you can override fragments of the.service
file by adding them to this directory under/etc
instead.so you could create a directory,
/etc/systemd/system/fail2ban.service.d
and add*.conf
files in it with contents like this:Adding your options there.
Ulimits & Systemd
If you're trying to set a
Excerptulimit
option for a particular service, then have a look at the man page forsystemd.exec
.So simply adding
Excerpt - setrlimit(2) man pageLimitSTACK=256
to the customized.conf
file that I describe above should give you the same effect as settingulimit -s 256
.If you have a look through the
setrlimit(2)
man page you can see how theulimit
switches line up with the Systemd limits.References