I router SOHO serie 800 (es. 877) e i moduli HWIC-1ADSL supportano ITU G.992.5 (ADSL2+) ma hanno mostrato con vari DSLAM numerosi problemi di stabilità.

Cisco incorpora in IOS il firmware per il chipset xDSL, e tipicamente è la versione 2.x per le HWIC-1ADSL e la versione 3.x per i router che hanno l’interfaccia xDSL on-board.

Nei nostri test in laboratorio e su circuiti reali abbiamo riscontrato che i firmware embedded sono troppo vecchi per operare in modalità ADSL 2+ con attenuazione lato ATU-R superiore a 25db, mentre con l’ultimo firmware versione 4.0.15 tutti i problemi di stabilità sono stati risolti.

Il firmware 4.0.15 non è ancora incorporato nelle versioni di IOS in produzione, è disponibile via Cisco CCO avendo una login non-guest e va caricato sulla flash del router da aggiornare con il nome “adsl_alc_20190.bin”:

All’avvio, IOS verifica se è disponibile sulla flash un firmware alternativo e carica d’ufficio quello sul processore xDSL: al primo reboot successivo alla preparazione dell nuovo firmware in flash, si può verificare che sia stato caricato correttamente così:

In alcuni particolari casi (ad es. se le caratteristiche elettriche-fisiche del doppino subiscono delle fluttuazioni cicliche), il modem xDSL Alcatel 20190 può tendere ad effettuare numerosi re-training (con conseguenti “cadute di portante” e cambio di stato sul livello 1): per ovviare a questi casi è possibile far considerare al modulo xDSL di avere un margine di rumore inferiore rispetto a quello effettivamente disponibile, obbligandolo ad allinearsi ad un bitrate inferiore:

Il comando specifica (anche in negativo, quindi utilizzabile addirittura adducendo una migliore sensibilità di quella rilevata) l’attenuazione in passi da 0.5db (”dsl noise-margin 1″ nell’esempio equivale a ridurre il margine di rumore di 0.5db).

Nei giorni 2 e 5 Gennaio 2008 effettueremo una manutenzione straordinaria nel POP di Milano: il nostro backoffice tecnico (0376 263639) sarà disponibile da mercoledì 7 Gennaio.

Il servizio di reperibilità sarà, come sempre, garantito. I problemi segnalati in segreteria verranno gestiti entro 4 ore.

Fidarsi della sicurezza di prodotti “completamente chiusi” nel tempo è risultata una scelta, spesso, disastrosa: anche per questa ragione la rete Mynet, sebbene basata anche su prodotti di vendor che non rilasciano il sorgente dei propri software, si avvale di quelli che abbracciano “security best practices” ben delineate e cercano, dove possibile, di onorare il naturale e salutare (dal punto di vista della sicurezza informatica) ecosistema nel campo dell’IT e dell’intranetworking.

DECT è un maturo standard di telefonia cordless: è stato proposto come la risoluzione definitiva ai problemi di sicurezza in questo campo (oltre a quelli di interoperabilità e di qualità della fonia) rispetto a sistemi precedenti e non standardizzati che trasmettevano la fonia in modulazione di frequenza e la segnalazione in banda, facilmente intercettabili e banalmente utilizzabili come vettori per effettuare frodi. Il sistema DECT basa la sua sicurezza su un sistema di autenticazione denominato DSAA e su un cipher denominato DSC. Etrambi i sistemi di sicurezza vengono ceduti dall’ETSI (similmente ai “segreti” dell’UMTS e del GSM) solo attraverso una NDA che perentoriamente vieta al firmatario la diffusione del dettaglio degli stessi. Al CCC Communication Congress Andreas Schuler, Erik Tews, Ralf-Philipp Weinmann hanno presentato un paper sulla sicurezza DECT, delineando quanto segue:

• Sniffare il protocollo DECT attraverso USRP è possibile, ma assolutamente non “tecnicamente comodo”
• Sniffare il protocollo DECT attraverso una scheda PCMCIA “Com-On-Air” è risultata la via migliore: con duro lavoro è stato possibile fare ingegneria inversa del driver di Windows per realizzarne uno per Linux, nonché analizzare il chip della National che si occupa specificatamente della gestione DECT e ne contiene i “segreti”.
• Molti telefoni DECT non richiedono nessun tipo di autenticazione con la base. Spesso la crittografia non è attiva. I telefoni accettano di essere redirezionati (handover) su una base senza crittografia anche se la telefonata in corso, prima dell’handover, era di tipo criptato. E’ possibile impersonare le funzionalità di una base DECT.
• Attraverso un duro lavoro di ingegnieria inversa dell’hardware, è stato possibile derivare una implementazione dell’algoritmo di DSAA, ed è ipotizzabile creare un attacco con forza bruta, ottimizzabile attraverso hardware dedicato basato su FPGA.
• Apparentemente contrariamente a quanto richiesto nello NDA, Alcatel Standard Eléctrica SA di Madrid ha registrato, a metà anni ‘90, un brevetto (5608802) negli USA che, presentando un sistema di risparmio energetico per il sistema di generazione di numeri pseudocasuali del cipher DECT, ne rivela parzialmente il funzionamento: le informazioni del brevetto unite al lavoro di ingegneria inversa dell’hardware a breve permetteranno di ricostruire completamente l’algoritmo DSC; dalla sua criptoanalisi e (probabilmente) dalle sue vulnerabilità (è un algoritmo non scrutinato dalla comunità scientifica), si potrebbe ottenenre la possibilità di intercettare anche comunicazioni criptate senza conoscere i seed originari, nonché altre interessanti “applicazioni”.

Quanto sopra significa che le comunicazioni telefoniche (e in alcuni casi, non telefoniche, come per i POS DECT, salvo protocolli aggiuntivi di sicurezza) sono da considerarsi assolutamente non confidenziali (ovvero facilmente intercettabili). Inoltre, a breve (quando si affineranno le tecniche di epxloit e l’analisi di sicurezza sul sistema sarà più completa), diventerà imperativo, per chi usa reti DECT, implementare un sistema di sicurezza che effettui alerting del traffico anomalo sulle reti DECT aziendali (o limitarne l’uso al solo traffico inbound o anche in uscita ma solo tramite operatore).