Nascondere l'IP del server di origine

«Dovrei mettere una CDN davanti?» è la prima domanda che quasi tutti si pongono dopo aver comprato un server offshore, e non ha una risposta unica, perché in realtà sono due domande travestite da una sola. Assorbire un attacco e restare irrintracciabili sono problemi diversi con soluzioni diverse, e l'assetto che risolve l'uno può silenziosamente disfare l'altro.

La confusione costa cara in entrambe le direzioni. C'è chi mette una grande CDN americana davanti a contenuti per cui aveva scelto apposta un hosting DMCA-ignored, e restituisce così uno sportello reclami esattamente al tipo di intermediario che stava evitando. Altri saltano tutto, vengono colpiti da un flood a livello applicativo che il filtraggio di rete non è mai stato progettato per vedere, e concludono che la protezione DDoS fosse una bugia. Questa guida separa i due problemi, spiega cosa fa davvero ciascuno strato, e dedica la maggior parte del suo spazio alla parte che decide l'esito in entrambi i casi: i sei modi in cui un indirizzo di origine trapela anche quando tutto il resto è configurato correttamente.

Due problemi che sembrano uno solo

Qualunque cosa metti davanti a un server sta svolgendo uno di due compiti: tenere lontano un attacco, oppure tenere sconosciuto il suo indirizzo. Si sovrappongono abbastanza da creare confusione, e differiscono abbastanza perché risolvere quello sbagliato sia uno spreco di denaro.

Leggi due volte l'ultima riga, perché è quella che frega la gente. Tutto il resto in questa pagina è ingegneria. Quella riga no.

Cosa fa già il tuo host, e dove si ferma

Il filtraggio di livello 3 e 4 è incluso in ogni piano che vendiamo, senza costi aggiuntivi, e agisce al bordo della rete anziché sul tuo server — l'unico posto in cui può funzionare, perché un uplink saturo non si ripara con nulla che giri dietro di esso. La banda è illimitata, quindi un attacco non si trasforma in una fattura. Per la grande maggioranza di ciò che la gente chiama «un DDoS», è tutta qui la storia.

Ciò che non può vedere è l'altro tipo. Cinquecento richieste al secondo verso un endpoint di ricerca provenienti da quarantamila indirizzi residenziali non è traffico malformato; è traffico. Le connessioni Slowloris che trasmettono un header ogni pochi secondi sono, prese singolarmente, educate. Un form di login bombardato con corpi POST reali è indistinguibile, a livello di pacchetto, da un lunedì impegnativo. Nessun filtro di pacchetti aiuta, perché non c'è nulla di sbagliato nei pacchetti.

C'è una direzione di traffico su cui interveniamo, ed è bene dirlo chiaramente: attacchi e spam di massa originati dalla nostra rete possono essere null-routati per mantenere sana il resto dell'infrastruttura. È una misura operativa, non una misura sui contenuti — la distinzione che la nostra guida sull'hosting DMCA-ignored traccia in modo più dettagliato.

Cosa nasconde una CDN, e lo sportello reclami che erediti

Il meccanismo è semplice e genuinamente efficace. Il tuo dominio risolve verso gli indirizzi del provider, i client si connettono lì, e il provider recupera i contenuti dalla tua origine. L'indirizzo reale non compare mai nella connessione di un client, quindi non può essere attaccato da chi conosce solo il dominio. Lo stesso trucco è il motivo per cui il fronting via CDN funziona per i proxy resistenti alla censura: un censore vede traffico verso un indirizzo che non può permettersi di bloccare.

Tre cose arrivano insieme, e nessuna è nascosta nelle note in piccolo:

• Il bordo termina il tuo TLS. Il traffico è testo in chiaro dentro la rete del provider per progettazione — è così che funzionano caching e filtraggio. Qualunque cosa digitino i tuoi utenti raggiunge una terza parte prima di raggiungere te.
• Un canale di abuso che prima non esisteva. I reclami possono essere presentati direttamente contro la CDN, e una CDN risponde: inoltrandoli a te, identificando il tuo provider di hosting, oppure eliminandoti come cliente. Se la tua ragione per stare offshore è che i reclami non vanno da nessuna parte, mettere davanti un intermediario statunitense ricollega la catena che avevi pagato per spezzare.
• Un account. Indirizzo email, metodo di pagamento, spesso un numero di telefono, legati al tuo dominio e conservati a tempo indeterminato. Ne parliamo più avanti, perché di solito è l'anello più debole dell'intero assetto.

Niente di tutto ciò rende sbagliata una CDN. Ne fa una decisione a due facce: eccellente per un negozio o un'applicazione con utenti reali e vera pressione di livello 7, attivamente controproducente per una pubblicazione che attira takedown. La nostra risposta alla domanda, sulla pagina dell'hosting DMCA-ignored, è sempre stata la versione breve di questo: per resistere ai takedown, usa il filtraggio di rete che hai già e salta la CDN.

I sei modi in cui un indirizzo di origine trapela comunque

Questa è la sezione che conta, perché l'occultamento non è un prodotto che compri — è una proprietà che mantieni o perdi, di solito nel giro di pochi giorni, a causa di una di sei cose. Le origini vengono trovate ogni giorno dietro configurazioni CDN perfettamente valide.

• I log di Certificate Transparency. Ogni certificato pubblicamente attendibile emesso per il tuo dominio viene pubblicato in log pubblici, permanenti e ricercabili entro pochi minuti. Non pubblicano il tuo indirizzo; pubblicano i tuoi hostname — staging, mail, vpn, il sottodominio che hai configurato una volta nel 2024. Ognuno è un candidato da risolvere, e un solo record che non punta al front chiude la questione.
• La cronologia DNS. I servizi di passive-DNS archiviano ogni indirizzo a cui il tuo dominio ha mai risolto. Spostarsi dietro una CDN in seguito non fa sparire ciò che era già stato registrato — l'occultamento deve iniziare prima che il dominio risolva per la prima volta, oppure ti serve un nuovo indirizzo, non un nuovo front.
• I record che non si possono proxare, e quelli che hai dimenticato. I mail exchanger devono puntare a qualcosa di raggiungibile. Lo stesso vale per un record AAAA lasciato indietro quando hai proxato solo IPv4, un vecchio hostname FTP o del pannello, un wildcard, o l'host di sviluppo «temporaneo» che ormai ha tre anni.
• Qualunque cosa il server invii. La posta dall'origine porta il suo indirizzo nelle intestazioni Received — un messaggio di reset della password è un'autodenuncia. Webhook, recuperi di immagini in uscita, anteprime di link, pingback, controlli di aggiornamento e crash reporter contattano tutti l'esterno dall'indirizzo reale, e chiunque riesca a far parlare la tua applicazione con un host che controlla lo scopre.
• La scansione di tutto internet. Ogni indirizzo IPv4 viene scansionato e indicizzato continuamente da servizi pubblici, e i risultati sono interrogabili in pochi secondi. Se la tua origine risponde sulla porta 443 con il tuo certificato, o serve la tua homepage a qualunque header Host, farla corrispondere è una sola query contro un hash del corpo, un'impronta del certificato o un hash della favicon. È così che vengono trovate la maggior parte delle origini, e non costa nulla a chi cerca.
• L'applicazione che parla di sé stessa. URL assoluti e redirect che contengono l'indirizzo grezzo, endpoint di stato o metriche lasciati aperti, stack trace verbosi che nominano host interni, header che rivelano il backend, e il virtual host predefinito che serve allegramente il tuo sito a chiunque lo richieda per indirizzo.

Blindare l'origine perché solo il front possa raggiungerla

Un occultamento che dipende dal fatto che nessuno indovini l'indirizzo non è occultamento. L'assetto regge solo quando l'origine rifiuta di parlare con chiunque non sia il front, così che un indirizzo trapelato sia un fastidio e non un evento.

• Default-deny, poi consenti il front. Accetta le porte 80 e 443 solo dai range di indirizzi pubblicati dal provider, e aggiorna automaticamente quella lista — i range cambiano, e una lista non aggiornata fallisce aperta o fallisce chiusa nel momento peggiore. Tutto il resto, SSH compreso, appartiene a un tunnel o a un indirizzo di gestione, come nella nostra checklist di hardening della prima ora.
• Autentica il front. I certificati client tra la CDN e la tua origine — di solito chiamati authenticated origin pulls — fanno sì che anche un indirizzo corretto più un header Host corretto non ottengano nulla senza il certificato.
• Meglio ancora: nessuna porta in ingresso. Un tunnel solo in uscita dall'origine verso il bordo, sia esso il connettore proprio della CDN o WireGuard verso un nodo che gestisci tu, fa sì che l'origine non sia mai in ascolto su un'interfaccia pubblica. La scansione non può trovare ciò che non risponde, ed è la versione singolarmente più solida dell'assetto.
• Un solo virtual host, un solo header Host. Il server predefinito non dovrebbe restituire nulla di utile. Se il tuo sito si carica per indirizzo, verrà individuato da uno scanner entro la settimana.
• Sposta la posta fuori dall'origine web. La posta deve essere raggiungibile e deve identificarsi; tienila su una macchina propria, come presuppone la guida al server di posta.
• Verifica dall'esterno. Ogni controllo di questa lista è privo di senso se eseguito dal server stesso. Testa da una rete che non è la tua.

Un tuo front node al posto di una CDN

La terza opzione viene saltata perché non ha budget di marketing: un piccolo VPS come volto pubblico, un tunnel cifrato verso la macchina che detiene i dati, e nginx o HAProxy che fa passare il traffico tra i due. Dall'esterno sembra un qualunque server web. Quello vero sta altrove, senza alcuna porta in ingresso.

Quello che ottieni è occultamento senza nessun altro coinvolto nell'assetto — nessun account di terze parti, nessuno sportello reclami esterno, nessuno sconosciuto che termina il tuo TLS. Ottieni anche una separazione di giurisdizione altrimenti difficile da comprare: il front dove stanno gli utenti, i dati dove la legge ti conviene, scelti tra le nostre sette location. E poiché nessuna identità è stata associata alla registrazione, il front è usa e getta — un indirizzo bruciato si sostituisce in pochi minuti anziché negoziarlo.

Quello che non ottieni è capacità anycast. Un nodo ha la capacità di un nodo, e mentre il nostro filtraggio di rete lo protegge esattamente come protegge qualunque altro server, un attacco volumetrico davvero grande è una gara di banda che vince una rete globale. Il posizionamento onesto: un front node è la risposta giusta per nascondere un backend pesante o costoso — uno storage array, una macchina con GPU, un server di posta, un database — e per separare le giurisdizioni. Non è un sostituto di una CDN sotto pressione di livello 7 sostenuta.

Come scegliere, in una tabella

L'account è di solito l'anello più debole

Considera cosa succede quando l'infrastruttura è perfetta e la documentazione no. Il server è stato pagato in Monero, senza documenti d'identità e senza indirizzo email — l'assetto descritto nelle nostre pagine sull'hosting no-KYC. Poi viene aperto un account CDN con una carta, un indirizzo personale e un numero di telefono, elencando il dominio che protegge. Quell'account è un record identitario più solido e più duraturo di qualunque cosa sul server, detenuto da un'azienda che risponde alle citazioni legali, e vanifica del tutto la riservatezza del pagamento.

La correzione non è complicata, solo facile da dimenticare: se l'obiettivo è l'anonimato, o il front appartiene a te, oppure l'account che gli sta davanti è usa e getta e non attribuibile quanto il server dietro di esso. Server OpSec tratta questa disciplina in modo corretto, e la nostra risposta onesta sull'anonimato offshore è franca su quali anelli della catena di solito si spezzano per primi. Quasi mai sono quelli tecnici.

Verificare la tua esposizione in dieci minuti

Ogni voce qui sotto è qualcosa che una parte interessata controllerebbe nei primi minuti. Eseguile tu stesso, da una macchina che non è il server, prima di averne bisogno.

• Elenca ogni hostname che hai mai certificato. Cerca il tuo dominio apice in un motore di ricerca per Certificate Transparency e risolvi ogni risultato. Tutto ciò che non punta al front è una falla, inclusi gli host che non usi più.
• Leggi la tua stessa cronologia DNS. Una ricerca passive-DNS mostra gli indirizzi a cui il tuo dominio risolveva prima della CDN. Se l'origine di ieri è ancora l'origine di oggi, l'occultamento non è mai stato reale.
• Interroga direttamente l'origine. curl -sI --resolve example.com:443:198.51.100.10 https://example.com/ — se il sito risponde, il tuo firewall non sta limitando l'accesso al front, e chiunque abbia un indirizzo candidato può confermarlo con una sola richiesta.
• Interrogala senza garbo. curl -skI https://198.51.100.10/ non dovrebbe restituire nulla di riconoscibile. Un virtual host predefinito che serve la tua homepage è l'errore singolo più comune su questa pagina.
• Controlla ogni tipo di record, non solo A. dig +short AAAA example.com, dig +short MX example.com, e lo stesso per ogni sottodominio rivelato dai log di trasparenza. Un IPv6 lasciato non proxato è un classico.
• Mandati un'email dall'applicazione. Attiva un reset della password e leggi l'intera catena Received. Se l'indirizzo di origine c'è, allora c'è anche in ogni messaggio che hai mai inviato.
• Conferma che le porte siano chiuse. Da una rete non collegata, nmap -Pn -p80,443 198.51.100.10 dovrebbe mostrare filtered, non open.
• Cerca negli scanner. Cerca l'impronta del tuo certificato e l'hash della favicon della tua homepage in un indice pubblico di scansione di internet. Se la tua origine è indicizzata, è così che verrà trovata.

Quando l'indirizzo è già bruciato

Dai per scontato che restera bruciato. Un indirizzo apparso nel passive-DNS e negli indici di scansione è un record pubblico permanente, e nessuna modifica di configurazione lo ritira. La risposta è meccanica, non ingegnosa.

• Prima chiudi la falla. Ruotare verso un nuovo indirizzo senza chiudere il buco riproduce la situazione entro pochi giorni, e avrai speso una migrazione per non imparare nulla.
• Poi ruota. Distribuisci un sostituto — in una giurisdizione diversa se la ragione era legale anziché tecnica — ripristina, e fai il cutover. Poiché nessuna identità era stata associata al primo server, questo è un nuovo inizio anziché una trattativa, il che è il ritorno pratico e poco glamour di comprare server senza uno storico account.
• Prepara il cutover prima dell'emergenza. Un TTL DNS breve, una configurazione ridistribuibile da un repository e un ripristino testato trasformano un brutto pomeriggio in venti minuti. Nessuno organizza tutto questo durante un attacco.
• Ritira correttamente il vecchio indirizzo. Non lasciare il vecchio server parcheggiato sul vecchio indirizzo a servire lo stesso contenuto; è una conferma dal vivo per chiunque stia osservando, e mantiene fresco il record.

La versione breve

Il filtraggio a livello di rete gestisce gli attacchi volumetrici, arriva con il server e non costa nulla in più. Una CDN gestisce lo strato applicativo e nasconde l'origine, al prezzo di un intermediario che termina il tuo TLS, risponde ai reclami e sa chi sei. Un tuo front node compra occultamento senza l'intermediario, ma non capacità globale. La giurisdizione decide la questione legale e nessuno dei tre la tocca. E tutti e tre vengono vanificati da un solo record non proxato, un'email dall'origine, o un solo virtual host predefinito.

Decidi in base all'obiettivo e non all'abitudine, poi dedica dieci minuti all'audit — trova più esposizione reale di qualunque upgrade. Se vuoi l'architettura senza la terza parte, un piccolo VPS come front e il lavoro vero su hardware dedicato dietro di esso è l'assetto che vediamo più spesso tra chi è già stato trovato una volta.