Security Basics mailing list archives

RE: RHEL 5: security of a default install and hardening


From: <jmacaranas () fxdd com>
Date: Wed, 6 Feb 2008 16:14:33 -0500

http://www.infosec.org.uk/media/archive1/papers/Securing_&_Hardening_Lin
ux_v1.0.pdf

     >-----Original Message-----
     >From: listbounce () securityfocus com
     >[mailto:listbounce () securityfocus com] On Behalf Of Erling Ringen
     >Elvsrud
     >Sent: Wednesday, February 06, 2008 4:00 AM
     >To: security-basics () securityfocus com
     >Subject: RHEL 5: security of a default install and hardening
     >
     >Hello,
     >
     >I have recently started to work with RHEL 5 and administration of
     >RHEL
     >in general. At my current workplace they have used
     >Bastille earlier to harden RHEL 4 machines, but Bastille does not
     >work
     >properly on RHEL 5 (When run, it gives error messages about not
     >being
     >able to detect which version of RH that is installed, a new
version
     >was announced to be released by the 14. january, but is not
     >published
     >yet).
     >
     >The servers I work with are not very accessible from the Internet,
     >and
     >behind one or several firewalls.
     >
     >I have also a internal hardening document to work from that
     >describes
     >standard steps in the organization for hardening Linux and Unix
     >machines.
     >Some of these steps are confusing and/or I doubt how much impact
     >they
     >will have in terms of increasing the security.
     >Like for instance:
     >
     >- "netstat and uucpd must be deactivated unless really needed". I
     >can
     >understand that uucpd should be deactivated (where is it activated
     >anyway?), but netstat? it is really useful for debugging problems
     >and
     >if an intruder has a local shell available it should not be that
     >difficult to get a working
     >netstat from outside anyway. Do you think removing or removing
     >execute
     >permissions for all users (using a special group like wheel) for
     >netstat)
     >will increase the security of a system noteably?
     >
     >- "verify that the permissions of /etc/services are 600". Unless
     >customized, this file is public information avaliable from IANA.
Is
     >it
     >really worth
     >breaking standard unix/linux behaviour to alter permissions of
this
     >file?
     >
     >Do you think a default install of RHEL 5 needs much constomization
     >to
     >be sufficiently secure for fairly normal tasks like application
     >servers as
     >long as it is placed behind firewalls and the services available
     >from
     >the internet are sufficiently.
     >
     >Do you know any alternatives to Bastille that works with RHEL 5 or
     >what is happening with the Bastille project? it seems farily slow
     >moving...
     >
     >Thanks,
     >
     >Erling

--------------------------------------------------------------------------------------------------------
This message and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom it is
addressed. It may contain sensitive and private proprietary or legally
privileged information. No confidentiality or privilege is waived or
lost by any mistransmission. If you are not the intended recipient,
please immediately delete it and all copies of it from your system,
destroy any hard copies of it and notify the sender. You must not,
directly or indirectly, use, disclose, distribute, print, or copy any
part of this message if you are not the intended recipient. 
FXDirectDealer, LLC reserves the right to monitor all e-mail 
communications through its networks. Any views expressed in this 
message are those of the individual sender, except where the 
message states otherwise and the sender is authorized to state them.

Unless otherwise stated, any pricing information given in this message
is indicative only, is subject to change and does not constitute an
offer to deal at any price quoted. Any reference to the terms of
executed transactions should be treated as preliminary only and subject
to our formal confirmation. FXDirectDealer, LLC is not responsible for any
recommendation, solicitation, offer or agreement or any information
about any transaction, customer account or account activity contained in
this communication.


Current thread: