There are two type of servers, I’ve encountered this message on:
1. Xen OpenVZ / VPS (Virtual Private Servers) 2. ISPs – Internet Providers with heavy traffic NAT network routers
I. What is the meaning of nf_conntrack: table full dropping packet error message
In short, this message is received because the nf_conntrack kernel maximum number assigned value gets reached. The common reason for that is a heavy traffic passing by the server or very often a DoS or DDoS(Distributed Denial of Service) attack. Sometimes encountering the err is a result of a bad server planning (incorrect data about expected traffic load by a company/companeis) or simply a sys admin error…
– Checking the current maximum nf_conntrack value assigned on host:
The shown connections are assigned dynamicly on each new succesful TCP / IP NAT-ted connection. Btw, on a systems that work normally without the dmesg log being flooded with the message, the output of lsmod is:
On servers which are encountering nf_conntrack: table full, dropping packet error, you can see, when issuing lsmod, extra modules related to nf_conntrack are shown as loaded:
Firstly, do you really need to be running an FTP server? If not, turn it off and block the relevant ports. For example, using iptables:
/sbin/iptables -A INPUT -p tcp --match multiport --dports ftp,ftp-data -j DROP
In any case you almost certainly want to disable anonymous FTP connections. For one thing Googlebot has a nasty habit of exploring anonymous ftp which could result in the wrong files being exposed.
Limit access to FTP
If you do need to allow FTP then can you restrict access to specific ip addresses within your local network or a clients network? If so you should set up a white-list.
This can be enabled using /etc/proftpd/proftpd.conf as shown below – including one or moreAllow clauses to identify from where you want to allow FTP access:
<Limit LOGIN>
# single ip address example
Allow from 192.168.0.1
# multiple ip addresses example
Allow from 192.168.0.1 10.30.124.6
# subnet example
Allow from 192.168.0.0/16
# hostname example
Allow from example.net DenyAll </Limit>
The final DenyAll prevents the rest of the world from being able to connect. If you’re running ftp viainetd then the changes take effect immediately. Otherwise you will need to restart your FTP server.
Make logins harder to guess
Most FTP hacking attempts are automated so rely on guessing both the username and the password. For example, if your domain name is www.example.net the hacking script will try « example« , « examplenet« , « [email protected]« , « [email protected] » and so on. Generic usernames including « admin« , « www« , « data » and « test » are also being tried.
If the script is unable to guess a valid username then it will not be able to try any passwords. You should ensure your FTP usernames are not predictable in any way from the domain name – by appending some random letters or digits for example.
Hackers are also equipped with dictionaries and large databases of exposed username/password combinations from previously exploited servers. So make sure your passwords, not just for FTP, are long and complicated and don’t match common patterns.
2. Dynamically blocking login attempts
The Fail2Ban program can be used to detect failed login attempts and automatically block the source ip address for a period of time. With Fail2Ban installed, we can enable this as follows.
Define the regular expression to look for in /etc/fail2ban/filter.d/proftpd.conf:
failregex = \(\S+\[<HOST>\]\)[: -]+ USER \S+: no such user found from \S+ \[\S+\] to \S+:\S+ *$
\(\S+\[<HOST>\]\)[: -]+ USER \S+ \(Login failed\): .*$
\(\S+\[<HOST>\]\)[: -]+ SECURITY VIOLATION: \S+ login attempted\. *$
\(\S+\[<HOST>\]\)[: -]+ Maximum login attempts \(\d+\) exceeded *$
With the above configuration any ip address responsible for 5 or more failed FTP login attempts – any logfile entries matching the above regular expressions – will be ‘jailed’ for a period of 1 hour. You can change these values to require less failed login attempts or to make the jailing last longer.
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.
Warning: The rules are given in the order that they are executed. If you are logged into a remote machine, you may be locked out of the machine while setting up the rules. You should only follow the steps below while you are logged in locally.The example config file can be used to get around this problem.
Prerequisites
Note: Your kernel needs to be compiled with iptables support. All stock Arch Linux kernels have iptables support.
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:
# iptables-save
# Generated by iptables-save v1.4.19.1 on Thu Aug 1 19:28:53 2013
*filter
:INPUT ACCEPT [50:3763]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [30:3472]
COMMIT
# Completed on Thu Aug 1 19:28:53 2013
or
# iptables -nvL --line-numbers
Chain INPUT (policy ACCEPT 156 packets, 12541 bytes)
num pkts bytes target prot opt in out source destination
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
num pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 82 packets, 8672 bytes)
num pkts bytes target prot opt in out source destination
If there are rules, you may be able to reset the rules by loading a default rule set:
On a vu dans l’article précédent comment fonctionnait IPTables et comment pouvait se construire ses commandes. Dans la suite je vais vous proposer un script qui permet d’initialiser IPTables avec ses propres règles au démarrage de la machine.
Ce n’est pas la meilleure façon de faire c’est juste celle que j’utilise. On pourrait rendre ce script plus court, plus interactif j’en suis parfaitement conscient. D’abord je commence a choisir mes règles par défaut: logiquement je bloque tout le trafic entrant mais est ce que je bloque aussi par défaut tout le trafic sortant ? C’est mon cas mais à vous de voir ce qui est le mieux pour votre situation. Par exemple, et c’est rare, lorsque qu’un attaquant réussit via je ne sais quel moyen a coller un rootkit sur votre serveur cela peut être intéressant de l’empêcher de dialoguer avec l’extérieur. Ensuite comme vous êtes sûrement connectés en SSH sur votre serveur on va éviter de couper la connexion à l’initialisation du pare feu par exemple donc il va falloir autoriser toutes les connexions déjà établies en considérant qu’elles soient sûres. Puis on enchaîne nos règles en gardant bien à l’esprit l’article précédent pour les agencer dans l’ordre. Donc ça donne quelque chose comme ça:
#!/bin/sh#On rappelle le chemin ou se trouve l'exécutable dont on va se servir
PATH=/bin:/sbin:/usr/bin:/usr/sbin
#On vide complètement les règles
iptables -t filter -F
iptables -t filter -X
#Tout le trafic est bloqué...
iptables -t filter -P INPUT DROP
iptables -t filter -P FORWARD DROP
iptables -t filter -P OUTPUT DROP
#...sauf les connexions déjà établies
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
#On autorise le serveur a pouvoir communiquer avec lui même (la boucle locale)
iptables -t filter -A INPUT -i lo -j ACCEPT
iptables -t filter -A OUTPUT -o lo -j ACCEPT
#Si on veut bloquer des adresses en particulier c'est ici qu'il faut les ajouter car en dessous on commence à ouvrir les ports et on risque que ces règles prennent le pas sur un blocage spécifique
iptables -A INPUT -s A.B.C.D -j DROP
iptables -A INPUT -s X.X.Y.Y -j DROP
#Autoriser le ping dans les deux sens
iptables -t filter -A INPUT -p icmp -j ACCEPT
iptables -t filter -A OUTPUT -p icmp -j ACCEPT
#Autorisation du traffic Web en entrant
iptables -t filter -A INPUT -p tcp --dport 80-j ACCEPT
iptables -t filter -A INPUT -p tcp --dport 443-j ACCEPT
#Autorisation du traffic SSH en entrant pour le management du serveur
iptables -t filter -A INPUT -p tcp --dport 22-j ACCEPT
#Autorisation du web en sortant (utile pour récupérer des sources)
iptables -t filter -A OUTPUT -p tcp --dport 80-j ACCEPT
iptables -t filter -A OUTPUT -p tcp --dport 443-j ACCEPT
#Autorisation SSH, FTP en sortant
iptables -t filter -A OUTPUT -p tcp --dport 21-j ACCEPT
iptables -t filter -A OUTPUT -p tcp --dport 22-j ACCEPT
#Autorisation NTP, RTM(OVH), DNS,
iptables -t filter -A OUTPUT -p tcp --dport 123-j ACCEPT
iptables -t filter -A OUTPUT -p udp --dport 6100:6200-j ACCEPT
iptables -t filter -A OUTPUT -p tcp --dport 53-j ACCEPT
#Protection DDOS
iptables -A FORWARD -p tcp --syn -m limit --limit 1/second -j ACCEPT
iptables -A FORWARD -p udp -m limit --limit 1/second -j ACCEPT
iptables -A FORWARD -p icmp --icmp-type echo-request -m limit --limit 1/second -j ACCEPT
#Anti Scan de port
iptables -A FORWARD -p tcp --tcp-flags SYN,ACK,FIN,RST RST -m limit --limit 1/s -j ACCEPT
Voilà donc comme je l’ai dit ce n’est pas un script parfait mais il permet au moins de voir que fait chaque ligne et reste clair malgrès tout. Il est évident qu’il faudrait réfléchir a une autre méthode si les règles viennent à se multiplier parce que cela peut vite devenir ingérable. Ceci dit vous allez pouvoir avoir une base compréhensible pour sécuriser votre serveur de manière fiable. En tout cas au niveau des connexions réseau !
