Realizzazione di un' interfaccia web per la gestione dei file di log generati da un Web Server

36
Università degli Studi di Trieste Realizzazione di un’interfaccia web per la gestione dei log file di un web server Facoltà di Ingegneria Corso di Laurea Triennale in Ingegneria Informatica Laureando: Relatore: Marco Furlanetto Prof. Maurizio Fermeglia Anno Accademico 2011/2012

description

 

Transcript of Realizzazione di un' interfaccia web per la gestione dei file di log generati da un Web Server

Page 1: Realizzazione di un' interfaccia web per la gestione dei file di log generati da un Web Server

Università degli Studi di Trieste

Realizzazionediun’interfacciawebperla

gestionedeilogfilediunwebserver

Facoltà di Ingegneria

Corso di Laurea Triennale in Ingegneria Informatica

Laureando: Relatore:

Marco Furlanetto Prof. Maurizio Fermeglia

Anno Accademico 2011/2012

Page 2: Realizzazione di un' interfaccia web per la gestione dei file di log generati da un Web Server

2

Page 3: Realizzazione di un' interfaccia web per la gestione dei file di log generati da un Web Server

3

Sommario

1 INTRODUZIONE

1.1 Obiettivo .......................................................................................................................................... 5

1.2 Risultato della tesi ............................................................................................................................ 5

2 LA GESTIONE DELLE AUTENTICAZIONI

2.1 RADIUS ............................................................................................................................................ 6

2.1.1 EAP ........................................................................................................................................................ 6

2.1.2 Struttura del protocollo ........................................................................................................................ 8

2.2 IAS ................................................................................................................................................... 9

2.2.1 Diversi metodi di autenticazione ........................................................................................................ 10

2.2.2 Diversi metodi di autorizzazione ........................................................................................................ 10

2.2.3 Server di accesso eterogenei .............................................................................................................. 11

2.2.4 Proxy RADIUS ...................................................................................................................................... 11

2.2.5 Autenticazione e autorizzazione utente centralizzate ....................................................................... 11

2.2.6 Amministrazione centralizzata per tutti i server di accesso ............................................................... 11

2.2.7 Controllo e accounting centralizzati ................................................................................................... 12

2.2.8 Scalabilità ............................................................................................................................................ 12

2.2.9 Estensibilità ......................................................................................................................................... 12

2.3 NPS ................................................................................................................................................ 12

3 STRUTTURA DELL'APPLICAZIONE

3.1 Log ................................................................................................................................................. 14

3.2 Database ........................................................................................................................................ 18

3.3 Software ........................................................................................................................................ 19

3.3.1 Pagina web ..................................................................................................................................... 20

3.3.2 Codice ............................................................................................................................................. 22

4 FUNZIONAMENTO DELL'APPLICAZIONE

4.1 Ricerca e caricamento log ............................................................................................................... 23

Page 4: Realizzazione di un' interfaccia web per la gestione dei file di log generati da un Web Server

4

4.2 Analisi log e caricamento database ................................................................................................. 24

4.3 Visualizzazione dei dati ................................................................................................................... 25

4.4 Funzionalità.................................................................................................................................... 26

4.4.1 Filtri sui campi del database ........................................................................................................... 27

4.4.2 Gestione degli archivi contenenti i file di log ................................................................................. 29

................................................................................................................................................................. 31

4.4.3 Operazioni sul database ................................................................................................................. 31

5 CONCLUSIONI

5.1 DIAMETER ...................................................................................................................................... 33

5.1.1 UDP (User Datagram Protocol) ........................................................................................................... 33

5.1.2 TCP (Transfer Control Protocol) .......................................................................................................... 33

5.1.3 Miglioramenti rispetto a RADIUS ....................................................................................................... 34

5.2 Possibili miglioramenti per l’applicazione ........................................................................................ 34

5.2.1 Estensione a più dipartimenti ............................................................................................................. 34

5.2.2 Gestione di più tipologie di log ........................................................................................................... 35

5.2.3 Grafici di andamento .......................................................................................................................... 35

5.2.4 Connessione a vari database .............................................................................................................. 35

5.3 Ambiente di sviluppo ...................................................................................................................... 35

Page 5: Realizzazione di un' interfaccia web per la gestione dei file di log generati da un Web Server

5

1. Introduzione

1.1 Obiettivo

Si vuole realizzare un’applicazione web per la gestione di file di log.

I file di log vengono creati da un Web Server che gestisce le autenticazioni per l’accesso ad Internet

attraverso la connessione wireless degli utenti del Dipartimento di Ingegneria Industriale e

dell’Informazione.

L’applicazione deve permettere all’analista di effettuare in maniera intuitiva il controllo delle informazioni

contenute nei log.

E’ da precisare che l’applicazione permette di analizzare le richieste di autenticazione, non i contenuti

scambiati.

1.2 Risultato della tesi

All’ avvio l’applicazione si presenta nel seguente modo:

Figura 1 - Schermata principale dell'applicazione

Page 6: Realizzazione di un' interfaccia web per la gestione dei file di log generati da un Web Server

6

2.Lagestionedelleautenticazioni

In questo capitolo illustrerò il funzionamento del sistema che gestisce le credenziali degli utenti di una rete

gestita in ambiente Microsoft Windows, chiarendo prima tre concetti fondamentali: autenticazione,

autorizzazione e accounting (AAA).

1. L’autenticazione ha lo scopo di riconoscere l’utente, normalmente tramite username e password;

2. L’autorizzazione definisce a quali risorse può accedere un utente autenticato. Tali risorse vengono

definite dai gestori di rete;

3. L’accounting permette di avere una panoramica sull’uso delle risorse da parte dell’utente, in modo

da tracciare delle statistiche di utilizzo.

2.1 RADIUS

RADIUS (Remote Authentication Dial-In User Service) è un protocollo di tipo AAA usato attualmente come

standard per l’autenticazione remota e viene implementato in appositi server.

Il protocollo non si occupa della memorizzazione delle credenziali: questo è a carico di servizi esterni come

database o file di testo.

A partire da username e password, grazie a RADIUS è possibile gestire numerose informazioni: per esempio

un Internet Service Provider (ISP) può analizzare l’uso della banda da parte degli utenti, e di conseguenza

imporre eventuali limiti di utilizzo.

Ai fini della tesi mi soffermerò sulla descrizione dei metodi di autenticazione tramite tecnologia wireless.

2.1.1 EAP

EAP (Extensible Authentication Protocol) è un protocollo di autenticazione largamente utilizzato negli

access-point. Il suo utilizzo all’interno di una rete wireless impone che l’access-point inoltri la richiesta

d’autenticazione di un client ad un server dedicato (server RADIUS).

Page 7: Realizzazione di un' interfaccia web per la gestione dei file di log generati da un Web Server

7

Di seguito vengono descritti i principali metodi di autenticazione EAP:

• EAP-Message Digest 5 (MD5)

E’ un metodo di autenticazione di livello base supportato da molti server e di facile

implementazione.

Il suo utilizzo, però, non è consigliato quando il grado di sicurezza richiesto è elevato; uno dei

principali motivi è la mancanza di mutua autenticazione: solo il client è obbligato a dimostrare la

propria identità, quindi un malintenzionato può fingere di essere il server, ed in questo modo

ottenere le credenziali della vittima;

• EAP-TLS

Il Transport Layer Security (TLS) offre un livello di sicurezza molto elevato grazie all’utilizzo di

certificati lato client e lato server tramite l’utilizzo dell’infrastruttura a chiave pubblica (Public Key

Infrastructure o PKI). Un certificato è un’ insieme di informazioni riguardanti un’entità (persona,

azienda, ecc.) verificato tramite appositi algoritmi; ogni client dispone di un certificato.

Questa maggior sicurezza richiede però un aumento della complessità degli strumenti software;

• EAP-TTLS

Il Tunnelled Transport Layer Security (TTLS), estensione di TLS, è un metodo a due passaggi. Nel

primo si verifica l’identità del server e si crea il tunnel crittato di comunicazione; nel secondo si

verifica l’identità del client utilizzando un secondo metodo di autenticazione, generalmente l’MD5.

Una volta verificata la sua identità, il tunnel viene disabilitato.

• EAP-LEAP

Lightweight Extensible Authentication Protocol sviluppato da Cisco. Si basa su un protocollo di

autenticazione chiamato "reciproco consenso": sia il client, sia l'access-point a cui il client richiede la

connessione devono autenticarsi prima di avere accesso all'interno della rete. In questo modo si

previene l'accesso non autorizzato di access-point estranei alla rete.

Page 8: Realizzazione di un' interfaccia web per la gestione dei file di log generati da un Web Server

8

2.1.2 Struttura del protocollo

Figura 2 - Struttura di un pacchetto RADIUS

Nel seguito vengono descritti nel dettaglio i campi del pacchetto:

Code, identifica i seguenti tipi di pacchetto:

Codice Nome Descrizione

1 Access-Request Inviato da un client ad un server RADIUS. Conterrà le informazioni che servono al server per

determinare se autorizzare l’accesso di un utente di un NAS

2 Access-Accept Quando il server RADIUS riceve un Access-Request, invierà un Access-Accept se il valore di tutti gli

attribute presenti nell’Access-Request sono accettabili. Access-Accept fornirà le informazioni di

configurazione necessarie al client

3 Access-Reject Quando il server RADIUS riceve un Access-Request, invierà un Access-Reject se qualcuno dei

valori degli attribute presenti nell’Access-Request è inaccettabile

4 Accounting-Request Inviato da un client ad un server, contiene informazioni di accounting. Se il server RADIUS accetta

l’Accounting-Request, risponderà con un Accounting-Response

5 Accounting-Response Inviato dal server al client per confermarela ricezione dell’Accounting-Request

11 Access-Challenge Quando il server RADIUS riceve un Access-Accept, può inviare al client un Access-Challenge, che

richiederà una risposta. Il client risponderà con un nuovo Access-Request

12 Status-Server

(experimental)

13 Status-Client

(experimental)

255 Reserved

Identifier: è utilizzato per associare richieste e risposte e per determinate richieste duplicate;

Length: la lunghezza dell’intero pacchetto;

Authenticator: è utilizzato per autenticare la risposta del server. Sono definiti due tipi di Authenticator:

o Request-Authentication: utilizzato nei pacchetti Access-Request e Accounting-Request;

o Response-Authenticator: utilizzato nei pacchetti Access-Accept, Access-Reject, Access-Challenge e

Accounting-Response;

Page 9: Realizzazione di un' interfaccia web per la gestione dei file di log generati da un Web Server

9

Attributes: campo di lunghezza variabile; il formato è il seguente:

Figura 3 - Campo 'Attributo'

• Type: tipo di attributo (dettaglio nella seguente tabella)

1 User-Name

2 User-Password

4 NAS-IP-

Address

5 NAS-Port

32 NAS-Identifier

40-59 Accounting

• Length: dimensione dell’attributo;

• Value: campo di lunghezza variabile; è possibile ottenere la sua dimensione analizzando il campo

length del pacchetto.

2.2 IAS

Il Servizio di Autenticazione Internet (IAS) è l'implementazione Microsoft di un server RADIUS in Windows

Server 2003. Come server RADIUS, il servizio IAS esegue operazioni centralizzate di autenticazione,

autorizzazione e accounting delle connessioni per numerosi tipi di accesso alla rete, tra cui wireless,

cablato, VPN, ecc..

Il protocollo può essere inoltre configurato come proxy RADIUS permettendo alle richieste dei client di

essere inoltrate ad altri server RADIUS.

Funzionalità di IAS:

• Diversi metodi di autenticazione

• Diversi metodi di autorizzazione

• Server di accesso eterogenei

• Proxy RADIUS

• Autenticazione e autorizzazione utente centralizzate

• Amministrazione centralizzata server di accesso

• Controllo e accounting centralizzati

• Scalabilità

• Estensibilità

Page 10: Realizzazione di un' interfaccia web per la gestione dei file di log generati da un Web Server

10

Nei paragrafi seguenti descriverò con più dettaglio le funzionalità appena elencate.

2.2.1 Diversi metodi di autenticazione

Il servizio IAS supporta diversi protocolli di autenticazione e consente di aggiungere metodi personalizzati

per determinate esigenze. I metodi di autenticazione supportati sono i seguenti:

• Protocolli di autenticazione PPP (Password-based Point-to-Point Protocol; PPP permette di

connettere due nodi di una rete):

o PAP (Password Authentication Protocol): il client si fa riconoscere dal server tramite una

password; se la rete è composta da più di due nodi la sicurezza diventa più debole;

o CHAP (Challenge Handshake Authentication Protocol): il server verifica periodicamente

l’identità del client tramite chiave condivisa (handshake);

o MS-CHAP (Microsoft Challenge Handshake Authentication Protocol): implementazione

Microsoft di CHAP a cui sono state aggiunte funzionalità di crittografia;

o MS-CHAP versione 2 (MS-CHAP v2): deriva da MS-CHAP; impone che anche il server

dimostri la propria identità al client.

• Protocollo EAP (Extensible Authentication Protocol):

Questo metodo viene descritto nel paragrafo 2.2.1.

2.2.2 Diversi metodi di autorizzazione

I metodi di autorizzazione supportati sono i seguenti:

• DNIS (Dialed Number Identification Service):

Autorizzazione in base alle credenziali fornite dal client in fase di autenticazione;

• Servizio ANI/CLI (Automatic Number Identification/Calling Line Identification):

Le credenziali non vengono trasmesse;

• Autorizzazione guest:

Quando, all’atto dell’accesso, non vengono fornite le credenziali del client.

Page 11: Realizzazione di un' interfaccia web per la gestione dei file di log generati da un Web Server

11

2.2.3 Server di accesso eterogenei

Il servizio IAS supporta server di accesso che supportano le specifiche RFC RADIUS 2865 e 2866; i principali

sono:

• Punti di accesso senza fili:

IAS può essere utilizzato come server RADIUS per punti di accesso senza fili che utilizzano RADIUS

per l'autenticazione e l'autorizzazione dei nodi senza fili.

• Switch di autenticazione:

può essere utilizzato come server RADIUS per switch di rete Ethernet che utilizzano RADIUS per

l'autenticazione e l'autorizzazione dei nodi di commutazione.

2.2.4 Proxy RADIUS

IAS consente di inoltrare una richiesta RADIUS in ingresso a un altro server RADIUS per l'elaborazione

dell'autenticazione e dell'autorizzazione o dell'accounting. In qualità di proxy RADIUS, il servizio IAS può

essere utilizzato ogni volta che la richiesta RADIUS deve essere indirizzata a un altro server RADIUS. Il

servizio IAS consente di inoltrare le richieste in base al nome utente, all'indirizzo IP del server di accesso

remoto, all'identificatore del server di accesso, ecc.

2.2.5 Autenticazione e autorizzazione utente centralizzate

Per autenticare una richiesta di connessione, il server IAS convalida le credenziali verificandole con gli

account utente memorizzati. È possibile autorizzare l'accesso alla rete sulla base di diverse condizioni, tra

cui:

• L'appartenenza dell'account utente ad un gruppo.

• L'ora del giorno o il giorno della settimana.

• Il tipo di supporto mediante il quale l'utente effettua la connessione, ad esempio un supporto senza

fili, un switch Ethernet, un modem o una rete VPN.

• Il numero telefonico chiamato dall'utente.

• Il server di accesso da cui proviene la richiesta.

2.2.6 Amministrazione centralizzata per tutti i server di accesso

Il supporto per lo standard RADIUS consente al server IAS di controllare i parametri di connessione per

ciascun server di accesso che implementa RADIUS.

Page 12: Realizzazione di un' interfaccia web per la gestione dei file di log generati da un Web Server

12

2.2.7 Controllo e accounting centralizzati

Il supporto per RADIUS consente al server IAS di raccogliere in un’unica posizione i record relativi all'utilizzo

(accounting) inviati da tutti i server di accesso. Vengono archiviate nei file di log informazioni sul controllo,

ad esempio le autenticazioni accettate e quelle rifiutate, oltre a informazioni sull'utilizzo, ad esempio i

record di connessione e disconnessione. Il server IAS supporta un formato di file di log che può essere

importato direttamente in un database permettendo l’analisi con qualsiasi applicazione standard per

l'analisi dei dati.

2.2.8 Scalabilità

È possibile utilizzare il server IAS in diverse configurazioni per reti di varie dimensioni: da server autonomi

per reti di piccole dimensioni a grandi organizzazioni e provider di servizi Internet.

2.2.9 Estensibilità

Attraverso strumenti di sviluppo software (SDK – Software Development Kit) compatibili con IAS si può:

• Controllare il numero di sessioni di rete degli utenti.

• Importare dati di utilizzo e di controllo direttamente in un database ODBC (Open Database

Connectivity).

• Creare moduli di autorizzazione personalizzati.

• Creare moduli di autenticazione personalizzati (non EAP).

2.3 NPS

A partire dalla versione 2008 dei sistemi operativi Microsoft Windows Server il sistema IAS viene sostituito

da NPS (Network Policy Server).

Fornisce le stesse funzionalità di IAS, introducendo vari miglioramenti, tra i quali :

• Supporto a NAP (Network Access Protection), che fornisce una piattaforma di accesso sicuro a reti

private; questo grazie al controllo dello stato del firewall e dell’anti-virus del client;

• Supporto ad indirizzi IPv6;

• Possibilità di salvare le informazioni di configurazione in documenti XML; IAS faceva uso del motore

per database JET.

NPS produce i file di log che verranno analizzati dall’applicazione sviluppata per la tesi.

Page 13: Realizzazione di un' interfaccia web per la gestione dei file di log generati da un Web Server

13

3.Strutturadell’applicazione

Il sistema è diviso in tre parti:

• Log

• Database

• Software

Figura 4 - Schema generico di un sistema RADIUS

In Figura 4 viene schematizzato il funzionamento del sistema RADIUS: i client possono connettersi al server

RADIUS utilizzando varie tecnologie. Il server dispone di un database contenente tutte le credenziali in

modo da verificare l’identità degli utenti.

Di seguito verrà descritta nel dettaglio ogni componente.

Page 14: Realizzazione di un' interfaccia web per la gestione dei file di log generati da un Web Server

14

3.1 Log

I log sono file di testo generati con cadenza ben definita dal server di autenticazione.

Questi file vengono salvati come INxxyy.log: “IN” indica che vengono generati mensilmente, xx l’anno e yy il

mese.

Genericamente, una riga del file appare nel seguente modo:

"CLIENTCOMP","IAS",03/07/2008,13:04:33,1,"client",,,,,,,,,9,"10.10.10.10","npsclient",,,,,,,1,,0,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,

La seguente tabella descrive nel dettaglio ogni attributo:

VALORE ATTRIBUTO TIPO DI DATO DESCRIZIONE

"CLIENTCOMP" ComputerName Text The name of the server where the packet was received (this is an IAS-internal

attribute).

"IAS" ServiceName Text The name of the service that generated the record—IAS or the Routing and

Remote Access service (this is an IAS-internal attribute).

03/07/2008 Record-Date Time The date at the NPS or Routing and Remote Access server (this is an IAS-

internal attribute).

13:04:33 Record-Time Time The time at the NPS or Routing and Remote Access server (this is an IAS-

internal attribute).

1 Packet-Type Number The type of packet, which can be:

1 = Access-Request

2 = Access-Accept

3 = Access-Reject

4 = Accounting-Request

This is an IAS-internal attribute.

"client" User-Name Text The user identity, as specified by the user.

Fully-Qualified-

Distinguished-

Name

Text The user name in canonical format (this is an IAS-internal attribute).

Called-Station-ID Text The phone number dialed by the user.

Calling-Station-ID Text The phone number from which the call originated.

Callback-Number Text The callback phone number.

Framed-IP-Address Text The framed address to be configured for the user.

NAS-Identifier Text The text that identifies the network access server originating the request.

NAS-IP-Address Text The IP address of the network access server originating the request.

NAS-Port Number The physical port number of the network access server originating the request.

9 Client-Vendor Number The manufacturer of the network access server (this is an IAS-internal

attribute).

"10.10.10.10" Client-IP-Address Text The IP address of the RADIUS client (this is an IAS-internal attribute).

"npsclient" Client-Friendly-

Name

Text The friendly name for the RADIUS client (this is an IAS-internal attribute).

Event-Timestamp Time The date and time that this event occurred on the network access server.

Port-Limit Number The maximum number of ports that the network access server provides to the

user.

NAS-Port-Type Number The type of physical port that is used by the network access server originating

the request.

Connect-Info Text Information that is used by the network access server to specify the type of

connection made. Typical information includes connection speed and data

encoding protocols.

Framed-Protocol Number The protocol to be used.

Service-Type Number The type of service that the user has requested.

1 Authentication-

Type

Number The authentication scheme, which is used to verify the user and can be:

Page 15: Realizzazione di un' interfaccia web per la gestione dei file di log generati da un Web Server

15

1 = PAP

2 = CHAP

3 = MS-CHAP

4 = MS-CHAP v2

5 = EAP

7 = None

8 = Custom

This is an IAS-internal attribute.

Policy-Name Text The friendly name of the network policy that either granted or denied access.

This attribute is logged in Access-Accept and Access-Reject messages. If a user

is rejected because none of the network policies matched, then this attribute is

blank.

0 Reason-Code Number The reason for rejecting a user, which can be:

0 = IAS_SUCCESS

1 = IAS_INTERNAL_ERROR

2 = IAS_ACCESS_DENIED

3 = IAS_MALFORMED_REQUEST

4 = IAS_GLOBAL_CATALOG_UNAVAILABLE

5 = IAS_DOMAIN_UNAVAILABLE

6 = IAS_SERVER_UNAVAILABLE

7 = IAS_NO_SUCH_DOMAIN

8 = IAS_NO_SUCH_USER

16 = IAS_AUTH_FAILURE

17 = IAS_CHANGE_PASSWORD_FAILURE

18 = IAS_UNSUPPORTED_AUTH_TYPE

32 = IAS_LOCAL_USERS_ONLY

33 = IAS_PASSWORD_MUST_CHANGE

34 = IAS_ACCOUNT_DISABLED

35 = IAS_ACCOUNT_EXPIRED

36 = IAS_ACCOUNT_LOCKED_OUT

37 = IAS_INVALID_LOGON_HOURS

38 = IAS_ACCOUNT_RESTRICTION

48 = IAS_NO_POLICY_MATCH

64 = IAS_DIALIN_LOCKED_OUT

65 = IAS_DIALIN_DISABLED

66 = IAS_INVALID_AUTH_TYPE

67 = IAS_INVALID_CALLING_STATION

68 = IAS_INVALID_DIALIN_HOURS

69 = IAS_INVALID_CALLED_STATION

70 = IAS_INVALID_PORT_TYPE

71 = IAS_INVALID_RESTRICTION

80 = IAS_NO_RECORD

96 = IAS_SESSION_TIMEOUT

97 = IAS_UNEXPECTED_REQUEST

This is an IAS-internal attribute.

Class Text The attribute that is sent to the client in an Access-Accept packet.

Session-Timeout Number The length of time (in seconds) before the session is terminated.

Page 16: Realizzazione di un' interfaccia web per la gestione dei file di log generati da un Web Server

16

Idle-Timeout Number The length of idle time (in seconds) before the session is terminated.

Termination-Action Number The action that the network access server takes when service is completed.

EAP-Friendly-

Name

Text The friendly name of the EAP-based authentication method that was used by

the access client and NPS server during the authentication process. For

example, if the client and server use Extensible Authentication Protocol (EAP)

and the EAP type MS-CHAP v2, the value of EAP-Friendly-Name is “Microsoft

Secured Password (EAP-MSCHAPv2)."

Acct-Status-Type Number The number that specifies whether an accounting packet starts or stops a

bridging, routing, or Terminal Server session.

Acct-Delay-Time Number The length of time (in seconds) for which the network access server has been

sending the same accounting packet.

Acct-Input-Octets Number The number of octets received during the session.

Acct-Output-

Octets

Number The number of octets sent during the session.

Acct-Session-Id Text The unique numeric string that identifies the server session.

Acct-Authentic Number The number that specifies which server authenticated an incoming call.

Acct-Session-Time Number The length of time (in seconds) for which the session has been active.

Acct-Input-Packets Number The number of packets received during the session.

Acct-Output-

Packets

Number The number of packets sent during the session.

Acct-Terminate-

Cause

Number The reason that a connection was terminated.

Acct-Multi-Ssn-ID Text The unique numeric string that identifies the multilink session.

Acct-Link-Count Number The number of links in a multilink session.

Acct-Interim-

Interval

Number The length of interval (in seconds) between each interim update that the

network access server sends.

Tunnel-Type Number The tunneling protocol to be used.

Tunnel-Medium-

Type

Number The medium to use when creating a tunnel for protocols. For example, L2TP

packets can be sent over multiple link layers.

Tunnel-Client-

Endpt

Text The IP address of the tunnel client.

Tunnel-Server-

Endpt

Text The IP address of the tunnel server.

Acct-Tunnel-Conn Text An identifier assigned to the tunnel.

Tunnel-Pvt-Group-

ID

Text The group ID for a specific tunneled session.

Tunnel-

Assignment-ID

Text The tunnel to which a session is assigned.

Tunnel-Preference Number The preference of the tunnel type, as indicated with the Tunnel-Type attribute

when multiple tunnel types are supported by the access server.

MS-Acct-Auth-

Type

Number A Routing and Remote Access service attribute. For more information, see RFC

2548.

MS-Acct-EAP-Type Number A Routing and Remote Access service attribute. For more information, see RFC

2548.

MS-RAS-Version Text A Routing and Remote Access service attribute. For more information, see RFC

2548.

MS-RAS-Vendor Number A Routing and Remote Access service attribute. For more information, see RFC

2548.

MS-CHAP-Error Text A Routing and Remote Access service attribute. For more information, see RFC

2548.

MS-CHAP-Domain Text A Routing and Remote Access service attribute. For more information, see RFC

2548.

MS-MPPE-

Encryption-Types

Number A Routing and Remote Access service attribute. For more information, see RFC

2548.

MS-MPPE-

Encryption-Policy

Number A Routing and Remote Access service attribute. For more information, see RFC

2548.

Proxy-Policy-Name Text The name of the connection request policy that matched the connection

request.

Provider-Type Number Specifies the location where authentication occurs. Possible values are 0, 1, and

2. A value of 0 indicates that no authentication occurred. A value of 1 indicates

that authentication occurs on the local NPS server. A value of 2 indicates that

the connection request is forwarded to a remote RADIUS server for

authentication.

Provider-Name Text A string value that corresponds to Provider-Type. Possible values are "None"

for a Provider-Type value of 0, "Windows" for a Provider-Type value of 1, and

"Radius Proxy" for Provider-Type value of 2.

Remote-Server-

Address

IP address The IP address of the remote RADIUS server to which the connection request

was forwarded for authentication.

"CLIENTCOMP" MS-RAS-Client-

Name

Text The name of the remote access client. The Vendor-Length of the Value field,

including the vendor ID, vendor-type, vendor-length, and value, must be at

Page 17: Realizzazione di un' interfaccia web per la gestione dei file di log generati da un Web Server

17

least 7 and less than 40.

Value, which specifies the computer name of the endpoint that is requesting

network access, is sent in ASCII format and is null terminated.

The valid character set for the computer name includes letters, numbers, and

the following symbols: ! @ # $ % ^ & ‘ ) ( . - _ { } ~.

MS-RAS-Client-

Version

Number The operating system version that is installed on the remote access client. The

Vendor-Length of the Value field, including the vendor ID, vendor-type,

vendor-length, and value, must be at least 7.

Value, which specifies the version of the operating system on a remote access

client, is a string that is in network byte order.

Ai fini della tesi tutti i file di log elaborati dall’applicazione sono raggruppati in un’unica directory, il cui

indirizzo viene memorizzato in una tabella del database.

Nella seguente schermata viene mostrato un log generato dal server universitario del dipartimento DI3:

Figura 5 - Struttura di un log

Le dimensioni dei file variano ovviamente a seconda del numero di tentativi di autenticazione da parte degli

utenti: generalmente posso occupare da poche centinaia di kilobyte a decine di megabyte di spazio su

memoria di massa.

Page 18: Realizzazione di un' interfaccia web per la gestione dei file di log generati da un Web Server

18

3.2 Database

Il database è stato realizzato attraverso MySQL 5.5 con l’ausilio dell’interfaccia grafica MySQL Workbench

5.2 CE e del connettore all’ambiente .NET MySQL Connector Net 6.5.4.

Figura 6 - MySQL Workbench 5.2 CE

Il database è costituito da una tabella principale, contenente le informazioni importate dai file di log e da

tabelle di look-up per la descrizione di campi codificati.

Page 19: Realizzazione di un' interfaccia web per la gestione dei file di log generati da un Web Server

19

In Figura 6 viene mostrata la tabella principale; in Figura 7 la tabella per la descrizione del campo codificato

Reason-Code:

Figura 7 - Tabella descrizione campo Reason-Code

3.3 Software

E’ l’interfaccia che permette all’utente di interagire con i log. Realizzata in ambiente VISUAL STUDIO 2010

ULTIMATE, è divisa in due parti:

1. Pagina web

2. Codice

Rappresenta l’intermediario tra le richieste dell’utente e il database.

Page 20: Realizzazione di un' interfaccia web per la gestione dei file di log generati da un Web Server

20

Figura 8 - Ambiente Visual Studio 2010

3.3.1 Pagina web

Realizzata nel linguaggio ASP.NET, consiste in un’unica pagina web con elementi a comparsa, a seconda

delle scelte dell’utente.

Page 21: Realizzazione di un' interfaccia web per la gestione dei file di log generati da un Web Server

21

Figura 9 - Codice ASP.NET

Page 22: Realizzazione di un' interfaccia web per la gestione dei file di log generati da un Web Server

22

3.3.2 Codice

E’ la parte che soddisfa le richieste dell’utente; è stato realizzato in linguaggio C#.

Figura 10 - Codice C#

Page 23: Realizzazione di un' interfaccia web per la gestione dei file di log generati da un Web Server

23

4.Funzionamentodell’applicazione

In questo capitolo verrà descritto il funzionamento dell’applicazione, mostrando come i file di log, il

database e il software operano tra di loro.

4.1 Ricerca e caricamento log

Come già descritto in precedenza in ciascun file di log sono memorizzate le informazioni di determinate

mensilità. L’applicazione permette il caricamento dei file del periodo di interesse.

All’avvio viene eseguito un controllo sul database: se risulta vuoto viene mostrata automaticamente la

finestra che permette il caricamento del file di log che si desidera analizzare (Figura 11).

Figura 11 - Avvio con database vuoto

Una volta scelto il file desiderato parte l’esecuzione di tre test:

1. Integrità dei dati inseriti: semplice controllo che conferma l’inserimento di dati numerici, e

successivamente della validità degli stessi (ad esempio mese 13);

2. Esistenza del file nella directory;

3. Esistenza del file nel database, evitando quindi perdite di tempo per il caricamento.

Page 24: Realizzazione di un' interfaccia web per la gestione dei file di log generati da un Web Server

24

4.2 Analisi log e caricamento database

Se i test descritti nel paragrafo precedente hanno dato esito positivo il programma apre il file in modalità

lettura e ne analizza ogni riga. Ciascuna corrisponde ad un record della tabella del database. Su ogni

elemento prelevato si esegue un controllo:

• in caso di stringa di caratteri si esegue la copia;

• si fa una conversione nel tipo di dato previsto dallo standard (ad esempio numero intero, data e

ora);

• se il campo è vuoto, nel corrispondente campo del database comparirà il valore NULL.

Successivamente si esegue una conversione per le date: dal formato mm/gg/aaaa utilizzato dal server al

formato gg/mm/aaaa per poter essere elaborati dal database MySQL.

Al termine di questa elaborazione il programma avvia la query di inserimento nel database, caricando il

record nella tabella. Questo procedimento viene ripetuto per ogni riga del file. Il tempo richiesto da questa

operazione dipende dalle prestazioni del computer.

Figura 12 - Log caricato con successo

Al termine dell’operazione compare un messaggio di conferma, e viene data la possibilità di caricare nel

database un nuovo file di log relativo ad un altro periodo di interesse.

In Figura 13 si visualizzano i dati appena caricati.

Page 25: Realizzazione di un' interfaccia web per la gestione dei file di log generati da un Web Server

25

Figura 13 - Visualizzazione log appena caricato

4.3 Visualizzazione dei dati

La visualizzazione è uno degli aspetti più importanti dell’applicazione: deve dare all’utente una visione

pulita delle informazioni assistendolo con una descrizione per ogni elemento dell’interfaccia. Data la

numerosa presenza di campi con informazione nulla, ho deciso di visualizzarne solo un sottoinsieme, che

rappresenta le informazioni più significative. Per mezzo di un pulsante è comunque possibile visualizzare in

dettaglio i singoli record (Figura 14).

Nello specifico il formato di NPS prevede 66 campi, ma di questi solo 13 li ho ritenuti di interesse per lo

sviluppo dell’applicazione in quanto contengono informazioni su data, orari, utenti e dispositivi.

Page 26: Realizzazione di un' interfaccia web per la gestione dei file di log generati da un Web Server

26

Figura 14 - Dettaglio di un record del database

Come è possibile vedere dalla Figura 14, nella schermata vengono visualizzati al massimo dieci record, in

modo da avere una visione più ampia delle informazioni. Questa configurazione è stata scelta e realizzata

anche per un suo utilizzo su un dispositivo mobile.

4.4 Funzionalità

Le funzionalità dell’applicazione si posso raggruppare in tre macro aree:

• filtri sui campi del database;

• gestione degli archivi contenenti i file di log;

• gestione dei record del database (inserimento e cancellazione).

Page 27: Realizzazione di un' interfaccia web per la gestione dei file di log generati da un Web Server

27

4.4.1 Filtri sui campi del database

I filtri permettono di raggruppare le informazioni per utente, per data, per tipologia di pacchetto RADIUS

(request/response) oppure facendo combinazioni su più campi. Si dividono in due gruppi:

• filtri semplici

• filtri composti

4.4.1.1 Filtri semplici

Questo tipo di filtri permette di raggruppare le informazioni in base ai valori di un singolo campo.

In Figura 15, ad esempio, è stato applicato il filtro sull’utente “Fermeglia Maurizio”:

Figura 15 - Applicazione del filtro utente

In Figura 16 vengono visualizzati tutti i record in cui lo ‘User-Name’ non è registrato nel database del web

server:

Page 28: Realizzazione di un' interfaccia web per la gestione dei file di log generati da un Web Server

28

Figura 16 - Esempio di filtro su campo 'Reason-Code'

4.4.1.2 Filtri composti

Questi filtri coinvolgono più campi, ad esempio è possibile visualizzare gli utenti che hanno avanzato una

richiesta di autenticazione al server in determinati momenti della giornata, come mostrato in Figura 17:

Page 29: Realizzazione di un' interfaccia web per la gestione dei file di log generati da un Web Server

29

Figura 17 - Filtro per definiti orari di una giornata

4.4.2 Gestione degli archivi contenenti i file di log

L’applicazione permette tre operazioni riguardanti i file di log:

• Modificare l’indirizzo della directory sorgente (Figura 18)

• Visualizzare tutti i file presenti nella directory (Figura 19)

• Visualizzare i file caricati nel database (Figura 20)

L’indirizzo della nuova directory viene salvato in una apposita tabella del database.

Page 30: Realizzazione di un' interfaccia web per la gestione dei file di log generati da un Web Server

30

Figura 18 - Possibilità di cambiare la directory sorgente dei log

Figura 19 – Lista dei file presenti nella directory sorgente

Page 31: Realizzazione di un' interfaccia web per la gestione dei file di log generati da un Web Server

31

Figura 20 - Lista dei file caricati nel database

4.4.3 Operazioni sul database

Sul database è possibile eseguire le seguenti operazioni:

• Caricare file

• Cancellare tutti i record (reset)

• Cancellazione mirata di record (Figura 21)

L’ultima operazione da la possibilità di cancellare i soli record che rispettano determinati requisiti: ad

esempio tra due date oppure in un intervallo orario di una giornata.

Page 32: Realizzazione di un' interfaccia web per la gestione dei file di log generati da un Web Server

32

Figura 21 - Parametri per la cancellazione dei record

E’ importante sottolineare che i record vengono cancellati solo nel database, quindi in caso di eliminazione

accidentale posso essere recuperati dai file di log.

Page 33: Realizzazione di un' interfaccia web per la gestione dei file di log generati da un Web Server

33

5.Conclusioni

5.1 DIAMETER

Ritengo opportuno a fini di interesse e non per la tesi, introdurre un protocollo sviluppato per correggere i

punti deboli di RADIUS ed evolverne le caratteristiche: DIAMETER.

DIAMETER, come RADIUS, è un protocollo AAA: è costituito da un protocollo base (specificato nell’RFC

3588) e da un set di estensioni chiamato Applicazioni Diameter.

Questa progettazione gli permette di essere esteso a nuove tecnologie d’accesso. Il protocollo base fornisce

meccanismi di base per un trasporto affidabile e gestione degli errori; ogni applicazione si affida ai servizi

del protocollo base per supportare uno specifico tipo di accesso alla rete (cablato, wireless, ecc).

Prima di illustrare le caratteristiche del protocollo apro una parentesi veloce sui protocolli utilizzati per il

trasporto dei dati: UDP e TCP.

5.1.1 UDP (User Datagram Protocol)

Questo protocollo viene utilizzato da applicazioni che non necessitano trasferimenti affidabili di dati,

prediligendo la velocità: in questa maniera si evitano ad esempio ritardi nelle comunicazioni broadcast.

UDP quindi permette, grazie alla sua semplice struttura, trasferimenti più veloci e una minore complessità

dei sistemi che lo adottano.

UDP viene utilizzato da RADIUS.

5.1.2 TCP (Transfer Control Protocol)

L'utilizzo del protocollo TCP è, in generale, preferito quando è necessario avere garanzie sulla consegna dei

dati o sull'ordine di arrivo dei vari segmenti (come nel caso di trasferimenti di file).

TCP è un protocollo orientato alla connessione, ovvero prima di poter trasmettere dati deve stabilire la

comunicazione, negoziando una connessione tra mittente e destinatario, che viene esplicitamente chiusa

quando non più necessaria. Esso quindi possiede le funzionalità per creare, mantenere e chiudere una

connessione.

TCP viene utilizzato da DIAMETER.

Page 34: Realizzazione di un' interfaccia web per la gestione dei file di log generati da un Web Server

34

5.1.3 Miglioramenti rispetto a RADIUS

Sono diversi i motivi per cui si dovrebbe passare a DIAMETER; di seguito elenco i principali:

• La necessità di trasmettere informazioni con attributi più lunghi di 255 caratteri, che RADIUS non

supporta, o di inviare pacchetti di richiesta più lunghi del limite imposto da UDP;

• Il campo identificativo del pacchetto è un ottetto, cioè contiene un numero da 0 a 255; quindi si

possono rilevare dei problemi in caso di un elevato numero di richieste da un server di accesso;

• DIAMETER è più robusto per certe tipologie di attacchi;

• DIAMETER protegge l’intera connessione tra client e server, e non singole tratte (client-NAS e NAS-

server) come RADIUS.

Di contro il protocollo DIAMETER è più complesso di RADIUS e le macchine lo utilizzano richiedono un

insieme di risorse maggiore.

5.2 Possibili miglioramenti per l’applicazione

L’applicazione è stata progettata per sistemi non aventi grandi capacità di calcolo; è stata sviluppata su un

notebook HP 6730b avente le seguenti specifiche:

• Sistema Operativo Windows 7 Enterprise, Service Pack 1;

• Processore Intel(R) Core(TM) 2 Duo P8400 @2,26GHz;

• 4 GB di memoria;

Tuttavia la sua struttura modulare permette l’introduzione di altre funzionalità, che verranno elencate di

seguito.

5.2.1 Estensione a più dipartimenti

Il programma è stato progettato per gestire i log del server NPS di un solo dipartimento, ma è possibile

estendere il controllo a tutto il campus universitario. Tale operazione richiede un aumento della

complessità del database e delle procedure di recupero dati: non più un recupero in locale, ma una

gestione delle connessioni ai vari server dipartimentali.

Page 35: Realizzazione di un' interfaccia web per la gestione dei file di log generati da un Web Server

35

5.2.2 Gestione di più tipologie di log

Eseguendo poche modifiche al codice, il programma è in grado di analizzare tipologie di log aventi formati

diversi, provenendo quindi da server diversi che registrano informazioni in altri ambiti, permettendo

all’utente di avere più servizi integrati gestibili da un’unica interfaccia grafica.

5.2.3 Grafici di andamento

L’applicazione può essere integrata con l’inserimento di strumenti grafici di analisi; di seguito elenco delle

situazioni la cui analisi può essere migliorata per mezzo di essi:

• Richieste di autenticazione nelle varie fasce orarie di una giornata;

• Richieste di autenticazione nell’arco di settimane, mesi e anni;

• Richieste provenienti dai vari dipartimenti universitari;

• Richieste per tipologia di utenti (personale, studenti, ecc);

• Access-point più utilizzati per le connessioni;

• Rilevamento di problemi di autenticazione.

5.2.4 Connessione a vari database

Grazie sempre alla sua struttura modulare e al linguaggio di programmazione utilizzato (C#), l’applicazione

è in grado di registrare le informazioni su diversi tipi di database (Jet, MySQL, SQL Server), a seconda delle

varie esigenze.

5.3 Ambiente di sviluppo

Come ambiente di sviluppo è stato scelto Microsoft Visual Studio 2010 Ultimate. Le motivazioni che mi

hanno portato a fare questa scelta sono:

• Semplicità di utilizzo dell’ambiente;

• Possibilità di sviluppare molte tipologie di applicativi;

• Linguaggi di programmazione supportati;

• Ampia documentazione disponibile in internet.

Page 36: Realizzazione di un' interfaccia web per la gestione dei file di log generati da un Web Server

36

L’apprendimento delle funzionalità dei linguaggi di programmazione ASP.NET e C#, secondo me da

includere nel piano di studio della facoltà, è stato possibile grazie ai forum di discussione e dai siti internet

ufficiali:

• technet.microsoft.com/;

• www.aspitalia.com;

• www.html.it;

• Stackoverflow.com;