English | German | Hungarian | French | Russian | Turkish | Spanish
UnrealIRCd
http://www.unrealircd.com
Version: 3.2.10.1
Letztes Update dieses Handbuchs: 2009-12-24
Head Coders: Stskeeps / codemastr / Syzop / Luke/ aquanight / WolfSage
Contributors: McSkaf / Zogg / NiQuiL / assyrian / chasm / DrBin / llthangel / Griever / nighthawk
Dokumentation: CKnight^ / Syzop
Deutsche Übersetzung: LowDigit / Orginalübersetzung: stylus740

Um diese Dokumentation zu lesen, ist einer der unten aufgeführten kompatiblen Browser erforderlich. Aktuelle Dokumentationen sind erhältlich @ http://www.vulnscan.org/UnrealIRCd/unreal32docs.html und eine FAQ @ http://www.vulnscan.org/UnrealIRCd/faq/.

Kompatible Browser:

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

INHALTSVERZEICHNIS
1. Einführung & Anmerkungen
---1.1. Anmerkungen zu Upgrade/Mixing 3.1.x -> 3.2
---1.2. Anmerkungen zu Upgrade von 3.2 Versionen
2. Installation
3. Features
-- 3.1. Cloaking
-- 3.2. Module
-- 3.3. Snomasks
-- 3.4. Aliases
-- 3.5. Helpop
-- 3.6. Oper Zugriffs-Levels
-- 3.7. Oper Befehle
-- 3.8. SSL
-- 3.9. IPv6
-- 3.10. Zip Links
-- 3.11. Dynamische DNS/IP Link Unterstützung
-- 3.12. Anti-Flood Features
-- 3.13. Bann Typen
-- 3.14. Spamfilter
-- 3.15. CIDR
-- 3.16. Nick Zeichensätze
-- 3.17 CGI:IRC Unterstützung
-- 3.18 Zeitsynchronisation
-- 3.19. Andere Features
4. Konfiguration der unrealircd.conf Datei
---4.1. Erklärung der Konfigurationsdatei
---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 Anweisung
---4.10. Loadmodule Anweisung
---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. Cgiirc Block
---4.37. Set Block -=- (networks/unrealircd.conf)
---4.38. Files Block
5. Additional Files
6. User & Channel Modi
7. User & Oper Befehlsliste
8. Sicherheitstipps/Checkliste
---8.1. Passworte
---8.2. Nicht IRCD betreffende Angriffsmöglichkeiten
---8.3. Berechtigungen und Config Datei
---8.4. User bezogene Probleme
---8.5. SSL/SSH & Sniffing
---8.6. Denial of Service Angriffe (DoS) [oder: wie schütze ich meinen Hub]
---8.7. Informationsbeschaffung
---8.8. Schutz gegen Exploits
---8.9. Zusammenfassung
9. Frequently Asked Questions (FAQ)
A. Reguläre Ausdrücke
---A.1. Literale
---A.2. Punkt Operator
---A.3. Wiederholungs Operatoren
---A.4. Klammer Ausdrücke
---A.5. Assertions
---A.6. Alternation
---A.7. Unterausdrücke
---A.8. Rückverweise
---A.9. Gross- und Kleinschreibung

1.0 – Einführung & Anmerkungen

Diese Anleitung wurde exklusiv zur Verwendung von UnrealIRCd geschrieben. Die Verwendung des Textes mit anderer Software oder das Anbieten zusammen mit anderer Software ohne schriftliche Genehmigung des UnrealIRCd Entwicklungsteams ist streng verboten. Solange es der Benutzung von UnrealIRCd dient, darf dieses Dokument beliebig kopiert/gedruckt/veröffentlicht, jedoch nicht verändert werden. – Copyright UnrealIRCd Development Team 2002-2006

Bitte lesen Sie diese Anleitung, bevor Sie um Hilfe bitten und schauen Sie WIRKLICH erst einmal in die FAQ, da rund 80% der Fragen dort beantwortet sind. Hilft dies alles nicht, kann bzgl. Support bei irc.unrealircd.org (Port 6667) im Channel #unreal-support nach Unterstützung gefragt werden (Wir erwarten UNBEDINGT, dass zuvor Dokumentation und FAQ gelesen wurden und wir helfen nur zu UnrealIRCd, nicht zu Services!). Ebenso können Sie das Forum nutzen, welches über http://forums.unrealircd.com erreichbar ist. Im Falle eines echten Bugs (z.B. einem Crash) bitte Nachricht an http://bugs.unrealircd.org.

1.1 – Anmerkungen zu Upgrade/Mixing 3.1.x -> 3.2

Bei einem Upgrade von Unreal3.1.x auf Unreal3.2 wird als erstes die völlig veränderte Konfigurations- Datei auffallen. Anfänglich ist dies eine große Umstellung, aber nachdem man erst einmal umgestellt hat, wird man feststellen, dass die neue Form viel besser ist!

Nicht vergessen, im Teil 3 über neue Features nachzulesen! Auch wenn einige Features aus früheren Versionen bekannt sind, finden sich hier auch eine Reihe neuer Features!

Am besten verzichtet man auf mischen/linken von 3.1.x mit 3.2, aber wenn das doch gewollt ist, wird mindestens 3.1.4 benötigt. Jedoch wird Version 3.1.5.1 unbedingt empfohlen.

1.2 – Anmerkungen zu Upgrade von 3.2 Versionen

Der empfohlene Weg für ein Upgrade ist:
Linux:

- Altes UnrealIRCd Verzeichnis umbenennen (ansonsten wird es im nächsten Schritt überschrieben)
- Neue UnrealIRCd Version entpacken und "./Config" und "make" laufen lassen (*NIX).
- Alte Konfigurationsdateien in das neue Verzeichnis kopieren (unrealircd.conf, motd, rules, server.* [SSL certs], network file, etc)

Windows:

- Alle Konfigurationsdateien in einen temporären Ordner kopieren.
- Die Deinstallation des vorhandenen Unreal starten.
- Den Installer für den neuen Unreal starten.
- Die alten Config Files in den neuen Ordner kopieren.

Bitte auch die RELEASE.NOTES lesen und ggf. jede Changes Datei um zu sehen, was sich geändert hat. Falls Änderungen (oder Bugs) zwischen Versionen festgestellt werden, AUF JEDEN FALL ERST IN DIESEN DATEIEN NACHLESEN bevor ein Bug gemeldet wird!

2.0 - Installation

Getestete & unterstützte Betriebs Systeme:

- *NIX Versionen:
  - Linux (2.2.*, 2.4.*, 2.6.*)
  - FreeBSD (4.*, 5.*, 6.*)
  - NetBSD (2.*)
  - OpenBSD (3.7, 3.8, 3.9)
  - Solaris (9,10)
- Windows Versionen:
  - Windows XP (Home, Pro)
  - Windows 2003
  - Windows 7
- Getestete Architektueren (Prozessoren):
  - ia32 (i386, i486, i586, i686)
  - ia64
  - amd64
  - alpha

Im Falle, dass Unreal3.2 korrekt unter anderen Betriebssystemen läuft, bitte Details an coders@lists.unrealircd.org senden.

Installationsanleitungen
Linux:

1. gunzip -d Unreal3.2.X.tar.gz
2. tar xvf Unreal3.2.X.tar
3. cd Unreal3.2
4. ./Config
5. Die hierbei angezeigten Fragen nach bestem Wissen beantworten. Allgemein ist es empfehlenswert, bei Unsicherheiten den Default zu belassen.
6. make
7. Nun die eigene unrealircd.conf und die anderen Konfigurationsdateien erstellen, siehe Teil 4.

Windows:

1. Den Unreal Installer starten
2. Nun die eigene unrealircd.conf und die anderen Konfigurationsdateien erstellen, siehe Teil 4.

3.0 - Features

In diesem Abschnitt werden einiger der größeren besonderen Features erläutert. Es wird ein genereller Überblick gegeben, in dem sich manchmal auf die .conf Datei bezogen wird (die Neuanfängern momentan noch unbekannt sein dürfte).

Dieser Abschnitt kann auch übersprungen werden, obwohl es sinnvoll ist ihn vor oder nach der Installation zu lesen, weil man ansonsten Konzepte wie cloaking, snowmask etc. nicht verstehen wird..

3.1 - Cloaking

Das Cloaking ist eine Möglichkeit, den echten Hostnamen vor Usern zu verbergen. Wenn z.B. der echte Host d5142341.cable.wanadoo.nl lautet, wird er (in join, part, whois, etc) als rox-2DCA3201.cable.wanadoo.nl angezeigt. Das ist hilfreich, um sich davor zu schützen, dass User sich gegenseitig flooden, da sie die echte Host/IP nicht erkennen können.

Eingestellt wird dies durch den Usermode +x (also: /mode yournick +x), Admins können +x auch als Default erzwingen oder so einstellen, dass User kein -x einstellen können.

Ein durch Cloaking geschützter Host wird durch ein Cloaking Modul (wenigstens eines muss geladen sein) erzeugt. Momentan wird nur 1 solches Modul mitgeliefert:
cloak:
Hierbei handelt es sich um das neue offizielle Cloaking Modul, welches viel sicherer, als der alte Algorithmus ist. Es verwendet intern md5 und erfordert, dass 3 set::cloak-keys:: gesetzt sind, die gemischt Kleinbuchstaben (a-z), Großbuchstaben (A-Z) und Ziffern (0-9) enthalten [z.B. "AopAS6WQH2Os6hfosh4SFJHs"] . Siehe auch example.conf für ein Beispiel.

Die Keys MÜSSEN identisch auf ALLEN SERVERN im Netzwerk sein und sie sollten GEHEIM gehalten werden. Wenn jemand diese drei Keys kennt, kann er den geschützten Host erkennen und den realen Host ermitteln (was dem Usermodus +x sinnlos macht).

Tipp: Wenn man auf *NIX Systemen arbeitet und Cloak Keys neu erstellt werden müssen, kann man in der Shell eingeben: './unreal gencloak' und erhält als Ausgabe 3 zufällig erzeugte Strings, die man verwenden kann.

3.2 - Module

UnrealIRCd unterstützt Module, was sehr nützlich ist, weil:
- Module können bei laufendem ircd geladen/ersetzt/gelöscht werden (durch /rehash). Dadurch können verschiedene Bugs gefixt oder neue Module hinzugefügt werden, ohne dass ein Neustart erforderlich ist.
- Andere Entwickler können weitere Module mit neuen Befehlen oder anderen Usermodi erstellen.
UnrealIRCd selbst enthält nur wenige Module. Durch eine Suche auf www.unrealircd.com (modules) oder per Google können weitere 3rd party Module gefunden werden.

Achtung: Minimal müssen zwei Module geladen sein, oder der ircd wird nicht starten:
- das commands Modul: commands.so (oder commands.dll bei Windows)
- das cloaking Modul: üblicherweise cloak.so (oder cloak.dll bei Windows)

3.3 - Snomasks

Bei Snomasks handelt es sich um Server notice masks, eine spezielle Form der Usermodi, durch die gesteuert wird, welche Server Nachrichten man empfängt (in der Regel von Opern benutzt)

Sie können durch "/mode yournick +s SNOMASK" eingestellt werden, z.B.: /mode yournick +s +cF
(d.h. +s leitet dem Modus "snomask" ein, danach folgen die Flags)
Um aktuelle snomasks zu löschen, gibt man z.B. ein: /mode yournick +s -c
Will man sämtliche snomask Flags löschen, gibt man ein: /mode yournick -s

Momentan unterstützte snomasks Flags sind:
c - lokale Connects
F - ferne Connects (also auf anderen Servern im Netz - mit Ausnahme der U-lined Server)
f - Flood Meldungen
k - Kill Meldungen
e - 'eyes' Meldungen
j - 'junk' Meldungen
v - vhost Meldungen
G - gline/shun Meldungen
n - lokale nick Änderungs-Meldungen
N - globale nick Änderungs- Meldungen
q - deny nick (Q:line) Meldungen zu Abweisung gesperrter Nicks
s - Server Nachrichten anzeigen [*]
S - Spamfilter Nachrichten anzeigen
o - Oper-up Meldungen anzeigen
[*: Diese snomask ist auch für Nicht-IrcOps möglich]

Es kann eingestellt werden, welche snomasks man automatisch erhält (set::snomask-on-connect) und welche man als Oper erhält (set::snomask-on-oper, set::oper::snomask)

Per Default ist eingestellt, dass einem User, der einfach nur den Modus +s setzt, bestimmte Flags eingestellt werden. Für Nicht-Opers ist das die snomask +ks, und für Opers die snomask +kscfvGqo.

3.4 - Aliases

Mit Alias können serverseitig bestimmte Befehle eingestellt und dadurch vereinfacht werden. So ist es z.B. möglich, dass der Befehl "/ns identify blah" direkt an Nickserv geleitet und übersetzt wird in: "privmsg nickserv identify blah". Man kann auch recht komplexe Alias Definitionen vornehmen, die beispielsweise den Befehl /register an Chanserv weiterleitet, wenn der erste Parameter mit einem # beginnt oder an Nickserv, wenn der erste Parameter nicht mit einem # beginnt. (Im ersten Fall soll ein Channel registriert werden, im zweiten Fall ein Nickname)

Aliases werden in alias Blocks in der Konfigurationsdatei definiert oder in einer Include Datei mit den häufigsten Default Aliassen.

3.5 - Helpop

UnrealIRCd hat ein integriertes Hilfesystem, auf welches mit dem Befehl "/helpop" zugegriffen werden kann. Über den Help Block in der Konfigurationsdatei bzw. die beigefügte "help.conf" ist die anzuzeigende Hilfe völlig frei konfigurierbar. Grundlegende Hilfen sind in der mitgelieferten help.conf schon vorkonfiguriert.
Beispielsweise wird nach dem Befehl /helpop chmodes ein Überblick über sämtliche Channel Modi von UnrealIRCd angezeigt.
Zu beachten ist, dass ein ircop (helpop) vor den Suchbegriff ein '?' setzten muss, also statt /helpop ist /helpop ? einzugeben und statt /helpop chmodes ist /helpop ?chmodes einzugeben etc.. (Alternative: Vor der Abfrage das +h Flag per "/mode <nick> -h" entfernen)

3.6 - Oper Zugriffs-Levels

Es gibt verschiedene Oper Levels in UnrealIRCd und jeder Level kann um zusätzliche Rechte (wie z.B. use /gline) erweitert werden, so dass jedem Oper genau die benötigten Rechte gegeben werden können..

Gesteuert wird dies über die Oper Flags im Oper Block. (siehe oper block für weitere Informationen.)

3.7 - Oper Befehle

UnrealIRCd hat eine Reihe mächtiger Befehle für Opers, die im Abschnitt User & Oper Befehlsliste erklärt werden. Es empfiehlt sich, diese nach der Installation zu lesen :).

3.8 - SSL

SSL ist die Abkürzung für "Secure Socket Layer" und ermöglicht sichere verschlüsselte Verbindungen. Dadurch kann server<->server Traffic verschlüsselt werden, aber auch die Verschlüsselung client<->server ist möglich. Üblicherweise wird SSL als Schutz vor "Sniffing" (Abhören von Netz Traffic) und zur sicheren Authentifizierung eingesetzt.

Um das zu ermöglichen, ist es erforderlich, dass der IRC Server mit SSL Support kompiliert wird. Um einen SSL Port einzustellen, muss
"set listen::options::ssl" eingetragen sein.

Zu einem SSL Port kann nicht normal verbunden werden (also nicht den Port 6667 auf SSL einstellen!), sondern es wird ein Client oder ein Tunnel benötigt, der das SSL Protokoll unterstützt.

Diese Clients unterstützen SSL: XChat, irssi, mIRC (6.14 und höher, weitere zusätzliche Schritte erforderlich)

Für Clients, die kein SSL unterstützen, kann man einen Tunnel wie stunnel benutzen. Hier ein Beispiel für eine stunnel.conf Beispiel (für stunnel 4.x):

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

Damit wird zu 127.0.0.1 über Port 6667 verbunden, der Datenverkehr wird verschlüsselt und weitergeleitet an irc.myserv.com port 6900 (ein SSL Port).

StunTour für mIRC kann ebenfalls hilfreich sein.

Es sollten auch die Zertifikate überprüft werden, wenn man zu einem Server verbindet und diesen nicht blind vertrauen (wie im stunnel Beispiel), andernfalls ist man noch durch "active sniffing" Angriffe (ssl redirects) empfänglich. Das ist allerdings ein anderes Thema und führt zu weit von der Erklärung zum IRCd weg. Hierzu gibt es eigene Sites im Internet um das zu lernen. Nicht bei Unreal nachfragen, es hat nichts mit dem UnrealIRCd zu tun. (mIRC und XChat öffnen ein Popup Fenster und fragen nach, ob ein Zertifikat erlaubt oder zurückgewiesen wird und das ist gut!)

3.9 - IPv6

UnrealIRCd unterstützt IPv6, dass seit beta15 stabil zu sein scheint.
Das Betriebssystem muss IPv6 unterstützen und es ist erforderlich, IPv6 Unterstützung in UnrealIRCD zu aktivieren (die entsprechende Frage bei ./config mit "yes" beantworten).

Obwohl Microsoft eine experimentelle IPv6 Unterstützung in w2k/XP implementiert hat, wird diese (noch) nicht von UnrealIRCd unterstützt.

3.10 - Zip Links

Zip Links können für server<->server Verbindungen aktiviert werden. Dadurch werden die Daten durch Verwendung von zlib komprimiert und es können so 60-80% Bandbreite eingespart werden. Das ist sinnvoll für Links mit niedriger Bandbreite oder für Links mit vielen Usern und kann ein wenig beim Linken helfen, da eine Menge von Daten über jeden User und jeden Channel zu übertragen sind.

Um mit zip links Support zu kompilieren, muss die zlib Frage mit "Yes" bei ./config beantwortet werden und dieses mit link::options::zip eingetragen sein.

3.11 - Dynamische DNS/IP Link Unterstützung

UnrealIRCd hat einige (neue) Features, die es ermöglichen, dass User dynamische IP's verwenden können (wie z.B.: blah.dyndns.org). Sollen zwei Hosts mit dynamischer DNS gelinkt werden, so ist set link::options::nodnscache und link::options::nohostcheck einzutragen.

3.12 - Anti-Flood Features

Throttling
Throttling nennt man die Methode, mit der geregelt wird, wie schnell ein User die Verbindung trennen und sich erneut zum Server verbinden kann. Im "set::throttle block" kann eingestellt werden, X Verbindungen innerhalb von YY Sekunden von derselben IP zu gestatten.

Channel Modi
Weiterhin gibt es einige Channel Modi, welche sehr effektiv gegen Flood sein können. Einige davon sind:
K = no /knock (kein Anklopfen, um in Channel eingeladen zu werden), N = no nickchanges (keine Änderung der Nicknamen möglich), C = no CTCPs (keine CTCP möglich), M = nur registrierte User können schreiben, j = join throttling (Beschränkung der Joins je User)
Seit der Beta 18 gibt es zusätzlich noch den erweiterten Modus +f...
Channel mode f
Um nicht Scripts und Bots zum Schutz gegen Channel Flood benutzen zu müssen, ist der notwendige Schutz nun im IRCd integriert.
Ein Beispiel für den +f Modus ist: *** Blah sets mode: +f [10j]:15
Das bedeutet, dass 10 joins innerhalb von 15 Sekunden im Channel gestattet sind. Wird dieser Wert überschritten, wird der Channel automatisch auf +i eingestellt.

Für folgende Flood Arten stehen Aktionen zur Verfügung:

Typ: | Name: | Default Action: | mögliche weitere Actions: | Kommentar
c | CTCPs | auto +C | m, M |
j | joins | auto +i R |  |
k | knocks | auto +K |  | (nur für lokale Clients)
m | messages/notices | auto +m | M |
n | nickchanges | auto +N |  |
t | text | kick | b | in messages/notices wie das alte +f. Kickt oder bannt User.

Beispiel:
*** 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
Das Ganze kann noch erweitert (damit aber auch komplizierter) werden:
Anstelle der Default Aktion kann für einige Flood Typen auch eine andere Aktion gewählt werden, wie z.B.: +f [20j#R,50m#M]:15
Dieser Channel wird auf +R gestellt, wenn das Join-Limit erreicht ist (>20 Joins in 15 Sekunden), und wird auf +M gesetzt, wenn das Msg Limit erreicht ist (>50 Nachrichten in 15 Sekunden).
Zusätzlich gibt es eine "Lösche nach X Minuten" Einstellung: +f [20j#R5]:15 setzt den Channel auf +R, wenn das Limit erreicht wird und nach 5 Minuten wieder auf -R.
Ein Server kann eine Default Unset-Zeit haben (set::modef-default-unsettime), die bewirkt, dass eine Angabe von +f [20j]:15 automatisch in +f [20j#i10]:15 umgewandelt wird. Es handelt sich hierbei lediglich um einen Default und man kann weiterhin auch andere Angaben wie [20j#i2]:15 setzen. Ebenso kann man den Lösch Channel Modus auch ganz abschalten, indem man +f [20j#i0]:15 angibt (also explizit den Wert 0 setzt).
Der alte +f Modus (messageflood per User) ist weiterhin vorhanden, allerdings als 't'. Der Eintrag +f 10:6 lautet nun +f [10t]:6 und
+f *20:10 ist jetzt +f [20t#b]:10. Aktuell wird der ircd alte +f Modi automatisch in die neuen Modi umwandeln. Zu beachten ist, dass es keine Unsettime Einstellung für 't' Banns gibt. ([20t#b30]:15 funktioniert nicht!).
Was der beste +f Modus ist, hängt vom jeweiligen Channel ab. Wie viele User hat der Channel? Läuft möglicherweise ein Spiel in dem Channel, welches viele längere Messages erfordert? Handelt es sich um einen Hauptchannel, möglicherweise mit auto-join? Das, was in dem einen Channel Flood ist, kann in einem anderen völlig normal sein...
Es gibt also keinen perfekten Channelmodus +f, der für alle Channels geeignet ist. Aber für den Anfang seien hier einige Beispiele gegeben, die man auf die eigenen Bedürfnisse anpassen kann:
+f [30j#i10,40m#m10,7c#C15,10n#N15,30k#K10]:15
30 Joins pro 15 Sekunden, bei Erreichen des Limits wird der Channel für 10 min auf +i gesetzt
40 Messages pro 15 Sekunden, bei Erreichen des Limits wird der Channel für 10 min auf +m gesetzt
7 CTCP pro 15 Sekunden, bei Erreichen des Limits wird der Channel für 15 min auf +C gesetzt
10 Nickänderungen pro 15 Sekunden, bei Erreichen des Limits wird der Channel für 15 min auf +N gesetzt
30 Knocks pro 15 Sekunden, bei Erreichen des Limits wird der Channel für 5 min auf +K gesetzt
In bestimmten größeren Channels (>75 User?) sollte man die Join Grenze erhöhen (auf z.B.: 50) und auch das Message Limit (z.B. 60 oder 75).
Speziell die Lösch-Modi erfordern viel Feinabstimmung. Man sollte bedenken, was passiert, wenn kein Op anwesend ist, der eine Situation regulieren kann. Soll ein Channel 15 Minuten gesperrt sein (nicht so schön für die User)? Oder nur 5 Minuten (dann warten Flooder möglicherweise 5 min um dann erneut zu flooden)? Das hängt auch vom Typ des Floods ab. Es beeinträchtigt User mehr, wenn sie nicht joinen können (+i) oder nicht schreiben können (+m) als wenn sie keinen Nick ändern können (+N) oder keine CTCP senden können (+C). Es sollten daher unterschiedliche Zeiten für das Löschen der Modi angegeben werden.

Channel mode j
Der +f Modus enthält ein Feature, um join Floods zu vermeiden, allerdings ist dieses Feature "global." Lautet z.B. die Einstellung 5:10 und 5 verschiedene User joinen in 10 Sekunden, spricht der Flood Schutz an. Der Channel Mode +j arbeitet anders. Dieser Modus arbeitet auf einer pro User Basis. Anders als Join Floods wirkt er gegen join-part Floods (eine Art ständig sich wiederholendes rein - raus). Der Modus benötigt einen Parameter in der Form X:Y, wobei X die Anzahl der Joins und Y die Anzahl der Sekunden ist. Überschreitet ein User dieses Limit, wird er für diesen Channel gesperrt und kann nicht mehr joinen.

3.13 - Bann Typen

Einfache Bann-Typen und verdeckte Hosts
UnrealIRCd unterstützt die einfache Bann Form: +b nick!user@host.
Angenommen, der verdeckte Host von jemandem ist 'rox-ACB17294.isp.com' und es wird ein Bann auf *!*@rox-ACB17294.isp.com gesetzt, dann wird auch, wenn der User sich selbst -x setzt (und sein Host z.B. zu 'dial-123.isp.com' wird), der Bann weiterhin gelten. Banns werden immer sowohl gegen reale Hosts UND verdeckte Hosts geprüft.
Auch IP Banns (z.B.: *!*@128.*) sind möglich und werden ebenso immer geprüft.
Banns auf verdeckte IPs erfordern einige Erklärungen:
Angenommen, ein User hat die IP 1.2.3.4, dann könnte sein verdeckter Host '341C6CEC.8FC6128B.303AEBC6.IP' sein.
Wenn man auf '*!*@341C6CEC.8FC6128B.303AEBC6.IP' einen Bann setzt, bannt man '*!*@1.2.3.4' (einleuchtend...)
Wenn man auf '*!*@*.8FC6128B.303AEBC6.IP' einen Bann setzt, bannt man '*!*@1.2.3.*'
Wenn man auf '*!*@*.303AEBC6.IP' einen Bann setzt, bannt man '*!*@1.2.*'
(Die "Stelle" in der verdeckten IP ist also genau anders herum, wie in der realen IP)
Diese Information könnte hilfreich sein, wenn man entscheidet, wie breit eine Maske sein soll.
Erweiterte bann Typen
Erweiterte Bann Typen sind so aufgebaut: '~[!]<type>:<stuff>'. Gegenwärtig gibt es folgende Typen:

Typ | Name | Erklärung
~q | quiet | User, auf die dieser Bann gesetzt ist, können joinen, aber nicht schreiben, solange sie nicht +v oder höher haben. Beispiel: ~q:*!*@blah.blah.com
~n | nickchange | User, auf die dieser Bann gesetzt ist, können ihre Nicks nicht ändern, solange sie nicht +v oder höher haben. Beispiel: ~n:*!*@*.aol.com
~c | Channel | Wenn der User in diesem Channel ist, kann er nicht joinen. Beispiel: ~c:#lamers. Es kann hier auch ein Prefix (+/%/@/&/~) angegeben werden, wodurch erreicht wird, dass dies nur für User mit diesem oder höheren Rechten im angegebenen Channel Auswirkungen hat. Beispiel: +b ~c:#lamers, +e ~c:@#trusted
~r | Realname | Wenn der Realname des Users gebannt ist, kann der User nicht joinen. Beispiel: ~r:*Stupid_bot_script* Zu Beachten: Ein Unterstrich ('_') bedeutet beides, sowohl ein Leerzeichen (' '), als auch den Unterstrich ('_') selbst. Der Bann aus dem Beispiel oben würde also 'Stupid bot script v1.4' treffen.

Diese Bann Typen werden auch in der Ausnahme Liste der Channels (channel exception list [+e]) berücksichtigt.
Ebenso können über Module andere erweiterte Bann Typen definiert werden.

3.14 - Spamfilter

Spamfilter ist ein neues System gegen Spam, Belästigungen, Würmer etc. Es arbeitet ein wenig ähnlich wie 'badwords', hat aber einige Erweiterungen..
Spamfilter werden durch den /spamfilter Befehl mit der folgenden Syntax gesetzt:
/spamfilter [add|del|remove|+|-] [type] [action] [tkltime] [reason] [regex]

[type] | gibt an, auf welchen Nachrichtentyp reagiert werden soll;
| Zeichen: | Config Eintrag | Bedeutung
| c | channel | Nachricht im Channel (öffentlich)
| p | privat | Private Nachricht (von User --> User)
| n | private-notice | Private Notiz
| N | channel-notice | Channel Notiz
| P | part | Grund Angabe beim Verlassen des Channels
| q | quit | Grund Angabe beim Beenden des Chats
| d | dcc | DCC Dateiname
| a | away | Away Meldung
| t | topic | Setzen eines Topics
| u | user | bannt User, geprüft wird auf nick!user@host:realname
| Es ist möglich, mehrere Ziele anzugeben, wie z.B.: cpNn
[action] | gibt an, welche Aktion erfolgen soll (es kann nur 1 Aktion angegeben werden)
| kill | Killt den User
| tempshun | setzt für die laufende Verbindung einen Shun auf den User (bei Reconnect ist der Shun aufgehoben
| shun | Setzt einen Shun auf den Host
| kline | Setzt eine kline auf den Host
| gline | Setzt eine gline auf den Host
| zline | Setzt eine zline auf den Host
| gzline | Setzt eine gzline (globale zline) auf den Host
| block | Blockiert lediglich die Nachricht
| dccblock | markiert den User derart, dass er nicht in der Lage ist, irgend welche DCCs zu senden
| viruschan | User wird aus allen Channels entfernt, wird in den unter set::spamfilter::virus-help-channel eingetragenen Channel geforwardet, alle Befehle außer PONG und ADMIN werden deaktiviert und msg/notices werden zum Channel aus set::spamfilter::virus-help-channel geleitet.
[tkltime] | Die Zeitdauer, die für eine durch den Filter gesetzte *line/shun gilt. Um den Default zu benutzen oder zum Übergehen (z.B. wenn action = 'block'), lediglich ein '-' eintragen,
[reason] | Der anzuzeigende Grund für Block- oder *lines/shun Befehle. Man kann hier KEINE Leerzeichen eintragen, aber Unterstriche ('_') werden zur Laufzeit in Leerzeichen umgesetzt. Ein doppelter Underscore ('__') erzeugt einen Underscore ('_') in der Ausgabe. Auch hier ein '-' eintragen, um den Default zu benutzen.
[regex] | gibt den Ausdruck oder das 'bad word' an, welches geblockt werden soll, oder worauf die Aktion erfolgen soll

Beispiele: (man beachte die Striche '-', die Default Angaben erzwingen)
/spamfilter add pc gline - - Come watch me on my webcam
Wenn der Text "come watch me on my webcam" entweder in einer priv msg oder in einer Channel Nachricht auftaucht, wird er blockiert und auf den Sender eine G-Line gesetzt.
/spamfilter add pc block - - come to irc\..+\..+
Hier wird auf Werbungen wie "Hi, come to irc.blah.net" usw. geprüft und die Nachricht wird einfach nur geblockt.
Und ein Beispiel mit time/reason:
/spamfilter add p gline 3h Please_go_to_www.viruscan.xx/nicepage/virus=blah Come watch me on my webcam
Wenn der Text "come watch me on my webcam" in einer privaten Nachricht gefunden wird, erfolgt eine G-Line für 3 Stunden mit dem Grund: "Please go to www.viruscan.xx/nicepage/virus=blah".
Spamfilter die über /spamfilter definiert werden, gelten netzweit. Sie wirken unabhängig davon, ob der User +G gesetzt hat und nur Oper und U-Lines (Services) sind von der Filterung ausgenommen.
Spamfilter können auch in der Config Datei eingetragen sein, doch sie sind dann nur lokal für den Server, auf dem sie eingetragen sind (also nicht netzweit), gültig. Die Syntax dieser spamfilter { } Blöcke wird hier erklärt:
Beispiel:

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

set::spamfilter::ban-time ermöglicht die Festlegung einer Default Bann Dauer für *lines/shuns, die durch den Spamfilter gesetzt wurden (default: 1 Tag)
set::spamfilter::ban-reason ermöglicht die Festlegung eines Grundes für die *lines/shuns (Default: 'Spam/advertising'). Mehrere Worte sind durch Underscores ("_") und nicht durch Leerzeichen zu trennen.
set::spamfilter::virus-help-channel ermöglicht die Angabe eines Channels, in den bei der Action 'viruschan' gejoined wird (Default: #help)
set::spamfilter::virus-help-channel-deny ermöglicht es, normale Joins in den virus-help-channel zu blockieren (Default: no)

Erkennung langsamer Spamfilter
Ein Spamfilter Ausdruck (regex) kann einen IRCd beträchtlich verlangsamen. Das hängt davon ab, welcher Ausdruck verwendet wird (und wie dieser Ausdruck ausgewertet wird). Einige Spamfilter Ausdrücke sind sehr schnell und UnrealIRCd kann Tausende von ihnen pro Sekunde verarbeiten. Andere können extrem langsam sein und mehrere Sekunden für die Ausführung benötigen und dadurch den IRCd regelrecht einfrieren..
Zur Unterstützung gegen dieses Problem stellt Unreal eine Erkennung langsamer Spamfilter ('Slow Spamfilter Detection' bereit: Für jeden Spamfilter wird bei jeder Ausführung die hierzu benötigte Zeit überprüft. Wird ein bestimmter Grenzwert erreicht, warnt der IRCd oder entfernt einfach diesen Spamfilter.
Warnungen werden durch set::spamfilter::slowdetect-warn konfiguriert (Default: 250ms) und die automatische Löschung durch set::spamfilter::slowdetect-fatal (Default: 500ms). Man kann beide Werte auf 0 setzen um die Erkennung langsamer Spamfilter zu deaktivieren.
Dieses Feature steht unter Windows derzeit noch nicht zur Verfügung.

3.15 - CIDR

UnrealIRCd unterstützt nun auch CIDR (Classless Interdomain Routing). CIDR ermöglicht es, IP Bereiche zu bannen. IPs werden an Internet Service Provider (ISP) unter Verwendung von CIDR vergeben. Daher ist es möglich unter Verwendung eines CIDR basierten Banns auf einfache Weise ganze ISPs zu sperren. Unreal unterstützt CIDR sowohl für IPv4 als auch für IPv6. CIDR Masken können benutzt werden bei: allow::ip, oper::from::userhost, ban user::mask, ban ip::mask, except ban::mask, except throttle::mask, und except tkl::mask (für gzline, gline, and shun). Zusätzlich kann CIDR bei /kline, /gline, /zline, /gzline, und /shun benutzt werden. Unreal verwendet die Standard Syntax von IP/bits, z.B. 127.0.0.0/8 (passt auf 127.0.0.0 - 127.255.255.255), und fe80:0:0:123::/64 (passt auf fe80:0:0:123:0:0:0:0 - fe80:0:0:123:ffff:ffff:ffff:ffff).

3.16 - Nick Zeichensätze

UnrealIRCd bietet die Möglichkeit, festzulegen, welche Zeichensätze/Sprachen in Nicknamen gestattet sein sollen. Dies wird festgelegt in set::allowed-nickchars.
Hier eine Liste der möglichen Einstellungen:

Name: | Beschreibung: | Character set/encoding:
catalan | Katalanische Zeichen | iso8859-1 (latin1)
danish | Dänische Zeichen | iso8859-1 (latin1)
dutch | Niederländische Zeichen | iso8859-1 (latin1)
french | Französische Zeichen | iso8859-1 (latin1)
german | Deutsche Zeichen | iso8859-1 (latin1)
swiss-german | Schweiz-Deutsche Zeichen (kein 'ß') | iso8859-1 (latin1)
icelandic | Isländische Zeichen | iso8859-1 (latin1)
italian | Italienische Zeichen | iso8859-1 (latin1)
spanish | Spanische Zeichen | iso8859-1 (latin1)
swedish | Schwedische Zeichen | iso8859-1 (latin1)
latin1 | katalanisch, dänisch, niederländisch, französisch, deutsch, schweizer deutsch, spanisch, isländisch, italienisch, schwedisch | iso8859-1 (latin1)
hungarian | Ungarische Zeichen | iso8859-2 (latin2), windows-1250
polish | Polnische Zeichen | iso8859-2 (latin2)
romanian | Rumänische Zeichen | iso8859-2 (latin2), windows-1250, iso8859-16
latin2 | ungarisch, polnisch, rumänisch | iso8859-2 (latin2)
polish-w1250 | Polnische Zeichen, Windows Variante (leider mehr allgemein, als iso) | windows-1250
slovak-w1250 | Slowakische Zeichen, Windows Variante | windows-1250
czech-w1250 | Tschechische Zeichen, Windows Variante | windows-1250
windows-1250 | polnisch-w1250, slowakisch-w1250, tschechisch-w1250, ungarisch, rumänisch | windows-1250
greek | Griechische Zeichen | iso8859-7
turkish | Türkische Zeichen | iso8859-9
russian-w1251 | Russische Zeichen | windows-1251
belarussian-w1251 | Belarussische Zeichen | windows-1251
ukrainian-w1251 | Ukrainische Zeichen | windows-1251
windows-1251 | russisch-w1251, belarussisch-w1251, ukrainisch-w1251 | windows-1251
hebrew | Hebräische Zeichen | iso8859-8-I/windows-1255
chinese-simp | Einfaches Chinesisch | Multibyte: GBK/GB2312
chinese-trad | Traditionelles Chinesisch | Multibyte: GBK
chinese-ja | Japanisch Hiragana/Pinyin | Multibyte: GBK
chinese | chinese-* | Multibyte: GBK
gbk | chinese-* | Multibyte: GBK

Anmerkung 1: Zu beachten ist, dass einige Kombinationen Probleme verursachen können. Beispielsweise kann eine Kombination aus latin* und chinesisch-* nicht korrekt von IRCd behandelt werden und es wird ein Fehler angezeigt. Das Mischen von Zeichensätzen kann der Grund von Anzeige Problemen sein. Aus diesem Grund wird Unreal eine Warnung anzeigen, wenn versucht wird, latin1/latin2/greek oder andere inkompatibele Gruppen zu mischen.
Anmerkung 2: Die Übereinstimmung von Zeichen, also welcher Großbuchstabe zu welchem Kleinbuchstaben gehört, erfolgt nach dem US-ASCII, was bedeutet, dass ö und Ö nicht als 'gleiches Zeichen' erkannt werden und deswegen jemand beispielsweise den Nick Bär haben kann, während jemand anderes gleichzeitig den Nick BÄr hat. Das ist eine Einschränkung durch das aktuelle System und IRCd Standards, die nicht binnen kurzer Zeit gelöst werden können. Den Usern sollte diese Einschränkung klar sein. Zu beachten dabei ist, dass es diese Einschränkung schon immer bei den Channelnamen gegeben hat, in denen ja fast alle Zeichen erlaubt sind und schon immer die US-ASCII Regeln der Zeichenübereinstimmung gegolten haben.
Anmerkung 3: Die Basis Nick Zeichen (a-z A-Z 0-9 [ \ ] ^ _ - { | }) sind immer erlaubt/aktiviert.
Beispiel 1, für West-Europäer:
set { allowed-nickchars { latin1; }; };
Beispiel 2, wenn man überwiegend chinesische User hat und normale chinesische Schriftzeichen gestatten will:
set { allowed-nickchars { chinese-simp; chinese-trad; }; };

3.17 - CGI:IRC Unterstützung

UnrealIRCD unterstützt eine CGI:IRC Host Manipulation. Das bedeutet: Man kann bestimmte CGI:IRC Gateways als "trusted" ("vertraut") festlegen, wodurch der IRCd veranlasst wird, statt Host/IP des CGI:IRC Gatewäys überall im IRC die reale Host/IP des Users anzuzeigen.

Nähere Informationen, wie dies konfiguriert wird, stehen im cgiirc Block

3.18 - Zeitsynchronisation

Es ist für die IRC Server sehr wichtig, immer die korrekte Zeit eingestellt zu haben. Ohne korrekte - insbesondere unterschiedliche Zeit zwischen Servern - können Channel desynchronisieren (auf verschiedenen Servern wird etwas anderes im gleichen Channel angezeigt), ahnungslose User grundlos gekillt werden, Channels gar nicht oder falsch in der /List Anzeige eingetragen sein. Kurzum: es entstehen sehr große Probleme.´

UnrealIRCd hat eine eine Unterstützung zur Zeitsybchronisation integriert. Obwohl sie nicht optimal ist (die Zeiten können weiterhin um wenige Sekunden differieren), sollten damit die meisten Zeitunterschiede beseitigt werden. Soweit möglich ist es weiterhin empfehlenswert, eine Zeitsynchronisations Software wie 'ntpd' auf *NIX Systemen oder den Zeit Synchonisations Service von Windosws laufen zu haben. In diesem Fall kann man die Unreal Zeitsynchronisation abschalten. (mehr dazu später)

Per Default versucht UnrealIRCd beim Start einen Versuch der Zeitsynchronisation. Es werden hierzu einige Anforderungen an Zeitserver gesendet und sobald die erste (schnellste) Antwort empfangen wird die interne IRCD Uhr (NICHT die Systemuhr) danach eingestellt. Wenn aus irgendwelchen Gründen nicht binnen 3 Sekunden eine Zeitabfrage beantwortet wird, startet der IRCD ohne Zeitsynchronisation (sollte nur selten passieren).

Zeitsynchronisation wird im set::timesynch Block konfiguriert (oder abgeschaltet). Siehe in der Set-Block Beschreibung für weitere Informationen.

3.18 - Andere Features

UnrealIRCd hat eine Reihe weiterer Features, die hier nicht alle einzeln aufgeführt sind. Man wird sie während der Konfiguration selbst herausfinden ;)

4.0 - Konfiguration der unrealircd.conf

Beim ersten Mal wird das Erstellen einer guten unrealircd.conf Datei eine gewisse Zeit in Anspruch nehmen - je nach Vorerfahrung etwa 15 - 60 Minuten. Eine gute unrealircd.conf zu erstellen, wird bedeutend länger dauern. Man sollte nicht hetzen, um den IRCd rasch gestartet zu bekommen, sondern lieber Schritt für Schritt vorangehen. Im Falle auftretender Probleme zuerst die Syntax überprüfen, diese Anleitung und auch die FAQ bevor man nach Hilfe fragt oder einen Bug meldet.

4.1 Erklärung der Konfigurationsdatei

Das neue System benutzt ein Block-basiertes Format. Jeder Eintrag, also jeder Block, in der neuen Form hat ein spezielles Format, welches etwa so aussieht:

    <block-name> <block-value> {
    	<block-directive> <directive-value>;
    };

<block-name> ist der Typ des Blocks wie z.B. "me", oder "admin".
<block-value> gibt bei einigen Typen einen notwendigen Wert an, wie z.B. "/oper login", oder in anderen Fällen einen Untertyp wie in "ban user".

<block-directive> ist eine speziell auf den Block bezogene Variable
<directive-value> ist der zugewiesene Wert. Falls <directive-value> Leerzeichen oder Kommentarzeichen enthält, muss die Abgabe von Anführungszeichen eingeschlossen sein. Soll das Anführungszeichen ebenfalls Bestandteil des Eintrags sein, muss im das Zeichen "\" vorangestellt werden, damit es als Anführungszeichen erkannt wird.

Innerhalb von <block-directive> können Anweisungen stehen, die dann mit geschweiften Klammern "{ }" eingeschlossen sind. Einige Blöcke haben keine Anweisungen sondern lediglich eine <block-value> Angabe, wie z.B. "include". Ebenso ist zu beachten, dass es kein spezielles Einstellungsformat gibt. Ein Block kann also in einer einzigen Zeile angegeben werden oder in mehreren Zeilen. Normalerweise wird das oben angegebene Format benutzt, welches leicht zu lesen ist und auch in der mitgelieferten unrealircd.conf benutzt wird.

Achtung: Die Konfigurationsdatei ist derzeit "case sensitive", daher ist "BLOCK-NAME" nicht dasselbe wie "block-name". Es gibt eine spezielle Notation wie Einträge in der Konfigurationsdatei als Beschreibung angegeben werden. Spricht man z.B. über "<directive-name>" im obigen Beispiel, so wird angegeben "<block-name>::<block-directive>" (also zwei Doppelpunkte dazwischen), und falls die Anweisung einen Unterblock hat, auf den sich bezogen wird, würde ein weiteres Paar "::" hinzugefügt, gefolgt vom Namen der Unteranweisung.

Bei einer Anweisung ohne Namen wird "<block-name>::" gesagt, was einfach nur "<block-value>" bedeutet, oder es könnte ein Eintrag in einem Unterblock sein, der keinen Namen hat.

Es gibt drei Arten von Kommentaren::

# Ein-Zeilen Kommentar
// Ein-Zeilen Kommentar
/* Kommentar
über mehrere
Zeilen */

Nachdem nun klar ist, wie das funktioniert, sollte man die doc/example.conf in das UnrealIRCd Verzeichnis kopieren (z.B.: /home/user/Unreal3.2) und in unrealircd.conf umbenennen. (Oder man erstellt eine unrealircd.conf und kopiert sich die entsprechenden Blöcke und editieret sie). Es ist empfehlenswert, sich Schritt für Schritt durch alle Blöcke und diese Anleitung als Referenz durchzuarbeiten.

4.2 - Me Block ERFORDERLICH (Früher bekannt als M:Line)

Syntax:

me {
name <Name-des-Servers>;
info <Server-Beschreibung>;
numeric <Server-Nummer>;
};

Diese Werte sollten klar sein. Der name gibt den Namen des Servers an (nicht dessen Internetadresse!), info eine kurze Info Zeile zur Beschreibung des Servers und numeric bedeutet eine Zahl zur Identifikation des Servers. Hierbei muss es sich um einen Wert zwischen 0 und 254 handeln, der EINMALIG im Netzwerk ist, es darf also KEIN Server im Netzwerk denselben numeric Wert haben.

Beispiel:

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

4.3 - Admin Block ERFORDERLICH (Früher bekannt als A:Line)

Syntax:

    admin {
    	<Text-Zeile>;
    	<Text-Zeile>;
    };

Im Admin Block werden die Informationen über die Serveradministration angegeben. Wenn ein User später eintippt: "/admin" (oder "/admin <servername>"), so wird ihm die hier angegebene Information dargestellt. Es können beliebig viele Zeilen eingetragen werden, die jede beliebige Information enthalten können, aber es gilt als Standard, mindestens den Nicknamen des Admins und dessen email Adresse anzugeben. Weitere Informationen können Kontakt Infos sein, die man angeben möchte.

Beispiel:

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

4.4 - Class Block ERFORDERLICH (Früher bekannt als Y:Line)

Syntax:

    class <name> {
    	pingfreq <Ping-Frequenz>;
    	connfreq <Connect-Frequenz>;
    	maxclients <Maximum-Clients>;
    	sendq <send-queue>;
    	recvq <recv-queue>;
    };

Class Blöcke definieren Verbindungs Klassen in welche Verbindungen eingeordnet werden (z.B. von Allow Blöcken oder Server von Link Blöcken). Im Allgemeinen hat man mehrere Class Blöcke (z.B. für Server, für Clients, für Opers)

Verbindungsklassen definieren eine Reihe von Parametern für Verbindungen, die folgendes umfassen:

name ist ein beschreibender Name wie "clients" oder "servers", dieser Name wird später in anderen Blöcken als Referenz verwendet.

pingfreq ist die Anzahl von Sekunden zwischen PINGs von diesem Server.

connfreq wird nur für Server verwendet und ist die Anzahl Sekunden zwischen zwei Verbindungsversuchen, falls autoconnect eingeschaltet ist.

maxclients gibt die maximale Gesamtzahl an Clients und Servern an, die in dieser Klasse sein können.

sendq gibt die Menge an Daten an, die sich in der Sende Queue befinden dürfen (sehr hoch für Server mit geringer Bandbreite, mittel für Clients)

recvq gibt die Menge an Daten an, die sich in der Empfangsqueue befinden können und wird zur Flood Kontrolle verwendet (das betrifft nur normale User, es sollte mit Werten zwischen 3000-8000 experimentiert werden, >8000 ergibt keine Änderung und 8000 ist Default).

Beispiele:

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

    class servers{
    	pingfreq 90;
    	maxclients 10; /* Maximum an gleichzeitigen möglichen Server Verbindungen */
    	sendq 1000000;
    	connfreq 100;  /* Wieviele Sekunden zwischen jedem Verbindungs Versuch */
    };

4.5 - Allow Block ERFORDERLICH (Früher bekannt als I:Line)

Syntax:

    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>;
    		...
    	};
    };

In Allow Blöcken wird angegeben, wer zum Server connecten darf. Es können mehrere Allow Blöcke vorhanden sein (was in der Regel auch erforderlich ist).

Anmerkungen zu Übereinstimmung (matching)
Die Zugangskontrolle arbeitet folgendermaßen: Es müssen entweder IPs übereinstimmen ODER Hosts. Einträge von "hostname *@*;" und "ip *@1.2.3.4;" stimmen also mit allem überein und gestatten einen universellen Zugang. Allow Blöcke in der unrealircd.conf werden von unten nach oben ausgewertet, deswegen müssen spezielle Host/IP Blöcke NACH den allgemeinen *@* Allow Blöcken aufgeführt werden. Soll ein Block ausschliesslich für eine IP gelten, so ist das Feld "hostname" auf irgendeinen ungültigen Wert zu setzen, wie z.B. "hostname NOBODY;". Dadurch wird der Allow Block ausschliesslich auf Übereinstimmung der IP eingestellt.

ip
Für die IP Maske gilt die Form user@ip, dabei ist user der ident und meist mit * eingetragen, ip ist eine gültige IP Adresse, die ebenfalls Wildcards enthalten kann. Einige Beispiele: *@* (jeder von überall her), *@192.168.* (jeder, dessen IP Adresse mit 192.168 beginnt), etc.

host
Für die host gilt die Form user@hostmask, dabei ist user der ident und meist mit * eingetragen, hostmask eine Internetadresse. Einige Beispiele: *@* (jeder von überall her), *@*.wanadoo.fr (nur User von wanadoo.fr).

password (optional)
Die Verbindung erfordert ein Passwort. Zusätzlich kann hier eine Verschlüsselungs Methode angegeben werden.

maxperip (optional, aber empfohlen)
Festlegung, wieviele Verbindungen mit derselben IP auf dem Server erlaubt sind (z.B.: maxperip 4;).

redirect-server (optional)
Wenn die Klasse voll ist, werden User zu diesem Server umgeleitet (wenn der Client das unterstützt [mIRC 6 unterstützt es]).

redirect-port (optional)
Wenn ein redirect-server angegeben ist, kann hier der Port eingetragen werden. Ohne Eintrag wird 6667 als Default angenommen.

options block (optional)
Gültige Optionen sind:
useip immer nur IP statt Hostnamen anzeigen
noident kein ident verwenden, sondern den vom Client übergebenen Usernamen
ssl Übereinstimmung ist nur gegeben, wenn der User via SSL verbindet
nopasscont Überprüfung fortsetzen, wenn kein Passwort angegeben wurde (dadurch kann man User, die ein Passwort übermitteln in eine extra Klasse
packen).

Beispiele:

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

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

4.6 - Listen Block ERFORDERLICH (Früher bekannt als P:Line)

Syntax:

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

Mit diesem Block können spezielle Ports angegeben werden, auf die der IRCD reagiert. Falls keine Optionen erforderlich sind, kann man diesen Eintrag auch in der einfachen Form setzen:
<ip:port>;.

ip und port
Die IP wird normalerweise auf "*" eingestellt, aber man kann auch eine IP eingeben, um ausschließlich diese an den Port zu binden.. Der Port ist die Nummer des Ports, der hier eingestellt werden soll. Man kann sowohl einen Portbereich als auch einen einzelnen Port angeben Beispielsweise bewirkt die Angabe "6660-6669", dass auf jeden Port von 6660 bis 6669 (einschließlich) reagiert wird. IPv6 User: siehe nächster Absatz.

Info für IPv6 User
Wenn für den Server IPv6 aktiviert ist, müssen die IPs in eckige Klammern (Brackets, "[ ]") eingeschlossen sein, wie z.B.: "[::1]:6667" (reagiere auf Local Host an Port 6667). Verwendet man IPv6 und es soll eine bestimmte IPv4 Adresse definiert werden, gilt das Format: "::ffff:ipv4ip". Ein Beispiel: [::ffff:203.123.67.1]:6667 (reagiert wird auf IP 203.123.67.1 auf Port 6667). Allerdings kann man auch "*" mit IPv6 verwenden.

options block (optional)
Für den Port können besondere Optionen angegeben werden. Gültige Optionen sind:

clientsonly | Port ist nur für Clients
serversonly | Port ist nur für Server
java | CR javachat support
ssl | SSL encrypted port

Beispiele:

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

Oder, wenn es keine Optionen gibt:

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

4.7 - Oper Block EMPFOHLEN (Früher bekannt als 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>;
    };

Mit dem Oper Block können für den Server IRC Operatoren festgelegt werden.
Der oper:: Eintrag legt den Login Namen für den /oper Befehl fest.
Der Eintrag oper::from::userhost ist eine user@host Maske, die zum User passen muss. Man kann hier mehr als eine Maske angeben, indem man mehrere oper::from::userhost Einträge erstellt.
Der Eintrag oper::password enthält das Passwort, dass der User angeben muss. Hier kann zusätzlich eine Verschlüsselungsmethode für dieses Passwort angegeben werden, gültige Typen sind dann: crypt, md5, und sha1, ripemd-160. Soll ein einfaches unverschlüsseltes Passwort verwendet werden, bleibt dieses Feld einfach leer.

Zu beachten ist, dass sowohl der Loginname als auch das Passwort case sensitive sind.

Beim Eintrag oper::class muss es sich um eine schon definierte Klasse handeln, die in der Konfigurationsdatei schon vor dieser Blockdefinition auftaucht (also ERST Class definieren und erst DANACH oper!).

Bei der oper::flags Anweisung gibt es zwei Formate. Falls man die frühere Form der Operflags vorzieht (mit Buchstaben wie z.B.: "OAa", verwendet man die "flags <flags>" Methode. Wenn man dagegen die neue Form (wie z.B.: "services-admin") verwenden möchte, benutzt man die "flags { <flag>; }" Methode.

Nachfolgend eine Liste aller Flags in beiden Formaten und ihre Bedeutung.

Altes Flag | Neues Flag | Description
o | local | Macht User zu lokalem Operator
O | global | Macht User zu globalem Operator
C | coadmin | Macht User zum Coadmin
A | admin | Macht User zum Admin
a | services-admin | Macht User zum Services Admin
N | netadmin | Macht User zum Netzwerk Admin
r | can_rehash | Oper kann /rehash durchführen
D | can_die | Oper kann /die durchführen
R | can_restart | Oper kann /restart durchführen
h | helpop | Oper empfängt umode +h (helpop)
w | can_wallops | Oper kann /wallops senden
g | can_globops | Oper kann /globops senden
c | can_localroute | Kann zu Servern lokal verbinden
L | can_globalroute | Kann zu Servern global verbinden
k | can_localkill | Kann /kill auf lokale User ausführen
K | can_globalkill | Kann /kill auf globale User ausführen
b | can_kline | Kann /kline setzen
B | can_unkline | Kann mit /kline -u@h K-Line löschen
n | can_localnotice | Kann lokale Server Notices senden
G | can_globalnotice | Kann globale Server Notices senden
z | can_zline | Kann /zline setzen
t | can_gkline | Kann /gline, /shun und /spamfilter setzen
Z | can_gzline | Kann /gzline setzen
W | get_umodew | Setzt Umode +W (Anzeige von externem /whois) wenn man (via /oper) als Operator identifiziert
H | get_host | Setzt Host auf Oper host (Durch das Flag wird die Anzeige der Funktion unterdrückt)
v | can_override | Kann OperOverride ausführen
q | can_setq | Kann Usermode +q setzen
X | can_addline | Kann den Befehl /addline benutzen
d | can_dccdeny | Kann /dccdeny und /undccdeny benutzen

Bestimmte Flags setzen andere Flags per 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

Mit der oper::swhois Anweisung kann eine zusätzliche Zeile für die whois Information eines Opers gesetzt werden. [optional]

Mit der oper::snomask Anweisung kann eine server notice Mask für einen Oper voreingestellt werden, so dass man beim oper Befehl bestimmte Flags automatisch voreingestellt sind. Siehe Abschnitt 3.3 für Infos über snomasks. [optional]

Mit der oper::modes Anweisung können Modi für Opers voreingestellt werden, so dass man beim oper Befehl bestimmte Flags automatisch voreingestellt sind. [optional]

Mit der oper::maxlogins Anweisung kann man die die Anzahl gleichzeitiger Oper Logins einschränken. Wenn hier z.B. der Wert 1 eingestellt wird, kann immer nur eine Person über diesen Oper Block eingeloggt sein. [optional]

Beispiel:

    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 "Beispiel einer whois Maske";
    	snomask frebWqFv;
    };

Einige Infos zu OperOverride:
OperOverride bedeutet z.B. joining in einen +ikl Channel und Übergehung von Banns (trotzdem muss man zuvor für sich selbst ein /invite durchführen), sich selbst Op in einem Channel zu geben etc.
Das "can_override" gibt es, um Missbrauch dieser Möglichkeiten einzuschränken. Per Default kann kein Oper vorhandene Einstellungen übergehen, solange nicht das Operflag "v" explizit gesetzt ist.

4.8 - DRpass Block EMPFOHLEN (Früher bekannt als X:Line)

Syntax:

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

Mit den Blöcken drpass::restart und drpass::die werden die Passworte für die Befehle "/restart" und "/die" festgelegt. Ebenfalls ist es möglich, einen Typ der Authentifizierung festzulegen. Gültige Typen sind hierbei crypt, md5, und sha1, ripemd-160.

Beispiel:

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

4.9 - Include Anweisung

Syntax:

include <file-name>;

Mit dieser Anweisung wird eine separate Konfigurationsdatei mit dem Namen "file-name" geladen. Diese Datei kann jeden Typ von Config Blöcken enthalten und ihrerseits weitere Include Anweisungen enthalten. Wildcards im Dateinamen werden unterstützt, wodurch es auch möglich ist, mehrere Dateien auf einmal zu laden..

Beispiel 1: eine network Datei

    include mynetwork.network;

Diese Anweisung lädt die Datei "mynetwork.network, wenn man eine eigene network Datei verwenden möchte. Eigene network Dateien sind eigentlich nicht mehr erforderlich, da sämtliche Anweisungen auch in der unrealircd.conf stehen können. Mit einer Include Anweisung kann man das File statt dessen getrennt halten und laden.

Beispiel 2: aliases

    include aliases/ircservices.conf

Ein weiteres Beispiel für die Anwendung von Alias Blöcken. UnrealIRCd wird mit einigen Dateien geliefert, die schon die wesentlichen Aliasse für die meisten Services enthalten.:

- 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 Anweisung ERFORDERLICH

Syntax:
loadmodule <file-name>;

Warum Module hilfreich sind, kann hier nachgelesen werden.

Folgende Module werden standardmäßig bei Unreal3.2 mitgeliefert:

commands.so /commands.dll - Enthält sämtliche / Befehle (noch nicht wirklich alle, aber sicher in einer der nächsten Versionen) ERFORDERLICH
cloak.so / cloak.dll - Cloaking Modul (oder irgend ein anderes Cloaking Modul - dient der Unterdrückung echter Hosts) ERFORDERLICH

Es ist sicherzustellen, dass diese Module in jedem Fall geladen werden:

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

oder unter Windows:

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

4.11 - Log Block RECOMMENDED

Syntax:

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

Mit dem Log Block kann man verschiedene Logfiles zu den unterschiedlichsten Zwecken erstellen lassen. Dabei bezeichnet log:: den Namen der Logdatei.
log::maxsize ist eine optionale Anweisung, um eine Größe anzugeben, ab der die Datei gelöscht und neu begonnen wird. Die Zahlenangabe dahinter kann gefolgt sein von MB für Megabytes, KB für Kilobytes oder GB für Gigabytes. Bei log::flags wird angegeben, welche Art von Informationen in der Log Datei gespeichert werden sollen. Angegeben werden kann hier einer oder mehrere der unten aufgelisteten Flags. Siehe hierzu die nachfolgende Liste möglicher Flags.

Es können auch mehrere Log Blocks definiert sein, um unterschiedliche Dinge in verschiedenen Dateien zu loggen.

Gültige Flags:

Flag | Bedeutung
errors | selbsterklärend
kills | zeichnet /kill Meldungen auf
tkl | zeichnet Infos auf über *lines (kline, zline etc), shuns und Spamfilter (setzen, löschen, Ablauf)
connects | Zeichnet connects/quits der User auf
server-connects | Zeichnet connects/squits der Server auf
oper | Zeichnet Oper Zugriffe auf (sowohl fehlgeschlagene als auch erfolgreiche)
sadmin-commands | Zeichnet die Verwendung von /sa* (samode, sajoin, sapart etc.) auf
chg-commands | Zeichnet die Verwendung von /chg* (chghost, chgname, chgident, etc.) auf
oper-override | Zeichnet die Verwendung von Operoverrides auf
spamfilter | Zeichnet Übereinstimmungen zu Spamfiltern auf

Beispiel:

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

4.12 - TLD Block OPTIONAL (Früher bekannt als T:Line)

Syntax:

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

Mit dem TLD Block kann man eine motd (Messageoftheday), rules und channels für User basierend auf deren Host festlegen. Das ist nützlich, falls man verschiedene motd's für verschiedene Sprachen verwenden möchte.
tld::mask ist eine user@host Maske, die zum Usernamen und seiner Hostmask passen muss.
tld::motd, tld::shortmotd, tld::opermotd, tld::botmotd, und tld::rules legen die jeweiligen Dateien für motd, shortmotd, opermotd, botmotd und rules fest, die in Abhängigkeit von der Hostmask angezeigt werden. Dabei sind tld::shortmotd, tld::opermotd und tld::botmotd optional.
tld::channel ist optional, und ermöglicht es, einen Channel festzulegen, in den der User beim Connect geleitet wird. Wenn dieser Eintrag existiert, überschreibt er einen Default Auto join Channel.
tld::options ermöglicht es, noch weitere notwendige Bedingungen zu setzen, bislang ist hier aber nur tld::options::ssl möglich.

TLD Einträge werden von unten nach oben abgearbeitet.

Beispiel:

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

4.13 - Ban Nick Block OPTIONAL (Früher bekannt als Q:Line)

Syntax:

    ban nick {

    	mask <nickname>;
    	reason <grund-für-bann>;
    };

Mit dem Ban Nick Block können bestimmte Nicknamen auf dem Server gesperrt werden.
ban::mask gestattet Masken mit Wildcards um mehrere Nicknamen zu erfassen
ban::reason ermöglicht es, einen Grund für den Bann anzugeben.
In der Regel werden in TLD Blöcken die Namen der Services angegeben, so dass kein User diese Namen als seinen Nick wählen kann.

Beispiel:

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

4.14 - Ban User Block OPTIONAL (Früher bekannt als K:Line)

Syntax:

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

Mit diesem Block kann man verbieten, dass sich ein user@host zum Server verbindet.
ban::mask ist eine user@host Maske, die gebannt werden soll, wobei Wildcards möglich sind.
ban::reason ist der Grund, der dem gesperrten User beim Verbindungsversuch angezeigt wird.
Zu beachten ist, dass dieser Bann nur lokal wirkt und deswegen der betreffende User ohne weiteres über andere Server zum Netzwerk verbinden kann.

Beispiel:

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

4.15 - Ban IP Block OPTIONAL (Früher bekannt als Z:Line)

Syntax:

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

Der Ban IP Block verhindert das Verbinden von bestimmten IP Adressen her zum Server. Das gilt sowohl für Verbindungsversuche von Usern als auch von Servern.
ban::mask ist eine IP, die Wildcards enthalten kann.
ban::reason ist der Grund, warum der Bann eingetragen wurde.
Da dieser Bann auch Server betreffen kann, sollte man beim Eintrag von IP Adressen sehr vorsichtig sein.

Beispiel:

    ban ip {
    	mask 192.168.1.*;
    	reason "Nimm eine richtige IP, du Lamer!";
    };

4.16 - Ban Server Block OPTIONAL (Früher bekannt als q:Line)

Syntax:

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

Dieser Block verhindert, dass sich bestimmte Server zum eigenen Server verbinden können.
ban::mask beinhaltet eine Maske, die Wildcards gestattet und zu dem Namen eines Servers passt, der nicht verbinden darf.
ban::reason Der Grund, warum dieser Bann existiert.

Beispiel:

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

4.17 - Ban RealName Block OPTIONAL (Früher bekannt als n:Line)

Syntax:

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

Der Ban Realname Block ermöglicht es, Clients auf das GECOS (Realname) Feld zu testen und entsprechend zu bannen, Das kann hilfreich sein, um Floods von Clones zu vermindern, da Floodbots des öfteren denselben Eintrag im Realnamen Feld verwenden.
ban::mask legt den Realnamen fest, der gebannt werden soll. Die Maske kann Wildcards enthalten.
ban::reason legt den anzuzeigenden Grund für den Bann fest.

Beispiel:

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

4.18 - Ban Version Block OPTIONAL (Früher nicht vorhanden)

Syntax:

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

Mit dem "ban version block" kann man Clients in Abhängigkeit der von ihnen verwendeten IRC Software bannen. Dazu wird die Antwort auf die CTCP Versions Abfrage ausgewertet. Deshalb wird dieser Bann dann nicht wirksam sein, wenn der entsprechende Client keine CTCP Version sendet. Mit diesem Feature ist es möglich, bestimmte möglicherweise störende Scripts zu blocken und damit zu verbieten.
ban::mask legt die Version des Clients fest, der gebannt werden soll. Die Maske kann Wildcards enthalten.
ban::reason legt den Grund fest, der dem User angezeigt wird.
ban::action kann ebenfalls festgelegt werden. Dabei ist der Default auf "kill". tempshun setzt ein shun auf die Verbindung des Users und arbeitet effektiv gegen Zombies und/oder Bots mit dynamischer IP, weil sie unschuldige User nicht beeinträchtigen. shun/kline/zline/gzline setzen einen Bann auf die IP (*@IPADDR). Die Dauer dieser Banns kann mit 'set::ban-version-tkl-time' konfiguriert werden und beträgt per Default 1 Tag.

Beispiele:

    ban version {
    	mask "*SomeLameScript*";
    	reason "SomeLameScript enthält Backdoors!";
    };

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

4.19 - Ban Exceptions Block OPTIONAL (Früher bekannt als E:Line)

Syntax:

    except ban {
    	mask <hostmask>;
    };

Mit dem "except ban Block" kann man user@host Masken angeben, die von den gesetzten Banns der Blöcke zuvor ausgenommen werden sollen. So etwas kann verwendet werden, falls man z.B. ganze ISP bannen möchte, aber einzelnen Usern trotzdem die Verbindung erlauben möchte. Dazu bei except::mask den oder die Hosts eintragen (als user@host Mask) die trotz globalem Bann connecten dürfen.

Beispiel:

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

4.20 - TKL Exceptions Block OPTIONAL (Früher nicht vorhanden)

Syntax:

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

Mit dem "except tkl Block" kann man user@host Masken angeben, die von den gesetzten tkl Banns (also G-Lines, Shuns, GZ Lines) auf breitere Hosts ausgenommen werden sollen. So etwas kann verwendet werden, falls man z.B. ganze ISP bannen möchte, aber einzelnen Usern trotzdem die Verbindung erlauben möchte. Dazu bei except::mask den oder die Hosts eintragen (als user@host Mask) die trotz globalem Bann connecten dürfen. Bei except::type wird angegeben, welcher Bann Typ ausgenommen werden soll. Gültige Typen sind hier: gline, gzline, qline, gqline und shun, für Ausnahmen von Glines, Global Zlines, Qlines, Global Qlines und Shuns. Wenn das {} Format benutzt wird, können unterschiedliche Typen angegeben werden.

Anm. des Übersetzers: Die Ausnahmen funktionieren wirklich nur bei gebanntem breiteren Host (123.123.* oder *@url). Man kann damit z.B. nicht einen versehentlichen Bann auf Localhost verhindern.

Beispiel:

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

4.21 - Throttle Exceptions Block OPTIONAL (Früher nicht vorhanden)

Syntax:

    except throttle {
    	mask <ipmask>;
    };

Der "except throttle block" gestattet die Angabe einer IP Maske, für die das throttling System nicht gelten soll. Dieser Block hat nur eine Auswirkung, wenn throttling im "set Block" auch aktiviert ist. Die bei except::mask angegebene IP Maske wird nicht wegen Throttlings gebannt.

Beispiel:

    except throttle {
    	mask 192.168.1.*;
    };

4.22 - Deny DCC Block OPTIONAL (Früher bekannt als dccdeny.conf)

Syntax:

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

Im "deny dcc Block" können Dateinamen angegeben werden, die nicht per DCC über den Server versandt werden dürfen. Das kann helfen, die Verteilung von Viren und Trojanern zu verhindern.

Der Parameter deny::filename definiert eine Maske von Dateinamen, deren Versand blockiert wird, Wildcards sind hier möglich. deny::reason legt den anzuzeigenden Grund für die Sperrung der Datei fest.

Ferner gibt es eine deny::soft Option. Wenn diese auf 'yes' gesetzt ist, ist dcc so lange gesperrt, bis der User es explizit via /DCCALLOW +nickname-der-versucht-zu-senden erlaubt.
Siehe dccallow.conf für ein gutes Konfigurationsbeispiel zu dccallow.

Beispiel:

    deny dcc {
    	filename *.exe;
    	reason "Ausführbare Datei";
    	soft yes;
    };

4.23 - Deny Version Block OPTIONAL (Früher bekannt als V:Line)

Syntax:

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

Mit diesem Block ist es möglich, Server aufgrund der Version ihres Unreal Ircds bzw. des Compilierungszeitpunktes oder bestimmter Optionen vom Linken auszuschliessen. Das Format des Blockes ist etwas komplex, aber nicht so schwer zu verstehen.
deny::mask definiert eine Wildcard Maske, für welchen Server die Ablhnung gelten soll.
deny::version bezeichnet eine Protokoll Nummer, um welche Version es geht.

Ein Beispiel: Für den UnrealIRCD Version 3.0 ist die Versionsnummer 2301, für 3.1.1/3.1.2 ist es 2302 und für 3.2 ist es 2303. Das erste Zeichen des Parameters kann eines der folgenden sein: >, <, =, !. Dieses Zeichen gibt an, wie der IRCD die Version interpretieren soll. Ist also z.B. das erste Zeichen ein ">" so werden alle Versionen mit einer größeren Nummer abgelehnt. Handelt es sich um ein "<", so werden alle kleineren Versionen abgelehnt. Bei einem "=" wird nur die angegebene Version abgelehnt. Bei einem "!" werden alle Versionen außer der angegebenen abgelehnt.
deny::flags ermöglicht die Angabe von Compile Zeit Flag, die der Server haben oder nicht haben darf. Die Flags müssen direkt nacheinander ohne Zwischenräume angegeben sein. Wird einem Zeichen ein "!" vorangestellt, darf der Server dieses Flag nicht haben, steht kein "!" davor, muss der Server dieses Flag haben, um vom Linken ausgeschlossen zu sein.

4.24 - Deny Link Block OPTIONAL (Früher bekannt als D/d:Line)

Syntax:

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

Mit diesem Block können Regeln angegeben werden, nach denen man Server vom Linken ausschliessen kann.
deny::mask definiert eine Wildcard Maske auf den Servernamen, für den die Regel gelten soll.
deny::rule ist ein sehr komplexer Ausdruck. Ein rule Ausdruck erlaubt es, den Link sehr detailliert zu steuern und ist aufgebaut wie eine Programm Anweisung. Vier Operatoren werden unterstützt:
connected(<servermask>) ergibt 'wahr', wenn ein Server zu dem die angegebene deny::mask passt, verbunden ist.
directcon(<servermask>) ergibt 'wahr', wenn ein Server zu dem die angegebene deny::mask passt, direkt verbunden ist.
via(<viamask>,<servermask>) ergibt 'wahr', wenn ein Server aus deny::mask über einen Server verbunden ist, auf den viamask passt.
directop() ergibt wahr, wenn der Operator über /connect direkt zu diesem Server verbunden hat.
Diese Operatoren können durch Verwendung von && (und) und || (oder) miteinander kombiniert werden. Durch Verwendung von Klammern um die eizelnen Items sind auch Gruppierungen möglich. Darüber hinaus kann einem Operator ein "!" vorangestellt sein, um darauf zu testen, ob der Operator 'falsch' ergibt. Wenn der gesamte Ausdruck 'wahr' ergibt, wird der Link abgelehnt.
deny::type kann zwei Werte haben: "auto" (gilt nur für autoconnects, /connect funktioniert trotzdem), und "all" (gilt für alle Verbindungsanfragen).

4.25 - Deny Channel Block OPTIONAL (Früher bekannt als chrestrict.conf)

Syntax:

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

Mit dem "deny channel Block" kann man Usern das joinen bestimmter Channels verbieten. In deny::channel wird die Maske der Channels angegeben, die die User nicht betreten dürfen, Wildcards sind erlaubt. In deny::reason wird der anzuzeigende Grund eingetragen, weswegen der Channel nicht betreten werden kann. Darüber hinaus kann in deny::redirect ein Channel angegeben werden, in den ein User umgeleitet wird, falls er versucht einen gesperrten Channel zu betreten. Darüber hinaus kann über deny::warn (falls eingestellt) angegeben werden, dass eine OperNotice (an EYES snomask) gesendet wird, wenn ein User versucht, einen solchen Channel zu joinen.

Beispiel:

    deny channel {
    	channel "#unrealsucks";
    	reason "Nein, tut es nicht!";
    };

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

    deny channel {
    	channel "#operhelp";
    	reason "Unser Hilfe Channel ist #help und nicht #operhelp";
    	redirect "#help";
    };

4.26 - Allow Channel Block OPTIONAL (Früher nicht vorhanden)

Syntax:

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

Mit dem "allow channel Block" kann man Channels festlegen, in die User joinen dürfen. In allow::channel wird eine Channel Maske angegeben, die auch Wildcards enthalten kann und festlegt, in welche Channels die User joinen dürfen.

Beispiele:

    allow channel {
    	channel "#something";
    };

    allow channel {
    	channel "#smart_*";
    };

4.27 - Allow DCC Block OPTIONAL (Früher nicht vorhanden)

Syntax:

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

Mit dem "allow dcc Block" kann man Ausnahmen zum deny dcc Block festlegen, wobei Wildcards erlaubt sind. Wenn allow dcc::soft auf 'yes' gesetzt ist, gilt die 'soft dcc Bann Liste', wenn 'no' eingestellt ist, gelten normale ('harte') dcc Banns.

Beispiel:

    allow dcc {
    	filename "*.jpg"; /* Bilder sind üblicherweise sicher */
    	soft yes;
    };

4.28 - Vhost Block OPTIONAL (Früher bekannt als vhosts.conf)

Syntax:

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

Der "vhost Block" ermöglicht es, eine "login"/"Passwort" Kombination festzulegen, die in Verbindung mit dem /vhost Befehl einen Fake Hostnamen ermöglicht. Der vhost::vhost Parameter kann entweder in der Form "user@host" oder einfach als Hos angegeben werden, damit der User erfolgreich /vhost durchführen kann. vhost::from::userhost enthält einen "user@host" der zu dem User passen muß, um einen vhost zu erhalten. Es kann mehr als eine Host Maske angegeben werden. vhost::login ist der Login Name, den der User eingeben muss und vhost::password ist das einzugebende Passwort. Darüber hinaus kann bei vhost::password:: auch ein Authentifizierungstyp für Verschlüsselung angegeben werden. Unterstützt werden hier z.Zt. crypt, md5, und sha1, ripemd-160. vhost::swhois ermöglicht es, eine Extra Zeile für eine /whois Abfrage einzufügen, genau wie im Oper Block bei "oper::svhost".

Beispiel:

    vhost {
    	vhost my.own.personal.vhost.com;
    	from {
    		userhost my@isp.com;
    		userhost myother@isp.com;
    	};
    	login mynick;
    	password mypassword;
    	swhois "Ich bin wichtig ;)";
    };

4.29 - Badword Block OPTIONAL (Früher bekannt als badwords.*.conf)

Syntax:

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

Mit dem Badword Block kann die Liste für User- und Channelmodus +G bearbeitet werden, um bestimmte "badwords" zu behandeln. badword:: legt den Typ fest, wobei hier gültige Werte sind: 'channel', 'message' und 'quit'. 'channel' gilt für Channel Modus +G Liste, 'message' gilt für User Modus +G Liste, und 'quit' gilt für die quit Meldung. badword::word kann ein einfaches Wort sein oder ein Ausdruck, nach dem gesucht werden soll. badword::replace ist ein Ersetzungstext, der anstelle des gefundenen Badwords angezeigt wird. Wird hier nichts eingetragen, so wird ein gefundenes Badword durch <censored> ersezt. Bei badword::action wird angegeben, was im Falle eines gefundenen Badwords geschehen soll. Wird hier das Wort "replace" eingetragen, dann wird das Badword ersetzt. Falls hier "block" angegeben wird, wird die gesamte Nachricht gar nicht erst angezeigt. Falls "badword::action" nicht gesetzt ist, wird "replace" als Default angenommen.

Beispiel:

    badword channel {
    	word shit;
    	replace shoot;
    };

4.30 - ULines Block OPTIONAL (Früher bekannt als U:Line)

Syntax:

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

Mit dem ulines block können bestimmte Server mit speziellen Zwecken definiert werden. Das sollte ausschließlich für Server wie "services" oder "stats" benutzt werden und nicht für normale Server. Jeder Eintrag steht für den Namen des Servers mit einem besonderen Zweck.

Beispiel:

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

4.31 - Link Block OPTIONAL (Früher bekannt als C/N/H:Lines)

Syntax:

    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>;
    		...
    	};
    };

Dieser Block wird benötigt, um Server zueinander linken zu lassen. Man sollte sich Zeit nehmen, hierzu alles genau zu lesen, weil das Ganze nicht unkompliziert ist und hier die häufigsten Fehler gemacht werden.

Der erste Eintrag, server-name, ist der Name des zu verbindenden entfernten Servers, so wie er in dessen Me { } Block definiert wurde (z.B.: hub.blah.com). Es darf sich nicht um eine IP handeln und der Eintrag kann sich von "hostname" unterscheiden.

username
Hier kann zu Zwecken der Authentifizierung über ident ein Eintrag erfolgen, aber normalerweise wird nur "*" eingestellt.

hostname
Der Hostname oder die IP des entfernten Servers. Der Eintrag gilt gleichermaßen für das Verbinden UND die Authentifizierung seitens des eigenen Servers.
Einige Beispiele:

1.2.3.4 | normale IP
hub.blah.com | Host: nur für ausgehende Verbindung, kann keine eingehenden Verbindungen akzeptieren, solange nicht "link::options::nohostcheck" gesetzt ist.
* | kann nicht selbst zu anderen Servern verbinden, aber akzeptiert eingehende Serververbindungen (mit korrektem Passwort) von überall her.
::ffff:1.2.3.4 | für Linking ipv6 zu ipv4.

bind-ip (optional)
Kann genutzt werden, um eine bestimmte IP (z.B.: 192.168.0.1) daran zu binden, von wo aus verbunden werden soll, wird allerdings so gut wie nie benutzt.

port
Port zu dem verbunden wird (auf welchen der entfernte Server reagiert).

password-connect
Das Passwort, welches zum Verbinden erforderlich ist. Es muss im Klartext vorliegen und darf nicht verschlüsselt sein.

password-receive
Das Passwort, welches zur Überprüfung eingehender Verbindungen verwendet wird, kann auch verschlüsselt sein (gültige Methoden sind crypt, md5, sha1, ripemd-160). Der "auth-type" Parameter kann auch frei gelassen werden, um das passwort im Klartext zu verwenden. Normalerweise ist das Passwort hier dasselbe, wie bei "password-connect".

hub oder leaf
Zu einem hub sind mehrere Server verbunden, ein leaf hat immer nur eine Verbindung. Ein Server ist solange ein leaf, wie es keine hub Anweisung gibt. Ebenso ist er ein leaf, wenn in der Anweisung lediglich * definiert ist oder die leaf Tiefe (Anzahl der hops) 1 ist.

hub (optional)
Der Wert ist eine Maske, auf welche Server dieser hub connecten darf (z.B.: *.my.net).

leaf (optional)
Dieser Wert gibt an, zu welchen Servern dieser Hub nicht verbindet. Hier einen * anzugeben ist das selbe, wie keine hub Anweisung zu haben.

leaf-depth (optional)
Dieser Wert gibt die Tiefe (Anzahl der hops)an, die dieser Server darunter haben darf. Beispielsweise bedeutet 1, dass der Server keine Links hat (ist ein leaf), 2 bedeutet, es kann zu Servern gelinkt werden, aber diese können zu keinem anderen linken (dieser Hub kann also nur zu leafs linken). Ein Wert von 0 bedeutet, dass es kein Limit gibt und das ist auch Default.

class
Die Klasse, in die der Server kommt, oft ist eine eigene Klasse für Server definiert.

compression-level (optional)
Gibt den Kompressions Level (1-9) für diesen Link an. Wird nur verwendet, wenn auch "link::options::zip" gesetzt ist.

ciphers (optional)
Gibt die SSL Verschlüsselung an, die für diesen Link benutzt wird. Um eine Liste der verfügbaren Verschlüsselungscodes zu erhalten, kann man den 'openssl ciphers' Befehl benutzen. ciphers ist als eine durch ':' getrennte Liste anzugeben.

options block
Eine oder mehrere Optionen für eine Verbindung zu diesem Server. Wird manchmal nicht benötigt.

ssl | wenn zu einem SSL Port verbunden wird.
autoconnect | Server versucht autoconnect, Zeit, wie in "class::connfreq" spezifiziert wird (wird am besten nur auf einer Seite aktiviert,wie leaf->hub)
zip | wenn komprimierte Verbindungen gewollt sind, muß auf beiden Seiten mit +set zip compiliert sein.
nodnscache | IP für ausgehende Serververbindung nicht im cache speichern, wird bei oft wechselndem Host benutzt (wie dyndns.org)
nohostcheck | den entfernten Host nicht überprüfen (link::hostname), wird bei oft wechselndem Host benutzt (wie dyndns.org)
quarantine | Opers auf diesem Server können keine GLOBAL Oper Privilegien erhalten (sie werden gekilled), dient zu Test Links etc.

Beispiel:

    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 OPTIONAL (Früher nicht vorhanden)

Syntax [standard alias]:

    alias <name> {
    	target <nick-to-forward-to>;
    	type <type-of-alias>;
    	spamfilter <yes|no|>
    };

(Hinweis: siehe auch hier , welche Standard Alias Dateien bei UnrealIRCd mitgeliefert werden.)

Mit dem "alias block [standard alias]" kann festgelegt werden, dass ein Befehl an einen User geleitet wird. So wird z.B. durch /chanserv eine Nachricht an den "User" chanserv weitergeleitet. alias:: legt den Namen des Befehls fest, der das Alias wird, z.B. 'chanserv'. alias::target ist der Nickname, an den weitergeleitet wird. Wenn "alias::" identisch mit dem Nick ist, an den weitergeleitet wird, kann "alias::target" weggelassen werden. alias::type gibt den Typ des Alias an, gültige Typen sind hier "services" (der User ist auf dem Services Server), "stats" (der User ist auf dem Stats Server) "normal" (der User ist normaler User auf irgendeinem Server) und "channel" (das Ziel ist ein Channel Name). Wenn alias::spamfilter (optional) auf 'yes' eingestellt ist, werden auch Spamfilter geprüft (Default ist 'no'). Der "alias block" hat auch einen weiteren nachfolgend erklärten Zweck.

Syntax [Befehl alias]:

    alias <name> {

    	/* Für Aliase, die an User/Channels gesendet werden */
    	format <regex-expression> {
    		target <nick-to-forward-to>;
    		type <type-of-alias>;
    		parameters <parameter-string>;
    	};
    	/* For 'echte Aliase' */
    	format <regex-expression> {
    		command <command>;
    		type real;
    		parameters <parameter-string>;
    	};
    	/* Etc... You can have as many format blocks as you wish.. */

    	format <regex-expression> {
    		...
    	};
    	type command;
    	spamfilter <yes|no>
    };

Wird der "alias Block" in diesem Format benutzt, ermöglicht er eine breitere Anwendungsweise. Beispielsweise kann man einen Alias wie /identify erstellen. alias:: ist dasselbe wie oben, der Name des Alias Befehls. alias::format legt einen regulären Ausdruck fest, der mit dem Text verglichen wird, der als Alias Befehl gesandt wurde. Es können mehrere "alias::format" angegeben werden, um unterschiedliche Dinge in Abhängigkeit vom gesandten Text durchführen zu lassen. alias::format::target ist das Ziel (der Name), an den der Alias weitergeleitet wird, bei "realen Aliasen" wird allerdings alias::format::command benutzt. alias::format::type definiert den Typ des Alias, zu dem die Nachricht geleitet wird. Neben den zuvor erwähnten Typen in der Syntax bein Standard Alias, kann hier auch der Typ "Real" für reale Aliase angegeben werden. alias::format::parameters ist, was als Parameter an den Alias geschickt wird. Um Parameter für einen Befehl an den Alias anzugeben, wird ein "%" gefolgt von einer Nummer angegeben. So ist z.B. %1 der erste Parameter, %2 der zweite Parameter usw. Man kann auch festlegen, dass ab einem Parameter alle bis zum Ende gelten sollen, dann gibt man z.B. an: %1- (das Minuszeichen bedeutet: "alle weiteren") Zusätzlich kann man %n angeben, was durch den Nicknamen des Users ersetzt wird, der den Befehl ausgeführt hat.

Um Beispiele zum Alias Block zu sehen, schaue man in doc/example.conf.

4.33 - Help Block OPTIONAL (Früher nicht vorhanden)

Syntax:

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

(zu beachten: Normalerweise genügt es statt dessen die help.conf per Include einzufügen)

Der "help block" ermöglicht es, Einträge zur Verwendung für den Befehl "/helpop" zu erstellen. help:: ist der Begriff, der später dem /helpop Befehl als Parameter übergeben wird. Wird hier kein Begriff angegeben, wird das Feld so verwendet, wie wenn bei "/helpop" kein weiterer Parameter angegeben ist (also z.B. eine globale Hilfe Übersicht). Die Einträge für den "help Block" sind der Text, der später dem User nach der Eingabe von "/helpop" angezeigt werden.

4.34 - Offizielle Channels Block OPTIONAL (Früher nicht vorhanden)

Syntax:

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

Offizielle Channels werden in der Channelliste (/list) auch angezeigt, wenn keine User im Channel sind. Das topic ist optional und wird nur angezeigt, wenn der Channel 0 User hat.

Beispiel:

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 OPTIONAL (Früher nicht vorhanden)

Mit dem Spamfilter Block kann man lokale (nicht netzweite) Spam Filter festlegen.
Siehe auch Features - Spamfilter für genauere Erläuterungen zu Spam Filtern.
Syntax:
spamfilter {
regex <word>;
target { <target(s)> };
action <action>;
reason <reason>;
ban-time <time>;
};
regex ist der Ausdruck, auf den geprüft wird.
target gibt die Ziele an. Eine Liste möglicher Ausdrücke (z.B.: 'channel') kann hier nachgelesen werden..
action gibt die Aktion an, die erfolgen soll. Eine Liste möglicher Aktionen (z.B.: 'gline') kann hier nachgelesen werden.
reason ist optional und legt den Grund für die Aktion fest, der dem User angezeigt wird. Der Text ist in Anführungszeichen anzugeben und sollte - anders als beim /spamfilter Befehl - keinerlei Undersores "_" zwischen den Worten enthalten (andernfalls werden die Underscores mit angezeigt).
ban-time ist optional und legt die Zeit für einen *line/shun Bann fest. Ohne Angabe gilt der Default von 1 Tag.
Beispiele:

spamfilter {
regex "Come watch me on my webcam";
target { private; channel; };
action gline;
reason "Du hast einen Trojaner, bitte schaue hier nach: www.antivirus.xx/blah/virus=GrrTrojan";
ban-time 6h;
};
spamfilter {
regex "come to irc\..+\..+";
target { private; channel; };
action gline;
reason "Kein Spam erlaubt"
};

4.36 - Cgiirc Block OPTIONAL

Im Cgiirc Block können Host Manipulationen für vertraute CGI:IRC Gateways konfiguriert werden (weitere Informationen).

Syntax:

    cgiirc {
    	type <webirc|old>;
    	username <mask>; /* optional */
    	hostname <mask>;
    	password <password>; /* only for type webirc */
    };

type ist entweder 'webirc' oder 'old'.
username wird auf die Ident geprüft (wenn angegeben). Falls nicht definiert, wird '*' angenommen.
hostname ist die Hostmaske, auf die geprüft wird.
password ist das webirc Passwort, wird nur beim Typ 'webirc' benutzt.

Konfiguration mit der 'webirc' Methode (empfohlene Methode)
In der CGI:IRC Konfigurationsdatei (cgiirc.conf) wird für "webirc_password" ein gutes Passwort festgelegt.
Danach wird in der unrealircd.conf ein cgiirc block eingetragen, um diesen Host mit diesem Passwort zu erlauben.
Dann wird für 'set cgiirc::type' "webirc" eingetragen.
Beispiel:
In die CGI:IRC Konfigurationsdatei (cgiirc.conf) wird eingetragen:

    webirc_password = LpT4xqPI5

Danach wird die unrealircd.conf um einen Cgiirc Block erweitert:

    cgiirc {
    	type webirc;
    	hostname "1.2.3.4";
    	password "LpT4xqPI5";
    };

Konfiguration mit Methode 'old'
ACHTUNG: Dies ist nicht die empfohlene Methode, da sie zwei Nachteile hat: Diese Methode sendet den IP/Host, der zu verändern ist, als ein Server Passwort, was bedeutet, als CGI:IRC User kein Server Passwort angeben kann. Außerdem ist die Zugriffskontrolle nur IP-basiert und erfordert kein Extra Passwort, wie die 'webirc' Methode. Kurz gesagt sollten Sie nicht diese Methode nur verwenden, wenn es einen triftigen Grund dazu gibt.
In der CGI:IRC Konfigurationsdatei (cgiirc.conf) wird 'realhost_as_password' auf 1 gesetzt.
Danach wird die unrealircd.conf um einen Cgiirc Block erweitert, um diesen Host zu erlauben.
Beispiel:
In die CGI:IRC Konfigurationsdatei (cgiirc.conf) wird eingetragen:

    realhost_as_password = 1

Danach wird die unrealircd.conf um einen Cgiirc Block erweitert:

    cgiirc {
    	type old;
    	hostname "1.2.3.4";
    };

4.37 - Set Block ERFORDERLICH (Früher bekannt als unrealircd.conf/networks file)

Im Set Block findet sich das, was früher in der networks/unrealircd.conf und der networks Datei von UnrealIRCd angegeben wurde. In Einzel-Server Netzwerken kann man die Set Anweisungen einfach in die unrealircd.conf eintragen, während es empfehlenswert ist, in größeren Netzwerken mit mehreren Servern weiterhin eine "networks" Datei zu verwenden.

Wenn nämlich der Server in ein Netzwerk eingebunden ist, werden wahrscheinlich überall die selben "Set" Einstellungen verwendet, so dass es mehr Sinn macht, eine "network" Datei zu verwenden, die mit der include Anweisung eingebunden wird. Weiter unten werden sämtliche möglichen "Set" Anweisungen im Einzelnen beschrieben.

In dieser Dokumentation werden Einstellungen / Anweisungen im <block-name>::<block-directive> Format angegeben. Dieses Format kann jedoch NICHT so in die unrealircd.conf eingetragen werden! Die Angaben MÜSSEN in das nachfolgend beschriebene Format konvertiert werden! Die Darstellung im vereinfachten Format dient nur der vereinfachten Beschreibung der möglichen Einstellungen.

Syntax:

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

Im "Set Block" werden die Optionen für bestimmte Server Funktionen eingestellt. Jeder Eintrag bewirkt etwas anderes und deshalb wird jeder einzeln beschrieben. Es gibt viele zu berücksichtigende Anweisungen und alle nachfolgend beschriebenen Anweisungen können in EINER "Set" Definition eingetragen werden. Wenn eine Anweisung Optionen ermöglicht oder erfordert, werden diese genauso in der einzelnen "Set" Anweisung mit angegeben.

Beispiel:

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

Sollen die "Set" Anweisungen getrennt erfolgen, also z.B. die Optionen in einer einzelnen Zeile aufgeführt werden, ist auch dies möglich:.
Beispiel:
set { options { hide-ulines; no-stealth; }; };

set::kline-address <email-address>;
Eine email Adresse, an die Fragen zur K-Line gesandt werden sollen. Es muss hier ein Wert angegeben sein.

set::gline-address <email-address>;
Eine email Adresse, an die Fragen zur G-Line gesandt werden sollen.

set::modes-on-connect <+modes>;
Die Modi, die für einen User nach einer Verbindung eingestellt werden.

set::snomask-on-connect <+modes>
Die snomask (Server Notice mask), die für einen User nach einer Verbindung eingestellt wird.

set::modes-on-oper <+modes>;
Die Modi, die eingestellt werden, wenn User (berechtigterweise) den /oper Befehl verwenden.

set::snomask-on-oper <+modes>;
Die snomask (Server Notice mask), die eingestellt wird, wenn User (berechtigterweise) den /oper Befehl verwenden.

set::modes-on-join <+modes>;
Die Modi, die für einen Channel eingestellt werden, wenn er das erste mal (durch /join) erstellt wird. Nicht alle Modi sind mit diesem Befehl möglich. Die Modi +qaohvbeOAzlLk können NICHT durch diesen Befehl gesetzt werden.

set::restrict-usermodes <modes>
Die User-Modi, die User wählen können werden auf die hier angegebenen Modi eingeschränkt. (kein + oder - angeben!).
Beispielsweise kann man +G in 'modes-on-connect' setzen und G in 'restrict-usermodes', wodurch erreicht wird, dass sämtliche User +G erhalten, aber kein -G anwenden können.

set::level-on-join <op|none>
Die Modus, der einem User beim ersten joinen eines Channels gegeben wird. Das ist entweder 'op' (Channel Operator, Default) oder 'none', wenn kein Level gegeben werden soll. Default ist Op.

set::restrict-channelmodes <modes>
Die Channel-Modi, die User wählen können werden auf die hier angegebenen Modi eingeschränkt. (kein + oder - angeben!).
Beispielsweise kann man +G in 'modes-on-join' setzen und G in 'restrict-channelmodes', wodurch erreicht wird, dass sämtliche (neuen) Channels +G erhalten, aber kein -G eingestellt werden kann.
ACHTUNG: Es kann weiterhin möglich sein, diese Channel Modi durch Services über MLOCK zu benutzen. Wir können dagegen leider nichts tun, es obliegt den Codern der Services, ebenfalls ein restrict-channelmodes feature zu implementieren.

set::restrict-extendedbans <types|*>
Den Usern ist nicht gestattet, irgendwelche erweiterten Banns ("*") zu benutzen oder es werden nur bestimmte Typen verboten (z.B.:"qc").

set::auto-join <channels>;
Der oder die Channel(s), in den/die User beim Connect automatisch geforwardet werden. Soll mehr als ein Channel angegeben werden, so sind diese durch Kommata zu trennen.
[Achtung: nicht vergessen, Anführungszeichen zu verwenden, wie: auto-join "#chan";]

set::oper-auto-join <channels>;
Der oder die Channel(s), in den/die User bei /oper automatisch geforwardet werden. Soll mehr als ein Channel angegeben werden, so sind diese durch Kommata zu trennen.
[Achtung: nicht vergessen, Anführungszeichen zu verwenden, wie: auto-join "#chan";]

set::anti-spam-quit-message-time <timevalue>;
Eine Zeitangabe, in der festgelegt wird, wie lange ein User verbunden gewesen sein muss, bevor eine /quit Meldung angezeigt wird. Das dient der Vermeidung von Spam. Ein Zeitwert ist ein numerischer String, in dem 'd" Tage bedeutet, 'h' Stunden, 'm' Minuten und 's' Sekunden. Beispiel: 1d2h3m bedeutet 1 Tag, 2 Stunden und 3 Minuten.

set::prefix-quit <text-to-prefix-quit>;
Hier wird der Text festgelegt, der einer Quit Meldung vorangestellt wird. Ist hier eine 0 eingetragen, wird der Standard "Quit:" verwendet.

set::static-quit <quit message>;
Hiermit kann eine feste Quit Meldung eingestellt werden, die immer angezeigt wird, wenn ein Client ausloggt. Das kann die 'anti-spam-quit-message-time' ebenso überflüssig machen, wie das 'set::prefix-quit'. Fehlermeldungen werden NICHT durch diese Einstellung ersetzt! (z.B. wird "ping timeout" weiterhin angezeigt)

set::static-part <no|yes|part message>;
Ein Wert von 'yes' unterdrückt sämtliche Kommentare bei 'part', ein Wert von 'no' läßt 'part' wie gewohnt arbeiten, jede andere Angabe wird als Kommentar für 'part' fest eingestellt (z.B.: static-part "Bye!"). Da dies auch als belästigend empfunden werden kann, sollte man dies mit Bedacht wählen.

set::who-limit <limit>;
Stellt den Maximalwert ein, wie viele Angaben bei einem /who angezeigt werden sollen. Ohne Eintrag hier gibt es kein Limit.

set::silence-limit <limit>;
Stellt den Maximalwert der anzeigbaren SILENCE Einträge ein. Ohne Eintrag ist hier ein Limit von 15 voreingestellt.

set::maxbans <limit>;
Stellt den Maximalwert der je Channel erlaubten Banns (+b) ein. Der Defaultwert beträgt 60. Wenn dieser Wert geändert wird, sollte man sich versichern, dass auch der Wert für 'maxbanlength' (siehe nächster Punkt) sinnvoll eingestellt ist.

set::maxbanlength <limit>;
Ähnliche Funktion wie im Punkt zuvor, aber legt den Maximalwert der Zeichen für alle Banns zusammen fest. Dadurch wird festgelegt, wie viel Speicherplatz für alle Banns in einem Channel zusammen benutzt wird. Der Default beträgt 2048 (Bytes). Bei einem Default von 'set::maxbans 60' gestattet dies 2048:60=34 Zeichen je Bann im Durchschnitt.

set::oper-only-stats <stats-list>;
Definiert eine Liste von Stats-Flags, die nur von Opers benutzt werden können. Die Flags sind ohne Trennungen (keine Kommata, keine Leerzeichen) anzugeben. Wird hier nichts angegeben, können alle User sämtliche Flags benutzen, bei Angabe von '*' keines. Es dürfen nur kurze Operflags angegeben werden.

set::oper-only-stats {<stats-flag>; <stats-flag>;};
Definiert eine Liste von Stats Flags, die nur von Opers benutzt werden können. In dieser Syntax dürfen nur lange Operflags angegeben werden.

set::maxchannelsperuser <amount-of-channels>;
Einstellung, in wie vielen Channels ein User gleichzeitig sein darf.

set::maxdccallow <amount-of-entries>;
Legt fest, wie viele Einträge ein User in seiner DCCALLOW Liste haben kann.

set::allowed-nickchars;
Zeichensätze/Sprachen, die für Nicks erlaubt sind. Siehe auch hier: Nick Zeichensätze

set::channel-command-prefix <command-prefixes>;
Stellt das Vorzeichen für Services in "channel Befehlen" ein. Nachrichten, die mit einem dieser Zeichen beginnen, werden auch noch gesendet, wenn der Client +d ist. Die Voreinstellung lautet "`!.".

set::allow-userhost-change [never|always|not-on-channels|force-rejoin]
Einstellung, was passiert, wenn sich der user@host ändert (+x/-x/chghost/chgident/setident/vhost/etc).
never schaltet sämtliche Befehle ab, always gestattet so etwas auch in Channel immer (was zu desyncs von Clients führen kann) [default], not-on-channels bedeutet, dass solche Befehle nur erlaubt sind, wenn der User in keinem Channel ist, force-rejoin bewirkt einen rejoin in sämtlichen Channels sowie re-op/voice/etc falls notwendig.

set::options::hide-ulines;
Wenn dies eingestellt ist, werden Ulined Server bei /links von Nicht-Opers nicht angezeigt.

set::options::flat-map;
Wenn dies eingestellt ist, werden alle Server bei /map und /links als direkt gelinkt angezeigt. Dadurch kann man nicht mehr erkennen, welcher Server mit welchem gelinkt ist. Das ist eine kleine Hilfe gegen (D)DoS Attacken, weil potentielle Angreifer jetzt keine möglichen "Schwachpunkte" mehr erkennen können.

set::options::show-opermotd;
Falls eingestellt wird die opermotd den Usern angezeigt, die erfolgreich /oper benutzen.

set::options::identd-check;
Falls eingestellt, wird die Präsenz eines identd Servers geprüft und der Rückgabewert für den Usernamen verwendet. Wird kein Rückgabewert geliefert oder existiert der identd Server nicht, wird dem Usernamen ein '~' vorangestellt. Wird diese Einstellung ausgelassen, erfolgt keine Überprüfung.

set::options::show-connect-info;
Falls eingestellt, werden dem User beim Connect Notices wie "ident request", "hostname lookup", etc. angezeigt.

set::options::dont-resolve;
Wenn eingestellt, werden die Hosts connectender User nicht aufgelöst. Das kann nützlich sein, um die Verbindung zu beschleunigen, falls viele User keinen Host haben.
Zu beachten ist, dass man keine host basierten allow Blöcke verwenden kann, wenn dies eingestellt ist.

set::options::mkpasswd-for-everyone;
Stellt ein, dass /mkpasswd von jedem User verwendet werden kann und nicht nur von Opers. Die Anwendung dieses Befehls durch Nicht-Oper wird an die EYES snomask gesendet.

set::options::allow-part-if-shunned;
Erlaubt es Usern, auf die ein /shun gesetzt ist, den /part Befehl zu benutzen.

set::options::fail-oper-warn;
Falls gesetzt, wird ein User benachrichtigt, dass ein fehlgeschlagener Oper Zugriff geloggt wurde.

set::dns::timeout <timevalue>;
Ein Wert, der angibt, innerhalb welcher Zeit ein DNS Server zu antworten hat, bevor "timeout" gemeldet wird. Der Zeitwert ist ein numerischer String, in dem 'd' Tage bedeutet, 'h' Sunden, 'm' Minuten und 's' Sekunden. Beispiel: '1d2h3m' bedeutet 1 Tag, 2 Stunden, 3 Minuten. (NICHT IMPLEMENTIERT)

set::dns::retries <number-of-retries>;
Ein Zahlenwert, durch den festgelegt wird, wie oft versucht werden soll, die DNS aufzulösen, bevor ein Fehler gemeldet wird. (NICHT IMPLEMENTIERT)

set::dns::nameserver <name-of-dns-server>;
Gibt den Hostnamen des Servers an, der zur DNS Namensauflösungen dient. (NICHT IMPLEMENTIERT)

set::network-name <name-of-network>;
Gibt den Namen des Netzwerks an, in dem der Server läuft (also den Namen des irc Netzes!) Dieser Eintrag sollte auf allen Servern im Netzwerk absolut identisch sein.

set::default-server <server-name>;
Legt den Namen des Servers fest, der den Usern mitteilt, wo sie connecten sollen, wenn dieser Server voll ist.

set::services-server <server-name>;
Legt den Namen des Servers fest, zu dem die Services Bots verbunden sind. Muß angegeben sein, der Wert ist auf so etwas wie 'services.yournet.com' zu setzen, wenn man keine Services hat.

set::stats-server <server-name>;
Stellt den Namen des Servers ein, auf dem die Stats laufen. Die Angabe kann ausgelassen werden, wenn man keine Stats laufen hat.

set::help-channel <network-help-channel>;
Legt den Namen des Hilfe Channels in diesem Netzwerk fest.

set::cloak-keys { <"key1">; <"key2">; <"key3">; };
Stellt die Verschlüsselungs Keys ein, die für die Erstellung eines +x Host erforderlich sind. Diese Einstellung muss auf allen Servern identisch sein, ansonsten linken die Server nicht. Jeder Wert in 'set::cloak-keys::' muss ein String zwischen 5 bis 100 Zeichen sein (10-20 ist gut), der gemisch Großbuchstaben (A-Z), Kleinbuchstaben (a-z) und Ziffern (0-9) enthält. Diese Regeln gelten für cloak.so/cloak.dll, bei anderen Cloaking Modulen können andere Zeichen erlaubt/erforderlich sein. Es müssen exakt 3 Werte angegeben werden.

set::hiddenhost-prefix <prefix-value>;
Legt die ersten Zeichen eines verdeckten Hosts (+x) fest. Üblicherweise nimmt man hier 3 oder 4 Buchstaben, die den Netzwerksnamen bezeichnen.

set::hosts::local <locop-host-name>;
Legt den Hostnamen fest, der lokalen Operatoren zugewiesen wird, wenn sie +x setzen. Optional kann für diesen Wert ein username@host angegeben werden.

set::hosts::global <globop-host-name>;
Legt den Hostnamen fest, der globalen Operatoren zugewiesen wird, wenn sie +x setzen.Optional kann für diesen Wert ein username@host angegeben werden.

set::hosts::coadmin <coadmin-host-name>;
Legt den Hostnamen fest, der co-admins zugewiesen wird, wenn sie +x setzen.Optional kann für diesen Wert ein username@host angegeben werden.

set::hosts::admin <admin-host-name>;
Legt den Hostnamen fest, der Admins zugewiesen wird, wenn sie +x setzen.Optional kann für diesen Wert ein username@host angegeben werden.

set::hosts::servicesadmin <servicesadmin-host-name>;
Legt den Hostnamen fest, der Service-Admins zugewiesen wird, wenn sie +x setzen.Optional kann für diesen Wert ein username@host angegeben werden.

set::hosts::netadmin <netadmin-host-name>;
Legt den Hostnamen fest, der Netadmins zugewiesen wird, wenn sie +x setzen.Optional kann für diesen Wert ein username@host angegeben werden.

set::hosts::host-on-oper-up <yes/no>;
Falls auf 'yes' eingestellt, wird das H/get_host Flag akzeptiert und +x wird automatisch bei /oper gesetzt.. Falls 'no', muss sich der User manuell +x setzen, um einen oper Host zu erhalten.

set::ssl::egd <filename>;
Gibt an, dass EGD (Entropy Gathering Daemon) Unterstützung aktiviert wird. Hat man OpenSSL 0.9.7 oder höher laufen, dann wird /var/run/egd-pool, /dev/egd-pool, /etc/egd-pool, und /etc/entropy per Default gesucht und es ist kein Dateiname erforderlich. Dann legt man einfach 'set::ssl::egd' ohne Wert fest. Verwendet man ältere Versionen von OpenSSL, oder soll der EGD socket woanders als in den oben angegebenen Ordnern liegen, muss man den Dateinamen des UNIX Domain Socket angeben, an dem EGD lauscht.

set::ssl::certificate <filename>;
Gibt den Dateinamen an, wo das SSL Zertifikat des Servers liegt.

set::ssl::key <filename>;
Gibt den Dateinamen an, wo der private SSL Key des Servers liegt.

set::ssl::trusted-ca-file <filename>;
Gibt den Dateinamen der Zertifikate der vertrauten CAs an.

set::ssl::server-cipher-list <cipherlist>;
Legt fest, welche Verschlüsselungen erlaubt sind, was per Default für OpenSSL eingestellt ist. Siehe http://www.openssl.org/docs/apps/ciphers.html wie eine Liste von Verschlüsselungen erstellt wird (englische Seite, nicht übersetzt!).

set::ssl::renegotiate-bytes <value>;
Legt fest, wieviele Bytes bei einer SSL Session neu ausgehandelt werden sollen (z.B.: 20m für 20 Megabyte).

set::ssl::renegotiate-timeout <timevalue>;
Legt fest, nach welcher Zeit eine SSL Session neu ausgehandelt werden soll (z.B.: 1h für 1 Stunde).

set::ssl::options::fail-if-no-clientcert;
Stellt ein, dass Clients ohne Zertifikat nicht connecten können.

set::ssl::options::no-self-signed;
Verbietet Verbindungen von Usern mit selbst erstellten Zertifikaten.

set::ssl::options::verify-certificate;
Stellt ein, dass Unreal SSL Zertifikate auf Gültigkeit überprüft, bevor eine Verbindung akzeptiert wird.

set::ssl::options::no-starttls;
Deaktiviert STARTTLS. STARTTLS ermöglicht es Clients, über reguläere (nicht SSL) Ports zu verbinden.

set::throttle::period <timevalue>
Wie lange muss ein User zum erneuten Connecten warten, wenn er häufiger, als unter 'set::throttle::connections' eingestellt, verbunden war.

set::throttle::connections <amount>;
Wie oft muss ein User mit demselben Host verbinden, bevor er temporär gesperrt wird.

set::ident::connect-timeout <amount>;
Zeitangabe von Sekunden, ab wann aufgegeben wird zum Ident Server zu verbinden (Default: 10s).

set::ident::read-timeout <amount>;
Nach wie viele Sekunden Warten auf einen Reply soll aufgegeben werden (Default: 30s).

set::anti-flood::unknown-flood-bantime <timevalue>;
Gibt an, wie lang ein Flooder mit 'unknown connection' gebannt wird.

set::anti-flood::unknown-flood-amount <amount>;
Legt eine Datenmenge (in KiloBytes) fest, die eine ' unknown connection' senden muss, damit der User gekillt wird.

set::anti-flood::away-flood <count>:<period>
Schutz vor 'Away Flood': legt fest, wie viele ('count') /away Änderungen innderhalb welcher Zeit in Sekunden ('period') erfolgen dürfen.. Das erfordert, dass in der config.h die Einstellung 'NO_FLOOD_AWAY' aktiviert wurde. Beispiel: away-flood 5:60s; bedeutet maximal 5 Änderungen innerhalb von 60 Sekunden.

set::anti-flood::nick-flood <count>:<period>
Nickflood Schutz: Beschränkt Nickänderungen auf 'count' pro 'period' Sekunden. Beispiel: nick-flood 4:90 bedeutet maximal 4 Nickänderungen in 90 Sekunden. Default ist 3 per 60.

set::default-bantime <time>
Default Bann Dauer wenn /kline, /gline, /zline, /shun, etc ohne Zeitangabe gesetzt werden (wie /gline *@some.nasty.isp). Default ist permanent (0). Beispiel: default-bantime 90d; (90 Tage)

set::modef-default-unsettime <value>
Für den Channel Modus +f kann eine Default Abschaltzeit festgelegt werden. Wird z.B. der Wert 10 festgelegt, dann wird +f [5j]:15 in [5j#i10]:15 umgewandelt. Default ist keine Abschaltzeit.

set::modef-max-unsettime <value>
Maximalwert in Minuten für eine Modus +f Abschaltzeit (z.B. in +f [5j#i<TIME>]:15). Der Wert kann zwischen 0 und 254 liegen und Default ist 60 (= 1 Stunde).

set::ban-version-tkl-time <value>
Definiert man in 'ban version' eine Aktion, wie zline/gline/etc, dann kann man hier die Dauer des Banns auf die IP in Sekunden angeben. Default ist 86400 (1 Tag).

set::spamfilter::ban-time <value>
Genauso, wie oben, aber für *lines/shuns, die durch den Spam Filter gesetzt wurden.

set::spamfilter::ban-reason <reason>
Grund, der bei Einträgen durch /spamfilter gesetzt wird.

set::spamfilter::virus-help-channel <channel>
Festlegung des Channels für die Aktion 'viruschan' in Spamfilter

set::spamfilter::virus-help-channel-deny <yes|no>
Falls auf 'yes' (oder '1') gesetzt, erhält jeder normalen User, der versucht, diesen Channel zu joinen, die Antwort 'invite only'. Nur Opers, User, bei denen der Spamfilter zutrifft oder User, die eingeladen werden, können diesen Channel joinen.

set::spamfilter::except <target(s)>
Diese Ziele werden vom Spamfilter ausgenommen (es wird also keine Aktion durchgeführt). Es sind einzelne Ziele oder eine durch Kommata getrennte Liste möglich. Beispiel: except "#help,#spamreport"

set::spamfilter::slowdetect-warn <value>
Wenn ein Spamfilter zur Ausführung länger als der hier festgelegte Wert dauert (in Millisekunden, 1000ms = 1 Sekunde), wird eine Warnung per Notice an alle Opers versandt. (Default: 250). Siehe auch Erkennung langsamer Spamfilter.

set::spamfilter::slowdetect-fatal <value>
Wenn ein Spamfilter zur Ausführung länger als der hier festgelegte Wert dauert (in Millisekunden, 1000ms = 1 Sekunde), wird er gelöscht50o). Siehe auch Erkennung langsamer Spamfilter.

set::check-target-nick-bans <yes|no>
Wann immer ein User seinen Nick ändert, wird überprüft, ob der NEUE Nick zu bannen wäre. Ist das der Fall, wird der Nickwechsel nicht erlaubt. Default ist 'yes'.

set::timesynch::enabled<yes|no>
Aktiviert oder deaktiviert die Zeitsynchronisation beim Start des IRCd. Default ist 'yes'.

set::timesynch::server <IP>
Server mit dem die Zeit synchronisiert werden soll. Hier können bis zu 4 IP's angegeben werden, die durch Komma zu trennen sind. Die Server müssen das NTP Protokoll Version 4 unterstützen. Default ist die Benutzung von 3 Zeitservern (US, EU, AU). Die Anforderungen an diese Server erfolgen zeitgleich, die schnellste Antwort gewinnt.

set::timesynch::timeout <time>
Maximale Zeit, die auf eine Zeitserverantwort gewartet wird. Möglich ist ein Wert von 1 bis 5, mehr ist nicht möglich, weil das Ergebnis sonst zu ungenau wäre. Default Einstellung ist hier 3 und normalerweise sollte es keinen Grund geben, dies zu ändern.

set::pingpong-warning<yes|no>
Die Versuche von Name-Servern einen falschen Hostnamen zurückzuliefern, werden Spoofing (Reinlegen) genannt. Um sich davor zu schützen, kann der Resolver so konfiguriert werden, daß er überprüft, ob die gegebene IP-Adresse auch tatsächlich zum erhaltenen Hostnamen gehört. Wenn dies nicht der Fall ist, wird der Name verworfen und ein Fehler zurückgeliefert. Dieses Verhalten wird mit nospoof on eingestellt. Wenn NOSPOOF aktiviert ist (üblicherweise in Windows), wird aene Warnung an jeden User geschickt, '/quote pong ..' zu benutzen, wenn es beim Verbinden Probleme gibt. Voreingestellt ist 'no'.

set::watch-away-notification <yes|no>
Ermöglicht eine AWAY Meldung in WATCH. Der Default is yes.

4.38 - Files Block OPTIONAL

Es ist nicht nötig, für die Default Speicherorte der MOTD und Rules Dateien einen TLD block zu definieren. Der Files Block steuert die Default Einstellungen für diese Dateien und zusätzlich für die pidfile und irc.tune file. Für alles, was hier nicht angegeben ist, wird der Defaultwert genommen, wie er in Additional Files steht.

Relative Pfadnamen werden als relativ zum unrealIRCD Startverzeichnis interpretiert, in dem normalerweise auch die `unrealircd.conf` steht. Dieser Block kan dazu benutzt werden, mehr als einen IRCd im gleichen Verzeichnis laufen zu lassen. In diesem Fall sollten mindestens verschiedene pidfiles und tunefiles definiert werden - eines für jeden Server.

Syntax:

    files {
    	motd <motd file>;
    	shortmotd <short motd file>;
    	opermotd <oper motd file>;
    	svsmotd <services motd file>;
    	botmotd <bot motd file>;

    	rules <rules file>;

    	tunefile <tune file>;
    	pidfile <pid file>;
    };

Beispiel:

    files {
    	motd /etc/motd;

    	pidfile /var/lib/run/unrealircd.pid;
    };

5 – Additional Files

Zusätzlich zu den Konfigurationsdateien hat Unreal einige weitere Dateien, wie MOTD, OperMOTD, BotMOTD, und Rules. In der nachfolgenden Liste stehen die Namen dieser dateien und ihr Verwendungszweck.
Zu beachten ist, dass die motd Dateien (alle Typen) und die rules Dateien auch in einem speziellen tld Block oder einem files Block angegeben sein können. Dies sind nur die Dateien, die per Default benutzt werden (und für Anforderungen von MOTD/RULES).

ircd.motd | Wird angezeigt, wenn der /motd Befehl ausgeführt wird und wenn ein User connected
ircd.rules | Wird angezeigt, wenn der /rules Befehl ausgeführt wird
oper.motd | Wird angezeigt, wenn der /opermotd Befehl ausgeführt wird, oder wenn man /oper (erfolgreich) benutzt
bot.motd | Wird angezeigt, wenn der /botmotd Befehl ausgeführt wird.

6 – User & Channel Modi

Mode | Beschreibung
Channel Modi
A | Nur ein Administrator kann joinen
a <nick> | Macht einen User zum Channel Admin
b <nick!user@host> | Bannt den angegebenen User vom Channel
c | Es können keine ANSI Farbcodes im Channel benutzt werden
C | Es sind keine CTCP's im Channel erlaubt
e <nick!user@host> | Bann Ausnahme – Wenn für jemanden dieser user@host zutrifft, kann er auch dann in den Channel joinen, wenn auf ihn eine Ban-Mask passt.
f * <lines:seconds> | Channel Flood Schutz. Siehe Abschnitt 3.12 für detailliertere Informationen
G | 'G rated'. Es werden Worte im Badword Block überprüft und bei Vorhandensein durch die dort angegebenen Worte esetzt.
h <nick> | Gibt dem User Half-Op Status
i | Es ist eine Einladung (/invite) erforderlich, um diesen Channel zu joinen
I | Invite Ausnahme ("invex") - Falls jemand hierzu passt, kann eine +i Einstellung umgangen werden, um den Channel zu betreten.
j<joins:sekunden> | Beschränkt die Joins des Users auf die angegebenen Sekunden
K | Der Befehl /knock ist nicht erlaubt
k <key> | Stellt ein, dass man einen 'key', ein Passwort, benötigt, um joinen zu können
l <##> | Stellt die maximale Anzahl von Usern im Channel ein
L <Chan> | Wenn so viele User, wie bei +l eingestellt ist, im Channel sind, werden weitere User in diesen Channel geforwardet
M | Nur registrierte Nicks(+r) können im Nachrichten in den Channel senden
m | Moderierter Channel. Nur +v/o/h User können Nachrichten in den Channel senden
N | Kein Wechsel des Nicknamens erlaubt
n | Keine Nachrichten von außerhalb des Channels erlaubt
O | Nur IRCOps dürfen joinen
o <nick> | Gibt dem User Channel Op Status
p | Macht einen Channel privat
q <nick> | Stellt den Channel Owner ein
Q | Nur U:Lined Server können User kicken
R | Erfordert einen registrierten Usernamen, um joinen zu können
S | Löscht sämtliche eingehenden Farbcodes
s | Macht den Channel geheim (Wird bei /list nicht mehr angezeigt)
t | Nur ein Channel Op kann das Topic verändern
T | Im Channel sind keine NOTICE's gestattet
u | Auditorium – Bewirkt, dass /names und /who #channel nur Channel OPs angezeigt wird
V | Der Befehl /invite ist nicht erlaubt
v <nick> | Gibt dem User voice Status. (Darf in +m Channels schreiben)
z | Nur Clients mit einer Secure (SSL) Verbindung dürfen joinen

Mode | Beschreibung
User Modi
A | Server Admin (wird im Oper Block eingestellt)
a | Services Admin (wird im Oper Block eingestellt)
B | Markiert User als Bot
C | Co-Admin (wird im Oper Block eingestellt)
d | User kann keine Channel PRIVMSGs empfangen (mit der Ausnahme von Text, dem bestimmte Zeichen vorangestellt sind. Siehe hierzu: 'set::channel-command-prefix'.
G | Filtert Badwords per Konfiguration aus
g | Kann Globops und Locops lesen und senden
H | IRCop Status verbergen (nur IRCops)
h | Verfügbar für Hilfe (HelpOp, wird im Oper Block eingestellt)
i | Unsichtbar (wird bei /who nicht angezeigt)
N | Network Administrator (wird im Oper Block eingestellt)
o | Globaler IRC Operator (wird im Oper Block eingestellt)
O | Lokaler IRC Operator (wird im Oper Block eingestellt)
p | Zeigt bei einer /whois Antwort nicht die Channels an, in denen man ist
R | Gestattet es, PRIVMSGs/NOTICEs nur von registrierten (+r) Usern zu empfangen
r | Identifiziert einen Nick als registriert
S | Zum Schutz von Services Daemons
s | Kann Server Notices lesen
T | Schützt vor dem Empfang von CTCPs
t | zeigt, dass der User einen /vhost benutzt
V | WebTV User
v | Empfängt Rejection Notices, wenn bei DCC File infiziert ist
W | User kann sehen, wenn ein anderer User auf ihn ein /whois auf ihn ausführt (nur IRCops)
w | Kann wallop Nachrichten empfangen
x | Verschlüsselt den Hostnamen des Users (vgl. Cloaking)
z | Zeigt an, dass man einen SSL Client benutzt

7 – User & Oper Befehlsliste

ACHTUNG: die /helpop Dokumentation ist aktueller, nutze /helpop Befehl (oder /helpop ?Befehl wenn Du Oper bist), um zusätzliche Informationen über einen Befehl zu erhalten.

Befehl | Beschreibung | Wer
nick <neuernickname> | Ändert Deine Online Identität auf dem Server. Alle in den Channels, in denen Du bist, werden über den Wechsel des Nicknamens benachrichtigt. | Alle
whois <nick> | Zeigt Informationen über den User, für den der Befehl ausgeführt wurde an, wie den Name, Channels in denen der User aktuell ist, Hostmask, etc. | Alle
who <mask> | Mit /who kann man User enstprechend einer Maske suchen. Maske beinhaltet: nickname, #channel, hostmask (*.attbi.com) Siehe auch /helpop ?who | Alle
whowas <nick> <maxreplies> | Liefert Informationen über User, die nicht mehr zum Server verbunden sind. Das <max replies> Feld ist optional und schränkt ggf. die Anzahl der Antworten ein. | Alle
ison <nick1 nick2 nick3 ...> | Überprüfung, ob bestimmte User mit angegebenem Nicknamen momentan online sind. Einfache Rückgabe, wird meist in Scripts verwendet | Alle
join <channel1,channel2, ...> | Damit betritt man einen Channel. Durch den Befehl /join #channel1, #channel2, #channel3 kann man mehr als einen Channel gleichzeitig aufschalten. Der Befehl /join 0 bewirkt, dass Channels verlassen werden. | Alle
cycle <channel1, channel2, ...> | Dieser Befehl ist gleichbedeutend mit /part und nachfolgendem /join. | Alle
motd <server> | Zeigt die Message Of The Day des IRC Servers an, auf dem man eingeloggt ist. Dabei handelt es sich um eine Information über den Server. Bei Angabe eines Servers erhält man die Motd des entsprechenden Servers. | Alle
rules <server> | Zeigt die Regeln des Servers an, mit dem man verbunden ist. Bei Angabe eines Servers erhält man die Regeln des entsprechenden Servers. | Alle
lusers <server> | Liefert Informationen über die Anzahl lokaler und globaler User und die maximal erreichte Userzahl. Bei Angabe eines Servers erhält man die Werte für diesen Server. | Alle
map | Zeigt eine (pseudo-)grafische Netzwerks Karte an, aus der die Struktur des IRC Netzwerkes hervorgeht. Das wird hauptsächlich zu Routing Zwecken benötigt. | Alle
quit <reason> | Beendet die Verbindung zum IRC Server. Wird ein Grund angegeben, wird dieser in allen Channels angezeigt, die man verlässt | Alle

ping <user>

Der Ping Befehl dient dazu, die Anwesenheit eines Users oder Servers auf der anderen Seite der Verbindung zu überprüfen. Server senden in regelmäßigen Abständen eine PING Nachricht, wenn keine andere Aktivität von der anderen Seite aus eingeht. Wird eine solche Ping Nachricht nicht innerhalb einer festgelegten Zeit beantwortet, wird die Verbindung beendet. Eine Ping Nachricht kann auch bei einer aktiven Verbindung gesendet werden. Zu beachten ist, dass dies unterschiedlich zum CTCP PING Befehl ist.

Alle

version <nick> | Sendet eine CTCP Versions Anfrage an den User. Dessen Client sendet, falls entsprechend konfiguriert, die Client Version als Antwort. | Alle
links | Listet sämtliche Server auf, die momentan zum Netzwerk verbunden sind. Je nach Einstellung können möglicherweise nur IRCops gelinkte U-lined Servers /Services sehen. | Alle
Admin <server> | Liefert Informationen über die Administration des Servers. Wird ein Servername mit angegeben, werden die Admin Infos dieses Servers angezeigt. | Alle
userhost <nick> | Zeigt den userhost des angegebenen Nicknamen an. Wird üblicherweise von Scripts oder Bots benutzt. | Alle
topic <channel> <topic> | Setzt oder ändert das Topic des angegebenen Channels oder zeigt das aktuelle Topic an. Topic <channel> zeigt das aktuelle Topic, Topic <channel> <topic> ändert das Topic des angegebenen Channels. | Alle
invite <nick> <channel> | Sendet einem User eine Einladung, einen bestimmten Channel zu betreten. Man muss Oper im Channel sein, um einen User einladen zu können. | ChanOp
kick <channel, channel> <user, user> <reason> | Entfernt einen User aus einem Channel. Kann nur von Operators oder HalfOps benutzt werden. Ein Grund kann mit angegeben werden. | ChanOp
away <reason> | Stellt den eigenen Online Status auf "Away" ein. Ein Grund kann mit angegeben werden (und wird dann bei /whois auch angezeigt). | Alle

Watch +-<nick> +-<nick>

Watch ist ein Benachrichtigungssystem welches schneller und ressourcenschonender arbeitet, als das alte Notify System. Der Server sendet eine Nachricht an einen selbst, wann immer ein User, der in der eigenen "Watch" Liste steht, ein- oder ausloggt.
Die Watch Liste wird nicht gespeichert, man muß über den eigenen Client oder ein Script bei jeder neuen Verbindung dafür sorgen, dass sie erneut an den Server übertragen wird. D.h. der Watch Befehl ist dann erneut einzugeben.

Alle

helpop ?<topic> or !<topic>

HelpOp ist ein System, um IRC Server Hilfe zu bekommen. Man gibt entweder ein "/HELPOP ? <help system topic>" oder "/HELPOP ! <question>". Das "?" in /HELPOP bedeutet, dass das Hilfesystem befragt wird und wenn man keine Antwort erhält, kann man die Frage mit '!' einem Help Operator online senden. Benutzt man weder ? noch !, bedeutet das, dass zunächst im Hilfe System gefragt wird und, wenn nichts passendes gefunden wird, ein Forward an die Help Operators erfolgt.

Alle

list <search string>

Ohne Angabe eines Suchstrings wird defaultmäßig die ungefilterte gesammte Channel Liste angezeigt. Nachfolgend Optionen, die man benutzen kann und die Ergebnisse, die LIST dann liefert:
/list >zahl Zeigt Channels mit mehr als <zahl> Usern an.
/list <zahl Zeigt Channels mit weniger als <zahl> Usern an.
/list C>zahl Channels, die in den letzten <zahl> Minuten eröffnet wurden.
/list C<zahl Channels, die vor mehr als <zahl> Minuten eröffnet wurden.
/list T>zahl Channels, deren topic älter als <zahl> Minuten ist.
/list T<zahl Channels, deren topic neuer als <zahl> Minuten ist.
/list *mask* Channels, deren Name zur angegebenen Maske passt.
/list !*mask* Channels, deren Name nicht zur angegebenen Maske passt.

Alle

Knock <channel> <message> | Ermöglicht es, in einem invite only Channel "anzuklopfen" und um eine Einladung zu bitten. Funktioniert nicht in Channels, in denen +K und/oder +V gesetzt ist. Auch wer gebannt ist, kann diesen Befehl nicht benutzen. | Alle
setname | Ermöglicht es Usern, ihren ‘Real Name’ ohne reconnecting zu ändern. | Alle
vhost <login> <password> | Verbirgt den eigenen Host durch Anzeige eines vom Server gelieferten virtuellen Hosts. | Alle
mode <chan/nick> <mode> | Ermöglicht es, Channel- oder User-Modi zu setzen oder zu ändern. Siehe auch Liste der Modi in User & Channel Modi | Alle
credits | Zeigt eine Dankesliste der Unterstützer von UnrealIRCD an. | Alle
license | Zeigt die GNU Lizenz an | Alle
time <server> | Zeigt Datum und Zeit des Servers an. Die Angabe des Servers ermöglicht es, Datum und Zeit aller Server im Netz zu überprüfen. | Alle
botmotd <server> | Zeigt die botmotd (Bot Message Of The Day) an. Bei Angabe eines Servers, wird dessen botmotd angezeigt. | Alle
identify <password> | Schickt das eigene Passwort an die Services, um den eigenen Nick zu identifizieren. | Alle
identify <channel> <password> | Schickt das eigene Passwort an die Services, um sich als Owner eines Channels zu identifizieren. | Alle
dns <option> | Liefert Informationen des DNS Cache des Servers. Da viele Clients einen eingebauten DNS Befehl haben, wird man den Befehl meist in der Form /raw DNS eingeben müssen, um das gewünschte Ergebnis zu erhalten. Opers dürfen eine 1 als ersten Parameter angeben, um eine Liste der Einträge im DNS Cache zu erhalten. | Alle
userip <nick> | Liefert die IP des angefragten Nicknamen | Alle
oper <userid> <password> | Befehl, um dem User IRCOp Status zu geben, wenn userid und passwort mit den Angaben im Operblock übereinstimmen. | IRCop
wallop <message> | Schickt eine Nachricht an alle User mit dem Usermode +w | IRCop
globops <message> | Schickt eine Nachricht an alle globalen IRCops | IRCop
chatops <message> | Schickt eine Nachricht an alle IRCops (lokal und global) | IRCop
locops <message> | Schickt eine Nachricht an alle lokalen IRCops | IRCop
adchat <message> | Schickt eine Nachricht an alle Admins | IRCop
nachat <message> | Schickt eine Nachricht an alle Net Admins | IRCop
kill <nick> <reason> | Disconnected (killt) einen User vom Netzwerk. | IRCop

kline [+-]<user@host> [<time to ban> <reason>]

Bannt die Host Mask von dem Server, auf dem die Line gesetzt wurde. Eine kline ist kein globaler Bann. time to ban ist entweder a) ein Wert in Sekunden, b) ein Zeitwert, wie '1d' für1 Tag, oder c) '0' für permanent. Zeit und Grund sind optional, falls nicht angegeben, werden der Werte aus 'set::default-bantime (Default: 0/permanent) und 'no reason' verwendet. Um eine kline zu löschen, benutzt man den Befehl /kline -user@host.

IRCop

zline [+-]<*@ip> [<time to ban> <reason>] | Bannt eine IP Adresse vom lokalen Server, auf dem die Line gesetzt wurde (nicht global). Siehe bei kline für genauere Informationen zur Syntax. Zum Löschen benutzt man /zline -*@ip. Gibt man bei zline statt einer IP einen Host an, so wirkt sie wie eine kline. | IRCop
gline [+-]<user@host>| nick> [<time to ban> <reason>] | Setzt einen globalen Bann auf alle, auf die die Maske zutrifft. Siehe bei kline für genauere Informationen zur Syntax. Zum Löschen benutzt man /gline -user@host. | IRCop
shun [+-]<user@host | nick> [<time to shun> <reason>] | Bewirkt, dass der User KEINERLEI Befehle auf dem Server mehr ausführen und auch nichts mehr schreiben kann. Shuns sind global (wie glines) Siehe bei kline für genauere Informationen zur Syntax. Zum Löschen benutzt man /shun -user@host.. | IRCop
gzline [+-]<ip> <time to ban> :<reason> | Setzt eine globale zline (Bann auf IP). Siehe bei kline für genauere Informationen zur Syntax. Zum Löschen benutzt man /gzline -*@ip. Gibt man bei gzline statt einer IP einen Host an, so wirkt sie wie eine gline. | IRCop

rehash <server> –<flags>

Rehasht die Config Datei des Servers (liest sie neu ein). Indem man den Server Namen angibt, kann man die Config Datei dieses Servers remote rehashen. Ebenso sind einige Flags möglich:
-all - Rehasht sämtliche Config Dateien
-motd - Rehasht alle MOTD und RULES Dateien (incl. tld {})
-opermotd - Rehasht die OPERMOTD
-botmotd - Rehasht die BOTMOTD
-garbage - Bewirkt Garbage Collection (Garbage Collection ist eine Methode, mit der nicht mehr verwendeter Speicher automatisch freigegeben wird).

IRCop

restart <password> <reason> | Restartet den IRCD Prozess. Das Passwort ist erforderlich, wenn ein drpass {} Block definiert ist. Man kann hier auch einen Grund mit angeben. | IRCop
die <password> | Beendet den IRCD Prozess. Das Passwort ist erforderlich, wenn ein drpass {} Block definiert ist. | IRCop
lag <server> | Dieser Befehl ähnelt einem TraceRoute für IRC server. Nach Eingabe von z.B. /lag irc.fyremoon.net erhält man Antwort von jedem Server mit Zeit. Nützlich, um herauszufinden, wo ein Lag ist und optional (TS future/past travels [??]) | IRCop
sethost <newhost> | Ermöglicht es, den eigenen vHost zu was immer man möchte, zu ändern. | IRCop
setident <newident> | Ermöglicht es, die eigene Ident zu was immer man möchte, zu ändern. | IRCop
chghost <nick> <newhost> | Ermöglicht es, den Host eines Users, der online ist, zu ändern. | IRCop
chgident <nick> <newident> | Ermöglicht es, den Ident eines Users, der online ist, zu ändern. | IRCop
chgname <nick> <newname> | Ermöglicht es, den Real Name eines Users, der online ist, zu ändern. | IRCop
squit <server> | Entfernt einen Server aus dem Netzwerk. | IRCop
connect <server> <port> <server> | Wenn nur ein Server angegeben ist, wird versucht, den Server, auf dem man aktuell ist, zum zweiten Server zu verbinden. Sind 2 Server angegeben, wird versucht, die beiden Server miteinander zu verbinden. Ein Leaf ist an erster Stelle anzugeben, ein Hub an zweiter Stelle. | IRCop
dccdeny <filemask> <reason> | Setzt ein DCCDENY für diese Dateimaske. Verhindert, dass diese Datei gesendet wird. | IRCop
undccdeny <filemask> | Löscht ein DCCDENY | IRCop
sajoin <nick> <channel>, <channel> | Zwingt einen User den/die angegebenen Channels zu joinen. Steht nur Services und Admins zur Verfügung. | IRCop
sapart <nick> <channel>, <channel> | Zwingt einen User den/die angegebenen Channels zu verlassen. Steht nur Services und Admins zur Verfügung. | IRCop
samode <channel> <mode> | Erlaubt es Netadmins und Service-Admins die Modi eines Channels zu ändern, ohne dort Channel Op zu sein. | IRCop
rping <servermask> | Berechnet den Lag zwischen Servern in Millisekunden. | IRCop
trace <servermask|nickname> | Auf einen User angewandt, liefert dieser Befehl die Klasse und ein Lag Info. Für einen Server wird Klasse / Version und Link Info angezeigt. | IRCop
opermotd | Zeigt die OperMotd Datei des Servers an. | IRCop
addmotd :<text> | Fügt den gegebenen Text an das Ende der Motd an. | IRCop
addomotd :<text> | Fügt den gegebenen Text an das Ende der OperMotd an. | IRCop
sdesc <newdescription> | Gestattet es Server Admins den Eintrag mit der Beschreibung des Servers zu ändern, ohne dass ein Restart erforderlich ist. | IRCop
addline <text> | Ermöglicht die Ergänzung der Unrealircd.conf um die in <text> angegebenen Zeilen. | IRCop
mkpasswd <password> | Verschlüsselt ein Clear Text Passwort zum Eintrag in die Unrealircd.conf. | IRCop
tsctl offset +/- <time> | Stellt die IRCD interne Uhr nach (NICHT benutzen, wenn man nicht genau versteht, was dieser Befehl tut!). | IRCop
tsctl time | Liefert einen TS Report. | IRCop
tsctl alltime | Liefert einen TS Report ALLER Server. | IRCop
tsctl svstime <timestamp> | Stellt die TS Zeit aller Server (NICHT benutzen, wenn man nicht genau versteht, was dieser Befehl tut!). | IRCop

htm <option>

Steuert Einstellungen, die sich auf den High Traffic Modus beziehen. Der High Traffic Modus (HTM) deaktiviert einige User Befehle, wie /list, /whois, /who etc als Antwort auf extrem hohen Traffic auf dem Server. Mögliche Optionen sind:
-ON Schaltet HTM für den Server ein
-OFF Schaltet HTM für den Server aus
-NOISY Der Server benachrichtigt users/admins bei Wechsel in oder aus HTM Modus
-QUIET Der Server benachrichtigt NIEMANDEN bei HTM Modus Wechsel
-TO <value> Stellt die Traffic Rate ein, ab der HTM aktiviert wird.

IRCop

stats <option>

B - banversion - Anzeige der Bann auf Version Liste
b - badword - Anzeige der Badword Liste
C - link - Anzeige der Liste geblockter Links
d - denylinkauto - Anzeige der Liste geblockter Links (deny link (auto)
D - denylinkall - Anzeige der Liste geblockter Links (deny link (all)
e - exceptthrottle - Anzeige der Ausnahmen bei throttle block
E - exceptban - Anzeige der Ausnahmen von Banns und der TKL Liste
f - spamfilter - Anzeige der Spamfilter Liste
F - denydcc - Anzeige der Liste geblockter DCCs
G - gline - Anzeige der Liste von glines und gzlines
Erweiterte Flags: [+/-mrs] [mask] [reason] [setby]
m Liefert glines, die zur angegebenen Maske passen/nicht passen
r Liefert glines, die zum angegebenen Grund passen/nicht passen
s Return glines, die von angegebenem Namen gesetzt/nicht gesetzt wurden
I - allow - Anzeige der Allow block Liste
j - officialchans - Liste der offiziellen Channels
K - kline - Liste der User/Bann und IP/Ausnahmen
l - linkinfo - Anzeige von Link Informationen
L - linkinfoall - Anzeige aller Link Informationen
M - command - Anzeige, wie oft jeder Befehl benutzt wurde
n - banrealname - Liste von Banns auf Realname
O - oper - Liste der Opers
P - port - Liste verwendeter Ports
q - sqline - Anzeige der SQLINE Liste
Q - bannick - Anzeige der Liste gebannter Nicks
r - chanrestrict - Anzeige der Liste verbotener Channels
R - usage - Zeigt Benutzungs Informationen an
S - set - Liste der Einträge im set Block
s - shun - Liste der Shuns
Erweiterte Flags: [+/-mrs] [mask] [reason] [setby]
m Liefert shuns, die zur angegebenen Maske passen/nicht passen
r Liefert shuns, die zum angegebenen Grund passen/nicht passen
s Return shuns, die von angegebenem Namen gesetzt/nicht gesetzt wurden
t - tld - Zeigt die tld Block Liste an
T - traffic - Zeigt Traffic Informationen an
u - uptime - Gibt an, wielange der Server schon up ist und wie viele User max
U - uline - Anzeige der ulines (Services)
v - denyver - Anzeige der deny version Block Liste
V - vhost - Anzeige der vHosts (soweit im vHost Block gesetzt)
X - notlink - Liste der Server, die momentan nicht gekinkt sind
Y - class - Anzeige Klassen im class Block
z - zip - Anzeige der Kompression bei ziplinked Servern (wenn mit ziplink Unterstützung kompiliert wurde)
Z - mem - Anzeige, für welche Zwecke wie viel Speicher benutzt wird

Admin

module | Anzeige aller geladenen Module | Alle
close | Dieser befehl disconnected alle unbekannten Verbindungen vom Server. | IRCOp

8 – Sicherheits Tipps/Checkliste

Wenn man um die Sicherheit besorgt ist (und das sollte man sein!), findet man in diesem Abschnitt Hilfe, um einen Überblick über Risiken und deren Bedeutung zu erhalten. Man kann diesen Abschnitt auch als "Checkliste" benutzen, um die Netzwerk Konfiguration zu überprüfen und sie sicherer zu machen.

Die Liste ist nach Popularität/Risiko und Level der am meisten verwendeten Methoden bei Attacken geordnet:

8.1 Passworte

Wähle gute Oper Passworte, Link Passworte, etc:
- benutze eine Mischung aus Groß -und Kleinschreibung und Ziffern ("Whbviwf5") und/oder etwas Langes ("blaheatsafish", "AlphaBeta555").
- VERWENDE KEINE link/oper Passwords für andere Zwecke, wie Mail Account, Bot Passwort, Foren, etc...

8.2 Nicht IRCD betreffende Angriffsmöglichkeiten

Die Wahrscheinlichkeit, dass ein System durch nicht den IRCd betreffende Angriffsmöglichkeiten gehackt wird, ist weit größer, als durch einen Bug im UnrealIRCd. Läßt man z.B. http, dns, smtp und ftp servers im selben System laufen, wie den IRCd, so ist das Risiko bedeutend höher. Wenn man ein Multi-User System benutzt (z.B. man hat eine Shell gemietet), riskiert man lokale Exploits und schlechte/unsichere Berechtigungseinstellungen (siehe nächsten Absatz). Dieses Risiko ist recht hoch und man sollte deswegen vorsichtig bei der Auswahl des Shell Providers sein.

8.3 Berechtigungen und Config Datei

Grundsätzlich sollte sicher gestellt sein, dass das /home Verzeichnis und das /UnrealIRCd Verzeichnis korrekte Berechtigungseinstellungen hat. "Gruppe" und "Andere" sollten keine Lese Berechtigung haben. Andernfalls könnte ein lokaler User einfach die Config datei zum Lesen öffnen und die Passworte auslesen.... Ist man sich dessen unsicher, hier ein Kurz-Befehl um das sicherzustellen: chmod -R go-rwx /path/to/Unreal3.2
Weiter zu beachten ist: Niemals sollte der UnrealIRCd Ordner innerhalb eines webroot Verzeichnisses oder anderer öffentlicher Verzeichnisse liegen.
Auch bei Backups ist sicher zu stellen, dass hier wieder auf korrekte Berechtigungseinstellungen geachtet wird. (es passiert häufiger, dass alles korrekt und sicher eingestellt ist, aber irgendwelche backup.tar.gz ungeschützt und für jedermann lesbar auf dem Server liegen).
Sicherlich möchte man auch verschlüsselte Passworte benutzen, wo immer das möglich ist, wenn man mit OpenSSL Unterstützung compiliert (was man natürlich, besorgt um Sicherheit, tun wird, richtig?) Zu empfehlen sind in diesem Fall die Verschlüsselung der Passworte mit "sha1" oder "ripemd160", andernfalls "md5". Soweit man schon verschlüsselte (oper) Blöcke von Unreal3.2.1 oder früher hat, sollten diese neu verschlüsselt werden (einfach erneut /mkpasswd), da mit 3.2.1 ein bedeutende Anti Crack Maßnahmen eingeführt wurden (basically a 14x slowdown of active cracks, and making stored-plain-ciphertext cracks impossible). [Text in Klammern nicht übersetzt, da vom Übersetzer nicht verstanden, sorry ;) ]
Auch sollte noch beachtet werden, dass dies "nur eine andere Ebene von Sicherheit" ist, da schlechte Passworte noch relativ leicht geknackt werden können. Und falls es jemandem gelingt, die Config Datei einzusehen, gibt es für einen potentiellen Angreifer darin interessante Dinge zu sehen, wie 'link::password-connect'.

8.4 User bezogene Probleme

Wie die meisten dieser Punkte ist auch dies nicht UnrealIRCd-spezifisch, aber...
Man sollte seine Opers und Admins weise auswählen und sich immer an das Prinzip des schwächsten Glieds einer Kette erinnern. Da hat man gerade sorgfältigst an alles gedacht, was in dieser Doku beschrieben ist und dann macht möglicherweise ein Freund, der Oper ist, irgend etwas Dummes. Wie z.B. die Festplatte via netbios/kazaa/morpheus/.. freigeben, einen Trojaner fangen, ein unsicheres Passwort nutzen , etc etc.. Unglücklicherweise hat man dadurch nicht alles unter eigener Konrolle.
Eines könnte man jedoch tun: Sorgfältig wählen, welche Privilegien jemand wirklich benötigt (oper::flags).

8.5 SSL/SSH & Sniffing

Es sollten unbedingt SSL Verbindungen zwischen Servern und als Oper benutzt werden, um gegen "Sniffing" geschützt zu sein. Sniffing ist möglich, wenn ein Angreifer ein System irgendwo zwischen Dir und dem Server gehackt hat. Der Angreifer kann dann den GESAMTEN Netzwerksverkehr, der durchläuft, beobachten, und u.a. sämtliche Passworte (Oper Logins, Nickserv etc.) aufzeichnen. Aus dem selben Grund sollte immer SSH statt Telnet benutzt werden.

8.6 Denial of Service Angriffe (DoS) [oder: wie schütze ich meinen hub

Viele Netzwerke haben erfahren müssen, wie viel "Fun" ein Flood oder ein (D)DoS Angriff ist, allerdings kann man einige Dinge tun, um den daraus resultierenden Schaden in Grenzen zu halten. Die meisten Netze haben einen Hub Server und einige Menschen scheinen zu vergessen, dass es vergleichsweise einfach ist, einen solchen Hub Server vor Angriffen zu schützen.
Dies soll hier erklärt werden:

1. Der Name des Hubs sollte auf einen Host eingestellt sein, der nicht existiert (z.B.: 'hub.yournet.com'), aber es sollte kein DNS Eintrag für ihn erfolgen. Dadurch kann ein Angreifer den Host nicht zu einer IP auflösen und ihn damit nicht flooden. Dann werden Server und Hub einfach durch Angabe der IP oder einen weiteren nicht öffentlichen Hostnamen gelinkt.
   Beispiel 1: link visibiblename.yournet.com { hostname 194.15.123.16; [etc] };.
   Beispiel2: link visibiblename.yournet.com { hostname thehostnamethatworks.yournet.com; [etc] };.
   Nebenbei bemerkt muss für das zweite Beispiel sichergestellt sein, dass der Nameserver keine Zonenübertragungen erlaubt, aber das führt hier zu weit vom Thema weg.
2. Ein weiterer wichtiger Punkt ist, '/stats c' und andere Stats Informationen zu verbergen, andernfalls können Angreifer einfach die Link Blöcke einsehen. Sinnvollerweise, wenn man so extrem wie der Autor auf Sicherheit bedacht ist, kann man folgendes eintragen: set { oper-only-stats "*"; }; und verhindert somit jeglichen Gebrauch von /stats.
   Wenn das nicht gewollt ist, ist wenigstens "CdDlLXz" zu verbergen. Mehr dazu im nächsten Abschnitt.

Allerdings sind solche Dinge wenig hilfreich, wenn sie später (z.B. nach einigen Monaten) durchgeführt werden, statt von Anfang an. Sonst könnte die IP nämlich bereits bekannt sein und auch einigen böswilligen Menschen.

Es ist auch zu beachten, dass Angreifer weiterhin die Nicht-Hub Server flooden können, aber das bedeutet einen höheren Aufwand, als lediglich 1-2 Schwachpunkte (die Hubs) anzugreifen. Das trägt damit ebenso zum Überleben von Hubs & Services bei :).

8.7 Informationsbeschaffung

STATS
Der /stats Befehl ist sehr informativ und es ist vielleicht sinnvoll, dessen Verwendung so weit wie möglich einzuschränken. Man sollte sich dabei von der frage leiten lassen: "Was möchte ich, dass meine User es sehen können?". Die meisten großen Netzwerke stellen hier "nichts" ein, während in anderen Netzwerken den Usern erlaubt wird, '/stats g' und '/stats k' zu benutzen.
Ich empfehle die Einstellung 'set { oper-only-stats "*"; };' zu setzen und damit sämtliche /stats Aufrufe für Nicht-Opers zu verbieten. Ist dies nicht gewollt, sollte mit /stats list die gesamte Liste möglicher /stats Parameter angezeigt werden und alles geblockt werden, was man nicht ausdrücklich anzuzeigen erlauben möchte. (im Zweifelsfalle einfach verbieten.... warum sollten die User das wirklich alles wissen müssen?).
Einige Beispiele:
- /stats o: zeigt die Nicks der Opers an (in der Schreibweise, wie sie sich opern!) und deren Hostmasks.
- /stats c: zeigt eine Übersicht der Serverlinks und welcher als 'backup', etc. benutzt wird.
- /stats g, /stats k: wird üblicherweise für gebannte Proxies benutzt.... und zeigt daher einem Angreifer, welche Proxies er nutzen kann.
- /stats E, /stats e: ziemlich sensitive Information, besonders, wenn ein Angreifer diese Adresse benutzen kann
- /stats i, /stats y: könnte einem Angreifer helfen, Hosts zu finden, welche viele Verbindungen gestatten.
- /stats P: hilft dem Angreifer, serveronly Ports zu finden
etc etc...

MAP / LINKS
Es wurde häufig gefragt, ob es möglich sei, /map oder /links zu deaktivieren. Unnsere Position hier zu ist, dass dies leichtfertig wäre und ein falsches Gefühl von Sicherheit gäbe. Um das zu erklären: Server zu verbergen, die aktuell von Usern benutzt werden, ist sinnlos, da die Server den Usern ja schon bekannt sind. Für alle anderen Server, auf denen man keine User möchte, siehe Abschnitt 8.6.
Nun, was KANN man tun? Seit der Version 3.2.1 gibt es eine Option namens 'flat map' (set::options::flat-map), die bewirkt, dass bei /map und /links Befehlen alle Server als direkt gelinkt erscheinen lässt. Dadurch können normale User nicht mehr erkennen, welcher Server zu welchem gelinkt ist. Dies kann ein netter zusätzlicher Schutz sein, weil dadurch nicht mehr irgendwelche Kiddies irgendwelche "Schwachpunkte" per /map und /links erkennen können. Somit ist es empfehlenswert, diese Option zu benutzen. Zu beachten ist, dass das nicht narrensicher ist. Denn bei einem Netsplit kann man noch erkennen, welcher Server mit welchem gelinkt war und dies gilt auch für einige andere Dinge genauso.
NORMAL USERS & SNOMASKS
Ein nicht allgemein bekanntes Feature ist, dass normale User ebenfalls einige eingeschränkte snomasks gesetzt haben können, insbesondere +s +sk. Dadurch können sie Dinge wie rehashs, kills und verschiedene andere Meldungen lesen.
Um das zu deaktivieren, kann man set::restrict-usermodes benutzten, wie hier: set { restrict-usermodes "s"; };.
Das ganze "Verbergen von Informationen" ist natürlich keine "echte" Sicherheit. Allerdings macht es Angriffe schwieriger und erhöht den Aufwand für einen Angriff oder hack.

8.8 Schutz gegen Expolits

Es gibt Kernel Patches, die es Stack- oder Heap-basierenden Expolits erschweren, zu arbeiten. Das ist schön, allerdings sollte man nicht nur primär hierauf achten, es gibt weit größere Risiken mit Expolits, die andere Punkte, als den Kernel angreifen.... aus verschiedenen Gründen.
Eine andere Option ist es chrooting zu aktivieren (gibt es nur in *nix Systemen), was bedeutet, dass bei einem erfolgreichen expolit der User auf auf das UnrealIRCd Verzeichnis begrenzt ist und keinen Zugriff auf andere Dateien hat. Dies erfordert root Rechte und Änderungen in der include/config.h (suche nach CHROOTDIR und setze sowohl IRC_USER als auch IRC_GROUP und compiliere neu.)

Eines allerdings sollte man tun: IMMER DIE NEUESTE VERSION BENUTZEN. Wenn man sich in die Unreal-notify mailinglist einträgt, erhält man die Ankündigung über neue Versionen (unreal-notify ist nur für Ankündigungen und man erhält nur alle X Monate 1 Mail). Üblicherweise gibt es neue Releases, wenn es (bedeutende) Sicherheits Fixes gibt, aber eigentlich ist es gut, in jedem Fall zu upgraden.

8.9 Zusammenfassung

Wie jetzt hoffentlich einleuchtend erklärt wurde, kann man niemals 100% sicher sein. Anwender und Entwickler haben jedes Sicherheitsloch zu finden und zu fixen, währen der Angreifer lediglich 1 Server mit 1 Sicherheitsloch finden muss. Alles, was hier erklärt wurde, hilft jedoch, die Risiken zu minimieren. Man sollte sich die Zeit nehmen, das Netzwerk sicher zu machen und die eigenen Opers zum Sicherheitsbewustsein anzuleiten. Viele Menschen kümmern sich so lange nicht um Sicherheit, bis sie gehackt wurden. Man sollte versuchen, dies zu vermeiden :).

9 – Frequently Asked Questions (FAQ)

Die FAQ kann man online hier lesen .

A. Reguläre Ausdrücke

Vorbemerkung (zitiert aus wikipedia.org): Reguläre Ausdrücke (Abk. RegExp oder Regex, engl. regular expression) bilden eine Familie von kompakten, leistungsfähigen formalen Sprachen mit denen sich (Unter-)Mengen von Zeichenketten beschreiben lassen. Diese Sprachen werden von vielen Texteditoren und Hilfsprogrammen (hauptsächlich unter Unix) verwendet, um bestimmte Muster zu suchen und dann durch etwas anderes zu ersetzen oder eine Aktion auszuführen.

Reguläre Ausdrücke werden innerhalb der Dokumentation von Unreal an vielen Stellen benutzt, einschließlich Spamfilter, Badwords und Aliases. Es handelt sich hierbei um ein mächtiges Werkzeug zum Vergleich von Zeichen. Sie werden oft als "regexp" oder "regex" bezeichnet. Unreal benutzt die 'regular expression' Bibliothek von TRE für die verwendeten regex. Diese Bibliothek unterstützt einige sehr komplexe und fortgeschrittene Ausdrücke, die möglicherweise verwirrend sein können. Die nachfolgenden Informationen sollen dabei helfen zu verstehen, wie regexp arbeitet. Wer sich für weitergehende und detaillierte Informationen zu dem Thema interessiert, sei auf die Hompage von TRE verwiesen. Eine gute deutsche Beschreibung des Themas findet man auch bei wikipedia.org.

A.1. Literale

Literale sind die am häufigsten benutzte Komponente in einem regexp. Grundsätzlich handelt es sich hierbei um Zeichen, die als Text behandelt werden. Beispielsweise besteht das Muster "test" aus den vier Literalen "t," "e," "s," und "t." In Unreal werden Litarale als case insensitive (Groß- oder Kleinschreibung ist egal) behandelt, so so dass der eben beschriebene Ausdruck sowohl auf "test" als auch auf "TEST" passt. Jedes Zeichen, bei dem es sich nicht um ein "meta Zeichen" (wird in nachfolgenden Absätzen erläutert) handelt, wird als ein Literal behandelt. Ebenso kann man explitit Zeichen als Literale definieren, indem man einen Backslash ('\') voranstellt. Ein Beispiel: Ein Punkt ('.') ist an sich ein Sonderzeichen, ein "meta Zeichen". Soll jedoch nur auf das Vorkommen eines Punktes in einem Text geprüft werden, der Punkt also als Literal behandelt werden, so wird dem Punkt einfach ein \ vorangestellt. Man kann auch auf Zeichen prüfen, die nicht einfach geschrieben werden können, wie z.B. ASCII Zeichen 3 (Farbe). Muss z.B. für den Umgang mit einem IRC Client dieses Zeichen definiert werden, kann als spezielle Zeichenfolge \x benutzt werden. Die Definition von '\x3' wird dann als ASCII Zeichen 3 interpretiert. Die Nummer nach dem x ist hexadezimal, angegeben werden können Werte von \x0 bis \xFF.

A.2. Punkt Operator

Der Punkt (.) Operator wird als "irgend ein Zeichen" benutzt". Er passt auf ein einzelnes Zeichen mit irgend einem Wert. Zum Beispiel passt regex "a.c" auf "abc," "adc," usw. Dagegen wird er nicht auf "abd" passen, weil die Zeichen "a" und "c" exakt übereinstimmen müssen.

A.3. Wiederholungs Operatoren

Einer der häufigsten Fehler, den Menschen im Zusammenhang mit regex machen, ist die Annahme, dass die Ausdrücke ähnlich wie Wildcards ('*', '?') funktionieren. Zwar haben diese Zeichen in regex eine ähnliche Bedeutung wie als Wildcards, aber sie sind doch nicht exakt dasselbe. Ausserdem unterstützen reguläre Ausdrücke andere und fritschrittlichere Methoden der Behandlung von Wiederholungen.

Der einfachste Wiederholungs Operator ist das '?'. Dieser Operator prüft auf Übereinstimmung mit 0 oder 1 der vorhergehenden Zeichen. Dieses "vorhergehende Zeichen" ist auch der Punkt, worin sich das '?' in einer regex von einer Wildcard unterscheidet. In Wildcards bedeutet die Angabe von "a?c" eine Übereinstimmung mit einem "a", gefolgt von irgend einem anderen Zeichen, gefolgt von einem "c." In Regex hat dies eine andere Bedeutung. Es wird auf Übereinstimmung geprüft mit 0 oder einem "a", gefolgt von dem Buchstaben "c". Damit kann durch das ? angegeben werden, wie viele "a" vorhanden sein dürfen. Soll das ? in einer Wildcard emuliert werden, wird der Punkt Operator verwendet. Der Ausdruck "a.c" ist gleichbedeutend mit der zuvor beschrieben Wildcard. Geprüft wird auf Übereinstimmung mit einem "a", gefolgt von irgend einem anderen Zeichen, gefolgt von einem "c."

Der nächste Wiederholungsoperator ist der *. Auch dieser ist wieder ähnlich zum Wildcard Zeichen. Geprüft wird die Übereinstimmung mit 0 oder mehr der voranstehenden Zeichen. Zu beachten ist, dass dieses "vornstehende Zeichen" das charakteristische für diese Wiederholungs Operatoren ist. Regex "a*c" passt auf 0 oder mehrere a's denen ein "c" folgt. Z.B. passt "aaaaaac", aber nicht "aaaaabc". Auch hier kann man, damit das Ganze wie Wildcards funktioniert, "a.*c" verwenden.

Der + Operator ist dem * sehr ähnlich. Allerdings passt er auf 1 mal oder mehr, statt 0 mal oder mehr. Damit wird z.B. "a*c" auf "c" passen, (0 a's gefolgt von einem c), ein "a+c" dagegen nicht. Das "a+" gibt an, dass es "mindestens" 1 a geben muss. Daher passt "c" nicht, aber "ac" und "aaaaaaaaac" passen sehr wohl.

Der qualifizierteste Wiederholungs Operator ist als "boundary" (Begrenzung) bekannt Eine Grenzbedingung gestattet es, konkret zu definieren, wie viele der vorangegstellten zeichen vorhanden sein müssen. Man kann z.B. festlegen, dass exakt 8 a's erforderlich sind, oder mindestens 8 a's oder zwischen 3 bis 5 a's. Mit der Angabe einer Grenzbedingung sind all diese Varaiationen möglich. Die einfache Syntax hierbei ist {M,N}, wobei M die untere Grenze und N die obere Grenze ist. Um beispielsweise auf 3 bis 5 a's zu prüfen, wäre anzugeben: "a{3,5}". Allerdings muss man nicht beide Zahlen angeben. Ein "a{8}" bedeutet, dass es exakt 8 a's sein müssen. Die Angabe "a{8}" ist also gleichbedeutend mit "aaaaaaaa." Um das "mindestens" Beispiel zu schreiben, erstellt man eine Grenze nur mit unterem Grenzwert. Dies würde dann so aussehen: "a{8,}".

Per Default arbeiten die Wiederholungs Operatoren so, dass versucht wird, so viele Zeichen wie möglich auf Übereinstimmung zu prüfen. Man spricht hier von "greedy" (= gierig) Nachfolgendes Beispiel soll dies beschreiben.
Angenommen, es existiere der folgende Text:
HELLO
Und der folgende Regex:
.+L
In diesem Beispiel könnte man annehmen, dass .+ auf "HE" passt, dies ist jedoch nicht korrekt. Da der Operator + "greedy" ist, passt er auf "HEL". Der grund hierführ ist, dass die größte Textportion, auf die der Eingangstext passen soll, solange noch die gesamte Bedingung passt. Im Beispiel wird "HEL" gewählt, weil die weitere Bedingung ist, dass das Zeichen nach dem Text ein "L" sein muss. Solange der Text "HELLO" lautet, folgt hinter "HEL" ein "L" und daher passt dies. Manchmal kann es sinnvoll sein, einen Operator nicht-"greedy" zu machen. Dies geschieht dadurch, dass man ein ? hinter den Wiederholungs Operator setzt. Wird ein ".+?L" gesetzt, passt das .+? nun auf "HE" eher als auf "HEL". Das ? kann hinter alle Wiederholungs Operatoren gesetzt werden: ??, *?, +?, {M,N}?.

A.4. Klammer Ausdrücke

Klammer Ausdrücke bilden einen bequemen Weg für einen "oder" Operator dar, wenn man z.B. festlegen will "passt auf a oder b". Diese Ausdrücke werden von eckigen Klammern ([]) eingeschlossen. (Dies Klammern heißen im Englischen 'Brackets', daher die englische Bezeichnung 'Bracket Expression'). In der einfachsten Syntax enthalten die Klammern eine Reihe von Zeichen, die dann so behandelt werden, als stünde ein "oder" zwischen ihnen. Beispielsweise passt der Ausdruck "[abc]" auf ein "a," ein "b," oder ein "c." Daher passt auf regexp "a[bd]c" zwar "abc" und "adc" aber nicht "acc."
Sehr häufig wird auf Zeichen wie einen Buchstaben oder eine Ziffer geprüft, aber der Klammer Ausdruck unterstützt auch Bereiche, wenn man z.B. so etwas wie "[0123456789]" benötigt. Bereiche werden durch einen Anfangs- und deinen Endwert definiert und dazwischen ein '-'. Daher ist ein einfacher Weg, um auf eine Ziffer zu testen die Angaben von "[0-9]". Auf demselben Weg kann auch auf Buchstaben getestet werden oder auch jeden anderen Bereich von ASCII Werten. Um auf einen Buchstaben zu prüfen, gibt man also an: "[a-z]". Und da Unreal 'case insensitive' ist, also nicht zwischen Groß- und Kleinbuchstaben unterschieden wird, passt dies auf alle Buchstaben. Man kann auch mehrere Bereiche innerhalb eines Ausdrucks angeben. Um auf eine Ziffer oder einen Buchstaben (aber nicht auf Satzzeichen) zu testen, gibt man an: "[0-9a-z]". Ein kleines Problem stellt dar, dass das Minuszeichen ('-') ja ein Sonderzeichen innerhalb der Klammer ist. Muss auf dieses Zeichen getestet werden, ist der einfachste Weg, es ganz zu Beginn oder ganz am Ende des Ausdruckes anzugeben. Beispielsweise passt auf "[0-9-]" eine Ziffer oder ein -.
Zur Vereinfachung von Definitionen gibt es eine Reihe von "Zeichen Klassen", die innerhalb eines Klammer Ausdrucks benutzt werden können.Durch diese Zeichenklassen kann auf die Definitionen von Bereichen verzichtet werden. Zeichenklassen werden durch ihren Namen, eingeschlossen in Doppelpunkten spezifiziert. Ein Beispiel: "[0-9]" könnte auch als "[:isdigit:]" angegeben werden. Die nachfolgende Liste zeigt die verfügbaren Klassen an:

- alnum - alphanumerische Zeichen (a-z, 0-9)

- alpha - alphabetische Zeichen (a-z)

- blank - Leerzeichen

- cntrl - Steuerungszeichen

- digit - dezimale Ziffern (0 - 9)

- graph - alle druckbaren Zeichen außer Leerzeichen

- lower - Kleinbuchstaben

- print - alle druckbaren Zeichen incl. Leerzeichen

- punct - druckbare zeichen, die nicht Leerzeichen oder alphanumerisch sind (%&/+= etc.)

- space - Leerzeichen

- upper - Großbuchstaben

- xdigit - Hexadezimale Ziffern (0-9, A-F)

Eine wichtige Anmerkung bei der Verwendung von Zeichenklassen ist, dass sie das einzige Element in einem Ausdruck sein müssen. So ist z.B. [:isdigit:-] NICHT gültig. Statt dessen kann man allerdings Ausdrücke schachteln und z.B. "[0-9-]" unter Verwendung einer Zeichenklasse so darstellen: "[[:isdigit:]-]".
Ein weiteres Feature der Klammer Ausdrücke ist die Negierung. Manchmal ist es sinnvoll zu definieren "alles außer diesen Zeichen". Soll beispielsweise auf "kein Buchstabe" geprüft werden, ist es einfacher a-z anzugeben und zu sagen "nicht diese", als sämtliche Nicht-Buchstaben aufzulisten. Eine Negierung wird durch ein "^" als erstes Zeichen im Ausdruck definiert. Somit würde "[^a-z]" auf jedes Nicht-Buxchstaben Zeichen zutreffen. Ähnlich dem '-' darf man, falls man das '^' als Literal testen möchte, dies nicht an erster Stelle angeben sondern so: "[a-z^]". Um eine Zeichenklasse zu negieren, muss der Ausdruck ebenfalls verschachtelt werden.; so würde "[^[:isdigit:]]" auf jedes Nicht-Ziffer Zeichen passen.

A.5. Assertions

Assertions gestatten es, auf bestimmte Bedingungen zu testen, die nicht durch Zeichenstring dargestellt werden können und ermöglichen Kurzformen für einige Klammerausdrücke.
Das Zeichen ^ hat die Bedeutung "linker Fixpunkt" und legt den Beginn eines Strings fest. Legt man eine einfache Regex "test" fest, so passt dies z.B. auch auf "dies ist ein test", da der String ja "test" enthält. Manchmal ist es jedoch auch erforderlich, auf daruf zu testen, dass ein String mit einem bestimmten Wort beginnt. Die kann durch '^' bewirkt werden. "^test" bedeutet z.B., das der Text mit dem Wort "test" beginnen muss. Des weiteren ist das Zeichen $ der "rechte Fixpunkt" und bedeutet das Ende eines Strings. Analog wird hier auf ein bestimmtes Wort am Ende des Strings getestet. Definiert man "^test$", dann muss der String exakt das Wort "test" sein.
Ähnlich wird auf die Existenz von Worten geprüft. Alle anderen Assertions beginnen mit einem \ gefolgt von einem speziellen Zeichen. Z.B, würde man zu Test auf Beginn oder Ende eines Wortes \< bzw. \> benutzen.
Die verbleibenden Assertions gibt es alle in zwei Formen, eine positive und eine negative. Hier eine Auflistung:

- \b - Wortende

- \B - Kein Wortende

- \d - Zahlzeichen (analog zu [[:digit:]])

- \D - Kein Zahlzeichen (analog zu [^[:digit:]])

- \s - Leerzeichen (analog zu [[:space:]])

- \S - Kein Leerzeichen (analog zu [^[:space:]])

- \w - Wortzeichen (analog zu [[:alnum:]_])

- \W - Kein Wortzeichen (analog zu [^[:alnum:]_])

A.6. Alternation

Alternation ist eine Methode, um "oder" auszudrücken. Der Operator für die Alternation ist der senkrechte Strich (' |'). Will man z.B. "a oder b" ausdrücken, würde man "a|b" definieren. Bei normalen Buchstaben könnte dies auch durch Klammer Ausdruck festgelegt werden, aber Alternation kann auch in Unterausdrücken (siehe weiter unten) benutzt werden.

A.7. Unterausdrücke

Unterausdrücke sind ein Teil eines Regulären Ausdrucks, der als einzelnes Element behandelt wird. Es gibt zwei Wege, um einen Unterausdruck zu erstellen. Die zwei Methoden unterscheiden sich in bezug auf "back references", die im nächsten Abschnitt erläutert werden. Zur Deklaration eines Unterausdrucks, der back references benutzt, ist dieser einfach in normale Klammern ( ) einzuschließen. Zur Deklaration eines Unterausdrucks, der keine back references benutzt, wird die geöffnete Klammer durch "(?:" ersetzt. Beispiele: "([a-z])" und "(?:[a-z])". Unterausdrücke sind deswegen so nützlich, weil man den Ausdrücken Operatoren hinzufügen kann. Beispielsweise können alle Wiederholungsoperatoren mit der Bedeutung "X oder mehr des vorherigen Zeichens" auch für "X oder mehr des vorherigen Unterausdrucks" benutzt werden. Ein Beispiel: Hat man einen Regex von "[0-9][a-z][0-9]", um auf die Folge "Ziffer - Buchstabe - Ziffer" zu testen und man benötigt dies Folge nun doppelt, so müsste man angeben: "[0-9][a-z][0-9][0-9][a-z][0-9]". Mit Unterausdrücken würde man das so angeben: "([0-9][a-z][0-9]){2}".

A.8. Rückverweise

Rückverweise gestatten es, einen String zu bezeichnen, der auf einen der Unterausdrücke einer Regex passt. Rückverweise werden durch einen Backslash ( \ ), gefolgt von einer Ziffer 0-9Nummer festgelegt. (Beispiel: \1). \0 ist ein spezieller Rückverweis, der den gesamten Regex bezeichnet statt eines Unterausdrucks. Rückverweise können dann nützlich sein, wenn derselbe String zwei mal zu testen ist..

Beispielsweise sei angenommen, es gebe einen nick!user@host und es gebe einen Trojaner, der Nickname und Username benutzt, die zu "[0-9][a-z]{5}" passen und Nick. und Username sind identisch. Hier nun "[0-9][a-z]{5}![0-9][a-z]{5}@.+" zu benutzen, wird nicht funktionieren, da es dabei erlaubt wäre, dass sich Nick- und Username unterscheiden. Der Nickname könnte z.B.1abcde und der Username 2fghij. Back references erlauben es nun, diese Einschränkung zu umgehen. Der Eintrag "([0-9][a-z]{5})!\1@.+" wird exakt wie erwartet funktionieren. Damit wird nach einem Nicknamen gesucht, auf den der gegebene Unterausdruck passt und dann ein Rückverweis benutzt, um anzugeben, dass der Username derselbe Text sein muss.
Da man nur 9 Rückverweise definieren kann ist die Notation (?:) aus Abschnitt A.7. so nützlich. Damit kann man Unterausdrücke ohne Verwendung von Rückverweisen festlegen. Dies ist auch schneller und daher sollten Ausdrücke ohne Rückverweise benutzt werden, wann immer dies möglich ist und Rückverweise nicht erforderlich sind..

A.9. Gross- und Kleinschreibung

Es wurde schon erwähnt, dass Unreal bei allen Regexps per Default nicht zwischen Groß- und Kleinschreibung unterscheidet. Hauptgrund hierfür ist, dass es deutlich mehr Gründe für Suchen ohne Berücksichtigung von Groß- und Kleinschreibung gibt, als dafür. Möchte man beispielsweise den Text "www.test.com" blocken, soll dies im Allgemeinen auch für "WWW.TEST.COM" gelten. Allerdings kann es auch erforderlich sein, z.B. bei der Suche nach bestimmten Trojanern, sehr wohl zwischen Groß- und Kleinschreibung zu unterscheiden. Deswegen gibt es die Möglichkeit, dynamisch die Prüfung auf Groß- und Kleinschreibung ein oder auszuschalten. Es gibt hierzu "(?-i)" und "(?i)".

?-i case insentivity ist aus Unterscheidung, ob Groß- oder Kleinschreibung
?i case insentivity ist an Keine Unterscheidung auf Groß und Klein

Beispiel: "(?-i)[a-z](?i)[a-z]" prüft auf Kleinbuchstaben (case insensitivity ist aus) gefolgt von entweder groß- oder Kleinbuchstaven (case insensitivity ist an). Anstatt sich immer an den Zustand des Flags erinnern zu müssen, kann man den Flagwechsel auch in Unterausdrücken festlegen, wie z.B.: "(?-i:[a-z])[a-z]".