DDoS-атака с моего сервера!

_{КАК ПРЕДОТВРАТИТЬ ИСПОЛЬЗОВАНИЕ СВОЕГО DNS-СЕРВЕРА В ХАКЕРСКИХ АТАКАХ}

По умолчанию DNS-серверы сконфигурированы так, что позволяют хакерам использовать ваш сервер для DDoS-атак. Мы расскажем, как можно этого избежать.

Допустим вам пришло письмо от провайдера со следующим содержанием:

Предупреждение о DDOS атаке: Open recursive resolver used for an attack: «Ваш IP»

-----Original Message-----
From: NFOservers.com DDoS notifier [mailto:Адрес электронной почты защищен от спам-ботов. Для просмотра адреса в вашем браузере должен быть включен Javascript.]
Sent: Sunday, June 19, 2016 2:00 PM
To: abuse@******.net
Subject: Open recursive resolver used for an attack: «Ваш IP»

You appear to be running an open recursive resolver at IP address
*17.11*.*1.**3 that participated in an attack against a customer of ours,
generating large UDP responses to spoofed queries, with those responses
becoming fragmented because of their size.

Please consider reconfiguring your resolver in one or more of these ways:

- To only serve your customers and not respond to outside IP addresses (in
BIND, this is done by defining a limited set of hosts in "allow-query"; with
a Windows DNS server, you would need to use firewall rules to block external
access to UDP port 53)
- To only serve domains that it is authoritative for (in BIND, this is done
by defining a limited set of hosts in "allow-query" for the server overall
but setting "allow-query" to "any" for each zone)
- To rate-limit responses to individual source IP addresses (such as by
using DNS Response Rate Limiting or iptables rules)

More information on this type of attack and what each party can do to
mitigate it can be found here: http://www.us-cert.gov/ncas/alerts/TA13-088A

If you are an ISP, please also look at your network configuration and make
sure that you do not allow spoofed traffic (that pretends to be from
external IP addresses) to leave the network. Hosts that allow spoofed
traffic make possible this type of attack.

Example DNS responses from your resolver during this attack are given below.

Date/timestamps (far left) are UTC.

