<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>