É possível criar firewall que permita apenas tráfego legítimo de servidor da web na porta 443 e não qualquer outro serviço?

Eu sempre usei o truque simples para ignorar a maioria dos firewalls, o que me impedia de usar qualquer porta. Eu simplesmente abri o ssh em um dos meus servidores na porta 443 e encapsulei todo o tráfego por lá.

No entanto, agora estou em uma rede que possui firewall que nunca vi antes e nem sabia que era possível.

Nesta rede, você pode usar a porta 443 apenas para tráfego legítimo de servidores da web. Se eu abrir o ssh, ou qualquer outra coisa na porta 443 e tentar conectar-se lá a partir desta rede, ele será morto imediatamente. Se eu iniciar o apache nesse servidor, ele funcionará.

Como isso é possível? Existem firewalls super sofisticados capazes de analisar o tráfego criptografado para verificar se é tráfego https legítimo? Quão?

networking ssh firewall

— Petr
fonte

Chama-se SPI, equipamento de ponta pode fazer uma inspeção mais avançada e encerrar conexões indesejadas.

— Linef4ult 11/01

Você pode criar uma lista de permissões e permitir apenas que o tráfego, o problema é que o tráfego legítimo do servidor da Web esteja sujeito a alterações, pois os endereços IP podem ser reatribuídos, portanto, o que pode ser a Microsoft hoje pode ser o Google amanhã. É melhor usar um túnel seguro para se comunicar com seus servidores e criar uma lista de permissões de clientes permitidos; depois, determine o procedimento para adicionar outros clientes no futuro (porque essa lista será alterada).

— Ramhound 11/01

Você pode usar, por exemplo, Obfsproxy para ofuscar o tráfego SSH como tráfego HTTP (S) inofensivo.

— Michael

Sim, e eles não precisam de mágica aqui, apenas uma correspondência trivial no conteúdo do pacote TCP. Embora SSH e TLS (SSL) criptografar as cargas , os cabeçalhos de protocolo próprios são ainda distinguíveis e muito diferentes umas das outras. Por exemplo, uma conexão SSHv2 sempre começa com o envio do cliente SSH-2.0-(client name and version). Da mesma forma, embora seu firewall não possa realmente saber se a conexão TLS carrega HTTP dentro, ele pode reconhecer o próprio TLS .

Essa inspeção das camadas acima do TCP geralmente se enquadra na "Deep Packet Inspection", um recurso relativamente comum.

Uma maneira óbvia de contornar isso é encapsular o SSH no TLS - por exemplo, usando stunnel, haproxy ou sniproxy. (Além do encapsulamento simples, em que a porta 443 é dedicada ao SSH sobre TLS, eles também podem multiplexar SSH / HTTP / outros protocolos na mesma porta, com base no SNI e no ALPN.)

Embora isso nem sempre anule a análise de tráfego realmente sofisticada, ainda contornaria a maioria dos filtros que apenas verificam "isso parece um cabeçalho TLS".

E depois há o tipo irritante de firewalls - os que interceptam o TLS para descriptografar e criptografar novamente todo o tráfego. Eles podem realmente ver dentro do TLS e podem passar solicitações HTTP enquanto bloqueiam todo o resto. (Observe que alguns programas antivírus também fazem a mesma coisa.) Você pode reconhecer esse tipo observando os certificados do servidor; todos os certificados gerados por proxy têm a mesma aparência e geralmente não passam na validação, enquanto os certificados reais são emitidos por várias CAs diferentes.

— gravidade
fonte

Portanto, o SSH possui sua própria segurança no nível do aplicativo, em vez de ser apenas outro protocolo sobre TLS (que, por padrão, ele não usa)?

— Medinoc 11/01

@Medinoc: Sim, ele implementa características semelhantes (no "transporte" SSHv2 e "Autenticação" camadas ) e não precisa de TLS para nada.

— grawity

Existe alguma maneira confiável de reconhecer esses firewalls farejadores? Não gosto da ideia de que alguém intercepte minhas senhas enquanto estiver usando https. Eu nem sabia que era possível até agora.

— Petr

POST / HTTP / 1.0 base64garbage HTTP / 200 200 OK base64garbage faz um protocolo de transporte

— Joshua

@Petr Estendendo as observações do grawity, se for um computador de propriedade de um empregador, os certificados provavelmente foram instalados antes de serem entregues a você; e o firewall do MITM será configurado para que, se você não estiver usando o certificado deles, nenhum tráfego https seja permitido, de modo que suas escolhas estejam em conformidade com a política ou não possuam https. A OTOH, nesse caso, a verificação do certificado provavelmente dirá algo como "verificado pelo Nome do Empregador" e algo semelhante no nome da CA, se você aprofundar. por exemplo, no meu computador de trabalho, é bluecoat.companyname.com (onde bluecoat é a marca do firewall que está sendo usado).

— Dan Neely