A Deep Dive into Iptables and Netfilter Architecture

Introduction

Firewalls are an important tool that can be configured to protect your servers and infrastructure. In the Linux ecosystem, iptables is a widely used firewall tool that interfaces with the kernel’s netfilter packet filtering framework. For users and administrators who don’t understand the architecture of these systems, creating reliable firewall policies can be daunting, not only due to challenging syntax, but also because of number of interrelated parts present in the framework.

In this guide, we will dive into the iptables architecture with the aim of making it more comprehensible for users who need to build their own firewall policies. We will discuss how iptables interacts with netfilter and how the various components fit together to provide a comprehensive filtering and mangling system.

 

What Are IPTables and Netfilter?

The basic firewall software most commonly used in Linux is called iptables. The iptables firewall works by interacting with the packet filtering hooks in the Linux kernel’s networking stack. These kernel hooks are known as the netfilter framework.

Every packet that enters networking system (incoming or outgoing) will trigger these hooks as it progresses through the stack, allowing programs that register with these hooks to interact with the traffic at key points. The kernel modules associated with iptables register at these hooks in order to ensure that the traffic conforms to the conditions laid out by the firewall rules.

 

Netfilter Hooks

There are five netfilter hooks that programs can register with. As packets progress through the stack, they will trigger the kernel modules that have registered with these hooks. The hooks that a packet will trigger depends on whether the packet is incoming or outgoing, the packet’s destination, and whether the packet was dropped or rejected at a previous point.

The following hooks represent various well-defined points in the networking stack:

  • NF_IP_PRE_ROUTING: This hook will be triggered by any incoming traffic very soon after entering the network stack. This hook is processed before any routing decisions have been made regarding where to send the packet.
  • NF_IP_LOCAL_IN: This hook is triggered after an incoming packet has been routed if the packet is destined for the local system.
  • NF_IP_FORWARD: This hook is triggered after an incoming packet has been routed if the packet is to be forwarded to another host.
  • NF_IP_LOCAL_OUT: This hook is triggered by any locally created outbound traffic as soon it hits the network stack.
  • NF_IP_POST_ROUTING: This hook is triggered by any outgoing or forwarded traffic after routing has taken place and just before being put out on the wire.

Kernel modules that wish to register at these hooks must provide a priority number to help determine the order in which they will be called when the hook is triggered. This provides the means for multiple modules (or multiple instances of the same module) to be connected to each of the hooks with deterministic ordering. Each module will be called in turn and will return a decision to the netfilter framework after processing that indicates what should be done with the packet.

 

IPTables Tables and Chains

The iptables firewall uses tables to organize its rules. These tables classify rules according to the type of decisions they are used to make. For instance, if a rule deals with network address translation, it will be put into the nat table. If the rule is used to decide whether to allow the packet to continue to its destination, it would probably be added to the filter table.

Within each iptables table, rules are further organized within separate « chains ». While tables are defined by the general aim of the rules they hold, the built-in chains represent the netfilter hooks which trigger them. Chains basically determine when rules will be evaluated.

As you can see, the names of the built-in chains mirror the names of the netfilter hooks they are associated with:

  • PREROUTING: Triggered by the NF_IP_PRE_ROUTING hook.
  • INPUT: Triggered by the NF_IP_LOCAL_IN hook.
  • FORWARD: Triggered by the NF_IP_FORWARD hook.
  • OUTPUT: Triggered by the NF_IP_LOCAL_OUT hook.
  • POSTROUTING: Triggered by the NF_IP_POST_ROUTING hook.

Chains allow the administrator to control where in a packet’s delivery path a rule will be evaluated. Since each table has multiple chains, a table’s influence can be exerted at multiple points in processing. Because certain types of decisions only make sense at certain points in the network stack, every table will not have a chain registered with each kernel hook.

There are only five netfilter kernel hooks, so chains from multiple tables are registered at each of the hooks. For instance, three tables have PREROUTING chains. When these chains register at the associated NF_IP_PRE_ROUTING hook, they specify a priority that dictates what order each table’s PREROUTING chain is called. Each of the rules inside the highest priority PREROUTING chain is evaluated sequentially before moving onto the next PREROUTING chain. We will take a look at the specific order of each chain in a moment.
Lire la suite…

How To Secure Nginx with Let’s Encrypt on Ubuntu 14.04

25/10/2026 Categories: Sécurité, Système Tags: , Aucun commentaire

Introduction

nginx lets encrypt ubuntuLet’s Encrypt is a new Certificate Authority (CA) that provides an easy way to obtain and install free TLS/SSL certificates, thereby enabling encrypted HTTPS on web servers. It simplifies the process by providing a software client, letsencrypt, that attempts to automate most (if not all) of the required steps. Currently, as Let’s Encrypt is still in open beta, the entire process of obtaining and installing a certificate is fully automated only on Apache web servers. However, Let’s Encrypt can be used to easily obtain a free SSL certificate, which can be installed manually, regardless of your choice of web server software.

In this tutorial, we will show you how to use Let’s Encrypt to obtain a free SSL certificate and use it with Nginx on Ubuntu 14.04. We will also show you how to automatically renew your SSL certificate. If you’re running a different web server, simply follow your web server’s documentation to learn how to use the certificate with your setup.

Nginx with Let's Encrypt TLS/SSL Certificate and Auto-renewal

 

Prerequisites

Before following this tutorial, you’ll need a few things.

You should have an Ubuntu 14.04 server with a non-root user who has sudo privileges. You can learn how to set up such a user account by following steps 1-3 in our initial server setup for Ubuntu 14.04 tutorial.

You must own or control the registered domain name that you wish to use the certificate with. If you do not already have a registered domain name, you may register one with one of the many domain name registrars out there (e.g. Namecheap, GoDaddy, etc.).

If you haven’t already, be sure to create an A Record that points your domain to the public IP address of your server. This is required because of how Let’s Encrypt validates that you own the domain it is issuing a certificate for. For example, if you want to obtain a certificate for example.com, that domain must resolve to your server for the validation process to work. Our setup will use example.com and www.example.com as the domain names, so both DNS records are required.

Once you have all of the prerequisites out of the way, let’s move on to installing the Let’s Encrypt client software.

 

Step 1 — Install Let’s Encrypt Client

The first step to using Let’s Encrypt to obtain an SSL certificate is to install the letsencrypt software on your server. Currently, the best way to install Let’s Encrypt is to simply clone it from the official GitHub repository. In the future, it will likely be available via a package manager.

Install Git and bc

Let’s install Git and bc now, so we can clone the Let’s Encrypt repository.

Update your server’s package manager with this command:

sudo apt-get update

Then install the git and bc packages with apt-get:

sudo apt-get -y install git bc

With git and bc installed, we can easily download letsencrypt by cloning the repository from GitHub.

Clone Let’s Encrypt

We can now clone the Let’s Encrypt repository in /opt with this command:

sudo git clone https://github.com/letsencrypt/letsencrypt /opt/letsencrypt

You should now have a copy of the letsencrypt repository in the /opt/letsencrypt directory.
Lire la suite…

Categories: Sécurité, Système Tags: ,

Track Multiple Files Simultaneously With MultiTail

24/10/2026 Categories: Système Tags: , , Aucun commentaire

https://www.dbsysnet.com/wp-content/uploads/2016/06/multitail-gnome-terminal.pngThe tail utility is one of the most useful tools an admin has — but it’s also a bit limited and dated. For watching two or more logs at once, and much more, you want MultiTail.

The tail utility is one of the most useful admin tools, but it’s limited and outdated. Bring your log-watching capabilities into the 21st century and view multiple logs at one time with MultiTail.

What’s MultiTail? It’s an ncurses utility that can display multiple files using « windows » (much like GNU Screen or Tmux) in a terminal or at the console. It also supports color highlighting, filtering and much more.

To get MultiTail, head over to the download page or see if your operating system already has packages. On Debian-based systems, you should need to look for only the multitail package. The project released an update (5.2.8) on April 14, so the most recent release probably won’t be in your upstream package repo just yet.

Once it’s installed, run multitail and hit F1. It will pop up a help menu with all of its keybindings. You’ll need to scroll down (use the down arrow key) to see all of the commands. It can be deceptive, otherwise, and it looks like you just have a few commands. Let’s look at a couple of the commands you’ll want to start with.

First, run t — this displays the stats for your instance of MultiTail. To add files, use the a command.

If you want to start multitail with a file or output of a command to access, use multitailfilename or multitail filename1 filename2 for more than one file. Use multitail -R 3 -l "command" -R 3 -l "command2" to see two commands displayed in one window.

Using the h command within MultiTail, you can set the height of each window. If you want to search through a window, use / or shift / to highlight the search string. Using I will toggle case sensitivity.

When you’ve used the search feature, you’ll get a buffer that displays in a « window » above the file. You can write this to a file using s, which will bring up a dialog that prompts for a filename to which to save.

If you get a MultiTail session configured just right you can save it for later using w from within the session. It will prompt you for a filename to which to save the script.

Basically, you can do just about anything you’d be able to do with tail and then some. It’s very interactive, and much of its commands have dialogs that will walk you through creating regular expressions or re-arranging windows and more.

The only caveat I have is that, occasionally, MultiTail is a bit crashy. Not wholly unreliable, but I have managed to crash MultiTail a few times while putting it through its paces. (I’ve never managed to crashtail…). But it’s still an invaluable tool to have around for any Linux or UNIX admin.

