BEST PRACTICES FOR SCSP POCS. Best Practices for Critical System Protection Proof of Concepts. Version 1.0

Transcription

1 BEST PRACTICES FOR SCSP POCS Best Practices for Critical System Protection Proof of Concepts Version 1.0 1

2 1. UNDERSTANDING SERVER RISK HOW TO PROTECT YOURSELF: DEVELOPING SERVER HARDENING CONFIGURATIONS LOGGING AND MONITORING INTRODUCTION TO CRITICAL SYSTEMS PROTECTION DETECTION AND PROTECTION UNDERSTANDING THE COMPONENTS OF SCSP PORTS AND COMMUNICATIONS DEPLOYMENT CONSIDERATIONS DATABASE SIZING INSTALLING SCSP SERVER INSTALLATION CONSOLE INSTALLATION WINDOWS AGENT INSTALL WORKING WITH SCSP CONSOLE PAGE ASSETS PAGE PREVENTION POLICIES Windows Core Prevention Policy Windows Strict Prevention Policy Creating a new policy for a server using the Wizard APPLYING A POLICY Monitoring a Policy Behavior Editing a policy Host Firewall Protection Application Buffer Overflow Protection Application Lockdown System Variables DETECTION POLICIES Baseline Policy Windows Template Policy NT Event Log File Integrity Monitoring Registry Watch Text Log Watch PREVENTION POLICY CREATION AND PROFILING System variables Resource Variables Custom Table Options Profiling an Application Example: Locking Down an Oracle Server Working with Resource Restrictions Working with Network Restrictions WALKTHROUGH OF COMMON USE CASES FILE INTEGRITY MONITORING PRIVILEGE DE-ESCALATION WEB SERVER CONFIGURATION AND WEB DEFACEMENT PREVENTION

3 5.4. PROTECTING APPS FROM USERS CONFIGURING CONNECTIONS TO AND FROM AN AGENT COMPUTER ALLOWING GRANULAR ACCESS TO FILES, DEVICES, AND REGISTRY KEYS BLOCKING ACCESS TO USB DEVICES GIVING A PROGRAM ACCESS TO A SPECIFIC RESOURCE SET GIVING A PROGRAM WIDE ACCESS TO RESOURCES PREVENTING ZERO DAY ATTACKS WHITE LISTING VIRTUALIZATION PROTECTION CONFIGURATION, REPORTING AND MONITORING ALERTING MONITORING SEARCHING AND REAL-TIME MONITORS POC TIPS

4 1. Understanding Server Risk Servers are responsible for serving content and invoking applications that generate content. Many application servers provide services that Web applications can use such as data storage, directory services, mail, messaging, and more. Failure to manage the proper configuration can lead to a wide variety of security problems. When deploying servers, you must defend against malicious attackers who can exploit the vulnerabilities in these servers and applications. Application vulnerabilities provide the potential for an unauthorized party to gain access to critical information, use resources inappropriately, and interrupt business or theft. Applications might be vulnerable to buffer overflows, which occur when a program attempts to store more data in a static buffer than it was designed to manage. The added data overwrites and corrupts memory, allowing an attacker to insert arbitrary instructions on the Web server or to crash the system or gain access. Applications might not adequately prevent introducing arbitrary code into the system that could be executed with the administrator privileges of the operating system. For example, a hacker might enter a commandline executable statement, such as into a legitimate Web site form under the guise of an "http request" to gain access to the Web server. If your security configuration allows, the hacker would receive the /etc/passwd file and have access to files, and access to usernames and passwords, which are stored on the Web server. Many application logs contain sensitive information, such as passwords, session IDs, These logs and other sensitive files may be stored on the web server or back-end database that hackers can retrieve to perform unauthorized functions, view their content or compromise the resource. Cybercriminals will examine applications and infrastructure to understand its design, identify any potentially weak aspects, and use these weaknesses to break or exploit the application. Server vulnerabilities can come from exposures in the server's operating system, server administration practices, or from flaws in the applications. These types of attacks can lead to the hackers installing a password stealing program and seizing full control of the machine. Server misconfiguration attacks exploit configuration weaknesses found in servers. Many servers come with defaults turned on that might be unnecessary depending on the role of the server They might also have unnecessary services enabled, such as content management and remote administration functionality. Debugging functions may be enabled or administrative functions may be accessible to anonymous users. These features may provide a means for a hacker to bypass authentication methods and gain access to sensitive information, perhaps with elevated privileges. Improper file system permissions are a threat to the confidentiality, integrity and availability of applications. The problem arises when incorrect file system permissions are set on files, folders, and symbolic links. When improper permissions are set, an attacker may be able to access restricted files or directories and modify or delete their contents. For example, if an anonymous user account has write permission to a file, then an attacker may be able to modify the contents of the file influencing the application in undesirable ways. An attacker may also exploit improper symlinks to escalate their privileges and/or access unauthorized files; for example, a symlink that points to a directory outside the web root. 4

