Thanks guys for your clarification!!! On Mon, Jun 10, 2013 at 9:59 PM, Amos Jeffries <squid3@xxxxxxxxxxxxx> wrote: > On 11/06/2013 12:21 p.m., Beto Moreno wrote: >> >> Just wondering, I had read that some ISP use squid for caching their >> clients contents, 1k+ users, by default squid have a list of know >> ports open: >> >> 80,443, etc. >> >> For a large deployments u know that u have a bunch of users that hit a >> lot pages per second, and some sites for example they required ports >> like 8080, 4578 in the url, is difficult for a sysadm to wait for a >> customer to request to open the port 4578 because some site he use >> require that port. >> >> Here how do u handle this? >> >> U open in squid ports 80-65535 or how do u manage this? u wait for the >> customer complain? > > > No. Some of the non-80 ports below 1024 are *extremely* dangerous to allow > through HTTP proxy. HTTP syntax accepted by the proxy and relayed on can be > confused by the receiving ports service as their own protocol and cause > great damage or security problems with internal systems. For example the MS > Windows RPC ports or email SMTP / Submission ports - allowing unlimited > access to these through your proxy is downright stupid even if the users ask > for it. > > The default list of Safe_ports ACL includes the "port 1024-65535" range for > generic web hosting ports such as your examples. So those sites work through > any Squid proxy in the world using the published defaults, and many of the > non-Squid proxies have equivalent rules as well. The list of the below-1024 > ports is carefully selected and restricted to those ports where HTTP can be > sent safely on any network. Extending service outside those port ranges in > the default config you must take great care in understanding what the > individual port is used for, its normal protocol syntax and how HTTP can > interact with it - this is somewhat variable between networks but for the > ISP situation tends to be dangerous. > > The SSL_ports acl definition controlling where SSL/TLS is expected for > CONNECT tunnels being sent to non-443 ports is more commonly adapted. Some > admin permit specific other services such as rsync, secure news service and > chat applications to explicitly tunnel through the web proxy - that is > network policy dependent. CONNECT tunnels are both extremely useful and > extremely dangerous - since there is no control whatsoever of what content > they contain. For the ISP situation you will typically not see services > using a HTTP-only proxy like Squid for relaying non-HTTP services so this is > not a big issue. > > Amos
