Introduction

Je vais présenter les manipulations effectuées pour installer un point d’accès wifi sur une machine servant de pare-feu et permettant donc l’accès à internet.

Attention : La configuration qui est présentée n’est absolument pas recommandée… En effet le point d’accès est situé à l’intérieur du réseau protégé par le pare-feu. Ainsi toute personne qui se connecte au point d’accès wifi accède au réseau local. Cependant, j’habite une maison isolée en pleine campagne, et un parasite qui voudrait se connecter au réseau devrait se positionner devant ma porte… Ce qui est valable pour moi n’est donc pas valable dans un immeuble, avec des voisins à l’affut !

Ma configuration réseau

Je vais utiliser mon pare-feu comme pont ethernet entre la carte wifi et une carte réseau cablée. Le pare-feu sert également de passerelle pour sortir sur internet, par un modem rtc pour l’instant, bientôt par un routeur en adsl.

Ainsi il est possible de connecter des machines sur un hub reliée à la carte réseau classique, mais aussi des machines (j’ai un portable, et des machines fixes à l’étage) dotées de cartes wifi.

Configuration logicielle et matérielle pré-requise

Matériel

Il faut une carte qui puisse fonctionner en mode Master, si possible qui fasse du WPA, mais cette fonctionnalité ne sera pas abordée dans ce document car ma carte cliente (carte pcmcia DLink DWL-650+) ne peut fonctionner avec le fameux wpasupplicant.

Je me suis donc procuré une carte DLink DWL-G250, qui fonctionne avec les pilotes Madwifi(chipset Atheros). Sur cette page vous trouverez une liste des cartes compatibles avec Madwifi.

Logiciel

Mon pare-feu est sous Debian Sarge (stable), avec un noyau Debian. Donc tout ce qu’il faut (bridging et ebtables ) est déjà en modules.

Pour ceux qui voudraient compiler leur noyau, tout ce trouve dans Networking. On trouve dans cette section ce qui concerne le protocole 802.11. Puis on sélectionne Networking options. Là on sélectionne 802.1d Ethernet bridging ainsi que la sous-section Network packet filtering, puis Bridge : Netfilter configuration, et on peut modulariser toutes les options de Ethernet Bridge tables (ebtables) support.

Les pilotes de la carte wifi sont à compiler avec les fichiers d’en-tête du noyau. J’ai choisi la facilité avec les sources de madwifi.

– Dans mon sources.list j’ai inclu la ligne :

deb http://www.backports.org/debian/ sarge-backports non-free

– Dans mon fichier /etc/apt/preferences j’ai inclu la section suivante :

Package: *
Pin: release a=sarge-backports
Pin-Priority: 200

– Puis j’ai utilisé module assistant pour la compilation des sources de Madwifi.

Il vous faut installer les paquets wireless-tools – pour les commandes iw* (iwlist, iwconfig…) – et bridge-utils – pour brctl et les spécifications particulières du fichier interfaces -.

Mise en place du bridge

J’utilise le fichier /etc/network/interfaces mais aussi les dossiers prévus pour l’exécution de commandes dans /etc/network : if-pre-up.d/, if-up.d/ et if-post-down.d/

Voici mon fichier /etc/network/interfaces :

auto br0
iface br0 inet dhcp
bridge_ports cable ath0
bridge_stp off


Le pont est monté au boot et cherche son adresse par dhcp. Le serveur dhcp (dnsmasq) est sur une machine fixe reliée au cable (eth0). Pour des raisons de sécurité, le serveur dhcp attribue des adresses fixes en fonction de l’adresse MAC.

Le pont est constitué des deux interfaces cable (eth0, mais voir le script activate pour le renommage) et ath0, le point d’accès wifi. Le Spanning Tree Protocol est désactivé, la configuration est simplissime avec un seul pont sur le réseau.

Le fichier suivant, /etc/network/if-pre-up.d/activate, construit le pont et active le filtrage.

