[SR-Users] loose_route security

[Daniel-Constantin Mierla]

Hello,

On 4/11/11 12:23 PM, Klaus Darilion wrote:
>
> Am 11.04.2011 10:17, schrieb Alex Balashov:
>> On 04/11/2011 03:25 AM, Klaus Darilion wrote:
>>
>>> Thus: Check for to-tag. This is how you can differ out-of-dialog
>>> requests from in-dialog requests. Only if the to-tag is present, call
>>> loose_route().
>> I suppose in principle the problem here is that has_totag() only checks
>> if there is *a* To-tag, not whether it is a valid To-tag associated with
>> a known dialog.
> Yes, that's the disadvantage of a transaction-only stateful proxy.
>
> Takeing a look at the previous problems with dialog module, and the
> recent problems, I prefer to not use dialog module even in the case
> someone my abuse my proxy as reflector. ;-)
first, skipping authentication for within dialog requests in default 
configuration file comes mainly from the early years when not many sip 
endpoints supported that. But can be done, of course and perhaps it 
should be enabled (or at least added as a #!define option).

We all know that Kamailio has a programable configuration file, the 
default one is given to address most common (and basic) needs and be a 
reliable starting point to add more actions to it, but surely can be 
improved a lot in terms of security and features. For example, one can 
tighten the checks by allowing traffic/calls only from registered 
endpoints (checking source IP and port using $ulc(...)) and from trusted 
peers. When allowing traffic from external untrusted networks, then for 
sure you have to analyze and add more security checks.

In Debian-like OS-es, kamailio does not start by default when it is 
installed from packages -- people have to edit the defaults file for it, 
making in this way sure that the admins at least know they started the 
service -- hopefully, also they understand what the config is doing.

To ship kamailio with most secure config it would be very easy, here it 
is that one:

route {
   exit;
}

Then let the people build from this one so they are fully aware of what 
they add there :-) ...

Regarding dialog states, it is not really needed to use dialog module, I 
use a lot htable for this purpose -- using call-id and the tags to build 
the keys, you can track lot of attributes, as you need, e.g., the IP 
addresses, auth state, a.s.o.

Cheers,
Daniel

-- 
Daniel-Constantin Mierla
http://www.asipto.com