Ruby on Rails bottom up security – web server

Reading Time: 2 minutes

TL;DR

In previous post I explained security hardening for linux server. This post will describe hardening based on server purpose.

Modern web application typically consists from following components:

  • web server
  • database server
  • job server
  • cache server

Security hardening for those servers is different.

Web server

Here are detailed instructions how to harden nginx web server.

  1. SELinux

SELinux is security kernel feature. If some component on your server is not patched, or there is Zero Day Vulnerability, SELinux will help you to protect other server components. For example, logging component has zero day vulnerability and hacker would use it to try to get access to your web server. SELinux adds additional level of kernel security to make that attack much harder.

2. Allow Minimal Privileges Via Mount Options

This is applied to partition that holds your web application files.

nosuid means that it will be not possible to change user and group permissions for that partition

noexec it will be not possible to run any program from that partition

nodev means do not interpret character or block special devices on
the file system

One of hacker attack vector is to serve his own malicious program using your web application. Those settings will make his attack much harder.

3. Linux /etc/sysctl.conf Hardening

These are low level linux networking and kernel parameters. First attack vector is try to login remotely to your server. These settings will make that job much harder.

4. Remove All Unwanted Nginx Modules

You need to run your nginx with modules that you need. Otherwise, your attack vector surface becomes larger.

nginx -V

will list current nginx modules. Here are instructions how to configure modules.

5. Change Nginx Version Header

This basically makes your nginx server more hidden. It will make hacker job much harder.

server_tokens off

How to change Server header. For centOS use

yum install

6. Install SELinux Policy To Harden The Nginx Webserver

These are selinux policies that will make your web server more secure.

7. Controlling Buffer Overflow Attacks

Buffer overflow attack is one of the first attack that will hacker try. There are special tools that help them (like Metasploit) to automate that attack. Basically, hacer will try to feed more data to web server connection. Setting explicit boundary values, you will make that task much harder. But be aware that those boundaries could influence your web application operations.

8. Control Simultaneous Connections

Set maximal number of simultaneous connections from same IP address. This will help you to fight web spiders and ddos attacks.

10. Limit Available Methods

You probably know about HTTP GET and POST methods, but do you know about OPTIONS? Restrict HTTP methods that are not used by your web application.

11. Nginx SSL Configuration

You need to run on SSL. For that you will need to buy signed ssl certificate.

12. Firewall

Your web server needs to be behind dedicated firewall appliance. Period.

That it is, security hardening for web server. In next post, I will talk about hardening for database server.

Facebooktwittergoogle_plusredditpinterestlinkedinmailby feather

Ruby on Rails bottom up security – hardening the servers

Reading Time: 3 minutes

TL;DR

Next series of blog posts is about Ruby on Rails bottom up security. I will cover all aspects of web application written in Ruby on Rails framework. Described security concepts could be applied to any other modern web framework because we will describe which security problem particular concept resolves. I will start with hardening the server that runs the web application.

You probably think that hardening (reducing the surface of vulnerability) the server is impossible task. But I will prove you wrong. I found this excellent blog post that is foundation for hardening the server.

It has all instructions for Ubuntu linux how to harden the server. And you could be done with this task in 5 minutes!

Precondition is that server is up and running, and you know root password. You should first login as root.

  1. Select linux distribution

As you probably know, there are various linux distributions. I suggest latest CentOS for two reasons:

  1. it has excellent database about security patches
  2. it is tailored for servers that run server side services (e.g. web application)

2. Change root password

Unix command is

passwd

Tip. We suggest that you use LastPass password manager for creating and storing that password.

2. Update the system

You want to have latest software version as starting point.

yum -y -d 0 -e 0 update yum
yum -y -e 0 -d 0 update

3. Install fail2ban

yum install fail2ban

fail2ban is daemon written in Python that monitors suspicious activities and if detected, automatically bans client ip addresses for some time.

4. create new user

useradd deploy

mkdir /home/deploy

