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

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 .

Flash or not flash !

La carte SUP-720-10G possède 2 cartes flash interne (sur la RP et la SP). Petit problème, elle change de nom entre le passage en rommon et le fonctionnement normal !

• Une pour la SP « Switching Processor » (flash_1)
  

• Une pour la RP « Routing Processor » (flash_2)

En CatOS la SP démarrais avec la flash_1 et la RP avec la flash_2 pour l'IOS. Ces deux flash possédaient le même nom mais sur 2 OS différents.

Aujourd'hui le CatOS et l'IOS sont mutualisés dans l'IOS. La SP et la RP démarrent donc avec le même binaire situé sur une seule flash (flash_1). La flash_2 n'est pas utilisée mais reste visible après le boot.

Il est bon de savoir que les flashs changent de nomination entre le boot (rommon) et une fois la phase de boot terminée. Cette remarque est importante pour identifier les variabales de boot, le stockage des différentes sauvegardes...

En résumé en phase de boot (rommon):

• SP => Bootflash:

• RP => Non Accessible

Après la phase de boot:

• SP => Sup-bootflash:

• RP => Bootflash:

Rmq: je n'ai pas abordé le cas des disques ATA qui modifient aussi leur identification!

Sauvegarde équipements réseaux via pexpect

Ci-dessous un petit script qui permet de lancer les commandes de sauvegarde TFTP via pexpect sur un composant Cisco:

import pexpect
IPa = raw_input('Entrer l adresse IP du composant:')
IP = 'ssh admin@'+IPa
child = pexpect.spawn (IP)
child.expect ('Password: ')
pwd = raw_input('Entrer le password du composant:')
print pwd
child.sendline (pwd)
child.expect ('#')
child.sendline ('copy running-config tftp:')
child.expect ('\? ')
child.sendline ('10.10.10.20')
child.expect ('\? ')
host = IPa+'.cfg'
child.sendline (host)
child.expect ('#')
child.sendline ('exit')
print child.before

Idem pour un Altéon:

import pexpect
child = pexpect.spawn ('ssh admin@10.10.10.10')
child.expect ('password: ')
child.sendline ('admin')
child.expect (['Main#','[y]'])
i = child.expect (['Main#','[y]'])
if i == 0:
print 'Connexion Ok'
elif i == 1:
child.sendline ('y')
else:
p.expect(pexpect.EOF)
print 'Timeout connexion'
child.expect ('Main#')
child.sendline ('/cfg/ptcfg')
child.expect ('server: ')
child.sendline ('10.10.10.20')
child.expect ('server: ')
child.sendline ('hostname.cfg')
child.expect ('server: ')
child.sendline ('')
print child.before

Idem pour un ISG1000:

import pexpect
child = pexpect.spawn ('ssh admin@10.10.10.10')
child.expect ('password: ')
child.sendline ('admin')
child.expect ('>')
child.sendline ('exec save config to tftp 10.10.10.20 hostname.cfg')
child.expect ('>')
print child.before

N'étant pas familié du scripting, je suis preneur de toute amélioration à apporter.

NAT sur Catalyst 6500

Le NAT sur les catalyst n'étant réalisable que sur les châssis 6500 (même les 3750 ne supporte pas le NAT), cette configuration est peut documentée. Dans certains cas, il est cependant nécessaire de réaliser une config de NAT autre part que sur un pare-feu.

Exemple de configuration:



Voici la configuration à appliquer pour reproduire le schéma ci-dessus:

ip nat pool testNAT 201.200.200.200 201.200.200.200 netmask 255.255.255.0
ip nat inside source list 150 pool testNAT overload
access-list 150 permit ip 192.168.20.0 0.0.0.255 200.200.200.0 0.0.0.255
!
interface Vlan100
ip address 192.168.20.1 255.255.255.0
ip nat inside
!
interface Vlan200
ip address 201.200.200.1 255.255.255.0
ip nat outside

La commande suivante permet de valider l'état du NAT:

show ip nat translations

Afin de pousser un peu plus le diagnostique, il est nécessaire
d'activer le mode debug avec la commande:
 debug ip nat

Sécurisation SNMP sur Catalyst Cisco

SNMP est une source importante d'information sur les composants réseaux. La communauté public est trop souvent laissée par défaut sur les composants. Si vous êtes appelé à utiliser SNMP, je conseil d'utiliser SNMPv3 et de filtrer les adresses IP qui ont l'accès en lecture ou lecture/écriture.

Ci-dessous la configuration à appliquer pour du SNMPv3 sur un catalyst Cisco (configuration en lecture avec du filtrage sur l'IP source):
access-list <Numero_ACL> permit
access-list <Numero_ACL> deny any

snmp-server group <Nom_groupe> v3 priv snmp-server user <Nom_user> <Nom_groupe> v3 auth md5 <password> priv des <password> access <Numero_ACL>
Exemple de configuration:
access-list 1 permit 192.168.1.0 0.0.0.255
access-list 1 deny any

snmp-server group ReadOnly v3 priv snmp-server user admin ReadOnly v3 auth md5 password priv des password access 1

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