[Freeswitch-users] Security Issue

Brian West brian at freeswitch.org
Wed Jan 14 20:43:41 MSK 2015 

ACLs are NOT used in the external profile at all.

<param name="apply-inbound-acl" value=
"XXXXX_ACL_NAME_FROM_ACL_CONF_XML_XXXXX"/>


On the external profile will help.

On Wed, Jan 14, 2015 at 11:30 AM, David Villasmil Govea <
david.villasmil at gmail.com> wrote:

> Authorization is done if you configure your sip profile to do it. By
> default 5060 (internal) requires authentication,  5080 (external) doesn't
> but it does use the ACL to allow or not calls.
>  On Jan 14, 2015 6:22 PM, "Ahmed Habiba" <ahabiba at gmail.com> wrote:
>
>>
>> Thanks Brian,
>>
>> What I got from the below link that unless having a record like the below
>> in acl.conf.xml, Digest Authentication(i.e. username/password) will be
>> required, please correct me.
>>
>> https://wiki.freeswitch.org/wiki/Connect_Two_FreeSWITCH_Boxes
>>
>> <node type="allow" cidr="10.10.0.1/32"/>
>>
>>
>>
>> *From: *Brian West <brian at freeswitch.org>
>> *To: *FreeSWITCH Users Help <freeswitch-users at lists.freeswitch.org>
>> *Date: *January 14, 2015 at 7:49:32 PM GMT+3
>> *Reply-To: *FreeSWITCH Users Help <freeswitch-users at lists.freeswitch.org>
>> *Subject: **Re: [Freeswitch-users] Security Issue*
>>
>>
>> Unless you've changed the configs its not setup to do that out of the box.
>>
>> On Wed, Jan 14, 2015 at 10:39 AM, Ahmed Habiba <ahabiba at gmail.com> wrote:
>>
>>> *Dear Brian,*
>>>
>>> *Thank you really for your feedback, what you mentioned is correct,
>>> however I understand that any call to comes from external system to public
>>> context to processed , the external system IP shall be allowed via ACL,
>>> accordingly we shouldn't expect any traffic to processed from a **server/IP
>>> that is not defined in the ACL, am I correct?*
>>>
>>> *Thanks,*
>>>
>>> *Ahmed Habiba.*
>>> *From: *Brian West <brian at freeswitch.org>
>>> *To: *FreeSWITCH Users Help <freeswitch-users at lists.freeswitch.org>
>>> *Date: *January 14, 2015 at 7:29:28 PM GMT+3
>>> *Reply-To: *FreeSWITCH Users Help <freeswitch-users at lists.freeswitch.org
>>> >
>>> *Subject: **Re: [Freeswitch-users] Security Issue*
>>>
>>>
>>> You have some learning to do about VoIP and various security models.
>>> See comments inline.
>>>
>>> On Wed, Jan 14, 2015 at 10:08 AM, Ahmed Habiba <ahabiba at gmail.com>
>>>  wrote:
>>>
>>>> Dears,
>>>>
>>>> Kindly I noticed a very strange behaviour on Freeswitch that may allow
>>>> non authorised users to make call through the system below is the log and
>>>> my notice highlighted, you help will be appreciated.
>>>>
>>>> 1-Below is a request coming from not authored IP.
>>>> 2-However the originating IP is “142.54.179.218” the from is as below
>>>> as if it is from the same server:
>>>>
>>>
>>> The IP was 142.54.179.218... thats the real IP we received the request
>>> from.
>>>
>>>
>>>>
>>>> freeswitch at internal> recv 770 bytes from udp/[142.54.179.218]:5070 at
>>>> 16:41:34.211099:
>>>>
>>>> ------------------------------------------------------------------------
>>>>    INVITE sip:9009972599796504 at 177.31.245.177:5080 SIP/2.0
>>>>    To: 9009972599796504<sip:9009972599796504 at 177.31.245.177>
>>>>    From: 1000<sip:1000 at 177.31.245.177>;tag=e8473b10
>>>>    Via: SIP/2.0/UDP 142.54.179.218:5070
>>>> ;branch=z9hG4bK-d6e1ddab827448435f49ecaf6e613e2e;rport
>>>>    Call-ID: d6e1ddab827448435f49ecaf6e613e2e
>>>>    CSeq: 1 INVITE
>>>>    Contact: <sip:1000 at 142.54.179.218:5070>
>>>>    Max-Forwards: 70
>>>>    Allow: INVITE, ACK, CANCEL, BYE
>>>>    User-Agent: sipcli/v1.8
>>>>    Content-Type: application/sdp
>>>>    Content-Length: 285
>>>>
>>>>    v=0
>>>>    o=sipcli-Session 1883669566 1798766211 IN IP4 142.54.179.218
>>>>    s=sipcli
>>>>    c=IN IP4 142.54.179.218
>>>>    t=0 0
>>>>    m=audio 5072 RTP/AVP 18 0 8 101
>>>>    a=fmtp:101 0-15
>>>>    a=rtpmap:18 G729/8000
>>>>    a=rtpmap:0 PCMU/8000
>>>>    a=rtpmap:8 PCMA/8000
>>>>    a=rtpmap:101 telephone-event/8000
>>>>    a=ptime:20
>>>>    a=sendrecv
>>>>
>>>> 3-Accordingly Freeswitch start to deal with the call normally
>>>>
>>>
>>> As it should, Its hitting the external profile which doesn't have
>>> authentication on it.
>>>
>>>
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------
>>>> send 333 bytes to udp/[142.54.179.218]:5070 at 16:41:34.211442:
>>>>
>>>> ------------------------------------------------------------------------
>>>>    SIP/2.0 100 Trying
>>>>    Via: SIP/2.0/UDP 142.54.179.218:5070
>>>> ;branch=z9hG4bK-d6e1ddab827448435f49ecaf6e613e2e;rport=5070
>>>>    From: 1000<sip:1000 at 177.31.245.177>;tag=e8473b10
>>>>    To: 9009972599796504<sip:9009972599796504 at 177.31.245.177>
>>>>    Call-ID: d6e1ddab827448435f49ecaf6e613e2e
>>>>    CSeq: 1 INVITE
>>>>    Content-Length: 0
>>>>
>>>>    ————————————————————————————————————
>>>>
>>>> 4-as we can see below Freeswitch consider the call coming from my
>>>> server IP not from the remote IP(My server IP = 177.31.245.177)
>>>>
>>>
>>> No thats false, This is just a channel named thats formed from various
>>> bits of data, Its meaningless data and can be set, overridden or changed.
>>> This has no bearing on what freeswitch thinks.  Most likely its using the
>>> host element from the From header.
>>>
>>>
>>>>
>>>> 2015-01-14 16:41:34.203196 [NOTICE] switch_channel.c:1055 New Channel
>>>> sofia/external/1000 at 177.31.245.177
>>>> [d1879400-9c03-11e4-8cd6-2f1eb174d7b4]
>>>> 2015-01-14 16:41:34.203196 [DEBUG] switch_core_session.c:1053 Send
>>>> signal sofia/external/1000 at 177.31.245.177 [BREAK]
>>>> 2015-01-14 16:41:34.203196 [DEBUG] switch_core_session.c:1053 Send
>>>> signal sofia/external/1000 at 177.31.245.177 [BREAK]
>>>> 2015-01-14 16:41:34.203196 [DEBUG] switch_core_state_machine.c:472 (
>>>> sofia/external/1000 at 177.31.245.177) Running State Change CS_NEW
>>>> 2015-01-14 16:41:34.203196 [DEBUG] sofia.c:8812
>>>> sofia/external/1000 at 177.31.245.177 receiving invite from
>>>> 142.54.179.218:5070 version: 1.4.13 git b942d0f 2014-11-03 19:53:00Z
>>>> 64bit
>>>> 2015-01-14 16:41:34.203196 [DEBUG] sofia.c:6606 Channel
>>>> sofia/external/1000 at 177.31.245.177 entering state [received][100]
>>>> 2015-01-14 16:41:34.203196 [DEBUG] sofia.c:6616 Remote SDP:
>>>> v=0
>>>> o=sipcli-Session 1883669566 1798766211 IN IP4 142.54.179.218
>>>> s=sipcli
>>>> c=IN IP4 142.54.179.218
>>>> t=0 0
>>>> m=audio 5072 RTP/AVP 18 0 8 101
>>>> a=rtpmap:18 G729/8000
>>>> a=rtpmap:0 PCMU/8000
>>>> a=rtpmap:8 PCMA/8000
>>>> a=rtpmap:101 telephone-event/8000
>>>> a=fmtp:101 0-15
>>>> a=ptime:20
>>>>
>>>> 2015-01-14 16:41:34.203196 [DEBUG] sofia.c:6868 (
>>>> sofia/external/1000 at 177.31.245.177) State Change CS_NEW -> CS_INIT
>>>> 2015-01-14 16:41:34.203196 [DEBUG] switch_core_session.c:1388 Send
>>>> signal sofia/external/1000 at 177.31.245.177 [BREAK]
>>>> 2015-01-14 16:41:34.203196 [DEBUG] switch_core_state_machine.c:491 (
>>>> sofia/external/1000 at 177.31.245.177) State NEW
>>>> 2015-01-14 16:41:34.203196 [DEBUG] switch_core_state_machine.c:472 (
>>>> sofia/external/1000 at 177.31.245.177) Running State Change CS_INIT
>>>> 2015-01-14 16:41:34.203196 [DEBUG] switch_core_state_machine.c:512 (
>>>> sofia/external/1000 at 177.31.245.177) State INIT
>>>> 2015-01-14 16:41:34.203196 [DEBUG] mod_sofia.c:87
>>>> sofia/external/1000 at 177.31.245.177 SOFIA INIT
>>>> 2015-01-14 16:41:34.203196 [DEBUG] switch_core_state_machine.c:40
>>>> sofia/external/1000 at 177.31.245.177 Standard INIT
>>>> 2015-01-14 16:41:34.203196 [DEBUG] switch_core_state_machine.c:48 (
>>>> sofia/external/1000 at 177.31.245.177) State Change CS_INIT -> CS_ROUTING
>>>> 2015-01-14 16:41:34.203196 [DEBUG] switch_core_session.c:1388 Send
>>>> signal sofia/external/1000 at 177.31.245.177 [BREAK]
>>>> 2015-01-14 16:41:34.203196 [DEBUG] switch_core_state_machine.c:512 (
>>>> sofia/external/1000 at 177.31.245.177) State INIT going to sleep
>>>> 2015-01-14 16:41:34.203196 [DEBUG] switch_core_state_machine.c:472 (
>>>> sofia/external/1000 at 177.31.245.177) Running State Change CS_ROUTING
>>>> 2015-01-14 16:41:34.203196 [DEBUG] switch_channel.c:2184 (
>>>> sofia/external/1000 at 177.31.245.177) Callstate Change DOWN -> RINGING
>>>> 2015-01-14 16:41:34.203196 [DEBUG] switch_core_state_machine.c:528 (
>>>> sofia/external/1000 at 177.31.245.177) State ROUTING
>>>> 2015-01-14 16:41:34.203196 [DEBUG] mod_sofia.c:123
>>>> sofia/external/1000 at 177.31.245.177 SOFIA ROUTING
>>>> 2015-01-14 16:41:34.203196 [DEBUG] switch_core_state_machine.c:166
>>>> sofia/external/1000 at 177.31.245.177 Standard ROUTING
>>>>
>>>
>>> This is someone from outside calling in to your system, the public
>>> context is a sandbox to allow you to isolate and route non-authenticated
>>> traffic to your internal contexts via the transfer app, per the vanilla
>>> config examples.  This is also whey you need to understand how to secure
>>> FreeSWITCH.
>>>
>>>
>>>
>>>> 2015-01-14 16:41:34.203196 [INFO] mod_dialplan_xml.c:558 Processing
>>>> 1000 <1000>->9009972599796504 in context public
>>>>
>>>>
>>>>
>>>>
>>>> _________________________________________________________________________
>>>> Professional FreeSWITCH Consulting Services:
>>>> consulting at 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 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
>>>>
>>>
>>>
>>>
>>> --
>>>
>>> *Brian West*
>>> brian at freeswitch.org
>>>
>>>
>>> *Twitter: @FreeSWITCH , @briankwest*
>>> http://www.freeswitchbook.com
>>> http://www.freeswitchcookbook.com
>>>
>>> *T:*+19184209001 | *F:*+19184209002 | *M:*+1918424WEST (9378)
>>> *iNUM:*+883 5100 1420 9001 | *ISN:*410*543 | *Skype:*briankwest
>>>
>>>
>> _________________________________________________________________________
>> Professional FreeSWITCH Consulting Services:
>> consulting at 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 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://confluence.freeswitch.org
> http://www.cluecon.com
>
> 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
>



-- 

*Brian West*
brian at freeswitch.org


*Twitter: @FreeSWITCH , @briankwest*
http://www.freeswitchbook.com
http://www.freeswitchcookbook.com

*T:*+19184209001 | *F:*+19184209002 | *M:*+1918424WEST (9378)
*iNUM:*+883 5100 1420 9001 | *ISN:*410*543 | *Skype:*briankwest
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20150114/428ebfe2/attachment-0001.html

Join us at ClueCon 2016 Aug 8-12, 2016
More information about the FreeSWITCH-users mailing list