Dear Amos,
Thank you. I didn't know that it cannot yet work on token based auth.So there is no work around?
Really appreciated.
On 12 January 2016 at 15:00, <squid-users-request@xxxxxxxxxxxxxxxxxxxxx> wrote:
Send squid-users mailing list submissions to
squid-users@xxxxxxxxxxxxxxxxxxxxx
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.squid-cache.org/listinfo/squid-users
or, via email, send a message with subject or body 'help' to
squid-users-request@xxxxxxxxxxxxxxxxxxxxx
You can reach the person managing the list at
squid-users-owner@xxxxxxxxxxxxxxxxxxxxx
When replying, please edit your Subject line so it is more specific
than "Re: Contents of squid-users digest..."
Today's Topics:
1. guideline on limiting users per IP (3@D4rkn3ss DuMb)
2. Re: kerberos authentication with a machine account doesn't
work (LYMN)
3. Re: guideline on limiting users per IP (Amos Jeffries)
4. cache_mem differs from output in mgr:config (XUFENG)
5. host header forgery false positives (Jason Haar)
----------------------------------------------------------------------
Message: 1
Date: Mon, 11 Jan 2016 21:54:18 +0300
From: "3@D4rkn3ss DuMb" <32d4rkn3ss@xxxxxxxxx>
To: squid-users@xxxxxxxxxxxxxxxxxxxxx
Subject: guideline on limiting users per IP
Message-ID:
<CAMDafwBjx9i4ErNQFkvYO1UNMZyv4ah6wPeVf_ZCgJ_a-vKp2w@xxxxxxxxxxxxxx>
Content-Type: text/plain; charset="utf-8"
Dear all,
I hope you all doing fine ! I know that this question has already been
asked multiple times, and I already checked the logs (old mailing list) but
I didn't find there my answers ... By the way, I am suspecting that this
might have something to do with the squid version itself.
In fact, I am running squid on two different servers: CentOS 6 and Debian
sid (testing)! I implemented the last one as a backup, but I would like to
perform a hot swap now since the version in CentOS does not support the
max_user_ip policy.
The version on Debian is 3.5.12 and but still max_user_ip does not work at
all and squid in verbose mode does not reject it but go through it
correctly, so I m bit confused. The authentication is against AD win 2008.
I will send the more details later on but If somebody could confirm
regarding the compatibility between the version and the max_user_ip/ AD
authentication.
Thank you in advance,
Ken
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20160111/c2afb02f/attachment-0001.html>
------------------------------
Message: 2
Date: Tue, 12 Jan 2016 09:58:44 +1030
From: LYMN <brett.lymn@xxxxxxxxxxxxxx>
To: Amos Jeffries <squid3@xxxxxxxxxxxxx>
Cc: squid-users@xxxxxxxxxxxxxxxxxxxxx
Subject: Re: kerberos authentication with a machine
account doesn't work
Message-ID: <20160111232844.GB19684@xxxxxxxxxxx>
Content-Type: text/plain; charset="us-ascii"
On Mon, Jan 11, 2016 at 09:06:27PM +1300, Amos Jeffries wrote:
> On 11/01/2016 2:48 p.m., LYMN wrote:
> >
> > I did manage to get this working, you did mention the correct solution
> > right down the end of your message.
> >
>
> Correct for you yes. That can happen when making half-blind guesses at
> what the problem actually is based on partial information. It might have
> been any of the issues mentioned or any of the solutions mentioned.
> Others in future may find differently depending on what they have mucked
> up or payed around with before asking.
>
Yes, correct for me. It indeed could be one or more of the suggestions
that were made. Kerberos errors are such fun to debug made more so by
multiple problems causing the same error message. I have had a
situation where I had a few different problems and it wasn't until I had
sorted them all that the error message went away but it is so unsettling
to get the same error after you have made a change that you are sure
makes things correct.
> > On Thu, Jan 07, 2016 at 09:37:46AM +0100, L.P.H. van Belle wrote:
> >> Hai,
> >>
> >>
> >> Few things to check.
> >>
> >> /etc/krb5.keytab should have rights 600 (root:root)
> >>
> >
> > And this was the problem but it should not, in my case, be as you
> > stated. In fact, /etc/krb5.keytab needed to have rights 640 with
> > ownership root:nobody. This is because the kerberos authenticator runs
> > as the user nobody and needs access to the keytab. I am not so sure I
> > like this situation because this does mean the nobody user now has
> > access to the machine kerberos keys not just the ones for the http SPN.
>
> "nobody" is the default low-privileged user account unless you build
> Squid with the --with-default-user=X - in which cases it will default to
> the "X" account.
>
> You can also configure "cache_effective_user X" in squid.conf to
> override the default if your Squid was built with one you dont want to use.
>
Yes. I think you have clarified the point that I was trying to make
which was the user/group used may depend on your configuration or squid
build.
--
Brett Lymn
This email has been sent on behalf of one of the following companies within the BAE Systems Australia group of companies:
BAE Systems Australia Limited - Australian Company Number 008 423 005
BAE Systems Australia Defence Pty Limited - Australian Company Number 006 870 846
BAE Systems Australia Logistics Pty Limited - Australian Company Number 086 228 864
Our registered office is Evans Building, Taranaki Road, Edinburgh Parks,
Edinburgh, South Australia, 5111. If the identity of the sending company is
not clear from the content of this email please contact the sender.
This email and any attachments may contain confidential and legally
privileged information. If you are not the intended recipient, do not copy or
disclose its content, but please reply to this email immediately and highlight
the error to the sender and then immediately delete the message.
------------------------------
Message: 3
Date: Tue, 12 Jan 2016 14:21:34 +1300
From: Amos Jeffries <squid3@xxxxxxxxxxxxx>
To: squid-users@xxxxxxxxxxxxxxxxxxxxx
Subject: Re: guideline on limiting users per IP
Message-ID: <5694551E.60406@xxxxxxxxxxxxx>
Content-Type: text/plain; charset=utf-8
On 12/01/2016 7:54 a.m., 3 wrote:
>
> The version on Debian is 3.5.12 and but still max_user_ip does not work at
> all and squid in verbose mode does not reject it but go through it
> correctly, so I m bit confused. The authentication is against AD win 2008.
>
> I will send the more details later on but If somebody could confirm
> regarding the compatibility between the version and the max_user_ip/ AD
> authentication.
All versions of Squid since 2.4 support the max_user_ip ACL.
It does only apply to username based authentication (eg Basic) though.
Token based authentication, particularly ones where the token changes
per TCP connection (eg NTLM, Kerberos) or per message (eg Digest) do not.
Amos
------------------------------
Message: 4
Date: Tue, 12 Jan 2016 09:36:40 +0800
From: "XUFENG" <xufengnju@xxxxxxxx>
To: "squid-users" <squid-users@xxxxxxxxxxxxxxxxxxxxx>
Subject: cache_mem differs from output in mgr:config
Message-ID: <20160112013640.E3D7116600A5@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Content-Type: text/plain; charset=GBK
My squid's cache_mem in squid.conf differs from output in mgr:config.
[root@squid-cache ~]# /usr/local/squid/bin/squidclient -h 127.0.0.1 -p 80 -w aaaaaa mgr:config |grep cache_mem
Sending HTTP request ... done.
cache_mem 0 bytes
[root@squid-cache ~]# /usr/local/squid/sbin/squid -v
Squid Cache: Version 3.4.14
configure options: '--prefix=/usr/local/squid' '--disable-icap-client' '--disable-wccp' '--disable-wccpv2' '--disable-htcp' '--disable-ident-lookups' '--disable-auto-locale' --enable-ltdl-convenience
[root@squid-cache ~]# cat /usr/local/squid/etc/squid.conf
unique_hostname squid-cache.xufeng.info
visible_hostname squid-cache.xufeng.info
http_port 80 accel
cache_mem 4096 MB
cache_dir ufs /app/cache 8096 32 5120
cache_log /usr/local/squid/var/logs/cache.log
access_log /usr/local/squid/var/logs/access.log
acl PURGE method PURGE
cachemgr_passwd aaaaaa config reconfigure shutdown
http_access allow manager localhost
http_access deny manager
http_access allow PURGE localhost
http_access deny PURGE
cache_mgr xufengnju@xxxxxxx
cache_effective_user squid
cache_effective_group squid
cache_peer 10.1.6.38 parent 80 0 no-query originserver round-robin name=server_xufeng_info
acl sites_xufeng_info dstdomain .xufeng.info
cache_peer_access server_xufeng_info allow sites_xufeng_info
[root@squid-cache ~]# cat /etc/issue
CentOS release 5.11 (Final)
Kernel \r on an \m
[root@squid-cache ~]# uname -a
Linux squid-cache.xufeng.info 2.6.18-407.el5 #1 SMP Wed Nov 11 08:12:41 EST 2015 x86_64 x86_64 x86_64 GNU/Linux
Anything wrong?
Thank you for your help.
------------------------------
Message: 5
Date: Tue, 12 Jan 2016 14:40:24 +1300
From: Jason Haar <Jason_Haar@xxxxxxxxxxx>
To: squid-users@xxxxxxxxxxxxxxxxxxxxx
Subject: host header forgery false positives
Message-ID: <56945988.3030003@xxxxxxxxxxx>
Content-Type: text/plain; charset=utf-8
Hi there
I am finding squid-3.5.13 is false positive-ing on ssl-bump way too
often. I'm just using "peek-and-splice" on intercepted port 443 to
create better squid logfiles (ie I'm not actually bump-ing) but that
enables enough of the code to cause the Host forgery code to kick in -
but it doesn't work well in a real network
As you can see below, here's a handful of sites that we're seeing this
trigger on, and as it's my home network I can guarantee there's no odd
DNS setups or forgery going on. This is just real-world websites doing
what they do (ie are totally outside our control or influence)
I don't know how the forgery-checking code works, but I guess what's
happened is the DNS lookups the squid server does doesn't contain the
same IP addresses the client resolved the same DNS name to. I must say
that is odd because all our home computers use the squid server as their
DNS server - just as the squid service does - so there shouldn't be any
such conflict - but I imagine caching could be to blame (maybe the
clients cache old values longer/shorter timeframes than squid does).
This is a bit of a show-stopper to ever using bump: having perfectly
good websites being unavailable really isn't an option (in the case of
"peek-and-splice" over intercepted they seem to hang forever when this
error occurs). Perhaps an option to change it's behaviour would be
better? eg enable/disable and maybe "ignore client and use the IP
addresses squid thinks are best" could work?
Jason
2016/01/12 06:04:10.303 kid1| SECURITY ALERT: Host header forgery
detected on local=121.254.166.35:443 remote=192.168.0.8:55203 FD 95
flags=33 (local IP does not match any domain IP)
2016/01/12 06:04:10.303 kid1| SECURITY ALERT: on URL: nydus.battle.net:443
2016/01/12 06:11:47.146 kid1| SECURITY ALERT: Host header forgery
detected on local=54.231.112.120:443 remote=192.168.0.8:56072 FD 273
flags=33 (local IP does not match any domain IP)
2016/01/12 06:11:47.146 kid1| SECURITY ALERT: on URL:
redditstatic.s3.amazonaws.com:443
2016/01/12 06:14:24.125 kid1| SECURITY ALERT: Host header forgery
detected on local=54.231.2.145:443 remote=192.168.0.8:56304 FD 286
flags=33 (local IP does not match any domain IP)
2016/01/12 06:14:24.125 kid1| SECURITY ALERT: on URL:
adzerk-www.s3.amazonaws.com:443
2016/01/12 06:14:24.125 kid1| SECURITY ALERT: Host header forgery
detected on local=54.231.2.145:443 remote=192.168.0.8:56305 FD 287
flags=33 (local IP does not match any domain IP)
2016/01/12 06:14:24.125 kid1| SECURITY ALERT: on URL:
adzerk-www.s3.amazonaws.com:443
2016/01/12 06:37:52.737 kid1| SECURITY ALERT: Host header forgery
detected on local=54.231.114.114:443 remote=192.168.0.8:58411 FD 309
flags=33 (local IP does not match any domain IP)
2016/01/12 06:37:52.737 kid1| SECURITY ALERT: on URL:
redditstatic.s3.amazonaws.com:443
2016/01/12 06:37:57.127 kid1| SECURITY ALERT: Host header forgery
detected on local=23.21.91.58:443 remote=192.168.0.8:58421 FD 298
flags=33 (local IP does not match any domain IP)
2016/01/12 06:37:57.127 kid1| SECURITY ALERT: on URL:
pixel.redditmedia.com:443
2016/01/12 06:37:58.158 kid1| SECURITY ALERT: Host header forgery
detected on local=54.231.49.32:443 remote=192.168.0.8:58422 FD 299
flags=33 (local IP does not match any domain IP)
2016/01/12 06:37:58.158 kid1| SECURITY ALERT: on URL:
redditstatic.s3.amazonaws.com:443
2016/01/12 07:59:46.480 kid1| SECURITY ALERT: Host header forgery
detected on local=54.231.82.178:443 remote=192.168.0.8:64203 FD 17
flags=33 (local IP does not match any domain IP)
2016/01/12 07:59:46.480 kid1| SECURITY ALERT: on URL:
redditstatic.s3.amazonaws.com:443
2016/01/12 10:42:07.376 kid1| SECURITY ALERT: Host header forgery
detected on local=192.30.252.129:443 remote=192.168.0.7:50212 FD 13
flags=33 (local IP does not match any domain IP)
2016/01/12 10:42:07.376 kid1| SECURITY ALERT: on URL: github.com:443
2016/01/12 10:49:52.696 kid1| SECURITY ALERT: Host header forgery
detected on local=54.231.13.169:443 remote=192.168.0.7:40358 FD 21
flags=33 (local IP does not match any domain IP)
2016/01/12 10:49:52.696 kid1| SECURITY ALERT: on URL:
adzerk-www.s3.amazonaws.com:443
2016/01/12 12:19:00.374 kid1| SECURITY ALERT: Host header forgery
detected on local=54.149.175.172:443 remote=192.168.0.7:57686 FD 53
flags=33 (local IP does not match any domain IP)
2016/01/12 12:19:00.374 kid1| SECURITY ALERT: on URL:
shavar.services.mozilla.com:443
2016/01/12 12:38:33.666 kid1| SECURITY ALERT: Host header forgery
detected on local=54.231.114.60:443 remote=192.168.0.7:60694 FD 240
flags=33 (local IP does not match any domain IP)
2016/01/12 12:38:33.666 kid1| SECURITY ALERT: on URL: s3.amazonaws.com:443
2016/01/12 12:45:24.356 kid1| SECURITY ALERT: Host header forgery
detected on local=52.35.143.137:443 remote=192.168.0.7:53313 FD 54
flags=33 (local IP does not match any domain IP)
2016/01/12 12:45:24.356 kid1| SECURITY ALERT: on URL:
events.redditmedia.com:443
2016/01/12 12:45:30.568 kid1| SECURITY ALERT: Host header forgery
detected on local=54.204.8.186:443 remote=192.168.0.7:44144 FD 237
flags=33 (local IP does not match any domain IP)
2016/01/12 12:45:30.568 kid1| SECURITY ALERT: on URL:
engine.a.redditmedia.com:443
2016/01/12 12:49:10.490 kid1| SECURITY ALERT: Host header forgery
detected on local=192.30.252.128:443 remote=192.168.0.7:36340 FD 79
flags=33 (local IP does not match any domain IP)
2016/01/12 12:49:10.490 kid1| SECURITY ALERT: on URL: github.com:443
2016/01/12 12:49:21.162 kid1| SECURITY ALERT: Host header forgery
detected on local=192.30.252.127:443 remote=192.168.0.7:41264 FD 250
flags=33 (local IP does not match any domain IP)
2016/01/12 12:49:21.162 kid1| SECURITY ALERT: on URL: api.github.com:443
2016/01/12 12:49:51.399 kid1| SECURITY ALERT: Host header forgery
detected on local=192.30.252.129:443 remote=192.168.0.7:50925 FD 203
flags=33 (local IP does not match any domain IP)
2016/01/12 12:49:51.399 kid1| SECURITY ALERT: on URL: github.com:443
2016/01/12 13:03:57.040 kid1| SECURITY ALERT: Host header forgery
detected on local=192.30.252.92:443 remote=192.168.0.7:46645 FD 291
flags=33 (local IP does not match any domain IP)
2016/01/12 13:03:57.040 kid1| SECURITY ALERT: on URL: live.github.com:443
2016/01/12 13:03:59.200 kid1| SECURITY ALERT: Host header forgery
detected on local=192.30.252.92:443 remote=192.168.0.7:46647 FD 275
flags=33 (local IP does not match any domain IP)
2016/01/12 13:03:59.200 kid1| SECURITY ALERT: on URL: live.github.com:443
--
Cheers
Jason Haar
Corporate Information Security Manager, Trimble Navigation Ltd.
Phone: +1 408 481 8171
PGP Fingerprint: 7A2E 0407 C9A6 CAF6 2B9F 8422 C063 5EBB FE1D 66D1
------------------------------
Subject: Digest Footer
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users
------------------------------
End of squid-users Digest, Vol 17, Issue 37
*******************************************
_______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
