[Freeswitch-users] Security Issue

Brian West brian at freeswitch.org
Wed Jan 14 19:29:28 MSK 2015


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20150114/cbd0dc3a/attachment-0001.html 


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