Curso MIT "Segurança de sistemas de computadores". Palestra 12: Segurança de Rede, Parte 1

Instituto de Tecnologia de Massachusetts. Curso de Aula nº 6.858. "Segurança de sistemas de computador". Nikolai Zeldovich, James Mickens. 2014 ano

Computer Systems Security é um curso sobre o desenvolvimento e implementação de sistemas de computador seguros. As palestras abrangem modelos de ameaças, ataques que comprometem a segurança e técnicas de segurança baseadas em trabalhos científicos recentes. Os tópicos incluem segurança do sistema operacional (SO), recursos, gerenciamento de fluxo de informações, segurança de idiomas, protocolos de rede, segurança de hardware e segurança de aplicativos da web.

Palestra 1: “Introdução: modelos de ameaças” Parte 1 / Parte 2 / Parte 3
Palestra 2: “Controle de ataques de hackers” Parte 1 / Parte 2 / Parte 3
Aula 3: “Estouros de Buffer: Explorações e Proteção” Parte 1 / Parte 2 / Parte 3
Palestra 4: “Separação de Privilégios” Parte 1 / Parte 2 / Parte 3
Palestra 5: “De onde vêm os sistemas de segurança?” Parte 1 / Parte 2
Palestra 6: “Oportunidades” Parte 1 / Parte 2 / Parte 3
Palestra 7: “Sandbox do Cliente Nativo” Parte 1 / Parte 2 / Parte 3
Aula 8: “Modelo de Segurança de Rede” Parte 1 / Parte 2 / Parte 3
Aula 9: “Segurança de aplicativos da Web” Parte 1 / Parte 2 / Parte 3
Palestra 10: “Execução Simbólica” Parte 1 / Parte 2 / Parte 3
Aula 11: “Linguagem de Programação Ur / Web” Parte 1 / Parte 2 / Parte 3
Aula 12: Segurança de rede Parte 1 / Parte 2 / Parte 3

Hoje falaremos sobre segurança de rede, em particular, discutiremos um artigo de Stephen Bellovin intitulado "Uma retrospectiva de" Problemas de segurança no conjunto de protocolos TCP / IP "". Esse cara trabalhava na AT&T e agora trabalha na Colômbia. O interessante neste trabalho é que ele é relativamente antigo - tem mais de 10 anos e, de fato, esses são comentários sobre um artigo publicado uma década antes em 1989.

Muitos de vocês perguntam por que estudamos isso se muitos dos problemas descritos lá foram resolvidos nas versões atuais do protocolo TCP.



É verdade que alguns dos problemas descritos por Stephen foram resolvidos e alguns continuam sendo problemas. Com isso em mente, vamos classificá-los e ver o que acontece. Você pode se perguntar por que as pessoas não resolveram todos esses problemas ao projetar o TCP? O que eles estavam pensando?

E isso não está claro. O que você acha? Por que o protocolo TCP não possui a segurança necessária, considerando todas essas considerações? Alguma sugestão?

Aluno: Naquela época, a Internet era um lugar muito mais ingênuo.

Professor: sim, foi literalmente uma citação do artigo desse cara. Sim, naquela época em geral ... um conjunto de protocolos da Internet foi desenvolvido, penso, cerca de 40 anos atrás. Os requisitos eram completamente diferentes. Era apenas necessário conectar um monte de sites relativamente ingênuos que se conheciam pelo nome a uma rede comum.

Eu acho que isso geralmente acontece em qualquer sistema que tenha sucesso - ele precisa de mudanças. Costumava ser um protocolo para um pequeno número de sites, agora este protocolo cobre o mundo inteiro. E você não sabe mais pelo nome de todas as pessoas conectadas à Internet. Você não pode ligar para eles se eles fizerem algo ruim e assim por diante.

Portanto, acho que essa história é a mesma para muitos dos protocolos que estamos considerando. E muitos de vocês estão fazendo uma pergunta como: “que diabos esses caras estavam pensando? Isso é tão falho! Mas, na realidade, eles projetaram um sistema completamente diferente, simplesmente o adaptaram às necessidades modernas.

A mesma coisa, e a Internet, como vimos nas últimas duas semanas, foi projetada para uma finalidade completamente diferente. Mas ele se expandiu e tivemos novas preocupações sobre como adaptar esse protocolo aos requisitos modernos.

