Linux Server Hardening

For today’s computing platforms, ease of access and openness is essential for web based communications and for lean resourced IT Management teams.

This is directly at odds for the increased necessity for comprehensive security measures in a world full of malware, hacking threats and would-be data thieves.
Most organizations will adopt a layered security strategy, providing as many protective measures for their IT infrastructure as are available – firewalls, sandboxes, IPS and IDS, anti-virus – but the most secure computing environments are those with a ‘ground up’ security posture.
If data doesn’t need to be stored on the public-facing Linux web server, then take it off completely – if the data isn’t there, it can’t be compromised.
If a user doesn’t need access to certain systems or parts of the network, for example, where your secure Ubuntu server farm is based, then revoke their privileges to do so – they need access systems to steal data so stop them getting anywhere near it in the first place.
Similarly, if your CentOS server doesn’t need FTP or Web services then disable or remove them. You reduce the potential vectors for security breaches everytime you reduce means of access.
To put it simply, you need to harden your Linux servers.

Linux Hardening Policy background

The beauty of Linux is that it is so accessible and freely available that it is easy to get up and running with very little training or knowledge. The web-based support community places all the tips and tutorials you’ll ever need to carry out any Linux set-up task or troubleshoot issues you may experience.
Finding and interpreting the right hardening checklist for your Linux hosts may still be a challenge so this guide gives you a concise checklist to work from, encompassing the highest priority hardening measures for a typical Linux server.

And, if you want to make life simpler…

NNT Change Tracker Enterprise provides an automated tool for auditing servers, firewalls, router and other network devices for compliance with a full range of hardened build checklists. Once a hardened build baseline has been established, any drift from compliance with the required build standard will be reported. To enhance security protection further, Change Tracker also provides system-wide, real-time file integrity monitoring to detect any Trojan, backdoor or other malware infiltrating a secure server. Request a trial or demonstration here www.newnettechnologies.com/enterprise-change-and-configuration-management.html

Account Policies

• Enforce password history – 365 days
• Maximum Password Age - 42 days
• Minimum password length – 8 characters
• Password Complexity - Enable
• Account Lockout Duration - 30 minutes
• Account Lockout Threshold – 5 attempts
• Reset Account Lockout Counter - 30 minutes

Edit the /etc/pam.d/common-password to define password policy parameters for your host.

Access Security

• Ensure SSH version 2 is in use
• Disable remote root logons
• Enable AllowGroups to permitted Group names only
• Allow access to valid devices only
• Restrict the number of concurrent root sessions to 1 or 2 only

Edit sshd.config to define SSHD policy parameters for your host and /etc/hosts.allow and /etc/hosts.deny to control access. Use /etc/securetty to restrict root access to tty1 or tty1 and tty2 only.

Secure Boot Only

Remove options to boot from CD or USB devices and password protect the computer to prevent the BIOS options from being edited.
Password protect the /boot/grub/menu.lst file, then remove the rescue-mode boot entry.

Disable All Unnecessary Processes, Services and Daemons

Each system is unique so it is important to review which processes and services are unnecessary for your server to run your applications.
Assess your server by running the ps –ax command and see what is running currently.
Similarly, assess the startup status of all processes by running a chkconfig –list command.
Disable any unnecessary services using the sysv-rc-conf service-name off

Restrict Permissions on Sensitive Files and Folders to root Only

Ensure the following sensitive programs are root executable only

• /etc/fstab
• /etc/passwd
• /bin/ping
• /usr/bin/who
• /usr/bin/w
• /usr/bin/locate
• /usr/bin/whereis
• /sbin/ifconfig
• /bin/nano
• /usr/bin/vi
• /usr/bin/which
• /usr/bin/gcc
• /usr/bin/make
• /usr/bin/apt-get
• /usr/bin/aptitude

Ensure the following folders are root access only

• /etc
• /usr/etc
• /bin
• /usr/bin
• /sbin
• /usr/sbin
• /tmp
• /var/tmp

Disable SUID and SGID Binaries

Identify SUID and SGID files on the system: find / \( -perm -4000 -o -perm -2000 \) –print.
Render these files safe by removing the SUID or SGID bits using chmod –s filename
You should also restrict access to all compilers on the system by adding them to a new ‘compilers’ group.

• chgrp compilers *cc*
• chgrp compilers *++*
• chgrp compilers ld
• chgrp compilers as

Once added to the group, restrict permissions using a chmod 750 compiler

Implement Regular/Real-Time FIM on Sensitive Folders and Files

File integrity should be monitored for all files and folders to ensure permissions and files do not change without approval.

Configure Auditing on the Linux Server

Ensure key security events are being audited and are forwarded to your syslog or SIEM server. Edit the syslog.conf file accordingly.

General Hardening of Kernel Variables

Edit the /etc/sysctl.conf file to set all kernel variables to secure settings in order to prevent spoofing, syn flood and DOS attacks.

Google+

Windows server 2008 hardening

