Curso MIT "Segurança de sistemas de computadores". Aula 13: Protocolos 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
Aula 13: “Protocolos de Rede” Parte 1 / Parte 2 / Parte 3

Suponha que um cliente emita uma solicitação para receber uma mensagem específica, por exemplo, “me dê a mensagem nº 7” e criptografe essa coisa com a chave Kc, mail. Tudo parece maravilhoso.
O servidor de email possui uma chave compartilhada que descriptografará esta mensagem, após a qual o servidor enviará de volta ao cliente o corpo dessa mensagem de email, também criptografada com o Kc, mail. Alguém vê isso como um problema? Por que isso pode ser ruim?



Aluno: existe a possibilidade de um hacker substituir uma mensagem ou falsificá-la.

Professor: sim, isso é preocupante, pois posso enviar qualquer e-mail que desejar. Suponha que pretendo excluir algumas mensagens da sua caixa de entrada porque não quero que você as leia. Suponha que esta letra esteja no número 23.

Portanto, vou lhe enviar uma carta que diz: "apague o número 23" e você a lerá. Você o receberá, e a resposta vinda do servidor de correio com o comando “delete No. 23” será criptografada com essa chave Kc, mail. E até agora não foi enviado para o servidor de correio.

Mas se eu digitalizar a rede no momento certo e confirmar esse pacote, posso enviá-lo de volta ao servidor de email. Será semelhante à mensagem "delete No. 23", criptografada usando a chave. Nesse caso, o servidor de correio dirá: "Ah, sim, claro, você deseja excluir esta mensagem e eu o farei!"

Portanto, há um problema aqui, porque permitimos que o adversário confunda o servidor de correio se nossa mensagem foi gerada por ele ou enviada a ele em primeiro lugar.

É o que é comumente referido nas descrições de criptografia e protocolo como um "ataque de reflexão". Você tem alguma sugestão sobre como evitar esse problema?

Aluno: é possível simplesmente incluir um cabeçalho de mensagem que fale de sua origem?

Professor: sim, como regra, você deseja ter algum tipo de maneira inequívoca de declarar o que está acontecendo. Uma maneira é ter um cabeçalho em cada mensagem que diz: “do cliente para o servidor” ou “do servidor para o cliente”. Uma maneira ainda melhor na prática é simplesmente usar duas chaves separadas.

Porque você pode querer ter um fluxo de dados longo que pode não ter espaço para os bits do cabeçalho. Assim, cada vez que você estabelece uma conexão com um serviço, o Kerberos 5 negocia o uso de duas chaves em vez de uma. A primeira chave será usada para criptografar dados do cliente para o servidor e a segunda para criptografar dados do servidor de volta para o cliente. Este é o método de proteção mais ideal para uso prático.

Vamos falar agora sobre o que está acontecendo com o KDC. O servidor Kerberos é muito importante para o sistema, mas o que acontece se esse KDC travar? Quão ruim é isso para o nosso sistema? Como a "queda" do KDC afetará sua vida se você usar o Athena?

Aluno: você provavelmente não consegue fazer login?

Professor: sim, é. Em segundo lugar, você também não poderá obter tickets para novos pedidos. Mas o mais interessante é que o KDC está praticamente fora do caminho crítico para uma conexão existente. Portanto, nenhum dado passa pelo KDC. E se você já possui um ticket para alguma coisa, pode continuar a usá-lo e manter a entrada para alguns serviços de rede. Isso é realmente muito bem armazenado em cache. Eu acho que a segunda coisa boa que os desenvolvedores imaginaram é o potencial de replicar o KDC. Portanto, o sistema possui um servidor Kerberos principal, que armazena a cópia inicial de todo o banco de dados. Isso permite que você leia apenas réplicas que contêm uma cópia do banco de dados inicial. Ele não permite nenhuma atualização, como registro do usuário ou atualizações de chave, mas permite responder a solicitações de login e TGS.

Portanto, o registro de "clone" do banco de dados Kerberos permite que você continue efetuando login e se comunique com os serviços, mesmo se o KDC falhar, até que seja eliminado e sua funcionalidade completa seja restaurada.

Aluno: quão difícil é comprometer o servidor KDC e o sistema como um todo?

Professor: KDC é a espinha dorsal de qualquer sistema que executa o Kerberos. Se esse serviço for comprometido, o invasor obterá controle completo sobre o sistema. Ele poderá obter tickets para qualquer serviço que desejar, fingindo ser o cliente certo, por isso é muito ruim. Nós realmente queremos manter o KDC seguro, mas é difícil. Embora eu não conheça um único caso em que o KDC MIT estaria realmente comprometido por cerca de 20 anos. Mas, aparentemente, o que realmente vale a pena se preocupar é a implementação de software da segurança das coisas que esses dois serviços trocam, Kerberos e TGS. Como se ocorrer um estouro de buffer ou surgir alguma outra vulnerabilidade semelhante, isso é muito ruim.



