Category Archives: Cisco

Cisco Category

Routing performance comparison chart – Cisco routers

Uneori se mai întâmplă să fiu întrebat care din două routere Cisco e mai performant unul față de celălalt. Dacă e sa las la o parte alte caracteristici cum ar fi: numărul și tipul de porturi, slot-uri pentru module de extensie, feature set ș.a.m.d răspunsul la întrebarea care din două routere rutează mai rapid rămâne destul de greu de găsit. De cele mai multe ori ne ghidăm de clasa echipamentului: small office, branch/SMB sau head office, dar asta nu întotdeauna e suficient. Ceea ce am gasit eu sunt sunt două documente Cisco care ne prezintă un chart comparativ pe performanță la o serie de routere. Ambele documente sunt cam outdated (2009/2010) dar de multe ori suficient mai ales pentru cei deprinși să achiziționeze echipamente Cisco refurbished pe e-bay. Vedeți mai jos un excerpt din unui din documente la un tabel comparativ pe performanță pentru mai multe routere Cisco:

cisco_routing_performance_chart_excerpt

 Cantitativ, în document, performanța se apreciază și se prezintă ca:

  • Numărul de pachete IP de 64 bytes (cel mai scurt pachet in rețele Ethernet) comutate pe secundă PPS.
  • Rata de transfer pentru aceleași pachete IP de 64 byte, măsurată in Mbps.
  • Valorile se prezintă atât pentru cazul cu routing in IOS (primul pachet pe destinație sau CEF deconectat) cât și pentru comutație pe ASIC prin Fast/CEF switching.

Calculele sunt făcute pentru worst case cu pachete de cele mai mici dimensiuni (64 bytes). Pentru pachete mai lungi (tipic 1500 bytes pentru Ethernet) rata de transfer va una sigur mai buna. E  și clar, cu pachete mai lungi se reduce overhead-ul per header de pachet și în plus router-ul ia mai puține decizii de comutație deci mai liber. La fel, evaluarea nu ia in calcul alte servicii posibile pe calea pachetului in router, s-a considerat că nu există filtre ACL, NAT, procese de criptare, compresie s.a.m.d care ar influență negativ performanța de rutare.

Cu părere de rău nu mai găsesc sursa pe WEB la documente – am doar copiile, așa că pentru partajare le atașez în box-ul meu pe onedrive. click aici pentru folder sau pe fiecare fișier in parte:

  1. Cisco – Portable Product Sheets – Routing Performance (nov 3, 2009)
  2. Cisco – Integrated Service Routers – Performance Overview (2010)

GNS3 – doesn’t work ping through the cloud on VM

First of all I would like to mention that all actions published here have as scope educational purpose. A lot of people who are trying to use GNS3 for testing/lab purpose meet the problem with connection to Internet through cloud.

My problem was: I couldn't ping from router in gns3 any external host. I meet this problem several times on different Operating Systems with different versions of GNS3. I researched on Internet for the solution many times and every time gave up in front of the problem. This is why I decided to write this article. It could be useful for someone in the same situation.

Let's begin with topology:

  1. I decided to install GNS3 on the Linux Ubuntu 14.04. Big Thanks to people who wrote this article http://www.computingforgeeks.com/2014/12/best-way-to-install-gns3-version-12-in.html and special thanks for those who wrote installation script.
  2. One of the most important things is that I decided to install GNS3 on VM using as hypervisor ESXi. Below you can see the topology. So I selected VM1 for this purpose.
  3. I connected ESXi host to the Cisco's switch using two cables. Cable connected to the G0/1 interface was set to trunk. Cable on G0/2 wasn't used (we will use it for debug purpose later).
  4. My VM1 has two interfaces. One is for remote management and the second for testing purpose.
  5. From VM1 I could ping from VLAN 10 interface User PC.

VMware_GNS3

Let's move to GNS3 and create topology:

I am not going explain how to create topology and connect to the cloud you could easy find how to do it on internet. I will just publish screen from my topology:

VMware_GNS3_topologyAfter topology creation I was configured Interface Fa0/0 to get ip address via DHCP:

R1(config)#int fa0/0
R1(config-if)#ip add dhcp
R1(config-if)#no sh
R1(config-if)#
*Mar  1 00:03:35.071: %LINK-3-UPDOWN: Interface FastEthernet0/0, changed state to up
*Mar  1 00:03:36.071: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/0, changed state to up
R1(config-if)#
*Mar  1 00:03:48.367: %DHCP-6-ADDRESS_ASSIGN: Interface FastEthernet0/0 assigned DHCP address 192.168.140.65, mask 255.255.255.0, hostname R1

Ok I have confirmation that packets are going through cloud. Everything is good. Next test is to ping CR2 interface ip address:

R1(config-if)#do ping 192.168.140.254

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.140.254, timeout is 2 seconds:
…..
Success rate is 0 percent (0/5)

 Hmm.. Maybe ICMP packets were suppressed. Let's try to send ping from VM – ping test passed. So we have the situation when some packets could reach GNS3 and some others couldn't. Let's try to find where is the exactly the problem. Packets could be stuck on VM or somewhere in the network. We are connected to the Cisco switch and we have option to configure SPAN or port mirroring in order to check out suppositions. Let's do it.

C2960(config)#monitor session 1 source interface gigabitEthernet 0/1 both

C2960(config)#monitor session 1 destination interface GigabitEthernet 0/2

Please keep in mind that Gi0/2 interface couldn't send legacy user traffic after this configuration. In our case this is not a problem because I don't use this interface. On the VM2 I run Wireshark application and from R1 in GNS run again ping command. In the wireshark I see that packets leave VM and return back to the host. So problem seems to be somewhere on the VM. It could be SElinux or iptables.

Let's try another thing. Let's check how is set vmnic0 interface for VLAN10 in security tab. For this go the vSphere Client -> Configuration -> Networking -> Properties -> Double-click on your VLAN -> Press Security tab. I had the following configuration:

VMware_GNS3_errorLet's try to change promiscuous mode from Reject to Accept and repeat test again. The results:

R1(config-if)#do ping 192.168.140.254

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.140.254, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/20/44 ms
R1(config-if)#

Here was my problem. Promiscuous mode allows vSwitch to forward all frames including those which are not directed to VM. Router in GNS3 acts as virtual interface inside of VM. From security purpose VMware block frames which are addressed to VM.

I hope that this article could be useful for you.

 

Frame Relay over IP (L2TPv3 / xConnect)

Curiozitatea m-a făcut să caut cum ar fi posibil de tunelat un circuit virtual PVC Frame Relay peste o simpla rețea pe IP. Ceea ce am gasit se bazează pe mecanismul de tunelare prin L2TP a cadrelor la diverse protocoale L2 cum ar fi PPP, HDLC, Frame Relay. Interesant e că prin L2TP poți tunela și frame-uri Ethernet fapt prin care poți construi simple rețele Ethernet private, un fel de VPLS (Virtual Private Lan Service) – vezi de exemplu configurația descrisă în articolul pe blog.ine.com (click aici). Sigur, astăzi, tehnologii utilizate pentru crearea de servicii de rețele suprapuse VPN sunt altele decât cea prin L2TP, in prim plan sare tehnologia MPLS cu capabilitatea AToM (Any Transport over MPLS) ce oferă aceeași idee de serviciu de transport de cadre L2 peste un backbone pe IP.

Mai jos voi descrie o configurație pe rutere Cisco în GNS pentru un PVC Frame Relay tunelat peste o rețea pe IP utilizând mecanismul bazat pe protocolul L2TPv3 (printre altele diferența dintre versiunea v3 față de v2 e că ultimul știa să tuneleze doar frame-uri PPP). Voi merge pe o descriere sumară fără a intra in detalii, pentru cei interesați de detalii recomand capitolul cu L2TP din Troubleshooting VPNs (more info).

Conexiune Frame Relay de la un router la altul (HQ to Branch) va fi configurată peste un grup de rutere interconectate prin IP. Grupul de rutere (două la număr) vor reprezenta backbone-ul pe IP a unui ISP fictiv. In general nu contează tehnologia prin care se vor interconecta routerele in interiorul ISP-ului, până la urmă cadrele FR vor fi încapsulate in pachete IP (peste L2TP) care la rândul lor pot fi transportate cu orice tehnologie L2 disponibila. Voi face ca circuitul intre rutere ISP să treacă prin Ethernet (mai jos in desen in spatele cloudului se află un circuit ethernet punct la punct între interfețele F1/0). Tunelul FR over IP prin L2TP va fi setat în configurație DLCI-to-DLCI pseudowire, cu sesiuni de control stabilite dinamic și autentificare între capete. 

FR_over_IP_via_L2TP_GNS_network_diagram

Să analizăm pe rând configurația specifică L2TP pe routerele de tunel endpoint (CE1, CE2). Descrierea o fac în raport cu liniile din configurația ilustrată mai jos.

  • Activăm CEF-ul (Cisco Express Forwarding) – linia 3
  • Configuram interfețe Loopback cu IP-ul cărora vor porni pachetele in tunelul creat prin L2TP – liniile 16,17. Fără interfețe loopback-uri se zice că pot fi probleme.
  • Configurăm un l2tp-class în cadrul căreia vom specifica parametri specifici pentru autentificare intre peer-uri. Opțional, e posibilă și o configurație fără l2tp-class sau invers de specificat și alți parametri pe lângă cei legați de autentificare.
  • Configurăm pseudowire-class – liniile 11-14, in modul de configurare a căruia specificăm: (a) încapsulare L2TP versiune 3 – linie 12 (b) asociem clasa L2TP-class creată anterior – linie 13 și (c) interfață Loopback local ca sursă de tunel – linie 14.
  • Pseudowire-ul de Frame Relay poate fi configurat fie prin DLCI-to-DLCI switching fie ca FR trunk. În primul caz routerele din capetele de tunel realizează ele însuși switching-ul Frame Relay și participă în conversații LMI (local management interface) iar in cazul cu FR trunk cadrele sunt comutate transparent peste pseudowire-ul L2TP. In exemplu vom folosi cazul cu DLCI-to-DLCI switching, pentru care: (a) activăm switching-ul Frame Relay – linie 9, (b) configurăm interfața serial cu încapsulare Frame Relay: IETF/LMI tip Cisco/intf type DCE – liniile 19-25.
  • Asociem circuitul PVC FR cu o sesiune nouă L2TPv3 session – liniile 27-28. In exemplu DLCI 371 pe interfața serial 0/0 este asociat cu o sesiune nouă L2TPv3 VCID 371 (virtual circuit ID) pentru pseudowire-ul definit anterior și care ajunge până la peer-ul (IP loopback) de la capătul opus al tunelului. 371 in linia 27 reprezintă DLCI-ul și 371 in linia 28 reprezintă VCID-ul sesiunii, nu e neapărat să coincidă, cred că pentru claritate trebuia să iau numere diferite.
  • Routing-ul in interiorul ISP-ului e configurat cu OSPF – linii 35-37. Pentru exemplu OSPF, poate fi orice alt protocol de rutare..

FR_over_IP_via_L2TP_GNS_configuration_details

Routerele HQ/BRANCH sunt configurate standard pentru transport peste circuite PVC Frame Relay (în exemplu: encapsulation Frame Relay IETTF / LMI type Cisco / static mapping): 

FR_over_IP_via_L2TP_GNS_br_hq_configuration

Odată finalizată configurația încercăm un ping de pe router-ul BRANCH pe HQ, care iată că funcționează din prima:

FR_over_IP_via_L2TP_GNS_success_ping

Imediat după, verificăm sesiunea L2TP pe unul din routere capete de tunnel. Flosim comanda show l2tun session:  

FR_over_IP_via_L2TP_GNS_show_tunnel_sessions

