HDTenEightyP/NetNews huggingface dataset:
From: smb@ulysses.att.com (Steven Bellovin)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Firewall usage (was: Re: ping works, but ftp/telnet get "no route)
Date: 28 Jul 92 15:36:14 GMT

In article <DRW.92Jul27143657@jordan.mit.edu>, drw@jordan.mit.edu (Dale R. Worley) writes:
> As far as I've seen, much of the problem with firewalls is not that
> they exist, but that they are badly configured.  For instance, I've
> seen firewalls that would allow "inside" users to telnet out, but they
> couldn't rlogin out.  A good firewall should allow everything that is
> permitted and nothing that is forbidden, and so improves security
> without adding any additional burden to proper usage.

There are a number of problems with that notion.  For one thing, what
you suggest is often impractical.  To use your example, how can I
characterize, at the router level, a legal rlogin packet?  About all I
can say is that the outside port number in one direction is 513, and
the inside port number is something less than 1024.  But when such a
packet floats by, the router has no way of knowing that that's really
rlogin.  The *real* definition is that the connection was initiated
from the inside.  Otherwise, the packet could be from a connection
initiated *from* port 513 on a dedicated attacker's machine, and to
some service on an inside machine.  But routers don't keep track of
connections, they look at individual packets.

Higher-level gateways, such as the one we run, can do what you say.
We've consciously decided not to support rlogin for two reasons.
First, in general we don't think that address-based or name-based
authentication is secure, and -- as a matter of principle -- we won't
ask people to trust us when we won't trust them in that regard.  The
second problem is the nature of our gateways.  All outbound connections
from AT&T come one of a very few machines (at the moment, exactly two,
I believe).  We can't vouch for the uniqueness of userids -- there
might be another smb, somewhere within the company, who would have the
same privileges as I would when doing an rlogin through the gateway.
That isn't acceptable.  For that matter, we don't keep track of the
trust level of every internal machine; if you saw an rlogin attempt
from us claiming a userid of ``root'', you'd have no way of knowing if
that was root on a great gronking huge UTS machine in one of our comp
centers, or root on an MS/DOS laptop.  I suppose we could munge the
username field on the rlogin messages, to include the inside host name;
however, that would demand more knowledge of the application protocol
than our gateway currently has.  (We run a circuit-level gateawy.  A
true application gateway, such as DEC's, could do that more easily, I'd
guess.)

UDP applications are even more problematic.  We'd love to support
``talk'', or have higher-level access to Archie.  And we haven't
given up; we have a number of ideas on how to improve our gateways.
We *don't* want gateways -- but we're very certain we need to have them.


		--Steve Bellovin
Newsgroups: comp.protocols.tcp-ip
From: pmetzger@snark.shearson.com (Perry E. Metzger)
Subject: Re: Stopping only incoming TCP connections (was: Firewall usage)
Reply-To: pmetzger@shearson.com
Organization: Lehman Brothers
	<chrisc.21.712446813@ramrod.lmt.mn.org>
	<1992Jul31.074154.4081@medtron.medtronic.com>
Date: Fri, 31 Jul 1992 17:02:03 GMT


In article <1992Jul31.074154.4081@medtron.medtronic.com> rh0083b@medtronic.COM (Roger-Hunen) writes:

>From: rh0083b@medtronic.COM (Roger-Hunen)

>So what you really want is application level proxies in the firewall for
>TELNET, FTP, MAIL etc. Of course this defaults to the 'everything is
>forbidden unless permitted' approach.

Ah, but this is a real pain in the posterior, and breaks the semantics
of many applications. By using intelligent filtering of SYN packets,
socket numbers, etc, you can allow easy addition of new services (such
as WAIS) without needing to write new code or break security.

For extra security, I'm considering building a firewall in which
requests to change filtering can come in on a kerberized TCP service,
and then restricting everything. Users wanting to go through the
gateway would have to explicitly open a "narrow hole" through the
firewall in order to get out, thus eliminating any "random"
connections; the holes would time out after a while if no packets of
the appropriate kind had gone through.
--
Perry Metzger		pmetzger@shearson.com
--
		  Just say "NO!" to death and taxes.
			 Extropian and Proud.
From: smb@ulysses.att.com (Steven Bellovin)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Firewall usage (was: Re: ping works, but ftp/telnet get "no route)
Date: 24 Jul 92 19:10:56 GMT

Let me very strongly second what Marcus Ranum said about the need for
firewalls.  No, I don't want to run one.  However, given the abominable
state of host security, I have no choice.  You can blame software
designers for not paying enough attention to the problem (and certainly,
that's some of the trouble), or you can blame the current state of
software engineering (if all large programs have bugs, then by Murphy's
Law all large network servers have security bugs), or you can blame
lax administration by folks who are more interested in getting their own
work done.  It doesn't matter.  I may or may not be able to keep my
own machine secure (modulo new surprises from the Hole of the Month Club);
I *know* I can't secure the tens of thousands of machines connected
to AT&T's internal networks.

Are their attackers out there?  You'd better believe it.  Skeptics are
invited to ftp dist/internet_security/dragon.{dvi,ps} from research.att.com;
it's a draft of a paper I'll be presenting at the UNIX Security Symposium.

		--Steve Bellovin
Newsgroups: comp.protocols.tcp-ip
From: vadim@cix.compulink.co.uk (Vadim Lebedev)
Subject: No subject 
Cc: vadim@cix.compulink.co.uk
Reply-To: vadim@cix.compulink.co.uk
Date: Wed, 29 Jul 1992 00:04:00 +0000

I want to thank everrybody for helping me to get Van Jacoboson's artcicles
ont TCP/IP optimisations

-----------------------------------------------------------------------
Vadim Lebedev                      |   Kortex International
vadim@cix.compulink.co.uk          |   139-147 av. Paul-Vaillant Couturier
                                   |   93126 La Courneuve - CEDEX, France


Newsgroups: comp.protocols.tcp-ip
From: drw@jordan.mit.edu (Dale R. Worley)
Subject: Re: Firewall usage (was: Re: ping works, but ftp/telnet get "no route)
Organization: MIT Dept. of Tetrapilotomy, Cambridge, MA, USA
	<1992Jul23.142026.20112@sci34hub.sci.com>
Date: Mon, 27 Jul 1992 19:36:57 GMT

As far as I've seen, much of the problem with firewalls is not that
they exist, but that they are badly configured.  For instance, I've
seen firewalls that would allow "inside" users to telnet out, but they
couldn't rlogin out.  A good firewall should allow everything that is
permitted and nothing that is forbidden, and so improves security
without adding any additional burden to proper usage.

Dale

Dale Worley		Dept. of Math., MIT		drw@math.mit.edu
--
What do you mean, *you're* a solipsist?
From: martillo@stars.clearpoint.com (Joachim Martillo)
Newsgroups: comp.protocols.tcp-ip
Subject: IP Directed Broadcast
Date: 30 Jul 92 06:10:16 GMT
Organization: Clearpoint Inc., Hopkinton, MA

On reading RFC 1009 Requirements for Internet Gateways, one finds in
section 4.4 on page 34.  An Internet gateway is permitted, but not
required, to filter out directed broadcasts destined for any of its
locally-connected networks.

If a networks gateways do not filter IP broadcasts and that network
has active loops in its subnet topology, and if someone extern to the
network sends a directed broadcast to that network with a TTL of 255,
the target network could easily suffer a major broadcast storm.

Such a storm would seem a bad thing.  Maybe I am missing something,
but perhaps filterning directed broadcasts should be obligatory rather
than optional.

Joachim Carlo Santos Martillo Ajami
From: bill@prijat.cs.uofs.edu (Bill Gunshannon)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Decnet Packets over Sun Router ??
Date: 21 Jul 92 17:30:59 GMT
Reply-To: bill@platypus.uofs.edu
Organization: University of Scranton, Scranton, PA

In article <1992Jul20.151114.9155@ee.eng.ohio-state.edu>, redmill@ee.eng.ohio-state.edu (Keith A. Redmill) writes:
|> I have a Sun 4 (IPC) with two ethernet cards running as a router for
|> a small subnet.  I would like to install some vax stations under this
|> subnet but Decnet packets don't seem to make it through the sun routed
|> software.  
|> 
|> Can this be done??

NO.

You need to go back and read up some more on DECNET.  
It is definitely not TCPIP.

bill

-- 

     Bill Gunshannon          |        If this statement wasn't here,
     bill@platypus.uofs.edu   |  This space would be left intentionally blank
     bill@tuatara.uofs.edu    |         #include <std.disclaimer.h>   
Newsgroups: comp.protocols.tcp-ip
From: Gary White
Subject: Re: satellite link file transfers
Organization: ARCO
Date: Mon, 27 Jul 1992 19:44:47 GMT

In article <1992Jul27.190345.22868@Arco.COM> Gary White <gwhite@arco.com>
writes:
>Hi-
>Between Texas and Alaska via a satellite -linked communications link, we 
>find that FTP goes awfully slowly.  Has anybody learned how to tune FTP,
>or come up with some other software, to go fast on a satellite link?
>
>Thanks-
>Gary White
>
More information:  this is with a T1 link with two RS/6000 560 machines
both running AIX 3.2;  FTP performance is similar to a 56Kb terrestial
hookup.


Newsgroups: comp.protocols.tcp-ip
From: Gary White <gwhite@arco.com>
Subject: satellite link file transfers
Organization: ARCO
X-Useragent: Nuntius v1.1
Date: Mon, 27 Jul 1992 19:03:45 GMT

Hi-
Between Texas and Alaska via a satellite -linked communications link, we 
find that FTP goes awfully slowly.  Has anybody learned how to tune FTP,
or come up with some other software, to go fast on a satellite link?

Thanks-
Gary White
Newsgroups: comp.protocols.tcp-ip
From: scott@dsg.tandem.com (Scott Hazen Mueller)
Subject: Confusing SLIP problem
Summary: ping works OK, telnet doesn't
Keywords: SLIP, ping, telnet, modems, T1600, T3000
Organization: Tandem Computers Inc., Cupertino CA
Date: Fri, 31 Jul 1992 05:22:42 GMT

I'm having a rather confusing SLIP-related problem, and I'm hoping that
I've just missed something obvious...  The problem is that when I bring
up my SLIP link, I can do ICMP stuff (e.g. ping, or traceroute from a
nearby Sun) just fine, but TCP-based apps (telnet, ftp) just say that they've
connected to the remote, and then hang.

At one end I have Zorch, a 4.3BSD-based system with a fairly antique kernel
SLIP driver.  At the other end is a Xylogics Annex III.  I'm using a T1600
modem at the Zorch end, and a T3000 at the Annex.  The T3000/Annex part is
probably working, as a colleague of mine can SLIP into it with no problems,
so I assume that the problem is in the Zorch end.

Here's where things start getting confusing:

1)  The SLIP driver on Zorch *seems* OK, though I suppose I could be having
a header-compression problem, since I don't think Zorch is doing that...
I can make a loopback connection to myself from port to port and bring up
SLIP over that wire, and it works just fine.  It even trims some 200ms of
latency off of pings...

2)  If I watch what's happening from aforementioned nearby Sun, using
etherfind, and try to telnet into another nearby Sun, I can see the SYNs
and acks fly by, and some data packets and whatnot.  If I then terminate
the telnet I can see FINs and RESETs go by, and netstat indicates that
the connection goes into FIN_WAIT_2 and then disappears properly.

3)  I thought it was a data transparency problem.  So, I discovered that
ping has this nice facility of padding out packets with byte sequences,
and if you ping with large enough packets it will go from 0x00 to 0xff
in increasing order.  Just lovely, only problem is that it showed pretty
conclusively that nothing was munging bytes...

My best guess is that it's a TCP header compression issue.  I think that
the Annex supports VJ compression, and from the 84-86 timeframe of the
dates on my if_sl.c, I gather that Zorch doesn't.  I thought that this
was an optionally negotiated type of thing, and if one end didn't know
about it things would still work OK, though less than optimally.  Am I
wrong?  If so, how do I go about finding the right modules to update my
driver and possibly associated header files?

Thanks for any assistance.

-- 
Scott Hazen Mueller              +1 408 285 5762  scott@dsg.tandem.com
Tandem Computers, Unix System Administrator, Email Postmaster and Usenet Admin
-- 
Scott Hazen Mueller              +1 408 285 5762  scott@dsg.tandem.com
Tandem Computers, Unix System Administrator, Email Postmaster and Usenet Admin
From: geray@ecs.umass.edu
Newsgroups: comp.protocols.tcp-ip
Subject: Econfig question
Date: 27 Jul 92 16:51:36 GMT

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
From: dricejb@drilex.dri.mgh.com (Craig Jackson drilex1)
Newsgroups: comp.protocols.tcp-ip
Subject: How to control permissions on incoming FTP?
Date: 29 Jul 92 21:58:52 GMT
Organization: DRI/McGraw-Hill, Lexington, MA
NNTP-Posting-Host: bbn.com

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).

We're developing an application where we need to accept files via ftp.
(Not anonymous; they're merely coming from another computer with limited
TCP capabilities.)  I'd like these files not to be world-readable.  I
know I can limit permissions on their directory, but can I limit
the permissions on the files themselves?

I can't find anything in any manual that describes how this might be done.
Newsgroups: comp.protocols.tcp-ip
From: Steinar.Haug@delab.sintef.no (Steinar Haug)
Subject: Re: How to control permissions on incoming FTP?
Organization: SINTEF DELAB, Trondheim, Norway.
Date: 30 Jul 92 10:05:16

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.

We have been using a "umask 022" as one of the first lines in /etc/rc on
our Suns for quite a while. Works like a charm.

Steinar Haug, system/networks administrator
SINTEF DELAB, University of Trondheim, NORWAY
Email: Steinar.Haug@delab.sintef.no, 
	sthaug@idt.unit.no, steinar@tosca.er.sintef.no
From: jrd@cc.usu.edu
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Problems with c-kermit telnet, right place to post?
Date: 22 Jul 92 10:13:16 MDT
Organization: Utah State University

In article <1992Jul22.032356.9842@ksgbbs.harvard.edu>, timb@ksgbbs.harvard.edu (Tim Buehrer - 625-6829) writes:
> 
> I hope that this is a good place to post this question.  If it is not, I would
> appreciate suggestions on where it should go.
> 
> We are setting up a system to communicate between our SCO XENIX box and a PC
> using c-kermit on the PC and the WATTCP telnetd on the PC.  Most parts are
> working fine, but there is one fundamental problem.  c-kermit insists on send-
> ing a return-linefeed combination when I type a return, even if the terminal
> setting for return-linefeed is off.  (When I just use the telnet that came
> from SCO, I don't have this problem.)  Is there a way to configure c-kermit to
> avoid this problem?  I've tried using set key but that doesn't seem to help.
> 
> Tim Buehrer
> timb@ksgbbs.harvard.edu
----------
Tim,
	Version numbers?
	My quick guess is the WATTCP stuff is not doing NETASCII properly.
CR-LF is the line terminator signal on the wire, and gets converted at each
end to suit the local system. Instead of WATTCP get MS-DOS Kermit 3.12 beta
and use that on the PC. C Kermit and MSK work properly for the CR-LF stuff.
	Further questions on the Kermit parts would get quicker attention if
sent to me, jrd@cc.usu.edu, for MS-DOS Kermit and to Frank da Cruz,
fdc@watsun.cc.columbia.edu, for C Kermit.
	Joe D.
From: zlsiimw@mcchpc.mcc.ac.uk (Mark Whidby)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: CLARIFICATION: NCSA Telnet problems
Keywords: TCP-IP, PC, UNIX
Date: 22 Jul 92 07:10:03 GMT
Reply-To: M.Whidby@mcc.ac.uk
Organization: Manchester Computing Centre

In article <1992Jul17.170955.17295@ccu.umanitoba.ca>, umrice02@ccu.umanitoba.ca
(Stephen Rice) writes:
|> I recently posted a message regarding a problem I am having with telnet'ing 
|> into a PC this message is meant to define the problem a little clearer:
|> 
|> The problem is that I set up the PC in server mode (*) with NCSA Telnet for
|> the PC.  I find that I can ftp to that machine but I cannot Telnet to the
|> machine ("Request for invalid port..." etc.).  My question is: Is it
|> possible
|> to setup Telnet for the PC to do this or am I doing something wrong?

You can only use ftp with NCSA telnet in server mode - you cannot telnet to
the PC.
-- 
_____________________________________________________________
Mark Whidby, Distributed Systems, Manchester Computing Centre
From: art@acc.com (Art Berggreen)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: IP Directed Broadcast
Date: 30 Jul 92 16:12:14 GMT
Organization: ACC, Advanced Computer Communications

In article <11132@crackers.clearpoint.com> martillo@stars.clearpoint.com (Joachim Martillo) writes:
>On reading RFC 1009 Requirements for Internet Gateways, one finds in
>section 4.4 on page 34.  An Internet gateway is permitted, but not
>required, to filter out directed broadcasts destined for any of its
>locally-connected networks.
>
>If a networks gateways do not filter IP broadcasts and that network
>has active loops in its subnet topology, and if someone extern to the
>network sends a directed broadcast to that network with a TTL of 255,
>the target network could easily suffer a major broadcast storm.
>
>Such a storm would seem a bad thing.  Maybe I am missing something,
>but perhaps filterning directed broadcasts should be obligatory rather
>than optional.
>
>Joachim Carlo Santos Martillo Ajami

Get the latest Router Requirements Draft from any internet-drafts server.
This will eventually replace RFC1009.

"All Subnets" broadcasts have been "deprecated" and multicasts encouraged.
The rule has become: if an IP packet arrives via media broadcast, it is
never forwarded (ignoring IP Multicast for the moment).  Thus if an All
Subnets broadcast is forwarded until it reaches the first subnet of the
target network, it may be exploaded there, but will not propagate to the
remaining subnets.  This is especially important with new routing protocols
which allow discontiguous subnets.

Art
From: shani@GENIUS.TAU.AC.IL (Oren Shani)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: ping works, but ftp/telnet get "no route to host"
Date: 23 Jul 92 05:29:40 GMT
Organization: Tel Aviv University Faculty of Engineering, ISRAEL

In article <BrruC8.FEo@spock.dis.cccd.edu> markb@spock.dis.cccd.edu (Mark Bixby) writes:
>Why would I be able to ping a site OK, but when I try to ftp or telnet to it
>I receive a "no route to host" error?  Traceroute can find the host, and it
>is apparently on Alternet, if that makes a difference.
>
>Any info would be most helpful to this tcp/ip novice.  Thanks.
>
>--
 Looks like there are traffic filters somewhere along the route. Some, more
advanced, routers and bridges, are able to filter traffic, and for instance,
allow ping or finger and disable ftp or telnet to certain targets.

This probably should be in the FAQ list (?)
-- 
    __    __  Oren Shani (shani@genius.tau.ac.il) 
   /  /  /    Faculty of Engineering, Tel Aviv university
  /  /   --   Israel
 /__/ . __/ . "Hold your temper" -- The caterpillar to Alice
Newsgroups: comp.protocols.tcp-ip
From: Alfred.Kayser@dnpap.et.tudelft.nl (Alfred Kayser)
Subject: Anybody installed 'authd' on IBM RS/6000???
Organization: Delft University of Technology, Dept. of Electrical Engineering
Date: Thu, 23 Jul 1992 07:47:09 GMT

Help, I want to install 'authd' on our RS/6000. Both available sources:
the original 'authd' and 'pidentd' fail to find certain vars in the kernel.
These variables are called '_file' and '_nfile'.

Anybody knows a solution???

Thanks in advance, Alfred

--
-- Ir. Alfred Kayser. PACS, OS/2, TCP/IP. --- Email: AKayser@et.tudelft.nl --
-- CARDIT, Delft University of Technology ------------ Tel: (31)-15-786179 --
-- P.O.Box 5031, 2600 GA Delft, The Netherlands ------ Fax: (31)-15-784898 --
Newsgroups: comp.protocols.tcp-ip
From: ji@cs.columbia.edu (John Ioannidis)
Subject: Re: ping works, but ftp/telnet get "no route to host"
Organization: Columbia University Department of Computer Science
Date: Wed, 22 Jul 1992 13:41:35 GMT

In article <BrruC8.FEo@spock.dis.cccd.edu> markb@spock.dis.cccd.edu (Mark Bixby) writes:
>Why would I be able to ping a site OK, but when I try to ftp or telnet to it
>I receive a "no route to host" error?  Traceroute can find the host, and it
>is apparently on Alternet, if that makes a difference.
>
>Any info would be most helpful to this tcp/ip novice.  Thanks.
>

The site you are trying to ping is running a firewall gateway, because
they're too lazy to beef up their host security and are relying on the
firewall to protect themselves against external attacks. The site
router(s) look inside your packets, and if they are not to/from
specific hosts or ports, they don't forward them, but rather send you
an ICMP host unreachable message back.

I wish I had a transcript of Dave Clark's talk at the IETF last week.
He said some great things about firewall gateways and mailbridges, and
how they've essentially destroyed the whole purpose of having an IP
internet, and have forced a lot of us to use mail as a transport-level
protocol.

/ji

In-Real-Life: John "Heldenprogrammer" Ioannidis
E-Mail-To: ji@cs.columbia.edu
V-Mail-To: +1 212 854 8120
P-Mail-To: 450 Computer Science \n Columbia University \n New York, NY 10027
Xref: sparky comp.protocols.tcp-ip.domains:558 comp.protocols.tcp-ip:3768