System Security Guide for Snare Server v7.0

Transcription

1 System Security Guide for Snare Server v7.0 Intersect Alliance International Pty Ltd. All rights reserved worldwide. Intersect Alliance Pty Ltd shall not be liable for errors contained herein or for direct, or indirect damages in connection with the use of this material. No part of this work may be reproduced or transmitted in any form or by any means except as expressly permitted by Intersect Alliance International Pty Ltd. This does not include those documents and software developed under the terms of the open source General Public Licence, which covers the Snare agents and some other software. The Intersect Alliance logo and Snare logo are registered trademarks of Intersect Alliance International Pty Ltd. Other trademarks and trade names are marks' and names of their owners as may or may not be indicated. All trademarks are the property of their respective owners and are used here in an editorial context without intent of infringement. Specifications and content are subject to change without notice. Page 1 of 8

2 Table of Contents 1. General Overview Snare Server Packages System Permissions Post-Install Configuration Page 2 of 8

3 1. General Overview About this Guide This document provides a brief overview of the security configuration of the Snare Server, to aid in the development of business security plans or documents. Other resources that may be useful to read include: Snare Server User Guide Snare Server Installation Guide 1.1. Snare Server The Snare Server is a security appliance, and does not supply general user computing capabilities. As such, many security guidelines designed for multi-user interactive systems are not relevant to the Snare Server, due to the lack of facilities such as interactive user logings, exported services (eg: file shares), or uncontrolled incoming data. In addition, the extremely narrow range of packages installed on the Snare Server implies that normal techniques used on more general-purpose user based operating systems, to restrict access to unnecessary services and applications, do not generally apply to Snare. As such, this document attempts to present recommendations for the subset of generally recommended security practices that are appropriate to a security appliance such as the Snare Server. Intersect Alliance International Pty Ltd Page 3 of 8

4 2. Snare Server Packages 2.1. Initial Installation The Snare Server uses a cut down, customised, and hardened version of the Ubuntu operating system. Key packages from Ubuntu provide the general infrastructure, whilst updated kernel updates and device-related packages provide enhanced hardware compatibility. The packages installed by the Snare Server installation CD have been trimmed to only those that are required: Directly by the Snare Server for normal operation (eg: the Apache web server) Indirectly, as dependencies of the above packages (eg: the libssl libraries, to implement encryption within the web server), or directly, for ease of system administration and support. Traditional operating systems (such as Windows) generally use a variety of firewall or application-level blocks to restrict access to services that are not required. The Snare Server in contrast never actually installs services that are not needed for day-to-day operation; however, within the Snare Server wizard, a firewall can be activated, to provide 'defense in depth' protection against custom package installation errors Service Configuration There are three exceptions to the above general rule. The "SSH", "FTP" and "Samba" services may be turned on, or off, under the control of the Snare Server system administrator. In the case of SSH and FTP, the services facilitate batch eventlog uploads to the Snare Server in situations where the host agency cannot push data to the Snare Server in real-time. Samba provides the capability to access the Snare Server log archive in read-only mode, for system backup purposes. If these services are required, or need to be disabled, the Snare Server Configuration Wizard provides the administrator with the capability to modify the appropriate settings Package Updates As part of the Snare service and support facilities, the Snare Server support team monitors security issues that may affect packages on which Snare relies. If a security issue is likely to affect the Snare Server, package updates are included within the normal Snare Server update process. Intersect Alliance International Pty Ltd Page 4 of 8

5 3. System Permissions 3.1. User Accounts There are four key system accounts installed by default on the Snare Server: www-data snarexfer snare root Normal user accounts are neither required, nor recommended for the Snare Server www-data The www-data account is a non-interactive account (i.e: it does not allow logins). The sole purpose of the account is to run the apache web server, and execute Snare's web-based user interface. It has permission to read, and modify files and directories within the following areas of the Snare Server: The /var/www/html directory, and subdirectories. This directory contains the various scripts that provide a web-based user interface for the Snare Server. The /data/snare directory, and subdirectories. This directory contains the event collection services. The /data/snarearchive directory, and subdirectories. This directory contains log data that is received from remote systems. Logs are readable by any authenticated, logged on user, but are only writable by either the authenticated root user, or the www-data account. The /data/snaredata directory Snare stores general application data in a small database. This directory holds the configuration database, and associated files. The /data/snareconfig directory. This directory holds files help Snare control operating-system configuration settings that cannot be stored in an internal configuration database. For example, the Snare Server will write the name of the preferred 'NTP' (time) server to this directory (as specified by the Snare Administrator, on the General Configuration Items page), which will be picked up by the 'ntpdate' application, and used to synchronise the date of the Snare Server with another server. The /data/snaredatastore directory. Files utilised by some objectives within the Snare Server web interface, that generally do not need to be accessed directly from a users web browser. Examples include raw results from the 'OpenVAS' vulnerability scanner. The /data/snarerescache directory. Snare caches query results in order to make your objectives run faster. This directory stores the cache data that is currently in-use. The /data/snaretransfer directory. Used to hold data from the /data/snarearchive directory, whilst preparing a CD or DVD full of information to archive. The /data/snareupdate directory. Used as part of the Snare Server update process to hold the uploaded, cryptographically verified Snare Server update file prior to application of the changes. It should be noted that the www-data user is allocated some semi-privileged capabilities by the Snare Server, in order to access select applications with high level privileges. Functions such as CD/DVD burning, IP Address changes, or system reboots, require more direct access to the hardware and/or increased privileges. Access to these privileged functions is controlled through the Snare global argument validation capability, which undertakes checks including, but not limited to: The entire command and argument group does not exceed 1024 bytes (to negate buffer overflows). Characters other than a specified acceptable group (a-z, A-Z, /-) are eliminated from the argument list. Intersect Alliance International Pty Ltd Page 5 of 8

6 Additional argument verification is also undertaken on a case-by-case basis where user input is required for a privileged command (e.g. IP addresses are verified to be of the format nnn.nnn.nnn.nnn) Full paths to invoked executables are embedded within the Snare Server application, and are not modifiable by Snare Server users snarexfer The snarexfer account has limited upload privileges to the directory /data/snarecollect, and subdirectories thereunder. It has read privileges to other world-readable areas of the Snare Server system. In general, however, we recommend turning off both the FTP and SSH subsystems via the 'General Configuration Items' area of the Snare Server, unless either or both of these capabilities are required operationally snare The snare account is a system administration account, which should only be used under instruction from your Snare Server support team. It is recommended that the account password be treated similarly to a normal system administration password, and secured appropriately. The snare user has privileges roughly equivalent to a traditional unix 'root' account root The root account is a system administration account, which should only be used under instruction from your Snare Server support team. It is recommended that the account password be treated similarly to a normal system administration password, and secured appropriately Authentication Settings Although the Snare Server does not provide general purpose computing resources, password level controls, compatible with most modern regulatory compliance frameworks, are available. The Snare Server includes some restrictions on password length and complexity by default, in both the Snare Server web interface, and at the operating system. However, within the Snare Server setup wizard, the Administrator can turn on "Enhanced Security for Operating System Accounts", and "Activate Password Expiry in the Snare Server". This will force accounts to implement mandatory password rotation every 90 days. In addition, "Enhanced Password Security" can be enabled to enforce additional controls in the Snare Server, including: Minimum password length (8 characters) Passwords must contain both alpha, numeric, and other characters Dictionary and simplicity checks Password history (5 passwords) Last Password similarity checks Intersect Alliance International Pty Ltd Page 6 of 8

