Hi!
I've got a small problem and don't know how to solve it best, so I would appreciate your comments:
I want to allow my ser users to call any IP destination for free and always, but I want to restrict access to the PSTN. Therefore, I authenticate, account and check if user is in PSTN group before forwarding to the gateway (local GW or the GW of an PSTN termination provider).
But, for example if one of my users call 1234567@anydomain.com and this domain resolvs to the IP address of the gateway, the request would be forwarded to the gateway, and the GW would accept the call as it comes from a trusted SIP proxy. How can I prevent this?
regards, Klaus
Klaus Darilion writes:
But, for example if one of my users call 1234567@anydomain.com and this domain resolvs to the IP address of the gateway, the request would be forwarded to the gateway, and the GW would accept the call as it comes from a trusted SIP proxy. How can I prevent this?
see allow_routing in permissions module, juha
On 15-03 11:42, Klaus Darilion wrote:
Hi!
I've got a small problem and don't know how to solve it best, so I would appreciate your comments:
I want to allow my ser users to call any IP destination for free and always, but I want to restrict access to the PSTN. Therefore, I authenticate, account and check if user is in PSTN group before forwarding to the gateway (local GW or the GW of an PSTN termination provider).
But, for example if one of my users call 1234567@anydomain.com and this domain resolvs to the IP address of the gateway, the request would be forwarded to the gateway, and the GW would accept the call as it comes from a trusted SIP proxy. How can I prevent this?
Perhaps the gateway could refuse messages which don't have the IP address of the gateway in the Request-URI ? In this case 1234567@mydomain.com would be refused even if it is coming from a trusted proxy.
Jan.
At 01:32 PM 3/15/2004, Jan Janak wrote:
Perhaps the gateway could refuse messages which don't have the IP address of the gateway in the Request-URI ? In this case 1234567@mydomain.com would be refused even if it is coming from a trusted proxy.
Actually I like this way best. It is simple which is good for security.
-jiri
At 11:42 AM 3/15/2004, Klaus Darilion wrote:
Hi!
I've got a small problem and don't know how to solve it best, so I would appreciate your comments:
I want to allow my ser users to call any IP destination for free and always, but I want to restrict access to the PSTN. Therefore, I authenticate, account and check if user is in PSTN group before forwarding to the gateway (local GW or the GW of an PSTN termination provider).
But, for example if one of my users call 1234567@anydomain.com and this domain resolvs to the IP address of the gateway, the request would be forwarded to the gateway, and the GW would accept the call as it comes from a trusted SIP proxy. How can I prevent this?
There are some techniques you may use to lower the risks by other means than calling outside.
You may for example authenticate and account all calls to outbound domains -- this way, only users of your domain will be able to make such calls and will be accounted for (but group checks are not executed!).
A technique is to split SER in two proxies -- general-purpose proxy and gateway barrier proxy. The gateway barrier would avoid risky logic such as DNS resolution and do simply its ACL job.
Other rechnique an esteemed seruser deployed is to insert a secret prefix in SER to URIs considered to go to gateway and only accept such at the gateway. (I haven't given it a try yet, I would have to see if we need some extra work to mangle the prefix if it appears in gateway's contacts. Otherwise callers may be tempted to learn and upload or provision such contacts.)
-jiri
Jiri Kuthan wrote:
At 11:42 AM 3/15/2004, Klaus Darilion wrote:
Hi!
I've got a small problem and don't know how to solve it best, so I would appreciate your comments:
I want to allow my ser users to call any IP destination for free and always, but I want to restrict access to the PSTN. Therefore, I authenticate, account and check if user is in PSTN group before forwarding to the gateway (local GW or the GW of an PSTN termination provider).
But, for example if one of my users call 1234567@anydomain.com and this domain resolvs to the IP address of the gateway, the request would be forwarded to the gateway, and the GW would accept the call as it comes from a trusted SIP proxy. How can I prevent this?
There are some techniques you may use to lower the risks by other means than calling outside.
You may for example authenticate and account all calls to outbound domains -- this way, only users of your domain will be able to make such calls and will be accounted for (but group checks are not executed!).
A technique is to split SER in two proxies -- general-purpose proxy and gateway barrier proxy. The gateway barrier would avoid risky logic such as DNS resolution and do simply its ACL job.
Other rechnique an esteemed seruser deployed is to insert a secret prefix in SER to URIs considered to go to gateway and only accept such at the gateway. (I haven't given it a try yet, I would have to see if we need some extra work to mangle the prefix if it appears in gateway's contacts. Otherwise callers may be tempted to learn and upload or provision such contacts.)
-jiri
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Could another simple solution for this be to simply put the gateway on a different UDP port? For example SER listens on 5060 and the gateway on 5090. That way if the request is forwarded because of a DNS resolv, then it is forwarded to the wrong port and there is no harm done.
Hi!
Andres wrote:
Could another simple solution for this be to simply put the gateway on a different UDP port? For example SER listens on 5060 and the gateway on 5090. That way if the request is forwarded because of a DNS resolv, then it is forwarded to the wrong port and there is no harm done.
Good idea, but a bad boy can create an ENUM entry which points to the GW to port 5090, and if ser is configured to try ENUM .... same problem.
Klaus