A következő címkéjű bejegyzések mutatása: jelszó. Összes bejegyzés megjelenítése
A következő címkéjű bejegyzések mutatása: jelszó. Összes bejegyzés megjelenítése

2012-02-29

Alapvető biztonsági beállítások MikroTiken

Néhány poszttal ezelőtt volt szó a Mikrotik eszközök ISR routerként történő használatáról, akkor egy-két teljesen szokványos lehetőséget (SNAT, DNAT, DHCP kliens WAN oldalon, DHCP szerver LAN oldalon, NTP kliens, WPA2 PSK wifi) vettünk elő CLI-ben, viszont tárva-nyitva hagytuk a rendszert, így valószínűleg nem élne túl a konfigurációnk pár napnál hosszabb időt érintetlenül publikus interneten. A biztonságosabb működés érdekében a legelső lépés az alapértelmezett admin jelszó megváltoztatása:
[admin@Tik] > /password
old password: password
new password: *************
retype new password: *************
Ez már önmagában sokat jelent, itt azonban semmiképp se pihenjünk még le, következhet a nem használt szolgáltatások kikapcsolása. Amire ténylegesen is szükség lehet, az az SSH, a többit bátran le lehet tiltani:
/ip service
set telnet disabled=yes
set ftp disabled=yes
set www disabled=yes
set www-ssl disabled=yes
set api disabled=yes
set winbox disabled=yes
Akár le is ellenőrizhetjük, hogy mindent sikerült-e kikapcsolni:
[admin@Tik] > /ip service print Flags: X - disabled, I - invalid 
#   NAME        PORT ADDRESS            CERTIFICATE                                     
0 X telnet                23
1 X ftp                   21
2 X www                   80
3   ssh                   22
4 X www-ssl              443                   none
5 X api                 8728
6 X winbox              8291
A RouterOS-en alapértelmezésben figyel UDP-n a bandwidth-server. Ez az IPerf-hez hasonló eszköz, amivel sávszélesség teszteket végezhetünk, érdemes ezt is addig pihentetni, amíg nincs rá ténylegesen szükség. A bandwidth-server szolgáltatás beállítása nem az IP service-ek közt található:
/tool bandwidth-server
set enabled=no
Végül tanácsos legalább a WAN és a WLAN interfészen letiltani a MikroTik Neighbor Discovery protocolt (MNDP) és a CDP-t, hogy ne szivárogtassunk feleslegesen információkat a rendszerről:
/ip neighbor discovery
set wlan1 disabled=yes
set ether1 disabled=yes
Ezzel az alapvető biztonsági beállításokon túl is vagyunk, a környezettől függően természetesen sok egyéb lehetőségünk van még a RouterOS alatt: tűzfalszabályok beállítása, központi RADIUS authentikáció, SNMPv3, BGP MD5 authentikáció, stb. ebben a posztban csupán a legáltalánosabb lehetőségeket vettük sorra.

2011-10-31

Parancssori SNMP eszközök (4.) - snmpset

Az első, második és harmadik részben hol keveset, hol sokat, de mindig csak olvastuk az adatokat az SNMP fából, pedig ez olyan, mint a karácsonyfa, nem csak szedegetni lehet róla a dolgokat, de ráaggatni is. Természetesen van parancssori eszköz erre is, snmpset a program neve, és éppúgy a Net-SNMP csomag része, mint az snmpget, az snmpwalk, snmptable.

Az snmpset néhány paraméterrel többet igényel mint az egyéb eszközök. Az első és talán a legfontosabb különbség, hogy olyan community stringet kell megadnunk neki, amellyel írni is lehet a fába. Tipikusan az alapértelmezett RO string a "public" szokott lenni, az alapértelmezett RW string pedig a "private". Ökölszabály, hogy soha nem használjuk az RW stringet (főleg SNMPv1 és SNMPv2 esetén), csak akkor, amikor tényleg írunk is a fába -- de erre még később visszatérünk. Persze önmagában a community string nem elég, pontosan meg kell adnunk, hogy hol, illetve azt is, hogy milyen típusú adatot szeretnénk tárolni. A következő példában egy Nortel 5510-esen a system ágat kilistázzuk, majd átírjuk az egyik levelét és újra kilistázzuk:

admin@NMS:~$ snmpwalk -v1 -cpublic 10.10.10.1 system
SNMPv2-MIB::sysDescr.0 = STRING: Ethernet Routing Switch 5510-24T  HW:32  FW:4.2.0.12  SW:v4.2.0.002
SNMPv2-MIB::sysObjectID.0 = OID: SNMPv2-SMI::enterprises.45.3.52.1
DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (1132653378) 131 days, 2:15:33.78
SNMPv2-MIB::sysContact.0 = STRING: Telecom Team
SNMPv2-MIB::sysName.0 = STRING: TESTSW-01
SNMPv2-MIB::sysLocation.0 = STRING: Testlab
SNMPv2-MIB::sysServices.0 = INTEGER: 3


admin@NMS:~$ snmpset -v1 -cprivate 10.10.10.1 SNMPv2-MIB::sysContact.0 s NINCS
SNMPv2-MIB::sysContact.0 = STRING: NINCS


admin@NMS:~$ snmpwalk -v1 -cpublic 10.10.10.1 system
SNMPv2-MIB::sysDescr.0 = STRING: Ethernet Routing Switch 5510-24T  HW:32  FW:4.2.0.12  SW:v4.2.0.002
SNMPv2-MIB::sysObjectID.0 = OID: SNMPv2-SMI::enterprises.45.3.52.1
DISMAN-EVENT-MIB::sysUpTimeInstance =
Timeticks: (1132667603) 131 days, 2:17:56.03
SNMPv2-MIB::sysContact.0 = STRING: NINCS
SNMPv2-MIB::sysName.0 = STRING: TESTSW-01
SNMPv2-MIB::sysLocation.0 = STRING: Testlab
SNMPv2-MIB::sysServices.0 = INTEGER: 3


Az snmpset paraméterei a példa alapján nagyjából egyértelműek lehetnek, az egyetlen kérdéses elem az az adattípus megadása, ez közvetlenül az érték előtt szerepel a parancssori paramétereinkben, ami esetünkben egy "s", azaz string érték volt. Értelemszerűen egy adott OID-be csak a MIB-ben definiált típusú adatot tudunk beírni. Az egyéb lehetséges típusok felsorolása az snmpset --help outputjának a végéről:

  TYPE: one of i, u, t, a, o, s, x, d, b
    i: INTEGER, u: unsigned INTEGER, t: TIMETICKS, a: IPADDRESS
    o: OBJID, s: STRING, x: HEX STRING, d: DECIMAL STRING, b: BITS
    U: unsigned int64, I: signed int64, F: float, D: double


Nem csak a típuson csúszhat meg az írás. Vannak ugyanis a fában igen terbélyes ágak, ahová egyáltalán nem írhatunk be semmit, még RW community stringgel sem, ezen OID-k esetén a MIB-ben a MAX-ACCESS tulajdonság "read-only" értékű, így a felülírásuk nem lehetséges, például nem tudjuk átírni egyebek mellett az interfészek neveit sem, pedig a string mint adattípus stimmelne:

admin@NMS:~$ snmpwalk -v1 -cpublic 10.10.10.1 IfName
IF-MIB::ifName.1 = STRING: ifc1 (Slot: 1 Port: 1)
IF-MIB::ifName.2 = STRING: ifc2 (Slot: 1 Port: 2)
IF-MIB::ifName.3 = STRING: ifc3 (Slot: 1 Port: 3)
IF-MIB::ifName.4 = STRING: ifc4 (Slot: 1 Port: 4)
IF-MIB::ifName.5 = STRING: ifc5 (Slot: 1 Port: 5)
IF-MIB::ifName.6 = STRING: ifc6 (Slot: 1 Port: 6)
IF-MIB::ifName.7 = STRING: ifc7 (Slot: 1 Port: 7)
IF-MIB::ifName.8 = STRING: ifc8 (Slot: 1 Port: 8)
IF-MIB::ifName.9 = STRING: ifc9 (Slot: 1 Port: 9)
IF-MIB::ifName.10 = STRING: ifc10 (Slot: 1 Port: 10)
IF-MIB::ifName.11 = STRING: ifc11 (Slot: 1 Port: 11)
IF-MIB::ifName.12 = STRING: ifc12 (Slot: 1 Port: 12)
IF-MIB::ifName.13 = STRING: ifc13 (Slot: 1 Port: 13)
IF-MIB::ifName.14 = STRING: ifc14 (Slot: 1 Port: 14)
IF-MIB::ifName.15 = STRING: ifc15 (Slot: 1 Port: 15)
IF-MIB::ifName.16 = STRING: ifc16 (Slot: 1 Port: 16)
IF-MIB::ifName.17 = STRING: ifc17 (Slot: 1 Port: 17)
IF-MIB::ifName.18 = STRING: ifc18 (Slot: 1 Port: 18)
IF-MIB::ifName.19 = STRING: ifc19 (Slot: 1 Port: 19)
IF-MIB::ifName.20 = STRING: ifc20 (Slot: 1 Port: 20)
IF-MIB::ifName.21 = STRING: ifc21 (Slot: 1 Port: 21)
IF-MIB::ifName.22 = STRING: ifc22 (Slot: 1 Port: 22)
IF-MIB::ifName.23 = STRING: ifc23 (Slot: 1 Port: 23)
IF-MIB::ifName.24 = STRING: ifc24 (Slot: 1 Port: 24)
IF-MIB::ifName.10001 = STRING: ifc10001 VLAN #1
IF-MIB::ifName.10101 = STRING: ifc10101 VLAN #101
IF-MIB::ifName.10111 = STRING: ifc10111 VLAN #111
IF-MIB::ifName.10112 = STRING: ifc10112 VLAN #112
IF-MIB::ifName.11099 = STRING: ifc11099 VLAN #1099
 

admin@NMS:~$ snmpset -v1 -cprivate 10.10.10.1 IF-MIB::ifName.1 s IFACE1
Error in packet.
Reason: (noSuchName) There is no such variable name in this MIB.
Failed object: IF-MIB::ifName.1


Hiába van azonban korlátozva már MIB szinten az SNMP fába való írás, nem rohangászhatunk állandóan SNMP RW stringekkel a hálózaton, hiszen SNMP v3 alatt minden kódolatlanul jön és megy, ami a legtöbb környezetben kockázatokat hordoz. Hogy ez mennyire így van, megosztok egy konkrét példát, ami a jelenlegi H3C / HPN eszközök nagyjából két generációval ezelőtti felmenőit érinti. Konkrétan a 3Com 4000-es széria darabjairól van szó, pl. a 4050-es, 4060-as, 4070-es, 4400-as, 4900-as stb. eszközökről, amelyek kb. 2004-2006-ban számítottak frissnek a piacon. Ezeken az eszközökön alapértelmezetten létezik az "admin", a "manager" és a "monitor" nevű felhasználó, és ha emlékeim nem csalnak, akkor az SNMP is alapértelmezetten be van kapcsolva, ráadásul olyan szörnyen "valószerűtlen" alapértékekkel, mint a "public" RO és a "private" RW community string. Ha pedig ismerjük az RW stringet, akkor tudunk írni az SNMP fába, például arra a helyre is, ahol a "monitor" nevű felhasználó jelszava van:

root@NMS:~# snmpset -v1 -cprivate 10.10.10.2 .1.3.6.1.4.1.43.10.4.2.1.4.7.109.111.110.105.116.111.114 s titok
SNMPv2-SMI::enterprises.43.10.4.2.1.4.7.109.111.110.105.116.111.114 = STRING: "titok"
root@NMS:~# telnet 10.10.10.2

Entering character mode
Escape character is '^]'.

Login: monitor
Password: titok

