[asterisk-dev] New Feature Idea

[Kevin P. Fleming]

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.

-- 
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
skype: kpfleming | jabber: kfleming at digium.com
Check us out at www.digium.com & www.asterisk.org