1 #!/bin/bash
2 #
3 # /etc/network/if-pre-up.d/activate
4 #
5 case $LOGICAL in
6 br0)
7 nameif cable 00:00:E8:E3:7E:9E
8 ifconfig cable 0.0.0.0 up
9 ifconfig ath0 0.0.0.0 up
10 iwconfig ath0 mode master
11 brctl addbr br0
12 brctl addif br0 cable
13 brctl addif br0 ath0
14 echo -e "\nRestoring ebtables/iptables rules..."
15 /etc/network/iptables-srv-br.init
16 ;;
17 esac
18


Ligne 7, on renomme ma carte réseau cablée en « cable », afin de lui attribuer toujours le même nom.

Lignes 8 et 9 configurent les cartes sans leur donner d’adresse, puisque c’est le pont qui la possède.

La ligne 10 configure la carte wifi en mode Master pour en faire le point d’accès.

Les lignes 11, 12 et 13 créent le bridge avec ses interfaces associées.

La ligne 15 lance le script de règles.

Remarque : Il est possible d’utiliser des commandes ebtables et iptables-restore pour relancer les règles, mais ça ne fonctionne pas chez moi à cause d’une règle additionnelle lancée par ppp à la connexion.

Dans if-up.d/wifi, le point d’accès est configuré, avec une clé WEP.

#!/bin/bash
#
# /etc/network/if-up.d/wifi
#
case $LOGICAL in
br0)
echo "Setting wifi...."
/sbin/iwconfig ath0 \
essid mon_wifi \
channel 1 \
rate 11M \
mode Master \
key restricted 0123456789abcdef \
encryption on
;;
esac


J’ai même écrit un script en Python qui fabrique des clés de la longueur donnée en argument (script très sommaire) :

#!/usr/bin/env python
# -*- coding: utf-8 -*-
#
# generateur de cle WEP

import sys, random

def convertir_en_hexa(i):
return "%x" % i

def generer_cle_wep(lgr):
s = ''
for i in range(lgr):
if i > 0 and i % 4 == 0:
s += '-'
s += str(convertir_en_hexa(random.randint(0, 15)))
return s

if __name__ == '__main__':
print generer_cle_wep(int(sys.argv[1]))


Le script /etc/network/if-post-down.d/inactivate défait tout ce qui a été construit : il fait tomber les interfaces, les désassocie du bridge et supprime le bridge. Les règles ebtables et iptables sont sauvegardées.

#!/bin/bash
#
# /etc/network/if-post-down.d/inactivate
#
case $LOGICAL in
br0)
ifconfig cable 0.0.0.0 down
ifconfig ath0 0.0.0.0 down
brctl delif br0 cable
brctl delif br0 ath0
brctl delbr br0
echo -e "\\nSaving ebtables rules...."
/sbin/ebtables --atomic-file /var/lib/ebtables/active --atomic-save
echo "Saving associated iptables rules..."
/sbin/iptables-save > /var/lib/iptables/active-br
;;
esac


1 Filtrage

Il ne suffit pas de créer puis d’activer le bridge. Il faut également permettre les accès, voire les filtrer. Je présente dans les lignes qui suivent mes règles ebtables, ainsi que quelques règles iptables liées au pont ethernet.

Un peu de documentation est nécessaire pour bien comprendre la logique d’ebtables, et surtout son imbrication avec iptables :

– Le site d’ebtables
– Notamment, dans ce site, les interactions entre iptables et ebtables ;
– Toujours sur ce site, un schéma très explicatif : ici.

Attention :Toutes les règles du pare-feu ne sont pas présentées dans le script.

