Application Control Logging Question

Hi Michael,

While I can't explain why other then my error cc get http sc_local_db none was there. However cc get http use_sxl_urid was 0. I am not sure how I missed it. In the line from the web log is this simply a warning indicating the length of the URL? I am not seeing the CFF server logging after making the changes and restarting. Thanks for you help!

BR,
Jim 


2014:03:05-19:48:50 Oasis httpproxy[5381]: id="0003" severity="info" sys="SecureWeb" sub="http" request="0xda6b980" function="parse_method_line" file="request.c" line="880" message="Ultra long url, length: 2163"

For the use_sxl_urid to be set to 1 automatically the following must be true:
Web Protection \ Web Filtering must be On
Endpoint Protection \ Computer Management must be On
Endpoint Protection \ Web Control must be On

Note: for people that manually set the that flag in cc, that if you change any of these things the use_sxl_urid value will reset itself.


We had some problems with long URLs and inefficiently written RegEx exception statements that gave similar warning messages, basically saying that they were going to skip the RegEx.  Those were slight different error messages, I would have to double-check what yours is.

Basically you can safely ignore it, or if you really don't like it I would have to investigate root cause of that message and look at your system.  My guess would be regex used in blacklist/whitelist.  This issue with regex is if you do something like http://.*\.site\.com  the .* will cause it to match anything (not just the domain name).

Michael,

Thank you, I'll look again at the black/white lists it is very possible I missed something. When I constructed the lasted version of regex I used a tool QuickRegex_1_1_19961.exe. This was noted by another member in a seperate post.

Thanks,
Jim

I did a little bit of asking around, actually in this case it isn't due to regex.  Its just an informational message for debugging that seems to have been left in there for some time.  AFAIK, no scanning is skipped.

IE has a limit of 2048 characters for a URL.  FF is a little longer.  Chrome has no limit and we've seen 3000+.

A few years ago when this message was added, ultra long URLs were almost never seen.  They are becoming more common, but there is no real need to log it.

Michael,

Thank you for the update. I think when you initially noted the regexs some of them did have errors in them. Noteably some of them turned up in the logs. Had you not highlighted them I would still be seeing some if the issues I encountered. Your guidence provided a path to effect the necessary changes.

Thanks,
Jim

Hi, 

Thank you for this thread as it explains how our 120 GB log partition is being filled up on a daily basis.  Does anyone know a command line we can use to stop this informational message, please? 

Our customer has high thousands of students being served by a box that is happily at 25% CPU during the busy hour (just breaking a sweat but nothing much).   300 GB 15K SAS hard drives, so bigger than average.  As a mature installation of 5 years, they have 146 exceptions for handling all sorts of things. 

Now, this PCRE advisory debugging message is generating at least 80 GB of logs per day.   

To put that 80 GB in context, this is enough to completely fill most if not all of the SSD drives on our new SG series boxes.    

Does anyone know a command line we can use to stop this મૂર્ખ נאַריש 愚蠢的 informational message, please?

We are upgrading but not before the students go on mid term leave.  

Thanks in advance

Adrien.

If I recall (not positive) it was been removed a few months ago.  Update to the latest.

There are two possibilities I can think of for an older system that cannot be updated.

If you are using transparent mode and it is a particular destination that always has this problem, try adding it to the skiplist.  You'll be skipping all the protection of the proxy for that site, however.

The only other thing would be to add a crontab that clears the logfile every hour. If you really need the normal logs, you can also run a tail on http.log, run it through grep -v to remove the bad lines, and log it to a different file.

But really, update to the latest build.

Adrien, that's the most entertaining મૂર્ખ נאַריש 愚蠢的 post I've ever seen here! [[[:D]]][[[:D]]][[[:D]]]

I'm with MD though - it's folly to not take the risk of Up2Dating now.

Cheers - Bob

Balfason & Mike,

Thankyou both for your replies.   All grist for the mill.  

There is a workaround but the Support engineer I talked to no longer had the information available.  The customer does not want to upgrade if at all possible during term time when an upgrade can (and often does) break functionality and affect students exam taking ability - causing related IT career failure if it does.   

They have a big installation that stresses the software more ways than most.   So little problems like the occasional PCRE message in a small company become a PCRE informational message "pack" of 80 lines consuming 170K every time this debug message is triggered.    Which is frequent enough in the 8 hours no one is in college to collect half a gig of logs already.  

So I was hoping that someone in this հրաշալի community might know this existing workaround for killing the informational logs - otherwise I may have to do the crontab trick you suggested Mike.  

Thanks as ever,   Adrien.

Gents and Ladies,

It turns out that any exception with a "*" in it was generating a PCRE log entry when a long URL was processed.  These long URLs are typically web ads - that seem to specialise in long URLs.  And also the exceptions were not being matched, they were just *all* being processes with complaint for each REGEX with a * in it for each long URL.   So four lines in an exception with * generate four 1-2000 byte log lines.  That multiplication will fill a log system double quick.  

So had to simplify all the exceptions to something in this format: astaro\.de/

So my Hotmail REGEXes go from being 

^https?://.*hotmail\.com/
^https?://.*hotmail\.co\.uk/
^https?://.*live\.com/
^https?://.*live\.co\.uk/

to

hotmail\.com/
hotmail\.co\.uk/
live\.com/
live\.co\.uk/

Which is not bad for matching but not perfect by a long shot.   Still now we have a sane logging system even if we cannot use Regex fully in exceptions.  

Thanks for your comments,

Adrien.