cs:spravce:monitoring:ermon2

Toto je starší verze dokumentu!


Dokumentace k implementaci noveho ermona

Většina testů se provádí na hostname RADIUSu. Některý by ale měly lepší smysl dělat na realm / respektive instituci, například to že dodali institution.xml.

TODO: Co s IPv6? Na národním RADIUSu ji nechci protože se pak musí řešit dvoje problém. Jenže server na kterém ermon běží ji má (a chci aby měl). Uhlídáme všecny tooly že komunikují po IPv4 a nebo při vyčítání RADIUSů z LDAPu

TODO: Řada testů RADSEC, IPSEC, … používá předání parametrů pomocí nrpe, to je nebezpečné (stačí za parametry dát ; a pak spustí další příkazy). V debianu je nrpe s parametry defautně zakázané, provozujeme nějakou mojí upravenou verzi kde jsem to povolil, chci se tohle zbavit. Má icinga nějaké bezpečnější řešení předávání parametrů? Pokud ano, dokáže to po dobu vývoje nového ermonu koexistovat se stávajícím nrpe na národním RADIUSu?

Zdroje dat o objektech pro Icingu

RADIUS servery jsou to o kolo čeho se vše točí.

Realmy představují instituci připojenou k eduroamu.

Admini jsou zodpovědni za Realm nebo RADIUS server.

RADIUS servery

Jsou evidovány v LDAPu

??baseDN

:: ou=Radius Servers,o=eduroam,o=apps,dc=cesnet,dc=cz !!

??filter

:: (!(radiusDisabled=true)) !!

??cn

::hostname RADIUS serveru !!

??eduroamInfTransport

::RADSEC anebo IPSEC !!

??eduroamMonRadiusSecret

:: sdílené tajemství pro komunikaci na UDP/1812 při testování RADIUS protokolem !!

??manager

:: více hodnotové pole odkazující na entry adminů. !!

Realmy

Jsou evidovány v LDAPu.

??baseDN

:: ou=Realms,o=eduroam,o=apps,dc=cesnet,dc=cz !!

??filter

:: (!(eduroamConnectionStatus=disconnected)) tj. ti co nebyli odpojeni !!

??cn

:: vícehodnotové pole obsahující všechny realmy příslušící jedné organizaci (např. cesnet.cz, cesnet.eu a guest.cesnet.cz). !!

??eduroamTestingID

:: uživatelské jméno testovacího uživatele obvykle asi s realmem který je RDN tohoto záznamu

tohle může být nedefinováno pro instituce co se připojují a zatím nedodali a nebo jsou SP only !!

??eduroamTestingPassword

:: heslo k testovacímu účtu !!

??eduroamMemberType

:: typ připojení IdPSP, SP, IdP !!

??eduroamConnectionStatus

:: stav připojení connected, in-process, disconected !!

??labeledURI

:: odkaz na XML dokumnet s informacemi o pokrytí !!

??manager

:: více hodnotové pole odkazující na entry adminů, trochu pitomé je že to mohou být jiní lidé než ti u realmu !!

Admini

Jsou evidovány v LDAPu.

??baseDN

:: o=eduroam,o=apps,dc=cesnet,dc=cz !!

??filter

:: (&(manager=*)(|(objectClass=eduRoamRealm)(objectClass=eduRoamRadius))) !!

Narozdíl od Serverů a Realmů tady nedostáváme přímo entry admina ale pouze její DN v attributu manager.

Následně se provede čtení dotyčné entry a tím se zjistí potřebné informace.

??uid

:: uživatelské jméno pro admina v CESNETím LDAPu, ePPN se pak tvoří jako <uid>@cesnet.cz.

??mail

:: email admina, pokud jich je víc, tak se bere ten první. CESNETí LDAP má sice položku prefferedMail, ale plánujem přechod na Peruna který má jen jediný preferovaný mail který cpe právě do atributu mail, takže pro zjednodušení budeme pracovat jen s ním.

??cn

:: jméno admina, pracuje vůbec Icinga se jménem? Nagiosu to bylo buřt.

??eduPersonPrincipalName

:: pouze u entry z podstromu ou=People,o=eduroam,o=apps,dc=cesnet,dc=cz jsou te ePPN které mají spojeny v Perunu.

Pro účely řízení práv bude třeba aby dotyčnému objektu měli přístup všichni kteří se přihlásí pomocí některého z eduPersonPrincipalName a nebo <uid>@cesnet.cz. !!

Možná bude možné si tuhle komplikaci zjednodušit tím že nový ermon schováme za proxyIdP. Tím bychom dostali vždy jen jedno jedné ePPN. Když bychom se vykašlali na nějaké přechodné období, tak bychom si taky mohli zjednodušit vyhledávaní uživatelů takto:

??baseDN

:: ou=People,o=eduroam,o=apps,dc=cesnet,dc=cz

??filter

:: (&(entryStatus=active)(objectClass=eduroamAdmin)) !!

A všechna data o uživatelích by byla okamžitě k dispozici, trochu to degraduje na praci s LDAPem jako SQL, ale přijde mi že by to za to stálo.

Podle této zjednodušené logiky by pak eduroam admini ze stávajícího LDAPu dolováni takto (není to uplně přesné, stává se mi že admina zapomenu přidat do skupiny):

??baseDN

:: ou=People,dc=cesnet,dc=cz !!

??filter

:: (&(entryStatus=active)(memberOf=cn=eduroam admins,ou=groups,dc=cesnet,dc=cz)) !!

Zastarala dokumentace k migraci na Peruna ktera nebrala v potaz proxyIdP.

TODO OBA: Prodiskutovat to a rozhodnout se.

Prováděné testy

PING

Test jestli je RADIUS server dosažitelný, pingá se na hostname které se získá z cn pomoci IPv4. Ping se sleduje na všech evidovaných RADIUS serverech bez ohledu na jejich roli.

??LDAP filter

::(!(radiusDisabled=true))

??závislosti

:: ne

??notifikace

:: ANO, 960 (u,c,r)

??RW oprávnění

:: admini serveru

??frekvence testů [běžný, fail, HARD]

:: 5min, 1min, 10x !!

IPSEC

Test jestli má RADIUS navázané IPSec spojení na národní RADIUS, má smysl pouze u těch RADIUS serverů které jsou infrastrukturní a jsou připojeny pomocí IPSec.

??LDAP filter

:: (&(!(radiusDisabled=true))(eduroamInfTransport=IPSEC))

??závislosti

:: PING

??notifikace

:: ANO, 960 (u,c,r)

??RW oprávnění

:: admini serveru

??frekvence testů [běžný, fail, HARD]

:: 5min, 1min, 10x

!!

Test je realizovan na národním RADIUSu, pomocí parametrizovaného pingu kterému se předává IPčko serveru na který se má pingnout, když pingnout jde tak se předpokládá že je sestaven IPSec. Předpkládá se že národní RADIUS má v kernelu politiky které znemožnují pingnout bez sestaveného tunelu. Důkladnější by bylo kontrolovat že je dohodnuté SA a následně pingnout, ale nemyslím že je třeba to dále komplikovat.

command[check_ping]=/usr/local/bin/check_ping -H $ARG1$ -w $ARG2$ -c $ARG3$ -p 5

RADSEC

Test zda má RADIUS navázané RadSec spojení na národní RADIUS, má smysl pouze u těch RADIUS serverů které jsou infrastrukturní a jsou připojeny pomocí RadSec.

??LDAP filter

:: (&(!(radiusDisabled=true))(eduroamInfTransport=RADSEC))

??závislosti

:: PING

??notifikace

:: ANO, 960 (u,c,r)

??RW oprávnění

:: admini serveru

??frekvence testů [běžný, fail, HARD]

:: 5min, 1min, 10x

!!

Test je realizovan na národním RADIUSu, tak že se v navazaných spojeních hledají ta která odpovídají IP adrese testovaného serveru. Pro server který pracuje v roli IdP+SP musí být navázáno alespoň jedno spojení k serveru a jedno od serveru ktery je v SP modu. IdP v soucasnosti vubec neumime.

Problem je s tim jak FR aktivne zavira spojeni, takze kdyz poklesne aktivita ermonu tak muze i falesne hlasit ze radsec spojeni neni v poradku navazano. Tohle by chtelo nejak vyresit. Ale nenapada me zadne snadne reseni, asi napsat neco sofistikovanejsiho a drzet si informaci ze posledni hodinu ci dve bylo nejaky spojeni navazano a tak to povazovat za OK? Nebo si proste vynutit navazani spojeni? To se mi asi libi vic. Ale …

command[check_radsec]=/usr/local/bin/check_radsec.pl -H $ARG1$
command[check_radsec_SP]=/usr/local/bin/check_radsec.pl -H $ARG1$ --SPonly

Domácí realm

Realm který RADIUS server obsluhuje. Domácí realmy jsou odkazovány v entry RADIUS serveru přes atribut eduroamMonRealm. Na jednom serveru muze byt monitorovano vice nez jeden

??LDAP filter

:: (&(!(radiusDisabled=true))(eduroamMonRealm=*))

??závislosti

:: (PING @ $mon_server)

??notifikace

:: ANO, 960 (w,u,c,r)

??RW oprávnění

:: admini realmu a admini serveru

??frekvence testů [běžný, fail, HARD]

:: 5min, 10min, 3x

!!

Test se provádí pomocí rad_eap_test, ten závisí na eapol_test z wpa_supplicantu (potřeba přeložit, není v distribuci. Pro zavolání testu je potřeba: IP/hostname, sdílené tajemství, testovací účet (jméno heslo); to vše lze vylovit z LDAPu.

TODO: Je třeba zajistit že v se nikdy nepoběží současně dva testy s tím samým uživatelským jménem a CSI (volba -M), do té podmínky patří i různé timeouty. Viz vlákno „Randomizace MAC adresy testu z ermon.cesnet.cz?“ v eduroam-admin.

Realmy ostatních organizací, testujeme všechny co známe.

??LDAP filter

:: (&(!(radiusDisabled=true))(eduroamMonRealm=*))

??závislosti

:: ( (RADSEC|IPSEC) @ $server) & ($visit_realm @ $homeservers)

??notifikace

:: NE

??RW oprávnění

:: admini serveru a admini realmu

??frekvence testů [běžný, fail, HARD]

:: 180min, 120min, 3x !!

Platí totéž o CSI jako u domácích realmů.

VISITORS / Agregované realmy

Nový test. Jde o to vytvořit nějaký test který bude informovat že na instituci mají návštěvníci problém. Potíž spočívá v tom že vždy existuje několik realmů které na serveru nefungují. Pěkné by bylo když by 80% - OK, 70% - WARNING a méně critical.

??LDAP filter

:: (&(!(radiusDisabled=true))(eduroamMonRealm=*))

??závislosti

:: ( (RADSEC|IPSEC) @ $server) & ($realm @ $server)

??notifikace

:: ANO, 960 (w,u,c,r)

??RW oprávnění

:: admini serveru

??frekvence testů [běžný, fail, HARD]

:: ??min, ??min, ??x - odvodit podle náročnosti & dopadu na infrastrukturu !!

BIG-PACKET

Test přenosu velkého paketu - sem tam se objevují instituce které zahazují fragmentované UDP pakety. Test je udělán tak, že na každém RADIUS serveru se testuje pomocí uživatele big-test@cesnet.cz, ten v access-accept odpovědi pošle vycpávky v podobě Reply-Message tak aby to zaručeně přeteklo 1500B.

Otázka je jestli je třeba to zachovávat, býval to problém v době kdy všichni jeli přes IPSec. Může to být problém v zahraničí když to tam ještě jede po UDP, to netestujem. Může to být problém mezi RADIUSem a AP na instituci (ale pokud se dobře pamatuji, tak většinou dělal problém nějaký hraniční FW pro nějž bylo snazší fragmentované pakety zahazovat.

Tak jak je test udělán testujeme cestu buď národní RADIUS → RADIUS instituce → AP (pokud jedou IPsec) a nebo RADIUS instituce → AP (pokud jedou RADSEC) tj. směr odpovědi od CENSETího RADIUSu. A potom směr RADIUS instituce → ermon pro odpověď která místo k AP putuje na ermon, což se dá považovat za test schopnosti odeslat fragmentovaný paket přes velkou část Internetu.

??LDAP filter

:: (&(!(radiusDisabled=true))(eduroamMonRealm=*))

??závislosti

:: (RADSEC|IPSEC) @ $server & (cesnet.cz @ $homeservers)

??notifikace

:: ANO, 2880 (c,r)

??RW oprávnění

:: admini serveru

??frekvence testů [běžný, fail, HARD]

:: 1440min, 720min, 3x !!

CALLING-STATION-ID

Kontrola že server posílá attribut Calling-Station-ID, týká se všech serverů (TODO SEMIK: a nebo jen těch napojených na národní RADIUS přímo?).

??LDAP filter

:: (radiusDisabled=true)

??závislosti

:: PING @ $server

??notifikace

:: ANO, 2880min (c,r)

??RW oprávnění

:: admini serveru

??frekvence testů [běžný, fail, HARD]

:: 1440min, 720min, 3x !!

Implementace na národním RADIUS serveru:

command[check_CSI]=/usr/local/bin/test-Calling-Station-Id-v2.pl -F /var/log/arch/radiator/ON_CSI.last -H $ARG1$

Další detaily u Operator-Name.

CHARGEABLE-USER-IDENTITY

Test že IdP implementuje fci Chargeable-User-Identity.

??LDAP filter

:: (&(!(radiusDisabled=true))(eduroamMonRealm=*))

??závislosti

:: $home_realm @ $server

??notifikace

:: ANO, 2880min (c,r)

??RW oprávnění

:: admini serveru

??frekvence testů [běžný, fail, HARD]

:: 2880min, 180min, 3x !!

Implementováno pomocí skriptu /usr/local/bin/test-Chargeable-User-Identity.pl který vnitřně volá rad_eap_test ale pro snazší zpracování vysledků je to napsáno v perlu.

CVE-2017-9148

Test na CVE-2017-9148, implementováno pomocí /usr/local/nagios-plugins/tls-resume-expl.

??LDAP filter

:: (&(!(radiusDisabled=true))(eduroamMonRealm=*))

??závislosti

:: $home_realm @ $server

??notifikace

:: ANO, 2880min (c,r)

??RW oprávnění

:: admini serveru

??frekvence testů [běžný, fail, HARD]

:: 2880min, 180min, 3x !!

FAKE-UID

Test jestli domácí RADIUS server vynucuje shodu vnější a vnitřní identity s vyjimkou anonymous@$realm. Testuje se pomocí anonymní identity anonXXXX@$realm a reálného testovacího účtu pro domácí realm. XXXX by mělo být proměnné aby si to některý z adminů nezjednodušil tak že začne zamítat konkrétní účet. Stávající implementace XXXX generuje náhodně při generování statické konfigurace pro nagios. TODO OBA: Zamyslet se jestli by nebylo jednodušší generovat XXXX pokaždé náhodně.

Test se provádí pomocí /usr/local/nagios-plugins/check-fake-id.

??LDAP filter

:: (&(!(radiusDisabled=true))(eduroamMonRealm=*))

??závislosti

:: $home_realm @ $server

??notifikace

:: ANO, 2880min (c,r)

??RW oprávnění

:: admini serveru

??frekvence testů [běžný, fail, HARD]

:: 2880min, 180min, 3x !!

OPERATOR-NAME

Kontrola že server posílá attribut Operator-Name, týká se všech serverů (TODO SEMIK: a nebo jen těch napojených na národní RADIUS přímo?).

??LDAP filter

:: (radiusDisabled=true)

??závislosti

:: PING @ $server

??notifikace

:: ANO, 2880min (c,r)

??RW oprávnění

:: admini serveru

??frekvence testů [běžný, fail, HARD]

:: 1440min, 720min, 3x !!

Implementace na národním RADIUS serveru:

command[check_operator_name]=/usr/local/bin/test-Operator-Name.pl -F /var/log/arch/radiator/ON_CSI.last -H $ARG1$

Soubor /var/log/arch/radiator/ON_CSI.last je vytvářen skriptem /root/scripts/scan-ON_CSI_CUI.pl který scanuje log za poslední hodinu, je spouštěn po uklizení hodinového logu skriptem /root/scripts/moveRadiatorLog.sh. Závisí to na hooku který je součástí kódu národního RADIUSu.

Chtělo by to zvážit frekvenci testů, stávající frekvence pravděpodobně vychází z toho že jsem v minulosti zkoušel parsovat log rovnou? A opakované čtení národní R. server přetěžovalo. Teď když je to podstatné vytaženo do malého souboru:

root@radius1mng5:~# ls -l /var/log/arch/radiator/ON_CSI.last
lrwxrwxrwx 1 root root 52 Apr  6 13:07 /var/log/arch/radiator/ON_CSI.last -> /var/log/arch/radiator/radiator.2018_04_06_12.ON_CSI
root@radius1mng5:~# ls -l /var/log/arch/radiator/radiator.2018_04_06_12.ON_CSI
-rw-r--r-- 1 root root 19621 Apr  6 13:07 /var/log/arch/radiator/radiator.2018_04_06_12.ON_CSI

tak pro to není důvod.

VCELKA-MAJA

Test že nedochází k přeposílání vnitřní identity. Vnější identita je vcelka-maja@tul.cz, vnitřní potom test001@cesnet.cz. Pokud by došlo k access-acceptu je to špatně. Test se provádí pomocí /usr/local/nagios-plugins/vcelka-maja.

??LDAP filter

:: (&(!(radiusDisabled=true))(eduroamMonRealm=*))

??závislosti

:: $home_realm @ $server

??notifikace

:: ANO, 2880min (c,r)

??RW oprávnění

:: admini serveru

??frekvence testů [běžný, fail, HARD]

:: 2880min, 180min, 3x !!

INSTITUTION-XML

TODO - revize semik

??LDAP filter

:: ?

??závislosti

:: PING @ $server

??notifikace

:: ANO, 2880min (c,r)

??RW oprávnění

:: admini serveru

??frekvence testů [běžný, fail, HARD]

:: 2880min, 180min, 3x !!

kompromitovany identity

Test hleda uzivatele se jmenem obsahujicim realm, kteri se uspesne overili s jinymi MAC adresami behem 60 sekund v ruznych realmech. TBD

soubezne se vyskytujici instituce

TBD Test hleda uzivatele, kteri se uspesne overili se stejnymi mac adresami behem 20 sekund s tim, ze navstivena instituce1 nebo navstivena instituce2 odpovida realmu.

RADIUSy s povolenym pristupem

@ujop.cuni.cz @lf1.cuni.cz @troja.mff.cuni.cz radius[12].karlov.mff.cuni.cz

Rúzné typy RADIUSu

??SP & IDP
::radius1.cesnet.cz

!!

?? SP & IdP schovaný za proxy
:: edukrvy.kr-vysocina.cz (realm kr-vysocina.cz)

!!

?? Pouze SP
::earth.cts.cuni.cz (realm cts.cuni.cz), radsec.eduroom.cesnet.cz (realm eduroom.cesnet.cz)

!!

?? Pouze SP schovaný za proxy
:: eduroamproxy.ssstavji.cz (realm ssstavji.cz)

!!

?? Pouze proxy server
::eduroam.kr-vysocina.cz

!!

Poslední úprava:: 2018/07/12 14:03