Equipment
|
INDEX / TABLE OF CONTENTS1. Introduction & Notes This document was written for exclusive use with UnrealIRCd. Use of thisdocument with another software package, or distribution of this document withanother software package is strictly prohibited without the written permissionof the UnrealIRCd Development Team. This document may be copied/printed/reproduced/publishedas many times as you like, provided it is for use with UnrealIRCd and it is notmodified in anyway. – Copyright UnrealIRCd Development Team 2002-2004 Please read this manual before asking for help, you also REALLY want to take a look at theFAQ since over 80% of your questions/problems are answered in it. If you stillneed help you can ask for support at irc.ircsystems.net (port 6667) channel #unreal-support (notethat we REQUIRE you to read the docs and faq and we only help with UnrealIRCd, not with services!).If you have a real bug (like a crash) then report it athttp://bugs.unrealircd.org. 1.1 – Notes on upgrading/mixing 3.1.x -> 3.2 In case you are upgrading from Unreal3.1.x to Unreal3.2 you'll notice the whole config file has changed,you may find it hard at first, but once you've switched you'll find it much better! Also don't forget to read section 3 about features, although you know already some of them which are in 3.1.x there are several new features too! It's best not to mix/link 3.1.x with 3.2, but if you really want to, you need at least 3.1.4, but 3.1.5.1 is strongly recommended. 1.2 – Notes on upgrading between 3.2 versions The recommended way to upgrade is:
Please also check .RELEASE.NOTES to see what has been changed.If you notice any changes (or bugs) between version, BE SURE TO READ THE RELEASE NOTES FIRST before reporting it as a bug!. Tested & Supported Operating Systems:
If you have Unreal3.2 working correctly under other operating systems, pleasesend the details to docs@unrealircd.com Installation Instructions
Windows:
Some major/nice features are explained in this section. It provides a general overview,and sometimes refers to the config file (something which you might know nothing about yet). You can skip this section, however it's suggested to read it before/after installing. Cloaking is a way to hide the real hostname of users, for example if your real host is d5142341.cable.wanadoo.nl,it will be shown (in join, part, whois, etc) as rox-2DCA3201.cable.wanadoo.nl.This feature is useful to prevent users flooding each other since they can't see the real host/IP. This is controlled by usermode +x (like: /mode yournick +x), admins can also force +x to be enabledby default, or make it so users can never do -x. A cloaked host is generated by a cloaking module (you are required to have one loaded), currently there's only 1 module included: Cloak keys MUST be the same on ALL SERVERS in a network. Also cloak keys should be kept SECRETbecause it's possible to decode the original host if you know the keys (which makes umode +x useless). UnrealIRCd supports modules which is nice because: You need to load at least 2 modules or else you won't be able to boot!: Snomasks are server notice masks, it's a special type of usermode that controls whichserver notices you will receive (mostly used by opers) It can be set by: /mode yournick +s SNOMASK, for example: /mode yournick +s +cF The current available snomasks are: You can control which snomasks you automatically get (set::snomask-on-connect) and which you geton oper (set::snomask-on-oper, oper::snomask) By default, if a user simply sets mode +s, certain snomasks are set. For non-opers, snomasks +ks, and for opers, snomasks +kscfvGqo. With aliases you can configure server-side alias commands.You can for example let "/ns identify blah" be forwarded to nickserv (it will betranslated to: privmsg nickserv identify blah). You can even make more complex aliases such as /register can forward toChanServ if the first parameter begins with a # and forwarded to NickServ if it doesn't. Aliases are configured by alias blocks in the configuration file, and you can also includea file with default aliases for most commonly used services. UnrealIRCd has a built-in help system accessible by /helpop. The /helpop command is completely user configurable viathe help block in the configuration file. Additionally, a help.conf is included which contains some basic help forall commands. There are several oper levels in UnrealIRCd and you can add additional rights (like to use /gline) toeach of them, that way you can give each oper the privileges they need. This is controlled by the oper flags in the oper block, see the oper block for more information. UnrealIRCd has a lot of powerful oper commands which are explained in User & Oper Commands,you probably want to read those after installing :). SSL stands for Secure Socket Layer, with SSL you can make secure encrypted connections.It can be used to encrypt server<->server traffic, but client<->server traffic can also be encrypted.You usually use SSL to protect against sniffing and for authentication. You need to have your IRC server compiled with SSL support. To setup an SSL port you need to set listen::options::ssl. You cannot connect normally to a SSL port (so don't make port 6667 ssl!), you need a client or a tunnelthat understands the SSL protocol. Clients that support SSL: XChat,irssi,mIRC (6.14 and up,also requires some additional steps) For clients which do not support SSL you can use a tunnel likestunnel, here's a stunnel.conf example (for stunnel 4.x): client = yes[irc]accept = 127.0.0.1:6667connect = irc.myserv.com:6697If you then connect to 127.0.0.1 port 6667, your traffic will be encrypted and forwarded to irc.myserv.comport 6697 (an SSL port). You should also validate certificates when you connect to servers and not blindly accept them (like in the stunnel example)else you are still vulnerable to "active sniffing" attacks (ssl redirects), that's however too offtopicto explain here (learn about SSL, don't ask us). [mIRC and xchat pop up a window asking you to allow/reject a certificate,so that's good]. UnrealIRCd supports IPv6, since beta15 it seems to be stable. Although microsoft has an experimental IPv6 implementation for w2k/XP it is not (yet) supported by UnrealIRCd. Zip links can be turned on for server<->server links, it compresses the data by using zlib.It can save 60-80% bandwidth... So it's quite useful for low-bandwidth links or links withmany users, it can help a lot when you are linking since a lot of data is sent about every user/channel/etc. To compile with zip links support, you need to answer Yes to the zlib question in ./Config and set it in link::options::zip(on both sides) 3.11 - Dynamic DNS/IP linking support UnrealIRCd has some (new) nice features which helps dynamic IP users using dynamic DNS (like blah.dyndns.org).If you are linking two dynamic DNS hosts, then set link::options::nodnscache and link::options::nohostcheck. Throttling
*** 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: +NIn fact, it can get even more advanced/complicated: Instead of the default action, you can for some floodtypes specify another one, for example: +f [20j#R,50m#M]:15 This will set the channel +R if the joinlimit is reached (>20 joins in 15 seconds),and will set the channel +M if the msg limit is reached (>50 messages in 15 seconds). There's also a "remove mode after X minutes" feature: +f [20j#R5]:15 will set the channel +R if thelimit is reached and will set -R after 5 minutes. A server can have a default unsettime (set::modef-default-unsettime), so if you type +f [20j]:15 it could gettransformed into +f [20j#i10]:15, it's just a default, you can still set [20j#i2]:15 or something like that,and you can also disable the remove-chanmode completely by doing a +f [20j#i0]:15 (an explicit 0). The old +f mode (msgflood per-user) is also still available as 't', +f 10:6 is now called +f [10t]:6 and+f *20:10 is now +f [20t#b]:10. Currently the ircd will automatically convert old +f mode types to new ones.Note that there's no unsettime feature available for 't' bans ([20t#b30]:15 does not work). What the best +f mode is heavily depends on the channel... how many users does it have? do you have a game that makes usersmsg a lot (eg: trivia) or do users often use popups? is it some kind of mainchannel or in auto-join? etc.. There's no perfect channelmode +f that is good for all channels, but to get you started have a look at the next example and modifyit to suit your needs: +f [30j#i10,40m#m10,7c#C15,10n#N15,30k#K10]:15 30 joins per 15 seconds, if limit is reached set channel +i for 10 minutes 40 messages per 15 seconds, if limit is reached set channel +m for 10 minutes 7 ctcps per 15 seconds, if limit is reached set channel +C for 15 minutes 10 nickchanges per 15 seconds, if limit is reached set channel +N for 15 minutes 30 knocks per 15 seconds, if limit is reached set channel +K for 10 minutes If it's some kind of large user channel (>75 users?) you will want to increase the join sensitivity (to eg: 50) and themessage limit as well (to eg: 60 or 75). Especially the remove-mode times are a matter of taste.. you should think like.. what if no op is available to handlethe situation, do I want to have the channel locked for like 15 minutes (=not nice for users) or 5 minutes (=likely the flooderswill just wait 5m and flood again). It also depends on the floodtype, users unable to join (+i) or speak (+m) is worse thanhaving them unable to change their nick (+N) or send ctcps to the channel (+C) so you might want to use different removal times. Channel mode j The +f mode includes a feature to prevent join floods, however this feature is "global." Forexample, if it is set to 5:10 and 5 different users join in 10 seconds, the floodprotection is triggered. Channel mode +j is different. This mode works on a per-user basis.Rather than protecting against join floods, it is designed to protect against join-part floods(revolving door floods). The mode takes a parameter of the form X:Y where X is the number ofjoins and Y is the number of seconds. If a user exceeds this limit, he/she will be preventedfrom joining the channel. Basic bantypes and cloaked hosts
Modules can also add other extended ban types. Spamfilter is a new system to fight spam, advertising, worms and other things. It works a bit likethe badwords system but has several advantages. Spamfilters are added via the /spamfilter command which uses the following syntax:
Here's an example: /spamfilter add pc gline - - Come watch me on my webcam If the text come watch me on my webcam is found in either a private msg or a channel msgthen the message will be blocked and a gline will be added immediately. Another example: /spamfilter add pc block - - come to irc\..+\..+ This is a regex that will match on Hi, come to irc.blah.net etc.... And an example with specified time/reason: /spamfilter add p gline 3h Please_go_to_www.viruscan.xx/nicepage/virus=blah Come watch me on my webcam If come watch me on my webcam is found in a private msg then the user is glined for 3 hourswith the reason Please go to www.viruscan.xx/nicepage/virus=blah. Spamfilters added with /spamfilter are network-wide. They work regardless of whether the user/channelhas mode +G set, only opers and ulines (services) are exempted from filtering. You can also add spamfilters in the config file but these will be local spamfilters (notnetwork-wide, though you could use remote includes for this).The syntax of these spamfilter { } blocks are explained here spamfilter { regex "//write \$decode\(.+\|.+load -rs"; target { private; channel; }; reason "Generic $decode exploit"; action block;}; set::spamfilter::ban-time allows you to modify the default ban time for *lines/shuns added by spamfilter (default: 1 day) UnrealIRCd now has support for CIDR (Classless Interdomain Routing). CIDR allows you to banIP ranges. IPs are allocated to ISPs using CIDR, therefore, being able to set a CIDR based banallows you to easily ban an ISP. Unreal supports CIDR for both IPv4 and IPv6. CIDR masks may beused in the allow::ip, ban user::mask, ban ip::mask, except ban::mask, except throttle::mask,and except tkl::mask (for gzline, gline, and shun). Additionally, CIDR can be used in /kline,/gline, /zline, /gzline, and /shun. Unreal uses the standard syntax of IP/bits, e.g.,127.0.0.0/8 (matches 127.0.0.0 - 127.255.255.255), and fe80:0:0:123::/64 (matchesfe80:0:0:123:0:0:0:0 - fe80:0:0:123:ffff:ffff:ffff:ffff). UnrealIRCd now has the ability to specify which charsets/languages should be allowedin nicknames. You do this in set::allowed-nickchars.
Example 1, for people of western europe: set { allowed-nickchars { latin1; }; };Example 2, if you have mainly chinese users and want to allow "normal" chinese characters: set { allowed-nickchars { chinese-simp; chinese-trad; }; }; UnrealIRCd has a lot of features so not everything is covered here... You'll find that out by yourself.
4.0 - Configuring your unrealircd.conf First of all, creating a good unrealircd.conf will take some time, probablysomething like 10 - 60m. You can try to get it booted up as quickly as you can andtweak later, or you can learn the major sections directly step-by-step which isthe recommended method ;P. If you have any problems, check your syntax, check the manualand check the FAQ before asking for help/reporting a bug. 4.1 Configuration File Explained The new system uses a block-based format. Each entry, or block, in the newformat has a specific format. The format works like: <block-name> <block-value> { <block-directive> <directive-value>;}; <block-name> is the type of block, such as me, or admin. <block-value>sometimes specifies a value, such as /oper login, but other times it will bea sub-type such as in ban user. <block-directive> is an individual variable specific to the block, and<directive-value> is the Associated value. If <directive-value>contains spaces, or characters that represents a comment it must be containedin double quotes. If you want to use a quote character inside a quoted stringuse \" and it will be understood as a quote character. A <block-directive> can have directives within it, if that’s thecase it will have it's own set of curly braces surrounding it. Some blocks donot have directives and are specified just by <block-value>, such as include.Also note that there is no set format, meaning the whole block can appear onone line or over multiple lines. The format above is what is normally used (andwhat will be used in this file) because it is easy to read. Note: the configuration file is currently case sensitive so BLOCK-NAME is notthe same as block-name. There is a special notation used to talk about entriesin the config file. For example, to talk about <directive-name> in theexample above, you'd say <block-name>::<block-directive>, and ifthat directive has a sub block you want to reverence, you would add another:: and the name of the sub directive. To talk about an unnamed directive you would do <block-name>:: whichwould in this case mean <block-value>, or it could be an entry in a subblock that has no name. Three types of comments are supported: # One line comment Now that you know how it works, create your unrealircd.conf from scratch orcopy doc/example.conf and start editing. It's recommended to walk step by stepthrough all block types and use this manual as a reference. 4.2 - Me BlockREQUIRED (Previously known as the M:Line) Syntax: me { name <name-of-server>; info <server-description>; numeric <server-numeric>;}; These values are pretty obvious. The name specifies the name of the server,info specifies the server's info line, numeric specifies a numeric toidentify the server. This must be a value between 0 and 254 that is UNIQUE tothe server meaning NO other servers on the network may have the same numeric. Example: me { name "irc.foonet.com"; info "FooNet Server"; numeric 1;}; 4.3 - Admin BlockREQUIRED (Previously known as the A:Line) Syntax: admin { <text-line>; <text-line>;};
The admin block defines the text displayed in a /admin request. You can specifyas many lines as you want and they can contain whatever information youchoose, but it is standard to include the admins nickname and email addressat a minimum. Other information may include any other contact information youwish to give. Example: admin { "Bob Smith"; "bob"; "widely@used.name";}; 4.4 - Class BlockREQUIRED (Previously known as the Y:Line) Syntax: class <name> { pingfreq <ping-frequency>; connfreq <connect-frequency>; maxclients <maximum-clients>; sendq <send-queue>; recvq <recv-queue>;};
Class blocks are classes in which connections will be placed (for example from allow blocksor servers from link blocks), you generally have multiple class blocks (ex: for servers, clients, opers). name is the descriptive name, like "clients" or "servers", this name isused for referring to this class from allow/link/oper/etc blocks pingfreq is the number of seconds between PINGs from the server (something between 90 and 180 is recommended). connfreq is used only for servers and is the number of seconds between connection attempts if autoconnect is enabled maxclients specifies the maximum (total) number of clients/servers which can be in this class sendq specifies the amount of data which can be in the send queue (very high for servers with low bandwidth, medium for clients) recvq specifies the amount of data which can be in the receive queue and is used for flood control(this only applies to normal users, try experimenting with values 3000-8000, 8000 is the default). Examples: class clients { pingfreq 90; maxclients 500; sendq 100000; recvq 8000;};class servers{ pingfreq 90; maxclients 10; /* Max servers we can have linked at a time */ sendq 1000000; connfreq 100; /* How many seconds between each connection attempt */};
4.5 - Allow BlockREQUIRED (Previously known as the 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>; ... };}; The allow class is where you specify who may connect to this server, you can have multiple allow blocks. About matching ip host password (optional) class maxperip (optional, but recommended) redirect-server (optional) redirect-port (optional) options block (optional) Examples: allow { ip *; hostname *; class clients; maxperip 5;};allow { ip *@*; hostname *@*.passworded.ugly.people; class clients; password "f00Ness"; maxperip 1;};
4.6 - Listen BlockREQUIRED (Previously known as the P:Line) Syntax: listen <ip:port> { options { <option>; <option>; ... };};
This block allows you to specify the ports on which the IRCD will listen. Ifno options are required, you may specify this without any directives in theform listen <ip:port>;. ip and port Info for IPv6 users options block (optional)
Examples: listen *:6601 { options { ssl; clientsonly; };}; Or if there are no options: listen *:8067; 4.7 - Oper BlockRECOMMENDED (Previously known as the 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>;}; The oper block allows you to assign IRC Operators for your server. The oper::specifies the login name for the /oper. The oper::from::userhost is a user@hostmask that the user must match, you can specify more than one hostmask by creatingmore than one oper::from::userhost. The oper::password is the password the usermust specify, oper::password:: allows you to specify an authentication methodfor this password, valid auth-types are crypt, md5, and sha1, ripemd-160. Ifyou want to use a plain-text password leave this sub-block out. Please note that BOTH the login name and password are case sensitive The oper::class directive specifies the name of a preexisting (appears beforethis in the config file) class name that the oper block will use. The oper::flags directive has two formats. If you wish to use the old styleoper flags i.e., OAa, you use the flags <flags> method, if you want touse the new style,i.e., services-admin, then you use the flags { <flag>;} method. Below is a list of all the flags (in both formats) and what they do.
Certain flags give you other flags by default:
The oper::swhois directive allows you to add an extra line to an opers whoisinformation. [optional] The oper::snomask directive allows you to preset an oper's server notice maskon oper up. For a list of available SNOMASKs, see Section 3.3[optional] The oper::modes directive allows you to preset an oper's modes on oper up.[optional] The oper::maxlogins allows you to restrict the number of concurrent oper logins from this host,for example if you set it to 1 then only 1 person can be oper'ed via this block at any time.[optional] Example: oper bobsmith { class clients; from { userhost bob@smithco.com; userhost boblaptop@somedialupisp.com; }; password "f00"; flags { netadmin; can_gkline; can_gzline; can_zline; can_restart; can_die; global; }; swhois "Example of a whois mask"; snomask frebWqFv;};Some little info about OperOverride: OperOverride are things like: joining a +ikl channel and going through bans (you need to /invite yourself first however),op'ing yourself in a channel, etc. The can_override operflag was added as an attempt to stop oper abuse.No oper is able to override by default, you would have to give them the can_override flag explicitly.
4.8 - DRpass BlockRECOMMENDED (Previously known as the X:Line) Syntax: drpass { restart <restart-password> { <auth-type>; }; die <die-password> { <auth-type>; };}; This block sets the /restart and /die passwords with drpass::restart and drpass::dierespectively. The drpass::restart:: and drpass::die:: allow you to specify thetype of authentication used by this item. The currently supported authenticationtypes are crypt, md5, and sha1, ripemd-160. Example: drpass { restart "I-love-to-restart"; die "die-you-stupid";};
Syntax: This directive specifies a filename to be loaded as a separate configurationfile. This file may contain any type of config block and can even include otherfiles. Wildcards are supported in the file name to allow you to load multiplefiles at once. example 1: a network file include mynetwork.network; That would be the statement to use if you wanted to use a separate networkfile. Separate network files are no longer required; all the network settingscan be inserted directly into the unrealircd.conf. Or you can put an includestatement them to load the file. example 2: aliases include aliases/ircservices.conf Another example is to use it for including alias blocks, UnrealIRCd comes withsome files which (should) contain the right aliases for most services:
4.10 - LoadModule DirectiveREQUIRED Syntax: See here why modules are nice/useful. Modules that come standard with Unreal3.2: commands.so / commands.dll - All the / commands (well not all yet, but will eventually be all) REQUIRED So you want to be sure to have these loaded: loadmodule "src/modules/commands.so";loadmodule "src/modules/cloak.so"; or on windows: loadmodule "modules/commands.dll";loadmodule "modules/cloak.dll"; Syntax: log <file-name> { maxsize <max-file-size>; flags { <flag>; <flag>; ... };}; The log block allows you to assign different log files for different purposes.The log:: contains the name of the log file. log::maxsize is an optional directivethat allows you to specify a size that the log file will be wiped and restarted.You can enter this string using MB for megabytes, KB, for kilobytes, GB, forgigabytes. The log::flags specifies which types of information will be in thislog. See the list of available flags below. You may also have multiple log blocks, to log different things to differentlog files. Available Flags:
Example: log ircd.log { maxsize 5MB; flags { errors; kills; oper; kline; tkl; };}; 4.12 - TLD BlockOPTIONAL (Previously known as the 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; }}; The tld block allows you to specify a motd, rules, and channel for a user basedon their host. This is useful if you want different motds for different languages.The tld::mask is a user@host mask that the user's username and hostname mustmatch. The tld::motd, tld::shortmotd, tld::opermotd,tld::botmotd, and tld::rules specify the motd, shortmotd, opermotd,botmotd, and rules file, respectively, to be displayed to this hostmask.The tld::shortmotd, tld::opermotd, and tld::botmotd are optional. tld::channelis optional as well, it allows you to specify a channel that this user will be forcedto join on connect. If this exists it will override the default auto join channel.The tld::options block allows you to define additional requirements,currently only tld::options::ssl which only displays the file for SSL users, andtld::options::remote which only displays the file for remote users, exists. TLD entries are matched upside down Example: tld { mask *@*.fr; motd "ircd.motd.fr"; rules "ircd.rules.fr";}; 4.13 - Ban Nick BlockOPTIONAL (Previously known as the Q:Line) Syntax: ban nick { The ban nick block allows you to disable use of a nickname on the server. Theban::mask allows wildcard masks to match multiple nicks, and ban::reason allowsyou to specify the reason for which this ban is placed. Most commonly theseblocks are used to ban usage of the nicknames commonly used for network services. Example: ban nick { mask "*C*h*a*n*S*e*r*v*"; reason "Reserved for Services";}; 4.14 - Ban User BlockOPTIONAL (Previously known as the K:Line) Syntax: ban user { mask <hostmask>; reason <reason-for-ban>;}; This block allows you to ban a user@host mask from connecting to the server.The ban::mask is a wildcard string of a user@host to ban, and ban::reason isthe reason for a ban being placed. Note, this is only a local ban and thereforethe user may connect to other servers on the network. Example: ban user { mask *tirc@*.saturn.bbn.com; reason "Idiot";}; 4.15 - Ban IP BlockOPTIONAL (Previously known as the Z:Line) Syntax: ban ip { mask <ipmask>; reason <reason-for-ban>;}; The ban ip block bans an IP from accessing the server. This includes both usersand servers attempting to link. The ban::mask parameter is an IP which may containwildcard characters, and ban::reason is the reason why this ban is being placed.Since this ban affects servers it should be used very carefully. Example: ban ip { mask 192.168.1.*; reason "Get a real ip u lamer!";};
4.16 - Ban Server BlockOPTIONAL (Previously known as the q:Line) Syntax: ban server { mask <server-name>; reason <reason-for-ban>;}; This block disables a server's ability to connect to the network. If the server linksdirectly to your server, the link is denied. If the server links to a remote server, thelocal server will disconnect from the network. The ban::mask field specifies a wildcardmask to match against the server attempting to connect's name, and ban::reason specifiesthe reason for which this ban has been placed. Example: ban server { mask broken.server.my.network.com; reason "Its broken!";};
4.17 - Ban RealName BlockOPTIONAL (Previously known as the n:Line) Syntax: ban realname { mask <realname-mask>; reason <reason-for-ban>;}; The ban realname block allows you to ban a client based on the GECOS (realname)field. This is useful to stop clone floods because often clone bots use thesame realname. The ban::mask specifies the realname which should be banned.The mask may contain wildcards. The ban::reason specifies the reason why thisban is being placed. Example: ban realname { mask "Bob*"; reason "Bob sucks!";}; 4.18 - Ban Version BlockOPTIONAL Syntax: ban version { mask <version-mask>; reason <reason-for-ban>; action [kill|tempshun|shun|kline|zline|gline|gzline];}; The ban version block allows you to ban a client based on the IRC client software they use.This makes use of the clients CTCP version reply. Therefore if a client does notsend out a CTCP version, the ban will not work. This feature is intended to allow you to blockmalicious scripts. The ban::mask specifies the version which should be banned.The mask may contain wildcards. The ban::reason specifies the reason why thisban is being placed. You can also specify ban::action, kill is the default,tempshun will shun the specific user connection only and would work very effective againstzombies/bots at dynamic IPs because it won't affect innocent users. shun/kline/zline/gline/gzlinewill place a ban of that type on the ip (*@IPADDR), the duration of these bans can be configuredwith set::ban-version-tkl-time and defaults to 1 day. Example: ban version { mask "*SomeLameScript*"; reason "SomeLameScript contains backdoors";}; ban version { mask "*w00tZombie*"; reason "I hate those hundreds of zombies"; action zline;}; 4.19 - Ban Exceptions BlockOPTIONAL (Previously known as the E:Line) Syntax: except ban { mask <hostmask>;}; The except ban block allows you to specify a user@host that will override aban placed on a broader host. This is useful when you want an ISP banned, butstill want specific users to be able to connect. The except::mask directivespecifies the user@host mask of the client who will be allowed to connect. Example: except ban { mask myident@my.isp.com;}; 4.20 - TKL Exceptions BlockOPTIONAL Syntax: except tkl { mask <hostmask>; type <type>; type { <type>; <type>; ... };}; The except tkl block allows you to specify a user@host that will override atkl ban placed on a broader host. This is useful when you want an ISP banned, butstill want specific users to be able to connect. The except::mask directivespecifies the user@host mask of the client who will be allowed to connect. Theexcept::type specifies which type of ban this should override. Valid types aregline, gzline, qline, gqline, and shun, which make an exception from Glines,Global Zlines, Qlines, Global Qlines, and shuns. If the type {} format is used,multiple types may be specified. Example: except tkl { mask myident@my.isp.com; type gline;}; 4.21 - Throttle Exceptions BlockOPTIONAL Syntax: except throttle { mask <ipmask>;}; The except throttle block allows you to specify an IP mask that will override thethrottling system. This only works if you have chosen to enable throttling. Theexcept::mask specifies an IP mask that will not be banned because of throttling. Example except throttle { mask 192.168.1.*;}; 4.22 - Deny DCC BlockOPTIONAL (Previously known as dccdeny.conf) Syntax: deny dcc { filename <file-to-block>; reason <reason-for-ban>; soft [yes|no];}; The deny dcc block allows you to specify a filename which will not be allowedto be sent via DCC over the server. This is very useful in helping stop distributionof trojans and viruses. The deny::filename parameter specifies a wildcard mask of the filename to rejectsends of, and deny::reason specifies the reason why this file is blocked. There's also a deny::soft option, if set to 'yes' the dcc is blockedunless the user explicitly allows it via /DCCALLOW +nickname-trying-to-send.See dccallow.conf for a good example configuration for dccallow. Example deny dcc { filename virus.exe; reason "This is a GD Virus";};deny dcc { filename "*.exe"; reason "Executable content"; soft yes;}; 4.23 - Deny Version BlockOPTIONAL (Previously known as the V:Line) Syntax: deny version { mask <server-name>; version <version-number>; flags <compile-flags>;}; This block allows you to deny a server from linking based on the version ofUnreal it is running and what compile time options it has. The format for thisblock is somewhat complex but isn't too hard to figure out. The deny::mask directivespecifies a wildcard mask of the server name this applies to. The deny::versionspecifies the protocol number of the version this refers to. For example, 3.0 is 2301, 3.1.1/3.1.2 is 2302, 3.2 is 2303. The first characterof this parameter can be one of the following >, <, =, !. This charactertells the IRCd how to interpret the version. If the first character is a >then all version greater than the specified version are denied, if it is a <all versions lower are denied, if it is an = only that version is denied, andif it is a ! then all versions except the specified are denied. The deny::flagsdirective allows you to specify what compile time flags the server may or maynot have. The flags are arranged one after the other with no separation between,if a character is prefixed by a ! then it means the server may not have thisflag compiled into it, if it does not have a ! prefix, then it means the servermust have this flag compiled. 4.24 - Deny Link BlockOPTIONAL (Previously known as the D/d:Line) Syntax: deny link { mask <server-name>; rule <crule-expression>; type <type-of-denial>;}; This block allows you to use specific rules to deny a server from linking.The deny::mask specifies a wildcard mask of the server name to apply this ruleto. The deny::rule directive is very complex. A crule expression allows youto control the link in great detail, and it is set up like a programming expression.Four operators are supported, connected(<servermask>), returns true ifa server matching servermask is connected, directcon(<servermask>), returnstrue if the server matching servermask is directly connected to this server,via(<viamask>,<servermask>), returns true if a server matching servermaskis connected by a server matching viamask, and directop(), which returns trueif the operator issuing a /connect is directly connected to this server. Theseoperators can be combined using && (and) and || (or), items may alsobe enclosed in parenthesis to allow grouping. In addition, an operator precededwith a ! checks if the operator returned false. If the entire expression evaluatesto true, then the link is denied. The deny::type allows two different values,auto (only applies to autoconnects, /connect will still work), and all (appliesto all connection attempts). 4.25 - Deny Channel BlockOPTIONAL (Previously known as chrestrict.conf) Syntax: deny channel { channel "<channel-mask>"; reason <reason-for-ban>; redirect "<channel-name>"; warn [on|off];};
The deny channel block allows you to disallow users from joining specific channels.The deny::channel directive specifies a wildcard mask of channels the usersmay not join, and the deny::reason specifies the reason why the channel maynot be joined. Additionally, you may specify a deny::redirect. If this is specified,when a user tries to join a channel that matches deny::channel, he/she will be redirectedto deny::redirect. And there's also deny::warn which (if set to on) will send anopernotice (to EYES snomask) if the user tries to join. Example deny channel { channel "#unrealsucks"; reason "No it don't!";};deny channel { channel "#*teen*sex*"; reason "You == dead"; warn on;};deny channel { channel "#operhelp"; reason "Our network help channel is #help, not #operhelp"; redirect "#help";}; 4.26 - Allow Channel BlockOPTIONAL Syntax: allow channel { channel "<channel-mask>";}; The allow channel block allows you to specify specific channels that usersmay join. The allow::channel directive specifies the wildcard mask of the channelswhich may be joined. Example: allow channel { channel "#something";}; 4.27 - Allow DCC BlockOPTIONAL Syntax: allow dcc { filename "<filename-mask>"; soft [yes|no];}; The allow dcc blocks allows you to specify exceptions over deny dcc blocks, wildcardsare permitted. If allow dcc::soft is set to 'yes' it applies to 'soft dcc bans' list,if set to 'no' it applies to the normal ('hard') dcc bans. Example: allow dcc { filename "*.jpg"; /* Images are usually safe */ soft yes;}; 4.28 - Vhost BlockOPTIONAL (Previously known as vhosts.conf) Syntax: vhost { vhost <vhost>; from { userhost <hostmask>; userhost <hostmask>; ... }; login <login-name>; password <password> { <auth-type>; }; swhois "<swhois info>";}; The vhost block allows you to specify a login/password that can be used withthe /vhost command to obtain a fake hostname. The vhost::vhost parameter canbe either a user@host or just a host that the user will receive upon successful/vhost. The vhost::from::userhost contains a user@host that the user must matchto be eligible for the vhost. You may specify more than one hostmask. The vhost::loginin the login name the user must enter and vhost::password is the password thatmust be entered. The vhost::password:: allows you to specify the type ofauthentication used by this item. The currently supported authentication typesare crypt, md5, and sha1, ripemd-160. Lastly vhost::swhois allows you to add an extraline to a users whois, exactly as it does in the Oper Block oper::swhois. Example: vhost { vhost my.own.personal.vhost.com; from { userhost my@isp.com; userhost myother@isp.com; }; login mynick; password mypassword; swhois "Im Special";}; 4.29 - Badword BlockOPTIONAL (Previously known as badwords.*.conf) Syntax: badword <type> { word <text-to-match>; replace <replace-with>; action <replace|block>;}; The badword block allows you to manipulate the list used for user and channelmode +G to strip "badwords". The badword:: specifies the type, validtypes are channel, message, quit, and all. channel is for the channel +G list, messageis for the user +G list, quit is for quit message censoring, and all adds it to all three lists.The badword::word can be a simple word or a regular expression we should search for. Thebadword::replace is what we should replace this match with. If badword::replaceis left out, the word is replaced with <censored>. The badword::action defineswhat action should be taken if this badword is found. If you specify replace, then thebadword is replaced, if you specify block, then the entire message is blocked. If you donot specify a badword::action, replace is assumed. Example: badword channel { word shit; replace shoot;}; 4.30 - ULines BlockOPTIONAL (Previously known as the U:Line) Syntax: ulines { <server-name>; <server-name>; ...}; The ulines block lets you define certain servers as having extra abilities.This should only be used for servers such as services and stats. This shouldnot be set for a normal server. Each entry is the name of the server which willreceive the extra abilities. Example ulines { services.mynetwork.com; stats.mynetwork.com;}; 4.31 - Link BlockOPTIONAL (Previously known as 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>; ... };}; This is the block you need for linking servers, please take your time to read allthis because this one of the hardest things to do and users often make errors ;P First of all server-name is the name of your remote server, the name the remoteserver has in his me { } block, like hub.blah.com (not the IP and can be different than hostname). username hostname
bind-ip (optional) port password-connect password-receive hub vs leaf hub (optional) leaf (optional) leaf-depth (optional) class compression-level (optional) ciphers (optional) options block
Example: 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; };};
Syntax [standard alias]: alias <name> { target <nick-to-forward-to>; type <type-of-alias>;}; (Note: also see here about the standard alias files UnrealIRCd has) The alias block [standard alias] allows you to forward a command to a user,for example /chanserv sends a message to the user chanserv. The alias:: specifiesthe name of the command that will be the alias (eg: chanserv), alias::target isthe nickname or channel it will forward to, if the alias:: is the same as the target, it willforward to, alias::target can be left out. The alias::type specifies the typeof alias, valid types are services (the user is on the services server), stats(the user is on the stats server), normal (the user is a normal user onany server), and channel (the target is a channel name). The alias block also has anotherpurpose which is explained below. Syntax [command alias]: alias <name> { format <regex-expression> { target <nick-to-forward-to>; type <type-of-alias>; parameters <parameter-string>; }; format <regex-expression> { ... }; type command;}; When the alias block is used in this format, it allows you a much broader rangeof usage. For example you can create aliases such as /identify. The alias::is the same as above, the name of the alias command. The alias::format specifiesa regular expression that compares against the text sent to the alias command,when matched the sub-entries of that alias::format will be used, you may havemultiple alias::format's to make the command do different things depending onthe text sent to it. The alias::format::target is the target to forward thisalias to. The alias::format::type specifies the type of the alias that themessage should be forwarded to. The alias::format::parameters is what willbe sent as the parameters to this alias. To specify one of the parameters givento the command alias specify % followed by a number, for example, %1 is thefirst parameter. To specify all parameters from a given parameter to the enddo % followed by the number and a -, for example %2- returns all parametersfrom the second till the last. Additionally, you may specify %n which will be replacedby the nickname of the user who executed the command. For examples of using the aliasblock in the command format, consult doc/example.conf. Syntax: help <name> { <text-line>; <text-line>; ...}; (Note: normally you just include help.conf) The help block allows you to create entries for use in /helpop. The help::is the value that must be passed to /helpop as a parameter, if the help:: isleft out, then it will be used when no parameter is passed to /helpop. The entriesfor the help block are the text that will be displayed to the user when requestingthe /helpop. 4.34 - Official Channels BlockOPTIONAL Syntax: official-channels { "#channel" { topic "The default topic"; };}; Official channels are shown in /list even if no users are in the channel.The topic is optional and is only shown in /list if it has 0 users. Example: official-channels { "#Help" { topic "The official help channel, if nobody is present type /helpop helpme"; }; "#Home"; "#Main" { topic "The main channel"; };}; 4.35 - Spamfilter BlockOPTIONAL The spamfilter block allows you to add local spamfilters (not network-wide). Syntax: spamfilter { regex <word>; target { <target(s)> }; action <action>; reason <reason>; ban-time <time>;}; regex is the regex to be matched. Examples: spamfilter { regex "Come watch me on my webcam"; target { private; channel; }; action gline; reason "You are infected, please go to www.antivirus.xx/blah/virus=GrrTrojan"; ban-time 6h;};spamfilter { regex "come to irc\..+\..+"; target { private; channel; }; action gline; action gline; reason "No spamming allowed";}; 4.36 - Set BlockREQUIRED (Previously known as unrealircd.conf/networks file) The set file is what use to be our networks/unrealircd.conf and our networksfile. On single server networks, rather than having 3 files you can just put allthe set statements in the unrealircd.conf itself, on multi-server networks, Irecommend using a seperate networks file. Now, if your server is on a network, chances are you will all basically usethe same Set settings. Therefore it makes more sense to have a network file,which is loaded with an include directive.Below you will find all of the set directives available. In this doc we refer to settings / directives in the <block-name>::<block-directive>format. This format is NOT the format that it can be entered into the configurationfile. IT MUST be converted to the format listed below. It is presented in theformat it is to make discussing it simpler. Syntax: set { <entry> <value>; <entry> <value>; ...}; The set block sets options for individual server features. Each entry doessomething different and therefore each will be described below. Some directiveshave sub blocks which will also be described. There are many set statementsto cover, all of the directives listed below can be included under ONE set statement.If a directive has options, they are included within the single set statementas well. set { kline-address my@emailaddress.com; auto-join #welcome; options { hide-ulines; }; hosts { local LocalOp.MyNet.com; global globalop.mynet.com; };}; Now if you wanted to make the set statements separate, say you wanted to setyour options in a single line. set::kline-address <email-address>; set::gline-address <email-address>; set::modes-on-connect <+modes>; set::snomask-on-connect <+modes> set::modes-on-oper <+modes>; set::snomask-on-oper <+modes>; set::modes-on-join <+modes>; set::restrict-usermodes <modes> set::restrict-channelmodes <modes> set::restrict-extendedbans <types|*> set::auto-join <channels>; set::oper-auto-join <channels>; set::anti-spam-quit-message-time <timevalue>; set::prefix-quit <text-to-prefix-quit>; set::static-quit <quit message>; set::static-part <no|yes|part message>; set::who-limit <limit>; set::silence-limit <limit>; set::oper-only-stats <stats-list>; set::oper-only-stats {<stats-flag>; <stats-flag>;}; set::maxchannelsperuser <amount-of-channels>; set::maxdccallow <amount-of-entries>; set::channel-command-prefix <command-prefixes>; set::allowed-nickchars { <list> }; set::allow-userhost-change [never|always|not-on-channels|force-rejoin] set::options::hide-ulines; set::options::flat-map; set::options::show-opermotd; set::options::identd-check; set::options::show-connect-info; set::options::dont-resolve; set::options::mkpasswd-for-everyone; set::options::allow-part-if-shunned; set::options::fail-oper-warn; set::dns::timeout <timevalue>; set::dns::retries <number-of-retries>; set::dns::nameserver <name-of-dns-server>; set::dns::bind-ip <ip>; set::network-name <name-of-network>; set::default-server <server-name>; set::services-server <server-name>; set::stats-server <server-name>; set::help-channel <network-help-channel>; set::cloak-keys { "key1"; "key2"; "key3"; }; set::hiddenhost-prefix <prefix-value>; set::hosts::local <locop-host-name>; set::hosts::global <globop-host-name>; set::hosts::coadmin <coadmin-host-name>; set::hosts::admin <admin-host-name>; set::hosts::servicesadmin <servicesadmin-host-name>; set::hosts::netadmin <netadmin-host-name>; set::hosts::host-on-oper-up <yes/no>; set::ssl::egd <filename>; set::ssl::certificate <filename>; set::ssl::key <filename>; set::ssl::trusted-ca-file <filename>; set::ssl::options::fail-if-no-clientcert; set::ssl::options::no-self-signed; set::ssl::options::verify-certificate; set::throttle::period <timevalue> set::throttle::connections <amount>; set::ident::connect-timeout <amount>; set::ident::read-timeout <amount>; set::anti-flood::unknown-flood-bantime <timevalue>; set::anti-flood::unknown-flood-amount <amount>; set::anti-flood::away-flood <count>:<period> set::anti-flood::nick-flood <count>:<period> set::default-bantime <time> set::modef-default-unsettime <value> set::modef-max-unsettime <value> set::ban-version-tkl-time <value> set::spamfilter::ban-time <value> set::spamfilter::ban-reason <reason> set::spamfilter::virus-help-channel <channel> set::spamfilter::virus-help-channel-deny <yes|no> set::spamfilter::except <target(s)> In addition to the configuration files, Unreal has a few other files, such as MOTD, OperMOTD,BotMOTD, and Rules. Listed below are the names of these files and their uses. Note that the motd files (all types) and rules files can also be specified in a tld block,these are just the files used by default (and for remote MOTD/RULES's).
7 – User & Oper Commands Table NOTE: the /helpop documentation is more up to date, use /helpop command (or /helpop ?command if you are oper)to get more information on a command.
If you are concerned about security (you should be!), this section will help you get an overviewof the risks that are out there and their risk-level. Alternatively you can use it as a "checklist"to walk through your (network) configuration to make things more secure. The list is ordered by by popularity/risk level/most-often-used-attack-methods: Choose good oper passwords, link passwords, etc: - use mixed case and digits ("Whbviwf5") and/or something long ("blaheatsafish", "AlphaBeta555"). - DO NOT use your link/oper passwords for something else like your mail account, bot password, forums, etc... 8.2 Non-Ircd related vulnerabilities There's a far bigger chance a box will get hacked by a non-irc(d) vulnerability than by some bug in UnrealIRCd.If you for example run http, dns, smtp and ftp servers on the same box you have a much higher risk.Also, if you are on a multi-user box (eg: you bought a shell) there's the risk of local exploits and bad permissions(see next). This risk is quite high so be careful when selecting a shell provider. 8.3 Permissions and the configfile Always make sure your home directory and UnrealIRCd directory have correct permissions,(group/)other shouldn't have read permissions. Otherwise a local user can simply grabyour configfile and look for passwords... In short: chmod -R go-rwx /path/to/Unreal3.2 if you are unsure about this. Other things related to this: never put your UnrealIRCd inside the webroot or some otherkind of shared directory. And for backups, make sure they get the correct permissions too(it happens quite frequently everything is secured fine but there's a backup.tar.gz lyingaround readable by everyone). You also want to use encrypted passwords wherever possible, if you compile with OpenSSLsupport (which you do, since you are concerned with security, right?) then I suggest touse sha1 or ripemd160 password encryption, else use md5. Also ifyou still have encrypted (oper) blocks left from Unreal3.2.1 or before I suggest you tore-enrypt these (just re-run /mkpasswd), because 3.2.1 introduced some considerableanti-crack improvements (basically a 14x slowdown of active cracks, and makingstored-plain-ciphertext cracks impossible). Still, do note that this is just 'yet another layer of security', since if you have weakpasswords they can still be cracked relatively easily and if someone manages to get yourconfigfile there are usually other interesting things in it that may aid an attacker,like link::password-connect. Just like most of these things, this is not UnrealIRCd-specific, but.. Always choose your opers and admins wisely. And do remember the concept of weakest-link.Even though you are careful and did everything in this doc, maybe your friend which is anoper too did something stupid. Like share his harddrive via netbios/kazaa/morpheus/..,got a trojan, used an obvious password, etc etc.. Unfortunately, it's not always in your control. One thing you could do however is carefuly choose which privileges someone needs (oper::flags). Use SSL connections between servers and as an oper, this will protect you against "sniffing".Sniffing is possible if an attacker hacked a box somewhere between you and your ircd server,he can then look at ALL network traffic that passes by; watch all conversations, capture all passwords(oper logins, nickserv, etc).. For the same reason, always use ssh instead of telnet. 8.6 Denial of Service attacks (DoS) [or: how to protect my hub] A lot of networks have experienced how much "fun" a flood or (D)DoS attack is, you can howeverdo some things to reduce the damage caused by it. Most nets have a hub server, what some peopleseem to forget is that it's quite easy to protect the hub server from getting attacked. I'll explain it here: 1. Set the name of the hub to a hostname that doesn't exist, eg 'hub.yournet.com', but don't add a dns record for it. This way an attacker cannot resolve the host and cannot flood it either. Then simply link your servers to the hub by specifying the IP or another non-public hostname. Example 1: link visibiblename.yournet.com { hostname 194.15.123.16; [etc] };. Example 2: link visibiblename.yournet.com { hostname thehostnamethatworks.yournet.com; [etc] };. On a sidenote, for the last example you must be sure your nameservers don't allow zone transfers,but that's way too off-topic ;). 2. Another important step is then to hide '/stats c' and other stats information, otherwise attackers can simply list your link blocks. Usually if you are this paranoid (like me) you can simply do: set { oper-only-stats "*"; }; to restrict all /stats usage. If you don't want that, at least hide "CdDlLXz". More about this in the next section. Of course those steps are less useful if they are applied afterwards (eg: after a few months) instead of at the beginning because the IP's might be already known to some evil guys, still.. it's worth to do. Also note that attackers can still flood all non-hub servers, but that requires more effort than just attacking 1 or 2 weak points (the hubs), also this way your hubs & serviceswill stay alive :). STATS The /stats command is very informative, you probably want to restrict it's usage as muchas possible. A question you should ask yourself is "what do I want my users to see?".Most big networks choose "nothing", while others prefer their clients to be able to do'/stats g' and '/stats k'. I suggest you to use set { oper-only-stats "*"; }; to deny all /stats for non-opers, but if you don'twant that, step through the '/stats' list (gives an overview of all available options) andblock everything except what you want to allow.. (if in doubt, just deny.. why should theyreally need to know all this?). To give you a few examples: - /stats o: gives you the nicks of opers (with correct case) and hostmasks. - /stats c: gives you an idea about serverlinks and which to use as 'backup', etc.. - /stats g, /stats k: usually used for banning proxies.. so this will simply give attackersa list of proxies they can use. - /stats E, /stats e: pretty sensitive info, especially if an attacker can use these addresses - /stats i, /stats y: might aid an attacker in finding hosts which allow lots of connections. - /stats P: helps him find serveronly ports etc etc... MAP / LINKS Several people have asked if there was some way to disable /map or /links.Our position on this is that it's silly and gives a false sense of security, let me explain...Hiding servers that are actually used by users is useless since they already knowabout your servers (how else could they get on them in the first place?). For any servers that youdon't want users on, see section 8.6. Now what CAN you do? Since 3.2.1 there's an option called 'flat map' (set::options::flat-map),this will make all servers appear as 'directly linked' in /map and /links, thus normal userscan no longer see which server is linked to which... This can be a nice additional layerof protection because this way a kiddie cannot easily spot any 'weak points' with /map or /links.So, use of this is recommended. Note that this is not foolproof... If any split happends someonecan still see which server was linked to which, and this is also true for some other things as well. NORMAL USERS & SNOMASKS A feature that isn't widely known is that normal users can also set some limited snomasks,namely +s +sk. By this they can see things like rehashes, kills and various other messages. To disable this you can use set::restrict-usermodes like this: set { restrict-usermodes "s"; };. Of course all of this is "information hiding", so it's not "true" security.It will however make it more difficult / increase the effort needed to attack/hack. 8.8 Protecting against exploits There are kernel patches that make it more difficult for stack- and heap-based exploits towork. This should however not be your main focus point, you have a far more bigger riskof getting exploited through the other points than this... for various reasons. There's one thing you should do however, which is to ALWAYS USE THE LATEST VERSION,subscribe to the unreal-notify mailinglistright now so you receive the release announcements (unreal-notify is for release announcements only,so only 1 mail per X months). Usually it's explicitly mentioned in the release announcement if therelease contains (high risk) security fixes, but it's good to upgrade anyway. As you now hopefully understand, you can never be 100% secure. You (and us) have tofind&fix every hole out there, while an attacker only needs to find just 1 server with 1 hole.Everything that was explained here DOES however help by minimizing the risks considerably.Do take the time to secure your network and educate your opers. A lot of people don't care aboutsecurity until they got hacked, try to avoid that :). 9 – Frequently Asked Questions (FAQ) The FAQ is available online here Regular expressions are used in many places in Unreal, including badwords, spamfilter, and aliases. Regular expressions are a very complex tool used for pattern matching. They are sometimes referred to as "regexp" or "regex." Unreal uses the TRE regular expression library for its regex. This library supports some very complex and advanced expressions that may be confusing. The information below will help you understand how regexps work. If you are interested in more technical and detailed information about the regexp syntax used by Unreal, visit the TRE homepage. Literals are the most basic component of a regexp. Basically, they are characters that are treated as plaintext. For example, the pattern "test" consists of the four literals, "t," "e," "s," and "t." In Unreal, literals are treated as case insensitive, so the previous regex would match "test" as well as "TEST." Any character that is not a "meta character" (discussed in the following sections) is treated as a literal. You can also explicitely make a character a literal by using a backslash (\). For example, the dot (.) is a metacharacter. If you wish to include a literal ., simply use \. and Unreal will treat this as a period. It is also possible that you want to check for a character that is not easily typed, say ASCII character 3 (color). Rather than having to deal with using an IRC client to create this character, you can use a special sequence, the \x. If you type \x3, then it is interpretted as being the ASCII character 3. The number after the \x is represented as hexidecimal and can be in the range from \x0 to \xFF. The dot (.) operator is used to match "any character." It matches a single character that has any value. For example, the regex "a.c" will match "abc," "adc," etc. However, it will not match "abd" because the "a" and "c" are literals that must match exactly. One of the common mistakes people make with regex is assuming that they work just like wildcards. That is, the * and ? characters will match just like in a wildcard. While these characters do have similar meaning in a regex, they are not exactly the same. Additionaly, regular expressions also support other, more advanced methods of repetition. The most basic repetition operator is the ? operator. This operator matches 0 or 1 of the previous character. This, "of the previous character," is where the ? in regex differs from a wildcard. In a wildcard, the expression, "a?c" matches an "a" followed by any character (or no character), followed by a "c." In regex it has a different meaning. It matches 0 or 1 of the letter "a" followed by the letter "c." Basically, the ? is modifying the a by specifying how many a's may be present. To emulate the ? in a wildcard, the . operator is used. The regex "a.?c" is equivilent to the previously mentioned wildcard. It matches the letter "a" followed by 0 or 1 of any character (the ? is modifying the .), followed by a "c." The next repetition operator is the *. Again, this operator is similar to a wildcard. It matches 0 or more of the previous character. Note that this "of the previous character" is something that is characteristic of all repetition operators. The regex "a*c" matches 0 or more a's followed by a "c." For example, "aaaaaac" matches. Once again, to make this work like a wildcard, you would use "a.*c" which will cause the * to modify the . (any character) rather than the "a." The + operator is very similar to the *. However, instead of matching 0 or more, it matches 1 or more. Basically, "a*c" will match "c" (0 a's followed by a c), where as "a+c" would not. The "a+" states that there must be "at least" 1 a. So "c" does not match but "ac" and "aaaaaaaaac" do. The most advanced repetition operator is known as a "boundary." A boundary lets you set exact constraints on how many of the previous character must be present. For example, you may want to require exactly 8 a's, or at least 8 a's, or between 3 and 5 a's. The boundary allows you to accomplish all of these. The basic syntax is {M,N} where M is the lower bound, and N is the upper bound. For example, the match between 3 and 5 a's, you would do "a{3,5}". However, you do not have to specify both numbers. If you do "a{8}" it means there must be exactly 8 a's. Therefore, "a{8}" is equivilent to "aaaaaaaa." To specify the "at least" example, you basically create a boundary that only has a lower bound. So for at least 8 a's, you would do "a{8,}". By default, all of the repetition operators are "greedy." Greediness is a somewhat complex idea. Basically, it means that an operator will match as many characters as it can. This is best explained by an example. Say we have the following text: In this example, you might think that the .+ matches "HE." However, this is incorrect. Because the + is greedy, it matches "HEL." The reason is, it chooses the largest portion of the input text that can be matched while still allowing the entire regex to match. In this example, it chose "HEL" because the only other requirement is that the character after the text matched by .+ must be an "L". Since the text is "HELLO", "HEL" is followed by an "L," and therefore it matches. Sometimes, however, it is useful to make an operator nongreedy. This can be done by adding a ? character after the repetition operator. Modifying the above to, ".+?L" the .+? will now match "HE" rather than "HEL" since it has been placed in a nongreedy state. The ? can be added to any repetition character: ??, *?, +?, {M,N}?. Bracket expressions provide a convenient way to do an "or" operator. For example, if you want to say "match an a or a b." The bracket expression gets its name from the fact that it is enclosed in brackets ([]). The basic syntax is that the expression includes a series of characters. These characters are then treated as though there were an "or" between them. As an example, the expression "[abc]" matches an "a," a "b," or a "c." Therefore, the regexp "a[bd]c" matches "abc" and "adc" but not "acc." One very common thing to do is to check for things such as, a letter, or a digit. Rather than having to do, for example, "[0123456789]", the bracket operator supports ranges. Ranges work by specifying the beginning and ending point with a - between them. Therefore, a more simplistic way to test for a digit is to simply do "[0-9]". The same thing can be used on letters, or in fact, any range of ASCII values. If you want to match a letter, simply do "[a-z]" since Unreal is case insensitive, this will match all letters. You can also include multiple ranges in the same expression. To match a letter or a number, "[0-9a-z]". One complication that this creates is that the - is a special character in a bracket expression. To have it match a literal -, the easiest way is to place it as either the first or last character in the expression. For example, "[0-9-]" matches a digit or a -. To make things even more simple, there are several "character classes" that may be used within a bracket expression. These character classes eliminate the need to define certain ranges. Character classes are written by enclosing their name in :'s. For example, "[0-9]" could also be written as "[:isdigit:]". The list below shows all of the available character classes and what they do:
The last feature of the bracket expression is negation. Sometimes it is useful to say "anything except these characters." For example, if you want to check if the character is "not a letter," it is easier to list a-z and say "not these," than it is to list all the non-letters. Bracket expressions allow you to handle this through negation. You negate the expression by specifying a "^" as the first character. For example, "[^a-z]" would match any non-letter. As with the -, if you want to include a literal ^, do not place it in the first position, "[a-z^]". Also, to negate a character class, you must once again use nesting, "[^[:isdigit:]]" would match any non-digit. Assertions allow you to test for certain conditions that are not representable by character strings, as well as providing shortcuts for some common bracket expressions. The ^ character is referred to as the "left anchor." This character matches the beginning of a string. If you simply specify a regex such as "test", it will match, for example "this is a test" since that string contains "test." But, sometimes it is useful to ensure that the string actually starts with the pattern. This can be done with ^. For example "^test" means that the text must start with "test." Additionally, the $ character is the "right anchor." This character matches the end of the string. So if you were to do "^test$", then the string must be exactly the word "test." Similar tests also exist for words. All of the other assertions are specified using a \ followed by a specific character. For example, to test for the beginning and ending of a word, you can use \< and \> respectively. The remaining assertions all come with two forms, a positive and a negative. These assertions are listed below:
Alternation is a method of saying "or." The alternation operator is the vertical bar (|). For example, if you wanted to say "a or b" you could do "a|b". For normal letters, this could be replaced by a bracket expression, but alternation can also be used with subexpressions (discussed in the next section). Subexpressions are a portion of of a regex that is treated as a single entity. There are two ways to create a subexpression. The two methods differ with regard to "back references," which will be explained later. To declare a subexpression that uses back references, simply enclose it in parentheses (). To create a subexpression that does not use back references, replace the open-parenthesis with, "(?:". For example, "([a-z])" and "(?:[a-z])". The reason subexpressions are useful is you can then apply operators to the expression. All of the repetition operators, for example, that were mentioned as "X or more of the previous character," can also be used for "X or more of the previous subexpression." For example, if you have a regex of "[0-9][a-z][0-9]", to match a digit, followed by a letter, followed by a digit, and then you decided you wanted to match this sequence twice. Normally, you would do, "[0-9][a-z][0-9][0-9][a-z][0-9]". With subexpressions, however, you can simply do "([0-9][a-z][0-9]){2}". Back references allow you to reference the string that matched one of the subexpressions of the regexp. You use a back reference by specifying a backslash (\) followed by a number, 0-9, for example \1. \0 is a special back reference that refers to the entire regexp, rather than a subexpression. Back references are useful when you want to match something that contains the same string twice. For example, say you have a nick!user@host. You know that there is a trojan that uses a nickname and username that matches "[0-9][a-z]{5}", and both the nickname and username are the same. Using "[0-9][a-z]{5}![0-9][a-z]{5}@.+" will not work because it would allow the nickname and username to be different. For example, the nickname could be 1abcde and the username 2fghij. Back references allow you to overcome this limitation. Using, "([0-9][a-z]{5})!\1@.+" will work exactly as expected. This searches for the nickname matching the given subexpressions, then it uses a back reference to say that the username must be the same text. Since you can only have 9 back references, this is the reason why the (?:) notation is useful. It allows you to create a subexpression without wasting a back reference. Additionally, since back reference information does not need to be saved, it is also faster. Because of this, non-back reference subexpressions should be used whenever back references are not needed. As was already mentioned, Unreal makes all regexps case insensitive by default. The main reason for this is, there seem to be many more instances where you want case insensitive searching rather than sensitive, for example, if you block the text "www.test.com," you presumably want to block "WWW.TEST.COM" as well. However, there are instances where you may want case sensitivity, for example, matching for certain trojans. Because of this, a method is provided to dynamically turn case insensitivity on/off. To turn it off, simply use "(?-i)" and to turn it on, "(?i)". For example, "(?-i)[a-z](?i)[a-z]" will match a lowercase letter (case insensitivity is off) followed by either an uppercase or lowercase letter (case insensitivity is on). Additionally, rather than having to always remember to turn the flag back on when you are finished, you can also specify that the flag change should only apply to a subexpression, for example, "(?-i:[a-z])[a-z]" is equivilent to the previous regexp because the -i only applies to the given subexpression.
|