{"id":31415,"date":"2019-10-31T21:41:08","date_gmt":"2019-10-31T18:41:08","guid":{"rendered":"https:\/\/prohoster.info\/blog\/vse-ochen-ploho-ili-novyj-vid-perehvata-trafika\/"},"modified":"2019-10-31T21:41:08","modified_gmt":"2019-10-31T18:41:08","slug":"vse-ochen-ploho-ili-novyj-vid-perehvata-trafika","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/vse-ochen-ploho-ili-novyj-vid-perehvata-trafika","title":{"rendered":"Tutto va molto male o una nuova forma di intercettazione del traffico","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

13 marzo nel gruppo di lavoro RIPE per la lotta contro gli abusi \u00e8 stata avanzata una proposta<\/a><\/noindex> di considerare l'hijack BGP come una violazione della politica RIPE. Se la proposta fosse accettata, il fornitore di servizi Internet attaccato attraverso l'intercettazione del traffico avrebbe la possibilit\u00e0 di inviare una richiesta speciale per far emergere il responsabile. Se il gruppo di esperti raccogliesse abbastanza prove a sostegno, tale LIR, fonte dell'hijack BGP, sarebbe considerato un trasgressore e potrebbe essere privato dello stato di LIR. Sono stati sollevati anche alcuni argomenti contro tale<\/a><\/noindex> modifiche.<\/p>\n

In questa pubblicazione vogliamo mostrare un esempio di attacco in cui non solo il vero colpevole era sotto esame, ma anche l'intero elenco di prefissi colpiti. Inoltre, tale attacco riaccende interrogativi sui motivi dei futuri hijack di traffico di questo tipo.
\n<\/a><\/noindex>
\nNegli ultimi due anni, la stampa ha riportato solo conflitti tipo MOAS (Multiple Origin Autonomous System) come hijack BGP. MOAS \u00e8 un caso specifico in cui due diverse autonome sistemi annunciano prefissi in conflitto con i rispettivi numeri ASN nell'AS_PATH (il primo ASN nell'AS_PATH \u00e8 indicato come origin ASN). Tuttavia, possiamo nominare almeno 3 tipi aggiuntivi<\/a><\/noindex> di intercettazione del traffico che consentono ai malintenzionati di manipolare l'attributo AS_PATH per vari scopi, incluso il bypass delle attuali tecniche di filtraggio e monitoraggio. Un noto tipo di attacco Piloso-Kapela<\/a><\/noindex> \u00e8 l'ultimo tipo di tale intercettazione, ma non per importanza. \u00c8 molto probabile che sia questo tipo di attacco che abbiamo osservato nelle ultime settimane. Tale evento ha una natura spiegabile e conseguenze piuttosto gravi.<\/p>\n

Coloro che cercano una versione TL;DR possono scorrere fino al sottotitolo 'Attacco ideale'.<\/p>\n

Contesto di rete<\/h3>\n

(per aiutarti a comprendere meglio i processi coinvolti in questo incidente)<\/i><\/p>\n

Se desideri inviare un pacchetto e hai diversi prefissi nella tabella di routing contenenti l'IP di destinazione, utilizzerai il percorso per il prefisso con la massima lunghezza. Se ci sono diversi percorsi per lo stesso prefisso nella tabella di routing, sceglierai il migliore (in base al meccanismo di selezione del miglior percorso).<\/p>\n

Le attuali tecniche di filtraggio e monitoraggio cercano di analizzare i percorsi e prendere decisioni analizzando l'attributo AS_PATH. Il router pu\u00f2 modificare questo attributo a qualunque valore durante l'annuncio. L'aggiunta semplice dell'ASN del proprietario all'inizio dell'AS_PATH (come origin ASN) pu\u00f2 essere sufficiente per aggirare i meccanismi di verifica della fonte correnti. Inoltre, se esiste un percorso dall'ASN attaccato a te, c'\u00e8 la possibilit\u00e0 di estrarre e utilizzare l'AS_PATH di quel percorso nei tuoi altri annunci. Qualsiasi verifica di validit\u00e0 solo dell'AS_PATH per i tuoi annunci contraffatti alla fine sar\u00e0 superata.<\/p>\n

Ci sono anche alcuni limiti degni di nota. In primo luogo, in caso di filtraggio di prefissi da parte di un fornitore superiore, il tuo percorso potrebbe comunque essere filtrato (anche con un AS_PATH corretto) se il prefisso non appartiene al tuo cono clienti configurato presso l'upstream. In secondo luogo, un AS_PATH valido pu\u00f2 diventare non valido se il percorso creato viene annunciato in direzioni non corrette, violando cos\u00ec la politica di routing. E infine, qualsiasi percorso con un prefisso che viola la lunghezza ROA pu\u00f2 essere considerato non valido.<\/p>\n

Incidente<\/h3>\n

\nAlcune settimane fa abbiamo ricevuto una segnalazione da un utente. Abbiamo visto percorsi con il suo ASN di origine e prefissi \/25, mentre l'utente ha affermato di non averli annunciati.<\/p>\n

TABLE_DUMP2|1554076803|B|xxx|265466|78.163.7.0\/25|265466 262761 263444 22356 3491 2914 9121|INCOMPLETE|xxx|0|0||NAG||
\nTABLE_DUMP2|1554076803|B|xxx|265466|78.163.7.128\/25|265466 262761 263444 22356 3491 2914 9121|INCOMPLETE|xxx|0|0||NAG||
\nTABLE_DUMP2|1554076803|B|xxx|265466|78.163.18.0\/25|265466 262761 263444 6762 2914 9121|INCOMPLETE|xxx|0|0||NAG||
\nTABLE_DUMP2|1554076803|B|xxx|265466|78.163.18.128\/25|265466 262761 263444 6762 2914 9121|INCOMPLETE|xxx|0|0||NAG||
\nTABLE_DUMP2|1554076803|B|xxx|265466|78.163.226.0\/25|265466 262761 263444 22356 3491 2914 9121|INCOMPLETE|xxx|0|0||NAG||
\nTABLE_DUMP2|1554076803|B|xxx|265466|78.163.226.128\/25|265466 262761 263444 22356 3491 2914 9121|INCOMPLETE|xxx|0|0||NAG||
\nTABLE_DUMP2|1554076803|B|xxx|265466|78.164.7.0\/25|265466 262761 263444 6762 2914 9121|INCOMPLETE|xxx|0|0||NAG||
\nTABLE_DUMP2|1554076803|B|xxx|265466|78.164.7.128\/25|265466 262761 263444 6762 2914 9121|INCOMPLETE|xxx|0|0||NAG||<\/code>
\nEsempi di annunci all'inizio di aprile 2019<\/i><\/p>\n

NTT in transito per il prefisso \/25 rende particolarmente sospettoso. Durante l'incidente, LG NTT non era a conoscenza di questo percorso. Quindi s\u00ec, un operatore sta creando un intero AS_PATH per questi prefissi! Un controllo su altri router evidenzia un ASN particolare: AS263444. Esaminando altri percorsi con questo sistema autonomo, ci siamo trovati nella seguente situazione:<\/p>\n

TABLE_DUMP2|1554076800|B|xxx|265466|1.6.36.0\/23|265466 262761 263444 52320 9583|IGP|xxx|0|0||NAG||
\nTABLE_DUMP2|1554076800|B|xxx|265466|1.6.38.0\/23|265466 262761 263444 52320 9583|IGP|xxx|0|0||NAG||
\nTABLE_DUMP2|1554076800|B|xxx|265466|1.23.143.0\/25|265466 262761 263444 22356 6762 9498 9730 45528|IGP|xxx|0|0||NAG||
\nTABLE_DUMP2|1554076800|B|xxx|265466|1.23.143.128\/25|265466 262761 263444 22356 6762 9498 9730 45528|IGP|xxx|0|0||NAG||
\nTABLE_DUMP2|1554076800|B|xxx|265466|1.24.0.0\/17|265466 262761 263444 6762 4837|IGP|xxx|0|0||NAG||
\nTABLE_DUMP2|1554076800|B|xxx|265466|1.24.128.0\/17|265466 262761 263444 6762 4837|IGP|xxx|0|0||NAG||
\nTABLE_DUMP2|1554076800|B|xxx|265466|1.26.0.0\/17|265466 262761 263444 6762 4837|IGP|xxx|0|0||NAG||
\nTABLE_DUMP2|1554076800|B|xxx|265466|1.26.128.0\/17|265466 262761 263444 6762 4837|IGP|xxx|0|0||NAG||
\nTABLE_DUMP2|1554076800|B|xxx|265466|1.64.96.0\/20|265466 262761 263444 6762 3491 4760|IGP|xxx|0|0||NAG||
\nTABLE_DUMP2|1554076800|B|xxx|265466|1.64.112.0\/20|265466 262761 263444 6762 3491 4760|IGP|xxx|0|0||NAG||<\/code>
\nProva a indovinare cosa non va qui<\/i><\/p>\n

Sembra che qualcuno abbia preso un prefisso da un percorso, lo abbia diviso in due parti e abbia annunciato un percorso con lo stesso AS_PATH per questi due prefissi.<\/p>\n

TABLE_DUMP2|1554076800|B|xxx|263444|1.6.36.0\/23|263444 52320 9583|IGP|xxx|0|0|32:12595 52320:21311 65444:20000|NAG||
\nTABLE_DUMP2|1554076800|B|xxx|263444|1.6.38.0\/23|263444 52320 9583|IGP|xxx|0|0|32:12595 52320:21311 65444:20000|NAG||
\nTABLE_DUMP2|1554076800|B|xxx|61775|1.6.36.0\/23|61775 262761 263444 52320 9583|IGP|xxx|0|0|32:12595 52320:21311 65444:20000|NAG||
\nTABLE_DUMP2|1554076800|B|xxx|61775|1.6.38.0\/23|61775 262761 263444 52320 9583|IGP|xxx|0|0|32:12595 52320:21311 65444:20000|NAG||
\nTABLE_DUMP2|1554076800|B|xxx|265466|1.6.36.0\/23|265466 262761 263444 52320 9583|IGP|xxx|0|0||NAG||
\nTABLE_DUMP2|1554076800|B|xxx|265466|1.6.38.0\/23|265466 262761 263444 52320 9583|IGP|xxx|0|0||NAG||
\nTABLE_DUMP2|1554076800|B|xxx|28172|1.6.36.0\/23|28172 52531 263444 52320 9583|IGP|xxx|0|0||NAG||
\nTABLE_DUMP2|1554076800|B|xxx|28172|1.6.38.0\/23|28172 52531 263444 52320 9583|IGP|xxx|0|0||NAG||<\/code>
\nEsempi di percorsi per una delle coppie di prefissi divisi<\/i><\/p>\n

Subito sorgono diverse domande. Qualcuno ha davvero provato nella pratica questo tipo di intercettazione? Qualcuno ha accettato questi percorsi? Quali prefissi sono stati colpiti?<\/p>\n

Qui inizia la nostra serie di sventure e un altro giro di delusione nella salute attuale di Internet.<\/p>\n

La strada delle sventure<\/h3>\n

\nIniziamo con ordine. Come possiamo identificare quali router hanno accettato percorsi intercettati e quale traffico pu\u00f2 gi\u00e0 essere reindirizzato oggi? Abbiamo pensato di partire dai prefissi \/25, poich\u00e9 sembrano \"non poter avere una diffusione globale\". Come potrete immaginare, ci siamo completamente sbagliati. Questa metrica si \u00e8 rivelata troppo rumorosa e i percorsi con such prefissi possono apparire anche da operatori Tier-1. Ad esempio, NTT ha circa 50 prefissi di questo tipo che distribuisce tra i propri clienti. D'altra parte, questa metrica \u00e8 scarsa, poich\u00e9 tali prefissi possono essere filtrati se l'operatore applica filtraggio di piccoli prefissi<\/a><\/noindex>, in tutte le direzioni. Pertanto, questo metodo non \u00e8 adatto per identificare tutti gli operatori il cui traffico \u00e8 stato reindirizzato a seguito di tale incidente.<\/p>\n

Un'altra buona idea \u00e8 sembrata quella di esaminare POV<\/a><\/noindex>. In particolare, i percorsi che violano la regola maxLength del relativo ROA. In questo modo, potremmo trovare il numero di diversi ASN origin con stato Invalid, visibili da questo AS. Tuttavia, c'\u00e8 un \"piccolo\" problema. La media (mediana e moda) di questo numero (il numero di diversi ASN origin) \u00e8 di circa 150 e, anche considerando il filtraggio dei piccoli prefissi, rimarr\u00e0 oltre 70. Questa situazione ha una spiegazione abbastanza semplice: ci sono solo pochi operatori che gi\u00e0 applicano filtri ROA con la politica di \"resettare i percorsi Invalid\" ai punti di ingresso, quindi, doveunque nel mondo reale un percorso che viola il ROA appaia, pu\u00f2 diffondersi in tutte le direzioni.<\/p>\n

Gli ultimi due approcci consentono di trovare operatori che hanno visto il nostro incidente (poich\u00e9 era abbastanza grande), ma in generale non sono applicabili. Bene, ma possiamo trovare l'autore dell'attacco? Quali sono le caratteristiche comuni di tale manipolazione AS_PATH? Ci sono alcune ipotesi di base:<\/p>\n