Linux Systems Security Security Design NETS1028 - Fall 2016
Designing a Security Approach Physical access Boot control Service availability and control User access Change control Data protection and backup Management support
Physical Access Risks Simple DOS (denial of service) through damage, disconnnection, powerdown Filesystem corruption can result A server taken offline this way can cause ripple corruption around the network, particularly if the clients are using state-dependent file access mechanisms Ripple DOS can be serious if the downed machine is an authentication server or proxy server Substituting or modifying devices such as disks CTRL-ALT-DEL risks with PC hardware, see https://help.ubuntu.com/lts/ serverguide/console-security.html for how Ubuntu can be configured for this Even when physical damage or substitution is not deemed an issue, there are other physical access concerns related to atypical boot scenarios
Physical Access Risks Attached device compromise via I/O ports or removable media Devices may invoke untested drivers Drivers can supply code to the system at high privilege levels Removable media can be used to supply code, false data, and privilege elevation tools Alternate boot scenarios using removable media are a concern if physical access is permitted Designing around this means a physically secure location and physical access controls, and securing boot control
Boot Control BIOS should not iterate through multiple boot devices, and BIOS should be password protected Grub and LILO boot loaders offer user intervention at boot Both have configuration files which must be protected, should be readable only by root, and have any available password options enabled, locations and file names can vary by distro
Boot Control Both common boot loaders support implementing passwords to perform non-default boot if needed, depending on which distro you are running http://www.gnu.org/software/grub/manual/grub.html http://www.tldp.org/ldp/solrhe/securing-optimizing-linux-rh-edition-v1.3/ chap5sec48.html Remove old boot options after kernel updates if your OS doesn t do it automatically, also remove old kernel files if update was done for security concerns
Service Availability Distro selection and installation is a big factor, it will determine how much work you have to do after the installation completes, distrowatch.com can help The GUI is a luxury, not a necessity, don t install it unless your server's purpose cannot be achieved without it Non-essential software offers opportunities to attackers, even if that software does not run automatically Remove innocuous but unnecessary services to reduce logfile clutter
Service Availability Remove or don t install whatever you don t need, it can be added later if requirements change Software packaging tools don t let you blindly remove software you don t use but which is needed by other software you do use Once your service availability is appropriately trimmed, consider how those services are controlled
Service Control Multiple mechanisms can start services, which ones are even available is distro-specific init and rc scripts are still common, upstart and systemd are becoming more widely implemented Different distros may not start the same services the same way, even if they have the same mechanisms available
Service Control Services may or may not log startup/shutdown and activities Services may have per-service logfiles or just lump their messages in with other services (often distrospecific) Default configurations often start many more services than is actually required
Service Control Resource and capacity limits are often non-existent or inappropriate; reviewing service configurations for these limits is a way to improve service stability and reduce potential impacts of service exploits Users who shouldn t be able to affect running services often can, by exploiting them or simply using them in non-standard ways, or by interfering with resources those services expect to have available, confused deputy problem applies
User Access System users are the most dangerous, consider where and how they can login, and what they can do once logged in Services commonly provide configuration parameters to control what their users can do Web servers, email servers, database servers, etc. usually are capable of managing private user lists and controls but the per-service lists are often not used in favour of simpler unix account reuse
User Access User data must be considered Where is it stored and how, can they impact the filesystem for other users How is access to it shared or controlled, what privileges do users have the ability to give away (DAC vs. MAC vs. RBAC) Removable media, network copying, sharing tools, backup tools are all potential data exposure avenues Data labelling may be relevant
User Access Passwords, remote access and social engineering are rocket fuel for attackers Audits, monitoring, and logging only help identify what happened, they do not prevent it Differentiating between expected system behaviour changes and unexpected changes can be enhanced with intentional change control
Change Control System updates, upgrades, or configuration changes can introduce new exposures or break existing protections Changes should be planned, tested, logged, and verified, software installation and update tools do not normally record what they do, they just do it Virtual machines can be used to test changes to a duplicated server without risk to a production system Change logs should be independent of the system so that a system compromise does not endanger the change logs
Change Control Automated updates are generally discouraged for servers, security updates can be the exception unless you are staging all updates Many software package tools check, or can check, signatures for download validation Software package tools do check dependencies Even with services, users, and change covered, data can still be at risk
Data Protection Storage of data is your primary protection opportunity Container access controls such as file permissions and ACLs, or storage control mechanisms such as database permissions are the basic tools Encrypting data in storage can be useful, but can also be a substantial overhead for the system Encrypted root filesystems is possible, but kernel maintenance becomes more difficult, better to cleanly separate root filesystem from any sensitive data storage
Data Protection Encrypting data in transit is a consideration, connection establishment is the primary attack vector, ssl/ssh is the primary widespread defense along with vpns Version control systems require extra attention Data replicates and backups must also be considered
Backup Backup of systems and data are separate topics Backup physical storage is a consideration Restoration should include tamper detection Backups can be encrypted, not just compressed Backup access and aging can complicate things Backups, like other aspects of security, have costs so management support becomes very important
Management Support Security requires tools, hardware, and personnel Those normally require funding and allocation of resources The security role may not be making the business decisions, but may instead be lobbying for them Security should be part of the business strategy and plan Ask the folks at the NSA, Ashley Madison, or in a presidential campaign if it is important to allocate sufficient resources and focus to security