Outra coisa aconteceu de repente: as pessoas tiveram que superestimar a gravidade do problema de segurança. Antes, você realmente não entendia tudo o que deveria se preocupar, porque não sabia o que o atacante era capaz de fazer com seu sistema.



Acho que, em parte, por esse motivo, será interessante ver o que aconteceu com a segurança do TCP, o que deu errado, como podemos corrigi-lo e assim por diante. Como resultado, precisamos descobrir que tipos de problemas devem ser evitados ao desenvolver nossos próprios protocolos, bem como o que constitui um pensamento adequado sobre ataques desse tipo. Como você sabe o que um invasor é capaz de fazer em seu próprio protocolo quando você o está desenvolvendo para evitar essas armadilhas?

Ok, vamos deixar o preâmbulo de lado e falar sobre este artigo.

Então, como devemos pensar em segurança de rede? Acho que poderíamos começar com o primeiro princípio e tentar descobrir qual é o nosso modelo de ameaça. Então, o que um invasor pode fazer em nossa rede?

Ele provavelmente tem a capacidade de interceptar pacotes e talvez seja capaz de modificá-los. Portanto, se você estiver enviando um pacote pela rede, é aconselhável supor que algum bandido verá seu pacote e poderá alterá-lo antes que ele chegue ao seu destino. Ele também pode descartá-lo e usar a capacidade de inserir pacotes personalizados com conteúdo arbitrário que você nunca enviou.



Mas mais perigosa é a possibilidade de bandidos interferirem nos seus protocolos descritos no artigo. O atacante tem seu próprio computador, que ele controla completamente. Mesmo que todos os computadores em que você confie estejam se comportando corretamente, o bandido que possui seu próprio computador pode interferir no seu protocolo ou sistema.

Portanto, se você tem um protocolo de roteamento que envolve muitas pessoas conversando entre si, e algumas reduções são provavelmente impraticáveis ​​para manter os bandidos do lado de fora. Se um protocolo de roteamento com 10 participantes estiver em execução, talvez você possa ligar para todos eles e dizer: "Bem, sim, pessoal, eu conheço todos vocês".

Mas na escala da Internet hoje em dia é impossível descobrir diretamente quem os outros membros da rede estão usando esse protocolo. Então, provavelmente, um bandido vai participar de seus protocolos ou sistemas distribuídos. Portanto, é importante projetar sistemas distribuídos que, no entanto, possam fazer algo razoável com isso.

OK, então quais são as implicações disso tudo? Eu acho que vamos analisar a lista. A interceptação de pacotes geralmente é fácil de entender, você não pode enviar dados importantes pela rede se espera que o bandido os intercepte ou pelo menos não os envie em texto sem formatação. Talvez você deva criptografar seus dados.



Parece relativamente fácil de entender, embora você ainda precise manter isso em mente ao desenvolver protocolos. A introdução ou injeção de pacotes leva a uma gama mais ampla de problemas interessantes, discutidos neste artigo. Em particular, os invasores podem injetar pacotes que podem representar pacotes de qualquer outro remetente. Como o caminho de transmissão de dados é baseado no uso de IP, o próprio pacote possui um cabeçalho que indica o IP de origem do pacote e o IP de destino. No entanto, ninguém verifica se a fonte está necessariamente correta. Atualmente, existe alguma filtragem, mas não é perfeita e é difícil confiar nela.

Portanto, em uma primeira aproximação, um invasor pode inserir qualquer endereço IP como fonte e enviá-lo para o destino correto. É interessante descobrir o que um invasor pode fazer com a capacidade de enviar pacotes arbitrários.

Nas semanas anteriores, analisamos os problemas de estouro de buffer em termos de segurança na web. Examinamos como um invasor pode usar um erro de implementação, como estouros de buffer. Curiosamente, o autor deste artigo não estava realmente interessado em erros de implementação; ele está mais interessado em erros de protocolo.

Então, o que há de tão especial nisso? Por que ele não prestou atenção nos erros de implementação, apesar de termos passado várias semanas para examiná-los? Por que isso importa?

Aluno: porque devemos descartar esses erros ao escrever o protocolo.

Professor: sim, isso é realmente uma grande falha devido a um erro no design do protocolo, porque é difícil mudar. Portanto, se você tiver um erro de implementação e tiver uma memória ou impressão que não verificou o intervalo de memória, não será possível notar esse erro. Mas se você tiver uma verificação de intervalo e ela ainda funcionar, os estouros de buffer poderão ser evitados, portanto, isso é ótimo.

Mas se você tiver algum tipo de erro na especificação do protocolo, em como o protocolo deve funcionar, a correção de um erro exigirá a correção de todo o protocolo, o que significa um impacto potencial em todos os sistemas que falam esse protocolo. Portanto, se encontrarmos algum tipo de problema no protocolo TCP, potencialmente será bastante destrutivo. Como todas as máquinas que usam TCP precisarão fazer alterações, pois é potencialmente muito difícil tornar um protocolo modificado compatível com a máquina antiga.

Os erros do protocolo TCP com os quais Stephen estava tão preocupado eram fundamentais, então ele decidiu falar sobre eles. No primeiro exemplo, ele analisa como os números do SN SN do TCP funcionam.

Aluno: esse tópico é um pouco estranho, mas estou curioso. Suponha que você encontre um erro no TCP. Como você faz alterações? Como você diz a todos os computadores do mundo que isso precisa ser alterado?

Professor : Sim, acho que esse é um problema enorme. O que fazer se você encontrar um erro no TCP? Bem, não está claro o que fazer. Eu acho que o autor aqui está lutando com isso. Se você pudesse reprojetar o TCP, muitos desses erros serão relativamente fáceis de corrigir se você souber com antecedência o que procurar.

Mas como o TCP é bastante difícil de corrigir ou alterar, acontece o seguinte: os desenvolvedores tentam encontrar configurações compatíveis com versões anteriores que permitem que as implementações antigas sejam usadas em conjunto com a nova implementação ou adicionam algum campo adicional que torna a conexão um pouco mais segura.



Mas este é um grande problema. Se esse é algum tipo de problema de segurança profundamente enraizado no TCP, ele se tornará um grande problema para todos, porque é muito difícil até mesmo mudar para a versão TCP, suponha que n mais 1.

O IPv6 pode ser visto como um exemplo de que isso não acontece e sabemos que esse problema ocorrerá por mais 15 ou 20 anos. O IPv6 existe há mais de 10 anos, mas é difícil convencer as pessoas a se afastarem do IPv4. O IPv4 é suficiente para eles, parece funcionar, e eles acham que mudar para um novo protocolo da Internet será muito caro. Eles dizem: “ninguém mais fala IPv6, então por que devo começar a falar sobre esse protocolo estranho com o qual não há ninguém para conversar comigo?” De qualquer forma, esse é um tipo de avanço, mas acho que levará muito tempo. Realmente haverá alguma motivação para a migração, e a compatibilidade com versões anteriores, neste caso, ajuda muito.

O IPv6 tem muitas opções de compatibilidade com versões anteriores, por exemplo, você pode conversar com um host IPv4 usando o IPv6. Portanto, os desenvolvedores estão tentando projetar todo esse suporte, mas ainda é difícil convencer as pessoas a atualizar.

Portanto, considerando os números de sequência TCP, vamos considerar dois problemas relacionados à maneira como o handshake TCP funciona. Então, vamos passar algum tempo olhando como uma conexão TCP é inicialmente estabelecida.

Três pacotes são enviados para estabelecer uma nova conexão TCP. Nosso cliente gera um pacote para se conectar ao servidor, que diz que aqui está o endereço IP do meu cliente, eu o envio ao servidor. Ao mesmo tempo, existe uma estrutura de cabeçalho de pacote composta por áreas diferentes, mas estaremos interessados ​​na área do número de série. Aqui teremos o sinalizador SYN dizendo: "Quero sincronizar o estado e estabelecer uma nova conexão", e inclui o número de série do cliente SNc.



Então, quando o servidor recebe esse pacote, ele diz: "o cliente quer se conectar a mim, então enviarei o pacote para esse endereço, independentemente de quem diga que está tentando entrar em contato comigo". Assim, o servidor enviará o pacote ao cliente, onde inclui seu próprio número de sequência de sincronização do servidor SNs e o número de confirmação do cliente ACK (SNc). Finalmente, no terceiro pacote, o cliente responde ao servidor, confirmando a sincronização e enviando o número de confirmação (SNs) do servidor ACK do servidor para o servidor. Agora o cliente pode começar a enviar dados.

