PDA

View Full Version : A quick conceptual overview


Dietrich
May 1st, 2007, 04:32 AM
After speaking to Alex earlier, I think it is within reach to come up with a set of solutions that would allow him to repair a problem like the one we had last week within about three hours, maximum.

As I see it, there needs to be three main solutions:

A solution to the problem of DNS
Pointing the ".com" where we need it, as smoothly and rapidly as possible

A robust solution to the problem of data
such as auto-scheduled backups that encrypt and store the backup in three redundant locations. Also includes having storage hosts lined up, such as my webspace that can be used temporarily, or OTPTT, who is likewise open to the idea. Others can throw their hat in the ring here if they have some webspace, mysql, and a little extra bandwidth for a week or so maximum should all hell break loose with two or three of us simultaneously.

A solution to the problem of restoration
This will mostly come from Alex, and he wants to learn more than he already knows on this. One way he could be helped is that we can make ourselves available. I've made this offer already and gave him my phone #. I'm going to step him through a few basic things next time we speak.

I've met tons of guys who are gurus in all sorts of areas over the years, and that is one valuable resource. I think we all can and should at least throw our hats into the ring and say "I can do this, this, and this." Perhaps the best way is to email me at theseusship@gmail.com and give me a general idea of your area of expertise and I can pass that along when it's necessary? I would say to put it here, but we're dealing with times when the board may be unavailable. So, if you're a photoshop, a php or a vBulletin whale (and I know you're out there), and you would be up for helping Alex out of a very occasional bind, make yourself known. Competent and solid Whites only, please.

There is no money, and little glory offered except that in helping maintain, embolden, and improve the last bastion of unafraid and unashamed free speech on planet Earth.

Subrosa
May 1st, 2007, 09:04 PM
Actually, this forum should be closed from kike eyes so they don't know what's being planned. Invite only.

Dietrich
May 1st, 2007, 09:17 PM
Actually, this forum should be closed from kike eyes so they don't know what's being planned. Invite only.

I agree but can't make it so.

Subrosa
May 1st, 2007, 09:20 PM
1. DNS
Use DynamicDNS name servers with a short TTL. This will allow any disruption to be repointed in quick fashion.

2. Data Storage.
The idea of distributed storage is important. I like your suggestions Detrich, The internet was designed to be fault tolerant, we should make use of this.

For the cheapest route, an Active/Passive design would work best. This would have one hot site with others standing by. The passive sites would simply be sitting there in the background waiting for the call. Very cheap we would only be paying for disk storage.
When the hot site gets pulled (and it will) one of the passive sites is fired up by simply changing the index page and repointing the DyDNS name servers. This would result in a disruption of 1 hour max.

A more expensive design is to have all sites hot and if one goes down, the others kick in in a "round robin" fashion. We should work toward this solution as the prefered one.

In all cases a mirrored solution or cron job should be run to replicate data DAILY to all the sights. Part of the responsibilities of a tech team would be to ensure this is happening.

We also need to raise money on a monthly basis to purchase services and equipment. To this end I have A Dell 2650 I can plant into a datacenter and can contribute $50 a month to start off. I can contribute more but I want to see how many people pledge.

We have to look at this as Disaster Recovery and plan for the worst possible scenerio.

Subrosa
May 1st, 2007, 09:21 PM
I agree but can't make it so.

We might as well copy the kikes and chans on our plans then.

Dietrich
May 1st, 2007, 11:42 PM
We might as well copy the kikes and chans on our plans then.

lol.

I can mirror w/ my site. I have an insane amount of bandwidth for $2.50/month.

Bolg
May 8th, 2007, 07:00 AM
Guys, you may have thought of that already, but dnsalias.net (http://dnsalias.net) has a similar service. You can simply register something like vnn.ath.cx, and point govnn.com to it.
(http://dnsalias.net)
When the kikes kick you off your server, you simply point vnn.ath.cx to a mirror (which we should be maintaining anyways).

dnsalias.net (http://dnsalias.net) has DNS servers in 5 different timezones, so a change takes place almost instantaneously. And it is free, so...

But we should be mirroring the site and the forum.

Bolg
May 8th, 2007, 07:23 AM
This may not be the place for ddos discussions, but anyway:

http://www.digitalgenesis.com/software/phrel/

PHREL is a Per Host RatE Limiter written in C to efficiently track the rate of incoming traffic on a per host basis and insert a chain into iptables when a configured threshold is crossed. The inserted chain may either rate limit or completely block the offending host for a period of time and will be automatically removed when the offending host's traffic levels return to normal. PHREL can be used with any type of traffic, but it is particularly well suited to protecting name servers from random hosts that flood DNS requests and preventing SSH brute force login attempts.Protecting a public nameserver (DNS) This example uses phreld to listen on port 53 (DNS) for hosts that exceed the threshold of 100 PPS and 200 PPS. The hosts that exceed 100 PPS are rate limited down to 25 PPS. The hosts that exceed 200 PPS are blocked (rate of 0). The blocked or rate limited host will need to stay below the exceeded threshold for 900 seconds (decay) to removed.

# /usr/local/bin/phreld -p 53 -T 100:25 -T 200:0 -D 900

Preventing SSH, Telnet and FTP brute force login attempts This example uses phreld to listen on TCP port 22 (SSH) for hosts that attempt to connect to SSH more than 5 times in 30 secs (interval). Hosts the exceed this threshold will be blocked for 1800 seconds (decay) before being allowed to connect to the server again.


# /usr/local/bin/phreld -A sum -i 30 -D 1800 -T 5:0 'port 22 and tcp[13] & tcp-syn != 0'

Elegant.

Denying access to the general public is one of the not-so-many pleasures an IT guy has left, right?

Johann_M
August 27th, 2007, 11:37 AM
Hello.

My first post.

Great forum!


Sorry. Wrong thread.