Uma vez que eu garanta a segurança do prédio, estou a salvo dos ataques do Homem no Meio?

2

Digamos que quero me envolver em uma ação que pode ser comprometida por meio de um ataque man-in-the-middle (como troca de chaves). Fiz o meu melhor para garantir o fim da comunicação até o momento em que a rede sai do prédio: certifico-me de que minha máquina não está comprometida, não há dispositivos não reconhecidos em minha LAN, verifico que meu DNS não foi comprometido, etc. Meu parceiro também faz o mesmo em sua extremidade e ambos estamos confiantes de que um homem no ataque do meio não pode ser conduzido de dentro do prédio.

Qual a motivação de um invasor para comprometer a rede entre nós para conduzir um homem no ataque do meio? Estou assumindo que o governo dos EUA, com a cooperação dos ISPs, seria capaz de fazê-lo. Mas e quanto a fazê-lo sem a permissão do ISP?

Se eu estiver usando DSL, alguém poderia invadir o DSLAM local e inserir um proxy?

Eles poderiam desenterrar o fio no jardim da frente de alguém & comprometer isso?

É possível invadir remotamente os roteadores de backbone e fazer com que eles atuem como proxy?

A maioria das discussões sobre proteção contra ataques man-in-the-middle se concentra na rede local com a suposição implícita de que, uma vez que ela saia do seu prédio, é segura. Como isso é verdade na teoria & prática?

    
por Shalmanese 24.12.2009 / 22:15

3 respostas

2

A resposta geral de segurança é que algumas informações, por exemplo, segredo compartilhado ou outra chave, devem ser trocadas "fora da banda". Essa informação é então usada para criptografar a conexão entre os pontos finais e também para fornecer algum grau de autenticação. Se tudo passar por uma determinada conexão, nenhum ponto final poderá ter confiança em nenhum aspecto da conexão, pois um ou ambos os pontos finais podem ser falsificados por um homem no meio.

Mesmo para algumas conexões aparentemente em banda, como conexões SSL, há informações sendo trocadas fora da conexão SSL - os certificados para CAs (Autoridades de Certificação) são empacotados com o navegador quando você o instala, fora da banda do SSL eventualmente conexão entre você e seu banco (espero).

Quanto às discussões de segurança usuais, acho que a suposição implícita é oposta à descrita "uma vez que sai do seu prédio [ou segmento de rede ou máquina host], é seguro". Quando os dados estão fora do seu prédio, você não tem controle sobre eles, e os dados e a conexão são implicitamente inseguros. É por isso que você cria VPNs entre prédios - para que, se um invasor interferir na conexão, você tenha a chance de conhecê-la.

Talvez o que você tenha notado sobre as discussões de segurança de ponto final seja que um invasor tem mais facilidade em atacar um alvo específico se o invasor estiver perto de um dos pontos finais. Uma vez que uma conexão é multiplexada na rede principal da Telco, pode ser difícil distinguir uma conexão da outra. Talvez o que você tenha notado sobre as discussões de segurança de end-point é que muitas empresas fazem menos para a segurança de suas redes locais do que o ISP para proteger seu data center e, portanto, o end-point é mais fácil de atacar.

Se você realmente quiser se aprofundar na paranóia de garantir conexões de rede, dê uma olhada na Série de livros / relatórios sobre segurança do Rainbow (superada pelos Critérios Comuns para Avaliação e Validação, e Rainbow Series é um apelido mais cativante) .

    
por 25.12.2009 / 08:40
1

"Depois que eu garantir a segurança do prédio, estou a salvo dos ataques do Man in the Middle?"

Em uma palavra, não . Você não está seguro só porque conseguiu sair do prédio com segurança.

Exemplos de MITM tendem a girar em torno de um comprometimento de LAN ou host, porque esses são os veículos mais prováveis para um ataque MITM.

Explorando qualquer roteador entre você e seu colega, de várias maneiras (algumas das quais você mencionou), um invasor pode obter a capacidade de realizar um ataque MITM.

    
por 25.12.2009 / 02:09
0

Todos os itens que você sugeriu são possíveis embora improváveis .

Usar o SSL com certificados devidamente verificados é, de longe, a melhor ideia.

    
por 31.12.2009 / 12:27