07-26-2016 07:28 PM
Hi,
Getting quite strange ip addresses in src and dst fields which are not part of the customers network, for eg. 0.0.0.0 as a source.
SOme more eg.
[119:4:1] http_inspect: BARE BYTE UNICODE ENCODING [Impact: Unknown] From "NAME" at Tue Jul 26 21:13:23 2016 UTC [Classification: Not Suspicious Traffic] [Priority: 3] {tcp} 1.0.0.0:51444 (australia)->1.0.0.0:3128 (australia)
and
[119:4:1] http_inspect: BARE BYTE UNICODE ENCODING [Impact: Unknown] From "NAME" at Tue Jul 26 21:13:23 2016 UTC [Classification: Not Suspicious Traffic] [Priority: 3] {tcp} 252.0.0.0:51444 (unknown)->20.0.0.0:3128 (united states)
Anyone else seen this?
07-27-2016 03:06 AM
Hello Evan,
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. In
summary, only IIS servers use this type of encoding, which is not an HTTP standard, and no
client connecting to the server should use this type of encoding.
If you want to leave the feature in place, but not see the large number of events, you can
disable the signature in question in your IPS policy and leave the functionality in place in the HTTP preprocessor for the Normalize UTF Encodings to UTF-8 option.
For now its priotity-3 which means it is not vulnerable.But you can suppress the events if you want. To check if its false positive or not we would need to check the captures for same.
Rate and mark correct if the post helps you
Regards
Jetsy
07-27-2016 01:39 PM
My question is not about the bare byte, I have read about that and happy to supress, i'm more questioning the ip address src and dst, both are not involving any of our ip address ranges at all.
I'm feeling its more of an ASA thing actually now. I might tighten my service policy that sends traffic to SFR and deal with the weird ip addresses at the ASA level.
Thanks