Additional security enhancements for pSPTs

[arlake228]

From @arlake228 on March 14, 2015 12:3

Original issue 854 created by arlake228 on 2014-02-26T17:31:24.000Z:

The following were suggested as options for future pSPT releases to enhance the security profile of the system:

a) SELinux enhancements - are we running in permissive right now?

b) changing filesystem components to immutable (RNP may be able to assist with this)

c) enforcing stronger passwords for users, restricting previous use, password timeouts/locksouts, and perhaps enforcing time limits.

I am not a fan of some of these in general, since it will force bad sociological behavior. E.g. writing down passwords, or '+1'ing the numbers in the password each expiration date.

d) better set of instructions for integrating host with campus wide configuration management (CFengine, Puppet, etc.) and authentication systems (kerberos)

e) review running services, and disable everything we don't need on this host. E.g. running this on a live CD:

chkconfig --list | grep '3:on'

Produces a long list of things we may not need.

Relatedly, see what is listening and make sure it needs to be listening:

netstat -tulpn

f) Harden sysctl. These suggestions are a little old (~2010?) so they may need to be updated:

# Turn on execshield
kernel.exec-shield=1
kernel.randomize_va_space=1
# Enable IP spoofing protection
net.ipv4.conf.all.rp_filter=1
# Disable IP source routing
net.ipv4.conf.all.accept_source_route=0
# Ignoring broadcasts request
net.ipv4.icmp_echo_ignore_broadcasts=1
net.ipv4.icmp_ignore_bogus_error_messages=1
# Make sure spoofed packets get logged
net.ipv4.conf.all.log_martians = 1

g) Disable Unwanted SUID and SGID Binaries.  This has a couple of parts:

#See all set user id files:
find / -perm +4000
# See all group id files
find / -perm +2000

YMMV on what we want to correct.  

Cutting down on world writeable things:

find /dir -xdev -type d \( -perm -0002 -a ! -perm -1000 \) -print

As well as things with no owner:

find /dir -xdev \( -nouser -o -nogroup \) -print

This last one is a bit of a problem for us:

[root@localhost ~]# find / -xdev \( -nouser -o -nogroup \) -print
/etc/aliases.db
/opt/perfsonar_ps/ls_registration_daemon/etc/ls_registration_daemon.conf
/opt/perfsonar_ps/snmp_ma/etc/daemon.conf
/opt/perfsonar_ps/PingER/etc/daemon.conf
/opt/perfsonar_ps/PingER/etc/pinger-landmarks.xml
/opt/perfsonar_ps/toolkit/etc/enabled_services
/opt/perfsonar_ps/toolkit/etc/external_addresses
/opt/perfsonar_ps/perfsonarbuoy_ma/etc/daemon.conf

h) Consolidate logging, and offer a couple of log scraping/identification tools.  We have done a good job lately on this, it could use a review.  A thread I found that outlines a couple of these:

http://serverfault.com/questions/89923/what-tool-or-scripts-do-you-use-to-audit-a-linux-box

We may want to enable logwatch/logcheck and send a daily email to the root user or use auditd, at a minimum.  

i) BCP rules for SSH:

http://www.cyberciti.biz/tips/linux-unix-bsd-openssh-server-best-practices.html

j) other host IDSs:

SNORT: http://www.snort.org

AIDE: http://aide.sourceforge.net

Copied from original issue: perfsonar/project#852

[arlake228]

Comment #1 originally posted by arlake228 on 2014-02-28T16:16:41.000Z:

For the "no owner, no group" thing, I'm not seeing it on my host:

[root@desk146 ~]# find /opt -xdev ( -nouser -o -nogroup ) -print [root@desk146 ~]#

There's some sysctl knobs suggested by RH. I'm not positive how old they are, but: http://docs.fedoraproject.org/en-US/Community_Services_Infrastructure/1/html/Security_Policy/HostGeneralSecurity-Standard-Sysctl.html

[arlake228]

Comment #2 originally posted by arlake228 on 2014-03-24T16:29:44.000Z:

<empty>

[arlake228]

Comment #3 originally posted by arlake228 on 2014-05-06T18:18:37.000Z:

This is exploratory to figure out what we should do.

[arlake228]

Comment #4 originally posted by arlake228 on 2014-08-13T18:11:45.000Z:

<empty>

[arlake228]

Comment #5 originally posted by arlake228 on 2014-10-07T11:59:12.000Z:

From Alex on 10/6/2014:

Hello,

Have the developers discussed any of these ideas/proposals for improving the Toolkit hardening?

1) Use the chattr command[1] to enable the 'immutable' flag in conjunction with elevated kernel securelevel setting. Specific flags could be applied to files to be read-only,

2) Use by default some sort of chrooted / jailed / contained environment (using any of Docker / KVM / Jails / chroot) to run the public facing services/processes?

Assuming there is no negative impact in the measurements or the host's overall performance by this approach, this may help limit the footprint of some kinds of vulnerabilities

This approach also may improve the recovery time for rebuild - deploy and run - a new instance (created from a template).

2.1) The contained environment could be locked by changing the host's filesystems attributes for hardening and also elevating the kernel securelevel

3) Other layers of security could be:

 3.1) include by default iptables rule set based on the recommended perfSONAR firewall rules that could be easily enabled by the admin

 3.2) include by default the installation of the mod_security in the HTTP Server, with a reasonable ruleset.

-Alex

[arlake228]

Comment #6 originally posted by arlake228 on 2015-01-27T14:42:07.000Z:

<empty>

[arlake228]

Comment #7 originally posted by arlake228 on 2015-01-30T18:48:02.000Z:

<empty>

[arlake228]

Comment #8 originally posted by arlake228 on 2015-01-30T18:49:20.000Z:

Issue 1023 has been merged into this issue.

[arlake228]

Comment #9 originally posted by arlake228 on 2015-02-02T16:55:19.000Z:

Should also revisit the question if the R&E only bwctld.limits options should be integrated into the toolkit, and if it should be on or off by default.

http://fasterdata.es.net/performance-testing/perfsonar/esnet-perfsonar-services/esnet-bwctld-limits-file/

I vote for integrating it, but off by default.

[laeti-tia]

Wrt SElinux, the default toolkit configuration is to set it to disable and for the bundles, we say in the installation guide to set it to permissive. We have separate issue to track SElinux configuration: https://github.com/perfsonar/toolkit/issues/68

[igarny]

Hi guys,

Just an observation from my side. I believe no one (or very few) have raised concerns with security level applied by perfSONAR. Unless you are aiming at some huge development effort being saved, I would vote against introducing the complexity of SELinux. I would expect that with this improved security we will be facing a new plethora of compatibility issues and will not gain any public acknowledgement. At least this is my read of the survey results.

Best regards, Ivan