[Dshield] Has anyone seen this before?
jsage at finchhaven.com
Sat Mar 6 22:11:19 GMT 2004
On Sat, Mar 06, 2004 at 03:48:50PM -0500, Ernest Eustace wrote:
> From: Ernest Eustace <e.eustace at bringit.ca>
> To: "'John Sage '" <jsage at finchhaven.com>
> Cc: "'list at dshield.org'" <list at dshield.org>
> Subject: RE: [Dshield] Has anyone seen this before?
> Date: Sat, 6 Mar 2004 15:48:50 -0500
> Hello John,
> Thanks for your reply, the logs are from one of our Fortinet ASIC
> based A/V firewalls (www.fortinet.com / .ca for more info).
> The units produce several different logs, the entries from my
> original e-mail are from the antivirus log which keeps track of
> virus events and file blocking events, thus the message "such and
> such file is blocked".
> As noted in my previous e-mails we prevent all uploading/downloading
> on the user subnets and so these apparent .com files were caught
> trying to leave the network.
> I correlated the timing and src/dst with the seperate traffic logs
> just to be sure and confirmed that the destination is port 80, so
> yes the service=http refers to the destination.
> Also by comparing the complete traffic logs with just the A/V/File
> block logs I noticed that some of the systems that communicated with
> the 22.214.171.124 ip did not try to send out these files.
My gut feeling is that there are no files being sent out.
I'm thinking that (for whatever reason) your Fortinet AV firewall is
deciding to parse out of an otherwise inoffensive URL a fragement that
happens to contain *.com, and is interpreting that portion of the
domain name as representing a file with an executable extension.
The destination host 126.96.36.199 does have a web server up:
[jsage at sparky /storage] $ lynx -head -dump http://188.8.131.52/
HTTP/1.0 400 Bad Request
Expires: Sat, 06 Mar 2004 21:58:54 GMT
Date: Sat, 06 Mar 2004 21:58:54 GMT
and it appears to be one of those distributed content servers that
Akamai runs; this is entirely in keeping with the oldnavy.com and
weatherunderground.com URL's that would be part of an HTTP GET.
At this point all I can suggest is some detailed packet captures,
correlated with the AV logs, to see if the offending packets acutally
contain HTTP GET's...
/* snip */
"Mad cow? You'd be mad too, if someone was trying to eat you."
More information about the list