Re: [squid-users] Firewalling the Proxy

Hi!

On Sun, Mar 1, 2009 at 12:09 PM, Nyamul Hassan <mnhassan_at_usa.net> wrote:
> Thank you Jose, for the detailed firewall config. �:) �The rules you wrote
> are perfectly clear. �But, I guess, I need to explain my network diagram a
> bit more, to be clear enough for everyone.
>
> My basic scenario is this:
>
> a) �Squid is running on a completely separate box (actually load balanced
> Squid Farm here, but let us say it's logically one box)

nice.

> b) �Internal Network users connect to Firewall, before coming to our NOC
> Servers (let's call it Internal Firewall)
> c) �The Internal Firewall handles the dst-nat (for outbound TCP 80-82, 3128,
> 8080) to my Squid box which is listening on TCP 3128. �In my case, right
> now, I'm not worried about requests from my internal network towards my
> Squid box.
> d) �There is another dedicated Firewall on my Uplink (let's call it Border
> Firewall), and say it has 2 interfaces: �eth_up and eth_local (names should
> be descriptive enough)
> e) �The DNS servers are all hosted on dedicated servers on my NOC, and both
> of them are configured on the Squid box at resolv.conf, so there is no
> reason for SquidIP sending DNS requests (TCP/UDP port 53) to any IP beyond
> the Border Firewall.
>
> Now, logically speaking, when Squid makes a query, the following could be
> seen on the Border Firewall:
>
> i) �Packets from SquidIP/RandomPortX1 (as src-ip/src-port) on eth_local for
> SomeRemoteIP/TCPport80 (as dst-ip/dst-port) to be routed through eth_up
> ii) �Packets fom SomeRemoteIP/TCPport80 (as src-ip/src-port) sending packets
> on eth_up for SquidIP/RandomPortX1 (as dst-ip/dst-port) on eth_local
>
> (replace TCPport80 with other TCP ports that the Internal Router is
> dst-nat-ting on: �80-82, 3128, 8080)

443, 8081, 21 and maybe 10000, depending on your network policies.

>
> Now, the original observation that I wrote about is:
>
> 1) �On my Border Firewall, when I observe packets on eth_up (like #ii above)
> with SquidIP as my dst-ip, there would be a few packets sent from
> RandomRemoteIP using RandomPort as src-port, and using another random port
> on the SquidIP as dst-port. �Is there any particular reason for this?

You should "pair" this with the squid logs, and see if is there a web
page hosted on a non-standard port, but if you are only nating the
standard ports, you shouldn't see any of this traffic. I believe that
passive ftp could cause this kind of connections, but as I use to use
stateful firewalls, and the firewall have connection tracking modules
for ftp, I don't have to worry about this.

> 2) �Are there any circumstances, where a Squid Process (just the process,
> not considering the other daemons on the Squid boxes) would be getting
> packets from RemoteIP that have RandomPort on remote end (src-port on eth_up
> of Border Firewall)?

Passive ftp, maybe.

>
> Basically, I was thinking if it would be ok to drop all packets that I see
> on eth_up of Border Firewall that are destined from my Squid IP, unless they
> have a src-port of the ones that I want squid to fetch data from (80-82,
> 3128, 8080 on RemoteIP).

I'm a little more paranoid on this, and I use to drop all packets that
I don't want. Off course, I always enable stateful firewall, because
that will save a lot of burden when it comes to complex protocols
(h323, sip, even ftp) that can negotiate random ports. But as for web
browsing (~99% of the sites), you shouldn't need any special ports,
so, I would just drop them, and if somebody complains, you just
evaluate the situation, and fix it according to the particular
problem, unless you know someone in your organization can get
problematic, and then you would need to analyze the connections and
try to figure out what is it before blocking it.

>
> Am I being clear enough this time? �If not, I would have to draw up some
> images! �:)

With my customers I use to just hand-draw the diagram with them :) .
Every network can be extremely different from others, and it depends
on several factors: size and kind of organization, directives
preferences (proprietary software, free software, or a mix of them),
end users, etc. It is very hard (maybe impossible) to come out with a
"perfect and general recipe" for a firewall or any other network
service.

>
> Regards
> HASSAN
>
>
>
> ----- Original Message ----- From: "Jose Ildefonso Camargo Tolosa"
> <ildefonso.camargo_at_gmail.com>
> To: "Nyamul Hassan" <mnhassan_at_usa.net>
> Cc: "Squid Users" <squid-users_at_squid-cache.org>
> Sent: Saturday, February 28, 2009 18:38
> Subject: 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 - 19:39:49 MST