/
README.Debian
130 lines (94 loc) · 4.81 KB
/
README.Debian
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
fail2ban for Debian
-------------------
This package is ~95% identical to the upstream version. Few features
could have been added but not yet propagated into upstream version and
some modifications might be Debian-specific (logsys logging
format). And although due to tight collaboration with upstream author
most of the Debian modifications penetrate into the next upstream, few
features present in Debian release were rejected by the upstream
author (-e option for instance).
Currently, the major difference with upstream: python libraries are
placed under /usr/share/fail2ban instead of /usr/lib/fail2ban to
comply with policy regarding architecture independent resources.
Also the main config file /etc/fail2ban.conf is a copy of
/usr/share/doc/examples/fail2ban.conf.iptables. There are config files
for banning via shorewall or hosts.deny are provided BUT they might
miss additional sections present in fail2ban.conf. Please copy them
taking care about added sections. Those files will be obsolete in the
next release which would handle split configuration files.
Default behavior:
-----------------
* Enabled Sections:
Only handling of ssh files is enabled by default. If you want to use
fail2ban with apache, please enable apache section manually in
/etc/fail2ban.conf or enable section using command line parameter -e
in /etc/default/fail2ban to avoid conflicts during upgrade of the
config file.
N.B. '-e' command line parameter is present solely in Debian release
of fail2ban, thus it will not work if you decided to proceed with
vanilla upstream.
* Multiport banning:
Comment for the wishlist #373592.
Default iptables rules for banning use --dport statement which allows to
ban just a single port. For multiport banning you would need to adjust iptables
rules to use multiport module ( -m multiport --dports %(port)s ). If you would
like to ban all ports for that host, just redefine fwban/fwunban commands to
don't have --dport %(port)s statement at all (can be redefined on per-section
basis as well)
Such option is not enabled by default since multiport module might not be
compiled for some hand compiled kernels.
Troubleshooting:
---------------
* Updated failregex:
To resolve the security bug #330827 [1] failregex expressions must
provide a named group (?P<host>...) as a placeholder of the abuser's
host. The naming of the group was introduced to capture possible
future generalizations of failregex to provide even more
information. At a current point, all named groups are considered as
possible locations of the host addresses, but usually you should need
just a single group (?P<host>...)
[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=330827
* "Interpolations" in the config file:
Since version 0.6.0-3 to reduce duplication, thus to improve
readability of the config file, interpolations provided by the module
ConfigParser are used. If you had custom sections defined before, you
might benefit from updating config file and adding appropriate
information for the new sections.
N.B. If you have some nice additional sections defined, I would really
appreciate if you share them with me, so they could be eventually
included in the fail2ban package for general use by the rest of the
community.
* Mailing:
As it was reported (bug #329722) you might need to provide a full
e-mail address in fail2ban.conf option MAIL:from to make your mail
server accept that email. I've added @localhost to both MAIL:from and
MAIL:to in the default configuration shipped with Debian. It seems to
work nicely now
See TODO.Debian for more details, as well as the Debian Bug Tracking
system.
* Dirty exit:
If firewall rules gets cleaned out before fail2ban exits (like was
happening with firestarter), errors get reported during the exit of
fail2ban, but they are "safe" and can be ignored.
** SSHD Configuration Specific Problems
* Ban "Not allowed" attempts:
Make sure that you have
ChallengeResponseAuthentication no
PasswordAuthentication yes
Details from the bug report #350980 [2]
[2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=350980
* Not caught attempts to login as root
On the boxes running older versions of openssh (e.g. sarge
distribution) in the case when PermitRootLogin is set to something
else than "yes" and iff AllowUsers is active, failed root logins do
not confirm to the standard logging message -- they omit the source
IP, thus allowing attack to persist since such messages are not caught
by fail2ban.
* Bantime:
An IP is banned for "bantime" not since the last failed login attempt
from the IP, but rather since the moment when failed login was
detected by fail2ban. Thus, if fail2ban gets [re]started, any IP which
had enough of failed logins within "findtime" will be banned for
"bantime" since [re]start moment, not since the last failed login
time.
-- Yaroslav O. Halchenko <debian@onerussian.com>, Sun, 19 Mar 2006 00:27:22 -0500