Re: Feedback solicited - best way to harden a mail/web server?
From: Jared (jared@hwai.com)
Date: 12/27/02
- Next message: Jared: "Re: Feedback solicited - best way to harden a mail/web server?"
- Previous message: sky-diving: "cryptoapi"
- In reply to: Jim Levie: "Re: Feedback solicited - best way to harden a mail/web server?"
- Next in thread: Jim Levie: "Re: Feedback solicited - best way to harden a mail/web server?"
- Reply: Jim Levie: "Re: Feedback solicited - best way to harden a mail/web server?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
From: jared@hwai.com (Jared) Date: 27 Dec 2002 08:06:40 -0800
"Jim Levie" <jim@entrophy-free.net> wrote in message news:<pan.2002.12.27.03.37.20.965093@entrophy-free.net>...
>
> at https://rhn.redhat.com/errata/rh8-errata-security.html. Then check to see
> if you had the current versions of the affected packages installed. Also
> consider what non-RedHat packages or applications you might have added to the
> system.
Most of the packages were current; whenever I received an RH advisory
email I would update that evening it if was relevant.
> Bastille is fine, but it doesn't take the place of a properly configured
> firewall. Was the system protected by a properly configured firewall? Did you
> have Tripwire installed and configured?
I did not, but I will. Please pardon my naivete, but I thought (part
of) Bastille was a front-end to generate iptables rules. I don't know
if you have ever seen the configuration files it generates, but they
cover the topics I have seen written about in firewall articles.
Overall I have used Bastille's hardening scripts as a baseline because
I thought it was well-regarded as a starting point.
> >
> Were you using Red Carpet or RedHat's up2date. The latter will ensure that all
> security advisories fixed. Dunno if Red Carpet is quite as good.
It is up2date.
> And what about the other nodes on the network? How secure are those and do
> they have expanded access to the server? It could well be that you weren't
Hmm. One of the other nodes is Win2K. It is used primarily for
browsing and checking email. It is open to anyone in our home - which
is pretty much nobody with much computer knowledge except for myself
(and the older I get, the less I seem to know). I had disabled
ZoneAlarm on it when I set up the LAN; I can certainly update it and
put it back on. That would stop unauthorized outgoing traffic as well
as incoming. And I will ask my wife to lock it when not in use.
My workstation (different machine than the one discussed in this
thread) is also RH8.0. There is no telnetd configured in xinetd, nor
is sshd running, nor is there a web or ftp server; aside from that I
haven't tried to secure it, and I do have an MTA on it. I can
certainly put iptables rules on it and install Tripwire.
My other thought was to set up a VPN internally. I have read of
issues with MS' IPsec implementation, but a Winadmin here thinks they
are mostly resolved. My wife used to use Unix in console mode, and
has said whe wouldn't care if I converted her to Linux; but I want to
keep one M$ machine around in case I need to run a DBA tool on it that
VMware chokes on. Fortunately WINE is getting more and more complete;
I hope to lose VMware in the next year if I can get some modeling and
DBA monitoring tools to run.
> resistant to a root attack. The probability is that something about the way
> your system was configured or maintained is the root cause of the break in.
I have no doubt of that if your opinion of secured RH is correct. Nor
am I averse to RTFMing; just trying to focus on what I should be doing
here, developing a plan and focusing my time on productive activities
in this regard.
> The way I'd do it (which has so far proved to be resistant to even
> professional security scans) is:
>
> Non-RedHat packages or
> things built from source are suspect and you want to think long and hard
> before adding one of them.
I haven't been careful about RPM's - I have noticed on rpmfind RH
seems to be a lot slower than its competitors about putting out
updated RPM's; I have been building whatever I ran from source when I
could find it, but I certainly haven't been reviewing the source code.
> 2) As soon as the system is installed and updated configure Tripwire. At the
> same time install a good set of firewall rules and make sure that those rules
> will catch illegal packet types.
Will do. Just browsed their site. It might have allowed me to
identify what binaries were changed; maybe I would've been able to
clean it up or figure out what I configured incorrectly more easily.
> The default stance of the firewall must be to
> disallow everything and then permit only those inbound services that are
> essential (25/tcp, 53/tcp/udp, 443/tcp apparently). Also carefully check any
> web apps for possible security vulnerabilities. If you only have HTML pages,
> you are safe, but any cgi's need to be carefully examined, especially if they
> read/write files, do DB accesses or invoke any system commands.
That was always my stance; Apache is only there to serve Squirrelmail
pages. No CGI's that I am aware of, just PHP scripts.
> 3) Make sure that no insecure protocols (plaintext passwords) are enabled.
> Note that POP and IMAP might use plaintext passwords, depending on what
> servers/clients are used.
So should I be installing IMAP with SASL? Never done that before,
this should be interesting. Would you know offhand how that would
impact Outlook as an IMAP client?
> 4) Go over every interior system very carefully and make sure that everything
> installed on those boxes is safe and that all security fixes are in place.
Reasonable for Linux, but secure Win2K seems like an oxymoron. Still,
I'll find some tools to do this.
> Make sure that you religiously keep the box up to date w/respect to RedHat
> errata. And of course there's the standard stuff like making sure that all
> passwords are GOOD passwords, and not routinely logging into the box (or any
> other system) as root.
SOP for me (not that it mattered).
> And never, never, build anthing as root. You should
> only be root for the specific commands that demand it (sudo is a wonderful
> tool).
Don't I have to build certain apps as root so everyone can use them?
I am thinking of user apps at the moment (sane, openoffice), but there
are probably server apps that would apply to as well. Setting up a
sudoer file is easy enough, but how does that add security? Doesn't
that open up SUID issues?
>To be enven safer, don't use the server/firewall as a workstation.
> That's where a dedicated firewall and/or firewall/server is nice.
That's fine, I will use the old laptop. This way if I have to blow it
away periodically the mail server won't have to be restored every
time. And I am gonig to look into using a VPN internally; we're
running 100MB ethernet, so we have the bandwidth and aside from the
laptop there is plenty of CPU in the machines.
Thank you for responding, and for recommending a plan to follow. It
is sane and, hopefully, effective.
Kind regards,
jh
- Next message: Jared: "Re: Feedback solicited - best way to harden a mail/web server?"
- Previous message: sky-diving: "cryptoapi"
- In reply to: Jim Levie: "Re: Feedback solicited - best way to harden a mail/web server?"
- Next in thread: Jim Levie: "Re: Feedback solicited - best way to harden a mail/web server?"
- Reply: Jim Levie: "Re: Feedback solicited - best way to harden a mail/web server?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|