mkdir /home/deploy/.ssh

chmod 700 /home/deploy/.ssh

You will use only that user to connect to your server! Never use root user for establishing ssh connection. Note important command, chmod and number 700. At first, this look very cryptic. Read this for more info, and for now, remember that 700 gives all access ONLY to deploy user to .ssh folder (1+2+4 = 7).

5. ssh using public/private key authentication

In order to connect to your server, you will use ssh without password. How to set up that type of access? I recommend github tutorial:

Check for existing ssh keys is not needed, since you have new fresh server.

Generate new ssh key pair. You should set up password phrase (which is by default optional). Also, add private key  to ssh agent, so you will not need to enter password phrase. Be sure to store password phrase to lastpass!

Test your ssh connection.

Add your public key to the server. Previous link contains instructions how to copy your public key. The you have to paste it:

vim /home/deploy/.ssh/authorized_keys

Save file and run:

chmod 400 /home/deploy/.ssh/authorized_keys chown deploy:deploy /home/deploy -R

Mode 400 is read only. This is highest security, and without that mode, you will get cryptic error when you will try to establish ssh connection.

6. Test The New User

Keep existing terminal open, and from new terminal type:

ssh deploy@server_ip_address

7. Enable sudo

In your first terminal as root, first set deploy user password:

passwd deploy

Save deploy user password in LastPass!

visudo

You are now in vi editor. Comment all lines and add at the bottom:

root ALL=(ALL) ALL

deploy ALL=(ALL) ALL

That means when you will run sudo as deploy user, you WILL BE ASKED TO ENTER PASSWORD!

8. Lock Down SSH

Via ssh, you will not be able to:

  • connect as as root user
  • connect using password
  • connect from any client, but only from clients that you will list in setting.
vim /etc/ssh/sshd_config

Enter this, and be sure that original entries ARE DELETED:

PermitRootLogin no
PasswordAuthentication no
AllowUsers deploy@(your-ip) deploy@(another-ip-if-any)
systemctl sshd restart

9. What about firewall ?

I strongly do not recommend that your server is directly exposed to the Internet. It must be BEHIND dedicated FIREWALL. Ask your IAAS provider about details.

10. Enable Automatic Security Updates

This should be set, at least for security update. Set it in cron to run automatically on daily basis.

vi /etc/cron.daily/yumupdate.sh

#!/bin/bash
 YUM=/usr/bin/yum
 $YUM -y -d 0 -e 0 update yum
 $YUM -y -e 0 -d 0 update

11. Install Logwatch To Keep An Eye On Things

Logwatch is tool that automatically monitors server logs and its logs can give you a hint about server intrusion.

yum install logwatch

vi /etc/cron.daily/logwatch_daily.sh

/usr/sbin/logwatch --output mail --mailto test@gmail.com --detail high

You are done with basic server hardening. In next post, I will explain how to harden servers based on their purpose. Web server, database server, cache server, job server have a slightly different security configuration.

Facebooktwittergoogle_plusredditpinterestlinkedinmailby feather

What I learned at Testival #30: learning by playing card games

Reading Time: 2 minutes

TL;DR

This post is about hands on session for learning about software testing using card games.

Intro

At TestBash Brighton2017, on Friday conference day, during the Lean Coffee, one lady ask question that you have probably already heard: “How should I motivate my team of testers?”

I suggested card games. Another participant immediately dismissed me: “I DO NOT LIKE GAMES IN SOFTWARE TESTING BECAUSE THIS IS NOT PROFESSIONAL!”

Noticed that this was his subjective opinion and he did not provide any arguments why is this bad idea. Well dear fellow software tester, this blog post is to prove you wrong.

Introductions

As usually, we started with 2-5 minute introductions. Every tester must be good at explaining things, so this is good way to practice that craft. We had new participants, 3 of them international. Meetup .com is powerful platform.

In this video extract, Priamo explains one concept from excellent book: “The design of everyday things

TestSphere by Ministry of testing

