Filtres : IP, ASN, DNS, bot signatures

Les listes de référence que les nodes de cloaking consomment. Où elles vivent dans le code, ce qu'elles contiennent, et comment les étendre.

Vue d'ensemble

Trackily ship 4 listes de référence utilisées par le moteur de cloaking et le calculateur de fraud score :

À ça s'ajoutent :

• KNOWN_BOTS — UA strings, utilisé par isBot() (server.js:1627)
• PROXY_HEADERS — headers HTTP révélateurs, utilisé par detectProxyHeaders() (server.js:1732)
• La blacklist IP utilisateur (table ip_blacklist) — IPs ajoutées dynamiquement (auto-fraud ou via action_block)

1. Reviewer IP blocklists

Liste de CIDR ranges appartenant aux infrastructures de review des plateformes pub. Source : public IP ranges officiels + observations terrain.

Plateformes couvertes

// server.js:1635
const REVIEWER_IP_RANGES = {
  facebook: [
    '66.220.144.0/20', '69.63.176.0/20', '69.171.224.0/19',
    '74.119.76.0/22', '103.4.96.0/22', '129.134.0.0/16',
    '157.240.0.0/16', '173.252.64.0/18', '179.60.192.0/22',
    '185.60.216.0/22', '204.15.20.0/22', '31.13.24.0/21',
    '31.13.64.0/18', '45.64.40.0/22', '185.89.218.0/23',
    '199.201.64.0/22',
  ],
  google: [
    '64.18.0.0/20', '64.233.160.0/19', '66.102.0.0/20',
    '66.249.64.0/19', '72.14.192.0/18', '74.125.0.0/16',
    '108.177.0.0/17', '142.250.0.0/15', '172.217.0.0/16',
    '173.194.0.0/16', '207.126.144.0/20', '209.85.128.0/17',
    '216.58.192.0/19', '216.239.32.0/19', '34.64.0.0/10',
    '35.190.0.0/17',
  ],
  tiktok: [
    '16.162.0.0/16', '34.92.0.0/14', '47.252.0.0/16',
    '47.88.0.0/14', '61.97.0.0/16', '103.136.220.0/22',
    '103.136.224.0/22', '111.225.148.0/22',
  ],
  bing: [
    '40.74.0.0/15', '40.76.0.0/14', '40.80.0.0/12',
    '40.112.0.0/13', '40.120.0.0/14', '40.124.0.0/16',
    '40.126.0.0/18', '52.96.0.0/12', '52.112.0.0/14',
    '104.40.0.0/13', '104.208.0.0/13', '131.253.12.0/22',
    '131.253.18.0/24', '131.253.21.0/24', '131.253.33.0/24',
    '199.30.16.0/20',
  ],
  snapchat: [
    '34.82.0.0/15', '35.186.0.0/16',
    '35.190.0.0/16', '35.227.0.0/16',
  ],
  pinterest: ['54.236.0.0/15', '52.0.0.0/11'],
};

Comment c'est évalué

function isReviewerIP(ip) {
  for (const [platform, ranges] of Object.entries(REVIEWER_IP_RANGES)) {
    for (const cidr of ranges) {
      if (ipInCIDR(ip, cidr)) return { detected: true, platform, cidr };
    }
  }
  return { detected: false };
}

Match CIDR pur (bitmask) — coût négligeable, ~0.1ms par check.

Comment étendre la liste

C'est hard-codé dans server.js. Pour ajouter une plateforme :

1. Édite server.js:1635
2. Ajoute une entrée dans REVIEWER_IP_RANGES : myplatform: ['1.2.3.0/24', ...]
3. Rebuild le binaire (npm run build:linux) ou redémarre Node si tu tournes en source

Roadmap : exposer ces listes dans Settings → Cloaking pour pouvoir les modifier sans recompiler. Ouvre une issue si tu en as besoin.

2. Reviewer DNS patterns

Suffixes de domaine qui trahissent une infra de reviewer via reverse DNS. Plus large que les CIDR — capture aussi les nouveaux ranges ajoutés par les plateformes.

// server.js:1708
const REVIEWER_DNS_PATTERNS = [
  // Meta / Facebook
  'facebook.com', 'fbcdn.net', 'fb.com', 'tfbnw.net', 'instagram.com',
  // Google
  'google.com', 'googlebot.com', 'googleapis.com',
  'googleplex.com', 'gstatic.com',
  // TikTok
  'tiktok.com', 'bytedance.com', 'musically.ly', 'tiktokcdn.com',
  // Microsoft / Bing
  'microsoft.com', 'bing.com', 'msn.com',
  'outlook.com', 'live.com',
  // Snapchat
  'snapchat.com', 'snap.com', 'sc-cdn.net',
  // Pinterest
  'pinterest.com', 'pinimg.com',
  // Twitter / X
  'twitter.com', 'x.com', 'twimg.com',
];

