La traccia della seconda simulazione del 2 aprile 2019 è oggettivamente più semplice della precedente dello stesso anno, vista e corretta anche su questo sito, sia per la componente informatica che per la parte di sistemi e reti. Vediamo una possibile soluzione con varie considerazioni che possono aiutare l’alunno ad orientarsi nella stesura di una prova analoga. La trattazione è volutamente discorsiva e, come sempre, è una delle possibili soluzioni che rispondono alla specifica.
Il sistema che andiamo ad analizzare è quella di un treno a bordo del quale sono coinvolti due attori principali: il controllore e il passeggero. Il controllore ha fondamentalmente la funzione di controllare/registrare ed annotare alcuni dati riguardanti i biglietti mentre il passeggero può guardare in streaming dei contenuti multimediali.
Come in tutte le tracce dobbiamo individuare alcune condizioni iniziali in cui vogliamo sviluppare la nostra soluzione.
Innanzi tutto il treno è un veicolo in movimento ad alta velocità; il percorso che compie, ci dice il testo, è spesso eterogeneo per quanto riguarda la conformazione del territorio che rende difficili determinate tipologie di intercomunicazione. Questo già ci mette nelle condizioni di non poter utilizzare alcun tipo di connessione cablata tra treno ed altra infrastruttura a terra. La stessa conformazione del territorio ci quasi obbliga a scegliere delle connessioni wireless ma da scegliere con attenzione. Non ci risulta che la rete ferroviaria abbia una sua struttura proprietaria di connessione wireless lungo i binari/tragitto anche perché implicherebbe un numero consistente di ponti radio lungo tutta la rete ferroviaria con costi di installazione e gestione decisamente proibitivi. Occorre utilizzare soluzioni che semplifichino il sistema e, ovviamente, la nostra trattazione sfruttando infrastrutture esistenti a cui integrare le nostre specifiche.
Innanzi tutto vediamo come fornire la connessione wireless all’interno delle cabine. Ricordiamo che il wireless nasce come sistema di comunicazione per reti locali, le cosiddette LAN. Spesso, in gergo comune, wireless è associata al possibilità di navigare su internet ma è solo un servizio aggiuntivo allo scopo iniziale della tecnologia in questione. Il lettore provi ad immaginare una rete senza fili nella propria casa ma non connessa ad internet: tutti i dispositivi connessi potrebbero comunque interagire tra di loro, ad esempio con un videogioco in LAN-party, molto diffusi tra i nostri alunni.
Indice dei contenuti
La rete WiFI
Dimensionare una rete wireless richiede poche semplici regole. Ogni cabina dovrebbe essere dotata di uno un access point da posizionare possibilmente al centro sul soffitto del vagone. L’access-point è collegato con un cavo Ethernet ad uno switch o hub posto all’inizio della cabina, possibilmente con tecnologia PoE o PoE+, Power Over Ethernet, che oltre a trasportare il segnale, trasporta una alimentazione per il dispositivo collegato che varia tra i 15 watt circa e i 30 watt per la versione plus. Occorre un cavo quindi per collegare l’AP alla cabina precedente ed uno proveniente dallo switch che propaga il segnale Ethernet fino alla successiva cabina e il suo switch/hub. Quest’ultimo collegamento deve essere realizzato con un cavo cross visto che stiamo collegando apparati dello stesso tipo/livello. Alcuni AP, hanno una doppia interfaccia che permetterebbe in caso il collegamento a cascata ingresso/uscita. In questo secondo caso, occorre comunque inserire uno switch o repeater nel vagone successivo poiché la potenza del segnale PoE non è tale da alimentare in cascata più apparati. Si da per scontato che tra un vagone e l’altro si possa opportunamente stendere un cavo Ethernet assieme a quelli che trasportano l’alimentazione della cabina stessa. Si esclude invece categoricamente che gli AP siano collegati tra di loro con un ponte radio a mezzo di range-extender o repeater wireless poiché soluzione poco efficiente e di cui non si avverte la necessità. I dispositivi AP devono garantire connettività 802.11n e 802.11ac per le connessioni nella banda dei 2,4 e 5,4 Ghz. Gli switch sono collegati in cascata con il router principale del treno, che potrebbe essere collocato nel vagone locomotiva o, meglio, nel vagone centrale solitamente adibito a ristorante. Questa soluzione centrale rende anche più efficiente il cablaggio e la distanza più omogenea degli apparati, considerando che ci sarebbe una porta del router che gestisce la coda ed una che gestisce la parte verso la testa. Il router deve avere, oltre che l’interfaccia Ethernet, anche una WAN 4G per permettere alla rete LAN di “uscire” su internet. Ovviamente l’interfaccia WAN ha IP pubblico configurato con NAT verso la rete interna gestita invece con IP privati. Per migliorare le prestazioni tutte le interfacce Ethernet sia del router che degli switch precedentemente descritti si consiglia l’uso di interfacce Gigabit Ethernet con cavi con CAT 6 o 7, in modo da avere una larghezza di banda fino a 10Gps. In ogni cabina, i vari AP, potrebbero essere configurati per avere un range di metri massimo di copertura tarato sulla dimensione cabina stessa o, per semplicità, ogni AP potrebbe essere impostato su un canale differente tenendo premura che tra ogni cabina si salti almeno un canale per non creare interferenze. (Es. cabina uno su canale uno, cabina successiva su canale tre, la successiva su canale cinque, la successiva ancora magari sul recuperiamo il canale due e così via)
La gestione dello streaming
Lo streaming è un flusso di dati audio/video continuo che richiede ingenti risorse di rete per permettere ad un client di usufruire di un contenuto come un film. Se questo flusso è richiesto da numerosi utenti, ci rendiamo conto che ci troviamo di fronte ad una mole di dati enorme che deve essere spostata. La rete WiFi interna è sicuramente un ottimo stratagemma per permettere all’utenza di collegarsi al sistema centrale ma non è conveniente permettere agli utenti di usufruire della connessione esterna WAN per accedere ai film. L’interfaccia di rete esterna al treno che possiamo configurare sul router di frontiera posto nella cabina principale, che la scegliamo 4G o HiperLan o WiMax, rappresenta comunque un collo di bottiglia enorme, a maggior ragione che il segnale del ponte radio potrebbe essere fortemente influenzato negativamente dalla conformazione del territorio percorso dal treno, gallerie soprattutto. Ecco perché la soluzione più conveniente è quella di bloccare flussi streaming anomali sulla rete Lan con un firewall o con un proxy semantico che blocchi determinati siti di streaming noti (legali e non, ad esempio youtube, video sono legali ma ridurrebbero fortemente la banda) o con un firewall opportunamente settato impostare una banda massima per ogni utente collergato così da garantire una QoS, quality of service adeguata per ciascun utente. Ricordiamo che la QoS è una caratteristica fondamentale per un buon servizio a utenti multipli e si può trovare anche sui router/modem di casa nostra con una comoda interfaccia grafica di configurazione del modem stesso. Bloccati i flussi di traffico, l’idea di base è quella di avere invece un catalogo di film direttamente sul treno da esporre ai passeggeri. Questo ovviamente ha un costo per il sistema di immagazzinamento ma darebbe un servizio di qualità ai passeggeri, tutti i passeggeri. Questo non toglie che un viaggiatore possa sempre usare la propria rete 4G per navigare fuori dalla rete wifi e accedere ad altri cataloghi.
La validazione del biglietto
Si è già accennato qualcosa nei paragrafi precedenti. La validazione del biglietto può essere fatta utilizzando un barcode 2d stampato sul biglietto stesso che contiene informazioni utili al riconoscimento del treno, orario, posto prenotato o che contiene semplicemente un id che, inquadrato con una fotocamera opportuna, permette di reperire tali informazioni direttamente con un URL da un server database centrale della compagnia di treni. Il controllore ha praticamente il solo compito di scannerizzare tale immagine e verificare che siano coerenti con quelle del treno in corsa su una app opportunamente realizzata per l’operazione. Occorre, ovviamente, una infrastruttura di rete a terra che è quindi possibile raggiungere attraverso la connessione lan wifi e l’interfaccia wan 4G. L’infrastruttura a terra non necessita di considerazioni particolari. Sarà sicuramente una area DMZ protetta opportunamente da un firewall che consente una connessione VPN tra il palmare del controllore e i server che contengono le informazioni dei treni e dei biglietti. La zona DMZ potrà essere collegata tramite un router con interfaccia WAN speculare a quella usata dal treno, sfruttando una infrastruttura di rete messa a disposizione dalle compagnie telefoniche esistenti. La sicurezza e riservatezza è assicurata dalla configurazione/uso di una VPN (ad esempio con sistemi Cisco, Citrix o Open VPN).
Dispositivi e loro caratteristiche
Abbiamo già discusso sulle prestazioni della rete WiFi, ma non ancora del tablet del controllore. Qui le scelte sono pressoché infinite. Tablet in commercio di fascia media si aggirano su prezzi al dettaglio accessibili tra 200/300 euro fino ad arrivare a 800 euro. Le caratteristiche che potranno interessare nel nostro contesto sono sicuramente:
- Schermi luminosi, con buoni angoli di visione e diagonale di 10 pollici
- Hardware: CPU con tecnologia ARM, come i Cortex o simili di altre case come NvIdia, Intel e RAM di almeno 3 GigaByte. Valutare la predisposizione all’uso di un pennino touch per operazioni di firma o appunti veloci.
- Autonomia: batterie abbastanza capienti da assicurare autonomie per i lunghi viaggi o sistemi di risparmio energetico particolarmente efficienti
- Connettività: qui abbiamo parlato di una rete Wi-Fi interna al treno, ma si consiglia di avere anche un modulo 4G, nel caso di avaria della rete locale o il controllore si trovi su un treno ancora non aggiornato.
- Fotocamera: necessaria al controllore per fare la scansione dei barcode 2D dei biglietti, non servono prestazioni particolari
- Software applicativi: i software possono essere delle tipologie più disparate ma devono mantenere un buon bilanciamento fra semplicità, fluidità e numero di funzioni
- Memoria interna: consigliata 16GByte o 32GB
- Sistema Operativo: Android 8
- Software specifici: occorrerà sviluppare una app che si integri col sistema progettato, non si fanno particolari considerazioni se non consigliare di svilupparle con tecnologie all’avanguardia e che permettono una compatibilità con dispositivi e s.o. differenti, vedi il prossimo Android 10 detto Fuchsia. In questo caso quindi si possono realizzare con il framework Flutter e il suo linguaggio Dart o React Native.
Per quanto riguarda il server contenente la raccolta di film, caratteristiche standard di interesse potrebbero essere, più che un hardware prestante, uno storage capiente per consentire di archiviare più titoli possibile.
- CPU: 2x Intel Xeon E5 con 6 Cores
- RAM 32 GB DDR4 con bit di parità per prevenire errori
- 8 Hard Disk da 3Tera Byte l’uno, in tecnologia non necessariamente SSD ma con piatto rotante/meccanico per contenere i costi. Invece 2 SSD per il sistema operativo in RAID5 per maggiori performance. L’array di HD per lo storage non è conveniente metterli in backup locale con il RAID1, avremmo la metà della capienza totale o un numero di HD davvero consistente. Il backup può essere fatto in un sistema cloud con cui ripristinare in locale eventuali anomalie/malfunzionamenti o una sostituzione degli hd danneggiati con un sistema di rimozione a caldo Hot Swap per la sostituzione in stazione a treno fermo.
- Due schede di rete 10 GBit (una ridondante di backup)
- Software: in questo caso non possiamo ricorrere ad un semplice server Apache con PHP7 e MySQL con InnoDB per le sole operazioni da eseguire. O meglio il sito web a cui il passeggero si collega, sarà sicuramente fornito attraverso questo servizio, mentre la parte di streaming non può essere affidata al server Apache poiché scarsamente ottimizzato per questo genere di operazioni di Video on demand (VOD). In questo caso è bene ricorrere a software server appositi come il RED5, software open source sviluppato da/per Google ed utilizzato per lo streaming su Facebook e Amazon o altre soluzioni ad esempio con Nginx e i suoi moduli dedicati (si, è un server molto polivalente sia per eseguire i classici PHP ma anche Python e audio/video streaming). Il tutto sempre su un sistema operativo Linux, come Mint, CentOS, Red Hat o Debian, specifiche distribuzioni per server di produzione.
Soluzione ottimale per lo streaming sarebbe avere più server che funzionano con load balance, suddividendo le richieste multiple degli utenti. In questo caso, come ordine di grandezza di utenti, non si vede necessario un sistema così complesso.
La zona DMZ a terra conterrà opportuni server per gestire il database e l’interfaccia di comunicazione con l’app del controllore. Tali server possono avere una classica configurazione con s.o. linux con MySQL con InnoDB e una configurazione classica con hard disk SSD almeno uno in Raid 1 e duo o più in Raid 5 per garantire il backup dei dati e le prestazioni di risposta verso più controllori/app. Anche in questo caso, andremo ad avere processori multipli Xeon con ram con bit di parità e interfacce di rete gigabit ridondate. (descrizione completa la trovate anche nella simulazione precedente)
Sicurezza
Sulla sicurezza dobbiamo tener conto dei software che sono stati realizzati per il login e quindi la possibilità a seguire di usufruire dei contenuti. Il sito su cui permetteremo il login con il barcode del biglietto e username e password deve ovviamente essere a prova di SQL Injection. Il fatto stesso che abbiamo username/password e barcode sul biglietto ci mette in una condizioni di login con “qualcosa che so” e “qualcosa che ho” (in questo assegnato dalla compagnia dei treni previo acquisto del biglietto). Il sistema deve essere a prova DDoS con sistemi di monitoraggio degli attacchi e delle intrusioni. Il sistema di login wifi può contare su tecnologie 802.1X con autenticazione EAP e server Radius (da porre magari assieme al server dei contenuti nella prima cabina o cabina ristorante). Si è già detto del firewall per filtrare il traffico su porte e servizi non consentiti e di un eventuale proxy per filtrare siti di streaming noti che potrebbero rallentare il traffico interno della rete Lan.
(da Wikipedia, Autenticazione 802.1X)
II PARTE
II. In relazione al tema proposto nella prima parte, si consideri che EasyTrainper motivi di sicurezza è tenuta a mantenere un registro dei siti visitati dai viaggiatori attraverso la connettività WiFi a loro riservata. Si discutano le possibili soluzioni, anche tenendo conto degli aspetti legati alla privacy.
Il quesito è un classico argomento che possiamo trattare a lezione sul salvataggio delle informazioni degli utenti e le relative normative della privacy. Elementi già trattati anche in questo sito sono quelli del login debole e login forte con password utente non salvata in chiaro ma con opportuna funzione di hash. Ovviamente l’aspetto più interessante è quello della trattazione di tutta la questione concernente il GDPR che potete trovare qui. Il candidato può eventualmente azzardare a citare la blockchain. La blockchain è una struttura dati condivisa in rete e immutabile e non modificabile, un po’ quindi come il registro che vogliamo tenere dei visitatori. È definita come un registro digitale le cui voci sono raggruppate in “pagine”, concatenate in ordine cronologico, e la cui integrità è garantita dalla crittografia e dal l’intero sistema distribuito che la sorregge.
IV. In una azienda dotata di diversi uffici, alcuni dipendenti collegano impropriamente via cavo i laptop personali ai “punti di rete” della Lan aziendale, allo scopo di attivare, negli stessi laptop, hot spot wifi “open” (senza protezioni) con cui fornire connessione per altri dispositivi, o proprio di eventuali ospiti non autorizzati. Il candidato tratti le conseguenze negative che una simile pratica può comportare per l’azienda e proponga soluzioni tecniche ed organizzative che potrebbero essere adottate per prevenire tali abusi.
Anche questo quesito non deve spaventare l’alunno poiché abbondantemente trattato nei programmi scolastici. Sono solito raccontare agli alunni che circa il 80 % dei problemi di sicurezza di una rete aziendale dipendono dal personale interno, sulla loro scarsa formazione in materia di sicurezza, dall’uso delle risorse hardware e software dell’azienda in modo improprio con palesi errori. Quello descritto nel testo del quesito ne è un valido esempio. Solo il 20% circa proviene da minacce esterne o attacchi hacker attivi! I pc aziendali sono solitamente protetti da una serie di policy, di regole ben definite e attuate dal responsabile/sistemista della rete. Regole che vanno da una base molto semplice quale l’aggiornamento costante dei software per proteggersi da bug, uso di antivirus e aggiornamento delle loro definizioni, il monitoraggio costante della rete e del traffico dagli ip configurati staticamente e non. Permettere ad un dispositivo non controllato e non ben protetto, di inserirsi dentro la rete, rappresenta un vero e proprio cavallo di Troia. E’ facile che un dispositivo infetto da virus e worm riesca a propagare tali infezioni all’interno della rete aziendale autospacciandosi per software aziendale sicuro proprio perché proveniente dall’interno e non dall’esterno, aggirando quello che è il firewall di confine della rete. Qui c’è tutta una carrellata di elementi che si possono descrivere che vanno a minare la sicurezza interna: dai keylogger agli spyware che carpiscono informazioni sensibili per lo spionaggio industriale (progetti, dati, risultati dell’azienda che vengono intercettati e rivenduti magari agli avversari), come il blocco con semplici DOS del sistema produttivo, virus che danneggiano hardware e software bloccando a loro volta il sistema produttivo e costringendo i responsabili della sicurezza al ripristino di situazioni dati consistenti precedenti l’infezione. La prima contromisura è sicuramente la prevenzione: formare il personale a seguire comportamenti corretti è fondamentale per evitare le pratiche descritte nel quesito. Anche azioni semplici come aprire email solo se ritenute affidabili, cliccare file allegati solo se controprovati ad esempio sono regole banali, spesso sottovalutato dal personale dell’azienda, come navigare in siti pericolosi di scarso interesse aziendale. Tecnicamente non è facile contrastare il danno fatto nel quesito, poiché tutto il traffico illecito del dispositivo connesso verrebbe “ripulito” dal pc che fa da tramite. Un buon sistemista di rete potrebbe sicuramente monitorare il traffico anomalo con sniffer di rete (ad es. un utente medio della rete in genere consuma una tot di kbyte di banda mentre quello che fa da hotspot consuma due o tre volte il traffico medio) e preimpostare un proxy semantico che permetta di scartare a priori tutti i siti di scarso interesse aziendale (banale eppure ci sono statistiche piuttosto imbarazzanti sull’uso di siti pornografici dai posti di lavoro), sistemi torrent o download, siti potenzialmente nocivi che andrebbe a guardare un utente qualsiasi che non lavora dentro la nostra azienda di riferimento.
Ultima modifica 10 Marzo 2022