<p dir="ltr">I did't dig into sources, but I actually tried both true and false. According to wiki:<br>
limit_ignore_transfer=true - causes the current call count to not be reset when the call is transferred. This is useful where calls that come into a gateway are transferred to an extension, but you want to preserve the call count.</p>
<p dir="ltr">limit_ignore_transfer=false - calls that are transferred cause the call count for that realm_id to decrement</p>
<p dir="ltr">So "false" is definitely not the right thing in my case. Docs are incorrect, or I misunderstand something?</p>
<div class="gmail_quote">On Mar 4, 2014 8:07 AM, "Brian West" <<a href="mailto:brian@freeswitch.org">brian@freeswitch.org</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Or you could just set limit_ignore_transfer=false<br>
<br>
<a href="https://wiki.freeswitch.org/wiki/Limit#Variables_that_affect_limit" target="_blank">https://wiki.freeswitch.org/wiki/Limit#Variables_that_affect_limit</a><br>
<br>
limit_state_handler in switch_limit.c<br>
<br>
<br>
--<br>
Brian West<br>
<a href="mailto:brian@freeswitch.org">brian@freeswitch.org</a><br>
FreeSWITCH Solutions, LLC<br>
PO BOX 2531<br>
Brookfield, WI 53008-2531<br>
Twitter: @FreeSWITCH , @briankwest<br>
<a href="http://www.freeswitchbook.com" target="_blank">http://www.freeswitchbook.com</a><br>
<a href="http://www.freeswitchcookbook.com" target="_blank">http://www.freeswitchcookbook.com</a><br>
<br>
T: +1.918.420.9001 | F: +1.918.420.9002 | M: +1.918.424.WEST<br>
iNUM: +883 5100 1420 9001<br>
ISN: 410*543<br>
Skype:briankwest<br>
PGP Key: <a href="http://www.bkw.org/key.txt" target="_blank">http://www.bkw.org/key.txt</a> (AB93356707C76CED)<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
On Mar 3, 2014, at 3:09 AM, Dmitry Sytchev <<a href="mailto:kbdfck@gmail.com">kbdfck@gmail.com</a>> wrote:<br>
<br>
> Hi all!<br>
><br>
> <intro><br>
> If you use FS or other softswitch with to provide services with limited amounts of concurrent calls and have enabled REFER method for your SIP users (you may disable it by disable-transfer in profiles, default false), your setup may be vulnerable to call limit bypass attack.<br>
><br>
> For example, someone stoles credentials or bruteforces account password of your SIP user and sends an amount of calls to premium numbers or longdistance directions. These attempts should be at least limited with customer call limit, but there is a method to bypass it.<br>
><br>
> When attacker sees the call limit is set on account, and call limit > 1, he tries to bypass it to increase speed and amount of outbound calls. He makes one outbound call, then makes second. At this moment there is four channels - two inbound channels to FS, and two outbound channels from FS to PSTN or SIP gw. FS sets call limit usage to 2.<br>
> Now attacker issuing transfer request by sending REFER to bridge two outbound channels with each other. After successful transfer, two inbound channels are destroyed and outbound channels are bridged together. After that, FS decreases call limit, since it destroyed channels limit was set on.<br>
> </intro><br>
><br>
> The problem is the method people often use to limit concurrent calls. Something like that:<br>
><br>
> <action application="limit" data="hash OutboundLimit ${pbx_subscriber_customer_id} ${pbx_customer_call_limit} !CALL_REJECTED"/><br>
> <action application="bridge" data="{ignore_early_media=false,hangup_after_bridge=false}sofia/gateway/gw/$1"/><br>
><br>
> Now limit is set on inbound channel. When attacker bridges outbound channels, their A-legs (inbound channels) get destroyed and FS decreases limit due to channel destruction. So attacker have 2 outbound bridged channels, and limit is still 0. Then the process repeats, allowing attacker effectively bypass your call limits.<br>
><br>
> One of possible solutions is to move limits on B-legs after answer, while keeping limits on A-legs too in order prevent exceeding limit by unanswered calls:<br>
><br>
> We set limit on A-LEG, then on answer we decrease limit on A-LEG and "move" it to B-leg by calling limit on outbound channel.<br>
><br>
> <action application="export" data="nolocal:execute_on_answer_1=set api_result=${uuid_limit_release(${uuid} hash OutboundLimit ${pbx_subscriber_customer_id})}"/><br>
> <action application="export" data="nolocal:execute_on_answer_2=limit hash OutboundLimit ${pbx_subscriber_customer_id} ${pbx_customer_call_limit} !CALL_REJECTED"/><br>
> <action application="limit" data="hash OutboundLimit ${pbx_subscriber_customer_id} ${pbx_customer_call_limit} !CALL_REJECTED"/><br>
> <action application="bridge" data="{ignore_early_media=false,hangup_after_bridge=false}sofia/gateway/gw/$1"/><br>
><br>
> Now limit is correctly evaluated for non-answered outbound calls, and doesn't allow excessive calls.<br>
><br>
> Hope this helps somebody. Maybe you guys know more effective and correct ways to prevent limit bypassing in this scenario?<br>
><br>
><br>
><br>
><br>
><br>
> --<br>
> Best regards,<br>
><br>
> Dmitry Sytchev,<br>
> IT Engineer<br>
> _________________________________________________________________________<br>
> Professional FreeSWITCH Consulting Services:<br>
> <a href="mailto:consulting@freeswitch.org">consulting@freeswitch.org</a><br>
> <a href="http://www.freeswitchsolutions.com" target="_blank">http://www.freeswitchsolutions.com</a><br>
><br>
> FreeSWITCH-powered IP PBX: The CudaTel Communication Server<br>
> <a href="http://www.cudatel.com" target="_blank">http://www.cudatel.com</a><br>
><br>
> Official FreeSWITCH Sites<br>
> <a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
> <a href="http://wiki.freeswitch.org" target="_blank">http://wiki.freeswitch.org</a><br>
> <a href="http://www.cluecon.com" target="_blank">http://www.cluecon.com</a><br>
><br>
> FreeSWITCH-users mailing list<br>
> <a href="mailto:FreeSWITCH-users@lists.freeswitch.org">FreeSWITCH-users@lists.freeswitch.org</a><br>
> <a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users</a><br>
> UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-users</a><br>
> <a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
<br>
<br>_________________________________________________________________________<br>
Professional FreeSWITCH Consulting Services:<br>
<a href="mailto:consulting@freeswitch.org">consulting@freeswitch.org</a><br>
<a href="http://www.freeswitchsolutions.com" target="_blank">http://www.freeswitchsolutions.com</a><br>
<br>
FreeSWITCH-powered IP PBX: The CudaTel Communication Server<br>
<a href="http://www.cudatel.com" target="_blank">http://www.cudatel.com</a><br>
<br>
Official FreeSWITCH Sites<br>
<a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
<a href="http://wiki.freeswitch.org" target="_blank">http://wiki.freeswitch.org</a><br>
<a href="http://www.cluecon.com" target="_blank">http://www.cluecon.com</a><br>
<br>
FreeSWITCH-users mailing list<br>
<a href="mailto:FreeSWITCH-users@lists.freeswitch.org">FreeSWITCH-users@lists.freeswitch.org</a><br>
<a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users</a><br>
UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-users</a><br>
<a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
<br></blockquote></div>