Re: [squid-users] Denying p2p connections

From: Ismael Silveira <[email protected]>
Date: Mon, 31 Mar 2003 22:11:09 -0300

OK, thanks guys, I'll try.

Ismael
----- Original Message -----
From: "Blaser, Shane" <SBlaser@corp.untd.com>
To: "'Ismael Silveira '" <milach@uol.com.br>; <squid-users@squid-cache.org>
Sent: Thursday, March 27, 2003 11:55 PM
Subject: RE: [squid-users] Denying p2p connections

> You can just use an ACL ....
>
>
> http://squid-docs.sourceforge.net/latest/book-full.html#AEN1393
>
>
>
> Destination Port
>
> Web servers almost always listen for incoming requests on port 80. Some
> servers (notably site-specific search engines and unofficial sites) listen
> on other ports, such as 8080. Other services (such as IRC) also use
> high-numbered ports. Because of the way HTTP is designed, people can
connect
> to things like IRC servers through your cache servers (even though the IRC
> protocol is very different to the HTTP protocol). The same problems can be
> used to tunnel telnet connections through your cache server. The major
part
> of the HTTP specification that allows for this is the CONNECT method,
which
> is used by clients to connect to web servers using SSL.
>
> Since you generally don't want to proxy anything other than the standard
> supported protocols, you can restrict the ports that your cache is willing
> to connect to. The default Squid config file limits standard HTTP requests
> to the port ranges defined in the Safe_ports squid.conf acl. SSL CONNECT
> requests are even more limited, allowing connections to only ports 443 and
> 563.
>
> Port ranges are limited with the port acl type. If you look in the default
> squid.conf, you will see lines like the following:
>
> acl Safe_ports port 80 21 443 563 70 210 1025-65535
>
> The format is pretty straight-forward: destination ports 443 OR 563 are
> matched by the first acl, 80 21 443, 563 and so forth by the second line.
> The most complicated section of the examples above is the end of the line:
> the text that reads "1024-65535".
>
> The "-" character is used in squid to specify a range. The example thus
> matches any port from 1025 all the way up to 65535. These ranges are
> inclusive, so the second line matches ports 1025 and 65535 too.
>
> The only low-numbered ports which Squid should need to connect to are 80
> (the HTTP port), 21 (the FTP port), 70 (the Gopher port), 210 (wais) and
the
> appropriate SSL ports. All other low-numbered ports (where common services
> like telnet run) do not fall into the 1024-65535 range, and are thus
denied.
>
> The following http_access line denies access to URLs that are not in the
> correct port ranges. You have not seen the ! http_access operator before:
it
> inverts the decision. The line below would read "deny access if the
request
> does not fall in the range specified by acl Safe_ports" if it were written
> in english. If the port matches one of those specified in the Safe_ports
acl
> line, the next http_access line is checked. More information on the format
> of http_access lines is given in the next section Acl-operator lines.
>
> http_access deny !Safe_ports
>
>
> -----Original Message-----
> From: Ismael Silveira
> To: squid-users@squid-cache.org
> Sent: 3/27/2003 6:43 PM
> Subject: [squid-users] Denying p2p connections
>
> Hey guys,
>
> I'd like to deny access to P2P connections here in my network, I know
> the
> hosts are using the 1214, 4662 and 4672 ports w/ Kazaa, so I thought
> this
> could work
>
> iptables -A FORWARD -s 0/0 -d 0/0 -p tcp --dport 4662 -j DROP
> iptables -A FORWARD -s 0/0 -d 0/0 -p tcp --dport 1214 -j DROP
> iptables -A FORWARD -s 0/0 -d 0/0 -p tcp --dport 4672 -j DROP
> (i'm not sure though)
>
> However I know that the user can work around those restrictions by
> setting
> different ports on their client...
>
> So I'd really appreciate if you guys could share some rules you made to
> deny
> P2P connections out there.
>
> Thanks in advance,
> Ismael
> Pelotas, Brazil
>
>
>
> .
>
Received on Mon Mar 31 2003 - 18:11:20 MST

This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 17:14:27 MST