AUTOMAZIONE84

RECS 101: UN WEB SERVEREMBEDDED PER APPLICAZIONIDI CONTROLLO REMOTOTRAMITE TCP/IP

RECS 101: UN WEB SERVEREMBEDDED PER APPLICAZIONIDI CONTROLLO REMOTOTRAMITE TCP/IP

di Cristian Randieri randieri@intellisystem.it

La sicurezza è un aspetto moltoimportante e da non trascurare neisistemi di controllo specie se sonogestiti tramite la rete Internet. Se daun lato la rete Internet offre grandiflessibilità a livello di condivisione dirisorse e di gestione da remoto, dal-l’altro è sicuramente un ambientenon sicuro, poiché chiunque puòconnettersi ad essa. Il web ha il pote-re di aumentare la produttività dichiunque, tuttavia come per ognitecnologia o attività di gruppo oltrealle straordinarie attività occorre con-siderarne i rischi. Generalmente gliattacchi ad un sistema di controlloremoto si possono classificaremediante l’individuazione dei puntideboli del sistema che s’intende esa-minare. In generale si possono indivi-duare quattro categorie:

• Vulnerabilità dei dati.• Vulnerabilità del software.• Vulnerabilità del sistema fisico.• Vulnerabilità delle trasmissioni.

Per difendersi da questi attacchi, ci sideve attendere che ogni potenziale

intruso possa sfruttare queste vulne-rabilità per accedere ai dati e quindipotenzialmente danneggiare il siste-ma. Ad esempio, la connessione diun sistema di controllo su internetpuò aprire delle falle nei sistemi disicurezza e tali falle possono essereutilizzate da utenti non autorizzatiper accedere o manipolarne le fun-zionalità. Gli intrusi potrebberoanche invalidare il server Internet delsistema di controllo, modificandone ifile in esso memorizzati (ad esempioi file che contengono le informazionisulle User-ID e Password degli utentidel sistema). I potenziali Hackerpotrebbero inserire nel sistema deivirus e altri programmi distruttiviauto-replicanti in grado di danneg-giare o disabilitare completamente ilsistema. Possiamo classificare gliattacchi provenienti da internet nelleseguenti categorie:

Attacchi da password: Gli intrusicercano di entrare nel sistemaimmettendo un codice di Login eduna password, provando varie voltesino a trovarne una funzionante [1].

Normalmente vengono adoperatidei software in grado di utilizzarevariegati dizionari che provano dicontinuo diverse combinazioni sino aquando non trovano quella vincenteche permette di far accedere al siste-ma. Ad esempio i sistemi Unix sonoparticolarmente vulnerabili ad attac-chi di questo tipo, poiché, UNIX nonblocca l’accesso degli utenti dopo undeterminato numero di tentativi falli-ti, cosa che normalmente avvienenella maggior parte degli altri sistemioperativi.

Attacchi alla sicurezza della rete edei pacchetti: Poiché ogni pacchettotrasmesso in Internet può attraversa-re un gran numero di nodi prima digiungere a destinazione, gli hackerpossono utilizzare appositi strumentidenominati “racket sniffer” per inter-cettare i pacchetti inoltrati nella rete(inclusi i pacchetti di login e trasmis-sione dei dati). I più comuni attacchiai pacchetti sono precursori degliattacchi al protocollo IP. Per iniziareun attacco sniffing, un hacker perprima cosa va alla ricerca di una User

Con questa quarta parte, si conclude la trattazione del dispositivo RECS 101 con unargomento di rilevante importanza: “il proble della sicurezza per i web server embedded”.

AUTOMAZIONE

quarta parte

AUTOMAZIONE 85

ID e di una password di un utentelegittimo utilizzandola per accederealla rete distribuita. Dopo essersiintruso nella rete l’hacker osserva ecopia le trasmissioni dei pacchetti etenta di raccogliere quante più infor-mazioni possibili sulla rete.

