Overzicht #

RADIUS , ofwel Remote Authentication Dial-In User Service, is een netwerkprotocol dat centraal beheer mogelijk maakt voor authenticatie, autorisatie en registratie van gebruikers en apparaten. Het wordt veel gebruikt door internetproviders en bedrijven om de toegang tot internet, lokale diensten, draadloze netwerken via wifi-toegangspunten, enzovoort te beheren.

Het RADIUS-protocol is geïmplementeerd in de applicatielaag met een client-serverarchitectuur die TCP of UDP als transportlaag kan gebruiken en communiceert met een gebruikersdatabase zoals Active Directory , een LDAP-service of een Linux-boekhoudsysteem . De meest populaire RADIUS-oplossingen zijn FreeRadius en Microsoft NPS RADIUS Server.

RADIUS-berichtenprotocol #

De protocolberichten zijn gebaseerd op de clientaanvraag en de serverreactie, zoals hieronder weergegeven.

1. Klant stuurt een Toegangsverzoek naar de server voor elke gebruiker of elk apparaat dat moet worden geauthenticeerd bij de serverpoort TCP/UDP 1812 (oudere serverversies zouden gebruiken 1645 (ook voor authenticatie).
2. Server reageert volgens het beleid Toegang-Accepteren als de authenticatie is toegestaan, Toegang-Weigeren als de toegang niet is toegestaan ​​of Toegangsuitdaging als de server meer informatie nodig heeft om de toegang te bepalen (zoals een tweede validatie: pincode, wachtwoord, certificaat, enz.)

Optioneel kunnen de client en server berichten uitwisselen met betrekking tot de boekhouding, zoals Accounting-Request en Accounting-Response, om een ​​unieke sessie-identificatie te behouden.

3. Klant stuurt een Boekhoudaanvraag naar de server via de poort TCP/UDP 1813 voor het beheer van boekhoudsessies (oudere serverversies zouden 1646 (ook voor authenticatie).
4. Server antwoordt met een Accounting-Response bericht om de nieuwe sessie te bevestigen.

In een RADIUS-omgeving is een extra service voor databasebeheer van gebruikers vereist en belangrijk om te overwegen met het oog op hoge beschikbaarheid. Dit wordt in een ander specifiek artikel behandeld.

RADIUS-load balancing en omgeving met hoge beschikbaarheid #

Het probleem als een RADIUS-service niet werkt, kan ertoe leiden dat gebruikers geen toegang hebben tot een servernetwerk of niet kunnen inloggen op een applicatie, geen sessie kunnen openen op een apparaat of geen autorisatie kunnen krijgen om een ​​recht in een bedrijfsproces te gebruiken. Om dergelijke situaties op te lossen, is het doel van dit artikel om de onderstaande omgeving in te stellen.

RELIANOID deelt de RADIUS-protocolberichten tussen alle RADIUS-servers, ongeacht of deze zich op verschillende of lokale locaties bevinden. In de volgende secties leggen we de configuratie van dit soort omgevingen, de geavanceerde statuscontroles voor RADIUS-services en de beveiligingsuitdagingen van dit protocol uit.

RADIUS Virtuele Service Configuratie #

Het RADIUS-protocol is gebaseerd op UDP-pakketten. De configuratie van een betrouwbare RADIUS-omgeving wordt daarom opgezet met een LSLB- farm met een L4xNAT -profiel op laag 4, poorten 1812 en 1813 , protocoltype UDP en bij voorkeur DNAT om transparantie te garanderen en het IP-adres van de client aan de backend-zijde te verkrijgen (hoewel NAT ook prima zou moeten werken).

In de services is standaard geen persistentie nodig, tenzij er een bepaalde mate van verbinding tussen de client en de RADIUS-server vereist is.

Als RADIUS via TCP in plaats van UDP wordt gebruikt, kan dit worden gewijzigd in het veld voor het protocoltype. Het kan ook worden ingesteld op 'ALLE protocollen' om zowel TCP als UDP tegelijkertijd vanaf hetzelfde virtuele IP-adres toe te staan.

Configureer ten slotte de backends zonder geconfigureerde poorten (aangezien deze de bestemmingspoort van de clientverbinding gebruiken) en test de verbinding. Zodra de virtuele RADIUS-service succesvol is geconfigureerd, kunnen we de geavanceerde statuscontrole voor deze service instellen.

RADIUS Geavanceerde Gezondheidscontrole Configuratie #

Een geavanceerde controle is inbegrepen RELIANOID met naam check_radius onder de standaardmap /usr/local/zenloadbalancer/app/libexec/.

De hulp van deze opdracht kan als volgt worden weergegeven:

root@noid5# /usr/local/zenloadbalancer/app/libexec/check_radius --help Test of een RADIUS-server verbindingen accepteert. Gebruik: check_radius -H host -F config_file -u gebruikersnaam -p wachtwoord [-P poort] [-t time-out] [-r pogingen] [-e verwacht] [-n nas-id] [-N nas-ip-addr] Opties: -h, --help Gedetailleerd helpscherm afdrukken -V, --version Versie-informatie afdrukken --extra-opts=[sectie][@file] Opties lezen uit een ini-bestand. Zie https://www.monitoring-plugins.org/doc/extra-opts.html voor gebruik en voorbeelden. -H, --hostname=ADRES Hostnaam, IP-adres of Unix-socket (moet een absoluut pad zijn) -P, --port=INTEGER Poortnummer (standaard: 1645) -u, --username=STRING De gebruiker die moet worden geverifieerd -p, --password=STRING Wachtwoord voor authenticatie (BEVEILIGINGSRISICO) -n, --nas-id=STRING NAS-identificatie -N, --nas-ip-address=STRING NAS IP-adres -F, --filename=STRING Configuratiebestand -e, --expect=STRING Verwachte antwoordreeks van de server -r, --retries=INTEGER Aantal keren dat een mislukte verbinding opnieuw moet worden geprobeerd -t, --timeout=INTEGER Seconden voordat de verbinding time-out geeft (standaard: 10) Deze plugin test een RADIUS-server om te zien of deze verbindingen accepteert. De te testen server moet worden opgegeven in de aanroep, evenals een gebruikersnaam en wachtwoord. Er kan ook een configuratiebestand aanwezig zijn. De indeling van het configuratiebestand wordt beschreven in de bronnen van de radiusclient-bibliotheek. De wachtwoordoptie vormt een aanzienlijk beveiligingsprobleem, omdat het wachtwoord mogelijk kan worden achterhaald door de opdrachtregel in een proceslijst nauwlettend te volgen. Dit risico wordt vergroot doordat de plugin doorgaans met regelmatige, voorspelbare tussenpozen wordt uitgevoerd. Zorg ervoor dat het gebruikte wachtwoord geen toegang geeft tot gevoelige systeembronnen.

Laten we eerst controleren of het goed werkt door de volgende voorbeeldopdracht uit te voeren (gebruik hiervoor uw eigen radius-clientconfiguratieparameters van RELIANOID):

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

De test wordt gedaan vanaf RELIANOID apparaat naar een specifieke RADIUS-server met een dummy-gebruikersvalidatie en, optioneel, een clientconfiguratiebestand voor specifieke clientparameters. Laten we de opdracht testen en, wanneer we de OK van de server en de MISLUKKING Als het down is, kunnen we de geavanceerde gezondheidscontrole configureren in de Services onderdeel van onze zojuist gecreëerde virtuele service.

Vergeet niet de HOST token bij het configureren van de geavanceerde gezondheidscontroles in RELIANOID zoals hieronder.

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

Zie hieronder de configuratie van het gedeelte Services.

RADIUS-beveiligingsopties #

Het RADIUS-protocol gebruikt traditioneel MD5-algoritmen voor authenticatie per pakket en integriteitscontroles via UDP. Omdat deze twee geen beveiligingsencryptie en bescherming bieden, zijn er verschillende benaderingen onderzocht.

Implementaties van RADIUS over IPsec or Internet Protocol Security zijn op grote schaal geïmplementeerd, maar deze optie kent enkele problemen, omdat de applicatielaag niet op de hoogte is van het beveiligingsbeleid, omdat dit impliciet in de netwerklaag is opgenomen. Om deze aanpak te gebruiken met RELIANOID Er is wat handmatige configuratie nodig omdat het nog niet geïntegreerd is.

De specificatie van DTLS , oftewel Datagram Transport Layer Security, maakt het mogelijk om encryptie te bieden en het beveiligingsbeleid van dergelijk verkeer te bewaken en te controleren.

Een andere optie zou RADIUS over TLS zijn , dat de betrouwbaarheids- en geordende transportlaagmogelijkheden van TCP biedt.

Voor dit soort benaderingen heeft de IANA een officiële vermelding voor RadSec ( RADIUS Security ) aangemaakt om UDP- poort 2083 te gebruiken voor RADIUS/TLS- implementaties.

Een andere optie zou zijn om de digest- en autorisatielaag te versterken met EAP ( Extensible Authentication Protocol ), dat niet wordt gebruikt in de verbindingsopbouwlaag, maar tijdens de authenticatiefase van de verbinding, waardoor het gebruik van zwakke MD5-hashes wordt vermeden.

Bovendien met RELIANOIDMet de IPDS-module kunnen de RADIUS-services worden beschermd tegen schadelijke pakketten en hosts, DoS-aanvallen, brute-force-pogingen en nog veel meer.

RADIUS Proxy-mogelijkheden #

Als er meerdere RADIUS-servers op verschillende locaties zijn geïmplementeerd, zou het interessant zijn om de clientverbinding door te sturen naar de site die hun authenticatie-, autorisatie- en accountinggegevens beheert. Momenteel RELIANOID Ondersteunt geen RADIUS-proxyfunctionaliteit, maar dit wordt binnenkort verwacht. Kijk uit naar de nieuwste ontwikkelingen!

Geniet van uw hoog beschikbare en schaalbare netwerktoegangsservices!