ACouch

10th October 201523rd November 2016

Web Server Hardening: Removing Server and Software version information

All too often web servers are setup with fairly standard configuration. The HTTP Headers display various information from time stamps, cookie info and also server version.

Server version information especially should be removed from the HTTP headers as it allows an attacker to identify what the underlying server and web server version is. If vulnerabilities lie in the stated version, an attacker can concentrate there efforts towards that version identified on your system more easily.

The below configurations should be set for minimal server version info.

Linux/Apache/PHP:

In the /etc/php5/apache2/php.ini file find the line ‘expose_php = On’ and set the parameter from ‘On’ to ‘Off’ as below:

; Decides whether PHP may expose the fact that it is installed on the server
; (e.g. by adding its signature to the Web server header).  It is no security
; threat in any way, but it makes it possible to determine whether you use PHP
; on your server or not.
; http://php.net/expose-php
expose_php = Off

This will remove the ‘X-Powered-by’ option from the HTTP header thus removing your PHP version and OS version information.

In the /etc/apache2/conf-available/security.conf locate the ‘Server Tokens Full’ line and change the parameter from ‘Full’ to ‘Prod’ this will give the least amount of information. Unfortunately without changing this hard-coded parameter and recompiling apache yourself there is no way to reduce this information any further.

# ServerTokens
# This directive configures what you return as the Server HTTP response
# Header. The default is 'Full' which sends information about the OS-Type
# and compiled in modules.
# Set to one of:  Full | OS | Minimal | Minor | Major | Prod
# where Full conveys the most information, and Prod the least.
#ServerTokens Minimal
#ServerTokens OS
#ServerTokens Full
ServerTokens Prod

In the same file locate the ‘ServerSignature On’ line and change the parameter from ‘On’ to ‘Off’, or comment out the existing line and add a new one in with the ‘Off’ option as below.

The ServerSignature isn’t actually information from or displayed in the HTTP headers, it is however information that is displayed at the bottom of for example a 404, 403 default page, which again will give away information about your system. Better still use a custom 404 or 403 page however if you don’t have custom pages this is the next best thing.

# Optionally add a line containing the server version and virtual host
# name to server-generated pages (internal error documents, FTP directory
# listings, mod_status and mod_info output etc., but not CGI generated
# documents or custom error documents).
# Set to "EMail" to also include a mailto: link to the ServerAdmin.
# Set to one of:  On | Off | EMail
ServerSignature Off
#ServerSignature On

And as usual you should test these configurations out in a test environment first before your main production web servers.

30th September 201523rd November 2016

Windows Client/Server Hardening Part 1: Remote Desktop

We can harden the Windows Client/Server Remote Desktop Protocol (RDP) in several ways using either local settings or preferable through Group Policy. As a minimum we should harden RDP in the following ways:

Using Network Level Authentication (NLA).
Setting Terminal Services Encryption Level to High.
Force the use of TLS 1.0 protocol as a transport layer for the service.
Setting the local security policy of the either the server or client to use only FIPS-140 compliant cryptography.

This post will we go through how we can accomplish these tasks.

Network Level Authentication (NLA)

Network level authentication allows the client to authenticate earlier in the remote connection process rather than the normal process. This option is most commonly seen in the Remote Desktop settings in the system properties as below:

RDP - NLA — Remote Desktop Settings – Network Level Authentication

However it is far easier to set this via Group Policy and distribute to all your Servers as below:

RDP- NLA GPO — Remote Desktop Services – Network Level Authentication GPO

This can be applied to both Servers and workstations from Windows Vista and above.

Setting Terminal Services Encryption Level to High

Setting the Encryption level to High encrypts data sent from client to server and server to clients using 128 bit encryption. Like with the above example we can set the Terminal Services Encryption level to High either locally on the server or via Group Policy. In a domain environment the GPO is the way to go. With windows server 2008 this could be set locally through the GUI by navigating from the start menu–>Administrative Tools–>Remote Desktop Services–>Remote Desktop Session Host Configuration, then double clicking on the ‘RDP-TCP’ connection in the middle of the screen. The Encryption level can be found on the General tab as below:

Remote Desktop Services - Encryption Level 'High' — Remote Desktop Services – Encryption Level ‘High’

Unfortunately Microsoft removed the ‘RD Session Host Configuration’ options as standard with Server 2012 R2. Rather than adding in the whole RDS role to apply this option in the GUI you can apply it via GPO which will in turn apply to both 2008 and 2012 as below:

RDP - Encryption Level High GPO — Remote Desktop Services – Encryption Level High GPO

Force the use of TLS 1.0 protocol as a transport layer for the service

Forcing the use of TLS 1.0 mitigates the risks associated with SSL 3.0 protocol. Like with the previous option this can only be set in the GUI locally on Windows Server 2008. With this being said, and from a management perspective GPO is our preferred option, in order to apply this setting to both Windows Server 2008 and 2012.

This option is set in Windows Server 2008 locally by navigating from the start menu–>Administrative Tools–>Remote Desktop Services–>Remote Desktop Session Host Configuration, then double clicking on the ‘RDP-TCP’ connection in the middle of the screen as below:

RDP - TLS 1.0 — Remote Desktop Services – Security Layer TLS 1.0

The GPO is located here:

RDP - TLS 1.0 GPO — Remote Desktop Services – Security Layer TLS 1.0 GPO

Setting the local security policy of the either the server or client to use only FIPS-140 compliant cryptography

This hardening technique can be accomplished by enabling the ‘System Cryptography’ through the Local computer policy editor or through GPO via the domain. It will force the use of FIPS-140 compliant cryptography for either the client or server across the system. This is windows system setting rather than an RDP setting, however by setting this you will be forcing the use of FIPS-140 compliant cryptography for Remote Desktop settings. If this setting is enabled only the FIPS-140 approved cryptographic algorithms are used: 3DES and AES for encryption, RSA or ECC public key for TLS key exchange and SHA256, SHA284 and SHA512 for TLS hashing. In the case of Remote Desktop it will only use 3DES.

Adding through the local computer policy can be achieved by opening a Microsoft Managment Console (MMC) adding a snap in; Group Policy Object Editor. As below:

RDP - FIPS-140 — Remote Desktop Services – FIPS-140 ‘Enabled’

Setting via GPO can be achieved as below:

RDP - FIPS-140 GPO — Remote Desktop Services – FIPS-140 GPO

Hardening RDP – GPO Settings

Putting all these settings together in one GPO would look something like this:

It clearly goes without saying you should first test these methods out for yourself in a safe test environment first before diving into your main production domain or web servers. Adding higher grade encryption to your communications across the domain may have extra computation costs in terms of performance on your network.

26th September 201523rd November 2016

Patch Management

Having good Patch managment is essential, and being able to keep on top of your microsoft patching is paramount to good security. It is all too easy to get caught behind in keeping systems upto date, since almost all software needs patching these days. Clawing your way back from out of date patches on servers can be a nightmare however automating patch managment if setup correctly with correctly configured maintenance windows makes life easier. Using products like WSUS, or better still SCCM 2012 R2 and having well built resiliant system architecture, can remove the pain from this task. Having a robust patching policy, and management buy in from the business is also essential. This enables the IT team to bring servers down at an appropriate time for that inevitable reboot is just as important and can make the process run far more effectively. Does this bring into question whether this is an IT issue, a resourcing issue or a business strategy issue? Getting down time approval from a section of the business can be tricky without managment buy in, however, not letting the IT team take down that all important business critical system for patching is in itself a risk. A risk assement needs to be carried out by the business as to whether they delay remediating that zero day vulnerabilty vs letting the IT team patch the server and losing potential revenue whilst the server is down vs patching the system which subsequntly causes a system failure. All businesses should be asking themselves ‘what are my vulnerabilities?’. Subsequently what is the impact vs likelihood of this resulting in my overall risk? Of course this will be a case by case decision, with multiple factors, ie what is the patch fixing, the system archetecture etc. This needs to be weighed up against the consenquenses of not applying a patch ie can you afford to be hacked…

What are your thoughts?

15th September 201523rd November 2016

Password Security

So what is good password security hygiene?

