[ anterior ] [ Conteúdo ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ A ] [ B ] [ C ] [ D ] [ E ] [ F ] [ G ] [ H ] [ próximo ]
Este capítulo introduz algumas das questões mais freqüentes da lista Debian security. Você deverá lê-las antes de postar lá ou senão as pessoas lhe dirão RTFM.
Um sistema é tão seguro quanto um administrador é capaz de faze-lo. A instalação padrão dos serviços da Debian tenta ser secura, mas pode não ser paranóica como outros sistemas operacionais que instalam todos os serviços desativados por padrão. Em qualquer caso, o administrador de sistemas precisa adaptar a segurança do sistema a sua política de segurança local.
Para uma coleção de dados envolvendo vulnerabilidades de segurança de muitos
sistemas operacionais, veja http://securityfocus.com/vulns/stats.shtml
.
Estes dados são úteis? O site lista diversos fatores a considerar quando
estiver interpretando dados, e alerta que os dados não podem ser usados para
comparar vulnerabilidades de um sistema operacional versus outro. [48] Também, tenha em mente que
algumas das vulnerabilidades reportadas via bugs com relação a Debian, se
aplicam somente ao repositório unstable (área de desenvolvimento).
Realmente não existem muitas diferenças entre as distribuições Linux, com exceção da instalação básica e do sistema de gerenciamento de pacotes. A maioria das distribuições compartilham muitos dos aplicativos, com a diferença básica nas versões em que estes aplicativos são oferecidos com o lançamento da distribuição estável. Por exemplo, o kernel, Bind, Apache, OpenSSH, XFree, gcc, zlib, etc. são todos idênticos entre as distribuições de Linux.
Por exemplo, a Red Hat foi infeliz e ofereceu quando 1.2.3 era a atual, que em
seguida foram encontrados problemas de segurança. Na Debian, por outro lado,
foi sortuda e forneceu 1.2.4 que já possui a correção da falha. Este foi o
caso no grande problema do rpc.statd
diversos anos atrás.
Existe muita colaboração entre os respectivos times de segurança das maiores
distribuições Linux. Atualizações de segurança conhecidas são raramente, se
existirem, deixadas de lado por desenvolvedores de uma distribuição. O
conhecimento de uma vulnerabilidade de segurança nunca é mantida isolada do
conhecimento de desenvolvedores de outra distribuição, pois as correções são
normalmente coordenadas com o autor ou através do CERT
. Como um resultado, as atualizações
necessárias de segurança são geralmente lançadas ao mesmo tempo e a segurança
relativa de diferentes distribuições são bem parecidas.
Uma das principais vantagens da Debian com relação a segurança é a facilidade
de atualizações do sistema através do uso do apt
. Aqui existem
muitos outros aspectos da segurança na Debian a serem considerados:
A Debian fornece mais ferramentas de segurança que outras distribuições, veja Ferramentas de segurança no Debian, Capítulo 8.
A instalação padrão da Debian é pequena (menos funcionalidades), e assim mais
segura. Outras distribuições, em nome da funcionalidade, tem a tendência de
instalarem diversos serviços por padrão e algumas vezes não estão corretamente
configurados (lembre-se dos worms Ramen ou Lion
). A
instalação da Debian não é limitada como o OpenBSD (não existem daemons ativos
por padrão), mas tem um bom compromisso. [49]
A Debian documenta as melhores práticas de segurança em documentos como este.
A distribuição Debian conta com um número grande e crescente de pacotes de software, provavelmente mais do que os fornecidos por muitos sistemas operacionais proprietários. Quanto mais pacotes instalados, maior o potencial de falhas de segurança em um determinado sistema.
Mais e mais pessoas estão examinando o código fonte por problemas. Existem muitos alertas relacionados com a auditoria de código fonte dos maiores componentes de software incluídos na Debian. Desta forma, tais auditorias de software mostram brechas de segurança, elas são corrigidas e um aviso é enviado para listas tal como Bugtraq.
Falhas que estão presentes na distribuição Debian normalmente também afetam outros distribuidores e vendedores. Verifique a seção "Específico da Debian: yes/no" no topo de cada aviso de segurança (DSA).
Resposta curta: não.
Resposta longa: certificação custa dinheiro (especialmente se for uma
certificação de segurança séria), ninguém dedicou seus recursos para
para certificar a Debian GNU/Linux em qualquer nível de, por exemplo, Critérios comuns
. Se
estiver interessado em ter uma distribuição de GNU/Linux seguramente
certificada, tente fornecer os recursos necessários para tornar isto possível.
Existem pelo menos duas distribuições de Linux certificadas em diferentes
níveis EAL
.
Note que alguns dos testes CC estão sendo integrados no Linux Testing Project
que está
disponível na Debian através do pacote ltp
.
Sim. Bastille Linux
,
originalmente orientado para outras distribuições de Linux (Red Hat e
Mandrake), atualmente funciona com a Debian. Alguns passos estão sendo feitos
para integrar as alterações feitas com a versão do autor no pacote da Debian,
tendo o nome de bastille
.
Algumas pessoas, no entanto, acreditam que uma ferramenta de fortalecimento não elimina a necessidade de se ter uma boa administração.
Um dos grandes potenciais da Debian é a grande variedade de escolhas disponíveis entre pacotes que oferecem a mesma funcionalidade (servidores de DNS, servidores de e-mail, servidores ftp, servidores web, etc.). Isto pode confundir o administrador novato ao tentar determinar que pacote é o mais adequado para você. O melhor para uma determinada situação depende de um balanceamento entre suas características e necessidades de segurança. Aqui estão algumas questões que devem ser feitas a você mesmo quando decidir entre pacotes parecidos:
Existem um maintainer do código fonte do programa? Quando foi o último lançamento?
O pacote está maduro? o número de versão realmente não mostra sua maturidade. Tente analisar o histórico de atualizações do software.
Este programa é atormentado por falhas? Tem avisos de segurança relacionados a ele?
Este programa oferece todas as funcionalidades que precisa? ele oferece mais do que você realmente precisa?
Você encontrará informações neste documento sobre como tornar alguns serviços (FTP, Bind) mais seguros na Debian GNU/Linux. Para serviços não cobertos aqui, verifique a documentação do programa, ou informações gerais sobre o Linux. Muitas das regras de segurança para sistemas Unix também se aplicam a Debian. Na maioria dos casos, o método para tornar um serviço X mais seguro na Debian é parecido com torná-lo mais seguro em qualquer outra distribuição de Linux (ou Unix, nesta importância).
Se não gosta que os usuários que se conectam ao seu serviço de POP3 recebam
informações sobre seu sistema (por exemplo), você pode querer remover (ou
alterar) o banner que este serviço mostra para os usuários. [50] Fazer isto depende do
programa que está executando para um determinado serviço. Por exemplo, no
postfix
, você poderá ajustar o banner SMTP no arquivo
/etc/postfix/main.cf
:
smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)
Outros softwares não são fáceis de serem alterados. O OpenSSH
precisará ser recompilado para alterar a versão que ele exibe. Tenha cuidado
para não remover a primeira parte do banner (SSH-2.0), pois os
clientes utilizam para identificar que protocolo é suportado por seu pacote.
O time de segurança da Debian não tem a possibilidade de analisar todos os pacotes incluídos na Debian procurando por vulnerabilidades de segurança em potencial, pois não existem recursos para auditar o código fonte de todo o projeto. No entanto, a Debian se beneficia da auditoria de código fonte feita por desenvolvedores que criam o programa.
Como um fato de importância, um desenvolvedor da Debian pode distribuir um Trojan em um pacote e não existe possibilidade de verificar isto. Até mesmo se for introduzido na estrutura da distribuição, seria impossível identificar todas as situações onde o trojan seria executado. Este é o motivo porque a Debian vem com a cláusula de licença "sem garantias".
No entanto, os usuários da Debian podem ter confiança no fato que que código estável tem uma audiência ampla e a maioria dos problemas foram descobertos durante o uso. A instalação de versões não testadas de programas em sistemas críticos é algo não recomendado (se não puder fornecer a auditoria de código necessária). Em qualquer caso, se for descoberta uma vulnerabilidade de segurança introduzida na distribuição, o processo usado para incluir pacote (usando assinaturas digitais) se certifica que o problema pode ser rastreado até o desenvolvedor. O projeto Debian não tem examinado isto levemente.
É claro, você pode alterar as permissões padrões da Debian em seu sistema. A política atual relacionada com arquivos de log e configuração é que eles sejam lidos por todos a não ser que eles contenham informações sensíveis.
Tenha cuidado se fizer estas alterações pois:
Alguns processos podem não ser capazes de gravar arquivos de log se restringir suas permissões.
Alguns aplicativos podem deixar de funcionar se o arquivo de configuração que
eles dependem não puder ser lido. Por exemplo, se você remover a permissão de
leitura para todos do /etc/samba/smb.conf
, o
smbclient
deixará de funcionar se for executado por um usuário
normal.
FIXME: Verificar se isto está escrito na Política. Alguns pacotes (i.e. daemons de ftp) parecem forçar permissões diferentes.
Como fato de importância, as mesmas questões são válidas para qualquer outro usuário. Como a instalação da Debian não coloca qualquer arquivo sob aquele diretório, não existe informações sensíveis a serem protegidas lá. Se você sentir que estas permissões são muito largas para seu sistema, considere altera-las para 750. Para os usuários, leia Limitando acesso a outras informações de usuários, Seção 4.10.12.1.
A lista de discussão Debian security thread
tem mais sobre este assunto.
Se estiver recebendo mensagens de console e configurou o
/etc/syslog.conf
para redirecioná-las ou para arquivos ou para um
TTY especial, você pode ver mensagens sendo direcionadas para a console.
O nível de registro padrão do console para qualquer kernel é 7, o que significa que qualquer mensagem que tem prioridade menor aparecerá no console. Normalmente, os firewalls (a regra LOG) e algumas outras ferramentas de segurança registram eventos em uma prioridade menor que esta, e assim, são enviadas diretamente para a console.
Para reduzir as mensagens enviadas para a console, você pode usar a opção
dmesg
(-n, veja dmesg(8)
), que examina e
controla o buffer do kernel. Para alterar isto após a próxima
reinicialização, altere o /etc/init.d/klogd
de:
KLOGD=""
para:
KLOGD="-c 4"
Use um número menor para -c se estiver ainda vendo as mensagens.
Uma descrição dos diferentes níveis de logs podem ser encontrados no arquivo
/usr/include/sys/syslog.h
:
#define LOG_EMERG 0 /* o sistema está inutilizável */ #define LOG_ALERT 1 /* uma ação deve ser tomada imediatamente */ #define LOG_CRIT 2 /* condições críticas */ #define LOG_ERR 3 /* condições de erro */ #define LOG_WARNING 4 /* condições de alerta */ #define LOG_NOTICE 5 /* condição normal mas significante */ #define LOG_INFO 6 /* informativas */ #define LOG_DEBUG 7 /* mensagens a nível de depuração */
Sim e não. A Debian vem com alguns usuários pré-definidos (identificação de
usuários (UID) < 99 como descritos na Debian Policy
ou
/usr/share/doc/base-passwd/README
) para facilitar a instalação de
alguns serviços que requerem que sejam executados sob um usuário/UID
apropriado. Se não tem a intenção de instalar novos serviços, você pode
seguramente remover estes usuários que não são donos de qualquer arquivo em seu
sistema e não executam qualquer serviço. Em qualquer caso, o comportamento
padrão é que UIDs de 0 a 99 são reservadas para a Debian, e UIDs de 100 a 999
são criados por pacotes na instalação (e apagados quando o pacote e suas
configurações são removidos do sistema).
Para encontrar facilmente que usuários não são donos de arquivos no sistema, execute o seguinte comando (execute-o como root, pois um usuário comum pode não ter permissões suficiente para entrar através de alguns diretórios sensíveis):
cut -f 1 -d : /etc/passwd | \ while read i; do find / -user "$i" | grep -q . && echo "$i"; done
Estes usuários são fornecidos pelo pacote base-passwd
. Olhe em
sua documentação por mais informações sobre como estes usuários são manipulados
pelo sistema Debian. A lista de usuários padrões (com o grupo correspondente)
segue:
root: O root é (tipicamente) o superusuário.
daemon: Alguns daemons não privilegiados que precisam gravar em arquivos no
disco são executados como daemon.daemon (e.g., portmap
,
atd
, provavelmente outros). Os daemons que não precisam ser donos
de quaisquer arquivos são executados sob nobody.nogroup e daemons mais
complexos ou com segurança em mente são executados como usuários dedicados. O
usuário do daemon é prático para daemons instalados localmente.
bin: mantido por razões históricas.
sys: mesmo que bin. No entanto. /dev/vcs* e /var/spool/cups
tem
como donos o grupo sys.
sync: O interpretador de comandos do usuário sync é /bin/sync
.
Assim se sua senha for ajustada para algo fácil de adivinhar (tal como
""), qualquer um pode fazer sync no sistema pela console, até mesmo
se não possuir uma conta.
games: Muitos jogos são SETGID para games assim eles podem gravar seus arquivos de pontuações. Isto é explicado na policy.
man: O programa man (algumas vezes) é executado como usuário man, assim ele
poderá gravar páginas de manuais em /var/cache/man
lp: Usado por daemons de impressão.
mail: Caixas de correios em /var/mail
tem como dono o grupo mail,
como explicado pela policy. O usuário e grupo também são usados para outros
propósitos por vários MTA's.
news: Vários servidores de notícias e outros programas associados (tal como o
suck
) utilizam usuário e grupo news de várias formas. Os arquivos
no spool de notícias tem freqüentemente como dono o usuário e grupo news. Os
programas tais como inews
que são usados para postar notícias
tipicamente usam SETGID para o grupo news.
uucp: O usuário e grupo uucp são usados pelo subsistema UUCP. Ele é dono do spool e arquivos de configuração. Usuários no grupo uucp podem executar o uucico.
proxy: Assim como o daemon, este usuário e grupo são usados por alguns daemons
(especificamente, daemons de proxy) que precisam de identificação de usuários
dedicadas para ser dono de arquivos. Por exemplo, o grupo proxy é usado pelo
pdnsd
e squid
para serem executados como o usuário
proxy.
majordom: Majordomo
tem uma UID estaticamente alocada em sistemas
Debian por razões históricas. Ele não é instalado em novos sistemas.
postgres: Os bancos de dados do Postgresql
tem como dono este
usuário e grupo. Todos os arquivos sob /var/lib/postgresql
tem
como dono este usuário para forçar segurança de forma apropriada.
www-data: Alguns servidores web são executados sob www-data. O conteúdo web *não* deve ter como dono este usuário, ou um servidor web comprometido poderia ser capaz de regravar um site de internet. Dados gravados por servidores web, incluindo arquivos de logs, terão que ter como dono www-data.
backup: Assim as responsabilidades de backup/restauração podem ser localmente delegadas para alguém sem permissões completas de usuário root.
operator: O operador é historicamente (e praticamente) a única conta de "usuário" que pode efetuar login remotamente, e não depende do NIS/NFS.
list: Os arquivos de listas de discussões e dados tem como dono este usuário e grupo. Alguns programas de listas de discussões podem ser executadas também sobe este usuário.
irc: Usado por daemons de irc. É necessário um usuário alocado estaticamente
somente por causa de um bug no ircd
, que faz SETUID()s de si mesmo
para a UID especificada na inicialização.
gnats.
nobody, nogroup: Daemons que não tem necessidade de serem donos de quaisquer arquivos são executados sob o usuário nobody e grupo nogroup. Assim, nenhum arquivo existente no sistema devem ter como donos este usuário ou grupo.
Outros grupos que não tem um usuário associado:
adm: O grupo adm é usado para tarefas de monitoramento do sistema. Os membros
deste grupo podem ler a maioria dos arquivos de log em /var/log
e
podem usar o xconsole. Historicamente, o /var/log
foi
/usr/adm
(e depois /var/adm
), isto explica o nome do
grupo.
tty: Os dispositivos TTY tem como dono este grupo. Eles são usados pelas ferramentas write e wall para permitir escrever para pessoas conectadas em outras TTYs.
disk: Acesso direto a disco. Muito equivalente ao acesso root.
kmem: /dev/kmem e arquivos similares são lidos por este grupo. Isto é mais uma relíquia do BSD, mas alguns programas que precisam de acesso de leitura direto a memória do sistema podem fazer SETGID para o grupo kmem.
dialout: Acesso direto e completo a portas seriais. Membros deste grupo podem reconfigurar o modem, discar para qualquer lugar, etc.
dip: O nome do grupo vem de "Dial-up IP", e membros que pertencem ao
grupo dip podem usar ferramentas como o ppp
, dip
,
wvdial
, etc. para realizar uma conexão. Os usuários neste grupo
não podem reconfigurar o modem, mas podem executar programas para fazerem uso
dele.
fax: Permite que membros usem programas de fax para ler/enviar faxes.
voice: Voicemail, útil para sistemas que usam modens como secretárias eletrônicas.
cdrom: Este grupo pode ser usado localmente para dar ao grupo de usuários acesso a unidade de CDROM.
floppy: Este grupo pode ser usado localmente par dar a um grupo de usuários acesso a unidade de disquetes.
tape: Este grupo pode ser usado localmente para dar a um grupo de usuários acesso a uma unidade de fita.
sudo: Membros dentro deste grupo não precisam digitar sua senha quando
estiverem fazendo o uso do sudo
. Veja
/usr/share/doc/sudo/OPTIONS
.
audio: Este grupo pode ser usado localmente para dar a um grupo de usuários acesso a um dispositivo de audio.
src: Este grupo é dono de código fonte, incluindo arquivos em
/usr/src
. Ele pode ser usado para dar a um usuário a habilidade
de gerenciar código fonte do sistema.
shadow: O arquivo /etc/shadow
é lido por este grupo. Alguns
programas que precisam ser capazes de acessar o arquivo tem SETGID ajustados
para shadow.
utmp: Este grupo pode gravar para o arquivo /var/run/utmp
e
similares. Programas que precisam se capazes de gravar para ele usam SETGID
para utmp.
video: Este grupo é usado localmente para dar a um conjunto de usuários permissões de acesso a dispositivos de vídeo.
staff: Permite que usuários adicionem modificações locais ao sistema
(/usr/local
, /home
) sem necessidade de privilégios de
usuário root. Compare com o grupo "adm", que é mais relacionado a
segurança/monitoramento.
users: Enquanto usuários de sistemas Debian usam seus grupos privados de sistema por padrão (cada usuário tem seu próprio grupo), alguns preferem usar um grupo de sistema mais tradicional, no qual cada usuário é membro de seu grupo.
Componentes do grupo "adm" são geralmente administradores e neste
grupo as permissões os permitem ler arquivos de log sem utilizar
su
. O grupo "staff" são geralmente administradores
junior e de suporte, permitindo que trabalhem em /usr/local
e
criarem diretórios em /home
.
O comportamento padrão na Debian é que cada usuário tem seu próprio e privado grupo. O esquema tradicional do UN*X coloca todos os usuários no grupo users. Grupos adicionais foram criados e usados para restringir o acesso a arquivos compartilhados associados com diferentes diretórios de projetos. O gerenciamento de arquivos se torna difícil quando apenas um usuário trabalha em múltiplos projetos, porque quando alguém cria um arquivo, ele é associado com o grupo primário do grupo que ele pertence (e.g. "users").
O método da Debian resolve este problema associando a cada usuário seu próprio grupo; assim com a máscara apropriada (0002) e o bit SETGID ajustado em um diretório determinado de projetos, o grupo correto é automaticamente designado para arquivos criados naquele diretório. Isto facilita a vida de pessoas que trabalham em múltiplos projetos, porque elas não terão que alterar os grupos e umasks quando estiverem trabalhando em arquivos compartilhados.
Você pode, no entanto, alterar este comportamento modificando o
/etc/adduser.conf
. Altere a variável USERGROUPS para
"no", assim um novo grupo não será criado quando o novo usuário for
criado. Também, altere USERS_GID para a identificação de grupo a que
os usuários pertencem.
Esta é simplesmente uma aproximação do problema de sendo, de um lado, consciente de segurança e por outro lado amigável ao usuário. De forma contrária a OpenBSD, que desativa todos os serviços a não ser que sejam ativados pelo administrador, a Debian GNU/Linux ativa todos os serviços instalados a não ser que sejam desativados (veja Desabilitando daemons de serviço, Seção 3.6.1 para mais informações). Afinal, você instalou o serviço, não foi?
Existem muitas discussões nas listas de discussões da Debian (ambas na debian-devel e na debian-security) com relação a qual é a melhor estratégia para a instalação padrão. No entanto, no momento em que isto foi escrito (Março de 2002), ainda não existia um consenso.
inetd
?
O Inetd
não é fácil de remover pois o pacote netbase
depende do pacote que o fornece (netkit-inetd
). Se deseja
removê-lo, você poderá ou desativá-lo (veja Desabilitando daemons de serviço, Seção
3.6.1) ou remover o pacote usando o pacote equivs
.
A porta 111 é usada pelo portmapper sunrpc e é instalada por padrão como parte do sistema de instalação básico da Debian, pois não existe a necessidade de saber quando o programa do usuário precisa do RPC para funcionar adequadamente. Em qualquer caso, ele é mais usado pelo NFS. Se não precisar dele, remova-o como explicado na seção Tornando serviços RPC mais seguros, Seção 5.13.
Em versões do pacote portmap maiores que a 5-5 você poderá ter o portmapper
instalado mas escutando somente em localhost (modificando o
/etc/default/portmap
)
identd
) é usada?
O serviço ident é um serviço de autenticação que identifica o dono de uma
conexão TCP/IP para o servidor remoto que está aceitando a conexão.
Tipicamente, quando um usuário se conecta ao servidor remoto, o
inetd
do sistema remoto envia uma requisição à porta 113 para
procurar informações sobre o dono. É freqüentemente usada em servidores de
e-mails, FTP e IRC, e também podem ser usadas para descobrir que usuário em seu
sistema local está atacando um sistema remoto.
Existem discussões extensivas relacionadas a segurança do identd
(Veja mailing
list archives
). Em geral, o identd
é mais útil em um
sistema multi-usuário que em uma estação de trabalho simples. Se não tiver um
uso para ele, desative-o, assim você não estará deixando um serviço aberto para
o mundo lá fora. Se decidir fazer um firewall na porta do ident, por
favor use a política reject e não a deny, caso contrário uma conexão para
o servidor usando o identd
travará até que o tempo limite expire
(veja questões
relacionadas a reject ou deny
).
Se executar o comando netstat -an e receber como retorno:
Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name raw 0 0 0.0.0.0:1 0.0.0.0:* 7 - raw 0 0 0.0.0.0:6 0.0.0.0:* 7 -
Você não está vendo processos escutando na porta TCP/UDP 1 e 6. De
fato, você está vendo um processo escutando em um soquete cru pelos
protocolos 1 (ICMP) e 6 (TCP). Tal comportamento é normal para Trojans e
alguns sistemas de detecção de intrusão como o iipl
,
iplogger
e portsentry
. Se tiver estes pacotes
simplesmente os remova. Se não tiver, tente executar a opção -p
do netstat (processo) para ver que processo é dono destas portas.
Sim, com certeza. As portas que está deixando abertas devem aderir a política
individual do seu site com relação a serviços públicos disponíveis para outras
redes. Verifique se estão sendo abertas pelo inetd
(veja Desabilitando o inetd
ou seus
serviços, Seção 3.6.2) ou instalando pacotes individuais e tome as medidas
apropriadas (i.e, configure o inetd, remova o pacote, evite executá-lo na
inicialização).
/etc/services
ajudará a tornar minha máquina mais segura?
Não o /etc/services
somente oferece o mapeamento entre um
nome virtual e um número dado de porta. A remoção de nomes deste arquivo
(geralmente) não evitará que os serviços sejam iniciados. Alguns daemons podem
não ser executados se o /etc/services
for modificado mas isto não
é a norma. Para desativar apropriadamente o serviço, veja Desabilitando daemons de serviço, Seção
3.6.1.
Os passos que precisa fazer para se recuperar disto depende se aplicou ou não
os procedimentos necessários para limitar o acesso ao lilo
e da
BIOS do seu sistema.
Se limitou ambos, precisará desativar a configuração de BIOS que somente lhe permite inicializar através do disco rígido antes de prosseguir. Se tiver também perdido a senha da sua BIOS, você terá que resetar a sua BIOS abrindo o computador e removendo manualmente a bateria que mantém os dados da BIOS>
Assim que permitir a inicialização através da unidade de CD-ROM ou ativação da unidade de disquete, faça o seguinte:
Inicialize através de um disquete de recuperação e inicie o kernel
Vá até o console virtual (Alt+F2)
Monte o disco rígido onde o sistema de arquivos raíz (/) está
Edite o arquivo /etc/shadow
(o disquete de recuperação da Debian
2.2 vem com o editor ae
e a Debian 3.0 vem com o
nano-tiny
que é similar ao vi
) e altere a linha:
root:asdfjgl29gl0341274075:XXXX:X:XXXX:X::: (X=um número qualquer)
para:
root::XXXX:X:XXXX:X:::
Isto removerá a senha de root perdida, contida no primeiro campo separado por dois pontos após o nome do usuário. Salve o arquivo, reinicie o sistema e faça login como usuário root usando uma senha em branco. Lembre-se de adicionar uma nova senha. Isto funcionará a menos que tenha configurado o sistema de forma mais restrita, ou seja, não permitindo que usuários utilizem senhas em branco ou não permitindo o login do usuário root através do console.
Se adicionou estas características, você precisará entrar em modo monousuário.
Se o LILO foi restringido, será necessário re-executar o lilo
após
alterar a senha de root acima. Este truque é necessário pois seu
/etc/lilo.conf
precisa ser mexido devido ao sistema de arquivos
raíz (/) ser um disco ram e não um disco rígido real.
Assim que a restrição do LILO for removida, tente o seguinte:
Pressione as teclas Alt, shift e Control antes do sistema terminar o processo de inicialização, assim você terá acesso ao aviso de comandos do LILO.
Digite linux single, linux init=/bin/sh ou linux 1 na linha de comandos.
Isto lhe dará um aviso de comandos do shell em modo monousuário (ele perguntará por uma senha, mas você já a conhece)
Remonte sua partição raíz (/) usando o comando mount.
# mount -o remount,rw /
Altere a senha do usuário root com o comando passwd
(como você é o
superusuário, o sistema não perguntará a senha anterior).
Por exemplo, se você quer configurar um serviço POP, você não precisará definir
uma conta para cada usuário que esteja usando. É melhor configurar uma
autenticação baseada em diretório através de um serviço externo (como Radius,
LDAP ou banco de dados SQL). Apenas instale a biblioteca PAM apropriada
(libpam-radius-auth
, libpam-ldap
,
libpam-pgsql
ou libpam-mysql
), leia a documentação
(para iniciantes, veja Autenticação do
Usuário: PAM, Seção 4.10.1) e configure o serviço que será ativado pelo PAM
para usar o método de autenticação que escolheu. Isto é feito editando-se os
arquivos sob o diretório /etc/pam.d/
para seu serviço e
modificando o
auth required pam_unix_auth.so shadow nullok use_first_pass
para, por exemplo, ldap:
auth required pam_ldap.so
No caso de diretórios LDAP, alguns serviços oferecem esquemas LDAP que devem ser incluídos em seu diretório e são necessários para a utilização de autenticação LDAP. Se estiver usando um banco de dados relacional, uma dica útil é usar a cláusula where quando estiver configurando os módulos do PAM. Por exemplo, se tiver um banco de dados com os seguintes atributos na tabela:
(user_id, user_name, realname, shell, password, UID, GID, homedir, sys, pop, imap, ftp)
Tornando os serviços campos de atributos boleanos, você poderá usa-los para permitir ou negar acesso a diferentes serviços apenas inserindo as linhas apropriadas nos seguintes arquivos:
/etc/pam.d/imap
:where=imap=1.
/etc/pam.d/qpopper
:where=pop=1.
/etc/nss-mysql*.conf
:users.where_clause = user.sys =
1;.
/etc/proftpd.conf
:SQLWhereClause "ftp=1".
Muitos scanners de avaliação de vulnerabilidades indicarão falso positivos quando forem usados em sistemas Debian, pois podem somente usar checagem de versões para determinar se uma determinada versão de pacote é vulnerável, mas realmente não testam a vulnerabilidade de segurança propriamente dita. Pois a Debian não muda os números de versões quando corrige um pacote (muitas vezes a correção feita em versões novas são reproduzidas nas atuais), algumas ferramentas tendem a achar que um sistema Debian atualizado está vulnerável, quando não está.
Se você acha que o seu sistema está atualizado com patches de segurança, você pode querer usar as referências cruzadas com o banco de dados de vulnerabilidades publicados com os DSAs (veja Debian Security Advisories, Seção 7.2) para afastar a possibilidade de falsos positivos, se a ferramenta que estiver usando inclui referências do CVE.
Um traço de ataque nem sempre significa que seu sistema foi comprometido, e você deverá fazer os passos tradicionais para determinar se o sistema está comprometido (veja Depois do comprometimento do sistema (resposta a incidentes), Capítulo 10). Também, note que o fato de ver os ataques nos logs pode significar que seu sistema está vulnerável a ele (um invasor determinado pode ter usado outras vulnerabilidades que não sejam a que você viu, no entanto).
Você pode achar as seguintes linhas nos seus logs de sistema:
Dec 30 07:33:36 debian -- MARK -- Dec 30 07:53:36 debian -- MARK -- Dec 30 08:13:36 debian -- MARK --
Isto não indica qualquer tipo de comprometimento e os usuários que estão
mudando de versão da Debian devem achar isto estranho. Se o seu sistema não
tem uma carga alta (ou muitos serviços ativos), estas linhas devem aparecer
entre seus logs. Isto é uma indicação que seu daemon do syslogd
está sendo executado de forma apropriada. Texto extraído da página de manual
syslogd(8)
:
-m intervalo O syslogd registra uma marca de horário regularmente. O intervalo padrão entre duas linhas -- MARK -- é de 20 minutos. Isto pode ser alterado com esta opção. O intervalo de zero, desativa totalmente este recurso.
Você pode encontrar linhas em seus logs como:
Apr 1 09:25:01 server su[30315]: + ??? root-nobody Apr 1 09:25:01 server PAM_unix[30315]: (su) session opened for user nobody by (UID=0)
Não se preocupe muito. Verifique para ver se estas mensagens são devido a
tarefas do cron
(normalmente /etc/cron.daily/find
ou
logrotate
):
$ grep 25 /etc/crontab 25 6 * * * root test -e /usr/sbin/anacron || run-parts --report /etc/cron.daily $ grep nobody /etc/cron.daily/* find:cd / && updatedb --localuser=nobody 2>/dev/null
Se ver linhas como estas em seus logs:
May 1 12:35:25 linux kernel: possible SYN flooding on port X. Sending cookies. May 1 12:36:25 linux kernel: possible SYN flooding on port X. Sending cookies. May 1 12:37:25 linux kernel: possible SYN flooding on port X. Sending cookies. May 1 13:43:11 linux kernel: possible SYN flooding on port X. Sending cookies.
Verifique se existe um número alto de conexões ao servidor usando o
netstat
, por exemplo:
linux:~# netstat -ant | grep SYN_RECV | wc -l 9000
Isto é uma indicação de ataque de negação de serviço (denial of service - DoS) contra a porta X do seu sistema (mais provável contra um serviço público tal como um servidor web ou servidor de e-mails). Você deverá ativar os SynCookies TCP em seu kernel, veja Configurando Syncookies, Seção 4.17.2. Note, no entanto, que um ataque DoS pode sobrecarregar sua rede até mesmo se você puder parar de fazê-lo travar seus sistemas (devido ao número de descritores de arquivos sendo reduzidos, o sistema pode parar de responder até que o tempo limite de algumas conexões se esgote). O único método efetivo de parar este ataque é contactar seu provedor de rede.
Se ver estes tipos de entradas em seu arquivo /var/log/auth.log
:
May 2 11:55:02 linux PAM_unix[1477]: (cron) session closed for user root May 2 11:55:02 linux PAM_unix[1476]: (cron) session closed for user root May 2 12:00:01 linux PAM_unix[1536]: (cron) session opened for user root by (UID=0) May 2 12:00:02 linux PAM_unix[1536]: (cron) session closed for user root
Estas são devido a uma tarefa do cron
sendo executada (neste
exemplo, a cada cinco minutos). Para determinar que programa é responsável por
estas tarefas, verifique as tarefas nos diretórios: /etc/crontab
,
/etc/cron.d
, /etc/crond.daily
e do root
crontab
sob /var/spool/cron/crontabs
.
Existem diversos passos que deve fazer no caso de uma invasão:
Verifique se o seu sistema está atualizado com as atualizações de segurança de
vulnerabilidades publicadas. Se o seu sistema estiver vulnerável, as chances
do sistema estar de fato comprometido são maiores. As chances crescem mais se
a vulnerabilidade foi conhecida durante algum tempo, pois normalmente existem
mais atividades com relação a vulnerabilidades antigas. Aqui está um link para
As 20 maiores Vulnerabilidades de
Segurança
.
Leia este documento, especialmente a seção Depois do comprometimento do sistema (resposta a incidentes), Capítulo 10
Peça assistência. Você deverá usar a lista de discussão debian-security para perguntar sobre como recuperar/corrigir seu sistema.
Notifique seu CERT
local (caso
ele exista, caso contrário você deverá considerar o contato direto com o CERT).
Isto pode ou não ajudar você, mas, pelo menos, informará o CERT de ataques que
estejam acontecendo. Esta informação é muito valiosa em determinar que
ferramentas e ataques estão sendo usados pela comunidade chapéu preto.
Olhando os logs (caso não tenham sido mexidos) usando sistemas de detecção de
intrusão (veja Configure um sistema
de Detecção de Intrusão, Seção 9.3), traceroute
,
whois
e ferramentas parecidas (incluindo análise forense), você
pode ser capaz de detectar um ataque até a sua origem. O método que pode
reagir a esta informação depende solenemente de sua política de segurança e o
que você considera um ataque. Um scan remoto é um ataque? É um teste
de vulnerabilidade um ataque?
Primeiro, leve um momento para se certificar se a vulnerabilidade foi anunciada
em listas de discussões de segurança públicas (como a Bugtraq) ou outros
fóruns. O time da Debian Security se mantém atualizada com estas listas, assim
elas também deverão ter conhecimento do problema. Não faça qualquer outra
ações se você ver um anúncio em http://security.debian.org
.
Caso nenhuma informação tenha sido publicada, por favor envie um e-mail sobre
o(s) pacote(s) afetado(s), assim como uma descrição detalhada da
vulnerabilidade (código que comprova isto também é válido) para team@security.debian.org
.
Isto lhe colocará em contato com o time de segurança da Debian.
Ao invés de atualizar para uma versão nova, a Debian adapta as correções para a versão que é fornecida com o lançamento estável. A razão disto é para ter certeza que o lançamento estável altere o mínimo possível, assim as coisas não alterarão ou quebrarão de forma inesperada como resultado de uma correção de falha. Você pode verificar se está executando uma versão segura de pacote olhando nos logs de alterações do pacote ou comparando seu número de versão exato (versão do autor - traço- lançamento da Debian) com o número de versão indicado no aviso de segurança da Debian.
proftpd
é vulnerável ao ataque de negação de serviço.
Adicione DenyFilter \*.*/ em seu arquivo de configuração, e para
mais informações veja http://www.proftpd.org/critbugs.html
.
portsentry
muitas portas são abertas
Este é simplesmente o método como o portsentry
funciona. Ele abre
cerca de vinte portas não usadas para tentar identificar port scans.
Esta informação foi derivada de Debian Security FAQ
. Este
texto inclui as informações de 19 de Novembro e oferece algumas outras questões
comuns perguntadas na lista de discussão debian-security.
É a informação enviada pelo Time de segurança da Debian (veja abaixo) com
relação a descoberta e correção de uma vulnerabilidade relacionada a segurança
em um pacote disponível na Debian GNU/Linux. DSAs assinados são enviados à
lista de discussões públicas (debian-security-announce) e postados no web site
da Debian (ambos na página inicial e na área de segurança
).
OS DSAs incluem informações sobre o pacote afetado, o problema de segurança descoberto e onde obter pacotes atualizados (com seus respectivos cálculos MD5).
É mais provável que este problema esteja sendo causado por algo em sua máquina.
A lista debian-security-announce
tem um filtro que somente permite postagem de mensagens de um dos membros do
time de segurança da Debian.
É mais provável que algumas peças do software de e-mail estejam alterando as mensagens, quebrando assim a assinatura. Tenha certeza que seu programa não faça qualquer encodificação ou decodificação MIME ou conversão de tab/espaços.
Acusados conhecidos são fetchmail (com a opção mimedecode ativada), formail (somente do procmail 3.14) e o evolution.
Assim que o time de segurança recebe a notificação de um incidente, um dos membros revisa e considera o impacto no lançamento estável da Debian (i.e. se é vulnerável ou não). Se o seu sistema é vulnerável, nós trabalharemos para corrigir o problema. O mantenedor do pacote também é contactado, caso ele já não tenha contactado o time de segurança. Finalmente, a correção é testada e novos pacotes são preparados, que então são compilados em todas as arquiteturas estáveis e após isto feito o upload. Após isto feito, um aviso de segurança é publicado.
A regra de conduta mais importante quando criar um novo pacote que corrige um problema de segurança é fazer menos alterações possíveis. Nossos usuários e desenvolvedores se preocupam com o exato comportamento de um lançamento quando é feito, assim qualquer alteração que nós fazemos, pode possivelmente tornar o programa não funcional no sistema de alguém. Isto é especialmente verdadeiro no caso de bibliotecas: tenha certeza de nunca alterar a interface de aplicação do programa (API) ou a interface de aplicação do Binário (ABI), não importa quanto pequena a alteração seja.
Isto significa que não é uma boa solução mover para uma nova versão do autor do pacote, ao invés disto as alterações importantes devem ser feitas na versão atual (backportadas). Geralmente os autores ajudam se necessário, senão o time de segurança da Debian poderá ser capaz de ajudar.
Em alguns casos não é possível adaptar uma atualização de segurança para uma versão antiga, por exemplo, quando foi necessária a alteração de uma grande quantidade de código fonte. Se isto acontecer, é necessário mover para uma nova versão do autor, mas isto deve ser coordenado de forma muito pró ativa com o time de segurança.
Quebras de segurança na distribuição estável garante um pacote em security.debian.org. Qualquer outra coisa não. O tamanho do comprometimento não é o problema real aqui. Normalmente o time de segurança preparará pacotes juntos com o mantenedor do pacote. Fornecendo os rastros dos testes de alguém (confiável) sobre o problema e tendo todos os pacotes necessários compilados e enviados para o time de segurança, até mesmo problemas de segurança simples farão o pacote ser enviado para security.debian.org. Por favor, veja baixo.
Ao invés de atualizar para uma nova versão, nós adaptamos as correções para a versão estável que é fornecida com o lançamento estável. A razão para fazermos isto é para ter certeza que a versão estável mude o mínimo possível assim as coisas não serão alteradas ou quebrarão de forma inesperada como resultado de um problema de segurança. Você poderá verificar se está executando uma versão segura de um pacote olhando nos logs de alterações do pacote (changelog), ou comparando seu número de versão exato com o número de versão indicado no aviso de segurança da Debian (DSA).
A resposta curta é: não é. Os lançamentos testing e unstable estão movendo rapidamente objetos e o time de segurança não possui os recursos necessários para suportá-las apropriadamente. Se desejar ter um servidor seguro (e estável) você é fortemente encorajado para permanecer usando a stable (estável). No entanto, as secretárias de segurança tentarão corrigir problemas na testing e unstable após terem sido corrigidos na stable (distribuição estável).
Em alguns casos, no entanto, o repositório unstable (instável) recebe correções de segurança de forma rápida, porque estas correções geralmente são disponibilizadas de forma rápida para o autor (outras versões, como as que estão no repositório stable, geralmente precisam ser adaptadas).
Não. Infelizmente o time de segurança da Debian não pode tomar conta de ambos os lançamentos estáveis (oficialmente, também a unstable) e outros lançamentos antigos. No entanto, você poderá esperar por atualizações de segurança por um período limitado de tempo (normalmente alguns meses) imediatamente seguindo o lançamento de uma nova distribuição da Debian.
O propósito de security.debian.org é tornar atualizações de segurança rapidamente disponíveis quanto possível. Os mirrors adicionariam uma complexidade extra que não é necessária e causariam frustração caso não estivessem sendo atualizados.
Diversos distribuidores (a maioria de GNU/Linux, mas também de BSD e derivados) coordenam avisos de segurança para alguns incidentes e concordam em ter uma limite de tempo particular de lançamento, assim todos os distribuidores são capazes de lançar um aviso em conjunto. Isto foi decidido com a intenção de não existirem discriminações entre alguns distribuidores que precisam de mais tempo (e.g. quando o distribuidor passou pacotes através de grandes testes de qualidade ou precisa manter o suporte a diversas arquiteturas ou distribuições binários). Nosso próprio time de segurança também prepara avisos de forma pró ativa. Toda vez que estiver acontecendo, outros problemas de segurança serão analisados antes de um aviso ser lançado, e assim deixando alguns números de avisos de lado temporariamente.
Informações de segurança podem ser enviadas para security@debian.org
, que é lida
por todos os desenvolvedores da Debian. Se tiver informações sensíveis, por
favor use team@security.debian.org
que
é lida somente por membros. Caso a mensagem puder ser encriptada pela chave de
contato do time de segurança da Debian (key ID 0x363CCD95
).
Quando envia uma mensagem para security@debian.org, ela é enviada apara a lista
de discussão de desenvolvedores (debian-private). Todos os desenvolvedores da
Debian estão inscritos nesta lista e as postagens são mantidas privadas (i.e.
não são arquivadas no site público da internet). A lista de discussão pública,
debian-security@lists.debian.org, é aberta para qualquer pessoa que deseja se
inscrever
e
existem arquivos que podem ser pesquisados disponíveis aqui
.
Contribuindo com este documento, corrigindo parágrafos marcados com FIXME ou fornecendo novos conteúdos. A documentação é importante e reduz a carga de perguntas de assuntos simples. A tradução desta documentação em outros idiomas também é de grande ajuda.
Empacotando aplicativos que são úteis para a checagem e fortalecimento de um
sistema Debian GNU/Linux. Se não for um desenvolvedor, envie uma falha sobre o WNPP
e
pergunte pelo software que acha que poderia ser útil, mas que atualmente não é
fornecido.
Audite os programas na Debian ou resolva bugs de segurança e reporte assuntos
para security@debian.org. Trabalhar em outros projetos como o Projeto de Auditoria e Segurança do
Kernel do Linux
ou o Projeto de
Segurança e Auditoria do Linux
também aumenta a segurança da Debian
GNU/Linux, pois as contribuições eventualmente também ajudarão aqui.
Em todos os casos, po favor revise cada problema antes de enviá-lo para security@debian.org. Se for capaz de fornecer patches, isto aceleraria o processo. Não redirecione mensagens de listas de bugtraq, pois eles já foram recebidos. O fornecimento de informações adicionais, no entanto, é sempre uma ótima idéia.
O time de segurança da Debian é composto de cinco membros e duas secretárias. O time de segurança por si mesmo recomenda pessoas para que façam parte do time.
Não, o time de segurança da Debian não verifica cada pacote e não existe um método de checagem automático (lintian) para detectar novos pacotes maliciosos, pois estas tarefas são quase impossíveis de serem detectadas automaticamente. Mantenedores, no entanto, são completamente responsáveis pelos pacotes que adicionam na Debian, e todos os pacotes são primeiramente assinados por um desenvolvedor autorizado. O desenvolvedor tem a responsabilidade de analisar a segurança de todos os pacotes que ele mantém.
O time de segurança da Debian trabalha rapidamente para enviar avisos e
produzir pacotes corrigidos para o repositório estável assim que uma
vulnerabilidade é descoberta. Um relatório públicado
na lista de discussão debian-security
mostrou que no ano de 2001,
houve uma média de 35 dias para corrigir problemas relacionados a segurança.
No entanto, 50% dos problemas foram solucionados em um intervalo de 10 dias, e
15% dos problemas foram corrigidos no mesmo dia quando o aviso foi
lançado.
No entanto, quando perguntam esta questão as pessoas tendem a se esquecer que:
Os DSAs não são enviados até que:
os pacotes estejam disponíveis para todas as arquiteturas suportadas pela Debian (o que leva muito tempo para pacotes que são partes do núcleo do sistema, especialmente considerando o número de arquiteturas suportadas pelo lançamento estável).
novos pacotes são constantemente testados para ter certeza que nenhuma nova falha foi introduzida
Os pacotes devem ser disponibilizados antes do DSA ser enviado (na queue incoming ou nos mirrors).
O Debian é um projeto baseado em trabalho voluntário.
A Debian é licenciada com uma cláusula "sem garantias".
Se quiser uma análise mais precisa do tempo que o time de segurança leva para
trabalhar em vulnerabilidades, você deverá considerar que os novos DSAs (veja
Debian Security Advisories, Seção 7.2)
publicados no website de
segurança
, e os metadados usado para gerá-los, incluem links para
bancos de dados de vulnerabilidades. Você poderá baixar os fontes do servidor
web (a partir do CVS
) ou usar
as páginas HTML para determinar o tempo que a Debian levou para corrigir a
vulnerabilidade e co-relacionar estes dados com bancos de dados públicos.
[ anterior ] [ Conteúdo ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ A ] [ B ] [ C ] [ D ] [ E ] [ F ] [ G ] [ H ] [ próximo ]
Securing Debian Manual
v3.1,mailto:jfs@debian.org