- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
В 2023 году Google заблокировал более 170 млн фальшивых отзывов на Картах
Это на 45% больше, чем в 2022 году
Оксана Мамчуева
Тренды маркетинга в 2024 году: мобильные продажи, углубленная аналитика и ИИ
Экспертная оценка Адмитад
Оксана Мамчуева
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
DDos - распределённая атака типа «отказ в обслуживании».
Давно известно, что нет безлимитных, отказоустойчивых серверов и каналов. В виду распределённости атаки, особенно когда атакующих много, и они каждый по интенсивности запросов (нагрузки от каждого) не превышают среднестатистического пользователя - любой софт или железо уже не способно отфильтровать паразитный трафик. Следовательно можно залить
любой пир, апстрим или сервер, вопрос лишь в денежных средствах атакующего.
Попробуем воспользоваться оружием атакующего - "распределённостью", для сдерживания атак.
Упрощения:
1) Будем пользоваться только общеизвестным ПО.
2) Защищаем один домен с TTL зоны 1 минута
3) Если есть БД, например mysql, то она не имеет критичных данных и ёё можно синхронизировать по расписанию.
4) Если узел "упал" - значит не доступны все его службы web dns mysql итд
Если это не так тогда это длится малое время и в расчёт не берётся.
Итак:
Узел - VPS/VDS или сервер на котором установлен web mysql php DNS. Естественно узел самодостаточен и способен полностью обработать запрос посетителя сайта. Домен "my.dom" припаркован в локальном DNS и "отдаёт" IP узла. Рекурсия на этом DNS выключена. Настраиваем узел обычным образом, чтобы выдержал максимально много запросов.
Арбитр - VPS/VDS или сервер на котором установлена DNS служба с подобной записью:
Минимальная схема: 1 Арбитр (к арбитру должны быть асоциированы 2 IP для DNS) и 2 Узла
Максимальная ограничена только средствами.
В DNS домена у регистратора пишем ip адреса всех арбитров.
Такая схема правда не пройдёт "Тестирования DNS" так как арбитры будут раздавать разые зоны:
Можно не тестировать (в РуЦентре есть такая возможность)
Можно на время "Тестирования" на всех арбитрах оставить только один узел (forwarders).
Данное "Тестирование" есть не у всех регистраторов и не у всех зон.
Что получается:
Пользователь запрашивает сайт, идёт на ближайший рабочий Арбитр, тот в свою очередь регулярно измеряет время доступа до всех узлов и выбирает самый быстрый. Как только узел становится перегруженным по времени доступа "выигрывать" начинает другой и запросы идут уже на другой узел. Так как TTL зоны 1 минута, получается мониторинг раз в минуту. Так как арбитров много и они по разному выбирают активный узел, то будет распределение трафика по узлам.
Получается online распределение трафика с постоянно изменяющимися ip адресами.
Основная проблема такой распределённости это синхронизация базы данных
Основная проблема такой распределённости это синхронизация базы данных
Нет, основная проблема - репликация файловых систем, особенно в случае полного ухода со связи одного из серверов на какое то время.
А вообще вы делаете очередной велосипед с квадратными колесами.
anycast bgp
snort
pf
proxy.
Нет, основная проблема - репликация файловых систем, особенно в случае полного ухода со связи одного из серверов на какое то время.
с файловыми системами прекрасно справляется rsync
anycast bgp
Не у каждого пользователя есть возможность установки своей AS
snort
pf
proxy.
Это безопасность и отказоустойчивость конкретного узла.
В выше описанной схеме это всё можно применить.
Хочется создать доступную и прозрачную по цене и технологию "рассеивания" паразитного трафика.
Так вы эту систему предлагаете реализовывать обычным пользователям, а не строите или обсуждаете собственное анти ддос решение?
Тема с DDOS даже на этом форуме перегрета, не говоря про остальной интернет.
Ведь обычный пользователь с ботнетом в 100 машин без проблем положит 50% сайтов.
Сейчас уже начали просто брать список анонимных прокси 1000-2000 их свободно можно найти и производят атаку через них. Даже ботнет собирать не надо.
Описанная система проверена на небольших атаках, проверить её в реальности и найти все подводные камни сможет сообщество.
Если будет доступно готовое решение из коробки, которое сможет применить большинство пользователей (возможно с помощью более продвинутых администраторов), пузырь с перегретым рынком защит от DDOS лопнет.
VPS/VDS сейчас доступны по цене и преобрести систему из двух Арбитров и трёх Узлов, разнесённых по миру не так дорого.
DPanel, Дадут вам 50 Гигагабит в мульти режиме (по всем А записям) и я посмотрю с какой скорость вас и ваш софт датацентры начнут вносить в blacklist :) А, такая атака была и даже Касперский её ощутил и пасанул (несмог отбиться в реальном времени) :)
rsync говоришь?
Ок. Допустим CMS, юзер залил туда картинку. А потом еще раз. И еще.
Получается что на 3-х разных срверах лежат 3 разных файла. и вот беда - под одинаковыми именами.
Что будешь делать?
Дадут вам 50 Гигагабит
и livejournal "убивали" и google трясло, всё это другой диапазон цен, как с атакующей так и с обороняющейся стороны
Допустим CMS, юзер залил туда картинку. А потом еще раз. И еще.
Получается что на 3-х разных срверах лежат 3 разных файла. и вот беда - под одинаковыми именами.
Что будешь делать?
Всё просто, изменения вносить только на одном узле, который является мастером (возможно даже о нём не будут знать Арбитры), остальные Узлы с него заберут.
DPanel, Для атакующей стороны цена 10 гигабитного ботнета 500-1000 wmz, ненужно жить прошлым, а ваш узел днс завалят первым udp флудом
Всё просто, изменения вносить только на одном узле, который является мастером (возможно даже о нём не будут знать Арбитры), остальные Узлы с него заберут.
Не ерунди. Upload идет не по ftp, а через браузер.
Не ерунди. Upload идет не по ftp, а через браузер.
В случае браузера можно использовать алгоритмы хранения картинок в общей базе данных (ссылки на ноды и имена файлов). Но в целом конечно проблему это составляет... ты прав... Хотя не верю что нет модуля в CMS-ках который предполагает работу с удаленными хранилищами....