13.2. Introdução
Anterior | Capítulo 13. Segurança | Próxima

## 13.2. Introdução

Segurança é responsabilidade de todos. Um ponto de entrada fraco em qualquer sistema pode permitir que intrusos obtenham acesso a informações críticas e causem estragos em toda a rede. Um dos princípios centrais da segurança da informação é a tríade CIA, que significa Confidencialidade, Integridade e Disponibilidade dos sistemas de informação.

A tríade CIA é um conceito básico de segurança de computadores, pois os clientes e usuários esperam que seus dados sejam protegidos. Por exemplo, um cliente espera que as informações do cartão de crédito sejam armazenadas com segurança (confidencialidade), que os pedidos não sejam alterados nos bastidores (integridade) e que tenham acesso às informações do pedido em todos os momentos (disponibilidade).

Para fornecer CIA, os profissionais de segurança aplicam uma estratégia de defesa em profundidade. A ideia de defesa em profundidade é adicionar várias camadas de segurança para evitar que uma falha em uma única camada e faça com que todo o sistema de segurança entre em colapso. Por exemplo, um administrador do sistema não pode simplesmente ativar um firewall e considerar a rede ou o sistema seguro. É preciso também auditar contas, verificar a integridade dos binários e garantir que ferramentas maliciosas não estejam instaladas. Para implementar uma estratégia de segurança eficaz, é preciso entender as ameaças e como se defender delas.

O que é uma ameaça no que se refere à segurança do computador? As ameaças não se limitam a invasores remotos que tentam acessar um sistema sem permissão de um local remoto. As ameaças também incluem funcionários, softwares mal-intencionados, dispositivos de rede não autorizados, desastres naturais, vulnerabilidades de segurança e até corporações concorrentes.

Sistemas e redes podem ser acessados ​​sem permissão, às vezes por acidente, ou por atacantes remotos e, em alguns casos, por meio de espionagem corporativa ou ex-funcionários. Como usuário, é importante se preparar e admitir quando um erro levou a uma violação de segurança e relatar possíveis problemas à equipe de segurança. Como administrador, é importante conhecer as ameaças e estar preparado para mitigá-las.

Ao aplicar a segurança aos sistemas, recomenda-se começar protegendo as contas básicas e a configuração do sistema e, em seguida, proteger a camada de rede de modo a aderir à política do sistema e aos procedimentos de segurança da organização. Muitas organizações já possuem uma política de segurança que abrange a configuração de dispositivos de tecnologia. A política deve incluir a configuração de segurança de estações de trabalho, desktops, dispositivos móveis, telefones, servidores de produção e servidores de desenvolvimento. Em muitos casos, procedimentos operacionais padrão (SOPs) já existem. Em caso de dúvida, pergunte à equipe de segurança.

O restante desta introdução descreve como algumas dessas configurações básicas de segurança são executadas em um sistema FreeBSD. O restante deste capítulo descreve algumas ferramentas específicas que podem ser usadas ao implementar uma política de segurança em um sistema FreeBSD.

### 13.2.1. Prevenindo Logins

Ao garantir a segurança de um sistema, um bom ponto de partida é uma auditoria de contas. Assegure-se de que o `root` tenha uma senha forte e que essa senha não seja compartilhada. Desabilite todas as contas que não precisam de acesso de para logar.

Para negar acesso de login a contas, existem dois métodos. O primeiro é bloquear a conta. Este exemplo bloqueia a conta `toor`:

    # pw lock toor

O segundo método é impedir o acesso ao login alterando o shell para `/sbin/nologin`. Apenas o superusuário pode alterar o shell para outros usuários:

    # chsh -s /usr/sbin/nologin toor

O shell `/usr/sbin/nologin` impede que o sistema atribua um shell ao usuário quando ele tenta efetuar login.

### 13.2.2. Escalonamento de Contas Permitido

Em alguns casos, a administração do sistema precisa ser compartilhada com outros usuários. O FreeBSD tem dois métodos para lidar com isso. O primeiro, que não é recomendado, é uma senha de root compartilhada usada por membros do grupo `wheel`. Com esse método, um usuário digita `su` e insere a senha para `wheel` sempre que o acesso do superusuário for necessário. O usuário deve então digitar `exit` para deixar o acesso privilegiado após terminar os comandos que requereram acesso administrativo. Para adicionar um usuário a este grupo, edite `/etc/group` e adicione o usuário ao final da entrada `wheel`. O usuário deve ser separado por um caractere vírgula sem espaço.

O segundo e recomendado método para permitir o escalonamento de privilégios é instalar o pacote ou port security/sudo. Este software fornece auditoria adicional, controle de usuário mais refinado e pode ser configurado para bloquear os usuários para que executem apenas os comandos privilegiados especificados.

Após a instalação, use o `visudo` para editar o `/usr/local/etc/sudoers`. Este exemplo cria um novo grupo `webadmin`, adiciona a conta `trhodes` a esse grupo e configura esse acesso de grupo para reiniciar o apache24:

    # pw groupadd webadmin -M trhodes -g 6000
    # visudo
    %webadmin ALL=(ALL) /usr/sbin/service apache24 *

### 13.2.3. Hashes de Senhas

As senhas são um mal necessário da tecnologia. Quando elas devem ser usadas, elas devem ser complexas e um poderoso mecanismo de hash deve ser usado para criptografar a versão armazenada no banco de dados de senhas. O FreeBSD suporta os algoritmos de DES, MD5, SHA256, SHA512 e Blowfish na sua biblioteca `crypt()`. O padrão de SHA512 não deve ser alterado para um algoritmo hash menos seguro, mas pode ser alterado para o algoritmo Blowfish mais seguro.

### Nota:

O Blowfish não faz parte do AES e não é considerado compatível com nenhum Federal Information Processing Standard (FIPS). Seu uso pode não ser permitido em alguns ambientes.

Para determinar qual algoritmo de hash é usado para criptografar a senha de um usuário, o superusuário pode visualizar o hash do usuário no banco de dados de senhas do FreeBSD. Cada hash começa com um símbolo que indica o tipo de mecanismo de hash usado para criptografar a senha. Se DES for usado, não haverá símbolo de início. Para MD5, o símbolo é `$`. Para SHA256 e SHA512, o símbolo é `$6$`. Para o Blowfish, o símbolo é `$2a$`. Neste exemplo, a senha para `dru` é criptografada usando o algoritmo SHA512 padrão quando o hash começa com `$6$`. Observe que o hash criptografado, não a senha em si, é armazenado no banco de dados de senhas:

    # grep dru /etc/master.passwd
    dru:$6$pzIjSvCAn.PBYQBA$PXpSeWPx3g5kscj3IMiM7tUEUSPmGexxta.8Lt9TGSi2lNQqYGKszsBPuGME0:1001:1001::0:0:dru:/usr/home/dru:/bin/csh

O mecanismo de hash é definido na classe de login do usuário. Para este exemplo, o usuário está na classe de login `default` e o algoritmo de hash é definido com esta linha em `/etc/login.conf`:

            :passwd_format=sha512:\

Para alterar o algoritmo para Blowfish, modifique a linha para ficar assim:

            :passwd_format=blf:\

Em seguida, execute `cap_mkdb /etc/login.conf` conforme descrito em Seção 13.13.1, “Configurando Classes de Login”. Observe que essa alteração não afetará os hashes de senha existentes. Isso significa que todas as senhas devem ser refeitas pedindo aos usuários que executem `passwd` para alterar sua senha.

Para logins remotos, a autenticação de dois fatores deve ser usada. Um exemplo de autenticação de dois fatores é “algo que você tem”, como uma chave, e “algo que você conhece”, como a senha para essa chave. Como o OpenSSH é parte do sistema básico do FreeBSD, todos os logins de rede devem ser sobre uma conexão criptografada e usar autenticação baseada em chave em vez de senhas. Para mais informações, consulte Seção 13.8, “OpenSSH”. Os usuários do Kerberos podem precisar fazer alterações adicionais para implementar o OpenSSH em sua rede. Essas alterações são descritas em Seção 13.5, “Kerberos”.

### 13.2.4. Aplicação de Política de Senha

Aplicar uma política de senha forte para contas locais é um aspecto fundamental da segurança do sistema. No FreeBSD, o tamanho da senha, a força da senha e a complexidade da senha podem ser implementados usando os Módulos de Autenticação Conectáveis ​​(PAM).

Esta seção demonstra como configurar o tamanho mínimo e máximo da senha e a imposição de caracteres mistos usando o módulo `pam_passwdqc.so`. Este módulo é aplicado quando um usuário altera sua senha.

Para configurar este módulo, torne-se o superusuário e remova o comentário da linha contendo `pam_passwdqc.so` em `/etc/pam.d/passwd`. Em seguida, edite essa linha para corresponder à política de senha:

    password        requisite       pam_passwdqc.so         min=disabled,disabled,disabled,12,10 similar=deny retry=3 enforce=users

Este exemplo define vários requisitos para novas senhas. A configuração `min` controla o tamanho mínimo da senha. Ele tem cinco valores porque este módulo define cinco tipos diferentes de senhas com base em sua complexidade. Complexidade é definida pelo tipo de caracteres que devem existir em uma senha, como letras, números, símbolos e maiúsculas e minúsculas. Os tipos de senhas são descritos em pam_passwdqc(8). Neste exemplo, os três primeiros tipos de senha são desativados, o que significa que as senhas que atendem a esses requisitos de complexidade não serão aceitas, independentemente da sua duração. O `12` define uma política de senha mínima de pelo menos doze caracteres, se a senha também contiver caracteres com três tipos de complexidade. O `10` define a política de senha para também permitir senhas de pelo menos dez caracteres, se a senha contiver caracteres com quatro tipos de complexidade.

A configuração `similar` nega senhas semelhantes à senha anterior do usuário. A configuração `retry` fornece ao usuário três oportunidades para inserir uma nova senha.

Depois que este arquivo for salvo, um usuário que alterar sua senha verá uma mensagem semelhante a seguinte:

    % passwd
    Changing local password for trhodes
    Old Password:

    You can now choose the new password.
    A valid password should be a mix of upper and lower case letters,
    digits and other characters.  You can use a 12 character long
    password with characters from at least 3 of these 4 classes, or
    a 10 character long password containing characters from all the
    classes.  Characters that form a common pattern are discarded by
    the check.
    Alternatively, if no one else can see your terminal now, you can
    pick this as your password: "trait-useful&knob".
    Enter new password:

Se uma senha que não corresponde à política for inserida, ela será rejeitada com um aviso e o usuário terá a oportunidade de tentar novamente, até o número configurado de novas tentativas.

A maioria das políticas de senha exige que as senhas expirem depois de tantos dias. Para definir um tempo de expiração da senha no FreeBSD, defina `passwordtime` para a classe de login do usuário em `/etc/login.conf`. A classe de login `default` contém um exemplo:

    #       :passwordtime=90d:\

Portanto, para definir uma expiração de 90 dias para esta classe de login, remova o símbolo de comentário (`#`), salve a edição e execute o `cap_mkdb /etc/login.conf`.

Para definir a expiração em usuários individuais, passe uma data de expiração ou o número de dias para expirar e um nome de usuário para o comando `pw`:

    # pw usermod -p 30-apr-2015 -n trhodes

Como visto aqui, uma data de expiração é definida na forma de dia, mês e ano. Para obter maiores informações, consulte pw(8).

### 13.2.5. Detectando Rootkits

Um rootkit é qualquer software não autorizado que tente obter acesso como `root` a um sistema. Uma vez instalado, esse software mal-intencionado normalmente abrirá outro caminho de entrada para um invasor. Realisticamente, uma vez que um sistema foi comprometido por um rootkit e uma investigação foi realizada, o sistema deve ser reinstalado do zero. Existe um tremendo risco de que mesmo o engenheiro de sistemas ou segurança mais prudente perca algo que um invasor deixou para trás.

Um rootkit faz uma coisa útil para administradores: uma vez detectado, é um sinal de que um comprometimento aconteceu em algum momento. Mas, esses tipos de aplicativos tendem a ser muito bem ocultos. Esta seção demonstra uma ferramenta que pode ser usada para detectar rootkits, security/rkhunter.

Após a instalação deste pacote ou port, o sistema pode ser verificado usando o seguinte comando. Ele produzirá muitas informações e exigirá uma entrada manual da tecla ENTER:

    # rkhunter -c

Depois que o processo for concluído, uma mensagem de status será impressa na tela. Esta mensagem incluirá a quantidade de arquivos verificados, arquivos suspeitos, possíveis rootkits e mais. Durante a verificação, alguns avisos de segurança genéricos podem ser produzidos sobre arquivos ocultos, a seleção do protocolo OpenSSH e versões vulneráveis ​​conhecidas do software instalado. Estes podem ser tratados agora ou após uma análise mais detalhada ter sido realizada.

Todo administrador deve saber o que está sendo executado nos sistemas pelos quais é responsável. Ferramentas de terceiros como o rkhunter e o sysutils/lsof e comandos nativos como o `netstat` e o `ps`, podem mostrar uma grande quantidade de informações sobre o sistema. Faça anotações sobre o que é normal, faça perguntas quando algo parecer fora do lugar e seja paranoico. Embora evitar um comprometimento seja ideal, detectar um comprometimento é imprescindível.

### 13.2.6. Verificação Binária

A verificação de arquivos e binários do sistema é importante porque fornece às equipes de administração e segurança do sistema informações sobre alterações no sistema. Uma aplicação de software que monitora o sistema para alterações é chamado de Sistema de Detecção de Intrusão (IDS).

O FreeBSD fornece suporte nativo para um sistema de IDS básico. Embora os emails de segurança noturnos notifiquem o administrador sobre alterações, as informações são armazenadas localmente e há uma chance de que um usuário mal-intencionado modifique essas informações para ocultar suas alterações no sistema. Como tal, recomenda-se criar um conjunto separado de assinaturas binárias e armazená-las em um diretório de read-only, propriedade do root ou, de preferência, em um disco USB removível ou servidor rsync remoto.

O utilitário `mtree` embutido pode ser usado para gerar uma especificação do conteúdo de um diretório. Um seed, ou uma constante numérica, é usada para gerar a especificação e é necessária para verificar se a especificação não foi alterada. Isso possibilita determinar se um arquivo ou binário foi modificado. Como o valor inicial do seed é desconhecido por um invasor, disfarçar ou impossibilitar a verificação dos valores de checksum dos arquivos será difícil ou impossível. O exemplo a seguir gera um conjunto de hashes SHA256, um para cada sistema binário no diretório `/bin` e salva esses valores em um arquivo oculto no diretório inicial do `root`, `/root/.bin_chksum_mtree`:

    # mtree -s 3483151339707503 -c -K cksum,sha256digest -p /bin > /root/.bin_chksum_mtree
    # mtree: /bin checksum: 3427012225

O `3483151339707503` representa o seed. Este valor deve ser lembrado, mas não compartilhado.

Visualizar o arquivo `/root/.bin_cksum_mtree` deve produzir uma saída semelhante à seguinte:

    #          user: root
    #       machine: dreadnaught
    #          tree: /bin
    #          date: Mon Feb  3 10:19:53 2014

    # .
    /set type=file uid=0 gid=0 mode=0555 nlink=1 flags=none
    .               type=dir mode=0755 nlink=2 size=1024 \
                    time=1380277977.000000000
        \133        nlink=2 size=11704 time=1380277977.000000000 \
                    cksum=484492447 \
                    sha256digest=6207490fbdb5ed1904441fbfa941279055c3e24d3a4049aeb45094596400662a
        cat         size=12096 time=1380277975.000000000 cksum=3909216944 \
                    sha256digest=65ea347b9418760b247ab10244f47a7ca2a569c9836d77f074e7a306900c1e69
        chflags     size=8168 time=1380277975.000000000 cksum=3949425175 \
                    sha256digest=c99eb6fc1c92cac335c08be004a0a5b4c24a0c0ef3712017b12c89a978b2dac3
        chio        size=18520 time=1380277975.000000000 cksum=2208263309 \
                    sha256digest=ddf7c8cb92a58750a675328345560d8cc7fe14fb3ccd3690c34954cbe69fc964
        chmod       size=8640 time=1380277975.000000000 cksum=2214429708 \
                    sha256digest=a435972263bf814ad8df082c0752aa2a7bdd8b74ff01431ccbd52ed1e490bbe7

O nome do host da máquina, a data e a hora em que a especificação foi criada e o nome do usuário que criou a especificação são incluídos neste relatório. Há um checksum, tamanho, hora e um digest SHA256 para cada binário no diretório.

Para verificar se as assinaturas binárias não foram alteradas, compare o conteúdo atual do diretório com a especificação gerada anteriormente e salve os resultados em um arquivo. Este comando requer o seed que foi usado para gerar a especificação original:

    # mtree -s 3483151339707503 -p /bin < /root/.bin_chksum_mtree >> /root/.bin_chksum_output
    # mtree: /bin checksum: 3427012225

Isso deve produzir o mesmo checksum para `/bin` que foi produzido quando a especificação foi criada. Se nenhuma alteração tiver ocorrido nos binários nesse diretório, o arquivo de saída `/root/.bin_chksum_output` estará vazio. Para simular uma alteração, altere a data no arquivo `/bin/cat` usando o `touch` e execute o comando de verificação novamente:

    # touch /bin/cat
    # mtree -s 3483151339707503 -p /bin < /root/.bin_chksum_mtree >> /root/.bin_chksum_output
    # more /root/.bin_chksum_output
    cat changed
    	modification time expected Fri Sep 27 06:32:55 2013 found Mon Feb  3 10:28:43 2014

