12.1.1. A Debian é mais segura que X?
Um sistema é tão seguro quanto um administrador é capaz de faze-lo. A instalação padrão dos serviços da Debian tenta ser secura, mas pode não ser paranóica como outros sistemas operacionais que instalam todos os serviços desativados por padrão. Em qualquer caso, o administrador de sistemas precisa adaptar a segurança do sistema a sua política de segurança local.
Para uma coleção de dados envolvendo vulnerabilidades de segurança de muitos sistemas operacionais, veja
http://securityfocus.com/vulns/stats.shtml. Estes dados são úteis? O site lista diversos fatores a considerar quando estiver interpretando dados, e alerta que os dados não podem ser usados para comparar vulnerabilidades de um sistema operacional versus outro.
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).
12.1.1.1. A Debian é mais segura que as outras distribuições Linux (tal como Red Hat, SuSE...)?
Realmente não existem muitas diferenças entre as distribuições Linux, com exceção da instalação básica e do sistema de gerenciamento de pacotes. A maioria das distribuições compartilham muitos dos aplicativos, com a diferença básica nas versões em que estes aplicativos são oferecidos com o lançamento da distribuição estável. Por exemplo, o kernel, Bind, Apache, OpenSSH, XFree, gcc, zlib, etc. são todos idênticos entre as distribuições de Linux.
Por exemplo, a Red Hat foi infeliz e ofereceu quando 1.2.3 era a atual, que em seguida foram encontrados problemas de segurança. Na Debian, por outro lado, foi sortuda e forneceu 1.2.4 que já possui a correção da falha. Este foi o caso no grande problema do
http://www.cert.org/advisories/CA-2000-17.html 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
http://www.cert.org. 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:
12.1.1.2. Existem muitas falhas no sistema de tratamento de falhas da Debian. Isto significa que é muito vulnerável?
A distribuição Debian conta com um número grande e crescente de pacotes de software, provavelmente mais do que os fornecidos por muitos sistemas operacionais proprietários. Quanto mais pacotes instalados, maior o potencial de falhas de segurança em um determinado sistema.
Mais e mais pessoas estão examinando o código fonte por problemas. Existem muitos alertas relacionados com a auditoria de código fonte dos maiores componentes de software incluídos na Debian. Desta forma, tais auditorias de software mostram brechas de segurança, elas são corrigidas e um aviso é enviado para listas tal como Bugtraq.
Falhas que estão presentes na distribuição Debian normalmente também afetam outros distribuidores e vendedores. Verifique a seção "Específico da Debian: yes/no" no topo de cada aviso de segurança (DSA).
12.1.1.3. A Debian possui qualquer certificação relacionada a segurança?
Resposta curta: não.
Resposta longa: certificação custa dinheiro (especialmente se for uma certificação de segurança
séria), ninguém dedicou seus recursos para para certificar a Debian GNU/Linux em qualquer nível de, por exemplo,
http://niap.nist.gov/cc-scheme/st/. Se estiver interessado em ter uma distribuição de GNU/Linux seguramente certificada, tente fornecer os recursos necessários para tornar isto possível.
12.1.1.4. Existe algum programa de fortalecimento para a Debian?
Yes.
http://bastille-linux.sourceforge.net/, originally oriented toward other Linux distributions (Red Hat and Mandrake), it currently works also for Debian. Steps are being taken to integrate the changes made to the upstream version into the Debian package, named
bastille.
Algumas pessoas, no entanto, acreditam que uma ferramenta de fortalecimento não elimina a necessidade de se ter uma boa administração.
12.1.1.5. Eu desejo executar o serviço XYZ, qual eu devo escolher?
Um dos grandes potenciais da Debian é a grande variedade de escolhas disponíveis entre pacotes que oferecem a mesma funcionalidade (servidores de DNS, servidores de e-mail, servidores ftp, servidores web, etc.). Isto pode confundir o administrador novato ao tentar determinar que pacote é o mais adequado para você. O melhor para uma determinada situação depende de um balanceamento entre suas características e necessidades de segurança. Aqui estão algumas questões que devem ser feitas a você mesmo quando decidir entre pacotes parecidos:
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?
12.1.1.6. Como eu posso tornar o serviço XYZ mais seguro na Debian?
Você encontrará informações neste documento sobre como tornar alguns serviços (FTP, Bind) mais seguros na Debian GNU/Linux. Para serviços não cobertos aqui, verifique a documentação do programa, ou informações gerais sobre o Linux. Muitas das regras de segurança para sistemas Unix também se aplicam a Debian. Na maioria dos casos, o método para tornar um serviço X mais seguro na Debian é parecido com torná-lo mais seguro em qualquer outra distribuição de Linux (ou Unix, nesta importância).
12.1.1.7. Como posso remover todos os banners de serviços?
Se não gosta que os usuários que se conectam ao seu serviço de POP3 recebam informações sobre seu sistema (por exemplo), você pode querer remover (ou alterar) o banner que este serviço mostra para os usuários.
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)
Other software is not as easy to change. ssh will need to be recompiled in order to change the version that it prints. Take care not to remove the first part (SSH-2.0) of the banner, which clients use to identify which protocol(s) is supported by your package.
12.1.1.8. Todos os pacotes da Debian são seguros?
O time de segurança da Debian não tem a possibilidade de analisar todos os pacotes incluídos na Debian procurando por vulnerabilidades de segurança em potencial, pois não existem recursos para auditar o código fonte de todo o projeto. No entanto, a Debian se beneficia da auditoria de código fonte feita por desenvolvedores que criam o programa.
Como um fato de importância, um desenvolvedor da Debian pode distribuir um Trojan em um pacote e não existe possibilidade de verificar isto. Até mesmo se for introduzido na estrutura da distribuição, seria impossível identificar todas as situações onde o trojan seria executado. Este é o motivo porque a Debian vem com a cláusula de licença "sem garantias".
No entanto, os usuários da Debian podem ter confiança no fato que que código estável tem uma audiência ampla e a maioria dos problemas foram descobertos durante o uso. A instalação de versões não testadas de programas em sistemas críticos é algo não recomendado (se não puder fornecer a auditoria de código necessária). Em qualquer caso, se for descoberta uma vulnerabilidade de segurança introduzida na distribuição, o processo usado para incluir pacote (usando assinaturas digitais) se certifica que o problema pode ser rastreado até o desenvolvedor. O projeto Debian não tem examinado isto levemente.
12.1.1.9. Porque alguns arquivos de logs/configuração tem permissão de leitura para qualquer um, isto não é inseguro?
É claro, você pode alterar as permissões padrões da Debian em seu sistema. A política atual relacionada com arquivos de log e configuração é que eles sejam lidos por todos a não ser que eles contenham informações sensíveis.
Tenha cuidado se fizer estas alterações pois:
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.
12.1.1.10. Porque o /root/ (ou UsuarioX) tem permissões 755?
Como fato de importância, as mesmas questões são válidas para qualquer outro usuário. Como a instalação da Debian não coloca
qualquer arquivo sob aquele diretório, não existe informações sensíveis a serem protegidas lá. Se você sentir que estas permissões são muito largas para seu sistema, considere altera-las para 750. Para os usuários, leia
Seção 4.11.19.1, “Limitando acesso a outras informações de usuários”.
12.1.1.11. Após instalar o grsec/firewall, comecei a receber muitas mensagens de console! como removê-las?
Se estiver recebendo mensagens de console e configurou o /etc/syslog.conf para redirecioná-las ou para arquivos ou para um TTY especial, você pode ver mensagens sendo direcionadas para a console.
O nível de registro padrão do console para qualquer kernel é 7, o que significa que qualquer mensagem que tem prioridade menor aparecerá no console. Normalmente, os firewalls (a regra LOG) e algumas outras ferramentas de segurança registram eventos em uma prioridade menor que esta, e assim, são enviadas diretamente para a console.
To reduce messages sent to the console, you can use
dmesg (
-n option, see
dmseg(8)), which examines and
controls the kernel ring buffer. To fix this after the next reboot, change
/etc/init.d/klogd from:
KLOGD=""
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 */
12.1.1.12. Usuários e grupos do sistema operacional
12.1.1.12.1. Todos os usuários do sistema são necessários?
Sim e não. A Debian vem com alguns usuários pré-definidos (identificação de usuários (UID) < 99 como descritos na
http://www.debian.org/doc/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).
To easily find users who don't own any files, execute the following command
(run it as root, since a common user might not have enough permissions to go through some sensitive directories):
cut -f 1 -d : /etc/passwd | \
while read i; do find / -user "$i" | grep -q . || echo "$i"; done
These users are provided by
base-passwd. Look in its documentation for more information on how these users are handled in Debian. The list of default users (with a corresponding group) follows:
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.
12.1.1.12.2. I removed a system user! How can I recover?
If you have removed a system user and have not made a backup of your password and group files you can try recovering from this issue using update-passwd (see update-passwd(8)).
12.1.1.12.3. Quais são as diferenças entre os grupos adm e staff?
Componentes do grupo "adm" são geralmente administradores e neste grupo as permissões os permitem ler arquivos de log sem utilizar su. O grupo "staff" são geralmente administradores junior e de suporte, permitindo que trabalhem em /usr/local e criarem diretórios em /home.
12.1.1.13. Porque existe um novo grupo quando adiciono um novo usuário? (ou porque a Debian cria um novo grupo para cada usuário?)
O comportamento padrão na Debian é que cada usuário tem seu próprio e privado grupo. O esquema tradicional do UN*X coloca todos os usuários no grupo users. Grupos adicionais foram criados e usados para restringir o acesso a arquivos compartilhados associados com diferentes diretórios de projetos. O gerenciamento de arquivos se torna difícil quando apenas um usuário trabalha em múltiplos projetos, porque quando alguém cria um arquivo, ele é associado com o grupo primário do grupo que ele pertence (e.g. "users").
O método da Debian resolve este problema associando a cada usuário seu próprio grupo; assim com a máscara apropriada (0002) e o bit SETGID ajustado em um diretório determinado de projetos, o grupo correto é automaticamente designado para arquivos criados naquele diretório. Isto facilita a vida de pessoas que trabalham em múltiplos projetos, porque elas não terão que alterar os grupos e umasks quando estiverem trabalhando em arquivos compartilhados.
Você pode, no entanto, alterar este comportamento modificando o /etc/adduser.conf. Altere a variável USERGROUPS para "no", assim um novo grupo não será criado quando o novo usuário for criado. Também, altere USERS_GID para a identificação de grupo a que os usuários pertencem.
12.1.1.14. Questões relacionadas a serviços e portas abertas
12.1.1.14.1. Porque todos os serviços são ativados durante a instalação?
Esta é simplesmente uma aproximação do problema de sendo, de um lado, consciente de segurança e por outro lado amigável ao usuário. De forma contrária a OpenBSD, que desativa todos os serviços a não ser que sejam ativados pelo administrador, a Debian GNU/Linux ativa todos os serviços instalados a não ser que sejam desativados (veja
Seção 3.5.1, “Desabilitando daemons de serviço” 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.
12.1.1.14.2. Can I remove inetd?
Inetd is not easy to remove since
netbase depends on the package that provides it (
netkit-inetd). If you want to remove it, you can either disable it (see
Seção 3.5.1, “Desabilitando daemons de serviço”) or remove the package by using the
equivs package.
12.1.1.14.3. Porque eu tenho a porta 111 aberta?
A porta 111 é usada pelo portmapper sunrpc e é instalada por padrão como parte do sistema de instalação básico da Debian, pois não existe a necessidade de saber quando o programa do usuário precisa do RPC para funcionar adequadamente. Em qualquer caso, ele é mais usado pelo NFS. Se não precisar dele, remova-o como explicado na seção
Seção 5.13, “Tornando serviços RPC mais seguros”.
In versions of the portmap package later than 5-5 you can actually have the portmapper installed but listening only on localhost (by modifying /etc/default/portmap)
12.1.1.14.4. Para que a porta 113 (identd) é usada?
O serviço ident é um serviço de autenticação que identifica o dono de uma conexão TCP/IP para o servidor remoto que está aceitando a conexão. Tipicamente, quando um usuário se conecta ao servidor remoto, o inetd do sistema remoto envia uma requisição à porta 113 para procurar informações sobre o dono. É freqüentemente usada em servidores de e-mails, FTP e IRC, e também podem ser usadas para descobrir que usuário em seu sistema local está atacando um sistema remoto.
Existem discussões extensivas relacionadas a segurança do
identd (Veja
http://lists.debian.org/debian-security/2001/debian-security-200108/msg00297.html). 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
http://logi.cc/linux/reject_or_deny.php3).
12.1.1.14.5. Tenho serviços usando a porta 1 e 6, o que são e como posso removê-las?
Se executar o comando
netstat -an e receber como retorno:
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State
PID/Program name
raw 0 0 0.0.0.0:1 0.0.0.0:* 7
-
raw 0 0 0.0.0.0:6 0.0.0.0:* 7
-
You are not seeing processes listening on TCP/UDP port 1 and 6. In fact, you are seeing a process listening on a raw socket for protocols 1 (ICMP) and 6 (TCP). Such behavior is common to both legitimate software like intrustion detection systems, such as iplogger and portsentry, but some trojans have also been known yo use them. If you have the mentioned packages simply remove them to close the port. If you do not, try netstat's -p (process) option to see which process is running these listeners.
12.1.1.14.6. Encontrei a porta XYZ aberta, posso fechá-la?
Sim, com certeza. As portas que está deixando abertas devem aderir a política individual do seu site com relação a serviços públicos disponíveis para outras redes. Verifique se estão sendo abertas pelo
inetd (veja
Seção 3.5.2, “Desabilitando o inetd ou seus serviços”) ou instalando pacotes individuais e tome as medidas apropriadas (i.e, configure o inetd, remova o pacote, evite executá-lo na inicialização).
12.1.1.14.7. Removendo serviços do /etc/services ajudará a tornar minha máquina mais segura?
Não o
/etc/services somente oferece o mapeamento entre um nome virtual e um número dado de porta. A remoção de nomes deste arquivo (geralmente) não evitará que os serviços sejam iniciados. Alguns daemons podem não ser executados se o
/etc/services for modificado mas isto não é a norma. Para desativar apropriadamente o serviço, veja
Seção 3.5.1, “Desabilitando daemons de serviço”.
12.1.1.15. Assuntos comuns relacionados a segurança
12.1.1.15.1. Perdi minha senha e não posso acessar o sistema!
Os passos que precisa fazer para se recuperar disto depende se aplicou ou não os procedimentos necessários para limitar o acesso ao lilo e da BIOS do seu sistema.
Se limitou ambos, precisará desativar a configuração de BIOS que somente lhe permite inicializar através do disco rígido antes de prosseguir. Se tiver também perdido a senha da sua BIOS, você terá que resetar a sua BIOS abrindo o computador e removendo manualmente a bateria que mantém os dados da BIOS>
Assim que permitir a inicialização através da unidade de CD-ROM ou ativação da unidade de disquete, faça o seguinte:
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).
12.1.1.16. Como posso configurar um serviço para meus usuários sem lhes dar uma conta de acesso ao shell?
For example, if you want to set up a POP service, you don't need to set up a user account for each user accessing it. It's best to set up directory-based authentication through an external service (like Radius, LDAP or an SQL database). Just install the appropriate PAM library (
libpam-radius-auth,
libpam-ldap,
libpam-pgsql or
libpam-mysql), read the documentation (for starters, see
Seção 4.11.1, “Autenticação do Usuário: PAM”) and configure the PAM-enabled service to use the back end you have chosen. This is done by editing the files under
/etc/pam.d/ for your service and modifying the
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".
12.1.2. Meu sistema é vulnerável! (Você tem certeza?)
12.1.2.1. O scanner de vulnerabilidade X diz que meu sistema Debian é vulnerável!
Muitos scanners de avaliação de vulnerabilidades indicarão falso positivos quando forem usados em sistemas Debian, pois podem somente usar checagem de versões para determinar se uma determinada versão de pacote é vulnerável, mas realmente não testam a vulnerabilidade de segurança propriamente dita. Pois a Debian não muda os números de versões quando corrige um pacote (muitas vezes a correção feita em versões novas são reproduzidas nas atuais), algumas ferramentas tendem a achar que um sistema Debian atualizado está vulnerável, quando não está.
Se você acha que o seu sistema está atualizado com patches de segurança, você pode querer usar as referências cruzadas com o banco de dados de vulnerabilidades publicados com os DSAs (veja
Seção 7.2, “Debian Security Advisories”) para afastar a possibilidade de falsos positivos, se a ferramenta que estiver usando inclui referências do CVE.
12.1.2.2. Eu vi um ataque em meus logs de sistema. Meu sistema foi comprometido?
Um traço de ataque nem sempre significa que seu sistema foi comprometido, e você deverá fazer os passos tradicionais para determinar se o sistema está comprometido (veja
Capítulo 11, Depois do comprometimento do sistema (resposta a incidentes)). 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).
12.1.2.3. Eu vi algumas linhas estranhas "MARK" em meus logs: Eu fui comprometido?
Você pode achar as seguintes linhas nos seus logs de sistema:
Dec 30 07:33:36 debian -- MARK --
Dec 30 07:53:36 debian -- MARK --
Dec 30 08:13:36 debian -- MARK --
Isto não indica qualquer tipo de comprometimento e os usuários que estão mudando de versão da Debian devem achar isto estranho. Se o seu sistema não tem uma carga alta (ou muitos serviços ativos), estas linhas devem aparecer entre seus logs. Isto é uma indicação que seu daemon do
syslogd está sendo executado de forma apropriada. Texto extraído da página de manual
syslogd(8):
-m intervalo
O syslogd registra uma marca de horário regularmente. O
intervalo padrão entre duas linhas -- MARK -- é de 20 minutos.
Isto pode ser alterado com esta opção.
O intervalo de zero, desativa totalmente este recurso.
12.1.2.4. Encontrei usuários usando o "su" em meus logs: Eu fui comprometido?
Você pode encontrar linhas em seus logs como:
Apr 1 09:25:01 server su[30315]: + ??? root-nobody
Apr 1 09:25:01 server PAM_unix[30315]: (su) session opened for user nobody by (UID=0)
Não se preocupe muito. Verifique para ver se estas mensagens são devido a tarefas do
cron (normalmente
/etc/cron.daily/find ou
logrotate):
$ grep 25 /etc/crontab
25 6 * * * root test -e /usr/sbin/anacron || run-parts --report
/etc/cron.daily
$ grep nobody /etc/cron.daily/*
find:cd / && updatedb --localuser=nobody 2>/dev/null
12.1.2.5. Encontrei um possível "SYN flooding" em meus logs: Estou sob um ataque?
Se ver linhas como estas em seus logs:
May 1 12:35:25 linux kernel: possible SYN flooding on port X. Sending cookies.
May 1 12:36:25 linux kernel: possible SYN flooding on port X. Sending cookies.
May 1 12:37:25 linux kernel: possible SYN flooding on port X. Sending cookies.
May 1 13:43:11 linux kernel: possible SYN flooding on port X. Sending cookies.
Verifique se existe um número alto de conexões ao servidor usando o
netstat, por exemplo:
linux:~# netstat -ant | grep SYN_RECV | wc -l
9000
Isto é uma indicação de ataque de negação de serviço (denial of service - DoS) contra a porta X do seu sistema (mais provável contra um serviço público tal como um servidor web ou servidor de e-mails). Você deverá ativar os SynCookies TCP em seu kernel, veja
Seção 4.18.2, “Configuring syncookies”. Note, no entanto, que um ataque DoS pode sobrecarregar sua rede até mesmo se você puder parar de fazê-lo travar seus sistemas (devido ao número de descritores de arquivos sendo reduzidos, o sistema pode parar de responder até que o tempo limite de algumas conexões se esgote). O único método efetivo de parar este ataque é contactar seu provedor de rede.
12.1.2.6. Encontrei seções de root estranhas em meus logs: Eu fui comprometido?
Se ver estes tipos de entradas em seu arquivo
/var/log/auth.log:
May 2 11:55:02 linux PAM_unix[1477]: (cron) session closed for user root
May 2 11:55:02 linux PAM_unix[1476]: (cron) session closed for user root
May 2 12:00:01 linux PAM_unix[1536]: (cron) session opened for user root by
(UID=0)
May 2 12:00:02 linux PAM_unix[1536]: (cron) session closed for user root
Estas são devido a uma tarefa do cron sendo executada (neste exemplo, a cada cinco minutos). Para determinar que programa é responsável por estas tarefas, verifique as tarefas nos diretórios: /etc/crontab, /etc/cron.d, /etc/crond.daily e do root crontab sob /var/spool/cron/crontabs.
12.1.2.7. Sofri uma invasão, o que faço?
Existem diversos passos que deve fazer no caso de uma invasão:
12.1.2.8. Como posso rastrear um ataque?
Olhando os logs (caso não tenham sido mexidos) usando sistemas de detecção de intrusão (veja
Seção 10.3, “Configure um sistema de Detecção de Intrusão”),
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?
12.1.2.9. O programa X na Debian é vulnerável, o que fazer?
Primeiro, leve um momento para se certificar se a vulnerabilidade foi anunciada em listas de discussões de segurança públicas (como a Bugtraq) ou outros fóruns. O time da Debian Security se mantém atualizada com estas listas, assim elas também deverão ter conhecimento do problema. Não faça qualquer outra ações se você ver um anúncio em
http://security.debian.org.
Caso nenhuma informação tenha sido publicada, por favor envie um e-mail sobre o(s) pacote(s) afetado(s), assim como uma descrição detalhada da vulnerabilidade (código que comprova isto também é válido) para
mailto:team@security.debian.org. Isto lhe colocará em contato com o time de segurança da Debian.
12.1.2.10. O número de versão de um pacote indica que eu ainda estou usando uma versão vulnerável!
Ao invés de atualizar para uma versão nova, a Debian adapta as correções para a versão que é fornecida com o lançamento estável. A razão disto é para ter certeza que o lançamento estável altere o mínimo possível, assim as coisas não alterarão ou quebrarão de forma inesperada como resultado de uma correção de falha. Você pode verificar se está executando uma versão segura de pacote olhando nos logs de alterações do pacote ou comparando seu número de versão exato (versão do autor - traço- lançamento da Debian) com o número de versão indicado no aviso de segurança da Debian.
