Comments 35
Это имеет определенный смысл в Германии, например, где в квартиры легко подключают 100 Мбит. Мне с моим 12 Мбит проводом (и 1.2 аплинк, плак-плак) веб-сайт дома толком не поднять, три посетителя весь канал заберут. Какой уж тут ддос.
Также, если говорить об отсутствии коннекта от пользователя к серверу (только от сервера к пользователю) — это вполне реализуемо и на обычном сервере в стойке, просто настройте firewall, чтобы дропал все пакеты.
Также, если говорить об отсутствии коннекта от пользователя к серверу (только от сервера к пользователю) — это вполне реализуемо и на обычном сервере в стойке, просто настройте firewall, чтобы дропал все пакеты.
Если следовать методике, описанной в статье, ваш канал забить ДДОС не смогут, этот трафик просто не будет учитываться биллингом провайдера и на загруженность канала не повлияет.
Firewall не спасает от тупого udp-flooda, то есть забития канала рандомными пакетами. А мой способ один из немногих, который спасает :)
Firewall не спасает от тупого udp-flooda, то есть забития канала рандомными пакетами. А мой способ один из немногих, который спасает :)
Канал забьют вполне легитимные пользователи, ддос в такой ситуации не нужен, все само ляжет ^_^
Интересно другое — вы можете привести пример такого приложения, которому приведенные в статье недостатки не мешают? Клиент-серверное приложение, рассчитанное на малое количество пользователей с белым IP. Quake-сервер на три человека, больше ничего на ум не приходит.
Интересно другое — вы можете привести пример такого приложения, которому приведенные в статье недостатки не мешают? Клиент-серверное приложение, рассчитанное на малое количество пользователей с белым IP. Quake-сервер на три человека, больше ничего на ум не приходит.
Про канал написал ниже.
По поводу мощности сервера: ничто не мешает купить современный десктоп с i7 домой и использовать как сервер. Вы наверное уже заметили, что я предлагаю использовать недорогие решения, рассчитанные на домашних пользователей, вместо фирменных серверных. Это некий компромис для стартапов с нулевым бюджетом, которые вы создаёте дома. Посмотрите, например, историю этого стартапа habrahabr.ru/blogs/gdev/120428/
Остаются пользователи с серыми IP. Могу оправдаться тем, что даже некоторые коммерческие проекты не учитывают это при разработке. Впрочем, и здесь есть варианты…
По поводу мощности сервера: ничто не мешает купить современный десктоп с i7 домой и использовать как сервер. Вы наверное уже заметили, что я предлагаю использовать недорогие решения, рассчитанные на домашних пользователей, вместо фирменных серверных. Это некий компромис для стартапов с нулевым бюджетом, которые вы создаёте дома. Посмотрите, например, историю этого стартапа habrahabr.ru/blogs/gdev/120428/
Остаются пользователи с серыми IP. Могу оправдаться тем, что даже некоторые коммерческие проекты не учитывают это при разработке. Впрочем, и здесь есть варианты…
И, как указано в статье, этот метод подходит только для сервисов с программным клиентом.
Ну, веб-браузер — это своего рода программный клиент. Имел в виду ширину канала домашнего интернета в принципе, данных-то от смены клиента меньше не станет.
Вот ради интереса, опять же — сколько у вас аплинк?
Вот ради интереса, опять же — сколько у вас аплинк?
Честные 15 Мбит down/up за 400 р. Живу не в Москве и не в Питере.
За 1000 р. можно купить 100 Мбит. Торренты тянут на половине этой скорости точно.
Просто провайдеры рассчитывают на обычных пользователей, реселлят канал, ну а мы его используем на полную мощность, при том легально. Где вы такой впс, а тем более дедик найдёте за эту цену?
За 1000 р. можно купить 100 Мбит. Торренты тянут на половине этой скорости точно.
Просто провайдеры рассчитывают на обычных пользователей, реселлят канал, ну а мы его используем на полную мощность, при том легально. Где вы такой впс, а тем более дедик найдёте за эту цену?
А если клиент тоже сидит за НАТом?
— Клиенты с серым IP не смогут подключиться.
Очень большой недостаток. Хотя раз и так имеем белый хост и полный контроль над кодом сервера, «прокси» и клиента, то можно и его обойти. Кажется аська так поступает при передаче файлов.
С другой стороны, у схемы и в первоначальном варианте есть уязвимая точка — задидосить логон-сервер и приложение будет лежать. Если логон выдерживает ддос, то НАт можно поднять и на нём, да и смысл в в НАТе теряется.
Понятно, что белые клиенты, которые установили соединение до атаки, будут продолжать работать даже если логон ляжет — но вот новые коннект поднять не смогут — насколько это критично сильно зависит от специфики приложения — если это типа банк-клиент, которые коннектятся часто, но не надолго, то смысла нет заморачиваться с логоном.
Если логон выдерживает ддос, можно попробовать зафлудить его ложными запросами на подключение, например. С этим чуть легче бороться, но все же.
Кстати, а зачем нам в такой ситуации вообще TCP-подключение? У нас же есть
Вот его и использовать в качестве протокола общения клиента и сервера. Клиент не знает ip и хостнейма сервера, ддос (в классическом понимании) невозможен, можно вешать сервер на белый ip.
Онлайн-игра с протоколом на основе Twitter, ыхыхы.
Кстати, а зачем нам в такой ситуации вообще TCP-подключение? У нас же есть
Любой сервис, который предоставляет API и через который можно обменяться информацией
Вот его и использовать в качестве протокола общения клиента и сервера. Клиент не знает ip и хостнейма сервера, ддос (в классическом понимании) невозможен, можно вешать сервер на белый ip.
Онлайн-игра с протоколом на основе Twitter, ыхыхы.
Эти вопросы как раз хотел обсудить в комментариях, спасибо за вашу активность.
Основное преимущество логон сервера — его простота. Это может быть любой бесплатный ftp-сервер, статическая страничка на надёжном хостинге, gmail и т. д. То есть и здесь мы прячем свой стартап за мощную инфраструктуру гигантов IT индустрии. Конечно, logon-сервер могут отключить за нагрузку. Поэтому надо всё заранее продумать и выбрать самый надёжный вариант. Например, посылать ip для подключения через почту гугла.
Основное преимущество логон сервера — его простота. Это может быть любой бесплатный ftp-сервер, статическая страничка на надёжном хостинге, gmail и т. д. То есть и здесь мы прячем свой стартап за мощную инфраструктуру гигантов IT индустрии. Конечно, logon-сервер могут отключить за нагрузку. Поэтому надо всё заранее продумать и выбрать самый надёжный вариант. Например, посылать ip для подключения через почту гугла.
Отправить миллионы писем на почту гугла — тривиальное действо, а скорость выборки и отбраковывания таких запросов будет ограничена. ДДОС вид сбоку.
У гугла вроде спам-фильтр хороший и имея белый список клиентов наверное можно левых в спам отправить.
Если делать рассылку (даже не рассылку, а спам одного ящика) с одного IP, все письма быстро попадут в спам-лист.
То есть имеем максимум 10 легитимных писем с одного IP, на основе которых уже наш сервер будет инициировать tcp соединения. Это явно не 100 Мбит флуд с каждого IP, с которым невозможно бороться.
То есть имеем максимум 10 легитимных писем с одного IP, на основе которых уже наш сервер будет инициировать tcp соединения. Это явно не 100 Мбит флуд с каждого IP, с которым невозможно бороться.
До того, чтобы логон поднять у «гигантов индустрии», да ещё в виде мыла (джаббер как-то поинтереснее наверное будет) как-то не додумался. Зашоренный взгляд — раз сервер, значит свой или хотя бы арендуемые мощности :(
Клиенты с серым IP тоже могут подключиться, если должным образом извратиться. Более того, для таких соединений уже готовые утилиты есть, работающие без участия внешнего сервера. И даже на хабре об этом было.
Провайдер сразу отправит такой адрес в блэкхол и сменит другим (клиенты улетают). Потом ещё несколько раз (клиенты хором кричат «спасибо» за такую «стабильность»). А потом Вас таки вычислят и вырубят, ибо нефиг; пункт соответствующий в любом договоре присутствует.
Больше похоже на извращение, так как по сути выполняет функционал пакетного фильтра находящегося на NAT сервере, таким образом вы только защитите приложение от воздействия паразитного трафика. Каналы провайдера все равно помрут от ICMP/UDP флуда.
В онлайн играх такая схема уже реализована, только после успешной авторизации логин сервер открывает доступ к гейм серверу используя для этого пакетный фильтр. Если не ошибаюсь расширение называется Game Guard.
В онлайн играх такая схема уже реализована, только после успешной авторизации логин сервер открывает доступ к гейм серверу используя для этого пакетный фильтр. Если не ошибаюсь расширение называется Game Guard.
Забить каналы провайдера гораздо сложнее, чем канал обычного клиента.
Представьте, что у вас есть гигабитный канал, совершенно бесплатно, и он доступен вам постоянно и без дополнительных движений, как подключение услуги antiddos. Атака такого канала дорогое удовольствие и очень рискованное.
Во всех системах пакетной фильтрации есть один серьёзный и неустранимый недостаток — они не смогут выдержать атаку больше, чем канал, на котором сидят. Моя идея позволяет решить эту проблему.
Пусть это извращённый метод, но, пожалуй, один из немногих возможных.
Представьте, что у вас есть гигабитный канал, совершенно бесплатно, и он доступен вам постоянно и без дополнительных движений, как подключение услуги antiddos. Атака такого канала дорогое удовольствие и очень рискованное.
Во всех системах пакетной фильтрации есть один серьёзный и неустранимый недостаток — они не смогут выдержать атаку больше, чем канал, на котором сидят. Моя идея позволяет решить эту проблему.
Пусть это извращённый метод, но, пожалуй, один из немногих возможных.
Могу сказать, что Вы не знаете на сколько просто положить гигабитный канал, говорю об этом потому, что сталкивался с UDP/ICMP флудом и представляю какой нужен ботнет чтобы забить гагабитный канал.
Ваше решение подвергает неподготовленного канального провайдера большим рискам, вот в чем соль. И кстати Ваше решение вовсе не позволяет решить проблему полной утилизации каналов провайдеров при атаках.
Ваше решение подвергает неподготовленного канального провайдера большим рискам, вот в чем соль. И кстати Ваше решение вовсе не позволяет решить проблему полной утилизации каналов провайдеров при атаках.
Гигабитный канал был назван для примера. Сейчас в моём городе провайдеры подключены сразу к нескольким магистральщикам, и каналы покупают шире гигабита на порядок.
К тому же, когда от атаки страдает крупный провайдер, проблема ддоса юридически может решиться гораздо быстрее.
К тому же, когда от атаки страдает крупный провайдер, проблема ддоса юридически может решиться гораздо быстрее.
В общем на мой взгляд эффективность борьбы с DDoS атаками у этого решения не больше чем у пакетного фильтра, проблемы точно такие-же.
Возможно, вы просто не поняли основную идею статьи.
Может и не понял.
Вот типичный сценарий который ожидает человека решившегося воспользоваться данным методом:
— Злоумышленник узнает реальный IP NAT сервера (он же может пройти авторизацию на сервере и увидеть с каким IP у него установлены соединения)
— Досит NAT сервер по выявленному IP
А теперь что будет в итоге:
— Либо забьется канал у провайдера, провайдер в шоке
— Либо помрет под нагрузкой NAT сервер/оборудование (пройтись по NAT таблице весьма не дешевая операция), в шоке будут пользователи этого NAT узла
Вот типичный сценарий который ожидает человека решившегося воспользоваться данным методом:
— Злоумышленник узнает реальный IP NAT сервера (он же может пройти авторизацию на сервере и увидеть с каким IP у него установлены соединения)
— Досит NAT сервер по выявленному IP
А теперь что будет в итоге:
— Либо забьется канал у провайдера, провайдер в шоке
— Либо помрет под нагрузкой NAT сервер/оборудование (пройтись по NAT таблице весьма не дешевая операция), в шоке будут пользователи этого NAT узла
Да, это может произойти.
Просто машинка, через которую идёт весь трафик провайдера, очень мощная. Её специально заказывают и ждут несколько месяцев. Это, можно сказать, основной объект инвестиций. И магистральный канал к ней подключается на десятки гигабит.
Очевидно, его забить гораздо труднее, чем обычный клиентский порт на 100 Мбит.
Просто машинка, через которую идёт весь трафик провайдера, очень мощная. Её специально заказывают и ждут несколько месяцев. Это, можно сказать, основной объект инвестиций. И магистральный канал к ней подключается на десятки гигабит.
Очевидно, его забить гораздо труднее, чем обычный клиентский порт на 100 Мбит.
А это оборудование выдержит дополнительно, скажем, 350000 lookup операций в секунду?
Здесь уже всё зависит от провайдера, и от его текущей загруженности.
В целом, я с вами согласен. От очень мощного ддос это не спасёт. Но тогда это будет уже не только ваша проблема, но и проблема провайдера.
В целом, я с вами согласен. От очень мощного ддос это не спасёт. Но тогда это будет уже не только ваша проблема, но и проблема провайдера.
Соль как раз в том, что атака становится проблемой провайдера и если в схеме с фильтром он может просто заблэкхолить маршрут к атакуемому IP и предоставлять далее услуги своим пользователям, то в вашей схеме пострадают абсолютно все и быстро решить провайдер уже ничего не сможет…
Sign up to leave a comment.
Прячемся от DDOS за NAT провайдера