tom@tnosoes.UUCP (Tom Vijlbrief) (05/07/90)
I modified a version of Phil Karns KA9Q internet package
so it acts as a suspicious secure gateway.
The goal of this gateway is to establish security of a local network
at the gateway instead of securing every host on your local network.
One would for example disallow excess to rlogin, rsh, ftp and telnet
because many users have bad passwords.
I'll make the binary and sources available to those who are
interested.
The README follows. (start reading at 'Security Features' if
you are only interested in the secure gateway extensions)
I would like to receive suggestions and comments about this package.
=====================================================================
Microsoft C 4.00 Changes to KA9Q
================================
The assembler files are translated to a format suitable for the
MASM assembler.
The clocktick rate has been increased from 1 tick per second to
10 ticks per seconds. (This is useful for fast transmission paths
like ethernet).
A little bug in the ping command (Concerning echo timing) has been fixed.
One can now specify TCP receive window and mss sizes which are different
from the send sizes. The is needed for dumb ethernet cards (3C501, 3C503)
which are easily overrun when a fast TCP peer (e.g. a Sun) sends bursts
of ethernet packets.
'tcp rwin 512' and 'tcp rmss 512' are appropriate values.
Some little improvements has been made to the TCP timeout mechanisms.
The file 'autoexec.net' is now searched for in the working directory and
subsequently in the root. (This allows easy customization for different
users).
Command line arguments are now interpreted as NET commands.
(It used to be the name of a startup file).
These commands are executed after the default startup file has been
read. Multiple command may be given when delimited by ';'.
The FTP server now recognizes printer names, so you can use NET
as a print server. (e.g.: put text lpt1).
Function keys are transmitted as \033[ sequences. (Useful for emacs, etc).
Four additional commands has been added:
funkeys [on|off]
funkeys on will disable Functionkey-10 so one can use emacs. Abort is
by means of CTRL-FN10 when funkeys are on.
rsh host command
will execute a shell command on the specified host by means of the
rexecd(8) or rshd(8) daemon.
uprsh file host command
acts like rsh but gives file as standard input.
buprsh file host command
acts like rsh but gives binary file as standard input.
Before a rsh command may be given you should identify yourself
by means of the name command. ("name username password" or
"name username RSH localname" for use of rshd instead of rexed).
examples:
DOS PROMPT> net rsh rainbow date
will show the date on the unix host rainbow and return to DOS.
DOS PROMPT> net uprsh \mail\greeting rainbow mail tom
will mail the contents of DOS-file \mail\greeting to tom from host
rainbow.
DOS PROMPT> net buprsh \dos\del.com rainbow cat ">" binfile
will copy the contents of DOS-file \dos\del.com to "binfile"
in your home directory on host rainbow.
A new server has been added. This server allows a tcp-stream to
a serial line (COMx) or the screen of a PC. (Could be used for a
remotely accessible printer).
start com 20000 1 silent
This starts the server which listens on port 20000 and directs all
incoming data to the first attached serial line. (Use 0 for the screen).
In the attach command one should specify the COM-port, baudrate, etc.
(E.g.: "attach asy 0x3f8 4 slip sl0 1024 576 9600").
If the fourth argument is omitted then diagnostic output will be
printed on the screen. (E.g.: "Incoming com session from.....")
A WD8003E ethernet driver has been added.
This version of the KA9Q internet package has been tested on a
IBM-AT communicating with Suns running SunOS 3.2/3.5/4.0.3 and Masscomps.
Slip has also been tested.
SMTP mail has been tested.
The log command now has an onscreen option which duplicates messages
on the screen. The logfile is now cyclic and will be rewritten after
500kB of messages. When net is started it will begin writing at the
start of the logfile. The best strategy is to start with a logfile
with a (random) contents of about 501kB. This will garantee that
messages can be logged even if the disk is completely full.
The NET program can act as a real gateway by giving an ethernet interface
a different IP address:
gateway ec0 [131.34.2.8]
On this gateway interface is only ping (= ICMP Echo Request) allowed.
SECURITY Features
=================
This version of net can act as a secure gateway between a local net
and an external IP network.
It allows connections to be initiated from the local network(s) to the
external network(s) but it disallows all connection attempts from the
external networks(s) the the local network(s).
Note that the gateway itself is always accesible over all interfaces.
So it can act as FTP server for the external insecure networks.
(This has ofcourse a negative impact on its performance as a
secure internetwork router.)
Be carefull to configure the file '\ftpusers` before you start FTP service
with the 'start ftp' command. Disallow access to the root directory or the
NET binary!
The insecure external network interface has to be attached with a name
that starts with 'Se' (Secure).
The local network(s) has to be specified with the command:
secure localnet <network>[/<bits>]
Example: secure localnet [140.24.67]/24
This will add the specified network to the list of protected (local) networks.
The protection is established by examination of packets which enter the network
over the 'Secure' interface:
1:
==
A packet which has an IP-source which matches one of the specified local
networks is considered a faked packet and is simply dropped. A warning
is written in the logfile.
2:
==
Every UDP packet with a port destination number < 1024 is rejected
with an ICMP Port Unreachable message.
3:
==
Every TCP packet with a port destination number < 1024 is rejected
with an ICMP Port Unreachable number.
4:
==
ICMP redirect packets are dropped.
5:
==
Source Routed packets are rejected with an ICMP Parameter Problem.
Local networks (or hosts) can be completely isolated from the external networks
by specifying a 'sink' route. The will reject EVERY packet with an
IP-source or IP-destination that matches the specified sink route with
an ICMP Host Unreachable message.
Example:
route add lonely sink
route add [140.24.67.128]/25 sink
A local network can be completely isolated with the exception of 1 or more
specific hosts by:
route add [197.25.45.0]/25 sink
route add [197.25.45.128]/25 sink
route add [197.25.45.212] ec0
route add [197.25.45.213] ec0
Tracing
=======
The command: secure trace on
will trace incoming packets on the 'Secure' interface. Remember that
turning trace on has a negative impact on routing performance.
Creating (dangerous) exceptions
===============================
It is possible to allow TCP connections to special hosts in order to
establish anonymous FTP connections or incoming mail.
This can be very dangerous because many older Unix FTP- and SMTP-
(= sendmail) daemons have dangerous security holes. A safe alternative
is to use a PC which runs this NET program as anonymous FTP server.
Many mail SMTP (and FTP) daemons have the famous Morris internet worm holes.
Do not allow connections until you are certain that your version is
secure. The safest way to assure this is to install the latest
Berkeley sendmail and ftpd sources which are publicly available.
The use of mail-aliases which resolve to programs (like |uudecode) is
also considered insecure.
This is an extract of:
===============================================================================
CERT Advisory
March 19, 1990
Internet Intruder Warning
-------------------------------------------------------------------------------
3) Exploit holes in sendmail.
Make sure you are running the latest sendmail from your vendor.
BSD 5.61 fixes all known holes that the intruder is using.
4) Exploit bugs in old versions of FTP; exploit mis-configured
anonymous FTP
Make sure you are running the most recent version of FTP which is
the Berkeley version 4.163 of Nov. 8 1988. Check with your vendor
for information on configuration upgrades. Also check
your anonymous FTP configuration. It is important to follow the
instructions provided with the operating system to properly configure
the files available through anonymous ftp (e.g., file permissions,
ownership, group, etc.). Note especially that you should not use your
system's standard password file as the password file for FTP.
9) Examine the /usr/lib/aliases (mail alias) file for unauthorized
entries. Some alias files include an alias named 'uudecode'; if this
alias exists on your system, and you are not explicitly using it, then
it should be removed.
=========================End of extract===============
After you have convinced yourself that your Unix servers are really
secure you can execute an secure allow command.
Example: secure allow mailhost TCP 25
This will allow TCP connections to be established over the Secure
interface to tcp port 25 on host 'mailhost'. 25 is the TCP port number
of the SMTP mail daemon.
The general syntax is:
secure allow <host/ALL> <TCP/UDP/RPC-UDP> <port/ALL> [source-host]
If no source-host is specified then it defaults to ALL.
RPC-UDP specifies a filter which examines UDP packets and determines
if these packets are RPC calls to a RPC based server. The port number
contains the RPC program number which should be filtered.
Example:
sec allow ALL RPC-UDP 100012 ALL
One can also specify disallows:
secure disallow <host/ALL> <TCP/UDP/RPC-UDP> <port/ALL> [source-host]
Example:
secure disallow ALL RPC-UDP ALL
NOTE that 'disallow' specifiers always overrule 'allow' specifiers
except 'allows' which have specified all four fields without any 'ALL' wildcard.
===============================================================================
Tom Vijlbrief
TNO Institute for Perception
P.O. Box 23 Phone: +31 34 63 562 11
3769 ZG Soesterberg E-mail: tnosoes!tom@hp4nl.nluug.nl
The Netherlands or: uunet!hp4nl.nluug.nl!tnosoes!tom
===============================================================================karn@ka9q.bellcore.com (Phil Karn) (05/25/90)
In article <9005231723.AA20278@hp-ses.sde.hp.com> wunder@HP-SES.SDE.HP.COM (Walter Underwood) writes: >HP does exactly the same thing. I think of it as similar to >international borders.[...] That's not a bad analogy, because I absolutely detest having to deal with customs stations. And I certainly don't depend on US customs to protect my house (or computer) from being burglarized. My personal favorite analogy is the Berlin Wall. Shortly after the wall was opened some East German official was quoted by the AP as saying that the wall as a whole would stay up because it was "necessary to protect East Germans against AIDS", among other things. Unfortunately, this kind of thinking is not unheard of in the computer security business. Once again, I argue that there is no substitute for each individual taking the responsibility for protecting his own local domain. Security mechanisms are always most effectively implemented as close as possible to whatever is being protected. Phil
smb@ulysses.att.com (Steven Bellovin) (05/26/90)
In article <9005231723.AA20278@hp-ses.sde.hp.com>, wunder@HP-SES.SDE.HP.COM (Walter Underwood) writes: > HP does exactly the same thing. And Bell Labs goes even farther; we have just 2 non-isolated machines on the Internet. Application-level gateways do the rest. Why? Because in the Real World (whatever that is), our machines are not secure enough today. Blame complacent vendors, blame lazy administrators, blame careless users -- it doesn't matter much, since the empirical fact remains: a very significant fraction of hosts (and not just ours, I might add) are vulnerable. We, as a corporation, have chosen not to take the risk of exposure. Total isolation would be a serious problem; as is, most of what most people need to do on the Internet -- mail, FTP out, telnet both ways -- can be handled in a safer fashion. And most of the exceptions can be dealt with in other ways -- we do have a few more hosts that are directly connected to the Internet, but they're used for special purposes, and don't talk to anything else internally; they're dead ends. In the abstract, I mostly agree with Phil Karn -- hosts should be able to protect themselves. In fact, I spend a lot of my time working on mechanisms to help that cause. In practice, neither he nor I can administer every machine in our respective companies. I'll quote Phil's own article: The hard problem, as it turns out, lies not in generating a list of vulnerable systems, but in getting the administrators of those machines to update their software or to fix their system configurations. It's not a technical problem, but it's very real. And, given rlogin and its friends, if one host falls, a lot more will fall with it. Incidentally, I say ``mostly'' because there's an important class of device -- dial-out modems -- that is not capable of security today, and is not likely to be in the forseeable future. Finding a dialer pool on the Internet would be a hacker's idea of heaven.
zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff) (05/27/90)
>not secure enough today. Blame complacent vendors, blame lazy >administrators, blame careless users -- it doesn't matter much, >since the empirical fact remains: a very significant fraction While it may not matter when deciding to use a "secure" gateway, the cause matters very much when you go to fix the problems (which I hope you are still doing). It doesn't inspire confidence - even AT&T can't make a Unix they trust. >Incidentally, I say ``mostly'' because there's an important class of >device -- dial-out modems -- that is not capable of security today, and >is not likely to be in the forseeable future. Finding a dialer pool on There are these $100 toll restrictors (a little box) that help quite a bit. -- Jon Zeeff (NIC handle JZ) zeeff@b-tech.ann-arbor.mi.us
smb@ulysses.att.com (Steven Bellovin) (05/27/90)
In article <46F%_++@b-tech.uucp>, zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff) writes: > It doesn't inspire confidence - even AT&T can't make a Unix they trust. AT&T is not a homogeneous place -- for example, we have a lot of Sun workstations. (Remember the joint development deal, if nothing else.) We have an OEM agreement with Pyramid. We buy other machines for other reasons. And the best system in the world can be totally hosed by an incompetent administrator. And even on 6386s or 3B2s with good administrators, sometimes a machine *must* run back releases of the software, with known bugs not yet fixed. > >Incidentally, I say ``mostly'' because there's an important class of > >device -- dial-out modems -- that is not capable of security today, and > >is not likely to be in the forseeable future. Finding a dialer pool on > > There are these $100 toll restrictors (a little box) that help quite a bit. No, they don't. Why should we prevent ourselves from making long-distance calls? We have dial-out modems because we need them and use them, and often -- generally? -- not for local use. To give an important case in point, there's an AT&T office in Tokyo; we call it often via uucp.
henry@utzoo.uucp (Henry Spencer) (05/27/90)
In article <46F%_++@b-tech.uucp> zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff) writes: >It doesn't inspire confidence - even AT&T can't make a Unix they trust. More precisely, they can't make a Unix that they can trust when it is administered by incompetents. Nobody else can make such a system either. -- As a user I'll take speed over| Henry Spencer at U of Toronto Zoology features any day. -A.Tanenbaum| uunet!attcan!utzoo!henry henry@zoo.toronto.edu
zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff) (05/28/90)
>> There are these $100 toll restrictors (a little box) that help quite a bit. > >No, they don't. Why should we prevent ourselves from making long-distance >calls? We have dial-out modems because we need them and use them, and They don't prevent long distance calls - you just have to program in the numbers that are allowed. Even so, I will admit that that aren't suitable for all situations. -- Jon Zeeff (NIC handle JZ) zeeff@b-tech.ann-arbor.mi.us
cliff@cfa250.harvard.edu (Cliff Stoll) (05/30/90)
From henry@utzoo.uucp (Henry Spencer): > they can't make a Unix that they can trust when it is > administered by incompetents. Nobody else can make such a system either. I second that!