[CentOS] Security checklist for new Centos server?

Sat Jul 21 07:22:03 UTC 2007
M. Fioretti <mfioretti at mclink.it>

On Fri, Jul 20, 2007 15:12:34 PM -0600, Stephen John Smoogen
(smooge at gmail.com) wrote:

> My first point is going over the long list
> http://iase.disa.mil/stigs/stig/unix-stig-v5r1.pdf and figuring out
> what meets the local environment.

> >- set up only ssh2 on a non standard port
>
> Depending on the environment, I have found that this is not a useful
> tool. The problems I have encountered is that it just turns off some
> of the attacks.

I agree, but I have noticed in the past, and read in several places,
that it's not security through obscurity: its main usefulness would
not as much extra security as saving a bit of bandwidth and server
load from automated attacks with off the shelf scripts.

> But if the target is considered worthwhile it does nothing as a slow
> nmap will point out that SSH is running on another port.

of course, but that's why I listed it together with SPA

> [Oh I will put ssh on the telnet port as no one would explain
> that.. and that way I can use a 5 letter password.]

long passwords are another item on the list.

> Other issues are that it can flag other security tools that might be
> used in an environment looking for non-standard traffic.

sorry, I am not sure I understand this. Care to elaborate?

> I do not know enough about this to answer, but its name does not imbue
> trust in me :). [E.G. I would believe more in a 3-5 packet approach.
> Query, ReverseQuery, Answer-To-RQuery, Authorization]

Is this scheme documented anywhere?

> >- set up itables (what would the safest iptables script to do all and
> >  only the services listed above?
> 
> I think that if security is essential, then one should know iptables
> first.. then use a script.

Me too, but it's a chicken-and-egg situation. iptables and ssl are
among the worst documented areas of what a learning sysadmin should
learn. I have NO trouble to study iptables, but doing it with a
tutorial or man page on one side, and a working, _recent_ script (some
of the most readable docs I've found are relatively old) would be much
more efficient. Hence my request of sharing iptables commands working
today.

> Not knowing iptables and relying on a script usually ends up with
> lots of email to some firewall list about why I cant talk to my
> remote server anymore.

Of course, I wouldn't run such a script, or any new tool suggested in
this discussion, before being sure to understand what each line and
option does.

Any further feedback is welcome!

        Marco

--
The Family Guide to Digital Freedom:           http://digifreedom.net