Ajuda IRC

Internet Relay Chat (IRC) é um protocolo de comunicação utilizado na Internet. Ele é utilizado basicamente como bate-papo (chat) e troca de arquivos, permitindo a conversa em grupo ou privada. Foi documentado formalmente pela primeira vez em 1993, com a RFC 1459.

 

Veja nossos tópicos de ajuda clique aqui

 

Abaixo um poco da história e evolução do IRC

Nascimento

O IRC foi escrito pelo programador finlandês Jarkko Oikarinen em 1988 na Universidade de Oulu na Finlândia. O trabalho começou em agosto daquele ano e o objetivo era criar um sistema de teletexto comunitário que rodasse em TCP/IP com recursos avançados como conversa pública massiva entre milhares de usuários separados por canais e com mensagens privadas entre eles. Eles diziam que o IRC seria um complemento e até um avanço da Usenet pois permitiria encontro maciço de grupos em tempo real. Os amigos de Jarkko, Markku Järvinen e Vijay Subramaniam ajudaram na concepção dos clientes e servidores.

As primeiras redes surgiram na Finlândia e rodavam em servidores de Universidades. Logo se espalharam por instituições em toda Escandinávia. Em 1989 já existiam mais de 40 servidores espalhados por todo o mundo. Em 1993 durante a Guerra da Golfo o IRC foi usado para noticiar eventos em tempo real entre usuários que tinham acesso à Internet em Universidades do Oriente Médio.

 

Expansão

Com a abertura comercial da Internet ao grande público em 1993, ao longo dos anos 1990 grandes redes de IRC começaram a surgir como EFnet e Undernet possibilitando que qualquer pessoa assinante de um provedor de acesso pudesse se conectar a essas redes. Muitas das novas redes que surgiam eram separações de grupos de usuários que não concordavam com regras dos servidores. Foi assim que em 1995 as primeiras redes de IRC no Brasil nasceram sendo fundadas por usuários brasileiros que já se conectavam às redes estrangeiras.

 

Popularidade

O IRC se tornou o principal meio de bate-papo na Internet no final dos anos 1990 e início dos anos 2000, concentrando milhares de usuários todos os dias. Tentaram recriar o mesmo sistema na Web e em Java, mas o IRC era insuperável pela capacidade de gerenciamento e o modo como os usuários interagiam. Por exemplo, os OPs (Operadores) cuidavam do bom andamento do canal expulsando usuários mal educados e que provacassem confusão.

O mIRC, cliente de IRC para Windows foi com certeza o mais popular e largamente utilizado, era fácil de usar e apresentava uma interface clara e agradável aos olhos dos iniciantes. Também possuia uma linguagem de scripts que permitiu que muitos programadores criassem variações do mIRC traduzidas para o português e com muitos recursos que facilitavam o seu uso. Surgiram também muitos jogos em canais, de enquetes e até Xadrez por computador foi portado para o sistema que lidava apenas com texto ditando as notações do tabuleiro. O ápice do IRC no Brasil foi em 2001 onde ambas BrasIRC e BrasNET registraram recordes de usuários conectados.

 

Decadência

A decadência do IRC começou por volta de 2003 quando os mensageiros instantâneos se tornavam ainda mais populares, permitindo bate-papo com amigos sem ser importunado por desconhecidos e uma série de recursos que o IRC não permitia. O MSN Messenger teve um grande impacto nesse período pois permitia conversas em vídeo por webcams e voz, além de integração com e-mail do Hotmail, jogos do portal MSN e salas de chat comunitárias que eram tão eficientes como o IRC em controle de usuários. Apesar de o bate-papo comunitário nos mensageiros não ter prosperado, eles permitiam conexões com sites de namoro aumentando a eficiência em conhecer gente nova como acontecia no IRC.

