2018. október 13., szombat

Cisco eszközök jelszavas védelme

Kapcsolódás lehet console, aux vagy vty mód. A console kapcsolatot általában a kezdeti beállítások megadásához használjuk. Ekkor a PC soros portját csatlakoztatjuk az eszköz konzolportjához a rollover kábel segítségével. Az aux kapcsolat a modemen keresztüli távoli elérés biztosításához szükséges. Általában routereken találkozhatunk vele. A vty portok virtuális portok (virtual teletype), telnet vagy ssh használatával hálózaton keresztül érhetők így el az eszközök. A virtuális portok száma eszközönként különböző lehet, a régebbi típusoknál 5 egyidejű kapcsolatot használhatunk (line vty 0 4), az újabbaknál 16-ot (line vty 0 15).

Jelszavak beállítása

A konzolkapcsolaton keresztül történő hozzáférés a console porthoz tartozó line konfigurációs módban megadott jelszóval korlátozható:

Router(config)# line console 0
Router(config-line)# password <password>
Router(config-line)# login

Az aux porton keresztül történő hozzáférés az aux porthoz tartozó line konfigurációs módban megadott jelszóval korlátozható:

Router(config)# line aux 0
Router(config-line)# password <password>
Router(config-line)# login

Az eszköz hálózaton keresztül történő eléréséhez vty kapcsolathoz tartozó line konfigurációs módban megadott jelszóval korlátozható:

Route(config)# line vty 0 4
Router(config-line)# password <password>
Router(config-line)# login

A 0 4 öt egyidejű sávon-belüli kapcsolatot jelöl. Minden kapcsolathoz külön jelszó állítható be a konkrét vonalkapcsolat számának megadásával (pl.: line vty 0).

Cisco CLI parancsmódok

A Cisco IOS a parancssorhoz történő hozzáférés két szintjét különbözteti meg:

felhasználói EXEC módot
privilegizált EXEC módot
A felhasználói EXEC módban végrehajtható parancsokkal információ kérhető az eszköz működéséről, míg az eszköz működését megváltoztató parancsok kiadásához privilegizált szintű hozzáférés szükséges. A privilegizált EXEC mód elérését jelszóval korlátozhatjuk. Ennek két módja van:

Router(config)#enable password <password>
Router(config)#enable secret <password>

Alapvetően az a különbség a két módszer között, hogy az enable secret titkosítva tárolja a jelszót a konfigurációs állományban, míg az enable password nem. Ha mindkét jelszót megadjuk, akkor az enable secret lesz érvényes! A jelszavak beállításának helyességét ellenőrizhetjük a show running-config parancs segítségével.

Egy running-config részlet:

Router#sh startup-config
Using 545 bytes
!
version 12.4
no service timestamps log datetime msec
no service timestamps debug datetime msec
no service password-encryption
!
hostname Router
!
!
!
enable secret 5 $1$mERr$9cTjUIEqNGurQiFU.ZeCi1
enable password cisco
!

Az enable secret kivételével a jelszavakat a konfiguráció (startup-config, running-config) tárolja egyszerű szöveg formájában. Lehetőség van az eszközön tárolt összes jelszó titkosítására, hogy az illetéktelenek ne tudják könnyen kiolvasni azokat. A globális konfigurációs módban kiadott

Router(config)#service password-encryption

parancs garantálja, hogy az összes jelszó titkosítva legyen. A fenti parancs kiadása után mind a már meglévő, mind a jövőbeli jelszavak titkosítva lesznek letárolva. Ez a titkosítás viszont nem megbízható, a neten számtalan oldal található, ahol pillanatok alatt kiírják az eredeti jelszót a titkosított változat megadása után (Cisco Type 7 Password Decrypt). Így ez csak arra jó, hogy a hátunk mögül ne tudják kiolvasni a jelszót a konfigurációs állományból.

A fenti running-config részlet a service password-encryption kiadása után:

Router#sh running-config
Building configuration…