din care observăm singura sesiune L2TPv3 cu VCID 37.

Pe final rămâne interesant de urmărit o captură Wireshark pentru circuitul Ethernet între routerele CE1, CE2. 

FR_over_IP_via_L2TP_GNS_wireshark_capture_ethernet

din care se observă clar cum cadre FR prezentate ca HDLC (payload-ul ping-ului conține in HEX secvența ab cd .. ) sunt reîncapsulare prin L2TP în pachete noi IP – Ethernet. Wireshark-ul ne arată header HDLC în loc de Frame Relay relativ corect, header-ul FR fiind o variație la cel de HDLC.

Fișierele de configurație pe routere din topologie le puteți descărca (de aici).

Configurație destination-based NAT realizată prin route-map-uri

Imaginativă un scenariu prin care o companie se interconectează cu rețeaua unuia din partenerii săi. Pentru siguranță interconectarea se face prin două circuite separate: unul de bază printr-un Layer 2 overlay peste MPLS și altul de backup printr-un circuit virtual peste o rețea Frame-Relay. Rețeaua companiei este ascunsă de parteneri printr-un serviciu NAT prin care pe de-o parte se exclude riscul suprapunerii spațiilor de adrese IP utilizate pe intern și pe de altă parte ține confidențial particularitățile de subnetare a rețelei companiei. In plus, partenerul își poate construi un sistem de protecție (e.g. prin liste de acces) prin care să permită accesul doar pentru adrese IP din spațiul adrese agreat pentru configurația NAT-ului. Configurația NAT-ului trebuie realizată în așa mod încât aceasta să transleze in adrese IP (inside global) din intervale care să depindă de circuitul activ la momentul translării. Fiecare circuit are rezervat câte un interval de adrese IP (pool) destinat translărilor NAT.

Ca să formalizez, in cele ce urmează vom modela o topologie cu următoarele particularități:

  • interconectare între companie și partener prin două circuite: (a) unul de bază prin L2 peste MPLS și (b) altul de rezervă printr-un PVC peste Frame Relay.
  • rețeaua companiei protejată prin NAT, fiecare circuit configurat cu pool de adrese NAT separat: (a) pentru MPLS NAT pe 32 IP-uri din subnet-ul: 172.31.5.0/27 și (b) pentru Frame Relay NAT 32 de IP-uri din subnet-ul: 172.31.5. 64/27. Funcție de circuitul activ: main sau back-up, NAT-ul va funcționa fie pe primul fie pe al doilea interval de IP-uri.
  • segmentul punct-la-punct MPLS se configurează cu adrese IP din 10.10.10.0/30 (.1 la companie)
  • segmentul PVC FR se configurează cu adrese IP din 10.10.10.4/30 (.5 la companie și .6  la partener)
  • circuitul Frame Relay folosește PVC cu: (a) DLCI 423 pe partea companiei și (b) DLCI 324 partener.
  • rețea utilizatori companie: 10.18.0.0/24 cu stație pentru test (client_companie) pe adresa: 10.18.0.20/24
  • rețea servere partener: 172.31.0.0/24 cu server pentru test (server_partener) pe adresă 172.31.0.10.

Pentru modelare vom folosi GNS3 într-o schemă ca cea de mai jos:

conditional_NAT_gns_topology

În schemă:

  • MPLS format pe două switch-uri ethernet sintetice (PE1/PE2), incluse in serie pentru a putea întrerupe circuitul fără ca interfețele să treacă in down.
  • Frame Relay pe switch FR sintetic (port 1 – DLCI 423, port 10 – DLCI 324)

În plus, pentru completeness, la configurația de routing și NAT pe deasupra vom configura pe routerul companiei o probă IP SLA pentru tracking-ul circuitului de bază și rută flotantă pentru failover automat pe circuitul de backup.

Configurație router R1 (companie)

Configurație interfețe FastEherenet1/0, Serial0/0, Serial0/0.423:

Configurație serviciu NAT pe două pool-uri de adrese IP

