Az IRCd , az Internet Relay Chat démon rövidítése, egy olyan alkalmazás, amely megvalósítja az IRC protokollt , amelyet egy szerveren indítanak el , így ez a szerver IRC szerverré válik . Lehetővé teszi, hogy a különböző emberek az interneten keresztül kommunikáljanak egymással azáltal, hogy valós időben cserélnek szöveges üzeneteket. Nem tévesztendő össze egy IRC robottal, amely egy olyan program, amely csatlakozik egy IRC szerverhez, mint bármely más kliens .
A kiszolgáló figyeli az IRC kliensektől érkező kapcsolatokat egy TCP portkészleten . Amikor a szerver egy IRC hálózat tagja, egy vagy több kapcsolatot tart fenn más szerverekkel / démonokkal is.
Az ircd kifejezés eredetileg egyetlen szoftverrészre vonatkozott, de végül általános kifejezéssé vált az IRC démonok bármilyen megvalósításához.
Ezeknek a szervereknek a többségét Linuxot használó gépekre telepítik . Egy ilyen eszköz telepítése gyors és egyszerű. A konfigurálás azonban több időt igényel. Számos webhely kínál oktatóanyagokat az IRCD telepítéséhez.
A leggyakrabban használt IRCD-k a következők:
Az IRCD-k nagy része a fő IRCD-k (nevezetesen az IRCu és a Bahamut ) módosított változata .
Ezeknek a szervereknek nagy része ingyenes és nyílt forráskódú (nyílt forráskódú), ez magyarázza a létező verziók nagy számát.
Ezenkívül az IRC szervereket gyakran kísérik olyan szolgáltatások (Nickserv, Chanserv ...), amelyek olyan funkciókkal egészülnek ki, mint az álnevek és csatornák lefoglalása.
Az O-vonal (Operators Line) az IRC Server konfigurációs fájl adatblokkja (ircd.conf, unrealircd.conf ... az IRCd-től függően ). Arra szolgál, hogy jelezze a rendszer számára, hogy kik a hálózat üzemeltetői, vagyis azok, akik globális szinten átvehetik az irányítást a szerver (ek) en. Az O-vonalakat általában a kiszolgáló / hálózati rendszergazda vagy az IRC szerver konfigurációs fájljaihoz közvetlen hozzáféréssel rendelkező rendszergazda hozza létre. Az O-vonal hozzárendelése egy felhasználóhoz, amely azt jelzi, hogy bizonyos számú hatalmat ad neki a rendszer felett, biztosítani kell, hogy az illető teljesen megbízható legyen, és képes legyen az egyes csatornákon túli szintű műveletek kezelésére is. menedzsment.
O-line példaA konfiguráció típusa az IRCd típusától függően változik.
A következő példa egy O-vonal konfigurációs blokkját mutatja az UnrealIRCd alatt . Összegyűjti az adott IrcOp összes információját és hozzáférési engedélyét , és annyi operátorblokkot tartalmazhat, amennyire szükséges. A mondat mindig az "Oper <operátor neve>" sorral kezdődik, amelyet nyitott zárójel követ, és mindig zárt zárójel és pontosvessző végződik. A pontosvessző általában egy blokk vagy egy konfigurációs sor végét jelzi. Ez így néz ki:
oper UserName { class clients; from { userhost *@InternetServiceProvider.com; }; password "motdepasse"; flags { netadmin; global; get_umodew; get_host; can_gkline; can_gzline; can_zline; can_restart; can_die; can_override; }; maxlogins 1; };Ha részletezzük a blokk tartalmát, akkor különböző elemeket észlelünk:
Az Operator Block számára további opcionális paraméterek is vannak, például a felhasználói módok hozzárendelése az operáció után ...
Ideiglenes o-vonalAz IrcOps szolgáltatásadminisztrátori szintű hozzáféréssel (Services Admins vagy SA) O-vonalakat határozhat meg az OperServen keresztül . A kiszolgáló konfigurációs fájljában definiáltakhoz képest ezek az O-vonalak ideiglenesnek tekinthetők, mert nagyon könnyű beállítani és eltávolítani őket. Ezenkívül nem igényli a konfiguráció újraolvasását, hogy aktív legyen, és az a felhasználó, aki profitál belőle, operációt végezhet a becenevén (a NickServnél regisztrálva) és a NickServ azonosító jelszaván. De a központi konfigurációval ellentétben nem lehet "can_kline" vagy "global" típusú Oper-flageket használni, de úgynevezett "régimódi" zászlókat, például + oaAWst ... (Ezek a módok az új Oper-flag-ekben való megfelelésükkel jelzik az UnrealIRCd dokumentációjában). Például egy felhasználó ideiglenes O-vonalának meghatározásához az adminisztrátor beírja a következő parancsot, és oda helyezi a megfelelő jelzőket:
/MSG OperServ OLINE <pseudonyme> <flags>
Példa: /MSG OperServ OLINE Nickoperateur +owghasW
Ebben a példában a következő jelzőket adtuk hozzá ( + ): egy operátor ( o ), amely láthatja az IrcOps-nak ( w ) küldött szolgáltatási üzeneteket és a hálózaton bárkinek elküldött üzeneteket ( g ). Azt is hozzáfér a különleges segítséget az üzemeltetők a parancs / helpop ( h ), ő is egy rendszergazda szolgáltatások ( a ), aki látja a körüzeneteket ( ek ), és aki kap értesítést, ha egy másik felhasználó nem egy / WHOIS rajta ( W ). A zászlók megkülönböztetik a kis- és nagybetűket. Különböző jogosultságokat adnak: az a különbözik az A-tól (ami a Kiszolgáló rendszergazdája).
Nagyon könnyű eltávolítani az ideiglenes O-vonalat. Ehhez egyszerűen írja be ugyanazt a parancsot, mint korábban, de egyszerűen kövesse a becenevet a mínusz szimbólummal ( - ).
Példa: /MSG OperServ OLINE Nickoperateur -
A felhasználó elveszíti O-vonalát és ideiglenes üzemeltetői jogait.
A D-vonal (vagy D: egyenes ) a tagadó vonalból az IRC szaknyelvben szereplő kifejezés . A K-vonalhoz hasonlóan a D-vonal is megakadályozza a felhasználót abban, hogy egy bizonyos szervert használjon egy IRC-hálózaton. A D-vonal sajátossága, hogy az érintett felhasználó nem is tud csatlakozni a szerverhez (ez azonnal megszünteti a kapcsolatot a tiltott IP-címmel), míg a K-vonal egyszer lekapcsolja ( megöli ) a felhasználót ha a szerverrel való kapcsolata megszűnik (esetleg azután, hogy megjeleníti a MOTD- t a tiltás okát tartalmazó értesítéssel). A D-vonalat általában a tartós támadók közötti kapcsolatok blokkolására használják .
A K-vonal (vagy K: vonal) a kill vonalból az IRC hálózati szakzsargon kifejezés . Egy K-vonal által érintett felhasználó ideiglenesen vagy véglegesen megtagadja a hozzáférést a hálózat bizonyos szervereihez .
Általában a K-vonal egyszerre csak egy szerverre vonatkozik: a tiltott felhasználó ezért egy másik szerveren keresztül csatlakozhat az IRC-hálózathoz. Számos más " vonal " ( G-vonal , Z-vonal stb.) Létezik , amelyek közel állnak a K-vonalhoz. Például egy G-vonal ugyanúgy működik, mint a K-vonal, de ez vonatkozik az IRC-hálózat összes szerverére.
A modern IRC démonok lehetővé tehetik az IrcOps számára, hogy K-vonalakat állítsanak be anélkül, hogy módosítanák a démon konfigurációs fájljait (ami általában a rendszergazdák számára van fenntartva). Néhány IRC szolgáltatás is segíthet ezeknek a vonalaknak a kezelésében , például az OperServ .
Az üzemmódok a csatornák és a felhasználók védelmét, a jogosultságok kiosztását, az opciók aktiválását szolgálják. A módoknak több szintjük van, a szerver kezelésétől a csatornák és a felhasználók szintjén át.
Csak az a felhasználó, akinek egy csatornán vagy egy szerveren vannak jogosultságai, módosíthatja az utóbbinak és a többi felhasználónak a módját (hozzáférési szintje szerint, IrcOp , Admin Services, Channel operator, Half-Op ...). A parancs használata /modeteljes mértékben a felhasználó által választott IRC klienstől függ, szintaxisa a következő:
/mode <cible> <mode> [paramètres]A cél lehet irc csatorna, például #plop, vagy egy felhasználó beceneve ( beceneve ). Az üzemmód nagy vagy kisbetű formájában jelenik meg, előtte + vagy a -, attól függően, hogy meg szeretné-e adni az üzemmódot. Egyes üzemmódok paramétereket igényelnek, különösen azok, amelyeket a felhasználói jogok kezelésére használnak.
Például ahhoz, hogy csak vendégfelhasználók engedjék be a #plop csatornát, az operátor a következőket fogja tenni:
/mode #plop +iUgyanezen a csatornán vonja vissza az üzemeltetői jogokat egy olyan felhasználótól, akinek beceneve "JeanClaude":
/mode #plop -o JeanClaudeHa JeanClaude nem akarja nyilvánosan megjeleníteni az IP-címét , akkor:
/mode JeanClaude +xAz o, v, l, b és k mód egy paramétert vesz fel.
Ezeket a leggyakoribb módokat határozza meg az RFC , minden IRC-kiszolgáló szabadon hozzáadhat annyi módot, amennyit csak akar.
A felhasználók számára bizonyos jogosultságokat biztosító csatorna módjai a következők:
Az IRC hálózatokhoz való legtöbb kapcsolat gyakran tiszta, titkosítatlan. Általában a felhasználók nem igazán figyelnek erre, de a probléma nyilvánvalóvá válik, amikor jelszóval kell bejelentkezni az IRC-szolgáltatásokba . Mivel a jelszavak tiszta állapotban kerülnek továbbításra, mint minden csatlakozási adat, lehetséges, hogy a hálózati forgalmat hallgató harmadik fél elfoghatja őket.
A megoldás tehát az adatok titkosításában áll az információk (beszélgetések, jelszavak, IrcOp bejelentkezések stb.) Védelme érdekében . Így a szerverre belépő és onnan kilépő forgalmat csak a jogos fogadó gépek olvashatják. Általánosságban a hálózat biztonságának biztosítása érdekében az üzemeltetőknek szisztematikusan biztonságos kapcsolatokat kell használniuk, hogy megakadályozzák a szimatolást és ezáltal a jelszavuk ellopását.
Az IRC-kapcsolat titkosítása / biztonsága a szokásos folyamatot követi, amelyet más típusú protokollokkal (például HTTPS- sel ) használnak. Az IRC kliens először tárgyal a szerverrel egy biztonsági alagút létrehozásáról (egy dedikált porton keresztül), amelyben az adatok áramlani fognak (nyilvános kulcsok és tanúsítványok ellenőrzésével és cseréjével). Csak az alagút készenléte után kezdődik az IRC munkamenet. A biztonságos IRC kapcsolat használata nem különbözik a normál kapcsolat használatától, azzal a különbséggel, hogy az ügyfél néha riasztási üzenetet jeleníthet meg, ha a tanúsítvány hiányosnak tűnik (például saját aláírású tanúsítványok esetén).
Általában a kiszolgáló jelzi az ügyfélnek, hogy az adatok titkosítva vannak, a MOTD előtti kapcsolat jellemzőinek megjelenítésével, például:
-irc.serveur.com- *** You are connected to irc.serveur.com with TLSv1-AES256-SHA-256bits
A TLSv1 a biztonsági rendszer verzióját jelzi, az AES a titkosítási protokoll, amelynek kulcshossza 256 bit, az SHA256 a kivonat . Ezek az információk nyilvánvalóan változnak a titkosítási protokolloktól és a kiszolgálón vagy az ügyfélen használt és / vagy elérhető titkosítási protokolloktól és kulcshosszaktól függően.
Ezt követően a Usermode + z alkalmazást kapja az ügyfél, biztonságosként megjelölve. Ez a mód lehetővé teszi a felhasználó számára, hogy csatlakozzon az adatok titkosítását igénylő csatornákhoz, például az adminisztrátorok / operátorok számára fenntartott csatornákhoz vagy másokhoz.
Egyébként, amikor a felhasználó csatlakozik egy szerverhez, és tudni akarja, hogy ez utóbbi támogatja-e a biztonságos kapcsolatokat, akkor csak nézze át a szerveren használható módok listáját. Ez az információ mindig megjelenik, amint létrejön a kapcsolat, a MOTD előtt, így:
Welcome to the MyServer IRC Network [email protected]
A módok listájában (" iowghra ... "), ha a " z " mód megjelenik, az azt jelenti, hogy a szerver támogatja a titkosítást. A biztonságos kapcsolat használatához ezért egy IRCOp-tól vagy egy rendszergazdától kell megkérdeznie a dedikált port számát.
Ez a technika nem mindig igaz. Egyes szerverek, például a hálózati freenode-ban, más módot használnak, más IRCd-k pedig egyszerűen nem rendelkeznek ilyen üzemmóddal.
A legtöbb modern IRC kliens olyan funkciókat valósít meg, hogy csatlakozzon egy IRC szerverhez, amely egy vagy több porttal rendelkezik a biztonságos munkamenetek számára. Néhány kliens ezeket a funkciókat natív módon kezeli (például a KVIrc , az XChat vagy akár az Irssi, ha SSL- támogatással van lefordítva ), ahol más ügyfelek, például az mIRC , titkosítási könyvtárak hozzáadását igénylik, például az OpenSSL-t ( például libeay32 .dll és ssleay32.dll ) . Ezért elegendő a biztonságos kapcsolatok számára kijelölt porton keresztül csatlakozni a szerverhez; például: 7000 (szokás szerint nem hivatalos) 6667 helyett.
Egyes ügyfelek számára néha szükség van egy paraméter hozzáadására a kapcsolat parancshoz, jelezve, hogy titkosítást kell használnia. Az mIRC alatt elegendő egy " + " jelet elhelyezni közvetlenül a portszám előtt (példa :) /server irc.server.com:+6668, vagy néha a kapcsoló -ssl is használható. Kliensenként változó.
A titkosítási rendszer szerveren történő megvalósítása a fordítás előkészítése során történik ( Linux / UNIX vagy FreeBSD rendszert futtató kiszolgáló esetén ). A szervertől ( UnrealIRCd , Bahamut stb.) Függően a parancsfájlt úgy kell konfigurálni, hogy a fordítás során integrálja a titkosítási modulokat. Ez néha felveti azt a kérdést, hogy a felhasználó szeretné-e, hogy a szerver támogassa az SSL típusú kapcsolatokat. Ha a válasz igen, a rendszer megkeresi az OpenSSL vagy más típusú modulokat a titkosítási támogatás telepítéséhez, és létrehozza a szerver kulcsát és tanúsítványát (ebben az esetben önaláírt, ha nincs hivatalos hatóság által kiadott tanúsítvány). A tanúsítvány létrehozásához a szkript számos kérdést tesz fel a felhasználónak, például: webhely neve, földrajzi hely stb. Miután ezt a lépést megtették, elindítható az összeállítás.
A következő lépés a szerver helyes beállítása a biztonságos kapcsolatokat lehetővé tevő port (ok) meghatározása érdekében. Ezt a konfigurációt általában a fájlban ircd.confvagy unrealircd.confa Figyelem blokkban vagy a „ P: sorban ” hajtják végre . Megadja a nem biztonságos szabványos portszámokat (leggyakrabban 6667), majd a biztonságos port (oka) t, hozzáadva a szükséges paramétereket és opciókat, amelyek megadják a szervernek, hogy titkosítást használjon ezekhez a speciális portokhoz. Ezenkívül a nyilvános kulcsot és a tanúsítványt tartalmazó fájlok pontos elérési útjait is fel kell venni az IRC-kiszolgáló fő konfigurációjába. Ezek a fájlok általában a szerver futtatható fájlját tartalmazó mappában találhatók.
Mivel az IRC olyan protokoll, amely megköveteli a továbbított adatok pontosságának ellenőrzését, ezért a TCP átviteli modellen alapul . Ez tehát azt jelenti, hogy ha a kapcsolat túl magas késleltetést, szinkronizálást vagy helyrehozhatatlan csomagvesztést tapasztal, a munkamenet nullnak tekintendő, és az ügyfél vagy a kiszolgáló automatikusan befejezi. Ezért magától értetődik, hogy a biztonsági alagút is ugyanezen szabályok szerint működik. A válasz hiánya az egyik vagy a másik oldalon, a titkosítási kulcsok szinkronizálásának elvesztése vagy egyszerűen a Ping Timeout (túl késleltetett) miatt az alagút bezáródik, és ezzel együtt az IRC munkamenet is véget ér. Így az adatokat nem továbbítják véletlenszerűen, a rendszer ellenőrzése nélkül. A biztonságos munkamenet visszaáll, amikor az ügyfél újra csatlakozik.