Prevention of security breaches is always seen as the best approach to protecting key data assets. Hardening a server in line with acknowledged best practices in secure configuration is still the most effective means of protecting your Server data.

Deriving the right checklist for your Server 2008 estate requires an iterative process, starting with an ‘off the shelf’ hardening checklist and comparing this to your current hardened build standard for Server 2008.
There will be discrepancies, for example, a decision will need to be made on settings to adopt such as Password Length. Some checklist authorities recommend an 8 character minimum, others 12 characters, and in fact, Server 2008 R2 allows up to 24 characters to be used. Password length and complexity significantly strengthens security – a typical brute force attack on a system with a 7 character password will take on average just 4 days to crack. An 8 character password with complexity i.e. including symbols, will take on average 23 years.

Server Hardening Policy background

Any server deployed in its default state will naturally be lacking in even basic security defenses. This leaves it vulnerable to compromise. A standard framework for your server security policy should include the following attributes defining password, local user accounts and the Windows Audit and Security policies. This sample Server 2008 hardening checklist will help to get your server more secure but please see also the sample Server 2008 services hardening checklist and FIM policy.

And, if you want to make life simpler…

NNT Change Tracker Enterprise provides an automated tool for auditing servers, firewalls, router and other network devices for compliance with a full range of hardened build checklists. Once a hardened build baseline has been established, any drift from compliance with the required build standard will be reported. To enhance security protection further, Change Tracker also provides system-wide, real-time file integrity monitoring to detect any Trojan, backdoor or other malware infiltrating a secure server. Request a trial or demonstration here

Account Policies

• Enforce password history – 24
• Maximum Password Age - 42 days
• Minimum Password Age –2 days
• Minimum password length - 8 characters
• Password Complexity - Enable
• Store Password using Reversible Encryption for all Users in the Domain - Disable
• Account Lockout Duration - 30 minutes
• Account Lockout Threshold – 5 attempts
• Reset Account Lockout Counter - 30 minutes
• Enforce User Logon Restrictions - Enable
• Maximum Lifetime for Service Ticket - 600 minutes
• Maximum Lifetime for User Ticket - 8 hours
• Maximum Lifetime for User Ticket Renewal - 7 days
• Maximum Tolerance for Computer Clock Synchronization - 5 minutes

Windows Audit Policy and Advanced Security Audit Policy (Group Policy)

All Event Log files must be set to 2048KB and must be set to overwrite events as needed.

• Audit account logon event - Success, Failure
• Audit account management - Success, Failure
• Audit directory service access - Failure
• Audit logon events - Success, Failure
• Audit object access - Success, Failure
• Audit policy change - Success, Failure
• Audit process tracking - Not configured
• Audit privilege use - Success, Failure
• Audit system events - Success, Failure

• Audit Authentication Policy Change - Success
• System: System Integrity - Success, Failure
• Security System Extension - Success, Failure
• Security State Change - Success, Failure
• Logoff - Success, Failure
• Logon - Success, Failure
• Special Logon - Success, Failure
• File System - Success, Failure
• Registry - Success, Failure
• Sensitive Privilege Use - Success, Failure

Windows Local Security Policy / Group Policy - User Rights Assignment Settings

• Access Credential Manager as a Trusted Caller - <no one>
• Allow Access to this Computer from the Network - (Restrict the Access this computer from the network user right to only those users and groups who require access to the computer) Example: Administrators, Domain Administrators
• Act as Part of the Operating System - <no one>
• Add Workstations to Domain – Administrators
• Adjust Memory Quotas for a Process - Administrators, Local Service and Network Service only
• Allow Log on Locally - Administrators
• Allow log on through Remote Desktop Services/Terminal Services - Remote Desktop Users, Administrators
• Back up Files and Directories - Administrators
• Bypass Traverse Checking - Restrict the Bypass traverse checking user right to only those users and groups who require access to the computer – for example, Users, network service, local service, Administrators
  

Windows Local Security Policy / Group Policy - User Rights Assignment Settings

- Contd.

• Change the System Time – Administrators, Domain Administrators
• Change the Time Zone - Users
• Create a Page File - Administrators
• Create a Token Object - <no one>
• Create Global Objects - Administrators
• Create Permanent Shared Objects - <no one>
• Create Symbolic Links - Administrators
• Debug Programs - <no one>
• Deny Access to this Computer from the Network – ANONYMOUS LOGON, Built-in local Administrator account, Local Guest account, All service accounts,
• Deny Log on as a Batch Job - <no one>
• Deny Log on as a Service - <no one>
• Deny Log on Locally - ASPNET account on computers that are configured with the Web Server role
• Deny log on through Terminal Services/RDP – Local Guest account, All service accounts
• Enable Computer and User Accounts to be Trusted for Delegation - <no one>
• Force Shutdown from a Remote System – Administrators
• Take Ownership of Files or other Objects - Administrators
• Generate Security Audits - Local Service and Network Service only
• Impersonate a Client after Authentication – Administrators, Local Service and Network Service only
• Increase a Process Working Set - <no one>
• Increase Scheduling Priority - <no one>
• Load and Unload Device Drivers – Administrators
• Lock Pages in Memory - <no one>
• Manage Auditing and Security Log – Local Administrator only
• Modify an Object Label - <no one>
• Modify Firmware Environment Values - Local Administrator only
• Perform Volume Maintenance Tasks - Local Administrator only
• Profile Single Process - Local Administrator only
• Profile System Performance - Local Administrator only
• Replace a Process Level Token - Local Service and Network Service only
• Restore Files and Directories - Local Administrator only
• Shut Down the System – Administrators
• Synchronize Directory Service Data - <no one>

