Module- 6

Le PARE-FEU
(FIREWALL)
Introduction & Définition
●
Les pares-feu filtrent le trafic indésirable et laisse passer le trafic vers
vos réseaux et à travers vos réseaux.
●
Avec les bonnes règles, vous pouvez bloquer les scanners de ports et
les tentatives de reconnaissance, empêcher les appareils d'être
cooptés dans les attaques DDoS, dépanner les performances du
réseau et collecter des statistiques de trafic.
●
L'implémentation du pare-feu RouterOS est très étroitement liée au
pare-feu Linux iptables. Les deux utilisent en grande partie la même
technologie et la même terminologie, mais RouterOS apporte des
fonctionnalités supplémentaires et des fonctionnalités de gestion.
●
Le pare-feu RouterOS est avec état (statefull firewall), ce qui
signifie qu'il suit les connexions de la source à la destination. Cette
inspection avec état du trafic signifie que chaque type de trafic autorisé
n'a pas besoin d'une règle l'autorisant dans un sens, puis dans l'autre.
●
Un bon exemple de ce comportement est le trafic Webfig via HTTP
depuis un poste de travail informatique ([Link]) vers le
routeur à [Link].
●
Il pourrait facilement y avoir une règle autorisant l'entrée HTTP
uniquement à partir de l'adresse [Link]. Cependant, il n'est
pas nécessaire qu'une règle autorise le retour du trafic HTTP vers le
poste de travail informatique. Avec la logique de pare-feu avec état, le
routeur s'attend à ce qu'il y ait un trafic de retour.
●
Si le trafic HTTP entrant était déjà autorisé, il va de soi que le routeur
devrait être autorisé à répondre. Il est possible de briser ce
comportement en ajoutant une règle de suppression dans la chaîne
de sortie (Output chain) pour HTTP, mais il serait simplement plus
facile de ne pas autoriser le trafic HTTP entrant en premier lieu.
6.1. Les Meilleures Pratiques
●
Pour que vos réseaux restent sécurisés et que les règles de pare-feu ne
deviennent pas trop compliquées, vous devez suivre certaines
directives. Considérez vos opérations réseau dans le contexte de ces
bonnes pratiques:
●
1. Autorisez le trafic dont vous avez besoin, bloquez tout le
reste.
●
2. Consolider les règles si possible pour plus de simplicité.
●
3. Trier les règles pour plus d'efficacité.
●
4. Bloquez tout le trafic à la fin de chaque chaîne avec des
règles finales «fourre-tout».
●
5. Auditez régulièrement les configurations de pare-feu pour en
assurer la cohérence et la sécurité.
●
Rappelez-vous de ces règles de meilleures pratiques tout en
apprenant plus sur les mécanismes des pare-feu sur les équipements
MikroTik.
6.2. Les Composants du Pare-feu
●
Le pare-feu RouterOS utilise trois composants pour contrôler le trafic:
●
(1) Chains ( les Chaînes)
●
(2) Rules (les Règles)
●
(3) Actions (les Actions)
●
Les chaînes sont des mécanismes qui traitent le trafic réseau à
différentes étapes pendant le routage et le pontage.
●
Chaque chaîne comporte des groupes de règles qui filtrent le trafic en
fonction de la source, de la destination, du protocole et d'autres critères
de correspondance.
●
Toutes les règles ont des actions qui leur sont affectées et ces actions
affectent le trafic correspondant à la règle. Ces actions incluent la
suppression (drop), l'enregistrement (log), l'acceptation (accept), le
rejet (reject), etc. La documentation du flux de paquets fournie par
MikroTik, montre à la Figure-6.1, les détails du flux de paquets à travers
les différentes interfaces et chaînes:
 Source de l’image : [Link]

Figure-6.1 : flux des paquets lors d’un routage

6.3. Les Chaînes du Pare-feu (Firewall Chains)
●
Trois chaînes existent par défaut et ne peuvent pas être supprimées:
●
(1) Input ( Entrée)
●
(2) Forward (Acheminement)
●
(3) Output (Sortie)
●
Vous pouvez également créer vos propres chaînes pour un pare-feu et
une surveillance du trafic plus avancés. Chaque chaîne est un groupe de
règles qui traite un certain type de trafic.
6.3.1. La Chaîne INPUT (ENTREE)
●
La chaîne INPUT traite les paquets entrants vers le routeur lui-même.
●
Un exemple de trafic entrant (input ou inbound trafic) serait un
administrateur qui envoie une requête ping à l'interface d'un routeur.
●
Un autre exemple serait une session Winbox vers un routeur.
●
Un diagramme du trafic entrant est présenté à la Figure-6.2.

Figure-6.2 : trafic pour la chaîne INPUT

Affichez toutes les règles de la chaîne INPUT avec la commande
suivante :
[admin@MikroTik]> /ip firewall filter print where chain=input
Flags: X - disabled, I - invalid, D - dynamic
0 D chain=input action=jump jump-target=hs-input hotspot=from-client

1 D chain=input action=drop protocol=tcp hotspot=!from-client dst-port=64872-64875

2 ;;; defconf: accept established,related,untracked

chain=input action=accept connection-state=established,related,untracked

3 ;;; defconf: drop invalid

chain=input action=drop connection-state=invalid

4 ;;; defconf: accept ICMP

chain=input action=accept protocol=icmp

5 ;;; defconf: accept to local loopback (for CAPsMAN)

chain=input action=accept dst-address=[Link]

6 X ;;; defconf: drop all not coming from LAN

chain=input action=drop in-interface-list=!LAN log=no log-prefix=""

Figure-5.4 : Affichage de la liste des règles par défaut de la chaîne INPUT

●
Le trafic entrant doit être bloqué sur les connexions extérieures comme
les liaisons montantes des FAI car les scanners de ports recherchent
constamment des ports ouverts et des services en cours d'exécution.
●
L'accès au routeur via des services tels que SSH et Winbox doit
également être autorisé uniquement à partir de sous-réseaux connus,
de sorte que les administrateurs réseau aient la possibilité d'accéder aux
configurations de périphériques et non quelqu’un d'autre.

Figure-6.3 : Interdiction du trafic INPUT

venant des liaisons montantes FAI
6.3.2. La Chaîne FORWARD (ENTREE)
La chaîne Forward traite les paquets qui passeront à travers un routeur.
Un diagramme du trafic FORWARD (acheminement ou traversée) est
présenté à la Figure-6.4:

Figure-6.4 : trafic pour la chaîne FORWAD

●
Tout trafic destiné à la chaîne FORWARD est du trafic acheminé que
l’équipement MikroTik transfère d'un réseau à un autre. Pendant que le
routeur gère ce trafic, il n’est pas destiné spécifiquement au routeur lui-
même, ce qui signifie les règles de la chaîne INPUT ne s'applique pas
au trafic de la chaîne FORWARD.
●
Sur la plupart des routeurs, la majorité du trafic traité correspond à la
chaîne FORWARD.
●
Répertoriez toutes les règles de chaîne FORWARD du pare-feu avec la
commande suivante:

/ip firewall filter print where chain=forward

 [admin@MikroTik]> /ip firewall filter print where chain=forward
Flags: X - disabled, I - invalid, D - dynamic
0 D chain=forward action=jump jump-target=hs-unauth hotspot=from-client,!auth

1 D chain=forward action=jump jump-target=hs-unauth-to hotspot=to-client,!auth

2 ;;; defconf: accept in ipsec policy

chain=forward action=accept ipsec-policy=in,ipsec

3 ;;; defconf: accept out ipsec policy

chain=forward action=accept ipsec-policy=out,ipsec

4 X ;;; defconf: fasttrack

chain=forward action=fasttrack-connection connection-state=established,related
log=no log-prefix=""

5 ;;; defconf: accept established,related, untracked

chain=forward action=accept connection-state=established,related,untracked

6 ;;; defconf: drop invalid

chain=forward action=drop connection-state=invalid

7 ;;; defconf: drop all from WAN not DSTNATed

chain=forward action=drop connection-state=new connection-nat-state=!dstnat
in-interface-list=WAN

Figure-6.5 : Affichage de la liste des règles par défaut de la chaîne FORWARD

●
1. Règle 0: il s'agit d'une règle dynamique intégrée qui ne peut pas être
supprimée. Il montre combien de paquets ont profité de la fonction
FastTrack.
●
2. Règles 1 et 2: Acceptez le trafic IPSEC dans les deux sens. Ces
règles ne sont pas obligatoires si vous n'utilisez pas de VPN IPSEC.
●
3. Règle 3: Tout le trafic qui est établi ou associé à la connexion
Fasttrack appliquée. Cette action est traitée plus loin.
●
4. Règle 4: Cette règle autorise tout le trafic établi ou associé. Il
fonctionne avec la règle numéro 3 pour réduire l'utilisation des
ressources dans le pare-feu pour les paquets qui sont déjà autorisés.
●
5. Règle 5: Tout trafic non-valide acheminé vers ou hors des réseaux
connectés au routeur est abandonné. Idéalement, très peu ou pas de
trafic du tout devrait correspondre à cette règle.
●
Exigence PCI-DSS numéro 1.3.5 [3, p. 3] est partiellement satisfaite par
cette règle: "Autorisez uniquement les connexions" établies "au
réseau."
 ●
6. Règle 6: La règle finale supprime tout le trafic entrant ou sortant de
l’interface WAN qui n'a pas été traité via le processus NAT. Il s'agit
généralement d'une bonne règle dans la plupart des organisations qui
font du trafic NAT via une seule adresse IP publique attribuée par leur
FAI.

6.3.3. Les Règles par défaut de la Chaîne OUTPUT

