È possibile creare un firewall che consenta solo il traffico legittimo del server web sulla porta 443 e non altri servizi?

Ho sempre usato il semplice trucco per aggirare maggior parte dei firewall che mi ha impedito di utilizzare tutte le porte. Ho semplicemente aperto ssh su uno dei miei assistenti sulla porta 443 e tunneling tutto il traffico attraverso là.

Tuttavia ora sono su una rete che ha un firewall che non ho mai visto prima e non sapevo nemmeno che fosse possibile.

Su questa rete è possibile utilizzare la porta 443 solo per il traffico server web legittimo. Se apro ssh o qualsiasi altra cosa sulla porta 443 e provo a collegarmi da questa rete, viene immediatamente ucciso. Se avvio apache su quel server, funziona.

Come è possibile? Esistono firewall super sofisticati che sono persino in grado di analizzare il traffico crittografato per verificare che sia traffico https legittimo? Come?

networking ssh firewall

— Petr
fonte

Si chiama SPI, le apparecchiature di fascia alta possono eseguire ispezioni più avanzate e terminare connessioni indesiderate.

— Linef4ult

È possibile creare una lista bianca e consentire solo il traffico che il problema è che il traffico web server legittima è soggetta al cambiamento in quanto, gli indirizzi IP possono riassegnati, quindi quello che potrebbe essere Microsoft oggi potrebbe essere Google domani. Si sta meglio usando un tunnel sicuro per comunicare con i server, e la creazione di una whitelist di client che ha permesso, quindi determinare la procedura per aggiungere ulteriori clienti int egli futuro (perché tale elenco cambierà).

— Ramhound

Si potrebbe utilizzare ad esempio Obfsproxy per offuscare il traffico SSH come innocuo HTTP (S) del traffico.

— Michael

Sì, e non hanno bisogno di nessuna magia qui, appena corrispondenza banali sui contenuti dei pacchetti TCP. Anche se SSH e TLS (SSL) crittografano i loro payload , le stesse intestazioni di protocollo sono ancora distinguibili e molto diverse tra loro. Ad esempio, una connessione SSHv2 inizia sempre con l'invio del client SSH-2.0-(client name and version). Allo stesso modo, anche se il tuo firewall non può davvero sapere se la connessione TLS trasporta HTTP all'interno, può riconoscere TLS stesso .

Tale ispezionando di strati sopra TCP cade generalmente sotto "Deep Packet Inspection", una caratteristica relativamente comune.

Un modo ovvio per bypass è quello tunnel SSH all'interno TLS - per esempio, utilizzando stunnel, haproxy o sniproxy. (Oltre al semplice tunneling, in cui la porta 443 è dedicata a SSH-over-TLS, possono anche multiplexare SSH / HTTP / altri protocolli sulla stessa porta in base a SNI e ALPN.)

Anche se questo non sarebbe sempre sconfiggere davvero sofisticate analisi del traffico, sarebbe ancora bypass maggior parte dei filtri che si limita a controllare "Ti sembra un colpo di testa TLS".

E poi c'è il tipo fastidioso di firewall - quelli che TLS intercettano per decrittografare e crittografare nuovamente tutto il traffico. Questi possono effettivamente vedere all'interno TLS, e possono passare le richieste HTTP, bloccando tutto il resto. (Si noti che alcuni programmi antivirus anche fare la stessa cosa.) Si può riconoscere questo tipo, cercando nei certificati del server; tutti i certificati generati dal proxy hanno lo stesso aspetto e spesso non superano la convalida, mentre i certificati reali vengono emessi da varie CA diverse.

— grawity
fonte

Così SSH fa propria, la sicurezza a livello di applicazione, invece di essere solo un altro protocollo su TLS (che di default, non usa)?

— Medinoc

@Medinoc: Sì, implementa caratteristiche simili (nel "trasporto" SSHv2 e "Autenticazione" strati ) e non ha bisogno di TLS per nulla.

— grawity

C'è un modo affidabile per riconoscere questi firewall fiuto? Non mi piace l'idea che qualcuno intercetta le mie password durante l'utilizzo di HTTPS. Io non sapevo nemmeno che è possibile fino ad ora.

— Petr

POST / HTTP / 1.0 base64garbage HTTP / 200 200 OK base64garbage fa un protocollo di trasporto

— Joshua

@Petr Estendere osservazioni di grawity, se si tratta di un computer di datore di lavoro di proprietà i CERT erano probabilmente installati prima hanno dato a voi; e il firewall MITM sarà configurata in modo che se non si sta usando il loro cert senza traffico HTTPS sarà permesso in modo che le scelte sono conformi alla politica o non hanno https. OTOH in questo caso il controllo il CERT sarà probabilmente dire qualcosa come "verificato dal datore di lavoro Nome" e qualcosa di simile nel nome CA se si punta più in profondità. ad esempio sul mio computer di lavoro è bluecoat.companyname.com (dove Bluecoat è il marchio del firewall in uso).

— Dan Neely