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

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: talvez você ainda tenha um problema de conflito de interesses, porque poderia usar 32 bits para endereços pares e ter muitas portas para cada um deles. Você provavelmente tem um conflito de números de sequência de todas essas conexões que obtém?

Professor: verifica - se que esses números de sequência são específicos para o endereço IP e o número da porta do par de origem / destino. Portanto, se essas são portas diferentes, elas não interferem uma com a outra. Especificamente, as portas têm números de série mais baixos.



Aluno: se os números de série forem globais, o invasor poderá entrar na conexão entre outros clientes?

Professor: Sim, este é um bom ponto. De fato, se o servidor aumenta o número de série, por exemplo, em 64k para cada conexão, você se conecta ao servidor e, em seguida, outras 5 pessoas se conectam a ele, e aqui você pode organizar um ataque. Então, até certo ponto, você está certo, é um pouco problemático. Por outro lado, você provavelmente poderia fazer com que um pacote da última linha de S-> A fosse entregue imediatamente antes desse pacote na primeira linha de C-> S. Se você enviar seus pacotes um após o outro, há uma boa chance de que eles cheguem ao servidor um por um também.

O servidor receberá S-> A e responderá com este número de sequência (SNs). Será diferente dos (SNs) na segunda linha, mas com o número de série imediatamente a seguir. E então você saberá exatamente qual número de sequência (SNs) deve ser incluído no terceiro pacote da sua sequência.
Portanto, acho que essa não é uma maneira muito confiável de conectar-se ao servidor, é baseada em suposições. Mas se você organizar cuidadosamente seus pacotes da maneira certa, poderá adivinhar facilmente a sequência. Ou talvez você tente várias vezes e tenha sorte.

Aluno: mesmo que os números sejam gerados por acaso, você precisa adivinhar um dos 4 bilhões de números possíveis. Isso não é demais, certo? Eu acho que dentro de um ano você provavelmente poderá entrar nessa rede.

Professor: sim, você está absolutamente certo. Você não deve confiar muito no TCP em termos de segurança. Porque você está certo, são apenas 4 bilhões de palpites. E você provavelmente pode enviar muitos pacotes durante o dia se tiver uma conexão razoavelmente rápida.

Então, aqui temos um tipo de argumento interessante sobre a falta de confiabilidade do TCP, porque só temos 32 bits. Não podemos protegê-lo de nenhuma maneira. Mas acho que muitos aplicativos que dependem desse protocolo suficientemente não pensam em segurança, e isso realmente se torna um problema.

Mas você está absolutamente certo. Na prática, você deseja usar algum tipo de criptografia, além de obter garantias mais sérias de que ninguém falsificou seus dados, pois você usa chaves de criptografia com mais de 32 bits. Na maioria dos casos, isso ainda é eficaz na prevenção de violações da conexão TCP.

Vamos ver agora por que é ruim se as pessoas podem falsificar conexões TCP a partir de endereços arbitrários?

Uma das razões pelas quais isso é ruim é que ela pode afetar a autorização com base no endereço IP quando o servidor verifica qual o endereço da solicitação. Se um servidor decidir se deve permitir ou negar a conexão com base no endereço IP, isso pode ser um problema para um invasor que falsificou a conexão a partir de um endereço de origem arbitrário.

Portanto, um exemplo em que isso foi um problema, hoje esse problema está basicamente resolvido, é o uso de uma família de comandos r, como o rlogin. Antes, era possível executar algo como o rlogin em um computador em, digamos, athena.dialup.mit.edu. E se sua conexão vier do host do MIT, esse comando rlogin será bem-sucedido se você disser: "Sim, sou o usuário de Alice neste computador, deixe-me fazer login como usuário de Alice em outro computador". E essa operação será permitida, pois todos os computadores da rede mit.edu são confiáveis ​​para fazer essas declarações.

Devo dizer que a conexão discada nunca teve esse problema. Este composto usou Cerberus desde o início. Mas outros sistemas, é claro, tinham esses problemas. E este é um exemplo de uso de um endereço IP em um mecanismo de autenticação de conexão quando o sistema verifica se o cliente que está chamando o servidor é confiável. Então, o que costumava ser um problema não é mais um problema. Mas confiar no IP ainda parece um plano ruim.



Agora o rlogin não está mais em uso, foi recentemente substituído pelo shell SSH seguro, que é um excelente protocolo de camada de rede. Por outro lado, existem muitos outros exemplos de protocolos que dependem de autorização baseada em endereço IP. Um deles é o SMTP. Ao enviar um email, você usa o SMTP para conversar com algum servidor de email para enviar mensagens. Para evitar spam, muitos servidores SMTP aceitam apenas mensagens recebidas de um endereço IP de origem específico. Por exemplo, o servidor de email Comcast aceita apenas emails de endereços IP da Comcast. O mesmo vale para servidores de correio MIT - eles aceitarão apenas emails de endereços IP do MIT. Mas tínhamos pelo menos um servidor que não funcionava como deveria, usando autenticação IP.

Tudo aqui não é tão ruim. Na pior das hipóteses, você enviará algum spam pelo servidor de email. Portanto, é provavelmente por isso que eles ainda estão usando o rlogin, enquanto as coisas que permitem que você efetue login em uma conta arbitrária pararam de usar a autenticação baseada em IP.

Então, por que esse mecanismo de autenticação é um plano ruim? Como suposição, suponha que algum servidor usasse rlogin. O que você faria para atacar? Que mal poderia acontecer?

Aluno: um invasor pode simplesmente entrar no seu computador, falsificar um usuário que entrará na rede com seu nome de usuário e obter acesso à rede.

Professor: sim, basicamente um invasor assume o controle de um computador. Ele sintetiza dados que se parecem com um conjunto válido de comandos rlogin que dizem: "Efetue login como usuário e execute este comando no meu shell Unix".

Você sintetiza esses dados (SNc + 1), monta todo o ataque e envia esses dados como se um usuário legítimo interagisse com o cliente rlogin e, em seguida, continue.



Bem, essa é uma das razões pelas quais você não deseja que seus números de sequência TCP sejam adivinhados. Outro problema é que esses ataques de redefinição redefinem o ataque. Da mesma maneira que poderíamos enviar um pacote SYN, se soubermos o número de série de alguém, podemos enviar um pacote de redefinição da mesma maneira.

Mencionamos brevemente um cliente legal que envia um pacote de redefinição de conexão falso que um invasor estabeleceu. Um invasor pode tentar enviar pacotes de descarte para uma conexão existente, se de alguma forma souber que o seu número de sequência está nessa conexão. De fato, não está claro o tamanho desse problema.

Em algum nível, você deve assumir que todas as suas conexões TCP podem ser interrompidas em qualquer caso e a qualquer momento, ou seja, não parece que sua rede é confiável. Portanto, talvez você deva esperar uma desconexão.

No caso em que os roteadores "conversam" entre si, essa suposição é especialmente crítica. Se você possui muitos roteadores que se comunicam usando alguns protocolos de roteamento, existem algumas conexões físicas entre eles. Mas, além dessas conexões físicas, eles se comunicam através de um protocolo de rede que funciona através de TCP. De fato, em cada uma dessas conexões físicas que os roteadores usam para trocar informações de roteamento, uma sessão TCP é iniciada. O protocolo BGP é usado aqui, sobre o qual falaremos mais adiante.

Este protocolo BGP usa o fato de que, se a conexão TCP estiver ativa, a conexão física também estará ativa. Portanto, se uma conexão TCP for interrompida, o roteador acredita que a conexão está interrompida e começa a recontar todas as suas tabelas de roteamento.



Portanto, se o adversário deseja organizar algum tipo de ataque de negação de serviço do DoS, ele pode tentar adivinhar os números de série desses roteadores e interromper essas sessões. Se a sessão TCP entre os dois roteadores estiver desativada, os dois roteadores consideram esta conexão morta e devem recontar todas as tabelas de roteamento, o que fará com que as rotas mudem. Depois disso, o invasor pode redefinir outra conexão e assim por diante.

Portanto, este é um ataque um tanto alarmante, e não porque viola o segredo de outra pessoa e assim por diante, pelo menos não diretamente, mas porque realmente causa muitos problemas de acesso para outros usuários do sistema.

Aluno: se você é um invasor e deseja organizar um ataque direcionado contra um usuário específico, você pode simplesmente continuar enviando solicitações para se conectar ao servidor em nome do endereço IP e forçá-lo a redefinir a conexão com o servidor?

Professor: suponha que eu use o Gmail e você queira impedir que eu receba qualquer informação do Gmail; basta enviar pacotes para minha máquina, fingindo que eles vêm do servidor do Gmail. Nesse caso, você deve adivinhar os números de porta de origem e destino corretos.

O número da porta de destino é provavelmente 443 porque eu uso HTTPS. Mas o número da porta de origem será algo aleatório de 16 bits. Além disso, os números de série variam. Portanto, se você não adivinhar o número de sequência que está na minha janela TCP e que é dezenas de kilobytes, não terá êxito.

Então você tem que adivinhar uma quantidade razoável de coisas. Não há acesso Oracle aqui. Você não pode simplesmente pedir ao servidor o número de série desse cara. Esta é a razão pela qual isso também não funcionará.

Portanto, muitos desses problemas foram corrigidos, incluindo esse item baseado em RST, especialmente para roteadores BGP. Na verdade, havia duas correções engraçadas. Uma coisa realmente mostra como você pode explorar coisas existentes ou usá-las para corrigir problemas específicos. Ele usa a propriedade que esses roteadores se comunicam apenas entre si e não com mais ninguém na rede. Como resultado, se o pacote não chegar de um roteador localizado na outra extremidade da conexão, esse pacote será descartado.

A implementação bem-sucedida dos desenvolvedores desses protocolos é uma área maravilhosa do pacote chamada "tempo de vida", ou TTL. Este é um campo de 8 bits decrementado por cada roteador para garantir que os pacotes não terminem em um loop infinito. O valor TTL máximo é 255 e diminui ainda mais.

Então, o que estou fazendo com esses protocolos inteligentes? Eles descartam qualquer pacote com um valor TTL que não seja igual a 255. Como se o pacote tiver um valor de 255, ele poderá vir apenas de um roteador do outro lado desta conexão. E se o adversário tentar injetar qualquer outro pacote na conexão BGP existente, ele terá um valor TTL menor que 255, porque esse valor será reduzido por outros roteadores localizados ao longo do caminho de roteamento, incluindo este roteador. Portanto, este pacote será simplesmente rejeitado pelo destinatário.

Portanto, este é um exemplo de uma combinação inteligente de técnicas compatíveis com versões anteriores que resolvem esse problema muito específico.



Aluno: O roteador inferior direito não envia algo com um TTL de 255?

Professor: Este é um roteador físico. E ele sabe que essas são conexões separadas, então ele analisa o TTL e de onde veio o pacote. Portanto, se o pacote vier do roteador superior esquerdo, ele não será aceito para uma conexão TCP entre ele e o roteador superior direito.

Na maioria das vezes, esses roteadores confiam nos vizinhos imediatos e esse processo pode ser controlado usando o mecanismo de roteamento de caminhos múltiplos do Auto Pan.

Outras correções para o BGP são implementar alguma forma de cabeçalho de autenticação, incluindo um cabeçalho de autenticação MD5. Mas, na realidade, os desenvolvedores se concentraram nesse aplicativo em particular, para o qual um ataque de redefinição é especialmente crítico.

Esse problema persiste hoje. Se houver alguma conexão de longo prazo e eu quero interrompê-la, só preciso enviar um grande número de pacotes RST, aproximadamente centenas de milhares, mas provavelmente não 4 bilhões. Como os servidores são realmente um pouco vulneráveis ​​a qual número de sequência eles aceitam para redefinição.

Pode ser qualquer pacote em uma janela específica. Nesse caso, o invasor pode interromper essa conexão sem muito esforço. Esse ainda é um problema para o qual não existe uma solução realmente boa.

E a última coisa ruim que pode acontecer devido à previsibilidade dos números de sequência é a injeção de dados nas conexões existentes. Suponha que tenhamos um protocolo hipotético semelhante ao rlogin, que na verdade não executa autenticação baseada em IP, portanto, você deve digitar sua senha para efetuar login.

O problema é que, assim que você digita sua senha, talvez sua conexão TCP seja simplesmente estabelecida e possa aceitar dados arbitrários. Portanto, o invasor só precisa esperar até que um de vocês faça logon no computador digitando sua senha.

O invasor não sabe qual é a senha, mas assim que você estabelece uma conexão TCP, ele imediatamente tenta adivinhar seu número de série e insere alguns dados na conexão existente. Portanto, se eu puder adivinhar corretamente seu número de série, isso permitirá que eu finja que não sou eu, mas você inseriu algum comando depois de se autenticar corretamente com uma senha.