5 The following table summarizes the typical types of attacks. Attack Type Denial of service Exploitation of configuration errors Insider Attack (Intentional or Unintentional) Exploitation of application vulnerabilities Attacks through other services Description Any of the network, web-server, or applicationbased attacks that result in denial of service, a condition in which a system is overloaded and can no longer respond normally These errors are our happen more often than you might think Admin with high privileges installs a malware or grants a user account with high privileges Unpatched or unknown problems in deployed web applications Access through RDP, Telnet, FTP and SSH Applied Example: Attacks on Web Servers 1. The Web server account is incorrectly given write access to the server's index file, "default.asp". An attacker accessing the web page might be able to modify the contents of the "default.asp" file. 2. The Web server account is incorrectly given access to system files such as password files, password hashes and critical operating system files. An attacker might be able to access and modify those files through the web server, such as when a directory traversal vulnerability is present. 3. The Web server account is incorrectly given script source access; an attacker might be able to view the source code of the Web application. 5

6 1.1. How to Protect Yourself: Developing Server Hardening Configurations The following table summarizes the key points to consider when creating a hardening guideline for your server configuration. This configuration should be used on all servers, including ones that are used for testing. Actions to take to protect a server Identify default files and directories that hackers could exploit Detect inadequate patch levels and vulnerable applications Point out poor passwords and controls Identify users that have too many privileges Identify applications and services that should not be installed and running Prevent unauthorized traffic to and from the system Best Practices to consider when creating hardening guidelines for server configurations Configuring all security mechanisms Turning off all unused services Setting up roles, permissions, and accounts, including disabling all default accounts or changing their passwords Configuring logging and alerts Monitoring the latest security vulnerabilities published Applying the latest security patches Updating the security configuration guideline Performing regular vulnerability scanning from internal and external perspectives Conducting regular internal reviews of the server s security configuration as compared with your configuration guide Running regular status reports to upper management documenting security posture Questions to ask about the environment in which the application resides What operating system is the server running? What kind of protection does it have? What other services does it offer? Is the server exclusively used for this application? Are many applications sharing the same server? Is it a shared hosting server managed by a third party? Who has access to the system and how? Shell access is the most dangerous because it gives great flexibility. Other types of access (FTP, CGI scripts) can become equally dangerous with effort and creativity. 6

7 1.2. Logging and Monitoring While one of the most important administrator tasks is to configure a system to be secure, it is also necessary to know it is secure. The only way to know a system is secure (and behaving correctly) is through review of log files. Most administrators do not think about the logs before an intrusion happens. Only then do they realize their configuration mistakes when they discover that critical forensic information is not available. Monitoring activity on the system can help identify a breach before the outcome leads to a leak. Most attack vectors for systems compromised can often be discovered in monitoring activity on the system. Detection and preserving evidence are key components to an effective response to an incident. Log activity should be not only monitored but should be stored on a system other than the system where the activity is being created. Hackers will try and clear their tracks as quick as possible once they have gained control of the system. 7

