“Posso identificare i bot tramite IP?” è una delle domande più comuni che riceviamo sul filtraggio lato server. La risposta onesta è: l'IP da solo è un punto di partenza, non un verdetto — ma combinato con alcuni segnali ben scelti diventa affidabile. sgcWebSockets 2026.6 aggiunge un nuovo modulo di rilevamento dei bot al componente TsgcWebSocketFirewall che fa esattamente questo, classificando ogni IP che si connette usando quattro segnali indipendenti.
Il rilevamento dei bot si affianca alle funzionalità del firewall che già conosci — blacklist / whitelist, GeoIP, brute-force, rate limiting, threat scoring — e segue lo stesso design basato sulle proprietà del componente. Questo articolo illustra come funziona e come configurarlo.
Quattro segnali, una classificazione
Il modulo valuta ogni IP rispetto a quattro segnali indipendenti e risolve un singolo valore TsgcBotClassification:
- Intervalli IP di bot noti — confronta l'IP con gli intervalli di crawler pubblicati (Googlebot, Bingbot, GPTBot, ClaudeBot…) caricati da un file CIDR. Una corrispondenza indica un crawler autentico e dichiarato.
- Rilevamento di datacenter / hosting — segnala gli IP che appartengono agli intervalli dei provider cloud e VPS (AWS, Hetzner, OVH…). Gli utenti reali si connettono raramente da ASN di datacenter; il traffico automatizzato lo fa molto spesso.
- Reverse DNS confermato in avanti (FCrDNS) — esegue una ricerca PTR sull'IP, quindi conferma in avanti l'hostname risultante riportandolo allo stesso IP. Questo è l'unico modo affidabile per distinguere un vero Googlebot da qualsiasi cosa che si limiti a dichiararsi tale in un header.
- Reputazione DNSBL — interroga le blocklist DNS (Spamhaus e altre) per IP con una storia di abusi nota.
Il risultato è uno di sei valori:
TsgcBotClassification = (bcUnknown, bcVerifiedCrawler, bcDatacenter,
bcSuspectedBot, bcBlocklisted, bcHuman);
Il rilevamento basato solo sull'IP ha limiti reali — gli indirizzi sono condivisi dietro CGNAT, ruotano, e i bot sofisticati si nascondono all'interno di pool di proxy residenziali. Quindi il rilevamento dei bot è costruito per darti un buon punteggio di prima approssimazione, non una verità assoluta. Ecco perché, per progettazione, non blocca mai una connessione da solo.
Abilitare il rilevamento dei bot
Tutto risiede sotto la nuova proprietà BotDetection. Attiva i segnali che desideri e indica a quelli basati su file i loro dati:
uses
sgcWebSocket_Server_Firewall;
var
oFirewall: TsgcWebSocketFirewall;
begin
oFirewall := TsgcWebSocketFirewall.Create(nil);
oFirewall.BotDetection.Enabled := True;
// 1. Verified crawler IP ranges (file lines: CIDR,botname)
oFirewall.BotDetection.KnownBotsFile := 'C:\firewall\known-bots.csv';
// 2. Datacenter / hosting ranges (file lines: CIDR,asn-name)
oFirewall.BotDetection.Datacenter.Enabled := True;
oFirewall.BotDetection.Datacenter.ASNFile := 'C:\firewall\datacenter-ranges.csv';
// 3. Forward-confirmed reverse DNS verification
oFirewall.BotDetection.ReverseDNS.Enabled := True;
// 4. DNSBL reputation lookups
oFirewall.BotDetection.DNSBL.Enabled := True;
oFirewall.BotDetection.DNSBL.Zones.Add('zen.spamhaus.org');
// Resolution tuning
oFirewall.BotDetection.CacheDurationSec := 3600; // cache a verdict for 1h
oFirewall.BotDetection.DNSTimeoutMS := 2000;
oServer.Firewall := oFirewall;
end;
I due segnali basati su file riutilizzano lo stesso motore CIDR veloce con ricerca binaria che alimenta il database GeoIP del firewall, quindi anche liste di intervalli di grandi dimensioni si risolvono in microsecondi.
Reverse DNS e DNSBL non bloccano mai il thread di accept
Reverse DNS e DNSBL sono query DNS in tempo reale — eseguirle inline sul thread di accept della connessione sarebbe un denial of service autoinflitto. Invece, il rilevamento dei bot le risolve su un thread di lavoro in background e serve ogni classificazione da una cache. In caso di cache miss l'IP viene messo in coda per la risoluzione e la chiamata corrente restituisce immediatamente bcUnknown; quando la ricerca termina la cache viene aggiornata e l'evento OnBotDetected viene generato. La proprietà CacheDurationSec controlla per quanto tempo un verdetto viene riutilizzato prima che l'IP venga ricontrollato.
Solo classificazione: OnBotDetected
Il rilevamento dei bot è solo per la classificazione. Non nega mai una connessione da solo — genera un evento, aggiorna le statistiche del firewall (un nuovo contatore fvBot) e lascia a te la decisione sulla policy. Questo evita che un crawler verificato classificato erroneamente venga scartato silenziosamente.
procedure TForm1.FirewallBotDetected(Sender: TObject; const aIP: string;
aClassification: TsgcBotClassification; const aBotName: string);
begin
case aClassification of
bcVerifiedCrawler:
DoLog(aIP + ' is a verified crawler: ' + aBotName);
bcDatacenter:
DoLog(aIP + ' originates from a datacenter / hosting range');
bcBlocklisted:
DoLog(aIP + ' is listed on a DNSBL');
end;
end;
Puoi anche richiedere un verdetto in qualsiasi momento con GetBotClassification — comodo per adattare una risposta anziché filtrare una connessione:
if oFirewall.GetBotClassification(vClientIP) = bcVerifiedCrawler then
// serve a lightweight, cache-friendly variant to the crawler
ServeStaticSnapshot
else
ServeFullApp;
Agire su un verdetto: il motore Custom Rules
Quando vuoi bloccare, lo fai esplicitamente tramite il motore Custom Rules già esistente del firewall. Ogni TsgcFirewallRuleItem guadagna una nuova proprietà BotType: impostala, e la regola corrisponde alle connessioni la cui classificazione è uguale a quel valore. Puoi quindi negarle, bandirle o registrarle nei log — riutilizzando tutto il meccanismo delle regole che già possiedi.
var
oRule: TsgcFirewallRuleItem;
begin
oFirewall.CustomRules.Enabled := True;
// Ban any IP listed on a DNSBL for one hour
oRule := oFirewall.CustomRules.Rules.Add as TsgcFirewallRuleItem;
oRule.Name := 'ban-blocklisted-bots';
oRule.BotType := bcBlocklisted;
oRule.ActionType := raBan;
oRule.BanDurationSec := 3600;
end;
Questa separazione — classificazione passiva nel modulo di rilevamento dei bot, applicazione attiva solo tramite una regola che scrivi tu — significa che la funzionalità non può mai sorprenderti bloccando traffico che volevi mantenere.
Porta il tuo verdetto: OnResolveBot
Se gestisci già un servizio di threat intelligence, una cache di reputazione interna o un feed commerciale di mitigazione dei bot, assegna l'evento OnResolveBot. Quando è impostato, il tuo gestore fornisce il verdetto e i passi del resolver integrato si fanno da parte — lo stesso pattern di override che il firewall usa già per l'OnResolveCountry del GeoIP.
procedure TForm1.FirewallResolveBot(Sender: TObject; const aIP: string;
var aClassification: TsgcBotClassification; var aBotName: string);
begin
// Consult your own threat feed instead of the built-in resolver
if MyThreatFeed.IsMaliciousBot(aIP) then
begin
aClassification := bcBlocklisted;
aBotName := 'internal-threat-feed';
end;
end;
Demo
La demo Firewall in Demos\04.WebSocket_Other_Samples\13.Firewall ha una nuova scheda Bot Detection dove puoi attivare ogni segnale, caricare i file degli intervalli di bot noti e di datacenter, configurare le zone DNSBL e usare un tester “Classify IP” in tempo reale per vedere il verdetto per qualsiasi indirizzo — con ogni classificazione trasmessa al log degli eventi.
Disponibilità
Il rilevamento dei bot è incluso in sgcWebSockets 2026.6 ed è un'aggiunta drop-in: la proprietà BotDetection è disabilitata per impostazione predefinita, quindi i progetti esistenti non sono interessati finché non la attivi. La funzionalità è disponibile per Delphi (da 7 a 13), C++Builder e l'edizione .NET.
I clienti con un abbonamento attivo possono scaricare la nuova build dall'area clienti. Gli utenti trial possono ottenere l'installer aggiornato su esegece.com/products/websockets/download.
Domande, feedback o aiuto per la migrazione? Contattaci — riceverai una risposta dalle persone che hanno scritto il codice.