Its important to have good password security in order to stop the bad guys from logging in with your account, easy to guess and common word passwords can be cracked with many different brute force tactics. In my opinion the following attributes class as good password hygiene:

No Dictionary words – these can be cracked very easily, even with numbers at the beginning or end.
Use a strong complex password containing:
Minimum of 9 characters (more like 15)
Must contain numbers
Must contain special character
Must contain symbols
Change your password periodically – with a large complex password I’m not so fussed about this. If I’m alerted to the fact I need to change my password it would indicate to me its potentially been compromised. Or unless I know it has been compromised then I will change it.
Don’t use the same password for different services. eBay, PayPal and your email account should all have different passwords!
Use two factor authentication where possible.

Alternatively, you could save yourself the headache and use a password manager. However does this then bring into question whether the ‘PASSWORD’ is now obsolete? I don’t have the answer to this question, however what I do know is that these days its my password manager that logs me in to services like eBay I don’t have a clue as to what most of my passwords are. They are all so complex and I have so many I wouldn’t be able to remember them if i tried. Is it time for a new authentication method?

What are your thoughts?

13th September 201523rd November 2016

SSL/TLS cipher suite selection and breakdown.

How do I know which cipher suites to select for my web server?

This is a common issue, sysadmins have their web servers up or vpn servers configured. However they are often using older SSL protocols and older cipher suites that are now vulnerable to attack in certain scenarios. We need to understand what a cipher suite is actually doing in order to select the correct ones.

For SSL/TLS connections a cipher suite is selected based on a number of tasks that it has to perform, the client uses a preferred cipher suite list and the server will normally honor this unless it also has a preferred list, set by the sysadmin.

Initial Key Exchange, the Asymmetric Encryption: This will most commonly be RSA, however the following are options; RSA ( Ron Rivest, Adi Shamir, and Leonard Adleman), DH (Diffie-Hellman) or ECDH (Elliptic Curve Diffie-Hellman).
RSA key length should be 2048 bit minimum. ECDH and others should be an equal strength, note the ECDH key length will be significantly lower due to the way the algorithm works! The Asymmetric Encryption is only being used in the initial key exchange and for the session symmetric encryption key. The Asymmetric encryption method could be used for the data transfer however the computational power needed is far higher than the symmetric Encryption due to the key size.

Session data, the Symmetric Encryption: The most commonly used three ciphers we see in use being RC4, 3DES and AES, careful selection of ciphers is required here:

RC4 (Rivest Cipher 4) although used almost everywhere is now considered weak, and being phased out by Microsoft. This should be avoided.
3Des (Triple Data Encryption Standard) uses DES and encrypts three times hence the ‘triple’. The original DES uses a weak key length and is considered weak.
AES (Advanced Encryption Standard) 128 bit block size using 128, 192 and 256 bit keys to encrypt data, is all good.

Many other options are available that are not so common include Blowfish, Twofish, Serpent etc. I won’t be going into the different ciphers here or the difference between Block (3DES+ AES) and Stream (RC4) on this page, I’ll save this for another blog.

Digital Signature – The digital signature is used to verify the server.

Integrity check – Here SHA-2 or SHA 256 (Secure Hash Algorithm) should be used. MD5 and SHA1 are being phased out due to weaknesses. SHA1 will still be seen on certificates however Google Chrome will now show a warning for this since October 2014. Microsoft has a deprecation policy indicating SHA1 issued certificates should not be used after 1/1/2017.

With all that being said, lets look at a typical cipher suite. Below is what you might commonly see in the likes of Firefox if you click on the padlock in the address bar and then click on more information.

Lets look at the cipher suite below for an example. We’ll break down the individual blocks to see what it actually all means.

TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256

TLS – The protocol in use
ECDHE – Elliptic Curve Diffie-Hellman key-exchange using ephemeral keys. More on ephemeral keys later, however this is what is going to give you that all important ‘Perfect Forward Secrecy’. Marked with the E at the front or behind for Ephemeral.
ECDSA – Elliptic Curve Digital Signature Algorithm, used to create the digital signature for authentication.
AES_128 – Advanced Encryption Standard 128 bit key size, used for the session encryption method for data.
GCM – Galois/Counter Mode an operation for block ciphers designed to provide both data authenticity (integrity) and confidentiality. GCMAC – provides authentication only.
SHA256 – Secure hashing Algorithm 256bit used for message integrity.

