[asterisk-dev] Non-universalized log messages render security tools useless in Asterisk SVN-branch-1.8-r354348 or maybe other versions as well !!!

[Bruce B]

>
>
> I understand your position, but I think there is still possible to use some
> (maybe a bit more complicated) heuristic to detect attacks. Please remember
> that VoIP/SIP is not as simple as for example ssh or telnet. SIP attacks
> may
> use relatively rich set of techniques, which will never cause generation of
> just one unified message in the "Hey! There's an attack!" style.
>
> Thanks very much for the input Pavel. I see your point on the messages
being the same and I take my objection back on #1.

But showing the source IP address in all logs CAN be standardized by
Asterisk and it should be done despite whatever sophisticated types of
attacks might come through because source IP is always an IP and has
nothing to do with what the attack format looks like.

If no source IP is sent in the SIP packet then one doesn't have to worry
because the response won't go anywhere any-ways. In that case maybe
Asterisk can pull the IP from network layer of the OS?!

Shouldn't it be upto chan_sip.c to always record that IP address? Why not
do it if the benefit greatly outweighs not doing it? Just that is done in
the registration attemtps:
*NOTICE[10331] chan_sip.c: Registration from 'Eyebeam-Softphone<
sip:9999 at 192.168.0.170>' failed for '172.16.0.6:8347' - No matching peer
found*

Above shows "172.16.0.6" which is the source IP and it can be used with
Fail2ban to block rather than resorting to CDRs. I really can't think of
using CDRs for security reasons as it will be way to complex. Log are
always used for security parsing in any system I know of and CDRs are not
really system logs bur rather dynamic logs...I appreciate and understand
that Asterisk is a PBX and security shouldn't be it's concern but it should
provide the basic standardized logging for security tools to use it
comfortably without being scared that it might changed over night with a
new build. I think once the logs are universalized for core things like
this then security issues would be much easier to tackle.

Best,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20120211/a394cea4/attachment.htm>