O lançamento da rede social Orkut foi o golpe final para as redes de IRC brasileiras. Os usuários do Orkut se reúnem em comunidades que possuem fóruns e neles organizam sistemas de chat nos tópicos. Com o auxílio do MSN, o Orkut sepultou de vez o IRC no Brasil e desde 2004 é restrito a encontro de saudosistas e subculturas.

No exterior, o IRC teve uma queda mais branda: apesar de perder muitos usuários, ainda mantinha uma boa taxa de conexões. O sistema de fóruns baseados em PHP foi também um dos grandes responsáveis pela queda do IRC por lá. Os usuários passaram a se organizar nesses fóruns e mantinham conversas em tempo real no MSN.

 

Tempos atuais

O IRC ainda existe, com centenas de redes ativas para quem queira usufruir de seus recursos. O número de freqüentadores, porém, é deveras baixo para bate-papo. O IRC hoje é usado para fins mais específicos. Existem canais que realizam troca de arquivos entre usuários semelhantes aos que os peer to peer fazem. Também é grande a procura por canais para obter senhas de sites pornográficos. Além disso o IRC é bastante utilizado por distribuições linux que utilizam o IRC para dar suporte aos usuarios, como a Ubuntu.

O IRC é também, atualmente, um meio usado para execução de Botnets em que se conectam usuários infectados por virus e trojans. Esses usuários hospedeiros ignoram tais conexões para servidores e canais, e, a partir de lá, lançam ataques de SPAM a milhares de computadores pelo mundo. Isso permite que o hacker propagador, nesse caso, permaneça anônimo e use pessoas infectadas para fazer ataques usando seus respectivos IPs. O sistema deve ser bem estruturado para que não se perca o controle do usuário-hospedeiro e que seja de difícil reconhecimento por parte dos provedores, já que utilizam portas e protocolos de IRC.

 

Informação técnica

O IRC é um protocolo aberto que usa o TCP e opcionalmente SSL. Um servidor de IRC pode ser ligado a outros servidores de forma a expandir a rede de IRC. Para que os utilizadores tenham acesso às redes de IRC é necessário ligar a um dos servidores utilizando um cliente apropriado. Existem muitas implementações do IRC em clientes e servidores sendo que a maioria dos servidores de IRC não requerem que o utilizador se identifique, no entanto o utilizador terá de escolher um apelido antes de efectuar a ligação.

O IRC é um protocolo de texto simples, o que quer dizer que é possível (embora algo inconveniente) usar o IRC através de um cliente como o netcat ou o telnet. Embora o protocolo use uma versão ligeiramente alterada do ASCII como codificação de caracteres, não tem suporte para quaisquer caracteres não ASCII sendo que isso leva ao uso de outros tipos de codificação de caracteres incompatíveis (como o ISO 8859-1 e UTF-8).

Devido ao uso de ligações em forma de árvore entre os servidores de IRC não existe redundância e como tal uma falha num servidor ou ligação pode causar o que é chamado de netsplit.

Para conseguir utilizar este protocolo, é necessário, primeiro, ter um cliente de IRC, que é um programa que se comunica com um servidor de uma rede de IRC. No sistema operativo Windows, o mais famoso é o mIRC.

Os servidores não são simples servidores, também podem ser unidos numa rede. Grandes redes podem juntar, num horário de pico, dezenas de milhares de pessoas. A especificação do protocolo é disponibilizada pelo RFC 2812.

 

Evolução

Todos os protocolos cliente-servidor de IRC em uso descendem do protocolo implementado na versão 2.8 do IRC2server, documentado na RFC 1459. Desde que esta foi publicada, as novas funcionalidades do IRC 2.10 levaram à publicação de outras propostas de protocolos; RFC 2810, RFC 2811, RFC 2812 e RFC 2813, no entanto estas alterações não foram largamente adaptadas pelas outras implementações. O protocolo IRC foi estendido pela Microsoft em 1998 através do seu protocolo IRCX que resolve muitos dos problemas que as redes de IRC têm, juntamente com algumas funcionalidades que a maioria dos utilizadores sentiu "estarem à frente do tempo". Embora muitas especificações do protocolo IRC tenham sido publicadas, não existe especificação oficial como o protocolo permanece dinâmico. Virtualmente nenhum cliente e muitos poucos servidores se restringem apenas às RFCs mencionadas como referência.

