INFN wiki

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== Configurazione Gateway per eduroam ======

Ai LNF e' stata implementata la rete wireless [[http://www.eduroam.org/|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.

{{:strutture:lnf:dr:calcolo:wireless:eduroam.png|schema}}

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

===== 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 {{:strutture:lnf:dr:calcolo:wireless: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 {{:strutture:lnf:dr:calcolo:wireless: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: {{:strutture:lnf:dr:calcolo:wireless:allcacerts.pem.txt|allcacert.pem}}


====== ======

**proxy.conf**

  * Modificare {{:strutture:lnf:dr:calcolo:wireless:proxy.conf|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 {{:strutture:lnf:dr:calcolo:wireless:clients.conf|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: {{:strutture:lnf:dr:calcolo:wireless:logger-accept.txt|logger-accept}} e {{:strutture:lnf:dr:calcolo:wireless:logger-reject.txt|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 {{:strutture:lnf:dr:calcolo:wireless:default.txt|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 {{:strutture:lnf:dr:calcolo:wireless:inner-tunnel.txt|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!**


====== DHCP Server ======

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 {{:strutture:lnf:dr:calcolo:wireless:dhcpd.conf|/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


====== Router IP ======

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


====== Firewall/NAT ======

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 {{:strutture:lnf:dr:calcolo:wireless:iptables.acl.txt|/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
    - Abbiamo installato conntrack (dai conntrack-tools: http://conntrack-tools.netfilter.org/); non esiste l'RPM, ma solo un tar.
    - Abbiamo creato lo script perl {{:strutture:lnf:dr:calcolo:wireless:conntracklogger.pl|/usr/custom/scripts/conntracklogger.pl}}
    - 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@lnf.infn.it|Claudio Soprano]] 2012/03/14 19:01//

--- //[[massimo.pistoni@lnf.infn.it|Massimo Pistoni]] 2012/03/14 19:01//