Tudo isso indica por que você realmente não deseja confiar nesses números de sequência de 32 bits no sentido de segurança. Mas vamos ver o que as modernas pilhas TCP realmente fazem para mitigar esse problema. Uma abordagem para o problema que abordaremos nas próximas 2 palestras é implementar algum grau de segurança no nível do aplicativo. Nesse nível, usaremos criptografia para autenticar, criptografar, assinar e verificar mensagens sem muito envolvimento do TCP.

Alguns dos aplicativos existentes também ajudam a resolver problemas de segurança ou, pelo menos, tornam mais difícil para um invasor explorar esses problemas. As pessoas colocam isso em prática hoje, por exemplo, no Linux e Windows, mantendo diferentes números de sequência inicial para cada par de origem / destino.

Portanto, a maioria das implementações TCP SYN ainda calcula esse número de sequência ISN inicial da mesma maneira que fizemos anteriormente. Portanto, este é um estilo antigo do ISN, digamos assim. E para realmente gerar um número de série para qualquer conexão em particular, adicionamos a esse ISN antigo um deslocamento aleatório de 32 bits. Ou seja, adicionamos uma função a ela - algo como uma função hash ou SHA-1, ou algo melhor.



Esse recurso inclui o endereço IP de origem, o número da porta de origem, o endereço IP de destino, o número da porta de destino e alguma chave secreta que apenas o servidor conhece. Assim, criamos uma boa oportunidade para qualquer conexão específica determinar o endereço IP e a porta do par de origem / destino, preservando todas as boas propriedades desse algoritmo de atribuição de número de série no estilo antigo.

Mas se você tiver conexões de diferentes conjuntos de origem / destino, não há nada que permita descobrir o valor exato do número de série de outro conjunto de conexões. Na verdade, você precisa adivinhar essa chave para calcular esse valor.

Espero que o kernel do sistema operacional do servidor armazene essa chave em algum lugar da memória e não a entregue a ninguém. É assim que a maioria das pilhas TCP hoje resolve esse problema específico no campo dos números de sequência comuns de 32 bits. Isso não é muito bom, mas funciona.

Aluno: você poderia repetir isso de novo? Sobre a exclusividade da chave ...

Professor: quando minha máquina é inicializada ou quando qualquer máquina é inicializada, gera uma chave aleatória. Cada vez que você recarrega, ele gera uma nova chave. Isso significa que cada vez que os números de série de um determinado par de origem / destino mudam com a mesma frequência de deslocamento. Assim, para um determinado par de origem / destino, os parâmetros de função são fixos. Então, você segue a sequência quando os números evoluem de acordo com os números de sequência iniciais para novos compostos, mudando de acordo com um algoritmo específico. Assim, é fornecida proteção contra a injeção de pacotes antigos de conexões anteriores em novas conexões, bem como proteção contra a reatribuição de pacotes.

A única coisa para a qual precisamos desse número de série da amostra antiga é a escolha do algoritmo para evitar problemas com esses pacotes duplicados. Anteriormente, consideramos que, se você obtiver um número de série para uma conexão A: A -> S: SYN (...), poderá concluir uma conclusão sobre o número de série da conexão ACK (SNs).



, 32- , F. , , .

: ?

: , . F, , F , , , .

: , …

: , F - -, . -, , . , , , , . , F .

, TCP, . , , - .

, . , TCP , DNS, . , DNS UDP – . UDP — , , . UDP . , , , . , , . DNS-. DNS?



, DNS- C: C53 -> S53 mit.edu, 53.

S: S53 -> C53 IP-, – .

, , , , . , mit.edu, .

, DNS- . IP-, , . IP- mit.edu IP-. , , , , . , .



, , . IP-. , , DNS- . , , IP- mit.edu.

: , , ?

: , . , , . DNS-, , . 2 . — , 16 . , 16 . ID, 16 , .

, , 32 . , , , , .



, , .

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

origin. DNS , IP-, : „, “. , , , , , , . , , ?

, – DNS- , . , , . -, DNS-, . , DNS SEC, , , DNS- . DNS- , , , – , .

DNS SEC , NSEC. , . , NSEC , foo.mit.edu, goo.mit.edu, , .



, , , , , , „, “.

. , foo.mit.edu -> goo.mit.edu — >…. : » , , gooa.mit.edu". , , .

, DNS . NSEC3, – - , - .

52:00

Curso MIT "Segurança de sistemas de computadores". 12: « », 3


.

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?