В последние годы участились случаи DDOS-атак с участием пассивных ботов. Я так называю серверы в сети (интернет), которые не были взломаны или как-то еще скомпрометированы а всего-лишь установленные с использованием настроек “по умолчанию”, принимающие благодаря этому участие в атаке в качестве промежуточных усилителей трафика. Им отправляют специально оформленный сетевой пакет, ответ на который должен быть отправлен “жертве” атаки, а не тому, кто его шлет.
Как такие действия становятся возможными?
В основу атак такого рода заложена особенность протокола UDP – отсутствие необходимости проводить так называемое рукопожатие во время установления сетевого соединения. То есть никакой проверки отправителя не производится, не проверяется тот факт, будет ли информация доставлена именно тому отправителю, который прислал запрос. Ответ отправляется тому адресату, который указан в заголовках пакета. Таким образом, если злоумышленник в заголовках отправляемых пакетов подменит свой IP адрес на IP адрес “жертвы”, то все ответы от пассивного бота будут направляться “жертве”. И если использовать множество таких пассивных ботов, будет крайне сложно выявить реальный источник атаки. Это одно из неприятных преимуществ подобной техники атак.
Другое преимущество заключается в том, что, как правило, размер ответа многократно превышает размер запроса. Например, запрос к DNS серверу (кстати DNS работает в основном по протоколу UDP) может не превышать и сотни байт, в то время как ответ (например, ответ об отсутствии домена и предложение сходить к корневым DNS серверам) будет занимать более килобайта, что в 10 раз больше размера запроса. Таким образом, атакующий может не только не раскрывать себя, но и десятикратно увеличивать размер совершаемой атаки. Атакующий, используя сервер с гигабитным подключением, сможет организовывать атаки, превышающие 10 Гбит. При таких объемах, сервер “жертвы” не сможет не то что обработать весь входящий трафик, но даже его принять.
Какие службы подвержены этой проблеме?
Да практически все, которые работают по протоколу UDP: DNS сервер, сервер времени, сервер удаленной записи логов(rsyslog) и многие другие. Но особенно привлекательной службой для совершения атак с использованием пассивных ботов является служба SNMP. На множестве сетевых устройств она включена по умолчанию, но не настроена должным образом. Эта служба работает на linux серверах, на сетевом оборудовании, даже удлинитель в стойке укомплектован SNMP службой, которая на чтение включена изначально. На запись она как правило закрыта, но и чтения вполне достаточно. Отправив коротенький snmpwalk запрос и использовав типовое community public (для авторизации), можно получить ответ размером в несколько мегабайт. Это позволит в десятки тысяч раз усилить атаку и достичь невероятных размеров трафика, даже работая с одного взломанного сервера. Естественно, для совершения атаки, с такого размера усилением, понадобиться множество промежуточных ботов, так как каждый бот будет отвечать много, но не быстро (особенности работы snmp). С другой стороны, сам факт потенциальной возможности усиления атаки в десять тысяч раз вселяет ужас.
А теперь я бы хотел осветить неприятный момент для тех, кто является владельцем систем, которые используются для усиления атак. Участие в такой атаке – это не только дополнительная нагрузка на ваш сервер, не только бессмысленная трата трафика, но и потенциальная ответственность за совершаемую атаку. Ведь все ответы на подделанные запросы отправляются от ИП адреса вашего сервера. “Жертва” атаки видит не реального злоумышленника, а сервер, через который осуществляется атака. Соответственно и претензии предъявляются владельцу IP адреса. В некоторых случаях доходит до отключения вышестоящим провайдером сервера, участвующего в атаке.
Кто виноват в том, что ваш сервер может быть использован в качестве пассивного бота, и что делать, чтобы это предотвратить?
Ответить на эти вопросы крайне просто. Начну с ответа на первый: виноваты все провайдеры конечных клиентов, которые в сетевых пакетах не фильтруют обратный путь (не используют reverse path filter). Отсутствием такой мелочи в настройках сетевого оборудования они потакают подобного рода атакам, позволяя подменять в заголовках отправляемых пакетов свой IP адрес на IP адрес “жертвы”, который, как правило, не принадлежит адресному пространству этого провайдера. Сказать, что фильтровать обратный путь сложно или дорого, будет глупо. Подавляющее большинство даже “домашних” маршрутизаторов это умеет. Я уже не говорю об интернет-провайдерах и датацентрах. Кто-то скажет, что это усложнит конфигурацию – я не спорю, но усложнение будет не столь критичным, чтобы его реализация была невозможной. Да и ситуации, где наличие фильтра обратного пути будет проблемой, крайне редкие. Но в мире преобладает практика: “работает – не трогай”. И большинство администраторов, ответственных за обслуживание сетевого оборудования, просто не хочет или боится этим заниматься. А кто-то просто и не задумывается об этом.
Переходим ко второму вопросу: что делать? Ответ также прост: по возможности фильтровать обратный путь, отключать или ограничивать службы, работающие по протоколу UDP, устанавливать ограничения на кол-во обрабатываемых запросов с одного IP адреса и так далее.
Более детально я бы хотел описать рекомендации для пользователей наших виртуальных серверов.
Для начала нужно отключить все неиспользуемые службы, работающие по протоколу UDP. На примере CentOS я покажу как это сделать. Определить список слушающих сетевые подключения служб можно, используя команду:
# ss -lnup
Она покажет не только номера прослушиваемых портов, но и названия программ, которые слушают эти порты. Например, в следующем выводе видно что использовался сервер nfs и сопутствующие ему сервис rpcbind:
Обычно на хостинг-сервере эти службы не нужны и могут быть отключены. Для дистрибутивов, основанных на RHEL, это делается следующими командами:
# service rpcbind stop
# chkconfig rpcbind off
Далее виден запущенный rsyslog сервер. Если вы не собираете логи с удаленных серверов, то и держать открытым rsyslog сервер не нужно. Его можно просто отключить или ограничить файрволом для доступа только с разрешенных хостов.
Аналогичная ситуация и с сервером времени (ntpd). Если Вы не предоставляете сервер времени другим серверам, а используете его лишь для синхронизации времени на своем сервере, то нет смысла слушать сетевые подключения извне. Для введения необходимых ограничений убедитесь, что в конфигурационном файле /etc/ntpd.conf присутствует следующая строка:
restrict default ignore
С DNS сервером BIND ситуация обстоит несколько иначе: он был так часто используем в атаках, что разработчики внедрили ограничения на кол-во запросов в секунду в сам сервер. Теперь, при установке свежей версии bind, можно увидеть следующие строки в конфигурационном файле:
rate-limit {
responses-per-second 5;
window 5;
};
Они не позволяют очень агрессивно использовать DNS сервер. Продолжая оптимизацию DNS сервера Bind я бы также рекомендовал отключить рекурсию. Обычно VPS не используют в качестве рекурсивного DNS сервера для других компьютеров, соответсвенно и отвечать он должен только на запросы о доменах, которые он обслуживает. Все остальные запросы должны игнорироваться. Отключить рекусрсивные запросы можно, добавив следующую строку
recursion no;
в раздел options файла /etc/named.conf
Ну и напоследок – snmpd. Если вы не используете snmp, то просто отключите эту службу командами service и checkconfig:
# service snmpd stop
# chkconfig snmpd off
Если же используете, то убедитесь в наличии и настройке авторизации. Оставлять коммьюнити public – это дурной тон. Сразу после установки в CentOS файл snmpd.conf будет содержать следующее:
com2sec notConfigUser default public
group notConfigGroup v1 notConfigUser
group notConfigGroup v2c notConfigUser
view systemview included .1.3.6.1.2.1.1
view systemview included .1.3.6.1.2.1.25.1.1
access notConfigGroup “” any noauth exact systemview none none
Что позволяет любому, используя community public обращаться к этому серверу. Как минимум, добавьте ограничение по IP адресу и смените community public на какое-нибудь другое. Например, так:
group MyReadgroup v2c myaccessnetwork
view all included .1 80
access MyReadgroup “” any noauth exact all none none
com2sec myaccessnetwork ip.add.re.ss Iighie1AMeuza
Как я уже постоянно говорю своим знакомым – нужно исправлять мир, начиная с самого себя. Ведь если каждый сделает над собой усилие, мир изменится и станет лучше 🙂
Руководитель отдела Системного Администрирования VPS.ua
Денис Мищенко
