Slashdot Mirror
IRC in the Dog House?
Emperor Tiberius asks: "It seems more and more dedicated server companies are turning tail to the idea of hosting IRC machines. Hosts like Rackshack are adding 'no-IRC' rules to their AUPs at the risk of having one's server unplugged. Why is IRC (the once applauded chat medium) being thrown to the dogs? Some might say the horrendous botnets written for the protocol are a part of the problem. However, if we were to shut down the IRC protocol. Isn't it theoretically possible the botnet authors would just migrate to a different protocols like Oscar/AIM, ICQ, ICB, Jabber, just to name a few? If so, how would we manage the problem? Would we shutdown all ICB servers, and cut-off the ICQ network? Are we trying to kill off the problem in the wrong way, or is there a compromise to keep IRC alive, and keep botnets away?"
I remember IRC back when the main system, efnet, only had about 700 users on it. Even then, it was a constant storm of splits, lag, and maneovers and assassinations by swarms of killer 'bots.
Last time I checked in, the bots had gotten more powerful, and things had taken a nasty turn where nicknames were commandeered and others who dared to use them got punished.
You want Skynet? Terminator: Rise of the Machines? Just witness how bot evolution calcified IRC.
It's not because of the botnets directly, but rather beacuse IRC servers tend to attract massive amounts of abuse (DDoS attacks, etc) that can be a huge pain for hosting companies.
IRC also tends to be a very easy way to access all kinds of illegal stuff. As well as bait for DDoS and other annoying attacks.
The various distrobuted denial of service attacts that were aimed at some of the more high profile networks... few providers want to deal with that sort of thing.
Combine that with the public image of IRC being used for illegal file distrobution and "hackers", IRC's in low reguard.
Hosts like Rackshack are adding 'no-IRC' rules to their AUPs at the risk of having one's server unplugged.
The submitter misread Rackshack's AUP (as I did when I was signing up for service through them, on this specific topic incidentally -- so I emailed them for clarification). Many of the items in their AUP apply to their virtual servers only -- where many customers share one physical machine. IRC servers aren't permitted on those machines because of the load they put on the machine.
If you've got your own Rackshack server, you can run IRC on it all you want.
NO CARRIER
I don't think that hosting companies necessarily care about the IRC protocol itself, but more with the problems that come along with hosting a service known for attracting the worst kind of attention while sucking up tremendous amounts of bandwidth.
The
technical requirements for running an Undernet.org server explain it pretty clearly. 5 Mbps of legit traffic, plus becoming a target for massive DDOS attacks? Why would a hosting company want that kind of service in their netblock?
Yea, sure, other IRC networks aren't nearly as high-profile, but this is the reputation that IRC has gotten, along with being a haven for copyright violation.
If you want to run an IRC server, then get your own dedicated net connection from a backbone provider and you can host whatever (legal) service you want.
The amount of warez traded on IRC is immense and exceeds ftp warez traffic by a significant margin. The kiddies can do their Google search for warez, but the real underground is in IRC.
Hosting an IRC server in this day and age is like running an illegal music swapping site in the open. At some point the powers that be (the RIAA or the BSA, for example) will act, so why tempt them in the first place?
I'm an oper on a major irc network, so I'm aware of a lot of what goes into running a server. The problem is that when a kiddie gets upset (at other users, a channel or some perceived slight by an oper/the network), they DDoS the server. This uses bandwidth, and bandwidth is money. IRC servers use a good chunk of bandwidth just for regular user behavior, and this blows that away. The bandwidth providers aren't getting much out of this other than a little brand recognition (if that much), so their charity isn't limitless. Hosting providers restrict IRC for this reason, too. They don't want to up the risk of being attacked. Running an IRC server is, unfortunately, a high risk activity these days.
Just to debunk a few things here before people get started...
1) Some trojans already use non-IRC protocol. Some trojans already use more than one protocol.
2) Almost all of the larger networks run some type of anti-drone and anti-proxy system to prevent the problem from getting out of control. Said programs are widely available in a variety of forms for most IRC daemons.
Newer worms target smaller networks because of this, since smaller networks generally don't run said software (besides the usual nickname/channel services). Many worms also use private IRC networks, since the botnets can't be tracked and/or shut down as easily on them.
3) Most IRC servers are not hosted by people who lease servers at small hosting companies. A majority of servers linked to larger networks are either hosted by ISPs or by large entities with large amounts of bandwidth to burn.
Smaller hosting providers purposely shun IRC servers because they know that they can be a bandwidth burden (not to mention a DDoS target). Larger hosts, which monitor their bandwidth 24/7, usually don't object to hosting servers - all they have to do is blackhole the server's IP when a DDoS attack comes their way and the disruption is minimalized.
EFnet may have lost some high-profile servers lately, but the majority of IRC networks are doing well server-wise. QuakeNet (the world's largest IRC network) is in the process of starting a campaign to link more North American servers... and not because the network needs more servers (they could easily handle 300000 users in their current state), but because they want to draw in more North American users.
At $350 a month, httpd.net is home for a huge number of IRC servers. With an incredibly advanced and secured network that has been running continuously for over SEVEN YEARS, it has the experience that proves that IRC hosting can be done effectively.
It's not cheap, but quality never is.
In those seven years, it has rarely had any substantial downtime due to attacks, mostly thanks to a serious investment by the administrators to ensure uplink filtering.
Its definitely worth a look when you get serious about a permanent home for an IRC server.
First of all, people tend to IRC from where they are, they don't often need to ssh into a machine and IRC from there (although, I must admit, it's not an unreasonable thing to do because of firewalls etc). The people that want to IRC from a shell box are often the ones that want to "hide", and that opens you up to people attacking your machine (via DDoS, exploits, etc), or they want to run a bot which holds a nick. Then the bot gets DDoS'd to get the nick back (and then held by a bot so someone else can have the nick).
If you're lucky the bot won't be used to host illegal warez using up any bandwidth that is left over from the DDoS, and now you have the RIAA/MPAA knocking on your door too.
People that want to hide from people are often doing it because they are involved in illegal activities such as CC# trading, and/or DDoS networks. So you are getting paid in illegal money (that people will want back), by someone you can't trace.
The people that want to use IRC shell accounts tend to "trade" them on IRC so that they can get even more obscure ones to hide even better (or to have backups in case their main one gets attacked). So now the account is used by 20 people, none of which are accountable for their actions, who are drawing attacks against your services.
In general, letting people IRC from your shell is just asking for trouble. There are plenty of shell providers that capture this niche market with hundreds of "vhosts" so you can choose which "leet" hostname you will appear to come from. They are better set up to weather DDoS, and they are careful about accepting CC#'s.
One of the reasons that IRC has such a bad rep is that it's very "instantanious" to see the affects that your attacks have on people. You can see someone's real IP, and DDoS them and watch them get disconnected. You could pick some random IP off the internet and DDoS that, but it's not nearly as satisfying as watching someone "Ping timeout" off IRC. Other networks like Jabber, ICQ, MSN etc don't give you the IP address of the remote person without their permission, and you have less of a situation where you can see other people. There are less common resources (such as globally nick names) to fight over. The networks aren't as vunerable to attack (DDoS'ing an IRC hub will make the entire network split in two, not just preventing people of that server from talking, but denying half the network from talking to the other half. DDoS'ing a Jabber server prevents users on just that server from talking).
I personally think that the IRC protocol should die a natural death (and, in fact, should have died it about 10 years ago when it was obvious it wasn't going to work) and should be replaced with something like Jabber.
Folks who want to foster quality chatting on their IRC servers might think about coming up with a way to charge some tiny amount for each message sent. Running even a single bot for any length of time would become an expense, but actually chatting would still be cheap. And the very idea that each message has a cost associated with it might improve the quality of discourse.
IRC really is the best thing going for real-time, group-based discussion. Unfortunately, it's also missing a large number of pretty useful features.
/list is one. If I were designing an IRC-like protocol, /list would be done on a separate TCP connection to avoid tying up the first and avoid having to implement multiplexing over a single connection (a la HTTP pipelining).
The current state of
The lack of security design is another. Using nicks as identifiers just isn't a fantastic idea -- in this day and age, a public key can reasonably be part of an identifier. Encryption should be simply part of the protocol, at least client-to-client, and ideally to the server as well. There isn't *that* much traffic from each client (though it'd certainly put more load on the server, and might require a more fanned-out-network.
Fserves are an affront to humanity. Granted, this isn't really a native IRC issue, but client support for easy linking to sftp servers would be a good idea.
A fair bit of IRC is a holdover from the days when everything was terminal-based. There's no reason you can't make good text-based clients that provide the same presentation (say, showing chanop prefixed with an "@", but the data being transferred to the client shouldn't be constrained by these formatting issues.
It would be nice to have some kind of anonyminity features, even if most people don't use them and doing so degrades performance. Say, the ability to form "rings" of clients that proxy each others' server-bound data.
Some sort of native support in IRC for mapping IRC networks would be nice.
May we never see th
IRC has become the pit for reasons of DOS and generally 13 year olds being dumbasses. I personally blame people releasing scripts that allow 13 year olds to become dumbasses. I hang out on a smaller IRC server and lately due to increased popularity, the owner has considered kill -9 the IRCD server because of stupid idiots. IRC is from the same age as SMTP. Both were protocols designed for a nicer internet. Both are being abused to no end and require a rewrite.
Botnets? Botnets? We don't need no stinking botnets!
--
Ok... Security 101 class - what does a public key give you on IRC that a nick doesn't ???
Absolutely nothing without a trust relationship beyond knowing that the same key is used to log in (and probably attaching nick usage to a private key somehow usefully). Oh and at 1.5kbit (or ~190 bytes without parity checking) private keys are a little large to throw around on a per message bassis.
Quiz II - What are you protecting from when you encrypt between you and the server (lets assume you also ment authenticate as well - since encryption without authentication is worthless)
Well I would say nothing, because your message will be decrypted - and re-encrypted to anyone that was listening to you where they can post it anywhere they want (to a log file maybe ?) - also the irc server has the message in the clear, so you have to trust it as well... not a pretty site.
I won't argue too hard with the rest though
I have mod points and I am not afraid to use them
what does a public key give you on IRC that a nick doesn't ???
Absolutely nothing without a trust relationship beyond knowing that the same key is used to log in
That alone would be useful: If someone needs to prove that they hold a private key in order to sign on with a gievn name, you dramatically reduce the risk of DDoS wars caused by people fighting over a name.
Tarsnap: Online backups for the truly paranoid
The effects of an attack are instantanious, but only if you are insecure to them. Back when WinNuke was the latest things my brother challanged someone to knock him off. Strange that a Mac protected by a linux firewall (which was very out of date, and insecure) isn't vulnerable to winNuke. (and that was just a 28.8 modem, should have been easy to do if an attacker had any abilities) Now a days whenever someone brags about what a leet attacker they are, we point them to the guy working at an ISP. Very hard to DoS someone with a OC-48 to his desktop...
In other words protect your systems and you will foil a lot of attacks. Most attackers are too lazy to figgure out how to attack something. That is why they are called "script kiddies" they really are kids who only know who to start a script, and if that fails they are lost.
Speaking of which, is there still a viable place to chat in realtime about Linux? I've tried to get into efnet a few times recently and found nothing but split-off servers with two people in #linux.
Check out the Apostrophe open-source CMS: http://www.apostrophenow.com/
Actually, besides the fact that WorldIRC is prone to having flaky connections, it's a pretty good network. They have some nice services- nickname services and channel services which largely prevent bot idiocy. X, the channel service bot, lets you log in and get operator status, but also supports tiered access, userlist administration, optional "strict ops" policy (only those logged in with the right permissions level can be opped... by anyone) de-op protection, and all sorts of fun stuff like that. You can't take over a WorldIRC channel with bot idiocy, I'll give them that.
If you do end up using WorldIRC, just connect to one of their servers- the randomizing server (irc.worldirc.org) has a tendency to route you over to another IRC network (Infomatrix or something like that).
The World Wide Web is dying. Soon, we shall have only the Internet.
Business as usual, then.
I use irc.chatjunkies.org:6667 - channel #linuxhelp or #linux :)
It seems to be down today... That's not good!
Ligaguinggligagiggagoogoogwillgo
Just as a matter of interest, how does one submit an rfc? I haven't seen an faq on the subject on ietf.org
There's more to IRC than EFnet ;)
Try looking here http://irc.netsplit.de/channels/?num=0&query=linux .
Ok... Security 101 class - what does a public key give you on IRC that a nick doesn't ???
You also sign a timestamped message from the server when you sign in. By checking signatures and comparing the advertised private key, other clients can form trusted mappings between "(bob37, [pubkey])" pair on Wednesday and a "(bob37, [pubkey])" pair today. This means that I know that Bob really is bob.
Private keys wouldn't need to be broadcast on a per message basis. Once a trusted mapping has been formed, the clients know that "bob37" is trusted to be "Mike Smith, CEO of SmithCorp" for the length of this session.
What are you protecting from when you encrypt between you and the server (lets assume you also ment authenticate as well - since encryption without authentication is worthless)
Those on the same network and those at your ISP monitoring everything you say and where you're talking to. When paired with an anonymity system, you and what you say cannot be easily mapped to you, regardless of whether a privacy attacker comes from your ISP or the IRC network. For an untrusted IRC server to be dealt with, addtional direct connections (not passing through the IRC server) would need to be established -- hence the "privacy ring" I mentioned earlier.
May we never see th
>Except that there is no content stored on the servers, and all the swapping is done via DCC (Direct Client Connection) and not through the server.
Caveat Emptor is not a business model.
Unlike napster however, file sharing is NOT part of the IRC RFC Protocol, the server itself does NOT facilitate searching for or downloading files and IRCs primary function is NOT file sharing, it's chatting.