198 lines
5.1 KiB
Markdown
198 lines
5.1 KiB
Markdown
---
|
|
title: "Sécurité des réseaux : Commandes utiles"
|
|
date: 2022-12-01
|
|
tags: ["nmap", "tcpdump", "MitM"]
|
|
categories: ["Sécurité des réseaux", "TD"]
|
|
---
|
|
|
|
Le but de cet article est de répertorier les commandes uiles que nous avons
|
|
utilisés lors de différents TD et d'expliquer le contexte d'utilisation.
|
|
|
|
## Nmap
|
|
|
|
map est le couteau suisse du scan de port. Il ppeut être utilisé en attaque mais
|
|
aussi en défense préventive (test de sa propre infrasctucture).
|
|
|
|
### découverte de l'hôte seulement
|
|
|
|
```
|
|
nmap -sn <adresse>
|
|
```
|
|
|
|
### déterminer les versions
|
|
|
|
```
|
|
nmap -A -sV <adresse>
|
|
```
|
|
|
|
* `-sV`: lance un scan en essayant de déterminer la version des services en
|
|
écoute
|
|
* `-A`: affiche plus d'informations
|
|
|
|
### Les différents type de scan
|
|
|
|
* `nmap -sS <addr>`: *SYN* scan
|
|
* `nmap -sX <addr>`: *XMAS* scan
|
|
* `nmap -sF <addr>`: *FIN* scan
|
|
|
|
### Temporiser
|
|
|
|
Il est possible de temporiser les différents scan afin de se rendre un peu plus
|
|
discret avec l'option `-T <num>`. `<num>` étant un chiffre de 0 (plus lent) à 5
|
|
plus rapide.
|
|
|
|
## Spoof ARP
|
|
|
|
La command `arpspoof` permet de faire de l'*ARP* cache poisoning en utilisant la
|
|
technique du *flood* afn de noyer les hôtes du réseau d'annonces.
|
|
|
|
```
|
|
arpspoof -i <dev> -r -t <addr_target> <host>
|
|
```
|
|
|
|
Empoisoser le cache de `<addr_target>` -- ou de tout le reseau si `-t` n;est pas
|
|
utilisé -- pour détourner le trafic de `<host>`
|
|
|
|
## TCP dump
|
|
|
|
`tcpdump` est un outils de capture de trame réseau en ligne de commande. Il est
|
|
possible de le lancer simplement afin qu'il affiche les informations sur la
|
|
sortie standard:
|
|
|
|
```
|
|
tcpdump -i <dev> -n
|
|
```
|
|
* `-i` périphériue à écouter
|
|
* `-n` ne résout pas les adresse IP vers le nom d'hôte
|
|
|
|
Dans le cadre d'un TD cette méthode peut suffire, mais dès que le traffic réseau
|
|
devient plus important, il est plus difficile de suivre. On peut alors capturer
|
|
le trafic pour l'analyse avec un outils comme *Wireshark*:
|
|
|
|
```
|
|
tcpump -i <dev> -n -s 1500 -w <file>
|
|
```
|
|
|
|
Ici `-s 1500` limite la taille des paquets à capturer à 1500 bits hitoire de ne
|
|
pas tronquer les trames. On peut spécifier `-s0` pour ne pas donner de limite.
|
|
|
|
`-w <file>` écrit la capture dans le fichier `<file>` en mode binaire
|
|
|
|
### requête
|
|
|
|
Il est aussi possible de faire en sorte de filter le traffic capturé.
|
|
|
|
```
|
|
tcpdump -i <dev> 'tcp and src <ip> and 80'
|
|
```
|
|
|
|
Ici on capture les trames *TCP* donc la source est `<ip>` et sur le port 80.
|
|
|
|
### Utiliser les outils usuel
|
|
|
|
Pour utiliser les outils usuels tels que `grep`, `awk` ou `sed` avec *tcpdump*,
|
|
il faut activer le mode *buffered line* avec le drapeau `-l`, il est aussi
|
|
conseillé d'activer le mode verbeux avec `-v` (ou `-vv` pour avoir plus de
|
|
détails):
|
|
|
|
```
|
|
tcpdump -v -l -n 'port http' | grep 'Host\|User-Agent'
|
|
```
|
|
|
|
L'exemple ci-dessus affiche le champs `Host` et `User-Agent` d'une connexion
|
|
http.
|
|
|
|
## Iptables
|
|
|
|
### rediriger le traffic sur la machine locale
|
|
|
|
Lors d'un forward, il est possible de rediriger le traffic sur la machine locale
|
|
avec l'option `-j REDIRECT`. Cette option s'utilise sur la table `nat`. voici un
|
|
exemple pour le traffic http:
|
|
|
|
```
|
|
iptables -t nat -A PREROUTING -p tcp --destination-port 80 -j REDIRECT --to-ports 8080
|
|
```
|
|
|
|
## Gnutls
|
|
|
|
### Mettre en place un serveur / client (tester les certificats)
|
|
|
|
Il est possible d'utiliser gnutls pour tester des certificats et s'assurer que
|
|
tout fonctionne correctement (le certificat de l'autorité de certification par
|
|
exemple).
|
|
|
|
|
|
```
|
|
# sur le serveur
|
|
gnutls-serv --x509keyfile=<file.key> --x509certfile=<file.crt>
|
|
```
|
|
|
|
```
|
|
# le client
|
|
gnutls-cli --x509cafile=<file.pem>
|
|
```
|
|
|
|
## Openssl
|
|
|
|
### Création de sa propre CA
|
|
|
|
Voici la commande pour générer la clé et le certificate de notre CA.
|
|
|
|
```
|
|
openssl req -x509 -new -newkey rsa:<keysize> -noenc \
|
|
-key $CANAME.key -sha256 -days 1826 \
|
|
-out <ca.crt> \
|
|
-keyout <ca.key> \
|
|
-subj '<subject>'
|
|
```
|
|
|
|
NMous allons pouvoir fournir le certificat aux machines voulues pour qu'elle
|
|
acceptent nos certificats et signer les requêtes en signature.
|
|
|
|
### Création de certificat
|
|
|
|
Il est d'abord nécessaire de créer une clé et une requête en signature. Ces deux
|
|
étapes sont réalisable en une seule commande:
|
|
|
|
```
|
|
# générer la clé
|
|
openssl req -new -newkey rsa:<keysize> -sha256 -noenc -out <filename.csr> \
|
|
-keyout <filename.key>
|
|
-subj <subject>
|
|
```
|
|
|
|
### Signer la CSR
|
|
Voici la commande pour signer lea requête en signature avec la clé de notre
|
|
autorité. C'est ici que nous alons définir la durée de validiter du certificat
|
|
signé.
|
|
|
|
```
|
|
openssl x509 -req -days 365 -in <filename.csr> -out <filename.crt> -signkey <ca.key>
|
|
```
|
|
|
|
## Kerberos
|
|
|
|
Quelques commande utiles pour administrer un service Kerberos.
|
|
|
|
### kadmin.local
|
|
|
|
Comme la commande le suggère, `kadmin` sert à adminstrer le serveur. Une fois la
|
|
commande lancée, un promp apparait.
|
|
|
|
La commande suivante créée une clé pour l'hôte `<host>`:
|
|
|
|
```
|
|
kadmin: addprinc -randkey host/<host>.example.com
|
|
```
|
|
|
|
`-randkey` permet de générer une clé aléatoire en lieu et place d'un mot de
|
|
passe.
|
|
|
|
Il est ensuite de créer une clé supplémentaire pour le service nfs par exemple:
|
|
|
|
Ou encore de rajouter un utilisateur à notre royaume
|
|
|
|
```
|
|
kadmin: addprinc <user>.example.com
|
|
```
|