From: Sam Munzani (sam@xxxxxxxxxxx)
Date: Fri Feb 15 2002 - 14:23:43 GMT-3
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