IRC/Usługi DCC i CTCP

Zarówno DCC (direct client to client) jak i CTCP (client to client protocol) są metodami łączenia się z sobą dwóch klientów IRC z pominięciem serwera. Zadanie serwera w tym przypadku sprowadza się do udzielenia obu klientom informacji umożliwiającej zrealizowanie bezpośredniego połączenia, po czym serwer dalej nie uczestniczy w przekazywaniu danych. DCC jest formalnie jedną z dopuszczalnych, specyficznych form CTCP, rodzajem nie do końca określonego "podprotokołu".

CTCP

Wysyłając komendę:

/CTCP nick dowolny tekst

powodujemy, że "dowolny tekst" jest bezpośrednio, bez żadnej interpretacji i zmian, wysyłany do klienta danego "nicka" z jednoczesną informacją przez kogo i kiedy został wysłany. Reakcja klienta, do którego wysłaliśmy tę komendę zależy od jego konfiguracji. Standardowo większość klientów IRC reaguje na następujące teksty wysyłane do nich komendą CTCP:

• PING - odpowiedzią jest różnica czasu od wysłania przez nas komendy do jej otrzymania - umożliwia więc oszacowanie lagu między dwoma klientami z uwzględnieniem czasu przesyłania informacji do i od serwera
• VERSION - odpowiedzią jest nazwa, wersja i czasem nazwa systemu operacyjnego klienta
• TIME - czas systemowy klienta
• USERINFO - ogólna informacja na temat klienta
• FINGER - zwraca pełną nazwę użytkownika klienta i jego idle time (czas od ostatniego odezwania się na IRC-u)
• SOURCE - adres strony WWW lub publicznego FTP, z którego można pobrać klienta danego użytkownika
• CLIENTINFO - nazwa używanego klienta
• SEND - zestawia i uruchamia szyfrowany transfer danych
• DCC - rozpoczyna transmisję DCC lub informuje o możliwości, lub jej braku nawiązania łączności DCC.

Oprócz tych standardowych komend, można swojego klienta "nauczyć" reagować na dowolne teksty wysyłane przez CTCP. Umożliwia to pisanie skryptów, które realizują rozmaite funkcje pod warunkiem, że zna się "sekretne hasła" wysyłane przez CTCP, na które one reagują jak na rodzaj komend. Niektóre rodzaje botów są standardowo sterowane poprzez komendy wysyłane przez CTCP.

Większość bardziej zaawansowanych klientów IRC umożliwia też spreparowania innych niż standardowe odpowiedzi na standardowe zapytania. Czasami jest to robione dla żartu, a czasem dla celowego wprowadzenia w błąd, stąd odpowiedzi na te zapytania należy zawsze traktować z dużą ostrożnością. Np: niektórzy konfigurują swojego klienta tak aby odpowiadał na /CTCP PING "pingnij się w głowę", albo na /CTCP TIME "u mnie jest zawsze taka jak trzeba". Inni z kolei ukrywają np. swoją wersję i rodzaj klienta, po to aby zyskać przewagę zaskoczenia w "wojnach ircowych". Typowy przykład to skonfigurowanie BitchX-a tak aby "udawał", że jest mIRC-em. mIRC jest klientem, z którym stosunkowo łatwo wygrać wojnę, natomiast dobrze skonfigurowany BitchX jest "bardzo groźną bronią".

Można też tak skonfigurować swojego klienta, aby całkowicie ignorował zapytania CTCP.

DCC

DCC jest podzbiorem usług, które są inicjowane przez komendy wysyłane protokołem CTCP. W ich przypadku CTCP służy jednak tylko do zestawienia łącza między klientami. Po zestawieniu łącza transmisja i sterowanie odbywa się już całkowicie bez pośrednictwa serwera IRC, aż do czasu zerwania połączenia. Istotą DCC jest bezpośredni transfer plików albo tekstów między klientami. Protokół zestawienia łącza DCC wymaga posiadania stałego numeru IP z tzw. zwrotnym DNS. Stąd usług DCC nie da się realizować, gdy pracuje się spod dynamicznych lub niezarejestrowanych numerów IP.

Podstawowy mechanizm DCC został stworzony w ramach prac nad klientem ircII i nie planowano go jako usługi, która by miała być stosowana powszechnie i stanowić część ogólnej specyfikacji protokołu IRC, jednak z czasem stał się on standardem, który został adaptowany do większość bardziej rozbudowanych klientów IRC.

Usługi DCC uruchamia się za pomocą komendy:

/DCC typ argument adres port (1)

gdzie - typ to rodzaj połączenia, argument - informacja o tym co ma być przesyłane (np: nazwa pliku), adres - adres IP użytkownika, z którym chcemy się połączyć, port - numer portu, z którym chcemy się połączyć. Większosć klientów IRC pozwala uprościć postać tej komendy do:

/DCC typ argument nick (2)

przy czym faktycznie wysyłana jest komenda (1) - tyle, że nasz klient pobiera automatycznie adres klienta z serwera IRC, zaś za port podstawia standardowy, najczęściej stosowany port danego typu połączenia.

Wysyłanie tej komendy uruchamia u docelowego użytkownika pojawienie się zapytania a akceptację. Połączenie akceptuje się odpowiednią, analogiczną komendą, tyle że skierowaną na adres klienta proszącego o zgodę na połączenie. Odmowa realizacji prośby o połączenie polega po prostu na jej zignorowaniu. Po akceptacji, o ile nie ma żadnych przeszkód technicznych, połączenie jest zestawiane i realizowane. Wiele klientów pracujących w środowisku graficznym upraszcza życie ich użytkownikom, wyświetlając okno dialogowe z pytaniem o zrealizowanie połączenia i wysyła odpowiednią komendę zwrotną po kliknięciu na "OK" w tym oknie. Można się zatem komendą zwrotną w ogóle nie kłopotać.

W podstawowym standardzie DCC dopuszczalne są następujące typy połączeń:

• CHAT - realizowane jest sekwencyjne przesyłanie od klienta do klienta kolejnych linii tekstu - mówiąc prościej umożliwia to po prostu rozmowę prowadzoną z pominięciem serwera IRC - aczkolwiek może też być używane do innych celów
• SEND - realizowane jest ciągłe, strumieniowe przesyłanie danych od klienta do klienta - co w praktyce umożliwia przesyłanie plików.

DCC CHAT w praktyce

W najprostszym wariancie klient posługujący się nickiem "kazio" wysyła do nicka "juzek" komendę:

/DCC CHAT juzek

na którą juzek odpowiada:

/DCC CHAT kazio

po czym juzio i kazio mogą między sobą wysyłać linie tekstu zakończone "enterem" mniej więcej tak, jak w zwykłej rozmowie IRC, tyle, że w tym przypadku komunikaty nie przechodzą przez serwer IRC. Umożliwia to zatem nieco bezpieczniejszą rozmowę, która nie jest też zależna od lagów i splitów serwera.

Warto zwrócić uwagę, że stosując bardziej rozbudowaną wersję tej komendy:

/DCC CHAT adres port

można się połączyć z klientem, który nie jest zalogowany do tej samej sieci IRC co my. Ściśle biorąc klient ten może w ogóle nie być zalogowany do żadnego serwera IRC - wystarczy, że jest włączony i akceptuje komendy DCC.

DCC CHAT oprócz prowadzenia zwykłych rozmów, jest też często stosowany przez skrypty i boty do zdalnego sterowania nimi, co jest dokładniej opisane w rozdziale "Skrypty i boty".

DCC SEND w praktyce

DCC SEND służy generalnie do wysyłania plików, choć może być również używane do wysyłania wszelkich danych strumieniowych (np: strumieni dźwięku i obrazu). Załóżmy, że "Kazio" chce wysłać plik "moje_foto.jpg" to "Juzka". Kazio rozpoczyna od wysłania do Juzka komendy:

/DCC SEND moje_foto.jpg Juzek

Juzek, po otrzymaniu pytania o zgodę na przyjęcie tego połączenia odpowiada:

/DCC ACCEPT moje_foto.jpg

Niektóre wersje klientów, niezgodnie z pierwotnym schematem DCC, zamiast "ACCEPT" oczekują komendy "GET", gdy zatem ACCEPT nie zadziała Juzek może spróbować:

/DCC GET moje_foto.jpg

Jeśli transfer danych zostanie z jakiegoś powodu przerwany, Kazio musi go ponownie uruchomić komendą:

/DCC SEND moje_foto.jpg Juzek

zaś Juzio może wtedy odpowiedzieć komendą:

/DCC RESUME moje_foto.jpg

dzięki czemu transfer pliku zacznie się od miejsca, w którym był poprzednio przerwany.

Pełna wersja komend "SEND", "ACCEPT", "GET" i "RESUME" (z podaniem adresu i portu klienta) umożliwia, tak samo jak w przypadku "CHAT" łączenie się z klientami, które aktualnie nie są zalogowane do naszej sieci IRC, lub w ogóle żadnej, a tylko są włączone.

Uwaga techniczna

plik moje_foto.jpg musi być przed rozpoczęciem wysyłania umieszczony w katalogu, w którym standardowo będzie go oczekiwał klient. Katalog plików "do wysyłki" trzeba zwykle zdefiniować w ramach konfiguracji klienta.

Przesyłanie plików w klientach działających w środowisku graficznym

