Ajout de la création du certificat client et aide HAProxy
Pierre Coimbra
parent
faccaeb0d1
commit
44d268e4ee
|
|
@ -0,0 +1,118 @@
|
|||
# Génération du certificat SSL client pour HAProxy
|
||||
|
||||
## Création du premier certificat client
|
||||
### Création du certificat serveur
|
||||
|
||||
```
|
||||
openssl genrsa -des3 -out ca.key 4096
|
||||
openssl req -new -x509 -days 365 -key ca.key -out ca.crt
|
||||
```
|
||||
|
||||
#### Spécification du certificat serveur
|
||||
|
||||
```
|
||||
Country Name (2 letter code) [AU]:FR
|
||||
State or Province Name (full name) [Some-State]:
|
||||
Locality Name (eg, city) []:Valence
|
||||
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Kr[HACK]en
|
||||
Organizational Unit Name (eg, section) []:
|
||||
Common Name (e.g. server FQDN or YOUR name) []:haproxy.krhacken.org
|
||||
Email Address []:contact@krhacken.org
|
||||
```
|
||||
|
||||
### Création de la clé et du CSR du client
|
||||
|
||||
```
|
||||
openssl req -newkey rsa:2048 -nodes -keyout client.key -out client.csr
|
||||
```
|
||||
|
||||
#### Spécification du certificat CSR
|
||||
|
||||
```
|
||||
Country Name (2 letter code) [AU]:FR
|
||||
State or Province Name (full name) [Some-State]:
|
||||
Locality Name (eg, city) []:Valence
|
||||
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Kr[HACK]en
|
||||
Organizational Unit Name (eg, section) []:
|
||||
Common Name (e.g. server FQDN or YOUR name) []:haproxy.krhacken.org
|
||||
Email Address []:contact@krhacken.org
|
||||
|
||||
Please enter the following 'extra' attributes
|
||||
to be sent with your certificate request
|
||||
A challenge password []:
|
||||
An optional company name []:
|
||||
```
|
||||
|
||||
```
|
||||
openssl x509 -req -days 365 -in client.csr -CA ca.crt -CAkey ca.key -set_serial 01 -out client.crt
|
||||
openssl req -newkey rsa:2048 -nodes -keyout haproxy.key -out haproxy.csr
|
||||
```
|
||||
|
||||
### Spécification du certificat Client
|
||||
|
||||
```
|
||||
Ici le CN est ce qui nous authentifira côté serveur
|
||||
|
||||
Country Name (2 letter code) [AU]:FR
|
||||
State or Province Name (full name) [Some-State]:
|
||||
Locality Name (eg, city) []:Valence
|
||||
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Kr[HACK]en
|
||||
Organizational Unit Name (eg, section) []:
|
||||
Common Name (e.g. server FQDN or YOUR name) []:CN_autorisé
|
||||
Email Address []:mail
|
||||
|
||||
Please enter the following 'extra' attributes
|
||||
to be sent with your certificate request
|
||||
A challenge password []:
|
||||
An optional company name []:
|
||||
```
|
||||
|
||||
```
|
||||
openssl x509 -req -days 365 -in haproxy.csr -CA ca.crt -CAkey ca.key -set_serial 02 -out haproxy.crt
|
||||
```
|
||||
|
||||
### Création du certificat pour le navigateur
|
||||
```
|
||||
openssl pkcs12 -export -out haproxy_user.pfx -inkey haproxy.key -in haproxy.crt -certfile ca.crt
|
||||
```
|
||||
|
||||
|
||||
## Génération d'un second certificat
|
||||
```
|
||||
openssl req -newkey rsa:2048 -nodes -keyout haproxy2.key -out haproxy2.csr
|
||||
```
|
||||
### Spécification du certificat Client
|
||||
Ici le CN est ce qui nous authentifira côté serveur
|
||||
|
||||
```
|
||||
Country Name (2 letter code) [AU]:FR
|
||||
State or Province Name (full name) [Some-State]:
|
||||
Locality Name (eg, city) []:Valence
|
||||
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Kr[HACK]en
|
||||
Organizational Unit Name (eg, section) []:
|
||||
Common Name (e.g. server FQDN or YOUR name) []:CN_autorisé2
|
||||
Email Address []:mail
|
||||
|
||||
Please enter the following 'extra' attributes
|
||||
to be sent with your certificate request
|
||||
A challenge password []:
|
||||
An optional company name []:
|
||||
```
|
||||
|
||||
### Certificat pour le navigateur
|
||||
|
||||
```
|
||||
openssl x509 -req -days 365 -in haproxy2.csr -CA ca.crt -CAkey ca.key -set_serial 03 -out haproxy2.crt
|
||||
openssl pkcs12 -export -out haproxy_user2.pfx -inkey haproxy2.key -in haproxy2.crt -certfile ca.crt
|
||||
```
|
||||
|
||||
Il faut maintenant que vous ajoutiez ce certificat à vos certificats Firefox
|
||||
|
||||
### Copie des certificats
|
||||
On copie le certificat pour HAProxy
|
||||
```
|
||||
cp ca.crt /home/hasync/pve.crt
|
||||
scp ca.crt root@10.0.0.7:/home/hasync/pve.crt
|
||||
```
|
||||
|
||||
On met sur l'hyperviseur le certificat client, il faudra ensuite le récupérer via SCP et l'installer dans votre navigateur.
|
||||
|
|
@ -1,22 +1,25 @@
|
|||
# DNS Interne
|
||||
|
||||
Il y a deux types principaux de configurations possible pour les serveurs DNS,
|
||||
Il y a deux types principaux de configurations possible pour les serveurs DNS :
|
||||
- Les serveurs récursif-cache qui servent pour résoudre les adresses.
|
||||
- Les serveurs d’autorité qui servent à faire la correspondance IP-NOM.
|
||||
|
||||
On conseille généralement de ne pas faire les deux sur un même serveur. En effet, une attaque peut être menée sur un serveur récursif ce qui impacterait le service d'autorité. Grâce à la gestion de vu pas de risque vu que seul les container / VM on accès au récursif.
|
||||
On conseille généralement de ne pas faire les deux sur un même serveur. En effet, une attaque peut être menée sur un serveur récursif ce qui impacterait le service d'autorité. Grâce à la gestion de vu pas de risque vu que seul les conteneurs / VM on accès au récursif.
|
||||
|
||||
## Installation
|
||||
Faites par le playbook Ansible.
|
||||
|
||||
```
|
||||
apt-get update
|
||||
apt-get install -y bind9 dnsutils
|
||||
```
|
||||
Création des répertoires nécessaire,
|
||||
```
|
||||
mkdir /var/log/dns/
|
||||
mkdir /etc/bind/zones
|
||||
touch /var/log/dns/query.log
|
||||
touch /var/log/dns/error.log
|
||||
chown bind:bind /var/log/dns/ -R
|
||||
mkdir /etc/bind/zones
|
||||
```
|
||||
|
||||
## Configuration
|
||||
|
|
@ -30,7 +33,12 @@ options {
|
|||
auth-nxdomain no;
|
||||
listen-on { any;};
|
||||
version "V1.0";
|
||||
};
|
||||
forwarders {
|
||||
80.67.169.12;
|
||||
80.67.169.40;
|
||||
};
|
||||
forward only;
|
||||
};
|
||||
logging {
|
||||
channel query_log {
|
||||
file "/var/log/dns/query.log";
|
||||
|
|
@ -54,7 +62,7 @@ logging {
|
|||
## Gestion par vue
|
||||
Pour savoir depuis quelle zone de notre réseau la requête est faites nous allons utiliser les vues de bind9 ainsi le serveur pourra renvoyer une IP différente en fonction de la zone.
|
||||
|
||||
Le serveur aura une pâte sur chaque zone comme décrit ci-dessous,
|
||||
Le serveur aura une pâte sur chaque zone comme décrit ci-dessous :
|
||||
- DMZ -> 10.0.0.253
|
||||
- PROXY -> 10.0.1.253
|
||||
- INT -> 10.0.2.253
|
||||
|
|
@ -82,15 +90,15 @@ view "internalfront" {
|
|||
allow-query-cache {front;};
|
||||
include "/etc/bind/named.conf.default-zones";
|
||||
include "/etc/bind/zones.rfc1918";
|
||||
zone "sessionkrkn.fr" {
|
||||
zone "krhacken.org" {
|
||||
notify no;
|
||||
type master;
|
||||
file "/etc/bind/zones/db.sessionkrkn.fr.front";
|
||||
file "/etc/bind/zones/db.krhacken.org.front";
|
||||
};
|
||||
zone "1.0.10.in-addr.arpa" {
|
||||
notify no;
|
||||
type master;
|
||||
file "/etc/bind/zones/db.sessionkrkn.fr.intrafront.rev";
|
||||
file "/etc/bind/zones/db.krhacken.org.intrafront.rev";
|
||||
};
|
||||
};
|
||||
view "internalback" {
|
||||
|
|
@ -101,29 +109,29 @@ view "internalback" {
|
|||
allow-query-cache {back;};
|
||||
include "/etc/bind/named.conf.default-zones";
|
||||
include "/etc/bind/zones.rfc1918";
|
||||
zone "sessionkrkn.fr" {
|
||||
zone "krhacken.org" {
|
||||
notify no;
|
||||
type master;
|
||||
file "/etc/bind/zones/db.sessionkrkn.fr.back";
|
||||
file "/etc/bind/zones/db.krhacken.org.back";
|
||||
};
|
||||
zone "1.1.10.in-addr.arpa" {
|
||||
notify no;
|
||||
type master;
|
||||
file "/etc/bind/zones/db.sessionkrkn.fr.intraback.rev";
|
||||
file "/etc/bind/zones/db.krhacken.org.intraback.rev";
|
||||
};
|
||||
};
|
||||
```
|
||||
|
||||
### /etc/bind/zones/db.sessionkrkn.fr.front
|
||||
### /etc/bind/zones/db.krhacken.org.front
|
||||
```
|
||||
$TTL 10800
|
||||
@ IN SOA dns.sessionkrkn.fr. dnsmaster.sessionkrkn.fr. (
|
||||
@ IN SOA dns.krhacken.org. dnsmaster.krhacken.org. (
|
||||
2015010101 ; Serial
|
||||
5400 ; Refresh
|
||||
2700 ; Retry
|
||||
2419200 ; Expire
|
||||
300 ) ; Negative TTL
|
||||
IN NS dns.sessionkrkn.fr. ;Nom du serveur
|
||||
IN NS dns.krhacken.org. ;Nom du serveur
|
||||
alpha.fw IN A 10.0.0.1
|
||||
beta.fw IN A 10.0.0.2
|
||||
vip.fw IN A 10.0.0.3
|
||||
|
|
@ -137,16 +145,16 @@ alpha.nginx IN A 10.0.1.3
|
|||
beta.nginx IN A 10.0.1.4
|
||||
```
|
||||
|
||||
### /etc/bind/zones/db.sessionkrkn.fr.back
|
||||
### /etc/bind/zones/db.krhacken.org.back
|
||||
```
|
||||
$TTL 10800
|
||||
@ IN SOA dns.sessionkrkn.fr. dnsmaster.sessionkrkn.fr. (
|
||||
@ IN SOA dns.krhacken.org. dnsmaster.krhacken.org. (
|
||||
2015010101 ; Serial
|
||||
5400 ; Refresh
|
||||
2700 ; Retry
|
||||
2419200 ; Expire
|
||||
300 ) ; Negative TTL
|
||||
IN NS dns.sessionkrkn.fr. ;Nom du serveur
|
||||
IN NS dns.krhacken.org. ;Nom du serveur
|
||||
alpha.haproxy IN A 10.0.1.1
|
||||
beta.haproxy IN A 10.0.1.2
|
||||
alpha.ldap IN A 10.0.2.1
|
||||
|
|
@ -160,49 +168,54 @@ proxyint IN A 10.0.2.254
|
|||
|
||||
INT
|
||||
|
||||
### /etc/bind/zones/db.sessionkrkn.fr.intrafront.rev
|
||||
### /etc/bind/zones/db.krhacken.org.intrafront.rev
|
||||
```
|
||||
REV
|
||||
$TTL 10800
|
||||
@ IN SOA dns.sessionkrkn.fr. dnsmaster.sessionkrkn.fr. (
|
||||
@ IN SOA dns.krhacken.org. dnsmaster.krhacken.org. (
|
||||
2015021102 ; Serial
|
||||
5400 ; Refresh
|
||||
2700 ; Retry
|
||||
2419200 ; Expire
|
||||
300 ) ; Negative TTL
|
||||
@ IN NS dns.sessionkrkn.fr.
|
||||
253 IN PTR dns.sessionkrkn.fr.
|
||||
1 IN PTR alpha.fw.sessionkrkn.fr.
|
||||
2 IN PTR beta.fw.sessionkrkn.fr.
|
||||
3 IN PTR vip.fw.sessionkrkn.fr.
|
||||
4 IN PTR alpha.haproxy.sessionkrkn.fr.
|
||||
5 IN PTR beta.haproxy.sessionkrkn.fr.
|
||||
6 IN PTR vip.haproxy.sessionkrkn.fr.
|
||||
7 IN PTR proxyint.sessionkrkn.fr.
|
||||
10 IN PTR mail.sessionkrkn.fr.
|
||||
3 IN PTR alpha.nginx.sessionkrkn.fr.
|
||||
4 IN PTR beta.nginx.sessionkrkn.fr.
|
||||
@ IN NS dns.krhacken.org.
|
||||
253 IN PTR dns.krhacken.org.
|
||||
1 IN PTR alpha.fw.krhacken.org.
|
||||
2 IN PTR beta.fw.krhacken.org.
|
||||
3 IN PTR vip.fw.krhacken.org.
|
||||
4 IN PTR alpha.haproxy.krhacken.org.
|
||||
5 IN PTR beta.haproxy.krhacken.org.
|
||||
6 IN PTR vip.haproxy.krhacken.org.
|
||||
7 IN PTR proxyint.krhacken.org.
|
||||
10 IN PTR mail.krhacken.org.
|
||||
3 IN PTR alpha.nginx.krhacken.org.
|
||||
4 IN PTR beta.nginx.krhacken.org.
|
||||
```
|
||||
|
||||
|
||||
### /etc/bind/zones/db.sessionkrkn.fr.intraback.rev
|
||||
### /etc/bind/zones/db.krhacken.org.intraback.rev
|
||||
```
|
||||
REV
|
||||
$TTL 10800
|
||||
@ IN SOA dns.sessionkrkn.fr. dnsmaster.sessionkrkn.fr. (
|
||||
@ IN SOA dns.krhacken.org. dnsmaster.krhacken.org. (
|
||||
2015021102 ; Serial
|
||||
5400 ; Refresh
|
||||
2700 ; Retry
|
||||
2419200 ; Expire
|
||||
300 ) ; Negative TTL
|
||||
@ IN NS dns.sessionkrkn.fr.
|
||||
253 IN PTR dns.sessionkrkn.fr.
|
||||
1 IN PTR alpha.haproxy.sessionkrkn.fr.
|
||||
2 IN PTR beta.haproxy.sessionkrkn.fr.
|
||||
1 IN PTR alpha.ldap.sessionkrkn.fr.
|
||||
2 IN PTR beta.ldap.sessionkrkn.fr.
|
||||
3 IN PTR vip.ldap.sessionkrkn.fr.
|
||||
4 IN PTR alpha.nginx.sessionkrkn.fr.
|
||||
5 IN PTR beta.nginx.sessionkrkn.fr.
|
||||
254 IN PTR proxyint.sessionkrkn.fr.
|
||||
@ IN NS dns.krhacken.org.
|
||||
253 IN PTR dns.krhacken.org.
|
||||
1 IN PTR alpha.haproxy.krhacken.org.
|
||||
2 IN PTR beta.haproxy.krhacken.org.
|
||||
1 IN PTR alpha.ldap.krhacken.org.
|
||||
2 IN PTR beta.ldap.krhacken.org.
|
||||
3 IN PTR vip.ldap.krhacken.org.
|
||||
4 IN PTR alpha.nginx.krhacken.org.
|
||||
5 IN PTR beta.nginx.krhacken.org.
|
||||
254 IN PTR proxyint.krhacken.org.
|
||||
```
|
||||
|
||||
Redémarrage de bind9
|
||||
```
|
||||
systemctl restart bind9
|
||||
```
|
||||
|
|
|
|||
|
|
@ -1,16 +1,16 @@
|
|||
# HAProxy
|
||||
Cela consiste en la gestion des flux post firewall.
|
||||
|
||||
## Présentation des containers
|
||||
## Présentation des conteneurs
|
||||
|
||||
Deux containers Debian 10 identiques, un sur Alpha l'autre sur Bêta avec deux interfaces
|
||||
- Sur Alpha le container HAProxy a comme IP 10.0.0.3/24 sur DMZ et 10.0.1.3/24 sur CTF.
|
||||
- Sur Beta le container HAProxy a comme IP 10.0.0.4/24 sur DMZ et 10.0.1.4/24 sur CTF
|
||||
Deux conteneurs Debian 10 identiques, un sur Alpha l'autre sur Bêta avec deux interfaces :
|
||||
- Sur Alpha le conteneur HAProxy a comme IP 10.0.0.6/24 sur DMZ et 10.0.1.6/24 sur CTF.
|
||||
- Sur Beta le conteneur HAProxy a comme IP 10.0.0.7/24 sur DMZ et 10.0.1.7/24 sur CTF
|
||||
L'option Firewall PVE des interfaces est désactivée
|
||||
|
||||
## Objectifs et choix techniques
|
||||
|
||||
Trois objectifs pour la gestion du flux post-firewall
|
||||
Trois objectifs pour la gestion du flux post-firewall :
|
||||
- Redondance du proxy / load balanceur entre les deux nodes.
|
||||
- Séparation des flux (reverse public et reverse ctf).
|
||||
- Load balancing entre deux reverse proxy Nginx public (un sur chaque nodes).
|
||||
|
|
@ -18,37 +18,42 @@ Trois objectifs pour la gestion du flux post-firewall
|
|||
- Vérification du certificat du client et de son CN si tentative de connexion au panel Proxmox (uniquement).
|
||||
|
||||
|
||||
Voici les choix techniques faits afin de répondre à ces objectifs
|
||||
Voici les choix techniques faits afin de répondre à ces objectifs :
|
||||
- Pour le load balancing entre les deux reverse proxy Nginx, on utilisera HAProxy.Le lien sécurisé sera entre l'utilisateur de HAProxy qui soumettra ensuite des requêtes HTTP à un des reverse proxy Nginx.
|
||||
- Pour la redondance du proxy entre les deux nodes, on utilisera keepalived et la technologie VRRP pour garantir la disponibilité du proxy via une ip virtuelle.
|
||||
- Pour la vérification du certificat client - uniquement si le client veut se connecter au panel Proxmox- on fera une première frontend à la couche 4 (TCP) pour les connexions https qui rediregera les connexions vers le panel sur une frontend dédié et le reste vers une frontend par défaut.
|
||||
- Pour les certificats SSL, nous allons utiliser Let's Encrypt avec un serveur Nginx local dédié à l'obtention des certificats et des scripts pour le dépoiement sur les deux containers HAProxy.
|
||||
- Pour les certificats SSL, nous allons utiliser Let's Encrypt avec un serveur Nginx local dédié à l'obtention des certificats et des scripts pour le dépoiement sur les deux conteneurs HAProxy.
|
||||
- La séparation des flux entre les deux reverse public et le reverse ctf ce fera au niveau de la seconde frontend par défaut tout comme le filtrage des requêtes par nom de domaine.
|
||||
|
||||
### Voilà un schéma résumé
|
||||
|
||||
|
||||
|
||||
## Création d'un canal d'échange par clé entre les deux containers
|
||||
Afin de pouvoir faire des scp de manière automatique entre les deux containers, il faut mettre en place une connexion ssh par clé en root entre les deux containers.
|
||||
## Création d'un canal d'échange par clé entre les deux conteneurs
|
||||
Afin de pouvoir faire des scp de manière automatique entre les deux conteneurs, il faut mettre en place une connexion ssh par clé en root entre les deux conteneurs.
|
||||
|
||||
Le procédé est le même, en voici les variantes,
|
||||
- Sur Alpha le container HAProxy aura comme IP 10.0.0.3
|
||||
- Sur Beta le container HAProxy aura comme IP 10.0.0.4
|
||||
Le procédé est le même, en voici les variantes :
|
||||
- Sur Alpha le conteneur HAProxy aura comme IP 10.0.0.6
|
||||
- Sur Beta le conteneur HAProxy aura comme IP 10.0.0.7
|
||||
|
||||
### /etc/ssh/sshd_config
|
||||
Remplacer la ligne concernée par
|
||||
```
|
||||
PermitRootLogin yes
|
||||
```
|
||||
```
|
||||
systemctl restart sshd
|
||||
```
|
||||
|
||||
### Génération et échange de la clé
|
||||
Utilisateur crée par le playbook Ansible
|
||||
```
|
||||
adduser hasync
|
||||
ssh-keygen -o -a 100 -t ed25519 -f /root/.ssh/id_ed25519
|
||||
|
||||
Alpha : ssh-copy-id -i /root/.ssh/id_ed25519 root@10.0.0.4
|
||||
Beta : ssh-copy-id -i /root/.ssh/id_ed25519 root@10.0.0.3
|
||||
Alpha : ssh-copy-id -i /root/.ssh/id_ed25519 root@10.0.0.7
|
||||
|
||||
Beta : ssh-copy-id -i /root/.ssh/id_ed25519 root@10.0.0.6
|
||||
```
|
||||
|
||||
### /etc/ssh/sshd_config
|
||||
|
|
@ -57,28 +62,55 @@ Remplacer les lignes concernées par
|
|||
PermitRootLogin without-password
|
||||
PubkeyAuthentication yes
|
||||
```
|
||||
Il est maintenant possible de se connecter par clé entre les containers
|
||||
```
|
||||
systemctl restart sshd
|
||||
```
|
||||
Il est maintenant possible de se connecter par clé entre les conteneurs
|
||||
|
||||
|
||||
## Installation et configuration de HAProxy sur chaque node
|
||||
|
||||
Le procédé est le même, en voici les variantes,
|
||||
- Sur Alpha le container HAProxy aura comme IP 10.0.0.3
|
||||
- Sur Beta le container HAProxy aura comme IP 10.0.0.4
|
||||
Le procédé est le même, en voici les variantes :
|
||||
- Sur Alpha le conteneur HAProxy aura comme IP 10.0.0.6
|
||||
- Sur Beta le conteneur HAProxy aura comme IP 10.0.0.7
|
||||
|
||||
### Installation
|
||||
Faite par le playbook Ansible
|
||||
```
|
||||
apt-get update
|
||||
apt-get install -y haproxy hatop certbot nginx psmisc
|
||||
systemctl enable haproxy
|
||||
systemctl enable nginx
|
||||
```
|
||||
```
|
||||
rm /etc/nginx/sites-enabled/default
|
||||
rm /etc/nginx/sites-available/default
|
||||
rm /etc/letsencrypt/live/README
|
||||
mkdir -p /home/hasync/letsencrypt-requests
|
||||
mkdir -p /etc/ssl/letsencrypt
|
||||
```
|
||||
|
||||
### Certificat client
|
||||
|
||||
Pour la vérification du certificat du client, la méthode est dans la git. Il faut placer le ca.crt dans /home/hasync/pve.crt et ajouter le CN autorisé dans /home/hasync/allowed_cn.txt
|
||||
|
||||
### Configuration
|
||||
Voilà une rapide explication de la configuration faite
|
||||
- Une première frontend (all-web-in) de type TCP en écoute sur le port 443 qui vérifie si les requêtes tcp sont bien SSL et redirige tout vers la frontend principale via un proxy sauf les requêtes vers la panel Proxmox qui sont redirigées vers la frontend admin via un proxy.
|
||||
### Copie du certificat de la Web UI
|
||||
```
|
||||
Alpha :
|
||||
scp root@10.0.0.1:/etc/pve/local/pve-ssl.key .
|
||||
scp root@10.0.0.1:/etc/pve/local/pve-ssl.pem .
|
||||
|
||||
Beta :
|
||||
scp root@10.0.0.2:/etc/pve/local/pve-ssl.key .
|
||||
scp root@10.0.0.2:/etc/pve/local/pve-ssl.pem .
|
||||
|
||||
Ensuite :
|
||||
cat pve-ssl.key pve-ssl.pem > /etc/ssl/letsencrypt/crt
|
||||
```
|
||||
|
||||
### Configuration
|
||||
Voilà une rapide explication de la configuration :
|
||||
- Une première frontend (all-web-in) de type TCP en écoute sur le port 443 qui vérifie si les requêtes tcp sont bien SSL et redirige tout vers la frontend principale via un proxy sauf les requêtes vers la panel Proxmox qui sont redirigées vers la frontend admin via un proxy.
|
||||
- La frontend principale (user-web-in) de type http écoute sur le ports 80 et le proxy évoqué plus haut. Filtrage des requêtes ne respectant pas le nom de domaine et forçage du https sans www sinon rejet du packet. Redirection des requêtes Let's Encrypt vers un serveur Nginx local dédié aux certifications sinon séparation du flux avec d'un côté une backend s'occupant du load balancing entre les deux reverse proxy Nginx public et de l'autre une backend redirigeant vers le reverse proxy ctf à l'aide du nom de domaine.
|
||||
|
||||
#### /etc/haproxy/haproxy.cfg
|
||||
|
|
@ -118,6 +150,7 @@ frontend all-web-in
|
|||
tcp-request inspect-delay 5s
|
||||
tcp-request content accept if { req_ssl_hello_type 1 }
|
||||
use_backend is-admin if { req_ssl_sni -i pve.krhacken.org }
|
||||
use_backend is-admin if { req_ssl_sni -i opn.krhacken.org }
|
||||
use_backend is-admin if { req_ssl_sni -i rspamd.krhacken.org }
|
||||
default_backend is-user
|
||||
|
||||
|
|
@ -126,7 +159,7 @@ frontend user-web-in
|
|||
bind *:80 interface eth0
|
||||
bind abns@haproxy-user accept-proxy ssl accept-proxy no-sslv3 crt /etc/ssl/letsencrypt interface eth0
|
||||
acl host_letsencrypt path_beg /.well-known/acme-challenge
|
||||
acl authorized_host hdr_end(host) krhacken.fr.fr
|
||||
acl authorized_host hdr_end(host) krhacken.org
|
||||
acl mail hdr_end(host) mail.krhacken.org
|
||||
acl rspamd path_beg /rspamd/
|
||||
acl ctf_host hdr_end(host) ctf.krhacken.org
|
||||
|
|
@ -147,11 +180,13 @@ frontend admin-in
|
|||
mode http
|
||||
bind abns@haproxy-admin accept-proxy ssl no-sslv3 crt /etc/ssl/letsencrypt ca-file /home/hasync/pve.crt verify required interface eth0
|
||||
acl is_auth ssl_c_s_dn(cn) -i -f /etc/haproxy/allowed_cn.txt
|
||||
acl opn hdr_end(host) opn.krhacken.org
|
||||
acl pve hdr_end(host) pve.krhacken.org
|
||||
acl rspamd hdr_end(host) rspamd.krhacken.org
|
||||
use_backend reverse-nginx if { ssl_fc_has_crt } is_auth rspamd
|
||||
use_backend pve-interface if { ssl_fc_has_crt } is_auth pve
|
||||
default_backend drop-http
|
||||
use_backend opn-interface if { ssl_fc_has_crt } is_auth opn
|
||||
default_backend drop-http
|
||||
|
||||
backend is-admin
|
||||
mode tcp
|
||||
|
|
@ -172,15 +207,21 @@ backend pve-interface
|
|||
server pve-alpha 10.0.0.1:8006 check ssl verify none
|
||||
server pve-beta 10.0.0.2:8006 check ssl verify none
|
||||
|
||||
backend opn-interface
|
||||
mode http
|
||||
balance roundrobin
|
||||
server opn-alpha 10.0.0.3:443 check ssl verify none
|
||||
server opn-beta 10.0.0.4:443 check ssl verify none
|
||||
|
||||
backend reverse-nginx
|
||||
mode http
|
||||
balance roundrobin
|
||||
server reverse1 10.0.0.6:80 check
|
||||
server reverse2 10.0.0.7:80 check
|
||||
server reverse1 10.0.1.3:80 check
|
||||
server reverse2 10.0.1.4:80 check
|
||||
|
||||
backend nginx-ctf
|
||||
mode http
|
||||
server nginx-ctf1 10.0.2.5:80 check
|
||||
server nginx-ctf1 10.0.3.3:80 check
|
||||
|
||||
backend drop-http
|
||||
mode http
|
||||
|
|
@ -189,14 +230,7 @@ backend drop-http
|
|||
|
||||
Une fois HAProxy configuré, il faut configurer le serveur Nginx permettant l'obtention des certificats Let's Encrypt.
|
||||
|
||||
```
|
||||
rm /etc/nginx/sites-enabled/default
|
||||
rm /etc/nginx/sites-available/default
|
||||
rm /etc/letsencrypt/live/README
|
||||
mkdir -p /home/hasync/letsencrypt-requests
|
||||
```
|
||||
|
||||
#### /etc/nginx/sites-availables/letsencrypt.conf
|
||||
#### /etc/nginx/sites-available/letsencrypt.conf
|
||||
```
|
||||
server {
|
||||
listen 8164;
|
||||
|
|
@ -204,38 +238,24 @@ server {
|
|||
root /home/hasync/letsencrypt-requests;
|
||||
}
|
||||
```
|
||||
|
||||
```
|
||||
ln -s /etc/nginx/sites-available/letsencrypt.conf /etc/nginx/sites-enabled/
|
||||
```
|
||||
### Démarrage des services
|
||||
```
|
||||
systemctl restart nginx.service
|
||||
systemctl restart haproxy.service
|
||||
```
|
||||
### Obtention des premiers certificats et déploiement
|
||||
```
|
||||
certbot certonly --webroot -w /home/hasync/letsencrypt-requests/ -d sub.krhacken.org
|
||||
```
|
||||
|
||||
Voici un script pour mettre en place les certificats Let's Encrypt au bon endroit qui s'occupe de propager les certificats sur l'autre container.
|
||||
```
|
||||
#!/bin/bash
|
||||
rm -f /etc/letsencrypt/live/README
|
||||
rm -rf /etc/ssl/letsencrypt/*
|
||||
for domain in $(ls /etc/letsencrypt/live); do
|
||||
cat /etc/letsencrypt/live/$domain/privkey.pem /etc/letsencrypt/live/$domain/fullchain.pem > /etc/ssl/letsencrypt/$domain.pem
|
||||
done
|
||||
scp -r /etc/ssl/letsencrypt/* root@10.0.0.3:/etc/ssl/letsencrypt
|
||||
ssh root@10.0.0.3 'systemctl restart haproxy.service'
|
||||
service haproxy restart
|
||||
```
|
||||
|
||||
## Mise en place de la haute disponibilité du load balanceur
|
||||
Voilà la configuration que nous allons mettre en place,
|
||||
- Sur Alpha le container HAProxy aura comme IP 10.0.0.3
|
||||
- Sur Beta le container HAProxy aura comme IP 10.0.0.4
|
||||
- L'IP virtuelle 10.0.0.5 sera attribuée en fonction de la disponibilité des load balanceur
|
||||
Voilà la configuration que nous allons mettre en place :
|
||||
- Sur Alpha le conteneur HAProxy aura comme IP 10.0.0.6
|
||||
- Sur Beta le conteneur HAProxy aura comme IP 10.0.0.7
|
||||
- L'IP virtuelle 10.0.0.8 sera attribuée en fonction de la disponibilité des load balanceur
|
||||
- La node Alpha sera le master et la node Beta sera le Slave
|
||||
|
||||
### Installation (commune au deux nodes)
|
||||
Faites par le playbook Ansible.
|
||||
```
|
||||
apt-get install -y keepalived
|
||||
systemctl enable keepalived.service
|
||||
|
|
@ -260,13 +280,16 @@ vrrp_instance VI_1 {
|
|||
virtual_router_id 51
|
||||
priority 101 # 101 on master, 100 on backup
|
||||
virtual_ipaddress {
|
||||
10.0.0.5 # the virtual IP
|
||||
10.0.0.8 # the virtual IP
|
||||
}
|
||||
track_script {
|
||||
chk_haproxy
|
||||
}
|
||||
}
|
||||
```
|
||||
```
|
||||
systemctl restart keepalived
|
||||
```
|
||||
|
||||
### Configuration sur Beta
|
||||
Comme décrite plus haut
|
||||
|
|
@ -284,29 +307,53 @@ vrrp_instance VI_1 {
|
|||
virtual_router_id 51
|
||||
priority 100 # 101 on master, 100 on backup
|
||||
virtual_ipaddress {
|
||||
10.0.0.5 # the virtual IP
|
||||
10.0.0.8 # the virtual IP
|
||||
}
|
||||
track_script {
|
||||
chk_haproxy
|
||||
}
|
||||
}
|
||||
```
|
||||
```
|
||||
systemctl restart keepalived
|
||||
```
|
||||
|
||||
#### Vérification
|
||||
Le retour de cette commande doit montrer l'adresse IP 10.0.0.5 sur Alpha
|
||||
Le retour de cette commande doit montrer l'adresse IP 10.0.0.8 sur Alpha
|
||||
```
|
||||
ip a | grep -e inet.*eth0
|
||||
```
|
||||
|
||||
## Renouvellement automatique des certificats
|
||||
A partir d'ici la configuration des NAT OPNSense est nécessaire.
|
||||
|
||||
Pour une question de simplicité d'administration, les certificats Let's Encrypt se renouvelleront automatiquement grâce à une crontab. Le problème est qu'un seul des deux containers sera accessible depuis l'extérieur. Il faut donc copier les certificats via scp entre les deux containers.
|
||||
### Obtention des premiers certificats et déploiement
|
||||
A faire sur le Master car c'est lui qui à un accès le DNAT du port 80
|
||||
```
|
||||
certbot certonly --webroot -w /home/hasync/letsencrypt-requests/ -d sub.krhacken.org
|
||||
```
|
||||
|
||||
### /home/hasync/renew.sh
|
||||
Voilà un script d'automatisation à mettre sur les deux containers
|
||||
Voici un script pour mettre en place les certificats Let's Encrypt au bon endroit qui s'occupe de propager les certificats sur l'autre conteneur (depuis Alpha vers Beta). Disponible dans `/root/install-certs.sh` si créer avec Ansible.
|
||||
```
|
||||
#!/bin/bash
|
||||
if [ "$(ip a | grep -c "10.0.0.5")" -ge 1 ]; then
|
||||
rm -f /etc/letsencrypt/live/README
|
||||
rm -rf /etc/ssl/letsencrypt/*
|
||||
for domain in $(ls /etc/letsencrypt/live); do
|
||||
cat /etc/letsencrypt/live/$domain/privkey.pem /etc/letsencrypt/live/$domain/fullchain.pem > /etc/ssl/letsencrypt/$domain.pem
|
||||
done
|
||||
scp -r /etc/ssl/letsencrypt/* root@10.0.0.7:/etc/ssl/letsencrypt
|
||||
ssh root@10.0.0.7 'service haproxy reload'
|
||||
service haproxy reload
|
||||
```
|
||||
|
||||
## Renouvellement automatique des certificats
|
||||
|
||||
Pour une question de simplicité d'administration, les certificats Let's Encrypt se renouvelleront automatiquement grâce à une crontab. Le problème est qu'un seul des deux conteneurs sera accessible depuis l'extérieur. Il faut donc copier les certificats via scp entre les deux conteneurs.
|
||||
|
||||
### /home/hasync/renew.sh
|
||||
Voilà un script d'automatisation à mettre sur les deux conteneurs. Déjà présent si installer avec Ansible.
|
||||
```
|
||||
#!/bin/bash
|
||||
if [ "$(ip a | grep -c "10.0.0.8")" -ge 1 ]; then
|
||||
certbot renew
|
||||
rm -rf /etc/ssl/letsencrypt/*
|
||||
for domain in $(ls /etc/letsencrypt/live); do
|
||||
|
|
@ -316,7 +363,7 @@ if [ "$(ip a | grep -c "10.0.0.5")" -ge 1 ]; then
|
|||
else
|
||||
fi
|
||||
```
|
||||
Le script est stocké dans /home/hasync/renew.sh, voici la crontab à ajouter (crontab -e) sur les deux containers.
|
||||
Le script est stocké dans /home/hasync/renew.sh, voici la crontab à ajouter (crontab -e) sur les deux conteneurs.
|
||||
```
|
||||
0 4 */15 * * /bin/sh /home/hasync/renew.sh >/dev/null 2>&1
|
||||
```
|
||||
|
|
|
|||
|
|
@ -2,12 +2,34 @@
|
|||
|
||||
Nous allons mettre en place un proxy interne pour permettre au services des zones n'ayant pas un accès direct à internet (PROXY, INT, CTF et DIRTY) d'accéder au gestionnaire de packet et à internet (via WGET). Le proxy interne sera dans la zone DMZ, il fera donc le lien entre l'extérieur et les services.
|
||||
|
||||
## Création du conteneur
|
||||
Comme dit dans la partie déploiement, c'est le seul conteneur qu'il faut mettre en place manuellement. Avant de le mettre en place il faut avoir mis en place le réseau et générer la clé SSH du conteneur Ansible.
|
||||
|
||||
Pour mon installation ce conteneur porte le numéro 103.
|
||||
|
||||
Au niveau de la clé SSH, mettez celle que vous avez générer dans le conteneur Ansible. Elle se trouve dans `/root/.ssh/id_ed25519.pub`
|
||||
|
||||
|
||||
Au niveau des ressources allouées :
|
||||
- 2Gb de RAM
|
||||
- 1Gb de SWAP
|
||||
- 24Gb de Stockage
|
||||
|
||||
Au niveau des interfaces réseaux :
|
||||
Firewall toujours désactiver.
|
||||
- eth0: vmbr1 / VLAN: 10 / IP: 10.0.0.9/24 / GW: 10.0.0.254
|
||||
- eth1: vmbr1 / VLAN: 20 / IP: 10.0.1.252/24
|
||||
- eth2: vmbr1 / VLAN: 30 / IP: 10.0.2.252/24
|
||||
- eth3: vmbr1 / VLAN: 40 / IP: 10.0.3.252/24
|
||||
- eth4: vmbr1 / VLAN: 50 / IP: 10.0.4.252/24
|
||||
- eth0: vmbr2 / VLAN: 100 / IP: 10.1.0.103/24 / GW: 10.1.0.254
|
||||
|
||||
## Apt Cacher NG
|
||||
Pour l'accès au gestionnaire de packet nous allons utiliser Apt-Cacher NG.
|
||||
|
||||
### Installation
|
||||
```
|
||||
apt-get install apt-cacher-ng -y
|
||||
apt-get install -y apt-cacher-ng
|
||||
```
|
||||
```
|
||||
Allow HTTP tunnel throutgt Apt-Cacher NG? -> No
|
||||
|
|
@ -16,7 +38,7 @@ Allow HTTP tunnel throutgt Apt-Cacher NG? -> No
|
|||
### /etc/apt-cacher-ng/acng.conf
|
||||
```
|
||||
Port: 9999
|
||||
BindAddress: 10.0.1.254 10.0.2.254 10.0.3.254 10.0.4.254
|
||||
BindAddress: 10.0.1.252 10.0.2.252 10.0.3.252 10.0.4.252
|
||||
```
|
||||
```
|
||||
systemctl restart apt-cacher-ng.service
|
||||
|
|
@ -59,15 +81,15 @@ systemctl restart squid.service
|
|||
Squid est maintenant accessible depuis le port 3128 du proxy interne uniquement depuis les zones PROXY, INT, CTF et DIRTY. Les requêtes depuis d'autres zones seront rejetées.
|
||||
|
||||
|
||||
## Accès au Proxy Interne depuis un container ou une VM
|
||||
## Accès au Proxy Interne depuis un conteneur ou une VM
|
||||
|
||||
Les outils principaux sont WGET et APT-GET on va donc les reliées au Proxy Interne.
|
||||
|
||||
Le proxy interne sera accessible uniquement depuis les zones PROXY, INT, CTF et DIRTY voilà l'ip du proxy en fonction de la zone
|
||||
- PROXY (VLAN 20) -> 10.0.1.254
|
||||
- INT (VLAN 30) -> 10.0.2.254
|
||||
- CTF (VLAN 40) -> 10.0.3.254
|
||||
- DIRTY (VLAN 50) -> 10.0.4.254
|
||||
Le proxy interne sera accessible uniquement depuis les zones PROXY, INT, CTF et DIRTY voilà l'ip du proxy en fonction de la zone :
|
||||
- PROXY (VLAN 20) -> 10.0.1.252
|
||||
- INT (VLAN 30) -> 10.0.2.252
|
||||
- CTF (VLAN 40) -> 10.0.3.252
|
||||
- DIRTY (VLAN 50) -> 10.0.4.252
|
||||
|
||||
### WGET
|
||||
Les requêtes passerons désormais par le proxy interne sur le port 3128 pour les requêtes http et https. Seul le root aura accès au proxy.
|
||||
|
|
|
|||
Loading…
Reference in New Issue