●
Listez toutes les règles de la chaîne OUTPUT du pare-feu à l’aide de la
commande suivante :
/ip firewall filter print where chain=output

[admin@MikroTik]> /ip firewall filter print where chain=output

Flags: X - disabled, I - invalid, D - dynamic

Figure-6.6 : affichage de la liste de toutes les règles de la chaîne OUTPUT

Aucune règle par défaut n'est configurée pour filtrer le trafic sortant du
routeur.
L’essentiel à retenir sur les règles du pare-feu embarqué dans le
Système RouterOS de MikroTik :
●
Les règles du pare-feu fonctionnent sur le principe :
● Si <Condition-1=vraie> alors mener <l’action-1>.

Sinon
Si <Condition-2=vraie> alors mener <l’action-2>
….
●
Les règles sont ordonnées par chaînes.
●
Des chaînes prédéfinies existent.
●
Les utilisateurs peuvent créer de nouvelles chaînes
personnalisées.
●
Il existe par défaut, trois chaînes :
●
INPUT : agit sur tout trafic entrant sur une interface du routeur ou
pare-feu.
●
OUPUT : agit sur tout trafic sortant d’une interface du routeur ou
pare-feu.
●
FORWARD : agit sur tout trafic qui doit traverser le routeur ou pare-
feu.
●
Chaque règle possède une action indiquant le traitement que doit
subir le paquet s’il correspond aux critères de sélection d’une règle :
●
Accept : autorise un trafic à passer
●
Drop :supprime silencieusement un trafic)
●
Reject :supprime et renvoie un message de rejet ICMP.
●
Jump :saut vers une chaîne définie par l’utilisateur.
●
Return :retour d’une chaîne définie par l’utilisateur.
6.4. Suivi des connexions – Connection Tracking
●
Les pares-feu RouterOS sont avec état, ce qui signifie qu'ils suivent les
paquets dans le cadre d'un flux global ou d'une connexion.
●
Les paquets dans une connexion qui correspondent à une règle de
pare-feu autorisant le trafic seront autorisés. Les paquets qui ne font
pas partie d'une connexion active mais qui ont des numéros de
séquence falsifiés sont abandonnés ou rejetés. Cette capacité de suivi
des connexions est essentielle à un pare-feu robuste et à la sécurité des
appareils.
●
Le suivi des connexions nous donne également la possibilité de filtrer
et d'analyser le trafic en fonction de son état de connexion.
6.4.1. Les Etats de Connexion – (Connection States)
Chaque paquet fait partie d'une connexion, que cette connexion ne
contienne que quelques paquets ou des millions. Toutes les connexions
existent dans l'un des quatre états possibles:
1. New (Nouveau).
2. Established (Établi).
3. Related (Connexes).
4. Invalid (Invalide).
Des règles de pare-feu peuvent être construites autour de ces états de
connexion pour filtrer efficacement le trafic et enregistrer le trafic suspect.


New Connections (Nouvelles Connexions)
Le premier paquet observé par le pare-feu dans un flux de paquets sera
marqué comme New (Nouveau). Ce paquet sera évalué par les règles de
pare-feu, et s'il est autorisé, le prochain paquet allant dans l'autre sens
dans ce flux créera une connexion établie (Established connection).

Established Connections (Connexions Etablies)
●
Un flux de trafic réseau qui réussit à faire passer les paquets dans les
deux sens à travers le pare-feu est considéré comme établi
(Established).
●
Les autres paquets dans cette connexion ne seront pas évalués par
le pare-feu car les premiers paquets à passer à travers le pare-feu
étaient déjà autorisés. Une vérification supplémentaire des paquets par
le pare-feu serait simplement un gaspillage de ressources puisque le
trafic allant dans les deux sens dans la connexion a déjà été vérifié par
rapport aux règles du pare-feu.

Related Connections (Connexions Connexes)
●
Les paquets marqués comme Related ne font pas partie d'une
connexion elle-même, mais ils sont liés à une connexion.
●
Un exemple mentionné dans la documentation de MikroTik2 est un
paquet ICMP notifiant à l'expéditeur une erreur dans une connexion.
●
Les protocoles comme FTP qui utilisent plusieurs ports peuvent générer
du trafic associé.
●
Le protocole PPTP(Point-To-Point Tunnelling Protocol) est un autre
bon exemple, avec la connexion utilisant à la fois le port TCP 1723 et le
protocole GRE(Generic Routing Encapsulation).
●
Avoir une entrée de pare-feu qui autorise le trafic associé réduit les
règles inutiles.

[Link]