În care linkfr și linkmpls sunt pool-urile de adree IP destinate NAT-ului pentru circuitele MPLS și respectiv Frame Relay. Ceea ce face ca NAT-ul să depinde de destinație este utilizarea in comenzile ip nat inside a route-map-rilor rmfr si rmmpls care la rândul lor sunt asociate fiecare cu altă interfață, partea cu match in secvența de mai jos:

Pentru route tracking vom folosi o proba SLA bazată pe ICMP echo-request/replay la IP-ul interfeței de partea partenerului pentru circuitul MPLS:

Note: secvența de mai sus pentru IP SLA valabilă pentru versiunea de IOS folosită de mine în GNS3, alte versiuni au altă sintaxă.

În final configurăm rutele statice către rețeaua de servere parteneri. Vom folosi două rute: una dependentă de track-ul la proba IP SLA și alta ca back-up inclusă cu o metrică mai proastă (100):

track 10 face referință la proba ip-sla 10

Configurație router R2 (partener)

Pe partea partenerului minim de configurație. Interfețe:

și două rute statice câte una pentru fiecare interval (subnet) de IP-uri NAT:

Acum că avem configurate toate componentele topologiei, putem să incercăm câteva teste.

Testing and Troubleshooting

Vom verifica două scenarii, unul pentru regimul normal cu trafic peste circuitul de bază și altul pentru cazul când circuitul de bază se intrerupe și traficul se redirecționează automat pe circuitul de rezervă. In avele cazuri se va verifica tabelul translărolor NAT și câte un capturi de wireshark pe fiecare circuit.

Așadar, după ce ne convingem că ping-ul are loc cu succes de la client la server verificam tabelul translarilor NAT pe router-ul R1:

conditional_NAT_ip_nat_translation_main_circuit

se observă o translare NAT cu un IP (inside global) din intervalul rezervat circuitului de bază, fapt confirmat și prin captura Wireshark (pe interfața R1-F1/0)

conditional_NAT_capture_main_circuit

in captură, IP-ul sursa la pachetul cu ICMP request pleacă NAT-uit cu 172.31.5.2. Ce este interant captura include și pachetele periodice de ICMP pentru proba IP SLA (R1 – 10.10.10.1 la R2 – 10.10.10.2). Funcționarea track-ului pe proba IP-SLA o confirmăm cu următoarele comenzi:

conditional_NAT_SLA_tracking_normal_state

din output interesant de urmărit Number fo Failures care e zero pentru moment, statutul track-ului care e Reachability is Up și ruta către servere prin circuitul de bază (R1-F1/0).

Acum să incercăm să simulăm intreruperea circutului de bază și să observăm efectul. Vom intrerupe link-ul intre switch-urile PE1 si PE2. Verificăm statutul IP SLA:

conditional_NAT_SLA_tracking_backup_state

din care imediat observăm efectul: (a) Number of failures in proba IP SLA diferit de zero (b) track 10 cu statut Reachability is down și (c) rută peste segmentul de bază in down. Ruta către rețeaua de servere parteneri trece deacum prin circuitul de back-up:

conditional_NAT_route_over_backup

executăm un ping de la client la server, după care verificam tabelul translărilor NAT:

conditional_NAT_ip_nat_translation_backup_circuit

deja se observa o translare cu un IP (172.31.5.66) din intervalul rezervat circuitului de rezerva 172.31.5.64/27). Fapt confirmat și prin captura Wireshar pe interfața Serial0/0:

conditional_NAT_capture_backup_circuit

se observă respectivul IP-ul sursă pentru pachetele ICMP echo request (și encapsularea FR).

Cam asta pe azi. Dacă vă doriți să reproduceți scenariul puteți descărca fișierele de configurație pentru R1 și R2 de aici (link).

How to find if Cisco supports specific command or feature

Hello all,

This is my first post in the blog and first article published in English. It is going to be interesting experience smiley

I decided to write this article to share my experience which could be interesting for some of you. One of the very common issue with Cisco IOS is that I found a command which doesn't work for me but this command is working for other people. Why so and how to solve this issue? I will try to give you some advice below.

Few time ago my task was to configure qinq vlan tagging on the Cisco switch. Let's start with what means qinq. Here you can find article from Cisco http://www.cisco.com/en/US/docs/ios/lanswitch/configuration/guide/lsw_ieee_802.1q.html which show us that qinq suppose to tag one frame twice. What is the reason to use qinq? Let's suppose that you have in the network one specific VLAN, for example 30. The same vlan 30 with the same pool of ip address you have on another part of your network. This situation is typical for ISP and his clients. Your task is to keep traffic from those VLANs separate and transport traffic through your network. So the solution for that is IEEE 802.1q tunneling or qinq tunnel in other words.

If you have some experience with Cisco you will try to enter on the Google how to configure IEEE 802.1q tunneling and will find article like this http://networklessons.com/switching/802-1q-tunneling-q-q-configuration-example/. By the way very good explained how to configure this specific feature. Not all people like to read official cisco docs (this was also my mistake). Let's say that Cisco provide information in not so interactive way like Rene did. I read Rene's article and said that is very easy to configure qinq and I need one switch and some minutes to do this task. I got C2960G switch, installed him and was starting to configure. I went to the interface:

Switch(config-if)#switchport mode ?
  access   Set trunking mode to ACCESS unconditionally
  dynamic  Set trunking mode to dynamically negotiate access or trunk mode
  trunk    Set trunking mode to TRUNK unconditionally

It seems to be that I will need more than couple of minutes to configure qinq. Command switchport mode qot1q-tunnel is missed from my IOS. So I need new version of IOS. But the question is which exactly one? One more problem could be that model of switch doesn't support this feature. So let's try to see what Google says about qinq on C2960. The result is confusing. In some links we could find that C2960 doesn't support this feature in other we see that feature is working (common situation). We need to know the answer. Let's go to the Cisco Feature Navigator http://www.cisco.com/web/go/fn. Feature navigator is very powerful tool which could show us if specific feature is supported on particular IOS. The most difficult thing here is to find the right name of the feature. Try to enter for example IPv6 on the feature field and you will see a lot of options. Which options is mine and command which I have to enter in configuration is covered? Try to search with some assumptions and using description of feature to do it faster. I supposed that my feature must contain 802.1q in his name. I supposed that name of my feature is IEEE 802.1Q tunneling. Description showed that it could be.

qinq

I searched on the Cisco's site and I found that is exactly the thing which I looked for. Now I have feature name and I see that this feature is supported on list of IOS-es. The great news I have one of this version on another switch. I repeated my configuration:

Switch(config-if)#switchport mode ?
  access   Set trunking mode to ACCESS unconditionally
  dynamic  Set trunking mode to dynamically negotiate access or trunk mode
  trunk    Set trunking mode to TRUNK unconditionally

Hey.. What is wrong? Feature name? License? It could be.. Let's go back to the internet..

License on this switch doesn't have any limitation and feature name seems to be right. Where to look ? Let's try Cisco Configuration guide http://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst2960/software/release/15-0_2_se/configuration/guide/scg2960.html. Configuration guide contain list of commands which are supported by the switch in specific version of IOS. I didn't find anything about qinq in configuration guide..

Conclusion: Cisco Feature Navigator is great tool but the results of searching must be verified with Cisco configuration guide to assure that your model of equipment is supported. It very useful to check before to upgrade switch with new IOS and find that command or feature which you are look for isn't working. My switch doesn't support IEEE 802.1q tunneling. This feature is supported by C2960X series of switches sad.

Cisco CCNA LAB – ARP spoofing

Și ca să nu credeți că cursurile desfășurate de DNT se bazează doar pe terorie vă propun mai jos textul pentru unul din lab-urile petrecute de mine in cadrul orelor practice de CCNA. Lab-ul e unul inventat și e complementar la ceea ce propune cursul oficial pentru orele practice. Fac un copy/paste raw din doc-ul original fără să mai corectez pe unde e nevoie.

