SameSite cookies

Recently, while reading through the updated 2017 OWASP Top Ten RC1 documentation, last updated in 2013, I noticed a recommendation to use Cookies with the “SameSite=strict” value set to reduce CSRF exposure in section A8.

Consider using the “SameSite=strict” flag on all cookies, which is increasingly supported in browsers.

Similar to the way that HttpOnly and Secure attributes have been added, SameSite allows for additional control.

Per the documentation, as of April 2017 the SameSite attribute is implemented in Chrome 51 and Opera 39. Firefox has an open defect, but I would expect it to be added soon to follow Chrome.

Set-Cookie: CookieName=CookieValue; SameSite=Lax;
Set-Cookie: CookieName=CookieValue; SameSite=Strict;

According to the specification you can issue the SameSite flag without a value and Strict will be assumed:

Set-Cookie: CookieName=CookieValue; SameSite

As many programming languages and server runtime environments do not yet support this for session cookies, you can use the Apache Tier1 configuration to append them.

Header edit Set-Cookie ^(JSESSIONID.*)$ $1;SameSite=Strict
Header edit Set-Cookie ^(PHPSESSID.*)$ $1;SameSite=Strict

It looks like PHP.INI might support the following attribute in a future release, but it’s not there yet!



Modify Ubuntu Swappiness for performance

Sometimes, it is possible to improve the performance of Ubuntu on older hardware by modifying the disk swapping behavior.

Check your current setting:

cat /proc/sys/vm/swappiness

To modify the behavior, just change the value and reboot. Most documentation recommends trying a value of 10.

sudo vi /etc/sysctl.conf

Add (or change):

# Decrease swappiness value (default:60)


Sonatype Nexus2 Repository Manager OSS

To allow for repeatable, faster builds in a continuous build environment, it’s often a good idea to use a central repository to cache common assets and prevent the need to download assets from the internet for each build. Using Nexus allows for those transfers to occur over your local network for previously downloaded assets.

You can download the WAR from:

And install on your Java application server, such as Apache Tomcat, via normal means.

If you are using Maven, you’ll need to make appropriate changes in (/.m2/settings.xml) to direct your builds to use Nexus.

Jenkins and other build automation tools will require similar changes.


Install Fail2Ban on Ubuntu to protect services

Many common adminstrative services such as VPN and SSH are exposed on known port numbers, unfortunately this makes it easy for hackers to use tools to attempt to access the systems. Use of countermeasures such as Fail2Ban can block them after a few failed attempts.

Installation Steps:

  1. sudo apt-get install fail2ban
  2. sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
  3. sudo vi /etc/fail2ban/jail.local
  4. Update:
    destemail & sender
    sudo /opt/splunkforwarder/bin/splunk add monitor /var/log/fail2ban.log -index main -sourcetype Fail2Ban

    Splunk (manual):
    sudo vi /opt/splunkforwarder/etc/apps/search/local/inputs.conf

    disabled = false
    index = main
    sourcetype = Fail2Ban

  6. sudo service fail2ban restart


Adding OpenSSH server logs to Splunk

By default, in most Linux distros, OpenVPN log output goes to the authlog, which is usually at /var/log/auth.log, as such it is trivial to add them to Splunk monitoring:

sudo /opt/splunkforwarder/bin/splunk add monitor /var/log/auth.log -index main -sourcetype OpenSSH

Splunk (manual):
sudo vi /opt/splunkforwarder/etc/apps/search/local/inputs.conf

disabled = false
index = main
sourcetype = OpenSSH


Adding OpenVPN logs to Splunk on Ubuntu

By default, in most Linux distros, OpenVPN log output goes to the syslog, which is usually at /var/log/syslog. However, your config files can set the logfile location explicitly, as shown below:

  1. sudo vi /etc/openvpn/server.conf
  2. Change or add:
    log-append /var/log/openvpn.log
  3. Restart to use the new config:
    sudo service openvpn restart
  4. Add to Splunk forwarder:
    sudo /opt/splunkforwarder/bin/splunk add monitor /var/log/openvpn.log -index main -sourcetype OpenVPN

    Splunk (manual):
    sudo vi /opt/splunkforwarder/etc/apps/search/local/inputs.conf

    disabled = false
    index = main
    sourcetype = OpenVPN


Squid3 Proxy on Ubuntu

