Zone 1 refers to the NPCF data center floor as described in Zoned Network Security. All systems in this zone must be vetted by security as stated in the OLD NCSA Network Security Zone Policy. This document presents the steps to vet such hosts.
Host is identified
System admins are supposed to have their machines jailed in a firewalled subzone while being built, until they are ready to be vetted by security. However, this subzone is not yet configured by networking. Until then, system admins may come to security to state they are ready, networking may refer them to security before giving them a Zone 1 IP, or the security teams Bro IDS may detect a new host in the data center. Regardless of how the host comes to the attention of the security team, it will go through the following procedures at a minimum.
There are several pieces of information that the security team will record for each host. This includes:
- IP Address(es)
- List of administrators (must contain at least one FTE)
- System's home group (e.g., storage, networking, PSP, etc.)
- Machine's general use and purpose (e.g., Web server for the LSST project)
- Operating System
- Necessary remote services (e.g., SSHD, HTTP/S, FTP, etc.)
Access for security
NCSA security operations should have access to any machine in Zone 1 in case of an emergency. As this is also needed for vetting, the first step will be to get access for NCSA security.
Using the list of services provided by the system's admin, the security team will make sure that those are the only ones running with netstat and scan-sec/nmap. They will also construct iptable rules and/or tcp wrappers as a back up to ensure additional services are not turned on by mistake. This will have to be done for each network interface, shutting down any unneeded interfaces (e.g., wireless). It is important that the machine not be a bridge between zones. Finally, Security will work with admins to remove unnecessary startup services such as Cups.
Systems should only allow root login from the console, and should avoid other local accounts if at all possible. Instead, Kerberos, OTP or LDAP should be used for user authentication. For a standard Linux system the following are checked.
- Check the /etc/shadow file
- No default passwords are set, and default accounts that are not needed disabled
- Only root should have a password entry
- Check the /etc/passwd file
- Compare the list of users with what the admins expect. For hosts that use LDAP this should be an empty file. Disable unneeded system accounts here, or at least remove login shells.
- Check for users with id of 0
- Check /etc/group
- Check for users in the wheel or admin groups
- Check root escalation
- Check configuration of /etc/sudoers if that is used for escalation
- If this is a host that does not allow root escalation then make sure there is no /root/.k5login files or sudo access (/etc/sudoers or the /etc/group wheel group).
- Root escalation requires or Multi-factor authentication is non-administrators are allowed on the system
- Utilize Multi-factor or Aurhenitcation or an bastion with OTP for any administrative interfaces
- Cerberus 1 to 4 are available for most machines to use in conjunction with firewall rules and wrappers.
- Check .ssh folders for authorized_keys files
- Accounts with ssh_keys should have precautions for the use of the key. e.g. 'from' directives, user matching in sshd_config to limit access, etc.
SSH should be configured to use version 2 only, not allow remote root login, and have only the necessary authentication mechanisms present. It is preferable that local passwords and SSH not used. Administrative interfaces behind a security bastion can use SSH keys though.
Host-based IDS We use OSSEC for a host-based intrusion detection system at the NCSA. This provides file integrity checking and other services for hosts on which the client is installed. We encourage its use on any system with a physical disk with users logging in. This of course depends on the OS being supported by OSSEC.
Remote and Authenticated Qualys scanning enabled
Setuid/gid & /NFS mounts
On critical systems we may remove unnecessary setuid/gid bits on executables. This is to prevent certain privilege escalation attacks.
For remotely mounted filesystems we prefer to block this for the whole filesystem in the export options. If possible, NFS filesystems should be mounted noexec, nosuid, root_squash, and RO.
Make sure the system is up-to-date on security patches.
DEPRECATED - See this document: System Vetting Procedures