7 4. Post-Install Configuration 4.1. Regulatory Compliance As part of the Snare installation, and configuration, several default configuration files are modified in order to help the Snare Server comply with key security regulation frameworks, such as NISPOM Chapter 8, PCI DSS and Sarbanes-Oxley. In particular, the following files are upgraded, or should form part of your NISPOM post-installation changes: Apache & PHP security configuration Various configuration changes are made to the default apache and PHP configuration files, including, but not limited to: Reducing the amount of data returned by the web server, in the server HTTP response header. Turning off server version and virtual hostname in HTTP responses Blocking the TRACE call Blocking Range and Request-Range headers. Turning off default Error 400 responses. Turning on frame-related XSS protection. Blocking ASP tags Disabling certain php functions that Snare does not use. Blocking php version information from being returned to remote systems. Adjusting resource limits. Changing the acceptable SSL ciphers to a restricted, high security subset SSH (secure shell) configuration SSH can be enabled or disabled from the Snare configuration wizard. When enabled, the ssh server configuration is modified to increase the resistance of the ssh server to attack in the following areas: Restrict protocol to SSH version 2 only. Privilege separation, and 'Strict file permission' mode is turned on. The option KeyRegenerationInterval has been set to '3600 seconds'. KeyRegenerationInterval specifies the number of seconds the server should wait before automatically regenerating its key. This is a security feature to prevent decrypting captured sessions. Logging has been enabled, and has been configured to send data to the local syslog server. This is picked up and recorded by the Snare Server. Although the Snare Server has very limited user login facilities, the SSH server has been configured to block individual users from overriding any of the core ssh server security controls (rhosts/known hosts). Block the most extremely insecure user passwords Force security warning and login banners to be printed VSFTP (File Transfer) Configuration VSFTP can be enabled or disabled from the Snare configuration wizard. When enabled, the VSFTP server configuration is modified in the following areas: Only allow authenticated users Log uploads and downloads Display a banner on login Login Banners As part of the Snare Server configuration wizard, server login banners (/etc/motd and /etc/issue) can be modified. The same notification message is also used in the Snare Server login screen. Intersect Alliance International Pty Ltd Page 7 of 8

8 Authentication Settings In general, most security guidelines recommend that user accounts on non-embedded systems include controls such as limited password lifetimes, account expiry on incorrect authentication, and dictionary-based checks on password strength. Snare does not offer, or support, interactive user sessions to the operating system, and does not supply services to external users other than the normal 'Snare' web interface, a secure-shell (optional), a limited file transfer capability (optional), and interface for incoming audit data. As such, Snare uses the default authentication controls available through the operating system Security Scans Security vulnerability scans may be run against the Snare Server. Most will return some results, that will include a mix of: False positives Risk items that can be mitigated Risk items that are intrinsic in operating the Snare Server Risk items that are new, and have not yet been mitigated by the Snare Server team False Positives Rather than actively attempting an exploit that may cause the target system to be unresponsive, vulnerability scanners often use version signature checks to determine whether a particular installation is vulnerable. If the vulnerability has been mitigated with controls other than a package upgrade, the scanner will continue to assume that the server is vulnerable, which may not be the case. Also, if the vulnerability scanner assumes that the Snare Server is running a baseline version of either the Debian, or Ubuntu operating systems, it may attribute many vulnerabilities to Snare that are not actually in place. Although Snare utilises baseline packages from common distributions of Linux, many have been removed, modified or otherwise tweaked to build an appliance-like solution that bares little relation to the source distribution. + OSVDB-561: /server-status: This reveals Apache information. Comment out appropriate line in httpd.conf or restrict access to allowed hosts. False positive, as a result of a local server scan. The above example, which was taken from Snare's internal security/vulnerability scanner, indicates that the server may be broadcasting information relating to the internal session and cache state. However, the information is restricted ONLY to clients connecting from the internal loopback interface, and the vulnerability scanner is utilising that same interface, the notification is actually a false positive Risk items that can be mitigated Services such as 'ssh' and 'ftp' are optional extras in Snare. You can turn them off from the Snare Server Configuration Wizard. The web server can also be defaulted to HTTPS (secure HTTP) Risk items that are intrinsic Fundamentally, the Snare Server interacts with your network by collecting log data, and serving web pages. Denial-of-service attacks against the Snare Server directly (e.g.: Log flooding, or web site overwhelm) cannot be mitigated with any level of success, and in some cases, attempts to mitigate the issue may be fundamentally opposed to Snare's core mission of attempting to collect and process as much data as is viable New risks The team at InterSect Alliance monitor security advisories that are likely to affect the Snare Server, and provide either configuration changes, or package upgrades via Snare Server Updates. However, if you discover an issue has not been addressed, please notify your Support team, and we will attempt to resolve the problem. Intersect Alliance International Pty Ltd Page 8 of 8