Ai LNF e' stata implementata la rete wireless eduroam per l'accesso ai servizi informatici dedicato alla comunita' internazionale della ricerca (education roaming).

La soluzione tecnica prevede l'annuncio di una rete WL con SSID eduroam su VLAN dedicata a cui e' attribuita una network IP privata "di classe C". E' stata creata una macchina virtuale (SL 6.1) con 2 interfacce LAN che svolge le funzioni di Gateway tra la rete WL eduroam e la rete internet pubblica.

In particolare il gateway svolge le funzioni di DHCP server, Router IP, Firewall/NAT, Radius Server.

Questo documento fornisce una guida per l'installazione e la configurazione di un radius server locale per l'autorizzazione alla connessione sulla rete wireless eduroam. Seguendo le indicazioni si potra' costruire un server radius in grado di demandare (via proxy) tutte le autenticazioni di tipo EAP-TTLS e PEAP, ma anche in grado di autenticare autonomamente tutte le richieste di tipo EAP-TLS (purche' l'utente si presenti con un certificato personale rilasciato da una delle CA della lista TACAR di eduroam).

• Installare l'ultima versione di Freeadius (quella attualmente testata e sperimentata e' la v. 2.1.12, comunque deve essere superiore alla 2.1.10; il server radius dei LNF per il servizio eduroam si chiama edugw).
• Posizionarsi nella directory ove sono situati i file di configurazione (ad esempio: /usr/custom/freeradius/etc/raddb/)

radiusd.conf

• Modificare radiusd.conf (esempio di file completo) secondo le esigenze di sede; in particolare:

impostare la variabile prefix (ove e' installato il s/w freeradius)

prefix = /usr/custom/freeradius

definire l'owner del processo radiusd (root e' sconsigliato per motivi di sicurezza), e ricordarsi di cambiare l'owner anche ai file presenti in ${prefix}/etc/raddb/

user = radiusd
group = radiusd

impostare opportunamente la sezione log:

log {
     ...
     destination = syslog
     ...
     syslog_facility = local6
     ...
}

eap.conf

• Modificare eap.conf secondo le esigenze di sede; in particolare:

eap {
       ...     
       default_eap_type = ttls
       ...
       tls {
              ...
              certdir = ${confdir}/certs
              cadir = ${confdir}/certs
              ...
              ##private_key_password = whatever
              ## Inserire i nomi dei files rispettivamente della chiave privata e del certificato x509 (rilasciato dalla CA INFN) 
              private_key_file = ${certdir}/myradius-cainfn-key.pem
              certificate_file = ${certdir}/myradius-cainfn-cert.pem
              ...
              ## inserire il file contenente tutti i certificati della lista https://www.tacar.org/cert/list/
              ## Attenzione!: per potersi autenticare con i certificati TERENA e' necessario aggiungere anche i certificati 
              ## di COMODO (root CA) e UTN-USERFirst-Client-Authentication-and-Email (Intermediate CA) [Vedi file allcacert allegato]
              CA_file = ${cadir}/allcacerts.pem
              ...
              fragment_size = 1200
              check_cert_cn = %{User-Name}
              ...
       }
       ...
       ttls {
              ...
              ##default_eap_type = md5
              ...
              copy_request_to_tunnel = yes
              ...
              use_tunneled_reply = yes
              ...
              virtual_server = "inner-tunnel"
              ...
       }
       ...
       peap {
              ...
              default_eap_type = mschapv2
              ...
              copy_request_to_tunnel = yes
              ...
              use_tunneled_reply = yes
              ...
              virtual_server = "inner-tunnel"
              ...
       }
       ...
}

Allegato: allcacert.pem

proxy.conf

• Modificare proxy.conf secondo le esigenze di sede; in particolare modificare la definizione dei realm a cui demandare le richieste di autenticazione. E' utile configurare il realm default affinche' sfrutti la ridondanza dei server radius centrali del GARR. Per la configurazione e' importante concordare le <secret password> con i gestori dei radius server dei realm remoti:

home_server localhost {
      ...
      secret = mysecret1
      ...
}
...
realm LOCAL {
      #  If we do not specify a server pool, the realm is LOCAL, and
      #  requests are not proxied to it.
}
...
realm NULL {
      authhost        = LOCAL
      accthost        = LOCAL
      nostrip
}
...
realm lnf.infn.it {
      type            = radius
      authhost        = radius.lnf.infn.it:1812
      accthost        = radius.lnf.infn.it:1813
      secret          = mysecret2
      nostrip
}
...
home_server radius-garr-1 {
      type            = auth+acct
      ipaddr          = radius.garr.net
      port            = 1812
      secret          = mysecret3
      status_check    = status-server
}
home_server radius-garr-2 {
      type            = auth+acct
      ipaddr          = radius2.garr.net
      port            = 1812
      secret          = mysecret3
      status_check    = status-server
}
home_server_pool EDUROAM {
      type            = fail-over
      home_server     = radius-garr-1
      home_server     = radius-garr-2
}
realm DEFAULT {
      pool            = EDUROAM
      nostrip
}
...

clients.conf

• Modificare clients.conf secondo le esigenze di sede; in particolare aggiungere in lista la definizione di tutti i client. Per la configurazione e' importante concordare le <secret password> con i gestori degli client (o degli access point) remoti:

client localhost {
      ...
      secret = mysecret
      ...
}
...
#
# Definizione relativa al server stesso (edugw)
#
client edugw.lnf.infn.it {
      secret          = mysecret
      shortname       = edugw
      nastype         = other
}
#
# Definizione relativa al radius server di autenticazione dei LNF (radius.lnf.infn.it)
# a cui vengono demandate via proxy tutte le richieste di autenticazione relative al dominio lnf
#
client radius.lnf.infn.it {
      secret          = mysecret
      shortname       = radius
      nastype         = other
}
#
# Definizione (eventuale) del server di monitoring (Nagios)
#
client 193.206.84.50 {
      secret          = mysecret
      shortname       = nagios
      nastype         = other
}
#
# Definizione del server proxy del GARR (DEFAULT GARR)
#
client 192.84.145.15 {
      secret          = mysecret2
      shortname       = eduroam
      nastype         = other
}
#
# Definizione del Wireless LAN Controller WLC4400 AP Ports IP
#
client 172.16.14.18 {
      secret          = mysecret
      shortname       = wlc4400
      nastype         = cisco
}
client 172.16.14.19 {
      secret          = mysecret
      shortname       = wlc4400ap
      nastype         = cisco
}
#
# Elenco degli aironet dei LNF ordinati per IP Address (o N. di edificio)
#
client 172.16.1.2 {
      secret          = mysecret
      shortname       = ed1ap1
      nastype         = cisco
}
...
etc
...

In alternativa alla definizione dell'elenco dei client ad uno ad uno, dovrebbe essere possibile anche inserire tutta una network (soluzione non testata):

client 172.16.0.0/16 {
      secret          = mysecret
      shortname       = accesspoint
      nastype         = cisco
}

modules/logger-accept e modules/logger-reject

• Al fine di specializzare i log, in modo che venga scritto anche il subject del certificato dell'utente che tenta l'autenticazione via EAP-TLS, e' necessario creare 2 nuovi moduli di radius: logger-accept e logger-reject

• Creare logger-accept in modo che contenga la stringa di log per le richieste di autenticazione EAP-TLS accettate; vedi esempio:

exec logger-accept {
      wait = yes
      #radiuspid = "%{exec:/bin/cat ${pidfile}}"
      outlog = "Access Accepted in Post-Auth session for user [%{User-Name}] [Issuer: %{TLS-Client-Cert-Issuer} - Subject: %{TLS-Client-Cert-Subject}]"
      program = "/usr/bin/logger -p local6.info -t radiusd[$pid$] ${outlog}"
      input_pairs = request
      output_pairs = reply
      #packet_type = Access-Accept
      shell_escape = yes
}

• Creare logger-reject in modo che contenga la stringa di log per le richieste di autenticazione EAP-TLS rifiutate; vedi esempio:

exec logger-reject {
      wait = yes
      #radiuspid = "%{exec:/bin/cat ${pidfile}}"
      outlog = "Access Rejected in Post-Auth session for user [%{User-Name}] due to local policy [Issuer: %{TLS-Client-Cert-Issuer} - Subject: %{TLS-Client-Cert-Subject}]"
      program = "/usr/bin/logger -p local6.info -t radiusd[$pid$] ${outlog}"
      input_pairs = request
      output_pairs = reply
      #packet_type = Access-Accept
      shell_escape = yes
}

• Nota: non sono riuscito a far scrivere il pid del processo radiusd nel log, ma non e' molto importante.

sites-enabled/default

• Modificare default secondo le esigenze di sede; in particolare e' importante abilitare i desiderati metodi di autenticazione e di autorizzazione:

...
authorize {
      ...
      eap
      ...
      files
      ...
}
...
Authenticate {
      ...
      eap
      ...
}

• e inserire i controlli sul certificato dell'utente nella sessione post-authentication:

...
post-auth {
      ...
#       update reply {
#              Reply-Message += "%{TLS-Cert-Serial}"
#              Reply-Message += "%{TLS-Cert-Expiration}"
#              Reply-Message += "%{TLS-Cert-Subject}"
#              Reply-Message += "%{TLS-Cert-Issuer}"
#              Reply-Message += "%{TLS-Cert-Common-Name}"
#
#              Reply-Message += "%{TLS-Client-Cert-Serial}"
#              Reply-Message += "%{TLS-Client-Cert-Expiration}"
#              Reply-Message += "%{TLS-Client-Cert-Subject}"
#              Reply-Message += "%{TLS-Client-Cert-Issuer}"
#              Reply-Message += "%{TLS-Client-Cert-Common-Name}"
#       }
      if ( TLS-Client-Cert-Subject !~ /^$/ ) {
           # accetta tutti i certificati tranne quello rilasciato dalla CA INFN (per via della policy della CA)
           if ( TLS-Client-Cert-Issuer == "/C=IT/O=INFN/CN=INFN CA" ) {
                logger-reject
                reject
           }
           else {
                logger-accept
           }
      }
}

sites-enabled/inner-tunnel

Il server inner-tunnel viene chiamato in causa nel caso di richiesta di autenticazione passata all'interno di un tunnel (PEAP o EAP-TTLS)

• Modificare inner-tunnel secondo le esigenze di sede; in particolare e' importante abilitare i desiderati metodi di autenticazione e di autorizzazione:

server inner-tunnel {
  ...
  authorize {
      ...
      eap {
              ok = return
      }
      ...
      files
      ...
      if ( "%{outer.request:User-Name}" != "%{User-Name}" ) {
         fail
      }
  }
  ...
  Authenticate {
      ...
      eap
      ...
  }
  ...
}

• Nota: le ultime righe nella sezione authorize sono necessarie per impedire l'autenticazione con outer-identity diversa da inner-identity

users

• Modificare il file users secondo le esigenze di sede; puo' essere utile aggiungere un utente locale di test per la verifica della funzionalita' del radius server; puo' essere utilizzato anche dal server di monitoring Nagios:

test                            Auth-Type := Local, Cleartext-Password := "mypassword"

#

• Nota: lasciare una riga vuota sotto ogni entry del file users

Start del server radius

• Prima dello start occorre modificare la proprieta' e le protezioni dei file di configurazione

chown -R radiusd:radiusd *
chmod -R u+rw,g+r,o+r *
chmod -R g-r,o-r certs/*

• Lanciare il servizio in debug mode:

/usr/custom/freeradius/sbin/radiusd -X

oppure (piu' verboso):

/usr/custom/freeradius/sbin/radiusd -Xxx

• Lanciare il servizio come daemon:

/etc/init.d/radiusd start

• Start automatico al boot

chkconfig --add radiusd
chkconfig --level 35 radiusd on

• Eseguire un banale test di autenticazione:

/usr/custom/freeradius/bin/radtest test mypassword localhost 10 mysecret

(verificare il file di log /var/log/messages)

• Buona fortuna!

Il server edugw e' abilitato anche come DHCP server per distribuire gli indirizzi IP ai nodi wireless connessi al SSID eduroam (sulla VLAN 202). Una delle due interfacce (qualla connessa alla VLAN 202) ha indirizzo 192.168.202.1/24 e assegna gli indirizzi ai client DHCP nel range 192.168.202.2-192.168.202.254

• Creare o modificare il file /etc/dhcpd.conf secondo le esigenze di sede;
• Lanciare il servizio come daemon:

/etc/init.d/dhcpd start

• Start automatico al boot

chkconfig --add dhcpd
chkconfig --level 35 dhcpd on

Il server edugw svolge le funzioni di router dei pacchetti IP dalla rete Wireless (SSID eduroam, VLAN 202, network 192.168.202.0/24) alla rete pubblica. L'interfaccia pubblica ha indirizzo IP 193.205.228.102/30 ed e' configurata come punto-punto verso il router di frontiera connesso al GARR.

• Per abilitare il routing (IP forwanding) occorre modificare il file /etc/sysctl.conf e impostare:

# Controls IP packet forwarding
net.ipv4.ip_forward = 1

• Quindi dare il seguente comando:

sysctl -p

Il server edugw svolge la funzione di NAT server per la traslazione degli indirizzi privati dei nodi connessi in Wireless al SSID eduroam. Tale funzione viene abilitata tramite comandi iptables. Lo stesso iptables e' utilizzato anche per alcune attivita' di filtro e controllo delle connessioni IP (Firewall).

• Per abilitare il NAT occorre creare o modificare il file /etc/sysconfig/iptables.acl (script utilizzato ai LNF per le impostazioni Firewall sulle macchine Linux tramite iptables):

#
# Source NAT to one IP  
#
  iptables -t nat -A POSTROUTING -j LOG --log-level info --log-prefix " NAT: " -m state --state NEW
  iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to 193.205.228.102

• Quindi eseguire lo script:

/etc/sysconfig/iptables.acl

• Attenzione: i log generati dal comando iptables indicato sopra, non sono affatto esaustivi. In tali log infatti manca il source IP e la source PORT translati dal NAT (nel caso specifico la mancanza grave e' quella della source PORT traslata, in quanto il source IP traslato e' univocamente impostato a 193.205.228.102). In mancanza di tali informazioni, potrebbe essere complicato o addirittura impossibile, in talune condizioni, risalire al nodo che ha generato il traffico. Per sopperire a tale grave mancanza
  1. Abbiamo installato conntrack (dai conntrack-tools: http://conntrack-tools.netfilter.org/); non esiste l'RPM, ma solo un tar.
  2. Abbiamo creato lo script perl /usr/custom/scripts/conntracklogger.pl
  3. inserito la seguente riga in /etc/inittab in modo che lo script sia eseguito in modo continuato (tanto contiene un loop infinito con uno sleep di 10 secondi ad ogni ciclo):

ctrk:3:respawn:/usr/custom/scripts/conntracklogger.pl 2>&1

• In questo modo oltre ai normali log derivati da iptables, nel file /var/log/messages arriveranno anche i LOG delle connessioni effettuate con le informazioni di IP e porta traslati, taggate con CONNTRACK:
• Queste info possono anche essere ridirette ad un syslog centrale (noi abbiamo syslog-ng).

— Claudio Soprano 2012/03/14 19:01

— Massimo Pistoni 2012/03/14 19:01