| Autore: PUOJACKZ | Data: 2005-10-24 |
| Modificato:
2005-10-25 |
Letture: 8628 |
|
Preambolo:
C'è da precisare che alcune tecniche descritte in questo articolo(sviluppato anni fa, ma pubblicato solo in questi giorni), ma soprattutto le cause che spingevano i ragazzi a sfruttare le IRCWars sono ormai poco diffuse in virtù del fatto che la stragrande maggioranza delle reti IRC hanno adottato sempre di più l'impiego di Services, i quali rendono obsoleto l'uso di DoS per ottenere lo status di canali(Takeover).
Contenuti
1. Introduzione
2. Il Lag
3. I NetSplits 4. Desynch & Resynch
1. Introduzione
A causa della propria natura di collegamento, il sistema Liveness, che si basa sulla spedizione di un segnale per capire se un determinato host è ancora collegato oppure no, soffre di una problematica rappresentata da aspetti fisici: i Netsplit e il Lag.
2. Il Lag
La prima cosa da comprendere è la struttura di IRC. IRC in sostanza non è nient'altro che un enorme rete di server linkati fra di loro. La struttura tipica è ad albero:
A - B - C - D
Questo tipo di network appena menzionato è un network principalmente di base. Un network esteso come IRCnet è, circa, come il diagramma qua sotto.
G - H - I - J - K - L - M - N
| | | | / \ \
A - B - C - D - E - F - Z
| | / | |
O - P - Q - R - S - T
| / \
U V W
Per i propositi di questa spiegazione, tuttavia, noi rimaniamo con i 4 server in serie per rendere il tutto più facile da capire. Dal diagramma si può notare che per ogni dato, che vada in qualsiasi posto della rete, c'è solo una via di instradamento. Percui se qualcuno spedisce dei dati dal server A al server D, questo può andare solo attraverso A, B e C e poi arrivare a destinazione nel server D. Da ogni punto di passaggio il viaggio richiede tempo, che può dipendere pure anche dalla distanza geografica tra client e server di passaggio. Se c'è una connessione lenta tra il server B e C questo causerà un rallentamento anche sensibile da parte del client e quindi ci vorrà molto tempo per inviare un dato.
Ora, se si esegue un CTCP (Client to Client Protocol = Protocollo utente - utente) ping a qualcuno (/ctcp nickname PING) si ottiene, come risposta, il seguente messaggio: (ad esempio)
[PUOJACKZ PING reply]: 37 secs
Percui diciamo che PUOJACKZ ha un lag di 37 secondi; questo significa che i dati inviati a lui necessitano 37 secondi perché siano recapitati e se quest'ultimo invia a noi dei dati, occorrerà lo stesso tempo perché noi riusciamo a riceverli. Inoltre possiamo dire che nei giorni in cui il lag è particolarmente alto, la differenza di risposta potrebbe dipendere anche tra servers stessi, causati da vari problemi quali errori degli IRCd (IRC Daemon), problemi esterni della shell dove sono installati, DoS presso le shell ecc... e quindi potrebbe apparire così:
A ------- B -------- C -------- D
9 sec 6 sec 10 sec
Se il lag è proporzionale e qualcuno esegue un ping al server D, dal server A, si riceverà una risposta di ping pari a 50 secondi. Questa è tutta la differenza di tempo moltiplicata per 2. Percui, ci vorrebbero 50 secondi per i dati spediti al server (in questo caso il ping) D, per raggiungere la destinazione e ritornare indietro; se qualcuno, invece, eseguisse un ping al server D dal server B, occorrerebbero 32 secondi. Questo sta a significare che il lag è proporzionale, e forse nessuno è realmente laggato, rispetto all'altro.
Guarda questo esempio:
A ------- B -------- C -------- D
1 2 3 4
Se noi abbiamo una persona su ogni server e tu, nel server A, esegui un ping su tutti, le risposte che riceverai saranno queste:
[1 PING reply]: 0 secondi
[2 PING reply]: 18 secondi
[3 PING reply]: 30 secondi
[4 PING reply]: 50 secondi
Ora, guarda dove il problema sembra sorgere. Noi abbiamo 2 bots, uno nel server A (Bot 1) e uno nel server D (Bot 2).
A ----- B ------ C ------ D
9 sec 6 sec 10 sec
Bot 1 Bot 2
Un utente entra in un canale dal server B. 9 secondi dopo che l'utente è entrato, Bot 1, nel server A, vede l'utente e lo rende moderatore di canale. Poi, dopo 7 secondi, il Bot 2 nel server D vede l'utente e gli da lo stato di ChanOp. Così tutti gli utenti nel server A pensano che sia il Bot 1 ad aver oppato l'utente, e tutti gli utenti del server D pensano che sia il Bot 2 ad averlo fatto. L'utente stesso pensa, naturalmente, che sia stato il Bot1 perché, avendo meno lag rispetto ad esso, ha visto prima l'azione compiuta da quest'ultimo che dell'altro bot. Questo significa che ogni volta che il lag è particolarmente alto, le conversazioni possono rapidamente diventare intollerabili a causa del tempo di risposta molto lungo. Gli utenti possono evitare ciò spostandosi nei servers più vicini a tutti gli altri. Idealmente il lag da server a server è in millisecondi e, in questi casi, non è un problema. Tuttavia, qualchevolta, a causa dei problemi dell'intero network, possono diventare addirittura dai 20 ai 30 (e superiori). Ci sono molte ragioni di questi ritardi come, ad esempio, a causa di servers sovraccarichi, troppi utenti in un server, server abusati (es. flooding e spreco di banda di trasmissione), link rallentati o routing scarso. Ultimamente il lag è anche un segnale, nelle reti di piccola affluenza di utenti, per indicizzare quando un server, o l'hub o un leaf, è sottoposto ad attacchi DoS o DDoS. Il synflooder Trin00, ad esempio, usa un sistema di reti combinate per spedire un fotio di segnali "echo ping" che in apparenza sembrano inutili, ma con lo scopo di occupare banda di trasmissione alla connessione in corso di un server. Questo è uno dei motivi di lag (o come dicono in gergo "quando la connessione soffre"), ed, in caso, quando splitta ("quando la connessione salta o muore"). Quando i due servers vedono che non c'è più risposta tra loro "splittano" la connessione, ossia si staccano. E se accade, gli utenti all'interno si staccano dalla rete per SQuit o NetSplit. Il termine SQuit è l'abbreviato di Split Quit ed indicizza una disconnessione dal network forzata (che avviene in automatico, in caso di lag, oppure eseguita dall'amministratore del server stesso).
3 . I NetSplits
Un NetSplit avviene quando due server perdono il contatto tra di loro. Di solito un server ha una differenza di tempo notevole dall'altro, che aumenta a seconda del punto dove, nella rete, non riescono a interscambiare i dati in modo abbastanza veloce. Usando i 4 servers come un esempio proviamo a vedere come e cosa succede durante uno Split.
A -------- B ------- C ------- D prima dello split
A ---| |--- B ------- C ------- D dopo
Dal punto di vista delle persone nel server B,C e D, le persone del server A hanno lasciato IRC, e vice versa per le quelle del server A. Il messaggio tipico di uscita (Quit) durante un netsplit è del tipo:
[18:40] *** Quit: LOL (Server1.MyServer.org Server2.MyServer.org)
[18:40] *** Lascia: LOL (Server1.MyServer.org (server di origine) Server2.MyServer.org (server splittato))
Percui su un canale si vedrà:
[18:40] *** LOL has left IRC (Server1.MyServer.org Server2.MyServer.org)
[18:40] *** LOL ha lasciato IRC (Server1.MyServer.org Server2.MyServer.org)
Questo dimostra che i due servers sono splittati. Ma ricorda: questo è relativo. Nel resto del network, gli altri utenti vedranno che gli utenti su Experience.* e CalifornianLighs.* hanno lasciato IRC, e gli utenti su Experience.* e CalifornianLighs.* hanno visto tutti gli altri lasciare IRC. Una delle funzioni degli IRCOp è quella di ricreare il routing, e l'amministratore del server ha il compito di tentare di riconnettere il server con gli altri servers del network; naturalmente loro decideranno pure il momento in cui è più conveniente riconnettersi. Se ad esempio vi è molto lag con i servers che ci si vuole connettere (ad esempio tutta il network è sotto attacco DDoS) è inutile eseguire tale operazione fino a quando il problema non è stato risolto.
Molti degli utenti meno intelligenti provano a provocare NetSplit o approfittando di quando accadono, per generare takeovers dentro i canali, sfruttando i desynch causati dalla scissione avvenuta. Quando due server splittano e si riconnettono, si passano le informazioni di tutti gli utenti collegati, dei canali creati e delle configurazioni di quest'ultimi. Quando questi vedono che in entrambi è presente lo stesso nickname, l'unico modo per riportare l'ordine è quello di killare entrambi i nicknames. Che fa un takker? se per esempio deve causare un takeover sul canale #italia, lui entra nel server splittato, entra nel canale dove vuole effettuare il TakeOver (che, essendo splittato, avrà gli utenti in locale, o sarà vuoto) e carica dei cloni o dei bots, impostando loro, le stesse identità dei moderatori del canale dove vuole causare il Take. Quando i due server linkano, vedono che i nicknames sono sia su uno che sull'altro server e li killa entrambi.
Un altro sistema per causare TakeOvers è sfruttando il ServerMode. Quando due servers si ricollegano, si passano le informazioni dei canali persi durante lo Split e quindi pure i modes di canale e di utente che c'erano su questi. I takker usano questo metodo per farsi oppare nei canali al momento del relink. Loro vanno nel server splittato, si rendono moderatori nel canale di quel server e aspettano il relink con il resto della rete. Quando il server relinka, vede anche il takker come moderatore del canale e lo rende ChanOp nel canale. Ultimamente, però, l'uso di questi sistemi è inefficace in quanto gli IRCd sono o patchati, o nella rete sono presenti i Services, in grado di ristabilire l'ordine senza problemi.
L'unica cosa da fare durante un netsplit sta nell'aspettare la riconnessione dei server, in tutta tranquillità. Cambiare server durante uno split è una CATTIVA IDEA, perchè potresti causare una collisione di nickname. Quando più servers sono vittima di lag elevati, spesso non riescono ad aggiornarsi, chiudendo la connessione con i nicknames collegati. In questi casi, il cambio di server potrebbe causare il kill di quest'ultimo.
3.1 Che significa quando un canale, in seguito alla riconnessione del server splittato, collide? e un nick?
Dopo un Netsplit, gli utenti continuano ad entrare da entrambi i network spezzati, e le persone che avevano lo stesso nickname, una volta avvenuta la riconnessione con il resto del Network, vengono killate. Questo accade frequentemente con i nick più usati. E' un fenomeno chiamato Nick Collision (Collisione di Nickname). Le collisioni di nick o di canali possono anche esser provocate tramite attacchi DDoS con il proposito di creare problemi agli utenti vittima dei Nick Collision Kills oppure per causare SQuit Collision Nick/Channel Takeover. In genere questi comportamenti sono molto fastidiosi, e gli IRCop pongono K-line agli utenti che li provocano.
3.2 Che cos'è un ServerOp? Server1.MyServer.org setta i mode: +ooo Nick1 Nick2 Nick3
Dopo un Netsplit, durante il processo di riconnessione dei servers e degli utenti presenti, avviene l'aggiornamento dei dati andati persi durante la scissione. I nuovi utenti, i loro nicknames, i canali dove si trovavano e i loro settaggi vengono riaggiornati. Il processo di settaggio dei ChanModes nei canali aggiornati avviene tramite il ServerMode o ServerOp:
Server1.MyServer.org setta i mode: +ooo Nick1 Nick2 Nick3
I ServerOps sono famosi nel loro utilizzo per scopi di danneggiamento o Takeover. Quando avviene un take, questo è denominato infatti SQuit Collision Channel Takeover.
Quando il server relinka dopo uno split, non è necessario che sia lo stesso a cui era connesso prima dello split. Riguardando ancora l'esempio, ora potrebbero essere linkati così:
B ---- C ---- D ---- A
Ora tutto è cambiato, perchè le persone che erano laggate rispetto a te ora non lo sono più e viceversa. Questa è la natura del LAG: qualche volta è noioso, ma non c'è da preoccuparsi.
4. Desynch & Resynch
Il desynch è uno dei più grossi problemi della rete, durante i periodi di NetSplit/Merge/Healing. Molto spesso, però, si lascia che sia il caso a risolvere questo problema, cosa che, col tempo, potrebbe essere generare noie inutili. Il Resyncing è semplice, di per sè, se comprendi cosa lo ha generato. Il Desync è una condizione in cui i servers della rete hanno delle informazioni che, in fase di sincronizzazione, per ristabilire lo status globale della rete, vanno in conflitto. Una situazione di Desynch è visibile, ad esempio, quando, entrando presso un canale globale, da un server, non è possibile inviare messaggi, ottenendo un messaggio d'errore uguale a quando il canale è impostato per la sola discussione moderata da un operatore di canale, oppure, quando si notano degli utenti con status Op, quando, altrove, non l'hanno e viceversa. Nel particolar caso dei ChanOp desincronizzati, se un utente Op, condivide questa caratteristica con un altro utente, anche quest'ultimo sarà desincronizzato con la rete. Se, invece, bannerà un utente dal canale, i servers avranno delle liste degli utenti di canale, totalmente scombinate. Per evitare che la desincronizzazione si diffonda, causando sempre più problemi (un canale non sincronizzato, non è moderabile, pertanto, la chat può essere compromessa, sia perchè i messaggi non vengono diffusi agli altri utenti, sia perchè potrebbe entrare un utente e causare flood ed harrasing, senza essere allontanato). Trovare il luogo ov'è avvenuto il desynch è utile per questi motivi. Un sistema molto semplice è quello, prima di tutto, nel vedere se, entrando in un canale, l'Op che ti viene fornito durante la creazione, ha sul serio il suo "potere". Si tenti, ad esempio, di settare il topic. Se si riceve un messaggio d'errore, da parte del server, specificando che tale operazione non è possibile, già si può capire che il server è desynch (questo non funziona molte volte). Se si è in un canale con utenti e si sospetta un desynch, s'incolli l'output del /names in canale e si chieda a chi è residente, se il /names a lui visualizzato contiene gli stessi dati. E' possibile adottare questo metodo anche collegando + cloni su servers diversi, facendoli entrare nello stesso canale. Una volta individuati su quali servers sono gli utenti che non dovrebbero avere certe determinate modalità o non dovrebbero essere in canale, si provveda, per quanto possibile, all'impostare manualmente la configurazione del canale.
|
|
