1sec.pl(1) General Commands Manual sec.pl(1)
2
6 sec.pl - simple event correlator
7
9 sec.pl [-conf=<file pattern> ...]
10 [-input=<file pattern>[=<context>] ...]
11 [-input_timeout=<input timeout>]
12 [-timeout_script=<timeout script>]
13 [-reopen_timeout=<reopen timeout>]
14 [-check_timeout=<check timeout>]
15 [-poll_timeout=<poll timeout>]
16 [-blocksize=<io block size>]
17 [-bufsize=<input buffer size>]
18 [-evstoresize=<event store size>]
19 [-cleantime=<clean time>]
20 [-log=<logfile>]
21 [-syslog=<facility>]
22 [-debug=<debuglevel>]
23 [-pid=<pidfile>]
24 [-dump=<dumpfile>]
25 [-quoting | -noquoting]
26 [-tail | -notail]
27 [-fromstart | -nofromstart]
28 [-detach | -nodetach]
29 [-intevents | -nointevents]
30 [-intcontexts | -nointcontexts]
31 [-testonly | -notestonly]
32 [-help] [-?]
33 [-version]
34
36 SEC is a tool that was designed for accomplishing various event corre‐
37 lation tasks in the domains of system monitoring, network and security
38 management, etc. Event correlation is a process where a stream of prim‐
39 itive events is processed in order to detect composite events that cor‐
40 respond to event patterns in the event stream.
41 After startup SEC reads lines from files, named pipes, or standard
43 input, matches the lines with patterns (regular expressions, Perl sub‐
44 routines, etc.) for recognizing input events, and correlates events
45 according to the rules in its configuration file(s). In order to
46 detect a composite event, rules are used sequentially in the same order
47 as they are given in the configuration file. If there are two or more
48 configuration files, rule sequences from different files are used vir‐
49 tually in parallel. SEC can be configured to produce its output by
50 executing user-specified shell commands, and by using utilities like
51 snmptrap(1) or snmpnotify(1), SEC can generate network management
52 events as output. Other options for producing output events are
53 described further in this man page.
54 Following rule types are currently implemented in SEC for detecting
56 composite events:
57 Single - match input event and execute an action immediately.
59 SingleWithScript - match input event and depending on the exit value of
61 an external script, execute an action.
62 SingleWithSuppress - match input event and execute an action immedi‐
64 ately, but ignore following matching events for the next t seconds.
65 Pair - match input event, execute an action immediately, and ignore
67 following matching events until some other input event arrives. On the
68 arrival of the second event execute another action.
69 PairWithWindow - match input event and wait for t seconds for other
71 input event to arrive. If that event is not observed within a given
72 time window, execute an action. If the event arrives on time, execute
73 another action.
74 SingleWithThreshold - count matching input events during t seconds and
76 if a given threshold is exceeded, execute an action and ignore all
77 matching events during the rest of the time window.
78 SingleWith2Thresholds - count matching input events during t1 seconds
80 and if a given threshold is exceeded, execute an action. Then start the
81 counting of matching events again and if their number per t2 seconds
82 drops below the second threshold, execute another action.
83 Suppress - suppress matching input events (used to keep the events from
85 being matched by later rules).
86 Calendar - execute an action at specific times.
88 If a rule defines the correlation of several events in a certain time
90 window, the rule will start an event correlation operation when the
91 first matching event occurs. In order to distinguish between different
92 event correlation operations that have been started by the rules, every
93 operation is assigned a unique key that is generated from the rule ID,
94 the name of the configuration file the rule belongs to, and the textual
95 description of the composite event that the correlation operation is
96 trying to detect (see RULES AND EVENT CORRELATION OPERATIONS section
97 for more information).
98 Rules support not only the execution of shell commands as actions, but
100 also the creation and deletion of contexts that decide whether a par‐
101 ticular rule can be applied at a given moment, the generation of syn‐
102 thetic events that will act as input for other rules, the clearing of
103 correlation operations that have been started by other rules, etc. This
104 makes it possible to combine several rules and form more complex event
105 correlation schemes. Contexts can not only be used for activating or
106 deactivating a particular rule, but they can also serve as event stores
107 (in logsurfer(1) the contexts are used in a similar way). There are
108 actions for adding events to a context, reporting all events associated
109 with a context, etc. By using the features of SEC in an appropriate
110 way, one can accomplish a wide range of event correlation and event
111 consolidation tasks.
112
114 -conf=<file pattern>
115 expand <file pattern> to filenames (with the Perl glob() func‐
116 tion) and read event correlation rules from every file. Multiple
117 -conf options can be specified at command line. Each time SEC
118 receives a signal that forces a configuration reload, <file pat‐
119 tern> is re-evaluated. See also TIMING AND IPC section for a
120 discussion about the rule processing order when multiple config‐
121 uration files are involved.
122 -input=<file pattern>[=<context>]
124 expand <file pattern> to filenames (with the Perl glob() func‐
125 tion) and use the files as event sources. An input file can be a
126 regular file, named pipe, or standard input if - was specified.
127 Multiple -input options can be specified at command line. Each
128 time SEC receives a signal that forces it to reopen its input
129 files, <file pattern> is re-evaluated. If SEC experiences a
130 system error when reading from an input file, it will close the
131 file (use the -reopen_timeout option for reopening the file). If
132 <context> is given, SEC will set up the context <context> each
133 time it reads a line from input files that correspond to <file
134 pattern>. This will help the user to write rules that match data
135 from particular input source(s) only. When there is an -input
136 option with <context> specified, it will automatically enable
137 the -intcontexts option. See TIMING AND IPC section for more
138 information.
139 -input_timeout=<input_timeout>, -timeout_script=<timeout_script>
141 if SEC has not observed new data in an input file during
142 <input_timeout> seconds (or the file was closed <input_timeout>
143 seconds ago), <timeout_script> will be executed with command
144 line parameters 1 and <the name of the input file>. If fresh
145 data become available again, <timeout_script> will be executed
146 with command line parameters 0 and <the name of the input file>.
147 -reopen_timeout=<reopen_timeout>
149 if an input file is in closed state (e.g., because SEC has
150 failed to open it at startup), SEC will attempt to reopen this
151 input file after every <reopen_timeout> seconds until open suc‐
152 ceeds.
153 -check_timeout=<check_timeout>
155 if SEC has not observed new data in an input file, SEC will not
156 poll the file (both for status and data) during the next
157 <check_timeout> seconds.
158 -poll_timeout=<poll_timeout>
160 a real number that specifies how many seconds SEC will sleep
161 when no new data were read from input files. Default is 0.1 sec‐
162 onds.
163 -blocksize=<io_block_size>
165 size of the block in bytes that SEC will attempt to read from
166 input files at once. Default is 1024 (i.e., read from input
167 files by 1KB blocks).
168 -bufsize=<input_buffer_size>
170 set input buffer to hold last <input_buffer_size> lines that
171 have been read from input files. The content of input buffer
172 will be compared with patterns that are part of rule definitions
173 (i.e., no more than <input_buffer_size> lines can be matched by
174 a pattern at a time). Default size is 10 lines.
175 -evstoresize=<event_store_size>
177 set an upper limit to the size of context event stores - if an
178 event store already contains <event_store_size> events, SEC will
179 add no more events to that context, regardless of its configura‐
180 tion file directives.
181 -cleantime=<clean_time>
183 time interval in seconds that specifies how often internal event
184 correlation and context lists are processed, in order to accom‐
185 plish time-related tasks and to remove obsolete elements.
186 Default is 1 second.
187 -log=<logfile>
189 use <logfile> for logging SEC activities. Note that if the SEC
190 standard error is connected to a terminal, messages will be
191 logged there, in order to facilitate debugging. If the -detach
192 option has also been specified, no logging to standard error
193 will take place.
194 -syslog=<facility>
196 use syslog for logging SEC activities. All messages will be
197 logged with the facility <facility>, e.g., local0 (see syslog(3)
198 for possible facility values). Warning: be careful with this
199 option if you use SEC for monitoring syslog logfiles, because it
200 might create message loops (SEC log messages are written to SEC
201 input files that trigger new log messages).
202 -debug=<debuglevel>
204 set logging verbosity for the SEC logfile. Setting debuglevel to
205 <debuglevel> means that all messages from <debuglevel> and lower
206 levels are logged (e.g., if <debuglevel> is 3, messages from
207 levels 1, 2, and 3 are logged). The following levels are recog‐
208 nized by SEC:
209 1 - critical messages (severe faults that cause SEC to termi‐
210 nate, e.g., a failed system call)
211 2 - error messages (faults that need attention but don't cause
212 SEC to terminate, e.g., an incorrect rule definition in a con‐
213 figuration file)
214 3 - warning messages (possible faults, e.g., a command forked
215 from SEC terminated with a non-zero exit code)
216 4 - notification messages (normal system level events and inter‐
217 rupts, e.g., the reception of a signal)
218 5 - informative messages (information about external commands
219 forked from SEC)
220 6 - debug messages (detailed information about all SEC activi‐
221 ties)
222 Default <debuglevel> is 6 (i.e., log everything).
223 -pid=<pidfile>
225 SEC will store its process ID to <pidfile> at startup.
226 -dump=<dumpfile>
228 SEC will use <dumpfile> as its dumpfile. See SIGNALS section for
229 more information. Default is /tmp/sec.dump.
230 -quoting, -noquoting
232 if the -quoting option is specified, event description strings
233 that are supplied to external shell commands of shellcmd and
234 spawn actions will be put inside apostrophes. All apostrophes '
235 that strings originally contain will be masked. This option pre‐
236 vents the shell from interpreting special symbols that event
237 description strings might contain. Default is -noquoting.
238 -tail, -notail
240 if the -notail option is specified, SEC will process all data
241 that are currently available in input files and exit after
242 reaching all EOFs. Default is -tail - SEC will jump to the end
243 of input files and wait for new lines to arrive. With the -tail
244 option, SEC follows an input file by its name (and not merely by
245 its i-node). If the input file is recreated or truncated, SEC
246 will reopen it and process its content from the start. If the
247 input file is removed (i.e., there is just an i-node left with‐
248 out name), SEC will keep the i-node open and wait for the input
249 file to be recreated.
250 -fromstart, -nofromstart
252 these flags have no meaning when the -notail option is also
253 specified. When used in combination with -tail (or alone, since
254 -tail is enabled by default), -fromstart will force SEC to read
255 and process input files from the beginning to the end, before
256 the 'tail' mode is entered at SEC startup. Default is -nofrom‐
257 start.
258 -detach, -nodetach
260 if the -detach option is specified, SEC will disassociate itself
261 from the controlling terminal and become a daemon at startup
262 (note that SEC will close its standard input, standard output,
263 and standard error, and change its working directory to the root
264 directory). Default is -nodetach.
265 -intevents, -nointevents
267 SEC will generate internal events when it starts up, when it
268 receives certain signals, and when it terminates normally. Spe‐
269 cific rules can be written to match those internal events, in
270 order to take some action at SEC startup, restart, and shutdown.
271 See TIMING AND IPC section for more information. Default is
272 -nointevents.
273 -intcontexts, -nointcontexts
275 SEC will create an internal context when it reads a line from an
276 input file. This will help the user to write rules that match
277 data from particular input source only. See TIMING AND IPC sec‐
278 tion for more information. Default is -nointcontexts.
279 -testonly, -notestonly
281 if the -testonly option is specified, SEC will exit immediately
282 after parsing the configuration file(s). If the configuration
283 file(s) contained no faulty rules, SEC will exit with 0, other‐
284 wise with 1. Default is -notestonly.
285 -help, -?
287 SEC will output usage information and exit.
288 -version
290 SEC will output version information and exit.
291 Note that one can introduce options both with a single dash (-) and
293 double dash (--), and also use both an equal sign (=) and whitespace as
294 a separator between the option name and the option value, e.g.,
295 -conf=<file pattern> and --conf <file pattern> are equivalent.
296
298 The SEC configuration file consists of rule definitions which are sepa‐
299 rated by empty and comment lines. Each rule definition is made up of
300 keyword=value pairs, one keyword and value per line. Values are case
301 sensitive only where character case is important (like the values spec‐
302 ifying regular expressions). \-symbol may be used at the end of a line
303 to continue the keyword=value pair on the next line. Lines which begin
304 with #-symbol are treated as comments and ignored (whitespace charac‐
305 ters may precede #-symbol). Any comment line, empty line, or end of the
306 file will terminate the preceding rule definition. In order to insert
307 comments into the rule definition, the rem keyword can be used.
308 Before describing each rule type in detail, patterns and pattern types,
310 context expressions, and action lists are discussed, since they are
311 important parts of the rule definition.
312 PATTERNS AND PATTERN TYPES
314 SEC supports the following pattern types (if <number> is omitted, 1 is
315 assumed):
316 SubStr[<number>]
318 pattern is assumed to be a substring that will be searched in
319 last <number> input lines L1, L2, ..., L<number>. The input
320 lines are joined into a single string with the newline character
321 acting as a separator, and the resulting string
322 "L1\nL2\n...\nL<number>" is searched for the substring. (Note
323 that if <number> is 1, the last input line without a terminating
324 newline is searched.) If the substring is found, the pattern
325 matches. The backslash constructs \t, \n, \r, \s, and \0 can be
326 used in the pattern to denote tabulation, newline, carriage
327 return, space character, and empty string, while \\ denotes
328 backslash itself. As an example, consider the following pattern
329 definition:
330 ptype=substr
332 pattern=Backup done:\tsuccess
333 The pattern matches lines containing "Backup done:<TAB>success".
335 RegExp[<number>]
337 pattern is assumed to be a regular expression that last <number>
338 input lines L1, L2, ..., L<number> are compared with. The input
339 lines are joined into a single string with the newline character
340 acting as a separator, and the resulting string
341 "L1\nL2\n...\nL<number>" is compared with the regular expression
342 pattern. (Note that if <number> is 1, the last input line with‐
343 out a terminating newline is compared with the pattern.) If the
344 pattern matches, backreference values will be assigned to the
345 special variables $1, $2, ..., and the special variable $0 will
346 be set to "L1\nL2\n...\nL<number>" (i.e., to the matching input
347 line(s)). These special variables can be used in some other
348 parts of the rule definition. All regular expression constructs
349 that Perl allows are allowed in the pattern (see perlre(1) for
350 more information). As an example, consider the following pattern
351 definition:
352 ptype=regexp
354 pattern=(?i)(\S+\.mydomain).*printer: toner\/ink low
355 The pattern matches "printer: toner/ink low" messages in a case
357 insensitive manner from printers belonging to .mydomain. Note
358 that the printer hostname is assigned to $1, while the whole
359 message line is assigned to $0. As another example, the follow‐
360 ing pattern definition
361 ptype=regexp2
363 pattern=^AAA\nBBB$
364 produces a match if the last two input lines are AAA and BBB,
366 and sets $0 to "AAA\nBBB".
367 PerlFunc[<number>]
369 pattern is assumed to be a Perl function that last <number>
370 input lines L1, L2, ..., L<number> are submitted to. The Perl
371 function is compiled at SEC startup by calling the Perl eval()
372 function, and eval() must return a code reference for the pat‐
373 tern to be valid (also see VARIABLES AND EVAL section for more
374 information). In order to check whether the pattern matches,
375 SEC will call the function in list context and pass lines L1,
376 L2, ..., L<number> and the names of corresponding input sources
377 S1, S2, ..., S<number> to the function as parameters:
378 function(L1, L2, ..., L<number>, S1, S2, ..., S<number>)
380 (if the input line has been generated with the event action, its
382 input source name will be set to 'undef'). If the function
383 returns several values or a single value that is TRUE in boolean
384 context, the pattern matches. If the pattern matches, return
385 values will be assigned to the special variables $1, $2, ...,
386 and the special variable $0 will be set to "L1\nL2\n...\nL<num‐
387 ber>" (i.e., to the matching input line(s)). These special vari‐
388 ables can be used in some other parts of the rule definition. As
389 an example, consider the following pattern definition:
390 ptype=perlfunc2
392 pattern=sub { return ($_[0] cmp $_[1]); }
393 The pattern compares last two input lines in a stringwise manner
395 ($_[1] holds the last line and $_[0] the preceding one), and
396 matches if the lines are different. Note that the result of the
397 comparison is assigned to $1, while the two input lines are con‐
398 catenated (with the newline character between them) and assigned
399 to $0. As another example, the following pattern definition
400 ptype=perlfunc
402 pattern=sub { if ($_[0] =~ /(abc|def)/) { \
403 return defined($_[1]) ? $_[1] : "SEC"; } return 0; }
404 produces a match if the input line contains either the string
406 "abc" or the string "def", and sets $0 to the matching line and
407 $1 to the name of the input source.
408 NSubStr[<number>]
410 like SubStr[<number>], except the result of the match is
411 negated.
412 NRegExp[<number>]
414 like RegExp[<number>], except the result of the match is
415 negated.
416 NPerlFunc[<number>]
418 like PerlFunc[<number>], except the result of the match is
419 negated.
420 TValue pattern is assumed to be a truth value with TRUE and FALSE being
422 legitimate values for the pattern. TRUE always matches an input
423 line while FALSE never matches an input line.
424 Note that since Pair and PairWithWindow rules have two pattern defini‐
426 tions, special variables $<number> set by the first pattern are shad‐
427 owed when the second pattern matches and sets the variables. In order
428 to access the shadowed variables, they must be referred to as %<number>
429 (e.g., instead of $1 one has to write %1). Also note that the second
430 pattern of Pair and PairWithWindow rules may contain $<number> vari‐
431 ables, if the second pattern is of type SubStr, NSubStr, Regexp, or
432 NRegExp. The variables are substituted at runtime with the values set
433 by the first pattern.
434 CONTEXT EXPRESSIONS
436 Context expression is a logical expression that consists of context
437 names, Perl miniprograms, and Perl functions as operands; operands are
438 combined with operators ! (logical NOT), && (short-circuit logical
439 AND), || (short-circuit logical OR), and parentheses. Context expres‐
440 sions are employed for activating or deactivating rules - normally, the
441 context expression is evaluated immediately after the pattern has
442 matched input line(s), and the rule will process the input line(s) only
443 if the expression evaluates TRUE.
444 If the operand contains the arrow (->), the text following the arrow is
446 considered to be a Perl function that will be compiled at SEC startup
447 by calling the Perl eval() function, and eval() must return a code ref‐
448 erence for the operand to be valid (also see VARIABLES AND EVAL section
449 for more information). If any text precedes the arrow, it is consid‐
450 ered to be the list of parameters for the function. Parameters are
451 separated by whitespace and may contain $<number> and %<number> special
452 variables. In order to evaluate the Perl function operand, the function
453 with its parameter list will be called in scalar context. If the return
454 value of the function is TRUE in boolean context, the truth value of
455 the operand is TRUE, otherwise its truth value is FALSE.
456 If the operand begins with the equal sign (=), the following text is
458 considered to be a Perl miniprogram. The miniprogram may contain $<num‐
459 ber> and %<number> special variables. In order to evaluate the Perl
460 miniprogram operand, it will be executed by calling the Perl eval()
461 function in scalar context (also see VARIABLES AND EVAL section for
462 more information). If the return value of the miniprogram is TRUE in
463 boolean context, the truth value of the operand is TRUE, otherwise its
464 truth value is FALSE.
465 Note that since Perl functions, miniprograms, and parameter lists may
467 contain strings that clash with the operators of the context expression
468 (e.g., '!'), it is strongly recommended to enclose them in parentheses,
469 e.g.,
470 ($1 $2) -> (sub { return ($_[0] != $_[1]); })
472 =({my($temp) = 0; return !$temp;})
474 If the operand is not a Perl function or program, it is considered to
476 be a context name. Context name may contain $<number> and %<number>
477 special variables. If the context name refers to an existing context,
478 the truth value of the operand is TRUE, otherwise its truth value is
479 FALSE.
480 If the whole context expression is enclosed in square brackets [ ],
482 e.g., [MYCONTEXT1 && !MYCONTEXT2], SEC evaluates the expression
483 _before_ pattern matching operation (normally the pattern is compared
484 with input line(s) first, so that $<number> and %<number> variables in
485 the context expression could be replaced with their values). Evaluating
486 context expression first could save CPU time when many of the input
487 lines are known to match the pattern but not the context expression,
488 and the expression does not contain any variables.
489 As an example, consider the following context expressions:
491 -> ( sub { my(@stat) = stat("/var/log/messages"); \
493 return (!scalar(@stat) || time() - $stat[9] > 3600); } )
494 ($1 $2) -> (sub { return ($_[0] != $_[1]); }) && C1
496 !(C1 || C2) && =("$1" eq "myhost.mydomain")
498 The first expression is TRUE when the /var/log/messages file does not
500 exist or was last modified more than 1 hour ago. The second expression
501 is TRUE when variables $1 and $2 are numerically not equal and the con‐
502 text C1 exists. The third expression is TRUE when contexts C1 and C2
503 do not exist and the $1 variable equals to the string "myhost.mydo‐
504 main". Note that since && is a short-circuiting operation, the Perl
505 code of the third expression is not evaluated if C1 and/or C2 exist.
506 ACTION LISTS
508 Action list consists of action definitions that are separated by semi‐
509 colons. Each action definition begins with a keyword specifying the
510 action type, followed by additional parameters. Additional parameters
511 that do not have a constant nature may contain $<number> and %<number>
512 special variables. Also, the following variables can be used in non-
513 constant parameters:
514 %s - event description string (set either by the desc or desc2 parame‐
516 ter of the rule definition).
517 %t - textual timestamp (as returned by date(1)).
518 %u - numeric timestamp (as returned by time(2)).
519 %<alnum_name> - user-defined variables that can be set at SEC runtime
520 with certain actions like assign and eval (<alnum_name> must begin with
521 a letter and may contain letters, digits, and underscores). In order to
522 disambiguate <alnum_name> from the following text, <alnum_name> must be
523 enclosed in braces: %{<alnum_name>}.
524 In order to use semicolons inside a non-constant action parameter, the
526 parameter must be enclosed in parentheses (the outermost set of paren‐
527 theses will be removed by SEC during configuration file parsing).
528 The following actions are supported:
530 none No action.
532 logonly [<event text>]
534 Event string <event text> is logged. If <event text> is omit‐
535 ted, %s is assumed for its value.
536 write <filename> [<event text>]
538 Event string <event text> and terminating newline are written to
539 the file <filename> (<filename> may not contain spaces). File
540 may be a regular file, named pipe, or standard output if - was
541 specified. If the file is a regular file, <event text> is
542 appended to the end of the file. If the file does not exist, it
543 is created as a regular file before writing. If <event text> is
544 omitted, %s is assumed for its value. Though write can also be
545 expressed through the shellcmd action, write does not involve
546 fork(2) like shellcmd does.
547 shellcmd <shellcmd>
549 Shell command <shellcmd> is executed. If the -quoting option was
550 specified, %s will be converted to '%s' before supplying it to
551 shell command (see the -quoting and -noquoting options).
552 spawn <shellcmd>
554 Identical to the shellcmd action, except the following - every
555 line from the standard output of <shellcmd> is treated like SEC
556 input line and matched against the rules. This is done by
557 applying event 0 <line> to every line from standard output (see
558 the event action). Note that if <shellcmd> outputs a large data
559 set at once, SEC will process it all at once, so if <shellcmd>
560 enters an endless "busy write" loop, it will block SEC from
561 doing anything other than processing its output.
562 pipe '<event text>' [<shellcmd>]
564 Event string <event text> and terminating newline are fed to the
565 standard input of shell command <shellcmd> (apostrophes are used
566 to mark the beginning and end of <event text>, in order to dis‐
567 tinguish it from <shellcmd>). If <event text> is omitted and
568 there is nothing between apostrophes, %s is assumed for <event
569 text>. If <shellcmd> is omitted, <event text> is written to
570 standard output.
571 create [<name> [<time> [<action list>] ] ]
573 Context with the name <name>, with the lifetime of <time> sec‐
574 onds, and with empty event store is created (<name> may not con‐
575 tain spaces, and <time> is an integer constant). If <name> is
576 omitted, %s is assumed for its value. Specifying 0 as <time> or
577 omitting the value means infinite lifetime. If <action list> is
578 specified, it will be executed when the context expires. If
579 <action list> is made up of more than one action, semicolons
580 must be used to separate the actions, and the list must be
581 enclosed in parentheses. If already existing context is recre‐
582 ated with create, its lifetime will be extended for <time> sec‐
583 onds and its event store will be emptied.
584 delete [<name>]
586 Context with the name <name> is deleted (<name> may not contain
587 spaces). If <name> is omitted, %s is assumed for its value. If
588 non-existing context is deleted, no operation will be performed.
589 obsolete [<name>]
591 Behaves like delete, except the action list of the context
592 <name> (if the context has an action list) will be executed
593 before deletion.
594 set <name> <time> [<action list>]
596 Settings for the context with the name <name> will be changed
597 (<name> may not contain spaces, and <time> is an integer con‐
598 stant). New lifetime of the context will be <time> seconds with
599 optional <action list> to be executed when the context expires.
600 Event store of the context will not be changed by set. Specify‐
601 ing 0 as <time> means infinite lifetime. If <action list> is
602 made up of more than one action, semicolons must be used to sep‐
603 arate the actions, and the list must be enclosed in parentheses.
604 alias <name> [<alias>]
606 An alias name <alias> will be created for the context with the
607 name <name> (<name> and <alias> may not contain spaces). After
608 the name <alias> has been created for a context, the context can
609 be referred to by using both <alias> and <name>. If <alias> is
610 omitted, %s is assumed for its value. If context with the name
611 <name> does not exist, or the name <alias> already exists, the
612 alias will not be created. Internally, SEC does not distinguish
613 in any way between <alias> and <name> - they are both pointers
614 to the same context data structure. Therefore, it makes no dif‐
615 ference whether context attributes (like lifetime, event store,
616 etc.) are changed by calling an action (e.g., set or add) for
617 <name> or <alias>. If the delete action is called for one of
618 the context names, the context data structure is destroyed, and
619 all context names (which are now pointers to unallocated memory)
620 are removed from the list of context names. Also note that if
621 the context expires, its action list is executed only once, no
622 matter how many names the context has.
623 unalias [<alias>]
625 Context name <alias> is removed from the list of context names,
626 so that the name <alias> can no longer be used to refer to the
627 context it was previously associated with (<alias> may not con‐
628 tain spaces). If <alias> is omitted, %s is assumed for its
629 value. If unalias is called for non-existing context name, no
630 operation will be performed. If the name <alias> was the last
631 reference to a context, the unalias action behaves like delete
632 and the context will be deleted; otherwise the context will con‐
633 tinue to exist under other name(s) with its event store and
634 other attributes intact.
635 add <name> [<event text>]
637 Event string <event text> is added to the event store of the
638 context <name> (<name> may not contain spaces). Events in the
639 store are ordered by the time they were added, and every add
640 appends event to the end of the store. If <event text> is omit‐
641 ted, %s is assumed for its value. If context <name> does not
642 exist, the context will be created with an infinite lifetime,
643 empty action list and empty event store (as with create <name>)
644 before adding the event. If <event text> contains newlines, it
645 will be split into parts using the newline symbol as a delim‐
646 iter, and each part is added to the event store as a separate
647 event string.
648 fill <name> [<event text>]
650 Behaves like add, except the event store of the context <name>
651 will be emptied before <event text> is added.
652 report <name> [<shellcmd>]
654 Event store of the context <name> is reported with shell command
655 <shellcmd> (<name> may not contain spaces). Reporting means that
656 events from the store are fed to standard input of <shellcmd> in
657 the order they were added into the store, every event on a sepa‐
658 rate line. If <shellcmd> is omitted, events from the store are
659 written to standard output.
660 copy <name> %<alnum_name>
662 Event store of the context <name> is assigned to a user-defined
663 variable %<alnum_name> (<name> may not contain spaces). Before
664 the assignment takes place, lines from the event store are
665 joined into a scalar using the newline character as the separa‐
666 tor (as with Perl join("\n", @array)).
667 empty <name> [%<alnum_name>]
669 Behaves like copy, except the event store of the context <name>
670 will be emptied after it has been assigned to the variable
671 %<alnum_name>. If %<alnum_name> is omitted, empty simply removes
672 all lines from the event store.
673 event [<time>] [<event text>]
675 After <time> seconds a synthetic event <event text> is created
676 (<time> is an integer constant). SEC treats the <event text>
677 string exactly like line(s) read from input - it is inserted
678 into the input buffer in order to compare it with rules. If
679 <event text> is omitted, %s is assumed for its value. Specify‐
680 ing 0 as <time> or omitting the value means now. If <event text>
681 contains newlines, it will be split into parts using the newline
682 symbol as a delimiter, and each part is created as a separate
683 synthetic event.
684 reset [<rule_number>] [<event text>]
686 Cancel event correlation operations that are currently detecting
687 the composite event <event text> (<rule_number> is a string con‐
688 stant), i.e., SEC will terminate event correlation operations
689 that have <event text> in their keys as event description string
690 (if such operations exist, see RULES AND EVENT CORRELATION OPER‐
691 ATIONS section for more information). If there are multiple
692 configuration files specified, reset can cancel only those cor‐
693 relation operations that have been started by the rules from the
694 same configuration file where the reset action itself is
695 defined. If <event text> is omitted, %s is assumed for its
696 value. Since correlation operations started by different rules
697 may detect composite events that have identical description
698 strings, rule number can be optionally specified to point to a
699 correlation operation that was started by a specific rule (1
700 means the first rule in the configuration file, 2 means the sec‐
701 ond, etc.; 0 denotes the current rule). If + or - is prepended
702 to <rule_number>, it is considered to be an offset from the cur‐
703 rent rule (e.g., -1 means the previous rule and +1 the next
704 rule). For example, if a rule definition with the reset action
705 is given in the configuration file named my.conf, then reset 1
706 Counting linkdown events will terminate the event correlation
707 operation with the key "my.conf | 0 | Counting linkdown events"
708 (note that internally the SEC rule IDs start from zero), while
709 reset Counting linkdown events will terminate event correlation
710 operations with keys "my.conf | X | Counting linkdown events",
711 where X runs from 0 to N-1 and N is the number of rules in the
712 configuration file my.conf. If no operation with a given key
713 exists, reset will take no action.
714 assign %<alnum_name> [<text>]
716 Text <text> is assigned to a user-defined variable
717 %<alnum_name>. If <text> is omitted, %s is assumed for its
718 value.
719 eval %<alnum_name> <code>
721 The parameter <code> is assumed to be a Perl miniprogram that
722 will be executed by calling the Perl eval() function in list
723 context. If the miniprogram returns a single value, it will be
724 assigned to the variable %<alnum_name>. If the miniprogram
725 returns several values, they will be joined into a scalar using
726 the newline character as a separator (as with Perl join("\n",
727 @array)), and the scalar will be assigned to the variable
728 %<alnum_name>. If no value is returned or eval() fails, no
729 assignment will take place. Note that before calling eval(),
730 $<number>, %<number>, and %<alnum_name> variables in the
731 miniprogram are replaced with their values and therefore can't
732 be used as lvalues. Since most Perl programs contain semicolons
733 which are also used by SEC as separators between actions, it is
734 recommended to enclose the <code> parameter in parentheses, in
735 order to avoid the inperpretation of semicolons inside the code
736 by SEC. Also see VARIABLES AND EVAL section for more informa‐
737 tion.
738 call %<alnum_name1> %<alnum_name2> [<parameter list>]
740 The parameter %<alnum_name2> is assumed to be a reference to a
741 Perl function that was created previously with the eval action.
742 The function will be called in list context by passing optional
743 parameter list to the function (parameters are separated by
744 whitespace). If the function returns a single value, it will be
745 assigned to the variable %<alnum_name1>. If the function returns
746 several values, they will be joined into a scalar using the new‐
747 line character as a separator (as with Perl join("\n", @array)),
748 and the scalar will be assigned to the variable %<alnum_name1>.
749 If no value is returned or %<alnum_name2> is not a code refer‐
750 ence, no assignment will take place. Also see VARIABLES AND
751 EVAL section for more information.
752 Examples:
754 spawn /bin/tail -f /var/log/trapd.log
756 Follow the /var/log/trapd.log file and feed to SEC input all lines that
758 are appended to the file.
759 pipe '%t: $0' /bin/mail -s "alert message" root@localhost
761 Mail the timestamp and the value of the $0 variable to the local root.
763 add ftp_$1 $0; set ftp_$1 1800 (report ftp_$1 /bin/mail root@localhost)
765 Add the value of the $0 variable to the event store of the context
767 ftp_<the value of $1>. Also extend the context's lifetime for 30 min‐
768 utes, so that when the context expires, its event store will be mailed
769 to the local root.
770 eval %funcptr ( sub { my(@buf) = split(/\n/, $_[0]); \
772 my(@ret) = grep(!/^#/, @buf); return @ret; } ); \
773 copy C1 %in; call %out %funcptr %in; fill C1 %out
774 Create a subroutine for weeding out comment lines from the input list,
776 and use this subroutine for removing comment lines from the event store
777 of the context C1.
778 OTHER ISSUES
780 As already noted, SEC context expressions and action lists may contain
781 parentheses which are used for grouping and masking purposes. When SEC
782 parses its configuration, it checks whether parentheses in context
783 expressions and action lists are balanced (i.e., whether each parenthe‐
784 sis has a counterpart), since unbalanced parentheses introduce ambigu‐
785 ity. This can cause SEC to reject some otherwise legitimate constructs,
786 e.g.,
787 action=eval %o (print ")";)
789 will be considered an invalid action list (however, note that
791 action=eval %o (print "()";)
793 would be passed by SEC, since now parentheses are balanced). In order
795 to avoid such unwanted behavior, each parenthesis without a counterpart
796 must be masked with a backslash (the backslash will be removed by SEC
797 during configuration file parsing), e.g.,
798 action=eval %o (print "\)";)
800 SINGLE RULE
802 The Single rule was designed for matching input events that require
803 immediate action to be taken. Its rule definition has the following
804 parameters:
805 type fixed to Single (value is case insensitive, so single or sIngLe
807 can be used instead).
808 continue (optional)
810 TakeNext or DontCont (values are case insensitive). The first
811 specifies that search for matching rules will continue after the
812 match (i.e., input line(s) that match pattern and context will
813 be passed to the next rule), the second will quit the search.
814 If continue keyword is missing from the rule definition, Dont‐
815 Cont is assumed.
816 ptype pattern type (value is case insensitive).
818 pattern
820 pattern.
821 context (optional)
823 context expression.
824 desc textual description of the detected event.
826 action action list that will be executed when the event is detected.
828 rem (optional, may appear more than once)
830 remarks and comments.
831 Note that context, desc, and action parameters may contain $<number>
833 variables.
834 Examples:
836 type=single
838 continue=takenext
839 ptype=regexp
840 pattern=ftpd\[(\d+)\]: \S+ \(ristov2.*FTP session opened
841 desc=ftp session opened for ristov2 pid $1
842 action=create ftp_$1
843 type=single
845 continue=takenext
846 ptype=regexp
847 pattern=ftpd\[(\d+)\]:
848 context=ftp_$1
849 desc=ftp session event for ristov2 pid $1
850 action=add ftp_$1 $0; set ftp_$1 1800 \
851 (report ftp_$1 /bin/mail root@localhost)
852 type=single
854 ptype=regexp
855 pattern=ftpd\[(\d+)\]: \S+ \(ristov2.*FTP session closed
856 desc=ftp session closed for ristov2 pid $1
857 action=report ftp_$1 /bin/mail root@localhost; \
858 delete ftp_$1
859 The first rule creates the context with the name ftp_<pid> when someone
861 connects from host ristov2 with ftp. The second rule adds all logfile
862 lines that are associated with the session <pid> to the event store of
863 the context ftp_<pid> (before adding a line, the rule checks if the
864 context exists). After adding a line, the rule extends context's life‐
865 time for 30 minutes and sets the action list that will be executed when
866 the context expires. The third rule mails collected logfile lines to
867 root@localhost when the session <pid> is closed. Collected lines will
868 also be mailed when the session <pid> has been inactive for 30 minutes
869 (no logfile lines observed for that session).
870 Note that the logfile line that has matched the first rule will be
872 passed to the second rule and will become the first line in the event
873 store (the first rule has the continue parameter set to TakeNext). The
874 second rule has also its continue parameter set to TakeNext, since oth‐
875 erwise no logfile lines would reach the third rule.
876 SINGLEWITHSCRIPT RULE
878 The SingleWithScript rule was designed to integrate external scripts
879 with the SEC event flow. Its rule definition is similar to the Single
880 rule, except of the additional script parameter:
881 type fixed to SingleWithScript (value is case insensitive).
883 continue (optional)
885 TakeNext or DontCont (values are case insensitive).
886 ptype pattern type (value is case insensitive).
888 pattern
890 pattern.
891 context (optional)
893 context expression.
894 script script that is executed after pattern and context have matched
896 some input line(s). The names of all existing contexts are fed
897 to the standard input of the script, a name per line. If the
898 script returns zero for its exit value, action will be executed;
899 if the script returns non-zero, action2 will be executed (if
900 given).
901 desc textual description of the detected event.
903 action action list that will be executed when script returns zero for
905 its exit value.
906 action2 (optional)
908 action list that will be executed when script returns non-zero
909 for its exit value.
910 rem (optional, may appear more than once)
912 remarks and comments.
913 Note that context, script, desc, action, and action2 parameters may
915 contain $<number> variables.
916 Also note that since the runtime of the script that is specified by the
918 script parameter is not limited in any way, waiting for that script to
919 complete could freeze the entire event processing for an indefinite
920 amount of time. Therefore, once the pattern and context parameters have
921 matched input line(s), SEC does not wait for the script to complete but
922 rather continues its work. The exit value of the script will be fetched
923 when the script actually terminates, and depending on the exit value,
924 either action or action2 (if it exists) will be executed.
925 Examples:
927 type=SingleWithScript
929 ptype=RegExp
930 pattern=interface (\S+) down
931 script=/usr/local/scripts/ping.sh $1
932 desc=Interface $1 down
933 action=shellcmd /usr/local/scripts/notify.sh "%s"
934 When "interface <ipaddress> down" line appears in input, this rule acts
936 by calling
937 /usr/local/scripts/ping.sh <ipaddress>
939 and if the script returns 0 as its exit value, the rule calls
941 /usr/local/scripts/notify.sh "Interface <ipaddress> down"
943 (note also that SEC feeds the names of all existing contexts to the
945 standard input of the /usr/local/scripts/ping.sh script.)
946 SINGLEWITHSUPPRESS RULE
948 The SingleWithSuppress rule was designed to implement the event corre‐
949 lation operation called compression, where multiple instances of event
950 A are reduced into a single event. Its rule definition is similar to
951 the Single rule, except of the additional window parameter:
952 type fixed to SingleWithSuppress (value is case insensitive).
954 continue (optional)
956 TakeNext or DontCont (values are case insensitive).
957 ptype pattern type (value is case insensitive).
959 pattern
961 pattern for detecting event A.
962 context (optional)
964 context expression.
965 desc textual description of event A.
967 action action list that will be executed when event A is first
969 observed. Following instances of event A will be ignored.
970 window time in seconds that following events A are ignored for.
972 rem (optional, may appear more than once)
974 remarks and comments.
975 Note that context, desc, and action parameters may contain $<number>
977 variables.
978 Examples:
980 type=SingleWithSuppress
982 ptype=RegExp
983 pattern=(\S+): [fF]ile system full
984 desc=File system $1 full
985 action=shellcmd notify.sh "%s"
986 window=900
987 When "/usr: file system full" line appears in input, this rule starts a
989 correlation operation that calls
990 notify.sh "File system /usr full"
992 and ignores following such lines during the next 15 minutes.
994 Note that line "/tmp: file system full" would not be ignored, since SEC
996 identifies correlation operations by a key that contains event descrip‐
997 tion string of the composite event (given by the desc parameter). Since
998 strings "/usr: file system full" and "/tmp: file system full" differ,
999 SEC will start another correlation operation for the latter (see RULES
1000 AND EVENT CORRELATION OPERATIONS section for more information).
1001 PAIR RULE
1003 The Pair rule was designed to implement one of the basic forms of the
1004 temporal relationship event correlation operation, where two or more
1005 events A and B are reduced into event pair (A, B) inside a given time
1006 window. Its rule definition has the following parameters:
1007 type fixed to Pair (value is case insensitive).
1009 continue (optional)
1011 TakeNext or DontCont (values are case insensitive). Specifies if
1012 input line(s) that match pattern and context will be passed to
1013 the next rule.
1014 ptype pattern type (value is case insensitive).
1016 pattern
1018 pattern for detecting event A.
1019 context (optional)
1021 context expression.
1022 desc textual description of event A.
1024 action action list that will be executed when event A is first
1026 observed. Following instances of event A will be ignored.
1027 continue2 (optional)
1029 TakeNext or DontCont (values are case insensitive). Specifies if
1030 input line(s) that match pattern2 and context2 will be passed to
1031 the next rule.
1032 ptype2 pattern type (value is case insensitive).
1034 pattern2
1036 pattern for detecting event B.
1037 context2 (optional)
1039 context expression.
1040 desc2 textual description of event B.
1042 action2
1044 action list that will be executed when event B is observed.
1045 After executing action2 the event correlation operation termi‐
1046 nates.
1047 window (optional)
1049 time t in seconds that is allowed to elapse between the first
1050 instance of event A and event B. If event B does not appear dur‐
1051 ing t seconds, then the correlation operation started by this
1052 rule terminates. Specifying 0 as value or omitting the window
1053 parameter means setting t to infinity (i.e., if event B does not
1054 appear, event A will be ignored forever).
1055 rem (optional, may appear more than once)
1057 remarks and comments.
1058 Note that context, desc, action, context2, desc2, and action2 parame‐
1060 ters may contain $<number> variables. The pattern2 parameter may con‐
1061 tain $<number> variables if ptype2 supports variable substitutions at
1062 runtime. If pattern2 shadows the $<number> variables of pattern, then
1063 context2, desc2, and action2 parameters may contain %<number> vari‐
1064 ables.
1065 Examples:
1067 type=Pair
1069 ptype=RegExp
1070 pattern=NFS server (\S+) not responding
1071 desc=$1 is not responding
1072 action=shellcmd notify.sh "%s"
1073 ptype2=substr
1074 pattern2=NFS server $1 ok
1075 desc2=$1 OK
1076 action2=shellcmd notify.sh "%s"
1077 window=3600
1078 When "NFS server fserv is not responding" line appears in input, the
1080 correlation operation started by this rule calls
1081 notify.sh "fserv is not responding"
1083 and waits for the line "NFS server fserv ok" for 1 hour, ignoring all
1085 "NFS server fserv is not responding" lines. When the line "NFS server
1086 fserv ok" appears, the correlation operation executes the shell command
1087 notify.sh "fserv OK"
1089 and terminates. If time (1 hour) runs out, the correlation operation
1091 will terminate without doing anything.
1092 PAIRWITHWINDOW RULE
1094 The PairWithWindow rule was designed to implement another variant of
1095 the temporal relationship event correlation operation that checks if
1096 event A will be followed by event B inside a given time window. Its
1097 rule definition has the following parameters:
1098 type fixed to PairWithWindow (value is case insensitive).
1100 continue (optional)
1102 TakeNext or DontCont (values are case insensitive). Specifies if
1103 input line(s) that match pattern and context will be passed to
1104 the next rule.
1105 ptype pattern type (value is case insensitive).
1107 pattern
1109 pattern for detecting event A.
1110 context (optional)
1112 context expression.
1113 desc textual description of event A.
1115 action action list that is executed after event A was observed and
1117 event B did not appear within the given time window.
1118 continue2 (optional)
1120 TakeNext or DontCont (values are case insensitive). Specifies if
1121 input line(s) that match pattern2 and context2 will be passed to
1122 the next rule.
1123 ptype2 pattern type (value is case insensitive).
1125 pattern2
1127 pattern for detecting event B.
1128 context2 (optional)
1130 context expression.
1131 desc2 textual description of event B.
1133 action2
1135 action list that is executed after event A was observed and
1136 event B appeared within the given time window. After executing
1137 action2 the event correlation operation terminates.
1138 window size of the time window in seconds.
1140 rem (optional, may appear more than once)
1142 remarks and comments.
1143 Note that context, desc, action, context2, desc2, and action2 parame‐
1145 ters may contain $<number> variables. The pattern2 parameter may con‐
1146 tain $<number> variables if ptype2 supports variable substitutions at
1147 runtime. If pattern2 shadows the $<number> variables of pattern, then
1148 context2, desc2, and action2 parameters may contain %<number> vari‐
1149 ables.
1150 Examples:
1152 type=PairWithWindow
1154 ptype=RegExp
1155 pattern=node (\S+) interface (\S+) down
1156 desc=$1 if $2 is down
1157 action=shellcmd notify.sh "%s"
1158 ptype2=SubStr
1159 pattern2=node $1 interface $2 up
1160 desc2=$1 if $2 short outage
1161 action2=event
1162 window=600
1163 When "node fserv interface 192.168.1.1 down" line appears in input,
1165 this rule starts a correlation operation that waits 10 minutes for
1166 "node fserv interface 192.168.1.1 up" line, and if that line does not
1167 arrive on time, the correlation operation executes the shell command
1168 notify.sh "fserv if 192.168.1.1 is down"
1170 and terminates. If the line arrives on time, the operation generates
1172 event "fserv if 192.168.1.1 short outage" and terminates.
1173 SINGLEWITHTHRESHOLD RULE
1175 The SingleWithThreshold rule was designed to implement the counting
1176 event correlation operation, where instances of event A are counted
1177 inside a given time window and the number of events is compared with a
1178 threshold value, in order to detect a composite event B. Its rule def‐
1179 inition has the following parameters:
1180 type fixed to SingleWithThreshold (value is case insensitive).
1182 continue (optional)
1184 TakeNext or DontCont (values are case insensitive).
1185 ptype pattern type (value is case insensitive).
1187 pattern
1189 pattern for detecting event A.
1190 context (optional)
1192 context expression.
1193 desc textual description of event B.
1195 action action list that is executed when thresh instances of event A
1197 have been observed within the given time window. After that all
1198 events A will be ignored during the rest of the time window.
1199 action2 (optional)
1201 action list that is executed when the event correlation opera‐
1202 tion terminates, if action has been previously executed by the
1203 operation.
1204 window size of the time window in seconds. The window is sliding - if
1206 event A has been observed less than thresh times at the end of
1207 the window, the beginning of the window is moved to the occur‐
1208 rence time of the second instance of event A, and the counting
1209 operation will continue. If there is no second instance of
1210 event A (i.e., the event has been observed only once), the cor‐
1211 relation operation will terminate.
1212 thresh threshold value.
1214 rem (optional, may appear more than once)
1216 remarks and comments.
1217 Note that context, desc, and action parameters may contain $<number>
1219 variables.
1220 Examples:
1222 type=SingleWithThreshold
1224 ptype=RegExp
1225 pattern=user (\S+) login failure on (\S+)
1226 desc=Repeated login failures for user $1 on $2
1227 action=shellcmd notify.sh "%s"
1228 window=60
1229 thresh=3
1230 When line "user dbadmin login failure on tty1" is observed, the rule
1232 starts a correlation operation that executes the shell command
1233 notify.sh "Repeated login failures for user dbadmin on tty1"
1235 if additional two such lines are observed within 1 minute. Following
1237 "user dbadmin login failure on tty1" lines will be ignored by this rule
1238 until 60 seconds have elapsed since the arrival of first line.
1239 After changing the action parameter in the rule definition to
1241 action=shellcmd notify.sh "%s"; reset 0 %s
1243 the correlation operation will terminate itself after calling
1245 notify.sh, and the next matching line will start a new counting opera‐
1246 tion.
1247 SINGLEWITH2THRESHOLDS RULE
1249 The SingleWith2Thresholds rule was designed to implement another vari‐
1250 ant of the counting event correlation operation, where instances of
1251 event A are counted twice - first for checking if the threshold value
1252 is exceeded (in order to detect a composite event B), and then for
1253 checking if the number of instances will stay below the second thresh‐
1254 old value (in order to detect a composite event C). Its rule defini‐
1255 tion has the following parameters:
1256 type fixed to SingleWith2Thresholds (value is case insensitive).
1258 continue (optional)
1260 TakeNext or DontCont (values are case insensitive).
1261 ptype pattern type (value is case insensitive).
1263 pattern
1265 pattern for detecting event A.
1266 context (optional)
1268 context expression.
1269 desc textual description of event B.
1271 action action list that is executed when thresh instances of event A
1273 have been observed within the time window window. After that
1274 event counting continues with the threshold value thresh2 and
1275 time window window2.
1276 window size of the first time window in seconds. The window is sliding.
1278 thresh the first threshold value.
1280 desc2 textual description of event C.
1282 action2
1284 action list that is executed if no more than thresh2 instances
1285 of event A have been observed during the last window2 seconds.
1286 After executing action2 the event correlation operation termi‐
1287 nates.
1288 window2
1290 size of the second time window in seconds. The window is slid‐
1291 ing.
1292 thresh2
1294 the second threshold value.
1295 rem (optional, may appear more than once)
1297 remarks and comments.
1298 Note that context, desc, action, desc2, and action2 parameters may con‐
1300 tain $<number> variables.
1301 Examples:
1303 type=SingleWith2Thresholds
1305 ptype=RegExp
1306 pattern=(\S+): %SYS-3-CPUHOG
1307 desc=router $1 CPU overload
1308 action=shellcmd notify.sh "%s"
1309 window=300
1310 thresh=2
1311 desc2=router $1 CPU load normal
1312 action2=shellcmd notify.sh "%s"
1313 window2=3600
1314 thresh2=0
1315 When SYS-3-CPUHOG syslog message is received from a router, the rule
1317 starts a counting operation that executes the shell command
1318 notify.sh "router <routername> CPU overload"
1320 if additional SYS-3-CPUHOG syslog message is received from the router
1322 within 5 minutes. After that the correlation operation waits until no
1323 SYS-3-CPUHOG syslog messages have been received from the router during
1324 the last 1 hour, and then executes
1325 notify.sh "router <routername> CPU load normal"
1327 SUPPRESS RULE
1329 The Suppress rule was designed to implement event suppression and fil‐
1330 tering, where event A is suppressed or filtered out if certain context
1331 is present or if the event parameters match the pattern specified. Its
1332 rule definition has the following parameters:
1333 type fixed to Suppress (value is case insensitive).
1335 ptype pattern type (value is case insensitive).
1337 pattern
1339 pattern for detecting event A (or its subclass) that must be
1340 suppressed (or filtered out).
1341 context (optional)
1343 context expression.
1344 desc (optional)
1346 textual description of this rule.
1347 rem (optional, may appear more than once)
1349 remarks and comments.
1350 Note that the context parameter may contain $<number> variables.
1352 Examples:
1354 type=Suppress
1356 ptype=RegExp
1357 pattern=[Ff]ile system full
1358 context=mycontext
1359 type=Suppress
1361 ptype=RegExp
1362 pattern=/dev/vg01/\S+: [Ff]ile system full
1363 The first rule suppresses all "file system full" events if the context
1365 mycontext is present. The second rule filters out all "file system
1366 full" events that concern the volume group vg01.
1367 CALENDAR RULE
1369 The Calendar rule was designed for executing actions at specific times.
1370 Unlike all other rules, this rule reacts only to the system clock,
1371 ignoring other input. Its rule definition has the following parameters:
1372 type fixed to Calendar (value is case insensitive).
1374 time crontab-style time specification (see crontab(1) for more infor‐
1376 mation). Time specification consists of five fields separated by
1377 whitespace characters. First field denotes minutes (allowed val‐
1378 ues 0-59), second field hours (allowed values 0-23), third field
1379 days (allowed values 0-31, 0 denotes the last day of the month),
1380 fourth field months (allowed values 1-12), and fifth field week‐
1381 days (allowed values 0-7, 0 and 7 denote Sunday). Asterisks (*),
1382 ranges of numbers (e.g., 8-11), and lists (e.g., 2,5,7-9) are
1383 allowed as field values.
1384 context (optional)
1386 context expression.
1387 desc event description string.
1389 action action list to be executed.
1391 rem (optional, may appear more than once)
1393 remarks and comments.
1394 Examples:
1396 type=Calendar
1398 time=0 23 * * *
1399 desc=NightContext
1400 action=create %s 32400
1401 This rule creates the context NightContext every day at 11PM. Context
1403 has a lifetime of 9 hours.
1404
1406 Although each event correlation operation is started by a SEC rule,
1407 there is no one-to-one relationship between rules and event correlation
1408 operations, since one rule could start several event correlation opera‐
1409 tions that run simultaneously. In order to distinguish one event corre‐
1410 lation operation from another, SEC assigns a key to every operation
1411 that is composed from the rule file name, the rule ID, and the event
1412 description string that is derived from the desc parameter of the rule
1413 definition (by replacing variables with their values).
1414 Suppose you have a configuration file my.conf with one rule in it:
1416 type=SingleWithThreshold
1418 ptype=RegExp
1419 pattern=user (\S+) login failure on (\S+)
1420 desc=Repeated login failures for user $1 on $2
1421 action=shellcmd notify.sh "%s"
1422 window=60
1423 thresh=3
1424 Suppose that SEC observes an input line "user admin login failure on
1426 tty1". This matches the pattern 'user (\S+) login failure on (\S+)',
1427 and after replacing $1 and $2 with their values, the desc parameter
1428 will yield "Repeated login failures for user admin on tty1". SEC will
1429 then form a key for the event correlation operation, using the configu‐
1430 ration file name, the rule ID, and the event description string:
1431 my.conf | 0 | Repeated login failures for user admin on tty1
1433 Since the rule was the first one in the configuration file, its ID is
1435 0. The ID for the second rule would be 1, for the third rule 2, etc.
1436 Note that because the configuration file name and the rule ID are
1437 present in the keys, event correlation operations started by different
1438 rules will not clash, even if the rules have identical values for the
1439 desc parameter.
1440 After calculating the key, SEC will check if there already is an event
1442 correlation operation with that key. If such operation exists, the
1443 input line will be correlated by the existing operation. Otherwise, a
1444 new event correlation operation will be started.
1445 By using appropriate event description string definitions, you can
1447 change the scope of individual event correlation operations. For
1448 instance, if you use "Repeated login failures for user $1" for the desc
1449 parameter in the above rule definition, the following three lines will
1450 now be correlated by the same event correlation operation:
1451 user admin login failure on tty1
1453 user admin login failure on tty5
1454 user admin login failure on tty2
1455 In other words, SEC will now just count login failures for different
1457 users, disregarding terminal names.
1458 Finally, it should be noted that Single, SingleWithScript, Suppress,
1460 and Calendar rules never start event correlation operations, since they
1461 don't involve the matching of several events over a certain time window
1462 (i.e., their design allows them to complete their work almost immedi‐
1463 ately without starting an event correlation operation). Therefore, the
1464 desc parameter of these rules does not influence the number and the
1465 scope of event correlation operations.
1466
1468 There are several kinds of events that SEC reacts to - changes in input
1469 files (e.g., appearance of new data), reception of a signal, status
1470 change of a child process, and time related events (e.g., context expi‐
1471 ration).
1472 When new data appear in SEC input files, only one line will be read at
1474 a time (even when more lines are available), after which the input buf‐
1475 fer is updated with the line that was read. Input buffer contains the
1476 last N lines from the SEC input, in the order they were read (the value
1477 of N can be set with the -bufsize option). Updating the input buffer
1478 means that the last element (the oldest line) is removed from the end
1479 of the buffer, while the new line becomes the first element of the buf‐
1480 fer. Note that when synthetic events have been created with the event
1481 action and new input data are also available in input files, synthetic
1482 events are always read first by SEC. After no more such events are
1483 available for reading, SEC will read new data from input files.
1484 After the buffer has been updated (every update always adds only one
1486 and removes only one line), the rules from configuration files are pro‐
1487 cessed, matching the rules against the new content of the input buffer.
1488 Even when a rule matches and its action list suggests an immediate
1489 change in the buffer (e.g., through the event action), the input buffer
1490 will _not_ be updated until all the rules have been compared with the
1491 current content of the buffer.
1492 Rules from the same configuration file are compared with the input buf‐
1494 fer in the order they were given in that file. When multiple configu‐
1495 ration files have been specified, each file containing a distinct rule‐
1496 set, events are processed virtually in parallel - the buffer is always
1497 processed by all rulesets. However, the order the rulesets are applied
1498 during event processing is determined by the order the files were given
1499 at SEC command line. If a -conf option specifies a pattern, SEC uses
1500 the Perl glob() function to expand the pattern, and the resulting file
1501 list is applied by SEC in the order returned by glob() (this is usually
1502 ascending ASCII order). E.g., if you have specified -conf options in
1503 the following order:
1504 -conf=/home/risto/*.conf -conf=/home/risto/*.conf2
1506 and directory /home/risto contains files A.conf, B.conf2, and C.conf,
1508 then SEC applies these ruleset files in the following order: A.conf,
1509 C.conf, and B.conf2. Also, note that even if A.conf contains a Suppress
1510 rule for a particular event, the event is still processed by rulesets
1511 in C.conf and B.conf2.
1512 After the input buffer has been updated and its content has been pro‐
1514 cessed by the rules, SEC handles the signals that have been received
1515 since the last check, and also reads possible output from its child
1516 processes.
1517 When the timeout specified with the -cleantime option has expired, SEC
1519 also checks the contexts and the event correlation operations that have
1520 timers associated with them (e.g., SingleWithSuppress and PairWithWin‐
1521 dow rules). This means that the value of -cleantime should be rela‐
1522 tively small, in order to keep the event correlation operations accu‐
1523 rate. By setting the -cleantime option value to 0, SEC will check the
1524 event correlation timers after reading every line, but this will con‐
1525 sume more CPU time. The higher the value, the less CPU time will be
1526 consumed, so the value of the -cleantime option depends on your
1527 requirements. Note that if the -poll_timeout option value exceeds the
1528 value given with -cleantime, the -poll_timeout option value takes
1529 precedence (i.e., sleeps after unsuccessful polls will not be short‐
1530 ened).
1531 If the -intevents command line option is given, SEC will generate
1533 internal events when it is started up, when it receives certain sig‐
1534 nals, and when it terminates normally. Inside SEC, internal event is
1535 treated as if it was a line that was read from a SEC input file. Spe‐
1536 cific rules can be written to match internal events, in order to take
1537 some action (e.g., start an external event correlation module with
1538 spawn when SEC starts up). The following internal events are supported:
1539 SEC_STARTUP - generated when SEC is started (once the -intevents option
1541 has been given, this event will always be the first event that SEC
1542 observes)
1543 SEC_RESTART - generated after SEC has received the SIGHUP signal and
1545 all internal data structures have been cleared (this event will be the
1546 first event that SEC observes after reloading its configuration)
1547 SEC_SOFTRESTART - generated after SEC has received the SIGABRT signal
1549 (this event will be the first event that SEC observes after reloading
1550 its configuration)
1551 SEC_SHUTDOWN - generated when SEC receives the SIGTERM signal, or when
1553 SEC reaches all EOFs of input files after being started with the
1554 -notail option. After generating SEC_SHUTDOWN event, SEC will sleep for
1555 3 seconds before sending SIGTERM to its child processes (if there are
1556 any child processes that were started by SEC_SHUTDOWN, the processes
1557 will have enough time to set a signal handler for SIGTERM if needed).
1558 Right before generating an internal event, SEC will also set up a con‐
1560 text named SEC_INTERNAL_EVENT, in order to distinguish between true
1561 internal events and coincidents that look like internal events. The
1562 SEC_INTERNAL_EVENT context will be deleted immediately after the inter‐
1563 nal event has been processed by all rules.
1564 If the -intcontexts command line option is given, or there is an -input
1566 option with a context specified, SEC will create an internal context
1567 each time a line is read from an input file, or a line is read that was
1568 created with the event action. The internal context will be deleted
1569 immediately after the line has been matched against all rules. For all
1570 input files that have the context name explicitly set with -input=<file
1571 pattern>=<context>, the name of the internal context is <context>. If
1572 the line was read from the input file <filename> for which there is no
1573 context name set, the name of the internal context is
1574 _FILE_EVENT_<filename>. If the line was created with the event action,
1575 the name of the internal context is _INTERNAL_EVENT. This will help the
1576 end user to write rules that will match data from one particular input
1577 source only, e.g., the rule
1578 type=Suppress
1580 ptype=TValue
1581 pattern=TRUE
1582 context=[!_FILE_EVENT_/dev/logpipe]
1583 will pass to the following rules only those lines that were read from
1585 /dev/logpipe.
1586 The shellcmd, spawn, pipe, and report actions involve the creation of a
1588 child process. The communication between SEC and its child processes
1589 takes place through pipes (created with Perl pipe opens like open(FH,
1590 "| mycommand") or pipe(2) system call). Note that the running time of
1591 children is not limited in any way, so long-running processes can be
1592 started from SEC. For instance, one could start a SEC agent with the
1593 spawn action that runs forever and provides SEC with additional input
1594 events. However, note that SEC sends the SIGTERM signal to all its
1595 children before termination. If some special exit procedures need to
1596 be carried out in the child process (or the child wishes to ignore
1597 SIGTERM), then the child must install a handler for the SIGTERM signal.
1598 Note that if a rule definition includes two shellcmd actions (or other
1600 actions that call external scripts or programs), the order that these
1601 scripts or programs are executed is not determined. For instance, with
1602 the following action definition
1603 action=shellcmd cmd1; shellcmd cmd2
1605 cmd2 could well terminate before cmd1, or cmd2 could well start before
1607 cmd1 (e.g., when cmd1 is a complex command line and cmd2 is relatively
1608 simple, it takes more time from the shell to process and start cmd1
1609 than cmd2).
1610
1612 There are two kinds of variables that can be used in SEC rule defini‐
1613 tions - $<number> and %<number> variables that are set during pattern
1614 matching, and %<alnum_name> variables (like %s, %t, and %u) that have
1615 been designed for use in action lists. All $<number> and %<number>
1616 variables will be substituted with their values immediately after input
1617 line(s) have matched the rule, even when they are part of the action
1618 list definition and this action list is going to be executed at a later
1619 time. %<alnum_name> variables, in turn, will be substituted with their
1620 values right before the action list is actually executed. If a vari‐
1621 able does not have a value (e.g., $4 when the pattern returned just two
1622 values), it will be left intact, i.e., it is not replaced with an empty
1623 string.
1624 In order to mask the variables, an extra $ or % must be prepended to
1626 them, e.g., $$1 yields $1, and not a dollar sign followed by the first
1627 value returned by the pattern. Also, all occurrences of $$ will be con‐
1628 verted to $ when $<number> variables are substituted, and all occur‐
1629 rences of %% will be converted to % when %<number> or %<alnum_name>
1630 variables are substituted, so that one could use $ or % together with
1631 variable names (e.g., $$$1 will yield a dollar sign that is followed by
1632 the first value returned by the pattern).
1633 Please note the following caveat for Pair and PairWithWindow rules when
1635 the second pattern shadows the $<number> variables of the first pattern
1636 - since both %<number> and %<alnum_name> variables may be used in the
1637 second action list and %<number> variables are substituted first (at
1638 the moment when the first pattern matches input line(s) and the event
1639 correlation operation is started), all occurrences of %% in the second
1640 action list have already been replaced with a single percent sign by
1641 the time when %<alnum_name> variables are finally substituted. (E.g.,
1642 in order to express %%t in the second action list, one must actually
1643 write it as %%%%t or %%%t, since after %% to % conversion they both
1644 yield %%t.)
1645 SEC allows the user to define patterns, context expressions, and
1647 actions which involve calls to the Perl eval() function. In addition to
1648 explicitly using %<alnum_name> variables that are global across the
1649 rules, the user can implicitly employ Perl variables created with
1650 eval() for the same purpose. E.g., when SEC has executed the following
1651 action
1652 action=eval %a ($b = 1)
1654 the variable $b and its value will become visible in the following con‐
1656 text expression
1657 context= =(++$b > 10)
1659 (with that expression one can implement event counting implicitly). In
1661 order to avoid possible clashes with the variables inside the SEC code
1662 itself, all calls for eval() are made in the main::SEC namespace (i.e.,
1663 inside the special package main::SEC). This still leaves the user with
1664 an opportunity to set the variables within the SEC code (e.g., by using
1665 the main:: prefix), and thus to alter the behavior of SEC, but this is
1666 only recommended for advanced users who have studied the code thor‐
1667 oughly and know what they are doing.
1668
1670 Example 1
1671 Consider the following rules:
1672 type=single
1674 continue=takenext
1675 ptype=regexp
1676 pattern=ftpd\[(\d+)\]: \S+ \(ristov2.*FTP session opened
1677 desc=ftp session opened for ristov2 pid $1
1678 action=create ftp_$1
1679 type=single
1681 continue=takenext
1682 ptype=regexp
1683 pattern=ftpd\[(\d+)\]:
1684 context=ftp_$1
1685 desc=ftp session event for ristov2 pid $1
1686 action=add ftp_$1 $0; set ftp_$1 1800 \
1687 (report ftp_$1 /bin/mail root@localhost)
1688 type=single
1690 ptype=regexp
1691 pattern=ftpd\[(\d+)\]: \S+ \(ristov2.*FTP session closed
1692 desc=ftp session closed for ristov2 pid $1
1693 action=report ftp_$1 /bin/mail root@localhost; \
1694 delete ftp_$1
1695 The first rule creates the context with the name ftp_<pid> when someone
1697 connects from host ristov2 with ftp. The second rule adds all logfile
1698 lines that are associated with the session <pid> to the event store of
1699 the context ftp_<pid> (before adding a line, the rule checks if the
1700 context exists). After adding a line, the rule extends context's life‐
1701 time for 30 minutes and sets the action list that will be executed when
1702 the context expires. The third rule mails collected logfile lines to
1703 root@localhost when the session <pid> is closed. Collected lines will
1704 also be mailed when the session <pid> has been inactive for 30 minutes
1705 (no logfile lines observed for that session).
1706 Note that the logfile line that has matched the first rule will be
1708 passed to the second rule and will become the first line in the event
1709 store (the first rule has the continue parameter set to TakeNext). The
1710 second rule has also its continue parameter set to TakeNext, since oth‐
1711 erwise no logfile lines would reach the third rule.
1712 Example 2
1714 Suppose there is a backup job in your system that runs at 2AM every
1715 night and logs "BACKUP READY" message when it has completed its work.
1716 You want to send an SNMP trap if there is no message in the log by
1717 2:15AM.
1718 type=Calendar
1720 time=59 1 * * *
1721 desc=WAITING FOR BACKUP
1722 action=event %s
1723 type=PairWithWindow
1725 ptype=SubStr
1726 pattern=WAITING FOR BACKUP
1727 desc=Backup not ready!
1728 action=shellcmd sendtrap.sh "%s"
1729 ptype2=SubStr
1730 pattern2=BACKUP READY
1731 desc2=Backup ready
1732 action2=none
1733 window=960
1734 The first rule generates "WAITING FOR BACKUP" event every night at
1736 1:59AM. This event is matched by the second rule, which starts a cor‐
1737 relation operation that will wait for "BACKUP READY" event for the next
1738 16 minutes. If the event arrives on time, no action is executed, oth‐
1739 erwise
1740 sendtrap.sh "Backup not ready!"
1742 is called.
1744 Example 3
1746 Consider the following rules:
1747 type=SingleWithScript
1749 ptype=RegExp
1750 pattern=node (\S+) interface (\S+) down
1751 script=not_resp.sh $2
1752 desc=NODE $1 IF $2 DOWN
1753 action=event %s
1754 type=Pair
1756 ptype=RegExp
1757 pattern=NODE (\S+) IF (\S+) DOWN
1758 desc=Interface $2 is down at node $1
1759 action=shellcmd notify.sh "%s"
1760 ptype2=SubStr
1761 pattern2=node $1 interface $2 up
1762 desc2=Interface $2 is up at node $1
1763 action2=shellcmd notify.sh "%s"
1764 window=86400
1765 If "node <node> interface <interface> down" event is observed, the
1767 interface is checked with the not_resp.sh script. If the interface is
1768 found to be down (not_resp.sh returns 0 as its exit code), event "NODE
1769 <node> IF <interface> DOWN" is generated which will be matched by the
1770 second rule. The second rule starts a correlation operation that calls
1771 notify.sh "Interface <interface> is down at node <node>"
1773 and then waits for the "node <node> interface <interface> up" event for
1775 the next 24 hours. When that event is observed, the correlation opera‐
1776 tion calls
1777 notify.sh "Interface <interface> is up at node <node>"
1779 and terminates.
1781 Example 4
1783 Suppose you have a disk box that logs following error messages:
1784 Description of Error:
1786 Disk drive (CRU: A1) has failed and can no longer be accessed. (SP
1788 Event Code 0xA07)
1789 Probable Cause / Recommended Action:
1791 Replace the disk module (CRU: A1).
1793 You would like to receive an e-mail message if something happens to the
1795 disk box. You would like to use different e-mail address at night-time
1796 and also receive a report of all night events. The problem here is that
1797 useful information is scattered over 7 lines and needs to be consoli‐
1798 dated into a single event. Consider the following rules for accomplish‐
1799 ing this task:
1800 type=Calendar
1802 time=0 22 * * *
1803 desc=night
1804 action=create %s 36000 \
1805 (report %s /bin/mail root@localhost)
1806 type=Single
1808 ptype=RegExp7
1809 pattern=Description of Error:\n.*\n(.+)\n.*\n.*\n.*\n(.+)
1810 context=night
1811 desc=Error=$1 Recmnd=$2
1812 action=shellcmd nightalarm.sh "%s"; add night %s
1813 type=Single
1815 ptype=RegExp7
1816 pattern=Description of Error:\n.*\n(.+)\n.*\n.*\n.*\n(.+)
1817 desc=Error=$1 Recmnd=$2
1818 action=shellcmd alarm.sh "%s"
1819 The first rule creates the context night with the lifetime of 10 hours
1821 every day at 10PM. The second rule specifies that the script nighta‐
1822 larm.sh must be used for sending alert messages at nights, otherwise
1823 the script alarm.sh should be used. Every night-time event is added to
1824 the context night, and collected events will be mailed to root@local‐
1825 host at 8AM.
1826 Example 5
1828 This section presents an example rulebase for managing Cisco devices.
1829 It is assumed that the managed devices have syslog(3)-style logging
1830 enabled, and that all syslog messages are sent to a central host and
1831 written to logfile(s) that are monitored by SEC.
1832 # Set up contexts NIGHT and WEEKEND for nights
1834 # and weekends. The context NIGHT has a lifetime
1835 # of 8 hours and the context WEEKEND 2 days
1836 type=Calendar
1838 time=0 23 * * *
1839 desc=NIGHT
1840 action=create %s 28800
1841 type=Calendar
1843 time=0 0 * * 6
1844 desc=WEEKEND
1845 action=create %s 172800
1846 # If a router does not come up within 5 minutes
1848 # after it was rebooted, generate event
1849 # "<router> REBOOT FAILURE". The next rule matches
1850 # this event, checks the router with ping and sends
1851 # a notification if there is no response.
1852 type=PairWithWindow
1854 ptype=RegExp
1855 pattern=(\S+) \d+: %SYS-5-RELOAD
1856 desc=$1 REBOOT FAILURE
1857 action=event %s
1858 ptype2=RegExp
1859 pattern2=($1) \d+: %SYS-5-RESTART
1860 desc2=$1 successful reboot
1861 action2=logonly
1862 window=300
1863 type=SingleWithScript
1865 ptype=RegExp
1866 pattern=(\S+) REBOOT FAILURE
1867 script=not_responding.sh $1
1868 desc=$1 did not come up after reboot
1869 action=shellcmd notify.sh "%s"
1870 # Send a notification if CPU load of a router is too
1872 # high (two CPUHOG messages are received within 5
1873 # minutes); send another notification if the load is
1874 # normal again (no CPUHOG messages within last 15
1875 # minutes). Rule is not applied at night or weekend.
1876 type=SingleWith2Thresholds
1878 ptype=RegExp
1879 pattern=(\S+) \d+: %SYS-3-CPUHOG
1880 context=!(NIGHT || WEEKEND)
1881 desc=$1 CPU overload
1882 action=shellcmd notify.sh "%s"
1883 window=300
1884 thresh=2
1885 desc2=$1 CPU load normal
1886 action2=shellcmd notify.sh "%s"
1887 window2=900
1888 thresh2=0
1889 # If a router interface is in down state for less
1891 # than 15 seconds, generate event
1892 # "<router> INTERFACE <interface> SHORT OUTAGE";
1893 # otherwise generate event
1894 # "<router> INTERFACE <interface> DOWN".
1895 type=PairWithWindow
1897 ptype=RegExp
1898 pattern=(\S+) \d+: %LINK-3-UPDOWN: Interface (.+), changed state to
1899 down
1900 desc=$1 INTERFACE $2 DOWN
1901 action=event %s
1902 ptype2=RegExp
1903 pattern2=($1) \d+: %LINK-3-UPDOWN: Interface ($2), changed state to up
1904 desc2=$1 INTERFACE $2 SHORT OUTAGE
1905 action2=event %s
1906 window=15
1907 # If "<router> INTERFACE <interface> DOWN" event is
1909 # received from the previous rule, send a notification and
1910 # wait for "interface up" event for the next 24 hours
1911 type=Pair
1913 ptype=RegExp
1914 pattern=(\S+) INTERFACE (\S+) DOWN
1915 desc=$1 interface $2 is down
1916 action=shellcmd notify.sh "%s"
1917 ptype2=RegExp
1918 pattern2=($1) \d+: %LINK-3-UPDOWN: Interface ($2), changed state to up
1919 desc2=$1 interface $2 is up
1920 action2=shellcmd notify.sh "%s"
1921 window=86400
1922 # If ten "short outage" events have been observed
1924 # in the window of 6 hours, send a notification
1925 type=SingleWithThreshold
1927 ptype=RegExp
1928 pattern=(\S+) INTERFACE (\S+) SHORT OUTAGE
1929 desc=Interface $2 at node $1 is unstable
1930 action=shellcmd notify.sh "%s"
1931 window=21600
1932 thresh=10
1933
1935 If the SECRC environment variable is set, SEC expects it to contain the
1936 name of its resource file. Resource file lines which are empty or which
1937 begin with # (whitespace may precede #) are ignored; other lines must
1938 contain SEC command line options, with each option on a separate line.
1939 When SEC reads the resource file, each non-empty and non-comment line
1940 is considered a single option and is pushed into the @ARGV array as a
1941 single element. Note that although SEC re-reads its resource file at
1942 the reception of the SIGHUP or SIGABRT signal, adding an option that
1943 specifies a certain startup procedure (e.g., -pid or -detach) will not
1944 produce the desired effect at runtime.
1945
1947 SIGHUP SEC will reopen its log and input files, reload its configura‐
1948 tion, and reset internal lists that contain correlation informa‐
1949 tion (i.e., all active event correlation operations will be can‐
1950 celled, all contexts will be deleted, and all user-defined vari‐
1951 ables will lose their values). SEC will also send the SIGTERM
1952 signal to its child processes.
1953 SIGABRT
1955 SEC will reopen its log and input files, and load its configura‐
1956 tion from rule files which have been modified (file modification
1957 time returned by stat(2) has changed) or created after the pre‐
1958 vious configuration load. SEC will also cancel event correla‐
1959 tion operations started from rule files that have been modified
1960 or removed after the previous configuration load. Other opera‐
1961 tions and other event correlation entities (contexts, variables,
1962 child processes, etc.) will remain intact. Note that on some
1963 systems SIGIOT is used in place of SIGABRT.
1964 SIGUSR1
1966 some information about the current state of SEC (content of
1967 internal lists, rule usage statistics, etc.) will be written to
1968 the SEC dumpfile.
1969 SIGUSR2
1971 SEC will reopen its logfile (useful for logfile rotation).
1972 SIGTERM
1974 SEC will terminate gracefully (all SEC child processes will
1975 receive SIGTERM).
1976
1978 Risto Vaarandi (ristov at users d0t s0urcef0rge d0t net)
1979
1981 crontab(1), date(1), fork(2), logsurfer(1), perl(1), perlre(1),
1982 pipe(2), snmpnotify(1), snmptrap(1), stat(2), syslog(3), time(2)
1983SEC 2.4.1 March 2007 sec.pl(1)