[unisog] Chronicle of Higher Ed. article on NetPD

H. Morrow Long morrow.long at yale.edu
Thu Nov 8 00:35:34 GMT 2001

There are some protocols and programs in the file sharing/swapping(/stealing)
category which don't require that the client program be able to act as a
server (e.g. what I call a 'servent' -- have a public IP address and listen
on a TCP or UDP port which can be sent to over the Internet).  Many, if not
most of these programs are 'servents' and, by default, act as both client &
server, accepting connections from other clients wishing to obtain files
(also often being 'shared' by default with the sharing 'community' in some
cases not very explicitly with the user/owner of the PC).

It is possible to design a client (or mode in a client) where the client
connects (e.g. via an outbound TCP connection) out to a server (or a more
'capable'/powerful node on the Internet and then it can advertise its 'wares'
as well as do 'searches' for various media by name/keyword/artist/etc.  In 
this case any file transferred either to or from the client will have to 
pass through another node (some peer-to-peer network actually use this type
of behaviour as a 'feature' to anonymize the clients by passing files and
requests through a network of nodes to attempt to hide the source -- and 
perhaps the ultimate destination).  Users out on the Internet could still
'fetch' files off of the client machine behind a firewall or other network
device blocking inbound network connections by doing it through the Internet
node to which the client is connected (e.g. by a form of "reverse proxy").

Several of these 'impure play' P-2-P clients have a configuration screen where they ask if the
client is 'behind a firewall will doesn't allow connections from the Internet'.

- H. Morrow Long
  University Information Security Officer
  Yale Univ., ITS, Dir. InfoSec Office

Ben Hockenhull wrote:
> On Wed, 7 Nov 2001, Paul L Schmehl wrote:
> > We use NAT in the residence halls.  That's even worse.  At the present time
> > we have no way of verifying who was using a particular IP at a particular
> > time.  So, even if we could ID the user, by the time we did that (by
> > grepping logs for MAC addresses associated with an IP - if the user is
> > still online - there's no logging) and associated their IP/MAC with a name
> > and physical location, they could be in class/eating/at the library/you
> > name it.
> Our entire campus is behind a NAT device, and the only way inbound setup
> connections are allowed is to specifically configure them in our firewall.
> Yet, we've gotten several notifications from NetPD that IPs in our NAT
> pool have infringed, and always with the same Michael Jackson song.
> Folks from the outside *can't* connect to an inside host and grab a file,
> so the only way we could be infringing is if our users are uploading
> files.  So, to say that I'm dubious of NetPD's verification methods would
> be a fair assessment.
> Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4243 bytes
Desc: S/MIME Cryptographic Signature
Url : http://www.dshield.org/pipermail/unisog/attachments/20011107/9975f8e7/smime-0007.bin

More information about the unisog mailing list