Auto-formation FortiGate I

Objectif : L'objectif de ce lab est de se familiariser avec l'interface Fortigate, de pouvoir effectuer des actions
basiques d'administration et de debug.

Durée : 2h

Prérequis : récupérer le firewall étiqueté « NXP-F-FORTIFORMATION02 ». Cette formation a été rédigée pour
un firewall en version 5.4.4.

I. Reset de configuration
1. Se connecter sur le port LAN du firewall.

2. Récupérer l'IP délivrée par le firewall (dans le réseau 192.168.1.0/24 normalement) et se

connecter sur l’IP 192.168.1.99.

Le login est normalement admin sans mot de passe.

3. Au niveau de la console CLI, lancer la commande.

(La console CLI est disponible dans l’accueil/dashboard de l’interface. Normalement nous utiliserons
une connexion SSH pour avoir accès à la CLI du firewall, mais pour ce lab, l’accès se fera directement
via la WebUI)

execute factoryreset

4. Il est également possible de formater le Fortigate en console :

https://pilotfiber.com/tutorials/restoring-factory-default-onfiguration-on-the-fortinet

5. Attendre que le FortiGate termine le formatage.

6. Se reconnecter en WebUI.
a. IP par défaut : 192.168.1.99

b. Login : admin, mdp : laisser vide

II. Changement de mot de passe et Trusted hosts

1. Dans system Administrator, modifier le mdp du compte admin

1
2. Choisir un mot de passe et bien le noter pour le reste du lab.

3. Cocher Restrict login to trusted hosts et mettre le reseau : 192.168.0.0/16.

Il est absolument primordial de spécifier les trusted hosts sur un environnement de production car
sinon l’accès au prompt d’admin est autorisé depuis n’importe quel réseau et des tentatives de
brute-force peuvent être observées au niveau des logs si le firewall est ouvert sur internet.

III. Modification de l’idle Timeout

La première action à effectuer avant de débuter une configuration de firewall est de modifier l’Idle
TimeOut à 1h afin d’éviter une deconnexion toutes les 5 minutes :

IV. Interfaces physiques/VLAN et zones

Pour administrer un FortiGate (et un firewall de manière générale) il est nécessaire de maitriser les
notions : d'interfaces physique, interface vlan, et de zones.

Interface physique : il s'agit des ports disponibles au niveau du firewall et sur lesquels il est possible
de brancher des câbles.

2
  LAN1
 LAN2
 LAN3
 LAN4
 WAN

Interface VLAN : comme sur les routeurs et switch, il est possible de créer des interfaces VLAN et de
les rattacher à une interface physique.

Pour ce lab, nous allons créer 2 interfaces VLANs rattachés à l’interface physique LAN.

 Serv_Data : 192.168.2.1/24 : VLAN 2

 Serv_ToIP : 192.168.3.1/24 : VLAN 3

Cocher le ping sur l’interface.

Zones : Les zones sont un regroupement d'interfaces VLAN ou physique, qui ont le même besoin de
sécurité. Nous allons pour ce lab créer une zone Serveurs dans laquelle nous allons regrouper les
zones serveurs_bureautique et serveurs_ToIP.

3
Créer la zone avec le blocage intra-zone coché.

Les ouvertures de flux peuvent se faire d'une interface à une autre, mais dès qu'une zone est créée,
il n'est plus possible sur fortinet d'utiliser l'interface pour les ouvertures de flux. L'ensemble des
ouvertures se font avec la zone contenant l'interface.

Il est possible d'activer ou non le filtrage intra-zone dans une zone. Si le filtrage est activé, il est alors
nécessaire de créer une règle de flux au sein de la même zone pour autoriser le trafic d'une interface
à l'autre. Sinon tout le trafic entre les interfaces de la zone est autorisé.

V. Debug flow

Depuis votre poste, tenter de pinger l'interface 192.168.2.1.

L'interface ne devrait normalement pas répondre. Nous allons tenter de débugger pourquoi.

Lancer les commandes suivantes :

 diag debug reset

 diag debug flow filter clear
 diag debug flow filter addr 192.168.2.1
 diag debug flow show console enable
 diag debug flow show function-name enable

Pour les consultants LiveXP, vous retrouverez les commandes de debug dans la page Intranet
suivante : https://intranetxp.netxp.fr/display/infogerance/FortiGate+-
+Commandes+et+outils+de+troubleshooting

Les logs montrent alors le message « check failed on policy 0, drop ».

4
Ce message signifie que le firewall n'a pas les ouvertures nécessaires pour autoriser le trafic.

Le diab debug peut montrer différentes raisons de blocage (manque de route, route retour).

Nous allons autoriser ce trafic.

VI. Ouverture de flux

Créer l'objet NET-Serveurs-Data_192.168.2.0_24.

En temps normal il faut suivre la nomenclature avant de créer un objet.

Rattacher l’objet à la zone serveurs. Sauf cas particuliers il vaut mieux toujours rattacher l’objet créer
à son interface/zone plutôt que de le laisser en ANY.

