Firewall in linux kernel

Firewall in linux kernel

Каждый уважающий себя администратор Linux должен уметь не только настраивать iptables, но и знать, как он работает. В этой статье речь пойдет не о том, как правильно настраивать iptables или какой-нибудь другой firewall, а о том, как работают firewall’ы в Linux.

В первую очередь, эта статья нацелена на читателей, которые занимаются (начинают или только хотят начать) программированием модулей ядра Linux (Linux Kernel Module – LKM), а также, надеюсь, поможет некоторым администраторам более детально разобраться в работе iptables. Все примеры в статье написаны для ядра 2.6.12.

Netfilter Hacking

Что такое netfilter и какое отношение он имеет к firewall’ам? В основном, Netfilter представляет собой набор функций (hook) расположенных в ядре, при помощи которых firewall’ы могут получать доступ к пакетам и, основываясь на правилах, решать, как с ними поступать дальше. Netfilter содержит 5 основных hook-функций, которые описаны в linux/netfilter_ipv4.h. Графически их можно изобразить так:

[1] NF_IP_PRE_ROUTING – наша функция срабатывает, как только мы получаем пакет, даже если он проходящий. Если мы хотим иметь доступ ко всем пакетам, проходящим через наш интерфейс, то мы должны использовать эту функцию.
[2] NF_IP_LOCAL_IN – срабатывает в случае, когда пакет адресован нам, перед поступлением его в сетевой стек.
[3] NF_IP_FORWARD – если пакет необходимо смаршрутизировать с одного интерфейса на другой.
[4] NF_IP_POST_ROUTING – для исходящих пакетов из нашего сетевого стека.
[5] NF_IP_LOCAL_OUT – для всех исходящих пакетов.

После вызова функции и проведения нехитрых проверок над пакетом, нам нужно вынести вердикт, что делать с этим пакетом дальше. В нашем распоряжении 5 вариантов:

[1] NF_ACCEPT – пропускает пакет дальше.
[2] NF_DROP – отбрасывает пакет.
[3] NF_REPEAT – повторный вызов функции.
[4] NF_STOLEN – забирает пакет (прекращается передвижение).
[5] NF_QUEUE – ставит пакет в очередь, как правило, для передачи в пользовательское пространство (мы ведь работаем в пространстве ядра).

Вот собственно и все, что нужно для нормальной работы любого firewall’а в Linux. С одной стороны, набор функций, позволяющий получать доступ к пакетам практически в любой точке сетевого стека, а с другой, набор решений, как поступить с пакетом дальше.

Теперь попытаемся разобраться, как все это работает! Первым делом нам нужно познакомиться со структурой nf_hook_ops, она и будет нашим проводником в мир netfilter’a. Описание её можно найти в /Linux/netfilter.h:

Первое что мы видим, это “struct list_head list” – это структура, которая содержит список всех hook-функций, но нас она не сильно интересует.
nf_hookfn *hook – указатель на нашу функцию, в которой мы будем проводить все наши проверки. Возвращаемое значение должно быть одно из 5-и поведений (NF_ACCEPT, NF_DROP, . ).
int pf – служит для определения протокола, с которым мы хотим работать (PF_INET)
int hooknum – а вот и место нашего вызова. (например NF_IP_PRE_ROUTING)
int priority – приоритет. В случае если определено несколько функций на один вызов, первым сработает тот, у кого выше приоритет. Мы будем использовать – NF_IP_PRI_FIRST.

Не поверите, но это все! Остается лишь маленькое дополнение. После того как мы объявим и заполним нашу структуру, её необходимо зарегистрировать. Для этого служат 2-е функции, которые объявлены все в том же /Linux/netfilter.h:

Первая из них — это nf_register_hook, служит для регистрации нашей hook-функции. А nf_unregister_hook – для удаления нашей функции из цепочки.

Ничего особенного, просто банальное предупреждение. Обязательно выгружайте ваши функции при выгрузке модуля из памяти при помощи nf_unregister_hook. Если этого не сделать, произойдет очень неприятная вещь. Придет пакет, сработает наш вызов, ядро попытается обратиться к странице памяти для вызова нашей функции для обработки, а там…. эээ в лучшем случае ничего, в худшем ..кто-то занял наше место и тогда результат буде непредсказуем.

Firewall своими руками

Для примера напишем маленький firewall. Который будет беспощадно уничтожать все входящие и исходящие пакеты.

