LinuxQuestions.org
Welcome to the most active Linux Forum on the web.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Networking
User Name
Password
Linux - Networking This forum is for any issue related to networks or networking.
Routing, network cards, OSI, etc. Anything is fair game.

Notices

Reply
 
Search this Thread
Old 01-01-2007, 09:06 AM   #1
Silly22
LQ Newbie
 
Registered: Mar 2002
Location: Edmonton, AB
Distribution: Mandrake 10.2, Ubuntu 6.10
Posts: 26

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


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....
 
Old 01-02-2007, 06:03 PM   #2
jschiwal
Guru
 
Registered: Aug 2001
Location: Fargo, ND
Distribution: SuSE AMD64
Posts: 15,733

Rep: Reputation: 654Reputation: 654Reputation: 654Reputation: 654Reputation: 654Reputation: 654
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.
 
Old 01-13-2007, 10:46 PM   #3
Silly22
LQ Newbie
 
Registered: Mar 2002
Location: Edmonton, AB
Distribution: Mandrake 10.2, Ubuntu 6.10
Posts: 26

Original Poster
Rep: Reputation: 15
"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.

Last edited by Silly22; 01-14-2007 at 01:51 AM.
 
  


Reply

Tags
iptables, proxy, rules, shorewall


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
shorewall config question with /etc/shorewall/rules peter72 Linux - Networking 3 01-01-2007 09:33 PM
Shorewall .....rules or tos? matthewa Linux - Security 3 06-26-2005 01:57 PM
Snort rules> priority linuxtommy Linux - Security 1 09-12-2004 09:35 PM
Shorewall ignores the rules? N3K0KUN Linux - Security 3 09-06-2004 02:48 PM
Iptables rules priority exalik Linux - Networking 1 04-18-2003 11:50 PM


All times are GMT -5. The time now is 09:45 PM.

Main Menu
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration