ez

Parfait, on va se mettre dans la peau de l’étudiant en cyber qui doit rendre son TD 😄
Je te propose :

1. Une **architecture simple** avec tes 3 machines, mais **2 sources de logs** : Linux + Windows 10 (sans agents).
2. Une **config Logstash complète**.
3. Des **idées de tableaux de bord Kibana**.
4. Un **rapport tout prêt au format `.md`** que tu pourras adapter / compléter.

---

## 1. Architecture globale (idée pour ton TD)

Machines :

* **Linux (192.168.30.100)**
  → héberge **Elasticsearch + Kibana + Logstash**
  → source de logs n°1 : logs système Linux (`/var/log/...`)

* **Windows 10 (192.168.30.x)**
  → source de logs n°2 : logs d’événements (Security / System)

* **Windows Server**
  → dispo dans le réseau mais **pas utilisée comme source** dans ce TD (tu peux le mentionner dans le rapport comme machine disponible mais non utilisée).

### Flux de logs proposés (sans agent type Beats)

**Source 1 – Linux → Logstash (UDP / syslog)**

* Rsyslog sur Linux envoie les logs vers Logstash (qui est sur la même machine).
* Logstash écoute sur un port UDP (ex : **5514**) et parse les messages syslog.

**Source 2 – Windows 10 → Logstash (TCP / JSON via script PowerShell)**

* Un **script PowerShell** sur Windows 10 lit les Event Logs (par ex. journal Security).
* Il envoie régulièrement les événements vers Logstash via TCP (port **5000**) au format JSON.
* Pas d’agent type Winlogbeat / Elastic Agent : juste un script maison + tâche planifiée.

**Logstash → Elasticsearch → Kibana**

* Logstash normalise un minimum les logs (tags, type, date…).
* Les documents sont indexés dans Elasticsearch avec 2 indexes distincts :

  * `linux-syslog-YYYY.MM.dd`
  * `win10-eventlog-YYYY.MM.dd`
* Dans Kibana, tu crées 2 index patterns correspondant, puis des dashboards.

---

## 2. Config côté Linux : Rsyslog → Logstash

### 2.1. Config Rsyslog (Linux)

Fichier à créer : `/etc/rsyslog.d/60-logstash.conf`

```conf
# Envoi de tous les logs locaux vers Logstash (sur la même machine)
*.*  @127.0.0.1:5514;RSYSLOG_SyslogProtocol23Format
```

Puis redémarrer rsyslog :

```bash
sudo systemctl restart rsyslog
```

---

## 3. Source Windows 10 : script PowerShell → Logstash

### 3.1. Script PowerShell d’envoi des logs

Par exemple : `C:\scripts\send-security-logs.ps1`

```powershell
$server = "192.168.30.100"
$port   = 5000

# Récupère les 200 derniers événements du journal Security
$events = Get-WinEvent -LogName Security -MaxEvents 200 |
    Select-Object TimeCreated, Id, LevelDisplayName, ProviderName, MachineName, Message

$client = New-Object System.Net.Sockets.TcpClient($server, $port)
$stream = $client.GetStream()
$writer = New-Object System.IO.StreamWriter($stream)
$writer.AutoFlush = $true

foreach ($event in $events) {
    $json = $event | ConvertTo-Json -Depth 3
    $writer.WriteLine($json)
}

$writer.Dispose()
$client.Close()
```

Ensuite tu crées une **tâche planifiée** (Task Scheduler) qui lance ce script toutes les X minutes.
Ça te donne un flux pseudo-temps réel, suffisant pour un TD.

---

## 4. Configuration Logstash (à mettre dans le rapport)

Fichier : `/etc/logstash/conf.d/td-siem.conf` (par exemple)

```conf
input {
  # Logs Linux via syslog/rsyslog
  udp {
    port => 5514
    type => "linux-syslog"
  }

  # Logs Windows 10 via script PowerShell (JSON sur TCP)
  tcp {
    port => 5000
    codec => json
    type => "win10-eventlog"
  }
}

filter {
  if [type] == "linux-syslog" {
    grok {
      match => { "message" => "%{SYSLOGTIMESTAMP:syslog_timestamp} %{HOSTNAME:host} %{DATA:program}(?:\[%{POSINT:pid}\])?: %{GREEDYDATA:log_message}" }
    }
    date {
      match => [ "syslog_timestamp", "MMM  d HH:mm:ss", "MMM dd HH:mm:ss" ]
      target => "@timestamp"
    }
  }

  if [type] == "win10-eventlog" {
    # Les champs sont déjà en JSON grâce au script
    mutate {
      rename => {
        "MachineName"      => "host"
        "ProviderName"     => "provider"
        "LevelDisplayName" => "level"
        "Id"               => "event_id"
      }
      add_tag => [ "windows", "eventlog" ]
    }
  }
}

output {
  elasticsearch {
    hosts => ["https://192.168.30.100:9200"]
    user => "elastic"
    password => "MOT_DE_PASSE_ELASTIC"
    index => "%{[type]}-%{+YYYY.MM.dd}"   # ex: linux-syslog-2025.12.02, win10-eventlog-2025.12.02
    ssl_enabled => true
    ssl_certificate_authorities => "/etc/logstash/certs/ca.crt"
  }

  # En debug pendant le TD, pratique :
  stdout {
    codec => rubydebug
  }
}
```

