[CentOS] Security checklist for new Centos server?

Mon Jul 23 05:45:38 UTC 2007
Stephen John Smoogen <smooge at gmail.com>

On 7/21/07, M. Fioretti <mfioretti at mclink.it> wrote:
> 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.
>

denyhosts or fail2ban also can help that. THe main issues I had was
that I had automated scans against SSH on other ports. Not as many as
I did with SSH on 22... but they do show up... the attacks seem to be
based on the principle that a lot of backdoors are  hacked ssh servers
running at a high port with usually a poor password. So some
hack-teams are just looking for existing backdoors and pounding away
at them until they figure out which 'default' backdoor it is.

> > 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?

At several places I have worked, our snort/etc servers would look for
SSH on high ports due to the backdoor problem listed above. A lot of
the intrustion prevention tools will auto-block that as bad traffic
also. We spent a couple of days dealing with a client who kept saying
SSH wasnt working.. and it was due to his providers IPS blocking stuff
at 22122 as SSH was only to occur at 22.


>
> > 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!
>

Will try to send some iptables stuff later this week.


-- 
Stephen J Smoogen. -- CSIRT/Linux System Administrator
How far that little candle throws his beams! So shines a good deed
in a naughty world. = Shakespeare. "The Merchant of Venice"