English | German | Spanish | Hungarian | French
UnrealIRCd
http://www.unrealircd.com
Version: 3.2.2
Version courante: 3.2.2
Dernière mise à jour de la documentation: 2004-10-11
Head Coders: Stskeeps / codemastr / Syzop / Luke
Contributors: McSkaf / Zogg / NiQuiL / assyrian / chasm / DrBin / llthangel / Griever / nighthawk
Documentation: CKnight^ / Syzop
Traduction française: Vincent Guesnard ( Kolibot ) & babass - irc.rs2i.net

En raison de la complexité croissante d'UnrealIRCd 3.2, nous avons changé pour une navigation plus facile, ce qui nous a permis de vous donner accès à beaucoup plus de documentations. Pour voir ce document vous devez avoir un navigateur compatible, ils sont listés ci-dessous. Les mises à jour de ce document sont disponibles ici : http://www.vulnscan.org/UnrealIrcd/unreal32docs.html ainsi qu'un FAQ http://www.vulnscan.org/UnrealIrcd/faq/.

Navigateurs compatibles:

- Opera 6.02
- Microsoft Internet Explorer 6.X / 5.5
- Netscape Navigator 6.X
- Mozilla 1.2.X
- Lynx (to a point)

INDEX / TABLE DES MATIERES
1. Introduction & Notes
---1.1. Notes sur la mise à jour/mixing 3.1.x -> 3.2
---1.2. Notes sur la mise à jour entre versions 3.2
2. Installation
3. Caractéristiques
-- 3.1. Cloaking
-- 3.2. Modules
-- 3.3. Snomasks
-- 3.4. Aliases
-- 3.5. Helpop
-- 3.6. Niveau d'accès des opérateurs
-- 3.7. Commandes opérateurs
-- 3.8. SSL
-- 3.9. IPv6
-- 3.10. Zip links
-- 3.11. Support des links avec DNS/IP dynamiques
-- 3.12. Caractéristiques de l'anti-flood
-- 3.13. Types de ban
-- 3.14. Spamfilter
-- 3.15. CIDR
-- 3.16. Autres particularités
4. Configurer votre fichier unrealircd.conf
---4.1. Explication du fichier de configuration
---4.2. Me Block -=- (M:Line)
---4.3. Admin Block -=- (A:Line)
---4.4. Class Block -=- (Y:Line)
---4.5. Allow Block -=- (I:Line)
---4.6. Listen Block -=- (P:Line)
---4.7. Oper Block -=- (O:Line)
---4.8. DRpass Block -=-(X:Line)
---4.9. Include Directive
---4.10. Loadmodule Directive
---4.11. Log Block
---4.12. TLD Block -=- (T:Line)
---4.13. Ban Nick Block -=- (Q:Line)
---4.14. Ban User Block -=- (K:Line)
---4.15. Ban IP Block -=- (Z:Line)
---4.16. Ban Server Block -=-(q:Line)
---4.17. Ban Realname Block -=- (n:Line)
---4.18. Ban Version Block
---4.19. Ban Exception Block -=- (E:Line)
---4.20. TKL Exception Block
---4.21. Throttle Exception Block
---4.22. Deny DCC Block -=- (dccdeny.conf)
---4.23. Deny Version Block -=- (V:Line)
---4.24. Deny Link Block -=- (D:Line / d:Line)
---4.25. Deny Channel Block -=- (chrestrict.conf)
---4.26. Allow Channel Block
---4.27. Allow DCC Block
---4.28. Vhost Block -=- (vhost.conf)
---4.29. Badword Block -=- (badwords.conf)
---4.30. Uline Block -=- (U:Line)
---4.31. Link Block -=- (C/N/H:Lines)
---4.32. Alias Block
---4.33. Help Block
---4.34. Official Channels Block
---4.35. Spamfilter Block
---4.36. Set Block -=- (networks/unrealircd.conf)
5. Fichiers additionnels
6. Modes utilisateurs & salons
7. Commandes utilisateurs & Opérateurs
8. Conseils de sécurité/checklist
---8.1. Mots de passe
---8.2. Vulnérabilités non liées à l'Ircd
---8.3. Permissions et fichier de configuration
---8.4. Problèmes liés aux utilisateurs
---8.5. SSL/SSH & sniffing
---8.6. Denial of Service attacks (DoS) [ou: comment protéger mon hub]
---8.7. Conseil sur la divulgation d'informations
---8.8. Protection contre les exploits
---8.9. Conclusion
9. Foire au questions (FAQ)

1.0 – Introduction & Notes

Ce document a été écris exclusivement pour l'utilisation d'UnrealIRCd. Utiliser ce document avec un autre logiciel, ou le distribuer avec un autre logiciel est strictement interdit sans la permission écrite de l'équipe de développement d'UnrealIRCd. Ce document peut être copié/imprimé/reproduit/publié autant de fois que vous le souhaitez, à condition que ce soit pour l'utilisation d'UnrealIRCd et qu'il ne soit jamais modifié d'une quelconque manière. – Copyright UnrealIRCd Development Team 2002-2004

Lisez ce manuel avant de demander de l'aide, vous devez aussi lire attentivement la FAQ qui répond à plus de 80% de vos questions/problèmes. Si vous avez encore besoin d'aide vous pouvez demander du support sur irc.ircsystems.net (port 6667) channel #unreal-support (notez que nous requerrons de votre part une parfaite connaissance de ce document et de la FAQ et que nous donnons uniquement de l'aide sur UnrealIRCD, pas sur les services !). Si vous avez un réel bug (comme un crash) alors reportez le ici http://bugs.unrealircd.org.

1.1 – Notes sur la mise à jour/mixing 3.1.x -> 3.2

Au cas où vous souhaiteriez mettre à jour Unreal3.1.x vers Unreal3.2 vous noterez que l'ensemble des fichiers de configuration a changé, vous devriez trouver cela difficile au début, mais une fois que vous aurez changé vous trouverez cela beaucoup mieux !

N'oubliez pas de lire la section 3 à propos des caractéristiques, bien que vous connaissiez déjà la plupart d'entre elles car elles sont issues des 3.1.x, il y en a tout de même de nouvelles !!

Le mieux n'est pas de mixer une 3.1.x avec une 3.2, mais si vous souhaitez réellement faire cela, vous aurez besoin d'une version 3.1.4 minimum, mais une 3.1.5 est fortement conseillée.

1.2 – Notes sur la mise à jour entre versions 3.2

Le protocole recommandé pour mettre à jour est :
Linux:

- Renommez votre ancien dossier UnrealIRCd (sinon vous écraserez son contenu dans la prochaine étape)
- Extraire la nouvelle version d'UnrealIRCd and écrivez ./Config et make
- Copiez vos anciens fichiers de configuration vers le nouveau répertoire (unrealircd.conf, motd, rules, server.* [SSL certs], network file, etc)

Windows:

- Copiez tous vos fichiers de configuration temporairement vers un autre dossier.
- Lancez le désinstalleur pour toutes les versions précédentes d'Unreal que vous avez installées.
- Lancez l'installeur pour la nouvelle version d'Unreal.
- Copiez vos anciens fichiers de configuration vers le nouveau dossier.

Veuillez vérifier les RELEASE NOTES pour voir ce qui a changé. Si vous notez des changements (ou bug) entre les versions, VOUS DEVEZ ÊTRE SUR D'AVOIR LU LES RELEASE NOTES EN PREMIER avant de reporter cela comme un bug.

2.0 - Installation

Systémes d'exploitation testés et supportés:

- *NIX versions:
  - Linux 2.2.x
  - Linux 2.4.x
  - FreeBSD 4.6-STABLE
  - FreeBSD 4.5-STABLE
  - Solaris 2.x
- Windows version:
  - WindowsXP Home
  - WindowsXP Pro
  - Windows 2000 Pro
  - Windows 2000 Server
  - Windows 2000 Advanced Server
  - Windows 98
  - Windows Me

Si vous avez Unreal3.2 et qu'il fonctionne correctement sous un autre système d'exploitation, envoyer les détails ici : docs@unrealircd.com

Instructions d'installation:
Linux:

1. gunzip -d Unreal3.2.2.tar.gz
2. tar xvf Unreal3.2.2.tar
3. cd Unreal3.2
4. ./Config
5. Répondez à ces questions avec le meilleur de vos connaissances. Généralement, si vous n'êtes pas sur, les paramètres par défaut devrait fonctionner !
6. make
7. Maintenant créez votre unrealircd.conf ainsi que les autres fichiers de configuration, regardez la section 4.

Windows:

1. Lancez l'installateur d'Unreal
2. Maintenant créez votre unrealircd.conf ainsi que les autres fichiers de configuration, regardez la section 4.

3.0 - Caractéristiques

La plupart des caractéristiques majeures/mineures sont expliquées dans cette section. Elle fourni une vue d'ensemble, et fait parfois référence aux fichiers de configuration (quelque chose dont vous ne connaissez encore rien).

Vous pouvez sauter cette section, toutefois il est suggéré de la lire avant/après l'installation.

3.1 - Cloaking

Le Cloaking vous permet de cacher le véritable host des utilisateurs, par exemple si votre host réel est d5142341.cable.wanadoo.nl, il sera montré (lors des join, part, whois, etc) ainsi : rox-2DCA3201.cable.wanadoo.nl. Cette spécificité est utile pour prévenir les floods entre utilisateurs depuis qu'ils ne peuvent plus voir l'host ou l'IP réel.

Cela est contrôlé par le usermode +x (comme : /mode votrepseudo +x), les administrateurs peuvent forcer le mode +x par défaut, ou rendre impossible aux utilisateurs d'enlever ce mode.

Un host cloaked est généré par un module de cloaking (vous devez en avoir un d'amorcé), il y en a 2 officiels à ce jour :
cloak: C'est le nouveau module officiel de cloaking qui est plus sécurisé que l'ancien, il utilise la méthode de hachage md5 et requière 3 set::cloak-keys:: consistant à mixer des caractères alphanumérique (a-z, A-Z et 0-9) [ex: CZCBd45Q6DmtExAd8Bm2"]. Regardez l'example.conf pour un exemple.
oldcloak: C'est l'ancien algorithme utilisé par Unreal3.2 et les versions précédentes, il est ici dans le but de vous montrer l'évolution du processus de chiffrage des hosts/IP réels. Il n'est plus considéré comme sécurisé (vous devriez avoir un avertissement si vous l'utilisez) et vous devriez passer au 'cloak' dès que tous les serveurs seront mis à jour.

Les Cloak keys DOIVENT être les mêmes sur TOUS LES SERVEURS d'un réseau. Elles doivent être gardées SECRETES car il est possible de déchiffrer l'host original si vous connaissez ces clés (ce qui rendrait le umode +x obsolète).

3.2 - Modules

UnrealIRCd supporte des modules, ce qui est très sympathique car :
- Vous pouvez les charger/décharger pendant que l'ircd est lancé (avec /rehash). Cela vous permet de corriger certains bugs ou d'ajouter de nouvelles spécificités sans être obligé de redémarrer !
- D'autres personnes peuvent créer (3rd party) des modules avec de nouvelles commandes, modes utilisateurs et même des modes channels. UnrealIRCd contient seulement quelques modules. Regarder ici www.unrealircd.com -> modules ou utiliser google pour trouver des 3rd party modules.

Vous avez besoin de lancer au moins 2 modules ausinon vous n'aurez pas la possibilité d'amorcer l'ircd ! :
- Le module des commandes : commands.so (commands.dll sous windows)
- un module de cloaking: habituellement cloak.so (cloak.dll sous windows)

3.3 - Snomasks

Les Snomasks sont des notices serveurs, c'est un type spécial de usermode que vous recevrez sous forme de notices serveurs. (la plupart du temps, cela est utilisé par les opérateurs).

Cela peut être établi par: /mode votrepseudo +s SNOMASK, par exemple: /mode votrepseudo +s +cF
Pour enlever certains snomasks, utilisez quelque chose comme : /mode votrepseudo +s -c
Ou vous pouvez aussi enlever tous vos snomasks en écrivant simplement: /mode votrepseudo -s

Les snomasks disponibles sont :
c - les connexions locales
F - les connexions globales (exceptées celles qui proviennent des serveurs qui sont dans vos U:lines)
f - les notices de flood
k - les notices de kill [*]
e - les notices de 'eyes'
j - les notices de 'junk'
v - les notices de vhost
G - les notices de gline/shun
n - les changements de pseudo locaux
N - les changements de pseudo globaux
q - les notices d'interdiction d'utilisation de nick (Q:line)
s - recevoir les notices serveurs [*]
S - recevoir les notices de l'anti-spam
o - recevoir les notices d'identification oper
[*: ces snomasks sont autorisés aux non-opérateurs]

Vous pouvez rendre automatique le don de snomasks (set::snomask-on-connect) et aussi ceux que vous souhaitez quand vous vous /oper (set::snomask-on-oper, oper::snomask)

3.4 - Aliases

Avec les aliases vous pouvez configurer des commandes rapides. Par exemple "/ns identify blah" sera envoyé à nickserv (cela sera traduis par : privmsg nickserv identify blah). Vous pouvez bien entendu créer des alias plus compliqués comme /register qui sera retourné vers Chanserv si le premier paramètre est un # ou sinon vers nickserv.

Les aliases sont à configurer dans les alias blocks contenus dans le fichier de configuration, vous pouvez aussi inclure un fichier avec des aliases par défaut dont la plupart des services se servent.

3.5 - Helpop

UnrealIRCd a un système d'aide accessible via /helpop. La commande /helpop est entièrement configurable via l'help block dans le fichier de configuration. En supplément, un help.conf est inclus, il contient une aide basique pour toutes les commandes par défaut.
Par exemple /helpop chmodes vous donne la liste de tous les modes channels disponibles d'UnrealIRCd.
Rappelez vous que si vous êtes un opérateur (helpop) vous devrez ajouter le préfix ? aux mots clés, donc /helpop devient /helpop ? et /helpop chmodes devient /helpop ?chmodes etc..

3.6 - Niveau d'accés des opérateurs

Dans UnrealIRCd, plusieurs niveaux d'opérateurs sont accessibles. Vous pouvez définir des droits supplémentaires (comme l'utilisation de /gline). Grâce à cela vous pouvez donner aux opérateurs les privilèges dont ils ont besoin.

Cela est contrôlé par les flags opérateurs dans l'oper block, regardez l'oper block pour plus d'informations.

3.7 - Commandes opérateurs

UnrealIRCd a beaucoup de commandes performantes pour les opérateurs qui sont expliquées dans Commandes utilisateurs et opérateurs, vous voudrez probablement lire cela après l'installation :)

3.8 - SSL

Le SSL (Secure Socket Layer) vous permet de sécuriser les connexions grâce à un chiffrement des E/S. Vous pouvez l'utiliser pour sécuriser le trafic entre serveurs mais aussi le trafic client<->serveur. Habituellement, le SSL est utilisé pour protéger contre le sniffing et pour l'authentification.

Pour l'utiliser, il vous faudra compiler votre IRCd avec le support SSL. Pour avoir un port SSL, voici la syntaxe : listen::options::ssl.

Les connexions SSL ne sont pas par défaut (donc ne mettez pas le port 6667 en SSL !!), il vous faut un client ou un tunnel qui supporte le protocol SSL.

Clients supportant le SSL: XChat, irssi, mIRC (6.14 et supérieures, requiert certaines dlls additionelles)

Pour les clients ne supportant pas le SSL vous pouvez utiliser un tunnel comme stunnel, ci-dessous, un exemple de stunnel.conf ( pour stunnel 4.x):

       client = yes
       [irc]
       accept = 127.0.0.1:6667
       connect = irc.myserv.com:6697

Si vous vous connectez sur 127.0.0.1 port 6667, votre trafic sera chiffré et retourné vers irc.myserv.com port 6697 (un port SSL).

Il faut aussi que vous ayez des certificats valides quand vous vous connectez aux serveurs et ne pas les accepter aveuglément (comme dans l'exemple stunnel) sinon vous serez vulnérable aux attaques "active sniffing" (ssl redirects). Ce n'est toutefois pas l'endroit approprié pour en parler (renseignez vous sur le SSL, ne nous demandez rien). [mIRC et xchat vous donne la possibilité d'accepter ou non un certificat, ce qui est parfait].

3.9 - IPv6

UnrealIRCd supporte l'IPv6, depuis la beta15 cela semble être stable.
Votre OS a besoin d'avoir le support IPv6 et il faut valider le support IPv6 durant le ./Config.

Bien que Microsoft ai une implantation expérimentale de l'IPv6 pour w2k/XP, cela n'est pas (encore) supporté par UnrealIRCd.

3.10 - Zip links

Les Zip links peuvent être activés pour les links entre serveurs, il compresse les données en utilisant zlib. Il peut sauvegarder entre 60 et 80% de votre bande passante... Donc, cela est très utilisé pour les links ayant des bandes passantes faibles ou les links avec énormément d'utilisateurs, cela peut beaucoup aider quand vous lancez un /connect et que le serveur à relier contient de nombreux utilisateurs/channels/etc...

Pour compiler avec le support zip links, il faudra répondre Yes lors de la question portant sur le zlib pendant le ./Config et ajouter dans votre link block link::options::zip (des deux côtés).

3.11 - Support des links avec IP/DNS dynamiques

UnrealIRCd a quelques (nouvelles) spécificités qui aideront les utilisateurs ayant des IP dynamiques et qui utilisent des DNS dynamiques (comme blah.dyndns.org). Si vous linkez 2 hosts DNS dynamiques, voici ce que vous devrez mettre : link::options::nodnscache et link::options::nohostcheck.

3.12 - Caractéristiques Anti-Flood

Throttling
Le Throttling est une méthode qui vous permet de déterminer le temps minimum pour qu'un client se reconnecte après une déconnexion à votre serveur. Vous pouvez configurer cela dans votre set::throttle block pour autoriser X connexions toutes les YY secondes depuis la même IP.
Modes des salons
Certains modes channels sont très efficaces contre le flood. En voici quelque uns:
K = /knock interdit, N = changements de pseudo interdits, C = CTCPs interdits, M = seul les utilisateurs enregistrés peuvent parler.
Depuis la beta18, il y a un mode channel beaucoup plus avancé +f...
Mode salon f
A la place d'utiliser des scripts ou des bots pour vous protéger du flood, cela est maintenant possible dans l'ircd.
Un exemple du mode +f est : *** Blah sets mode: +f [10j]:15
Cela signigie que 10 joins sont autorisés toutes les 15secondes sur le salon, si la limite est atteinte, le salon va mettre automatiquement le mode +i Les types de flood suivant sont disponibles :

Type: | Nom: | Action par défaut: | Autres actions possibles: | Commentaires
c | CTCPs | auto +C | m, M |
j | joins | auto +i | R |
k | knocks | auto +K |  | (uniquement pour les clients locaux)
m | messages/notices | auto +m | M |
n | nickchanges | auto +N |  |
t | text | kick | b | par messages/notices utilisateurs comme l'ancien +f. Kick ou ban l'utilisateur.

Example:

    *** ChanOp sets mode: +f [20j,50m,7n]:15
    <ChanOp> lalala
    *** Evil1 (~fdsdsfddf@Clk-17B4D84B.blah.net) has joined #test
    *** Evil2 (~jcvibhcih@Clk-3472A942.xx.someispcom) has joined #test
    *** Evil3 (~toijhlihs@Clk-38D374A3.aol.com) has joined #test
    *** Evil4 (~eihjifihi@Clk-5387B42F.dfdfd.blablalba.be) has joined #test
    -- snip XX lines --
    *** Evil21 (~jiovoihew@Clk-48D826C3.e.something.org) has joined #test
    -server1.test.net:#test *** Channel joinflood detected (limit is 20 per 15 seconds), putting +i
    *** server1.test.net sets mode: +i
    <Evil2> fsdjfdshfdkjfdkjfdsgdskjgsdjgsdsdfsfdujsflkhsfdl
    <Evil12> fsdjfdshfdkjfdkjfdsgdskjgsdjgsdsdfsfdujsflkhsfdl
    <Evil15> fsdjfdshfdkjfdkjfdsgdskjgsdjgsdsdfsfdujsflkhsfdl
    <Evil10> fsdjfdshfdkjfdkjfdsgdskjgsdjgsdsdfsfdujsflkhsfdl
    <Evil8> fsdjfdshfdkjfdkjfdsgdskjgsdjgsdsdfsfdujsflkhsfdl
    -- snip XX lines --
    -server1.test.net:#test *** Channel msg/noticeflood detected (limit is 50 per 15 seconds), putting +m
    *** server1.test.net sets mode: +m
    *** Evil1 is now known as Hmmm1
    *** Evil2 is now known as Hmmm2
    *** Evil3 is now known as Hmmm3
    *** Evil4 is now known as Hmmm4
    *** Evil5 is now known as Hmmm5
    *** Evil6 is now known as Hmmm6
    *** Evil7 is now known as Hmmm7
    *** Evil8 is now known as Hmmm8
    -server1.test.net:#test *** Channel nickflood detected (limit is 7 per 15 seconds), putting +N
    *** server1.test.net sets mode: +N

En fait, cela peut être plus avancé/compliqué:
A la place de l'action par défaut, vous pouvez spécifier d'autres types de flood, par exemple : +f [20j#R,50m#M]:15
Cela mettra le salon en +R si la limite de join est atteinte (>20 joins en 15 secondes), et mettra le salon en +M si la limite de message est atteinte (>50 messages en 15 secondes).
Il y a également des paramètres que vous pouvez ajouter pour enlever les modes après X minutes : +f [20j#R5]:15 mettra le salon en +R si la limite est atteinte et l'enlevera après 5 minutes.
Un serveur peut avoir un temps par défaut pour l'enlèvement de ces modes (set::modef-default-unsettime) donc si vous écrivez +f [20j]:15, celà pourra être transformé en +f [20j#i10]:15, c'est juste par défaut, vous pouvez toujours mettre [20j#i2]:15 ou quelque chose dans le genre, et vous pouvez aussi annuler complétement le retrait automatique en faisant : +f [20j#i0]:15 (un 0 explicite).
L'ancien mode +f (msgflood par un utilisateur) est aussi toujours disponible via 't', +f 10:6 est maintenant appelé +f [10t]:6 et +f *20:10 est maintenant +f [20t#b]:10. Actuellement l'ircd devrait automatiquement convertir l'ancien mode +f vers le nouveau. Notez qu'il n'y a aucun unsettime disponible pour les bans via 't' ([20t#b30]:15 ne fonctionne pas).
Le meilleur mode +f dépend fortement du salon... combien d'utilisateurs a t'il ? Avez vous un jeu qui fait que les utilisateurs envoient beaucoup de messages (ex:trivia) ? Est ce un genre de salon principal ou en auto-join? etc...
Il n'y a pas un mode +f parfait pour tous les salon s, mais pour commencer regardez l'exemple suivant et modifiez le en fonction de vos besoins:
+f [30j#i10,40m#m10,7c#C15,10n#N15,30k#K10]:15
30 joins toutes les 15 secondes, si la limite est atteinte, le salon met le mode +i pour 10 minutes.
40 messages toutes les 15 secondes, si la limite est atteinte, le salon met le mode +m pour 10 minutes.
7 ctcps toutes les 15 secondes, si la limite est atteinte, le salon met le mode +C pour 15 minutes.
10 changements de pseudo toutes les 15 secondes, si la limite est atteinte, le salon met le mode +N pour 15 minutes.
30 knocks toutes les 15 secondes, si la limite est atteinte, le salon met le mode +K pour 10 minutes.
Si le salon a beaucoup d'utilisateurs (>75 ?) vous devrez augmenter la sensibilité du join (par ex: 50) et bien entendu la limite de messages (par ex: 60 ou 75).
Les temps de retrait des modes est spécialement une question de goût... vous devez vous en douter... Que faire si aucun op n'est disponible quand un événement se produit, voudrais-je que le salon soit bloqué pendant 15 minutes (= pas agréable pour les utilisateurs) ou 5 minutes (= la fautif n'ayant qu'à attendre 5m et flooder à nouveau). Ca dépend aussi du type de flood, les utilisateurs sont incapables de rejoindre le salon (+i) ou parler (+m) est pire que de leur empecher de changer leur pseudo (+N) ou d'envoyer des ctcps au salon (+C) onc vous devrez établir différents temps de retrait des modes.

3.13 - Types de ban

Les types de ban basiques et les cloaked hosts
UnrealIRCd supporte les types de ban basiques comme +b nick!user@host.
Mais aussi, si l'host masqué de quelqu'un est 'rox-ACB17294.isp.com' et que vous posez un ban *!*@rox-ACB17294.isp.com, alors si l'utilisateur enlève le mode x (/mode votrepseudo -x) (et son host devient par exemple 'dial-123.isp.com') alors le ban fonctionnera toujours. Les bans sont toujours vérifiés pour les hosts réels ET les hosts masqués.
Les bans avec des IP sont aussi disponibles (ex: *!*@128.*) et sont aussi toujours vérifiés.
Les bans sur les cloaked IPs requièrent quelques explications :
Si l'IP d'un utilisateur est 1.2.3.4 son cloaked host pourrait être 341C6CEC.8FC6128B.303AEBC6.IP.
Si vous bannissez *!*@341C6CEC.8FC6128B.303AEBC6.IP vous bannirez donc aussi *!*@1.2.3.4 (ce qui semble évident...)
Si vous bannissez *!*@*.8FC6128B.303AEBC6.IP vous bannissez *!*@1.2.3.*
Si vous bannissez *!*@*.303AEBC6.IP vous bannissez *!*@1.2.*
Cela devrait vous aider à savoir comment un ban doit être établi le moment venu.
Types de ban étendus
Les bans étendus ressemble à ~[!]<type>:<stuff>. Actuellement, les types suivant sont disponibles:

type: | nom: | explication:
~q | quiet | Les personnes conformes à ces bans peuvent rejoindre les salons mais ne peuvent pas parler, si ils n'ont pas au moins comme flag +v. Ex: ~q:*!*@blah.blah.com
~n | nickchange | Les personnes conformes à ces bans ne peuvent pas changer de pseudo, si ils n'ont pas au moins comme flag +v. Ex: ~n:*!*@*.aol.com
~c | channel | Si l'utilisateur est sur ce salon, il ou elle ne pourra pas rejoindre le salon. Ex: ~c:#lamers
~r | realname | Si le nom réel d'un utilisateur est conforme alors il ne pourra pas rejoindre le salon. Ex: ~r:*Stupid_bot_script* NOTE: un underscore ('_') correspond aussi bien à un espace (' ') qu'à un underscore ('_'), donc ce ban correspondra à 'Stupid bot script v1.4'.

Ces types de bans sont aussi supportés dans la liste d'exception (+e) d'un salon.
Certains modules peuvent ajouter d'autres types de ban étendus.

3.14 - Spamfilter

Le Spamfilter est un nouveau système de lutte contre le spam, la publicité, les worms et plein d'autres choses. Il fonctionne un peu comme que le système de badwords mais il a de nombreux avantages.

Les Spamfilters sont ajoutés grâce à la commande /spamfilter qui utilise la syntaxe suivante:
/spamfilter [add|del|remove|+|-] [type] [action] [tkltime] [reason] [regex]

[type]

Spécifie le type de la cible:

Char: | Config item: | Description:
c | channel | Channel message
p | private | Message privé(d'utilisateur à utilisateur)
n | private-notice | Private notice
N | channel-notice | Channel notice
P | part | Part reason
q | quit | Quit reason
d | dcc | DCC filename
u | user | Ban utilisateur, serra comparé à nick!user@host:realname

Vous pouvez spécifier plusieurs cibles, comme : cpNn

[action]

specifie l'action devant être prise (seule 1 action peut être specifiée)

kill | kill l'utilisateur
tempshun | shun le session courante de l'utilisateur (si il se reconnecte le shun n'est valable)
shun | met un shun sur l'host
kline | met une kline sur l'host
gline | met une gline sur l'host
zline | met une zline sur l'host
gzline | met sur une gzline ( zline globale ) sur l'host
block | bloque seulement le message
dccblock | marque l'utilisateur et l'empêche donc d'envoyer d'autres DCCs
viruschan | part tous les salons, rejoint le set::spamfilter::virus-help-channel, désactive toutes les commandes excepté PONG, ADMIN, et msg/notices vers le set::spamfilter::virus-help-channel

[tkltime] | Durée de la *line ajoutée par le filre, utilisez '-' pour mettre la valeur par défaut ou pour passer outre (ex: si action = 'block')
[reason] | Raison du Block ou de la *line... Vous NE POUVEZ PAS, mais des underscores ('_') seront traduits par des espaces lors de l'utilisation. Et un double underscore ('__') donne un underscore ('_'). Encore une fois, utilisez '-' pour utiliser la valeur par défaut.
[regex] | Ceci est le vrai regex ou "bad word" correspondant au terme qui doit bloquer le message et lancer l'action.

Voici un exemple: /spamfilter add pc gline - - Come watch me on my webcam
Si le texte come watch me on my webcam est trouvé dans un message privé ou sur un salon alors le message sera bloqué et une gline sera immédiatement ajoutée.
Un autre exemple: /spamfilter add pc block - - come to irc\..+\..+
Ceci est un regex qui sera validé sur Hi, come to irc.blah.net etc....
Et un dernier exemple avec un temps/raison :
/spamfilter add p gline 3h Please_go_to_www.viruscan.xx/nicepage/virus=blah Come watch me on my webcam
Si come watch me on my webcam est trouvé dans un message privé alors l'utilisateur est gline pour 3 heures avec comme raison : Please go to www.viruscan.xx/nicepage/virus=blah.
Les Spamfilters ajoutés avec /spamfilter sont globaux. Ils fonctionnent que l'utilisateur/salon ait le mode +G défini ou pas, seuls les opérateurs et les ulines (services) sont exemptés de filtrage.

Vous pouvez aussi ajouter des spamfilters dans le fichier de configuration mais ceux ci seront des spamfilters locaux (non globaux, mais vous pouvez utiliser d'autres "includes" pour cela). La syntaxe de ces spamfilters { } block sont expliqués ici
Exemple:

    spamfilter {
    	regex "//write \$decode\(.+\|.+load -rs";
    	target { private; channel; };
    	reason "Generic $decode exploit";
    	action block;
    };

set::spamfilter::ban-time vous autorise à modifier le ban time par défaut pour les *lines ajoutées par le spamfilter (défaut: 1 jour)
set::spamfilter::ban-reason vous autorise à spécifier une raison par défaut pour les *lines (défaut: 'Spam/advertising')
set::spamfilter::virus-help-channel vous autorise à spécifier le salon à joindre pour l'action 'viruschan' (défaut: #help)
set::spamfilter::virus-help-channel-deny vous autorise à bloquer tout join normal au virus-help-channel (défaut: no)

3.15 - CIDR

UnrealIRCd a maintenant un support pour le CIDR (Classless Interdomain Routing). CIDR vous permet de bannir des ranges d'IP. Des Ips sont allouées aux FAI en utilisant CIDR, cela vous permet en plaçant un ban basé sur le CIDR de bannir facilement un FAI. Unreal supporte le CIDR pour l'IPv4 et l'IPv6. Les masques CIDR peuvent être utilisés dans l'allow::ip, ban user::mask, ban ip::mask, except ban::mask, except throttle::mask, et except tkl::mask (pour gzline, gline, et shun). De plus, le CIDR peut être utilisé dans les /kline, /gline, /zline, /gzline, et /shun. Unreal utilise la syntaxe standard d'IP/bits, 127.0.0.0/8 (correspond à 127.0.0.0 - 127.255.255.255), et fe80:0:0:123::/64 (correspond à fe80:0:0:123:0:0:0:0 - fe80:0:0:123:ffff:ffff:ffff:ffff).

3.16 - Autres particularités

UnrealIRCd a énormément de particularités donc tout n'est pas exposé ici... Vous découvrirez tout cela par vous même.

4.0 - Configurer votre unrealircd.conf

Tout d'abord, créer un bon unrealircd.conf vous prendra un peu de temps, certainement quelquechose comme 10 - 60 min. Vous pouvez essayer de le lancer le plus tôt que vous pouvez et le modifier plus tard, ou alors vous pouvez étudier les sections principales directement pas-à-pas ce qui est la méthode recommandée :p. Si vous avez un problème, vérifiez votre syntaxe, regardez dans le manuel et la FAQ avant de demander de l'aide ou de rapporter un bug.

4.1 Explication du fichier de configuration

Le nouveau système utilise un système basé sur des blocs. Chaque entrée, ou bloc, dans le nouveau format a un format spécifique. Le format est du type :

    <nom du bloc> <valeur du bloc> {
    	<directive du bloc> <valeur du bloc>;
    };

<nom du bloc> est le type du bloc, tel que me, ou admin. <valeur du bloc> parfois spécifie une valeur, telle que /oper login, mais d'autres fois ce sera des sous-types tel que dans un ban utilisateur.

<directive du bloc> est une variable individuelle spécifique au bloc, et <valeur de la directive> contient des espaces, ou des caractères représentant un commentaire qui doit être contenu entre des guillemets. Si vous voulez utiliser un guillemet à l'intérieur à l'intérieur d'un commentaire (texte entre guillemets) utilisez \" et il sera interprété comme un caractère simple.

Une <directive du bloc> peut contenir des directives, si c'est le cas elle aura elle aura son propre jeu d'accolades l'entourant. Certains blocs n'ont pas de directives et sont juste spécifiés par <valeur du bloc>, tel que include. Notez aussi qu'il n'y a pas de format défini, cela veut dire qu'un bloc peut tenir sur une seule ligne comme sur plusieurs lignes. Le format ci-dessus est ce qui est normalement utilisé (et qui sera utilisé dans ce fichier) parce qu'il est facile à lire.

Note : le fichier de configuration est sensible aux majuscules / minuscules (case sensitive) donc NOM-DU-BLOC n'est pas la même chose que nom-du-bloc. Il y a une notation spéciale utilisée pour parler d'entrées dans le fichier de configuration. Par exemple pour parler du <nom de la directive> dans l'exemple ci-dessus, vous devrez dire <nom du bloc>::<directive du bloc>, et si la directive a un sous bloc que vous voulez référencer, vous ajouterez un autre :: et le nom de la sous directive.

Pour parler d'une directive non nommée vous devrez mettre <nom du bloc>:: qui voudra dans ce cas dire <valeur du bloc>, ou cela pourra être une entrée dans un sous bloc qui n'a pas de nom.

Trois types de commentaires sont supportés :

# commentaire d'une seule ligne
// Ocommentaire d'une seule ligne
/* Commentaire
multi-ligne */

Maintenant que vous savez comment ça fonctionne, créez votre unrealircd.conf ou copiez doc/example.conf et commencez à l'éditer. Il est recommandé d'y aller pas à pas avec les différents blocs et de suivre ce manuel de référence.

4.2 - Me Block OBLIGATOIRE (Connu précédemment comme M:Line)

Syntaxe:

    me {
    	name <nom du serveur>;
    	info <description du server>;
    	numeric <numeric du serveur>;
    };

Ces valeurs sont plutôt claires. Le nom défini le nom du serveur, info défini les ligne d'information sur le serveur, numeric défini un numérique pour identifier le serveur. Ce dernier doit avoir une valeur comprise entre 1 et 255 qui est SPÉCIFIQUE au serveur ce qui signifie qu'aucun autre serveur du réseau ne doit avoir le même numérique.

Exemple:

    me {
    	name "irc.foonet.com";
    	info "FooNet Server";
    	numeric 1;
    };

4.3 - Admin Block OBLIGATOIRE (Connu précédemment comme A:Line)

Syntaxe:

    admin {
    	<text-line>;
    	<text-line>;
    };

Ce bloc défini le texte qui sera affiché lors d'une requête /admin. Vous pouvez spécifier autant de lignes que vous le souhaitez et elles peuvent contenir toutes les informations que vous voulez, mais il est standard d'indiquer les pseudos et email des admins au minimum. Vous pouvez également inclure d'autres informations sur les contacts que vous désirez donner.

Exemple:

    admin {
    	"Bob Smith";
    	"bob";
    	"widely@used.name";
    };

4.4 - Class Block OBLIGATOIRE (Connu précédement comme Y:Line)

Syntaxe:

    class <name> {
    	pingfreq <ping-frequency>;
    	connfreq <connect-frequency>;
    	maxclients <maximum-clients>;
    	sendq <send-queue>;
    	recvq <recv-queue>;
    };

Les Class blocks sont les classes dans lequels les connections seront placées (par exemple pour les allow blocks ou les serveurs des link blocks), vous avez généralement plusieurs class blocks (exemple : pour les serveurs, clients, opers).

name est la description, comme "clients" ou "serveurs", ce nom est utilisé comme référence pour les classes dans allow/link/oper/etc blocks.

pingfreq est le nombre de secondes entres les PINGs depuis le server (quelquechose entre 90 et 180 secondes est recommandé).

connfreq est utilisé uniquement pour les serveurs et représente le nombre de secondes entre 2 tentatives de connections si l'autoconnection est activée.

maxclients spécifie le nombre maximum (total) de clients / serveurs pouvant faire partie de cette classe.

sendq spécifie la quantité d'informations pouvant être dans la file d'envoi (send queue) (très grand pour les serveurs avec une faible bande passante, moyen pour les clients).

recvq spécifie la quantité d'informations pouvant être dans la file de reception (receive queue) et est utilisé pour contrôler le flood (cela s'applique uniquement aux utilisateurs normaux, essayez avec des valeurs 3000-8000, 8000 est la valeur par défaut).

Exemples:

    class clients {
    	pingfreq 90;
    	maxclients 500;
    	sendq 100000;
    	recvq 8000;
    };

    class servers{
    	pingfreq 90;
    	maxclients 10; /* Nombre maximal de serveur pouvant être linké au même moment */
    	sendq 1000000;
    	connfreq 100; /* Combien de secondes entre 2 tentatives de connexions */
    };

4.5 - Allow Block OBLIGATOIRE (connu précédemment comme I:Line)

Syntaxe:

    allow {
    	ip <user@ip-connection-mask>;
    	hostname <user@host-connection-mask>;
    	class <connection-class>;
    	password <connection-password> { <auth-type>; };
    	maxperip <max-connections-per-ip>;
    	redirect-server <server-to-forward-to>;
    	redirect-port <port-to-forward-to>;
    	options {
    		<option>;
    		<option>;
    		...
    	};
    };

C'est ici que vous spécifiez qui peut se connecter à ce serveur, vous pouvez avoir plusieurs allow blocks.

A propos des correspondances
Le contrôle des accès fonctionne comme ceci : concordances des ip ou des host, donc "hostname *@*"; et "ip *@1.2.3.4" signifiera que ça concordera toujours. Les allow blocks sont lus de haut en bas, donc vous devez spécifier les host/ip particuliers APRÈS votre allow block général *@*. De plus, si vous voulez spécifier un bloc basé uniquement sur la correspondance à un ip, alors mettez pour l'hostname quelque chose d'invalide, tel que "hostname PERSONNE;", cela permettra au bloc de ne vérifier que la correspondance de l'ip.

ip
L'ip mask est de la forme user@ip, user est l'ident et souvent est défini par *, ip est l'ipmask. Quelques exemples : *@* (depuis n'importe où), *@192.168. * (seulement depuis les adresses commençant par 192.168), etc.

host
Également un user@host hostmask, encore une fois... user est souvent défini par *. Quelques exemples : *@* (n'importe où), *@*.wanadoo.fr (seulement depuis wanadoo.fr).

password (optionnel)
Requiert un mot de passe à la connexion. Vous devez également spécifier une méthode d'encryption des mot de passe ici.

class
Spécifie le nom de la classe dans lequel les connections relevant de cet allow block sont placées.

maxperip (optionnel, mais recommendé)
Vous permet de spécifier combien de connections à ce serveur sont autorisées par ip (exemple : maxperip 4;).

redirect-server (optionnel)
Si la classe est pleine, les utilisateurs seront redirigés vers ce serveur (si les clients le supporte [mIRC 6 le fait]).

redirect-port (optionnel)
Si un serveur de redirection est spécifié vous pouvez définir le port ici, sinon ce sera le 6667.

options block (optionnel)
Les options valides sont :
useip toujours afficher l'ip à la place de l'hostname
noident n'utilise pas d'ident mais l'username spécifié par le client
ssl ne fonctionne que si le client est connecté via ssl
nopasscont concordance continue si aucun mot de passe n'est donnée (ainsi vous pourrez mettre des clients dans des classes spéciales si ils fournissent un mot de passe).

Exemples:

    allow {
    	ip *;
    	hostname *;
    	class clients;
    	maxperip 5;
    };

    allow {
    	ip *@*;
    	hostname *@*.passworded.ugly.people;
    	class clients;
    	password "f00Ness";
    	maxperip 1;
    };

4.6 - Listen Block OBLIGATOIRE (Connu précédemment comme P:Line)

Syntaxe:

    listen <ip:port> {
    	options {
    		<option>;
    		<option>;
    		...
    	};
    };

Ce bloc vous permet de spécifier les ports d'écoute de votre IRCd. Si aucune option n'est requise, vous devez le spécifier sans aucune directive sous la forme listen <ip:port>;.

ip et port
Vous pouvez mettre * comme valeur pour ip pour toutes les accepter, ou en spécifier une pour accepter uniquement les connexions sur cette ip (habituellement requis chez des loueurs de shell). Le port est le port que vous voulez écouter. Vous pouvez également spécifier un intervalle de ports à la place d'une valeur unique. Par exemple, 6660-6669 écoutera du port 6660 au port 6669 (inclus). Pour les utilisateur d'IPv6, voir ci-dessous.

Info pour les utilisateurs de l'IPv6
Si vous avez un serveur Ipv6 vous devrez inclure les ip entre crochets. Comme [::1]:6667 (écouter en localhost sur le port 6667). Si vous utilisez l'IPv6 et que vous voulez écouter une adresse Ipv4 spécifique vous devrez utiliser ::ffff:ipv4ip. Par exemple : [::ffff:203.123.67.1]:6667 qui écoutera à 203.123.67.1 sur le port 6667. Évidemment, vous pouvez aussi juste utiliser *.

options block (optionnel)
Vous pouvez spécifier des options spéciales pour ce port si vous le souhaitez, les options possibles sont :

clientsonly | port réservé aux clients
serversonly | port réservé aux serveurs
java | support CR java
ssl | port encrypté SSL

Exemples:

    listen *:6601 {
    	options {
    		ssl;
    		clientsonly;
    	};
    };

Si il n'y a pas d'options :

listen *:8067;
listen 213.12.31.126:6667;
listen *:6660-6669;

4.7 - Oper Block RECOMMENDE (Connu précédemment comme O:Line)

    oper <name> {
    	from {
    		userhost <hostmask>;
    		userhost <hostmask>;
    	};
    	password <password> { <auth-type>; };
    	class <class-name>;
    	flags <flags>;
    	flags {
    		<flag>;
    		<flag>;
    		...
    	};
    	swhois <whois info>;
    	snomask <snomask>;
    	modes <modes>;
    	maxlogins <num>;
    };

L'oper block vous permet d'assigner des IRC Opérateurs pour votre serveur. Le oper:: spécifie le login pour la commande /oper. Le oper::from::userhost est le masque user@host auquel l'utilisateur doit correspondre, vous pouvez spécifier plus qu'un seul hostmask en créant plusieurs oper::from::userhost. Le oper::password est le mot de passe que l'utilisateur doit spécifier, oper::password:: vous permet de spécifier une méthode d'authentification pour ce mot de passe, les types d'authentifications valides sont crypt, md5 et sha1, ripemd-160. Si vous voulez laisser un mot de passe non crypté ne mettez pas ce sous-bloc.

Notez s'il vous plait que le login et le mot de passe sont tous deux case sensitive autrement dit les majuscules et les minuscules ont leurs importance.

La directive oper::class spécifie le nom d'une classe préexistante (apparaît avant dans le fichier de configuration) que le oper block utilisera.

La directive oper::flags a deux formats. Si vous voulez utiliser l'ancien style d'oper flags, OAa, vous utilisez la méthode flags <flags> method, si vous voulez utiliser la nouvelle méthode, alors vous utiliserez la méthode flags { <flag>; } Ci-dessous ce trouve la liste des flags (dans les deux formats) et leurs correspondances.

Ancien Flag | Nouveau Flag | Description
o | local | Fait de vous un local operator
O | global | Fait de vous un global operator
C | coadmin | Fait de vous un coadmin
A | admin | Fait de vous un admin
a | services-admin | Fait de vous un services admin
N | netadmin | Fait de vous un Network Admin
r | can_rehash | Oper pouvant utiliser /rehash
D | can_die | Oper pouvant utiliser /die
R | can_restart | Oper pouvant utiliser /restart
h | helpop | Oper reçoit umode +h (helpop)
w | can_wallops | Oper pouvant envoyer des /wallops
g | can_globops | Oper pouvant envoyer des /globops
c | can_localroute | Peut se connecter aux serveurs localement
L | can_globalroute | Peut se connecter aux serveurs globalement
k | can_localkill | Peut /kill les utilisateurs locaux
K | can_globalkill | Peut /kill les utilisateurs globaux
b | can_kline | Peut utiliser /kline
B | can_unkline | Peut utiliser /kline -u@h
n | can_localnotice | Peut envoyer des notices sur le serveur local
G | can_globalnotice | Peut envoyer des notices globales
z | can_zline | Peut utiliser /zline
t | can_gkline | Peut utiliser /gline, /shun et /spamfilter
Z | can_gzline | Peut utiliser /gzline
W | get_umodew | Mets umode +W lorsque vous vous oper
H | get_host | Vous applique un oper host
v | can_override | Peut utiliser OperOverride
q | can_setq | Peut utiliser l'usermode +q
X | can_addline | Peut utiliser /addline
d | can_dccdeny | Peut utiliser /dccdeny et /undccdeny

Certain flags give you other flags by default:

local | global | admin/coadmin | services-admin | netadmin
can_rehash | can_rehash | can_rehash | can_rehash | can_rehash
helpop | helpop | helpop | helpop | helpop
can_globops | can_globops | can_globops | can_globops | can_globops
can_wallops | can_wallops | can_wallops | can_wallops | can_wallops
can_localroute | can_localroute | can_localroute | can_localroute | can_localroute
can_localkill | can_localkill | can_localkill | can_localkill | can_localkill
can_kline | can_kline | can_kline | can_kline | can_kline
can_unkline | can_unkline | can_unkline | can_unkline | can_unkline
can_localnotice | can_localnotice | can_localnotice | can_localnotice | can_localnotice
| can_globalroute | can_globalroute | can_globalroute | can_globalroute
| can_globalkill | can_globalkill | can_globalkill | can_globalkill
| can_globalnotice | can_globalnotice | can_globalnotice | can_globalnotice
|  | global | global | global
|  | can_dccdeny | can_dccdeny | can_dccdeny
|  |  | can_setq | can_setq
|  |  |  | admin
|  |  |  | services-admin

La directive oper::swhois vous permet d'ajouter une ligne supplémentaire dans le whois d'un oper. [optionnel]

La directive oper::snomask vous permet d'obtenir automatiquement les snomaks que vous souhaitez lors d'un /oper. Pour avoir la liste des SNOMASKs possibles reportez vous à la Section 3.3 [optionnel]

La directive oper::modes vous permet de prédéfinir un mode oper lors de l'identification. [optionnel]

La directive oper::maxlogins vous permet de restreindre le nombre de login oper concurrent pour un host, par exemple si vous définissez 1 alors, une seule personne pourra se oper à partir d'un bloc à n'importe quel moment. [optionnel]

Exemple:

    oper bobsmith {
    	class clients;
    	from {
    		userhost bob@smithco.com;
    		userhost boblaptop@somedialupisp.com;
    	};
    	password "f00";
    	flags {
    		netadmin;
    		can_gkline;
    		can_gzline;
    		can_zline;
    		can_restart;
    		can_die;
    		global;
    	};
    	swhois "Example of a whois mask";
    	snomask frebWqFv;
    };

Quelques petites informations à propos d' OperOverride :
Les OperOverride sont des choses comme : joindre un salon +ikl et passer outre les bans (vous devez d'abord vous inviter), vous oper sur le salon, etc.
L'operflag can_override a été ajouté de manière à stopper les abus d'opers. Aucun oper n'est capable d'override par défaut, vous devez explicitement leur donner le flag can_override.

4.8 - DRpass Block RECOMMENDE (connu précédemment comme X:Line)

Syntaxe:

    drpass {
    	restart <restart-password> { <auth-type>; };
    	die <die-password> { <auth-type>; };
    };

Ce bloc défini les mots de passe /restart et /die avec respectivement drpass::restart et drpass::die. Les drpass::restart:: et drpass::die:: vous permettent de spécifier le type d'authentification qu'ils utilisent. Les types d'authentification actuellement supportés sont crypté, md5 et sha1, ripemd-160.

Exemple:

    drpass {
    	restart "I-love-to-restart";
    	die "die-you-stupid";
    };

4.9 - Include Directive

Syntaxe:
include <file-name>;

Cette directive spécifie le nom de fichier devant être chargé comme fichier de configuration séparé. Ce fichier peut contenir n'importe quel type de bloc de configuration et peut également inclure d'autres fichiers. Les wildcards sont supporté dans le nom du fichiers pour vous permettre de charger plusieurs fichiers en une fois.

exemple 1: un fichier réseau

    include mynetwork.network;

Ce sera la syntaxe à utiliser si vous voulez utiliser un fichier réseau séparé. Les fichiers réseaux séparés ne sont plus requis; tous les paramètres réseaux peuvent être insérés directement dans unrealircd.conf. Ou vous pouvez mettre un include pour les charger depuis le fichier.

exemple 2: aliases

    include aliases/ircservices.conf

Un autre exemple est de l'utiliser pour inclure des alias blocks, UnrealIRCd est fournis avec des fichiers contenant les bons aliases pour beaucoup de services:

- aliases/ircservices.conf (IRCServices, Daylight)
- aliases/epona.conf (Epona)
- aliases/anope.conf (Anope)
- aliases/auspice.conf (Auspice)
- aliases/generic.conf (Magick, Sirius, Wrecked)
- aliases/cygnus.conf (Cygnus)
- aliases/operstats.conf (OperStats)
- aliases/genericstats.conf (GeoStats, NeoStats)

4.10 - LoadModule Directive OBLIGATOIRE

Syntaxe:
loadmodule <file-name>;

Reportez-vous ici pour voir pourquoi les modules sont biens/utiles.

Modules qui viennent standards avec Unreal3.2 :

commands.so / commands.dll - Toutes les / commandes (en réalité pas encore toutes, mais pourra éventuellement être toutes) OBLIGATOIRE
cloak.so / cloak.dll - Cloaking module OBLIGATOIRE (ou n'importe quel autre cloaking module)

Si vous voulez être sur que ceux si seront chargés :

    loadmodule "src/modules/commands.so";
    loadmodule "src/modules/cloak.so";

ou sous windows:

    loadmodule "modules/commands.dll";
    loadmodule "modules/cloak.dll";

4.11 - Log Block OPTIONNEL

Syntaxe:

    log <file-name> {
    	maxsize <max-file-size>;
    	flags {
    		<flag>;
    		<flag>;
    		...
    	};
    };

Le log block vous permet d'assigner différents fichiers de log pour différentes actions. Le log:: contient le nom du fichier de log. log::maxsize est une directive optionnelle vous permettant de spécifier la taille à laquelle vous voulez que le fichier soit effacé et relancé. Vous pouvez utiliser MB pour megabytes, KB pour kilobytes, GB pour gigabytes. Le log::flags spécifie quel type d'information sera dans ce log. Ci-dessous la liste des flags disponibles.

Vous pouvez également avoir plusieurs log block, pour loguer différentes choses dans des fichiers différents.

Flags disponibles:

errors | erreurs
kills | logue le /kill notices
tkl | logue les infos sur les *lines, shun et spamfilters (ajout/suppression/expiration)
connects | logue les connexions / déconnexions des utilisateurs
server-connects | logue les connections / squit des serveurs
kline | logue l'usage des /kline
oper | logue les tentatives de s'oper (réussies et ratées)
sadmin-commands | logue l'usage des /sa* (samode, sajoin, sapart, etc.)
chg-commands | logue l'usage des /chg* (chghost, chgname, chgident, ect.)
oper-override | logue l'usage des operoverrides
spamfilter | logue les concordances au spamfilter

Exemple:

    log ircd.log {
    	maxsize 5MB;
    	flags {
    		errors;
    		kills;
    		oper;
    		kline;
    		tkl;
    	};
    };

4.12 - TLD Block OPTIONNEL (connu précédemment comme T:Line)

Syntaxe:

    tld {
    	mask <hostmask>;
    	motd <motd-file>;
    	rules <rules-file>;
    	shortmotd <shortmotd-file>;
    	channel <channel-name>;
    	options {
    		ssl;
    	}
    };

Le tld block vous permet de spécifier un motd, rules (règles), et salon pour un utilisateur en se basant sur son host. C'est utile si vous voulez différents motd pour différentes langues. Le tld::mask est un masque user@host auquel l'username et l'host de l'utilisateur doivent correspondre. Les tld::motd, tld::shortmotd, et tld::rules spécifie respectivement les fichiers motd, shortmotd et rules qui doivent être affichés pour un hostmask. Le tld::shortmotd est optionnel. tld::channel spécifie respectivement les fichiers motd, shortmotd et rules qui doivent être affichés pour un hostmask. Le tld::shortmotd est optionnel. Le bloc tld::options vous permet de définir des exigences supplémentaires, habituellement seuls tld::options::ssl qui affiche seulement le fichier pour les usagers SSL, et tld::options::remotes qui affiche seulement le fichier pour les utilisateurs étrangers existent.

Les entrées TLD sont vérifiées de haut en bas.

Exemple:

    tld {
    	mask *@*.fr;<
    	motd "ircd.motd.fr";
    	rules "ircd.rules.fr";
    };

4.13 - Ban Nick Block OPTIONNEL (connu précédemment comme Q:Line)

Syntaxe:

    ban nick {

    	mask <nickname>;
    	reason <reason-for-ban>;
    };

Le ban nick block vous permet d'interdire l'utilisation d'un pseudo sur le serveur. Le ban::mask permet à des masques avec joker de correspondre à plusieurs pseudos, et ban::reason vous permet de spécifier la raison pour laquelle ce ban a été placé. Le plus souvent ces blocs sont utilisés pour bannir l'usage de pseudos généralement utilisés par des services réseaux.

Exemple:

    ban nick {
    	mask "*C*h*a*n*S*e*r*v*";
    	reason "Reserved for Services";
    };

4.14 - Ban User Block OPTIONNEL (connu précédemment comme K:Line)

Syntaxe:

    ban user {
    	mask <hostmask>;
    	reason <reason-for-ban>;
    };

Ce bloc vous permet de bannir un masque user@host à sa connexion au serveur. Le ban::mask est une version avec joker du user@host à bannir, et ban::reason est la raison pour laquelle ce ban a été placé. Notez que ceci est uniquement un ban local et l'utilisateur peut toujours se connecter à un autre serveur pour rejoindre le réseau.

Exemple:

    ban user {
    	mask *tirc@*.saturn.bbn.com;
    	reason "Idiot";
    };

4.15 - Ban IP Block OPTIONNEL (connu précédemment comme Z:Line)

Syntaxe:

    ban ip {
    	mask <ipmask>;
    	reason <reason-for-ban>;
    };

Le ban ip block banni une IP lorsqu'il se connecte au serveur. Cela inclus aussi bien les utilisateurs que les serveurs qui essayent de se connecter. Le paramètre ban::mask est un IP pouvant contenir un joker, et ban::reason est la raison pour laquelle ce ban a été placé. Depuis que ce ban affecte les serveur il doit être utilisé très prudemment.

Exemple:

    ban ip {
    	mask 192.168.1.*;
    	reason "Get a real ip u lamer!";
    };

4.16 - Ban Server Block OPTIONNEL (connu précédemment comme q:Line)

Syntaxe:

    ban server {
    	mask <server-name>;
    	reason <reason-for-ban>;
    };

Ce bloc retire la possibilité d'un serveur de se connecter au réseau. Si le serveur se link directement à votre serveur, le link sera rejeté. Si le serveur se link à un autre serveur, le serveur local se déconnectera du réseau. Le champ ban::mask spécifie un masque avec joker à confronter au nom du serveur tentant de se connecter, et ban::reason spécifie la raison pour laquelle ce ban a été placé.

Exemple:

    ban server {
    	mask broken.server.my.network.com;
    	reason "Its broken!";
    };

4.17 - Ban RealName Block OPTIONNEL (connu précédemment comme n:Line)

Syntaxe:

    ban realname {
    	mask <realname-mask>;
    	reason <reason-for-ban>;
    };

Le ban realname block vous permet de bannir un client basé sur le champs GECOS (realname). Cela est utilisé pour les flood de clones car souvent les bots clones utilisent le même realname. Le ban::mask spécifie le realname devant être banni. Le masque peut contenir un joker. Le ban::reason spécifie pour ce ban a été placé.

Exemple:

    ban realname {
    	mask "Bob*";
    	reason "Bob sucks!";
    };

4.18 - Ban Version Block OPTIONNEL

Syntaxe:

    ban version {
    	mask <version-mask>;
    	reason <reason-for-ban>;
    	action [kill|tempshun|shun|kline|zline|gline|gzline];
    };

Le ban version block vous permet de bannir un utilisateur pour l'utilisation du client IRC qu'il utilise. Ceci se base sur la réponse au CTCP version envoyé au client. Il est donc bien entendu que si le client n'envoie pas de réponse au CTCP version, le ban ne fonctionnera pas. Cette fonction doit vous permettre de bloquer des scripts dangereux. Le ban::mask spécifie la version devant être bannie. Le mask peut contenir un joker. Le ban::reason spécifie la raison pour laquelle le ban a été placé. Vous pouvez également spécifier ban::action, kill est la valeur par défaut, tempshun shunera uniquement la connexion de l'utilisateur et devrait fonctionner très efficacement contres les bots/zombies avec des IPs dynamiques car il n'affectera pas les utilisateurs innocents. shun/kline/zline/gline/gzline placeront un ban de ce type sur l'ip (*@IPADDR), la durée de ce ban peut être configurée avec set::ban-version-tkl-time et est de 1 jour par défaut.

Exemples:

    ban version {
    	mask "*SomeLameScript*";
    	reason "SomeLameScript contains backdoors";
    };

    ban version {
    	mask "*w00tZombie*";
    	reason "I hate those hundreds of zombies";
    	action zline;
    };

4.19 - Ban Exceptions Block OPTIONNEL (connu précédemment comme E:Line)

Syntaxe:

    except ban {
    	mask <hostmask>;
    };

L'except ban block vous permet de spécifier un user@host qui outrepassera un ban placé sur une plage de host. Ceci est très utile lorsque vous voulez bannir un FAI, mais que vous voulez que certains utilisateurs spécifiques puissent toujours se connecter. La directive except::mask spécifie le masque user@host du client qui sera autorisé à se connecter.

Exemple:

    except ban {
    	mask myident@my.isp.com;
    };

4.20 - TKL Exceptions Block OPTIONNEL

Syntaxe:

    except tkl {
    	mask <hostmask>;
    	type <type>;
    	type {
    		<type>;
    		<type>;
    		...
    	};
    };

L'except tkl block vous permet de spécifier un user@host qui pourra outrepasser un ban tkl placé sur une plage de host. Ceci est très utile lorsque vous voulez bannir un FAI, mais que vous voulez que certains utilisateurs spécifiques puissent toujours se connecter. La directive except::mask spécifie le masque user@host du client qui sera autorisé à se connecter. L' except::type spécifie quel type de ban pourra être outrepassé. Les types valides sont gline, gzline, qline, gqline et shun qui feront une exception pour les Glines, Global Zlines, Qlines, Global Qlines, et shuns.

Exemple:

    except tkl {
    	mask myident@my.isp.com;
    	type gline;
    };

4.21 - Throttle Exceptions Block OPTIONNEL

Syntaxe:

    except throttle {
    	mask <ipmask>;
    };

L'except throttle block vous permet de spécifier une IP qui pourra outrepasser le throttling system. Ceci fonctionne uniquement si vous avez choisi d'activer le throttling. L'except::mask spécifie l'IP qui ne sera pas bannie à cause du throttling.

Exemple

    except throttle {
    	mask 192.168.1.*;
    };

4.22 - Deny DCC Block OPTIONNEL (connu précédemment comme dccdeny.conf)

Syntaxe:

    deny dcc {
    	filename <file-to-block>;
    	reason <reason-for-ban>;
    	soft [yes|no];
    };

Le deny dcc block vous permet de spécifier un nom de fichier qui ne pourra être envoyé par DCC via le serveur. Ceci est très utile pour aider à stopper la propagation de virus et / ou trojans.

Le paramètre deny::filename spécifie un masque avec joker du nom de fichier à rejeter, et deny::reason spécifie la raison pour laquelle ce fichier est bloqué.

Il existe aussi une option deny::soft ,si elle a la valeur 'yes' (oui) le dcc sera bloqué à moins que l'utilisateur le permette explicitement via /DCCALLOW + pseudo-essayant-d'envoyer. Regardez le dccallow.conf pour avoir un bon exemple de configuration pour dccallow.

Exemples

    deny dcc {
    	filename virus.exe;
    	reason "This is a GD Virus";
    };

    deny dcc {
    	filename "*.exe";
    	reason "Executable content";
    	soft yes;
    };

4.23 - Deny Version Block OPTIONNEL (connu précédemment comme V:Line)

Syntaxe:

    deny version {
    	mask <server-name>;
    	version <version-number>;
    	flags <compile-flags>;
    };

Ce bloc vous permet d'interdire à un serveur de se linker en fonction de la version d'Unreal qu'il utilise et quelle option de compilation il a. Le format pour ce bloc est un peu complexe mais il n'est pas trop difficile à comprendre. La directive deny::mask spécifie le nom du serveur avec joker auquel il s'applique. Le deny::version spécifie le numéro de protocole de la version auquel on fait référence.

Par exemple, 3.0 d'où 2301, 3.1.1/3.1.2 d'où 2032, 3.2 d'où 2303. Le premier caractère de ce paramètre peut être un des suivant >, <, =, !. Ce caractère dit à l' IRCd comment interpréter la version. Si ce caractère est un > alors toutes les versions supérieures à celle spécifiée seront interdites, Si c'est un < toutes les versions inférieures seront interdites, si c'est un = seulement cette version sera interdite, et si c'est un ! alors toutes les versions seront interdites excepté celle spécifiée. La directive deny::flags vous permet de spécifier que compile time flag le serveur doit ou ne doit pas avoir. Les flags sont arrangé l'un après l'autre sans séparation entre eux, si un caractère est précédé d'un ! alors cela signifiera que le serveur ne pourra pas être compilé avec ce flag, si il n'y a pas de préfixe !, alors cela signifiera que le serveur devra être compilé avec ce flag.

4.24 - Deny Link Block OPTIONNEL (connu précédemment comme D/d:Line)

Syntaxe:

    deny link {
    	mask <server-name>;
    	rule <crule-expression>;
    	type <type-of-denial>;
    };

Ce bloc vous permets d'utiliser des règles spécifiques pour interdire le link d'un serveur. Le deny::mask spécifie un nom de serveur avec joker auquel cette règle s'applique. La directive deny::rules est très complexe. Une expression crule vous permet de contrôler le link en détail, et il se règle comme un programme. Quatre opérateurs sont supportés, connected(<servermask>), retourne vrai si un serveur correspondant au servermask est connecté, directcon(<servermask>), etourne vrai si un serveur correspondant au servermask est directement connecté à ce serveur, via(<viamask>,<servermask>), retourne vrai si un serveur correspondant au servermask est connecté à partir d'un serveur correspondant au viamask, et directop(), qui retourne vrai si l'IRCOP utilisant /connect est directement connecté sur ce serveur. Ces opérateurs peuvent être combinés en utilisant && (et) et || (ou), les items peuvent également être mis entre parenthèses pour permettre le regroupement. De plus, un opérateur précédé d'un ! vérifier si l'opérateur retourne faux. Si l'expression est évaluée comme entièrement vraie, alors le link est refusé. Le deny::type permet deux valeurs différentes, auto (s'applique uniquement aux autoconnexions, /connect fonctionnera toujours), et all (s'applique à toutes les tentatives de connections).

4.25 - Deny Channel Block OPTIONNEL (connu précédemment comme chrestrict.conf)

Syntaxe:

    deny channel {
    	channel "<channel-mask>";
    	reason <reason-for-ban>;
    	redirect "<channel-name>";
    	warn [on|off];
    };

Le deny channel block vous permet d'interdire aux utilisateurs de rejoindre un salon. La directive deny::channel spécifie le nom d'un salon avec joker que les utilisateurs ne pourront rejoindre, et le deny::reason spécifie la raison pour laquelle le salon ne peut être rejoint. De plus, vous pouvez spécifier un deny::redirect. Si celui-ci est spécifié, lorsqu'un utilisateur essaye de rejoindre un salon correspondant à un deny::channel, il ou elle sera redirigé(e) vers deny::redirect. Et il y a également deny::warn qui (si il est activé) enverra une opernotice (au EYES snomask) si un utilisateur essaye de rejoindre le salon.

Exemples

    deny channel {
    	channel "#unrealsucks";
    	reason "No it don't!";
    };

    deny channel {
    	channel "#*teen*sex*";
    	reason "You == dead";
    	warn on;
    };

    deny channel {
    	channel "#operhelp";
    	reason "Our network help channel is #help, not #operhelp";
    	redirect "#help";
    };

4.26 - Allow Channel Block OPTIONNEL

Syntaxe:

    allow channel {
    	channel "<channel-mask>";
    };

Le allow channel block vous permet de spécifier des salons spécifiques que les utilisateurs pourront joindre. La directive allow::channel spécifie les noms de salon avec joker pouvant être rejoint.

Exemple:

    allow channel {
    	channel "#something";
    };

4.27 - Allow DCC Block OPTIONNEL

Syntaxe:

    allow dcc {
    	filename "<filename-mask>";
    	soft [yes|no];
    };

Le allow dcc block vous permet de spécifier des exceptions au deny dcc block, les jokers sont permis. Si allow dcc::soft est mis à 'yes' il applique la liste des 'soft dcc bans', si il est mis à 'no' il applique la listes des dcc bans normaux ('hard').

Exemple:

    allow dcc {
    	filename "*.jpg"; /* Images are usually safe */
    	soft yes;
    };

4.28 - Vhost Block OPTIONNEL (connu précédemment comme vhosts.conf)

Syntaxe:

    vhost {
    	vhost <vhost>;
    	from {
    		userhost <hostmask>;
    		userhost <hostmask>;
    		...
    	};
    	login <login-name>;
    	password <password> { <auth-type>; };
    	swhois "<swhois info>";
    };

Le vhost block vous permet de spécifier un login/mot-de-passe pouvant être utilisé avec la commande /vhost pour obtenir un faux hostname. Le paramètre vhost::vhost peut être un user@host ou juste un host que l'utilisateur recevra après un /vhost réussi. Le vhost::from::userhost contient un user@host auquel l'utilisateur doit correspondre pour être éligible pour un vhost. Vous pouvez spécifier plus d'un hostmask. Le vhost::login est le login que l'utilisateur doit rentrer et vhost::password est le mot de passe devant être entré. Le vhost::password:: vous permet de spécifier le type d'authentification utilisé par cet item. Les types d'authentification actuellement supportés sont crypté, md5 et sha1, ripemd-160. Finallement, vhost::swhois vous permet d'ajouter un ligne supplémentaire au whois des utilisateurs, exactement comme dans le oper block oper::swhois.

Exemple:

    vhost {
    	vhost my.own.personal.vhost.com;
    	from {
    		userhost my@isp.com;
    		userhost myother@isp.com;
    	};
    	login mynick;
    	password mypassword;
    	swhois "Im Special";
    };

4.29 - Badword Block OPTIONNEL (connu précédemment comme badwords.*.conf)

Syntaxe:

    badword <type> {
    	word <text-to-match>;
    	replace <replace-with>;
    	action <replace|block>;
    };

Le badword block vous permet de manipuler la liste utilisée pour le mode utilisateur et salon +G pour cacher les 'mauvais mots'. Le badword:: spécifie le type, les types valides sont channel, message, quit et all. Channel est pour la liste des salons +G, message est pour la liste des utilisateurs +G, quit est pour la censure des messages de quit et all est pour ajouter les trois listes. Le badword::word peut être un simple mot ou une expression régulière que nous pouvons chercher. Le badword::replace est ce par quoi doit être remplacé le mot correspondant. Si badword::replace n'est pas spécifié, le mot est remplacé par <censored>. Le badword::action défini quelle action doit être réalisée si un mauvais mots est trouvé. Si vous spécifiez replace, alors le mauvais mots est remplacé, si vous spécifez block, le message entier sera bloqué. Si vous ne spécifiez pas un badword::action, le mot sera remplacé.

Exemple:

    badword channel {
    	word shit;
    	replace shoot;
    };

4.30 - ULines Block OPTIONNEL (connu précédemment comme the U:Line)

Syntaxe:

    ulines {
    	<server-name>;
    	<server-name>;
    	...
    };

Le ulines block vous permet d'accorder à certains serveurs des possibilités supplémentaires. Ceci doit uniquement être utilisé pour des serveurs comme les services et les stats. Ceci ne doit pas être appliqué à un serveur normal. Chaque entrée est le nom du serveur qui recevra les possibilités supplémentaires.

Exemple

    ulines {
    	services.mynetwork.com;
    	stats.mynetwork.com;
    };

4.31 - Link Block OPTIONNEL (connu précédemment comme C/N/H:Lines)

Syntaxe:

    link <server-name> {
    	username <usermask>;
    	hostname <ipmask>;
    	bind-ip <ip-to-bind-to>;
    	port <port-to-connect-on>;
    	password-connect <password-to-connect-with>;
    	password-receive <password-to-receive> { <auth-type>; };
    	hub <hub-mask>;
    	leaf <leaf-mask>;
    	leafdepth <depth>;
    	class <class-name>;
    	ciphers <ssl-ciphers>;
    	options {
    		<option>;
    		<option>;
    		...
    	};
    };

C'est le bloc dont vous avez besoin pour linker les serveurs, s'il vous plaît prenez le temps de lire tout ceci car c'est l'une des parties les plus difficiles et les utilisateurs font souvent des erreurs. ;P

D'abord server-name est le nom du serveur distant, le nom que le serveur distant a dans son bloc me { }, tel que hub.blah.com (pas l'ip et peut être différent de l'hostname).

username
Vous pouvez le spécifier si vous utilisez l'ident pour l'authentification,normalement vous mettrez "*".

hostname
L'host ou l'ip du serveur distant. Ceci est utilisé pour la connexion et pour l'authentification / vérification du coté entrant. Quelques exemples :

1.2.3.4 | IP normale
hub.blah.com | host: seulement pour sortie, ne peut accepter de connexion entrante sans la présence de link::options::nohostcheck
* | ne peut pas se connecter mais accepte la connexion de n'importe quel serveur (avec le bon mot de passe)
::ffff:1.2.3.4 | pour linker de l'ipv6 à de l'ipv4.

bind-ip (optionnel)
Peut être utilisé pour spécifier un IP (ex. : 192.168.0.1) depuis lequel nous devons nous connecter, presque jamais utilisé.

port
Port auquel on se connecte (celui que le serveur distant écoutera).

password-connect
Le mot de passe utilisé pour se connecter au serveur distant, doit être écrit en clair.

password-receive
Le mot de passe utilisé pour valider les links entrants, peut être encrypté (les méthodes d'encryptions valides sont crypt, md5, sha1, ripemd-160). Vous pouvez laisser le paramètre auth-type décrypté. Souvent, il est le même que le password-connect.

hub vs leaf
Un hub a plusieurs serveurs linké à lui, un leaf n'a qu'un seul link... le vôtre. Un serveur est soit un hub, soit un leaf, vous ne pouvez combiner ces options.

hub (optionnel)
Cette valeur est un masque des serveurs auquel ce hub peut se connecter (ex. : *.my.net).

leaf (optionnel)
Cette valeur est un masque que ce serveur interprétera comme un leaf.

leaf-depth (optionnel)
Si celui-ci est spécifier, alors leaf doit l'être aussi. Cette valeur spécifie la profondeur (nombre de sauts) que ce serveur peut avoir derrière lui.

class
La classe dont ce serveur fait partie, souvent une classe de serveurs séparés est utilisé pour ceci.

compression-level (optionnel)
Spécifie le taux de compression (1-9) pour ce link. Seulement utilisé si link::options::zip est activé.

ciphers (optionnel)
Specifie le SSL ciphers a utiliser pour ce link. Pour obtenir une liste de ciphers disponibles, utilisez la commande `openssl ciphers`. Les ciphers doivent être spécifiés comme : une liste séparée.

options block
Une ou plusieurs options utilisées pour se connecter à ce serveur. Parfois pas requises.

ssl | si vous êtes connecté à un port ssl.
autoconnect | le serveur essayera de se connecter automatiquement, le temps est spécifié dans votre class::connfreq (il est mieux d'activer ceci seulement dans un sens, comme leaf->hub)
zip | si vous voulez des links compressés, vous devez compiler les deux serveurs concernés avec l'option zip activé
nodnscache | ne pas cacher l'ip pour les connexions des serveurs sortants, utilisez cela pour des serveurs dont l'host change souvent (comme dyndns.org)
nohostcheck | ne pas valider l'host distant (link::hostname), utilisez cela pour des serveurs dont l'host change souvent (comme dyndns.org)
quarantine | les opers sur ce serveur conserveront le status de locop.

Exemple:

    link hub.mynet.com {
    	username *;
    	hostname 1.2.3.4;
    	bind-ip *;
    	port 7029;
    	hub *;
    	password-connect "LiNk";
    	password-receive "LiNk";
    	class servers;
    	options {
    		autoconnect;
    		ssl;
    		zip;
    	};
    };

4.32 - Alias Block OPTIONNEL

Syntaxe [standard alias]:

    alias <name> {
    	target <nick-to-forward-to>;
    	type <type-of-alias>;
    };

(Note: reportez-vous également ici à propos des fichiers d'alias standards d'UnrealIRCd)

L'alias block (alias standards) vous permet de transmettre une commande à un utilisateur, par exemple /chanserv envoie un message à l'utilisateur chanserv. L' alias:: spécifie le nom de la commande qui sera l'alias (ici : chanserv), alias::target est le pseudo ou le salon à qui il sera envoyé, si l' alias:: est le même que la cible à qui il sera envoyé alias::target peut ne pas être rempli. L' alias::type spécifie le type d'alias, les types valides sont services (l'utilisateur est sur le serveur des services), stats (l'utilisateur est sur le serveur de statistiques), normal (la cible est sur n'importe quel serveur). L'alias block a également une autre utilité expliqué ci-dessous.

Syntaxe [command alias]:

    alias <name> {
    	format <regex-expression> {
    		target <nick-to-forward-to>;
    		type <type-of-alias>;
    		parameters <parameter-string>;
    	};
    	format <regex-expression> {
    		...
    	};
    	type command;
    };

Lorsque l'alias block est utilisé dans ce format, il vous permet une plus vaste plage d'usage. Par exemple, vous pouvez créer des alias tels que /identify. L' alias:: est comme ci-dessus, le nom de l'alias de commande. L' alias::format spécifie une expression régulière comparée au texte envoyé à l'alias de commande, si l'entrée correspond à l' alias::format elle sera utilisée, vous pouvez définir plusieurs alias::format qui feront faire différentes choses à la commande suivant la syntaxe utilisée. L'alias::format::target est la cible à qui envoyer cette commande. L' alias::format::type spécifie le type d'alias devant être transmit. L'alias::format::parameters est ce qui sera envoyé à cet alias en tant que paramètre. Pour spécifier un des paramètres donné à l'alias de commande, spécifiez % suivi d'un nombre, par exemple %1 est le premier paramètre. Pour spécifier tous les paramètres depuis un paramètre donné jusqu'à la fin, mettez % suivi par le nombre et un -, par exemple %2- retourne tous les paramètres depuis le deuxième jusqu'au dernier. De plus, vous pouvez spécifier %n qui sera remplacé par le pseudo de l'utilisateur qui a tappé la commande. Pour des exemples d'utilisation de l'alias block dans le format de commande, consultez le doc/example.conf.

4.33 - Help Block OPTIONNEL

Syntaxe:

    help <name> {
    	<text-line>;
    	<text-line>;
    	...
    };

(Note: normalement vous ajoutez seulement l'help.conf)

L'help block vous permet des créer des entrées à utiliser dans /helpop. L' help:: est la valeur qui doit être interprétée comme paramètre dans /helpop, si l'help:: est laissé vide, alors il sera utilisé lorsqu'aucun paramètre n'est précisé dans /helpop. Les entrées pour l'help block sont les textes qui seront affiché lorsque l'utilisateur demandera l' /helpop.

4.34 - Official Channels Block OPTIONNEL

Syntaxe:

    official-channels {
    	"#channel" { topic "The default topic"; };
    };

Les salons officiels sont affichés dans la /list même si aucun utilisateurs n'y sont. Le topic est optionnel et est montré dans la /list si il y a 0 utilisateur.

Exemple:

    official-channels {
    	"#Help" { topic "The official help channel, if nobody is present type /helpop helpme"; };
    	"#Home";
    	"#Main" { topic "The main channel"; };
    };

4.35 - Spamfilter Block OPTIONNEL

Le spamfilter block vous permet d'ajouter un filtre anti-spam local (pas au niveau du réseau).
Voir Features - Spamfilter pour plus d'information à propos des filtres anti-spam.

Syntaxe:

    spamfilter {
    	regex <word>;
    	target { <target(s)> };
    	action <action>;
    	reason <reason>;
    	ban-time <time>;
    };

regex est le regex auquel on doit correspondre.
target spécifie les cibles, reportez-vous ici pour obtenir la liste des types disponibles (ex: 'channel').
action spécifie l'action à effectuer, reportez-vous ici pour obtenir la liste des types disponibles (ex: 'gline')
reason optionnel : spécifie la raison du ban ou du blocage, sinon la raison par défaut est utilisée.
ban-time optionnel : spécifie la durée d'un ban *line, sinon la valeur par défaut est utilisée (1 jour).

Exemples:

    spamfilter {
    	regex "Come watch me on my webcam";
    	target { private; channel; };
    	action gline;
    	reason "You are infected, please go to www.antivirus.xx/blah/virus=GrrTrojan";
    	ban-time 6h;
    };

    spamfilter {
    	regex "come to irc\..+\..+";
    	target { private; channel; };
    	action gline;
    	action gline;
    	reason "No spamming allowed";
    };

4.36 - Set Block OBLIGATOIRE (connu précédemment comme unrealircd.conf/networks file)

Le fichier set est ce qui est utilisé en tant que notre networks/unrealircd.conf et notre fichier networks. Sur les réseaux d'un seul serveur, plutôt que d'avoir 3 fichiers vous pouvez tout mettre dans l'unrealircd.conf lui même, sur les réseaux multi-serveurs, je vous recommande d'utiliser des fichiers networks séparés.

Maintenant, si votre serveur est sur un réseau, il y a des chances pour que vous utilisiez basiquement les mêmes réglages Set. Dans ce cas, il est plus logique d'avoir un fichier network, qui est chargé avec une directive include. Ci-dessous, vous trouverez toutes les directives set disponibles.

Dans cette documentation, nous nous référons aux réglages / directives sous la forme <block-name>::<block-directive> Ce format N'est PAS le format pouvant être entré dans le fichiers de configuration. IL DOIT être converti dans le format listé ci-dessous. Il est présenté dans un format qui le rend plus simple à expliquer.

Syntaxe:

    set {
    	<entry> <value>;
    	<entry> <value>;
    	...
    };

Le set block appliques des options pour les réglages d'un serveur individuel. Chaque entrée fait quelque chose de différent et elles seront toutes décrites ci-dessous. Certaines directives ont des sous blocs qui seront également décrits. Il y a beaucoup de intitulés réglages à couvrir, toutes les directives listées ci-dessous peuvent être incluses sous UN intitulé. Si une directive a des options, elles seront incluses dans l'intitulé de réglages au mieux.
Exemple:

    set {
    	kline-address my@emailaddress.com;
    	auto-join #welcome;
    	options {
    		hide-ulines;
    	};
    	hosts {
    		local LocalOp.MyNet.com;
    		global globalop.mynet.com;
    	};
    };

Maintenant si vous voulez faire les intitulés de réglages séparément, dites que vous voulez régler vos options sur une simple ligne.
Exemple:
set { options { hide-ulines; no-stealth; }; };

set::kline-address <email-address>;
L'adresse email à laquelle doivent être envoyés les questions sur les K:line. Cette valeur doit être spécifiée.

set::modes-on-connect <+modes>;
Les modes qui seront appliqués à un utilisateur à la connexion.

set::snomask-on-connect <+modes>
Les snomask qui seront appliqués à un utilisateur à la connexion.

set::modes-on-oper <+modes>;
Les modes qui seront appliqués à un utilisateur lorsqu'il s' /oper.

set::snomask-on-oper <+modes>;
Les snomask qui seront appliqués à un utilisateur lorsqu'il s' /oper.

set::modes-on-join <+modes>;
Les modes qui seront appliqués à un salon lors de sa création. Tous les modes ne peuvent pas être utilisés par cette commande. +qaohvbeOAzlLk ne peuvent être appliqués par cette commande.

set::restrict-usermodes <modes>
Empêche les utilisateurs d'appliquer / enlever les modes listés ici (n'utilisez pas + ou -). Par exemple, vous pouvez mettre le +G en modes-on-connect et G en restrict-usermodes, de cette façon vous obligez tous les utilisateurs à avoir le mode +G et les empêcher de se mettre en -G.

set::restrict-channelmodes <modes>
Empêche les utilisateurs d'appliquer / enlever les modes de salon listés ici (n'utilisez pas + ou -). Par exemple, vous pouvez mettre le +G en modes-on-connect et G en restrict-channelmodes, de cette façon vous obligez tous les (nouveaux) salons à avoir le mode +G et les empêcher de se mettre en -G.
NOTE : il peut toujours être possible d'utiliser ces modes de salon sans passer par les services en utilisant MLOCK. Malheureusement nous ne pouvons pas en faire plus à ce propos, vous devrez le demander aux codeurs de vos services d'implémenter une option restrict-channelmodes également.

set::restrict-extendedbans <types|*>
Ne permet pas aux utilisateurs d'utiliser des bans étendus ("*") ou en empêche certains (ex. : "qc").

set::auto-join <channels>;
Les salons qu'un utilisateur est forcé de rejoindre à la connexion. Pour spécifier plus d'un salon, utilisez une virgule pour les séparer.
[Note : n'oubliez pas d'ajouter des quotes comme : auto-join "#chan";]

set::oper-auto-join <channels>;
Le(s) salon(s) qu'un utilisateur sera forcé de rejoindre après /oper. Pour spécifier plus d'un salon, utilisez une virgule pour les séparer.
[Note: n'oubliez pas d'ajouter des quotes comme : oper-auto-join "#chan";]

set::anti-spam-quit-message-time <timevalue>;
Cette valeur de temps spécifie la durée minimale pendant laquelle l'utilisateur doit être connecté avant de pouvoir afficher un message /quit. Utilisé pour prévenir le spam. Une valeur de temps est une valeur numérique avec d pour jour, h pour heure, m pour minutes, et s pour secondes, par exemple 1d2h3m signifie 1 jour, 2 heures, 3 minutes.

set::prefix-quit <text-to-prefix-quit>;
Défini le texte qui sera affiché devant le message de quit. Si la valeur est 0, alors le texte standard "Quit:" sera appliqué.

set::static-quit <quit message>;
Défini le message de quit qui sera envoyé quel que soit le message envoyé par le client lorsqu'il quitte le réseau. Ceci élimine le besoin de recourir à l'anti-spam-quit-message-time, ainsi que le set::prefix-quit. Cela NE remplacera PAS les ERREURS par le message static-quit.

set::static-part <no|yes|part message>;
Le 'yes' empêchera tous les commentaires de part, le 'no' laissera fonctionner les part comme d'habitude, n'importe quoi d'autre sera utilisé comme commentaire de part (ex. : static-part "Bye!") mais ca peut être assez ennuyeux, alors utilisez le prudemment.

set::who-limit <limit>;
Défini le nombre maximum de réponses retournées lors d'un /who. Si cette option n'est pas spécifiée, il n'y aura pas de limite.

set::silence-limit <limit>;
Défini le maximum d'entrées dans la SILENCE list. Si la directive n'est pas spécifiée, une limite de 15 sera appliquée.

set::oper-only-stats <stats-list>;
Spécifie une liste de flags stats sans séparateur qui défini les flags stats que seuls les opérateurs pourront utiliser. Ne donnez pas de valeur si vous voulez permettre aux utilisateurs d'utiliser tous les flags, ou spécifiez * pour que les utilisateurs ne puissent en utiliser aucun. Seul les flags stats cours peuvent être spécifiés ici.

set::oper-only-stats {<stats-flag>; <stats-flag>;};
Spécifie une liste de flags stats pouvant être utilisés uniquement par les opérateurs. Ceci ne marche qu'avec les flags stats longs.

set::maxchannelsperuser <amount-of-channels>;
Spécifie le nombre de salons sur lesquels un simple utilisateur peut être en même temps.

set::maxdccallow <amount-of-entries>;
Spécifie le nombre maximum d'entrées qu'un utilisateur peut avoir dans son / sa list DCCALLOW.

set::channel-command-prefix <command-prefixes>;
Spécifie le caractère de préfixe pour les services dans les "commandes de salons". Les messages commençant par le caractère spécifié seront envoyé même si le client est en +d. La valeur par défaut est "`".

set::allow-userhost-change [never|always|not-on-channels|force-rejoin]
Spécifie ce qu'il arrive quand un user@host change (+x/-x/chghost/chgident/setident/vhost/etc).
never supprime toutes les commandes, always le permet toujours même si le client est sur un salon (peut causer le desync du client) [défaut] not-on-channels le permet uniquement si l'utilisateur n'est sur aucun salon, force-rejoin forcera à rejoindre tous les salons avec re-op/voice/etc si nécessaire.

set::options::hide-ulines;
Si il est présent, Les serveurs avec Uline seront cachés dans une requête /links par les non-opers.

set::options::flat-map;
Si il est présent, tous les serveurs apparaîtrons comme directement linkés dans /map et /links, ainsi vous ne pourrez plus voir quel serveur est linké directement au quel. C'est une petite aide contre les attaque (D)DoS parce que les personnes mal-intentionnées ne peuvent plus voir facilement les 'points faibles'.

set::options::show-opermotd;
Si il est présent, l'opermotd sera montré aux utilisateurs une fois qu'ils se seront /oper avec succès.

set::options::identd-check;
Si il est présent, la présence d'un serveur d'identd sera vérifiée et la valeur retournée sera utilisée comme username. Si aucune requête d'ident n'est retournée ou si le serveur d'identd n'existe pas, l'username de l'utilisateur spécifié sera préfixé d'un ~. Si cette valeur est omise, aucune vérification ne sera faite.

set::options::show-connect-info;
Si il est présent, les notices "ident request", "hostname lookup", etc. seront affichées à la connexion de l'utilisateur..

set::options::dont-resolve;
Si il est présent, les hosts des utilisateurs entrants ne seront pas résolus, peut être utile si beaucoup de vos utilisateur n'ont pas d'host pour accélérer la connexion.
Notez que depuis que le 'non resolving' existe vous pouvez également avoir des allow blocks basés sur les hosts.

set::options::mkpasswd-for-everyone;
Fait en sorte que le /mkpasswd puisse être utilisé par tout le monde à la place des opers uniquement, l'usage de cette commande par les non-opers est envoyé aux EYES snomask.

set::options::allow-part-if-shunned;
Permet aux utilisateurs shun d'utiliser /part.

set::dns::timeout <timevalue>;
Une valeur de temps spécifie la durée qu'un serveur DNS a pour répondre. Une valeur de temps est un numérique avec d pour jour, h pour heure, m pour minutes, et s pour secondes, par exemple 1d2h3m signifie 1 jour, 2 heures, 3 minutes.

set::dns::retries <number-of-retries>;
Une valeur numérique spécifie le nombre de fois que la résolution de DNS reprendra en cas d'échec.

set::dns::nameserver <name-of-dns-server>;
Spécifie l'hostname du serveur qui sera utilisé pour la résolution de DNS.

set::network-name <name-of-network>;
Spécifie le nom du réseau sur lequel ce serveur tourne. Cette valeur devrait être exactement la même sur tous les serveurs d'un réseau.

set::default-server <server-name>;
Défini le nom au serveur par défaut à indiquer aux utilisateurs pour se connecter si celui-ci est remplis.

set::services-server <server-name>;
Spécifie le nom du serveur auquel les services sont connectés. Obligatoire, définissez le avec quelquechose comme services.yournet.com si vous n'avez pas de services.

set::stats-server <server-name>;
Établis le nom du serveur sur lequel le bot de statistique est présent.Si aucun service de statistique n'est lancé, cette valeur peut être ignoré.

set::help-channel <network-help-channel>;
Spécifie le nom du channel d'aide du réseau.

set::cloak-keys { "key1"; "key2"; "key3"; };
Spécifie les clés qui seront utilisés pour générer les +x hosts. Cette valeur doit être la même sur tous les serveurs d'un réseau. Si ce n'est pas le cas, les serveurs ne pourront plus linker. Les 3 set::cloak-keys:: doivent être des strings de 5 à 100 caractères (10 à 20, c'est bien), elles doivent contenir des lowercases (a-z), des uppercases (A-Z) et des chiffres (0-9). Noter que cela dépend du module de cloaking que vous utilisez, d'autres règles peuvent être appliquées.

set::hiddenhost-prefix <prefix-value>;
Définis le préfix qui sera utilisé dans les hiddenhosts (+x). Il est composé généralement de trois ou quatre lettres qui représente le nom du réseau.

set::hosts::local <locop-host-name>;
Définie l'hostname qui sera assigné aux opérateurs locaux quand ils se mettent le umode +x. Vous pouvez optionnellement specifier un username@host pour cette valeur.

set::hosts::global <globop-host-name>;
Définie l'hostname qui sera assigné aux opérateurs globaux quand ils se mettent le umode +x. Vous pouvez optionnellement specifier un username@host pour cette valeur.

set::hosts::coadmin <coadmin-host-name>;
Définie l'hostname qui sera assigné aux co-admins quand ils se mettent le umode +x. Vous pouvez optionnellement specifier un username@host pour cette valeur.

set::hosts::admin <admin-host-name>;
Définie l'hostname qui sera assigné aux admins quand ils se mettent le umode +x. Vous pouvez optionnellement specifier un username@host pour cette valeur.

set::hosts::servicesadmin <servicesadmin-host-name>;
Définie l'hostname qui sera assigné aux services-admins quand ils se mettent le umode +x. Vous pouvez optionnellement specifier un username@host pour cette valeur.

set::hosts::netadmin <netadmin-host-name>;
Définie l'hostname qui sera assigné aux netadmins quand ils se mettent le umode +x. Vous pouvez optionnellement specifier un username@host pour cette valeur.

set::hosts::host-on-oper-up <yes/no>;
Si vous mettez yes, le flag H/get_host sera honoré et le umode +x sera automatiquement mis quand vous vous /oper. Si vous mettez no, l'utilisateur doit se mettre le umode +x manuellement pour recevoir l'oper host.

set::ssl::egd <filename>;
Spécifie que le support de l'EGD (Entropy Gathering Deamon) devrait être activé. Si vous utilisez OpenSSL 0.9.7 ou une version postérieure, alors /var/run/egd-pool, /dev/egd-pool, /etc/egd-pool, et /etc/entropy seront recherchés par défaut donc aucun nom de fichier n'est nécessaire, vous pouvez simplement spécifier set::ssl::egd sans valeur. Si vous utilisez une version d'OpenSSL antérieure à la 0.9.7 ou vous voulez utiliser un socket EGD placé ailleurs que dans la liste des emplacements listés ci-dessus, vous pouvez spécifier le nom de fichier de l'UNIX Domain Socket qu'un EGD écoute.

set::ssl::certificate <filename>;
Spécifie le nom de fichier où le certificat SSL du serveur est situé.

set::ssl::key <filename>;
Spécifie le nom de fichier où la clé privée SSL du serveur est située.

set::ssl::trusted-ca-file <filename>;
Spécifie le nom de fichier où les certificats du trusted CAs sont situés.

set::ssl::options::fail-if-no-clientcert;
Force les clients n'ayant pas de certificat a être refusé.

set::ssl::options::no-self-signed;
N'autorise par de connexion en provenance de personne ayant des certificats auto-signés.

set::ssl::options::verify-certificate;
Fais qu' Unreal détermine si le certificat SSL est valide avant d'accepter la connexion.

set::throttle::period <timevalue>
Combien de temps un utilisateur doit attendre avant de ce reconnecter.

set::throttle::connections <amount>;
Combien de fois un utilisateur doit se connecter avec le même host pour être throttled. ( stoppé )

set::ident::connect-timeout <amount>;
Nombre de secondes avant de renoncer à la connexion au serveur d'ident (défaut : 10s).

set::ident::read-timeout <amount>;
Nombre de secondes avant de renoncer à une réponse (défaut : 30s).

set::anti-flood::unknown-flood-bantime <timevalue>;
Spécifie combien de temps une connexion inconnue d'un floodeur est bannie.

set::anti-flood::unknown-flood-amount <amount>;
Spécifie la quantité de données (en KiloBytes) que la connexion inconnue doit envoyer pour que l'utilisateur soit killé.

set::anti-flood::away-flood <count>:<period>
Protection contre le flood d'away : limite le nombre de /away par périodes en secondes. Ceci réclame que le NO_FLOOD_AWAY soit activé dans le config.h. Exemple : away-flood 5:60s; signifie maximum 5 changements en 60 secondes.

set::anti-flood::nick-flood <count>:<period>
Protection contre le NickFlood : limite le nombre de changements de pseudo par périodes en secondes. Par exemple nick-flood 4:90 signifie 4 en 90 secondes, le défaut est 3 en 60 secondes.

set::default-bantime <time>
Le bantime par défaut quand vous faites /kline, /gline, /zline, /shun, etc sans paramètre de temps (comme /gline *@some.nasty.isp), par défaut, celui ci est permanent (0). Exemple: default-bantime 90d;

set::modef-default-unsettime <value>
Pour le chmode +f vous pouvez spécifier un unsettime par défaut, si vous spécifiez 10 par exemple, alors +f [5j]:15 sera transformé en [5j#i10]:15. La valeur par défaut est pas d'unsettime par défaut.

set::modef-max-unsettime <value>
Le nombre maximum de minutes pour un mode +f unsettime (in +f [5j#i]:15), c'est une valeur comprise entre 0 et 255. Par défaut, ceci est à 60 (= 1 heure).

set::ban-version-tkl-time <value>
Si vous spécifiez une 'action' like zline/gline/etc dans les ban version, alors vous pouvez spécifier ici combien de temps l'ip va être bannie, par défaut, ceci est établi à 86400 (1 jour).

set::spamfilter::ban-time <value>
Même chose qu'au dessus mais pour les *lines ajoutés par le spamfilter

set::spamfilter::ban-reason <reason>
La raison utilisée pour l'ajout de *lines par le spamfilter

set::spamfilter::virus-help-channel <channel>
Le salon a utiliser pour l'action 'viruschan' dans le spamfilter

set::spamfilter::virus-help-channel-deny <yes|no>
Si vous mettez yes (ou "1") cela enverra "invite only" à tous les utilisateurs normaux essayant de rejoindre le virus-help-channel. Seul les opérateurs, les personnes qui résulte des spamfilters et les personnes qui sont /invite peuvent le rejoindre.

set::spamfilter::except <target(s)>
Ces cibles sont exemptés du spamfilter ( aucune action sera entrepris ), cela peut être une simple cible, ou une liste séparé par des virgules. Ex: except "#help,#spamreport"

5 – Fichiers additionnels

En plus des fichiers de configuration, Unreal compte quelques autres fichiers comme MOTD, OperMOTD, BotMOTD et les règles (Rules). Ci-dessous ce trouve la liste des fichiers et leurs utilités.
Notez que les fichiers motd (tous les types) et les fichiers de règles peuvent aussi être spécifiés dans un tld block, ce sont juste les fichiers utilisés par défauts (et pour les remotes de MOTD / Rules).

ircd.motd | Affiché lorsqu'un /motd est exécuté et (si ircd.smotd n'est pas présent) lorsqu'un utilisateur se connecte
ircd.smotd | Affiché à la connexion uniquement (MOTD court)
ircd.rules | Affiché lorsqu'un /rules est exécuté
oper.motd | Affiché lorsqu'un /opermotd est exécuté ou lorsque vous tapez /oper
bot.motd | Affiché lorsqu'un /botmotd est exécuté

6 – Modes des salons et des utilisateurs

Mode | Description
Modes des salons
A | Seul les administrateurs peuvent rejoindre le salon
a <nick> | Rend l'utilisateur administrateur du salon
b <nick!user@host> | Banni du salon l'utilisateur spécifié
c | Aucune couleur ANSI ne peut être envoyé sur le salon
C | Aucun CTCP n'est accepté sur le salon
e <nick!user@host> | Exception ban – L'utilisateur spécifié peut rejoindre le salon même si il en est banni
f * <lines:seconds> | Flood protection, Si le * est spécifié, un utilisateur sera kickban si il envoie <lines:seconds> si le * n'est pas spécifié, il sera juste kické
G | Contrôle les mots listés dans les Badword Blocks et les remplace par les mots spécifiés.
M | Seul les utilisateurs dont le pseudo est enregistré (+r) peuvent parler sur le salon
h <nick> | Donne le statut de half-op à l'utilisateur
i | Le salon ne peut être rejoint que sous invitation
K | /knock n'est pas autorisé
k <key> | Attribue un mot de passe à spécifier pour rejoindre le salon
l <##> | Spécifie le nombre maximum d'utilisateurs
L <Chan> | Si le maximum spécifié par +l est atteint, les utilisateurs seront redirigés vers ce salon
m | Salon modéré. Seuls les utilisateurs +v/h/o peuvent parler
N | Aucun changement de pseudo n'est autorisé
n | Aucune message ne peut être envoyé de l'extérieur du salon
O | Seul les IRCops peuvent joindre le salon
o <nick> | Donne le statut d'opérateur à l'utilisateur
p | Rend le salon privé (n'apparaît plus dans la liste des salons)
q <nick> | Rend l'utilisateur « owner » (propriétaire) du salon
Q | Seul les U:Lined peuvent kicker les utilisateurs
R | Seuls les utilisateurs enregistrés peuvent rejoindre le salon
S | Supprime toutes les couleurs
s | Rend le salon secret (n'apparaît plus dans la liste des salons)
t | Seuls les chanops peuvent changer le topic
T | Aucune notice ne peut être envoyée sur le salon
u | Auditorium – Les commandes /names et /who #chan n'affichent que les opérateurs
V | /invite n'est pas autorisé
v <nick> | Donne le statut de voice à l'utilisateur (peut parler quand le salon est modéré, +m)
z | Seul les utilisateurs avec une connexion sécurisée (SSL) peuvent joindre le salon

Mode | Description
Modes des utilisateurs
r | Identifie le pseudo comme étant enregistré
s | Peut lire les server notices
v | Reçoit les notices de refus de DCC infectés
o | Global IRC Operator (défini par Oper Block)
O | Local IRC Operator (défini par Oper Block)
B | Vous renseigne comme étant un bot
i | Invisible (n'est pas montré dans un /who)
A | Server Admin (défini dans Oper Block)
x | Donne à l'utilisateur un hostname caché
q | Seul les U:Lines peuvent vous kicker (Services Admin uniquement)
a | Services Admin (défini dans Oper Block)
g | Peut envoyer et lire les globops et locops
H | Cache le status d'IRCop (IRCop uniquement)
S | Utilisé pour protéger les Services Daemons
t | Dis que vous utilisé un /vhost
C | Co-Admin (défini dans Oper Block)
d | Fait en sorte que vous ne puissiez pas recevoir de message provenant des channels
N | Network Administrator (défini dans Oper Block)
w | Peut lire les wallops
h | Disponible pour aide (HelpOp) (défini dans Oper Block)
G | Filtre tous les bad words définis par configuration
W | Vous laisse voir quand quelqu'un vous /whois (IRCop uniquement)
p | Cache les canaux sur lesquels vous êtes dans les /whois
R | Vous permet de ne recevoir de messages privés et de notices que d'utilisateurs enregistrés (+r)
V | Vous marque comme un utilisateur de WebTV
z | Indique que vous êtes un client SSL
T | Vous empêche de recevoir des CTCPs

7 – Commandes utilisateurs et opérateurs

Notez que la documentation fournie par /helpop est plus à jour, utilisez /helpop commande (ou /helpop ?commande si vous êtes oper) pour avoir des informations sur une commande.

Commande | Description | Qui
nick <newnickname> | Change votre pseudo. Averti les autres de votre changement de pseudo | Tous
whois <nick> | Affiche les informations sur l'utilisateur ciblé. Inclus le pseudo, l'host, les salons sur lesquels il se trouve et son statut d'Oper. Si vous êtes un IRCOP, vous avez accès à plus d'informations tel que les umodes de l'utilisateur. | Tous
who <mask> | Vous permet de chercher des utilisateurs. Masks inclus : pseudo, #salon, hostmask (*.attbi.com) | Tous
whowas <nick> <max de réponses> | Affiche les informations sur un pseudo qui n'est plus connecté. Le nombre maximum de réponses est facultatif et limite le nombre d'enregistrements qui seront retournés | Tous
ison <nick1 nick2 nick3 ...> | Vous permet de vérifier qu'un utilisateur (ou plusieurs) est connecté. Réponse simple, meilleur usage pour les scripts. | Tous
join <channel1,channel2, ...> | Vous permet de rejoindre des salons. Utiliser /join #salon1,#salon2,#salon3 vous permettra de rejoindre plus d'un salon en une fois. La commande /join 0 vous fait partir (PART) de tous les salons. | Tous
cycle <channel1, channel2, ...> | Cycle les salons spécifiés. Cette commande équivaut à faire un PART suivi d'un JOIN. ( Pour les utilisateurs de mIRC, la commande /hop est équivalente ) | Tous
motd <server> | Affiche le motd ( Message Of The Day ) du serveur. Vous pouvez spécifier un nom de serveur si vous souhaitez voir le motd d'un serveur particulier sur un réseau. | Tous
rules <server> | Affiche le ircd.rules d'un serveur. Ajouter le nom d'un serveur. Vous pouvez spécifier un nom de serveur si vous souhaitez voir le ircd.rules d'un serveur particulier sur un réseau. | Tous
lusers <server> | Affiche le nombre actuel et maximum d'utilisateurs, en global et local. Vous pouvez spécifier un nom de serveur si vous souhaitez voir les statistiques d'un serveur particulier sur un réseau. | Tous
map | Affiche la carte (map) du réseau | Tous
quit <reason> | Vous déconnecte du serveur. Si vous ajoutez une raison, elle sera affichée sur tous les salons, lorsque vous quitterez. | Tous
ping <user> | Envoie une requête de PING à l'utilisateur. Utilisé pour vérifier une connexion et son lag. Les serveurs envoient des pings à des moments déterminés pour vérifier que les utilisateurs sont toujours connectés. | Tous
version <nick> | Cela envoie une requête de CTCP Version à l'utilisateur. Si il est configuré pour, le client renverra sa version en réponse. | Tous
links | Affiche la liste de tous les serveurs reliés au réseau. | Tous
Admin <server> | Affiche les "admin info" du serveur. Si un nom de serveur est inclus, il affichera les infos de ce serveur. | Tous
userhost <nick> | Affiche les userhost du pseudo spécifié. Généralement utilisé pour les scripts. | All
topic <salon> <topic> | Topic <salon> affichera le topic courrant du salon spécifié. Topic <salon> <topic> changera le topic du salon spécifié. | Tous
invite <nick> <channel> | Invite l'utilisateur spécifié à rejoindre le salon spécifié. (Vous devez être channel Op) | ChanOp
kick <channel, channel> <user, user> <reason> | Kick le ou les utilisateurs spécifiés du ou des salons spécifiés. Une raison peut également être précisée. | ChanOp
away <raison> | Vous marque comme étant absent. Une raison peut également être spécifiée. | Tous

Watch +-<nick> +-<nick>

Watch est un nouveau système de "notify-type" dans UnrealIRCd qui est en même temps plus rapide et moins gourmant en ressources du réseau qu'aucun autre ancien système de notify. Le serveur vous envoye un message lorsqu'un pseudo de votre watch list se connecte ou se déconnecte. La watch list NE RESTE PAS ENTRE 2 SESSIONS - vous (ou votre script ou client) devez ajouter les pseudos dans la watch list à chaque fois que vous vous connectez sur un serveur IRC.

Tous

helpop ?<topic> ou !<topic>

HelpOp est un nouveau système pour avoir l'aide d'un serveur IRC. Vous tapez soit /HELPOP ? <sujet du système d'aide> ou /HELPOP ! <question> Le "?" dans /HELPOP veut dire interroger le système d'aide et si vous n'avez pas de réponse, "!" enverra la question à un Opérateur connecté. Utiliser ? et ! signifie que la question sera d'abord envoyée au système d'aide et que si aucune réponse n'est trouvée, elle sera envoyée à un Opérateur.

Tous

list <élément recherché>

Si vous ne spécifiez pas d'élément recherché, par défaut toute la liste des salons vous serra envoyée. Ci-dessous, les options que vous pouvez utiliser, et ce que la liste des salons vous reverra lorsque vous les utiliserez.
>nombre affichera la liste des salons comptant plus de <nombre> utilisateurs.
<nombre affichera la liste des salons comptant moins de <nombre> utilisateurs.
C>nombre affichera les salons créés depuis <nombre> minutes
C<nombre affichera les salons créés avant <nombre> minutes.
T>nombre affichera les salons dont le topic n'a plus été changé depuis au moins <nombre> minutes (Ie., ils n'ont pas chnagés dans les dernières <nombre> minutes.
T<nombre affichera les salons dont le topic a été changé depuis moins de <nombre> minutes.
*mask* affichera les salons comprennant *mask*
!*mask* affichera les salons ne comprennant pas *mask*

Tous

Knock <salon> <message> | Vous permet de ‘frapper à la porte’ d'un salon sous invitation pour demander le droit de le rejoindre. Ne fonctionnera pas sur les salons ayant les modes suivants : +K +V. Ne fonctionnera pas non plus si vous êtes banni. | Tous
setname | Permet aux utilisateurs de changer leur ‘Real Name’ sans avoir à se reconnecter. | Tous
vhost <login> <mot de passe> | Cache votre host en utilisant une vhost fournie par le serveur. | Tous
mode <salon/pseudo> <mode> | Vous permet de changer les modes des salons et des utilisateurs. Voir Modes des salons et des utilisateurs pour avoir la liste. | Tous
credits | Affiche la liste de toutes les personnes ayant aider à créer UnrealIRCd. | Tous
license | Affiche la licence GNU. | Tous
time <server> | Affiche la date et l'heure du serveur. Spécifier un nom de serveur vous permet d'interroger un autre serveur. | Tous
botmotd <server> | Affiche le motd du serveur de bot. Spécifier un nom de serveur vous permet d'interroger un autre serveur. | Tous
identify <mot de passe> | Envoie votre mot de passe aux services pour identifier votre pseudo. | Tous
identify <salon> <mot de passe> | Envoie votre mot de passe aux services pour vous identifier en tant que "founder" (fondateur) d'un salon. | Tous
dns <option> | Renvoie les informations concernant les DNS cache du serveur IRC. Notez que depuis, certains clients ont leur propre commande DNS, vous pourrez alors utiliser /raw DNS. Les Opérateurs peuvent spécifier un "l" comme premier paramètre dans la commande pour recevoir une liste d'entrée dans le DNS cache. | Tous
oper <login> <mot de passe> | Commande pour donner le status d'Opérateur à un utilisateur si les spécifications correspondent à un Oper Block. | IRCop
wallops <message> | Envoie un message à tous les utilisateurs +w | IRCop
globops <message> | Envoie un message à tous les IRCops | IRCop
chatops <message> | Envoie un message à tous les IRCops ayant le mode +c | IRCop
locops <message> | Envoie un message à tous les IRCops locaux | IRCop
adchat <message> | Envoie un message à tous les Admins | IRCop
nachat <message> | Envoie un message à tous les Net Admins | IRCop
kill <nick> <raison> | Kill l'utilisateur du réseau | IRCop

kline [+|-]<user@host | nick> [<durée du ban> <raison>]

Bannir le hostmask du serveur sur lequel la commande a été utilisée. Une kline n'est pas un ban global.
La durée du ban peut être: a) une valeur en seconde, b) une durée, comme "1d" pour un jour (day) c) "0" pour permanent. Le temps et la raison son optionnels, si rien n'est spécifié, ce sera set::default-bantime (défaut : 0 / permanent) et "no reason" qui seront utilisés.
Pour enlever une kline, utilisez /kline -user@host.

IRCop

zline [+|-]<*@ip> [<durée du ban> <raison>] | Banni une adresse ip du serveur locals sur lequel la commande a été utilisée (pas global). Regardez kline pour plus d'informations. Utilisez /zline -*@ip pour l'enlever. | IRCop
gline [+|-]<user@host | nick> [<durée du ban> <raison>] | Ajoute un ban global sur l'utilisateur spécifié. Regardez kline pour plus d'informations. Utilisez /gline -user@host pour l'enlever. | IRCop
shun [+|-]<user@host | nick> [<durée du shun> <raison>] | Empêche un utilisateur d'utiliser n'importe quelle commande et de parler. Les shuns sont globaux (comme les glines). Regardez kline pour plus d'informations. Utilisez /shun -user@host pour l'enlever. | IRCop
gzline [+|-]<ip> <durée du ban> :<raison> | Ajoute une zline globale. Regardez kline pour plus d'informations. Utilisez /gzline -*@ip pour l'enlever. | IRCop

rehash <server> –<flags>

Rehash le fichier de configuration des serveurs. Spécifier un nom de serveur, vous permet de rehasher le fichier de configuration d'un serveur distant. De nombreux flags sont disponibles. Ils incluent :
-motd - rehash uniquement les fichiers MOTD et RULES (incluant tld {})
-opermotd - rehash uniquement le fichier OPERMOTD
-botmotd - rehash uniquement le fichier BOTMOTD
-garbage - Force garbage collection

IRCop

restart <server> <mots de passe> | Relance l'IRCD Process. Le mot de passe est requis. Vous devez aussi spécifier un nom de serveur pour relancer un serveur distant. | IRCop
die <mots de passe> | Arrête un IRCD Process. Le mot de passe est requis. | IRCop
lag <server> | Cette commande est comme un Sonar ou un Traceur pour serveur IRC. Vous tapez /LAG irc.rs2i.net et il a mis pour trouver un serveur et donc le fait qu'il fonctionne. Utile lorsque vous cherchez d'ou viens le lag et en option les TS futurs et passés. | IRCop
sethost <nouveau host> | Vous permet de changer votre vhost. | IRCop
setident <nouvel ident> | Vous permet de changer votre ident. | IRCop
chghost <nick> <nouvel host> | Vous permet de changer votre l'hostname d'un utilisateur connecté. | IRCop
chgident <nick> <nouvel ident> | Vous permet de changer votre l'ident d'un utilisateur connecté. | IRCop
chgname <nick> <nouveau nom> | Vous permet de changer votre le realname d'un utilisateur connecté. | IRCop
squit <server> | Déconnecte un serveur du réseau. | IRCop
connect <server> <port> <server> | Si un seul serveur est précisé, le serveur sur lequel vous êtes va tenter de se connecter au serveur spécifié. Si 2 serveurs sont précisés, ils vont tenter de se connecter l'un à l'autre. Mettre le hub en deuxième position. | IRCop
dccdeny <filemask> <reason> | Ajoute un DCCDENY pour ce filemask. Empêche ce fichier d'être envoyé. | IRCop
undccdeny <filemask> | Enlève un DCCDENY | IRCop
sajoin <nick> <channel>, <channel> | Force l'utilisateur à joindre le, les salons. Accessible par les services et network admins seulement. | IRCop
sapart <nick> <channel>, <channel> | Force l'utilisateur à partir du, des salons. Accessible par les services et network admins seulement. | IRCop
samode <channel> <mode> | Permet aux services et network admins de changer les modes d'un salon sans en être ChanOp. | IRCop
rping <servermask> | Calcule en millisecondes le lag entre les serveurs. | IRCop
trace <servermask|nickname> | Quand elle est utilisée sur un utilisateur, elle vous donnera les informations sur la classe et le lag. Si elle est utilisée sur un serveur, elle vous donnera les informations sur le classe, la version et le link. | IRCop
opermotd | Affiche le fichier OperMotd des serveurs. | IRCop
addmotd :<text> | Ajoute le texte donné à la fin du Motd | IRCop
addomotd :<text> | Ajoute le texte donné à la fin du OperMotd | IRCop
sdesc <nouvelle description> | Permet aux server admins de changer la description de leur serveur sans avoir a le relancer. | IRCop
addline <texte> | Vous permet d'ajouter des lignes à unrealircd.conf | IRCop
mkpasswd <mots de passe> | Va encrypter un mot de passe pour l'ajouter dans le unrealircd.conf | IRCop
tsctl offset +/- <time> | Ajuste l'horloge interne de l'IRCD (NE PAS utiliser si vous ne savez pas exactement ce que vous faites). | IRCop
tsctl time | Donnera un TS Report. | IRCop
tsctl alltime | Donnera un TS Report de tous les serveurs. | IRCop
tsctl svstime <timestamp> | Applique le temps TS à tous les serveurs (NE PAS utiliser si vous ne savez pas exactement ce que vous faites). | IRCop

htm <option>

Réglages relatifs au mode "high traffic". Le mode "high traffic" (HTM) désactive certaines commandes comme : list, whois, who, etc. en réponse à un traffic important sur le serveur. Les options sont :
-ON Force le passage du serveur en HTM
-OFF Force la sortie du serveur du HTM
-NOISY Active l'avertissement des utilisateurs / admins lorsque le serveur entre / sort du HTM
-QUIT Désactive l'avertissement des utilisateurs / admins lorsque le serveur entre / sort du HTM
-TO <valeur> Dis au HTM, à quel taux il doit s'activer

IRCop

stats <option>

B - banversion - envoie la liste des versions de ban
b - badword - envoie la liste des mots censurés
C - link - envoie la liste des link block
d - denylinkauto - envoie la liste des links block (auto) interdits
D - denylinkall - envoie la liste des links block (tous) interdits
e - exceptthrottle - envoie la liste des except throttle block
E - exceptban - envoie des except ban block
f - spamfilter - envoie la liste des spamfilter
F - denydcc - envoie la liste des deny dcc block
G - gline - envoie la liste des gline
Flags secondaires: [+/-mrs] [masque] [raison] [mis par]
m Renvoie les glines contenant / ne contenant pas la mask spécifié
r Renvoie les glines dont la raison est / n'est pas celle spécifiée
s Renvoie les glines mis / n'ont mis par la personne spécifiée
I - allow - envoie la liste des allow block
j - officialchans - envoie la liste des salons officiels
K - kline - envoie la liste des ban user / ban ip / except ban
l - linkinfo - envoie les informations sur le link
L - linkinfoall - envoie les informations sur les links
M - command - envoie le nombre de fois que les commandes ont été utilisées
n - banrealname - envoie la liste des ban realname block
O - oper - envoie la liste des oper block
S - set - envoie la liste des set block
s - shun - envoie la liste des shuns
Flags secondaires: [+/-mrs] [masque] [raison] [mis par]
m Renvoie les glines contenant / ne contenant pas la mask spécifié
r Renvoie les glines dont la raison est / n'est pas celle spécifiée
s Renvoie les glines mis / n'ont mis par la personne spécifiée
P - port - envoie les informations concernant les ports
q - sqline - envoie la liste des SQLINE
Q - bannick - envoie la liste des ban nick block
r - chanrestrict - envoie la liste des chans deny / allow block
R - usage - envoie les informations d'usage
t - tld - envoie la liste des tld block
T - traffic - envoie les informations sur le traffic
u - uptime - envoie l'uptime du serveur et le nombre de connections
U - uline - envoie la liste des ulines block
v - denyver - envoie la liste des deny version block
V - vhost - envoie la liste des vhost block
X - notlink - envoie le liste des serveurs qui ne sont pas actuellement linkés
Y - class - envoie la liste des class block
z - zip - envoie les informations sur la compression des serveurs ziplinked (si ils ont été compilés avec le support ziplink)
Z - mem - envoie les informations sur la mémoire utilisée

Tous

module | Liste tous les modules chargés | Tous
close | Cette commande déconnectera toutes les connections inconnues du serveur IRC. | IRCOp

8 – Conseils de sécurité/checklist

Si vous êtes concernés par la sécurité, et vous le devriez, cette section vous donnera un aperçu des risques possibles et leurs niveaux de sensibilité. Vous pouvez également utiliser celle-ci comme une checklist pour parcourir la configuration de votre réseau et le rendre plus sécurisé.

Cette liste est ordonnée suivant la popularité, le niveau de risque et les méthodes les plus souvent utilisées :

8.1 Mots de passe

Choisissez de bons mots de passe oper, link, etc. :
- mélangez les lettres (majuscules et minuscules) et les chiffres ("Whbviwf5") et/ou quelque chose de long ("blaheatsafish", "AlphaBeta555").
- N'UTILISEZ PAS vos mots de passe oper, link pour autre chose comme votre compte mail, bot, forums, etc ...

8.2 Vulnérabilités non lièes à l'IRCd

Il y a beaucoup plus de chance qu'un serveur se fasse pirater à cause d'une vulnérabilité non-ircd qu'à cause d'un bug UnrealIRCd. Si vous faites tourner sur la même machine des serveurs http, dns, smpt ou ftp par exemple, vous avez de plus grands risques. Aussi, si vous êtes sur une machine Multi-Utilisateurs (ex. : vous louez un shell) il y a des risques de failles locales ou mauvaises permissions (voir plus loin). Le risque est grand donc soyez prudent lors du choix de votre loueur de shell.

8.3 Permissions et fichier de configuration

Soyez toujours sur que vos dossiers home et UnrealIRCd ont des permissions correctes, les autres groupes ne doivent pas avoir la permission de les lire. Sinon un utilisateur local pourra ouvrir votre configfile (fichier de configuration) et chercher les mots de passe ... Vous pouvez faire : chmod -R go-rwx /path/to/Unreal3.2 si vous n'en êtes pas sûr.
Autres choses dans le même style : ne mettez jamais votre UnrealIRCd dans un webroot ou un autre type de fichier partagé. Et pour les backups (sauvegardes), assurez vous qu'elles aient les bonnes permissions également (il arrive assez souvent que tout est bien sécurisé mais qu'il y a un backup.tar.gz quelque part lisible par tout le monde).
Vous pourrez également vouloir crypter les mots de passe lorsque ce sera possible. Notez que même si ceci n'est "qu'une autre couche de sécurité", beaucoup de mots de passe de 1 à 8 caractères peuvent être craqués en moins de quelques heures, et il y a souvent d'autres informations intéressantes non cryptées dans le configfile (comme link::password-connect).

8.4 Problèmes liés aux utilisateurs

Tout comme beaucoup des choses dites ici, ceci n'est pas spécifique à UnrealIRCd, mais ...
Choisissez toujours bien vos opers et admins. Et rappelez-vous le concept du maillon faible. Même si vous êtes prudents et suivez la documentation, peut-être qu'un de vos amis oper fera quelque chose de stupide. Comme partager son disque dur via netbios/kazaa/morpheus/..., avoir un trojan, utiliser un mauvais mot de passe, etc etc ... Malheureusement, ce n'est pas toujours sous votre contrôle.

8.5 SSL/SSH & sniffing

Utilisez des connections SSL entre les serveurs et pour les opers, cela vous protègera cointre le "sniffing". Le sniffing est possible si quelqu'un attaque un serveur entre vous et votre serveur ircd, il pourra voir tout votre traffic qui passe par ce serveur; lire les conversations, récupérer les mots de passe (les logins oper, nickserv, etc ...) ... Pour les mêmes raisons, utilisez toujours ssh à la place de telnet.

8.6 Denial of Service attacks (DoS) [ou: comment protéger mon hub]

Beaucoup de réseaux ont expérimenté combien était "fun" un flood ou une (D)DoS attaque, vous pouvez toutes fois faire certaines choses permettant d'en réduire les dommages. La plupart des réseaux ont un serveur hub, ce que certaines personnes oublient, c'est qu'il est assez facile de protèger le hub contre des attaques.
Je vais l'expliquer ici :
1. Choissisez pour le hub un hostname qui n'existe pas (ex. : hub.yournet.com), mais n'ajoutez
pas un enregistrement de dns pour lui.
De cette manière, un attaquant ne pourra résoudre ni resoudre son host, ni le flooder.
Ensuite, linkez vos serveurs au hub en spécifiant l'ip ou un hostname non publique
Exemple 1: link visibiblename.yournet.com { hostname 194.15.123.16; [etc] };.
Exemple 2: link visibiblename.yournet.com { hostname thehostnamethatworks.yournet.com; [etc] };.
Remarque : pour le dernier exemple, vous devez être sûr que votre nom de serveur ne permet pas de zones de transfert, mais ceci nous éloigne du sujet.
2. Une autre étape importante est alors de cacher "/stats c" et autres informations "stats" sinon les attaquants
pourront simplement lister vos links blocks. Si vous êtes paranoyaque,vous pouvez simplement faire :
set { oper-only-stats "*"; }; pour restreindre l'utulisation de tous les /stats.
Si vous ne voulez pas cela, cachez seulement "CdDlLXz". Vous en verrez plus sur ce sujet dans la section suivante.
Évidemment, ces étapes sont moins utiles si elles sont appliquées ultérieurement (ex.: après quelques mois)
Au lieux de dès le début puisque l'IP peut déjà être connu de quelqu'un de malveillant, jusqu'à ... Ça vaut la peine de le faire.
Notez aussi que les attaquants peuvent toujours flooder les serveurs qui ne sont pas des Hubs,
mais cela demande plus d'efforts que juste attaquer 1 ou 2 points faibles (les hubs), aussi de cette manière vos hubs et services resteront saufs :).

8.7 Conseil sur la divulgation d'informations

STATS
La commande /stats fournit beaucoup d'informations, vous voulez probablement restreindre son usage le plus possible. Une question que vous devez vous poser est "Qu'est ce que je veux que mes utilisateurs voient ?". La plupart des gros réseaux choisissent "rien", lorsque d'autres préfèrent que leurs clients puisse faire "/stats g" et "/stats k".
Je vous suggère d'utiliser set { oper-only-stats "*"; }; pour empêcher tous /stats pour les non-opers, mais si vous ne voulez pas cela, inspectez la liste des "/stats" et empèchez l'accès à tous ce que vous voulez... (en cas de doute, empècher... Pourquoi auraient-ils besoin de savoir cela ?
Pour vous donner quelques exemples :
- /stats o: vous donne le noms des opers (avec la 'case' correcte) et leurs hostmasks.
- /stats c: vous donne une idée des links et qui peut être utilisée comme backup, etc ...
- /stats g, /stats k: en général utilisés pour bannir les proxys ... donc cela donnera juste aux attaquants une liste de proxys qu'ils peuvent utiliser.
- /stats E, /stats e: informations plut sensibles, spécialement si un attaquant peut utiliser ces adresses.
- /stats i, /stats y: peut aider un attaquant à trouver des hosts permettant beaucoup de connections.
- /stats P: aide à trouver des ports serveronly
etc etc...
MAP / LINKS
Beaucoup de personnes ont demandé si il était possible de désactiver /map ou /links. Notre position sur ce sujet est que c'est bête et donne un mauvais sens à la sécurité, laissez moi vous expliquer... Cacher les serveurs sur lesquels les utilisateurs sont connectés est inutile vu qu'ils les connaissent déjà (sinon comment s'y seraient-ils connectés ?). Pour les serveurs sur lesquels vous ne voulez aucuns utilisateurs, reportez vous à la section 8.6.
Maintenez, que POUVEZ vous faire ? Depuis la version 3.2.1, il existe une option appelée 'flat map' (set::options::flat-map), cela fera apparaître tous les serveurs comme 'directement connectés' dans /map et /links, comme cela les utilisateurs ne sauront plus voir quel serveur est lié au quel... Ca peut être une bonne couche supplémentaire de protection car ainsi une personne ne pourra pas repérer les 'points faibles' avec /map ou /links. Donc, utiliser cela est recommandé. Notez que cela n'élimine pas totalement les risques... Si un split arrive, quelqu'un peut toujours voir quel serveur est linké auquel, et ceci est aussi valable pour d'autres choses.
UTILISATEURS NORMAUX ET SNOMASKS
Une chose qui n'est pas toujours connues est que les utilisateurs normaux peuvent également s'appliquer certains snomask limités, appelé +s +sk. Grâce à cela, ils peuvent voir des choses comme les rehashes, l'identification d'opers, les kills et d'autres messages variés.
Pour désactiver cela, vous pouvez utiliser set::restrict-usermodes comme ceci : set { restrict-usermodes "s"; };.
Évidement tout ceci n'est que de la "dissimulation d'informations", ce n'est pas de la "vraie" sécurité. Cela rendra plus difficiles / importants les efforts requis pour attaquer / pirater.

8.8 Se protéger des exploits

Il y a des patches de kernel qui rendent plus difficiles les stack- et heap-based exploits. Cela ne devrait pas être votre principal point d'inquiétude, vous avez des risques de loin plus importants d'être attaqué par d'autres points que celui-ci... Pour des raisons variées.
Il y a en tout cas une chose que vous devez faire, qui est TOUJOURS UTILISER LA DERNIÈRE VERSION, inscrivez vous à la unreal-notify mailinglist tout de suite et vous recevrez les annonces de release (la unreal-notify est pour les annonces de release uniquement, d'où seulement 1 mail tout les X mois). En général il est explicitement mentionné dans l'annonce si la release permet de fixer (de hauts risques) de sécurité.

8.9 Conclusion

Comme vous l'aurez je l'espère maintenant compris, vous ne pouvez jamais être 100% sécurisé. Vous (et nous) devons trouver et éliminer toutes les failles car un attaquant a juste besoin de trouver une faille sur un serveur. Tout ce qui a été expliqué ici DOIT de toutes façons aider à minimiser les risques considérablement. Prenez le temps de sécuriser votre réseau et éduquer vos opers. Beaucoup de personne ne prennent pas attention à la sécurité, jusqu'à ce qu'ils se fassent attaquer, essayez d'éviter ca :).

9 – Foire aux Questions (FAQ)

La FAQ est disponible en ligne ici