Re: [squid-users] Squid 4 Development / Blog
On 25/02/18 06:26, Chase Wright wrote: > It's been nearly 2 years since there was a blog post about Squid 4.x and > I've noticed that the daily auto-generated Squid 3.5 stable branch > release last updated on "08 Dec 2017" > > I've also noticed that the last two CVEs were only fixed in the 4.x > branch (2018) > > Is the squid team planning to move 4.x to stable soon? > "Soon" yes. Those last few bugs proved to be extremely painful and slow to get fixed. As of today we have one major bug unfixed, and some testing needed for checking the stability of the recent huge fixes. I'm just waiting on the backports of some small regressions already found before the next v4 beta package. I am *hoping* not to have to release any more 3.5 packages. But that of course depends on what the timeline this final bug turns into. Amos ___ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
[squid-users] Squid 4 Development / Blog
It's been nearly 2 years since there was a blog post about Squid 4.x and I've noticed that the daily auto-generated Squid 3.5 stable branch release last updated on "08 Dec 2017" I've also noticed that the last two CVEs were only fixed in the 4.x branch (2018) Is the squid team planning to move 4.x to stable soon? Cheers! ___ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
Re: [squid-users] kerberos authentication with kerberos groups
Hi Jeroen, Do you use Active Directory as ldap server ? My automated test says it is not. I use this check to determine the group attribute check. support_ldap.cc(342): pid=2951 :2018/02/20 17:02:27| kerberos_ldap_group: DEBUG: Search ldap server with bind path CN=Schema,CN=Configuration,DC=bnh,DC=local and filter: (ldapdisplayname=samaccountname) support_ldap.cc(345): pid=2951 :2018/02/20 17:02:27| kerberos_ldap_group: DEBUG: Found 0 ldap entries support_ldap.cc(350): pid=2951 :2018/02/20 17:02:27| kerberos_ldap_group: DEBUG: Determined ldap server not as an Active Directory server Markus "Jeroen Ruijter" wrote in message news:510fcecd6e595a4d83bf67fc07028e7507c99...@bhmb-01.bnh.local... I believe this has to be the problem, but how do I solve it? Its almost at the end of the whole listing support_ldap.cc(333): pid=2951 :2018/02/20 17:02:27| kerberos_ldap_group: DEBUG: Search ldap server with bind path "" and filter: (objectclass=*) support_ldap.cc(602): pid=2951 :2018/02/20 17:02:27| kerberos_ldap_group: DEBUG: Search ldap entries for attribute : schemaNamingContext support_ldap.cc(645): pid=2951 :2018/02/20 17:02:27| kerberos_ldap_group: DEBUG: 1 ldap entry found with attribute : schemaNamingContext support_ldap.cc(342): pid=2951 :2018/02/20 17:02:27| kerberos_ldap_group: DEBUG: Search ldap server with bind path CN=Schema,CN=Configuration,DC=bnh,DC=local and filter: (ldapdisplayname=samaccountname) kerberos_ldap_group.cc(283): pid=2951 :2018/02/20 17:02:21| kerberos_ldap_group: INFO: Starting version 1.3.1sq support_group.cc(382): pid=2951 :2018/02/20 17:02:21| kerberos_ldap_group: INFO: Group list ADGroupRaamregeling@ support_group.cc(447): pid=2951 :2018/02/20 17:02:21| kerberos_ldap_group: INFO: Group ADGroupRaamregeling Domain support_netbios.cc(83): pid=2951 :2018/02/20 17:02:21| kerberos_ldap_group: DEBUG: Netbios list NULL support_netbios.cc(87): pid=2951 :2018/02/20 17:02:21| kerberos_ldap_group: DEBUG: No netbios names defined. support_lserver.cc(82): pid=2951 :2018/02/20 17:02:21| kerberos_ldap_group: DEBUG: ldap server list NULL support_lserver.cc(86): pid=2951 :2018/02/20 17:02:21| kerberos_ldap_group: DEBUG: No ldap servers defined. kerberos_ldap_group.cc(283): pid=2953 :2018/02/20 17:02:21| kerberos_ldap_group: INFO: Starting version 1.3.1sq support_group.cc(382): pid=2953 :2018/02/20 17:02:21| kerberos_ldap_group: INFO: Group list ADGroupRaamregeling@ support_group.cc(447): pid=2953 :2018/02/20 17:02:21| kerberos_ldap_group: INFO: Group ADGroupRaamregeling Domain support_netbios.cc(83): pid=2953 :2018/02/20 17:02:21| kerberos_ldap_group: DEBUG: Netbios list NULL support_netbios.cc(87): pid=2953 :2018/02/20 17:02:21| kerberos_ldap_group: DEBUG: No netbios names defined. support_lserver.cc(82): pid=2953 :2018/02/20 17:02:21| kerberos_ldap_group: DEBUG: ldap server list NULL support_lserver.cc(86): pid=2953 :2018/02/20 17:02:21| kerberos_ldap_group: DEBUG: No ldap servers defined. kerberos_ldap_group.cc(283): pid=2952 :2018/02/20 17:02:21| kerberos_ldap_group: INFO: Starting version 1.3.1sq support_group.cc(382): pid=2952 :2018/02/20 17:02:21| kerberos_ldap_group: INFO: Group list ADGroupRaamregeling@ support_group.cc(447): pid=2952 :2018/02/20 17:02:21| kerberos_ldap_group: INFO: Group ADGroupRaamregeling Domain support_netbios.cc(83): pid=2952 :2018/02/20 17:02:21| kerberos_ldap_group: DEBUG: Netbios list NULL support_netbios.cc(87): pid=2952 :2018/02/20 17:02:21| kerberos_ldap_group: DEBUG: No netbios names defined. support_lserver.cc(82): pid=2952 :2018/02/20 17:02:21| kerberos_ldap_group: DEBUG: ldap server list NULL support_lserver.cc(86): pid=2952 :2018/02/20 17:02:21| kerberos_ldap_group: DEBUG: No ldap servers defined. 2018/02/20 17:02:21 kid1| helperOpenServers: Starting 5/5 'ext_kerberos_ldap_group_acl' processes kerberos_ldap_group.cc(283): pid=2954 :2018/02/20 17:02:21| kerberos_ldap_group: INFO: Starting version 1.3.1sq support_group.cc(382): pid=2954 :2018/02/20 17:02:21| kerberos_ldap_group: INFO: Group list ADGroupRaamregeling@ support_group.cc(447): pid=2954 :2018/02/20 17:02:21| kerberos_ldap_group: INFO: Group ADGroupRaamregeling Domain support_netbios.cc(83): pid=2954 :2018/02/20 17:02:21| kerberos_ldap_group: DEBUG: Netbios list NULL support_netbios.cc(87): pid=2954 :2018/02/20 17:02:21| kerberos_ldap_group: DEBUG: No netbios names defined. support_lserver.cc(82): pid=2954 :2018/02/20 17:02:21| kerberos_ldap_group: DEBUG: ldap server list NULL support_lserver.cc(86): pid=2954 :2018/02/20 17:02:21| kerberos_ldap_group: DEBUG: No ldap servers defined. kerberos_ldap_group.cc(283): pid=2955 :2018/02/20 17:02:21| kerberos_ldap_group: INFO: Starting version 1.3.1sq support_group.cc(382): pid=2955 :2018/02/20 17:02:21| kerberos_ldap_group: INFO: Group list ADGroupRaamregeling@ support_group.cc(447): pid=2955 :2018/02/20 17:02:21| kerberos_ldap_group: INFO: Group ADGroupRaamregeling Domain
Re: [squid-users] Kerberos negotiate slow avg service time
On 24/02/18 06:29, erdosain9 wrote: > Hi to all. > I dont know why i have this bad values. My network is woking fine. How i can > do to fix this. I think is a high value. > > HTTP/1.1 200 OK > Server: squid/3.5.27 > Mime-Version: 1.0 > Date: Fri, 23 Feb 2018 17:16:25 GMT > Content-Type: text/plain;charset=utf-8 > Expires: Fri, 23 Feb 2018 17:16:25 GMT > Last-Modified: Fri, 23 Feb 2018 17:16:25 GMT > X-Cache: MISS from proxy.mydomain.lan > X-Cache-Lookup: MISS from proxy.mydomain.lan:3128 > Via: 1.1 proxy.mydomain.lan (squid/3.5.27) > Connection: close > > Negotiate Authenticator Statistics: > program: /lib64/squid/negotiate_kerberos_auth > number active: 50 of 50 (0 shutting down) > requests sent: 4106 > replies received: 4105 > queue length: 0 > avg service time: 82 msec The above "avg service time" is not bad for a system as complicated as Kerberos. Note that this is significantly less than the outstanding requests listed below in the report. That is a sign that a very large number of the lookups are performed very, very fast. In other words; what you see in the report is _only_ the odd ones that do go slow enough to show up there. With maybe, at most, a few of the faster ones that happened by chance to be partially done at the instant the report was generated. Be aware that it is normal for a helper which has not been used much to require time to refresh its internal state in order to process a request. Avoiding that problem is why you see the clear pattern of #Requests going to one helper, with a second getting most of the remainder and so on. Squid intentionally biases lookups towards the most recently used/updated helper. Also, the longer delay times visible being for the later helpers down the list is another side effect of that problem. As Yuri cryptically asked, did this come to your attention due to customer complaints? or just while observing the reports? if it is not causing observable issues to the clients I would not worry. If you want to tune the helpers better than default, you can maybe further reduce that state refresh by configuring the helper with explicit details about what backed server to be contacting. A lot of the delays are caused by sequences of DNS lookups and parsing + processing the machine KeyTab files. The debug (-d) option of the helper itself can assist you with identifying which of its internal processes is going slowest. Just try not to drown in the flood of data from those very, very fast ones. > >ID #FD PID # Requests # Replies Flags Time > Offset > Request > 2118 5725911831182 B R 0.293 > 0 (none) > 2222 57260 652 652 0.164 > 0 (none) ... > > > ###Kerberos Auth with ActiveDirectory### > auth_param negotiate program /lib64/squid/negotiate_kerberos_auth -s > HTTP/proxy.empddh@empddh.lan > auth_param negotiate children 50 startup=0 idle=1 > auth_param basic credentialsttl 2 hours > auth_param negotiate keep_alive on > ___ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
Re: [squid-users] Block some web to a group of ip and allow the rest.
On 24/02/18 04:45, erdosain9 wrote: > Hi to all. > Im trying to block some web to a ip group. > > [root@squid ips]# cat i-restringidos.lst > 192.168.1.42 > 192.168.1.43 > 192.168.1.44 > 192.168.1.45 > 192.168.1.99 > 192.168.1.50 > 192.168.1.128 > > This same ip group has access to all internet. > [root@squid ips]# cat prensa_isla.lst > 192.168.1.42 > 192.168.1.43 > 192.168.1.44 > 192.168.1.45 > 192.168.1.99 > 192.168.1.50 > 192.168.1.128 If they are really the same, then it is better to use one ACL name instead of two like that. Using one will help you see more clearly what your config is actually doing for those IPs, and also make it impossible to accidentally configure something that can never happen. Like "i-restringidos !prensa_isla". > > This is what i want to block > [root@squid listas]# cat restringidos.lst > .whatsapp.com > .facebook.com > .instagram.com > .twitter.com > > > (so i have this 2 acl whit the same ip, one for deny, the other to allow. > > So this is my config... and it's not working. Some help?? Thanks! > That is a very complicated setup you have. Below are some simplifications you can make to shorten it and make it easier to read what is going on... > > http_access allow localhost manager > http_access deny manager > http_access deny to_localhost > > http_access deny i-restringidos restringidos The above line does exactly what you are asking for. The only problem that could happen is that the clients in i-restringidos are not doing what you think they are. Perhapse they are actually: a) not using your proxy to contact those sites, and/or b) using a protocol that skips through the proxy. For example; Using SPDY, QUICK, WebSockets etc. instead of HTTP. and/or, c) using a domain name (or raw IP address) not on your list. For example most of Facebook traffic usually comes from fbcdn.net, "Facebook.com" is just the brand name and front page(s). > http_access allow prensa-isla > http_access allow red6 > http_access allow red2 All the below lines have !dominios_denegados. So you can add this here: http_access deny dominios_denegados ... then remove all the "!dominios_denegados". > http_access allow logistica !multimedia !peligrosos > http_access allow adminis All the below lines have "!peligrosos". So you can do the same again: http_access deny peligrosos And again with !multimedia; ... http_access deny multimedia .. leaving the remainder looking like this: http_access allow institucionales http_access allow patriysumi http_access allow proyecto http_access allow rrhh http_access allow programas_y_activ http_access allow auditoria http_access allow legales http_access allow proteccion http_access allow oe http_access deny all > > refresh_pattern -i \.jpg$ 30 0% 30 ignore-no-cache ignore-no-store > ignore-private The ignore-no-cache parameter no longer exists. Please remove. > > request_header_access From deny all > request_header_access Server deny all > request_header_access WWW-Authenticate deny all > request_header_access Link deny all > request_header_access Cache-Control deny all > request_header_access Proxy-Connection deny all > request_header_access X-Cache deny all > request_header_access X-Cache-Lookup deny all > request_header_access Via deny all > request_header_access X-Forwarded-For deny all > request_header_access Pragma deny all > request_header_access Keep-Alive deny all The Server, X-Cache, X-Cache-Lookup headers are not request headers. Those lines are pointless. The Proxy-Connection header is obsolete and automatically stripped by all current Squid. No need to do anything for it either. The Keep-Alive header is hop-by-hop ad stripped by Squid without havign anyeffect. The Pragma header is mandatory for HTTP proxies to ignore except in the rare case of "Pragma:no-cache". Current Squid are HTTP/1.1 so even that is even more rarely mattering. ALmost all traffic will ignore this header. Also, these directives do not in any way affect how your Squid interprets those headers. All it does is erase them from traffic going to servers. Which in the case of Pragma is mandatory to pass on exactly as received. Right now you are breaking all HTTP/1.0 caches across the Internet between your proxy and the origin server. > > delay_pools 15 > #Limitar Youtube > delay_class 1 2 > delay_parameters 1 200/200 10/100 Two things about these delay rules: 1) Youtube and Facebook are different companies and services. So traffic going to YouTube cannot simlultaneously be going to Facebook. That makes the Facebook part of the check pointless. 2) All of the below lines have "youtube !facebook". Like with http_access simplification you can make these rules vastly simpler by checking for the forbidden property and rejecting based on that before any allow rules. So, combining the two details mentioned above. You can make this your first rule: delay_access 1 deny !youtube ... then remove the
