Hi!
In many situations it would be useful to verify the destination IP address of a message before sending the message. E.g. I want to make sure that accounting and authentication was applied before sending a request to a gateway.
loose_route and DNS resolving make it impossible to handle all scenarios in the config script. Thinking about the problem I got the following idea: The tm module should, after all DNS lookups, verify the dest. IP against a blacklist (e.g. the GW table from lcr module). If the dest. IP is on the blacklist, the message will only be sent if a certain flag is set. This flag will be set in the config script after all checks (acc, auth...) has been applied.
What do you think about this idea? Any other ideas for this problem?
regards, klaus
Hi Klaus,
I was already considering this feature, from same reasons as you. Attacks may hide behind DNS address IPs of critical components of a platform (like GW).
I was thinking having this in core to be able to use it both in stateless (core) and statefull (tm) mode. My concern is where/how to define the IP black list. If it will be kept in core, will the core populated it (via script??) or module should register IPs to the core list? All this in the idea of being able to do a nice provisioning of the IP blacklist. At this hot spot, any comments/ suggestions are welcomed!
regards, bogdan
Klaus Darilion wrote:
Hi!
In many situations it would be useful to verify the destination IP address of a message before sending the message. E.g. I want to make sure that accounting and authentication was applied before sending a request to a gateway.
loose_route and DNS resolving make it impossible to handle all scenarios in the config script. Thinking about the problem I got the following idea: The tm module should, after all DNS lookups, verify the dest. IP against a blacklist (e.g. the GW table from lcr module). If the dest. IP is on the blacklist, the message will only be sent if a certain flag is set. This flag will be set in the config script after all checks (acc, auth...) has been applied.
What do you think about this idea? Any other ideas for this problem?
regards, klaus
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Bogdan-Andrei Iancu writes:
I was already considering this feature, from same reasons as you. Attacks may hide behind DNS address IPs of critical components of a platform (like GW).
GWs (and any SIP UAs) should reject requests where request uri doesn't designate the SIP UA itself. if they don't, report it as a bug to the manufacturer.
I was thinking having this in core to be able to use it both in stateless (core) and statefull (tm) mode. My concern is where/how to define the IP black list. If it will be kept in core, will the core populated it (via script??) or module should register IPs to the core list? All this in the idea of being able to do a nice provisioning of the IP blacklist.
in order to be useful, blacklist must be kept in a database table, which ser can reload into memory by a fifo command.
-- juha
Hi Juha,
Juha Heinanen wrote:
Bogdan-Andrei Iancu writes:
I was already considering this feature, from same reasons as you. Attacks may hide behind DNS address IPs of critical components of a platform (like GW).
GWs (and any SIP UAs) should reject requests where request uri doesn't designate the SIP UA itself. if they don't, report it as a bug to the manufacturer.
I agree, but is not the case I was referring to. Imagine the following scenario: some user upload as contact or redirect/forward address an uri like "sip:user@somedomain.com"; he can later switch the DNS entry of the domain "somedomain.com" to point to your GW IP. In [Open]SER, the DNS resolve is done when no more scripting is possible, so .... :)
I was thinking having this in core to be able to use it both in stateless (core) and statefull (tm) mode. My concern is where/how to define the IP black list. If it will be kept in core, will the core populated it (via script??) or module should register IPs to the core list? All this in the idea of being able to do a nice provisioning of the IP blacklist.
in order to be useful, blacklist must be kept in a database table, which ser can reload into memory by a fifo command.
again, agree; the question is where to keep the list: in core and the core should export fifo command for reload from file maybe (the core should not be DB dependent)?
regards, bogdan
Bogdan-Andrei Iancu writes:
I agree, but is not the case I was referring to. Imagine the following scenario: some user upload as contact or redirect/forward address an uri like "sip:user@somedomain.com"; he can later switch the DNS entry of the domain "somedomain.com" to point to your GW IP.
In [Open]SER, the DNS resolve is done when no more scripting is possible, so .... :)
this is not a problem, because resolving somedomain.com doesn't rewrite r-uri, which thus arrives to your GW as sip:user@somedomain.com. if your GWs name is not somedomain.com, the GW should reject the request.
again, agree; the question is where to keep the list: in core and the core should export fifo command for reload from file maybe (the core should not be DB dependent)?
if not, then i guess file is the only choice (which is not good).
-- juha
Juha Heinanen wrote:
Bogdan-Andrei Iancu writes:
I agree, but is not the case I was referring to. Imagine the following scenario: some user upload as contact or redirect/forward address an uri like "sip:user@somedomain.com"; he can later switch the DNS entry of the domain "somedomain.com" to point to your GW IP.
In [Open]SER, the DNS resolve is done when no more scripting is possible, so .... :)
this is not a problem, because resolving somedomain.com doesn't rewrite r-uri, which thus arrives to your GW as sip:user@somedomain.com. if your GWs name is not somedomain.com, the GW should reject the request.
That whould be the easiest solution, but:
- Does this work with Cisco GWs? AFAIK not. - Also, often the GW is not under my control. Fixing the problem locally is much easier than discussing the reason of such a GW configuration with other "VoIP experts".
again, agree; the question is where to keep the list: in core and the core should export fifo command for reload from file maybe (the core should not be DB dependent)?
if not, then i guess file is the only choice (which is not good).
I think the blacklist should use ser's DB API. Is it possible to implement this as a separate module?
regards, klaus
Juha Heinanen wrote:
Klaus Darilion writes:
- Does this work with Cisco GWs? AFAIK not.
no, but cisco has officially admitted that it is a bug and given it a bug id.
You never know how long it takes to fix Cisco bugs (-->ENUM lookup).
Further, I'm not sure if this will also be fixed for old equipment (AS5300).
regards, klaus
Hi there,
I agree with Juha's arguments - in actually do not need anything special in order to protect a SIP device, if the device has proper and secure behaviour (rejecting everything that doesn't explicitly have it's address, having the possibility to set IP filters to accept only from selected sources, etc).
But I have a question: are all SIP devices able to act in that way? Look like not even the GW and not even CISCO GW do so. So, not sure how many GW plans to add this security features and when.... :(
And that's only about GW - the idea is to be able to protect whatever SIP device - media servers, billing servers, etc....which never knows how "smart are"...right?
on the other hand, is somebody seeing another applicability for this IP blacklist feature (excepting to protect inner SIP entities) ?
regards, bogdan
Klaus Darilion wrote:
Juha Heinanen wrote:
Klaus Darilion writes:
- Does this work with Cisco GWs? AFAIK not.
no, but cisco has officially admitted that it is a bug and given it a bug id.
You never know how long it takes to fix Cisco bugs (-->ENUM lookup).
Further, I'm not sure if this will also be fixed for old equipment (AS5300).
regards, klaus
Bogdan-Andrei Iancu writes:
But I have a question: are all SIP devices able to act in that way?
perhaps not, but in that case the gw service provider should be held liable for misuse, not the customer. if your gw service provide doesn't want to assume liability, switch to another one. the whole thing becomes a big can of worms if we invent a hack in ser each time devices don't conform to standards.
but go ahead with your plan if you wish ...
-- juha
Bogdan-Andrei Iancu writes:
on the other hand, is somebody seeing another applicability for this IP blacklist feature (excepting to protect inner SIP entities) ?
for example, when you add a header (rpid, p-a, etc.) that contains "sensitive" information you don't want to distribute outside of "trusted" devices, you could add those headers as COND_IF_ON_WHITE_LIST conditional lumps meaning that they would be added only if the destination branch is on the list.
-- juha
Bogdan-Andrei Iancu wrote:
Juha Heinanen wrote:
I was thinking having this in core to be able to use it both in >
stateless (core) and statefull (tm) mode. My concern is where/how to > define the IP black list. If it will be kept in core, will the core > populated it (via script??) or module should register IPs to the core
list? All this in the idea of being able to do a nice provisioning
of > the IP blacklist.
in order to be useful, blacklist must be kept in a database table, which ser can reload into memory by a fifo command.
again, agree; the question is where to keep the list: in core and the core should export fifo command for reload from file maybe (the core should not be DB dependent)?
in the case of gateways, it would be nice, if for example the GW table from lcr can be reused. Maybe by having a paramter in lcr which let the LCR module export the GW IPs to the blacklist of the core.
klaus
-
Bogdan-Andrei Iancu -
Juha Heinanen -
Klaus Darilion