<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Mili kolegovia,<br>
<br>
toto je edukacny prispevok z oblasti praktickeho vyuzitia AAA
(Authentication, Authorization, Accounting), necitajte ho, ak je
obsahom alebo jeho urovnou mimo ramca Vasho zaujmu. Prispevok obsahuje
rozne formatovanie, preto moze v niektorych jednoduchsich e-mailovych
klientoch vyzerat menej prehladne.<br>
<br>
<b>MOTIVACIA<br>
<br>
</b>Mate v sprave viacero linuxovych serverov, manazovatelnych
switchov,
accesspointov, a pod., a ich spravu zdielate s inymi ludmi? Ak ano,
vadi Vam, nastavovanie viacerych pristupovych hesiel pre Vas a tiez
Vasich kolegov osobitne na kazdom zariadeni, ich zmeny, ked kolegovia
zabudnu, resp. ziadanie
kolegov o zmeny zabudnutych alebo vyexpirovanych hesiel k roznym vyssie
spomenutym sietovym zariadeniam (ved kto si ma pamatat tolko hesiel,
nie?)? Zda sa Vam nastavovanie rovnakych hesiel vsade malo bezpecne a
malo flexibilne? Ak ste tieto problemy aj ciastocne vyriesili napr. s
pomocou zretazenej RSA/DSA autentifikacie, rozmyslate nad tym, ako do
toho zaclenit sietove zariadenia, ktore to neumoznuju (vacsina
manazovatelnych switchov a accesspointov)? Ak Vas tato tema zaujima a
mate cas a chut, citajte dalej, ci odlozte na neskorsie precitanie. V
opacnom pripade prepacte za spam, presunte tento mail do kosa a pokojne
sa venujte svojmu core businessu.<br>
<br>
Ak si odmyslime premakany, ale proprietarny, a preto upadajuci, Cisco
protokol TACACS+, odpoved mi pripada byt jasna - budeme rozoberat
moznosti protokolu <u><b>RADIUS</b></u> na vyssie spomenute ucely.
Jeho
potencialny nastupca DIAMETER, ktory by mal vychytat nielen nedostatky
RADIUSu voci TACACS+, ale je v istych kruhoch povazovany za AAA
protokol novej generacie,
zatial nie je velmi rozsireny v "nasich" aplikaciach, takze o nom mozno
inokedy.<br>
<br>
<b>PRIPADOVA STUDIA</b><br>
<br>
Traja admini, Peto, Jano a Laco
spravuju v 2 spriatelenych firmach priamo alebo s pomocou svojich
technikov niekolko linuxovych
serverov/routerov/firewallov, a vela
aktivnych sietovych prvkov (manazovatelne switche a accesspointy s
podporou protokolu RADIUS). Dalej maju k dispozicii zopar v sieti
distribuovanych freeRADIUS serverov, ktore sa kvoli bezpecnosti
zalohuju failoverom (konfiguracia failoveru je mimo ramec tohto
prispevku, lebo som si ju zatial nenastudoval a neodskusal, ale
iniciative poslat o
tomto prispevok sa medze nikomu nekladu). <br>
<br>
AUTENTIFIKACIA<br>
<br>
Kazdy z nasich adminov a technikov chce mat <u><b>jediny username a
password</b></u>,
ktorym sa bude prihlasovat do manazovatelnych aktivnych prvkov a aj
linuxovych masin (a dajme tomu aj do posty a inych aplikacii, ktore su
na niektorych z tychto serverov). Ked si heslo zmeni na jednom mieste,
tak bude zmenene globalne.<br>
<br>
AUTORIZACIA<br>
<br>
Riesenie musi umoznovat urcovat, <u><b>kto sa moze kam prihlasit a
tiez ake opravnenia tam ma mat</b></u> (v praxi moze byt viacero roli:
guest, user, operator, manager, admin, security, .... ja sa vo vyklade
obmedzim na 2 kategorie: bud je niekto admin, alebo nie, hoci samotny
protokol RADIUS umoznuje mat 16 stupnov opravneni).<br>
<br>
ACCOUNTING<br>
<br>
<u><b>Sledovanim kto, kedy a kam sa prihlasoval</b></u>, sa na tomto
mieste zaoberat
nebudem, avsak RADIUS umoznuje aj toto.<br>
<br>
BEZPECNOST<br>
<br>
V pripade <u><b>nedostupnosti RADIUS servera</b></u> nesmie byt
znemozneny pristup k zariadeniam, preto aj nadalej musi existovat
lokalna autentifikacia (napr. defaultnymi, resp. vopred dohodnutymi
heslami), avsak v jej pripade je mensia potreba silnych a casto
menenych hesiel, kedze v pripade dostupnosti RADIUS servera (co by malo
byt v 99,9% pripadov) je lokalna autentifikacia zakazana a samozrejme
firewallom je obmedzeny pristup k zariadeniam len z niektorych IP
adries.<br>
<br>
OSNOVA:<br>
1. Komentovane nastavenie freeRADIUS servera<br>
2. Komentovane nastavenie RADIUS klienta na linuxovom pocitaci.<br>
3. Komentovane nastavenie RADIUS klienta v manazovatelnom aktivnom
prvku.<br>
<br>
<b>1. freeRADIUS server (<a class="moz-txt-link-freetext"
href="http://www.freeradius.org/">http://www.freeradius.org/</a>)</b><br>
<br>
Konfiguracia zavisi od roznych parametrov, napr. loginy a hesla tychto
adminov mozu byt ulozene
lokalne (<tt>/etc/shadow</tt>, resp. v
konfigurakoch freeRADIUS), alebo v LDAP ci SQL databaze. Server moze
byt jeden, alebo viacero failoverovanych. Ja budem demonstrovat na
jednom serveri s lokalnym prihlasovanim, pretoze to mam vyskusane, a
mozno to pripadne vyuzit ako odrazovy mostik pre zlozitejsie poziadavky.<br>
<br>
Predpokladajme, ze freeRADIUS je nainstalovany. Konfiguraky byvaju
najcastejsie
v <tt>/usr/local/etc/raddb/</tt>, alebo v <tt>/etc/raddb/</tt>.<br>
<br>
Pre zakladnu konfiguraciu su podstatne tieto subory:<br>
radiusd.conf - globalna konfiguracia + odkazy na nizsie uvedene
konf. subory<br>
clients.conf - nastavenie IP adries a rozsahov, z ktorych budu
komunikovat RADIUS klienti + nastavenie secret key a i.<br>
users - nastavenie pouzivatelov a ich parametrov (napr. kde najst
heslo pre overenie, stupen opravneni, huntgroup, ...)<br>
huntgroups - urcovanie "administrativnych domen" na zaklade IP
adries RADIUS klientov<br>
<br>
Tento RADIUS server mozeme ovladat napr. takto: <tt>/etc/init.d/radiusd
start | restart | stop | status</tt>.<br>
<br>
<b>1.1 clients.conf<br>
<br>
</b><tt>client 192.168.0.0/24 {<br>
secret = <secret_key1><br>
shortname = sietAB<br>
}<b><br>
<br>
</b>client ... {<br>
...<br>
}<b><br>
</b></tt><br>
<b>1.2 users</b><br>
<br>
<tt>peto Auth-Type := System, Huntgroup-Name == "<font
color="#33cc00"><b>firmaA</b></font>"<br>
Service-Type = <font color="#3333ff"><b>Administrative</b></font>-User<br>
<br>
jano Auth-Type := System, Huntgroup-Name == "</tt><tt><font
color="#33cc00"><b>firmaA</b></font></tt><tt>"<br>
Service-Type = <font color="#3333ff"><b>Administrative</b></font>-User<br>
<br>
jano Auth-Type := System, Huntgroup-Name == "<font
color="#cc0000"><b>firmaB</b></font>"<br>
Service-Type = <font color="#3333ff"><b>Administrative</b></font>-User<br>
<br>
laco Auth-Type := System, Huntgroup-Name == "</tt><tt><font
color="#cc0000"><b>firmaB</b></font></tt><tt>"<br>
Service-Type = <font color="#3333ff"><b>Administrative</b></font>-User<br>
<br>
Atechnik Auth-Type := System, Huntgroup-Name == "</tt><tt><font
color="#33cc00"><b>firmaA</b></font></tt><tt>"<br>
Service-Type = <font color="#ff0000"><b>Login</b></font>-User<br>
<br>
Btechnik1 Auth-Type := System, Huntgroup-Name == "</tt><tt><font
color="#cc0000"><b>firmaB</b></font></tt><tt>"<br>
Service-Type = <font color="#ff0000"><b>Login</b></font>-User<br>
<br>
Btechnik2 Auth-Type := Local, Password == "wolfenstein",
Huntgroup-Name == "</tt><tt><font color="#cc0000"><b>firmaB</b></font></tt><tt>"<br>
Service-Type = <font color="#ff0000"><b>Login</b></font>-User<br>
<br>
"$enab15$" Auth-Type := Local, Password == "spearof",
Huntgroup-Name == "</tt><tt><font color="#33cc00"><b>firmaA</b></font></tt><tt>"<br>
"$enab15$" Auth-Type := Local, Password == "destiny",
Huntgroup-Name == "</tt><tt><font color="#cc0000"><b>firmaB</b></font></tt><tt>"<br>
<br>
</tt><br>
<small><small><i><big>Rozlisovanie medzi Administrative-User a
Login-User ma vyznam pri manazovatelnych aktivnych prvkoch - napr.
Cisco, SMC Networks, ... Rozdiel je ten, ze Administrative-User bude
hned po prihlaseni v enable mode (testovane na SMC6824M a SMC8612XL3...
v pripade Cisco switchov sa zvykne v konfiguraku users uvadzat
direktiva Cisco-AVPair = "shell:priv-lvl=<font color="#ff0000"><b>X</b></font>",
kde X z intervalu 0 az 15 urcuje uroven opravnenia).<br>
<br>
Jano je uvadzany 2x, pretoze pracuje pre obe firmy. Kazda firma ma ine
"enable" password k manazovatelnym aktivnym prvkom.</big><br>
</i></small></small><br>
<b>1.3 huntgroups<br>
<tt><br>
</tt></b><tt># linuxove servery a manazovatelne switche firmy A<br>
firmaA NAS-IP-Address == "192.168.0.10"<br>
firmaA NAS-IP-Address == "192.168.0.11"<br>
firmaA NAS-IP-Address == "192.168.0.12"<br>
firmaA NAS-IP-Address == "192.168.0.13"<br>
<br>
# linuxove servery a manazovatelne switche firmy B<br>
firmaB NAS-IP-Address == "192.168.0.20"<br>
firmaB NAS-IP-Address == "192.168.0.21"<br>
firmaB NAS-IP-Address == "192.168.0.22"<br>
firmaB NAS-IP-Address == "192.168.0.23"</tt>
<br>
<br>
Ucinok vyssieuvedenych nastaveni bude ten, ze Peto, Jano a Atechnik sa
budu moct prihlasovat na zariadenia firmy A, a Jano, Laco, Btechnik1 a
Btechnik2 na zariadenia firmy B. Na spominanych manazovatelnych
aktivnych prvkoch budu mat Peto, Jano a Laco defaultne administratorsky
(enable) pristup, technici operatorsky (disable).<br>
<br>
<b>2. PAM & sudoers</b><br>
<br>
Podla mojej skusenosti je nutnou podmienkou vyuzitia RADIUS
autentifikacie pri prihlasovani sa na linuxovy stroj je existencia
accountu s rovnakym loginom ako na RADIUS serveri, resp. aj existencia
jeho home directory na pocitaci, na ktory sa prihlasuje. Cize
jednoduche '<tt>mkdir /home/<user></tt>' a nasledne '<tt>useradd
<user></tt>' to riesi. Pokial sa nam jedna aj o prihlasovanie cez
SSH (z povolenych IP adries), tak dotycny <tt><user></tt> musi
byt aj povoleny v <tt>sshd_config</tt>.<br>
<br>
Dalej je potrebne nainstalovat toto:
<a class="moz-txt-link-freetext"
href="http://www.freeradius.org/pam_radius_auth/">http://www.freeradius.org/pam_radius_auth/</a>.
Instalacia je easy: po
rozbaleni staci skompilovat prikazom make a skopirovat vzniknuty <tt>pam_radius_auth.so</tt>
k ostatnym PAM modulom do <tt>/lib/security/</tt>. (PAM = Pluggable
Authentication Module)<br>
<br>
A teraz nasleduje cast specificka pre vyssie uvedenu pripadovu studiu:
konfiguracie v <tt>/etc/pam.d/</tt>. Nasledovne bolo skusane v Gentoo
a neviem vylucit, ci v inych distribuciach nie su syntakticke
odlisnosti, principialne odlisnosti by sa vsak vyskytovat nemali.<br>
<tt><br>
<b>/etc/pam.d/system-auth</b><br>
<br>
# primarne sa autentifikuje voci RADIUS<br>
auth sufficient pam_radius_auth.so
conf=/etc/raddb/pam_radius_auth.conf<br>
<br>
# ak RADIUS autentifikacia zlyha, autentifikuje sa predtym zadanym
heslom voci lokalnemu /etc/shadow<br>
# ak zlyha, prompt pre zadanie UNIX (SYSTEM) passwordu (neplati pre
ssh, passwd ani su)<br>
auth sufficient pam_unix.so try_first_pass likeauth nullok<br>
<br>
# permission denied<br>
auth required pam_deny.so</tt><br>
<br>
<tt><b>/etc/pam.d/su</b><br>
<br>
# iba root moze pouzit su, ine direktivy zacinajuce 'auth', nez tato, v
konfiguraku nie su:<br>
auth sufficient pam_rootok.so<br>
<br>
</tt><tt><b>/etc/pam.d/sshd</b></tt><br>
<tt><br>
# cez ssh je umoznene prihlasovanie len cez RADIUS, lokalne nie,
pretoze ine direktivy 'auth' nie su<br>
auth sufficient pam_radius_auth.so
conf=/etc/raddb/pam_radius_auth.conf<br>
<br>
<b>/etc/pam.d/passwd a </b></tt><tt><b>/etc/pam.d/chpasswd</b></tt><tt><br>
<br>
# zakaz menit defaultne, resp. vopred dohodnute lokalne hesla kymkolvek
(v pripade nutnosti zmeny to root moze docasne odstavit)<br>
password required pam_deny.so<br>
<br>
<b>/etc/raddb/pam_radius_auth.conf</b><br>
<br>
<IPadresa_RADIUSservera> <secret_key1>
<timeout_sec><br>
# ...<br>
127.0.0.1 <secret_key2>
<timeout_sec><br>
</tt><br>
Otazkou bolo, ako zabezpecit, aby boli <u><b>lokalne hesla testovane
IBA vtedy, ak je RADIUS server nedostupny</b></u>, a nie aj vtedy, ked
napr. pouzivatel zada nespravne heslo. Pouzila sa na to vyssieuvedena
finta s localhostom, na ktorom bezi dalsi - lokalny RADIUS server,
ktoreho ulohou je prihlasit pouzivatela dohodnutym lokalnym heslom, ked
je RADIUS server nedostupny. Len s pomocou konfiguracie PAM modulov v
<tt>/etc/pam.d/</tt> sa to riesit neda, pretoze tie nerozlisuju dovod,
pre ktory
autentifikacia predchadzajuceho modulu zlyhala. Konfiguracia lokalneho
RADIUS servera (ktory sa pri takomto rieseni z bezpecnostnych dovodov
vyzaduje na kazdom klientovi, ktory sa ma autentifikovat voci
vzdialenemu RADIUSu), je nasledovna:<br>
<br>
<tt><b>clients.conf</b><br>
<br>
client 127.0.0.1 {<br>
#<br>
# The shared secret use to "encrypt" and "sign" packets between<br>
# the NAS and FreeRADIUS. You MUST change this secret from the<br>
# default, otherwise it's not a secret any more!<br>
#<br>
# The secret can be any string, up to 32 characters in length.<br>
#<br>
secret = <secret_key2><br>
#<br>
# The short name is used as an alias for the fully qualified<br>
# domain name, or the IP address.<br>
#<br>
shortname = <shortname><br>
nastype = other # localhost isn't usually a NAS...<br>
}<br>
<br>
<b>users</b><br>
<br>
DEFAULT Auth-Type := System<br>
Service-Type = Login-User<br>
<br>
</tt>Ako vidime, v pripade SSH su znemoznene ine typy autentifikacie,
nez RADIUS. Riziko, ze zlyha vzdialeny a aj lokalny zalozny RADIUS
klient, je sice male, ale nie je vylucene. Preto sa toto obmedzenie
tyka len SSH - v pripade inych prihlasovani (napr. cez lokalnu konzolu)
sa v pripade zlyhania oboch RADIUSov skusa aj pam_unix (<tt>/etc/shadow</tt>).<br>
<br>
Zmenu hesla na RADIUS serveri (<tt>/etc/shadow</tt>) z RADIUS klienta
sa mi zatial nepodarilo urobit, ak s tym ma dakto skusenost, budem rad,
ked poradi.<br>
<br>
A najdolezitejsi prvok autorizacie - kto moze bez hesla vykonat '<tt>sudo
su root</tt>', to stanovime v <tt>/etc/sudoers</tt> prikazom <tt>visudo</tt>,
napr.:<br>
<br>
<tt>laco ALL=(root) NOPASSWD: /bin/su root<br>
<br>
</tt>Vysledok tohto celeho je okrem ineho aj to, ze nikto uz nebude
potrebovat vediet rootovske heslo, nakolko autorizacia je v tejto
pripadovej studii riesena tak, ze jeho selektivna znalost nie je
potrebna, a v pripade ze zakomentujeme vsetky riadky v <tt>/etc/securetty</tt>,
tak pri danej konfiguracii ani prakticky pouzitelna.<br>
<br>
Ceresnicka na torte pridana do <tt>/etc/profile</tt>:<br>
<br>
<tt>alias enable="sudo su root"</tt> ;)<br>
<br>
<b>3. nastavenie RADIUS klienta na manazovatelnych aktivnych prvkoch
siete</b><br>
<br>
Na rozdiel od vyssie popisaneho linuxoveho RADIUS klienta, u ktoreho sa
na RADIUS serveri riesi kompletna autentifikacia a vacsina autorizacie,
u pocetnejsich "hlupejsich" zariadeni je vhodnejsie nastavovat vsetko
na serveri. Tento pristup ma svoje vyhody aj nevyhody, hlavne vsak je,
ze nespravnymi pristupovymi pravami na linuxe sa da napachat viac skod,
ako na takomto zariadeni, preto je tato odlisnost logicka.<br>
<br>
V globalnom konfiguracnom rezime SMC6824M:<br>
<tt><br>
authentication login RADIUS local<br>
authentication enable RADIUS local<br>
<br>
</tt><tt>RADIUS-server 1 host <IPadresa_RADIUSservera> status
enable auth-port 1812 acct-port 1813 timeout 5 retransmit 2 key
<secret_key1><br>
RADIUS-server 2 host <IPadr_zaloznehoRADserv> status enable
auth-port 1812 acct-port 1813 timeout 5 retransmit 2 key
<secret_keyX><br>
</tt><br>
Ucinok je ten, ze <u><b>ako prva sa testuje RADIUS
autentifikacia/autorizacia
a LEN v pripade nedostupnosti vsetkych specifikovanych RADIUS serverov</b></u>
prichadza na rad autentifikacia/autorizacia lokalna, co neplati v
pripade zadania nespravnych prihlasovacich udajov. A to plati tak pre
primarne prihlasenie, ako aj pre vstup do "enable" rezimu.<br>
<br>
V pripade SMC8612XL3, SMC6724AL2, SMC6248M, SMC6224M a inych
manazovatelnych aktivnych prvkov nielen od SMC Networks je syntax
podobna.<br>
<br>
Narozdiel od linuxovych pocitacov, username z RADIUS servera nemusi
byt vytvarane aj na sietovom zariadeni, a jeho filesystem tiez
neumoznuje ziadne domovske priecinky, takze netreba vytvarat ani tie. V
pripade tychto zariadeni sa mi tiez nepodarilo take nastavenie, ktore
by umoznovalo niektorym userom "enable" bez hesla, a inym userom
"enable" znemoznovalo, preto som vo vyssie uvedenom konfiguraku
freeRADIUS zaviedol tzv. "enable domeny" (realizovane cez huntgroups),
v ramci ktorych su nastavene rozne enable hesla, zname v danej domene
len tym, ktori v ramci nej enable pristup nevyhnutne potrebuju.<br>
<br>
<b>ZAVER</b><br>
<br>
Verim, ze tento prispevok niekomu posluzi a pripadne ak sa v niecom
mylim, alebo neuvadzam najvhodnejsie riesenia, tak dufam, ze ma niekto
opravi. Tiez dufam, ze tento prispevok nebol prilis zlozity, cim by
mohol odradit pripadnych nasadzovatelov takychto rieseni - v
skutocnosti su tie veci ovela jednoduchsie, ked do nich clovek
prenikne, nez sa to moze zdat na prvy pohlad.<br>
<br>
S pozdravom,<br>
<pre class="moz-signature" cols="72">--
Jan Ostrochovsky, technicky spravca IIKS
Areal v Karlovej Vsi Univerzity Komenskeho
telefon: +421 2 602 99 251, SIP: 11801 (v ramci UK)
</pre>
</body>
</html>