[Freeswitch-users] Per-channel fsctl loglevel?

[Avi Marcus]

On Wed, May 30, 2012 at 11:18 PM, Michael Collins <msc at freeswitch.org>wrote:

> How are you protecting everything else? If the XML CDR is sent over HTTP
> instead of HTTPS then everything about the call is plain text.

As far as I know, the only thing sensitive in the xml_cdr is digits_dialed.


> And what about the FS logs? Are you encrypting those somehow? It seems to
> me that you need a more comprehensive solution than just scrubbing a single
> channel variable.
>
No, I'm not encrypting them.. because t here wouldn't be anything
sensitive. As far as I can tell, the only issue is the DTMF in DEBUG and
the curl post message, again in DEBUG.
Since this is a lua IVR it seems nearly nothing else makes it into the log.
Only api:execute("curl",...) is in the log because it's not a native direct
curl command (like session:playandgetdigits())


> However, if you need an interim solution I would suggest commenting out
> the line that sets digits_dialed:
>
> http://fisheye.freeswitch.org/browse/freeswitch.git/src/switch_channel.c?r=HEAD#to3912
>
> A more permanent solution might be to create a channel variable that
> controls whether stuff like this gets logged. Something like
> "no_dtmf_logging=true" or whatever. That's a bit more involved because you
> have to decide if there are other places where DTMF info gets logged and if
> so, decide whether or not you want not to log them.
>
That's an interesting idea... it might be more encompassing to have a
loglevel=X channel variable instead that affects the logging for that
channel. But this is probably overkill...

>
> What would be the ideal solution for your scenario? That answer might
> yield the best course of action.
> -MC
>
>
> On Wed, May 30, 2012 at 11:20 AM, Avi Marcus <avi at avimarcus.net> wrote:
>
>> The PCI-DSS (Payment Card Industry Data Security Standard) requires
>> encryption, not merely permission restriction, for sensitive data. Hence
>> I'm looking at the DTMF logging which can probably be easily re-patterned
>> back into the digits, the curl POST which also shows everything in the log,
>> the dialed_digits in a standard xml_cdr..
>> Otherwise, afaik, lua won't log things unless you explicitly tell it to.
>>
>> Any suggestions other than setting the entire switch to fsctl loglevel 6
>> and not storing the xml_cdrs in their raw form?
>>
>> -Avi
>>
>> On Wed, May 30, 2012 at 8:11 PM, Michael Collins <msc at freeswitch.org>wrote:
>>
>>> If it's a compliance issue then I'd triple-check to make sure that no
>>> one unauthorized can get to any of your FS logs or CDR data. I suspect that
>>> logging vs. not logging dialed_digits is not a make-or-break proposition.
>>> If you're doing xml_cdrs then you've probably got that same data in other
>>> log lines.
>>>
>>> -MC
>>>
>>>
>>> On Wed, May 30, 2012 at 9:08 AM, Patrick Lists <
>>> freeswitch-list at puzzled.xs4all.nl> wrote:
>>>
>>>> On 30-05-12 17:48, Michael Collins wrote:
>>>> >     And.. similarly is there a way to blank out the var digits_dialed
>>>> in
>>>> >     the xml_cdr, from within FS, before the end of the call?
>>>> >
>>>> > Why do you need to clear it out? What information does it collect that
>>>> > you don't need?
>>>>
>>>> Since it's credit card data I can imagine Avi does not want it logged
>>>> for security purposes.
>>>>
>>>> Regards,
>>>> Patrick
>>>>
>>>
>>>
>>> _________________________________________________________________________
>>> Professional FreeSWITCH Consulting Services:
>>> consulting at freeswitch.org
>>> http://www.freeswitchsolutions.com
>>>
>>> 
>>> 
>>>
>>> Official FreeSWITCH Sites
>>> http://www.freeswitch.org
>>> http://wiki.freeswitch.org
>>> http://www.cluecon.com
>>>
>>> Join Us At ClueCon - Aug 7-9, 2012
>>>
>>> FreeSWITCH-users mailing list
>>> FreeSWITCH-users at lists.freeswitch.org
>>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
>>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
>>> http://www.freeswitch.org
>>>
>>>
>>
>> _________________________________________________________________________
>> Professional FreeSWITCH Consulting Services:
>> consulting at freeswitch.org
>> http://www.freeswitchsolutions.com
>>
>> 
>> 
>>
>> Official FreeSWITCH Sites
>> http://www.freeswitch.org
>> http://wiki.freeswitch.org
>> http://www.cluecon.com
>>
>> Join Us At ClueCon - Aug 7-9, 2012
>>
>> FreeSWITCH-users mailing list
>> FreeSWITCH-users at lists.freeswitch.org
>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
>> http://www.freeswitch.org
>>
>>
>
> _________________________________________________________________________
> Professional FreeSWITCH Consulting Services:
> consulting at freeswitch.org
> http://www.freeswitchsolutions.com
>
> 
> 
>
> Official FreeSWITCH Sites
> http://www.freeswitch.org
> http://wiki.freeswitch.org
> http://www.cluecon.com
>
> Join Us At ClueCon - Aug 7-9, 2012
>
> FreeSWITCH-users mailing list
> FreeSWITCH-users at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
> http://www.freeswitch.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20120530/8e960262/attachment-0001.html