Por exemplo, se um servidor SSH estiver em execução no KDC Kerberos e alguém adivinhar a senha raiz desse servidor SSH, ele simplesmente fará login e copiará o banco de dados. Então, eu acho que você realmente deseja minimizar a superfície de ataque aqui; portanto, tenha muito cuidado ao escrever o código KDC. Não permita que ninguém acesse diretamente este serviço. Obviamente, existem alguns lugares em que você deve ser considerado paranóico em relação à segurança, mas isso não é tão importante para os servidores. Obviamente, eles armazenam dados, mas se alguém invadir um servidor de correio ou servidor de impressão, eles poderão ser restaurados.

Aqui está uma pergunta interessante. Suponha que alguém tenha hackeado um servidor de email. O que você deve fazer para se recuperar desse ataque? Por exemplo, se alguém roubou seu e-mail, isso é ruim. Mas o que deve ser feito para impedir que um invasor obtenha acesso a seus e-mails no futuro?

O Kerberos não possui uma operação de cancelamento, mas você pode gerar uma nova chave para o servidor de correio e colá-la no banco de dados KDC. Em seguida, você instala um novo servidor de email, fornece uma nova chave e, em seguida, algum invasor que possui uma chave antiga do servidor de email não pode influenciá-lo de nenhuma maneira.

Por outro lado, suponha que você não altere a chave do servidor de correio, o Kmail. O que isso levará?



Aluno: a chave não cabe no novo servidor.

Professor: bem, suponha que você instale um novo servidor de email, corrigindo o erro que o hacker usou. Mas ele ainda tem uma chave do Kmail. Talvez a recuperação do servidor tenha demorado um dia inteiro, para que todos os tickets expirassem. Esse hacker pode fazer algo interessante com o sistema? Se você fornecer o Kmail antigo para o novo servidor de email - isso é ruim?

Estudante: um invasor pode se infiltrar em um servidor de correio porque pode descriptografar o primeiro ticket.

Professor: com certeza, é por isso que o Kmail é realmente muito importante. Você diz que pode descriptografar tudo o que acontece no servidor de email. Suponha que o cliente se conecte ao servidor de email após corrigi-lo, mas o invasor ainda conhece o Kmail, que permaneceu desde o último hacking do sistema. Portanto, ele pode descriptografar esse ticket do Kmail, olhar dentro do ticket e obter uma chave de sessão. Com ele, ele será capaz de descriptografar todas as mensagens que você enviar, todas as respostas que você receber, e assim por diante. Portanto, após restaurar o servidor de email, é muito importante alterar este Kmail.

De muitas maneiras, isso é ainda pior do que simplesmente rastrear o tráfego, porque se um invasor conhece essa chave do Kmail, ele pode sintetizar novos tickets para o servidor de email sem entrar em contato com o KDC. Suponha que eu conheça o Kmail e queira ler mensagens de um servidor de mensagens. Vou apenas emitir esse tíquete, reunirei todos esses cinco campos na ordem correta, gerarei uma nova chave e criptografarei usando o Kmail. Será semelhante à coisa real gerada pelo KDC.

Portanto, basta conectar-me ao servidor de email, ele descriptografará a mensagem corretamente e pensará que é um usuário específico, para que você possa enviar e-mail, compartilhar uma chave compartilhada e assim por diante. Portanto, é fundamental que ninguém reconheça a chave secreta desse serviço, pois, caso contrário, você poderá não apenas tornar o tráfego descriptografável e visível, mas também imitar qualquer pessoa nesse serviço.

Aluno: se o servidor de email for restaurado após uma falha, provavelmente você precisará alterar sua chave no banco de dados?

Professor: sim, depois de restaurar o servidor de email após a falha, você precisa ligar para o funcionário que trabalha com este KDC e dizer: "nosso servidor de email foi hackeado, exclua sua chave Ks antiga do banco de dados e insira uma nova!" Portanto, você provavelmente desejará ter algum tipo de mecanismo fora do banco de dados para provar que realmente é um servidor de correio.

Porque veremos em um segundo como você altera as chaves, por exemplo, usando o protocolo de alteração de senha. Você pode senhas no protocolo Kerberos, porque se você souber a senha antiga, poderá alterar a senha do usuário para a nova senha no KDC. Mas como o hacker pode interceptar a senha enviada pelo correio, você provavelmente precisará entrar em contato com o escritório de registro da conta e solicitar que ele mude sua senha para o servidor de correio. Eles irão gerar uma nova chave e entregá-la para que o hacker não possa reconhecê-la.



Caso contrário, se o invasor conhecer essa chave do Kmail, o servidor de email não terá nada para diferenciar o invasor do cliente correto. Na realidade, o invasor provavelmente alterou a chave, agora eles conhecem os novos parâmetros e você não está lá, como se não estivesse mais no servidor de email. Portanto, você precisa de protocolos externos para os princípios do registro inicial no banco de dados e para alterar as chaves se você esqueceu sua senha ou alguém alterou sua senha para que você perdesse o acesso.

Portanto, há um grupo de pessoas no MIT que ajuda os usuários a registrar contas e alterar suas senhas. Para fazer isso, você apresenta seu ID do MIT e, aconteça o que acontecer, eles poderão alterar a chave para você.

Portanto, é muito importante fazer o certo. Porque se a pessoa que permite redefinir a senha estiver errada ao verificar seu ID do MIT, você poderá comprometer o sistema, certo? Portanto, essas pessoas na Kerberos fazem parte de uma base de computação confiável.

Vejamos outro uso interessante do Kerberos. Você pode usar o Kerberos para efetuar login em um computador remoto via SSH. E o modo como funciona é muito semelhante ao trabalho com um servidor de correio. Você recebe um ticket para o servidor SSH e envia o ticket junto com sua conexão SSH. Mas e se você se conectar ao Athena.dial-up e não tiver um cliente Kerberos no seu computador? Você só deseja fazer login no Athena.dial-up com sua senha normal.

Então, como o Dial-up Athena o autentica se você acabou de se conectar a esta máquina com uma senha? Você não tem uma senha para Athena.dial-up, é uma senha para o servidor Kerberos. Então, o que um computador dial-up deve fazer se você fizer login com uma senha?

A discagem dial-up funcionará usando o mesmo protocolo que o logon. Portanto, ele enviará uma solicitação do cliente ao servidor Kerberos com uma solicitação para fornecer um ticket, por exemplo, ao nome de usuário "Alice". Além disso, o cliente receberá uma resposta criptografada com a senha de Alice. Em seguida, ele tentará aplicar a senha e verificar se ele descriptografa corretamente. Se descriptografar corretamente, você poderá efetuar login no sistema.

Aluno: você nem precisa enviar sua chave ao servidor SSH, pois, nesse caso, o servidor KDS pode enviar o usuário Kc de volta através da conexão SSH.

Professor: é possível que sim, mas requer alguma imaginação do cliente SSH, o que pode não ser. Mas, em princípio, isso é verdade. Se você quiser fazer isso corretamente, provavelmente desejará ter um cliente Kerberos no seu computador e obter um ticket, ou talvez usar um servidor SSH para encaminhar, embora não permita que o servidor SSH tenha sua chave.

Este é provavelmente um bom plano. Mas acontece que, de fato, isso é algo bastante perigoso que permite que qualquer pessoa efetue login no servidor SSH. Anteriormente, falamos sobre um cliente tentando fazer login. Esse cliente sabia que, ao fornecer uma senha legal, ele recebeu uma resposta do servidor Kerberos correto e, se conseguir descriptografar a resposta, provavelmente a senha funcionará corretamente.

No entanto, não há nada neste protocolo que confirme o fato de que essa resposta vem do servidor Kerberos correto. Portanto, se eu tentar fazer login na máquina simplesmente digitando uma senha, a máquina enviará essa solicitação ao servidor. Em seguida, a resposta será retornada a essa solicitação, que parece estar criptografada com a senha que eu inseri, mas essa resposta também pode não ser do servidor Kerberos.

Suponha que eu tenha uma máquina com a qual quero fazer login. Eu digito a senha X e a máquina envia essa solicitação de, s para o servidor Kerberos.



Mas antes que o servidor Kerberos envie a resposta real ao cliente, enviarei minha própria resposta, que parece a resposta real, criptografada com minha senha X. E então a estação de trabalho na qual estou tentando fazer login ou o servidor SSH tentará descriptografar essa resposta com minha senha falsa. Isso ficará bem, porque essa resposta foi gerada por mim em vez do servidor Kerberos real. Portanto, posso efetuar login em vez de você. Por que isso está acontecendo?

Aluno: porque não há autenticação do servidor Kerberos.

Professor: sim, não há nada aqui que vincule isso a um servidor Kerberos real. A maneira como o Kerberos corrige esse inconveniente em computadores remotos, como o Athena.dial-up, é que os próprios computadores dial-up têm um tipo de chave secreta que compartilham com o KDC. Portanto, para entrar na discagem ou em qualquer estação de trabalho que realmente se preocupe em verificar se você é realmente o usuário certo, duas coisas são feitas.

O primeiro logon no Kerberos ocorre como mostrado no diagrama. Mas ele não confiará em ninguém apenas porque esta resposta foi descriptografada corretamente. Ele tentará obter uma multa de serviço usando o TGS, porque esse computador dial-up possui sua própria chave secreta. Na primeira etapa, ele simplesmente registra você e depois se volta para o TGS, dizendo: "por favor, me dê uma multa de serviço por meu próprio princípio, com base na discagem, para esse cliente".

