[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Secure/hardened/minimal Debian (or "Why is the base system the way it is?")



sorry my english is not good .

I suggest that you can use mondo and mindi (freshmeat.net) to make images

Regards

danilo

On Sun, 19 May 2002, Nicole Zimmerman wrote:

> 
> I did this for my company, or something similar. We ship a security
> information management solution, deliverables are a network appliance (the
> "manager" node) and the client software. Anyway, we use debian as our
> network appliance OS and I have "hardened" it and provided a very
> restricted shell for modification of network parameters, etc.
> 
> What I did was:
> 
> 1. Install potato out of the "box" (we have a local mirror)
> 2. Thin potato out (remove unnecessary packages, compilers, etc)
> 3. Make a custom 2.4 kernel with NO loadable modules (because we know the
> hardware, we can do this) and with iptables
> 4. Install back-compiled packages for SSH, postgres, anything else (system
> requirements, plus SSH2 security advantages)
> 5. Switch partitions over to ext3 (if I ship the box and the box goes down
> and fails an fsck, we either give them root or send a tech, expensive
> either way)
> 6. Configure some of the packages to be "more" secure (e.g.
> exim configuration)
> 7. Configure an iptables firewall to further restrict access to
> illegitamite ports (anything but 80 and our 3 proprietary ports)
> (8: Install our software, test, etc)
> 
> My final install, including our software, is under 200M. Right now, I am
> using Norton Ghost for imaging. I considered FAI but because I was only
> doing one "flavor" of image that was not very dynamic, I stuck with Ghost
> (we are also not releasing *too* many of these yet, when we do the Ghost
> licensing fees might be higher than is justified).
> 
> For some packages we use "virtual" packages through equivs (for example,
> j2re1.3 from blackdown.org requires some X crap that we don't want, so I
> build an equivs package that says "sure it's here, trust me").
> 
> If you have any questions about specifics, let me know.
> 
> -nicole
> 
> At 12:10 on May 20, Andrew Pollock combined all the right letters to say:
> 
> > We want these "builds" to be as "hardened" as possible. For example, we
> > don't want compilers installed, unnecessary binaries floating around, etc
> > etc. I really don't want to deviate from using the packaging system to
> > maintain what's installed. I don't want to wind up with a
> > Frankenstein Debian installation that can't be maintained easily. It's
> > just not the Debian Way either.
> > 
> > One thing in particular is inetd. It seems it's unavoidable to have
> > inetd installed, with the netbase package depending on netkit-inetd. Is it
> > possible to completely remove the inetd binary and use a diversion or
> > something to keep the package system reasonably happy with what's happened
> > (I'm not very clued up on more advanced elements of the packaging system
> > like diversions). (Side issue, but why the heck is Woody shipping with
> > inetd and not xinetd? After seeing the way Red Hat manages xinetd based
> > services, it's so much more elegant than using update-inetd).
> > 
> > Secondly, even the base system comes with exim installed and port 25 open
> > (granted, I haven't checked to see if it's only on localhost). A lot of
> > reasonably necessary packages depend on a mail-transport-agent virtual
> > package being installed. For example, on my home machine, if I try to
> > remove the sendmail package, I can also kiss goodbye:
> > 
> > Some of these I find a little bit strange to be losing because I've gotten
> > rid of my mail transport agent... Log rotation, for example, is something
> > I'd need and want in any build I make. I don't understand why I lose at
> > but not cron either...
> > 
> > So my main conundrum at present is what is the best way to make a truly
> > minmalist Debian installation, the "Debian Way", in a highly security
> > conscious environment? I'd really like to see Debian get up in this
> > organisation.
> > 
> > Anything insightful (and hopefully not inciteful) appreciated.
> 
> 
> -- 
> To UNSUBSCRIBE, email to debian-security-request@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
> 


-- 
To UNSUBSCRIBE, email to debian-security-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org



Reply to: