[LinuxUsers] Checklist for CentOs server setup

[Jeff Lasman]

On Monday 06 August 2007 04:45 pm, Randall Whitman wrote:

> So I
> am posting this checklist to this maillist and hoping some of our
> list members will be able to review the checklist and point out any
> important omissions.  This is for a customer who called me last week,
> although the subject matter has some overlap with the ongoing
> discussion about Aldo's setup.

Randall, please feel free to call me at any time; you've been very 
helpful to me and I don't mind returning the favor.

> * partitioning
>   /   root should be read-only except during maintenance

Why?  I've never understood why / should be read-only.  In a properly 
designed install (as ours unfortunately aren't) 
probably /usr, /bin, /sbin.  But for example, if / is read-only, so 
is /root, and /root can't be read-only.  My guess is that you're trying 
to economize on the number of partitions.  There are lots of good 
reasons to do that, but lots of good reasons not to, as well.

> (how auto-updates?)

Do auto-updates on a staging server, even a cheap one on a home 
connection.  Know when you're updating your Internet facing public 
servers.

> /var  needs read-write probably not execute 
>   /tmp  needs read-write should be no-exec

While these are good, they're not that important; a hacker can always 
run "perl /path/to/something" or "python /path/to/something" or 
"php /path/to/something" easily enough.

>   /home presumably minimal use on an application server

If a webserver is going to host more than one site, then putting the 
sites in /home makes sense to easily compartmentalize access by 
username.  If individuals are responsible for their own sections of a 
large site, then /home makes sense, along with symbolic links (don't 
forget to set apache to follow them) to compartmentalize access in the 
same way.

> * services/daemons to run vs uninstall
>   Apache + apps needs to run for web app
>   check what modules / app-server-framework (e.g if the app needs
> tomcat) the respective apps

Start with nothing.  When we install CentOS we install NOTHING extra; we 
uncheck everything (in my case, I also check joe, because it's my 
editor of choice, but most other editors are installed by default).  
Basically we end up with a box that can connect to the web and do 
nothing else.

Then we shell into the box and using yum install ONLY the RPMs we need, 
allowing yum to figure out the dependencies.

> * Hardening - /etc/hosts.allow
>   HTTP port needs to be open for web app, probably HTTPS too
>   what exactly needed with SMTP for root/cron mail
>   determine whether we need SSH from remote for maintenance
>   close everything unneeded

We do this with APF+BFD firewal, not with any manual manipulation of 
hosts.allow/hosts.deny.  For SMTP we open:

25 smtp
110 pop3
143 imap
587 authenticated submission

> * Firewall
>   how much can I block outgoing SMTP without losing root/cron mail?

Outgoing email goes on any high port.

>   SSH if remote maintenance

ssh port is 22, but you may want to use something else as part of 
security by obscurity; ask me the alternate port we use.

If you're going to allow access then be sure to enforce a good password 
policy.

> * Updates - automated or manual/periodic? (asking customer
> requirement/pref) plan what happens when kernel/glibc update requires
> reboot

If you're using RHEL/CentOS you shouldn't need a glibc update (RHEL 
packages take care of that for you; ask me how if you're not sure); 
only kernel updates should require a reboot.

(Again, using RHEL/CentOS) you can allow kernel updates if you want, but 
that won't run them; they'll only run when you reboot the server.

See above about a staging server.

> * Monitoring, Detection, Notification  [logging]
>   Nagios

We use Nagios only to monitor external services; we use scripts on the 
servers to monitor internal services, etc.

>   chkrootkit - what frequency?

We run it in cron.daily; you can run it more often.  We prefer rkhunter.

>   tripwire/snort/etc - intrusion detection - which one do you all
> use?

Tripwire, also in cron.daily.

>   determine to which address(es) should root/cron mail be sent

If you set up cronjobs carefully to only send you exceptions, then you 
can send the mail to your main inbox.

> Thanks in advance.

Anyway, I've already given away too much <smile>.

Jeff
-- 
Jeff Lasman, Nobaloney Internet Services
P.O. Box 52200, Riverside, CA  92517
Our jplists address used on lists is for list email only
voice:  +1 951 643-5345, or see: 
"http://www.nobaloney.net/contactus.html"