[ anterior ] [ Conteúdo ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ A ] [ B ] [ C ] [ D ] [ E ] [ F ] [ G ] [ H ] [ próximo ]
Assim que o sistema for instalado, você ainda poderá fazer mais para deixá-lo mais seguro; alguns dos passos descritos neste capítulo podem ser seguidos. É claro que isto depende de sua configuração, mas para prevenção de acesso físico você deverá ler Altere a BIOS (de novo), Seção 4.3,Configurar a senha do LILO ou GRUB, Seção 4.4,Remover o aviso de root do kernel, Seção 4.5, Desativando a inicialização através de disquetes, Seção 4.6, Restringindo o acesso de login no console, Seção 4.7 e Restringindo reinicializações do sistema através da console, Seção 4.8.
Antes de se conectar a qualquer rede, especificamente se for uma rede pública, no mínimo execute uma atualização de segurança (veja Executar uma atualização de segurança, Seção 4.2). Opcionalmente, você deverá fazer um snapshot do seu sistema (veja Fazendo um snapshot do sistema, Seção 4.18).
Para receber informações sobre atualizações e alertas de segurança (DSAs)
disponíveis e DSAs você deverá se inscrever na lista de discussão
debian-security-announce. Veja O
time Debian Security, Seção 7.1 para mais informações sobre como o time de
segurança do Debian funciona. Para mais informações sobre como se inscrever
nas listas de discussões do Debian, leia http://lists.debian.org
.
Os DSAs são assinados pelo time de segurança do Debian e as assinaturas podem
ser pegas através do endereço http://security.debian.org
.
Você deverá considerar, também, em se inscrever na lista de discussão
debian-security
para discussões gerais de problemas de segurança no
sistema operacional Debian. Na lista você poderá entrar em contato com outros
administradores de sistemas experientes, assim como também desenvolvedores do
Debian e autores de ferramentas de segurança que podem responder suas questões
e oferecer recomendações.
FIXME: também adicionar a chave aqui?
Assim que novos bugs são descobertos nos pacotes, os mantenedores do Debian e
autores de software geralmente aplicam patches dentro de dias ou até mesmo
horas. Após uma falha ser corrigida, um novo pacote é disponibilizado em
http://security.debian.org
.
Se estiver instalando um lançamento do Debian, você deverá ter em mente que desde que o lançamento foi feito devem existir atualizações de segurança que podem determinar um pacote como vulnerável. Também existem lançamentos menores (foram sete no lançamento da 2.2 potato) que incluem estas atualizações de pacotes.
Você precisa anotar a data em que a mídia removível foi feita (se estiver usando uma) e verificar o site de segurança para ter certeza que existem atualizações de segurança. Se existem atualizações e você não puder baixar os pacotes de um site security.debian.org em outro sistema (você não está conectado na Internet ainda? está?) antes de se conectar a rede você deverá considerar (se não estiver protegido por um firewall, por exemplo) adicionar regras de firewall assim seu sistema somente poderá se conectar a security.debian.org e então executar a atualização. Um modelo de configuração é mostrado em Atualização de segurança protegida por um firewall, Apêndice F.
Nota:Desde o Debian woody 3.0, após a instalação você terá a oportunidade de adicionar atualizações de segurança ao sistema. Se disser "sim" a isto, o sistema de instalação tomará os passos apropriados para adicionar a fonte de origem para as atualizações de segurança para sua origem de pacotes e seu sistema. Se já tiver uma conexão de Internet, o sistema baixará e instalará qualquer atualização de segurança que produziu após a mídia ser criada. Se estiver atualizando a partir de uma versão anterior do Debian, o perguntou ao sistema de instalação para não fazer isto, você deverá realizar os passos descritos aqui.
Para atualizar manualmente o sistema, insira a seguinte linha em seu
sources.list
e você obterá as atualizações de segurança
automaticamente, sempre que atualizar seu sistema.
deb http://security.debian.org/ stable/updates main contrib non-free
Assim que instalar isto, você poderá usar ou o apt
ou
dselect
para atualizar:
Se quiser usar o apt
simplesmente execute (como root):
# apt-get update # apt-get upgrade
Se quiser usar o dselect
então primeiro execute o [U]pdate, então
[I]nstall e depois, finalmente, [C]onfigure pata instalar/atualizar os pacotes.
Se quiser, você também poderá adicionar linhas deb-src ao seu arquivo
/etc/apt/sources.list
. Veja apt(8)
para mais
detalhes.
Nota: Você não precisa adicionar a seguinte linha:
deb http://security.debian.org/debian-non-US stable/non-US main contrib non-free
isto é porque security.debian.org é hospedado em uma localização fora dos Estados Unidos e não possui um arquivo separado non-US.
Se lembra Escolha uma senha para a BIOS, Seção 3.1? Bem, então você deve agora, uma vez que não precisa inicializar através de uma mídia removível, alterar a configuração padrão da BIOS, desta forma ela poderá somente inicializar a partir do disco rígido. Tenha certeza de que não perderá a senha da BIOS, caso contrário, se ocorrer uma falha no disco rígido você não será capaz de retornar a BIOS e alterar a configuração e recuperá-la usando, por exemplo, um CD-ROM.
Outro método mais conveniente, mas menos seguro, é alterar a configuração para ter o sistema inicializando a partir do disco rígido e, caso falhe, tentar a mídia removível. Por agora, isto é feito freqüentemente porque a maioria das pessoas não usam a senha de BIOS com freqüência; pois se esquecem dela facilmente.
Qualquer um pode facilmente obter uma linha de comando de root e alterar sua senha entrando com o parâmetro <name-of-your-bootimage> init=/bin/sh no aviso de boot. Após alterar a senha e reiniciar o sistema, a pessoa terá acesso ilimitado como usuário root e poderá fazer qualquer coisa que quiser no sistema. Após este processo, você não terá acesso root ao seu sistema, já que não saberá mais sua senha.
Para se assegurar que isto não ocorra, você deverá definir uma senha para o gerenciador de partida. Escolha entre uma senha global ou uma senha para determinada imagem.
Para o LILO, você precisará editar o arquivo de configuração
/etc/lilo.conf
e adicionar uma linha password e
restricted como no exemplo abaixo.
image=/boot/2.2.14-vmlinuz label=Linux read-only password=mude-me restricted
Quando terminar, re-execute o lilo. Caso omita restricted o lilo
sempre perguntará por uma senha, não importando se foram passados parâmetros de
inicialização. As permissões padrões do /etc/lilo.conf
garantem
permissões de leitura e gravação para o root e permite o acesso somente leitura
para o grupo do lilo.conf
, geralmente root.
Caso utilize o GRUB ao invés do LILO, edite o /boot/grub/menu.lst
e adicione as seguintes duas linhas no topo do arquivo (substituindo, é claro
mude-me pela senha designada). Isto evita que usuários editem os
itens de inicialização. A opção timeout 3 especifica uma espera
de 3 segundos antes do grub
inicializar usando o item padrão.
timeout 3 password mude-me
Para fortalecer futuramente a integridade da senha, você poderá armazenar a
senha em um formato criptografado. O utilitário grub-md5-crypt
gera um hash de senha que é compatível com o algoritmo de senha encriptada pelo
grub (md5). Para especificar no grub
que uma senha no formato md5
será usada, use a seguinte diretiva:
timeout 3 password --md5 $1$bw0ez$tljnxxKLfMzmnDVaQWgjP0
O parâmetro --md5 foi adicionado para instruir o grub
a fazer o
processo de autenticação md5. A senha fornecida é uma versão encriptada md5 do
mude-me. O uso do método de senhas md5 é preferido em contrapartida da seleção
de sua versão texto plano. Mais informações sobre senhas do grub
podem ser encontradas no pacote grub-doc
.
Os kernels 2.4 do Linux oferecem um método de acessar um shell de root durante
a inicialização que será logo mostrado após de carregar o sistema de arquivos
cramfs. Uma mensagem aparecerá para permitir ao administrador entrar com um
interpretador de comandos executável com permissões de root, este shell poderá
ser usado para carregar manualmente módulos quando a auto-detecção falhar.
Este comportamento é padrão para o linuxrc
do initrd
.
A seguinte mensagem será mostrada:
Press ENTER to obtain a shell (waits 5 seconds)
Para remover este comportamento, você precisará alterar o
/etc/mkinitrd/mkinitrd.conf
e definir:
# DELAY O número de segundos que o script linuxrc deverá aguardar para # permitir ao usuário interrompe-lo antes do sistema ser iniciado DELAY=0
Então gere novamente sua imagem do disco ram. Um exemplo de como fazer isto:
# cd /boot # mkinitrd -o initrd.img-2.4.18-k7 /lib/modules/2.4.18-k7
ou (preferido):
# dpkg-reconfigure -plow kernel-image-2.4.x-yz
Note que o Debian 3.0 woody permite aos usuários instalarem o kernel 2.4
(selecionando tipos de kernels), no entanto o kernel padrão é
o 2.2 (salvo para algumas arquitetura no qual o kernel 2.2 ainda não foi
portado). Se você acha que isto é um bug, veja Bug 145244
antes de reporta-lo.
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:
Pressione shift durante a inicialização, e um aviso MBR aparecerá
Então aperte F e o sistema inicializará pelo disquete. Isto pode ser usado para se obter acesso root ao sistema.
Este comportamento pode ser alterado com:
lilo -b /dev/hda
Agora o LILO foi colocado na MBR. Isto também pode ser feito adicionando-se
boot=/dev/hda ao arquivo de configuração lilo.conf
.
Existe também outra solução que desativa o prompt MBR completamente:
install-mbr -i n /dev/hda
Por outro lado, esta "porta dos fundos", no qual muitas pessoas simplesmente não se preocupam, podem salvar pessoas que tiverem problemas com sua instalação por quaisquer razões.
FIXME verifique se isto é realmente verdade no kernel 2.2, ou foi no 2.1? INFO: Os disquetes de inicialização no Debian 2.2 não instalam o mbr, mas somente o LILO.
Algumas políticas de segurança podem forçar os administradores a entrar no
sistema através do console com seus usuários/senhas e então se tornar o
superusuário (com o su
ou sudo
). Esta política é
implementada no Debian editando-se o arquivo /etc/login.defs
ou
/etc/securetty
quando utilizar PAM. Em:
login.defs
, editando a variável CONSOLE que define um arquivo ou
lista de terminais nos quais o login do root é permitido
securetty
[6]
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
console, ttyX [7] e vc/X (se estiver usando dispositivos
devfs), você pode querer adicionar também ttySX [8] se estiver usando um console
serial para acesso local (onde X é um inteiro, você pode querer ter múltiplas
instâncias [9] dependendo do
nível de consoles virtuais que tem ativado no /etc/inittab
[10]). Para mais informações
sobre dispositivos de terminais, leia o Text-Terminal-HOWTO
Quando utilizar PAM, outras alterações no processo de login, que podem incluir
restrições a usuários e grupos em determinadas horas, podem ser configurados no
/etc/pam.d/login
. Uma característica interessante que pode ser
desativada é a possibilidade de fazer login sem senhas. Esta característica
pode ser limitada removendo-se nullok da seguinte linha:
auth required pam_unix.so nullok
Caso seu sistema tenha um teclado conectado, qualquer um (sim, qualquer
um) poderá reinicializar o sistema sem efetuar login. Isto pode se
encaixar ou não em sua política de segurança. Se deseja restringir isto, você
deverá alterar o arquivo /etc/inittab
assim a linha que inclui a
chamada para ctrlaltdel executará shutdown
com a
opção -a (lembre-se de executar o init q após
realizar qualquer modificação neste arquivo). O padrão no Debian inclui esta
opção:
ca:12345:ctrlaltdel:/sbin/shutdown -t1 -a -r now
Agora para permitir somente que alguns usuários possam desligar o
sistema, como descreve a página de manual shutdown(8)
, você deverá
criar o arquivo /etc/shutdown.allow
e incluir lá os nomes de
usuários que podem reiniciar o sistema. Quando a combinação de três teclas
(a.k.a. Ctrl+Alt+del) for feita, o programa verificará se qualquer um
dos usuários listados estão conectados ao sistema. Se nenhum deles estiver, o
shutdown
não reiniciará o sistema.
Quando montar uma partição ext2, existem diversas opções adicionais que pode
utilizar para a chamada de montagem ou para o /etc/fstab
. Por
exemplo, esta é minha configuração do fstab para a partição /tmp
:
/dev/hda7 /tmp ext2 defaults,nosuid,noexec,nodev 0 2
Observe as diferenças na seção opções. A opção nosuid ignore os bits setuid e setgid completamente, enquanto a noexec proíbe a execução de qualquer programa naquele ponto de montagem, e a nodev ignora dispositivos. Isto soa muito bem, mas elas:
somente se aplicam a sistemas de arquivos ext2
podem ser burlados facilmente
A opção noexec evita que os binários sejam executados diretamente, mas isto é facilmente contornado:
alex@joker:/tmp# mount | grep tmp /dev/hda7 on /tmp type ext2 (rw,noexec,nosuid,nodev) alex@joker:/tmp# ./date bash: ./date: Permission denied alex@joker:/tmp# /lib/ld-linux.so.2 ./date Sun Dec 3 17:49:23 CET 2000
No entanto, muitos script kiddies tem exploits que tentam criar e executar
arquivos em /tmp
. se eles não tem conhecimento disto, caem nesta
restrição. Em outras palavras, um usuário não pode ser convencido a executar
um binário alterado em /tmp
e.g. quando acidentalmente adicionar
/tmp
em sua variável PATH.
Esteja já avisado que muitos scripts dependem de /tmp
sendo
executável. Mais notavelmente, o Debconf tem (ainda?) alguns problemas
relacionados a isto, para mais informações veja o bug 116448
.
A parte a seguir é mais um tipo de exemplo. Uma nota, no entanto:
/var
pode ser ajustado para noexec, mas alguns programas [11] mantém seus programas sob
/var
. O mesmo se aplica a opção nosuid.
/dev/sda6 /usr ext2 defaults,ro,nodev 0 2 /dev/sda12 /usr/share ext2 defaults,ro,nodev,nosuid 0 2 /dev/sda7 /var ext2 defaults,nodev,usrquota,grpquota0 2 /dev/sda8 /tmp ext2 defaults,nodev,nosuid,noexec,usrquota,grpquota 0 2 /dev/sda9 /var/tmp ext2 defaults,nodev,nosuid,noexec,usrquota,grpquota 0 2 /dev/sda10 /var/log ext2 defaults,nodev,nosuid,noexec 0 2 /dev/sda11 /var/account ext2 defaults,nodev,nosuid,noexec 0 2 /dev/sda13 /home ext2 rw,nosuid,nodev,exec,auto,nouser,async,usrquota,grpquota 0 2 /dev/fd0 /mnt/fd0 ext2 defaults,users,nodev,nosuid,noexec 0 0 /dev/fd0 /mnt/floppy vfat defaults,users,nodev,nosuid,noexec 0 0 /dev/hda /mnt/cdrom iso9660 ro,users,nodev,nosuid,noexec 0 0
/tmp
Tenha cuidado em ajustar a opção noexec em /tmp
quando desejar
instalar novos programas, pois alguns programas o utilizam para a instalação.
O Apt
é um dos tais programas (veja http://bugs.debian.org/116448
),
isto pode ser resolvido alterando-se a variável
APT::ExtractTemplates::TempDir (veja
apt-extracttemplates(1)
). Você poderá definir esta variável no
arquivo /etc/apt/apt.conf
apontando para outro diretório com
privilégio de execução ao invés de /tmp
.
Com relação a noexec, esteja alertado que ela pode não oferecer tanta segurança assim. Considere este exemplo:
$ cp /bin/date /tmp $ /tmp/date (does not execute due to noexec) $/lib/ld-linux.so.2 /tmp/date (funciona, pois o comando date não é executado diretamente)
Se configurar o /usr
como somente leitura, você não será capaz de
instalar novos pacotes em seu sistema Debian GNU/Linux. Você terá primeiro que
remontá-lo como leitura-gravação, instalar os pacotes e então remontá-lo como
somente-leitura. A última versão do apt
(no Debian woody 3.0)
pode ser configurada para executar comandos antes e após instalar pacotes,
assim você pode querer configurá-lo corretamente.
Para fazer isto, modifique o /etc/apt/apt.conf
e adicione:
DPkg { Pre-Invoke { "mount /usr -o remount,rw" }; Post-Invoke { "mount /usr -o remount,ro" }; };
Note que o Post-Invoke pode falhar com a mensagem de erro "/usr busy". Isto acontece basicamente porque está usando arquivos durante a atualização que foram atualizados. Você encontrará estes programas executando
# lsof +L1
Interrompa ou reinicie estes programas e execute manualmente o Post-Invoke.
Cuidado! Isto significa que você provavelmente precisará reiniciar sua
seção do X (se estiver executando uma) cada vez que fizer uma grande
atualização em seu sistema. Você deverá levar em conta se um sistema de
arquivos /usr
somente-leitura é adequado ao seu sistema. Veja
também isto discussion
on debian-devel about read-only /usr
.
O PAM (módulos de autenticação alteráveis) permite ao administrador do sistema
escolher como os aplicativos autenticarão os usuários. Note que o PAM não pode
fazer nada caso o aplicativo não esteja compilado com suporte a PAM. A maioria
dos aplicativos que vem com o Debian 2.2 tem este suporte ativado. Além do
mais, o Debian não tem suporte a PAM em versões anteriores a 2.2. A
configuração atual para qualquer serviço que tenha PAM ativado é para emular a
autenticação do UNIX (leia
/usr/share/doc/libpam0g/Debian-PAM-MiniPolicy.gz
para mais
informações sobre como os serviços PAM devem funcionar no Debian).
Cada aplicação com suporte a PAM fornece um arquivo de configuração em
/etc/pam.d/
que pode ser usado para modificar seu comportamento:
que método é usada para autenticação.
que método é usada para sessões.
como a checagem de senha se comportará.
A seguinte descrição está longe de ser completa, para mais informações você
deve ler o Guia do
Administrador de Sistemas Linux-PAM
(presente no site primário de distribuição
do PAM
). Este documento também pode ser encontrado no pacote do
Debian libpam-doc
.
O PAM lhe oferece a possibilidade de utilizar vários passos de autenticação de
uma só vez, sem o conhecimento do usuário. Você pode autenticar em um banco de
dados Berkeley e no banco de dados no arquivo passwd
padrão, e o
usuário somente entrará no sistema caso ele se autentique corretamente em
ambos. Você pode restringir muita coisa com o PAM, como também abrir bastante
as portas do seu sistema. Assim, seja cauteloso. Uma linha de configuração
típica que tem o tempo de controle como seu segundo elemento: Geralmente ele
deve ser ajustado para requisite, que retorna uma falha de login
caso um dos módulos falhe.
A primeira coisa que eu gosto de fazer é adicionar o suporte a MD5 nas
aplicações com suporte a PAM, pois isto nos ajuda a se proteger contra ataques
de dicionário (as senhas podem ser maiores se estiver usando MD5). As
seguintes duas linhas podem ser adicionadas em todos os arquivos em
/etc/pam.d/
que garantem acesso a máquina, como login
e ssh.
# Tenha certeza de instalar primeiro o libpam-cracklib ou então não será capaz # de se logar no sistema password required pam_cracklib.so retry=3 minlen=12 difok=3 password required pam_unix.so use_authtok nullok md5
Assim, o que este encanto faz? A primeira linha carrega o módulo cracklib do
PAM, que fornece checagem de senhas fracas, pergunta por uma nova senha com no
mínimo de 12 caracteres, uma diferença de pelo menos 3 letras da antiga senha e
permite 3 novas tentativas. O Cracklib depende do pacote wordlist (tal como
wenglish
, wspanish
, wbritish
, ...),
assim tenha certeza de instalar um que seja apropriado a seu idioma ou o
cracklib pode não ser totalmente útil. [12] A segunda linha introduz o módulo de autenticação padrão
com senhas MD5 e permite uma senha de tamanho zero. A diretiva
use_authtok é necessária para pegar a senha do módulo anterior.
Para se assegurar que o usuário root pode somente se logar no sistema de
terminais locais, a seguinte linha deverá ser ativada no
/etc/pam.d/login
:
auth requisite pam_securetty.so
Então você deverá modificar a lista de terminais no qual o usuário root pode se
logar no sistema no arquivo /etc/securetty
. Alternativamente,
você poderá ativar o módulo pam_access e modificar o arquivo
/etc/security/access.conf
que possui um controle de acesso mais
fino e geral, mas (infelizmente) não possui mensagens de log decentes (o log
dentro do PAM não é padronizado e é particularmente um problema a ser tratado).
Nós voltaremos no arquivo access.conf
um pouco mais a frente.
Em seguida, a seguinte linha deverá ser ativada no
/etc/pam.d/login
para ativar a restrição dos recursos do usuário.
session required pam_limits.so
Isto restringe os recursos do sistema que os usuários têm permissão (veja
abaixo em Limitando o uso de recursos: o arquivo
limits.conf
, Seção 4.10.2 ). Por exemplo, você pode
restringir o número de logins concorrentes (de um determinado grupo de
usuários, ou de todo o sistema), número de processos, tamanho de memória, etc.
Agora, edite o arquivo /etc/pam.d/passwd
e altere a primeira
linha. Você deverá adicionar a opção "md5" para usar senhas MD5,
altere o tamanho mínimo da senha de 4 para 6 (ou mais) e ajuste o tamanho
máximo, se quiser. A linha resultante deverá se parecer com isto:
password required pam_unix.so nullok obscure min=6 max=11 md5
Se planeja proteger o su, faça isto de forma que somente algumas pessoas possam
usá-lo para se tornar o usuário root em seu sistema, você precisará adicionar
um novo grupo chamado "wheel" em seu sistema (que é o método mais
limpo, pois nenhum arquivo tem tal permissão deste grupo ainda). adicione
neste grupo o root e outros usuários que devem ter permissão de su
para se tornar root. Então adicione a seguinte linha no
/etc/pam.d/su
:
auth requisite pam_wheel.so group=wheel debug
Isto assegura que somente algumas pessoas do grupo "wheel" poderão
usar su
para se tornar o usuário root. Outros usuários não
poderão ser capazes de se tornar root. De fato eles obterão uma mensagem de
acesso negado ao tentarem se tornar root.
Se deseja que somente alguns usuários se autentiquem em um serviço do PAM, é
muito fácil fazer isto usando arquivos onde os usuários que tem permissão de
fazer login (ou não) são armazenados. Imagine que você somente deseja permitir
o usuário "ref" a fazer o login usando ssh
. Assim,
coloque o usuário no arquivo /etc/sshusers-allowed
e escreva o
seguinte no arquivo /etc/pam.d/ssh
:
auth required pam_listfile.so item=user sense=allow file=/etc/sshusers-allowed onerr=fail
Depois crie o arquivo /etc/pam.d/other
e entre com as seguintes
linhas:
auth required pam_securetty.so auth required pam_unix_auth.so auth required pam_warn.so auth required pam_deny.so account required pam_unix_acct.so account required pam_warn.so account required pam_deny.so password required pam_unix_passwd.so password required pam_warn.so password required pam_deny.so session required pam_unix_session.so session required pam_warn.so session required pam_deny.so
Esta linhas lhe oferecerão uma boa configuração padrão para todas as aplicações que suportam PAM (o acesso é negado por padrão).
limits.conf
Você realmente deverá dar uma olhada séria neste arquivo. Aqui você poderá
limitar os recursos usados pelos usuários. Se utilizar PAM, o arquivo
/etc/limits.conf
será ignorado e deverá usar o
/etc/security/limits.conf
ao invés deste.
Se você não restringir o uso de recursos, qualquer usuário com um
interpretador de comandos válido em seu sistema (ou até mesmo um intruso que
comprometeu o sistema através de um serviço) pode usar a quantidade de CPU,
memória, pilhas, etc. que o sistema puder fornecer. Este problema de
exaustão de recursos pode somente ser corrigido com o uso de PAM.
Note que lá existe um método para adicionar limitação de recursos para alguns
interpretadores de comandos (por exemplo, o bash
possui
ulimit
, veja bash(1)
), mas nem todos os
interpretadores oferecem as mesmas limitações e também o usuário pode mudar seu
shell (veja chsh(1)
). Então é melhor colocar as limitações nos
módulos do PAM.
Mais detalhes podem ser lidos em:
Tornando
o Linux mais seguro passo a passo
na seção Limitando a visão dos
usuários.
LASG
na seção
Limitando e monitorando usuários.
FIXME: Colocar um belo limits.conf
acima deste local
/etc/login.defs
O próximo passo é editar a configuração e ação básica que será feita após o
login do usuário. Note que este arquivo não é parte da configuração do PAM, é
um arquivo de configuração lido pelos programas login e
su, assim não faz sentido configurá-lo para casos onde nem um dos
programas são indiretamente chamados (o programa getty
que é
executado através do console e requer login e senha, executa o
login
).
FAIL_DELAY 10
Esta variável deve se ajustada para um valor alto para tornar difícil ataques brute force através de tentativas de logon no terminal. Caso uma senha incorreta seja digitada, o possível atacante (ou o usuário normal!) terá que aguardar 10 segundos para obter um novo aviso de login, que é bastante tempo quando se utiliza programas automatizados para esta tarefa.
FAILLOG_ENAB yes
Se ativar esta variável, as falhas nas tentativas de login serão registradas. É importante mantê-las para pegar alguém que tente fazer um ataque brute force.
LOG_UNKFAIL_ENAB yes
Se ajustar a variável FAILLOG_ENAB para yes, então você deverá também ajustar esta variável para yes. Isto gravará nomes de usuários desconhecidos caso o login falhar. Se fizer isto, tenha certeza que os logs tenham permissões corretas (640 por exemplo, com a configuração apropriada de grupo tal como adm), pois os usuários podem acidentalmente entrar com suas senhas como se fossem nomes de usuários e você não desejará que outros as vejam.
SYSLOG_SU_ENAB yes
Isto somente permite que sejam registradas tentativas do uso de su
no syslog
. Muito importante em máquinas em produção, mas note que
isto pode criar também problemas de privacidade.
SYSLOG_SG_ENAB yes
O mesmo que SYSLOG_SU_ENAB mas se aplica ao programa
sg
.
MD5_CRYPT_ENAB yes
Como mencionado acima, as senhas em MD5 reduzem fortemente o problema de ataques de dicionário, pois você poderá usar senhas grandes. Se estiver usando a versão slink, leia os documentos sobre MD5 antes de ativar esta opção. Caso contrário, isto é definido no PAM.
PASS_MAX_LEN 50
Caso senhas MD5 sejam ativadas em sua configuração do PAM, então esta variável deverá ter o mesmo valor da que é usada lá.
/etc/ftpusers
O arquivo /etc/ftpusers
contém uma lista de usuários que não podem
logar no sistema usando ftp. Somente use este arquivo se você realmente deseja
permitir ftp (que não é recomendado em geral, pois utiliza autenticação de
senhas em texto plano). Caso seu daemon suporta PAM, você poderá também usá-lo
para permitir e bloquear usuários para certos serviços.
FIXME (BUG): É m bug que o arquivo ftpusers
padrão no Debian
não inclua todos os usuários administrativos (do
base-passwd
).
Se você realmente precisa que os usuários se tornem superusuário em seu
sistema, e.g. para instalar pacotes ou adicionar usuários, você pode usar o
comando su
para alterar sua identidade. Você deverá tentar evitar
se logar como usuário root, usando o su
ao invés disto.
Atualmente a melhor solução é remover o su
e utilizar os
mecanismos do sudo
que tem uma lógica mais geral e mais
características que o su
. No entanto, o su
é mais
comum e é usado em muitos outros sistemas Unix.
O programa sudo
permite ao usuário executar comandos definidos com
outra identidade de usuário, até mesmo como usuário root. Se o usuário for
adicionado ao arquivo /etc/sudoers
e se autenticar corretamente,
ele será capaz de executar comandos que foram definidos no
/etc/sudoers
. Violações, tais com senhas incorretas ou tentativa
de executar um programa que não tem permissões, são registradas e enviadas para
o usuário root.
Você deverá modificar o /etc/security/access.conf
para bloquear
logins remotos para contas administrativas. Desta forma, usuários precisarão
executar o su
(ou sudo
) para usar qualquer poder
administrativo e traços para auditoria apropriada sempre serão gerados.
Você precisará adicionar a seguinte linha no arquivo
/etc/security/access.conf
, o arquivo padrão de configuração do
Debian tem a linha de exemplo comentada:
-:wheel:ALL EXCEPT LOCAL
Lembre-se de ativar o módulo pam_access para cada serviço (ou
configuração padrão) em /etc/pam.d/
se quiser que suas alterações
em /etc/security/access.conf
sejam mantidas.
Algumas vezes você deve pensar que precisa ter seus usuários criados em seu sistema local para oferecer acesso a um determinado serviço (serviço de mensagens pop3 ou ftp). Antes de fazer isto, primeiro lembre-se que a implementação do PAM no Debian GNU/Linux lhe permite validar usuários em uma grande variedade de serviços de diretório externos (radius, ldap, etc.) através dos pacote libpam.
Caso os usuários precisem ser criados e o sistema poderá ser acessado
remotamente, tenha em mente que os usuários poderão ser capazes de se logar no
sistema. Você poderá corrigir isto dando aos usuários um shell nulo
(/dev/null
) (ele não precisará estar listado no arquivo
/etc/shells
). Se deseja permitir aos usuários acessar o sistema
mas com seus movimentos limitados, você poderá usar o /bin/rbash
,
que é equivalente a adicionar a opção -r ao bash
(RESTRICTED SHELL veja bash(1)
). Por favor observe que
até mesmo em um shell restrito, um usuário pode acessar um programa interativo
(que pode permitir a execução de um subshell) e poderá pular as limitações do
shell.
O Debian atualmente fornece em sua versão instável (e poderá ser incluída em
uma futura versão estável) do módulo pam_chroot
(no pacote
libpam-chroot
). Uma alternativa a ele é o chroot
o
serviço que fornece log remoto (ssh
, telnet
).[13]
Se você deseja restringir quando seus usuários podem acessar o
sistema, você deverá personalizar o /etc/security/access.conf
a
suas necessidades.
Informações sobre como fazer chroot
dos usuários acessando o
sistema através do ssh
é descrito em Ambiente chroot
para
SSH
, Apêndice G.
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.
Você poderá usar o comando script
para auditar ambos o que os
usuários executam e quais são os resultados destes comandos.Não é possível
definir o script
como um interpretador de comandos (até mesmo se
ele for adicionado ao arquivo /etc/shells
). Mas você poderá ter o
arquivo de inicialização do shell executando o seguinte:
umask 077 exec script -q -a "/var/log/sessions/$USER"
É claro, se você fizer isto de forma que afete todo o sistema, significa que o
shell não continuará lendo arquivos de configurações pessoais (pois ele será
substituído pelo script
). Uma alternativa é fazer isto nos
arquivos de inicialização do usuário (mas então o usuário poderá removê-la,
veja os comentários sobre isto abaixo)
Você também precisa ajustar os arquivos no diretório de auditoria (no exemplo
/var/log/sessions/
) assim os usuários poderão gravar para ele, mas
não poderão remover o arquivo. Isto pode ser feito, por exemplo, criando os
arquivos de seção de usuário antecipadamente e definindo a opção
append-only usando o chattr
.
Uma alternativa útil para administradores de sistemas, que inclui informações sobre data, pode ser:
umask 077 exec script -q -a "/var/log/sessions/$USER-`date +%Y%m%d`"
Se deseja rever o que o usuário está digitando no seu shell (mas não se sabe
qual seu resultado) você poderá configurar um /etc/profile
para
todo o sistema que configura o ambiente de forma que todos os comandos são
salvos em um arquivo de histórico. A configuração de todo o sistema precisa
ser feita de forma que os usuários não possam remover as capacidades de
auditoria em seu shell. Isto muitas vezes é específica de cada shell assim
tenha certeza que todos os usuários estão utilizando um shell que suporte isto.
Por exemplo, para o bash, o /etc/profile
deverá ser ajustado da
seguinte forma [14] :
HISTFILE=~/.bash_history HISTSIZE=10000 HISTFILESIZE=999999 # Don't let the users enter commands that are ignored # in the history file HISTIGNORE="" HISTCONTROL="" readonly HISTFILE readonly HISTSIZE readonly HISTFILESIZE readonly HISTIGNORE readonly HISTCONTROL export HISTFILE HISTSIZE HISTFILESIZE HISTIGNORE HISTCONTROL
Para isto funcionar, o usuário poderá somente adicionar dados ao
.bash_history
. Você também precisará ajustar a opção
append-only usando o programa chattr
para o
.bash_history
de todos os usuários. [15].
Note que você poderá introduzir as configurações acima no arquivo
.profile
do usuário. Mas então você precisará ajustar permissões
adequadamente de tal forma que isto prevenirá que o usuário modifique este
arquivo. Isto inclui: ter os diretórios home dos usuários não
pertencendo ao usuário (pois ele seria capaz de remover o arquivo) mas da mesma
forma permitir ler o arquivo de configuração .profile
e gravar no
.bash_history
. Seria bom ajustar a opção imutável
(usando também o chattr
) também para o .profile
se
fizer desta forma.
O exemplo anterior é um método simples de se configurar a auditoria do usuário,
mas pode não ser útil para sistemas complexos ou para este em que os usuários
não precisam executar um shell (de forma exclusiva). Neste caso, você
precisará dar uma olhada no pacote acct
, que contém ferramentas de
contabilização. Estes utilitários registrarão todos os comandos executados
pelos usuários ou por processos no sistema, ao custo de espaço em disco.
Quando ativar a contabilização, todas as informações sobre processos e usuários
são mantidas sob /var/account/
, mais especificamente em
pacct
. O pacote de contabilização inclui algumas ferramentas como
(sa
, ac
e lastcomm
) para realizar a
análise destes dados.
Se você for completamente paranóico e deseja auditar cada comando do usuário,
você deverá pegar o código fonte do bash
, editá-lo e assim ter ele
enviando tudo o que o usuário digitar para outro arquivo. Ou ter o pacote
ttysnoop
monitorando constantemente qualquer novo ttys [16] e gravar sua saída para um
arquivo. Outro programa útil é o snoopy
(veja também the project
page
) que é um programa transparente ao usuário que trabalha em cima
de uma biblioteca fornecendo um gancho nas chamadas execve(),
qualquer comando executado é registrado no syslogd
usando a
facilidade authpriv (normalmente armazenada em
/var/log/auth.log
).
Se deseja ver o que os usuários estão atualmente fazendo quando entram
no sistema você poderá usar o banco de dados wtmp
que inclui todas
as informações de login. Este arquivo pode ser processado por vários
utilitários, entre eles o sac
que pode enviar como saída um perfil
sobre cada usuário mostrando o intervalo de tempo que eles geralmente entram no
sistema.
No caso de ter a contabilização ativada, você também poderá usar as ferramentas fornecidas por ele para ser capaz de determinar quando os usuários acessam o sistema e o que eles executam.
Dependendo de sua política de usuários você pode querer alterar como as
informações são compartilhadas entre os usuários, o que significa, o que cada
permissão padrão permite. Esta alteração é feita definindo uma configuração
apropriada de umask para todos os usuários. Você poderá alterar a
configuração de UMASK no arquivos /etc/limits.conf
,
/etc/profile
, /etc/csh.cshrc
,
/etc/csh.login
, /etc/zshrc
e provavelmente em alguns
outros (dependendo do tipo de shell que tem instalado em seu sistema). De
todos estes, o último executado tem preferência. A ordem é:
limits.conf
do PAM, o padrão de configuração do sistema para o
shell do usuário, o shell do usuário(seu ~/.profile
,
~/.bash_profile
...)
A configuração padrão de umask no Debian é 022 isto
significa que o arquivo (e diretórios) podem ser lidos e acessados pelo grupo
de usuário e por outros usuários no sistema. Se isto é muito permissivo para o
sistema você terá que ajustar a configuração de umask para todos os shells (e
para o PAM). Não se esqueça de modificar os arquivos sob
/etc/skel/
pois estes se tornarão os novos padrões do sistema
quando criados pelo comando adduser
.
Note, no entanto que os usuários podem modificar sua própria configuração de umask se desejarem, torná-la mais permissiva ou mais restritiva.
FIXME: É necessário mais conteúdo. Falar das consequências de alterar as
permissões de pacotes quando atualiza o sistema (e administração desta paranóia
deverá ser através de chroot
em seus usuários).
Se você precisa garantir acesso dos seus usuários ao sistema usando um interpretador de comandos, pense sobre isto muito cuidadosamente. Um usuário pode por padrão, a não ser que esteja em um ambiente severamente restrito (como uma jaula chroot), obter muitas informações sobre o seu sistema, incluindo:
alguns arquivos de configuração em /etc
. 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 find /etc -type f -a -perm 600 -a -uid
0.
você instalou pacote, ou vendo no banco de dados de pacotes, ou no diretório
/usr/share/doc
ou adivinhando olhando nos binários e bibliotecas
instalados em seu sistema.
alguns arquivos de registro em /var/log
. Também note que alguns
arquivos de registro somente são acessíveis aos usuários root e grupo
adm (tente executar find /var/log -type f -a -perm
640) e alguns são somente disponíveis ao usuário root (tente executar
find /var/log -type f -a -perm 600 -a -uid 0).
O que um usuário pode ver em seu sistema? Provavelmente muitas coisas, tente isto (faça uma breve parada):
find / -type f -a -perm +006 2>/dev/null find / -type d -a -perm +007 2>/dev/null
A saída mostra a lista de arquivos que um usuário pode ver e os diretórios que ele tem acesso.
Se você ainda permite acesso a shell para os usuários você deverá querer limitar que informações eles podem ver de outros usuários. Os usuários com acesso a shell têm a tendência de criar um número de arquivos dentro do seu diretório pessoal: caixas de correio, documentos pessoais, configurações de aplicativos do X/GNOME/KDE...
No Debian, cada usuário é criado com um grupo associado e nunca dois usuários pertencerão ao mesmo grupo. Este é o comportamento padrão: quando uma conta de usuário é criada, um grupo com o mesmo nome também é criado, e o usuário é adicionado a ele. Isto evita o conceito do grupo users compartilhado, que torna mais difícil aos usuários ocultarem informações de outros.
No entanto, os diretórios de usuários em $HOME são criados com permissões 0755 (lido pelo grupo e por todos). As permissões de grupo não são críticas pois somente o usuário pertence ao grupo, no entanto as permissões de todos os outros pode (ou não) ser um problema dependendo de sua política local.
Você poderá alterar este comportamento, assim a criação de usuários oferecerá
uma permissão diferente em $HOME. Para alterar o comportamento para
novos usuários quando forem criados, altere DIR_MODE no
arquivo de configuração /etc/adduser.conf
para 0750 (sem acesso de
leitura para todos).
Os usuários ainda poderão compartilhar informações mas não diretamente em seus diretórios $HOME, a não ser que eles mudem suas permissões.
Note que a desativação de leitura para todos em diretórios de usuários evitará
que os usuários criem suas páginas pessoais no diretório
~/public_html
, pois o servidor web não será capaz de ler um
componente no path - seu diretório $HOME. Se deseja permitir aos
usuários publicar páginas HTML em seus diretórios
~/public_html
,então altere DIR_MODE para 0751. Isto
permitirá o servidor web acessar o diretório final public_html
(que terá por si próprio a permissão) e oferecerá o conteúdo publicado pelos
usuários. É claro, nós estamos somente falando aqui sobre uma configuração
padrão; os usuários podem geralmente ajustar os modos de seus próprios arquivos
completamente a seu gosto, ou você poderá manter o conteúdo que tem a intenção
de publicação na web em um diretório separado que não seja um subdiretório do
diretório de usuário $HOME.
Existem muitos casos quando um administrador precisa criar muitas contas de
acesso de usuários e fornece senhas a a todas elas. É claro, o administrador
poderia somente ajustar a senha para ser a mesma da conta de usuário, mas isto
não seria uma atitude muito segura. Uma alternativa melhor é gerar um programa
gerador de senhas. O Debian oferece os pacotes makepasswd
,
apg
e pwgen
que contém programas (o nome do programa
é o mesmo do pacote) que podem ser usados para este propósito. O
makepasswd
gerará senhas aleatórias reais com uma ênfase em
segurança até mesmo na pronunciabilidade, enquanto o pwgen
tentará
criar senhas pronunciáveis (é claro que isto dependerá de sua língua mãe). O
apg
tem algorítmos para oferecer ambos (existe uma versão
cliente/servidor deste programa mas não está incluída no pacote do Debian).
O passwd
não permite que uma senha seja definida de forma
interativa (pois ele utiliza acesso direto a tty). Se deseja alterar senhas
quando cria um grande número de usuários, você poderá criá-las usando o
adduser
com a opção --disabled-login e então usar o
usermod
ou chpasswd
[17] (ambos vêm no pacote
passwd
assim você já os terá instalados). Se desejar usar um
arquivo com todas as informações dos usuários como um processo não interativo,
será melhor usar o newusers
.
Senhas de usuários podem algumas vezes ser o ponto vulnerável na
segurança de um determinado sistema. Isto é devido ao fato de que alguns
usuários escolherem senhas fracas para suas contas (e quanto mais deles têm
acesso ao sistema, maiores as chances disto acontecer). Até mesmo se você
estabelecer checagens com o módulo cracklib do PAM e limitações de senhas como
descrito em Autenticação do Usuário: PAM, Seção
4.10.1 os usuários ainda serão capazes de usar senhas simples. Pois o
acesso a usuários remotos pode incluir acesso a um shell remoto (felizmente
sobre ssh
) tornando possível deduzir a senha mais difícil para
invasores remotos. Especialmente se eles são capazes de coletar informações
importantes, tais como nomes de usuários e até dos próprios arquivos
passwd
e shadow
.
Um administrador de sistema deverá, dado um grande número de usuários,
verificar se a senha que eles têm são consistentes com a política local de
segurança. Como verificar? Tente quebrá-las assim como um invasor faria se
ele tivesse acesso ao hash de senhas (o arquivo /etc/shadow
).
Um administrador poderia usar o john
ou crack
(ambos
crackers de senhas força bruta) juntos com um dicionário apropriado para
procurar senhas de usuários e ter um plano de ação quando uma senha fraca for
detectada. Você pode procurar por pacote Debian que contém lista de palavras
de dicionário usando apt-cache search wordlist
ou visitando os
sites clássicos de pesquisas de dicionário tais como ftp://ftp.ox.ac.uk/pub/wordlists
ou ftp://ftp.cerias.purdue.edu/pub/dict
.
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:
porque o console do usuário pode ser destravado e pode ser acessado por um intruso.
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 telnet
).
Alguns sistemas remotos podem ter sido comprometidos através de uma
screen
inativa (ou desconectada).
A desconexão automática de usuários idle é geralmente parte da política local de segurança que deve ser forçada. Existem várias formas de se fazer isto:
Caso o interpretador de comandos do usuário seja o bash
, o
administrador do sistema poderá definir um valor para a variável
TMOUT (veja bash(1)
) que fará o shell deslogar os
usuários inativos automaticamente. Note que ela deverá ser definida com a
opção -o ou os usuários serão capazes de alterá-la (ou
desativá-la).
Instale o timeoutd
e configure /etc/timeouts
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.
Instale o autolog
e o configure para remover usuários inativos.
Os daemons timeoutd
ou autolog
são os métodos
preferidos, pois, após tudo, os usuários podem alterar seu shell padrão ou
podem alterar para um outro shell que não possua tais controles.
Os TCP wrappers foram desenvolvidos quando não existiam filtros de pacotes
disponíveis e eram necessários controle de acesso. Mesmo assim, eles ainda são
muito interessantes e úteis. Com os TCP wrappers é possível permitir ou negar
um serviço para uma máquina ou domínio e definir uma regra padrão também para
permitir ou negar (tudo feito a nível de aplicação). Se desejar mais
informações, dê uma olhada em hosts_access(5)
.
Muitos dos serviços instalados no Debian são executados de duas formas:
carregados através do serviço tcpwrappers (tcpd
)
compilados com o suporte a libwrapper embutido
De um lado, para serviços configurados no /etc/inetd.conf
(isto
inclui o telnet
, ftp
, netbios
,
swat
e finger
) você verá que o arquivo de
configuração executa primeiro o /usr/sbin/tcpd
. De outro lado,
até mesmo se um serviço não for carregado pelo superdaemon inetd
,
o suporte a regras do tcp wrappers pode ser compilado nele. Os serviços
compilados com o tcp wrappers no Debian incluem o ssh
,
portmap
, in.talk
, rpc.statd
,
rpc.mountd
, gdm
, oaf
(o daemon ativador
do GNOME), nessus
e muitos outros.
Para ver que pacotes usam o tcpwrappers, execute:
$ apt-cache showpkg libwrap0 | egrep '^[[:space:]]' | sort -u | \ sed 's/,libwrap0$//;s/^[[:space:]]\+//'
Leve isto em conta quando executar o tcpdchk
(um verificar de
sintaxe e regras de arquivos muito útil que vem com o TCP wrappers). Quando
adicionar serviços stand-alone (que são ligados diretamente com a biblioteca
wrapper) nos arquivos hosts.deny
e hosts.allow
, o
tcpdchk
deverá te alertar que não é capaz de encontrar o serviço
mencionado pois ele somente procura por eles no arquivo
/etc/inetd.conf
(a página de manual não é totalmente precisa com
relação a este ponto).
Agora, vem uma pequena dica, e provavelmente o menor sistema de detecção de
intrusão disponível. Em geral, você deverá ter uma política de firewall
decente como primeira linha e o tcp wrappers como segunda linha de defesa. Um
pequeno truque é configurar um comando SPAWN [18], no arquivo
/etc/hosts.deny
que envia uma mensagem para o root assim que for
tentado acesso a um serviço negado:
ALL: ALL: SPAWN ( \ echo -e "\n\ TCP Wrappers\: Connection refused\n\ By\: $(uname -n)\n\ Process\: %d (pid %p)\n\ User\: %u\n\ Host\: %c\n\ Date\: $(date)\n\ " | /usr/bin/mail -s "Conexão bloqueada para %d" root) &
Cuidado: O exemplo impresso acima é aberto a um ataque DoS fazendo muitas conexões em um curto período de tempo. Muitos e-mails significam muito I/O de arquivos pelo envio de poucos pacotes.
É fácil ver que o tratamento de mensagens de logs e alertas é um assunto importante em um sistema seguro. Suponha que um sistema está perfeitamente configurado e é 99% seguro. Se a probabilidade de 1% do ataque ocorrer e não existir medidas de segurança no lugar, para primeiro detectar e segundo disparar alarmes, o sistema não estará bem seguro.
O Debian GNU/Linux fornece algumas ferramentas que fazem análise de logs, mais
notavelmente swatch
, [19] logcheck
ou log-analysis
(todos
precisarão de algumas personalizações para que coisas desnecessárias sejam
removidas do relatório). Também pode ser útil, se o sistema estiver
visivelmente próximo, ter as mensagens do sistema mostradas em um console
virtual. Isto é útil, pois você pode (através de certa distância) ver se o
sistema está se comportando adequadamente. O /etc/syslog.conf
do
Debian vem com uma configuração padrão comentada; para ativá-la, descomente as
linhas e reinicie o syslogd
(/etc/init.d/syslogd
restart):
daemon,mail.*;\ news.=crit;news.=err;news.=notice;\ *.=debug;*.=info;\ *.=notice;*.=warn /dev/tty8
Para tornar os logs coloridos, você deverá dar uma olhada nos pacotes
colorize
, ccze
ou glark
. Existe muita
coisa sobre análise de logs que não poderá ser coberta aqui, assim uma boa
fonte de informações pode ser o site Log Analysis
. Em qualquer caso,
até mesmo ferramentas automatizadas não batem a melhor ferramenta de análise:
seu cérebro.
logcheck
O pacote logcheck
no Debian é dividido em três pacotes:
logcheck
(o programa principal), logcheck-database
(um banco de dados de expressões regulares de um programa) e
logtail
(mostra linhas de logs que ainda não foram lidas). O
padrão do Debian (em /etc/cron.d/logcheck
) é executar o
logcheck
a cada hora e após reinicializações.
Esta ferramenta pode ser muito útil se personalizada adequadamente para alertar
ao administrador de eventos estranhos. O Logcheck
pode ser
totalmente personalizado assim enviará mensagens baseadas em eventos
encontrados nos logs e passíveis de atenção. A instalação padrão inclui perfis
para eventos ignorados e violações de políticas para três diferentes
configurações (workstation, server e paranoid). O pacote do Debian inclui um
arquivo de configuração /etc/logcheck/logcheck.conf
, instalado
pelo programa, que define que usuário receberá as verificações. Ele também
oferece um método para os pacotes que fornecem serviços para implementar novas
políticas nos diretórios: /etc/logcheck/cracking.d/_packagename_
,
/etc/logcheck/violations.d/_packagename_
,
/etc/logcheck/violations.ignore.d/_packagename_
,
/etc/logcheck/ignore.d.paranoid/_packagename_
,
/etc/logcheck/ignore.d.server/_packagename_
e
/etc/logcheck/ignore.d.workstation/_packagename_
. No entanto, são
poucos os pacotes que fazem isto. Se tiver uma política que pode ser útil para
outros, por favor envie-a como relatório de falha para o pacote apropriado
(como um bug wishlist). Para mais informações, leia
/usr/share/doc/logcheck/README.Debian
.
O melhor método de configurar o logcheck
é editar seu arquivo
principal de configuração /etc/logcheck/logcheck.conf
após a
instalação. Altere o usuário padrão (root) para quem o relatório deverá ser
enviado. Você deverá ajustar o nível de relatório lá também. O pacote
logcheck-database
possui três níveis de relatório para aumentar o
detalhamento: workstation, server e paranoid. "server" (servidor) é
o nível padrão, paranoid (paranóico) é somente recomendado para máquinas de
alta segurança executando poucos serviços quanto forem possíveis e workstation
(estação de trabalho) para máquinas relativamente não críticas. Se desejar
adicionar novos arquivos de logs, adicione-os em
/etc/logcheck/logcheck.logfiles
. Ele é ajustado para a instalação
padrão do syslog.
Assim que isto for feito, você deverá olhar se os e-mails são enviados, durante
os primeiros dias/semanas/meses. Se você achar que estão sendo enviadas
mensagens que não deseja receber, apenas adicione as expressões regulares (veja
regex(7)
e egrep(1)
) que correspondem a estas
mensagens em /etc/logcheck/ignore.d.reportlevel/local
.
tente conferir com toda a linha de log. Detalhes sobre como escrever regras
estão explicados em
/usr/share/doc/logcheck-database/README.logcheck-database.gz
. É
um processo de ajuste fino constante; assim que as mensagens que são enviadas
são sempre importantes, você deverá considerar este tunning finalizado. Note
que se o logcheck
não encontrar nada importante em seu sistema,
ele não enviará um e-mail para você mesmo se ele for executado (assim se você
obtiver somente um e-mail por semana, considere-se uma pessoa de sorte).
O Debian vem com uma configuração padrão do syslog (em
/etc/syslog.conf
) que registra mensagens em arquivos apropriados
dependendo da facilidade do sistema. Você deverá estar familiarizado com isto;
dê uma olhada no arquivo syslog.conf
e na documentação caso não
estiver registrando. Se você tem a intenção de manter um sistema seguro você
deverá se atentar aonde as mensagens de log são enviadas, assim elas não
passarão desapercebidas.
Por exemplo, o envio de mensagens para o console também é uma configuração interessante para muitos sistemas a nível de produção. Mas para muitos do sistemas também é importante adicionar uma nova máquina que servirá de servidor de logs (i.e. ela receberá os logs de todos os outros sistemas).
Os e-mails enviados para o root também deverão ser considerados, muitos
controles de segurança (como o snort
) enviam alertas para a caixa
de correios do root. Esta caixa de correios normalmente aponta para o primeiro
usuário criado no sistema (verifique no /etc/aliases
). Tenha
atenção de enviar as mensagens do root para algum lugar onde sejam lidas (ou
localmente ou remotamente).
Existem outras contas e aliases em seu sistema. Em um sistema pequeno, é provavelmente o método mais simples de ter certeza que todos estes aliases apontam para a senha de root, e aquele e-mail do root é redirecionado para a caixa de mensagens pessoal do administrador do sistema.
FIXME: seria interessante em falar como um sistema Debian pode enviar/receber
traps SNMP relacionado a problemas de segurança (jfs). Checar:
snmptraglogd
, snmp
e o snmpd
.
Um servidor de logs é uma máquina que coleta dados do syslog remotamente
através da rede. Se uma de suas máquinas for comprometida, o intruso não será
capaz de cobrir seus rastros, a não ser que ataque também o servidor de logs.
Assim, esta máquina deverá estar especialmente segura. Fazer uma máquina de
loghost é simples. Apenas inicie o syslogd
com a opção
syslogd -r e um novo servidor de logs nasce. Para tornar isto
permanentemente na Debian, edite o arquivo /etc/init.d/sysklogd
e
adicione a linha
SYSLOGD=""
to
SYSLOGD="-r"
Em seguida, configure as outras máquinas para enviar dados para o servidor de
logs. Adicione uma entrada como a seguinte no arquivo
/etc/syslog.conf
:
facility.level @your_loghost
Veja a documentação sobre o que pode ser usado no lugar de facility e level (eles não devem ser usados na configuração que foi mostrada). Se quiser registrar tudo remotamente, apenas escreva:
*.* @your_loghost
em seu arquivo syslog.conf
. O log remoto, assim como o local, é a
melhor solução (o intruso pode presumir que cobriu seus rastros após apagar os
arquivos de log locais). Veja as páginas de manual syslog(3)
,
syslogd(8)
e syslog.conf(5)
para informações
adicionais.
Não só é importante decidir como os alertas são usados, mas também quem tem acesso a leitura/modificação dos arquivos de histórico (caso não estiver usando um servidor de logs remoto). Não é difícil alterar ou desativar os alertas de segurança em um evento de intrusão. Você também deverá levar em conta que os arquivos de histórico podem revelar muitas informações sobre o sistema para um intruso caso ele tenha acesso a eles.
Algumas permissões de arquivos de log não são ideais após a instalação (mas é
claro, isto depende da política de segurança local do sistema). Primeiro, os
arquivos /var/log/lastlog
e /var/log/faillog
não
precisam ser lidos por usuários normais. No arquivo lastlog
você
pode ver quem entrou recentemente no sistema e no arquivo faillog
terá um resumo de logins que falharam. O autor recomenda fazer um chmod
660
para ambos. De uma breve olhada em seus arquivos de log e decida
cuidadosamente que arquivos de logs deverão se tornar legíveis para um usuário
com um UID diferente de 0 e um grupo que não sejam 'adm' ou 'root'. Você
deverá facilmente verificar isto em seu sistema com:
# find /var/log -type f -exec ls -l {} \; | cut -c 17-35 |sort -u (procura que usuários os arquivos em /var/log pertencem) # find /var/log -type f -exec ls -l {} \; | cut -c 26-34 |sort -u (procura que grupos os arquivos em /var/log pertencem) # find /var/log -perm +004 (procura que arquivos são lidos por qualquer usuário) # find /var/log \! -group root \! -group adm -exec ls -ld {} \; (procura por arquivos que não pertencem ao grupo root ou adm)
Para personalizar a forma que os arquivos de log são criados, você provavelmente terá que personalizar o programa que os gera. Se os arquivos de log forem rotacionados, no entanto, você poderá personalizar o comportamento do rotacionamento e da criação.
O Debian GNU/Linux oferece alguns dos patches para o kernel do Linux que aumentam sua segurança. Estes incluem:
Detecção de Intrusão no Linux (no pacote lids-2.2.19
), 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
http://www.lids.org
Listas de Controle de Acessos POSIX (ACLs) para Linux (no pacote
kernel-patch-acl
). 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: http://acl.bestbits.at/
Linux Trustees (no pacote trustees
). 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: http://trustees.sourceforge.net/
NSA Enhanced Linux (no pacote selinux
também disponível de
the developer's
website
)
kernel-patch-2.2.18-openwall
, por Solar Designer. Este contém um
conjunto útil de restrições do kernel, como links restritos, FIFOs em
/tmp
, um sistema de arquivos /proc
restrito,
manipulação especial de descritores de arquivos, área não executável de pilha
do usuário e outras. Página: http://www.openwall.com/linux/
kernel-patch-2.4-grsecurity
: O patch do Grsecurity [20] implementa Controle de
Acesso Mandatário, oferece proteção contra estouro de buffer, ACLs, network
randomness (para tornar OS fingerprint mais difícil) e muito mais
características
.
kernel-patch-2.2.19-harden
. FIXME Adicionar conteúdo.
suporte a kernel IPSEC (no pacote kernel-patch-freeswan
). 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: http://www.freeswan.org
.
FIXME: Os últimos kernels 2.4 contidos no Debian incluem o backport do
código ipsec do kernel 2.5. Comente sobre isto
cryptoapi-core-source
. 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 Nota: este pacote não existe em
lançamentos do Debian antes da Sarge
. Homepage:
http://www.kerneli.org/
cryptoloop-source
. Este patch lhe permite usar as funções do
pacote cryptoapi-core-source
para criar sistemas de arquivos
criptografados usando o dispositivo de loopback.
kernel-patch-int
. 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
cryptoapi-core-source
.
FIXME: adicionar mais conteúdo, explicar como estes patches específicos podem ser instalados no Debian usando os pacotes do kernel kernel-2.x.x-patch-XXX.
FIXME: Dividir patches que se aplicam somente nos kernels 2.2, patches que se aplicam nos kernels 2.4 e os que funcionam com ambos.
No entanto, alguns patches ainda não foram adicionados ainda no Debian. Se
sentir que alguns destes devem ser incluídos, por favor pergunte por ele em
Work Needing and Prospective
Packages
. Alguns destes pacotes são:
SubDomain. 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 chroot
, ele clama ser de fácil construção e mais flexível
que um ambiente chroot
.
Contexts (ctx) patch. Uma extensão do kernel feita para implementar
servidores privados virtuais. É parecido com o jail
no BSD.
Homepage: http://www.immunix.org/subdomain.html
UserIPAcct. 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: http://ramses.smeyers.be/useripacct
.
O estouro de buffer (buffer overflow) é o nome de um comum ataque a softwares [21] que faz o uso de checagem insuficiente de limites (um erro de programação, mais comum na linguagem C) para executar o código de máquina através de entrada de programas. Estes ataques, contra programas de servidores que escutam conexões remotamente ou contra softwares locais que garantem altos privilégios aos usuários (setuid ou setgid) podem resultar no comprometimento de qualquer sistema determinado.
Existem basicamente quatro métodos de se proteger contra estouro de buffer:
aplicar um patch no kernel para prevenir a execução da pilha (você pode usar os patches OpenWall ou Grsecurity)
usar uma biblioteca, tal como a libsafe
,
para substituir funções vulneráveis e introduzir a checagem apropriada (para
informações sobre como instalar a libsafe
leia isto
).
corrigir o código fonte usando ferramentas para encontrar fragmentos de onde pode introduzir esta vulnerabilidade.
recompilar o código fonte para adicionar checagens apropriadas que previnem
buffer overflows, usando, por exemplo, StackGuard
(que é
usado pelo Immunix
) ou o
patch Stack Smashing
Protector (SSP)
para o GCC (que é usado pelo Adamantix
)
O Debian GNU/Linux em seu lançamento 3.0, fornece software para introduzir
todos estes métodos exceto a proteção de compilação do código fonte (mas isto
foi requisitado no Bug
#213994
)
Note que até mesmo se o Debian fornecer um compilador que possua proteção contra estouro de pilha/buffer, todos os pacotes precisariam ser recompilados para introduzir esta característica. Isto é, de fato, o que o Adamantix faz (entre outras características). O feito desta nova característica na estabilidade do software é algo que deverá ser determinado (alguns programas ou arquiteturas de processador podem ter problemas com seu uso).
Em qualquer caso, esteja alerta que até mesmo estas alternativas podem não
prevenir buffer overflows, pois existem formas de burlá-los, como descrito na
revista phrack's issue
58
ou no aviso CORE's Múltiplas
vulnerabilidades nas tecnologias de proteção de pilha
.
Os patches do kernel relacionados a estouro de buffer incluem o patch Openwall
que oferece proteção contra buffer overflows nos kernels do Linux 2.2. Para
kernels 2.4 ou superiores, utilize o patch Grsecurity (existente no pacote
kernel-patch-2.4-grsecurity
) que inclui o patch do Openwall e
muito mais características
(incluindo ACLs e métodos de rede que dificultam a realização de OS
fingerprinting), ou os módulos de Segurança do Linux (nos pacotes
kernel-patch-2.4-lsm
e kernel-patch-2.5-lsm
). Para
mais informações sobre como usar estes patch leia a seção Adicionando patches no kernel, Seção 4.13.
Libsafe
A proteção do sistema Debian GNU/Linux com a libsafe
é bastante
fácil, apenas instale o pacote e diga Sim para ter a biblioteca pré
carregada globalmente. Tenha cuidado, no entanto, pois isto pode quebrar
alguns programas (notavelmente, programas compilados usando a antiga
libc5
, assim tenha certeza de ler os relatórios de falhas
reportadas
antes e testar os programas mais críticos em seu sistema
com o programa libsafe
.
Nota Importante: A proteção da Libsafe
pode não ser
efetiva atualmente como descrito em 173227
. Considere testá-la
antes de usá-la em um ambiente de produção e não dependa exclusivamente dela
para proteger seu sistema.
O uso de ferramentas para detecção de estouro de buffer requer, em qualquer
caso, conhecimento de programação para corrigir (e recompilar) o código. O
Debian contém, por exemplo: bfbtester
(um verificar de estouro de
buffer que faz ataques de força bruta em binários e estouro de ambiente) e o
njamd
. Outros pacotes de interesse podem também ser o
rats
, pscan
, flawfinder
e o
splint
.
Durante a administração normal do sistema, sempre são necessárias
transferências de arquivos de um sistema para outro. A cópia de arquivos de
maneira segura de um sistema para outro pode ser feita usando o pacote do
servidor sshd
. Outra possibilidade é usar o
ftpd-ssl
, um servidor ftp que faz uso da Camada de Conexões
Seguras para encriptar as transmissões.
Qualquer um destes métodos precisam de clientes especiais. O Debian fornece
programas clientes, como scp
no pacote ssh
, que
trabalha como o rcp
mas é completamente criptografada, assim os
maus meninos não poderão nem saber O QUE você copia. Também existe o
pacote ftp-ssl
para o servidor equivalente. Você poderá encontrar
clientes para estes softwares até mesmo para outros sistemas operacionais
(não-UNIX), o putty
e o winscp
fornecem
implementações de cópia segura para qualquer versão do sistema operacional da
Microsoft.
Note que o uso de scp
fornece acesso dos usuários a todos os
arquivos do sistema a não ser que esteja dentro de um chroot
como
descrito em Executando o ssh
em uma jaula chroot, Seção 5.1.1. O acesso FTP pode ser feito usando
chroot
, possivelmente mais fácil dependendo do daemon escolhido,
como descrito em Tornando o
FTP mais seguro, Seção 5.3. Se está preocupado sobre usuários navegando em
seus arquivos locais e deseja ter comunicação encriptada, você poderá usar um
daemon FTP com suporte a SSL ou combinar ftp texto plano com uma configuração
de VPN (veja Redes Privadas Virtuais
(VPN), Seção 8.5).
É importante se ter uma boa política de quotas, pois ela evita que os usuários ocupem todo o(s) disco(s) rígido(s).
Você poderá usar dois sistemas diferentes de quota: quota do usuário e quota do grupo. Você provavelmente notará que limites de quota de usuários definem o espaço que o usuário pode utilizar, a quota de grupo é equivalente para grupos. Mantenha isto em mente quando estiver trabalhando com tamanhos de quota.
Existem alguns pontos importantes que devem ser pensados sobre a configuração de um sistema de quotas:
Mantenha as quotas suficientemente pequenas, assim os usuários não poderão acabar com todo seu espaço em disco.
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.
Use quotas em todas as áreas graváveis por usuários, em /home
como
também em /tmp
.
Cada partição ou diretório no qual os usuários tem acesso completo a gravação deverão ter a quota ativada. Calcule e defina um tamanho de quota funcional para estas partições e diretórios que combinam utilização e segurança.
Assim, você deseja usar quotas. A primeira coisa que precisa checar, é se
ativou o suporte a quotas em seu kernel. Se não ativou, você terá que
recompilá-lo. Após isto, verifique se o pacote quota
está
instalado. Caso negativo, você terá que instalá-lo.
Ativar as quotas para um respectivo sistema de arquivos é muito fácil, bastando
modificar as configurações de defaults para
defaults,usrquota em seu arquivo /etc/fstab
. Se você
precisar de quota de grupo, substitua usrquota por
grpquota. Você também poderá usar ambos. Então crie os arquivos
vazios quota.user
e quota.group
no raiz do sistema de
arquivos que deseja ativar as quotas (e.g. touch /home/quota.user
/home/quota.group, para um sistema de arquivos /home
).
Reinicie o sistema de quota
executando /etc/init.d/quota
stop;/etc/init.d/quota start. Agora o sistema de quotas deverá estar
funcionando e os tamanhos de quotas poderão ser definidos.
A edição de quotas de um usuário específico poderá ser feita através de edquota -u <user>. As quotas de grupos podem ser modificadas com edquota -g <group>. Então ajuste a quota soft e hard e/ou quotas de inodes se necessário.
Para mais detalhes sobre quotas, leia a página de manual do quota, e o
mini-howto do quota
(/usr/share/doc/HOWTO/en-html/mini/Quota.html
).
Você pode ou não gostar do lshell
, pois ele viola a FHS. Também
tenha em mente que o pam_limits.so
pode fornecer a mesma
funcionalidade e lshell
está atualmente orfanado
Em adição as permissões atuais do Unix, os sistemas de arquivos ext2 e ext3
oferecem um conjunto de atributos específicos que lhe dão mais controle sobre
os arquivos em seu sistema. De forma contrária a permissões básicas, estes
atributos não são mostrados com o tradicional comando ls -l
ou
alterados usando-se o chmod
, e você precisará de dois utilitários
diferentes, o lsattr
e o chattr
(que estão no pacote
e2fsprogs
) para gerênciá-los. Note que isto significa que estes
atributos normalmente não serão salvos quando fizer o backup do seu sistema,
assim se alterar qualquer um deles, será um tormento salvar comandos
chattr
sucessivos em um script que será usado depois de ter
restaurado o backup.
Entre todos os atributos disponíveis, os dois abaixo são os mais importantes para aumentar a segurança e são referenciados pelas letras 'i' e 'a' e podem ser somente definidos (ou removidos) pelo superusuário:
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.
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 /var/log/
, assim você deverá
considerar que eles serão movidos sempre devido aos scripts de rotacionamento
de logs.
Estes atributos também podem ser definidos para diretórios, neste caso ninguém terá o direito de modificar o conteúdo de um diretório (eg. renomear ou excluir um arquivo, ...). Quando aplicado a um diretório, o atributo incremental permite somente a criação de arquivos.
É fácil ver porque o atributo 'a' aumenta a segurança, dando a programas que
não estão rodando sob o superusuário a capacidade de adicionar dados a um
arquivo sem modificar seu conteúdo anterior. Por outro lado, o atributo 'i'
parece ser menos interessante: depois de tudo, somente o superusuário poderá
usar as permissões básicas do Unix para restringir o acesso a um arquivo, e um
intruso que teria acesso a uma conta de superusuário poderia sempre usar o
programa chattr
para remover o atributo. Tal intruso ficara
primeiramente confuso quando se ver não ser capaz de remover um arquivo, mas
ele deverão não assumir que ele está blindado - acima de tudo, ele entrou no
seu sistema! Alguns manuais (incluindo a versão anterior deste documento)
sugerem remover os programas chattr
e lsattr
do
sistema para aumentar a segurança, mas este tipo de estratégia, conhecida
também por "segurança pela obscuridade", deve ser absolutamente
evitada, pois ela fornece uma falsa sensação de segurança.
Um método de resolver isto é usar as capacidades do kernel do Linux, como descrito em Defesa pró-ativa, Seção 9.4.2.1. A capacidade de interesse aqui é chamada CAP_LINUX_IMMUTABLE: se removê-la do conjunto de capacidades (usando por exemplo,o comando lcap CAP_LINUX_IMMUTABLE) não será possível alterar qualquer atributo 'a' ou 'i' em seu sistema, até mesmo pelo superusuário! Uma estratégia completa pode ser a seguinte:
Defina os atributos 'a' e 'i' nos arquivos que deseja;
Execute o comando lcap CAP_LINUX_IMMUTABLE (também como lcap CAP_SYS_MODULE, como sugerido em Defesa pró-ativa, Seção 9.4.2.1) a um dos scripts de inicialização;
Defina o atributo 'i' neste script e em outros arquivos de inicialização, assim
também como no próprio binário lcap
;
Execute manualmente o comando acima (ou reinicie o seu sistema para ter certeza que tudo funciona como planejado).
Agora que a capacidade foi removida do seu sistema, um intruso não poderá alterar qualquer atributo em arquivos protegidos, e assim não poderá alterar ou excluir os arquivos. Se ele forçar a máquina a reiniciar (que é o único método de restaurar o conjunto de capacidades), ele será facilmente detectado, e a capacidade será removida novamente assim que o sistema for reiniciado. O único método de alterar um arquivo protegido seria inicializar o sistema em modo monousuário ou usar outro disco de inicialização. Duas operações que requerem acesso físico a máquina!
Você tem certeza que o /bin/login
em seu disco rígido é ainda o
binário que instalou alguns meses atrás? Se ele for uma versão hackeada, que
armazena a senha que digitou em um arquivo oculto ou o envia por e-mails em
texto plano através da Internet?
O único método que tem algum tipo de proteção é verificar seus arquivos a cada
hora/dia/mês (eu prefiro diariamente) comparando o md5 do atual e do antigo.
Dois arquivos nunca têm o mesmo md5sum (o digest do MD5 é de 128 bits, assim a
chance de arquivos terem o mesmo md5sum é 3.4e3803), assim, você está do lado
seguro aqui, a não ser que alguém tenha hackeado o algoritmo que cria md5sums
em sua máquina. Isto é, bem, extremamente difícil e muito improvável. Você
realmente deverá considerar esta auditoria de seus binários como muito
importante, pois é um método fácil de reconhecer alterações. Ferramentas
padrões usadas para isto são sXid
, AIDE
(Ambiente
Avançado de Detecção de Intrusões), TripWire
,
integrit
e samhain
.
A instalação do debsums
ajudará a verificar a integridade do
sistema de arquivos, comparando o md5sum de cada arquivo com o md5sum usado no
arquivo de pacotes do Debian. Tenha cuidado, estes arquivos podem ser
facilmente alterados.
Você pode querer usar o locate
para indexar todo o sistema de
arquivos, se fizer isto, considere as implicações disto. O pacote
locate
no Debian é executado como usuário nobody, e assim ele
somente indexa arquivos que são visíveis para todos. No entanto, se você
alterar seu comportamento, você tornará todas as localizações de arquivos
visíveis para todos os usuários. Se deseja indexar todo o sistema de arquivos
(não os poucos que o usuário nobody pode ver) você poderá substituir o
locate
pelo slocate
. O slocate tem a etiqueta de uma
versão avançada e segura do locate da GNU, mas ele atualmente fornece
funcionalidade adicional de localização de arquivos. Quando usar o
slocate
, o usuário somente verá os arquivos que ele tem acesso e
você poderá ignorar qualquer arquivo ou diretório no sistema. O pacote
slocate
executa seus privilégios de atualização com altos
privilégios se comparado ao locate e indexa cada arquivo. Os usuários são
então capazes de localizar rapidamente cada arquivo que podem ver. O
slocate
não lhes permitem ver novos arquivos; ele faz a filtragem
da saída baseado em sua UID.
FIXME: colocar referências ao snapshot feito após a instalação.
FIXME: Adicionar uma nota com relação a pacotes que não fornecem debsums de aplicativos instalados (não mandatário).
FIXME: Mencionar binários assinados usando digamos, bsign ou elfsign
O Debian oferece um trabalho do cron
que é executado diariamente
no arquivo /etc/cron.daily/standard
. Esta tarefa do
cron
executará o script /usr/sbin/checksecurity
que
armazena informações destas alterações.
Para esta verificação ser feita, você deverá definir
CHECKSECURITY_DISABLE="FALSE" no
/etc/checksecurity.conf
. Note que, este é o padrão, assim a não
ser que tenha alterado algo, esta opção já estará definida para
"FALSE".
O comportamento padrão é não enviar esta mensagem para o superusuário, mas ao
invés disto manter cópias diárias das alterações em
/var/log/setuid.changes
. Você deverá alterar o
CHECKSECURITY_EMAIL (no /etc/checksecurity.conf
) para 'root' para
ter estes dados enviados por e-mail para ele. Veja
checksecurity(8)
para mais detalhes.
FIXME. Necessário mais conteúdo (específico o Debian)
FIXME: Faltando conteúdo
Muitas características do kernel podem ser modificadas usando comandos echo no
sistema de arquivos /proc
ou usando o sysctl
.
Executando o /sbin/sysctl -A você poderá ver o que pode ser
configurado e que opções existem, e elas podem ser modificadas executando
/sbin/sysctl -w variável=valor (veja sysctl(8)
).
Somente em raros casos você precisará editar algo aqui, mas você poderá
aumentar também a segurança desta forma. Por exemplo:
net/ipv4/icmp_echo_ignore_broadcasts = 1
Este é um emulador de Windows pois ele atua como o Windows em ping broadcast caso esta opção seja ajustada para 1. Que é, requisições ICMP_ECHO enviadas para o endereço de broadcast serão ignoradas. Caso contrário, ela não faz nada.
Se quer evitar que o seu sistema responda requisições ICMP, apenas ative esta opção de configuração:
net/ipv4/icmp_echo_ignore_all = 1
Para registrar pacotes com endereços impossíveis (devido a roteamento incorreto) em seu sistema, use:
/proc/sys/net/ipv4/conf/all/log_martians = 1
Para mais informações sobre que coisas podem ser feitas com
/proc/sys/net/ipv4/*
leia
/usr/src/linux/Documentation/filesystems/proc.txt
. Todas as
opções estão descritas através do
/usr/src/linux/Documentation/networking/ip-sysctl.txt
[22].
Esta opção é uma faca de dois gumes. De um lado ela protege o seu sistema contra flood de pacotes syn; por outro lado ela viola os padrões definidos (RFCs).
net/ipv4/tcp_syncookies = 1
Se deseja alterar esta opção cada vez que o kernel estiver funcionando, você precisará alterá-la em /etc/network/options definindo syncookies=yes. Ela fará efeito sempre quando /etc/init.d/networking for executado (que é tipicamente feito durante a inicialização do sistema) enquanto o seguinte comando fará efeito imediatamente até a reinicialização:
echo 1 > /proc/sys/net/ipv4/tcp_syncookies
Esta opção somente estará disponível caso o kernel tenha sido compilado com a opção CONFIG_SYNCOOKIES. Todos os kernels do Debian são compilados com esta opção embutida, mas você poderá verificá-la executando:
$ sysctl -A |grep syncookies net/ipv4/tcp_syncookies = 1
Para mais informações sobre os syncookies TCP, leia http://cr.yp.to/syncookies.html
.
Quando definir opções de configuração do kernel para a rede, você precisará configurá-la de forma que seja carregada sempre que o sistema for iniciado. O seguinte exemplo ativa muitas das opções anteriores assim como outras opções úteis.
FIXME Ao invés de fornecer este script, fornecer uma configuração
modelo para o sysctl.conf
(veja: sysctl.conf(5)
).
Também envie isto como um bug wishlist para o pacote.
Crie um script em /etc/network/interface-secure
(o nome é dado
como um exemplo) e o execute do arquivo /etc/network/interfaces
desta forma:
auto eth0 iface eth0 inet static address xxx.xxx.xxx.xxx netmask 255.255.255.xxx broadcast xxx.xxx.xxx.xxx gateway xxx.xxx.xxx.xxx pre-up /etc/network/interface-secure
#!/bin/sh # Nome do Script: /etc/network/interface-secure # Modifica o comportamento padrão para tornar o sistema seguro contra # alguns tipos de ataques TCP/IP spoofing # some TCP/IP spoofing & attacks # # Contribuído por Dariusz Puchalak # echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts # proteção contra broadcast de ECHO echo 0 > /proc/sys/net/ipv4/ip_forward # desativação de forward de ip echo 1 > /proc/sys/net/ipv4/tcp_syncookies # Proteção contra syn cookies ativada echo 1 >/proc/sys/net/ipv4/conf/all/log_martians # Registra pacotes estranhos # (isto inclui pacotes falsos, pacotes com a rota de origem alterada e pacotes redirecionados) # mas tenha cuidado com isto em servidores web carregados echo 1 > /proc/sys/net/ipv4/ip_always_defrag # opção de desfragmentação sempre ativada echo 1 > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses # proteção ativada contra mensagens de erro incorretas # proteção contra ip spoofing echo 1 > /proc/sys/net/ipv4/conf/all/rp_filter # e finalmente mais coisas: # Não aceita redirecionamento de ICMP echo 0 > /proc/sys/net/ipv4/conf/all/accept_redirects echo 0 > /proc/sys/net/ipv4/conf/all/send_redirects # Desativa pacotes com rota de origem echo 0 > /proc/sys/net/ipv4/conf/all/accept_source_route echo 1 > /proc/sys/net/ipv4/conf/all/log_martians
Você também poderá criar um script em init.d que é executado na
inicialização (usando o update-rc.d
para criar os links
apropriados em rc.d).
Para ter capacidades de firewall, ou para proteger o sistema local ou outros
atrás dele, o kernel precisa ser compilado com capacidades de
firewall. O kernel padrão do Debian 2.2 (também 2.2) fornece o filtro de
pacotes chamado ipchains
, o Debian 3.0 usando o kernel padrão
(kernel 2.4) oferece um filtro de pacotes de estado chamado
iptables
(netfilter). As distribuições antigas do Debian
precisarão de um patch apropriado no kernel (o Debian 2.1 usa o kernel 2.0.34).
De qualquer forma, é muito fácil usar um kernel diferente do fornecido pelo
Debian. Você poderá encontrar um kernel pré-compilado como pacotes que poderão
facilmente instalar em seu sistema Debian. Você também poderá copiar os fontes
do kernel usando os pacotes kernel-source-X
e construir pacotes de
kernel personalizados usando o make-kpkg
.
A configuração de firewalls no Debian é discutida mais precisamente em Adicionando capacidades de firewall, Seção 5.14.
Sistemas com mais de uma interface de rede em diferentes redes podem ter os serviços configurados de forma que escutem somente a um determinado endereço IP. Isto normalmente evita o acesso a serviços quando são requisistados através de qualquer outro endereço. No entanto, isto não significa (que foi até mesma uma concepção correta que tive) que o serviço é oferecido ao endereço de hardware (interface de rede). [23]
Isto não é um assunto relacionado a ARP e não é uma violação da RFC (isto é
chamado máquina weak end na RFC1122
, seção
3.3.4.2). Lembre-se, endereços IP não tem nada a ver com a interface física.
Nos kernels da série 2.2 (e anteriores) isto pode ser corrigido com:
# echo 1 > /proc/sys/net/ipv4/conf/all/hidden # echo 1 > /proc/sys/net/ipv4/conf/eth0/hidden # echo 1 > /proc/sys/net/ipv4/conf/eth1/hidden .....
Em outros kernels, isto pode ser corrigido com uma das alternativas:
regras do iptables.
roteamento corretamente configurado. [24]
Patch do kernel [25]
Junto com este texto, existirão algumas ocasiões em que será mostrado como configurar alguns serviços (servidor sshd, apache, serviço de impressão...) para tê-los escutando em um determinado endereço, o leitor deverá ter em mente que, sem as correções fornecidas aqui, a correção não evitará acesso de dentro do mesmo segmento de rede (local). [26]
FIXME: os comentários na bugtraq indicam que lá existe um método específico do Linux para escutar em uma determinada interface.
FIXME: Enviar um bug contra o netbase, assim a correção de roteamento será o comportamento padrão no Debian?
Quando não confia em outras máquinas na sua rede (que deve sempre ser o caso, por ser uma atitude mais segura) você deverá proteger a si mesmo de vários ataques ARP existentes.
Como deve saber, o protocolo ARP é usado para ligar endereços IP a endereços
MAC. (veja RFC826
para todos os
detalhes). Cada vez que enviar um pacote para um endereço IP uma resolução arp
é feita (primeiro procurando no cache ARP local, então se o endereço IP não
estiver presente no cache faz o broadcast de uma requisição arp) para encontrar
o endereço de hardware alvo. Todos os pacotes ARP tentam deixar sua máquina
ingênua fazendo-a pensar que o endereço IP da máquina B é associado com o
endereço MAC da máquina do invasor. Então cada pacote que deseja enviar para o
endereço IP associado com a máquina B, será enviado para a máquina do invasor.
Estes ataques (envenenamento e cache, falsificação ARP...) permitem ao invasor
capturar o tráfego até mesmo em redes com switches, para facilmente roubar
conexões, para desconectar qualquer máquina da rede... ataques arp são
poderosos e fáceis de serem implementados, e existem diversas ferramentas, tais
como arpspoof
através do pacote dsniff
.
No entanto, sempre existe uma solução:
Use um cache arp estático. Você pode configurar entradas "estáticas" em seu cache arp:
arp -s host_name hdwr_addr
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.
Detectar tráfego ARP suspeito. Você poderá usar o pacote
arpwatch
, karpski
ou ferramentas IDS mais gerais que
também poderão detectar tráfego arp suspeitos como (snort
,
prelude
...).
Implementando filtragem na validação de tráfego IP no endereço MAC.
Antes de por o sistema em produção você deverá tirar um snapshot de todo o sistema. Este snapshot deverá ser usado em um evento de compromisso (veja Depois do comprometimento do sistema (resposta a incidentes), Capítulo 10). Você deverá refazer este upgrade assim que o sistema for atualizado, especialmente se seu upgrade for para uma novo lançamento do Debian.
Para isto você deverá usar uma mídia removível gravável que poderá ser configurada como somente-leitura, isto poderá ser feito em um disquete (proteja como somente leitura após o uso) ou uma unidade de CD-ROM (você poderá usar um CD-ROM regravável assim poderá até mesmo manter backups de md5sums em diferentes datas).
O seguinte script criará o snapshot:
#!/bin/bash /bin/mount /dev/fd0 /mnt/floppy /bin/cp /usr/bin/md5sum /mnt/floppy echo "Calculando banco de dados md5" >/mnt/floppy/md5checksums.txt for dir in /bin/ /sbin/ /usr/bin/ /usr/sbin/ /lib/ /usr/lib/ do find $dir -type f | xargs /usr/bin/md5sum >>/mnt/floppy/md5checksums-lib.txt done /bin/umount /dev/fd0 echo "Pós instalação do banco de dados md5 calculada"
Note que o binário md5sum é colocado em uma unidade de disquetes assim ele poderá ser usado depois para verificar binários no sistema (como no caso de ser atacado por um trojan).
O snapshot não inclui os arquivos sob /var/lib/dpkg/info
que
incluem os hashs md5 de pacotes instalados (em arquivos que finalizam com
.md5sums
). Você poderá copiar esta informação também, no entanto
você deverá saber:
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)
nem todos os pacotes do Debian contém md5sums de arquivos que foram instalados pois esta não é (atualmente) a política mandatória.
Assim que o snapshot for feito você deverá se assegurar de proteger a mídia
como somente leitura. Você poderá então armazená-la para backup ou colocá-la
na unidade e usá-la fazendo uma verificação com o cron
toda a
noite comparando os md5sums originais com estes no snapshot.
A Svgalib é muito bonita para amantes de console, como eu, mas no passado ela
provou diversas vezes que é muito insegura. Foram lançadas explorações de
vulnerabilidades contra o zgv
e era simples se tornar usuário
root. Tente evitar o uso de programas usando Svgalib sempre que possível.
[ anterior ] [ Conteúdo ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ A ] [ B ] [ C ] [ D ] [ E ] [ F ] [ G ] [ H ] [ próximo ]
Securing Debian Manual
v3.1,mailto:jfs@debian.org