<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
-----BEGIN PGP SIGNED MESSAGE----- <br>
Hash: SHA1 <br>
<br>
Also, finally, gents.<br>
<br>
Google Drive application uses network:<br>
<br>
# Google Drive<br>
74.125.201.0/24<br>
<br>
in my region. ;)<br>
<br>
So to bypass bump you must specify this network as dst with no
bumping.<br>
<br>
WBR, Yuri<br>
<br>
31.12.2014 18:00, <a class="moz-txt-link-abbreviated" href="mailto:squid-users-request@lists.squid-cache.org">squid-users-request@lists.squid-cache.org</a> пишет:<br>
<span style="white-space: pre;">> Send squid-users mailing list
submissions to<br>
> <a class="moz-txt-link-abbreviated" href="mailto:squid-users@lists.squid-cache.org">squid-users@lists.squid-cache.org</a><br>
><br>
> To subscribe or unsubscribe via the World Wide Web, visit<br>
> <a class="moz-txt-link-freetext" href="http://lists.squid-cache.org/listinfo/squid-users">http://lists.squid-cache.org/listinfo/squid-users</a><br>
> or, via email, send a message with subject or body 'help' to<br>
> <a class="moz-txt-link-abbreviated" href="mailto:squid-users-request@lists.squid-cache.org">squid-users-request@lists.squid-cache.org</a><br>
><br>
> You can reach the person managing the list at<br>
> <a class="moz-txt-link-abbreviated" href="mailto:squid-users-owner@lists.squid-cache.org">squid-users-owner@lists.squid-cache.org</a><br>
><br>
> When replying, please edit your Subject line so it is more
specific<br>
> than "Re: Contents of squid-users digest..."<br>
><br>
><br>
> Today's Topics:<br>
><br>
> 1. Re: Squid Deployment Questions (Amos Jeffries)<br>
> 2. Re: Squid 3 SSL bump: Google drive application could
not<br>
> connect (James Harper)<br>
><br>
><br>
>
----------------------------------------------------------------------<br>
><br>
> Message: 1<br>
> Date: Wed, 31 Dec 2014 22:55:18 +1300<br>
> From: Amos Jeffries <a class="moz-txt-link-rfc2396E" href="mailto:squid3@treenet.co.nz"><squid3@treenet.co.nz></a><br>
> To: <a class="moz-txt-link-abbreviated" href="mailto:squid-users@lists.squid-cache.org">squid-users@lists.squid-cache.org</a><br>
> Subject: Re: [squid-users] Squid Deployment Questions<br>
> Message-ID: <a class="moz-txt-link-rfc2396E" href="mailto:54A3C806.4010405@treenet.co.nz"><54A3C806.4010405@treenet.co.nz></a><br>
> Content-Type: text/plain; charset=utf-8<br>
><br>
> On 31/12/2014 6:59 p.m., Evan Blackstone wrote:<br>
> > Hey all, Wondering if I could get some advice on
potentially<br>
> > setting up a Squid forward proxy on my network. I'm not
a Linux<br>
> > novice by any means, but I'm not experienced in server<br>
> > administration, log review, etc.<br>
><br>
> > We're needing to deploy a simple non-caching,
non-peering forward<br>
> > proxy to integrate with an ICAP server for web
filtering. My plan<br>
> > is pretty basic...here's my network config:<br>
><br>
> > Internet --> Cisco ASA --> DMZ --> Internal LAN<br>
><br>
> > I've received conflicting advice on whether or not
there's any<br>
> > advantage to putting a forward proxy on the DMZ vs.
internal LAN.<br>
> > In any case, 'm wanting to deploy an explicit proxy with
a single<br>
> > NIC. Workstations will use a PAC file, etc. to point to
the proxy.<br>
><br>
> > If the server is on the DMZ, I'd allow 80/443 from the
internal LAN<br>
> > to the DMZ, then allow 80/443 from the proxy to outside.
I'd also<br>
> > be allowing the proxy to internal LAN for ICAP, syslog,
and<br>
> > possibly NTP. The proxy would have a single
interface...although it<br>
> > would NAT to outside for internet access, there would be
no ports<br>
> > open on the outside interface.<br>
><br>
> Like Eliezer mentioned if ICAP services are in the LAN place
the proxy<br>
> there. Placing the proxy in the DMZ if ICAP services are in
the LAN<br>
> means the traffic has to flow across the DMZ<->LAN
pathways three<br>
> times - limiting your traffic to 1/3 of line speed on the
slowest NIC<br>
> along the way.<br>
><br>
> Similarly using a single NIC machine means the HTTP traffic
through<br>
> the proxy is already limited to 1.2 the speed of that NIC. If
it's not<br>
> a Gbit NIC then using two NIC (for separate inbound and
outbound<br>
> flows) will allow Squid to run at capacity - which is
somewhat over<br>
> 50Mbps these days and increasing a little each release.<br>
><br>
><br>
><br>
> > Based on some testing I've done, my squid.conf would be
pretty<br>
> > basic...<br>
><br>
> > http_access allow internalnetwork cache deny
internalnetwork<br>
> > always_direct allow internalnetwork http_access deny all
etc.<br>
><br>
><br>
> No need for always_direct. Nor for "cache deny
internalnetwork".<br>
><br>
> You could use "cache deny all" to prevent all HTTP caching
but a small<br>
> amount of memory-only cache is good for improving responses
to the<br>
> topmost popular URLs. Squid has a default 256MB of memory
cache to<br>
> store approx 10K objects (cache_mem directive).<br>
><br>
><br>
> > My questions are:<br>
><br>
> > Does it sound like I'm on the right track here? Would
the above<br>
> > described configuration be safe? I've read that Squid
should listen<br>
> > only on an internal interface? What about when the
server only has<br>
> > one?<br>
><br>
> Use the default squid.conf as a basis and extend as
necessary. It has<br>
> the basic security measures that are important. For a quick
start you<br>
> only need to ensure *localnet* ACL is defined with your LAN
IP ranges<br>
> and you are good to go as a forward proxy.<br>
><br>
><br>
> Internal/external interface makes no difference when there is
only one<br>
> NIC.<br>
><br>
> The default config is safe enough to reject traffic from
external<br>
> sources (non-localnet), but you can be extra sure with either
a<br>
> firewall block in the routers preventing non-LAN connections
inbound<br>
> to the proxy machine.<br>
><br>
><br>
><br>
> > What level of risk would I be assuming (regular patching
included)?<br>
> > Given that I'm relatively new to monitoring Linux
servers for<br>
> > security, etc., is this a bad idea? I'm not really sure
what to be<br>
> > looking for log-wise in terms of compromise. I have edge
devices<br>
> > and monitoring on the perimeter, but I don't really know
what to<br>
> > look for on the server itself...<br>
><br>
> Squid is one of (if not The) most hardened proxies available.
It can<br>
> basically only be compromised in two ways:<br>
> 1) corruption of cached objects - you dont have any on disk,
and<br>
> avoiding the refresh_pattern override/ignores removes the
risk of<br>
> memory objects corruption.<br>
><br>
> 2) infection of the binaries that make up Squid - this is not<br>
> detectable from within Squid anyway. A system AV scanner (or
regular<br>
> update schedule) is required for that.<br>
><br>
> Squid does crash in a numer of ways, but that is a
fail-closed DoS<br>
> type event rather than compromise.<br>
><br>
> * You should monitor cache.log for anything that mentions
"assertion"<br>
> or "FATAL". These are Squid bugs and self-DoS vulnerability.
We are<br>
> always interested in finding out how these happen and fixing.<br>
><br>
> * access.log monitoring is a possibility. One can usually
find web<br>
> exploits being attempted on *other* services in a Squid
access.log, so<br>
> monitoring it like one woud la web server log for suspicious
URL<br>
> requests can be useful to proactively identify compromised
clients.<br>
><br>
><br>
> The Safe_ports and SSL_ports ACLs in the default config map
out blocks<br>
> on the ports with known security issues.<br>
><br>
> You may have clients with web apps needing special ports
accessible<br>
> via CONNECT. Take the usual due-diligence there as if you
were opening<br>
> a firewall port for unrestricted use, then if you wish add
the port<br>
> number to SSL_ports ACL (Safe_ports should already be open
for 1024 or<br>
> larger port numbers).<br>
><br>
><br>
> You can enable the to_localhost rules which are commented out
by<br>
> default to protect against clients accessing services on the
Squid<br>
> machine itself (if any exist accessible over localhost
interface).<br>
> Though on a dedicated proxy the SSL_Ports rule should already
be<br>
> taking care of that.<br>
><br>
><br>
><br>
> > Am I approaching this the wrong way? Should I be looking
at putting<br>
> > it on the inside LAN? Would such an approach leave my
network<br>
> > vulnerable should the Squid box get owned?<br>
><br>
><br>
> Since the purpose of a proxy is to be reachable from LAN
clients the<br>
> security impact on Squid itself is no different in either
position.<br>
><br>
> The security balance is betweeen whether the rest of the
machine<br>
> access methods (including the ICAP servers security
"footprint") are<br>
> more/worse secure in either position vs the traffic costs
mentioned above.<br>
><br>
> NP: ICAP servers and particularly the unencrypted TCP
connections to<br>
> them are the weakest point, since they have the ability to
alter the<br>
> HTTP traffic contents in arbitrary ways. Explicitly not
touching the<br>
> traffic content is one of the security hardening aspects of
Squid.<br>
><br>
> Amos<br>
><br>
><br>
><br>
> ------------------------------<br>
><br>
> Message: 2<br>
> Date: Wed, 31 Dec 2014 11:11:36 +0000<br>
> From: James Harper <a class="moz-txt-link-rfc2396E" href="mailto:james@ejbdigital.com.au"><james@ejbdigital.com.au></a><br>
> To: <a class="moz-txt-link-rfc2396E" href="mailto:squid-users@lists.squid-cache.org">"squid-users@lists.squid-cache.org"</a><br>
> <a class="moz-txt-link-rfc2396E" href="mailto:squid-users@lists.squid-cache.org"><squid-users@lists.squid-cache.org></a><br>
> Subject: Re: [squid-users] Squid 3 SSL bump: Google drive
application<br>
> could not connect<br>
> Message-ID:<br>
>
<a class="moz-txt-link-rfc2396E" href="mailto:HKNPR04MB1933D74D5F5A53D56ED20C8E85F0@HKNPR04MB193.apcprd04.prod.outlook.com"><HKNPR04MB1933D74D5F5A53D56ED20C8E85F0@HKNPR04MB193.apcprd04.prod.outlook.com></a><br>
> <br>
> Content-Type: text/plain; charset="utf-8"<br>
><br>
>><br>
>> Probably non-HTTPS protocol being used.<br>
>><br>
>> As bumping gets more popular we are hearing about a
number of services<br>
>> abusing port 443 for non-HTTPS protocols on the false
assumption that<br>
>> the TLS layer goes all the way to the origin server
without<br>
>> inspection. That has never been a true assumption, CDN
frontends have<br>
>> always decrypted.<br>
>><br>
><br>
> I've mentioned it before, and it's been pointed out that it
probably doesn't scale, but I wrote a callout helper for this
reason and for better logging.<br>
><br>
> Basically:<br>
><br>
> external_acl_type cert_callout concurrency=20 %DST %PORT
/usr/local/squid/libexec/ext_cert_callout_acl<br>
> acl is_ssl external cert_callout IS_SSL<br>
> ssl_bump bump is_ssl<br>
> ssl_bump splice all<br>
><br>
> The helper connects to the IP:port and tries to obtain the
certificate, and then caches the result (in an sqlite database).
If it can't do so within a fairly short time it returns failure
(but keeps trying a bit longer and caches it for next time).
Alternatively if the IP used to be SSL but is now timing out it
returns the previously cached value. Negative results are cached
for an increasing amount of time each time it fails, on the basis
that it probably isn't SSL.<br>
><br>
> So it's somewhat optimistic - on a slow link or for a slow
server a given IP:port might be spliced the first time when it
should be bumped, but it will learn fairly quickly. And for
non-SSL connections that appear to just hang in response to the
request there will be an additional delay the first time. But
otherwise it learns about the target without requiring admin
intervention.<br>
><br>
> It also returns the name of the cert so it can be logged
instead of the IP (for transparent connections), although that
isn't ideal as the same IP might be used for many services
(google/youtube/etc)<br>
><br>
> I can post it if anyone is interested, although it would
require a bit of work to be completely useful.<br>
><br>
> James<br>
><br>
><br>
> ------------------------------<br>
><br>
> Subject: Digest Footer<br>
><br>
> _______________________________________________<br>
> squid-users mailing list<br>
> <a class="moz-txt-link-abbreviated" href="mailto:squid-users@lists.squid-cache.org">squid-users@lists.squid-cache.org</a><br>
> <a class="moz-txt-link-freetext" href="http://lists.squid-cache.org/listinfo/squid-users">http://lists.squid-cache.org/listinfo/squid-users</a><br>
><br>
><br>
> ------------------------------<br>
><br>
> End of squid-users Digest, Vol 4, Issue 75<br>
> ******************************************</span><br>
<br>
-----BEGIN PGP SIGNATURE-----
<br>
Version: GnuPG v2
<br>
<br>
iQEcBAEBAgAGBQJUo+djAAoJENNXIZxhPexGcEAH/Ap3Vx/czpznQaAAtKoeHK/k
<br>
6NXQTJVYxC5FkSV9S4UXGjp+DcWd4bIsIPC0oZ0ZJ7W67d98qC0lP3ciC6rBwPnB
<br>
cV9pzA2ewL73dWQJOwd1rtX44ZVvAgA9uDlg0zW7ZDrrefw1ACxgPvD2Ta2EHNsI
<br>
QD8FwMSA7I5IGc2jgYeL0uILnWX64BuTUw/r1zIbm6uMaRERjxWOujNGNgu6ToRL
<br>
GKOwdxbZIDGBKYo8LmYG1gv5urvVVtZ2ghpZN9iyFrdSmpBNU9wyPc/OssowY0jX
<br>
5Qy9qQD5xWlYpsslivS90WzXdgMpd+n0livRpfIXUStTu6r3juTt34awAG9MzF4=
<br>
=QCIn
<br>
-----END PGP SIGNATURE-----
<br>
<br>
</body>
</html>