Amazon Echo sono i device Amazon che portano l'assistente vocale Alexa nelle nostre case. In particolare gli Amazon Echo interagiscono con i servizi cloud Amazon al fine di sfruttare l'AI di Alexa e comunicare con una serie di servizi di terze parti. Se un amazon Echo opera dietro un firewall Stormshield potrebbe verificarsi la situazione in cui il device non rileva la connessione internet. In questa guida illustreremo come è possibile effettuare efficacemente un troubleshooting del problema e analizzeremo nel dettaglio le cause che lo generano.
Per prima cosa analiziamo i log per individuare eventuali azioni di blocco da parte del firewall, nell'immagine sotto ci troviamo nella visuale all events (all log nella 4.0) e ho impostato un filtro per sorgente. Il nome "echocucina" è una label ad un'oggetto che ho creato appositamente. Vi ricordo che nella visualizzazione dei log è possibile creare i filtri semplicemente trascinando il valore che ci interessa nella parte sinistra dello schermo.
Una volta impostata la visualizzazione si possono facilmente individuare i record relativi alle azioni di blocco.
Analizzando la riga relativa al blocco si evince che l'azione è stata compiuta dall'IPS in quanto è rilevata un'irregolarità nel protocollo HTTP (vi ricordo che il packet filtering agisce fino al livello 4 della pila ISO/OSI salvo alcune particolari eccezioni, nei livelli superiori opera l'IPS), nel caso specifico il problema è realtivo ad un pacchetto malformato o fuori standard che rende invalida l'analisi del protocollo HTTP, di fatto il messaggio Invalid HTTP protocol è abbastanza eloquente e il resto del messaggio (client data after request) ci dà anche un'idea di cosa ha causato questa anomalia.
Per un'analisi più approfondita occorre capire come è composto un'header HTTP, per far questo basta leggere l'RFC relativa al protocollo, in particolare la sezione 5 della RFC 2616
Leggendo il documento capiamo che ogni riga dell'header è delimitata da un CRLF (carriage return line feed, ossia i simboli ASCII \r\n che corrispondono al codice 13 e 10 o 0D 0A in esadecimale) e trermina con una linea vuota, ossia un singolo CRLF.
Ora che sappiamo come è fatto un header HTTP analiziamo meglio l'allarme, per far questo cerchiamone la descrizione nell'help online. Per faqr questo andiamo in Application Protection -> Application and Protection e cerchiamo "invalid http protocol" nell'apposita search box. Una volta individuato clicchiamo sulla voce HELP
La KB ci dice questo:
Sappiamo quindi che il problema è relativo a dei dati nel pacchetto che, secondo la RFC non dovrebbero essere lì. Verifichiamo ora quanto rilevato dal firewall, per far questo è comodo usare la funzione di cattura del pacchetto che genera l'allarme, tale funzionalità si abilità nella configurazione dell'allarme stesso, essendo un impostazione legata al profilo di ispezione è bene verificare preventivamente quale profilo ha agito nell'azione di blocco e poi modificare il relativo alert. Tornimao quindi sui log e verifichiamo il profilo di inspection analizzando i dettagli del log relativo al blocco:
Una volta verificato il profilo andiamo nuovamente in Application Protection -> Application and Protection e cerchiamo "invalid http protocol" sincerandoci di avere il corretto profilo selezionato
Ora configuriamo l'allarme tramite la voce Configure
La voce da selezionare è Capture the packet that raised the alarm
A questo punto occorre ricreare la situazione e generare un nuovo allarme, il pacchetto sarà disponibile per il download nella sezione Alarm sotto LOG nella colonna Captuerd Packet (selezionatela se è nascosta)
il pacchetto verrà scaricato con il formato pcap e sarà possibile aprirlo con wireshark:
Come potete vedere il pacchetto termina con tre CRLF (0D 0A), uno è il CRLF della riga contenente lo user agent, uno è il CRLF che dovrebbe delimitare l'header della richiesta (quello evidenziato) e c'è un'altro header a seguito dei primi due. Analizzando una GET verso il sito ANSA è possibile verificare che i CRLF sono solo due:
se a questo aggiungiamo quanto riportato nella sezione 4.3 della RFC 2616 è possibile dedurre che l'implementazione del protocollo HTTP in Amazon ECHO è errata
A questo punto è necessario capire a cosa serve questa chiamata. Da una veloce ricerca relativa all'url fireoscaptiveportal.com (destinazione del pacchetto droppato) capiamo che è un url usato per verificare la raggiungibilità di internet, quindi dal nostro punto di vista è possibile creare una regola di filtro in firewall mode e risolvere il problema
Con questo è tutto, come sempre non esitate a contattarci se avete bisogno di assistenza.
Uploading ....
