hi Santosh,
as I can see, the first rule (SingleWithScript) employs the 'event' action
for creating a synthetic event which apparently serves as an input for the
second rule. For creating a synthetic event, a prefix "Suppressed Alert"
will be added to the original input line. Unfortunately, this creates an
event loop, since the synthetic event contains all characters from original
event line, and will thus match the first rule (the one which created it).
The match will trigger another synthetic event which leads to another
match, etc. For resolving this issue, you can change 'event %s' action of
the first rule and replace %s with a different string (or edit the 'desc'
field of the first rule by replacing the $0 variable). Also, the pipe
symbol (|) is unnecessary for the 'pipe' action in the second rule, and
leaving it in place will result in a syntax error from shell.
The approach you are using might also lead to performance issues if you
have many incoming events which need to be matched against blacklists or
whitelists, since every such event will fork a new process. It is much more
efficient to keep blacklist or whitelist data as sec contexts. For example,
the following sample ruleset assumes that a hostname whitelist is stored in
a file whitelist.txt, and the whitelist is loaded when sec is started (or
HUP or ABRT signals are received):
# the name of this rulefile is test.sec
type=Single
ptype=RegExp
pattern=(?:SEC_STARTUP|SEC_RESTART|SEC_SOFTRESTART)
desc=load blacklist
action=delete WL; create WL; \
lcall %events -> ( sub { scalar `cat whitelist.txt` } ); \
cevent WHITELIST 0 %events
type=Single
ptype=RegExp
pattern=.
context=WHITELIST
desc=create a whitelist entry
action=alias WL WL_$0
type=Single
ptype=RegExp
pattern=event from host (\S+)
context=!WL_$1
desc=event from bad host $1
action=write - %s
When you start sec with the following commandline
sec --conf=test.sec --input=input.log --intevents --intcontexts
the first rule will load the whitelist of hostnames, so that whitelist
entries serve as aliases to a single context WL (this allows for dropping
the entire whitelist by just deleting one context with 'delete WL').
In order to create the aliases, the first rule generates relevant synthetic
events which are captured by the second rule, and the second rule invokes
the 'alias' action. In order to ensure that the second rule would match
proper events, an internal context WHITELIST is set by 'cevent' action, in
order to avoid accidental matches by similarly looking events from regular
input file. (Note that you could use the same technique for avoiding the
message loop in your original solution, since internal contexts allow for
distinguishing events by their source.)
The third rule will check if hostname is whitelisted by a context
expression evaluation which involves a simple hash table lookup. It
consumes *much* less resources that forking a process, especially if the
ruleset has to handle large event volumes. If you definitely want to have
external process around, I would recommend the following approach -- fork
it once when sec starts up with a cspawn action, and provide input data via
file system fifo to this process. Since the process has been started with
'cspawn' action, whatever line(s) it writes to standard output will be
received by sec as synthetic event(s).
Hope this helps,
risto
2018-07-10 9:52 GMT+03:00 S, Santosh <santos...@rakuten.com>:
> Hi Risto
>
>
>
> I recently come across this wonderful product and researching about its
> utilization on security events. Query on whitelisting or blacklisting. Need
> your inputs as I couldn’t find any topic specific to this. I’m suppressing
> security alerts based on its name and IP address. But looking for a best
> way to perform whitelist or blacklist specific attacks.
>
>
>
> Ideally the goal is to maintain a separate list of Attack Name’s, so the
> suppress rule will ignore or consider it as out of scope.
>
>
>
> Tried something like this but no luck. Can you please check and help me
> with the below scenario,
>
> ------------------------------------------------------------
> ------------------------------------------------------------
> ---------------
>
> # Suppress Duplicate Alerts Based on Attack Name and Source & Destination
> IP for 24hrs except SQLI
>
> type=SingleWithScript
>
> ptype=RegExp
>
> pattern=Attack Name.*([\w:\s\-\/]+).*dst":"([\d\.]+).*src":"([\d\.]+)
>
> script=/usr/bin/python /usr/bin/sec-rules/whitelist.py $1
>
> continue=takenext
>
> desc=Suppressed Alert $0
>
> action= logonly; event %s
>
>
>
> type=SingleWithSuppress
>
> ptype=regexp
>
> pattern=Suppressed Alert.*Attack Name.*([\w:\s\-\/]+).*dst":"([
> \d\.]+).*src":"([\d\.]+)
>
> continue=dontcont
>
> desc=[SEC][Critical]Suppressed $1 Security Alert towards $2
>
> action = logonly; pipe '$0' | nc test.com 80
>
> window = 86400
>
> ------------------------------------------------------------
> ------------------------------------------------------------
> ---------------
>
> whitelist.py
>
>
>
> #! /usr/bin/python
>
>
>
> import sys
>
> import urllib2
>
>
>
> IP = sys.argv[1]
>
> TI1 = [sql injection, xss attack, bruteforce attempt]
>
>
>
> if IP in TI1:
>
> sys.exit(1)
>
> else:
>
> sys.exit(0)
>
> ------------------------------------------------------------
> ------------------------------------------------------------
> ---------------------------------------
>
>
>
> Regards,
>
> Santosh.S
>
>
>
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Simple-evcorr-users mailing list
Simple-evcorr-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users
