HDTenEightyP/NetNews huggingface dataset:
From: wls@cray.csd.uwm.edu (Bill Stapleton)
Subject: Re: How to control permissions on incoming FTP?
Reply-To: Bill Stapleton <wls@csd4.csd.uwm.edu>
Organization: Computing Services, U of Wisc-Milwaukee
Date: Thu, 30 Jul 1992 16:57:26 GMT

In article <1992Jul30.070925.23754@spdcc.com>, dyer@spdcc.com (Steve Dyer) writes:
> Until I made the (simple) change to ftpd, I maintained a writable
> directory accessible via anonymous FTP.  One day I was amused (surprised
> is too strong a word) to discover that said directory was being used as
> a world-wide rendezvous point for porno GIF seekers and providers: there

We've also had this problem.  There's a way to restrict this usage by using
directory permissions.  We have an incoming directoy that's writeable by
anonymous ftp only, but readable by everybody except anonymous ftp.  We also
have the usual pub directory, readable by everyone and writeable by everyone
except anonymous ftp.  An "ls -l" looks like this:

-rw-r--r--  1 root         1592 Mar 23 17:44 Policy
dr-xr-xr-x  2 root          512 Oct 24  1991 bin
dr-xr-xr-x  2 root          512 May 13 20:12 etc
d-wxr-xr-x  2 ftp           512 Jul 17 14:54 incoming
dr-xrwxrwt 20 ftp          1024 Jul 28 09:11 pub

So, an anonymous ftp user can drop something off in "incoming" that everyone
on our system can read, but other anonymous users can't see it.  They can
only see the things that our users place in the "pub" directory.

This worked fine until one of our vendors (I won't mention Convex by name :-)
changed "ftpd" permissions taking away world read on newly written anonymous
files.  This "security" change makes anonymous ftp pretty useless, except as a
dumping ground described above, since nobody on our system can read the files.
Thanks guys.  :-)

--
Bill Stapleton
     wls@csd4.csd.uwm.edu
     uwmcsd4!wls
Xref: sparky comp.protocols.tcp-ip:3944 comp.dcom.sys.cisco:1004
From: art@acc.com (Art Berggreen)
Newsgroups: comp.protocols.tcp-ip,comp.dcom.sys.cisco
Subject: Re: Multiple Subnets and Non-byte boundary netmasks
Date: 31 Jul 92 20:15:08 GMT
Organization: ACC, Advanced Computer Communications

In article <1992Jul31.170907.23562@nstn.ns.ca> daniel@nstn.ns.ca (Daniel MacKay) writes:
>In <1992Jul24.160634.5645@acc.com> art@acc.com (Art Berggreen) writes:
>>The only problem I can think of right now with non octet aligned masks,
>>is that some older host TCP/IP implementations would only take octet
>>sized chuncks on netmasks.
>
>That's what everyone *says*.  Does anyone have a list of these noncompliant
>entities?  or is it just one of those net.legends that will be with us
>forever?  I have worked with my share of devices in the past couple of
>years, and a lot with 27 and 28 bit subnet masks, and haven't found
>anything out of sorts.