Enquanto os protocolos cliente-servidor são pelo menos similarmente funcionais, os protocolos servidor-servidor variam largamente (TS5, P10, e ND/CD são vários dos protocolos mais usados), tornando a ligação entre dois servidores com implementações diferentes muito difícil. Alguns servidores "ponte" existem para permitirem a ligação, de por exemplo, servidores 2.10 a servidores TS5, mas estes são normalmente acompanhados de restrições no que toca ao uso de partes de cada protocolo, e não estão largamente adaptados.

Nas suas primeiras versões, o IRC não tinha muitas das funcionalidades existentes hoje em dia, como canais com nomes e operadores de canais. Os canais eram numerados – canal 4 e 57, por exemplo – e o tópico do canal descrevia o tipo de conversação que tomava lugar no canal. Uma consequência deste tipo de numeração é que ao entrar no canal 0 faz com que o cliente deixe todos os canais em que está no momento: sendo "CHANNEL 0" o comando original para deixar o canal corrente.

A primeira grande alteração ao IRC ocorreu na versão 2.5 com a adição de nomes aos canais – "+canal" sendo que mais tarde viria a ser substituído por "#canal" na versão 2.7, tendo os canais numéricos sido completamente removidos e implementados os bans de canal (modo +b). O irc2.8 adicionou a forma "&canal" sendo que esta representa todos os canais que existem no servidor corrente, ao invés de serem globais a toda a rede; e "!canal" representando os canais que teoricamente estariam a salvo de sofrer as consequências da exploração indevida pelos utilizadores através dos netsplits, sendo esta a versão a partir da qual quase todas as implementações derivam.

Edições baseadas na versão 2.8 incluem:

  • 2.8.1+CS, desenvolvido por Comstud
  • 2.8+th, conjunto de correcções de Taner, que mais tarde viria a tornar-se
  • 2.8/hybrid, originalmente desenvolvido por Jon Lusky (Rodder) e Diana Bruce (Dianora), tendo mais tarde incorporado uma extensa equipa de desenvolvimento.
  • 2.9, 2.10, 2.11, … continuam o desenvolvimento da base de código original, principalmente para o uso na rede IRCnet. Esta linha de desenvolvimento produziu 4 especificações de IRC (RFC) editadas após a RFC 1459, que documentam este protocolo de servidor exclusivamente.

 

Canais e modos

A forma mais típica de comunicação numa sessão de IRC é a conversação num canal onde os utilizadores podem juntar-se e enviar mensagens as quais são depois reenviadas para todos os outros utilizadores do mesmo canal. Os canais que estão disponíveis através de toda a rede de IRC são precedidos de um ‘#’, enquanto os canais locais de um servidor são precedidos por ‘&’. Outros tipos de canais (não standard) incluem canais ‘+’ – ‘sem modos’, canais sem operadores, e canais ‘!’, uma forma de canal com marcação temporal em redes sem marca temporal.

Ambos utilizadores e canais podem ter modos que são no fundo um tipo de atributos ou opções. Os modos são abreviados por letras para que seja possível agrupa-los de forma concisa. Um exemplo de um modo de utilizador é o ‘i’, que quer dizer invisível. (Não é possível saber se um dado utilizador invisível está num canal, amenos que se junte ao canal ou use o comando whois no seu apelido). Um exemplo simples de um modo de canal é ‘m’ (moderado), o qual específica que apenas utilizadores com ‘voice’ e operadores de canal podem falar no canal. Existem cinco tipos de modos de canais, quatro dos quais aceitam um argumento, tipo A que aceita um argumento para adicionar/remover valores de uma lista (tal como ‘b’); tipo B que aceita um argumento para alterar o valor entre ‘ligado’ e ‘desligado’ (tal como ‘k’); tipo C que aceita um argumento apenas quando o modo está ‘ligado’ (tal como ‘l’); tipo D que não aceita argumentos e é simplesmente uma opção booleana (tal como ‘m’, ‘n’, e ‘t’); e tipo E (normalmente chamado modo ‘class’ ou ‘prefixo’) que dá ou tira um privilégio de um utilizador num canal (tal como ‘o’).

