Muitas vezes, temos visto o uso do Zabbix como uma simples ferramenta de monitoramento de ativos de rede e infraestrutura de Tecnologia da Informação e Comunicação (TIC). Embora esse conceito não esteja errado, é igualmente importante compreender que com o avanço de suas versões, mais e mais funcionalidades vêm sendo disponibilizadas para outros tipos de monitoramento, seguindo para análises avançadas de dados e visualizações magníficas através de novos e modernos widgets da camada de frontend.
Neste pequeno blogpost, vamos explorar um pouco de algumas funcionalidades existentes e pouco faladas do Zabbix, as quais contribuem para o amadurecimento da disciplina de segurança cibernética nas organizações, tema este que vem se tornando cada vez mais requisitado e crítico no ambiente corporativa.
FIM – File Integrity Monitoring
Um conceito muito comum entre ferramentas de segurança da informação, especificamente em ferramentas do tipo SIEM/XDR (Security Information Event Management/Extended Detection and Response) é o FIM.
O nome é bem sugestivo quanto à sua usabilidade, contudo, algumas ferramentas trazem este recurso como uma de suas principais funcionalidades e para quem usa Zabbix, elas também estão lá, só não estampadas com este mesmo nome.
Aqui, vamos tratar o FIM com um conceito e não apenas uma funcionalidade. Isso porque queremos alcançar um resultado, e não ter um menu com um nome para dizer que estamos em conformidade suando nossa ferramenta. De fato, o resultado precisa ser mais importante que uma simples “propaganda”.
O que esperar do FIM?
Imagine que exista em seus servidores alguns diretórios e/ou arquivos tão importantes que você não possa deixar de monitorá-los quanto a alterações, inserções e deleção de dados. Ou ainda, os arquivos possuem proprietários e propriedades que não podem ser alteradas pois, do contrário, os sistemas que dependem dele podem perder a capacidade de lê-los e executar suas funções. É isso, minimamente, que esperamos do FIM como funcionalidade.
Para ilustrar um pouco melhor, considere um serviço de banco de dados como o MariaDB:
# ls -lR /etc/mysql/
/etc/mysql/:
total 24
drwxr-xr-x 2 root root 4096 Jun 25 18:40 conf.d
-rwxr-xr-x 1 root root 1740 Nov 30 2023 debian-start
-rw——- 1 root root 544 Jun 25 18:43 debian.cnf
-rw-r–r– 1 root root 1126 Nov 30 2023 mariadb.cnf
drwxr-xr-x 2 root root 4096 Sep 30 16:36 mariadb.conf.d
lrwxrwxrwx 1 root root 24 Oct 20 2020 my.cnf -> /etc/alternatives/my.cnf
-rw-r–r– 1 root root 839 Oct 20 2020 my.cnf.fallback
/etc/mysql/conf.d:
total 8
-rw-r–r– 1 root root 8 Oct 20 2020 mysql.cnf
-rw-r–r– 1 root root 55 Oct 20 2020 mysqldump.cnf
/etc/mysql/mariadb.conf.d:
total 40
-rw-r–r– 1 root root 575 Nov 30 2023 50-client.cnf
-rw-r–r– 1 root root 231 Nov 30 2023 50-mysql-clients.cnf
-rw-r–r– 1 root root 927 Nov 30 2023 50-mysqld_safe.cnf
-rw-r–r– 1 root root 3795 Sep 30 16:36 50-server.cnf
-rw-r–r– 1 root root 570 Nov 30 2023 60-galera.cnf
-rw-r–r– 1 root root 76 Nov 8 2023 provider_bzip2.cnf
-rw-r–r– 1 root root 72 Nov 8 2023 provider_lz4.cnf
-rw-r–r– 1 root root 74 Nov 8 2023 provider_lzma.cnf
-rw-r–r– 1 root root 72 Nov 8 2023 provider_lzo.cnf
-rw-r–r– 1 root root 78 Nov 8 2023 provider_snappy.cnf
Todos os arquivos, diretórios e subdiretórios listados acima já foram configurados e o sistema, seja qual for, está em perfeito funcionamento. Contudo, se alguém de forma repentina resolve alterar uma configuração no arquivo “/etc/mysql/mariadb.conf.d/50-server.cnf”, isso pode ser um desastre para o serviço, ou não, mas o importante é ter o monitoramento desse escopo e avisar quem é interessado no tema para que seja feita uma análise adequada.
E o Zabbix pode ajudar com isso. Vejamos como.
Zabbix e funções para FIM
Considere que o Zabbix agent está instalado no servidor a ser monitorado:
vfs.dir.count[/etc/mysql]
Com esta chave, podemos contabilizar os objetos presentes dentro do diretório “/etc/mysql”. Posteriormente, podemos criar uma trigger a ser ativada se houver qualquer alteração relacionada ao número inicial da coleta, ou seja, alguém apagou ou inseriu um arquivo ou diretório neste local.
vfs.dir.size[/etc/mysql]
Com esta chave, podemos conhecer o total utilizado em bytes pelos diretórios e arquivos de configuração, de forma que no futuro, podemos criar uma trigger que seja ativada quando esse tamanho for alterado, sugerindo deleção ou adição de algum arquivo.
vfs.file.exists[/etc/mysql/mariadb.conf.d/50-server.cnf]
Dentre vários arquivos importantes, podemos ter um interesse maior em alguns arquivos de configuração e podemos validar sua existência. Desse modo, podemos criar uma trigger que seja ativada quando este arquivo deixar de existir. Isso claramente vai nos dizer que algo importante desapareceu.
Neste caso, o valor “1” representa um “OK” para a existência do arquivo.
vfs.file.cksum[/etc/mysql/mariadb.conf.d/50-server.cnf,sha256]
Além de avaliar a existência do arquivo de configuração que consideramos importante, precisamos ser informados se algo nele for alterado. Esta chave se encarrega de avaliar isso, gerando um hash em alguns formatos possíveis, de forma que uma trigger possa ser ativada no caso de mudança do hash, o que seria reflexo da alteração do arquivo (infelizmente, não saberemos qual foi a alteração).
vfs.file.regmatch[/etc/mysql/mariadb.conf.d/50-server.cnf,^max_connections\s+=\s+(\d+)]
Pode ser que tenhamos um parâmetro especial de nosso interesse. Por exemplo, o número máximo de conexões permitidas ao banco de dados. Monitorar isso é importante porque se a configuração for a padrão (default), significa que não houve “tunning” no banco de dados ou ainda, pode significar que alguém simplesmente apagou essa linha ou ainda, a comentou, fazendo com que ela fosse ignorada pelo sistema. Então, verificar se o parâmetro existe e está configurado, é importante.
Neste caso, o número “1” representa que a expressão regular foi encontrada com sucesso, ou seja, a configuração ou parâmetro que precisamos que exista, está lá.
vfs.file.regexp[/etc/mysql/mariadb.conf.d/50-server.cnf,^max_connections\s+=\s+(\d+),,,,\1]
Além da existência e da integridade do arquivo, é possível sim saber o que foi alterado nele. A questão é que teremos de especificar a configuração de interesse por uma expressão regular. Por exemplo, considerando que o número máximo de conexões permitidas pelo sistema de banco de dados é “x”, podemos ser alertados por uma trigger se passar a ser “y” ou “z” ou no caso de qualquer outro valor diferente de “x”. Essa configuração permite monitorar o parâmetro de interesse com precisão. Essa lógica pode ser aplicada a qualquer outro parâmetro que você ache importante e claro, existe ainda uma outra maneira de automatizar isso. Não abordaremos essa automatização.
Neste caso, o parâmetro que define o número máximo de conexões não apenas está lá, como também sabemos qual é o número de conexões. Dessa forma, teremos o histórico da parametrização aplicada, no caso de ela ser alterada em algum momento.
vfs.file.owner[/etc/mysql/mariadb.conf.d/50-server.cnf]
vfs.file.owner[/etc/mysql/mariadb.conf.d/50-server.cnf,group]
As duas chaves acima nos permitem saber quem é o proprietário de um arquivo e no caso de um sistema Linux, o grupo proprietário. Podemos ainda optar pelo nome do usuário ou seu uid no sistema. Claro, uma trigger pode ser ativada e nos alertar no caso de alteração de proprietário, indicando que alguém está se “apoderando” de um arquivo importante no sistema.
vfs.file.permissions[/etc/mysql/mariadb.conf.d/50-server.cnf]
A chave acima nos permite conhecer as permissões de um arquivo. Leitura, escrita, leitura e escrita, execução, se há um bit especial na permissão. Claro, uma trigger pode ser ativada nos alertar no caso de alteração de permissão no arquivo.
vfs.file.attr[/etc/mysql/mariadb.conf.d/50-server.cnf]
A chave acima não existe. Ela foi criada a partir de um UserParameter, ou seja, uma personalização de verificação de um comando que, no caso, verifica os atributos de um determinado arquivo. Considere o comando abaixo sendo executado diretamente no terminal do seu sistema:
# lsattr /etc/mysql/mariadb.conf.d/50-server.cnf
————–e——- /etc/mysql/mariadb.conf.d/50-server.cnf
O que nos interessa são os atributos:
————–e——-
Se alguém que invade o sistema alterar o atributo de um arquivo por exemplo, com o comando:
# chattr +A /etc/mysql/mariadb.conf.d/50-server.cnf
# lsattr /etc/mysql/mariadb.conf.d/50-server.cnf
——-A——e——- /etc/mysql/mariadb.conf.d/50-server.cnf
Pode significar que alguém não quer que o sistema registre quando este arquivo foi acessado (vide manual do comando chattr). Ou ainda, qualquer outro atributo pode ser acrescentado ou retirado e isso pode ser um risco ao sistema, pois esses atributos podem mudar até mesmo a maneira como os arquivos são acessados ou como eles são armazenados no disco e posteriormente lidos. Então, podemos criar um UserParmeter da seguinte forma:
# cd /etc/zabbix/zabbix_agent2.d/
# echo “UserParameter=vfs.file.attr[*],lsattr \$1 | cut -d\” \” -f1″ > attr.conf
# zabbix_agent2 -R userparameter_reload
E por fim, podemos testar a leitura dos atributos ainda pelo terminal:
# zabbix_agent2 -t vfs.file.attr[/etc/mysql/mariadb.conf.d/50-server.cnf]
vfs.file.attr[/etc/mysql/mariadb.conf.d/50-server.cnf][s|——-A——e——-]
Podes experimentar agora também pelo frontend.
Ao criar o item, não se esqueça de criar a trigger que deve ser ativada caso haja uma mudança no atributo de um arquivo, seja qual for.
De olho no tempo de acesso e modificação dos arquivos
Para avançar um pouco mais no conceito do FIM, devemos nos perguntar se monitoramos os acessos a um arquivo e suas modificações, em relação aos seus horários. De certe forma, se fizemos tudo o que foi proposto acima, a resposta é sim.
De toda sorte, existe um jeito mais fácil de ficar de olho nessas coisas todas as quais abordamos. Trata-se da chave:
vfs.dir.get[/etc/mysql]
Ao criar um item com essa chave, obteremos de forma recursiva todos os seus objetos, tais como subdiretórios e arquivos. O formato da saída será um JSON e isso nos possibilitará criar regras do tipo LLD (Low-level Discovery) para automatizar o FIM. Abaixo, veja um pequeno pedaço da saída do monitoramento:
{
“basename”: “mariadb.cnf”,
“pathname”: “/etc/mysql/mariadb.cnf”,
“dirname”: “/etc/mysql”,
“type”: “file”,
“user”: “root”,
“group”: “root”,
“permissions”: “0644”,
“uid”: 0,
“gid”: 0,
“size”: 1126,
“time”: {
“access”: “2024-11-30T23:01:01-0300”,
“modify”: “2023-11-30T01:42:37-0300”,
“change”: “2024-06-25T18:41:01-0300”
},
“timestamp”: {
“access”: 1733018461,
“modify”: 1701319357,
“change”: 1719351661
}
…
Considerando que a saída contempla todos os objetos do diretório principal, este seria o caminho mais sensato para configurar nosso FIM, porém, é preciso criar a LLD e os protótipos. Não abordaremos isso neste artigo, mas esse é o caminho que te oriento a seguir.
Abaixo, uma “blueprint” de uma LLD para a criação de monitoramentos FIM de forma automatizada.
O “Master item”:
A “Dependent rule”:
As “LLD Macros”:
Os “Item prototypes”:
Abaixo, os componentes de uma trigger prototype (fiz apenas uma, para simbolizar um tipo de alerta por alteração de arquivo):
Name: Object: {#BASENAME} just changed
Event name: Object: {#BASENAME} just changed. Last hash: {ITEM.VALUE} The previous one: {?last(/MySQLDB/vfs.file.cksum[“{#PATHNAME}”,sha256],#2)} Object: {#BASENAME} just changed. Last hash: {ITEM.VALUE} The previous one: {?last(/MySQLDB/vfs.file.cksum[“{#PATHNAME}”,sha256],#2)}
Severity: Warning
Expression: last(/MySQLDB/vfs.file.cksum[“{#PATHNAME}”,sha256],#1)<>last(/MySQLDB/vfs.file.cksum[“{#PATHNAME}”,sha256],#2)
E então, alguns resultados:
Conclusão sobre o FIM
A implementação de um sistema robusto de File Integrity Monitoring (FIM) é uma das melhores práticas para ajudar a garantir a segurança da infraestrutura de TI. Detectar mudanças não autorizadas em arquivos críticos ajuda a prevenir ataques, identificar falhas de segurança e garantir a integridade e disponibilidade dos sistemas. Com o Zabbix, temos uma solução eficaz para aplicar o FIM, permitindo a automação do processo e a visualização em tempo real das alterações. Esse monitoramento não só reforça a proteção contra intrusões, como também facilita a auditoria e a conformidade com normas regulatórias.
Os principais benefícios de integrar o FIM com Zabbix incluem:
- Detecção precoce de alterações em arquivos críticos, permitindo respostas rápidas.
- Aumento da conformidade com regulamentações de segurança e políticas internas.
- Proteção contra malware e ransomware, identificando alterações em arquivos essenciais.
- Facilidade de auditoria com relatórios automatizados e históricos de modificações.
- Maior visibilidade e controle sobre a integridade dos dados e sistemas em tempo real.
- Eficiência operacional por meio da automação de alertas e relatórios.
- Melhoria da segurança proativa, ajudando na prevenção de ataques antes que se tornem críticos.
Com o uso do Zabbix, as organizações podem fortalecer sua postura de segurança e otimizar a gestão de riscos, garantindo que qualquer alteração não autorizada seja detectada e corrigida rapidamente.