Assim, para enviar dados, no início da conexão, o cliente deve incluir alguns dados no pacote e anexar o número de série do cliente SNc para indicar que esses são realmente dados legítimos do cliente. Ele ressalta, por exemplo, que não são alguns dados de mensagens posteriores que acabam de chegar agora, porque o servidor perdeu algumas das partes iniciais dos dados.



Assim, como regra, todos esses números de série são projetados para fornecer entrega de pacotes. Se o cliente transmitir dois pacotes, aquele que possui o número de sequência inicial é o primeiro dado, o próximo número de sequência é o próximo dado. Também é útil para fornecer alguns requisitos de segurança.

Antes disso, dei um exemplo de que esses requisitos estão mudando. Portanto, inicialmente ninguém pensou que o TCP deveria fornecer recursos de segurança. Mas então o TCP começou a usar aplicativos, e eles pareciam confiar nessas conexões TCP, acreditando que não poderiam ser quebrados por nenhum invasor ou que o invasor não foi capaz de injetar dados maliciosos na conexão TCP existente. Como se de repente esse mecanismo, originalmente destinado apenas a pedidos de pacotes, começasse a garantir alguma aparência de segurança para essas conexões.

Portanto, neste caso, suponho que o problema esteja relacionado ao que o servidor poderia ter sugerido em relação a essa conexão TCP. Normalmente, o servidor assume - implicitamente, como você pode imaginar - que essa conexão seja estabelecida com o cliente desejado nesse endereço IP C, e é natural que ele pense assim. Mas existe alguma razão para tal suposição? Se o servidor receber uma mensagem com alguns dados sobre essa conexão cliente-servidor e tiver um número de sequência C, por que o servidor conclui que o cliente real enviou esses dados?

Aluno: porque o número de série é difícil de adivinhar.
Professor: certo, então isso é um tipo de coisa implícita, o que implica que deve haver um número de sequência SNc correto. E para que essa conexão seja estabelecida, o cliente deve ter um número de série do servidor SNs confirmado e o número de série do servidor é enviado pelo servidor apenas para o endereço IP do cliente.

Aluno: quantos bits estão disponíveis para o número de sequência?

Professor: O número de sequência do TCP tem 32 bits e, embora não seja um número aleatório, não é fácil adivinhar, seria necessário muita largura de banda.

Aluno: o número de série é maior que o número de série inicial?

Professor: sim, em princípio, essas coisas estão aumentando. Portanto, toda vez que você envia SYN, é considerado 1 byte a mais que o seu número de sequência. Ou seja, se na primeira linha tivemos o argumento (SNc), na quarta já haverá (SNc + 1) e, em seguida, a numeração continua daqui. Portanto, se você transferir 5 bytes, o valor a seguir (SNc) +6 será o seguinte. Ele simplesmente conta os bytes enviados, com cada SYN contando 1 byte. A especificação TCP recomenda escolher esses números de série para que seu incremento ocorra a uma velocidade aproximadamente fixa. Os documentos de trabalho iniciais do protocolo RFC sugeriam que você aumentasse essas coisas em aproximadamente 250.000 unidades mais 250.000 por segundo.



A razão pela qual isso não foi completamente aleatório é porque esses números de sequência são realmente usados ​​para impedir que pacotes falhem em intervir ou para misturar pacotes de conexões anteriores com novas conexões. Cada vez que você estabelece uma nova conexão, escolhe um número de série completamente aleatório. Ao mesmo tempo, há alguma chance de que, se você instalar uma série de conexões repetidas vezes, um pacote da conexão anterior terá um número de sequência bastante semelhante ao número de sequência da sua nova conexão e, portanto, será aceito pelo servidor como parte válida dos dados para a nova conexão.

Portanto, é com isso que os desenvolvedores de TCP estavam muito preocupados - esses pacotes não ordenados ou pacotes atrasados. Como resultado, eles realmente queriam que esses números de sequência fossem uma sequência de tempo bastante monótona, mesmo entre os compostos.

