[Snort-sigs] Proposed Sirefef (was Re: Late in the day...bet this could be sig'd)
wkitty42 at ...3507...
Mon May 6 17:58:31 EDT 2013
On 5/6/2013 17:18, Joel Esler wrote:
> On May 6, 2013, at 5:04 PM, waldo kitty <wkitty42 at ...3507...> wrote:
>> On 5/6/2013 13:37, Joel Esler wrote:
>>> Looking at what you are intending here, I think you mean it the other way
>>> (HOME_NET -> $EXTERNAL_NET)
>> ok... now i'm officially confused... the flow in the rule is
>> "from_server"... with that specified, does it really matter if HOME_NET or
>> EXTERNAL_NET come first?
>> then there's the situation of not only detecting this coming into a
>> network from an external server, but also of detecting this going out of a
>> network that runs servers feeding the public on the outside...
>> does the '->' really make any difference?
>> should it instead have been '<-' if the rule writer really wanted HOME_NET
>> to be first?
> There is no such thing as "<-".
i didn't think there was... because the flow would seem to indicate the
direction... the question then is how to denote an external server or an
internal one if using [to|from]_server...
> The way that Nathan wrote the rule above says we are looking for a URI to be
> returned from a server external to our network to a client that initiated the
> connection. This wouldn't work.
ahhhh! right right right... the URI buffer was that indicator... ok...
> Which is why I said we need to reverse it to look for HOME_NET ->
> $EXTERNAL_NET and "to_server" in the flow. That way we are alerting on
> someone making an outbound request for a file with the exe extension in the
> /wp-content/ directory on the server.
>> would using '<->' or '<>' (if either is allowed) detect the traffic no
>> matter which way the traffic was going (internal server to external client
>> or external server to internal client) no matter where the server is
> <> is allowed, but isn't very descriptive from an alert point of view.
this is true... it is one of the reasons why i brought up something similar in
the ET list... especially if one has both internal servers and internal clients
and one needs to determine where the violation resides... on the internal server
or an infested internal client...
> Plus, coupled with flow "to_server" you'd want to make sure that your msg was
> reflective of what you were trying to do in the rule.
i'll check it out! thanks :)
NOTE: No off-list assistance is given without prior approval.
Please keep mailing list traffic on the list unless
private contact is specifically requested and granted.
More information about the Snort-sigs