On Wed, 6 Feb 2013, Risto Vaarandi wrote: > hi all, > > as you know, currently there are number of outputs which are not > directly supported by sec. For example, with 'pipe' action one can feed > only one event to an external program (with most programs exiting after > the 'pipe' action closes the pipe). Also, the 'write' action opens a > given file before each access and closes it afterwards. While this makes > output file rotation worry-free, it is not very efficient. Finally, sec > does not directly support various sockets as output (for example, it is > not possible to connect directly to a syslog server on another host and > issue syslog events without any intermediaries). > > Therefore, would there be any interest to an output action which would > leave the output open/running/connected, so that the next access of the > same output would not have to do reopen/restart/connect again? This > action would have to support a number of output types, e.g., > > write2 udp myserver:514 This is my event > write2 tcp myserver:514 Another event > write2 file /var/log/myevents Third event > write2 program /bin/logger -p user.notice Fourth event > > It is probably easy to see that with sockets and files it is not that > hard to distinguish them from each other, since the filename or server > name plus port number can serve as unique identifiers. With command > lines, however, it is somewhat more difficult, since an extra space or > different ordering of options makes two command lines different, even if > their effect is exactly the same. Also, since sec uses positional > parameters, there is an issue with parsing, although this could be > solved with the use of (). In addition, one workaround for both issues > would be storing command line in an action list variable. > The action outlines above would also need an output rotation mechanism, > but this could be implemented with adding this to SIGUSR2 handler > (closing all currently open outputs). > > Would the action above be of interest, and are there any other ideas for > handling these situations?
I think this sort of thing would be useful, a lot of 'action scripts' end up being trivial wrappers to do these sorts of things, and opening/closing files and starting programs can have a surprisingly large effect on performance (I suspect that SEC has other bottlenecks, but even if it's not a bottleneck, speeding it up will leave more time for the bottleneck code :-) I would not try to match up command lines, as you note it's hard to tell when you really have two identical ones, and it makes it hard to have multiple connectons open to the same destination (important for network connections) This crys out for a filehandle approach, have something define the output and then write2 can use it. You can have calendar events close and re-open the files for log rotation now, as to specific output options. My first thing is make this extendable, people will have lots of strange outputs they want to talk to. Make it so they can define a perl subroutine and use that. you need pipe to command line (think |gzip -c - >/var/log/alerts.gz) you need send to syslog, but this may not be just send the raw string. Syslog message formatting is common across the different transport types, so it would be more 'open syslog destination' than 'open tcp destination' In formatting the syslog message, options that jump out at me include: facility/priority syslog tag (program name) source hostname (it's useful to be able to generate alert messages with the name of the relavent server, not just the SEC box) syslog format (historic syslog rfc3164, new syslog rfc5424, lumberjack JSON, CEE, CEF, ....) how to handle multiline (report) data (send as multiple log messages, send as one message with newlines, send as one message with a different separator character,...) for these, there should be a default set at open time, but it can make sense to override these for particular messages. Much of this formatting stuff is useful even if just writing to files, so it may be that the right thing is to define the transport at open time and then have a function call to format the message at log time. thoughts? David Lang ------------------------------------------------------------------------------ Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb _______________________________________________ Simple-evcorr-users mailing list Simple-evcorr-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users
