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…
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.
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.
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.
A brief summary of the commands needed to install VirtualBox Guest Additions in Kali Linux v1.x. Having the Guest Additions installed is very useful, being able to copy and paste text like bash lines like the below is extremely useful. There is also the extra screen options such as the transparency mode. Being able to copy files in and out of the system into the host is also very useful.
After it has successfully installed you will now be able to go full screen, add in file sharing options, copy and paste and clipboard functionality. Enjoy.
Having spent many hours over several days trying to get to a point were I could run a Cisco ASA in GNS3 in stable condition has proven to to be harder than first thought. However I now have a set of configuration options specific to the Cisco ASA to keep it running in a stable manner in GNS3. Check it out under my Labs and Projects menu here, let me know your thoughts or any other better ways to achieve this.