Lorsque vous utilisez Webmin pour administrer votre serveur, les paramètres de votre firewall iptables sont visibles et manageables depuis la console Webmin.
Toutefois, les règles iptables présentées par Webmin sont celles qui ont été préalablement sauvées par /sbin/iptables-save dans le fichier que vous avez choisi.
Donc si vous utilisez un script depuis le shell pour changer les règles de iptables, ce ne seront pas ces règles que Webmin vous présentera mais celles que vous avez sauvées préalablement avec Webmin.When using Webmin as an administration tool, iptables rules visible for Webmin are those previously saved through Webmin.
So when you use a shell script to change iptables rules on the fly, these rules won’t be the ones Webmin present to you.
Firewalls are heavily used to secure private networks (home or corporate). Usually, they are used to protect the network from:
intrusions from outsiders
misuse from insiders
In a TCP/IP environment, the typical corporate firewall configuration is to block everything (both incoming and outgoing), and give access to the internet only through a HTTP proxy. The proxy usually has filtering capabilities (censors URLs and file types), and access to the proxy often requires credentials (login/password). This gives greater contol to the network administrator over what and who is going in and out of the network.
Still, this should not considered a ultimate weapon, and network administrators should not rely on the firewalls only.
Encapsulation is the basis of networking. For example, HTTP is encapsulated by TCP, TCP is encapsulated by IP, and IP is often encapsulated in PPP or Ethernet. Encapsulating protocols in an unsual way is often reffered as tunnelling.
As soon as you let a single protocol out, tunelling allows to let anything go through this protocol, and thus through the firewall.
This paper demonstrates how to encapsulate any TCP-based protocol (SMTP, POP3, NNTP, telnet…) into HTTP, thus bypassing the firewall protection/censorship (depending on your point of view)
A word of warning:
In many countries and corporate environments, bypassing a firewall is forbidden and exposes you to sanctions, redundancy, legal proceedings and – in some countries – death penalty. You are warned.
Nevertheless, in some countries this kind of firewall/proxy bypassing is the only way to ensure free speech (such as China or United Arab Emirates where the government severly censors the internet and where firewall bypassing is a national sport.)
Now you known what you’re doing, let’s move on.
The problem
Say you want to fetch your mail from your ISP mail server. You usually simply connect to port 110 on the POP server of your ISP.
Trouble: there is a Big Bad firewall which blocks everything.
Well… it does not exactly block everything: it lets HTTP out through a proxy. Let’s encapsulate our POP3 connection into HTTP.
The tools
We need:
A computer on the internet which has unrestricted access to the internet, such as a home ADSL computer.
SSH is a secure shell (http://www.openssh.com). It provides secure (and compressed) channels between two hosts using SSL. Besides providing a shell (like telnet), it also provides file copy (scp) and TCP port forwarding (tunnelling). We will use the port forwarding feature.
Why not use GNU HTTP Tunnel alone ?
In principle, only HTTP Tunnel is necessary. But this is not desirable:
the tunnel is public: anyone can use your tunnel. Your could be held liable for what anybody has done with your tunnel.
the tunnel is cleartext: anyone can spy on your connection. Your passwords (SMTP, POP3, telnet…) are transmitted in clear text.
the tunnel is not protected: anyone can alter the datastream.
you have to run a new instance of the HTTP Tunnel client and the server for each new tunnel you want to set up.
This is where ssh come in. ssh provides:
authentication (only authorised users can use the tunnel)
privacy (no one can spy on what’s going through the tunnel)
integrity (no one can tamper data going through the tunnel)
easy tunnel set-up (you can create a new tunnel with a single ssh command on the client side).
These tools are available on Unix/Linux and Windows environments.
The whole chain
Let’s see how this works. Here is the full chain:
Technically speaking, once this chain is established, connecting to OfficeComputer:800 is identical to connecting to pop3server:110. The mail client will not see the difference.
On the office computer:
TCP data sent to port 800 is encrypted by ssh, which forwards data to port 900.
ssh stream sent to port 900 is chunked in individual HTTP requests by the HTTP Tunnel client and sent to the home computer through the proxy.
On the home computer:
the HTTP Tunnel server receives HTTP requests, decapsulates and re-assembles the ssh stream and forwards it to port 22 (to the ssh server).
the ssh server decrypts the datastream and forwards it to the pop3server on port 110.
As TCP is a bi-directionnaly datastream, once established, the TCP connection can pass data back and forth through the HTTP proxy.
Recently, I had to lease a new server. My old one was ok, but it was 5 years old, and showing it’s age. The most recent bout of problems was due to postfix, and a specific domain that I host mail for.
I had previously set up Policyd in an attempt to stop the influx of spam before it ever hit the server, but it wasn’t doing anything at this point. So approximately 800 messages per minute were getting directly to Postfix, and then running queries against MySQL (I use virtual maps for users, aliases, domains, etc). 99% of these messages were to non-existant users, so Postfix would bounce them. But the little 2.0GHz Celeron couldn’t handle it. The load shot up to 8 for around 3 weeks, and stayed there. I wish the fail2ban idea had come to me sooner… Lire la suite…
Mais que faire contre les attaques de type brute-force ? (Essai de toutes les combinaisons de lettre pour trouver le mot de passe).
C’est simple:
sudo aptitude install fail2ban
Et voilà !
Si quelqu’un fait 6 essais ratés de connexion sur le serveur ssh, son adresse IP sera bannie pendant 10 minutes. C’est suffisant pour rendre inutile ce genre d’attaque.
Pour voir les actions du programme, faites:
sudo cat /var/log/fail2ban.log
Aller plus loin
En fait, fail2ban peut être configuré pour faire plein d’autres choses. Dans le principe, il surveille les fichiers log de votre choix, et déclenche alors des actions.
Dans le cas de ssh, il surveille /var/log/auth.log et lance des commandes iptables pour bannir les adresses IP.
Regardez le fichier /etc/fail2ban/jail.conf Il contient déjà les lignes pour bloquer les attaques sur les serveurs ftp (vsftpd, wuftpd, proftpd…), postfix, apache… Vous pouvez les activer en remplaçant enabled = false par enabled = true.
La commande iptables-save est, comme nous l’avons déjà expliqué, un outil pour sauvegarder dans la table de règles un fichier que iptables-restore peut utiliser. Cette commande est tout à fait simple, et prend seulement deux arguments. Regardons l’exemple suivant pour comprendre la syntaxe :
iptables-save [-c] [-t table]
L’argument -c indique à iptables-save de conserver les valeurs spécifiées dans les compteurs de bits et de paquets. Ce qui pourrait être utile si vous voulez redémarrer votre pare-feu principal, mais sans perdre les compteurs de bits et de paquets que nous pourrions utiliser dans un but de statistiques. Exécuter une commande iptables-save avec l’argument -c nous permet de redémarrer sans briser les routines de statistique et de comptage. La valeur par défaut est, bien sûr, de ne pas garder les compteurs intacts quand cette commande est exécutée.
L’argument -t indique à la commande iptables-save quelle table sauvegarder. Sans cet argument toutes les tables disponibles dans le fichier seront automatiquement sauvegardées. Ci-dessous, un exemple de ce que donne une commande iptables-save sans avoir chargé de table de règles.
Les commentaires débutent avec la signe #. Chaque table est marquée par *<table-name>, par exemple, *mangle. Dans chaque table nous avons les spécifications de chaînes et les règles. Une spécification de chaîne ressemble à : <chain-name> <chain-policy> [<packet-counter>:<byte-counter>]. Le chain-name peut être, par exemple, PREROUTING, la règle d’action est décrite avant et peut être, par exemple, ACCEPT. Enfin les compteurs d’octets et de paquets sont les mêmes que dans la sortie de la commande iptables -L -v. Chaque déclaration de table se termine avec un mot-clé COMMIT. Le mot-clé COMMIT indique qu’à ce niveau toutes les règles seront envoyées au noyau par l’opérateur de transfert de données.
L’exemple ci-dessus est tout à fait basique, et je crois qu’il est approprié de montrer un bref exemple qui contient un petit Iptables-save ruleset. Si nous voulons lancer iptables-save sur celui-ci, la sortie de la commande sera :
# Generated by iptables-save v1.2.6a on Wed Apr 24 10:19:55 2002
*filter
:INPUT DROP [1:229]
:FORWARD DROP [0:0]
:OUTPUT DROP [0:0]
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i eth1 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
-A OUTPUT -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
COMMIT
# Completed on Wed Apr 24 10:19:55 2002
# Generated by iptables-save v1.2.6a on Wed Apr 24 10:19:55 2002
*mangle
:PREROUTING ACCEPT [658:32445]
:INPUT ACCEPT [658:32445]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [891:68234]
:POSTROUTING ACCEPT [891:68234]
COMMIT
# Completed on Wed Apr 24 10:19:55 2002
# Generated by iptables-save v1.2.6a on Wed Apr 24 10:19:55 2002
*nat
:PREROUTING ACCEPT [1:229]
:POSTROUTING ACCEPT [3:450]
:OUTPUT ACCEPT [3:450]
-A POSTROUTING -o eth0 -j SNAT --to-source 195.233.192.1
COMMIT
# Completed on Wed Apr 24 10:19:55 2002
Comme on peut le voir, chaque commande a été préfixée avec les compteurs d’octets et de paquets car nous avons utilisé l’argument -c. Excepté pour ceci, la ligne de commande est tout à fait identique au script. Le seul problème, est de savoir comment sauvegarder la sortie dans un fichier. Vraiment simple, et vous devriez savoir le faire si vous avez utilisé Linux auparavant. Il suffit d’utiliser un « pipe » (canal de communication) pour enregistrer la sortie de la commande dans le fichier. Ça ressemblera à cela :
iptables-save -c > /etc/iptables-save
La commande ci-dessus fera une sauvegarde de toute la table de règles appelée /etc/iptables-save avec les compteurs d’octets et de paquets toujours intacts.
Firewalls are heavily used to secure private networks (home or corporate). Usually, they are used to protect the network from:
