<!-- CVS revision of original english document "1.17" -->
<!-- original version: 1.17 -->
<!-- last translator: gleydson@debian.org -->
<!-- last revisor: philipe@debian-ba.org -->
<!-- last line: 2531 -->

<chapt>Após a instalação

<p>Assim que o sistema for instalado, você ainda poderá fazer mais para deixá-lo
mais seguro;
alguns dos passos descritos neste capítulo podem ser seguidos. É claro que isto
depende de sua configuração, mas para prevenção de acesso físico 
você deverá ler <ref id="bios-boot">,<ref id="lilo-passwd">,<ref
id="kernel-root-prompt">, <ref id="floppy-boot">, <ref
id="restrict-console-login"> e <ref id="restrict-reboots">.

<p>Antes de se conectar a qualquer rede, especificamente se for uma 
rede pública, no mínimo execute uma atualização de segurança (veja
<ref id="security-update">). Opcionalmente, você deverá fazer um snapshot
do seu sistema (veja <ref id="snapshot">).

<sect id="debian-sec-announce">Inscreva-se na lista de discussão "Anúncios de Segurança do Debian"

<p>Para receber informações sobre atualizações e alertas de segurança (DSAs) disponíveis 
e DSAs você deverá se inscrever na lista de discussão debian-security-announce. Veja <ref
id="debian-sec-team"> para mais informações sobre como o time de segurança
do Debian funciona. Para mais informações sobre como se inscrever nas 
listas de discussões do Debian, leia <url id="http://lists.debian.org">.

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

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

<p>FIXME: também adicionar a chave aqui?

<sect id="security-update">Executar uma atualização de segurança

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

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

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

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

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

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

<p>Assim que instalar isto, você poderá usar ou o <package>apt</package> ou
<package>dselect</package> para atualizar:

<list>
<item>Se quiser usar o <package>apt</package> simplesmente execute (como root):
<example>
# apt-get update
# apt-get upgrade
</example>
<item>Se quiser usar o <package>dselect</package> então primeiro execute o [U]pdate,
então [I]nstall e depois, finalmente, [C]onfigure pata instalar/atualizar os 
pacotes.
</list>

<p>Se quiser, você também poderá adicionar linhas deb-src ao seu arquivo
<file>/etc/apt/sources.list</file>. Veja
<manref name="apt" section="8"> para mais detalhes.

<p>Nota: Você <em>não</em> precisa adicionar a seguinte linha:

<example>
  deb http://security.debian.org/debian-non-US stable/non-US main contrib non-free
</example>
<p>isto é porque security.debian.org é hospedado em uma localização 
fora dos Estados Unidos e não possui um arquivo separado non-US.

<sect id="bios-boot">Altere a BIOS (de novo)

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

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

<sect id="lilo-passwd">Configurar a senha do LILO ou GRUB
<p>
Qualquer um pode facilmente obter uma linha de comando de root e alterar 
sua senha entrando com o parâmetro <tt>&lt;name-of-your-bootimage&gt; init=/bin/sh</tt> no aviso de boot. Após alterar a senha e reiniciar o sistema, a pessoa
terá acesso ilimitado como usuário root e poderá fazer qualquer coisa que 
quiser no sistema. Após este processo, você não terá acesso root ao seu 
sistema, já que não saberá mais sua senha.
<p>
Para se assegurar que isto não ocorra, você deverá definir uma senha
para o gerenciador de partida. Escolha entre uma senha global ou uma
senha para determinada imagem.
<p>
Para o LILO, você precisará editar o arquivo de configuração 
<file>/etc/lilo.conf</file> e adicionar uma linha <tt>password</tt> e 
<tt>restricted</tt> como no exemplo abaixo.

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

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

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

<example>
  timeout 3
  password mude-me
</example>

<p>Para fortalecer futuramente a integridade da senha, você poderá armazenar a 
senha em um formato criptografado. O utilitário <prgn>grub-md5-crypt</prgn> 
gera um hash de senha que é compatível com o algoritmo de senha encriptada 
pelo grub (md5).
Para especificar no <prgn>grub</prgn> que uma senha no formato md5 será usada, use 
a seguinte diretiva:
<example>
  timeout 3
  password --md5 $1$bw0ez$tljnxxKLfMzmnDVaQWgjP0
</example>

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

<sect id="kernel-root-prompt">Remover o aviso de root do kernel

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

<p>Para remover este comportamento, você precisará alterar o 
<file>/etc/mkinitrd/mkinitrd.conf</file> e definir:
<example>
  # DELAY  O número de segundos que o script linuxrc deverá aguardar para
  # permitir ao usuário interrompe-lo antes do sistema ser iniciado
  DELAY=0
</example>
<p>Então gere novamente sua imagem do disco ram. Um exemplo de como fazer isto:
<example>
  # cd /boot
  # mkinitrd -o initrd.img-2.4.18-k7 /lib/modules/2.4.18-k7
</example>
<p>ou (preferido):
<example>
  # dpkg-reconfigure -plow kernel-image-2.4.x-yz
</example>
<!-- Informação desatualizada. Já estamos na versão 2.6 -->
<p>Note que o Debian 3.0 woody permite aos usuários instalarem 
o kernel 2.4 (selecionando <em>tipos de kernels</em>), <em>no entanto</em> 
o kernel padrão é o 2.2 (salvo para algumas arquitetura no qual o kernel
2.2 ainda não foi portado). Se você acha que isto é um bug, veja
<url id="http://bugs.debian.org/145244" name="Bug 145244"> antes de reporta-lo.


<sect id="floppy-boot">Desativando a inicialização através de disquetes
<p>
O MBR padrão no Debian antes da versão 2.2 não atua como setor mestre
de partida como recomendado e deixa aberto um método de se fazer a quebra
do sistema:

<list>
<item>Pressione shift durante a inicialização, e um aviso MBR aparecerá

<item>Então aperte F e o sistema inicializará pelo disquete. Isto pode ser usado
para se obter acesso root ao sistema.
</list>

<p>Este comportamento pode ser alterado com:

<example>
  lilo -b /dev/hda
</example>

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

<example>
  install-mbr -i n /dev/hda
</example>

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

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


<sect id="restrict-console-login">Restringindo o acesso de login no console

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

<list>

<item><file>login.defs</file>, editando a variável CONSOLE que define 
um arquivo ou lista de terminais nos quais o login do root é permitido

