<!-- CVS revision of original english document "1.6" -->
<!-- original version: 1.6 -->
<!-- last translator: gleydson@debian.org -->

<chapt>Questões feitas com freqüência (FAQ)

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

<sect>Tornando o sistema operacional Debian mais seguro

<sect1>A Debian é mais segura que X?

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

<p>Para uma coleção de dados envolvendo vulnerabilidades de segurança de muitos
sistemas operacionais, veja <url
id="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. <footnote>Neste exemplo, baseado nos 
dados da Securityfocus, pode ser visto que o Windows NT é mais seguro que o Linux, 
o que é uma afirmação questionável. Apesar de tudo, as distribuições do Linux
geralmente oferecem mais aplicações comparadas ao Windows NT da Microsoft. 
Estas situações de <em>contagem de vulnerabilidades</em> são melhor 
descritas em <url id="http://www.dwheeler.com/oss_fs_why.html#security" 
name="Why Open Source Software / Free Software (OSS/FS)? Look at the Numbers!">
por David A. Wheeler</footnote> Também, tenha em mente que algumas das 
vulnerabilidades reportadas via bugs com relação a Debian, se aplicam somente
ao repositório <em>unstable</em> (área de desenvolvimento).

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

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

<p>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 <url
id="http://www.cert.org/advisories/CA-2000-17.html" name="rpc.statd">
diversos anos atrás.

<p>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 <url
id="http://www.cert.org" name="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.

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

<list>

<item>A Debian fornece mais ferramentas de segurança que outras distribuições, 
veja <ref id="sec-tools">.

<item>A instalação padrão da Debian é pequena (menos funcionalidades),
e assim mais segura. Outras distribuições, em nome da funcionalidade, 
tem a tendência de instalarem diversos serviços por padrão e algumas 
vezes não estão corretamente configurados (lembre-se dos <url
id="http://www.sans.org/y2k/lion.htm" name="worms Ramen ou Lion">). 
A instalação da Debian não é limitada como o OpenBSD (não existem 
daemons ativos por padrão), mas tem um bom compromisso.

<footnote>Sem mencionar o fato que algumas distribuições, tal como a
Red Hat ou Mandrake, também estão permitindo que o usuário selecione
<em>perfis de segurança</em> ou usando assistentes para ajudar na 
configuração de <em>firewalls pessoais</em>.</footnote>

<item>A Debian documenta as melhores práticas de segurança em documentos
como este.

</list>

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

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

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

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

<sect1>A Debian possui qualquer certificação relacionada a segurança?

<p>Resposta curta: não. 

<p>Resposta longa: certificação custa dinheiro (especialmente se for uma
certificação de segurança <em>séria</em>), ninguém dedicou seus recursos
para para certificar a Debian GNU/Linux em qualquer nível de, por 
exemplo, 
<!-- NOTE: commoncriteria.org is no longer available, jfs -->
<url id="http://niap.nist.gov/cc-scheme/st/" name="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. 

<p>Existem pelo menos duas distribuições de Linux certificadas em diferentes
níveis 
<url id="http://en.wikipedia.org/wiki/Evaluation_Assurance_Level" name="EAL">. 
Note que alguns dos testes CC estão sendo integrados no 
<url id="http://ltp.sourceforge.net" name="Linux Testing Project"> que
está disponível na Debian através do pacote <package>ltp</package>.

<sect1>Existe algum programa de fortalecimento para a Debian?

<p>Sim. <url name="Bastille Linux"
id="http://www.bastille-unix.org">, 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 
<package>bastille</package>.

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

<sect1>Eu desejo executar o serviço XYZ, qual eu devo escolher?

<p>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:

<list>

<item>Existem um maintainer do código fonte do programa? Quando foi o último lançamento?

<item>O pacote está maduro? o número de versão realmente 
<em>não</em> mostra sua maturidade. Tente analisar o histórico de 
atualizações do software.

<item>Este programa é atormentado por falhas? Tem avisos de segurança relacionados
a ele?

<item>Este programa oferece todas as funcionalidades que precisa? ele oferece mais
do que você realmente precisa?

</list>

<sect1>Como eu posso tornar o serviço XYZ mais seguro na Debian?
<!-- Alterado para XYZ para evitar confusão :) jfs -->

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

<sect1>Como posso remover todos os banners de serviços?

<p>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. 
<footnote>Note que isto é "segurança pela obscuridade" e provavelmente este
esforço não valerá a pena em longo termo.</footnote> Fazer isto depende
do programa que está executando para um determinado serviço. Por exemplo, 
no <prgn>postfix</prgn>, você poderá ajustar o banner SMTP no arquivo
<file>/etc/postfix/main.cf</file>: 
<example> 
  smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU) 
</example>

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

<sect1>Todos os pacotes da Debian são seguros?

<p>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.
<!-- FIXME kernel-audit doesn't exist on sourceforge:
ou por outros projetos como o <url name="Linux
Projeto de Auditoria e Segurança do Kernel"
id="http://sourceforge.net/projects/kernel-audit/">, ou o <url name="Linux
Projeto de auditoria e segurança" id="http://www.lsap.org/">.
-->

<p>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 <em>"sem garantias"</em>.

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


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

<p>É 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 <em>a não ser</em> que eles contenham informações sensíveis.

<p>Tenha cuidado se fizer estas alterações pois:

<list>

<item>Alguns processos podem não ser capazes de gravar arquivos de log se restringir
suas permissões.

<item>Alguns aplicativos podem deixar de funcionar se o arquivo de configuração
que eles dependem não puder ser lido. Por exemplo, se você remover
a permissão de leitura para todos do <file>/etc/samba/smb.conf</file>, o 
<prgn>smbclient</prgn> deixará de funcionar se for executado por um
usuário normal.

</list>

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

<sect1>Porque o /root/ (ou UsuarioX) tem permissões 755?

<p>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 <em>qualquer</em> 
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 <ref id="limit-user-perm">.

<p>A lista de discussão Debian security <url
id="http://lists.debian.org/debian-devel/2000/debian-devel-200011/msg00783.html"
name= "thread"> tem mais sobre este assunto.

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

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

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

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

<example>
  KLOGD=""
</example>

<p>para:

<example>
  KLOGD="-c 4"
</example>

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

<example>
  #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 */
</example>


<sect1>Usuários e grupos do sistema operacional

<sect2>Todos os usuários do sistema são necessários?

<p>Sim e não. A Debian vem com alguns usuários pré-definidos (identificação
de usuários (UID) &lt; 99 como descritos na <url name="Debian Policy"
id="http://www.debian.org/doc/debian-policy/"> ou
<file>/usr/share/doc/base-passwd/README</file>) 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).

<p>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):

<!-- Tome a liberdade de tornar este scritp mais seguro ... >:^) // era -->
<example>
  cut -f 1 -d : /etc/passwd | \
  while read i; do find / -user "$i" | grep -q . && echo "$i"; done
</example>

<p>Estes usuários são fornecidos pelo pacote <package>base-passwd</package>. 
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:

<list>

<item>root: O root é (tipicamente) o superusuário.

<item>daemon: Alguns daemons não privilegiados que precisam gravar em 
arquivos no disco são executados como daemon.daemon (e.g., <prgn>portmap</prgn>,
<prgn>atd</prgn>, provavelmente outros). Os daemons que não precisam ser 
donos de quaisquer arquivos são executados sob nobody.nogroup e daemons mais
complexos ou com segurança em mente são executados como usuários dedicados. 
O usuário do daemon é prático para daemons instalados localmente.

<item>bin: mantido por razões históricas.

<item>sys: mesmo que bin. No entanto. /dev/vcs* e 
<file>/var/spool/cups</file> tem como donos o grupo sys.

<item>sync: O interpretador de comandos do usuário sync é <file>/bin/sync</file>. 
Assim se sua senha for ajustada para algo fácil de adivinhar (tal como ""), 
qualquer um pode fazer sync no sistema pela console, até mesmo se não 
possuir uma conta.

<item>games: Muitos jogos são SETGID para games assim eles podem gravar seus 
arquivos de pontuações. Isto é explicado na policy.

<item>man: O programa man (algumas vezes) é executado como usuário man, assim ele 
poderá gravar páginas de manuais em <file>/var/cache/man</file>

<item>lp: Usado por daemons de impressão.

<item>mail: Caixas de correios em <file>/var/mail</file> tem como dono
o grupo mail, como explicado pela policy. O usuário e grupo também são 
usados para outros propósitos por vários MTA's. 

<item>news: Vários servidores de notícias e outros programas associados (tal 
como o <prgn>suck</prgn>) utilizam usuário e grupo news de várias formas. Os
arquivos no spool de notícias tem freqüentemente como dono o usuário e 
grupo news. Os programas tais como <prgn>inews</prgn> que são usados para 
postar notícias tipicamente usam SETGID para o grupo news.

<item>uucp: O usuário e grupo uucp são usados pelo subsistema UUCP. Ele é dono
do spool e arquivos de configuração. Usuários no grupo uucp podem executar o 
uucico.


<item>proxy: Assim como o daemon, este usuário e grupo são usados por alguns
daemons (especificamente, daemons de proxy) que precisam de identificação
de usuários dedicadas para ser dono de arquivos. Por exemplo, o 
grupo proxy é usado pelo <prgn>pdnsd</prgn> e <prgn>squid</prgn> para serem 
executados como o usuário proxy.

<item>majordom: <prgn>Majordomo</prgn> tem uma UID estaticamente alocada
em sistemas Debian por razões históricas. Ele não é instalado em novos
sistemas.

<item>postgres: Os bancos de dados do <prgn>Postgresql</prgn> tem como 
dono este usuário e grupo. Todos os arquivos sob <file>/var/lib/postgresql</file> 
tem como dono este usuário para forçar segurança de forma apropriada.

<item>www-data: Alguns servidores web são executados sob www-data. O 
conteúdo web *não* deve ter como dono este usuário, ou um servidor 
web comprometido poderia ser capaz de regravar um site de internet. 
Dados gravados por servidores web, incluindo arquivos de logs, 
terão que ter como dono www-data.

<item>backup: Assim as responsabilidades de backup/restauração podem ser 
localmente delegadas para alguém sem permissões completas de usuário
root.

<item>operator: O operador é historicamente (e praticamente) a única
conta de "usuário" que pode efetuar login remotamente, e não depende
do NIS/NFS.

<item>list: Os arquivos de listas de discussões e dados tem como dono este usuário 
e grupo. Alguns programas de listas de discussões podem ser executadas também
sobe este usuário.

<item>irc: Usado por daemons de irc. É necessário um usuário alocado estaticamente
somente por causa de um bug no <prgn>ircd</prgn>, que faz SETUID()s de si mesmo
para a UID especificada na inicialização.

<item>gnats.

<item>nobody, nogroup: Daemons que não tem necessidade de serem donos de 
quaisquer arquivos são executados sob o usuário nobody e grupo
nogroup. Assim, nenhum arquivo existente no sistema devem ter como donos
este usuário ou grupo.

</list>

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

<list>

<item>adm: O grupo adm é usado para tarefas de monitoramento do sistema. Os membros
deste grupo podem ler a maioria dos arquivos de log em <file>/var/log</file> e
podem usar o xconsole. Historicamente, o <file>/var/log</file> foi
<file>/usr/adm</file> (e depois <file>/var/adm</file>), isto explica o nome
do grupo.

<item>tty: Os dispositivos TTY tem como dono este grupo. Eles são usados pelas 
ferramentas write e wall para permitir escrever para pessoas conectadas em 
outras TTYs.

<item>disk: Acesso direto a disco. Muito equivalente ao acesso root.

<item>kmem: /dev/kmem e arquivos similares são lidos por este grupo. 
Isto é mais uma relíquia do BSD, mas alguns programas que precisam
de acesso de leitura direto a memória do sistema podem fazer SETGID para
o grupo kmem.

<item>dialout: Acesso direto e completo a portas seriais. Membros deste 
grupo podem reconfigurar o modem, discar para qualquer lugar, etc.

<item>dip: O nome do grupo vem de "Dial-up IP", e membros que pertencem 
ao grupo dip podem usar ferramentas como o <prgn>ppp</prgn>, <prgn>dip</prgn>,
<prgn>wvdial</prgn>, etc. para realizar uma conexão. Os usuários neste grupo não
podem reconfigurar o modem, mas podem executar programas para fazerem 
uso dele.

<item>fax: Permite que membros usem programas de fax para ler/enviar faxes.

<item>voice: Voicemail, útil para sistemas que usam modens como secretárias
eletrônicas.

<item>cdrom: Este grupo pode ser usado localmente para dar ao grupo de usuários
acesso a unidade de CDROM.

<item>floppy: Este grupo pode ser usado localmente par dar a um grupo de usuários
acesso a unidade de disquetes.

<item>tape: Este grupo pode ser usado localmente para dar a um grupo de usuários 
acesso a uma unidade de fita.

<item>sudo: Membros dentro deste grupo não precisam digitar sua senha quando
estiverem fazendo o uso do <prgn>sudo</prgn>. Veja
<file>/usr/share/doc/sudo/OPTIONS</file>.

<item>audio: Este grupo pode ser usado localmente para dar a um grupo de 
usuários acesso a um dispositivo de audio. 

<item>src: Este grupo é dono de código fonte, incluindo arquivos em
<file>/usr/src</file>. Ele pode ser usado para dar a um usuário a 
habilidade de gerenciar código fonte do sistema.

<item>shadow: O arquivo <file>/etc/shadow</file> é lido por este grupo. Alguns 
programas que precisam ser capazes de acessar o arquivo tem SETGID ajustados
para shadow.

<item>utmp: Este grupo pode gravar para o arquivo <file>/var/run/utmp</file> e
similares. Programas que precisam se capazes de gravar para ele usam 
SETGID para utmp.

<item>video: Este grupo é usado localmente para dar a um conjunto de 
usuários permissões de acesso a dispositivos de vídeo.

<item>staff: Permite que usuários adicionem modificações locais
ao sistema
(<file>/usr/local</file>, <file>/home</file>) sem necessidade de 
privilégios de usuário root. Compare com o grupo "adm", que é 
mais relacionado a segurança/monitoramento.

<item>users: Enquanto usuários de sistemas Debian usam seus grupos privados de 
sistema por padrão (cada usuário tem seu próprio grupo), alguns preferem usar
um grupo de sistema mais tradicional, no qual cada usuário é membro de seu 
grupo.

</list>

<sect2>Quais são as diferenças entre os grupos adm e staff?

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

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

<p>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 <em>users</em>. 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").

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

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

<sect1>Questões relacionadas a serviços e portas abertas

<sect2>Porque todos os serviços são ativados durante a instalação?

<p>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 <ref id="disableserv"> 
para mais informações). Afinal, você instalou o serviço, não foi?

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

<sect2>Posso remover o <prgn>inetd</prgn>?

<p>O <prgn>Inetd</prgn> não é fácil de remover pois o 
pacote <package>netbase</package> depende do pacote que o fornece
(<package>netkit-inetd</package>). Se deseja removê-lo, você poderá 
ou desativá-lo (veja <ref id="disableserv">) ou remover o pacote
usando o pacote <package>equivs</package>.

<sect2>Porque eu tenho a porta 111 aberta?

<p>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 <ref id="rpc">.

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

<sect2>Para que a porta 113 (<prgn>identd</prgn>) é usada?

<p>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 <prgn>inetd</prgn> 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.

<p>Existem discussões extensivas relacionadas a segurança do 
<prgn>identd</prgn> (Veja <url
id="http://lists.debian.org/debian-security/2001/debian-security-200108/msg00297.html"
name="mailing list archives">). Em geral, o <prgn>identd</prgn> é 
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, <em>por favor</em> 
use a política reject e não a deny, caso contrário uma conexão
para o servidor usando o <prgn>identd</prgn> travará até que o 
tempo limite expire (veja <url
id="http://logi.cc/linux/reject_or_deny.php3" name="questões relacionadas 
a reject ou deny">).

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

<p>Se executar o comando <tt>netstat -an</tt> e receber como retorno:

<example>
  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
  -
</example>

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

<sect2>Encontrei a porta XYZ aberta, posso fechá-la?

<p>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 <prgn>inetd</prgn> (veja <ref id="inetd">) ou instalando
pacotes individuais e tome as medidas apropriadas (i.e, configure o 
inetd, remova o pacote, evite executá-lo na inicialização).

<sect2>Removendo serviços do <file>/etc/services</file> ajudará a tornar minha
máquina mais segura?

<p><em>Não</em> o <file>/etc/services</file> 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 <file>/etc/services</file> for 
modificado mas isto não é a norma. Para desativar apropriadamente o 
serviço, veja <ref id="disableserv">.


<sect1>Assuntos comuns relacionados a segurança

<sect2>Perdi minha senha e não posso acessar o sistema!

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

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

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

<list>

<item>Inicialize através de um disquete de recuperação e 
inicie o kernel

<item>Vá até o console virtual (Alt+F2)

<item>Monte o disco rígido onde o sistema de arquivos raíz (/) está

<item>Edite o arquivo <file>/etc/shadow</file> (o disquete de recuperação
da Debian 2.2 vem com o editor <prgn>ae</prgn> e a Debian 3.0 vem com o 
<prgn>nano-tiny</prgn> que é similar ao <prgn>vi</prgn>) e altere a 
linha:

<example>
  root:asdfjgl29gl0341274075:XXXX:X:XXXX:X::: (X=um número qualquer)
</example>

<p>para:

<example>
  root::XXXX:X:XXXX:X:::
</example>

</list>

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

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

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

<list>

<item>Pressione as teclas Alt, shift e Control antes do sistema terminar
o processo de inicialização, assim você terá acesso ao aviso de comandos do LILO.

<item>Digite <tt>linux single</tt>, <tt>linux init=/bin/sh</tt> ou
<tt>linux 1</tt> na linha de comandos.

<item>Isto lhe dará um aviso de comandos do shell em modo monousuário (ele perguntará
por uma senha, mas você já a conhece)

<item>Remonte sua partição raíz (/) usando o comando mount. 
<example>
  # mount -o remount,rw / 
</example>

<item>Altere a senha do usuário root com o comando <prgn>passwd</prgn> (como
você é o superusuário, o sistema não perguntará a senha anterior).

</list>

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

<p>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 (<package>libpam-radius-auth</package>,
<package>libpam-ldap</package>, <package>libpam-pgsql</package> ou
<package>libpam-mysql</package>), leia a documentação (para iniciantes,
veja <ref id="auth-pam">) 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 <file>/etc/pam.d/</file> 
para seu serviço e modificando o 
<example> 
  auth   required    pam_unix_auth.so shadow nullok use_first_pass 
</example> 
para, por exemplo, ldap: 
<example>
  auth   required    pam_ldap.so 
</example>

<!-- FIXME: verificar se isto está correto (jfs) -->

<p>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 <em>where</em> 
quando estiver configurando os módulos do PAM. Por exemplo, se 
tiver um banco de dados com os seguintes atributos na tabela:

<example>
  (user_id, user_name, realname, shell, password, UID, GID, homedir, sys, pop, imap, ftp)
</example>

<p>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:

<list>

<item><file>/etc/pam.d/imap</file>:<tt>where=imap=1</tt>.

<item><file>/etc/pam.d/qpopper</file>:<tt>where=pop=1</tt>.

<item><file>/etc/nss-mysql*.conf</file>:<tt>users.where_clause =
user.sys = 1;</tt>.

<item><file>/etc/proftpd.conf</file>:<tt> SQLWhereClause "ftp=1"</tt>.

</list>

<sect id="vulnerable-system">Meu sistema é vulnerável! (Você tem certeza?)

<sect1 id="vulnasses-false-positive">O scanner de vulnerabilidade 
X diz que meu sistema Debian é vulnerável!

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

<p>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 <ref id="dsa">) para
afastar a possibilidade de falsos positivos, se a ferramenta que 
estiver usando inclui referências do CVE.

<sect1>Eu vi um ataque em meus logs de sistema. Meu sistema foi comprometido?

<p>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 <ref id="after-compromise">). 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).

<sect1>Eu vi algumas linhas estranhas "MARK" em meus logs: Eu fui comprometido?

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

<example>
  Dec 30 07:33:36 debian -- MARK --
  Dec 30 07:53:36 debian -- MARK --
  Dec 30 08:13:36 debian -- MARK --
</example>

<p>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 
<prgn>syslogd</prgn> está sendo executado de forma apropriada. Texto
extraído da página de manual <manref
section="8" name="syslogd">:

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

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

<p>Você pode encontrar linhas em seus logs como:
<example>
  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)
</example>

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

<example>
  $ 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
</example>

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

<p>Se ver linhas como estas em seus logs:

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

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

<example>
  linux:~# netstat -ant | grep SYN_RECV | wc -l
     9000
</example>

<p>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 <ref id="tcp-syncookies">. 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.

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

<p>Se ver estes tipos de entradas em seu arquivo
<file>/var/log/auth.log</file>:

<example>
  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
</example>

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

<sect1>Sofri uma invasão, o que faço?

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

<list>

<item>Verifique se o seu sistema está atualizado com as atualizações
de segurança de vulnerabilidades publicadas. Se o seu sistema estiver
vulnerável, as chances do sistema estar de fato comprometido são maiores.
As chances crescem mais se a vulnerabilidade foi conhecida durante
algum tempo, pois normalmente existem mais atividades com relação a
vulnerabilidades antigas. Aqui está um link para <url
id="http://www.sans.org/top20/" name="As 20 maiores Vulnerabilidades de 
Segurança">.

<item>Leia este documento, especialmente a seção <ref id="after-compromise">

<item>Peça assistência. Você deverá usar a lista de discussão 
debian-security para perguntar sobre como recuperar/corrigir seu 
sistema.

<item>Notifique seu <url id="http://www.cert.org" name="CERT"> local (caso
ele exista, caso contrário você deverá considerar o contato direto com 
o CERT). Isto pode ou não ajudar você, mas, pelo menos, informará o 
CERT de ataques que estejam acontecendo. Esta informação é muito 
valiosa em determinar que ferramentas e ataques estão sendo usados
pela comunidade <em>chapéu preto</em>.

</list>

<sect1>Como posso rastrear um ataque?

<p>Olhando os logs (caso não tenham sido mexidos) usando sistemas
de detecção de intrusão (veja <ref id="intrusion-detect">),
<prgn>traceroute</prgn>, <prgn>whois</prgn> 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 <em>você</em> considera
um ataque. Um scan remoto é um ataque? É um teste de vulnerabilidade um
ataque?

<sect1>O programa X na Debian é vulnerável, o que fazer?

<p>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 <url id="http://security.debian.org">.

<p>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
<url id="mailto:team@security.debian.org" name="team@security.debian.org">.
Isto lhe colocará em contato com o time de segurança da Debian.

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

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

<sect1>Programas específicos

<sect2><package>proftpd</package> é vulnerável ao ataque de negação de 
serviço.

<p>Adicione <tt>DenyFilter \*.*/</tt> em seu arquivo de 
configuração, e para mais informações veja 
<url id="http://www.proftpd.org/critbugs.html">.

<sect2>Após instalar o <package>portsentry</package> muitas portas
são abertas

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

<sect id="debian-sec-team-faq">Questões relacionadas ao time de segurança
da Debian

<p>Esta informação foi derivada de
<url id="http://www.debian.org/security/faq" 
name="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.


<!-- FIXME: isto deve ser incluido na FAQ? -->
<sect1>O que é um Aviso de Segurança da Debian (Debian Security Advisory - DSA)?

<p>É 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 <url
id="http://www.debian.org/security/" name="área de segurança">).

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

<!-- FIXME: atualizar automaticamente da página web -->

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

<p>É mais provável que este problema esteja sendo causado por algo em sua 
máquina. A lista <url id="http://www.debian.org/security/faq" 
name="debian-security-announce"> tem um filtro que somente 
permite postagem de mensagens de um dos membros do time de segurança da 
Debian.

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

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

<sect1>Como a segurança é tratada na Debian?

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

<sect1>Porque vocês estão trabalhando em uma versão antiga daquele pacote?

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

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

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

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

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

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

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


<sect1 id="sec-unstable">Como a segurança é tratada na <tt>testing</tt> e <tt>unstable</tt>?

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

<!-- Note: os seguintes parágrafos não estão na FAQ (jfs) -->
<p>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).

<!-- A seguinte seção não está na FAQ -->
<sect1 id="sec-older">Eu uso uma versão antiga da Debian, ela é suportada pelo
time de segurança?

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

<sect1>Porque não existem mirrors oficiais de security.debian.org?

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

<sect1>Eu vi o DSA 100 e DSA 102, o que aconteceu com o DSA 101?

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

<!--
<p>Em alguns casos, o time do Debian Security prepara avisos de forma
antecipada e segura números de avisos até que o aviso possa ser lançado. 
Ocorrendo os pulos nos números de DSA.
-->

<sect1>Como posso contactar o time de segurança?

<p>Informações de segurança podem ser enviadas para
<url id="mailto:security@debian.org" name="security@debian.org">,
que é lida por todos os desenvolvedores da Debian. Se tiver informações
sensíveis, por favor use <url id="mailto:team@security.debian.org"
name="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 
<url id="http://pgpkeys.pca.dfn.de:11371/pks/lookup?search=0x363CCD95&amp;op=vindex"
name="0x363CCD95">
<!-- This old link doesn't work any more 
<url id="http://blackhole.pca.dfn.de:11371/pks/lookup?op=get&amp;exact=on&amp;search=0x363CCD95" name="0x363CCD95"> -->
). 

<sect1>Qual é a diferença entre security@debian.org e
debian-security@lists.debian.org?

<p>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 <url
id="http://www.debian.org/MailingLists/" name="inscrever"> e existem arquivos
que podem ser pesquisados disponíveis 
<url id="http://lists.debian.org/search.html" name="aqui">.

<!-- Os seguintes itens não estão incluidos na FAQ do time de segurança da
Debian -->
<sect1>Como posso contribuir com o time de segurança da Debian?
<p>
<list>

<item>Contribuindo com este documento, corrigindo parágrafos marcados com
FIXME ou fornecendo novos conteúdos. A documentação é importante e reduz a 
carga de perguntas de assuntos simples. A tradução desta documentação em
outros idiomas também é de grande ajuda.

<item>Empacotando aplicativos que são úteis para a checagem e fortalecimento
de um sistema Debian GNU/Linux. Se não for um desenvolvedor, envie uma 
<url name="falha sobre o WNPP"
id="http://www.debian.org/devel/wnpp/"> e pergunte pelo software que acha que 
poderia ser útil, mas que atualmente não é fornecido.

<item>Audite os programas na Debian ou resolva bugs de segurança e reporte
assuntos para security@debian.org. Trabalhar em outros projetos como o
<url name="Projeto de Auditoria e Segurança do Kernel do Linux"
id="http://kernel-audit.sourceforge.net/"> ou o <url name="Projeto
de Segurança e Auditoria do Linux" id="http://www.lsap.org/"> também 
aumenta a segurança da Debian GNU/Linux, pois as contribuições 
eventualmente também ajudarão aqui.

</list>

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

<sect1>quem compõe o time de segurança?

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

<sect1>O time de segurança verifica cada novo pacote que entra na Debian?

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

<sect1>Quanto tempo a Debian levará para resolver a vulnerabilidade XXXX?

<p>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 <url
id="http://lists.debian.org/debian-security/2001/debian-security-200112/msg00257.html"
name="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 
<em>mesmo dia</em> quando o aviso foi lançado.

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

<list>

<item>Os DSAs não são enviados até que:

<list>

<item>os pacotes estejam disponíveis para <em>todas</em> as arquiteturas
suportadas pela Debian (o que leva muito tempo para pacotes que são partes
do núcleo do sistema, especialmente considerando o número de arquiteturas
suportadas pelo lançamento estável).

<item>novos pacotes são constantemente testados para ter certeza que nenhuma
nova falha foi introduzida

</list>

<item>Os pacotes devem ser disponibilizados antes do DSA ser enviado (na 
queue incoming ou nos mirrors).

<item>O Debian é um projeto baseado em trabalho voluntário.

<item>A Debian é licenciada com uma cláusula "sem garantias".

</list>

<p>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 <ref id="dsa">) publicados no <url
id="http://security.debian.org" name="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 <url id="http://cvs.debian.org" name="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.