Comment c'est évalué

const rdns = await reverseDNS(ip);  // dns.reverse() avec cache 1h
const match = REVIEWER_DNS_PATTERNS.find(p => rdns.toLowerCase().endsWith(p));

Cache

Les lookups sont cachés dans reverseDNSCache (server.js:1692), TTL 1h. Première visite d'une IP = ~10–20ms, ensuite ~0ms.

Override per-workflow

Le node check_reverse_dns accepte un override patterns dans sa config (array de strings). Utile si tu veux ajouter le DNS d'une plateforme moins connue sans modifier le code global.

3. VPN / Proxy / Tor — KNOWN_VPN_ASNS

Mots-clés à chercher dans le champ isp retourné par l'API GeoIP. Si l'ISP contient un de ces mots, c'est probablement une connexion cachée.

// server.js:1719
const KNOWN_VPN_ASNS = [
  // VPN grand public
  'nordvpn', 'expressvpn', 'surfshark', 'cyberghost',
  'private internet access', 'mullvad', 'protonvpn',
  'ipvanish', 'tunnelbear', 'hotspot shield', 'windscribe',
  'hide.me', 'purevpn', 'zenmate', 'ghostery',
  // Tor
  'tor project', 'tor exit', 'tor relay',
  // Hosting providers souvent utilisés par services VPN
  'hostroyale', 'datacamp', 'm247', 'cdnext', 'tzulo',
  'privatelayer', 'vps2day', 'xhost', 'hostslick',
  // Termes génériques
  'vpn', 'proxy', 'anonymize', 'anonymo', 'hideme', 'hidester',
  'unblock', 'tunnelguru',
  // VPN second-tier
  'astrill', 'strongvpn', 'perfect privacy', 'anonine',
  'airvpn', 'atlasvpn',
  // Antivirus avec VPN intégré
  'bitdefender', 'kaspersky', 'avast secureline', 'norton secure',
  'f-secure', 'keepsolid',
];

Évaluation

const ispLower = (geo.isp || '').toLowerCase();
if (KNOWN_VPN_ASNS.some(v => ispLower.includes(v))) detected = true;

Plus le flag geo.is_proxy (de l'API GeoIP) — si l'API retourne is_proxy=true, c'est traité comme VPN détecté direct.

Faux positifs typiques

• bitdefender matche bien les vrais utilisateurs Bitdefender VPN, mais aussi parfois des résidentiels qui sortent via le VPN bundled de leur antivirus. Tu vas perdre 1-2% de vrai trafic.
• vpn est trop générique — match aussi des ISP légitimes qui ont "VPN" dans leur nom commercial. À supprimer si tu vois trop de bons users bloqués.

4. Datacenter detection — DATACENTER_KEYWORDS

// server.js:1760
const DATACENTER_KEYWORDS = [
  // Hébergeurs majeurs
  'hosting', 'cloud', 'datacenter', 'data center', 'server',
  'ovh', 'hetzner', 'digitalocean', 'amazon', 'aws',
  'google cloud', 'microsoft', 'azure', 'linode', 'vultr',
  'contabo', 'scaleway',
  // Tier 2
  'cogent', 'leaseweb', 'psychz', 'quadranet',
  'softlayer', 'rackspace', 'choopa',
  // CDN / edge
  'zscaler', 'akamai',
];

Évaluation

const ispLower = (geo.isp || '').toLowerCase();
detected = DATACENTER_KEYWORDS.some(k => ispLower.includes(k));

Faux positifs

• microsoft matche les vrais users qui sortent via Microsoft 365 (rare mais existe)
• amazon matche les visiteurs en lien avec Amazon WorkSpaces / VDI

Si tu vises du trafic B2B, mets check_datacenter en log only plutôt qu'en bloc.

5. Bots — KNOWN_BOTS

Liste des User-Agent strings de bots reconnus (crawlers SEO, scrapers, monitoring). Située plus haut dans server.js.

const KNOWN_BOTS = [
  'googlebot', 'bingbot', 'slurp', 'duckduckbot', 'baiduspider',
  'yandex', 'sogou', 'exabot', 'facebot', 'ia_archiver',
  'twitterbot', 'rogerbot', 'linkedinbot', 'embedly',
  'quora link preview', 'showyoubot', 'outbrain',
  'pinterest', 'developers.google.com', 'slack', 'vkshare',
  'w3c_validator', 'redditbot', 'applebot', 'whatsapp',
  'facebookexternalhit', 'tweetmeme',
  // Headless / automation
  'curl', 'wget', 'python-requests', 'go-http-client',
  'java/', 'okhttp', 'phantomjs', 'headless',
  'selenium', 'puppeteer', 'playwright',
  // SEO tools
  'ahrefsbot', 'semrushbot', 'mj12bot', 'dotbot',
  // Monitoring
  'uptimerobot', 'pingdom', 'newrelic',
];

Évaluation

function isBot(ua) {
  if (!ua) return true;
  const lc = ua.toLowerCase();
  return KNOWN_BOTS.some(b => lc.includes(b));
}

Note : un UA vide est toujours traité comme bot.

6. Proxy headers

Headers HTTP révélateurs d'un proxy :

// server.js:1732
const PROXY_HEADERS = [
  'x-forwarded-for', 'via', 'x-proxy-id', 'x-real-ip',
  'forwarded', 'x-originating-ip', 'x-remote-ip',
  'x-remote-addr', 'x-client-ip', 'x-cluster-client-ip',
  'true-client-ip',
];

L'analyse detectProxyHeaders() (server.js:1738) ne flag qu'en cas vraiment suspect :

• X-Forwarded-For avec plus de 2 IPs → multi_proxy_chain
• Présence d'un Via → via_header

Les autres headers de la liste sont collectés pour audit mais ne flag pas automatiquement (trop de faux positifs — beaucoup de proxies légitimes les utilisent).

La blacklist IP dynamique

Stockée en DB dans la table ip_blacklist. Alimentée :

1. Auto-fraude : quand fraud_score >= fraud_auto_blacklist_threshold (settable, défaut 80) — voir server.js:7532
2. Action action_block d'un workflow (si blacklist=true)
3. Manuel via Settings → Cloaking → Blacklist

Schema

CREATE TABLE ip_blacklist (
  id          SERIAL PRIMARY KEY,
  ip_start    TEXT,
  ip_end      TEXT,
  reason      TEXT DEFAULT '',
  auto_added  BOOLEAN DEFAULT false,
  created_at  TIMESTAMPTZ DEFAULT NOW()
);

Manipuler via MCP

Le tool MCP correspondant est exposé sous l'umbrella des outils de sécurité. Voir MCP → tools-reference.

Edge integration — Cloudflare

Si tu as configuré Cloudflare dans Settings → Integrations, les IPs auto-blacklistées sont aussi pushed vers le Cloudflare Edge Firewall (voir cfPushBlockedIP dans server.js). Ça les bloque avant même qu'elles n'arrivent sur ton serveur — économie CPU + bande passante.

Settings globaux — page Settings → Cloaking

L'onglet Settings → Cloaking expose 8 toggles globaux (voir public/admin.html:6442) :

Layer 1 (server-side)

Layer 2 (client-side)

Ces toggles agissent sur le fraud score global — ils n'affectent pas les nodes de cloaking spécifiques. Un workflow avec un node check_vpn continue de vérifier même si "VPN Detection" est désactivé globalement (le node a sa propre config).

Settings extra

Mettre à jour les listes en production

Trois cas :

a) Tu vois passer un reviewer non détecté

1. Note l'IP / le hostname dans les logs (fraud_events ou system_logs)
2. Si c'est dans un range CIDR identifiable, ajoute-le à REVIEWER_IP_RANGES (server.js:1635)
3. Si c'est un hostname distinct, ajoute le suffixe à REVIEWER_DNS_PATTERNS (server.js:1708)
4. Rebuild + redéploie

b) Un nouveau VPN passe à travers

1. Trouve le nom commercial du VPN (souvent dans l'ISP du whois)
2. Ajoute un mot-clé à KNOWN_VPN_ASNS (server.js:1719)
3. Rebuild

c) Tu vois trop de faux positifs

1. Identifie le mot-clé qui matche (ex : bitdefender)
2. Retire-le de la liste OU enrichis le check avec une seconde condition

Roadmap : exposer toutes ces listes en DB (table cloaking_lists) pour pouvoir les modifier depuis l'UI sans rebuild. Voir issue tracker.

Vérifier qu'une IP est bien dans une liste

Le simulateur de campagne (voir Workflows → Tester un workflow) te dit exactement ce qui a matché pour une IP donnée :

→ Check Reviewer IP: 🔴 DETECTED (facebook)
→ Check Reverse DNS: 🟢 No match [rdns: ec2-54-x-x-x.compute-1.amazonaws.com]
→ Check VPN/Proxy/Tor: 🟢 Clean [ISP: Amazon]
→ Check Datacenter: 🔴 DETECTED

Voir aussi

• Workflows — créer, attacher, tester
• Nodes — quels nodes utilisent quelles listes
• Cloaking — index — concept
• Settings — Cloaking — UI des toggles globaux
• MCP — tools-reference — outils de gestion blacklist