Curso MIT "Segurança de sistemas de computadores". Aula 12: Segurança de Rede, Parte 3

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

Aluno: existe algum tipo de assinatura para domínios de nível superior inexistentes?

Professor: Eu acho que sim. Um domínio de ponto é apenas outro domínio e implementa o mesmo mecanismo. Atualmente, os domínios "ponto" e "ponto.com" usam a SEC DNS, e existem todos esses registros que dizem, por exemplo, que .in é o nome de domínio que existe e o nome "ponto" também existe, e não há mais nada entre eles. Portanto, nos domínios de nível superior, todas essas coisas estão presentes.



Aluno: além do perigo de ataques de DoS, por que nos preocupamos tanto com a repetição de nomes de domínio no mit.edu?

Professor: não sei ao certo. De qualquer forma, o AFS possui um arquivo de texto que lista todos esses nomes de domínio do MIT. Mas acho que, em geral, algumas empresas se sentem um pouco estranhas nesse sentido, porque geralmente têm nomes internos que estão no DNS e que não podem ser dados a pessoas de fora. Penso que, de fato, esta é uma área confusa que nunca foi formalizada e que não explica exatamente o que garante que os usuários do DNS ofereçam. Geralmente, as pessoas assumem que, se existir um nome confidencial, no caso do DNS, ele não será divulgado.

Penso que este é outro local em que este sistema não possui uma especificação clara em termos do que deve ou não fornecer.

Aluno: é possível definir o período de validade de uma assinatura destacando-a de alguma forma?

Professor: essas coisas têm uma data de validade, por exemplo, você pode assinar que esse conjunto de nomes é válido por uma semana e, em seguida, os clientes, se tiverem um relógio sincronizado, podem rejeitar as mensagens antigas assinadas.

Portanto, podemos assumir que discutimos ataques adivinhando os números de sequência TCP SYN. Outra questão interessante sobre o TCP é o ataque DDoS, que explora o fato de o servidor estar em algum estado. Se você observar esse handshake, que foi desenhado anteriormente no quadro, verá que, quando o cliente estabelece uma conexão com o servidor, o servidor deve lembrar o número de série do cliente SNc. Portanto, o servidor deve suportar alguma estrutura de dados em um bloco separado, o que mostra que esse número de sequência é usado para esta conexão.



Este é um tipo de tabela em que o número de sequência SN é armazenado e que a conexão cliente-servidor possui o número de sequência SNc. O motivo pelo qual o servidor deve manter essa tabela é porque ele precisa descobrir qual o número de sequência SNc correto deve levar posteriormente, por exemplo, SNc + 1. Além disso, o servidor também precisa armazenar números de SNs, que são muito mais importantes, pois mostram ao servidor que a conexão é estabelecida com o "cara certo".

O problema é que esta tabela não possui uma borda real. Dessa forma, você pode obter pacotes de alguma máquina sem saber quem os está enviando. Você acaba de obter um pacote que se parece com C-> S com um endereço de origem que afirma ser C. Para potencialmente aceitar essa conexão desse endereço IP, você deve criar uma entrada na tabela. Além disso, esses registros existem por um longo tempo, porque, talvez, alguém estabeleça uma conexão com você a partir de um local muito distante e, ao mesmo tempo, muitos pacotes sejam perdidos. Na pior das hipóteses, pode levar, por exemplo, um minuto até que alguém termine esse handshake TCP. Portanto, você deve manter esse estado na pilha TCP por um tempo relativamente longo e não há como adivinhar se será válido ou não.

Portanto, o ataque de DoS mais comum contra a maioria das pilhas TCP criadas pelas pessoas é a transmissão simples de um grande número de pacotes. Se eu sou um invasor, basta enviar um grande número de pacotes SYN para um servidor específico e causar o estouro dessa tabela.

O problema é que, na melhor das hipóteses, um invasor simplesmente usa o mesmo endereço IP de origem. Nesse caso, você pode simplesmente dizer que cada cliente tem permissão apenas para duas entradas, ou algo assim. E então o invasor pode usar no máximo 2 duas entradas na tabela.

O problema, é claro, é que um invasor pode falsificar endereços IP de clientes e fazer com que pareçam aleatórios. Então, será muito difícil para o servidor distinguir quem está tentando estabelecer uma conexão com ele - um invasor ou algum cliente que o servidor nunca ouviu falar antes.

Portanto, se você procurar algum site que aceite conexões de qualquer lugar do mundo, isso será um grande problema. Como você nega o acesso a todos ou deve poder armazenar o estado para a maioria das tentativas de conexão falsas.

Portanto, esse é um problema para o TCP e a maioria dos protocolos que permitem um tipo de iniciação de conexão, no qual o servidor deve salvar o estado. Mas há algumas correções implementadas no TCP sobre as quais falaremos em um segundo, e elas tentarão lidar com esse problema, chamado SYN Flooding in TCP.



Em geral, esse é um problema que você deve conhecer e tentar evitar em qualquer protocolo que esteja desenvolvendo. Você deve especificar que o servidor não deve salvar o estado até poder autenticar e identificar o cliente. Porque somente após a autenticação do cliente é possível tomar uma decisão se é permitido conectar-se, por exemplo, apenas uma vez; nesse caso, o servidor não precisa salvar o estado para esta conexão.

O problema é que você garante a preservação do estado antes mesmo de saber quem está se conectando a você. Vamos ver como podemos combater o ataque de inundação do SYN Flooding, que é o servidor que está acumulando muito estado.

Você pode alterar o TCP novamente, por exemplo, corrigi-lo facilmente com criptografia ou outra coisa ou alterar o que é responsável por salvar algum estado. Mas o fato é que precisamos usar o TCP como ele é. Poderíamos resolver esse problema sem modificar o protocolo TCP existente?

Este é novamente um exercício para tentar descobrir exatamente quais truques poderíamos executar, ou melhor, quais suposições poderíamos deixar em paz e ainda assim aderir ao formato de cabeçalho TCP existente ao trabalhar com eles.

E o truque é encontrar uma maneira inteligente de criar um servidor sem estado, para que ele não precise armazenar esta tabela na memória. Isso pode ser feito escolhendo SNs com cuidado, ou seja, em vez da fórmula que consideramos anteriormente e onde tivemos que adicionar essa função, escolheremos os números de série de uma maneira completamente diferente. Vou lhe dar a fórmula exata, e depois falaremos sobre por que é realmente interessante e quais são as boas propriedades.

Se o servidor detectar que está sofrendo um ataque desse tipo, entrará no modo em que seleciona SNs usando a fórmula com a mesma função F que consideramos anteriormente.



Esta função possui o endereço IP de origem, o endereço IP de destino, da mesma forma que antes - porta de origem, porta de destino, carimbo de data e hora e chave. E vamos combinar essa função com um carimbo de data / hora, em vez de "granulação grossa", com alguns minutos de tamanho. Há uma separação entre essas duas partes do cabeçalho - a função e o registro de data e hora, que não precisam de muitos bits. Esqueci como exatamente esse protocolo funciona em um computador real, mas você pode imaginar que o carimbo de data / hora leva 8 bits e o restante da fórmula do número de sequência é de 24 bits.

Então, por que esse é um bom plano? O que está acontecendo aqui? Por que essa fórmula estranha é necessária? Você deve se lembrar do que tentamos obter dos números de série. Duas coisas acontecem aqui.

O primeiro é a proteção contra pacotes duplicados. Permaneceu na placa um circuito com esse número de série à moda antiga, ao qual adicionamos uma função para impedir a duplicação de pacotes de conexões anteriores.



Acontece que as pessoas não conseguiram encontrar uma maneira melhor de se proteger de ataques como o SYN Flooding, exceto usar esse plano de ação, que funciona bem em algumas situações. Era um plano, mas outro era uma função de data e hora em que abandonamos esse componente do estilo antigo. Em vez disso, focaremos em garantir que, se alguém nos fornecer esse número de sequência ACK (SNs) em resposta ao pacote, essa pessoa será o cliente "certo".

Você se lembra que, para evitar ataques de falsificação de IP, meio que confiamos nesse valor (SNs). Afinal, se o servidor enviar esse valor de SNs para o cliente na segunda etapa, esperamos que somente esse cliente possa nos enviar o valor corrigido de SNs na terceira etapa, concluindo a conexão.

É por isso que você teve que armazenar esse número de série em uma tabela, porque, caso contrário, como você saberia se essa é uma resposta real ou falsa? A razão para usar esta função F é que agora não podemos salvar esta tabela na memória.

Em vez disso, quando a tentativa de conexão é mostrada, mostrada na primeira etapa, na segunda etapa calculamos os SNs usando essa fórmula e simplesmente os enviamos de volta ao cliente que deseja entrar em contato conosco, e esquecemos essa conexão.



