Ca c'est fait !

Votre ticket est payé, vous êtes bien enregistré pour le SSTIC.

Sécuriser l'authentification sur les switchs

Pas toujours simple de comprendre le fonctionnement et la configuration de l'authentification sur les switchs, pour cela voici un petit récapitulatif

Cisco:
Chez Cisco il y a trois types de connexion bien distinct:
- en telnet ou ssh: line vty
- par le port console: line con, petit conseil utiliser la commande logging synchronous
- et le dernier que je n'ai que rarement vu fonctionner sert aux connexions type modem à distance: line aux
Je ne vais traiter que le premier qui me semble le plus intéressant
La première protection est de créer un couple username password soit directement dans la configuration line vty:
Switch(config)#line vty 0 4
Switch(config-line)#login
Switch(config-line)#password vty-password
soit en utilisant une liste locale dans la conf du switch:
Switch(config)#username enrico password enrico-password
Switch(config)#username rodrigo password rodrigo-password
Switch(config)#line vty 0 4
Switch(config-line)#login local
Rmq: bien faire attention qu'il existe des users dans la conf avant d'utiliser la commande login local, car lors de la prochaine connexion en telnet il est impossible de se connecter (pas de login local alors que le switch en cherche un pour vous authentifier).
authentification pour le mode priviligier (enable):
enable secret enable-secret
enable password enable-password
Si l'authentification par password et secret sont tous les 2 configurés, par défaut le secret sera utilisé.
Le secret est crypté dans la conf contrairement au password
Il est donc fortement conseillé de ne pas mettre le même password et secret afin de ne pas mettre en clair dans la con l'enable secret.
restriction de connexion par adresse réseaux:
pour cela il faut créer une ACL:
access-list 1 permit 192.168.1.12
access-list 1 permit 192.168.1.15
access-list 1 permit 192.168.10.15
puis entrer la commande:
line vty 0 4
access-class 1 in

Configuration pour une connexion ssh (connexion sécurisée):
Switch(config)#hostname SwitchA
SwitchA(config)#ip domain-name mydomain.com
SwitchA(config)#crypto key generate rsa
The name for the keys will be: SwitchA
Choose the size of the key modulus in the range of 360 to 2048 for your
General Purpose Keys. Choosing a key modulus greater than 512 may take
a few minutes.
How many bits in the modulus 512: 1024
Generating RSA keys ...
OK
SwitchA(config)#ip ssh time-out 60
SwitchA(config)#ip ssh authentication-retries 2
SwitchA(config)#line vty 0 4
SwitchA(config-line)#transport input ssh

Vista et DHCPv6

Vista implante le protocole DHCPv6 or après avoir implanté un serveur DHCPv6, je n'arrivais pas à obtenir une adresse via le DHCP.

Après plusieurs essais, je me suis rendu compte qu'il fallait modifier un champ des paquets Router advertisement : Avant modification du RA distribué par le routeur

0000 33 33 00 00 00 01 00 19 06 2f e9 fc 86 dd 6e 00 33...... ./....n.
0010 00 00 00 40 3a ff fe 80 00 00 00 00 00 00 02 19 ...@:... ........
0020 06 ff fe 2f e9 fc ff 02 00 00 00 00 00 00 00 00 .../.... ........
0030 00 00 00 00 00 01 86 00 2e db 40 "20" 07 08 00 00 ........ ..@ ....
0040 00 00 00 00 0b b8 01 01 00 19 06 2f e9 fc 05 01 ........ .../....
0050 00 00 00 00 05 dc 03 04 40 e0 00 27 8d 00 00 09 ........ @..'....
0060 3a 80 00 00 00 00 20 00 12 34 45 67 89 ac 00 00 :..... . .4Eg....
0070 00 00 00 00 00 00 ......

