CMS Eleanor - Поиск
Полная версия этой страницы: Официальный форум Eleanor CMS » ВНИМАНИЕ! Борьба с ддосом
Официальный форум Eleanor CMS » Свободные форумы для общения по интересам » Флейм
Страницы: 1, 2
Skyff
Как я успел заметить нас всех запарили непонятные перегрузки серверов, непонятное увеличение гостей на сайте, тормоза и тому подобные штучки.
И все поняли уже что это все ддос атаки

По нескольким источником да и темам, которые не раз всплывали на этом и других форумах, стала известно что эти ддос атаки, проделки нашего конкурента а точнее лаеда под руководством всем известного человека под именем Пед.
Причины его ддоса неясные толи какаето непонятная детская обида, толи его не идея способность и потеря клиентов, поэтому с помощью ддос атаки он решил вернуть клиентов, толи ещё какие то непонятные причины которые известны только ему самому.
Но что главное нам всем известно кто этим все руководит, и пока мы все тупо смотрим как нас сайт летит в г**** он радуется своими в кавычках успехами, мол как он натянул Елеанору.

На самом деле пока мы все по одиночки сидим и смотрим на свои подующие сайта ситуация изменится неизвестно когда, может он моньяк и от этого получает удовольствие.
Я думаю надо как то с этим бороться и для этого была создана отдельная темо по борьбе с ддосом.
И все желающии быстрее покончить с атаками на свой сайт должны присоеденится к противостоянию.

Некоторые пользователи заметили когда они отражали свою атаку на вредителя, через пару часов атака прекращялась хотя до этого атака продолжалась 5 суток подрят.
И так если каждый начнет переправлять досс атаку на его вредителя его сайт перестанет функционировать вообще в течении нескольких месяцев а то и больше если он непрекратить ддосить, пользователей которые постоянно находятся под ддосом как я понял немало и пусть каждый перенаправит атаку на его сайт и сайт остановится.
И интерес Педа может резко снизится по поводу ддоса в нечем не винных пользователей.
Против одного человека бороться проще который нечего против непредпренимает а если нас будет много и все будут гадить уме в ответ может он задумается а стоит ли это свеч. Так же и против других его гадастей объеденившись мы сможем чтото сделать по одиночки врятли.


И так способы борьбы с ддос атаками.
открывает .htaccess и прописываем следующие строки

1.
RewriteEngine on
 rewritecond %{http_host} ^domain.com [nc]
 rewriterule ^(.*)$ [url]http://www.slaed.net/[/url]$1 [r=301,nc]


Где domain.com прописываем свой домен

2.
Redirect / [url]http://www.slaed.net/[/url]


*самой простой способ

Заранее сделайте два .htaccess, один стандартный другой с методом борьбы и переименовывайте их при атаке.


Можно ещё обратится к хостеру по поводу настройки ограничения обращений за определенное время и временное блокирования такого ип адресса на 2 часа к примеру.

Для тех у кого выделеный сервер или VPS обращайтесь к Sys(3)X (в личку) он поможет решить проблему с досс атаками.


Если будут другие идеи по поводу защиты и Т.П. пишите я обновлю пост
Надеюсь на ваше понимание и участие.
NoIndex
Мда, а-то никто не знал... Бойан, который против серьёзной DDoS атаки — ничто.

Цитата (Skyff @ 27.6.2009, 2:14)
блокирования такого ип адресса

