ISDN GW 3241 - SIP security

[epicolo]

Does someone know if it is in roadmap an improvement on SIP settings/security in the ISDN GW 3241?

We where checking the config and we couldn´t found a way to configure the GW (version 2.2(1.79)P to use SIP and avoid undesired usage.

When the Dial Plan (IP to ISDN) is configured as Any or SIP, there is no configuration in the GW to don´t accept calls from any device that sends an INVITE.  It should be a SIP trunk configuration, to stablish a relationship with it pair (only accept call form SIP trunk sources, certificates, etc).

Any idea?

This is impacting a customer (goverment) deployment.

Thanks

[Martin Koch]

I would recommend putting it in a DMZ and limit access to the h323 and sip signaling ports allow access only

by the call control and limit it to what you want.

Asking your ISDN provider to block by outbound destinations or after a max. money limit might also be a handy idea.

Further access control by the isdn gw looks like a feature request.

[natroxby]

Hi Elter,

Martin is correct here and has a good recommendation.

The ISDN GW has not been designed with a specific function to also as a call control device, this is predominantly the function of the VCS. The ISDN GW "call control" options are really limited to the dial plan where the action is configured to reject the call based on the incoming calling protocol, incoming call type and called/calling number matches fields.

If you are interested in seeing further call control features on the ISDN GW a feature request is definitely the best course of action.

Thanks.

[epicolo]

Tks Martin.

Nathan, Martin´s recommendation is a workaround that should help to avoid undesired usage.

The question here is not a call control on ISDN GW, it is a lack of security on the GW itself.

Lets use the VCS E as an example:

If you put it on internet and enable SIP/H323, the system will accept any invitation, but you can configure internal rules (Firewall and/or CPL, Search Rules, etc). It "need" to be open for everyone to do its job.

When you enable the SIP on the ISDN GW (you need to do so to use with CUCM without extra conversions or boxes), there is no way to deny any attempt to use the GW. Any device that send an INVITE to the GW can make a call.

SO, for me, this is a security failure. The system is not capable to make a simple source IP control using a SIP trunk configuration or something else.

Regards

[Martin Koch]

The DMZ and the port blockage is like you noticed critical by today.

The biggest security failure is to deploy it somehow (public or unwanted internal) reachable without the above.

But yes I fully agree with you Elter, the more levels of security the better,

its easy to get very expensive, very fast :-/

The best way is to have multiple layers of security and some could be already on the IPGW:

* firewall to block unwanted ip

* trust/block lists for remote-ip, domains, numbers, country codes, ...

* only allow from/to calls when registration to that ip is present

* rate limit per ip / uri / numer / trunk

* intrusion detection (like alert if many call attempts made or a first rate limit threshold is reached)

* auth users via pin code

* accounting of calls

* ...

So for now the feature request (talk to your Cisco Partner / Representive)

Again there are additional external levels as well

* usage of DMZ

* usage of call control

* check cdrs & logfiles on a daily  bases

* check with isdn-provider for limits / reporting from their site

* use access codes / pin numbers

* check for flaws like hairpinning / external dial through (voip2isdn but also isdn2isdn)

* ...

and so on, ...

Elter: please rate the answers! (and set the thread to answered if it is, even if you do not like the answer :-)

[epicolo]

Hi Martin,

i´ll mark as answered, but my first question wasn´t answered: If someone know something about future security improvements in ISDN Gateway (roadmap).

Thanks

[Martin Koch · Accepted solution]

Ok. Thank you for tagging the answer (Sure rating would also be appreciated :-)

Besides that sometimes some roadmap info is mentioned here I would not expect or wait for it

as its a public forum but roadmap info is often under NDA.

I would recomend to talk to your Cisco Partner / contact and see if you can get a roadmap talk

and also note down for them the impact for your deployments and possible feature requests.

Hope that answered your question :-)

Martin