-------- From academic-firewalls-owner@net.tamu.edu Mon Mar 18 09:20:43 1996 Content-Type: text/plain Mime-Version: 1.0 (NeXT Mail 3.3 v118.2) References: Date: Mon, 18 Mar 96 09:15:36 -0600 From: Dave Hess To: academic-firewalls@net.tamu.edu Subject: Re: The list The behaviour of this list is rather odd. There are over 1000 subscriptions to the list yet hardly anybody ever posts to it. Discussions will start up in a flurry and then die down again such that nobody posts for a month or two at a time. It seems that everyone wants to lurk and learn but nobody wants to initiate any kind of discussion on these issues. BTW, two administrative notes: 1) Due to the load that this last flurry put on our server (and the content of most of the messages), the reply-to field no longer points back to the list; it points to the sender of the message. You are going to have to override it to send your response back to the list from now on. 2) We think we have fixed the filter that should have been catching those subscribe/unsubscribe requests that some people seem to love to send to the list. Dave - --- David K. Hess Network Analyst David-K-Hess@tamu.edu Computing and Information Services - Network Group (409) 845-0372 (work) Texas A&M University -------- From academic-firewalls-owner@net.tamu.edu Mon Mar 18 23:16:19 1996 X-Sender: swift@miya.llnl.gov Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 18 Mar 1996 20:49:10 -0800 From: uncl@llnl.gov (Fence-Walker (UNCL-afoot)) To: academic-firewalls@net.tamu.edu Subject: CIAC Notes 96-01 Date: Mon, 18 Mar 1996 18:49:51 -0800 (PST) Reply-To: fisher@bill.llnl.gov Originator: ciac-bulletin@cheetah.llnl.gov Sender: ciac-bulletin@cheetah.llnl.gov Precedence: bulk From: fisher@bill.llnl.gov (John M. Fisher) To: uncl@llnl.gov Subject: CIAC Notes 96-01 CIAC is sending this addition of CIAC Notes to the CIAC Bulletins list because of the high demand for information on Java and JavaScript vulnerabilities. - -----BEGIN PGP SIGNED MESSAGE----- ___ __ __ _ ___ __ __ __ __ __ / | /_\ / |\ | / \ | |_ /_ \___ __|__ / \ \___ | \| \__/ | |__ __/ Number 96-01 March 18, 1996 This edition of CIAC NOTES includes: 1) Java and JavaScript Vulnerabilitites 2) FIRST Conference Announcement 3) Security and Web Search Engines 4) Microsoft Word Macro Virus Update Please send your comments and feedback to ciac@llnl.gov. $-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$ $ Reference to any specific commercial product does not necessarily $ $ constitute or imply its endorsement, recommendation or favoring by $ $ CIAC, the University of California, or the United States Government.$ $-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$ ========================================================================= 1) Java and JavaScript Vulnerabilities ========================================================================= By John Fisher Introduction - - ------------ Over the past several weeks, a variety of reports have surface regarding security problems with Java and JavaScript. Java was developed by Sun Microsystems Incorporated, and JavaScript was developed by Netscape Incorporated. Java is available directly from Sun through the Java Development Kit. Both Java and JavaScript are supported with Netscape Navigator 2.0. Although similiar in name, and in some ways similiar in syntax, these two languages are vastly different in their usage. Accordingly, the security problems that have been reported are completely separate as well. This article maps out what problems have been reported and discusses the availability of solutions. Java applications communicate easily across a network environment, particularly the Internet. Although not initially intended for this environment, Java became a natural mechanism for enhancing the usability and functionality of the World-Wide Web. With Java "applets," a Web site can provide functionality for its visitors that is not available with HTML code. Java can be used in a variety of different capacities. A standard Java application can work stand-alone, providing functionality similar to other programming languages (i.e., file input/output, graphical interfaces, etc). When a Java application is made available on a Web site (via an HTML Web page), it is in the form of a Java applet. An applet is given definite restrictions on its capabilities. For example, a Java applet can not write files to a Web visitor's local disk drive, or contact an Internet site besides the server it was downloaded from. Java was supported with Netscape's Navigator 2.0, released in February. JavaScript is also supported in Navigator 2.0. Originally named LiveScript, JavaScript code is placed directly in the text of an HTML document (as opposed to being referenced in the HTML, similar to how an image would be included, like Java does). For browsers that don't understand JavaScript, JavaScript code simply seems to be a comment in the HTML code. For Navigator 2.0, a JavaScript program can provide additional functionality for the Web page that can't be provided with just HTML. While JavaScript provides increased functionality, it is syntactically simpler and less powerful than Java. Both Java and JavaScript have been developed with security in mind. Both were developed with considerable emphasis on preventing a Web site from gaining unintended access to a Web user's system or from performing actions on behalf of the Web user without the user's knowledge. Unfortunately, as is common with new technologies, unanticipated security concerns have come to light. The next section addresses the latest security concerns for Java and the section following addresses security issues for JavaScript. Java Problems - - ------------- The security problems reported about Java exist both in Netscape's Navigator 2.0 and in the Java Devlopment Kit 1.0 from Sun Microsystems. Solutions to both problems are provided below. DNS Attack In January, three students at Princeton University (Drew Dean, Ed Felten, and Dan Wallach) discovered a way to use Java to exploit a well-known Domain Name Service (DNS) vulnerability. Note that this is not a vulnerability with Java, per se. It is really a vulnerability with DNS that Java does not check for. DNS servers provide a means for translating between host names and IP addresses. For example, if a computer on the Internet were to initiate a connection to the machine ciac.llnl.gov, the local DNS server for that machine with resolve the host name as representing the IP address 128.115.19.53. Java applets running under Sun's appletviewer or Netscape's Navigator 2.0 are only allowed to connect the host from which they originated. To allow an applet to connect to other hosts would be dangerous, as the applet would be acting on behalf of the user who downloaded the applet. Imagine downloading an applet from a Web site, only to find that the applet sent mail to another system, acting as you. What's worse, without this restriction, a Java applet would have all the access capabilities your machine does, including accessing hosts behind a firewall. The problem occurs because Java does not completely verify that the information provided by the DNS server is accurate. Thus, if one can corrupt the DNS server, it is possible to trick a Java applet into accessing an arbitrary host. The potential for corrupting the information in DNS servers is a known problem. See, for example, CIAC Bulletin G-14, Domain Name Services Vulnerabilities. CLASSPATH Attack In February, David Hopwood of Oxford University made public another security problem with Java related to the loading of local class libraries. Java provides a class loading capability which allows a Java applet to load a class either from the host it originated from or from the user's local system. Java applets residing on the user's local system are allowed special capabilities such as reading and writing files or executing processes. Either of these tasks can cause serious security problems if not used properly. But, for large Java applets connecting to recognized hosts, the additional functionality provided by placing class libraries on a local system may be warranted. Ordinarily, an applet is restricted to loading applets from the directories specified in the environment variable CLASSPATH. However, Hopwood discovered a way to load class libraries from any readable directory on a user's system. This means that by placing a malicious class file and a dynamic library on the user's system, an attacker can open that system to attack. JavaScript Problems - - ------------------- Several different security problems have been identified with JavaScript as well. Some of these vulnerabilities existed only in the public beta distributions made available by Netscape Navigator 2.0. Others still were present in the final release. The various problems reported include the following: (1) Reading a user's URL history list and transmitting it to a remote site. (2) Reading a user's disk cache (containing URLs recently acquired by the Web browser) and sending the information to the Web server. (3) Stealing the e-mail address of the Web user and forging an e-mail message with it. (4) Obtaining a recursive listing of local disk directories. (5) Logging all URL accesses made by a Web browser and transmitting the information to a remote system. Problems (1) and (2) were fixed in the final release of Netscape Navigator 2.0. The other problems were fixed in the latest release, described below. Solutions - - --------- Netscape solution In late Februrary, Netscape made a patch available to solve the DNS server problem. On March 14, Netscape released Navigator 2.01, which fixed all of the vulnerabilities described above. It can be found at: http://home.netscape.com Sun Microsystems solution On March 15, Sun released Java Development Kit 1.0.1, which fixed all of the vulnerabilities described above. It can be found at: http://java.sun.com ========================================================================= 2) FIRST Conference Announcement ========================================================================= The Forum of Incident Response and Security Teams (FIRST) is an international organization that brings together a variety of computer security incident response teams. These teams include government agencies, commercial companies, academic organizations and computer vendors. This year the 8th FIRST Conference and Workshop on Computer Security Incident Handling and Response will be held in Santa Clara, CA, July 28-31, 1996. For more information on the conference, please go to: http://ciac.llnl.gov/firstconf ========================================================================= 2) Security and Web Search Engines ========================================================================= By John Fisher A variety of very powerful search engines are available on the Internet, including Netscape (http://home.netscape.com/home/internet-search.html), Yahoo (http://www.yahoo.com), Alta Vista (http://altavista.digital.com), Lycos (http://www.lycos.com), and others. These engines, known as "web crawlers," provide a means for users to find URLs matching keywords. Their databases are populated by gathering up all of the available information provided by any Web server that can be found. The Alta Vista database, for example, contains an index over 30 gigabytes in size. But, perhaps, these search engines have become a little too powerful. Some Web sites have provided a few too many links, including information related to system configuration. For example, doing a search for keywords such as "root", "daemon:", "passwd", etc, will return back a few stray /etc/passwd or /etc/group files, located on systems that have very poor Web configurations. This is a way to quickly find those Web sites that are not maintained very well and are most vulnerable to attack. So, the lesson here, if you maintain a Web site, be very sure of what information you are making available. Make sure no URLs are available which give configuration information about your system. With today's advanced search engines, you may be opening yourself to unnecessary problems. ========================================================================= 2) Microsoft Word Macro Virus Update ========================================================================= By Bill Orvis Here is the latest news on the Microsoft Word Macro Virus: 1. CIAC Bulletin G-10 has been revised to G-10a. 2. It needs to be emphasized that the scanning software from Microsoft only works if you open a document using the File, Open command. It does not work if you double click or drag and drop a document. It may not work if you open an attached document from within a mailer program. 3. The scanning software from Microsoft comes in three versions: mvtool10.exe English version mvtool20.exe International version 1 (defaults to English) mvtool30.exe International version 2 (defaults to English) For English speaking peoples, all three of these scanners will give the same results. 4. The scanner works in Word 6 on the Macointosh as well, but the file mvtool10.exe must be uncompressed on a PC first. Once it is uncompressed, it can be copied to a Macintosh system and loaded into Word. 5. If you save a document in any format that does not have macros, the macros can not be passed on. For example, on an infected machine, saving a file in Macintosh Word 5 format would not pass a macro virus. Safe formats include: Any Macintosh format earlier than 6, rtf, text only, WordPerfect, Word for Windows 1, Word for MS-DOS. Note that you may lose special formatting when converting to some of these other file formats. 6. The Wordview reader (Windows only) can be used to display or print the contents of a Word file. The reader completely ignores any attached macros. This would also be a good choice for use with a mail reader that wants to launch an application to display a formatted document. 7. There is currently no scanner for Excel, and only one known Excel macro virus. ============================================================================ CIAC, the Computer Incident Advisory Capability, is the computer security incident response team for the U.S. Department of Energy (DOE) and the National Institutes of Health (NIH). CIAC is located at the Lawrence Livermore National Laboratory in Livermore, California. CIAC is also a founding member of FIRST, the Forum of Incident Response and Security Teams, a global organization established to foster cooperation and coordination among computer security teams worldwide. CIAC services are available to DOE, DOE contractors, and the NIH. CIAC can be contacted at: Voice: +1 510-422-8193 FAX: +1 510-423-8002 STU-III: +1 510-423-2604 E-mail: ciac@llnl.gov For emergencies and off-hour assistance, DOE, DOE contractor sites, and the NIH may contact CIAC 24-hours a day. During off hours (5PM - 8AM PST), call the CIAC voice number 510-422-8193 and leave a message, or call 800-759-7243 (800-SKY-PAGE) to send a Sky Page. CIAC has two Sky Page PIN numbers, the primary PIN number, 8550070, is for the CIAC duty person, and the secondary PIN number, 8550074 is for the CIAC Project Leader. Previous CIAC notices, anti-virus software, and other information are available from the CIAC Computer Security Archive. World Wide Web: http://ciac.llnl.gov/ Anonymous FTP: ciac.llnl.gov (128.115.19.53) Modem access: +1 (510) 423-4753 (28.8K baud) +1 (510) 423-3331 (28.8K baud) CIAC has several self-subscribing mailing lists for electronic publications: 1. CIAC-BULLETIN for Advisories, highest priority - time critical information and Bulletins, important computer security information; 2. CIAC-NOTES for Notes, a collection of computer security articles; 3. SPI-ANNOUNCE for official news about Security Profile Inspector (SPI) software updates, new features, distribution and availability; 4. SPI-NOTES, for discussion of problems and solutions regarding the use of SPI products. Our mailing lists are managed by a public domain software package called ListProcessor, which ignores E-mail header subject lines. To subscribe (add yourself) to one of our mailing lists, send the following request as the E-mail message body, substituting CIAC-BULLETIN, CIAC-NOTES, SPI-ANNOUNCE or SPI-NOTES for list-name and valid information for LastName FirstName and PhoneNumber when sending E-mail to ciac-listproc@llnl.gov: subscribe list-name LastName, FirstName PhoneNumber e.g., subscribe ciac-notes OHara, Scarlett W. 404-555-1212 x36 You will receive an acknowledgment containing address, initial PIN, and information on how to change either of them, cancel your subscription, or get help. PLEASE NOTE: Many users outside of the DOE, ESnet, and NIH computing communities receive CIAC bulletins. If you are not part of these communities, please contact your agency's response team to report incidents. Your agency's team will coordinate with CIAC. The Forum of Incident Response and Security Teams (FIRST) is a world-wide organization. A list of FIRST member organizations and their constituencies can be obtained by sending email to docserver@first.org with an empty subject line and a message body containing the line: send first-contacts. This document was prepared as an account of work sponsored by an agency of the United States Government. Neither the United States Government nor the University of California nor any of their employees, makes any warranty, express or implied, or assumes any legal liability or responsibility for the accuracy, completeness, or usefulness of any information, apparatus, product, or process disclosed, or represents that its use would not infringe privately owned rights. Reference herein to any specific commercial products, process, or service by trade name, trademark, manufacturer, or otherwise, does not necessarily constitute or imply its endorsement, recommendation or favoring by the United States Government or the University of California. The views and opinions of authors expressed herein do not necessarily state or reflect those of the United States Government or the University of California, and shall not be used for advertising or product endorsement purposes. - -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: Processed by Mailcrypt 3.3, an Emacs/PGP interface iQCVAwUBMU3mqrnzJzdsy3QZAQGW9wQAzFvbhwJWdPKNwdW+pO1uiA/xIw4z/VqC /4Ma+Kl/Ei9egmeTlDebBp7h9iqk7K6EzE+IfhCf5z8XHcNRnnQBiZgF/yWTnHKA gZvUxrnXyTlXlB2Obl2fITFGh/Z2WR/Ccw5JWxhUqKDtCuB86fAdvpDRyjeUcy4w g1P44CnQrNs= =+YAS - -----END PGP SIGNATURE----- Frank R. Swift Computer Security Lawrence Livermore National Laboratory Voice (510) 422-1463 Fax (510) 423-0913 uncl@llnl.gov PGP Key fingerprint = 1A 14 02 5A 76 B2 BD 47 C0 3E ED 9A C5 3B 81 2D -------- From academic-firewalls-owner@net.tamu.edu Tue Mar 19 10:43:16 1996 X-Mailer: Novell GroupWise 4.1 Date: Tue, 19 Mar 1996 11:42:49 -0500 From: ALICE BRAINERD To: academic-firewalls@net.tamu.edu Subject: Re: -Reply Several months ago there was a network security survey, I believe, and the publication of the resulting summary of responses received. Apparently that process slowed subsequent discussion. This list appears to be dormant for weeks/months and then become very active as a topic of interest arises. Perhaps one of you have such a topic/question/issue to present. I am a an IS auditor who has found the discussions of the past occasionally very interesting, although off-topic discussions such as this can also create flurries of activity. Hope someone finds some a pertinenet topic soon. -- Alice Brainerd, Johns Hopkins U. -------- From academic-firewalls-owner@net.tamu.edu Tue Mar 19 11:28:07 1996 X-Sender: jemmett@goodnet.com X-Mailer: Windows Eudora Version 2.1.1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 19 Mar 1996 10:20:59 -0700 From: David Jemmett To: academic-firewalls@net.tamu.edu Subject: unsubscribe unsubsribe Thanks _______________________ GoodNet, LLC David Jemmett 602-303-9500 ext 224 602-303-0550 Fax _______________________ -------- From academic-firewalls-owner@net.tamu.edu Wed Mar 20 07:45:10 1996 Date: Wed, 20 Mar 96 13:40:52 GMT From: Dave Mitchell To: academic-firewalls@net.tamu.edu Subject: using passive ftp Since people have been complaining about lack of activity on academic-firewalls, here's something to get the ball rolling.... I currently use a packet filter (drawbridge) to protect machines within my dept from the worst excesses of the World Out There. However, this is severely compromised by having to allow in TCP connections with a src port of 20, in order to support the "standard" ftp client data connection. I would like it so that all the ftp clients in my dept use passive mode; however this must be achieved without the users having to do anything different. So what I need to do is to go around and change all the ftp clients in use. This is the tricky bit. Presumably some clients already use passive mode, some could be made to do it by a change in a global config file, some might need source changes, some will never support it, etc etc... What I would like to do is build a list of ftp clients for various platforms (PC, Mac, UNIX x N) with details what is needed to make them passive. In an ideal world, one of you out there may have already got a completely passive-only setup. But more likely several of you will have different bits of the jigsaw. If you have any info, please let me know! Perosnally I'm a UNIX person, although there are Mac and Windows users in my dept. [ In case some of you are wondering what the hell I'm talking about, ftp works as follows. The ftp client establishes a TCP connection to the ftp server (the command connection), and uses it to send commands and receive status info back. When it wishes to transfer data, it asks the *server* to establish a 2nd TCP connection back to the client, over which the data is then transmitted. Having to allow this externally-initiated connection through the packet filter is what compromises the filtering severely. An alternative is for the *client* to establish the data connection instead ("passive mode") - this means that both connections are initiated from inside, and the filter can be set up to reject (nearly all) external connection requests. the hard bit is to make *all* clients use passive mode ] Dave. * David Mitchell, Systems Administrator, email: D.Mitchell@dcs.shef.ac.uk * Dept. Computer Science, Sheffield Uni. phone: +44 114-282-5573 * 211 Portobello St, Sheffield S1 4DP, UK. fax: +44 114-278-0972 * * Standards (n). Battle insignia or tribal totems * * >>>> Support Randal Schwartz! email fund@stonehenge.com for info <<<<< -------- From academic-firewalls-owner@net.tamu.edu Wed Mar 20 08:43:13 1996 In-Reply-To: <9603201340.AA13320@dcs.shef.ac.uk> from "Dave Mitchell" at Mar 20, 96 01:40:52 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Date: Wed, 20 Mar 1996 08:42:00 -0600 (CST) From: "Pug" To: academic-firewalls@net.tamu.edu Subject: Re: using passive ftp > [ In case some of you are wondering what the hell I'm talking about, > ftp works as follows. The ftp client establishes a TCP connection to the ftp > server (the command connection), and uses it to send commands and receive > status info back. When it wishes to transfer data, it asks the *server* > to establish a 2nd TCP connection back to the client, over which the > data is then transmitted. Having to allow this externally-initiated > connection through the packet filter is what compromises the filtering > severely. An alternative is for the *client* to establish the data > connection instead ("passive mode") - this means that both connections > are initiated from inside, and the filter can be set up to reject > (nearly all) external connection requests. the hard bit is to make *all* > clients use passive mode ] Now what I've always wondered is what the "correct" thing to do is when you go through 2 firewalls. I've been asked to help someone who people were having problems with passive connections going through 2 firewalls. Since my setup isn't as closed as their's is, I haven't researched this particular area yet. Ciao, - -- Richard Bainter Mundanely | OS Specialist - OMG/CSD Pug Generally | Applied Research Labs - U.Texas pug@arlut.utexas.edu | pug@eden.com | {any user}@pug.net Note: The views may not reflect my employers, or even my own for that matter. -------- From academic-firewalls-owner@net.tamu.edu Wed Mar 20 08:53:34 1996 Comments: Authenticated sender is Organization: ZDH-Bonn X-mailer: Pegasus Mail for Windows (v2.23DE) Date: Wed, 20 Mar 1996 15:45:13 +0100 From: o.spauka@zdh.handwerk.de Reply-To: o.spauka@zdh.handwerk.de To: academic-firewalls@net.tamu.edu Subject: Problems with forwarded mails Hi, I just recently subscribed to this list, so I may have gotten something wrong here. Every day , I get a couple of mails, obviously from other subscribers to this list. I thought this mailing list was supposed to be moderated, so that everyone received a collection of all the mails in O N E list, not dozens of single mails. Please stop forwarding me all those single mails, and send me just the one list containing them all. Thanx Oliver C. Spauka -------- From academic-firewalls-owner@net.tamu.edu Wed Mar 20 08:57:50 1996 Content-Type: text/plain Mime-Version: 1.0 (NeXT Mail 3.3 v118.2) References: <9603201340.AA13320@dcs.shef.ac.uk> Date: Wed, 20 Mar 96 08:56:32 -0600 From: Dave Hess To: academic-firewalls@net.tamu.edu Subject: Re: using passive ftp > Now what I've always wondered is what the "correct" thing to do is when > you go through 2 firewalls. I've been asked to help someone who people > were having problems with passive connections going through 2 firewalls. > Since my setup isn't as closed as their's is, I haven't researched this > particular area yet. I'm not convinced that the current implementation of PASV is the best solution for FTP. It assumes that the server is not firewalled against random port connections which is not necessarily true. Granted, that is preferable to the hole that source port filtering causes but it still is not the ideal solution. Anybody know of or care to propose a better solution? Dave - --- David K. Hess Network Analyst David-K-Hess@tamu.edu Computing and Information Services - Network Group (409) 845-0372 (work) Texas A&M University -------- From academic-firewalls-owner@net.tamu.edu Wed Mar 20 10:37:47 1996 Cc: academic-firewalls@net.tamu.edu In-Reply-To: <9603201340.AA13320@dcs.shef.ac.uk> from "Dave Mitchell" at Mar 20, 96 01:40:52 pm X-Mailer: ELM [version 2.4PL24PGP3 *ALPHA*] Content-Type: text Date: Wed, 20 Mar 1996 09:28:16 -0700 (MST) From: "Allen J. Newton" To: academic-firewalls@net.tamu.edu Subject: Re: using passive ftp Dave Mitchell wrote: > Subject: using passive ftp > > I currently use a packet filter (drawbridge) to protect machines > within my dept from the worst excesses of the World Out There. However, > this is severely compromised by having to allow in TCP connections with > a src port of 20, in order to support the "standard" ftp client data > connection. I would like it so that all the ftp clients in my dept > use passive mode; however this must be achieved without the users having > to do anything different. So what I need to do is to go around and > change all the ftp clients in use. This is the tricky bit. > > Presumably some clients already use passive mode, some could be made > to do it by a change in a global config file, some might need source > changes, some will never support it, etc etc... > > What I would like to do is build a list of ftp clients for various > platforms (PC, Mac, UNIX x N) with details what is needed to make them > passive. Hi, Dave, I'm glad you brought this up. For the *NIX platforms, you can obtain the SOCKS distribution from ftp.nec.com (SOCKS supports PASV, and the rftp client that comes with it uses it). SOCKSCAP and various other .DLLs exist to SOCKSify MSDOS/Win apps. I believe that SOCKScap is supported under OS/2 as well, but don't recall (I might need to look at that, soon). I use SOCKS v4.2.2 but understand v5 supports some UDP support (for pings/ tracerts, etc). The question I have, which I haven't gotten anyone to answer on the SOCKS mailing list (or the Linux-ISP mailing list when the topic came up there) is... How can I get NcFTP (which supports PASV and is advertised to work with SOCKS) v2.3.0 to work with SOCKS v4.2.2? I have worked on this for a long time, and haven't gotten it to work under Linux 1.2.13. Tried configuring and building SOCKS with either arg count for Rbind (3 or 4 args), it just WILL not build the data connection. rftp builds it in PASV mode just fine. I really don't want to have to comb through all the code, but if I can't find anyone in all the Internet who's dealt with this and done it, I guess I'll have to play pioneer. Do you have any ideas? Have you played with NcFTP? It's got a much nicer interface than vanilla ftp, and remembers where you've been, what directories you liked there, etc, and supports shortcuts for sitenames, etc. If you're not already on it, there is a SOCKS mailing list where these topics are discussed. I forget the sub address, but if you can't find it, email me directly and I'll look it up for you... And anyone else is welcome to give me their input on this as well. Thanks... - -- - ------------------------------------------------------------------------------- Allen J. Newton BASIS International Ltd, (505)-345-5232 5901 Jefferson NE, Albuquerque, New Mexico 87109 anewton@basis.com Network Administrator <*> -------- From academic-firewalls-owner@net.tamu.edu Wed Mar 20 12:49:59 1996 CC: academic-firewalls@net.tamu.edu, TEX@rmcs.cranfield.ac.uk Date: Wed, 20 Mar 1996 18:46:22 GMT From: Brian {Hamilton Kelly} To: academic-firewalls@net.tamu.edu Subject: RE: Problems with forwarded mails In message <199603201449.PAA16673@zdh.handwerk.de> (to academic-firewalls) of Wed, 20 Mar 1996 15:45:13 +0100, o.spauka@zdh.handwerk.de wrote: > I just recently subscribed to this list, so I may have gotten > something wrong here. You have... > Every day , I get a couple of mails, obviously from other > subscribers to this list. Ignoring the ones from idiots that are attempting to subscribe (or, worse, unsubscribe) by sending the message to the list as a whole, that's exactly how it should work. It's a mailing list: as such, anything sent to academic-firewalls@net.tamu.edu is exploded to all the subscribers to the list --- that's the way mailing lists work. > I thought this mailing list was supposed to be moderated, so that > everyone received a collection of all the mails in O N E list, not > dozens of single mails. I don't believe you meant "moderated": that's more usually something done to Usenet newsgroups. What you meant, I'm sure, is "digestified"; some mailing lists work in a form where all the postings over a period are put together in one mailing (as happens, for example, with texhax@tex.ac.uk, for the TeX community). This has the advantage of reducing the perceived volume of traffic, but with the disadvantage of loss of immediacy: if *you* post a query, no one will be able to respond until the weekly digest is mailed to all the subscribers. Some mailing lists exist both in a "send each mailing as it arrives" and a "send a digest of the week's traffic" mode: I can't remember any of them off the top of my head at present, but they do exist. For these, one needs to subscribe to, respectively, the-list or to the-list-digest. In either case, submissions are still sent to the-list@somewhere, but the contributions get mailed out as required to the two groups of subscribers. > Please stop forwarding me all those single mails, and send me just > the one list containing them all. To the best of my knowledge, academic-firewalls appears only in the non- digestified format. Therefore you'll either have to put up with the traffic, or unsubscribe (and please make sure you do this by sending the request to academic-firewalls-request@net.tamu.edu, and *not* to the list itself). - -- Brian {Hamilton Kelly} TeX@rmcs.cranfield.ac.uk Smail: School of Engineering & Applied Science, Royal Military College of Science, Shrivenham, SWINDON SN6 8LA, U.K. Phone: Swindon (01793) 785252 (UK), +44-1793-785252 (International) -------- From academic-firewalls-owner@net.tamu.edu Wed Mar 20 15:32:40 1996 In-Reply-To: <199603200700.BAA01134@net.tamu.edu> from "academic-firewalls-owner@net.tamu.edu" at Mar 20, 96 01:00:07 am X-Mailer: ELM [version 2.4 PL24 ME8b] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Date: Thu, 21 Mar 1996 09:27:18 +1200 (NZT) From: Russell Fulton To: academic-firewalls@net.tamu.edu Subject: Securing Public labs > discussions such as this can also create flurries of activity. Hope > someone finds some a pertinenet topic soon. -- Alice Brainerd, Johns > Hopkins U. > OK I'll bite. Up to now we have kept all our public labs IPX only. (Yeah, I know that anyone with enough clues can get trumpet winsock and packet drivers on to a diskete). We are now under a lot of pressure to load IP software on to all these machine so students can access web servers on campus. One of the things that worries us is that this will allow unauthenticated access to the university's network for large numbers of people and that breakin attempts will be very difficult to track back to individuals unless they are 'caugth in the act' which is unlikely, given the resources we have. Our CS department has been running tcp student network for a long time and has gone to great lengths to 1) keep their students contained within their own network and 2) to make sure that they know who was on any particular machine at any time. They took these measures after a spate of cracking from CS student accounts a few years ago. We are looking at buying a heap of Karl Bridges and using these in conjunction with an authentication server to firewall all our public labs. We have another motivation for this. Since Internet access is so expensive here (because of the very expensive international links to the US and OZ (Australia for those of you who don't know the local lingo :). We charge all departments by volume. (Rates are around $US0.50/MB during the day). Most departments, therefore, don't allow access to the Internet for undergraduates. So we are looking at using the authentication system in conjunction with Netramet (a locally developed network traffic meter) to account for student usage so we can set up a billing system. My questions are: What do others do about securing Public labs? Do you have many problems with cracking from them? Cheers, Russell. +-------------------------------------------------------------------+ | Russell Fulton 'phone +64 9 373-7599 x 8955 | | ITSS fax +64 9 373-7425 | | University of Auckland email r.fulton@auckland.ac.nz | | Private Bag 92019 time gmt -12 (-13 oct - mar) | | Auckland, New Zealand. | +-------------------------------------------------------------------+ -------- From academic-firewalls-owner@net.tamu.edu Wed Mar 20 17:04:14 1996 Content-Type: text/plain Date: Wed, 20 Mar 1996 17:58 EST From: Barney Wolff To: academic-firewalls@net.tamu.edu Subject: Re: using passive ftp > Date: Wed, 20 Mar 96 08:56:32 -0600 > From: Dave Hess > > I'm not convinced that the current implementation of PASV is the best > solution for FTP. It assumes that the server is not firewalled > against random port connections which is not necessarily true. > Granted, that is preferable to the hole that source port filtering > causes but it still is not the ideal solution. > > Anybody know of or care to propose a better solution? There is no inherent reason to use separate TCP connections for control and data. It would be a different protocol, but one could easily do it with one, thus getting rid of all the firewall-unfriendly aspects. Another possibility is to hack the server so that when the client says PASV, the server always picks the same port number, which the firewall can then be programmed to let through. Barney Wolff -------- From academic-firewalls-owner@net.tamu.edu Wed Mar 20 18:14:49 1996 References: TVWTICHR, Company Limited by Guarantee, ACN 009 278 755 X-Sun-Charset: US-ASCII Date: Thu, 21 Mar 1996 08:12:38 +0800 (WST) From: John Gibbins To: academic-firewalls@net.tamu.edu Subject: Re: using passive ftp Barney Wolff said: > > > Another possibility is to hack the server so that when the client says > PASV, the server always picks the same port number, which the firewall > can then be programmed to let through. This would not work if a client machine tried to create two concurrent ftp transfers. This is particularly a problem for multiuser machines where two different users may want to ftp to the same site at the same time. They can't both use the same port number. Just to add to the discussion: We have hit another problem with filtering ftp. We are running Firewall-1 (V2.0). FW-1 understands ftp and examines outgoing PORT commands (which specify the port number that the remote server should use to connect to the local machine). It then opens up that port number for a limited time period so the reverse connection can be made. It will only open up the port for connections coming from source-port 20 (ftp-data). This results in two problems: 1) A remote server may be so slow that it does not make the reverse connection before fw-1 closes the hole. This is only a minor problem as fw-1 allows you to increase the timeout period. 2) Some servers do not use port 20 for the reverse connection. I recently discovered that I could not GET files or even do a DIR on research.att.com. I have to admit that I did not try using PASV mode, I logged in to a machine outside our firewall, ftp'd from there and then up to my local machine. My 2c worth. regards johng - -- John Gibbins TVW Telethon Institute The University of Western Australia for Child Health Research email: johng@ichr.uwa.edu.au PO Box 855 ,-_|\ Phone: +61-9-3408547 WEST PERTH W.A. 6872 / \ Fax: +61-9-3883414 AUSTRALIA *_,-._/ "Nothing is foolproof as fools are so ingenious" v -------- From academic-firewalls-owner@net.tamu.edu Wed Mar 20 19:08:24 1996 In-Reply-To: <199603202127.JAA17720@ccu1.auckland.ac.nz> Date: Wed, 20 Mar 1996 19:06:36 -0600 From: Doug Hughes To: academic-firewalls@net.tamu.edu Subject: Re: Securing Public labs > >Up to now we have kept all our public labs IPX only. (Yeah, I know >that anyone with enough clues can get trumpet winsock and packet >drivers on to a diskete). We are now under a lot of pressure to load >IP software on to all these machine so students can access web servers >on campus. One of the things that worries us is that this will allow >unauthenticated access to the university's network for large numbers >of people and that breakin attempts will be very difficult to track >back to individuals unless they are 'caugth in the act' which is >unlikely, given the resources we have. > >Our CS department has been running tcp student network for a long time >and has gone to great lengths to 1) keep their students contained >within their own network and 2) to make sure that they know who was on >any particular machine at any time. They took these measures after a >spate of cracking from CS student accounts a few years ago. > >We are looking at buying a heap of Karl Bridges and using these in >conjunction with an authentication server to firewall all our public >labs. > >We have another motivation for this. Since Internet access is so >expensive here (because of the very expensive international links to >the US and OZ (Australia for those of you who don't know the local >lingo :). We charge all departments by volume. (Rates are around >$US0.50/MB during the day). Most departments, therefore, don't allow >access to the Internet for undergraduates. So we are looking at using >the authentication system in conjunction with Netramet (a locally >developed network traffic meter) to account for student usage so we >can set up a billing system. > >My questions are: > >What do others do about securing Public labs? Do you have many problems >with cracking from them? > Well, we have our public PC labs and our public Sun labs. We have had occassional problems from both. The problems from the sun labs are typically rectified quickly with process accounting and service logs. We can usually find the individual who did it with a little searching, and always narrow it down to one or two people if we can't find the exact culprit. On the PC's, this is more difficult. We have our PC labs doing authentication via PCNFS (which has its own problems, but we'll bypass them for the sake of this discussion). These authentications are verified by pcnfsd which creates a utmp record on the machine. Unfortunately, since these are typically Solaris machines, and because of the way pcnfsd and solaris create the records, you only have an idea of when the person logged in, and no idea when the person left the lab. What we plan on doing is (when we get the developers kit, shortly) modifying PCNFS so that when a new login prompt is displayed, the utmp record is updated reflecting the logout of the person associated with the last login. Until then, we only have a rough idea of who was using the machine. Also, the PC's, being what they are, don't have any process accounting or ident (RFC931 process) for identification, so it's much harder to track who was actually using the machine. The PC subnets are also restricted from getting at NIS/NIS+ via securenets, tcp_wrappers, portmap/rpcbind replacements, and router filters. - -- ____________________________________________________________________________ Doug Hughes Engineering Network Services System/Net Admin Auburn University doug@eng.auburn.edu Pro is to Con as progress is to congress -------- From academic-firewalls-owner@net.tamu.edu Wed Mar 20 19:06:59 1996 Content-Type: text/plain Date: Wed, 20 Mar 1996 19:43 EST From: Barney Wolff To: academic-firewalls@net.tamu.edu Subject: Re: using passive ftp > Date: Thu, 21 Mar 1996 08:12:38 +0800 (WST) > From: John Gibbins > > Barney Wolff said: > > > > > Another possibility is to hack the server so that when the client says > > PASV, the server always picks the same port number, which the firewall > > can then be programmed to let through. > > This would not work if a client machine tried to create two concurrent ftp > transfers. This is particularly a problem for multiuser machines where > two different users may want to ftp to the same site at the same time. > They can't both use the same port number. Actually, it should work, because the client machine should not use a constant port number on its side. What makes a TCP connection unique is the tuple of source/dest IP address and source/dest port. (I just looked at the BSD ftp client code, and so far as I can tell, it does not bind to a particular source port when using PASV, so I believe I'm right.) > 2) Some servers do not use port 20 for the reverse connection. > I recently discovered that I could not GET files or even do a DIR on > research.att.com. I have to admit that I did not try using PASV mode, > I logged in to a machine outside our firewall, ftp'd from there and then > up to my local machine. PASV does work with research.att.com. I use a Web browser to retrieve files from it, for just that reason. Barney Wolff -------- From academic-firewalls-owner@net.tamu.edu Wed Mar 20 21:52:36 1996 Content-Type: text/plain Mime-Version: 1.0 (NeXT Mail 3.3 v118.2) Date: Wed, 20 Mar 96 21:50:30 -0600 From: Dave Hess To: academic-firewalls@net.tamu.edu Subject: Re: using passive ftp > Date: Wed, 20 Mar 1996 19:43 EST > From: Barney Wolff > > Date: Thu, 21 Mar 1996 08:12:38 +0800 (WST) > > From: John Gibbins > > > > Barney Wolff said: > > > > > > > Another possibility is to hack the server so that when the client says > > > PASV, the server always picks the same port number, which the firewall > > > can then be programmed to let through. > > > > This would not work if a client machine tried to create two concurrent ftp > > transfers. This is particularly a problem for multiuser machines where > > two different users may want to ftp to the same site at the same time. > > They can't both use the same port number. > > Actually, it should work, because the client machine should not use a > constant port number on its side. What makes a TCP connection unique is > the tuple of source/dest IP address and source/dest port. (I just > looked at the BSD ftp client code, and so far as I can tell, it does not > bind to a particular source port when using PASV, so I believe I'm right.) Think of it this way. Two ftpd's start up on the server and each get a PASV from the same client machine. Now they both need to bind a socket to the *same* port number and try to catch the connect from the client. Since it is not a unique port number they will need to use SO_REUSEADDR but even then you can't control which ftpd handles which client's connect. I.E. the file transfers may get swapped. Maybe the solution is to go toward a monolithic style server like httpd in daemon mode. The client could pass the port number it will connect from in the PASV command to the server and the server passes back its standard port. In a sense you would be combining the PORT and PASV commands together. It will be the only process bound to that port and it will have the necessary info to distinguish incoming connections from the same machine. This could be made very efficient using threads. Heck, for that matter, why not just use httpd? (with http URLs minus the index.html's) It's a glorified file transfer agent anyway. I'm not sure the browsers are setup to expect that kind of usage and I don't know that getting the authentication right would be easy but it might work. BTW, I stumbled across RFC1579 (Firewall-Friendly FTP) by Bellovin which talks about using PASV with firewalls and he had this to say .... [...] > Concerns have been expressed that this use of PASV just trades one > problem for another. With it, the FTP server must accept calls to > random ports, which could pose an equal problem for its firewall. We > believe that this is not a serious issue, for several reasons. > > First, there are many fewer FTP servers than there are clients. It > is possible to secure a small number of special-purpose machines, > such as gateways and organizational FTP servers. The firewall's > filters can be configured to allow access to just these machines. > Further precautions can be taken by modifying the FTP server so that > it only uses very high-numbered ports for the data channel. It is > comparatively easy to ensure that no dangerous services live in a > given port range. Again, this is feasible because of the small > number of servers. [...] Dave - --- David K. Hess Network Analyst David-K-Hess@tamu.edu Computing and Information Services - Network Group (409) 845-0372 (work) Texas A&M University -------- From academic-firewalls-owner@net.tamu.edu Thu Mar 21 07:28:55 1996 X400-Received: by mta d400relay in /PRMD=dfnrelay/ADMD=d400/C=de/; Relayed; Thu, 21 Mar 1996 14:21:53 +0100 X400-Received: by /PRMD=bgr/ADMD=d400/C=de/; Relayed; Thu, 21 Mar 1996 14:21:50 +0100 X400-Originator: sticher@gate1.bgr.d400.de X400-Recipients: non-disclosure:; X400-MTS-Identifier: [/PRMD=bgr/ADMD=d400/C=de/;960321142150] X400-Content-Type: P2-1984 (2) Content-Identifier: 880 Alternate-Recipient: Allowed Date: Thu, 21 Mar 1996 14:21:50 +0100 From: "Sticher,Hans-Juergen" To: academic-firewalls@net.tamu.edu Subject: unsubscribe unsubsribe