-----BEGIN PGP SIGNED MESSAGE-----
Matt> Date: Thu, 7 Nov 1996 14:04:10 -0500 From: C Matthew Curtin
Matt> <cmcurtin @
research .
megasoft .
com> Subject: Re: re:Security
Matt> Risks with Real Audio?
>>>>> "Chris" == Chris Carlson <carlson @
cycon .
com> writes:
>>>>> "Matt" == Matt Curtin cmcurtin @
research .
megasoft .
com
Chris> 2) Use RealAudio's proxy for firewalls
Matt> How does proxying UDP overcome the problem of opening
Matt> yourself up to UDP? You're still allowing UDP to come in. It
Matt> doesn't matter whether it's coming over proxy or not... The
Well, with an application layer proxy, you are opening *specific*
UDP ports. In theory, you should be able to check that the originating
address is the same as the destination of the TCP control
connection. I wasn't able to get this statement out of the Progressive
Networks folks: I got the impression that maybe they have some kind of
load balancing system whereby the packets might originate from *other*
IP addresses planned. (I sure hope not)
The destination address is either the firewall or the internal node
(depending on whether NAT is occuring), if it isn't then you discard
the packet (or the kernel does). No matter what, you send to the
specific node that is in control of that connection.
So, in effect, the RealAudio proxy is really no worse than the
traffic-aware (%) application layer FTP proxy.
All of this doesn't really stump the good kracker: they just make
sure that all the headers are correct. It does however, render any
attack into "mere" denial of service (assuming that the raplayer has no
backdoors). The kracker doesn't get to scan your NFS ports, or find
out who's talkd is broken, etc...
Since the application layer firewall also makes sure the checksum is
correct, and formats the headers again, all extra "options" and any
covert data hiding after the UDP packet are discarded.
Chris> 3) Get a firewall that supports UDP-based RealAudio
Matt> ...so that you can open yourself up to any incoming-UDP
Matt> problems in a more automated fashion?
I suspect, Matt, that you've only ever seen the so called "stateful"
packet filters.
Matt> The only really safe (how you define "safe" will depend on
Matt> whom you ask) way to deal with UDP is to do so in a stateful
Matt> packet filtering mechanism, whereby the packet filtering
Matt> rules will be dynamically changed to allow incoming UDP from
Matt> outside hosts only if UDP packets from an inside host has
Matt> gone that way, and could be expecting a reply via UDP.
How can you do this with RealAudio? The player never sends out any
UDP packets. Apparently a newer version of the protocol *does* send
UDP out, but the number of packets expected in response is not
defined.
Matt> http://www.research.megasoft.com/people/cmcurtin/ I speak
Matt> only for myself. Hacker Security Firewall Crypto PGP
Matt> Privacy Unix Perl Java Internet Intranet
(%) see http://www.milkyway.com/People/Michael_Richardson/proxyrating/proxyrating.html.
:!mcr!: | Network security consulting and
Michael Richardson | contract programming
WWW: <A HREF="http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html";>mcr @
sandelman .
ottawa .
on .
ca</A>. PGP key available.
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2i
iQBVAwUBMoKib9TTll4efmtZAQH1IgH9HwutsXdt/J6BOhllHA7xD0L2fEMfvKzg
aWLE2ueGrN40vWWM6OABlBuIoTdBh6CBZhhCFLpfJ9wHRWbWG9/EIA==
=m/Ap
-----END PGP SIGNATURE-----
Follow-Ups:
|
|
