[VOIPSEC] Actual Attacks
Ken Peterson
kapnet at mindspring.com
Fri Feb 25 09:40:11 CST 2005
Yes.. an excellent exchange all... thanks.
The scenario you described can be seen in product form at:
http://www.ingate.com/siparatorwork.php
To moderator:
Do you consider a discussion of product experience appropriate for this
forum? In this case, I would be curious if anyone else has experience with
this product I can benefit from.
(I have no relationship with this organization)
Cheers,
Ken
****************************************************************************
********
* *
* Ken Peterson, CCIE 4297 * Cisco Certified Security Professional
* PacketBrain, Inc. * Cisco IP Telephony Support Specialist
* Cary, NC 27511 * Cisco Content Networking Specialist
* *
****************************************************************************
********
-----Original Message-----
From: Voipsec-bounces at voipsa.org [mailto:Voipsec-bounces at voipsa.org]On
Behalf Of Christopher A. Martin
Sent: Thursday, February 24, 2005 9:50 PM
To: 'Brian Rosen'; 'Simon Horne'; voipsec at voipsa.org
Subject: RE: [VOIPSEC] Actual Attacks
This was an excellent exchange. Thank you.
I have a couple of ideas and comments.
I have been going back to the PGP concept and actually have seen a potential
gateway solution for enterprises that is used for email (which supports
SMIME, etc. in a more transparent and semi scalable manner than in the past,
using an appliance built by PGP [Great work from what I can see, kudos PGP])
that could also work for SIP on the same level, even though it is still as
cumbersome as those pesky firewalls and SBC's.... just kidding.
The product is PGP Universal... I believe the same type of solution could be
created with GPG with a focus on SIP... but that is just me thinking aloud
and in print....
As for the SBC/Firewall scenarios...I actually support the idea of not a
parallel solution but a DMZ solution which can be met with some degree of
support by many business class networks as well as carriers. By placing the
SBC in the DMZ and still allowing the firewall to enforce security and
maintain logging you satisfy many of the enterprise concerns. In the case of
NAT you would implement static NAT for the SBC, in the case of non nat you
merely implement rules for SIP...sort of like this in very loose Cisco
speak....
First avery basic diagram....
/-------------\
| Internet |
\-----+-------/
|A
/---+----\ B DMZ NET /---------\
|Firewall +-----------+ SBC |
\---+----/ E \---------/
|C
/-----+-------\
| Internal |
| Network |
\-------------/
In this scenario we are implementing what I call a one legged SBC, since we
are compromising and placing it inside the realm of a firewall DMZ, normally
I would implement as I would a firewall with one or more interfaces (DMZ's).
Applied to interface A for inbound traffic
permit tcp any E eq 5060
permit tcp any E eq 5061
permit udp any E eq 5060
permit udp any E eq 5061
permit udp any E range <range of RTP/RTCP ports configured on the SBC>
Applied to interface B for outbound traffic (inbound to the firewall)
permit tcp host E eq 5060 any
permit tcp host E eq 5061 any
permit udp host E eq 5060 any
permit udp host E eq 5061 any
(for management - I require SSH for managing devices or SNMPv3)
permit tcp host E <internal-network> eq 22
permit udp host E <internal-network> eq 161
Applied to interface C for outbound traffic from internal network (inbound
to the firewall)
permit ip any any
The internal rules may be more restrictive on many carrier or enterprise
networks so then you would have to adjust to meet the policies for the DMZ
but you get the picture... assume that all outbound traffic responses are
permitted back into the firewall reflexively (on a router use reflexive
ACL's)
Just an example, not meant to be comprehensive....
This typically will satisfy the isolation and security requirements of many
installations, but the assurance has to exist with the SBC to be robust
enough to ensure security is not compromised by rogue clients... this also
goes for SIP aware firewalls, otherwise you have nothing more than an
approved covert channel.
The only part sometimes frowned on is the use of ANY but since we have a
single (or pair) of hosts in the DMZ this helps to allieviate those as well.
:)
Christopher A. Martin
P.O. Box 1264
Cedar Hill, Texas 75106
Chris at InfraVAST.com
> -----Original Message-----
> From: Voipsec-bounces at voipsa.org [mailto:Voipsec-bounces at voipsa.org] On
> Behalf Of Brian Rosen
> Sent: Thursday, February 24, 2005 12:12 PM
> To: Chris at sip1.com; 'Simon Horne'; voipsec at voipsa.org
> Subject: RE: [VOIPSEC] Actual Attacks
>
> So, before the specifics, an opportunity to vent:
> <rant>
> I've been involved in work that seeks to allow distributed teams of people
> to work cooperatively with one another while separated by distance. My
> team
> has produced tools which are quite effective. One of the interesting
> aspects of "effective" is how you define it. Our definition is "you
> behave
> the same using the tool as you do when you are in the same room with your
> team". We have also sought to use tools produced by others to expand our
> own work.
>
> In the 6 or 8 years I've been working on this problem, we have had exactly
> two sustained, relatively unsolvable-by-us problems. One is the cost of
> bandwidth. It was dropping like a stone, but it hasn't been lately.
>
> The other is the "security teams" in the enterprises where we worked
> (sorry
> Britt).
>
> These guys have stopped us cold. They simply will not allow us to deploy
> the tools.
>
> Let me get into a specific. One of the most effective tools out there is
> the applications sharing tool in Netmeeting. It's been out, available,
> and
> free for 10 years. Yet, today, 90% of the deployed firewalls stop it.
>
> So, what have we done? I'll tell you what we did; we changed the protocol
> to HTTP, that's what we did. See WebEx.
>
> WebEx is not quite as good as Netmeeting, and it costs a heck of a lot
> more,
> but it goes through the firewall because it runs on HTTP.
>
> Is that the right answer? NO! It is the wrong answer. HTTP is not an
> appropriate protocol for real time application sharing. The result of the
> stupidity of not allowing dynamic UDP ports running T.120 in any
> reasonable
> way is to force people to get on planes and fly to meetings rather than
> sit
> in their office and have the meeting distributed (or pay through the nose
> to
> make an end-to-end problem a service provider business opportunity while
> bypassing the firewall).
>
> I'll go farther. Firewalls are a very bad idea. They have become a
> crutch
> that has two significant, unfixable problems:
> 1. It breaks end to end connectivity that is the basis of the
> Internet
> 2. It provides a convenient short cut to avoid fixing problems
> The latter is the real issue. The former is just a consequence. By using
> the firewall to stop known attacks, you push off the need to fix the
> endpoints. That's a bad approach because there is always a back door.
> WebEx is an example of a back door. IP over HTTP is available.
>
> The right way is to fix the endpoints. We're dealing with this in IE and
> Outlook and ..., because the firewalls don't stop the problems. We should
> deal with it in all the applications. I know it sounds harder, but
> actually, these days, it's not really. We should give up on walled
> gardens.
> It's getting too easy to breach the walls. We should deploy systems that
> are secure end to end (although getting that with a hop by hop mechanism
> is
> more likely).
>
> The security teams must hate the fact that VoIP is a reality in most
> enterprises that are upgrading their phone service. They haven't gotten
> to
> the real problem yet, but they are about to. VoIP peering is coming on
> fast. That means instead of just having to allow VoIP within the
> enterprise, they have to allow it between enterprises. And that traffic
> is
> all going to be SIP. SIP is the interchange protocol for domains that do
> not have bilateral arrangements. All carrier peering is going to SIP.
> They
> may accept H.323 at the boundary (SBC), so the enterprise could maintain
> all
> H.323 interfaces, if they are content to pay carriers to make all their
> interconnections. But, like Email, why would they? If you can make a SIP
> call over the Internet, and you can receive one, why would you pay a
> carrier
> to connect you to someone else who can do that?
>
> </rant>
>
> And now we return to our regularly scheduled program -- comments inline
>
> > -----Original Message-----
> > From: Christopher A. Martin [mailto:chris at sip1.com]
> > Sent: Wednesday, February 23, 2005 11:03 PM
> > To: 'Brian Rosen'; 'Simon Horne'; voipsec at voipsa.org
> > Subject: RE: [VOIPSEC] Actual Attacks
> >
> > I would like clarification regarding your comment below:
> >
> > "> SBCs and firewalls are very unfriendly to any signaling security,
> > because
> > > they want to peer into the signaling, and sometimes alter it. They
> > could
> > > be
> > > more visible in the process; for example, a firewall or SBC could be a
> > > real
> > > SIP proxy server, in the routing path, and thus be a hop in the TLS
> > path."
> >
> > The fact that an organization or individual places the trust on SIP
> > endpoints, in this case, to basically bypass security measures (which
> you
> > stated are unfriendly to signaling security) is ludicrous to me.
> Maybe so, but if I got a sips: call from a domain who's cert I was
> reasonably sure of, I think I'm a heck of a lot better off than getting a
> sip call that passed someone's firewall.
>
> Firewalls (and SBCs) are unable to do anything really useful with respect
> to
> creating SECURE connections. They hurt. They can stop some kinds of
> problems, but secure connections from an open port are probably a heck of
> a
> lot more useful than insecure connections from a firewalled port.
>
> YMMV.
>
> >
> > Firewalls and border controllers are not merely in place to facilitate
> > VoIP,
> > :) well at least not the former. They are in place to protect the
> > infrastructure from unauthorized use of resources at various levels,
> > whether
> > it is a home user, enterprise application, or carrier service. But they
> > are
> > not the silver bullet either.
> Well, as above, I think they are an ill-conceived crutch. They are there
> however. Denying reality rarely gets you anywhere. If they are there,
> then
> they either have to do one of two things:
> 1. Be an active participant in a TLS hop-by-hop signaling path, so that
> they
> can look at the signaling and do their thing with it. This breaks if
> S/MIME
> is used to protect the end-to-end stuff, but it's better than nothing.
> 2. Pass all TLS protected signaling and sRTP protected media through with
> no
> inspection.
>
> There is a third option, see below.
>
>
> >
> > Firewalls are becoming more intelligent as they evolve to meet the needs
> > of
> > these new protocols and applications and because they have to in order
> to
> > provide the protection that they were originally intended for. They are
> a
> > fact of life that will not go away. IDS's and IPS's are also going to
> have
> > to evolve in this direction too.
> Actually, what I see happening in the wild is that people are deploying
> SBCs
> in parallel with the firewalls, because the firewalls are not evolving
> fast
> enough to keep up. I don't like most SBCs either, but they are being
> deployed. I don't see many firewalls that have full SIP support being
> deployed.
>
> But to reiterate, neither of them correctly deals with secure connections,
> and I have big problems with that.
>
> >
> > SIP and other peer to peer protocols like it pose a very real threat to
> > these environments. The very fact that we developed the enablement of
> > these
> > protocols through these security mechanisms means that the dynamic
> > pinholes,
> > port redirections, and what have you, are now fully authorized conduits
> of
> > whatever mischief can be thought up unless the security mechanism can
> > "peer"
> > into the signaling and/or media to determine authorization and
> > authentication is not being attacked.
> Nope. The idea that you have to "peer" into the signaling is the wrong
> approach. You make the endpoints secure, and depend on them. You can
> never
> make the walled garden secure.
>
> The firewall vendors have not been very supportive of the "midcom" stuff
> that seeks to have intelligent signaling devices be able to tell them how
> to
> open the pinhole. Probably an economic issue, as well as a control-freak
> kind of thing. Reality is that there is no other way to correctly
> determine
> how to open the pinhole.
>
> I'm not a fan of pin hole firewalls, but if you want to do it, do it
> right.
> That means having the endpoint tell you which ports it needs. There is no
> other way, because the intermediaries can't look into S/MIME protected
> SDP.
> Telling me not to protect my signaling with S/MIME is an unacceptable
> answer.
>
>
> >
> > What we have to do is determine how to find the middle ground to an
> > acceptable risk and develop this so that there can be confidence in
> using
> > the applications derived from it.
> Sure, but that means the firewall is active, and not passive, if it is
> there
> at all.
>
> >
> > Signaling security should also be designed with these things in mind,
> not
> > just the other way around...infrastructures are built of many
> components,
> > some are standards based, and some are for survival. You have to look at
> > the
> > whole picture.
> Well, in some sense I agree with you. For some time the signaling
> protocol
> folks have been wishing firewalls and NATs would go away, and designing
> systems that assume they are not there.
>
> But then the firewall guys have not been exactly cooperative about making
> it
> possible to do the right thing, as above. Endpoint signaling of pinholes
> for example.
>
>
> Brian
>
>
>
> _______________________________________________
> Voipsec mailing list
> Voipsec at voipsa.org
> http://voipsa.org/mailman/listinfo/voipsec_voipsa.org
_______________________________________________
Voipsec mailing list
Voipsec at voipsa.org
http://voipsa.org/mailman/listinfo/voipsec_voipsa.org
More information about the Voipsec
mailing list