Регулярно просматриваю логи сервера и по большей мере они содержат информацию о работе брандмауэра и некоторых служб, которые «смотрят» в сеть.
Нынче любой открытый и проброшенный извне порт является потенциальной дыркой в безопасности системы. И как показывает практика, в сети далеко не шутки распространяют, что с той стороны все открытые адреса и домены прощупываются с целью поиска уязвимых мест.
Так, в один прекрасный день я стал наблюдать, что нагрузка на сеть возросла. Я сразу полез в журнал и увидел, что мой DNS сервер стал сходить с ума. У меня был включен кэш для того, чтобы использовать свой DNS извне в качестве альтернативного и я считал, что иметь такую штуку полезно. Однако, я ошибался. Когда bind стал ругаться, что кэш ограничен 100 записями типа TXT на одно доменное имя, я понял, что на мой адрес пошла «атака усиления» DNS. Подробнее об этом можно прочитать здесь и здесь.
Проблема бинтов (bind)
Однажды в логах я увидел это:
database: error: error adding ‘shine-prices.ru/TXT’ in ‘./IN’ (cache): too many records (must not exceed 100)
Это немного отличается от описанного на страницах, ссылки на которые я привёл выше. Но суть похожая. Bind отказывается кешировать указанные записи (и это правильно) и помимо этого генерирует повышенный трафик, что было заметно в программе сетевого мониторинга iptraf.
Решением было отключить кеширование и резолв любых доменных доменных имен, кроме своего собственного.
Однако, эта операция потребовала создания списка доверенных клиентов, которыми не являются внешние адреса, а также выходящие за пределы локальной сети.
Это выглядит примерно (потому что на самом деле сильно иначе) так:
$bind$/named.conf.options
options {
****************
recursion yes;
allow-recursion {192.168.x.0/24;};
allow-query {any;}
allow-query-cahe {разрешено;};
};
После этого логи очистились и DNS снизил нагрузку на сеть.
Проблема c webmin
Хорошая админка, но сразу после установки дырявая и требует входа через открытый порт. Если раньше такое поведение админа было нормальным, когда он выводит сетевые службы на альтернативные порты, то сейчас это перестало быть преградой. Сетевые сканеры очень хорошо находят всё что открыто, даже если оно не мелькает, и проверяют возможность подключения через любую открытую «дырку».
Так, на веб-сервере наибольшую опасность представляет служба администрирования баз данных. С ней работают и CMS, и некоторые локальные службы, для которых база данных является наиболее предпочтительным посредником. По факту для подключения требуется лишь физический канал, а если что-то открыто, значит уже «провода» соединены правильно.
Ну, это было мне пинком, чтобы убрать админку за NAT и проксировать запросы. Плюс, ужесточил требования по аутентификации.
XRDP. Новая цель — служба удаленного рабочего стола.
Sep 03 08:19:23 xrdp[348554]: [WARN ] Cannot accept TLS connections because certificate or private key file is not readable. certificate file: [/etc/xrdp/cert.pem], private key file: [/etc/xrdp/key.pem]
Sep 03 08:19:23 xrdp[348554]: [ERROR] Cannot read private key file /etc/xrdp/key.pem: Permission denied
Sep 03 08:19:23 xrdp[348554]: [INFO ] Using default X.509 key file: /etc/xrdp/key.pem
Sep 03 08:19:23 xrdp[348554]: [INFO ] Using default X.509 certificate: /etc/xrdp/cert.pem
Sep 03 08:19:20 xrdp[348536]: [ERROR] xrdp_iso_send: trans_write_copy_s failed
Sep 03 08:19:20 xrdp[348536]: [ERROR] xrdp_process_main_loop: libxrdp_process_incoming failed
Sep 03 08:19:20 xrdp[348536]: [ERROR] xrdp_rdp_incoming: xrdp_sec_incoming failed
Sep 03 08:19:20 xrdp[348536]: [ERROR] xrdp_sec_incoming: xrdp_mcs_incoming failed
Sep 03 08:19:20 xrdp[348536]: [ERROR] libxrdp_force_read: header read error
Как видно, какая-то тварь пыталась долбиться на сервер xrdp причем в логе есть строчка:
Sep ***** xrdp[*****]: [INFO ] Socket 12: AF_INET6 connection received from ::ffff:194.180.49.104 port 49591
То-есть попытка законнектиться через INET6. Пока не понимаю, как это возможно, потому что у меня отключена адресация IPV6, но видимо это возможно. Поэтому временно отключил службу и закрыл открытый порт. Но картинка не радужная вот в каком смысле. Когда у тебя обычный роутер, он может не вести журнал на достаточном уровне. Когда у тебя шлюз, то логирование позволяет увидеть, насколько бурная в сети «жизнь».