[asterisk-dev] New security log channel

[Atis Lezdins]

On Fri, Apr 24, 2009 at 4:27 PM, Russell Bryant <russell at digium.com> wrote:
> freebetel wrote:
>> As discussed earlier this month with John Todd and Kevin Flemings in our
>> meeting in Canada (IT360 & Asterisk conference), I'm working on adding more
>> security log information to be treated later by an external process that
>> will make decision about blocking access to certain IP addresses found to be
>> a security threat.
>>
>> I'm starting to write code and patches to inform the Asterisk administrator
>> about potential SIP and IAX2 attacks in realtime and I need to create a new
>> log channel.
>>
>> Should we call it SECURITY? I checked the logger.c file and didn't find any
>> specific channel log for security information (from the trunk source).
>>
>> Waiting for suggestions otherwise I will use SECURITY.
>
> I think identifying the pieces of code where we would want to report a
> security event is an excellent idea.  However, I would not recommend
> going ahead with writing log messages in the form:
>
>  ast_log(LOG_SECURITY, "something ...\n");
>
> My main concern with this approach is that it means the _only_ place
> that you will be able to get access to this information is via the
> Asterisk logger.  What if someone wants to monitor this information over
> the manager interface?  What if they'd like to write a custom C module
> that logs them to a database?  etc etc ... It's manager_event() all over
> again.
>
> I propose that instead, we use the ast_event API to report security
> events.  This will require a definition of event types and information
> elements needed to be able to report all of the relevant information.
> Then, we can still have LOG_SECURITY.  However, the implementation will
> be a subscriber to these security events, and will encode them into a
> parseable log file format.
>
> So, in summary, this approach would do a few things:
>
> 1) The security information is easily available throughout any part of
> Asterisk.
>
> 2) By forcing a definition in code of the event types and information
> elements, it will help us enforce content consistency across the various
> events.
>
> 3) We will still have a security log file that can be used by fail2ban
> or some other similar tool.
>

Nice idea, but what about extending it a bit more?

In manager add a translator to log, so all manager events are
transformed to log lines.

For example SecurityFail event gets translated into [SECURITY] level
in log, the rest goes to [DEBUG] or somewhere else, as it's useful for
debugging. Currently some functions generating manager events also
generate line with [DEBUG] next to event, but some don't.

Regards,
Atis


-- 
Atis Lezdins,
VoIP Project Manager / Developer,
IQ Labs Inc,
atis at iq-labs.net
Skype: atis.lezdins
Cell Phone: +371 28806004
Cell Phone: +1 800 7300689
Work phone: +1 800 7502835