Shorewall, Ipsets, Fail2Ban and Recidive Jail v.2

This is my second post on the above subject.  I have now started using ipsets to handle blocking of ip addresses at my firewalls.  For the purposes of this post, the ipsets will be call F2BLIST for ipv4 and F2BLIST6 for ipv6 address.  In the shorewall init file, place the following code:

ipset create F2BLIST hash:ip timeout 300 -exist

This creates an ipset with a default timeout of 300 seconds, and won’t throw an error if it already exists (if you happen to restart shorewall).

Next add a rule to the shorewall rules file like:

?SECTION ALL

DROP:info net:+F2BLIST all

Next, create a new action file under /etc/fail2ban/action.d/ called shorewall-ipset.conf

[Definition]
actionstart =
actionstop =
actioncheck =
actionban = ipset add F2BLIST <ip> timeout <bantime> -exist
actionunban =
[Init]
blocktype = logdrop
bantime = 600

The last line sets the default ban time to 600 seconds.  Next, create a jail in /etc/fail2ban/jail.local like the following:

[ssh-shorewall]

enabled = true
filter = sshd
action = shorewall-ipset[bantime=3600]
sendmail-geoip-lines[name=SSH, dest=youremail, sender=anotheremail, logpath=/var/log/messages]
logpath = /var/log/messages
maxretry = 3

This jail sets the ban time to 3600 seconds, and uses the default findtime.  A recidive jail could look like the following:

[recidive]

enabled = true
filter = recidive
logpath = /var/log/fail2ban.log
action = shorewall-ipset[bantime=172800]
sendmail-geoip-lines[name=recidive, logpath=/var/log/fail2ban.log]
findtime = 172800 ; 2 day
maxretry = 2

The beauty of the ipsets is that the kernel handles expiring the entry, so you don’t have to worry about fail2ban expirying an ip that is still supposed to be blocked in the recidive jail.  If you issue the following command:

ipset list

it will show the ipset and all the entries in it with the corresponding seconds left for each ip to expire.

Hurricane Electric IPv6 Tunnel, Netflix & Unbound

I had been happily using HE’s tunnel broker to gain access to the IPv6 internet for some time.  A side effect of this was that I would quite often get the US version of the Netflix catalogue.  Back in June of 2016, Netflix started actively blocking HE’s subnets because of people using them explicitly to avoid their geo blocking.  Consequently, I would get an error when trying to watch Netflix. The solution I had been using was to reject all IPv6 traffic at the firewall for any device that I used to access Netflix.  It bothered me to essentially turn off IPv6 for those devices, and I recently found a better solution.  I use unbound as my recursive dns resolver, and I found by adding the following code to its configuration file, Netflix has been working without rejecting the IPv6 traffic.

local-zone: “netflix.com” typetransparent
local-data: “netflix.com AAAA ::1”
local-data: “android-appboot.netflix.com AAAA ::1”
local-data: “android.nccp.netflix.com AAAA ::1”
local-data: “android.prod.cloud.netflix.com AAAA ::1”
local-data: “api-global.latency.prodaa.netflix.com AAAA ::1”
local-data: “api-global.netflix.com AAAA ::1”
local-data: “api-global.us-east-1.prodaa.netflix.com AAAA ::1”
local-data: “api-global.us-west-2.prodaa.netflix.com AAAA ::1”
local-data: “api.netflix.com AAAA ::1”
local-data: “appboot.netflix.com AAAA ::1”
local-data: “appboot.us-east-1.prodaa.netflix.com AAAA ::1”
local-data: “appboot.us-west-2.prodaa.netflix.com AAAA ::1”
local-data: “cast-uiboot.prod.http1.netflix.com AAAA ::1”
local-data: “cast.netflix.com AAAA ::1”
local-data: “cast.prod.http1.netflix.com AAAA ::1”
local-data: “customerevents.netflix.com AAAA ::1”
local-data: “dockhand.netflix.com AAAA ::1”
local-data: “ichnaea.geo.netflix.com AAAA ::1”
local-data: “ichnaea.latency.prodaa.netflix.com AAAA ::1”
local-data: “ichnaea.netflix.com AAAA ::1”
local-data: “ichnaea.us-east-1.prodaa.netflix.com AAAA ::1”
local-data: “ichnaea.us-west-2.prodaa.netflix.com AAAA ::1”
local-data: “ios.nccp.netflix.com AAAA ::1”
local-data: “ios.prod.http1.netflix.com AAAA ::1”
local-data: “nintendo.nccp.netflix.com AAAA ::1”
local-data: “nrdp.nccp.netflix.com AAAA ::1”
local-data: “presentationtracking.netflix.com AAAA ::1”
local-data: “prod.http1.us-west-2.prodaa.netflix.com AAAA ::1”
local-data: “secure.netflix.com AAAA ::1”
local-data: “uiboot.netflix.com AAAA ::1”
local-data: “www.geo.netflix.com AAAA ::1”
local-data: “www.latency.prodaa.netflix.com AAAA ::1”
local-data: “www.netflix.com AAAA ::1”
local-data: “www.us-east-1.prodaa.netflix.com AAAA ::1”
local-data: “www.us-west-2.prodaa.netflix.com AAAA ::1”

