Analisi log e negative SEO: isolare attacchi con Python e Regex

Negli anni ho “assistito” a numerosi attacchi di negative SEO, trovando situazioni spesso complesse da comprendere, non solo nelle modalità ma anche e soprattutto nelle motivazioni dietro a questi attacchi.

Questo blog, ad esempio, è stato costantemente attaccato per anni, riuscendo tutto sommato a contrastare buona parte di queste tecniche. Non ho mai capito quelle persone che hanno tempo e soldi da perdere per danneggiare altri. Se dedicassero quel tempo nel fare cose buone probabilmente ne gioverebbero di più. Ma questo è un altro discorso…

La diagnosi standard del Negative SEO si concentra quasi esclusivamente sull’analisi del profilo backlink tramite tool di terze parti. Questo approccio è reattivo, incompleto e spesso fuorviante. Quando i link tossici appaiono in GSC o in un tool esterno, il danno potenziale (in termini di crawling, indicizzazione o valutazione algoritmica) è già in corso.

Per architetture complesse, l’unica “ground truth” per l’identificazione di un attacco in tempo reale è l’analisi dei file di log del server. È qui che i pattern anomali diventano evidenti prima che Google li processi e li rifletta nel ranking.

Questo articolo non discute il disavow. Discute la difesa proattiva a livello infrastrutturale, analizzando come identificare scraping aggressivo, resource draining e tentativi di injection tramite l’analisi di grandi volumi di log con Python e Regex.

Perché i tool di backlink non bastano

Affidarsi ai soli tool di analisi backlink per la diagnosi di Negative SEO presenta tre limiti fondamentali:

1. Latenza (Lag): Esiste un ritardo significativo tra la creazione di un link, la sua scoperta da parte dei crawler (sia di Google che dei tool), la sua indicizzazione e la sua eventuale valutazione algoritmica. L’analisi dei log è istantanea.
2. Incompletezza: Nessun tool ha una visione completa del link graph. Molti link (specialmente da domini spam di bassa qualità) potrebbero non essere mai scoperti dai crawler dei tool, ma essere comunque rilevati da Googlebot.
3. Focus Errato: La maggior parte degli algoritmi di Google (come Penguin 4.0, ora parte del core) è progettata per ignorare e svalutare lo spam, non per penalizzare attivamente. Il vero pericolo spesso non è il “link juice” negativo, ma l’impatto infrastrutturale dell’attacco.

Il Negative SEO più efficace oggi opera a un livello differente, mirando a esaurire le risorse del server e il crawl budget.

Tassonomia degli Attacchi Infrastrutturali (Rilevabili dai Log)

Prima di analizzare i dati, dobbiamo definire cosa stiamo cercando. I log rivelano pattern che i profili backlink non mostrano. Gli attacchi possono essere diretti (consumo di risorse server) o indiretti (consumo di crawl budget).

1. Direct Resource Draining (Attacco DoS Applicativo)

Questo è un attacco infrastrutturale diretto, spesso classificabile come attacco DoS (Denial of Service) a livello 7 (applicazione). L’attaccante utilizza una rete di bot o script (che non sono Googlebot) per generare un volume massiccio di richieste HTTP verso specifici endpoint del server.

L’obiettivo non è manipolare la SEO, ma saturare le risorse computazionali e infrastrutturali del target:

• CPU: Esecuzione di script complessi.
• RAM: Mantenimento di processi e sessioni.
• Connessioni al Database: Esaurimento del pool di connessioni disponibili.
• I/O Disco/Rete: Scrittura di log, lettura di file, invio di risposte.

Il risultato è un degrado delle performance fino al completo “service disruption” (Denial of Service), che impatta sia gli utenti reali sia i crawler legittimi come Googlebot, che riceverà timeout o errori 5xx.

Vettori Comuni: Gli URL “Costosi”

L’attacco è tanto più efficace quanto più “costoso” è l’URL target. Gli attaccanti non mirano a pagine statiche, che sono spesso servite da cache (CDN o server-side), ma a endpoint che forzano l’applicazione a lavorare.

1. Pagine Listing Complesse (Categorie, Filtri Faceted):

• Perché: Sono il target primario per e-commerce e portali. Ogni richiesta a un URL come /categoria?colore=rosso&taglia=L&ordina=prezzo_desc forza il backend a eseguire query SQL complesse (JOIN multipli tra tabelle prodotti, attributi, prezzi) e operazioni di sorting.
• Impatto: Un volume elevato di queste richieste può saturare il pool di connessioni del database (es. MySQL, PostgreSQL), bloccare tabelle e paralizzare l’intero sito, dato che il database è il bottleneck principale.

2. Script di Ricerca Interna (?s=, ?q=):

• Perché: Sono notoriamente resource-intensive. Ogni query di ricerca scatena operazioni LIKE '%...%' sul database o, in architetture più moderne, colpisce un engine di ricerca dedicato (es. Elasticsearch, Solr), che a sua volta consuma CPU e RAM per calcolare la pertinenza.
• Impatto: Gli attaccanti spesso usano query con stringhe randomizzate (?s=akjdhfksjdhf) per bypassare qualsiasi livello di cache (es. Varnish, Redis) e forzare un “cache miss” a ogni richiesta, colpendo direttamente l’engine di ricerca.

3. API Endpoints non protetti (o con Rate-Limiting insufficiente):

• Perché: Sono un accesso diretto alla logica applicativa. Endpoint che recuperano grandi volumi di dati (/api/v1/getProducts) o, peggio, che scrivono dati (es. form contatti, API di login) sono vettori ad alto impatto.
• Impatto: Un attacco a un’API di login può saturare i processi di hashing delle password (CPU-bound), mentre un attacco a un form di contatto può riempire il database di dati spazzatura (I/O-bound).

4. Generatori di Risorse “On-the-fly”:

• Perché: Funzionalità come la generazione dinamica di PDF (es. /download-scheda-tecnica.php?id=123), l’esportazione di CSV o il resizing/watermarking di immagini al volo sono estremamente onerose in termini di CPU e memoria.
• Impatto: Poche centinaia di richieste simultanee a questi script possono esaurire la CPU del server più rapidamente di decine di migliaia di richieste a pagine statiche.

Come si identifica nei Log

L’analisi dei log mostrerà pattern inequivocabili:

• Alto “Hit Rate”: Un numero anomalo di richieste al secondo/minuto provenienti da un singolo IP o da un blocco di IP (se l’attacco è distribuito, DDoS).
• Targeting Specifico: Le richieste non sono distribuite sull’intero sito, ma focalizzate quasi esclusivamente sui vettori “costosi” identificati sopra (es. POST /api/login, GET /search?q=...).
• User-Agent: Lo User-Agent è palesemente non-Googlebot. Sarà assente, generico (python-requests/3.8, curl/7.68.0, Go-http-client/1.1) o falsificato in modo banale. In questo scenario, Googlebot non è coinvolto né come attore né come vittima diretta (se non per il fatto che troverà il sito irraggiungibile).

2. Crawl Budget Hijacking (Dirottamento del Crawl Budget)

Questo è l’attacco SEO, più sofisticato. L’obiettivo è consumare il crawl budget che Googlebot dedica al sito web.

Lo spammer non può comandare Googlebot. Può, tuttavia, guidarlo. L’attacco consiste nell’indurre Googlebot a scoprire e scansionare un numero virtualmente infinito di URL spazzatura sul tuo dominio.

Il Meccanismo Tecnico:

1. Identificazione del Vettore: Lo spammer identifica un “crawl trap” sul tuo sito. I più comuni sono:
   • Pagine di ricerca interna (es. tuosito.com/search?q=)
   • Filtri faceted non gestiti (es. tuosito.com/categoria?colore=...&taglia=...)
   • Parametri URL che generano pagine uniche (es. tuosito.com/page.php?id=...)
2. Creazione di Link Esterni: Lo spammer utilizza la sua rete di siti (PBN, forum spam, sezioni commenti) per generare migliaia o milioni di backlink che puntano a questi URL trappola.
   • sito-spam-1.com -> linka a -> tuosito.com/search?q=viagra-online
   • sito-spam-2.com -> linka a -> tuosito.com/search?q=poker-strategy
   • sito-spam-3.com -> linka a -> tuosito.com/categoria?colore=blu&taglia=xxl&prezzo=1-1000
3. Scoperta e Scansione: Googlebot scansiona questi siti spam. Scopre i link che puntano al tuo dominio e, diligentemente, li segue per scoprirne il contenuto.
4. Consumo del Budget: Googlebot arriva sul tuo server e inizia a scansionare tuosito.com/search?q=viagra-online. Spreca il suo “crawl budget” (il tempo e le risorse che dedica al tuo sito) su queste pagine inutili, invece di scansionare i tuoi prodotti, servizi o articoli strategici.

Come si vede nei Log: In questo scenario, i log mostrerebbero:

• User-Agent: Googlebot (e la sua reale appartenenza va verificata tramite reverse DNS lookup).
• Richieste: Un volume anomalo di richieste a URL con parametri di ricerca (?s=, ?q=) o combinazioni di filtri infinite.
• Referer (a volte): L’analisi dei referer di queste richieste potrebbe (ma non sempre) rivelare i siti spam da cui Googlebot sta scoprendo i link.

Questo attacco è particolarmente dannoso perché non solo consuma risorse server per servire queste pagine a Googlebot, ma danneggia direttamente la SEO impedendo la corretta indicizzazione dei contenuti validi.

3. Hotlinking Massivo

Se il sito ospita immagini o risorse (es. PDF), un attacco di hotlinking da migliaia di domini spam può consumare la banda e le risorse del server, degradando l’esperienza utente e potenzialmente violando i parametri ToS dell’hosting.

Tempo fa mi capitò questo caso:

1. Il Target (La Vittima)

• Sito: Un produttore di macchinari industriali.
• Contenuto: Il sito ospita “schede tecniche”, “manuali utente” o “cataloghi” in PDF ad alta risoluzione.
• Il Vettore (L’Obiettivo): Un file specifico, ad esempio catalogo_generale_2024.pdf, che pesa 80MB. È un file “costoso” da servire in termini di banda.

2. I Sintomi (La Diagnosi Iniziale)

Il cliente si presenta con questi problemi:

• “Il sito è lento, specialmente in certi orari.”
• Google Search Console segnala un aumento degli errori server (503 Service Unavailable).
• I report di crawl budget mostrano un calo delle pagine scansionate al giorno e un aumento del “tempo di risposta del server”.
• Il ranking per le keyword principali sta iniziando a fluttuare e calare.
• L’hosting provider ha inviato alert per “eccessivo consumo di banda”.

L’analisi iniziale, fatta da un team poco esperto, concludeva così: “Dobbiamo ottimizzare il server, forse serve un upgrade dell’hosting”.

3. L’Analisi Log (La Diagnosi Corretta)

Seguendo la metodologia del nostro articolo, l’analisi dei file di log (access.log) mostrava un pattern anomalo. Non usai Python per questo, bastava un semplice grep o awk in shell per iniziare:

# 1. Troviamo le richieste più pesanti (top 10 file per byte inviati)
# 2. Contiamo le richieste per il nostro PDF sospetto
$ grep "catalogo_generale_2024.pdf" access.log | wc -l
> 150000

# 3. Analizziamo i referer per quel file
$ grep "catalogo_generale_2024.pdf" access.log | awk -F'"' '{print $6}' | sort | uniq -c | sort -nr | head -20

L’output di questo comando fu la prova schiacciante:

• 85000 http://sito-spam-cinese-1.cn/
• 72000 http://forum-russo-hackerato.ru/
• 61000 http://pbn-xyz-network.com/
• ... (migliaia di altri domini spam)
• 1500 http://www.sito-vittima.com/pagina-download/ (Questo è il traffico legittimo)

4. Cosa è Successo (La Meccanica dell’Attacco)

Un concorrente (o un servizio di Negative SEO) ha identificato il file da 80MB. Ha poi usato una rete di migliaia di siti spam (PBN, siti hackerati, commenti spam) per inserire un link diretto a quel PDF.

I pochi (o tanti) bot e visitatori che arrivano su queste migliaia di siti spam iniziano a scaricare il file da 80MB, migliaia di volte al giorno.

5. L’Impatto (Il Danno SEO)

Il server della vittima fu messo in ginocchio. È un attacco DoS applicativo a basso volume ma ad alto impatto.

Il server esaurisce la banda e/o il numero di connessioni disponibili. Quando Googlebot arriva per scansionare la homepage o una pagina categoria strategica, trova il server occupato (o “down”) e riceve spesso un errore 503.

Google non “penalizza” il sito: semplicemente, lo registra come inaffidabile. Di conseguenza, riduce il crawl budget (visita il sito meno spesso) e, non potendo accedere ai contenuti, inizia a declassare le pagine nei risultati di ricerca.

6. La Soluzione (La Neutralizzazione)

La soluzione non è il Disavow Tool. La soluzione è tecnica e immediata:

• Blocco a livello server (.htaccess / Nginx): Si implementa una regola che blocca le richieste per i file .pdf, .zip, .mp4 se l’HTTP_REFERER non appartiene al dominio stesso.

Esempio Nginx:

location ~ \.(pdf|zip|jpg|png)$ {
    valid_referers none blocked server_names *.sito-vittima.com;
    if ($invalid_referer) {
        return 403; # Forbidden
    }
}

4. Injection e Parameter Pollution

Questo attacco consiste nell’associare il dominio a query spam. I bot richiedono URL come:

• www.tuosito.com/?q=viagra-online
• www.tuosito.com/pagina-legittima?parametro_spam=parola-chiave-illegale

L’obiettivo è far sì che Google associ queste query al sito, inquini i report di GSC e, in casi estremi, generi “soft 404” o pagine indicizzate con contenuto spazzatura.

L’effetto di questo attacco è massimizzato nei casi in cui il sito web attaccato non faccia uso del tag rel canonical. Questo infatti genera l’indicizzazione di pagine duplicate con parametri “nocivi”.

Metodologia Operativa: Identificazione tramite Python e Regex

Assumiamo di avere accesso ai log (Nginx, Apache, CDN). Analizzare manualmente file da 10GB è impossibile. Utilizziamo Python con la libreria pandas per l’analisi e regex per il pattern matching.

Fase 1: Parsing dei Log

Il primo passo è convertire i log grezzi in un formato strutturato (un DataFrame pandas). Un formato Nginx comune potrebbe essere:

<ip_address> - - [<timestamp>] "<request_method> <request_url> <http_version>" <status_code> <bytes_sent> "<http_referer>" "<user_agent>"

Utilizziamo una Regex per parsare questa struttura.

import pandas as pd
import re

# Regex per un formato Nginx comune
# Questo deve essere adattato alla configurazione specifica del server
log_regex = r'^(?P<ip>[\d\.]+) - - \[(?P<timestamp>.+?)\] "(?P<request>.+?)" (?P<status>\d{3}) (?P<size>\d+) "(?P<referer>.*?)" "(?P<user_agent>.*?)"'

# Lista per contenere i dati parsati
data = []
# Leggere il file di log linea per linea per gestire grandi volumi
with open('access.log') as f:
    for line in f:
        match = re.search(log_regex, line)
        if match:
            data.append(match.groupdict())

# Creare il DataFrame per l'analisi
df = pd.DataFrame(data)

# Convertire tipi di dati per l'analisi
df['status'] = df['status'].astype(int)
df['size'] = df['size'].astype(int)
df['timestamp'] = pd.to_datetime(df['timestamp'], format='%d/%b/%Y:%H:%M:%S %z')

print(df.head())

Fase 2: Aggregazione e Identificazione Pattern

Ora che i dati sono in un DataFrame, possiamo aggregarli per trovare anomalie.

A. Identificare IP Sospetti (Alta Frequenza)

Un attacco “brute force” o di scraping è caratterizzato da un numero elevato di richieste da pochi IP.

# Aggregare per IP e contare le richieste
ip_analysis = df.groupby('ip').agg(
    request_count=('ip', 'size'),
    total_bytes=('size', 'sum'),
    unique_user_agents=('user_agent', 'nunique')
).sort_values(by='request_count', ascending=False)

# Visualizzare i top 10 IP per richieste
print("--- Analisi IP per Frequenza ---")
print(ip_analysis.head(10))

Cosa cercare:

• request_count elevato: Un IP che genera 50.000 richieste in un’ora è un’anomalia.
• Verifica DNS Inversa: Un IP con un request_count elevato che si spaccia per Googlebot (user_agent contenente “Googlebot”) deve essere validato. Un reverse DNS lookup sull’IP deve risolvere a un dominio googlebot.com o google.com. Se non lo fa, è uno spoofer.

B. Identificare User-Agent Sospetti

Aggreghiamo per User-Agent per trovare bot non identificati o malevoli.

# Aggregare per User-Agent
ua_analysis = df.groupby('user_agent').agg(
    request_count=('user_agent', 'size')
).sort_values(by='request_count', ascending=False)

# Filtrare i bot noti (es. Google, Bing) per concentrarsi sulle anomalie
known_bots = ['Googlebot', 'Bingbot', 'AhrefsBot', 'SemrushBot', 'DuckDuckGoBot']
ua_analysis_filtered = ua_analysis[~ua_analysis.index.str.contains('|'.join(known_bots), case=False)]

print("--- Analisi User-Agent Anomali ---")
print(ua_analysis_filtered.head(10))

Cosa cercare:

• User-Agent sconosciuti (es. python-requests, Go-http-client, o stringhe vuote) con decine di migliaia di richieste.

C. Identificare “Parameter Pollution” e “Crawl Budget Draining”

Qui entra in gioco la potenza di Regex applicata al DataFrame. Cerchiamo URL che contengono pattern di query spam o combinazioni di filtri eccessive.

# Esempio 1: Trovare URL con query spam (es. ?q=, ?s=, ?param=)
# (Crawl Budget Hijacking o Parameter Pollution)
spam_regex = r'\?(q|s|param|search)=.*(viagra|cialis|poker|casino)'
spam_requests = df[df['request'].str.contains(spam_regex, case=False, regex=True)]

if not spam_requests.empty:
    print(f"--- Rilevati {len(spam_requests)} tentativi di Parameter Pollution ---")
    # Aggregare gli IP che compiono questo attacco (se diretto)
    # o verificare lo User-Agent (se è Googlebot)
    print(spam_requests.groupby(['ip', 'user_agent']).size().sort_values(ascending=False))


# Esempio 2: Trovare attacchi a filtri faceted (e-commerce)
# Cerca URL che hanno 3 o più parametri filtro
filter_regex = r'(\?|&).*filter.*(\?|&).*filter.*(\?|&).*filter'
filter_drain_requests = df[df['request'].str.contains(filter_regex, case=False, regex=True)]

if not filter_drain_requests.empty:
    print(f"--- Rilevati {len(filter_drain_requests)} richieste di potenziale Filter Draining ---")
    print(filter_drain_requests.groupby(['ip', 'user_agent']).size().sort_values(ascending=False))

L’analisi di questi output fornisce una kill list precisa di indirizzi IP e User-Agent da neutralizzare (in caso di attacco diretto) o un elenco di pattern URL da bloccare (in caso di Crawl Budget Hijacking).

Strategie di Neutralizzazione (Server-Side)

Una volta identificata la fonte, l’azione deve essere immediata e a livello infrastrutturale.

1. Blocco Immediato (WAF, .htaccess, Nginx)

Questa è la soluzione prioritaria per gli attacchi diretti. Bloccare gli IP o gli User-Agent identificati.

Esempio Nginx (nginx.conf):

# Blocco per User-Agent malevolo identificato
if ($http_user_agent ~* (BadBot|python-requests|ScraperBot)) {
    return 403; # Forbidden
}

# Blocco IP singoli (da output Python)
deny 123.45.67.89;
deny 98.76.54.32;

# Blocco di un intero range (se l'attacco è distribuito)
deny 123.45.67.0/24;

Esempio Apache (.htaccess):

# Blocco per User-Agent
RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} (BadBot|python-requests|ScraperBot) [NC]
RewriteRule .* - [F,L]

# Blocco IP
<RequireAll>
    Require all granted
    Require not ip 123.45.67.89
    Require not ip 98.76.54.32
</RequireAll>

L’utilizzo di un Web Application Firewall (WAF) come Cloudflare o Akamai permette di implementare queste regole in modo più scalabile (es. “rate limiting”).

2. Gestione del Crawl (robots.txt)

Questa è la soluzione per il Crawl Budget Hijacking. Non vogliamo bloccare Googlebot (che sta solo seguendo dei link), ma impedirgli di scansionare gli URL spazzatura.

Esempio (robots.txt):

User-agent: *
Disallow: /*?s=
Disallow: /*?q=
Disallow: /*?*filter_
Disallow: /*?parametro_spam=

Questo previene la scansione di URL spazzatura, preservando il crawl budget per le pagine rilevanti.

3. Il Disavow Tool: L’Ultima Spiaggia

Il Disavow Tool di Google in genere non andrebbe utilizzato. Valuta di usarlo solo se:

1. In Google Search Console è stata ricevuta una Azione Manuale per link innaturali.
2. L’analisi (non dei log, ma dei tool di backlink) conferma un numero massiccio di link tossici che sono stati effettivamente indicizzati e che i blocchi server-side non possono gestire.

Nella maggior parte dei casi di Negative SEO infrastrutturale, il disavow è irrilevante. Il problema non è il link, ma la richiesta HTTP (se attacco diretto) o la gestione dei parametri (se attacco indiretto).

Conclusione Operativa

L’analisi di attacchi di Negative SEO non può limitarsi al monitoraggio dei backlink. Un approccio “expert-plus” richiede una difesa proattiva dell’infrastruttura.

L’analisi dei file di log tramite script (Python, Regex) è l’unico metodo per ottenere una diagnosi ground-truth e in tempo reale. Permette di distinguere un attacco diretto (DoS applicativo) da uno indiretto (Crawl Budget Hijacking) e di applicare la contromisura corretta:

• Attacco Diretto: Blocco IP/User-Agent a livello server/WAF.
• Attacco Indiretto: Blocco dei pattern URL tramite robots.txt.

Questa metodologia sposta il focus dalla reazione (disavow) alla prevenzione (blocco), che è fondamentale per la gestione di penalizzazioni e la salute a lungo termine di architetture complesse.