<item><file>securetty</file> 
<footnote>
O arquivo <file>/etc/securetty</file> é um arquivo de configuração que 
pertence ao pacote <package>login</package>.
</footnote>
adicionando/removendo os terminais nos quais o root tem permissão de acesso. 
Se você deseja permitir somente acesso a console local
então você precisa por <em>console</em>, <em>ttyX</em> 
<footnote>
Ou <em>ttyvX</em> no GNU/FreeBSD, e <em>ttyE0</em> no GNU/NetBSD.
</footnote>
e <em>vc/X</em> (se estiver usando dispositivos <em>devfs</em>), você pode
querer adicionar também <em>ttySX</em> 
<footnote>
Ou <em>comX</em> no GNU/Hurd, <em>cuaaX</em> no GNU/FreeBSD, 
e <em>ttyXX</em> no GNU/KNetBSD.
</footnote>
se estiver usando um console serial para 
acesso local (onde X é um inteiro, você pode querer ter múltiplas
instâncias 
<footnote>
A configuração padrão na <em>woody</em> incluem 12 tty e consoles vc
locais. Na <em>sarge</em> a configuração padrão oferece 64 consoles 
para consoles tty e vc. Você pode remover seguramente isto se não estiver 
usando mais do que estas consoles.
</footnote>
dependendo do nível de consoles virtuais que tem ativado no 
<file>/etc/inittab</file>
<footnote>Procure pelas chamadas <em>getty</em>.</footnote>). Para
mais informações sobre dispositivos de terminais, leia o 
<url id="http://tldp.org/HOWTO/Text-Terminal-HOWTO-6.html" name="Text-Terminal-HOWTO">

</list>

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

<example>
  auth       required   pam_unix.so nullok
</example>

<sect id="restrict-reboots">Restringindo reinicializações do sistema através da console

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

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

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

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

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

<p>
Observe as diferenças na seção opções. A opção <tt>nosuid</tt> 
ignore os bits setuid e setgid completamente, enquanto a
<tt>noexec</tt> proíbe a execução de qualquer programa naquele 
ponto de montagem, e a <tt>nodev</tt> ignora dispositivos. Isto
soa muito bem, mas elas:
<list>
<item>somente se aplicam a sistemas de arquivos ext2
<item>podem ser burlados facilmente
</list>

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

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

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

<p>Esteja já avisado que muitos scripts dependem de <file>/tmp</file> sendo 
executável. Mais notavelmente, o Debconf tem (ainda?) alguns problemas
relacionados a isto, para mais informações veja o bug <url
id="http://bugs.debian.org/116448" name="116448">.

<p>
A parte a seguir é mais um tipo de exemplo. Uma nota, no entanto:
<file>/var</file> pode ser ajustado para noexec, mas alguns programas
<footnote>Alguns destes incluem o gerenciador de pacotes <package>dpkg</package>
pois os scripts de instalação (post,pre) e remoção (post,pre) estão em 
<file>/var/lib/dpkg/</file> e também o Smartlist</footnote>
mantém seus programas sob <file>/var</file>. 
O mesmo se aplica a opção nosuid.

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

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

<!-- Esta é uma parte duplicada do exemplo de alguns parágrafos acima -->
<p>Com relação a noexec, esteja alertado que ela pode não oferecer tanta 
segurança assim. Considere este exemplo:
<example>
  $ cp /bin/date /tmp
  $ /tmp/date
  (does not execute due to noexec)
  $/lib/ld-linux.so.2 /tmp/date
  (funciona, pois o comando date não é executado diretamente)
</example>

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

<p>Para fazer isto, modifique o <file>/etc/apt/apt.conf</file> e adicione:
<example>
  DPkg
  {
      Pre-Invoke  { "mount /usr -o remount,rw" };
      Post-Invoke { "mount /usr -o remount,ro" };
  };
</example>

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

<p>Interrompa ou reinicie estes programas e execute manualmente o Post-Invoke.
<em>Cuidado!</em>  Isto significa que você provavelmente precisará 
reiniciar sua seção do X (se estiver executando uma) cada vez que fizer uma
grande atualização em seu sistema. Você deverá levar em conta se um 
sistema de arquivos <file>/usr</file> somente-leitura é adequado ao 
seu sistema. Veja também isto <url id="http://lists.debian.org/debian-devel/2001/11/threads.html#00212"
name="discussion on debian-devel about read-only /usr">.

<sect>Fornecendo acesso seguro ao usuário

<sect1 id="auth-pam">Autenticação do Usuário: PAM

<p>

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


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

<list>
<item>que método é usada para autenticação.
<item>que método é usada para sessões.
<item>como a checagem de senha se comportará.
</list>

<p>
A seguinte descrição está longe de ser completa, para mais informações
você deve ler o  <url
id="http://www.kernel.org/pub/linux/libs/pam/Linux-PAM-html/pam.html"
name="Guia do Administrador de Sistemas Linux-PAM"> (presente no <url
id="http://www.kernel.org/pub/linux/libs/pam/" name="site primário de 
distribuição do PAM">). Este documento também pode ser encontrado no 
pacote do Debian <package>libpam-doc</package>.

<p>O PAM lhe oferece a possibilidade de utilizar vários passos de autenticação
de uma só vez, sem o conhecimento do usuário. Você pode autenticar em um 
banco de dados Berkeley e no banco de dados no arquivo <file>passwd</file> 
padrão, e o usuário somente entrará no sistema caso ele se autentique 
corretamente em ambos. Você pode restringir muita coisa com o PAM, como 
também abrir bastante as portas do seu sistema. Assim, seja cauteloso. 
Uma linha de configuração típica que tem o tempo de controle como seu segundo
elemento:
<!-- Second in mine (old Debian v2.0 though), check this! (FIXME) (era) -->
Geralmente ele deve ser ajustado para <tt>requisite</tt>, que retorna
uma falha de login caso um dos módulos falhe.
<!-- Lots of fields in mine are "required", please elaborate? (FIXME) (era) -->

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

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


<p>Assim, o que este encanto faz? A primeira linha carrega o módulo
cracklib do PAM, que fornece checagem de senhas fracas, pergunta 
por uma nova senha com no mínimo de 12 caracteres, uma diferença de pelo 
menos 3 letras da antiga senha e permite 3 novas tentativas. O Cracklib 
depende do pacote wordlist (tal como
<package>wenglish</package>, <package>wspanish</package>, 
<package>wbritish</package>, ...), assim tenha certeza de instalar um que
seja apropriado a seu idioma ou o cracklib pode não ser totalmente útil.
<footnote>
Esta dependência não foi corrigida, no pacote do Debian 3.0. Por favor
veja <url id="http://bugs.debian.org/112965" name="Bug #112965">.
</footnote>
A segunda linha introduz o módulo de autenticação padrão
com senhas MD5 e permite uma senha de tamanho zero. A diretiva
<tt>use_authtok</tt> é necessária para pegar a senha do módulo anterior. 

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

<example>
  auth     requisite  pam_securetty.so
</example>

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

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

<example>
  session  required   pam_limits.so
</example>

<p>Isto restringe os recursos do sistema que os usuários têm permissão (veja
abaixo em <ref id="user-limits"> ). Por exemplo, você pode restringir o 
número de logins concorrentes (de um determinado grupo de usuários, ou 
de todo o sistema), número de processos, tamanho de memória, etc.

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

<example>
  password   required   pam_unix.so nullok obscure min=6 max=11 md5
</example>

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

<example>
  auth        requisite   pam_wheel.so group=wheel debug
</example>

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

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

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

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

<example>
  auth     required       pam_securetty.so
  auth     required       pam_unix_auth.so
  auth     required       pam_warn.so
  auth     required       pam_deny.so
  account  required       pam_unix_acct.so
  account  required       pam_warn.so
  account  required       pam_deny.so
  password required       pam_unix_passwd.so
  password required       pam_warn.so
  password required       pam_deny.so
  session  required       pam_unix_session.so
  session  required       pam_warn.so
  session  required       pam_deny.so
</example>

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


<sect1 id="user-limits">Limitando o uso de recursos: o arquivo <file>limits.conf</file>

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

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

<p>Mais detalhes podem ser lidos em:
<list>

<item><url
id="http://www.samag.com/documents/s=1161/sam0009a/0009a.htm"
name="artigo de configuração do PAM">.

<item> <url
id="http://seifried.org/security/os/linux/20020324-securing-linux-step-by-step.html"
name="Tornando o Linux mais seguro passo a passo"> na seção <em>Limitando
a visão dos usuários</em>.

<item><url id="http://seifried.org/lasg/users/" name="LASG"> na seção
<em>Limitando e monitorando usuários</em>.

</list>

<p>FIXME: Colocar um belo <file>limits.conf</file> acima deste local

<sect1>Ações de login do usuário: edite o <file>/etc/login.defs</file>
<p>
O próximo passo é editar a configuração e ação básica que será feita 
após o login do usuário. Note que este arquivo não é parte da 
configuração do PAM, é um arquivo de configuração lido pelos programas 
<tt>login</tt> e <tt>su</tt>, assim não faz sentido configurá-lo para 
casos onde nem um dos programas são indiretamente chamados (o 
programa <prgn>getty</prgn> que é executado através do console e requer
login e senha, <em>executa</em> o <prgn>login</prgn>).

<example>
  FAIL_DELAY          10
</example>

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

<example>
  FAILLOG_ENAB        yes
</example>

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

<example>
  LOG_UNKFAIL_ENAB    yes
</example>

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

<example>
  SYSLOG_SU_ENAB      yes
</example>

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

<example>
  SYSLOG_SG_ENAB      yes
</example>

<p>O mesmo que <var>SYSLOG_SU_ENAB</var> mas se aplica ao programa <prgn>sg</prgn>.

<example>
  MD5_CRYPT_ENAB      yes
</example>

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

<example>
  PASS_MAX_LEN        50
</example>

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

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

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

<sect1>Usando su

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


<sect1>Usando o sudo

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

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

<p>Você precisará adicionar a seguinte linha no arquivo
<file>/etc/security/access.conf</file>, o arquivo padrão de 
configuração do Debian tem a linha de exemplo comentada:
<example>
   -:wheel:ALL EXCEPT LOCAL
</example>

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


<sect1 id="user-restrict">Restringindo acessos de usuários

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

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

<p>O Debian atualmente fornece em sua versão instável (e poderá ser 
incluída em uma futura versão estável) do módulo <file>pam_chroot</file> (no
pacote <package>libpam-chroot</package>). Uma alternativa a ele é o 
<prgn>chroot</prgn> o serviço que fornece log remoto (<prgn>ssh</prgn>, <prgn>telnet</prgn>).<footnote><package>Libpam-chroot</package> ainda
não foi ainda testado, ele funciona com o <prgn>login</prgn> mas ele
não é fácil de ser configurado para funcionar com outros programas</footnote>

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

<p>Informações sobre como fazer <prgn>chroot</prgn> dos usuários 
acessando o sistema através do <prgn>ssh</prgn> é descrito em <ref
id="chroot-ssh-env">.

<sect1>Auditoria do usuário

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

<sect2>Auditoria de entrada e saída com o script

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

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

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

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

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

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

<sect2>Usando o arquivo de histórico do interpretador de comandos

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

<p>Por exemplo, para o bash, o <file>/etc/profile</file> 
deverá ser ajustado da seguinte forma
<footnote>
A definição de HISTSIZE para um número elevado poderá causar problemas
em algumas circunstâncias, pois o histórico é mantido em memória para cada
sessão do usuário. Você estará mais seguro caso defina esta variável para um 
valor suficientemente grande e realizar o backup de arquivos de histórico 
de usuários (se precisar do histórico de todos os usuários por 
alguma razão).
</footnote>
:

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

<p>Para isto funcionar, o usuário poderá somente adicionar 
dados ao <file>.bash_history</file>. Você <em>também</em> 
precisará ajustar a opção <em>append-only</em> usando o 
programa <prgn>chattr</prgn> para o <file>.bash_history</file> 
de todos os usuários.
<footnote>
Sem a opção append-only, os usuários poderão ser capazes de 
apagar o conteúdo do arquivo de histórico executando
<tt> > .bash_history</tt>
</footnote>.

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

<sect2>Auditoria completa do usuário com ferramentas de contabilização

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

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

<sect2>Outros métodos de auditoria do usuário
<p>
Se você for completamente paranóico e deseja auditar cada comando do usuário, 
você deverá pegar o código fonte do <prgn>bash</prgn>, editá-lo e assim
ter ele enviando tudo o que o usuário digitar para outro arquivo. Ou 
ter o pacote <package>ttysnoop</package> monitorando constantemente qualquer
novo ttys <footnote>Ttys são criados para logins locais e logins remotos 
durante seções do ssh e telnet</footnote>
e gravar sua saída para um arquivo. Outro programa útil é o 
<package>snoopy</package> 
(veja também  <url id="http://sourceforge.net/projects/snoopylogger/" name="the project page">)
que é um programa transparente ao usuário que trabalha em cima de uma 
biblioteca fornecendo um gancho nas chamadas <var>execve()</var>, qualquer
comando executado é registrado no <prgn>syslogd</prgn> usando a 
facilidade <tt>authpriv</tt> (normalmente armazenada em 
<file>/var/log/auth.log</file>).

<sect1>Revisando perfis de usuários

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

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

<sect1>Ajustando a umask dos usuários

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

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

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

<sect1>Limitando o que os usuários podem ver/acessar

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

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

<list>

<item>alguns arquivos de configuração em <file>/etc</file>. No 
entanto, as permissões padrões do Debian para alguns arquivos
sensíveis (que podem conter senhas, por exemplo), não terão acesso
devido a informações críticas. Para ver que arquivos são somente
acessíveis pelo usuário root, por exemplo, execute como superusuário
o comando <tt>find /etc -type f -a -perm 600 -a -uid 0</tt>.

<item>você instalou pacote, ou vendo no banco de dados de pacotes, ou 
no diretório <file>/usr/share/doc</file> ou adivinhando olhando 
nos binários e bibliotecas instalados em seu sistema.

<item>alguns arquivos de registro em <file>/var/log</file>. Também note
que alguns arquivos de registro somente são acessíveis aos usuários
root e grupo <tt>adm</tt> (tente executar 
<tt>find /var/log -type f -a -perm 640</tt>) e alguns são somente
disponíveis ao usuário root (tente executar <tt>find /var/log -type f -a -perm
600 -a -uid 0</tt>).

</list>


<p>O que um usuário pode ver em seu sistema? Provavelmente muitas coisas, 
tente isto (faça uma breve parada):
<example>
  find / -type f -a -perm +006 2>/dev/null  
  find / -type d -a -perm +007 2>/dev/null  
</example>

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

<sect2 id="limit-user-perm">Limitando acesso a outras
informações de usuários

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

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

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

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

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

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

<sect1 id="user-pwgen">Gerando senhas de usuários

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

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

<sect1>Verificando senhas de usuários

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

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

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


<sect1 id="idle-logoff">Logout de usuários ociosos

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

<list>
<item>porque o console do usuário pode ser destravado e pode ser acessado por
um intruso.  

<item>porque um intruso pode ser capaz de reconectar a si mesmo a uma 
conexão de rede fechada e enviar comandos ao shell remoto (isto é muito fácil
de ser feito caso o shell remoto não seja criptografado como no caso 
do <prgn>telnet</prgn>).
</list>

<p>Alguns sistemas remotos podem ter sido comprometidos através de 
uma <prgn>screen</prgn> inativa (ou desconectada).

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

<list>
<item>Caso o interpretador de comandos do usuário seja o <prgn>bash</prgn>, 
o administrador do sistema poderá definir um valor para a variável 
<tt>TMOUT</tt> (veja <manref section="1" name="bash">) que fará o 
shell deslogar os usuários inativos automaticamente. Note que ela 
deverá ser definida com a opção <tt>-o</tt> ou os usuários serão 
capazes de alterá-la (ou desativá-la).

<item>Instale o <package>timeoutd</package> e configure
<file>/etc/timeouts</file> de acordo com sua política de segurança
local. O daemon observará usuários inativos e respectivamente 
fará o logout de suas seções.
<!-- FIXME : o 'screen' não permite que o timeoutd detecte 
tempo ocioso como eu penso que faz, ou foi por causa de meus 
testes com o ttysnoop -->

<item>Instale o <package>autolog</package> e o configure para remover usuários inativos.

</list>

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


<sect id="tcpwrappers">Usando os tcpwrappers 

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

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

<list>
<item>carregados através do serviço tcpwrappers (<file>tcpd</file>)
<item>compilados com o suporte a libwrapper embutido
</list>

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

<p>Para ver que pacotes usam o tcpwrappers, execute:

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


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

<p>Agora, vem uma pequena dica, e provavelmente o menor 
sistema de detecção de intrusão disponível. Em geral, você deverá ter uma
política de firewall decente como primeira linha e o tcp wrappers como segunda
linha de defesa. Um pequeno truque é configurar um comando <var>SPAWN</var> 
<footnote>tenha certeza de usar maiúsculas, pois <em>spawn</em> não 
executará fork</footnote>, no arquivo
<file>/etc/hosts.deny</file> que envia uma mensagem para o root assim que 
for tentado acesso a um serviço negado:

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

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

<!--
# Este exemplo pode ser mais interessante? 
# Ele também faz relação com a próxima seção (jfs)
#
# era: página de manual do hosts_access(5),
# e porque você não está usando o logger(1) aqui? (FIXME?)
#
#&lt;example&gt;
#ALL: ALL: SPAWN ( \
#  /usr/local/sbin/send_syslog %u %c %d )
#&lt;example&gt;

#  With send_syslog as:
##!/usr/bin/perl -w
#
#use Sys::Syslog qw(:DEFAULT setlogsock);
#
#$user=shift(@ARGV) || 'unknown';
#$host=shift(@ARGV) || 'unknown';
#$service=shift(@ARGV) || 'unknown';
#setlogsock('unix');
#openlog("alert",'', 'user');
#syslog('warning', 'Conexão bloqueada vinda de %s em %s para %s.', ($user, $host, $service) );
#closelog();
#
#exit 0;
-->

<sect id="log-alerts">A importância dos logs e alertas

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

<p>O Debian GNU/Linux fornece algumas ferramentas que fazem análise de logs, mais 
notavelmente <package>swatch</package>, <footnote>existe um artigo muito 
bom, escrito por <url id="http://www.spitzner.net/swatch.html" name="Lance Spitzner">
</footnote> <package>logcheck</package> ou <package>log-analysis</package> 
(todos precisarão de algumas personalizações para que coisas desnecessárias 
sejam removidas do relatório). Também pode ser útil, se o sistema estiver 
visivelmente próximo, ter as mensagens do sistema mostradas em um console virtual. Isto é 
útil, pois você pode (através de certa distância) ver se o sistema está se 
comportando adequadamente. O <file>/etc/syslog.conf</file> do Debian vem 
com uma configuração padrão comentada; para ativá-la, descomente as linhas e 
reinicie o <prgn>syslogd</prgn> (<tt>/etc/init.d/syslogd restart</tt>):

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


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

<!-- FIXME: Procurar por informações sobre o SHARP, o 'syslog heuristic analysis
and response program'.  O papel está em 
id="http://www.csis.gvsu.edu/sharp/". É software livre? empacotado?

a URL não existe mais, mas é arquivada em 
http://web.archive.org/web/20020816100838/http://www.csis.gvsu.edu/sharp/
http://web.archive.org/web/20020816100838/http://www.csis.gvsu.edu/sharp/sharp.ps

Nenhuma localização de download está disponível.
-->

<sect1 id="custom-logcheck">Usando e personalizando o <prgn>logcheck</prgn>

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

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

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

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


<sect1>Configurando para onde os alertas são enviados

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

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

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

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

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


<sect1>Usando um servidor de logs

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

<!-- FIXME: A seguinte também pode ser interessante -->
<!-- Como ocultar o servidor de logs na rede i.e. não dando um endereço -->
<!-- IP e adicionando uma entrada ARP estática nas máquinas usando o -->
<!-- servidor syslog remoto (somente se estiver no mesmo hub); se o servidor -->
<!-- remoto não estiver em uma rede separada, o gateway padrão deverá ser -->
<!-- configurado de forma apropriada -->

<example>
  SYSLOGD=""
</example>
to 
<example>
  SYSLOGD="-r"
</example>

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

<example>
  facility.level            @your_loghost
</example>

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

<example>
  *.*                       @your_loghost
</example>

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


<sect1>Permissões dos arquivos de log

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

<!--  Deverá ser explicado após a instalação porque isto já não é feito, jfs -->

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

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

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

<!-- This is no longer true, check apache's logrotate
<p>
I want to emphasize that the apache log file permissions are really
screwed due to the fact that the apache user owns the apache log
files. If a user gets a shell with a back door in apache, they can
easily remove the log files.
-->

<sect id="kernel-patches">Adicionando patches no kernel
<!-- last edited by Frédéric Schütz <schutz@mathgen.ch> -->


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

<list>

<item>Detecção de Intrusão no Linux (no pacote <package>lids-2.2.19</package>),
por Huagang Xie e Philippe Biondi. Este patch do kernel torna o 
processo de fortalecimento do seu sistema Linux uma tarefa fácil 
permitindo que você restrinja, oculte e proteja processos, até mesmo 
do usuário root. Ele também permite que proteja ou oculte certos 
arquivos para que até mesmo o root não possa modificá-los. Adicionalmente, 
você poderá também definir capacidades para certos processos. Um "máximo" 
para o administrador de sistema paranóico. Página web 
<url id="http://www.lids.org" name="http://www.lids.org">

<item><em>Listas de Controle de Acessos POSIX (ACLs) para Linux</em> 
(no pacote <package>kernel-patch-acl</package>). Este patch de kernel
adiciona listas de controle de acesso, um método avançado de restringir 
acesso a arquivos. Ele permite a você um fino controle de acesso a arquivos
e diretórios. Este patch foi adicionado ao kernel 2.6. Página do projeto: <url
name="http://acl.bestbits.at/" id="http://acl.bestbits.at/">
<!--Este patch foi adicionado ao kernel de desenvolvimento 2.5 e 
será incluindo no futuro kernel 2.6. Página do projeto: <url
name="http://acl.bestbits.at/" id="http://acl.bestbits.at/">-->

<item>Linux Trustees (no pacote <package>trustees</package>). Este patch
adiciona um gerenciamento avançado decente de permissões do sistema para
o kernel do Linux. Objetos especiais (chamados trustees) são ligados a 
cada arquivo ou diretório e são armazenados na memória do kernel, permitindo
pesquisa rápida de todas as permissões.
Homepage: <url name="http://trustees.sourceforge.net/"
id="http://trustees.sourceforge.net/">

<item>NSA Enhanced Linux (no pacote <package>selinux</package> também
disponível de  
<url id="http://www.coker.com.au/selinux/" name="the developer's website">)

<item><package>kernel-patch-2.2.18-openwall</package>, por Solar
Designer. Este contém um conjunto útil de restrições do kernel, como 
links restritos, FIFOs em <file>/tmp</file>, um sistema de arquivos 
<file>/proc</file> restrito, manipulação especial de descritores de 
arquivos, área não executável de pilha do usuário e outras. Página: 
<url name="http://www.openwall.com/linux/"
id="http://www.openwall.com/linux/">

<item><package>kernel-patch-2.4-grsecurity</package>: O patch do Grsecurity
 
<footnote>
Note que, dependendo do pacote de fonte do kernel 2.4 que você usar, você 
poderá encontrar problemas durante o patch de fontes de kernel. Se 
este for seu caso, você precisa usar o kernel vanilla. Você poderá fazer 
isto com os seguintes passos:
<example>
# apt-get install kernel-source-2.4.22 kernel-patch-debian-2.4.22
# tar xjf /usr/src/kernel-source-2.4.22.tar.bz2
# cd kernel-source-2.4.22
# /usr/src/kernel-patches/all/2.4.22/unpatch/debian
</example>
<p>Para mais detalhes veja
<url id="http://bugs.debian.org/194225"
name="#194225">, <url id="http://bugs.debian.org/199519"
name="#199519">, <url id="http://bugs.debian.org/206458"
name="#206458">, <url id="http://bugs.debian.org/203759"
name="#203759">, <url id="http://bugs.debian.org/204424"
name="#204424">, <url id="http://bugs.debian.org/210762"
name="#210762">, <url id="http://bugs.debian.org/211213"
name="#211213">, e <url
id="http://lists.debian.org/debian-devel/2003/debian-devel-200309/msg01133.html"
name="discussion at debian-devel">
</footnote>
implementa Controle de Acesso Mandatário, oferece proteção contra 
estouro de buffer, ACLs, network randomness
(para tornar OS fingerprint mais difícil) e <url
id="http://www.grsecurity.net/features.php" name="muito mais
características">.


<item><package>kernel-patch-2.2.19-harden</package>. <em>FIXME</em>
Adicionar conteúdo.

<item>suporte a kernel IPSEC (no pacote <package>kernel-patch-freeswan</package>). 
Se deseja usar o protocolo IPSec com o Linux, você precisará deste patch. 
Você poderá criar VPNs com este muito facilmente, até em máquinas Windows, 
pois o IPsec é um padrão comum. As capacidades do IPsec foram adicionadas 
ao kernel de desenvolvimento 2.5, assim esta característica estará presente
por padrão em um kernel 2.6 futuro. Página: <url id="http://www.freeswan.org">. 

<em>FIXME</em>: Os últimos kernels 2.4 contidos no Debian incluem o backport
do código ipsec do kernel 2.5. Comente sobre isto

<item><package>cryptoapi-core-source</package>. Este patch 
adiciona capacidades de criptografia do kernel do Linux, como 
embaralhadores e funções digest. Usos tradicionais para estas funções 
são a criptografia de sistemas de arquivos ou swap. Note que no kernel
2.5.45, funcionalidades parecidas foram adicionadas ao fonte 
oficial do kernel do Linux, assim é possível que não precise mais
deste patch em um kernel 2.6 futuro
<em>Nota</em>: este pacote não existe em lançamentos do Debian antes da 
<url id="http://www.debian.org/releases/sarge/" name="Sarge">.
Homepage: <url name="http://www.kerneli.org/" id="http://www.kerneli.org/">

<item><package>cryptoloop-source</package>. Este patch lhe permite 
usar as funções do pacote <package>cryptoapi-core-source</package> para
criar sistemas de arquivos criptografados usando o dispositivo de loopback.

<item><package>kernel-patch-int</package>. Este patch também
adiciona capacidades criptográficas ao kernel do Linux e foi 
útil com lançamentos do Debian até a Potato. Ele não funciona com a 
Woody e se você estiver usando a Sarge ou release mais novo, 
deverá usar um pacote mais recente do <package>cryptoapi-core-source</package>.


</list>

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

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

<!-- Tornar as entradas coerentes: os nomes dos pacotes devem ser links 
para a página do pacotes? -->

<p>No entanto, alguns patches ainda não foram adicionados ainda no Debian. 
Se sentir que alguns destes devem ser incluídos, por favor pergunte por 
ele em <url name="Work Needing and Prospective Packages"
id="http://www.debian.org/devel/wnpp/">. Alguns destes pacotes são:

<list>

<item><url id="http://pageexec.virtualave.net/" name="
patch do PaX">

<item>
<url name="patch HAP"
id="http://www.theaimsgroup.com/~hlein/hap-linux/">

<item>
<url name="Patch Stealth"
id="http://www.energymech.net/madcamel/fm/">

<item><em>SubDomain</em>. Uma extensão do kernel feita para 
oferecer confinamento com poucas permissões para programas
possivelmente inseguros. Complemento de subdomínio e 
extensão para controle de acesso nativo. Enquanto é similar 
ao ambiente <prgn>chroot</prgn>, ele clama ser de fácil 
construção e mais flexível que um ambiente <prgn>chroot</prgn>.
<!-- FIXME URL não é válida, ou não é possível achar a nova localização
Homepage:
<url name="http://www.immunix.org/subdomain.html"
id="http://www.immunix.org/subdomain.html">
-->

<item><em>Contexts (ctx) patch</em>. Uma extensão do kernel feita para 
implementar servidores privados virtuais. É parecido com o <prgn>jail</prgn> no BSD.
Homepage:
<url name="http://www.immunix.org/subdomain.html"
id="http://www.immunix.org/subdomain.html">

<item><em>UserIPAcct</em>. Não é um patch realmente relacionado a segurança, mas ele 
lhe permite criar quotas de tráfego por usuário em seu sistema. Você também 
pode obter estatísticas sobre o tráfego de usuário.
Homepage: <url id="http://ramses.smeyers.be/useripacct">.

</list>


<sect>Protegendo-se contra estouros de buffer

<p>O <em>estouro de buffer (buffer overflow)</em> é o nome de um comum ataque a softwares
<footnote>Tão comum, de fato, que eles são a base de 20% de vulnerabilidades
reportadas de segurança todo ano, como determinado pelas
<url id="http://icat.nist.gov/icat.cfm?function=statistics"
name="estatísticas do banco de dados dde vulnerabilidades ICAT's"></footnote>
que faz o uso de checagem insuficiente de limites (um erro de 
programação, mais comum na linguagem C) para executar o código de 
máquina através de entrada de programas. Estes ataques, contra programas
de servidores que escutam conexões remotamente ou contra softwares locais 
que garantem altos privilégios aos usuários (<tt>setuid</tt> ou <tt>setgid</tt>) 
podem resultar no comprometimento de qualquer sistema determinado.

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

<list>

<item>aplicar um patch no kernel para prevenir a execução da pilha (você pode 
usar os patches OpenWall ou Grsecurity)

<!-- FIXME: adicionar um link para a libsafe -->

<item>usar uma biblioteca, tal como a <url
id="http://www.research.avayalabs.com/project/libsafe/"
name="libsafe">, para substituir funções vulneráveis e introduzir
a checagem apropriada (para informações sobre como instalar a <package>libsafe</package> leia <url
id="http://www.Linux-Sec.net/harden/libsafe.uhow2.txt" name="isto">).

<item>corrigir o código fonte usando ferramentas para encontrar 
fragmentos de onde pode introduzir esta vulnerabilidade.

<item>recompilar o código fonte para adicionar checagens apropriadas que 
previnem buffer overflows, usando, por exemplo, <url
id="http://www.immunix.org/stackguard.html" name="StackGuard"> (que é 
usado pelo <url id="http://www.immunix.org" name="Immunix">) ou o patch 
<url id="http://www.research.ibm.com/trl/projects/security/ssp/" name="Stack
Smashing Protector (SSP)"> para o GCC (que é usado pelo <url
id="http://www.adamantix.org" name="Adamantix">)

</list>

<p>O Debian GNU/Linux em seu lançamento 3.0, fornece software para 
introduzir todos estes métodos exceto a proteção de compilação do 
código fonte (mas isto foi requisitado no <url
id="http://bugs.debian.org/213994" name="Bug #213994">)

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

<p>Em qualquer caso, esteja alerta que até mesmo estas alternativas 
podem não prevenir buffer overflows, pois existem formas de  
burlá-los, como descrito na revista phrack's <url name="issue 58"
id="http://packetstorm.linuxsecurity.com/mag/phrack/phrack58.tar.gz">
ou no aviso CORE's 
<url id="http://onlne.securityfocus.com/archive/1/269246"
name="Múltiplas vulnerabilidades nas tecnologias de 
proteção de pilha">.

<sect1>Patches de kernel para proteção contra estouros de buffer

<p>Os patches do kernel relacionados a estouro de buffer incluem o 
patch Openwall que oferece proteção contra buffer overflows nos kernels 
do Linux 2.2. Para kernels 2.4 ou superiores, utilize o patch Grsecurity 
(existente no pacote <package> kernel-patch-2.4-grsecurity</package>) 
que inclui o patch do Openwall e muito mais  <url
id="http://www.grsecurity.net/features.php" name="características">
(incluindo ACLs e métodos de rede que dificultam a realização de 
OS fingerprinting), ou os módulos de Segurança do Linux (nos pacotes
<package>kernel-patch-2.4-lsm</package> e
<package>kernel-patch-2.5-lsm</package>).
Para mais informações sobre como usar estes patch leia a seção <ref
id="kernel-patches">.

<sect1>Proteção da <prgn>Libsafe</prgn>

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

<p><em>Nota Importante</em>: A proteção da <prgn>Libsafe</prgn> pode não 
ser efetiva atualmente como descrito em <url id="http://bugs.debian.org/173227"
name="173227">. Considere testá-la antes de usá-la em um ambiente de produção 
e não dependa exclusivamente dela para proteger seu sistema.

<sect1>Testando problemas de estouro em programas

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


<sect>Transferência segura de arquivos

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

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

<p>Note que o uso de <prgn>scp</prgn> fornece acesso dos usuários a
todos os arquivos do sistema a não ser que esteja dentro de um 
<prgn>chroot</prgn> como descrito em <ref
id="ssh-chroot">. O acesso FTP pode ser feito usando <prgn>chroot</prgn>, 
possivelmente mais fácil dependendo do daemon escolhido, como descrito em 
<ref id="ftp-secure">. Se está preocupado sobre usuários 
navegando em seus arquivos locais e deseja ter comunicação encriptada, 
você poderá usar um daemon FTP com suporte a SSL ou combinar ftp texto 
plano com uma configuração de VPN (veja <ref id="vpn">).

<sect>Limitações e controle do sistema de arquivos

<!-- Talvez seja interessante usar cotas no lugar de quotas -->
<sect1>Usando quotas

<p>
É importante se ter uma boa política de quotas, pois ela evita que os usuários
ocupem todo o(s) disco(s) rígido(s).
<p>
Você poderá usar dois sistemas diferentes de quota: quota do usuário
e quota do grupo. Você provavelmente notará que limites de quota 
de usuários definem o espaço que o usuário pode utilizar, a quota de 
grupo é equivalente para grupos. Mantenha isto em mente quando estiver
trabalhando com tamanhos de quota.

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

<list>
<item>Mantenha as quotas suficientemente pequenas, assim os usuários não 
poderão acabar com todo seu espaço em disco.

<item>Mantenha as quotas grande o bastante, assim os usuarios não se importarão
ou sua quota de e-mails os proibirá de receber mensagens por um longo período.

<item>Use quotas em todas as áreas graváveis por usuários, em <file>/home</file> 
como também em <file>/tmp</file>.
</list>

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

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

<!-- FIXME: como checar pelo suporte a quotas? O que fazer durante a 
recompilação? -->

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

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

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

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

<p>Você pode ou não gostar do <package>lshell</package>, pois ele
viola a FHS. Também tenha em mente que o <file>pam_limits.so</file> 
pode fornecer a mesma funcionalidade e <package>lshell</package>
está atualmente <url id="http://bugs.debian.org/93894" name="orfanado">


<sect1 id="ext2attr">Os atributos específicos do sistema de arquivos ext2 (chattr/lsattr) 
<!-- section last edited by Frédéric Schütz <schutz@mathgen.ch> -->

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

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

<list>
<item>O atributo 'i' ('imutável'): um arquivo com este atributo 
não pode ser modificado, excluído ou renomeado, e nenhum link poderá 
ser criado para ele, até mesmo pelo superusuário.

<item>O atributo 'a' ('incremental'): este atributo tem o mesmo 
efeito do atributo imutável, exceto que você ainda poderá abrir o 
arquivo em modo incremental. Isto significa que você poderá adicionar
mais conteúdo a ele, mas será impossível modificar o conteúdo anterior. 
Este atributo é especialmente útil para arquivos de log armazenados em
<file>/var/log/</file>, assim você deverá considerar que eles serão movidos
sempre devido aos scripts de rotacionamento de logs.
</list>

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

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

<p>
Um método de resolver isto é usar as capacidades do kernel do Linux, como 
descrito em <ref id="proactive">. A capacidade de interesse aqui é 
chamada <tt>CAP_LINUX_IMMUTABLE</tt>: se removê-la do conjunto 
de capacidades (usando por exemplo,o comando 
<tt>lcap CAP_LINUX_IMMUTABLE</tt>) não será possível alterar qualquer atributo
'a' ou 'i' em seu sistema, até mesmo pelo superusuário! Uma estratégia 
completa pode ser a seguinte:

<enumlist>
  <item> Defina os atributos 'a' e 'i' nos arquivos que deseja;
  <item> Execute o comando <tt>lcap CAP_LINUX_IMMUTABLE</tt> (também como
         <tt>lcap CAP_SYS_MODULE</tt>, como sugerido em <ref id="proactive">)
         a um dos scripts de inicialização;
<!-- Existe algo interessante em:
http://lists.debian.org/debian-security/2001/debian-security-200107/msg00024.html -->
  <item> Defina o atributo 'i' neste script e em outros arquivos de inicialização, 
assim também como no próprio binário <prgn>lcap</prgn>;
  <item> Execute manualmente o comando acima (ou reinicie o seu sistema 
para ter certeza que tudo funciona como planejado).
</enumlist>

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

<!-- Add a note about the fact that it is not widely used -->

<sect1 id="check-integ">Verificando a integridade do sistema de arquivos

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

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

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

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

<p>FIXME: colocar referências ao snapshot feito após a instalação.
<p>FIXME: Adicionar uma nota com relação a pacotes que não fornecem debsums
de aplicativos instalados (não mandatário).
<p>FIXME: Mencionar binários assinados usando digamos, bsign ou elfsign

<sect1>Configurando verificação de setuid

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

<!-- FIXME: Qual é o padrão para isto no pacote cron? jfs -->

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

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

<sect id="network-secure">Tornando o acesso a rede mais seguro

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


<sect1 id="kernel-conf">Configurando características de rede do kernel

<p>FIXME: Faltando conteúdo

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

<!-- FIXME: O profixo em todos estes deve ser /proc/sys/? era -->

<example>
net/ipv4/icmp_echo_ignore_broadcasts = 1
</example>

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

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

<example>
net/ipv4/icmp_echo_ignore_all = 1
</example>

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

<example>
/proc/sys/net/ipv4/conf/all/log_martians = 1
</example>

<p>Para mais informações sobre que coisas podem ser feitas com
<file>/proc/sys/net/ipv4/*</file> leia
<file>/usr/src/linux/Documentation/filesystems/proc.txt</file>. 
Todas as opções estão descritas através do
<file>/usr/src/linux/Documentation/networking/ip-sysctl.txt</file>
<footnote>No Debian o pacote <package>kernel-image</package> instala
o fonte sob <file>/usr/src/kernel-source-2.X.X</file>, apenas 
subistitua <em>linux</em> com o tipo de kernel que está instalado</footnote>.

<sect1 id="tcp-syncookies">Configurando Syncookies


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

<!-- O que isto significa? (jfs)
Esta opção é bastante muda, pois ela faz flood no outro lado
assim como ela faz em você, assim o outro lado também estará 
ocupado. 
-->

<example>
net/ipv4/tcp_syncookies = 1
</example>

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

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

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

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

<p>Para mais informações sobre os syncookies TCP, leia
<url id="http://cr.yp.to/syncookies.html">.


<sect1 id="net-harden">Tornando a rede segura em tempo de inicialização
 <p>
Quando definir opções de configuração do kernel para a rede, você precisará 
configurá-la de forma que seja carregada sempre que o sistema for iniciado. O 
seguinte exemplo ativa muitas das opções anteriores assim como outras opções 
úteis.

<p><em>FIXME</em> Ao invés de fornecer este script, fornecer uma configuração
modelo para o <file>sysctl.conf</file> (veja: <manref section="5"
name="sysctl.conf">). Também envie isto como um bug wishlist para o 
pacote.

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

<example>
auto eth0
iface eth0 inet static
        address xxx.xxx.xxx.xxx
        netmask 255.255.255.xxx
        broadcast xxx.xxx.xxx.xxx
        gateway xxx.xxx.xxx.xxx
        pre-up /etc/network/interface-secure
</example>

<example>
#!/bin/sh
# Nome do Script: /etc/network/interface-secure
# Modifica o comportamento padrão para tornar o sistema seguro contra
# alguns tipos de ataques TCP/IP spoofing
# some TCP/IP spoofing & attacks
#
# Contribuído por Dariusz Puchalak  
#
echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts 
                                           # proteção contra broadcast de ECHO
echo 0 > /proc/sys/net/ipv4/ip_forward     # desativação de forward de ip
echo 1 > /proc/sys/net/ipv4/tcp_syncookies # Proteção contra syn cookies ativada
echo 1 >/proc/sys/net/ipv4/conf/all/log_martians # Registra pacotes estranhos
# (isto inclui pacotes falsos, pacotes com a rota de origem alterada e pacotes
redirecionados)
                         # mas tenha cuidado com isto em servidores web carregados
echo 1 > /proc/sys/net/ipv4/ip_always_defrag 
                                           #  opção de desfragmentação sempre ativada
echo 1 > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses 
                                           # proteção ativada contra mensagens de erro incorretas

# proteção contra ip spoofing
echo 1 > /proc/sys/net/ipv4/conf/all/rp_filter

# e finalmente mais coisas:
# Não aceita redirecionamento de ICMP
echo 0 > /proc/sys/net/ipv4/conf/all/accept_redirects
echo 0 > /proc/sys/net/ipv4/conf/all/send_redirects

# Desativa pacotes com rota de origem
echo 0 > /proc/sys/net/ipv4/conf/all/accept_source_route

echo 1 > /proc/sys/net/ipv4/conf/all/log_martians
</example>

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


<sect1 id="kernel-fw">Configurando características do firewall
 <p>
Para ter capacidades de firewall, ou para proteger o sistema local
ou outros <em>atrás</em> dele, o kernel precisa ser compilado 
com capacidades de firewall. O kernel padrão do Debian 2.2 
(também 2.2) fornece o filtro de pacotes 
chamado <prgn>ipchains</prgn>, o Debian 3.0
usando o kernel padrão (kernel 2.4) oferece um filtro de pacotes de 
<em>estado</em> chamado <prgn>iptables</prgn> (netfilter). As 
distribuições antigas do Debian precisarão de um patch apropriado 
no kernel (o Debian 2.1 usa o kernel 2.0.34).

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

<p>A configuração de firewalls no Debian é discutida mais precisamente em <ref
id="firewall-setup">.


<sect1 id="limit-bindaddr">Desativando assuntos relacionados a weak-end de máquinas

<!-- FIXME I read this and I dont get what's the point ? -->

<p>Sistemas com mais de uma interface de rede em diferentes 
redes podem ter os serviços configurados de forma que escutem
somente a um determinado endereço IP. Isto normalmente evita o 
acesso a serviços quando são requisistados através de qualquer 
outro endereço. No entanto, isto não significa
(que foi até mesma uma concepção correta que tive) que o 
serviço é oferecido ao endereço de <em>hardware</em> (interface 
de rede).
<footnote>
Para reproduzir isto (exemplo oferecido por Felix von Leitner na 
lista de discussão bugtraq):
<example>
   máquina A (eth0 conectada a eth0 da máquina B):
     ifconfig eth0 10.0.0.1
     ifconfig eth1 23.0.0.1
     tcpserver -RHl localhost 23.0.0.1 8000 echo fnord

   máquina B:
     ifconfig eth0 10.0.0.2
     route add 23.0.0.1 gw 10.0.0.1
     telnet 23.0.0.1 8000
</example>
<p>Parece, no entanto, não funcionar com serviços funcionando na
interface 127.0.0.1, você precisará fazer os testes usando 
soquetes simples.</p>
</footnote>

<p>Isto não é um assunto relacionado a ARP e não é uma violação da RFC 
(isto é chamado <em>máquina weak end</em> na
<url id="ftp://ftp.isi.edu/in-notes/rfc1122.txt" name="RFC1122">, 
seção 3.3.4.2). 
Lembre-se, endereços IP não tem nada a ver com a interface física.

<p>Nos kernels da série 2.2 (e anteriores) isto pode ser corrigido com:
<example>
# echo 1 > /proc/sys/net/ipv4/conf/all/hidden
# echo 1 > /proc/sys/net/ipv4/conf/eth0/hidden
# echo 1 > /proc/sys/net/ipv4/conf/eth1/hidden
.....
</example>
<p>Em outros kernels, isto pode ser corrigido com uma das alternativas:
<list>
<item>regras do iptables.
<item>roteamento corretamente configurado.
<footnote>
O fato deste comportamento ser alterado através do roteamento foi 
descrito por Matthew G. Marsh na thread do bugtraq:
<example>
eth0 = 1.1.1.1/24
eth1 = 2.2.2.2/24

ip rule add from 1.1.1.1/32 dev lo table 1 prio 15000
ip rule add from 2.2.2.2/32 dev lo table 2 prio 16000

ip route add default dev eth0 table 1
ip route add default dev eth1 table 2
</example>
</footnote>
<item>Patch do kernel
<footnote>
Existem alguns patches disponíveis para este comportamento como 
descrito na discussão do bugtraq em
<url id="http://www.linuxvirtualserver.org/~julian/#hidden">
e <url id="http://www.fefe.de/linux-eth-forwarding.diff">.
</footnote>
</list>
<p>Junto com este texto, existirão algumas ocasiões em que será mostrado 
como configurar alguns serviços (servidor sshd, apache, serviço de 
impressão...) para tê-los escutando em um determinado 
endereço, o leitor deverá ter em mente que, sem as correções 
fornecidas aqui, a correção não evitará acesso de dentro do 
mesmo segmento de rede (local).
<footnote>
Um invasor pode ter muitos problemas para contornar o 
acesso através da escuta de endereços IP se ele não está no 
mesmo domínio de broadcast (mesma rede) que a máquina que será 
atacada. Se a invasão for através do roteador, será bastante 
difícil as repostas retornarem a algum lugar.
</footnote>

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

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


<sect1>Protegendo-se contra ataques ARP

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

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

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

<!-- removido <url name="arpmim"
id="http://www.team-teso.net/releases/arpmim-0.2.tar.gz">, <url
name="arpoison" id="http://web.syr.edu/~sabuer/arpoison/">...
 ~sabuer broken and unavailable in the new web site provided -->

<p>No entanto, sempre existe uma solução:

<list>

<item>Use um cache arp estático. Você pode configurar entradas "estáticas" em seu 
cache arp:

<example>
arp -s host_name hdwr_addr 
</example> 

<p>Configurando entradas estáticas para cada máquina importante em sua rede
você se assegura de que ninguém poderá criar/modificar uma entrada (falsa) 
para estas máquinas (entradas estáticas não expiram e não podem ser 
modificadas) e respostas arp falsificadas serão ignoradas.


<item>Detectar tráfego ARP suspeito. Você poderá usar o pacote
<package>arpwatch</package>, <package>karpski</package> ou ferramentas
IDS mais gerais que também poderão detectar tráfego arp suspeitos como 
(<package>snort</package>, <url name="prelude"
id="http://www.prelude-ids.org">...).

<item>Implementando filtragem na validação de tráfego IP no endereço MAC.
</list>


<sect id="snapshot">Fazendo um snapshot do sistema

<p>Antes de por o sistema em produção você deverá tirar um snapshot de todo 
o sistema. Este snapshot deverá ser usado em um evento de compromisso
(veja <ref id="after-compromise">). Você deverá refazer este upgrade 
assim que o sistema for atualizado, especialmente se seu upgrade 
for para uma novo lançamento do Debian.

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

<p>O seguinte script criará o snapshot:

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

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

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

<list>
<item>os md5sums fornecidos por pacotes do Debian incluem todos os 
arquivos fornecidos por eles, que torna o banco de dados grande (5 MB contra
600Kb em um sistema Debian GNU/Linux com um sistema gráfico e 
com aproximadamente 2.5 Gb de programas instalados)

<item>nem todos os pacotes do Debian contém md5sums de arquivos que foram
instalados pois esta não é (atualmente) a política mandatória.

</list>

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


<sect>Outras recomendações
<sect1>Não use programas que dependem da svgalib

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

<!-- FIXME: mover isto para a seção da policy se existir uma? -->


