AWS IAM Policy exclusion

Few days back I was in a situation were I have to provide full access (sort of) on our AWS account to one of our partner so they can setup an Elastic Beanstalk cluster. Obviously I was not in favor to provide complete access to the resources which are critical for us so I come up with below IAM policy which is not only protecting our critical resources but also providing full access to deploy a Elastic Beanstalk cluster.

Download: IAM Policy

The logic in above policy is to add an additional tag “critical : true” (Key and Value respectively) to all of your existing resources and setup an explicit deny on resources which matches the tag (Note that not all AWS resources support tagging). To further extend the protection we are also setting up direct explicit deny rules on each resource on which we don’t want to provide access to IAM user.


Automatic RootKit scanning using “chkrootkit”

Scanning servers for presence of any hidden RootKit was always an important role of system administration but recently discovery of Linux Ransomeware (luckily fix too) has highlighted the importance of it and also motivated me to write something about it. So what I have come with?

chkrootkit is among mostfamous and widely used tool for the detection of rootkits so I decided to write a script which take care of the installation, scanning and the report. The installation is pretty easy and quickly but why I wrote the script?

Usually when smart hackers are able to inject rootkit in server they also scan the system for the presence of AntiRootKit and if they found they replace it with hacked version of tool, but they are not done yet as they also replace your system binaries (ls, ps, egrep, awk etc) which Antirootkit tools uses hence by using the modified binaries Antirootkit tools fail to detect the presence of any rootkit and you think that you are safe.

So what script does?

The script download the latest version of chkrootkit, compile it, download safe versions of my system libraries (Ubuntu 14.04.3 LTS, which you need to replace with your own as you should not be using mine on your servers), scan the system and send its report on your email. As we don’t want hackers to know that we are using antirootkit when everything is done the script also remove the traces of chkrootkit installation and anything related. Lastly remove itself (the bash script) from filesystem and clear history. You can find the script here

Once the script downloaded you need to execute it as below

./chkrootkit.sh && history -c && history -w

Notes: Before using the script you should also review your hosts file (/etc/hosts) for any malformed entries as that way hacker can lead you to its own website and download modified version of chkrootkit.

Don’t install any cron of it as it will help hacker to detect the presence of antirootkit tool.

Update: If you are receiving “chkrootkit: can’t find `ssh’” error then its a bug in current release and you can find additional details here.


How to enable Online Certificate Status Protocol (OCSP) Stapling in Nginx

Generally when you access a secure site (HTTPS) browser has to create another request to specific certificate revocation server known as OCSP Responder to verify whether the certificate is revoked or not, due to this some browsers (Chrome etc) does not implement OCSP because of this overhead.

By implementing OCSP Stapling you can replace the role of your OCSP Responder by letting the your web server to periodically query the OCSP Responder itself and then serve client both certificate and the proof that certificate is not revoked.

To enable OCSP Stapling in Nginx add following lines under your SSL listener.

ssl_stapling on;
ssl_stapling_verify on;
ssl_trusted_certificate /etc/nginx/ssl/sub.class1.server.ca.pem;

ssl_trusted_certificate should contain your intermediate certificates followed by your Root CA.

Once OCSP Stapling is properly configured you can verify it online by SSL Labs or OpenSSL.

echo QUIT | openssl s_client -connect azfarhashmi.com:443 -status 2> /dev/null | grep -A 17 'OCSP response:' | grep -B 17 'Next Update'

If you see any result then OCSP Stapling is working fine. Don’t forget to replace ‘azfarhashmi.com‘ with your own domain.


Securing Solr installation

You can protect your Solr installation in just few minutes.

    1.  Never install Solr in your web server working directories i-e: under your webroot
    2. Make Solr listen only on localhost

      vi bin/solr.in.sh
      SOLR_OPTS="$SOLR_OPTS -Djetty.host="
    3. Put localhost8983 as Solr server address in your application configuration, don’t use external / public address
    4. If you want to run SELECT queries from client’s browser (AJAX calls etc) then put a reverse proxy on front of your instance and protect remaining areas of Solr console (admin, update etc). Below is an example of Nginx host.

location ~* /solr/\w+/select {
location / {
auth_basic "Restricted";
auth_basic_user_file /etc/nginx/htpasswd;

By above nginx will only allow SELECT queries and will ask authentication on rest.


HTTP Strict Transport Security (Enable with CAUTION)

As Google is encouraging use of HTTPS on whole website so its good time to force whole website on HTTPS, typically you can do it by a simple redirect from your web-server but now you can do it even more efficiently at client level by passing an additional HSTS header.


add_header Strict-Transport-Security "max-age=63072000; includeSubdomains; preload";


Header always set Strict-Transport-Security "max-age=63072000; includeSubdomains; preload"

This will tell the browser that the site should be accessible only via HTTPS so in-case you type http://yourdomain the browser itself redirect it to https://yourdomain (Once the header is received and browser stored the information locally for future use).

You can also submit your domain to include in HSTS Preloading list. This service will submit your domain for the inclusion in the Chrome list which is also followed by other major browsers. HSTS is supported by all mainstream browsers and you can find full compatibility matrix here. This list is hard-coded into browsers so the browser will automatically use HTTPS for domains included in that list.

So far all good so where is the CAUTION!

If you want to use HSTS then you must be sure that you will be supporting HTTPS on whole site for a long period and specially when you are submitting it for HSTS Preloading. Those lists are hard-coded in browsers and does not have any method to de-list your domain and even if you are able to submit the de-list request then it may take months to take effect as this involves approval of request, update list in newer version of browsers, release of newer version of browser etc, but this is still not enough until your visitors /users have the newer browser version installed.

So whenever your are going to use HSTS put special attention on “max-age”, “includeSubdomains”, “Preloading” and “HSTS Preload Submission” otherwise you will be in big trouble if you want to stop use of HSTS on your site or don’t want to use HTTP on any sub-domain etc, also if your certificate is bad i-e expired, bad_cert_domain etc then browser won’t allow you to bypass or proceed for HSTS enabled sites.


Squueze-LTS WARNING: The following packages cannot be authenticated!

I was suing squueze-lts repos from a while but suddenly I start getting following error when performing apt-get upgrade (after apt-get update)

WARNING: The following packages cannot be authenticated!

So what I did to sort it.

Removed squeeze-lts repos and pinning then

apt-get clean
apt-get update
apt-get upgrade
apt-get install debian-keyring debian-archive-keyring

Then I re-add squeeze-lts repos and pinning and re-run apt.

apt-get update
apt-get upgrade

Voila, warning gone and everything back to to normal.



POODLE Bite: Exploiting The SSL 3.0 CVE-2014-3566

Google has recently discovered an exploit in the implementation of SSL V3 protocol which potentially compromise secure connections. It is recommended to system administrators to disable SSL 3.0 on their servers and use TLS 1.1 or 1.2.

This vulnerability does not affect your SSL Certificates so there is no need to renew, reissue, or reinstall any SSL Certificates.

How to disable SSL V3.

Edit your SSL virtualhost and make sure it contain below parameter.

SSLProtocol all -SSLv2 -SSLv3

Edit your SSL virtualhost and make sure it contain below parameter.

ssl_protocols TLSv1.2 TLSv1.1 TLSv1;


Download DisableSSL3.zip, extract it and install DisableSSL3.reg, reboot server.

Finally make sure you have restarted the web server service so the changes can take effect.

Amazon has also released instructions how to cop with this vulnerability.


Once you disabled SSL V3 you can test your site / server from following tool.


Alternatively you have also verify it via command line.

openssl s_client -connect google.com:443 -ssl3

If there is hadshake failure then SSL V3 is disabled on server.

UPDATE: 10/16/2014

The vulnerability has been fixed in OpenSSL 1.0.1j version, so lets wait for the patches from Debian, RedHat and other Linus distributors.


Microsoft Windows Zero-Day Vulnerability CVE-2014-4114

Yesterday a Zero-Day vulnerability was found in all Microsoft Windows operating systems versions which was discovered and announced by iSIGHT Partners in collaboration with Microsoft.

Now as Microsoft has already released patch for it it so everyone is suggested to patch all versions of Windows asap.

More details about the patch can be found at



Remote exploit vulnerability in bash CVE-2014-6271

A remotely exploitable vulnerability has been found in bash on Linux. The vulnerability has the CVE identifier CVE-2014-6271. This affects all Linux distributions and could pose a bigger threat to computer than the “Heartbleed” bug that discovered in April so you need to patch servers asap.

The exploit can potentially be used to execute arbitrary code on environment variables that are passed to child processes. This could include CGI scripts that are used to pass through environment variables from a web server to the child process and that is run by a bash script for vulnerable versions of bash.

Both Debian and RedHat have provided updated binaries and other operating system vendors are expected to follow this quickly.

More OS specific details can be found below.




You can verify if your server is vulnerable to this exploit or not by executing following command.

env x='() { :;}; echo vulnerable' bash -c "echo this is a test"

If it reports “vulnerable this is a test” then you need to apply the security update asap but if you see something like below then your good.

bash: warning: x: ignoring function definition attempt
bash: error importing function definition for `x
this is a test


The initial round of patches to fix CVE-2014-6271 have proven ineffective at fully resolving the issue. A new CVE code has been issued “CVE-2014-7169“ and vendors have already provided new patch for it so everyone is required to apply the new update.