Windows Local Security Policy / Group Policy - Security Options

• Administrator Account Status -Disabled
• Guest Account Status - Disabled
• Limit Local Account Use of Blank Passwords to Console Logon Only - Enabled
• Rename Administrator Account – Must be set to something other than Administrator
• Rename Guest Account - Must be set to something other than Guest
• Audit the Access of Global System Objects -Disabled
• Audit the use of Backup and Restore Privilege - Enabled
• Force Audit Policy Subcategory Settings to Override Audit Policy Category Settings – Enabled
• Shut Down System Immediately if Unable to Log Security Audits - Enabled
• Prevent Users from Installing Printer Drivers when connecting to Shared Printers – Enabled
• Machine Access Restrictions in Security Descriptor Definition Language (SDDL) – Bespoke for each environment
• Machine Launch Restrictions in Security Descriptor Definition Language (SDDL) – Bespoke for each environment
• Allowed to Format and Eject Removable Media – Administrators
• Prevent Users from Installing Printer Drivers – Enabled
• Allow Server Operators to Schedule Tasks - Disabled
• Digitally Encrypt or Sign Secure Channel Data (Always) - Enabled
• Digitally Encrypt or Sign Secure Channel Data (when possible) - Enabled
• Disable Machine Account Password Changes - Disabled
• Maximum Machine Account Password Age - 30 days
• Require Strong (Windows 2000 or later) Session Key – Enabled
• Interactive Logon: Display User Information when the Session is Locked - Enabled
• interactive logon: Do Not Display Last User Name - Enabled
• Interactive logon: Do Not Require CTRL+ALT+DEL - Disabled
• Interactive logon: Message Text for Users Attempting to Log On – For example, ‘By using this computer system you are subject to the 'Computer Systems Policy' of New Net Technologies. The policy is available on the NNT Intranet and should be checked regularly for any updates’
• Interactive logon: Message Title for Users Attempting to Log on- For example ‘Warning – Authorized Users Only – Disconnect now if you are not unauthorized to use this system’
• Number of Previous Logons to Cache (in case domain controller is not available) – 0
• Interactive Logon: Prompt User to Change Password before Expiration – 14 days
• Interactive Logon: Require Domain Controller Authentication to Unlock Workstation - Enabled
• Microsoft Network Client: Digitally Sign Communications (always) – Enabled
• Microsoft Network Server: Digitally Sign Communications (always) - Enabled
• Microsoft Network Client: Digitally Sign Communications (if server agrees) - Enabled
• Microsoft Network Server: Digitally Sign Communications (if client agrees) – Enabled

Windows Local Security Policy / Group Policy - Security Options – Contd.

• Microsoft network client: Send Unencrypted Password to Connect to Third-party SMB servers -Disabled
• Microsoft Network Server: Amount of Idle Time required before Suspending a Session - 15 minutes
• Microsoft Network Server: Disconnect clients when Logon Hours Expire – Enabled
• Microsoft Network Server: Server SPN target Name Validation Level – Accept if Provided by Client or Required from Client
• Microsoft Network Server: Digitally Sign Communications (always) – Enabled

• Network Access: Allow anonymous SID/name translation – Disabled
• Network Access: Do not allow anonymous enumeration of SAM accounts – Enabled
• Network Access: Do not allow storage of passwords or credentials for network authentication – Enabled
• Network Access: Let Everyone Permissions Apply to Anonymous Users - Disable
• Network Access: Named Pipes that can be Accessed Anonymously – Set to Null, review system functionality
• Network Access: Remotely Accessible Registry Paths and Sub-paths - Set to Null, review system functionality
• Network Access: Shares that can be Accessed Anonymously - <no one>
• Network Access: Sharing and Security Model for Local Accounts – For Network Servers, ‘Classic – local users authenticate as themselves’. On end-user computers, ‘Guest only – local users authenticate as guest’
• Network Security: Allow Local System NULL session fallback – Disabled
• Network Security: Allow Local System to use computer identity for NTLM – Enabled
• Network Security: Allow PKU2U authentication requests to this computer to use online identities - Disabled
• Network Security: Do not store LAN Manager Hash value on Next password Change – Enabled
• Network Security: Force Logoff when Logon Hours Expire - Enabled
• Network Security: LAN Manager authentication level - Send NTLMv2 response only\refuse LM & NTLM
• Network Security: LDAP Client Signing Requirements - Negotiate Signing
• Network security: Minimum session security for NTLM SSP based (including secure RPC) clients - Require NTLMv2 session security
• Network security: Minimum session security for NTLM SSP based (including secure RPC) servers - Require NTLMv2 session security

