Advanced search  


CPG Release 1.6.26
Correct PHP8.2 issues with user and language managers.
Additional fixes for PHP 8.2
Correct PHP8 error with SMF 2.0 bridge.
Correct IPTC supplimental category parsing.
Download and info HERE

Pages: [1]   Go Down

Author Topic: Snort Generates error when User tries to login / view  (Read 5627 times)

0 Members and 1 Guest are viewing this topic.


  • Coppermine newbie
  • Offline Offline
  • Posts: 3
Snort Generates error when User tries to login / view
« on: June 16, 2004, 03:17:12 am »

I have installed CPG 1.3.0 on my custom Redhat 7.3 server, and I must say this is very nice, install went smooth, no problems setting up what so ever and am happily using it right now, all in all a very professional distro, well done.

The only problem I have is that I also have Snort and Guardian installed and now my acid logs are filling up with
NON-RFC HTTP DELIMITER .errors whenever CPG is accessed / logged into, the upshot of which is guardain blocks the offending IP, damn, no more photos for you.
Any suggestions, other than disabling guardian ?

Damn, sorry just realised this post is on the wrong board, can admin please move it to the support forum ?
« Last Edit: June 16, 2004, 03:32:21 am by DK1 »

Tarique Sani

  • VIP
  • Coppermine addict
  • ***
  • Offline Offline
  • Gender: Male
  • Posts: 2712
Re: Snort Generates error when User tries to login / view
« Reply #1 on: June 16, 2004, 04:40:12 am »

Can you give pointers to what each of these errors mean and possibly which part of the out put generates it?
SANIsoft PHP applications for E Biz


  • Coppermine newbie
  • Offline Offline
  • Posts: 3
Re: Snort Generates error when User tries to login / view
« Reply #2 on: June 20, 2004, 03:21:09 am »

Sorry about the no responding thing, I ddint get an update email so didnt know you had posted....

So after actually doing some research (Note - Next time do this bit first)
Here are the results

From :

Found that all these errors are generated by http inspect :-
HttpInspect is a generic HTTP decoder for user applications. Given a data buffer, HttpInspect will decode
the buffer, find HTTP fields, and normalize the fields. HttpInspect works on both client requests and
server responses.

So here are the errors, there desricption and matched with the http access log...

Bare byte encoding is an IIS trick that uses non-ASCII chars as valid values in decoding UTF-8 values.
This is NOT in the HTTP standard, as all non-ASCII values have to be encoded with a %. Bare byte encoding
allows the user to emulate an IIS server and interpret non-standard encodings correctly.
The alert on this decoding should be enabled, because there are no legitimate clients that encoded UTF-8 this way, since it is non-standard."

Acid log : - (http_inspect) BARE BYTE UNICODE ENCODING        2004-06-19 14:18:29
Httpd access log : - - - [19/Jun/2004:14:18:07 +1200] "GET /stilllife/upload.php
HTTP/1.1" 200 10068 "" "Mozilla/4.0
(compatible; MSIE 6.0; Windows NT 5.0)" - - [19/Jun/2004:14:20:16 +1200] "POST /stilllife/upload.php
HTTP/1.1" 200 7185 "" "Mozilla/4.0 (compatible;
MSIE 6.0; Windows NT 5.0)"
This option deals with non-RFC standard of tab for a space delimiter. Apache uses this, so if the
emulated web server is Apache you need to enable this option. Alerts on this option may be interesting,
but may also be false positive prone.

Acid log :- (http_inspect) APACHE WHITESPACE (TAB)        2004-06-19 14:18:33
Http access log : - - - [19/Jun/2004:14:18:07 +1200] "GET /stilllife/upload.php
HTTP/1.1" 200 10068 "" "Mozilla/4.0
(compatible; MSIE 6.0; Windows NT 5.0)" - - [19/Jun/2004:14:20:16 +1200] "POST /stilllife/upload.php HTTP/1.1" 200 7185 "" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)"
non_rfc_char { <byte> [<byte ...>] }
This option let's users receive an alert if certain non-RFC chars are used in a request URI. For
instance, a user may not want to see NULL bytes in the request-URI and we can give an alert on that.
Please use this option with care, because you could configure it to say, alert on all '/' or something
like that. It's flexible, so be careful.

Acid log :- (http_inspect) NON-RFC HTTP DELIMITER        2004-06-19 14:18:29
Http access log :- See above (Apache whitespace & Bare Byte errors for this time stamp)
double_decode <yes|no> The double_decode option is once again IIS specific and emulates IIS
functionality. How this works is that IIS does two passes through the request URI, doing decodes in each
one. In the first pass, it seems that all types of IIS encoding is done: UTF-8 unicode, ASCII, bare byte,
and %u. In the second pass the following encodings are done: ASCII, bare byte, and %u. We leave out UTF-8
because I think how this works is that the % encoded UTF-8 is decoded to the unicode byte in the first
pass, and then UTF-8 decoded in the second stage. Anyway, this is really complex and adds tons of
different encodings for one char. When double_decode is enabled, so is ascii to enforce correct decoding.

ACID Log :-[snort] (http_inspect) DOUBLE DECODING ATTACK        2004-06-19 22:15:51
Http access log :- - - [19/Jun/2004:22:15:51 +1200] "GET /stilllife/index.php
HTTP/1.1" 200 26678 "" "Mozilla/4.0
(compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 1.1.4322)" - - [19/Jun/2004:22:15:51 +1200] "GET /stilllife/albums/userpics/10003/thumb_1_multipart_xF8FF_3_silver%2520ww%25204wks5.jpg HTTP/1.1" 200 4019 "" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 1.1.4322)"
chunk_length <non-zero positive integer>
This option is an anomaly detector for abnormally large chunk sizes. This picks up the apache chunk
encoding exploits, and may also alert on HTTP tunneling that uses chunk encoding.

Acid log :- (http_inspect) OVERSIZE CHUNK ENCODING        2004-06-19 14:21:00    
Httpd Log :- - - [19/Jun/2004:14:21:00 +1200] "POST /stilllife/upload.php
HTTP/1.1" 200 6648 "" "Mozilla/4.0 (compatible;
MSIE 6.0; Windows NT 5.0)

So after all that im going to tune my snort install and remove the IIs allerters, but that still leaves the specific apache errors that appear to be being generated by uploading to an album.

Pages: [1]   Go Up

Page created in 0.022 seconds with 19 queries.