Current configuration : 551 bytes
!
version 12.4
no service timestamps log datetime msec
no service timestamps debug datetime msec
service password-encryption
!
hostname Router
!
!
!
enable secret 5 $1$mERr$9cTjUIEqNGurQiFU.ZeCi1
enable password 7 0822455D0A16

Alapértelmezett beállítások:

!
line con 0
line aux 0
login
line vty 0 4
 login
line vty 5 15
 login
!

A login parancs megadásával állítjuk be, hogy az adott porton keresztül hitelesítés szükséges. Ha a login parancs üresen áll, akkor a hitelesítés szükséges, de mivel nincs jelszó beállítva, ezért nem lehetséges belépni az adott porton keresztül! Pl. a vty-n keresztüli hozzáférés így alakul:

telnet 192.168.1.104

Password required, but none set

A kapcsolat megszakadt az állomással.

Ha megadjuk a vty jelszót, akkor már tovább léphetünk, de jelszó nélkül nem enged be a privilegizált exec módba:

telnet 192.168.1.104

User Access Verification

Password:
Router>ena
% No password set
Switch>

Ha mind a vty, mind az enable jelszót beállítjuk, akkor már lehetőségünk van távolról konfigurálni az eszközt:

telnet 192.168.1.104

User Access Verification

Password:
Router>enable
Password:
Router#

Ha az adott porton kiadjuk a no login parancsot, akkor ez azt jelenti, hogy nem szükséges a hitelesítés, így jelszó nélkül is be tudunk lépni, függetlenül attól, hogy van-e jelszó megadva, vagy sem.

A console porton kiadott üres login azt eredményezheti, hogy ha más lehetőségünk nincs, akkor nem fogunk tudni belépni az eszközbe (csak a jelszó helyreállítási folyamat után).
Sokkal biztonságosabb, ha adatbázisból vagy távoli radius illetve tacacs+ szerver általi hitelesítést használunk.
A hálózathoz való hozzáférés ellenőrzésére két kiemelkedő biztonsági protokoll található: Cisco TACACS + és RADIUS.
RADIUS Háttér
A RADIUS olyan hozzáférési kiszolgáló, amely AAA protokollt használ. Ez egy elosztott biztonsági rendszer, amely biztosítja a hozzáférést a hálózathoz és a hálózati szolgáltatásokhoz a jogosulatlan hozzáférés ellen. A RADIUS három összetevőből áll:

Egy protokoll, amelyen a felhasználói adatkommunikációs protokollt (UDP) / IP-t használják.

Egy szerver.

Egy ügyfél.

A kiszolgáló központi számítógépen futtatható, jellemzően az ügyfél telephelyén, míg az ügyfelek a betárcsázós hozzáférési szervereken tartózkodnak, és az egész hálózaton eloszthatók. A Cisco beépítette a RADIUS klienst a Cisco IOS Software Release 11.1 és újabb verziójába, valamint más eszközökhöz.

Ügyfél / kiszolgáló modell
A hálózati hozzáférési kiszolgáló (NAS) a RADIUS ügyfélként működik. Az ügyfél felelős azért, hogy átadja a felhasználói adatokat a kijelölt RADIUS kiszolgálóknak, majd a visszaküldött válaszra reagál. A RADIUS-kiszolgálók felelősek a felhasználói kapcsolódási kérelmek fogadásáért, a felhasználó hitelesítéséért és az összes olyan konfigurációs információ visszaszolgáltatásáért, amely ahhoz szükséges, hogy az ügyfél kiszolgálja a szolgáltatást a felhasználónak. A RADIUS-kiszolgálók proxy kliensekként működhetnek más típusú hitelesítési kiszolgálókhoz.

Hálózati biztonság
Az ügyfél és a RADIUS szerver közötti tranzakciók megosztott titok használatával kerülnek hitelesítésre, amelyet soha nem küld a hálózaton. Ezenkívül minden felhasználói jelszó titkosításra kerül az ügyfél és a RADIUS szerver között. Ez kiküszöböli annak a lehetőségét, hogy valaki, aki egy nem biztonságos hálózatra ugrik, meghatározhatja a felhasználó jelszavát.

Rugalmas hitelesítési mechanizmusok
A RADIUS szerver számos módszert támogat a felhasználó hitelesítéséhez. A felhasználó által megadott felhasználói névvel és eredeti jelszóval támogatva támogatja a PPP-t, a jelszó-hitelesítési protokollt (PAP) vagy a kihívások kezelése hitelesítési protokollt (CHAP), a UNIX bejelentkezést és más hitelesítési mechanizmusokat.

Szerverkód elérhetősége
A kiszolgálói kód számos elosztása kereskedelmi forgalomban és szabadon elérhető. A Cisco szerverek közé tartoznak a Cisco Secure ACS for Windows, a Cisco Secure ACS for UNIX és a Cisco Access Registrar.

TACACS + és RADIUS összehasonlítása
Ezek a részek összehasonlítják a TACACS + és a RADIUS számos jellemzőjét.

UDP és TCP
A RADIUS UDP-t használ, míg a TACACS + TCP-t használ. A TCP számos előnnyel rendelkezik az UDP felett. A TCP összeköttetés-orientált szállítást kínál, míg az UDP a legjobb erőfeszítést biztosítja. A RADIUS további programozható változókat igényel, mint például a továbbadási kísérleteket és időeltolódásokat a legjobb erőfeszítéssel történő szállítás kompenzálására, de hiányzik a beépített TCP szállítási támogatás szintje:

A TCP-használat külön nyugtázást nyújt, hogy egy kérés érkezett, körülbelül (körülbelül) egy hálózati útkeresztezési időn (RTT) belül, attól függetlenül, hogy mennyire terhelik és lassítják a háttér-hitelesítési mechanizmust (TCP-visszaigazolást).

A TCP azonnali jelzést ad a leállt vagy nem futó kiszolgálóról egy reset (RST) segítségével. Meghatározhatja, hogy a kiszolgáló összeomlik és visszatér-e a szolgáltatáshoz, ha hosszú élettartamú TCP kapcsolatokat használ. Az UDP nem tudja megmondani a különbséget a leállt kiszolgáló, a lassú szerver és a nem létező kiszolgáló között.

A TCP keepalives használatával a kiszolgáló összeomlása észlelhető a sávon kívül a tényleges kérésekkel. Több szerverhez való kapcsolódás egyszerre is megmaradhat, és csak olyan üzeneteket kell üzennie, amelyekről tudjuk, hogy futnak és futnak.

A TCP skálázhatóbb és alkalmazkodik a növekvő, valamint a zsúfolt hálózatokhoz.

Csomagkódolás
A RADIUS csak a jelszót titkosítja a hozzáférési kérés csomagban, az ügyféltől a kiszolgálóig. A csomag többi része titkosítatlan. Az egyéb információkat, például a felhasználónevet, a felhatalmazott szolgáltatásokat és a könyvelést egy harmadik fél rögzítheti.

A TACACS + titkosítja a csomag teljes testét, de hagyja a standard TACACS + fejlécet. A fejlécben egy mező jelzi, hogy a szervezet titkosított-e vagy sem. A hibakeresési célok érdekében hasznos a csomagok testének titkosítása. Normális működés közben azonban a csomag teste teljesen titkosítva van a biztonságosabb kommunikáció érdekében.

Hitelesítés és engedélyezés
A RADIUS egyesíti a hitelesítést és az engedélyezést. A RADIUS-kiszolgáló által az ügyfélnek küldött hozzáférési-elfogadási csomagok engedélyezési információkat tartalmaznak. Ez megnehezíti a hitelesítést és az engedélyezést.

A TACACS + az AAA architektúrát használja, amely elválasztja az AAA-t. Ez lehetővé teszi a különálló hitelesítési megoldásokat, amelyek még mindig használhatják a TACACS + -ot engedélyezéshez és számvitelhez. Például a TACACS + segítségével lehetőség van Kerberos hitelesítésre és TACACS + engedélyezésre és számvitelre. Miután a NAS hitelesíti a Kerberos kiszolgálón, engedélykéréseket kér a TACACS + kiszolgálótól, anélkül, hogy újra hitelesítené. A NAS tájékoztatja a TACACS + kiszolgálóról, hogy sikeresen hitelesítette a Kerberos kiszolgálón, és a kiszolgáló ezt követően megadja az engedélyezési adatokat.

