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 3Palestra 2: “Controle de ataques de hackers”
Parte 1 /
Parte 2 /
Parte 3Aula 3: “Estouros de Buffer: Explorações e Proteção”
Parte 1 /
Parte 2 /
Parte 3Palestra 4: “Separação de Privilégios”
Parte 1 /
Parte 2 /
Parte 3Palestra 5: “De onde vêm os sistemas de segurança?”
Parte 1 /
Parte 2Palestra 6: “Oportunidades”
Parte 1 /
Parte 2 /
Parte 3Palestra 7: “Sandbox do Cliente Nativo”
Parte 1 /
Parte 2 /
Parte 3Aula 8: “Modelo de Segurança de Rede”
Parte 1 /
Parte 2 /
Parte 3Aula 9: “Segurança de aplicativos da Web”
Parte 1 /
Parte 2 /
Parte 3Palestra 10: “Execução Simbólica”
Parte 1 /
Parte 2 /
Parte 3Aula 11: “Linguagem de Programação Ur / Web”
Parte 1 /
Parte 2 /
Parte 3Aula 12: Segurança de rede
Parte 1 /
Parte 2 /
Parte 3Aula 13: “Protocolos de Rede”
Parte 1 /
Parte 2 /
Parte 3Palestra 14: “SSL e HTTPS”
Parte 1 /
Parte 2 /
Parte 3Palestra 15: “Software Médico”
Parte 1 /
Parte 2 /
Parte 3Palestra 16: “Ataques de Canal Lateral”
Parte 1 /
Parte 2 /
Parte 3Palestra 17: “Autenticação de Usuário”
Parte 1 /
Parte 2 /
Parte 3Palestra 18: “Navegação Privada na Internet”
Parte 1 /
Parte 2 /
Parte 3Palestra 19: “Redes Anônimas”
Parte 1 /
Parte 2 /
Parte 3 Vamos dar uma olhada em como o protocolo funciona. Porque seria uma pena ler um artigo da palestra e não falar sobre coisas sobre as quais chama a atenção. Quero me desculpar novamente pela minha técnica de desenhar no quadro-negro, afinal, na maioria das vezes passo à mesa, digitando em um computador.
Esta é uma tecnologia alienígena. Então aqui está o repetidor. E aqui está Alice. Aqui está outro repetidor e aqui está Bob. Alice agora quer conversar com Bob, então a primeira coisa que ela faz é criar uma cadeia através desses repetidores para Bob. Digamos que ela escolheu esses dois repetidores, R1 e R2. Alice primeiro cria um link TLS para R1, digamos que ela já tenha um link TLS para R2. Então, primeiro, Alice realiza autenticação unidirecional, correspondência unidirecional de chaves anônimas.
O antigo protocolo Tor foi chamado TAP - Tor Authentication Protocol, o novo é chamado NTor. Ambos têm evidências de segurança. Esta é uma evidência correta, embora tenham sido cometidos erros em sua descrição.
Após a autenticação, Alice seleciona o ID do circuito, digamos 3, instrui o repetidor a criar o canal “3” - crie “3” e ele diz a ela que o canal foi criado - criado. Alice e o relé agora compartilham a chave simétrica secreta S1. E os dois armazenam com um índice "3", que é um link para este canal.
Alice agora pode usar essa tecla para enviar mensagens R1. Ela diz que na "troika", esse é o identificador do canal, discutido no artigo da palestra, uma célula estendida com conteúdo é enviada para o revezamento.
Uma célula expandida contém basicamente a primeira metade de um aperto de mão. Mas desta vez não é criptografada com a chave pública R1, mas criptografada com a chave pública R2. Isso indica que a mensagem está sendo enviada para o R2. Portanto, o R1 sabe que é necessário abrir um novo canal para o R2 e o reporta ao retransmissor do R2 com a mensagem create (....), onde a mesma metade do aperto de mão que veio de Alice é colocada entre colchetes. Ao fazer isso, o R1 cria seu próprio ID de circuito, uma vez que os identificadores de canal definem outros canais nesta segunda conexão TLS. Além disso, Alice não sabe quais identificadores de canal ainda são usados aqui, porque esse é um "assunto pessoal" de R1 e R2.
Assim, o repetidor pode escolher, por exemplo, o ID 95. Na verdade, isso é improvável, porque o número do canal é selecionado aleatoriamente a partir de 4 bytes de espaço, mas não quero escrever todos os números de 32 bits hoje.
Depois disso, o R2 responde o primeiro relé "criado" e o R1 retorna para Alice uma célula estendida, criptografada com a chave S1. Agora, Alice e R2 retransmitem o compartilhamento S2 e Alice pode enviar mensagens, primeiro criptografadas com S2 e, em seguida, com S1. Ela envia essa mensagem, R1 remove a criptografia de S1 e a encaminha ainda mais.
O primeiro repetidor sabe que as mensagens do canal 3 devem ser enviadas para o segundo repetidor no canal 95. Após receber esta mensagem, o segundo repetidor vê que a tecla S2 corresponde ao canal 95 e, com sua ajuda, descriptografa a mensagem: “oh, diz conexão aberta com Bob”! Depois de ler isso, o relé R2 abre uma conexão TCP com Bob e relata isso para Alice usando o mesmo processo de passagem de mensagem reversa.
Depois de tudo isso, Alice diz: “ótimo, então diga a Bob algo como http: 1.0get /index.html” e a vida continua.
Vamos ver o que eu perdi no artigo da palestra ... então ... isso, isso e isso. Ok, então o que estamos realmente retransmitindo? Algumas soluções nessa área afirmam que é necessário transferir pacotes IP de um lado para outro, ou seja, esse esquema deve ser simplesmente uma maneira de transmitir pacotes IP. Um dos problemas é que queremos oferecer suporte ao maior número possível de usuários, o que significa que devemos trabalhar em todos os tipos de sistemas operacionais.
Mas as pilhas TCP de diferentes sistemas operacionais agem de maneira diferente. Se você já usou o Nmap ou algum tipo de ferramenta de análise de tráfego de rede, pode distinguir facilmente o Windows TCP do FreeBSD TCP ou TCP Linux. Você pode até distinguir entre diferentes versões. Além disso, se você pode enviar pacotes IP brutos para um host selecionado, pode provocar respostas baseadas em parte no que o host faz.
Portanto, se você encaminhar pacotes IP para frente e para trás, precisa da normalização de IP. Como qualquer coisa menor que a pilha IP completa não poderá funcionar na normalização, você não o fará.
Em vez disso, escolhemos a maneira mais fácil - simplesmente aceitamos todo o conteúdo dos fluxos TCP, assumindo que seja confiável e que tudo esteja em ordem. O programa analisa todos os dados transmitidos por Alice, concorda em aceitar conexões TCP provenientes de seus aplicativos e simplesmente retransmite o conteúdo sem fazer nada complicado no nível da rede.
Você pode tentar aumentar a produtividade usando outros meios descritos nos materiais da aula. Mas descrevi um esquema que pode realmente ser implementado, porque ao criar o Tor, prestamos muito mais atenção às classes e compiladores de segurança do que às classes de rede. Agora temos especialistas em rede, mas em 2003-2004 tivemos uma escassez deles.
O protocolo TCP parece ser um nível correto e muito apropriado. Os protocolos de nível superior discutidos em alguns projetos originais usam proxies separados no lado de Alice para HTTP, FTP e parecem uma má idéia. Isso ocorre porque qualquer protocolo deve ter criptografia do início ao fim em toda a conexão Alice-Bob e, se tivermos sorte, Alice poderá criar uma conexão TLS entre R2 e Bob, que possui recursos de integridade e segurança.
Mas, se esse for o caso, quaisquer transformações de anonimato que você deseja aplicar aos dados criptografados devem ocorrer no aplicativo que Alice usa antes que a conexão TLS seja totalmente criada. Mas isso não é possível usando um servidor proxy, portanto, o TCP é mais adequado para nós.
Alguém me perguntou: onde está nossa evidência de segurança? Temos evidências de segurança para muitos dos métodos de criptografia que usamos, são versões padrão de documentos. Em geral, para o protocolo, há evidências da segurança de certos aspectos do roteamento da cebola. Mas os modelos que eles devem usar para provar que isso fornece anonimato devem basear-se em propriedades tão bizarras do universo, propriedades da rede ou nas habilidades do atacante que podem satisfazer apenas as comissões de programação presentes em algumas conferências teóricas.
Em resumo, essas propriedades de anonimato devem provar que um invasor que pode ver o volume e o tempo dos dados na seção Alice-R1 não poderá identificá-los, observando apenas os bytes de saída na seção R2-Bob. Mas este não é um resultado satisfatório. Digamos apenas: que garantias de segurança você gostaria de ter em um sistema que não sabe construir? Bem, eu tenho que ter cuidado com essas declarações ... Lembre-se de que existem sistemas com fortes garantias de anonimato e você sabe como criar esses sistemas, mas nunca desejará usá-los. Como, por exemplo, a rede clássica DC-Net, que fornece anonimato garantido, exceto que qualquer participante pode fechar toda a rede simplesmente deixando de participar dela. Além disso, este sistema não é escalável.
Mas, para as coisas criadas em nosso tempo, as propriedades do anonimato são mais probabilísticas e não categoricamente garantidas. Então, em vez de perguntar se esse sistema garante a segurança de Alice, vale a pena perguntar quanto tráfego Alice pode enviar com segurança se ela quiser ter 99% de chance de que essa atividade de rede não possa ser associada a ela.
A primeira pergunta que fizemos a nós mesmos quando começamos a criar o Tor é: quem gerenciará todas essas coisas? Não sabíamos se nosso sistema realmente "se manteria em pé", então a única opção era tentar ver o que resultou dele.
Tivemos voluntários suficientes. Um número razoável de organizações sem fins lucrativos simplesmente queria fazer doações e usá-las para comprar largura de banda e lançar sites Tor. Algumas universidades e várias empresas privadas participaram do projeto, cujos serviços de segurança decidiram que seria divertido lançar seu próprio servidor Tor.
Nesse caso, surgiram questões legais, mas, novamente, eu não sou advogado e não posso dar uma avaliação legal dessas coisas. No entanto, cinco pessoas diferentes me perguntaram sobre a legalidade do nosso sistema. Pelo que sei, pelo menos nos EUA, não há obstáculos legais para iniciar o servidor Tor. E parece-me que uma situação semelhante ocorre na maioria dos países europeus. Em países com menos liberdade na Internet, o Tor é mais restritivo.
O problema não é quão legal ou ilegal é o uso do sistema Tor, mas alguém pode fazer algo ilegal ou indesejado com o meu servidor Tor. Por exemplo, meu provedor me desconectará da rede se eu fornecer meu computador como um nó Tor, as agências de aplicação da lei acreditarão que eu apenas uso o servidor Tor, ou elas virão buscar o meu computador para garantir isso.
Nesse caso, aconselho você a não iniciar o servidor Tor a partir do seu dormitório, ou melhor, a não usar o computador para transmitir uma grande quantidade de tráfego de saída, assumindo que isso permita a política de rede. Honestamente, não tenho idéia do que é essa política agora, porque mudou muito desde os meus dias de estudante. Mas, em qualquer caso, um grande tráfego de saída do seu computador no albergue pode causar problemas. No entanto, iniciar um repetidor sem emitir tráfego para a Internet será menos problemático. Mas se o seu provedor permitir que você aja dessa maneira, isso é bastante razoável.
Alguém me perguntou se os usuários não confiam em um site específico? Isso nos leva ao próximo tópico. Os clientes da rede usam o software a seu critério, e você não pode proibi-los de usar alguns dos programas e obrigá-los a usar outros. Mas lembre-se de que o anonimato adora companhia. Se eu usar três nós, você usa outros três nós e você é outros três nós, nosso tráfego não será misturado.
Enquanto separamos as partes da rede que usamos, somos facilmente distinguidos um do outro. Agora, se eu simplesmente excluir um ou dois nós e você simplesmente excluir um ou dois nós, isso não será uma divisão tão grande da rede em partes e complicará nossa identificação. Mas seria ideal que todos usassem os mesmos nós o máximo possível. Como conseguimos isso?
Portanto, na primeira versão do Tor, deixamos de lado uma lista de todos os nós para os usuários, havia cerca de 6 deles, dos quais três trabalhavam em um computador no laboratório de ciência da computação da Tech Square. Mas isso não foi uma boa ideia, porque o número de nós aumenta e diminui, os próprios nós mudam e você não deseja lançar uma nova versão do software cada vez que alguém ingressa na rede.
Mas você pode garantir que cada nó contenha uma lista de todos os outros nós conectados a ele, e todos eles "anunciarão" um ao outro. Então, quando o cliente se conecta à rede, ele só precisa conhecer um nó e dizer: "Ei, quem está aí na rede"?
De fato, muitas pessoas têm projetos construídos sobre esse princípio. Muitos projetos anteriores de anonimato por pares funcionam dessa maneira. Mas essa é uma ideia terrível. Como se você se conecta a um nó e pergunta quem está online e confia na pessoa que responde, eu posso responder: “Estou online e meu amigo está aqui online, e meu amigo também está online e muito mais. ninguém está online! ” Ou seja, posso dizer qualquer número de nós falsos que eu gerencie e que interceptem todo o seu tráfego. Isso é chamado de ataque de captura de rw ou ataque de interceptação no nó de origem.
Portanto, é possível que, se tivermos apenas um diretório gerenciado por uma parte confiável, isso não seja tão bom, então vamos assumir que temos várias partes confiáveis. Os clientes vão a essas partes confiáveis, recebem de cada uma uma lista de todos os nós e combinam-na em uma lista comum de nós da rede.
Isso não é bom porque estamos novamente divididos em clusters de rede identificáveis. Se eu selecionar esses três nós e você selecionar outros três nós, usaremos conjuntos diferentes de nós, o que não é bom. Além disso, se eu usar a lista de nós transmitidos para mim, qualquer uma das partes confiáveis poderá me impedir de usar um nó que ela não gosta, simplesmente não o especificando na lista. Se eu usar uma lista combinada, alguém poderá me inundar com 20 mil servidores falsos, indicando-os na lista. Eu poderia votar em sua exclusão e, de alguma forma, resolver os dois últimos problemas, mas ainda assim serei separado de todos que usam diferentes partes confiáveis.
Poderíamos criar um DHT mágico ou uma tabela de hash distribuída, um tipo de estrutura distribuída mágica que atravessa todos os nós. Digo "mágica" porque, embora existam projetos nessa área e alguns sejam melhores que outros, nenhum deles atualmente possui evidências sólidas de segurança. Tão difícil que posso dizer com confiança que é realmente seguro.
Então, aqui está a solução que encontramos como resultado. Nossa rede possui várias autoridades confiáveis, gerenciadas por partes confiáveis, que coletam listas de nós que votam a cada hora em quais nós podem trabalhar na rede e podem votar para excluir nós suspeitos. Todos trabalham no mesmo / 16, que faz coisas tão estranhas com o tráfego, e formam um consenso que se baseia no cálculo do resultado da votação.
E os clientes não usam o nó se ele não for assinado por um número suficiente de "votos" de partes confiáveis.
Esta não é a versão final do projeto, mas é a melhor que conseguimos apresentar até agora. A propósito, tudo o que você precisa distribuir entre os clientes é uma lista de todas as chaves públicas autorizadas e uma lista de alguns lugares para receber diretórios. Você deseja que todos os nós armazenem em cache esses diretórios, porque, caso contrário, a carga da rede se tornará perigosa e a largura de banda da rede diminuirá drasticamente.
Pretendo pular a próxima pergunta e ir diretamente para como os clientes devem escolher quais caminhos devem rotear pela rede. Eu gostaria de falar sobre os problemas de usar e criar aplicativos que não se trairiam. Eu gostaria de falar sobre abusos de rede, sobre serviços ocultos e como eles funcionam, sobre resistência à censura, e também gostaria de falar sobre ataques e proteção. Mas temos apenas 35 minutos, então não posso falar sobre tudo o que quero. Peço que você vote nos tópicos que você considera mais importantes para discussão.
Se você acha que um dos tópicos mais importantes é a escolha de caminhos e nós, levante a mão. Se um dos tópicos mais importantes for problemas de aplicativos e como garantir que os aplicativos não violem seu anonimato, levante a mão. Se o abuso é uma das questões mais importantes e como pode ser evitado, levante a mão. Então, vejo que este tópico é popular e marque-o.
Se for importante para você como os serviços ocultos funcionam e como eles podem funcionar melhor, levante a mão. , , . , . , ? , . ?
, . , , . , , — .
, . , IP-, , . , Whole stack, -, , Tor.
«» -, , , , , , , , .
, : , , , . , -, . , . , . . , .
, . , , – , -, . , BitTorrent, Gnutella . , , , .
, , , 80 443. , 80. IRC- - IRC. -, , , , .
, , - 80 443, , , . , Tor. - , . , , .
, - IRC- IP-.
, My Little Pony, IRC-, , , , – . , IP-, , IP- . Tor .
IP- ? , IP ? Não. , IP, . , IP-, .
IP- , , , , , , Tor -.
. - «» ? , IP, , IP IP-. , , IP-.
, , , , . – « ». , , , , , IRC – , , , .
, . , . , , , - IP, .
- . , 2013 , « 2» , Silk Road. « 2» , Tor, , , .
, - , OPSEC – . , , . Tor , .
, , , , , « ». : «, , . , , . , , — ». , , .
54:00
Curso MIT "Segurança de sistemas de computadores". 19: « », 3 ( Tor).
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 Cores) 10GB DDR4 240GB SSD 1Gbps ,
.
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?