Ну вот. Все очень просто! Теперь компилируем наш модуль, для этого я пользуюсь вот таким Makefile’ом: (предположим, что исходный код сохраним с именем firewall.c, а исходники ядра находится в папке /usr/src/linux).

И запускаем: insmod firewall.ko (иногда приходится запускать с ключом -f: insmod -f firewall.ko, а то ему версии не нравятся, но кому не лень, можно в модуле прописать все данные о версии ядра :). Посмотрите /var/log/messages – если увидите «FireWall loaded», значит наш модуль загрузился. Теперь, если вы попробуете подключиться к кому-нибудь, или наоборот, кто-то захочет к вам подключиться, ничего не выйдет. Наш модуль не пропустит ни одного пакета. Чтобы вернуть все на место, просто выгрузите модуль командой rmmod firewall.

Вот пример firewall’a в 60 строк, включая заголовки. Не сложно, правда. 🙂 Теперь перейдем к более сложным вещам. Но совсем на чуть-чуть.

Пример norm.c

В этом примере мы будем проводить небольшой анализ захваченного нами пакета. Наша программа будет анализировать заголовки пакета и в случае неудовлетворения правилам будет удалять его или править. Итак, для начала, небольшое введение в структуру sk_buff:

sk_buff – это буфер для работы с пакетами. Как только приходит пакет или появляется необходимость его отправить, создается sk_buff куда и помещается пакет, а также сопутствующая информация, откуда, куда, для чего… На протяжении всего путешествия пакета в сетевом стеке используется sk_buff. Как только пакет отправлен или данные переданы пользователю, структура уничтожается, тем самым освобождая память. Описание этой структуры можно найти в linux/skbuff.h. Она очень большая, я не буду выкладывать её сюда 🙂 Все, что мы будем использовать из неё, это:

Protocol – чтобы знать, с каким протоколом сетевого уровня мы имеем дело.
Data – место, где лежит пакет.

Более подробно о работе sk_buff можно почитать в Интернете, информации о нем море, а что касается практической части, советую почитать статью «Building Into The Linux Network Layer» из phrack №55

Ну вроде все, с теорией маленько разобрались. Теперь определимся, что и как мы будем делать. Так как это лишь пример использования, я не буду заострять внимание над нормализацией конкретного протокола, просто пробежимся немного по протоколам и все:

Источник

Simple stateful firewall

This page explains how to set up a stateful firewall using iptables. It also explains what the rules mean and why they are needed. For simplicity, it is split into two major sections. The first section deals with a firewall for a single machine, the second sets up a NAT gateway in addition to the firewall from the first section.

Contents

Prerequisites

First, install the userland utilities iptables or verify that they are already installed.

This article assumes that there are currently no iptables rules set. To check the current ruleset and verify that there are currently no rules run the following:

If there are rules, you may be able to reset the rules by loading a default rule set:

Firewall for a single machine

Creating necessary chains

For this basic setup, we will create two user-defined chains that we will use to open up ports in the firewall.

The chains can of course have arbitrary names. We pick these just to match the protocols we want handle with them in the later rules, which are specified with the protocol options, e.g. -p tcp , always.

The FORWARD chain

If you want to set up your machine as a NAT gateway, please look at #Setting up a NAT gateway. For a single machine, however, we simply set the policy of the FORWARD chain to DROP and move on:

The OUTPUT chain

The OUTPUT chain can be a powerful tool for filtering outbound traffic, especially for servers and other devices which do not run web browsers or peer-to-peer tools that need to connect to arbitrary destinations on the internet. However, properly setting up an OUTPUT chain requires information about the intended use of the system. A secure set of rules for a desktop system, laptop system, cloud server and home/on-prem server would all be very different.

In this simple example, we will allow all outbound traffic by setting the default policy for the OUTPUT chain to ACCEPT. This is less secure, but is highly compatible with many systems.

The INPUT chain

Similar to the previous chains, we set the default policy for the INPUT chain to DROP in case something somehow slips by our rules. Dropping all traffic and specifying what is allowed is the best way to make a secure firewall.

Every packet that is received by any network interface will pass the INPUT chain first, if it is destined for this machine. In this chain, we make sure that only the packets that we want are accepted.

