TP SECURITE ARS-IRT nmap tcpdump wireshark et filtrage iptables statique

Transcription

1 TP SECURITE ARS-IRT nmap tcpdump wireshark et filtrage iptables statique NMAP est un scanner de ports TCPDUMP et WIRESHARK sont des sniffers Ce tp se fera directement sur la mandriva serveur virtuel CE N'EST PAS LA MÊME QU'AU TP PRECEDENT ( dans le menu tp_secu_statique ) il y a deux comptes sur la mandriva serveur virtuel root ( azerty ) vmuser ( azerty ) Vous utiliserez la machine réelle comme client vérifier la présence sur le serveur virtuel des commandes nmap, tcpdump et wireshark ( ex ethereal ) noter l'adresse IP de votre serveur vérifier la présence de nmap sur la machine réelle 1 NMAP Depuis la machine réelle faire un scan tcp du serveur virtuel sur tous les ports tcp 216-pc01 ~vmuser > nmap Starting Nmap 4.11 ( ) at :06 CET Interesting ports on : Not shown: 1672 closed ports PORT STATE SERVICE 21/tcp open ftp 22/tcp open ssh 80/tcp open http 6000/tcp open X11 vérifier que vous avez bien au moins les services ftp,ssh et web pas de probleme les ports sont et 80 sont ouvert 2 TCPDUMP et WIRESHARK lancer sur votre serveur virtuel la commande ( Il faut être root pour sniffer les paquets ): tcpdump -i eth0 port 21 -w /tmp/ votre login /ftp-session.log depuis un terminal sur la machine réelle faites un ftp vers votre serveur virtuel rentrer comme login vmuser et le mot de passe tapper dir stopper la commande tcpdump (^C) lancer : wireshark /tmp/ votre login /ftp-session.log cliquer sur analyse follow tcp stream que constatez vous? Login et mot de passe en clair

2 En regardant les 3 premiers paquets on voit bien la séquence syn, syn ack, ack et le login en ligne 10 ainsi que le mot de passe en ligne 13 Problème de tout les protocoles qui ne chiffrent pas l'authentification

3 3 filtrage statique toutes les commandes de filtrage ont lieu sur le serveur virtuel Sur le serveur virtuel il y a un fichier /root/iptables-statique.sh le lire!/bin/sh set -vx IPC=/sbin/iptables Politique par defaut $IPC -P INPUT DROP $IPC -P OUTPUT ACCEPT $IPC -P FORWARD ACCEPT reset de toutes les règle précédentes $IPC -F $IPC -X $IPC -Z On autorise tout sur l'interface de loopbak $IPC -A INPUT -i lo -j ACCEPT On autorise tout avec le serveur srvlnx quelque soit la salle $IPC -A INPUT -s j ACCEPT $IPC -A INPUT -s j ACCEPT $IPC -A INPUT -s j ACCEPT $IPC -A INPUT -s j ACCEPT Vous insèrerez vos règle ICI On rejette tout le reste avec des logs $IPC -A INPUT -j LOG --log-prefix 'LAST RULE REJECT: ' $IPC -A INPUT -j REJECT on affiche toute les règles de la table filter $IPC -t filter -L -nv l'exécuter sur votre poste ( sous root ) les messages de log se trouvent dans /var/log/messages faite un ssh vers le poste réel depuis le serveur virtuel fonctionne t'il? NON quelle règles le bloque Le reject final : on peut voir dans les logs : Jan 25 10:07:33 localhost kernel: LAST RULE REJECT IN=eth0 OUT= MAC=00:13:d4:66:91:a3:00:13:d4:66:88:a2:08:00 SRC= DST= LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=22 DPT=37737 WINDOW=5792 RES=0x00 ACK SYN URGP=0 On a tout autorisé en OUTPUT ( iptables -P OUTPUT ACCEPT ) par contre on rejette tout en INPUT un petit exemple avec un tcpdump sur executé sur le serveur virtuel nous donnent :

4 ~] tcpdump -vvv -n -i eth0 host tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes paquet d'initialisation de la connexion (SYN): 10:15: IP (tos 0x0, ttl 64, id 56293, offset 0, flags [DF], proto: TCP (6), length: 60) > : S, cksum 0x2c87 (correct), : (0) win 5840 <mss 1460,sackOK,timestamp ,nop,wscale 7> paquet de retour de la machine :15: IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: TCP (6), length: 60) > : S, cksum 0xe591 (correct), : (0) ack win 5792 <mss 1460,sackOK,timestamp ,nop,wscale 4> la règle REJECT a généré un ICMP host unreachable 10:15: IP (tos 0xc0, ttl 64, id 12431, offset 0, flags [none], proto: ICMP (1), length: 88) > : ICMP tcp port unreachable, length 68 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: TCP (6), length: 60) > : S : (0) ack win 5792 <mss 1460,sackOK,timestamp [ tcp]> rajouter une règle d'autorisation des flux de retour tcp avec log ( message TCP RETOUR ) On rajoute une règle permettant sur l'input les paquets ayant comme port source 22 qui ne sont pas des demandes de connexions ( qui n'ont pas le flag SYN positionné seul ) $IPC A INPUT p tcp sport 22! syn j LOG log prefix 'ACCEPT ESTABLISHED SSH ' $IPC A INPUT p tcp sport 22! syn j ACCEPT Si on voulait permettre au poste toutes les réponses sur tous les protocoles TCP on écrirait simplement : $IPC A INPUT p tcp! syn j LOG log prefix 'ACCEPT ESTABLISHED ' $IPC A INPUT p tcp! syn j ACCEPT refaite le ssh vers le poste réel en vérifiant les messages de log ce coup ci ça marche et dans les logs on peut voir Jan 25 10:32:01 localhost kernel: ACCEPT ESTABLISHED :IN=eth0 OUT= TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=22 DPT=39602 WINDOW=5792 RES=0x00 ACK SYN URGP=0 lancer maintenant depuis votre poste réel un scan tcp vers le serveur virtuel quels sont les ports ouverts? Aucun

