OpenBSD
Haute-Disponibilité de fermes Apache et Tomcat
par guiguiabloc le 04 juil, 2008, sous OpenBSD, architecture, linux
Trouver un titre court pour résumer ce billet n’a pas été facile.
Pour détailler un peu plus, je vous propose de mettre un place un Load-balancing croisé entre une ferme de serveurs Apache et une ferme de serveurs Tomcat, le tout bien sûr contrôlé par un système de répartition de charges et d’ip virtuelle.
(nb. Le terme « ferme » désigne un ensemble de serveurs (2 minimum 
). Et puis, Apache… Indien, Plumes, Poule, Ferme, la boucle est bouclée 
… Bon ok, je –>[] )
Un dessin valant mieux qu’un long discours, voici ce que nous allons mettre en place
Oui je sais, je suis un grand malade…
Le principe est le suivant : Nous avons une IP Virtuelle, affectée par le protocole CARP sur un ensemble de 2 serveurs OpenBSD. Nous utilisons « Hoststated » qui est un « vérificateur d’état » pour Packet Filter qui nous permettra de load balancer nos frontaux Apache.
Bien évidemment, j’utilise ce moyen car nous n’avons pas tous un ALTEON chez soi…
En dessous nous aurons notre ferme Apache en mode proxy qui fera du load-balancing sur nos tomcats qui eux, ecouteront en http.
(dans cette architecture, on laisse les Tomcats gérér les contenus dynamiques ET statiques).
- Configuration des Tomcats
Que ce soit un tomcat 5 ou 6, la configuration du connecteur Coyote se fait tout simplement dans le fichier server.xml dans le répertoire conf.
Exemple :
<Connector port="60001"
minProcessors="5"
maxProcessors="64"
enableLookups="false"
scheme="http"
proxyName="monappli.blog.guiguiabloc.fr"
proxyPort="80"
acceptCount="100" debug="0" connectionTimeout="1000"
useURIValidationHack="false" disableUploadTimeout="true" />
<Engine name="Catalina" defaultHost="localhost" jvmRoute="guiguiabloc-a">
<Host name="localhost" appBase="webapps" unpackWARs="true" autoDeploy="true"
xmlValidation="false" xmlNamespaceAware="false">
<Alias>monappli.blog.guiguiabloc.fr</Alias>
<Context path="/guiguiabloc"
docBase="/opt/tomcat-guiguiabloc/webapps/guiguiabloc"
debug="0" privileged="false">
A adapter bien sûr à votre appli tomcat.
Ce qui est important c’est :
- Le « Connector Port » qui est le port http sur lequelle écoute le tomcat (identique sur le deuxième serveur tomcat), ici 60001.
- la JVMRoute qui nous servira pour le balancing (ici « guiguiabloc-a » pour le serveur Tomcat-A et « guiguiabloc-b » pour le serveur Tomcat-B).
Le reste est a peu près classique, il est bon de rajouter un « proxyName » qui nous aidera lorsque l’appli est mal codée… (qui a dit, cela arrive souvent ???)
Il faut créer une page des test dans notre webapp, qui servira au redirecteur principal a vérifier que le Tomcat répond correctement :
Exemple de page test.jsp :
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<%@ page session="false" %>
<HTML>
<HEAD>
<%
response.setHeader("Pragma","No-cache");
response.setDateHeader("Expires",0);
response.setHeader("Cache-Control","no-cache");
%>
</HEAD>
<BODY>
Cette page est utilisée par le frontal pour tester si Tomcat est lancé
</BODY>
</HTML>
Vérifier que cela fonctionne avec un navigateur :
lynx http://monappli.blog.guiguiabloc.fr:60001/guiguiabloc/test.jsp
- Configuration des frontaux Apache
Pré-requis, compiler les modules proxy (j’utilise la version 2.2.8 d’Apache).
N’oubliez pas de les inclure dans votre httpd.conf :
LoadModule proxy_module modules/mod_proxy.so
LoadModule proxy_connect_module modules/mod_proxy_connect.so
LoadModule proxy_ftp_module modules/mod_proxy_ftp.so
LoadModule proxy_http_module modules/mod_proxy_http.so
LoadModule proxy_ajp_module modules/mod_proxy_ajp.so
LoadModule proxy_balancer_module modules/mod_proxy_balancer.so
Etc… (modules mod_rewrite, mod_unique_id, mod_setenvif, mod_logio, mod_log* et d’autres sont nécessaire et dépendent de la façon dont vous travaillez avec Apache).
Un petit peaufinage en fin de fichier :
ProxyReceiveBufferSize 65536
# Capacity configuration
ServerLimit 4096
MaxClients 4096
SetEnv force-proxy-request-1.0 1
SetEnv proxy-nokeepalive 1
Ne reste qu’a configurer vos vhost :
<VirtualHost 192.168.1.1:80> l’ip du web-a
ServerName monappli.blog.guiguiabloc.fr
<Proxy balancer://lbguigui> Un nom unique pour identifier le loadbalancer
BalancerMember http://l’adresse ip du tomcat-a:60001 route=guiguiabloc-a retry=1
connecttimeout=2000 timeout=30 loadfactor=100
BalancerMember http://l’adresse ip du tomcat-b:60001 route=guiguiabloc-b retry=1
connecttimeout=2000 timeout=30 loadfactor=100
</Proxy>
ProxySet balancer://lbguigui stickysession=JSESSIONID|jsessionid nofailover=on
maxattempts=1
Pour des applis PHP, remplacer « JSESSIONID » par « PHPSESSIONID » (si vous gérez les sessions)
On positionne le « nofailover=on » car on ne fait pas de réplication de session
Si vous voulez plus d’informations, je vous invite à consulter le site d’Apache, surtout LA .
Le Proxy via le module Rewrite :
RewriteEngine On
RewriteRule ^(.*)$ $1 [E=request-uri:$1,C]
RewriteRule ^(/.*)$ balancer://lbguigui$1 [P,L]
RewriteRule ^(.*)$ / [R=permanent,L]
PS: Je vous conseille fortement de vous définir votre propre format de log afin de tracer au mieux vos sessions.
Exemple de création de format de Log et de modification des en-têtes :
LogFormat "%h %l %u %t \"%r\" %>s %B \"
%{Referer}i\" \"%{User-Agent}i\" I=%I O=%O %{X-Guiguiabloc-Diag}o
h=web-a r=%{BALANCER_SESSION_ROUTE}e w=%{BALANCER_WORKER_NAME}e D
D=%D C=%X s=%{REDIRECT_STATUS}e
XFF=\"%{X-Forwarded-For}i\"" GuiguiablocLogFormat
CustomLog logs/monappli.blog.guiguiabloc.fr/access.log GuiguiablocLogFormat
ErrorLog logs/monappli.blog.guiguiabloc.fr/error.log
Header set X-Guiguiabloc-Diag "%t %D"
Header set X-Guiguiabloc-Route "h=web-a
r=%{BALANCER_SESSION_ROUTE}e w=%{BALANCER_WORKER_NAME}e"
Header set X-Guiguiabloc-URI "u=%{request-uri}e"
Header append Vary User-Agent
RequestHeader set Host monappli.blog.guiguiabloc.fr
ProxyPreserveHost On
Header set Server "MA FERME H-A"
Header set Cache-Control no-cache="Set-Cookie,Set-Cookie2" env=cacheable-maxage
Header append Cache-Control private env=cacheable-private
Header append Cache-Control max-age=%{cacheable-maxage}e env=cacheable-maxage
Header set Cache-Control no-store env=!cacheable-maxage
Header append Cache-Control no-cache env=!cacheable-maxage
Header unset Set-Cookie env=cacheable-maxage
Header unset Set-Cookie2 env=cacheable-maxage
Header unset ETag
Lire cette partie chez Apache.
- Configuration de la VIP et du load-balancer
J’avais déjà expliquer dans un billet précédent la configuration d’une VIP avec CARP sous OpenBSD, je ne reviendrais donc pas dessus.
La configuration du Load Balancing avec PacketFilter est on ne peut plus simple (comme toujours avec ce bijou 
) :
webA = "192.168.1.1"
webB = "192.168.1.2"
rdr on $ext from any to $VIP port 80 -> {$webA $webB}
table <serveursWeb> persist rdr on $ext from any $VIP port 80 -> <serveursWeb>
Ne reste qu’a ajouter nos serveurs Apache dans la table « serveursWeb » :
pfctl -t serveursWeb -T a 192.168.1.1
pfctl -t serveurWeb -T a 192.168.1.2
Afin de vérifier l’état de nos serveurs Web, nous allons utiliser « Hoststated« . (Sa mise en oeuvre est extrèmement simpliste).
Une petite ancre bien placée dans notre pf.conf :
rdr-anchor "hoststated/*"
Puis on renseigne notre fichier /etc/hoststated.conf :
webA="192.168.1.1"
webB="192.168.1.2"
interval 5 # vérifiation toutes les 5 secondes
table serveursWeb {
check http "/test.jsp" code 200
timeout 300
real port 80
host $webA
host $webB
}
service www {
virtual ip $VIP port 80
table serveursWeb
}
Vous pouvez vérifier l’état de vos serveurs Apache en temps réel :
# hoststatectl show Type Id Name Status service 0 www active table 0 serveursWeb active (2 hosts up) host 1 192.168.1.1 down host 0 192.168.1.2 up
Magique non ?
Le schéma du début avec les IP utilisées pour vous aider à comprendre l’architecture :
J’ai bien évidemment survoler toutes les possibilités que vous offre ce type d’architecture. Je laisse votre esprit désormais en ébullition pour peaufiner le travail et vous plonger dans les MAN et fichiers de configuration des différents outils utilisés ici afin de l’adapter à vos besoins.
Serveur d’authentification TACACS+
par guiguiabloc le 26 juin, 2008, sous OpenBSD, cisco, sécurité
Lorsque l’on commence à avoir un peu de matériel réseau (i.e. Cisco ), il est alors intéressant de centraliser l’authentification et l’autorisation sur ses équipements.
Les serveurs que vous rencontrerez le plus souvent sont les Radius (bien connu des internautes :-p ) et plus spécifiquement à Cisco, Tacacs+.
On peut d’authentifier sur un Cisco de plusieurs façons, soit part un mot de passe local, soit via un serveur Radius, soit via un serveur TACACS+.
C’est cette dernière solution que nous allons mettre en oeuvre.
Je ne rentrerais pas dans les détails concernant L’authentification, l’autorisation et l’accounting (le fameux AAA) ni dans le choix de TACACS+ plutôt que Radius, aussi je vous invite à lire ce très bon article de Ben.
Bien évidemment, j’ai choisi mes serveurs OpenBSD pour y installé Tacacs+.
De plus le package TACACS+ est diponible pour le poisson qui pique ( tacacs+-4.0.4ap1.tgz pour la version 4.3).
Vous le trouverez sûrement pour votre distribution Linux favorite sinon, sur le FTP de Cisco, ftp-eng.cisco.com dans /pub/tacacs .
- Partie Serveur
La configuration se fait dans le fichier /etc/tac_plus.conf.
Nous allons faire une configuration simplifiée qui nous servira a nous authentifier sur nos ciscos avec 2 comptes. Celui de l’administrateur et un compte Opérateur qui nous servira plus tard pour la sauvegarde (dans un futur billet) .
key = maclésecrète (une clé d'échange)
accounting file = /var/log/tacacs
# Le password Enable :
user = $enable$ {
login = des "1234567890"
}
On évitera bien évidement de mettre les mots de passe en clair… L’utilitaire /usr/local/sbin/generate_passwd vous permettra de chiffrer vos mots de passe :
poissonquipique# ./generate_passwd Password to be encrypted:
On défini un groupe « Admin » et un groupe « Operator » :
group = admin {
login = des "AB12GR54RE98"
expires = "Dec 31 2099"
}
group = operators {
login = cleartext "motdepassesupersecret"
expires = "Dec 31 2999"
Ici je mets login = cleartext pour définir un mot de passe en clair (c’est un exemple hein !!!!), crypté toujours vos mots de passe dans vos fichiers de configuration.
user = charlie {
default service = permit
member = admin
}
Je définie l’admin « charlie » qui fait partie du groupe « admin » et qui a tout les droits (default service=permit).
user = lulu {
member = operators
cmd = show { permit ver permit ip }
cmd = traceroute { permit .* }
cmd = logout { permit .* }
}
Je définie l’utilisateur « lulu » (oui je sais j’ai un humour imparable…), membre du groupe « operator » et n’a le droit d’executer que les commandes suivantes :
show version
show ip
traceroute (vers n’importe ou)
logout (vaut mieux )
Ne reste plus qu’a lancer le serveur :
/usr/local/sbin/tac_plus -C /etc/tac_plus.conf
(A rajouter bien sûr dans votre /etc/rc.local et n’oubliez pas non plus d’ouvrir le port 49/tcp dans PacketFilter si vous faites du filtrage).
- Partie Cisco
Sur les routeurs et switchs :
aaa new-model aaa authentication login default group tacacs+ enable
tacacs-server host ipdupoissonquipique tacacs-server directed-request tacacs-server key maclésecrète line vty 0 4 exec-timeout 0 0 password motdepasselocal login authentication default
Sur un Pix 6.3 :
aaa-server TACACS+ protocol tacacs+ aaa-server TACACS+ max-failed-attempts 3 aaa-server TACACS+ deadtime 10 aaa-server TACACS+ (inside) host ipdupoissonquipique maclésecrète timeout 10 aaa-server LOCAL protocol local aaa authentication ssh console TACACS+ LOCAL
Attention : N’oubliez pas de rajouter enable (ou local) a la fin de la ligne aaa authentication, ceci afin de vous permettre de vous identifier quand le serveur TACACS+ est indisponible (enfin, c’est vous qui voyez )
Et voilà, désormais vous pouvez vous logguer sur vos Cisco avec le user « charlie » et le mot de passe associé.
J’ai volontairement simplifié la procédure, il y a énormément d’options possible, d’accounting et d’autorisation que je vous laisse potasser tranquillement
Quelques documents ICI
et LA
Centralisation des logs
par guiguiabloc le 28 mai, 2008, sous OpenBSD, cisco, linux, réseau
Avec l’ajout de nouveaux serveurs, pc, équipements dans votre réseau, la centralisation des logs sur une seule machine devient une évidence.
Passer 1 heure a se connecter en ssh, minicom ou autre sur chaque bestiole pour vérifier les logs devient vite fastidieux et la mise en place d’un « Syslog Host » (terme que j’emploierai pour désigner le serveur de récupération des logs) coule de source.
Heureusement, ce genre de déploiement est assez simple car déjà inclus nativement sur nos Linux / *BSD préféré.
Le choix du serveur de logs n’est pas non plus à prendre a la légère. Outre le volume de données a stocker/traiter, la criticité d’une telle machine ne doit pas être oubliée.
- Vous vous exposez à une « attaque » de type Syslog Bombing
- Certains logs peuvent être sensible et ne pas être donné en pature a n’importe quel lecteur
Prévoyez donc une partition dédiée (type /var/log) suffisamment dimensionnée et réservée aux logs.
Côté sécurité réseau, les flux Syslog utilisent le protocole UDP sur le port 514, a vous donc de positionner vos ACL et/ou règles Firewall en conséquences et bien entendu à ne pas l’exposer au réseau Internet.
L’idéal étant bien évidemment de positionner le SyslogHost dans un VLAN dédié ou vous n’autoriserez que l’UDP port 514 et le SSH depuis le poste de management.
(Petite parenthèse d’humour paranoïaque :
La sécurité ultime étant justement d’utiliser la particularité du protocole UDP qui travaille en mode non-connecté pour couper physiquement le fil TX du câble réseau côté carte du SyslogHost
Bon OK, là c’est vraiment Parano
fin de la parenthèse qui sert à rien)
Activation du démon Syslogd
Sur votre Pingouin, il suffit de rajouter l’option « -r » a Syslog.
Debian Like : /etc/default/syslogd
RedHat Like : /etc/sysconfig/syslog
Relancer syslog.
Sur le Poisson qui pique, ajouter le flag -u dans votre /etc/rc.conf :
syslogd_flags= »-u »
Killer le process Syslogd et relancer le en mode -u : syslogd -u
Un netstat -an | grep 514 vous confirmera l’écoute :
udp 0 0 *.514 *.*
Sur les clients, il suffit maintenant de modifier le fichier /etc/syslog.conf pour lui demander de tout envoyer au Syslog Host :
Ex: *.* @192.168.0.1
Bien sur vous pouvez peaufiner ce que vous voulez envoyer comme logs. (lire cet article par exemple).
N’oubliez surtout pas de configurer la rotation automatique des logs !!!
Avec logrotate.d sur Linux et Newsyslog sur OpenBSD (MAN est votre ami)…
Remontée les logs Cisco
Les Ciscos savent envoyer leurs logs ves un Syslog host.
Sur un routeur :
logging 192.168.0.1
Sur un Pix :
logging host inside 192.168.0.1
Par défaut, les Ciscos envoient leurs logs avec le niveau local.7
Il peut être intéressant de peaufiner le traitement des logs et de séparer les logs « syslog » des machines, des logs équipements.
Pour un Pix par exemple, nous pouvons utiliser le tableau suivant :
|
Facility |
Logging Facility Command Value |
local 0 |
16 |
|
local 1 |
17 |
|
local 2 |
18 |
|
local 3 |
19 |
|
local 4 |
20 |
|
local 5 |
21 |
|
local 6 |
22 |
|
local 7 |
23 |
- Préparons le SyslogHost a recevoir les logs : local3.debug /var/log/cisco.log (dans le syslog.conf)
- Sur le Pix ou le routeur Cisco :
logging trap informational
logging facility 19
Car facility 19 = local 3
NB : Il s’agit simplement d’une traduction du binaire :-p
- 16 = 00010000 = local0
- 17 = 00010001 = local1
- 18 = 00010010 = local2
- 19 = 00010011 = local3
- 20 = 00010100 = local4
- 21 = 00010101 = local5
- 22 = 00010110 = local6
- 23 = 00010111 = local7
On utilise les 4 derniers bits, exemple 22 = 00010110, les 4 derniers =0110 = en décimal 6, c’est du local 6.
Le flag Trap est le niveau de log voulu :
alerts Immediate action needed (severity=1)
critical Critical conditions (severity=2)
debugging Debugging messages (severity=7)
emergencies System is unusable (severity=0)
errors Error conditions (severity=3)
informational Informational messages (severity=6)
notifications Normal but significant conditions (severity=5)
warnings Warning conditions (severity=4)
Les commandes suivantes ne sont pas négligeables à rajouter :
service timestamps log datetime localtime (Cisco routeur)
logging timestamp (Cisco PIX)
Si cela vous amuse vous pouvez également coloriser vos logs qui s’afficheront (voir l’article ICI ).
Traitement des logs
Se coltiner des flux continus de logs qui défilent n’est pas des plus agréables et une information Critique peut vous échapper si vous ne lisez pas vos logs ou ne les traiter pas automatiquement.
Il existe des multitudes de script vous permettant de parser vos logs et d’en extraire les informations essentielles, je vous laisse avec Google pour faire le plein de bonne solution.
Personnellement, comme je l’avais expliqué dans un billet précédent, j’utilise Prelude comme centralisateur d’informations et en installant un module Prelude-LML (LML : Log Monitoring Lackey) sur le SyslogHost, je remonte tout cela sur le Prelude Manager et une bonne moulinette maison me permet d’être alerté en temps réel en cas d’incident.
J’espère que vous prendrez conscience de l’utilité et de l’importance de la centralisation des logs qui n’a été que rapidement approchée dans ce billet mais que vous pourrez étendre beaucoup plus loin (remontée des logs applicatives par exemple (qui a dit Log4j ??? ) etc..
Bon courage
Anatomie d’une architecture (4)
par guiguiabloc le 21 mar, 2008, sous OpenBSD, sécurité
Conception d’un Firewall Rouge en Haute-Disponiblité (2ème Partie)
Je considère que vos deux futures firewalls son prêt, sous OpenBSD et dispose au minimum de 3 cartes réseaux.
CARP est un protocole permettant à un même groupe d’hôtes de partager la même adresse IP.
Il supporte Ipv4 et Ipv6, mais personnellement, je bloque tout les flux ipv6 actuellement.
NB : je vous invite si vous avez le temps à lire l’Ipv6 Security Guide de Juniper.
Si vous avez activé PF (PacketFilter), n’oubliez pas d’autoriser le protocole CARP :
pass out on $carp_dev proto carp keep state
Dans votre fichier /etc/sysctl.conf, ajouter les entrées suivantes :
net.inet.carp.preempt=1
net.inet.carp.allow=1
Pour les insérer à chaud :
# sysctl -w net.inet.carp.allow=1
Maintenant sur chaque Firewall, nous allons créer l’interface CARP côté rouge :
# ifconfig carp0 create
Puis configurer l’interface (dans un fichier également hostname.carp0 pour qu’il soit effectif au reboot) :
#ifconfig carp0 vhid 1 pass motdepasse carpdev sis0 advskew 1 192.168.0.1 netmask 255.255.255.0
Dans le fichier :
inet 192.168.0.1 255.255.255.0 192.168.0.255 vhid 1 carpdev sis0 advskew 1 pass motdepasse
Sur le deuxième Firewall, changer la valeur advskew de 1 à 100.
Explications :
VHID : C’est l’identifiant unique qui unit les deux interfaces du groupe de firewall.
CARPDEV : l’interface sur laquelle monter le CARP
ADVSKEW : Plus grand est ce nombre moins de chance cette interface à d’être le maître au démarrage
ADVBASE (optionnel): délai en seconde de vérification de l’état des cartes (1 seconde par défaut)
Un petit ifconfig sur le maître (advskew = 1) :
carp0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
lladdr 00:00:5e:00:01:01
carp: MASTER carpdev sis0 vhid 1 advbase 1 advskew 1
groups: carp
inet6 fe80::200:5eff:fe00:101%carp0 prefixlen 64 scopeid 0×6
inet 192.168.0.1 netmask 0xffffff00 broadcast 192.168.0.255
Sur l’esclave :
carp0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
lladdr 00:00:5e:00:01:01
carp: BACKUP carpdev em0 vhid 1 advbase 1 advskew 100
groups: carp
inet6 fe80::200:5eff:fe00:101%carp0 prefixlen 64 scopeid 0×6
inet 192.168.0.1 netmask 0xffffff00 broadcast 192.168.0.255
Maintenant, débrancher le cable réseau , arreter le ou un ifconfig carp0 down sur le maître :
# ifconfig carp0 down
#ifconfig
carp0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
lladdr 00:00:5e:00:01:01
carp: INIT carpdev sis0 vhid 1 advbase 1 advskew 1
groups: carp
inet6 fe80::200:5eff:fe00:101%carp0 prefixlen 64 scopeid 0×6
inet 192.168.0.1 netmask 0xffffff00 broadcast 192.168.0.255
Sur l’esclave, vous devriez voir l’interface CARP0 passée en MASTER en 1 seconde et si vous faites un test ping d’une autre machine sur le 192.168.0.1, vous ne devriez quasiment rien voir.
Magique
Mais maintenant vous vous dites, « oui mais si j’ai du trafic sur mon firewall-A ??? » et là je vous réponds « pfsync ».
Pfsync permet de synchroniser les états firewalls entre les deux noeuds du cluster.
Dans la cas d’un basculement, le trafic n’est pas interrompu.
Comme pour CARP, nous autorisons PFSYNC dans nos règles PF :
pass on $sync_if proto pfsync
Sur les deux firewalls, nous dédions une interface réseau à pfsync (les deux FW reliés par un cable croisé par exemple) :
# ifconfig pfsync0 syncdev sis2
# ifconfig pfsync0 up
PS: Cela marche aussi sur un lien série
Par défaut psync fait du multicast. Je vous conseille fortement d’utiliser l’attribut « syncpeer x.x.x.x » pour spécifier l’ip de l’autre Firewall :
# ifconfig pfsync0 syncpeer 192.168.0.5 syncdev sis2
Dans une politique de sécurité poussée, vous devriez utiliser IPsec pour encapsuler les flux psync entre les deux firewalls.
Et voila comment en quelques minutes, vous avez montée un Firewall en haute-disponibilité et entièrement redondant.
Vous ferez les mêmes manipulations côtés pattes Vertes afin d’avoir une HA coté LAN aussi :
+----| WAN/Internet |-------+
| |
sis0| |sis0
+-----+ +-----+
| fw1 |-sis2--------sis2-| fw2 |
+-----+ +-----+
sis1| |sis1
| |
---+----------LAN-----------+---
Nous avons donc maintenant une VIP coté rouge en 192.168.0.1
C’est sur cette IP que vous allez configurér la Freebox en mode… DMZ.
Tout ce qui arrivera sur votre Freebox en entrée, sera redirigé sur votre cluster de Firewall. Ce qui vous permettra de gérer vos translations de port sans avoir à rebooter la Freebox… Ni vos Firewalls d’ailleurs, il est abérant de devoir rebooter un équipement réseau pour appliquer une règle réseau.
NB: Vous pouvez également ne rediriger sur 192.168.0.1 que des plages de porst, l’avantage est de laisser la Freebox bloquer les ports « pourris » (135,139 etc…) et donc d’avoir un premier étage Rouge de blocage.
Ne vous reste plus qu’à configurer votre /etc/pf.conf (le fichier de configuration de PacketFilter) :
Lire PF pour les nuls
Exemple de règle sur une interface CARP :
pass in quick inet proto udp from any to carp1 port 123
Je vous laisse peaufiner votre fichier de configuration PF afin de répondre au mieux à vos propres règles firewall.
A faire, ajouter une autre carte réseau sur vos deux firewalls et monter une interface CARP2 Jaune pour votre DMZ
Petit exemple en dessin :
Prochaine étape, monter le Firewall Vert qui contrôlera les flux inter-vlans et les sorties sur Internet.