Então, quando o terceiro pacote chegar e seu valor (SNs) corresponder ao que esperamos ver, significa que alguém recebeu nossa resposta na segunda etapa e finalmente a enviou para nós. Finalmente, após esta terceira etapa, podemos colocar o registro real dessa conexão TCP na memória. Essa é uma maneira de adiar a persistência do servidor até que o cliente envie o valor exato do número de série. A construção dessa construção possibilita verificar se o cliente enviou ao servidor exatamente a resposta que se espera dele e não algum valor arbitrário.

Aluno: o SNc dura apenas um tempo limitado?

Professor: sim, o servidor não armazena o valor SNc permanentemente, e isso não é muito bom. Eu não mostrei isso no diagrama, mas aqui no final da terceira linha há um campo que mostra que esse pacote não possui dados, mas inclui o número de sequência SNc apenas porque possui esse campo.



Assim, o servidor pode restaurar o valor do SNc, porque o cliente o incluirá neste pacote de qualquer maneira. Anteriormente, isso não importava, mas agora é como se fosse relevante. Não vamos verificar nada aqui, mas a existência de tal campo é em si uma coisa boa. No entanto, tem algumas conseqüências tristes. Por exemplo, se você usar algumas coisas complicadas que podem ser abusadas aqui. Mas isso não é tão ruim quanto sobrecarregar a memória do servidor com solicitações do cliente.

Porque a única coisa que nos preocupa é liberar o armazenamento dessa tabela e a confiança de que as conexões são estabelecidas com clientes genuínos. E se esse cliente estabelecer um milhão de conexões comigo, pararei de aceitar solicitações dele, é bastante simples. O problema é que é difícil distinguir endereços falsos de endereços de clientes genuínos.

Aluno: preciso manter um registro de data e hora?

Professor: sim, há uma coisa inteligente! Quando obtemos o valor dos SNs na terceira etapa, precisamos descobrir como calcular os dados de entrada para esta função F, a fim de verificar se esse valor está correto. Portanto, pegamos o carimbo de data / hora localizado no final da embalagem e o usamos para calcular dentro da função. Tudo o resto podemos restaurar. Sabemos quem acabou de nos enviar o terceiro passo e pacote, temos todos esses campos e nossa chave, que, novamente, ainda é secreta, e o carimbo de data e hora dos últimos 8 bits da sequência. Nesse caso, pode acontecer que excluamos carimbos de data / hora muito antigos, simplesmente banindo conexões antigas.

Aluno: Eu acredito que você usa isso quando é atacado, apenas porque perde 8 bits de segurança ou por algum outro motivo?

Professor: sim, isso não é muito bom, tem muitas propriedades ruins. De certa forma, estamos realmente perdendo 8 bits de segurança. Porque agora a parte indiscutível é de apenas 24 bits em vez de 32.

Outro problema é o que acontece se você perder determinados pacotes? No TCP, geralmente é aceito que, se o terceiro pacote for perdido, o cliente poderá estar esperando por nada. Ou, desculpe-me, talvez o protocolo que executamos sobre essa conexão TCP seja um protocolo que pressupõe que o servidor inicialmente pretenda dizer algo, então eu me conecto e apenas ouço a resposta. E no SMTP, por exemplo, o servidor deve me enviar algo como uma saudação por meio do protocolo. Suponha que eu me conecte ao servidor SMTP, envie o terceiro pacote, acho que fiz tudo e apenas aguarde o servidor me responder, por exemplo:

"Olá, este é um servidor SMTP, por favor me envie seu email!"

Portanto, este terceiro pacote pode ser perdido. No TCP real, o servidor lembra que, na segunda etapa, respondeu ao cliente, mas nunca recebeu um terceiro pacote de resposta. Portanto, o servidor enviará ao cliente novamente um segundo pacote para reiniciar o terceiro pacote. Obviamente, se o servidor não armazenar nenhum estado, ele não fará ideia do que enviar. Isso torna o estabelecimento de uma conexão um tanto problemático, porque ambos os lados esperam um passo recíproco um do outro. O servidor nem sabe que o cliente está aguardando uma resposta e o cliente está aguardando a resposta do servidor, embora não atenda porque não armazena o estado. Portanto, esse é outro motivo pelo qual você não usa o modo produtivo do servidor constantemente.

Aluno: você também pode ter perda de dados se estabelecer duas conexões de curta duração a partir de um host imediatamente após o outro.

Professor: sim, claro. Outra coisa é que nos recusamos a usar esse estilo antigo de número de sequência ISN, o que aumentou a independência dessas múltiplas conexões em um curto espaço de tempo. Eu acho que há uma série de compromissos aqui, acabamos de falar sobre três deles, então há mais algumas razões para preocupação.

