When true all users must have a real-name set or will not allow them on the server.
Example:
/as security set allow-null-realname false
/as security set allow-null-realname true
Many clone scripts do not use the real-name field and this is just one more way to lock down your server.
Disable all private messages on the server. This means that users will only be able to send channel messages, or system notices (for administrators).
Examples:
/as security set channelonly on
There are applications where you do not want users to be able to message each other. This mode is for those applications that require tighter security than a modelock on umode +m
If the number of clones from a specific IP exceeds "multiplier * trigger" services automatically akills that IP.
Examples:
/as security set clone-kill-multiplier 5
The default trigger used by services
Examples:
/as security set deftrigger 5
This sets the timing for flood control on the server. Users gain penalties as they send messages to the server. As time passes between messages the penalty count lowers. Each time the user sends more messages per second than allowed, they gain a penalty. When they have more than their allowed penalties they get disconnected if kill is set on. If the user paused, the penalty count would lower. Values are on|off for the kill option. All other values are in seconds.
KILL - Disconnect users when users hit the flood limits.
OPER - Adjust Server Operator flood limits.
PENALTIES - Number of penalties allowed within the set time period.
SECONDS - The window of time that penalties will be accumulated.
Examples:
/as security set flood kill off
/as security set flood kill on
/as security set flood seconds 2
/as security set flood penalties 12
/as security set flood oper 3
The lower the seconds and penalties are set, the more flooding will be discouraged. But some bots or scripts may send commands faster but have legitimate purposes. Try to experiment to find the right balance for your network.
This is how ofter services warms... e.g. with a granularity at 5, and trigger at 10, you'd get a warning at 10, 15, 20, 25, 30, ...
Examples:
/as security set granularity 5
This controls how many /invite commands can be sent for each room. Each room can send as many as the count as often as the seconds.
Examples:
/as security set invite count 5
/as security set invite seconds 2
There are valid reasons for invites, but some people use them as a way to advertise their rooms. When the invite limit is exceeded, the invites will simply not be sent and the user will get an error message warning them not to mass advertise. If they try again a little later, the invite will go through.
If enabled this command limits clients from joining channels that do not have any channel operators (+o clients) in them.
NONE - Don't allow any clients to join unmanaged channels.
IRC - Only allow IRC clients to join unmanaged channels.
JAVA - Only allow Java clients to join unmanaged channels.
BOTH - Allow both client types to join unmanaged channels.
Examples:
/as security set joinunmananaged irc
/as security set joinunmananaged java
/as security set joinunmananaged both
This mode can lead to reduced server abuse by drones and other types of malicious clients. See also security set joinunregistered
This command will limit which clients can join unregistered channels based on their status. For example if you have it set to java, then only java clients will be able to join unregistered channels:
NONE - Don't allow any clients to join unregistered channels.
IRC - Only allow IRC clients to join unregistered channels.
JAVA - Only allow Java clients to join unregistered channels.
BOTH - Allow both client types to join unregistered channels.
Examples:
/as security set joinunregistered irc
/as security set joinunregistered java
/as security set joinunregistered both
This mode can lead to reduced server abuse by drones and other types of malicious clients. See also security set joinunmananaged
This is a command that will create log files for different events occurring on your server. The logs are stored to WEBMASTER/DB/CRACCESS.LOG and you will need to shut down the server to open the logs.
0 = Log nothing
1 = Log local clients
2 = Log local errors
3 = Log local clients and local errors
Example:
/as security set loglevel 2
Logs can be useful if your server goes down, to see what was happening just before it stopped running.
This command sets the number of bans allowed in each room's ban list. The default is fifty. A network operator can add bans even if the ban list is full.
Example:
/as security set maxbans 30
Bans are an important part of room maintenance; they allow the room operators to keep out users who cause problems. Larger ban limits give room operators more space to deal with problems, but use up more database space. Smaller ban limits use up less space and encourage room operators to be more efficient with their bans, but may be too restrictive. If your network has services then a small ban limit may encourage more akicks to be set.
This command will set a maximum number of rooms a user can join at one time. The default is 12 rooms. You can increase or decrease the number as you see fit.
Example:
/as security set maxchans 12
Some networks want to limit their users to only a single room. Others want to allow a large number. This setting is just a matter of how the administration wants their network used.
This command sets the minimum number of users that must be in a room for the room to be included in the /list command. The default setting is two.
Example:
/as security set minlist 3
Generally you will want the minlist to be either 1,2, or 3. If it is set to 1 then all rooms in use will be shown in the list, which is intuitive for users. But many of the rooms will not actually be interesting, and if the list is long, the users will have to weed through it to find useful information. Most users won't want rooms with only one other user. Rooms with two users may have actual chat, but they are also more likely to be personal or dull. Rooms with three or more users tend to be good rooms for chat. But having rooms in the list that are not particularly friendly does not cause many problems, while rooms that are not shown are not going to have more users joining them very often. So setting the minlist too high will make it difficult for new rooms, even good ones, to become popular. As with everything else, it is a trade-off and depends on your priorities.
This command sets the access level required to create new rooms.
All - All may create rooms.
REGISTERED - Must be a registered and identified user.
JAVA - Must be on a ConferenceRoom java applet.
REGORJAVA - Must be registered or on a java client.
Oper - Must be +o to create rooms.
SA - Must be +a to create rooms.
Admin - Must be +s to create rooms.
Example:
/as security set newchan all
If you allow everyone to create new rooms then you will have a network with a large number of rooms on various topics. The advantage of this is that the users will normally enjoy it more and you do not need to think up every room they might want nor run each one yourself. The disadvantage is that they may create some rooms that you do not approve of without you noticing. All of the other levels allow you to choose who is responsible enough to create new rooms if you have decided to have a more restrictive network.
When noop is set on, someone who joins an unregistered room will not get opped even if they are the first person to join. The effect of this is that they cannot register nor control the room. The default is off.
Example:
/as security set noop on
If newchan is set to all and noop is set to on, then people can join dynamic rooms, but they cannot control them. This may be the effect you want if you want all users to have equal power in new rooms. Although then you still need to have network operators running new rooms or let them remain unsupervised.
This turns on or off IP address spoof protection. This will prevent spoofed IP addresses from getting on the server. Most current operating systems like Windows2000, FreeBSD, Solaris7+ and Linux do not need this feature enabled.
Example:
/as security set nospoof on
/as security set nospoof off
If you do not have a reason to turn this off, leave it on. Nospoof protection is important to make bans work and to identify users.
This command will enable or disable part and quit messages from being viewed in rooms by local users.
Example:
/as security set reasons off
Part and quit messages add flavor to chat. But on the downside, they are very difficult to control. You can't effectively ban a user for an offensive quit message when they may not try to login again until the ban is gone. Most users will either use the default part/quit messages or use their parts and quits to put in a personal message that, much like an email .sig, says something about them. But a small number may use these messages in annoying ways. You can choose to allow the messages for the majority of legitimate users or remove them to prevent the abuse. They also can be annoying just for their length, even if they are interesting. If most of your rooms have a very large number of users, then the part/quit messages add to the scroll while not contributing to the chat, and thus may be a detriment to the network.
This command will enable or disable STATS requests by users. Network operators can still see stats.
Example:
/as security set stats on
For the most part non-operators do not need to see stats. They may find some of them useful or interesting, but they should be able to get by without them. Disabling them can be useful since they provide information, and some users may try to use that in ways you dislike. Particularly by listing bans they can try to find ways to evade them. Restricting stats to network operators only may make your server somewhat more secure.
This creates a more strict version of the +i user mode. When this is enabled (it is by default) the server will not allow users to message other users that are also +i that do not meet the following criteria:
1) They don't share the same channel.
2) They don't have a watch for the other user. (Both sides must have watches set).
3) The user is not a buddy.
Example:
/as security set superinvis off
This prevents mass messaging outside of the channel environment and allows users to only communicate with those that already have an aquaitence with.
Sets the maximum number of characters in a user name. The default is 10.
Example:
/as security set usernamelength 10
Raising this value above the default may cause problems with some chat clients and is not recommended.
Normally the who command will show differences between opers, channel ops and users. When this is enabled it applies new rules to the server.
1) '*' not shown for IRCops when command is issued by someone who is not an IRCop or channel op.
2) Even if you are in the channel, and even if the channel isn't secret/private the command works as if you weren't in it and it was private if you are neither a channel op nor an IRCop.
3) 'WHO #<channel> o' is disallowed unless you are a channel op or IRCop.
Example:
/as security set whochan off
This tightens down the security for those implementations that are more vulnerable to external scripting and use of mass advertising.