Invalid Connections (Connexions Invalides)
●
Le trafic réseau qui crée des connexions non valides (Invalid
connections) doit presque toujours être supprimé dans le pare-feu.
●
Ces types de paquets peuvent arriver au routeur dans le désordre ou
avec un numéro de séquence invalide.
●
Dans les réseaux de production connectés à Internet, nous rencontrons
souvent des connexions invalides qui sont créées par des scanners
de ports (nmap, …) à la recherche de services ouverts.
●
Un routeur soumis à une utilisation extrême qui perd des paquets
peut également voir le trafic comme non valide car les connexions ne
peuvent pas être correctement initiées.
6.4. Les Actions d’un Pare-feu (Firewall Actions)
●
Les actions d’un pare-feu déterminent ce que le routeur fait réellement
avec les paquets qui correspondent à une règle de pare-feu.
●
Les principales actions sont discutées ici, bien qu'il y en ait d'autres
que d'activer une régulation plus avancée du trafic (advanced trafic
policing).

6.4.1. Accept
●
L'action d'acceptation - Accept permet à un paquet de traverser le
pare-feu. Le paquet ne sera pas traité par d'autres règles et continuera
vers sa destination.
●
Lorsque vous acceptez du trafic sur le pare-feu, assurez-vous de
n'accepter que le trafic nécessaire - tout le reste doit être détruit ou
rejété.
 ●
La commande suivante accepte le trafic ICMP d'un hôte approuvé et
appartenant au segment de surveillance réseau a.b.c.d:
/ip firewall filter add chain=input protocol=icmp
src-address=a.b.c.d action=accept comment="Network Monitoring"

6.4.2. Add-to-Address-List
L’action Add-to-Address-List permet d’analyser le trafic et de recueillir
une adresse IP afin de l’ajouter à une liste d’adresses (address list). Il
s'agit en fait de deux actions distinctes, mais elles ajoutent toutes deux
une adresse IP à une liste d'adresses. Les deux actions individuelles
sont les suivantes:
• add-src-to-address-list : ajoute une adresse IP Source à une liste
d’adresses IP.
• add-dst-to-address-list :ajoute une adresse IP Destination à une
liste d’adresses IP
●
L'exemple de commandes ci-dessous ajoute l'adresse IP source de
tout trafic telnet (TCP, port 23) entrant vers le WAN (ether1) à la liste
d'adresses «Scanners_de_Ports».
●
Aucun réseau en production ne doit avoir le port du protocole Telnet
ouvert sur l'interface WAN, donc toute adresse IP source du trafic
correspondant à cette règle est probablement un analyseur de port qui
est à la recherche de cibles souples. Créez la règle avec la commande
suivante:
/ip firewall filter
add chain=input protocol=tcp dst-port=23 in-interface=ether1
action=add-src-to-address-list address-list="Port_Scanners"

La règle de pare-feu suivante fait référence à cette liste d'adresses et

bloque le trafic entrant sur ether1 :
/ip firewall filter
add chain=input action=drop in-interface=ether1
src-address-list="Port_Scanners" comment="Drop port scanners"
 NOTE

La règle ‘’Drop’’ devrait être placée AU-DESSUS de la règle add-

src-to-address-list afin que les adresses IP qui sont déjà sur la liste
soient immédiatement bloquées, au lieu d’être constamment
réajoutées à la liste.

6.4.3. Drop
●
L'action de suppression - Drop force le routeur à arrêter de traiter un
paquet. Aucune autre action n'est effectuée et le trafic correspondant à
la règle est supprimé en mode silencieux.
●
Il s'agit de la méthode préférée pour supprimer le trafic indésirable.
●
Il est considéré comme une bonne pratique d'accepter le trafic
nécessaire et de supprimer tout le reste avec une règle finale à la fin de
chaque chaîne.
 ●
La règle suivante supprime tout le trafic qui n'a pas déjà été autorisé et
doit être trié jusqu'à la fin de la chaîne:
/ip firewall filter
add chain=input action=drop comment="SUPPRIME TOUT AUTRE TRAFIC"

NOTE
Cette règle est efficace en tant que «fourre-tout» car elle n'a pas de critères - elle
correspond à tous les protocoles, tous les ports, tous les types de trafic..

6.4.4. FastTrack Connection

●
L'action de pare-feu FastTrack est spéciale et son utilisation peut
avoir un impact tangible sur vos routeurs.
●
Une fois qu'une connexion est marquée par FastTrack, tous les futurs
paquets de la connexion ne seront pas vérifiés par rapport au pare-feu.
Si le premier paquet d'une connexion correspond à une règle
d'autorisation (accept), il n'y a aucune valeur à vérifier les paquets qui
suivent.
●
Pour les périphériques à haut débit ou les pare-feu avec de
nombreuses règles, ne pas vérifier chaque paquet peut économiser des
ressources de traitement importantes.
●
La configuration par défaut des pare-feu RouterOS est l’application de
FastTrack sur toutes les connexions dont l'état est établi(Established)
ou associé (Related). Si une connexion a déjà été établie, elle est
passée à travers le pare-feu, donc l’action FastTrack considère que le
reste de la connexion est logique.
●
Les deux règles de pare-feu suivantes fonctionnent ensembles pour les
connexions FastTrack:
/ip firewall filter
add chain=forward action=fasttrack-connection
connection-state=established,related
add chain=forward action=accept
connection-state=established,related
●
Pour cet exemple, le premier paquet d'une connexion passe par le
pare-feu avec succès. Cela crée une session établie (Established)
sur le pare-feu.
●
Le deuxième paquet de cette session établie pour atteindre le pare-
feu correspondra à la première règle pour laquelle action = fasttrack-
connection est définie. À partir de ce moment, le reste des paquets de
la connexion contournera le pare-feu.
 NOTE
