tips & tricks - Security Part 1

Talk about pretty much anything here, but DO NOT USE FOR SUPPORT.

Moderator: Supporters

Official supporter
Posts: 1124
Joined: Sun Apr 18, 2004 5:06 pm

tips & tricks - Security Part 1

Post by katsklaw » Thu Sep 29, 2011 7:56 pm

I got bored so I thought I'd post a quick list of tips & tricks you can use to make your network more secure. The main thing I see with newer admins these days is they will simply configure their network only enough to make services link to the ircd and then call it quits. HARDLY! :)

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 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? :P 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";
4> Since opers are expected to be a bit more tech savvy, it's ok to require them to do more for their access. As painful as it may be and regardless of the amount of excuses your opers have about getting around this first point .. DONT DO IT!! I personally travel for a living. I literally spend the night in a different town every single day and I still use this advice. Do NOT EVER use *@* as the host mask in a users oper block!! Yes, it's a pain when dealing with opers like me that have many many IPs or ISPs, but no one ever said being an oper, let alone a server/network admin was all fun and games. If they did, you have my permission to tell them I said they lied!! :) Administration can be very taxing at times. Some days you don't even get to chat because you are so busy handling your admin duties. Have a backbone and stick to your guns on this point. It can prevent a malicious user from taking over an oper account. If you don't think it's serious, please read these: ... mpromised/ ... mpromised/

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: ... 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.

Head of Support
Posts: 2086
Joined: Tue Jun 15, 2004 8:50 pm
Location: Chino Hills, CA, US

Re: tips & tricks - Security Part 1

Post by Stealth » Fri Sep 30, 2011 3:57 am

Just a quick note, we've also got more information here: