[{"body":"","link":"https://juni2dev.github.io/labs/","section":"labs","tags":null,"title":"Labs"},{"body":"","link":"https://juni2dev.github.io/","section":"","tags":null,"title":"NetSec Core"},{"body":"Déploiement d’instance sur Splunk\nSplunk offre la possibilité d’adapter le déploiement en fonction de nos exigences ainsi, on peut soit faire endosser toute la gestion à une seule instance on parle de « single-instance » ou bien distribuer notre déploiement en plusieurs instances auxquelles on spécifiera une fonction bien déterminée. D’un autre point de vue, l’aspect taille de l’infrastructure à monitorer peut aiguiller le choix d’un mode au détriment d’un autre.\nTrois interrogations sont à prendre pour un choix pertinent :\nLa taille de l’infrastructure et la complexité des données à manipuler. La diversité des sources (où les données proviennent). La huate disponibilité et la reprise après désastre en effectuant des réplications multi-sites La prochaine étape dans cette installation en instance unique (sigle-instance) consiste à configurer le receveur (l’indexer à proprement parler).\n","link":"https://juni2dev.github.io/labs/reverse-shell/","section":"labs","tags":["splunk"],"title":"splunk"},{"body":"","link":"https://juni2dev.github.io/tags/splunk/","section":"tags","tags":null,"title":"Splunk"},{"body":"","link":"https://juni2dev.github.io/tags/","section":"tags","tags":null,"title":"Tags"},{"body":"Quand j\u0026rsquo;ai commencé à monter mon lab OpenVPN sur pfSense, j\u0026rsquo;ai dû générer des certificats, configurer une CA, choisir des algorithmes de chiffrement\u0026hellip; et là j\u0026rsquo;ai réalisé que je ne comprenais pas vraiment ce que je faisais. Je savais que TLS = cadenas vert dans le navigateur. Mais derrière ce cadenas, que se passe-t-il exactement ?\nVoici ce que j\u0026rsquo;aurais aimé lire à l\u0026rsquo;époque.\n🤔 SSL ou TLS — on parle de quoi ? SSL (Secure Sockets Layer) est le prédécesseur de TLS (Transport Layer Security). Aujourd\u0026rsquo;hui SSL est mort — SSL 2.0, SSL 3.0, TLS 1.0 et TLS 1.1 sont tous dépréciés et vulnérables. Quand on dit \u0026ldquo;SSL\u0026rdquo; dans la vie courante, on parle en réalité de TLS 1.2 ou TLS 1.3.\nLa version actuelle recommandée est TLS 1.3 (RFC 8446, 2018). TLS 1.2 est encore acceptable si bien configuré. Tout le reste est à proscrire.\n","link":"https://juni2dev.github.io/cybersecurite/tls-ssl-handshake-chiffrement-vulnerabilites/","section":"cybersecurite","tags":["tls","ssl","cryptographie","cybersécurité","réseau"],"title":"🔐 TLS/SSL : le protocole que tout le monde utilise sans vraiment comprendre"},{"body":"","link":"https://juni2dev.github.io/tags/cryptographie/","section":"tags","tags":null,"title":"Cryptographie"},{"body":"","link":"https://juni2dev.github.io/cybersecurite/","section":"cybersecurite","tags":null,"title":"Cybersécurité"},{"body":"","link":"https://juni2dev.github.io/tags/cybers%C3%A9curit%C3%A9/","section":"tags","tags":null,"title":"Cybersécurité"},{"body":"","link":"https://juni2dev.github.io/tags/r%C3%A9seau/","section":"tags","tags":null,"title":"Réseau"},{"body":"","link":"https://juni2dev.github.io/tags/ssl/","section":"tags","tags":null,"title":"Ssl"},{"body":"","link":"https://juni2dev.github.io/tags/tls/","section":"tags","tags":null,"title":"Tls"},{"body":"Description Ce lab documente la mise en place complète d\u0026rsquo;un VPN d\u0026rsquo;accès à distance utilisant OpenVPN sur pfSense. Il couvre l\u0026rsquo;intégralité de la chaîne : création d\u0026rsquo;une autorité de certification interne (root-CA), émission d\u0026rsquo;un certificat serveur et d\u0026rsquo;un certificat client, configuration du serveur OpenVPN via le Wizard pfSense, export du profil client, et quelques tests de validation par capture réseau Wireshark.\n⚠️ Contrairement à un VPN site-à-site où il aurait fallu mettre en place au moins deux pfSense, le présent scénario met en lumière un utilisateur mobile se connectant à un serveur distant typiquement le réseau d\u0026rsquo;entreprise (télétravailleur / télétravailleuse). on peut modéliser la connexion comme suit utilisateur ↔ serveur . Par ailleurs, pfSense endossera la fonction de serveur d\u0026rsquo;authentififaction (local user authentication) bien qu\u0026rsquo;il soit tout à fait possible d\u0026rsquo;utiliser LDAP/Radius. Ce choix se justifie par une gestion plus simple au travers de la section User manager du GUI aussi, le test sera effectué avec un seul utilisateur (user).\n🏗️ Architecture Il s\u0026rsquo;agit ici de l\u0026rsquo;environnement du lab dans son entièreté incluant un acteur malveillant.\n🧰 Stack technique Composant Détail Firewall/VPN Gateway pfSense Community Edition Protocole VPN OpenVPN Authentification Local User Access (pfSense User Manager) PKI Root-CA interne pfSense Algorithme de clé RSA 2048 bits Digest SHA-256 Chiffrement données AES-256-GCM / AES-128-GCM / CHACHA20-POLY1305 Chiffrement fallback AES-256-CBC Échange de clés Diffie-Hellman 2048 bits Authentification TLS Clé TLS partagée (auto-générée) Client OS Kali Linux (OpenVPN CLI) Analyse réseau Wireshark 📋 Étapes de configuration 1. Création de l\u0026rsquo;autorité de certification System → Certificates → Authorities → Add\nChamp Valeur Descriptive Name Root-CA Method Create an internal Certificate Authority Randomize Serial ✅ Activé Key Type RSA Key Length 2048 bits (minimum recommandé) Digest Algorithm SHA256 Lifetime 3650 jours (10 ans) Common Name Root-CA 💡 RSA 2048 est de facto la longueur de clé la plus utilisée par les CA. SHA-256 est considéré comme assez robuste face aux attaques du type arc-en-ciel (ou plus simplement collision).\n2. Création du certificat serveur System → Certificates → Certificates → Add\nChamp Valeur Method Create an internal Certificate Descriptive Name Authority-server Certificate Authority Root-CA Key Type RSA 2048 Digest Algorithm SHA256 Lifetime ≤ 398 jours ⚠️ Certificate Type Server (pas Client !) Common Name Authority-server ⚠️ La durée de vie du certificat serveur ne doit pas dépasser 398 jours — au-delà, certains clients TLS le rejettent.\n3. Configuration du serveur VPN via Wizard VPN → OpenVPN → Wizards Du fait que nous venons de créer la CA et le serveur, certaines étapes sont sautés par pfSense.\nÉtape 1/11 — Authentication Backend\nType of Server : Local User Access Étape 5/11 — Certificate Authority\nSélectionner Root-CA Étape 7/11 — Server Certificate\nSélectionner Authority-server Étape 9/11 — Server Setup\nChamp Valeur Description Remote workers from home Protocol UDP on IPv4 only Interface WAN Local Port 1194 TLS Authentication ✅ Activé Generate TLS Key ✅ Auto-généré DH Parameters Length 2048 bits Data Encryption AES-256-GCM, AES-128-GCM, CHACHA20-POLY1305 IPv4 Tunnel Network 10.0.8.0/24 IPv4 Local Network 192.168.110.0/24 Allow Compression Refuse (Most Secure) DNS Default Domain google.com (exemple) DNS Server 1 8.8.8.8 Étape 10/11 — Firewall Rules\n✅ Firewall Rule (Traffic from clients to server) ✅ OpenVPN rule (Traffic from clients through VPN) 💡 Par défaut pfSense applique un default block. Or les deux précédentes règles sont indispensables pour que le trafic VPN passe, il faut donc qu\u0026rsquo;ils soient explicitement mentionnées. On peut constater que les utilisateurs autorisés à se connecter n\u0026rsquo;ont pas été explicitement identifiés ce qui pourrait constituer une surface d\u0026rsquo;attaque potentielle. En production, affiner la règle WAN dans Firewall → Rules → WAN pour restreindre les IPs sources autorisées.\n4. Création de l\u0026rsquo;utilisateur et du certificat client System → User Manager → Users → Add\nChamp Valeur Username edi (exemple) Password (mot de passe fort) Certificate ✅ Cocher pour créer Certificate Name Identique au Username Certificate Authority Root-CA Key Type RSA 2048 Digest Algorithm SHA256 5. Export du profil client VPN → OpenVPN → Export Client\nInstaller le package OpenVPN Client Export via System → Package Manager Dans Client Connection Behavior → Bind Mode : Use a random local source port (permet des clients concurrents) Cliquer Save as default Dans OpenVPN Clients → colonne Export → télécharger Most Clients (.ovpn) 6. Connexion depuis le client Linux # Installation du client OpenVPN sudo apt update \u0026amp;\u0026amp; sudo apt install openvpn # Connexion avec le profil exporté sudo openvpn --config /chemin/vers/pfSense-UDP4-1194-edi-config.ovpn # → Enter Auth Username: edi # → Enter Auth Password: **** Indicateur de succès :\nI n i t i a l i z a t i o n S e q u e n c e C o m p l e t e d ⚠️ Vérifier que la règle Block Private Networks (l\u0026rsquo;interface WAN de pfSense) n\u0026rsquo;empeche pas l\u0026rsquo;établissement de la connexion avec le serveur.\n🔬 Validation — Wireshark Test 1 : Sniff sur l\u0026rsquo;interface tunnel tun0 Capture effectuée à l\u0026rsquo;intérieur du tunnel depuis l\u0026rsquo;interface virtuelle tun0 du client. À ce niveau, OpenVPN a déjà déchiffré les paquets — on observe donc le trafic applicatif en clair (HTTP, TCP\u0026hellip;). C\u0026rsquo;est un comportement attendu et normal : les adresses source appartiennent au subnet 10.0.8.0/24, ce qui confirme l\u0026rsquo;attribution d\u0026rsquo;adresse tunnel et le bon fonctionnement du routage vers le LAN.\nTest 2 : Sniff sur l\u0026rsquo;interface WAN de pfSense Capture effectuée côté WAN, avant déchiffrement. Tout le trafic apparaît en OpenVPN P_DATA_V2 — le contenu est illisible, ce qui confirme que l\u0026rsquo;encapsulation OpenVPN fonctionne.\nVoir l\u0026rsquo;analyse détaillée → docs/wireshark-analysis.md\n📁 Structure du repo o ├ ├ │ ├ │ ├ │ │ └ p ─ ─ ─ ─ ─ e ─ ─ ─ ─ ─ n v R c └ d └ d ├ └ s └ p E o ─ i ─ o ─ ─ c ─ n A n ─ a ─ c ─ ─ r ─ - D f g s e r M i c r a / w t e R e E g l a r i r n E m . s i m c r o s A o m / e s h e u h D t d n / i s b o M e t t h l t E - - e a e s . a c c r s m c o t k h d c n u - o e f r a o s i e n t s g . a i - - m l n l e d y g a x s . b a i m / m s d p . l m e d . o v p n ⚠️ Avertissement Ce lab est réalisé dans un environnement virtualisé isolé à des fins éducatives. Les configurations présentées (règles de pare-feu larges, mots de passe de test) ne doivent pas être reproduites en production sans durcissement approprié.\n📎 Ressources pfSense OpenVPN Documentation OpenVPN Community RFC 5280 — Certificate Lifetime ","link":"https://juni2dev.github.io/labs/openvpn-remote-access-pfsense/","section":"labs","tags":["vpn","pfsense","cybersécurité","digital signature"],"title":"🔐 OpenVPN Remote Access Lab — pfSense"},{"body":"","link":"https://juni2dev.github.io/tags/digital-signature/","section":"tags","tags":null,"title":"Digital Signature"},{"body":"","link":"https://juni2dev.github.io/tags/pfsense/","section":"tags","tags":null,"title":"Pfsense"},{"body":"","link":"https://juni2dev.github.io/tags/vpn/","section":"tags","tags":null,"title":"Vpn"},{"body":"NetSeCore NetSeCore est un blog technique centré sur la cybersécurité, les réseaux et les labs pratiques. L\u0026rsquo;objectif est de documenter des expérimentations réelles — configurations, attaques, défenses — de façon claire et reproductible.\nCe que vous trouverez ici Cybersécurité — analyse de protocoles, vulnérabilités, outils offensifs et défensifs Réseaux — infrastructure, VPN, firewall, segmentation et captures Wireshark Labs — guides pas-à-pas sur des environnements virtuels (pfSense, OpenVPN, PKI…) Articles — notes de veille, concepts et retours d\u0026rsquo;expérience Philosophie Chaque article repose sur une mise en pratique concrète. Pas de théorie sans lab, pas de lab sans explication. Les configurations présentées sont testées dans des environnements isolés avant d\u0026rsquo;être publiées.\nContact GitHub — juni2dev LinkedIn — Edmond Kameni ","link":"https://juni2dev.github.io/about/","section":"","tags":null,"title":"À propos"},{"body":"","link":"https://juni2dev.github.io/articles/","section":"articles","tags":null,"title":"Articles"},{"body":"","link":"https://juni2dev.github.io/categories/","section":"categories","tags":null,"title":"Categories"},{"body":"","link":"https://juni2dev.github.io/reseau/","section":"reseau","tags":null,"title":"Réseau"}]