Plan Laborator:

  1. Rezumat curs la subiectul conectare la dispozitive Cisco prin consola.
  2. Rezumat curs la subiectul ARP Spoofing.
  3. Practice PART A – Conectare prin consola la dispozitivele intermediare Cisco.
  4. Practice Part B – ARP Spoofing (Scenariu A, Scenariu B).

PART A – Conectare prin consolă la dispozitive intermediare CISCO

  1. Conectarea prin consolă cu cablu rollover la dispozitivul switch-ului Cisco Catalyst 2960de la primul PC din dreapta lingă rack. Demo conectare cu Putty.exe.
  2. Conectarea prin consolă cu terminal server la dispozitivele rack-ului de laborator. Explicaţie schemă rack.

PART B – ARP SPOOFING

Scenariu A – ARP Spoofing cu sustragerea parolei de access la un serviciu FTP pe internet.

Cisco_CCNA_LAB_ARP_Spoofing_Scenario_A

Sarcini de laborator:

  1. Deconectăm aplicaţiile antivirus şi firewall pe staţiile implicate în scenariul de laborator (staţia atacatorului şi staţia atacată). Verificăm interconectarea pe reţea între acestea şi accesul la internet de pe staţia atacată (ping pe ftp.subiectiv.md). ftp.subiectiv.md – serviciul ftp a cărui parola de access o vom sustrage prin arp spoofing.
  2. Descărcăm utilitarul arpspoof.exe pe site-ul http://arpspoof.sourceforge.net/ (arhiva rar) – recomandabil de descărcat cu  un alt browser decât Internet Explorer, acesta din urmă poate bloca descărcarea fişierului prin funcţia de SmartScreen Filter.
  3. Dez-arhivăm utilitarul (exe-ul plus fişierul dll) în folderul hack pe discul local c: (c:\hack) pe staţia atacatorului (hacker).
  4. Verificăm dacă pe ambele staţii avem instalate corect aplicaţiile Wireshark şi WinCap.
  5. Obţinem adresele IP (ipconfig /all) şi mac pentru staţii şi default gateway (ping DG + arp -a). Adresele IP sunt setate automat prin DHCP.
  6. Desenam schema reţelei. Notăm în dreptul fiecărui nod adresele IP şi adresele MAC (staţia atacată, atacatorului şi default gateway).
  7. Verificam OUI pentru adresele MAC înregistrate cu tool-ul pe Wireshark portal.
  8. Configurează routing-ul pe staţia atacatorului (Windows XP) – pentru rutarea pachetelor străine captate şi tranzitate prin staţie. Modificare cheie registru IPEnableRouter din 0 în 1 HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\ParametersRef: http://technet.microsoft.com/en-us/library/cc962461.aspx Note: Modificările pe registru se realizează cu maximă atenţie !!!
  9. Pe staţia atacată şi a atacatorului ştergem toate înregistrările din cache-ul arp -d  (Nu e o operaţiune necesară pentru realizarea arp spoofing-ului. E pentru a exclude din arp cache toate înregistrările irelevante).
  10. Pe fiecare staţie se executa ping între ele şi cu default gateway – e pentru a completa tăblițele arp.
  11. arp spoofing funcţionează în cazul în care există deja înregistrări în arp cache, gratuitous ARP le înnoind valorile.
  12. Se notează tăblițele arp până la arp spoofing (de pe ambele staţii).
  13. Pe staţia atacatorului se execută în linia de comanda CMD: arpsoofing.exe –t <IP attacked host> <IP default gateway> – înşelăm staţia atacată.
  14. Pe staţia atacată verificam modificările în arp cache (arp -a).  La acest moment in arp cache ar trebuie să observam că şi IP-ul staţiei atacatoare şi IP-ul Default Gateway sunt legate de aceiaşi adresa MAC şi anume cea a atacatorului.
  15. Pe staţia atacatorului se execută în linia de comanda CMD (alta decât cea din p.12): arpsoofing.exe –t <IP default gateway> <IP attacked host> – înşelăm ruter-ul default gateway.
  16. Pe staţia atacatorului lansam Wireshark cu Display Filter:ARP. Analizăm mesajele ARP (Source/Destination MAC/IP).
  17. Realizăm pe staţia atacată un ping pe ftp.subiectiv.md. Analizăm în Wireshark pachetele ECHO request, ECHO replay. Acestea ar trebuie sa fie câte două – odată înregistrată la intrare şi a doua înregistrată la ieşire.
  18. Pe staţie atacată descărcăm Total Commander. Interesant de urmărit procesul pe Wireshark-ul atacatorului (display filter pe HTTP)
  19. Pe staţia atacată în Total Commander instructorul configurează o conexiune FTP la ftp.subiectiv.md, fără ca studenţii să afle parola. Parola va fi furată prin arp spoofing de pe staţia atacatorului.
  20. Pe staţia atacatorului se configurează Wireshark cu display filter pe FTP.
  21. Pe staţia atacată se iniţiază conexiunea ftp. Se urmăreşte captura Wireshark din care se identificam parola de acces la serviciul ftp.
  22. La plecare: (a) Ştergem folderul Hack pe discul c: (b) Restabilim valoarea zero pentru IPEnableRouter din registru pe staţia atacatorului. (c) Ştergem conexiunea FTP din Total Commander pe staţia atacată. (d) Dezinstalam Total Commander de pe staţia atacată.