With the above knowledge and knowing the current vulnerabilities in SSL and TLS we can now make an informed decision and build the cipher suites we would like to use in Windows and Linux.

10th September 201523rd November 2016

Changing SSL TLS Cipher Suites in Windows and Linux

I have added a basic guide for changing SSL TLS cipher suites that Windows Server IIS and Linux Ubuntu Apache2 use. Allowing only secure ciphers to be negotiated between your web server and client is essential. This guide will go through how to change and select the different ciphers for both Windows server 2012 R2 and Ubuntu 14.04 in order to help mitigate some of the vulnerabilities in the SSL/TLS protocols.

Read further on the Resource page for changing SSL TLS Cipher Suites here.

7th September 201523rd November 2016

Linux Firewall

Check out the Linux Firewall mini setup guide which demonstrates the use of iptables in Linux. Here I demonstrate a few basic commands and rules and explained how we can allow and deny specific traffic on your Linux server. The scenario is for typical web server allowing only HTTP, HTTPS and SSH. Host based firewalls are often overlooked relying solely on perimeter defenses however are an important aspect of protecting your endpoint whether that is on a server or workstation. Iptables in built into Linux is a pretty capable command line based stateful firewall. Once you have the hang on the syntax it is fairly straightforward to implement and customize to your own requirements.

Click to check out the full Linux Firewall iptables mini guide here.

4th September 201523rd November 2016

Labs and Virtualization

Anybody that works in IT that really wants to progress will know and will have experienced the value of labs and virtualization. Being able to test an idea or for learning in a virtual lab, its essential whether it be in Linux or Windows. Being able to through up a webserver to test a setting or a domain controller to test a group policy. Whether its on a full blown ESXi deployment or just virtual box. The aim of this page is to go through some of the virtualization options that are available to the home user, and dig into the software and hardware that’s required. Check out the following page for some hint and tips: https://www.adamcouch.co.uk/labs-projects/labs-and-virtualization/

2nd September 201523rd November 2016

Advanced Persistent Threats

Advanced Persistent Threats are becoming an increasingly prevalent threat to organisations and the information they hold. Advanced Persistent Threats are a type of attack that are defined by the National Institute of Standards and Technology (2011) as being a highly sophisticated attack, well-orchestrated, well-funded and are targeted at specific organisations or people. These type of attacks seek to gain a foothold inside an organisation, remain undetected and over a specific time frame from Advanced Persistent Threats
hours to months laterally move across the network and exfiltrate data, the specific information assets they desire undetected, often more than once. This is as opposed to the more conventional opportunist attacker who isn’t interested in any particular target or any specific data. If the attacker doesn’t succeed the first time they will simply move onto the next weakest victim, these types of attack have often in the passed been used only to heighten the profile of a hacker. Attack vectors include Spear fishing attempts with either email content or attachments carrying the payload through to malware and more commonly malvertising.

Evidence of high profile targeted Advanced Persistent Threats are being reported in the press more than ever. Some examples of such being Target’s 2013 breach, Sony 2014 breach and more recently Ashley Madison 2015 this list goes on. Upholding the confidentiality, availability and integrity of information that these sites and companies hold is possible through the use of good IT Governance. With an effective and current Information Security Management System in place and utilizing good strong controls organisations can better protect themselves from Advanced Persistent Threats.

Ensuring user awareness training is provided. Ensuring the desktop is appropriately secured. Keeping software up to date. Ensuring strong Authentication mechanisms are in place. Ensuring Antivirus, Firewalls and Host Intrusion Detection/Prevention systems are appropriately configured and kept up to date are all only some of the controls that should be in place as a standard to help mitigate the risk.

All too often perimeter defenses are in place and appropriately secured from the outside, however from inside out, the desktop and the actual user are all attack vectors that are left open to threats. The threat landscape is constantly evolving, we need to stay on top in order to try and evade APTs.

SMB Signing through the Registry

SMB Signing through Group Policy