Depuis quelques jours, le soir, je rencontre de grosses difficultés de connexion à internet. En effet j'ai des pings à 6000ms avec 50% de pertes de paquets. J'ai remarqué que le fait d'éteindre mon serveur @home permettait de résoudre le problème, ce qui est un peu étrange car j'imagine mal comment on peut mettre à genoux une connexion de 100Mbps. Plus étrange encore, le fait de désactiver les services nginx et postfix permettait également de résoudre les problèmes. En revanche la lecture des logs de ces services et ceux du système n'indiquait rien d'anormal.

Je m'orientais donc soit vers un ddos, soit un bug de lxc car la version proposée sur Debian est obsolète et on peut très bien imaginer des problèmes avec le bridge menant à des tempêtes de broadcast ou autres joyeusetés du genre. Désespéré, j'ai upgradé mon serveur en Jessie. Exit le kernel 3.2 et bonjour au 3.16, exit lxc 0.8 et bonjour lxc1.0. Suite à cela j'ai remarqué un retour à la normale et même une hausse de la réactivité du serveur. Je pensais donc le problème résolu.

Mais ce soir, rebelotte. Ping à 6000ms, 50% de pertes de paquets, et encore une fois le fait de couper mon serveur faisait disparaitre le problème. Cette fois j'ai donc fait tourner une analyse wireshark sur l'interface réseau du serveur.

Capture du trafic avec wireshark

Côté serveur (remote)

Installer tcpdump :

# apt-get install tcpdump

Côté PC portable

Installer Wireshark puis exécuter les commandes suivantes :

# mkfifo /tmp/wshark
# ssh root@192.168.0.1 "tcpdump -s 0 -U -n -w - -i eth0 not port 22" > /tmp/wshark

Puis, dans un autre onglet :

 # wireshark -k -i /tmp/wshark

Wireshark doit s'ouvrir et commencer à afficher le traffic du serveur :

Analyse des résultats

J'ai donc observé que pour deux IP, les trames suivantes inondaient le serveur :

3	0.023193000	5.39.90.132	192.168.0.2	TCP	66	[TCP Port numbers reused] 80→25 [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=256 SACK_PERM=1

Sans connaître tous les détails il semble que ce soit donc bien une attaque. Apparemment c'est du SYN flood.

Actions

A l'aide d'iptables, j'ai bloqué les deux adresses IP en cause :

# iptables -I FORWARD -s 5.39.90.132 -j DROP
# iptables -I FORWARD -s 37.187.112.166 -j DROP

Note : j'utilise FORWARD car j'ajoute cette règle sur l'hôte alors que les paquets sont à destination d'un container LXC qui dispose d'une autre adresse IP. INPUT doit être mis à la place si ce n'est pas le cas, ou dans le doute, les deux.

Miracle, après avoir bloqué ces deux IP, ma connexion à internet est revenue à la normale.

Ma deuxième action fut d'exécuter un whois sur ces deux IP pour en apprendre un peu plus. Elles appartiennent à des serveurs dédiés OVH, j'ai donc rempli le formulaire abuse sur leur site pour leur signaler que ces serveurs ont un comportement étrange.

Conclusion

Mon interprétation est la suivante : deux serveurs m'ont inondé de requêtes, qui arrivent sur nginx et postfix puisqu'elles sont destinées aux ports 25/80/443 d'après Wireshark. Si mon container LXC est éteint, elles finissent dans le vide. En revanche s'il est allumé, elles aboutissent et se multiplient jusqu'à saturer la BBox (le routeur en amont), ce qui provoque les ralentissements. Wireshark m'a beaucoup aidé à diagnostiquer ce problème, c'est maintenant mon meilleur ami.

iptables a pour instruction de "droper" (DROP) les paquets en provenance de ces deux adresses, ce qui revient donc à reproduire le comportement du serveur éteint. Le signalement à OVH permettra, j'espère, de faire couper ces deux serveurs probablement compromis.

En 4 ans d'auto-hébergement c'est la première fois que je suis confronté à un tel problème. On en revient aux raisons qui m'ont poussé à externaliser le blog maniatux.fr sur un VPS OVH, à savoir que si des attaques doivent avoir lieu, autant que ce ne soi pas chez moi. Mais il me reste un serveur @home que je pensais suffisamment "discret" pour ne pas se faire attaquer. J'espère que cela ne se reproduira pas à l'avenir...

Mon serveur tourne sur FreeBSD 10 et les services sont fournis par des jails sous Debian GNU/kFreeBSD. J'ai activé pf, le pare-feu sur l'hôte avec quelques règles de filtrage pour grosso modo tout autoriser en sortie, mais bloquer en entrée ce qui n'est pas désiré. Ces règles n'agissent que sur la partie IPv6 car je me repose sur le NAT de la box et les redirections de port pour filtrer ce qui entre l'IPv4.

Exemple

Dans l'exemple ci-dessous on va considérer les adresses suivantes :

• Serveur IPv6 Address : 2001:470:c851::1
• Client IPv6 Address : 2001:470:c851::2
• www jail : 2001:470:c851::1001 (on va ouvrir les ports 80 et 443)
• mail jail : 2001:470:c851::1002 (on va ouvrir les ports 25, 143 et 587)

Configuration

Note : Je me suis basé sur cette documentation chez SixXs.

/etc/rc.conf.local

# PF
pf_enable="YES"
pflog_enable="YES"

/etc/pf.conf/

# Macros
sendpoint = "2001:470:c851::1" # Votre Server IPv6 Address
cendpoint = "2001:470:c851::2" # Votre Client IPv6 Address
www = "2001:470:c851::1001" # ip de la jail www
mail = "2001:470:c851::1002" # ip de la jail mail
ext_inf = "gif0" # Mon interface tunnel

# don't filter l0
set skip on l0

# scrub incomming packets
scrub in all

# block in/out on $tun_if
block in log on $ext_inf inet6
block out log on $ext_inf inet6

# allow heartbeat ping
pass in quick on $ext_inf inet6 proto { ipv6-icmp } from $sendpoint to $cendpoin
t keep state

# pass tcp, udp, and icmp6 out on the ipv6 tunnel interface.
pass out quick on $ext_inf inet6 proto { tcp udp ipv6-icmp } keep state

# www jail
pass in quick on $ext_inf inet6 proto tcp from any to $www port { 80 443 }

# mail jail
pass in quick on $ext_inf inet6 proto tcp from any to $mail port { 25 143 587 }

Vérifier

pf dispose d'une commande pour vérifier un fichier de configuration :

# pfctl -vnf /etc/pf.conf

Charger

Lorsque la vérification est OK, on peut charger :

# service pf restart

Test en ligne

Certains sites vous proposent de scanner vos ports en ligne, notamment ce site. Il supporte les navigateurs en mode texte donc vous pouvez faire le scan directement depuis votre serveur ;)