Em seguida, ele recebe uma resposta e verifica se pode descriptografá-la corretamente, porque conhece a tecla de discagem desses Ks. E se descriptografar, significa que o computador estava conversando com o servidor Kerberos correto. Porque apenas o servidor Kerberos correto no segundo estágio pode me enviar um ticket criptografado com minha chave secreta do Kdial-up.

Então isso é realmente muito importante. Normalmente, as estações de trabalho Athena não executam essa etapa extra porque as estações de trabalho Athena não possuem uma chave secreta armazenada e compartilhada com o KDC. Por que é considerado normal que as estações de trabalho Athena ofereçam a você a oportunidade de efetuar login no primeiro estágio, mas não a oportunidade de acesso discado?

Aluno: isso é normal se você não tiver acesso a nenhum serviço porque o invasor não conseguiu falsificar um ticket.

Professor: sim, isso é verdade, porque não há nada interessante na própria estação de trabalho dial-up. Mesmo se você tiver acesso root ou entrar em uma estação de trabalho com uma senha falsa, isso não incomoda ninguém. Não é como se eles pudessem fazer outra coisa fora da estação de trabalho. Na discagem, tudo é muito mais interessante. Talvez você tenha outros processos em execução em outras sessões na estação de trabalho dial-up, e o fato de estar conectado com um UID específico do Unix, e eles realmente querem ter certeza de que você é a entidade certa, é importante. . É por isso que eles realizam um processo de duas etapas para entrar na máquina, que é usada simultaneamente por vários usuários.

A última coisa que quero falar é sobre como substituímos as chaves. Apresentamos a ideia de que você pode comprometer a chave do servidor de correio. Mas como usuário, você provavelmente também deseja alterar a senha. Por exemplo, você pensou que sua senha não era segura o suficiente, você a escreveu em um pedaço de papel e alguém pode ter espionado, então agora você deseja alterá-la.

Em certo sentido, é bastante simples. Além dos serviços Kerberos e TGS, a interface do servidor Kerberos possui um serviço adicional chamado Kpassword, que permite alterar sua senha.



Você recebe um ticket para usar este serviço, assim como um ticket para um servidor de correio ou qualquer outro servidor. Depois disso, você envia sua nova senha para este serviço Kpassword, criptografada com sua chave de sessão. E então, se todas as verificações passarem, sua chave no banco de dados será atualizada com uma nova chave.

Se você se lembra, tínhamos um objetivo: se alguém roubar seu bilhete, ele não deve ser bom o suficiente para dar a oportunidade de capturar completamente sua conta. Por esse motivo, o serviço Kpassword não aceita nenhum ticket, mas apenas o ticket que você recebe inicialmente do serviço Kerberos com sua chave Kc. : , , , , – Kerberos TGS – . : Kerberos, , TGS, .
Kpassword, , , : «, Kerberos, . TGS, , , , - , . ».

, Kpassword , , , Kerberos. , Kpassword , Kerberos Kpassword.

Kpassword, - . , , Kerberos. Kerberos, ID , Kpassword.



Kerberos , Kpassword, Kpass, Kc,kpass Kpassword, Kc.

, – Kpassword, Tc,kpass, Kpass, , new pass Kc,pass, .

, , , , . - Athena, , , , . , , Gmail, , . , Kerberos TGS , - , .

, - Athena , , , . , . , . Tc,kpass, Kpassword, TGS, . , Kerberos Kc.

: , ?

: K . Kerberos , . , K. - K, .

: , ?

: , - , , . .

, , , , , , .

: , , .

: , , . , , Kerberos , , . , . . , , .

: K, ?

: , K – 56- DES, , , 56 , , 7 , . .

, , . , , , , . Kerberos?



: …

: , , , , , , . ?

: .

: , .

: - , , , , …

: , , Kerberos , , , . . , , , «» - , ! : „, Kc,pass, K. Kc,pass , Kpassword». , , KDC. , .
, , - , - . .

: , Kerberos ?

: , . « -», , , . , .

, Kerberos 5. , , , . , . , X, Kpassword - Y. , , . , g X , g Y.



gy X, gxy, gx Y gxy. gxy , . , , gxy. , , - gxy, . , .

: - G.

:sim claro. G é um parâmetro que você pode enviar no início do protocolo ou colocar com antecedência no Kerberos, não é muito importante. De qualquer forma, se você usar o protocolo de criptografia de troca Diffie-Hellman, o Kerberos 5 fará isso corretamente. Mas você precisa saber sobre a existência desse protocolo se estiver desenvolvendo algum protocolo novo. Então, era tudo o que eu queria falar sobre o Kerberos e, na segunda-feira, vamos falar sobre SSL.


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?