Se pudéssemos desenvolver um protocolo a partir do zero, buscando o melhor, poderíamos apenas ter um bom volume de 64 bits separado para a função F e um volume de 64 bits para o registro de data e hora, e poderíamos usá-lo constantemente, sem desistir todas essas coisas legais.

Aluno: os SNs no segundo e terceiro passo devem ser os mesmos?

Professor: é claro, porque, caso contrário, o servidor não poderá concluir que este cliente recebeu nosso pacote. Se o servidor não verificar se esses SNs têm o mesmo significado de antes, isso pode ser ainda pior - porque eu poderia falsificar uma conexão de um endereço IP arbitrário na primeira etapa e obter essa resposta na segunda etapa. Ou eu nem receberia essa resposta porque ela é direcionada para um endereço IP diferente. Na terceira etapa, eu estabeleço uma conexão a partir de outro endereço IP. Nesse caso, o servidor suportaria a conexão estabelecida, espere que eu envie dados e assim por diante.



Aluno: mas o timestamp será diferente, certo? Como o servidor pode recontar isso usando um novo carimbo de data e hora se ele não armazena o estado?

Professor: como eu disse, esses registros de data e hora são bastante "granulares" e são classificados em minutos. Se você se conectar no mesmo minuto, tudo estará em ordem, se você se conectar na borda do minuto - isso é muito ruim.

Outro problema com este circuito é que ele é imperfeito de várias maneiras. Mas a maioria dos sistemas em funcionamento, incluindo Linux, tem maneiras de detectar muitas entradas nesta tabela. E quando a ameaça de seu transbordamento ocorre, o sistema muda para outro esquema.

Aluno: se um invasor controla um grande número de endereços IP e faz o que você disse, mesmo se você alternar ...

Professor: sim, você realmente pode fazer pouco. A razão pela qual esse esquema nos importou tanto foi porque queríamos filtrar ou de alguma forma distinguir entre os agressores e os "mocinhos". Se um invasor tiver mais endereços IP e apenas controlar mais máquinas do que os mocinhos, ele poderá se conectar ao nosso servidor, solicitar várias páginas da web ou manter contato.

E então será muito difícil para o servidor determinar se as solicitações são recebidas de clientes legítimos ou se é apenas um invasor que liga os recursos do servidor. Então você está absolutamente certo. Esse esquema só funciona se o invasor tiver um pequeno número de endereços IP e desejar obter um efeito.

E isso é motivo de preocupação, porque hoje alguns invasores controlam um grande número de computadores invadidos por usuários comuns. Isso lhes permite criar DoS com uma frota de máquinas localizadas em todo o mundo, e é muito difícil se defender.

Quero mencionar mais uma coisa interessante - a negação do serviço DoS é ruim por si só, mas ainda pior quando os próprios protocolos contribuem para esse ataque. O invasor sabe disso e ataca principalmente sistemas com protocolos como o DNS. O protocolo DNS inclui um cliente enviando uma solicitação ao servidor e o servidor envia uma resposta de volta ao cliente. E, em muitos casos, o tamanho da resposta em bytes é muito maior que o volume da solicitação.



Você perguntou sobre o servidor mit.edu. , , mit.edu — , mit.edu, , DNS SEC, .

100 , — 1000 . , «» - . , DNS- . 100 - DNS-, , , 1000 .

, . , TCP SYN Flooding, DNS- , . , , « ».

DNS. . , DNS-. , . .

: DNS- …

: , DNS- , - .

: , ?

: , DNS-, . DNS-, . 10 DNS-, , , , , . . , , DNS-, .

, DNS , , , . , .

, , , – , , , . , , . .

DNS- , . , , .

, : «, , »! , , DNS- .

, . - -, . DoS , . , , , , .



, , . , , , .

, , . .

, DHCP, . , , IP-. , , MIT DHCP, , , , IP-, , DNS-, , .

, DHCP DHCP-, , DHCP-. , , . , DHCP IP-, : «, DNS- »! DNS .

, . , BGP, IP-, . , , BGP, : «, IP-!», : „, , “.



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

DNS SEC. , , DNS, , . , , , , DNS SEC.

, , , . : , , , , , DoS — . .

Portanto, você deve tentar evitar coisas como ataques SYN Flooding e ataques RST que permitem desconectar um usuário de rede arbitrário. São coisas realmente prejudiciais em um nível baixo e difíceis de corrigir em um nível alto. Porém, mais ou menos, garante a integridade e a confidencialidade dos dados usando criptografia. Falaremos sobre como fazer isso na próxima palestra sobre Cerberus.


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) 10GB DDR4 240GB SSD de 1Gbps 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?