Créer l'objet NET-LAN_192.168.1.0_24.

5
Créer une policy de LAN vers la zone Serveurs avec en source NET-Serveurs-Data_192.168.2.0_24 et
en destination NET-LAN_192.168.1.0_24 et comme protocole PING.

 Bien décocher le NAT car sinon le firewall effectue un source NAT avec l’IP de l’interface.
 Cocher Log Allowed Traffic : All Sessions afin d’avoir les logs en WebUI.

6
Ne pas hésiter à arrêter le lab et à poser des questions si vous avez des doutes sur pourquoi il est
nécessaire de désactiver le NAT car ce point est extrêmement important pour la compréhension du
comportement du firewall.

Réeffectuer un diag debug et analyser les logs après avoir fait un ping 192.168.2.1.

Cette fois-ci, on voit que le trafic est autorisé :

Les champs importants dans les lignes de logs sont :

 Received a packet from <nom de interface source>

 Allocate a new session
 Find a route : gw- via <interface de sortie>

Remarque : L'ID d’une règle et son numéro de séquence sont différents. Il est possible de faire
apparaitre l'ID en Web UI.

(2) : clic droit sur une des colonnes.

Autres informations pratique pour le débug à faire apparaitre en WebUI :

Bytes : la volumétrie de trafic utilisé par la règle. (on voit d’ailleurs dans l’exemple que la règle ping
vers serveurs Data a bien été utilisée)

Last Used : Montre la dernière date à la quelle la règle a été utilisée. Pratique pour déterminer si une
règle de flux est bien utilisée ou non.

Remarque : Les policies sont traitées par ordre de séquencement. Si un deny est placé au-dessus
d’un allow, c’est le deny qui prendra le dessus.

L’implicit deny est la dernière règle du firewall qui deny l’ensemble du trafic s’il ne match aucune
règle au-dessus.

7
 VII. Diag sniffer
Lancer la commande « diag sniffer packet any 'host 192.168.2.1 » avant de lancer un ping et analyser
le résultat.

Le diag sniffer permet de voir rapidement les interfaces par lesquelles transitent un trafic et si un
host distant répond bien aux requêtes ou non.

VIII. Hardware Switch

Par défaut, les interfaces LAN1, LAN2, LAN3, LAN4 sont regroupés au sein de ce qui est appelé un
hardward switch. Les interfaces jouent alors le même rôle comme si l’on passait par un switch
intermédiaire.
Pour la suite nous allons sortir LAN3 et LAN4 du hardware switch :

IX. Création d’un serveur DHCP

Le FortiGate peut faire office de serveur DHCP. Nous allons configurer un serveur DHCP sur l’interface
LAN3 du firewall.

8
Mettre : 192.168.4.0/24 en IP et cocher la case DHCP Server.

Nous allons également cocher PING et HTTPS. Les services cocher à l’interface déterminent si
l’interface est joignable ou non sur son IP. Ajouter l’HTTPS permettra donc d’accéder au firewall
depuis le port3.

Se brancher alors sur le port3 du firewall et vérifier que l’on récupère bien une IP dans le bon range.

X. Filtrage Intra-zone
Se connecter sur le firewall avec l’IP du port3 : 192.168.4.1

Rajouter l’interface lan3 à la zone serveurs.

Tenter un ping vers l’interface Serv_Data : 192.168.2.1
Le ping ne devrait normalement pas fonctionner.
Décocher la case « Block intra-zone traffic » et retenter le ping 192.168.2.1 qui devrait normalement
passer.

9
Dès qu’une zone contient des interfaces qui n’ont pas besoin de communiquer, il est nécessaire de
cocher le blocage intra-zone.

XI. Sequence View vs Interface Pair View

Il existe deux moyens d’afficher les policies :

Interface Pair View :

Les règles sont regroupées en fonction de la zone source et destination.

Sequence View :

Les règles ne sont pas regroupées mais il est possible de filtrer sur l’interface source ou destination.
Pour effectuer un filtre, il suffit de cliquer sur le from / to / Source / Destination.
A LiveXP, nous utilisons surtout l’interface Pair View.
Il est très important de ne jamais créer de règle avec comme source interface ou destination
interface ANY ou plusieurs interfaces. Il devient alors impossible d’utiliser l’interface Pair View.

XII. Voir/clearer les sessions en cours

Voir les sessions en cours :

Executer les commandes suivantes :

 diag system session filter dst 192.168.4.1

 diag system session list

Il est possible d’effectuer différents filtres (src pour IP source, dst pour IP destination, sport pour port
source etc)

Pour clearer les sessions :

 diag sys session clear

Attention : En ne mettant pas de filtre, l’ensemble des sessions du firewalls sont cleatés de qui
entraine une coupure de toutes les sessions en cours.

10
 XIII. Reset de la configuration
Effectuer de nouveau un reset de la configuration.

11