> **À adapter** : chemin `ca.crt` + mot de passe `elastic` selon ce que tu as configuré.

---

## 5. Schéma d’architecture (ASCII pour ton .md)

Tu peux coller ça tel quel dans ton rapport :

```text
                         +-------------------------+
                         |   Windows Server 2019  |
                         |   (non utilisé comme   |
                         |   source de logs dans  |
                         |   ce TD)               |
                         +-------------------------+

+--------------------+                      +-------------------------------------+
|   Windows 10       |                      |   Linux 192.168.30.100             |
| 192.168.30.X       |                      |  (Elastic Stack + Logstash)        |
|--------------------|      TCP/5000        |-------------------------------------|
| - Event Logs       |  ----------------->  |  Logstash                           |
| - Script PS        |  JSON                |   - input udp 5514 (linux-syslog)   |
|   send-security-   |                      |   - input tcp 5000 (win10 JSON)     |
|   logs.ps1         |                      |   - filters (grok/mutate/date)      |
+--------------------+                      |   - output Elasticsearch            |
                                            +-----------------+-------------------+
                                                              |
                                                              | HTTPS 9200
                                                              v
                                                       +--------------+
                                                       | Elasticsearch|
                                                       +------+-------+
                                                              |
                                                              | HTTP/HTTPS 5601
                                                              v
                                                       +--------------+
                                                       |   Kibana     |
                                                       +--------------+
```

---

## 6. Kibana : index patterns et dashboards

### 6.1. Index patterns

Dans Kibana (Menu “Stack Management” → “Index patterns”) :

1. `linux-syslog-*`
2. `win10-eventlog-*`

Tu les utiliseras pour tes visualisations.

---

## 7. Tableaux de bord (jusqu’à 5 max)

Je te propose **3 ou 4 dashboards**, largement suffisant pour un TD.

### Dashboard 1 – Vue globale des logs

**Index** : `linux-syslog-*` + `win10-eventlog-*` (tu peux utiliser un pattern `*eventlog-*` si tu veux, mais ici nos indexes sont bien nommés).

**Visualisations possibles :**

* Histogramme (Area / Bar) : nombre de logs par minute/heure (`@timestamp`).
* Pie chart : répartition par `[type]` (`linux-syslog` vs `win10-eventlog`).
* Data table : top `host`.

**Ce que ça permet de voir :**

* Volume de logs global dans le temps.
* Répartition des événements entre Linux et Windows.
* Quel host génère le plus de logs.

**Intérêt SOC :**

* Vue “overview” pour détecter des pics d’activité anormaux (ex : brute force, crash massif, etc.).
* Rapide aperçu de l’état des sources de logs (source silencieuse = problème).

---

### Dashboard 2 – Authentification Linux (SSH / sudo)

**Index** : `linux-syslog-*`
Filtre : `log_message : "sshd" OR log_message : "sudo"`

**Visualisations :**

* Histogramme : nombre d’événements `sshd` (authentification) dans le temps.
* Data table : top des adresses IP sources (extraction depuis `log_message` si tu vas plus loin avec `grok`).
* Data table : top des utilisateurs (`user` si tu l’extrais, ou simple recherche texte).

**Ce que ça permet de voir :**

* Tentatives de connexion SSH sur la machine.
* IP les plus actives → potentiels attaquants.
* Utilisateurs les plus utilisés (compte à surveiller).

**Intérêt SOC :**

* Détection de brute-force SSH.
* Identifier des comptes ciblés.
* Premières analyses d’incident sur la machine Linux.

---

### Dashboard 3 – Authentification Windows 10

**Index** : `win10-eventlog-*`

Tu peux te concentrer sur les événements clés :

* `event_id = 4624` : logon réussi
* `event_id = 4625` : logon échoué

**Visualisations :**

* Histogramme : nombre d’authentifications réussies / échouées dans le temps (split series par `event_id`).
* Data table : top utilisateurs (extrait à partir du champ `Message` si tu n’as pas décodé plus finement).
* Data table : top `event_id`.

**Ce que ça permet de voir :**

* Activité de connexion sur la machine Windows 10.
* Périodes avec beaucoup d’échecs (tape mal son mot de passe vs brute-force).
* Comptes / utilisateurs les plus utilisés.

**Intérêt SOC :**

* Détection d’activité suspecte sur les comptes Windows.
* Détection de brute-force ou tentatives d’accès non autorisé.
* Corrélation possible avec d’autres sources (si tu étends le TD plus tard).

---

### Dashboard 4 (optionnel) – Erreurs & alertes système

**Index** : `linux-syslog-*` + `win10-eventlog-*`

* Filtrer sur niveau d’erreur :

  * Linux : `log_message` contenant `error`, `fail`, etc.
  * Windows : `level` égal à `Error` ou `Warning`.

**Visualisations :**

* Bar chart : nombre d’erreurs par host.
* Data table : top messages d’erreur.
* Data table : top programmes/processus (`program` pour Linux, `provider` pour Windows).

**Intérêt SOC :**

* Suivi de la santé des systèmes (pannes, erreurs récurrentes).
* Mise en évidence d’applications instables ou mal configurées, qui peuvent devenir une surface d’attaque.

---

## 8. Modèle de rapport `.md` à rendre

Tu peux copier-coller ce squelette et l’adapter (changer ton nom, ajouter des captures d’écran, etc.).

````markdown
# TD SIEM – Elastic Stack (Elasticsearch / Logstash / Kibana)

**Étudiant :** Prénom NOM  
**Filière :** Ingénieur Cybersécurité  
**Date :** JJ/MM/AAAA

---

## 1. Contexte et objectifs

Dans le cadre de la matière SIEM, l’objectif de ce TD est de :

- Installer et configurer la stack Elastic (Elasticsearch, Logstash, Kibana).
- Récupérer des logs depuis **deux sources de données différentes**, sans utiliser d’agent (type Beats / Elastic Agent).
- Créer plusieurs tableaux de bord dans Kibana afin de visualiser ces données.
- Documenter l’architecture de remontée des logs et les dashboards créés.

---

## 2. Architecture de remontée des logs

### 2.1. Environnement

- **Machine Linux (192.168.30.100)**
  - Elasticsearch 8.x
  - Kibana 8.x
  - Logstash 8.x
  - Rôle : plateforme SIEM + première source de logs (logs système)

- **Machine Windows 10 (192.168.30.X)**
  - Source de logs n°2 (Event Logs Windows)
  - Script PowerShell d’export des logs vers Logstash (sans agent)

- **Machine Windows Server**
  - Présente sur le réseau, mais non utilisée comme source de logs dans ce TD.

### 2.2. Schéma d’architecture

```text
+--------------------+                      +-------------------------------------+
|   Windows 10       |                      |   Linux 192.168.30.100             |
| 192.168.30.X       |                      |  (Elastic Stack + Logstash)        |
|--------------------|      TCP/5000        |-------------------------------------|
| - Event Logs       |  ----------------->  |  Logstash                           |
| - Script PS        |  JSON                |   - input udp 5514 (linux-syslog)   |
|   send-security-   |                      |   - input tcp 5000 (win10 JSON)     |
|   logs.ps1         |                      |   - filters (grok/mutate/date)      |
+--------------------+                      |   - output Elasticsearch            |
                                            +-----------------+-------------------+
                                                              |
                                                              | HTTPS 9200
                                                              v
                                                       +--------------+
                                                       | Elasticsearch|
                                                       +------+-------+
                                                              |
                                                              | HTTP/HTTPS 5601
                                                              v
                                                       +--------------+
                                                       |   Kibana     |
                                                       +--------------+
````

### 2.3. Description des flux

1. **Linux → Logstash (UDP/syslog)**

   * Rsyslog envoie tous les logs locaux vers Logstash sur le port UDP **5514**.
   * Logstash reçoit ces événements, les parse et les indexe dans Elasticsearch dans des indexes de type
     `linux-syslog-YYYY.MM.dd`.

2. **Windows 10 → Logstash (TCP/JSON)**

   * Un script PowerShell lit les 200 derniers événements du journal Security.
   * Les événements sont envoyés au format JSON via TCP sur le port **5000** de la machine Linux.
   * Logstash reçoit ces événements, les enrichit et les stocke dans des indexes
     `win10-eventlog-YYYY.MM.dd`.

3. **Logstash → Elasticsearch → Kibana**

   * Logstash écrit dans Elasticsearch via HTTPS (port **9200**), avec authentification (utilisateur `elastic`).
   * Kibana se connecte à Elasticsearch pour la visualisation (port **5601**).

---

## 3. Configuration Logstash

### 3.1. Fichier de configuration `td-siem.conf`

```conf
input {
  udp {
    port => 5514
    type => "linux-syslog"
  }

  tcp {
    port => 5000
    codec => json
    type => "win10-eventlog"
  }
}

filter {
  if [type] == "linux-syslog" {
    grok {
      match => { "message" => "%{SYSLOGTIMESTAMP:syslog_timestamp} %{HOSTNAME:host} %{DATA:program}(?:\[%{POSINT:pid}\])?: %{GREEDYDATA:log_message}" }
    }
    date {
      match => [ "syslog_timestamp", "MMM  d HH:mm:ss", "MMM dd HH:mm:ss" ]
      target => "@timestamp"
    }
  }

  if [type] == "win10-eventlog" {
    mutate {
      rename => {
        "MachineName"      => "host"
        "ProviderName"     => "provider"
        "LevelDisplayName" => "level"
        "Id"               => "event_id"
      }
      add_tag => [ "windows", "eventlog" ]
    }
  }
}

output {
  elasticsearch {
    hosts => ["https://192.168.30.100:9200"]
    user => "elastic"
    password => "MOT_DE_PASSE_ELASTIC"
    index => "%{[type]}-%{+YYYY.MM.dd}"
    ssl_enabled => true
    ssl_certificate_authorities => "/etc/logstash/certs/ca.crt"
  }

  stdout {
    codec => rubydebug
  }
}
```

*(Les valeurs sensibles comme le mot de passe sont masquées dans ce rapport.)*

---

## 4. Tableaux de bord Kibana

### 4.1. Index patterns

* `linux-syslog-*`
* `win10-eventlog-*`

### 4.2. Dashboard 1 – Vue globale des logs

* **Index :** `linux-syslog-*` + `win10-eventlog-*`
* **Visualisations :**

  * Histogramme du nombre de logs au cours du temps (`@timestamp`).
  * Diagramme en secteurs par type (`linux-syslog` vs `win10-eventlog`).
  * Tableau des top hosts.
* **Utilité :**

  * Donne une vue d’ensemble de l’activité.
  * Permet de détecter des pics de logs anormaux et de vérifier la bonne remontée des sources.

### 4.3. Dashboard 2 – Authentification Linux (SSH/sudo)

* **Index :** `linux-syslog-*`
* **Filtre :** `log_message` contenant `sshd` ou `sudo`.
* **Visualisations :**

  * Histogramme des tentatives de connexion SSH dans le temps.
  * Tableau des IP sources les plus fréquentes.
  * Tableau des utilisateurs les plus utilisés.
* **Utilité SOC :**

  * Détection de brute-force SSH.
  * Identification de comptes et IP suspects.

### 4.4. Dashboard 3 – Authentification Windows 10

* **Index :** `win10-eventlog-*`
* **Filtre :** `event_id` = 4624 (succès) ou 4625 (échec).
* **Visualisations :**

  * Histogramme des logons réussis/échoués, série par `event_id`.
  * Tableau des utilisateurs fréquents.
  * Tableau des codes d’événements.
* **Utilité SOC :**

  * Suivi de l’activité de connexion sur Windows.
  * Détection de multiples échecs pouvant indiquer une attaque ou un compte compromis.

### 4.5. Dashboard 4 – Erreurs et alertes système (optionnel)

* **Index :** `linux-syslog-*` + `win10-eventlog-*`
* **Filtre :**

  * Linux : `log_message` contenant `error`, `fail`, etc.
  * Windows : `level = Error` ou `Warning`.
* **Visualisations :**

  * Barres : nombre d’erreurs par host.
  * Tableau des messages d’erreur les plus fréquents.
* **Utilité SOC :**

  * Suivi de la santé des systèmes.
  * Identification d’applications ou de services problématiques.

---

## 5. Conclusion

Ce TD m’a permis de :

* Installer et configurer la stack Elastic (Elasticsearch, Logstash, Kibana).
* Mettre en place une remontée de logs sans agent pour deux sources différentes (Linux et Windows 10).
* Créer plusieurs dashboards Kibana orientés surveillance de la sécurité (authentification, erreurs).
* Comprendre l’intérêt d’un SIEM pour un SOC : corrélation d’événements, détection d’anomalies, visibilité centralisée.

Des améliorations possibles incluraient :

* L’ajout d’autres sources de logs (Windows Server, équipements réseau).
* Plus de parsers `grok` pour extraire finement les champs de sécurité.
* La mise en place de règles de détection plus avancées dans Elastic Security.

```

---

Si tu veux, au prochain message tu peux m’envoyer ce que tu as déjà fait (ou les erreurs que tu as côté Logstash / Kibana) et on ajuste la config pour que ça colle exactement à ton environnement.
::contentReference[oaicite:0]{index=0}
```
Créé il y a 1 mois.