2016-06-19 10:53:00.493318 IP (tos 0x28, ttl 117, id 26983, offset 0, flags
[none], proto UDP (17), length 1233) «Ваш IP».53 > 95.172.92.x.38725:
31745| 11/0/1 cpsc.gov. A 63.74.109.2, cpsc.gov. NS[|domain]
0x0000: 4528 04d1 6967 0000 7511 2b8f d977 15f2 E(..ig..u.+..w..
0x0010: 5fac 5ce8 0035 9745 04bd 8198 7c01 8380 _.\..5.E....|...
0x0020: 0001 000b 0000 0001 0463 7073 6303 676f .........cpsc.go
0x0030: 7600 00ff 0001 c00c 0001 0001 0000 27dc v.............'.
0x0040: 0004 3f4a 6d02 c00c 0002 0001 0000 27dc ..?Jm.........'.
0x0050: 0012 ..
2016-06-19 10:53:00.493734 IP (tos 0x28, ttl 117, id 26984, offset 0, flags
[none], proto UDP (17), length 1233) «Ваш IP».53 > 95.172.92.x.38725:
31745| 11/0/1 cpsc.gov. A 63.74.109.2, cpsc.gov. NS[|domain]
0x0000: 4528 04d1 6968 0000 7511 2b8e d977 15f2 E(..ih..u.+..w..
0x0010: 5fac 5ce8 0035 9745 04bd 8198 7c01 8380 _.\..5.E....|...
0x0020: 0001 000b 0000 0001 0463 7073 6303 676f .........cpsc.go
0x0030: 7600 00ff 0001 c00c 0001 0001 0000 27dc v.............'.
0x0040: 0004 3f4a 6d02 c00c 0002 0001 0000 27dc ..?Jm.........'.
0x0050: 0012 ..
2016-06-19 10:53:00.494391 IP (tos 0x28, ttl 117, id 26985, offset 0, flags
[none], proto UDP (17), length 1233) «Ваш IP».53 > 95.172.92.x.38725:
31745| 11/0/1 cpsc.gov. A 63.74.109.2, cpsc.gov. NS[|domain]
0x0000: 4528 04d1 6969 0000 7511 2b8d d977 15f2 E(..ii..u.+..w..
0x0010: 5fac 5ce8 0035 9745 04bd 8198 7c01 8380 _.\..5.E....|...
0x0020: 0001 000b 0000 0001 0463 7073 6303 676f .........cpsc.go
0x0030: 7600 00ff 0001 c00c 0001 0001 0000 27dc v.............'.
0x0040: 0004 3f4a 6d02 c00c 0002 0001 0000 27dc ..?Jm.........'.
0x0050: 0012 ..

(The final octet of our customer's IP address is masked in the above output
because some automatic parsers become confused when multiple IP addresses
are included. The value of that octet is "232".)

-John
President
NFOservers.com

(We're sending out so many of these notices, and seeing so many
auto-responses, that we can't go through this email inbox effectively. If
you have follow-up questions, please contact us at ***@***.net.)

---------- Конец пересылаемого письма ----------

_{ПРЕДИСЛОВИЕ}

В наши дни наиболее массированные DDoS-атаки часто используют метод, называемый «DNS-усиление». В этом методе атакующий использует публично доступные DNS-сервера, чтобы «заполонить» свою цель трафиком ответа от DNS-серверов. Атакующий отправляет запрос на определение по имени на публично-доступный сервер, но подставляет в качестве адреса источника адрес цели. Когда DNS-сервер отправляет ответ, он отправляет его на адрес цели. Поскольку величина ответа обычно больше, чем сам запрос, атакующий получает возможность увеличить размер трафика и направить его на цель, как бы «усиливая» его.

К сожалению, DNS-сервера часто остаются открытыми для использования их в таком виде атаки.

Лучшее, что может сделать любой админ – это ограничить, на какие запросы и кому DNS-сервера вообще отвечают. Для внутренних DNS-серверов убедитесь, что они отвечают только компьютерам внутри сети и другим авторизованным DNS-серверам.

Даже ваши внешние, публично-доступные DNS-сервера не должны отвечать на каждый запрос. Если ваш DNS-сервер отвечает на все запросы, особенно на запросы в отношении любого домена, то у вас потенциальная проблема.

_{ИСПОЛЬЗОВАНИЕ RESPONSE RATE LIMITING}

Одна из лучших защит против того, чтобы ваш DNS-сервер использовался в хакерской атаке, это Response Rate Limiting (RRL). Хотя эта настройка не включена по умолчанию (а стоило бы!), она присутствует в BIND 9.9 и более поздних версиях, а также входит в DNS-сервисы, доступные в Windows Server 2016.

Если ваш DNS-сервер не поддерживает RRL, можно попробовать добиться того же эффекта, используя фильтры на файрволле или с использованием других анти-DDoS сервисов.

_{ТАКЖЕ ВОЗМОЖНО ОТКЛЮЧЕНИЕ РЕФЕРРАЛЬНЫХ ОТВЕТОВ «ВВЕРХ»}

Ранее, когда DNS-сервер получал запрос на доменное имя, за которое он не отвечал, он отвечал, перенаправляя к DNS-серверам верхнего уровня. Атака с использованием «DNS-усиления» сделала этот метод неприятной практикой. BIND давно рекомендует отключить эту возможность, Microsoft собирается сделать отключенной эту возможность по дефолту в Windows Server 2016. В более ранних версиях, вы можете просто стереть файл с так называемыми roothints (c:\windows\system32\DNS\cache.dns).

_{ПРОВЕРЬТЕ ВСЕ СЕРВИСЫ DNS}

Определите все компьютеры и устройства в сети, принимающий соединение на порт 53 в TCP или UDP, чтобы найти и сконфигурировать все устройства, на которых могут быть запущены сервисы DNS. Часто вы обнаружите устройства типа беспроводных роутеров, где могут быть запущены неожиданные DNS-сервера.

_{КАК МЫ ЭТУ УЯЗВИМОСТЬ ПОБОРОЛИ!}

Мы изменили правило входящего соединения в брандмауэре Windows (в консоли Windows Firewall with Advanced security), которое разрешает входящий трафик DNS (UDP, порт 53): на вкладке «Область» укажите, что Удалённый IP-адрес должен принадлежать диапазону адресов вашей сети, например: от 192.168.1.1 до 192.168.1.254

А далее, вы можете проверить свою уязвимость по этому ресурсу!