• Domain controller: LDAP server signing requirements - Require signing
• Domain controller: Refuse machine account password changes - Disabled

Windows Local Security Policy / Group Policy - Security Options – Contd.

• MSS: (DisableIPSourceRouting) IP source routing protection level (protects against packet spoofing) - Highest protection, source routing is completely disabled
• MSS: (EnableICMPRedirect) Allow ICMP redirects to override OSPF generated routes – Disabled
• MSS: (ScreenSaverGracePeriod) The time in seconds before the screen saver grace period expires (0 recommended) – 0
• System Objects: Require case insensitivity for non-Windows subsystems – Enabled
• System Cryptography: Force strong key protection for user keys stored on the computer - User must enter a password each time they use a key
• System Cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing - Enable
• System objects: Default owner for objects created by members of the Administrators group - Object Creator
• System objects: Require case insensitivity for non-Windows subsystems - Enable
• System objects: Strengthen default permissions of internal system objects (e.g., Symbolic Links) - Enable
• System settings: Optional subsystems – Null value
• Recovery Console: Allow automatic administrative logon – Disabled
• Recovery Console: Allow floppy copy and access to all drives and all folders - Disabled
• Domain Controllers Policy- if present in scope - Domain controller: Allow server operators to schedule tasks – Disabled
• System settings: Use Certificate Rules on Windows Executables for Software Restriction Policies - Enable
• User Account Control: Admin Approval Mode for the Built-in Administrator account – Enable
• User Account Control: Allow UIAccess applications to prompt for elevation without using the secure desktop - Disable
• User Account Control: Behavior of the elevation prompt for administrators in Admin Approval Mode - Prompt for consent
• User Account Control: Behavior of the elevation prompt for standard users - Prompt for credentials
• User Account Control: Detect application installations and prompt for elevation – Enable
• User Account Control: Only elevate executables that are signed and validated – Enable
• User Account Control: Only elevate UIAccess applications that are installed in secure locations – Enable
• Enable the User Account Control: Only elevate UIAccess applications that are installed in secure locations policy setting – Enable
• User Account Control: Run all administrators in Admin Approval Mode – Enable
• User Account Control: Switch to the secure desktop when prompting for elevation – Enable
• User Account Control: Virtualize file and registry write failures to per-user locations – Enable

Google+

So did the OSSEC File Integrity Monitor detect the Java Remote Exploit? For this and much more...Security BSides Delaware

I am sure many that read this blog like to attend security conferences. I am sure you are familiar with Black Hat, Defcon, and H.O.P.E. These are great conferences with a lot of high quality content, they are also expensive and very crowded. Last month I had the opportunity to attend Security BSides in Delaware. It was my first BSides and will not be my last. It was held at Wilmington University on November 9^th and 10^th. The conference was a smaller one but in my opinion that made it great. The best part the entire conference was free. Free attendance, parking, breakfast, and lunch. The content was high quality and attracted a number of well-known speakers.

I was only able to attend on Saturday. My first talk of the day was “Social Engineering Basics and Beyond” given by Valerie Thomas @hacktress09. Valerie is a penetration tester. She audits company’s security policies and is paid to hack them. The focus of the talk was on what could be the weakest link in your organization, people. You can have the best firewalls, anti-virus, and advanced persistent threat detection but all of that could be overcome by an unaware staff member or inattentive help desk team member. Since everyone transmits their entire lives and routines on Twitter, Facebook, and 4Square, it is not hard to figure out who works for a company and their co-workers. Once you have that information it is a quick hop to Google to figure out the organization email format, username format and other key information. The information in hand the hacker makes a carefully crafted call to the helpdesk and requests a password reset or gathers the other information they need to launch their attack. The bottom line is train your people, make sure they verify security information and know who you are on the phone with.  The person on the other end of the phone may be trying to steal your information.

After a quick lunch I decided to visit the lock pick village. The challenges were to pick some simple locks as well as learning how to impression a lock and cut a key. I have previous experience with lock picking so picking was easy. As a side note, the Kwikset lock on your front door can be picked by an experienced picker in less than 2 minutes. The process to impression a key however is very difficult. After about 20 minutes I was able to impression and open a one pin lock. Most locks have 5 pins so you can see why it is so hard. The good part is that a lock impression can be done in stages, so if you have to abort your attempt you can always come back and finish later. Also, once you have the key you always have it and can get in and out quickly.

The afternoon was punctuated by shorter talks. I attended three others. The first was a talk given by a group of students regarding the CVE 2012-4681 Java Remote Exploit. The presentation was interesting in the fact that the standard security that most people would have on their machines was easily bypassed. The various freeware programs such as OSSEC also did not detect the exploit. It looks like the file integrity monitoring or FIM portion of OSSEC wasn’t used but in this case would have picked  up the changes. They also caught a special privileges escalation to a user account in the system logs which a properly configured log management tool would have alerted to the problem and warranted further investigation.  The write up is available here: https://cyberoperations.wordpress.com/student-research/cve-2012-4681-by-o-oigiagbe-r-patterson/.

