Date: Wed, 18 Jul 2001 11:30:10 +0100 From: Paul Robinson <paul@akita.co.uk> To: Bart Silverstrim <bsilver@sosbbs.com> Cc: freebsd-isp@FreeBSD.ORG Subject: Re: gcc on production server Message-ID: <20010718113010.C59895@jake.akitanet.co.uk> In-Reply-To: <017f01c10f0b$2cf38be0$0100a8c0@sosbbs.com>; from bsilver@sosbbs.com on Tue, Jul 17, 2001 at 05:55:18PM -0400 References: <20010711170336.B84178@krijt.livens.net> <20010711123133.A21587@pitr.tuxinternet.com> <20010712123523.G53408@jake.akitanet.co.uk> <007c01c10b14$5462d820$0100a8c0@sosbbs.com> <20010713122500.A23202@jake.akitanet.co.uk> <010c01c10bdb$a8f11600$0100a8c0@sosbbs.com> <20010716103740.C37477@jake.akitanet.co.uk> <00a701c10e42$2075b560$0100a8c0@sosbbs.com> <20010717121913.J27087@jake.akitanet.co.uk> <017f01c10f0b$2cf38be0$0100a8c0@sosbbs.com>
next in thread | previous in thread | raw e-mail | index | archive | help
This one is getting big and unwieldy, so I'm going to chop a lot of stuff out for the sake of diskspace. ;-) On Jul 17, Bart Silverstrim <bsilver@sosbbs.com> wrote: > Mr. Robinson, My bank calls me Mr. Robinson. And my Doctor. You, you will be pleased to hear, don't need to. :-) > In the environment where I am now, it's simply not practical for me to refit > a system to improve on something that's working. And therein lies an inherent misunderstanding. This thread picked up with the idea of doing a retro-fit - moving boxes onto RO media. My point was that if you're starting from scratch, you have the oppurtunity to do it properly, and just wacking stuff onto RO, whilst making you sleep a little better at night, was not IMHO "best practise". > > We're less than 10 people and have a full-time security officer. > > I'd love to have even that :-) Well, you need to start up a pen-testing company like we did. Then you get one. :-) > For better or worse, time is a luxury as is budgeting where I am. I have no > doubt that 4 months of planning would make things a lot more stable and well > suited. Except within one month my head would be on a platter. Four months was an exaggeration. What I meant was (and this betrays my Software Engineering background), that if you sit down and plan and design, and spend orders of magnitude doing that, and then quickly implement it, the solution would be better than if you just start implementing with only a rough plan and design. > Although I do disagree with the walk away philosophy part. No system is > foolproof. Except for Microsoft marketing, maybe. And no admin is > infallible. "Walk Away" again is a bit of an exaggeration. What I am trying to infer is very little maintenance. Sure, everything needs maintenance, but the less you have to do, the more time you get to work on new projects. With the right time at the beginning, that is a more acheivable goal. Or at least, it is for me. > work near my servers" sentiment...I didn't think I was that bad of a Linux > admin. Never underestimate how terrible you are. :-) > I'd really have liked to work at a place where I'd have more time to immerse > myself or work with others on implementing freenix systems. It just hasn't > worked out that way at this point. But I'm young :-) So am I. Only 23 next month. ;-) > arguments came off more as rapid fire brushoffs. At least, that was my > interpretation when I read and re-read your previous posting. Another > apology may be in order to you. And another apology from me. I can be a bit abrupt at times. Something to do with several hundred mails a day to get through, plus the day job. :-) > I'm very much trying to listen to what you're saying. I haven't dismissed > your approach. I asked about the implementation of the MD5 checksummed > executables, remember? (BTW-does that have overhead cost to the server when > doing heavy accesses to different programs on the server side, having to do > the checksum computation before execution?) OK, the executables are MD5 checked against a database every day or so (a la tripwire), but with trustedbsd, which is to be merged with FreeBSD 5.0 over time, you can play silly buggers with all sorts of mad stuff. You can control what syscalls get used by who, where, etc. and there is all sorts of mad stuff to play with. To get started, take a look at: http://www.trustedbsd.org/downloads/ > > FAR more useful than thinking you can prevent (which you can never do) but > > are never able to detect. You're assuming an implicit trust in a piece of > > software on the IDE controller that says "no, I think I'm read only". > > Somewhere in here we seem to have switched rolls. Yeah, mine has got cheese in it. This one is tuna. :-) > Nopes. I wouldn't want the hassle of disassembling the case just to make a > change. Especially on a production server. Which was one of my original points - e.g. the administrative costs on a large site would make the idea prohibitive. > Here...I'll put up an NT machine with the telnet server...you'll never get > root on that! Administrator maybe, but never root!! We can make an Administrator-equivalent account called "root". :-) > > We just spend Friday afternoons in the pub instead of pizza partys. ;-) > > Can't we all just get along and have pizza at a pub? I actually know a bar in Manchester, UK (where I am), where you can have pizza delivered, and the bar staff will come and find you. Sounds like a good idea. > > Ohhh, no. Don't go that far. We're fumbling as much as you are. Perhaps > > we've just tried more things than most. > > How long have you been in the security biz, out of curiosity? The sec. officer has been involved one way or another for about 15-20 years now. I've been messing with security for about 7 years or so, and although I'm still quite young have worked in quite senior positions in a variety of places. Plus I spend most of my time outside of work playing with kit as well. > Oh, dammit, I'm male. And not all that good looking. How about just > locking me in the server room? As long as you wear a gimp mask in corporate colours, I'm sure we could sort something out. :-) > suggest that this be drawn to a close with a virtual handshake and be taken > to private email offlist if there are more comments on this, and thanks to > everyone who emailed some arguments in private :-) Yeah, I didn't read that bit until I got here, but I agree. I think we can wrap this one up as: 1. Use the tools provided with/for the OS for security - don't try and make your own unless you know what you're doing. 2. RO media can be a hassle if you're OS is on there. It needs careful planning, and your admin costs are likely to rise. 3. RO media is great for things like tripwire databases. 4. Arguments are futile when it comes to security, because everybody has their own technique, and their own angle and perception as to what the priorities are. 5. Life is too short to spend most of it worrying about a 14-year old getting access to your password file. -- Paul Robinson ,--------------------------------------- Technical Director @ Akita | A computer lets you make more mistakes PO Box 604, Manchester, M60 3PR | than any other invention with the T: +44 (0) 161 228 6388 (F:6389)| possible exceptions of handguns and | Tequila - Mitch Ratcliffe `----- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-isp" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010718113010.C59895>