Recomenda-se criar especificações para os diretórios que contêm binários e arquivos de configuração, bem como quaisquer diretórios que contenham dados sensíveis. Normalmente, as especificações são criadas para `/bin`, `/sbin`, `/usr/bin`, `/usr/sbin`, `/usr/local/bin`, `/etc` e `/usr/local/etc`.

Existem sistemas de IDS mais avançados, como o security/aide. Na maioria dos casos, o `mtree` fornece a funcionalidade que os administradores precisam. É importante manter o valor inicial e a saída do checksum oculta de usuários mal-intencionados. Maiores informações sobre o `mtree` podem ser encontradas em mtree(8).

### 13.2.7. Otimizando o Sistema para Segurança

No FreeBSD, muitos recursos do sistema podem ser ajustados usando o `sysctl`. Alguns dos recursos de segurança que podem ser ajustados para impedir ataques de negação de serviço (DoS) serão abordados nesta seção. Mais informações sobre o uso do `sysctl`, incluindo como alterar temporariamente os valores e como tornar as alterações permanentes após o teste, podem ser encontradas em Seção 11.9, “Efetuando ajustes com o sysctl(8)”.

### Nota:

Sempre que uma configuração é alterada com o `sysctl`, a chance de causar danos indesejados é aumentada, afetando a disponibilidade do sistema. Todas as alterações devem ser monitoradas e, se possível, testadas em um sistema de teste antes de serem usadas em um sistema de produção.

Por padrão, o kernel do FreeBSD é inicializado com um nível de segurança `-1` . Isso é chamado de “modo inseguro” porque as flags de arquivos imutáveis ​​podem ser desativadas e todos os dispositivos podem ser lidos ou gravados. O nível de segurança permanecerá em `-1`, a menos que seja alterado através do `sysctl` ou por uma configuração nos scripts de inicialização. O nível de segurança pode ser aumentado durante a inicialização do sistema, definindo `kern_securelevel_enable` para `YES` no arquivo `/etc/rc.conf`, e o valor de `kern_securelevel` para o nível de segurança desejado. Veja security(7) e init(8) para maiores informações sobre essas configurações e os níveis de segurança disponíveis.

### Atenção:

Aumentar o valor da variável `securelevel` pode quebrar o Xorg e causar outros problemas. Esteja preparado para fazer alguma depuração.

As configurações da variável `net.inet.tcp.blackhole` e `net.inet.udp.blackhole` podem ser usadas para descartar pacotes SYN de entrada em portas fechadas sem enviar uma resposta RST. O comportamento padrão é retornar um RST para mostrar que uma porta está fechada. A alteração do padrão fornece algum nível de proteção contra varreduras de portas, que são usadas para determinar quais aplicativos estão sendo executados em um sistema. Defina `net.inet.tcp.blackhole` para `2` e `net.inet.udp.blackhole` para `1`. Consulte blackhole(4) para obter maiores informações sobre essas configurações.

As configurações das variáveis `net.inet.icmp.drop_redirect` e `net.inet.ip.redirect` ajudam a evitar ataques de redirecionamento. Um ataque de redirecionamento é um tipo de DoS que envia um grande número de pacotes ICMP tipo 5. Como esses pacotes não são necessários, configure `net.inet.icmp.drop_redirect` para `1` e configure `net.inet.ip.redirect` para `0`.

O roteamento de origem é um método para detectar e acessar endereços não roteáveis ​​na rede interna. Isso deve ser desativado, pois endereços não roteáveis ​​normalmente não são roteáveis ​​de propósito. Para desativar este recurso, defina `net.inet.ip.sourceroute` e `net.inet.ip.accept_sourceroute` como `0`.

Quando uma máquina na rede precisa enviar mensagens para todos os hosts em uma sub-rede, uma mensagem de solicitação echo do ICMP é enviada para o endereço de broadcast. No entanto, não há motivo para um host externo executar essa ação. Para rejeitar todas as solicitações externas de transmissão, defina `net.inet.icmp.bmcastecho` como `0`.

Algumas configurações adicionais estão documentadas em security(7).

Anterior | Acima | Próxima
Capítulo 13. Segurança | Principal | 13.3. Senhas de Uso Unico

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