Os modos do tipo E (classes de canais) especificam quais os utilizadores que têm privilégios num canal, e qual o nível dos privilégios que têm. Originalmente apenas os modos de operadores de canal (modo ‘o’) e ‘voice’ (modo ‘v’) existiam. Os privilégios dos operadores de canal (normalmente abreviados por chanop ou simplesmente ‘op’) permitem expulsar utilizadores (kick), colocar modos, e alterar o tópico do canal se este estiver ‘+t’. Os privilégios dos utilizadores com ‘voice’ permitem ao utilizador falar no canal se este estiver moderado (modo ‘m’). Outros modos adicionais destas classes são: ‘fundador’ (modo ‘q’) criado pela Microsoft na sua implementação IRCX (e mais tarde usado pelo UnrealIrcd); ‘half-operator’ (também referido como ‘halfop’, modo ‘h’) que é similar a um operador de canal, excepto que os utilizadores com este privilégio não podem colocar certos modos e apenas podem expulsar utilizadores normais; ‘protegido’ (modo ‘a’); ‘administrator’ (modo ‘a’ ou ‘u’); e muitos mais.

Cada classe de canal tem associado um prefixo que é mostrado ao lado do apelido de cada utilizador que estiver associado com o canal. Os prefixos mais comuns são ‘@’ para operadores de canal, ‘+’ para ‘voices’, ‘%’ para ‘half-op’, ‘.’ ou ‘~’ para os fundadores, ‘&’ para utilizadores protegidos, e ‘!’ ou ‘*’ para administrador.

A maioria das redes de IRC tem uma série de modos extra não especificados em qualquer dos documentos RFC. No entanto existe uma maneira elegante para os clientes se adaptarem, uma lista de todos os modos de utilizadores e canais é enviada para os clientes na resposta RPL_MYINFO quando o utilizador efectua o logon. Em adição, a lista de modos de canal (e o tipo de argumentos que estes aceitam), e os prefixos para as classes de modo são especificados na resposta do protocolo (RPL_PROTOCTL ou 005) enviado por parte da maioria dos servidores de IRC quando um cliente liga. Esta mensagem é usada para informar os clientes quais são as funcionalidades que o servidor aceita e quais são os limites (por exemplo, o número máximo de utilizadores que pode ter na lista de notificação, ou o tamanho máximo do apelido do utilizador). Existem também utilizadores cujos privilégios se estendem para servidores inteiros ou mesmo redes de servidores; chamado de operador de IRC (também muitas vezes referidos como IRCop). Em algumas implementações do IRC, aos operadores de IRC é também garantido o privilégio de operador de canal em todos os canais embora muitas pessoas acreditem que a administração dos canais e a administração da rede deva ser mantida separada e que o estatuto de operador de IRC não deve conferir o direito em interferir na operação de um canal particular.

Devido às ligações ao IRC não serem encriptadas e tipicamente estarem activas durante um longo período, são um alvo atractivo para actividades maliciosas. Devido a este facto, uma política de segurança eficaz é necessária para que uma rede de IRC não seja susceptível a ataques como os tradicionais takeovers. As redes de IRC também podem colocar k-line ou g-line a utilizadores ou redes que tendam a ter efeitos negativos para com as mesmas.

O IRC serviu como um laboratório para muitos tipos de ataques na Internet, como usar mensagens ICMP do tipo unreachable para desligar ligações TCP ao IRC (o chamado "nuke") para chatear utilizadores ou facilitar takeovers.

 

