RE: Securing Fedora Core 4

From: Charles Heselton (charles.heselton_at_gmail.com)
Date: 09/23/05

  • Next message: Will Yonker: "RE: Securing Fedora Core 4" 
    To: "'Will Yonker'" <aragonx@dcsnow.com>, <focus-linux@securityfocus.com>
Date: Fri, 23 Sep 2005 08:44:16 -0700

     
    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1

    > -----Original Message-----
    > From: Will Yonker [mailto:aragonx@dcsnow.com]
    > Sent: Friday, September 23, 2005 5:34 AM
    > To: focus-linux@securityfocus.com
    > Cc: charles.heselton@gmail.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"
    something. ;-)

    >
    > > 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 spread***. 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

    iQA/AwUBQzQi0Hv40fZIKe3PEQL55wCfb5PKdmQG3LWDuazcvbumDMa1AucAoJob
    GWCRO+3NQDbP1G7bBdp9yd6e
    =mgHk
    -----END PGP SIGNATURE-----

  • Next message: Will Yonker: "RE: Securing Fedora Core 4"