Mes Projets

01 Structure du projet

Le projet est organisé en trois parties : le serveur, le client, et un portail de login. Chaque protocole (TCP, UDP) a ses propres classes. L'application démarre par une authentification avant de lancer les modules réseau.

02 Portail d'authentification

Le client affiche un écran de connexion demandant identifiant et mot de passe. Ces informations sont envoyées au serveur, qui valide ou refuse l'accès.

Socket socket = new Socket("127.0.0.1", 5000);
PrintWriter out = new PrintWriter(socket.getOutputStream(), true);
BufferedReader in = new BufferedReader(
    new InputStreamReader(socket.getInputStream()));

System.out.print("Identifiant : ");
String user = sc.nextLine();
System.out.print("Mot de passe : ");
String pass = sc.nextLine();

out.println(user + ":" + pass);
String response = in.readLine();
if ("OK".equals(response)) {
    System.out.println("Connexion autorisée !");
} else {
    System.out.println("Accès refusé.");
}

03 TCP — Serveur & Client

Le serveur TCP écoute sur un port et lance un thread par client. Le client envoie des messages textuels et reçoit les réponses. Chaque échange est journalisé.

04 UDP — Serveur & Client

L'implémentation UDP repose sur des datagrammes indépendants. Le serveur reçoit et renvoie des paquets sans connexion persistante.

05 Multithreading

Pour éviter les blocages, le serveur crée un thread par client TCP ou par paquet UDP, permettant des échanges simultanés.

06 Sécurité d'accès

Aucun client non authentifié ne peut établir de communication. Une fois connecté, l'utilisateur accède à l'interface réseau.

01 Gestion des clics

public void onCellClick(View view) {
    Button cell = (Button) view;
    if (!cell.getText().toString().equals("") || gameOver) return;

    cell.setText(currentPlayer);
    checkForWin();

    if (!gameOver) {
        currentPlayer = (currentPlayer.equals("X")) ? "O" : "X";
        status.setText("Au tour de " + currentPlayer);
    }
}

02 Vérification des victoires

private void checkForWin() {
    for (int i = 0; i < 3; i++) {
        if (board[i][0].equals(board[i][1]) && board[i][1].equals(board[i][2])
                && !board[i][0].equals("")) {
            status.setText("Le joueur " + board[i][0] + " a gagné !");
            gameOver = true; return;
        }
        if (board[0][i].equals(board[1][i]) && board[1][i].equals(board[2][i])
                && !board[0][i].equals("")) {
            status.setText("Le joueur " + board[0][i] + " a gagné !");
            gameOver = true; return;
        }
    }
    // Diagonales
    if (board[0][0].equals(board[1][1]) && board[1][1].equals(board[2][2])
            && !board[0][0].equals("")) {
        status.setText("Le joueur " + board[0][0] + " a gagné !");
        gameOver = true;
    }
}

03 Démo

01 Architecture de l'infrastructure

L'ensemble du SOC est déployé dans un environnement virtualisé sous VirtualBox, avec une segmentation réseau stricte. La machine attaquante (Kali Linux) est isolée sur un réseau WAN_LOC distinct des machines du SOC (SOC_LAN), forçant tout le trafic offensif à transiter par pfSense — condition indispensable pour que Suricata puisse l'inspecter.

02 Détection d'intrusion avec Suricata

Suricata est intégré directement au pare-feu pfSense en mode Inline IPS, ce qui lui permet d'inspecter et de bloquer le trafic en temps réel. Il utilise un ensemble de règles pour détecter les scans de ports, tentatives d'exploitation, anomalies protocolaires et communications suspectes. Chaque alerte identifie les machines impliquées, le type d'événement et la règle déclenchée.

# Règle déclenchée lors d'un SYN scan Nmap
alert tcp $EXTERNAL_NET any -> $HOME_NET any (
  msg:"ET SCAN Possible Nmap User-Agent Observed";
  flow:established,to_server;
  http.user_agent; content:"Nmap Scripting Engine";
  classtype:web-application-attack;
  sid:2024364; rev:2;
)

03 Analyse comportementale avec Zeek

Zeek complète Suricata en adoptant une approche comportementale : plutôt que de chercher des signatures, il enregistre toutes les communications réseau dans des journaux structurés au format JSON. Ces fichiers (conn.log, dns.log, http.log, notice.log) donnent une vision détaillée de l'activité et facilitent l'identification des anomalies.

<localfile>
  <log_format>json</log_format>
  <location>/opt/zeek/logs/current/*.log</location>
</localfile>

04 Centralisation dans le SIEM Wazuh

Wazuh agrège les logs de tous les composants du SOC. Son moteur de règles analyse les événements et génère des alertes corrélées. Le dashboard permet aux analystes de visualiser l'activité réseau en temps réel : volume d'alertes, IPs sources, ports ciblés, niveaux de criticité. Le projet a généré plus de 6 992 événements lors des phases de test.

05 Scénarios d'attaque et détection

Deux scénarios ont été simulés depuis Kali Linux pour valider le fonctionnement du SOC.

# Scan SYN furtif ciblant une machine du SOC_LAN
nmap -sS 192.168.10.X

# Analyse des requêtes DNS depuis la machine attaquante
dig wazuh.com

06 Automatisation SOAR — Shuffle & IRIS

Chaque alerte Wazuh peut déclencher automatiquement un workflow Shuffle. Dans le workflow mis en place, une alerte entraîne l'enrichissement de l'événement puis la création automatique d'un ticket dans IRIS — reproduisant le pipeline d'un SOC professionnel : détection → centralisation → orchestration → ticketing.

07 Difficultés rencontrées & solutions