Segurança extrema com LIDS: novos recursos
Quem leu o primeiro artigo sobre LIDS que postei aqui não deve perder esta segunda parte, onde são tratados os novos recursos de sua versão 1.2 e apresentadas as evoluções desse formidável sistema.
Parte 2: LIDS TPE (Trusted Path Execution)
Um dos novos features é o TPE (Trusted Path Execution).
Este novo recurso veio para criar uma lista de paths de execução segura em nosso sistema. Com ele criamos uma ACL que irá verificar toda a execução de programas e scripts em nosso sistema, visando assim barrar possíveis execuções de programas/usuários que não deviam ser executados e em pastas/paths que não deveriam estar.
Para que os binários sejam executados, eles devem ter no MÍNIMO proteção pelo LIDS como READONLY.
Para habilitar essa feature deve-se compilar o kernel com LIDS e habilitar esta linha:
[*] Enable LIDS Trusted Path Execution (TPE) feature.
Para iniciar o modo TPE basta:
# lidsadm -S -- +TPE
Com o TPE podemos solucionar muitos problemas relevantes a usuários executando binários que não deveriam ou de arquivos binários que não deveriam estar sendo executados pela sua máquina a dentro.
Mais a frente vamos ver algumas configurações ilustrativas.
O TPE pode ser dividido em algumas partes interessantes:
Digamos que já tenhamos uma lista com o Trusted path e com o Trusted ACL, a lista irá agir da seguinte maneira para verificar o que pode ou não ser executado:
Trusted User + Trusted Path = usuário pode executar o binário.
Trusted User + Untrusted Path = usuário pode executar o binário.
Untrusted User + Untrusted Path = usuário não pode executar.
Esse é um pequeno exemplo de implementação de regras onde apenas usuários não confiáveis e arquivos que não estão no TP irão ser barrados. Esta implementação teve apenas um caráter didático porque se formos realmente verificar, encontraremos muitas falhas de segurança nesse tipo de regra, se um usuário não confiável executar um tipo de ataque que utilize por exemplo, /lib/ld-linux.so.X <executável>, que está no trusted path... veremos que ele não precisa de muito esforço para explorar essas vulnerabilidades.
Este novo recurso veio para criar uma lista de paths de execução segura em nosso sistema. Com ele criamos uma ACL que irá verificar toda a execução de programas e scripts em nosso sistema, visando assim barrar possíveis execuções de programas/usuários que não deviam ser executados e em pastas/paths que não deveriam estar.
Para que os binários sejam executados, eles devem ter no MÍNIMO proteção pelo LIDS como READONLY.
Para habilitar essa feature deve-se compilar o kernel com LIDS e habilitar esta linha:
[*] Enable LIDS Trusted Path Execution (TPE) feature.
Para iniciar o modo TPE basta:
# lidsadm -S -- +TPE
Com o TPE podemos solucionar muitos problemas relevantes a usuários executando binários que não deveriam ou de arquivos binários que não deveriam estar sendo executados pela sua máquina a dentro.
Mais a frente vamos ver algumas configurações ilustrativas.
O TPE pode ser dividido em algumas partes interessantes:
- Trusted Path: um path confiável é aquele que o diretório atual
do binário e de propriedade do root (uid=0) é o seu grupo ou então que seja
world writable (todo mundo pode escrever).
- Trusted ACL: essa é a lista onde temos os usuários confiáveis
(trusted users). Em adição ao 'root', todo usuário nesta lista será considerado
confiável a executar nossos binários.
- Regras: estas regras serão adicionadas com o lidsadm para dizer se determinado binário será executado ou não levando em consideração a lista de Trusted Path e Trusted ACL.
Digamos que já tenhamos uma lista com o Trusted path e com o Trusted ACL, a lista irá agir da seguinte maneira para verificar o que pode ou não ser executado:
Trusted User + Trusted Path = usuário pode executar o binário.
Trusted User + Untrusted Path = usuário pode executar o binário.
Untrusted User + Untrusted Path = usuário não pode executar.
Esse é um pequeno exemplo de implementação de regras onde apenas usuários não confiáveis e arquivos que não estão no TP irão ser barrados. Esta implementação teve apenas um caráter didático porque se formos realmente verificar, encontraremos muitas falhas de segurança nesse tipo de regra, se um usuário não confiável executar um tipo de ataque que utilize por exemplo, /lib/ld-linux.so.X <executável>, que está no trusted path... veremos que ele não precisa de muito esforço para explorar essas vulnerabilidades.
estou pensando em postar um bom sobre snort.