Configurar e operar Sophos Firewall Threat Feeds com segurança

Os Sophos Firewall Threat Feeds importam automaticamente endereços IP, domínios e URLs maliciosos conhecidos como Indicators of Compromise (IoCs). Para uma implementação segura, deve observar-se primeiro o feed no modo Monitor, verificar os hits e os efeitos secundários e só depois mudar para Block.

Este artigo aborda sobretudo Third-Party Threat Feeds, como os feeds da Cybora. A funcionalidade foi introduzida com a Sophos Firewall v21.

Configurar um Threat Feed

Os Third-Party Threat Feeds requerem o Xstream Protection Bundle, mas não uma licença Sophos Fusion (anteriormente Sophos Central) adicional. A firewall tem de conseguir aceder ao URL do feed através de DNS e HTTPS.

1. Abrir System services > Log settings.
2. Em Active threat response, ativar pelo menos um destino de log suportado. Local reporting armazena logs de eventos localmente para o Log Viewer; estes logs não são relatórios gerados no próprio equipamento. Em alternativa, utilizar o Sophos Fusion (anteriormente Sophos Central) ou um servidor syslog como destino de log.
3. Para ver hits em tráfego DNAT e WAF de entrada, ativar também Remote source match (inbound traffic). Esta opção está desativada por predefinição.
4. Abrir Protect > Active threat response > Third-party threat feeds > Add.
5. Introduzir um nome e uma descrição inequívocos, por exemplo:
   • Projeto-piloto: Name cybora-premium-ipv4-monitor, Description Cybora Premium IPv4 - Pilot
   • Feed de produção já validado: Name cybora-premium-ipv4, Description Cybora Feed - Premium
6. Em Indicator type, selecionar IPv4 address, Domain ou URL. Se uma fonte fornecer vários tipos, cria-se um feed separado para cada tipo.
7. Definir Action como Monitor durante a introdução. Após um período de observação verificado, pode mudar-se para Block.
8. Em Position, selecionar Top para um feed piloto, para que a respetiva correspondência não fique oculta por outro feed de terceiros. Bottom é adequado para um feed de prioridade inferior cujas sobreposições já são conhecidas.
9. Em External URL, introduzir o endereço adequado da lista de feeds da Avanet ou do fornecedor. O URL tem de devolver diretamente o ficheiro de texto simples. Se o endpoint responder, por exemplo, com HTTP 302, o SFOS classifica-o como Connection error. O ficheiro contém um indicador por linha.
10. Em Authorization, selecionar No authentication, API key ou Basic authentication, conforme as indicações do fornecedor. Com API key, introduzir separadamente o nome do header ou parâmetro indicado pelo fornecedor e o valor secreto; em seguida, selecionar Header ou Query parameters como local de envio. Se um fornecedor exigir, por exemplo, o header X-API-Key, este é o nome e não a chave secreta. Com Basic authentication, introduzir o nome de utilizador e a palavra-passe. Tanto o valor da API key como a palavra-passe suportam no máximo 64 carateres cada. As credenciais não devem constar de tickets nem capturas de ecrã.
11. Ativar Validate server certificate. Para um certificado público, a CA emissora tem de estar disponível em Certificates > Certificate authorities; para uma CA privada, importa-se primeiro o respetivo certificado.
12. Selecionar um Polling interval adequado ao intervalo de atualização do fornecedor.
13. Executar Test connection e guardar com Save.

Em seguida, verificar Sync status, Last updated, o número de Threat indicators e a Storage quota disponível. Success confirma uma ligação ou um pedido HTTP GET bem-sucedido, mas não a análise completa da lista nem que o tráfego esperado seja efetivamente detetado ou bloqueado. O conteúdo e o efeito têm de ser validados separadamente.

Selecionar corretamente o feed e a ação

Indicadores suportados

Cada configuração de feed analisa exatamente um destes tipos de indicadores:

• IPv4 address: scanners, botnets, sistemas comprometidos ou servidores C2
• Domain: domínios de malware, phishing ou command-and-control
• URL: caminhos maliciosos específicos ou links de download

O feed tem de ser um ficheiro de texto simples com um indicador por linha. Se o ficheiro do fornecedor contiver vários tipos, o SFOS considera apenas o Indicator type selecionado. Por isso, é necessária uma configuração separada para cada tipo pretendido; um ficheiro misto não tem de ser dividido apenas por conter vários tipos. Intervalos IP, endereços IPv6, redes, domínios wildcard e expressões regulares não são utilizados em Third-Party Threat Feeds como substitutos de IoCs individuais suportados.

Um exemplo de formato exclusivamente IPv4 é o seguinte:

192.0.2.10
198.51.100.20

Estes endereços de documentação mostram apenas o formato, não ameaças reais nem destinos de teste acessíveis. Para o teste controlado descrito mais adiante, utiliza-se antes o endereço IPv4 individual do próprio destino de teste, e não a respetiva rede com sufixo CIDR. No caso da Cybora, utilizam-se diretamente os ficheiros de feed disponibilizados.

O SFOS não impõe um número fixo de IoCs por Third-Party Feed. O tamanho utilizável é limitado pela Storage quota dependente do modelo. Após a importação, verificar em conjunto a quota livre, o número de Threat indicators e a obtenção bem-sucedida do feed.

Uma lista grande não é automaticamente uma boa lista. A origem, atualidade, intervalo de atualização, risco de falsos positivos e os hits no próprio ambiente são mais importantes do que o número total de entradas. Um feed que não oferece utilidade duradoura apenas ocupa armazenamento. A integração não está limitada a uma lista fixa de fornecedores: qualquer Third-Party Feed pode ser integrado se cumprir os requisitos de ficheiro descritos. A Sophos menciona, por exemplo, GreyNoise Intelligence, CrowdSec e Q-Feeds como fornecedores; esta referência não substitui a verificação do endpoint concreto nem o próprio projeto-piloto em Monitor.

Monitor antes de Block

Monitor regista os hits, mas permite o tráfego. Desta forma, mostra que origens, destinos e serviços seriam afetados. Block regista e descarta o tráfego correspondente.

Para um feed novo, recomenda-se o seguinte procedimento:

1. Colocar o feed no topo da lista Third-Party.
2. Começar com Monitor.
3. Verificar os hits e possíveis falsos positivos durante um período representativo.
4. Documentar a pessoa responsável e o processo de exceções.
5. Só depois mudar para Block.

Um feed IPv4 bem selecionado para serviços muito expostos pode entrar em produção mais rapidamente do que um feed de domínios ou URLs. Estes últimos correspondem com maior frequência a infraestrutura partilhada, CDNs ou redirecionamentos e, por isso, exigem uma análise particularmente cuidadosa.

Antes de mudar para Block, registar o nome do feed, o número de IoCs, a posição e os hits observados até então. Se a alteração causar uma interrupção inesperada, voltar a definir imediatamente Action no mesmo feed como Monitor e testar novamente o tráfego afetado. Um feed defeituoso ou incontrolável pode ser temporariamente desativado. Uma Threat Exclusion global não é um rollback equivalente, porque também afeta MDR, NDR e Sophos X-Ops.

Ordem e nomes

O Active Threat Response processa os módulos pela seguinte ordem: MDR, NDR Essentials, Sophos X-Ops e depois Third-Party Threat Feeds. Com Log and drop, um hit num módulo anterior termina a verificação posterior. Com Log only ou Monitor, por outro lado, a firewall regista eventos individuais para MDR, X-Ops e Third-Party Threat Feeds.

Dentro de Third-Party Threat Feeds, a firewall avalia separadamente as listas Block e Monitor pela ordem apresentada. Regista o primeiro hit de cada lista e bloqueia com base no primeiro hit da lista Block. Por esse motivo, feeds de produção, feeds piloto e listas de incidentes temporárias devem ser claramente identificados e ordenados:

• cybora-premium-ipv4-block
• cybora-standard-domain-monitor
• incident-2026-06-c2-ipv4

Um bom nome indica o fornecedor ou a finalidade, o tipo de indicador e a ação. Isto poupa tempo durante a análise de logs e as revisões.

Distinguir os módulos de Threat Feed

Em Active threat response encontram-se várias funcionalidades com tarefas e requisitos de licença diferentes:

• Sophos X-Ops Threat Feeds: indicadores da Sophos; requerem Network Protection e, para aplicação, também Web Protection. Ambos estão incluídos nos bundles Standard ou Xstream ou podem ser licenciados individualmente.
• MDR Threat Feeds: IoCs do Sophos MDR; requerem o Xstream Protection Bundle e MDR Essentials ou MDR Complete no Sophos Fusion. O guia específico explica a integração com Sophos Fusion, a ação local, Audit ID, Task Queue e a validação do incidente.
• Third-Party Threat Feeds: listas externas de IPv4, domínios ou URLs; requerem o Xstream Protection Bundle.
• NDR Essentials: analisa o tráfego com machine learning. A visão geral de licenciamento dos módulos indica o Xstream Appliance Bundle, enquanto a ajuda de configuração indica o Xstream Protection Bundle. Antes de comprar ou implementar, consulte a comparação específica de licenças e fontes para NDR Essentials e obtenha uma confirmação vinculativa do entitlement para a firewall concreta.
• NDR Active Threat Intelligence: regista padrões NDR selecionados pela Sophos, requer o Xstream Protection Bundle e tem de ser ativado em cada regra de firewall através de Scan with NDR Active threat intelligence. Os modelos XGS 87/87w e 88/88w não são suportados.

Para utilizar Synchronized Security e obter o contexto adicional do endpoint nos logs do Active Threat Response, é também necessária uma licença Intercept X no Sophos Fusion. Esta licença não é um requisito do próprio Threat Feed, mas do enriquecimento do evento com dados do host, do utilizador e do processo.

Synchronized Security é opcional para a correspondência com os Threat Feeds. Se um Sophos Endpoint gerido enviar um Security Heartbeat vermelho após contactar um servidor malicioso, uma regra de Heartbeat corretamente configurada pode bloquear o seu tráfego; Lateral Movement Protection pode ainda isolar o endpoint comprometido da rede interna. Esta resposta do endpoint complementa o feed e os respetivos logs, mas não substitui a configuração do feed nem a regra de firewall.

Para NDR, consultar a instrução separada Operar Sophos Firewall NDR e Active Threat Response.

Compreender o efeito sobre o tráfego

Tráfego IPv4, de domínios e URLs

O tráfego IPv4 reencaminhado requer uma regra de firewall que processe o tráfego em causa. O tráfego direcionado para o sistema e destinado a serviços em Administration > Device access, como WebAdmin, VPN Portal e VPN, é comparado separadamente com indicadores de IP de origem e não passa por uma regra de firewall de trânsito.

Os pedidos DNS a que a própria firewall responde como servidor DNS são comparados com IoCs de domínio pelo módulo DNS. Se os clientes utilizarem outro servidor DNS, o IPS tem de ver o tráfego DNS. Por isso, um feed de domínios por si só não prova que o percurso real do resolver esteja a ser inspecionado.

Para tráfego reencaminhado, os feeds de domínios e URLs requerem adicionalmente Application Classification ou uma política IPS na regra de firewall. Application Classification está ativada por predefinição, mas deve mesmo assim ser verificada no percurso da regra em causa.

No caso de URLs HTTPS completos, a firewall também tem de ver o caminho. No percurso Web Proxy, selecionam-se Use web proxy instead of DPI engine e Decrypt HTTPS during web proxy filtering em Web filtering na regra de firewall. No percurso DPI, desativa-se Use web proxy instead of DPI engine e adiciona-se uma regra de inspeção SSL/TLS adequada com Action: Decrypt. Sem desencriptação, a firewall vê apenas o domínio através de SNI, e não o caminho URL completo.

O percurso de inspeção responsável é o módulo Web para o Web Proxy ou o IPS para a DPI Engine com regras de SSL/TLS Inspection. Isto aplica-se tanto a HTTPS encriptado como desencriptado; os IoCs que podem ser detetados continuam a depender de estar visível apenas o domínio ou também o caminho URL.

DNAT e WAF a partir do SFOS 22

Desde o SFOS 22, a firewall pode comparar o IP de origem do tráfego de entrada reencaminhado para DNAT e WAF com os MDR, NDR e Third-Party Threat Feeds. Isto permite reconhecer scanners e botnets conhecidos antes de alcançarem serviços publicados.

Para que estes hits apareçam no log do Active Threat Response, a opção Remote source match (inbound traffic) tem de estar ativada em System services > Log settings > Active threat response. Está desativada por predefinição. Sem esta definição, o bloqueio pode funcionar sem que os eventos DNAT ou WAF esperados apareçam no Log Viewer.

Casos de utilização típicos

Os Threat Feeds não ajudam apenas no tráfego de saída dos clientes. Sobretudo os serviços acessíveis publicamente são muitas vezes alvo de scans automatizados num curto espaço de tempo.

• DNAT para servidores internos: um feed IPv4 pode bloquear origens maliciosas conhecidas antes de estas chegarem ao servidor publicado.
• Publicações WAF: os dados de reputação complementam as regras WAF contra tráfego de bots, scans de CVE, sondagens a CMS e credential stuffing.
• VPN Portal, User Portal e WebAdmin: estes serviços são protegidos primeiro com MFA, redes de origem e Device Access e Local Service ACL. Os Threat Feeds reduzem adicionalmente origens de ataque conhecidas.
• Tráfego de saída dos clientes: feeds de domínios e URLs podem bloquear destinos conhecidos de malware, phishing e C2.
• Endereços WAN alvo de scans intensivos: um bom feed IPv4 reduz o ruído automatizado e alivia a firewall e os logs.

Os Threat Feeds complementam o hardening básico, mas não o substituem. Os serviços publicados continuam a precisar de regras DNAT ou WAF restritivas, apenas das portas necessárias, de limitações adequadas por origem ou país, IPS ou WAF e logging ativado. Um feed não dá carta branca para regras Any abrangentes. O processo geral encontra-se no Sophos Firewall Hardening Hub.

Verificar sincronização e operação

Testar separadamente a obtenção do feed e o efeito no tráfego

Sync status: Success confirma uma ligação ou um pedido HTTP GET bem-sucedido ao External URL, não a presença de todos os indicadores esperados nem a análise bem-sucedida de todos eles. Test connection também é apenas uma verificação da ligação. Uma verificação completa requer três níveis:

1. Obtenção: Test connection, Sync status, Last updated e Storage quota são plausíveis.
2. Conteúdo: existe um IoC esperado em Threat indicators.
3. Efeito: tráfego de teste controlado gera um hit em Log viewer > Active threat response ou no destino Sophos Fusion ou syslog configurado. Dependendo da correspondência, é possível rastrear o nome do feed, Log/Drop, a direção da correspondência, origem e destino ou URL, protocolo e portas.

Para um teste reproduzível, pode utilizar-se um feed piloto próprio e curto num servidor HTTPS controlado. Este contém o endereço IPv4 de um destino de teste também controlado. O feed permanece em Monitor, um cliente de laboratório estabelece uma ligação ao destino de teste e o administrador verifica a entrada no log. Não se deve aceder a destinos de malware ativos nem a sistemas de terceiros para realizar testes.

Sincronização e Storage Quota

