Category Archives: linux how-to

Allow access to S3 bucket only from EC2 instances

The goal of this post is to show how to enable access to objects inside S3 buckets only from your EC2 instances, while at the same time denying public access.
In order to make this work, you’ll need to add an Endpoint to your VPC. Endpoints enable you to connect directly to S3 without going through a gateway (say because you want your instances isolated, LAN only).
Continue reading →

Logging drupal logs with Logstash and drupal_dblog

Do you have a Drupal website with a lot of traffic? Then you might know how it feels when you have to debug a problem and you find out that the period you are looking for is no longer available in the Recent Logs messages menu.

One of our clients, whose website is powered by Drupal and serves ~500.000/requests per day, has tasked us to keep a history of these logs, so issues can be tracked, quantified and displayed in a more visual friendly way.

OS used in this scenario: Ubuntu Server
Software needed: ElasticSearch, Logstash, drupal_dblog plugin, Kibana
Infrastructure scenario: 1 web server (192.168.1.10), 1 database server (192.168.1.99).
All required software will be installed on the web server.
Continue reading →

shellshock bash horror and Apache

realizationface
Also referred to as CVE-2014-6271, CVE-2014-7169, CVE-2014-7186 and CVE-2014-7187, the now infamous shellshock flaw refers to Bash being able to blindly run commands inside specially crafted environment variables.

Just run env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
OR
env var='() {(a)=>\' bash -c "echo vulnerable"; cat echo.
If in the output you find the word vulnerable, then you are.

A few of the identified attack vectors are:

  • ForceCommand of OpenSSH;
  • Apache with mod_cgi or mod_cgid;
  • DHCP invoking shell scripts to configure clients;

    • And possibly many other.

    What I want to focus on here is Apache and mod_cgi, because that seems the most exposed vector of attack and because nobody actually mentions the dependencies for this attack to be successful.

    As a note, at the moment there is conflicting information on whether this affects mod_php with exec functions enabled. Quoting from securityblog.redhat.com: PHP scripts executed with mod_php are not affected even if they spawn subshells.
    But I haven’t tested this myself as of yet.

    In order to make this work under mod_cgi you would need to meet the following conditions:

  • a script which spawns a shell, like #!/bin/bash or by using popen(), exec, shell_exec etc;
  • that same script parsed by mod_cgi (by default it executes only extensions with .cgi, as defined by AddHandler cgi-script .cgi);
  • have the script publicly discoverable – possibly through Google dorking for /bin/bash.