From star at starshine.org Sat Dec 2 08:40:54 2006 From: star at starshine.org (Heather Stern) Date: Sat, 2 Dec 2006 08:40:54 -0800 Subject: Upcoming events on baylisa site In-Reply-To: <3d2fe1780611301032k291f2acdrd593d1a674a37df1@mail.gmail.com> References: <3d2fe1780611301032k291f2acdrd593d1a674a37df1@mail.gmail.com> Message-ID: <20061202164054.GA32650@starshine.org> On Thu, Nov 30, 2006 at 10:32:19AM -0800, Bill Ward wrote: > I'm very confused by the upcoming events on the baylisa.org site. I'm > setting up my Google Calendar and wanted to get BayLISA meetings in > there, but I can't find the info about the next general meeting. > There are two "Upcoming Events" links on the homepage, one of which > links to a page talking about last September's meeting, and the other > redirects to baylisa.info and shows an empty calendar.... The General Meeting is always on Third Thursday. Our current host is Yahoo! campus in Mountain View. We *usually* are in the classrooms in Building E (which we prefer because it's the easy to reach parking lot) but sometimes a conflict results in us getting an upper story room on floor 3 of Building C. Jennifer's usually the gal to poke in the ribs about the calendar bits, but she has her brain all a-smoke from her finals which will be done soon. -* Heather Stern * Baylisa Board Emeritus :) * star at starshine.org *- From rsr at inorganic.org Mon Dec 4 11:47:08 2006 From: rsr at inorganic.org (Roy S. Rapoport) Date: Mon, 4 Dec 2006 11:47:08 -0800 Subject: Hardware Lifecycle Management: How To Start? Message-ID: <20061204194708.GA24878@puppy.inorganic.org> Howdy, Three weeks into my new job, I've been asked to lead an effort to come up with a Hardware Lifecycle Management (HLM) strategy, initially focused on our UNIX (Sun Sparc systems, currently) assets but eventually migrated to Windows servers, desktops, etc. Such a strategy would include such issues as how long we keep things in production, whether we just get rid of them afterward or they get migrated to QA or DR, etc. Since I've got about ... oh, no experience with this issue, and not wanting to completely re-implement the wheel, does anyone have any suggestions for some good reading materials or guides? Thanks, -roy From jxh at jxh.com Mon Dec 4 12:22:00 2006 From: jxh at jxh.com (Jim Hickstein) Date: Mon, 04 Dec 2006 14:22:00 -0600 Subject: Hardware Lifecycle Management: How To Start? In-Reply-To: <20061204194708.GA24878@puppy.inorganic.org> References: <20061204194708.GA24878@puppy.inorganic.org> Message-ID: <45748368.3020107@jxh.com> > Since I've got about ... oh, no experience with this issue, and not wanting > to completely re-implement the wheel, does anyone have any suggestions for > some good reading materials or guides? I can contribute this one thing: When I was at a large networking-equipment company some years ago, the rule of thumb was to replace all networking equipment when it was amortized to zero, at 30 months. Granted, they got it at cost :-) and I don't know the tax situation exactly. But there it is, for what it's worth. The buy/lease decision, and disposal outcomes, will be driven mostly by tax considerations and the overall financial plan of the company, which changes over time. Get to know the auditors early on. Invite them to your planning process now. From star at starshine.org Mon Dec 4 21:09:55 2006 From: star at starshine.org (Heather Stern) Date: Mon, 4 Dec 2006 21:09:55 -0800 Subject: This is the Short But Cools month Message-ID: <20061205050955.GD18319@starshine.org> ...so if there's something Short, But Cool, that you'd like to present, by all means please let us know. I'll also rejuvenate the old BayLISA RFC: Request For Cookies! The edible kind, not browser bait, unless maybe your SBC talk is about some nifty sysadminly browser feature. -* Heather Stern * BayLISA Board Emeritus & Catherd^WEvent Coord this month * http://www.baylisa.org/ *- From star at starshine.org Tue Dec 5 09:02:22 2006 From: star at starshine.org (Heather Stern) Date: Tue, 5 Dec 2006 09:02:22 -0800 Subject: This is the Short But Cools month In-Reply-To: <20061205050955.GD18319@starshine.org> References: <20061205050955.GD18319@starshine.org> Message-ID: <20061205170222.GA21118@starshine.org> My pardon, Rick's the monthly catherder this time around. -* Heather Stern * BayLISA Board Emeritus * http://www.baylisa.org/ *- On Mon, Dec 04, 2006 at 09:09:55PM -0800, Heather Stern wrote: > > ...so if there's something Short, But Cool, that you'd like to present, by > all means please let us know. > > I'll also rejuvenate the old BayLISA RFC: Request For Cookies! The edible > kind, not browser bait, unless maybe your SBC talk is about some nifty > sysadminly browser feature. > > -* Heather Stern * BayLISA Board Emeritus & Catherd^WEvent Coord this month > * http://www.baylisa.org/ *- From rick at linuxmafia.com Tue Dec 5 12:21:40 2006 From: rick at linuxmafia.com (Rick Moen) Date: Tue, 5 Dec 2006 12:21:40 -0800 Subject: This is the Short But Cools month In-Reply-To: <20061205170222.GA21118@starshine.org> References: <20061205050955.GD18319@starshine.org> <20061205170222.GA21118@starshine.org> Message-ID: <20061205202139.GL14528@linuxmafia.com> Quoting Heather Stern (star at starshine.org): > My pardon, Rick's the monthly catherder this time around. And the December cat-herder appreciates your assist very, very much! -- Cheers, find / -user your -name base -print | xargs chown us:us Rick Moen rick at linuxmafia.com From cba at groundworkopensource.com Tue Dec 5 12:38:33 2006 From: cba at groundworkopensource.com (Chris Barton Anderson) Date: Tue, 5 Dec 2006 12:38:33 -0800 Subject: Monitoring SIG: Weds, Dec. 13 Message-ID: <1165351113.5137.31.camel@peterX20> An embedded and charset-unspecified text was scrubbed... Name: not available URL: From bill at wards.net Tue Dec 5 16:57:49 2006 From: bill at wards.net (Bill Ward) Date: Tue, 5 Dec 2006 16:57:49 -0800 Subject: PenLUG meeting next week on Thursday Dec 14: Jamie Cameron, Webmin Message-ID: <3d2fe1780612051657m1d5676a7kd3b90255c74aa5cb@mail.gmail.com> Remember, due to the Thanksgiving and Christmas holidays, we are moving to the second Thursday for November and December. So our next meeting is next week, on Thursday, December 14. You are invited. RSVP is not required, but so we can get an idea of how many people to expect please send mail to rsvp at penlug.org to let us know if you are planning to attend. For full details about the group, as well as directions to the meeting, visit www.penlug.org. Free pizza, hors d'ouvres and soft drinks, courtesy of Open Country, will be provided. Free review copies of books from O'Reilly, Prentice-Hall, APress, and/or other publishers, will be given out as door prizes. Be on time for the eary bird drawing. Date: Thursday, December 14th, 2006 Time: meeting 7:00 - 9:00 PM, social/networking until 10 PM Location: Twin Pines Park, 1225 Ralston Ave, Belmont, CA 94002 Speaker: Jamie Cameron Topic: Webmin Webmin is an open-source web-based system administration interface for Linux systems. It lets you perform tasks like managing BIND, Apache, Sendmail, Unix users and so on without having to manually edit configuration files in the /etc directory, all through a web browser running locally or connecting to the Linux box over the network. Jamie will give an introduction to Webmin and a demo of its capabilities, talking about how it can be useful for managing a home system or small network server, and then covering some of the work he has been doing with OpenCountry to add a Bacula backup module. Jamie was born in Australia but is now working for Google in California. He started work on Webmin in 1997 while working in Singapore, as a way to avoid having people pester him for trivial DNS updates, and has been developing it ever since. He is married with 2 children, and currently lives in Santa Clara. From bill at wards.net Tue Dec 12 08:41:17 2006 From: bill at wards.net (Bill Ward) Date: Tue, 12 Dec 2006 08:41:17 -0800 Subject: Reminder: PenLUG meeting this week on Thursday Dec 14: Jamie Cameron, Webmin Message-ID: <3d2fe1780612120841s112b6676oe162d79065f8e86e@mail.gmail.com> Remember, due to the Thanksgiving and Christmas holidays, we are moving to the second Thursday for November and December. So our next meeting is next week, on Thursday, December 14. You are invited. RSVP is not required, but so we can get an idea of how many people to expect please send mail to rsvp at penlug.org to let us know if you are planning to attend. For full details about the group, as well as directions to the meeting, visit www.penlug.org. Free pizza, hors d'ouvres and soft drinks, courtesy of Open Country, will be provided. Free review copies of books from O'Reilly, Prentice-Hall, APress, and/or other publishers, will be given out as door prizes. Be on time for the eary bird drawing. Date: Thursday, December 14th, 2006 Time: meeting 7:00 - 9:00 PM, social/networking until 10 PM Location: Twin Pines Park, 1225 Ralston Ave, Belmont, CA 94002 Speaker: Jamie Cameron Topic: Webmin Webmin is an open-source web-based system administration interface for Linux systems. It lets you perform tasks like managing BIND, Apache, Sendmail, Unix users and so on without having to manually edit configuration files in the /etc directory, all through a web browser running locally or connecting to the Linux box over the network. Jamie will give an introduction to Webmin and a demo of its capabilities, talking about how it can be useful for managing a home system or small network server, and then covering some of the work he has been doing with OpenCountry to add a Bacula backup module. Jamie was born in Australia but is now working for Google in California. He started work on Webmin in 1997 while working in Singapore, as a way to avoid having people pester him for trivial DNS updates, and has been developing it ever since. He is married with 2 children, and currently lives in Santa Clara. From pmui at groundworkopensource.com Tue Dec 12 12:12:04 2006 From: pmui at groundworkopensource.com (Peter Mui) Date: Tue, 12 Dec 2006 12:12:04 -0800 Subject: Reminder: Monitoring SIG III: Weds Dec 13 Message-ID: (Hi, just a friendly reminder that December's Monitoring SIG is Wednesday Dec 13, 7PM. Feel free to forward this along. Also: if you want to add your monitoring story to the mix let me know. See ya there! -Peter) ----------------------------------------------------- December Monitoring SIG: 'Twas the night before backup...: Real-World Stories At November's meeting at least three people volunteered to share real- world stories about their monitoring installation (more stories are welcome: please email me back and let me know.) We'll use these stories as a launching point for generalizing about monitoring best practices. Bring your monitoring wish list, questions and insights -- share your experiences! What: Monitoring SIG III : 'Twas the night before backup...: Real- World Stories Who: Anyone interested in IT monitoring issues and tools When: Wednesday, December 13 2006, 7PM Where: GroundWork Open Source, 139 Townsend St., San Francisco How: 139 Townsend St. is very near AT&T Park. It is two blocks from the CalTrain Depot. Take the MUNI N trolley "inbound" to 2nd and King (ballpark stop) or take the 15 or 30 buses crosstown. Free evening street parking can usually be found. Festive holiday season refreshments (pizza, pop, snacks) and other good cheer will be provided by Santa's elves (aka GroundWork). We'll open up the doors at 6:30 or so and start the formal part of the meeting promptly at 7PM. RSVP (not necessary, but helpful): Peter Mui, pmui at groundworkopensource.com, 415 992 4573 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ahorn at deorth.org Tue Dec 19 16:02:25 2006 From: ahorn at deorth.org (Alan Horn) Date: Tue, 19 Dec 2006 16:02:25 -0800 (PST) Subject: December General meeting THIS THURSDAY (12/21/2006) Message-ID: Topics : Short but Cools, plus Xangati's Falcon (network intelligence solution) Speakers: Heather Stern, Alan Horn, Jim Dennis, Jaymin Patel Time : Thursday, 7pm Pizza and Soda provided by BayLISA For more details, check the BayLISA website. Feel free to forward this email to other interested lists/people. Cheers, Al From lgj at usenix.org Thu Dec 21 11:26:39 2006 From: lgj at usenix.org (Lionel Garth Jones) Date: Thu, 21 Dec 2006 11:26:39 -0800 Subject: USENIX Annual Tech '07 Call for Papers Message-ID: <458ADFEF.5030905@usenix.org> --------------------------------------- Call for Papers 2007 USENIX Annual Technical Conference June 17-22, 2006, Santa Clara, CA Paper Submissions Deadline: January 9, 2007 http://www.usenix.org/usenix07/cfpa/ --------------------------------------- Dear Colleague, On behalf of the 2007 USENIX Annual Technical Conference program committee, we request your ideas, proposals, and papers for tutorials, refereed papers, and a poster session. The program committee invites you to submit original and innovative papers to the Refereed Papers Track of the 2007 USENIX Annual Technical Conference. Authors are required to submit full papers by 11:59 p.m. PST, Tuesday, January 9, 2007. We seek high-quality submissions that further the knowledge and understanding of modern computing systems, with an emphasis on practical implementations and experimental results. We encourage papers that break new ground or present insightful results based on experience with computer systems. The USENIX conference has a broad scope. Specific topics of interest include but are not limited to: * Architectual interaction * Benchmarking * Deployment experience * Distributed and parallel systems * Embedded systems * Energy/power management * File and storage systems * Networking and network services * Operating systems * Reliability, availability, and scalability * Security, privacy, and trust * System and network management * Usage studies and workload characterization * Virtualization * Web technology * Wireless and mobile systems More information on these and other submission guidelines is available on our Web site: http://www.usenix.org/usenix07/cfpa/ IMPORTANT DATES: Paper submissions due: Tuesday, January 9, 2007, 11:59 p.m. PST Notification to authors: Monday, March 19, 2007 Final papers due: Tuesday, April 24, 2007 Please note that January 9 is a hard deadline; no extensions will be given. We look forward to your submissions. On behalf of the Annual Tech '07 Conference Organizers, Jeff Chase, Duke University Srinivasan Seshan, Carnegie Mellon University 2007 USENIX Annual Technical Conference Program Co-Chairs usenix07chairs at usenix.org From ahorn at deorth.org Thu Dec 21 14:39:08 2006 From: ahorn at deorth.org (Alan Horn) Date: Thu, 21 Dec 2006 14:39:08 -0800 (PST) Subject: Reminder : BayLISA general meeting TONIGHT Message-ID: Topics : Short but Cools, plus Xangati's Falcon (network intelligence solution) Speakers: Heather Stern, Alan Horn, Jim Dennis, Jaymin Patel Time : Thursday, 7pm Pizza and Soda provided by BayLISA For more details, check the BayLISA website. Feel free to forward this email to other interested lists/people. Cheers, Al From david at catwhisker.org Thu Dec 28 15:04:01 2006 From: david at catwhisker.org (David Wolfskill) Date: Thu, 28 Dec 2006 15:04:01 -0800 Subject: "Password validation services" -- how can we avoid creating more of them? Message-ID: <20061228230401.GK88511@bunrab.catwhisker.org> Authentication seems to me to be a fairly well understood art by now; at the same time, we (sysadmins, some of whom ought to know better) deploy services that have their authentication mechanism(s) set up in such a way that these mechanism may be abused by folks to acquire authentication information that may be used to allow impersonation of valid users of the service. For example: set up an SSH server that allows the use of "passwords" for authentication and is accessible from anywhere on the Internet. If one actually checks the logs, one finds that there are periodic probes -- often in the form of "dictionary attacks" -- against often-used logins. Once a valid login is guessed or determined, it's a simple matter to have one or more processes try various passwords (possibly as simple as a brute-force attack) until a particualr working login/password combination is found. The best cure for this I know of is to do at least one of the following: * Disallow password authentication in favor of public key authentication (or some form(s) of Kerberos authentication that require more than just a password), or some 2-factor mechanism such as a SecureID fob. * Restrict the use of password authentication to connections such that both the endpoints and all intermediate points are on "trusted" (and adequately secure) machines and networks. But we still deploy services such as HTTPS or IMAPS that "need" to be open to access from untrusted networks & machines, and which (often?) only provide "password" as an aythentication mechanism. I submit that to the extent that this occurs, it is a Bad Thing. Were it up to me, I'd just set up SSH servers to only use public key authentication, and have folks access everything via SSH tunnels. As things stand, I've been accessing mail that way for some time: I run mutt on my desktop, which is configured to go talk to the IMAP server somewhere else via an SSH tunnel. (Of course, I run mutt within screen(1), but that's for different reasons.) And yes, I've run graphical Web browsers on remote machines accessed via SSH tunnels; it's not necessarily fast, but it does work. (It is more tolerable within a LAN than over a WAN, certainly.) Anyone have better (or at least "other") ideas? Thanks! Peace, david -- David H. Wolfskill david at catwhisker.org Believe SORBS at your own risk: 63.193.123.122 has been static since Aug 1999. See http://www.catwhisker.org/~david/publickey.gpg for my public key. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available URL: From jason.dusek at gmail.com Thu Dec 28 16:57:33 2006 From: jason.dusek at gmail.com (Jason Dusek) Date: Thu, 28 Dec 2006 16:57:33 -0800 Subject: "Password validation services" -- how can we avoid creating more of them? In-Reply-To: <20061228230401.GK88511@bunrab.catwhisker.org> References: <20061228230401.GK88511@bunrab.catwhisker.org> Message-ID: <42784f260612281657q16c35a9tc385d7c0deecb40b@mail.gmail.com> On 12/28/06, David Wolfskill wrote: > [sysadmins should] disallow password authentication in favor of public key > authentication (or some form(s) of Kerberos authentication... Public key authentication has its own problems, doesn't it? If you want to distribute keys infrequently than you have the revocation list problem. If you distribute keys frequently, then you've got to secure that process and you're basically back to square one. Kerberos' combination of keys and passwords does seem like a good compromise, though. > ...we still deploy services such as HTTPS or IMAPS that "need" to be > open to access from untrusted networks & machines, and which (often?) > only provide "password" as an authentication mechanism. > > Were it up to me, I'd just set up SSH servers to only use public key > authentication, and have folks access everything via SSH tunnels. Well, it's reasonable to use keys when they are available -- keys should be preferred, and hopefully the majority of your users will have them; but password authentication helps to cover those authentication corner cases that crop up every so often (a staff member is on a trip, their laptop dies, they find an internet kiosk at the public library...) -- _jsn From jesse at boldandbusted.com Thu Dec 28 17:46:10 2006 From: jesse at boldandbusted.com (Jesse Adelman) Date: Thu, 28 Dec 2006 17:46:10 -0800 Subject: "Password validation services" -- how can we avoid creating more of them? In-Reply-To: <42784f260612281657q16c35a9tc385d7c0deecb40b@mail.gmail.com> References: <20061228230401.GK88511@bunrab.catwhisker.org> <42784f260612281657q16c35a9tc385d7c0deecb40b@mail.gmail.com> Message-ID: <45947362.5030008@boldandbusted.com> Jason Dusek wrote: > On 12/28/06, David Wolfskill wrote: >> [sysadmins should] disallow password authentication in favor of >> public key authentication (or some form(s) of Kerberos >> authentication... > > Public key authentication has its own problems, doesn't it? If you > want to distribute keys infrequently than you have the revocation > list problem. If you distribute keys frequently, then you've got to > secure that process and you're basically back to square one. > Kerberos' combination of keys and passwords does seem like a good > compromise, though. > >> ...we still deploy services such as HTTPS or IMAPS that "need" to >> be open to access from untrusted networks & machines, and which >> (often?) only provide "password" as an authentication mechanism. >> >> Were it up to me, I'd just set up SSH servers to only use public >> key authentication, and have folks access everything via SSH >> tunnels. > > Well, it's reasonable to use keys when they are available -- keys > should be preferred, and hopefully the majority of your users will > have them; but password authentication helps to cover those > authentication corner cases that crop up every so often (a staff > member is on a trip, their laptop dies, they find an internet kiosk > at the public library...) > OK, here's one tip. While I don't believe in "Security by Obscurity" as the only method to secure a network, why make it easier for crackers when you don't have to? Like using "The Club" on your car, putting SSH (and other sensitive administrative services) on alternate public ports at least keeps opportunistic, quick and dumb network-block-wide scans from picking you up on their radar. Real-world example: People who use "The Club" on their car make it *more difficult* (but not impossible) to boost their cars, so thieves will move on and look for easier prey. I did this on some of the networks I'm responsible for and those pesky bot-based and wide-net SSH login attempts from China and elsewhere (trying to log in as "root", "admin", "manager", etc.) have stopped COLD. Yes, you should also use every other means to secure your network within the bounds of what your users (and you) can take without taking up arms against you, but just making life a little more difficult for the "Bad People" can help as well. In this case, if you then DO see break-in attempts on these wacky ports, you can and should pay MUCH more attention to them, since the noise level will have dropped. Happy New Year, Jesse Adelman Linux SysAdmin http://www.ilikelinux.com/ From david at catwhisker.org Thu Dec 28 19:32:38 2006 From: david at catwhisker.org (David Wolfskill) Date: Thu, 28 Dec 2006 19:32:38 -0800 Subject: "Password validation services" -- how can we avoid creating more of them? In-Reply-To: <42784f260612281657q16c35a9tc385d7c0deecb40b@mail.gmail.com> References: <20061228230401.GK88511@bunrab.catwhisker.org> <42784f260612281657q16c35a9tc385d7c0deecb40b@mail.gmail.com> Message-ID: <20061229033238.GL88511@bunrab.catwhisker.org> On Thu, Dec 28, 2006 at 04:57:33PM -0800, Jason Dusek wrote: > ... > Public key authentication has its own problems, doesn't it? I don't know of anything that has no problems. The issue is how one establishes the cost/benefit tradeoff. In the case in point, my concern is that allowing authentication mechanisms that rely strictly on a login/password correspondence are effectively services that may be abused by folks to set up processes to determine passwords for known logins (gleaned, e.g., from email addresses) to be determined -- via brute force, if nothing else. Allowing such requests from untrusted sources is an invitation to thiis particular form of abuse; I seek ways to mitigate this effect. > If you want to distribute keys infrequently than you have the > revocation list problem. If you distribute keys frequently, then > you've got to secure that process and you're basically back to > square one. Kerberos' combination of keys and passwords does seem > like a good compromise, though. My recollection is that there are no authentication mechanisms specified by Kerbeos per se. If that's correct -- I don't recall, and the copy of the O'Reilly "Kerberos" book I've been reading is at work, which is a place where I am currently not -- I invite you to clarify your meaning. > ... > >Were it up to me, I'd just set up SSH servers to only use public key > >authentication, and have folks access everything via SSH tunnels. > > Well, it's reasonable to use keys when they are available -- keys > should be preferred, and hopefully the majority of your users will > have them; but password authentication helps to cover those > authentication corner cases that crop up every so often (a staff > member is on a trip, their laptop dies, they find an internet kiosk at > the public library...) Hmmm... it seems that I failed to communicate my concern. At least for OpenSSH, I do not know of a way to (only) permit public key authentication for some users, while allowing password authentication for others. If this assertion is correct, allowing *any* password authentication for a given machine exposes *every* user with an account on that machine to precisely the type of password-acquisition abuse that I'm trying to avoid. Yes, I understand that keys are inconnvenient at times. A reasonable alternative might be some other 2-factor authentication mechanism, such as requiring (first) a SecureID fob, then a password (something you have + something you know). But in the mean time -- and *this* was the original point of my note -- there are other services, such as IMAPS or HTTPS which encrypt their traffic (which is good) and requiree authentication to use them (which is also good), but for which the common (only?) authentication mecchanisms are such single-factor authenticators as passwords, so opening these services up to the Internet provides a service to facilitate the inappropriate acquisition of authenticastion information via those services. And at least where I work, my colleagues & I are expected to make these available to an ever-widening set of clients. Is there some way to usee 2-factor authentication mechanisms for *all* remote access? Not just SSH; that works fine: what about HTTPS? IMAPS? Any others? Thanks. Peace, david -- David H. Wolfskill david at catwhisker.org Believe SORBS at your own risk: 63.193.123.122 has been static since Aug 1999. See http://www.catwhisker.org/~david/publickey.gpg for my public key. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available URL: From jason.dusek at gmail.com Thu Dec 28 20:10:05 2006 From: jason.dusek at gmail.com (Jason Dusek) Date: Thu, 28 Dec 2006 20:10:05 -0800 Subject: "Password validation services" -- how can we avoid creating more of them? In-Reply-To: <20061229033238.GL88511@bunrab.catwhisker.org> References: <20061228230401.GK88511@bunrab.catwhisker.org> <42784f260612281657q16c35a9tc385d7c0deecb40b@mail.gmail.com> <20061229033238.GL88511@bunrab.catwhisker.org> Message-ID: <42784f260612282010k6374e5b5l7aff6a5915ff2ce4@mail.gmail.com> On 12/28/06, David Wolfskill wrote: > My recollection is that there are no authentication mechanisms > specified by Kerbeos per se. There are two steps to Kerberos authentication: authenticating to the Kerberos server, and authenticating to a 'Kerberized' service -- a service that trusts the Kerberos server for authentication. When you authenticate to the Kerberos server, you have a lot of choices -- x509 certificates (University of Michigan has done this, I believe), password authentication (probably the most common choice), &c. The Kerberos server gives you a 'ticket granting ticket' (we could call it a key) and from that point forward, it's all tickets until your ticket granting ticket expires. So, most Kerberos installations combine password authentication (to the Kerberos server) with key authentication (to Kerberized services -- Apache, DoveCot, SSH, PAM). > Is there some way to usee 2-factor authentication mechanisms for *all* > remote access? Not just SSH; that works fine: what about HTTPS? > IMAPS? Any others? You could Kerberize all these services, and then set up your Kerberos Domain Controller to use two factor authentication. With Apache, for example, use mod_krb5, and then get Mozilla with the integrated auth extenstion. You can find out more about that at: http://www.mozilla.org/projects/netlib/integrated-auth.html Some smart people have posted some stuff, available via Google search, about two factor authentication and Kerberos -- it's been done, I gather. I wish I could tell you more -- I love this kind of stuff and was working on it about 6 months ago -- but I've never set up two factor authentication with Kerberos (or with anything else, for that matter). -- _jsn From rob.markovic at gmail.com Thu Dec 28 23:37:11 2006 From: rob.markovic at gmail.com (Robi) Date: Thu, 28 Dec 2006 23:37:11 -0800 Subject: "Password validation services" -- how can we avoid creating more of them? In-Reply-To: <42784f260612282010k6374e5b5l7aff6a5915ff2ce4@mail.gmail.com> References: <20061228230401.GK88511@bunrab.catwhisker.org> <42784f260612281657q16c35a9tc385d7c0deecb40b@mail.gmail.com> <20061229033238.GL88511@bunrab.catwhisker.org> <42784f260612282010k6374e5b5l7aff6a5915ff2ce4@mail.gmail.com> Message-ID: <97a9d8c80612282337n1f700eeaw4d576e4bbd75055@mail.gmail.com> > There are two steps to Kerberos authentication: authenticating to the > Kerberos server, and authenticating to a 'Kerberized' service -- a > service that trusts the Kerberos server for authentication. When you > authenticate to the Kerberos server, you have a lot of choices -- x509 > certificates (University of Michigan has done this, I believe), True, I went to U of M. I've also been on the admin side of things and figured out how to hack kerberos logins. It's not perfect, just mostly dumb/bot proof. > > Is there some way to usee 2-factor authentication mechanisms for *all* > > remote access? Not just SSH; that works fine: what about HTTPS? > > IMAPS? Any others? Yes, one is easy tunneling via something like hamachi. Make all your trusted networks appear like a lan. You can do port knocking. The default setup of a particular knock over and over isn't as effective as someone could "listen" and "replay" your knocks. Sync generated knocks on both sides, or one time knocks would be better. A long list of shuffled knocks might work too. Another method is some simple logic scripting that wraps your sshd connections. Treat them as email spam, block lets say 3 repeated failure attempts, or better yet, let it keep trying on a harmless loop, so it keeps the bot occupied like a tar pit. Makes brute force much harder. Lots of other clever things out there. I'm sure google knows, even yahoo. A fun one can be that you recompile your fav auth mechanism with some special "foo" that will break any "normal" connection attempt, except your "foo" type connection. Splunk logs and see whats going on. Adjust accordingly. On another note, by now most of us probably have at least one RSA like FOB, those should be reusable for as long as the battery lasts. Any tools out there to make them work with readily available auth systems? -- Rob -- Rob From rayw at rayw.net Fri Dec 29 10:46:06 2006 From: rayw at rayw.net (Ray Wong) Date: Fri, 29 Dec 2006 18:46:06 +0000 Subject: "Password validation services" -- how can we avoid creating more of them? In-Reply-To: <20061229033238.GL88511@bunrab.catwhisker.org> References: <20061228230401.GK88511@bunrab.catwhisker.org> <42784f260612281657q16c35a9tc385d7c0deecb40b@mail.gmail.com> <20061229033238.GL88511@bunrab.catwhisker.org> Message-ID: <20061229184605.GA8028@timeout.rayw.net> > > have them; but password authentication helps to cover those > > authentication corner cases that crop up every so often (a staff > > member is on a trip, their laptop dies, they find an internet kiosk at > > the public library...) > > Hmmm... it seems that I failed to communicate my concern. > > At least for OpenSSH, I do not know of a way to (only) permit public > key authentication for some users, while allowing password > authentication for others. If this assertion is correct, allowing *any* > password authentication for a given machine exposes *every* user with an > account on that machine to precisely the type of password-acquisition > abuse that I'm trying to avoid. Well, OpenSSH doesn't, but there's always the trivial OS workaround: 1) outside SSH is via designated access hosts, i.e. bastions. 2) by default, shadow entry for each user is locked (set to * or *LK*,etc). 3) SA sets up initial key access for each user (can be automated, of course) 4) when temporary password access is needed, set a password, and (depending on account options), set account to expire the day after said user gets back from trip. It's a bit manual, but usually there aren't that many folks who actually need to keep access, and can do so if their own laptop is missing (SA's better be able to, but most developers and the like seem dependent on other tools so end up just having to take some time away from work). Biggest PITA is setting up all those user keys in the first place. Even using CFEngine to propagate to all the bastions doesn't usually save me from helping most users get it right in the first place, which effectively means personally doing it for each user.