2019

GuruNetwork.it di Massimo Martini è stata nominata WatchGuardONE Silver Partner da WatchGuard® Technologies, leader globale in multi-function firewalls.

WatchGuard’s Silver level ci rappresenta come partner impegnato nei più alti livelli di security expertise con servizi WatchGuard.

About WatchGuard Technologies, Inc.

WatchGuard è leader mondiale per le soluzioni business di sicurezza informatica integrate e multi funzione che combinano l’industria standard hardware, le features di sicurezza più evolute e tools appositi per la gestione delle policies. WatchGuard prevede appliances di facile uso ma dotate di potenti strumenti di protezione a livello enterprise e conta decine di migliaia di installazioni in tutto il mondo. WatchGuard ha sede in Seattle, WA, con sedi in Nord America, Europa, Asia e Latino America.

---

TECHNICAL FOCUS

La pubblicazione tecnica di IPJ [Winter2019 issue]
I focus di questo numero: i valori del parametro MSS nelle connessioni TCP ed il compleanno (50 anni… auguri!) di Internet.

TCP MMS
In questa disamina Geoff Huston analizza quali sono i valori consigliati del parametro TCP MSS, Maximum Segment Size, alla luce di una recente vulnerabilità scoperta nei sistemi Linux che adottano nello loro stack valori di MMS sotto i 500 byte.
Il paramentro MSS è parte di un campo “Option” nel processo iniziale di 3-Way handshake che specifica la massima ampiezza di dati che uno speaker può ricevere in un singolo segmento TCP. Ogni end di direzione di traffico TCP (client<->server) usa il suo valore di MMS, senza l’obbligo di negoziare un comune valore.
In linea teorica la sessione TCP non è coinvolta nell’operazione di frammentazione a livello IP qual’ora la lunghezza dell’intero pacchetto IP superi il valore del parametro MTU, Maximum Transmission Unit. In pratica è consigliato un settaggio giudizioso del valore di MSS che eviti di produrre a livello IP la frammentazione del pacchetto.
Ma qual’è può essere un buon valore di MSS ?
Il valore del MSS non contiene ne l’header IP ne l’header TCP. Con un valore di norma di MTU pari a 1500 ottetti sia per IPv4 che IPv6, si ottiene un valore di MSS di 1460 byte per IPv4 e 1440 byte per IPv6.
Sino a 10 anni fa tali valori erano sconsigliati per un problema legato ai tunnel di incapsulazione IPv6-in-IPv4 nei percorsi di transito IP.
Ora se noi usiamo un valore MTU di riferimento di 1480 byte, otterremo un valore corrispondente di TCP MSS pari a 1420 byte per IPv4 e di 1440 byte per IPv6, con il risultato di avere un servizio TCP adeguatamente attendibile.

50’s Internet Birthday
Vint Cerf, uno dei pionieri di Internet, ricorda questa importante ricorrenza, l’inizio di una nuova era.
Il 29 Ottobre del 1969 venne posta la pietra miliare nelle connessioni tra computer, più precisamente tra XDS Sigma-7 computer dell’Università di California, Los Angeles (UCLA) ed il time-shared SDS 940 computer del Stanford Research Institute (SRI).
Questi furono i primi due computer collegati previsti dal progetto ARPANET, Advanced Research Projects Agency Network, prima rete di computer studiata dall Agenzia dal Dipartimento di Difesa degli Stati Uniti d’America (DARPA), forma embrionale della rete Internet. A questi due computer eterogenei, chiamati hosts, se ne aggiunsero altri due nel Dicembre del 1969, uno dell’Università di California, Santa Barbara (UCSB), l’altro dell’Università dello Utah, Salt Like City.
Nacque così la prima rete di computer a commutazione di pacchetto, packet switching communication network, attraverso un circuito telefonico dedicato a 50 kbps.
Il protocollo FTP, File Transfer Protocol, e il protocollo TELNET, remote-access telecommunications network, furono le prime applicazioni usate da ARPANET e successivamente traslate in Internet.
Un altro merito del progetto ARPANET fu il lancio di una serie di documenti chiamati RFC, Request for Comments, che ancora adesso documentano ufficialmente i protocolli che compongono Internet.

La pubblicazione tecnica di IPJ [Summer2019 issue]
I focus di questo numero: le ragioni che portano all’utilizzo del protocollo DoH, e la sicurezza nel campo del routing protocol negli ISP (MANRS).

DoH
Nel primo articolo Geoff Huston ci illustra come l’utilizzo di un nuovo standard chiamato DoH, DNS over HyperText Transfer Protocol Secure, può coprire l’attuale mancanza di sicurezza e segretezza dovute alle normali queries DSN che transitano in chiaro.
In sostanza si delegherebbe direttamente ai browsers le queries DNS, invece di lasciare che il sistema consulti un DNS cache-resolver autonomo (es. 8.8.8.8, 9.9.9.9, 208.67.222.222, etc).
A fronte di un vantaggio di security così evidente c’è il rischio fondato che giganti come Google, il quale detiene con il suo browser Chrome più del 60% del mercato, possano, in mancanza di un regolamento esplicito, usare a fini commerciali le informazioni che il proprio broswer filtra come richieste DNS.

MANRS
Nel secondo articolo Andrei Robachevsky di Internet Society spiega l’importanza di utlizzare un set di “best practice” chiamate MANRS, Mutually Agreed Norms for Routing Security, da parte delle società di Internet Service Provider.
Ogni anno, infatti, hijacking, route leaks, IP spoofing e altre tecniche dannose, portano ad attachi DoS, Denied of Service, che causano seri problemi sulla sicurezza degli istradamenti nei router BGP degli ISP, o delle interruzioni di servizio. Le società di network che operano in questo campo (60mila ca.) hanno libero arbitrio per quanto riguarda eventuali azioni di sicurezza che vogliono intraprendere e non hanno relazioni tra loro.
Questo set di norme appositamente definite vuole offrire un insieme di azioni che hanno come obbiettivo rendere attendibili e stabili le operazioni di routing di ognuno degli ISP che aderiranno a questa community.

La pubblicazione tecnica di IPJ [Spring2019 issue].
I focus di questo numero: il protocollo QUIC, come alternativa al TCP per traffico web e il problema dei key-tags usati sui DNSSEC. 

QUIC
Geoff Huston spiega come il nuovo protocollo chiamato QUIC, Quick UDP Internet Connection, inizialmente sviluppato e utilizzato da Google ed ora standardizzato dall’IETF, sia un protocollo a livello trasporto più efficente rispetto al classico TCP, specialmente per le sessioni HTTP/HTTPS.
Visto come un datagram TCP incapsulato e cifrato come payload entro un datagram UDP, le applicazione che ne fanno uso spediscono e ricevono pacchetti UDP su porta 443.
Diversamente dal TCP i pacchetti QUIC non possono essere frammentati, ma questo non ne limita le potenzialità ne l’efficenza del suo utilizzo.

KEY-TAGS DNSSEC
Nel secondo articolo, Roy Arends, ricercatore scientifico di ICANN, affronta i problemi legati ai key-tag, valori a 16-bit generati tramite funzioni simili alle funzioni di checksum, che aiutano ad indentificare le chiavi di crittografia usate sui DNSSEC, Domain Name System Security Extensions, serie di specifiche ed estensioni che permettono ai caches-resolverDNS di autenticare i dati ricevuti dai root DNS.
Viene dimostrato come l’utilizzo di queste funzione checksum per identificare le chiavi di crittografia non è ottimale.
Essi, infatti, sono stati progettati fondamentalmente per verificare l’integrità dei dati e di errori presenti in questi.