Hi!
This is what I do:
1. use permissions module to:
- deny REGISTER with contact which points to IP of gateways by using a
regexp which also detects leading 0
- deny domain names in contact URI. yes, this is not RFC conform and will
break SMTP style forwarding
2. newer openser with blacklist feature:
- put all the sensitive IP addresses on the blacklist
- if the proxy routes a call by purpose to the gateway (detects PSTN
call) then the blacklist is not activated
- for all other calls the blacklist is activated thus the proxy can not
send a request to the gateway by mistake.
3. older openser without blacklist feature
- either check domain part of RURI in gateway (like Juha told), (make
sure to reject out-of-dialog requests with pre-laoded route set in
strict-router syntax which will cause some gateways to use the Route set
instead of the target URI)
- use some secret which is known only to the proxy and the gateway, e.g:
- add a certain header which is checked for existence in the gateway
(works of course only with gateways which allows this feature like
Asterisk)
- do not use a prefix to the RURI as secret as Cisco and Asterisk will
use the userpart of RURI in the userpart of Contact URI - those the
secret prefix is visible to the attacker
- use certain port for communication with gateway. e.g. configure openser
to listen on port 6060 too. This port will be blocked by firewall from
outside - thus SIP client can not send requests to port 6060. In openser,
when sending a request to the gateway do a
"force_send_socket("ip:6060")". This causes openser to not use
default
506 but 6060 as source port (works only with UDP). Then in the gateway
accept only SIP requests coming from port 6060 (e.g. ip access rules in
Cisco gateways, iptables with Asterisk). If the proxy sends a request to
the gateway by mistake (attack) it will send the request from port 5060
and it can't be sent to the gateway as the firewall blocks.
cheers
klaus
Hi, Permissions module tries to avoid REGISTER with
privileged IP's in
Contact
(using "register.deny" file) but I have some doubs about this security.
I'll play with the example explained in "register.deny" file:
---------------------------------------------------------------------------------------
# Suppose that we have a PSTN gateway with IP address 1.2.3.4
# We should prevent REGISTER messages that contain that IP
# address in Contact header field because that can cause serious
# security hole (a malicious user might be able to register such
# a contact and bypass security checks performed by the SIP proxy).
#
# The following line prevents registering Contacts with IP 1.2.3.4
# (Don't forget to list also all hostnames that can be used to
# reach the PSTN gateway)
ALL : "^sip:.*1\.2\.3\.4"
---------------------------------------------------------------------------------------
Ok, now a malicious user could just use SipSak to send a malicious
REGISTER
to call for free to a PSTN number 01666555444:
~# sipsak -U -C sip:01666555444@1.2.3.00004 -a passwd -s
sip:200@domain.org
Note the "000004" !!!!
So this causes a entry in "location" with fields:
- username = 200
- domain =
domain.org
- contact = sip:01666555444@1.2.3.00004
And sure 1.2.3.00004 is a valid IPv4.
This is: if the user calls itself (sip:200@domain.org) he'll get a free
PSTN call. Oppss...
Ok, a solution could be to improve the regular expression by avoiding any
number of 0's:
ALL : "^sip:.*0*1\.0*2\.0*3\.0*4"
Ok, but now the malicious user can register a domain
"hacking_my_proxy.com"
to resolve to IP 1.2.3.4, and send this REGISTER:
~# sipsak -U -C sip:01666555444@hacking_my_proxy.com -a passwd -s
sip:200@domain.org
So this will bypass the "register.deny" policy !!!!
Note that "register.deny" file says:
# (Don't forget to list also all hostnames that can be used to
# reach the PSTN gateway)
Of course, it's not possible to list all hostnames and domain resolving an
IP (anyone can
register a domain to any IP).
So then... is it really valid this "register.deny" security????
Solution for this?
-------------------------
- Forbid hostnames or domains in Contact: Ohh, too much anti-RFC 3261
(what would
"alice(a)pc33.atlanta.com" think about it? XDDD).
- Do a DNS query for the "Contact" during REGISTER: What about if DNS
changes later?
- Match the resolved IP against IP's in "register.deny" for every INVITE
leaving OpenSer. Humm.
- Avoid OpenSer using internet DNS system (so "hacking_my_proxy.com"
wouldn't be resolved)
and allow just secure domains (internal DNS or /etc/hosts): and what about
outbound calls?
isn't this solution an atrocity?
How to handle it? is it not a real security hole?
Comments are welcome. Regards.
--
Iñaki Baz Castillo
_______________________________________________
Users mailing list
Users(a)lists.openser.org
http://lists.openser.org/cgi-bin/mailman/listinfo/users