Curso MIT "Segurança de sistemas de computadores". Palestra 4: “Compartilhando Privilégios”, 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

Assim, nosso desenho mostra uma "obra de arte", que seus criadores tentaram proteger contra ameaças. No caso deles, acho que estavam muito preocupados, porque, ao criar o site de namoro okcupid.com , eles realmente queriam garantir que a reputação dos usuários do site não fosse afetada pela divulgação de dados pessoais. De uma conversa com um dos desenvolvedores do site que escreveu o artigo sobre isso, sabe-se que eles não foram realmente comprometidos. Pelo menos, não houve vazamento de dados devido ao uso da arquitetura OKWS e em parte devido ao monitoramento de atividades maliciosas.

A razão pela qual as pessoas não dividem seus aplicativos em componentes menores é porque esse processo exige algum esforço. É necessário selecionar todas as partes do código, definir interfaces claras entre elas e decidir a quais dados cada componente deve ter acesso. Se você decidir implementar uma nova função, precisará alterar os dados aos quais cada componente do programa tem acesso, para conceder novos privilégios ou selecionar alguns, e assim por diante. Portanto, este é um processo bastante demorado.



Vamos tentar entender como o servidor da web é projetado, e talvez uma maneira de fazer isso seja rastrear como a solicitação http é processada pelo servidor OKWS . Assim, semelhante ao mostrado na figura anterior, temos um navegador da web que deseja acessar okcupid.com . Os desenvolvedores do projeto do site imaginaram que teriam um monte de máquinas, mas analisaremos apenas a interface do site em que o OKWS funcionará e outra máquina em segundo plano que armazenará o banco de dados. Esta segunda máquina usa o MySQL porque é um bom software para muitas tarefas. Eles querem realmente proteger esses dados porque é realmente difícil acessar um disco ou banco de dados bruto com datagramas brutos.

Então, como a solicitação funciona, como a solicitação é processada pelo servidor OKWS ? Primeiro, ele chega e é processado por um processo chamado okd para o despachante OKWS . Ele verifica se solicita essa solicitação e, em seguida, faz algumas coisas. Como você pode precisar registrar essa solicitação primeiro, ela a redireciona para um componente chamado oklogd , após o qual você precisará criar alguns modelos e pode ser necessário criá-los mesmo antes da chegada da solicitação. E faz outro componente chamado pubd .



E, finalmente, há um serviço específico para o qual essa solicitação é enviada; portanto, no okd, há uma tabela do conjunto de serviços que ele suporta. Presumivelmente, essa solicitação trata de um desses serviços, portanto, após revisar o okd, a solicitação será redirecionada para um processo de serviço svc específico. Este serviço fará exatamente o que a solicitação exige, por exemplo, inscrever o usuário no boletim informativo ou possibilitar a visualização do diretório de usuários do ocupid , utilizando o banco de dados, etc.

E para isso, você provavelmente precisará do serviço para deixar as informações do aplicativo no log do componente oklogd . E no final do dia, ele deve "conversar" com o banco de dados. Os criadores do site implementaram esse processo de "comunicação" de maneira um pouco diferente do que normalmente acontece no Apache , onde você simplesmente se comunica com o banco de dados e emite consultas SQL arbitrárias. Eles criaram esse conceito de proxy de banco de dados, dbproxy , localizado na frente do banco de dados MySQL e aceita solicitações do serviço svc para executá-los. Penso que esta ilustração mostra basicamente como o OKWS funciona.



Há outro componente que inicia tudo isso, chamado okld , e é responsável por iniciar todos os processos na interface deste servidor web. Espero que algumas dessas coisas lhe pareçam familiares, porque essa é exatamente a arquitetura que foi considerada em laboratório. Parece que é um bom design. Você não tinha pubd , logd e dbproxy no LR , mas tinha okd e svc . Tem dúvidas sobre o OKWS ?

Público: entendemos corretamente que o dbproxy não aceita consultas SQL, mas um tipo diferente de consulta?

Professor: sim, certo! Como é essa interface? Eles não descrevem isso detalhadamente, mas uma coisa que você pode fazer com esse dbproxy é estocar muitos argumentos para modelos de consulta SQL . Por exemplo, poderia ser um modelo de consulta de pesquisa para seus amigos, selecionando-os por ID .



Suponha que exista um modelo como “selecione ^ ID da sua lista de amigos, em que ^ ID =“% S ” . Suponha que você queira encontrar Alice entre seus amigos e enviar uma solicitação S , onde o argumento é "alice" . Deixe nosso aplicativo, disponível na interface, saber que o dbproxy está pronto para executar três tipos de solicitações em seu nome. Se você deseja executar a consulta número 1 e seu argumento é "Alice" , ele fornece acesso ao banco de dados.

Público-alvo: um usuário externo no nível de um navegador da Web pode enviar essa solicitação ao banco de dados ou tudo se aplica apenas a usuários internos da rede?

Professor: sim, talvez. Então, como isso funciona? De fato, é estranho que esse banco de dados esteja em uma máquina separada, porque você pode simplesmente se conectar ao banco de dados OKWS ou ao servidor MySQL ? Então, o que está parando isso?

Público: firewall?

Professor: sim, provavelmente em algum nível. Os desenvolvedores não descrevem isso com muitos detalhes, mas provavelmente existe alguma rede interna na segunda máquina, e há uma alternância entre a interface e o banco de dados que não pode ser acessado do mundo exterior. De fato, ambas as máquinas estão na mesma rede, mas há um firewall Fw que possui certas regras. Talvez eles só possam ser conectados a esse computador de interface através da porta 80, mas não diretamente ao servidor interno. Essa é uma das opções de proteção.



Outro, provavelmente, é que, quando você se conecta a esse proxy do banco de dados dbproxy , precisa fornecer um token ou chave criptográfica de 20 bytes e, se não o fornecer, o dbproxy rejeitará sua conexão. Portanto, a regra é que você abra uma conexão TCP, envie 20 bytes e, se estiverem errados, a conexão será fechada. Acho que esse é o significado de um projeto desse sistema.

Então, vamos tentar descobrir como esses diferentes processos são isolados aqui. Como você pode garantir que todos esses componentes não se sobrecarreguem?

Público-alvo: direitos de root diferentes e IDs de usuário diferentes?

Professor: sim, quase cada um desses componentes funciona como um uid diferente; portanto, aqui, na descrição do sistema, há uma tabela inteira que descreve para cada componente onde ele trabalha e com qual uid . Então, podemos escrever que o okd tem seu próprio uid , o pubd tem o seu próprio uid e o oklogd também tem o seu próprio uid .

Okld funciona como root , o que é um pouco mal sucedido, mas talvez isso não seja um grande problema. Depois, há um monte de identificadores de usuário atribuídos dinamicamente para cada serviço, por exemplo, ID 51001 etc.



Assim, isso garante que cada serviço não possa interferir nos processos de outros serviços. O chroot também é amplamente usado aqui, portanto, alguns desses componentes têm direitos chroot em diretórios separados. Por exemplo, okd e svc são dotados de direitos chroot comuns em alguns diretórios. Por que você acha que esses dois componentes têm um separado e não é comum com outros componentes chroot ?

Público: porque o okd não tem privilégios de root.

Professor: sim, mas por que eles não colocam pubd , oklogd e todos os outros no mesmo chroot ?

Público-alvo: é possível que, se os serviços precisem compartilhar muitos dados, eles sejam isolados um do outro?

Professor: talvez. Eu acho que eles devem compartilhar alguns dados, mas esses dados não estão nos arquivos, eles são transferidos através de sockets do okd para os serviços. Mas, de fato, nenhum desses componentes armazena algo interessante no sistema de arquivos.

Portanto, não há nada de interessante no diretório chroot , e acho que os funcionários da OKWS simplesmente decidiram reduzir despesas improdutivas para o chroot , como a necessidade de criar uma cópia do diretório. Talvez eles também quisessem se livrar de algumas despesas gerais de gerenciamento para cada comando chroot . Mas como não há arquivos reais aqui, tudo está em ordem.

A razão pela qual esses caras atribuíram chroot diferente para os componentes do ambiente é por causa de algumas coisas interessantes. Pode haver modelos, mas aqui, talvez, haja um arquivo de log, portanto eles não desejam que o arquivo de log seja lido acidentalmente e assim por diante.

Público-alvo: esses serviços possuem arquivos, por exemplo, como aspx ?

Professor: como eles descrevem no artigo, o serviço é um único binário C ++ compilado; portanto, não há arquivos adicionais.

Existem modelos, mas eles são realmente transmitidos por esse mecanismo estranho: o pubd possui modelos em seu diretório, os exibe em algum pré-computador, formulário inicial no okd e o okd já fornece modelos para todos os serviços através de chamadas RPC . Assim, eles ficam na memória, mas na verdade são inacessíveis diretamente através do sistema de arquivos. Esse é um design um tanto paranóico quando eu nem consigo ler os modelos.
Então, qual é o sentido de separar todos esses componentes? Por que precisamos de um oklogd separado?

Público: para eliminar a possibilidade de substituir ou aparar o diário?

Professor: sim, então queremos realmente garantir que, se algo der errado, o diário, pelo menos, não seja corrompido. Portanto, há um arquivo de log separado gravável por este uid e todas as mensagens de log são enviadas como RPC para este serviço de log. E mesmo que todo o resto esteja arruinado, bem, com exceção do okld , a revista permanecerá ilesa.

Público: e se você acidentalmente encontrou uma maneira de ler a revista e não vê o que os outros fizeram com ela?

Professor: não, acho que se você " hackear " algum serviço, pubd ou qualquer outra coisa, poderá escrever qualquer coisa no diário. Portanto, a criação de uma entrada oklogd separada faz sentido. Na verdade, o oklogd é um processo separado, e não apenas atualizado, anexando arquivos como um arquivo somente anexado . Portanto, o oklogd não pode adicionar algumas informações adicionais a cada entrada de log, porque se o sistema operacional suportar o arquivo somente anexado , você não saberá que alguém gravou no arquivo quando isso acontecer. Enquanto o oklogd coloca um registro de data e hora para cada mensagem e permite descobrir qual serviço fez a gravação ou veio do okd . Portanto, você realmente obtém informações adicionais nesse arquivo de log porque é um serviço separado.

E qual é o significado da boa separação e por que ela deveria funcionar com direitos de root? Eu acho que existem várias razões para isso.

Público: se você quiser que mais ninguém aja com privilégios de root, você precisará delegar a função de autenticação de usuário okld .



Professor: sim. Alguém tem que configurar tudo isso uid chroot , e você precisa de root para este Unix , então o okld fornece isso. Essa é uma das razões. Mais alguma coisa?

Público: definição de 80 portas?

Professor: sim, claro! Você precisa ligar a porta 80, que está okld e fornece mais alguma coisa?

Público: conclui a abertura do arquivo de log oklogd porque não queremos deixar o oklogd aberto para impedir o acesso ao arquivo de log.

Professor: talvez. Mas não sei se os desenvolvedores realmente fizeram isso porque não examinaram o código-fonte. Você acha que o okld abre o arquivo de log e o passa oklogd ? Possivelmente.

Público-alvo: caso contrário, um invasor que comprometeu o oklogd pode apagar o log inteiro.

Professor: sim, está certo. Talvez você queira abri-lo no modo de acréscimo e depois passá-lo para oklogd , para ter mais garantias de segurança para o log. Isso é algo que você não pode fazer sem privilégios de root.

Então, tivemos uma pergunta sobre a lição de casa, o que acontecerá quando esse token de 20 bytes for "vazado" para acessar o banco de dados. Que dano isso pode causar? Devemos nos preocupar com isso?

Público: neste caso, um invasor pode assumir o controle de um serviço específico.

Professor: sim, certo, porque agora você pode se conectar e obter todos os modelos de consulta. Na verdade, parece bastante simples. Você provavelmente precisará comprometer um desses componentes para poder conectar-se ao banco de dados do servidor primeiro. Portanto, acho que se você tiver esse token e puder comprometer um desses componentes mostrados na figura, poderá usar todas essas consultas.

Agora vamos ver como esse design do OKWS pode ser aprimorado? Por exemplo, seria possível alocar uma unidade de uid separada para cada usuário, além de alocar uma uid separada para cada serviço. Aqui, cada serviço, por exemplo, notícias, pesquisa de amigos ou criação de uma conta, possui um ID do usuário separado, mas cada usuário do OKWS não é representado como um UID do Unix . Na verdade, não há ID do usuário aqui, apenas IDs de serviço estão presentes aqui. Você acha que precisa ter um uid diferente para cada cliente do OKWS ?

Público: neste caso, acontece que, se um usuário "hackear" um serviço, ele poderá acessar todos os dados de outros usuários deste servidor.

Professor: sim, está certo!

Público: mas se você tivesse, de fato, um serviço separado e um dbproxy separado para cada usuário, seria impossível acessar os dados de outras pessoas.

Professor: sim, mas poderia ser um modelo mais forte? Eu acho que os desenvolvedores do OKWS não dão esse passo por duas razões. O primeiro é o desempenho. Se você possui alguns milhões de usuários do site okcupid , vários milhões de processos em execução e alguns milhões de dbproxie , as despesas gerais de desempenho são possíveis. E isso não permitirá obter o mesmo desempenho que a arquitetura OKWS existente fornece .

Público: a descrição da OKWS diz que o desempenho deste sistema é melhor que outros sistemas. Como isso foi alcançado?

