Команда Red Hat выпустила рекомендации по смягчению уязвимости memcached

Команда Red Hat выпустила рекомендации по смягчению уязвимости memcached

Команда Red Hat выпустила рекомендации по смягчению уязвимости memcached

Команда Red Hat сообщила, что она осведомлена о серьезной угрозе атак DDoS, использующих уязвимость memcached в серверах, открытых на доступ извне. Также специалисты опубликовали ряд рекомендаций для пользователей, которые желают снизить воздействие этой бреши.

Прежде всего, грамотная настройка брандмауэра. Только в очень редких случаях сервер memcached должен быть доступ извне по Сети. Эксперты призывают пользователей установить брандмауэр, чтобы обеспечить доступ к серверам memcached только из локальной сети.

Не допускайте внешний трафик на порты, используемые memcached (например, на 11211, который используется по умолчанию). К примеру, фаервол Red Hat Enterprise Linux не разрешает доступ к этому UDP-порту в конфигурации по умолчанию.

Во-вторых, отключить UDP.

«Если вам не требуется использовать UDP для memcached, мы настоятельно рекомендуем переключиться на TCP-соединения для вашего сервера (для этого надо добавить "-U 0" в переменную OPTIONS в /etc/sysconfig/memcached). Если вам требуется использование UDP, а также необходим удаленный доступ к серверам memcached, рекомендуется настроить брандмауэр для разрешения соединений только с доверенных хостов», — пишет команда Red Hat.

Ниже приведен пример файла /etc/sysconfig/memcached с отключенным UDP:

PORT="11211"
USER="memcached"
# max connection 2048
MAXCONN="2048"
# set ram size to 2048 - 2GiB
CACHESIZE="4096"
# disable UDP and listen to loopback ip 127.0.0.1
OPTIONS="-U 0 -l 127.0.0.1"

Более подробные рекомендации по правильной конфигурации memcached специалисты Red Hat опубликовали здесь.

Напомним, что в конце февраля мы сообщали, что утилита для кеширования memcached используется для DDoS-атак. А в пятницу стало известно о крупнейшей в истории DDoS-атаке, совершенной на Github, в которой как раз использовалась уязвимость memcached.

Массовые сбои Telegram в России связали с тестированием блокировки

Председатель совета Фонда развития цифровой экономики Герман Клименко заявил, что нынешние перебои в работе Telegram в России могут быть связаны не со случайным сбоем, а с настройкой механизмов ограничения доступа к мессенджеру. По словам Клименко, Telegram — слишком сложная система, чтобы его можно было «выключить одной кнопкой» сразу и одинаково у всех.

Об этом он сказал в комментарии «Парламентской газете». Клименко предположил, что сейчас на разных ТСПУ — технических средствах противодействия угрозам — могут тестировать разные варианты софта и смотреть, как именно они работают в реальных сетях.

Именно поэтому, по его версии, ограничения проявляются неравномерно: у одних пользователей мессенджер ещё более-менее жив, у других почти не открывается.

Эксперт при этом подчеркнул, что задачи полностью «уронить» Telegram, вероятно, нет. Логика, по его мнению, другая: не обязательно добиваться стопроцентной недоступности сервиса, достаточно сделать так, чтобы он перестал нормально выполнять свою главную функцию — связывать людей друг с другом. Если большая часть контактов, чатов и привычных сценариев общения перестаёт работать, пользоваться мессенджером становится попросту неудобно и бессмысленно.

Формально это остаётся именно мнением Клименко, а не официальным подтверждением новой блокировки. Но сам фон для таких заявлений уже есть: ещё 10 февраля Роскомнадзор сообщил о продолжении последовательных ограничений в отношении Telegram. При этом сообщения о якобы полной блокировке Telegram с 1 апреля власти ранее прямо не подтверждали.

К слову, на днях зампред комитета Госдумы по информполитике Андрей Свинцов заявил СМИ, что в случае дальнейших ограничений Telegram в России VPN не поможет.

При этом с вечера субботы, 14 марта, работа мессенджера резко замедлилась. У пользователей некоторых провайдеров Telegram и вовсе перестал открываться.

RSS: Новости на портале Anti-Malware.ru