iptables: Using shorewall and the priority (dominance) of rules

Silly22 · 01-01-2007, 09:06 AM

I'm editing the /etc/shorewall/rules file in order to block all internet access for a local (internal) client with the IP address 192.168.1.240. This internal computer is a liability if it were able to become infected from the Internet, so I have to restrict its access to the WWW.

I wrote a line in the /etc/shorewall/rules file:
Headings included for clarification...

Code:

#ACTION  SOURCE 	    DEST	PROTO	DEST    SOURCE	ORIGINAL#
#	                                	PORT    PORT(S) DEST    #
REJECT   loc:192.168.1.240  net 	all  #this is the line I added

This partly worked; I couldn't SSH to a host on port 22, and my pings were unable to reach Internet hosts. However, I could still surf http:// websites using Netscape.

And then I noticed the line in the rules file just below the recently added rule.

Code:

REDIRECT loc		    3128    	tcp	www

This is when I first realized just how much I relied on the squid proxy server on my linux machine for port 80 website surfing. By default Mandrake 10.1 is set-up this way.

Why is it that when I commented the second line out (rules in question reproduced below), the one about redirecting local port 80 traffic to a squid server on port 3128, I was finally able to accomplish my goal of blocking all internet access for the internal machine?

Code:

REJECT   loc:192.168.1.240  net 	all  #this is the line I added
#REDIRECT loc		    3128    	tcp	www

I thought that this applied... quote from shorewall.net website

Quote:

Rules for each pair of zones (source zone, destination zone) are evaluated in the order that they appear in the file — the first match determines the disposition of the connection

So that would mean the REDIRECT rule after my REJECT rule shouldn't have caught that internal client's traffic? Am I wrong here? Am I understanding the traffic incorrectly?

Your thoughts please....

jschiwal · 01-02-2007, 06:03 PM

Does "net" refer to any nonlocal address or your proxy. If you want to block html access, I think you also need to block traffic from 192.168.1.240 to the proxy server IP address.

Silly22 · 01-13-2007, 10:46 PM

"net" refers to any nonlocal address. Well, thanks for framing the idea in a question. Now I understand that the "pair of zones" as described by shorewall documentation is evaluated in order. The first pair in my rules being loc to net, and the second pair being loc to proxy on port 3128.

Now here's another thing I did so that I wouldn't have to nullify the utility of the Squid proxy.
I changed the redirect rule to the following instead of commenting it out.

Code:

#ACTION  SOURCE 	    DEST	PROTO	DEST    SOURCE	ORIGINAL#
#	                                	PORT    PORT(S) DEST    #
REDIRECT loc		    3128    	tcp	www	-	!192.168.1.240

It worked, I can't surf the web from the internal machine, BUT the rule doesn't really make sense. Because the way it is written actually means the following:
Redirect all local machine TCP port 80 (www) traffic to port 3128 on the proxy (my router), unless the traffic was originally intended to go to machine at address 192.168.1.240.
The rule kind of makes sense since, I quote the example in the rules file, "This example shows yet another use for the ORIGINAL DEST column; here, connection requests that were NOT (notice the “!”) originally destined to [192.168.1.240] are redirected to local port 3128."

If I think about this in terms of traffic coming from the proxy back to 192.168.1.240 (if the proxy itself is considered in the "loc" group, I don't know), then the rule implies traffic that is originally destined for 192.168.1.240 does not get redirected to 3128. This is confusing...

Perhaps I should write a rule like the following to make it explicit what my goal is...

Code:

REJECT   loc:192.168.1.240  3128 	tcp	www

Any other ideas? Note that by default, I think Mandrake names my router/firewall, where the proxy resides, "fw". So if you can write me a rule that's clear and doesn't hinder internal port 80 traffic from 192.168.1.240, please let us see.