Pour de meilleures performances, ces règles (FastTrack) devrait
être placées au dessus de la chaîne FORWARD.

6.4.5. Jump
●
L'action de saut - JUMP prend un paquet en cours d'évaluation et le
déplace vers une chaîne différente.
●
Ceci est souvent utilisé lorsque des chaînes personnalisées ont été
créées avec des règles de pare-feu spéciales. Par exemple, la règle
suivante prend tout trafic de chaîne d'entrée correspondant au
protocole ospf et le fait passer à la chaîne ospf que nous aurions déjà
créée.
/ip firewall filter
add protocol=ospf chain=input action=jump jump-target=ospf

●
Le trafic sera à présent évalué en tenant compte des règles de la
chaîne personnalisée ospf que nous aurions déjà créée.
6.4.6. Log
●
L'action de journalisation - logging ajoute des informations de
source et de destination pour les paquets correspondants au journal
(log) du routeur.
●
Le trafic est transmis à la règle de pare-feu suivante de la chaîne.
Comme pour les règles de relais (passthrough rules), il est
recommandé de désactiver ou de supprimer les règles de
journalisation (log rule) lorsque vous en avez terminé.
●
Sachez que l'action du journal peut créer une quantité importante
d'entrées de journal qui remplissent le stockage d'un périphérique et
provoquent une instabilité.
●
La commande suivante utilise l'action de journalisation pour enregistrer
le trafic SSH entrant:
/ip firewall filter
add chain=input protocol=tcp dst-port=22 action=log
●
La ligne de commande ci-après montre les résultats d’une action de
journalisation des règles d’un pare-feu. Remarquez les données du
journal qui correspondent au critère de la règle précédente (Protocole
TCP, port 22).
[admin@MikroTik] > /log print
[Link] firewall ,info input : in : bridge out :( none), src−mac [Link], proto TCP (SYN),

[Link]:9477−>[Link]:22, len 52

[Link] firewall ,info input : in : bridge out :( none), src−mac [Link], proto TCP (ACK),

[Link]:9477−>[Link]:22, len 40

[Link] firewall ,info input : in : bridge out :( none), src−mac [Link], proto TCP (ACK,PSH),

[Link]:9477−>[Link]:22, len 68

[Link] firewall ,info input : in : bridge out :( none), src−mac [Link], proto TCP (ACK,PSH),

[Link]:9477−>[Link]:22, len 712

[Link] firewall ,info input : in : bridge out :( none), src−mac [Link], proto TCP (ACK,PSH),

[Link]:9477−>[Link]:22, len 64

[Link] firewall ,info input : in : bridge out :( none), src−mac [Link], proto TCP (ACK,PSH),

[Link]:9477−>[Link]:22, len 312

...

[Link] system, error , critical login failure for user admin from [Link] via ssh

[Link] system, info , account user admin logged in via local

●
Pour le dépannage, vous pouvez également spécifier un préfixe de
journal (log prefix) qui ajoute un texte personnalisé au message du
journal. Ceci est utile pour le dépannage et facile à implémenter avec la
commande suivante:
/ip firewall filter
add chain=input protocol=icmp action=log log-prefix="ICMP traffic"

NOTE

Déplacez cette règle de filtre au-dessus de la dernière règle de

suppression (drop) sinon elle ne sera jamais en mesure d’enregistrer
n’importe quel trafic dans le journal du pare-feu.

●
Un exemple d’entrée du journal créée par la règle ci-dessus :
[Link] firewall,info ICMP Traffic! input: in:bridge out:(none),
src-mac [Link], proto ICMP (type 3, code 3),
[Link] -> [Link], len 145
●
Dans les environnements à haute sécurité, il est souvent nécessaire
d'activer la journalisation sur la règle de suppression finale (final Drop
rule) dans chaque chaîne afin que les attaques possibles puissent être
étudiées.
●
Le routeur d'infrastructure STIG [1, Vul. ID V-3000] indique ce qui suit à
propos de la journalisation du trafic abandonné:
”Consultez les ACL (Listes d’Accès) de l'interface du périphérique
réseau pour vérifier que toutes les instructions de refus (deny
statement) sont consignées dans le journal. Si les instructions de refus
ne sont pas consignées, il s'agit d'une constatation. »
6.4.7. Passthrough
●
L'action de relais - Passthorough ajoute le nombre d'octets et de
paquets aux statistiques de la règle, puis permet au trafic de continuer à
être traité. Ceci est utile pour déterminer si un certain type de trafic atteint
votre pare-feu.
●
Désactivez ou supprimez les règles passthrough lorsque vous en
avez terminé afin de ne pas ajouter de surcharge de traitement. La
commande suivante utilise passthrough pour obtenir des informations
de compteur pour le trafic SSH:
/ip firewall filter
add chain=input protocol=tcp dst-port=22 action=passthrough

