How to set up an IRC server

It's probably not worth bothering; IRC servers are complex, require a fair amount of maintenance, and seem to attract trouble (many hosts ban them, and while Linode doesn't, the Atlanta datacenter does).

It's probably easier to just let somebody else do it for you. Mibbit (http://mibbit.com/) is a web-based client intended for this sort of purpose, and they run their own IRC server for people to use with their websites (you can connect to it using a classical IRC program as well). And best of all, Mibbit is all hosted at Linode.

Something I'd like to add, as a seasoned IRC server administrator - If you want to run an actual IRC server, you need to know how IRC itself works, period. That not only means having at least a basic understanding of the protocol, but also knowing what commands there are, what modes and features there are for whatever IRC daemon you choose to run, how to configure it, etc. It's not for those unwilling or unable to dedicate a large chunk of their free time to it from start to finish. This includes taking the time to properly secure your IRC server as well as maintaining that security (updating it constantly, for example).

And, unfortunately, Guspaz makes a VERY good point here - IRC servers do have a tendency to attract unwanted attention, sometimes even at random. I've had botnets text-flood (or join-flood, or just flood in general) some of my servers in the past and for no real reason other than I just happened to be in the crosshairs.

Bottom line - if you're 200% into it, and can put forth the immense amounts of effort and time in setting up, configuring, securing, and maintaining an IRC server, then go for it. Otherwise, not recommended, just set something up over Mibbit's service.

Ok, it's probably not worth it.

It's not worth it, but as I said, there are alternatives like Mibbit (which still uses IRC) that can work for you.

I don't hate IRC or anything. I've used it for many years, administered channels on various networks, written (from scratch, raw network sockets here) multiple IRC clients, bots, and even a server once (needed something interesting for a school project). It's just that the DIY approach doesn't seem to fit your needs.

Mibbit allows you to use a web interface? This would be very useful, especially for users who are not familiar with IRC. How flexible is it? I don't know if this is possible with IRC, but can you use your domain name with it?

ngircd is a very simple IRC server that is simple to setup and admin.

http://ngircd.barton.de/

@bgneal:

ngircd is a very simple IRC server that is simple to setup and admin.

http://ngircd.barton.de/

So this is IRC server software for setting up your own IRC server? If it's simple to install and use, I could use it. Thanks.

Yes. I use it for an IRC server for a small community website. It's perfect for us. It's easy to configure and setup.

@Inquisitor Sasha:

Mibbit allows you to use a web interface? This would be very useful, especially for users who are not familiar with IRC. How flexible is it? I don't know if this is possible with IRC, but can you use your domain name with it?

Mibbit is sort of two things; an IRC network, and an IRC client.

The network is just a regular network, although it's intended for use with Mibbit (the client).

Mibbit (the client) has two modes. Regular mode, and widget mode. In regular mode, you can use it as a full blown IRC client. It can do most of the stuff most people care about in an IRC client, with the possible exception of XDCC transfers. In this mode, the end-user goes to mibbit.com and logs in with their account, which stores all their settings (what networks/channels to connect to, how to auth/ident/login/etc., themes, settings, etc)

Widget mode is designed to be embedded in your website. You configure it, theme it to fit your website's design, and stick it on your site (it's in an iframe, I think?). You set it to auto-connect to whatever server/channel you want (doesn't have to be the Mibbit IRC server), and all users have to enter is a username (it defaults to some auto-generated guest name).

Mibbit is probably the best web-based (fully server-side) IRC client available; it's certainly much better than CGI:IRC or qwebirc, and I'm not aware of any other true web-based IRC clients than those. There may be some java-based clients out there that technical run in a web browser, but they're connecting to IRC networks from the user's machine, which doesn't work if the user is behind a firewall or proxy; Mibbit (and CGI:IRC and qwebirc) run entirely on the webserver, and the user interface is entirely HTML/JavaScript/AJAX/etc.

Why not use Jabber? It's not IRC, but there are quite a few free servers out there (ones that others are running) that you and whomever you're chatting with can register on (including Gmail/Gtalk, and quite a few free jabber clients. It also supports Multi-User Chat (the Jabber equivalent of "Chat Rooms" or IRC channels), though you need a Jabber client that supports it.

The nice thing is, most of the IRC networks are inter-connected, so you and whomever you wish to chat with can talk to each other regardless of which chat client or Jabber network you're registered on.

Multi-user jabber isn't really as robust or mature as IRC, though, and I'm not sure that many (or any) of the web-based widget Jabber clients support multi-user chat.

I wasn't aware there were any web-based clients for Jabber. Personally I wouldn't use one that I personally didn't manage (technological paranoia).

It's true multi-user chat in Jabber isn't very robust compared to IRC, but it is sufficient for most uses and doesn't attract as many attacks. And just like IRC channels, MUC rooms support passwords.

Running your own jabber server and requiring users to install jabber clients is a heck of a lot more effort on both the server and the client than just slapping a Mibbit widget on a website…

@Guspaz:

Running your own jabber server and requiring users to install jabber clients is a heck of a lot more effort on both the server and the client than just slapping a Mibbit widget on a website…

Read my post:
@Piki:

Why not use Jabber? It's not IRC, but there are quite a few free servers out there (ones that others are running) that you and whomever you're chatting with can register on (including Gmail/Gtalk, and quite a few free jabber clients. It also supports Multi-User Chat (the Jabber equivalent of "Chat Rooms" or IRC channels), though you need a Jabber client that supports it.

Sure, users need to have their own clients, but I don't see the big issue with that – most clients are easy to setup, and would allow people to chat with their Gmail friends (Gmail is still popular, right?). Better still, multi-protocol clients exist for those of us using non-Jabber protocols, e.g. Pidgin (though it would be better to just use Jabber since there's full client-side support on all operating systems through easy to use clients).

Google Talk is moving away from XMPP in the near future, towards the proprietary Google Hangouts feature from Google+. As of right now, I can still connect to it with bitlbee, and can talk to non-Google XMPP users with it, but I wouldn't recommend building anything new around Google services. (For the same reason, I wouldn't recommend building anything around Twitter or Facebook, either.)

The vast majority of people out there don't have Jabber clients installed, and asking the users of a website to install software on their computer to use your website should hopefully raise a big red flag to the typical user. It depends on the target audience of the website. Is it techies? Then such a thing might be feasible. Is it your average person? Requiring software installations is a bad idea.

@Guspaz:

The vast majority of people out there don't have Jabber clients installed, and asking the users of a website to install software on their computer to use your website should hopefully raise a big red flag to the typical user. It depends on the target audience of the website. Is it techies? Then such a thing might be feasible. Is it your average person? Requiring software installations is a bad idea.

I think I might just use a Mibbit IRC web based iframe in a webpage like irc.sturmkrieg.com. Or the simple IRC that was recommended. I like the idea of a web based client though.

@bgneal:

ngircd is a very simple IRC server that is simple to setup and admin.

http://ngircd.barton.de/

Could you please quickly go through some of the important setup for it? Just stuff like the directory to extract it in, port it uses, unblocking the port in the firewall, that sort of thing.

I found this guide, which looks useful.

http://www.techrepublic.com/article/run … th-ngircd/">http://www.techrepublic.com/article/run-an-irc-server-with-ngircd/

@Inquisitor Sasha:

@bgneal:

ngircd is a very simple IRC server that is simple to setup and admin.

http://ngircd.barton.de/

Could you please quickly go through some of the important setup for it? Just stuff like the directory to extract it in, port it uses, unblocking the port in the firewall, that sort of thing.

I found this guide, which looks useful.

http://www.techrepublic.com/article/run … th-ngircd/">http://www.techrepublic.com/article/run-an-irc-server-with-ngircd/

You don't need to "extract" anything, your distro's package manager (e.g. apt-get, yum, …) should do that when you go to install it.

It uses 6667 by default (very common for IRC), but that can be changed in the configuration file. You should definitely go through that file before starting ngircd. It contains a lot of comments explaining each option, so it should be easy for most people to figure out. It should be either /etc/ngircd.conf or /etc/ngircd/ngircd.conf.

@Piki:

@Inquisitor Sasha:

@bgneal:

ngircd is a very simple IRC server that is simple to setup and admin.

http://ngircd.barton.de/

Could you please quickly go through some of the important setup for it? Just stuff like the directory to extract it in, port it uses, unblocking the port in the firewall, that sort of thing.

I found this guide, which looks useful.

http://www.techrepublic.com/article/run … th-ngircd/">http://www.techrepublic.com/article/run-an-irc-server-with-ngircd/

You don't need to "extract" anything, your distro's package manager (e.g. apt-get, yum, …) should do that when you go to install it.

It uses 6667 by default (very common for IRC), but that can be changed in the configuration file. You should definitely go through that file before starting ngircd. It contains a lot of comments explaining each option, so it should be easy for most people to figure out. It should be either /etc/ngircd.conf or /etc/ngircd/ngircd.conf.

Thanks. I used apt-get. Do you know what I should add to open the port on the firewall? I used this guide for making it: https://library.linode.com/securing-you … a-firewall">https://library.linode.com/securing-your-server#sph_creating-a-firewall I could probably figure it out but I don't want to do it wrong.

iptables is fairly easy to use once you know the basic syntax:

iptables -A INPUT -p tcp --dport 6667 -j ACCEPT

* -A should specify INPUT or OUTPUT (FORWARD is mostly for routers).

• -p should be (usually) tcp or udp. If I remember right, IRC uses tcp.

• –dport stands for "destination port", in this case the destination of the traffic of people connecting to your server.

• -j should be followed by either ACCEPT or DROP.

The part to keep track of is whether you should use –dport or --sport (source port), e.g. using the above example to allow port 80: you'd use --dport to allow people to access your web site, while you'd use --sport to allow yourself to access outside web sites.

Another useful thing to add, right before "-j ACCEPT":

* -m state –state ESTABLISHED,RELATED

This is usually most useful only for specifying INPUT without any ports/protocols – something that guide already does. (though if you wish to be ultra-paranoid like me, you can set it to drop everything on OUTPUT, set the ESTABLISHED,RELATED rule for OUTPUT, then set individual rules in both directions)

After you make your changes, verify they've taken effect, then save them:

iptables -L
iptables-save > /etc/iptables.firewall.rules

Note: iptables requires that you either log in as root, or that you use sudo.

@Piki:

iptables is fairly easy to use once you know the basic syntax:

iptables -A INPUT -p tcp --dport 6667 -j ACCEPT

* -A should specify INPUT or OUTPUT (FORWARD is mostly for routers).

• -p should be (usually) tcp or udp. If I remember right, IRC uses tcp.

• –dport stands for "destination port", in this case the destination of the traffic of people connecting to your server.

• -j should be followed by either ACCEPT or DROP.

The part to keep track of is whether you should use –dport or --sport (source port), e.g. using the above example to allow port 80: you'd use --dport to allow people to access your web site, while you'd use --sport to allow yourself to access outside web sites.

Another useful thing to add, right before "-j ACCEPT":

* -m state –state ESTABLISHED,RELATED

This is usually most useful only for specifying INPUT without any ports/protocols – something that guide already does. (though if you wish to be ultra-paranoid like me, you can set it to drop everything on OUTPUT, set the ESTABLISHED,RELATED rule for OUTPUT, then set individual rules in both directions)

After you make your changes, verify they've taken effect, then save them:

iptables -L
iptables-save > /etc/iptables.firewall.rules

Note: iptables requires that you either log in as root, or that you use sudo.

Thanks. So would the code with the additional element be?

iptables -A INPUT -p tcp --dport 6667 -m state --state ESTABLISHED,RELATED -j ACCEPT

@Inquisitor Sasha:

Thanks. So would the code with the additional element be?

iptables -A INPUT -p tcp --dport 6667 -m state --state ESTABLISHED,RELATED -j ACCEPT

Using connection states isn't absolutely necessary if you're just aiming to allow access to a specific port on your server, the rule will work with or without it, so you can omit '-m state –state ESTABLISHED,RELATED' if you wish or move it to its own rule in the chain. Up to you.

@Inquisitor Sasha:

Thanks. So would the code with the additional element be?

iptables -A INPUT -p tcp --dport 6667 -m state --state ESTABLISHED,RELATED -j ACCEPT

That effectively blocks any connection which isn't already established when you set that rule, meaning new connections can't come in. The "-m state –state ESTABLISHED,RELATED" bit should be use with --sport for INPUT, or --dport for OUTPUT, otherwise the connection better already be established and maintained.

Alternatively, you could keep the stat and use NEW,ESTABLISHED,RELATED , however it's easier just to exclude them.

You could also just avoid running a firewall. If you're running a website and an IRC server, there really isn't a reason for a firewall.

-Tim

@theckman:

You could also just avoid running a firewall. If you're running a website and an IRC server, there really isn't a reason for a firewall.

I can think of many reasons to run one: SQL server intended to run on localhost only, VPN or otherwise networking with insecure hosts, DDoS mitigation, limit access to trusted IP addresses, reduce log spam, lock yourself out of your own server, …………..

@Piki:

@theckman:

You could also just avoid running a firewall. If you're running a website and an IRC server, there really isn't a reason for a firewall.

I can think of many reasons to run one: SQL server intended to run on localhost only, VPN or otherwise networking with insecure hosts, DDoS mitigation, limit access to trusted IP addresses, reduce log spam, lock yourself out of your own server, …………..

If you standardize your configuration methods and be sure to triple check, you should avoid having a SQL server listening on the wrong port. Even so, it's trivial to write a small script to make sure you only have important services listening on the public network.

DDoS mitigation? If someone is attacking your system and causing congestion upstream, your software firewall isn't going to do anything.

And yes, firewalls can be used to limit access to trusted IP address. But simply blocking all ports (except the ones you have services on) isn't really beneficial to security. Those services that are listening are still listening…

@theckman:

If you standardize your configuration methods and be sure to triple check, you should avoid having a SQL server listening on the wrong port. Even so, it's trivial to write a small script to make sure you only have important services listening on the public network.

Sure, but what about keeping it blocked from the public? Sure, there's good chance the SQL server will allow this, but no garuntee…

@theckman:

DDoS mitigation? If someone is attacking your system and causing congestion upstream, your software firewall isn't going to do anything.

Depends on where the congestion occurs. On the routers at Linode's datacenters? Nothing I can do about that. At my specific Linode? Firewall can help (though I realize it's not a sure thing).

