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

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

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

3

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

4

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

5

2. La gestione delle autenticazioni

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).

6

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.

7

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;

8

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à

9

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.

10

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.

11

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.

12

3. Struttura dell’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.

13

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- Text The user name in canonical format (this is an IAS-internal attribute).
Distinguished-
Name
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- Text The friendly name for the RADIUS client (this is an IAS-internal attribute).
Name
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- Number The authentication scheme, which is used to verify the user and can be:
Type

14

1 = PAP

2 = CHAP

3 = MS-CHAP

4 = MS-CHAP v2

5 = EAP

7 = None

8 = Custom


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


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.

15

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- Text The friendly name of the EAP-based authentication method that was used by
Name 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- Number The number of octets sent during the session.
Octets
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- Number The number of packets sent during the session.
Packets
Acct-Terminate- Number The reason that a connection was terminated.
Cause
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- Number The length of interval (in seconds) between each interim update that the
Interval network access server sends.
Tunnel-Type Number The tunneling protocol to be used.

Tunnel-Medium- Number The medium to use when creating a tunnel for protocols. For example, L2TP
Type packets can be sent over multiple link layers.
Tunnel-Client- Text The IP address of the tunnel client.
Endpt
Tunnel-Server- Text The IP address of the tunnel server.
Endpt
Acct-Tunnel-Conn Text An identifier assigned to the tunnel.

Tunnel-Pvt-Group- Text The group ID for a specific tunneled session.
ID
Tunnel- Text The tunnel to which a session is assigned.
Assignment-ID
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- Number A Routing and Remote Access service attribute. For more information, see RFC
Type 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- Number A Routing and Remote Access service attribute. For more information, see RFC
Encryption-Types 2548.
MS-MPPE- Number A Routing and Remote Access service attribute. For more information, see RFC
Encryption-Policy 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- IP address The IP address of the remote RADIUS server to which the connection request
Address was forwarded for authentication.
"CLIENTCOMP" MS-RAS-Client- Text The name of the remote access client. The Vendor-Length of the Value field,
Name including the vendor ID, vendor-type, vendor-length, and value, must be at

16

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- Number The operating system version that is installed on the remote access client. The
Version 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.

17

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.

18

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.

19

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.

20

Figura 9 - Codice ASP.NET

21

3.3.2 Codice

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

Figura 10 - Codice C#

22

4. Funzionamento dell’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.

23

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.

24

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.

25

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).

26

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:

27

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:

28

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.

29

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

Figura 19 – Lista dei file presenti nella directory sorgente
30

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.

31

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.

32

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.

33

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.

34

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.

35

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;

36

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

More Related Content

Similar to Realizzazione di un' interfaccia web per la gestione dei file di log generati da un Web Server (20)

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