Servizi IT – Università di Cagliari

1. Servizi IT – Università di Cagliari

2. DRSI Divisione Reti (Via Marengo) Servizi Amministrativi (Rettorato) … Settore Web e Sistemi (Settore Fonia) Settore Posta Settore Reti

3. Settore Posta (1 Risorsa) • Implementazione, sviluppo, gestione e manutenzione di tutti i sistemi di posta elettronica: • 2 virtual domains ufficiali (unica.it, amm.unica.it); • 2 virtual domains in uso per altre strutture (greenfuture.unica.it, com.unica.it); • 1 virtual domain dedicato al personale esterno (servizi di portineria etc); • Server POP, IMAP, SMTP; • 2 interfacce webmail (amm ed unica); • Server dedicato all’antispam. • Gestione della parte relativa alla posta elettronica del server LDAP di Ateneo.

4. Settore Web e Sistemi (4 risorse) • Implementazione, configurazione e gestione webserver di Ateneo (esclusi contenuti); • Preparazione e configurazione server per altre strutture; • Implementazione, configurazione e gestione Moodle (esclusi contenuti); • Implementazione, configurazione e gestione streaming ; • Implementazione, configurazione e gestione server contenuti multimediali; • …

5. Settore Reti (3 risorse) • Implementazione, gestione fisica e logica e manutenzione della rete di Ateneo; • Implementazione, gestione e manutenzione delle due reti wireless (UniCAMente ed eduRoam); • Implementazione, gestione e manutenzione dei sistemi di controllo degli accessi e security dell’Ateneo (NAM, Firewall, …); • Implementazione, gestione e manutenzione del Datacenter di Ateneo (Via Marengo): • Cluster VOIP; • 90 VM in produzione; • Cluster in uso presso altre strutture; • Implementazione, gestione e manutenzione della SAN e del sistema di backup (Networker); • Implementazione, gestione e manutenzione del Firewall (Palo Alto Networks PA-5050);

6. Implementazione, gestione e manutenzione del server di gestione degli accessi (LDAP, esclusa posta elettronica); • Implementazione, gestione e manutenzione dell’Identity Provider di Ateneo e di due Service Provider interni (di cui al momento uno in test e l’altro in produzione); • Implementazione (lato networking) aule didattiche e laboratori.

7. DATACENTER VIA MARENGO

8. Sistemi Operativi (Datacenter Via Marengo) 121 macchine virtuali, al momento circa 0.5 PB di spazio nel datacenter (1 PB ≈ 1000 TB ≈ 106 GB) 23 macchine con a bordo Windows Server (2008-2012) 98 macchine con a bordo Linux (Debian – RHEL – Ubuntu)

9. Rete GARR attuale GARR-X

10. UniCA: Backbone e Firewall

11. Benefits studenti • Gli studenti dell'Università di Cagliari beneficiano di alcune risorse, sia realizzate espressamente dalla DRSI-Divisione Reti, sia ottenute grazie alla Divisione Servizi da alcune software houses. • Gestione della propria carriera; • Account e-mail su dominio studenti.unica.it (gestito da Microsoft); • Accesso al Wi-Fi interno (UNICAMENTE) e federato (eduRoam); • Utilizzo di piattaforme di e-learning e di streaming; • Accesso alle principali banche dati bibliografiche dall'esterno della rete di ateneo mediante autenticazione federata (Shibboleth); • (DVD Live Ubuntu custom); • (Blog/forum con accesso via Shibboleth); • Accesso (previa registrazione) a Microsoft Dreamspark: http://dreamspark.com/Student/Software-Catalog.aspx e download gratuito di OS, ambienti di sviluppo e manuali MS; • Sconti nell'acquisto di Windows 8.1 e di Office 365: http://www.microsoft.com/student/it-it/default.aspx; • Download di prodotti Autodesk full (richiede registrazione): http://www.autodesk.com (seguire “sign in” e quindi “education”)

12. Wifi Network proprietario dell’Università di Cagliari, fornisce la copertura Wireless dei campus dislocati all’interno delle aree metropolitane di Cagliari e Monserrato. La struttura di tipo misto Wired-Wireless (rame – fibra ottica – etere) ha consentito alla nuova wireless di diffondersi come naturale espansione della rete tradizionale. L’accesso avviene mediante autenticazione web attraverso una procedura di autenticazione centralizzata basata sui protocolli e servizi IEEE 802.1x, Radius ed LDAP, che ne permette la massima fruibilità. Ammessi solo i protocolli http/https.

13. Wifi eduRoam (education Roaming) offre un servizio di accesso in modalità world-wide roaming appositamente pensato per la comunità dell’istruzione superiore e della ricerca. eduRoam permette a studenti, ricercatori e personale degli enti membri di ottenere connettività wifi tanto nei campus del proprio ateneo, quanto in quelli delle altre istituzioni partecipanti alla federazione in maniera semplice e sicura. L’accesso avviene mediante la stessa procedura di autenticazione centralizzata basata sui protocolli e servizi IEEE 802.1x, Radius ed LDAP e gli stessi criteri della rete proprietaria UNICAMeNTe, ma a differenza di quest’ultima non utilizza il web access. La rete è disponibile in quasi tutti i paesi occidentali, oltre a Turchia, Giappone, Corea, PRC, Kirgizistan, India, Australia e Nuova Zelanda, alcuni paesi sudamericani ed alcuni africani. La struttura avanzata delle configurazioni di sicurezza da noi adottate non permettono tuttavia l’accesso diretto ad alcuni OS (Windows, Windows Phone) ed è perciò necessario installare un software apposito distribuito dalla nostra Direzione.

14. Accesso a risorse per mezzo di autenticazione federata • SITUAZIONE DI PARTENZA: • Lato utente: • per ogni servizio, una coppia di credenziali; • Facilità di smarrimento o dimenticanza; • Difficoltà di recupero di eventuali credenziali smarrite; • Rischio di utilizzare password o codici banali e facilmente identificabili con un minimo di ingegneria sociale o non resistenti ad attacchi del tipo «forza bruta» (con o senza dizionario). • Lato organizzazione di appartenenza: • Elevati costi per la gestione delle utenze; • Scarso o difficile controllo dei processi di autenticazione e autorizzazione. • Lato fornitore di servizi: • Gravoso carico amministrativo per la gestione di identità e credenziali; • Difficoltà ad estendere il proprio bacino d’utenza.

15. Single Sign On • VANTAGGI: • Lato utente: • Riduzione del numero di password da ricordare; • Semplificazione dell’accesso alle risorse online, indipendentemente dal luogo in cui ci si trova. • Lato organizzazione di appartenenza: • Riduzione dei costi per la gestione delle utenze e per la realizzazione di nuovi servizi; • Maggior controllo dei processi di autenticazione e autorizzazione. • Lato fornitore di servizi: • Riduzione del carico amministrativo per la gestione di identità e credenziali; • Possibilità di estendere il proprio bacino d’utenza. • STRUMENTI: • Athens; • CAS; • Shibboleth.

16. Single Sign On • Shibbboleth è un pacchetto software open source e standardizzato che ha per obbiettivo il web Single Sign On, molto ricco per quello che riguarda lo scambio degli attributi, basato su standards aperti tra cui, prevalentemente, SAML2. • E’ un sistema federato che supporta l’accesso sicuro a risorse attraverso il web: le informazioni relative all’utente vengono trasmesse dall’Identity Provider (IdP) aziendale al Service Provider (SP) esterno che le prepara per la protezione dei dati sensibili e per l’utilizzo da parte delle applicazioni. Schema di autenticazione

17. Single Sign On l’utente richiede la connessione ad una risorsa protetta facendo sì che il SP intercetti la richiesta (la risorsa da proteggere è definita nei files di configurazione del web server che la ospita); il SP, basandosi sulla configurazione di cui sopra, determina a quale IdP far riferimento e quale protocollo utilizzare attraverso un meccanismo di “scoperta” noto come servizio WAYF (acronimo di Where Are You From): la richiesta di autenticazione è così delegata al WAYF che la passa all’IdP selezionato dall’utente; come risultato delle azioni precedenti, una richiesta di autenticazione via browser è inviata dal SP all’IdP selezionato dall’utente: l’IdP decide se l’utente può autenticarsi e quali attributi inviare al SP: scelta, questa, basata prevalentemente sulle caratteristiche del SP che fornisce il servizio e su quelle degli attributi principali dell’utente ricavati a seguito di una query sul server LDAP; l’IdP impacchetta e firma i dati che trasmette sotto forma di asserzione SAML al SP che la spacchetta e la decodifica eseguendo poi una serie di controlli di sicurezza per decidere infine se il richiedente abbia o meno diritto di accesso alla risorsa desiderata; infine, se il processo di verifica del punto precedente ha esito positivo, l’utente viene finalmente rediretto alla risorsa richiesta. L’Universita di Cagliari ha aderito alla fase pilota del progetto sin dalla sua nascita avvenuta nel 2008 ed ora, dal marzo 2010, è a pieno titolo membro della Federazione IDEM-GARR-AAI, mettendo a disposizione un IdP per l’accesso ai servizi offerti dalla Federazione ed avendo costruito un SP (al momento interno) in maniera da diventare anche fornitore di servizi e non soltanto fruitore. Dal 2103 è membro a pieno titolo dell’interfederazione europea eduGAIN. E’ rappresentata nell’Assemblea della Federazione dall’Ing. Roberto Porcu in qualità di referente organizzativo e dal Dott. Stefano Manfredda in qualità di referente tecnico.

18. Single Sign On • Federazione di identità: insieme di organizzazioni (università, enti di ricerca, scuole, comuni, …) associate al fine di accedere a risorse e condividere risorse sulla base di rapporti di fiducia reciproca fondati su: • Tracciabilità degli accounts; • Condivisione della profilatura degli utenti. • Alcune Federazioni: • IDEM-GARR (I); • SWITCH (CH); • BELNET (B); • UNIVERSITES ET GRANDES ECOLES (F); • UK FEDERATION (UK); • In-Common (USA); • CERNET (Cina); • … • SERVIZI E CONTENUTI ACCESSIBILI TRAMITE LA FEDERAZIONE IDEM: • servizi di biblioteca digitale: banche dati, articoli full text, document delivery; • servizi di e-learning; • strumenti di community (wiki e blog); • servizi di prenotazione e teleconferenza; • …

19. Single Sign On • Dall’ottobre 2013, nei profili LDAP degli studenti, oltre ai seguenti attributi standard: • ou Attributo descrittivo dell’Ateneo • uid Nome utente • cn Nome e cognome dell’utente • givenName Nome di battesimo dell’utente • sn Cognome dell’utente • email Indirizzo e-mail dell’utente • employeeNumber Numero di matricola dell’utente • userPassword Password (criptata) dell’utente • sono stati inseriti anche alcuni di quelli appartenenti alle objectClass eduPerson e schacContactLocation ed in particolare: • preferredLanguage Lingua preferita dall’utente (madrelingua) • eduPersonEntitlement Abilitazioni particolari • eduPersonPrincipalName Attributo “scoped” derivato dall’uid • eduPersonAffiliation Grado di affiliazione all’interno dell’organizzazione • eduPersonScopedAffiliation Scoped derivato dal precedente • eduPersonTargetedID Attributo che permette la gestione di sessioni in forma anonima • schacHomeOrganization Attributo scoped dell’ente di appartenenza • schacHomeOrganizationType Attributo che identitfica il tipo di ente di appartenenza • l Luogo di residenza • st Provincia di residenza • Servizi accessibili agli studenti mediante autenticazione federata e dunque anche dall’esterno della rete di Ateneo: • Banche dati bibliografiche (v. elenco in • Servizi eduGAIN; • Servizi di e-learning (in fase di sviluppo); • Servizio di blog - forum (ultimato e funzionante ma non ancora pubblicato).

20. Single Sign On Esempio di profilo LDAP (studenti) utilizzato dal server Shibboleth

21. VPN – Virtual Private Network L’università di Cagliari fornisce ai suoi utenti la possibilità di accedere alle sue risorse – o a risorse esterne normalmente accessibili dall’interno della rete di Ateneo – anche da fuori: per esempio da casa o da apparati mobili (smartphones, tablet). Un tempo, parlando in generale, tale obbiettivo era raggiunto mediante la creazione e l’utilizzi di reti private che ampliavano il cosiddetto perimetro di sicurezza dell’azienda o dell’ente in maniera da includere anche eventuali sedi periferiche; per esempio, fino ad una decina di anni orsono gli stabilimenti del gruppo COMAU erano tutti nella stessa rete privata che era strutturata in maniera da poter includere non solo i quattro nella periferia torinese, ma anche quelli delle sedi francese, tedesca, rumena, marocchina, russa e sudafricana dell’azienda.

22. Reti private: pro e contro • PRO: • Estensione all’intera area aziendale del perimetro di sicurezza; • Isolamento fisico della rete dal resto del mondo: la comunicazione all’interno dell’azienda è fisicamente isolata dal resto del mondo e le comunicazioni extra-aziendali avvengono tramite gli apparati in DMZ (De-Militarized Zone) e da questi verso internet (congruente al principio in base al quale «la miglior difesa è la distanza», distanza dal potenziale aggressore) • CONTRO • Elevati costi per l’infrastruttura fisica; • Elevate esigenze di manutenzione e controllo con relativi costi; • Scarsa o comunque costosa scalabilità; • Vulnerabilità a tecnologie di intercettazione su cavo che non creino interferenze.

23. VPN: un diverso approccio Obbiettivo: costruire una rete che sia: Diffusa fino al livello più capillare; Economica; Scalabile; Indipendente dall’ubicazione geografica dell’accesso; Sicura almeno quanto una rete privata. La risposta alle prime 4 domande è Internet, che però non soddisfa in alcun modo la richiesta di sicurezza (in internet il potenziale aggressore non è distante, è contiguo e la difesa diventa un concetto asimmetrico: il difensore è potenzialmente solo contro tutti). La soluzione al problema è la RETE PRIVATA VIRTUALE o VPN. Rete privata: sicura e non accessibile dall’esterno VPN Virtuale: sfrutta un’infrastruttura insicura (internet) garantendo la sicurezza per mezzo di collegamenti privati, sicuri e logicamente separati dal resto di internet

24. VPN: un diverso approccio Impiego di protocolli di tunneling e di sistemi di cifratura avanzata dei dati al fine di riprodurre il livello di sicurezza delle reti private

25. VPN: un diverso approccio • Vantaggi: • Riservatezza delle informazioni mediante cifratura: Il mittente può cifrare i pacchetti dei dati prima di trasmetterli attraverso la rete. Così facendo, nessuno può accedere alla comunicazione senza autorizzazione. E se vengono intercettate, le comunicazioni non possono essere lette e comprese: • Integrità dei dati: il ricevente può verificare con dei meccanismi di hashing (di firma elettronica dei dati) che i dati sono stati trasmessi attraverso Internet senza essere stati alterati; • Autenticazione dell’origine: il ricevente può autenticare la sorgente del pacchetto, garantendo e certificando dopo la verifica la sorgente delle informazioni. Questo permette un accesso remoto sicuro. • L’autenticazione può essere ulteriormente distinta in: • Device authentication • User authentication • Riduzione dei costi: le VPN riducono in maniera profonda i costi di mantenimento di una rete sicura perché usano Internet come infrastruttura di collegamento site-to-site di accesso remoto; • Miglioramento delle comunicazioni: con le VPN, gli utenti remoti (sedi distaccate, road warriors, telelavoratori, clienti, fornitori e partner negli affari) si possono connettere in sicurezza da qualunque posto e in ogni tempo 24 ore su 24 alle risorse della rete sicura o tra di loro; • Flessibilità e Scalabilità: le VPN hanno una flessibilità e una capacità di scalare che le linee affittate non hanno. L’implementazione di una VPN semplifica e centralizza l’amministrazione delle reti. Una infrastruttura di VPN può adattarsi con facilità alle necessità di cambiamento delle reti; • Sicurezza ed Affidabilità: utilizzo protocolli di tunneling e cifratura avanzata. Ridotto numero di punti di entrata, un punto di entrata ed un punto di uscita (topologia a tunnel, quindi estremamente semplice: • Indipendenza dagli standard tecnologici dei primi due livelli dalla pila OSI: garantisce che una rete non sia vulnerabile alle caratteristiche di debolezza dei primi due livelli. (V. sotto: descrizione degli strati della pila OSI).

26. Cenni sul networking Requisiti fondamentali di una rete: • ELEVATA DISPONIBILITA’: la rete deve essere accessibile sempre; • RIDONDANZA: la rete deve essere progettata in maniera tale che se uno degli apparati che la costituiscono si guasta, il traffico possa essere dirottato attraverso un altro apparato senza – per quanto possibile – che gli utenti se ne accorgano; • SCALABILITA’: la rete deve essere progettata in maniera tale da prevederne la crescita futura; in genere si considera standard una previsione di crescita almeno del 20%; • GESTIBILITA’: è requisito base per l’efficienza di una rete e comprende attività come deployment, configurazione, monitoraggio e troubleshooting. Il modello OSI (Open Systems Interconnection), o pila ISO/OSI, è uno standard per reti di calcolatori stabilito nel 1978 dall'International Organization for Standardization (ISO) che stabilisce per l'architettura logica di rete una struttura a strati composta da una pila di protocolli di comunicazione suddivisa in 7 livelli, i quali insieme espletano in maniera logico-gerarchica tutte le funzionalità della rete. La pila OSI

27. Modello OSI Definisce i processi di comunicazione tra applicazioni per lo scambio di dati o la creazione di connessioni remote(e-mail, ftp, file, pagine web) Definisce i codici usati nella comunicazione: formattazione, compressione e/o criptaggio dei dati Gestisce (apertura, chiusura e sincronizzazione) sessioni multiple tra applicazioni Definisce le tecniche di frammentazione e ricostruzione dei messaggi in altri di dimensioni minore (pacchetti) e per il controllo di errore Definisce le tecniche di instradamento (routing) dei pacchetti Definisce il formato dei frame scambiati all'interno della medesima rete e la modalità di accesso al mezzo fisico Definisce l'infrastruttura di una singola rete: topologia, hardware delle apparecchiature e cablaggio

28. Modello OSI

29. Modello OSI

30. TCP/IP • Il TCP/IP (Transmission Control Protocol/Internet Protocol) è una suite di protocolli che definisce l'insieme delle regole di comunicazione su internet e si basa sulla nozione di indirizzamento IP, cioè il fatto di fornire un indirizzo IP ad ogni terminale di rete per poter inviare dei pacchetti di dati. • Dato che la serie protocollare TCP/IP è stata creata in origine per scopi militari, essa è concepita per rispondere ad un certo numero di criteri fra i quali : • Il frazionamento dei messaggi in pacchetti ; • L'uso di un sistema di indirizzi ; • L'invio di dati sulla rete (routing) ; • Il controllo degli errori di trasmissione di dati. • Indirizzo IP: • assegnato manualmente; • Assegnato automaticamente da un DHCP server.

31. TCP/IP rappresenta l'interfaccia con l'utente ed abilita, ad esempio, la consultazione di pagine web, stabilendo e gestendo le sessioni di lavoro dei processi tra il browser ed il server web o l'invio e la ricezione di messaggi di posta elettronica, stabilendo e gestendo le sessioni di lavoro dei processi tra il nostro client ed il mailserver mette in coda i messaggi generati da client e server e li trasmette sotto forma di pacchetti su di una connessione full-duplex; il buon fine della spedizione è attestato da una ricevuta di ritorno o riscontro. gestisce l'indirizzamento dei nodi e l'instradamento. A ciascun nodo viene assegnato un indirizzo IP che lo identificherà in modo non ambiguo in rete. L’instradamento consente di selezionare il percorso migliore verso un dato nodo destinatario, noto il suo indirizzo IP specifica solo che ci deve essere un livello host-to-network in grado di spedire i pacchetti IP (nel modello ISO/OSI questo strato corrisponde ai primi due livelli: il livello di collegamento e il livello fisico). Al livello di collegamento si decide come fare il trasferimento del messaggio per ogni singolo tratto del percorso: dal computer al primo router, dal primo router al secondo, dal secondo al terzo ... fino al server. Anche in questo caso le interfacce di comunicazione dei nodi adiacenti saranno individuate per mezzo di un indirizzo univoco, usualmente denominato indirizzo MAC. Il livello fisico, trasmette il messaggio sul canale di comunicazione usualmente sotto forma di segnali elettrici o elettromagnetici.

32. DHCP (Dynamic Host Configuration Protocol) • La procedura descritta dal protocollo consta di diversi handshake tra client e server, ovvero scambio di pacchetti, tutti incapsulati in frame di livello datalink • il client invia un pacchetto chiamato DHCPDISCOVERin broadcast, con indirizzo IP sorgente messo convenzionalmente a 0.0.0.0, e destinazione 255.255.255.255 (indirizzo di broadcast). • Il pacchetto è ricevuto da tutto il dominio di broadcast e in particolare da tutti i server DHCP presenti, i quali possono rispondere (o meno) ciascuno con un pacchetto di DHCPOFFER in cui propongono un indirizzo IP e gli altri parametri di configurazione al client. Questo pacchetto di ritorno è indirizzato direttamente all'indirizzo di livello datalink del client (che non ha ancora un indirizzo IP) cioè in unicast, per cui può essere inviato solo da un server che si trovi sullo stesso dominio di broadcast. • Il client aspetta per un certo tempo di ricevere una o più offerte, dopodiché ne seleziona una, e invia un pacchetto di DHCPREQUEST in broadcast, indicando all'interno del pacchetto, con il campo "server identifier", quale server ha selezionato. Anche questo pacchetto raggiunge tutti i server DHCP presenti sulla rete (direttamente o tramite un relay). • Il server che è stato selezionato conferma l'assegnazione dell'indirizzo con un pacchetto di DHCPACK (nuovamente indirizzato in unicast all'indirizzo di livello datalink del client, possibilmente attraverso un relay); gli altri server vengono automaticamente informati che la loro offerta non è stata scelta dal client, e che sulla sottorete è presente un altro server DHCP. • A questo punto, il client è autorizzato a usare l'indirizzo ricevuto per un tempo limitato, detto tempo di lease. Prima della scadenza, dovrà tentare di rinnovarlo inviando un nuovo pacchetto DHCPREQUEST al server, che gli risponderà con un DHCPACK se vuole prolungare l'assegnazione dell'indirizzo. Questi sono normali pacchetti IP unicast scambiati tra due calcolatori che hanno indirizzi validi. Se il client non riesce a rinnovare l'indirizzo, tornerà allo stato iniziale cercando di farsene attribuire un altro.

33. Tipi di indirizzamento e furti Laddove sia possibile, è preferibile utilizzare l’indirizzamento automatico via DHCP server, eventualmente escludendo alcuni indirizzi che è meglio non cambino nel tempo, come quelli di stampanti di rete, eventuali fileserver locali, … , etc. La gestione di pool di indirizzi fissi è sicuramente più complessa ed onerosa rispetto all’indirizzamento automatico: comporta la perdita di parecchio tempo nel mantener aggiornate tabelle che riportano le generalità del titolare dell’indirizzo, la sua mail, il MAC della macchina, ed altro, ma soprattutto presenta la non indifferente criticità – dal pdv della sicurezza - legata a cessioni arbitrarie della macchina e/o dell’IP, cambi di PC o anche solo di scheda di rete, oltre al non infrequente pericolo di furto di IP. Per quanto possa sembrare inutile burocrazia, la gestione di pool di IP fissi richiede di necessità la conoscenza dei dati del titolare: assai più spesso di quanto piaccia fare, tocca rispondere a fax inviati dalla Polizia Postale su richiesta della magistratura nel corso di indagini su crimini informatici o sospetti tali. Al momento presso l’Università di Cagliari la situazione è mista, almeno per quanto riguarda la rete cablata: la maggior parte dei poli è configurata con indirizzo fisso, mentre solo alcuni (tra cui gli istituti biologici di Ponte Vittorio e la Cittadella dei Musei, aule informatiche e laboratori) sono in DHCP con autenticazione. L’obbiettivo per il prossimo futuro è la copertura totale dei poli via DHCP con autenticazione, ma il problema è squisitamente ‘’politico’’ oltre che economico. Per la rete wireless gli indirizzi sono assegnati dal DHCP server a seguito di autenticazione dell’utente (credenziali di posta per gli utenti AMM e RTSC, credenziali di Esse3 per gli studenti, credenziali temporanee rilasciate appositamente, per gli utenti temporanei quali partecipanti esterni a convegni, personale di altri atenei/enti di ricerca non membri di eduRoam. I visitatori i cui enti di appartenenza sono membri di eduRoam, utilizzano le loro credenziali native).

34. Tipi di indirizzamento e furti In caso di furto di indirizzo IP, solitamente le contromisure consistono nello spegnimento della porta dello switch su cui il ‘’ladro ‘’ è collegato, o – quando ciò non sia possibile (per esempio perché su quella porta sono collegati più utenti) - mediante drop sullo switch più prossimo o sul centro-stella del suo MAC, rendendogli così impossibile la navigazione entro la rete di Ateneo. Nei casi peggiori, quando il furto è segnalato in ritardo o il ‘’ladro’’ si scollega prima che il suo MAC sia identificato, si procede al blocco dell’IP sul firewall ed all’assegnazione di un altro indirizzo alla ‘’vittima’’. *esempio di collegamento allo switch*

35. Risoluzione dei nomi Per poter accedere ad una risorsa in internet è necessario raggiungere la macchina che la ospita; per esempio, se si vuole fare una ricerca su google, occorrerà raggiungere la pagina di ricerca ospitata sul webserver di google. A tale scopo, siamo abituati a scrivere l’URL che ci interessa sulla barra degli indirizzi del browser ed alla pressione del tasto invio, in maniera per noi assolutamente trasparente, avremo raggiunto la pagina che ci interessa. Ma il TCP/IP ignora totalmente il significato della stringa alfanumerica ‘www.google.it’, dato che opera unicamente su indirizzi IP, al livello più alto e su MAC ai livelli inferiori. Il problema, dunque, è come tradurre in indirizzi IP le stringhe alfanumeriche che costituiscono le URL che siamo abituati a chiamare con il browser (vale la stessa cosa quando spediamo una mail: nel client abbiamo configurato i FQDN dei nostri server di invio e ricezione della posta, dei quali ignoriamo totalmente – o quasi – l’indirizzo IP). A tradurre le URL o i FQDN in indirizzi IP oggi ci pensano i nameserver o DNS (Domain Name Server) mentre un tempo tale compito era demandato al file hosts residente su ciascun PC (con il crescere del numero di dispositivi connessi alla rete, l’utilizzo dei file hosts è risultato impossibile per ovvie ragioni ed oggi si usano solo eventualmente per le reti private di piccole dimensioni). Il file hosts altro non è se non un file di testo contenente una serie di associazioni hostname < > IP – prevalentemente per reti locali. Per esempio: 127.0.0.1 localhost 127.0.0.1 calliope 10.2.2.100 antigone 10.2.2.102 ismene 10.2.2.103 tersicore 10.2.2.104 calliope 10.20.0.5 vc1-u1.virtual.zone 10.20.0.6 vc1-vum1-u1.virtual.zone 10.20.0.50 esx1-u1.virtual.zone 10.20.0.51 esx2-u1.virtual.zone …

36. Risoluzione dei nomi • Ovviamente l’attuale situazione rende impraticabile l’uso dei file hosts se non per reti private di piccole dimensioni e si utilizza la risoluzione automatica dei nomi tramite server DNS. • L’indirizzo del DNS primario e di quello di backup per un dato dominio è configurato automaticamente dal DHCP, se l’indirizzamento è automatico, o va inserito a mano nella tabella di configurazione dell’IP nel caso di assegnazione manuale. • Il meccanismo di traduzione, trasparente rispetto all’utente finale, è il seguente: • Il PC dell’utente invia una richiesta di traduzione da nome (hostname o url) ad indirizzo IP al server DNS di riferimento; • Il DNS consulta i suoi files di configurazione (o «di zona») e, se trova la traduzione, permette l’instradamento della richiesta; • Se non trova la traduzione, possiede comunque l’indirizzo di un server DNS di livello superiore al quale trasferisce la richiesta; • Nella peggiore delle ipotesi, si ‘’scala’’ la catena fino a raggiungere uno dei circa 12 root nameservers che sicuramente ha l’IP del nameserver autoritativo per quella zona e gli trasferisce la richiesta; la risposta torna al PC dell’utente seguendo la stessa catena dell’andata. Supponiamo per esempio che un PC collegato alla rete dell’Università di Cagliari debba contattare per qualche motivo il server debian.mines.inpl-nancy.fr Il nome in sé non ci dice molto, se non che il server cui vogliamo accedere si trova in Francia, a Nancy ed all’Ecole des Mines di quella città, tutte cose che già sapevamo prima di connetterci. Il percorso che la nostra richiesta di risoluzione compie è indicato nelle due successive slides.

37. Risoluzione dei nomi

38. Risoluzione dei nomi

39. Principali protocolli Per protocollo di rete (o anche protocollo di comunicazione) si intende la definizione formale a priori delle modalità di interazione che, due o più apparecchiature elettroniche collegate tra loro, devono rispettare per operare particolari funzionalità di elaborazione necessarie all'espletamento di un certo servizio di rete. Si tratta dunque della descrizione a livello logico del processo di comunicazione (meccanismi, regole o schema di comunicazione) tra terminali e apparati preposto al funzionamento efficace della comunicazione in rete. Ciascun protocollo è descritto in una o più RFC /Request For Comments), rese poi standard dalla IETF. Le RFC documenti che riportano informazioni o specifiche riguardanti nuove ricerche, innovazioni e metodologie dell'ambito informatico o, più nello specifico, di Internet. Attraverso l'Internet Society gli ingegneri o gli esperti informatici possono pubblicare dei memorandum, sotto forma di RFC, per esporre nuove idee o semplicemente delle informazioni che una volta vagliati dall'IETF possono diventare degli standard Internet. In riferimento alla pila OSI, i principali protocolli di uso comune sono Livello 7: applicazione Protocolli di servizio: Dynamic Host Configuration Protocol - (DHCP) Domain Name System - (DNS) Network Time Protocol - (NTP) Lightweight Directory Access Protocol - (LDAP)

40. Principali protocolli Protocolli di accesso a terminali remoti: Telnet Secure shell - (SSH) Protocolli usati per realizzare il servizio di posta elettronica e newsgroup: Simple Mail Transfer Protocol (SMTP) Post Office Protocol (POP) Internet Message Access Protocol (IMAP) Network News Transfer Protocol (NNTP) Protocolli di trasferimento file: File Transfer Protocol - (FTP) Hyper Text Transfer Protocol - (HTTP) Internet Relay Chat - (IRC)

41. Esempi live collegamento centro stella, show, ricerca porte, blocco IP, shut sporta Esempi live sessioni ldap, ftp, ssh, pop, smtp, http (wget)

42. Schema apparati Via Marengo

43. Schema apparati DIGITA

44. Grazie dell’attenzione Indirizzi ed url utili stefano@unica.it settorereti@unica.it Idem-help-studenti@unica.it http://people.unica.it/settorereti http://people.unica.it/wifi http://people.unica.it/idem