Re: [squid-users] Re: slow browsing in centos 6.3 with squid 3 !!

From: Amos Jeffries <squid3_at_treenet.co.nz>
Date: Mon, 25 Feb 2013 13:34:03 +1300

On 25/02/2013 12:30 a.m., Ahmad wrote:
> hello ,
> thanks Amos , ive modified the config file as u suggested .
> after removing the raid 0 , ive noted a better performance .
> =============================================================
> in general , browsing speed is lower than the speed in the absence of squid
> , but any way it is acceptable and i wish to enhance it as i can !
> ======================================================
> As i mentioned in the beginning , i have an excellent hardware with about 32
> G ram.
> but i have major problem in squid-guard !!
> after sometime it begins to bypass!!!!!!
> i searched to use dansguardian instead of squid-guard but it seems that
> dansguardian is not compatible with tproxy !!===> seems as shook to me !
> ==================================================
>
> i have pumped only 1000 users with about 150-180 M only !!!!
> here is the log of squidguard !
> ==============
> 2013-02-24 06:25:32 [17282] Warning: Possible bypass attempt. Found multiple
> slashes where only one is expected:
> http://surprises.tango.me/ts//assets/ayol_fairy_gingerbread_surprise_2-UI_VG_SELECTOR_PACK-android.zip

Ah I see. SquidGuard is detecting what it reports as "bypass attempt".

This is NOT squidguard being bypassed.

There is a type of Web server attack *called* a "bypass attack" which
was designed to use multiple slashes like // or ./ or ../ to trick
simple URL matching security rules (like Squidguard appears to be using)
into ignoring parts of the URL. Any pattern match regex which you are
applying on the URL looking for the "http://" by ignoring the "http:"
portion and identifying the "//" portion as the start will ignore the
real domain name, attack login details, and maybe some of the path.

However "//" is not necessarily a wrong patten. The author of the
website determines what the URL syntax is, so if the web server the URL
is supposed to be handled by can cope with it correctly that is a valid URL.

> 2013-02-24 06:27:04 [17282] Warning: Possible bypass attempt. Found a
> trailing dot in the domain name:
> http://www.google.ps/xjs/_/js/s/sy15,gf,adnsp,wta,sy5,sy45,sy47,sy6,sy50,sy46,sy51,sy7,sy48,sy53,sy54,sy49,sy52,adct,ssi/rt=j/ver=OMt9IcC1O10.en_US./am=CA/d=0/sv=1/rs=AItRSTOekKHDXRJiLDzqcQkCe4C3pVWkbw

"Trailing dot" ??

Oh I see. .http://.... C1O10.en_US./

Whatever URL match squidGuard is testing there is *VERY* broken. Only
[a-zA-Z0-9\-\.\:] are permitted characters in domain names (or raw-IP
whch can also be there). squidGuard pattern is currently is allowing _ ,
/ = and probably # and ? as well I guess.
You need to fix that pattern *immediately* regardless of whatever else
you do about squidGuard.

> [root_at_squid ~]#
> ==============================
> here is a sample of cache.log file:
> {Accept: */*
> Content-Type: application/x-www-form-urlencoded
> 2013/02/24 06:24:18| WARNING: HTTP header contains NULL characters {Accept:
> */*
> Content-Type: application/x-www-form-urlencoded}
> NULL
> {Accept: */*
> Content-Type: application/x-www-form-urlencoded
> 2013/02/24 06:24:18| WARNING: HTTP header contains NULL characters {Accept:
> */*
> Content-Type: application/x-www-form-urlencoded}
> NULL
> {Accept: */*
> Content-Type: application/x-www-form-urlencoded
> 2013/02/24 06:24:18| WARNING: HTTP header contains NULL characters {Accept:
> */*
> Content-Type: application/x-www-form-urlencoded}
> NULL
> {Accept: */*
> Content-Type: application/x-www-form-urlencoded
> 2013/02/24 06:24:18| WARNING: HTTP header contains NULL characters {Accept:
> */*
> Content-Type: application/x-www-form-urlencoded}
> NULL
> {Accept: */*
> Content-Type: application/x-www-form-urlencoded
> 2013/02/24 06:24:41| clientProcessRequest: Invalid Request
> 2013/02/24 06:25:00| clientProcessRequest: Invalid Request
> 2013/02/24 06:25:04| clientProcessRequest: Invalid Request
> 2013/02/24 06:25:07| clientProcessRequest: Invalid Request
> 2013/02/24 06:25:09| helperHandleRead: unexpected reply on channel 0 from
> redirector #1 ''

The squidGuard helper is sending Squid more lines of response than Squid
sent lines of requests.
It looks like something is causing an extra newline at the end of a
response.

The above happening will cause that squidGuard helper to be killed and a
new one to be started. This process will slow down your Squid with a
small pause as the new helper is started. If it happens often that could
be a large part of your speed problem.

Amos
Received on Mon Feb 25 2013 - 00:34:09 MST

This archive was generated by hypermail 2.2.0 : Mon Feb 25 2013 - 12:00:05 MST