Quand vista reçoit cet RA, il ne produit pas de DHCPv6 solicitation
Après la commande ipv6 nd managed-config-flag sur l'interface réseau d'un routeur cisco. Nouvel RA :
0000 33 33 00 00 00 01 00 19 06 2f e9 fc 86 dd 6e 00 33...... ./....n.
0010 00 00 00 40 3a ff fe 80 00 00 00 00 00 00 02 19 ...@:... ........
0020 06 ff fe 2f e9 fc ff 02 00 00 00 00 00 00 00 00 .../.... ........
0030 00 00 00 00 00 01 86 00 2e 5b 40 "a0" 07 08 00 00 ........ .[@.....
0040 00 00 00 00 0b b8 01 01 00 19 06 2f e9 fc 05 01 ........ .../....
0050 00 00 00 00 05 dc 03 04 40 e0 00 27 8d 00 00 09 ........ @..'....
0060 3a 80 00 00 00 00 20 00 12 34 45 67 89 ac 00 00 :..... . .4Eg....
0070 00 00 00 00 00 00
Maintenant Vista envoie un DHCPv6 solicitation et reçoit une adresse du serveur DHCP.

Rendre anonyme les traces PCAP avec pktanon

Il arrive régulièrement de déposer des traces d'un trafic réseau sur un forum ou un blog. Pour garder l'anonymat des traces, on est obligé de camoufler les IPs ou autre champ des paquets. L'outil pktanon permet l'automatisation de cette démarche.

Allez hop, je l'installe :

• Décompression de pktanon :
  

wget http://www.tm.uka.de/software/pktanon/download/pktanon-1.2.3-dev.tar.gz
tar xfz pktanon-1.2.3-dev.tar.gz

• Installation des dépendances :
  

su
apt-get install libxerces-c2-dev libboost-dev

• Installation :
  

   ./configure
  make
  su

make install


Au préalable j'ai récupéré une trace pcap avec wireshark. ensuite je modifie le fichier ''settings_identity.xml situé dans le répertoire profile. Dans l'exemple ci-dessous, mon fichier source de se nomme trace.pcap et je le modifie en trace_new.pcap. Je valorise donc de la manière suivante le fichiersettings_identity.xml '':
name="Input">trace.pcap
name="Output">trace_new.pcap
Dans ma trace, je souhaite modifier l'adresse IP source (celle de mon poste par exemple):
anon="AnonBytewiseHashSha1" name="IpSourceip", par défaut le champ anon est à AnonIdentity
Ensuite, il suffit de lancer l'outil pktanon:
pktanon settings_identity.xml
Paquet d'origine:

tcpdump -neXv -c 1 -r trace.pcap

reading from file trace.pcap, link-type EN10MB (Ethernet)
21:15:30.665242 00:23:54:1c:4c:a6 > 00:07:cb:21:1e:27, ethertype IPv4 (0x0800),
length 71: (tos 0x0, ttl 64, id 7617, offset 0, flags DF, proto TCP (6), length 57) 
192.168.0.10. 53135 > 65.54.172.110.1863: P, cksum 0xae82
(incorrect (-> 0xbe20), 1181321880:1181321885(5) ack 1801540939 win 594  
0x0000:  4500 0039 1dc1 4000 4006 6ea7 c0a8 000a  E..9..@.@.n..... 
0x0010:  4136 ac6e cf8f 0747 4669 8a98 6b61 554b  A6.n...GFi..kaUK 
0x0020:  8018 0252 ae82 0000 0101 080a 0010 45b7  ...R..........E. 
0x0030:  002e b810 504e 470d 0a                   ....PNG..

Paquet formaté:
tcpdump -neXv -c 1 -r trace_new.pcap

reading from file trace_new.pcap, link-type EN10MB
(Ethernet)  21:15:30.665242 da:d5:44:a7:12:59 > 00:07:cb:21:1e:27,
ethertype IPv4 (0x0800), length 71: (tos 0x0, ttl 64, id 7617, offset 0,
flags DF, proto TCP (6), length 57) 246.142.218.253 .53135 >
65.54.172.110.1863: P, cksum 0x6745 (incorrect (-> 0xad46),
1181321880:1181321885(5) ack 1801540939 win 594   
0x0000:  4500 0039 1dc1 4000 4006 5dcd f68e dafd  E..9..@.@.].....  
0x0010:  4136 ac6e cf8f 0747 4669 8a98 6b61 554b  A6.n...GFi..kaUK  
0x0020:  8018 0252 6745 0000 0101 080a 0010 45b7  ...RgE........E.  
0x0030:  002e b810 504e 470d 0a                   ....PNG..

Accès de secours au module FWSM

Pour accèder à la configuration d'une carte FWSM sur un châssis Cisco 6500 on utilise généralement une connexion SSH. Or si la carte n'est plus accessible en SSH (se couper l'herbe sous le pied est si vite arrivé:)) et la carte n'ayant pas de port console, la seule solution est de se connecter au châssis puis de simuler l'accès console. Cet accès est un pseudo-accès en telnet comme on peut le voir dans l'exemple ci-dessous:
CAT#session switch 1 slot 3 processor 1
The default escape character is Ctrl-^, then x.
You can also type 'exit' at the remote prompt to end the session
Trying 127.0.0.31 ... Open
Cependant, l'accès en telnet depuis un châssis est souvent refusé par l'administrateur afin d'éviter les rebonds. La solution est donc de créer des ACLs qui autorisent la connexion au module FWSM, pour se faire il suffit de suivre la configuration ci-dessous (remarque: cet exemple s'applique à un cluster VSS):
access-list 1 permit 127.0.0.0 0.0.0.255
access-list 1 permit 127.0.1.0 0.0.0.255! Accès au module dans le switch 2
line vty 0 15
access-class 1 out
transport input telnet ssh
transport output telnet
session switch 1 slot 3 processor 1
CAT#session switch 1 slot 3 processor 1
The default escape character is Ctrl-^, then x.
You can also type 'exit' at the remote prompt to end the session
Trying 127.0.0.31 ... Open
User Access Verification
Password:

CAT#session switch 2 slot 3 processor 1
The default escape character is Ctrl-^, then x.
You can also type 'exit' at the remote prompt to end the session
Trying 127.0.1.31 ... Open
User Access Verification
Password:

Evite les rebonds:

CAT#telnet 192.168.10.61

Trying 192.168.10.61 ...

% Connections to that host not permitted from this terminal

Debug firewall ISG

Faire un snoop sur un firewall juniper et récupérer les traces au format pcap est plutôt sympa. Cependant quand seulement le premier paquet (d'une session, càd le SYN) est récupéré dans le buffer du debug car les autres sont traités en ASICs, c'est moins facile pour investiguer. Par chance quelques commandes permettent d'éviter le passage en ASICs.

Il est conseillé d'activer des filtres si vous ne voulez pas être pollué ou pire (crash cpu)! Je ne détail les différents filtres, ils sont disponible dans le menu:
snoop filter XXXXX
Lancement du snoop en mode détail:
snoop detail
snoop
La commande magique qui permet de faire transiter les paquets dans la CPU a été appliquée au préalable sur une policy:
set policy id 3
set no-hw-sess
surtout ne pas oublier de désactiver cette commande une fois les traces prises.
Pour visualiser les flux il existe deux possibilités:
En direct sur la console par la commande: get db stream
Ou après transformation au format pcap et une lecture via un client wireshark sur votre poste. Pour se faire il faut récupérer les traces via TFTP:
get db stream > tftp XXX.XXX.XXX.XXX traces.pcap