Attacchi al protocollo IP: Si concen-tra sull’indirizzamento dei pacchettiche il protocollo IP utilizza per le tra-smissioni. Un attacco di questo tipoprevede due fasi. Nella prima si cercadi determinare l’indirizzo IP del ser-ver, generalmente mettendosi inascolto dei pacchetti Internet, pro-vando a specificare in ordine varinumeri di host oppure connettendo-si al sito mediante un browser web eosservando l’indirizzo IP nella barradi stato. Poiché l’hacker sa che glialtri computer della rete condivido-no una parte del dell’indirizzo IP delserver, cercherà di simulare un indi-rizzo IP che gli consenta di scavalca-re il router e di accedere al sistema,come se fosse un utente interno.Dopo che l’hacker avrà iniziato a tro-vare gli indirizzi della rete, inizieràanche a controllare i numeri disequenza dei pacchetti che si tra-smettono tali computer. In seguito,dopo aver controllato le trasmissionidella rete, l’hacker cercherà di preve-dere il prossimo numero di sequenzache verrà generato dal server e quin-di fornirà un proprio pacchetto contale numero di sequenza inserendosifra il server e l’utente. Poiché l’hackerha già l’indirizzo IP del server, può inrealtà generare pacchetti con inumeri di sequenza corretti e indiriz-zi IP che gli consentono di intercetta-re le trasmissioni con l’utente. Dopoche l’hacker ha avuto accesso al siste-ma tramite la previsione di un nume-ro di sequenza, può accedere alleinformazioni che il sistema di comu-nicazione trasmette al server, inclusi ifiles di password, nomi, login, datiriservati e ogni altra informazioni tra-smessa in rete. In generale un hacker

utilizza la previsione del numero disequenza come preparativo per l’at-tacco vero e proprio al server oppurecome base per l’attacco di un altroserver della rete.

Hyperlink Spoofing: È un tipo d’at-tacco che gli hacker sferrato controcomputer che comunicano utilizzan-do il protocollo HTTP [2]. Gli hackerpossono dunque sferrare attacchianche al protocollo di autenticazionedi server SSL (Secure Socket Layer)utilizzato per la creazione di browsere server Web sicuri, come i prodottiMicrosoft e Netscape. Un attacco diquesto tipo prevede che un hackerfungendo da intermediario convincail browser a connettersi a un serverfittizio presentando al browser l’a-spetto di una sessione sicura. Un hac-ker intermediario è un hacker ches’inserisce nel flusso dei pacchetti chescorrono fra un client ed un server. Inquesto modo l’hacker convince l’u-tente a rilevare determinate informa-zioni quali ad esempio User ID ePassword o altre informazioni riserva-te che saranno memorizzate nel ser-ver fittizio. Un alto rischio diHyperlink spoofing accade se l’uten-te preleva ed esegue dal server fittizioapplet Java pericolosi, credendo chetali applet siano forniti da un serversicuro e che debbano pertanto esse-re considerati sicuri. L’attaccoHyperlink spoofing rende palese undifetto nel modo in cui, la maggiorparte dei browser, impiega i certifica-ti digitali per rendere sicure le sessio-ni. L’attacco spoofing tramite colle-gamenti ipertestuali non attacca lacrittografia a basso livello o il funzio-namento del protocollo SSL. Di con-seguenza l’attacco può essere sferra-to anche ad altre applicazioni garan-tite da un certificato, a seconda delmodo in cui tali applicazioni impie-ghino i propri certificati. Il problemaprincipale è che gli attacchi Hyperlinkspoofing si basano sul fatto che il cer-tificato SSL fornito contiene informa-

zioni errate (ad esempio il nome delDNS). Quindi, nonostante gli indiriz-zi URL sembrino corretti e riflettendol’attività dell’azienda che possiede ilsito Web cui si fa riferimento, nonsempre questo accade. Quando èregistrato un dominio, le autoritàInternet assicurano che il DNS nonsia già stato registrato da altri manon assicurano che non violi le leggidi copyright.

