Date: Tue, 17 Jul 2001 17:55:18 -0400 From: "Bart Silverstrim" <bsilver@sosbbs.com> To: "Paul Robinson" <paul@akita.co.uk> Cc: <freebsd-isp@FreeBSD.ORG> Subject: Re: gcc on production server Message-ID: <017f01c10f0b$2cf38be0$0100a8c0@sosbbs.com> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
Mr. Robinson, > Firstly, can I suggest that you use more paragraph breaks. Your mail was > bordering on unreadable due to the big mass of text. ;-) I'll try :-) > You're talking about something completely different. Ditto. Perhaps one of the key points of contention and misunderstanding in this thread. >I'm not talking about a > proven exploitation. I'm not talking about the case where there is direct > evidence that your machine has been compromised. I'm talking about you > keeping your daemons patched up to date. That would be a different but related issue; I think we should be talking in the same context in order to come to an understanding. I came from the school of thought where an attack, and eventual compromise, is almost a definite given with enough time online. And in the environments where I worked, there simply wasn't enough manpower to properly plan and execute things; in the practical sense. I have tried to do things as best as possible given that when the powers that be needed something it was always a crisis mode deal. often budgeting and planning weren't priorities not by MY choice, but by those that if I don't live up to their expectations, I'm out of there. You imply that I give little regard to security. Far from it. I put a high priority on it. I haven't been lucky enough to have a neighborhood guru around to help teach me. I've learned mainly through howtos, newsgroups, printing and reading enough docs to get lab admins ticked at the paper allotments I used up, and experimenting with setups. That's why I asked you about the howtos for doing the MD5's. 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 if you are honestly stating > that there are fewer patches released for software you run over say, a year, > than the number of times you get rootkitted in a year, again I thank God you > don't work anywhere near any equipment I operate. I haven't been rootkitted. I also do the best I can to prevent having a myriad of services running on a single system, coupled with different passwords to my servers so infiltrating one doesn't give carte blanche to the others. As I said, I'm not as irresponsible security-wise as you're implying. As for the standpoint of patching just to keep up to date, I have been bitten once in awhile for being on the bleeding edge in updates. If an exploit is for a service I don't run, why apply it? If an exploit is for a program only expolitable locally, but the only person who has any access on the machine is myself, why update it and run the risk of having a downtime problem because of it? Being called into the office to get dressed down for taking out a service just because I was trying to fix something that wouldn't be used anyway by anyone would not make management exactly happy. I realize what you're saying, and if it were just my server or just my services in question, I'd do it. In my situation, and in the situation I suspect many admins out there are in, there are times where well enough alone works. > We're less than 10 people and have a full-time security officer. I'd love to have even that :-) > Not really, we have less than half a dozen permanently connected hosts. I > have worked in very large sites with 100's of machines, but I like it here > where things are nice and small. :-) I kind of miss that too...my previous job was smaller but with more people depending on the systems. I liked having a boss that knew that SMTP wasn't something that involved Halloween and toilet papering. > Build it Once and Walk Away. You should put the time and effort in at the > design stage to try and get things to work well. If you spend 4 months > designing and then a weekend implementing, you will find things to be a lot > more stable and better suited to the app than 2 months rushed gradual > implementing based on a design put together in a weekend. 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. Although I do disagree with the walk away philosophy part. No system is foolproof. Except for Microsoft marketing, maybe. And no admin is infallible. Ever read "@Large"? I'd like to see you keep that kid out of your servers. > I agree with that, I'm just trying to get across to you that from a security > point of view, it's a dead end. I would think it's a matter of "security priorities". Your argument sounds like security through latest patchlevels are the key. The CD idea I tossed out was essentially saying "if you manage to break into my house, you can take what you want", only all the belongings are nailed down and superglued. That gets into the argument, which neither of us can win, of "can I come up with a system that no one will ever break into" or "someone may get in eventually, lets minimize the damage as much as possible". >As for security, all I have to say is "why > bother?" just use the tools provided. Too many clever hacks I've occasionally met up with, basically. I'm not dismissing your argument, I agree with you on many points. I'm just not comfortable with the tools provided being the place to rest on laurels. Just when you think you've seen it all...never underestimate the power of a bored and malcontented mind. > Ho, ho, ho. Look, I've worked in a variety of sites, on a variety of > applications. If you knew what some of our products were, and how they were > developed you would realise I'm open to new approaches. I apologize if I came off too strong in sounding like a personal attack. I don't know you, and it wouldn't be right of me to make that kind of judgement. I was returning the volley released by the "thank God you don't work near my servers" sentiment...I didn't think I was that bad of a Linux admin. >However, we also > know about security. <snip> Then you can acknowledge that you are in an evironment where such learning and care are encouraged. Where I was, and am, it's an unfortunate luxury. 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 :-) > We have never told them to move to read-only media as a security measure. Another point of context, I didn't mean to say that it was a purely security driven measure. When I had discussed this with my previous boss, it was part of setting up servers for the ease of use in certain areas, the security would have been a side benefit. > This is not because we're not "open to new ideas". It's because we've seen > it, done it, played with it, broken it, stamped on it, trashed it, written > reports on it, and got paid to consider it. I came to that conclusion about the open ideas mainly because I didn't remember you telling what background you had done before about it; your 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 the simple truth is that you > will improve security and lower administrative costs by using standard > installs, but using the tools provided for the security measures that are > appropriate for the organisation. Very true. > And the worst security risk on a network is the admin who thinks he knows > about security and won't listen to what we're saying. 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?) > What the HELL is doing there? It should be on a CD, in the drive of the > machine, being checked on a daily basis automatically. Or at least, that's > what databases like that are there for. The Aide database? Because I routinely run a check from it and compare the database on the server with the one on the media. As changes are made I archive a new copy to another disk. The file isn't big enough to really warrant transferring it over to a machine with a burner when the ZIP works more than adequately. > Now I see the reason why the first you know about being rootkitted is when > customers start complaining, or you get mail from the admins at ibm.com... I have yet to find myself in that particular situation, but if you find every glitch in your system or configuration on your own without anyone else noticing, you must be charmed. > The point about all these measures is that you are supposed to be able to > detect a compromise. Not prevent it. Being able to detect but not prevent is > 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. > The point about using MD5, signed executables, etc. is to detect > compromise. The idea of being able to *very* quickly patch your daemons is > about prevention. MD5: again, why I asked if there was a reference to implementing it. > Fair enough. I've got confused in this criss-crossing of threads as well. I > thought you were referring to HDD RO. Nopes. I wouldn't want the hassle of disassembling the case just to make a change. Especially on a production server. >CD RO is more realistic, but then you > still have rising admin costs, etc. and you start to have real problems if > your servers are in a co-location facility 3,000 miles away. ;-) True, our colos at the time were only about 20 or 30. :-) > If you give or sell shell accounts, expect to get compromised one day. Exactly why we don't. >The > guy who does the security audits here reckons that given a shell on any > machine, he'll eventually get root. And he's proved himself right every > time. :-) Then perhaps one day I'll find a way to prove him wrong, if that's a challenge :-) Here...I'll put up an NT machine with the telnet server...you'll never get root on that! Administrator maybe, but never root!! > Absolutely, which is why detection is IMHO better than attempted prevention. I try fortifying prevention and having a regimen of detection in the backside. The management who doesn't care what a daemon or spooler is are the same ones that will see more problems with the mopup after an attack rather than being told that if we're compromised, we'll definitely know it. > Well, all the TrustedBSD stuff is being merged at the moment into 5.0, and > there has been something like $1.2 million awarded by the DoD to be spent on > improving this functionality in FreeBSD, to bring it up to DoD specs. So, at > the moment, it requires a lot of messing around, but we should see over the > next 12 months it become more common place, and for more docs to appear. I will be watching more of this as it happens then. One thing I did not like was the liklihood of splitting configs even more; finding that something wasn't working properly because of the security enhancements put into the system. Small chance, but another training hurdle for new admins to get aquainted with and keep in mind that keeps it from being more or less standard. > Agreed, and the more we have this argument, the more I'm starting to wane to > your point of view, and I can see what you're attempting to state. The heart of most arguments, it seems, is not necessarily having a different opinion, but rather a different interpretation and approach to the perceived problem at hand, eh? > 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? > > You sound as if you have a solid implementation of policies and procedures, > > 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? > Well, like I say, I'm seeing your point, slowly. And I wouldn't neccessarily > dismiss you as an employee. Providing you were female, good looking, could > give good shoulder massages, etc. :-) Oh, dammit, I'm male. And not all that good looking. How about just locking me in the server room? Okay, that was indeed a couple big messages, and I'm about ready to go relax a little. Unless there are other points to be made for everyone to view, I 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 :-) -Bart --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.264 / Virus Database: 136 - Release Date: 7/4/01 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?017f01c10f0b$2cf38be0$0100a8c0>