Date: Tue, 17 Jul 2001 12:19:13 +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: <20010717121913.J27087@jake.akitanet.co.uk> In-Reply-To: <00a701c10e42$2075b560$0100a8c0@sosbbs.com>; from bsilver@sosbbs.com on Mon, Jul 16, 2001 at 05:56:09PM -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>
next in thread | previous in thread | raw e-mail | index | archive | help
On Jul 16, Bart Silverstrim <bsilver@sosbbs.com> wrote:
Firstly, can I suggest that you use more paragraph breaks. Your mail was
bordering on unreadable due to the big mass of text. ;-)
<snip>
> besides reinstall to fix it; even with AIDE or Tripwire I'd be paranoid
> about running the machine "dirty". So in that case, yes, I'd rather
You're talking about something completely different. 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. 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.
> People who work for companies that are big enough to have admins that can,
> as part of daily routine, monitor security lists for every bit of software
> that they're running and can take the time to do patches as needed are
> indeed fortunate. Some of us have to make due with limited resources and
We're less than 10 people and have a full-time security officer.
> time, and do what we can to make things work. Out of curiosity, how big is
> the company you own/work for? From your description of the server racks it
> must be a pretty big operation. Usually big corporations seem to have a
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. :-) The plan is within 12 months to move to
a larger operation as we grow, but I doubt we'll ever need more than about
20 servers. Sites that operate more than that, generally, are inefficient
and bloated, IME. Depends on what you're trying to do I suppose.
> bureacracy in place that either works well for a department or forces people
> to use what's there for other reasons, regardless of how well it works or
> how appropriate an alternative may be. But there's always exceptions.
> Because I have found myself in established networks that could probably use
> some tweaking in some areas, but instead have to make what we have work.
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.
> ideas didn't pan out for the things we needed to do. That's fine. One idea
> was putting the boot/sys information on a CD for certain (notice I'm not
> saying all?) applications...like hosting at other sites, or running servers
> that have a more "static" purpose. So when you say
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. From an ease of upgrade point of view, it's
great. From a point of view of being able to ensure that a customer site is
running a given distro, it's a good idea. We actually use it so that a disk
goes into a box, it boots off the CD, and does a custom install on the first
IDE drive in the machine. As for security, all I have to say is "why
bother?" just use the tools provided.
> I'm afraid I would say "Thank God I don't work for you." I'm all for solid
> leadership and vision, but I also think that entertaining an idea for
> certain applications may actually prove to be beneficial in the long run for
> a business or organization.
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. However, we also
know about security. As a company, we know a lot about security. You would
not comprehend how much time and effort we as a company have spent
understanding security applications from both sides of the fence. As well as
running a small ISP, an IT consultancy, a computer retail operation and a
publishing and graphic design company, we run a security audit and
penetration testing company. We get paid $10k's to advise other companies on
their security policy.
We have never told them to move to read-only media as a security measure.
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. 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.
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. It's their choice,
their board of directors paying for the advise. If they want to use RO
media, than that again, is their choice, but their administrative costs will
rise, and it's attacking security from the wrong angle.
> On a ZIP disk for the server I have at the moment, passworded and locked
> away in a safe, if you really would like to know. Like I tried to say
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.
> before, the CD idea was for certain types of servers in certain situations.
> And besides that, on that type of system, what are they going to trojan if
> the whole filesystem is RO? And if you know your binaries have been
> compromised, you still have to replace them. It still takes time. Unless
> I'm totally missing something here.
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...
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".
> If the system WAS compromised, the "safe admin" wouldn't consider anything
> "probably uncompromised" in terms of binaries being replaced. They got in
> to the system somehow, and you never know if the bugger that got in is doing
> something you didn't expect or think of to compromise you again or leave
> back doors.
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.
> I've been referring to the idea of CD RO, not HD RO. I'm largely unfamiliar
> with using that technique; another poster brought it up and I was asking
> about it. I apologize for confusion of the context.
Fair enough. I've got confused in this criss-crossing of threads as well. I
thought you were referring to HDD RO. 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. ;-)
> information. If they stole a user account, or is a valid user (as I believe
> some FBI statistic report said the majority of "hacking" attacks are, but
> don't quote me on that) getting even, then they can still steal data from
If you give or sell shell accounts, expect to get compromised one day. 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. :-)
> the machine or alter things. I'm pretty sure that in the race of security,
> there's ALWAYS a way to get around it for someone trying hard enough with
> time.
Absolutely, which is why detection is IMHO better than attempted prevention.
> How common is using the MD5-executable only method of setting up a machine?
> Is there a HOWTO on it? How many FreeBSD people on the list are using this
> technique?
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.
> an idiotic idea that you're corrected on and feel embarassed for a little
> while for looking like an idiot, or having an idiotic idea and never being
> corrected until it bites you on the butt? Me, I'd rather be told (and given
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. I just
don't feel that the time and effort spent in implementing it will
neccesarily give you an improvement in security in the long run, and that
the admin costs can get out of control on larger sites. Therefore, I would
advise that detection is a better method of protecting against compromise
for the majority of applications.
> solid reasons for) why an idea is too far off to ever be feasible. But I
> already know of one thing that it would work for...demos
> (*cough*demolinux*cough*). So my idea from a few years ago can't be *all*
> bad. You're right on the points you made.
Yeah, that sort of application would suit it, but more for reasons of ease
of distribution, which if a factor, I have already stated is a reasonable
case for bootable CD implementations.
> And I also mentioned the ideas in business thing earlier...unlike what
> appears to come out of Redmond sometimes, ideas coming from employees trying
> to find ways to solve a problem that's not always "in the box" are a good
> source of "innovation"...and saving small businesses enough money to throw a
> pizza party for the employees :-)
We just spend Friday afternoons in the pub instead of pizza partys. ;-)
> 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.
> and a lot of money and resources to back that up. That's great. And I
Not at all. Quite limited on fiscal budgets, just plenty of talent and time
on our hands. ;-)
> already know you'd never consider me as an employee, so I won't even ask
> about a job :-) But you might want to give some thought to where or how
> something like that could work, rather than why it wouldn't work for your
> setup.
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. :-)
I'm starting to calm down now, and I can see your point.
> One last quick note; to anyone responding to this (if anyone chooses to)
> PLEASE don't quote the ENTIRE THING!! It's getting way to big! Out of
It was a biggie, and I'm suggesting we bring this thread to a close with a
quick summary of where we are.
--
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?20010717121913.J27087>