[asterisk-dev] New Feature Idea

[Nir Simionovich]

On 26-Sep-10 1:39 PM, Tzafrir Cohen wrote:
> On Sun, Sep 26, 2010 at 01:11:31PM +0200, Nir Simionovich wrote:
>>    Hi All,
>>
>>     As some of you know, I'm currently involved in developing an
>> Anti-Fraud system.
>> I've recently analyzed an Asterisk hack that happened about 2 weeks ago.
>> The hack
>> involved the hacking of the "asterisk-config" tool via an insecure
>> website, then
>> adding a new context with "NoCDR" application in it.
>>
>>     This introduced a very interesting problem. Asterisk enables calls to
>> traverse without
>> CDR's being created what so ever. I believe the the NoCDR application
>> should have a small
>> config file indicating if no CDR are created, or if only manager events
>> of CDRs are sent out.
>> If someone disables CDRs completely, then if they get hacked and there
>> is no record,
>> it's their responsibility - however, the default should generate manager
>> events at least.
> If one was able to update the dialplan, one would also be able to update
> nocdr.conf or whatever.
Hmmm... True. Well, why not simply make CDR's to manager work as a 
default in the code?
not leaving the user a possibility to manage that portion. Having the 
possibility to not register
CDR records, at least in my view, is somewhat dangerous. I admit that at 
times you don't want
to do so, however, this should mainly be reflected in the MySQL backend 
of the CDR files.

>> If you then go about an connect an external system, at least that one
>> should have some
>> visibility of it.
> The call would also appear in your logs if you're verbose enough.
Be reasonable, in production environment systems you always turn all 
logging off, specifically
verbose. I can't even imagine running verbose on my customer systems, 
they can easily rack
up to 400 concurrent calls on a system, and that would inflate the 
verbose log like crazy.

>>     What do you think?
> If someone has broken into a system, that someone has direct access to
> the CDR records anyway[*]
>
> [*] Granting the asterisk user only 'CREATE' permission and not
> 'UPDATE'/'DELETE' does help here, though.
Well, that is not all that true. Sometimes only the web interface gets 
hacked, thus, the hacker
is mostly interested in hiding their track then going about and deleting 
stuff. Going about and
doing that just from the web isn't all that simplistic, and most of 
these hackers are interested
in passing traffic - not hijacking the box for a botnet or something.

Nir