Por Paulo Deolindo Jr.
Introdução
O Zabbix é amplamente conhecido como uma solução robusta de monitoramento de ativos de rede e infraestrutura de TIC (Tecnologia da Informação e Comunicação). No entanto, com suas versões mais recentes, a ferramenta evoluiu para oferecer funcionalidades sofisticadas voltadas à segurança cibernética, como o File Integrity Monitoring (FIM).
Muitas vezes, temos visto o uso do Zabbix como uma simples ferramenta de monitoramento de infraestrutura. 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. Essa evolução coloca o Zabbix como uma solução completa, indo além do monitoramento e entrando no campo da proteção contra ameaças cibernéticas.
O File Integrity Monitoring (FIM), conceito popular em soluções SIEM/XDR (Security Information Event Management/Extended Detection and Response), desempenha um papel fundamental na detecção de alterações não autorizadas em arquivos críticos, proporcionando maior controle e visibilidade sobre os sistemas, garantindo a integridade e atendendo às exigências de conformidade e segurança corporativa.
Neste blogpost, exploraremos como o Zabbix pode ser uma poderosa ferramenta para aprimorar a segurança cibernética nas organizações. Mostraremos como as funcionalidades nativas do Zabbix podem ser aplicadas para implementar práticas de File Integrity Monitoring, contribuindo para o amadurecimento das políticas de segurança e mitigação de riscos em ambientes corporativos cada vez mais desafiadores.
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 File Integrity Monitoring (FIM). O conceito de FIM é simples, mas poderoso: ele detecta alterações não autorizadas em arquivos críticos, garantindo maior controle e visibilidade sobre a integridade do sistema.
Embora muitas ferramentas de segurança apresentem o FIM como um recurso destacado em suas funcionalidades, o Zabbix também oferece essa capacidade, mesmo sem rotular explicitamente com este nome. O Zabbix permite monitorar a integridade de arquivos como parte de suas funcionalidades avançadas de monitoramento, entregando resultados práticos para quem busca segurança cibernética proativa além de conformidade.
Aqui, tratamos o FIM como um conceito estratégico e não apenas uma funcionalidade. Isso porque queremos alcançar resultados tangíveis para o negócio, e não um recurso de vitrine com um nome para dizer que estamos em conformidade quanto à nossa ferramenta. De fato, o resultado precisa ser mais importante que uma simples “propaganda” e são estes resultados que exploramos em diante. O foco é alcançar impactos concretos, como aumento na segurança, conformidade com regulamentações e redução de riscos operacionais.
Por Que Monitorar Arquivos Críticos é Crucial para a Segurança da Informação?
Alterações inesperadas em arquivos sensíveis — como configurações de sistemas ou registros importantes — podem comprometer a estabilidade de serviços essenciais. Através do Zabbix, é possível implementar o monitoramento de integridade de arquivos com eficácia, identificando rapidamente alterações, exclusões ou adições indesejadas.
Como o Zabbix Transforma o File Integrity Monitoring (FIM) em Segurança Proativa
- Prevenção de ataques cibernéticos: Proteja seus sistemas contra ameaças como ransomware e malware.
- Conformidade com regulamentações: Atenda a padrões como ISO e LGPD com monitoramento estruturado.
- Gestão proativa de incidentes: Reduza riscos operacionais com alertas em tempo real e relatórios detalhados.
O Zabbix, quando configurado para monitorar a integridade de arquivos, se torna uma poderosa ferramenta para fortalecer a segurança cibernética e promover a estabilidade operacional.
Como o File Integrity Monitoring (FIM) Garante a Segurança dos Seus Arquivos
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. É exatamente aqui que o File Integrity Monitoring entra em ação. Com o FIM, você pode monitorar continuamente esses arquivos e diretórios.
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:
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
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 cibernéticos, identificar falhas de segurança e garantir a integridade e disponibilidade dos sistemas. Com 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, como ISO 27001, ISO 27002, PIC-DSS, NIST800-53, HIPAA, dentre outras.
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.
O uso do Zabbix para FIM oferece um monitoramento avançado e centralizado, permitindo que as organizações fortaleçam sua postura de segurança, otimizem a gestão de riscos e garantam que qualquer alteração não autorizada seja detectada e corrigida rapidamente. Com isso, o Zabbix se consolida como uma solução completa para a segurança cibernética e gestão de infraestrutura de TI.