ChannelSecurity - Revision history

Unknown Entity: /* Invite Exceptions */

2012-08-07T19:26:34Z

‎Invite Exceptions

Unknown Entity: /* Invite Exceptions */

2012-08-07T19:20:08Z

‎Invite Exceptions

Unknown Entity: /* Unregistered channels */ Adding some information about the +I channel mode

2012-08-07T19:19:52Z

‎Unregistered channels: Adding some information about the +I channel mode

FiXato: /* NOJOIN Level */

2011-02-22T00:17:46Z

‎NOJOIN Level

Unknown Entity at 01:08, 17 February 2011

2011-02-17T01:08:28Z

FiXato: /* Knock */ Added info about +K

2010-12-01T13:21:16Z

‎Knock: Added info about +K

FiXato: Added links to the Mlock article.

2010-09-26T15:57:07Z

Added links to the Mlock article.

FiXato: /* Using ACCESS system */

2010-09-26T15:49:26Z

‎Using ACCESS system

FiXato: /* ChanServ Restricted */ Added pros and cons and some more references to semi-identified.

2010-09-26T15:16:23Z

‎ChanServ Restricted: Added pros and cons and some more references to semi-identified.

FiXato: Reduced the level of headers by 1

2010-09-26T15:09:47Z

Reduced the level of headers by 1

Show changes

← Older revision		Revision as of 19:26, 7 August 2012
Line 104:		Line 104:

	such that they will only be allowed in if their nick is StaffMember, they have a consistent ident as listed in the mask, and they are coming from the same ISP region all the time.		such that they will only be allowed in if their nick is StaffMember, they have a consistent ident as listed in the mask, and they are coming from the same ISP region all the time.
		+
		+
		+	===Pros===
		+	* You have a server side list of who is and isn't allowed to enter your channel without an /invite
		+	* People matching +I masks can just join without having to /knock or be /invite-d
		+	===Cons===
		+	* There is no method of persistent storage of the +I list in the event the channel gets destroyed

	==Unregistered channels==		==Unregistered channels==

@@ Line 86: / Line 86: @@
 * An invite evades bans (if you invite a user that otherwise wouldn't be allowed to enter because of a +b channel-mode ban, he'll be allowed to enter.)
-===Invite Exceptions===
+==Invite Exceptions==
 You can use channel mode +I to create "Invite Exceptions".  These work exactly like [[Ban|bans]] (+b) and [[Ban#Ban_Exceptions|ban exceptions]] (+e) , only they will allow matching hostmasks to bypass the need for an /invite to join the channel. Please note that there is 'not' a way to save these via ChanServ like how bans have the '/chanserv akick', so when the channel is destroyed (when the last person leaves), all invite exceptions will be 'removed'.

@@ Line 85: / Line 85: @@
 ===Cons===
 * An invite evades bans (if you invite a user that otherwise wouldn't be allowed to enter because of a +b channel-mode ban, he'll be allowed to enter.)
 ==Unregistered channels==

@@ Line 200: / Line 200: @@
 By default, on a newly created channel, this is set to level -2, allowing everyone to be on the channel, unless they have a userlevel of -2 or lower.
-However, when you enable RESTRICTED, it will automatically be changed to 0, thus disallowing everyone who is NOT on the access level with a level of 1 or higher.<br />
+However, when you enable RESTRICTED, it will automatically be changed to 0, thus disallowing everyone who is NOT on the access list with a level of 1 or higher.<br />
 You can still change this back manually to -2 after you've set RESTRICTED ON with:
    /CHANSERV LEVELS #channel SET NOJOIN -2

← Older revision		Revision as of 01:08, 17 February 2011
Line 1:		Line 1:
		+	[[Category:EN]]
	There are several ways on locking down your channel to restrict access. This article deals with several suggestions to make your channel less prone to attacks by malicious users.		There are several ways on locking down your channel to restrict access. This article deals with several suggestions to make your channel less prone to attacks by malicious users.

@@ Line 66: / Line 66: @@
    NoticeOp(eu.chat4all.org): [Knock] by JackDaniels!Jack@the.liquor.cabinet (I want in..)
 Upon which they can decide whether or not to invite you (or ban you in case they get tired of your knocks)
 You can't knock if:
@@ Line 71: / Line 77: @@
 * you are already on the channel
 * the channel is not invite-only
 ===Pros===

@@ Line 17: / Line 17: @@
 * If someone mentions your channelname in a different channel, malicious users might find out about the channel as well.
 * You won't as easily get new users perhaps, since people with similar interests can't discover the channel through /LIST
-* Mode will be lost when channel is destroyed (for instance when no-one is in the channel anymore). This can be circumvented though for registered channels by adding the +s mode to the channel's ChanServ MLOCK setting.
+* Mode will be lost when channel is destroyed (for instance when no-one is in the channel anymore). This can be circumvented though for registered channels by adding the +s mode to the channel's [[Mlock|ChanServ MLOCK]] setting.
 =Channel Key=
@@ Line 35: / Line 35: @@
 * Prevents random users from entering your channel when they see it in the channel /LIST.
 ==Cons==
-* Mode will be lost when channel is destroyed (for instance when no-one is in the channel anymore). This can be circumvented though for registered channels by adding the key mode to the channel's ChanServ MLOCK setting.
+* Mode will be lost when channel is destroyed (for instance when no-one is in the channel anymore). This can be circumvented though for registered channels by adding the key mode to the channel's [[Mlock|ChanServ MLOCK]] setting.
 * First user to enter will not need the channel key to enter, since the channel effectively doesn't exist at that point and thus has no key mode set. This can be worked around by requesting the ChannelKeeper bot to be added to your channel to keep the channel open.
 * It is harder for people to join the channel if they are using an applet.
@@ Line 83: / Line 83: @@
 ===Extra cons for unregistered channels===
 * The +i mode will be lost when the channel is 'destroyed' because the last user left.
-* The first user to enter does not need to be invited, because since +i is only set ''after'' the first user has entered. This can only be worked-around for registered channels using ChannelKeeper and MLOCK; see the next section for details)
+* The first user to enter does not need to be invited, because since +i is only set ''after'' the first user has entered. This can only be worked-around for registered channels using ChannelKeeper and [[Mlock|ChanServ MLOCK]]; see the next section for details)
 * An operator always needs to be active to let people in (though there are ways for registered channels to work around this, see further sections)
 ==Registered channels==
-Registered channels can add the +i channel-mode to the ChanServ MLOCK, so it will automatically be set (and not allowed to be unset) upon channel creation (when the first user enters the room).
+Registered channels can add the +i channel-mode to the [[Mlock|ChanServ MLOCK]], so it will automatically be set (and not allowed to be unset) upon channel creation (when the first user enters the room).
 However, since no channel-modes are in effect when a channel has no users, the first user to enter the channel will be able to enter without being invited (since +i will be set ''after'' the first user has entered).
 This can be circumvented by requesting the ChannelKeeper to be added to your room to always keep it open.
@@ Line 96: / Line 96: @@
 ===Extra pros for registered channels===
-* You can add +i to the channel's ChanServ MLOCK setting.
+* You can add +i to the channel's [[Mlock|ChanServ MLOCK]] setting.
 * You can request a ChannelKeeper to keep the channel open so the +i mode is also effective for the first real user to enter the channel.
 * CHANSERV INVITE can be used by users with the proper rights (see next sections for details)

@@ Line 118: / Line 118: @@
 ===Using ACCESS system===
 If you are using the [[Levels|ACCESS LEVELS]] system instead of the xOP system, you have a bit more control over who you'll allow access to the ChanServ INVITE command to invite themselves into the channel.
-For information on how/when to enable the [[Levels||ACCESS LEVELS]] system by disabling the xOP system, please read the [[Levels||main article on access levels]].
+For information on how/when to enable the [[Levels|ACCESS LEVELS]] system by disabling the xOP system, please read the [[Levels|main article on access levels]].
 Using the default access levels, you can add a user with the minimum of level 5 to your channel's ChanServ Access list:

@@ Line 154: / Line 154: @@
 # Your NickServ SECURE setting is set to OFF (please note that this by default is set to ON)
 # You are connected from a host that matches the hostmask in your /NICKSERV ACCESS LIST
 ==using xOP system==
@@ Line 216: / Line 218: @@
    Allows:
      # people who are identified for their nickname,
-     # people who are on the ChanServ ACCESS list with a nickname that is semi-identified
+     # people who are on the ChanServ ACCESS list with a nickname that is semi-identified (unless the channel's SECURE setting is ON)
 NOJOIN 0  ->
@@ Line 224: / Line 226: @@
    Allows:
      # everyone who is on the access list with a positive level