The first rule added to the INPUT chain will allow traffic that belongs to established connections, or new valid traffic that is related to these connections such as ICMP errors, or echo replies (the packets a host returns when pinged). ICMP stands for Internet Control Message Protocol. Some ICMP messages are very important and help to manage congestion and MTU, and are accepted by this rule:

The connection state ESTABLISHED implies that either another rule previously allowed the initial ( —ctstate NEW ) connection attempt or the connection was already active (for example an active remote SSH connection).

The second rule will accept all traffic from the «loopback» (lo) interface, which is necessary for many applications and services.

The third rule will drop all traffic with an «INVALID» state match. Traffic can fall into four «state» categories: NEW, ESTABLISHED, RELATED or INVALID and this is what makes this a «stateful» firewall rather than a less secure «stateless» one. States are tracked using the «nf_conntrack_*» kernel modules which are loaded automatically by the kernel as you add rules.

The next rule will accept all new incoming ICMP echo requests, also known as pings. Only the first packet will count as NEW, the others will be handled by the RELATED, ESTABLISHED rule. Since the computer is not a router, no other ICMP traffic with state NEW needs to be allowed.

Now we attach the TCP and UDP chains to the INPUT chain to handle all new incoming connections. Once a connection is accepted by either TCP or UDP chain, it is handled by the RELATED/ESTABLISHED traffic rule. The TCP and UDP chains will either accept new incoming connections, or politely reject them. New TCP connections must be started with SYN packets.

We reject TCP connections with TCP RESET packets and UDP streams with ICMP port unreachable messages if the ports are not opened. This imitates default Linux behavior (RFC compliant), and it allows the sender to quickly close the connection and clean up.

For other protocols, we add a final rule to the INPUT chain to reject all remaining incoming traffic with icmp protocol unreachable messages. This imitates Linux’s default behavior.

Resulting iptables.rules file

Example of iptables.rules file after running all the commands from above:

This file can be generated and saved with:

and can be used to continue with the following sections. If you are setting up the firewall remotely via SSH, append the following rule to allow new SSH connections before continuing (adjust port as required):

The TCP and UDP chains

The TCP and UDP chains contain rules for accepting new incoming TCP connections and UDP streams to specific ports.

Opening ports to incoming connections

To accept incoming TCP connections on port 80 for a web server:

To accept incoming TCP connections on port 443 for a web server (HTTPS):

To allow remote SSH connections (on port 22):

To accept incoming TCP/UDP requests for a DNS server (port 53):

See iptables(8) for more advanced rules, like matching multiple ports.

Port knocking

Port knocking is a method to externally open ports that, by default, the firewall keeps closed. It works by requiring connection attempts to a series of predefined closed ports. When the correct sequence of port «knocks» (connection attempts) is received, the firewall opens certain port(s) to allow a connection. See Port knocking for more information.

Protection against spoofing attacks

Blocking reserved local addresses incoming from the internet or local network is normally done through setting rp_filter (Reverse Path Filter) in sysctl to 1. To do so, add the following line to your /etc/sysctl.d/90-firewall.conf file (see sysctl for details) to enable source address verification which is built into Linux kernel itself. The verification by the kernel will handle spoofing better than individual iptables rules for each case.

This can be done with netfilter instead if statistics (and better logging) are desired:

For niche setups where asynchronous routing is used, the rp_filter=2 sysctl option needs to be used instead. Passing the —loose switch to the rpfilter module will accomplish the same thing with netfilter.

«Hide» your computer

If you are running a desktop machine, it might be a good idea to block some incoming requests.

Block ping request

A ‘Ping’ request is an ICMP packet sent to the destination address to ensure connectivity between the devices. If your network works well, you can safely block all ping requests. It is important to note that this does not actually hide your computer — any packet sent to you is rejected, so you will still show up in a simple nmap «ping scan» of an IP range.

This is rudimentary «protection» and makes life difficult when debugging issues in the future. This should only be done for educational purposes.

To block echo requests, add the following line to your /etc/sysctl.d/90-firewall.conf file (see sysctl for details):

More information is in the iptables man page, or reading the docs and examples on the webpage http://www.snowman.net/projects/ipt_recent/

Tricking port scanners

Port scans are used by attackers to identify open ports on your computer. This allows them to identify and fingerprint your running services and possibly launch exploits against them.

The INVALID state rule will take care of every type of port scan except UDP, ACK and SYN scans (-sU, -sA and -sS in nmap respectively).

