Archivo del sitio

Manejar la Command Line de CISCO con más destreza

Manejar la Command Line con más destreza.

R1#show run | include (router|network)

Este comando muestra la configuración que esta en el running solamente la parte que tiene las palabras “router” o “Network”

Por ejemplo para saber que rutas están incluidas en cada protocolo:
c1
Otro camino para mostrar las rutas del comando show, es usar Filtros.

R1# show ip route eigrp | section (35|50|64|200)

usar “section” en lugar de “include” es porque la tabla puede ser muy grande y solo queremos ver la lista en unas pocas lineas. ej. 172.16.200.0/22
c2

Otro ejemplo sería el caso que queremos mostrar solo los interfaces loopback en una salida del comando brief.

c3
R1# show ip int brief | i \.

Este commando muestra todos los interfaces que tienen ipv4 configurado. Si tienes alguna sub-interfaces que no tienen ninguna dirección IP, también se mostrar

En caso de usar  \..*\. Tendría que probar para saber que nos mostraría no tengo nada claro.

R1# show ip int brief | i \..*\.

 

c4

Otros filtros muy interesantes para la ayuda “help”. 

Cuando quieres saber un commando y su descripción en particular para saber si quieres seleccionar ese u otro, ponemos “?” y damos al enter. Después obtenemos como salida en pantalla una maravillosa lista de comandos.

Si por ejemplo queremos encontrar la descripción de “standby” tenemos que darle varias veces a la barra espaciadora hasta  llegar al comando.

Lo ideal es aplicar un filtro cuando veamos “–MORE–” usando la tecla “+”, por ejemplo la del teclado numérico.

+regex es incluir

-regex es excluir

?regex es … no se probarlo en una IOS moderna.
c5

 

show interface | include is up|BW|load

 RtrA#show int | inc is up|BW|load GigabitEthernet0/0 is up, line protocol is up   MTU 1500 bytes, BW 1000000 Kbit/sec, DLY 10 usec,      reliability 255/255, txload 1/255, rxload 1/255

 

El comando “section” es muy usable. Por ejemplo, 

show run | sec interface

show run | sec crypto

show run | sec router

show run | sec crypto|-list

 

Cisco ofrece el comando  <i>alias</i> command

Es un comando nuevo para mi. Normalmente usamos include/begin/exclude el alias me parece genial para entornos de trabajo

srb - Show Running-Config | Begin
sre - Show Running-Config | Exclude
sri - Show Running-Config | Include
srint - Show Running-Config Interface"

Hay personas que usan estos commando en los examines con los laboratorios de CCIE para ir más rápido o lógicamente en el mercado laboral donde los comandos pueden llegar a ser repetitivos. ””To make life easier, Cisco offers the alias command, which can help dispel part of this repetition.

