FQDN alapú tűzfalszabályok diagnosztikája FortiOS alatt

A legtöbb komolyabb tűzfalplatform biztosít lehetőséget FQDN alapú tűzfalszabályok létrehozására, nincs ez másként a FortiOS alatt sem. Az FQDN-es szabályok alkalmazása azonban nem feltétlenül jó ötlet, hiszen a forgalom átengedése vagy visszatartása a  tűzfal szempontjából egy másik, független rendszerre, a DNS-re épít, illetve megbízik annak a másik rendszernek az integritásában. Többek közt ezért is érdemes mindig a belső DNS szervereinket beállítani a tűzfalon (bár ettől még önmagában nem lesz biztonságosabb vagy megbízhatóbb a DNS rendszerünk). Mindenesetre ha alkalmazunk ilyen domain neves szabályokat is a tűzfalon, akkor további talányokhoz vezethet, ha az FQDN-es szabály mégsem működik, látszólag mégis minden tökéletesen rendben van.

A Fortigate tűzfalakon a webes felület nem ad sok lehetőséget arra, hogy leellenőrizzük, hogy egy FQDN-es szabály éppen milyen IP-kre helyettesíti a domain nevet, ugyanakkor van egy remek parancs a CLI-ben, amivel utánajárhatunk a tűzfalunk által a domian nevek helyett használt épp aktuális IP-knek:

FORTIGATE ~ $ diagnose firewall fqdn list
www.google.hu: ID(27) REF(1) ADDR(209.85.148.103) ADDR(209.85.148.104) ADDR(209.85.148.105) ADDR(209.85.148.106) ADDR(209.85.148.147) ADDR(209.85.148.99)
srp.eu.blackberry.net: ID(33) REF(2) ADDR(93.186.25.33) ADDR(193.109.81.33)
interwetten.com: ID(38) REF(1) ADDR(195.10.192.12)
energia.eon-hungaria.com: ID(52) REF(2) ADDR(217.67.35.141)
kkk.vam.gov.hu: ID(56) REF(2) ADDR(84.206.40.1)
microsoft.com: ID(67) REF(1) ADDR(207.46.197.32) ADDR(207.46.232.182)
login.live.com: ID(356) REF(1) ADDR(65.54.186.19) ADDR(65.54.186.47) ADDR(65.54.186.77) ADDR(65.54.165.136) ADDR(65.54.165.169) ADDR(65.54.165.175) ADDR(65.54.165.177) ADDR(65.54.186.17)
symantec.com: ID(209) REF(1) ADDR(206.204.52.31) ADDR(216.12.145.20)
update.microsoft.com: ID(244) REF(1) ADDR(65.55.25.59)

Ezeket a DNS cache információkat összevethetjük a DNS-ben elérhető információkkal, gyakran csak annyiról van ugyanis szó, hogy a tűzfal nincs szinkronban a DNS-sel, becache-elt valamilyen IP-t egy adott névhez, míg a valódi közben megváltozott. A parancs kimenetében minden egyes domain névhez tartozik ADDR mezőn vagy mezőkön kívül egy ID és egy REF mező is: fogalmam sincs mit jelenthetnek. Az ID-ról azt gondoltam, hogy a FortiOS tűzfal policyjeiben használt, és külön listában is (get firewall address) kezelt címek ID-jairól van szó, de semmi jele, hogy ezekhez tartozna ID, még a konfigurációs fájlban sem, szóval ezt a teóriát sem megerősíteni sem cáfolni nem tudom. A másik mezőről, a REF-ről elsőre úgy véltem, hogy arra utal, hány referencia van az adott névre a tűzfal policy-kben, de ez sem stimmelt, szóval passz, nem tudni mik ezek. A CLI Reference Guide-ot sem üthetjük fel ezekkel kapcsolatban, ott ugyanis nincs egy szó sem erről a parancsról.

A fenti diagnose firewall fqdn list parancsnak van egyébként még két testvére, az fqdn flush eldobja a cache-ben lévő IP-ket, míg az fqdn purge egyszerűen kipucolja a névlistából az összes olyan domain nevet, amit nem használ a tűzfal. Van továbbá arra is lehetőség, szintén csak a CLI alatt, hogy a DNS cache-be bekerülő nevekhez mi magunk definiáljuk, hogy milyen időközönként ellenőrizze a rendszer a DNS-ben az IP címeket (set ttl <másodperc> a config firewall address / edit domain_név alatt) -- felülvágva ezzel a rendes DNS-ből származó TTL információkat.

BGP neighbor ellenőrzés FortiOS alatt

Igen rugalmas a Fortigate eszközök webes felülete, valóban szinte mindent el lehet intézni a webGUI-n keresztül, a BGP routeolás épp a kivételek közé tartozik, legalábbis keresgéltem egy ideig menüben rejtett opciókat, amivel több információt ki lehetne szedni a BGP-ről, aztán persze, mint oly sok egyéb esetben is, a vége CLI lett. Érdekes különben összevetni, hogy mennyire hasonlít az IOS show ip bgp neighbors x.x.x.x kimenetére a parancs FortiOS alatti párja:

FORTIGATE $ get router info bgp neighbors 10.10.10.10

BGP neighbor is 10.10.10.10, remote AS 65200, local AS 65100, external link

  BGP version 4, remote router ID 10.1.1.1

  BGP state = Established, up for 05w5d16h

  Last read 00:00:28, hold time is 180, keepalive interval is 60 seconds

  Configured hold time is 180, keepalive interval is 60 seconds

  Neighbor capabilities:

    Route refresh: advertised and received (old and new)

    Address family IPv4 Unicast: advertised and received

    Address family IPv6 Unicast: advertised and received

  Received 295328 messages, 159 notifications, 0 in queue

  Sent 297947 messages, 170 notifications, 0 in queue

  Route refresh request: received 0, sent 0

  Minimum time between advertisement runs is 30 seconds

 For address family: IPv4 Unicast

  BGP table version 7017, neighbor version 6997

  Index 0, Offset 0, Mask 0x1

  Community attribute sent to this neighbor (both)

  Outbound path policy configured

  Route map for outgoing advertisements is *SET-COMMUNITY-OUTroot

  1 accepted prefixes

  66 announced prefixes

 For address family: IPv6 Unicast

  BGP table version 1, neighbor version 1

  Index 0, Offset 0, Mask 0x1

  0 accepted prefixes

  0 announced prefixes

 Connections established 44; dropped 43

Local host: 10.10.10.1, Local port: 7864

Foreign host: 10.10.10.10, Foreign port: 179

Nexthop: 10.10.10.1

Nexthop global: ::

Nexthop local: ::

BGP connection: non shared network

Last Reset: 05w5d16h, due to BGP Notification sent

Notification Error Message: (CeaseUnspecified Error Subcode)

A legfontosabb sorok egy az egyben az IOS kimenetét imitálják. A BGP peer IP-je után, szintén az IOS-es mintára, biggyeszthetünk mindenféle kiegészítőket, például, hogy mit hirdetünk a szomszéd felé, mit kapunk tőle, stb.:

FORTIGATE $ get router info bgp neighbors 10.10.10.10 ?
<WORD>    (advertised-routes|received prefix-filter|received-routes|routes)

Reguláris kifejezések a különféle network OS-ekben (1.)

Az előző posztban említett kézi hálózatfelderítés során többször is alkalmaztam IOS alatt reguláris kifejezéseket a különféle parancsok kimenetének szűrésére, nem kell bonyolult dolgokra gondolni, csak nagyjából ilyesféle szűrésekre:

DEVICE#sh mac-address-table | include Gi1/0/1
   1    0001.e674.baa6    DYNAMIC     Gi1/0/13
   1    0001.e674.bab8    DYNAMIC     Gi1/0/1
   1    0001.e6a2.02b6    DYNAMIC     Gi1/0/13
   1    0002.e33c.5203    DYNAMIC     Gi1/0/13
   1    0002.e33c.5316    DYNAMIC     Gi1/0/15
   1    0002.e34f.08fd    DYNAMIC     Gi1/0/13
   1    0002.e34f.0a42    DYNAMIC     Gi1/0/13
   1    0002.e352.8dbb    DYNAMIC     Gi1/0/13
   1    000f.fe02.3f48    DYNAMIC     Gi1/0/13
   1    000f.fe30.880e    DYNAMIC     Gi1/0/13
   1    000f.fe31.920d    DYNAMIC     Gi1/0/15

DEVICE#sh mac-address-table | include Gi1/0/1$
   1    0001.e674.bab8    DYNAMIC     Gi1/0/1


Nyilván egyértelmű a különbség azok számára is, akik nem ismerik a regexpeket. A $ kifejezés a keresendő minta végéhez illeszkedik, tehát az az megelőző szöveges mintának a sorvégeken kell szerepelnie, ezért nem jelenik meg egy olyan sor sem a második példában, amelynek a végén nem pontosan a "Gi1/0/1" karaktersor áll. Ez persze az egyik legegyszerűbb példa, számtalan egyéb dolgot bevethetünk még, a regexpek használatának lehetősége átszövi az IOS-t, legtöbbször persze a különféle show kimeneteket szűrjük meg velük, de vannak más alkalmazási lehetőségek is, többek közt ilyen a BGP AS-path szűrés. Vajon mi a helyzet az egyéb OS-ekben?

A márciusban kiadott legújabb FortiOS-ben (4.0MR3) a CLI referencia kézikönyv szerint az alábbi területeken nyílik lehetőségünk regexp használatra:

• Data Leakage Prvention (DLP) szabályok definiálásakor
• BGP AS-path szűrésre
• Különféle e-mail szűrésekhez (e-mail cím alapú levélszűrésre, spamszűrőkben, MIME header szűrésre)
• Weboldalak tartalom- illetve URL alapú szűrésére
• CLI-ben a get, show és diagnose parancsok kimenetének szűrésére (a szokásosnak mondható include, exclude parancsok helyett itt egyszerűen csak grep a szűrő parancs)

A H3C/3Com örökséget tovább vivő HP Networking termékekben szintén megtalálható a regexp támogatás, hogy pontosan mire is használható, arról a  "Reguláris kifejezések a különféle network OS-ekben" következő részében lesz szó.

IPSec site-to-site VPN Cisco és Fortigate eszközökkel

A korábbi Cisco-Cisco majd Cisco-Vyatta felállás után jöjjön most ismét ugyanaz, ám Cisco-Fortinet variációban. A teszteszköz egy Fortigate 60-as, még a régebbi, 3-as FortiOS-szel, de ugyanezek a CLI parancsok használhatók a legfrissebb 4-es verziójú FortiOS-ekben is. A korábbi topológia változatlan:

Az IPSec beállításokat összegző táblázat szintén változatlan, a Cisco-Cisco posztban megtalálható. A vyattás felállással ellentétben a FortiOS parancsokat nem próbálom megfeleltetni az IOS-es parancsoknak, alapvető szemléletbeli különbségek vannak a Fortigate tűzfalak és a Cisco routerek közt, túl sok lenne a különbség, így az IOS-t futtató R1 eszköz beállításai itt nem is szerepelnek, pontról pontra ugyanazt a konfigurációt használtam, amit korábban is.

A korábbi versenyzőkkel ellentétben a Fortigate viszonylag terjedelmes gyári beállításokkal érkezik, NAT/route üzemmódban (ez az alapértelmezett) a következő IP-k vannak a fizikai interfészeken beállítva:

• Internal: 192.168.1.99
• WAN1: 192.168.100.99
• WAN2: 192.168.101.99
• DMZ: 10.10.10.1

Az alapértelmezett user/jelszó páros: admin/nincs jelszó, ha nem tudjuk a jelszót, állítsuk vissza az eszközt a gyári beállításokra. A bejelentkezés után kezdhetünk az interfészekkel, a WAN1 porton lesz a WAN kapcsolatunk (10.1.1.0/24), az internalon pedig a belső háló (10.3.3.0/24), a többit le lehet lőni:

config system interface
    edit "internal"
        set ip 10.3.3.1 255.255.255.0
    next
    edit "dmz"
        set status down
    next
    edit "wan1"
        set ip 10.1.1.2 255.255.255.0
    next
    edit "wan2"
        set status down
end

A következő lépés a Phase1 adatok megadása, minden további beállítás esetén az itt létrehozott néven (TESZT-PH1) tudunk erre a VPN kapcsolatra hivatkozni.

config vpn ipsec phase1-interface
    edit "TESZT-PH1"
        set interface "wan1"
        set proposal aes256-sha1
        set keylife 28800
        set remote-gw 10.1.1.1
        set psksecret TITOK
end

Szükségünk lesz természetesen Phase2 beállításokra is, amelyek a már létrehozott Phase1 beállításokra fognak épülni:

config vpn ipsec phase2-interface
    edit "TESZT-PH2"
        set pfs enable
        set phase1name "TESZT-PH1"
        set proposal aes128-md5
        set dst-subnet 10.2.2.0 255.255.255.0
        set keylifeseconds 3600
        set src-subnet 10.3.3.0 255.255.255.0
end

Ezzel maga az IPSec konfiguráció ugyan készen van, de ne feledjük, hogy a Fortigate-ek alapvetően UTM eszközök, magától szinte semmi sem működik, ha csak nem kreálunk hozzá tűzfalszabályokat. Mielőtt azonban ténylegesen a tűzfal policy-khez nyúlnánk, definiálnunk kell a subneteket, amelyekkel dolgozgatni szeretnénk a későbbiekben:

config firewall address
    edit "R2-belso-subnet"
        set associated-interface "internal"
        set subnet 10.3.3.0 255.255.255.0
    next
    edit "R1-belso-subnet"
        set associated-interface "TESZT-PH1"
        set subnet 10.2.2.0 255.255.255.0
end

Miután készen vannak a subnetek, jöhet a tűzfal policy. Ha az alapértelmezett beállításról indulunk, akkor észrevehetjük, hogy egy szabály már létezik a tűzfalon, ami az R2 belső subnet hostjai számára hozzáférést engedélyez a WAN1 interfészen keresztül elérhető dolgokhoz. Ezt a szabályt megtarthatjuk, vagy akár törölhetjük, letilthatjuk (set status disable), attól függően, mire van épp szükségünk, ezért nem eggyel kezdődik a tűzfalszabályok számozása:

config firewall policy
    edit 2
        set srcintf "internal"
        set dstintf "TESZT-PH1"
        set srcaddr "R2-belso-subnet"           
        set dstaddr "R1-belso-subnet"           
        set action accept
        set schedule "always"
        set service "ANY"           
    next
    edit 3
        set srcintf "TESZT-PH1"
        set dstintf "internal"
        set srcaddr "R1-belso-subnet"           
        set dstaddr "R2-belso-subnet"           
        set action accept
        set schedule "always"
        set service "ANY"
end

A végére maradt a statikus route a távoli subnet felé:

config router static
    edit 1
        set device "TESZT-PH1"
        set dst 10.2.2.0 255.255.255.0
end

A FortiOS-ben külön nem szükséges menteni, amint kilépünk az end paranccsal valamilyen objektum konfigurációs módjából, a beállított értékeket a rendszer elmenti, illetve természetesen a futó konfigurációban érvényre juttatja.

A figyelmesebbeknek szemet szúrhat, hogy történt egy kis csalás ebben a Fortigate beállításban. A korábbiakban sehol sem használtam az IPSec-hez bármilyen módon köthető virtuális interfészt, VTI-t, loopback interfészt, a Cisco routeren és a Vyattán is egyszerű tunnel módban hoztam létre a kapcsolatot, nem hajtottuk át az adatokat semmilyen egyéb interfészen, csak azon, ahol kiléptek a routerből. A Fortigate esetén is elérhető ez a tunnel mód, policy-based VPN-nek hívják, config vpn ipsec phase1-interface helyett a config vpn ipsec phase1 paranccsal kell létrehozni. Phase2-ben szintén a megfelelő parancs interface nélküli változatát kell választanunk, majd egy tűzfalszabályt kell még hozzárendelnünk, ahol ACCEPT vagy DENY helyett az IPSEC műveletet kell a szabályban műveletként megadni (egy tunnelhez csak egy szabály tartozhat). Eddig egyébként még sosem sikerült értelmes módon beállítanom a policy-based VPN-t, például a távoli site-ról kezdeményezett forgalom során nem áll fel magától az IPSec kapcsolat, bármilyen tűzfal policy-vel is próbálkoztam, míg a Fortigate mögötti subnetből meginduló forgalom hatására mindig azonnal létrejött az IPSec összeköttetés.

A másik, a posztban részletesen is bemutatott módszerrel létrehozott, virtuális IPSec interfésszel operáló beállítást a Fortigate rendszerekben route-based VPN-nek nevezik. A virtuális interfész segítségével kezelhetőbbé válnak a IPSec-en keresztül kimenő vagy beérkező csomagok, átláthatóbbak a rájuk vonatkozó tűzfalszabályok, és mivel ekkor önálló interfészként jelenik meg az IPSec tunnel Fortigate-en lévő vége, bármennyi szabály vonatkozhat rá, kedvünk szerint finomhangolhatjuk.

TCP/UDP session timeout értékek beállítása FortiOS-ben

A közelmúltban egy különös problémára sikerült megtalálni a megoldást. Az egyik telephelyünkön az ERP rendszer felhasználói egyik napról a másikra elkezdtek panaszkodni, hogy mindig kidobja őket a rendszer, és hogy naponta hússzor bejelentkezni nem vicces. Persze nem is hozzám került első körben a probléma, megjárta az ERP rendszerünkért felelős outsourcing partnert, és csak utána került a hálózatos csapathoz.

Annyit érdemes tudni az ERP-nkről, hogy egy özönvíz előtti, kb. tizenöt éves Baan verziót (IV) használunk. Az összes Baan szerverünk és adatbázisunk a Global Data Centerünkben van, a szóban forgó telephelyen pedig csak kliensek vannak, így minden ERP-vel kapcsolatos forgalom át kell, hogy menjen a belső WAN-unkon. Ezen kívül pedig volt még két másik tényező is: a kérdéses telephelyen a bérelt vonalat új szolgáltatóhoz vittük, illetve két héttel később belső tűzfal is került a csomagok útjába.

Mivel az adott telephelyen én felügyeltem a bérelt vonal migrációját illetve a tűzfal telepítést, megnyertem a Baan kliensek problémáját is. Az új szolgáltatót, mint problémaforrást viszonylag hamar ki lehetett zárni, hiszen az új vonal üzembe helyezése és a tűzfal telepítése közt eltelt két hétben a Baan kliensek hasítottak, bejelentkeztek reggel, kijelentkeztek délután, nem panaszkodott senki eldobált sessionökre.

Ideiglenes megoldásként a szerveres csapattal összefogva azt a megoldást javasoltuk első körben az adott telephely Baan usereinek, hogy akiket valóban zavar, hogy nem él egész nap a sessionjük, azok használják a Global Data Centerünkben frissen telepített Windows Server 2008 alapú új terminál szerver szolgáltatást, amin fent van a Baan kliens is, kiváló, gyors (LAN) kapcsolatuk lesz az adatbázissal, stb. Közben Baan forgalomra készíttettem az MPLS szolgáltatónkkal QoS-t, hátha... persze ehhez túl sok reményt nem fűztem, de mindenesetre egyértelműen monitorozhatóvá vált, hogy van-e gond az ERP-vel kapcsolatos adatforgalommal az MPLS-ünkben, hát nem volt.

Mondanom sem kell, minden egyéb forgalom tökéletesen rendben volt, nem volt gond a WAN-on keresztül az RDP sessionökkel, CIFS-sel, HTTP-vel, semmivel, csak a Baan4 gyengélkedett. Az adott telephely LAN-jában sem történtek változások, a fizikai réteggel kapcsolatos problémákat (laza patch kábel, vacak optikai kapcsolat LAN gerincen stb.) szintén gyorsan ki lehetett szórni, mint lehetséges problémaforrásokat. Maga a Baan IV kliens program sem egy bonyolult jószág, nincsenek speciális TCP beállításai, amelyek változása esetleg okozhatna hasonló jelenséget. Volt egy zsákutca még a kliensek védelmét ellátó Symantec SEP csomaggal, hátha ott valamilyen félresikerült policy kavar be... de nem, SEP nélkül is hullottak a sessionök, ha magukra hagyták őket a userek.

Időközben a belső tűzfalas projekt futott tovább, és hogy, hogy nem egy másik telephelyen is felmerült ugyanez a gond a Baan kliensekkel nem sokkal az ottani Fortigate tűzfal cluster telepítése után. Innen már viszonylag egyszerű volt a végkövetkeztetést levonni: a Fortigate-eken akadnak fenn a Baan sessionök. Valamiért a Baan IV TCP keepalive kezelése (ha van egyáltalán ilyesmije) nem kerek, és a Fortigate tűzfalak némi inaktivitás után egyszerűen eldobják a sessiont, szegény kliens meg csak áll, és nem érti, hogy ki vette el tőle az ő kis kapcsolatát a szerverhez.