I do seem to recall an implementation that only allowed assigning netmasks
of Class A, B or C formats (but don't remember what system).

This could well be more of an urban legend that a real problem.  I don't
recall having any problems with netmasks in the past couple of years.
But I still do occasionly see very limited implementations of TCP/IP.

I'm willing to declare it a non issue unless someone can produce a system
with the problem.

Art
Newsgroups: comp.protocols.tcp-ip
From: kbridge@magnus.acs.ohio-state.edu (Doug Karl)
Subject: Re: Firewall usage (was: Re: ping works, but ftp/telnet get "no route)
Organization: The Ohio State University
Date: Sun, 26 Jul 1992 10:08:25 GMT

Folks,  I have recently released for annonymous ftp an IP, DECNET, AppleTalk,
etc firwall.  It is in the form a bridge similar to PCBRIDGE called
KarlBridge.  If you get a chance please pick it up and let me know what
you think.  (Also an inexpensive version is available from a real company
with support and all that stuff).

OSU KarlBridge can be found on: nisca.acs.ohio-state.edu (128.146.1.7)
 /pub/kbridge

FROM THE BROCHURE:

The OSU KarlBridge is a full featured protocol filtering bridge for Ethernet.
It has the most extensive filtering capability of any bridge or router
available.  It will filter packets by any Ethernet protocol or Ethernet
address and also IP Socket (incomming and/or outgoing), IP address, IP Subnet,
AppleTalk Server Name, AppleTalk Zone Name, DECnet Object and DECnet address.

Features:
	1) Ping'able with SNMP support for MIB-II, Ethernet-like Interface MIB,
	   and Bridge MIB.
	2) Can be configured to filter specific packets by protocol, address
	   server name and zone name by the use of easy to understand menus.
	3) Provides protection against erroneous Ethernet packets, that a
	   standard bridge does not provide.
	4) Leaks are greatly reduced compared to standard bridges, due to
	   unique filtering and timed-learning algorithms.
	5) Works on any Thin or Thick Ethernet with 10BASE-T optional.
	6) Very good packet forwarding rate; 8100 packets per second.
		(If you choose to use your own clone this may vary)
	7) Excellent packet forwarding delay; 140 uS (for small packets)
		(If you choose to use your own clone this may vary)
	8) Easily upgraded, since the code and filters are on standard PC
	   compatible bootable floppy.

Any questions....  Send e-mail to kbridge@osu.edu

Doug Karl
Senior Computer Specialist
Ohio State University
From: dyer@spdcc.com (Steve Dyer)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: How to control permissions on incoming FTP?
Date: 30 Jul 92 05:23:40 GMT
Organization: S.P. Dyer Computer Consulting, Cambridge MA

In article <51690@drilex.dri.mgh.com> dricejb@drilex.dri.mgh.com (Craig Jackson drilex1) writes:
>Is there any way, using the standard ftpd which one might receive with
>Ultrix or SunOS, for example, to control the permissions on incoming files?
>I just did a sample put (from a PC), and the file was stored with
>permisions of rw-rw-rw- (wide open).
>
>I can't find anything in any manual that describes how this might be done.

Use the source, Luke.  FTP source is available everywhere, and
the change is trivial (a judiciously placed umask call).

-- 
Steve Dyer
dyer@ursa-major.spdcc.com aka {ima,harvard,rayssd,linus,m2c}!spdcc!dyer
From: oberman@ptavv.llnl.gov
Newsgroups: comp.protocols.tcp-ip
Subject: Re: SMTP mail
Date: 29 Jul 92 16:30:24 GMT

In article <92211.092548KKEYTE@ESOC.BITNET>, KKEYTE@ESOC.BITNET (Karl Keyte) writes:
> 
>   14rticle <1992Jul29.021534.6708@mp.cs.niu.edu>, rickert@mp.cs.niu.edu (Neil
> Rickert) says:
>>
>>In article <92209.190519KKEYTE@ESOC.BITNET> Karl Keyte <KKEYTE@ESOC.BITNET>
>>writes:
>>>
>>>The SMTP has recently been removed at our site because of its well-known
>>>security hole.
>>
>>  Would you like to enlighten us as to the nature of this "well known
>>security hole".
>>
>>  It is well known that email can be forged.  Most people don't consider
>>this a security problem, although it may present an identification
>>problem.  If you consider email forgery a security hole, then I presume
>>you have also shut off all paper mail, which can just as easily be
>>forged.
>>
> 
> & that's not a security hole?  It is if you want to believe mail that you
> receive.  Paper mail is usually signed.  The point is, SMTP is stupidly
> simple (as we all know) in it's "authentication".  My question still
> stands.

It's hardly a security hole in SMTP. It is a nearly universal problem in
networking and common to virtually all protocols. This INCLUDES paper mail. I
get at least a dozen letters and "official memos" a day of which probably one a
week is signed.

SMTP is rapidly becoming the lingua franca of electronic mail. With the
deployment of MIME, it is likely to displace X.400 in short order. To remove
SMTP because of the possibility of forgery is cutting off ones node to spite
ones face. It's not going away and it doesn't look like anything will replace
it in the next several years. And, because it works so well, noone is even
looking at a replacement (except OSI folk who are pushing X.400).

