From: Church, Chuck (cchurch@xxxxxxxx)
Date: Fri Feb 15 2002 - 14:54:22 GMT-3
I tried that too, but it appears that the streaming servers listen on port
80. Differentiating between legitimate html over http and Media Player
using port 80 seems to be real difficult.
Chuck
-----Original Message-----
From: Sam Munzani [mailto:sam@munzani.com]
Sent: Friday, February 15, 2002 12:24 PM
To: Jason Gardiner; Church, Chuck; ccielab@groupstudy.com
Subject: Re: OT: Any way to block streaming audio/video?
I came across same situation and did it cheap way. I applied an access-list
to inside interface and only permitted required traffic to go out. e.g. 80,
443, 20, 21 etc.
If there is any better way, I would definately like to know about it.
Thanks,
Sam
> I believe that the inbound is multicast/UDP on upper ports and would be
> fairly hard to block. The initial request, however, is sent differently,
I
> believe through TCP. You should be able to sniff the session setup and
block
> that packet, thus preventing the session.
>
>
> On Friday 15 February 2002 10:53, Church, Chuck wrote:
> > Anyone,
> >
> > Has anyone had luck blocking Windows Media Player from streaming
> > audio sites? I've been looking at Sniffer traces this morning, but
don't
> > see anything that NBAR could block. The first packet after the
connection
> > is established looks like this:
> >
> > GET /jazzfmstation HTTP/1.0
> > Accept: */*
> > User-Agent: NSPlayer/7.1.0.3055
> > Host: mediaservices1.webpage-marketing.com
> > Pragma:
> >
no-cache,rate=1.000000,stream-time=0,stream-offset=0:0,request-context=1285
> >6 9540
> > ....
> >
> >
> > After that, every packet coming from the server is interpreted as
> > 'Graphics Data' by Sniffer, but is actually the compressed audio. Any
> > ideas?
> >
> > Thanks,
> >
> > Chuck Church
> > Sr. Network Engineer
> > CCIE #8776, MCNE, MCSE
> > US Tennis Association
> > 70 W. Red Oak Lane
> > White Plains, NY 10604
> > 914-696-7199
This archive was generated by hypermail 2.1.4 : Thu Jun 20 2002 - 13:46:24 GMT-3