Protect against unwanted Router Advertisements (RA)

RA is used by auto-configuration. What is it auto-configuration ? It's a solution who allows devices to choose their own address.
How it works ?

Autoconfiguration is a two-step process:

- Host has to obtain prefix information to configure its address. To do this, it sends a Router Solicitation (RS). It's a multicast frame (ICMPv6 RS) for each router.
- Router advertisement (RA) is sent back by the router. These RAs are also sent periodically by the router. In our case, it's an instantaneous response.

It's a helpful solution for administrator but it's also a good way for hacker to shunt data flows. A hacker can send a wrong RA to a device. In this case, there are 2 issues, denial of service or man in the middle attack. If the hacker sends his own address (gateway information in the RA) all the flows can pass through him. Another error can occur with a misconfigured device, the host should obtain a wrong prefix. To protect against this kind of attack you can use this simple configuration (Port ACL) to stop untrusted RA. The access-list stop RA on all the untrusted interface. Just keep free interface where the router is plugged:

ipv6 access-list filter_RA
 remark Block Rogue RA
 deny icmp any any router-advertisement
 permit any any
!
interface gigabitethernet 1/0/10
 ipv6 traffic-filter filter_RA in

On the Catalyst 6500 and 4500 it's possible to use a macro to configure this kind of PACL:

interface gigabitethernet 1/0/10

 ipv6 nd raguard 

It's also possible to filter DHCPv6 with a PACL and just authorize the interface of the server to send response:

ipv6 access-list filter_DHCP
 remark Block traffic from DHCP to client
 deny udp any eq 547 any eq 546
 permit any any
!
interface gigabitethernet 1/0/10
 ipv6 traffic-filter filter_DHCP in

Provide TFTP address by DHCP

A simple memo (in english!) to explain the configuration of DHCP option 150:

Cisco phone use TFTP to download their configuration. To determine the address of the TFTP server, the phone (when the phone starts) sends a DHCP request with option 150 (DHCP 150 provide address of the TFTP server). Below, you will find a simple way to configure this option on a Cisco switch:


 ip dhcp pool DHCPPool
   network 192.162.1.0 255.255.255.0
   option 150 ip 192.168.1.200
   default-router 192.168.1.1

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