Pour afficher les statistiques de toutes les règles qui ont pour action
passthrough, employez la commande suivante :
/ip firewall filter print stats where action=passthrough
6.4.8. Reject
●
L'action de rejet – Reject force le routeur à rejeter les paquets
correspondants mais ne le fait pas silencieusement comme le fait
l'action de suppression (Drop). Au lieu de cela, un message ICMP est
envoyé pour informer l'expéditeur que le trafic a été abandonné. Cela
pourrait permettre à un attaquant exécutant des analyses de port de
collecter des signatures digitales de votre appareil et de poursuivre ses
efforts de reconnaissance. Pour cette raison, l'action de rejet - Reject
n'est pas la méthode préférée pour rejeter le trafic indésirable.
●
Certaines normes de conformité comme PCI-DSS et HIPAA exigent
spécifiquement que le trafic indésirable soit silencieusement
abandonné, et non ignoré.
●
À des fins de test, une règle de pare-feu bloquant toutes les requêtes
ICMP de [Link] vers le routeur a été créée et déplacée vers
le haut de la chaîne d'entrée:
/ip firewall filter
chain=input action=reject protocol=icmp src-address=[Link]
La ligne de commandes ci-après affiche le résultat d'un écho ICMP
(ping) qui correspond à la règle qui vient d'être créée.
Resultats d’un Rejet de paquets ICMP (ICMP Packet Rejected)
[admin@MikroTik] > ping [Link]
Pinging [Link] with 32 bytes of data:
Reply from [Link]: Destination net unreachable.

Notez la réponse «Reply from [Link]”. Il s’agit d’un message

ICMP de type trois qui informe un attaquant effectuant une
reconnaissance qu'un périphérique est en ligne avec une sorte de
filtrage. Cet attaquant peut désormais personnaliser davantage les
tentatives de reconnaissance pour démasquer l'appareil. La ligne de
commande montre le résultat de cette même règle et test ping mais avec
l'action de suppression au lieu de rejet.
Resultats d’une Suppression de paquets ICMP (ICMP Packet Drop)
[admin@MikroTik] > ping [Link]
Pinging [Link] with 32 bytes of data:
Request timed out.
 ●
C'est ce que devrait voir un attaquant en effectuant une reconnaissance
- rien du tout. La différence entre les résultats est la raison pour laquelle
il est si important de comprendre les conséquences de l’utilisation de
l’action reject.
●
Pour en savoir plus sur le type de message ICMP, consultez cette
page :
[Link]
meters-types

6.4.9. Return
●
L'action de retour - return renvoie le trafic vers la chaîne à partir de
laquelle il a été initialement sauté (jump).
●
Si vous avez une chaîne spéciale configurée pour l'analyse du trafic
ou le dépannage, vous pouvez renvoyer le trafic vers la chaîne
d'origine afin qu'il soit traité par le reste de ses règles.
6.4.10. Tarpit
●
L'action tarpit maintient les connexions TCP ouvertes et ralentit
délibérément les réponses aux sources de trafic qui correspondent à
une règle de pare-feu. Ces sources de trafic peuvent être des scanners
de ports, des spammeurs ou d'autres types peu recommandables.
Certains fournisseurs d'atténuation DDoS et les grandes entreprises qui
traitent les attaques DDoS utilisent le tarpitting pour les ralentir.
Cependant, avec des botnets comptant des milliers ou des dizaines de
milliers, cela peut avoir une efficacité limitée.
●
Sachez que l'utilisation de tarpit maintient les connexions ouvertes,
donc l'application de cette action sur beaucoup de trafic impose une
charge importante sur un appareil.
6.5. Les Listes d’Adresses – Address List
●
Les listes d'adresses vous aident à consolider et à simplifier les règles
de pare-feu.
●
Elles peuvent également contribuer au processus de documentation du
réseau.
●
Les listes d'adresses sont des objets auxquels les règles de pare-feu
peuvent faire référence, constitués d'hôtes individuels ou de sous-
réseaux entiers. Un exemple de topologie de réseau pouvant utiliser une
liste d'adresses est illustré à la Figure-6.7:

Figure-6.7 :
Topologie pour un
Groupe d’Adresses.
●
Pour créer une liste d'adresses, ajoutez simplement une entrée. Si la
liste n’existait pas avant, elle sera créée automatiquement.
●
La suppression de la dernière entrée dans une liste d'adresses
supprime également la liste.
●
La commande suivante crée une liste d'adresses nommée LAN
contenant trois sous-réseaux, chacun étant un réseau local derrière
un routeur:
/ip firewall address-list
add address=[Link]/24 list="LANs" comment=Ressources_Hum
add address=[Link]/24 list="LANs" comment=Comptabilité
add address=[Link]/24 list="LANs" comment=Entrepos

