Quão comum é bloquear conexões TCP de saída ou restringir a portas de serviço externo conhecidas (por exemplo, 22, 80, 443, 3306, etc.)? [fechadas]

1

Estou construindo um serviço que requer que os clientes se conectem a ele por meio de uma porta TCP. Ele estará acessível pela Internet em alguma porta conhecida (digamos 9999). Assim, os clientes precisariam abrir uma conexão TCP para "myhost.com:9999".

Especificamente, o serviço é direcionado a servidores da Web, incluindo pessoas que executam seus aplicativos em itens como o Heroku. Minha pergunta é: Quão comum é para servidores / hosts / provedores bloquear conexões TCP de saída?

Eu já vi isso algumas vezes na AWS, mas eles tendem a ser super-restritivos com suas configurações de VPC e assim por diante. Eu nunca realmente vi isso comumente feito em qualquer outro lugar, mas minha experiência é bastante limitada aqui. O Heroku bloqueia conexões TCP de saída? E quanto à nuvem do Azure?

Em suma, se meu serviço exigir que as pessoas se conectem ao meu servidor via TCP em uma porta específica, quanto do mundo eu estou excluindo do meu pool de usuários em potencial?

Nota: Antes de aparecer, estou pensando em proteger a conexão TCP com SSL / TLS. Ainda estou um pouco confuso nos detalhes, mas essa parte do quebra-cabeça de segurança está planejada.

Mais detalhes

Eu tenho um servidor central (S) e os usuários finais instalam uma camada de middleware que é o cliente (MW). MW abrirá uma conexão para S e enviar / receber periodicamente nela.

Os clientes não precisam implementar ou entender o protocolo, eles apenas instalam o MW (um Rubygem em Ruby, o pacote npm no Node, etc.) e fornecem algumas opções de configuração. MW manipula a compreensão do protocolo e a comunicação.

Neste momento, tudo é tratado com a pesquisa REST. Funciona, mas parece meio confuso e desnecessariamente verboso. S é escrito em Elixir, o que significa que, teoricamente, ele pode manipular um grande número de conexões abertas e ociosas. Então, parece uma boa idéia usar algo diferente de pesquisa REST.

Outra opção aqui seria websockets, onde o MW se conecta ao S por meio de um websocket. Talvez essa seja a melhor escolha praticamente, mas parece um pouco estranho para mim que estejamos em um mundo onde tudo acontece pela porta 80/443. Além disso, não tenho certeza de como é comum usar websockets para comunicação entre servidores. Eles parecem mais orientados para oferecer conteúdo a clientes JavaScript conectados.

Por fim, minha solução de pesquisa REST atual funciona e será dimensionada em um nível muito alto, muito mais alto do que jamais alcançarei. Estou apenas curioso sobre o que seria necessário para "fazer certo".

    
por Micah 14.09.2016 / 17:06

1 resposta

1

Esta questão pode ser marcada como sendo baseada em opinião, mas até que ela faça-

Minha opinião, sem saber mais detalhes, é que um porto personalizado é um grande obstáculo, não necessariamente no sentido de criar obstáculos à segurança, embora também o faça - mas o que é essencialmente solicitado aos clientes é Invente ou codifique um protocolo de aplicação personalizado, personalizado e desconhecido.

Mesmo se as bibliotecas do cliente forem enviadas em um ou outro idioma, haverá pessoas que essa abordagem deixa de fora. Os clientes Heroku são precisamente aqueles que não estão implementando protocolos personalizados.

A implantação de um serviço em uma porta sob medida usando um protocolo personalizado que visa a mercadoria Heroku sem outras informações de contexto, isso me parece inaceitável.

A pergunta é: por que não pode ser implantado como um serviço que os clientes da Web podem consumir, seja http ou websocket? O que está a faltar?

    
por 15.09.2016 / 03:39