Re: [squid-users] Firewalling the Proxy

Hi!

The question is: do you need squid to be accessed *from* the
Internet?, if the answer is no, then you should do something like
this:

I'm assuming you are using a Linux firewall here, if no: please adapt
the concept to your X firewall:

Let's say your LAN interface is eth0 and your wan interface is eth1,
and that your squid box and your firewall are *different* servers, and
that your LAN is using private addresses:

1. On the filter table, the FORWARD chain:
1.1. Allow by state: -m state --state ESTABLISHED,RELATED -j ACCEPT
1.2. Allow packets coming from your squid box (-s <ip of your squid>),
coming from eth0 (-i eth0), and going anywhere (-d 0/0, this is
default) to interface eth1. It is usually safe to allow any port
here, because there are web sites published in "non-standard" ports.
1.3. Add any other forward rules you consider necessary (allow routing
of the packets coming from your mail server to the Internet for
outgoing mail, and maybe coming from the Internet to your mail server,
for incoming mail, for example).
1.4. Change the policy for the FORWARD chain to DROP.

2. On the nat table, the POSTROUTING chain:
2.1. MASQUERADE/SNAT the packets coming from your internal network (by
IP, ie, -s parameter), going out to eth1 (WAN).

3. On the nat table, the PREROUTING chain (optional, only needed if
you need to allow incoming connections to any of your servers, mail
server, web server, etc.).
3.1. DNAT the packets coming from your WAN interface (-i eth0), with
destination to the external IP you need, with destination to the port
you need (-p tcp --dport 25 , for example), -j DNAT --to <internal
server IP here>.

That's a very simple configuration that will allow any machine you
have on your network, that is allowed by the FORWARD rules, to go to
the Internet, then, you only worry about rules in FORWARD, and for
incoming connections, well, there you will need to manage the
PREROUTING and FORWARD, off course.. The use of stateful rules allows
you to simplify the firewall a lot, and you can stop worrying about
any "external" connections attempts.

I hope this helps,

Ildefonso Camargo

On Sun, Mar 1, 2009 at 7:00 AM, Nyamul Hassan <mnhassan_at_usa.net> wrote:
> Thank you all for your comments.  What I meant was, I was looking at the
> packets on my router flowing from / to my proxy server.  I'm not much
> concerned about outbound packets from squid, as that is going to be arbitary
> for each request.  But, what I was curious about was the inbound
> connections.
>
> So, I re-state my observations again below, but please keep in mind these
> are only for packets that are coming from the WAN side of my router and into
> the squid.
>
> 1.  Majority packets were sent from TCP port 80 and 53 towards the squid,
> which is obvious.
> 2.  Some were TCP 82 also, which is also obvious in our scenario, as a
> locally popular website hosts it's meda files on port 82.
> 3.  Some were TCP 8080, same explanation is #2
> 4.  Some were TCP 443, which struck me as odd, as we do not have 443
> redirected to our squid.  This could happen when someone uses manual proxy.
> So, I think this is safe.
> 5.  Some were TCP high arbitary ports, usually above 10,000 (sometimes a few
> below 10,000 but above 1,000).
> 6.  Whenever #5 would be seen, there would also be an ICMP request from the
> same remote IP towards my squid.
>
> It is the last #5 and #6 that is my concern.  Is this normal behaviour?  Can
> I safely do the following on my router for packets whose destinaion address
> is my squid's IP:
>
> 1.  Allow ICMP packets to my squid from outside
> 2.  Allow packets from TCP ports 53, 80, 82, 443, 3128, 8080.
> 3.  Block all other packets.
>
> Thank you once again for your comments / suggestions.
>
> Regards
> HASSAN
>
>
>
>
> ----- Original Message ----- From: "Amos Jeffries" <squid3_at_treenet.co.nz>
> To: "Jose Ildefonso Camargo Tolosa" <ildefonso.camargo_at_gmail.com>
> Cc: "Nyamul Hassan" <mnhassan_at_usa.net>; "Squid Users"
> <squid-users_at_squid-cache.org>
> Sent: Saturday, February 28, 2009 12:34
> Subject: Re: [squid-users] Firewalling the Proxy
>
>
>> Jose Ildefonso Camargo Tolosa wrote:
>>>
>>> Hi!
>>>
>>> On Sat, Feb 28, 2009 at 4:43 PM, Nyamul Hassan <mnhassan_at_usa.net> wrote:
>>>>
>>>> Hi,
>>>>
>>>> I was checking the requests to and from my proxy servers, and I noticed
>>>> that, while most src-port were TCP 80, 53, 443, some were very high TCP
>>>> ports.  These high port packets would usually also be accompanied by an
>>>> ICMP
>>>> request.  Is this normal web server behaviour?  In my firewall,
>>>> accepting
>>>> src-port of TCP 80, 53, 443, or UDP 53, and ICMP, can I block all else
>>>> directed toward my proxy server?
>>
>> No. There are no rules about what src-port can be.
>> Firewall dst-port that you don't want people getting access *to*.
>>
>> Inbound HTTP connection accompanied by ICMP echo, sounds a lot like a
>> NetDB enhanced HTTP proxy (Squid?) doing best-source detection.
>>
>> Amos
>>
>>>
>>> Ok, you got me a little confused on the "src-port", maybe I'm just
>>> falling a slept now.
>>>
>>> Usually, the connections works like this:
>>>
>>> client (any port above 1024, depends on OS, but usually a high port)
>>> ---> proxy (proxy port,3128) , proxy (local port, usually high port)
>>> ---> Remote Web Server (80,443,....).
>>>
>>> So, you will usually see a "high port" and a "normal port" associated
>>> to a connection, usually the high port is the "local part" and the low
>>> port is the "remote end", from the point of view of the machine that
>>> is initiating the connection.  The IP,port combination is called a
>>> tuple, and each connection have a "local tuple" and a "remote tuple",
>>> the local tuple is usually referred as the "source IP, source port",
>>> and use to have a high port associated with it (in the computer that
>>> is creating the connection, the remote end will see it reversed).
>>>
>>>> Thx in advance for your comments / suggestions.
>>>
>>> Any more info would be useful.
>>>
>>>> Regards
>>>> HASSAN
>>>>
>>>>
>>>
>>> c-ya!
>>>
>>> Ildefonso Camargo
>>
>>
>> --
>> Please be using
>>  Current Stable Squid 2.7.STABLE6 or 3.0.STABLE13
>>  Current Beta Squid 3.1.0.5
>>
>
>
Received on Sat Feb 28 2009 - 12:38:54 MST