[ anterior ] [ Conteúdo ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ A ] [ B ] [ C ] [ D ] [ E ] [ F ] [ G ] [ H ] [ próximo ]


Securing Debian Manual
Capítulo 4 - Após a instalação


Assim que o sistema for instalado, você ainda poderá fazer mais para deixá-lo mais seguro; alguns dos passos descritos neste capítulo podem ser seguidos. É claro que isto depende de sua configuração, mas para prevenção de acesso físico você deverá ler Altere a BIOS (de novo), Seção 4.3,Configurar a senha do LILO ou GRUB, Seção 4.4,Remover o aviso de root do kernel, Seção 4.5, Desativando a inicialização através de disquetes, Seção 4.6, Restringindo o acesso de login no console, Seção 4.7 e Restringindo reinicializações do sistema através da console, Seção 4.8.

Antes de se conectar a qualquer rede, especificamente se for uma rede pública, no mínimo execute uma atualização de segurança (veja Executar uma atualização de segurança, Seção 4.2). Opcionalmente, você deverá fazer um snapshot do seu sistema (veja Fazendo um snapshot do sistema, Seção 4.18).


4.1 Inscreva-se na lista de discussão "Anúncios de Segurança do Debian"

Para receber informações sobre atualizações e alertas de segurança (DSAs) disponíveis e DSAs você deverá se inscrever na lista de discussão debian-security-announce. Veja O time Debian Security, Seção 7.1 para mais informações sobre como o time de segurança do Debian funciona. Para mais informações sobre como se inscrever nas listas de discussões do Debian, leia http://lists.debian.org.

Os DSAs são assinados pelo time de segurança do Debian e as assinaturas podem ser pegas através do endereço http://security.debian.org.

Você deverá considerar, também, em se inscrever na lista de discussão debian-security para discussões gerais de problemas de segurança no sistema operacional Debian. Na lista você poderá entrar em contato com outros administradores de sistemas experientes, assim como também desenvolvedores do Debian e autores de ferramentas de segurança que podem responder suas questões e oferecer recomendações.

FIXME: também adicionar a chave aqui?


4.2 Executar uma atualização de segurança

Assim que novos bugs são descobertos nos pacotes, os mantenedores do Debian e autores de software geralmente aplicam patches dentro de dias ou até mesmo horas. Após uma falha ser corrigida, um novo pacote é disponibilizado em http://security.debian.org.

Se estiver instalando um lançamento do Debian, você deverá ter em mente que desde que o lançamento foi feito devem existir atualizações de segurança que podem determinar um pacote como vulnerável. Também existem lançamentos menores (foram sete no lançamento da 2.2 potato) que incluem estas atualizações de pacotes.

Você precisa anotar a data em que a mídia removível foi feita (se estiver usando uma) e verificar o site de segurança para ter certeza que existem atualizações de segurança. Se existem atualizações e você não puder baixar os pacotes de um site security.debian.org em outro sistema (você não está conectado na Internet ainda? está?) antes de se conectar a rede você deverá considerar (se não estiver protegido por um firewall, por exemplo) adicionar regras de firewall assim seu sistema somente poderá se conectar a security.debian.org e então executar a atualização. Um modelo de configuração é mostrado em Atualização de segurança protegida por um firewall, Apêndice F.

Nota:Desde o Debian woody 3.0, após a instalação você terá a oportunidade de adicionar atualizações de segurança ao sistema. Se disser "sim" a isto, o sistema de instalação tomará os passos apropriados para adicionar a fonte de origem para as atualizações de segurança para sua origem de pacotes e seu sistema. Se já tiver uma conexão de Internet, o sistema baixará e instalará qualquer atualização de segurança que produziu após a mídia ser criada. Se estiver atualizando a partir de uma versão anterior do Debian, o perguntou ao sistema de instalação para não fazer isto, você deverá realizar os passos descritos aqui.

Para atualizar manualmente o sistema, insira a seguinte linha em seu sources.list e você obterá as atualizações de segurança automaticamente, sempre que atualizar seu sistema.

       deb http://security.debian.org/ stable/updates main contrib non-free

Assim que instalar isto, você poderá usar ou o apt ou dselect para atualizar:

Se quiser, você também poderá adicionar linhas deb-src ao seu arquivo /etc/apt/sources.list. Veja apt(8) para mais detalhes.

Nota: Você não precisa adicionar a seguinte linha:

       deb http://security.debian.org/debian-non-US stable/non-US main contrib non-free

isto é porque security.debian.org é hospedado em uma localização fora dos Estados Unidos e não possui um arquivo separado non-US.


4.3 Altere a BIOS (de novo)

Se lembra Escolha uma senha para a BIOS, Seção 3.1? Bem, então você deve agora, uma vez que não precisa inicializar através de uma mídia removível, alterar a configuração padrão da BIOS, desta forma ela poderá somente inicializar a partir do disco rígido. Tenha certeza de que não perderá a senha da BIOS, caso contrário, se ocorrer uma falha no disco rígido você não será capaz de retornar a BIOS e alterar a configuração e recuperá-la usando, por exemplo, um CD-ROM.

Outro método mais conveniente, mas menos seguro, é alterar a configuração para ter o sistema inicializando a partir do disco rígido e, caso falhe, tentar a mídia removível. Por agora, isto é feito freqüentemente porque a maioria das pessoas não usam a senha de BIOS com freqüência; pois se esquecem dela facilmente.


4.4 Configurar a senha do LILO ou GRUB

Qualquer um pode facilmente obter uma linha de comando de root e alterar sua senha entrando com o parâmetro <name-of-your-bootimage> init=/bin/sh no aviso de boot. Após alterar a senha e reiniciar o sistema, a pessoa terá acesso ilimitado como usuário root e poderá fazer qualquer coisa que quiser no sistema. Após este processo, você não terá acesso root ao seu sistema, já que não saberá mais sua senha.

Para se assegurar que isto não ocorra, você deverá definir uma senha para o gerenciador de partida. Escolha entre uma senha global ou uma senha para determinada imagem.

Para o LILO, você precisará editar o arquivo de configuração /etc/lilo.conf e adicionar uma linha password e restricted como no exemplo abaixo.

       image=/boot/2.2.14-vmlinuz
          label=Linux
          read-only
          password=mude-me
          restricted

Quando terminar, re-execute o lilo. Caso omita restricted o lilo sempre perguntará por uma senha, não importando se foram passados parâmetros de inicialização. As permissões padrões do /etc/lilo.conf garantem permissões de leitura e gravação para o root e permite o acesso somente leitura para o grupo do lilo.conf, geralmente root.

Caso utilize o GRUB ao invés do LILO, edite o /boot/grub/menu.lst e adicione as seguintes duas linhas no topo do arquivo (substituindo, é claro mude-me pela senha designada). Isto evita que usuários editem os itens de inicialização. A opção timeout 3 especifica uma espera de 3 segundos antes do grub inicializar usando o item padrão.

       timeout 3
       password mude-me

Para fortalecer futuramente a integridade da senha, você poderá armazenar a senha em um formato criptografado. O utilitário grub-md5-crypt gera um hash de senha que é compatível com o algoritmo de senha encriptada pelo grub (md5). Para especificar no grub que uma senha no formato md5 será usada, use a seguinte diretiva:

       timeout 3
       password --md5 $1$bw0ez$tljnxxKLfMzmnDVaQWgjP0

O parâmetro --md5 foi adicionado para instruir o grub a fazer o processo de autenticação md5. A senha fornecida é uma versão encriptada md5 do mude-me. O uso do método de senhas md5 é preferido em contrapartida da seleção de sua versão texto plano. Mais informações sobre senhas do grub podem ser encontradas no pacote grub-doc.


4.5 Remover o aviso de root do kernel

Os kernels 2.4 do Linux oferecem um método de acessar um shell de root durante a inicialização que será logo mostrado após de carregar o sistema de arquivos cramfs. Uma mensagem aparecerá para permitir ao administrador entrar com um interpretador de comandos executável com permissões de root, este shell poderá ser usado para carregar manualmente módulos quando a auto-detecção falhar. Este comportamento é padrão para o linuxrc do initrd. A seguinte mensagem será mostrada:

       Press ENTER to obtain a shell (waits 5 seconds)

Para remover este comportamento, você precisará alterar o /etc/mkinitrd/mkinitrd.conf e definir:

       # DELAY  O número de segundos que o script linuxrc deverá aguardar para
       # permitir ao usuário interrompe-lo antes do sistema ser iniciado
       DELAY=0

Então gere novamente sua imagem do disco ram. Um exemplo de como fazer isto:

       # cd /boot
       # mkinitrd -o initrd.img-2.4.18-k7 /lib/modules/2.4.18-k7

ou (preferido):

       # dpkg-reconfigure -plow kernel-image-2.4.x-yz

Note que o Debian 3.0 woody permite aos usuários instalarem o kernel 2.4 (selecionando tipos de kernels), no entanto o kernel padrão é o 2.2 (salvo para algumas arquitetura no qual o kernel 2.2 ainda não foi portado). Se você acha que isto é um bug, veja Bug 145244 antes de reporta-lo.


4.6 Desativando a inicialização através de disquetes

O MBR padrão no Debian antes da versão 2.2 não atua como setor mestre de partida como recomendado e deixa aberto um método de se fazer a quebra do sistema:

Este comportamento pode ser alterado com:

       lilo -b /dev/hda

Agora o LILO foi colocado na MBR. Isto também pode ser feito adicionando-se boot=/dev/hda ao arquivo de configuração lilo.conf. Existe também outra solução que desativa o prompt MBR completamente:

       install-mbr -i n /dev/hda

Por outro lado, esta "porta dos fundos", no qual muitas pessoas simplesmente não se preocupam, podem salvar pessoas que tiverem problemas com sua instalação por quaisquer razões.

FIXME verifique se isto é realmente verdade no kernel 2.2, ou foi no 2.1? INFO: Os disquetes de inicialização no Debian 2.2 não instalam o mbr, mas somente o LILO.


4.7 Restringindo o acesso de login no console

Algumas políticas de segurança podem forçar os administradores a entrar no sistema através do console com seus usuários/senhas e então se tornar o superusuário (com o su ou sudo). Esta política é implementada no Debian editando-se o arquivo /etc/login.defs ou /etc/securetty quando utilizar PAM. Em:

Quando utilizar PAM, outras alterações no processo de login, que podem incluir restrições a usuários e grupos em determinadas horas, podem ser configurados no /etc/pam.d/login. Uma característica interessante que pode ser desativada é a possibilidade de fazer login sem senhas. Esta característica pode ser limitada removendo-se nullok da seguinte linha:

       auth       required   pam_unix.so nullok

4.8 Restringindo reinicializações do sistema através da console

Caso seu sistema tenha um teclado conectado, qualquer um (sim, qualquer um) poderá reinicializar o sistema sem efetuar login. Isto pode se encaixar ou não em sua política de segurança. Se deseja restringir isto, você deverá alterar o arquivo /etc/inittab assim a linha que inclui a chamada para ctrlaltdel executará shutdown com a opção -a (lembre-se de executar o init q após realizar qualquer modificação neste arquivo). O padrão no Debian inclui esta opção:

       ca:12345:ctrlaltdel:/sbin/shutdown -t1 -a -r now

Agora para permitir somente que alguns usuários possam desligar o sistema, como descreve a página de manual shutdown(8), você deverá criar o arquivo /etc/shutdown.allow e incluir lá os nomes de usuários que podem reiniciar o sistema. Quando a combinação de três teclas (a.k.a. Ctrl+Alt+del) for feita, o programa verificará se qualquer um dos usuários listados estão conectados ao sistema. Se nenhum deles estiver, o shutdown não reiniciará o sistema.


4.9 Montando partições do jeito certo

Quando montar uma partição ext2, existem diversas opções adicionais que pode utilizar para a chamada de montagem ou para o /etc/fstab. Por exemplo, esta é minha configuração do fstab para a partição /tmp:

       /dev/hda7    /tmp    ext2    defaults,nosuid,noexec,nodev    0    2

Observe as diferenças na seção opções. A opção nosuid ignore os bits setuid e setgid completamente, enquanto a noexec proíbe a execução de qualquer programa naquele ponto de montagem, e a nodev ignora dispositivos. Isto soa muito bem, mas elas:

A opção noexec evita que os binários sejam executados diretamente, mas isto é facilmente contornado:

       alex@joker:/tmp# mount | grep tmp
       /dev/hda7 on /tmp type ext2 (rw,noexec,nosuid,nodev)
       alex@joker:/tmp# ./date
       bash: ./date: Permission denied
       alex@joker:/tmp# /lib/ld-linux.so.2 ./date
       Sun Dec  3 17:49:23 CET 2000

No entanto, muitos script kiddies tem exploits que tentam criar e executar arquivos em /tmp. se eles não tem conhecimento disto, caem nesta restrição. Em outras palavras, um usuário não pode ser convencido a executar um binário alterado em /tmp e.g. quando acidentalmente adicionar /tmp em sua variável PATH.

Esteja já avisado que muitos scripts dependem de /tmp sendo executável. Mais notavelmente, o Debconf tem (ainda?) alguns problemas relacionados a isto, para mais informações veja o bug 116448.

A parte a seguir é mais um tipo de exemplo. Uma nota, no entanto: /var pode ser ajustado para noexec, mas alguns programas [11] mantém seus programas sob /var. O mesmo se aplica a opção nosuid.

     /dev/sda6   /usr          ext2    defaults,ro,nodev       0       2
     /dev/sda12  /usr/share    ext2    defaults,ro,nodev,nosuid        0       2
     /dev/sda7   /var          ext2    defaults,nodev,usrquota,grpquota0       2
     /dev/sda8   /tmp          ext2    defaults,nodev,nosuid,noexec,usrquota,grpquota    0       2
     /dev/sda9   /var/tmp      ext2    defaults,nodev,nosuid,noexec,usrquota,grpquota    0       2
     /dev/sda10  /var/log      ext2    defaults,nodev,nosuid,noexec    0       2
     /dev/sda11  /var/account  ext2    defaults,nodev,nosuid,noexec    0       2
     /dev/sda13  /home         ext2    rw,nosuid,nodev,exec,auto,nouser,async,usrquota,grpquota                0       2
     /dev/fd0    /mnt/fd0      ext2    defaults,users,nodev,nosuid,noexec      0       0
     /dev/fd0    /mnt/floppy   vfat    defaults,users,nodev,nosuid,noexec      0       0
     /dev/hda    /mnt/cdrom    iso9660 ro,users,nodev,nosuid,noexec            0       0

4.9.1 Ajustando a opção noexec em /tmp

Tenha cuidado em ajustar a opção noexec em /tmp quando desejar instalar novos programas, pois alguns programas o utilizam para a instalação. O Apt é um dos tais programas (veja http://bugs.debian.org/116448), isto pode ser resolvido alterando-se a variável APT::ExtractTemplates::TempDir (veja apt-extracttemplates(1)). Você poderá definir esta variável no arquivo /etc/apt/apt.conf apontando para outro diretório com privilégio de execução ao invés de /tmp.

Com relação a noexec, esteja alertado que ela pode não oferecer tanta segurança assim. Considere este exemplo:

       $ cp /bin/date /tmp
       $ /tmp/date
       (does not execute due to noexec)
       $/lib/ld-linux.so.2 /tmp/date
       (funciona, pois o comando date não é executado diretamente)

4.9.2 Definindo o /usr como somente-leitura

Se configurar o /usr como somente leitura, você não será capaz de instalar novos pacotes em seu sistema Debian GNU/Linux. Você terá primeiro que remontá-lo como leitura-gravação, instalar os pacotes e então remontá-lo como somente-leitura. A última versão do apt (no Debian woody 3.0) pode ser configurada para executar comandos antes e após instalar pacotes, assim você pode querer configurá-lo corretamente.

Para fazer isto, modifique o /etc/apt/apt.conf e adicione:

       DPkg
       {
           Pre-Invoke  { "mount /usr -o remount,rw" };
           Post-Invoke { "mount /usr -o remount,ro" };
       };

Note que o Post-Invoke pode falhar com a mensagem de erro "/usr busy". Isto acontece basicamente porque está usando arquivos durante a atualização que foram atualizados. Você encontrará estes programas executando

     # lsof +L1

Interrompa ou reinicie estes programas e execute manualmente o Post-Invoke. Cuidado! Isto significa que você provavelmente precisará reiniciar sua seção do X (se estiver executando uma) cada vez que fizer uma grande atualização em seu sistema. Você deverá levar em conta se um sistema de arquivos /usr somente-leitura é adequado ao seu sistema. Veja também isto discussion on debian-devel about read-only /usr.


4.10 Fornecendo acesso seguro ao usuário


4.10.1 Autenticação do Usuário: PAM

O PAM (módulos de autenticação alteráveis) permite ao administrador do sistema escolher como os aplicativos autenticarão os usuários. Note que o PAM não pode fazer nada caso o aplicativo não esteja compilado com suporte a PAM. A maioria dos aplicativos que vem com o Debian 2.2 tem este suporte ativado. Além do mais, o Debian não tem suporte a PAM em versões anteriores a 2.2. A configuração atual para qualquer serviço que tenha PAM ativado é para emular a autenticação do UNIX (leia /usr/share/doc/libpam0g/Debian-PAM-MiniPolicy.gz para mais informações sobre como os serviços PAM devem funcionar no Debian).

Cada aplicação com suporte a PAM fornece um arquivo de configuração em /etc/pam.d/ que pode ser usado para modificar seu comportamento:

A seguinte descrição está longe de ser completa, para mais informações você deve ler o Guia do Administrador de Sistemas Linux-PAM (presente no site primário de distribuição do PAM). Este documento também pode ser encontrado no pacote do Debian libpam-doc.

O PAM lhe oferece a possibilidade de utilizar vários passos de autenticação de uma só vez, sem o conhecimento do usuário. Você pode autenticar em um banco de dados Berkeley e no banco de dados no arquivo passwd padrão, e o usuário somente entrará no sistema caso ele se autentique corretamente em ambos. Você pode restringir muita coisa com o PAM, como também abrir bastante as portas do seu sistema. Assim, seja cauteloso. Uma linha de configuração típica que tem o tempo de controle como seu segundo elemento: Geralmente ele deve ser ajustado para requisite, que retorna uma falha de login caso um dos módulos falhe.

A primeira coisa que eu gosto de fazer é adicionar o suporte a MD5 nas aplicações com suporte a PAM, pois isto nos ajuda a se proteger contra ataques de dicionário (as senhas podem ser maiores se estiver usando MD5). As seguintes duas linhas podem ser adicionadas em todos os arquivos em /etc/pam.d/ que garantem acesso a máquina, como login e ssh.

       # Tenha certeza de instalar primeiro o libpam-cracklib ou então não será capaz
       # de se logar no sistema
       password   required     pam_cracklib.so retry=3 minlen=12 difok=3
       password   required     pam_unix.so use_authtok nullok md5

Assim, o que este encanto faz? A primeira linha carrega o módulo cracklib do PAM, que fornece checagem de senhas fracas, pergunta por uma nova senha com no mínimo de 12 caracteres, uma diferença de pelo menos 3 letras da antiga senha e permite 3 novas tentativas. O Cracklib depende do pacote wordlist (tal como wenglish, wspanish, wbritish, ...), assim tenha certeza de instalar um que seja apropriado a seu idioma ou o cracklib pode não ser totalmente útil. [12] A segunda linha introduz o módulo de autenticação padrão com senhas MD5 e permite uma senha de tamanho zero. A diretiva use_authtok é necessária para pegar a senha do módulo anterior.

Para se assegurar que o usuário root pode somente se logar no sistema de terminais locais, a seguinte linha deverá ser ativada no /etc/pam.d/login:

       auth     requisite  pam_securetty.so

Então você deverá modificar a lista de terminais no qual o usuário root pode se logar no sistema no arquivo /etc/securetty. Alternativamente, você poderá ativar o módulo pam_access e modificar o arquivo /etc/security/access.conf que possui um controle de acesso mais fino e geral, mas (infelizmente) não possui mensagens de log decentes (o log dentro do PAM não é padronizado e é particularmente um problema a ser tratado). Nós voltaremos no arquivo access.conf um pouco mais a frente.

Em seguida, a seguinte linha deverá ser ativada no /etc/pam.d/login para ativar a restrição dos recursos do usuário.

       session  required   pam_limits.so

Isto restringe os recursos do sistema que os usuários têm permissão (veja abaixo em Limitando o uso de recursos: o arquivo limits.conf, Seção 4.10.2 ). Por exemplo, você pode restringir o número de logins concorrentes (de um determinado grupo de usuários, ou de todo o sistema), número de processos, tamanho de memória, etc.

Agora, edite o arquivo /etc/pam.d/passwd e altere a primeira linha. Você deverá adicionar a opção "md5" para usar senhas MD5, altere o tamanho mínimo da senha de 4 para 6 (ou mais) e ajuste o tamanho máximo, se quiser. A linha resultante deverá se parecer com isto:

       password   required   pam_unix.so nullok obscure min=6 max=11 md5

Se planeja proteger o su, faça isto de forma que somente algumas pessoas possam usá-lo para se tornar o usuário root em seu sistema, você precisará adicionar um novo grupo chamado "wheel" em seu sistema (que é o método mais limpo, pois nenhum arquivo tem tal permissão deste grupo ainda). adicione neste grupo o root e outros usuários que devem ter permissão de su para se tornar root. Então adicione a seguinte linha no /etc/pam.d/su:

       auth        requisite   pam_wheel.so group=wheel debug

Isto assegura que somente algumas pessoas do grupo "wheel" poderão usar su para se tornar o usuário root. Outros usuários não poderão ser capazes de se tornar root. De fato eles obterão uma mensagem de acesso negado ao tentarem se tornar root.

Se deseja que somente alguns usuários se autentiquem em um serviço do PAM, é muito fácil fazer isto usando arquivos onde os usuários que tem permissão de fazer login (ou não) são armazenados. Imagine que você somente deseja permitir o usuário "ref" a fazer o login usando ssh. Assim, coloque o usuário no arquivo /etc/sshusers-allowed e escreva o seguinte no arquivo /etc/pam.d/ssh:

       auth        required    pam_listfile.so item=user sense=allow file=/etc/sshusers-allowed onerr=fail

Depois crie o arquivo /etc/pam.d/other e entre com as seguintes linhas:

       auth     required       pam_securetty.so
       auth     required       pam_unix_auth.so
       auth     required       pam_warn.so
       auth     required       pam_deny.so
       account  required       pam_unix_acct.so
       account  required       pam_warn.so
       account  required       pam_deny.so
       password required       pam_unix_passwd.so
       password required       pam_warn.so
       password required       pam_deny.so
       session  required       pam_unix_session.so
       session  required       pam_warn.so
       session  required       pam_deny.so

Esta linhas lhe oferecerão uma boa configuração padrão para todas as aplicações que suportam PAM (o acesso é negado por padrão).


4.10.2 Limitando o uso de recursos: o arquivo limits.conf

Você realmente deverá dar uma olhada séria neste arquivo. Aqui você poderá limitar os recursos usados pelos usuários. Se utilizar PAM, o arquivo /etc/limits.conf será ignorado e deverá usar o /etc/security/limits.conf ao invés deste.

Se você não restringir o uso de recursos, qualquer usuário com um interpretador de comandos válido em seu sistema (ou até mesmo um intruso que comprometeu o sistema através de um serviço) pode usar a quantidade de CPU, memória, pilhas, etc. que o sistema puder fornecer. Este problema de exaustão de recursos pode somente ser corrigido com o uso de PAM. Note que lá existe um método para adicionar limitação de recursos para alguns interpretadores de comandos (por exemplo, o bash possui ulimit, veja bash(1)), mas nem todos os interpretadores oferecem as mesmas limitações e também o usuário pode mudar seu shell (veja chsh(1)). Então é melhor colocar as limitações nos módulos do PAM.

Mais detalhes podem ser lidos em:

FIXME: Colocar um belo limits.conf acima deste local


4.10.3 Ações de login do usuário: edite o /etc/login.defs

O próximo passo é editar a configuração e ação básica que será feita após o login do usuário. Note que este arquivo não é parte da configuração do PAM, é um arquivo de configuração lido pelos programas login e su, assim não faz sentido configurá-lo para casos onde nem um dos programas são indiretamente chamados (o programa getty que é executado através do console e requer login e senha, executa o login).

       FAIL_DELAY          10

Esta variável deve se ajustada para um valor alto para tornar difícil ataques brute force através de tentativas de logon no terminal. Caso uma senha incorreta seja digitada, o possível atacante (ou o usuário normal!) terá que aguardar 10 segundos para obter um novo aviso de login, que é bastante tempo quando se utiliza programas automatizados para esta tarefa.

       FAILLOG_ENAB        yes

Se ativar esta variável, as falhas nas tentativas de login serão registradas. É importante mantê-las para pegar alguém que tente fazer um ataque brute force.

       LOG_UNKFAIL_ENAB    yes

Se ajustar a variável FAILLOG_ENAB para yes, então você deverá também ajustar esta variável para yes. Isto gravará nomes de usuários desconhecidos caso o login falhar. Se fizer isto, tenha certeza que os logs tenham permissões corretas (640 por exemplo, com a configuração apropriada de grupo tal como adm), pois os usuários podem acidentalmente entrar com suas senhas como se fossem nomes de usuários e você não desejará que outros as vejam.

       SYSLOG_SU_ENAB      yes

Isto somente permite que sejam registradas tentativas do uso de su no syslog. Muito importante em máquinas em produção, mas note que isto pode criar também problemas de privacidade.

       SYSLOG_SG_ENAB      yes

O mesmo que SYSLOG_SU_ENAB mas se aplica ao programa sg.

       MD5_CRYPT_ENAB      yes

Como mencionado acima, as senhas em MD5 reduzem fortemente o problema de ataques de dicionário, pois você poderá usar senhas grandes. Se estiver usando a versão slink, leia os documentos sobre MD5 antes de ativar esta opção. Caso contrário, isto é definido no PAM.

       PASS_MAX_LEN        50

Caso senhas MD5 sejam ativadas em sua configuração do PAM, então esta variável deverá ter o mesmo valor da que é usada lá.


4.10.4 Restringindo o ftp: editando o /etc/ftpusers

O arquivo /etc/ftpusers contém uma lista de usuários que não podem logar no sistema usando ftp. Somente use este arquivo se você realmente deseja permitir ftp (que não é recomendado em geral, pois utiliza autenticação de senhas em texto plano). Caso seu daemon suporta PAM, você poderá também usá-lo para permitir e bloquear usuários para certos serviços.

FIXME (BUG): É m bug que o arquivo ftpusers padrão no Debian não inclua todos os usuários administrativos (do base-passwd).


4.10.5 Usando su

Se você realmente precisa que os usuários se tornem superusuário em seu sistema, e.g. para instalar pacotes ou adicionar usuários, você pode usar o comando su para alterar sua identidade. Você deverá tentar evitar se logar como usuário root, usando o su ao invés disto. Atualmente a melhor solução é remover o su e utilizar os mecanismos do sudo que tem uma lógica mais geral e mais características que o su. No entanto, o su é mais comum e é usado em muitos outros sistemas Unix.


4.10.6 Usando o sudo

O programa sudo permite ao usuário executar comandos definidos com outra identidade de usuário, até mesmo como usuário root. Se o usuário for adicionado ao arquivo /etc/sudoers e se autenticar corretamente, ele será capaz de executar comandos que foram definidos no /etc/sudoers. Violações, tais com senhas incorretas ou tentativa de executar um programa que não tem permissões, são registradas e enviadas para o usuário root.


4.10.7 Desativação de acesso administrativo remoto

Você deverá modificar o /etc/security/access.conf para bloquear logins remotos para contas administrativas. Desta forma, usuários precisarão executar o su (ou sudo) para usar qualquer poder administrativo e traços para auditoria apropriada sempre serão gerados.

Você precisará adicionar a seguinte linha no arquivo /etc/security/access.conf, o arquivo padrão de configuração do Debian tem a linha de exemplo comentada:

        -:wheel:ALL EXCEPT LOCAL

Lembre-se de ativar o módulo pam_access para cada serviço (ou configuração padrão) em /etc/pam.d/ se quiser que suas alterações em /etc/security/access.conf sejam mantidas.


4.10.8 Restringindo acessos de usuários

Algumas vezes você deve pensar que precisa ter seus usuários criados em seu sistema local para oferecer acesso a um determinado serviço (serviço de mensagens pop3 ou ftp). Antes de fazer isto, primeiro lembre-se que a implementação do PAM no Debian GNU/Linux lhe permite validar usuários em uma grande variedade de serviços de diretório externos (radius, ldap, etc.) através dos pacote libpam.

Caso os usuários precisem ser criados e o sistema poderá ser acessado remotamente, tenha em mente que os usuários poderão ser capazes de se logar no sistema. Você poderá corrigir isto dando aos usuários um shell nulo (/dev/null) (ele não precisará estar listado no arquivo /etc/shells). Se deseja permitir aos usuários acessar o sistema mas com seus movimentos limitados, você poderá usar o /bin/rbash, que é equivalente a adicionar a opção -r ao bash (RESTRICTED SHELL veja bash(1)). Por favor observe que até mesmo em um shell restrito, um usuário pode acessar um programa interativo (que pode permitir a execução de um subshell) e poderá pular as limitações do shell.

O Debian atualmente fornece em sua versão instável (e poderá ser incluída em uma futura versão estável) do módulo pam_chroot (no pacote libpam-chroot). Uma alternativa a ele é o chroot o serviço que fornece log remoto (ssh, telnet).[13]

Se você deseja restringir quando seus usuários podem acessar o sistema, você deverá personalizar o /etc/security/access.conf a suas necessidades.

Informações sobre como fazer chroot dos usuários acessando o sistema através do ssh é descrito em Ambiente chroot para SSH, Apêndice G.


4.10.9 Auditoria do usuário

Se você é realmente paranóico, pode querer adicionar uma configuração em todo o sistema para auditar o que os usuários estão fazendo no sistema. Esta seção mostra algumas dicas de utilitários diversos que poderão ser usados.


4.10.9.1 Auditoria de entrada e saída com o script

Você poderá usar o comando script para auditar ambos o que os usuários executam e quais são os resultados destes comandos.Não é possível definir o script como um interpretador de comandos (até mesmo se ele for adicionado ao arquivo /etc/shells). Mas você poderá ter o arquivo de inicialização do shell executando o seguinte:

     umask 077
     exec script -q -a "/var/log/sessions/$USER"

É claro, se você fizer isto de forma que afete todo o sistema, significa que o shell não continuará lendo arquivos de configurações pessoais (pois ele será substituído pelo script). Uma alternativa é fazer isto nos arquivos de inicialização do usuário (mas então o usuário poderá removê-la, veja os comentários sobre isto abaixo)

Você também precisa ajustar os arquivos no diretório de auditoria (no exemplo /var/log/sessions/) assim os usuários poderão gravar para ele, mas não poderão remover o arquivo. Isto pode ser feito, por exemplo, criando os arquivos de seção de usuário antecipadamente e definindo a opção append-only usando o chattr.

Uma alternativa útil para administradores de sistemas, que inclui informações sobre data, pode ser:

     umask 077
     exec script -q -a "/var/log/sessions/$USER-`date +%Y%m%d`"

4.10.9.2 Usando o arquivo de histórico do interpretador de comandos

Se deseja rever o que o usuário está digitando no seu shell (mas não se sabe qual seu resultado) você poderá configurar um /etc/profile para todo o sistema que configura o ambiente de forma que todos os comandos são salvos em um arquivo de histórico. A configuração de todo o sistema precisa ser feita de forma que os usuários não possam remover as capacidades de auditoria em seu shell. Isto muitas vezes é específica de cada shell assim tenha certeza que todos os usuários estão utilizando um shell que suporte isto.

Por exemplo, para o bash, o /etc/profile deverá ser ajustado da seguinte forma [14] :

       HISTFILE=~/.bash_history
       HISTSIZE=10000
       HISTFILESIZE=999999
       # Don't let the users enter commands that are ignored
       # in the history file
       HISTIGNORE=""
       HISTCONTROL=""
       readonly HISTFILE
       readonly HISTSIZE
       readonly HISTFILESIZE
       readonly HISTIGNORE
       readonly HISTCONTROL
       export HISTFILE HISTSIZE HISTFILESIZE HISTIGNORE HISTCONTROL

Para isto funcionar, o usuário poderá somente adicionar dados ao .bash_history. Você também precisará ajustar a opção append-only usando o programa chattr para o .bash_history de todos os usuários. [15].

Note que você poderá introduzir as configurações acima no arquivo .profile do usuário. Mas então você precisará ajustar permissões adequadamente de tal forma que isto prevenirá que o usuário modifique este arquivo. Isto inclui: ter os diretórios home dos usuários não pertencendo ao usuário (pois ele seria capaz de remover o arquivo) mas da mesma forma permitir ler o arquivo de configuração .profile e gravar no .bash_history. Seria bom ajustar a opção imutável (usando também o chattr) também para o .profile se fizer desta forma.


4.10.9.3 Auditoria completa do usuário com ferramentas de contabilização

O exemplo anterior é um método simples de se configurar a auditoria do usuário, mas pode não ser útil para sistemas complexos ou para este em que os usuários não precisam executar um shell (de forma exclusiva). Neste caso, você precisará dar uma olhada no pacote acct, que contém ferramentas de contabilização. Estes utilitários registrarão todos os comandos executados pelos usuários ou por processos no sistema, ao custo de espaço em disco.

Quando ativar a contabilização, todas as informações sobre processos e usuários são mantidas sob /var/account/, mais especificamente em pacct. O pacote de contabilização inclui algumas ferramentas como (sa, ac e lastcomm) para realizar a análise destes dados.


4.10.9.4 Outros métodos de auditoria do usuário

Se você for completamente paranóico e deseja auditar cada comando do usuário, você deverá pegar o código fonte do bash, editá-lo e assim ter ele enviando tudo o que o usuário digitar para outro arquivo. Ou ter o pacote ttysnoop monitorando constantemente qualquer novo ttys [16] e gravar sua saída para um arquivo. Outro programa útil é o snoopy (veja também the project page) que é um programa transparente ao usuário que trabalha em cima de uma biblioteca fornecendo um gancho nas chamadas execve(), qualquer comando executado é registrado no syslogd usando a facilidade authpriv (normalmente armazenada em /var/log/auth.log).


4.10.10 Revisando perfis de usuários

Se deseja ver o que os usuários estão atualmente fazendo quando entram no sistema você poderá usar o banco de dados wtmp que inclui todas as informações de login. Este arquivo pode ser processado por vários utilitários, entre eles o sac que pode enviar como saída um perfil sobre cada usuário mostrando o intervalo de tempo que eles geralmente entram no sistema.

No caso de ter a contabilização ativada, você também poderá usar as ferramentas fornecidas por ele para ser capaz de determinar quando os usuários acessam o sistema e o que eles executam.


4.10.11 Ajustando a umask dos usuários

Dependendo de sua política de usuários você pode querer alterar como as informações são compartilhadas entre os usuários, o que significa, o que cada permissão padrão permite. Esta alteração é feita definindo uma configuração apropriada de umask para todos os usuários. Você poderá alterar a configuração de UMASK no arquivos /etc/limits.conf, /etc/profile, /etc/csh.cshrc, /etc/csh.login, /etc/zshrc e provavelmente em alguns outros (dependendo do tipo de shell que tem instalado em seu sistema). De todos estes, o último executado tem preferência. A ordem é: limits.conf do PAM, o padrão de configuração do sistema para o shell do usuário, o shell do usuário(seu ~/.profile, ~/.bash_profile...)

A configuração padrão de umask no Debian é 022 isto significa que o arquivo (e diretórios) podem ser lidos e acessados pelo grupo de usuário e por outros usuários no sistema. Se isto é muito permissivo para o sistema você terá que ajustar a configuração de umask para todos os shells (e para o PAM). Não se esqueça de modificar os arquivos sob /etc/skel/ pois estes se tornarão os novos padrões do sistema quando criados pelo comando adduser.

Note, no entanto que os usuários podem modificar sua própria configuração de umask se desejarem, torná-la mais permissiva ou mais restritiva.


4.10.12 Limitando o que os usuários podem ver/acessar

FIXME: É necessário mais conteúdo. Falar das consequências de alterar as permissões de pacotes quando atualiza o sistema (e administração desta paranóia deverá ser através de chroot em seus usuários).

Se você precisa garantir acesso dos seus usuários ao sistema usando um interpretador de comandos, pense sobre isto muito cuidadosamente. Um usuário pode por padrão, a não ser que esteja em um ambiente severamente restrito (como uma jaula chroot), obter muitas informações sobre o seu sistema, incluindo:

O que um usuário pode ver em seu sistema? Provavelmente muitas coisas, tente isto (faça uma breve parada):

       find / -type f -a -perm +006 2>/dev/null  
       find / -type d -a -perm +007 2>/dev/null

A saída mostra a lista de arquivos que um usuário pode ver e os diretórios que ele tem acesso.


4.10.12.1 Limitando acesso a outras informações de usuários

Se você ainda permite acesso a shell para os usuários você deverá querer limitar que informações eles podem ver de outros usuários. Os usuários com acesso a shell têm a tendência de criar um número de arquivos dentro do seu diretório pessoal: caixas de correio, documentos pessoais, configurações de aplicativos do X/GNOME/KDE...

No Debian, cada usuário é criado com um grupo associado e nunca dois usuários pertencerão ao mesmo grupo. Este é o comportamento padrão: quando uma conta de usuário é criada, um grupo com o mesmo nome também é criado, e o usuário é adicionado a ele. Isto evita o conceito do grupo users compartilhado, que torna mais difícil aos usuários ocultarem informações de outros.

No entanto, os diretórios de usuários em $HOME são criados com permissões 0755 (lido pelo grupo e por todos). As permissões de grupo não são críticas pois somente o usuário pertence ao grupo, no entanto as permissões de todos os outros pode (ou não) ser um problema dependendo de sua política local.

Você poderá alterar este comportamento, assim a criação de usuários oferecerá uma permissão diferente em $HOME. Para alterar o comportamento para novos usuários quando forem criados, altere DIR_MODE no arquivo de configuração /etc/adduser.conf para 0750 (sem acesso de leitura para todos).

Os usuários ainda poderão compartilhar informações mas não diretamente em seus diretórios $HOME, a não ser que eles mudem suas permissões.

Note que a desativação de leitura para todos em diretórios de usuários evitará que os usuários criem suas páginas pessoais no diretório ~/public_html, pois o servidor web não será capaz de ler um componente no path - seu diretório $HOME. Se deseja permitir aos usuários publicar páginas HTML em seus diretórios ~/public_html,então altere DIR_MODE para 0751. Isto permitirá o servidor web acessar o diretório final public_html (que terá por si próprio a permissão) e oferecerá o conteúdo publicado pelos usuários. É claro, nós estamos somente falando aqui sobre uma configuração padrão; os usuários podem geralmente ajustar os modos de seus próprios arquivos completamente a seu gosto, ou você poderá manter o conteúdo que tem a intenção de publicação na web em um diretório separado que não seja um subdiretório do diretório de usuário $HOME.


4.10.13 Gerando senhas de usuários

Existem muitos casos quando um administrador precisa criar muitas contas de acesso de usuários e fornece senhas a a todas elas. É claro, o administrador poderia somente ajustar a senha para ser a mesma da conta de usuário, mas isto não seria uma atitude muito segura. Uma alternativa melhor é gerar um programa gerador de senhas. O Debian oferece os pacotes makepasswd, apg e pwgen que contém programas (o nome do programa é o mesmo do pacote) que podem ser usados para este propósito. O makepasswd gerará senhas aleatórias reais com uma ênfase em segurança até mesmo na pronunciabilidade, enquanto o pwgen tentará criar senhas pronunciáveis (é claro que isto dependerá de sua língua mãe). O apg tem algorítmos para oferecer ambos (existe uma versão cliente/servidor deste programa mas não está incluída no pacote do Debian).

O passwd não permite que uma senha seja definida de forma interativa (pois ele utiliza acesso direto a tty). Se deseja alterar senhas quando cria um grande número de usuários, você poderá criá-las usando o adduser com a opção --disabled-login e então usar o usermod ou chpasswd [17] (ambos vêm no pacote passwd assim você já os terá instalados). Se desejar usar um arquivo com todas as informações dos usuários como um processo não interativo, será melhor usar o newusers.


4.10.14 Verificando senhas de usuários

Senhas de usuários podem algumas vezes ser o ponto vulnerável na segurança de um determinado sistema. Isto é devido ao fato de que alguns usuários escolherem senhas fracas para suas contas (e quanto mais deles têm acesso ao sistema, maiores as chances disto acontecer). Até mesmo se você estabelecer checagens com o módulo cracklib do PAM e limitações de senhas como descrito em Autenticação do Usuário: PAM, Seção 4.10.1 os usuários ainda serão capazes de usar senhas simples. Pois o acesso a usuários remotos pode incluir acesso a um shell remoto (felizmente sobre ssh) tornando possível deduzir a senha mais difícil para invasores remotos. Especialmente se eles são capazes de coletar informações importantes, tais como nomes de usuários e até dos próprios arquivos passwd e shadow.

Um administrador de sistema deverá, dado um grande número de usuários, verificar se a senha que eles têm são consistentes com a política local de segurança. Como verificar? Tente quebrá-las assim como um invasor faria se ele tivesse acesso ao hash de senhas (o arquivo /etc/shadow).

Um administrador poderia usar o john ou crack (ambos crackers de senhas força bruta) juntos com um dicionário apropriado para procurar senhas de usuários e ter um plano de ação quando uma senha fraca for detectada. Você pode procurar por pacote Debian que contém lista de palavras de dicionário usando apt-cache search wordlist ou visitando os sites clássicos de pesquisas de dicionário tais como ftp://ftp.ox.ac.uk/pub/wordlists ou ftp://ftp.cerias.purdue.edu/pub/dict.


4.10.15 Logout de usuários ociosos

Usuários inativos geralmente são um risco de segurança, um usuário pode estar inativo porque saiu para comer ou porque ocorreu um problema com sua conexão remota, que não foi restabelecida. Por alguma razão, os usuários inativos podem levar a um comprometimento do sistema:

Alguns sistemas remotos podem ter sido comprometidos através de uma screen inativa (ou desconectada).

A desconexão automática de usuários idle é geralmente parte da política local de segurança que deve ser forçada. Existem várias formas de se fazer isto:

Os daemons timeoutd ou autolog são os métodos preferidos, pois, após tudo, os usuários podem alterar seu shell padrão ou podem alterar para um outro shell que não possua tais controles.


4.11 Usando os tcpwrappers

Os TCP wrappers foram desenvolvidos quando não existiam filtros de pacotes disponíveis e eram necessários controle de acesso. Mesmo assim, eles ainda são muito interessantes e úteis. Com os TCP wrappers é possível permitir ou negar um serviço para uma máquina ou domínio e definir uma regra padrão também para permitir ou negar (tudo feito a nível de aplicação). Se desejar mais informações, dê uma olhada em hosts_access(5).

Muitos dos serviços instalados no Debian são executados de duas formas:

De um lado, para serviços configurados no /etc/inetd.conf (isto inclui o telnet, ftp, netbios, swat e finger) você verá que o arquivo de configuração executa primeiro o /usr/sbin/tcpd. De outro lado, até mesmo se um serviço não for carregado pelo superdaemon inetd, o suporte a regras do tcp wrappers pode ser compilado nele. Os serviços compilados com o tcp wrappers no Debian incluem o ssh, portmap, in.talk, rpc.statd, rpc.mountd, gdm, oaf (o daemon ativador do GNOME), nessus e muitos outros.

Para ver que pacotes usam o tcpwrappers, execute:

       $ apt-cache showpkg libwrap0 | egrep '^[[:space:]]' | sort -u | \
             sed 's/,libwrap0$//;s/^[[:space:]]\+//'

Leve isto em conta quando executar o tcpdchk (um verificar de sintaxe e regras de arquivos muito útil que vem com o TCP wrappers). Quando adicionar serviços stand-alone (que são ligados diretamente com a biblioteca wrapper) nos arquivos hosts.deny e hosts.allow, o tcpdchk deverá te alertar que não é capaz de encontrar o serviço mencionado pois ele somente procura por eles no arquivo /etc/inetd.conf (a página de manual não é totalmente precisa com relação a este ponto).

Agora, vem uma pequena dica, e provavelmente o menor sistema de detecção de intrusão disponível. Em geral, você deverá ter uma política de firewall decente como primeira linha e o tcp wrappers como segunda linha de defesa. Um pequeno truque é configurar um comando SPAWN [18], no arquivo /etc/hosts.deny que envia uma mensagem para o root assim que for tentado acesso a um serviço negado:

       ALL: ALL: SPAWN ( \
         echo -e "\n\
         TCP Wrappers\: Connection refused\n\
         By\: $(uname -n)\n\
         Process\: %d (pid %p)\n\
         User\: %u\n\
         Host\: %c\n\
         Date\: $(date)\n\
       " | /usr/bin/mail -s "Conexão bloqueada para %d" root) &

Cuidado: O exemplo impresso acima é aberto a um ataque DoS fazendo muitas conexões em um curto período de tempo. Muitos e-mails significam muito I/O de arquivos pelo envio de poucos pacotes.


4.12 A importância dos logs e alertas

É fácil ver que o tratamento de mensagens de logs e alertas é um assunto importante em um sistema seguro. Suponha que um sistema está perfeitamente configurado e é 99% seguro. Se a probabilidade de 1% do ataque ocorrer e não existir medidas de segurança no lugar, para primeiro detectar e segundo disparar alarmes, o sistema não estará bem seguro.

O Debian GNU/Linux fornece algumas ferramentas que fazem análise de logs, mais notavelmente swatch, [19] logcheck ou log-analysis (todos precisarão de algumas personalizações para que coisas desnecessárias sejam removidas do relatório). Também pode ser útil, se o sistema estiver visivelmente próximo, ter as mensagens do sistema mostradas em um console virtual. Isto é útil, pois você pode (através de certa distância) ver se o sistema está se comportando adequadamente. O /etc/syslog.conf do Debian vem com uma configuração padrão comentada; para ativá-la, descomente as linhas e reinicie o syslogd (/etc/init.d/syslogd restart):

       daemon,mail.*;\
             news.=crit;news.=err;news.=notice;\
             *.=debug;*.=info;\
             *.=notice;*.=warn       /dev/tty8

Para tornar os logs coloridos, você deverá dar uma olhada nos pacotes colorize, ccze ou glark. Existe muita coisa sobre análise de logs que não poderá ser coberta aqui, assim uma boa fonte de informações pode ser o site Log Analysis. Em qualquer caso, até mesmo ferramentas automatizadas não batem a melhor ferramenta de análise: seu cérebro.


4.12.1 Usando e personalizando o logcheck

O pacote logcheck no Debian é dividido em três pacotes: logcheck (o programa principal), logcheck-database (um banco de dados de expressões regulares de um programa) e logtail (mostra linhas de logs que ainda não foram lidas). O padrão do Debian (em /etc/cron.d/logcheck) é executar o logcheck a cada hora e após reinicializações.

Esta ferramenta pode ser muito útil se personalizada adequadamente para alertar ao administrador de eventos estranhos. O Logcheck pode ser totalmente personalizado assim enviará mensagens baseadas em eventos encontrados nos logs e passíveis de atenção. A instalação padrão inclui perfis para eventos ignorados e violações de políticas para três diferentes configurações (workstation, server e paranoid). O pacote do Debian inclui um arquivo de configuração /etc/logcheck/logcheck.conf, instalado pelo programa, que define que usuário receberá as verificações. Ele também oferece um método para os pacotes que fornecem serviços para implementar novas políticas nos diretórios: /etc/logcheck/cracking.d/_packagename_, /etc/logcheck/violations.d/_packagename_, /etc/logcheck/violations.ignore.d/_packagename_, /etc/logcheck/ignore.d.paranoid/_packagename_, /etc/logcheck/ignore.d.server/_packagename_ e /etc/logcheck/ignore.d.workstation/_packagename_. No entanto, são poucos os pacotes que fazem isto. Se tiver uma política que pode ser útil para outros, por favor envie-a como relatório de falha para o pacote apropriado (como um bug wishlist). Para mais informações, leia /usr/share/doc/logcheck/README.Debian.

O melhor método de configurar o logcheck é editar seu arquivo principal de configuração /etc/logcheck/logcheck.conf após a instalação. Altere o usuário padrão (root) para quem o relatório deverá ser enviado. Você deverá ajustar o nível de relatório lá também. O pacote logcheck-database possui três níveis de relatório para aumentar o detalhamento: workstation, server e paranoid. "server" (servidor) é o nível padrão, paranoid (paranóico) é somente recomendado para máquinas de alta segurança executando poucos serviços quanto forem possíveis e workstation (estação de trabalho) para máquinas relativamente não críticas. Se desejar adicionar novos arquivos de logs, adicione-os em /etc/logcheck/logcheck.logfiles. Ele é ajustado para a instalação padrão do syslog.

Assim que isto for feito, você deverá olhar se os e-mails são enviados, durante os primeiros dias/semanas/meses. Se você achar que estão sendo enviadas mensagens que não deseja receber, apenas adicione as expressões regulares (veja regex(7) e egrep(1)) que correspondem a estas mensagens em /etc/logcheck/ignore.d.reportlevel/local. tente conferir com toda a linha de log. Detalhes sobre como escrever regras estão explicados em /usr/share/doc/logcheck-database/README.logcheck-database.gz. É um processo de ajuste fino constante; assim que as mensagens que são enviadas são sempre importantes, você deverá considerar este tunning finalizado. Note que se o logcheck não encontrar nada importante em seu sistema, ele não enviará um e-mail para você mesmo se ele for executado (assim se você obtiver somente um e-mail por semana, considere-se uma pessoa de sorte).


4.12.2 Configurando para onde os alertas são enviados

O Debian vem com uma configuração padrão do syslog (em /etc/syslog.conf) que registra mensagens em arquivos apropriados dependendo da facilidade do sistema. Você deverá estar familiarizado com isto; dê uma olhada no arquivo syslog.conf e na documentação caso não estiver registrando. Se você tem a intenção de manter um sistema seguro você deverá se atentar aonde as mensagens de log são enviadas, assim elas não passarão desapercebidas.

Por exemplo, o envio de mensagens para o console também é uma configuração interessante para muitos sistemas a nível de produção. Mas para muitos do sistemas também é importante adicionar uma nova máquina que servirá de servidor de logs (i.e. ela receberá os logs de todos os outros sistemas).

Os e-mails enviados para o root também deverão ser considerados, muitos controles de segurança (como o snort) enviam alertas para a caixa de correios do root. Esta caixa de correios normalmente aponta para o primeiro usuário criado no sistema (verifique no /etc/aliases). Tenha atenção de enviar as mensagens do root para algum lugar onde sejam lidas (ou localmente ou remotamente).

Existem outras contas e aliases em seu sistema. Em um sistema pequeno, é provavelmente o método mais simples de ter certeza que todos estes aliases apontam para a senha de root, e aquele e-mail do root é redirecionado para a caixa de mensagens pessoal do administrador do sistema.

FIXME: seria interessante em falar como um sistema Debian pode enviar/receber traps SNMP relacionado a problemas de segurança (jfs). Checar: snmptraglogd, snmp e o snmpd.


4.12.3 Usando um servidor de logs

Um servidor de logs é uma máquina que coleta dados do syslog remotamente através da rede. Se uma de suas máquinas for comprometida, o intruso não será capaz de cobrir seus rastros, a não ser que ataque também o servidor de logs. Assim, esta máquina deverá estar especialmente segura. Fazer uma máquina de loghost é simples. Apenas inicie o syslogd com a opção syslogd -r e um novo servidor de logs nasce. Para tornar isto permanentemente na Debian, edite o arquivo /etc/init.d/sysklogd e adicione a linha

       SYSLOGD=""

to

       SYSLOGD="-r"

Em seguida, configure as outras máquinas para enviar dados para o servidor de logs. Adicione uma entrada como a seguinte no arquivo /etc/syslog.conf:

       facility.level            @your_loghost

Veja a documentação sobre o que pode ser usado no lugar de facility e level (eles não devem ser usados na configuração que foi mostrada). Se quiser registrar tudo remotamente, apenas escreva:

       *.*                       @your_loghost

em seu arquivo syslog.conf. O log remoto, assim como o local, é a melhor solução (o intruso pode presumir que cobriu seus rastros após apagar os arquivos de log locais). Veja as páginas de manual syslog(3), syslogd(8) e syslog.conf(5) para informações adicionais.


4.12.4 Permissões dos arquivos de log

Não só é importante decidir como os alertas são usados, mas também quem tem acesso a leitura/modificação dos arquivos de histórico (caso não estiver usando um servidor de logs remoto). Não é difícil alterar ou desativar os alertas de segurança em um evento de intrusão. Você também deverá levar em conta que os arquivos de histórico podem revelar muitas informações sobre o sistema para um intruso caso ele tenha acesso a eles.

Algumas permissões de arquivos de log não são ideais após a instalação (mas é claro, isto depende da política de segurança local do sistema). Primeiro, os arquivos /var/log/lastlog e /var/log/faillog não precisam ser lidos por usuários normais. No arquivo lastlog você pode ver quem entrou recentemente no sistema e no arquivo faillog terá um resumo de logins que falharam. O autor recomenda fazer um chmod 660 para ambos. De uma breve olhada em seus arquivos de log e decida cuidadosamente que arquivos de logs deverão se tornar legíveis para um usuário com um UID diferente de 0 e um grupo que não sejam 'adm' ou 'root'. Você deverá facilmente verificar isto em seu sistema com:

       #  find /var/log -type f -exec ls -l {} \; | cut -c 17-35 |sort -u
       (procura que usuários os arquivos em /var/log pertencem)
       #  find /var/log -type f -exec ls -l {} \; | cut -c 26-34 |sort -u
       (procura que grupos os arquivos em /var/log pertencem)
       # find /var/log -perm +004
       (procura que arquivos são lidos por qualquer usuário)
       #  find /var/log \! -group root \! -group adm -exec ls -ld {} \;
       (procura por arquivos que não pertencem ao grupo root ou adm)

Para personalizar a forma que os arquivos de log são criados, você provavelmente terá que personalizar o programa que os gera. Se os arquivos de log forem rotacionados, no entanto, você poderá personalizar o comportamento do rotacionamento e da criação.


4.13 Adicionando patches no kernel

O Debian GNU/Linux oferece alguns dos patches para o kernel do Linux que aumentam sua segurança. Estes incluem:

FIXME: adicionar mais conteúdo, explicar como estes patches específicos podem ser instalados no Debian usando os pacotes do kernel kernel-2.x.x-patch-XXX.

FIXME: Dividir patches que se aplicam somente nos kernels 2.2, patches que se aplicam nos kernels 2.4 e os que funcionam com ambos.

No entanto, alguns patches ainda não foram adicionados ainda no Debian. Se sentir que alguns destes devem ser incluídos, por favor pergunte por ele em Work Needing and Prospective Packages. Alguns destes pacotes são:


4.14 Protegendo-se contra estouros de buffer

O estouro de buffer (buffer overflow) é o nome de um comum ataque a softwares [21] que faz o uso de checagem insuficiente de limites (um erro de programação, mais comum na linguagem C) para executar o código de máquina através de entrada de programas. Estes ataques, contra programas de servidores que escutam conexões remotamente ou contra softwares locais que garantem altos privilégios aos usuários (setuid ou setgid) podem resultar no comprometimento de qualquer sistema determinado.

Existem basicamente quatro métodos de se proteger contra estouro de buffer:

O Debian GNU/Linux em seu lançamento 3.0, fornece software para introduzir todos estes métodos exceto a proteção de compilação do código fonte (mas isto foi requisitado no Bug #213994)

Note que até mesmo se o Debian fornecer um compilador que possua proteção contra estouro de pilha/buffer, todos os pacotes precisariam ser recompilados para introduzir esta característica. Isto é, de fato, o que o Adamantix faz (entre outras características). O feito desta nova característica na estabilidade do software é algo que deverá ser determinado (alguns programas ou arquiteturas de processador podem ter problemas com seu uso).

Em qualquer caso, esteja alerta que até mesmo estas alternativas podem não prevenir buffer overflows, pois existem formas de burlá-los, como descrito na revista phrack's issue 58 ou no aviso CORE's Múltiplas vulnerabilidades nas tecnologias de proteção de pilha.


4.14.1 Patches de kernel para proteção contra estouros de buffer

Os patches do kernel relacionados a estouro de buffer incluem o patch Openwall que oferece proteção contra buffer overflows nos kernels do Linux 2.2. Para kernels 2.4 ou superiores, utilize o patch Grsecurity (existente no pacote kernel-patch-2.4-grsecurity) que inclui o patch do Openwall e muito mais características (incluindo ACLs e métodos de rede que dificultam a realização de OS fingerprinting), ou os módulos de Segurança do Linux (nos pacotes kernel-patch-2.4-lsm e kernel-patch-2.5-lsm). Para mais informações sobre como usar estes patch leia a seção Adicionando patches no kernel, Seção 4.13.


4.14.2 Proteção da Libsafe

A proteção do sistema Debian GNU/Linux com a libsafe é bastante fácil, apenas instale o pacote e diga Sim para ter a biblioteca pré carregada globalmente. Tenha cuidado, no entanto, pois isto pode quebrar alguns programas (notavelmente, programas compilados usando a antiga libc5, assim tenha certeza de ler os relatórios de falhas reportadas antes e testar os programas mais críticos em seu sistema com o programa libsafe.

Nota Importante: A proteção da Libsafe pode não ser efetiva atualmente como descrito em 173227. Considere testá-la antes de usá-la em um ambiente de produção e não dependa exclusivamente dela para proteger seu sistema.


4.14.3 Testando problemas de estouro em programas

O uso de ferramentas para detecção de estouro de buffer requer, em qualquer caso, conhecimento de programação para corrigir (e recompilar) o código. O Debian contém, por exemplo: bfbtester (um verificar de estouro de buffer que faz ataques de força bruta em binários e estouro de ambiente) e o njamd. Outros pacotes de interesse podem também ser o rats, pscan, flawfinder e o splint.


4.15 Transferência segura de arquivos

Durante a administração normal do sistema, sempre são necessárias transferências de arquivos de um sistema para outro. A cópia de arquivos de maneira segura de um sistema para outro pode ser feita usando o pacote do servidor sshd. Outra possibilidade é usar o ftpd-ssl, um servidor ftp que faz uso da Camada de Conexões Seguras para encriptar as transmissões.

Qualquer um destes métodos precisam de clientes especiais. O Debian fornece programas clientes, como scp no pacote ssh, que trabalha como o rcp mas é completamente criptografada, assim os maus meninos não poderão nem saber O QUE você copia. Também existe o pacote ftp-ssl para o servidor equivalente. Você poderá encontrar clientes para estes softwares até mesmo para outros sistemas operacionais (não-UNIX), o putty e o winscp fornecem implementações de cópia segura para qualquer versão do sistema operacional da Microsoft.

Note que o uso de scp fornece acesso dos usuários a todos os arquivos do sistema a não ser que esteja dentro de um chroot como descrito em Executando o ssh em uma jaula chroot, Seção 5.1.1. O acesso FTP pode ser feito usando chroot, possivelmente mais fácil dependendo do daemon escolhido, como descrito em Tornando o FTP mais seguro, Seção 5.3. Se está preocupado sobre usuários navegando em seus arquivos locais e deseja ter comunicação encriptada, você poderá usar um daemon FTP com suporte a SSL ou combinar ftp texto plano com uma configuração de VPN (veja Redes Privadas Virtuais (VPN), Seção 8.5).


4.16 Limitações e controle do sistema de arquivos


4.16.1 Usando quotas

É importante se ter uma boa política de quotas, pois ela evita que os usuários ocupem todo o(s) disco(s) rígido(s).

Você poderá usar dois sistemas diferentes de quota: quota do usuário e quota do grupo. Você provavelmente notará que limites de quota de usuários definem o espaço que o usuário pode utilizar, a quota de grupo é equivalente para grupos. Mantenha isto em mente quando estiver trabalhando com tamanhos de quota.

Existem alguns pontos importantes que devem ser pensados sobre a configuração de um sistema de quotas:

Cada partição ou diretório no qual os usuários tem acesso completo a gravação deverão ter a quota ativada. Calcule e defina um tamanho de quota funcional para estas partições e diretórios que combinam utilização e segurança.

Assim, você deseja usar quotas. A primeira coisa que precisa checar, é se ativou o suporte a quotas em seu kernel. Se não ativou, você terá que recompilá-lo. Após isto, verifique se o pacote quota está instalado. Caso negativo, você terá que instalá-lo.

Ativar as quotas para um respectivo sistema de arquivos é muito fácil, bastando modificar as configurações de defaults para defaults,usrquota em seu arquivo /etc/fstab. Se você precisar de quota de grupo, substitua usrquota por grpquota. Você também poderá usar ambos. Então crie os arquivos vazios quota.user e quota.group no raiz do sistema de arquivos que deseja ativar as quotas (e.g. touch /home/quota.user /home/quota.group, para um sistema de arquivos /home).

Reinicie o sistema de quota executando /etc/init.d/quota stop;/etc/init.d/quota start. Agora o sistema de quotas deverá estar funcionando e os tamanhos de quotas poderão ser definidos.

A edição de quotas de um usuário específico poderá ser feita através de edquota -u <user>. As quotas de grupos podem ser modificadas com edquota -g <group>. Então ajuste a quota soft e hard e/ou quotas de inodes se necessário.

Para mais detalhes sobre quotas, leia a página de manual do quota, e o mini-howto do quota (/usr/share/doc/HOWTO/en-html/mini/Quota.html).

Você pode ou não gostar do lshell, pois ele viola a FHS. Também tenha em mente que o pam_limits.so pode fornecer a mesma funcionalidade e lshell está atualmente orfanado


4.16.2 Os atributos específicos do sistema de arquivos ext2 (chattr/lsattr)

Em adição as permissões atuais do Unix, os sistemas de arquivos ext2 e ext3 oferecem um conjunto de atributos específicos que lhe dão mais controle sobre os arquivos em seu sistema. De forma contrária a permissões básicas, estes atributos não são mostrados com o tradicional comando ls -l ou alterados usando-se o chmod, e você precisará de dois utilitários diferentes, o lsattr e o chattr (que estão no pacote e2fsprogs) para gerênciá-los. Note que isto significa que estes atributos normalmente não serão salvos quando fizer o backup do seu sistema, assim se alterar qualquer um deles, será um tormento salvar comandos chattr sucessivos em um script que será usado depois de ter restaurado o backup.

Entre todos os atributos disponíveis, os dois abaixo são os mais importantes para aumentar a segurança e são referenciados pelas letras 'i' e 'a' e podem ser somente definidos (ou removidos) pelo superusuário:

Estes atributos também podem ser definidos para diretórios, neste caso ninguém terá o direito de modificar o conteúdo de um diretório (eg. renomear ou excluir um arquivo, ...). Quando aplicado a um diretório, o atributo incremental permite somente a criação de arquivos.

É fácil ver porque o atributo 'a' aumenta a segurança, dando a programas que não estão rodando sob o superusuário a capacidade de adicionar dados a um arquivo sem modificar seu conteúdo anterior. Por outro lado, o atributo 'i' parece ser menos interessante: depois de tudo, somente o superusuário poderá usar as permissões básicas do Unix para restringir o acesso a um arquivo, e um intruso que teria acesso a uma conta de superusuário poderia sempre usar o programa chattr para remover o atributo. Tal intruso ficara primeiramente confuso quando se ver não ser capaz de remover um arquivo, mas ele deverão não assumir que ele está blindado - acima de tudo, ele entrou no seu sistema! Alguns manuais (incluindo a versão anterior deste documento) sugerem remover os programas chattr e lsattr do sistema para aumentar a segurança, mas este tipo de estratégia, conhecida também por "segurança pela obscuridade", deve ser absolutamente evitada, pois ela fornece uma falsa sensação de segurança.

Um método de resolver isto é usar as capacidades do kernel do Linux, como descrito em Defesa pró-ativa, Seção 9.4.2.1. A capacidade de interesse aqui é chamada CAP_LINUX_IMMUTABLE: se removê-la do conjunto de capacidades (usando por exemplo,o comando lcap CAP_LINUX_IMMUTABLE) não será possível alterar qualquer atributo 'a' ou 'i' em seu sistema, até mesmo pelo superusuário! Uma estratégia completa pode ser a seguinte:

  1. Defina os atributos 'a' e 'i' nos arquivos que deseja;

  1. Execute o comando lcap CAP_LINUX_IMMUTABLE (também como lcap CAP_SYS_MODULE, como sugerido em Defesa pró-ativa, Seção 9.4.2.1) a um dos scripts de inicialização;

  1. Defina o atributo 'i' neste script e em outros arquivos de inicialização, assim também como no próprio binário lcap;

  1. Execute manualmente o comando acima (ou reinicie o seu sistema para ter certeza que tudo funciona como planejado).

Agora que a capacidade foi removida do seu sistema, um intruso não poderá alterar qualquer atributo em arquivos protegidos, e assim não poderá alterar ou excluir os arquivos. Se ele forçar a máquina a reiniciar (que é o único método de restaurar o conjunto de capacidades), ele será facilmente detectado, e a capacidade será removida novamente assim que o sistema for reiniciado. O único método de alterar um arquivo protegido seria inicializar o sistema em modo monousuário ou usar outro disco de inicialização. Duas operações que requerem acesso físico a máquina!


4.16.3 Verificando a integridade do sistema de arquivos

Você tem certeza que o /bin/login em seu disco rígido é ainda o binário que instalou alguns meses atrás? Se ele for uma versão hackeada, que armazena a senha que digitou em um arquivo oculto ou o envia por e-mails em texto plano através da Internet?

O único método que tem algum tipo de proteção é verificar seus arquivos a cada hora/dia/mês (eu prefiro diariamente) comparando o md5 do atual e do antigo. Dois arquivos nunca têm o mesmo md5sum (o digest do MD5 é de 128 bits, assim a chance de arquivos terem o mesmo md5sum é 3.4e3803), assim, você está do lado seguro aqui, a não ser que alguém tenha hackeado o algoritmo que cria md5sums em sua máquina. Isto é, bem, extremamente difícil e muito improvável. Você realmente deverá considerar esta auditoria de seus binários como muito importante, pois é um método fácil de reconhecer alterações. Ferramentas padrões usadas para isto são sXid, AIDE (Ambiente Avançado de Detecção de Intrusões), TripWire, integrit e samhain.

A instalação do debsums ajudará a verificar a integridade do sistema de arquivos, comparando o md5sum de cada arquivo com o md5sum usado no arquivo de pacotes do Debian. Tenha cuidado, estes arquivos podem ser facilmente alterados.

Você pode querer usar o locate para indexar todo o sistema de arquivos, se fizer isto, considere as implicações disto. O pacote locate no Debian é executado como usuário nobody, e assim ele somente indexa arquivos que são visíveis para todos. No entanto, se você alterar seu comportamento, você tornará todas as localizações de arquivos visíveis para todos os usuários. Se deseja indexar todo o sistema de arquivos (não os poucos que o usuário nobody pode ver) você poderá substituir o locate pelo slocate. O slocate tem a etiqueta de uma versão avançada e segura do locate da GNU, mas ele atualmente fornece funcionalidade adicional de localização de arquivos. Quando usar o slocate, o usuário somente verá os arquivos que ele tem acesso e você poderá ignorar qualquer arquivo ou diretório no sistema. O pacote slocate executa seus privilégios de atualização com altos privilégios se comparado ao locate e indexa cada arquivo. Os usuários são então capazes de localizar rapidamente cada arquivo que podem ver. O slocate não lhes permitem ver novos arquivos; ele faz a filtragem da saída baseado em sua UID.

FIXME: colocar referências ao snapshot feito após a instalação.

FIXME: Adicionar uma nota com relação a pacotes que não fornecem debsums de aplicativos instalados (não mandatário).

FIXME: Mencionar binários assinados usando digamos, bsign ou elfsign


4.16.4 Configurando verificação de setuid

O Debian oferece um trabalho do cron que é executado diariamente no arquivo /etc/cron.daily/standard. Esta tarefa do cron executará o script /usr/sbin/checksecurity que armazena informações destas alterações.

Para esta verificação ser feita, você deverá definir CHECKSECURITY_DISABLE="FALSE" no /etc/checksecurity.conf. Note que, este é o padrão, assim a não ser que tenha alterado algo, esta opção já estará definida para "FALSE".

O comportamento padrão é não enviar esta mensagem para o superusuário, mas ao invés disto manter cópias diárias das alterações em /var/log/setuid.changes. Você deverá alterar o CHECKSECURITY_EMAIL (no /etc/checksecurity.conf) para 'root' para ter estes dados enviados por e-mail para ele. Veja checksecurity(8) para mais detalhes.


4.17 Tornando o acesso a rede mais seguro

FIXME. Necessário mais conteúdo (específico o Debian)


4.17.1 Configurando características de rede do kernel

FIXME: Faltando conteúdo

Muitas características do kernel podem ser modificadas usando comandos echo no sistema de arquivos /proc ou usando o sysctl. Executando o /sbin/sysctl -A você poderá ver o que pode ser configurado e que opções existem, e elas podem ser modificadas executando /sbin/sysctl -w variável=valor (veja sysctl(8)). Somente em raros casos você precisará editar algo aqui, mas você poderá aumentar também a segurança desta forma. Por exemplo:

     net/ipv4/icmp_echo_ignore_broadcasts = 1

Este é um emulador de Windows pois ele atua como o Windows em ping broadcast caso esta opção seja ajustada para 1. Que é, requisições ICMP_ECHO enviadas para o endereço de broadcast serão ignoradas. Caso contrário, ela não faz nada.

Se quer evitar que o seu sistema responda requisições ICMP, apenas ative esta opção de configuração:

     net/ipv4/icmp_echo_ignore_all = 1

Para registrar pacotes com endereços impossíveis (devido a roteamento incorreto) em seu sistema, use:

     /proc/sys/net/ipv4/conf/all/log_martians = 1

Para mais informações sobre que coisas podem ser feitas com /proc/sys/net/ipv4/* leia /usr/src/linux/Documentation/filesystems/proc.txt. Todas as opções estão descritas através do /usr/src/linux/Documentation/networking/ip-sysctl.txt [22].


4.17.2 Configurando Syncookies

Esta opção é uma faca de dois gumes. De um lado ela protege o seu sistema contra flood de pacotes syn; por outro lado ela viola os padrões definidos (RFCs).

     net/ipv4/tcp_syncookies = 1

Se deseja alterar esta opção cada vez que o kernel estiver funcionando, você precisará alterá-la em /etc/network/options definindo syncookies=yes. Ela fará efeito sempre quando /etc/init.d/networking for executado (que é tipicamente feito durante a inicialização do sistema) enquanto o seguinte comando fará efeito imediatamente até a reinicialização:

     echo 1 > /proc/sys/net/ipv4/tcp_syncookies

Esta opção somente estará disponível caso o kernel tenha sido compilado com a opção CONFIG_SYNCOOKIES. Todos os kernels do Debian são compilados com esta opção embutida, mas você poderá verificá-la executando:

     $ sysctl -A |grep syncookies
     net/ipv4/tcp_syncookies = 1

Para mais informações sobre os syncookies TCP, leia http://cr.yp.to/syncookies.html.


4.17.3 Tornando a rede segura em tempo de inicialização

Quando definir opções de configuração do kernel para a rede, você precisará configurá-la de forma que seja carregada sempre que o sistema for iniciado. O seguinte exemplo ativa muitas das opções anteriores assim como outras opções úteis.

FIXME Ao invés de fornecer este script, fornecer uma configuração modelo para o sysctl.conf (veja: sysctl.conf(5)). Também envie isto como um bug wishlist para o pacote.

Crie um script em /etc/network/interface-secure (o nome é dado como um exemplo) e o execute do arquivo /etc/network/interfaces desta forma:

     auto eth0
     iface eth0 inet static
             address xxx.xxx.xxx.xxx
             netmask 255.255.255.xxx
             broadcast xxx.xxx.xxx.xxx
             gateway xxx.xxx.xxx.xxx
             pre-up /etc/network/interface-secure
     #!/bin/sh
     # Nome do Script: /etc/network/interface-secure
     # Modifica o comportamento padrão para tornar o sistema seguro contra
     # alguns tipos de ataques TCP/IP spoofing
     # some TCP/IP spoofing & attacks
     #
     # Contribuído por Dariusz Puchalak  
     #
     echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts 
                                                # proteção contra broadcast de ECHO
     echo 0 > /proc/sys/net/ipv4/ip_forward     # desativação de forward de ip
     echo 1 > /proc/sys/net/ipv4/tcp_syncookies # Proteção contra syn cookies ativada
     echo 1 >/proc/sys/net/ipv4/conf/all/log_martians # Registra pacotes estranhos
     # (isto inclui pacotes falsos, pacotes com a rota de origem alterada e pacotes
     redirecionados)
                              # mas tenha cuidado com isto em servidores web carregados
     echo 1 > /proc/sys/net/ipv4/ip_always_defrag 
                                                #  opção de desfragmentação sempre ativada
     echo 1 > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses 
                                                # proteção ativada contra mensagens de erro incorretas
     
     # proteção contra ip spoofing
     echo 1 > /proc/sys/net/ipv4/conf/all/rp_filter
     
     # e finalmente mais coisas:
     # Não aceita redirecionamento de ICMP
     echo 0 > /proc/sys/net/ipv4/conf/all/accept_redirects
     echo 0 > /proc/sys/net/ipv4/conf/all/send_redirects
     
     # Desativa pacotes com rota de origem
     echo 0 > /proc/sys/net/ipv4/conf/all/accept_source_route
     
     echo 1 > /proc/sys/net/ipv4/conf/all/log_martians

Você também poderá criar um script em init.d que é executado na inicialização (usando o update-rc.d para criar os links apropriados em rc.d).


4.17.4 Configurando características do firewall

Para ter capacidades de firewall, ou para proteger o sistema local ou outros atrás dele, o kernel precisa ser compilado com capacidades de firewall. O kernel padrão do Debian 2.2 (também 2.2) fornece o filtro de pacotes chamado ipchains, o Debian 3.0 usando o kernel padrão (kernel 2.4) oferece um filtro de pacotes de estado chamado iptables (netfilter). As distribuições antigas do Debian precisarão de um patch apropriado no kernel (o Debian 2.1 usa o kernel 2.0.34).

De qualquer forma, é muito fácil usar um kernel diferente do fornecido pelo Debian. Você poderá encontrar um kernel pré-compilado como pacotes que poderão facilmente instalar em seu sistema Debian. Você também poderá copiar os fontes do kernel usando os pacotes kernel-source-X e construir pacotes de kernel personalizados usando o make-kpkg.

A configuração de firewalls no Debian é discutida mais precisamente em Adicionando capacidades de firewall, Seção 5.14.


4.17.5 Desativando assuntos relacionados a weak-end de máquinas

Sistemas com mais de uma interface de rede em diferentes redes podem ter os serviços configurados de forma que escutem somente a um determinado endereço IP. Isto normalmente evita o acesso a serviços quando são requisistados através de qualquer outro endereço. No entanto, isto não significa (que foi até mesma uma concepção correta que tive) que o serviço é oferecido ao endereço de hardware (interface de rede). [23]

Isto não é um assunto relacionado a ARP e não é uma violação da RFC (isto é chamado máquina weak end na RFC1122, seção 3.3.4.2). Lembre-se, endereços IP não tem nada a ver com a interface física.

Nos kernels da série 2.2 (e anteriores) isto pode ser corrigido com:

     # echo 1 > /proc/sys/net/ipv4/conf/all/hidden
     # echo 1 > /proc/sys/net/ipv4/conf/eth0/hidden
     # echo 1 > /proc/sys/net/ipv4/conf/eth1/hidden
     .....

Em outros kernels, isto pode ser corrigido com uma das alternativas:

Junto com este texto, existirão algumas ocasiões em que será mostrado como configurar alguns serviços (servidor sshd, apache, serviço de impressão...) para tê-los escutando em um determinado endereço, o leitor deverá ter em mente que, sem as correções fornecidas aqui, a correção não evitará acesso de dentro do mesmo segmento de rede (local). [26]

FIXME: os comentários na bugtraq indicam que lá existe um método específico do Linux para escutar em uma determinada interface.

FIXME: Enviar um bug contra o netbase, assim a correção de roteamento será o comportamento padrão no Debian?


4.17.6 Protegendo-se contra ataques ARP

Quando não confia em outras máquinas na sua rede (que deve sempre ser o caso, por ser uma atitude mais segura) você deverá proteger a si mesmo de vários ataques ARP existentes.

Como deve saber, o protocolo ARP é usado para ligar endereços IP a endereços MAC. (veja RFC826 para todos os detalhes). Cada vez que enviar um pacote para um endereço IP uma resolução arp é feita (primeiro procurando no cache ARP local, então se o endereço IP não estiver presente no cache faz o broadcast de uma requisição arp) para encontrar o endereço de hardware alvo. Todos os pacotes ARP tentam deixar sua máquina ingênua fazendo-a pensar que o endereço IP da máquina B é associado com o endereço MAC da máquina do invasor. Então cada pacote que deseja enviar para o endereço IP associado com a máquina B, será enviado para a máquina do invasor.

Estes ataques (envenenamento e cache, falsificação ARP...) permitem ao invasor capturar o tráfego até mesmo em redes com switches, para facilmente roubar conexões, para desconectar qualquer máquina da rede... ataques arp são poderosos e fáceis de serem implementados, e existem diversas ferramentas, tais como arpspoof através do pacote dsniff.

No entanto, sempre existe uma solução:


4.18 Fazendo um snapshot do sistema

Antes de por o sistema em produção você deverá tirar um snapshot de todo o sistema. Este snapshot deverá ser usado em um evento de compromisso (veja Depois do comprometimento do sistema (resposta a incidentes), Capítulo 10). Você deverá refazer este upgrade assim que o sistema for atualizado, especialmente se seu upgrade for para uma novo lançamento do Debian.

Para isto você deverá usar uma mídia removível gravável que poderá ser configurada como somente-leitura, isto poderá ser feito em um disquete (proteja como somente leitura após o uso) ou uma unidade de CD-ROM (você poderá usar um CD-ROM regravável assim poderá até mesmo manter backups de md5sums em diferentes datas).

O seguinte script criará o snapshot:

     #!/bin/bash
     /bin/mount /dev/fd0 /mnt/floppy
     /bin/cp /usr/bin/md5sum /mnt/floppy
     echo "Calculando banco de dados md5"
     >/mnt/floppy/md5checksums.txt
     for dir in /bin/ /sbin/ /usr/bin/ /usr/sbin/ /lib/ /usr/lib/
     do
        find $dir -type f | xargs /usr/bin/md5sum >>/mnt/floppy/md5checksums-lib.txt
     done
     /bin/umount /dev/fd0
     echo "Pós instalação do banco de dados md5 calculada"

Note que o binário md5sum é colocado em uma unidade de disquetes assim ele poderá ser usado depois para verificar binários no sistema (como no caso de ser atacado por um trojan).

O snapshot não inclui os arquivos sob /var/lib/dpkg/info que incluem os hashs md5 de pacotes instalados (em arquivos que finalizam com .md5sums). Você poderá copiar esta informação também, no entanto você deverá saber:

Assim que o snapshot for feito você deverá se assegurar de proteger a mídia como somente leitura. Você poderá então armazená-la para backup ou colocá-la na unidade e usá-la fazendo uma verificação com o cron toda a noite comparando os md5sums originais com estes no snapshot.


4.19 Outras recomendações


4.19.1 Não use programas que dependem da svgalib

A Svgalib é muito bonita para amantes de console, como eu, mas no passado ela provou diversas vezes que é muito insegura. Foram lançadas explorações de vulnerabilidades contra o zgv e era simples se tornar usuário root. Tente evitar o uso de programas usando Svgalib sempre que possível.


[ anterior ] [ Conteúdo ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ A ] [ B ] [ C ] [ D ] [ E ] [ F ] [ G ] [ H ] [ próximo ]


Securing Debian Manual

v3.1, Mon, 10 Feb 2014 17:06:00 +0000

Javier Fernández-Sanguino Peña jfs@debian.org
Autores, Seção 1.1