@theckman:

And yes, firewalls can be used to limit access to trusted IP address. But simply blocking all ports (except the ones you have services on) isn't really beneficial to security. Those services that are listening are still listening…

It's more an issue of blocking ports for service daemons that don't let you listen only on localhost. Sure, it's better to not run any such service daemons, however in the (extremely) unlikely case I'd require such a service, I'd rather just be prepared.

There may also be instances where people want to allow stuff only on their internal network (e.g. to utilize XMPP internally for a business), however it's unlikely a Linode will be used for that.

Also, IIRC from my networking class, servers will respond to open ports with no services to say "no service here". While sending such a response would se a miniscule amount of bandwidth, it could add up quickly on a busy site.

@Piki:

While sending such a response would se a miniscule amount of bandwidth, it could add up quickly on a busy site.

A TCP RST packet is 20 bytes, 40 bytes with the IP header. The smallest Linode server includes 2000GB of transfer. To consume even 1% of the cheapest Linode server's monthly transfer, you would have to respond to 537 million connection attempts, or an average of roughly 200 per second.

In other words, no, it could not add up quickly.

@Guspaz:

@Piki:

While sending such a response would se a miniscule amount of bandwidth, it could add up quickly on a busy site.

A TCP RST packet is 20 bytes, 40 bytes with the IP header. The smallest Linode server includes 2000GB of transfer. To consume even 1% of the cheapest Linode server's monthly transfer, you would have to respond to 537 million connection attempts, or an average of roughly 200 per second.

In other words, no, it could not add up quickly.

Yes, it could. I'll not fool myself into thinking I can gain enough fame in just a few months to hit that many connections, however I'd honestly be surprised if big-time sites like Google and Yahoo did not get more than that.

Sure, web traffic costs much more bandwidth than an attempted connection to an empty port, however if a server gets hammered hard enough, it could add up to at least a few MB a week. Not a worry for most people.

Also, it could have an effect on latency, however small, depending on the number of connections and server config.

Seems probable that Linode would be on your case before they became a bandwidth issue. 537 million connection attempts… Linode will notice something like that.

@tubaguy50035:

Seems probable that Linode would be on your case before they became a bandwidth issue. 537 million connection attempts… Linode will notice something like that.

If anything, they'd probably think it was a DoS attack and shut down my Linode for awhile. But my over-strict block-all policy can help if that ever becomes an issue :wink:

I think I'll keep it up, just having a firewall seems important. Plus I read that you need it with memcached, but I don't think that's something I'll need, even for a long time.

I still have problems connecting. I added the line, but I can't connect. I'm using Jabbretro, which was a free client I found in the the Apple Store. I set the domain in the configuration file to irc.sturmkrieg.com and I set an A record to that domain and the IP address of the server. Is it just a bad client or something?

EDIT

I also tried Limechat, which seems better and it's still not working.

EDIT

What IP address should it be listening on?

EDIT

I think I might have had a problem with updating the firewall after I saved the file. Is there anything I need to do after saving the file?

EDIT

iptables -L gives this:

ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:ircd state RELATED,ESTABLISHED

I used this:

# Allow IRC
-A INPUT -p tcp --dport 6667 -m state --state ESTABLISHED,RELATED -j ACCEPT

@Inquisitor Sasha:

I think I'll keep it up, just having a firewall seems important. Plus I read that you need it with memcached, but I don't think that's something I'll need, even for a long time.

I still have problems connecting. I added the line, but I can't connect. I'm using Jabbretro, which was a free client I found in the the Apple Store. I set the domain in the configuration file to irc.sturmkrieg.com and I set an A record to that domain and the IP address of the server. Is it just a bad client or something?

EDIT

I also tried Limechat, which seems better and it's still not working.

EDIT

What IP address should it be listening on?

EDIT

I think I might have had a problem with updating the firewall after I saved the file. Is there anything I need to do after saving the file?

EDIT

iptables -L gives this:

ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:ircd state RELATED,ESTABLISHED

I used this:

# Allow IRC
-A INPUT -p tcp --dport 6667 -m state --state ESTABLISHED,RELATED -j ACCEPT

A few posts back, I said:

@Piki:

That effectively blocks any connection which isn't already established when you set that rule, meaning new connections can't come in. The "-m state –state ESTABLISHED,RELATED" bit should be use with --sport for INPUT, or --dport for OUTPUT, otherwise the connection better already be established and maintained.

Alternatively, you could keep the stat and use NEW,ESTABLISHED,RELATED , however it's easier just to exclude them.

Wow. Sorry I missed that. Thanks for that! It's working.

I'm getting too old. I was recently wondering why an image gallery I imported from GoDaddy wasn't working, and it turned out I hadn't imported the database.

EDIT

Do you know what command to use to restart it after I edit the configuration file?

EDIT

I figured it out.