27 Jul
2005
27 Jul
'05
5:58 p.m.
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
27 Jul
27 Jul
6:14 p.m.
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(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
9:56 p.m.
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
10:17 p.m.
Hi Juha,
Juha Heinanen wrote:
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 .... :)
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.
10:38 p.m.
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
11:53 p.m.
Juha Heinanen wrote:
I think the blacklist should use ser's DB API. Is it possible to
implement this as a separate module?
regards,
klaus
Bogdan-Andrei Iancu writes:
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".
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).
3:37 p.m.
Juha Heinanen wrote:
Klaus Darilion writes:
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
- 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.
29 Jul
29 Jul
12:29 p.m.
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:
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
- 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.
30 Jul
30 Jul
2:02 p.m.
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
2:09 p.m.
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
27 Jul
27 Jul
10:40 p.m.
Bogdan-Andrei Iancu wrote:
Juha Heinanen wrote:
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
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.
7058
days inactive
7061
days old
11 comments
3 participants
participants (3)
-
Bogdan-Andrei Iancu -
Juha Heinanen -
Klaus Darilion