Ressources

• http://ipv6.chappell-family.com/ipv6tcptest/
• https://www.sixxs.net/wiki/IPv6_Firewalling#FreeBSD_support

Cela va bientôt faire 3 mois que j'utilise pfSense, un système d'exploitation FreeBSD orienté routeur. En 2011 j'avais déjà rédigé un article dessus, mais depuis Juillet 2012 je l'ai mis en "production" avec fonctionnement 24h/24 et conditions réelles. Plusieurs points m'ont particulièrement plu dans pfSense, je vais les décrire ci-dessous.

Voici les fonctionnalités que j'exploite actuellement :

• NAT et PAT
• Firewall (DMZ)
• Serveur DHCP
• Client OpenVPN
• Routes statiques
• 3 VLAN taggés sur un unique port
• Casé sur une carte CF
• 4 postes utilisateurs sur le VLAN30, 4 serveurs sur le VLAN20 (dmz)

Notez qu'il y en a de nombreuses autres que je n'utilise pas : serveur NTP, DNS, relai DHCP, IPSec, la liste est longue...

Fiabilité

Pour l'instant, 79 jours d'uptime, ça peut paraître peu mais comme je l'ai dit précédemment cela ne fait que 3 mois. Les derniers redémarrages ont été volontaires pour des opérations de mise à jour ou des coupures en cas d'orage. Il faut aussi comparer cela à une merdebox domestique qui nécessite un reboot quasi journalier pour rétablir l'accès à internet. Bref, pfSense c'est fiable, ça tourne sans interruption.

Fonctionnalités

J'apprécie particulièrement que cette petite boite noire (Alix 1.d) soit capable de gérer à elle toute seule l'intégralité du réseau. J'ai ainsi pu y "greffer" mon VPN, mais aussi un serveur DHCP. Et les autres points appréciables concernent les outils de diagnostic. On peut faire des ping, visualiser les tables de routage, arp, traceroute, et il y a même un sniffeur de réseau réglable sur plusieurs niveaux de verbosité.

Simplicité

Tout est bien organisé, facile à trouver et à utiliser. Les changements sont pris en compte sans devoir redémarrer le routeur (là encore, comparaison aux box domestiques) ce qui est appréciable. Les tableaux récapitulatifs des règles de parefeu sont assez bien pensés. La configuration peut être exportée dans un fichier XML si vous désirez "formater" la machine (pour une mise à jour par exemple).

Conclusion

Je ne regrette pas le choix de pfSense comme solution pour gérer mon réseau :D toutes les qualités que l'on peut rechercher y sont, avec la souplesse, la simplicité et la fiabilité. C'est une appliance excellente qui n'est pas prête de me lâcher !

pfSense est un système d'exploitation conçu pour faire fonctionner un ordinateur en tant que parefeu/routeur sur un réseau. Basiquement, il est constitué de FreeBSD et son firewall netfilter sur lesquels un Webgui a été ajouté. En pratique il est très complet et dispose de fonctionnalités intégrées comme un serveur NTP, DNS, possibilité de construire des liaisons VPN, Load balancing, VLAN, etc...

Le projet a débuté comme fork de M0n0wall, mais sa version 2.0, encore au stade de RC1, apporte une interface totalement nouvelle. Le système sera encore capable de tourner sur des systèmes embarqués, il tient notamment sur carte Compact Flash et n'a pas besoin de carte graphique.

L'installation est vraiment très simple et très rapide. La seule configuration à faire est de définir votre interface WAN et votre LAN, puis leur donner une adresse IP (ou laisser faire la magie du DHCP). Ensuite vous pouvez utiliser le Webgui en tapant http://adresseip (possibilité d'utiliser le https via les options). L'utilisateur est 'admin' et le mot de passe 'pfsense'.

Cliquez pour agrandir

L'interface est triée via un système d'onglets très pratique et très clairs. La configuration du parefeu est particulièrement bien détaillée et les fonctionalités de filtrage et de NAT sont séparées. Le VPN peut fonctionner sur plusieurs protocoles: IPSec, OpenVPN, PPTP et L2TP. Leur configuration se révèle encore une fois intuitive.

En conclusion je pense que pfSense est le meilleur des OS orienté firewall parmi ceux que j'ai pu tester jusqu'ici. Son concurrent le plus sérieux dans le monde Linux est ipfire, mais son interface manque de logique et de clarté. Donc si le matériel le permet, privilégiez pfSense.