Chaque réseau a sa propre entrée et commentaire, mais ils font tous

partie de la liste «LANs».
Les entrées peuvent être ajoutées ou supprimées à des listes
d'adresses sans modifier les règles de pare-feu qui les référencent.
Si un nouveau réseau [Link]/24 était mis en ligne, une simple
commande /ip firewall address-list add… ajoutera le réseau à
la liste et toutes les règles de pare-feu s'appliqueront automatiquement.
La commande suivante utilise la liste d'adresses pour autoriser le trafic
vers ether1 à partir de tous ces réseaux:
/ip firewall filter
add chain=forward src-address-list="LANs" out-interface=ether1
action=accept comment="LANs to WAN"

Ce qui aurait pris trois règles au total (une pour chaque réseau) se
fait maintenant en une seule règle. Cette solution évolue vraiment bien
au fur et à mesure que vos réseaux se développent et que le pare-feu
devient plus complexe. Le tri des règles devient également plus facile,
car une seule règle doit être déplacée vers le haut ou vers le bas de la
chaîne de pare-feu au lieu de trois. Ce type de simplicité permet
également d'éviter les erreurs humaines (et les temps d'arrêt).
6.6. Les Commentaires - Comments
●
L'ajout de commentaires aux règles de pare-feu au fur et à mesure de
leur création est une étape importante qui peut faire gagner du temps à
l'avenir avec un effort minimal dans le présent.
●
La mise en place de commentaires pour les règles aide également à
intégrer les nouveaux administrateurs réseau plus rapidement car ils
n'ont pas à comprendre à quoi sert chaque règle.
●
La plupart des exemples cette section de la formation comportent des
commentaires, même s’ils ne sont qu’un seul mot. Les commentaires
doivent être descriptifs - supposez qu’une personne autre que vous, les
lit pendant que vous créez des commentaires. Ils n'ont pas besoin d'être
trop compliqués, mais ils devraient orienter une personne qui ne connaît
pas intimement le réseau dans la bonne direction.
MISE EN GARDE
Evitez les commentaires qui requièrent une documentation
complémentaire pour identifier par exemple ‘’Reseau-1’’ , ‘’Reseau-2’,
‘’Reseau-3’’.
6.7. Le Protocole NAT(Network Address Translation)
●
La traduction d'adresses réseau – NAT(Network Address
Translation) est un protocole réseau dont l’objectif est une
modification de l’adresse IP de la source ou de la destination d'un
paquet à la couche 3 (Réseau) du modèle OSI.
• Il existe deux types de NAT :
●
Source NAT (NAT à la source)
●
Destination NAT (NAT à la destination) encore appelé redirection
de port (Port Forwarding).
●
NAT est généralement utilisé pour fournir l'accès à un réseau externe
à partir d'un réseau utilisant des adresses IP privées (src-nat).
●
Ou pour autoriser l'accès depuis un réseau externe à une ressource
(par exemple, un serveur Web) sur un réseau interne (dst-nat).
SOURCE NAT – NAT à la Source
DESTINATION NAT – NAT à la Destination
●
Les chaînes srcnat et dstnat sont employées pour implémenter la
fonctionnalité NAT.
●
Le fonctionnement des règles NAT est similaire à celui des règles de
Filtrage du pare-feu. Elles fonctionnent selon une structure si
<Condition> alors …
●
L’analyse des règles NAT est faite de façon séquencielle :
●
Lorsque la première règle est analysée et qu’on trouve une
correspondance, on ne passe plus à l’analyse de la règle NAT qui suit.
●
Sinon si la condition de la première règle NAT n’est pas vérifiée, on
passe à l’analyse de la deuxième règle et ainsi de suit.
CAS Pratique de DST-NAT
 REDIRECTION
●
Il s’agit d’un type spécial de DST-NAT.
●
Il s’agit de rediriger les paquets entrant dans le routeur vers le routeur
lui-même.
●
Elle peut être employée pour créer des services de proxy transparent
(ex : proxy DNS, proxy HTTP).
6.8. Ateliers Pratique - AP
AP
AP #1 : Utilisation de la Chaîne INPUT pour un filtrage
●
(1) Créez une règle de filtrage sur la Chaîne INPUT. Cett règle sera
implémentée sur l’interface bridge de votre routeur et autorisera
(accepter) uniquement le trafic venant de l’adresse ([Link].200)
de votre ordinateur.
●
(2) Créez une autre règle de filtrage sur la chaîne INPUT. Cette
deuxième règle sera implémentée sur l’interface bridge toujours et
supprimera (drop) le trafic venant de toute adresse IP qui est
différente de [Link].200.
●
(3) Attribuez une adresse IP statique différente de [Link].200
(par exemple [Link].199), une adresse IP de serveur DNS et
l’adresse IP de la passerelle de votre réseau local à votre ordinateur.
●
(4) Déconnectez votre ordinateur du routeur MikroTik.
●
(5) Essayer de vous connectez au routeur et d’accéder à son interface
de configuration. (Vous verrez qu’il est impossible d’y accéder.)
●
(6) Essayer de vous connectez à Internet. (Vous verrez qu’il est
impossible d’y accéder.)
 AP