Egy munkamenet során, ha további engedélyezési ellenőrzésre van szükség, a hozzáférési szerver egy TACACS + kiszolgálóval ellenőrzi annak megállapítását, hogy a felhasználó számára engedélyt kapott-e egy adott parancs használatához. Ez nagyobb ellenőrzést biztosít a parancskiszolgálón végrehajtható parancsok felett, miközben függetleníti a hitelesítési mechanizmust.

Többprotocol támogatás
A RADIUS nem támogatja ezeket a protokollokat:

AppleTalk Remote Access (ARA) protokoll

NetBIOS keret protokoll protokoll

Novell Asynchronous Services Interface (NASI)

X.25 PAD kapcsolat

A TACACS + multiprotocol támogatással rendelkezik.

Router Management
A RADIUS nem teszi lehetővé a felhasználók számára, hogy ellenőrizzék, mely parancsokat lehet végrehajtani egy routeren, és amelyek nem. Ezért a RADIUS nem annyira hasznos a router kezelésénél, sem a terminálszolgáltatásokhoz rugalmasan.

A TACACS + kétféle módon szabályozhatja az útválasztó parancsok engedélyezését felhasználóonként vagy csoportonként. Az első módszer a jogosultsági szintek hozzárendelése a parancsokhoz, és az útválasztó ellenőrizze a TACACS + kiszolgálóval, függetlenül attól, hogy a felhasználó jogosult-ea megadott jogosultság szintjén. A második módszer az, hogy a TACACS + kiszolgálóban, egy felhasználóonként vagy csoportonként, a megengedett parancsokat kifejezetten meg kell adni.

Az interoperabilitás
A RADIUS RFC-k (RFC-k) különböző értelmezései miatt a RADIUS RFC-k betartása nem garantálja az interoperabilitást. Bár számos gyártó implementálja a RADIUS ügyfeleket, ez nem jelenti azt, hogy interoperábilisak. A Cisco a legtöbb RADIUS attribútumot hajtja végre, és következetesen többet ad hozzá. Ha az ügyfelek csak a szabványos RADIUS-attribútumokat használják szervereikben, akkor együttműködhetnek több szállító között, amíg ezek a gyártók ugyanazokat az attribútumokat hajtják végre. Azonban sok gyártó kiterjesztéseket hajt végre, amelyek tulajdonosi tulajdonságok. Ha egy ügyfél ezen szállító-specifikus kiterjesztett attribútumok egyikét használja, akkor az interoperabilitás nem lehetséges.


A TACACS + és a RADIUS közötti korábban említett különbségek miatt az ügyfél és a kiszolgáló között létrejött forgalom mennyisége különbözik. Ezek a példák illusztrálják a kliens és a kiszolgáló közötti forgalmat a TACACS + és a RADIUS esetében, ha a router kezelése hitelesítéssel, végrehajtható engedélyezéssel, parancs-engedélyezéssel (melyet a RADIUS nem tehet), a végrehajtó könyvelésből és a parancsok könyveléséből (amelyet a RADIUS nem tehet) használ.

Feltételezzük a bejelentkezési hitelesítést, a végrehajtás engedélyezését, a parancsok engedélyezését, a start-stop végrehajtás könyvelését és a parancsok könyvelését a TACACS + alkalmazásával, amikor egy felhasználó Telnetet küld egy routernek, parancsot hajt végre és kilép a routerből:

A Radius esetén is feltételezzük a bejelentkezési hitelesítést, a végrehajtás engedélyezését és a start-stop exec számlázást a RADIUS alkalmazásával, amikor egy felhasználó Telnetet egy routerhez, végrehajt egy parancsot, és kilép az útválasztóból (más irányítási szolgáltatások nem állnak rendelkezésre.


Nincsenek megjegyzések:

Megjegyzés küldése