4.5. Segurança e confidencialidade

Uma das principais características de um sistema Linux ou UNIX é sua capacidade de manter vários usuários ao mesmo tempo (multiusuário) e permitir que esses usuários executem inúmeras tarefas (multitarefas) no mesmo computador simultaneamente. Além disso, o sistema operacional é transparente à rede. Os usuários normalmente não sabem se os dados e aplicativos que usam são fornecidos localmente por suas máquinas ou disponibilizados pela rede.

Com o recurso multiusuário, os dados de usuários diferentes precisam ser armazenados separadamente. A segurança e privacidade precisam ser garantidas. A segurança dos dados já era considerada uma questão importante, mesmo antes de os computadores poderem se vincular através de redes. Como nos dias de hoje, a maior preocupação era a capacidade de manter os dados disponíveis, apesar da perda ou danificação do meio dos dados, na maioria das vezes, um disco rígido.

Esta seção enfoca, principalmente, problemas de confidencialidade e formas de proteger a privacidade de usuários. Porém, ela não se estende o suficiente para abordar o conceito abrangente de segurança, que deve sempre incluir procedimentos para ter um backup regularmente atualizado, utilizável e testado à disposição. Sem isso, você pode ter muita dificuldade na recuperação de seus dados — não só no caso de algum defeito de hardware, mas também se suspeitar de alguém ter adquirido acesso não autorizado e falsificado arquivos.

4.5.1. Segurança local e de rede

Há várias formas de acessar dados:

  • comunicação pessoal com quem possui as informações desejadas ou acesso aos dados através de um computador

  • diretamente do console de um computador (acesso físico)

  • através de uma linha serial

  • usando um link de rede

Em todos esses casos, o usuário deve ser autenticado antes de acessar os recursos ou dados em questão. Um servidor da Web talvez seja menos restritivo a esse respeito, ainda assim, você não gostaria que ele divulgasse todos os seus dados pessoais para qualquer pessoa na rede.

Na lista acima, o primeiro caso é onde a maior quantidade de interação humana está envolvida, por exemplo, quando você contacta um funcionário de um banco e ele solicita que você prove que é a pessoa proprietária daquela conta de banco. Então, solicitam sua assinatura, um PIN ou uma senha para provar que você é aquela pessoa. Em alguns casos, pode ser possível extrair informações de uma pessoa esclarecida apenas mencionando poucos detalhes conhecidos, suficientes para ganhar a confiança dessa pessoa, usando uma retórica inteligente. A vítima pode ser levada a revelar, gradativamente, mais informações, talvez sem nem mesmo se dar conta disso. Entre os hackers, isso é chamado de engenharia social. A única forma de se proteger contra isso é educar as pessoas e saber lidar com linguagem e informações de uma forma consciente. Antes de invadirem sistemas de computador, os invasores geralmente tentam atingir recepcionistas, auxiliares que trabalham na empresa ou até mesmo membros de uma família. Em muitos casos, como um ataque baseado em engenharia social, ele só é descoberto muito tempo depois.

Uma pessoa que deseja obter acesso não autorizado aos seus dados poderia também tentar obtê-lo da forma tradicional, diretamente através do seu hardware. Portanto, a máquina deve ser protegida contra qualquer falsificação, para que ninguém possa remover, substituir ou danificar seus componentes. Isso também se aplica a backups e, até mesmo, a qualquer cabo de rede ou de energia. Proteja também o procedimento de inicialização, pois há algumas combinações de tecla bastante conhecidas que podem provocar um comportamento anormal. Proteja-se contra isso, configurando senhas para o BIOS e para o carregador de boot.

Os terminais seriais conectados a portas seriais ainda são usados em muitos locais. Diferente das interfaces de rede, eles não usam um protocolo de rede para se comunicar com o host. Um cabo simples ou porta infravermelha envia e retorna caracteres simples entre os dispositivos. O próprio cabo é o ponto mais fraco de um sistema desses: com uma impressora mais antiga conectada a ele, é fácil registrar qualquer coisa que seja transmitida pelos cabos. O que se consegue com uma impressora também pode ser feito de outras formas, dependendo do esforço envolvido no ataque.

Ler um arquivo localmente em um host exige outras regras de acesso, diferentes de abrir uma conexão de rede com um servidor em um host diferente. Não há distinção entre segurança local e segurança de rede. A linha é desenhada onde os dados devem ser colocados em pacotes para serem enviados para outro local.

4.5.1.1. Segurança local

A segurança local começa com o ambiente físico, no local onde o computador é executado. Configure sua máquina em um local onde a segurança esteja de acordo com suas expectativas e necessidades. O principal objetivo da segurança local é manter usuários separados entre si, para que nenhum assuma a permissão ou a identidade do outro. Essa é uma regra geral a ser observada, mas é extremamente verdadeira para o root do usuário, que contém a força suprema do sistema. root pode assumir a identidade de qualquer usuário local sem que lhe seja solicitada uma senha e pode ler qualquer arquivo armazenado localmente.

4.5.1.2. Senhas

Em um sistema Linux, as senhas não são armazenadas como texto simples e a string de texto digitada não corresponde diretamente com o padrão salvo. Se fosse assim, todas as contas do seu sistema estariam comprometidas assim que alguém tivesse acesso ao arquivo correspondente. Em vez disso, a senha armazenada é criptografada e, toda vez que é digitada, é novamente criptografada para que as duas strings criptografadas sejam comparadas. Isso oferece mais segurança somente se a senha criptografada não puder ser computada de forma inversa na string de texto original.

Isso pode ser feito através de um tipo especial de algoritmo, também chamado de algoritmo trapdoor, pois ele só funciona em uma direção. Um invasor que obteve a string criptografada não é capaz de obter sua senha simplesmente aplicando o mesmo algoritmo novamente. Em vez disso, seria preciso testar todas as combinações de caracteres possíveis, até encontrar uma que se parecesse com sua senha quando criptografada. Em senhas com oito caracteres, há um número considerável de combinações possíveis de serem calculadas.

Nos anos setenta, dizia-se que esse método seria mais seguro do que outros, devido à relativa lentidão do algoritmo usado, que levava alguns segundos para criptografar apenas uma senha. Entretanto, enquanto isso, os PCs foram se tornando mais potentes o suficiente para executar centenas de milhares ou até milhões de criptografias por segundo. Por causa disso, as senhas criptografadas não devem ficar visíveis para usuários regulares (/etc/shadow não pode ser lida por usuários normais). É até mais importante que senhas não sejam fáceis de adivinhar, no caso de um arquivo de senha ficar visível por algum erro. Conseqüentemente, não é de muita utilidade “traduzir” uma senha como “tantalize” para “t@nt@1lz3”.

Substituir algumas letras da palavra por números parecidos não é seguro o suficiente. Programas para fraudar senhas, que usam dicionários para adivinhar palavras, também testam substituições como essa. Uma forma melhor é criar uma palavra sem um significado comum, mas que só faça sentido para você, como as primeiras letras das palavras de uma frase ou do título de um livro, como “The Name of the Rose” by Umberto Eco (O Nome da Rosa, de Umberto Eco). A senha segura criada ficaria assim: “TNotRbUE9”. Diferentemente, senhas como “beerbuddy” ou “jasmine76” são de fácil adivinhação, mesmo por alguém que tenha pouco conhecimento a seu respeito.

4.5.1.3. O procedimento de inicialização

Configure o sistema de forma que não possa ser inicializado de um disquete ou CD, removendo totalmente as unidades ou configurando uma senha para o BIOS e configurando-o para que inicialize somente a partir de um disco rígido. Normalmente, um sistema Linux é iniciado por um carregador de boot, permitindo que você passe opções adicionais para o kernel inicializado. Para evitar que outros usem esses parâmetros durante a inicialização, configure uma senha adicional em /boot/grub/menu.lst (consulte o Capítulo 9, O Carregador de Boot). Isso é imprescindível para a segurança do sistema. O kernel não só é executado com permissões de root, como também é a primeira autoridade a conceder permissões de root na inicialização do sistema.

4.5.1.4. Permissões de arquivo

Como regra geral, sempre trabalhe com os privilégios mais restritivos possíveis para uma determinada tarefa. Por exemplo, definitivamente, não é necessário ser root para ler ou gravar e-mails. Se o programa de correio possuir um bug, esse bug pode ser explorado para um ataque que atue com as permissões exatas do programa quando foi inicializado. Ao seguir a regra acima, os possíveis danos serão minimizados.

As permissões de mais de 200.000 arquivos incluídos em uma distribuição SUSE são escolhidos cuidadosamente. Um administrador de sistemas que instale softwares adicionais ou outros arquivos deve ser cuidadoso ao fazê-lo, especialmente quando configurar os bits de permissão. Administradores de sistemas experientes e atentos à segurança sempre usam a opção -l com o comando ls, para obter uma lista de arquivos extensa, que ajuda na detecção imediata de qualquer permissão de arquivo incorreta. Um atributo de arquivo incorreto não significa somente que os arquivos podem ser mudados ou apagados. Esses arquivos modificados podem ser executados pelo root ou, no caso de arquivos de configuração, programas poderiam usar tais arquivos com as permissões do root. Isso aumenta significativamente as possibilidades de um ataque. Ataques como esse são chamados de cuckoo eggs (ovos de cuco), pois o programa (o ovo) é executado (quebrado) por um usuário diferente (pássaro), exatamente como um cuco engana outros pássaros para quebrar seus ovos.

Um sistema SUSE Linux inclui os arquivos permissions, permissions.easy, permissions.secure e permissions.paranoid, todos no diretório /etc. A função desses arquivos é definir permissões especiais, como diretórios graváveis mundialmente ou, para arquivos, o bit do setuser ID (programas com o conjunto de bits setuser ID não são executados com as permissões do usuário que os inicializou e sim com as do proprietário do arquivo, na maioria dos casos, o root). Um administrador pode usar o arquivo /etc/permissions.local para adicionar suas próprias configurações.

Para definir qual dos arquivos acima é usado pelos programas de configuração do SUSE para definir permissões compatíveis, selecione Segurança no YaST. Para saber mais sobre esse tópico, leia os comentários em /etc/permissions ou consulte a página do manual do chmod (man chmod).

4.5.1.5. Bugs de string de formato e overflows de buffer

Deve-se ter extremo cuidado sempre que um programa cuja função é processar dados possa ser modificado por um usuário. Porém, esse é um problema mais para o programador de um aplicativo do que para usuários regulares. O programador deve verificar se o aplicativo interpreta os dados de forma correta, sem gravá-lo em áreas da memória muito pequenas para mantê-lo. Da mesma forma, o programa deve manter os dados de forma consistente, usando as interfaces definidas para esse fim.

Um overflow de buffer pode ocorrer se o tamanho real do buffer da memória não for levado em conta quando uma gravação for feita nesse buffer. Há casos em que esses dados (como os gerados pelo usuário) usam mais espaço do que o disponibilizado no buffer. Como conseqüência, os dados são gravados além da área final do buffer, o que, em certas circunstâncias, possibilita que um programa execute seqüências de programa influenciado pelo usuário (e não pelo programador), em vez de apenas processar os dados do usuário. Um bug desse tipo pode trazer sérias conseqüências, especialmente se o programa estiver sendo executado com privilégios especiais (consulte Seção 4.5.1.4, “Permissões de arquivo”).

Bugs de string de formato funciona um pouco diferente, porém novamente é a entrada do usuário que pode controlar a bandeja do programa. Na maioria dos casos, esses erros de programação são explorados com programas executados com permissões especiais — programas setuid e setgid — o que também significa que você pode proteger os dados e o sistema desses bugs, removendo dos programas os privilégios de execução correspondentes. Novamente, a melhor forma é aplicar uma política de uso de privilégios mais baixos possíveis (consulte Seção 4.5.1.4, “Permissões de arquivo”).

Como os overflows de buffer e bugs de string de formato são bugs relacionados ao manuseio de dados do usuário, eles não são só exploráveis se o acesso tiver sido concedido a uma conta local. Muitos dos bugs relatados também podem ser explorados por um link de rede. Da mesma forma, bugs de string de formato e overflows de buffer devem ser classificados como relevantes tanto para a segurança de rede quanto a local.

4.5.1.6. Vírus

Contrário ao que dizem algumas pessoas, há vírus que são executados no Linux. Entretanto, os vírus conhecidos foram criados por seus autores como um protótipo, para provar que a técnica funciona como determinado. Nenhum desses vírus foi apontado em lugar algum até agora.

Os vírus não conseguem sobreviver e se espalharem sem que haja um host onde possam permanecer. Nesse caso, o host seria um programa ou uma área de armazenamento importante do sistema, como o MBR (Master Boot Record), que precisa ser gravável para o código de programa do vírus. Devido aos seus recursos de multiusuário, o Linux pode restringir o acesso de gravação a certos arquivos especialmente importantes para arquivos do sistema. Portanto, se você trabalhou normalmente com as permissões de root, as chances de o sistema ser infectado por vírus aumentarão. Por outro lado, se você seguiu os princípios do uso de privilégios mais baixos possíveis, conforme mencionado anteriormente, há poucas chances de um vírus entrar no computador.

Independente disso, nunca execute um programa às pressas a partir de algum site da Internet que você não conheça bem. Os pacotes RPM do SUSE possuem uma assinatura criptográfica como rótulo digital indicando o extremo cuidado utilizado durante sua criação. Os vírus são um sinal típico de que o administrador ou o usuário não possuem uma precaução de segurança necessária, colocando em risco um sistema que deveria estar altamente protegido.

Vírus não devem ser confundidos com worms, que pertencem inteiramente ao mundo das redes. Worms não precisam de um host para se espalharem.

4.5.1.7. Segurança de rede

A segurança da rede é importante para a proteção contra um ataque iniciado externamente. O procedimento de login típico, que exige um nome de usuário e senha para a autenticação do usuário ainda é uma questão de segurança local. No caso específico de efetuar login em uma rede, existe uma diferença entre os dois aspectos de segurança. O que acontece até a autenticação real é a segurança da rede e tudo o que acontece depois disso é a segurança local.

4.5.1.8. Sistema x window e autenticação x

Conforme mencionado no início, a transparência da rede é uma das características principais de um sistema UNIX. X, o sistema de janelas dos sistemas operacionais do UNIX, usa esse recurso de uma forma impressionante. Com X, basicamente não há problemas para efetuar login em um host remoto e iniciar um programa gráfico que será, depois, enviado para a rede para ser exibido no computador.

Quando um cliente X deve ser exibido remotamente usando um servidor X, o último deve proteger o recurso gerenciado por ele (a tela) de acessos não autorizados. Em termos mais concretos, certas permissões precisam ser fornecidas ao programa cliente. Com o sistema X Window, há duas formas de fazer isso, chamadas controle de acesso baseado em host e controle de acesso baseado em cookie. O anterior se baseia no endereço IP do host onde o cliente deve ser executado. O programa que controla isso é o xhost. O xhost. insere o endereço IP de um cliente legítimo em um banco de dados mínimo pertencente ao servidor X. Entretanto, basear-se em endereços IP para autenticação não é muito seguro. Por exemplo, se houvesse um segundo usuário trabalhando no host que envia o programa cliente, esse usuário também teria acesso ao servidor X — o mesmo acesso de alguém que desejasse roubar o endereço IP. Devido a essas faltas, esse método de autenticação não é descrito mais detalhadamente aqui, mas você pode obter mais informações sobre ele com o man xhost.

No caso do controle de acesso baseado em cookie, uma string de caracteres gerada é conhecida somente pelo servidor X e pelo usuário legítimo, da mesma forma que uma placa ID de algum tipo. Esse cookie (a palavra é originada não de cookies (biscoitos) comuns, mas dos fortune cookies chineses (biscoitos da sorte chineses) que contêm um epigrama) é armazenado durante o login no arquivo .Xauthority no diretório principal do usuário e fica disponível para qualquer cliente X que deseje usar o servidor X para exibir uma janela. O arquivo .Xauthority pode ser examinado pelo usuário com a ferramenta xauth. Se você renomeasse o .Xauthority ou se apagasse acidentalmente o arquivo do seu diretório principal, não conseguiria abrir nenhuma janela ou cliente X novos. Leia mais sobre os mecanismos de segurança do sistema X Window na página do manual do Xsecurity (man Xsecurity).

O SSH (secure shell) pode ser usado para criptografar uma conexão de rede completamente e encaminhá-la para um servidor X de forma transparente, sem que o mecanismo de criptografia seja percebido pelo usuário. Também é chamado de encaminhamento de X. O encaminhamento de X é feito simulando um servidor X no lado do servidor e configurando uma variável DISPLAY para o shell no host remoto. Informações detalhadas sobre o SSH podem ser encontradas na Seção 4.2, “SSH: operações seguras de rede”.

[Warning]Atenção

Se você não considera seguro o host onde efetua login, não use o encaminhamento de X. Com o encaminhamento de X habilitado, um invasor pode se autenticar através da conexão SSH e invadir o servidor X para farejar sua entrada de teclado, por exemplo.

4.5.1.9. Bugs de string de formato e overflows de buffer

Conforme discutido na Seção 4.5.1.5, “Bugs de string de formato e overflows de buffer”, os bugs de overflows de buffer e de strings de formato devem ser classificados como relevantes tanto para a segurança de rede quanto a local. Como as variantes locais desses bugs, os overflows de buffer em programas de rede, quando são explorados com sucesso, quase sempre são usados para obter permissões de root. Mesmo que não seja o caso, um invasor poderia usar o bug para ter acesso a uma conta local não privilegiada para explorar quaisquer outras vulnerabilidades que pudessem existir no sistema.

Bugs de overflows de buffer e de strings de formato exploráveis em um link de rede são, certamente, a forma mais freqüente de ataques remotos em geral. As explorações desses programas — que exploram furos de segurança recentemente encontrados — geralmente são enviadas para listas de discussão de segurança. Elas podem ser usadas para identificar a vulnerabilidade, sem saber os detalhes do código. Através dos anos, a experiência mostrou que a disponibilidade de códigos de exploração contribuiu para a criação de sistemas operacionais mais seguros, obviamente devido ao fato de os criadores de sistemas operacionais terem sido forçados a consertar os problemas em seus softwares. Com software livre, qualquer pessoa tem acesso ao código fonte (o SUSE Linux vem com todos os códigos fonte disponíveis) e qualquer um que encontre uma vulnerabilidade e seu código de exploração poderá submeter um patch para consertar o bug correspondente.

4.5.1.10. DoS (Denial of Service)

A finalidade de um ataque DoS (denial of service) é bloquear um programa de servidor ou mesmo todo o sistema, algo que pode ser realizado de várias formas: sobrecarregar o servidor, mantendo-o ocupado com pacotes de lixo ou explorar um overflow de buffer remoto. Geralmente, a única finalidade de um ataque DoS é fazer o serviço desaparecer. Entretanto, quando um determinado serviço não está mais disponível, as comunicações podem ficar vulneráveis a ataques man-in-the-middle (farejamento, roubo de conexão de TCP, falsificação) e envenenamento do DNS.

4.5.1.11. Man in the middle: farejamento, roubo, falsificação

Em geral, qualquer ataque remoto executado por um invasor que se coloca entre os hosts de comunicação é chamado de ataque man-in-the-middle. O que a maioria dos tipos de ataques man-in-the-middle tem em comum é que a vítima, geralmente, não percebe o que está acontecendo. Há muitas variantes possíveis, por exemplo, o invasor pode escolher uma solicitação de conexão e encaminhá-la para a máquina de destino. Agora, a vítima estabeleceu, involuntariamente, uma conexão com o host errado, porque a outra extremidade está posando como a máquina de destino legítima.

A forma mais simples de um ataque man-in-the-middle é o farejamento — o invasor “apenas” escuta a passagem do tráfego de rede. Em um ataque mais complexo, o “man in the middle” pode tentar controlar uma conexão já estabelecida (roubar). Para fazer isso, o invasor precisa analisar os pacotes durante algum tempo, para ser capaz de prever os números da seqüência do TCP pertencentes à conexão. Quando o invasor finalmente identifica a função do host de destino, as vítimas percebem isso, pois elas recebem uma mensagem de erro informando que a conexão foi encerrada devido a uma falha. O que facilita os invasores é o fato de haver protocolos pouco seguros contra roubos através de criptografia, que apenas executam um procedimento de autenticação simples quando estabelecem a conexão.

Falsificação é um ataque onde os pacotes são modificados para conter dados de origem falsificada, normalmente, o endereço IP. A maioria dos ataques ativos consiste em enviar esses pacotes falsos — algo que, em uma máquina Linux, só pode ser feito pelo superusuário (root).

Muitos dos ataques mencionados são executados junto com um DoS. Se um invasor vir uma oportunidade de desativar abruptamente um host, mesmo que por um curto período, será mais fácil para ele usar o ataque ativo, pois o host não será capaz de interferir contra o ataque por algum tempo.

4.5.1.12. Envenenamento de DNS

O envenenamento de DNS significa que o invasor corrompe o cache de um servidor DNS respondendo a ele com pacotes de respostas de DNS falsificados, para tentar fazer com que o servidor envie certos dados a uma vítima que esteja solicitando informações a esse servidor. Muitos servidores mantêm uma relação de confiança com outros hosts, baseada nos endereços IP ou nos nomes de host. O invasor precisa ter um bom conhecimento da estrutura real das relações de confiança entre os hosts, para ser distinguido como um dos hosts confiáveis. Normalmente, o invasor analisa alguns pacotes recebidos do servidor para obter as informações necessárias. O invasor geralmente também precisa planejar um ataque DoS bem programado ao servidor de nomes. Proteja-se, usando conexões criptografadas que possam verificar a identidade dos hosts aos quais deve se conectar.

4.5.1.13. Worms

Worms geralmente são confundidas com vírus, mas há uma clara diferença entre os dois. Diferente dos vírus, worms não precisam infectar um programa de host para viverem. Em vez disso, suas especialidades são se espalharem o mais rápido possível por estruturas de rede. Os worms que apareciam antigamente, como Ramen, Lion ou Adore, faziam uso de falhas conhecidas na segurança dos programas de servidor, como bind8 ou lprNG. A proteção contra worms é relativamente fácil. Considerando que um certo tempo decorre entre a descoberta de uma falha na segurança e o momento em que o worm entra no servidor, há uma boa chance de uma versão atualizada do programa afetado estar disponível a tempo. Isso só tem utilidade se o administrador realmente instalar as atualizações de segurança nos sistemas em questão.

4.5.2. Algumas dicas e truques gerais de segurança

Para usar a segurança de forma competente, é importante estar atualizado com os novos produtos desenvolvidos e manter-se informado sobre as questões de segurança mais recentes. Uma boa forma de proteger o sistema contra problemas de todos os tipos é obter e instalar os pacotes atualizados recomendados pelos anúncios de segurança o mais rápido possível. Os anúncios de segurança do SUSE são publicados em uma lista de discussão na qual você pode se inscrever através do link http://www.novell.com/linux/security/securitysupport.html. A lista suse-security-announce@suse.de é a fonte principal de informações referente a pacotes atualizados e inclui membros da equipe de segurança do SUSE entre seus contribuintes ativos.

A lista de discussão suse-security@suse.de é um bom local para discutir quaisquer problemas de segurança de seu interesse. Inscreva-se nela na mesma página da Web.

bugtraq@securityfocus.com é uma das listas de discussão sobre segurança mais conhecidas no mundo. A leitura dessa lista, que recebe entre 15 a 20 publicações por dia, é recomendada. Mais informações podem ser encontradas em http://www.securityfocus.com.

A seguir, uma lista de regras que podem ser úteis para lidar com questões de segurança básica:

  • De acordo com a regra de uso do conjunto de permissões mais restritivo para cada trabalho, evite fazer seus trabalho regulares no root. Isso reduzirá o risco de obter um cuckoo egg (ovo do cuco) ou um vírus e protegerá seu computador dos seus próprios erros.

  • Se possível, tente sempre usar conexões criptografadas para trabalhar em uma máquina remota. O uso de ssh (shell seguro) para substituir telnet, ftp, rsh e rlogin deve ser uma prática padrão.

  • Evite usar métodos de autenticação baseados em endereços IP isolados.

  • Tente manter os pacotes relacionados à rede mais importantes atualizados e inscreva-se nas listas de discussão correspondentes, para receber anúncios sobre novas versões desses programas (bind, sendmail, ssh, etc.). O mesmo deve se aplicar aos softwares relevantes à segurança local.

  • Mude o arquivo /etc/permissions, para otimizar as permissões dos arquivos cruciais para a segurança do seu sistema. Se você remover o setuid bit de um programa, haverá grandes chances de ele não ser mais capaz de executar suas respectivas funções da forma devida. Por outro lado, considere que, na maioria dos casos, o programa não será mais um risco potencial à segurança. Você pode usar um método semelhante, com arquivos e diretórios internacionalmente graváveis.

  • Desabilite quaisquer serviços de rede que não sejam absolutamente necessários para o servidor funcionar adequadamente. Isso torna o sistema mais seguro. Portas abertas, com o estado do socket LISTEN, podem ser encontradas no programa netstat. Quanto às opções, é recomendável usar netstat -ap ou netstat -anp. A opção -p permite que você veja que processo está ocupando uma porta com qual nome.

    Compare os resultados do netstat com os de uma exploração de porta mais completa feita fora do host. Um programa excelente para esse trabalho é o nmap, que não só verifica as portas da máquina, como também conclui quais serviços estão aguardando atrás delas. Entretanto, a exploração da porta pode ser interpretada como um ato agressivo, portanto, não a faça em um host sem a aprovação explícita do administrador. Por fim, lembre-se de que é importante não só explorar as portas TCP, mas também as portas UDP (opções -sS e -sU).

  • Para monitorar a integridade dos arquivos do seu sistema de forma confiável, use o programa AIDE (Advanced Intrusion Detection Environment), disponível no SUSE Linux. Criptografe o banco de dados criado pelo AIDE, para evitar que alguém o falsifique. Além disso, mantenha um backup desse banco de dados disponível fora da máquina, armazenado em um meio de dados externo não conectado à rede.

  • Instale cuidadosamente qualquer software de terceiros. Houve casos de um hacker ter criado um Cavalo de Tróia no arquivo tar de um pacote de softwares de segurança, mas, felizmente, o ataque foi descoberto rapidamente. Se você instalar um pacote binário, não tenha dúvidas quanto ao site de onde foi feito o seu download.

    Os pacotes RPM do SUSE são gpg-signed (assinados pelo gpg). A chave usada pelo SUSE para a assinatura é:

    Chave de assinatura de pacote do SUSE: ID:9C800ACA 2000-10-19 <build@suse.de>

    Impressão digital da chave = 79C1 79B2 E1C8 20C1 890F 9994 A84E DAE8 9C80 0ACA

    O comando rpm --checksig package.rpm mostra se o checksum e a assinatura de um pacote desinstalado estão corretos. Encontre a chave no primeiro CD de distribuição e na maioria dos servidores de chaves em todo o mundo.

  • Verifique os backups de arquivos do sistema e usuário regularmente. Considere que, se você não testar os backups para ver se funcionam, eles serão, na verdade, inúteis.

  • Verifique seus arquivos de registro. Sempre que possível, grave um pequeno script para pesquisar entradas suspeitas. Com certeza, essa não é exatamente uma tarefa trivial. No final, somente você saberá quais entradas não são comuns e quais são.

  • Use o tcp_wrapper para restringir o acesso a serviços individuais executados na sua máquina, para que você tenha controle total sobre quais endereços IP podem se conectar a um serviço. Para obter informações adicionais referentes ao tcp_wrapper, consulte as páginas do manual do tcpd e do hosts_access (man 8 tcpd, man hosts_access).

  • Use o SuSEfirewall para aprimorar a segurança fornecida pelo tcpd (tcp_wrapper).

  • Defina suas medidas de segurança para serem redundantes: uma mensagem vista duas vezes é melhor do que não ver mensagem alguma.

4.5.3. Usando o Central Security Reporting Address (Endereço de Relatórios de Segurança Central)

Se encontrar um problema relacionado à segurança (verifique, primeiro, os pacotes de atualização disponíveis), escreva um e-mail para security@suse.de. Inclua uma descrição detalhada do problema e o número de versão do pacote em questão. O SUSE tentará enviar uma resposta o mais rápido possível. Você é incentivado a criptografar por pgp suas mensagens de e-mail. A chave pgp do SUSE é:


ID:3D25D3D9 1999-03-06 SUSE Security Team <security@suse.de> 
Impressão digital da chave = 73 5F 2E 99 DF DB 94 C4 8F 5A A3 AE AF 22 F2 D5 

Essa chave também está disponível para download em http://www.novell.com/linux/security/securitysupport.html.