Joe ‘Zonker’ Brockmeier is a freelance writer and editor with more than 10 years covering IT. Formerly the openSUSE Community Manager for Novell, Brockmeier has written for Linux Magazine, Sys Admin, Linux Pro Magazine, IBM developerWorks, Linux.com, CIO.com, Linux Weekly News, ZDNet, and many other publications. You can reach Zonker at [email protected] and follow him on Twitter.

Source: ServerWatch

Categories: Système Tags: , ,

What is a Distributed Firewall?

24/10/2026 Categories: Logiciel, Réseau Tags: Aucun commentaire

In the post “What is Network Virtualization?” I described a model where the application’s complete L2-L7 virtual network is decoupled from hardware and moved into a software abstraction layer for the express purpose of automation and business agility. In this post I’ll focus on network security, and describe an imminent firewall form factor enabled by Network Virtualization — the Distributed Firewall.

ALL YOUR PACKET ARE BELONG TO US

If InfoSec ruled the world … well, OK, maybe not the world … if InfoSec ruled the data center network design, and if money was no object, we would probably have something like this. Every server in the data center directly connected to its own port on one massive firewall. Every packet sent from every server would be inspected against a stateful security policy before going anywhere. And every packet received by every server would pass one final policy check before hitting the server’s NIC receive buffer. The firewall wouldn’t care about the IP address of the servers, for the simple reason that it’s directly connected to every server. E.g. “The server on this port can talk to the server on that port, on TCP port X”. And if that wasn’t good enough, the firewall knows everything about the servers connected to it, and can create rules around a rich set of semantics. All of this with no performance penalty. That would be awesome, right?

Let’s pretend money was not the issue. How would you design this massive omnipresent data center firewall? I can think of three ways off hand.

  1. You design a monstrous power sucking stateful firewall chassis with thousands of line-rate ports. At this point it’s time to route a ghastly mess of cables from every server to this centralized mega firewall core chassis – but that’s somebody else’s problem. Oh, and don’t forget you’ll need two of those bad boys for “redundancy”. Your monster firewall is pretty freaking awesome at security, but only so-so at basic L2 and L3 networking. But so what — the network team can learn to like it or find a new job. And if you run out of ports … no worries; just wait another few years for a bigger chassis and do the rip/replace routine.
  2. You design a line rate stateful firewall ToR switch. Rip out the network team’s favorite ToR and put this one in its place. Tell them to stop throwing a fit and just deal with it. You’ll have hundreds of these ToR firewalls to manage and configure consistently. No problem … just let the network team re-apply for their jobs as firewall engineers.

Go ahead and pinch yourself now. This is nothing but a fantasy nightmare.

The interests of security often poorly translate into networking. Comprehensive security ~= Compromisednetworking.

What about design #3? More on that in a minute. (Hint: title of the post)

In the real world, rest assured we do have firewalls to provide some security. But this security is not ubiquitous, nor is it assured. Instead, we have firewalls (physical or virtual) hanging off the network somewhere catching steered packets – and we can only hope the network was configured correctly to steer the right traffic to the right policy.

In this post we’ll briefly review the physical and virtual firewall, followed by a discussion on the Distributed Firewall.

Lire la suite…

Categories: Logiciel, Réseau Tags:

/etc/hosts vs. /etc/resolv.conf

23/10/2026 Categories: Réseau, Système Tags: Comments off

From Wikipedia:

resolv.conf is the name of a computer file used in various operating systems to configure the system’s Domain Name System (DNS) resolver. The file is a plain-text file usually created by the network administrator or by applications that manage the configuration tasks of the system. The resolvconf program is one such program on FreeBSD or other Unix machines which manages the resolv.conf file.

When an application performs DNS lookup as part of its operations on Linux, it can leverage both /etc/hosts and /etc/resolv.conf configuration files to resolve DNS names. How these configuration files are used for DNS lookup can vary among different applications, complicating system administration. But Linux libc library and the GNU C Library (glibc) provides a clean solution to this problem, by defining DNS lookup orders with Name Service Switch (NSS). NSS defines a set of databases and their lookup order in NSS configuration file (/etc/nsswitch.conf in Linux). Applications built with those libraries will then perform DNS lookups in a consistent manner.

In /etc/nsswitch.conf, the database for DNS lookup is called « hosts« . For example:

$ cat /etc/nsswitch.conf | grep "hosts"
hosts: files dns

The above means that DNS lookup refers to /etc/hosts first, and then DNS servers specified in /etc/resolv.conf

gethostbyname() in glibc will follow the DNS lookup order specified in /etc/nsswitch.conf. So do other programs like wget and curl.

Note that DNS lookup tools such as nslookup/dig which are made to query DNS servers, will ignore /etc/nsswitch.conf, and always refer to DNS servers in /etc/resolv.conf

Source: Xmodulo

Categories: Réseau, Système Tags: