MUXing and Portability

olene · Posted: May 17, 2005 11:12am Post subject: MUXing and Portability

Ok.. I'm gonna fit two topics into one thread here because its seems the forum gods don't seem to like my threads very much.

In any case... I've thought about the actions of an old network called TalkCity that created several dozen proxies to keep the server's addresses secret in an attempt to minimize attacks, and current day AIM servers that use the same scenario, in a much more integrated fashion, and i've drawn http://www.olene.net/rofl/prm.txt up. Tell me what you think. I've had no problem implementing it. There are some areas that need work (the RE mechanism), but uh.. yeah.

The other thing is that I just wanted to let you people who were watching rofl ircd know that last night, thanks to Evil_smurf, i acquired a linux shell. Since I havn't tested rofl ircd on linux since just after i finished the core about a month ago.. I'd figure i'd try to run it on mono, all 13 modules. And.. to my surprise.. it ran. Without a single error.
The only problems i encountered were two unhandled exceptions when i /DIE'ed the server.. and it turns out .. both of those exceptions came from within Mono's classes.. so.. "salad as a rock?".

You can view proof of my no-nonsense-portability here http://www.olene.net/rofl

Roku · Newbie Joined: 18 Apr 2005 Posts: 92

Jamie · none Joined: 06 May 2005 Posts: 36

I believe even the daftest attacker has discovered a little thing called "resolving a host."

(Basically, what's the point of only adding IP addresses into a pool when everyone can simply `host` or /DNS that pool (acquiring each IP address), and then connect to each server/DDoS it/whatever, "bypassing" the pool?)

This sounds like a really neat idea, Olene.

- Jamie O.

Roku · Newbie Joined: 18 Apr 2005 Posts: 92

Jamie · none Joined: 06 May 2005 Posts: 36

The attacker would resolve the pool, and have a list of IP addresses. S/he would then connect to each IP address and note what server is listening on what IP address. That's not extremely complicated.

Proxy servers allow for even more bandwidth configuration. It'd be interesting if "registered" users had to either identify to their nickname (DFV-style) or register at the proxy level.

By the way, DALnet introduced a single point of failure quite a while ago, known as the "IX concept."

It also annoys me that nearly every post gets back to the mentality of "BUT NO TEH DALNET DOESNOT DO IT THAT WAY!!1 IT MUST BE WRONG!!"

Simply because DALnet is one of the largest IRC networks, it doesn't mean it's the "best."

- Jamie O.

Roku · Newbie Joined: 18 Apr 2005 Posts: 92

Jamie · none Joined: 06 May 2005 Posts: 36

Yes, I realise how networks "work."

If you had to code an IRCd from scratch, how would you implement such a system? What language would you code it in?

- Jamie O.

Roku · Newbie Joined: 18 Apr 2005 Posts: 92

To be honest, attempting to protect an IRCd and it's resources is a noble effort. However, IMO, simply putting up proxies is not the answer. You don't rid warts by cutting the top off, you must remove the roots.

To answer your question, I'm not a coder so I can't directly answer it. However, I've worked for ISP's for several years in the past and I've been an MCSE for about 10 years now. So I am somewhat familiar with how DDoS's work and know that IRC is not the only targets to them. Admitedly though I have been "out of the loop" for sometime and I'm not "hip" to current technologies.

As far as networks goes. There is nothing better, IMO, than to learn from successful examples. 99.9999% of the networks in existance have not done what DALnet and Undernet have done. They have endured more than a decade while hosting hundreds of thousands of users. We should learn from this not get defensive because alot of others envy their success.

As side note and rather off topic. I do apologize if I seemed "snappy" a few moments ago. So many threads here are wasted to flamers. I didn't want this to be yet another. If you wish to comment please do so privately. I'd be happy to talk to you off topic. This apology IMO is best done publicly or I would have taken it private as well.

Back to the topic.

Jason · Posted: May 17, 2005 4:15pm Post subject:

olene · Posted: May 17, 2005 8:04pm Post subject:

Roku, you're obviously missing the point of this. Say your network has 5 servers. Each server might have say, 5 proxies. Thats 25 proxies. Now there are several ways you could set this up:

1. Simply have your dns roundrobin the proxies. This would cause an attack to have to bring down all 25 hosts (and even still, the ircd wouldn't lag a second) to cut off all access to your network.

2. Use a load balancer, or balance the dns based on origin location. If the attacker is hosting a botnet in a single or a few IP blocks, and that particular region only resolves to say "US" proxies, thats all that they are gonna get the IP for unless they have IPs in all the places your dns is configured to localize.

3. Simply implement some auto-readdressing system that if a proxy goes down, you change it's address and bring it back up, or bring up a backup proxy at another point in the network. Unless the attacker is constantly running DNS queries (which is normally only done once at the beginning of the attack to get the target ips), they aren't going to be targetting all of the network.

4. Proxies (multiplecies) can be setup in a manner to each other as if one proxy is being attacked, it can NOTICE the other proxies to firewall the involved ip's at the node level, router level, or even at the gateway level.

The whole point(s) of multiplexers are:
1. To be able to dynamically change where and how users connect to the network without moving, disrupting, or reconfiguring the server.
2. To take some socket load (including dns resolves, ident lookups, and tcp/ip overhead) off the server.
3. To move the networks' public interface away from where the work gets done. With multiplexers, even if 9 out of 10 of your gateways are being packetted mercilessly, the users that are still on aren't going to be lagged a single second.
4. To keep the address of the box that is responsible for keeping the state information secret. This eliminates the "attacking to desync" or "attacking to abuse split" problem.

Roku · Newbie Joined: 18 Apr 2005 Posts: 92

Or maybe I know that the physical interface has limits, saturate it and your ircd will become unreachable ... and I know that bandwidth is allocated in most cases, in which it can be saturated regardless where the packets go. Bandwidth consumption is still bandwidth consumption, the ircd still has to receive a PONG from clients and even a 1 gigabit LAN can be saturated easily.

olene · Posted: May 17, 2005 9:51pm Post subject:

You can't saturate the entire network unless you know the IP of every proxy. And you can't get the IP for every proxy unless the DNS server gives it to you. And the DNS server wont give it to you if it's programmed to only give you the closest server to your connection. So unless you have floodbots in every region or otherwise logical delimination of the network, you can't saturate the entire network.

It doesn't matter that it's not "foolproof". It's not meant to eliminate DDos. It was originally intended to take socket load off of the server, provide an off-premises portal to IRC, and allow the actual server box address to remain secret. It just happens that, if you implement it correctly, it can lower your affectedness of attacks. Obviously at least it's providing some stress relief rather than having your server's TCP/IP stack given out to anyone in the world who wants to resolve your hostname, even if they aren't a member of your network.

magpie · Idler Joined: 18 Jan 2004 Posts: 454 Location: Essex, UK

Is socket load really that big an issue?

Dr-Voodo · Eleet Joined: 07 Nov 2003 Posts: 535 Location: IRC

Seems like it

nenolod · Idler Joined: 23 Jan 2004 Posts: 333 Location: A box!