Login

Benvenuto, Ospite
Nome utente: Password: Ricordami
  • Pagina:
  • 1

ARGOMENTO:

giallo nel panorama della sicurezza informatica BGP 6 Anni 10 Mesi fa #1

  • roberto ulisse
  • Autore della discussione
  • Offline
  • Platinum Member
  • Platinum Member
  • Messaggi: 289
  • Ringraziamenti ricevuti 35
A quanto pare per quanto riportato in questo articolo: checkblacklist.altervista.org/hacker-rus...edito-dovete-sapere/ ed in inglese in quest'altro: bgpmon.net/bgpstream-and-the-curious-case-of-as12389/ e cosi pare che router di rostelecom abbiano emesso degli annunci nei quali dichiaravano di avere sotto di se indirizzi ip che invece appartenevano in realta' ad altri provider cosi come scritto qui: "Starting at April 26 22:36 UTC till approximately 22:43 UTC AS12389 (PJSC Rostelecom) started to originate 50 prefixes for numerous other Autonomous systems. The 50 hijacked prefixes included 37 unique autonomous systems ......"
. Mi chiedevo se tali eventi siano in realta' la dimostrazione che la rete comunque funziona bene, visto e considerato che il problema e' durato dai 5 ai sette minuti e quali meccanismi consentanop a BGP di rilevare chi dice la verita' e chi invece mente, a quanto immagino io, pero' senza avere conoscenze specifiche di BGP, se due router annunciano di avere sotto loro delle reti non riesco a capire come fare per decidere, a meno che uno dei due dopo un primo annuncio che magari ha riconfigurato la rete in maniera errata poi sta zitto.
Qualcuno sa darmi qualche delucidazione, lo ringrazio anticipatamente!

Si prega Accedi a partecipare alla conversazione.

giallo nel panorama della sicurezza informatica BGP 6 Anni 10 Mesi fa #2

  • adorsi
  • Avatar di adorsi
  • Offline
  • Administrator
  • Administrator
  • Messaggi: 26
  • Ringraziamenti ricevuti 18
Ciao,

il problema degli annunci fake viene generalmente risolto filtrando le route annunciate in ingresso. In altre parole ciascun AS provvede a verificare cosa il corrispondente peer BGP ci annuncia, permettendo solo quanto è corretto. E come fa a sapere cosa va bene e cosa no? Semplice: si referenzia al RIPE, per quanto riguarda la nostra zona, oppure gli altri RIR se l'AS è geograficamente dislocato altrove.

Una volta eseguita la query al RIPE (anche mediante tool disponibili in rete) di solito si crea una prefix-list che contiene l'elenco di tutte le reti che appartengono al peer e poi la si applica come filtro in ingresso. Così facendo ciascun peer BGP potrà annunciarci solo le route che legalmente gli appartengono, mentre le altre verranno scartate.



Andrea
IpCert Instructor
CCNA R&S - CCNP R&S - CCIE #56256 R&S
Ringraziano per il messaggio: jpalombi

Si prega Accedi a partecipare alla conversazione.

giallo nel panorama della sicurezza informatica BGP 6 Anni 10 Mesi fa #3

  • roberto ulisse
  • Autore della discussione
  • Offline
  • Platinum Member
  • Platinum Member
  • Messaggi: 289
  • Ringraziamenti ricevuti 35
. Secondo quanto descrive DOrsi il processo di accettazione dei messaggi di routing deve passare un test di attendibilita' con conferma di una terza entita' quale un RIPE o un RIR, se le informazioni contenute nel messaggio ricevuto non sono avallate dal RIR o RIPE vengono scartate. Ritengo che comunque il processo di comunicazione tra peer sia preventivamente soggetto a sistemi di autenticazione attraverso meccanismi quali RSA cosi da escludere che i messaggi siano stati trasmessi da un "peer impostore".
Cosi il meccanismo funziona ma la vulnerabilita' resta perché comunque basta intervenire oltre che sul peer anche sul RIPE e si ottiene l'effetto voluto, e comunque sia a questo punto mi chiedo come sia potuto succedere quello che e' successo.
Oltretutto osservo che se nella sostanza ad ogni messaggio ricevuto si deve chiedere ad una entita' terza se il messaggio e' corretto cosa cambia a chiedere direttamente tutto cio' che puo' essere confermato al RIPE o al RIR cosi da costruire le tabelle anche piu' velocemente?
Comunque sia qualcuno sa indicare dove sia descritto questo processo di ulteriore conferma dei messaggi?

Si prega Accedi a partecipare alla conversazione.

giallo nel panorama della sicurezza informatica BGP 6 Anni 10 Mesi fa #4

  • adorsi
  • Avatar di adorsi
  • Offline
  • Administrator
  • Administrator
  • Messaggi: 26
  • Ringraziamenti ricevuti 18
Un paio di precisazioni:

Cosi il meccanismo funziona ma la vulnerabilita' resta perché comunque basta intervenire oltre che sul peer anche sul RIPE e si ottiene l'effetto voluto, e comunque sia a questo punto mi chiedo come sia potuto succedere quello che e' successo.
Il database del RIPE non è soggetto a modifiche esterne. I range di ip vengono assegnati agli ISP, abbinati ai corrispondenti numeri di AS. Per quanto riguarda il peer, questo è direttamente connesso su una PTP /30. A mio parere quanto accaduto è sinonimo del fatto che... non vi era quel controllo.

Oltretutto osservo che se nella sostanza ad ogni messaggio ricevuto si deve chiedere ad una entita' terza se il messaggio e' corretto cosa cambia a chiedere direttamente tutto cio' che puo' essere confermato al RIPE o al RIR cosi da costruire le tabelle anche piu' velocemente?
Il controllo viene fatto inizialmente, in fase di instaurazione del peering. Ci si mette d'accordo con il collega dell'altro AS (via email oppure al telefono) e si concorda su tutto: autenticazione, ip della PTP per l'interconnessione, prefix annunciati, eventuale default-route, eventuali community, eccetera. Poi, una volta fatte le verifiche del caso, si instaura il peering vero e proprio compreso dei filtri sopra indicati, ed il gioco è fatto.
Se un domani uno dei due AS otterrà dal RIPE un altro range di ip pubblici e vorrà quindi annunciarli, allora al suo peer diretto sarà necessario estendere quel filtro, aggiungendoci i nuovi prefix.



Andrea
IpCert Instructor
CCNA R&S - CCNP R&S - CCIE #56256 R&S

Si prega Accedi a partecipare alla conversazione.

giallo nel panorama della sicurezza informatica BGP 6 Anni 10 Mesi fa #5

  • roberto ulisse
  • Autore della discussione
  • Offline
  • Platinum Member
  • Platinum Member
  • Messaggi: 289
  • Ringraziamenti ricevuti 35
la risposta non coglie la piu' importante obiezione da me sollevata che non e' nel merito se il meccanismo funzioni o meno, il meccanismo funziona e' chiaro a tutti e comunque sia concepito ci sono tre entita, i due peer ed il ripe (o il rir), i messaggi tra i due peer sono confermati dal ripe o dal rir ma se c'e' una discordanza, e cioe' se da un controllo un messaggio viene scartato si opera nella convinzione che cio' che dice RIPE o RIR sia verita' maggiore rispetto a cio' che c'e' nel messaggio ricevuto dal PEER, allora non capisco a cosa servano i messaggi tra peer se, giustamente, un AS prima di aprire una nuova sottorete lo deve richiedere al RIPE, tanto vale a questo punto fare un routing centralizzato cosi da essere sempre sicuri che i riouter sianop avvisati solo quando viene effettivamemte richiesta da un qualche AS l'apertura di nuove numerazioni, come succedeva una volta per la rete telefonica nazionale nella quale il routing era centralizzato.
Rispondendo descrivendo i dettagli del meccanismo non toglie nulla alla obiezione che ho sollevato, introdurre una seconda entita' "piu' fidata" non ha senso perché se e' piu' fidata lei gli si puo' lasciare a lei il compito di distribuire le informazioni di configurazione della rete

Si prega Accedi a partecipare alla conversazione.

giallo nel panorama della sicurezza informatica BGP 6 Anni 10 Mesi fa #6

  • adorsi
  • Avatar di adorsi
  • Offline
  • Administrator
  • Administrator
  • Messaggi: 26
  • Ringraziamenti ricevuti 18
Rispondendoti con i dettagli non intendevo togliere alcunché. Cercavo solo di chiarirti qualcosa che, per lavoro, vedo tutti i giorni.
Scusa se ti ho risposto Roberto. Buona giornata.


Andrea
IpCert Instructor
CCNA R&S - CCNP R&S - CCIE #56256 R&S

Si prega Accedi a partecipare alla conversazione.

giallo nel panorama della sicurezza informatica BGP 6 Anni 10 Mesi fa #7

  • roberto ulisse
  • Autore della discussione
  • Offline
  • Platinum Member
  • Platinum Member
  • Messaggi: 289
  • Ringraziamenti ricevuti 35
=D Probabilmente la questione e' che non c'e' soluzione, si puo' solo cercare di rendere piu' difficile l'errore spostando e distribuendo le responsabilita', cosa che peraltro implica altri problemi, non e' il caso di scusarsi, qui si discute le questioni, hai dato il tuo contributo chiarendo che nel processo di routing BGP le informazioni scambiate tra gli AS sono soggette ed una verifica e che il PEER ricevente chiede esplicita conferma ad una terza entita', e' cosi?
Se e' cosi allora perché prima di rendere esecutive le azioni conseguenti al messaggio non si aspettino tali conferme? - Dal'analisi dell'accaduto parrebbe essere proprio cosi e cioe' che i messaggi vengono ricevuti ed attuati (aggiornando le tabelle di istradamento) e solo se poi non confermati scartati, perché se non fosse cosi non si spiegherebbe come mai ci sia stato il disservizio a meno di non ammettere che anche la preventiva verifica aveva dato esito positivo ed allora che senso ha fare due verifiche se sono ambedue false.
In altri termini consideriamo i fatti si assuma per fatto verificato che il disservizio sia avvenuto e che si sia risolto tra i 5 ed i 7 minuti, cio' significa che il messaggio "avvelenato" ha avuto seguito ed e' stato messo in atto, qui, in base al meccanismo da lei indicato, le ipotesi sono due la prima e' che il messaggio ricevuto viene prima attuato e poi verificato cosi il messaggio avvelenato e falso sia stato attuato ed abbia modificato le tabelle in rete e solo dopo che la verifica via RIPE abbia rivelato la falsita' del messaggio si siano scartate le modifiche (ma questa modalita' mi pare poco intelligente, perche' attuare qualcosa di cui si chiede conferma e non attendere la conferma prima di attuare?) oppure, in maniera piu' intelligente ed efficace, che il messaggio sia stato ricevuto verificato e confermato anche dal RIPE e cosi poi anche attuato, se e' questa seconda l'ipotesi reale mi chiedo una cosa: allora il RIPE o l'entita' terza che sia come ha fatto a cambiare idea in meno di 5 minuti? Cioe' se il Ripe o l'entita' terza ha convalidato in base a quale logica dopo qualche minuto ha smentito cio' che aveva affermato minuti prima?
Insomma c'e' molto piu' di qualcosa che non quadra, a meno di non pensare che c'e' stata sia la manomissione dei messaggi tra i peer e sia el database del RIPE o della terza entita' e che sia stato ricorretto in pochi minuti.
Un'altra ipotesi che viene invece dalla mia fantasia e' che quando il messaggio che annuncia la rete appartenente ad un AS venga ricevuto dall'AS che invece ha la rete realmente collegata al suo interno questo AS originale apra una procedura di contenzioso che viene in qualche modo risolta, secondo me questa potrebbe essere una modalita' migliore per l'accensione di una procedura di contesa, il protocollo descritto prima attraverso il RIPE o l'entita' terza a mio parere non chiarisce per come sono andate le cose

Si prega Accedi a partecipare alla conversazione.

Ultima Modifica: da roberto ulisse. Motivo: evidenziazione

giallo nel panorama della sicurezza informatica BGP 6 Anni 10 Mesi fa #8

  • roberto ulisse
  • Autore della discussione
  • Offline
  • Platinum Member
  • Platinum Member
  • Messaggi: 289
  • Ringraziamenti ricevuti 35
In riferimento a quanto ho scritto "questo AS originale apra una procedura di contenzioso che viene in qualche modo risolta" ritengo che l'accensione del contenzioso sia da attribuire all'entita' dell'autonomous system che ha realmente la rete collegata mentre la risoluzione della contesa sia da realizzarsi su hardware ed apparecchiature scollegate e secondo protocolli e servizi che non poggino in nessun modo sulle infrastrutture di rete che sono state oggetto del problema.
Cioe' la contesa e la sua risoluzione deve avvenire al di fuori delle infrastrutture di rete attaccate dal problema e con credenziali nuove utilizzate solo in caso di questo tipo di emergenza

Si prega Accedi a partecipare alla conversazione.

  • Pagina:
  • 1
Moderatori: jpalombi