Oleg_ST

Рейтинг
46
Регистрация
11.02.2009
Интересы
swimming
netwind:
Нет с BGP все не так. И даже не так как а книжках 2000 года.

А как? :)

netwind:

1. Боты запрограммированы посылать трафик на IP, который не меняется и может быть вообще один единственный. На BGP ботам наплевать. Боты с маршрутизаторами не взаимодействуют напрямую. Вы не сможете "менять Б сервера" с помощью BGP.

Атака может быть на ip, а может быть на домен, чаще встречаются по доменному имени, т.к. ip можно быстро поменять через А-запись и атака пойдет впустую. Боты не взаимодействуют с маршрутизатором, BGP и т.п., но в конечном итоге они взаимодействуют с ip адресом, который мы как раз и можем перекидывать с одного сервера на другой.

netwind:

2. Множество точек входа, желательно разбросанные по миру, анонсируют одно и то же адресное пространство (Anycast), что не дает возможности трафику сойтись в одной точке и забить каналы или уронить маршрутизаторы. У ботнета отсутствует сама возможность направить атаку в конкретную географическую точку. Вообще не нужно выдумывать какие-то переключающие схемы.

3. При особо массивных атаках, точка обработки трафика может, согласно партнерским соглашениям с региональными провайдерами, подавить трафик на атакуемый IP к себе, начав анонсировать этот IP в bgp blackhole comminity. Это дает возможность подавить объем трафика намного больше чем закуплен канал для точки. И это нормально. Вряд ли русских вебмастеров интересует трафик из Китая. Такой трафик помрет где-то на подходе прямо в китайской провинции. Разумеется, китайские пользователи сайт не смогут открыть. Компромиссы приходится искать везде.

Это замечательно, но что делать конечному владельцу ресурса, писать региональным провайдерам?

netwind:

Вот теперь прикиньте сколько минимально стоит создание подобной инфраструктуры и сравните с колхозным DNS из трех серверов по 100$, который тоже сносно должен переварить атаку 300 мбит и с довольно серьезным pps.

Согласен, с DNS выйдет гораздо проще и дешевле. Но ТС спрашивал как сделать так же, но исключив задержки DNS.

С BGP точно такая же схема предложенная ТС, только меняем Б-серверы не при помощи DNS, а посредством BGP. Захотели, траф пошел на Б1, захотели на Б2 и т.д. А захотели, пошел и сразу на оба. Все тоже самое, только без задержек DNS.

Кому конкретная реализация нужна, есть книга, заодно с BGP можно познакомиться...

blackcats:
а такой вариант:

http://www.ashep.org/2011/nginx-balansirovka-nagruzki/

В случае ддоса этот вариант ни чем не отличается от одного единственного сервера, забьют канал до балансировщика udp флудом и все точно так же встанет.

Применение BGP сильно расширит варианты решения проблемы. Появится возможность быстрее сообщать клиенту на какой из серверов ему идти.

Raistlin, простите, но кажется Вы не уловили юмора, начавшегося еще с поста LEOnidUKG :)

Я думаю CSS генерит ненужный хостеру лишний траф :)

Raistlin, Блокируется расширение css на уровне апача, что-то вроде

<Files "\.(css">

deny from all

</Files>

А для хитрых клиентов, вставляющих css прямо в html/php, ставится модуль, выдирающий их от туда на лету.

Можно сделать из веб сервера на старой площадке прокси сервер, пересылающий все запросы на новый сервер, по принципу связки nginx/apache на одном сервере.

jMaax:
VDS-ки предлагаете?

jMaax, VDS-ок, к сожалению, нету. Как говорится, за двумя зайцами (услугами) погонишься... 🚬

Пользуясь случаем, хочу поблагодарить всех, оставивших свой отзыв в теме и обновить несколько устаревшую информацию о скорости подключения серверов, сейчас она 100Mbit/s.

iamsens:
а мне кажется по-другому, если пройтись по-диску badblcocksом, то винт нормально пройдет смарт-тест, а выкинуть веник дело последнее, это ж десктоп всё таки, а не сервер на гарантии...

Если жалко 1-1,5к рублей на новый, можно конечно и поковырять, только вряд ли поможет надолго. Как правило, такие топики заканчиваются появлением ТС со словами "Диск вчера благополучно скончался во время очередного еженочного бэкапа. Аминь."

iamsens:
извиняюсь, не заметил строк
SMART Self-test log structure revision number 1
Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error
# 1 Extended offline Completed: read failure 90% 1819 159807914
# 2 Extended offline Completed: read failure 90% 1819 159807914


надо тест веника провести, -t long
если тест пройдет, то всё ок, если нет, то надо смотреть

пока причин для замены нет

Это и есть результат работы long теста, говорящий о невозможности чтения очередного блока данных с диска. Является поводом для гарантийной замены диска, либо походом до ближайшей свалки )

Всего: 105