Archive

Articles taggués ‘firewall’

GeoIP pour iptables

11/12/2023 Comments off

Source: how-to.ovh

Marre des pays exotiques qui essaient de s’introduire sur le serveur et pourrissent vos logs et font bosser fail2ban ?

Une solution pour bloquer les pays avec lesquels vous n’avez pas de relations. Pour Debian mais sûrement adaptable à d’autres distributions.

# Install GeoIP pour iptables

apt-get install dkms xtables-addons-dkms xtables-addons-common xtables-addons-dkms geoip-database libgeoip1 libtext-csv-xs-perl unzip

# On vérifie que c’est ok

dkms status xtables-addons

# on crée le repertoire

mkdir /usr/share/xt_geoip

# on se déplace dedans

cd /usr/share/xt_geoip/

# on télécharge le fichier

wget http://man.sethuper.com/wp-content/uploads/2013/06/geoip-dl-build.tar.gz

# on le décompresse

tar xvf geoip-dl-build.tar.gz

# on l’exécute

./xt_geoip_dl

# si cela donne un message d’erreur, on fait ceci

/usr/bin/perl -MCPAN -e'install Text::CSV_XS'

# on exécute l’autre fichier

./xt_geoip_build -D . *.csv

# on efface les fichiers inutiles

rm -rf geoip-dl-build.tar.gz

# on teste iptables en bloquant la Chine et la Russie

iptables -A INPUT -m geoip --src-cc CN,RU -j DROP

# on vérifie

iptables -L -v

# ce qui donnera cette ligne indiquant que les pays seront bloqués

DROP all -- anywhere anywhere -m geoip --source-country CN,RU

pour interdire le port 22 à ces pays

iptables -A INPUT -p tcp --dport 22 -m geoip --src-cc CN,RU -j DROP

Block entire countries on Ubuntu server with Xtables and GeoIP

10/12/2023 Comments off

Source: jeshurun.ca

Anyone who has administered even a moderately high traffic server will have noticed that certain unwelcome traffic such as port scans and probes tend to come from IP addresses belonging to a certain group of countries. If your application or service does not cater to users in these countries, it might be a safe bet to block these countries off entirely.

This is especially true for email servers. The average email server, based on anecdotal evidence of servers for around 20 domains, rejects about 30% of incoming email every day as spam. Some servers on some days reject up to as much as 97% of incoming email as spam. Most of these originate in a certain subset of countries. That is a lot of wasted CPU cycles being expended on scanning these undesired emails for spam and viruses. Although tools such as amavisd and spamassasin do a good job of keeping the vast majority of spam out of users’ inboxes, when the rare well crafted and targeted phishing email does get through, it wrecks havoc in the enterprise.

Lire la suite…

Easy Ubuntu 16.04 Server Firewall

08/12/2023 Comments off

If you read our previous article Easy Ubuntu Server Firewall, then you may have noted that on Ubuntu 16.04 the described method no longer works. This is due to systemd. In the article below we will walk through creating a persistent IPTables based firewall on Ubuntu 16.04 LTS. First we need to install some required software packages. As seen in the command below, install iptables-persistent. Next we will make netfilter-persistent run at boot. This is the most important step as it will ensure your rules are reloaded at boot time.

# Install IPTables Persistent Package
apt-get install -y iptables-persistent
# Add netfilter-persistent Startup
invoke-rc.d netfilter-persistent save
# Stop netfilter-persistent Service
service netfilter-persistent stop

Once the packages above are installed and the service is stopped, you will have a new directory at /etc/iptables/. This directory holds the IPTables filter rules that will be reloaded at boot time. These files are named rules.v4 and rules.v6 respectively. IPV4 rules are loaded into rules.v4 and IPV6 rules are loaded into rules.v6. For the purpose of this article we will focus on IPV4 rules. Next we will want to copy the rules below into our rules.v4 file. Of course the rules will need to be modified to fit your environment.

# Generated by iptables-save v1.3.3 on Wed Apr 9 10:51:08 2008
# Flush out any rules that are already in there
*filter
:INPUT ACCEPT [146:11332]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [104:9831]
 
# Allow internal loopback connections
-A INPUT -i lo -j ACCEPT
-A OUTPUT -o lo -j ACCEPT
 
# Allow pinging
-A INPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT
 
# Allow any outbound data, and any inbound data related to a connection that is already in use
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A OUTPUT -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
 
# =========BEGIN SERVER SPECIFIC PORT OPEN RULES=========
# Allow SCP/SSH Access from Green & Blue Subnet
-A INPUT -s 172.16.12.0/255.255.255.0 -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -s 10.10.12.0/255.255.255.0 -p tcp -m tcp --dport 22 -j ACCEPT
 
