# Shorewall: Problem Banning Range of IPs [SOLVED]

## Bob P

Edit:  this problem turned out to be caused by a configuration error.  :Embarassed: 

I have been working on blocking an entire range of IP addresses using Shorewall, the front-end for IP tables.  I've run into some problems implementing the feature to ban ranges of IP addresses and I'm hoping that someone can help.

The Shorewall Site specifies that this feature is available in the current release of shorewall:

http://www.shorewall.net/configuration_file_basics.htm#IPRanges

First of all, I'd like to preface my post with verification that my kernel is properly configured to support banning by ranges of IP addresses:

```
# shorewall check

Loading /usr/share/shorewall/functions...

Processing /etc/shorewall/params ...

Processing /etc/shorewall/shorewall.conf...

Loading Modules...

Shorewall has detected the following iptables/netfilter capabilities:

   NAT: Available

   Packet Mangling: Available

   Multi-port Match: Available

   Extended Multi-port Match: Not available

   Connection Tracking Match: Available

   Packet Type Match: Available

   Policy Match: Not available

   Physdev Match: Not available

 * IP range Match: Available *

```

and i also see that my DROP rules for the offending IP have been tested and appear to be good:

```
# shorewall check

...

Validating rules file...

   Rule "DROP net:64.233.160.0/19 fw all" checked.

   Rule "DROP net:66.246.0.0/16 fw all" checked.

   Rule "DROP net:66.249.0.0/16 fw all" checked.

   Rule "DROP net:80.81.16.106 fw all" checked.

   Rule "DROP net:212.27.41.35 fw all" checked.

   Rule "DROP net:66.249.71.3 fw all" checked.

   Rule "DROP net:66.249.64.0-66.249.64.255 fw all" checked.

   Rule "DROP net:66.249.66.0-66.249.66.255 fw all" checked.

   Rule "DROP net:66.249.71.0-66.249.71.255 fw all" checked.

...

Configuration Validated

Notice:  The 'check' command is provided to catch

         obvious errors in a Shorewall configuration.

         It is not designed to catch all possible errors

         so please don't submit problem reports about

         error conditions that 'check' doesn't find
```

the problem is that the offending IP continues to be logged by my http server:

```
66.249.71.3 - - [07/Sep/2005:05:48:16 +0000] "GET /robots.txt HTTP/1.0" 200 127 "" "Googlebot/2.1 (+http://www.google.com/bot.html)"

66.249.71.3 - - [07/Sep/2005:05:48:16 +0000] "GET / HTTP/1.0" 200 5447 "" "Googlebot/2.1 (+http://www.google.com/bot.html)"

66.249.64.52 - - [07/Sep/2005:06:46:13 +0000] "GET / HTTP/1.0" 200 5447 "" "Googlebot/2.1 (+http://www.google.com/bot.html)"

66.249.64.13 - - [07/Sep/2005:07:07:22 +0000] "GET /robots.txt HTTP/1.0" 200 127 "" "Googlebot/2.1 (+http://www.google.com/bot.html)"

66.249.64.13 - - [07/Sep/2005:07:07:22 +0000] "GET / HTTP/1.0" 200 5447 "" "Googlebot/2.1 (+http://www.google.com/bot.html)"
```

can anyone explain why the packets aren't being dropped by the firewall?

----------

## GordSki

I know nothing about shorewall. However, check this to see if it helps. If you're using port forwarding to your web server, check to make sure the forward rule is after your banning rules, otherwise the packets could be forwarded before you get a chance to block them.

Hope it does the trick......

G.

----------

## think4urs11

mhh... the webserver is the same machine as the machine shorewall is running on?

If not - you're only dropping those source ip addresses to access the firewall machine itself, NOT anything behind the firewall - at least if i'm not totally wrong here...

----------

## Bob P

yes, the configuration is a single ended firewall running on the server.  thanks for the idea.

----------

## GordSki

In that case do you have an explicit 'ALLOW' for port 80? Again this would need to be after your banning rules.

