strange ip addresses in event analysis

[evan.chadwick1]

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?

[Jetsy Mathew]

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 

[evan.chadwick1]

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

[jwornstaff]

Did you ever find the cause of the strange/unknown source IPs? I am seeing this as well on a fairly closed network..no direct internet access. With source 0.0.0.0 as well as 8.0.0.0 and others causing the Bare Byte alerts to the random external IPs most of which either private range or showing to other countries.

Now, one thing I noticed is that the event from source 0.0.0.0 had packet data associated so when I looked at the frames, I could see a different source and destination which was our squid proxy server going out to another corporate proxy, which is normal approved traffic, then when I expanded and looked at the packet text data, I could see part of URL that referenced intelligence.sourcefire.com, so I disabled the feed retrieval for the security intelligence to see what would happen, and the alerts went away form 0.0.0.0....what the heck is causing firepower to display alert for 0.0.0.0 to a 160.246.xx. address in Japan, if the packet data says the source of our real internal proxy and real external proxy and to a cisco/source fire feed???

Now the other random unknown source address have no packet capture data, so I can't find or don't know what is cause them and they don't exist on our network and usually not complete address.