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)
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)
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?
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)?
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).
Am I being clear enough this time? If not, I would have to draw up some
images! :)
Regards
HASSAN
----- Original Message -----
From: "Jose Ildefonso Camargo Tolosa" <ildefonso.camargo@xxxxxxxxx>
To: "Nyamul Hassan" <mnhassan@xxxxxxx>
Cc: "Squid Users" <squid-users@xxxxxxxxxxxxxxx>
Sent: Saturday, February 28, 2009 18:38
Subject: Re: 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@xxxxxxx> 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@xxxxxxxxxxxxx>
To: "Jose Ildefonso Camargo Tolosa" <ildefonso.camargo@xxxxxxxxx>
Cc: "Nyamul Hassan" <mnhassan@xxxxxxx>; "Squid Users"
<squid-users@xxxxxxxxxxxxxxx>
Sent: Saturday, February 28, 2009 12:34
Subject: Re: Firewalling the Proxy
Jose Ildefonso Camargo Tolosa wrote:
Hi!
On Sat, Feb 28, 2009 at 4:43 PM, Nyamul Hassan <mnhassan@xxxxxxx> 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