W przypadku, gdy Juzek i Kazio dysponują dobrymi klientami pracującymi w środowisku graficznym, wysyłanie i przyjmowanie plików odbywać się będzie zapewne za pomocą okien dialogowych, które uruchamia się wybierając odpowiednią pozycję z menu programu. Wówczas oboje mogą nie mieć świadomości, że ich klienty wysyłają komendy DCC - z całą pewnością to się jednak dzieje, tyle że w sposób dla nich niewidoczny. Poznanie podstawowej składni komend umożliwia jednak bardziej świadome posługiwanie się DCC i pozwala lepiej zrozumieć co się właściwie w czasie wymiany plików dzieje.

Szyfrowane DCC

Niektóre klienty IRC umożliwiają przesyłanie tekstów i plików za pomocą szyfrowanych protokołów, takich jak np SSL. Obsługa szyfrowych połączeń jest jednak różna, w różnych klientach, stąd zwykle tego rodzaju komunikacja jest możliwa tylko w przypadku, gdy obie strony używają takich samych lub przynajmniej kompatybilnych klientów. Czasami problem niekompatybilności daje się rozwiązać przez wybranie jednej, umówionej wcześniej metody szyfrowania i zainstalowanie odpowiedniego skryptu lub wtyczki rozszerzającej możliwości naszego klienta.

Jednym z rozwiązań, zaimplementowanym w m.in. programie kVirc oraz jako wtyczka mIRC jest poszerzenie protokołu DCC o komendy, które nazywają się tak samo jak oryginalne, z dodaną literą "S" na początku, jest to zatem odpowiednio: SCHAT, SSEND, SACCEPT itd.

Innym rozwiązaniem jest stosowanie normalnych komend z dodatkowym mechanizmem uzgadniania protokołu szyfrowania już po nawiązaniu połączenia. Po nawiązaniu połączenia DCC CHAT, klienty wymieniają automatycznie komunikaty informujące się nawzajem o przejściu na szyfrowany protokół, po czym dopiero następuje właściwa transmisja danych. W praktyce, aby móc zacząć stosować szyfrowane DCC, należy się zapoznać z instrukcją jego użycia dostarczoną przez producenta swojego klienta IRC.

Zagadnieniem ustandaryzowania procedur szyfrowych w ramach protokołu DCC zajmuje się projekt DCC2 (http://www.dcc2.org/), który pracuje nad stworzeniem nowej wersji DCC.

Pasywne i aktywne DCC

Przy normalnym połączeniu DCC strona zgłaszająca chęć uzyskania połączenie komendą "SEND" lub "CHAT" staje się jej stroną aktywną, biorącą na siebie zestawienie łącza, czyli spełniającą dla drugiej strony funkcję serwera. Z tego powodu właśnie, nie posiadając stałego adresu IP nie można z tej usługi skorzystać. Ten sam problem stwarza korzystanie z adresu NAT, czy zapory sieciowej nie ujawaniającej rzeczywistych numerów IP znajdujących się za nią komputerów.

Aby choć częściowo obejść ten problem, niektóre klienty IRC posiadają mechanizmy pozwalające zestawić łącze w trybie pasywnym. Działa to zwykle tak, że nasz klient wysyła komendę CTCP, która po drugiej stronie uruchamia procedurę nawiązania połączenia DCC z nami, dzięki czemu, mimo że to my inicjujemy połączenie, stajemy się jego bierną stroną. Oczywiście ten system może działać tylko wtedy, kiedy druga strona ma stały numer IP.

Niestety, podobnie jak to jest z szyfrowanym DCC różne programy do IRC mają róże mechanizmy pasywnego DCC i mechanizm ten nie jest zestandaryzowany. Do najczęściej spotykanych należą:

System 100-121

jest on stosowany w mIRC-u i paru innych klientach i jest chyba najbardziej popularny - polega on na wysyłaniu komendy /CTCP 100 nick dla połączenia CHAT i /CTCP 120 nick dla połączenia SEND - wadą tego rozwiązania jest konieczność wcześniejszego uzgodnienia adresu i numeru portu dla połączenia strony pasywnej.

System RDCC

w systemie tym inicjujący wysyła komendę /RDCC funkcja gdzie "funkcja" to "c" dla "CHAT" i "s" dla "SEND", a przyjmujący odpowiada komendą RDCC 0 numer_IP numer_portu - dzięki czemu nasz klient dostaje informację na jakim porcie i spod jakiego numeru IP ma oczekiwać na połączenie.

Serwery plików

Istnieją dwa rozszerzenia DCC, które umożliwiają przekształcenie naszego klienta w rodzaj serwera plików działającego trochę podobnie jak serwery FTP. Po uruchomieniu tej usługi nasz klient IRC będzie automatycznie wysyłał listy udostępnionych przez nas plików i umożliwiał ich ściąganie - w zależności od konfiguracji wszystkim, lub tylko wybranym.

Rozszerzenie DCC o nazwie fSERVe zostało pierwotnie zaadaptowanie w programie mIRC - dla innych programów jest ono jednak dostępne w postaci skryptu lub wtyczki. Obsługuje ono do 5 połączeń na raz i działa na zasadzie kombinacji DCC CHAT i DCC SEND. Przez DCC CHAT wysyłane są listy plików i komendy uruchamiające transfer, zaś sam transfer plików odbywa się przez tradycyjny mechanizm DCC, z fSERVe'em jako stroną czynną. W zasadzie każdy właściciel mIRCA, posiadający stały numer IP może w dość prosty sposób (poprzez okno dialogowe) uruchomić tę usługę. Słabość mechanizmów zabezpieczających mIRC-a powoduje jednak, że jest to potencjalnie ryzykowne przedsięwzięcie.

Drugim tego rodzaju rozszerzeniem jest skrypt XDCC pierwotnie napisany w 1994 r. do programu ircII. XDCC zostało dołączone do BitchX-a i paru innych klientów obsługujących język skryptowy ircII. XDCC oferuje znacznie więcej możliwości niż fSERVe - może być skonfigurowane tak, aby komendy wyświetlające listy plików i uruchamiające transfer mogły być wysyłane w formacie "/CTCP komenda", "/msg komenda" lub przez DCC CHAT. XDCC obsługuje też system katalogowy plików, po którym można "wędrować" przy pomocy komend znanych z DOS-a (DIR, CD itp.) XDCC jest bardzo popularną metodą rozpowszechniania tzw. warezu - czyli bibliotek legalnie i nielegalnie rozprowadzanych programów i plików multimedialnych.

CTCP/DCC a bezpieczeństwo

Ze względu na to, że usługi CTCP i DCC odbywają się bezpośrednio między dwoma klientami rodzi to szereg potencjalnych niebezpieczeństw, co szczególnie dotyczy DCC.

Pomijając już sprawę, że przez DCC SEND można łatwo komuś posłać wirusa lub konia trojańskiego, sam mechanizm połączenia może być dość łatwo wykorzystany do włamania się do systemu operacyjnego komputera z zainstalowanym klientem. Szczególnie narażeni są na tego rodzaju ataki użytkownicy klientów posiadających słabe zabezpieczenia, zwłaszcza mIRC-a i Chatzilii.

Inny rodzaj ryzyka, dotyczący zarówno CTCP jak i DCC to możliwość kierowania ataku na klienta, który popularnie nazywany jest CTCP bomb lub DCC bomb. Atak ten polega na wysyłaniu serii komunikatów CTCP lub DCC jeden po drugim, w krótkim czasie, co powoduje oślepienie atakowanego. Przy standardowej konfiguracji klientów stosowanych najczęściej przez osoby początkujące, klient reaguje automatycznie na każda przysyłana komendę CTCP lub DCC. Konieczność wysłania odpowiedzi na kilkaset komend w przeciągu np. 10 sekund powoduje, że klient się zawiesza lub zrywa łącze z serwerem. Wiele skryptów "bojowych" dostępnych w sieci daje możliwość łatwego wysyłania bomb DCC i CTCP. Właściciel takiego skryptu zazwyczaj musi wystukać tylko komendę np. "/BOMB DCC CHAT nick" aby wypuścić ją do określonego użytkownika.

Szczególnie skuteczny jest atak w postaci wysyłania specjalnie spreparowanej serii plików przez DCC SEND do klientów pracujących w środowisku graficznym. Jeśli klient jest ustawiony w ten sposób, że automatycznie akceptuje wszystkie nadsyłane pliki, realizacja klikudziesięciu transferów dużych plików na raz skutecznie blokuje łącze, o ile wcześniej nie spowoduje to zawieszenie się komputera. Gdy klient jest ustawiony w ten sposób, że wyświetla okno dialogowe z pytaniem o akceptację przyjęcia plików - wyświetlenie kilkudziesięciu takich okien na raz skutecznie zawiesza klienta lub nawet cały komputer ofiary.

Aby się zabezpieczyć przed niebezpieczeństwami związanymi z DCC i CTCP można:

• ustawić swojego klienta tak, aby całkowicie ignorował wszelkie komendy DCC i CTCP - jest to metoda 100% skuteczna, tyle, że utrudnia nam samym z korzystania z tych usług
• zainstalować skrypt, który posiada zabezpieczenie przed bombami - różne skrypty realizują to zabezpiecznie na różny sposób; do najczęściej spotykanych należy akceptowanie DCC i CTCP tylko od osób z "białej listy" oraz automatyczne czasowe włączanie ignorowania komend DCC i CTCP, jeśli ktoś do nas wysyła np. więcej niż 3 takie komendy jedna po drugiej w krótkim czasie.