The second talk I attended was on exploiting android operating systems. In this case the attack victim would be on a “rooted” android phone in which ADB was left on (the default). In this case the attacker could attach his phone or Nexus 7 table to a device and within a few minutes steal critical data from the victim phone or table. Included in this critical data was the Google Authentication token. The token, which can be pasted directly into a web browser allows access the victims entire user account bypassing any Google supplied security enhancements including two factor. The speaker even gave everyone in the class a cable to perform the attack with. Bottom line, if you root your phone, turn ADB off!

The last talk I attended I was on Pentoo http://www.pentoo.ch/ the Gentoo based penetration testing live cd. It is an alternative to BackTrack. The developer of the tool was very passionate about it  and presented several advantages. The first being an hardened kernel, pointing out how laughably easy it is to hack BackTrack when its running, a real problem at cons like Defcon. He also pointed out the advantage of having a good stable of WIFI drivers as well as built in update system and the ability to save changes to a USB stick. I have not had an opportunity to test Pentoo myself but I hope to over the holiday break and I will report back in another blog post.

Finally after a long day at the con I stopped off at Capriotti’s and picked up a Bobbie. Those from Delaware will know what I am talking about, for the rest of the world, think Thanksgiving on a sub roll.

Bart Lewis, NNT

Server Hardening Policy - Examples and Tips

Introduction
Data Protection and Information Security best practice guidelines always place server hardening at the top of the list of measures that should be taken.
Every organization should have a hardened Windows build standard, a hardened Linux build standard, a hardened firewall standard etc. However, determining what is an appropriate server hardening policy for your environment will require detailed research of hardening checklists and then an understanding of how this should be applied to your operating systems and applications.

Server Hardening Policy background
Any server deployed in its default state will naturally be lacking in even basic security defenses. This leaves it vulnerable to compromise.
A standard framework for your server security policy should include

• Access Security (physical and logical)
• Operating System Configuration
• User Accounts and Passwords
• Filesystem Permissions
• Software and Applications image
• Patching and Updates
• Auditing and Change Control

The server hardening policy should be documented and reviewed regularly.

Access Security

• Is the server held under lock and key? Is there a log of all access to the server (visitor book, card swipe/entry code records, and video surveillance) for any access to the server?
• Is server access governed by firewall appliances and/or software?
• Is network access disabled, or if required, restricted using device/address based access control lists? For example, are the hosts.allow and hosts.deny files configured in line with best practice guidelines? Are accounts provided on a strict ‘must have access’ basis? Are there logs kept of all access and all account privilege assignment?

Operating System Configuration

• Is the OS service packed/patched to latest levels and is this reviewed at least once a month?
• Are all services/daemons removed or disabled where not required? For example, obvious candidates like web, ftp and telnet services should be removed and SSH used instead of Telnet. Similarly, remote desktop access should be removed if business operations will not be overly compromised. The best tip is to remove everything you know is not required e.g. Themes service, and then carefully experiment one at a time with other services you feel are unnecessary but may not be sure, however, don’t feel obliged to take this process too far – if you find that disabling a service compromises server operation too much for you, then don’t feel you need to do so.
• For Windows Servers, is the Security and Audit Policy configured in line with best practice guidelines?
• Is there a documented Secure Server Build Standard?

Filesystem Permissions

• For example, for Unix and Linux Servers, are permissions on key security files such as /etc/passwd or /etc/shadow set in accordance with best practice checklist recommendations?
• Is sudo being used, and are only root wheel members are allowed to use it?
• For Windows servers, are the key executables, DLLs and drivers protected in the System32 and SysWOW64 folder?

User Accounts and Passwords

• Are default user accounts, such as the local Administrator account and a local Guest account, renamed and in the case of the Guest Account, disabled? Whilst these accounts will be protected via a password, a number of simple steps can be taken to multiply up the security defenses in this area, simply by disabling the Guest account, and then renaming both the Guest and Administrator accounts.
• Is there a password policy set with ageing, complexity, length, retry, lockout and reuse settings in line with best practice guidelines?
• Is there a regular review process for removing redundant or leavers’ accounts?
• Is there an audit trail of all account creation, privilege or rights assignments and a process for approval?

Software and Applications image/ Patching and Updates

• Which packages and applications are defined within the Secure Build Standard? For example, anti-virus, data leakage protection, firewalling and file integrity monitoring?
• Is there a process to check latest versions and patches have been tested and applied
• Are automated updates to packages disabled in favor of scheduled, planned updates deployed in conjunction with a Change Management process?

Auditing and Change Control

• Are audit trails enabled for all access, use of privilege, configuration changes and object access, creation and deletion? Are audit trails securely backed up and retained for at least 12 months?
• Is file integrity monitoring used to verify the secure build standard/hardened server policy?
• Is there a Change Management process, including a change proposal (covering impact analysis and rollback provisions), change approval, QA Testing and Post Implementation Review?

