Alex, Thank you and the others for that breakdown. That really helps my understanding of it a bit more than trying to grasp the full concept through just reading. I struggle a bit without further context that FAQ's and KB's usually lack, just for simplicities sake. I'm going to keep persuing this route, I'm sure I can get this working. At the very least, this whole project, and Linux, has helped me understand a deeper(smaller?) level on how things work behind the scenes. I'm going to review the original configuration again, and see what I could be missing. I've already removed/changed a lot of the obsolete terms that you were pointed out to me and what I found online using the squid online resources. I've been visiting this page everyday: http://www.squid-cache.org/Doc/config/ I know that, seemingly, our custom ACL's are not blocking a clients access to browse to internald evices via hostname. I thought it may have been an issue with the allowed ports, maybe an "http_access" rule, or a (likely) user error in creating conflicting rules or statements. Greatful for the assistance, Josh -----Original Message----- From: squid-users <squid-users-bounces@xxxxxxxxxxxxxxxxxxxxx> On Behalf Of Alex Rousskov Sent: Monday, September 16, 2024 11:55 PM To: squid-users@xxxxxxxxxxxxxxxxxxxxx Subject: Re: Unable to access internal resources via hostname Caution: This email originated from outside of Hexcel. Do not click links or open attachments unless you recognize the sender and know the content is safe. On 2024-09-16 14:06, Piana, Josh wrote: >> http_access deny !localnet > This denies HTTP traffic to what I defined as "localnet". ... Because > this argument is near the bottom of my config, won't all other ACL's > and lists apply before getting to this deny all rule? Others have already guided you further, but I will try to correct the above misunderstanding: * The order of http_access directives matters: Squid evaluates http_access rules in their squid.conf order and applies the first http_access rule that has a matching condition. All subsequent http_access rules are ignored (for that transaction). Here, "to apply" means to allow or deny the transaction (depending on the matching rule action) and "matching condition" means that all ACLs named in that http_access rule have matched the transaction. * The order of acl directives only matters in special cases for ACLs with side effects. For now, you can probably ignore that order. * For a given ACL name "foo", it is usually best to keep all "acl foo" directives together and above the first http_access (or any other ACL-using directive) line that uses ACL named "foo". > I thought every statement needs a contradicting statement as well. No, it does not: N+1 http_access rule is only evaluated if the first/earlier N http_access rules did _not_ match (see the first bullet above), so you effectively get that "contradicting" or "else" effect automatically as Squid moves through http_access rules... Said that, it is often a good idea to use "http_access deny all" as the very last explicit http_access rule to avoid relying on an ever-changing default/implicit action that is applied when none of the explicit rules matched. That implicit default is "ever-changing" because it depends on the last explicit http_access rule action (which, naturally, may change as folks update their rules). FWIW, the following FAQ entry covers the same concepts: https://wiki.squid-cache.org/SquidFaq/SquidAcl HTH, Alex. > -----Original Message----- > From: squid-users <squid-users-bounces@xxxxxxxxxxxxxxxxxxxxx> On > Behalf Of Alex Rousskov > Sent: Monday, September 16, 2024 10:42 AM > To: squid-users@xxxxxxxxxxxxxxxxxxxxx > Subject: Re: Unable to access internal resources via > hostname > > Caution: This email originated from outside of Hexcel. Do not click links or open attachments unless you recognize the sender and know the content is safe. > > > On 2024-09-16 09:58, Piana, Josh wrote: > >> I removed all of the special, custom ACL's and we still don't have internal to internal browsing via hostname. > > FWIW, these first two http_access rules make all subsequent http_access rules irrelevant/unused because these two rules match all traffic: > >> http_access deny !localnet >> http_access allow localnet > > I did not look further, but the above combination is a sign that you interpret http_access rules differently than Squid does. Please make sure you understand why the two rules above make all subsequent http_access rules irrelevant/unused before adjusting your configuration further. Ask questions as needed. > > > If the primary problem persists after addressing this configuration problem, then my earlier (2024-09-04) recommendation stands: Please restate the primary problem (e.g., detail what "don't have browsing" > means in terms of the test transaction outcome) and share debugging log of that test transaction again. > > > HTH, > > Alex. > > >> So there's something wrong with either the order of the squid.conf or I'm missing some "allow" variable. >> >> Please see below for my current config: >> >> ##################################################################### >> # >> ######## >> # Authentication >> ##################################################################### >> # >> ######## >> >> auth_param negotiate program /usr/lib64/squid/negotiate_kerberos_auth >> -k /etc/squid/HTTP.keytab -s >> HTTP/ARCGATE2.ad.arc-tech.com@xxxxxxxxxxxxxxx >> auth_param negotiate children 10 >> auth_param negotiate keep_alive on >> acl kerb-auth proxy_auth REQUIRED >> >> ##################################################################### >> # ######## # Access control - shared/common ACL definitions >> ##################################################################### >> # >> ######## # >> --------------------------------------------------------------------- >> - >> ------ # networks and hosts (by name or IP address) >> >> acl src_self src 127.0.0.0/8 >> acl src_self src 10.46.11.69 >> >> acl to_localhost dst 10.46.11.69 >> >> acl localnet src 10.0.0.0/8 >> acl localnet src 172.0.0.0/8 >> >> acl local_dst_addr dst 10.0.0.0/8 >> acl local_dst_addr dst 172.0.0.0/8 >> >> # >> --------------------------------------------------------------------- >> - >> ------ >> # protocols (URL schemes) >> >> acl proto_FTP proto FTP >> acl proto_HTTP proto HTTP >> >> # >> --------------------------------------------------------------------- >> - >> ------ >> # TCP port numbers >> >> # TCP ports for ordinary HTTP >> acl http_ports port 80 # standard HTTP >> acl http_ports port 81 # common alternative >> acl http_ports port 8001 # epson.com support sub-site >> acl http_ports port 8080 # common alternative >> acl http_ports port 88 8000 8888 # ad-hoc services >> acl http_ports port 1080 # SOCK frontend to HTTP service >> acl http_ports port 21-22 # http:// frontend to FTP service >> acl http_ports port 443 # https:// URLs >> >> # TCP ports for HTTP-over-SSL >> acl Ssl_ports port 443 # standard HTTPS >> acl Ssl_ports port 9571 # lexmark.com >> acl Ssl_ports port 22 # SSH >> >> # TCP ports for plain FTP command channel acl ftp_ports port 21 >> >> # >> --------------------------------------------------------------------- >> - >> ------ >> # HTTP methods (and pseudo-methods) >> >> acl CONNECT method CONNECT >> >> ##################################################################### >> # >> ######## >> # Access control - general proxy >> ##################################################################### >> # >> ######## >> >> # define and allow new ACL for "Safe_ports" >> acl Safe_Ports any-of http_ports Ssl_ports ftp_ports >> >> # >> --------------------------------------------------------------------- >> - >> ------ >> # basic deny rules >> >> # deny anything not from the LAN >> http_access deny !localnet >> >> # allow localnet users >> http_access allow localnet >> >> # blocks self to self connections >> http_access deny to_localhost >> >> # deny unauthorized access and DoS attacks http_access deny >> !Safe_ports http_access deny CONNECT !Ssl_ports >> >> # allow authenticated clients after all other ACL's http_access allow >> kerb-auth >> >> # deny any request we missed in the above http_access deny all >> >> # if no other ACL applies, allow >> http_reply_access allow all >> >> This is it. I commented out all other ACL's for allow/deny we had in place for our custom rules. Still unable to browse local via hostname, IP works fine again. >> >> -----Original Message----- >> From: squid-users <squid-users-bounces@xxxxxxxxxxxxxxxxxxxxx> On >> Behalf Of Amos Jeffries >> Sent: Saturday, September 7, 2024 10:51 AM >> To: squid-users@xxxxxxxxxxxxxxxxxxxxx >> Subject: Re: Unable to access internal resources via >> hostname >> >> Caution: This email originated from outside of Hexcel. Do not click links or open attachments unless you recognize the sender and know the content is safe. >> >> >> On 6/09/24 03:56, Piana, Josh wrote: >>> Hello Amos, >>> >>> While the comments did say that it was just the 10.46.11.0 range, I don't think there's any other ACL forcing that. I tried adding the the two internal sites that are being blocked by their IP, restarted Squid, and tested. Still being blocked. You are right though, both of those web addresses are on a different IP scheme. Ideally we want anything on 172.0.0.0 to be allowed, and 10.96.0.0. The other question I have is, even if we specify those sites IP as "allowed", shouldn't we be able to brwose to them by their hostname as well? >> >> >> That depends no your configuration policy. The default squid.conf only checks that clients are from the LAN and not doing any nasty protocol trick attacks. >> >> >>> >>> Currently, those internal sites ARE reachable. But only if we use IP. While this doesn't bother me, personally, the rest of our users would like to keep browsing via hostname as that's what they're used to and what many have shortcuts for. >>> >> >> Currently I see the ACL "local_dst_dom" is commented out (disabled). >> >> I guess you also have not listed the hostname or domain in the file loaded by "authless_dst" ACL. >> >> >> >> >>> In regards to the results of /etc/resolv.conf, see below: >>> search ad.arc-tech.com >>> nameserver 10.46.11.67 >>> >> >> Okay. Then the "NDOT" default of 1 will be applied. So for these HTTP >> messages: >> >> CONNECT hexp:443 HTTP/1.1 >> Host: hexp >> ... >> >> >> Will be interpreted by Squid as URL: >> >> https://hexp/ >> >> >> The "dstdomain" ACL will try to match "hexp" exactly. >> >> The "dst" ACL will try to match IPs of "hexp.ad.arc-tech.com" >> >> >> >>> There must be a better way to just allow internal to internal traffic without needing to authenticate through the web proxy. The old config had it, but that was part of the issue. We have no idea how that was working, it didn't make sense at all and it was a bit outdated, Version 2.5 as opposed to our current 5.5. >>> >>> I'm happy to post out config again here, as it's changed a bit and I have cleaned it up. >>> >>> # squid.conf - Squid web cache configuration >>> >>> #################################################################### >>> # >>> # >>> ######## >>> # General >>> #################################################################### >>> # >>> # >>> ######## >>> >>> # 2020MAR23 running out with just 1024 as we switch to Hexcel.com >>> OMA max_filedesc 4096 >>> >> >> Unrelated to your problem, but FYI this should probably be much larger (ie 64K minimum, up to 100x expected user count) for a production proxy. >> >> >>> >>> #################################################################### >>> # >>> # >>> ######## >>> # Logging >>> #################################################################### >>> # >>> # >>> ######## >>> >>> # this makes the logs readable to humans logformat custom %tl.%03tu >>> %>a %Ss/%03>Hs %<st %rm %ru %[un %Sh/%<a %mt access_log >>> daemon:/var/log/squid/access.log custom >>> >>> # this gives better error reporting >>> logformat custom %err_code/%err_detail access_log >>> daemon:/var/log/squid/access.log custom >>> >> >> This repeat of "custom" will cause issues. >> >> IIRC this was added misunderstanding of Alex instructions. >> What he meant was to **add** "%err_code/%err_detail" to your existing "custom" format. >> >> Like this: >> >> logformat custom %tl.%03tu %>a %Ss/%03>Hs %<st %rm %ru %[un \ >> %Sh/%<a %mt %err_code/%err_detail >> >> >>> # Red Hat-ish log names >>> cache_log /var/log/squid/cache.log >>> cache_access_log /var/log/squid/access.log >> >> This setting opens a third logger writing to access.log, causing more issues. >> >> Remove this "cache_access_log" line. >> >> >>> >>> # store_log is only useful for debugging cache_store_log none >> >> >> FYI, off by default on current Squid. You can probably erase this setting entirely now. >> >> >>> #################################################################### >>> # >>> # >>> ######## >>> # Network - General/misc >>> #################################################################### >>> # >>> # >>> ######## >>> >>> # our HTTP proxy port >>> http_port 10.46.11.69:8080 >>> # loopback management >>> http_port 127.0.0.1:3128 >> >> >> FWIW, you have denied access to "dst 127.0.0.0/8". So traffic to this port will be rejected. >> >> >>> >>> # disable ICP, port is typically 3130 icp_port 0 >> >> FYI; disabled by default in modern Squid. You can remove "icp_port". >> >>> >>> # if set to "on", Squid will append your client's IP address in the >>> HTTP requests it forwards forwarded_for off >> >> "off" will send the text "unknown". >> >> It is better to use "transparent" (pass-thru unchanged) or "delete" >> (erase if existing). >> >> >>> #################################################################### >>> # >>> # >>> ######## >>> # Authentication >>> #################################################################### >>> # >>> # >>> ######## >>> >>> auth_param negotiate program >>> /usr/lib64/squid/negotiate_kerberos_auth >>> -k /etc/squid/HTTP.keytab -s >>> HTTP/ARCGATE2.ad.arc-tech.com@xxxxxxxxxxxxxxx >>> auth_param negotiate children 10 >>> auth_param negotiate keep_alive on >>> acl kerb-auth proxy_auth REQUIRED >>> >>> #################################################################### >>> # # ######## # Access control - shared/common ACL definitions >>> #################################################################### >>> # >>> # >>> ######## >>> >>> # >>> -------------------------------------------------------------------- >>> - >>> - >>> ------ # networks and hosts (by name or IP address) >>> >>> # acl all src all >>> >>> acl src_self src 127.0.0.0/8 >>> acl src_self src 10.46.11.69 >>> >>> acl dst_self dst 127.0.0.0/8 >>> acl dst_self dst 10.46.11.69 >> >> >> FYI, there are more IPs than just 127.0.0.0/8 which can be problematic as loopback sources. >> >> Replace "dst_self" with: >> >> acl to_localhost dst 10.46.11.69 >> >> >>> >>> acl from_arc src 10.46.0.0/15 >>> >>> acl local_dst_addr dst 10.0.0.0/8 >>> acl local_dst_addr dst 172.0.0.0/8 >>> >>> # >>> -------------------------------------------------------------------- >>> - >>> - >>> ------ >>> # protocols (URL schemes) >>> >>> acl proto_FTP proto FTP >>> acl proto_HTTP proto HTTP >>> >>> # >>> -------------------------------------------------------------------- >>> - >>> - >>> ------ >>> # TCP port numbers >>> >>> # TCP ports for ordinary HTTP >>> acl http_ports port 80 # standard HTTP >>> acl http_ports port 81 # common alternative >>> acl http_ports port 8001 # epson.com support sub-site >>> acl http_ports port 8080 # common alternative >> >> >> Other ports that are common: >> >> acl http_ports port 88 8000 8888 # ad-hoc services >> acl http_ports port 1080 # SOCK frontend to HTTP service >> acl http_ports port 21-22 # http:// frontend to FTP service >> acl http_ports port 443 # https:// URLs >> >> >> Or really, **any** port can be valid now that Alt-Svc is widely used. >> >>> >>> # TCP ports for HTTP-over-SSL >>> acl Ssl_ports port 443 >>> acl Ssl_ports port 9571 # lexmark.com >>> >>> # TCP ports for plain FTP command channel acl ftp_ports port 21 >>> >>> # TCP ports for SSH/SFTP (secure shell) acl ssh_ports port 22 >> >> FTR, "ssh_ports" is unused. SSH and SFTP can only use Squid via CONNECT tunnel anyway. So you should list this port as part of "Ssl_ports". >> >>> >>> # >>> -------------------------------------------------------------------- >>> - >>> - >>> ------ >>> # HTTP methods (and pseudo-methods) >>> >>> acl method_CONNECT method CONNECT >> >> FYI: we have a built-in for modern Squid: >> >> acl CONNECT method CONNECT >> >> You can replace all "method_CONNECT" with just "CONNECT". >> >> >>> >>> # list of standard HTTP methods >>> acl methods_std method GET HEAD POST PUT DELETE acl methods_std >>> method TRACE OPTIONS >>> >> >> Consider removing these ACLs and the extra complexity they create. >> Modern HTTP considers many other method names "standard" and current Squid follows the standard-required handling for all of them, and special ones. >> >> >>> #################################################################### >>> # >>> # >>> ####### >>> # Access control - general proxy >>> #################################################################### >>> # >>> # >>> ######## >>> >>> # This major section is about which HTTP proxy clients can use Squid >>> # as an HTTP proxy server. As opposed to the maintenance/admin-type >>> # stuff in the previous section. >>> >>> # >>> -------------------------------------------------------------------- >>> - >>> - >>> ------ >>> # basic deny rules >>> # these block stuff that's never good # we put most denies after >>> user-auth so we know *who* is trying >>> >> >> Missing basic security to prevent DoS and protocol hijacking attacks: >> >> >> http_access deny !Safe_ports >> http_access deny CONNECT !Ssl_ports >> >> >> You can define Safe_ports like this: >> >> acl Safe_Ports any-of http_ports Ssl_ports ftp_ports >> >> >> >>> # block attempts to connect to proxy server via proxy http_access >>> deny dst_self >>> >> >> Use: >> http_access deny to_localhost >> >> >> >>> # block clients which are the proxy server machine itself >>> http_access deny src_self >>> >> >> FYI, there should be nothing wrong with other software running on the proxy machine (eg software updaters) using Squid. They have to obey the same rules an any other client. >> >> >>> # deny anything not from the LAN >>> http_access deny !from_arc >> >> FYI, we use "localnet" ACL to define the LAN. Makes it a bit easier for others to assist if you use the same. Up to you though. >> >> >>> >>> # >>> -------------------------------------------------------------------- >>> - >>> - >>> ------ >>> # allow without authentication >>> # these rules allow certain connects without user authentication # >>> these allow any protocol/method/etc >>> >>> # ***** IMPORTANT ***** >>> # Adding to these lists also exempts from all content filtering. >>> # In particular, executables will be allowed to download! >>> # ***** IMPORTANT ***** >>> >>> # allow connects to local destinations without authentication # by >>> domain name from URL # acl local_dst_dom dstdomain ad.arc-tech.com >>> # http_access allow local_dst_dom >>> # http_reply_access allow local_dst_dom >> >> >> You have a domain name whitelist ACL two sections below. >> You can remove the above, and list and use the later one for both >> "local" and other domains. >> >> >>> >>> # by IP address name resolves to >>> http_access allow local_dst_addr >>> # http_reply_access allow local_dst_addr >>> >> >> Maybe rename "local_dst_addr" to "whitelist_dst_ips" for clarity on >> what it is doing. >> >> >> Which brings up a security issue: When you list the entire LAN range >> in this ACL, anyone accessing the proxy is allowed to do whatever >> they want to your LAN machines. That includes all LAN **and** WAN connections. >> >> Additionally, the bypass of authentication leaves you no trace that >> this was actually a user, and not some infected LAN machine spreading >> malware across your LAN. Which is rather risky. >> >> >> Prefer to keep by-IP whitelist's empty or minimal content. >> >> >> >>> # allow trusted hosts without authentication # these are just ip's >>> on the 10.46.11.x network acl authless_src src "/etc/squid/authless_src" >>> http_access allow authless_src >>> # http_reply_access allow authless_src >>> >>> # allow the following destinations without authentication # list of >>> random approved websites # whats the advantage of not authenticating? >>> acl authless_dst dstdomain "/etc/squid/authless_dst" >>> http_access allow authless_dst >>> # http_reply_access allow authless_dst >>> >> >> This should be combined with "local_dst_dom". Just use different >> lines like so: >> >> acl authless_dst dstdomain "/etc/squid/authless_dst" >> acl authless_dst dstdomain .ad.arc-tech.com >> acl authless_dst dstdomain .hexcelssp.com hexcelssp >> >> http_access allow whitelist >> >> >>> # >>> -------------------------------------------------------------------- >>> -------- >>> # block before authentication >>> # these rules block certain connects without user authentication # >>> done for software which handles proxy auth requests badly # for >>> example, popping up many auth prompts # this does mean we cannot >>> whitelist for users >>> >>> # blocked destinations, by host or domain, before authentication # >>> websites that are auto-deny acl bad_domains_preauth dstdomain >>> "/etc/squid/bad_domains_preauth" >>> http_access deny bad_domains_preauth >>> >>> # >>> -------------------------------------------------------------------- >>> -------- >>> # require proxy authentication >>> >>> # >>> ******************************************************************** >>> # * anything past this point requires users to authenticate to proxy >>> * # >>> ******************************************************************** >>> >>> # Uncomment these lines to disable authentication requirement for >>> all # but a few test boxes. Useful if NTLM gets broken. >>> # acl from_test_boxes src 10.2.1.5 >>> # http_access allow !from_test_boxes from_arc >>> >> >> FYI, you have "deny !from_arc" earlier above. >> >> This is simpler and does the same thing as the above line: >> >> # http_access allow !from_test_boxes >> >> >>> # block clients which are not authenticated # http_access deny >>> !authenticated >>> >> >> You named the ACL "kerb-auth", not "authenticated". >> >> >>> # block certain user IDs from using proxy server # list of ad users >>> and service accounts to automatically deny proxy acl block_user >>> proxy_auth_regex -i "/etc/squid/block_user" >>> http_access deny block_user >> >> >> I suggest this to prevent re-login loop for these forbidden services: >> >> http_access deny !kerb-auth >> http_access deny block_user all >> >> >>> >>> # >>> -------------------------------------------------------------------- >>> -------- >>> # general whitelist >>> >>> # whitelist for locations/sites (override blocking) # allows complex >>> URLs # some bad_urls patterns are generic # they block suspicous >>> URLs or generally unwanted sites # this whitelist can make specific >>> exceptions within those acl bad_exception_urls url_regex -i >>> "/etc/squid/bad_exception_urls" >>> >>> # >>> -------------------------------------------------------------------- >>> -------- >>> # executable blocking >>> >>> # we do this separately from other content blocking # in order to >>> allow ITLIB to still download # doing it with other blocking causes >>> a flood of browser auth req's # for users visting sites with video >>> >>> # file extensions to block >>> # don't try to block .COM files here # it will get confused with >>> .com domain and block too many things acl exec_files url_regex -i >>> "/etc/squid/exec_files" >> >> Consider using the "urlpath_regex" ACL type instead. It does not >> match against the scheme://domain:port part of URLs. >> >> >>> >>> # usernames not to block >>> acl exec_users proxy_auth_regex -i "/etc/squid/exec_users" >>> >>> # activate >>> http_access deny !bad_exception_urls !exec_users exec_files >>> deny_info ERR_BLOCK_TYPE exec_files >>> >>> # >>> -------------------------------------------------------------------- >>> -------- >>> # selective whitelists >>> >>> # these override the general blacklists by explictly allowing things >>> # some multimedia services (I.E. YouTube) are permitted for certain >>> users # exempts them from content blocking in this section >>> >>> # list of users for this >>> acl mmedia_users proxy_auth_regex -i "/etc/squid/mmedia_users" >>> >>> # list of sites for this >>> acl mmedia_sites dstdomain "/etc/squid/mmedia_sites" >>> >>> # if a mmedia user attempts to access a mmedia site via appropriate >>> protocols, allow it # done for both HTTP/TCP/80 and HTTP/SSL/443 # >>> done for both HTTP request as well as HTTP reply/response # >>> otherwise the later bad_types Content-Type multimedia blocking rule >>> kicks in >>> >>> http_access allow methods_std proto_HTTP http_ports mmedia_sites mmedia_users >>> # tp_reply_access allow methods_std proto_HTTP http_ports mmedia_sites mmedia_users >>> >>> http_access allow method_CONNECT ssl_ports mmedia_sites mmedia_users >>> # http_reply_access allow method_CONNECT ssl_ports mmedia_sites mmedia_users >> >> >> FYI, Websites like YouTube can dynamically negotiate the media source >> ports to be non-standard values using Alt-Svc headers. >> >> If you had the default security settings at the top of your >> http_access >> rules: >> >> http_access deny !Safe_ports >> http_access deny CONNECT !SSL_Ports >> >> ... you would not need to make (bad) assumptions about the protocols >> and ports used by media sites here. >> >> Also, "mmedia_users" being last on the line risks a 407 re-auth >> challenge occuring. Best place it earlier. >> >> >> Leaving these rules as: >> >> http_access allow mmedia_users mmedia_sites >> >> >>> >>> # >>> -------------------------------------------------------------------- >>> -------- >>> # general blacklists >>> # porn, wastes of bandwidth, etc. >>> >>> >>> # blocked destinations, by host or domain # sites we don't want >>> people using acl bad_domains dstdomain "/etc/squid/bad_domains" >>> http_access deny !bad_exception_urls bad_domains >>> deny_info ERR_BLOCK_DST bad_domains >>> >>> # blocked destinations, by host or domain, regex pattern acl >>> bad_domains_regex dstdom_regex -i "/etc/squid/bad_domains_regex" >>> http_access deny !bad_exception_urls bad_domains_regex >>> deny_info ERR_BLOCK_DST bad_domains_regex >>> >>> # blocked destinations, by complex URL # typical use: block just >>> part of a site, by URL path # example use: block just the advertsing >>> section of a site acl bad_urls url_regex -i "/etc/squid/bad_urls" >>> http_access deny !bad_exception_urls bad_urls >>> deny_info ERR_BLOCK_DST bad_urls >>> >>> # blocked content types, by apparent file name acl bad_files >>> urlpath_regex -i "/etc/squid/bad_files" >>> http_access deny !bad_exception_urls bad_files deny_info >>> ERR_BLOCK_TYPE bad_files >>> >>> # blocked content types, by MIME content type, in response acl >>> bad_types rep_mime_type -i "/etc/squid/bad_types" >>> # http_reply_access deny bad_types !bad_exception_urls deny_info >>> ERR_BLOCK_TYPE bad_types >> >> >> FYI, in order for the deny_info action to be taken the ACL it is >> attached to must be the final one on a line. >> >> Previous config was fine, but this "bad_types" use will not work. You >> need to re-order the access checks like this: >> >> >> # http_reply_access deny !bad_exception_urls bad_types >> >> >>> >> >> This part from here ... >> >>> # >>> -------------------------------------------------------------------- >>> -------- # standard web (HTTP PUT/GET/etc) access >>> >>> # We basically allow any auth'ed user to connect via HTTP to >>> anywhere, # so long as it uses a standard port, and is not a direct >>> CONNECT # attempt, or blocked, or any of the other stuff above. >>> >>> http_access allow http_ports proto_HTTP methods_std >>> >>> # >>> -------------------------------------------------------------------- >>> -------- # direct CONNECT for HTTP-over-SSL (HTTPS) >>> >>> http_access allow method_CONNECT ssl_ports >>> >>> # >>> -------------------------------------------------------------------- >>> -------- >>> # deny any other CONNECT attempts >>> >>> http_access deny method_CONNECT >>> >>> # >>> -------------------------------------------------------------------- >>> -------- >>> # FTP via HTTP proxy >>> >>> http_access allow ftp_ports proto_FTP >>> >> >> ... to here. >> >> Is better handled by the default squid.conf: >> >> http_access deny !Safe_ports >> http_access deny CONNECT !Ssl_ports >> >> Placed at the top of your http_access lines. >> >> >>> # >>> -------------------------------------------------------------------- >>> -------- >>> # catch-all defaults >>> http_access allow kerb-auth >>> >>> # deny any request we missed in the above http_access deny all >>> >>> # If we allowed the request, allow the reply (HTTP response) as well. >>> # Rules above many allow or deny specific reply before now. >>> # If nothing more specific matched, we allow. >>> # This should be OK since we filter mainly on requests. >>> # http_reply_access allow all >>> >> >> FWIW, it is hard to tell what the exact last reply action could have >> been. So I would un-comment this allow line to be certain it is what >> happens. >> >> >>> #################################################################### >>> ########## >>> # END OF FILE >>> #################################################################### >>> ########## >>> >> >> HTH >> Amos >> >> _______________________________________________ >> squid-users mailing list >> squid-users@xxxxxxxxxxxxxxxxxxxxx >> https://lis/ >> ts.squid-cache.org%2Flistinfo%2Fsquid-users&data=05%7C02%7Cjosh.piana >> %40hexcel.com%7C3b51806fd45a486445a208dcd6cc8283%7C4248050df19546d5ac >> 9c0c7c52b04cae%7C0%7C0%7C638621421091750002%7CUnknown%7CTWFpbGZsb3d8e >> yJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0 >> %7C%7C%7C&sdata=BYN%2B7Opba35jH10drkdIZnvG7xTzYCO22wQEkJ9nTHE%3D&rese >> rved=0 _______________________________________________ >> squid-users mailing list >> squid-users@xxxxxxxxxxxxxxxxxxxxx >> https://lis/ >> ts.squid-cache.org%2Flistinfo%2Fsquid-users&data=05%7C02%7Cjosh.piana >> %40hexcel.com%7C3b51806fd45a486445a208dcd6cc8283%7C4248050df19546d5ac >> 9c0c7c52b04cae%7C0%7C0%7C638621421091750002%7CUnknown%7CTWFpbGZsb3d8e >> yJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0 >> %7C%7C%7C&sdata=BYN%2B7Opba35jH10drkdIZnvG7xTzYCO22wQEkJ9nTHE%3D&rese >> rved=0 > > _______________________________________________ > squid-users mailing list > squid-users@xxxxxxxxxxxxxxxxxxxxx > https://list/ > s.squid-cache.org%2Flistinfo%2Fsquid-users&data=05%7C02%7Cjosh.piana%4 > 0hexcel.com%7C3b51806fd45a486445a208dcd6cc8283%7C4248050df19546d5ac9c0 > c7c52b04cae%7C0%7C0%7C638621421091750002%7CUnknown%7CTWFpbGZsb3d8eyJWI > joiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7 > C%7C&sdata=BYN%2B7Opba35jH10drkdIZnvG7xTzYCO22wQEkJ9nTHE%3D&reserved=0 > _______________________________________________ > squid-users mailing list > squid-users@xxxxxxxxxxxxxxxxxxxxx > https://list/ > s.squid-cache.org%2Flistinfo%2Fsquid-users&data=05%7C02%7Cjosh.piana%4 > 0hexcel.com%7C3b51806fd45a486445a208dcd6cc8283%7C4248050df19546d5ac9c0 > c7c52b04cae%7C0%7C0%7C638621421091750002%7CUnknown%7CTWFpbGZsb3d8eyJWI > joiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7 > C%7C&sdata=BYN%2B7Opba35jH10drkdIZnvG7xTzYCO22wQEkJ9nTHE%3D&reserved=0 _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx https://lists.squid-cache.org/listinfo/squid-users _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx https://lists.squid-cache.org/listinfo/squid-users