1 #!/bin/bash
2 #
3 # Quelques règles ebtables et iptables liées.
4
5 IPTABLES="/sbin/iptables"
6 EBTABLES="/sbin/ebtables"
7
8 cable="cable"
9 wifi="ath0"
10 bridge="br0"
11
12 ESPINASSE_MAC_ADR="00:10:5A:BE:28:EF"
13 SRV_CABLE_MAC_ADR="00:00:E8:E3:7E:9E"
14 PROJET_CABLE_MAC_ADR="00:10:A4:A5:D3:E5"
15 PROJET_WIFI_MAC_ADR="00:40:05:D0:6C:4C"
16 BRIDGE_MAC_ADR="00:00:E8:E3:7E:9E"
17 BROADCAST_MAC_DEST="ff:ff:ff:ff:ff:ff"
18
19 ESPINASSE="192.168.0.1"
20 PROJET_CABLE="192.168.0.2"
21 PROJET_WIFI="192.168.0.3"
22 SRV="192.168.0.4"
23 MAC_VS_IP="$ESPINASSE_MAC_ADR=$ESPINASSE,$PROJET_CABLE_MAC_ADR=$PROJET_CABLE,$PROJET_WIFI_MAC_ADR=$PROJET_WIFI"
24
25 $EBTABLES -F
26 $EBTABLES -X
27 $EBTABLES -Z
28
29 $EBTABLES -P INPUT DROP
30 $EBTABLES -P OUTPUT ACCEPT
31 $EBTABLES -P FORWARD DROP
32
33 # une chaine pour loger/dropper
34 $EBTABLES -N ERR-MAC-IP
35 $EBTABLES -A ERR-MAC-IP --log-ip \
36 --log-level 6 --log-prefix "NON MATCHING MAC-IP :" -j DROP
37
38 # opérations sur br0
39
40 # ATTENTION : L'ordre de passage par les chaines est :
41 # bridging ?
42 # si oui : forwarding
43 # si non : ebt-filter-input -> routing ?
44 # si oui : ipt-filter-forward -> ebt-filter-output
45 # si non : ipt-filter-input -> processus local -> ipt-filter-output -> ebt-filter-output
46 # donc les ebtables input et output doivent tout laisser passer des machines autorisées
47 # et on filtre vers le parefeu (processus locaux) avec iptables
48
49 # autorise les connexions du pare-feu vers la machine :
50 $EBTABLES -A INPUT -p IPv4 --ip-proto udp -d $BROADCAST_MAC_DEST \
51 --ip-sport 68 --ip-dport 67 -j ACCEPT
52 $EBTABLES -A INPUT -p IPv4 --among-src ! $MAC_VS_IP -j ERR-MAC-IP
53 $EBTABLES -A INPUT -p IPv4 --among-src $MAC_VS_IP -j ACCEPT
54 $EBTABLES -A INPUT -p ARP -j ACCEPT
55 # n'autoriser que la machine ESPINASSE à se connecter sur le pare-feu
56 $IPTABLES -A INPUT -i $bridge -s $ESPINASSE -j ACCEPT
57 $IPTABLES -A OUTPUT -o $bridge -d $ESPINASSE -j ACCEPT
58
59
60 # filtrage du pont
61 # bridging : accepte de laisser passer tout le trafic du cable vers wifi (et vice versa)
62 # dhcp
63 $EBTABLES -A FORWARD -p IPv4 --ip-proto udp -d $BROADCAST_MAC_DEST \
64 --ip-sport 68 --ip-dport 67 -j ACCEPT
65 # blocage des paires mac-ip non valides
66 $EBTABLES -A FORWARD -p IPv4 --among-src ! $MAC_VS_IP -j ERR-MAC-IP
67 # ssh de cable vers wifi seulement
68 # tout le reste est autorisé
69 $IPTABLES -A FORWARD -p tcp -m physdev --physdev-in $wifi --physdev-out $cable --dport $SSH_PORT \
70 -m state --state NEW -j REJECT --reject-with icmp-port-unreachable
71 $IPTABLES -A FORWARD -m physdev --physdev-is-bridged \
72 -m state --state ESTABLISHED,RELATED -j ACCEPT
73 $IPTABLES -A FORWARD -m physdev --physdev-is-in --physdev-is-out -j ACCEPT
74 $IPTABLES -A FORWARD -m physdev --physdev-is-bridged -j LOG --log-level $LOG_LEVEL --log-prefix "BR FORWARD :"
75 $IPTABLES -A FORWARD -m physdev --physdev-is-bridged -j DROP
76
77 $EBTABLES -A FORWARD -i $cable -o $wifi -j ACCEPT
78 $EBTABLES -A FORWARD -i $wifi -o $cable -j ACCEPT


