Securing a Web Server Using a Linux Namespaces Sandbox

The goal of this article is to isolate a small public web server on a simulated demilitarized zone (DMZ) network, and to restrict the local network access in case the server is breached. It is an extra security layer added to an existing home server setup.

Internal DMZ network setup

Internal DMZ network setup

The DMZ consists of an internal network 10.10.20.0/24 connected to br0 bridge device. On this network I place a Linux namespaces security sandbox at 10.10.20.10, running a web server. In case an intruder gets control of the web server, he will be running with low privileges as a generic www-data user. The host firewall configuration will not allow him to open connections anywhere outside DMZ network.

Continue reading

How to Restrict a Login Shell Using Linux Namespaces

Firejail is a SUID sandbox program that reduces the risk of security breaches by restricting the running environment of untrusted applications using Linux namespaces. It allows a process and all its descendants to have their own private view of the globally shared kernel resources, such as the network stack, process table, mount table.

Started as a simple sandbox for Mozilla Firefox, Firejail was expanded to work on any type of executable, such as servers, graphic programs, and even as login shell.

The program is written in C and only needs libc and POSIX threads (libpthreads), available by default on any Linux platform. The download page provides source code (./configure && make && sudo make install), deb (dpkg -i firejail.deb) and rpm (rpm -i firejail.rpm) packages. Once installed, you can start a program in sandbox as:

$ firejail [options] program and arguments
Example:
$ firejail --debug firefox

Default sandbox

To login into a Firejail sandbox, you need to set /usr/bin/firejail as user shell in /etc/passwd. You can change the shell for an existing user with chsh command:

# chsh --shell /usr/bin/firejail

Another option is to define the shell when the user account is created:

# adduser --shell /usr/bin/firejail username

Below is a ssh login session into a sandboxed account:

SSH login into a default Firejail sandbox

SSH login into a default Firejail sandbox

Continue reading

Lightweight Debian: LXDE Desktop From Scratch Part 2

In part 1 of this article series I’ve described a minimal Debian installation using network install image. I started with a regular server, added the desktop environment, and installed some more common desktop applications. In this article I will continue with several enhancements to the previous setup. Most of the information in these articles applies to other desktop environments as well.

Continue reading

A Memory Comparison of Light Linux Desktops – Part 3

Linux kernel manages all RAM memory in your computer. Unused memory goes into a special buffering pool, where the kernel caches all recently used data. If a process attempts to read a file and the kernel already has the file cached, reading it is as fast as reading RAM.

Filesystem-heavy task, such as compiling source code, processing video files, etc. benefit from as much free memory as possible in buffering pool. It is not uncommon today to see users with powerful systems running tiling window managers in only a few megabytes of memory. Also, with the personal computer market in decline, people tend to keep their computers longer.

In this article I continue the measurements started in part 1 and part 2 of this series.

I use free command to measure memory. It basically prints out values provided by the kernel. Of interest to us is the number on -/+ buffers/cache line, 121MB in the example below:

Measuring desktop memory

Measuring desktop memory

Continue reading

Debian Virtualization: Back to the Basics, part 3

The traditional Linux security model starts with file permissions. The model lets the kernel decide whether or not a process may access a resource based on permissions set as part of the filesystem. The coarse-grained granularity of this model often causes Linux processes to have too many rights. If more granularity is needed, one has to resort to adding security related code into the program source.

This series of articles is about Linux namespaces, a lightweight virtualization technology implemented in Linux kernel. In part 1 I’ve talked about building chroot jails using mount namespace, and in part 2 I’ve looked into isolating processes using PID namespace. The next step is to isolate the TCP/IP networking stack using network namespaces.

Security at this level is always reactive. Assuming the bad guy breaks into your server, he will realize he doesn’t have root privileges (classic Unix privilege separation implemented in server software), he runs on top of a fake filesystem (chroot), and he cannot get outside on the network. The later is usually done by placing the computer in a Demilitarized Zone (DMZ) behind a firewall.

The same effect can be achieved on the cheap using Linux namespaces. For this, I place the server in a container (vm1) running its own network segment (10.10.20.0/24). The container is connected to the host through a Linux bridge interface (br0). On the host I configure iptables firewall, isolating the server and effectively limiting the potential damage that could be inflicted on the larger network. The final setup looks like this:

Network setup

Network setup

Continue reading

Debian Virtualization: Back to the Basics, part 2

Linux ptrace() system call provides a means by which one process may observe and control the execution of another process. It is primarily used to implement breakpoint debugging with gdb and system call tracing with strace. In this article I will look at the security implications of ptrace, and how to overcome them using Linux PID namespaces.

Public enemy numero uno

This is an experiment every Linux enthusiast should try. Start an ssh connection in a terminal and stop when you are just about to enter the password:

Starting an ssh session

Starting an ssh session

Open another terminal, find the pid of your ssh session (ps ax | grep ssh) and start strace on it (strace -p 3660). Then, go back to your ssh terminal, type in your password, and watch it flying across strace terminal:

ptrace usage example

ptrace usage example

Continue reading