# Preparations to run an IRCd daemon



## wlanboy (Sep 21, 2013)

Knowing that some board members are running IRC networks for quite some time -

I want to ask some basic questions about running an IRC daemon.


What type of server is suitable
OpenVZ, KVM, dedicated?
What type of OS should be used (net stack)
Linux like Debian or some BSD?
How much RAM and traffic is needed?
Which daemon should be used for a small lightweight network?
I have looked into UnrealIRCd, InspIRCd, Bahamut, Ratbox and Charybdis.
My choice would be InspIRCd.
What services should be used?
Atheme, Anope, BOPM, Deonra, NeoStats, ...?
And no I don't want to run the next fancy public IRC network. Maybe a private one later.

But today I just want to have a small own network to test my own IRC stuff I am currently developing.


----------



## HalfEatenPie (Sep 21, 2013)

Not that I know a whole lot about this, but just giving you a basic idea in terms of traffic.

My IRC Bouncer uses about 1GB (average) in bandwidth per month. Depending on how many leaves you have and how many people are active on your IRC Network (and bandwidth is cheap in Europe and parts of USA) I wouldn't be too worried about the traffic use.

Of course this is just me and my own personal uses. Could be totally different for others.


----------



## splitice (Sep 21, 2013)

Get good DDoS protection. There is a large correlation between people who get easily angered on IRC and people who start DDoS's.

There are reasons there are providers who offer DDoS protection and started out to host IRCs (e.g Sharktech).

Also choose your provider carefully, ensure you have a good relationship with them as botnet operators will try and use you. Ensure you have measures in place for this, and an agreement with your provider for handling this (you dont want your network offline do you?).


----------



## HalfEatenPie (Sep 21, 2013)

splitice said:


> Get good DDoS protection. There is a large correlation between people who get easily angered on IRC and people who start DDoS's.
> 
> 
> There are reasons there are providers who offer DDoS protection and started out to host IRCs (e.g Sharktech).
> ...


Haha while IRC is known to be a honeypot for DDoS, I'd say for his current uses (private/personal) it'd be fine.  As long as no-one he brings onto his network is an unstable individual who will decide to DDoS due to emotional reasons it should be fine.  

In terms of actual setup I hear tons of people use Debian, but that's my understanding.


----------



## Tux (Sep 21, 2013)

Services is a tricky thing. A lot of the larger networks use Atheme, some use Anope, some none at all.


----------



## 365Networks (Sep 21, 2013)

I don't think mitigation is needed if it's a personal IRC server. Maybe something simple like BuyVM or RamNode's mitigation would always be nice, but not needed IMO.

My choices go for Unreal, InspIRCd, and Charybdis. It basically comes down to personal choice.

You can have services and the IRCd easily on a ~256MB box.


----------



## blergh (Sep 21, 2013)

wlanboy said:


> Knowing that some board members are running IRC networks for quite some time -
> 
> I want to ask some basic questions about running an IRC daemon.
> 
> ...


1. I would recommend a dedicated box, you never know if anyone decides to attack your network, and if you are on a shared environment it will suck for all parties.

2. Doesn't matter. I used FreeBSD and Debian.

3. Not much at all. 256MB is plenty unless you're serving a buttload of users, or running services on the same box.

4. I liked inspire, but i suppose unreal is okay too.

5. bopm can help if you configure it properly. Anope as well.


----------



## mojeda (Sep 21, 2013)

My IRC server is currently using 18MB of RAM for ~100 users.

It's also running flash daemon, BOPM, and whatever other system processes.

My network uses InspIRCd + Atheme however we are looking into ShadowIRCd or a fork of it: http://www.irc-wiki.org/ShadowIRCd.

I'm currently using a 128MB OpenVZ vps from BuyVM for my server and it's way more than sufficient.

Our IRC Services is on another vps and is using around 70MB of RAM, it's running both InspIRCd and Atheme however regular users do not connect to this server, just the services bots (NickServ, ChanServ, etc).


----------



## wlanboy (Sep 22, 2013)

HalfEatenPie said:


> My IRC Bouncer uses about 1GB (average) in bandwidth per month.


I am running a bouncer too and it is consuming about the same level of bandwith.



splitice said:


> Get good DDoS protection.
> 
> 
> Also choose your provider carefully, ensure you have a good relationship with them as botnet operators will try and use you. Ensure you have measures in place for this, and an agreement with your provider for handling this.


Is this still an issue?

Even for a private network?



HalfEatenPie said:


> In terms of actual setup I hear tons of people use Debian, but that's my understanding.


I read a lot of good opinions about the BSD network stack.

But it looks like a lot of ircd owners do prefer Debian.



365Networks said:


> I don't think mitigation is needed if it's a personal IRC server. Maybe something simple like BuyVM or RamNode's mitigation would always be nice, but not needed IMO.
> 
> 
> My choices go for Unreal, InspIRCd, and Charybdis. It basically comes down to personal choice.
> ...


Yup, you don't need a ddos protected ip if you never got ddosed.


I don't want to wake up someone but I never got any attacks so far (at least in the last 8 years).

How do provider handle such situations?



blergh said:


> 1. I would recommend a dedicated box, you never know if anyone decides to attack your network, and if you are on a shared environment it will suck for all parties.
> 
> 2. Doesn't matter. I used FreeBSD and Debian.
> 
> ...


Thank you for the input.



mojeda said:


> My IRC server is currently using 18MB of RAM for ~100 users.
> 
> It's also running flash daemon, BOPM, and whatever other system processes.
> 
> ...


One key advantage if your provider is supporting private lan.

Thank you for the numbers.


----------



## HalfEatenPie (Sep 22, 2013)

wlanboy said:


> Is [botnet] still an issue?
> 
> Even for a private network?


Honestly, it still can be an issue when not maintained properly (and of course who you bring or maybe they just got really lucky and randomly got onto your server).  It's probably for the best to talk this over with your provider first, better prepare and know what to do than deal with it as it comes up (reaction time is much slower).  If you want your provider to react with the same amount of speed and precision to any error then shouldn't you return the courtesy?  



wlanboy said:


> How do provider handle [DDoS] situations?


Nullroute?  Standard DDoS protection measures really (unless they have the hardware then... well... no problem).


----------



## kaniini (Sep 22, 2013)

mojeda said:


> My network uses InspIRCd + Atheme however we are looking into ShadowIRCd or a fork of it: http://www.irc-wiki.org/ShadowIRCd.


ShadowIRCd is discontinued, but there is a fork of it you could use called Pendulum.


----------



## peterw (Sep 23, 2013)

HalfEatenPie said:


> Honestly, it still can be an issue


Botnets are used to search for them. I would not like to run a irc network if noone is there 24/7 to watch what is happening.


----------



## HalfEatenPie (Sep 23, 2013)

peterw said:


> Botnets are used to search for them. I would not like to run a irc network if noone is there 24/7 to watch what is happening.



While I don't see the reason to keep an eye on it 24/7 (once a day or so?), this does fall under the clause "it still can be an issue when not maintained properly".


----------



## peterw (Sep 23, 2013)

HalfEatenPie said:


> "maintained properly"


How would you "maintained your ircd properly"?


----------



## HalfEatenPie (Sep 23, 2013)

peterw said:


> How would you "maintained your ircd properly"?


I'm going to be clear that I am not an expert at this (because I haven't ran my own IRC network nor have I done much research, so obviously read what I write with a grain of salt), but I will state that from my definition of "maintain the ircd properly" means: make sure the server(s) are online and operational, monitor/observe popular channels to make sure that there's no malicious activity going on (e.g. botnet systems), monitor network/bandwidth to see if there's a sudden spike in network events (but no major noticeable change in users in major/popular channels).  etc.  

This doesn't require 24/7 "eye in the sky", just every once in a while doing an audit would be perfectly fine in my opinion.  If it's a small network (like described above) then I believe that these measures should be more than enough to protect the IRC network.  

Because my explanation is a small network (and a hypothetical scenario) I might sound pretty relaxed about it (and I am).  If there was actual money involved (aka a business) then this would not be the case (basically stating this does not reflect my server administration policies).


----------



## Quexis (Sep 23, 2013)

splitice said:


> Get good DDoS protection. There is a large correlation between people who get easily angered on IRC and people who start DDoS's.


This.

NetChat was founded as a response to the constant attacks on our users. Clients of RamNode were being "sniped" by someone with a rather large botnet. I had my bouncer and personal website taken offline for several days due to these attacks. Resultingly, one of the core aspects of NetChat is that user IPs are hidden by default. From there, we offer group-vHosts to entities (companies, organisations).

From there, we had large-scale DDoS attacks on all our leaf nodes (the hub, main website and webchat are behind CloudFlare) at one point or another. I believe our Latte node, which is hosted by BuyVM, enjoyed at least one 20Gbit attack.

OP, to answer your questions:

1. OpenVZ is absolutely fine for this.

2. NetChat's leaf nodes all run Debian, which works. You're going to be wanting to compile your IRCd from scratch anyway. Don't use them from your package manager.

3. You can run a leaf node comfortably on 128MB. Perhaps 256MB if you're hosting a bunch of things (services, main site, mailserver) off the one node. Bandwidth, I'd be surprised if you hit even 10GB.

4. InspIRCd is my personal choice. I've used Unreal before and it's not too bad, but I prefer InspIRCd's configs.

5. Atheme and Anope are pretty much at the same stage of the game, except for their data store. Atheme uses OpenSEX, and Anope (from memory) uses SQL. Both can alternatively use FlatFile, but that's kind of a bad idea.


----------



## peterw (Sep 23, 2013)

Speck said:


> NetChat was founded as a response to the constant attacks on our users. Clients of RamNode were being "sniped" by someone with a rather large botnet. I had my bouncer and personal website taken offline for several days due to these attacks. Resultingly, one of the core aspects of NetChat is that user IPs are hidden by default. From there, we offer group-vHosts to entities (companies, organisations).
> 
> From there, we had large-scale DDoS attacks on all our leaf nodes (the hub, main website and webchat are behind CloudFlare) at one point or another. I believe our Latte node, which is hosted by BuyVM, enjoyed at least one 20Gbit attack.


Good to see that networks start to hide IPs by default.

I never got ddosed and so my opinion was that ddos stories are urban legend. But reading that someone paid money to rent a botnet to ddos one customer at a time to harm a hoster left me speechless.


----------



## Quexis (Sep 24, 2013)

peterw said:


> Good to see that networks start to hide IPs by default.
> 
> I never got ddosed and so my opinion was that ddos stories are urban legend. But reading that someone paid money to rent a botnet to ddos one customer at a time to harm a hoster left me speechless.


Realistically we didn't have much of a choice, users were being sniped hard enough that we were having to nullroute IPs almost daily. As I said, my own bouncer was taken offline. I left it nullrouted for a week before bringing it back online, only for it to be smacked with a massive UDP flood almost immediately.

Somebody had/has some serious problems with RamNode.


----------



## kaniini (Sep 24, 2013)

Speck said:


> 1. OpenVZ is absolutely fine for this.


So, let me get this straight.

Earlier, you complain of being hit by 20gbit on one node, which would be indicative in the context of administrating an IRC network, of an "advanced persistent threat" (I hate that phrase, but certainly seems to apply here).

Okay.  So, you have some OpenVZ VPS instances... well, now you have two problems because the filesystem is directly alterable from the host node.

This means an attacker can just compromise the host node and then proceed to compromise your IRCd.  Especially, because in OpenVZ, PIDs are remapped inside containers, but are a 32-bit value outside the container.  So, they can just do killall -HUP ircd on the host node and they now have an o:line or whatever after a nice series of edits to some ircd.conf in /vz/private/CTID.

Yeah.  That sounds pretty awesome.

Personally, I wouldn't recommend OpenVZ for this because at least the alternatives are tamper-proof in this regard; it may be possible to snapshot the FS and extract the ircd.conf but you can't send signals to processes inside the VPS, so you would be forced to restart it.  That would cause most anyone with a clue facing this sort of persistent threat to assume their ircd has been compromised...


----------



## peterw (Sep 24, 2013)

kaniini said:


> So, let me get this straight.
> 
> you have two problems


Anything beyond "don' trust your host"?


----------



## kaniini (Sep 24, 2013)

peterw said:


> Anything beyond "don' trust your host"?


A good ballpark rule here is, don't trust anything in the stack you don't control any more than you are forced to.  Using OpenVZ forces you to trust the host environment a lot more than the alternatives.

Of course, either way they could MITM you, as network traffic has to pass through the host environment, but that is presently well-mitigated by having a secure trust root (the network having it's own CA, or using an established CA).


----------



## wlanboy (Sep 24, 2013)

Speck said:


> OP, to answer your questions:
> 
> 1. OpenVZ is absolutely fine for this.
> 
> ...


Thank you for the input.


----------