Web Spoofing: È un tipo d’attaccoche prevede di creare una copia falsama convincente dell’intero sito Web[3]. Il sito Web ha tutto l’aspetto delsito vero e proprio, ovvero contienele stesse pagine e gli stessi link delvero sito WEB, ma è completamentesotto il controllo dell’hacker. In unattacco di questo tipo, l’hacker puòosservare o modificare tutti i dati chevanno dalla vittima al server del sitoWeb. Inoltre, l’hacker può controllaretutto il traffico di ritorno dal serverWeb alla sua vittima. In seguito l’hac-ker può impiegare vari tipi di attaccotra cui ad esempio lo sniffing e lospoofing. Con lo sniffing l’hackerosserva passivamente il traffico dellarete. Lo spoofing invece prevedeun’attività di manipolazione in quan-to l’hacker convince un host di esse-re un altro computer fidato e pertan-to si prepara a ricevere varie informa-zioni. Ad esempio l’hacker può regi-strare i contenuti e le risposte che ilserver invia al client (User ID, pas-sword ecc.). L’hacker può eseguireun’attività di sorveglianza, anche sela vittima ritiene di trovarsi in unaconnessione sicura.Indipendentemente dal fatto che laconnessione impieghi i metodi SSL oS-http, l’hacker sarà comunque ingrado di ingannare l’utente. Sipotrebbe pensare che sia difficile perl’hacker sostituirsi all’intero Web, masfortunatamente non è così. L’hackernon deve memorizzare l’intero con-tenuto del Web, poiché il Web è, perdefinizione, disponibile on-line.

AUTOMAZIONE

AUTOMAZIONE86

Quando il server dell’hacker deve for-nire una falsa pagina, gli basta prele-varla e modificarla dal Web stesso.

POSSIBILI CONTROMISURESebbene il mondo dell’informaticasia in continua evoluzione trovare deirimedi che eliminino definitivamentetali problemi è molto difficile, tuttavianel seguente paragrafo vogliamopresentare alcune soluzioni che adot-tate potrebbero essere un modo perfronteggiare queste problematiche.Rispecchiando lo schema precedenteriportiamo di seguito le soluzionipossibili:

Attacchi da password: Nelle reti,l’intercettazione delle transazioni,rappresenta uno dei rischi più graviche attualmente affligge i singoliutenti e le organizzazioni. Per proteg-gersi dall’intercettazione dei pacchet-ti è opportuno crittografare tutte letrasmissioni. I due tipi principali dicrittografia sono: la crittografia achiave semplice (o a chiave simmetri-ca) e quella a chiave pubblica (o achiave asimmetrica). La crittografia achiave semplice, utilizza un'unicachiave nota ai due capi della comuni-cazione che la usano per crittografa-re e decrittografare le informazioni.La crittografia a chiave pubblica, usauna chiave disponibile pubblicamen-te e una segreta conosciuta dall’uten-te. La maggior parte dei programminormalmente utilizzati per eseguirela crittografia dei messaggi, seguonolo standard PEM (Privacy EnanchedMail) definito in dettaglio nelle RFC1421, 1422,1423 e 1424. Gli algorit-mi di crittografia più utilizzati sonol’algoritmo RSA (Rivest-Shamir-Adleman) e l’algoritmo Diffide-Hellman. Tali algoritmi possono quin-di essere utilizzati per marcare inmodo digitale le trasmissioni. Questatecnica consente ai destinatari deimessaggi di verificare l’identità delmittente. Studi recenti hanno dimo-strato che misurando accuratamente

il tempo necessario per eseguire leoperazioni sulla chiave privata, unhacker può dedurre gli esponenti fissidi Diffide-Hellman, i fattori delle chia-vi RSA e dunque violare questi siste-mi di crittografia. In termini realistici,il pericolo che qualcuno possa deco-dificare una trasmissione criptata, uti-lizzando un attacco di questo tipo, èsolo leggermente inferiore rispetto alpericolo che qualcuno possa rubarela chiave privata dal disco fisso.

Attacchi alla sicurezza della rete edei pacchetti: Gli attacchi sniffer sureti distribuite possono essere evitatiutilizzando degli schemi di identifica-zione come il sistema delle passwordmonouso o il sistema di autenticazio-ne a ticket (come Kerberos [4]).Alcuni sistemi monouso fornisconoagli utenti la prossima password nelmomento in cui l’utente si connettedal sistema. Anche se sia le passwordmonouso che gli schemi Kerberospossono rendere molto più difficile losniffing delle password su una retenon sicura, entrambi i metodi espon-gono al rischio di attacchi attivi se ilcanale dati non è criptato o codifica-to. Un attacco attivo al protocolloTCP/IP consente all’hacker di ridire-zionare il canale TCP verso la propriamacchina. Dopodiché l’hacker puòby-passare la protezione che offre unsistema di password monouso o diautenticazione a ticket. La connessio-ne TCP, diviene vulnerabile, a chiun-que sia in possesso di uno sniffer dipacchetti TCP e di un generatore dipacchetti TCP posizionati sul percor-so della connessione.

Attacchi al protocollo IP: Il modopiù semplice per prevenire il sistemacontro questo tipo di attacchi a pre-visione di numero di sequenza consi-ste nell’assicurarsi che il router, il fire-wall e ogni server del sistema abbia-no attivato la protezione audit-trail.Un audit-trail è una registrazionecronologica delle attività di sistema,

sufficiente per consentire la ricostru-zione, la revisione e l’esame dellasequenza di situazioni e di attivitàche hanno riguardato o che hannocondotto a un’operazione, una pro-cedura o un evento in una transazio-ne dal suo inizio ai suoi risultati fina-li. Utilizzando gli audit-trail, si puòosservare quando un hacker tenta diattraversare il router e il firewall equando tenta di accedere al server.Utilizzando uno dei programmi diservizio disponibili nel sistema ope-rativo, si può richiedere che a segui-to di un determinato numero dirichieste di accesso negate vengaprodotto un avvertimento. Si devericonoscere che l’auditing e la manu-tenzione e l’osservazione degli audit-trail non offrono una protezione “ aprova d’errore” contro gli attacchi alsistema. Se qualcuno esegue lo“spoofing” del sistema, ad esempio,l’operazione non potrà essere indivi-duata dall’auditing. Se qualcunoascolterà il sistema con uno sniffer,l’auditing probabilmente non siaccorgerà di nulla poiché l’hackernon accede ai dati del server masemplicemente osserva i dati in pas-saggio. Come tutti gli altri strumenti di pre-venzione degli attacchi, l’auditing-trail, se utilizzato correttamente, èsolo uno degli strumenti per unpiano organico di sicurezza.L’auditing non può sostituire un fire-wall o uno screening router o unapolitica di sicurezza. Analogamentegli altri sistemi difensivi non possonosostituire l’auditing.

Hyperlink Spoofing: Se s’impieganogià applicazioni Web che fanno affi-damento sull’autenticazione del ser-ver (ad esempio per il prelevamentodi applet Java), l’unica soluzione pra-ticabile consiste nel far partire ilbrowser da una pagina sicura inmodo che gli utenti possano fidarsidei link iniziali e che un hacker nonpossa mai inviarli in luoghi sospetti.

AUTOMAZIONE

AUTOMAZIONE 87

Una pagina sicura è quella di cui sipuò verificare l’integrità e questo, ingenere, significa che tale paginadeve essere un file HTML locale o unapagina su un server SSL. Se si deside-ra che il browser di un utente partaaprendo una pagina SSL, si deveinviare l’indirizzo URL di tale paginatramite mezzi difficili o impossibili daintercettare (ad esempio un floppy ouna lettera), altrimenti la paginapotrebbe diventare il punto di par-tenza per l’attacco che s’intende pre-venire. Tutti i link contenuti in questapagina dovrebbero inviare gli utentisu siti di provata affidabilità e preferi-bilmente tutti i link dovrebbero esse-re di tipo SSL. L’affidabilità può basar-si sui seguenti criteri:

• Il sito deve essere condotto con cri-teri di sicurezza. Ovvero l’interosito deve essere reso sicuro controgli attacchi e l’intercettazione dellepagine.

• Il sito deve contenere link che con-ducono solo ad altri siti sicuri.

Web Spoofing: Questo genere d’at-tacchi è veramente pericoloso e insostanza non è rilevabile. Le misurepreventive che possono essere adot-tate si riassumono nei seguenti punti:

• Disabilitare nel browser gli script inmodo che l’hacker non possanascondere l’evidenza dell’attacco;

• Assicurarsi che la riga degli indirizzidel browser sia sempre visibile.

• Fare attenzione all’indirizzo URLvisualizzato dal browser, assicuran-dosi che punti sempre al server acui si pensa di essere connessi.

Questa strategia riduce fortemente irischi di attacco anche se un hackerpuò comunque colpire un utentedalla rete, specialmente coloro chenon si preoccupano di osservare stra-ni comportamenti sulla riga degliindirizzi o della barra di stato. Con ladisattivazione degli script si perderà

qualche utile funzionalità, si potrà inogni caso riattivarne l’uso, all’internodi siti fidati, per disattivarli, nuova-mente, quando si lascia il sito fidato. La creazione di una soluzione a lungotermine è molto più difficile, poichéoccorrerebbe modificare il codice delbrowser in modo tale che program-ma visualizzi sempre la riga dell’indi-rizzo offrendo una maggiore sicurez-za così come la possibilità di renderesicuro il browser contro modificheesterne, ovvero fare in modo che iprogrammi Web non possano crearefalse barre di menù, false barre distato ecc.Per le pagine che il browser prelevautilizzando una connessione sicura,una migliore indicazione di attivazio-ne della connessione sicura potrebbeaiutare a garantire un’effettiva sicu-rezza dell’utente.Invece di indicare semplicementel’attivazione di una connessione sicu-ra, i browser potrebbero visualizzarecon chiarezza il nome del server cheha completato tale connessione. Fondamentalmente ogni approccioal problema del Web-spoofing sem-bra essere affidato alla vigilanza del-l’utente. Il fatto che un amministrato-re di sistema possa realisticamenteattendersi questo tipo di vigilanza datutti gli utenti della rete, pone seridubbi.

I PRINCIPALI PROBLEMIDI SICUREZZA DEGLIAPPLET JAVAAnche se Java rappresenta unambiente di programmazione relati-vamente sicuro, occorre considerarevari argomenti che aiutino a difen-

dersi contro i problemi di sicurezzaderivanti dall’impiego di Java. Poichéla JVM interpreta gli applet Java local-mente, in genere gli applet consu-mano grandi quantità di risorse disistema. Gli applet ostili o mal pro-grammati possono consumare trop-pe risorse di sistema utilizzando lamaggior parte della CPU o dellamemoria de computer. Quando un applet consuma tropperisorse, il computer può rallentaresino quasi a bloccarsi.Questo stato di blocco è il risultato diun attacco. Nelle prime implementa-zioni di Java (JDK 1.1.2) esisteva unbug nel verificatore di applet checonsentiva a un applet prelevato suun client che si trova all’interno di unfirewall di collegarsi a un determina-to host al di là del firewall. Dopo laconnessione, l’applet poteva tra-smettere informazioni relative allamacchina client invece che informa-zioni relative al server proxy cosìcome dovrebbe fare l’applet, apren-do la rete a un attacco spoofing.

In generale possiamo dire che il Javapuò soffrire di quattro tipi possibili diattacchi [5÷13]:

• Leakage (unauthorized attemptsto obtain information belongingto or intended for someone else).

• Tampering (unauthorized chan-ging/including deleting/of infor-mation).

• Resource stealing (unauthorizeduse of resources or facilities such asmemory or disk space).

• Antagonism (interactions notresulting in a gain for the intruder

AUTOMAZIONE

Installazione Cache SAND BOX Accesso Completo Trusted

Applet java Standard * Applet java Trusted *

Installazione permanente Libreria Java standard * Libreria Java Trusted *

* Utilizzo dell’autenticazione

Tabella 1: Sisitema di sicurezza Sandbox di Java

AUTOMAZIONE88

but annoying for the attackedparty).

Gli Applet Java utilizzano un sistemadi sicurezza, noto con il nome diSandbox, che protegge il computercontro l’intrusione di applet ostili. Ilmodello Sandbox limita l’accesso alsistema da parte del applet restrin-gendolo a determinate aree delclient.La tabella 1 si riferisce ad un appletJava di tipo standard chiamato appletsandbox. L’applet sandbox ha unaccesso limitato alle risorse del siste-ma. Un applet sandbox non può adesempio accedere al disco fisso del-l’utente, aprire nuovi canali di tra-smissione o restituire informazioniapprofondite, relative al client cheesegue l’applet stessa. Gli applet e la libreria standard java,sono applet sandbox. Il tipo trusted èuna nuova variante del modello java,un applet trusted ha accesso a tuttele risorse di sistema e opera all’ester-no della sandbox. In genere, gli applet java trusted,sono applet creati da un’organizza-zione o all’interno di un’intranetaziendale, oppure applet che l’autorefirma prima della trasmissione viainternet. In generale non è possibilegarantire la sicurezza degli applettrusted in quanto l’applet ha unaccesso completo alle risorse delsistema.

ARCHITETTURA DISICUREZZA JAVAIn accordo a quanto riportato in let-teratura [8], l’applet Verifier [9], èuna parte del sistema run-time dijava, che assicura che l’applet seguadeterminate regole di sicurezza.Per iniziare, l’applet verifier confermache il file della classe segua le specifi-che del linguaggio java. L’applet veri-fier non presume che il file della clas-se sia stato prodotto da un compila-tore sicuro.Al contrario controlla nel file della

classe l’esistenza di violazioni alleregole del linguaggio e altre restri-zioni riguardanti lo spazio dei nomie chiudere altre via di fuga, impie-gabili per uscire dal file della clas-se. In particolare l’applet verifierassicura che:

• Il programma non provochi l’over-flow o l’underflow dello stack.

• Il programma esegua accessi validialla memoria e ai registri.

• I parametri di tutte le istruzionibytecode siano corretti.

• Il programma non converta illegal-mente i dati.

L’applet verifier svolge queste funzio-ni critiche analizzando le istruzionicontenute nel file dell’applet. Unbrowser Web utilizza un solo classloader che il browser attiva all’avvio,dopo questa fase il browser non puòestendere, modificare o sostituire ilcaricatore di class. Gli applet nonpossono creare o far riferimento a unproprio class loader.L’applet verifier è indipendente dal-l’implementazione di riferimento Sundel compilatore java e dalle specifi-che di alto livello del linguaggio Java.L’applet verifier esamina il bytecodegenerato dal compilatore java. LaJVM si fida (e pertanto esegue) delbyte code importato da internet solodopo che tale bytecode ha passatol’analisi del verifier. Per passare alverifier il bytecode deve risponderealla sintassi, alle firme degli oggetti,al formato del file della classe ed altreprevedibilità dello stack run-timedefiniti dall’implementazione.Gli applet sono eseguiti in condizionidi sicurezza relativamente stringenti.L’applet security manager è il mecca-nismo java che si occupa delle restri-zioni sugli applet. Un browser ha unsolo manager della sicurezza.L’applet security manager si inizializ-za all’avvio del browser e in seguitonon può essere sostituito, modificatoo esteso.

Gli applet non possono creare o farriferimento a un proprio gestore dellasicurezza. Per una descrizione piùdettagliata dell’architettura di sicu-rezza Java si rimanda alle note biblio-grafiche [5÷13].

RECS 101 SECURITYCome evidenziato in precedenza,RECS101, rappresenta un implemen-tazione realistica di un web serverintegrato capace di gestire al suointerno la JVM.Il problema della sicurezza nel nostrocaso presenta diversi vincoli nonindifferenti che riguardano le scarsecapacità di calcolo del dispositivorealizzato.Sicuramente è quasi impensabilepoter implementare tutti i sistemianti-intrusione presentati nei para-grafi precedenti. Nonostante ciògioca a nostro favore il fatto cheessendo un dispositivo non standardche non ha al suo interno un sistemaoperativo standard ciò permette disfruttare le proprietà hardware deldispositivo.Per essere più chiaro, i problemi percui il dispositivo potrebbe esserevulnerabile, sono principalmentedovuti a:

• Possibile attacco alla passwordd’accesso al sistema.

• Attacchi al protocollo IP e alla sicu-rezza dei pacchetti.

• Hyperlink Spoofing.• Web Spoofing.

Poiché la nostra applicazione si basasulla JVM, abbiamo un livello di pro-tezione base che comunque ci vienefornito dalla gestione delle Applet(come esposto precedentemente).Le contromisure che abbiamo adot-tato per far fronte alle problematichesopra esposte, sono le seguenti:

Possibile attacco alla passwordd’accesso al sistema. RECS 101 nonintegra al suo interno alcun sistema

AUTOMAZIONE

AUTOMAZIONE 89

da il Web Spoofing, si può pensare didisattivare il supporto Java in RECS101, però il prezzo da pagare è laportabilità del dispositivo, nel sensoche il dispositivo perderebbe tutte leproprietà inerenti l’accesso alle portedi I/O tramite interfaccia Web.Poiché RECS 101 supporta anche iSocket C è possibile scrivere delle

applicazioni Client/Server in C cheeseguite localmente in un PC posso-no attivare una connessione conquest’ultimo. In questo modo si risol-vono tutti i possibili problemi diHyperlink Spoofing e Web Spoofing.

di gestione delle chiavi sia esse pub-bliche che private, trattandosi di unsistema embedded dedicato al con-trollo remoto di apparecchiatureelettronico il suo utilizzo sarà sicura-mente riservato ad una cerchia moltoristretta di utenti di conseguenza sipuò ipotizzare che gli utenti del siste-ma possano essere definiti a priori.Ciò implica che il firmware del siste-ma deve essere programmato inmodo tale da inserire tutti i possibiliutenti del sistema.La gestione del database delle pas-sword ed user ID è effettuatamediante l’applet Java Stessa cheandrà a leggere un file crittografatoposto all’interno del file system diRECS 101.

Attacchi al protocollo IP e alla sicu-rezza dei pacchetti. Un attacco diquesto tipo viene in qualche motoridotto mediante la crittografia delpacchetto contente lo stato delleporte di I/O.Poiché come si è visto precedente-mente le porte di I/O di RECS 101sono codificate in un dato a 32 bit èpossibile inserire un algoritmo di crit-tografia che possa proteggere il con-tenuto dei dati. Nel caso in cui RECS101 venga utilizzato con una proprialogica di controllo con operazioni disniffing è pressoché impossibile risali-re all’algoritmo di controllo del siste-ma poiché questo è contenuto all’in-terno dell’applet.

Hyperlink Spoofing & WebSpoofing. L’implementazione di unsupporto SSL all’interno di RECS 101,per la sua complessità è pressochéimpensabile. Di conseguenza unattacco Hyperlink Spoofing sarebbepossibile. Per evitare ciò si può pen-sare di adoperare due RECS 101 chelavorando in parallelo uno controlligli stati dell’altro, in questo modo laprobabilità che entrambi i sistemivengano attaccati simultaneamentedecresce di molto. Per quanto riguar-

[1] Netid Managed Services, Information technology, NorthwesternTechnology: http://gradeswww.acns.nwu.edu/ist/snap/doc/sniffing.html

[2] Internet spoofing reference page:http://www.brd.ie/paper/sslpaper/hyperlin.html

[3] Web Spoofing: An Internet Con Game:http://www.cs.pronceton.edu/sip/pub/spoofing.html

[4] B. C. Neuman and T. Ts’o. Kerberos: An Authentication Service forComputer Networks. In IEEE Communications, volume 39, pages33–38.

[5] S.Fritzinger and M. Mueller. Java security, 1996. Sun MicrosystemsIncorporated, White Paper:http://java.sun.com/security/whitepaper.txt

[6] L. Gong. Secure Java Classloading. IEEE Internet Computing,2(6):56{61, November/December 1998.

[7] C. Kerer. A exible and extensible security framework for Java code.Master's thesis, Distributed Systems Group, Technical University ofVienna, Austria, October 1999.

[8] G. McGraw and E. Felten. Java security and type safety. Byte,22(1):63{64, January 1997.

[9] G. McGraw and E. W. Felten. Java security: hostile applets, holes, andantidotes. John Wiley, New York, 1997.

[10]G. McGraw and E. W. Felten. Securing Java: getting down to businesswith mobile code. John Wiley, New York, 1999.

[11]A. Rubin and D. E. Geer. Mobile Code Security.IEEE Internet Computing, 2(6):30{34, November/December 1998.

[12]Sun Microsystems, Incorporated. Secure computing with Java: nowand the future, September 1998. White Paper:http://java.sun.com/marketing/collateral/security.html

[13]F. Yellin. Low level security in Java. In Proceedings of the FourthInternational World Wide Web Conference, Boston, Massachusetts,USA, December 11{14, 1995, volume 1 of World Wide Web Journal.O'Reilly & Associates, Incorporated, November 1995.http://www.w3.org/pub/Conferences/WWW4/Papers/197/40.html

AUTOMAZIONE

BIBLIOGRAFIA

Electronic shop 28