Em um passado não muito distante, um servidor configurado corretamente tinha seus riscos de ser invadido, mas esse risco era fisicamente dimencionado até os limites da sua rede local. Mas nos dias de hoje isso não é mais possível, por causa da chegada da Internet.
O grande crescimento de computadores interconectados, o crescimento de serviços virtuais e a quantidade de softwares com finalidades ilícitas, trazem como consequência a preocupação de se defender dessas pessoas mal intencionadas que posso utilizar esses softwares que tentam de várias formas invadir seu computador.
Existem vários aplicativos voltados a detectar a invasão do seu sistema, mas existem dois tipos de IDS, o que trabalha na user space (nível de usuário) ou kernel space (nível de kernel).
Podemos dizer que os IDS do tipo tripware que trabalha na camada de usuário podem ser mais vulneráveis, sendo assim burlados com mais facilidade, porque a maioria desses IDS tem arquivos de configuração, onde é informado , quais diretórios ou arquivos que precisam ter a proteção do IDS.
Caso a pessoa que efetuar a invasão não precisar fazer nenhuma alteração em arquivos, que estão relacionados no arquivo de configuração do IDS, somente fizer alterações em arquivos não configurados no IDS ou na camada de kernel ela possivelmente ela não será notada,tudo depende do contexto como o acesso arbitrário ocorreu.
Já com um sistema configurado com um IDS que esteja na camada de kernel, a dificuldade aumenta porque tudo o que a pessoa estiver tentando executar, gerará uma chamada no kernel(systemcall), assim como o IDS está na camada de kernel, todas as chamadas feitas geram mensagens de logs.
O registro das atividades dos usuários e serviços dos sistemas é, notoriamente, muito importante para os administradores e como foi citado o fato de todas as chamadas ao sistema que são negadas serem registradas, cria um cenário muito importante para auditorias futuras.
A importância de registro dos eventos do sistemas é tanta, que na norma NBR ISO/IEC 17799, o item 9.7.1 é todo dedicado ao “Registro (log) de eventos. Deixando claro que registro de eventos são também prioridade em uma política de segurança.
Em um sistema de log, oficialmente somente o root poderia alterar os arquivos de log, já com o Lids aplicado, nem o root teria o poder de alterar esses arquivos.
Lids é um path de segurança no nível de kernel, ou seja, é necessário a recompilação do kernel para a aplicação do path. Esse patch pode ser encontrado no site oficial do LIDS “www.lids.org” e o fonte do kernel em “www.kernel.org”
As ferramentas que acompanham o patch do Lids “lidsadm e lidsconf” são fáceis de utilizar e de configurar, elas estão no nível de usuário e servem para configurar as ACLs que serão determinadas pelo root, que, dependendo da configuração das ACLs do Lids, não será mais o dono do sistema, mas sim somente um usuário comum.
Como o Lids está no nivel de kernel, ele é acionado já no início do boot do sistema, portanto, já na inicialização o sistema se encontra protegido.
Com esse sistema de proteção no boot, ela nega permissão a muitos serviços padrões do sistema, como o dmesg, que gera um relatório de todo a inicialização do kernel. Isso é muito importante, por isso que se deve liberar o dmesg a gravar no diretório /var/log/.
# lidsconf -A BOOT -o /var/log/dmesg -j WRITE
Todos sabem que o arquivo /etc/shadow contém as senhas de todos os usuários do sistema e que as senhas estão criptografadas. Mesmo assim, existe um grande risco de alguém descobrí-las.
Por esse motivo, o LIDS trabalha da seguinte forma: ainda como usuário root é possivel determinar que nenhum binário vá conseguir o acesso a esse arquivo de senhas, colocando uma regra de DENY (proibido), por exemplo:
# lidsconf -A -o /etc/shadow -j DENY
Mas o mais importante é que para toda regra existem as exceções, podendo assim liberar qual binário poderá acessar o /etc/shadow como READONLY (somente leitura). Um exemplo claro, seria o binário /bin/login, que precisa ter permissão de leitura no arquivo para que possa efetuar o login normalmente.
# lidsconf -A -s /bin/login -o /etc/shadow -j READONLY
Mas caso se tente visualizar o conteúdo do arquivo com outros binários (por exemplo: vi, cat, more, etc..), o IDS acusará que esse arquivo não existe.
Da mesma que é possivel proibir o acesso as arquivos para todos os binários e liberar para alguns, também existe a possibilidade de ocultar processos, isso mesmo esconder os processos. Veja por exemplo como ocultar o processo do serviço ssh.
# ldisconf -A -s /usr/sbin/sshd -o CAP_HIDDEN -j GRANT
Quando tentar listar os processos da máquina, esse processo do serviço ssh não aparecerá, mas o serviço está ativo.
Diante desse poder de fogo sugiro como a melhor opção seria utilizar os dois sistemas de IDS, para que vc esteja protegido na camada de usuário e na camada de kernel. Assim dificultado em muito possiveis atividades arbritárias.
Mesmo hoje tendo recursos como LIDS e outros como o SELinux, GrSecurity, devemos pensar sempre de forma estratégica em tudo que for possivel e viável tanto na Kernel Space como na User Space, pois em algumas situações como uma estação de trabalho fica impraticavel o uso de um recurso com LIDS.
O Lids também é um mecanismo a mais para aumentar o nível de segurança de um sistema operacional buscando atender também as diretrizes inerentes ao nível C2 de segurança no que diz respeito o Sistema Operacional.
O nivel C2 recomendado pelo TCSEC ” Trusted Computer System Evaluation Criteria”, que é nível de segurança minimo requerido pelo governo Americano e utilizada em algumas instituições no Brasil.
Outro valor agregado nessa história é que somente conhecendo profudamente como o sistema funciona e as respectivas aplicações que estejam sendo executadas, conseguimos tirar proveito de um recurso como LIDS, pois do contrário, simplesmente nada vai funcionar corretamente, ou seja, além de melhoramos a segurança do sistema, nossa base de conhecimento se aprimora.
