[Snort-users] msg update for these, please?

waldo kitty wkitty42 at ...14940...
Tue Sep 28 15:55:43 EDT 2010


On 9/28/2010 15:19, Alex Kirk wrote:
>>>      16425 looks at a packet coming "up" from the client -
>>
>>     yes, so the client is uploading a file... possibly a game or self-extracting
>>     binary to a file distribution channel like on the original BBS' where users
>>     uploaded and downloaded lottsa files all day long ;)
>
> No, it's not. It's sending a GET request to the server that has a URI which
> contains .exe. It's asking for a .exe file.

ahhh... my bad... i didn't/don't see a content:"GET "; depth:4; in there... i 
assume a GET is determined because it is http_uri?

(yes, i realize that the content i just used up there is "old style" but it is 
extremely clear in its intent ;) )

how would that rule appear if it were an actual executable upload to the 
"server"? i assume that would be a POST...

>>>       which will then trigger data coming back "down" from the server that you may
>>>       not want.
>>
>>     hunh? where do you see that in 1:16425? it would be the job of /other/ rules
>>     to detect that, wouldn't it? ;)
>
> You don't see that in 16425. It's implied, though, from the fact that the client
> has requested a .exe file that it's probably going to get such a file returned
> to it. While 15306 will generally alert on the file being returned, we have SID
> 16425 because some people want to drop outbound requests that have .exe in the URI.

i can understand that... i missed, somehow, that this was a GET request... i 
hope your answers to the above can clarify that for me...

that also means that my original post should have read like this...

OLD:
  15306   WEB-CLIENT Portable Executable binary file transfer
  16425   WEB-CLIENT Portable Executable binary file transfer

NEW:
  15306   WEB-CLIENT Portable Executable binary file transfer
  16425   WEB-CLIENT Executable binary file request

OR:
  15306   WEB-CLIENT Portable Executable binary file transfer to client
  16425   WEB-CLIENT Executable binary file request to server

this because .exe does not denote a PE .exe binary by default ;)

i wonder what a GET /foo/my.exe.sourcecode.pas would do with that rule? :P

maybe i need more c0ffee?

>     in any case, i really do think it best that the one to the client denotes
>     that and the one to the server denotes that as well... no matter what else
>     may happen after it gets where it is going :)  i do try to adhere to the
>     KISS principle and go with the most simple choice when i can instead of
>     over-engineering things ;) :P
>
>
>          > Duplicate messages are generally no fun, though, so how about making the
>             second
>          > one "WEB-CLIENT Portable Executable binary file transfer - .exe in URI"?
>
>             that might work but see above... ;)
>
>          > On Tue, Sep 28, 2010 at 1:48 PM, waldo kitty <wkitty42 at ...14940...
>         <mailto:wkitty42 at ...14940...>
>         <mailto:wkitty42 at ...14940... <mailto:wkitty42 at ...14940...>>
>          > <mailto:wkitty42 at ...14940... <mailto:wkitty42 at ...14940...>
>         <mailto:wkitty42 at ...14940... <mailto:wkitty42 at ...14940...>>>> wrote:
>          >
>          >
>          >     can we get a MSG update for these, please??
>          >
>          >     OLD:
>          >     15306   WEB-CLIENT Portable Executable binary file transfer
>          >     16425   WEB-CLIENT Portable Executable binary file transfer
>          >
>          >     NEW:
>          >     15306   WEB-CLIENT Portable Executable binary file transfer to client
>          >     16425   WEB-CLIENT Portable Executable binary file transfer to server
>          >
>          >     or some such?
>          >
>          >     thanks!




More information about the Snort-users mailing list