314 lines
8.2 KiB
Markdown
314 lines
8.2 KiB
Markdown
---
|
|
title: "Sécurité des réseaux : Commandes utiles"
|
|
date: 2022-12-01
|
|
tags: ["nmap", "tcpdump", "MitM", "SSH"]
|
|
categories: ["Sécurité des réseaux", "TD"]
|
|
---
|
|
|
|
Le but de cet article est de répertorier les commandes utiles que nous avons
|
|
utilisés lors de différents TD et d'expliquer le contexte d'utilisation.
|
|
|
|
## Nmap
|
|
|
|
Nmap est le couteau suisse du scan de port. Il peut être utilisé en attaque mais
|
|
aussi en défense préventive (test de sa propre infrastructure).
|
|
|
|
### 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 commande `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.
|
|
|
|
Avant tout chose il faut activer le forward IP,
|
|
[Voir la partie IPTable]({{<relref "#activer-le-forward-ipv4">}})
|
|
```
|
|
arpspoof -i <dev> -r -t <addr_target> <host>
|
|
```
|
|
|
|
Empoisser le cache de `<addr_target>` -- ou de tout le réseau 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érie à é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 trafic 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 histoire 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 filtre le trafic 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
|
|
|
|
### Activer le forward IPv4
|
|
|
|
Il existe plusieurs méthodes pour activer le forward IPv4, il est d'abord
|
|
possible d'utiliser sysctl :
|
|
|
|
```
|
|
sysctl -w net.ipv4.ip_forward=1
|
|
```
|
|
|
|
Ou encore avec un simple echo:
|
|
|
|
```
|
|
echo 1 > /proc/sys/net/ipv4/ip_forward
|
|
```
|
|
|
|
Pour que les changement persiste au redémarrage, on va jouer un peu avec sed:
|
|
|
|
```
|
|
# modification du fichier
|
|
sed -E 's/^#(net\.ipv4\.ip_forward=1)$/\1/'
|
|
# application des modifications
|
|
sysctl -p /etc/sysctl.conf
|
|
```
|
|
|
|
### rediriger le trafic sur la machine locale
|
|
|
|
Lors d'un forward, il est possible de rediriger le trafic sur la machine locale
|
|
avec l'option `-j REDIRECT`. Cette option s'utilise sur la table `nat`. Voici un
|
|
exemple pour le trafic HTTP.
|
|
|
|
```
|
|
iptables -t nat -A PREROUTING -p tcp --destination-port 80 -j REDIRECT --to-ports 8080
|
|
```
|
|
|
|
## SSH
|
|
|
|
SSH est bien plus qu'un outils pour se connecter sur un TTY à distance de
|
|
manière sécurisée. Il est possible de faire des rebonds, de rediriger les
|
|
connexions, créer des tunnels etc.
|
|
|
|
Certaines options de la ligne de commande peuvent être intéressante:
|
|
|
|
* `-f`: passer SSH en tâche de fond et rendre la main. Utile pour les tunnels
|
|
* `-N`: ne pas exécuter de commandes, utile lorsqu'on redirige simplement des
|
|
ports.
|
|
* `-n`: ne rien lire sur l'entrée standard, utile pour juste lancer une
|
|
application sur le serveur cible
|
|
* `-T`: ne pas allouer de pseudo terminal (mode non interactif)
|
|
* `-t`: forcer l'allocation de pseudo terminal
|
|
|
|
### Connexion par rebond
|
|
|
|
Le principe: utiliser un serveur pour faire un rebond et ainsi accéder à une
|
|
machine non accessible
|
|
|
|
```
|
|
ssh -J ssh.domain.com leserveur.domain.local
|
|
```
|
|
|
|
Je me connecte ainsi à `leserveur.domain.local` en passant par `ssh.domain.com`
|
|
|
|
Il est possible d'automatiser le rebond dans le fichier de configuration de ssh
|
|
(`~/.ssh/config`):
|
|
|
|
```
|
|
# Se connecter à mcgonagall en passant par jaguar
|
|
Host mcgonagall
|
|
Hostname mcgonagall
|
|
ProxyJump <user>@jaguar.emi.u-bordeaux.fr
|
|
User <user>
|
|
```
|
|
|
|
### Créer un tunnel
|
|
|
|
Il est aussi possible de créer un tunnel sécurisé afin d'accéder à une ressource
|
|
d'un réseau local en passant par un serveur SSH:
|
|
|
|
```
|
|
ssh -L 8443:192.168.0.254:443 ssh.domain.com
|
|
```
|
|
|
|
Ici la connections se fait comme suit:
|
|
|
|
```
|
|
localhost:8443 -> ssh.domain.com -> 192.168.0.253:443
|
|
```
|
|
|
|
Il est possible de faire l'inverse avec `-R`
|
|
|
|
### Proxy SOCKS
|
|
|
|
Il est possible de créer un proxy socks afin de faire une redirection de ports
|
|
dynamique (avec des applications qui le supporte):
|
|
|
|
```
|
|
ssh -D 9050 -Nf ssh.domaine.com
|
|
```
|
|
|
|
Il est par exemple possible de configure son navigateur web afin d'utiliser ce
|
|
proxy pour y faire transiter les données. Le site visité identifiera sa source
|
|
comme `ssh.domain.com`.
|
|
|
|
#### proxychains
|
|
|
|
Proxychains est un logiciel permettait de "proxyfier" n'importe quel logiciel.
|
|
Il est par exemple possible de lancer un scan de port via un proxy socks pour
|
|
être au plis près de sa cible.
|
|
|
|
La configuration se fait dans le fichier `/etc/proxychains.conf`, dans notre
|
|
exemple plus haut il faut ajouter la ligne si elle n'y est pas:
|
|
|
|
```
|
|
socks4 127.0.0.1 9050
|
|
```
|
|
|
|
Puis lancer un scan de ports en préfixant la commande de `proxychains`:
|
|
|
|
```
|
|
proxychains nmap -sV macible.domain.com
|
|
```
|
|
|
|
Il est ainsi possible de scanner les ports d'une machine inaccessible auparavant.
|
|
|
|
## 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 certificat 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 la requête en signature avec la clé de notre
|
|
autorité. C'est ici que nous allons définir la durée de validités 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 à administrer le serveur. Une fois la
|
|
commande lancée, un prompt 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
|
|
```
|