“”Let’s take a closer look at the alias command. This is a Global Configuration command. To use it, enter the alias command and identify which privilege level you want to specify the alias for. Here are some examples:

  • Use alias exec for Privileged Mode (any command you use at the router# prompt).
  • Use alias configure for Global Configuration Mode (any command you use at the router(config)# prompt).
  • Use alias interface for Interface Configuration Mode (any command you use at the router(config-if)# prompt).

After specifying the privilege level, enter the alias you want to create and the command you want it to stand for.

As far as I know, you can configure an alias to do anything that you can do at the command line. Of course, there’s a catch: An alias can’t move between modes, type in passwords, or do anything interactive for you.”””

Alias examples

srb - Show Running-Config | Begin
Router(config)# alias exec srb show running-config | begin
sre - Show Running-Config | Exclude
Router(config)# alias exec sre show running-config | exclude
sri - Show Running-Config | Include
Router(config)# alias exec sri show running-config | include
srint - Show Running-Config Interface
Router(config)# alias exec srint show running-config interface

Como veis con estos alias no esta el commando complete faltan parámetros que podemos introducir a posterior.

Por ejemplo:

srint fa0/0

Default aliases

¿Sabías que la IOS de Cisco incluye e incorpora alias de algunos comandos incorporados? (Por supuesto, Cisco IOS siempre acepta comandos únicos más cortos, pero estoy hablando de alias de comandos reales.) Comandos alias por defecto:

  • p stands for ping.
  • h stands for help.
  • lo stands for logout.
  • u and un stand for undebug.
  • w stands for where.

You can view these aliases by using the show alias command—whether you’ve actually configured any aliases of your own.

Alias muy recomendables:

Alias: s
Para: show running-configuration
Se crea con: alias exec s sh run
Alias: c
Para: configure terminal
Se crea con: alias exec c conf t
Alias: sir
Para: show ip route
Se crea con: alias exec sir sh ip ro

You can use the above alias to specify parameters, such as sir bor sir o, to show all BGP routes or all OSPF routes. Or, to see a specific route, you could use sir 10.1.1.1.

Alias: i
Para: show ip interface brief
Se crea con: alias exec i sh ip int brie

Para frame relay, puedes usar estos otros:

Alias: pvc
Para: show frame-relay pvc
Se crea con: alias exec pvc show fram pvc
Alias: dwn
Para: show frame-relay map | include down
Se crea con: alias exec dwn sh fram map | inc down

If you go into a certain router configuration a lot (for example, BGP AS 1234), you can use the following:

Alias: b
Short for: router bgp 1234
Create it with: alias configure b router bgp 1234

Usamos mucho por ejemplo el no shutdown en un interface, podemos hacer el alias:

Alias: ns
Para: no shutdown
Se crea con: alias interface ns no shutdown

http://routerjockey.com/2010/05/16/using-regular-expressions-on-cisco-ios/

http://startup-config.com/command-line-shortcuts-cisco-geek/

http://www.handsomeplanet.com/archives/11

 

 

Anuncios

ENTENDIENDO Plantillas Switch CISCO ( SDM templates CISCO)

Recomiendo ver el post anterior sobre la CAM y la TCAM https://cmdsistemas.wordpress.com/2014/03/11/tabla-cam-en-cisco-switch-y-tcam/
Como habíamos comentado anteriormente continuamos con el post anterior y nueva característica de IOS 15.

SDM (Switch Database Manager)

Por entender SDM templates, por ejemplo en un siwtch de capa tres SDM lanbase-routing  template activará el switch para enrutar entre VLANs y soportar rutas estaticas. Por ejemplo un Cisco Catalyst 2960 switch.
  • Verificar el template o plantilla será con el comando:

                 #show sdm prefer

  • Para cambiar la plantilla ser hará desde modo global con el comando:

                (config)#sdm prefer command

Más adelanteaquí mismo veremos unos ejemplos.

Para optimizar el uso de un switch CISCO podemos especificar mejor los comandos y características a usar dependiendo del uso que le queramos dar en la red.

Por ejemplo podemos querer balancear los recursos que tiene un switch o podemos querer el número máximo de MAC almacenadas en la tabla CAM o por el contrario el número máximo de ACL para controlar las redes que están conectadas a él. Para esto surge el concepto de plantilla SDM en CISCO. En resumen optimizamos el soporte del equipo para ciertas características.
Hay varias plantillas e imagino que CISCO tendra nuevas ideas, las que encontré hasta ahora son las siguientes:

Routing: Prepara los recursos del sistema para unicast routing, tipico requerimiento en un switch que vamos usar para enrutar vlan, normalmente este tipo de equipos los colocamos en la capa de CORE o de distribución.

VLAN: Este tipo de platilla desactiva el enrutamiento por defecto y soporta el número máximo de direcciones MAC y tráfico unicast para estas direcciones, es típico para switches de capa 2.

Default: Balancea entre todas las funciones del switch

Access: Esta plantilla maximiza los recursos para las access control lists (ACLs) para disponer del número máximo de ACLs.

Dual-ipv4-and-ipv6: se divide en, enrutamiento y VLAN. Reservas menos espacio para la capa 2 unicast, y asigna mas a enrutamiento IPv6 y las entradas de seguridad ACL.

Por default los switches usan the Default SDM Template.
switch# show sdm prefer

The current template is “desktop default” template.

The selected template optimizes the resources in

the switch to support this level of features for

8 routed interfaces and 1024 VLANs.

number of unicast mac addresses: 6K

number of igmp groups + multicast routes: 1K

number of unicast routes: 8K

number of directly connected hosts: 6K

number of indirect routes: 2K

number of policy based routing aces: 0

number of qos aces: 512

number of security aces: 1K

En esta plantilla por defecto no se admite enrutamiento.
Vamos a cambiarlo a routing: “Policy Based Routing”
Switch(config)# sdm prefer routing

Switch(config)# end
Switch# wr
Switch# reload
Proceed with reload? [confirm]

Switch# show sdm prefer
(nos mostraría)
The selected template optimizes the resources in

the switch to support this level of features for

8 routed interfaces and 1024 VLANs.

number of unicast mac addresses: 3K

number of igmp groups + multicast routes: 1K

number of unicast routes: 11K

number of directly connected hosts: 3K

number of indirect routes: 8K

number of policy based routing aces: 512

number of qos aces: 512

number of security aces: 1K

 

Fijaros en el cambio:

number of policy based routing aces: 512

Ahora nos permite el comando route-maps, antes nos daría error, esto mismo puede pasar con otros comandos. De tener una plantilla por defecto el error citado sería:
May 30 06:10:02.705: %PLATFORM_PBR-3-UNSUPPORTED_RMAP: Route-map PBR not supported for Policy-Based Routing

A veces en ciertos swiches puede ser que no veamos esto nada claro, la mejor manera de comprobar si los paquetes están siendo políticamente enrutados, es ejecutar una traza desde el origen al destino.
Cuando tenemos “log” para una lista ACL que se llama en un PBR (politica de enrutamiento), el PBR no funcionará como se espera, a menos que desactivemos CEF o eliminamos la ip route cache del interfaz.
CEF: Cisco Express Forwarding ( http://www.cisco.com/c/en/us/support/docs/ios-nx-os-software/ios-software-releases-120-mainline/47205-cef-whichpath.html )

Dependiendo del dispositivo tendremos unas plantillas u otras, también una tabla orientativa sobre los recursos que ocupan cada recurso en la memoria, por ejemplo:

http://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst2960x/software/15-0_2_EX/system_manage/configuration_guide/b_sm_152ex_2960-x_cg/b_sm_152ex_2960-x_cg_chapter_0100.html#task_410B1DD6081440C88990117265012059

http://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst3850/software/release/3se/system_management/configuration_guide/b_sm_3se_3850_cg/b_sm_3se_3850_cg_chapter_01011.html

Resumiendo: El uso de estas plantillas aumenta la flexibilidad y permite elegir lo que debe ser extendido al máximo en el hardware , dependiendo de dónde se despliega el switch.
En algunos Catalyst como el 3750 se puede ver el uso que hace la TCAM con este comando: show platform tcam utilization
Switch# show platform tcam utilization
CAM Utilization for ASIC# 0 Max Used

Masks/Values Masks/values

Unicast mac addresses: 6364/6364 31/31

IPv4 IGMP groups + multicast routes: 1120/1120 1/1

IPv4 unicast directly-connected routes: 6144/6144 4/4

IPv4 unicast indirectly-connected routes: 2048/2048 2047/2047

IPv4 policy based routing aces: 452/452 12/12

IPv4 qos aces: 512/512 21/21

IPv4 security aces: 964/964 30/30

Note: Allocation of TCAM entries per feature uses
a complex algorithm. The above information is meant
to provide an abstract view of the current TCAM utilization

http://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst3750/software/troubleshooting/cpu_util.html#wp1004066
Las primeras plantillas aparecieron en el año 2011 mejorando en los switches actuales.

Solución ejercicio aprendiendo analizar tráfico de red.

En el Frame 1 si nos vamos alguna herramienta online tipo http://www.ip-adress.com/ip_tracer/67.217.65.244 nos da que pertenece a Citrix y así es, para este laboratorio se usaron aplicaciones de Citrix.

Frame 25, hay un host probablemente con Windows 7 que usa el stack o pila de protocolo IpV6, nos está mostrando las solicitudes de este protocolo ICMPv6 hacia sus vecinos (neighbor notifications).

Frame 27, esto es algo relativamente nuevo para muchos y desconocido por otros tantos, un protocolo de Windows llamado Browser que da mucha información sobre la víctima, quiero decir sobre la máquina. Se llama Browser, podemos ver que el host recibe el nombre de VID02 y si nos fuéramos al panel de detalle, podemos averiguar mucho más, os dejo un copy&paste de: http://www.rinconinformatico.net donde explica muy bien este protocolo y la información que nos da al analizarlo con wireshark, lo veo muy apropiado al post y seguirnos a posterior con el resto del ejercicio, leerlo por favor.

**********************************************************************

Microsoft Windows Browser Protocol, la verdad no conocía este protocolo de red, fue desarrollado por Microsoft para su famoso sistema operativo Windows, como muchas de las cosas que Microsoft desarrolla este protocolo es de uso privativo y no tiene nada que ver con Internet o HTTP.

El Browser Protocol registra los nombres SMB (CIFS) o de NetBIOS de una red, los almacena y los comparte para los demás nodos de la red. No se puede confundir ni con SAMBA ni con el WINS los cuales cumplen funciones parecidas pero no iguales. ¿Para que almacenar los nombres NetBIOS de los computadores que hacen parte de la red?, bueno es que este protocolo no solo almacena el nombre, también tiene un campo en el que se incluyen los servicios que el host ofrece, claro los servicios que están integrados con el sistema operativo, en este caso, Windows.

Todos estos datos son enviados por parte del computador cliente, el servidor solo registra lo que lee en el campo del protocolo.

¿Que nos ofrece este campo? Este campo se llama Server Type y tenemos 8 grupos de 4 bits con los que podemos identificar que rol tiene un host en una red, debemos recordar que esto SOLO aplica para los host que usen un sistema operativo que tenga esta característica de MailSlot en SMB, principal y casi únicamente Windows.

Veamos un ejemplo de trama.


El campo en cuestión es el que esta subrayado, como podemos ver después del 0x tenemos 8 dígitos hexadecimales los cuales me pueden indicar lo siguiente:


He remarcado los bits que identifican al host en la red, es así como sabemos que esta es una Estación de trabajo (para Windows TODO es una estación de trabajo) y es un servidor (Para Windows todos los host pueden ser servidor), este es un ejemplo de un nodo sencillo, pero si vemos uno como esto:


Sabríamos que se trata de un equipo en la red, con sistema operativo Windows, que tiene una impresora conectada y compartida. Por ultimo como para ver hasta donde llega este protocolo podemos encontrarnos con información como esta:


Con lo que ya tendríamos mucha información y una muy posible víctima de ataque, valgan la redundancia.

DISCLAIMER: toda la información contenida en esta entrada es para fines educativos y de Pen Testing, JAMAS se ha pensando en modificar una trama de este tipo para generar un DoS sobre algún dominio, no puede haber alguien tan malo.

Ya sabemos analizar un protocolo más.

¿Seguimos con el ejercicio?

VPN CISCO CON CERTIFICADO OPEN SSL GENERADO EN LINUX DEBIAN

Iba hablaros sobre el VLAN Hopping y como hacer el saltar de una Vlan a otra con el doble etiquetado, pero vamos a cambiar un poco la temática de los anteriores post.

Echamos de menos a Chema escribiendo sobre aplicaciones para sistemas operativos que nos facilitan la vida, Chema animate y cuelga algo anda que tanto facebook es malo para el cuerpo.

Para los que ya sabeis hacer una VPN o estais estudiando para el CCNA Security, si teneis una VPN establecida ya entre dos routers CISCO os vamos a explicar como establecer la VPN con certificados generados con openSSL desde DEBIAN. Podeis prácticar OPENSSL siguiendo este curso de la universidad Politecnica de Madrid gratuito y que esta ahora mismo desarrollandose a tiempo libre, os dejo el enlace, echarle un vistazo os va gustar y vais aprender bastante (no sobre CISCO):

http://www.criptored.upm.es/crypt4you/temas/privacidad-proteccion/leccion1/leccion1.html

Este será nuestro esquema:

escenario

Dos routers conectados por VPN mediante SITE to SITE haciendo un peer entre RA y RC con RB por el medio.

Instalamos un debian en una máquina virtual, por defecto ya viene instalado el openssl y si no viene pues desde modo super user escribimos apt-get install openssl

Procedemos a solicitar los certificados de router1 y router2:

Creamos directorios para trabajar en nuestro directorio de usuario:

Crear directorio: mkdir cisco

Movernos al directorio creado: cd cisco
Crear varios directorios: mkdir certs newcerts private crl
Crear el directorio index vacio sint exto con: touch index.txt
Ahora meter en serial echo 01: echo 01 > serial
Copiar por seguridad a donde estamos el fichero openssl.cnf: cp /etc/ssl/openssl.cnf

Ahroa vamos a modificar el fichero /etc/ssl/openssl.cnf y modificamos con nano /etc/ssl/openssl.cnf dos de las entradas que hay dentro del fichero y las dejamos así:

dir = .
certificate = $dir/certs/cacert.pem

Copiamos y salimos.

Toca generar el par de claves de CA y el certificado raíz.

openssl y damos al enter a continuación ya en modo openssl

genrsa –des3 –out private/cakey.pem 2048

Nos pide inserta una key, poneis la vuestra habitual, por ejemplo ciscopass

vpn1
openssl req –new –x509 –days 1000 –key private/cakey.pem –out certs/cacert.pem –config openssl.cnf

De este no pongo imagen pero sería similar.

Nos va pedir los datos para el certificado raiz, os pongo un ejemplo de lo que podeis poner.

Country = ES, State or province = AST, Locality = Koeln, Organization Name = CMD, Sistemas Unit = Prueba, Common Name = CA. Email y otros campos los dejamos vacios.

Ojo en la creación de certificados más adelante, hay que tener cuidado con el common name, no debemos de poner el mismo ya que luego no deben coincidir deben ser únicos. Es decir al crear el certificado para RouterA y nos pida los datos de más arriba podemos poner en Common Name=RA

Podemos ver en pantalla el certificado raíz con el siguiente comando:

root@Mich:/home/miguel/prueba# openssl x509 -in certs/cacert.pem -noout -text

Toca generar los certificados para los routers, los vamos hacer un poco más ligeros de 1024 en vez de 2048 como el de CA de antes, así que generamos la RSA para RA y para RB, dejo la de RA pero la de RC sería lo mismo pero cambiando el nombre.pem. Recordar la palabra que ponéis, si no estais en producción y es una prueba lo que estais haciendo usar siempre la misma.

generarcertR6

Escribí R6key.pem pero en vuestro caso sería RAkey.pem, lo mismo para RCkey pero variando ahí el nombre, el proceso es el mismo.

Si os fijais en la sintasis y quereis saber para que sirve el -noout el -text de más arriba o el -out que utilizamos en esta genración de certificado pinchar en este enlace que tiene una buena chuleta en pdf, aunque habrá algunos como des3 que ya os imaginais que es hacerlo con triple DES:

http://stuff.gpul.org/2004_cripto/doc/chuleta_openssl.pdf

Toca solicitar la petición a la CA del certificado de RA y RC, dando la llave RSA que acabamos de generar y dando de salida una petición:

openssl req –new –key private/RAkey.pem –out certs/RAreq.pem –config openssl.cnf

openssl req –new –key private/RCkey.pem –out certs/RCreq.pem –config openssl.cnf

Mi intención era marcar en verde la RSA RAkey.pem pero os capture la imagen y ahora no puedo pero bueno ya la veis en el comando de la imagen solo que escribí R6key.pem

Ahora la CA usando la petición (request) generá el certificado, hay que hacerlo para RA y para RC, es muy parecido en Windows al proceso con el ADCS.

openssl ca -notext –in certs/RAreq.pem –out certs/RAcert.pem –config openssl.cnf

openssl ca -notext –in certs/RCreq.pem –out certs/RCcert.pem –config openssl.cnf

Toca pasarlo todo al contenedor PKCS#12, por que hacemos esto, pues porque tenemos que  definir un formato de fichero usado comúnmente para almacenar claves privadas con su certificado de clave pública protegido mediante clave simétrica.

Recordar la clave de exportación que ya sabeis de anteriores pasos.

Ahora toca pasar los certificados del directorio de linux donde los habéis generado al router. Yo he usado el método del USB 🙂 me parecio el más rápido para no tener que hacer nada especial con el vmware, ya que mi router 2911 dispone de puerto USB, así que hice un copy usbflash0: flash: hay que tener en cuenta que para que nos reconozca el usb debe de estar recien formateado y ojo con el formato de partición que usais si vais con este método.

Finalmente los importamos:

RA(config)# crypto ca import RALab pkcs12 flash:RA.p12 test
RA(config)# crypto ca trustpoint RALab
enrollment terminal
revocation-check none
exit

RC(config)# crypto ca import RCLab pkcs12 flash:RC.p12 test
RC(config)# crypto ca trustpoint RCLab
enrollment terminal
revocation-check none
exit

Crypto ca trustpoint significa que vamos a ser un entidad de certificación que acepta certificados autofirmados y no necesita firma de terceros, esto por resumir, al final del post os explico que quiero decir con resumir.

Enrollment terminal se usa para indicar que los certificados van a ser un copy paste del certificado directamente de un txt, o lo que es lo mismo en nuestro caso una importación.

Revocation-check none significa que no vamos a usar ninguna lista de rovocación, como una CRL o un online responder.

Por último queda cambiar en la politica de vuestra vpna la authentication pre-share por rsa-sig  que al visualizar la configuración no aparecerá pues por defecto es rsa-sig

Os dejo un ejemplo:

RA(config)# crypto isakmp policy 10
RA(config-isakmp)# authentication rsa-sig
RA(config-isakmp)# encryption aes 256
RA(config-isakmp)# hash sha
RA(config-isakmp)# group 5
RA(config-isakmp)# lifetime 3600
RA(config-isakmp)# end

Para RC lo mismo

También quitar las líneas que no se van a usar ya de la pre-shared, ejemplo:

R1(config)#no crypto isakmp key cisco123456 address 10.2.2.1

Cosas que pueden suceder, pues para que se establezca la VPN pues haberla tenido antes de los certificados funcionando para evitar problemas y estar seguros que la FASE 1 y 2 las hacia correctamente.

Yo por ejemplo tuve problemas al generar los pines, donde menos piensas, en el equipo, resulta que tenía un movil conectado a la wifi pero haciendo de modem para mi pc (si si para escaquearme y saltarme el firewall del trabajo) y al ser wifi realmente me generó una métrica mas baja en la tabla de enrutamiento del pc y ahi tenía el problema que salia por otra red el ping extendido.

07-06-2013 21-36-48 07-06-2013 21-37-12 07-06-2013 21-37-31Fue cuestión de cambiarla y a correr.

Espero que aprendierais algo, ya que tuve que escribirlo dos veces entero, pues un fallo con el teclado me hizo perder todo …, na que la lie con el wordpress 😦 a quien no le paso alguna vez ??, así que me he armado de valor y lo he vuelto a escribir todo un poco mas escueto, pero ahí queda todo esto, ahora ya puedo dar a subir el post y descargar toda la FURIA que llevo guardando por cada letra que he repetido, ya puedo golpear y romper el teclado, quizas tambien el ratón …

INSPECCION DINAMICA DE ARP en CISCO

(ver post anteriores dhcp snooping y ip source guard)

Con anterioridad veíamos un ataque de capa se puede decir que 3 mediante direcciones ip, ahora va ser directamente sobre capa 2, la MAC

Doy por supuesto a estas alturas que ya se sabe como almacena un switch una dirección MAC.

Si un host solicita mediante un broadcast de arp y con la ip de destino, una MAC que no conoce para poder mandar sus datos, el equipo que tenga esa ip responderá con un ARP Replay conteniendo su dirección MAC, por eso un atacante puede engañar diciendo que  tiene esa ip y mandar su MAC falsa, con lo que el host origen asociará esa ip con esa MAC falsa, enviando los paquetes ip a esa dirección mas falsa que el pressing catch.

Este ataque es conocido como envenenamiento de ARP y es considerado un ataque man in the middle. Aclarado y dedicado al comentario que nos llego si podíamos aclararlo un poco más para los novatos.

Los switches de CISCO pueden utilizar DAI (Dinamic ARP Inspector) para evitar este tipo de ataques, uuuuuh cuidadin que muerde CISCO.

Los puertos del switch los vamos a considerar confiables o no confiables, inspeccionando solo los que llegan a los puertos no confiables contra la base de datos de DHCP Snooping y las introducidas de manera estática y si ve alguna incoherencia entre la MAC y la IP descarta la trama y envía un mensaje de log. Recomendamos tener un servidor de syslog funcionando.

Para habilitar DAI se debe introducir esta línea por cada vlan que se quiera activar el servicio de protección y se considerará puerto no confiable a todos los que pertenezcan a esa VLAN, lo que quiere decir que se inspeccione el trafico que pasa por ese puerto.

SwitchMiguel(config)#ip arp inspection vlan {vlan-rango}

Pero si queremos que algún Puerto determinado dentro de esa Vlan sea confiable y no se inspeccione el tráfico pues:

SwitchMiguel(config)#interface type {mod/num} ejemplo: interface fastethernet 0/0

SwitchMiguel(config-if)#ip arp inspection trust

 

Para las direcciones que estén configuradas de manera estática necesitamos al no haber comprobación contra DHCP snooping darle esa información de manera estática:

SwitchMiguel(config)#arp access-list {nombre de la acl}

SwitchMiguel(config-acl)#permit ip host {ip estática} mac host {mac estática}

El siguiente paso es asociar esta ACL al DAI:

SwitchMiguel(config)#ip arp inspection filter {nombre de la acl arp} vlan {id de vlan o rango de vlan} [static]

OJOOOO pistojooo Como toda lista de acceso si no encuentra ninguna coincidencia descarta la trama ya que lleva implícito al final un denegar todo. Los CCNA ya los sabeis y sino a repasar por paquetes. (ver listas de acceso)

 

LA MAC PUEDE VENIR FALSEADA en el paquete de respuesta de ARP por el atacante y ser luego distinta en la trama ethernet, entonces podemos comprobar la mac que nos llego del ARP con el de esta trama de datos. Por ejemplo:

Src-mac: compara

IP SOURCE GUARD EN CISCO

(ver antes dhcp snooping)

Es una característica de los switches Cisco y se usa para detectar y eliminar ataques de direcciones Ip falsas. Este tipo de ataque es más difícil de parar sin CISCO, lo que no quiere decir de detectar.

Imaginemos un PC al que le damos una Ip por ejemplo por DHCP, este PC puede ser atacado y cambiada su IP comenzando a usar direcciones falsas. Este ataque se suele usar para ataques de denegación de servicio, en las que lógicamente los paquetes jamás regresan al origen.

Este tipo de ataque se suele producir dentro de una misma VLAN, ya sería más difícil descubrir que la ip es falsa pues está comprendida dentro de la misma red y en redes grandes pues quien sabe … sobre todo si tenemos la desgracia de ser informáticos de los de verdad, de los que llevamos toda la vida subcontratados (cuando hablamos de VLAN nos referimos a una misma subred)

Esta característica de CISCO habilitada en un Switch analiza y busca la dirección MAC y la asociación con la IP correspondiente en la base de datos de DHCP Snooping visto anteriormente. También comprueba las estáticas grabadas por nosotros.

Se deben cumplir dos condiciones para que ip source guard no plante cara a la trama:

1) La dirección IP de origen no puede ser distinta de la dirección IP aprendida en el DHCP Snooping. Automáticamente el switch crea una ACL dinámica en el puerto que se usa a modo de filtro para impedir entrada de cualquier ip que no coincida con la correspondiente a la base de datos del ya citado un millón de veces DHCP Snooping.

2) La dirección MAC de origen debe ser igual a la aprendida en el DHCP Snooping y a la aprendida en el puerto del Switch. En este caso usa el comando port.security que os sonará a los que habéis hecho pinitos con el Cisco Security.

Para que todo funcione se debe tener DHCP Snooping configurado. Ya canse de escribir tantas veces esa palabra, a partir de ahora es sustituida por snoopy  o poríndice  ahí le dimos ohhh ehhh oeee oeee oeee.

Lo primero a configurar serían aquellas direcciones IP y MAC es decir “host” que no usan DHCP y están conectadas a puertos de los switches, asociando el puerto a la vlan, mac e ip correspondientes:

SwitchMiguel(config)#ip source binding {mac-address} vlan {vlan-id ip-address} interface {tipo modelo y número}

Ahora habilitamos snoopyen los puertos del switch que lo queremos implementar:

SwitchMiguel(config)#interface {tipo modelo y número de interface}

SwitchMiguel(config-if)#ip verify source

Si añadimos el parámetro port-security inspecciona también la MAC, sino solo la IP.

SwitchMiguel(config-if)#ip verify source port-security

Verificación del estado de dhcp snoopingsnoopycommando:

SwitchMiguel(config)#show ip verify source {interface type mod/num}

Para ver las direcciones aprendidas dinámicamente en la base de datos sería:

SwitchMiguel(config)#show ip source bindng {ip-address} {mac-address} dhcp-snooping interface {type mod/num} vlan {vlan-id}

 

Podemos prevenir este tipo de ataques de ARP Poisoning

Podéis ver la entrada en este blog sobre ARP Watch para Debian o ArpON. Hay otras aplicaciones como Marmita que son gratuitas y sirve como preventivas siempre y cuando no dispongamos de aplicaciones específicas de CISCO u otros.

Más sobre la aplicación en este fantástico sitio web http://www.flu-project.com/marmita-detectando-ataques-man-in-the-middle.html

Seguir las prácticas de esta web. Tampoco es mala idea.

El caso de Marmita no va impedir un ataque pero si su detección y es gratuita, la han creado los chicos de informática64 unos genios en su área. (No seguir leyendo sin haber descargado y estar visualizando la aplicación.) Su fuerte se basa en tener una base de datos local con las asociaciones de IP y MAC, es decir la tabla original de ARP antes de ser comprometida. Vamos a poder ver en su sección de ARP Table la misma Mac para dos Ip distintas, la del router verdadero y la del atacante. Si vamos a la pestaña Virtual Arp Table veremos que la ip del atacante tenía antes otra MAC.

Hay más aplicaciones como XARP para Windows, yo personalmente no la he usado pero he leído que a veces detectada positivos que no lo son, pero bueno siempre pensamos que estas aplicaciones son reactivas y no valen para otra cosa, donde estén las de monedero …

También tenemos gratuitos sistemas de detección de intrusión como EASYIDS . Si vamos a usar un PC con estos sistemas debemos de tener dos tarjetas de red instaladas, una para administración y la otra en modo promiscuo para sniffar la red. EASYIDS si nos ha gustado bastante, descargarla y probarla, está basada en snort.

Tanto para Marmita como para este sistema u otros debemos usar si por ejemplo estamos en un CISCO la funcionalidad de Spam para monitorizar todos los puertos. En el caso de EASYIDS es una imagen que podemos arrancar desde una ISO en una máquina virtual de vmware, es un Linux.

Ver como ayuda indispensable-> http://seguridadyredes.wordpress.com/2011/02/10/snort-easyids-un-ids-preconfigurado-con-base/

Hacer todas las prácticas de la red completa con monitorización y reenviar tramas de spam entre swiches de distintas vlan con respam podéis lanzar tramas de un switch a otro switch con una vlan distinta para monitorizar en esta (ver comandos de CCNP Swiching) en un equipo en la vlan administración pero distinta a donde tenemos el syslog corriendo, por poner un ejemplo retorcido.

Antes de implementar esta seguridad yo usaría el Evil Foca que acaba de salir al mercado y es Español, para realizar los ataques de envenenamiento y comprender un poco más toda esta situación.

Practicar estos ejemplos enseña mucho (recordar siempre la ética Hacker) manual sencillo del foca àhttp://www.dragonjar.org/evil-foca-manual-no-oficial.xhtml

Página del creador con direcciones a distintos tutoriales y ejemplos así como la descarga, si el chico del gorrito o mejor dicho consultor de seguridad, que por cierto nosotros no conocemos de nadaàhttp://www.elladodelmal.com/2013/04/pruebas-con-evil-foca.html

Descarga directa àhttp://informatica64.com/evilfoca/

HUAWEI A TUTIPLEN , comparativa con CISCO

Estamos empezando a trabajar con equipos Huawei ohhhhhhhhhhhhhhhhhhhhh
Le vemos una ventaja sobre Cisco, primero que nos hacen la pelota para su venta y segundo que donde pones un equipo Cisco colocas dos Huawei y todavía te ahorras la mitad del precio para pagar mas a tus técnicos 🙂 .
La pimera impresión es la de estar configurando un Cisco tal cuál, (no me extraña que los tengan medio medio denunciados), pero nos trae ciertos recuerdos a la metodología de Teldat con sus famosos comandos para estar en dintintos modos de ejecución.

Nos ha gustado sobre todo por que no pesan nada y los colocas con una mano, por lo que deducimos que no hay chinos dentro trabajando, (no eran nuestros y no los abrimos aunque no sería por ganas).
Los logs nos los da muy rápido y la configuración es inmediata, solo le encontramos una Contra, tardan mucho en reiniciarse, van arrancando servicio a servicio hasta completar el boot, la Ios deja algo que desear frente a una de Cisco y su arranque lo mismo, pero quizas es que estamos acostumbrados al oro en vez de a la plata.

Tienen un plástico para sujetar el cable de corriente pero es bastante malo sobre todo en la sujección de la propia pieza contra el chasis del router.
En el modelo de 3G serie AR200 traen una chapa para tapar una de las conexiones de seguridad para robo del equipo por si no lo vas a usar, un detalle de calidad.

La conclusión es clara, si tuvieran escrito Cisco por su comportamiento pensariamos estar ante una serie 1.800 de Cisco, casi no apreciamos diferencias.
De lo que no podemos es hablar de su durabilidad ya que como decía son de los primeros en desplegar en grandes cuentas de clientes.

En nuestro caso hemos usado uno para datos y otro para backup por 3g

OS dejo una foto de los equipos que algunas compañias estan empezando a desplegar, desde mi punto de vista acertadamente para algunos escenarios en concreto no me digais que no parecen un CISCO?, quereis ver algo de configuración para comprobar el parecido??, quizas en otro post.

Jornada Cisco Networking Academy 2012

CMD Sistemas estuvo en el evento, enterándonos un poco del futuro que depara a los nuevos estudiantes y próximos profesionales de Cisco.

El evento se pudo catalogar de bueno y resolutivo en cuanto a dudas y explicación, el trato hacia los asistentes fue bueno y coordial. Las ponencias fueron tres, una por parte de Elena la responsable, con alegria y dinamismo, bastante concreta y explicativa, no dejando lugar a ninguna duda.

Sepués mediante conexión Webex fue el turno de Jose Esquivel, al que ya estoy acostumbrado a ver en los primeros Webcast en castellano en los nuevos foros,  con cambio de look en cada webcast, a veces con bigote a lo chicano, a veces sin bigote, otras con perilla, otras sin ella, unas con gafas otras sin gafas , pero en general bastante bien sobre todo pensando a que hora se tuvo que levantar, menudo madrugon eh José ??, pensar que esta en la otra parte del mundo, aunque no creo que tenga el Spanish salario o también conocido (S.D.M.)

La conexión se hizo mediante productos CISCO y poco más se puede decir al respecto, imposible que la conexión fuera deficiente, una maravilla.

El tercero fue realizado por el director de Sistemas en España, concretamente la conexión se hacia hacia contra Barcelona, esta tercera a mi parecer no era necesaria, se salia un poco del temario a tratar pero fue muy interesante ya que abordaba nuevos aspectos tecnológicos de CISCO, como crítica esos productos se podrán vender a empresas como el BBVA, BSCH o Iberdrola  pero no a gruas perico el de los palotes, es decir no al medio empresario para el que trabajamos la mayoría, pero como decía dio gusto escucharlo, más que por su acento que era simpático 🙂 por lo bien que explico y el control que tenía de la tecnología (pilotaba).

Por resumirlo para los estudiantes que estáis viendo esto, no va  haber más cursos 100% online , así que si los veís olvidaros de que sean oficiales o sean validos, no veremos cambios en la documentación hasta el 2013 en la que se incluira MPLS, banda ancha, IP V6 y puede que entonces tengamos una nueva sorptesa que será un nuevo curso en la plataforma, por fin el CURSO DE VOZ IPPPPP suena a película de miedo, pero a ver si un día podemos gritar por finnnnnnnnnnnnnnnnnn !!!!

Por la parte que a nosotros o a un servidor nos toca, seguiremos luchando sanamente contra CISCO en la parte de las prácticas, a ver si un día conseguimos que tengáis prácticas de empresas y obliguen a los que son partner como mínimo a tener en sus filas algún estudiante, aunque sea sin renumeración …, vamos sin pagar un chapo como se suele decir 😉 pero por lo menos serán unas buenas prácticas para los que acaben los cursos y quien sabe después, de nada nos sirve lo que hay ahora de un trabajo en por ejemplo BRASILLLLL, aunque yo me iría ahora mismo sin pensarlo, vendita crisis eres entre todas las … bueno dejemos el tema.

Vimos el evento como muy organizado, muy positivo y bueno en general, dando a entender la buena organizacion de cisco e interpretación hacia su plan de estudios. La parte negativa la pusieron las academias, de un total de mas de 380 por toda España, solo estabamos allí unas 50 personas y no cada uno era de una distinta, lo que da mucho que pensar sobre algunas de ellas.

Por mecionar algunas buenas academias estaban , Academia Postal, Academia Lugones, Inadeco S.L., La representación de la Univesidad de Galicia de Telecomunicaciones …

Dejamos una foto del evento, no tapamos ningún rostro gracias al que el móvil hace unas fotos de maravilla, no creemos que haga falta y bueno la foto esta hecha de espaldas, bueno de espaldas los demás, que … ahí queda la foto:

http://www.netacadevents.com/europe/event/46/jornada-cisco-networking-academy-2012/

 

Poema Spanning-tree

¿Sabían que la señora Radia Perlman inventó el Spanning-tree?.
Inventó un algoritmo, basado en un poema para describir el protocolo:

I think that I shall never see
A graph more lovely than a tree.
A tree whose crucial property
Is loop-free connectivity.
A tree that must be sure to span
So packets can reach every LAN.
First, the root must be selected.
By ID, it is elected.
Least-cost paths from root are traced.
In the tree, these paths are placed.
A mesh is made by folks like me,
Then bridges find a spanning tree.
—Radia Perlman

😉 podeis traducirlo, no creo que se os olvide más que es el spanning-tree

Post dedicado a Diego.

STICKY en un puerto swich

Este post es dedicado a THAIS y su pregunta.
STICKY podría ser facilmente el nombre de un perro. Todos conocemos la típica familia americana feliz. Te levantas y no esta ahí tu madre diciendo desayunaaaa día tras día, o por el contrario vives solo y tienes un triste cartón de leche en la nevera de hace una semana por no poder ir a la compra. Todo culpa de las interminables horas que haces en el trabajo.
No, no es así, lo que tienes es una pedazo de TRUFON RUBI@ esperándote en la cocina con un …, bueno con un zumo de naranja en la mano, beicon, huevos, y tostadas con una perfecta mermelada esparcida por encima y ahí entre ella y fregadero, esta Sticky en esa cocina de 20×20, al lado de la pezado de barra americana que te gastas en tu pedazo de casa de campo, en la que te espera tan suculento manjar.
Esta situación me hace pensar, mas que en el desayuno en el trufonaz@ , esta claro que si esta por la mañana, algo paso por la noche, ayyyyyss picar@n picar@n mmmmmmm, seguramente entonces necesitare todo ese desayuno para coger fuerzas, mejor dicho recuperar las fuerzas :)!!!, se me escapa la sonrisilla y me brillan los dientes, como no me van a brillar, efectivamente soy americano y sticky es mi perro.

Pero como no soy amerciano, sticky es un estado de aprendizaje en el que puedo poner un puerto de un switch.
Para ello tengo que antes haber definido el número de direcciones MAC permitidas que se van a conectar a través de la interfaz o llamado comunmente el puerto del switch . Por ejemplo:
switch(config-if)# switchport port-security maximum 2

Ahora puede ser que no conozcamos la MAC de los equipos que vamos a conectar o no tenemos ni una pizca de ganas de mirarla y queremos que sea establecida dinámicamente, es decir que la aprenda dinámicamente, así que ponemos el comando:
switch(config-if)# switchport port-security mac-address sticky
Y eso es lo que hace sticky. En nuestro ejemplo aprenderá dos MAC, las dos primeras en conectarse definidas en el comando anterior y estas serán agregadas a nuestra lista de MAC seguras. Recordar que hay otros comandos anteriores para que estos funcionen.

Hay muchos más valores a tener en cuenta, por ejemplo este comando no debe ser configurado en un puerto troncal o de backbone, ya que por estos puertos circulan tramas con múltiples direcciones MAC, diferentes de origen. Esto daría como resultado el bloqueo del puerto y como esta otras cuántas, pero casi es más de entender lo que hace Port Security y sus diferentes estados y no es tema de este post.
Muchas gracias por su atención y hasta otro tema. Chao.