G.

----------

## think4urs11

did you consider using Shorewall Blacklisting instead of using the rules file?

----------

## Bob P

 *GordSki wrote:*   

> In that case do you have an explicit 'ALLOW' for port 80? Again this would need to be after your banning rules.
> 
> G.

 

sorry for the delay, but i've had to wait a couple of days to test the firewall.

here is a subset of my firewall's rules table.  all of the rules related to the offending IP are included.  they were updated on 9 September are included in the order that they are listed in /etc/shorewall/rules.  there is an explicit ACCEPT for port 80, and it occurs AFTER the banning rules.  its one of the last rules in my rules table:

```

# The following IPs are banned 

#

DROP    net:64.233.160.0/19     fw                      all                                    

DROP    net:66.246.0.0/16       fw                      all                                    

DROP    net:66.249.0.0/16       fw                      all                                    

DROP    net:216.239.32.0/19     fw                      all                                  

#

DROP    net:80.81.16.106        fw                      all                                    

DROP    net:212.27.41.35        fw                      all                                    

DROP    net:66.249.71.3         fw                      all                                     

DROP    net:66.249.64.66        fw                      all                                    

#

DROP    net:66.249.64.0-66.249.64.255   fw              all                           

DROP    net:66.249.66.0-66.249.66.255   fw              all                           

DROP    net:66.249.71.0-66.249.71.255   fw              all                                    

#

# Port 80 is promiscuous:

#

ACCEPT  net                     fw                      tcp     80                           

ACCEPT  fw                      net                     tcp     80                             

#

```

unfortunately, the DROP rules don't appear to be working, as one of the banned sites continues to access my box even after the firewall rules have been updated and the firewall has been restarted.  :Confused: 

```
# grep Google /var/log/thttpd.log

66.249.71.32 - - [10/Sep/2005:17:54:54 +0000] "GET /robots.txt HTTP/1.0" 200 158 "" "Googlebot/2.1 (+http://www.google.com/bot.html)"

66.249.71.72 - - [11/Sep/2005:14:07:07 +0000] "GET /robots.txt HTTP/1.0" 200 158 "" "Googlebot/2.1 (+http://www.google.com/bot.html)"

66.249.66.41 - - [11/Sep/2005:17:09:40 +0000] "GET /robots.txt HTTP/1.1" 200 158 "" "Mediapartners-Google/2.1"

```

i am hoping that i have made a simple oversight in configuration, but upon review of the shorewall documentation, everything looks good including the CIDR rules and the IP range rules.  does anyone have any ideas?

----------

## Bob P

 *Think4UrS11 wrote:*   

> did you consider using Shorewall Blacklisting instead of using the rules file?

 

i had considered Blacklisting, but I was scared off by the note that it severely degrades performance.  i was hoping that i could get by with a simple entry in the rules table.  for the life of me, i can't figure out why the rules table isn't working, so i may have to try the blacklisting approach if i can't find another solution.   :Confused: 

----------

## GordSki

The ruleset looks fine to me (again I point out that I know nothing about shorewall   :Shocked: ). Have you considered trying iptables (assuming your running 2.6.x or 2.4.x)? Or is there a feature of shorewall you require?

G.

PS: The iptables init script for gentoo is pretty good. Handles all the rules saving and restoring for you.

----------

## Bob P

yes, i am running a 2.6 kernel with iptables installed.  shorewall is an interface for iptables.  its supposed to make IP tables easier to use, but in this case it doesn't seem to be quite what i had in mind.   :Embarassed: 

----------

## GordSki

Yeah, the iptables interface isn't that user friendly  :Very Happy: 

You could check what shorewall is setting up in iptables running this as root: "iptables -nL"

The 'n' stops it doing a reverse lookup on IPs, saves a little time.

G.

----------

## Bob P

yeah, "L" makes it take alot longer.  

here is the relevant portion of the output:

```
DROP       all  --  193.110.85.240       anywhere

DROP       all  --  212.112.0.0/16       anywhere

DROP       all  --  219.148.74.104       anywhere

DROP       all  --  64.233.160.0/19      anywhere

DROP       all  --  66.246.0.0/16        anywhere

DROP       all  --  66.249.0.0/16        anywhere

DROP       all  --  216.239.32.0/19      anywhere

DROP       all  --  crawl25.dir.com      anywhere

DROP       all  --  crawl-66-249-71-3.googlebot.com  anywhere

DROP       all  --  crawl-66-249-64-66.googlebot.com  anywhere

DROP       all  --  anywhere             anywhere            source IP range 66.249.64.0-66.249.64.255

DROP       all  --  anywhere             anywhere            source IP range 66.249.66.0-66.249.66.255

DROP       all  --  anywhere             anywhere            source IP range 66.249.71.0-66.249.71.255

ACCEPT     tcp  --  pool-71-115-47-154.sbndin.dsl-w.verizon.net  anywhere            tcp dpt:www

ACCEPT     tcp  --  anywhere             anywhere            tcp dpt:www

net2all    all  --  anywhere             anywhere

```

so it appears that IPTables is properly configured to drop the Googlebot.  but look at a log entry from yesterday:

```
66.249.71.72 - - [11/Sep/2005:14:07:07 +0000] "GET /robots.txt HTTP/1.0" 200 158 "" "Googlebot/2.1 (+http://www.google.com/bot.html)"
```

i have at least 2 rules that should have prevented that from happening.   :Confused: 

----------

## GordSki

Your right, they look like they should do it. What chains are the rules on? The only thing I can think of is that maybe the rules are in the wrong place. I think they should all be on the INPUT chain.

G.

----------

## Bob P

those rules aren't on the Input chain.  they're in the net2fw chain.

i have to admit, i'm not quite sure what to do here.  the output of "iptables -L" makes it look like the Input Chain is defined by the Shorewall Policies table.  According to the header of /etc/shorewall/policies, that file is only used to assess traffic that is NOT already configured in the /etc/shorewall/rules table, and fwict in shorewall, the appropriate place for me to put those rules is in the rules table.

so from the shorewall perspective, the "rules" table is processed before the "policies" table, and my rules are supposed to be in the right place.  :Confused:   ideas?

----------

## GordSki

Well I'm out of ideas..... I guess it's time to mail the Shorewall guys.

Sorry  :Sad: 

G.

----------

## Bob P

well, i figured that there had to be a problem in shorewall, but i thought i'd exhaust my options here first.  i guess i'll drop them a line.  thanks again for your help.

----------

## GordSki

No problem. Shame we couldn't fix it!

G.

PS: Thanks for your excellent install method  :Wink: 

----------

## Chris W

I just tried blocking the range used by grc.com scanners using this rule: 

```
DROP:info net:4.79.142.192-4.79.142.207  fw all
```

 and watched my logs during a grc.com port scan.  Sure enough, the packets were dropped and logged  (incl. ports that would normally be open).  I'm running Shorewall 2.4.1 from Portage.  I don't think there's anything wrong with Shorewall (at least this version).

Clearly, if traffic is still getting to your web server (and the web server is on the firewall machine not elsewhere on an internal LAN) then there must be an ACCEPT rule or some unexpected path through the chains leading to a default ACCEPT.  Can you post your whole rules and policy files (minus comments)?

----------

## Bob P

D'Oh!  I think I've found an unexpected path through the chains.  I've updated my rules table and I'm going to try it again for a couple of days to see if it keeps the undesirables out.  thanks again for your help.  i'll report back as soon as i know something.

----------

## Bob P

how embarassing.  the problem was caused by a config error on my part.  i had failed to notice an innocuous ACCEPT rule among the shorewall default rules at the top of the rules table that allowed the undesired IP address to pass through the firewall.   :Embarassed: 

thanks everyone for your help.   :Wink: 

----------

