Aller au menu - Aller au contenu

Icône Les interfaces réseau

Avatar
Mise à jour : 04/08/2011
Difficulté : Facile Facile Creative Commons BY-NC-SA
7 018 visites depuis 7 jours, dont 76 sur ce chapitre classé 32/786
Un serveur est là pour ... servir des clients. C'est vrai dans un café, et aussi entre ordinateurs. Cela implique que les ordinateurs communiquent entre eux. On peut les relier les uns aux autres par des fibres optiques, des cables ethernet, les ondes de la Wi-Fi, etc.
Sommaire du chapitre :
Icône du chapitre
Chapitre précédent Sommaire Chapitre suivant

A - Adresses, ports et sockets

Les interfaces réseau sont les portes de votre ordinateur : elles lui permettent de communiquer avec le reste du monde.

Image utilisateur


Votre machine a donc plusieurs portes mais, ce que vous ne savez peut-être pas, c'est que chacune a une adresse différente. En plus de votre adresse publique, accessible en vous connectant au site whatsmyip, vous avez donc aussi plusieurs adresses locales. Dans ce chapitre, nous ne parlerons que de ces dernières.

Tapez ifconfig dans un terminal pour en savoir plus sur vos interfaces réseau.

Image utilisateur

Même sur un système simple, il y a toujours au moins deux interfaces réseau. Sur la capture d'écran ci-dessus, vous voyez rl0 et lo0.

Pourquoi ces deux là ? J'en compte cinq, moi.


fwe0, fwip0 et plip0 ne sont pas de vraies interfaces. Vous voyez que dans leur liste de drapeaux (flags), il n'y a pas le drapeau UP. Et elles n'ont pas non plus d'adresse locale (inet).

lo0 (adresse locale 127.0.0.1) correspond à ce qu'on appelle la boucle locale : c'est une connexion entre l'ordinateur et... lui-même. Eh oui ! Je ne sais pas quel âge a votre machine, mais sachez qu'il lui arrive fréquemment de parler toute seule. :D Cela vous a déjà servi pour communiquer avec CUPS.

L'autre interface (adresse locale 192.168.1.38 dans mon cas) n'a pas forcément le même nom chez vous. Tout dépend du modèle de votre carte réseau. Chez moi, c'est rl0. Chez vous, c'est peut-être em0, re0 ou autre chose. Dans la suite du chapitre, chaque fois que j'écrirai rl0, rectifiez par le nom de votre interface à vous.

Image utilisateur


Vous voyez sur ce schéma qu'il n'y a pas vraiment de barrière entre internet et les précieuses données que renferme votre ordinateur. La moindre des choses, c'est d'installer un pare-feu, qui filtrera les données. Et sous FreeBSD, il y a une deuxième ligne de défense : la prison.

Vous allez installer un serveur web sur votre ordinateur, afin de créer votre propre site. Bientôt, les visiteurs afflueront dessus par milliers (mais si, soyez un peu optimistes ;) ). Comment être certain que toutes ces requêtes sur votre serveur n'endommageront :waw: pas le reste de votre machine ? Ou encore qu'un pirate :pirate: qui parviendrait à s'introduire dans le serveur ne puisse pas aller plus loin ?

Réponse : en établissant une cloison étanche entre le serveur et le reste. C'est à dire, en mettant le serveur dans une prison, qui aura sa propre interface réseau, différente de celles de votre système principal.


Image utilisateur


Le problème, c'est qu'il faut maintenant trier les données en provenance d'internet. Il y en a qui ne doivent pas passer, d'autres qui doivent être acheminées vers votre serveur HTTP (donc vers lo1) et d'autres encore sont destinées à votre système principal via rl0. Comment faire pour s'y retrouver ?

Ces données qui circulent sur internet sont appelées des paquets (packets en Anglais). Elles n'ont cependant rien à voir avec les paquets (packages en Anglais) dont vous vous servez (ou pas) pour installer des logiciels. Pour éviter toute ambiguité, j'écrirai donc le mot paquets en rouge chaque fois que je parlerai d'elles.

Pensez aux vrais courriers papiers. Chacun comporte l'adresse de son destinataire, un contenu et l'adresse de l'expéditeur. De même, chaque paquet comporte, en plus de son contenu, un ensemble de quatre numéros, qu'on appelle un socket. Parmi ces quatre numéros, il y a l'adresse IP de l'ordinateur d'origine, celle de l'ordinateur destinataire,...

Bah, c'est bon, alors... Si l'adresse IP du destinataire est 192.168.1.38, on envoie vers rl0 et si c'est 127.0.0.1, on envoie vers lo1.


Si seulement la vie pouvait être aussi simple ! Mais l'adresse de destination indiquée dans le paquet est en réalité votre adresse publique ! Ce n'est donc ni l'adresse locale de rl0 ni celle de lo1. Impossible de s'en servir pour faire le tri. :( Heureusement, :) le socket comporte deux autres informations : des numéros de ports.

Je précise que ces ports-là (du mot porte) n'ont rien à voir avec les ports (du verbe porter) dont vous vous servez (ou pas) pour installer des logiciels. Pour éviter toute ambiguité, j'écrirai donc le mot ports en rouge chaque fois que je parlerai d'eux.

C'est bon ? Pas trop embrouillés ? o_O Je vous explique.

Les ports sont numérotés. Par exemple, les ports 20 et 21 concernent les communications FTP, dont nous avons déjà parlé. Vous connaissez aussi 631, le port de CUPS. 22 est consacré aux connexions sécurisées de type SSH. Les serveurs DHCP, qui attribuent automatiquement les adresses aux autres machines, se servent des ports 67 et 68.

Votre futur serveur HTTP, quant à lui, utilisera les ports 80 et 443.

Donc, lorsqu'un internaute cherchera à contacter votre futur serveur web, il lui enverra des paquets dont les sockets comprendront :

  • Votre adresse IP publique.
  • Son adresse IP publique.
  • Le numéro de port de votre serveur web.
  • Le numéro de port du programme expéditeur.

La solution, par conséquent, c'est de demander à votre pare-feu de détourner vers lo1 tous les paquets destinés aux ports 80 et 443.

Image utilisateur

Bon, là, j'ai un peu simplifié. Il est évident que votre prison pourra recevoir d'autres communications que celles des ports 80 et 443, notamment quand c'est elle qui cherchera à joindre un serveur extérieur.

Il n'est pas indispensable de mettre votre serveur dans une prison. Un pare-feu peut suffire. Mais pourquoi se priver de cette merveilleuse fonctionnalité de FreeBSD ?


B - Wi-Fi

Avec la Wi-Fi, les ordinateurs peuvent aussi communiquer par la seule magie des ondes électromagnétiques. :magicien:

Si votre machine dispose d'une connection Wi-Fi, elle peut être activée à l'aide de trois fichiers de configuration : /boot/loader.conf, /etc/rc.conf et /etc/wpa_supplicant.conf. On ne présente plus les deux premiers. Quant au troisième, c'est vous qui allez l'écrire.

Voyons d'abord si FreeBSD a détecté votre carte Wi-Fi. Le programme ifconfig ne demande qu'à vous renseigner. Parmi les interfaces réseau, il vous affichera quelque chose comme :

Code : Console
ath0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 2290
        ether f0:7b:cb:57:1b:d5
        media: IEEE 802.11 Wireless Ethernet autoselect mode 11b
        status: associated


Le votre ne commence peut-être pas par ath0 mais la présence du mot Wireless vous indique qu'il s'agit bien de l'interface Wi-Fi. FreeBSD dispose donc du pilote nécessaire pour la faire fonctionner. En principe, il dispose de tous les pilotes pour toutes les cartes Wi-Fi courantes. Mais si la votre est plus atypique, il est possible qu'il ne la détecte pas.

Sachez, dans ce cas, qu'il existe une astuce (à la section 11.8.1.1) pour faire fonctionner sous FreeBSD le pilote Windows (à récupérer sous Windows). Je n'ai pas testé. Par ailleurs, si vous avez activé la compatibilité binaire avec Linux (voir le chapitre Multimédia), le pilote Linux (s'il existe et si vous l'avez) devrait fonctionner.

Mais attention : ce n'est pas parce que votre interface est détectée qu'elle est prise en charge pour autant. Il faut pour cela charger dans le noyau le module adéquat. Ajoutez donc au fichier /boot/loader.conf, la ligne :

