Re: [Freeswitch-users] FreeSWITCH-users Digest, Vol 103, Issue 177
Thank you really David, Here is my point, the sip-trace in the first mail shows that, the call comes to public context mainly through port 5080, and however the originator IP was not defined in my ACL list Freeswitch continue to process the call for some reason. even if it come to 5060, I was expecting some request for digest authentication, which is not shown in the log. From: David Villasmil Govea <david.villasmil@gmail.com <mailto:david.villasmil@gmail.com>> To: FreeSWITCH Users Help <freeswitch-users@lists.freeswitch.org <mailto:freeswitch-users@lists.freeswitch.org>> Date: January 14, 2015 at 8:30:35 PM GMT+3 Reply-To: FreeSWITCH Users Help <freeswitch-users@lists.freeswitch.org <mailto:freeswitch-users@lists.freeswitch.org>> Subject: Re: [Freeswitch-users] Security Issue 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@gmail.com <mailto:ahabiba@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 <https://wiki.freeswitch.org/wiki/Connect_Two_FreeSWITCH_Boxes> <node type="allow" cidr="10.10.0.1/32 <http://10.10.0.1/32>"/> From: Brian West <brian@freeswitch.org <mailto:brian@freeswitch.org>> To: FreeSWITCH Users Help <freeswitch-users@lists.freeswitch.org <mailto:freeswitch-users@lists.freeswitch.org>> Date: January 14, 2015 at 7:49:32 PM GMT+3 Reply-To: FreeSWITCH Users Help <freeswitch-users@lists.freeswitch.org <mailto:freeswitch-users@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@gmail.com <mailto:ahabiba@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@freeswitch.org <mailto:brian@freeswitch.org>> To: FreeSWITCH Users Help <freeswitch-users@lists.freeswitch.org <mailto:freeswitch-users@lists.freeswitch.org>> Date: January 14, 2015 at 7:29:28 PM GMT+3 Reply-To: FreeSWITCH Users Help <freeswitch-users@lists.freeswitch.org <mailto:freeswitch-users@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@gmail.com <mailto:ahabiba@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@internal> recv 770 bytes from udp/[142.54.179.218]:5070 at 16:41:34.211099: ------------------------------------------------------------------------ INVITE <> <> <>sip:9009972599796504@177.31.245.177:5080 <sip:9009972599796504@177.31.245.177:5080> SIP/2.0 To: 9009972599796504< <> <> <>sip:9009972599796504@177.31.245.177 <sip:9009972599796504@177.31.245.177>> From: 1000< <> <> <>sip:1000@177.31.245.177 <sip:1000@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@142.54.179.218:5070 <sip:1000@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@177.31.245.177 <sip:1000@177.31.245.177>>;tag=e8473b10 To: 9009972599796504< <> <> <>sip:9009972599796504@177.31.245.177 <sip:9009972599796504@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@177.31.245.177 <mailto:1000@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@177.31.245.177 <mailto:sofia/external/1000@177.31.245.177> [BREAK] 2015-01-14 16:41:34.203196 [DEBUG] switch_core_session.c:1053 Send signal sofia/external/1000@177.31.245.177 <mailto:sofia/external/1000@177.31.245.177> [BREAK] 2015-01-14 16:41:34.203196 [DEBUG] switch_core_state_machine.c:472 (sofia/external/1000@177.31.245.177 <mailto:sofia/external/1000@177.31.245.177>) Running State Change CS_NEW 2015-01-14 16:41:34.203196 [DEBUG] sofia.c:8812 sofia/external/1000@177.31.245.177 <mailto:sofia/external/1000@177.31.245.177> receiving invite from 142.54.179.218:5070 <http://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@177.31.245.177 <mailto:sofia/external/1000@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@177.31.245.177 <mailto:sofia/external/1000@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@177.31.245.177 <mailto:sofia/external/1000@177.31.245.177> [BREAK] 2015-01-14 16:41:34.203196 [DEBUG] switch_core_state_machine.c:491 (sofia/external/1000@177.31.245.177 <mailto:sofia/external/1000@177.31.245.177>) State NEW 2015-01-14 16:41:34.203196 [DEBUG] switch_core_state_machine.c:472 (sofia/external/1000@177.31.245.177 <mailto:sofia/external/1000@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@177.31.245.177 <mailto:sofia/external/1000@177.31.245.177>) State INIT 2015-01-14 16:41:34.203196 [DEBUG] mod_sofia.c:87 sofia/external/1000@177.31.245.177 <mailto:sofia/external/1000@177.31.245.177> SOFIA INIT 2015-01-14 16:41:34.203196 [DEBUG] switch_core_state_machine.c:40 sofia/external/1000@177.31.245.177 <mailto:sofia/external/1000@177.31.245.177> Standard INIT 2015-01-14 16:41:34.203196 [DEBUG] switch_core_state_machine.c:48 (sofia/external/1000@177.31.245.177 <mailto:sofia/external/1000@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@177.31.245.177 <mailto:sofia/external/1000@177.31.245.177> [BREAK] 2015-01-14 16:41:34.203196 [DEBUG] switch_core_state_machine.c:512 (sofia/external/1000@177.31.245.177 <mailto:sofia/external/1000@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@177.31.245.177 <mailto:sofia/external/1000@177.31.245.177>) Running State Change CS_ROUTING 2015-01-14 16:41:34.203196 [DEBUG] switch_channel.c:2184 (sofia/external/1000@177.31.245.177 <mailto:sofia/external/1000@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@177.31.245.177 <mailto:sofia/external/1000@177.31.245.177>) State ROUTING 2015-01-14 16:41:34.203196 [DEBUG] mod_sofia.c:123 sofia/external/1000@177.31.245.177 <mailto:sofia/external/1000@177.31.245.177> SOFIA ROUTING 2015-01-14 16:41:34.203196 [DEBUG] switch_core_state_machine.c:166 sofia/external/1000@177.31.245.177 <mailto:sofia/external/1000@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@freeswitch.org <mailto:consulting@freeswitch.org> http://www.freeswitchsolutions.com <http://www.freeswitchsolutions.com/> Official FreeSWITCH Sites http://www.freeswitch.org <http://www.freeswitch.org/> http://confluence.freeswitch.org <http://confluence.freeswitch.org/> http://www.cluecon.com <http://www.cluecon.com/> FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org <mailto:FreeSWITCH-users@lists.freeswitch.org> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users <http://lists.freeswitch.org/mailman/listinfo/freeswitch-users> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users <http://lists.freeswitch.org/mailman/options/freeswitch-users> http://www.freeswitch.org <http://www.freeswitch.org/> -- Brian West brian@freeswitch.org <mailto:brian@freeswitch.org> Twitter: @FreeSWITCH , @briankwest http://www.freeswitchbook.com <http://www.freeswitchbook.com/> http://www.freeswitchcookbook.com <http://www.freeswitchcookbook.com/> T:+19184209001 <tel:%2B19184209001> | F:+19184209002 <tel:%2B19184209002> | M:+1918424WEST (9378) iNUM:+883 5100 1420 9001 | ISN:410*543 | <> <>Skype: <skype:briankwest> <> <>briankwest <skype:briankwest>
Thank you really David, Here is my point, the sip-trace in the first mail shows that, the call comes to public context mainly through port 5080, and however the originator IP was not defined in my ACL list Freeswitch continue to process the call for some reason. even if it come to 5060, I was expecting some request for digest authentication, which is not shown in the log. From: David Villasmil Govea <david.villasmil@gmail.com <mailto:david.villasmil@gmail.com>> To: FreeSWITCH Users Help <freeswitch-users@lists.freeswitch.org <mailto:freeswitch-users@lists.freeswitch.org>> Date: January 14, 2015 at 8:30:35 PM GMT+3 Reply-To: FreeSWITCH Users Help <freeswitch-users@lists.freeswitch.org <mailto:freeswitch-users@lists.freeswitch.org>> Subject: Re: [Freeswitch-users] Security Issue 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@gmail.com <mailto:ahabiba@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 <https://wiki.freeswitch.org/wiki/Connect_Two_FreeSWITCH_Boxes> <node type="allow" cidr="10.10.0.1/32 <http://10.10.0.1/32>"/> From: Brian West <brian@freeswitch.org <mailto:brian@freeswitch.org>> To: FreeSWITCH Users Help <freeswitch-users@lists.freeswitch.org <mailto:freeswitch-users@lists.freeswitch.org>> Date: January 14, 2015 at 7:49:32 PM GMT+3 Reply-To: FreeSWITCH Users Help <freeswitch-users@lists.freeswitch.org <mailto:freeswitch-users@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@gmail.com <mailto:ahabiba@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@freeswitch.org <mailto:brian@freeswitch.org>> To: FreeSWITCH Users Help <freeswitch-users@lists.freeswitch.org <mailto:freeswitch-users@lists.freeswitch.org>> Date: January 14, 2015 at 7:29:28 PM GMT+3 Reply-To: FreeSWITCH Users Help <freeswitch-users@lists.freeswitch.org <mailto:freeswitch-users@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@gmail.com <mailto:ahabiba@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@internal> recv 770 bytes from udp/[142.54.179.218]:5070 at 16:41:34.211099: ------------------------------------------------------------------------ INVITE <> <> <>sip:9009972599796504@177.31.245.177:5080 <sip:9009972599796504@177.31.245.177:5080> SIP/2.0 To: 9009972599796504< <> <> <>sip:9009972599796504@177.31.245.177 <sip:9009972599796504@177.31.245.177>> From: 1000< <> <> <>sip:1000@177.31.245.177 <sip:1000@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@142.54.179.218:5070 <sip:1000@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@177.31.245.177 <sip:1000@177.31.245.177>>;tag=e8473b10 To: 9009972599796504< <> <> <>sip:9009972599796504@177.31.245.177 <sip:9009972599796504@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@177.31.245.177 <mailto:1000@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@177.31.245.177 <mailto:sofia/external/1000@177.31.245.177> [BREAK] 2015-01-14 16:41:34.203196 [DEBUG] switch_core_session.c:1053 Send signal sofia/external/1000@177.31.245.177 <mailto:sofia/external/1000@177.31.245.177> [BREAK] 2015-01-14 16:41:34.203196 [DEBUG] switch_core_state_machine.c:472 (sofia/external/1000@177.31.245.177 <mailto:sofia/external/1000@177.31.245.177>) Running State Change CS_NEW 2015-01-14 16:41:34.203196 [DEBUG] sofia.c:8812 sofia/external/1000@177.31.245.177 <mailto:sofia/external/1000@177.31.245.177> receiving invite from 142.54.179.218:5070 <http://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@177.31.245.177 <mailto:sofia/external/1000@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@177.31.245.177 <mailto:sofia/external/1000@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@177.31.245.177 <mailto:sofia/external/1000@177.31.245.177> [BREAK] 2015-01-14 16:41:34.203196 [DEBUG] switch_core_state_machine.c:491 (sofia/external/1000@177.31.245.177 <mailto:sofia/external/1000@177.31.245.177>) State NEW 2015-01-14 16:41:34.203196 [DEBUG] switch_core_state_machine.c:472 (sofia/external/1000@177.31.245.177 <mailto:sofia/external/1000@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@177.31.245.177 <mailto:sofia/external/1000@177.31.245.177>) State INIT 2015-01-14 16:41:34.203196 [DEBUG] mod_sofia.c:87 sofia/external/1000@177.31.245.177 <mailto:sofia/external/1000@177.31.245.177> SOFIA INIT 2015-01-14 16:41:34.203196 [DEBUG] switch_core_state_machine.c:40 sofia/external/1000@177.31.245.177 <mailto:sofia/external/1000@177.31.245.177> Standard INIT 2015-01-14 16:41:34.203196 [DEBUG] switch_core_state_machine.c:48 (sofia/external/1000@177.31.245.177 <mailto:sofia/external/1000@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@177.31.245.177 <mailto:sofia/external/1000@177.31.245.177> [BREAK] 2015-01-14 16:41:34.203196 [DEBUG] switch_core_state_machine.c:512 (sofia/external/1000@177.31.245.177 <mailto:sofia/external/1000@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@177.31.245.177 <mailto:sofia/external/1000@177.31.245.177>) Running State Change CS_ROUTING 2015-01-14 16:41:34.203196 [DEBUG] switch_channel.c:2184 (sofia/external/1000@177.31.245.177 <mailto:sofia/external/1000@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@177.31.245.177 <mailto:sofia/external/1000@177.31.245.177>) State ROUTING 2015-01-14 16:41:34.203196 [DEBUG] mod_sofia.c:123 sofia/external/1000@177.31.245.177 <mailto:sofia/external/1000@177.31.245.177> SOFIA ROUTING 2015-01-14 16:41:34.203196 [DEBUG] switch_core_state_machine.c:166 sofia/external/1000@177.31.245.177 <mailto:sofia/external/1000@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@freeswitch.org <mailto:consulting@freeswitch.org> http://www.freeswitchsolutions.com <http://www.freeswitchsolutions.com/> Official FreeSWITCH Sites http://www.freeswitch.org <http://www.freeswitch.org/> http://confluence.freeswitch.org <http://confluence.freeswitch.org/> http://www.cluecon.com <http://www.cluecon.com/> FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org <mailto:FreeSWITCH-users@lists.freeswitch.org> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users <http://lists.freeswitch.org/mailman/listinfo/freeswitch-users> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users <http://lists.freeswitch.org/mailman/options/freeswitch-users> http://www.freeswitch.org <http://www.freeswitch.org/> -- Brian West brian@freeswitch.org <mailto:brian@freeswitch.org> Twitter: @FreeSWITCH , @briankwest http://www.freeswitchbook.com <http://www.freeswitchbook.com/> http://www.freeswitchcookbook.com <http://www.freeswitchcookbook.com/> T:+19184209001 <tel:%2B19184209001> | F:+19184209002 <tel:%2B19184209002> | M:+1918424WEST (9378) iNUM:+883 5100 1420 9001 | ISN:410*543 | <> <>Skype: <skype:briankwest> <> <>briankwest <skype:briankwest>
On Wed, Jan 14, 2015 at 9:40 AM, Ahmed Habiba <ahabiba@gmail.com> wrote:
Thank you really David,
Here is my point, the sip-trace in the first mail shows that, the call comes to public context mainly through port 5080, and however the originator IP was not defined in my ACL list Freeswitch continue to process the call for some reason.
Just an FYI, the external profile does not have auth-calls param set to true, so FS simply tries to route the call in the public context without sending back an auth challenge. Since the public context is pretty paranoid it's not exactly easy to dial out. Also, just because FS tries to route the call does not mean that FS considers the call to be "authenticated." If you want all traffic coming in to your server to be authenticated then either send it all to the internal profile (i.e. port 5060) or add auth-calls to your external profile. The bigger question you may want to ask is: why are these random IP even getting to your server? Do you allow public access to your system? If so, why? If not, then you need a firewall (iptables or whatnot) to block those SIP messages from ever getting to your FreeSWITCH. You may also be interested in something like fail2ban and voipbl.org. -MC
even if it come to 5060, I was expecting some request for digest authentication, which is not shown in the log.
*From: *David Villasmil Govea <david.villasmil@gmail.com> *To: *FreeSWITCH Users Help <freeswitch-users@lists.freeswitch.org> *Date: *January 14, 2015 at 8:30:35 PM GMT+3 *Reply-To: *FreeSWITCH Users Help <freeswitch-users@lists.freeswitch.org> *Subject: **Re: [Freeswitch-users] Security Issue*
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 5060 is not asking for authentication??? If it's not, something's wrong with your config. It's not the default config. Can you paste your sip profile both internal and external? On Jan 14, 2015 6:40 PM, "Ahmed Habiba" <ahabiba@gmail.com> wrote:
Thank you really David,
Here is my point, the sip-trace in the first mail shows that, the call comes to public context mainly through port 5080, and however the originator IP was not defined in my ACL list Freeswitch continue to process the call for some reason.
even if it come to 5060, I was expecting some request for digest authentication, which is not shown in the log.
*From: *David Villasmil Govea <david.villasmil@gmail.com> *To: *FreeSWITCH Users Help <freeswitch-users@lists.freeswitch.org> *Date: *January 14, 2015 at 8:30:35 PM GMT+3 *Reply-To: *FreeSWITCH Users Help <freeswitch-users@lists.freeswitch.org> *Subject: **Re: [Freeswitch-users] Security Issue*
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@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@freeswitch.org> *To: *FreeSWITCH Users Help <freeswitch-users@lists.freeswitch.org> *Date: *January 14, 2015 at 7:49:32 PM GMT+3 *Reply-To: *FreeSWITCH Users Help <freeswitch-users@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@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@freeswitch.org> *To: *FreeSWITCH Users Help <freeswitch-users@lists.freeswitch.org> *Date: *January 14, 2015 at 7:29:28 PM GMT+3 *Reply-To: *FreeSWITCH Users Help <freeswitch-users@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@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@internal> recv 770 bytes from udp/[142.54.179.218]:5070 at 16:41:34.211099:
------------------------------------------------------------------------ INVITE sip:9009972599796504@177.31.245.177:5080 SIP/2.0 To: 9009972599796504<sip:9009972599796504@177.31.245.177> From: 1000<sip:1000@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@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@177.31.245.177>;tag=e8473b10 To: 9009972599796504<sip:9009972599796504@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@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@177.31.245.177 [BREAK] 2015-01-14 16:41:34.203196 [DEBUG] switch_core_session.c:1053 Send signal sofia/external/1000@177.31.245.177 [BREAK] 2015-01-14 16:41:34.203196 [DEBUG] switch_core_state_machine.c:472 ( sofia/external/1000@177.31.245.177) Running State Change CS_NEW 2015-01-14 16:41:34.203196 [DEBUG] sofia.c:8812 sofia/external/1000@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@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@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@177.31.245.177 [BREAK] 2015-01-14 16:41:34.203196 [DEBUG] switch_core_state_machine.c:491 ( sofia/external/1000@177.31.245.177) State NEW 2015-01-14 16:41:34.203196 [DEBUG] switch_core_state_machine.c:472 ( sofia/external/1000@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@177.31.245.177) State INIT 2015-01-14 16:41:34.203196 [DEBUG] mod_sofia.c:87 sofia/external/1000@177.31.245.177 SOFIA INIT 2015-01-14 16:41:34.203196 [DEBUG] switch_core_state_machine.c:40 sofia/external/1000@177.31.245.177 Standard INIT 2015-01-14 16:41:34.203196 [DEBUG] switch_core_state_machine.c:48 ( sofia/external/1000@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@177.31.245.177 [BREAK] 2015-01-14 16:41:34.203196 [DEBUG] switch_core_state_machine.c:512 ( sofia/external/1000@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@177.31.245.177) Running State Change CS_ROUTING 2015-01-14 16:41:34.203196 [DEBUG] switch_channel.c:2184 ( sofia/external/1000@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@177.31.245.177) State ROUTING 2015-01-14 16:41:34.203196 [DEBUG] mod_sofia.c:123 sofia/external/1000@177.31.245.177 SOFIA ROUTING 2015-01-14 16:41:34.203196 [DEBUG] switch_core_state_machine.c:166 sofia/external/1000@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@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
--
*Brian West* brian@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@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
participants (3)
-
Ahmed Habiba
-
David Villasmil Govea
-
Michael Collins