Menu options: ---------------------3Com Switch 4070---------------------
 bridge             - Administer bridge-wide parameters
 fabric             - Administer XRN fabrics
 feature            - Administer system features
 logout             - Logout of the Command Line Interface
 physicalInterface  - Administer physical interfaces
 protocol           - Administer protocols
 system             - Administer system-level functions
 trafficManagement  - Administer traffic management

Type  ? for help
-------------------------------------TESTSW-2 (1)-----------------------
Select menu option: logout

exiting session....
Connection closed by foreign host
root@NMS:~#


Még egy érdekesség a 3Com-os felhasználónevekkel kapcsolatban, ha megnézzük az OID-t ahová írtunk, láthatjuk, hogy az OID vége az, hogy: "109.111.110.105.116.111.114". Ha most utánanézünk, hogy mi is az ASCII kódja a "monitor" egyes karaktereinek, akkor már nem is olyan nehéz kitalálni, hogyan lehet a jóval több jogosultsággal bíró "manager" felhasználó jelszavát átírni. Az "admin" OID-je egy picit különbözik, de nem sokban:

2010-12-20

Expect

Előfordul, hogy nincs jobb megoldás a kézi vezérlésnél, mert a központi management eszközben nincs olyan opció, amire szükségünk lenne, vagy van ugyan valami hasonló, de nem pontosan azt csinálja. Ilyenkor aztán marad az SSH, Telnet, command line. Viszont ha sok eszközön kell ugyanazt bepötyögni, hát, az bizony lélekölő feladat, nem is szívesen kezdek ilyesmibe. Helyette jöhet az Expect. Ez egy remek kis linuxos program, amivel bármilyen parancssoros interaktív kommunikációt le lehet szkriptelni, készíthetünk elágazásokat, használhatunk változókat, meghívhatunk külső programokat, igazi svájci bicska.

További magyarázatok helyett álljon itt egy példa, amely bejelentkezik Linux alól egy Cisco eszközre SSH-n keresztül (spawn ssh -l $ap_user $ap_ip) és beállít ezt-azt. Ha még soha nem jelentkeztünk be erre az eszközre, akkor ugye meg kell erősítenünk, hogy tényleg elfogadjuk azt az RSA kulcsot, amit az SSH szerver küld a kliensünk számára, viszont ilyesmire csak az első bejelentkezésnél kér minket az SSH kliens, minden további bejelentkezésnél a szerver RSA kulcsát a saját kis "known_hosts" fájljában lévő kulccsal veti össze, és nem kérdez alapból semmit. A kilencedik sor ezt a helyzetet kezeli le, küld egy "yes"-t, ha még nem látott ilyen RSA kulcsot, ellenkező esetben pedig csendben timeoutol az ötödik másodperc után és folytatja a következő sorral. Maga a konfiguráció egyébként, amit a szkript elvégez, az egy új, "minta" nevű SNMPv3 user felvétele a "MINTAcsoport" nevű SNMPv3 group-ba, illetve a hozzá tartozó jelszó beállítása, majd a teljes konfiguráció mentése:

#!/usr/bin/expect

set ap_user [lindex $argv 0]
set ap_pass [lindex $argv 1]
set ap_ip [lindex $argv 2]
set timeout 5

spawn ssh -l $ap_user $ap_ip
expect "Are you sure" { send "yes\r"} timeout {}
expect "password:"
send "$ap_pass\r"
expect "#"
send "conf t\r"
expect "(config)#"
send "snmp-server user minta MINTAcsoport v3 auth md5 MINTAjelszo\r"
expect "(config)#"
send "exit\r"
expect "#"
send "copy run start\r"
expect "Destination"
send "\r"
expect "#"
send "exit\r"
expect "closed"
A kódból látható, hogy ezt a szkriptet változókkal kell meghívni, a szkript neve után meg kell adnunk az admin user nevét, jelszavát, majd azt az IP-t is, ahová be szeretnénk jelentkezni. Ez a megoldás jelentősen megkönnyíti az expect szkriptünk ciklusból való meghívását, így ugyanis könnyen fabrikálhatunk olyan shell szkriptet köré, amivel minden adminisztrálandó eszközünkön el tudjuk végezni a kérdéses feladatot.

2010-12-15

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 !!