- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Тренды маркетинга в 2024 году: мобильные продажи, углубленная аналитика и ИИ
Экспертная оценка Адмитад
Оксана Мамчуева
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Здравствуйте.
Исходя из статьи на habrahabr.ru об атаке DNS Amplification, там пишется: "Атака строится на отправке DNS запроса к какому либо DNS серверу с подставленным ip адресом источника, равным ip адресу жертвы."
Я не силен в сетевой части, на каком уровне происходит подмена IP адреса? Я не думаю, что это делается на сетевом уровне, в следствии этого мне представляется такая схемка:
1. Запрос от злоумышленника идет на 53 порт моего сервера, по правилам iptables срабатывает "--state NEW" для сервера злоумышленника, соединение принимается и передается на DNS сервис.
2. Далее DNS сервис разбирает полученные данные, "кушает" подставной IP (или я на этом этапе не прав?) и пытается отправить ответ на подставной сервер.
Собственно, исходя из этой схемы есть в iptables два правила:
В следствии, iptables разрешит принять запрос на 53 порт с сервера злоумышленника, а вот далее при отправке ответа на подставной сервер iptables сбросит ли соединение? Ответ ведь разрешен только на тот сервер, с которым установлено соединение.
поскольку речь идет о UDP, то правила касающиеся ESATABLISHED не могут использоваться
проблему стоит решать на уровне конфигурации DNS-сервера.
например обратите внимание на http://www.zytrax.com/books/dns/ch9/close.html
сама проблема и возможные методы ее решения на уровне iptables описаны по ссылке http://habrahabr.ru/post/51574/
поскольку речь идет о UDP, то правила касающиеся ESATABLISHED не могут использоваться
проблему стоит решать на уровне конфигурации DNS-сервера.
например обратите внимание на http://www.zytrax.com/books/dns/ch9/close.html
сама проблема и возможные методы ее решения на уровне iptables описаны по ссылке http://habrahabr.ru/post/51574/
Проблема в том, что нам недавно заблокировали сервер за исходящий UDP трафик. Технической информации спустя несколько дней так и не предоставили.
На момент проблемы recursion и transfer были полностью запрещены, BIND был последней версии. То есть, что создало проблему непонятно. NTP из вне был закрыт, тоже последней версии.
Сейчас мы поставили лимит на исходящий UDP трафик с помощью iptables, не более N запросов в секунду. Разрешили общаться только с DNS от Google, NTP синхронизируется только с указанным списком серверов, которые прописаны также в iptables и самое главное, BIND отдает только свои зоны.
При настройке iptables заинтересовал вот именно конкретный момент, на который и хотелось бы получить ответ. Статью на habrahabr.ru я читал и не только эту :)
проблема описана как именно DNS amplification и поэтому и предложены решения для него.
к сожалению, не зная подробностей о том какой трафик был (а возможно он есть и сейчас) - посоветовать ничего не получится.
уточняйте у хотсера - имеет ли место трафик и сейчас и дальше. Если он присутствует, то надо искать источник.
например, если речь идет о выделенном сервере, то может иметь место трафик к/c IPMI
проблема описана как именно DNS amplification и поэтому и предложены решения для него.
к сожалению, не зная подробностей о том какой трафик был (а возможно он есть и сейчас) - посоветовать ничего не получится.
уточняйте у хотсера - имеет ли место трафик и сейчас и дальше. Если он присутствует, то надо искать источник.
например, если речь идет о выделенном сервере, то может иметь место трафик к/c IPMI
Да, я понимаю, спасибо, за Ваши развернутые ответы. При написании просто развернуто все описал, чтобы было понятно, о чем идет речь и выделил шрифтом важные для меня моменты, на них хотел получить ответ.
Мне уже сообщили на другом ресурсе, как происходит общение по UDP протоколу и как работает с этим iptables.
А так, мне сообщили только что был исходящий UDP трафик. Куда, откуда - нет информации.
Еще раз спасибо за информацию, тема исчерпана.