Best Practice Checklist for Server Hardening Policy
In the previous section there were a number of references to hardening the server ‘in line with best practice checklists’, and there are a number of sources for this information. In fact you may be reading articles like this in search of a straight answer to ‘How do I harden my Windows of Linux Server?’ It isn’t quite as simple as that unfortunately, but it also doesn’t have to be over complicated either.
Getting access to a hardening checklist or server hardening policy is easy enough. For example, the Center for Internet Security provide the CIS hardening checklists, Microsoft and Cisco produce their own checklists for Windows and Cisco ASA and Cisco routers, and the National Vulnerability Database hosted by NIST provides checklists for a wide range of Linux, Unix, Windows and firewall devices. NIST also provide the National Checklist Program Repository, based around the SCAP and OVAL standards.
SCAP is an ambitious project designed as a means of not only delivering standardized hardenings checklists, but automating the testing and reporting for devices. As such it is still being developed and refined, but in the meantime, commercial systems like Tripwire Enterprise and NNT Change Tracker provide automated means of auditing server hardening policy. The hardened server policy checklists can cover host operating systems such as CentOS, RedHat, Debian, Ubuntu, Solaris, AIX and of course Server 2003, Server 2008 and Windows 7/Windows 8.
However, any default checklist must be applied within the context of your server’s operation – what is its role? For example, if it is internet-facing then it will need to be substantially more hardened with respect to access control than if it is an internal database server behind a perimeter and internal firewall.

Server Hardening and File Integrity Monitoring
Once you have established your hardened server policy and have applied the various security best practice checklists to your hardened server build, you will now need to audit all servers and devices within your estate for compliance with the build standard. This can be very time-consuming but in order to automate the audit of a server for compliance with the security policy it is necessary to use a FIM or file integrity monitoring tool like Change Tracker Enterprise or Tripwire Enterprise. These tools can automatically audit even wide scale server estates within a few minutes, providing a full report of both passes and failures for the policy. Tips for mitigation of vulnerabilities will also be provided so the task can be greatly simplified and de-skilled.
Best of all, the hardened build standard for your server hardening policy can be monitored continuously. Any drift in configuration settings will be reported, enabling the system administrator to quickly mitigate the vulnerability again.

Summary
Prevention of security breaches is the best approach to data security. By locking out configuration vulnerabilities through hardening measures, servers can be rendered secure and attack-proof.
Using file integrity monitoring not only provides an initial audit and compliance score for all servers against standardized hardening checklists, but ensures the Windows, Linux, Ubuntu, Solaris and CentOS servers all remain securely configured at all times.

Google+

Server Hardening Checklist - Which Configuration Hardening Checklist Will Make My Server Most Secure?

Introduction
Any information security policy or standard will include a requirement to use a ‘hardened build standard’. The concept of hardening is straightforward enough, but knowing which source of information you should reference for a hardening checklist when there are so many published can be confusing.

Server Hardening Checklist Reference Sources
The most popular ‘brands’ in this area are the Center for Internet Security or CIS hardening checklists (free for personal use), the NIST (aka National Vulnerability Database) provided National Checklist Program Repository or the SANS Institute Reading Room articles regarding hardening of Top 20 Most Critical Vulnerabilities.

All of these groups offer Configuration Hardening Checklists for most Windows Operating Systems, Linux variants (Debian, Ubuntu, CentOS, RedHat Enterprise Linux aka RHEL, SUSE Linux), Unix variants (such as Solaris, AIX and HPUX), and firewalls and network appliances, (such as Cisco ASA, Checkpoint and Juniper).

These sources offer a convenient, one-stop shop for checklists but you may be better served by seeking out the manufacturer or community-specific checklists for your devices and Operating Systems. For example, Microsoft and Cisco offer very comprehensive hardening best-practice recommendations on their websites, and the various CentOS and Ubuntu communities have numerous secure configuration best practice tutorials across the internet.

So which checklist is the best? Which configuration hardening benchmark is the best and the most secure? If you consider that all benchmarks for say, Windows 2008 R2 are all seeking to eliminate the same vulnerabilities from the same operating system, then you quickly realize that there is naturally a high degree of commonality between then various sources. In short, they are all saying the same thing, just in slightly different terms. What is important is that you assess the relevant risk levels for your systems versus what compromises you can make in terms of reduced functionality in return for greater security.

Configuration Hardening and Vulnerability Management
It is important to distinguish between software-based vulnerabilities which require patching for remediation, and configuration based vulnerabilities which can only ever be mitigated. Achieving a hardened, secure build standard is really what a hardening program is all about as this provides a constant and fundamental level of security.

Configuration hardening presents a uniquely tough challenge as the level to which you can harden depends on your environment, applications and working practices. For example, removing web and ftp services from a host are good, basic hardening practices. However, if the host needs to act as a web server, then this is not going to be a sensible hardening measure!