Les premières lignes, 25 à 31 sont connues des utilisateurs d’iptables.

On remarquera, lignes 34 à 36, la syntaxe ebtables pour loger.

Les lignes 50 à 57 filtrent l’accès au parefeu lui-même par les adresses MAC. La syntaxe -among-src permet de spécifier plusieurs paires adresse=ip. On peut faire de même avec -among-dst. Ainsi qu’il est indiqué dans le schéma PacketFlow, la chaine FORWARD de la table filter d’iptables est passée après la chaine INPUT de la table filter d’ebtables. Donc les machines autorisées doivent passer en INPUT. Les lignes 56 et 57 sont donc présentes pour filtrer sur la table filter, chaine INPUT d’iptables, afin de réguler les accès sur le pare-feu.

A partir de la ligne 66, on configure le passage dans le pont. C’est la chaine FORWARD de la table filter d’ebtables qui filtre et permet le passage.

La ligne 63 permet le contact avec le serveur dhcp qui est sur la machine fixe accessible au travers du pont.

La ligne 66 effectue le même filtrage que vu précédemment sur INPUT.

Les lignes 77 et 78 laissent passer tout le traffic qui passe au travers du pont, car pour l’instant seul le traffic ssh est filtré.

J’ai laissé les lignes 69 à 75 qui utilisent iptables car elles
utilisent un module particulier : le module physdev.

– Les lignes 69 et 70 rejettent les demandes de connexion sur le serveur ssh du cable vers le wifi ;
– Les lignes 71 et 72 laissent passer les paquets relatifs à une connexion établie, donc dans les deux sens ;
– La ligne 73 accepte tous les paquets qui entrent par une interface du pont et qui ressortent par une interface du pont (seul le traffic ssh est filtré) ;
– Les lignes 74 et 75 filtrent ce qui reste et qui n’a pas été déjà accepté ou rejeté (en fait il ne devrait rien passer par cette règle).

2 Conclusion

La difficulté dans l’utilisation conjointe d’ebtables et d’iptables est bien dans l’articulation des deux filtres. Car il ne faut pas oublier que les chaines ebtables puis iptables sont traversées successivement.

J’ai tenté de protéger au maximum le réseau en donnant des ip fixes aux machines via le serveur dhcp, et en filtrant sur les correspondances entre adresses MAC et adresses ip. Il serait également possible de restreindre le champ des adresses attribuées aux machines via le serveur dhcp, mais aussi de filtrer sur les adresses MAC au travers de Madwifi (mais je n’y arrive pas sur ma machine, il semble y avoir un problème de mémoire disponible).

Ce qui est présenté ici est fonctionnel chez moi. Mais attention : les règles ebtables et iptables doivent protéger le réseau, et je ne suis pas un gourou du filtrage de paquets. Il convient donc de considérer mes règles avec un certain sens critique (et un sens critique certain).

Ce document est appelé à évoluer : en effet je voudrais installer Dansguardian pour du filtrage parental (mes enfants vont utiliser le portable et une machine à l’étage). De plus l’adsl arrive bientôt dans ma commune…

Contribuer

Code source en .tex disponible, pour améliorer cette modeste contribution.

Le tout joint dans le fichier attaché.

Dernière mise à jour le 6 février 2006 par jm.oltra@wanadoo.fr