Stopper les usurpations d'adresse MAC

De nombreux outils permettent de corrompre les tables MAC des hosts situés sur un réseaux. Un exemple fréquent est l'usurpation d'adresse MAC. Cette opération qui est très simple à réaliser permet de récupérer du trafic censer transiter par la victime.
La technique utilisée pour stopper cette attaque est le DAI (Dynamic ARP inspection) sur les switchs Cisco.
Le but du DAI est d'étudier toutes les trames ARP qui transitent par les ports du réseaux. Pour se faire, le DAI utilise la base créée par le DHCP snooping qui est aussi une technologie Cisco. Une fois activé, le DHCP snooping créé une base qui relie le port du switch, l'adresse IP fixée par le DHCP et l'adresse MAC
(le DHCP snooping n'est pas présenté dans ce post, mais peut-être bientôt :)). Donc toute trame ARP qui circule sur le réseau et qui ne correspond pas à cette base est droppée. Ci-dessous un exemple de  configuration:

Activation du DHCP snooping, la configuration ci-dessous n'est pas complète car certaines précautions non présentées sont à prendre en compte (port serveur, lien trunk...):
Switch(config)#ip dhcp snooping
Switch(config)#ip dhcp snooping vlan 10-5

Exemple de base créée:
Switch#show ip dhcp snooping binding
MacAddress          IpAddress        Lease(sec)  Type           VLAN  Interface
------------------  ---------------  ----------  -------------  ----  --------------------
00:1C:23:14:12:27   192.168.51.10    691130      dhcp-snooping   11    FastEthernet0/1
Total number of bindings: 1

Activation du DAI sur un switch:
Switch(config)#ip arp inspection vlan 10-15
Switch(config)#interface range FastEthernet0/1 – 24
Switch(config-if-range)#no ip arp inspection trust

Ci-dessous, une tentative de ARP spoofing (attaque man-in-the-middle) réalisée sur le réseau et droppée par le switch:
*Mar  1 06:48:16.546: %SW_DAI-4-DHCP_SNOOPING_DENY: 1 Invalid ARPs (Res) on Fa0/3, vlan 11.([001c.2314.1227/192.168.51.1/5c26.0a33.ba85/192.168.51.12/06:48:16 UTC Mon Mar 1 1993])


Remarque:
il est nécessaire de désactiver le DAI sur les interfaces trunks, Access point et tous les ports où les adresses IP sont fixes. Ou l'on peut utiliser des ACLs ce qui supprime toute la souplesse du protocole pour fixer les adresses MACs autorisées sur un port.

Filtrage ICMP Redirect sous Windows XP

Le but de ce billet est de décrire la méthode pour que Windows XP ne subisse pas les attaques par ICMP redirect. Petit rappel sur l'ICMP redirect:
L'attaque par ICMP redirect consiste à envoyer des messages (type ICMP 'redirect') à une cible. Le message généré proposera à la victime de passer par un nouveau chemin pour joindre un réseau. De cette manière la machine ne pourra joindre un réseau ou une machine puisque la gateway proposée sera erronée.

Ci-dessous vous trouverez un exemple d'ICMP Redirect généré via scapy:


ip=IP()
ip.src='192.168.20.1'
ip.dst='192.168.20.66' => poste attaqué
icmp=ICMP()
icmp.type=5
icmp.code=1
icmp.gw='192.168.20.100' => GW erronée
ip2=IP()
ip2.src='192.168.20.66' => poste attaqué
ip2.dst='100.100.100.0' => route modifiée
ip2.display
send(ip/icmp/ip2/UDP())

Afin de ce prémunir de ce type d'attaque sur un poste Windows XP, il est cependant possible de modifier la clé de registre Ci-dessous:

HKEY_LOCAL_MACHINE\System\Currentcontrolset\Services \Tcpip\Parameters

EnableICMPRedirect

En passant la valeur à 0 (qui est par défaut à 1), le poste n'interprètera pas ce type de message.

Filtrer la redistribution OSPF

Dans certains cas il peut être souhaité de filtrer l'annonce des routes OSPF. Par exemple à des fins de sécurité pour ne pas annoncer un réseau choisi. L'exemple ci-dessous permet d'annoncer que les sous-réseaux prédéfinis:

router ospf 10
redistribute connected subnets route-map filter_ospf ==> filtre les routes connected
redistribute static subnets route-map filter_ospf ==> filtre les routes statiques
network 1.1.1.11 0.0.0.0 area 0
!
ip access-list standard distributed_route
permit 192.168.1.0 0.0.0.255
!
route-map filter_ospf permit 10
match ip address distributed_route
set metric 20
set metric-type type-1

Gestion de l'archive sur catalyst

La gestion des archives par l'IOS fournie différents mécanismes de gestion des configs et des logs.
L'exemple ci-dessous permet de sauvegarder la configuration toutes les 24heures sur une carte flash externe:

archive
path disk0:/hostname_
maximum 14
time-period 1440

Validation:

dir disk0:/
5 -rw- 68004 Jun 6 2011 10:11:58 +02:00 hostname_Jun--6-10-11-49.310-CET-0


L'exemple ci-dessous permet de sauvegarder la configuration toutes les 24heures sur un serveur ftp distant:

ip ftp username cisco
ip ftp password cisco
archive
path ftp://10.10.10.10/hostname_
write-memory

L'exemple ci-dessous permet de suivre les différents changements appliqués à la configuration:

archive
log config
logging enable
hidekeys

Validation:

show archive log config all
idx sess user@line Logged command
670 63 admin@vty1 | interface GigabitEthernet1/1/44
671 63 admin@vty1 | no channel-group 430 mode active

NAT64 et DNS64

La normalisation par l'IETF du mécanisme de translation d'adresse IPv6 vers IPv4 est effective (RFC6144). Elle repose sur le NAT64 (RFC6146 ) et le DN64 (RFC6147). Je pense que cette dernière sera une composante importante dans les mécanismes de coexistence entre IPv4 et IPv6.

Le but de ce mécanisme est de préciser le fonctionnement général d'une communication entre une machine en IPv6 et une machine en IPv4. Il est à noter que ce type de protocole (NAT64) repose sur une communication client/serveur.

L'intérêt de cette RFC est de permettre à une entreprise ou un ISP dont seule une plage d'adresse IPv6 leur sera affectée de continuer à communiquer avec le reste du monde (en IPv4).

Le déploiement de ce mécanisme nécessite 2 équipements:

• Le routeur qui réalisera le NAT64
• Le DNS64 qui permet de traduire un enregistrement A en un enregistrement AAAA

Le schéma ci-dessous détail la mise en œuvre:

1. Le client réalise une requête DNS vers le DNS64
2. Si le domaine ne possède pas d'enregistrement AAAA (retour message erreur) le serveur DNS64 effectue une requête A
3. Le serveur IPv6 génère une adresse IPv6 avec le préfixe 64:FF9B::/64 et renvoie cette dernière au client
4. Le client reçoit une adresse AAAA
5. Le client initie une communication avec le serveur au travers du routeur NAT64
6. Le routeur NAT64 créé une session via l'association adresse IP + port

Les implémentations existantes de NAT64:

- Ecdysis, opensource

- Cisco dans une version IOS XE

Les implémentations existantes de DNS64:

- Bind 9.8.0

Communication entre VRF (Astuce)

Le but des VRFs est de cloisonner plusieurs instances de routage sur les mêmes équipements.
Cependant, à des fins de tests ou pour une config un peu particulière il peut être souhaité de faire communiquer 2 VRFs entre elles. Pour se faire, il existe une petite astuce qui consiste à tirer un câble entre 2 ports du switch et de les configurer en tant qu'interface de niveau 3. Le schéma ci-dessous est un exemple de cette configuration:


La configuration à appliquer:

ip vrf VRF_A
rd 2:2
!
ip vrf VRF_B
rd 3:3
!
ip vrf VRF_B
rd 4:4
!
vlan 200
name in_VRF_A
!
vlan 100
name in_VRF_B
!
vlan 150
name in_VRF_C
!
interface GigabitEthernet10
no switchport
ip vrf forwarding VRF_A
ip address 10.10.10.10 255.255.255.0
!
interface GigabitEthernet11
no switchport
ip vrf forwarding VRF_B
ip address 10.10.10.20 255.255.255.0
!
interface GigabitEthernet12
no switchport
ip vrf forwarding VRF_A
ip address 10.10.11.10 255.255.255.0
!
interface GigabitEthernet11
no switchport
ip vrf forwarding VRF_C
ip address 10.10.11.20 255.255.255.0
!
interface Vlan100
ip vrf forwarding in_VRF_A
ip address 100.100.100.100 255.255.255.0
!
interface Vlan150
ip vrf forwarding in_VRF_C
ip address 150.150.150.150 255.255.255.0
!
interface Vlan200
ip vrf forwarding VRF_B
ip address 200.200.200.200 255.255.255.0

!

ip route vrf VRF_A 100.100.100.0 255.255.255.0 10.10.10.20
ip route vrf VRF_A 150.150.150.0 255.255.255.0 10.10.11.20
!
ip route vrf VRF_C 100.100.100.0 255.255.255.0 10.10.11.10
ip route vrf VRF_C 200.200.200.0 255.255.255.0 10.10.11.10
!
ip route vrf VRF_B 150.150.150.0 255.255.255.0 10.10.10.10
ip route vrf VRF_B 200.200.200.0 255.255.255.0 10.10.10.10

IPv6: un point sur les Opérateurs français et les accès aux particuliers

Ce post a pour vocation de lister l'avancement du déploiement d'IPv6 chez les principaux opérateurs français. Je n'ai étudié que les offres réservées aux particuliers.

SFR:
Ils annoncent la possibilité de passer en IPv6 sur les neufBox d'ici cet été:
http://www.sfr.com/les-mondes-numeriques/les-nouvelles-technologies/ipv6-un-nouveau-protocole

Orange:
La livebox n'est pas aujourd'hui compatible avec IPv6. L'opérateur a annoncé sur twitter que cette dernière serait compatible dans ça nouvelle génération disponible à l'horizon de l'été 2012.
Si cela est confirmé, l'impact sera important puisque seules les nouvelles livebox n'auront cette fonctionnalité. Le changement de parc est donc considérable.
https://twitter.com/#!/presseorange/status/25907079453614080


Free:
Ils ont déployé la technologie 6rd qui permet d'offrir un accès IPv6 aux clients dégroupés et ceux depuis 2007.
http://www.iliad.fr/presse/2007/CP_IPv6_121207.pdf
Aujourd'hui aucune information circule sur les accès non dégroupés.


Bouygues Telecom:
La seule information que j'ai trouvé à leur sujet est que la nouvelle Bbox fibre supporte IPv6 en dual stack après upgrade FW .