hi all,
sec rule repository has been updated with new rules for Xymon:
https://github.com/simple-evcorr/rulesets/tree/master/xymon
I would like to thank Andy for sharing them with other sec users :-)
kind regards,
risto
2018-01-26 15:59 GMT+02:00 Risto Vaarandi <risto.vaara...@gmail.com>:
> hi Andy,
>
> calling the signal handler which sets the relevant flag is another way for
> addressing the problem.
> Thanks for posting such a nice example to the mailing list :-)
>
> Since you mentioned sharing the relevant module, it would be a nice
> candidate for sec rule repository: https://github.com/simple-
> evcorr/rulesets
> If you want to share it, please let me know.
>
> kind regards,
> risto
>
>
> 2018-01-26 15:15 GMT+02:00 Andy Smith <hastym...@googlemail.com>:
>
>> Hi,
>>
>> I have some sympathy, we look after servers where the owners will not
>> permit the use of Cygwin.
>>
>> As a workaround, we load a module (Sec2Xym.pm) that includes this :-
>>
>> # Subroutine to provide access to native signal processing on platforms
>> # where signals not supported, eg Windows with native perl (ActiveState,
>> # Strawberry etc)
>> sub fake_signal_handler {
>> my ($fakesignal) = @_;
>> given ($fakesignal) {
>> when (/^HUP$/i) { main::hup_handler; }
>> when (/^ABRT$/i) { main::abrt_handler; }
>> when (/^USR1$/i) { main::usr1_handler; }
>> when (/^USR2$/i) { main::usr2_handler; }
>> when (/^INT$/i) { main::int_handler; }
>> when (/^TERM$/i) { main::term_handler; }
>> default: {
>> main::log_msg(main::LOG_WITHOUT_LEVEL,
>> "$SELF Unknown fake signal $fakesignal");
>> return "Unknown fake signal $fakesignal";
>> }
>> }
>> return 0;
>> }
>>
>> Then we include --conf=etc/01control.sr --input=etc/control=CONTROL in
>> the startup and have a ruleset like this that allows us to manipulate SEC
>> via additions to a text file we control.
>>
>> ############################################################
>> ###################
>> # Rules to allow Windows implementations to be controlled when
>> # no signals are otherwise supported
>> ############################################################
>> ###################
>> type=single
>> continue=dontcont
>> ptype=tvalue
>> pattern=TRUE
>> desc=don't apply these rules unless from control file.
>> context=! CONTROL
>> action=none
>>
>> ############################################################
>> ###################
>> type=single
>> continue=takenext
>> ptype=tvalue
>> pattern=TRUE
>> desc=report event processed.
>> action=create EVENT_PROCESSED
>>
>> ############################################################
>> ###################
>> type = single
>> continue=dontcont
>> desc = do a full restart of SEC
>> ptype = regexp
>> pattern = ^reset
>> action = lcall %r HUP -> ( sub { Sec2Xym::fake_signal_handler(@_) } );\
>> if %r ( logonly %r )
>>
>> ############################################################
>> ###################
>> type = single
>> continue=dontcont
>> desc = do a soft restart of SEC
>> ptype = regexp
>> pattern = ^reload
>> action = lcall %r ABRT -> ( sub { Sec2Xym::fake_signal_handler(@_) } );\
>> if %r ( logonly %r )
>>
>> ############################################################
>> ###################
>>
>> I am happy to share these snippets in full if anyone is interested.
>> --
>> Andy
>>
>> On 26 January 2018 at 12:46, Risto Vaarandi <risto.vaara...@gmail.com>
>> wrote:
>>
>>> hi Jaren,
>>>
>>> I can see that your rules are trying to emulate process control via UNIX
>>> signals which are missing on Windows/Strawberry platform. However, I would
>>> *not* recommend to call functions like read_config() directly, since in sec
>>> source code they are executed with a number of additional surrounding
>>> statements. For example, for clean execution of read_config() a number of
>>> hash tables are cleared in sec-2.6.2 source code, but your rules lack these
>>> statements. As a result, your sec instance will run with inconsistent
>>> internal state which could also result in unexpected duplicate output.
>>>
>>> If you want to emulate UNIX signals with Strawberry perl, probably the
>>> only reasonable way for that is to set corresponding signal flags (as
>>> signal handlers would do). For example, the following action list would set
>>> the "softrefresh" flag that is raised by ABRT signal (this signal forces
>>> SEC to reopen its inputs and reload its configuration):
>>>
>>> lcall %o -> ( sub { $main::softrefresh = 1; } )
>>>
>>> When sec sees this flag, it will execute the full code for handling the
>>> ABRT signal and then clear the flag. Therefore, you would not have issues
>>> from partial execution that would most likely lead to inconsistent/corrupt
>>> internal state.
>>>
>>> Although the mailing list archive contains an example when USR1 signal
>>> is emulated by calling dump_data() function directly, this example only
>>> works since the handling of USR1 involves executing just dump_data(). But
>>> for the sake of clarity I would personally use the signal flag approach
>>> even for USR1.
>>>
>>> However, if you seriously need support for signals and other UNIX-like
>>> functionality, I'd recommend to go with Cygwin perl.
>>>
>>> Hope this helps,
>>> risto
>>>
>>> 2018-01-26 12:59 GMT+02:00 Jaren Peich <burkol...@gmail.com>:
>>>
>>>> Hi,
>>>>
>>>> I have a problem with the reading a processing the file logs wit SEC
>>>> 2.6.2 on Windows. I use Strawberry Perl.
>>>> I have a main file with regexp and Jump rules for post processing log
>>>> lines.
>>>>
>>>> Example(invented):
>>>>
>>>> rem = Alert 001
>>>> type = Jump
>>>> ptype = RegExp
>>>> desc = $0
>>>> continue = DontCont
>>>> pattern = (.*)
>>>> varmap = alert;log=0;
>>>> cfset = alertSet
>>>>
>>>> After this rules, previously we had problems with the reading and i
>>>> added this calls from SEC library.
>>>>
>>>> #Force reopen file logs at 06:15
>>>> type=Calendar
>>>> time= 15 6 * * *
>>>> desc= $0
>>>> action= lcall %o -> ( sub { main::read_options(); main::open_input(-1,
>>>> $keepopen); } )
>>>>
>>>>
>>>> #Open Files not open yet
>>>> #type=Calendar
>>>> #time= */5 * * * *
>>>> #desc= $0
>>>> #action= lcall %o -> ( sub { main::open_input(0,1); } )
>>>>
>>>>
>>>> #Reload configuration after 2 hours.
>>>> type=Calendar
>>>> time= */15 * * * *
>>>> desc= $0
>>>> action= eval %o (sleep 61;);\
>>>> lcall %o -> ( sub { main::read_config(); } )
>>>>
>>>> The problem it´s when i rexecute(finish process and execute again)
>>>> alerts get duplicated in the output file. any idea to solve this?
>>>>
>>>> I have another doubt where or how do you create file paths from log
>>>> files in library?
>>>>
>>>> Sorry for my english.
>>>>
>>>> Thank you!. Regards. :)
>>>>
>>>
>>>
>>> ------------------------------------------------------------
>>> ------------------
>>> 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
>>>
>>>
>>
>
------------------------------------------------------------------------------
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
