RE: Securing Fedora Core 4
From: Charles Heselton (charles.heselton_at_gmail.com)
To: "'Will Yonker'" <email@example.com>, <firstname.lastname@example.org> Date: Fri, 23 Sep 2005 08:44:16 -0700
-----BEGIN PGP SIGNED MESSAGE-----
> -----Original Message-----
> From: Will Yonker [mailto:email@example.com]
> Sent: Friday, September 23, 2005 5:34 AM
> To: firstname.lastname@example.org
> Cc: email@example.com
> Subject: RE: Securing Fedora Core 4
> <quote who="Charles Heselton">
> > 4. Set up your firewall. I like firestarter (should come
> with FC4).
> > Other people like shorewall. Ultimately, it's the same outcome.
> I wasn't fond of the way Firestarter worked at all. I'll take a
> close look at Shorewall. I was really worried about rolling my own
> firewall but
> didn't like Firestarter or the standard Fedora one.
Like I said, they all provide the same outcome. They all are
glorified wrappers for iptables, so they all have the same ultimate
effect. I believe shorewall is a little more "low-level", and may
provide more of the granularity that you are probably looking for. I
haven't used shorewall, so I can't say for sure. If that one doesn't
work out, I would recommend finding/writing a script (at least) to
manage your iptables configuration. It makes for easy management and
configurability, and you also are less likely to "fat-finger"
> > 5. Install/configure Bastille (this sort of overlaps some
> > things, but can also affect installation of others, so it might
> > be a good idea to do it early. SELinux might be better here, but
> > I think SELinux depends on some of the kernel hooks and such.
> > The two have really meshed over time, and I haven't followed it
> > that closely.
> I abandoned my attempts at getting SELinux working quite the
> way I like.
> I installed LIDS and really liked the way it worked. The
> ACLs are easy to
> understand and just as easy to configure. My major problem
> with LIDS is
> it doesn't like BIND. There are things that SELinux does that LIDS
> doesn't but I can live with that.
I know what you mean. I haven't really followed SELinux since the
days of the NSA 2.2 kernel. It seems to have advanced quite a bit,
with all of the kernel hooks and such. What's important is that you
know what's going on with your system, and that you're able to manage
it. I haven't used LIDS, but I've heard about it some, and if it
works for you then use it. I'll probably look into it a little
deeper myself now. ;-)
> > 7. If you have another mail host for external mail
> > (administrative messages and such), configure sendmail to only
> > send mail internally (local system). You can configure spam
> > assassin if you want, but unless you're actually transferring
> > bulk mail, you don't really need it, nor the other 3 spam filters
> > you listed.
> The hosts will receive email for the domain so spam filters
> are required.
So, every host will be an MTA?
> Some of our users are really dumb about what sites they go to.
> Their email addresses seem to get harvested every time we change
> them... User
> education has not worked so we will block some sites with
> Dansguardian/squid + some plugins.
Again with the host function segregation. Every host is going to be
an HTTP proxy?
> I doubt this will solve
> the problem
> totally, so all the spam filters...
I've always said that users are the weakest link in any chain of
security. That will never change.
> I've tried Spamassassin by itself but it doesn't get a lot of
> spam without
> a WHOLE lot of tweaking. Simply lowering the number just blocks
> valid email. Lol
This is understandable. But I'm still a little confused about every
single host being an MTA. I mean your network, is your network. But
it seems like you are going to be deploying enough servers that you
should have the ability to segregate function a bit. If you really
have such a big problem with "dumb users" and/or targeted
spam/phishing, a commercial product (and/or a more robust linux
distro) might be in order. JMHO
> > 9. Now configure tripwire (or aide).
> > It's tough to try to generalize this into a concise format. If
> > you have a large enough environment to warrant specific purpose
> > hosts, you should do that. It will allow you to be much more
> specific about
> > your security measures, and will provide much less headache in
> > regards to management.
> I took this from a spreadsheet. I really was trying to keep
> the wording
> down to a check list format so I could check them off as I
> did them. It's
> hard to put very much information in the space I left myself. lol
> Thank you for the tips.
Well, once you get the general gist down, you can break it up and
simplify it into a checklist. Someone else mentioned that security
is an attitude. This is true. It's a way of thinking about how you
manage your systems. Identify your critical assets, i.e. what data
are you trying to protect? Then, build your protection scheme from
the inside out.
- - Charlie
5A27 58D2 C791 8769 D4A4 F316 7BF8 D1F6 4829 EDCF
In memoriam: http://www.militarycity.com/valor/1029976.html
-----BEGIN PGP SIGNATURE-----
Version: PGP 8.1
-----END PGP SIGNATURE-----