Using a personal proxy server can be helpful for a variety of reasons, such as:

  • Performance – network speed and bandwidth
  • Security – filtering and monitoring
  • Debugging – to trace activity

Here are some simple steps to get you started,  obviously you will need to further “harden” security to make it production ready!

sudo apt-get install squid3

cd /etc/squid3/
sudo mv squid.conf squid.orig
sudo vi squid.conf

NOTE: the following configuration works, but will likely need to be adapted for your specific usage.

http_port 3128
auth_param digest program /usr/lib/squid3/digest_file_auth -c /etc/squid3/passwords
#auth_param digest program /usr/lib/squid3/digest_pw_auth -c /etc/squid3/passwords
auth_param digest realm proxy
auth_param basic credentialsttl 4 hours
acl authenticated proxy_auth REQUIRED
acl localnet src # RFC 1918 possible internal network
acl localnet src # RFC 1918 possible internal network
acl localnet src # RFC 1918 possible internal network
acl localnet src fc00::/7 # RFC 4193 local private network range
acl localnet src fe80::/10 # RFC 4291 link-local (directly plugged) machines
#acl SSL_ports port 443
#http_access deny to_localhost
#http_access deny CONNECT !SSL_ports
http_access allow localnet
http_access allow localhost
http_access allow authenticated
via on
forwarded_for transparent

Create the users and passwords:

sudo apt-get install apache2-utils (required for htdigest)
sudo htdigest -c /etc/squid3/passwords proxy user1
sudo htdigest /etc/squid3/passwords proxy user2

Open up firewall port (if enabled):

sudo ufw allow 3128

Restart the server and tail the logs:

sudo service squid3 restart
sudo tail -f /var/log/squid3/access.log



MONITORING with Splunk…

sudo /opt/splunkforwarder/bin/splunk add monitor /var/log/squid3/access.log -index main -sourcetype Squid3
sudo /opt/splunkforwarder/bin/splunk add monitor /var/log/squid3/cache.log -index main -sourcetype Squid3


IPv6 and IPv4 for Apache Tomcat

If you’ve recently upgraded your network from IPv4 to IPv6, you might find that some software no longer works as it had before. Apache Tomcat is one that I recently stumbled upon, as it seems to prefer the IPv6 connection and stops listening on IPv4 with the default configuration.

The solution is simple, you just have to tell the server to listen on all incoming IP addresses. This worked for me with versions 7.x and 8.x, and I suspect that older and newer versions would be similar.

  1. sudo vi /opt/tomcat/conf/server.xml
  2. To each <Server> entry add:
  3. Restart Tomcat


Brotli Compression

If you look at HTTP Headers as often as I do, you’ve likely noticed something different in Firefox 44 and Chrome 49. In addition to the usual ‘gzip’, ‘deflate’ and ‘sdhc’ , a new value ‘br’ has started to appear for HTTPS connections.





Compared to gzip, Brotli claims to have significantly better (26% smaller) compression density woth comparable decompression speed.

The smaller compressed size allows for better space utilization and faster page loads. We hope that this format will be supported by major browsers in the near future, as the smaller compressed size would give additional benefits to mobile users, such as lower data transfer fees and reduced battery use.


  • Brotli outperforms gzip for typical web assets (e.g. css, html, js) by 17–25 %.
  • Brotli -11 density compared to gzip -9:
  • html (multi-language corpus): 25 % savings
  • js (alexa top 10k): 17 % savings
  • minified js (alexa top 10k): 17 % savings
  • css (alexa top 10k): 20 % savings

NOTE: Brotli is not currently supported Apache HTTPd server (as of 2016feb10), but will likely be added in an upcoming release.[email protected]%3E

Until there is native support, you can pre-compress files by following instructions here…


Upgrade Splunk server

Initially this seemed a bit problematic for me. Each time the browser client is started it (by default) checks for a new server release and prompts the user to upgrade. The installation automatically identifies the currently installed version and takes the necessary steps to migrate configuration.

Steps are similar to initial installation.

  1. Download the appropriate build for your server (i386 vs. amd64)
  2. transfer to the server via sftp or other secure means
  3. sudo /opt/splunk/bin/splunk stop
  4. sudo dpkg -i splunk*
  5. sudo /opt/splunk/bin/splunk start
  6. … accept terms… Y
  7. MIGRATE “y”
  8. http://HOSTNAME:8000
  9. sudo /opt/splunk/bin/splunk enable boot-start