8 2. Introduction to Critical Systems Protection Symantec Critical Systems Protection (SCSP) can be used to secure and lockdown servers. SCSP installs as a kernel-level driver that protects the operating system and applications from hackers trying to gain access to the system through known or unknown vulnerabilities. SCSP can also be used to monitor and lock down application configuration files from being changed, which could weaken the security of the application. The previous section addressed how server applications contain vulnerabilities and provided examples of how hackers can use buffer overflow attacks to try and gain access or launch commands. SCSP wraps around the applications and monitors for buffer overflow attacks, and prevents the attack from using the application to gain access to the system. Running unnecessary services on a server could allow a hacker to exploit one of them and gain access to the system. When SCSP is installed on the server, rules can be written to only allow services that are needed to run, and prevent all others. Even if an application or a piece of malware was installed on the system and attempted to open a back door, SCSP would prevent this from occurring by controlling network communication to and from the server. Often, applications running on a server might use an account that has more rights that what is needed, allowing access to configuration files and logs. If a different account is used and given write access to the wrong files, a hacker could gain access to the. SCSP can be used to restrict access to files based on what rights the user or application should have to those files. Hackers will try and exploit applications that are running with privileged users to either use the user account to install a backdoor or create another user account for access. If a hacker cannot gain access to a system using an account that he hijacked, the hacker will often try and gain access to the system and create a new account. Log files and debug files can contain information that can help hackers discover the purpose of the application. Hackers can also use such files to map out other systems in the network that are communicating with the server, such as a database system. SCSP can lock down the log files, only allowing certain users or applications from viewing the files. SCSP can also prevent the file from being removed from the system. Administrators often need to restrict which internal systems can talk to critical servers. For example, an organization might have a back-end database server that houses information that is accessed by the web server application. If a hacker successfully performs a SQL Injection attack, he may be able to gain access to that backend database. By installing SCSP on the back-end database, administrators can write rules permitting communication only between those two systems. This configuration would prevent data from getting extracted from that database system Detection and Protection Critical System Protection has two components that companies can deploy on their critical systems. One component provides prevention of potential security or compliance threats to the system. The other component will detect such violations but will not prevent them. Several regulations require that companies deploy file integrity monitoring to monitor for critical system and application files changes. The detection component of SCSP can help companies meet this requirement. If the ultimate goal was to deny the changes in the first place, the prevention component would be more applicable. Detecting that svchost.exe was just modified is very different than preventing that modification from occurring. SCSP can impose resource restrictions to prevent the modifications of important files on the system. In most large scale data breaches, a system was compromised and was used to launch attacks or target other high profile systems that contain the data that they attacker was after. In a lot of cases misconfigured systems and open shares allowed this leap frog attack to occur. Many times data is left sitting on a system where anyone who can access the system can access the data. 8

9 The out of the box detection policies can be used to alert on activity on a system that could be a compliance or security violation. Normal activity does not always mean good activity. A compromise to a system and the hijacking of an account can go unnoticed unless something is there to prevent the attack in the first place. Many companies will deploy detection to get by the checkbox of meeting the regulation or to say that we are monitoring activity on our critical systems. As important as that is in the overall big picture of looking at the security posture of the system, things can still slip through the cracks if someone is not responding to those alerts Understanding the components of SCSP SCSP has several components. These components can be installed on one system or installed in a distributed model. The console is available as a thick client that can be installed on a system or accessed through a Web UI. The management server, data store and thick client are only supported to run under Microsoft Windows. The SCSP agents are supported to run under several different operating systems Ports and Communications When deploying CSP in your environment, you need to make sure that the proper communication is available for the components. The following figure summarizes the key port and communication flows. 9

10 2.4. Deployment considerations Platform Prevention Detection Microsoft Windows Solaris Solaris 8, 9, 10* Windows 2000, 2003 and 2008, including 64- bit versions, Windows 2008 SP2 and R2 Windows NT *includes x86, x86 VM, 64-bit & Global Zones Linux SuSE Linux Enterprise Server 8, 9,10 RedHat Enterprise Linux 3**, 4**, 5 includes 32-bit & 64-bit support VMWare ESX 3.5 Host Windows 2000, 2003 and 2008, including 64-bit versions, Windows 2008 SP2 and R2, Windows NT Solaris 8, 9, 10* *includes x86, x86 VM, 64-bit & Local Zones SuSE Linux Enterprise Server 8, 9,10 RedHat Enterprise Linux 3**, 4**, 5 includes 32-bit & 64-bit support VMWare ESX 3.5 Host AIX Future release AIX 5L (5.1, 5.2, and 5.3) HP-UX Future release HP-UX 11i v1 (11.11)**, v2 (11.23)** and v3 (11.31)** HP Tru64 Unix V5.1B Component Hardware OS Management 150MB free disk space Windows 2000 SP4 / Windows XP Pro SP1 Console 256 MB RAM Windows 2003 including 64-bit versions SP1, R2 Management Server Pentium III 1.2 GHz 1GB free disk space (all platforms/databases) 1 GB RAM Pentium III 1.2 GHz Windows Server 2003 Standard/Enterprise x64 Agent 100MB free disk space (all SuSE Linux Enterprise Server 8, 9,10 Windows platforms) 256 MB RAM RedHat Enterprise Linux 3**, 4**, 5 Pentium III 1.2 GHz includes 32-bit & 64-bit support VMWare ESX 3.5 Host Agent Solaris Sun SPARC 450 MHz Solaris 8, 9, 10 Sun SPARC32, SPARC64 Solaris 10 Agent HP-UX Hewlett-Packard PA-RISC 450 HP-UX on PARISC MHz Agent AIX IBM Power PC (CHRP) 450 MHZ AIX Agent X86 X86 Windows NT Server Windows Server bit Windows XP Professional Red Hat Enterprise Linux ES 3.0, 4.0 SUSE Linux Enterprise 8, 9, 10 Sun Solaris 10 (IDS only in non-global zone) VMWare support VMware Workstation v5.00 and v5.54 VMware ESX v3.01 and Database Sizing By default SCSP installs with SQL Express Your data retention needs will dictate whether this default choice is appropriate. SQL Express has a limitation to 4 GB in size (4 million events). If your servers generate a lot of traffic, and you plan on retaining events for a long period of time, consider using the full version of SQL Server. If you are feeding the 10