Essentially, any request for AAAA records returns localhost, but all other records are resolved normally.  I created the list by checking the unbound log file while devices were trying to access Netflix.  If I find any more hostnames to redirect, I will add them to the list.

Latest update July 6 2018

Shorewall limit your kids

A quick little note about turning off the internet at a certain time.  If you can assign all your kids devices IP addresses in a certain range, then you can easily cut them off the network at a given time with an addition to the shorewall rules file

DROP dmz:192.168.12.151-192.168.12.199 net – – – – – – – – timestart=22:00&timestop=23:59&weekdays=Sun,Mon,Tue,Wed,Thu&localtz
DROP dmz:192.168.12.151-192.168.12.199 net – – – – – – – – timestart=00:30&timestop=02:00&weekdays=Fri,Sat&localtz

As you can see, a certain address range on my dmz gets dropped at 10pm on school nights and 1230am on weekends.  Hope someone finds this usefull

Fail2Ban and Squirrelmail

With the help of squirrel logger I now have Fail2Ban banning IPs from attempted logins of my webmail interface.  Configuring squirrel logger was a breeze.  I simple send it to syslog, where it is picked up by my mail.info log.  I created my own squirrelmail.conf for fail2ban which is below.

# Fail2Ban configuration file
#
[Definition]

# Option: failregex
failregex =  0: Failed webmail login: by.*\(.*\) at <HOST> on.*$

ignoreregex =

Fail2Ban and WordPress

I noticed some unusual activity on my webserver recently, and tracked it down to brute force attempts on wordpress installs.  I did a little searching and found wp-fail2ban.  Without too much tweaking of rsyslog, I got the auth messages to my firewall, where I set about getting fail2ban to monitor for login attempts.  I was using the supplied wordpress.conf file that came with the plugin, but it was failing to match the regex due to the 32 character limitation of the syslog tag.  Essentially a tag that should be of the form

wordpress(www.example.com)[12345]

would sometimes be truncated to

wordpress(www.longdomainname.com

This would cause a failure of the regex.  So if you have long domain names, you may need to modify the wordpress.conf.  In my case, I just removed

^%(__prefix_line)

from the beginning of the regex

Fail2Ban, Shorewall and Recidive Jail

I have been using Fail2Ban with Shorewall to block brute force attempts against open ports.  I noticed that during a recent attack, the attackers were being repeatedly banned, so I decided to turn on the Recidive Jail.  Unfortunately, it doesn’t work with the shorewall action – in a nut shell, the short term jail that finally triggers the recidive jail releases the IP even though the recidive jail believes it is still banned.  I got around the problem by adding a new action ‘shorewall-recid’ and creating a few short scripts.  Essentially, if the recidive jail is triggered, the scripts make sure the ip is unbanned from all other jails before it is banned with the recidive one.  If you are interested in the scripts, just let me know.