From Firewalls-Owner Thu Jul 1 19:55:25 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA27057; Thu, 1 Jul 93 19:55:25 GMT Received: from sc.tamu.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA27048; Thu, 1 Jul 93 12:55:09 PDT Received: from posaune.tamu.edu by sc.tamu.edu (AA18864); Thu, 1 Jul 93 14:57:38 CDT Message-Id: <9307011957.AA18864@sc.tamu.edu> Received: by posaune.tamu.edu (NX5.67c/NX3.0X) id AA00844; Thu, 1 Jul 93 14:57:32 -0500 Date: Thu, 1 Jul 93 14:57:32 -0500 From: David-Hess@sc.tamu.edu Received: by NeXT.Mailer (1.87.1) Received: by NeXT Mailer (1.87.1) To: Firewalls@GreatCircle.COM Subject: TAMU Security Package Update Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Texas A&M Network Security Package Update 7/1/93 Dave Safford Doug Schales Dave Hess This is an updated release of the security tools developed at the Texas A&M University Supercomputer Center. These tools are available for anonymous FTP from sc.tamu.edu:/pub/security/TAMU. ------------------------------------------------------------------------ CHANGE SUMMARY (see respective README files for more information): 'tiger' - Version 2.1.1 - UNIX security checking tool An explain facility for giving more information on the output from tiger. Many new checks, bug fixes, all around improvements. Too numerous to go into. Briefly, checks mail aliases, cron jobs, inetd configuration, PATH variables, more checks on passwd and group files. Untested initial configuration files for AIX 3, IRIX 4, HPUX and UNICOS. Tested configurations for SunOS 4.1.1, 4.1.2, 4.1.3, 5.1 and 5.2, including signatures for latest security patches, and NeXTSTEP 3.0. 'netlog' - Version 1.02 - Network traffic logging tools Bug fixes, minor enhancements to functionality. New tool for gathering statistics on protocol and port usage. 'drawbridge' - Version 1.1 - IP bridging filter Bug fixes. Allow and reject clauses did not work properly and bridging was not working efficiently. 'check_TAMU' - TAMU Security distribution check script A new script is now available for checking this distribution for any signs of tampering. This is intended for anyone who obtains this distribution from a site other than sc.tamu.edu. The script is available from a mailserver at "drawbridge-server@sc.tamu.edu". See the section AVAILABILITY below for more info. ------------------------------------------------------------------------ ORIGINAL DESCRIPTION: Last August, Texas A&M University UNIX computers came under extensive attack from a coordinated group of internet crackers. This package of security tools represents the results of over nine months of development and testing of the software we have been using to protect our estimated five thousand IP devices. This package includes three coordinated sets of tools: "drawbridge", an exceptionally powerful bridging filter package; "tiger", a set of convenient yet thorough machine checking programs; and "netlog", a set of intrusion detection network monitoring programs. KEY FEATURES: For full technical details on the products, see their individual README's, but here are some highlights: DRAWBRIDGE: - inexpensive (PC with two SMC/WD 8013 cards) - high level filter language and compiler - powerful filtering parameters - DES authenticated remote filter management - O(1) table lookup processing even with dense class B net filter specifications. TIGER: - checks key binaries against cryptographic checksums from original distribution files - checks for critical security patches - checks for known intrusion signatures - checks all critical configuration files - will run on most UNIX systems, and has tailored components for SunOS, Next, SVR4, Unicos. NETLOG: - efficiently logs all tcp/udp establishment attempts - powerful query tool for analyzing connection logs - "intelligent" intrusion detection program AVAILABILITY: This package is available via anonymous ftp in sc.tamu.edu: pub/security/TAMU Due to the sensitive nature of these tools, we recommend that you retrieve them from this location. If you do not get them from sc.tamu.edu we suggest that you use our check_TAMU script that uses cryptographic checksums to check the distribution for any signs of tampering. The script is available in the anonymous ftp directory above and from an e-mail server at: drawbridge-server@sc.tamu.edu Note that there are some distribution limitations, such as the inability to export outside the US the DES libraries used in drawbridge; see the respective tool README's for details of any restrictions. (Note that the DES libraries are NOT required to use drawbridge. They just enable secure remote management of drawbridge.) CONTACT: Comments and questions are most welcome. Please address them to: drawbridge@sc.tamu.edu From Firewalls-Owner Fri Jul 2 01:54:01 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA28170; Fri, 2 Jul 93 01:54:01 GMT Received: from sgigate.sgi.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA28163; Thu, 1 Jul 93 18:53:55 PDT Received: from yeager.corp.sgi.com by sgigate.sgi.com via SMTP (920330.SGI/920502.SGI) id AA24723; Thu, 1 Jul 93 18:55:32 -0700 Received: from [192.82.198.205] by yeager.corp.sgi.com via SMTP (930416.SGI/911001.SGI) for @sgigate.sgi.com:firewalls@GreatCircle.COM id AA28588; Thu, 1 Jul 93 18:55:26 -0700 Message-Id: <9307020155.AA28588@yeager.corp.sgi.com> Date: Sat, 3 Jul 1993 11:58:33 +1000 To: safdas@gsco.com (Shabbir J Safdar), safdas@gsco.com, randy@psg.com From: lear@yeager.corp.sgi.com (Eliot Lear) X-Sender: el2@yeager.corp.sgi.com (Unverified) Subject: Re: You've got to be kidding me. Cc: firewalls@GreatCircle.COM Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >If enough people refuse to run it, perhaps we'll have a more secure >information service built. However that still won't help sites who >have business reasons for not exposing who is working at their site. Perhaps we'll have no information service. Speaking as a guilty party in this area, I remain, Eliot Lear [lear@sgi.com] From Firewalls-Owner Fri Jul 2 22:52:14 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA01057; Fri, 2 Jul 93 22:52:14 GMT Received: from volitans.MorningStar.Com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA01050; Fri, 2 Jul 93 15:51:53 PDT Received: by volitans.MorningStar.Com (5.65a/93052901) id AA11669; Fri, 2 Jul 93 18:54:19 -0400 Date: Fri, 2 Jul 93 18:54:19 -0400 From: Bob Sutterfield Message-Id: <9307022254.AA11669@volitans.MorningStar.Com> To: firewalls@GreatCircle.COM Subject: why do information services use so many different ports? Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk As more and more of our users see Xmosaic and get excited about WWW, WAIS, Gopher, Archie, and friends, they spend more and more time browsing the nets. (This stuff may turn out to be a bigger time sink than the Usenet, but that's not what I came here to talk about...) RFC 1340 specifies particular well-known sockets for use by each of those popular services: gopher 70/tcp Gopher gopher 70/udp Gopher www 80/tcp World Wide Web HTTP www 80/udp World Wide Web HTTP prospero 191/tcp Prospero prospero 191/udp Prospero webster 765/tcp webster 765/udp But conformance is completely optional, and servers will seemingly use any port their administrators happened to choose. For example, in acquiring http://www.cis.ohio-state.edu:82/rfc/rfc1340.html to get the information above, my xmosaic client used TCP ports 80, 81, and 82. That's easy to implement, because the URL contains the port. Here's the problem: Our corporate network is protected from the Internet by a packet-filtering firewall. We take the philosophy that we should first block all packets, then explicitly make exceptions for the traffic we know to be safe. It's easy to say "pass www gopher prospero webster !all". But it's very frustrating to continually add more and more peepholes through the wall, in reaction to users coming to ask me "why couldn't I get to such-and-such service". The firewall is beginning to look more like a screen mesh. So is there some effort underway to standardize information services on the well-known ports that are designated for them? If not, what's a poor firewall maintainer to do? -- Bob Sutterfield, Morning Star Technologies +1 614 451 1883 1760 Zollinger Rd, Columbus Ohio USA, 43221-2856 +1 800 558 7827 bob@MorningStar.Com +1 614 459 5054 (FAX) From Firewalls-Owner Sat Jul 3 03:59:22 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA01732; Sat, 3 Jul 93 03:59:22 GMT Received: from yarra-glen.aaii.oz.au (eden-valley.aaii.oz.AU) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA01725; Fri, 2 Jul 93 20:59:10 PDT Received: from localhost.aaii.oz.AU by yarra-glen.aaii.oz.au with SMTP (5.65c/SMI-4.0/AAII) id AA29739; Sat, 3 Jul 1993 14:01:12 +1000 Message-Id: <199307030401.AA29739@yarra-glen.aaii.oz.au> To: Bob Sutterfield Cc: firewalls@GreatCircle.COM Subject: Re: why do information services use so many different ports? In-Reply-To: Your message of "Fri, 02 Jul 1993 18:54:19 -0400." <9307022254.AA11669@volitans.MorningStar.Com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 03 Jul 1993 14:01:10 +1000 From: Anthony Baxter Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk In message <9307022254.AA11669@volitans.MorningStar.Com>you write: > As more and more of our users see Xmosaic and get excited about WWW, > WAIS, Gopher, Archie, and friends, they spend more and more time > browsing the nets. (This stuff may turn out to be a bigger time sink > than the Usenet, but that's not what I came here to talk about...) > [..] > > So is there some effort underway to standardize information services > on the well-known ports that are designated for them? If not, what's > a poor firewall maintainer to do? I doubt you'll see much standardization of port numbers - I suspect as the Web gets bigger, the situation will get worse, not better, as more people add specialised daemons for an individual information service. i) Change the clients to connect from a range of ports, and filter on that, rather than the destination. Assuming your filters can do this, its probably the best option, as it requires < 10 lines of code to be added to XMosaic, and a few less than that to be added to Xgopher. I suggested adding this code to the developers of Mosaic, but they felt there weren't enough sites that would benefit from it. ii) If you are not worried about users connecting to arbitrary ports (ie you are trying to keep bad guys out, not your people in), then run something on a DMZ host that runs a proxy service for arbitrary ports. Both these require some source code hackery, but assuming you have Motif, and so can recompile Mosaic, its not such a big deal. Anthony From Firewalls-Owner Mon Jul 5 03:15:41 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA07154; Mon, 5 Jul 93 03:15:41 GMT Received: from norman.li.Cubic.COM by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA07146; Sun, 4 Jul 93 20:15:32 PDT Received: by norman.li.Cubic.COM (5.67/1.34a) id AA15338; Sun, 4 Jul 93 23:18:04 -0359 Date: Sun, 4 Jul 93 23:18:04 -0359 From: mischler@Cubic.COM (Dave Mischler) Message-Id: <9307050317.AA15338@norman.li.Cubic.COM> To: bob@MorningStar.Com, firewalls@GreatCircle.COM Subject: Re: why do information services use so many different ports? Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > So is there some effort underway to standardize information services > on the well-known ports that are designated for them? If not, what's > a poor firewall maintainer to do? Presumably you are more worried about keeping J. Random Cracker out than keeping Joe User in. If this is true then all of the TCP services that are originated from inside your packet filter could be easily handled by using an implementation that allows TCP packets for established connections (i.e. letting through TCP packets that have the TCP header ACK bit set, or the SYN bit clear). Most of your filter rules then relate only to what services you will allow outside machines to originate. This is not too confining, although it doesn't help for UDP services. Dave Mischler mischler@cubic.com From Firewalls-Owner Thu Jul 8 06:51:46 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA16512; Thu, 8 Jul 93 06:51:46 GMT Received: from ftp.com (babyoil.ftp.com) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA16505; Wed, 7 Jul 93 23:51:40 PDT Received: by ftp.com id AA10121; Thu, 8 Jul 93 02:54:04 -0400 Date: Thu, 8 Jul 93 02:54:04 -0400 From: hobbit@ftp.com (*Hobbit*) Message-Id: <9307080654.AA10121@ftp.com> To: firewalls@GreatCircle.COM Subject: user interfaces Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk I've been playing with a bunch of different routers of late [major vendors], and I've found universally that the configuration user interfaces are soggy and hard to light, ESPECIALLY where filtering is concerned. Why is this? Why can't these vendors chuck some resources in the direction of lowering the customer's learning curve and frustration level? An indirect result of this sad-ass state of affairs is that a lot of people might wind up configuring their filtering wrong, because they missed something obscure, and are really wide open when they think otherwise. _H* From Firewalls-Owner Thu Jul 8 20:50:21 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA18160; Thu, 8 Jul 93 20:50:21 GMT Received: from dot.ca.gov (nic.dot.ca.gov) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA18149; Thu, 8 Jul 93 13:50:12 PDT Received: from trew002 (trew.dot.ca.gov) by dot.ca.gov (4.1/SMI-4.1) id AA03482; Thu, 8 Jul 93 13:59:56 PDT Message-Id: <9307082059.AA03482@dot.ca.gov> Date: Thu, 8 Jul 93 13:43:46 PDT From: trstan@trew.dot.ca.gov ( ) To: Firewalls@GreatCircle.COM Subject: Firewall Software request Cc: stan@dot.ca.gov Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk I represent a government organization that has need to connect (Telnet/FTP) to hosts on the Internet from a small number of hosts. Many of our hosts (VAX,VM,UNIX) are multi-user systems. We require the ability to define users, hosts, and services within our corporate internet that are permitted to connect to corresponding services at hosts on the Internet. Our current Internet connectivity is E-mail only via a Sun workstation on a network protected with access-lists on a cisco router such that the Sun is the only host that can be reached from both our corporate internet and the INTERNET. The following diagram shows this topology. -------------- ---------- --------- ---------- | Corporated | | cisco | | Sun | | cisco | | internet |-| with | | Email | | with |->Internet | cloud | | filters| | G/W | | filters| -------------- ---------- --------- ---------- | | | --------------------------- Ethernet We need a product (Gimme preferred but not required) that will let us: 1) permit user "Able" on multi-user host "SYS1" to telnet anywhere on the Internet, 2) user "Baker" on host "SYS1" can only FTP (or ?) to only hosts on network "134.186.x.x", 3) user "Charlie" (and others) on host "SYS1" cannot get to the Internet, 4) Email must pass thru the Sun, 5) the DNS services on the Sun are available from anywhere, 6) and similiar simple scenerios. Cisco router filter's don't work for restricting users on multi-user hosts, neither does Igateway. Products like Secure-ID don't work with FTP. Logging features (like successful connections) are needed by security audit people as well as failed attempts from otherwise authorized hosts/users for other reasons. Source code (or BINs with exits) would be desirable as I would also like my Sun to log IP addresses of hosts sending Email to my GateWay for tracking and security purposes. When I ask vendors about this kind of "stuff", they either don't seem to know what I am talking about or they don't have anything to offer. Maybe someone on this list can point me in a direction (without, of course, compromising their own methods) I am new to this list so please accept my apologies if what I am asking for is "common knowledge". I am a C programmer of modest abilities with lots of motivation. Any help or advise will be appreciated. Stan Jones Caltrans Internet Manager From Firewalls-Owner Fri Jul 9 02:03:55 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA19172; Fri, 9 Jul 93 02:03:55 GMT Received: from TIS.COM by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA19165; Thu, 8 Jul 93 19:03:49 PDT Received: by TIS.COM (4.1/SUN-5.64) id AA17571; Thu, 8 Jul 93 22:06:14 EDT Date: Thu, 8 Jul 93 22:06:14 EDT From: Marcus J Ranum Message-Id: <9307090206.AA17571@TIS.COM> To: Firewalls@GreatCircle.COM, trstan@trew.dot.ca.gov Subject: Re: Firewall Software request Cc: stan@dot.ca.gov Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > Cisco router filter's don't work for restricting > users on multi-user hosts, neither does Igateway. > Products like Secure-ID don't work with FTP. DEC SEAL's FTP and telnet gateways can both use SecurID or other token authentication systems, so they can be configured to permit complete systems or individual users to perform operations by operation type and direction. (I.e.: "users on system A can talk to the internet, but internet users can only talk to system A if they first authenticate with SecurID" or "users on system A can FTP files IN from the internet but can only FTP files OUT if they authenticate with SecurID" or more simply, "you can do nothing unless you first authenticate. period.") mjr. From Firewalls-Owner Fri Jul 9 08:28:33 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA20019; Fri, 9 Jul 93 08:28:33 GMT Message-Id: <9307090828.AA20019@mycroft.GreatCircle.COM> To: firewalls@GreatCircle.COM Subject: Incident Response Workshop info Reply-To: spaf@cs.purdue.edu Organization: COAST, Department of Computer Sciences, Purdue Univ. Date: Thu, 08 Jul 93 20:51:05 -0500 From: Gene Spafford Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk [Please forward this to other lists and to interested parties.] ** NOTE: July 10 is the deadline for discounted registration!! ** PRELIMINARY AGENDA 5th Computer Security Incident Handling Workshop Sponsored by the Forum of Incident Response and Security Teams (FIRST) August 10-13, 1993 St. Louis, MO TUESDAY, August 10, 1993 Full-day Tutorials 1. Creating a Security Policy presented by Charles Cresson Wood: [no abstract available at time of posting] 2. Vulnerabilities of the IBM PC Architecture: Virus, Worms, Trojan Horses, and Things That Go Bump In The Night presented by A. Padgett Peterson: An intensive look into the architecture of the IBM-PC and MS/PC-DOS -- What it is and why it was designed that way. An understanding of assembly language and the interrupt structure of the Intel 80x86 processor is helpful. The day will begin with the BIOS and what makes the PC a fully functional computer before any higher operating system is introduced. Next will be a discussion of the various operating systems, what they add and what is masked. Finally, the role and effects of the PC and various LAN configurations (peer-peer and client server) will be examined with emphasis on the potential protection afforded by login scripting and RIGHTS. At each step, vulnerabilities will be examined and demonstrations made of how malicious software exploits them. Demonstrations may include STONED, MICHELANGELO, AZUSA, FORM, JERUSALEM, SUNDAY, 4096, and EXEBUG viruses depending on time and equipment available. On completion attendees will understand the vulnerabilities and how to detect attempted exploitation using simple tools included with DOS such as DEBUG and MEM. 3. Unix Security presented by Matt Bishop: Unix can be a secure operating system if the appropriate controls and tools are used. However, it is difficult for even experienced system administrators to know all the appropriate controls to use. This tutorial covers the most important aspects of Unix security administration, including internal and external controls, useful tools, and administration techniques to develop better security. Upon completion, Unix system administrators will have a better understanding of vulnerabilities in Unix, and of methods to protect their systems. WEDNESDAY, August 11, 1993 8:30 - 8:45 Opening Remarks - Rich Pethia (CERT/CC) 8:45 - 9:30 Keynote Speaker - Dr. Vinton Cerf (XXXX) 9:30 - 10:00 Break 10:00 - 12:00 International Issues - Computer networks and communication lines span national borders. This session will focus on how computer incidents may be handled in an international context, and on some ways investigators can coordinate their efforts. SPEAKERS: Harry Onderwater (Dutch Federal Police) John Austien (New Scotland Yard) other speakers pending 12:00 - 1:30 Lunch with Presentations by various Response Teams 1:30 - 3:00 Professional Certification & Qualification - how do you know if the people you hire for security work are qualified for the job? How can we even know what the appropriate qualifications are? The speakers in this session will discuss some approaches to the problem for some segments of industry and government. SPEAKERS: Sally Meglathery ((ISC)2) Lynn McNulty (NIST) Genevieve Burns (ISSA) 3:00 - 3:30 Break 3:30 - 6:00 Incident Aftermath and Press Relations - What happens after an incident has been discovered? What are some of the consequences of dealing with law enforcement and the press? This session will feature presentations on these issues, and include a panel to answer audience questions. SPEAKERS: Laurie Sefton (Apple Computer) Jeffrey Sebring (MITRE) Terry McGillen (Software Engineering Institute) John Markoff (NY Times) Mike Alexander (InfoSecurity News) 7:00 - 9:00 Reception THURSDAY August 12 8:30 - 10:00 Preserving Rights During an Investigation - During an investigation, sometimes more damage is done by the investigators than from the original incident. This session reinforces the importance of respecting the rights of victims, bystanders, and suspects while also gathering evidence that may be used in legal or administrative actions. SPEAKERS: Mike Godwin (Electronic Frontiers Foundation) Scott Charney (Department of Justice) other speaker pending 10:00 - 10:30 Break 10:30 - 12:00 Coordinating an Investigation - What are the steps in an investigation? When should law enforcement be called in? How should evidence be preserved? Veteran investigators discuss these questions. A panel will answer questions, time permitting. SPEAKER: Jim Settle (FBI) other speakers pending 12:00 - 1:30 Special Interest Lunch 1:30 - 3:00 Liabilities and Insurance - You organize security measures but a loss occurs. Can you somehow recover the cost of damages? You investigate an incident, only to cause some incidental damage. Can you be sued? This session examines these and related questions. SPEAKERS: Mark Rasch (Arent Fox) Bill Cook (Willian, Brinks, Olds, Hoffer, & Gibson) Marr Haack (USF&G Insurance Companies) 3:00 - 3:15 Break 3:15 - 5:30 Incident Role Playing -- An exercise by the attendees to develop new insights into the process of investigating a computer security incident. Organized by Dr. Tom Longstaff of the CERT/CC. 7:30 - ? Birds of a Feather and Poster Sessions FRIDAY August 13 8:30 - 10:00 Virus Incidents - How do you organize a sussessful virus analysis and response group? The speakers in this session have considerable experience ans success in doing exactly this. In their talks, and subsequent panel, they will explain how to organize computer virus response. SPEAKERS: Werner Uhrig (Macintosh Anti-virus Expert) David Grisham (University of New Mexico) Christoph Fischer (CARO) Karen Picharczyk (LLNL/DoE CIAC) Ken van Wyk (DISA/Virus-L) 10:00 - 10:15 Break 10:15 - 11:15 Databases - How do you store incident, suspect, and vulnerability information safely, but still allow the information to be used effectively? The speakers in this session will share some of their insights and methods on this topic. SPEAKERS: John Carr (CCTA) Michael Higgins (DISA) speaker pending 11:15 - 12:15 Threats - Part of incidence response is to anticipate riska and threats. This session will focus on some likely trends and possible new problems to be faced in computer security. SPEAKERS: Karl A. Seeger speakers pending 12:15 - 12:30 Closing Remarks - Dennis Steinauer (NIST/FIRST) 12:30 - 2:00 Lunch 2:00 - 3:00 FIRST General Meeting and the Steering Committee Elections 3:00 - 4:00 FIRST Steering Committee Meeting ^^^^^^^^^^^^^^^^^^^^^Registration Information/Form Follows^^^^^^^^^^^^^^^^^^^^^ INQUIRES: Direct questions concerning registration and payment to: Events at 412-268-6531 Direct general questions concerning the workshop to: Mary Alice "Sam" Toocheck at 214-268-6933 Return to: Helen E. Joyce Software Engineering Institute Carnegie Mellon University Pittsburgh, PA 15213-3890 Facsimile: 412-268-7401 TERMS: Please make checks or purchase orders payable to SEI/CMU. Credit cards are not accepted. No refunds will be issued, substitutions are encouraged. The registrations fee includes materials, continential breakfast, lunches (not included on August 13), morning and afternoon breaks and an evening reception on August 11. Completed registration materials must be received by the SEI no later than July 10, 1993. A minimum of 7 attendees are needed for each tutorial and there will be limit of 50 attendees. You MUST indicate which tutorial you would like to attend and an alternate if your first choice is full. GOVERNMENT TERMS: If your organization has not made prior arrangements for reimbursement of workshop expenses, please provide authorization (1556) from your agency at the time of registration. GENERAL REGISTRATION INFORMATION: Workshop................................. ..............$300.00 All registrations received after July 10, 1993..........$350.00 Tutorials (Must be registered by July, 10, 1993)........$190.00 NAME: TITLE: COMPANY: DIVISION: ADDRESS: CITY: STATE: ZIP: BUSINESS PHONE: EMERGENCY PHONE: FACSIMILE NUMBER: E-MAIL ADDRESS: DIETARY/ACCESS REQUIREMENTS: CITIZENSHIP: Are you a U.S. Citizen? YES/NO Identify country where citizenship is held if not the U.S.: (Note: there will be no classified information disclosed at this workshop. There is no attendance restriction based on citizenship or other criteria.) GENERAL HOTEL INFORMATION: RATES: A block of rooms has been reserved at the Hyatt Regency at Union Station, One St. Louis Union Station, St. Louis, Missouri 63103. The hotel will hold these rooms until July 10, 1993. Hotel arrangements should be made directly with the Hyatt, 314-231-1234. To receive the special rate of $65.00 per night, please mention the Fifth Computer Security Incident Handling Workshop when making your hotel arrangements. ACCOMMODATIONS: Six-story hotel featuring 540 guest rooms, including 20 suites. All rooms have individual climate control, direct-dial telephone with message alert, color TV with cable and optional pay movies. Suites available with wet bar. Hotel offers three floors of Regency accomodations, along with a Hyatt Good Passport floor, and a special floor for women travelers. LOCATION/TRANSPORTATION FACTS: Downtown hotel located in historic Union Station one mile from Cervantes Convention Center and St. Louis Convention Center and St. Louis Arch. Fifteen miles (30 minutes) from St. Louis Zoo. DINING/ENTERTAINMENT: Italian Cuisine is features at Aldo's, the hotel's full-service restaurant. Enjoy afternnon cocktails in the Grand Hall, an open-air, six-story area featuring filigree work, fresco and stained glass windows. The station Grille offers a chop house and seafood menu. RECREATIONAL/AMUSEMENT FACILITIES: Seasonal outdoor swimming pool. Full health club; suana in both men's and women's locker rooms. Jogging maps are available at the hotel front desk. SERVICES/FACILITIES/SHOPS: Over 100 specialty shops throughout the hotel, including men's and women's boutiques, children's toy shops and train stores. From Firewalls-Owner Fri Jul 9 16:57:30 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA20969; Fri, 9 Jul 93 16:57:30 GMT Received: from telemann.inoc.dl.nec.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA20962; Fri, 9 Jul 93 09:57:20 PDT Received: by telemann.inoc.dl.nec.com (4.1/YDL1.9-920831.09) id AA02842(telemann.inoc.dl.nec.com); Fri, 9 Jul 93 11:59:43 CDT Received: by texas.syl.dl.nec.com (4.1/YDL1.9-930614.17) id AA14257(texas.syl.dl.nec.com); Fri, 9 Jul 93 11:59:42 CDT Received: by florida.syl.dl.nec.com (4.1/YDL1.9-920708.13) id AA15356(florida.syl.dl.nec.com); Fri, 9 Jul 93 11:59:41 CDT Date: Fri, 9 Jul 93 11:59:41 CDT From: ylee@syl.dl.nec.com (Ying-Da Lee) Message-Id: <9307091659.AA15356@florida.syl.dl.nec.com> To: Firewalls@GreatCircle.COM, trstan@trew.dot.ca.gov Subject: Wanted: testers for SOCKS (Was: Firewall Software request) Cc: ylee@syl.dl.nec.com Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > We need a product (Gimme preferred but not required) > that will let us: > > 1) permit user "Able" on multi-user host "SYS1" > to telnet anywhere on the Internet, > 2) user "Baker" on host "SYS1" can only FTP (or ?) > to only hosts on network "134.186.x.x", > 3) user "Charlie" (and others) on host "SYS1" > cannot get to the Internet, > 4) Email must pass thru the Sun, > 5) the DNS services on the Sun are available > from anywhere, > 6) and similiar simple scenerios. > > Cisco router filter's don't work for restricting > users on multi-user hosts, neither does Igateway. > Products like Secure-ID don't work with FTP. The SOCKS package that I recent made available allows you to define access control on a per user basis, so it can deal with 1), 2), and 3). You should be able to compile and run the server daemon on your Sun. The ftp and telnet clients should be easy for Sun workstations and, with a bit more work, other Unix machines. I assume porting them for VM or VMS might be a lot of work. The current version of SOCKS package (server with finger/telnet/ftp/xgopher clients) is available with anonymous ftp from ftp.inoc.dl.nec.com (143.101.112.3) in directory pub/security, the file name is socks.cstc.930629.tar.Z. A newer version is coming. It will include an xmosaic client which allows access to WWW/Gopher/Hytelnet/ftp and other goodies, assuming that I can get permission from the NCSA folks. It will also have the network/host byte order mess cleaned up, which is the major hurdle for porting the current version to machines with different endian-isms. Since I have only Suns here (and no 386i's), I really can't see whether I caught them all. Would anyone on this list with machines of mixed endian-isms want to volunteer for testing? 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 Jul 9 22:59:43 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA21606; Fri, 9 Jul 93 22:59:43 GMT Received: from bos1a.delphi.com (delphi.com) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA21599; Fri, 9 Jul 93 15:59:34 PDT Received: from bix.com by delphi.com (PMDF V4.2-11 #4520) id <01H0CKZ5I7PS934PQX@delphi.com>; Fri, 9 Jul 1993 19:01:47 EDT Received: by bix.com (CoSy3.31.1.29) id <9307091859.memo.93327@BIX.com>; Fri, 9 Jul 1993 18:59:47 -0400 (EDT) Date: Fri, 09 Jul 1993 18:59:46 -0400 (EDT) From: macallen@BIX.com Subject: DEC SEAL proxy ftp & SecurID To: firewalls@GreatCircle.COM Message-Id: <9307091859.memo.93327@BIX.com> Content-Transfer-Encoding: 7BIT X-Cosy-To: firewalls@greatcircle.com Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Marcus, we were unable to make SecurID work with SEAL's proxy ftp last December because there is no terminal session to work with. Did Roj, Allen and I miss something? BTW, Roj had no trouble getting SecurID to work with proxy telnet. - Mac From Firewalls-Owner Sat Jul 10 10:39:42 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA22804; Sat, 10 Jul 93 10:39:42 GMT Received: from bos1a.delphi.com (delphi.com) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA22797; Sat, 10 Jul 93 03:39:34 PDT Received: from bix.com by delphi.com (PMDF V4.2-11 #4520) id <01H0D9FMYWB49353ZP@delphi.com>; Sat, 10 Jul 1993 06:42:16 EDT Received: by bix.com (CoSy3.31.1.29) id <9307100637.memo.93889@BIX.com>; Sat, 10 Jul 1993 06:37:32 -0400 (EDT) Date: Sat, 10 Jul 1993 06:37:32 -0400 (EDT) From: macallen@BIX.com Subject: DEC SEAL proxy ftp & SecurID To: firewalls@GreatCircle.COM Message-Id: <9307100637.memo.93889@BIX.com> Content-Transfer-Encoding: 7BIT X-Cosy-To: firewalls@greatcircle.com Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk oops! I am cracking up... Roj did get it to work by presenting a menu after the user logged in with username & password. The way it works favors the PIN PAD card, so PINs don't get sent unencrypted. From Firewalls-Owner Sun Jul 11 01:09:56 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA23869; Sun, 11 Jul 93 01:09:56 GMT Received: from TIS.COM by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA23862; Sat, 10 Jul 93 18:09:51 PDT Received: by TIS.COM (4.1/SUN-5.64) id AA12242; Sat, 10 Jul 93 21:12:19 EDT Date: Sat, 10 Jul 93 21:12:19 EDT From: Marcus J Ranum Message-Id: <9307110112.AA12242@TIS.COM> To: firewalls@GreatCircle.COM, macallen@BIX.com Subject: Re: DEC SEAL proxy ftp & SecurID Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >oops! I am cracking up... Roj did get it to work by presenting a menu >after the user logged in with username & password. Mac, Would you *PLEASE* stop including the entire mailing list on your mail to me?` mjr. From Firewalls-Owner Mon Jul 12 18:44:54 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA27326; Mon, 12 Jul 93 18:44:54 GMT Received: from chsun.eunet.ch (chsun.chuug.ch) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA27319; Mon, 12 Jul 93 11:44:41 PDT Received: from open.ch by chsun.eunet.ch (5.65c8/1.34) id AA23946; Mon, 12 Jul 1993 20:47:32 +0200 Received: from turbo by open.ch (NX5.67c/NX3.0M.pizza1) id AA04830; Mon, 12 Jul 93 20:21:43 +0100 From: Goetz von Escher Message-Id: <9307121921.AA04830@open.ch> Received: by turbo. (NX5.67c/NX3.0X) id AA05852; Mon, 12 Jul 93 20:22:07 +0100 Date: Mon, 12 Jul 93 20:22:07 +0100 Received: by NeXT.Mailer (1.87.1) Received: by NeXT Mailer (1.87.1) To: Firewalls@GreatCircle.COM Subject: another one on source routing... Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk I want to use a Wellfleet router (AFN) in a firewall configuration. Does anybody know wether these routers do source routing and can it be disabled? Is this an issue at all? How come there hasn't been a lot of discussion on Wellfleet routers so far? Are there not enough or too many problems with them? :-) Talking about source routing: If I don't run "routed" on a dual homed gateway and I reconfigure the kernel to disable IP forwarding is source routing still a problem? --- Goetz von Escher email: goetz@open.ch Open Systems AG voice: +41 (61) 262-0505 Basel, Switzerland FAX: +41 (61) 262-0510 From Firewalls-Owner Mon Jul 12 23:51:01 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA27806; Mon, 12 Jul 93 23:51:01 GMT Received: from rock.concert.net by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA27799; Mon, 12 Jul 93 16:50:55 PDT Received: by rock.concert.net (5.59/tas-rock/8-12-92) id AA24997; Mon, 12 Jul 93 19:53:28 -0400 From: Michael G Reamy -- Support X-Disclaimer-1: rock is a CONCERT-CONNECT public access host. X-Disclaimer-2: Opinions expressed are not necessarily X-Disclaimer-3: those of MCNC or the CONCERT Network. Message-Id: <9307122353.AA24997@rock.concert.net> Subject: screening routers To: firewalls@GreatCircle.COM Date: Mon, 12 Jul 93 19:53:27 EDT X-Mailer: ELM [version 2.3 PL11] Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk What is this groups opinion on the best screening routers. We are beginning to look at routers for use as in a firewall system. Most people seem to use Cisco routers for screening with access lists. How do other routers compare in this area? Especially Wellfleet. -- Michael G. Reamy (mreamy@rock.concert.net) The light at the end of the tunnel may be an oncoming dragon. From Firewalls-Owner Tue Jul 13 03:00:48 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA28167; Tue, 13 Jul 93 03:00:48 GMT Received: from almaden.ibm.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA28160; Mon, 12 Jul 93 20:00:41 PDT Message-Id: <9307130300.AA28160@mycroft.GreatCircle.COM> Received: from ALMVMA by almaden.ibm.com (IBM VM SMTP V2R2) with BSMTP id 5390; Mon, 12 Jul 93 20:03:39 PDT Date: Mon, 12 Jul 93 20:02:09 PDT From: enge@almaden.ibm.com To: firewalls@GreatCircle.COM Subject: Re: screening routers News-Software: UReply 3.1 References: <9307122353.AA24997@rock.concert.net> Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk In <9307122353.AA24997@rock.concert.net> Michael G Reamy -- Support writes: >What is this groups opinion on the best screening routers. We are beginning >to look at routers for use as in a firewall system. Most people seem to use >Cisco routers for screening with access lists. How do other routers compare >in this area? Especially Wellfleet. >-- > >Michael G. Reamy (mreamy@rock.concert.net) > >The light at the end of the tunnel may be an oncoming dragon. > We have both Cisco and Wellfleet here. The WF configuration changes require a reboot of the box (3-5 minutes). On the Cisco, the changes are immediate. Roy From Firewalls-Owner Tue Jul 13 10:47:20 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA28981; Tue, 13 Jul 93 10:47:20 GMT Received: from vision.visionware.co.uk by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA28974; Tue, 13 Jul 93 03:47:10 PDT Received: by vision.visionware.co.uk (5.59/5.930520) id AA16373; Tue, 13 Jul 93 10:10:40 GMT Newsgroups: vw.net.firewalls Path: chris From: chris@visionware.co.uk (Chris Davies) Subject: Re: another one on source routing... Message-Id: <1993Jul13.101026.16330@visionware.co.uk> Organization: VisionWare Ltd., Leeds, UK X-Newsreader: TIN [version 1.1 PL8] References: <9307121921.AA04830.vw.net.firewalls@open.ch> Date: Tue, 13 Jul 1993 10:10:26 GMT Apparently-To: firewalls@greatcircle.com Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Goetz von Escher (goetz@open.ch) wrote: > Does anybody know wether these routers do source routing and can it be > disabled? Is this an issue at all? I've seen a lot about the dire nature of source routing when used to circumvent a firewall. I think I understand the concept, but not the implications. We've a Xyplex 6220 router configured to drop all incoming packets to specific well know ports (rlogin, telnet,...). One host can be reached with telnet; the others are supposed to be unreachable. Do I have a problem with this source routing stuff here? Ta, Chris -- VISIONWARE LTD, 57 Cardigan Lane, LEEDS LS4 2LE, England Tel +44 532 788858 x238. Fax +44 532 304676. Email chris@visionware.co.uk ---------- "VisionWare: The home of DOS/SQL/UNIX/X/VMS integration" --------- From Firewalls-Owner Tue Jul 13 13:43:58 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA29271; Tue, 13 Jul 93 13:43:58 GMT Received: from mercury.house.gov by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA29264; Tue, 13 Jul 93 06:43:44 PDT Received: from ozone.house.gov by mercury.house.gov with SMTP (1.37.109.4/16.2) id AA02046; Tue, 13 Jul 93 09:44:04 -0400 Received: by oxygen.house.gov (AIX 3.2/UCB 5.64/3.2.083191-) id AA19096; Tue, 13 Jul 1993 09:39:52 -0400 Date: Tue, 13 Jul 1993 09:39:52 -0400 From: johns@oxygen.house.gov (John Schnizlein) Message-Id: <9307131339.AA19096@oxygen.house.gov> To: firewalls@GreatCircle.COM Subject: Re: another one on source routing... Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Regarding the following questions on the list recently: > Does anybody know wether these routers do source routing and can it be > disabled? Is this an issue at all? I've seen a lot about the dire nature of source routing when used to circumvent a firewall. I think I understand the concept, but not the implications. We've a Xyplex 6220 router configured to drop all incoming packets to specific well know ports (rlogin, telnet,...). One host can be reached with telnet; the others are supposed to be unreachable. Do I have a problem with this source routing stuff here? The source routing issue is independent of filtering based on TCP and UDP ports. It is used where the reachability of networks is managed through control of the content of the route tables rather than (in addition to) packet filters. Since a router cannot forward a packet to a destination it doesn't know, (the IP spec requires it to discard it) this control is efficient and powerful. However, it requires that default routes and IP source routes not provide a path that has been closed by removing route table information. Disabling source routing is made trickier by some implementations: (1) Unix hosts will process source routing even if they have only one interface and have their route forwarding process disabled. (2) Some routers interpreted NO IP SOURCE ROUTE to mean "don't process the next source route hop in the IP header" instead of "discard any packet that includes the source route option". Cisco has changed their implementation to do what I (and others) think is right.I can't say what other vendors have done. From Firewalls-Owner Tue Jul 13 14:11:00 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA29331; Tue, 13 Jul 93 14:11:00 GMT Received: from research.att.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA29324; Tue, 13 Jul 93 07:10:51 PDT Message-Id: <9307131410.AA29324@mycroft.GreatCircle.COM> From: smb@research.att.com Received: by gryphon; Tue Jul 13 10:11:11 EDT 1993 To: chris@visionware.co.uk (Chris Davies) Cc: firewalls@GreatCircle.COM Subject: Re: another one on source routing... Date: Tue, 13 Jul 93 10:11:10 EDT Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk The problem is that source-routing makes address-spoofing very easy. And if I can spoof source IP addresses, I can spoof you to rlogind, rshd, etc. Source routing overrides the normal routing tables. Thus, though I can easily send a random TCP packet with a bogus source address, normally I won't see the reply. While that's not a perfect defense against attacks, it does make them much harder. With source routing, on the other hand, I manually specify the hops that the packet should traverse on its way to you. Worse yet, according to RFC1122, when a TCP packet arrives via source-routing, the destination host is supposed to turn the route around for response packets. Thus, the reply packets will arrive at the attacker's machine. Some further details on routing attacks can be found in a paper I published a few years ago. You can ftp it from research.att.com, as dist/internet_security/ipext.ps.Z. --Steve Bellovin From Firewalls-Owner Tue Jul 13 20:31:40 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA29929; Tue, 13 Jul 93 20:31:40 GMT Received: from relay1.UU.NET by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA29922; Tue, 13 Jul 93 13:31:33 PDT Received: from spool.uu.net (via LOCALHOST) by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA20692; Tue, 13 Jul 93 16:34:31 -0400 Received: from rayssd.UUCP by spool.uu.net with UUCP/RMAIL (queueing-rmail) id 162845.15332; Tue, 13 Jul 1993 16:28:45 EDT Received: from JAGUAR.NMC.ED.RAY.COM by rayssd.ssd.ray.com with SMTP id AA12299 (5.65c/IDA-1.5 for ); Tue, 13 Jul 1993 15:36:07 -0400 Received: from tdw901.ED.RAY.COM by jaguar.NMC.ED.RAY.COM (4.1/SMI-4.1-DNI) id AA00372; Tue, 13 Jul 93 15:36:42 EDT Received: by tdw901.ED.RAY.COM (4.1/SMI-4.1-BH102992) id AA27434; Tue, 13 Jul 93 15:36:09 EDT From: heiser@tdwr.ed.ray.com (Bill Heiser) Message-Id: <9307131936.AA27434@tdw901.ED.RAY.COM> Subject: IP Filtering for SunOS 4.X To: Firewalls@GreatCircle.COM Date: Tue, 13 Jul 1993 15:36:08 -0400 (EDT) Cc: heiser@tdwr.ed.ray.com (Bill Heiser) X-Organization: Raytheon Company Equipment Division X-Location: Sudbury, Massachusetts USA 01776 X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 442 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk DEC Ultrix has a program called "screend" which acts as an IP filter, allowing a DECstation to be used, say, as a FIREWALL between two networks. I am interested in a comparable program for use on a SunOS 4.1 system. Is there such a thing? If so, where might I find it. Thanks in advance, Bill -- Bill Heiser Business: heiser@TDWR.ED.RAY.COM Unix Workstation System Manager Personal: heiser@world.std.com From Firewalls-Owner Tue Jul 13 21:57:18 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA00193; Tue, 13 Jul 93 21:57:18 GMT Received: from mail-relay-2.mv.us.adobe.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA00186; Tue, 13 Jul 93 14:57:10 PDT Received: by mail-relay-2.mv.us.adobe.com; id AA25898; Tue, 13 Jul 93 15:00:10 -0700 Received: by guardi.mv.us.adobe.com; id AA03736; Tue, 13 Jul 93 15:00:08 -0700 Message-Id: <9307132200.AA03736@guardi.mv.us.adobe.com> To: Michael G Reamy -- Support Cc: firewalls@GreatCircle.COM Subject: Re: screening routers In-Reply-To: Your message of "Mon, 12 Jul 93 19:53:27 EDT." <9307122353.AA24997@rock.concert.net> Date: Tue, 13 Jul 93 15:00:06 MDT From: Tim Guarnieri Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Attached is a note I posted to this list back in May re: using Cisco's as screening routers. Tim To: firewalls@GreatCircle.COM Subject: Re: Ok, so what is a "Good" filtering router? In-reply-to: Your message of "Thu, 27 May 93 15:21:14 CDT." <199305272021.AA25403@triton.cis.corp.medtronic.COM> Date: Thu, 27 May 93 17:57:12 MDT From: Tim Guarnieri Dean R. Schrimpf asks: >> I would greatly appreciated it, if any of you have evaluated several routers >> for your opinions regarding which routers work well for firewalls. I did extensive evaluation of Cisco AGS+ routers as possible firewall gateways. We decided not to go with them here. Here are my conclusions: (1) Cisco does not log rejected packets. We wanted to know when someone was "knocking at our door". (2) Cisco does not provide source port level filtering. We wanted to have that feature on our firewall. Note that there has been religious debate on this issue in several newsgroups. I don't want to start those debates again here. Suffice it to say that, in general, the more flexible your filtering language is, the better off you are. (3) To filter in both directions on a Cisco, you need to use extended access lists on the "Internet side" as well as the "Local Net" side. This causes performance degradation. There is a school of thought that says you only need to filter inbound traffic; traffic initiated from internal hosts to the Internet is "O.K." thus you do not need filters for outbound traffic. This is a risky position at best. If there are any other means of accessing your network (i.e. via dialup modem), and a cracker breaks in to an internal host, they have carte blanche access to the Internet at whatever speed you are running. The company "crown jewels" can be taken quite quickly and, unless you have fairly extensive logging of outbound connections, you may never know it happened. (4) Lastly, Cisco has the notion of an "established" keyword to make decisions on whether or not a connection attempt should be allowed. There have been several problems with this feature as noted in a few CERT advisories. I believe Cisco has fixed these problems, but it is something you should be aware of. In general, I like Cisco routers a lot. They are very good at routing packets fast. We use them all over our internal networks. I'm just not sure they're the best solution for an Internet packet screen. I don't have any firsthand experience with the NetBlazer, but have seen various postings on the net expressing concern about their filtering language and what order their routers parse through the filtering rules. I seem to recall that some behavior was seen that was not expected due to order in which the rules were processed. Hope this helps. Tim From Firewalls-Owner Wed Jul 14 12:26:50 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA01557; Wed, 14 Jul 93 12:26:50 GMT Received: from vision.visionware.co.uk by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA01550; Wed, 14 Jul 93 05:26:38 PDT Received: by vision.visionware.co.uk (5.59/5.930520) id AA09116; Wed, 14 Jul 93 12:26:24 GMT Newsgroups: vw.net.firewalls Path: chris From: chris@visionware.co.uk (Chris Davies) Subject: Re: another one on source routing... Message-Id: <1993Jul14.122545.9007@visionware.co.uk> Organization: VisionWare Ltd., Leeds, UK X-Newsreader: TIN [version 1.1 PL8] References: <1993Jul13.101026.16330.vw.net.firewalls@visionware.co.uk> Date: Wed, 14 Jul 1993 12:25:45 GMT Apparently-To: firewalls@greatcircle.com Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Chris Davies (chris@visionware.co.uk - that's me!) wrote: > I've seen a lot about the dire nature of source routing when used to > circumvent a firewall. I think I understand the concept, but not the > implications. Thanks to those of you who took the time to explain this to me. > We've a Xyplex 6220 router configured to drop all > incoming packets to specific well know ports (rlogin, telnet,...). One > host can be reached with telnet; the others are supposed to be > unreachable. Do I have a problem with this source routing stuff here? It appears (after experimentation, and also talking with our supplier) that this is OK. The filter is applied on the destination port as packets arrive over our WAN link interface, so it doesn't matter what route the packet takes - it will still get dropped. Chris -- VISIONWARE LTD, 57 Cardigan Lane, LEEDS LS4 2LE, England Tel +44 532 788858 x238. Fax +44 532 304676. Email chris@visionware.co.uk ---------- "VisionWare: The home of DOS/SQL/UNIX/X/VMS integration" --------- From Firewalls-Owner Thu Jul 15 13:58:16 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA05195; Thu, 15 Jul 93 13:58:16 GMT Received: from acri.acri.fr ([192.70.70.39]) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA05167; Thu, 15 Jul 93 06:57:34 PDT Received: from lscc1.acri.fr (mailhost.acri.fr [192.134.232.2]) by acri.acri.fr (8.1C/ACRI-930701) with SMTP id PAA19755; Thu, 15 Jul 1993 15:59:30 +0200 Received: from syst06.acri.fr by lscc1.acri.fr (4.1/SMI-4.1) id AA13271; Thu, 15 Jul 93 15:59:18 +0200 Date: Thu, 15 Jul 93 15:59:18 +0200 Message-Id: <9307151359.AA13271@lscc1.acri.fr> From: amellan@acri.fr (Alain Mellan) To: firewalls@GreatCircle.COM Subject: socks on Alpha Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Does anybody have socks client part ported on alpha? The clients compile OK, but I think there is a pb because of the 64 bits ... My sockd syslog says: sockd [pid]: connect from 192.x.x.x by Kh^F@ to 0.0.0.0 Sounds like the client didn't send the what sockd expected. -- Alain Mellan From Firewalls-Owner Fri Jul 16 16:57:09 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA09647; Fri, 16 Jul 93 16:57:09 GMT Received: from ftp.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA09640; Fri, 16 Jul 93 09:57:02 PDT Received: from lard.ftp.com by ftp.com with SMTP id AA22635; Fri, 16 Jul 93 13:00:23 -0400 Received: by lard.ftp.com.ftp_nis (5.0/SMI-SVR4) id AA06606; Fri, 16 Jul 93 12:57:14 EDT Date: Fri, 16 Jul 93 12:57:14 EDT From: hobbit@lard.ftp.com (*Hobbit*) Message-Id: <9307161657.AA06606@lard.ftp.com.ftp_nis> To: firewalls%greatcircle.com@ftp.com Subject: source routing Content-Length: 80 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Why not just drop everything whose first byte of the IP header isn't 0x45? _H* From Firewalls-Owner Fri Jul 16 18:09:16 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA09988; Fri, 16 Jul 93 18:09:16 GMT Received: from nic.near.net by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA09981; Fri, 16 Jul 93 11:09:08 PDT Message-Id: <9307161809.AA09981@mycroft.GreatCircle.COM> Received: from IRON.BBN.COM by nic.near.net id aa16134; 16 Jul 93 14:12 EDT To: *Hobbit* Cc: firewalls@GreatCircle.COM Subject: Re: source routing In-Reply-To: Your message of "Fri, 16 Jul 1993 12:57:14 EDT." <9307161657.AA06606@lard.ftp.com.ftp_nis> Date: Fri, 16 Jul 1993 14:11:31 -0400 From: Ed Anselmo Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > Why not just drop everything whose first byte of the IP header isn't 0x45? I guess that's OK if you're prepared to quit handling all IP options, but this would break things like timestamp and record route. -- Ed Anselmo (anselmo@nic.near.net) From Firewalls-Owner Fri Jul 16 19:18:36 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA10121; Fri, 16 Jul 93 19:18:36 GMT Received: from mercury.house.gov by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA10114; Fri, 16 Jul 93 12:18:30 PDT Received: from ozone.house.gov by mercury.house.gov with SMTP (1.37.109.4/16.2) id AA14221; Fri, 16 Jul 93 15:19:46 -0400 Received: by oxygen.house.gov (AIX 3.2/UCB 5.64/3.2.083191-) id AA09937; Fri, 16 Jul 1993 15:15:39 -0400 Date: Fri, 16 Jul 1993 15:15:39 -0400 From: johns@oxygen.house.gov (John Schnizlein) Message-Id: <9307161915.AA09937@oxygen.house.gov> To: firewalls@GreatCircle.COM Subject: Re: source routing Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Am I missing the interpretation of a humor indicator: "_H*" ? What you propose might be an implementation, but wouldn't it also preclude otherwise usefull options such as record route and timestamp? Also wouldn't this implementation preclude a future IP version; aren't there at least 3 in competition right now? For those who do not usually hack bits inside IP datagrams, 0x45 would be version=4, len=5 word header (ie no options). page 69-74 in original Comer; page 92-102 in Volume I, 2nd Ed. From Firewalls-Owner Fri Jul 16 19:25:15 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA10165; Fri, 16 Jul 93 19:25:15 GMT Received: from localhost by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA10148; Fri, 16 Jul 93 12:24:15 PDT Message-Id: <9307161924.AA10148@mycroft.GreatCircle.COM> To: johns@oxygen.house.gov (John Schnizlein) Cc: firewalls@GreatCircle.COM Subject: Re: source routing In-Reply-To: Your message of Fri, 16 Jul 1993 15:15:39 -0400 Date: Fri, 16 Jul 93 12:24:14 -0700 From: Brent Chapman Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk # Am I missing the interpretation of a humor indicator: "_H*" ? That's not humor; that's how Hobbit signs everything. # What you propose might be an implementation, # but wouldn't it also preclude otherwise usefull options such as # record route and timestamp? Does anything actually use those options, though? And do the routers and hosts support those options? I've never seen anything that does, not in routine TCP or UDP packets; everything I've seen that does stuff like that uses ICMP. # Also wouldn't this implementation preclude a future IP version; # aren't there at least 3 in competition right now? If this is user-level programming (i.e., a user-specified filter), and it becomes an issue, you just change the filter. If it's vendor-level programming (i.e., hardcoded), any new verion of IP is going to require significant code modifications on the part of the vendor anyway. They're probably already dropping packets that aren't 0x4? anyway, since they don't know what to do with them. # For those who do not usually hack bits inside IP datagrams, # 0x45 would be version=4, len=5 word header (ie no options). # page 69-74 in original Comer; page 92-102 in Volume I, 2nd Ed. -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 Jul 16 20:22:55 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA10292; Fri, 16 Jul 93 20:22:55 GMT Received: from TIS.COM by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA10285; Fri, 16 Jul 93 13:22:48 PDT Received: from otter.TIS.COM.tis.com by TIS.COM (4.1/SUN-5.64) id AA09177; Fri, 16 Jul 93 16:25:55 EDT Received: by otter.TIS.COM.tis.com (5.65/client) id AA00213; Fri, 16 Jul 93 16:25:55 -0400 From: mjr@TIS.COM Date: Fri, 16 Jul 93 16:25:55 -0400 Message-Id: <213.9307162025@otter.TIS.COM> To: firewalls@GreatCircle.COM, johns@oxygen.house.gov Subject: Re: source routing Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >Also wouldn't this implementation preclude a future IP version; >aren't there at least 3 in competition right now? I'll take this as my call to do my usual "broken record" routine. ;) I sure *HOPE* that whatever future IP version wins out, it has some kind of support for end-to-end security or even encryption. That way, we firewalls folks can put ourselves out of business. :) My suspicion is that for a long time at least, any future versions of IP are going to be being encapsulated over old links, because of the huge amount of existing stuff that may not be able to support IP:TNG. mjr. From Firewalls-Owner Mon Jul 19 02:47:10 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA16725; Mon, 19 Jul 93 08:44:09 GMT Received: from mod.dsto.gov.au (manta.dsto.gov.au) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA16718; Mon, 19 Jul 93 01:43:53 PDT Received: from caddyshack.mod.dsto.gov.au ([131.185.21.72]) by mod.dsto.gov.au (4.1/SMI-4.1) id AA19846; Mon, 19 Jul 93 15:08:21 CST Date: Mon, 19 Jul 93 15:08:21 CST From: sjf@mod.dsto.gov.au (Stephen Fitzgerald) Message-Id: <9307190538.AA19846@mod.dsto.gov.au> To: firewalls@GreatCircle.COM Subject: Novell and TCP/IP firewalls Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Dear Wallers, I have a Sun workstation configured as a firewall between a local network and corporate wide network. On the local network and on the corporate network I need to run Novell servers that talk to each other. tcp/ip tcp/ip -----------------------------------[firewall]------------------------------- | | ------- ------- | | | | ------- ------- novell server novell server local net corporate net The rough diagram shows the configuration. All machines are Sun, SGI or PC's all running TCP/IP. We have been offered as a solution dual ethernet interfaces in each Novell server, which are on their own network and communication between these servers is via that connection. I do not like this solution for a number of reasons 1 - I now have to monitor and configure this connection 2 - I know precious little about IPX and do not know if it offers the level of protection I require. A question - can these 2 novell servers talk through some tunnelling arrangement via my existing TCP/IP firewall? Is there a proxy service available for IPX that can run on my firewall?? Please email any suggestions or comments and I will summarise to the forum. Thanks for any suggestions ========================================================================== 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 Mon Jul 19 19:27:33 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA18596; Mon, 19 Jul 93 19:27:33 GMT Received: from lard.ftp.com.ftp_nis by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA18589; Mon, 19 Jul 93 12:27:25 PDT Received: by lard.ftp.com.ftp_nis (5.0/SMI-SVR4) id AA21855; Mon, 19 Jul 93 15:27:48 EDT Date: Mon, 19 Jul 93 15:27:48 EDT From: hobbit@lard.ftp.com (*Hobbit*) Message-Id: <9307191927.AA21855@lard.ftp.com.ftp_nis> To: firewalls@GreatCircle.COM Subject: options, etc Content-Length: 236 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Try firing IPSO at a Buglix box or an older SUnOS, and see what it does. We might want to chuck some options or source routing around in-house, but I can't see *any* reason we'd want to support it coming from the outside world... _H* From Firewalls-Owner Mon Jul 19 22:22:26 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA19107; Mon, 19 Jul 93 22:22:26 GMT Received: from tigger.jvnc.net by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA19100; Mon, 19 Jul 93 15:22:17 PDT Received: by tigger.jvnc.net id AA17742 (5.65c/IDA-1.4.4 for firewalls@greatcircle.com); Mon, 19 Jul 1993 18:25:27 -0400 Date: Mon, 19 Jul 1993 18:25:27 -0400 From: Moodys Investors Service Message-Id: <199307192225.AA17742@tigger.jvnc.net> To: firewalls@GreatCircle.COM Subject: ICMP redirects Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Hi All- I've set up a gateway and everything works fine except that the networking people have told me that their log files are full of ICMP redirects coming from my gateway box. I killed off routed, of course- but the redirects kept coming- so it must be in the kernel. Does anybody know the adb command to shut this off? Further reading has indicated that ICMP redirects can actually be used by a cracker and have no real use in todays nets (Security Problems in TCP... by Steve Bellovin) Any comments would be appreciated. John vV aka moodys@tigger.jvnc.net From Firewalls-Owner Mon Jul 19 22:27:22 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA19133; Mon, 19 Jul 93 22:27:22 GMT Received: from tigger.jvnc.net by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA19126; Mon, 19 Jul 93 15:27:15 PDT Received: by tigger.jvnc.net id AA17964 (5.65c/IDA-1.4.4 for firewalls@greatcircle.com); Mon, 19 Jul 1993 18:30:29 -0400 Date: Mon, 19 Jul 1993 18:30:29 -0400 From: Moodys Investors Service Message-Id: <199307192230.AA17964@tigger.jvnc.net> To: firewalls@GreatCircle.COM Subject: ICMP redirect p.s. Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk OK, I guess I'm getting a litle smarter (thanks to y'all) poohbear}strings /vmunix | egrep "ICMP|icmp|redirect" icmp_error icmp len redirect (%d) to %x But where I go from here... BTW its a sparc w/4.1.3 Thanx- John vV From Firewalls-Owner Mon Jul 19 22:38:36 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA19180; Mon, 19 Jul 93 22:38:36 GMT Received: from tigger.jvnc.net by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA19173; Mon, 19 Jul 93 15:38:29 PDT Received: by tigger.jvnc.net id AA18120 (5.65c/IDA-1.4.4 for firewalls@greatcircle.com); Mon, 19 Jul 1993 18:41:42 -0400 Date: Mon, 19 Jul 1993 18:41:42 -0400 From: Moodys Investors Service Message-Id: <199307192241.AA18120@tigger.jvnc.net> To: firewalls@GreatCircle.COM Subject: ICMP Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk I think I got it: echo "ip_sendredirects/W 0" | /usr/bin/adb -kw /vmunix /dev/mem Right? Hope so. Sorry for the bother- John vV But why is it I get all my work done after 5:00 pm ;^) From Firewalls-Owner Mon Jul 19 23:50:00 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA19448; Mon, 19 Jul 93 23:50:00 GMT Received: from research.att.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA19441; Mon, 19 Jul 93 16:49:53 PDT Message-Id: <9307192349.AA19441@mycroft.GreatCircle.COM> From: smb@research.att.com Received: by gryphon; Mon Jul 19 19:51:30 EDT 1993 To: Moodys Investors Service Cc: firewalls@GreatCircle.COM Subject: Re: ICMP redirects Date: Mon, 19 Jul 93 19:51:29 EDT Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Hi All- I've set up a gateway and everything works fine except that the networking people have told me that their log files are full of ICMP redirects coming from my gateway box. I killed off routed, of course- but the redirects kept coming- so it must be in the kernel. Does anybody know the adb command to shut this off? Further reading has indicated that ICMP redirects can actually be used by a cracker and have no real use in todays nets (Security Problems in TCP... by Steve Bellovin) Any comments would be appreciated. ICMP redirects are useful if you have two routers on the same network, and if the hosts don't run a routing protocol (and that's the right idea, actually). The abuses I described occur if intermediate routers listen to redirects. RFC1009 permits such behavior, but it's not advisable. If you're getting lots of redirects from your gateway, it sounds like something is misconfigured. Hosts are sending packets in a direction they shouldn't, and that needs to befixed, rather than adding random kernel hacks. --Steve Bellovin From Firewalls-Owner Tue Jul 20 20:28:30 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA22382; Tue, 20 Jul 93 20:28:30 GMT Message-Id: <9307202028.AA22382@mycroft.GreatCircle.COM> To: Firewalls@GreatCircle.COM Subject: Incident Response Workshop info Reply-To: spaf@cs.purdue.edu Organization: COAST, Department of Computer Sciences, Purdue Univ. Date: Thu, 08 Jul 93 20:51:05 -0500 From: Gene Spafford Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk [ My apologies for the delay in getting this out. This message was intercepted without being posted by the software that manages the Firewalls mailing list because it was over 10000 bytes long; such messages are held pending human inspection. Normally I see such messages and forward them on the same day. In this case, I've been travelling on business for most of the last month, and this one slipped through the cracks of my intermittent reading of email. Again, my apologies. -Brent ] [Please forward this to other lists and to interested parties.] ** NOTE: July 10 is the deadline for discounted registration!! ** PRELIMINARY AGENDA 5th Computer Security Incident Handling Workshop Sponsored by the Forum of Incident Response and Security Teams (FIRST) August 10-13, 1993 St. Louis, MO TUESDAY, August 10, 1993 Full-day Tutorials 1. Creating a Security Policy presented by Charles Cresson Wood: [no abstract available at time of posting] 2. Vulnerabilities of the IBM PC Architecture: Virus, Worms, Trojan Horses, and Things That Go Bump In The Night presented by A. Padgett Peterson: An intensive look into the architecture of the IBM-PC and MS/PC-DOS -- What it is and why it was designed that way. An understanding of assembly language and the interrupt structure of the Intel 80x86 processor is helpful. The day will begin with the BIOS and what makes the PC a fully functional computer before any higher operating system is introduced. Next will be a discussion of the various operating systems, what they add and what is masked. Finally, the role and effects of the PC and various LAN configurations (peer-peer and client server) will be examined with emphasis on the potential protection afforded by login scripting and RIGHTS. At each step, vulnerabilities will be examined and demonstrations made of how malicious software exploits them. Demonstrations may include STONED, MICHELANGELO, AZUSA, FORM, JERUSALEM, SUNDAY, 4096, and EXEBUG viruses depending on time and equipment available. On completion attendees will understand the vulnerabilities and how to detect attempted exploitation using simple tools included with DOS such as DEBUG and MEM. 3. Unix Security presented by Matt Bishop: Unix can be a secure operating system if the appropriate controls and tools are used. However, it is difficult for even experienced system administrators to know all the appropriate controls to use. This tutorial covers the most important aspects of Unix security administration, including internal and external controls, useful tools, and administration techniques to develop better security. Upon completion, Unix system administrators will have a better understanding of vulnerabilities in Unix, and of methods to protect their systems. WEDNESDAY, August 11, 1993 8:30 - 8:45 Opening Remarks - Rich Pethia (CERT/CC) 8:45 - 9:30 Keynote Speaker - Dr. Vinton Cerf (XXXX) 9:30 - 10:00 Break 10:00 - 12:00 International Issues - Computer networks and communication lines span national borders. This session will focus on how computer incidents may be handled in an international context, and on some ways investigators can coordinate their efforts. SPEAKERS: Harry Onderwater (Dutch Federal Police) John Austien (New Scotland Yard) other speakers pending 12:00 - 1:30 Lunch with Presentations by various Response Teams 1:30 - 3:00 Professional Certification & Qualification - how do you know if the people you hire for security work are qualified for the job? How can we even know what the appropriate qualifications are? The speakers in this session will discuss some approaches to the problem for some segments of industry and government. SPEAKERS: Sally Meglathery ((ISC)2) Lynn McNulty (NIST) Genevieve Burns (ISSA) 3:00 - 3:30 Break 3:30 - 6:00 Incident Aftermath and Press Relations - What happens after an incident has been discovered? What are some of the consequences of dealing with law enforcement and the press? This session will feature presentations on these issues, and include a panel to answer audience questions. SPEAKERS: Laurie Sefton (Apple Computer) Jeffrey Sebring (MITRE) Terry McGillen (Software Engineering Institute) John Markoff (NY Times) Mike Alexander (InfoSecurity News) 7:00 - 9:00 Reception THURSDAY August 12 8:30 - 10:00 Preserving Rights During an Investigation - During an investigation, sometimes more damage is done by the investigators than from the original incident. This session reinforces the importance of respecting the rights of victims, bystanders, and suspects while also gathering evidence that may be used in legal or administrative actions. SPEAKERS: Mike Godwin (Electronic Frontiers Foundation) Scott Charney (Department of Justice) other speaker pending 10:00 - 10:30 Break 10:30 - 12:00 Coordinating an Investigation - What are the steps in an investigation? When should law enforcement be called in? How should evidence be preserved? Veteran investigators discuss these questions. A panel will answer questions, time permitting. SPEAKER: Jim Settle (FBI) other speakers pending 12:00 - 1:30 Special Interest Lunch 1:30 - 3:00 Liabilities and Insurance - You organize security measures but a loss occurs. Can you somehow recover the cost of damages? You investigate an incident, only to cause some incidental damage. Can you be sued? This session examines these and related questions. SPEAKERS: Mark Rasch (Arent Fox) Bill Cook (Willian, Brinks, Olds, Hoffer, & Gibson) Marr Haack (USF&G Insurance Companies) 3:00 - 3:15 Break 3:15 - 5:30 Incident Role Playing -- An exercise by the attendees to develop new insights into the process of investigating a computer security incident. Organized by Dr. Tom Longstaff of the CERT/CC. 7:30 - ? Birds of a Feather and Poster Sessions FRIDAY August 13 8:30 - 10:00 Virus Incidents - How do you organize a sussessful virus analysis and response group? The speakers in this session have considerable experience ans success in doing exactly this. In their talks, and subsequent panel, they will explain how to organize computer virus response. SPEAKERS: Werner Uhrig (Macintosh Anti-virus Expert) David Grisham (University of New Mexico) Christoph Fischer (CARO) Karen Picharczyk (LLNL/DoE CIAC) Ken van Wyk (DISA/Virus-L) 10:00 - 10:15 Break 10:15 - 11:15 Databases - How do you store incident, suspect, and vulnerability information safely, but still allow the information to be used effectively? The speakers in this session will share some of their insights and methods on this topic. SPEAKERS: John Carr (CCTA) Michael Higgins (DISA) speaker pending 11:15 - 12:15 Threats - Part of incidence response is to anticipate riska and threats. This session will focus on some likely trends and possible new problems to be faced in computer security. SPEAKERS: Karl A. Seeger speakers pending 12:15 - 12:30 Closing Remarks - Dennis Steinauer (NIST/FIRST) 12:30 - 2:00 Lunch 2:00 - 3:00 FIRST General Meeting and the Steering Committee Elections 3:00 - 4:00 FIRST Steering Committee Meeting ^^^^^^^^^^^^^^^^^^^^^Registration Information/Form Follows^^^^^^^^^^^^^^^^^^^^^ INQUIRES: Direct questions concerning registration and payment to: Events at 412-268-6531 Direct general questions concerning the workshop to: Mary Alice "Sam" Toocheck at 214-268-6933 Return to: Helen E. Joyce Software Engineering Institute Carnegie Mellon University Pittsburgh, PA 15213-3890 Facsimile: 412-268-7401 TERMS: Please make checks or purchase orders payable to SEI/CMU. Credit cards are not accepted. No refunds will be issued, substitutions are encouraged. The registrations fee includes materials, continential breakfast, lunches (not included on August 13), morning and afternoon breaks and an evening reception on August 11. Completed registration materials must be received by the SEI no later than July 10, 1993. A minimum of 7 attendees are needed for each tutorial and there will be limit of 50 attendees. You MUST indicate which tutorial you would like to attend and an alternate if your first choice is full. GOVERNMENT TERMS: If your organization has not made prior arrangements for reimbursement of workshop expenses, please provide authorization (1556) from your agency at the time of registration. GENERAL REGISTRATION INFORMATION: Workshop................................. ..............$300.00 All registrations received after July 10, 1993..........$350.00 Tutorials (Must be registered by July, 10, 1993)........$190.00 NAME: TITLE: COMPANY: DIVISION: ADDRESS: CITY: STATE: ZIP: BUSINESS PHONE: EMERGENCY PHONE: FACSIMILE NUMBER: E-MAIL ADDRESS: DIETARY/ACCESS REQUIREMENTS: CITIZENSHIP: Are you a U.S. Citizen? YES/NO Identify country where citizenship is held if not the U.S.: (Note: there will be no classified information disclosed at this workshop. There is no attendance restriction based on citizenship or other criteria.) GENERAL HOTEL INFORMATION: RATES: A block of rooms has been reserved at the Hyatt Regency at Union Station, One St. Louis Union Station, St. Louis, Missouri 63103. The hotel will hold these rooms until July 10, 1993. Hotel arrangements should be made directly with the Hyatt, 314-231-1234. To receive the special rate of $65.00 per night, please mention the Fifth Computer Security Incident Handling Workshop when making your hotel arrangements. ACCOMMODATIONS: Six-story hotel featuring 540 guest rooms, including 20 suites. All rooms have individual climate control, direct-dial telephone with message alert, color TV with cable and optional pay movies. Suites available with wet bar. Hotel offers three floors of Regency accomodations, along with a Hyatt Good Passport floor, and a special floor for women travelers. LOCATION/TRANSPORTATION FACTS: Downtown hotel located in historic Union Station one mile from Cervantes Convention Center and St. Louis Convention Center and St. Louis Arch. Fifteen miles (30 minutes) from St. Louis Zoo. DINING/ENTERTAINMENT: Italian Cuisine is features at Aldo's, the hotel's full-service restaurant. Enjoy afternnon cocktails in the Grand Hall, an open-air, six-story area featuring filigree work, fresco and stained glass windows. The station Grille offers a chop house and seafood menu. RECREATIONAL/AMUSEMENT FACILITIES: Seasonal outdoor swimming pool. Full health club; suana in both men's and women's locker rooms. Jogging maps are available at the hotel front desk. SERVICES/FACILITIES/SHOPS: Over 100 specialty shops throughout the hotel, including men's and women's boutiques, children's toy shops and train stores. ------- End of Blind-Carbon-Copy From Firewalls-Owner Wed Jul 21 00:51:43 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA24130; Wed, 21 Jul 93 00:51:43 GMT Received: from localhost by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA24122; Tue, 20 Jul 93 17:51:38 PDT Message-Id: <9307210051.AA24122@mycroft.GreatCircle.COM> To: Firewalls@GreatCircle.COM Subject: Firewalls administrivia Date: Tue, 20 Jul 93 17:51:37 -0700 From: Brent Chapman Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk A short administrivia note. This ESPECIALLY applies to folks using "magic" mailers that hide email addresses, and folks using non-Internet mail systems (stuff like QuickMail, Microsoft Mail, BITNET, etc.) via some sort of gateway. Lately I've been getting quite a few submissions for Firewalls that have been misaddressed to Firewalls-Owner@GreatCircle.COM, particularly from folks replying to other messages. When I notice, I send these messages back to the originator with a short note explaining what they should have done. I often don't notice, though, and assume I'm looking at a message that everybody is seeing. When you send something to Firewalls, and especially when you reply to something from Firewalls, please check that your message is addressed properly. The Firewalls-Owner address appears only in the "Sender:" field of Firewalls messages that leave GreatCircle.COM. If some gateway or mailer between me and you is picking that up the "Sender:" field as some sort of reply address, it's broken. -Brent -- Brent Chapman Great Circle Associates Brent@GreatCircle.COM 1057 West Dana Street +1 415 962 0841 Mountain View, CA 94041 From Firewalls-Owner Tue Jul 20 18:19:12 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA24217; Wed, 21 Jul 93 01:15:07 GMT Received: from genesis.ecn.purdue.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA24208; Tue, 20 Jul 93 18:15:00 PDT Received: from localhost.ARPA by genesis.ecn.purdue.edu (5.0/2.8davy) id AA10192; Tue, 20 Jul 93 20:15:59 EST Message-Id: <9307210115.AA10192@genesis.ecn.purdue.edu> To: firewalls@GreatCircle.COM Subject: TAMU security package Date: Tue, 20 Jul 1993 20:15:50 EST From: "Philip R. Moyer" Content-Length: 284 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk I'm writing a review of the TAMU security package (Drawbridge, Netlog, and Tiger). If anyone has installed it and is using it on a daily basis, I'd be interested in hearing your comments, particularly any problems you had, and how you solved them. Cheers, Phil prm@ecn.purdue.edu From Firewalls-Owner Wed Jul 21 01:36:16 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA24331; Wed, 21 Jul 93 01:36:16 GMT Received: from research.att.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA24324; Tue, 20 Jul 93 18:36:07 PDT Message-Id: <9307210136.AA24324@mycroft.GreatCircle.COM> From: smb@research.att.com Received: by gryphon; Tue Jul 20 21:35:53 EDT 1993 To: Firewalls@GreatCircle.COM Subject: terminology Date: Tue, 20 Jul 93 21:35:53 EDT Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk I'm curious what terminology folks use for different parts of a firewall. I'll tell you my nomenclature (some taken from the net); I'd like to know what other terms are used, and what I've forgotten. First, I classify firewalls into three types, packet filters, circuit gateways (or relays), and application gateways. I assume the meaning of each is obvious. A filter (I've seen the word ``choke'' used) blocks some types of packets; in a packet-filter gateway, the filter is the main component. The host (or hosts) that talk past the filters are the gateways. Depending on the configuration, one of the machines may be an inside gateway, and one outside. The outside (or only) gateway lives on a net known as the DMZ. Finally, the whole collection of components is collectively referred to as the firewall. --Steve Bellovin From Firewalls-Owner Wed Jul 21 01:50:35 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA24396; Wed, 21 Jul 93 01:50:35 GMT Received: from localhost by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA24388; Tue, 20 Jul 93 18:50:22 PDT Message-Id: <9307210150.AA24388@mycroft.GreatCircle.COM> To: smb@research.att.com Cc: Firewalls@GreatCircle.COM Subject: Re: terminology In-Reply-To: Your message of Tue, 20 Jul 93 21:35:53 EDT Date: Tue, 20 Jul 93 18:50:21 -0700 From: Brent Chapman Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk # I'm curious what terminology folks use for different parts of a firewall. # I'll tell you my nomenclature (some taken from the net); I'd like to know # what other terms are used, and what I've forgotten. # # First, I classify firewalls into three types, packet filters, circuit # gateways (or relays), and application gateways. I assume the meaning # of each is obvious. A filter (I've seen the word ``choke'' used) # blocks some types of packets; in a packet-filter gateway, the filter # is the main component. The host (or hosts) that talk past the # filters are the gateways. Depending on the configuration, one # of the machines may be an inside gateway, and one outside. The # outside (or only) gateway lives on a net known as the DMZ. # # Finally, the whole collection of components is collectively referred # to as the firewall. # # --Steve Bellovin That pretty much checks with the usage I see, with the exception of "gateway". I like the terminology suggested in Marcus Ranum's "Thinking About Firewalls" paper (i.e., "screening router", "bastion host", "dual homed host", etc.). That's the terminology I use when I teach my Firewalls tutorial (though I often slip and say "filtering" instead of "screening"). I certainly refer to the exposed net as the "DMZ"; I have to explain the acronym to some folks, but it usually gets a chuckle. I think there's starting to be general consensus that the whole system is "the firewall", though that hasn't always been the case. -Brent -- Brent Chapman Great Circle Associates Brent@GreatCircle.COM 1057 West Dana Street +1 415 962 0841 Mountain View, CA 94041 From Firewalls-Owner Tue Jul 20 19:19:12 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA24527; Wed, 21 Jul 93 02:14:53 GMT Received: from genesis.ecn.purdue.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA24520; Tue, 20 Jul 93 19:14:41 PDT Received: from localhost.ARPA by genesis.ecn.purdue.edu (5.0/2.8davy) id AA10273; Tue, 20 Jul 93 21:15:40 EST Message-Id: <9307210215.AA10273@genesis.ecn.purdue.edu> To: firewalls@GreatCircle.COM Subject: Re: terminology Date: Tue, 20 Jul 1993 21:15:32 EST From: "Philip R. Moyer" Content-Length: 1697 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk My definition for firewall depends on the context of the conversation. If I'm talking to other systems administrators, who may not be as familiar with the issues, I use a very vague definition. In that conversation, a firewall is a software/hardware combination that sits between the secured network and the "outside" and prevents "some" traffic at the IP or TCP/ICMP/UDP level (that's really not defined). With this definition, packet filters and screening routers would all be "firewalls". On the other hand if I were talking to, say, you, I'd use the following definition: A Firewall(TM) is a piece of hardware that acts as a gateway between a secure network segment and an insecure network segment. Traffic going from the insecure segment to the secure segment is "inbound" traffic, and the reverse flow is "outbound" traffic. The critical function of the firewall is to translate inbound traffic to match the internal network design and vice versa. The insecure segment's view of the secure segment should not match reality. For example, mail sent to smb@securenet.com may in fact pass through the firewall, after having the address translated to smb@bitbucket.securenet.com. Outbound mail would have the addressing munged so as not to reveal internal networking details. DNS would be blocked at the firewall. No inbound packet would be directly dropped onto the secure segment. It would all be de-encapsulated, examined, then re-encapsulated and dropped out the other interface. An important thing to note here is that, for example, Drawbridge from TAMU isn't a firewall. It's a packet filter. Screening routers don't count as firewalls, either. Cheers, Phil From Firewalls-Owner Wed Jul 21 02:28:05 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA24574; Wed, 21 Jul 93 02:28:05 GMT Received: from capsicum.lcs.mit.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA24567; Tue, 20 Jul 93 19:27:58 PDT Received: by capsicum.lcs.mit.edu; id AA01444; Tue, 20 Jul 1993 22:28:54 -0400 Message-Id: <9307210228.AA01444@capsicum.lcs.mit.edu> To: smb@research.att.com Cc: Firewalls@GreatCircle.COM Subject: Re: terminology In-Reply-To: Message from smb@research.att.com of 20 Jul 93 21:35:53 EDT From: treese@lcs.mit.edu Date: Tue, 20 Jul 93 22:28:53 +28716 X-Mts: smtp Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk I sometimes use the term "application relay" for "application gateway". "relay" seems more appropriate when the application whatever-it-is is doing the same protocol on both sides, whereas "gateway" is more appropriate when the whatever-it-is speaks different protocols. Thus we have an "FTP relay" and a "SMTP-DECnet gateway". But I'm not completely consisten about it. I also tend to say "packet screen" rather than "packet filter", which probably has more to do with distinguishing it from the packet filter that Jeff Mogul developed for grabbing packets off the Ethernet. Win Treese MIT Laboratory for Computer Science DEC Cambridge Research Lab treese@lcs.mit.edu treese@crl.dec.com From Firewalls-Owner Wed Jul 21 02:48:04 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA24630; Wed, 21 Jul 93 02:48:04 GMT Received: from NMSU.Edu (dns1.NMSU.Edu) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA24623; Tue, 20 Jul 93 19:47:57 PDT From: amolitor@NMSU.Edu Received: from emmy (emmy.NMSU.Edu) by NMSU.Edu (4.1/NMSU-1.18) id AA15642; Tue, 20 Jul 93 20:48:56 MDT Date: Tue, 20 Jul 93 20:48:56 MDT Message-Id: <9307210248.AA15642@NMSU.Edu> Received: by emmy (4.1/NMSU) id AA22456; Tue, 20 Jul 93 20:48:55 MDT To: firewalls@GreatCircle.COM Subject: Re: terminology Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk I once defined a firewall as follow, in a paper I scribbled together once. If there's anything smart in the paper, this is it. Taking the point of view that it's processes, or 'entities' on either side of the firewall, and communication between them, that matters, and terming a process inside the firewall 'protected', while one outside is 'foreign': ---------- Each [i.e. every possible] process, on each side of the firewall, is assigned a number representing the trustworthiness of it. [...] Finally, we introduce a set of allowed connections, communications between protected and foreign processes which are permitted. The firewall is now viewed abstractly as this set of connections. Formally: Definition: A firewall is a set of ordered pairs of numbers strictly between 0 and 1. ----------- The two numbers in each ordered pair are the trustworthinesses of the two processes involved in the connection. I thought it was sort of nice, but I suspect it won't catch on ;) Andrew From Firewalls-Owner Wed Jul 21 16:13:30 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA28413; Wed, 21 Jul 93 16:13:30 GMT Received: from ncar.UCAR.EDU by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA28406; Wed, 21 Jul 93 09:13:22 PDT From: woods@ncar.UCAR.EDU (Greg Woods) Message-Id: <9307211614.AA07463@ncar.ucar.EDU> Received: by ncar.ucar.EDU (5.65/ NCAR Central Post Office 03/11/93) id AA07463; Wed, 21 Jul 93 10:14:20 MDT Subject: Re: terminology To: Firewalls@GreatCircle.COM Date: Wed, 21 Jul 93 10:14:19 MDT X-Mailer: ELM [version 2.3 PL11] Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk I hope it's OK to use this list to learn more about firewalls; I am relatively new to the world of security. We're one of those sites that has been on the net for years and been completely open for years that is now considering some kind of firewall due to repeated cracker incidents of various sorts (no malicious damage yet, but lots of staff time wasted cleaning up after breakins). I apologize if I ask some questions that are beneath the average level of the members of this list, but perhaps others can learn something too. > From: smb@research.att.com > Subject: terminology > Date: Tue, 20 Jul 93 21:35:53 EDT > First, I classify firewalls into three types, packet filters, circuit > gateways (or relays), and application gateways. I assume the meaning > of each is obvious. OK, I can guess that a packet filter is a router or set of routers, or hosts being used as routers, that are programmed to block at least some packets bound for hosts on the inside of a secured network. An application gateway would presumably be a host running something like SOCKS or Xforward. But what's a "circuit gateway"? I've never heard that term before. --Greg (woods@ncar.ucar.edu) From Firewalls-Owner Wed Jul 21 16:56:34 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA28507; Wed, 21 Jul 93 16:56:34 GMT Received: from research.att.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA28496; Wed, 21 Jul 93 09:56:23 PDT Message-Id: <9307211656.AA28496@mycroft.GreatCircle.COM> From: smb@research.att.com Received: by gryphon; Wed Jul 21 12:54:09 EDT 1993 To: woods@ncar.UCAR.EDU (Greg Woods) Cc: Firewalls@GreatCircle.COM Subject: Re: terminology Date: Wed, 21 Jul 93 12:54:08 EDT Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk I hope it's OK to use this list to learn more about firewalls; I am relatively new to the world of security. We're one of those sites that has been on the net for years and been completely open for years that is now considering some kind of firewall due to repeated cracker incidents of various sorts (no malicious damage yet, but lots of staff time wasted cleaning up after breakins). I apologize if I ask some que stions that are beneath the average level of the members of this list, but perhaps others can learn something too. No problem with asking questions. OK, I can guess that a packet filter is a router or set of routers, or hosts being used as routers, that are programmed to block at least some packets bound for hosts on the inside of a secured network. An application gateway would presumably be a host running something like SOCKS or Xforward. But what's a "circuit gateway"? I've never heard that term before. An application gateway is one that understands something of the semantics of the connection. Thus, the DEC SEAL gateway that looks at ftp commands would qualify, as would a mail relay that was selected via MX records. A circuit gateway is a TCP-level relay, one that doesn't try to figure out what's going to happen with it. I personally classify SOCKS as a circuit gateway, and Xforward as application-level, since it's geared rather specifically towards the needs of that one protocol. From Firewalls-Owner Wed Jul 21 17:34:50 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA28907; Wed, 21 Jul 93 17:34:50 GMT Received: from relay1.UU.NET by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA28900; Wed, 21 Jul 93 10:34:42 PDT Received: from spool.uu.net (via LOCALHOST) by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA04491; Wed, 21 Jul 93 13:35:33 -0400 Date: Wed, 21 Jul 93 13:35:33 -0400 From: uworld!uucp@uunet.uu.net Message-Id: <9307211735.AA04491@relay1.UU.NET> Received: from uworld.UUCP by spool.uu.net with UUCP/RMAIL (queueing-rmail) id 133329.18430; Wed, 21 Jul 1993 13:33:29 EDT Apparently-To: Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >From rik Wed Jul 21 10:07:29 1993 remote from crow Reply-To: crow!rik Received: by crow.spirit.com (4.1/SMI-4.1) id AA19742; Wed, 21 Jul 93 10:07:29 MST Date: Wed, 21 Jul 93 10:07:29 MST From: crow!rik (Rik Farrow) Message-Id: <9307211707.AA19742@crow.spirit.com> To: uworld!uunet!GreatCircle.com!Firewalls Subject: Re: terminology Like Brent Chapman, I use the terminology described in Marcus Ranum's "Thinking about Firewalls" paper in my TCP/IP security tutorials. I don't understand what Steve Bellovin means by "circuit gateways" (unless he is describing a secure subnet between screening routers or dual-homed hosts). I also find myself in disagreement with Phil Moyer, who said A Firewall(TM) is a piece of hardware that acts as a gateway between a secure network segment and an insecure network segment. Who has trademarked the term "Firewall"? Besides, this definition is much too limited. Some sites only use a screening router between themselves and an "insecure network", while others use combinations of specially configured workstations, routers, and software. The software is a key element to making a firewall function correctly (and has also been the downfall of many security solutions). While some argue that dual-homed hosts running proxy servers (an application gateway) are the only way to create a firewall, this isn't reflected in reality. Using screening routers is much more common. I will agree with anyone who says that using screening routers is less secure than other approaches, but may be sufficent for a small site which can provide good, secure host configuration for a handful of systems. Rik Farrow rik@uworld.com From Firewalls-Owner Wed Jul 21 23:50:14 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA00255; Wed, 21 Jul 93 23:50:14 GMT Received: from cmsa.Berkeley.EDU by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA00246; Wed, 21 Jul 93 16:50:08 PDT Received: from PCCCP6.BITNET by cmsa.Berkeley.EDU (IBM VM SMTP V2R2) with BSMTP id 9615; Wed, 21 Jul 93 16:50:09 PDT Received: from JV@PCCCP6 by CP-6 BitNet Exporter B02 @PCCCP6;21 JUL 93 16:47:21 PDT Received: from JV@PCCCP6 by CP-6 MAIL Exporter B02 @PCCCP6;21 JUL 93 16:47:17 PD T Date: 21 JUL 93 16:46:01 PDT From: VALLUZZI JIM To: X-Orig-To: Firewalls@GreatCircle.COM Subject: Information about H.P./Wellfleet routers Message-Id: <930721.16460014.070555@PCC.CP6> Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk I am looking for information about H.P./Wellfleet routers We currently have some and have to use them. Has anyone had any experience with them? We are trying to do packet and services filtering and have had no luck. Jim Valluzzi, Network Specialist Information Services [503] 244-6111 ext. 4713 Portland Community College, Portland, OR. 97280-0990 U.S.A. From Firewalls-Owner Thu Jul 22 03:14:18 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA00855; Thu, 22 Jul 93 03:14:18 GMT Received: from genesis.ecn.purdue.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA00848; Wed, 21 Jul 93 20:14:08 PDT Received: from localhost.ARPA by genesis.ecn.purdue.edu (5.0/2.8davy) id AA11749; Wed, 21 Jul 93 22:15:08 EST Message-Id: <9307220315.AA11749@genesis.ecn.purdue.edu> To: firewalls@GreatCircle.COM In-Reply-To: Your message of "Wed, 21 Jul 1993 13:35:33 EST." <9307211735.AA04491@relay1.UU.NET> Date: Wed, 21 Jul 1993 22:14:58 EST From: "Philip R. Moyer" Content-Length: 1281 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >Who has trademarked the term "Firewall"? Besides, this definition is >much too limited. Some sites only use a screening router between themselves Nobody's trademarked it. That was levity, to differentiate between the generic term firewall (with a lowercase 'f') which I defined as an ambiguous security device to limit network traffic. This seems to be the way you use "firewall", from your description below. >reality. Using screening routers is much more common. I will agree with >anyone who says that using screening routers is less secure than other >approaches, but may be sufficent for a small site which can provide good, >secure host configuration for a handful of systems. I agree that screening routers are both more common and probably effective. But a screening router is _technically_ not a firewall (IMO). That's the distinction I was trying to make in my mail to Steve Bellovin. There's a difference between "firewall" and "Firewall" (I'll leave off the TM :-). In general conversation, I use the term "firewall" like you do, to mean a generic method of protecting a network segment. It can be a packet filter, a real Firewall, or whatever. But I also gave my technical definition of a firewall. I guess I just didn't make it clear. Cheers, Phil From Firewalls-Owner Thu Jul 22 11:45:09 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA02391; Thu, 22 Jul 93 11:45:09 GMT Received: from research.att.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA02382; Thu, 22 Jul 93 04:45:03 PDT Message-Id: <9307221145.AA02382@mycroft.GreatCircle.COM> From: ches@research.att.com Date: Thu, 22 Jul 93 07:44:52 EDT To: firewalls@GreatCircle.COM Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >I don't understand what Steve Bellovin means by "circuit gateways" This refers to TCP-level gating services provided by `socks' and our proxy library. Bill Cheswick Bell Labs From Firewalls-Owner Thu Jul 22 18:07:50 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA03598; Thu, 22 Jul 93 18:07:50 GMT Received: from gossip.pyramid.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA03591; Thu, 22 Jul 93 11:07:42 PDT Received: from shield.eng.pyramid.com by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway) id AA24072; Thu, 22 Jul 93 11:09:20 -0700 Received: by shield.eng.pyramid.com (5.67/DC/OSx1.1) id AA27354; Thu, 22 Jul 93 18:08:44 GMT From: mfrost@pyramid.com (Mark Frost) Message-Id: <9307221108.ZM27352@shield.eng.pyramid.com> Date: Thu, 22 Jul 1993 11:08:43 -0700 X-Mailer: Z-Mail (2.1.4 29apr93) To: firewalls@GreatCircle.COM Subject: Gatewaying UDP services (and socks) Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk We've gotten quite a lot of mileage out of socks. However, there are still those other wonderful services like archie (and a bunch of other ones I haven't even looked into yet like mosaic and world-wide-web that I haven't even looked into yet) that we would like to be able to use across our firewall system. I remember hearing about how difficult it is to do proxy services with UDP packets. Has anyone come up with a solution to this yet? I don't really like the idea of using a screening router, but in light of some of the services we'd like to get, it's looking better and better all the time. Thanks -m----------- Mark "Hoek" Frost (mfrost@pyramid.com) ---mmm--------- R&D Lab Manager Group -----mmmmm------- Pyramid Technology Corporation -------mmmmmmm----- 3860 North First Street ---------mmmmmmmmm--- San Jose, California 95134 (408) 428-8163 From Firewalls-Owner Thu Jul 22 22:28:05 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA04275; Thu, 22 Jul 93 22:28:05 GMT Received: from telemann.inoc.dl.nec.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA04268; Thu, 22 Jul 93 15:27:55 PDT Received: by telemann.inoc.dl.nec.com (4.1/YDL1.9-920831.09) id AA27157(telemann.inoc.dl.nec.com); Thu, 22 Jul 93 17:28:54 CDT Received: by texas.syl.dl.nec.com (4.1/YDL1.9-930614.17) id AA19150(texas.syl.dl.nec.com); Thu, 22 Jul 93 17:28:52 CDT Received: by florida.syl.dl.nec.com (4.1/YDL1.9-920708.13) id AA00997(florida.syl.dl.nec.com); Thu, 22 Jul 93 17:28:46 CDT Date: Thu, 22 Jul 93 17:28:46 CDT From: ylee@syl.dl.nec.com (Ying-Da Lee) Message-Id: <9307222228.AA00997@florida.syl.dl.nec.com> To: firewalls@GreatCircle.COM, mfrost@pyramid.com Subject: Re: Gatewaying UDP services (and socks) Cc: ylee@syl.dl.nec.com Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >We've gotten quite a lot of mileage out of socks. However, there are still >those other wonderful services like archie (and a bunch of other ones I >haven't even looked into yet like mosaic and world-wide-web that I haven't >even looked into yet) that we would like to be able to use across our >firewall system. NCSA's Mosaic makes available to you all the goodies of World Wide Web AND Archie, not to mention Gopher & Veronica, WAIS, FTP, Finger, X.500, TeXinfo, Techinfo, Hytelnet, Hyper-G, and a couple others. It warns you about how slow it is going through it to access Archie, but I have not found the delays to be intolerable. Still, Xarchie is nicer. My next SOCKS release will have an xmosaic client, among other new features. A few people are testing it now and I expect to have it released soon. Contact me if you just can't wait. >I remember hearing about how difficult it is to do proxy services with UDP >packets. Has anyone come up with a solution to this yet? I don't really >like the idea of using a screening router, but in light of some of the >services we'd like to get, it's looking better and better all the time. Xarchie uses UDP. That is the only strong temptation now for me to consider force-feeding UDP into SOCKS. HP users are in luck as I have reason to believe that an HP-specific version of SOCKS with UDP support and all sorts of clients will be available soon. I don't think the author is on this mailing list though. 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 Thu Jul 22 23:59:58 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA04590; Thu, 22 Jul 93 23:59:58 GMT Received: from uu3.psi.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA04583; Thu, 22 Jul 93 16:59:49 PDT Received: from bacon.UUCP by uu3.psi.com (5.65b/4.0.071791-PSI/PSINet) via UUCP; id AA11111 for ; Thu, 22 Jul 93 19:54:32 -0400 Received: from webster.imsi.com by bacon.IMSI.COM (4.1/SMI-4.1) id AA27135; Thu, 22 Jul 93 19:20:00 EDT Received: from localhost by webster.imsi.com (4.1/SMI-4.1) id AA22177; Thu, 22 Jul 93 19:17:04 EDT Message-Id: <9307222317.AA22177@webster.imsi.com> To: mfrost@pyramid.com (Mark Frost) Cc: firewalls@GreatCircle.COM Subject: Re: Gatewaying UDP services (and socks) In-Reply-To: Your message of "Thu, 22 Jul 1993 11:08:43 PDT." <9307221108.ZM27352@shield.eng.pyramid.com> Reply-To: rens@imsi.com Date: Thu, 22 Jul 1993 19:17:04 -0400 From: Rens Troost Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >>>>> On Thu, 22 Jul 1993 11:08:43 -0700, mfrost@pyramid.com (Mark Frost) said: mfrost> We've gotten quite a lot of mileage out of socks. However, mfrost> there are still those other wonderful services like archie mfrost> (and a bunch of other ones I haven't even looked into yet mfrost> like mosaic and world-wide-web that I haven't even looked mfrost> into yet) that we would like to be able to use across our mfrost> firewall system. Socks is indeed great. WWW is TCP-based, so you can easily retrofit xmosaic to use socks; it took me less than an hour. If there is demand I'll make the diffs available. mfrost> I remember hearing about how difficult it is to do proxy mfrost> services with UDP packets. Has anyone come up with a mfrost> solution to this yet? I don't really like the idea of using mfrost> a screening router, but in light of some of the services mfrost> we'd like to get, it's looking better and better all the mfrost> time. I would stay away from letting any UDP accross the firewall, although I guess if you restricted incoming UDP to a small number of ports on a small number of machines with source routing quenched might be ok. Make sure the ports are never in the range that could be dynamically assigned to some RPC service. What is really needed is a prospero gateway; has anybody looked into this? -Rens From Firewalls-Owner Wed Jul 28 15:55:17 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA24066; Wed, 28 Jul 93 15:55:17 GMT Received: from tigger.jvnc.net by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA24059; Wed, 28 Jul 93 08:55:09 PDT Received: by tigger.jvnc.net id AA16454 (5.65c/IDA-1.4.4 for firewalls@greatcircle.com); Wed, 28 Jul 1993 11:56:21 -0400 Date: Wed, 28 Jul 1993 11:56:21 -0400 From: Moodys Investors Service Message-Id: <199307281556.AA16454@tigger.jvnc.net> To: firewalls@GreatCircle.COM Subject: ASET/ARM Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Hi All- For what it's worth (FWIW): I was at a meeting at Coopers/Lybrand and the ANS CO+RE person formerly fo gtech was there. I got plaster'd later, so I forgot his name but he seemed nice and told me that Sun will spin off [ much deleted... ] a firewall application. Of course, I didnt tell you this. Oh, BTW, to those concerned about my flagrant hacking, the router guy reconfigured something, and now I can unhack my gateway. Yours- John van Vlaanderen aka moodys@tigger.jvnc.net From Firewalls-Owner Wed Jul 28 10:25:18 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA24365; Wed, 28 Jul 93 16:52:42 GMT Received: from tigger.jvnc.net by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA24358; Wed, 28 Jul 93 09:52:34 PDT Received: by tigger.jvnc.net id AA19199 (5.65c/IDA-1.4.4 for firewalls@greatcircle.com); Wed, 28 Jul 1993 12:53:41 -0400 Date: Wed, 28 Jul 1993 12:53:41 -0400 From: Moodys Investors Service Message-Id: <199307281653.AA19199@tigger.jvnc.net> To: firewalls@GreatCircle.COM Subject: ASET/ARM Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk p.s. - Y'all are the best ;^) From Firewalls-Owner Wed Jul 28 21:19:19 1993 Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA27309; Wed, 28 Jul 93 21:19:19 GMT Received: from halon.sybase.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA27302; Wed, 28 Jul 93 14:19:10 PDT Received: from sybase.com (sybgate.sybase.com) by halon.sybase.com (5.0/SMI-SVR4/SybFW4.0) id AA03299; Wed, 28 Jul 93 14:21:28 PDT Received: from shandra.sybgate.sybase.com by sybase.com (4.1/SMI-4.1/SybH3.2) id AA12357; Wed, 28 Jul 93 14:21:23 PDT Received: by shandra.sybgate.sybase.com (5.0/SMI-4.1/SybEC3.1) id AA00776; Wed, 28 Jul 93 14:21:17 PDT Date: Wed, 28 Jul 93 14:21:17 PDT From: tims@sybase.com (Tim Swilling) Message-Id: <9307282121.AA00776@shandra.sybgate.sybase.com> To: firewalls@GreatCircle.COM Subject: Need info Cc: tims@sybase.com X-Sun-Charset: US-ASCII Content-Length: 701 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Hi, Someone recomended I send e-mail to find out more information on setting up proxy servers to the internet. Specifically, my company, Sybase, Inc. need to set up a secure proxy server that connects to the internet. We need some software that would run on a Sun4m server running Solaris2.2. I'm not sure what "firewalls@GreatCircle.COM" alias does. If you could send me some information on it, and how to subscribe, I'd appreciate it. Thanks, - Tim Swilling --------------------------------------------------- - Tim Swilling - CS - Systems Administrator Sybase, Inc. Emeryville, CA. PH# (510) 596-3834 email - Tim.Swilling@sybase.com ---------------------------------------------------