ACK scans are not used to identify open ports, but to identify ports filtered by a firewall. Due to the SYN check for all TCP connections with the state NEW, every single packet sent by an ACK scan will be correctly rejected by a TCP RESET packet. Some firewalls drop these packets instead, and this allows an attacker to map out the firewall rules.

The recent module can be used to trick the remaining two types of port scans. The recent module is used to add hosts to a «recent» list which can be used to fingerprint and stop certain types of attacks. Current recent lists can be viewed in /proc/net/xt_recent/ .

SYN scans

In a SYN scan, the port scanner sends a SYN (synchronization) packet to every port to initiate a TCP connection. Closed ports return a TCP RESET packet, or get dropped by a strict firewall, while open ports return a SYN ACK packet.

The recent module can be used to keep track of hosts with rejected connection attempts and return a TCP RESET for any SYN packet they send to open ports as if the port was closed. If an open port is the first to be scanned, a SYN ACK will still be returned, so running applications such as ssh on non-standard ports is required for this to work consistently.

First, insert a rule at the top of the TCP chain. This rule responds with a TCP RESET to any host that got onto the TCP-PORTSCAN list in the past sixty seconds. The —update switch causes the recent list to be updated, meaning the 60 second counter is reset.

Next, the rule for rejecting TCP packets need to be modified to add hosts with rejected packets to the TCP-PORTSCAN list.

UDP scans

UDP port scans are similar to TCP SYN scans except that UDP is a «connectionless» protocol. There are no handshakes or acknowledgements. Instead, the scanner sends UDP packets to each UDP port. Closed ports should return ICMP port unreachable messages, and open ports do not return a response. Since UDP is not a «reliable» protocol, the scanner has no way of knowing if packets were lost, and has to do multiple checks for each port that does not return a response.

The Linux kernel sends out ICMP port unreachable messages very slowly, so a full UDP scan against a Linux machine would take over 10 hours. However, common ports could still be identified, so applying the same countermeasures against UDP scans as SYN scans is a good idea.

First, add a rule to reject packets from hosts on the UDP-PORTSCAN list to the top of the UDP chain.

Next, modify the reject packets rule for UDP:

Restore the Final Rule

If either or both of the portscanning tricks above were used, the final default rule is no longer the last rule in the INPUT chain. It needs to be the last rule, or it would intercept the trick port scanner rules you just added, rendering them useless. Simply delete (-D) the rule, then add it again using append (-A), which will place it at the end of the chain.

Protection against other attacks

See the sysctl#TCP/IP stack hardening for relevant kernel parameters.

Bruteforce attacks

Unfortunately, bruteforce attacks on services accessible via an external IP address are common. One reason for this is that the attacks are easy to perform with the many tools available. Fortunately, there are a number of ways to protect the services against them. One is the use of appropriate iptables rules which activate and blacklist an IP after a set number of packets attempt to initiate a connection. Another is the use of specialised daemons that monitor the logfiles for failed attempts and blacklist accordingly.

Two packages that ban IPs after too many password failures are Fail2ban or, for sshd in particular, Sshguard. These two applications update iptables rules to reject temporarily or permanently future connections from attackers.

The following rules give an example configuration to mitigate SSH bruteforce attacks using iptables .

Most of the rules should be self-explanatory: the first one allows for a maximum of three connection packets in ten seconds and drops further attempts from this IP. The next rule adds a quirk by allowing a maximum of four hits in 30 minutes. This is done because some bruteforce attacks are actually performed slow and not in a burst of attempts. The rules employ a number of additional options. To read more about them, check the original reference for this example in compilefailure.blogspot.com. The LOG_AND_DROP chain is used for logging dropped connections.

The above rules can be used to protect any service, though the SSH daemon is probably the most often required one.

In terms of order, one must ensure that -A INPUT -p tcp —dport ssh -m conntrack —ctstate NEW -j IN_SSH is at the right position in the iptables sequence: it should come before the TCP chain is attached to INPUT in order to catch new SSH connections first. If all the previous steps of this wiki have been completed, the following positioning works:

If you do not use IPv6, you can consider disabling it, otherwise follow these steps to enable the IPv6 firewall rules.

Copy the IPv4 rules used in this example as a base, and change any IPs from IPv4 format to IPv6 format:

A few of the rules in this example have to be adapted for use with IPv6. The ICMP protocol has been updated in IPv6, replacing the ICMP protocol for use with IPv4. Hence, the reject error return codes —reject-with icmp-port-unreachable and —reject-with icmp-proto-unreachable have to be converted to ICMPv6 codes.

