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 :
http://www.snort.org/docs/snort_manual/node17.html#SECTION003810000000000000000Found 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 UNICODE ENCODINGBare 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 : -
www.derivedsingularity.com 202.180.103.41 - - [19/Jun/2004:14:18:07 +1200] "GET /stilllife/upload.php
HTTP/1.1" 200 10068 "
http://www.derivedsingularity.com/stilllife/modifyalb.php?album=18" "Mozilla/4.0
(compatible; MSIE 6.0; Windows NT 5.0)"
www.derivedsingularity.com 202.180.103.41 - - [19/Jun/2004:14:20:16 +1200] "POST /stilllife/upload.php
HTTP/1.1" 200 7185 "
http://www.derivedsingularity.com/stilllife/upload.php" "Mozilla/4.0 (compatible;
MSIE 6.0; Windows NT 5.0)"
------------------------------
apache_whitespaceThis 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 : - www.derivedsingularity.com 202.180.103.41 - - [19/Jun/2004:14:18:07 +1200] "GET /stilllife/upload.php
HTTP/1.1" 200 10068 "
http://www.derivedsingularity.com/stilllife/modifyalb.php?album=18" "Mozilla/4.0
(compatible; MSIE 6.0; Windows NT 5.0)"
www.derivedsingularity.com 202.180.103.41 - - [19/Jun/2004:14:20:16 +1200] "POST /stilllife/upload.php HTTP/1.1" 200 7185 "
http://www.derivedsingularity.com/stilllife/upload.php" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)"
-----------------------------
NON-RFC HTTP DELIMITER 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 DECODING ATTACKdouble_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 :-www.derivedsingularity.com 210.54.97.213 - - [19/Jun/2004:22:15:51 +1200] "GET /stilllife/index.php
HTTP/1.1" 200 26678 "
http://www.derivedsingularity.com/stilllife/thumbnails.php?album=11" "Mozilla/4.0
(compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 1.1.4322)"
www.derivedsingularity.com 210.54.97.213 - - [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 "
http://www.derivedsingularity.com/stilllife/index.php" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 1.1.4322)"
-----------------------------
OVERSIZE CHUNK ENCODING 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 :- www.derivedsingularity.com 202.180.103.41 - - [19/Jun/2004:14:21:00 +1200] "POST /stilllife/upload.php
HTTP/1.1" 200 6648 "
http://www.derivedsingularity.com/stilllife/upload.php" "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.
Cheers