TestSphere is deck of cards about testing concepts, 100 cards divided in 5 dimensions:

  • Heuristics: Possible ways of tackling a problem.
  • Techniques: Clever activities we use in our testing to find possible problems.
  • Feelings: Every feeling that was triggered by your testing should be handled as a fact.
  • Quality Aspects: Possible aspects of your application that may be of interest.
  • Patterns: Patterns in our testing, but also patterns that work against us, while testing such as Biases.

My point of view is that TestSpehere cards can be used for:

  • test plan
  • interview tester
  • share learning

TestSpehere also represents coverage of knowledge that skilfull tester must have. We randomly picked up green cards which represent technique. Each card has:

  • name
  • product level – hint how you should apply this card
  • three examples to seed idea flow

And magic happened! I handed a card to each participant and everybody had something to say about it. Which means we have the knowledge for software testing techniques, and TestShere cards helped us to structure that knowledge.

FluXX

FluXX is card game where rules and goals could be changed on every hand play. You have seven card types:

  • basic rule – draw one, play one. Game initial state
  • new rule – adds rule and removes existing rules if contradicts with them

Hmmm. Are those two rules contradict each other?

  • Goal card – how to win instruction
  • Creeper helps you to lose
  • Keeper helps you to win
  • Action – do something
  • Surprise

Note: play and discard card are two different actions!

How to play? Have one experience player and just play. Start from basic rule, everything else is written on cards (requirements!), but, you will have to think in order to apply them.

Fluxx helps you to practice all types of thinking in fast changing environment.

Game of Set

Helps you to practice multidimensional pattern recognition.

You have four properties: shape, quantity, filling and colour. Each property could have three values. Rule is very simple: you have 12 cards on a table, cards make a set of three if each of four properties are same OR different.

During gameplay I noticed that players usually forgot about one dimension, or they do not take into account that properties could also be DIFFERENT.

Have you ever tested something that has more than four dimensions? Our brain has system one and system two (more about that in Michael Bolton’s Critical thinking for testers.), you need to give system two time to wake up!

Facebooktwittergoogle_plusredditpinterestlinkedinmailby feather

Be careful with your testing tools

Reading Time: 2 minutes

TL;DR

In this post I will describe how I got different test results using two testing tools Bug Magnet and Counter strings.

Bug Magnet is handy Chrome Extension developed by Gojko Adzic.

It is: “Convenient access to common boundaries and edge cases for exploratory testing.

Counterstings is implementation of James Bach algorithm that quickly reveals character position in string.

In my test, I used them to check maximal number of allowed characters in input form. This test should be simple, right?

One interesting thing happened. I first used Bug Magnet and inserted string with 128 characters. String was accepted and test failed because maximal allowed number should be 64 characters. I did second test with counterstrings. Boundary of 64 characters was successfully detected. What!?

What happened?

For me, any test should provoke sapient thinking process. In modern web applications, input form could be implemented in two ways:

  • html 5 standard, where all input constraint checks are done by browser code according to that standard

You can recognize this by inspecting input text box (Chrome developer tools) and if you see something like this:

<form action="/action_page.php">
  Username: <input type="text" name="usrname" maxlength="10"><br>
  <input type="submit" value="Submit">
</form>

then input textbox is implemented in pure html5.

  • using one of popular javascript frameworks (Angular for example, and that was the case with application that I was testing).

Then there is javascript code triggered on keyboard typing action. That code usually manipulates DOM tree to create better looking results.

Application created using modern javascript framework.

Bug Magnet is implemented in javascript, and it manipulates DOM tree in order to insert the test data. Be careful, because application user does not do that. Application user types directly into input box. Doing that manipulation, Bug Magnet managed to avoid string length check.

Counterstring uses Ruby on Rails code to generate counterstring on server side. It uses javascript to copy/paste counterstring to user clipboard. My input was done with copy/paste, something more closer to application user.

Facebooktwittergoogle_plusredditpinterestlinkedinmailby feather