howell@ecsvax.UUCP (Doc A. Howell) (03/24/88)
Did anyone read the recent LAN magazine article on ethernet security? I am sure some did. The article addressed the use of an ethernet monitor to spy on an ethernet to obtain passwords, look at data, and have fun in general. This seems to me to be a very severe problem. With the example given, there appears to be no way, other than encryption, to prevent this type of problem. Does anyone have any ideas of how to deal with this? Is encryption the only answer, ($$$)? Anyone have any reason to believe than their networks are being spied on?
cyrus@hi.unm.edu (Tait Cyrus) (03/24/88)
In article <4805@ecsvax.UUCP> howell@ecsvax.UUCP (Doc A. Howell) writes: > > Did anyone read the recent LAN magazine article on ethernet security? >I am sure some did. The article addressed the use of an ethernet monitor >to spy on an ethernet to obtain passwords, look at data, and have fun in >general. Here at UNM we had to resort to this to aid us in "tracing" a user that was breaking into accounts. We had our program trigger whenever the account name (being broken into) was seen on the net. It then latched onto the connection that it saw this "key" on. From that moment till the intruder logged off we had a "script" of both directions of their conversation. This allowed us to see exactly what the intruder was doing to our systems and how they were trying to break in (allowing us to fix any UN*X security problems we had unintentionally left open.) Unfortunately, this program could just as easily watch for "keys" such as "password", "su", "login", etc (we have done this to try to show the higher ups here at UNM how insecure the net is -- we got over 200 passwords in a couple hour period). >This seems to me to be a very severe problem. With the example >given, there appears to be no way, other than encryption, to prevent >this type of problem. > > Does anyone have any ideas of how to deal with this? Is encryption >the only answer, ($$$)? No encryption is not the only answer. Dollars, though, can really help. Some other possible solutions are: 1) keep PC's OFF off of your cable so that they can't "watch" your traffic 2) restrict who has root on your systems (so they can't run these 'spy' programs on them) 3) Restrict physical access to the cable - put in conduit (preferablly pressurized thought this can be gotten around quite easily) 4) use fiber optics. This is a little harder for a person to tap, though it is still possible 5) Watch when people use their accounts. You will notice right away when a secretarial account is being used at "odd" hours of the night. Doing this will give you some idea of which accounts have be compromised. 6) force people to change their passwords often (once a month for example) so that if someone does gain unauthorized access to the cable, the passwords they see won't do them much good These are just a few steps you can take to keep people from "watching" the net. If they start to put data out on the net, then watch out because they can change machines arp tables so that packets are forced to the other sides of certain ethernet bridges (DEC DEBIT for example), send icmp redirects so that packets are forced to the other sides of gateways, step into a conversation (say of someone with root) and take over the connection, etc. To protect against an unauthorized person actively putting things on the net, an authentication routine should be used (such as Kerbose (sp?) from MIT -- I don't know much about the whats/hows/etc though) that "notices" any strangness it sees on the net. >Anyone have any reason to believe than their >networks are being spied on? Yes. I am watching (I don't like the word 'spy') our network. I am performing some statistical analysis. Not all "spying", as you put it, is bad. Some is a necessary eval. -- @__________@ W. Tait Cyrus (505) 277-0806 /| /| University of New Mexico / | / | Dept of Electrical & Computer Engineering @__|_______@ | Parallel Processing Research Group (PPRG) | | | | UNM/LANL Hypercube Project | | hc | | Albuquerque, New Mexico 87131 | @.......|..@ | / | / e-mail: @/_________@/ cyrus@hc.dspo.gov
mjr@osiris.UUCP (Marcus J. Ranum) (03/24/88)
In article <4805@ecsvax.UUCP> howell@ecsvax.UUCP (Doc A. Howell) writes: > > Did anyone read the recent LAN magazine article on ethernet security? >I am sure some did. The article addressed the use of an ethernet monitor >to spy on an ethernet to obtain passwords, look at data, and have fun in >general. [...] Don't forget the venerable IBM PC with the ethernet card in it. In fact, any system that does not have some form of reasonable security to prevent a user from changing its name, in the case of a trusted host, or sending hand-made packets out on the net (which the PC can do, if you care to). I believe there is even TCP monitoring software available for the PCs. This is in issue in my mind, since I know of at least one site that has PCs on the net, as well as confidential and highly sensitive data. --mjr(); -- ------------------------------------------------------------------------------ ...ich bin in einem dusenjet ins jahr 53 vor chr...ich lande im antiken Rom... einige gladiatoren spielen scrabble...ich rieche PIZZA...
kwe@bu-cs.BU.EDU (kwe@bu-it.bu.edu (Kent W. England)) (03/25/88)
In article <4805@ecsvax.UUCP> howell@ecsvax.UUCP (Doc A. Howell) writes: > > Did anyone read the recent LAN magazine article on ethernet security? >I am sure some did. The article addressed the use of an ethernet monitor >to spy on an ethernet to obtain passwords, look at data, and have fun in >general. This seems to me to be a very severe problem. With the example >given, there appears to be no way, other than encryption, to prevent >this type of problem. > > Does anyone have any ideas of how to deal with this? Is encryption >the only answer, ($$$)? Anyone have any reason to believe than their >networks are being spied on? Back in July of last year there was a great discussion of LAN security on the BIG-LAN BITnet list. I saved it in an archive. It started with a question of security when academic and administrative users are on the same LANs. How does one protect sensitive administrative data and systems from those impish academic hackers? Not much was said about physical security, except that some can't control physical access and some demand physical security, like network closets and conduits, as part of their standard cable distribution. Of course, physical security helps protect against accidents as well as malicious abuse. One solution: use bridges to isolate traffic and cut down on what a snooper could see. A follow-on to that would be to use a subnetted internet with routers instead of bridges. Various people commented about security holes in both approaches, although the consensus was that this was a most significant means of enhancing security. Another solution: Run parallel LANs and segregate the academic and admin machines and users (David Wasley @ UC Berkeley and John Wobus @ Syracuse U) Another solution: encrypt sensitive data and transfers. [vendors have since come out with hardware to support link level encryption on LANs, Bridge and U-B come to mind.] I said something about the threat of snoopers not being serious and Philip Prindeville from MIT posted a simple explanation of a $1.98 snooper package and opened my eyes to the ease of snooping. Quote: A year and a half ago, at my previous employer, we put a $900 PC with a $300 ethernet card and some public domain software on our ethernet. We set up the monitor to log any TCP packets on port 25. That afternoon, all the mail that had been sent was pinned to a bulletin board next to the conference room. Security took on a new sense of urgency... EOQ A very funny article but quite serious and instructive In response to my idea of a public key cryptosystem for logon and transactions MAR@ATHENA.MIT.EDU posted a notice of the MIT project Athena Kerberos authentication system. Kerberos, which is slated to be publicly released, provides for secure access control, including logon transactions. The short and simple answer is: segment and/or segregate and implement some kind of encryption [total or Kerberos(like)]. Kent England Boston University
ron@topaz.rutgers.edu (Ron Natalie) (03/25/88)
Better than that, someone wrote a program for a sun that allows you to evesdrop on complete TCP connections (provided that the net is lightly loaded enough). Ethernets are not secure. Neither are your RS-232 lines. We used to tap terminal lines quite a bit (it's a lot easier than ethernet). -Ron
romkey@kaos.UUCP (John Romkey) (03/25/88)
In article <20906@bu-cs.BU.EDU> kwe@buit13.bu.edu (Kent England) writes: >I said something about the threat of snoopers not being serious and >Philip Prindeville from MIT posted a simple explanation of a $1.98 >snooper package and opened my eyes to the ease of snooping. While the software is from MIT, Philip is not. The software is a program called netwatch that I wrote as a part of the public domain PC/IP. There are also commercial versions of it available now. It's really intended for protocol and network debugging, but if you're bored, yes, it does a fine job of catching data and passwords. It actually costs about $15 from MIT. You can buy more sophisticated programs like this from FTP Software, Network General, Excelan, Hewlett-Packard and Network Research Corporation. I think that there's similar software for Sun workstations, too. >In response to my idea of a public key cryptosystem for logon and >transactions MAR@ATHENA.MIT.EDU posted a notice of the MIT project >Athena Kerberos authentication system. Kerberos, which is slated to >be publicly released, provides for secure access control, including >logon transactions. > > The short and simple answer is: segment and/or segregate and >implement some kind of encryption [total or Kerberos(like)]. As you said, Kerberos provides secure authentication - you don't end up sending a password across the net in plaintext, and you can't spoof it, but it doesn't encrypt any of your data. So with an ethernet monitor in a Kerberos system you could still pick up lots of neat data. If someone REALLY wants to get at your data, then they'll manage to tap your ethernet cable and segregating won't really help. It will only prevent the casual cracker from breaking security; it won't help you with truly malicious crackers. Physical security seems to be necessary to really be as close to 100% as is possible, especially with UNIX based systems that can easily be brought up in single user mode as 'root' if you have access to the physical computer. -- - john romkey ...harvard!spdcc!kaos!romkey romkey@kaos.uucp romkey@xx.lcs.mit.edu
jsloan@wright.EDU (John Sloan) (03/28/88)
in article <Mar.24.20.17.27.1988.4240@topaz.rutgers.edu>, ron@topaz.rutgers.edu (Ron Natalie) says: >We used to tap terminal > lines quite a bit (it's a lot easier than ethernet). With a box like the H-P 4951 serial protocol analyzer, its embarressingly trivial. We used to wire up some test clips to an RS-232 connector, plug that onto the 4951, program the box to look for a particular login, and from that point on start recording until it filled up its 64KB of RAM. Then we'd attach the test clips to the requisite pins on the telco block that was used for direct connect terminal connections. Of course, you could use a modem and do something similar with real tip and ring telco connections, as well. It made for an interesting demo. Fortunately, at the moment our telco splice blocks used for terminal traffic are either in locked telephone closets or in the computer room. Unfortunately, this will change as we deploy more terminal servers in out of the way places. John Sloan, The SPOTS Group Wright State University Research Building CSNET: jsloan@SPOTS.Wright.Edu 3171 Research Blvd., Kettering, OH 45420 UUCP: ...!cbosgd!wright!jsloan +1-513-259-1384 +1-513-873-2491 Logical Disclaimer: belong(opinions,jsloan). belong(opinions,_):-!,fail. -- John Sloan, The SPOTS Group Wright State University Research Building CSNET: jsloan@SPOTS.Wright.Edu 3171 Research Blvd., Kettering, OH 45420 UUCP: ...!cbosgd!wright!jsloan +1-513-259-1384 +1-513-873-2491 Logical Disclaimer: belong(opinions,jsloan). belong(opinions,_):-!,fail.
howell@ecsvax.UUCP (Doc A. Howell) (03/29/88)
From what I hear there seems to be two basic options in securing an ethernet packet from the probing eyes of another user on the same network. The first would be some means of seperation, physical via completly seperate networks or logically via a bridge, router etc... The second would be encryption of data within the packets. It seems there are several products out that offer each of these alternatives. If you go the physically seperate route, then you still have to figure someway to let the networks communicate, since that was probably the reason you put the network in to begin with. This could be done with gateways, but it seems there is still the potential to have sensitive data in the wrong place at the wrong time. The logical seperation with bridges and routers seems to be feasible, although costly, but the question of being able to ping, probe and otherwise shoot holes through that scheme is still an issue. There is still the question of data sensitive data being viewed as it moves from one network side to the other. Encryption looks to me to be the best solution, but it appears most people are looking at this from a software standpoint. Trying to hide passwords and such does little good when a patient person can just sit and wait for what he wants to see go by. This is obviously a tough one or it would have been solved by now, I suppose it is a matter of wait and see what happens. Anyone have any ideas of the best and CHEAPEST way to handle this problem? Now is your chance to run out and make a killing in the SECURE THE ETHERNET MARKET!! Doc (I hope nobody is watching) Howell At Univ. of N.C. at Wilmington Add your favorite Quotes, disclaimers etc... HERE __________________!!
naftoli@aecom.YU.EDU (Robert N. Berlinger) (03/29/88)
In article <Mar.24.20.17.27.1988.4240@topaz.rutgers.edu>, ron@topaz.rutgers.edu (Ron Natalie) writes: > Better than that, someone wrote a program for a sun that > allows you to evesdrop on complete TCP connections (provided > that the net is lightly loaded enough). Ethernets are not > secure. Neither are your RS-232 lines. We used to tap terminal > lines quite a bit (it's a lot easier than ethernet). > > -Ron Yes but the significant difference is that the Ethernet cable comes right to a potentially malicious user's office whereas RS-232 is point to point. If you want to tap RS-232 you need to get in close proximity to the cable (where physical security can protect you), but with Ethernet the malintent need only obtain the appropriate software. In short, if you want to be careful, don't use telnet to system logins (e.g., root) if you don't want your passwords to leak out. Theft of services (by stealing a user login) is a considerable problem if your user population can't be trusted. -- Robert N. Berlinger | /------Preferred-------\ Supervisor of Systems Support |Domain: | naftoli@aecom.yu.edu | Scientific Computing Center |UUCP: {philabs,cucard,ihnp4}!aecom!naftoli Albert Einstein College of Medicine |CompuServe: 73047,741 GEnie: R.Berlinger
henry@utzoo.uucp (Henry Spencer) (03/30/88)
> Does anyone have any ideas of how to deal with this? Is encryption > the only answer, ($$$)? ... Encryption is not necessary if your Ethernet meets ALL the following conditions: 1. Unauthorized connections are not an issue, either because you take precautions against them (a lot of work) or because you're not worried about them. Unauthorized tapping of fiber or thick Ethernet is not a trivial operation, i.e. casual snoopers are unlikely to bother. Thin Ethernet with a connector just sitting there waiting to be plugged in to is another matter. 2. All authorized connections go to machines whose physical security is not an issue, again either because you take precautions or because you're not worried. The ability to reboot a machine often constitutes complete control over its software. 3. All authorized connections go to machines which either (a) cannot be used by untrusted users, or (b) are controlled by software that enforces appropriate restrictions on network access by users. Unix can do okay in this area if you pay attention to it. MSDOS is inherently incapable of enforcing security. If your network does not meet all three of these conditions, it cannot be secure without carefully-designed encryption. "Carefully-designed" means, in particular, that the procedures for setting up an encrypted connection must be planned with problems like "active wiretapping" [bad guys injecting false messages to try to capture the connection] in mind. -- "Noalias must go. This is | Henry Spencer @ U of Toronto Zoology non-negotiable." --DMR | {allegra,ihnp4,decvax,utai}!utzoo!henry
henry@utzoo.uucp (Henry Spencer) (03/30/88)
> 6) force people to change their passwords often (once a month for > example) so that if someone does gain unauthorized access to > the cable, the passwords they see won't do them much good This has a high probability of being counterproductive; the usual result is stupidly-chosen passwords, alternation between two passwords, passwords that are minor variations on each other, etc. -- "Noalias must go. This is | Henry Spencer @ U of Toronto Zoology non-negotiable." --DMR | {allegra,ihnp4,decvax,utai}!utzoo!henry
ejnorman@dogie.edu (Eric Norman) (03/31/88)
In article <4826@ecsvax.UUCP> howell@ecsvax.UUCP (Doc A. Howell) writes: > From what I hear there seems to be two basic options in securing an > ethernet packet from the probing eyes of another user on the same The Berkeley .rhosts scheme does avoid sending passwords (either cleartext or encrypted) across the network, you know. That stops the voyeurs with LAN monitors. Sure its security can be defeated by sloppy use, but that's true of anything else. > network. The first would be some means of seperation, physical via > completly seperate networks or logically via a bridge, router etc... Some degree of logically physical separation can be easily achieved by merely wiring in the mapping that bridges do from Ethernet address to bridge side. This makes being an imposter from the other side of a bridge very difficult (as if it isn't already). > suppose it is a matter of wait and see what happens. Anyone have any > ideas of the best and CHEAPEST way to handle this problem? Now is your Sure, in order for there to be a crime, you need (1) motive, (2) opportunity, and (3) means. All the suggested methods attempt to eliminate either means or opportunity. Why not just eliminate the motive? How? Well, maybe that's a toughie, then again, maybe nobody's thought about it much. You could always believe that paranoia is an infectious and self-extinguishing disease. Eric Norman Internet: ejnorman@unix2.macc.wisc.edu UUCP: ...!uwvax!ejnorman Life: Detroit!Alexandria!Omaha!Indianapolis!Madison!Hyde "I really had to act; 'cause I didn't have any lines." -- Marilyn Chambers --
kwe@bu-cs.BU.EDU (kwe@bu-it.bu.edu (Kent W. England)) (04/01/88)
In article <4826@ecsvax.UUCP> howell@ecsvax.UUCP (Doc A. Howell) writes: > [in reference to physical/segmented security versus encryption] > Encryption looks to me to be the best solution, but it appears most >people are looking at this from a software standpoint. Trying to hide >passwords and such does little good when a patient person can just sit >and wait for what he wants to see go by. > > This is obviously a tough one or it would have been solved by now, I >suppose it is a matter of wait and see what happens. I think hardware is the only way to encrypt entire sessions (versus encryption of transactions like login). But wait: In article <525@cunixc.columbia.edu> alan@cunixc.columbia.edu (Alan Crosswell) writes: > DEC has very recently announced what I believe to be a LAN-bridge like > box combined with a VMS-based key server. It use a hardware DES > implementation and is supposed to encrypt data at the packet level in > one box and decrypt it at the other (totally transparent to the > hosts). It will also allow clear text passthru when one host sits > behind a decrypter but the other doesn't so you can add these things > to an existing ethernet, protecting the "important" hosts ("important" > meaning how much money you want to spend) while still allowing access > for others. It's supposed to have all kinds of configuration stuff > too so you can decide who can talk to whom. Okay, so how will this hardware based solution work? Sounds like the DEC box will encrypt packets on an individual host basis. Will it also encrypt at the session level? Will you have a secure terminal server with encryption to one or several hosts and clear access to all others? What about a workstation with a DES chip? Would you encrypt at the session level (by that I mean encrypting each telnet session individually or each virtual circuit individually) or would you encrypt at the link level for each packet sent to a secure host? I think we need a design and an RFC. I'll make my killing when the interoperability issues are a little clearer :-) Kent England Boston University