Now, lets try to look at fixing the problem instead of shooting the messenger!
The only real way to do this is PEM. There are a number of RFCs on the subject
(1113, 1114, and 1115. PEM allows mail to be "signed" digitally to preclude
forgery. It also allows encryption to gaurantee privacy. PEM is available
commercially from at least one source, Trusted Information Systems. While this
is not exportable, I know there are foreign sources which eliminate the
silliness of the US Government.

Please note that all of this still uses SMTP.

And, since the vast volume of mail requires neither privacy or authentication,
I doubt that most E-Mail will use privacy options for some time to come. So
cutting off SMTP merely cuts off your users from 99% of the world. If my sysop
did this in the name of security, I'd wring his neck. (No possibility of this
since I am the sysop.) It's simply stupid.

And, while you're at it, ban paper mail too. After all, it works when it's not
signed, so it may be forged!

R. Kevin Oberman			Lawrence Livermore National Laboratory
Internet: koberman@llnl.gov		(510) 422-6955

Disclaimer: Don't take this too seriously. I just like to improve my typing
and probably don't really know anything useful about anything.
Newsgroups: comp.protocols.tcp-ip
From: beame@maccs.dcss.mcmaster.ca (Carl Beame)
Subject: Re: Econfig question
Organization: McMaster University, Hamilton, Ontario, Canada.
Date: Wed, 29 Jul 1992 01:00:41 GMT

In article <18162.2a742998@ecs.umass.edu> geray@ecs.umass.edu writes:
>Hello Netters,
>Do I have to Econfig a Novell file server if I use ipxodi and odipkt and
>PD applications ? Or Does the file server not need to be Econfiged ?
>Thank you in advance.
>
>Okan Geray
>
	If the FRAME type in the NET.CFG file is in the form

		Frame ETHERNET_II
		Frame ETHERNET_802.3
		PROTOCOL IPX 0 ETHERNET_802.3

then you don't need to ECONFIG the server. If however you have already ECONFIG
it, just change the PROTOCOL statement to: PROTCOL IPX 8137 ETHERNET_II

- Carl Beame
beame@bws.com
From: dls@mentor.cc.purdue.edu (David L Stevens)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: UDP Broadcast - Maximum message size
Date: 29 Jul 92 14:36:35 GMT
Organization: PUCC UNIX Group


	The default BSD code prohibits fragmenting broadcast packets. You
can disable that (with kernel sources) by just #ifdef'ing out the check;
we've run it that way here for years with no noticeable performance problem.
	Diffs below for 4.3 Tahoe sources; replace "PUCC" with a symbol
defined for your site, or change the name to something more descriptive.

*** NEW ip_output.c	Wed Jul 29 09:33:06 1992
--- OLD ip_output.c	Mon Jun 12 23:08:33 1989
***************
*** 156,166 ****
--- 156,170 ----
  			error = EACCES;
  			goto bad;
  		}
+ 
+ #ifndef	PUCC
  		/* don't allow broadcast messages to be fragmented */
  		if (ip->ip_len > ifp->if_mtu) {
  			error = EMSGSIZE;
  			goto bad;
  		}
+ #endif	/* NOT PUCC */
+ 
  	}
-- 
					+-DLS  (dls@mentor.cc.purdue.edu)
Newsgroups: comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
From: joe@eng3.sci.com (Joe LaRocque)
Subject: Wanted: PD Source for rwho
Reply-To: joe@eng3.sci.com (Joe LaRocque)
Organization: SCI Technology, Inc., Huntsville, Al.
Distribution: usa
Date: Thu, 23 Jul 92 18:41:48 GMT

Is there someone out here who would be kind enough to mail a public domain
version of rwho to me? We don't have a full internet connection (we're using
UUCP) so I can't ftp to a site. 

Appreciation is given in advance.

Thanks

Joe La Rocque
SCI, Inc.
Huntsville, AL
From: dyer@spdcc.com (Steve Dyer)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: How to control permissions on incoming FTP?
Date: 30 Jul 92 07:09:25 GMT
Organization: S.P. Dyer Computer Consulting, Cambridge MA

In article <1582elINN9mf@early-bird.think.com> barmar@think.com (Barry Margolin) writes:
>Others have already suggested getting public ftpd source and adding a
>umask() call.
>
>Another solution is to run ftpd via a script that first sets the umask and
>then execs the real ftpd.  I believe the standard BSD telnet just inherits
>its umask from its parent.