Os seguintes valores da vista geral de feeds são importantes para a operação contínua:

• Success, Fetching ou Disabled em Sync status
• o timestamp esperado em Last updated
• um número plausível de Threat indicators
• uma Storage quota livre suficiente
• uma atualização manual bem-sucedida através de Synchronize now

O Summary apresenta Active feeds como o número de feeds ativos e o total de feeds configurados, Total threat indicators como o número de indicadores IPv4, de domínios e de URLs, e Storage quota como o armazenamento ocupado na quota dependente do modelo. Os equipamentos maiores têm mais espaço do que os modelos desktop. Refresh apenas atualiza estes contadores apresentados. Synchronize now, em Manage, obtém imediatamente o feed selecionado. É possível abrir e pesquisar IoCs individuais através de Threat indicators ou do número em Total indicators do feed em causa. Fetching significa que o download está em curso; Disabled significa que o feed está desativado.

Em caso de Authentication error, verificar primeiro o nome da API key, o valor secreto, o local de envio ou o nome de utilizador e a palavra-passe. Se estes dados estiverem corretos, investigar também uma possível falha no handshake TLS: verificar o certificado e a cadeia de confiança do servidor do feed e, se necessário, esclarecer a situação com o fornecedor. Nem todos os erros de autenticação são erros TLS. Validate server certificate permanece ativado; a falta de confiança na CA resolve-se com o certificado CA correto, não desativando a validação.

Em caso de Connection error, verificar DNS, acesso à Internet, servidor do feed e estado HTTP; 404, 500 e 302 também são causas possíveis. SSL/TLS error é um estado específico para problemas de certificados. Em caso de Failed, verificar se o ficheiro efetivamente fornecido está em texto simples, contém um indicador por linha e utiliza os tipos suportados adequados; também são possíveis outros erros. Após a correção, executar novamente Test connection e Synchronize now, verificar o timestamp e o IoC esperado e só depois repetir o teste de tráfego controlado. Se o erro persistir, registar o estado, a hora e os dados do feed sem informações secretas para os enviar ao fornecedor ou ao suporte.

Storage full significa que não existe espaço suficiente para a lista completa. A firewall continua a obter o feed no intervalo de polling configurado, mas só atualiza a lista de IoCs armazenada quando volta a existir espaço disponível. Por isso, deve verificar-se o âmbito, a qualidade e a prioridade dos feeds em vez de adicionar mais listas. Nos modelos XGS 87/87w, 88/88w e 107/107w, apenas estão disponíveis os intervalos de polling 24h, 7d e 30d para Third-Party Threat Feeds. Um feed do fornecedor atualizado com maior frequência não elimina esta limitação do equipamento.

Se não aparecerem hits

Ordem de verificação recomendada:

1. Feed ativo, Sync status: Success e IoC esperado em Threat indicators
2. uma deteção MDR, NDR ou X-Ops com prioridade superior para o mesmo IoC
3. logging do Active Threat Response e, para DNAT/WAF, Remote source match
4. a regra de firewall correspondente e o respetivo logging
5. para domínios e URLs, Application Classification ou uma política IPS
6. para URLs, Web Proxy ou DPI e SSL/TLS Inspection
7. Threat Exclusions, Web Exclusions e SSL/TLS Exclusion Lists

Para rastrear um IoC de domínio ou URL permitido até à regra responsável, abrir Log viewer > Web filter, procurar o IoC em Category ou diretamente o domínio e abrir a vista detalhada. Aí são apresentados o Firewall Rule ID e a Web policy selecionada nessa regra. Se a ação da política correspondente for Allow, verificar a ordem das regras e da política. Um bloqueio intencional utiliza um URL Group estritamente limitado numa Web Policy de bloqueio atribuída a uma regra LAN-to-WAN de prioridade superior. Em seguida, repetir o mesmo teste de tráfego.

Para o caminho DPI, abrir também Log viewer > SSL/TLS inspection, procurar o URL em Server name e verificar Action e SSL/TLS rule. Um IoC de URL requer Decrypt. Se a correspondência apresentar Don't decrypt, o Rule ID identifica a exceção ou regra que ignora a desencriptação. Adicionar um URL Group estritamente limitado a uma regra Decrypt de prioridade superior apenas depois desta atribuição. Implementar TLS Inspection passo a passo descreve o procedimento controlado.

Se um feed não gerar hits relevantes durante um período de observação representativo, deve reavaliar-se a sua utilidade. Primeiro, confirmar que a obtenção e o percurso de inspeção funcionam e verificar se MDR, NDR ou X-Ops já detetam os mesmos IoCs. Um teste curto sem hits não justifica a eliminação. Se, após estas verificações, o feed for efetivamente redundante, documentar antes de o eliminar o nome, URL, tipo de indicador, ação, posição, intervalo de polling e o local seguro onde estão guardadas as credenciais. Em Protect > Active threat response > Third-party threat feeds, eliminar o feed verificado para libertar armazenamento. Em seguida, verificar Refresh, Storage quota e Active feeds e voltar a obter, através de Synchronize now, um feed que tenha anteriormente falhado com Storage full. Para reverter a eliminação, recriar o feed com os valores documentados, inicialmente em Monitor. A desativação temporária para um rollback continua a ser uma operação distinta; não é considerada prova de que foi libertado armazenamento.

Tratar falsos positivos

Em caso de bloqueio incorreto, abrir primeiro a entrada no log e documentar o nome do feed, Log/Drop, a direção da correspondência, origem e destino ou URL, protocolo e portas. Em seguida, confirmar que o tráfego é legítimo, comunicar o indicador afetado ao fornecedor do feed e criar apenas a exceção mais restrita possível, com motivo, responsável e data de revisão.

Uma exceção abrangente para redes inteiras não é uma solução adequada. Em hits de domínio ou URL, podem estar igualmente envolvidos TLS Inspection, uma Web Policy, DNS Protection ou outra funcionalidade de segurança.

Uma exceção controlada é criada em Protect > Active threat response > Add threat exclusions. Em Host and network exclusions > Add new item, selecionar objetos de host ou rede existentes. Em Threat exclusions, introduzir um único endereço IP, domínio ou URL; cada entrada pode ter no máximo 128 carateres. Depois de Add e Apply, repetir o mesmo teste de tráfego e confirmar no Log Viewer que apenas a deteção esperada deixa de aparecer.

⚠️ Uma Threat Exclusion aplica-se a todos os módulos de Active Threat Response, não apenas ao feed que causou o falso positivo. Antes de Apply, avaliar o efeito sobre MDR, NDR, Sophos X-Ops e Third-Party Threat Feeds. Documentar a entrada, o motivo, o responsável e a data de revisão, e remover a exclusão quando deixar de ser necessária.

Backup e restore

Um backup da firewall contém a configuração dos Third-Party Threat Feeds, mas não as listas descarregadas. Após um restore, a firewall volta a obter imediatamente as fontes e aplica a ação configurada. Por isso, DNS, acesso à Internet, validação de certificados e credenciais têm de funcionar logo após o restauro.

As configurações de Threat Feed não podem ser importadas ou exportadas separadamente; as Threat Exclusions, por outro lado, podem. Após um restore, devem verificar-se novamente a obtenção do feed, o número de IoCs e o efeito no tráfego.

Automatizar ThirdPartyFeed através de XML

Para automatizar a mesma configuração de feed, a interface XML utiliza o objeto ThirdPartyFeed. Este configura a obtenção e a ação, não os IoCs individuais descarregados. O acesso, a operação explícita de escrita, a estrutura do pedido dependente da versão e a avaliação segura da resposta são explicados em Proteger o acesso à API XML. Os nomes de campos e limites seguintes aplicam-se ao contrato API do SFOS 22/23. Antes da utilização, confirmar a operação Add/Edit concreta e o respetivo payload em API help do build instalado. Se a sintaxe não estiver esclarecida ou existir um conflito entre fontes, não efetuar a escrita; esclarecer a questão com o suporte.

Antes de uma alteração, identificar o feed existente pelo seu Name no WebAdmin e guardar o nome, o tipo de indicador, o URL, a ação, o estado de ativação, a posição e o intervalo de consulta. O nome identifica a configuração do feed, não o fornecedor nem um IoC individual. O mesmo fornecedor pode ter várias configurações com nomes distintos para IPv4, domínios e URLs. Não deduzir do nome do objeto uma semântica de Rename, Upsert ou substituição que não tenha sido verificada.

• Identidade e origem: Name é obrigatório, permite no máximo 63 caracteres e apenas letras, números, sublinhados e hífenes. Description é opcional e está limitado a 255 caracteres. ExternalURL é obrigatório e está limitado a 1024 caracteres; continuar a utilizar um feed HTTPS de texto simples diretamente acessível, com um indicador por linha.
• Ação e ordem: Action exige exatamente block ou monitor, correspondentes a Block ou Monitor na interface. monitor regista as correspondências sem bloqueio pelo feed; block regista e bloqueia. As designações Log only e Log and drop de outros módulos não são valores de substituição para este campo. Position permite top ou bottom, correspondentes a Top ou Bottom. Isto seleciona a posição dentro dos Third-Party Feeds, não a sua precedência sobre MDR, NDR Essentials ou Sophos X-Ops. As listas de bloqueio e de monitorização mantêm-se separadas; a primeira correspondência de cada lista é determinante.
• Tipo de indicador: IndicatorType exige ip, domain ou url, correspondentes a IPv4 address, Domain ou URL. Neste contexto, ip não é um tipo IPv6, de rede ou de intervalo. Criar uma configuração própria para cada tipo de indicador pretendido.
• Autenticação: Authorization exige noAuthentication, basicAuthentication ou apiKey. Apenas com Basic Authentication se incluem Username e Password, cada um com um máximo de 64 caracteres. Apenas com autenticação por chave de API se incluem Key, Value e AddTo: o nome da chave e o valor secreto são separados e estão limitados a 64 caracteres cada; o local de transmissão é exatamente header ou queryParam, correspondentes a Header ou Query parameters. O requisito do fornecedor é determinante, não um valor predefinido presumido. Utilizar apenas os campos correspondentes ao método; obter os segredos de um repositório de segredos protegido e mantê-los fora de ficheiros XML no repositório, URLs em tickets, histórico da shell, capturas de ecrã e registos. Com parâmetros de consulta, prestar especial atenção à ocultação dos dados sensíveis nos URLs de feed registados.
• Verificação do certificado: ValidateServerCertificate é obrigatório; o exemplo do objeto apresenta true e false. Para um funcionamento seguro, ativar explicitamente a verificação e estabelecer previamente a confiança na CA adequada. Um erro de TLS ou de autenticação não justifica desativar a verificação.
• Intervalo de consulta: PollingInterval é obrigatório e permite exclusivamente 5m, 15m, 30m, 1h, 6h, 24h, 7d ou 30d. Estes são tokens fixos, não um número de minutos livremente selecionável. Nos XGS 87/87w, 88/88w e 107/107w, a seleção continua limitada a 24h, 7d e 30d. Por exemplo, 1h é adequado a uma atualização horária do fornecedor apenas num modelo que suporte esse intervalo.
• Ativação e valores predefinidos: Para Enabled, a tabela de parâmetros indica 1 e 0, enquanto o exemplo do objeto indica true e false. Trata-se de uma diferença de representação por esclarecer, não de uma prova de que as formas de escrita são intercambiáveis. Antes de tentar uma escrita, esclarecer a forma válida no build instalado. A tabela indica monitor, top, ip e noAuthentication como valores predefinidos dos campos correspondentes; confirmar os valores efetivos no build instalado. Definir deliberadamente a ação, a posição, o tipo e a autenticação, em vez de confiar em valores omitidos.

Interpretar com segurança as respostas Add/Edit

Para Add Third-party threat feed e Edit Third-party threat feed, estão documentadas as seguintes correspondências. Os valores Message.* são símbolos de mensagem não resolvidos, não textos de erro literais nem instruções de atuação suficientes por si só:

Em particular, 409 / Message.CPResourceConflict correspondem a Add e 404 / Message.CPRecordNotFound correspondem a Edit. Não equiparar estas correspondências específicas do objeto a códigos XML gerais ou a um estado de transporte HTTP; o que importa é a resposta efetiva e Status Message Information no build. Após cada alteração, comparar o feed guardado no WebAdmin com os valores pretendidos e verificar o Audit Trail. Em caso de erro, timeout ou resposta pouco clara, verificar primeiro o estado efetivamente guardado antes de voltar a enviar um Add ou Edit. Não deduzir de um símbolo uma repetição automática, uma mudança de nome ou uma suposta correção do erro.

Uma resposta de configuração adequada não comprova a obtenção do feed, o conteúdo dos IoCs nem o efeito sobre o tráfego. Em seguida, continuar a verificar Test connection, Synchronize now, Last updated, Storage quota, um IoC esperado e um teste controlado de tráfego em Monitor. Mudar para Block apenas após esta verificação; em caso de falhas inesperadas, restaurar a ação guardada ou desativar o feed de forma controlada, conforme descrito acima, e não definir uma Threat Exclusion global como alternativa.

Cybora Threat Feeds para Sophos Firewall

A Cybora disponibiliza os feeds de IPv4, domínios e URLs como ficheiros de texto através de HTTPS, com um indicador por linha. Segundo a descrição pública do produto, combina fontes OSINT e comunitárias, Threat Intelligence comercial, honeypots, sensores e sinais de firewalls. O formato é, portanto, diretamente compatível com a interface de terceiros do SFOS, mas um projeto-piloto em modo Monitor continua a ser necessário para confirmar o valor na própria rede.

A Cybora serve aqui como exemplo concreto de fornecedor. A qualquer outro fornecedor aplicam-se os mesmos critérios técnicos: tipos de indicadores adequados, ficheiro obtido diretamente, dados atuais, falsos positivos aceitáveis, hits rastreáveis e um processo de correção acessível.

Comparar planos

Free (Basic) contém apenas indicadores IPv4 e é atualizado a cada 24 horas, permitindo validar a entrega e a compatibilidade com o SFOS antes da compra. Standard fornece IPv4 e um conjunto menor de domínios a cada seis horas. Premium fornece IPv4, domínios e URLs de hora a hora, enquanto Ultimate fornece os mesmos tipos a cada 15 minutos. Nos XGS 87/87w, 88/88w e 107/107w, porém, o intervalo mínimo selecionável no SFOS continua a ser 24h, independentemente do plano do fornecedor.

Além do número e do preço, são importantes a atualidade, os tipos de indicadores suportados, a qualidade das fontes, o intervalo de atualização, o risco de falsos positivos e a rastreabilidade no Log Viewer. O feed adequado é aquele que gera hits relevantes com efeitos secundários aceitáveis no próprio ambiente.

Avanet Firewall Network

Uma parte do feed Premium provém de uma rede distribuída de firewalls. Esta perspetiva ajuda a identificar padrões de ataque que são quase impercetíveis numa única firewall.

Em ataques de brute force distribuídos, cada bot realiza apenas algumas tentativas de início de sessão falhadas e permanece frequentemente abaixo de um limiar local. A combinação de sinais anonimizados revela endereços IP que atacam deliberadamente infraestruturas em vários sistemas. Deste modo, surge um Threat Intelligence Feed continuamente atualizado para defesa automática.