Panoramica #

RAGGIO or Servizio utente di accesso remoto con autenticazione remota è un protocollo di rete che fornisce autenticazione, autorizzazione e contabilità di utenti e dispositivi per la gestione centralizzata. È ampiamente utilizzato dai provider di servizi Internet e dalle imprese per controllare l'accesso a Internet, servizi locali, reti wireless tramite punti di accesso WiFi, ecc.

Il protocollo RADIUS è implementato nel livello applicazione con un'architettura client-server che può utilizzare TCP o UDP come livello di trasporto e viene comunicato con un database utenti come Active Directory, Servizio LDAP or Sistema di contabilità Linux. Le soluzioni RADIUS più diffuse sono FreeRadius o Microsoft NPS Radius Server.

Protocollo di messaggistica RADIUS #

La messaggistica del protocollo si basa sulla richiesta del client e sulle modalità di risposta del server, come mostrato di seguito.

1. Il cliente invia un Access-Request al server per ogni utente o dispositivo da autenticare sulla porta del server TCP / UDP 1812 (versioni server più vecchie avrebbero usato 1645 anche per l'autenticazione).
2. Il server risponde in base alla politica Access-Accept se l'autenticazione è consentita, Access-Reject se l'accesso non è consentito o Access-Challenge se il server richiede più informazioni per determinare l'accesso (come una seconda convalida: PIN, password, certificato, ecc.)

Facoltativamente, il client e il server potrebbero scambiare messaggi di contabilità come Accounting-Request and Accounting-Response al fine di mantenere un identificativo di sessione univoco.

3. Il cliente invia un Accounting-Request al server attraverso la porta TCP / UDP 1813 per la gestione della sessione di accounting (versioni server precedenti userebbero 1646 anche per l'autenticazione).
4. Il server risponde con a Accounting-Response messaggio per confermare la nuova sessione.

In un ambiente RADIUS, sarà richiesto un servizio aggiuntivo per la gestione del database degli utenti, che sarà considerato importante in alta disponibilità, che verrà trattato in un altro articolo specifico.

Bilanciamento del carico RADIUS e ambiente ad alta disponibilità #

Il problema se un servizio RADIUS è inattivo potrebbe comportare il rischio che gli utenti non possano accedere a una rete di server o accedere a un'applicazione, gli utenti non possano aprire una sessione in un dispositivo o non possano ottenere l'autorizzazione per utilizzare un processo aziendale. Per risolvere questo tipo di situazioni, lo scopo di questo articolo è configurare l'ambiente mostrato di seguito.

RELIANOID condividerà i messaggi del protocollo RADIUS tra tutti i server RADIUS, sia che si trovino in siti diversi o locali. Nelle sezioni seguenti spiegheremo la configurazione di questo tipo di ambienti, i controlli di integrità avanzati per i servizi RADIUS e le sfide di sicurezza di questo protocollo.

Configurazione del servizio virtuale RADIUS #

La natura del protocollo RADIUS è basata su pacchetti UDP, quindi la configurazione di un ambiente RADIUS affidabile è realizzata con a LSLB fattoria con L4xNAT profilo a livello 4, porte 1812 and 1813, tipo di protocollo UDP e preferito DTA per avere trasparenza e ottenere l'IP del client dal lato back-end (anche se NAT dovrebbe funzionare perfettamente pure).

Nel Servizi, nessuna persistenza è necessaria per impostazione predefinita a meno che non sia richiesta una certa aderenza tra il server client-radius.

Se RADIUS viene utilizzato tramite TCP anziché UDP, potrebbe essere modificato nel campo del tipo di protocollo. Potrebbe essere impostato anche TUTTO protocolli per consentire sia TCP che UDP allo stesso tempo dallo stesso IP virtuale.

Infine, configura i backend senza porte configurate (poiché utilizzerà la porta di destinazione della connessione client) e testare la connessione. Una volta configurato correttamente il servizio virtuale RADIUS, è possibile impostare il controllo di integrità avanzato per questo servizio.

RADIUS Advanced Health Check Configuration #

È incluso un controllo avanzato RELIANOID con il nome check_radius sotto la cartella predefinita / Usr / local / zenloadbalancer / app / libexec /.

L'aiuto di questo comando può essere elencato:

root@noid5# /usr/local/zenloadbalancer/app/libexec/check_radius --help Verifica se un server RADIUS accetta connessioni. Utilizzo: check_radius -H host -F file_config -u nome utente -p password [-P porta] [-t timeout] [-r tentativi] [-e aspetta] [-n nas-id] [-N nas-ip-addr ] Opzioni: -h, --help Stampa la schermata di aiuto dettagliata -V, --version Stampa le informazioni sulla versione --extra-opts=[sezione][@file] Legge le opzioni da un file ini. Vedi https://www.monitoring-plugins.org/doc/extra-opts.html per utilizzo ed esempi. -H, --hostname=INDIRIZZO Nome host, indirizzo IP o socket unix (deve essere un percorso assoluto) -P, --port=INTEGER Numero di porta (predefinito: 1645) -u, --username=STRING L'utente a cui authenticate -p, --password=STRING Password per l'autenticazione (RISCHIO PER LA SICUREZZA) -n, --nas-id=STRING identificatore NAS -N, --nas-ip-address=STRING indirizzo IP NAS -F, --filename= STRING File di configurazione -e, --expect=STRING Stringa di risposta attesa dal server -r, --retries=INTEGER Numero di tentativi di connessione non riuscita -t, --timeout=INTEGER Secondi prima del timeout della connessione (impostazione predefinita: 10) Questo plugin testa un server RADIUS per vedere se accetta connessioni. Nella chiamata è necessario specificare il server da testare, nonché un nome utente e una password. Potrebbe essere presente anche un file di configurazione. Il formato del file di configurazione è descritto nei sorgenti della libreria Radiusclient. L'opzione password presenta un sostanziale problema di sicurezza perché la password può essere determinata osservando attentamente la riga di comando nell'elenco dei processi. Questo rischio è aggravato dal fatto che il plug-in verrà in genere eseguito a intervalli regolari e prevedibili. Assicurati che la password utilizzata non consenta l'accesso a risorse di sistema sensibili.

Innanzitutto, controlliamo se funziona correttamente eseguendo il seguente comando di esempio (utilizza i parametri di configurazione del client Radius da RELIANOID):

root@noid5# cd /usr/local/zenloadbalancer/app/libexec/ root@noid5# ./check_radius -H -P -u -P -F

Il test verrà effettuato da RELIANOID dispositivo a un determinato server RADIUS con una convalida utente fittizia e, facoltativamente, un file di configurazione client per parametri client specifici. Testiamo il comando e poi, quando otteniamo il file OK dal server e dal FALLIMENTO quando è inattivo possiamo configurare il controllo di integrità avanzato nel file Servizi sezione del nostro servizio virtuale appena creato.

Non dimenticare di usare il file HOST token durante la configurazione dei controlli di integrità avanzati RELIANOID come di seguito.

check_radius -H HOST -P 1812 -u johndoe -p johnspass -F /etc/radius_client.cfg

Vedi sotto il Servizi configurazione della sezione.

Opzioni di sicurezza RADIUS #

Il protocollo RADIUS utilizza tradizionalmente algoritmi MD5 per l'autenticazione per pacchetto e i controlli di integrità su UDP. Poiché questi due non forniscono alcuna crittografia e protezione di sicurezza, sono stati studiati diversi approcci.

Distribuzioni di RADIUS terminate IPsec or Internet Protocol Security sono stati ampiamente distribuiti, ma ci sono alcune difficoltà di questa opzione poiché il livello dell'applicazione non è a conoscenza delle politiche di sicurezza, poiché sono implicite nel livello della rete. Per utilizzare questo approccio con RELIANOID è necessaria una configurazione manuale in quanto non è ancora integrato.

La specifica di DTLS or Datagram Transport Layer Security consente di fornire crittografia, monitorare e controllare le politiche di sicurezza di tale traffico.

Un'altra opzione sarebbe RADIUS finito TLS che fornisce funzionalità TCP di affidabilità e livello di trasporto in ordine.

Per questo tipo di approcci, il IANA ha creato una voce ufficiale per RadSec (Sicurezza RADIUS) per utilizzare UDP 2083 porto per RADIUS / TLS implementazioni.

Un'altra opzione potrebbe essere quella di migliorare il livello di digest e autorizzazione con EAP (Protocollo di autenticazione estensibile) che non viene utilizzato nel livello di creazione del collegamento ma durante la fase di autenticazione della connessione, evitando l'uso di digest deboli di MD5.

Inoltre, con RELIANOID, i servizi RADIUS possono essere protetti con il modulo IPDS da pacchetti e host dannosi, attacchi DoS, tentativi di forza bruta e molto altro.

Funzionalità del proxy RADIUS #

Se più server RADIUS vengono distribuiti su siti diversi, sarebbe interessante inoltrare la connessione del client al sito che gestisce i loro dati di autenticazione, autorizzazione e contabilità. Attualmente, RELIANOID non supporta le funzionalità proxy RADIUS ma è previsto che venga incluso a breve. Attendo con ansia gli ultimi sviluppi!

Goditi i tuoi servizi di accesso alla rete disponibili e scalabili!