●
(7) Bienque le trafic vers Internet soit contrôler par la chaîne FORWARD
du pare-feu, les pages web ne s’ouvrent pas après avoir implémenté ces
premiers filtrage.
●
(8) POURQUOI ? (la réponse se trouvera après la réalisation de l’atelier
pratique suivant).
AP #2 : Utilisation de la Chaîne INPUT pour un filtrage
AP
autorisant le trafic DNS
●
(1) Votre ordinateur passe par le routeur MikroTik pour effectuer la
résolution de nom DNS.
●
(2) Accédez à l’interface de configuration du routeur via Mac WinBox.
●
(3) Créez une règle de filtrage sur la Chaîne INPUT. Cett règle sera
implémentée sur l’interface bridge de votre routeur et autorisera
(accepter) uniquement le trafic contenant les requêtes DNS (protocole
UDP, Numéro de port 53). Placez cette règle d’autorisation du trafic
DNS au-dessus de la règle ‘’drop’’ créée à l’atelier pratique AP#1 .
●
(4) Essayez maintenant d’accéder à Internet. (Succès n’est-ce pas) ?
 AP
AP #4 : Implémentation d’une règle de filtrage via la chaîne
FORWAD
●
(1) Dans cet atelier pratique, nous allons interdire (ou bloquer) le
trafic http dans le réseau.
●
(2) Créez une règle de filtrage pour le protocole HTTP (tcp, port 80).
●
(3) Lors de la spécification des ports TCP, le protocole TCP doit être
sélectionné.
●
(3) Essayez d’accéder à [Link] . (Impossible n’est-ce pas?)
●
(2) Essayez d’accéder la page WebFig du routeur ([Link]
(Succès n’est-ce pas?).
●
(3) POURQUOI l’accès à la page web WebFig du routeur est couronné
de succès ?
Les Ports TCP | UDP qui sont fréquemment utilisés
 AP
AP #5 : Implémentation d’une règle de filtrage sur une
Liste d’Adresses
●
(1) Créez une liste d’adresses IP qui seront autorisées. Assurez-vous
que l’adresse IP de votre ordinateur en fasse partie.
●
(2) Créez une règle de filtrage sur l’interface bridge et ce, sur la
chaîne INPUT pour le port TCP(8291) de WinBox.
Cette règle a pour objectif(action) l’autorisation (accept) du trafic
venant de toute adresse IP qui se trouve dans la liste d’adresses IP
que nous avons créée précédemment.
●
(3) Ensuite, créez une règle d’interdiction (drop) sur la chaîne INPUT
pour toute autre adresse IP qui ne se trouvera pas dans la liste des
adresses IP qui ont été autorisées à accéder à l’interface du routeur
MikroTik via WinBox.
 AP
AP #6 : Fichiers journaux du Pare-feu (Firewall Logs)
●
Chaque événément engendré par une règle du pare-feu peut être
enregistré dans le fichier journal (LOG) lorsqu’il y a une
correspondance.
●
Vous pouvez ajouter un préfixe spécifique à chaque entrée du fichier
journal pour faciliter la recherche à travers les enregistrements plus tard.
●
(1) Activez la journalisation (logging) pour les deux règles de pare-
feu créées au cours de l’atelier pratique sur les Listes d'adresses.
●
(2) Connectez-vous à WinBox en utilisant l'adresse IP autorisée.
●
(3) Déconnectez-vous et changez l'adresse IP de votre ordinateur
portable en une adresse IP qui n'est pas dans la liste autorisée.
●
(4) Essayez de vous connecter à WinBox. (Impossible n’est-ce pas?)
●
(5) Modifiez l'adresse IP de votre ordinateur en reprenant une adresse
IP qui se trouve dans la listed d’adresses IP aurotisées.
●
(6) Accédez de nouveau à WinBox et observez les entrées du journal
(log).
 AP
AP #7 : Fichiers journaux du Pare-feu (Firewall Logs)
●
Chaque événément engendré par une règle du pare-feu peut être
enregistré dans le fichier journal (LOG) lorsqu’il y a une
correspondance.
●
Vous pouvez ajouter un préfixe spécifique à chaque entrée du fichier
journal pour faciliter la recherche à travers les enregistrements plus tard.
 Rendez-vous au
Module 7
pour étudier la
Qualité de Service
QoS (Quality of Service)