[asterisk-dev] New Feature Idea

[Nir Simionovich]

  On 9/27/2010 11:27 PM, Kevin P. Fleming wrote:
> On 09/27/2010 04:10 PM, Nir Simionovich wrote:
>>    On 9/27/2010 10:26 PM, Russell Bryant wrote:
>>> On Mon, 2010-09-27 at 20:41 +0200, Nir Simionovich wrote:
>>>> I may have come off base here and missed the point a bit. I'm not
>>>> claiming there is a bug or a behaviour
>>>> that is not planned. My only claim is that in a production environment,
>>>> having the possibility of disabling
>>>> the CDR generation on a diaplan basis is good, however, at the same time
>>>> the manager should at least
>>>> report that CDR. It doesn't get written to the file or MySQL, but an
>>>> external process that monitors the system
>>>> can get view of that.
>>> but if someone gains the ability to modify the configuration files, then
>>> they can turn off the manager interface, too.  Or, if they were trying
>>> to be more sneaky about it, they could _only_ disable CDR events for
>>> manager accounts.  As has been implied, the problem here is really much
>>> more serious than CDRs, and is not something Asterisk can solve.
>>>
>> Well,
>>
>>     To be honest, I was thinking about something that is a little more
>> drastic, in such a manner
>> that you can't turn it off. Let's say, a compile time flag that
>> indicates that CDR events are
>> always created.
> And what if the person who has gained access causes all modules that
> output CDRs to be unloaded? What if they change the passwords on all
> manager.conf accounts, so that even though the CDRs are sent to manager
> connections, no such connections can be established?
>
> If a person has gained access to modify any and all Asterisk
> configuration files, there's pretty much no way you can ensure that
> you'll be able to see evidence of what they are doing
Ohhhhh... point well taken.

Nir S