11 events from SCSP to a log management or SIEM product, then the limitation might not be a problem. For example, if a deployment consists of 10 agents (for example, 10 Web servers), this equates to storing 200,000 events per agent. In this case, 5,000 events/day would equate to retention period of 40 days If deploying on SQL server, the disk space needed for storing event data (data content and database overhead) can be sized at 1KB for each event stored (or 1 million events per 1 GB disk space). So a typical size of 5 million stored events will require about 5GB of database disk space. All the other objects in SCSP (asset data, policy data, configs, and query/alert/reports) will often never take more than 2GB of disk space regardless of agents deployed. So the primary consideration is to determine the average number of events to be generated by an agent each day and how long you wish to retain events in the database. Both of these variables are directly under your control. 20 GB of space is more than enough for CSP to function. One of the key factors to database management is to enable purging, which by default it is off as shown in the following figure. 11

12 3. Installing SCSP The following table summarizes the installation sequence for the different SCSP components. Order of installation File to execute (in root CSP directory) Notes First: Server Server.exe For a POC, install all components on a Second: Console Third: Agent Console.exe Agent.exe (To install agent on a Windows systems (except for NT). Use the other agent files in the directory to install other operating systems. single system. You can install the console on a separate system or use the Web UI for management 3.1. Server Installation To install the server component using the embedded database: 1. Launch the installation by executing server.exe. This example assumes a server monitoring installation, in which the default SQL Server Express 2005 database is acceptable 2. Choose the installation path for the Server. 12

13 3. Confirm the ports used for communication with the agent and the console. If you are installing the agent on a system that contains an application that is already using port 443, ensure that no other host software conflicts with SCSP communications. Possible conflicts can occur with the following types of programs and software: Host based firewall Programs using SSL (port), such as IIS server, WebVPN, or Symantec Endpoint Protection Manager (if agents use SSL to connect) 4. Choose a password that will be used by SCSP to connect to the database. 13

14 5. Click Finish to complete the installation Console Installation To install the console component: 1. Launch the installation wizard by executing console.exe. 2. Proceed through the wizard prompts Windows Agent Install Symantec Critical System Protection agents support prevention and detection features. Prevention:Agents that support prevention features control behavior by allowing and preventing specific actions that an application or user can take. For example, a Symantec Critical System Protection prevention policy could specify that aweb application may not spawn other processes, including dangerous processes like viruses, worms, and Trojan horses. 14

15 Detection: Agents that support detection features control behavior by detecting suspicious activity and taking action. For example, a Symantec Critical System Protection detection policy could act when it detects an attempt by an unauthorized user to gain illegitimate access to a system. No action would be taken for failed attempts that resulted from normal behavior such as an expired password or a user forgetting a password. Before installing the agent, the certificate file that was created during the management server installation needs to be copied to the system where the agent is being installed. On Windows installations, the certificate is in C:\Program Files\Symantec\Critical System Protection\Server. The name of the file is called agent-cert.ssl. Copy this file to a directory on the agent system. Note: For information on installing the agent on platforms other than Windows or on using the silent installation, refer to the CSP documentation. In general, you need to be logged in as the superuser and perform the following tasks: Insert the installation CD cd /mnt/cdrom Run the./agent-os.bin file for the appropriate operating system. To install the agent a Windows platform: 1. Launch the installation wizard by executing agent.exe. 2. Accept the default installation path for the agent of choose a new folder. 15

16 3. On the Agent Configuration page, specify a name for the agent that will appear in the CSP console. Also specify a Polling Interval to control how often the agent will poll the manager for updates. 4. Click Enable Intrusion Prevention to allow prevention policies to be deployed. When you enable prevention the system must be rebooted before a prevention policy will work. 5. Set the Enable Real-Time notification option to configurations to be pushed to an agent. If this setting is disabled, the agent will only pull down configurations during the set polling interval. 6. On the Management Server Configuration page, specify the management server that will manage the agent. 16

17 7. Specify the agent port that was configured during the management server installation. If the port was changed because this system has an application that is using port 443, change the port number appropriately. Make sure that the agent port matches what was specified at the management server. 8. Optionally specify fail-over servers in the Alternate Management Server(s) field. 9. In the Management Server Certificate field, specify the path to the certificate that you copied from the management server. 10. Click Next. 11. If configuration and policies have been pre-defined in the console, you can configure agent management groups. This option is helpful if, for example, you want all your Web servers to go into a specific group that has a prevention policy assigned to it. Agents assigned to a group will receive policies pushed down to its respective group. Note that you can leave this page blank, and assign the agent to the group after the installation. 12. On the Service User Configuration page, specify the account the agent will run as on the local system. You would usually leave the default account as LocalSystem unless you want it to run as a different account. The account must have administrator privileges if you plan on using a different account. 17

18 Click Finish to complete the agent installation.

19 4. Working with SCSP Once SCSP is installed, log in to the management console to manage policies and the agents. When you login, use symadmin for the user name and leave the password field blank. You will be prompted to set a new password Console Page Once logged in, you will be presented with the SCSP console. From the console screen you will see the agents that you registered to the manager. 19

20 The Home page provides current agent, event, and Internet security statistics that show the health and status of your network. You can analyze this information to identify problem computers and threats to your network's security. From this page, you can : View statistics for your entire network View statistics for agents that support prevention features View statistics for agents that support detection features View the Symantec ThreatCon rating Access popular management console tasks You can view the Home page in all three console views (Master, Prevention, and Detection.). Each view presents a customized view of agent and event statistics Assets Page Use the Assets page in the management console to apply policies and configurations to agents, and to monitor the health of your agents. Assets are the computers on which agents are installed. Agents are the software that you install on the computers that you want to protect. From the Assets page, you can Determine how agents communicate with the management server, and which events agents send to the management server View information about the agents in your network, including which policies are enforced on agents, and how the agents are configured View a list of agents that run on Windows, Solaris, Linux, AIX, and HP-UX operating systems Apply policies and configurations to agents and groups Delete an agent s record from the management server database When an agent first registers with the management server, it tells the server whether it supports prevention features, detection features, or both. The agent is placed in a default group in each console view that it supports, unless a group was assigned during agent installation. 20

21 Each console view lets you create agent groups in different ways. Each view has its own rules about policy and configuration assignment to agents, and lets you perform specific actions. Agent Health is the first column in the agent pane. The Agent Health column indicates whether an agent is in contact with the management server. Place your mouse cursor over the Agent Health column to view a pop-up tool tip. The Agent Health column displays one of the following icons: A green circle icon indicates that an agent is healthy. A yellow circle icon indicates than an agent is possibly offline and experiencing minor problems. A red circle icon indicates that an agent is offline and experiencing major problems. The Shield Icon indicates that an agent is protected. A Shield Icon with red X indicates that an agent has limited or no protection. If an agent has a shield with an X it could mean that the policy that was pushed down contains problems If an agent is not listed after you install it, check the SISIPSService.log file found under the scsplog directory on the agent Prevention Policies The Symantec Critical System Protection prevention policies protect against inappropriate modification of system resources. The policies confine each process on a computer to its normal behavior. Programs that are identified as critical to system operation are given specific behavior controls; generic behavior controls provide compatibility for other services and applications. The following graphic summarizes the overall flow during the system hardening process as it relates to Prevention Policies: 21

22 To begin, click the Prevention View tab to work with prevention policies. The Symantec Critical System Protection prevention policies often require tailoring for your site-specific needs. For example, the base policies limit network connectivity to and from applications. If your organization requires protection beyond what the Symantec Critical System Protection prevention policies provide, you can increase or decrease the restrictions enforced by the policies. Depending on the CSP policy that is deployed, good guidance to follow when creating firewall rules includes: Deny everything by default Allow only what is necessary Treat internal networks and servers as hostile and only give them minimum privilege SCSP provides several pre-installed prevention policies. The degree of protection and lockdown you want on the server will depend on which policy you use. You can only have one prevention policy deployed per system. The two prevention policies that we recommend to be chosen for servers are the Windows Core Prevention Policy and the Windows Strict Prevention Policy Windows Core Prevention Policy The Windows Core prevention policy, suitable for most servers and workstations, provides basic protection for the operating system and common applications, while enabling a highly compatible environment for all other programs. The core policy prevention prevents remote computers from making inbound network connections to an agent computer. Exception lists allow for remote computers to make inbound network connections. The core policy denies services from launching programs that may be used by exploits and that services normally do not launch. The core policy provides specific behavior controls for the core operating system services and the following application services: Microsoft Exchange Server Microsoft SQL Server Microsoft Internet Information Server 22