-------- From academic-firewalls-owner@net.tamu.edu Sun Mar 24 12:16:02 1996 Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Date: Sun, 24 Mar 1996 12:11:56 -0600 (CST) From: Doug Hughes To: academic-firewalls@net.tamu.edu Subject: STEL - waiting a long long time Well, I've been waiting a long long time for STEL about now. Does anybody have it or does anybody know when it will be released? It seemed to have a lot of promise, and I know the guys at CERT-IT have put a lot of work into it. It seems to me they were asking for beta testers more than 8 months ago and I thought it would have been released by now. Maybe the IT govt got involved. Anybody know the story? I tried sending mail once and got no response. I sure would love to start using it and trash these clear-text logins we're still using (SHHH). It may be time I gave up on waiting and just use ssh... ____________________________________________________________________________ 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 Sun Mar 24 14:19:55 1996 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Date: Sun, 24 Mar 1996 13:18:27 -0700 (MST) From: chris sieber To: academic-firewalls@net.tamu.edu Subject: Security Costs Greetings- I am currently investigating several security measures and would like to find out how to obtain them and how much they cost. I am looking for info on the following ( I already have info on several firewalls) Kerberos Hand-held authenticators software encryption (for PC and Mac) logging( tcp wrapper, etc.) If anybody has any info on purchasing, licensing, or info on free products, that would be very helpful. Please also include any comments concerning your likes or dislikes for any particular products. Please e-mail me directly, Thanks for your time, Chris Sieber -------- From academic-firewalls-owner@net.tamu.edu Mon Mar 25 23:56:42 1996 X-Sender: if430a11@nova cc: academic-firewalls@net.tamu.edu In-Reply-To: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Date: Tue, 26 Mar 1996 00:53:29 -0500 (EST) From: IFSM 430-4061 Student 11 To: academic-firewalls@net.tamu.edu Subject: Re: -Reply Hi! I just can not think of anything else but computer security, specially, network security. If anyone is interested in that subject matter, by all means reply! -------- From academic-firewalls-owner@net.tamu.edu Tue Mar 26 02:41:42 1996 X-Sender: if430a11@nova cc: academic-firewalls@net.tamu.edu In-Reply-To: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Date: Tue, 26 Mar 1996 01:03:19 -0500 (EST) From: IFSM 430-4061 Student 11 To: academic-firewalls@net.tamu.edu Subject: Re: Security Costs I have an articule on MIT's kerbros and I will send it to you later this week or next week. I also have information on firewall-1. I also like to discuss security measures because it is hot, it is now. I would like to know if anyone has information on 90 bit encryption software??? chao... -------- From academic-firewalls-owner@net.tamu.edu Tue Mar 26 09:27:00 1996 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Date: Tue, 26 Mar 1996 09:12:07 -0600 (CST) From: Larry Owen To: academic-firewalls@net.tamu.edu Subject: Mobile (internal) users Well, here's something that will hopefully start at least a little discussion on this list. Although the solution to this problem may or may not involve a firewall per se, this is at least tangentially related to the list. I've been asked to look into making provisions for two types of mobile (but not remote) users: o faculty who wish to be able to take their notebooks into a classroom and connect to the network there (with a minimum of, and ideally no, reconfiguration). They will almost certainly be on a different ip subnet in the class room than when in their office. (We do a little of this now, with jacks in classrooms having ip addresses assigned, requiring faculty to recofigure their machines, and having a hot jack just sitting there when not in use. Also, there is no authentication). o providing some "bull pen" areas, such as study lounges, student union areas, the library, etc., where students may do the same. The main requirements are that all users be authenticated before their packets are routed off the local subnet; little or no re-configuration be required as users move back and forth from office to classroom, or home to study area; the following OSes be supported: MacOS, Win3.1, Win95, probably NT workstation, and Linux would be a bonus. It seems obvious that some sort of dynamic address assignment be performed ... I know how to do all of the above (well, perhaps a little reconfiguration would be required) if I use some sort of access server, but we'd really like to get ethernet speeds if possible. Has anyone done something like this? Could you share your strategies? Thanks. Larry Owen Campus Network Administrator Auburn University owen@noc.auburn.edu (334) 844-4110 -------- From academic-firewalls-owner@net.tamu.edu Tue Mar 26 09:57:15 1996 Cc: academic-firewalls@net.tamu.edu In-Reply-To: from "Larry Owen" at Mar 26, 96 09:12:07 am Organization: NTUA-NOC, National Technical University of Athens, GREECE X-Disclaimer: The views expressed herein are of my own, unless otherwise explicitly expressed. X-Home-Address: 7 Elvetias St., Agia Paraskevi GR15342, Athens, GREECE X-Home-Phone: +30-1-639-4-638 X-Work-Phone: +30-1-772-1-861 X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Date: Tue, 26 Mar 1996 17:53:38 +0200 (EET) From: y.adamopoulos@noc.ntua.gr Reply-To: y.adamopoulos@noc.ntua.gr To: academic-firewalls@net.tamu.edu Subject: Re: Mobile (internal) users > Has anyone done something like this? Could you share your > strategies? Thanks. I think I'd use DHCP for the machine to learn it's address and block routing on these subnets. Anyone who wants to telnet/ftp beyond, would be forced to go thru a proxy server running sth. like FWTK or Freestone for authentication. - -- Yiorgos Adamopoulos adamo@noc.ntua.gr National Technical University of Athens, NOC -------- From academic-firewalls-owner@net.tamu.edu Tue Mar 26 10:16:07 1996 Cc: academic-firewalls@net.tamu.edu In-Reply-To: Date: Tue, 26 Mar 1996 10:13:51 -0600 From: Doug Hughes To: academic-firewalls@net.tamu.edu Subject: Re: Mobile (internal) users > > >Well, here's something that will hopefully start at least a >little discussion on this list. Although the solution to this >problem may or may not involve a firewall per se, this is at >least tangentially related to the list. > >I've been asked to look into making provisions for two types >of mobile (but not remote) users: > o faculty who wish to be able to take their notebooks > into a classroom and connect to the network there (with > a minimum of, and ideally no, reconfiguration). They will > almost certainly be on a different ip subnet in the class > room than when in their office. (We do a little of this > now, with jacks in classrooms having ip addresses assigned, > requiring faculty to recofigure their machines, and having > a hot jack just sitting there when not in use. Also, there > is no authentication). Why not use BOOTP for this? (or DHCP) No more configuration. In the context of faculty notebooks, identification by MAC address would at least inform you of who was using it. Anything that did not have a registered MAC address would not be assigned an address. Of course, people could try to hard-code their IP addresses and plug in rogue notebooks, but it would require knowledge of the network configuration. You could even install one of our many security enabled HP hubs that would continuously monitor changes in MAC addresses and when one shows up that is not in BOOTP table, send out an alarm that a possible intruder has been detected. A little SNMP trap, some syslog magic, and you're there. > o providing some "bull pen" areas, such as study lounges, > student union areas, the library, etc., where students > may do the same. You want to make SURE that only read-only stuff goes here. Make them like the dorms, untrusted lans. I'd thought about this myself. They can telnet to other places or surf the web or whatever to do what they want. > >Has anyone done something like this? Could you share your >strategies? Thanks. > Authentication is the hardest part. It's not so hard with the faculty, because keeping up with a faculty registry of notebooks wouldn't be that hard. But, with students, I shudder to think. I'd probably just leave them least common denominator.. read-only services, telnet access, stuff like that. I guess the other possible thing would be to setup something like kerberos, but it'd be a lot of work. - -- ____________________________________________________________________________ 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 Tue Mar 26 12:07:07 1996 X-Mailer: ELM [version 2.3 PL11F] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Date: Tue, 26 Mar 96 11:02:39 MST From: "Tu Nguyen" To: academic-firewalls@net.tamu.edu Subject: How to secure an Ethernet Network? Hi All, We are in the process of upgrading our ethernet networks to secured network. Our prime goals are: 1. Users are free to attach to any port (good for class environment) 2. Prevent users from sniffing the network. 3. Safely control these equipments from a central size. We are using 3Com FMS_II with eavedrop avoidance. These hubs eseem to work fine but setting up these hub is not a trivial task. The process is time consuming and very cubersome. On the same hub, different versions of software management asks for different setup procedures and Eavedrop prevention feature on their latest version is only accessible with their latest Transcend software ( and I never got this thing to run properly on my PC, it crashed constantly). We don't want intrusion prevention, just eavedrop avoidance. The major drawback with this hub is the lack of "IP Manager" list. This list controls what workstations (based on IP number) can manage the hub. Due to this missing feature we must turn off SNMP and thus lose control of the device. We never consider SNMP with "community string" is a safe way to control a device. "IP Manager" is a must for any secure device. There must be lots of secured networks out there. If any of you has designed a similar network, can you share your ideas on: . What kind of hub is best suited? . How do you best control these devices. thank you all. - -- Tu Nguyen email: nguyen@acs.ucalgary.ca University Computing Services voice: (403)220-5155 University of Calgary fax : (403)282-9199 -------- From academic-firewalls-owner@net.tamu.edu Tue Mar 26 13:18:18 1996 X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Date: Tue, 26 Mar 1996 11:16:31 -0800 (PST) From: Peter Van Epp To: academic-firewalls@net.tamu.edu Subject: Re: Mobile (internal) users > In the context of faculty notebooks, identification by MAC address > would at least inform you of who was using it. Anything that did I assume that you are aware that around 5 minutes with DOS and debug will enable me (and thus an awful lot of our students, it isn't rocket science, and I am not a rocket scientist) to set any MAC address that I please in most PC ethernet cards? The controller chip is typically available from the bus. There may be enet cards that aren't but there are certainly ones where this is true and the attacker can chose to use such a card! This makes security based on a Mac address less than secure. The appropriate MAC address can typically be picked up from the ARP cache of a host where the real machine to be spoofed has connected to ... The best bet is as was suggested to not worry about it on the local net and authenticate in a secure firewall for access to the Internet. Our sites plan for something like this falls out of our intent to upgrade our backbone to Newbridge's VIVID ATM product. One of its features is virtual routing which seperates the subnets from the physical ethernet or ATM ports to the ATM cloud. This should allow us to distribute a student only subnet to public areas physically all around campus, and let VIVID detect where physically a student has connected. It of course doesn't stop the MAC spoofing discussed above, but I expect that the subnet will connect to a secured firewall that requires authentication to get out. A similar net can be configured for teaching spaces around campus for faculty. Again given MAC spoofing, I expect it would be firewalled for off campus access, since there will be ports in unattended classrooms where the resourceful could attempt to pretend to be a faculty member's machine. Peter Van Epp / Operations and Technical Support Simon Fraser University, Burnaby, B.C. Canada -------- From academic-firewalls-owner@net.tamu.edu Tue Mar 26 13:25:05 1996 X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Date: Tue, 26 Mar 1996 11:23:31 -0800 (PST) From: Peter Van Epp To: academic-firewalls@net.tamu.edu Subject: Re: Mobile (internal) users (fwd) Doug replied directly to me because I klutz fingered it and sent my reply directly to him instead of the list as I intended. With his permission I am forwarding his reply to the list to continue the discussion. Forwarded message: From doug@Eng.Auburn.EDU Tue Mar 26 10:53 PST 1996 From: Doug Hughes Date: Tue, 26 Mar 1996 12:53:07 -0600 Subject: Re: Mobile (internal) users To: vanepp@sfu.ca > >> In the context of faculty notebooks, identification by MAC address >> would at least inform you of who was using it. Anything that did > > I assume that you are aware that around 5 minutes with DOS and debug >will enable me (and thus an awful lot of our students, it isn't rocket science, >and I am not a rocket scientist) to set any MAC address that I please in >most PC ethernet cards? The controller chip is typically available from the >bus. There may be enet cards that aren't but there are certainly ones where >this is true and the attacker can chose to use such a card! This makes >security based on a Mac address less than secure. The appropriate MAC address >can typically be picked up from the ARP cache of a host where the real machine >to be spoofed has connected to ... The best bet is as was suggested to not >worry about it on the local net and authenticate in a secure firewall for access >to the Internet. very aware of that. But, I would certainly not put a connection host on the same lan as the PC's for security reasons, though some people might. And, you can set the router to stale out the ARP cache rather quickly if desired. A person could plug in, run a snooper, catch an ARP, and then use it for him or herself at a later date. This would be more an issue for a public lab of this type, and not so much for a classroom with only one port. A firewalled public lab would probably be a good idea, however it depends on the level of effort that the telecom department wants to put into it. We've recently had to back off our ATM strategy due to some very strange and obscure bugs in the CISCO ATM LANE product that tickled a bug in NIS+ that caused our entire network to be unavailable for approx 40 hours. (What fun that was! ;) The right way to do it is certainly to firewall. However, given that we also buy HP hubs with eavesdrop protection, even snooping will not yield anything of value. And, telling the cisco to reject SNMP packets from the public subnet would block grabbing of the current ARP table. So, it probably would be less cost and effort to do it without the firewall machine. > Our sites plan for something like this falls out of our intent to >upgrade our backbone to Newbridge's VIVID ATM product. One of its features >is virtual routing which seperates the subnets from the physical ethernet or >ATM ports to the ATM cloud. This should allow us to distribute a student only >subnet to public areas physically all around campus, and let VIVID detect >where physically a student has connected. It of course doesn't stop the >MAC spoofing discussed above, but I expect that the subnet will connect to >a secured firewall that requires authentication to get out. A similar net >can be configured for teaching spaces around campus for faculty. Again given >MAC spoofing, I expect it would be firewalled for off campus access, since >there will be ports in unattended classrooms where the resourceful could >attempt to pretend to be a faculty member's machine. > > You could probably block SNMP queries from these virtual subnets too, and use hubs that prevent snooping. That would block your MAC stealing problems too. - -- ____________________________________________________________________________ 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 Tue Mar 26 13:35:29 1996 Date: Tue, 26 Mar 1996 13:33:48 -0600 From: Doug Hughes To: academic-firewalls@net.tamu.edu Subject: Re: How to secure an Ethernet Network? >Hi All, > We are in the process of upgrading our ethernet networks to >secured network. Our prime goals are: > 1. Users are free to attach to any port (good for class environment) > 2. Prevent users from sniffing the network. > 3. Safely control these equipments from a central size. > We can do all of these things with our HP hubs (we have 16, 32, and 48 port varieties - they are also stackable) You just need to specify that you also want the management module. You can manage them via serial PC connection with software, or via telnet connection (and hence expect or other scripting). You can have eavesdrop protection with or without port lock-out ability. -------- From academic-firewalls-owner@net.tamu.edu Tue Mar 26 15:18:25 1996 X-Sun-Charset: US-ASCII Date: Tue, 26 Mar 1996 13:02:06 -0800 From: cjayasur@hmsi.com To: academic-firewalls@net.tamu.edu Subject: Drawbridge-2.0 fc.exe fm.exe for NT Hi All I am sorry if you receve this email two times I seem to have mailed it first time to academic-firewalls-owner. Any way ? I like to know if more work is been done on drawbridge from TAMU. I use drawbridge internaly to firewall traffic coming in from the ASCEND MAX ISDN router it seem to work great. How secure is it to use as a FireWall?. Also I used a LEX and YACC on Windows NT to Port fc and fm programs to Windows NT and I have a windows gui to specify filtering rules that gets compiled with fc.exe and then I have modified fm to be able work with the GUI to install the filter over the net. I also ported syslogd to NT to use as the login mechanism. I have not changed the actual drawbridge program on the DOS box and I am not a expert at IP security problems or security problems that is to do with Packet Filters (exept the once there are some papers about which drawbridge takes care of) any way I am wandering if anybody would like to use it ?. Charitha -------- From academic-firewalls-owner@net.tamu.edu Tue Mar 26 15:34:31 1996 Date: Tue, 26 Mar 1996 16:31:28 -0500 From: gary flynn To: academic-firewalls@net.tamu.edu Subject: Re: How to secure an Ethernet Network? > Hi All, > We are in the process of upgrading our ethernet networks to > secured network. Our prime goals are: > 1. Users are free to attach to any port (good for class environment) > 2. Prevent users from sniffing the network. > 3. Safely control these equipments from a central size. > > We are using 3Com FMS_II with eavedrop avoidance. These hubs > eseem to work fine but setting up these hub is not a trivial > task. The process is time consuming and very cubersome. > On the same hub, different versions of software management asks for different > setup procedures and Eavedrop prevention feature on their latest version > is only accessible with their latest Transcend software ( and I never got > this thing to run properly on my PC, it crashed constantly). We don't > want intrusion prevention, just eavedrop avoidance. The major > drawback with this hub is the lack of "IP Manager" list. This list > controls what workstations (based on IP number) can manage the hub. > Due to this missing feature we must turn off SNMP and thus lose control > of the device. We never consider SNMP with "community string" is a safe > way to control a device. "IP Manager" is a must for any secure device. > There must be lots of secured networks out there. If any of you has > designed a similar network, can you share your ideas on: > . What kind of hub is best suited? > . How do you best control these devices. > thank you all. We use HP AdvanceStack hubs. They let you specify the allowed managment station. HP sells a product called Interconnect Manager that provides a GUI interface to configure them but you can do the same thing with scripts using snmp sets and gets which is what we do. Its much faster and more efficient than going through the GUI. The GUI is nice for spot checking and the inevitable "special request". There is a version of Interconnect Manager for both Windows and unix. The eavesdrop prevention, intruder traps, and other security functions can be set independantly of one another. Gary Flynn Network Manager James Madison University -------- From academic-firewalls-owner@net.tamu.edu Tue Mar 26 16:13:51 1996 Cc: bukys@cs.rochester.edu Date: Tue, 26 Mar 1996 17:10:48 -0500 From: bukys@cs.rochester.edu To: academic-firewalls@net.tamu.edu Subject: Re: How to secure an Ethernet Network? While an "IP Manager" list is nice, it is not any more secure than a community password. The best thing to do would be to use out-of-band management, eg, SNMP over a serial port. I agree that the dropping of Eavesdrop protection from the 3COM FMSII dumb-terminal config port is a really stupid idea on 3COM's part. Liudvikas Bukys University of Rochester Computer Science Department 734 Computer Studies Building Rochester, NY 14627-0226 tel# 716-275-7747 fax# 716-461-2018 -------- From academic-firewalls-owner@net.tamu.edu Tue Mar 26 16:35:39 1996 Date: Tue, 26 Mar 1996 17:32:46 -0500 From: gary flynn To: academic-firewalls@net.tamu.edu Subject: Re: How to secure an Ethernet Network? > While an "IP Manager" list is nice, it is not any more secure than > a community password. The best thing to do would be to use out-of-band > management, eg, SNMP over a serial port. > Very true. Security is relative and absolute security is unobtainable. Security based on clear text authentication or IP source address is almost no security at all. However, I feel a little bit more comfortable knowing that the hubs are set to only accept managment commands from one unknown station and the community string is somewhat protected by the eavesdrop feature. Every little bit helps :-) gary -------- From academic-firewalls-owner@net.tamu.edu Tue Mar 26 16:40:57 1996 Date: Tue, 26 Mar 1996 17:39:01 -0500 From: gary flynn To: academic-firewalls@net.tamu.edu Subject: Re: Mobile (internal) users (fwd) > The right way to do it is certainly to firewall. However, given that we > also buy HP hubs with eavesdrop protection, even snooping will not yield > anything of value. And, telling the cisco to reject SNMP packets from > the public subnet would block grabbing of the current ARP table. So, it > probably would be less cost and effort to do it without the firewall > machine. Not only that. The HP hubs can be configured to send an SNMP trap and/or lock the port if the MAC address changes. It all depends on the amount of administration you're willing to do to get an extra level of security. Its that risk analysis thing again :-) gary -------- From academic-firewalls-owner@net.tamu.edu Tue Mar 26 17:32:27 1996 Date: Wed, 27 Mar 96 10:28:45 EST From: Peter Billam To: academic-firewalls@net.tamu.edu Subject: Re: How to secure an Ethernet Network? > From: gary flynn > Sender: academic-firewalls-owner@net.tamu.edu > > > While an "IP Manager" list is nice, it is not any more secure than > > a community password. The best thing to do would be to use out-of-band > > management, eg, SNMP over a serial port. > > Very true. Security is relative and absolute security is unobtainable. > Security based on clear text authentication or IP source address is > almost no security at all. However, I feel a little bit more comfortable > knowing that the hubs are set to only accept managment commands from one > unknown station and the community string is somewhat protected by the > eavesdrop feature. Every little bit helps :-) > How long will it take for hub and router manufacturers to offer ssh-style authentication in their gear ? How nice it would be to able to say, eg $ scp configfile router:/configfile Strong authentication ! No cleartext passwords ! Encrypted traffic ! Regards, Peter Billam -------- From academic-firewalls-owner@net.tamu.edu Tue Mar 26 17:48:44 1996 Cc: academic-firewalls@net.tamu.edu In-Reply-To: <9603262328.AA00705@ocean>; from "Peter Billam" at Mar 27, 96 10:28 am X-Mailer: ELM [version 2.3 PL11] Date: Tue, 26 Mar 96 16:46:36 MST From: woods@ncar.UCAR.EDU (Greg Woods) To: academic-firewalls@net.tamu.edu Subject: Re: How to secure an Ethernet Network? > How long will it take for hub and router manufacturers to offer ssh-style > authentication in their gear ? How nice it would be to able to say, eg > > $ scp configfile router:/configfile > > Strong authentication ! No cleartext passwords ! Encrypted traffic ! This is probably obvious to most people, but in case someone hasn't realized it: this is only secure if the host you are running on is adequately secure. Someone who has compromised your local host will now be able to reprogram your router too. This is generically true for anything that relies on encryption alone for security; it does not protect you against a compromise of one endpoint used to access the other endpoint. What you really need is scp *combined* with a password on the router. - --Greg -------- From academic-firewalls-owner@net.tamu.edu Tue Mar 26 21:02:09 1996 In-Reply-To: <9603262328.AA00705@ocean> Date: Tue, 26 Mar 1996 20:58:03 -0600 From: Doug Hughes To: academic-firewalls@net.tamu.edu Subject: Re: How to secure an Ethernet Network? Peter Billam wrote: > >How long will it take for hub and router manufacturers to offer ssh-style >authentication in their gear ? How nice it would be to able to say, eg > > $ scp configfile router:/configfile > >Strong authentication ! No cleartext passwords ! Encrypted traffic ! > I would be inclined to believe this will never be supported (specifically speaking of ssh) except possibly in some small start-up outfit. I think most will end up waiting for SNMPv2 security stuff to use that, or maybe even IPSEC, but the former will probably be sooner, even though it hit a stumbling block a few months back. - -- ____________________________________________________________________________ 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 Tue Mar 26 23:46:41 1996 Cc: academic-firewalls@net.tamu.edu In-Reply-To: <9603262102.AA06115@sun260b.hmsi.com> from "cjayasur@hmsi.com" at Mar 26, 96 01:02:06 pm Organization: NTUA-NOC, National Technical University of Athens, GREECE X-Disclaimer: The views expressed herein are of my own, unless otherwise explicitly expressed. X-Home-Address: 7 Elvetias St., Agia Paraskevi GR15342, Athens, GREECE X-Home-Phone: +30-1-639-4-638 X-Work-Phone: +30-1-772-1-861 X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Date: Wed, 27 Mar 1996 07:40:30 +0200 (EET) From: y.adamopoulos@noc.ntua.gr Reply-To: y.adamopoulos@noc.ntua.gr To: academic-firewalls@net.tamu.edu Subject: Re: Drawbridge-2.0 fc.exe fm.exe for NT > the GUI to install the filter over the net. I also ported syslogd to NT > to use as the login mechanism. Do you distribute it? If so, from where? - -- Yiorgos Adamopoulos adamo@noc.ntua.gr National Technical University of Athens, NOC -------- From academic-firewalls-owner@net.tamu.edu Tue Mar 26 23:48:05 1996 X-Sender: swift@miya.llnl.gov Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 26 Mar 1996 21:21:57 -0800 From: uncl@llnl.gov (Fence-Walker (UNCL-afoot)) To: academic-firewalls@net.tamu.edu Subject: CERT Summary CS-96.02 Date: Tue, 26 Mar 1996 15:09:26 -0500 From: CERT Advisory To: cert-advisory@cert.org Subject: CERT Summary CS-96.02 Reply-To: cert-advisory-request@cert.org Organization: CERT(sm) Coordination Center - +1 412-268-7090 - --------------------------------------------------------------------------- CERT(sm) Summary CS-96.02 March 26, 1996 The CERT Coordination Center periodically issues the CERT Summary to draw attention to the types of attacks currently being reported to our strategic incident response staff. The summary includes pointers to sources of information for dealing with the problems. We also list new or updated files that are available for anonymous FTP from ftp://info.cert.org/pub/ Past CERT Summaries are available from ftp://info.cert.org/pub/cert_summaries/ - --------------------------------------------------------------------------- Recent Activity - --------------- In the two months since the last CERT Summary, we have continued to receive reports about the same types of activities that were described in CERT advisory CA-95:18 Widespread Attacks on Internet Sites. In addition, we have seen an increase in the number of reports relating to software piracy, many of which involve intruders taking advantage of systems with poorly configured anonymous FTP areas. If you haven't done so already, the CERT staff urges you to immediately take the steps described in the advisories and README files listed below. Note that it is important to check README files, as they can contain updated information that we receive after an advisory is published. The majority of the incidents reported to our incident response staff during the last two months fit into one (or more) of these seven categories: 1. Root compromise on systems that are unpatched or running old OS versions. We receive daily reports of systems that have been compromised by intruders who have gained unauthorized access to root or other privileged accounts by exploiting widely known security vulnerabilities on systems that did not have appropriate patches installed (and/or systems that were running old [unpatched] versions of the operating system). We encourage everyone to check with their vendor(s) regularly for updates or new patches that relate to their systems, and install security-related patches as soon as they are available. For a list of additional suggestions on recovering from a UNIX root compromise, see ftp://info.cert.org/pub/tech_tips/root_compromise 2. Compromised user-level accounts that are leveraged to gain further access. We receive daily reports of compromised accounts that have been used to launch attacks against other sites, and/or have been used to gain privileged access on vulnerable systems. We encourage you to check your systems regularly (in accordance with your site policies and guidelines) for any signs of unauthorized accesses or suspicious activity. For a list of suggestions on how to determine whether your system may have been compromised, see ftp://info.cert.org/pub/tech_tips/security_info 3. Packet sniffers and Trojan horse programs We continue to receive almost daily incident reports about intruders who have installed packet sniffers on root-compromised systems. These sniffers, used to collect account names and passwords, are frequently installed as part of a widely-available kit that also replaces common system files with Trojan horse programs. The Trojan horse binaries (du, ls, ifconfig, netstat, login, ps, etc.) hide the intruders' files and sniffer activity on the system on which they are installed. For further information and methods for detecting packet sniffers and Trojan horse binaries, see the following files: ftp://info.cert.org/pub/cert_advisories/CA-94:01.network.monitoring.attacks ftp://info.cert.org/pub/cert_advisories/CA-94:01.README ftp://info.cert.org/pub/cert_advisories/CA-94:05.MD5.checksums ftp://info.cert.org/pub/cert_advisories/CA-94:05.README 4. IP spoofing attacks We continue to receive several reports each week of IP spoofing attacks. Intruders attack by using automated tools that are becoming widespread on the Internet. Some sites incorrectly believed that they were blocking such spoofed packets, and others planned to block them but hadn't yet done so. For further information on this type of attack and how to prevent it, see ftp://info.cert.org/pub/cert_advisories/CA-95:01.IP.spoofing ftp://info.cert.org/pub/cert_advisories/CA-95:01.README 5. Software piracy We receive new reports each week about compromised accounts and/or poorly configured anonymous FTP servers that are being used for exchanging pirated software. While the compromised accounts should be addressed as a separate security issue (see item 2, above), the abuse of anonymous FTP areas for software piracy activities can be reduced if the anonymous FTP service is correctly configured and administered. For related information and guidelines for configuring anonymous FTP, see ftp://info.cert.org/pub/cert_advisories/CA-93:10.anonymous.FTP.activity 6. Sendmail attacks We still receive new reports each week about intruders attempting to exploit vulnerabilities in the sendmail program mailer facility. Unfortunately, some of these attacks have been successful against sites that are running old versions of sendmail and/or are not restricting the sendmail program mailer facility. Sendmail's program mailer facility can be restricted by using the sendmail restricted shell program (smrsh). Information on known sendmail vulnerabilities and the smrsh tool can be obtained from ftp://info.cert.org/pub/cert_advisories/CA-93:16.sendmail.vulnerability ftp://info.cert.org/pub/cert_advisories/CA-93:16a.sendmail.vulnerability.supplement ftp://info.cert.org/pub/cert_advisories/CA-93:16a.README ftp://info.cert.org/pub/cert_advisories/CA-95:05.sendmail.vulnerabilities ftp://info.cert.org/pub/cert_advisories/CA-95:05.README ftp://info.cert.org/pub/cert_advisories/CA-95:08.sendmail.v.5.vulnerability ftp://info.cert.org/pub/cert_advisories/CA-95:08.README ftp://info.cert.org/pub/cert_advisories/CA-95:11.sun.sendmail-oR.vul ftp://info.cert.org/pub/cert_advisories/CA-95:11.README ftp://info.cert.org/pub/cert_advisories/CA-95:13.syslog.vul ftp://info.cert.org/pub/cert_advisories/CA-95:13.README The smrsh program can be obtained from: ftp://info.cert.org/pub/tools/smrsh/ smrsh is also included in the sendmail 8.7.5 distribution. 7. NFS and NIS attacks, and automated tools to scan for vulnerabilities We receive weekly reports of intruders using automated tools to scan sites for hosts that may be vulnerable to NFS and NIS attacks. Intruders are continuing to exploit the rpc.ypupdated vulnerability to gain root access, and intruders are still exploiting widely known vulnerabilities in NFS to gain root access. For related information, see ftp://info.cert.org/pub/cert_advisories/CA-95:17.rpc.ypupdated.vul ftp://info.cert.org/pub/cert_advisories/CA-95:17.README ftp://info.cert.org/pub/cert_advisories/CA-94:15.NFS.Vulnerabilities ftp://info.cert.org/pub/cert_advisories/CA-94:15.README ftp://info.cert.org/pub/cert_advisories/CA-92:13.SunOS.NIS.vulnerability What's New at the CERT Coordination Center - ------------------------------------------ The CERT Coordination Center has a new Web site. It includes information on Internet security and has a link to the CERT FTP archive. http://www.cert.org What's New in the CERT FTP Archive - ---------------------------------- We have made the following changes since the last CERT Summary (January 23, 1996). * New Additions ftp://info.cert.org/pub incident_reporting_form v.3 (replaced v.2 with v.3) ftp://info.cert.org/pub/cert_advisories CA-96.01.UDP_service_denial CA-96.02.bind CA-96.03.kerberos_4_key_server CA-96.04.corrupt_info_from_servers CA-96.05.java_applet_security_mgr CA-96.06.cgi_example_code ftp://info.cert.org/pub/cert_bulletins VB-96.01.splitvt VB-96.02.sgi VB-96.03.sun VB-96.04.bsdi ftp://info.cert.org/pub/FIRST conference.info ftp://info.cert.org/pub/tech_tips root_compromise ftp://info.cert.org/pub/tools /cpm/* (replaced older version with v.1.2) /sendmail/sendmail.8.7.5 (replaced older version) /tcp_wrappers/tcp_wrappers_7.3 (replaced older version) /sendmail/smrsh/* (replaced older vsersion with v.8.4) ftp://info.cert.org/pub/vendors /sgi/SGI_contact_info * Updated Files ftp://info.cert.org/pub cert_faq (version 10.2) ftp://info.cert.org/pub/cert_advisories CA-94:01.README (added info about cpm v.1.2) CA-95:13.README (added info from sendmail author and Cray; added info from HP and Sun) CA-95:14.README (added info from NEC Corp and Silicon Graphics) CA-95:17.README (added info from IBM) CA-96.01.README (new URL for Argus; added info from Silicon Graphics) CA-96.02.README (added info from IBM, Solbourne, and Silicon Graphics) CA-96.03.README (added new checksums and patch.readme info; added info from Transarc and TGV Software, Inc.) CA-96.04.README (added info from Silicon Graphics) CA-96.05.README (added pointer to Netscape 2.01) rdist-patch-status (added pointer to version 6.1.2) ftp://info.cert.org/pub/vendors /hp/HP.contact.info - --------------------------------------------------------------------------- How to Contact the CERT Coordination Center Email cert@cert.org Phone +1 412-268-7090 (24-hour hotline) CERT personnel answer 8:30-5:00 p.m. EST (GMT-5)/EDT(GMT-4), and are on call for emergencies during other hours. Fax +1 412-268-6989 Postal address CERT Coordination Center Software Engineering Institute Carnegie Mellon University Pittsburgh PA 15213-3890 USA URLs: http://www.cert.org/ ftp://info.cert.org/pub/ To be added to our mailing list for CERT advisories and bulletins, send your email address to cert-advisory-request@cert.org CERT advisories and bulletins are posted on the USENET news group comp.security.announce If you wish to send sensitive incident or vulnerability information to CERT staff by electronic mail, we strongly advise you to encrypt your message. We can support a shared DES key or PGP. Contact the CERT staff for more information. Location of CERT PGP key ftp://info.cert.org/pub/CERT_PGP.key - --------------------------------------------------------------------------- Copyright 1996 Carnegie Mellon University This material may be reproduced and distributed without permission provided it is used for noncommercial purposes and credit is given to the CERT Coordination Center. CERT is a service mark of Carnegie Mellon University. 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