[linux] pam_radius_auth & freeRADIUS
Jan Ostrochovsky
ostrochovsky na rec.uniba.sk
Pondělí Březen 20 22:32:24 CET 2006
Mili kolegovia,
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.
*MOTIVACIA
*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.
Ak si odmyslime premakany, ale proprietarny, a preto upadajuci, Cisco
protokol TACACS+, odpoved mi pripada byt jasna - budeme rozoberat
moznosti protokolu _*RADIUS*_ 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.
*PRIPADOVA STUDIA*
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).
AUTENTIFIKACIA
Kazdy z nasich adminov a technikov chce mat _*jediny username a
password*_, 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.
AUTORIZACIA
Riesenie musi umoznovat urcovat, _*kto sa moze kam prihlasit a tiez ake
opravnenia tam ma mat*_ (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).
ACCOUNTING
_*Sledovanim kto, kedy a kam sa prihlasoval*_, sa na tomto mieste
zaoberat nebudem, avsak RADIUS umoznuje aj toto.
BEZPECNOST
V pripade _*nedostupnosti RADIUS servera*_ 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.
OSNOVA:
1. Komentovane nastavenie freeRADIUS servera
2. Komentovane nastavenie RADIUS klienta na linuxovom pocitaci.
3. Komentovane nastavenie RADIUS klienta v manazovatelnom aktivnom prvku.
*1. freeRADIUS server (http://www.freeradius.org/)*
Konfiguracia zavisi od roznych parametrov, napr. loginy a hesla tychto
adminov mozu byt ulozene lokalne (/etc/shadow, 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.
Predpokladajme, ze freeRADIUS je nainstalovany. Konfiguraky byvaju
najcastejsie v /usr/local/etc/raddb/, alebo v /etc/raddb/.
Pre zakladnu konfiguraciu su podstatne tieto subory:
radiusd.conf - globalna konfiguracia + odkazy na nizsie uvedene
konf. subory
clients.conf - nastavenie IP adries a rozsahov, z ktorych budu
komunikovat RADIUS klienti + nastavenie secret key a i.
users - nastavenie pouzivatelov a ich parametrov (napr. kde najst
heslo pre overenie, stupen opravneni, huntgroup, ...)
huntgroups - urcovanie "administrativnych domen" na zaklade IP
adries RADIUS klientov
Tento RADIUS server mozeme ovladat napr. takto: /etc/init.d/radiusd
start | restart | stop | status.
*1.1 clients.conf
*client 192.168.0.0/24 {
secret = <secret_key1>
shortname = sietAB
}*
*client ... {
...
}*
*
*1.2 users*
peto Auth-Type := System, Huntgroup-Name == "*firmaA*"
Service-Type = *Administrative*-User
jano Auth-Type := System, Huntgroup-Name == "*firmaA*"
Service-Type = *Administrative*-User
jano Auth-Type := System, Huntgroup-Name == "*firmaB*"
Service-Type = *Administrative*-User
laco Auth-Type := System, Huntgroup-Name == "*firmaB*"
Service-Type = *Administrative*-User
Atechnik Auth-Type := System, Huntgroup-Name == "*firmaA*"
Service-Type = *Login*-User
Btechnik1 Auth-Type := System, Huntgroup-Name == "*firmaB*"
Service-Type = *Login*-User
Btechnik2 Auth-Type := Local, Password == "wolfenstein",
Huntgroup-Name == "*firmaB*"
Service-Type = *Login*-User
"$enab15$" Auth-Type := Local, Password == "spearof",
Huntgroup-Name == "*firmaA*"
"$enab15$" Auth-Type := Local, Password == "destiny",
Huntgroup-Name == "*firmaB*"
/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=*X*", kde X z intervalu 0 az 15 urcuje uroven opravnenia).
Jano je uvadzany 2x, pretoze pracuje pre obe firmy. Kazda firma ma ine
"enable" password k manazovatelnym aktivnym prvkom.
/
*1.3 huntgroups
*# linuxove servery a manazovatelne switche firmy A
firmaA NAS-IP-Address == "192.168.0.10"
firmaA NAS-IP-Address == "192.168.0.11"
firmaA NAS-IP-Address == "192.168.0.12"
firmaA NAS-IP-Address == "192.168.0.13"
# linuxove servery a manazovatelne switche firmy B
firmaB NAS-IP-Address == "192.168.0.20"
firmaB NAS-IP-Address == "192.168.0.21"
firmaB NAS-IP-Address == "192.168.0.22"
firmaB NAS-IP-Address == "192.168.0.23"
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).
*2. PAM & sudoers*
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
'mkdir /home/<user>' a nasledne 'useradd <user>' to riesi. Pokial sa nam
jedna aj o prihlasovanie cez SSH (z povolenych IP adries), tak dotycny
<user> musi byt aj povoleny v sshd_config.
Dalej je potrebne nainstalovat toto:
http://www.freeradius.org/pam_radius_auth/. Instalacia je easy: po
rozbaleni staci skompilovat prikazom make a skopirovat vzniknuty
pam_radius_auth.so k ostatnym PAM modulom do /lib/security/. (PAM =
Pluggable Authentication Module)
A teraz nasleduje cast specificka pre vyssie uvedenu pripadovu studiu:
konfiguracie v /etc/pam.d/. Nasledovne bolo skusane v Gentoo a neviem
vylucit, ci v inych distribuciach nie su syntakticke odlisnosti,
principialne odlisnosti by sa vsak vyskytovat nemali.
*/etc/pam.d/system-auth*
# primarne sa autentifikuje voci RADIUS
auth sufficient pam_radius_auth.so
conf=/etc/raddb/pam_radius_auth.conf
# ak RADIUS autentifikacia zlyha, autentifikuje sa predtym zadanym
heslom voci lokalnemu /etc/shadow
# ak zlyha, prompt pre zadanie UNIX (SYSTEM) passwordu (neplati pre ssh,
passwd ani su)
auth sufficient pam_unix.so try_first_pass likeauth nullok
# permission denied
auth required pam_deny.so
*/etc/pam.d/su*
# iba root moze pouzit su, ine direktivy zacinajuce 'auth', nez tato, v
konfiguraku nie su:
auth sufficient pam_rootok.so
*/etc/pam.d/sshd*
# cez ssh je umoznene prihlasovanie len cez RADIUS, lokalne nie, pretoze
ine direktivy 'auth' nie su
auth sufficient pam_radius_auth.so
conf=/etc/raddb/pam_radius_auth.conf
*/etc/pam.d/passwd a **/etc/pam.d/chpasswd*
# zakaz menit defaultne, resp. vopred dohodnute lokalne hesla kymkolvek
(v pripade nutnosti zmeny to root moze docasne odstavit)
password required pam_deny.so
*/etc/raddb/pam_radius_auth.conf*
<IPadresa_RADIUSservera> <secret_key1> <timeout_sec>
# ...
127.0.0.1 <secret_key2> <timeout_sec>
Otazkou bolo, ako zabezpecit, aby boli _*lokalne hesla testovane IBA
vtedy, ak je RADIUS server nedostupny*_, 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
/etc/pam.d/ 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:
*clients.conf*
client 127.0.0.1 {
#
# The shared secret use to "encrypt" and "sign" packets between
# the NAS and FreeRADIUS. You MUST change this secret from the
# default, otherwise it's not a secret any more!
#
# The secret can be any string, up to 32 characters in length.
#
secret = <secret_key2>
#
# The short name is used as an alias for the fully qualified
# domain name, or the IP address.
#
shortname = <shortname>
nastype = other # localhost isn't usually a NAS...
}
*users*
DEFAULT Auth-Type := System
Service-Type = Login-User
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 (/etc/shadow).
Zmenu hesla na RADIUS serveri (/etc/shadow) z RADIUS klienta sa mi
zatial nepodarilo urobit, ak s tym ma dakto skusenost, budem rad, ked
poradi.
A najdolezitejsi prvok autorizacie - kto moze bez hesla vykonat 'sudo su
root', to stanovime v /etc/sudoers prikazom visudo, napr.:
laco ALL=(root) NOPASSWD: /bin/su root
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 /etc/securetty,
tak pri danej konfiguracii ani prakticky pouzitelna.
Ceresnicka na torte pridana do /etc/profile:
alias enable="sudo su root" ;)
*3. nastavenie RADIUS klienta na manazovatelnych aktivnych prvkoch siete*
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.
V globalnom konfiguracnom rezime SMC6824M:
authentication login RADIUS local
authentication enable RADIUS local
RADIUS-server 1 host <IPadresa_RADIUSservera> status enable auth-port
1812 acct-port 1813 timeout 5 retransmit 2 key <secret_key1>
RADIUS-server 2 host <IPadr_zaloznehoRADserv> status enable auth-port
1812 acct-port 1813 timeout 5 retransmit 2 key <secret_keyX>
Ucinok je ten, ze _*ako prva sa testuje RADIUS
autentifikacia/autorizacia a LEN v pripade nedostupnosti vsetkych
specifikovanych RADIUS serverov*_ 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.
V pripade SMC8612XL3, SMC6724AL2, SMC6248M, SMC6224M a inych
manazovatelnych aktivnych prvkov nielen od SMC Networks je syntax podobna.
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.
*ZAVER*
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.
S pozdravom,
--
Jan Ostrochovsky, technicky spravca IIKS
Areal v Karlovej Vsi Univerzity Komenskeho
telefon: +421 2 602 99 251, SIP: 11801 (v ramci UK)
------------- dal¹í èást ---------------
HTML p?íloha byla odstran?na...
URL: http://lists.linux.sk/pipermail/linux/attachments/20060320/60b6529c/attachment.html
Další informace o konferenci linux