Code : Console
if_ath_load="YES"


Naturellement, si votre pilote à vous n'est pas ath, rectifiez en conséquence. Par exemple, si votre interface s'appelle wi0 au lieu de ath0, écrivez if_wi_load="YES". Idem pour toute la suite de ce paragraphe consacré à la Wi-Fi.


De plus en plus souvent, les communications Wi-Fi sont cryptées. Vous aurez donc besoin, toujours dans /boot/loader.conf, de l'instruction :

Code : Console
wlan_wep_load="YES"

Sur un réseau local peu sécurisé, qui utilise un chiffrage de type WEP, c'est suffisant. Mais rien n'est plus facile, pour tout pirate :pirate: un peu sérieux, que de craquer un WEP. Des systèmes plus sophistiqués ont donc été mis au point, comme le chiffrage WPA et ses variantes. Par conséquent, vous devez ajouter :


Code : Console
wlan_ccmp_load="YES"                                                                                                                                                                            
wlan_tkip_load="YES"


Je vais continuer en prenant l'exemple du cryptage WPA : c'est maintenant le plus répandu (et c'est celui-là que j'ai). Vous allez vous identifier à l'aide du fichier /etc/wpa_supplicant.conf. Créez-le avec l'éditeur de votre choix et écrivez :

Code : Console
network={
  ssid="NEUF_2200"
  psk="motdepasseduréseau"
}

En remplaçant évidemment NEUF_2200 par le nom de votre réseau Wi-Fi local. Le mot de passe psk est inscrit sur votre "box" ou dans sa documentation.

Passons enfin au fameux rc.conf, où vous ajouterez ces lignes :

Code : Console
wlans_ath0="wlan0"
ifconfig_wlan0="WPA DHCP mode 11n"


Là, quelques explications s'imposent. WLAN est le Wireless Local Area Network (Réseau local sans fil). Vous vous connectez à lui via l'interface ath0. La première ligne ci-dessus va créer une interface fictive wlan0, associée à ath0. La deuxième ligne configure wlan0 en confiant à DHCP l'attribution d'une adresse IP et en précisant que le cryptage local est de type WPA.

Et le mode 11n ?


Le protocole Wi-Fi s'appelle aussi 802.11 et il comporte plusieurs variantes, avec des fréquences et des performances diverses. Par défaut, ath0 est en mode 11b, comme le montre le ifconfig un peu plus haut. Mais le mode 11n permet un meilleur débit.

La prochaine fois que vous allumerez votre ordinateur portable, ouvrez un navigateur web et surfez tant qu'il vous plaira... sans fil ! :)

C - Le pare-feu

Packet Filter (pf pour les intimes) n'est pas n'importe quel pare-feu. C'est la grande fierté d'OpenBSD, son OS d'origine, et certainement l'un des meilleurs qui soient. Avec Packet Filter d'un côté et ses prisons de l'autre, FreeBSD est donc ultra-sécurisé ! A condition, bien sûr, de le configurer correctement. ;)


Image utilisateur


Pour en profiter, il faut bien sûr l'activer en ajoutant à notre cher /etc/rc.conf :

Code : Console
pf_enable="YES"
pf_rules="/etc/pf.conf"


Et il faut aussi le configurer :

Code : Console
[Nom de l'ordinateur]# emacs /etc/pf.conf


Vous allez définir dans ce fichier les règles qui indiquent quels paquets refuser, accepter ou rediriger. Vous commencerez par tout bloquer avec :

Code : Console
block in  all
block out all

Puis vous ajouterez des règles pour autoriser au cas par cas les services dont vous avez besoin. La documentation d'OpenBSD explique très bien comment.

En attendant, ce n'est pas l'aspect sécurité qui nous intéresse. C'est plutôt l'acheminement du traffic internet vers les interfaces rl0 et lo1. Trois instructions suffisent pour ça. Commentez donc provisoirement les deux lignes block all.

Code : Console
nat on rl0 from lo1:network to any -> (rl0)
rdr pass on rl0 inet proto tcp to port http -> 10.1.1.1 port http
rdr pass on rl0 inet proto tcp to port https -> 10.1.1.1 port https

Je rappelle qu'il vous faut personnaliser ces lignes si votre interface réseau principale n'est pas rl0. Veillez bien à ce que pf.conf ne contienne, pour l'instant, aucune autre instruction (à part les commentaires qui, vous le savez, sont ignorés). S'il y en a, commentez-les.

nat (Network Address Translation) est le système de traduction d'adresse réseau. Il permet à la prison de solliciter des communications avec l'extérieur.

rdr, lui, redirige le traffic destiné aux ports 80 (http) et 443 (https) de l'adresse inet de rl0 vers ceux de 10.1.1.1 (l'adresse inet de lo1). Cette redirection fait intervenir le protocole TCP/IP, celui qui permet les échanges de données sur internet, et qui a d'ailleurs été développé sous BSD.


