Hi Lyubo, In this case it may be better to see if your CDR parser can skip the non-numeric caller id values, perhaps by adding a validation check prior to performing the parse action. As a rule of thumb, if your CDR parser can be tripped up by the data it is parsing then it needs to be hardened. I'm sure many here would highly recommend sanitizing/validation as a best practice, particularly when handling data that comes from the public Internet. Another consideration is that you may actually want to have a record of these kinds of attacks in case there is a need to investigate an incident or otherwise analyze attack patterns. I would recommend that you change the behavior of the parser from "complaining" to "keeping the CDR database clean but logging invalid input for future reference." Hope this helps, -MC On Fri, Dec 15, 2017 at 1:11 PM, Lyubo Popov <koki.roul@gmail.com> wrote:
Hello all,
Maybe someone can help me with this problem and will be greatly appreciated. We are getting calls with CallerID like this one ‘hi'or‘x’='x'. Later when our billing start parsing the CDRs it will complain because of the first character "`". My question I suppose is, how to prevent such calls to get added to the CDRs? We want to reject the call that has non numeric CallerID and not get it added in the CDRs. This is what we have in the dialplan.
<extension name="Routing"> <condition field="${radius_auth_result}" expression="0"/>
<!-- <condition field="${h323-redirect-number}" expression="^(.+)$" break="never"> <action application="set" data="destination_number=$1" /> </condition> --> <condition field="caller_id_number" expression="^([0-9]+)$"> <anti-action application="hangup"/> </condition> <condition field="destination_number" expression="^(.+)$"> <!--<action application="info"/>--> <action application="export" data="nolocal:h323-call- origin=originate"/> <action application="set" data="sip_h_X-accountcode=${accountcode}" /> <action application="set" data="call_direction=outbound" /> <action application="set" data="hangup_after_bridge=true"/> <action application="set" data="continue_on_fail=true"/> <action application="set" data="inherit_codec=true" /> <action application="set" data="call_timeout=20"/> <action application="set" data="fail_on_single_reject=USER_BUSY" /> <action application="set" data="origination_caller_id_ name=${sip_req_user}"/> <action application="set" data="origination_caller_id_ number=${sip_from_user}"/> <action application="set" data="execute_on_answer=sched_hangup +${h323-credit-time} alloted_timeout" /> <action application="bridge" data="{sip_invite_from_uri= sip:${sip_from_user}@${sip_network_ip}}sofia/internal/${ destination_number}@x.x.x.x:5060" /> <action application="hangup" data="${bridge_hangup_cause}"/> </condition> </extension>
Thank you all!
L.Popov
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=icon> Virus-free. www.avast.com <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=link> <#m_-7626445720286026976_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org