Similarly, if you need remote access to the host via the network then you will need to open firewall ports and enable terminal server or ssh services on the host, otherwise these should always be removed or disabled to help secure the host.

Conversely, patching is a much simpler discipline, with a general rule that the latest version is always the most secure (but test it first just to make sure it works!).

Configuration Hardening Procedures
In a similar way that patching should be done at least once a month, configuration hardening must also be practiced regularly – it is not a one-time exercise.

Unlike patching, where new vulnerabilities to software packages are routinely discovered then fixed via the latest patches, new configuration-based vulnerabilities are discovered very seldom. For example, the CIS Server 2008 Benchmark has only been updated 3 times despite the Operating System having been available for nearly 5 years now. The initial benchmark, Version 1.0.0 was released in March 2010, and then updated to Version 1.1.0 in July the same year. There was then a recent update to Version 1.2.0 in September 2011.
 
However, even though new configuration best practices are rarely introduced, it is vital that the hardened configuration of your Windows Servers, Linux and Unix hosts and network devices are reviewed regularly because changes could be made at any time which may adversely affect the inherent security of the device.
When you consider that any checklist can typically comprise between 200 and 300 measures, verifying that all hardening measures are being consistently and continuously applied has to be an automated process.

This can be provided by vulnerability scanning appliances such as Nessus or Qualys, however these are limited in the range and depth of checks they can make unless they are given administrator or root access to the host under test. Of course, in doing so, this actually introduces additional security vulnerabilities, as the host is now accessible via the network and there is at least one more administrator or root account in circulation which could be abused.

Configuration Hardening – File Integrity Monitoring
The other limitation of scanning appliances is that they can only take a snapshot assessment of the device concerned. While this is a good way to check compliance of the device with a configuration hardening best practice checklist, there is no way to verify that the filesystem has not been compromised, for example, by a Trojan or other malware.

Summary
Continuous file integrity monitoring combined with continuous configuration hardening assessment is the only true solution for maintaining secure systems. While branded checklists such as the CIS Benchmarks are a great source of hardening best practices, they are not the only option available. In fact, manufacturer provided checklists are generally a more focused source of vulnerability mitigation practices. Remember that there may be a wide choice of checklists using different terms and language, but that ultimately there is only one way to harden any particular system. What is more important is that you apply the hardening measures appropriate for your environment, balancing risk reduction against operational and functional compromises.

Google+

Device Hardening, Vulnerability Scanning and Threat Mitigation for Compliance and Security

All security standards and Corporate Governance Compliance Policies such as PCI DSS, GCSx CoCo, SOX (Sarbanes Oxley), NERC CIP, HIPAA, HITECH, GLBA, ISO27000 and FISMA require devices such as PCs, Windows Servers, Unix Servers, network devices such as firewalls, Intrusion Protection Systems (IPS) and routers to be secure in order that they protect confidential data secure.

There are a number of buzzwords being used in this area - Security Vulnerabilities and Device Hardening? 'Hardening' a device requires known security 'vulnerabilities' to be eliminated or mitigated. A vulnerability is any weakness or flaw in the software design, implementation or administration of a system that provides a mechanism for a threat to exploit the weakness of a system or process. There are two main areas to address in order to eliminate security vulnerabilities - configuration settings and software flaws in program and operating system files. Eliminating vulnerabilites will require either 'remediation' - typically a software upgrade or patch for program or OS files - or 'mitigation' - a configuration settings change. Hardening is required equally for servers, workstations and network devices such as firewalls, switches and routers.

How do I identify Vulnerabilities? A Vulnerability scan or external Penetration Test will report on all vulnerabilities applicable to your systems and applications. You can buy in 3rd Party scanning/pen testing services - pen testing by its very nature is done externally via the public internet as this is where any threat would be exploited from. Vulnerability Scanning services need to be delivered in situ on-site. This can either be performed by a 3rd Party Consultant with scanning hardware, or you can purchase a 'black box' solution whereby a scanning appliance is permanently sited within your network and scans are provisioned remotely. Of course, the results of any scan are only accurate at the time of the scan which is why solutions that continuously track configuration changes are the only real way to guarantee the security of your IT estate is maintained.

What is the difference between 'remediation' and 'mitigation'? 'Remediation' of a vulnerability results in the flaw being removed or fixed permanently, so this term generally applies to any software update or patch. Patch management is increasingly automated by the Operating System and Product Developer - as long as you implement patches when released, then in-built vulnerabilities will be remediated. As an example, the recently reported Operation Aurora, classified as an Advanced Persistent Threat or APT, was successful in infiltrating Google and Adobe. A vulnerability within Internet Explorer was used to plant malware on targeted users' PCs that allowed access to sensitive data. The remediation for this vulnerability is to 'fix' Internet Explorer using Microsoft released patches. Vulnerability 'mitigation' via Configuration settings ensures vulnerabilities are disabled. Configuration-based vulnerabilities are no more or less potentially damaging than those needing to be remediated via a patch, although a securely configured device may well mitigate a program or OS-based threat. The biggest issue with Configuration-based vulnerabilities is that they can be re-introduced or enabled at any time - just a few clicks are needed to change most configuration settings.
How often are new vulnerabilities discovered? Unfortunately, all of the time! Worse still, often the only way that the global community discovers a vulnerability is after a hacker has discovered it and exploited it. It is only when the damage has been done and the hack traced back to its source that a preventative course of action, either patch or configuration settings, can be formulated. There are various centralized repositories of threats and vulnerabilities on the web such as the MITRE CCE lists and many security product vendors compile live threat reports or 'storm center' websites.