5 autoriser les demandes de connexions ssh et www vers votre serveur virtuel avec log (message SSHSRV et WWWSRV) $IPC A INPUT p tcp dport 22 syn j LOG log prefix 'SSHSRV ACCEPT :' $IPC A INPUT p tcp dport 22 syn j ACCEPT $IPC A INPUT p tcp dport 80 syn j LOG log prefix 'WWWSRV ACCEPT :' $IPC A INPUT p tcp dport 80 syn j ACCEPT vérifier que cela fonctionne convenablement [vmuser@216 pc01 ~]$ ssh vmuser@ password: dans les log on a : Jan 25 11:08:09 localhost kernel: SSHSRV ACCEPT :IN=eth0 OUT= TOS=0x00 PREC=0x00 TTL=64 ID=20562 DF PROTO=TCP SPT=60608 DPT=22 WINDOW=5840 RES=0x00 SYN URGP=0 [vmuser@216 pc01 ~]$ wget 12:08:03 => `index.html' Resolving 216 pc Connecting to :80... connected. HTTP request sent, awaiting response OK Length: 44 [text/html] 12:08:03 (4.20 MB/s) `index.html' saved [44/44] dans les logs on a : Jan 25 12:10:15 localhost kernel: WWWSRV ACCEPT :IN=eth0 OUT= TOS=0x00 PREC=0x00 TTL=64 ID=11564 DF PROTO=TCP SPT=38195 DPT=80 WINDOW=5840 RES=0x00 SYN URGP=0 autoriser les ftp ( passif et actif ) depuis la machine réelle on logguera chacune des règles avec un message différent En ajoutant la règle $IPC A INPUT p tcp syn dport 21 j LOG log prefix 'FTPSRV ACCEPT :' $IPC A INPUT p tcp syn dport 21 j ACCEPT [vmuser@216 pc01 ~]$ ftp Connected to ProFTPD Server (ProFTPD Default Installation) [ ] 500 AUTH not understood Name (216 pc15:vmuser): phtest 331 Password required for phtest. Password: 230 User phtest logged in. 230 Down: 0 Files (0mb) Up: 0 Files (0mb) 10,000,000:1 CR: LEECH Remote system type is UNIX. Using binary mode to transfer files. ftp> dir 200 PORT command successful 150 Opening ASCII mode data connection for file list drwx 2 phtest phtest 105 Sep 27 15:54 Desktop drwxrwxr x 2 phtest phtest 23 Sep 27 14:57 Documents drwxrwxr x 2 phtest phtest 23 Sep 27 14:57 Download

6 drwx 9 phtest phtest 152 Oct 2 15:58 Maildir drwx 5 phtest phtest 63 Sep 27 15:54 tmp 226 Transfer complete. 226 Down: 0 Files (0mb) Up: 0 Files (0mb) 10,000,000:1 CR: LEECH le mode actif fonctionne sans règles supplémentaires ftp> passive Passive mode on. ftp> dir 227 Entering Passive Mode (192,168,216,15,136,235). ftp: connect: Connection refused ftp> par contre le mode passif est refusé cette ligne est instructive 227 Entering Passive Mode (192,168,216,15,136,235). elle signifie que le serveur dit au client de le contacter sur le port 136x = et dans les logs on trouvent : Jan 25 11:21:34 localhost kernel: LAST RULE REJECT :IN=eth0 OUT= TOS=0x00 PREC=0x00 TTL=64 ID=7154 DF PROTO=TCP SPT=37478 DPT=35051 WINDOW=5840 RES=0x00 SYN URGP=0 il faut donc autoriser le client a pouvoir contacter le serveur sur tous les ports > 1024 il faut donc pour le ftp passif $IPC A INPUT p tcp syn sport 1024:65535 dport 1024:65535 j LOG log prefix 'SUP 1024 ACCEPT :' $IPC A INPUT p tcp syn sport 1024:65535 dport 1024:65535 j ACCEPT en modifiant la config de proftpd (/etc/proftpd.conf ) en mettant par exemple PassivePorts on pourrait restreindre la règle à : $IPC A INPUT p tcp syn sport 1024:65535 dport 35051:35100 j LOG log prefix 'SUP 1024 ACCEPT :' $IPC A INPUT p tcp syn sport 1024:65535 dport 35051:35100 j ACCEPT par contre on accepterait un maximum de 50 connexions