Il va maintenant falloir créer la prison. Et ce n'est pas une mince affaire. La première étape consiste en effet à recompiler FreeBSD.
Chapitre précédent Sommaire Chapitre suivant

Partager

14 commentaires pour "Les interfaces réseau"
Note moyenne : 3.71 / 4 (299 votes)
Pseudo Commentaire
Hors ligne Brice Errandonea # Posté le 02/08/2011 à 10:49:22
Avatar
Groupe : Auteurs

Non, la syntaxe du cours n'est pas obsolète (pas sous FreeBSD, en tout cas). Essaie d'écrire directement :

nat on rl0 from lo1:network to any -> (rl0)

A condition, bien sûr, que tes interfaces à toi s'appellent bien rl0 et lo1.

Ceci dit, ton problème semble davantage porter sur l'ordre des règles. Tu en a mis 25 ? Cette règle fait partie du groupe "translation". Elle doit donc être écrite avant celles du groupe "filtering".
Hors ligne Bilbax # Posté le 03/08/2011 à 22:17:26
www.bilbax.com
Avatar

Avis : Très bon

Ville : Saint-pierre
Pays : Saint-Pierre-et-Miquelon

Non je n'en ai pas mis 25 ^^ c'est à cause de l'organisation du fichier, que voici :

Code : Autre
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
#### Variables
eth_if = "rl0"
www_if = "lo1"


#### Tables
table <banned> persist file "/etc/pf/banned"

#nat on $eth_if from $www_if:network to any -> ($eth_if)
nat on rl0 from lo1:network to any -> (rl0)

#### Rules
set skip on lo0
block in quick from <banned>
block in quick from urpf-failed

block in on $eth_if all

pass in on $eth_if proto tcp to any port 22 
pass in on $eth_if proto { tcp udp } to any port 53

pass out on $eth_if proto { tcp udp icmp } all modulate state


Tu verras que je l'ai déplacé, en effet, il fallait la mettre avant les règles de filtrage.

Par contre ça ne marche toujours pas (test avec dig). :(


“What gets us into trouble is not what we don’t know, it’s what we know for sure that just ain’t so.”
      — Mark Twain
 
Hors ligne Brice Errandonea # Posté le 04/08/2011 à 11:59:34
Avatar
Groupe : Auteurs

Je vois que tu n'as pas mis les instructions de redirection :

Code : Console
rdr pass on rl0 inet proto tcp to port http -> 10.1.1.1 port http
rdr pass on rl0 inet proto tcp to port https -> 10.1.1.1 port https


Essaie avec.

Si ça ne fonctionne toujours pas, essaie de désactiver temporairement tes règles de filtrage pour voir si ça permet à dig de passer.
Hors ligne Bilbax # Posté le 04/08/2011 à 17:55:21
www.bilbax.com
Avatar

Avis : Très bon

Ville : Saint-pierre
Pays : Saint-Pierre-et-Miquelon

Shame on me, j'ai oublié de spécifier un serveur DNS dans le resolv.conf. :D dig arrive maintenant à contacter le monde extérieur, merci. :)

Par contre, rediriger les ports n'y aurait évidemment rien changé. ^^


“What gets us into trouble is not what we don’t know, it’s what we know for sure that just ain’t so.”
      — Mark Twain
 
Hors ligne Titox31 # Posté le 15/02/2012 à 13:22:09
Avatar

Avis : Bon

J'ai un problème lors de l'installation http://www.siteduzero.com/forum-83-736 [...] t-pc-bsd.html

Voir tous les commentaires