Capítulo 13. Segurança

13.1. O que é uma caixa de areia (sandbox)?
13.2. O que é securelevel?
13.3. O BIND9 (named) está escutando em algumas portas de numeração alta. O que está acontecendo?
13.4. O daemon Sendmail está escutando na porta 587, assim como na porta padrão 25! O que está acontecendo?
13.5. O que é essa conta UID 0 toor? Eu fui comprometido?

13.1.

O que é uma caixa de areia (sandbox)?

Sandbox é um termo de segurança. Isso pode significar duas coisas:

  • Um processo que é colocado dentro de um conjunto de paredes virtuais que são projetadas para impedir que alguém que interrompa o processo seja capaz de invadir o sistema mais amplo.

    O processo só é capaz de correr dentro das barreiras. Desde que nada que o processo faça em relação à execução de código seja capaz de violar as barreiras, uma auditoria detalhada de seu código não é necessária para poder dizer certas coisas sobre sua segurança.

    As barreiras podem ser um ID do usuário, por exemplo. Esta é a definição usada nas páginas de manual de security(7) e named(8).

    Veja o serviço ntalk, por exemplo (veja inetd(8)). Este serviço costumava rodar como ID de usuário root. Agora ele é executado como ID do usuário tty. O usuário tty é um sandbox projetado para tornar mais difícil para alguém que invadiu o sistema com sucesso através do ntalk ser capaz de hackear além do seu ID de usuário.

  • Um processo que é colocado dentro de uma simulação da máquina. Isso significa que alguém que é capaz de entrar no processo pode acreditar que ele pode invadir a máquina mais ampla, mas está, na verdade, apenas invadindo uma simulação dessa máquina e não modificando nenhum dado real.

    A maneira mais comum de fazer isso é construir um ambiente simulado em um subdiretório e então executar os processos nesse diretório chrooted para que o diretório / para esse processo seja este, não o diretório / real do sistema).

    Outro uso comum é montar um sistema de arquivos subjacente somente leitura e, em seguida, criar uma camada do sistema de arquivos sobre ele, o que dá a um processo uma visualização aparentemente gravável nesse sistema de arquivos. O processo pode acreditar que é capaz de escrever nesses arquivos, mas o processo apenas vê os efeitos - outros processos no sistema não, necessariamente.

    Foi feita uma tentativa de tornar esse tipo de sandbox tão transparente que o usuário (ou hacker) não percebe que está dentro dele.

O UNIX® implementa dois sandboxes principais. Um está no nível do processo e o outro está no nível do usuário.

Todo processo UNIX® é completamente protegido contra qualquer outro processo UNIX®. Um processo não pode modificar o espaço de endereço de outro.

Um processo UNIX® é de propriedade de um determinado ID de usuário. Se o ID de usuário não for o usuário root, ele servirá para proteger o processo contra processos pertencentes a outros usuários. O ID do usuário também é usado para proteger os dados no disco.

13.2.

O que é securelevel?

securelevel é um mecanismo de segurança implementado no kernel. Quando o nível de segurança é positivo, o kernel restringe certas tarefas; nem mesmo o superusuário (root) pode executá-los. O mecanismo de securelevel limita a capacidade de:

  • Desativar determinados flags de arquivo, tais como schg (o flag de sistema imutável).

  • Escrever na memória do kernel através de /dev/mem e /dev/kmem.

  • Carregar módulos do kernel.

  • Alterar as regras do firewall.

Para verificar o status do securelevel em um sistema em execução:

# sysctl -n kern.securelevel

A saída contém o valor atual do nível de segurança. Se for maior que 0, pelo menos algumas das proteções do securelevel são ativadas.

O securelevel de um sistema em execução não pode ser reduzido, pois isso invalidaria seu propósito. Se uma tarefa exigir que o securelevel seja não-positivo, altere as variáveis ​​kern_securelevel e kern_securelevel_enable em /etc/rc.conf e reinicialize.

Para obter mais informações sobre o securelevel e as coisas específicas que todos os níveis fazem, consulte init(8).

Atenção:

O securelevel não é uma bala de prata; tem muitas deficiências conhecidas. Mais frequentemente do que não, fornece uma falsa sensação de segurança.

Um dos seus maiores problemas é que, para que seja eficaz, todos os arquivos usados ​​no processo de inicialização até que o nível de segurança seja definido devem ser protegidos. Se um invasor puder fazer o sistema executar seu código antes do nível de segurança que está sendo definido (o que acontece muito tarde no processo de inicialização, pois algumas coisas que o sistema deve fazer na inicialização não podem ser feitas em um nível elevado), suas proteções são invalidadas . Embora essa tarefa de proteger todos os arquivos usados ​​no processo de inicialização não seja tecnicamente impossível, se for obtida, a manutenção do sistema se tornará um pesadelo, já que seria necessário desativar o sistema, pelo menos no modo de usuário único, para modificar um arquivo de configuração.

Este ponto e outros são frequentemente discutidos nas listas de discussão, particularmente na lista de discussão de segurança do FreeBSD. Pesquise nos arquivos aqui para uma discussão extensa. Um mecanismo mais refinado é o preferido.

13.3.

O BIND9 (named) está escutando em algumas portas de numeração alta. O que está acontecendo?

O BIND usa uma porta aleatória de numeração alta para consultas de saída. Versões recentes dele escolhem uma nova porta UDP aleatória para cada consulta. Isso pode causar problemas para algumas configurações de rede, especialmente se um firewall bloquear pacotes UDP de entrada em portas específicas. Para passar por esse firewall, tente as opções avoid-v4-udp-ports e avoid-v6-udp-ports para evitar a seleção de números de porta aleatórios dentro de um intervalo bloqueado.

Atenção:

Se um número de porta (como 53) for especificado através das opções query-source ou query-source-v6 em /usr/local/etc/namedb/named .conf, a seleção de portas aleatórias não será usada. É altamente recomendável que essas opções não sejam usadas para especificar números de porta fixos.

Parabéns, a propósito. É uma boa prática ler a saída sockstat(1) e observar coisas estranhas!

13.4.

O daemon Sendmail está escutando na porta 587, assim como na porta padrão 25! O que está acontecendo?

Versões recentes do Sendmail suportam um recurso de envio de mensagens que é executado pela porta 587. Isso ainda não é amplamente suportado, mas está crescendo em popularidade.

13.5.

O que é essa conta UID 0 toor? Eu fui comprometido?

Não se preocupe. toor é uma conta de superusuário alternativa, onde toor é root soletrada para ao contrário. Ele deve ser usado com um shell não padrão, portanto, o shell padrão para root não precisa ser alterado. Isto é importante porque os shells que não fazem parte da distribuição base, mas que são instalados a partir de ports ou packages, são instalados em /usr/local/bin que, por padrão, reside em um sistema de arquivos diferente . Se o shell do root estiver localizado em /usr/local/bin e o sistema de arquivos contendo /usr/local/bin) não está montado, root não poderá efetuar login para corrigir um problema e terá que reinicializar no modo de usuário único para inserir o caminho para um shell.

Algumas pessoas usam toor para tarefas do dia-a-dia do root com um shell não padrão, deixando o root, com um shell padrão, para o modo de usuário único ou emergências. Por padrão, um usuário não pode logar usando toor porque ele não tem uma senha, então efetue login como root e defina um senha para toor antes de usá-lo para efetuar login.

All FreeBSD documents are available for download at https://download.freebsd.org/ftp/doc/

Questions that are not answered by the documentation may be sent to <freebsd-questions@FreeBSD.org>.
Send questions about this document to <freebsd-doc@FreeBSD.org>.