# Allow HTTP Access from Red Subnet/Internet
-A INPUT -p tcp -m state --state NEW,ESTABLISHED --dport 80 -j ACCEPT
 
# Allow HTTPS Access from Red Subnet/Internet
-A INPUT -p tcp -m state --state NEW,ESTABLISHED --dport 443 -j ACCEPT
 
# Allow MySQL Access from Red Subnet/Internet
-A INPUT -p tcp -m state --state NEW,ESTABLISHED --dport 3306 -j ACCEPT
 
# Allow FTP Access from Red Subnet/Internet
-A INPUT -p tcp -m state --state NEW,ESTABLISHED --dport 21 -j ACCEPT
-A INPUT -p tcp -m state --state NEW,ESTABLISHED --dport 58000:58010 -j ACCEPT
# =========END SERVER SPECIFIC PORT OPEN RULES=========
 
# Drop everything that hasn't been picked up by one of the rules above
-A INPUT -j DROP
-A FORWARD -j DROP
-A OUTPUT -j DROP
 
COMMIT
# Completed on Wed Apr 9 10:51:08 2008

Lastly, in order for our new rules to take affect, we simply need to start the netfilter-persistent service as seen below. That’s it, you now have a fully functional IPTables based firewall.

# Start netfilter-persistent Service
service netfilter-persistent start

# Check if IPTables were applied
iptables -L

Rendre ses règles persistantes sous GNU/Debian avec iptable-persistent

27/11/2023 Comments off

Si vous souhaitez rendre vos règles de firewalling persistantes les développeurs de iptables ont prévu deux commandes : iptables-save et iptables-restore.

Ces commandes permettent de créer une copie de la configuration actuelle et de charger une de ces copies.

Il se trouve que nos amis de chez Debian ont prévu un petit script permettant d’automatiser le chargement des règles iptables au démarrage : iptables-persistent. Nous allons donc dans un premier temps installer ce paquet. Nous verrons ensuite comment sauvegarder notre configuration actuelle.

Installation de iptables-persistent

L’installation est très très très simple … voyez plutôt !

# aptitude install iptables-persistent 

Et le tour est joué !

À l’installation il vous sera demandé si vous souhaitez sauvegarder les règles de firewalling actuellement en place. Vous pouvez répondre oui ou non.

Ce paquet vous a créé plusieurs fichiers dont

  • /etc/iptables/rules.v4 : Le fichier qui sera lu par le script de démarrage pour charger vos règles IPV4.
  • /etc/iptables/rules.v6 : Le fichier qui sera lu par le script de démarrage pour charger vos règles IPV6.

Sauvegarder nos règles

Comme je le disais plus haut, il existe la commande iptables-save qui nous permet d’exporter la configuration actuelle. Petit exemple

# iptables-save

<em id="__mceDel"># Generated by iptables-save v1.4.8 on Thu Apr 18 20:48:47 2013
*raw
:PREROUTING ACCEPT [9797384:2383152683]
:OUTPUT ACCEPT [7848850:7602037790]
COMMIT
# Completed on Thu Apr 18 20:48:47 2013
# Generated by iptables-save v1.4.8 on Thu Apr 18 20:48:47 2013
*nat
:PREROUTING ACCEPT [535202:35374631]
:INPUT ACCEPT [535202:35374631]
:OUTPUT ACCEPT [107902:12861811]
:POSTROUTING ACCEPT [107902:12861811]
COMMIT
# Completed on Thu Apr 18 20:48:47 2013
# Generated by iptables-save v1.4.8 on Thu Apr 18 20:48:47 2013
*mangle
:PREROUTING ACCEPT [9797384:2383152683]
:INPUT ACCEPT [9797384:2383152683]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [7848852:7602038246]
:POSTROUTING ACCEPT [7848852:7602038246]
COMMIT
# Completed on Thu Apr 18 20:48:47 2013
# Generated by iptables-save v1.4.8 on Thu Apr 18 20:48:47 2013
*filter
:INPUT ACCEPT [721005:567300541]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [7247423:5928062896]
-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 80 -j ACCEPT
COMMIT
# Completed on Thu Apr 18 20:48:47 2013

La seul chose que nous avons à faire est de rediriger la sortie de cette commande non plus dans le terminal mais dans le fichier rules.v4 ou rules.v6 utilisés par iptables-persistent.

# iptables-save > /etc/iptables/rules.v4
 # iptables-save > /etc/iptables/rules.v6
Categories: Réseau, Sécurité Tags: ,

A Deep Dive into Iptables and Netfilter Architecture

26/11/2023 Comments off

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…