That's fine, but it affects all incoming FTP tasks.  Some of your
users might not like such a decision being made for them.  I wanted
a version of anonymous FTP which allowed deposition of files into
a writable 'incoming' directory, but the resulting files would not
be generally accessible to anonymous FTP browsers.  I didn't want
to affect anyone other users of ftp.

Until I made the (simple) change to ftpd, I maintained a writable
directory accessible via anonymous FTP.  One day I was amused (surprised
is too strong a word) to discover that said directory was being used as
a world-wide rendezvous point for porno GIF seekers and providers: there
was even a convention for creating hidden directories in the incoming
directory, one for requests and one for replies.  Files named like
I_want_wandanude.gif in the requests directory would cause wandanude.gif
to appear in the reply directory, and so on.  Ingenious, but not on
my bandwidth...

-- 
Steve Dyer
dyer@ursa-major.spdcc.com aka {ima,harvard,rayssd,linus,m2c}!spdcc!dyer
From: barmar@think.com (Barry Margolin)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Help?
Date: 22 Jul 1992 00:43:23 GMT
Organization: Thinking Machines Corporation, Cambridge MA, USA
Distribution: comp
NNTP-Posting-Host: telecaster.think.com

In article <1992Jul21.112712.12158@kei.is.s.u-tokyo.ac.jp> jeff@is.s.u-tokyo.ac.jp writes:
>So now that I have a connection?  (it didn't complain), I fork a
>reader and writer task.  The writer repsonds to my key presses and
>claims to have written successfully.  The reader ALWAYS immediately
>reports 3 characters whose values when printed at integers are -1, -3
>and 24.  That is all I ever hear from the reader.  I would have
>expected that the getty on the receiving end would say something.  Are
>these chars some sort of handshake that I have to respond to?  What is
>the response?

That's an IAC sequence.  These are sent by TELNET implementations to
implement control operations in the protocol and negotiate options.  That
specific sequence is IAC DO TERMINAL-TYPE, i.e. a request for the client to
send the user's terminal type.  If you don't want to send the terminal
type, you should respond IAC WONT TERMINAL-TYPE.

See the specification of the TELNET protocol in RFC 854.  You should
probably use unsigned characters, so that the values will match the
character codes used in the specification (e.g. it describes that sequence
as 255 253 24).

>All I want to do is pass, *completely* unprocessed characters from
>standard in to the socket stream and from the socket stream to stdout.
>I would really appreciate any help or code :-) you can give me.

If you're going to talk to a TELNET server, you have to talk its language.
And that requires recognizing and acting on control operations in the
protocol.  TELNET isn't just a simple pass-through protocol, it's a virtual
terminal protocol with great flexibility.

-- 
Barry Margolin
System Manager, Thinking Machines Corp.

barmar@think.com          {uunet,harvard}!think!barmar
From: atkinson@itd.nrl.navy.mil (Randall Atkinson)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Terminology for firewalls (was Re: Firewall usage)
Date: 28 Jul 92 00:38:39 GMT
Followup-To: comp.security.misc
Distribution: na
Organization: Naval Research Laboratory, DC

In article <1992Jul26.211639.29453@decuac.dec.com>,
  mjr@hussar.dco.dec.com (Marcus J. "will do TCP/IP for food" Ranum) writes:


>Trusted application gateway - a software gateway for a given application,
>	such as a telnet "forwarder", or relay. Sendmail is a trusted
>	(or at least some versions) application gateway.

  The other terms were OK, but the term "trusted" usually refers to a
component believed not to compromise a multilevel security policy
(e.g. Bell-Lapadula).  The overloading of the meaning that the above
proposes is not helpful because it tends to confuse terms used in the
same community.

  I would suggest just using "application gateway" instead.

Ran
atkinson@itd.nrl.navy.mil
Newsgroups: comp.protocols.tcp-ip
From: eengelke@sail.uwaterloo.ca (Erick Engelke)
Subject: Re: wanted, traffic monitor with snmp access
Organization: University of Waterloo
Date: Tue, 28 Jul 1992 20:24:48 GMT

 dorl@vms.macc.wisc.edu (Michael (NMI) Dorl) writes:
>|> I have a need for a ethernet monitor that would gather
>|> statistics on all traffic to or from a given ethernet
>|> address for IP traffic with a given IP network number. 
>|> Information must be retrievable with snmp. 
>|> 
>|> What I have in mind would be something like a PC or a
>|> Unix worskstation with an ethernet interface.  The PC
>|> would spy on all traffic on the ethernet and would
>|> select traffic to or from a given set of ethernet
>|> addresses. It would examine the source and destination
>|> IP numbers of this traffic for a set of IP network
>|> numbers (IP addresses anded with a mask would be nice)
>|> and accummulate in/out tarffic stats (bytes plus
>|> packets) for each IP network number.   It would be 
>|> great if the device made this information available via 
>|> snmp router interface mib variables (each network would
>|> be a kind of pseudo interface) but other snmp access 
>|> would be acceptable.
>|> 
>|> The application is to measure the traffic passing
>|> through a router for a set of IP network numbers. 
>|> 

Look around dutepp0@et.tudelft.nl [130.161.144.65], some 
excellent work at the Delft University in Holland has
produced some wonderful freeware applications which do
network monitoring and are SNMP queriable.  Some of the
applications run under DOS, others on Unix. 

Erick

-- 
Erick Engelke					  Engineering Computing
						 University of Waterloo
Waterloo TCP Architect		 erick@development.watstar.uwaterloo.ca
Organisation: European Space Operation Centre (E.S.O.C)
Date: Monday, 27 Jul 1992 10:46:10 CET
From: <MPACE@ESOC.BITNET>
Newsgroups: comp.protocols.tcp-ip
Subject: Brdcast datagram size problem

Hi netters,

we are currently implementing a library, on top of UDP, which supports
reliable broadcast as well as point-to-point transmission.

The implementation is based on the Berkeley socket under SunOS 4.1.2
and tries to hide to the programmers the socket details, providing a more
user-friendly interface.

The problem we have encountered concerns the size of the datagram one
can send using such interface.

In particular, we discovered that we can send datagrams of up to
16KBytes (setting the send buffer size with the SO_SNDBUF socket
option) when we use point-to-point transmission, but we can send ONLY
MUCH SMALLER DATAGRAMS (less than 2KBytes) when using BROADCAST.

In practice, what happens is that the "sendmsg" primitive we are using
returns (in the case of broadcast) with an "message too long" error.

Does anyone know if this is a limitation of the socket interface (in
case of broadcast) ? Or is some of our assumptions wrong ?

Any help will be appreciated. Cheers.

Marco & Andrea.


   Andrea Baldi
   Bitnet  : abaldi@esoc.bitnet
   Uucp    : unido!esoc.bitnet!abaldi

   European Space Agency (ESA)
   European Space Operations Center (ESOC)

   Robert-Bosch-Str 5
   D-6100 DARMSTADT West-Germany

   Phone 0049-6151-902762
   Fax   0049-6151-90-495  Tlx: 419453



-------------------------------------------------------------------------
Marco Pace, Software Engineer
ESOC, Robert-Bosch-Strasse 5, D-6100 Darmstadt, Germany
E-mail: MPACE@ESOC.BITNET
Voice:  +49 (0)6151 903065
Fax:    +49 (0)6151 904065
-------------------------------------------------------------------------
From: J.Crowcroft@cs.ucl.ac.uk (Jon Crowcroft)
Newsgroups: comp.protocols.tcp-ip
Subject: The Protocol
Date: 29 Jul 92 14:54:11 GMT


Evolution dictates:
SGMP (simple gateway management protocol)
SNMP (simple network management protocol)
SMP (simple management protocol)
SP (simple protocol)
P (protocol)

but then what?
:-)

jon 
p.s. of course, we should expect divergent species, such as
MP (managment protocol)
and
M (management)

but since these are neither simple, nor necessarily protocols, they
serve no useful function.
Newsgroups: comp.protocols.tcp-ip
From: rh0083b@medtronic.COM (Roger-Hunen)
Subject: Re: FTP's Kernel and Ipx/Netx compatibility
Keywords: ethdrv, FTP, WD8003e, netx
Organization: Medtronic, Inc.
Date: Wed, 22 Jul 1992 11:11:25 GMT