De mit lehet ezzel kezdeni? Van ugyan a FortiOS-ben egy "system session-ttl" parancs, amivel minden (!) TCP és UDP sessionön meg lehet növelni a keepalive értéket, de ezzel ugye viszonylag hamar le lehet térdeltetni a tűzfalat, hiszen annak sem végtelenek az erőforrásai. Kiderült, hogy a FortiOS 4.0-ban viszont már nem csak system szinten, hanem firewall rule-onként lehet TTL-t állítani ("set session-ttl <másodperc>" az adott rule-on belül). Szóval a megoldás mindenhol az lett, hogy a Fortigate-eket frissíteni kell legalább 4.0-ra, majd egy külön rule készült a Baan forgalomra, amelyben a session-ttl értéket be kell lőni 28800-ra (8 óra). A tanulság? A tűzfal még akkor is tud nagy gondot okozni, ha egyébként tisztességgel átengedné a kérdéses forgalmat.

Fortigate jelszó-helyreállítás

Kezdjük egy friss élménnyel: jelszó-helyreállítás Fortigate tűzfalakon. Több ilyen eszközünk is van a cégnél, és ma úgy alakult, hogy egy teszthez fel szerettem volna használni egy régóta porosodó Fortigate masinát. Ahogy az lenni szokott, a rajta beállított jelszót már senki és sehonnan nem tudja előteremteni. Természetesen a jelszó-helyreállításról szemérmesen hallgat a gyártótól letölthető több száz oldalas dokumentáció is. Mivel a különböző fórumokon, blogokon egymásnak némileg ellentmondó információk találhatók a témában, talán teljesen nem haszontalan, ha közzéteszem a tudnivalókat egy posztban.

Természetesen, mint ahogy azt más gyártóknál is megszokhattuk a jelszó-helyreállításhoz konzolportos, fizikai hozzáférésre van szükség, a soros port beállításai a szokásosak: 9600, 8N1. Az eszköz bootolása során elfecsegi nekünk a serial számát is, ezt másoljuk ki magunknak jegyzettömbbe vagy bárhova ahol át tudjuk szerkeszteni és ahonnan újra vágólapra tehetjük:

Ver:04000000
Serial number:FGT-XXXXXXXXXXXX
RAM activation
Total RAM: 128MB
Enabling cache...Done.
Scanning PCI bus...Done.
Allocating PCI resources...Done.
Enabling PCI resources...Done.
Zeroing IRQ settings...Done.
Verifying PIRQ tables...Done.
Boot up, boot device capacity: 30MB.
Press any key to display configuration menu...
......

Reading boot image 1322895 bytes.
Initializing firewall...
System is started.


HOSTNEV login:

A kimásolt serial szám elé közvetlenül írjuk be a "bcpb" karaktereket (esetünkben tehát „bcpbFGT-XXXXXXXXXXXX”), így megkapjuk a jelszót a "maintainer" nevű felhasználóhoz. Többen is említik, hogy a jelszó case sensitive, erre tehát ügyeljünk.

HOSTNEV login: maintainer
Password: ********************
Welcome !

HOSTNEV #

Nincs túl sok időnk a felhasználónév/jelszó páros klimpírozására, egyes fórumok szerint 14 másodperc, mások szerint 30, megint mások szerint 60 másodperc áll rendelkezésünkre, hogy belépjünk a "maintainer" userrel, ezért érdemes előre összeszerkeszteni és vágólapra tenni a jelszót. Állítólag léteznek olyan Fortigate típusok is, amelyeknél egyáltalán nincs időkorlát. Ha idáig eljutottunk, akkor jelszó-helyreállítás fronton két lehetőségünk van: felülírhatjuk az "admin" felhasználó jelszavát, illetve törölhetjük a teljes konfigurációt (az alapértelmezett "admin" jelszó üres).

Az "admin" userhez tartozó jelszó új jelszóval való felülírása a konfiguráció egyéb részeinek megtartása mellett:

HOSTNEV # config system admin
HOSTNEV (admin) # edit admin
HOSTNEV (admin) # set password UJ-JELSZO
HOSTNEV (admin) # end
HOSTNEV #

A teljes konfiguráció törlése, gyári alapbeállításokra való visszaállás:

HOSTNEV# execute factoryreset
This operation will reset the system to factory default!
Do you want to continue? (y/n)y

System is resetting to factory default...

The system is going down NOW !!