maltrail
0.76
Maltrail é um sistema de detecção de tráfego malicioso, que utiliza listas (negras) publicamente disponíveis contendo trilhas maliciosas e/ou geralmente suspeitas, juntamente com trilhas estáticas compiladas de vários relatórios AV e listas personalizadas definidas pelo usuário, onde a trilha pode ser qualquer coisa, desde nome de domínio (por exemplo, zvpprsensinaix.com para malware Banjori), URL (por exemplo, hXXp://109.162.38.120/harsh02.exe para executável malicioso conhecido), endereço IP (por exemplo, 185.130.5.231 para invasor conhecido) ou valor do cabeçalho HTTP User-Agent (por exemplo, sqlmap para injeção automática de SQL e ferramenta de controle de banco de dados). Além disso, utiliza mecanismos heurísticos avançados (opcionais) que podem ajudar na descoberta de ameaças desconhecidas (por exemplo, novo malware).
As seguintes listas negras (ou seja, feeds) estão sendo utilizadas:
360bigviktor, 360chinad, 360conficker, 360cryptolocker, 360gameover,
360locky, 360necurs, 360suppobox, 360tofsee, 360virut, abuseipdb, alienvault,
atmos, badips, bitcoinnodes, blackbook, blocklist, botscout,
bruteforceblocker, ciarmy, cobaltstrike, cruzit, cybercrimetracker,
dataplane, dshieldip, emergingthreatsbot, emergingthreatscip,
emergingthreatsdns, feodotrackerip, gpfcomics, greensnow, ipnoise,
kriskinteldns, kriskintelip, malc0de, malwaredomainlistdns, malwaredomains,
maxmind, minerchk, myip, openphish, palevotracker, policeman, pony,
proxylists, proxyrss, proxyspy, ransomwaretrackerdns, ransomwaretrackerip,
ransomwaretrackerurl, riproxies, rutgers, sblam, socksproxy, sslbl,
sslproxies, talosintelligence, torproject, trickbot, turris, urlhaus,
viriback, vxvault, zeustrackermonitor, zeustrackerurl, etc.
A partir das entradas estáticas, as trilhas para as seguintes entidades maliciosas (por exemplo, C&Cs de malware ou sumidouros) foram incluídas manualmente (a partir de vários relatórios AV e pesquisas pessoais):
1ms0rry, 404, 9002, aboc, absent, ab, acbackdoor, acridrain, activeagent,
adrozek, advisorbot, adwind, adylkuzz, adzok, afrodita, agaadex, agenttesla,
aldibot, alina, allakore, almalocker, almashreq, alpha, alureon, amadey,
amavaldo, amend_miner, ammyyrat, android_acecard, android_actionspy,
android_adrd, android_ahmythrat, android_alienspy, android_andichap,
android_androrat, android_anubis, android_arspam, android_asacub,
android_backflash, android_bankbot, android_bankun, android_basbanke,
android_basebridge, android_besyria, android_blackrock, android_boxer,
android_buhsam, android_busygasper, android_calibar, android_callerspy,
android_camscanner, android_cerberus, android_chuli, android_circle,
android_claco, android_clickfraud, android_cometbot, android_cookiethief,
android_coolreaper, android_copycat, android_counterclank, android_cyberwurx,
android_darkshades, android_dendoroid, android_dougalek, android_droidjack,
android_droidkungfu, android_enesoluty, android_eventbot, android_ewalls,
android_ewind, android_exodus, android_exprespam, android_fakeapp,
android_fakebanco, android_fakedown, android_fakeinst, android_fakelog,
android_fakemart, android_fakemrat, android_fakeneflic, android_fakesecsuit,
android_fanta, android_feabme, android_flexispy, android_fobus,
android_fraudbot, android_friend, android_frogonal, android_funkybot,
android_gabas, android_geinimi, android_generic, android_geost,
android_ghostpush, android_ginmaster, android_ginp, android_gmaster,
android_gnews, android_godwon, android_golddream, android_goldencup,
android_golfspy, android_gonesixty, android_goontact, android_gplayed,
android_gustuff, android_gypte, android_henbox, android_hiddad,
android_hydra, android_ibanking, android_joker, android_jsmshider,
android_kbuster, android_kemoge, android_ligarat, android_lockdroid,
android_lotoor, android_lovetrap, android_malbus, android_mandrake,
android_maxit, android_mobok, android_mobstspy, android_monokle,
android_notcompatible, android_oneclickfraud, android_opfake,
android_ozotshielder, android_parcel, android_phonespy, android_pikspam,
android_pjapps, android_qdplugin, android_raddex, android_ransomware,
android_redalert, android_regon, android_remotecode, android_repane,
android_riltok, android_roamingmantis, android_roidsec, android_rotexy,
android_samsapo, android_sandrorat, android_selfmite, android_shadowvoice,
android_shopper, android_simbad, android_simplocker, android_skullkey,
android_sndapps, android_spynote, android_spytekcell, android_stels,
android_svpeng, android_swanalitics, android_teelog, android_telerat,
android_tetus, android_thiefbot, android_tonclank, android_torec,
android_triada, android_uracto, android_usbcleaver, android_viceleaker,
android_vmvol, android_walkinwat, android_windseeker, android_wirex,
android_wolfrat, android_xavirad, android_xbot007, android_xerxes,
android_xhelper, android_xploitspy, android_z3core, android_zertsecurity,
android_ztorg, andromeda, antefrigus, antibot, anubis, anuna, apocalypse,
apt_12, apt_17, apt_18, apt_23, apt_27, apt_30, apt_33, apt_37, apt_38,
apt_aridviper, apt_babar, apt_bahamut, etc.
Maltrail é baseado na arquitetura Tráfego -> Sensor <-> Servidor <-> Cliente . Sensor (es) é um componente autônomo executado no nó de monitoramento (por exemplo, plataforma Linux conectada passivamente à porta SPAN/espelhamento ou transparentemente embutido em uma ponte Linux) ou na máquina autônoma (por exemplo, Honeypot) onde ele "monitora" o tráfego que passa. para itens/trilhas na lista negra (ou seja, nomes de domínio, URLs e/ou IPs). No caso de uma correspondência positiva, ele envia os detalhes do evento para o servidor (central) onde estão sendo armazenados dentro do diretório de registro apropriado (ou seja, LOG_DIR descrito na seção Configuração ). Se o Sensor estiver sendo executado na mesma máquina que o Servidor (configuração padrão), os logs serão armazenados diretamente no diretório de log local. Caso contrário, eles serão enviados via mensagens UDP para o servidor remoto (ou seja, LOG_SERVER descrito na seção Configuração ).
A função principal do servidor é armazenar os detalhes do evento e fornecer suporte de back-end para o aplicativo da web de relatórios. Na configuração padrão, o servidor e o sensor serão executados na mesma máquina. Portanto, para evitar possíveis interrupções nas atividades dos sensores, a parte de relatórios front-end é baseada na arquitetura "Fat client" (ou seja, todo o pós-processamento de dados é feito dentro da instância do navegador web do cliente). Os eventos (ou seja, entradas de log) do período escolhido (24h) são transferidos para o Cliente , onde a aplicação web de relatórios é a única responsável pela parte de apresentação. Os dados são enviados ao cliente em blocos compactados, onde são processados sequencialmente. O relatório final é elaborado de forma altamente condensada, permitindo praticamente a apresentação de um número virtualmente ilimitado de eventos.
Nota: O componente Server pode ser totalmente ignorado e apenas usar o Sensor autônomo. Nesse caso, todos os eventos seriam armazenados no diretório de log local, enquanto as entradas de log poderiam ser examinadas manualmente ou por algum aplicativo de leitura de CSV.
Páginas de demonstração totalmente funcionais com ameaças reais coletadas podem ser encontradas aqui.
Para executar o Maltrail corretamente, o Python 2.6 , 2.7 ou 3.x é necessário no sistema *nix/BSD, junto com o pacote pcapy-ng instalado.
NOTA: O uso de pcapy lib em vez de pcapy-ng pode levar ao funcionamento incorreto do Maltrail, especialmente em ambientes Python 3.x. Exemplos.
O componente Sensor requer pelo menos 1 GB de RAM para ser executado no modo de processo único ou mais se for executado no modo de multiprocessamento, dependendo do valor usado para a opção CAPTURE_BUFFER . Além disso, o componente Sensor (em geral) requer privilégios administrativos/root.
O componente servidor não possui nenhum requisito especial.
O seguinte conjunto de comandos deve colocar seu Sensor Maltrail em funcionamento (pronto para uso com configurações padrão e interface de monitoramento "qualquer"):
sudo apt-get install git python3 python3-dev python3-pip python-is-python3 libpcap-dev build-essential procps schedtool
sudo pip3 install pcapy-ng
git clone --depth 1 https://github.com/stamparm/maltrail.git
cd maltrail
sudo python3 sensor.pysudo zypper install gcc gcc-c++ git libpcap-devel python3-devel python3-pip procps schedtool
sudo pip3 install pcapy-ng
git clone --depth 1 https://github.com/stamparm/maltrail.git
cd maltrail
sudo python3 sensor.pyPara iniciar o servidor (opcional) na mesma máquina, abra um novo terminal e execute o seguinte:
[[ -d maltrail ]] || git clone --depth 1 https://github.com/stamparm/maltrail.git
cd maltrail
python server.pyPara testar se tudo está funcionando, execute o seguinte:
ping -c 1 136.161.101.53
cat /var/log/maltrail/ $( date + " %Y-%m-%d " ) .logAlém disso, para testar a captura do tráfego DNS, você pode tentar o seguinte:
nslookup morphed.ru
cat /var/log/maltrail/ $( date + " %Y-%m-%d " ) .logPara interromper as instâncias do Sensor e do Servidor (se estiverem em execução em segundo plano), execute o seguinte:
sudo pkill -f sensor.py
pkill -f server.py Acesse a interface de relatórios (ou seja, Cliente ) visitando http://127.0.0.1:8338 (credenciais padrão: admin:changeme! ) no seu navegador:
A configuração do sensor pode ser encontrada na seção do arquivo maltrail.conf [Sensor] :
Se a opção USE_MULTIPROCESSING estiver definida como true , todos os núcleos da CPU serão usados. Um núcleo será usado apenas para captura de pacotes (com afinidade apropriada, prioridade de E/S e configurações de nível agradável), enquanto outros núcleos serão usados para processamento de pacotes. Caso contrário, tudo será executado em um único núcleo. A opção USE_FEED_UPDATES pode ser usada para desativar completamente as atualizações de trilha dos feeds (e apenas usar as estáticas fornecidas). A opção UPDATE_PERIOD contém o número de segundos entre cada atualização automática de trilhas (Nota: o valor padrão é definido como 86400 (ou seja, um dia)) usando definições dentro do diretório trails (Nota: tanto o Sensor quanto o Servidor cuidam da atualização das trilhas). A opção CUSTOM_TRAILS_DIR pode ser usada pelo usuário para fornecer a localização do diretório que contém os arquivos de trilhas personalizadas ( *.txt ).
A opção USE_HEURISTICS ativa mecanismos heurísticos (por exemplo, long domain name (suspicious) , excessive no such domain name (suspicious) , direct .exe download (suspicious) , etc.), potencialmente introduzindo falsos positivos. A opção CAPTURE_BUFFER apresenta uma memória total (em bytes de porcentagem da memória física total) a ser utilizada no caso de modo multiprocessamento para armazenar a captura de pacotes em um ring buffer para posterior processamento por processos não-capturadores. A opção MONITOR_INTERFACE deve conter o nome da interface de captura. Use o valor any para capturar de todas as interfaces (se o sistema operacional suportar isso). A opção CAPTURE_FILTER deve conter o filtro de captura de rede ( tcpdump ) para pular os pacotes desinteressantes e facilitar o processo de captura. A opção SENSOR_NAME contém o nome que deve aparecer dentro do valor sensor_name dos eventos, para que o evento de um sensor possa ser diferenciado do outro. Se a opção LOG_SERVER estiver definida, todos os eventos serão enviados remotamente para o Server , caso contrário, eles serão armazenados diretamente no diretório de log definido com a opção LOG_DIR , que pode ser encontrado na seção do arquivo maltrail.conf [All] . Caso a opção UPDATE_SERVER esteja configurada, então todos os trilhas estão sendo puxados do local determinado, caso contrário estão sendo atualizados a partir de definições de trilhas localizadas dentro da própria instalação.
As opções SYSLOG_SERVER e/ou LOGSTASH_SERVER podem ser usadas para enviar eventos de sensor (ou seja, dados de log) para servidores não-Maltrail. No caso de SYSLOG_SERVER , os dados do evento serão enviados no formato CEF ( Common Event Format ) para o serviço UDP (por exemplo, Syslog) que escuta no endereço fornecido (por exemplo, 192.168.2.107:514 ), enquanto no caso de LOGSTASH_SERVER os dados do evento serão enviados em Formato JSON para serviço UDP (por exemplo, Logstash) escutando no endereço fornecido (por exemplo, 192.168.2.107:5000 ).
Um exemplo de dados de eventos enviados por UDP é o seguinte:
SYSLOG_SERVER (Nota: os valores LogSeverity são 0 (para baixo), 1 (para médio) e 2 (para alto)): Dec 24 15:05:55 beast CEF:0|Maltrail|sensor|0.27.68|2020-12-24|andromeda (malware)|2|src=192.168.5.137 spt=60453 dst=8.8.8.8 dpt=53 trail=morphed.ru ref=(static)
LOGSTASH_SERVER : {"timestamp": 1608818692, "sensor": "beast", "severity": "high", "src_ip": "192.168.5.137", "src_port": 48949, "dst_ip": "8.8.8.8", "dst_port": 53, "proto": "UDP", "type": "DNS", "trail": "morphed.ru", "info": "andromeda (malware)", "reference": "(static)"}
Ao executar o sensor (por exemplo, sudo python sensor.py ) pela primeira vez e/ou após um longo período sem execução, ele atualizará automaticamente as trilhas a partir das definições de trilhas (Nota: armazenadas dentro do diretório trails ). Após a inicialização, ele começará a monitorar a interface configurada (opção MONITOR_INTERFACE dentro do maltrail.conf ) e gravará os eventos no diretório de log configurado (opção LOG_DIR dentro da seção do arquivo maltrail.conf [All] ) ou os enviará remotamente para o Servidor de registro/relatório (opção LOG_SERVER ).
Os eventos detectados são armazenados dentro do diretório de registro do servidor (ou seja, opção LOG_DIR dentro da seção do arquivo maltrail.conf [All] ) em formato CSV de fácil leitura (Nota: espaço em branco ' ' é usado como delimitador) como entradas de linha única consistindo em: sensor time src_ip src_port dst_ip dst_port proto trail_type trail trail_info reference (por exemplo, "2015-10-19 15:48:41.152513" beast 192.168.5.33 32985 8.8.8.8 53 UDP DNS 0000mps.webpreview.dsl.net malicious siteinspector.comodo.com ):
A configuração do servidor pode ser encontrada na seção maltrail.conf [Server] :
A opção HTTP_ADDRESS contém o endereço de escuta do servidor web (Nota: use 0.0.0.0 para escutar em todas as interfaces). A opção HTTP_PORT contém a porta de escuta do servidor web. A porta de escuta padrão está definida como 8338 . Se a opção USE_SSL estiver definida como true então SSL/TLS será usado para acessar o servidor web (por exemplo, https://192.168.6.10:8338/ ). Nesse caso, a opção SSL_PEM deve apontar para o arquivo PEM privado/certificado do servidor.
A subseção USERS contém as configurações do usuário. Cada entrada de usuário consiste em username:sha256(password):UID:filter_netmask(s) . O valor UID representa o identificador único do usuário, onde é recomendado utilizar valores inferiores a 1000 para contas administrativas, enquanto valor superior para contas não administrativas. A parte filter_netmask(s) representa os filtros rígidos delimitados por vírgulas que podem ser usados para filtrar os eventos mostrados dependendo da(s) conta(s) do usuário. A entrada padrão é a seguinte:
A opção UDP_ADDRESS contém o endereço de escuta de coleta de log do servidor (Nota: use 0.0.0.0 para escutar em todas as interfaces), enquanto a opção UDP_PORT contém o valor da porta de escuta. Se ativado, quando usado em combinação com a opção LOG_SERVER , pode ser usado para arquiteturas distintas (múltiplas) de Sensor <-> Servidor .
A opção FAIL2BAN_REGEX contém a expressão regular (por exemplo attacker|reputation|potential[^"]*(web scan|directory traversal|injection|remote code|iot-malware download|spammer|mass scanner ) a ser usada em chamadas da web /fail2ban para extração dos IPs de origem dos invasores atuais. Isso permite o uso de mecanismos de bloqueio de IP (por exemplo, fail2ban , iptables ou ipset ) por meio da extração periódica de IP na lista negra. endereços de local remoto. Um exemplo de uso seria o seguinte script (por exemplo, executado como um cronjob root a cada minuto):
#! /bin/bash
ipset -q flush maltrail
ipset -q create maltrail hash:net
for ip in $( curl http://127.0.0.1:8338/fail2ban 2> /dev/null | grep -P ' ^[0-9.]+$ ' ) ; do ipset add maltrail $ip ; done
iptables -I INPUT -m set --match-set maltrail src -j DROP A opção BLACKLIST permite construir expressões regulares para aplicar em um campo. Para cada regra, a sintaxe é: <field> <control> <regexp> onde:
field indica o campo a ser paginado, pode ser: src_ip , src_port , dst_ip , dst_port , protocol , type , trail ou filter .control pode ser ~ para correspondências ou !~ para não correspondênciaregexp é a expressão regular a ser aplicada ao campo. Encadeie outra regra com a palavra-chave and (a palavra-chave or não é suportada, basta adicionar uma linha para isso). Você pode usar a palavra-chave BLACKLIST sozinha ou adicionar um nome: BLACKLIST_NAME . Neste último caso, a URL será: /blacklist/name
Por exemplo, o seguinte criará uma lista negra para todo o tráfego de outra origem que não seja 192.168.0.0/16 para a porta de destino SSH ou correspondente à scan de filtros ou known attacker
BLACKLIST_OUT
src_ip !~ ^192.168. and dst_port ~ ^22$
src_ip !~ ^192.168. and filter ~ scan
src_ip !~ ^192.168. and filter ~ known attacker
BLACKLIST_IN
src_ip ~ ^192.168. and filter ~ malware
A maneira de construir a lista negra de ipset é a mesma (veja acima), exceto que os URLs serão /blacklist/in e /blacklist/out em nosso exemplo.
O mesmo que para Sensor , ao executar o servidor (por exemplo, python server.py ) pela primeira vez e/ou após um longo período de inatividade, se a opção USE_SERVER_UPDATE_TRAILS estiver definida como true , ele atualizará automaticamente as trilhas a partir das definições de trilha ( Nota: armazenado dentro do diretório trails ). Sua função básica é armazenar as entradas de log dentro do diretório de log (ou seja, opção LOG_DIR dentro da seção do arquivo maltrail.conf [All] ) e fornecer a interface de relatórios da web para apresentar essas mesmas entradas ao usuário final (Nota: não há precisa instalar pacotes de servidores web de terceiros, como Apache):
Ao entrar na interface de relatórios do servidor (ou seja, através do endereço definido pelas opções HTTP_ADDRESS e HTTP_PORT ), o usuário verá a seguinte caixa de diálogo de autenticação. O usuário deve inserir as credenciais adequadas que foram definidas pelo administrador do servidor dentro do arquivo de configuração maltrail.conf (Nota: as credenciais padrão são admin:changeme! ):
Uma vez dentro, o usuário verá a seguinte interface de relatórios:
A parte superior contém uma linha do tempo deslizante (Nota: ativada após clicar no rótulo da data atual e/ou no ícone do calendário) onde o usuário pode selecionar registros de eventos passados (Nota: passar o mouse sobre o evento acionará a exibição de uma dica de ferramenta com o número aproximado de eventos para o atual data). As datas são agrupadas por meses, onde o período de dados de 4 meses é exibido dentro do próprio widget. No entanto, usando o controle deslizante fornecido (ou seja), o usuário pode acessar facilmente os eventos dos meses anteriores.
Ao clicar na data, todos os eventos dessa data específica deverão ser carregados e representados pelo navegador do cliente. Dependendo do número de eventos e da velocidade da conexão de rede, o carregamento e a exibição dos eventos registrados podem levar de alguns segundos a vários minutos (por exemplo, 100.000 eventos levam cerca de 5 segundos no total). Durante todo o tempo de processamento, o carregador animado será exibido na interface do usuário desativada:
A parte intermediária contém um resumo dos eventos exibidos. A caixa Events representa o número total de eventos em um período selecionado de 24 horas, onde a linha vermelha representa eventos baseados em IP, a linha azul representa eventos baseados em DNS e a linha amarela representa eventos baseados em URL. A caixa Sources representa o número de eventos por fontes principais na forma de um gráfico de colunas empilhadas, com o número total de fontes no topo. A caixa Threats representa a porcentagem das principais ameaças na forma de um gráfico de pizza (Observação: a área cinza contém todas as ameaças, cada uma com <1% no total de eventos), com o número total de ameaças no topo. A caixa Trails representa a porcentagem das trilhas principais em forma de gráfico de pizza (Observação: a área cinza contém todas as trilhas com <1% no total de eventos), com o número total de trilhas no topo. Cada uma dessas caixas está ativa, portanto, clicar em uma delas resultará em um gráfico mais detalhado.
A parte inferior contém uma representação condensada dos eventos registrados na forma de uma tabela paginada. Cada entrada contém detalhes de uma única ameaça (Nota: identificado exclusivamente por um par (src_ip, trail) ou (dst_ip, trail) se o src_ip for o mesmo que o trail como no caso de ataques vindos de fora):
A coluna threat contém o ID exclusivo da ameaça (por exemplo, 85fdb08d ) e a cor (Nota: extrudado do ID da ameaça), sensor contém o(s) nome(s) do sensor onde o evento foi acionado (por exemplo, blitvenica ), events contém o número total de eventos para uma ameaça atual , severity contém a gravidade avaliada da ameaça (Observação: calculada com base nos valores nas colunas info e reference , priorizando o tráfego gerado por malware), first_seen contém a hora do primeiro evento em um período selecionado (24h) (por exemplo, 06th 08:21:54 ), last_seen contém a hora do último evento em um período selecionado (24h) (por exemplo, 06th 15:21:23 ), sparkline contém um pequeno gráfico minigráfico que representa a atividade da ameaça no período selecionado, src_ip contém IP(s) de origem de uma ameaça (por exemplo, 99.102.41.102 ), src_port contém porta(s) de origem (por exemplo, 44556, 44589, 44601 ), dst_ip contém IP(s) de destino (por exemplo, 213.202.100.28 ), dst_port contém porta(s) de destino (por exemplo, 80 (HTTP) ), proto contém protocolo(s), (por exemplo, TCP ), trail contém uma lista negra entrada (ou heurística) que acionou o(s) evento(s), info contêm mais informações sobre a ameaça/trilha (por exemplo, known attacker para o IP do invasor conhecido endereços ou ipinfo para serviços de informações de IP conhecidos comumente usados por malware durante uma inicialização), reference contém uma fonte da entrada na lista negra (por exemplo, (static) para trilhas estáticas ou myip.ms para um feed dinâmico recuperado dessa mesma fonte) e tags contém tags definidas pelo usuário para uma determinada trilha (por exemplo, APT28 ).
Ao passar o mouse sobre as entradas da tabela src_ip e dst_ip , uma dica de ferramenta de informações é exibida com informações detalhadas de DNS reverso e WHOIS (Nota: RIPE é o provedor de informações):
Os detalhes do evento (por exemplo, src_port , dst_port , proto , etc.) que diferem dentro da mesma entrada de ameaça são condensados na forma de um ícone de bolha (ou seja, ). Isso é executado para obter uma interface de relatório utilizável com o mínimo de linhas possível. Mover o mouse sobre esse ícone resultará na exibição de uma dica de ferramenta com todos os itens mantidos (por exemplo, todos os números de porta sendo verificados pelo attacker ):
Clicar em um desses ícones abrirá uma nova caixa de diálogo contendo todos os itens armazenados (Nota: em sua forma não condensada) prontos para serem copiados e colados (d) para análise posterior:
Ao passar o ponteiro do mouse sobre a trilha da ameaça por alguns segundos, isso resultará em um quadro composto por resultados usando a trilha como um termo de pesquisa realizado contra Criptografar pesquisa mecanismo de pesquisa searchX. Em muitos casos, isso fornece informações básicas sobre a ameaça em si, eliminando a necessidade de o usuário fazer a busca manual por ela. No canto superior direito da janela do quadro aberto existem dois botões extras. Ao clicar no primeiro (ou seja ), o quadro resultante será aberto dentro da nova aba (ou janela) do navegador, enquanto ao clicar no segundo (ou seja ) fechará imediatamente o quadro (Nota: a mesma ação é obtida movendo o ponteiro do mouse fora das bordas do quadro):
Para cada ameaça existe uma tag de coluna que pode ser preenchida com "tags" arbitrárias para descrever detalhadamente todas as ameaças que compartilham o mesmo rastro. Além disso, é uma ótima maneira de descrever ameaças individualmente, para que todas as ameaças que compartilham a mesma tag (por exemplo, yahoo ) possam ser agrupadas posteriormente:
Na seção seguinte, alguns dos cenários dos “suspeitos do costume” serão descritos através de casos da vida real.
Varreduras em massa são um fenômeno bastante comum onde indivíduos e/ou organizações se dão o direito de varrer todo o intervalo de IP 0.0.0.0/0 (ou seja, toda a Internet) diariamente, com isenção de responsabilidade onde eles dizem que se você não gostar então você deve contatá-los em particular para serem ignorados em verificações futuras.
Para piorar as coisas, organizações como Shodan e ZoomEye disponibilizam todos os resultados gratuitamente (para outros possíveis invasores) por meio de seu mecanismo de busca. Nas capturas de tela a seguir você verá detalhes das varreduras do Shodan em um único dia.
Aqui está uma pesquisa reversa de DNS e WHOIS do endereço do "invasor":
Ao passar o ponteiro do mouse sobre o conteúdo da coluna trail (endereço IP), você verá os resultados da pesquisa do searX, onde poderá encontrar mais informações sobre o "atacante":
Na coluna dst_ip , se você tiver uma organização grande, será apresentada uma grande lista de endereços IP verificados:
Na coluna dst_port você poderá ver todas as portas que foram verificadas por essas verificações em massa:
Em outras situações semelhantes, você verá o mesmo comportamento, vindo de invasores individuais na lista negra (neste caso, cinsscore.com):
Um comportamento mais comum é a varredura de toda a faixa de IP 0.0.0.0/0 (ou seja, Internet) em busca de uma porta específica (por exemplo, porta TCP 443 quando o Heartbleed for encontrado). Na captura de tela a seguir, você encontrará um caso de invasor(es) anteriormente colocado(s) na lista negra (neste caso, alienvault.com e duas outras listas negras) visando a porta UDP 5060 (ou seja, SIP) em busca de dispositivos VoIP configurados incorretamente:
Para detectar os possíveis invasores escondidos atrás da rede de anonimato Tor, Maltrail utiliza listas publicamente disponíveis de nós de saída Tor. Na captura de tela a seguir, você verá um caso em que um invasor em potencial utilizou a rede Tor para acessar o alvo da web (por HTTP) no alcance de nossa organização de forma suspeita (total de 171 solicitações de conexão em 10 minutos):
Um caso bastante semelhante ao anterior é quando um invasor anteriormente colocado na lista negra tenta acessar serviços específicos (por exemplo, não-HTTP(s)) no alcance da nossa organização de maneira bastante suspeita (ou seja, um total de 1.513 tentativas de conexão em menos de 15 minutos):
Se inserirmos o ssh attacker no campo Filter , poderemos ver todas as ocorrências semelhantes naquele dia, mas neste caso para a porta 22 (ou seja, SSH):
No caso de tentativas de conexão provenientes de computadores infectados dentro de nossa organização para servidores C&C já conhecidos, você poderá encontrar ameaças semelhantes às seguintes (neste caso Beebone):
No caso de solicitações DNS contendo nomes de domínio DGA conhecidos, a ameaça será mostrada como (neste caso Necurs):
No seguinte caso, ocorreram downloads de arquivos de URL(s) da lista negra (neste caso, por malwarepatrol.net):
Se inserirmos o nome do malware específico (neste caso Ramnit) no campo Filter , apenas as ameaças que estiverem vinculadas a esse malware serão filtradas (mostrando todos os computadores internos afetados):
De forma mais geral, se inserirmos o malware no campo Filter , todas as ameaças que foram encontradas por trilhas de malware (relacionadas) (por exemplo, endereços IP ) serão filtradas em:
Maltrail usa a lista estática de domínios TLD que são comumente envolvidos em atividades suspeitas. A maioria desses domínios TLD vem de registradores de domínios gratuitos (por exemplo, Freenom), portanto, deveriam estar sob maior escrutínio. Na captura de tela a seguir, podemos encontrar um caso em que um domínio TLD .cm foi usado por malware desconhecido usando o algoritmo DGA para entrar em contato com seu(s) servidor(es) C&C:
Há também casos em que domínios TLD perfeitamente válidos (por exemplo, .ru ) são usados para atividades suspeitas, como neste caso (por exemplo, long domain name (suspicious) ) onde os domínios são obviamente DGA gerados por malware desconhecido:
Maltrail usa uma lista estática dos chamados "domínios dinâmicos" que são frequentemente usados em atividades suspeitas (por exemplo, para servidores C&C de malware que frequentemente alteram os endereços IP do destino):
Além disso, Maltrail usa uma lista estática de domínios relacionados à "cebola" que também são frequentemente usados em atividades suspeitas (por exemplo, malware entrando em contato com servidores C&C usando serviço(s) Tor2Web):
No caso de malware antigo e/ou obsoleto que permanece sem ser detectado nos computadores internos infectados da organização, muitas vezes há um "fenômeno" em que o malware tenta continuamente entrar em contato com o domínio do servidor C&C há muito morto, sem qualquer resolução de DNS. Conseqüentemente, esse tipo de ameaça (potencial) será marcada como excessive no such domain (suspicious) :
Caso uma trilha seja responsável por muitas ameaças (por exemplo, no caso de IPs de origem falsos, como em ataques de amplificação de DNS), todas as ameaças semelhantes serão agrupadas sob uma única ameaça flood (Nota: o ID da ameaça será marcado com o sufixo F0 ), como no exemplo a seguir:
Muitos malwares usam algum tipo de serviço ipinfo (por exemplo, ipinfo.io) para descobrir o endereço IP da Internet da vítima. No caso de solicitações regulares e principalmente fora do horário de expediente, esse tipo de solicitação deve ser monitorado de perto, como no exemplo a seguir:
Ao usar o filtro ipinfo todos os computadores potencialmente infectados no alcance da nossa organização podem ser listados e que compartilham este tipo de comportamento suspeito:
Maltrail rastreia todas as tentativas suspeitas de download direto de arquivos (por exemplo, .apk , .bin , .class , .chm , .dll , .egg , .exe , .hta , .hwp , .lnk , .ps1 , .scr , .sct , .wbk extensões de arquivo .wbk e .xpi ). Isso pode desencadear muitos falsos positivos, mas eventualmente pode ajudar na reconstrução da cadeia de infecção (Observação: provedores de serviços legítimos, como o Google, geralmente usam HTTPS criptografado para realizar esse tipo de download):
No caso de solicitações suspeitas provenientes de verificadores de segurança de aplicativos da Web externos (por exemplo, pesquisa de vulnerabilidades SQLi, XSS, LFI, etc.) e/ou tentativas maliciosas do usuário interno em sites desconhecidos, ameaças como as seguintes podem ser encontradas (caso real de invasores que tentam explorar as vulnerabilidades CMS CVE-2015-7297, CVE-2015-7857 e CVE-2015-7858 do Joomla):
No exemplo a seguir, a verificação de vulnerabilidades de aplicativos da web foi marcada como "suspeita":
Se clicarmos no ícone de bolha (ou seja, ) para obter detalhes e copiar e colar todo o conteúdo em um arquivo de texto, poderemos ver todas as solicitações HTTP suspeitas:
Na captura de tela a seguir, uma execução da popular ferramenta de vulnerabilidade SQLi sqlmap pode ser encontrada em nossos logs:
No caso de muitas tentativas de conexão para uma quantidade considerável de portas TCP diferentes, o Maltrail avisará sobre a potencial varredura de portas, como resultado de seu mecanismo heurístico de detecção. Na captura de tela a seguir, esses avisos podem ser encontrados para uma execução da popular ferramenta de verificação de portas nmap:
Um ataque DDoS popular contra a infraestrutura de servidores web é o esgotamento dos recursos de seu servidor DNS (principal), fazendo consultas de recursão DNS válidas para nomes de subdomínios (pseudo)aleatórios (por exemplo, abpdrsguvjkyz.www.dedeni.com ):
Diversos programas (especialmente baseados em dispositivos móveis) apresentam comportamento semelhante ao de malware, onde enviam dados potencialmente confidenciais para postos de beacon remotos. Maltrail tentará capturar tal comportamento como no exemplo a seguir:
Como em todas as outras soluções de segurança, o Maltrail está sujeito a “falsos positivos”. Nesse tipo de casos, o Maltrail irá (especialmente no caso de ameaças suspicious ) registrar o comportamento de um usuário regular e marcá-lo como malicioso e/ou suspeito. No exemplo a seguir, pode-se ver que um provedor de feed de lista negra blocklist.de marcou servidores regulares do Google como attacker , resultando na seguinte ameaça:
Ao passar o mouse sobre a trilha, o quadro com os resultados da pesquisa searchX mostra que este é (provavelmente) um servidor normal do Google:
Como outro exemplo, o acesso a domínios .work regulares (TLD populares para fins maliciosos) resultou na seguinte ameaça:
No entanto, o(s) administrador(es) deve(m) investir algum tempo extra e verificar (com outros meios) se o “suspeito” significa malicioso ou não, como no exemplo a seguir:
No Ubuntu/Debian
sudo apt-get install git python3 python3-dev python3-pip python-is-python3 libpcap-dev build-essential procps schedtool
sudo pip3 install pcapy-ng
cd /tmp
git clone --depth 1 https://github.com/stamparm/maltrail.git
sudo mv /tmp/maltrail /opt
sudo chown -R $USER : $USER /opt/maltrailNo SUSE/openSUSE
sudo zypper install gcc gcc-c++ git libpcap-devel python3-devel python3-pip procps schedtool
sudo pip3 install pcapy-ng
cd /tmp
git clone --depth 1 https://github.com/stamparm/maltrail.git
sudo mv /tmp/maltrail /opt
sudo chown -R $USER : $USER /opt/maltrailDefinir ambiente de trabalho:
sudo mkdir -p /var/log/maltrail
sudo mkdir -p /etc/maltrail
sudo cp /opt/maltrail/maltrail.conf /etc/maltrail
sudo nano /etc/maltrail/maltrail.confDefina o ambiente de execução:
crontab -e # autostart server & periodic update */5 * * * * if [ -n "$(ps -ef | grep -v grep | grep 'server.py')" ]; then : ; else python3 /opt/maltrail/server.py -c /etc/maltrail/maltrail.conf; fi
0 1 * * * cd /opt/maltrail && git pull
sudo crontab -e # autostart sensor & periodic restart */1 * * * * if [ -n "$(ps -ef | grep -v grep | grep 'sensor.py')" ]; then : ; else python3 /opt/maltrail/sensor.py -c /etc/maltrail/maltrail.conf; fi
2 1 * * * /usr/bin/pkill -f maltrail
Habilite como serviços systemd (somente Linux):
sudo cp /opt/maltrail/maltrail-sensor.service /etc/systemd/system/maltrail-sensor.service
sudo cp /opt/maltrail/maltrail-server.service /etc/systemd/system/maltrail-server.service
sudo systemctl daemon-reload
sudo systemctl start maltrail-server.service
sudo systemctl start maltrail-sensor.service
sudo systemctl enable maltrail-server.service
sudo systemctl enable maltrail-sensor.service
systemctl status maltrail-server.service && systemctl status maltrail-sensor.service
Nota : /maltrail-sensor.service pode ser iniciado como serviço dedicado sem /maltrail-server.service pré-iniciado. Isso é útil no caso em que /maltrail-server.service está instalado e funciona em outra máquina em seu ambiente de rede.
Este software é fornecido sob uma licença do MIT. Consulte o arquivo LICENSE que acompanha para obter mais informações.
1 Usando (apenas) trilhas
2 Conector para trilhas (somente)
