[VOIPSEC] RE: SBC security/pen testing

[Geoff Devine]

In many cases, a service provider has no control over the routers that could enforce anti-spoofing rules.  Personally, I think it's too risky to allow attackers to direct a huge ICMP hose at a corporate VoIP network and it's better to silently ignore packets received on dead ports at an SBC.  I guess the best approach would be for the SBC to limit the rate of ICMP messages it sends.  That way, an endpoint that errantly has an RTP or RTCP stream up can be told it's doing the wrong thing.  In my experience (limited to maybe a half-dozen devices where I've looked), cheap SIP phones ignore ICMP so I'm not sure what good it does.
 
In PacketCable, RTCP is profiled to limit it to passing performance data (extended reports).  RTCP is supposed to be authenticated and encrypted though security is typically not turned on at the moment.  If you don't adopt a similar strategy on all implementations, you have a big vulnerability.  An SBC really doesn't help since an attacker could sniff traffic between the endpoint and the SBC.
 
Geoff 

________________________________

From: Christopher A. Martin [mailto:chris at infravast.com]
Sent: Fri 4/29/2005 12:39 AM
To: Geoff Devine; Voipsec at voipsa.org
Subject: RE: [VOIPSEC] RE: SBC security/pen testing



True, but hopefully security indepth is practiced... anti-spoofing rules
implemented at the router... a firewall, and, if a port isn't listening
(since there isn't a valid session associated with it, the proper
response should be icmp port unreachable...no need to make it to the
application layer if the application wasn't listening after all.

SIP on the other hand, or whatever signaling protocol is implemented, is
where the risk lies, also any actual active media session.

An active media session that is not protected by the SBC on the basis of
the call signaling then all bets are off...it may be possible to divert
traffic using the media mechanisms (RTCP) to pull it or any other attack
off.

If the media session is based on signaling then only the session may be
at risk of DoS or misdirection based on RTCP.

Just a thought.

-----Original Message-----
From: Voipsec-bounces at voipsa.org [mailto:Voipsec-bounces at voipsa.org] On
Behalf Of Geoff Devine
Sent: Wednesday, April 27, 2005 7:18 AM
To: Voipsec at voipsa.org
Subject: [VOIPSEC] RE: SBC security/pen testing

It depends on implementation strategy.  A Session Border Controller may
very well treat messages to ports that don't have known flows on them as
attacks.  If that's your strategy, it's better to dump the messages on
the floor rather than generate responses for each message and inject
work into the network.  If the source of those messages is spoofed, you
can actually use an SBC to mount an attack that traverses some other
firewall that has policy to trust anything that comes from the SBC.
This is a pretty common topology for VoIP hosted PBX environments where
the SBC is owned by some service provider.  SBCs typically support at
least wirespeed GigE so an attacker could direct a really big hose that
would kill any host sitting behind that corporate firewall.  An SBC
isn't a host so you shouldn't necessarily expect it to behave like one.



Geoff

---------------------------------------------------------------

Subject: RE: [VOIPSEC] SBC security/pen testing
To: "'Geoff Devine'" <gdevine at cedarpointcom.com>, <Voipsec at voipsa.org>
Message-ID: <000001c549f0$ae8cd110$6403a8c0 at home1>
Content-Type: text/plain;       charset="us-ascii"

Not necessarily...

Much like a firewall, those ports should be listening for specific
endpoints...other hosts probing those ports should receive a port
unreachable message...

The ports should only be dynamically listening during the time that they
are required for use as signaled by the signaling protocol for the
respective endpoints that are part of that dynamic session.

If we rely on static rules or listening ports there will be no security
and a full high risk scenario waiting to happen.