From michael at halligan.org Wed Oct 5 10:21:06 2005 From: michael at halligan.org (Michael T. Halligan) Date: Wed, 05 Oct 2005 10:21:06 -0700 Subject: Tech jobs in the midwest? Message-ID: <43440B82.50603@halligan.org> From time to time I seem to hear a lot of people complaining about the economy in the bay area.. This always seems to be followed by a lot of press about H1B visa caps, etc. This always gets followed by a flurry of spam from recruiters, most of them offshored recruiters in call centers, calling me about "wonderful jobs in ohio". I think the existance of the midwest will forever perplex the truth about the job situation (which I think is overblown by a few overtly vocal people), and will continually keep spamme... err I mean recruiters in business. Recruiters from the midwest are fun. Am I the only one being spammed/called by them so often, unsolicited? From david at catwhisker.org Wed Oct 5 10:47:46 2005 From: david at catwhisker.org (David Wolfskill) Date: Wed, 5 Oct 2005 10:47:46 -0700 Subject: Tech jobs in the midwest? In-Reply-To: <43440B82.50603@halligan.org> References: <43440B82.50603@halligan.org> Message-ID: <20051005174746.GO54033@bunrab.catwhisker.org> On Wed, Oct 05, 2005 at 10:21:06AM -0700, Michael T. Halligan wrote: > From time to time I seem to hear a lot of people complaining about the > economy in the bay area.. .... This always > gets followed by a flurry of spam from recruiters, > most of them offshored recruiters in call centers, calling me about > "wonderful jobs in ohio". Hmmm... > I think the existance of the midwest will forever perplex the truth "perplex the truth?" Hmmm...? > about the job situation (which I think is overblown > by a few overtly vocal people), While I'm fairly sure that there are some who overstate the extent to which the employment situation in the SF Bay area is difficult for many reasonably talented folks, I would also observe that none of the folks I have heard saying positive things about the economy were either significantly underemployed or had been unemployed for a significant amount of time. Disclosure: I count myself as both "reasonably talented" and "significantly underemployed." > and will continually keep spamme... err > I mean recruiters in business. :-} > Recruiters from the midwest are fun. Am I the only one being > spammed/called by them so often, unsolicited? No; there was another just today who tried to spam baylisa-jobs with some blurb about someone to customize some CRM system in Illinois. I added the domain name in question to baylisa.org's access list with a rejection message informing them that they'd been blacklisted, and that if they wanted to fix htat, they needed to send an apology to postmaster at baylisa.org. There are ... many ... such domain names in that access list. :-} Since I started doing that stuff with the access list, I've had only one contact postmaster@; that one turned out to have been an innocent mistake, and was corrected. Peace, david (sometime postmaster at baylisa.org, among others) -- David H. Wolfskill david at catwhisker.org Prediction is difficult, especially if it involves the future. -- Niels Bohr See http://www.catwhisker.org/~david/publickey.gpg for public key. From rsr at inorganic.org Wed Oct 5 10:48:32 2005 From: rsr at inorganic.org (Roy S. Rapoport) Date: Wed, 5 Oct 2005 10:48:32 -0700 Subject: Tech jobs in the midwest? In-Reply-To: <43440B82.50603@halligan.org> References: <43440B82.50603@halligan.org> Message-ID: <20051005174832.GA161@puppy.inorganic.org> On Wed, Oct 05, 2005 at 10:21:06AM -0700, Michael T. Halligan wrote: > From time to time I seem to hear a lot of people complaining about the > economy in the bay area.. This always seems > to be followed by a lot of press about H1B visa caps, etc. This always > gets followed by a flurry of spam from recruiters, > most of them offshored recruiters in call centers, calling me about > "wonderful jobs in ohio". I think it's more "a wonderful job in Ohio." I find it hard to believe there's more than one. And once you're there ... it's a little hard to find another one. > about the job situation (which I think is overblown > by a few overtly vocal people), and will continually keep spamme... err Given how hard it is for us to find good people, I'd tend to agree. > Recruiters from the midwest are fun. Am I the only one being > spammed/called by them so often, unsolicited? I've not gotten those calls. -roy From dannyman at toldme.com Wed Oct 5 11:05:51 2005 From: dannyman at toldme.com (Danny Howard) Date: Wed, 5 Oct 2005 11:05:51 -0700 Subject: Tech jobs in the midwest? In-Reply-To: <43440B82.50603@halligan.org> References: <43440B82.50603@halligan.org> Message-ID: <20051005180551.GH564@ratchet.nebcorp.com> On Wed, Oct 05, 2005 at 10:21:06AM -0700, Michael T. Halligan wrote: > > Recruiters from the midwest are fun. Am I the only one being > spammed/called by them so often, unsolicited? The online version of my resume still says Chicago, so I get the occasional cold inquiry from recruiters who have found me via Google. I don't mind: the salaries are higher here in the Bay Area, (SAGE survey says my job averages $20,000 higher here than back home, though in my experience it is so far $30,000 higher, :) but the housing is overpriced and the infrastructure sucks, so I'm saving my money this time around so I can afford some housing in a better place, like Chicago, a way down the road, and I'll probably want a job then too. As for the midwest, I came out here as part of a large migration of Illinois people. Most are from Chicago suburbs, and they vastly prefer Bay Area suburbs, and don't intend to leave. A few of us are from Chicago proper, and we tend to look forward to the day that we can return. For those who don't grok the midwest, but may be curious, please understand that cities are different from suburbs are different from rural areas ... and, imo ... Cali has better suburbs, it seems, and Chicago is a better city than San Francisco, it seems. Though, everyone's milage will vary. Cheers, -danny -- http://dannyman.toldme.com/ From michael at halligan.org Wed Oct 5 11:23:41 2005 From: michael at halligan.org (Michael T. Halligan) Date: Wed, 05 Oct 2005 11:23:41 -0700 Subject: Tech jobs in the midwest? In-Reply-To: <20051005174746.GO54033@bunrab.catwhisker.org> References: <43440B82.50603@halligan.org> <20051005174746.GO54033@bunrab.catwhisker.org> Message-ID: <43441A2D.1020005@halligan.org> David Wolfskill wrote: >On Wed, Oct 05, 2005 at 10:21:06AM -0700, Michael T. Halligan wrote: > > >>From time to time I seem to hear a lot of people complaining about the >>economy in the bay area.. .... This always >>gets followed by a flurry of spam from recruiters, >>most of them offshored recruiters in call centers, calling me about >>"wonderful jobs in ohio". >> >> > >Hmmm... > > > >>I think the existance of the midwest will forever perplex the truth >> >> > >"perplex the truth?" Hmmm...? > > > This is what happens when your doctor forbids you from consuming caffeine. 's/perplex/perpetuate/' >>about the job situation (which I think is overblown >>by a few overtly vocal people), >> >> > >While I'm fairly sure that there are some who overstate the extent to >which the employment situation in the SF Bay area is difficult for many >reasonably talented folks, I would also observe that none of the folks >I have heard saying positive things about the economy were either >significantly underemployed or had been unemployed for a significant >amount of time. > >Disclosure: I count myself as both "reasonably talented" and >"significantly underemployed." > > I just don't see it. Maybe two or three years ago it was a bit tight, but the past year or so has been great. I've been off of the market for quite a while now, only posting my resume on the rare occasion to generate new consulting leads. Given my relative inactivity in my job search, I am constantly being called and emailed by recruiters, some of them who even have relevant jobs. The flipside of this, is every job lead I'm given that doesn't just annoy me, I do my best to find a placement for, and have helped at least a dozen people in '05 find gigs. I think the key to a job search is networking. Resumes, frequencies of postings, current state of the market, none of that really matters. Good people are good people, they just need to find a way to connect with good job leads, which isn't always easy. >>and will continually keep spamme... err >>I mean recruiters in business. >> >> > >:-} > > > >>Recruiters from the midwest are fun. Am I the only one being >>spammed/called by them so often, unsolicited? >> >> > >No; there was another just today who tried to spam baylisa-jobs with >some blurb about someone to customize some CRM system in Illinois. > >I added the domain name in question to baylisa.org's access list with a >rejection message informing them that they'd been blacklisted, and that >if they wanted to fix htat, they needed to send an apology to >postmaster at baylisa.org. > >There are ... many ... such domain names in that access list. :-} > >Since I started doing that stuff with the access list, I've had only one >contact postmaster@; that one turned out to have been an innocent >mistake, and was corrected. > >Peace, >david (sometime postmaster at baylisa.org, among others) > > What I find really fun about the job spammers, is I'll get a call from a spammer, and either give them good advice on where to post, or give them good advice as to what type of janitoral career they shoudl be persuing instead. 1/5th of the time, I'll see those people google my name (looking at apache exit logs), find some of my postings in baylisa or sage, and then post their same flamebait job listings there. We need an anonymous, un-logged, un-archived mailing list to share opinions about some of these job postings & companies, because I've seen some really frightening ones get posted. It annoys me that companies have so many avvenues to unfairly deject potential employees, and job-seekers have zero recourse to warn good people off of bad jobs. On the flipside of that coin, it'd also be a good place to speak the accolades of the good companies to work for/good recruiters to work with. From rsr at inorganic.org Wed Oct 5 11:24:08 2005 From: rsr at inorganic.org (Roy S. Rapoport) Date: Wed, 5 Oct 2005 11:24:08 -0700 Subject: Tech jobs in the midwest? In-Reply-To: <20051005174746.GO54033@bunrab.catwhisker.org> References: <43440B82.50603@halligan.org> <20051005174746.GO54033@bunrab.catwhisker.org> Message-ID: <20051005182408.GA1836@puppy.inorganic.org> On Wed, Oct 05, 2005 at 10:47:46AM -0700, David Wolfskill wrote: > reasonably talented folks, I would also observe that none of the folks > I have heard saying positive things about the economy were either > significantly underemployed or had been unemployed for a significant > amount of time. The economy's doing pretty well. I spent two five month stints looking for jobs in the last four years. Does that count? -roy From michael at halligan.org Wed Oct 5 11:33:58 2005 From: michael at halligan.org (Michael T. Halligan) Date: Wed, 05 Oct 2005 11:33:58 -0700 Subject: Tech jobs in the midwest? In-Reply-To: <20051005174832.GA161@puppy.inorganic.org> References: <43440B82.50603@halligan.org> <20051005174832.GA161@puppy.inorganic.org> Message-ID: <43441C96.7030606@halligan.org> Roy S. Rapoport wrote: >On Wed, Oct 05, 2005 at 10:21:06AM -0700, Michael T. Halligan wrote: > > >>From time to time I seem to hear a lot of people complaining about the >>economy in the bay area.. This always seems >>to be followed by a lot of press about H1B visa caps, etc. This always >>gets followed by a flurry of spam from recruiters, >>most of them offshored recruiters in call centers, calling me about >>"wonderful jobs in ohio". >> >> > >I think it's more "a wonderful job in Ohio." I find it hard to believe >there's more than one. And once you're there ... it's a little hard to >find another one. > > Ohio is a funny one, though. A decade ago, I had a friend in Pennsylvania who worked in Ohio making $120k doing SAP programming with a sweet package (they paid his rent in Ohio, his weekly first class flights, $30 per diem eating expenses, a company car, etc). He still does it, making about the same amount, which in Bethlehem, Pennsylvania is the equivalent to $240k in the bay area. When I asked him how that was a good deal for his employer, he said his employer's other option was to pay an EDS like company $350k+ for the same position. Perhaps big business is just inherently inefficient? >>about the job situation (which I think is overblown >>by a few overtly vocal people), and will continually keep spamme... err >> >> > >Given how hard it is for us to find good people, I'd tend to agree. > > > >>Recruiters from the midwest are fun. Am I the only one being >>spammed/called by them so often, unsolicited? >> >> > >I've not gotten those calls. > >-roy > > I get them all the time. Three e-mails, and two calls today. 75% of the time they're offshored Indian recruiters over low quality VOIP connections who did a keyword search on Oracle and decided that I would be a great candidate for their fabulous Oracle DBA position making a mind-blowing $75k in Geary, Indiana or some equivalent cesspool. The other 25% of the time they're recruiters in the Midwest who used to make a great living at firms like Andersen or EDS staffing overblown $350/hour button pushers before the market got flooded by $25/hour button pushers. What's fun is I'll social engineer the customer out of them, then call up the customer, and find out what the real rate is, then call them back. The last call I successfully did this was for some aerospace (read: boeing) company town with a "Linux Architect" position they wanted to pay $35/hour for, which I found was $165/hour once I actually got to the person @ boeing who had hired the consulting firm that had contracted the staffing firm who spammed me. Someday I'll understand how the headhunter market still exists with their unrealistic margins. I've run the numbers, staffing bodies just isn't a good, scaleable business. -- Michael T. Halligan Chief Technology Officer ------------------- BitPusher, LLC http://www.bitpusher.com/ 1.888.9PUSHER 415.724.7998 (Mobile) 415.751.1073 (Fax) From pmm at igtc.com Wed Oct 5 11:48:53 2005 From: pmm at igtc.com (Paul M. Moriarty) Date: Wed, 5 Oct 2005 11:48:53 -0700 Subject: Tech jobs in the midwest? In-Reply-To: <20051005174832.GA161@puppy.inorganic.org> References: <43440B82.50603@halligan.org> <20051005174832.GA161@puppy.inorganic.org> Message-ID: <20051005184853.GB21993@igtc.igtc.com> Roy S. Rapoport writes: > > I think it's more "a wonderful job in Ohio." I find it hard to believe > there's more than one. And once you're there ... it's a little hard to > find another one. Yeah. They still use chisels and clay tablets for most things in Ohio. C'mon, there's interesting IT going on throughout the country. Now, if you want to limit yourself to high-tech only, perhaps the above statement is true. The major growth areas I see in IT moving forward are not in high-tech, but rather in health care and finance (especially real estate). - Paul - From david at catwhisker.org Wed Oct 5 11:48:26 2005 From: david at catwhisker.org (David Wolfskill) Date: Wed, 5 Oct 2005 11:48:26 -0700 Subject: Tech jobs in the midwest? In-Reply-To: <43441A2D.1020005@halligan.org> References: <43440B82.50603@halligan.org> <20051005174746.GO54033@bunrab.catwhisker.org> <43441A2D.1020005@halligan.org> Message-ID: <20051005184826.GS54033@bunrab.catwhisker.org> On Wed, Oct 05, 2005 at 11:23:41AM -0700, Michael T. Halligan wrote: > ... > >>I think the existance of the midwest will forever perplex the truth > > > >"perplex the truth?" Hmmm...? > > > This is what happens when your doctor forbids you from consuming > caffeine. 's/perplex/perpetuate/' Oh. Had *me* perplexed.... :-} > >Disclosure: I count myself as both "reasonably talented" and > >"significantly underemployed." > > I just don't see it. Maybe two or three years ago it was a bit tight, > but the past year or so has > been great. I'm happy for you. Your experience is apparently rather different from mine. > .... > I am constantly being called and emailed by recruiters, some of them who > even have relevant jobs. I'll grant that my experience with recruiters has been quite limited since a rather unpleasant experience with one in southern California around 1980. >... > Good people are good people, they just need to find a > way to connect with good job leads, which isn't always easy. Indeed. And perhaps BayLISA can help with this...? > ... > We need an anonymous, un-logged, un-archived mailing list to share > opinions about some of these job postings & companies, because I've > seen some really frightening ones get posted. Well, that could be a bit challenging, though mostly doable, as a mailing list. I observe that any recipient of messages from the list could create an archive, and could utilize that information in various ways. > It annoys me that companies have so many avvenues to unfairly deject > potential employees, and job-seekers have zero recourse to warn > good people off of bad jobs. On the flipside of that coin, it'd > also be a good place to speak the accolades of the good companies > to work for/good recruiters to work with. And without an archive, a given subscriber will only see the messages that are sent after the subscription takes effect. I'm becoming less certain that a "mailing list" is wanted for this application, vs. (e.g.) some Web-based forum. Folks who are sufficiently interested in implementing something like this should start communicating with one another. There's a mailing list, services-tf at baylisa.org, that is intended for folks implementing services for BayLISA. Peace, david -- David H. Wolfskill david at catwhisker.org Prediction is difficult, especially if it involves the future. -- Niels Bohr See http://www.catwhisker.org/~david/publickey.gpg for public key. From michael at halligan.org Wed Oct 5 11:57:59 2005 From: michael at halligan.org (Michael T. Halligan) Date: Wed, 05 Oct 2005 11:57:59 -0700 Subject: Tech jobs in the midwest? In-Reply-To: <20051005184853.GB21993@igtc.igtc.com> References: <43440B82.50603@halligan.org> <20051005174832.GA161@puppy.inorganic.org> <20051005184853.GB21993@igtc.igtc.com> Message-ID: <43442237.7000602@halligan.org> Paul M. Moriarty wrote: >Roy S. Rapoport writes: > > >>I think it's more "a wonderful job in Ohio." I find it hard to believe >>there's more than one. And once you're there ... it's a little hard to >>find another one. >> >> > >Yeah. They still use chisels and clay tablets for most things in Ohio. > >C'mon, there's interesting IT going on throughout the country. Now, if you >want to limit yourself to high-tech only, perhaps the above statement is >true. > >The major growth areas I see in IT moving forward are not in high-tech, but >rather in health care and finance (especially real estate). > >- Paul - > > Roy's point was right. Taking jobs in dead-end areas really limits you. There was an article on news.com a few months ago about software companies opening up in these impoverished dead farming communities. Their whole strategy was low cost in labor & other resources. They specifically mentioned moving people out under the guise of lower costs of living (with far lower salaries) and ensuring loyalty because they were the only option in town. The thing about working in, or near a major metropolitan area is that you have choices. There is absolutely no honor in being a company man, and staying with the same company your whole life. The last decade or so of spectacular bankruptcies, offshoring, and pension mismanagement should have been a wake-up call to everybody. The last thing you should be saying before you take a job is "Show me the money". Since the beginning, I've laughed my head off when companies offered me lower salaries with higher amounts of stock options, especially in the bay area where the rule is to over-hire to meet a deadline, then do mass layoffs afterwards. If a company wants to keep an employee, they shouldn't even bother with false promises of stock options, gradual salary increases, etc. The two things a company MUST do to keep and retain good talent is give them competitive salaries, and keep them working on interesting projects, because the employee is going to be looking out for themself first, they're not stupid. You're definitely right about health care & finance. I guess in those areas you can get pidgeonholed into a cog-like position as a techie... Maybe get thrown a bone every five years when a new auditing standard gets forced upon the employer.. Then at age 55 find out that your promised pension was mismanaged, and you now have to work until age 70, like everybody at Lucent/Bell/AT&T found out in the late '90s, like everybody at GM will find out this decade. The real estate money is a karmically sad one. Real estage agents & mortgage brokers pushing massive interest-only loans on people who cannot afford them, but are too caught up in the buzz to think better. In the end, when it crashes, there will be massive bailouts like the SNL bailouts of the early '80s, and the same unethical real estate and mortgage brokers will get to sell the houses a second time. Yes, I definitely miss caffeine. Michael T. Halligan Chief Technology Officer ------------------- BitPusher, LLC http://www.bitpusher.com/ 1.888.9PUSHER 415.724.7998 (Mobile) 415.751.1073 (Fax) From pmm at igtc.com Wed Oct 5 12:08:25 2005 From: pmm at igtc.com (Paul M. Moriarty) Date: Wed, 5 Oct 2005 12:08:25 -0700 Subject: Tech jobs in the midwest? In-Reply-To: <43442237.7000602@halligan.org> References: <43440B82.50603@halligan.org> <20051005174832.GA161@puppy.inorganic.org> <20051005184853.GB21993@igtc.igtc.com> <43442237.7000602@halligan.org> Message-ID: <20051005190825.GD21993@igtc.igtc.com> Michael T. Halligan writes: > > Roy's point was right. Taking jobs in dead-end areas really limits > you. There was an article > on news.com a few months ago about software companies opening up in > these impoverished > dead farming communities. Their whole strategy was low cost in labor & > other resources. They > specifically mentioned moving people out under the guise of lower costs > of living (with far lower > salaries) and ensuring loyalty because they were the only option in town. I read that article. IIRC they were talking about South Dakota and Arkansas. Not Ohio. Top 50 metropolitan areas in the US: 15. Cleveland-Akron 2.9 mln people 23. Cincinnati-Hamilton 1.9 mln 31. Columbus 1.4 mln 49. Dayton-Springfield .9 mln Ohio is a pretty populous state. Remember the last national election? 20 electoral votes. By comparison, Arkansas has 6. South Dakota has 3. - Paul - From michael at halligan.org Wed Oct 5 12:15:50 2005 From: michael at halligan.org (Michael T. Halligan) Date: Wed, 05 Oct 2005 12:15:50 -0700 Subject: Tech jobs in the midwest? In-Reply-To: <20051005190825.GD21993@igtc.igtc.com> References: <43440B82.50603@halligan.org> <20051005174832.GA161@puppy.inorganic.org> <20051005184853.GB21993@igtc.igtc.com> <43442237.7000602@halligan.org> <20051005190825.GD21993@igtc.igtc.com> Message-ID: <43442666.9010004@halligan.org> Paul M. Moriarty wrote: >Michael T. Halligan writes: > > >>Roy's point was right. Taking jobs in dead-end areas really limits >>you. There was an article >>on news.com a few months ago about software companies opening up in >>these impoverished >>dead farming communities. Their whole strategy was low cost in labor & >>other resources. They >>specifically mentioned moving people out under the guise of lower costs >>of living (with far lower >>salaries) and ensuring loyalty because they were the only option in town. >> >> > >I read that article. IIRC they were talking about South Dakota and Arkansas. >Not Ohio. > >Top 50 metropolitan areas in the US: > >15. Cleveland-Akron 2.9 mln people >23. Cincinnati-Hamilton 1.9 mln >31. Columbus 1.4 mln >49. Dayton-Springfield .9 mln > >Ohio is a pretty populous state. Remember the last national election? 20 >electoral votes. By comparison, Arkansas has 6. South Dakota has 3. > >- Paul - > > Ohio is a pretty populous state. So is Indiana. Both of them are still reeling to find a new economy after the death of manufacturing in the '80s. Working in the midwest, except maybe Chicago is like being the last guy at a start-up in the valley, except it's cold and there's nowhere to go once you've sold off the rest of the equipment. Population means nothing in this context really. Columbus? How much of that population exists to support the college, or are students themselves? Hey, I'm not trying to bash the midwest, without Ohio we'd probably only throw out 50% of our yearly corn crop instead of 60% of it. -- Michael T. Halligan Chief Technology Officer ------------------- BitPusher, LLC http://www.bitpusher.com/ 1.888.9PUSHER 415.724.7998 (Mobile) 415.751.1073 (Fax) From michael at halligan.org Wed Oct 5 12:16:30 2005 From: michael at halligan.org (Michael T. Halligan) Date: Wed, 05 Oct 2005 12:16:30 -0700 Subject: Tech jobs in the midwest? In-Reply-To: <20051005190825.GD21993@igtc.igtc.com> References: <43440B82.50603@halligan.org> <20051005174832.GA161@puppy.inorganic.org> <20051005184853.GB21993@igtc.igtc.com> <43442237.7000602@halligan.org> <20051005190825.GD21993@igtc.igtc.com> Message-ID: <4344268E.1090804@halligan.org> Oh, and to be fair to Ohio. Cedar Point is awesome. Paul M. Moriarty wrote: >Michael T. Halligan writes: > > >>Roy's point was right. Taking jobs in dead-end areas really limits >>you. There was an article >>on news.com a few months ago about software companies opening up in >>these impoverished >>dead farming communities. Their whole strategy was low cost in labor & >>other resources. They >>specifically mentioned moving people out under the guise of lower costs >>of living (with far lower >>salaries) and ensuring loyalty because they were the only option in town. >> >> > >I read that article. IIRC they were talking about South Dakota and Arkansas. >Not Ohio. > >Top 50 metropolitan areas in the US: > >15. Cleveland-Akron 2.9 mln people >23. Cincinnati-Hamilton 1.9 mln >31. Columbus 1.4 mln >49. Dayton-Springfield .9 mln > >Ohio is a pretty populous state. Remember the last national election? 20 >electoral votes. By comparison, Arkansas has 6. South Dakota has 3. > >- Paul - > > -- Michael T. Halligan Chief Technology Officer ------------------- BitPusher, LLC http://www.bitpusher.com/ 1.888.9PUSHER 415.724.7998 (Mobile) 415.751.1073 (Fax) From holland at guidancetech.com Wed Oct 5 12:24:31 2005 From: holland at guidancetech.com (Rich Holland) Date: Wed, 5 Oct 2005 12:24:31 -0700 Subject: Tech jobs in the midwest? In-Reply-To: <43441C96.7030606@halligan.org> Message-ID: <20051005192459.CDCFF87@orb.sasl.smtp.pobox.com> Michael T. Halligan wrote: > Someday I'll understand how the headhunter market still exists with > their unrealistic margins. I've run the numbers, > staffing bodies just isn't a good, scaleable business. ...it is if you can source candidates for $35/hr and bill them at $165/hr! If there weren't a market for this sort of slimy activity, it wouldn't exist. The same is true of spam -- it wouldn't be sent if it didn't work on some small level. If you could make $130/hr off some guy's every hour of work, it doesn't take a lot of "hits" to make all the shots in the dark worthwhile, I'd guess. -- Rich Holland (913) 645-1950 SAP Technical Consultant print unpack("u","92G5S\=\"!A;F]T:&5R(\'!E Message-ID: hi ya On Wed, 5 Oct 2005, Michael T. Halligan wrote: > Recruiters from the midwest are fun. Am I the only one being > spammed/called by them so often, unsolicited? you're probably on somebody's spam list of people to call/email i get tons of it ... but i dont pick up the phone calls on the first ring etc, etc ... - if the call is real, they'll leave a message, etc "great job" spams by email ... i can't reject those ... that's how we make a living .. and a little hard to filter since they're all strangers until we reply to it or blacklist 'um c ya alvin From rsr at inorganic.org Thu Oct 6 09:37:25 2005 From: rsr at inorganic.org (Roy S. Rapoport) Date: Thu, 6 Oct 2005 09:37:25 -0700 Subject: Tech jobs in the midwest? In-Reply-To: <20051005184853.GB21993@igtc.igtc.com> References: <43440B82.50603@halligan.org> <20051005174832.GA161@puppy.inorganic.org> <20051005184853.GB21993@igtc.igtc.com> Message-ID: <20051006163725.GA29815@puppy.inorganic.org> On Wed, Oct 05, 2005 at 11:48:53AM -0700, Paul M. Moriarty wrote: > The major growth areas I see in IT moving forward are not in high-tech, but > rather in health care and finance (especially real estate). And if all you need/want is good pay or just a job, that's a good thing to remember. I'm not trying to be snarky here -- I used to think that I'd really prefer not to work in financial companies due to the culture thing, but then was out of a job for about four months and when the opportunity to join a financial company came up, I jumped on it. I'd do it again if I had to -- being employed is a Good thing[tm]. But you know, the truth is that in my experience, at least, financial companies and health care organizations (got a friend who's a network engineer in one) typically encourage an environment that I frankly know, due to my own character limitations, I don't thrive, nor am I happy, in. So for me, it really needs to be some sort of innovative tech company, and it'd be hard to find a concentration of these sorts of opportunities between the coasts, I think. Not that I disagree with you, of course -- the real estate angle especially is an interesting one, and speaking as someone who's dating an attorney looking to get into real estate, I hope it becomes even hotter :) -roy From sigje at sigje.org Thu Oct 6 09:59:54 2005 From: sigje at sigje.org (Jennifer Davis) Date: Thu, 6 Oct 2005 09:59:54 -0700 (PDT) Subject: BaySUG 2005 Registration Open! Message-ID: Event: The Bay Area Super User Group Meeting, aka BaySUG 2005 Date: November 12, 2005 Time: 1-5pm Location: Mountain View, CA Cost: Free! Agenda: Still being finalized .. but Chris DiBona will be talking about the Summer of Code Projects, and Jeremy Allison will be talking about Samba Registration is available now (limited to ~300, first come first served!) Notes: This is going to be an amazing event. USENIX will be using their powerhouse of knowledge of running conferences to organize, and set up the event. We will have power, and wireless available. Registration will be in a similar style as USENIX conferences. -- Jennifer Davis BayLISA Board of Directors From sigje at sigje.org Thu Oct 6 10:34:28 2005 From: sigje at sigje.org (Jennifer Davis) Date: Thu, 6 Oct 2005 10:34:28 -0700 (PDT) Subject: BaySUG 2005 Registration Open! In-Reply-To: References: Message-ID: > Event: The Bay Area Super User Group Meeting, aka BaySUG 2005 > Date: November 12, 2005 > Time: 1-5pm > Location: Mountain View, CA > Cost: Free! > Agenda: Still being finalized .. but Chris DiBona will be talking about the > Summer of Code Projects, and Jeremy Allison will be talking about Samba > > Registration is available now (limited to ~300, first come first served!) It would be useful to have the URL for registration. Sorry about that: https://db.usenix.org/cgi-bin/Conference/baysug05/reg.cgi Jennifer From holland at guidancetech.com Thu Oct 6 11:06:17 2005 From: holland at guidancetech.com (Rich Holland) Date: Thu, 6 Oct 2005 11:06:17 -0700 Subject: Tech jobs in the midwest? In-Reply-To: <20051006163725.GA29815@puppy.inorganic.org> Message-ID: <20051006174918.BE17249A9@thorn.sasl.smtp.pobox.com> Roy wrote: > [...] and speaking as someone who's dating an attorney looking > to get into real estate, I hope it becomes even hotter :) Real estate or the attorney? :-) -- Rich Holland (913) 645-1950 SAP Technical Consultant print unpack("u","92G5S\=\"!A;F]T:&5R(\'!E References: <20051006163725.GA29815@puppy.inorganic.org> <20051006174918.BE17249A9@thorn.sasl.smtp.pobox.com> Message-ID: <20051006191840.GA7630@puppy.inorganic.org> On Thu, Oct 06, 2005 at 11:06:17AM -0700, Rich Holland wrote: > Roy wrote: > > > [...] and speaking as someone who's dating an attorney looking > > to get into real estate, I hope it becomes even hotter :) > > Real estate or the attorney? :-) I think the attorney would find it hard to be hotter. :) (Hey, what am I supposed to say?) -roy From sigje at sigje.org Fri Oct 7 08:00:01 2005 From: sigje at sigje.org (Jennifer Davis) Date: Fri, 7 Oct 2005 08:00:01 -0700 (PDT) Subject: Oct 20, 2005: BayLISA: Incident Command for IT In-Reply-To: References: Message-ID: This meeting is sponsored by USENIX. Please join us for an evening of brilliant technical talk from local expert Brent Chapman, who will be just back from his experience helping out with setting up IT in the hurricane devastated regions in the South, and pizza! Date: Thursday, October 20, 2005 Where: Apple Campus, Building 4, upstairs meeting room (Garage 1) (Yes, we are back to our usual room, with power, and network galore!) Free and Open to the General Public! Please RSVP to rsvp at baylisa.org so we have an idea of how much pizza and soda to buy! 7:30 pm Introductions and announcements 7:45 pm Formal Presentation 9:45 After-meeting social outings at a local restaurant D. Brent Chapman will be presenting "Incident Command for IT: What we can Learn from the Fire Department". This is one of the USENIX LISA 2005 invited talks http://www.usenix.org/events/lisa05/tech/. If you have ever been curious about what kind of value you get from the LISA conference, come check out Brent's talk. LISA packs in 5 days of training and 4 days of technical sessions (they overlap on days for a total of 6 days of technical immersion), and is the conference for System Administrators. It's being held in San Diego, California this year, so much easier for travelling. Many thanks to USENIX for sharing Brent's technical talk at BayLISA, and sponsoring the October meeting. ______________________________________________ baylisa mailing list: baylisa at baylisa.org rsvp for meeting: rsvp at baylisa.org baylisa board (request to sponsor or present): blw at baylisa.org From sigje at sigje.org Fri Oct 7 16:59:22 2005 From: sigje at sigje.org (Jennifer Davis) Date: Fri, 7 Oct 2005 16:59:22 -0700 (PDT) Subject: Thoughts.. Message-ID: (please pass this on to any lists you think would be interested in contributing, or participating!) So if given the thought "Critical Problems of our Industry", what springs to mind? What aspects of your job do you think "they" could do better, (where they is the vendors or open source ventures that tackle some of the problems)? What things do you bang your head on the table about, or find yourself griping about yet again at the local coffee shop? The reason I'm asking is that BayLISA is planning a "System Administrators' Problems and Solutions" Summit and we are trying to come up with 5 topics that would be of interest. Any information to come out of this sharing of the minds will be made available on the website! (For those people interested in attending, save November 17 on your calendar. This will take place in San Francisco proper for easy access to public transportation. Send me an email, and I'll keep you updated. It will be limited to 75-100 people who will split up into the 5 groups - each person will tackle two of the problems, and then we'll all talk about the thoughts generated in the groups. For you guru types in the area, I'm also looking for moderators for the discussions. We will feed you, and supply plenty of tasty chocolate/soda. ) Many Many Thanks! :) Hopefully this will stir up some constructive conversations. Jennifer From sigje at sigje.org Fri Oct 7 17:20:52 2005 From: sigje at sigje.org (Jennifer Davis) Date: Fri, 7 Oct 2005 17:20:52 -0700 (PDT) Subject: Thoughts updated.. Message-ID: The date to reserve is November 19 for the "Summit". November 17, also an important date is Elections. Sorry about (my) confusion. Jennifer From jeff at drinktomi.com Sat Oct 8 10:24:44 2005 From: jeff at drinktomi.com (Jeff With The Big Yellow Suit) Date: Sat, 8 Oct 2005 10:24:44 -0700 Subject: Thoughts.. In-Reply-To: References: Message-ID: <6aa6ce1e75b74c5174fb1fb6e19a5865@drinktomi.com> Inventory. Knowing what you have is the key to controlling it and auditing it. It's not glamorous, but I've yet to work at a company that had an accurate database of what they owned and how it was configured. It's not a glamorous problem, but I think solving it is necessary to addressing a host of other issues. -jeff On Oct 7, 2005, at 4:59 PM, Jennifer Davis wrote: (please pass this on to any lists you think would be interested in contributing, or participating!) So if given the thought "Critical Problems of our Industry", what springs to mind? What aspects of your job do you think "they" could do better, (where they is the vendors or open source ventures that tackle some of the problems)? What things do you bang your head on the table about, or find yourself griping about yet again at the local coffee shop? From sigje at sigje.org Sat Oct 8 11:21:53 2005 From: sigje at sigje.org (Jennifer Davis) Date: Sat, 8 Oct 2005 11:21:53 -0700 (PDT) Subject: Location.. Message-ID: So I've heard from people time and again that BayLISA meetings are located too far South to easily get to. So in planning events outside of BayLISA general meetings I try to find places further North.. ie Mountain View, San Francisco.. Where are the people interested in BayLISA events really located? Is Cupertino great fine and dandy? Added to that, when are the best times to have events.. evenings or weekends? Jennifer From rick at linuxmafia.com Sat Oct 8 22:24:32 2005 From: rick at linuxmafia.com (Rick Moen) Date: Sat, 8 Oct 2005 22:24:32 -0700 Subject: Location.. In-Reply-To: References: Message-ID: <20051009052431.GK8455@linuxmafia.com> Quoting Jennifer Davis (sigje at sigje.org): > So I've heard from people time and again that BayLISA meetings are located > too far South to easily get to. So in planning events outside of BayLISA > general meetings I try to find places further North.. ie Mountain View, > San Francisco.. > > Where are the people interested in BayLISA events really located? Is > Cupertino great fine and dandy? > > Added to that, when are the best times to have events.. evenings or > weekends? You can drive yourself mad, trying to get a good answer to those questions. Days/times.... Conventional wisdom about day choice, filtered through local workaholism, is: Monday evening, many people will be frazzled at the end of a busy first day of work. Tuesday, Wednesday, and Thursday evenings are considered good. Friday, people are assumed to want free or with their families. Saturday morning is assumed bad: People are assumed to want to sleep in. Saturday afternoon and evening are assumed good, though best for somewhat laid-back events. Sundays seem unpopular: I'm guessing that people are assumed to be unavailable for various reasons. (Might be true, might not. Few groups have tested the assumption.) Ask people which night is best, and you tend to run straight into sampling bias. E.g., ask on the Internet, and people will weigh in who won't attend in-person meetings at all, but have opinions anyway. Try to fix that problem by asking people attending a Tuesday in-person event, and (of course) the overwhelmning majority will respond that they like Tuesday evenings. (After all, they came; the Tuesday-haters mostly didn't.) Locations.... Hold meetings in Cupertino, and the two guys in Burlingame will claim you'd do better to move north. Hold them in Redwood City, and the two participants from Morgan Hill will advise going south. One way to find out is move and see what happens -- but then you should wait a few months: Some former regulars will cease attending, but you'll also slowly pick up people for whom the new location is better. (Any move introduces "friction" over the shart term: All else being equal, keep changes of venue/time to a minimum.) In short, it's a muddle, and ultimately has to come down to someone's judgement about which area to serve and what evening or afternoon to stake out. In an ideal world, you _would_ be able to survey who our intended constituency are and where they live & work, then pick spots and regular times that work for them, but I'm not able to envision offhand any real-world heuristic that approximates that very well. (If someone else can think of one, though, good!) -- Cheers, Chip Salzenberg: "Usenet is not a right." Rick Moen Edward Vielmetti: "Usenet is a right, a left, a jab, rick at linuxmafia.com and a sharp uppercut to the jaw. The postman hits! You have new mail." From jesse at boldandbusted.com Sun Oct 9 01:50:22 2005 From: jesse at boldandbusted.com (Jesse Adelman) Date: Sun, 9 Oct 2005 01:50:22 -0700 (PDT) Subject: Location.. In-Reply-To: Message-ID: <20051009085022.37098.qmail@web60717.mail.yahoo.com> Hello. I'm not a Bay-LISA member, just a lurking Linux SysAdmin in SF. Might I suggest setting up Mod_Survey to generate a web-based survey for such questions? It exports to a wide variety of formats (SPSS, CSV, Excel, Access, etc.), and is well supportd. I really like it, have installed it for a few clients, and it is pretty easy to use if you know HTML, or any tag-based markup. http://gathering.itm.mh.se/modsurvey/ Cheers, Jesse Adelman SF, CA --- Jennifer Davis wrote: > > So I've heard from people time and again that BayLISA meetings are > located > too far South to easily get to. So in planning events outside of > BayLISA > general meetings I try to find places further North.. ie Mountain > View, > San Francisco.. > > Where are the people interested in BayLISA events really located? Is > > Cupertino great fine and dandy? > > Added to that, when are the best times to have events.. evenings or > weekends? > > Jennifer > -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Jesse Adelman http://www.boldandbusted.com/ -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ From sigje at sigje.org Tue Oct 11 13:28:11 2005 From: sigje at sigje.org (Jennifer Davis) Date: Tue, 11 Oct 2005 13:28:11 -0700 (PDT) Subject: Violation of Security/Privacy... Message-ID: Interesting articles here: http://www.alternet.org/columnists/story/26402/ www.rootkit.com/blog.php?newsid=358 In summary, it appears that Blizzard is doing some interesting things with looking at process/files running on the system to keep people from breaking the EULA. Now I'm wondering about other software companies attaching this kind of spyware into their software. We don't allow this kind of thing in our web browsers, we specifically install Spyware detection kits, and in general we have very strong opinions about privacy. Is this legal? Just the idea that a bunch of different software companies implementing this kind of scheme with their software, and _stealing_ my system resources gets me kind of angry. Maybe you don't play WoW, so you might not find this applicable to you, but if there isn't any comments about this, then perhaps companies will start accepting that it's completely ok to do this sort of thing. Jennifer From zwicky at greatcircle.com Tue Oct 11 17:10:37 2005 From: zwicky at greatcircle.com (Elizabeth Zwicky) Date: Tue, 11 Oct 2005 17:10:37 -0700 Subject: Violation of Security/Privacy... In-Reply-To: References: Message-ID: <7ee9e5e178c131c6030d4fe5acf425b5@greatcircle.com> So they go through a lot of stuff and hash it, and complain if the hashes match ones they don't like. The only thing it sends back to the company is "Yes, this hash matched". As invasions of privacy go, I'm not impressed. As for stealing resources, exactly how is it stealing system resources for a game to use cycles while you are running it? It's stealing resources by reading more files than it should and wearing out your disk bearings too fast? If using more CPU than you need is an offense against propriety, there isn't a lot of software that avoids stealing resources. And no, this doesn't violate anybody's 4th amendment rights because the 4th amendment only applies to the government, and World of Warcraft is not run by the legitimate government of the United States. I believe companies decided this was completely OK long ago, and nasty EULAs are not uncommon. I don't even think this one is particularly unreasonable. Elizabeth On Oct 11, 2005, at 1:28 PM, Jennifer Davis wrote: > > Interesting articles here: > http://www.alternet.org/columnists/story/26402/ > www.rootkit.com/blog.php?newsid=358 > > In summary, it appears that Blizzard is doing some interesting things > with looking at process/files running on the system to keep people > from breaking the EULA. > > Now I'm wondering about other software companies attaching this kind > of spyware into their software. We don't allow this kind of thing in > our web browsers, we specifically install Spyware detection kits, and > in general we have very strong opinions about privacy. > > Is this legal? Just the idea that a bunch of different software > companies implementing this kind of scheme with their software, and > _stealing_ my system resources gets me kind of angry. > > Maybe you don't play WoW, so you might not find this applicable to > you, but if there isn't any comments about this, then perhaps > companies will start accepting that it's completely ok to do this sort > of thing. > > > Jennifer > From sigje at sigje.org Tue Oct 11 17:21:40 2005 From: sigje at sigje.org (Jennifer Davis) Date: Tue, 11 Oct 2005 17:21:40 -0700 (PDT) Subject: Violation of Security/Privacy... In-Reply-To: <7ee9e5e178c131c6030d4fe5acf425b5@greatcircle.com> References: <7ee9e5e178c131c6030d4fe5acf425b5@greatcircle.com> Message-ID: > So they go through a lot of stuff and hash it, and complain if the hashes > match ones they don't like. The only thing it sends back > to the company is "Yes, this hash matched". As invasions of > privacy go, I'm not impressed. As for stealing resources, Do I know what the hashes are? Does the presence of something on my system mean that they should have access to it? Considering the number of things that can be hidden in packets (as illustrated by the instructive talk Mark Langston gave last year as one example), should I really trust that some process poking around in _all_ my files/processes is genuinely ok? > exactly how is it stealing system resources for a game to use > cycles while you are running it? It's stealing resources by > reading more files than it should and wearing out your disk > bearings too fast? If using more CPU than you need is an > offense against propriety, there isn't a lot of software > that avoids stealing resources. Well my system which is quite a speedy system, 3.2 GHz CPU, and 2GB of memory used to be able to run multiple applications and WoW at the same time. Ie I could chill out working on stuff have the application minimized in part of the screen and work on other items, check email, etc on my 21 inch monitor. Since the update, I can't. In fact my system chugs. So yes, I feel like the company has decided to steal some of my resources. I see the function of them guaranteeing the integrity of their gaming environment as a separate requirement than my gaming experience. I purchased a game, and pay a monthly fee to experience that game. They shouldn't be borrowing my system resources to filter out addons. Jennifer From alvin at Mail.Linux-Consulting.com Tue Oct 11 18:11:02 2005 From: alvin at Mail.Linux-Consulting.com (Alvin Oga) Date: Tue, 11 Oct 2005 18:11:02 -0700 (PDT) Subject: slow Re: Violation of Security/Privacy... In-Reply-To: Message-ID: hi ya On Tue, 11 Oct 2005, Jennifer Davis wrote: > Do I know what the hashes are? Does the presence of something on my > system mean that they should have access to it? no .. unless its the police etc... with court orders .. > Well my system which is quite a speedy system, 3.2 GHz CPU, and 2GB of > memory used to be able to run multiple applications and WoW at the same > time. i'm curious, what are you running that makes it go chug-a-lug-putt-putt... my k6-350 w/ 256M of memory with 50+ xterms with ssh to various pc keep up fine with me .. ( except for a 5sec stall to bring up the bloatware konqueror/mozilla ) but there's a memory leak some place, that the silly box needs to be rebooted once every couple months and ssh back into all them pc's again .. c ya alvin From david at catwhisker.org Tue Oct 11 18:24:20 2005 From: david at catwhisker.org (David Wolfskill) Date: Tue, 11 Oct 2005 18:24:20 -0700 Subject: Violation of Security/Privacy... In-Reply-To: References: Message-ID: <20051012012420.GD47561@bunrab.catwhisker.org> On Tue, Oct 11, 2005 at 01:28:11PM -0700, Jennifer Davis wrote: > > Interesting articles here: > http://www.alternet.org/columnists/story/26402/ > www.rootkit.com/blog.php?newsid=358 > > In summary, it appears that Blizzard is doing some interesting things with > looking at process/files running on the system to keep people from > breaking the EULA. OK; I admit that I was too lazy to deref the above link & read it.... But it seems to me that they'd need to acquire the information in order to make use of it. So what happens if the information received differs from that sent? Might there be perturbations of that information that might catalyze "interesting" reactions from Blizzard (whoever they are/it is)? Peace, david (who is sometimes known to edit his "cookie" files for spite) -- David H. Wolfskill david at catwhisker.org Prediction is difficult, especially if it involves the future. -- Niels Bohr See http://www.catwhisker.org/~david/publickey.gpg for public key. From alvin at Mail.Linux-Consulting.com Tue Oct 11 18:53:13 2005 From: alvin at Mail.Linux-Consulting.com (Alvin Oga) Date: Tue, 11 Oct 2005 18:53:13 -0700 (PDT) Subject: cookies .. Re: Violation of Security/Privacy... In-Reply-To: <20051012012420.GD47561@bunrab.catwhisker.org> Message-ID: hi ya david On Tue, 11 Oct 2005, David Wolfskill wrote: > david (who is sometimes known to edit his "cookie" files for spite) doesn't that screw up your order ( shopping cart ?? ) or i suppose you're changing it after the order is completed .. but cookies/js/java/history/cache should all be turned off to begin with c ya alvin From baylisa at jgreely.com Tue Oct 11 19:16:53 2005 From: baylisa at jgreely.com (J Greely) Date: Tue, 11 Oct 2005 19:16:53 -0700 Subject: Violation of Security/Privacy... In-Reply-To: References: Message-ID: <76BF2480-E435-4803-878B-F572CB7BE618@jgreely.com> On Oct 11, 2005, at 1:28 PM, Jennifer Davis wrote: > Interesting articles here: > http://www.alternet.org/columnists/story/26402/ > www.rootkit.com/blog.php?newsid=358 As smoking guns go, these lack both smoke and guns. Nothing about visible performance hits on your machine, nothing about uploading PII to their servers, just a fairly simple scan of running processes for known hacks, and a few heuristic methods for identifying the processes to scan. > In summary, it appears that Blizzard is doing some interesting things > with looking at process/files running on the system to keep people > from > breaking the EULA. Could be worse. They could still be using the old Diablo cheat-checker that not only lost all your save files when you reconfigured your machine in just about any way, but also when Daylight Savings Time started. Of course, the simple solution to this problem is to turn on fast user switching and run the game from another account that has limited privileges. That way it won't have permission to read any processes, files, or memory that might contain personal or confidential information, and all of your applications are a click away. Since WoW doesn't ship with any setuid root binaries, that'll lock it down pretty securely. Oh, wait, you're not playing WoW on a Mac, are you? Glad I am. A careful reading of the ToS suggests two conditions under which you agree to allow them to acquire information from your machine: - scanning RAM and process table for known hack programs. - collecting system identification information to hash into a unique identifier (hopefully less prone to error than the mess used in Diablo 1.0). The ToS and the linked articles suggest that no PII leaves your system, which is exactly what I'd expect from a company that needs to keep a few million people happy or risk losing their monthly fees. > Now I'm wondering about other software companies attaching this > kind of > spyware into their software. Look for any software that includes an "activation" system. Since it's not running on one of those vaporware trusted computing platforms, its method is going to look pretty similar to Blizzard's. > and _stealing_ my system resources gets me kind of angry. I note that the text mentioning the hack scanner is in ALL CAPS, and you must scroll through the ToS to the end every time it's updated and click the Accept button. Never mind that the chances of this code visibly degrading your system performance are somewhere between 'slim' and 'none'. I see no evidence in the linked articles supporting this claim, and no one in my guild has experienced any such slowdown after a patch (Mac or PC). -j From gwen at reptiles.org Tue Oct 11 19:31:48 2005 From: gwen at reptiles.org (Gwendolynn ferch Elydyr) Date: Tue, 11 Oct 2005 22:31:48 -0400 (EDT) Subject: Violation of Security/Privacy... In-Reply-To: References: <7ee9e5e178c131c6030d4fe5acf425b5@greatcircle.com> Message-ID: <20051011222614.T49277@skink.reptiles.org> On Tue, 11 Oct 2005, Jennifer Davis wrote: >> So they go through a lot of stuff and hash it, and complain if the hashes >> match ones they don't like. The only thing it sends back >> to the company is "Yes, this hash matched". As invasions of >> privacy go, I'm not impressed. As for stealing resources, > > Do I know what the hashes are? Does the presence of something on my system > mean that they should have access to it? Considering the number of things > that can be hidden in packets (as illustrated by the instructive talk Mark > Langston gave last year as one example), should I really trust that some > process poking around in _all_ my files/processes is genuinely ok? Er... perhaps there's some confusion here about what exactly a 'hash' is in this context. Even at the most simplistic, presuming that they're using something like an MD5 hash, which under most conditions[0] will always be unique to any given bit of data, you're still not talking about something that would allow them to reverse engineer that piece of data. MD5 (test.out) = 3730fc15d054e3ead3db0e1049f28959 would allow you to say that the following was identical: MD5 (test) = 3730fc15d054e3ead3db0e1049f28959 ... but wouldn't say a thing about the file contents[1]. cheers! [0] Yes, collisions are possible, but hard to come by in general. [1] If you -can- tell me about the file contents based on a hash, I'd be interested and amused. ========================================================================== "A cat spends her life conflicted between a deep, passionate and profound desire for fish and an equally deep, passionate and profound desire to avoid getting wet. This is the defining metaphor of my life right now." From ahorn at deorth.org Tue Oct 11 20:18:59 2005 From: ahorn at deorth.org (Alan Horn) Date: Tue, 11 Oct 2005 20:18:59 -0700 (PDT) Subject: Violation of Security/Privacy... In-Reply-To: <76BF2480-E435-4803-878B-F572CB7BE618@jgreely.com> References: <76BF2480-E435-4803-878B-F572CB7BE618@jgreely.com> Message-ID: On Tue, 11 Oct 2005, J Greely wrote: >Date: Tue, 11 Oct 2005 19:16:53 -0700 >From: J Greely >To: baylisa at baylisa.org >Subject: Re: Violation of Security/Privacy... > > > On Oct 11, 2005, at 1:28 PM, Jennifer Davis wrote: >> Interesting articles here: >> http://www.alternet.org/columnists/story/26402/ >> www.rootkit.com/blog.php?newsid=358 > > As smoking guns go, these lack both smoke and guns. Nothing about > visible performance hits on your machine, nothing about uploading > PII to their servers, just a fairly simple scan of running processes > for known hacks, and a few heuristic methods for identifying the > processes to scan. I recall everquest trying something similar and it lasted about three weeks before dying under consumer pressure. With several million players, even a few percent is likely to be a considerably loud minority. There *are* privacy issues associated with this. I have absolutely no idea what Blizzard does with any data they receive, and I haven't seen any references online to exactly what they're looking for, other than the EULA. I think the big issue is not that they're doing it, but that they're not disclosing enough details to satisfy the more concerned amongst the community. Other than voting with ones feet, there is little to be done to bring accountability here. The problem there of course, is if you play the game, you probably want to continue playing the game. You could argue that if all that gets passed is hashes, then its harmless. However, what if thoses hashes are of files that are considered subversive, or key phrases that are related to terrorist activities, or any number of 'lawful intercept' reasons. This isn't to say that Blizzard will do this, but maybe the next vendor will... I think theres a larger picture here. Cheers, Al From gwen at reptiles.org Tue Oct 11 21:05:55 2005 From: gwen at reptiles.org (Gwendolynn ferch Elydyr) Date: Wed, 12 Oct 2005 00:05:55 -0400 (EDT) Subject: Violation of Security/Privacy... In-Reply-To: References: <76BF2480-E435-4803-878B-F572CB7BE618@jgreely.com> Message-ID: <20051012000437.R49277@skink.reptiles.org> On Tue, 11 Oct 2005, Alan Horn wrote: > You could argue that if all that gets passed is hashes, then its harmless. > However, what if thoses hashes are of files that are considered subversive, > or key phrases that are related to terrorist activities, or any number of > 'lawful intercept' reasons. Actually I don't see why they'd pass anything other than a binary pass/fail. Either there's a match, against -something-, or there isn't. In a game context, any match would mean you were cheating. cheers! ========================================================================== "A cat spends her life conflicted between a deep, passionate and profound desire for fish and an equally deep, passionate and profound desire to avoid getting wet. This is the defining metaphor of my life right now." From ahorn at deorth.org Tue Oct 11 21:41:47 2005 From: ahorn at deorth.org (Alan Horn) Date: Tue, 11 Oct 2005 21:41:47 -0700 (PDT) Subject: Violation of Security/Privacy... In-Reply-To: <20051012000437.R49277@skink.reptiles.org> References: <76BF2480-E435-4803-878B-F572CB7BE618@jgreely.com> <20051012000437.R49277@skink.reptiles.org> Message-ID: On Wed, 12 Oct 2005, Gwendolynn ferch Elydyr wrote: >> You could argue that if all that gets passed is hashes, then its harmless. >> However, what if thoses hashes are of files that are considered subversive, >> or key phrases that are related to terrorist activities, or any number of >> 'lawful intercept' reasons. > > Actually I don't see why they'd pass anything other than a binary > pass/fail. Either there's a match, against -something-, or there isn't. > All intel is intel... > In a game context, any match would mean you were cheating. Who was talking about a game context ? :) Cheers, Al From extasia at extasia.org Tue Oct 11 21:45:03 2005 From: extasia at extasia.org (David Alban) Date: Tue, 11 Oct 2005 21:45:03 -0700 Subject: [baylisa] cookies .. Re: Violation of Security/Privacy... In-Reply-To: References: <20051012012420.GD47561@bunrab.catwhisker.org> Message-ID: <4c714a9c0510112145t11a515cdw6e707ed2e72d5f1a@mail.gmail.com> On 10/11/05, Alvin Oga wrote: > On Tue, 11 Oct 2005, David Wolfskill wrote: > > david (who is sometimes known to edit his "cookie" files for spite) > > doesn't that screw up your order ( shopping cart ?? ) > or i suppose you're changing it after the order is completed .. I seem to have good luck with the symbolic link: cookies.txt -> /dev/null Cookies in memory work, but don't persist across sessions. The "cookies file" is writeable, and upon each browser start up looks empty. David -- Live in a world of your own, but always welcome visitors. From windsor at warthog.com Tue Oct 11 22:43:28 2005 From: windsor at warthog.com (Rob Windsor) Date: Wed, 12 Oct 2005 00:43:28 -0500 Subject: Violation of Security/Privacy... In-Reply-To: <20051012000437.R49277@skink.reptiles.org> References: <76BF2480-E435-4803-878B-F572CB7BE618@jgreely.com> <20051012000437.R49277@skink.reptiles.org> Message-ID: <434CA280.3040907@warthog.com> Gwendolynn ferch Elydyr wrote: >> You could argue that if all that gets passed is hashes, then its >> harmless. However, what if thoses hashes are of files that are >> considered subversive, or key phrases that are related to terrorist >> activities, or any number of 'lawful intercept' reasons. > Actually I don't see why they'd pass anything other than a binary > pass/fail. Either there's a match, against -something-, or there isn't. > In a game context, any match would mean you were cheating. And then there's the way Mythic handles this situation -- any file not matching the "current" hash is updated via a pull from the server. All of this is handled on the client side so the servers only see a pull request for the current file. This has the side-benefit of allowing users to zip/rar/tar/cpio the install area on one computer and extract archive on another computer to shorten the update time on a fresh install. IMO, if you've installed someone's software and agreed to their explicit EULA, you've accepted your fate. Otherwise, uninstall and vote with your money. (WoW isn't the only gui-MUD [er.. "MMORPG"] out there, if you're adamant about wasting time on a computer.) Rob++ -- Internet: windsor at warthog.com __o Life: Rob at Carrollton.Texas.USA.Earth _`\<,_ (_)/ (_) "They couldn't hit an elephant at this distance." -- Major General John Sedgwick From ulf at Alameda.net Wed Oct 12 00:42:47 2005 From: ulf at Alameda.net (Ulf Zimmermann) Date: Wed, 12 Oct 2005 00:42:47 -0700 Subject: Violation of Security/Privacy... In-Reply-To: References: <76BF2480-E435-4803-878B-F572CB7BE618@jgreely.com> <20051012000437.R49277@skink.reptiles.org> Message-ID: <20051012074247.GJ57653@evil.alameda.net> On Tue, Oct 11, 2005 at 09:41:47PM -0700, Alan Horn wrote: > > On Wed, 12 Oct 2005, Gwendolynn ferch Elydyr wrote: > > >>You could argue that if all that gets passed is hashes, then its > >>harmless. However, what if thoses hashes are of files that are considered > >>subversive, or key phrases that are related to terrorist activities, or > >>any number of 'lawful intercept' reasons. > > > >Actually I don't see why they'd pass anything other than a binary > >pass/fail. Either there's a match, against -something-, or there isn't. > > > > All intel is intel... > > >In a game context, any match would mean you were cheating. > > Who was talking about a game context ? :) > > Cheers, > > Al My understanding from the posts they have made on their forums [1] is they are scanning for certain processes, not files. If they find said certain processes, it alerts their hacking department who will then observe the account multiple times before doing any temporary or permantly bannings. [1] http://forums.worldofwarcraft.com/thread.aspx?fn=blizzard-archive&t=33&p=1&tmp=1#post33 -- Regards, Ulf. --------------------------------------------------------------------- Ulf Zimmermann, 1525 Pacific Ave., Alameda, CA-94501, #: 510-865-0204 You can find my resume at: http://seven.Alameda.net/~ulf/resume.html From sigje at sigje.org Wed Oct 12 09:53:57 2005 From: sigje at sigje.org (Jennifer Davis) Date: Wed, 12 Oct 2005 09:53:57 -0700 (PDT) Subject: Annual December Short but Cool meeting - December 15 Message-ID: So far we have a great collection of speakers/topics for the December SBC series.. DragonFly Project - DragonFly BSD SUSE - OpenSUSE OpenSolaris/Solaris x86 XenSource - Enterprise Grade Open Source Virtualization Zimbra Collaboration Suite - Open Source Email/Collaboration Suite If you have any projects you are currently working on, or interesting problems you've solved this last year, and you want a few minutes to talk about it/share please send an email to blw at baylisa.org describing the 5-10 minute talk. Prizes awarded to the best of, determined by the attending audience! Jennifer From rick at linuxmafia.com Wed Oct 12 14:02:15 2005 From: rick at linuxmafia.com (Rick Moen) Date: Wed, 12 Oct 2005 14:02:15 -0700 Subject: Violation of Security/Privacy... In-Reply-To: References: <76BF2480-E435-4803-878B-F572CB7BE618@jgreely.com> Message-ID: <20051012210215.GX8455@linuxmafia.com> Quoting Alan Horn (ahorn at deorth.org): > There *are* privacy issues associated with this. I have absolutely no idea > what Blizzard does with any data they receive, and I haven't seen any > references online to exactly what they're looking for, other than the > EULA. This will sound a _little_ like the "well-poisoning" fallacy, but: The reason I haven't yet bothered looking into the merits of the two articles posted is that I'd already mentally consigned Blizzard and Battle.net to the outer darkness a couple of years ago, because of their (IMVAO) extremely scummy DMCA lawsuit against the open-source bnetd developers: http://lwn.net/Articles/105200/ I'm sure the issues raised are worth looking into, but given limited personal time and resources, sometimes one is best advised to cut to the chase and say "Wild horses wouldn't drag me into a business relationship with these low-lives." Ergo, whether a particular current setup they have is objectionable or not becomes, from that perspective, a bit academic. > Other than voting with ones feet, there is little to be done to bring > accountability here. Irony: The bnetd developers (cited above) _were_ trying to vote with their feet, and used none of what any sensible person would consider any sort of Blizzard-copyright-encumbered property. Yet, they've been vindictively dragged through the courts by Blizzard, anyway. Wild horses, I say -- and I'm glad to let others know, too. From michael at halligan.org Wed Oct 12 20:15:04 2005 From: michael at halligan.org (Michael T. Halligan) Date: Wed, 12 Oct 2005 20:15:04 -0700 Subject: Location.. In-Reply-To: <20051009052431.GK8455@linuxmafia.com> References: <20051009052431.GK8455@linuxmafia.com> Message-ID: <1E4182A0-02F1-411D-B1E8-AE89FD837C46@halligan.org> > Locations.... > > Hold meetings in Cupertino, and the two guys in Burlingame will claim > you'd do better to move north. Hold them in Redwood City, and the two > participants from Morgan Hill will advise going south. One way to > find > out is move and see what happens -- but then you should wait a few > months: Some former regulars will cease attending, but you'll also > slowly pick up people for whom the new location is better. (Any move > introduces "friction" over the shart term: All else being equal, keep > changes of venue/time to a minimum.) > > In short, it's a muddle, and ultimately has to come down to someone's > judgement about which area to serve and what evening or afternoon to > stake out. In an ideal world, you _would_ be able to survey who our > intended constituency are and where they live & work, then pick spots > and regular times that work for them, but I'm not able to envision > offhand any real-world heuristic that approximates that very well. > (If someone else can think of one, though, good!) A middle ground needs to be found in terms of location. By being hosted in Cupertino, BayLisa is excluding quite a bit of people. The bay area is the worst place to drive in. At least in San Francisco we have semi-decent public transportation.. What are the options for Cupertino again, besides asking Steve Jobs for us to catch a ride the next time one of his press conferences coincide with a BayLisa meeting? Honestly, to get to BayLisa is 2.25 hours of driving. I'm sure it's nice and easy for those who live in sunnyvale, so perhaps it should be SunnyvaleLisa instead? -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part URL: From dannyman at toldme.com Wed Oct 12 21:39:03 2005 From: dannyman at toldme.com (Danny Howard) Date: Wed, 12 Oct 2005 21:39:03 -0700 Subject: Location.. In-Reply-To: <1E4182A0-02F1-411D-B1E8-AE89FD837C46@halligan.org> References: <20051009052431.GK8455@linuxmafia.com> <1E4182A0-02F1-411D-B1E8-AE89FD837C46@halligan.org> Message-ID: <20051013043903.GN564@ratchet.nebcorp.com> Eh? Location is up for debate? I vote for "anywhere on the BART network, especially Oakland or Berkeley" Now, unfortunately, that rules out the Silicon Valley, but, uhmmm ... well, anybody in that territory always has do drive everywhere anyway, so driving over to Oakland isn't quite as annoying as it us for those of us who have been spoiled by public transportation having to oil up the engine block and set out South ... San Francisco seems a good compromse ... you can drive up there pretty damn quick off-peak, without bridge tolls! Or, is this just some grumbling I missed while slaving away in the San Ramon valley? I'll return to my previously-scheduled cowering in my little hovel in the faraway exotic land of Walnut Creek, where I keep hearing this weird whirring noise ... servers? No, that's just BART spinning people around the region while they kick back and read books n stuff. Sincere feelings someone who only attends about .75 meetings a year, -danny -- http://dannyman.toldme.com/ From Steve at luminareconsulting.com Wed Oct 12 22:59:14 2005 From: Steve at luminareconsulting.com (Steve Churchill) Date: Wed, 12 Oct 2005 22:59:14 -0700 Subject: Location.. Message-ID: <62CD392670EA4C47B81F8A06C7A22D7B6C14@luminaresbs.LuminareConsulting.LAN> I'm gonna hafta vote for San Francisco. I even work in Sunnyvale. Caltraining back home late is never fun. But a bike ride home... I'd make more meetings :) -steve -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill at wards.net Wed Oct 12 23:07:38 2005 From: bill at wards.net (Bill Ward) Date: Wed, 12 Oct 2005 23:07:38 -0700 Subject: Location.. In-Reply-To: <20051013043903.GN564@ratchet.nebcorp.com> References: <20051009052431.GK8455@linuxmafia.com> <1E4182A0-02F1-411D-B1E8-AE89FD837C46@halligan.org> <20051013043903.GN564@ratchet.nebcorp.com> Message-ID: <3d2fe1780510122307y1270e4f7o93fb4c8e539393d5@mail.gmail.com> On 10/12/05, Danny Howard wrote: > Eh? Location is up for debate? > > I vote for "anywhere on the BART network, especially Oakland or Berkeley" That would be a great idea except I think most people who would attend are in the Silicon Valley region. If near BART is a key criterion, why aren't there a lot of successful user groups in SF and the East Bay? Or are there, and we just don't hear much about them? Public transport is great, and it sucks that we don't have BART 'round the bay. Caltrain's pretty good too. But they don't go to Cupertino. I don't know any big companies willing to host BayLISA that are near rail in the south bay. Oracle in Redwood Shores is close to Caltrain though, and I might be able to arrange for BayLISA to meet there if there was a lot of demand for it, however. -- Help save the San Jose Earthquakes - http://www.soccersiliconvalley.com/ From michael at halligan.org Thu Oct 13 00:31:04 2005 From: michael at halligan.org (Michael T. Halligan) Date: Thu, 13 Oct 2005 00:31:04 -0700 Subject: Location.. In-Reply-To: <3d2fe1780510122307y1270e4f7o93fb4c8e539393d5@mail.gmail.com> References: <20051009052431.GK8455@linuxmafia.com> <1E4182A0-02F1-411D-B1E8-AE89FD837C46@halligan.org> <20051013043903.GN564@ratchet.nebcorp.com> <3d2fe1780510122307y1270e4f7o93fb4c8e539393d5@mail.gmail.com> Message-ID: <51486E96-A9DC-4D65-AF59-62664E524688@halligan.org> > >> Eh? Location is up for debate? >> >> I vote for "anywhere on the BART network, especially Oakland or >> Berkeley" >> > > That would be a great idea except I think most people who would attend > are in the Silicon Valley region. If near BART is a key criterion, > why aren't there a lot of successful user groups in SF and the East > Bay? Or are there, and we just don't hear much about them? Hrm, I wonder. Perhaps the answer to this set of questions is.. There's more to do in SF? I hang out with a good circle of techies rather regularly, but it's more in the form of alpha geeks drinking scotch at good restaurants and arguing over design issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part URL: From michael at halligan.org Thu Oct 13 00:24:08 2005 From: michael at halligan.org (Michael T. Halligan) Date: Thu, 13 Oct 2005 00:24:08 -0700 Subject: Location.. In-Reply-To: <3d2fe1780510122244y7b29dc7bl134a6c8767bb29c@mail.gmail.com> References: <20051009052431.GK8455@linuxmafia.com> <1E4182A0-02F1-411D-B1E8-AE89FD837C46@halligan.org> <20051013043903.GN564@ratchet.nebcorp.com> <3d2fe1780510122244y7b29dc7bl134a6c8767bb29c@mail.gmail.com> Message-ID: Bill, You are correct. Most people in attendance of BayLisa are in the "Silicon Valley" region. I cannot personally speak for them, but my guess is that Systems Administrators in San Francisco, the Peninsula, the North Bay, and the East Bay would love to have a professional organization filled with peers that they could network with. I know I would. Just from a financial point of view, sysadmins are not buying housing in the over-priced silicon valley. The SAGE salary survey is proof that most systems administrators cannot afford the valley anymore. Almost every sysadmin I know who has purchased housing in the past 5 years has. They've all moved to Dublin, Pittsburg, San Ramon, even Santa Rosa. Beyond housing problems, not all companies with technology needs are in the "Silicon Valley" (man I hate that term). A lot of our colleagues work in the further reaches of the east bay at security companies, financial institutes, etc. These are all people with great potential contributions to BayLisa, none of whom have the time to commute to BayLisa. Cupertino is not central to anything but Santa Clara, San Jose, or Sunnyvale. Is the goal to inject some new blood into BayLisa, or to maintain the status quo? If it's to maintain the status quo of a stodgy, decades old group content with sitting around and playing remember when, then by all means, keep the meetings at Apple, but consider changing the name to SouthBayLisa?If the goal, however, is to reinvigorate this as a professional group for networking, information exchange, collaboration, and professional advancement, then consider that the other 3/4 of us will never find Cupertino convenient for anything (except pot shots). (BTW, this rant wasn't directed at Bill, just at the notion that the world revolves around Sunnyvale. It doesn't.) On Oct 12, 2005, at 10:44 PM, Bill Ward wrote: > On 10/12/05, Danny Howard wrote: > Eh? Location is up for debate? > > I vote for "anywhere on the BART network, especially Oakland or > Berkeley" > > That would be a great idea except I think most people who would > attend are in the Silicon Valley region. If near BART is a key > criterion, why aren't there a lot of successful user groups in SF > and the East Bay? Or are there, and we just don't hear much about > them? > > Public transport is great, and it sucks that we don't have BART > 'round the bay. Caltrain's pretty good too. But they don't go to > Cupertino. I don't know any big companies willing to host BayLISA > that are near rail in the south bay. Oracle in Redwood Shores is > close to Caltrain though, and I might be able to arrange for > BayLISA to meet there if there was a lot of demand for it, however. > > -- > Help save the San Jose Earthquakes - http:// > www.soccersiliconvalley.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part URL: From rayw at rayw.net Thu Oct 13 08:42:37 2005 From: rayw at rayw.net (Ray Wong) Date: Thu, 13 Oct 2005 15:42:37 +0000 Subject: Location.. In-Reply-To: References: <20051009052431.GK8455@linuxmafia.com> <1E4182A0-02F1-411D-B1E8-AE89FD837C46@halligan.org> <20051013043903.GN564@ratchet.nebcorp.com> <3d2fe1780510122244y7b29dc7bl134a6c8767bb29c@mail.gmail.com> Message-ID: <20051013154237.GG20010@notfound.rayw.net> Yep, you're both correct. I've laregely fallen out of attendance simply because it's become too far to go. I've made exactly one meeting his year. Mostly I made it because I had to head down to our Colo, which was in San Jose, so was already nearby. While the population center is likely still in the south bay, it's also about the worst area to get into at the end of the day. I recently tried in the course of organizing some south bay sushi mixers, and the flocks of commuters migrating south to their nests create no end of delays. About the worst drive north from the south, I'd say, is the 680 return to the Livermore side of things. Coming south on 680 wasn't great either. >From my own experience having to/from Oakland, WC, Livermore, SJ, SF, Redwood City in the past year or two, I'd say that the drive is worst to the bedroom areas (SJ, Livermore, WC/Concord/Pitts), and best to the center (SF, Oakland, down the peninsula as far as... MV). I'm leaving out a lot of the north bay since I've only driven in and out of Mill Valley so far, which isn't really typical. The only reason Oakland might suck would be 880N between 280 and 237, so many of our Colleagues from east Santa Clara and west San Jose would still be stuck. Oddly, when I was working in the south bay, it turns out that it's really not all that bad to drive up into SF. I think there's a big psychological barrier, but if I could stay on the 280 corridor, it never got worse than slow (as opposed to parking lot on the southbound side), even near SBC Park on gamedays (and for now, at least, the season's over so no prob there). Fortunately for me I was coming out along 85, but even when I had to start near Brokaw/101, it wasn't so bad. Ray On Thu, Oct 13, 2005 at 12:24:08AM -0700, Michael T. Halligan wrote: > Bill, > > You are correct. Most people in attendance of BayLisa are in the > "Silicon Valley" region. I cannot personally speak for them, but > my guess is that Systems Administrators in San Francisco, the > Peninsula, the North Bay, and the East Bay would love to have a > professional organization filled with peers that they could network > with. I know I would. > > Just from a financial point of view, sysadmins are not buying housing > in the over-priced silicon valley. The SAGE salary survey is > proof that most systems administrators cannot afford the valley > anymore. Almost every sysadmin I know who has purchased housing > in the past 5 years has. They've all moved to Dublin, Pittsburg, San > Ramon, even Santa Rosa. > > Beyond housing problems, not all companies with technology needs are > in the "Silicon Valley" (man I hate that term). A lot of our > colleagues work > in the further reaches of the east bay at security companies, > financial institutes, etc. These are all people with great potential > contributions to BayLisa, > none of whom have the time to commute to BayLisa. Cupertino is not > central to anything but Santa Clara, San Jose, or Sunnyvale. > > Is the goal to inject some new blood into BayLisa, or to maintain the > status quo? If it's to maintain the status quo of a stodgy, decades > old group content > with sitting around and playing remember when, then by all means, > keep the meetings at Apple, but consider changing the name to > SouthBayLisa?If the > goal, however, is to reinvigorate this as a professional group for > networking, information exchange, collaboration, and professional > advancement, then consider > that the other 3/4 of us will never find Cupertino convenient for > anything (except pot shots). > > (BTW, this rant wasn't directed at Bill, just at the notion that the > world revolves around Sunnyvale. It doesn't.) > > > On Oct 12, 2005, at 10:44 PM, Bill Ward wrote: > > >On 10/12/05, Danny Howard wrote: > >Eh? Location is up for debate? > > > >I vote for "anywhere on the BART network, especially Oakland or > >Berkeley" > > > >That would be a great idea except I think most people who would > >attend are in the Silicon Valley region. If near BART is a key > >criterion, why aren't there a lot of successful user groups in SF > >and the East Bay? Or are there, and we just don't hear much about > >them? > > > >Public transport is great, and it sucks that we don't have BART > >'round the bay. Caltrain's pretty good too. But they don't go to > >Cupertino. I don't know any big companies willing to host BayLISA > >that are near rail in the south bay. Oracle in Redwood Shores is > >close to Caltrain though, and I might be able to arrange for > >BayLISA to meet there if there was a lot of demand for it, however. > > > >-- > >Help save the San Jose Earthquakes - http:// > >www.soccersiliconvalley.com/ > From rick at linuxmafia.com Thu Oct 13 09:26:20 2005 From: rick at linuxmafia.com (Rick Moen) Date: Thu, 13 Oct 2005 09:26:20 -0700 Subject: Location.. In-Reply-To: <20051013154237.GG20010@notfound.rayw.net> References: <20051009052431.GK8455@linuxmafia.com> <1E4182A0-02F1-411D-B1E8-AE89FD837C46@halligan.org> <20051013043903.GN564@ratchet.nebcorp.com> <3d2fe1780510122244y7b29dc7bl134a6c8767bb29c@mail.gmail.com> <20051013154237.GG20010@notfound.rayw.net> Message-ID: <20051013162620.GJ29287@linuxmafia.com> Quoting Ray Wong (rayw at rayw.net): > Oddly, when I was working in the south bay, it turns out that it's > really not all that bad to drive up into SF. I think there's a big > psychological barrier.... Reminds me of a story. I was living way out in San Francisco's Outer Sunset district near the end of Golden Gate Park, and suggested to some friends that we go to dinner at Joe's of Westlake. They were non-plussed: "But _that's_ in Daly City! It's in _San Mateo County_! Let's go to Pot Sticker in Chinatown." I said, "Er, it's a 5-minute trip down Sunset to Joe's; it's 40 minutes to Pot Sticker. What colour is the sky in this world of yours where Chinatown's closer?" Funny thing about the classic S.F. mindset: It's a rare day when they even think of venturing south of Army^WCesar Chavez. (Present company is assumed to differ.) Anyhow, I'll bet that anyone able to put together and run San Francisco meetings would have no trouble convincing the Board to call them BayLISA meetings, regardless of existing BayLISA events occurring elsewhere -- unless of course this is one of those ever-popular "Here, I have a great idea for a new volunteer initiative for _someone else_ to do", in which case it's been fun as always. From dannyman at toldme.com Thu Oct 13 09:29:25 2005 From: dannyman at toldme.com (Danny Howard) Date: Thu, 13 Oct 2005 09:29:25 -0700 Subject: Location.. In-Reply-To: <51486E96-A9DC-4D65-AF59-62664E524688@halligan.org> References: <20051009052431.GK8455@linuxmafia.com> <1E4182A0-02F1-411D-B1E8-AE89FD837C46@halligan.org> <20051013043903.GN564@ratchet.nebcorp.com> <3d2fe1780510122307y1270e4f7o93fb4c8e539393d5@mail.gmail.com> <51486E96-A9DC-4D65-AF59-62664E524688@halligan.org> Message-ID: <20051013162925.GO564@ratchet.nebcorp.com> On Thu, Oct 13, 2005 at 12:31:04AM -0700, Michael T. Halligan wrote: > >That would be a great idea except I think most people who would > >attend are in the Silicon Valley region. If near BART is a key > >criterion, why aren't there a lot of successful user groups in SF and > >the East Bay? Or are there, and we just don't hear much about them? > > Hrm, I wonder. Perhaps the answer to this set of questions is.. > There's more to do in SF? I hang out with a good circle of techies > rather regularly, but it's more in the form of alpha geeks drinking > scotch at good restaurants and arguing over design issues. Well, my rule of thumb stereotype is that the truly hard-core monkish types, and the early-career "I could learn a lot from a user meeting" types are more likely to live in or very near the Silicon Valley. A lot of the mid-career, married-and-maybe-with-children types live a more work-life balanced humdrum existence farther East, where there are still plenty of jobs, but you can maybe afford your own place, and your kids won't grow up in the warping disneyland of Los PaloAlthertonViewpertinoGatos Hills. My hunch is that in the East bay, you'll see a little less passion, which means less leadership, to form a user group out that way, to compete with similar groups in the Silicon Valley. Though, who knows? Maybe someone ... I suppose I could ping this list ... could see what the interest level is ... I know there's been that occasional SIGbeer in Oakland ... how's the turnout there? But, yeah, if there was a meeting place in San Francisco, preferably not far from the BART, I for one, would be more inclined to show. I think of Silicon Valley as the "campus" and a lot of us Sophores and Juiniors have moved "off campus" to live among the townies. The only problem is this metaphorical college town stretches to 70 miles on a side ... so, if you want to bring the whole tribe together, you can't just use the Appledome, even if it is conveniently located adjacent to the Engineering Quadrangle. -danny -- http://dannyman.toldme.com/ From sigje at sigje.org Thu Oct 13 09:43:06 2005 From: sigje at sigje.org (Jennifer Davis) Date: Thu, 13 Oct 2005 09:43:06 -0700 (PDT) Subject: Modified Title: Location of BayLISA Meetings In-Reply-To: <51486E96-A9DC-4D65-AF59-62664E524688@halligan.org> References: <20051009052431.GK8455@linuxmafia.com> <1E4182A0-02F1-411D-B1E8-AE89FD837C46@halligan.org> <20051013043903.GN564@ratchet.nebcorp.com> <3d2fe1780510122307y1270e4f7o93fb4c8e539393d5@mail.gmail.com> <51486E96-A9DC-4D65-AF59-62664E524688@halligan.org> Message-ID: So some options: -More meetings per month, but sprinkled around the Bay area? Some North, some South, some East, some Mid? I know I couldn't make it to all of these meetings, but if I can coordinate the folks to actually be present at the meetings we can definitely fill the speaking slots! We are getting requests for presenting more and more, and at this point the pipeline is full up to Aprilish (up to Feb confirmed, and multiples offered up to April). -Rotate the one meeting around multiple places across the year? -One night, multiple meetings across the Bay area? Again same stipulation as 1.. We _are_ BayLISA. It's not meant to be South BayLISA. I brought up the point of location because I've heard multiple queries about having BayLISA in different areas, and there is also this notion that at some point in the past we had consistently more people at a more northern location. It sounds like we have a strong base of South BayLISA attendees that are consistent. Do we have a possible attendee base in other areas? So do I have some volunteers who want to be the meeting hosts/coordinators in some alternate areas? I'll talk to Bill separately, as having a Peninsula BayLISA meeting (even if it's just a one off) would be a good data point. We don't want to detract from any area.. quality, people, whatever. Right now we get a good number in the audience and I want to maintain that. We are still figuring out good food quantities, but we do the sodas, and we know what to expect month to month somewhat. Jennifer Jennifer From rick at linuxmafia.com Thu Oct 13 10:23:55 2005 From: rick at linuxmafia.com (Rick Moen) Date: Thu, 13 Oct 2005 10:23:55 -0700 Subject: Modified Title: Location of BayLISA Meetings In-Reply-To: References: <20051009052431.GK8455@linuxmafia.com> <1E4182A0-02F1-411D-B1E8-AE89FD837C46@halligan.org> <20051013043903.GN564@ratchet.nebcorp.com> <3d2fe1780510122307y1270e4f7o93fb4c8e539393d5@mail.gmail.com> <51486E96-A9DC-4D65-AF59-62664E524688@halligan.org> Message-ID: <20051013172355.GM29287@linuxmafia.com> Quoting Jennifer Davis (sigje at sigje.org): > -Rotate the one meeting around multiple places across the year? IMVAO, one of the worst things you can do with a user group is make its regular place(s)/time(s) become irregular, any more than you have to. I've seen a number of groups destroy themselves that way. > It sounds like we have a strong base of South BayLISA attendees > that are consistent. Do we have a possible attendee base in other areas? One caution: Granting existence of some overlap between the discuss-online crowd and the regularly-show-up-and-participate crowd, that correlation tends in my experience to be weak. So, it's easy to overinterpret online expressions of interest; the armchair and the participant may prove reluctant to part. From michael at halligan.org Thu Oct 13 10:29:23 2005 From: michael at halligan.org (Michael T. Halligan) Date: Thu, 13 Oct 2005 10:29:23 -0700 Subject: Location.. In-Reply-To: <20051013162620.GJ29287@linuxmafia.com> References: <20051009052431.GK8455@linuxmafia.com> <1E4182A0-02F1-411D-B1E8-AE89FD837C46@halligan.org> <20051013043903.GN564@ratchet.nebcorp.com> <3d2fe1780510122244y7b29dc7bl134a6c8767bb29c@mail.gmail.com> <20051013154237.GG20010@notfound.rayw.net> <20051013162620.GJ29287@linuxmafia.com> Message-ID: On Oct 13, 2005, at 9:26 AM, Rick Moen wrote: > Quoting Ray Wong (rayw at rayw.net): > > >> Oddly, when I was working in the south bay, it turns out that it's >> really not all that bad to drive up into SF. I think there's a big >> psychological barrier.... >> > > Reminds me of a story. I was living way out in San Francisco's Outer > Sunset district near the end of Golden Gate Park, and suggested to > some > friends that we go to dinner at Joe's of Westlake. They were > non-plussed: "But _that's_ in Daly City! It's in _San Mateo County_! > Let's go to Pot Sticker in Chinatown." > > I said, "Er, it's a 5-minute trip down Sunset to Joe's; it's 40 > minutes > to Pot Sticker. What colour is the sky in this world of yours where > Chinatown's closer?" > > Funny thing about the classic S.F. mindset: It's a rare day when they > even think of venturing south of Army^WCesar Chavez. (Present company > is assumed to differ.) > > Anyhow, I'll bet that anyone able to put together and run San > Francisco > meetings would have no trouble convincing the Board to call them > BayLISA > meetings, regardless of existing BayLISA events occurring elsewhere -- > unless of course this is one of those ever-popular "Here, I have a > great > idea for a new volunteer initiative for _someone else_ to do", in > which > case it's been fun as always. South of Army? I don't know about that.. South of 30th, definitely. There's a good chinese place a block away from Army, the Jade Teahouse. That block also has the best salvadorean restaurants in city, and the city's only Jamaican/Italian place, Emma's Spaghetti shack. Going beyond 30th, however, became sad once the only good restaurant in the excelsior, Bistro E Europe, went out of business. There is still, however, a great liquor store at Mission & Silver, Mike's Liquors, which is the only place I know of who will deliver a keg of guinness on 3 hour's notice. There are also three great bars (the Knockout [formerly the Odeon], Argus, and El Rio). We also shouldn't forget Mitchell's Ice cream, or the dozen great restaurants up on Cortland in Bernal.. ALl of them south of Cesar Chavez (but not too far south!). And for slumming it, the best burrito shop is a block south of Army on Bayshore in the warehouse district, Taqueria el Potrillo. The sunset is an odd comparsion, actually. People in the sunset might as well be in sunnyvale, it's definitely a bedroom community... In the Sunset, SUVS, Bad Drivers, and stores who roll up their sidewalks at 7pm abound -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part URL: From brent at hplbct.hpl.hp.com Thu Oct 13 10:47:31 2005 From: brent at hplbct.hpl.hp.com (Brent Thompson) Date: Thu, 13 Oct 2005 10:47:31 -0700 Subject: Location.. In-Reply-To: Your message of "Thu, 13 Oct 2005 00:24:08 PDT." Message-ID: <200510131747.KAA16908@kanha.hpl.hp.com> > Is the goal to inject some new blood into BayLisa, or to maintain the > status quo? If it's to maintain the status quo of a stodgy, decades > old group content > with sitting around and playing remember when, then by all means, > keep the meetings at Apple, but consider changing the name to > SouthBayLisa?If the > goal, however, is to reinvigorate this as a professional group for > networking, information exchange, collaboration, and professional > advancement, then consider > that the other 3/4 of us will never find Cupertino convenient for > anything (except pot shots). Previously: > to get to BayLisa [from SF] is 2.25 hours of driving If Cupertino is too far to go for residents or workers near SF and northwards, one imagines SF is too far to go for residents or workers near Cupertino and southwards, and this latter set presumably constitutes the core attendance at BayLisa mtgs. So, it seems there is a reasonable chance most of the core attendance of BayLisa meetings would cease attending if meetings were moved to SF, or even significantly closer to SF. And if so, regardless whether 'stodgy' is applicable or not, effectively BayLisa would have done "out with the old blood", and would survive only if "new blood" -- a new core of attendance -- formed. This being a separate constituency, why not just form a new group to cater to that constituency: SFLisa or NorthBayLisa or even EastBayLisa? Even a unilateral decision to split by some small number of persons (as opposed to being via vote or consensus of entire group) is not necessarily a deathknell for the old group, nor cause for permanent disaffection between the groups. Of course, if normal meeting attendance is already near the bottom limit of sustainability (a condition I don't know about), then maybe splitting and its attendant reduction of attendance at each of the split parts would be a deathknell. If so, the matters of splitting and moving are serious and deserve careful analysis, not just the whim of a few writers. --- Brent From extasia at extasia.org Thu Oct 13 10:49:23 2005 From: extasia at extasia.org (David Alban) Date: Thu, 13 Oct 2005 10:49:23 -0700 Subject: [baylisa] Re: Location.. In-Reply-To: <20051013162925.GO564@ratchet.nebcorp.com> References: <20051009052431.GK8455@linuxmafia.com> <1E4182A0-02F1-411D-B1E8-AE89FD837C46@halligan.org> <20051013043903.GN564@ratchet.nebcorp.com> <3d2fe1780510122307y1270e4f7o93fb4c8e539393d5@mail.gmail.com> <51486E96-A9DC-4D65-AF59-62664E524688@halligan.org> <20051013162925.GO564@ratchet.nebcorp.com> Message-ID: <4c714a9c0510131049wc116be7o34df91fc5bc0ba7c@mail.gmail.com> On 10/13/05, Danny Howard wrote: > I know there's been that > occasional SIGbeer in Oakland ... how's the turnout there? Turnout hasn't been terribly encouraging in Berkeley or Oakland. Best turnout has been in SF.[1] [1] The current sbw instigator is admittedly SF-centric. Most events have been in the city. -- Live in a world of your own, but always welcome visitors. From dannyman at toldme.com Thu Oct 13 11:33:51 2005 From: dannyman at toldme.com (Danny Howard) Date: Thu, 13 Oct 2005 11:33:51 -0700 Subject: Interest in "BayLISA North" Message-ID: <20051013183351.GC18563@ratchet.nebcorp.com> Hello, I have volunteered to help coordinate our hypothetical meetings in the Berkeley-Oakland-San Francisco area. I have been assured that if we can find a venue, and someone to manage the venue and emcee the speaker, then speakers can be had ... so, if we can get a venue, and we can get people to show up, BayLISA and I are willing to bring you meetings. (It sounds like these meetings would be held in addition to South Bay meetings.) In order to gauge interest and feasibility, please write me if you answer YES to any of these questions: - Would you be likely to attend BayLISA meetings in San Francisco? - Would you be likely to attend BayLISA meetings in Oakland-Berkeley? - Do you know of an appropriate venue in either of these places? Required: * Largeish conference room or small auditorium Preferred: * Internet access * Proximity to BART or other public transportation * Parking * Proximity to nice restaurant / bar ===================================================================== == Hosting a venue is a great opportunity for your employer to == == build recognition and goodwill among technical people. == ===================================================================== Thanks, -danny -- http://dannyman.toldme.com/ From sigje at sigje.org Thu Oct 13 11:35:17 2005 From: sigje at sigje.org (Jennifer Davis) Date: Thu, 13 Oct 2005 11:35:17 -0700 (PDT) Subject: Location.. In-Reply-To: <200510131747.KAA16908@kanha.hpl.hp.com> References: <200510131747.KAA16908@kanha.hpl.hp.com> Message-ID: > If Cupertino is too far to go for residents or workers near SF and > northwards, one imagines SF is too far to go for residents or workers near > Cupertino and southwards, and this latter set presumably constitutes the > core attendance at BayLisa mtgs. Not true. Core attendance of current BayLISA meetings is from South Bay because the meetings are in south bay. We've had more or less depending on where the meetings are held. > And if so, regardless whether 'stodgy' is applicable or not, effectively > BayLisa would have done "out with the old blood", and would survive only if > "new blood" -- a new core of attendance -- formed. This being a separate > constituency, why not just form a new group to cater to that constituency: > SFLisa or NorthBayLisa or even EastBayLisa? Let's _not_ form additional groups. Instead, let's find out where there are enough people in the different areas that are willing to be MCs in those locations.. make sure the meeting runs smoothly because the people that do this in Cupertino can't do this everywhere. What we can do is leverage our speaking contacts, involvement with industry, and coordinate excellent speaking opportunities. We can make sure that all the little pieces like "confirm room", "confirm speaker", "confirm speaker has address/directions/date", "confirm possible attendees know date/location/topic" all happen. We don't want to splinter the group, we want to make sure that our target group is getting needs met. There is no need to splinter the group off. We just need people in the areas that feel that there is a need to actually step up and volunteer to have some responsibility. Jennifer From sigje at sigje.org Thu Oct 13 11:58:04 2005 From: sigje at sigje.org (Jennifer Davis) Date: Thu, 13 Oct 2005 11:58:04 -0700 (PDT) Subject: BayLISA - what is it and where are we going.. Message-ID: BayLISA is not just a user group. It's not just about meeting up once a month, although that is one of the key items that we do. It's partly a place we can help each other improve our technical skills, network, and meet the needs of our profession. It's what each individual makes of it. We've got some exciting news to announce soon, and we have more technical events planned for the next year. One of my goals is helping shape this organization into a professional association that vendors/open source projects/other groups recognize, and respect. You want to get involved, _get involved_. There aren't barriers to entry. In fact elections are coming up _next month_. Join BayLISA, send blw at baylisa.org your candidate statement (so we can put it up on the website), announce your candidacy at the October meeting, and vote in November. There are 5 seats up for election this year. What do you get out of being on the Board? Jim Hickstein and I were discussing this recently. After you have been on the Board for 2 years (the term of a board member), you will develop critical skills in managing, developing an organization. As an MC (doesn't require being on the Board), you will become a better public speaker, and more outgoing. People skills for geeks! :) This isn't just a resume builder. There are people that care passionately about the organization, and its direction. We have different ideas about what does and doesn't work, but that just helps to keep us doing our best. Be a part of this growth, and development. Any BayLISA member is _welcome_ to every Board meeting. Don't want to run for Board? here are some other options for getting involved - conference committee - event coordination - speaker solicitation - sponsor solicitation - MC at events - marketing/logo redesign - "article" writer, how tos/reviews or products/book reviews that's just some of the options. Jennifer From sigje at sigje.org Thu Oct 13 12:05:43 2005 From: sigje at sigje.org (Jennifer Davis) Date: Thu, 13 Oct 2005 12:05:43 -0700 (PDT) Subject: BayLISA in SF In-Reply-To: <20051013183351.GC18563@ratchet.nebcorp.com> References: <20051013183351.GC18563@ratchet.nebcorp.com> Message-ID: > - Do you know of an appropriate venue in either of these places? > Required: > * Largeish conference room or small auditorium > Preferred: > * Internet access > * Proximity to BART or other public transportation > * Parking > * Proximity to nice restaurant / bar I've sent a separate note to Danny, but I have a possible venue in SF. Going to arrange dates, set up speaker line up, and give more details soon. It's got everything we need for a SF meeting, need to confirm wireless/internet availability, but it is good for public transport. If this doesn't work because of lack of interest .. :) Well we tried. Jennifer From rick at linuxmafia.com Thu Oct 13 12:25:44 2005 From: rick at linuxmafia.com (Rick Moen) Date: Thu, 13 Oct 2005 12:25:44 -0700 Subject: Location.. In-Reply-To: References: <20051009052431.GK8455@linuxmafia.com> <1E4182A0-02F1-411D-B1E8-AE89FD837C46@halligan.org> <20051013043903.GN564@ratchet.nebcorp.com> <3d2fe1780510122244y7b29dc7bl134a6c8767bb29c@mail.gmail.com> <20051013154237.GG20010@notfound.rayw.net> <20051013162620.GJ29287@linuxmafia.com> Message-ID: <20051013192544.GP29287@linuxmafia.com> Quoting Michael T. Halligan (michael at halligan.org): > The sunset is an odd comparsion, actually. People in the sunset might > as well be in sunnyvale, it's definitely a bedroom community... In the > Sunset, SUVS, Bad Drivers, and stores who roll up their sidewalks at > 7pm abound. Not to mention having all the exterior horizontal surfaces of your cars rust, because the morning dew has ocean salt in it. Shortly after the time of my anecdote, when I moved from the Outer Sunset to San Mateo, my commute to 345 California Street, S.F. went from 45 minutes to 20. But ragging on the Sunset District, however well deserved, is missing my point: The attitude I cited is widespread among City denizens. I heard the same all the time from locals when I lived at the CoffeeNet[1] building in SOMA -- the fabled "-rwxr--r-- Harrison" hangout of yore -- when I suggested (e.g.) getting a burger at Seven Mile House. It was: "But that's in Daly City. Let's go to Mel's on Lombard." [1] Mirror: http://linuxmafia.com/coffeenet/ Operation is now reconstituted in Guadalajara: http://www.linuxcabal.com/ From pmm at igtc.com Thu Oct 13 13:45:57 2005 From: pmm at igtc.com (Paul M. Moriarty) Date: Thu, 13 Oct 2005 13:45:57 -0700 Subject: Location.. Message-ID: <20051013204557.GB11417@igtc.igtc.com> A more northerly LISA group was tried once before in the past. Hal Pomeranz tried setting something up in Berkeley/Oakland IIRC. It might be wise to drop him a note and finds out what he believes were the impediments to the success of that attempt before investing lots of time and effort potentially reinventing the (non-working) wheel. - Paul - From extasia at extasia.org Thu Oct 13 14:06:22 2005 From: extasia at extasia.org (David Alban) Date: Thu, 13 Oct 2005 14:06:22 -0700 Subject: [baylisa] Re: Location.. In-Reply-To: <20051013204557.GB11417@igtc.igtc.com> References: <20051013204557.GB11417@igtc.igtc.com> Message-ID: <4c714a9c0510131406w20364c68sbc717d56a21da341@mail.gmail.com> One of the things dc-sage tried, with some success, was not to splinter off any new groups, but to have every other meeting on the Virginia side of the D.C. beltway, and every other meeting on the Maryland side. Most folks were able to go to half the meetings. I imagine this won't appeal very much to people who currently have easy access to meetings, and will appeal to those who don't. But it seems like an all-or-none scenario now. David -- Live in a world of your own, but always welcome visitors. From dannyman at toldme.com Thu Oct 13 14:48:50 2005 From: dannyman at toldme.com (Danny Howard) Date: Thu, 13 Oct 2005 14:48:50 -0700 Subject: [baylisa] Re: Location.. In-Reply-To: <4c714a9c0510131406w20364c68sbc717d56a21da341@mail.gmail.com> References: <20051013204557.GB11417@igtc.igtc.com> <4c714a9c0510131406w20364c68sbc717d56a21da341@mail.gmail.com> Message-ID: <20051013214849.GE18563@ratchet.nebcorp.com> On Thu, Oct 13, 2005 at 02:06:22PM -0700, David Alban wrote: > One of the things dc-sage tried, with some success, was not to > splinter off any new groups, but to have every other meeting on the > Virginia side of the D.C. beltway, and every other meeting on the > Maryland side. Most folks were able to go to half the meetings. > > I imagine this won't appeal very much to people who currently have > easy access to meetings, and will appeal to those who don't. But it > seems like an all-or-none scenario now. My reading is that the current ambition is not to splinter so much as run 2x as many meetings, splitting between North and South, since we have quite a few speakers in the pipeline. :) So, not splintering, not splitting, but "upgrading" capacity and geographic distribution ... if you get used to attending meetings up north you might feel all the more comfortable if you hear of an appealing meeting in the South, and vice versa. -danny -- http://dannyman.toldme.com/ From lanning at lanning.cc Thu Oct 13 14:16:52 2005 From: lanning at lanning.cc (Robert Hajime Lanning) Date: Thu, 13 Oct 2005 14:16:52 -0700 (PDT) Subject: Location.. In-Reply-To: References: <200510131747.KAA16908@kanha.hpl.hp.com> Message-ID: <58837.192.168.128.102.1129238212.squirrel@ssl.monsoonwind.com> > Not true. Core attendance of current BayLISA meetings is from > South Bay because the meetings are in south bay. We've had more > or less depending on where the meetings are held. >From someone who sporadicly attends the meetings... I may live in San Jose (680/101 & McKee), but I work in Scotts Valley. So, unless the meetings are on weekends, there is no way I will be attending anything north of Mountain View/Milpitas. I have been able to get co-workers to attend sometimes, when the talk is something they are interested in. I really think the only answer is regular regional meetings. -- And, did Guloka think the Ulus were too ugly to save? -Centauri From pozar at lns.com Fri Oct 14 04:25:08 2005 From: pozar at lns.com (Tim Pozar) Date: Fri, 14 Oct 2005 04:25:08 -0700 Subject: Location.. In-Reply-To: <58837.192.168.128.102.1129238212.squirrel@ssl.monsoonwind.com> References: <200510131747.KAA16908@kanha.hpl.hp.com> <58837.192.168.128.102.1129238212.squirrel@ssl.monsoonwind.com> Message-ID: <434F9594.3040306@lns.com> A quick $0.02... When I ran the Bay Area Wireless User Group meetings, we tried to scatter them around the Bay as much as possible. Some of this was driven on what venues we could get such as what vendors would accommodate us. We found that we would get about 3 times the attendance for South Bay meetings than north. Much to my chagrin as I live in San Francisco. Tim -- 1978 45th Ave / San Francisco CA 94116 / USA // POTS: +1 415 665 3790 GPG Fingerprint: 4821 CFDA 06E7 49F3 BF05 3F02 11E3 390F 8338 5B04 Life is playful - Ben Olizar -------------- next part -------------- A non-text attachment was scrubbed... Name: pozar.vcf Type: text/x-vcard Size: 209 bytes Desc: not available URL: From rayw at rayw.net Fri Oct 14 08:51:01 2005 From: rayw at rayw.net (Ray Wong) Date: Fri, 14 Oct 2005 15:51:01 +0000 Subject: Modified Title: Location of BayLISA Meetings In-Reply-To: References: <20051009052431.GK8455@linuxmafia.com> <1E4182A0-02F1-411D-B1E8-AE89FD837C46@halligan.org> <20051013043903.GN564@ratchet.nebcorp.com> <3d2fe1780510122307y1270e4f7o93fb4c8e539393d5@mail.gmail.com> <51486E96-A9DC-4D65-AF59-62664E524688@halligan.org> Message-ID: <20051014155101.GH20010@notfound.rayw.net> On Thu, Oct 13, 2005 at 09:43:06AM -0700, Jennifer Davis wrote: > > So some options: > > -More meetings per month, but sprinkled around the Bay area? Some North, > some South, some East, some Mid? I know I couldn't make it to all of > these meetings, but if I can coordinate the folks to actually be present > at the meetings we can definitely fill the speaking slots! We are getting > requests for presenting more and more, and at this point the pipeline is > full up to Aprilish (up to Feb confirmed, and multiples offered up to > April). > -Rotate the one meeting around multiple places across the year? > -One night, multiple meetings across the Bay area? Again same stipulation > as 1.. A thought: Do all meetings/speakers hold equal interests for all members? Are members more likely to be attending based on something being directly related to the type of problems they face, or being outside the usual work mode? I'd be perfectly happy to leave a regular meeting every month as is to avoid confusing or annoying the regulars, and perhaps trying out some other spot for additionals. If we can get a decent crowd going, even if it's not as large as the south bay folk, we can at least have a better sample to ask questions of and refine answers for. As to timing, the same night ensures the same sample (i.e. eliminates scheduling external conflicts among those who "might" go), but does force people to choose which speaker, if they can go at all that night. > We _are_ BayLISA. It's not meant to be South BayLISA. I brought up the > point of location because I've heard multiple queries about having > BayLISA in different areas, and there is also this notion that at some > point in the past we had consistently more people at a more northern > location. It sounds like we have a strong base of South BayLISA attendees > that are consistent. Do we have a possible attendee base in other areas? I'd think we do, though as we know it can be difficult to build that into an actual attendee base. > So do I have some volunteers who want to be the meeting hosts/coordinators > in some alternate areas? I'll talk to Bill separately, as having a > Peninsula BayLISA meeting (even if it's just a one off) would be a good > data point. I personally need to see what resources I can help bring to bear for the SF area. Currently on a primary oncall rotation with lots of evening traffic so will have to see if I can support any meeting I commit to around performing those oncall duties. If I arrange anything outside my building, I'd need not only power and internet but a room where I could yell intot he phone without distracting anyone :) At work, well, I'll have to see WHAT I can arrange there. > We don't want to detract from any area.. quality, people, whatever. > Right now we get a good number in the audience and I want to maintain > that. We are still figuring out good food quantities, but we do the > sodas, and we know what to expect month to month somewhat. Agreed. I miss being able to go to the South Bay events, but they were fine the last time I was able to... no need to rm the binaries with the tmpfiles. From dan_bethe at yahoo.com Fri Oct 14 11:45:14 2005 From: dan_bethe at yahoo.com (Dan Bethe) Date: Fri, 14 Oct 2005 11:45:14 -0700 (PDT) Subject: basic cacti help Message-ID: <20051014184514.35581.qmail@web51702.mail.yahoo.com> Hi all. I know that some of you here have cacti experience (cacti.net, the rrdtool-based successor to mrtg) because I've found some of you on the open source software support sites! That's really great, but I am afraid I don't need serious consulting at this point. If anyone has a firm grasp on cacti basics and would like to help out the community, I'd love to chat in #cacti on irc.freenode.net and maybe we can help each other out on some things. Thanks! __________________________________ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com From jesse at boldandbusted.com Sat Oct 15 16:11:40 2005 From: jesse at boldandbusted.com (Jesse Adelman) Date: Sat, 15 Oct 2005 16:11:40 -0700 (PDT) Subject: basic cacti help In-Reply-To: <20051014184514.35581.qmail@web51702.mail.yahoo.com> Message-ID: <20051015231140.32362.qmail@web60721.mail.yahoo.com> I'm also available for not-so-serious, yet, interestingly, paid Cacti setup and configuration consulting. ;) Of course, all of the "basic" cacti help you need can be found in the Documentation section on cacti.net, and more help is available in the Cacti forums. Cheers, Jesse Adelman http://resume.boldandbusted.com/ --- Dan Bethe wrote: > Hi all. I know that some of you here have cacti experience > (cacti.net, the > rrdtool-based successor to mrtg) because I've found some of you on > the open > source software support sites! That's really great, but I am afraid > I don't > need serious consulting at this point. If anyone has a firm grasp on > cacti > basics and would like to help out the community, I'd love to chat in > #cacti on > irc.freenode.net and maybe we can help each other out on some things. > Thanks! > > > > > __________________________________ > Yahoo! Mail - PC Magazine Editors' Choice 2005 > http://mail.yahoo.com > -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Jesse Adelman http://www.boldandbusted.com/ -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ From sigje at sigje.org Sun Oct 16 20:48:08 2005 From: sigje at sigje.org (Jennifer Davis) Date: Sun, 16 Oct 2005 20:48:08 -0700 (PDT) Subject: Reminder - October 20, 2005 - Brent Chapman - General Meeting Message-ID: Just a reminder that this Thursday is the monthly meeting of BayLISA with Brent Chapman speaking on Incident Command for IT. For those people who don't know, he is also one of the co-authors of "Building Internet Firewalls". Even better is that Elizabeth Zwicky will be MC-ing the meeting, one of the other co-authors of this great reference book. Maybe we can convince them to come out with a new edition! USENIX is sponsoring the meeting, so we will be having pizza! Please do RSVP (if you haven't already) so we have an idea of how many people are coming. Also those people who have received books, please do send me a review! If you need a bit of guidance, check out Mark Langston's helpful "Writing a Book Review for BayLISA" http://www.baylisa.org/library/bookReview.shtml It doesn't have to be very long, just give us your honest thoughts. Don't forget to register for BaySUG. It is limited in number! http://www.usenix.org/events/baysug05/ Remember, if you want to run for Board, please do send a mail to blw at baylisa.org with a candidate statement! Jennifer From sigje at sigje.org Mon Oct 17 11:50:31 2005 From: sigje at sigje.org (Jennifer Davis) Date: Mon, 17 Oct 2005 11:50:31 -0700 (PDT) Subject: Advance Notice - November General Meeting - November 17, 2005 Message-ID: October's meeting is this week, but I wanted to give you advance notice about next month's meeting. Jennifer Granick, Executive Director for the Stanford Law School Center for Internet & Society, most recently well known for her defense of researcher Michael Lynn's presentation at this year's Black Hat conference on research he did at ISS on Cisco systems, will be presenting on legal concerns we face in the profession today. (You can read about the insider's view of Ciscogate written by Jennifer Granick herself on Wired: http://www.wired.com/news/technology/0,1282,68435,00.html?tw=wn_tophead_8 ) Additionally, Bob Camors will be speaking as a "Guru in Session" speaker on "Email Regulations and Solutions for Compliance". Mirapoint is sponsoring this meeting, so we will be having pizza! Afterwards we will be adjourning over to BJs and Mirapoint will be covering drinks and snacks (I'm not sure what the exact details will be on number of drinks, etc, but it will be resolved by Nov 17.) Finally, the November meeting is our annual elections meeting! So show up early to vote (if you are a member). 7:00, so we can start the meeting on time at 7:30. Jennifer From michael at halligan.org Mon Oct 17 12:38:41 2005 From: michael at halligan.org (Michael T. Halligan) Date: Mon, 17 Oct 2005 12:38:41 -0700 Subject: Wiring Contractors? Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Does anybody know of a good wiring contractor they can recommend? I'm about to open a new cage @ my datacenter, and am looking for a group that does decent work at a fair rate. Somebody reliable, who can work in SF without too many time constraints. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) iD8DBQFDU/3FwjCqooJyNAMRAteTAJ0dSrCNFvXHIBrD2wwnJXAUVKbBwQCdGzUy MQJUO+w9kDELQZM1e4+K4SQ= =wXSp -----END PGP SIGNATURE----- From dsmith at FinancialEngines.com Mon Oct 17 12:53:28 2005 From: dsmith at FinancialEngines.com (David Smith) Date: Mon, 17 Oct 2005 12:53:28 -0700 Subject: Wiring Contractors? Message-ID: <17D60EFECB2C044097D6C4336DD8ED753F0508@INF-EXCH-SJC-01.fngn.com> Without a doubt, TD Communications -- These guys are simply one of the best out there. Tony is the Owner. http://www.tdcommunications.com/ Cheers, Dave ---- David Smith Voice: 650-565-7750 Fax: 650-565-4905 432F 465C 5866 FC46 5B19 EAC6 AED3 E032 F49B 62CF -----Original Message----- From: owner-baylisa at baylisa.org [mailto:owner-baylisa at baylisa.org] On Behalf Of Michael T. Halligan Sent: Monday, October 17, 2005 12:39 PM To: baylisa at baylisa.org Subject: Wiring Contractors? -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Does anybody know of a good wiring contractor they can recommend? I'm about to open a new cage @ my datacenter, and am looking for a group that does decent work at a fair rate. Somebody reliable, who can work in SF without too many time constraints. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) iD8DBQFDU/3FwjCqooJyNAMRAteTAJ0dSrCNFvXHIBrD2wwnJXAUVKbBwQCdGzUy MQJUO+w9kDELQZM1e4+K4SQ= =wXSp -----END PGP SIGNATURE----- From vraptor at employees.org Mon Oct 17 13:51:22 2005 From: vraptor at employees.org (vraptor at employees.org) Date: Mon, 17 Oct 2005 13:51:22 -0700 (PDT) Subject: Tech jobs in the midwest? In-Reply-To: <20051005184826.GS54033@bunrab.catwhisker.org> References: <43440B82.50603@halligan.org> <20051005174746.GO54033@bunrab.catwhisker.org> <43441A2D.1020005@halligan.org> <20051005184826.GS54033@bunrab.catwhisker.org> Message-ID: <20051017133518.G87605@willers.employees.org> On Wed, 5 Oct 2005, David Wolfskill wrote: >On Wed, Oct 05, 2005 at 11:23:41AM -0700, Michael T. Halligan wrote: >>> Disclosure: I count myself as both "reasonably talented" and >>> "significantly underemployed." >> >> I just don't see it. Maybe two or three years ago it was a bit tight, >> but the past year or so has >> been great. > > I'm happy for you. Your experience is apparently rather different from > mine. Perhaps getting out of the Bay Area would help? Frankly, it's amazing to me that talented people are still having employment difficulties, given the knuckle draggers I see passing as "Senior" in many East Coast positions. >> Good people are good people, they just need to find a >> way to connect with good job leads, which isn't always easy. > > Indeed. And perhaps BayLISA can help with this...? > >> We need an anonymous, un-logged, un-archived mailing list to share >> opinions about some of these job postings & companies, because I've >> seen some really frightening ones get posted. This is what networking with your peers is for. My personal observations, given my own trials with getting employed post- bust, as well as observing people I know, suggests to me that folks who are still having issues getting employed seem to have trouble breaking through three walls: a) Lack of confidence due to long-term un-/under-employment-- depression breeds lack of confidence; lack of confidence is evident to the people you interview with, even if you think you are hiding it. Likewise lack of enthusiasm for a potential position (see b). b) Filtering themselves out due to fear of yet another "no" or non-response--people get rejected often enough, they look for rationalizations not to even apply so as to avoid another "no". (see a) c) Failure to network (social, not IT :-); this is an art that few IT folks are good at--and the ones who are generally are successful consultants and make more money than the rest of us :-). [on talking about crappy companies and bogus job listings] > And without an archive, a given subscriber will only see the messages > that are sent after the subscription takes effect. > > I'm becoming less certain that a "mailing list" is wanted for this > application, vs. (e.g.) some Web-based forum. > > Folks who are sufficiently interested in implementing something like > this should start communicating with one another. There's a mailing > list, services-tf at baylisa.org, that is intended for folks implementing > services for BayLISA. Perhaps getting F*ckedCompany to set up a separate forum for this type of discussion? The most ironically amusing thing I see is my continual bombardment from recruiting co's in India b/c the word "India" shows up in my resume. I keep asking about relocation but I never get replies. =Nadine= From vraptor at employees.org Mon Oct 17 13:55:54 2005 From: vraptor at employees.org (vraptor at employees.org) Date: Mon, 17 Oct 2005 13:55:54 -0700 (PDT) Subject: Tech jobs in the midwest? In-Reply-To: <20051005182408.GA1836@puppy.inorganic.org> References: <43440B82.50603@halligan.org> <20051005174746.GO54033@bunrab.catwhisker.org> <20051005182408.GA1836@puppy.inorganic.org> Message-ID: <20051017135454.K87605@willers.employees.org> On Wed, 5 Oct 2005, Roy S. Rapoport wrote: > On Wed, Oct 05, 2005 at 10:47:46AM -0700, David Wolfskill wrote: >> reasonably talented folks, I would also observe that none of the folks >> I have heard saying positive things about the economy were either >> significantly underemployed or had been unemployed for a significant >> amount of time. > > The economy's doing pretty well. > > I spent two five month stints looking for jobs in the last four years. > Does that count? I'm still getting hits on a monster resume that's been stale since last Nov. I was out for almost 2yr before coming to the right coast. =Nadine= From ulf at Alameda.net Mon Oct 17 14:18:35 2005 From: ulf at Alameda.net (Ulf Zimmermann) Date: Mon, 17 Oct 2005 14:18:35 -0700 Subject: Wiring Contractors? In-Reply-To: References: Message-ID: <20051017211835.GM57653@evil.alameda.net> On Mon, Oct 17, 2005 at 12:38:41PM -0700, Michael T. Halligan wrote: > Does anybody know of a good wiring contractor they can recommend? I'm > about to open a new cage @ my datacenter, and am > looking for a group that does decent work at a fair rate. Somebody > reliable, who can work in SF without too many time constraints. We use Valley Communications, they have done several good jobs for us. You can see some of their work around this picture: http://www.alameda.net/gallery/colo/colo_2005_07_19_014 This is from our colo rebuild, expanding cage, they ran the wire across our active production machines, with no interruptions. -- Regards, Ulf. --------------------------------------------------------------------- Ulf Zimmermann, 1525 Pacific Ave., Alameda, CA-94501, #: 510-865-0204 You can find my resume at: http://seven.Alameda.net/~ulf/resume.html From vraptor at employees.org Mon Oct 17 14:31:10 2005 From: vraptor at employees.org (vraptor at employees.org) Date: Mon, 17 Oct 2005 14:31:10 -0700 (PDT) Subject: Thoughts.. In-Reply-To: References: Message-ID: <20051017140434.D87605@willers.employees.org> On Fri, 7 Oct 2005, Jennifer Davis wrote: > So if given the thought "Critical Problems of our Industry", what springs to > mind? What aspects of your job do you think "they" could do better, (where > they is the vendors or open source ventures that tackle some of the problems)? > What things do you bang your head on the table about, or find yourself griping > about yet again at the local coffee shop? Scalability, particularly in the area of storage mgmt. I was recently asked a question in a technical interview which reiterated to me again the issues we are having with storage--both in large orgs and small. Basically--it was the usenet problem (many millions of small files), but with real files with real data, and it had to be migrated to another file system--with no downtime. A find on the filesystem took three weeks to complete. (I was asked to explain why a find would take three weeks and to quickly "talk through" the various ways people might try to transfer the data and whether they would work.) Consider the decrease in the size of a file as a percentage of total storage space available, and the overwhelming amount of storage that individual users have at their disposal in their non-work environments. As an example, I have <$500 worth of disks at home, and have close to 1TB of space. It would cost me probably 4-6x that much to buy just the tape drive to be able to back it up. As a system administrator, I understand why my mail spool has to be capped with a small quota, but Joe User with their 250GB Winblows box at home is a much harder sell. The other problem I see continuously is mgmt drinking marketing Koolaid and then trying to tell IT how to do it's job. As more users get exposed to more technology, the worse this problem will get. They think they are experts b/c they help Granda and Auntie Em set up their wireless network. Thus, we just got a new OS railroaded into $ork b/c some lab "tests" (which the SA's who support the systems at $ork were never involved in--so you know no hard questions were asked) proved that Oracle 11i "doesn't scale" on Solaris or Linux. ("Blade" Koolaid was involved you can guess the new OS from that.) =Nadine= From marie at mmwi.com Mon Oct 17 14:55:18 2005 From: marie at mmwi.com (Marie Minder) Date: Mon, 17 Oct 2005 14:55:18 -0700 Subject: Wiring Contractors? In-Reply-To: Message-ID: <1087DB6371C8FE42B34A1EC6FDB23144104B79@SERVER.corp.mmwi.com> Hidden connections worked well for me over the years on a variety of installations. Contact Si Lewis at si at hiddenconnections.net Marie E. Minder President MMW International, Inc Marie at mmwi.com 925-838-9163 925-215-2429 (Fax) -----Original Message----- From: Michael T. Halligan [mailto:michael at halligan.org] Sent: Monday, October 17, 2005 12:39 PM To: baylisa at baylisa.org Subject: Wiring Contractors? -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Does anybody know of a good wiring contractor they can recommend? I'm about to open a new cage @ my datacenter, and am looking for a group that does decent work at a fair rate. Somebody reliable, who can work in SF without too many time constraints. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) iD8DBQFDU/3FwjCqooJyNAMRAteTAJ0dSrCNFvXHIBrD2wwnJXAUVKbBwQCdGzUy MQJUO+w9kDELQZM1e4+K4SQ= =wXSp -----END PGP SIGNATURE----- From sigje at sigje.org Mon Oct 17 17:06:08 2005 From: sigje at sigje.org (Jennifer Davis) Date: Mon, 17 Oct 2005 17:06:08 -0700 (PDT) Subject: MacWorld Conference and Expo discounts Message-ID: Register for a free exhibits-only pass (Deadline Nov 4) or 15% discount on all conference packages (Deadline Dec.9) for Macworld Conference and Expo in San Francisco, January 9-13. User Group Code - H0101 (You must use to get the discount, or Exhibits pass) If you want to volunteer at the Macworld Expo, contact me, and I'll forward your information on. Discounts to the MUG store User ID: Mug Password: Store http://www.applemugstore.com I'm not sure what kind of discounts they have, but if you find something of use, enjoy! Jennifer From sigje at sigje.org Mon Oct 17 23:15:10 2005 From: sigje at sigje.org (Jennifer Davis) Date: Mon, 17 Oct 2005 23:15:10 -0700 (PDT) Subject: USENIX LISA - Discount Message-ID: Don't forget, LISA Registration is available at http://www.usenix.org/events/lisa05/. BayLISA members get a discount using the code: BAY05. LISA is being held in San Diego this year so not too far of a hike for us. If people are interested in coordinating for car pools/hotels let me know, and we can set up a mailing list, or discussion board. Jennifer From sigje at sigje.org Thu Oct 20 11:17:51 2005 From: sigje at sigje.org (Jennifer Davis) Date: Thu, 20 Oct 2005 11:17:51 -0700 (PDT) Subject: TODAY: Oct 20, 2005: BayLISA: Incident Command for IT In-Reply-To: References: Message-ID: Don't forget! Today! > Date: Thursday, October 20, 2005 > Where: Apple Campus, Building 4, upstairs meeting room (Garage 1) > Free and Open to the General Public! > > 7:30 pm Introductions and announcements > 7:45 pm Formal Presentation > 9:45 After-meeting dinner/social outings at a local restaurant > > D. Brent Chapman will be presenting "Incident Command for IT: What we can > Learn from the Fire Department". > > This is one of the USENIX LISA 2005 invited talks > http://www.usenix.org/events/lisa05/tech/. > If you have ever been curious about what kind of value you get from the LISA > conference, come check out Brent's talk. LISA packs in 5 days of training > and 4 days of technical sessions (they overlap on days for a total of 6 days > of technical immersion), and is the conference for System Administrators. > It's being held in San Diego, California this year, so much easier for > travelling. > > Many thanks to USENIX for sharing Brent's technical talk at BayLISA, and sponsoring this month's meeting. Other goodies: Splunk hats/tshirts, Samba books for review ______________________________________________ baylisa mailing list: baylisa at baylisa.org rsvp for meeting: rsvp at baylisa.org baylisa board (request to sponsor or present): blw at baylisa.org Directions: Map it: http://maps.yahoo.com/dd?ed=UQXygP960Sz4MSU21UFEL0PTm.NocQb_k_rL3EntSvtUQ1xTqf8D4yOYIBOTjUjKZOXeEnyzvQ--&tname=&tcsz=Cupertino%2C+CA+95014-2083&tcountry=US&tdesc= >From 101 Freeway Exit on Mathilda, turn south, drive a bunch, watch Mathilda merge with Sunnyvale-Saratoga Rd, drive south some more, changes names to De Anza somewhere around the 280 fwy. [continue on 280 directions.] If you miss Mathilda (when coming south) or prefer to stay on highways for a maximum time, you can take Lawrence Expressway south, and exit on Stevens Creek, heading west into the setting sun. You'll pass the mall near Wolfe; keep going. De Anza is a huge street with a light, turn right. Just past Lazaneo (a light, there's a Donut Wheel to your right), turn right into the driveway with a low white sign showing a blue apple. The first opportunity you have to turn left will be marked Infinite Loop. Take this left, and follow the loop until you get to Building 4. Park. >From 280 Freeway Exit on De Anza Blvd, turn south. It will not be very far; there is a light at Mariami and you should turn left there. The first opportunity you have to turn left will be marked Infinite Loop. Take this left, and follow the loop until you get to Building 4. Park. If you miss Mariani (and if it's really wet, you might) this is a divided highway... you will have to U-turn at the next light, Lazaneo. (You'd see a Donut Wheel shop to the left.) >From 85 Freeway Exit turning north. You are going to be driving a little while. Do not distress and wonder where Apple is as street numbers approach the 10500 range - this is "S. De Anza" and you have to cross Stevens Creek before you're in the right section. Once past Stevens Creek, keep an eye out for the light marked Lazaneo (with its donut shop). Past it there will be low white signs with blue apples on your right. If you miss the little driveways, you can turn right at Mariani, which is rather large, and a light. The first opportunity you have to turn left will be marked Infinite Loop. Take this left, and follow the loop until you get to Building 4. Park. From sigje at sigje.org Thu Oct 20 16:19:23 2005 From: sigje at sigje.org (Jennifer Davis) Date: Thu, 20 Oct 2005 16:19:23 -0700 (PDT) Subject: Virtualization space getting interesting Message-ID: VMWare has released VM Player. You don't have to buy VMWare if you just want to run an image. You can't create new images, but you can modify the image itself. From holland at guidancetech.com Thu Oct 20 21:25:29 2005 From: holland at guidancetech.com (Rich Holland) Date: Thu, 20 Oct 2005 21:25:29 -0700 Subject: Virtualization space getting interesting In-Reply-To: Message-ID: <20051021041918.062BC588D@thorn.sasl.smtp.pobox.com> Actually, it looks like you can. There are some detailed instructions (not mine) here: http://www.laportestyle.org/tutorials/ghostinthemachine.php Rich -- Rich Holland (913) 645-1950 SAP Technical Consultant print unpack("u","92G5S\=\"!A;F]T:&5R(\'!E References: Message-ID: <1129929496.27154.2.camel@localhost.localdomain> And now VMware's website is actually handling the load so you can download it. -J On Thu, 2005-10-20 at 16:19 -0700, Jennifer Davis wrote: > VMWare has released VM Player. You don't have to buy VMWare if you just > want to run an image. You can't create new images, but you can modify the > image itself. > > From rsr at inorganic.org Fri Oct 21 16:14:59 2005 From: rsr at inorganic.org (Roy S. Rapoport) Date: Fri, 21 Oct 2005 16:14:59 -0700 Subject: Virtualization space getting interesting In-Reply-To: <1129929496.27154.2.camel@localhost.localdomain> References: <1129929496.27154.2.camel@localhost.localdomain> Message-ID: <20051021231459.GA27388@puppy.inorganic.org> On Fri, Oct 21, 2005 at 02:18:16PM -0700, Jeremy Hunt wrote: > And now VMware's website is actually handling the load so you can > download it. So basically, it sounds like I could put up my rhel4 image somewhere and let people download it ... right? (well, modulo the rhel4 licensing issues, of course :) ) -roy From sigje at sigje.org Fri Oct 21 18:20:07 2005 From: sigje at sigje.org (Jennifer Davis) Date: Fri, 21 Oct 2005 18:20:07 -0700 (PDT) Subject: Nov 17: BayLISA General Monthly meeting: ELECTIONS! Mirapoint Sponsored Bash! In-Reply-To: References: Message-ID: Date: Thursday, November 17 2005 Where: Apple Campus, Town Hall (original meeting location at BayLISA) DeAnza Three off of Mariani Ave/DeAnza Blvd in Cupertino, CA Please note the change of venue!! Free and Open to the General Public! 7:00 pm Elections! BayLISA members vote for the 2006-2007 Board members 7:30 pm Introductions and announcements 7:45 pm Guru Session: Bob Camors "Legal Implications of Email" 8:15 pm Formal Presentation: Jennifer Granick (Lawyer in Ciscogate!) "Public Interest Internet law" post meeting - Mirapoint Sponsored Pizza + beer Bash!!! RSVP if you want a guaranteed seat at the bash!! (seriously the restaurant is only so big..we have at least 40 seats :) Come hungry! ______________________________________________ baylisa mailing list: baylisa at baylisa.org rsvp for meeting: rsvp at baylisa.org baylisa board (request to sponsor or present): blw at baylisa.org From dan_bethe at yahoo.com Sat Oct 22 09:29:55 2005 From: dan_bethe at yahoo.com (Dan Bethe) Date: Sat, 22 Oct 2005 09:29:55 -0700 (PDT) Subject: Virtualization space getting interesting In-Reply-To: <20051021231459.GA27388@puppy.inorganic.org> Message-ID: <20051022162955.98477.qmail@web51712.mail.yahoo.com> > So basically, it sounds like I could put up my rhel4 image somewhere and > let people download it ... right? (well, modulo the rhel4 licensing issues, > of course :) ) s/rhel/centos/g Sure! :) Also note that qemu exists; it's a free virtual machine with optional emulator with several hosts and targets including ia32, ppc, sparc, arm, etc. It can also be hosted on MacOS and Windows. A native kernelspace accelerator is available for Linux hosts. But it can run in pure userspace. I booted ppc linux on an ia32 host with no visible performance problems as far as the boot process goes. The Darwine project has fused Qemu and Wine for running win32 apps seminatively on MacOS. http://fabrice.bellard.free.fr/qemu/ <-- home site http://en.wikipedia.org/wiki/QEMU <-- quick abstract with pro/con list Qemu can make use of vmware disk images as well. I am not sure if that's by using them directly or by only converting them though. __________________________________ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com From strata at virtual.net Sat Oct 22 09:32:50 2005 From: strata at virtual.net (Strata R. Chalup) Date: Sat, 22 Oct 2005 09:32:50 -0700 Subject: iCal calendar for BayLISA available Message-ID: <435A69B2.6020301@virtual.net> Here is a demo calendar I've created for BayLISA: http://icalexchange.com/public/strata/BayLISA.ics (subscribe) http://www.icalx.com/html/strata/day.php?cal=BayLISA (view in HTML) It's *very* easy. And see, it includes BaySUG! :-) I will update it as new speakers and events are confirmed. cheers, Strata -- ======================================================================== Strata R Chalup [KF6NBZ] strata "@" virtual.net Virtual.Net Inc http://www.virtual.net/ ** Strategic IT for the Growing Enterprise ** ========================================================================= From michael at halligan.org Sun Oct 23 21:13:01 2005 From: michael at halligan.org (Michael T. Halligan) Date: Sun, 23 Oct 2005 21:13:01 -0700 Subject: Reminder - October 20, 2005 - Brent Chapman - General Meeting In-Reply-To: References: Message-ID: <7C2050EE-999A-4F77-8185-7C6193D424ED@halligan.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I just wanted to give thanks to Brent for giving his presentation to us. I walked out of there with a couple of pages worth of notes and good points from the presentation. If every presentation given @ BayLisa is as good as this was, then I just might have found myself a reason to begrudgingly drive to the South Bay in rush-hour traffic more than once a year. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) iD8DBQFDXF9TwjCqooJyNAMRAomDAKCAxtn6Js9gSd1PYweVt+TksiJpegCgwPID gKBz3VsEmFZT4VSs+YrJpBQ= =W3yO -----END PGP SIGNATURE----- From brian.street at bayarea.net Mon Oct 24 13:13:25 2005 From: brian.street at bayarea.net (Brian Street) Date: Mon, 24 Oct 2005 13:13:25 -0700 Subject: Thin Client solutions Message-ID: <1130184805.435d4065e8195@myaccount.bayarea.net> Hello everyone, I'm tasked with trying to come up with a Thin Client Windows solution for a new venture in a foreign country. The solution should allow users access to data, but not to be able to save locally as in hard disk, floppy, cd, or USB drive. All of the data will be located on a server. Some further requirements at this stage is to disallow sending any data through {web,e}mail but I'm not sure how feasible that is. One solution is to not have the server/clients connected to the internet at all with separate computers for internet access. I'm familiar with Citrix but does anyone have any other possible solutions I can look into? Thanks in advance for any insight you may be able to provide. Brian. From sigje at sigje.org Mon Oct 24 15:32:13 2005 From: sigje at sigje.org (Jennifer Davis) Date: Mon, 24 Oct 2005 15:32:13 -0700 (PDT) Subject: [sf-perl] _Ruby_ Beer & Pizza SIG; 8 pm, 10/26, San Francisco, CA, USA (fwd) Message-ID: Hey folks, I wanted to pass this on as Michael Halligan pointed me out to the great software that is Puppet http://reductivelabs.com/projects/puppet, which is a GPLed configuration management solution written in Ruby. The author has significant experience using cfengine. So take a look at Puppet. Perhaps like me you don't have experience with Ruby, and connecting with some Ruby-ers to get a better grip on the language would be helpful. Puppet looks pretty interesting. Jennifer ---------- Forwarded message ---------- Date: Mon, 24 Oct 2005 15:11:34 -0700 From: Rich Morin Reply-To: San Francisco Perl Mongers User Group To: sfpug at sf.pm.org Subject: [sf-perl] _Ruby_ Beer & Pizza SIG; 8 pm, 10/26, San Francisco, CA, USA [last-minute try for RSVPs! -r] In the spirit of Bay Area Debian's "SHOTGUN RULES FOR BAD MEETINGS" (http://bad.debian.net/shotgun_rules.txt), I am calling yet another meeting of the Bay Area Ruby Beer & Pizza SIG. No program; just a way for folks to get together and chat about Ruby, Rails, etc. Note: Ruby appeals to a broad spectrum of programmers. Your dinner companions may speak any of a variety of languages, including C++, Perl, PHP, Python, Scheme, and Smalltalk. At the same time, they may well be struggling to learn about Rails, Ruby, SQL, etc. So, expect diversity... At the last meeting, several folks brought laptops. Given that the upcoming venue has free wifi, this seems even more appropriate! In fact, the restaurant has promised to provide a power outlet near the table, so if anyone can bring a largish LCD monitor, let me know! Beer and Pizza SIG RSVP: An RSVP would be appreciated, so that I can tell the restaurant folks what to expect. OTOH, feel free to just show up and look for a sign. :) Date: Wednesday, October 26, 2005 Time: 8:00 p.m. Place: South Beach Cafe, 800 The Embarcadero (just past the end of Townsend, at King) San Francisco, California, USA http://local.google.com/local?output=html&q=%22South+Beach+Cafe%22&btnG=Search&latlng=37630556,-122410000,10934445030027146126 Food: Cafe, Italian Trattoria, Pizzeria; free wifi Parking: Unless there's a monster baseball game, parking should be no problem after 6 pm. BART: Be prepared for a bit of a crowd, as this is the end of the prime commute time. Get off at the Embarcadero station. Within the station, exit BART, enter MUNI, and catch the N (inbound). Get off at the train station. Caltrain: (Don't take Caltrain if you can avoid it. Trains run back at 10:00 p.m. and 11:59 p.m. only!) From the train station, walk Northeast on King to the restaurant. -r P.S. The Delancey Street Restaurant is nearby and also worth considering for a special (read, nice but slightly pricy) venue. -- email: rdm at cfcl.com; phone: +1 650-873-7841 http://www.cfcl.com - Canta Forda Computer Laboratory http://www.cfcl.com/Meta - The FreeBSD Browser, Meta Project, etc. _______________________________________________ SanFrancisco-pm mailing list SanFrancisco-pm at pm.org http://mail.pm.org/mailman/listinfo/sanfrancisco-pm From bill at thecrookes.com Mon Oct 24 15:36:59 2005 From: bill at thecrookes.com (Bill Crooke) Date: Mon, 24 Oct 2005 15:36:59 -0700 Subject: Peninsula Linux Users' Group Meeting, Thursday, October 27th, 2005 Message-ID: <435D620B.7080907@thecrookes.com> Peninsula Linux Users' Group, Thursday, October 27th, 2005 We have a meeting of the Peninsula Linux Users' Group (PenLUG) this week! Here are the details about the next meeting. For more information or directions go to http://www.penlug.org/ Our website is a TWiki; please feel free to create a user account and modify the website if you have something to contribute. Date: Thursday, October 27th, 2005 Time: 7:00 - 9:00 PM Location: 100 Oracle Parkway, Redwood Shores, CA 94065 Room 104 Agenda: ======= 7:00 - 8:30 PM: Presentation by Patrick Lin: "VMware" 8:30 - 9:00 PM: Members' Minutes 8:45 - 9:00 PM: Adjourn to IHOP (Belmont) for social & food time Presentation by Patrick Lin: "VMware" ====================================================================== VMware provides virtualization software for developers and system administrators who want to revolutionize software development, testing and deployment in their enterprise. Patrick will talk about VMware's offerings, emerging technologies in virtualization and how VMware is opening up access to its source code via a community source initiative. Members' Minutes ================ Members will have an opportunity to take a few minutes to... * Describe their latest Linux discovery * Ask questions and get help from other members * Discuss Linux projects You can just stand up and talk, or give a short demo or presentation. If you need audio/visual support for your Members' Minute, please contact me in advance to arrange for your needs. We have a limited number of books courtesy of Prentice-Hall and O'Reilly to give away as an added inducement to participate in this portion of the meeting. :-) RSVP ==== Although it is NOT required, we like to have an idea of how many people to expect, so if possible please email rsvp at penlug.org if you are planning to attend. Bill Crooke PenLUG Speaker Coordinator From alvin at Mail.Linux-Consulting.com Mon Oct 24 18:47:59 2005 From: alvin at Mail.Linux-Consulting.com (Alvin Oga) Date: Mon, 24 Oct 2005 18:47:59 -0700 (PDT) Subject: more server room fun Message-ID: hi ya baylisa-erz - i thought it was funny or annoying: - the plans calls for the air ducts to blow air down the middle of the the 2 rows of racks - they built the air ducts right above one row of the 8' tall racks ( about 2' clearance ) :-) i just happened to go in there for the first time and though it was hilarious .. not building to the plans and arbitrarily moving things around - dumb questions .. for seismic reinforcement of racks .. - "ladder things" like this that is above the racks http://chatsworth.com/main.asp?ID=29 - can the ladder style cable management seen above the racks be used to hold the tops of the raacks for earthquake reinforcement ?? - i say no since its not nailed to anything and the ladder is usually just hanging :-) - they want to secure these ladders vertically to the 4x8 plywood screwed into the wall ( tin behind the sheetrock ) - when you pull on the ladder say 0.25" ( half the thickness of the plywood), the plywood will simply break apart - guess the ladder and cablement stuff just depends on which ones are used .. :-) - i like the 2x4 or 2x6 for holding the tops of the racks in place during the earthquakes and that the 2x4 is mounted into regular "x" and nailed together with those reinforcing corner brackets c ya alvin From alvin at Mail.Linux-Consulting.com Mon Oct 24 18:57:35 2005 From: alvin at Mail.Linux-Consulting.com (Alvin Oga) Date: Mon, 24 Oct 2005 18:57:35 -0700 (PDT) Subject: Thin Client solutions In-Reply-To: <1130184805.435d4065e8195@myaccount.bayarea.net> Message-ID: hi ya brian On Mon, 24 Oct 2005, Brian Street wrote: > I'm tasked with trying to come up with a Thin Client Windows solution > for a new venture in a foreign country. sounds like fun ... if its a paying job > The solution should allow users access to data, but not to be able to > save locally as in hard disk, floppy, cd, or USB drive. > All of the data will be located on a server. good idea for security and/or less headaches of managing user's data .. i assume a CF inside is not acceptable ?? - but people can write to it .. which may be bad for the same reason that usb and cd is banned > Some further requirements at this > stage is to disallow sending any data through {web,e}mail but I'm not > sure how feasible that is. that will be harder to prevent ... too too many ways to send data out or get it - lot easier to stop outgoing data ... just simply disallow outgoing connections with a simple firewall - if you cannot send outgoing email .. you cannot send data with outgoing attachments - if you cannot serve web pages .. you cannot send data over http - all other ftp/ssh/etc ports are all closed - you can view web pages .. you can read emails ?? which means they can piggy-back data onto those connections and no way to stop it ... you can drop the attachments but the "important data" can still go out or come in with the content of html or emails login is "Thief", and password is "easy" > One solution is to not have the server/clients connected to the > internet at all with separate computers for internet access. all internal PCs shoudl go throw the firewall/gateway, but means they can play with those servers and try to get out > I'm familiar with Citrix but does anyone have any other possible > solutions I can look into? network boot will prevent all the "media" needed for booting and will not have any storage for legit users or crackers > Thanks in advance for any insight you may be able to provide. the bigger problem is what is the budget for implementing the "wish list" and why is important vs what is the consequence of a packet of data sneaking thru c ya alvin From brian.street at bayarea.net Mon Oct 24 18:52:06 2005 From: brian.street at bayarea.net (Brian Street) Date: Mon, 24 Oct 2005 18:52:06 -0700 Subject: Thin Client solutions In-Reply-To: References: Message-ID: <1130205126.435d8fc6155fc@myaccount.bayarea.net> Quoting Alvin Oga : > > hi ya brian > > On Mon, 24 Oct 2005, Brian Street wrote: > > > I'm tasked with trying to come up with a Thin Client Windows > solution > > for a new venture in a foreign country. > > sounds like fun ... if its a paying job > This is for my company. We are going to open an Engineering office. > > The solution should allow users access to data, but not to be > able to > > save locally as in hard disk, floppy, cd, or USB drive. > > All of the data will be located on a server. > > good idea for security and/or less headaches of managing user's > data .. > > i assume a CF inside is not acceptable ?? > - but people can write to it .. which may be bad > for the same reason that usb and cd is banned > I'm sorry...CF? > > Some further requirements at this > > stage is to disallow sending any data through {web,e}mail but I'm > not > > sure how feasible that is. > > that will be harder to prevent ... too too many ways to > send data out or get it > > - lot easier to stop outgoing data ... just simply disallow > outgoing connections with a simple firewall > - if you cannot send outgoing email .. you cannot > send data with outgoing attachments > > - if you cannot serve web pages .. you cannot > send data over http > > - all other ftp/ssh/etc ports are all closed > > - you can view web pages .. you can read emails ?? > > which means they can piggy-back data onto those connections > and no way to stop it ... > > you can drop the attachments but the "important data" can still > go out or come in with the content of html or emails > > login is "Thief", and password is "easy" > > > One solution is to not have the server/clients connected to the > > internet at all with separate computers for internet access. > > all internal PCs shoudl go throw the firewall/gateway, but means > they can play with those servers and try to get out > > > I'm familiar with Citrix but does anyone have any other possible > > solutions I can look into? > > network boot will prevent all the "media" needed for booting > and will not have any storage for legit users or crackers > > > Thanks in advance for any insight you may be able to provide. > > the bigger problem is what is the budget for implementing the "wish > list" > and why is important vs what is the consequence of a packet > of data sneaking thru > > c ya > alvin > Your points are valid and we've been thinking about them all. What I am considering is a firewalled network for code development that only allows connections from specific thin clients (I should be able to allow only specific mac addresses to connect just like a wireless node, no?). We are also considering a separate desktop for the users to check email, internet access, etc. but what prevents them from just taking the time to copy the data from the isolated network to the other network. At some point you have to trust that your source code is safe with your new employees, but I think that might be too cautious of an approach. We'd like to limit the access to the code and try like heck to keep it from getting out....which is a huge task and probably not possible. Brian. From david at catwhisker.org Mon Oct 24 19:37:56 2005 From: david at catwhisker.org (David Wolfskill) Date: Mon, 24 Oct 2005 19:37:56 -0700 Subject: Thin Client solutions In-Reply-To: <1130205126.435d8fc6155fc@myaccount.bayarea.net> References: <1130205126.435d8fc6155fc@myaccount.bayarea.net> Message-ID: <20051025023756.GC69015@bunrab.catwhisker.org> On Mon, Oct 24, 2005 at 06:52:06PM -0700, Brian Street wrote: > ... > > Your points are valid and we've been thinking about them all. What I > am considering is a firewalled network for code development that only > allows connections from specific thin clients (I should be able to > allow only specific mac addresses to connect just like a wireless > node, no?). The phrase "just like" is well-used here, since that MAC address filtering may range anywhere from "adequate" to "about as effective as tissue paper." My knowledge of the Microsoft Windows world is, bluntly, negligible, so it's possible that folks using such a platform would find such filtering effective. But running FreeBSD, I know -- because I've done it -- that one may change the MAC address of certain NICs. Indeed, MAC address filtering is one of the techniques I use on my home wireless net. So to verify that it was acting as I expected it to, I established a connection between my laptop and an access point ("AP") using a Cisco 340 (802.11b) card. I then used the "ifconfig" command to change the MAC address -- and noted with some satisfaction that this disrupted the connection quite effectively. I then changed the MAC address back, and the connection was restored. Maybe you won't be dealing with folks who would (be able to) do such things; I don't know. And not all NICs necessarily have "programmable" MAC addresses. MAC address filtering can be of use, but you should know its limitations before going too far with plans to deploy it. > We are also considering a separate desktop for the users > to check email, internet access, etc. but what prevents them from > just taking the time to copy the data from the isolated network to > the other network. At some point you have to trust that your source > code is safe with your new employees, but I think that might be too > cautious of an approach. What happens if one of them has a cell phone with a camera? How about an employee with an eidetic memory (referring to the "between the ears" type of memory here, not semiconductors)? > We'd like to limit the access to the code and try like heck to keep it > from getting out....which is a huge task and probably not possible. Think "risk mitigation." :-} Peace, david -- David H. Wolfskill david at catwhisker.org Prediction is difficult, especially if it involves the future. -- Niels Bohr See http://www.catwhisker.org/~david/publickey.gpg for public key. From alvin at Mail.Linux-Consulting.com Mon Oct 24 19:40:16 2005 From: alvin at Mail.Linux-Consulting.com (Alvin Oga) Date: Mon, 24 Oct 2005 19:40:16 -0700 (PDT) Subject: Thin Client solutions In-Reply-To: <1130205126.435d8fc6155fc@myaccount.bayarea.net> Message-ID: hi ya brian On Mon, 24 Oct 2005, Brian Street wrote: > > i assume a CF inside is not acceptable ?? > > I'm sorry...CF? compact flash > Your points are valid and we've been thinking about them all. What I > am considering is a firewalled network for code development that only > allows connections from specific thin clients (I should be able to > allow only specific mac addresses to connect just like a wireless > node, no?). for security ... macaddress is worthless, since it's easily changed by those that want to get in that way wireless is say 99.99% insecure ... unless one uses ssh for the connections between the wireless client and where ever it goes on the other end > We are also considering a separate desktop for the users > to check email, internet access, etc. but what prevents them from > just taking the time to copy the data from the isolated network to > the other network. nothing ... and sneaker net always works best ...and can't stop it other than if they were fired and "needs the job" > At some point you have to trust that your source > code is safe with your new employees, but I think that might be too > cautious of an approach. you have to trust the people you hire and work with otherwise, why are you hiring them ?? > We'd like to limit the access to the code and try like heck to keep it > from getting out....which is a huge task and probably not possible. if it does go out .. what is the consequence in terms of $$$ for loss because the competitor steals your idea and beats you to the paying consumer market vs costs to prevent the leak ?? - you can always encrypt the data with people's private key, so that it goes out, you know who leaked it ======== if they have physical access to the pc ... there is no security ... - all best are off - first thing anybody can do is simply pull the power plug or mroe likely, wiggle the ethernet cable and you get your 3am phone call that the network is down - endless list of security issues to solve vs productivity to get products out the door c ya alvin From brian.street at bayarea.net Mon Oct 24 20:15:55 2005 From: brian.street at bayarea.net (Brian Street) Date: Mon, 24 Oct 2005 20:15:55 -0700 Subject: Thin Client solutions In-Reply-To: <20051025023756.GC69015@bunrab.catwhisker.org> References: <1130205126.435d8fc6155fc@myaccount.bayarea.net> <20051025023756.GC69015@bunrab.catwhisker.org> Message-ID: <1130210155.435da36b1ec42@myaccount.bayarea.net> Quoting David Wolfskill : [snip] > > Think "risk mitigation." :-} > > Peace, > david > -- David, Mitigation is why I was thinking of a diskless client with the server locked down. The hope was that they wouldn't be able to save anything locally but all of the diskless clients I've seen so far have USB ports. I haven't played with BIOS enough to know if I could lock out USB on them or not, but if I can't, then it wouldn't matter if it was a thin client or not. Thanks, Brian. From david at catwhisker.org Mon Oct 24 20:37:36 2005 From: david at catwhisker.org (David Wolfskill) Date: Mon, 24 Oct 2005 20:37:36 -0700 Subject: Thin Client solutions In-Reply-To: <1130210155.435da36b1ec42@myaccount.bayarea.net> References: <1130205126.435d8fc6155fc@myaccount.bayarea.net> <20051025023756.GC69015@bunrab.catwhisker.org> <1130210155.435da36b1ec42@myaccount.bayarea.net> Message-ID: <20051025033736.GD69015@bunrab.catwhisker.org> On Mon, Oct 24, 2005 at 08:15:55PM -0700, Brian Street wrote: > ... > Mitigation is why I was thinking of a diskless client with the server > locked down. The hope was that they wouldn't be able to save anything > locally but all of the diskless clients I've seen so far have USB > ports. I haven't played with BIOS enough to know if I could lock out > USB on them or not, but if I can't, then it wouldn't matter if it was > a thin client or not. Surely a bit of surgery can "fix" this (in the veterinary sense), at least to the point that the USB port doesn't work...? Of course, as Alvin pointed out, physical access to the machine renders many of the evasive maneuvers rather pointless. Peace, david -- David H. Wolfskill david at catwhisker.org Prediction is difficult, especially if it involves the future. -- Niels Bohr See http://www.catwhisker.org/~david/publickey.gpg for public key. From alvin at Mail.Linux-Consulting.com Mon Oct 24 21:17:28 2005 From: alvin at Mail.Linux-Consulting.com (Alvin Oga) Date: Mon, 24 Oct 2005 21:17:28 -0700 (PDT) Subject: Thin Client solutions In-Reply-To: <1130210155.435da36b1ec42@myaccount.bayarea.net> Message-ID: hi ya brian On Mon, 24 Oct 2005, Brian Street wrote: > Mitigation is why I was thinking of a diskless client with the server > locked down. The hope was that they wouldn't be able to save anything > locally but all of the diskless clients I've seen so far have USB > ports. I haven't played with BIOS enough to know if I could lock out > USB on them or not, but if I can't, then it wouldn't matter if it was > a thin client or not. the ony way to break usb connectivity is to stick epoxie glue and other assorted fun stuff of equivalents inside the usb-port you could password protect the bios to prevent people from getting into the bios, but, there's probably a free bios pwd cracker or bypasser as long as they can touch the pc ... you're better off to do a really serious background check of the new employee and have a really good and agreesive lawyers to review all documents - if there's some false data on the resume, you're already in trouble before their first day of work and have the lawyers meet with each person say monthly just to show the big guns is watching their every move c ya alvin From jkavitsk at Brocade.COM Mon Oct 24 21:44:55 2005 From: jkavitsk at Brocade.COM (Jim Kavitsky) Date: Mon, 24 Oct 2005 21:44:55 -0700 Subject: Thin Client solutions Message-ID: <24BD2D5F3CEF4F4780606124741B48169969@hq-ex-7.brocade.com> You might want to check out these guys. They are the remains of the old NCD company, that made thin client Xterminal hardware/software. They now make software that they claim will turn a PC into a secure, easily managed thin client. I'm not that convinced that a software solution alone can do this, but you never know, they may have an interesting design. http://www.thinpathsystems.com/ -jimk -----Original Message----- From: owner-baylisa at baylisa.org [mailto:owner-baylisa at baylisa.org] On Behalf Of Brian Street Sent: Monday, October 24, 2005 6:52 PM To: Alvin Oga Cc: baylisa at baylisa.org Subject: Re: Thin Client solutions Quoting Alvin Oga : > > hi ya brian > > On Mon, 24 Oct 2005, Brian Street wrote: > > > I'm tasked with trying to come up with a Thin Client Windows > solution > > for a new venture in a foreign country. > > sounds like fun ... if its a paying job > This is for my company. We are going to open an Engineering office. > > The solution should allow users access to data, but not to be > able to > > save locally as in hard disk, floppy, cd, or USB drive. > > All of the data will be located on a server. > > good idea for security and/or less headaches of managing user's > data .. > > i assume a CF inside is not acceptable ?? > - but people can write to it .. which may be bad > for the same reason that usb and cd is banned > I'm sorry...CF? > > Some further requirements at this > > stage is to disallow sending any data through {web,e}mail but I'm > not > > sure how feasible that is. > > that will be harder to prevent ... too too many ways to > send data out or get it > > - lot easier to stop outgoing data ... just simply disallow > outgoing connections with a simple firewall > - if you cannot send outgoing email .. you cannot > send data with outgoing attachments > > - if you cannot serve web pages .. you cannot > send data over http > > - all other ftp/ssh/etc ports are all closed > > - you can view web pages .. you can read emails ?? > > which means they can piggy-back data onto those connections > and no way to stop it ... > > you can drop the attachments but the "important data" can still > go out or come in with the content of html or emails > > login is "Thief", and password is "easy" > > > One solution is to not have the server/clients connected to the > > internet at all with separate computers for internet access. > > all internal PCs shoudl go throw the firewall/gateway, but means > they can play with those servers and try to get out > > > I'm familiar with Citrix but does anyone have any other possible > > solutions I can look into? > > network boot will prevent all the "media" needed for booting > and will not have any storage for legit users or crackers > > > Thanks in advance for any insight you may be able to provide. > > the bigger problem is what is the budget for implementing the "wish > list" > and why is important vs what is the consequence of a packet > of data sneaking thru > > c ya > alvin > Your points are valid and we've been thinking about them all. What I am considering is a firewalled network for code development that only allows connections from specific thin clients (I should be able to allow only specific mac addresses to connect just like a wireless node, no?). We are also considering a separate desktop for the users to check email, internet access, etc. but what prevents them from just taking the time to copy the data from the isolated network to the other network. At some point you have to trust that your source code is safe with your new employees, but I think that might be too cautious of an approach. We'd like to limit the access to the code and try like heck to keep it from getting out....which is a huge task and probably not possible. Brian. From michael at halligan.org Mon Oct 24 22:15:40 2005 From: michael at halligan.org (Michael T. Halligan) Date: Mon, 24 Oct 2005 22:15:40 -0700 Subject: iCal calendar for BayLISA available In-Reply-To: <435A69B2.6020301@virtual.net> References: <435A69B2.6020301@virtual.net> Message-ID: <655BDEF5-EBDF-489A-98B2-1654F0F7399B@halligan.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Strata, You rock! Michael On Oct 22, 2005, at 9:32 AM, Strata R. Chalup wrote: > Here is a demo calendar I've created for BayLISA: > > http://icalexchange.com/public/strata/BayLISA.ics (subscribe) > http://www.icalx.com/html/strata/day.php?cal=BayLISA (view in > HTML) > > It's *very* easy. And see, it includes BaySUG! :-) > > I will update it as new speakers and events are confirmed. > > cheers, > Strata > > > -- > ====================================================================== > == > Strata R Chalup [KF6NBZ] strata "@" > virtual.net > Virtual.Net Inc http:// > www.virtual.net/ > ** Strategic IT for the Growing Enterprise ** > ====================================================================== > === > > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) iD8DBQFDXb+AwjCqooJyNAMRAjuaAJ4xdCF3THorMQhQ+U/f3uEi/5wowgCePyui OFryljT9hfFrB9jfuErQoSk= =KQpP -----END PGP SIGNATURE----- From brian.street at bayarea.net Tue Oct 25 03:17:22 2005 From: brian.street at bayarea.net (Brian Street) Date: Tue, 25 Oct 2005 03:17:22 -0700 Subject: Thin Client solutions In-Reply-To: <24BD2D5F3CEF4F4780606124741B48169969@hq-ex-7.brocade.com> References: <24BD2D5F3CEF4F4780606124741B48169969@hq-ex-7.brocade.com> Message-ID: <1130235442.435e0632bca66@myaccount.bayarea.net> Quoting Jim Kavitsky : > You might want to check out these guys. They are the remains of the > old > NCD company, that made thin client Xterminal hardware/software. > They now > make software that they claim will turn a PC into a secure, easily > managed thin client. I'm not that convinced that a software > solution > alone can do this, but you never know, they may have an interesting > design. > > http://www.thinpathsystems.com/ > > -jimk > Jim, Thanks for the reply. I came across these guys in my search...NCD was one of the first searches I did because I worked in a company where all the engineers had one of these on their desks. History repeats. Brian. From lanning at lanning.cc Mon Oct 24 22:01:39 2005 From: lanning at lanning.cc (Robert Hajime Lanning) Date: Mon, 24 Oct 2005 22:01:39 -0700 (PDT) Subject: Thin Client solutions In-Reply-To: References: <1130205126.435d8fc6155fc@myaccount.bayarea.net> Message-ID: <52608.192.168.128.102.1130216499.squirrel@ssl.monsoonwind.com> > On Mon, 24 Oct 2005, Brian Street wrote: >> Your points are valid and we've been thinking about them all. >> What I am considering is a firewalled network for code >> development that only allows connections from specific thin >> clients (I should be able to allow only specific mac addresses >> to connect just like a wireless node, no?). > > for security ... macaddress is worthless, since it's easily > changed by those that want to get in that way Also, MAC address filtering is only good for directly connected devices. It is all stripped as soon as you hit a router. -- And, did Guloka think the Ulus were too ugly to save? -Centauri From jeff at drinktomi.com Tue Oct 25 11:03:24 2005 From: jeff at drinktomi.com (Jeff With The Big Yellow Suit) Date: Tue, 25 Oct 2005 11:03:24 -0700 Subject: Thin Client solutions In-Reply-To: <1130205126.435d8fc6155fc@myaccount.bayarea.net> References: <1130205126.435d8fc6155fc@myaccount.bayarea.net> Message-ID: <06d3dec016cf22abaac6712931561e1b@drinktomi.com> > This is for my company. We are going to open an Engineering office. No doubt it's in a third wold country with really cheap labor, and damn near no legal system. That sounds like your company is trying to treat economic and political problems with IT. This is going to be a pretty brutal letter. It's a little tongue and check, but only a little. Law, contracts, and trustworthy judicial systems are wonderful things. When you don't have them you have to supply your own substitutes. Pay the employees real wages: buy their loyalty. Make sure you have political relationships in the area. Grease their palms as needed. If you're in an area that's truly lawless then hire your own intelligence, and have muscle on retainer. Gangster's rackets aren't violent by nature, they just have to supply their own law. They don't use IT to ensure loyalty. -jeff From wingedpower at gmail.com Tue Oct 25 12:04:50 2005 From: wingedpower at gmail.com (Wing Wong) Date: Tue, 25 Oct 2005 12:04:50 -0700 Subject: Thin Client solutions In-Reply-To: <24BD2D5F3CEF4F4780606124741B48169969@hq-ex-7.brocade.com> References: <24BD2D5F3CEF4F4780606124741B48169969@hq-ex-7.brocade.com> Message-ID: <7097bd8c0510251204m4377496g831e71a8bb27c2e6@mail.gmail.com> >From Previous Post: > > Your points are valid and we've been thinking about them all. What I > am considering is a firewalled network for code development that only > allows connections from specific thin clients (I should be able to > allow only specific mac addresses to connect just like a wireless > node, no?). We are also considering a separate desktop for the users > to check email, internet access, etc. but what prevents them from > just taking the time to copy the data from the isolated network to > the other network. At some point you have to trust that your source > code is safe with your new employees, but I think that might be too > cautious of an approach. > > We'd like to limit the access to the code and try like heck to keep it > from getting out....which is a huge task and probably not possible. > > Brian. > > [ warning : long post ] Mac addresses can be cloned, so mac address filtering is pretty pointless. Google the internet for articles about getting into wifi access points and you will see notes about Mac address cloning. Your best bet would be to have a VPN setup on your network. The coders are on one VPN and the public access terminals for email/etc are on a seperate VPN. That way, the only way anyone is able to do anything on your network is if they are authenticated against one of the VPNs. Just plugging a computer/laptop into your network won't get them anywhere. This will prevent code from walking. Note: The developer VPN should have its own email server for internal only emails. That way, the developers can email one another code and notes, but the email has no chance of ever entering the public networks/internet. Same for word processing, printing, etc. One way to do this is: Setup your various VPN networks so that developers are isolated from the rest of the world, since theft of IP seems to be a concern. Have a VMware ACE setup to create limited access images of Windows for developers to use. Have development data on a central server, not on the images. All changes to the thinclient images are undone when the system is rebooted or the user logs out. USB, PCMCIA, FW, CDROM, SOUND, etc are disabled on the thinclient machine image. The Image contains the VPN software to authenticate against the Developer network, but requires a developer to login. Instead of ACE, you can also use a stripped down and hardened PXE-booted Linux to run VMware player. Use that to run restricted VMware images served by your central server. The Linux image can have the USB, CDROM, PCMCIA, etc modules unloaded or not compile in so that the developer/user won't have access to it from Linux or VMware/Windows. Ultimately, if your developers are looking to steal your info, they can always bring in a digicam to photograph snippets of code/etc. They could bridge the private and public networks to copy data. They could work with someone who manages to the networks to bridge the networks physically. They could steal a backup tape. Depending on the code they are developing, they could even embed the source code into the compiled application for redumping later. They could even bridge the desktop and the thin client with a serial cable or parallel port cable to do a system-to-system copy. I mean... they are developers, it isn't hard to write a simple utility or download a public one to do a serial/parallel cable transfer. With a custom LED/photo-diode device, you could, in theory, use the monitor to export data serially or parallel. (Might be a nice hobby project, actually.) If the thinclient needs to be secure, then it should store NO information and have no means to input/output other than the screen and the keyboard/mouse. The system should stop working if it is unplugged from the network and require re-authentication to prevent cached data from being copied to another computer(thinclient+ramdrive => laptop via cross-over cable). Ie, if the thinclient's OS detects it isn't in contact with the central server, it should wipe it's local ramdisk and shutdown. The desktop/workstation should similarly be restricted and limited, but via a different network and different central server. "Maybe" have USB/CDROM access since it is for normal office work, but it should definitely not have any means to connect with the thin client in any way. Assume that the BIOS can be compromised. Passwords can be reset. So a normal machine plugged into your network will get nothing except the PXE-boot/dhcp information to load a highly restricted image which will not access the hard drive, cdrom, usb, flash, pcmcia, serial, parallel, infrared, bluetooth, wifi, or sound ports. Regarding the "thinpathsystems.com " X terminal product, it makes use of the local hard disk. So once you have installed it once, there is very little to prevent it from being compromised to allow copying data to another machine from hooking up to it and copying data from it. Seriously, virtualize the OS. This allows you to lock down the hardware at 2 levels: the host OS(Linux) can disable drivers to the various hardware ports, so that even if the system HAD a hard drive in it, it won't be used, and the GUEST OS ala VMware Player(Windows), where it has no access to the HOST OS's devices, which aren't available, and the VMware instance is further disabled. If they manage to hack the Windows Guest OS, the Linux underlying OS won't let them write to anything or transmit anywhere. If they manage to hack the underlying Linux OS, there is nowhere to write programs to since the system isn't compiled with support for local storage or local buses. VMware Player can even limit which shared folders are available. If they disconnect the network, you can encode the Linux distro to basically wipe the ram drive on the thinclient via a heartbeat with a central server. No return beats in say 5 seconds and the ethernet link is down? We've been disconnected, wipe it and shutdown. Mitigated risk to cached data theft. Since the saved data is stored on a NFS/CIFS/CVS central server, no data loss. Since the OS is booting from a remote image, no OS corruption. It might be a bit more involved than a straightforward firewall/VPN/segmented network approach or an X11 thinclient approach, but you get alot more control while being able to provide a "full" OS to the developers to work on. You can also maintain different revisions of workstation images,should someone need to work on a particular OS revision or a different set of development tools. The VMware ACE route has a higher price tag, but is a single bundled package. The Linux+VmwarePlayer+VMwareWorkstation route is cheaper, but requires a little more admin experience/knowledge. But both options will mitigate the risk of developers walking off with information on their laptops, portable media, etc... when properly configured. How much protection you need depends on what the requirements are for the project. Wing. -- Wing Wong wingedpower at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From wingedpower at gmail.com Tue Oct 25 12:04:50 2005 From: wingedpower at gmail.com (Wing Wong) Date: Tue, 25 Oct 2005 12:04:50 -0700 Subject: Thin Client solutions In-Reply-To: <24BD2D5F3CEF4F4780606124741B48169969@hq-ex-7.brocade.com> References: <24BD2D5F3CEF4F4780606124741B48169969@hq-ex-7.brocade.com> Message-ID: <7097bd8c0510251204m4377496g831e71a8bb27c2e6@mail.gmail.com> >From Previous Post: > > Your points are valid and we've been thinking about them all. What I > am considering is a firewalled network for code development that only > allows connections from specific thin clients (I should be able to > allow only specific mac addresses to connect just like a wireless > node, no?). We are also considering a separate desktop for the users > to check email, internet access, etc. but what prevents them from > just taking the time to copy the data from the isolated network to > the other network. At some point you have to trust that your source > code is safe with your new employees, but I think that might be too > cautious of an approach. > > We'd like to limit the access to the code and try like heck to keep it > from getting out....which is a huge task and probably not possible. > > Brian. > > [ warning : long post ] Mac addresses can be cloned, so mac address filtering is pretty pointless. Google the internet for articles about getting into wifi access points and you will see notes about Mac address cloning. Your best bet would be to have a VPN setup on your network. The coders are on one VPN and the public access terminals for email/etc are on a seperate VPN. That way, the only way anyone is able to do anything on your network is if they are authenticated against one of the VPNs. Just plugging a computer/laptop into your network won't get them anywhere. This will prevent code from walking. Note: The developer VPN should have its own email server for internal only emails. That way, the developers can email one another code and notes, but the email has no chance of ever entering the public networks/internet. Same for word processing, printing, etc. One way to do this is: Setup your various VPN networks so that developers are isolated from the rest of the world, since theft of IP seems to be a concern. Have a VMware ACE setup to create limited access images of Windows for developers to use. Have development data on a central server, not on the images. All changes to the thinclient images are undone when the system is rebooted or the user logs out. USB, PCMCIA, FW, CDROM, SOUND, etc are disabled on the thinclient machine image. The Image contains the VPN software to authenticate against the Developer network, but requires a developer to login. Instead of ACE, you can also use a stripped down and hardened PXE-booted Linux to run VMware player. Use that to run restricted VMware images served by your central server. The Linux image can have the USB, CDROM, PCMCIA, etc modules unloaded or not compile in so that the developer/user won't have access to it from Linux or VMware/Windows. Ultimately, if your developers are looking to steal your info, they can always bring in a digicam to photograph snippets of code/etc. They could bridge the private and public networks to copy data. They could work with someone who manages to the networks to bridge the networks physically. They could steal a backup tape. Depending on the code they are developing, they could even embed the source code into the compiled application for redumping later. They could even bridge the desktop and the thin client with a serial cable or parallel port cable to do a system-to-system copy. I mean... they are developers, it isn't hard to write a simple utility or download a public one to do a serial/parallel cable transfer. With a custom LED/photo-diode device, you could, in theory, use the monitor to export data serially or parallel. (Might be a nice hobby project, actually.) If the thinclient needs to be secure, then it should store NO information and have no means to input/output other than the screen and the keyboard/mouse. The system should stop working if it is unplugged from the network and require re-authentication to prevent cached data from being copied to another computer(thinclient+ramdrive => laptop via cross-over cable). Ie, if the thinclient's OS detects it isn't in contact with the central server, it should wipe it's local ramdisk and shutdown. The desktop/workstation should similarly be restricted and limited, but via a different network and different central server. "Maybe" have USB/CDROM access since it is for normal office work, but it should definitely not have any means to connect with the thin client in any way. Assume that the BIOS can be compromised. Passwords can be reset. So a normal machine plugged into your network will get nothing except the PXE-boot/dhcp information to load a highly restricted image which will not access the hard drive, cdrom, usb, flash, pcmcia, serial, parallel, infrared, bluetooth, wifi, or sound ports. Regarding the "thinpathsystems.com " X terminal product, it makes use of the local hard disk. So once you have installed it once, there is very little to prevent it from being compromised to allow copying data to another machine from hooking up to it and copying data from it. Seriously, virtualize the OS. This allows you to lock down the hardware at 2 levels: the host OS(Linux) can disable drivers to the various hardware ports, so that even if the system HAD a hard drive in it, it won't be used, and the GUEST OS ala VMware Player(Windows), where it has no access to the HOST OS's devices, which aren't available, and the VMware instance is further disabled. If they manage to hack the Windows Guest OS, the Linux underlying OS won't let them write to anything or transmit anywhere. If they manage to hack the underlying Linux OS, there is nowhere to write programs to since the system isn't compiled with support for local storage or local buses. VMware Player can even limit which shared folders are available. If they disconnect the network, you can encode the Linux distro to basically wipe the ram drive on the thinclient via a heartbeat with a central server. No return beats in say 5 seconds and the ethernet link is down? We've been disconnected, wipe it and shutdown. Mitigated risk to cached data theft. Since the saved data is stored on a NFS/CIFS/CVS central server, no data loss. Since the OS is booting from a remote image, no OS corruption. It might be a bit more involved than a straightforward firewall/VPN/segmented network approach or an X11 thinclient approach, but you get alot more control while being able to provide a "full" OS to the developers to work on. You can also maintain different revisions of workstation images,should someone need to work on a particular OS revision or a different set of development tools. The VMware ACE route has a higher price tag, but is a single bundled package. The Linux+VmwarePlayer+VMwareWorkstation route is cheaper, but requires a little more admin experience/knowledge. But both options will mitigate the risk of developers walking off with information on their laptops, portable media, etc... when properly configured. How much protection you need depends on what the requirements are for the project. Wing. -- Wing Wong wingedpower at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From wingedpower at gmail.com Tue Oct 25 12:15:20 2005 From: wingedpower at gmail.com (Wing Wong) Date: Tue, 25 Oct 2005 12:15:20 -0700 Subject: Thin Client solutions In-Reply-To: <7097bd8c0510251204m4377496g831e71a8bb27c2e6@mail.gmail.com> References: <24BD2D5F3CEF4F4780606124741B48169969@hq-ex-7.brocade.com> <7097bd8c0510251204m4377496g831e71a8bb27c2e6@mail.gmail.com> Message-ID: <7097bd8c0510251215p4a351d8xb076de48a68f74b5@mail.gmail.com> Regarding "At some point you have to trust that your source code is safe with your new employees...", I would say that that won't hold water with your employers if something goes wrong and code leaks. It is better to say, "This failed and can be fixed to prevent future breeches" than to say, "We thought we could trust them with the code." They could all be your friends. They could be people you don't know. They could be employees of some years. But what matters is that the system needs to be secure. Maybe it isn't going to be any of the people who work with the company now. It might be an intern. It might be that new hire your company pulled from a competitor. It could be the janitor. In a similar situation, I would say that it is a matter of ensuring that if someone should want to steal your company's intellectual property, you are going to make it as near impossible as is feasible, rather than saying you don't trust current and future employees. Wing. On 10/25/05, Wing Wong wrote: > > > From Previous Post: > > > > > Your points are valid and we've been thinking about them all. What I > > am considering is a firewalled network for code development that only > > allows connections from specific thin clients (I should be able to > > allow only specific mac addresses to connect just like a wireless > > node, no?). We are also considering a separate desktop for the users > > to check email, internet access, etc. but what prevents them from > > just taking the time to copy the data from the isolated network to > > the other network. At some point you have to trust that your source > > code is safe with your new employees, but I think that might be too > > cautious of an approach. > > > > We'd like to limit the access to the code and try like heck to keep it > > from getting out....which is a huge task and probably not possible. > > > > Brian. > > > > > [ warning : long post ] > > Mac addresses can be cloned, so mac address filtering is pretty pointless. > Google the internet for articles about getting into wifi access points and > you will see notes about Mac address cloning. > > Your best bet would be to have a VPN setup on your network. The coders are > on one VPN and the public access terminals for email/etc are on a seperate > VPN. That way, the only way anyone is able to do anything on your network is > if they are authenticated against one of the VPNs. Just plugging a > computer/laptop into your network won't get them anywhere. This will prevent > code from walking. > > Note: The developer VPN should have its own email server for internal only > emails. That way, the developers can email one another code and notes, but > the email has no chance of ever entering the public networks/internet. Same > for word processing, printing, etc. > > One way to do this is: > > Setup your various VPN networks so that developers are isolated from the > rest of the world, since theft of IP seems to be a concern. Have a VMware > ACE setup to create limited access images of Windows for developers to use. > Have development data on a central server, not on the images. All changes to > the thinclient images are undone when the system is rebooted or the user > logs out. USB, PCMCIA, FW, CDROM, SOUND, etc are disabled on the thinclient > machine image. The Image contains the VPN software to authenticate against > the Developer network, but requires a developer to login. > > Instead of ACE, you can also use a stripped down and hardened PXE-booted > Linux to run VMware player. Use that to run restricted VMware images served > by your central server. The Linux image can have the USB, CDROM, PCMCIA, etc > modules unloaded or not compile in so that the developer/user won't have > access to it from Linux or VMware/Windows. > > Ultimately, if your developers are looking to steal your info, they can > always bring in a digicam to photograph snippets of code/etc. They could > bridge the private and public networks to copy data. They could work with > someone who manages to the networks to bridge the networks physically. They > could steal a backup tape. Depending on the code they are developing, they > could even embed the source code into the compiled application for redumping > later. > > They could even bridge the desktop and the thin client with a serial cable > or parallel port cable to do a system-to-system copy. I mean... they are > developers, it isn't hard to write a simple utility or download a public one > to do a serial/parallel cable transfer. With a custom LED/photo-diode > device, you could, in theory, use the monitor to export data serially or > parallel. (Might be a nice hobby project, actually.) > > > If the thinclient needs to be secure, then it should store NO information > and have no means to input/output other than the screen and the > keyboard/mouse. The system should stop working if it is unplugged from the > network and require re-authentication to prevent cached data from being > copied to another computer(thinclient+ramdrive => laptop via cross-over > cable). Ie, if the thinclient's OS detects it isn't in contact with the > central server, it should wipe it's local ramdisk and shutdown. > > The desktop/workstation should similarly be restricted and limited, but > via a different network and different central server. "Maybe" have USB/CDROM > access since it is for normal office work, but it should definitely not have > any means to connect with the thin client in any way. > > Assume that the BIOS can be compromised. Passwords can be reset. So a > normal machine plugged into your network will get nothing except the > PXE-boot/dhcp information to load a highly restricted image which will not > access the hard drive, cdrom, usb, flash, pcmcia, serial, parallel, > infrared, bluetooth, wifi, or sound ports. > > Regarding the "thinpathsystems.com " X > terminal product, it makes use of the local hard disk. So once you have > installed it once, there is very little to prevent it from being compromised > to allow copying data to another machine from hooking up to it and copying > data from it. > > Seriously, virtualize the OS. This allows you to lock down the hardware at > 2 levels: the host OS(Linux) can disable drivers to the various hardware > ports, so that even if the system HAD a hard drive in it, it won't be used, > and the GUEST OS ala VMware Player(Windows), where it has no access to the > HOST OS's devices, which aren't available, and the VMware instance is > further disabled. > > If they manage to hack the Windows Guest OS, the Linux underlying OS won't > let them write to anything or transmit anywhere. If they manage to hack the > underlying Linux OS, there is nowhere to write programs to since the system > isn't compiled with support for local storage or local buses. > VMware Player can even limit which shared folders are available. > > If they disconnect the network, you can encode the Linux distro to > basically wipe the ram drive on the thinclient via a heartbeat with a > central server. No return beats in say 5 seconds and the ethernet link is > down? We've been disconnected, wipe it and shutdown. Mitigated risk to > cached data theft. Since the saved data is stored on a NFS/CIFS/CVS central > server, no data loss. Since the OS is booting from a remote image, no OS > corruption. > > It might be a bit more involved than a straightforward > firewall/VPN/segmented network approach or an X11 thinclient approach, but > you get alot more control while being able to provide a "full" OS to the > developers to work on. You can also maintain different revisions of > workstation images,should someone need to work on a particular OS revision > or a different set of development tools. > > The VMware ACE route has a higher price tag, but is a single bundled > package. > The Linux+VmwarePlayer+VMwareWorkstation route is cheaper, but requires a > little more admin experience/knowledge. > > But both options will mitigate the risk of developers walking off with > information on their laptops, portable media, etc... when properly > configured. > > How much protection you need depends on what the requirements are for the > project. > > Wing. > > -- > Wing Wong > wingedpower at gmail.com > -- Wing Wong wingedpower at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From wingedpower at gmail.com Tue Oct 25 12:15:20 2005 From: wingedpower at gmail.com (Wing Wong) Date: Tue, 25 Oct 2005 12:15:20 -0700 Subject: Thin Client solutions In-Reply-To: <7097bd8c0510251204m4377496g831e71a8bb27c2e6@mail.gmail.com> References: <24BD2D5F3CEF4F4780606124741B48169969@hq-ex-7.brocade.com> <7097bd8c0510251204m4377496g831e71a8bb27c2e6@mail.gmail.com> Message-ID: <7097bd8c0510251215p4a351d8xb076de48a68f74b5@mail.gmail.com> Regarding "At some point you have to trust that your source code is safe with your new employees...", I would say that that won't hold water with your employers if something goes wrong and code leaks. It is better to say, "This failed and can be fixed to prevent future breeches" than to say, "We thought we could trust them with the code." They could all be your friends. They could be people you don't know. They could be employees of some years. But what matters is that the system needs to be secure. Maybe it isn't going to be any of the people who work with the company now. It might be an intern. It might be that new hire your company pulled from a competitor. It could be the janitor. In a similar situation, I would say that it is a matter of ensuring that if someone should want to steal your company's intellectual property, you are going to make it as near impossible as is feasible, rather than saying you don't trust current and future employees. Wing. On 10/25/05, Wing Wong wrote: > > > From Previous Post: > > > > > Your points are valid and we've been thinking about them all. What I > > am considering is a firewalled network for code development that only > > allows connections from specific thin clients (I should be able to > > allow only specific mac addresses to connect just like a wireless > > node, no?). We are also considering a separate desktop for the users > > to check email, internet access, etc. but what prevents them from > > just taking the time to copy the data from the isolated network to > > the other network. At some point you have to trust that your source > > code is safe with your new employees, but I think that might be too > > cautious of an approach. > > > > We'd like to limit the access to the code and try like heck to keep it > > from getting out....which is a huge task and probably not possible. > > > > Brian. > > > > > [ warning : long post ] > > Mac addresses can be cloned, so mac address filtering is pretty pointless. > Google the internet for articles about getting into wifi access points and > you will see notes about Mac address cloning. > > Your best bet would be to have a VPN setup on your network. The coders are > on one VPN and the public access terminals for email/etc are on a seperate > VPN. That way, the only way anyone is able to do anything on your network is > if they are authenticated against one of the VPNs. Just plugging a > computer/laptop into your network won't get them anywhere. This will prevent > code from walking. > > Note: The developer VPN should have its own email server for internal only > emails. That way, the developers can email one another code and notes, but > the email has no chance of ever entering the public networks/internet. Same > for word processing, printing, etc. > > One way to do this is: > > Setup your various VPN networks so that developers are isolated from the > rest of the world, since theft of IP seems to be a concern. Have a VMware > ACE setup to create limited access images of Windows for developers to use. > Have development data on a central server, not on the images. All changes to > the thinclient images are undone when the system is rebooted or the user > logs out. USB, PCMCIA, FW, CDROM, SOUND, etc are disabled on the thinclient > machine image. The Image contains the VPN software to authenticate against > the Developer network, but requires a developer to login. > > Instead of ACE, you can also use a stripped down and hardened PXE-booted > Linux to run VMware player. Use that to run restricted VMware images served > by your central server. The Linux image can have the USB, CDROM, PCMCIA, etc > modules unloaded or not compile in so that the developer/user won't have > access to it from Linux or VMware/Windows. > > Ultimately, if your developers are looking to steal your info, they can > always bring in a digicam to photograph snippets of code/etc. They could > bridge the private and public networks to copy data. They could work with > someone who manages to the networks to bridge the networks physically. They > could steal a backup tape. Depending on the code they are developing, they > could even embed the source code into the compiled application for redumping > later. > > They could even bridge the desktop and the thin client with a serial cable > or parallel port cable to do a system-to-system copy. I mean... they are > developers, it isn't hard to write a simple utility or download a public one > to do a serial/parallel cable transfer. With a custom LED/photo-diode > device, you could, in theory, use the monitor to export data serially or > parallel. (Might be a nice hobby project, actually.) > > > If the thinclient needs to be secure, then it should store NO information > and have no means to input/output other than the screen and the > keyboard/mouse. The system should stop working if it is unplugged from the > network and require re-authentication to prevent cached data from being > copied to another computer(thinclient+ramdrive => laptop via cross-over > cable). Ie, if the thinclient's OS detects it isn't in contact with the > central server, it should wipe it's local ramdisk and shutdown. > > The desktop/workstation should similarly be restricted and limited, but > via a different network and different central server. "Maybe" have USB/CDROM > access since it is for normal office work, but it should definitely not have > any means to connect with the thin client in any way. > > Assume that the BIOS can be compromised. Passwords can be reset. So a > normal machine plugged into your network will get nothing except the > PXE-boot/dhcp information to load a highly restricted image which will not > access the hard drive, cdrom, usb, flash, pcmcia, serial, parallel, > infrared, bluetooth, wifi, or sound ports. > > Regarding the "thinpathsystems.com " X > terminal product, it makes use of the local hard disk. So once you have > installed it once, there is very little to prevent it from being compromised > to allow copying data to another machine from hooking up to it and copying > data from it. > > Seriously, virtualize the OS. This allows you to lock down the hardware at > 2 levels: the host OS(Linux) can disable drivers to the various hardware > ports, so that even if the system HAD a hard drive in it, it won't be used, > and the GUEST OS ala VMware Player(Windows), where it has no access to the > HOST OS's devices, which aren't available, and the VMware instance is > further disabled. > > If they manage to hack the Windows Guest OS, the Linux underlying OS won't > let them write to anything or transmit anywhere. If they manage to hack the > underlying Linux OS, there is nowhere to write programs to since the system > isn't compiled with support for local storage or local buses. > VMware Player can even limit which shared folders are available. > > If they disconnect the network, you can encode the Linux distro to > basically wipe the ram drive on the thinclient via a heartbeat with a > central server. No return beats in say 5 seconds and the ethernet link is > down? We've been disconnected, wipe it and shutdown. Mitigated risk to > cached data theft. Since the saved data is stored on a NFS/CIFS/CVS central > server, no data loss. Since the OS is booting from a remote image, no OS > corruption. > > It might be a bit more involved than a straightforward > firewall/VPN/segmented network approach or an X11 thinclient approach, but > you get alot more control while being able to provide a "full" OS to the > developers to work on. You can also maintain different revisions of > workstation images,should someone need to work on a particular OS revision > or a different set of development tools. > > The VMware ACE route has a higher price tag, but is a single bundled > package. > The Linux+VmwarePlayer+VMwareWorkstation route is cheaper, but requires a > little more admin experience/knowledge. > > But both options will mitigate the risk of developers walking off with > information on their laptops, portable media, etc... when properly > configured. > > How much protection you need depends on what the requirements are for the > project. > > Wing. > > -- > Wing Wong > wingedpower at gmail.com > -- Wing Wong wingedpower at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From wingedpower at gmail.com Tue Oct 25 12:04:50 2005 From: wingedpower at gmail.com (Wing Wong) Date: Tue, 25 Oct 2005 12:04:50 -0700 Subject: Thin Client solutions In-Reply-To: <24BD2D5F3CEF4F4780606124741B48169969@hq-ex-7.brocade.com> References: <24BD2D5F3CEF4F4780606124741B48169969@hq-ex-7.brocade.com> Message-ID: <7097bd8c0510251204m4377496g831e71a8bb27c2e6@mail.gmail.com> >From Previous Post: > > Your points are valid and we've been thinking about them all. What I > am considering is a firewalled network for code development that only > allows connections from specific thin clients (I should be able to > allow only specific mac addresses to connect just like a wireless > node, no?). We are also considering a separate desktop for the users > to check email, internet access, etc. but what prevents them from > just taking the time to copy the data from the isolated network to > the other network. At some point you have to trust that your source > code is safe with your new employees, but I think that might be too > cautious of an approach. > > We'd like to limit the access to the code and try like heck to keep it > from getting out....which is a huge task and probably not possible. > > Brian. > > [ warning : long post ] Mac addresses can be cloned, so mac address filtering is pretty pointless. Google the internet for articles about getting into wifi access points and you will see notes about Mac address cloning. Your best bet would be to have a VPN setup on your network. The coders are on one VPN and the public access terminals for email/etc are on a seperate VPN. That way, the only way anyone is able to do anything on your network is if they are authenticated against one of the VPNs. Just plugging a computer/laptop into your network won't get them anywhere. This will prevent code from walking. Note: The developer VPN should have its own email server for internal only emails. That way, the developers can email one another code and notes, but the email has no chance of ever entering the public networks/internet. Same for word processing, printing, etc. One way to do this is: Setup your various VPN networks so that developers are isolated from the rest of the world, since theft of IP seems to be a concern. Have a VMware ACE setup to create limited access images of Windows for developers to use. Have development data on a central server, not on the images. All changes to the thinclient images are undone when the system is rebooted or the user logs out. USB, PCMCIA, FW, CDROM, SOUND, etc are disabled on the thinclient machine image. The Image contains the VPN software to authenticate against the Developer network, but requires a developer to login. Instead of ACE, you can also use a stripped down and hardened PXE-booted Linux to run VMware player. Use that to run restricted VMware images served by your central server. The Linux image can have the USB, CDROM, PCMCIA, etc modules unloaded or not compile in so that the developer/user won't have access to it from Linux or VMware/Windows. Ultimately, if your developers are looking to steal your info, they can always bring in a digicam to photograph snippets of code/etc. They could bridge the private and public networks to copy data. They could work with someone who manages to the networks to bridge the networks physically. They could steal a backup tape. Depending on the code they are developing, they could even embed the source code into the compiled application for redumping later. They could even bridge the desktop and the thin client with a serial cable or parallel port cable to do a system-to-system copy. I mean... they are developers, it isn't hard to write a simple utility or download a public one to do a serial/parallel cable transfer. With a custom LED/photo-diode device, you could, in theory, use the monitor to export data serially or parallel. (Might be a nice hobby project, actually.) If the thinclient needs to be secure, then it should store NO information and have no means to input/output other than the screen and the keyboard/mouse. The system should stop working if it is unplugged from the network and require re-authentication to prevent cached data from being copied to another computer(thinclient+ramdrive => laptop via cross-over cable). Ie, if the thinclient's OS detects it isn't in contact with the central server, it should wipe it's local ramdisk and shutdown. The desktop/workstation should similarly be restricted and limited, but via a different network and different central server. "Maybe" have USB/CDROM access since it is for normal office work, but it should definitely not have any means to connect with the thin client in any way. Assume that the BIOS can be compromised. Passwords can be reset. So a normal machine plugged into your network will get nothing except the PXE-boot/dhcp information to load a highly restricted image which will not access the hard drive, cdrom, usb, flash, pcmcia, serial, parallel, infrared, bluetooth, wifi, or sound ports. Regarding the "thinpathsystems.com " X terminal product, it makes use of the local hard disk. So once you have installed it once, there is very little to prevent it from being compromised to allow copying data to another machine from hooking up to it and copying data from it. Seriously, virtualize the OS. This allows you to lock down the hardware at 2 levels: the host OS(Linux) can disable drivers to the various hardware ports, so that even if the system HAD a hard drive in it, it won't be used, and the GUEST OS ala VMware Player(Windows), where it has no access to the HOST OS's devices, which aren't available, and the VMware instance is further disabled. If they manage to hack the Windows Guest OS, the Linux underlying OS won't let them write to anything or transmit anywhere. If they manage to hack the underlying Linux OS, there is nowhere to write programs to since the system isn't compiled with support for local storage or local buses. VMware Player can even limit which shared folders are available. If they disconnect the network, you can encode the Linux distro to basically wipe the ram drive on the thinclient via a heartbeat with a central server. No return beats in say 5 seconds and the ethernet link is down? We've been disconnected, wipe it and shutdown. Mitigated risk to cached data theft. Since the saved data is stored on a NFS/CIFS/CVS central server, no data loss. Since the OS is booting from a remote image, no OS corruption. It might be a bit more involved than a straightforward firewall/VPN/segmented network approach or an X11 thinclient approach, but you get alot more control while being able to provide a "full" OS to the developers to work on. You can also maintain different revisions of workstation images,should someone need to work on a particular OS revision or a different set of development tools. The VMware ACE route has a higher price tag, but is a single bundled package. The Linux+VmwarePlayer+VMwareWorkstation route is cheaper, but requires a little more admin experience/knowledge. But both options will mitigate the risk of developers walking off with information on their laptops, portable media, etc... when properly configured. How much protection you need depends on what the requirements are for the project. Wing. -- Wing Wong wingedpower at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From wingedpower at gmail.com Tue Oct 25 12:15:20 2005 From: wingedpower at gmail.com (Wing Wong) Date: Tue, 25 Oct 2005 12:15:20 -0700 Subject: Thin Client solutions In-Reply-To: <7097bd8c0510251204m4377496g831e71a8bb27c2e6@mail.gmail.com> References: <24BD2D5F3CEF4F4780606124741B48169969@hq-ex-7.brocade.com> <7097bd8c0510251204m4377496g831e71a8bb27c2e6@mail.gmail.com> Message-ID: <7097bd8c0510251215p4a351d8xb076de48a68f74b5@mail.gmail.com> Regarding "At some point you have to trust that your source code is safe with your new employees...", I would say that that won't hold water with your employers if something goes wrong and code leaks. It is better to say, "This failed and can be fixed to prevent future breeches" than to say, "We thought we could trust them with the code." They could all be your friends. They could be people you don't know. They could be employees of some years. But what matters is that the system needs to be secure. Maybe it isn't going to be any of the people who work with the company now. It might be an intern. It might be that new hire your company pulled from a competitor. It could be the janitor. In a similar situation, I would say that it is a matter of ensuring that if someone should want to steal your company's intellectual property, you are going to make it as near impossible as is feasible, rather than saying you don't trust current and future employees. Wing. On 10/25/05, Wing Wong wrote: > > > From Previous Post: > > > > > Your points are valid and we've been thinking about them all. What I > > am considering is a firewalled network for code development that only > > allows connections from specific thin clients (I should be able to > > allow only specific mac addresses to connect just like a wireless > > node, no?). We are also considering a separate desktop for the users > > to check email, internet access, etc. but what prevents them from > > just taking the time to copy the data from the isolated network to > > the other network. At some point you have to trust that your source > > code is safe with your new employees, but I think that might be too > > cautious of an approach. > > > > We'd like to limit the access to the code and try like heck to keep it > > from getting out....which is a huge task and probably not possible. > > > > Brian. > > > > > [ warning : long post ] > > Mac addresses can be cloned, so mac address filtering is pretty pointless. > Google the internet for articles about getting into wifi access points and > you will see notes about Mac address cloning. > > Your best bet would be to have a VPN setup on your network. The coders are > on one VPN and the public access terminals for email/etc are on a seperate > VPN. That way, the only way anyone is able to do anything on your network is > if they are authenticated against one of the VPNs. Just plugging a > computer/laptop into your network won't get them anywhere. This will prevent > code from walking. > > Note: The developer VPN should have its own email server for internal only > emails. That way, the developers can email one another code and notes, but > the email has no chance of ever entering the public networks/internet. Same > for word processing, printing, etc. > > One way to do this is: > > Setup your various VPN networks so that developers are isolated from the > rest of the world, since theft of IP seems to be a concern. Have a VMware > ACE setup to create limited access images of Windows for developers to use. > Have development data on a central server, not on the images. All changes to > the thinclient images are undone when the system is rebooted or the user > logs out. USB, PCMCIA, FW, CDROM, SOUND, etc are disabled on the thinclient > machine image. The Image contains the VPN software to authenticate against > the Developer network, but requires a developer to login. > > Instead of ACE, you can also use a stripped down and hardened PXE-booted > Linux to run VMware player. Use that to run restricted VMware images served > by your central server. The Linux image can have the USB, CDROM, PCMCIA, etc > modules unloaded or not compile in so that the developer/user won't have > access to it from Linux or VMware/Windows. > > Ultimately, if your developers are looking to steal your info, they can > always bring in a digicam to photograph snippets of code/etc. They could > bridge the private and public networks to copy data. They could work with > someone who manages to the networks to bridge the networks physically. They > could steal a backup tape. Depending on the code they are developing, they > could even embed the source code into the compiled application for redumping > later. > > They could even bridge the desktop and the thin client with a serial cable > or parallel port cable to do a system-to-system copy. I mean... they are > developers, it isn't hard to write a simple utility or download a public one > to do a serial/parallel cable transfer. With a custom LED/photo-diode > device, you could, in theory, use the monitor to export data serially or > parallel. (Might be a nice hobby project, actually.) > > > If the thinclient needs to be secure, then it should store NO information > and have no means to input/output other than the screen and the > keyboard/mouse. The system should stop working if it is unplugged from the > network and require re-authentication to prevent cached data from being > copied to another computer(thinclient+ramdrive => laptop via cross-over > cable). Ie, if the thinclient's OS detects it isn't in contact with the > central server, it should wipe it's local ramdisk and shutdown. > > The desktop/workstation should similarly be restricted and limited, but > via a different network and different central server. "Maybe" have USB/CDROM > access since it is for normal office work, but it should definitely not have > any means to connect with the thin client in any way. > > Assume that the BIOS can be compromised. Passwords can be reset. So a > normal machine plugged into your network will get nothing except the > PXE-boot/dhcp information to load a highly restricted image which will not > access the hard drive, cdrom, usb, flash, pcmcia, serial, parallel, > infrared, bluetooth, wifi, or sound ports. > > Regarding the "thinpathsystems.com " X > terminal product, it makes use of the local hard disk. So once you have > installed it once, there is very little to prevent it from being compromised > to allow copying data to another machine from hooking up to it and copying > data from it. > > Seriously, virtualize the OS. This allows you to lock down the hardware at > 2 levels: the host OS(Linux) can disable drivers to the various hardware > ports, so that even if the system HAD a hard drive in it, it won't be used, > and the GUEST OS ala VMware Player(Windows), where it has no access to the > HOST OS's devices, which aren't available, and the VMware instance is > further disabled. > > If they manage to hack the Windows Guest OS, the Linux underlying OS won't > let them write to anything or transmit anywhere. If they manage to hack the > underlying Linux OS, there is nowhere to write programs to since the system > isn't compiled with support for local storage or local buses. > VMware Player can even limit which shared folders are available. > > If they disconnect the network, you can encode the Linux distro to > basically wipe the ram drive on the thinclient via a heartbeat with a > central server. No return beats in say 5 seconds and the ethernet link is > down? We've been disconnected, wipe it and shutdown. Mitigated risk to > cached data theft. Since the saved data is stored on a NFS/CIFS/CVS central > server, no data loss. Since the OS is booting from a remote image, no OS > corruption. > > It might be a bit more involved than a straightforward > firewall/VPN/segmented network approach or an X11 thinclient approach, but > you get alot more control while being able to provide a "full" OS to the > developers to work on. You can also maintain different revisions of > workstation images,should someone need to work on a particular OS revision > or a different set of development tools. > > The VMware ACE route has a higher price tag, but is a single bundled > package. > The Linux+VmwarePlayer+VMwareWorkstation route is cheaper, but requires a > little more admin experience/knowledge. > > But both options will mitigate the risk of developers walking off with > information on their laptops, portable media, etc... when properly > configured. > > How much protection you need depends on what the requirements are for the > project. > > Wing. > > -- > Wing Wong > wingedpower at gmail.com > -- Wing Wong wingedpower at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From wingedpower at gmail.com Tue Oct 25 12:04:50 2005 From: wingedpower at gmail.com (Wing Wong) Date: Tue, 25 Oct 2005 12:04:50 -0700 Subject: Thin Client solutions In-Reply-To: <24BD2D5F3CEF4F4780606124741B48169969@hq-ex-7.brocade.com> References: <24BD2D5F3CEF4F4780606124741B48169969@hq-ex-7.brocade.com> Message-ID: <7097bd8c0510251204m4377496g831e71a8bb27c2e6@mail.gmail.com> >From Previous Post: > > Your points are valid and we've been thinking about them all. What I > am considering is a firewalled network for code development that only > allows connections from specific thin clients (I should be able to > allow only specific mac addresses to connect just like a wireless > node, no?). We are also considering a separate desktop for the users > to check email, internet access, etc. but what prevents them from > just taking the time to copy the data from the isolated network to > the other network. At some point you have to trust that your source > code is safe with your new employees, but I think that might be too > cautious of an approach. > > We'd like to limit the access to the code and try like heck to keep it > from getting out....which is a huge task and probably not possible. > > Brian. > > [ warning : long post ] Mac addresses can be cloned, so mac address filtering is pretty pointless. Google the internet for articles about getting into wifi access points and you will see notes about Mac address cloning. Your best bet would be to have a VPN setup on your network. The coders are on one VPN and the public access terminals for email/etc are on a seperate VPN. That way, the only way anyone is able to do anything on your network is if they are authenticated against one of the VPNs. Just plugging a computer/laptop into your network won't get them anywhere. This will prevent code from walking. Note: The developer VPN should have its own email server for internal only emails. That way, the developers can email one another code and notes, but the email has no chance of ever entering the public networks/internet. Same for word processing, printing, etc. One way to do this is: Setup your various VPN networks so that developers are isolated from the rest of the world, since theft of IP seems to be a concern. Have a VMware ACE setup to create limited access images of Windows for developers to use. Have development data on a central server, not on the images. All changes to the thinclient images are undone when the system is rebooted or the user logs out. USB, PCMCIA, FW, CDROM, SOUND, etc are disabled on the thinclient machine image. The Image contains the VPN software to authenticate against the Developer network, but requires a developer to login. Instead of ACE, you can also use a stripped down and hardened PXE-booted Linux to run VMware player. Use that to run restricted VMware images served by your central server. The Linux image can have the USB, CDROM, PCMCIA, etc modules unloaded or not compile in so that the developer/user won't have access to it from Linux or VMware/Windows. Ultimately, if your developers are looking to steal your info, they can always bring in a digicam to photograph snippets of code/etc. They could bridge the private and public networks to copy data. They could work with someone who manages to the networks to bridge the networks physically. They could steal a backup tape. Depending on the code they are developing, they could even embed the source code into the compiled application for redumping later. They could even bridge the desktop and the thin client with a serial cable or parallel port cable to do a system-to-system copy. I mean... they are developers, it isn't hard to write a simple utility or download a public one to do a serial/parallel cable transfer. With a custom LED/photo-diode device, you could, in theory, use the monitor to export data serially or parallel. (Might be a nice hobby project, actually.) If the thinclient needs to be secure, then it should store NO information and have no means to input/output other than the screen and the keyboard/mouse. The system should stop working if it is unplugged from the network and require re-authentication to prevent cached data from being copied to another computer(thinclient+ramdrive => laptop via cross-over cable). Ie, if the thinclient's OS detects it isn't in contact with the central server, it should wipe it's local ramdisk and shutdown. The desktop/workstation should similarly be restricted and limited, but via a different network and different central server. "Maybe" have USB/CDROM access since it is for normal office work, but it should definitely not have any means to connect with the thin client in any way. Assume that the BIOS can be compromised. Passwords can be reset. So a normal machine plugged into your network will get nothing except the PXE-boot/dhcp information to load a highly restricted image which will not access the hard drive, cdrom, usb, flash, pcmcia, serial, parallel, infrared, bluetooth, wifi, or sound ports. Regarding the "thinpathsystems.com " X terminal product, it makes use of the local hard disk. So once you have installed it once, there is very little to prevent it from being compromised to allow copying data to another machine from hooking up to it and copying data from it. Seriously, virtualize the OS. This allows you to lock down the hardware at 2 levels: the host OS(Linux) can disable drivers to the various hardware ports, so that even if the system HAD a hard drive in it, it won't be used, and the GUEST OS ala VMware Player(Windows), where it has no access to the HOST OS's devices, which aren't available, and the VMware instance is further disabled. If they manage to hack the Windows Guest OS, the Linux underlying OS won't let them write to anything or transmit anywhere. If they manage to hack the underlying Linux OS, there is nowhere to write programs to since the system isn't compiled with support for local storage or local buses. VMware Player can even limit which shared folders are available. If they disconnect the network, you can encode the Linux distro to basically wipe the ram drive on the thinclient via a heartbeat with a central server. No return beats in say 5 seconds and the ethernet link is down? We've been disconnected, wipe it and shutdown. Mitigated risk to cached data theft. Since the saved data is stored on a NFS/CIFS/CVS central server, no data loss. Since the OS is booting from a remote image, no OS corruption. It might be a bit more involved than a straightforward firewall/VPN/segmented network approach or an X11 thinclient approach, but you get alot more control while being able to provide a "full" OS to the developers to work on. You can also maintain different revisions of workstation images,should someone need to work on a particular OS revision or a different set of development tools. The VMware ACE route has a higher price tag, but is a single bundled package. The Linux+VmwarePlayer+VMwareWorkstation route is cheaper, but requires a little more admin experience/knowledge. But both options will mitigate the risk of developers walking off with information on their laptops, portable media, etc... when properly configured. How much protection you need depends on what the requirements are for the project. Wing. -- Wing Wong wingedpower at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From wingedpower at gmail.com Tue Oct 25 12:04:50 2005 From: wingedpower at gmail.com (Wing Wong) Date: Tue, 25 Oct 2005 12:04:50 -0700 Subject: Thin Client solutions In-Reply-To: <24BD2D5F3CEF4F4780606124741B48169969@hq-ex-7.brocade.com> References: <24BD2D5F3CEF4F4780606124741B48169969@hq-ex-7.brocade.com> Message-ID: <7097bd8c0510251204m4377496g831e71a8bb27c2e6@mail.gmail.com> >From Previous Post: > > Your points are valid and we've been thinking about them all. What I > am considering is a firewalled network for code development that only > allows connections from specific thin clients (I should be able to > allow only specific mac addresses to connect just like a wireless > node, no?). We are also considering a separate desktop for the users > to check email, internet access, etc. but what prevents them from > just taking the time to copy the data from the isolated network to > the other network. At some point you have to trust that your source > code is safe with your new employees, but I think that might be too > cautious of an approach. > > We'd like to limit the access to the code and try like heck to keep it > from getting out....which is a huge task and probably not possible. > > Brian. > > [ warning : long post ] Mac addresses can be cloned, so mac address filtering is pretty pointless. Google the internet for articles about getting into wifi access points and you will see notes about Mac address cloning. Your best bet would be to have a VPN setup on your network. The coders are on one VPN and the public access terminals for email/etc are on a seperate VPN. That way, the only way anyone is able to do anything on your network is if they are authenticated against one of the VPNs. Just plugging a computer/laptop into your network won't get them anywhere. This will prevent code from walking. Note: The developer VPN should have its own email server for internal only emails. That way, the developers can email one another code and notes, but the email has no chance of ever entering the public networks/internet. Same for word processing, printing, etc. One way to do this is: Setup your various VPN networks so that developers are isolated from the rest of the world, since theft of IP seems to be a concern. Have a VMware ACE setup to create limited access images of Windows for developers to use. Have development data on a central server, not on the images. All changes to the thinclient images are undone when the system is rebooted or the user logs out. USB, PCMCIA, FW, CDROM, SOUND, etc are disabled on the thinclient machine image. The Image contains the VPN software to authenticate against the Developer network, but requires a developer to login. Instead of ACE, you can also use a stripped down and hardened PXE-booted Linux to run VMware player. Use that to run restricted VMware images served by your central server. The Linux image can have the USB, CDROM, PCMCIA, etc modules unloaded or not compile in so that the developer/user won't have access to it from Linux or VMware/Windows. Ultimately, if your developers are looking to steal your info, they can always bring in a digicam to photograph snippets of code/etc. They could bridge the private and public networks to copy data. They could work with someone who manages to the networks to bridge the networks physically. They could steal a backup tape. Depending on the code they are developing, they could even embed the source code into the compiled application for redumping later. They could even bridge the desktop and the thin client with a serial cable or parallel port cable to do a system-to-system copy. I mean... they are developers, it isn't hard to write a simple utility or download a public one to do a serial/parallel cable transfer. With a custom LED/photo-diode device, you could, in theory, use the monitor to export data serially or parallel. (Might be a nice hobby project, actually.) If the thinclient needs to be secure, then it should store NO information and have no means to input/output other than the screen and the keyboard/mouse. The system should stop working if it is unplugged from the network and require re-authentication to prevent cached data from being copied to another computer(thinclient+ramdrive => laptop via cross-over cable). Ie, if the thinclient's OS detects it isn't in contact with the central server, it should wipe it's local ramdisk and shutdown. The desktop/workstation should similarly be restricted and limited, but via a different network and different central server. "Maybe" have USB/CDROM access since it is for normal office work, but it should definitely not have any means to connect with the thin client in any way. Assume that the BIOS can be compromised. Passwords can be reset. So a normal machine plugged into your network will get nothing except the PXE-boot/dhcp information to load a highly restricted image which will not access the hard drive, cdrom, usb, flash, pcmcia, serial, parallel, infrared, bluetooth, wifi, or sound ports. Regarding the "thinpathsystems.com " X terminal product, it makes use of the local hard disk. So once you have installed it once, there is very little to prevent it from being compromised to allow copying data to another machine from hooking up to it and copying data from it. Seriously, virtualize the OS. This allows you to lock down the hardware at 2 levels: the host OS(Linux) can disable drivers to the various hardware ports, so that even if the system HAD a hard drive in it, it won't be used, and the GUEST OS ala VMware Player(Windows), where it has no access to the HOST OS's devices, which aren't available, and the VMware instance is further disabled. If they manage to hack the Windows Guest OS, the Linux underlying OS won't let them write to anything or transmit anywhere. If they manage to hack the underlying Linux OS, there is nowhere to write programs to since the system isn't compiled with support for local storage or local buses. VMware Player can even limit which shared folders are available. If they disconnect the network, you can encode the Linux distro to basically wipe the ram drive on the thinclient via a heartbeat with a central server. No return beats in say 5 seconds and the ethernet link is down? We've been disconnected, wipe it and shutdown. Mitigated risk to cached data theft. Since the saved data is stored on a NFS/CIFS/CVS central server, no data loss. Since the OS is booting from a remote image, no OS corruption. It might be a bit more involved than a straightforward firewall/VPN/segmented network approach or an X11 thinclient approach, but you get alot more control while being able to provide a "full" OS to the developers to work on. You can also maintain different revisions of workstation images,should someone need to work on a particular OS revision or a different set of development tools. The VMware ACE route has a higher price tag, but is a single bundled package. The Linux+VmwarePlayer+VMwareWorkstation route is cheaper, but requires a little more admin experience/knowledge. But both options will mitigate the risk of developers walking off with information on their laptops, portable media, etc... when properly configured. How much protection you need depends on what the requirements are for the project. Wing. -- Wing Wong wingedpower at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From wingedpower at gmail.com Tue Oct 25 12:15:20 2005 From: wingedpower at gmail.com (Wing Wong) Date: Tue, 25 Oct 2005 12:15:20 -0700 Subject: Thin Client solutions In-Reply-To: <7097bd8c0510251204m4377496g831e71a8bb27c2e6@mail.gmail.com> References: <24BD2D5F3CEF4F4780606124741B48169969@hq-ex-7.brocade.com> <7097bd8c0510251204m4377496g831e71a8bb27c2e6@mail.gmail.com> Message-ID: <7097bd8c0510251215p4a351d8xb076de48a68f74b5@mail.gmail.com> Regarding "At some point you have to trust that your source code is safe with your new employees...", I would say that that won't hold water with your employers if something goes wrong and code leaks. It is better to say, "This failed and can be fixed to prevent future breeches" than to say, "We thought we could trust them with the code." They could all be your friends. They could be people you don't know. They could be employees of some years. But what matters is that the system needs to be secure. Maybe it isn't going to be any of the people who work with the company now. It might be an intern. It might be that new hire your company pulled from a competitor. It could be the janitor. In a similar situation, I would say that it is a matter of ensuring that if someone should want to steal your company's intellectual property, you are going to make it as near impossible as is feasible, rather than saying you don't trust current and future employees. Wing. On 10/25/05, Wing Wong wrote: > > > From Previous Post: > > > > > Your points are valid and we've been thinking about them all. What I > > am considering is a firewalled network for code development that only > > allows connections from specific thin clients (I should be able to > > allow only specific mac addresses to connect just like a wireless > > node, no?). We are also considering a separate desktop for the users > > to check email, internet access, etc. but what prevents them from > > just taking the time to copy the data from the isolated network to > > the other network. At some point you have to trust that your source > > code is safe with your new employees, but I think that might be too > > cautious of an approach. > > > > We'd like to limit the access to the code and try like heck to keep it > > from getting out....which is a huge task and probably not possible. > > > > Brian. > > > > > [ warning : long post ] > > Mac addresses can be cloned, so mac address filtering is pretty pointless. > Google the internet for articles about getting into wifi access points and > you will see notes about Mac address cloning. > > Your best bet would be to have a VPN setup on your network. The coders are > on one VPN and the public access terminals for email/etc are on a seperate > VPN. That way, the only way anyone is able to do anything on your network is > if they are authenticated against one of the VPNs. Just plugging a > computer/laptop into your network won't get them anywhere. This will prevent > code from walking. > > Note: The developer VPN should have its own email server for internal only > emails. That way, the developers can email one another code and notes, but > the email has no chance of ever entering the public networks/internet. Same > for word processing, printing, etc. > > One way to do this is: > > Setup your various VPN networks so that developers are isolated from the > rest of the world, since theft of IP seems to be a concern. Have a VMware > ACE setup to create limited access images of Windows for developers to use. > Have development data on a central server, not on the images. All changes to > the thinclient images are undone when the system is rebooted or the user > logs out. USB, PCMCIA, FW, CDROM, SOUND, etc are disabled on the thinclient > machine image. The Image contains the VPN software to authenticate against > the Developer network, but requires a developer to login. > > Instead of ACE, you can also use a stripped down and hardened PXE-booted > Linux to run VMware player. Use that to run restricted VMware images served > by your central server. The Linux image can have the USB, CDROM, PCMCIA, etc > modules unloaded or not compile in so that the developer/user won't have > access to it from Linux or VMware/Windows. > > Ultimately, if your developers are looking to steal your info, they can > always bring in a digicam to photograph snippets of code/etc. They could > bridge the private and public networks to copy data. They could work with > someone who manages to the networks to bridge the networks physically. They > could steal a backup tape. Depending on the code they are developing, they > could even embed the source code into the compiled application for redumping > later. > > They could even bridge the desktop and the thin client with a serial cable > or parallel port cable to do a system-to-system copy. I mean... they are > developers, it isn't hard to write a simple utility or download a public one > to do a serial/parallel cable transfer. With a custom LED/photo-diode > device, you could, in theory, use the monitor to export data serially or > parallel. (Might be a nice hobby project, actually.) > > > If the thinclient needs to be secure, then it should store NO information > and have no means to input/output other than the screen and the > keyboard/mouse. The system should stop working if it is unplugged from the > network and require re-authentication to prevent cached data from being > copied to another computer(thinclient+ramdrive => laptop via cross-over > cable). Ie, if the thinclient's OS detects it isn't in contact with the > central server, it should wipe it's local ramdisk and shutdown. > > The desktop/workstation should similarly be restricted and limited, but > via a different network and different central server. "Maybe" have USB/CDROM > access since it is for normal office work, but it should definitely not have > any means to connect with the thin client in any way. > > Assume that the BIOS can be compromised. Passwords can be reset. So a > normal machine plugged into your network will get nothing except the > PXE-boot/dhcp information to load a highly restricted image which will not > access the hard drive, cdrom, usb, flash, pcmcia, serial, parallel, > infrared, bluetooth, wifi, or sound ports. > > Regarding the "thinpathsystems.com " X > terminal product, it makes use of the local hard disk. So once you have > installed it once, there is very little to prevent it from being compromised > to allow copying data to another machine from hooking up to it and copying > data from it. > > Seriously, virtualize the OS. This allows you to lock down the hardware at > 2 levels: the host OS(Linux) can disable drivers to the various hardware > ports, so that even if the system HAD a hard drive in it, it won't be used, > and the GUEST OS ala VMware Player(Windows), where it has no access to the > HOST OS's devices, which aren't available, and the VMware instance is > further disabled. > > If they manage to hack the Windows Guest OS, the Linux underlying OS won't > let them write to anything or transmit anywhere. If they manage to hack the > underlying Linux OS, there is nowhere to write programs to since the system > isn't compiled with support for local storage or local buses. > VMware Player can even limit which shared folders are available. > > If they disconnect the network, you can encode the Linux distro to > basically wipe the ram drive on the thinclient via a heartbeat with a > central server. No return beats in say 5 seconds and the ethernet link is > down? We've been disconnected, wipe it and shutdown. Mitigated risk to > cached data theft. Since the saved data is stored on a NFS/CIFS/CVS central > server, no data loss. Since the OS is booting from a remote image, no OS > corruption. > > It might be a bit more involved than a straightforward > firewall/VPN/segmented network approach or an X11 thinclient approach, but > you get alot more control while being able to provide a "full" OS to the > developers to work on. You can also maintain different revisions of > workstation images,should someone need to work on a particular OS revision > or a different set of development tools. > > The VMware ACE route has a higher price tag, but is a single bundled > package. > The Linux+VmwarePlayer+VMwareWorkstation route is cheaper, but requires a > little more admin experience/knowledge. > > But both options will mitigate the risk of developers walking off with > information on their laptops, portable media, etc... when properly > configured. > > How much protection you need depends on what the requirements are for the > project. > > Wing. > > -- > Wing Wong > wingedpower at gmail.com > -- Wing Wong wingedpower at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From wingedpower at gmail.com Tue Oct 25 12:15:20 2005 From: wingedpower at gmail.com (Wing Wong) Date: Tue, 25 Oct 2005 12:15:20 -0700 Subject: Thin Client solutions In-Reply-To: <7097bd8c0510251204m4377496g831e71a8bb27c2e6@mail.gmail.com> References: <24BD2D5F3CEF4F4780606124741B48169969@hq-ex-7.brocade.com> <7097bd8c0510251204m4377496g831e71a8bb27c2e6@mail.gmail.com> Message-ID: <7097bd8c0510251215p4a351d8xb076de48a68f74b5@mail.gmail.com> Regarding "At some point you have to trust that your source code is safe with your new employees...", I would say that that won't hold water with your employers if something goes wrong and code leaks. It is better to say, "This failed and can be fixed to prevent future breeches" than to say, "We thought we could trust them with the code." They could all be your friends. They could be people you don't know. They could be employees of some years. But what matters is that the system needs to be secure. Maybe it isn't going to be any of the people who work with the company now. It might be an intern. It might be that new hire your company pulled from a competitor. It could be the janitor. In a similar situation, I would say that it is a matter of ensuring that if someone should want to steal your company's intellectual property, you are going to make it as near impossible as is feasible, rather than saying you don't trust current and future employees. Wing. On 10/25/05, Wing Wong wrote: > > > From Previous Post: > > > > > Your points are valid and we've been thinking about them all. What I > > am considering is a firewalled network for code development that only > > allows connections from specific thin clients (I should be able to > > allow only specific mac addresses to connect just like a wireless > > node, no?). We are also considering a separate desktop for the users > > to check email, internet access, etc. but what prevents them from > > just taking the time to copy the data from the isolated network to > > the other network. At some point you have to trust that your source > > code is safe with your new employees, but I think that might be too > > cautious of an approach. > > > > We'd like to limit the access to the code and try like heck to keep it > > from getting out....which is a huge task and probably not possible. > > > > Brian. > > > > > [ warning : long post ] > > Mac addresses can be cloned, so mac address filtering is pretty pointless. > Google the internet for articles about getting into wifi access points and > you will see notes about Mac address cloning. > > Your best bet would be to have a VPN setup on your network. The coders are > on one VPN and the public access terminals for email/etc are on a seperate > VPN. That way, the only way anyone is able to do anything on your network is > if they are authenticated against one of the VPNs. Just plugging a > computer/laptop into your network won't get them anywhere. This will prevent > code from walking. > > Note: The developer VPN should have its own email server for internal only > emails. That way, the developers can email one another code and notes, but > the email has no chance of ever entering the public networks/internet. Same > for word processing, printing, etc. > > One way to do this is: > > Setup your various VPN networks so that developers are isolated from the > rest of the world, since theft of IP seems to be a concern. Have a VMware > ACE setup to create limited access images of Windows for developers to use. > Have development data on a central server, not on the images. All changes to > the thinclient images are undone when the system is rebooted or the user > logs out. USB, PCMCIA, FW, CDROM, SOUND, etc are disabled on the thinclient > machine image. The Image contains the VPN software to authenticate against > the Developer network, but requires a developer to login. > > Instead of ACE, you can also use a stripped down and hardened PXE-booted > Linux to run VMware player. Use that to run restricted VMware images served > by your central server. The Linux image can have the USB, CDROM, PCMCIA, etc > modules unloaded or not compile in so that the developer/user won't have > access to it from Linux or VMware/Windows. > > Ultimately, if your developers are looking to steal your info, they can > always bring in a digicam to photograph snippets of code/etc. They could > bridge the private and public networks to copy data. They could work with > someone who manages to the networks to bridge the networks physically. They > could steal a backup tape. Depending on the code they are developing, they > could even embed the source code into the compiled application for redumping > later. > > They could even bridge the desktop and the thin client with a serial cable > or parallel port cable to do a system-to-system copy. I mean... they are > developers, it isn't hard to write a simple utility or download a public one > to do a serial/parallel cable transfer. With a custom LED/photo-diode > device, you could, in theory, use the monitor to export data serially or > parallel. (Might be a nice hobby project, actually.) > > > If the thinclient needs to be secure, then it should store NO information > and have no means to input/output other than the screen and the > keyboard/mouse. The system should stop working if it is unplugged from the > network and require re-authentication to prevent cached data from being > copied to another computer(thinclient+ramdrive => laptop via cross-over > cable). Ie, if the thinclient's OS detects it isn't in contact with the > central server, it should wipe it's local ramdisk and shutdown. > > The desktop/workstation should similarly be restricted and limited, but > via a different network and different central server. "Maybe" have USB/CDROM > access since it is for normal office work, but it should definitely not have > any means to connect with the thin client in any way. > > Assume that the BIOS can be compromised. Passwords can be reset. So a > normal machine plugged into your network will get nothing except the > PXE-boot/dhcp information to load a highly restricted image which will not > access the hard drive, cdrom, usb, flash, pcmcia, serial, parallel, > infrared, bluetooth, wifi, or sound ports. > > Regarding the "thinpathsystems.com " X > terminal product, it makes use of the local hard disk. So once you have > installed it once, there is very little to prevent it from being compromised > to allow copying data to another machine from hooking up to it and copying > data from it. > > Seriously, virtualize the OS. This allows you to lock down the hardware at > 2 levels: the host OS(Linux) can disable drivers to the various hardware > ports, so that even if the system HAD a hard drive in it, it won't be used, > and the GUEST OS ala VMware Player(Windows), where it has no access to the > HOST OS's devices, which aren't available, and the VMware instance is > further disabled. > > If they manage to hack the Windows Guest OS, the Linux underlying OS won't > let them write to anything or transmit anywhere. If they manage to hack the > underlying Linux OS, there is nowhere to write programs to since the system > isn't compiled with support for local storage or local buses. > VMware Player can even limit which shared folders are available. > > If they disconnect the network, you can encode the Linux distro to > basically wipe the ram drive on the thinclient via a heartbeat with a > central server. No return beats in say 5 seconds and the ethernet link is > down? We've been disconnected, wipe it and shutdown. Mitigated risk to > cached data theft. Since the saved data is stored on a NFS/CIFS/CVS central > server, no data loss. Since the OS is booting from a remote image, no OS > corruption. > > It might be a bit more involved than a straightforward > firewall/VPN/segmented network approach or an X11 thinclient approach, but > you get alot more control while being able to provide a "full" OS to the > developers to work on. You can also maintain different revisions of > workstation images,should someone need to work on a particular OS revision > or a different set of development tools. > > The VMware ACE route has a higher price tag, but is a single bundled > package. > The Linux+VmwarePlayer+VMwareWorkstation route is cheaper, but requires a > little more admin experience/knowledge. > > But both options will mitigate the risk of developers walking off with > information on their laptops, portable media, etc... when properly > configured. > > How much protection you need depends on what the requirements are for the > project. > > Wing. > > -- > Wing Wong > wingedpower at gmail.com > -- Wing Wong wingedpower at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From wingedpower at gmail.com Tue Oct 25 12:04:50 2005 From: wingedpower at gmail.com (Wing Wong) Date: Tue, 25 Oct 2005 12:04:50 -0700 Subject: Thin Client solutions In-Reply-To: <24BD2D5F3CEF4F4780606124741B48169969@hq-ex-7.brocade.com> References: <24BD2D5F3CEF4F4780606124741B48169969@hq-ex-7.brocade.com> Message-ID: <7097bd8c0510251204m4377496g831e71a8bb27c2e6@mail.gmail.com> >From Previous Post: > > Your points are valid and we've been thinking about them all. What I > am considering is a firewalled network for code development that only > allows connections from specific thin clients (I should be able to > allow only specific mac addresses to connect just like a wireless > node, no?). We are also considering a separate desktop for the users > to check email, internet access, etc. but what prevents them from > just taking the time to copy the data from the isolated network to > the other network. At some point you have to trust that your source > code is safe with your new employees, but I think that might be too > cautious of an approach. > > We'd like to limit the access to the code and try like heck to keep it > from getting out....which is a huge task and probably not possible. > > Brian. > > [ warning : long post ] Mac addresses can be cloned, so mac address filtering is pretty pointless. Google the internet for articles about getting into wifi access points and you will see notes about Mac address cloning. Your best bet would be to have a VPN setup on your network. The coders are on one VPN and the public access terminals for email/etc are on a seperate VPN. That way, the only way anyone is able to do anything on your network is if they are authenticated against one of the VPNs. Just plugging a computer/laptop into your network won't get them anywhere. This will prevent code from walking. Note: The developer VPN should have its own email server for internal only emails. That way, the developers can email one another code and notes, but the email has no chance of ever entering the public networks/internet. Same for word processing, printing, etc. One way to do this is: Setup your various VPN networks so that developers are isolated from the rest of the world, since theft of IP seems to be a concern. Have a VMware ACE setup to create limited access images of Windows for developers to use. Have development data on a central server, not on the images. All changes to the thinclient images are undone when the system is rebooted or the user logs out. USB, PCMCIA, FW, CDROM, SOUND, etc are disabled on the thinclient machine image. The Image contains the VPN software to authenticate against the Developer network, but requires a developer to login. Instead of ACE, you can also use a stripped down and hardened PXE-booted Linux to run VMware player. Use that to run restricted VMware images served by your central server. The Linux image can have the USB, CDROM, PCMCIA, etc modules unloaded or not compile in so that the developer/user won't have access to it from Linux or VMware/Windows. Ultimately, if your developers are looking to steal your info, they can always bring in a digicam to photograph snippets of code/etc. They could bridge the private and public networks to copy data. They could work with someone who manages to the networks to bridge the networks physically. They could steal a backup tape. Depending on the code they are developing, they could even embed the source code into the compiled application for redumping later. They could even bridge the desktop and the thin client with a serial cable or parallel port cable to do a system-to-system copy. I mean... they are developers, it isn't hard to write a simple utility or download a public one to do a serial/parallel cable transfer. With a custom LED/photo-diode device, you could, in theory, use the monitor to export data serially or parallel. (Might be a nice hobby project, actually.) If the thinclient needs to be secure, then it should store NO information and have no means to input/output other than the screen and the keyboard/mouse. The system should stop working if it is unplugged from the network and require re-authentication to prevent cached data from being copied to another computer(thinclient+ramdrive => laptop via cross-over cable). Ie, if the thinclient's OS detects it isn't in contact with the central server, it should wipe it's local ramdisk and shutdown. The desktop/workstation should similarly be restricted and limited, but via a different network and different central server. "Maybe" have USB/CDROM access since it is for normal office work, but it should definitely not have any means to connect with the thin client in any way. Assume that the BIOS can be compromised. Passwords can be reset. So a normal machine plugged into your network will get nothing except the PXE-boot/dhcp information to load a highly restricted image which will not access the hard drive, cdrom, usb, flash, pcmcia, serial, parallel, infrared, bluetooth, wifi, or sound ports. Regarding the "thinpathsystems.com " X terminal product, it makes use of the local hard disk. So once you have installed it once, there is very little to prevent it from being compromised to allow copying data to another machine from hooking up to it and copying data from it. Seriously, virtualize the OS. This allows you to lock down the hardware at 2 levels: the host OS(Linux) can disable drivers to the various hardware ports, so that even if the system HAD a hard drive in it, it won't be used, and the GUEST OS ala VMware Player(Windows), where it has no access to the HOST OS's devices, which aren't available, and the VMware instance is further disabled. If they manage to hack the Windows Guest OS, the Linux underlying OS won't let them write to anything or transmit anywhere. If they manage to hack the underlying Linux OS, there is nowhere to write programs to since the system isn't compiled with support for local storage or local buses. VMware Player can even limit which shared folders are available. If they disconnect the network, you can encode the Linux distro to basically wipe the ram drive on the thinclient via a heartbeat with a central server. No return beats in say 5 seconds and the ethernet link is down? We've been disconnected, wipe it and shutdown. Mitigated risk to cached data theft. Since the saved data is stored on a NFS/CIFS/CVS central server, no data loss. Since the OS is booting from a remote image, no OS corruption. It might be a bit more involved than a straightforward firewall/VPN/segmented network approach or an X11 thinclient approach, but you get alot more control while being able to provide a "full" OS to the developers to work on. You can also maintain different revisions of workstation images,should someone need to work on a particular OS revision or a different set of development tools. The VMware ACE route has a higher price tag, but is a single bundled package. The Linux+VmwarePlayer+VMwareWorkstation route is cheaper, but requires a little more admin experience/knowledge. But both options will mitigate the risk of developers walking off with information on their laptops, portable media, etc... when properly configured. How much protection you need depends on what the requirements are for the project. Wing. -- Wing Wong wingedpower at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From wingedpower at gmail.com Tue Oct 25 12:15:20 2005 From: wingedpower at gmail.com (Wing Wong) Date: Tue, 25 Oct 2005 12:15:20 -0700 Subject: Thin Client solutions In-Reply-To: <7097bd8c0510251204m4377496g831e71a8bb27c2e6@mail.gmail.com> References: <24BD2D5F3CEF4F4780606124741B48169969@hq-ex-7.brocade.com> <7097bd8c0510251204m4377496g831e71a8bb27c2e6@mail.gmail.com> Message-ID: <7097bd8c0510251215p4a351d8xb076de48a68f74b5@mail.gmail.com> Regarding "At some point you have to trust that your source code is safe with your new employees...", I would say that that won't hold water with your employers if something goes wrong and code leaks. It is better to say, "This failed and can be fixed to prevent future breeches" than to say, "We thought we could trust them with the code." They could all be your friends. They could be people you don't know. They could be employees of some years. But what matters is that the system needs to be secure. Maybe it isn't going to be any of the people who work with the company now. It might be an intern. It might be that new hire your company pulled from a competitor. It could be the janitor. In a similar situation, I would say that it is a matter of ensuring that if someone should want to steal your company's intellectual property, you are going to make it as near impossible as is feasible, rather than saying you don't trust current and future employees. Wing. On 10/25/05, Wing Wong wrote: > > > From Previous Post: > > > > > Your points are valid and we've been thinking about them all. What I > > am considering is a firewalled network for code development that only > > allows connections from specific thin clients (I should be able to > > allow only specific mac addresses to connect just like a wireless > > node, no?). We are also considering a separate desktop for the users > > to check email, internet access, etc. but what prevents them from > > just taking the time to copy the data from the isolated network to > > the other network. At some point you have to trust that your source > > code is safe with your new employees, but I think that might be too > > cautious of an approach. > > > > We'd like to limit the access to the code and try like heck to keep it > > from getting out....which is a huge task and probably not possible. > > > > Brian. > > > > > [ warning : long post ] > > Mac addresses can be cloned, so mac address filtering is pretty pointless. > Google the internet for articles about getting into wifi access points and > you will see notes about Mac address cloning. > > Your best bet would be to have a VPN setup on your network. The coders are > on one VPN and the public access terminals for email/etc are on a seperate > VPN. That way, the only way anyone is able to do anything on your network is > if they are authenticated against one of the VPNs. Just plugging a > computer/laptop into your network won't get them anywhere. This will prevent > code from walking. > > Note: The developer VPN should have its own email server for internal only > emails. That way, the developers can email one another code and notes, but > the email has no chance of ever entering the public networks/internet. Same > for word processing, printing, etc. > > One way to do this is: > > Setup your various VPN networks so that developers are isolated from the > rest of the world, since theft of IP seems to be a concern. Have a VMware > ACE setup to create limited access images of Windows for developers to use. > Have development data on a central server, not on the images. All changes to > the thinclient images are undone when the system is rebooted or the user > logs out. USB, PCMCIA, FW, CDROM, SOUND, etc are disabled on the thinclient > machine image. The Image contains the VPN software to authenticate against > the Developer network, but requires a developer to login. > > Instead of ACE, you can also use a stripped down and hardened PXE-booted > Linux to run VMware player. Use that to run restricted VMware images served > by your central server. The Linux image can have the USB, CDROM, PCMCIA, etc > modules unloaded or not compile in so that the developer/user won't have > access to it from Linux or VMware/Windows. > > Ultimately, if your developers are looking to steal your info, they can > always bring in a digicam to photograph snippets of code/etc. They could > bridge the private and public networks to copy data. They could work with > someone who manages to the networks to bridge the networks physically. They > could steal a backup tape. Depending on the code they are developing, they > could even embed the source code into the compiled application for redumping > later. > > They could even bridge the desktop and the thin client with a serial cable > or parallel port cable to do a system-to-system copy. I mean... they are > developers, it isn't hard to write a simple utility or download a public one > to do a serial/parallel cable transfer. With a custom LED/photo-diode > device, you could, in theory, use the monitor to export data serially or > parallel. (Might be a nice hobby project, actually.) > > > If the thinclient needs to be secure, then it should store NO information > and have no means to input/output other than the screen and the > keyboard/mouse. The system should stop working if it is unplugged from the > network and require re-authentication to prevent cached data from being > copied to another computer(thinclient+ramdrive => laptop via cross-over > cable). Ie, if the thinclient's OS detects it isn't in contact with the > central server, it should wipe it's local ramdisk and shutdown. > > The desktop/workstation should similarly be restricted and limited, but > via a different network and different central server. "Maybe" have USB/CDROM > access since it is for normal office work, but it should definitely not have > any means to connect with the thin client in any way. > > Assume that the BIOS can be compromised. Passwords can be reset. So a > normal machine plugged into your network will get nothing except the > PXE-boot/dhcp information to load a highly restricted image which will not > access the hard drive, cdrom, usb, flash, pcmcia, serial, parallel, > infrared, bluetooth, wifi, or sound ports. > > Regarding the "thinpathsystems.com " X > terminal product, it makes use of the local hard disk. So once you have > installed it once, there is very little to prevent it from being compromised > to allow copying data to another machine from hooking up to it and copying > data from it. > > Seriously, virtualize the OS. This allows you to lock down the hardware at > 2 levels: the host OS(Linux) can disable drivers to the various hardware > ports, so that even if the system HAD a hard drive in it, it won't be used, > and the GUEST OS ala VMware Player(Windows), where it has no access to the > HOST OS's devices, which aren't available, and the VMware instance is > further disabled. > > If they manage to hack the Windows Guest OS, the Linux underlying OS won't > let them write to anything or transmit anywhere. If they manage to hack the > underlying Linux OS, there is nowhere to write programs to since the system > isn't compiled with support for local storage or local buses. > VMware Player can even limit which shared folders are available. > > If they disconnect the network, you can encode the Linux distro to > basically wipe the ram drive on the thinclient via a heartbeat with a > central server. No return beats in say 5 seconds and the ethernet link is > down? We've been disconnected, wipe it and shutdown. Mitigated risk to > cached data theft. Since the saved data is stored on a NFS/CIFS/CVS central > server, no data loss. Since the OS is booting from a remote image, no OS > corruption. > > It might be a bit more involved than a straightforward > firewall/VPN/segmented network approach or an X11 thinclient approach, but > you get alot more control while being able to provide a "full" OS to the > developers to work on. You can also maintain different revisions of > workstation images,should someone need to work on a particular OS revision > or a different set of development tools. > > The VMware ACE route has a higher price tag, but is a single bundled > package. > The Linux+VmwarePlayer+VMwareWorkstation route is cheaper, but requires a > little more admin experience/knowledge. > > But both options will mitigate the risk of developers walking off with > information on their laptops, portable media, etc... when properly > configured. > > How much protection you need depends on what the requirements are for the > project. > > Wing. > > -- > Wing Wong > wingedpower at gmail.com > -- Wing Wong wingedpower at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From wingedpower at gmail.com Tue Oct 25 12:04:50 2005 From: wingedpower at gmail.com (Wing Wong) Date: Tue, 25 Oct 2005 12:04:50 -0700 Subject: Thin Client solutions In-Reply-To: <24BD2D5F3CEF4F4780606124741B48169969@hq-ex-7.brocade.com> References: <24BD2D5F3CEF4F4780606124741B48169969@hq-ex-7.brocade.com> Message-ID: <7097bd8c0510251204m4377496g831e71a8bb27c2e6@mail.gmail.com> >From Previous Post: > > Your points are valid and we've been thinking about them all. What I > am considering is a firewalled network for code development that only > allows connections from specific thin clients (I should be able to > allow only specific mac addresses to connect just like a wireless > node, no?). We are also considering a separate desktop for the users > to check email, internet access, etc. but what prevents them from > just taking the time to copy the data from the isolated network to > the other network. At some point you have to trust that your source > code is safe with your new employees, but I think that might be too > cautious of an approach. > > We'd like to limit the access to the code and try like heck to keep it > from getting out....which is a huge task and probably not possible. > > Brian. > > [ warning : long post ] Mac addresses can be cloned, so mac address filtering is pretty pointless. Google the internet for articles about getting into wifi access points and you will see notes about Mac address cloning. Your best bet would be to have a VPN setup on your network. The coders are on one VPN and the public access terminals for email/etc are on a seperate VPN. That way, the only way anyone is able to do anything on your network is if they are authenticated against one of the VPNs. Just plugging a computer/laptop into your network won't get them anywhere. This will prevent code from walking. Note: The developer VPN should have its own email server for internal only emails. That way, the developers can email one another code and notes, but the email has no chance of ever entering the public networks/internet. Same for word processing, printing, etc. One way to do this is: Setup your various VPN networks so that developers are isolated from the rest of the world, since theft of IP seems to be a concern. Have a VMware ACE setup to create limited access images of Windows for developers to use. Have development data on a central server, not on the images. All changes to the thinclient images are undone when the system is rebooted or the user logs out. USB, PCMCIA, FW, CDROM, SOUND, etc are disabled on the thinclient machine image. The Image contains the VPN software to authenticate against the Developer network, but requires a developer to login. Instead of ACE, you can also use a stripped down and hardened PXE-booted Linux to run VMware player. Use that to run restricted VMware images served by your central server. The Linux image can have the USB, CDROM, PCMCIA, etc modules unloaded or not compile in so that the developer/user won't have access to it from Linux or VMware/Windows. Ultimately, if your developers are looking to steal your info, they can always bring in a digicam to photograph snippets of code/etc. They could bridge the private and public networks to copy data. They could work with someone who manages to the networks to bridge the networks physically. They could steal a backup tape. Depending on the code they are developing, they could even embed the source code into the compiled application for redumping later. They could even bridge the desktop and the thin client with a serial cable or parallel port cable to do a system-to-system copy. I mean... they are developers, it isn't hard to write a simple utility or download a public one to do a serial/parallel cable transfer. With a custom LED/photo-diode device, you could, in theory, use the monitor to export data serially or parallel. (Might be a nice hobby project, actually.) If the thinclient needs to be secure, then it should store NO information and have no means to input/output other than the screen and the keyboard/mouse. The system should stop working if it is unplugged from the network and require re-authentication to prevent cached data from being copied to another computer(thinclient+ramdrive => laptop via cross-over cable). Ie, if the thinclient's OS detects it isn't in contact with the central server, it should wipe it's local ramdisk and shutdown. The desktop/workstation should similarly be restricted and limited, but via a different network and different central server. "Maybe" have USB/CDROM access since it is for normal office work, but it should definitely not have any means to connect with the thin client in any way. Assume that the BIOS can be compromised. Passwords can be reset. So a normal machine plugged into your network will get nothing except the PXE-boot/dhcp information to load a highly restricted image which will not access the hard drive, cdrom, usb, flash, pcmcia, serial, parallel, infrared, bluetooth, wifi, or sound ports. Regarding the "thinpathsystems.com " X terminal product, it makes use of the local hard disk. So once you have installed it once, there is very little to prevent it from being compromised to allow copying data to another machine from hooking up to it and copying data from it. Seriously, virtualize the OS. This allows you to lock down the hardware at 2 levels: the host OS(Linux) can disable drivers to the various hardware ports, so that even if the system HAD a hard drive in it, it won't be used, and the GUEST OS ala VMware Player(Windows), where it has no access to the HOST OS's devices, which aren't available, and the VMware instance is further disabled. If they manage to hack the Windows Guest OS, the Linux underlying OS won't let them write to anything or transmit anywhere. If they manage to hack the underlying Linux OS, there is nowhere to write programs to since the system isn't compiled with support for local storage or local buses. VMware Player can even limit which shared folders are available. If they disconnect the network, you can encode the Linux distro to basically wipe the ram drive on the thinclient via a heartbeat with a central server. No return beats in say 5 seconds and the ethernet link is down? We've been disconnected, wipe it and shutdown. Mitigated risk to cached data theft. Since the saved data is stored on a NFS/CIFS/CVS central server, no data loss. Since the OS is booting from a remote image, no OS corruption. It might be a bit more involved than a straightforward firewall/VPN/segmented network approach or an X11 thinclient approach, but you get alot more control while being able to provide a "full" OS to the developers to work on. You can also maintain different revisions of workstation images,should someone need to work on a particular OS revision or a different set of development tools. The VMware ACE route has a higher price tag, but is a single bundled package. The Linux+VmwarePlayer+VMwareWorkstation route is cheaper, but requires a little more admin experience/knowledge. But both options will mitigate the risk of developers walking off with information on their laptops, portable media, etc... when properly configured. How much protection you need depends on what the requirements are for the project. Wing. -- Wing Wong wingedpower at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From wingedpower at gmail.com Tue Oct 25 12:15:20 2005 From: wingedpower at gmail.com (Wing Wong) Date: Tue, 25 Oct 2005 12:15:20 -0700 Subject: Thin Client solutions In-Reply-To: <7097bd8c0510251204m4377496g831e71a8bb27c2e6@mail.gmail.com> References: <24BD2D5F3CEF4F4780606124741B48169969@hq-ex-7.brocade.com> <7097bd8c0510251204m4377496g831e71a8bb27c2e6@mail.gmail.com> Message-ID: <7097bd8c0510251215p4a351d8xb076de48a68f74b5@mail.gmail.com> Regarding "At some point you have to trust that your source code is safe with your new employees...", I would say that that won't hold water with your employers if something goes wrong and code leaks. It is better to say, "This failed and can be fixed to prevent future breeches" than to say, "We thought we could trust them with the code." They could all be your friends. They could be people you don't know. They could be employees of some years. But what matters is that the system needs to be secure. Maybe it isn't going to be any of the people who work with the company now. It might be an intern. It might be that new hire your company pulled from a competitor. It could be the janitor. In a similar situation, I would say that it is a matter of ensuring that if someone should want to steal your company's intellectual property, you are going to make it as near impossible as is feasible, rather than saying you don't trust current and future employees. Wing. On 10/25/05, Wing Wong wrote: > > > From Previous Post: > > > > > Your points are valid and we've been thinking about them all. What I > > am considering is a firewalled network for code development that only > > allows connections from specific thin clients (I should be able to > > allow only specific mac addresses to connect just like a wireless > > node, no?). We are also considering a separate desktop for the users > > to check email, internet access, etc. but what prevents them from > > just taking the time to copy the data from the isolated network to > > the other network. At some point you have to trust that your source > > code is safe with your new employees, but I think that might be too > > cautious of an approach. > > > > We'd like to limit the access to the code and try like heck to keep it > > from getting out....which is a huge task and probably not possible. > > > > Brian. > > > > > [ warning : long post ] > > Mac addresses can be cloned, so mac address filtering is pretty pointless. > Google the internet for articles about getting into wifi access points and > you will see notes about Mac address cloning. > > Your best bet would be to have a VPN setup on your network. The coders are > on one VPN and the public access terminals for email/etc are on a seperate > VPN. That way, the only way anyone is able to do anything on your network is > if they are authenticated against one of the VPNs. Just plugging a > computer/laptop into your network won't get them anywhere. This will prevent > code from walking. > > Note: The developer VPN should have its own email server for internal only > emails. That way, the developers can email one another code and notes, but > the email has no chance of ever entering the public networks/internet. Same > for word processing, printing, etc. > > One way to do this is: > > Setup your various VPN networks so that developers are isolated from the > rest of the world, since theft of IP seems to be a concern. Have a VMware > ACE setup to create limited access images of Windows for developers to use. > Have development data on a central server, not on the images. All changes to > the thinclient images are undone when the system is rebooted or the user > logs out. USB, PCMCIA, FW, CDROM, SOUND, etc are disabled on the thinclient > machine image. The Image contains the VPN software to authenticate against > the Developer network, but requires a developer to login. > > Instead of ACE, you can also use a stripped down and hardened PXE-booted > Linux to run VMware player. Use that to run restricted VMware images served > by your central server. The Linux image can have the USB, CDROM, PCMCIA, etc > modules unloaded or not compile in so that the developer/user won't have > access to it from Linux or VMware/Windows. > > Ultimately, if your developers are looking to steal your info, they can > always bring in a digicam to photograph snippets of code/etc. They could > bridge the private and public networks to copy data. They could work with > someone who manages to the networks to bridge the networks physically. They > could steal a backup tape. Depending on the code they are developing, they > could even embed the source code into the compiled application for redumping > later. > > They could even bridge the desktop and the thin client with a serial cable > or parallel port cable to do a system-to-system copy. I mean... they are > developers, it isn't hard to write a simple utility or download a public one > to do a serial/parallel cable transfer. With a custom LED/photo-diode > device, you could, in theory, use the monitor to export data serially or > parallel. (Might be a nice hobby project, actually.) > > > If the thinclient needs to be secure, then it should store NO information > and have no means to input/output other than the screen and the > keyboard/mouse. The system should stop working if it is unplugged from the > network and require re-authentication to prevent cached data from being > copied to another computer(thinclient+ramdrive => laptop via cross-over > cable). Ie, if the thinclient's OS detects it isn't in contact with the > central server, it should wipe it's local ramdisk and shutdown. > > The desktop/workstation should similarly be restricted and limited, but > via a different network and different central server. "Maybe" have USB/CDROM > access since it is for normal office work, but it should definitely not have > any means to connect with the thin client in any way. > > Assume that the BIOS can be compromised. Passwords can be reset. So a > normal machine plugged into your network will get nothing except the > PXE-boot/dhcp information to load a highly restricted image which will not > access the hard drive, cdrom, usb, flash, pcmcia, serial, parallel, > infrared, bluetooth, wifi, or sound ports. > > Regarding the "thinpathsystems.com " X > terminal product, it makes use of the local hard disk. So once you have > installed it once, there is very little to prevent it from being compromised > to allow copying data to another machine from hooking up to it and copying > data from it. > > Seriously, virtualize the OS. This allows you to lock down the hardware at > 2 levels: the host OS(Linux) can disable drivers to the various hardware > ports, so that even if the system HAD a hard drive in it, it won't be used, > and the GUEST OS ala VMware Player(Windows), where it has no access to the > HOST OS's devices, which aren't available, and the VMware instance is > further disabled. > > If they manage to hack the Windows Guest OS, the Linux underlying OS won't > let them write to anything or transmit anywhere. If they manage to hack the > underlying Linux OS, there is nowhere to write programs to since the system > isn't compiled with support for local storage or local buses. > VMware Player can even limit which shared folders are available. > > If they disconnect the network, you can encode the Linux distro to > basically wipe the ram drive on the thinclient via a heartbeat with a > central server. No return beats in say 5 seconds and the ethernet link is > down? We've been disconnected, wipe it and shutdown. Mitigated risk to > cached data theft. Since the saved data is stored on a NFS/CIFS/CVS central > server, no data loss. Since the OS is booting from a remote image, no OS > corruption. > > It might be a bit more involved than a straightforward > firewall/VPN/segmented network approach or an X11 thinclient approach, but > you get alot more control while being able to provide a "full" OS to the > developers to work on. You can also maintain different revisions of > workstation images,should someone need to work on a particular OS revision > or a different set of development tools. > > The VMware ACE route has a higher price tag, but is a single bundled > package. > The Linux+VmwarePlayer+VMwareWorkstation route is cheaper, but requires a > little more admin experience/knowledge. > > But both options will mitigate the risk of developers walking off with > information on their laptops, portable media, etc... when properly > configured. > > How much protection you need depends on what the requirements are for the > project. > > Wing. > > -- > Wing Wong > wingedpower at gmail.com > -- Wing Wong wingedpower at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From rw at tensilica.com Wed Oct 26 09:23:24 2005 From: rw at tensilica.com (RW Hawkins) Date: Wed, 26 Oct 2005 09:23:24 -0700 Subject: Consulting Rates Message-ID: <435FAD7C.3010102@tensilica.com> I am interested in hearing what different folks are asking for consulting rates. In particular for Linux email infastructure, firewall and fileserving type administration that can be done remotely. Do you have different rates for different size companies or different tasks? How do you handle short, minimum tasks and mission critical late night emergencies. Thanks in advance, RW Hawkins From brian.street at bayarea.net Thu Oct 27 11:38:16 2005 From: brian.street at bayarea.net (Brian Street) Date: Thu, 27 Oct 2005 11:38:16 -0700 Subject: Thin Client solutions In-Reply-To: <200510261358.j9QDwk719884@baygate.bayarea.net> References: <200510261358.j9QDwk719884@baygate.bayarea.net> Message-ID: <1130438296.43611e98a93eb@myaccount.bayarea.net> Thank you everyone for your replies. There are a lot of factors to take into account and as usual I'll have to weigh security against ease of use. Brian. From sigje at sigje.org Fri Oct 28 00:03:46 2005 From: sigje at sigje.org (Jennifer Davis) Date: Fri, 28 Oct 2005 00:03:46 -0700 (PDT) Subject: Nov 9: BayLISA Peninsula Meeting: Email/Collaboration Tools in the Workplace In-Reply-To: References: Message-ID: It's an exciting month for BayLISA! People asked for a meeting more North, show some support if you want to see a Peninsula based meeting continued! Zimbra is hosting, and sponsoring the meeting with food and beverages. The format of this meeting is a little different, in that we are going to basically attack a topic, present some content about that topic, and then have a discussion period from 9:15-9:45pm. Topic: Email and Collaboration Tools in the Workplace Date: Wednesday, November 9 2005 Where: Zimbra, Inc 1500 Fashion Island Blvd Ste 100 San Mateo, CA 94404 http://maps.google.com/maps?q=1500+Fashion+Island+Boulevard,+94404&spn=0.030477,0.047252&hl=en (Funnily enough a BJs is right down the street :), so we could have after meeting at BJs if there is enough interest...) 7:30 pm Introductions and Announcements - Have a Job/Want a Job 7:45 pm 1st Speaker - Zimbra Inc 8:30 pm 2nd Speaker - Mirapoint Inc 9:15 Discussion/Analysis/Comments/Interact with Demos Please RSVP to rsvp at baylisa.org. BaySUG 2005 Date: Saturday November 12, 2005 Where: Computer History Musuem, 1401 N Shoreline Blvd Mtn View, CA 94043 Jeremy Allison - Samba what's new, complexities, status of the project Chris DiBona - Google's Summer of Code process and results networking, tour of the computer history museum, and reception sponsored by google Books from Addison-Wesley/Prentice Hall PTR, and O'Reilly give aways This event is free, and registration is open now at http://www.usenix.org/events/baysug05/ If you are interested in getting your group some space on the available tables please do make sure to email baysug05groups at usenix.org with a description of your group, and contact details. It's not too late to get involved. ALSO!! BayLISA General Meeting: Date: Thursday, November 17 2005 Where: Apple Campus, Town Hall (original meeting location at BayLISA) DeAnza Three off of Mariani Ave/DeAnza Blvd in Cupertino, CA Please note the change of venue!! Free and Open to the General Public! 7:00 pm Elections! BayLISA members vote for the 2006-2007 Board members 7:30 pm Introductions and announcements 7:45 pm Guru Session: Bob Camors "Legal Implications of Email" 8:15 pm Formal Presentation: Jennifer Granick (Lawyer in Ciscogate!) "Public Interest Internet law" post meeting - Mirapoint Sponsored Pizza + beer Bash!!! RSVP if you want a guaranteed seat at the bash!! (seriously the restaurant is only so big..we have at least 40 seats :) Come hungry! ______________________________________________ baylisa mailing list: baylisa at baylisa.org rsvp for meeting: rsvp at baylisa.org baylisa board (request to sponsor or present): blw at baylisa.org From david at catwhisker.org Fri Oct 28 08:15:32 2005 From: david at catwhisker.org (David Wolfskill) Date: Fri, 28 Oct 2005 08:15:32 -0700 Subject: Nov 9: BayLISA Peninsula Meeting: Email/Collaboration Tools in the Workplace In-Reply-To: References: Message-ID: <20051028151532.GG69015@bunrab.catwhisker.org> On Fri, Oct 28, 2005 at 12:03:46AM -0700, Jennifer Davis wrote: > > It's an exciting month for BayLISA! > > People asked for a meeting more North, show some support if you want to > see a Peninsula based meeting continued! Zimbra is hosting, and > sponsoring the meeting with food and beverages. The format of this > meeting is a little different, in that we are going to basically attack a > topic, present some content about that topic, and then have a discussion > period from 9:15-9:45pm. >... You know, there's a great deal to be said in favor of the empirical method for determining the likely success of such a venture: cheers to Jennifer for making the arrangements so that folks can try it! The different format (discussion vs. "lecture") should be an interesting experiment, as well. I think I'll see if I can make it. Peace, david (just the "BayLISA member" hat this time) -- David H. Wolfskill david at catwhisker.org Prediction is difficult, especially if it involves the future. -- Niels Bohr See http://www.catwhisker.org/~david/publickey.gpg for public key. From michael at halligan.org Sat Oct 29 13:21:53 2005 From: michael at halligan.org (Michael T.Halligan) Date: Sat, 29 Oct 2005 13:21:53 -0700 Subject: Options for a 24-port firewall? Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I'm sitting around, analyzing my firewall needs. My needs are pretty simple. I need to be able to throw a lot of customers on their own 100mb firewall ports. Most customers will never use more than about 3 mb/s. Given this, I expect the overall throughput for 24 customers, given some flux, to be about 150mb/s. Ideally, I'd love to throw Linux or OpenBSD onto a box that has 1/2 dozen quad ethernet cards.. I'd also like to keep the budget per firewall under $7.5k, which rules out any commerical solution. Given these requirements, am I insane? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) iD8DBQFDY9nlwjCqooJyNAMRAuziAJ4oKy9GZEn7GwKeSHECZ73Mw0UVUACeIUFk blEFfFlsvaMUBOK/ZjsJNM0= =7Pvv -----END PGP SIGNATURE----- From ulf at Alameda.net Sat Oct 29 13:49:11 2005 From: ulf at Alameda.net (Ulf Zimmermann) Date: Sat, 29 Oct 2005 13:49:11 -0700 Subject: Options for a 24-port firewall? In-Reply-To: References: Message-ID: <20051029204911.GA20309@evil.alameda.net> On Sat, Oct 29, 2005 at 01:21:53PM -0700, Michael T.Halligan wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > I'm sitting around, analyzing my firewall needs. My needs are pretty > simple. I need to be able to throw a lot of customers on their own > 100mb firewall ports. Most customers > will never use more than about 3 mb/s. Given this, I expect the > overall throughput for 24 customers, given some flux, to be about > 150mb/s. Ideally, I'd love to throw Linux or > OpenBSD onto a box that has 1/2 dozen quad ethernet cards.. I'd also > like to keep the budget per firewall under $7.5k, which rules out any > commerical solution. > > Given these requirements, am I insane? The keyword is VLANs as your bandwidth need itself isn't that high. Even commercial, Netscreen 25 or 50 would come to mind should be able to handle that. -- Regards, Ulf. --------------------------------------------------------------------- Ulf Zimmermann, 1525 Pacific Ave., Alameda, CA-94501, #: 510-865-0204 You can find my resume at: http://seven.Alameda.net/~ulf/resume.html From michael at halligan.org Sat Oct 29 15:01:38 2005 From: michael at halligan.org (Michael T. Halligan) Date: Sat, 29 Oct 2005 15:01:38 -0700 Subject: Options for a 24-port firewall? In-Reply-To: <20051029204911.GA20309@evil.alameda.net> References: <20051029204911.GA20309@evil.alameda.net> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ulf, You're probably right on that. In an ideal world, I'd just have a firewall port for every customer, but I'm realizing this is just too much of a pie in the sky type hope.. Hmm. Back to hoping that Linux's 802.1q implementation is stable. Somebody needs to come out with a 144-port firewall. On Oct 29, 2005, at 1:49 PM, Ulf Zimmermann wrote: > On Sat, Oct 29, 2005 at 01:21:53PM -0700, Michael T.Halligan wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> I'm sitting around, analyzing my firewall needs. My needs are pretty >> simple. I need to be able to throw a lot of customers on their own >> 100mb firewall ports. Most customers >> will never use more than about 3 mb/s. Given this, I expect the >> overall throughput for 24 customers, given some flux, to be about >> 150mb/s. Ideally, I'd love to throw Linux or >> OpenBSD onto a box that has 1/2 dozen quad ethernet cards.. I'd also >> like to keep the budget per firewall under $7.5k, which rules out any >> commerical solution. >> >> Given these requirements, am I insane? >> > > The keyword is VLANs as your bandwidth need itself isn't that high. > Even commercial, Netscreen 25 or 50 would come to mind should be > able to handle that. > > -- > Regards, Ulf. > > --------------------------------------------------------------------- > Ulf Zimmermann, 1525 Pacific Ave., Alameda, CA-94501, #: 510-865-0204 > You can find my resume at: http://seven.Alameda.net/~ulf/resume.html > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) iD8DBQFDY/FGwjCqooJyNAMRAnPjAJ9n8ZoJ1dQLkYjWxu1HlAMCP9+wbQCgup8F A3VyHr8SmsiwO++ejfOQ70I= =5Iij -----END PGP SIGNATURE----- From gwen at reptiles.org Sat Oct 29 16:56:31 2005 From: gwen at reptiles.org (Gwendolynn ferch Elydyr) Date: Sat, 29 Oct 2005 19:56:31 -0400 (EDT) Subject: Options for a 24-port firewall? In-Reply-To: References: Message-ID: <20051029195238.N13322@skink.reptiles.org> On Sat, 29 Oct 2005, Michael T.Halligan wrote: > I'm sitting around, analyzing my firewall needs. My needs are pretty simple. > I need to be able to throw a lot of customers on their own 100mb firewall > ports. Most customers will never use more than about 3 mb/s. Given this, > I expect the overall throughput for 24 customers, given some flux, to be > about 150mb/s. Ideally, I'd love to throw Linux or OpenBSD onto a box > that has 1/2 dozen quad ethernet cards.. I'd also like to keep the budget > per firewall under $7.5k, which rules out any commerical solution. > > Given these requirements, am I insane? Er... given the lack of requirements, you may be insane ;> What do you want this 'firewall' to do ;> Is this supposed to do stateful inspection? vpn? simple port filtering? nat? the thousand monkey cha-cha? *grin* Is there a reason to want all of the customers on the same device? We've certainly had plenty of entertaining examples of devices using logical separation to enforce security/traffic failing miserably. All that aside, there are a metric ton of appliance-class firewall devices that will push the amount of per-customer traffic you're describing, and come in well under $1k/box, never mind $7.5k/box... (or was that a typo intended to read "$7.5k total")? cheers! ========================================================================== "A cat spends her life conflicted between a deep, passionate and profound desire for fish and an equally deep, passionate and profound desire to avoid getting wet. This is the defining metaphor of my life right now." From alvin at Mail.Linux-Consulting.com Sat Oct 29 19:20:05 2005 From: alvin at Mail.Linux-Consulting.com (Alvin Oga) Date: Sat, 29 Oct 2005 19:20:05 -0700 (PDT) Subject: Options for a 24-port firewall? In-Reply-To: Message-ID: hi ya michael On Sat, 29 Oct 2005, Michael T. Halligan wrote: > > On Sat, Oct 29, 2005 at 01:21:53PM -0700, Michael T.Halligan wrote: > > > >> I'm sitting around, analyzing my firewall needs. My needs are pretty > >> simple. I need to be able to throw a lot of customers on their own > >> 100mb firewall ports. Most customers > >> will never use more than about 3 mb/s. Given this, I expect the > >> overall throughput for 24 customers, given some flux, to be about > >> 150mb/s. Ideally, I'd love to throw Linux or > >> OpenBSD onto a box that has 1/2 dozen quad ethernet cards.. I'd also motherboards with 6-pci slots is harder to find but if you're not locked to a particular cpu or mb vendor .. its doable .. yo'd probably want pci-x instead and there's probably not many choices of mb for 4x or 6x 64-bit pci slot motherboards .. openbsd would be better os > >> like to keep the budget per firewall under $7.5k, which rules out any > >> commerical solution. i'd go for 2 machines instead of 1 ... and seems doable for the budget .. except for the "time for home brew" :-) c ya alvin - to make things more fun .. i'm looking to build a custom 24-port gigE or at least take off the plastics and stick it inside my box for "demo" From david at catwhisker.org Sun Oct 30 20:14:35 2005 From: david at catwhisker.org (David Wolfskill) Date: Sun, 30 Oct 2005 20:14:35 -0800 Subject: Possible aid in filtering spam Message-ID: <20051031041435.GM69015@bunrab.catwhisker.org> The externally-visible SMTP server I have at home is often fairly maxed out -- it's a P-150 with 64 MB RAM, and it could use more CPU and more memory, especially since I have all the MTA filtering done on the same machine (while it also does packet-filtering, NAT, & externally-visible DNS, too). Thus, I have a certain incentive to try to do the less-expensive tests earlier in the SMTP conversation. This afternoon, I happened to be doing ps ax | grep sendm a few times in succession while watching "top" and some logs; I noticed that sendmail was reporting the status of various incoming SMTP transactions by munging the command line that "ps" reports (as expected, of course). Then I saw one pop up that went from "startup" to "HELO" -- nothing odd about that. But then I saw that this conversation was being reported as the client claiming to be "mx.catwhisker.org." Now just waitaminute here.... The client is claiming the identity of the server to which it's talking? Excuse me? I decided that HELO time would be a great point at which to reject this sort of thing; after all, about the only thing that's testable that comes before that in SMTP is "connect". So I adjusted my filter to reject such things. I then saw some machine say "HELO 63.192.123.122". Ummm... no sale: that's *my* IP address. Added that to the filter, too. I've added similar expressions to the filter for BayLISA, as well. I'll grant that it says something (not too positive) about the Internet when a postmaster can be pleased about how much mail his SMTP server rejects, rather than how much is being passed along. Still, this seems like a fair amount of progress: the bulk of the messages that are being thus rejected appear to be being bounced off of SMTP clients in such places as China and Vietnam -- and I'm already blocking several such netblocks at "connect" time anyway. I now expect to be informed of (allegedly) "legitimate" SMTP clients that actually do this. Hmmmm.... Peace, david (wearing some postmaster hat, I guess) -- David H. Wolfskill david at catwhisker.org Prediction is difficult, especially if it involves the future. -- Niels Bohr See http://www.catwhisker.org/~david/publickey.gpg for public key. From ames at montebellopartners.com Mon Oct 31 08:40:33 2005 From: ames at montebellopartners.com (Ames Cornish) Date: Mon, 31 Oct 2005 08:40:33 -0800 Subject: Possible aid in filtering spam In-Reply-To: <20051031041435.GM69015@bunrab.catwhisker.org> References: <20051031041435.GM69015@bunrab.catwhisker.org> Message-ID: <1130776833.8198.2.camel@localhost.localdomain> On Sun, 2005-10-30 at 20:14 -0800, David Wolfskill wrote: > I then saw some machine say "HELO 63.192.123.122". Ummm... no sale: > that's *my* IP address. Added that to the filter, too. > David, Thanks for the tip! I just looked at my logs and I have quite a few spammers using my IP as the HELO. None use the host name -- hmmmm. Incidentally, I've been trying various anti-spam techniques on my mailserver, and collected statistics on the results. I have a presentation on what worked best and what didn't here: http://montebellopartners.com/slides/ Thanks for the info! - Ames -- Ames Cornish ~ http://montebellopartners.com/ 650-331-1402 ~ ames at montebellopartners.com From ulf at Alameda.net Mon Oct 31 12:22:01 2005 From: ulf at Alameda.net (Ulf Zimmermann) Date: Mon, 31 Oct 2005 12:22:01 -0800 Subject: Possible aid in filtering spam In-Reply-To: <1130776833.8198.2.camel@localhost.localdomain> References: <20051031041435.GM69015@bunrab.catwhisker.org> <1130776833.8198.2.camel@localhost.localdomain> Message-ID: <20051031202200.GC20309@evil.alameda.net> On Mon, Oct 31, 2005 at 08:40:33AM -0800, Ames Cornish wrote: > On Sun, 2005-10-30 at 20:14 -0800, David Wolfskill wrote: > > I then saw some machine say "HELO 63.192.123.122". Ummm... no sale: > > that's *my* IP address. Added that to the filter, too. > > > > David, > > Thanks for the tip! I just looked at my logs and I have quite a few > spammers using my IP as the HELO. None use the host name -- hmmmm. > > Incidentally, I've been trying various anti-spam techniques on my > mailserver, and collected statistics on the results. I have a > presentation on what worked best and what didn't here: > http://montebellopartners.com/slides/ > > Thanks for the info! > > - Ames I have started rejecting HELO using my IP a longer time ago. Then I went actually a step further and rejecting any HELO with an IP. Much spam software which are using comprised hosts, don't look up their hostname but just use the IP number. As I interpret the RFC 821, HELO is to follow by the hostname and a hostname is not an IP address. Yesterday my mail server rejected 6205 emails, 308 of those were based on HELO . -- Regards, Ulf. --------------------------------------------------------------------- Ulf Zimmermann, 1525 Pacific Ave., Alameda, CA-94501, #: 510-865-0204 You can find my resume at: http://seven.Alameda.net/~ulf/resume.html From david at catwhisker.org Mon Oct 31 12:57:26 2005 From: david at catwhisker.org (David Wolfskill) Date: Mon, 31 Oct 2005 12:57:26 -0800 Subject: Possible aid in filtering spam In-Reply-To: <20051031202200.GC20309@evil.alameda.net> References: <20051031041435.GM69015@bunrab.catwhisker.org> <1130776833.8198.2.camel@localhost.localdomain> <20051031202200.GC20309@evil.alameda.net> Message-ID: <20051031205726.GX69015@bunrab.catwhisker.org> On Mon, Oct 31, 2005 at 12:22:01PM -0800, Ulf Zimmermann wrote: > ... > I have started rejecting HELO using my IP a longer time ago. Then I went > actually a step further and rejecting any HELO with an IP. Much spam software > which are using comprised hosts, don't look up their hostname but just use > the IP number. That makes a certain amount of sense..... > As I interpret the RFC 821, HELO is to follow by the hostname > and a hostname is not an IP address. Well, RFC 821 is venerable, but it was superceded by RFC 2821 April 2001. And on that topic, RFC 2821, in section 4.1.1.1 Extended HELLO (EHLO) or HELLO (HELO), has: These commands are used to identify the SMTP client to the SMTP server. The argument field contains the fully-qualified domain name of the SMTP client if one is available. In situations in which the SMTP client system does not have a meaningful domain name (e.g., when its address is dynamically allocated and no reverse mapping record is Klensin Standards Track [Page 29] ^L RFC 2821 Simple Mail Transfer Protocol April 2001 available), the client SHOULD send an address literal (see section 4.1.3), optionally followed by information that will help to identify the client system. y The SMTP server identifies itself to the SMTP client in the connection greeting reply and in the response to this command. .... [The last-quoted sentence is not a transcription error on my part.] And here's the part in section 4.1.3 Address Literals: Sometimes a host is not known to the domain name system and communication (and, in particular, communication to report and repair the error) is blocked. To bypass this barrier a special literal form of the address is allowed as an alternative to a domain name. For IPv4 addresses, this form uses four small decimal integers separated by dots and enclosed by brackets such as [123.255.37.2], which indicates an (IPv4) Internet Address in sequence-of-octets form. For .... Based on that, perhaps a plausible course of action would be (in response to HELO or EHLO): * See if SMTP client is claiming the server's identity. If so, reject. * See if the identity claimed is an IPv4 dotted-quad. If so: * See if there's a PTR record for the IP address. If so, reject. [This is a bit enthusiastic, because we don't really know that there's an A record that resolves to the IP address specified.] A variant that is used for the (Postfix) MTA on mx1.freebsd.org is: * Examine the IP address that the SMTP client is using. * Use gethostbyaddr() to obtain the canonical hostname for the address. * Use gethostbyname() to resolve the hostname to a set of IP addresses. * If the IP address that the SMTP client is currently using is not among the IP addresses obtained, reject the mail (unless it's for postmaster or one of the other "special" recipients). * Examine the identity claimed in the HELO/EHLO command. * If it's a hostname, use gethostbyname() to resolve it to a set of IP addresses. * If the IP address that the SMTP client is currently using is not among the IP addresses obtained, reject the mail (unless it's for postmaster or one of the other "special" recipients). * If it's an IP address, use gethostbyaddr() to obtain the canonical hostname for the address. * Use gethostbyname() to resolve the hostname to a set of IP addresses. * If the IP address that the SMTP client is currently using is not among the IP addresses obtained, reject the mail (unless it's for postmaster or one of the other "special" recipients). At least that's my recollection at the moment. > Yesterday my mail server rejected 6205 > emails, 308 of those were based on HELO . I'm not dealing with numbers quite that big -- ignoring the "did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA" (which appears to be about 30% of the total for me), I usuaully have about 2K messages/day hit my SMTP server, and about 75% of those are rejected and 15% are silently discarded. Since midnight, about 22% of today's rejects have been for trying to claim my SMTP server's identity during HELO. [Maybe I should change the rejection message to read "I refuse to talk to myself." :-) ] (I try to merely discard unwanted mail that was already accepted by a system that I consider "friendly" but for which I cannot cause the unwanted mail to be rejected when it hits that SMTP server. Chief among these for me in mx1.freebsd.org.) Peace, david -- David H. Wolfskill david at catwhisker.org Prediction is difficult, especially if it involves the future. -- Niels Bohr See http://www.catwhisker.org/~david/publickey.gpg for public key. From ulf at Alameda.net Mon Oct 31 13:13:26 2005 From: ulf at Alameda.net (Ulf Zimmermann) Date: Mon, 31 Oct 2005 13:13:26 -0800 Subject: Possible aid in filtering spam In-Reply-To: <20051031205726.GX69015@bunrab.catwhisker.org> References: <20051031041435.GM69015@bunrab.catwhisker.org> <1130776833.8198.2.camel@localhost.localdomain> <20051031202200.GC20309@evil.alameda.net> <20051031205726.GX69015@bunrab.catwhisker.org> Message-ID: <20051031211326.GD20309@evil.alameda.net> On Mon, Oct 31, 2005 at 12:57:26PM -0800, David Wolfskill wrote: > On Mon, Oct 31, 2005 at 12:22:01PM -0800, Ulf Zimmermann wrote: > > ... > > > I have started rejecting HELO using my IP a longer time ago. Then I went > > actually a step further and rejecting any HELO with an IP. Much spam software > > which are using comprised hosts, don't look up their hostname but just use > > the IP number. > > That makes a certain amount of sense..... > > > As I interpret the RFC 821, HELO is to follow by the hostname > > and a hostname is not an IP address. > > Well, RFC 821 is venerable, but it was superceded by RFC 2821 April > 2001. > > And on that topic, RFC 2821, in section 4.1.1.1 Extended HELLO (EHLO) > or HELLO (HELO), has: > > These commands are used to identify the SMTP client to the SMTP > server. The argument field contains the fully-qualified domain name > of the SMTP client if one is available. In situations in which the > SMTP client system does not have a meaningful domain name (e.g., when > its address is dynamically allocated and no reverse mapping record is > > Klensin Standards Track [Page 29] > ^L > RFC 2821 Simple Mail Transfer Protocol April 2001 > > available), the client SHOULD send an address literal (see section > 4.1.3), optionally followed by information that will help to identify > the client system. y The SMTP server identifies itself to the SMTP > client in the connection greeting reply and in the response to this > command. > .... > > [The last-quoted sentence is not a transcription error on my part.] > > And here's the part in section 4.1.3 Address Literals: > > Sometimes a host is not known to the domain name system and > communication (and, in particular, communication to report and repair > the error) is blocked. To bypass this barrier a special literal form > of the address is allowed as an alternative to a domain name. For > IPv4 addresses, this form uses four small decimal integers separated > by dots and enclosed by brackets such as [123.255.37.2], which > indicates an (IPv4) Internet Address in sequence-of-octets form. For > .... > > Based on that, perhaps a plausible course of action would be (in response > to HELO or EHLO): > > * See if SMTP client is claiming the server's identity. If so, reject. > > * See if the identity claimed is an IPv4 dotted-quad. If so: > * See if there's a PTR record for the IP address. If so, reject. > [This is a bit enthusiastic, because we don't really know that > there's an A record that resolves to the IP address specified.] > > A variant that is used for the (Postfix) MTA on mx1.freebsd.org is: > * Examine the IP address that the SMTP client is using. > * Use gethostbyaddr() to obtain the canonical hostname for the address. > * Use gethostbyname() to resolve the hostname to a set of IP addresses. > * If the IP address that the SMTP client is currently using is not > among the IP addresses obtained, reject the mail (unless it's > for postmaster or one of the other "special" recipients). > > * Examine the identity claimed in the HELO/EHLO command. > * If it's a hostname, use gethostbyname() to resolve it to a set of > IP addresses. > * If the IP address that the SMTP client is currently using is not > among the IP addresses obtained, reject the mail (unless it's > for postmaster or one of the other "special" recipients). > * If it's an IP address, use gethostbyaddr() to obtain the canonical > hostname for the address. > * Use gethostbyname() to resolve the hostname to a set of IP addresses. > * If the IP address that the SMTP client is currently using is not > among the IP addresses obtained, reject the mail (unless it's > for postmaster or one of the other "special" recipients). > > At least that's my recollection at the moment. > > > Yesterday my mail server rejected 6205 > > emails, 308 of those were based on HELO . > > I'm not dealing with numbers quite that big -- ignoring the "did > not issue MAIL/EXPN/VRFY/ETRN during connection to MTA" (which > appears to be about 30% of the total for me), I usuaully have about > 2K messages/day hit my SMTP server, and about 75% of those are > rejected and 15% are silently discarded. Since midnight, about 22% of > today's rejects have been for trying to claim my SMTP server's identity > during HELO. > > [Maybe I should change the rejection message to read "I refuse to > talk to myself." :-) ] > > (I try to merely discard unwanted mail that was already accepted by a > system that I consider "friendly" but for which I cannot cause the > unwanted mail to be rejected when it hits that SMTP server. Chief > among these for me in mx1.freebsd.org.) > > Peace, > david You just refreshed my memory, I did this based on RFC2821, rejecting things like: HELO xxx.xxx.xxx.xxx (where xxx can be any IP) HELO [yyy.yyy.yyy.yyy] (if yyyy is my IP) -- Regards, Ulf. --------------------------------------------------------------------- Ulf Zimmermann, 1525 Pacific Ave., Alameda, CA-94501, #: 510-865-0204 You can find my resume at: http://seven.Alameda.net/~ulf/resume.html From extasia at extasia.org Mon Oct 31 14:45:21 2005 From: extasia at extasia.org (David Alban) Date: Mon, 31 Oct 2005 14:45:21 -0800 Subject: Fwd: [PenLUG] Sys Admin In-Reply-To: <004d01c5de6b$97a75500$c801a8c0@goldenfamily.info> References: <004d01c5de6b$97a75500$c801a8c0@goldenfamily.info> Message-ID: <4c714a9c0510311445n4ae909fbr1b24ef99a13f0d45@mail.gmail.com> [Please reply to Bernard Golden . Thanks.] ---------- Forwarded message ---------- From: Bernard Golden Date: Oct 31, 2005 2:36 PM Subject: [PenLUG] Sys Admin To: penlug-members at penlug.org Can anyone recommend a good quality, affordable sys admin available for a bit of work? I'm going nuts trying to get my network set up and am looking for some help. Many thanks. Bernard Golden Chief Executive Officer, Navica www.navicasoft.com Author, "Succeeding with Open Source," Addison-Wesley, 2005 (T) 650 585 5309 (C) 650 400 3204 (F) 650 591 3805 Sign up for Navica's monthly open source newsletter _______________________________________________ PenLUG-Members mailing list PenLUG-Members at penlug.org http://jeffk.com/mailman/listinfo/penlug-members -- Live in a world of your own, but always welcome visitors. From "Wolfgang S. Rupprecht" at wsrcc.com Mon Oct 31 14:47:03 2005 From: "Wolfgang S. Rupprecht" at wsrcc.com ("Wolfgang S. Rupprecht" at wsrcc.com) Date: Mon, 31 Oct 2005 14:47:03 -0800 Subject: Possible aid in filtering spam References: <20051031041435.GM69015@bunrab.catwhisker.org>, <20051031205726.GX69015@bunrab.catwhisker.org> Message-ID: <87y849fgns.fsf@bonnet.wsrcc.com> david at catwhisker.org (David Wolfskill) writes: > ... To bypass this barrier a special literal form > of the address is allowed as an alternative to a domain name. For > IPv4 addresses, this form uses four small decimal integers separated > by dots and enclosed by brackets such as [123.255.37.2], which > indicates an (IPv4) Internet Address in sequence-of-octets form. For > .... What is funny about the spamware authors is that they usually can't be bothered to even code for proper address literals. Most of the numeric HELO's/EHLO's I see are *unbracketed* addresses which I gleefully drop as being non-RFC conformant. -wolfgang -- Wolfgang S. Rupprecht http://www.wsrcc.com/wolfgang/