In article <1992Jul22.031048.27400@news.nd.edu> mandell@bach.helios.nd.edu (Dan Mandell) writes:
>We currently use Hummingbird's Exceed Xwindows product with FTP's TCP/IP
>ethdrv kernal running on top of the wd8003e packet drivers. Works great.
>Except, that I don't seem to be able to run ipx/netx while FTP's ethdrv 
>kernel is loaded.  I have been asked if it is possible to do this - and 
>seem to recall being told by FTP tech support that it can't be done.  But 
>I thought one of the motivations for the packetdrivers was to allow several 
>protocoll stacks to use the same ethernet card (Western Digital) -
>simultaneously, if need be.  Is there something we could do to make this work?
>Is theresomething that would replace the packetdriver that would support 
>a connection to both a unix host and a novell server at the same time.
>Is anybody doing this?

I'm doing this right now! What you need is an IPX that is linked with a
packet driver interface. If you use an IPX linked with a WD8003e driver,
you have two programs that try to control the NIC simultaneously. Needless
to say that this is a safe way to create disaster. Get yourself the archive
NOVELL.EXE (available from omnigate.clarkson.edu) and follow the
instructions to create a new IPX. It works just fine for me.

Regards,
-Roger
(I speak for myself)
Newsgroups: comp.protocols.tcp-ip
From: mjr@hussar.dco.dec.com (Marcus J. Ranum)
Subject: Is someone gatewaying this to a mailing list??
Organization: Digital Equipment Corporation, Washington ULTRIX Resource Center
Date: Fri, 31 Jul 1992 13:39:11 GMT


	Is someone gatewaying this news group into a mailing list? I keep
getting mail from certain clueless individuals' vacation programs every
time I post here.
	Whoever you are: the world at large doesn't *CARE* if you are
on vacation right now. Either make your software work right, or don't
use it.

mjr.
Newsgroups: comp.protocols.tcp-ip
From: gmarzot@mitre.org (G. S. Marzot)
Subject: what is ifnet?
Organization: MITRE Corp.
Date: Fri, 24 Jul 1992 21:05:41 GMT

I need to be pointed in the right direction.
I am setting up a syncronous 256kbit link on a SPARC2 w/ a Sun HSI/S card.
The card claims to support a standard "ifnet" interface to the kernel. The
card also claims to support INR, X.25, and SNA. What I want is basic TCP/IP
services(rlogin, ftp) over the link. Oh, I should also mention that the
link is fairly long delay (~250 msec one way) so we are considering a
variant transport layer protocol, NETBLT. Any info, books to read, source
code to check out , etc. would be greatly appreciated. Thanks in advance
for any help.
-GSM
Newsgroups: comp.protocols.tcp-ip
From: mark@homebase.vistachrome.com (Mark Alexander)
Subject: ftp network programming
Organization: Vista-Chrome Incorporated
X-Newsreader: Tin 1.1 PL4
Date: Tue, 21 Jul 1992 12:55:02 GMT

I am trying to learn how to write a C program which uses the 
socket library to connect to a remote ftp server and negotiate
file transfers.  I am having a bit of a hard time although I
believe I understand a good deal of what needs to be done.

If someone could direct me to a good beginner's book or to some
code which is easy to follow I would appreciate it.  I have the
source to ftp, and rfc959 for ftp, but there's too much I dont
know about the basics. 
-- 

-----------------------------------------------------------------------
      Mark Alexander      alexand@nu.cs.fsu.edu    mark@vistachrome.com
                          Florida State Univ.      Vista-Chrome, Inc.
                          Tallahassee, FL          Tallahassee, FL 
-----------------------------------------------------------------------
From: GJAMES@HUSKY1.STMARYS.CA (GJames)
Newsgroups: comp.protocols.tcp-ip
Subject: TCP/IP info wanted
Date: 21 Jul 92 16:16:21 GMT
Organization: Saint Mary's University

I am lookin for any public domain guides to TCP/IP, IPX, internet protocols.
Is there anything available by FTP

Thanks
Newsgroups: comp.protocols.tcp-ip