Se eu abrir uma conexão, ela poderá ter a mesma origem e destino, números de porta, endereços IP e assim por diante. Mas desde que eu estabeleci essa conexão agora, e não antes, espero que os pacotes das mensagens enviadas anteriormente não coincidam com os números de sequência que tenho para minha nova conexão. Portanto, esse era um mecanismo para evitar confusão entre conexões repetitivas.

Aluno: se você não sabe exatamente qual será a etapa da sequência do pacote, como você sabe que o pacote que você recebe é o próximo pacote e não faz parte do anterior que você ...

Professor: Como regra geral, você se lembra do último pacote recebido. E o próximo número de sequência é exatamente o próximo pacote na sequência. Assim, por exemplo, o servidor sabe que vi exatamente uma parte dos dados da data (SNc +1); o próximo será o pacote SYN (SNc +1), porque o pacote anterior no início da conexão era SYN (SNc).

Aluno: então, você diz que quando define o número de série, mesmo depois disso ...

Professor: bem, é claro, esses números de série, inicialmente, quando você os instala, são selecionados de acordo com algum plano. Vamos falar sobre esse plano. Você pode pensar que eles são aleatórios, mas com o tempo eles devem representar algum fluxo seqüencial de alterações nos números de sequência iniciais da conexão.

Mas em uma conexão, tudo termina assim que é estabelecido - os números de série são fixos. E eles apenas sinalizam essa conexão quando os dados são enviados por ela.

Havia planos que sugeriam o gerenciamento desses números de série. , . , , , .

, - , 250000. , , , 64k 128k, . , – , SYN .

, 64 . , .

, . , , , , IP-.
, , , , , . , , .

, ? , , , — SNc. , , - , , , .

, . ACK (SNs).

- .



SNs , , , IP- C.

, . , : , , , data (SNc +1).



(SNs). ?

: , ?

: . , , , , . , , , , .

: , , ?

: . , ?

, . , , 32 , , .

, .

: , , , . …

: , TCP .

: , .

: , .

: , , .

: , , , . , , 1000 , 2 32 .

, - , , . . , .



: - , ?

: , . , , IP-, ?

: ?

: — ? , . ?

: , , , , - .

: , , , , , . IP-, TCP , , , .

TCP , - , , , C RST (SN…), , .



- , , C , .

, C , . , S , : «, , , ».

, , , , , C .

, «» C , . , «» C , . , TCP.

: , . , SYN , .

: , , . , , , , NAT, . , NAT RST , . , , , , , Comcast , RST .

: ?

: , , TCP. , . , , , . /, .

, data (SNc +1). , IP- , : « », , S.



E se este SYN (SNs) para esta conexão na última linha e (SNs) na terceira linha estiverem conectados, isso será realmente um problema. Mas você diz - vamos desconectá-los, porque esse é um número de um endereço IP diferente, portanto, isso não é mais um problema. Você não pode imaginar que esse SNS será baseado no SNS para outra conexão.

25:50 min

Curso MIT "Segurança de sistemas de computadores". Palestra 12: Segurança de Rede, Parte 2


A versão completa do curso está disponível aqui .

Obrigado por ficar conosco. Você gosta dos nossos artigos? Deseja ver materiais mais interessantes? Ajude-nos fazendo um pedido ou recomendando a seus amigos, um desconto de 30% para os usuários da Habr em um análogo exclusivo de servidores básicos que inventamos para você: Toda a verdade sobre o VPS (KVM) E5-2650 v4 (6 núcleos) 10GB DDR4 240GB SSD 1Gbps da US $ 20 ou como dividir o servidor? (as opções estão disponíveis com RAID1 e RAID10, até 24 núcleos e até 40GB DDR4).

VPS (KVM) E5-2650 v4 (6 núcleos) 10 GB DDR4 240 GB SSD de 1 Gbps até dezembro de graça quando pagar por um período de seis meses, você pode fazer o pedido aqui .

Dell R730xd 2 vezes mais barato? Somente nós temos 2 TVs Intel Dodeca-Core Xeon E5-2650v4 128GB DDR4 6x480GB SSD 1Gbps 100 a partir de US $ 249 na Holanda e nos EUA! Leia sobre Como criar um prédio de infraestrutura. classe usando servidores Dell R730xd E5-2650 v4 custando 9.000 euros por um centavo?