Here's a few extra things you can do to be more secure.
1> Properly setup and config your aliases as well as set::services-server,
2> Use and advertise the /id and /identify aliases that are in example.conf. This makes it so users type: /id <password> to identify to either nick or channel. There is no need to type out the entire thing. /msg nickserv identify #Channel MyUberPass would simply be /id #Channel MyUberPass.
3> Working in concert with #1 and #2 above, if your services package can strict privmsg usage, DO IT! Just make sure aliases are working first. This will prevent users, and yourself from having to type: /msg [email protected] before each command. This along with the aliases will insure 100% success when communicating with services.
Why is this important? Glad you asked! On a poorly configured network it would be possible for any user to take NickServ as their nick and get users passwords. However, your network is properly configured, right? We do this by Q:Line'ing services nicks so that only services can use them. Generally speaking this is already done when services connects. Anope does it automaticly for example. There is no harm in manually doing it too. We do this with a ban nick block. Using the example below we banned the nick ChanServ or any thing looking like ChanServ, the same can be done for any nickname. It can also be used to provide work arounds for poorly written clients too. Example is many years ago there was a mIRC bug that caused mIRC to crash when it tried to private message a COM port. The bug caused mIRC to freeze thus acting as a victim initiated DOS attack. Obviously this bug is long since patched, but we will use it as an example. We could use a ban::nick block to reserve COM* ports like COM1, COM2 .. etc. There are many other uses but I think you get the idea. the ban::nick block must exist on all servers or on a globally loaded config if you use Remote Includes.
Example ban::nick block for ChanServ:
Code: Select all
ban nick {
mask "*C*h*a*n*S*e*r*v*";
reason "Reserved for Services";
};
http://www.irc-junkie.org/2011-08-14/mi ... mpromised/
http://www.irc-junkie.org/2005-11-15/un ... mpromised/
http://forums.unrealircd.com/viewtopic.php?f=3&t=6182
Just to name a few. Unreal's oper block can handle multiple oper::from::userhost and they are free of charge! USE THEM!! Personally, I'd rather you complain about having to add the 15th userhost than you complain your network was hacked because you was lazy and used *@* just once.
5> If possible use SSL Certs! They are rather easy and can be used on many popular clients. A quick how-to is found at: http://forums.unrealircd.com/viewtopic. ... 81&p=21634 Using SSL Certs requires you to compile with ssl and requires the oper to be connected via a SSL enabled port, but that's just a bit more security.
6> As mentioned in #5, Enable SSL and use ssl connections for ALL servers! This will inherently secure services data too as long as services connects to it's uplink server locally. Also with #5 require as many opers to use ssl as possible. The more ssl enabled connections you have, the more secure the data. Just like a chain, data security is only as strong as the weakest link. If your servers are ssl and all your opers are ssl, then your data is completely secure right? WRONG! Users connect to non-ssl enabled ports all the time and that is a break in your security. While it's not realistic to require all users to use ssl, it's an advantage to endorse and promote it. If every point from beginning to end is using SSL, then SSL has been helpful.
I hope this helps, even 1 person.
Thanks for reading.