Professor: Eu acho que isso ocorre em parte porque eles ajustaram seu design para uma carga de trabalho específica. Além disso, eles escreveram tudo isso em C ++ . Uma alternativa é escrever algumas coisas em PHP , e é provável que você obtenha benefícios nessa frente.

Além disso, eles não têm muitos dos recursos que o Apache possui. Ele tem um design de uso geral, portanto, possui muitos processos de trabalho e os recarrega de tempos em tempos. Existem muitas conexões TTP que garantem a duração do processo de conexão e mantêm suas atividades. Também aumenta o número de processos em execução no sistema. O Apache tornou-se mais universal e pode fazer tudo o que você deseja obter do servidor da Internet, e os funcionários da OKWS estão mais focados em resolver problemas específicos.

Mas acho que atualmente existem outros servidores da web que provavelmente podem corresponder ao desempenho do OKWS . Por exemplo, o Nginx é um servidor da web muito otimizado que você pode executar atualmente. Se você deseja aplicativos de alto desempenho no lado do servidor, provavelmente deseja que o longo processo seja muito semelhante ao serviço OKWS . E para que houvesse um mecanismo para uma interface rápida comum de gateway CGI para conectar um programa externo a um servidor da Web ou um tipo de protocolo que pudesse ser usado no servidor para implementar isso, mesmo no Apache ou Nginx . Portanto, acho que muitas dessas idéias não são exclusivas do OKWS , elas podem ser implementadas em outros servidores da web. Eles simplesmente mostram que melhorar a segurança não exclui o uso desses "truques". Eu acho que eles começaram com um esquema semelhante ao Apache , mas pensaram que não seria seguro o suficiente.

Portanto, acho que uma das razões pelas quais os criadores do OKWS não quiseram introduzir privilégios separados para os usuários foi uma possível degradação do desempenho.



Outro motivo é que o modelo de aplicativo completo "gira" em torno de um serviço que tenta acessar os dados de cada usuário, como encontrar amigos no okcupid ou alguém que você possa convidar para uma data. Como resultado, esse modelo de isolamento do usuário não faz muito sentido, porque, em última análise, deve haver um serviço para o qual você envia uma solicitação e ele examinará todos os outros dados para encontrar uma correspondência para sua solicitação. Portanto, mesmo se você tiver identificadores de usuário ou algum mecanismo para isolá-los, ainda precisará abrir o acesso ao serviço para cada usuário.

Para outros serviços, como o Gmail ou o Dropbox , que são muito mais focados em um usuário específico e não oferecem uma capacidade aberta de compartilhar seus arquivos, o isolamento de usuários pode oferecer mais vantagens. Por exemplo, no servidor do Dropbox, há um ID do usuário para cada cliente do Dropbox . E se houver um processo em execução para você e outro para outra pessoa, mesmo usando uma exploração maliciosa, você não poderá se apossar das informações de outras pessoas.
Agora vamos ver se o OKWS realmente conseguiu melhorar a segurança nesse modelo de servidor. Para avaliar a segurança, você precisa considerar cada componente do sistema e determinar que tipo de ataque poderia prejudicá-lo.

Vamos começar com okd . Pode ser atacado com solicitações via navegador, por exemplo, causando um estouro de buffer. c++, , - , okd . ?



: ?

: , , . ?

: , .

: , . , , , http , , , . , .

: ?

: , . , , , , , match.com . , , OkCupid . , - ? ?

: , , okd . , ?

: . , okd .

: , ?

: ! , , , , , . , , , , . , , . «» okd , , , .

: DOS-?

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

: okd , , …

: , . , , okd , okd , . okd , . , okd , , , , .

: .

: , . , okd . , oklogd ? ?

: .

: , , , ? pubd , , , - .

: , , «» oklogd .

: , . , , append-only , .

: , …

: , , . .

svc ? , , . , , okd oklogd . , , .

svc - -, , , . , , , .

okld ? , root. ? , . dbproxy . okld ? «»? ?

: , - ?

: , . , , . , , - , , , - . - . root- .

: -, , - dbproxy .

: !

: , , , RPC , , , , , ! .



: , . dbproxy ? , . , «» , dbproxy - .

: , svc …

: , svc , !

: , , !

: , , «» , …

: dbproxy .

: . , dbproxy , .

Espero que você entenda o que os privilégios de compartilhamento de aplicativos nos dão. E como podemos ver, isso não é perfeito. Há muito mais coisas que podem dar errado. Mas parece que esta solução é melhor que projetar aplicativos individuais sem privilégios de acesso, onde começamos.


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 de 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).

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?