> I recently put together a web server, running FC3. I'm looking to hear
> some tips for what are the best security practices for the box. I'm
> not looking for the box to be put into lock-down, but it is for a small
> web hosting buisness, with several dozen virtual hosts.

There are lots of guides on this, but my main tips would be:

Run only a web server on that host. Disable all other unnecessary services.
For instance, if you have DNS servers or email servers put them on separate
physical hosts. Computers are cheap these days.

Keep the software up to date. I'm not a fan of automatic updates, I like to
verify everything myself.

Unless you absolutely have to, I recommend avoiding extras like the
database or PHP functions. A web server with cgi, perl, php, mysql is much
more likely to encounter security problems than a plain web server. If you
need these extras perhaps put them on a separate physical host. This way if
there is a security problem, you can disconnect and wipe that scripting
host while keeping your main web server clean.

Also how you might configure everything and your network depends to a large
degree how much you 'trust' your customers, if they will be logging in. For
example what is their level of technical expertise. Are they likely to make
mistakes such as installing insecure cgi/php scripts.

--
Jem Berkes
Software design for Windows and Linux/Unix-like systems
http://www.sysdesign.ca/

In article <1143045497.355728.323650@g10g2000cwb.googlegroups. com>, Jeff Plotzke wrote:
> Hello all,
>
> I recently put together a web server, running FC3. I'm looking to hear
> some tips for what are the best security practices for the box. I'm
> not looking for the box to be put into lock-down, but it is for a small
> web hosting buisness, with several dozen virtual hosts.

If you can get away with removing PHP, do it.
Most crackers don't seem to want your box these days,
they just want to spam through it, and lusers with
downrev PHPnuke/phpBB/Joomla type junk will let them do it.
This crap is especially popular with phish spammers.

If you have to support user-supplied PHP programs,
rename /usr/lib/sendmail and /usr/sbin/sendmail.
Then link those names to /bin/true. (Or link it to
your burglar alarm...) Let PHP's broken-
by-design mail() function fail. Anybody who wants
to send mail from PHP can just popen() your real sendmail
after you tell them where it is.
Anybody who can't make that change to their PHP
programs shouldn't be installing PHP programs on your
machine.

Next, make a file system you can mount -o noexec.
Use it for /tmp, /var/tmp, Squirrel Mail's data directory,
/var/log/apache, anywhere the Web server can write.
Apache has no business creating its own executables.
Don't forget to remount it -o exec during the few seconds
yum is running. Update scripts run in those directories.



> Some specific questions I have:
>
> -Updates: Is it wise to do nightly yum updates? I don't think that I
>
> -Log Files: Is it advisable to keep a separate copy
> elsewhere in case of a hack attempt?

Methinks you're triple-locking the upstairs window while
leaving the barn door ajar.
Crackers have hundreds of thousands of easily exploited
Linux-Apache-MySQL-PHP boxes these days. (And that's
just at Theplanet.com...) They're looking for low-
hanging fruit, in wholesale lots. Remove PHP (or at least
obscure sendmail) and move sshd somewhere besides port 22
and they'll pick on someone else's box.

Cameron


--
NewsGuy.Com 30Gb $9.95 Carry Forward and On Demand Bandwidth

Cameron L. Spitzer wrote:
> In article <1143045497.355728.323650@g10g2000cwb.googlegroups. com>, Jeff Plotzke wrote:
> Remove PHP (or at least obscure sendmail) and

Is this "real" sendmail, or does postfix's sendmail replacement count
too?

> move sshd somewhere besides port 22 and they'll pick on someone
> else's box.

I've heard that comment before. It seems that some people are fans of
moving away from 22 and others are fans of securing sshd's config
tighter than the defaults. Certainly the latter is a must.

Cheers...

--
PLEASE post a SUMMARY of the answer(s) to your question(s)!
Show Windows & Gates to the exit door.
Unless otherwise noted, the statements herein reflect my personal
opinions and not those of any organization with which I may be affiliated.

In article , Kevin the Drummer wrote:
> Cameron L. Spitzer wrote:
>> In article <1143045497.355728.323650@g10g2000cwb.googlegroups. com>, Jeff Plotzke wrote:
>> Remove PHP (or at least obscure sendmail) and
>
> Is this "real" sendmail, or does postfix's sendmail replacement count
> too?

Any "sendmail." The cracker/spammer wants to put his
mailing script on a thousand compromised servers.
His script expects PHP mail() to work. Or maybe it
expects /usr/{lib,sbin}/sendmail to accept a message on
STDIN and a thousand addresses in @ARGV.
That's because it works on 99 out of a hundred LAMP
boxes. If it doesn't work on your box, is he going
to spend a lot of time troubleshooting?


>
>> move sshd somewhere besides port 22 and they'll pick on someone
>> else's box.
>
> I've heard that comment before. It seems that some people are fans of
> moving away from 22 and others are fans of securing sshd's config
> tighter than the defaults.

The two are not mutually exclusive. Do both if you like.
Perhaps you have so few users you can find out where
all the authorized clients are and block the rest of
the world in iptables. Perhaps your users are smart enough
to create key pairs.

The cracker needs to compromise hundreds of boxes for his
spam run. So he needs to run his dictionary attack against
thousands or tens of thousands of targets. So he needs to scan
a hundred thousand IPAs in some hosting range to find sshds
to beat on. Is he going to scan 65 thousand ports on each of
the hundred thousand IPAs, or just the port where sshd usually is?
Try an experiment. Open sshd on port 22 and another sshd on
some random port between 12 thousand and 42 thousand.
See which one experiences dictionary attacks.

There's not *much* security in obscurity. But when you and
some other guy are running from a bear, you don't
need to be faster than the bear, just faster than
the other guy. Why be low-hanging fruit?


Cameron



--
NewsGuy.Com 30Gb $9.95 Carry Forward and On Demand Bandwidth

of course, if you were running OpenVMS, you
could run PHP or Perl or whatever you want
and not worry about hacks or viruses because
vms cannot get viruses or hacked ... your web
server and apps running under it would run with
NO priviledges except mail and vms mail cannot
and never has had or passed viruses ...

In article <1143641757.110497.33550@z34g2000cwc.googlegroups.c om>, bob@instantwhip.com wrote:
> of course, if you were running OpenVMS, you
> could run PHP or Perl or whatever you want
> and not worry about hacks or viruses because
> vms cannot get viruses or hacked ... your web
> server and apps running under it would run with
> NO priviledges except mail and vms mail cannot
> and never has had or passed viruses ...

The PHP and Perl-CGI exploits I've been talking about
occur at the application level, not the operating
system level. If you installed last June's
phpBB or PHP Nuke on Apache on OpenVMS,
and got it working as designed, it would have the
XML-PHP vulnerability. In order to work as designed
it's got to have a directory under DocumentRoot
that the Apache process UID can create and execute
files in. If it's immune to that exploit,
it won't run the way it's supposed to either.
The exploit is used to send spam. It uses the
mail() function in PHP. If the mail() function isn't
working, PHP Nuke isn't working.

I couldn't find a price for OpenVMS on HP's Web site.
Must be really expensive.


Cameron



--
NewsGuy.Com 30Gb $9.95 Carry Forward and On Demand Bandwidth