Scenariu B – ARP Spoofing intre 2x staţii izolate în reţea. Monitorizare mac address-table pe switch.

Cisco_CCNA_LAB_ARP_Spoofing_Scenario_B

Sarcini de laborator:

  1. Stabilim 3x staţii din clasa DNT pentru scenariul de laborator – 2x staţii atacate şi 1x staţie a atacatorului. Verificam numărul prizei de reţea la care sunt acestea conectate.
  2. Recomutăm pe panoul patch staţiile de la switch-ul clasei (D-Link de prod.) pe unul din switch-urile Cisco Catalyst 2960. Se notează porturile la care sau conectat PC-urile (recomandat: Fa0/1, F0/2, Fa0/3).
  3. Instructorul se conectează prin consolă la switch şi îl configurează cu utilizatori şi password  local, configurează adresa IP.
  4. Verificam IP-urile pe staţii. În lipsa unui DHCP acestea trebui să fi luat IP-uri prin autoconfigurare Automatic Private IP Addressing (APIPA) din 169.254.0.0/16
  5. Configuram adrese IP pe stațiile din scenariul de laborator: 131.108.10.1, 131.108.10.2, 131.108.10.3 (atacator).
  6. Verificăm connectivity între acesta (cu ping).
  7. Analizăm cache-ul ARP pe staţii (cu arp -a). Notăm valorile perechilor de înregistrări MAC-IP.
  8. Pe staţia atacatorului executam spoofing-ul:

arpsoofing.exe –t <IP attacked host 1> <IP attacked host 2>

arpsoofing.exe –t <IP attacked host 2> <IP attacked host 1>

  1. Pe staţia atacatorului lansam Wireshark cu Display Filter:ARP. Analizăm mesajele ARP (Source/Destination MAC/IP).
  2. Ne logăm pe consola switch-ului cu unul din utilizatori (fiecare pe rând) sau de pe staţii cu telnet la adresa IP a switch-ului. Executăm

switch > show mac address-table  

  1. Executam un ping cu parametrul -t intre host-urile atacate.
  2. Pe staţia atacatorului se configurează Wireshark cu display filter pe ICMP.  Analizam rezultatele.
  3. Deconectam temporar de la reţea (scoatem cablul din switch sau shut pe switch din line configuration mode) staţia atacatorului. Observăm statutul mesajelor ICMP in CMD-ul cu ping –t.
  4. La plecare: (a) recomutăm calculatoarele (cablurile pe patch-pannel) exact cum a fost acestea până la începerea scenariului de laborator.

Done. Have a nice lab ..