From: Church, Chuck (cchurch@xxxxxxxx)
Date: Fri Feb 15 2002 - 16:58:54 GMT-3
Thanks. Glad my layer-4 predicament is interesting. I might need to go to
a Cyber-Patrol like software maybe.
Chuck
-----Original Message-----
From: Brant Stevens [mailto:branto@myrealbox.com]
Sent: Friday, February 15, 2002 2:49 PM
To: Church, Chuck; 'Sam Munzani'; Jason Gardiner; ccielab@groupstudy.com
Subject: Re: OT: Any way to block streaming audio/video?
Any chance of setting the clients to use an HTTP Proxy to provide Internet
connectivity? That's the only thing I can think of... but it seems as
though a proxy may not even help since the data request comes in as a
properly-formatted HTTP request. I think that it may beyond the
capabilities of NBAR.
You may need a 3rd party product that hooks into a Checkpoint Firewall as a
CVP...
-Brant.
PS. Congratulations to you Chuck. I have been on this list for a while,
and have always found your questions to be helpful in evaluating my own
understanding of a topic.
----- Original Message -----
From: "Church, Chuck" <cchurch@USTA.com>
To: "'Sam Munzani'" <sam@munzani.com>; "Jason Gardiner"
<gardiner@sprint.net>; "Church, Chuck" <cchurch@USTA.com>;
<ccielab@groupstudy.com>
Sent: Friday, February 15, 2002 12:54 PM
Subject: RE: OT: Any way to block streaming audio/video?
> 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