Prevenção de abuso: marca temporal x nick/channel delay

Uma das dificuldades técnicas do IRC mais contenciosa, e que ainda hoje persiste, é o mérito dos protocolos "Nick/Channel Delay" x marca temporal. Ambos os métodos existem para resolver o problema dos ataques de negação de serviço (Denial of Service), mas têm soluções muito diferentes.

O problema com o protocolo original do IRC como implementado era que quando dois servidores se separavam e voltavam a ligar-se, os dois lados da rede simplesmente juntavam os canais. Se um utilizador entrasse num servidor separado da rede, num canal que existisse em ambos os lados da rede e estivesse vazio, ganhasse estatuto de operador de canal, este tornar-se-ia operador de canal dos canais "combinados" da junção da rede; se um utilizador utilizasse um apelido que existisse no outro lado da rede, o servidor desligaria ambos quando ocorresse a junção.

Isto era muitas vezes usado para fazer "mass-ban/kick" sobre todos os utilizadores de um canal, criando assim canais sem operadores de canal: aonde não existiam operadores disponíveis para tomar conta do abuso. Além de criar problemas dentro do IRC, isto encorajava as pessoas a efectuarem ataques de negação de serviço contra servidores de IRC para causar netsplits, os quais seriam então abusados.

Protocolo Nick/Channel Delay

A solução do protocolo de espera de nick/canal (conhecida do inglês como "Nick/Channel delay" e abreviada ND/CD) para este problema era simples. Após um utilizador ter saído da rede e o apelido tornando-se disponível, ou um canal ter deixado de existir porque todos os seus utilizadores o tinham deixado (como regularmente acontece num netsplit), o servidor não permitiria nenhum utilizador usar esse apelido ou entrar naquele canal, respectivamente, até que um certo período de tempo tivesse ocorrido (delay). A ideia por trás disto era que mesmo que um netsplit ocorresse, seria inútil para um utilizador mal intencionado porque não poderiam mudar o apelido ou ganhar privilégios de operador de canal, não havendo assim colisões de apelido caso uma junção de um canal ocorresse. Até certo ponto, isto torna-se inconveniente para utilizadores legítimos que podem ser obrigados a usar, durante um breve tempo, um nome diferente depois de voltar ao canal.

Protocolo de marca temporal

A alternativa, a marca temporal ou protocolo TS, tomou uma aproximação diferente. A todos os apelido e canais numa rede era atribuído uma marca temporal – a data e tempo da sua criação. Quando um netsplit ocorria, dois utilizadores nos dois lados da rede eram livres de usar o mesmo apelido e canal, mas quando os dois lados eram juntos, apenas um poderia sobreviver. No caso dos apelidos, o utilizador mais recente, de acordo com a sua marca de tempo, seria desligado; quando um canal colidisse, os membros do canal eram juntos, mas os operadores de canais ficavam a perder sendo-lhes retirado o estatuto de operador.

O protocolo TS é muito mais complicado que o ND/CD, tanto em desenho como em implementação, e apesar de terem sido várias as revisões, algumas implementações ainda têm problemas de dessincronização (referido como "desyncs", aonde todos os servidores na mesma rede discordam à cerca do estado corrente da rede), permitindo muita leniedade no que era permitido pelo lado que perdia. No protocolo TS original, por exemplo, não existia protecção contra utilizadores que colocassem bans ou outros modos no canal no lado afectado pelo netsplit, que depois viriam a ser juntos quando os servidores se ligassem novamente, mesmo sabendo que os utilizadores que tivessem colocado esses modos não estivessem mais com estatuto de operador. Alguns servidores de IRC modernos que implementam o TS também incorporam alguma forma do ND e ou CD em adição a marcação temporal numa tentativa de restringir os abusos.

 

 

Comentários da página

Explicação

Gabriel 22-01-2015
Muito bem explicado , show!
Itens: 1 - 1 de 1

Novo comentário