Нету смысла. Во-первых, атакующих компьютеров не один, не два и даже не 10 — банить устанете. Во-вторых, как уже говорил Sys(3)x — IP адреса постоянно меняются.
Skyff
NoIndex, Эта тема специально и создана для идей борьбы с ддос атаками, идеи, методы, советы, собрать все воедино в одном посте.
Если нечего не делать, фиг его знает сколько это все продлится...
Screatch
Найти нормального хостера.
Апач не способен противостоять ддос, единственный способ спасти сервер в этом случае - блокировать аккаунт.
В случае выделенного сервера, необходим второй, более быстрый веб сервер, в нашем случае nginx, на его уровне и происходит фильтрация и при этом блокировка аккаунта не требуется. То что вы описали выше, то это не доказывает что это пед. т.к. если злоумышленник видит что идёт переадрессация ботов, то он поймёт что его ддос бессполезен, и следовательно приостановит его до лучших времён.
Попробуйте сделать переадресацию на другой адрес и сообщите о результатах.
Sys(3)X
Цитата (NoIndex @ 26.6.2009, 23:05)
Бойан, который против серьёзной DDoS атаки — ничто.


Возможно - я тоже так думал. Но если сайт ставит перенаправление и лаедник педа падает - пед этот сайт как правило больше не досит, как стало известно из соседней темы. Я могу помочь сделать что-то конкретное но только тем у кого выделенный сервер или хотябы VPS - в остальных случаях, единственная защита это перенаправление.

Цитата (Screatch @ 26.6.2009, 23:20)
необходим второй, более быстрый веб сервер


Как выясняется, пед ддосит сайты пользователей с гораздо более меньшей силой чем например нас - поэтому есть большая вероятность что и на апаче хотя бы перенаправления но будут работать.
А вообще скольких пользователей сейчас ддосят?
Skyff
После перенапровления ддос атаки на лаед нет, атака снизилась до такой отметки что сайл лает нет не падает но досс атака не кончилась просто снизилась с 50 до 15 гостей.

Sys(3)X, Можеш описать свои методы для выделенного сервера или это лично к тебе?
Screatch
Лично к нему.
Sys(3)X
Цитата (Skyff @ 26.6.2009, 23:30)
атака снизилась до такой отметки что сайл лает нет не падает но досс атака не кончилась просто снизилась с 50 до 15 гостей


Вот как только лаед начал падать пед мог остановить атаку. По инерции боты могут ддосить ещё несколько часов - сразу атака не прекратиться.

Цитата (Skyff @ 26.6.2009, 23:30)
Sys(3)X, Можеш описать свои методы для выделенного сервера или это лично к тебе?


А у Вас выделенный?
Screatch
Ребят, попробуйте для интереса сделать редирект на другой сайт, может дело не в слаеде а именно в редиректе?
Sys(3)X
Думаю там не самое удачное время для экспериментов. Да и если эту тему читает пед (а он её читает) то результат будет таким же, ты проболтался.
Skyff
Sys(3)X, К сожалению нет, но я о таком подумывал, и чем больше будет атак тем чаще я о нем буду думать :) и тем быстрее я его возьму.
Ставим fastcgi, в дополнение eAccelerator, + чуть грубой настройки, что бы с одного ip нельзя было сразу 20 страниц открывать, и здесь уже не обойтись 40-100 ботами, а значит на всех пользователей ботов не хватит:)
Sys(3)X
Цитата (ars @ 2010-02-05, 20:01)
Ставим fastcgi, в дополнение eAccelerator


Тут как минимум VPS нужен для таких целей. От небольших атак спасёт limit_req_zone в nginx.
ну да, но есть тарифы за 20$, совершенно не плохие, например

Дисковое пространство     40 Gb
CPU гарантировано, MHz 700
RAM гарантировано, Mb 512

за такие характеристики, это недорого.
50 гостей - это детский сад...

вот сейчас подбираю движок для сайта газеты, вроде как по заявленым возможностям подходит ваш движок, но не нравится следующие вещи:
1. заточенность под apache (перепишите rewrite правила для nginx, и вам 90% клиентов скажут спасибо!!!)
2. судя по тому, что 50 ботов уложили сайт, значит не оптимизирован движок к нагрузкам, у нас например сейчас на самописном движке, держим нагрузку в 300 человек в секунду. при связки nginx + apache2. но нагрузка сервера 80% =( что не очень радует...
3. я так понимаю, mysql используется myisam хранилище для таблиц, по умолчанию... советую присмотреться к innodb, так как когда дойдет до сотней тысяч новостей и комментов, движок будет тормозить безбожно. переведя таблицы которые часто обновляются в innodb, вы дадите ему производительности и запас прочности от контента... Так же совет, если хотите сделать действительно стоящий продукт, сделайте его с использованием базы данных postgresql, этим самым привлечете крупных заказчиков и серьезные проекты. Так как назгрузки по базе postgresql держит очень хорошо, там уже реализованы лучшие вещи для баз... так же вам позволит заявить о неограниченной возможности хранения контента.

p.s. хотелось бы услышать мнение разработчика и администратора по этим пунктам. Сам являюсь админом в крупном издании, и уже не раз сталкивались с подобными проблемами, даже готовы заплатить, за написание стоящего движка под наши нужды.

p.s. модуль блоги хорошо реализован ;-)
1) заточенность? у меня на ngnix хорошо работает
2) сайт здесь не причем, просто на всех хостингах стоял просто апач, а его повалить нефиг делать. Тем более у движка есть кеш.
поставь fastcgi и акселлератор, нагрузка уменьшиться в 2-3 раза.
Sys(3)X
Цитата (devosx @ 2010-02-07, 13:22)
значит не оптимизирован движок к нагрузкам


Как Вы это определили? Всё что требуется от движка это быстрая генерация и минимум SQL запросов. Но защита от атак это работа серверного ПО а не движка. Не должны запросы доходить до движка, они должны блокироваться. Нет CMS систем которые заточены для 300 запросов в секунду.

Цитата (devosx @ 2010-02-07, 13:22)
использованием базы данных postgresql


MySQL всё же более универсален и неприхотлив. PostgreSQL хоть и работает быстрее, но возни у конечного пользователя с ним больше, для небольших проектов MySQL куда лучше подходит. Но уверен в будущем поддержка PostgreSQL появится.

Цитата (devosx @ 2010-02-07, 13:22)
и вам 90% клиентов скажут спасибо!!!


Судя по темам о проблемах с сайтом из-за 50 гостей, 90% клиентов сидят на хостингах где про nginx пока не слышали.
Цитата (ars @ 2010-02-07, 20:20)
1) заточенность? у меня на ngnix хорошо работает
2) сайт здесь не причем, просто на всех хостингах стоял просто апач, а его повалить нефиг делать. Тем более у движка есть кеш.
поставь fastcgi и акселлератор, нагрузка уменьшиться в 2-3 раза.


Если у вас есть правила rewrite для nginx, то выложите их, насчет акселерации, используем. (изза акселерации растет потребление разовое по памяти, порядка 1 гига хавает, и всё, на этом тормозится... когда без акселерации всего занимает 350 метров процессы php, но при активной нагрузке, растет до свапа...
Цитата (Sys(3)X @ 2010-02-07, 20:51)
Как Вы это определили? Всё что требуется от движка это быстрая генерация и минимум SQL запросов. Но защита от атак это работа серверного ПО а не движка. Не должны запросы доходить до движка, они должны блокироваться. Нет CMS систем которые заточены для 300 запросов в секунду.

ну я бы так не сказал, что задача ПО защищать, движок тоже имеет не последнее значение.
Существует такие системы кеширования, как memcached, если бы ваш движок мог бы сохранять там кеш, то цены небыло бы ему...
так как за счет этого кеширования, можно держать нагрузки в 10-ки тысяч в секунду... вы думаете у дурова на 23 серверах держится 57 миллионов просто так... из них каждую секунду 30 лямов, что-то делают. Конечно можно говорить, о том, что цмс не для этого, но это движок, на котором стоится проекты, и если они будут популярны, то наращиванием железа, проблему не решить....

Цитата (Sys(3)X @ 2010-02-07, 20:51)
MySQL всё же более универсален и неприхотлив. PostgreSQL хоть и работает быстрее, но возни у конечного пользователя с ним больше, для небольших проектов MySQL куда лучше подходит. Но уверен в будущем поддержка PostgreSQL появится.

Если человек выбирает себе PostgreSQL, то он думаю знает на что идет, и настраивать его будет либо его администратор, либо по документации и на своем сервере. или тех поддержка площадки размещения.

MySQL хорошь, тогда когда проект начинается, и когда порог наполнения не возникает... А когда у вас таблицы с миллионами записей, и сортировками и выборками по этим записям, хотел бы я посмотреть на то, как бы работал сайт, у которого таблица на 30 миллионов записей, и там надо сделать сортировку по текстовому полю, а не по id. это уйдет как минимум в медленный запрос, и не выполниться... На postgresql, 30 лямов выполнится без особых проблем (3.5 сек). тут можно разводить флейм, но хотелось бы видеть поддержку замечательной базы.

А насчет 300 в секунду не держит не один движок, могу вам сказать, что держит, и то самописный и допилинный, и больше держал...

Цитата (Sys(3)X @ 2010-02-07, 20:51)
Судя по темам о проблемах с сайтом из-за 50 гостей, 90% клиентов сидят на хостингах где про nginx пока не слышали.


если так относится к проекту, то о серьезности проекта, я так понимаю можно не думать... типа движок для homepage... У вас же есть заказчики, и просто идеи, вы бы хотели видеть свой движок в топ-10 российских движков? думаю любой создатель бы хотел...

возьмите к примеру Сысоева Игоря, он писал под свои нужды nginx, выложил под открытой лицензией, и теперь, он один из самых уважаемых разработчиков на планете... 10% всего интернета на его детище, это не просто так... а за счет чего? то что он очень хорошо держит нагрузки... на высоких и нагруженных проектак... так что симбиоз nginx + postgresql + memcached + движок, даст максимальную маштабируемость и большие возможности для сайта..
Alexander
Цитата (devosx @ 2010-02-07, 21:48)
вы думаете у дурова на 23 серверах держится 57 миллионов просто так...

Ссылочку на источник?

Цитата (devosx @ 2010-02-07, 12:22)
советую присмотреться к innodb

У этой БД SELECT запросы выполняются медленее, поэтому не подходит. Кроме того нет полнотекстового поиска. Для 99% информационных проектов MyISAM идеально подходит.

По поводу Postgres и MySQL. Во-первых, кто Вам сказал, что MySQL намного хуже Postgres-a? Движок баз данных - это всего лишь инструмент, и, умение им пользоваться и определяет результат. Грузит сервер не MySQL, а неоптимизированные запросы. Если запрос не попадает в индексы, то выполнятся он будет одинаково коряво что на MySQL, что на Postgres-e. И не надо рассказывать басни, что серьезные дяди не используют MySQL. Вот Вам в пример два гиганта: Wikipedia и FaceBook. - Прекрасно стоят на MySQL и не говорят о ее неполноценности.
Во-вторых MySQL установлен на всех 99.999% платных хостингов, поэтому система сможет работать у 99.999% потребителей. Чего не скажешь о Postgres. Кроме того работа с ним более хлопотная и сложная, чем с MySQL. Не для средних умов.
В-третьих, запросы в Postgres и MySQL отличаются, поэтому для его поддержки придется абстрагировать запросы что приведет к пусть и небольшой, но потере производительности. Зачем усложнять жизнь 99.999% пользователям? По-моиму Postgres годится, только для старапов и проектов, которые не ориентированы на среднестатического пользователя.

Цитата (devosx @ 2010-02-07, 21:48)
Существует такие системы кеширования, как memcached, если бы ваш движок мог бы сохранять там кеш, то цены небыло бы ему...

А он это умеет. Просто пока не отлажено до конца (негде).
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.