[ 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 11 - Questões feitas com freqüência (FAQ)


Este capítulo introduz algumas das questões mais freqüentes da lista Debian security. Você deverá lê-las antes de postar lá ou senão as pessoas lhe dirão RTFM.


11.1 Tornando o sistema operacional Debian mais seguro


11.1.1 A Debian é mais segura que X?

Um sistema é tão seguro quanto um administrador é capaz de faze-lo. A instalação padrão dos serviços da Debian tenta ser secura, mas pode não ser paranóica como outros sistemas operacionais que instalam todos os serviços desativados por padrão. Em qualquer caso, o administrador de sistemas precisa adaptar a segurança do sistema a sua política de segurança local.

Para uma coleção de dados envolvendo vulnerabilidades de segurança de muitos sistemas operacionais, veja http://securityfocus.com/vulns/stats.shtml. Estes dados são úteis? O site lista diversos fatores a considerar quando estiver interpretando dados, e alerta que os dados não podem ser usados para comparar vulnerabilidades de um sistema operacional versus outro. [48] Também, tenha em mente que algumas das vulnerabilidades reportadas via bugs com relação a Debian, se aplicam somente ao repositório unstable (área de desenvolvimento).


11.1.1.1 A Debian é mais segura que as outras distribuições Linux (tal como Red Hat, SuSE...)?

Realmente não existem muitas diferenças entre as distribuições Linux, com exceção da instalação básica e do sistema de gerenciamento de pacotes. A maioria das distribuições compartilham muitos dos aplicativos, com a diferença básica nas versões em que estes aplicativos são oferecidos com o lançamento da distribuição estável. Por exemplo, o kernel, Bind, Apache, OpenSSH, XFree, gcc, zlib, etc. são todos idênticos entre as distribuições de Linux.

Por exemplo, a Red Hat foi infeliz e ofereceu quando 1.2.3 era a atual, que em seguida foram encontrados problemas de segurança. Na Debian, por outro lado, foi sortuda e forneceu 1.2.4 que já possui a correção da falha. Este foi o caso no grande problema do rpc.statd diversos anos atrás.

Existe muita colaboração entre os respectivos times de segurança das maiores distribuições Linux. Atualizações de segurança conhecidas são raramente, se existirem, deixadas de lado por desenvolvedores de uma distribuição. O conhecimento de uma vulnerabilidade de segurança nunca é mantida isolada do conhecimento de desenvolvedores de outra distribuição, pois as correções são normalmente coordenadas com o autor ou através do CERT. Como um resultado, as atualizações necessárias de segurança são geralmente lançadas ao mesmo tempo e a segurança relativa de diferentes distribuições são bem parecidas.

Uma das principais vantagens da Debian com relação a segurança é a facilidade de atualizações do sistema através do uso do apt. Aqui existem muitos outros aspectos da segurança na Debian a serem considerados:


11.1.2 Existem muitas falhas no sistema de tratamento de falhas da Debian. Isto significa que é muito vulnerável?

A distribuição Debian conta com um número grande e crescente de pacotes de software, provavelmente mais do que os fornecidos por muitos sistemas operacionais proprietários. Quanto mais pacotes instalados, maior o potencial de falhas de segurança em um determinado sistema.

Mais e mais pessoas estão examinando o código fonte por problemas. Existem muitos alertas relacionados com a auditoria de código fonte dos maiores componentes de software incluídos na Debian. Desta forma, tais auditorias de software mostram brechas de segurança, elas são corrigidas e um aviso é enviado para listas tal como Bugtraq.

Falhas que estão presentes na distribuição Debian normalmente também afetam outros distribuidores e vendedores. Verifique a seção "Específico da Debian: yes/no" no topo de cada aviso de segurança (DSA).


11.1.3 A Debian possui qualquer certificação relacionada a segurança?

Resposta curta: não.

Resposta longa: certificação custa dinheiro (especialmente se for uma certificação de segurança séria), ninguém dedicou seus recursos para para certificar a Debian GNU/Linux em qualquer nível de, por exemplo, Critérios comuns. Se estiver interessado em ter uma distribuição de GNU/Linux seguramente certificada, tente fornecer os recursos necessários para tornar isto possível.

Existem pelo menos duas distribuições de Linux certificadas em diferentes níveis EAL. Note que alguns dos testes CC estão sendo integrados no Linux Testing Project que está disponível na Debian através do pacote ltp.


11.1.4 Existe algum programa de fortalecimento para a Debian?

Sim. Bastille Linux, originalmente orientado para outras distribuições de Linux (Red Hat e Mandrake), atualmente funciona com a Debian. Alguns passos estão sendo feitos para integrar as alterações feitas com a versão do autor no pacote da Debian, tendo o nome de bastille.

Algumas pessoas, no entanto, acreditam que uma ferramenta de fortalecimento não elimina a necessidade de se ter uma boa administração.


11.1.5 Eu desejo executar o serviço XYZ, qual eu devo escolher?

Um dos grandes potenciais da Debian é a grande variedade de escolhas disponíveis entre pacotes que oferecem a mesma funcionalidade (servidores de DNS, servidores de e-mail, servidores ftp, servidores web, etc.). Isto pode confundir o administrador novato ao tentar determinar que pacote é o mais adequado para você. O melhor para uma determinada situação depende de um balanceamento entre suas características e necessidades de segurança. Aqui estão algumas questões que devem ser feitas a você mesmo quando decidir entre pacotes parecidos:


11.1.6 Como eu posso tornar o serviço XYZ mais seguro na Debian?

Você encontrará informações neste documento sobre como tornar alguns serviços (FTP, Bind) mais seguros na Debian GNU/Linux. Para serviços não cobertos aqui, verifique a documentação do programa, ou informações gerais sobre o Linux. Muitas das regras de segurança para sistemas Unix também se aplicam a Debian. Na maioria dos casos, o método para tornar um serviço X mais seguro na Debian é parecido com torná-lo mais seguro em qualquer outra distribuição de Linux (ou Unix, nesta importância).


11.1.7 Como posso remover todos os banners de serviços?

Se não gosta que os usuários que se conectam ao seu serviço de POP3 recebam informações sobre seu sistema (por exemplo), você pode querer remover (ou alterar) o banner que este serviço mostra para os usuários. [50] Fazer isto depende do programa que está executando para um determinado serviço. Por exemplo, no postfix, você poderá ajustar o banner SMTP no arquivo /etc/postfix/main.cf:

      
       smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)

Outros softwares não são fáceis de serem alterados. O OpenSSH precisará ser recompilado para alterar a versão que ele exibe. Tenha cuidado para não remover a primeira parte do banner (SSH-2.0), pois os clientes utilizam para identificar que protocolo é suportado por seu pacote.


11.1.8 Todos os pacotes da Debian são seguros?

O time de segurança da Debian não tem a possibilidade de analisar todos os pacotes incluídos na Debian procurando por vulnerabilidades de segurança em potencial, pois não existem recursos para auditar o código fonte de todo o projeto. No entanto, a Debian se beneficia da auditoria de código fonte feita por desenvolvedores que criam o programa.

Como um fato de importância, um desenvolvedor da Debian pode distribuir um Trojan em um pacote e não existe possibilidade de verificar isto. Até mesmo se for introduzido na estrutura da distribuição, seria impossível identificar todas as situações onde o trojan seria executado. Este é o motivo porque a Debian vem com a cláusula de licença "sem garantias".

No entanto, os usuários da Debian podem ter confiança no fato que que código estável tem uma audiência ampla e a maioria dos problemas foram descobertos durante o uso. A instalação de versões não testadas de programas em sistemas críticos é algo não recomendado (se não puder fornecer a auditoria de código necessária). Em qualquer caso, se for descoberta uma vulnerabilidade de segurança introduzida na distribuição, o processo usado para incluir pacote (usando assinaturas digitais) se certifica que o problema pode ser rastreado até o desenvolvedor. O projeto Debian não tem examinado isto levemente.


11.1.9 Porque alguns arquivos de logs/configuração tem permissão de leitura para qualquer um, isto não é inseguro?

É claro, você pode alterar as permissões padrões da Debian em seu sistema. A política atual relacionada com arquivos de log e configuração é que eles sejam lidos por todos a não ser que eles contenham informações sensíveis.

Tenha cuidado se fizer estas alterações pois:

FIXME: Verificar se isto está escrito na Política. Alguns pacotes (i.e. daemons de ftp) parecem forçar permissões diferentes.


11.1.10 Porque o /root/ (ou UsuarioX) tem permissões 755?

Como fato de importância, as mesmas questões são válidas para qualquer outro usuário. Como a instalação da Debian não coloca qualquer arquivo sob aquele diretório, não existe informações sensíveis a serem protegidas lá. Se você sentir que estas permissões são muito largas para seu sistema, considere altera-las para 750. Para os usuários, leia Limitando acesso a outras informações de usuários, Seção 4.10.12.1.

A lista de discussão Debian security thread tem mais sobre este assunto.


11.1.11 Após instalar o grsec/firewall, comecei a receber muitas mensagens de console! como removê-las?

Se estiver recebendo mensagens de console e configurou o /etc/syslog.conf para redirecioná-las ou para arquivos ou para um TTY especial, você pode ver mensagens sendo direcionadas para a console.

O nível de registro padrão do console para qualquer kernel é 7, o que significa que qualquer mensagem que tem prioridade menor aparecerá no console. Normalmente, os firewalls (a regra LOG) e algumas outras ferramentas de segurança registram eventos em uma prioridade menor que esta, e assim, são enviadas diretamente para a console.

Para reduzir as mensagens enviadas para a console, você pode usar a opção dmesg (-n, veja dmesg(8)), que examina e controla o buffer do kernel. Para alterar isto após a próxima reinicialização, altere o /etc/init.d/klogd de:

       KLOGD=""

para:

       KLOGD="-c 4"

Use um número menor para -c se estiver ainda vendo as mensagens. Uma descrição dos diferentes níveis de logs podem ser encontrados no arquivo /usr/include/sys/syslog.h:

       #define LOG_EMERG       0       /* o sistema está inutilizável */
       #define LOG_ALERT       1       /* uma ação deve ser tomada imediatamente */
       #define LOG_CRIT        2       /* condições críticas */
       #define LOG_ERR         3       /* condições de erro */
       #define LOG_WARNING     4       /* condições de alerta */
       #define LOG_NOTICE      5       /* condição normal mas significante */
       #define LOG_INFO        6       /* informativas */
       #define LOG_DEBUG       7       /* mensagens a nível de depuração */

11.1.12 Usuários e grupos do sistema operacional


11.1.12.1 Todos os usuários do sistema são necessários?

Sim e não. A Debian vem com alguns usuários pré-definidos (identificação de usuários (UID) < 99 como descritos na Debian Policy ou /usr/share/doc/base-passwd/README) para facilitar a instalação de alguns serviços que requerem que sejam executados sob um usuário/UID apropriado. Se não tem a intenção de instalar novos serviços, você pode seguramente remover estes usuários que não são donos de qualquer arquivo em seu sistema e não executam qualquer serviço. Em qualquer caso, o comportamento padrão é que UIDs de 0 a 99 são reservadas para a Debian, e UIDs de 100 a 999 são criados por pacotes na instalação (e apagados quando o pacote e suas configurações são removidos do sistema).

Para encontrar facilmente que usuários não são donos de arquivos no sistema, execute o seguinte comando (execute-o como root, pois um usuário comum pode não ter permissões suficiente para entrar através de alguns diretórios sensíveis):

       cut -f 1 -d : /etc/passwd | \
       while read i; do find / -user "$i" | grep -q . && echo "$i"; done

Estes usuários são fornecidos pelo pacote base-passwd. Olhe em sua documentação por mais informações sobre como estes usuários são manipulados pelo sistema Debian. A lista de usuários padrões (com o grupo correspondente) segue:

Outros grupos que não tem um usuário associado:


11.1.12.2 Quais são as diferenças entre os grupos adm e staff?

Componentes do grupo "adm" são geralmente administradores e neste grupo as permissões os permitem ler arquivos de log sem utilizar su. O grupo "staff" são geralmente administradores junior e de suporte, permitindo que trabalhem em /usr/local e criarem diretórios em /home.


11.1.13 Porque existe um novo grupo quando adiciono um novo usuário? (ou porque a Debian cria um novo grupo para cada usuário?)

O comportamento padrão na Debian é que cada usuário tem seu próprio e privado grupo. O esquema tradicional do UN*X coloca todos os usuários no grupo users. Grupos adicionais foram criados e usados para restringir o acesso a arquivos compartilhados associados com diferentes diretórios de projetos. O gerenciamento de arquivos se torna difícil quando apenas um usuário trabalha em múltiplos projetos, porque quando alguém cria um arquivo, ele é associado com o grupo primário do grupo que ele pertence (e.g. "users").

O método da Debian resolve este problema associando a cada usuário seu próprio grupo; assim com a máscara apropriada (0002) e o bit SETGID ajustado em um diretório determinado de projetos, o grupo correto é automaticamente designado para arquivos criados naquele diretório. Isto facilita a vida de pessoas que trabalham em múltiplos projetos, porque elas não terão que alterar os grupos e umasks quando estiverem trabalhando em arquivos compartilhados.

Você pode, no entanto, alterar este comportamento modificando o /etc/adduser.conf. Altere a variável USERGROUPS para "no", assim um novo grupo não será criado quando o novo usuário for criado. Também, altere USERS_GID para a identificação de grupo a que os usuários pertencem.


11.1.14 Questões relacionadas a serviços e portas abertas


11.1.14.1 Porque todos os serviços são ativados durante a instalação?

Esta é simplesmente uma aproximação do problema de sendo, de um lado, consciente de segurança e por outro lado amigável ao usuário. De forma contrária a OpenBSD, que desativa todos os serviços a não ser que sejam ativados pelo administrador, a Debian GNU/Linux ativa todos os serviços instalados a não ser que sejam desativados (veja Desabilitando daemons de serviço, Seção 3.6.1 para mais informações). Afinal, você instalou o serviço, não foi?

Existem muitas discussões nas listas de discussões da Debian (ambas na debian-devel e na debian-security) com relação a qual é a melhor estratégia para a instalação padrão. No entanto, no momento em que isto foi escrito (Março de 2002), ainda não existia um consenso.


11.1.14.2 Posso remover o inetd?

O Inetd não é fácil de remover pois o pacote netbase depende do pacote que o fornece (netkit-inetd). Se deseja removê-lo, você poderá ou desativá-lo (veja Desabilitando daemons de serviço, Seção 3.6.1) ou remover o pacote usando o pacote equivs.


11.1.14.3 Porque eu tenho a porta 111 aberta?

A porta 111 é usada pelo portmapper sunrpc e é instalada por padrão como parte do sistema de instalação básico da Debian, pois não existe a necessidade de saber quando o programa do usuário precisa do RPC para funcionar adequadamente. Em qualquer caso, ele é mais usado pelo NFS. Se não precisar dele, remova-o como explicado na seção Tornando serviços RPC mais seguros, Seção 5.13.

Em versões do pacote portmap maiores que a 5-5 você poderá ter o portmapper instalado mas escutando somente em localhost (modificando o /etc/default/portmap)


11.1.14.4 Para que a porta 113 (identd) é usada?

O serviço ident é um serviço de autenticação que identifica o dono de uma conexão TCP/IP para o servidor remoto que está aceitando a conexão. Tipicamente, quando um usuário se conecta ao servidor remoto, o inetd do sistema remoto envia uma requisição à porta 113 para procurar informações sobre o dono. É freqüentemente usada em servidores de e-mails, FTP e IRC, e também podem ser usadas para descobrir que usuário em seu sistema local está atacando um sistema remoto.

Existem discussões extensivas relacionadas a segurança do identd (Veja mailing list archives). Em geral, o identd é mais útil em um sistema multi-usuário que em uma estação de trabalho simples. Se não tiver um uso para ele, desative-o, assim você não estará deixando um serviço aberto para o mundo lá fora. Se decidir fazer um firewall na porta do ident, por favor use a política reject e não a deny, caso contrário uma conexão para o servidor usando o identd travará até que o tempo limite expire (veja questões relacionadas a reject ou deny).


11.1.14.5 Tenho serviços usando a porta 1 e 6, o que são e como posso removê-las?

Se executar o comando netstat -an e receber como retorno:

       Active Internet connections (servers and established)
       Proto Recv-Q Send-Q Local Address           Foreign Address         State
       PID/Program name
       raw        0      0 0.0.0.0:1               0.0.0.0:*               7
       -
       raw        0      0 0.0.0.0:6               0.0.0.0:*               7
       -

Você não está vendo processos escutando na porta TCP/UDP 1 e 6. De fato, você está vendo um processo escutando em um soquete cru pelos protocolos 1 (ICMP) e 6 (TCP). Tal comportamento é normal para Trojans e alguns sistemas de detecção de intrusão como o iipl, iplogger e portsentry. Se tiver estes pacotes simplesmente os remova. Se não tiver, tente executar a opção -p do netstat (processo) para ver que processo é dono destas portas.


11.1.14.6 Encontrei a porta XYZ aberta, posso fechá-la?

Sim, com certeza. As portas que está deixando abertas devem aderir a política individual do seu site com relação a serviços públicos disponíveis para outras redes. Verifique se estão sendo abertas pelo inetd (veja Desabilitando o inetd ou seus serviços, Seção 3.6.2) ou instalando pacotes individuais e tome as medidas apropriadas (i.e, configure o inetd, remova o pacote, evite executá-lo na inicialização).


11.1.14.7 Removendo serviços do /etc/services ajudará a tornar minha máquina mais segura?

Não o /etc/services somente oferece o mapeamento entre um nome virtual e um número dado de porta. A remoção de nomes deste arquivo (geralmente) não evitará que os serviços sejam iniciados. Alguns daemons podem não ser executados se o /etc/services for modificado mas isto não é a norma. Para desativar apropriadamente o serviço, veja Desabilitando daemons de serviço, Seção 3.6.1.


11.1.15 Assuntos comuns relacionados a segurança


11.1.15.1 Perdi minha senha e não posso acessar o sistema!

Os passos que precisa fazer para se recuperar disto depende se aplicou ou não os procedimentos necessários para limitar o acesso ao lilo e da BIOS do seu sistema.

Se limitou ambos, precisará desativar a configuração de BIOS que somente lhe permite inicializar através do disco rígido antes de prosseguir. Se tiver também perdido a senha da sua BIOS, você terá que resetar a sua BIOS abrindo o computador e removendo manualmente a bateria que mantém os dados da BIOS>

Assim que permitir a inicialização através da unidade de CD-ROM ou ativação da unidade de disquete, faça o seguinte:

Isto removerá a senha de root perdida, contida no primeiro campo separado por dois pontos após o nome do usuário. Salve o arquivo, reinicie o sistema e faça login como usuário root usando uma senha em branco. Lembre-se de adicionar uma nova senha. Isto funcionará a menos que tenha configurado o sistema de forma mais restrita, ou seja, não permitindo que usuários utilizem senhas em branco ou não permitindo o login do usuário root através do console.

Se adicionou estas características, você precisará entrar em modo monousuário. Se o LILO foi restringido, será necessário re-executar o lilo após alterar a senha de root acima. Este truque é necessário pois seu /etc/lilo.conf precisa ser mexido devido ao sistema de arquivos raíz (/) ser um disco ram e não um disco rígido real.

Assim que a restrição do LILO for removida, tente o seguinte:


11.1.16 Como posso configurar um serviço para meus usuários sem lhes dar uma conta de acesso ao shell?

Por exemplo, se você quer configurar um serviço POP, você não precisará definir uma conta para cada usuário que esteja usando. É melhor configurar uma autenticação baseada em diretório através de um serviço externo (como Radius, LDAP ou banco de dados SQL). Apenas instale a biblioteca PAM apropriada (libpam-radius-auth, libpam-ldap, libpam-pgsql ou libpam-mysql), leia a documentação (para iniciantes, veja Autenticação do Usuário: PAM, Seção 4.10.1) e configure o serviço que será ativado pelo PAM para usar o método de autenticação que escolheu. Isto é feito editando-se os arquivos sob o diretório /etc/pam.d/ para seu serviço e modificando o

      
       auth   required    pam_unix_auth.so shadow nullok use_first_pass

para, por exemplo, ldap:

       auth   required    pam_ldap.so

No caso de diretórios LDAP, alguns serviços oferecem esquemas LDAP que devem ser incluídos em seu diretório e são necessários para a utilização de autenticação LDAP. Se estiver usando um banco de dados relacional, uma dica útil é usar a cláusula where quando estiver configurando os módulos do PAM. Por exemplo, se tiver um banco de dados com os seguintes atributos na tabela:

       (user_id, user_name, realname, shell, password, UID, GID, homedir, sys, pop, imap, ftp)

Tornando os serviços campos de atributos boleanos, você poderá usa-los para permitir ou negar acesso a diferentes serviços apenas inserindo as linhas apropriadas nos seguintes arquivos:


11.2 Meu sistema é vulnerável! (Você tem certeza?)


11.2.1 O scanner de vulnerabilidade X diz que meu sistema Debian é vulnerável!

Muitos scanners de avaliação de vulnerabilidades indicarão falso positivos quando forem usados em sistemas Debian, pois podem somente usar checagem de versões para determinar se uma determinada versão de pacote é vulnerável, mas realmente não testam a vulnerabilidade de segurança propriamente dita. Pois a Debian não muda os números de versões quando corrige um pacote (muitas vezes a correção feita em versões novas são reproduzidas nas atuais), algumas ferramentas tendem a achar que um sistema Debian atualizado está vulnerável, quando não está.

Se você acha que o seu sistema está atualizado com patches de segurança, você pode querer usar as referências cruzadas com o banco de dados de vulnerabilidades publicados com os DSAs (veja Debian Security Advisories, Seção 7.2) para afastar a possibilidade de falsos positivos, se a ferramenta que estiver usando inclui referências do CVE.


11.2.2 Eu vi um ataque em meus logs de sistema. Meu sistema foi comprometido?

Um traço de ataque nem sempre significa que seu sistema foi comprometido, e você deverá fazer os passos tradicionais para determinar se o sistema está comprometido (veja Depois do comprometimento do sistema (resposta a incidentes), Capítulo 10). Também, note que o fato de ver os ataques nos logs pode significar que seu sistema está vulnerável a ele (um invasor determinado pode ter usado outras vulnerabilidades que não sejam a que você viu, no entanto).


11.2.3 Eu vi algumas linhas estranhas "MARK" em meus logs: Eu fui comprometido?

Você pode achar as seguintes linhas nos seus logs de sistema:

       Dec 30 07:33:36 debian -- MARK --
       Dec 30 07:53:36 debian -- MARK --
       Dec 30 08:13:36 debian -- MARK --

Isto não indica qualquer tipo de comprometimento e os usuários que estão mudando de versão da Debian devem achar isto estranho. Se o seu sistema não tem uma carga alta (ou muitos serviços ativos), estas linhas devem aparecer entre seus logs. Isto é uma indicação que seu daemon do syslogd está sendo executado de forma apropriada. Texto extraído da página de manual syslogd(8):

            -m intervalo
                   O syslogd registra uma marca de horário regularmente. O
                   intervalo padrão entre duas linhas -- MARK -- é de 20 minutos.
                   Isto pode ser alterado com esta opção. 
                   O intervalo de zero, desativa totalmente este recurso.

11.2.4 Encontrei usuários usando o "su" em meus logs: Eu fui comprometido?

Você pode encontrar linhas em seus logs como:

       Apr  1 09:25:01 server su[30315]: + ??? root-nobody
       Apr  1 09:25:01 server PAM_unix[30315]: (su) session opened for user nobody by (UID=0)

Não se preocupe muito. Verifique para ver se estas mensagens são devido a tarefas do cron (normalmente /etc/cron.daily/find ou logrotate):

       $ grep 25 /etc/crontab
       25 6    * * *   root    test -e /usr/sbin/anacron || run-parts --report
       /etc/cron.daily
       $ grep nobody /etc/cron.daily/*
       find:cd / && updatedb --localuser=nobody 2>/dev/null

11.2.5 Encontrei um possível "SYN flooding" em meus logs: Estou sob um ataque?

Se ver linhas como estas em seus logs:

       May 1 12:35:25 linux kernel: possible SYN flooding on port X. Sending cookies.
       May 1 12:36:25 linux kernel: possible SYN flooding on port X. Sending cookies.
       May 1 12:37:25 linux kernel: possible SYN flooding on port X. Sending cookies.
       May 1 13:43:11 linux kernel: possible SYN flooding on port X. Sending cookies.

Verifique se existe um número alto de conexões ao servidor usando o netstat, por exemplo:

       linux:~# netstat -ant | grep SYN_RECV | wc -l
          9000

Isto é uma indicação de ataque de negação de serviço (denial of service - DoS) contra a porta X do seu sistema (mais provável contra um serviço público tal como um servidor web ou servidor de e-mails). Você deverá ativar os SynCookies TCP em seu kernel, veja Configurando Syncookies, Seção 4.17.2. Note, no entanto, que um ataque DoS pode sobrecarregar sua rede até mesmo se você puder parar de fazê-lo travar seus sistemas (devido ao número de descritores de arquivos sendo reduzidos, o sistema pode parar de responder até que o tempo limite de algumas conexões se esgote). O único método efetivo de parar este ataque é contactar seu provedor de rede.


11.2.6 Encontrei seções de root estranhas em meus logs: Eu fui comprometido?

Se ver estes tipos de entradas em seu arquivo /var/log/auth.log:

       May 2 11:55:02 linux PAM_unix[1477]: (cron) session closed for user root
       May 2 11:55:02 linux PAM_unix[1476]: (cron) session closed for user root
       May 2 12:00:01 linux PAM_unix[1536]: (cron) session opened for user root by
       (UID=0)
       May 2 12:00:02 linux PAM_unix[1536]: (cron) session closed for user root

Estas são devido a uma tarefa do cron sendo executada (neste exemplo, a cada cinco minutos). Para determinar que programa é responsável por estas tarefas, verifique as tarefas nos diretórios: /etc/crontab, /etc/cron.d, /etc/crond.daily e do root crontab sob /var/spool/cron/crontabs.


11.2.7 Sofri uma invasão, o que faço?

Existem diversos passos que deve fazer no caso de uma invasão:


11.2.8 Como posso rastrear um ataque?

Olhando os logs (caso não tenham sido mexidos) usando sistemas de detecção de intrusão (veja Configure um sistema de Detecção de Intrusão, Seção 9.3), traceroute, whois e ferramentas parecidas (incluindo análise forense), você pode ser capaz de detectar um ataque até a sua origem. O método que pode reagir a esta informação depende solenemente de sua política de segurança e o que você considera um ataque. Um scan remoto é um ataque? É um teste de vulnerabilidade um ataque?


11.2.9 O programa X na Debian é vulnerável, o que fazer?

Primeiro, leve um momento para se certificar se a vulnerabilidade foi anunciada em listas de discussões de segurança públicas (como a Bugtraq) ou outros fóruns. O time da Debian Security se mantém atualizada com estas listas, assim elas também deverão ter conhecimento do problema. Não faça qualquer outra ações se você ver um anúncio em http://security.debian.org.

Caso nenhuma informação tenha sido publicada, por favor envie um e-mail sobre o(s) pacote(s) afetado(s), assim como uma descrição detalhada da vulnerabilidade (código que comprova isto também é válido) para team@security.debian.org. Isto lhe colocará em contato com o time de segurança da Debian.


11.2.10 O número de versão de um pacote indica que eu ainda estou usando uma versão vulnerável!

Ao invés de atualizar para uma versão nova, a Debian adapta as correções para a versão que é fornecida com o lançamento estável. A razão disto é para ter certeza que o lançamento estável altere o mínimo possível, assim as coisas não alterarão ou quebrarão de forma inesperada como resultado de uma correção de falha. Você pode verificar se está executando uma versão segura de pacote olhando nos logs de alterações do pacote ou comparando seu número de versão exato (versão do autor - traço- lançamento da Debian) com o número de versão indicado no aviso de segurança da Debian.


11.2.11 Programas específicos


11.2.11.1 proftpd é vulnerável ao ataque de negação de serviço.

Adicione DenyFilter \*.*/ em seu arquivo de configuração, e para mais informações veja http://www.proftpd.org/critbugs.html.


11.2.11.2 Após instalar o portsentry muitas portas são abertas

Este é simplesmente o método como o portsentry funciona. Ele abre cerca de vinte portas não usadas para tentar identificar port scans.


11.3 Questões relacionadas ao time de segurança da Debian

Esta informação foi derivada de Debian Security FAQ. Este texto inclui as informações de 19 de Novembro e oferece algumas outras questões comuns perguntadas na lista de discussão debian-security.


11.3.1 O que é um Aviso de Segurança da Debian (Debian Security Advisory - DSA)?

É a informação enviada pelo Time de segurança da Debian (veja abaixo) com relação a descoberta e correção de uma vulnerabilidade relacionada a segurança em um pacote disponível na Debian GNU/Linux. DSAs assinados são enviados à lista de discussões públicas (debian-security-announce) e postados no web site da Debian (ambos na página inicial e na área de segurança).

OS DSAs incluem informações sobre o pacote afetado, o problema de segurança descoberto e onde obter pacotes atualizados (com seus respectivos cálculos MD5).


11.3.2 As assinaturas nos avisos de segurança da Debian não são verificados corretamente!

É mais provável que este problema esteja sendo causado por algo em sua máquina. A lista debian-security-announce tem um filtro que somente permite postagem de mensagens de um dos membros do time de segurança da Debian.

É mais provável que algumas peças do software de e-mail estejam alterando as mensagens, quebrando assim a assinatura. Tenha certeza que seu programa não faça qualquer encodificação ou decodificação MIME ou conversão de tab/espaços.

Acusados conhecidos são fetchmail (com a opção mimedecode ativada), formail (somente do procmail 3.14) e o evolution.


11.3.3 Como a segurança é tratada na Debian?

Assim que o time de segurança recebe a notificação de um incidente, um dos membros revisa e considera o impacto no lançamento estável da Debian (i.e. se é vulnerável ou não). Se o seu sistema é vulnerável, nós trabalharemos para corrigir o problema. O mantenedor do pacote também é contactado, caso ele já não tenha contactado o time de segurança. Finalmente, a correção é testada e novos pacotes são preparados, que então são compilados em todas as arquiteturas estáveis e após isto feito o upload. Após isto feito, um aviso de segurança é publicado.


11.3.4 Porque vocês estão trabalhando em uma versão antiga daquele pacote?

A regra de conduta mais importante quando criar um novo pacote que corrige um problema de segurança é fazer menos alterações possíveis. Nossos usuários e desenvolvedores se preocupam com o exato comportamento de um lançamento quando é feito, assim qualquer alteração que nós fazemos, pode possivelmente tornar o programa não funcional no sistema de alguém. Isto é especialmente verdadeiro no caso de bibliotecas: tenha certeza de nunca alterar a interface de aplicação do programa (API) ou a interface de aplicação do Binário (ABI), não importa quanto pequena a alteração seja.

Isto significa que não é uma boa solução mover para uma nova versão do autor do pacote, ao invés disto as alterações importantes devem ser feitas na versão atual (backportadas). Geralmente os autores ajudam se necessário, senão o time de segurança da Debian poderá ser capaz de ajudar.

Em alguns casos não é possível adaptar uma atualização de segurança para uma versão antiga, por exemplo, quando foi necessária a alteração de uma grande quantidade de código fonte. Se isto acontecer, é necessário mover para uma nova versão do autor, mas isto deve ser coordenado de forma muito pró ativa com o time de segurança.


11.3.5 Qual é a política para um pacote corrigido aparecer em security.debian.org?

Quebras de segurança na distribuição estável garante um pacote em security.debian.org. Qualquer outra coisa não. O tamanho do comprometimento não é o problema real aqui. Normalmente o time de segurança preparará pacotes juntos com o mantenedor do pacote. Fornecendo os rastros dos testes de alguém (confiável) sobre o problema e tendo todos os pacotes necessários compilados e enviados para o time de segurança, até mesmo problemas de segurança simples farão o pacote ser enviado para security.debian.org. Por favor, veja baixo.


11.3.6 O número de versão de um pacote indica que eu ainda estou usando uma versão vulnerável!

Ao invés de atualizar para uma nova versão, nós adaptamos as correções para a versão estável que é fornecida com o lançamento estável. A razão para fazermos isto é para ter certeza que a versão estável mude o mínimo possível assim as coisas não serão alteradas ou quebrarão de forma inesperada como resultado de um problema de segurança. Você poderá verificar se está executando uma versão segura de um pacote olhando nos logs de alterações do pacote (changelog), ou comparando seu número de versão exato com o número de versão indicado no aviso de segurança da Debian (DSA).


11.3.7 Como a segurança é tratada na testing e unstable?

A resposta curta é: não é. Os lançamentos testing e unstable estão movendo rapidamente objetos e o time de segurança não possui os recursos necessários para suportá-las apropriadamente. Se desejar ter um servidor seguro (e estável) você é fortemente encorajado para permanecer usando a stable (estável). No entanto, as secretárias de segurança tentarão corrigir problemas na testing e unstable após terem sido corrigidos na stable (distribuição estável).

Em alguns casos, no entanto, o repositório unstable (instável) recebe correções de segurança de forma rápida, porque estas correções geralmente são disponibilizadas de forma rápida para o autor (outras versões, como as que estão no repositório stable, geralmente precisam ser adaptadas).


11.3.8 Eu uso uma versão antiga da Debian, ela é suportada pelo time de segurança?

Não. Infelizmente o time de segurança da Debian não pode tomar conta de ambos os lançamentos estáveis (oficialmente, também a unstable) e outros lançamentos antigos. No entanto, você poderá esperar por atualizações de segurança por um período limitado de tempo (normalmente alguns meses) imediatamente seguindo o lançamento de uma nova distribuição da Debian.


11.3.9 Porque não existem mirrors oficiais de security.debian.org?

O propósito de security.debian.org é tornar atualizações de segurança rapidamente disponíveis quanto possível. Os mirrors adicionariam uma complexidade extra que não é necessária e causariam frustração caso não estivessem sendo atualizados.


11.3.10 Eu vi o DSA 100 e DSA 102, o que aconteceu com o DSA 101?

Diversos distribuidores (a maioria de GNU/Linux, mas também de BSD e derivados) coordenam avisos de segurança para alguns incidentes e concordam em ter uma limite de tempo particular de lançamento, assim todos os distribuidores são capazes de lançar um aviso em conjunto. Isto foi decidido com a intenção de não existirem discriminações entre alguns distribuidores que precisam de mais tempo (e.g. quando o distribuidor passou pacotes através de grandes testes de qualidade ou precisa manter o suporte a diversas arquiteturas ou distribuições binários). Nosso próprio time de segurança também prepara avisos de forma pró ativa. Toda vez que estiver acontecendo, outros problemas de segurança serão analisados antes de um aviso ser lançado, e assim deixando alguns números de avisos de lado temporariamente.


11.3.11 Como posso contactar o time de segurança?

Informações de segurança podem ser enviadas para security@debian.org, que é lida por todos os desenvolvedores da Debian. Se tiver informações sensíveis, por favor use team@security.debian.org que é lida somente por membros. Caso a mensagem puder ser encriptada pela chave de contato do time de segurança da Debian (key ID 0x363CCD95 ).


11.3.12 Qual é a diferença entre security@debian.org e debian-security@lists.debian.org?

Quando envia uma mensagem para security@debian.org, ela é enviada apara a lista de discussão de desenvolvedores (debian-private). Todos os desenvolvedores da Debian estão inscritos nesta lista e as postagens são mantidas privadas (i.e. não são arquivadas no site público da internet). A lista de discussão pública, debian-security@lists.debian.org, é aberta para qualquer pessoa que deseja se inscrever e existem arquivos que podem ser pesquisados disponíveis aqui.


11.3.13 Como posso contribuir com o time de segurança da Debian?

Em todos os casos, po favor revise cada problema antes de enviá-lo para security@debian.org. Se for capaz de fornecer patches, isto aceleraria o processo. Não redirecione mensagens de listas de bugtraq, pois eles já foram recebidos. O fornecimento de informações adicionais, no entanto, é sempre uma ótima idéia.


11.3.14 quem compõe o time de segurança?

O time de segurança da Debian é composto de cinco membros e duas secretárias. O time de segurança por si mesmo recomenda pessoas para que façam parte do time.


11.3.15 O time de segurança verifica cada novo pacote que entra na Debian?

Não, o time de segurança da Debian não verifica cada pacote e não existe um método de checagem automático (lintian) para detectar novos pacotes maliciosos, pois estas tarefas são quase impossíveis de serem detectadas automaticamente. Mantenedores, no entanto, são completamente responsáveis pelos pacotes que adicionam na Debian, e todos os pacotes são primeiramente assinados por um desenvolvedor autorizado. O desenvolvedor tem a responsabilidade de analisar a segurança de todos os pacotes que ele mantém.


11.3.16 Quanto tempo a Debian levará para resolver a vulnerabilidade XXXX?

O time de segurança da Debian trabalha rapidamente para enviar avisos e produzir pacotes corrigidos para o repositório estável assim que uma vulnerabilidade é descoberta. Um relatório públicado na lista de discussão debian-security mostrou que no ano de 2001, houve uma média de 35 dias para corrigir problemas relacionados a segurança. No entanto, 50% dos problemas foram solucionados em um intervalo de 10 dias, e 15% dos problemas foram corrigidos no mesmo dia quando o aviso foi lançado.

No entanto, quando perguntam esta questão as pessoas tendem a se esquecer que:

Se quiser uma análise mais precisa do tempo que o time de segurança leva para trabalhar em vulnerabilidades, você deverá considerar que os novos DSAs (veja Debian Security Advisories, Seção 7.2) publicados no website de segurança, e os metadados usado para gerá-los, incluem links para bancos de dados de vulnerabilidades. Você poderá baixar os fontes do servidor web (a partir do CVS) ou usar as páginas HTML para determinar o tempo que a Debian levou para corrigir a vulnerabilidade e co-relacionar estes dados com bancos de dados públicos.


[ 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