> I am currently looking into killing the MP3 Program Napster.
>
> A user told me that he had been using it inside the firewall to
> download files on an external Napster server. He assumed he was safe
> because he was behind the firewall, but soon discovered that other
> users were downloading from his machine. My guess is that Napster
> establishes a connection from client to server that is used for
> uploads AND downloads. So, the burning question is, has anyone
> blocked Napster by specifying the destination port (which I haven't
> figured out yet) going out? I am not running an application level
> firewall, so I can only do it by port.
Napster isn't a "client/server" system so much as it is a "peer pool
with a common directory service" system. I think of it as a system of
end-user agents (the app you download from napster.com) which uses the
index/directory/state servers run by napster.com to discover and
broker holdings, locations, and connection-method information with
other folks' end-user agents. A Napster end-user agent is capable of
both accessing others' files and providing its own files to others (as
well as doing chat, but that's ususally not what people are worried
about with Napster).
Blocking by bulk-transfer port doesn't work - the transfer ports are
user-configurable without any penalty on the effectiveness of the
end-user applications as either clients or servers. Perhaps you've
already discovered that the transfers can be initiated from either
direction. :-( And the direction that "works" is
auto-discovered/-negotitated by the end-user agents.
Blocking access to the napster.com nets to prevent communications with
the directory services agents is partially effective, until your users
discover one of the (reportedly growing) number of ad-hoc public SOCKS
proxies for the directory services.
Napster is a fiendishly difficult application to try to defeat by
means of anything other than discovery and subsequent draconian
application of policy (ahem). You gotta give the guys who put it
together credit - it does what it does (which is fairly unique) in a
*very* robust manner.
If sucking bandwidth isn't against the local network policy, your user
could perhaps configure his end-user-agent to have an upload directory
which is always empty.
Best of luck.
-jml
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:04:07 PDT