So all I need to do is to work through the checklist and then I am secure? In theory, but there are literally hundreds of known vulnerabilities for each platform and even in a small IT estate, the task of verifying the hardened status of each and every device is an almost impossible task to conduct manually.
Even if you automate the vulnerability scanning task using a scanning tool to identify how hardened your devices are before you start, you will still have work to do to mitigate and remediate vulnerabilities. But this is only the first step - if you consider a typical configuration vulnerability, for example, a Windows Server should have the Guest account disabled. If you run a scan, identify where this vulnerability exists for your devices, and then take steps to mitigate this vulnerability by disabling the Guest Account, then you will have hardened these devices. However, if another user with Administrator privileges then accesses these same servers and re-enables the Guest Account for any reason, you will then be left exposed. Of course, you wont know that the server has been rendered vulnerable until you next run a scan which may not be for another 3 months or even 12 months. There is another factor that hasn't yet been covered which is how do you protect systems from an internal threat - more on this later.

So tight change management is essential for ensuring we remain compliant? Indeed - Section 6.4 of the PCI DSS describes the requirements for a formally managed Change Management process for this very reason. Any change to a server or network device may have an impact on the device's 'hardened' state and therefore it is imperative that this is considered when making changes. If you are using a continuous configuration change tracking solution then you will have an audit trail available giving you 'closed loop' change management - so the detail of the approved change is documented, along with details of the exact changes that were actually implemented. Furthermore, the devices changed will be re-assessed for vulnerabilities and their compliant state confirmed automatically.

What about internal threats? Cybercrime is joining the Organised Crime league which means this is not just about stopping malicious hackers proving their skills as a fun pastime! Firewalling, Intrusion Protection Systems, AntiVirus software and fully implemented device hardening measures will still not stop or even detect a rogue employee who works as an 'inside man'. This kind of threat could result in malware being introduced to otherwise secure systems by an employee with Administrator Rights, or even backdoors being programmed into core business applications. Similarly, with the advent of Advanced Persistent Threats (APT) such as the publicized 'Aurora' hacks that use social engineering to dupe employees into introducing 'Zero-Day' malware. 'Zero-Day' threats exploit previously unknown vulnerabilities - a hacker discovers a new vulnerability and formulates an attack process to exploit it. The job then is to understand how the attack happened and more importantly how to remediate or mitigate future re-occurrences of the threat. By their very nature, anti-virus measures are often powerless against 'zero-day' threats. In fact, the only way to detect these types of threats is to use File-Integrity Monitoring technology. "All the firewalls, Intrusion Protection Systems, Anti-virus and Process Whitelisting technology in the world won't save you from a well-orchestrated internal hack where the perpetrator has admin rights to key servers or legitimate access to application code - file integrity monitoring used in conjunction with tight change control is the only way to properly govern sensitive payment card systems" Phil Snell, CTO, NNT

See our other whitepaper 'File-Integrity Monitoring - The Last Line of Defense of the PCI DSS' for more background to this area, but this is a brief summary -Clearly, it is important to verify all adds, changes and deletions of files as any change may be significant in compromising the security of a host. This can be achieved by monitoring for should be any attributes changes and the size of the file.

However, since we are looking to prevent one of the most sophisticated types of hack we need to introduce a completely infallible means of guaranteeing file integrity. This calls for each file to be 'DNA Fingerprinted', typically generated using a Secure Hash Algorithm. A Secure Hash Algorithm, such as SHA1 or MD5, produces a unique, hash value based on the contents of the file and ensures that even a single character changing in a file will be detected. This means that even if a program is modified to expose payment card details, but the file is then 'padded' to make it the same size as the original file and with all other attributes edited to make the file look and feel the same, the modifications will still be exposed. This is why the PCI DSS makes File-Integrity Monitoring a mandatory requirement and why it is increasingly considered as vital a component in system security as firewalling and anti-virus defences.

Conclusion
Device hardening is an essential discipline for any organization serious about security. Furthermore, if your organization is subject to any corporate governance or formal security standard, such as PCI DSS, SOX, HIPAA, NERC CIP, ISO 27K, GCSx Co Co, then device hardening will be a mandatory requirement. - All servers, workstations and network devices need to be hardened via a combination of configuration settings and software patch deployment - Any change to a device may adversely affect its hardened state and render your organization exposed to security threats - file-integrity monitoring must also be employed to mitigate 'zero-day' threats and the threat from the 'inside man' - vulnerability checklists will change regularly as new threats are identified