![]() |
| December 1999 | Get BSD | New to BSD? | Search BSD | Submit News | FAQ | Contact Us | Join Us |
|
It was a dark and stormy night when I arrived at the Seattle airport. (Ever since Snoopy used that line, I have wanted to try it. It finally fit...) My plane arrived just a little before midnight local time, which translated to about 2 A.M. where I am from. The rain I expected; I lived in Washington for most of my life and just recently moved away. This is my second USENIX conference. The first one was the Annual Technical Conference in Monterey, California. LISA '99 was quite different, both in focus and attendees.
The Annual Technical Conference had a FreeNIX track that featured both BSD and Linux. The attendees to that conference seemed to be evenly matched between BSD and Linux, with a little Solaris and other UNIX tossed in. LISA '99 seemed to focus a lot on dealing with NT and sites running commercial UNIX OSes like Solaris and AIX. Linux and BSD were referenced as "we have them, but they don't cause us problems".
LISA is an acronym for Large Installation System Administrators. Where I work currently, we have somewhere in the neighborhood of 500 computers. With a staff of about 5, it is a large installation. But I realized how small it was when I met one of the sysadmins for what was probably the largest installation represented at LISA '99: Hotmail. Hotmail has over 4000 FreeBSD web servers.
This year, almost 2000 people attended LISA. It also had one of the largest vendor displays ever: over 130 different vendors who were there for almost 2 full days.
There were some very good papers presented there. I will try to summarize a few of the best ones. I have partially quoted the abstract of some of the papers.
ssmail: Opportunistic Encryption in sendmail
Damian Bentley, Australian National University; Greg Rose, QUALCOMM Australia; and Tara Whalen, Communications Research Centre Canada
Abstract
Much electronic mail is sent unencrypted, making it vulnerable to passive eavesdropping. We propose to protect email privacy by building encryption functionality into ESMTP mailers. Our solution, ssmail, provides fast, simple encryption for sendmail that does not require user intervention or reliance on public key infrastructure. We added a small number of steps to an ESMTP session, thereby allowing a client and server to create a secret, one-time session key used to encrypt the mail transfer session. ssmail relies on caching to reduce key generation overhead. The overhead imposed by our encryption scheme is minimal, allowing even busy mail servers to support privacy.
We placed our encryption mechanism within the mail transfer agent itself, allowing people to use privacy protection software without having to know how to run an encryption program explicitly. Furthermore, we are able to encrypt the email transmission session, protecting such information as sender and recipient identities. The speed and simplicity of ssmail make it a very useful addition to widely deployed ESMTP mailers. Our solution can also be adopted easily by other mailers, and can be extended to use other encryption algorithms.
Greg Rose from Qualcomm gave the presentation and quoted an interesting fact regarding the security of the Internet. He was doing research for this paper and found that "26 major routers in the UK alone had sniffers along the backbone in one year, in 1998". Those are some scary numbers. These are the major routers that handle most of the Internet for the UK, imagine how it is for the rest of the world. Ssmail was developed as a patch for Sendmail, but Greg said he has received an e-mail commenting that they had it running for qmail as well.
It uses 80 bit RC4 compatible encryption. The threat model for this project, was passive sniffing of network traffic. It isn't intended to guard against active attacks, but to prevent people from passively collecting your e-mail.
To obtain a copy of the software, you have to e-mail Greg Rose <ggr@qualcomm.com>.
Bob Beck of OpenBSD won the award for best paper. When I talked with him, he blamed it all on Theo for making him write it. He didn't think they would even like the paper, since he is simply using cheap hardware and Free Software.
Dealing with Public Ethernet Jacks - Switches, Gateways, and Authentication
Robert Beck, University of Alberta
Abstract This paper describes the tools and techniques developed and deployed to address the problem of blocking unauthorized users on unprotected Ethernet jacks. Our solution is being deployed to control public labs at the University of Alberta during the summer of 1999. In this environment, we have a mix of ``walk up'' Ethernet connections used for laptop computers, and public Windows 95 and 98 workstations with fixed Ethernet connections. By themselves, none of these provide adequate facilities for preventing unauthorized Internet usage and enabling us to track Internet abuses originating from these networks. Prior to the deployment of our new access control system, these networks were not routed off of our campus due to these problems.
Our access control system consists of MAC-locked switches behind a gateway at which an IP filter only allows Internet access when authenticated. Now we allow the authenticated users full access to the Internet, while preventing unauthorized people from plugging in for free Internet access. This also provides a record of Internet activity by authenticated users so that abuses can be easily tracked.
To use the Internet on this campus, the users must telnet to the firewall and keep the session open. When the telnet session is terminated, so is the Internet connection.
Since the user is authenticated to the router, the router now identifies the user to the outside world regardless of what information the user supplied. This allows them to "selectively proxy out bound IMAP, SMTP, and HTTP requests, as well as answering IDENT requests coming in to the lab with the real user." Problems with IRC are virtually non-existant, since users don't want to cause trouble when people know who they really are.
With this running, e-mail system abusers, even those that use Hotmail accounts and such, can be tracked down in about 30 seconds. Bob said he has a collection of PERL scripts that scan his logs and can find the offender almost immediately.
They currently have this deployed in about 30 labs. The people who were causing all the trouble, have migrated to the unprotected labs, and those labs are now actively requesting that this service be installed.
This paper can be found online at http://www.openbsd.org/papers/a uth-gw.ps
This last paper deals with something we have all experienced. In my last job, we had two adverse terminations, neither of which were me. :-) I left on good terms, however, the information in this paper would have been helpful nonetheless. In the two adverse terminations I experienced, we were lucky enough that there were no serious backlashes. On one of the occasions, I inherited the network he used to sysadmin. Basically we got around the problem by re-installing from media, not necessarily because of the need for security, but because we had no idea how to run the network the way it was setup.
Adverse Termination Procedures -or- "How To Fire A System Administrator
Matthew F. Ringel and Thomas A. Limoncelli, Lucent Technologies/Bell Labs
Abstract
When an employee is terminated, his or her access to the organization's network and computer systems must be removed. However, the most difficult employee to terminate is often the person that built the system. We propose a three tier model for coordinating access removal that is useful in normal and adverse termination scenarios. We then work through a number of case studies to see how the model performs in this difficult situation. We feel this model performs extremely well. We also discuss, informally, how to minimize the risk of backdoors and how employees can reduce the possibility of being blamed for security incidents if they are terminated.
He gives a nice list of do's and don'ts for both the employer and the employee. He also has four case studies that he gives details on how they did the job right or wrong. This paper was definately worth reading, even if you are only planning on moving jobs.
His paper will soon be online at http://www.bell-labs.com/user/tal/papers/