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

[Pavel Troller]

Hi Bruce,
> >
> >
> > 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. 

And this is just one of the examples, which is not true for SIP!
Let's imagine that someone sends you INVITE with an invalid (random,
spoofed) source IP address. What happens ?
1) Your asterisk will try to respond, at least with 100 Trying, maybe later
with other messages.
2) Your asterisk will immediately try to make the required connection (if it's
configured this way, for example with allowguest=yes, which is necessary for
people, wanting to be reachable for example by ENUM or other publicly
available methods).
It's possible that the call will be established BEFORE the incoming leg
recognizes that nobody is there (because of the spoofed IP address) and it
will cost you money (in the case that the attacker finds an unprotected
prefix from your Asterisk outside). And somebody can maliciously make a fraud
on you, if he wants, and you will be unable to find his identity, because he
never sends a single packet with his real IP address! He can go even further
and by systematically supplying an IP address of someone else, he can cause
that you will block or maybe even try to prosecute an innocent person.

> In that case maybe
> Asterisk can pull the IP from network layer of the OS?!

Of course it can, but please be informed, that at least on systems I'm
running, a lot of attacks are done with spoofed source IP addresses. The
attackers are using the mechanism described above - they are trying to
call a certain numbers and the sign of success is not a 200 Ok message
coming back, but the fact that the called number has been rung by your
system. And once they found you by this trick, they will quickly exploit
your system by routing a massive traffic to it, this time with real IP
address pointing to Jamaica, Cuba or other exotic countries.

> 
> 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.

You are probably right that there is a space for improvement in the Asterisk
logging system. But please don't overestimate usefullness of this, just
for the reasons said above.

> 
> Best,

Regards,
  Pavel