The available ICMPv6 error codes are listed in RFC 4443, which specifies that connection attempts blocked by a firewall rule should use —reject-with icmp6-adm-prohibited . Doing so will basically inform the remote system that the connection was rejected by a firewall, rather than a listening service.

If it is preferred not to explicitly inform about the existence of a firewall filter, the packet may also be rejected without the message:

The above will reject with the default return error of —reject-with icmp6-port-unreachable . You should note though, that identifying a firewall is a basic feature of port scanning applications and most will identify it regardless.

This article or section needs expansion.

In the next step make sure the protocol and extension are changed to be IPv6 appropriate for the rule regarding all new incoming ICMP echo requests (pings):

Netfilter conntrack does not appear to track ICMPv6 Neighbor Discovery Protocol (the IPv6 equivalent of ARP), so we need to allow ICMPv6 traffic regardless of state for all directly attached subnets. The following should be inserted after dropping —ctstate INVALID , but before any other DROP or REJECT targets, along with a corresponding line for each directly attached subnet:

If you want to enable DHCPv6, you need to accept incoming connections on UDP port 546:

Since there is no kernel reverse path filter for IPv6, you may want to enable one in ip6tables with the following:

Saving the rules

The rule sets are now finished and should be saved to a file so that they can be loaded on every boot.

Save the IPv4 and IPv6 rules with these commands:

Resulting ip6tables.rules file

Example of ip6tables.rules file after running all the commands from above:

Then enable and start iptables.service and the ip6tables.service . Check the status of the services to make sure the rules are loaded correctly.

Setting up a NAT gateway

This section of the guide deals with NAT gateways. It is assumed that you already read the first part of the guide and set up the INPUT, OUTPUT, TCP and UDP chains like described above. All rules so far have been created in the filter table. In this section, we will also have to use the nat table.

Setting up the filter table

Creating necessary chains

In our setup, we will create two new chains in the filter table, fw-interfaces and fw-open, using the following commands:

Setting up the FORWARD chain

Setting up the FORWARD chain is similar to the INPUT chain in the first section.

Now we set up a rule with the conntrack match, identical to the one in the INPUT chain:

The next step is to enable forwarding for trusted interfaces and to make all packets pass the fw-open chain.

The remaining packets are denied with an ICMP message:

Setting up the fw-interfaces and fw-open chains

The meaning of the fw-interfaces and fw-open chains is explained later, when we deal with the POSTROUTING and PREROUTING chains in the nat table, respectively.

Setting up the nat table

All over this section, we assume that the outgoing interface (the one with the public internet IP) is ppp0. Keep in mind that you have to change the name in all following rules if your outgoing interface has another name.

Setting up the POSTROUTING chain

Now, we have to define who is allowed to connect to the internet. Let us assume we have the subnet 192.168.0.0/24 (which means all addresses that are of the form 192.168.0.*) on eth0. We first need to accept the machines on this interface in the FORWARD table, that is why we created the fw-interfaces chain above:

Now, we have to alter all outgoing packets so that they have our public IP address as the source address, instead of the local LAN address. To do this, we use the MASQUERADE target:

Do not forget the -o ppp0 parameter above. If you omit it, your network will be screwed up.

Let us assume we have another subnet, 10.3.0.0/16 (which means all addresses 10.3.*.*), on the interface eth1. We add the same rules as above again:

The last step is to enable packet forwarding (if it is not already enabled).

Machines from these subnets can now use your new NAT machine as their gateway. Note that you may want to set up a DNS and DHCP server like dnsmasq or a combination of BIND and dhcpd to simplify network settings DNS resolution on the client machines. This is not the topic of this guide.

Setting up the PREROUTING chain

Sometimes, we want to change the address of an incoming packet from the gateway to a LAN machine. To do this, we use the fw-open chain defined above, as well as the PREROUTING chain in the nat table in the following two simple examples.

First, we want to change all incoming SSH packets (port 22) to the ssh server of the machine 192.168.0.5:

The second example will show you how to change packets to a different port than the incoming port. We want to change any incoming connection on port 8000 to our web server on 192.168.0.6, port 80:

The same setup also works with udp packets.

Saving the rules

This assumes that you have followed the steps above to enable the iptables systemd service.

Источник