Скрыть рекламный блок

Кто Он-лайн

Google AdSense

Защита rcon пароля с помощью IPTables

Разместил: Venom4eG

Итак, в данной статье я хочу рассказать Вам, как защитить свой RCON пароль от подбора или не санкционированного использования средствами Linux / Unix систем.

Linux & IPtables



Предыстория

Так уже получилось, что необходимость использования rcon на наших серверах обуславливалась использованием системы статистики HLStatsX. В принципе если бы не эта система, то rcon можно было бы спокойно убрать и не ломать голову о его безопасности. 

В какой то момент мы стали замечать о внезапных перезагрузках серверов. Судя по логам сервера перезагружались командой из консоли, такое могло происходить только с помощью rcon пароля.

Сменили пароль и, думая, что мы заткнули дырку - забыли об этом. Но спустя какое то время у нас сменилось MOTD окно и сервер опять стал рандомно перезагружаться. Стали изучать логи более детально. Выяснилось, что существует некая бот сеть, которая уводит rcon пароль с CS сервера через какой то бекдор в плагине (прим.: эту дырку мы так и не нашли, но это уже не имеет смысла). После того, как в бот сеть попадает ркон сервера, с рандомной ноды (рандомного бота с рандомного IP адреса) поступает команда через rcon о смене MOTD окна, в него заносится ссылка на скачку вредоносного кода (судя по всему эта бот сеть так и расширяется), далее идёт команда на перезагрузку сервера, чтобы данное изменение MOTD окна применилось. 

Дроп входящих соединений с данных IP на фаерволе ни к чему не привела, т.к. всех не перебанить .

Смену MOTD мы заблокировали на уровне файловой системы, ибо выдача стандартных прав файлу motd.txt вида 0444 – read only не спасала, т.к. файл менялся самим сервером. Блокировку мы сделали с помощью команды chattr. 

chattr — изменяет атрибуты файлов на файловых системах ext2fs, ext3, ext4 и частично на других файловых системах Linux 

Достаточно выполнить:

#sudo  chattr +i motd.txt

И изменение файла motd.txt запрещается на уровне файловой системы.

Но это было полдела, т.к. перезагрузки сервера остались, причём, т.к. файл не менялся, боты видели это и делали повторные перезагрузки серверов.

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

В поисках различных способов защитить rcon я наткнулся на единственное решение, которое использовали владельцы серверов - плагин rcon defencer. Смысл плагина довольно простой, плагин является некой прослойкой между сервером и amx’ом. 

Автор: DJ_WEST

Описание: 

Данный плагин позволяет защитить ваш RCON пароль сервера от различного рода эксплойтов и бэкдоров (в плагинах без исходника). Суть плагина заключается в том, что вам не нужно нигде прописывать rcon_password "ваш_пароль". Поэтому его не видно ни в конфигах, ни в строке запуска сервера, а также пароль нельзя получить с помощью функции get_cvar_string (get_pcvar_string), вызываемых из других AMXX плагинах. RCON указывается внутри исходника плагина (в зашифрованном виде), отсюда следует, что пароль будет храниться в скомпиленном плагине. С данным плагином будет работать управление сервером через RCON, как обычно с помощью клиента игры, HLSW или других приложений.

Идея интересная, но довольно сырая и является скорее костылём, чем полноценным решением проблемы. Тем более что наша статистика не смогла с ним работать.

В итоге, поразмыслив, наконец то вспомнили, что мы используем Linux систему на сервере, которая имеет столь мощное средство как IPTables.

IPTables — утилита командной строки, является стандартным интерфейсом управления работой межсетевого экрана (брандмауэра) NETFilter для ядер Linux, начиная с версии 2.4. Для использования утилиты IPTables требуются привилегии суперпользователя (root).

Итак, на этом оканчиваем нашу предысторию и переходим к собственно решению – защите нашего RCON пароля.

Решение проблемы

IPTables имеет в своём арсенале столь замечательную вещь, как расширение string. Оно позволяет выполнять фильтрацию пакетов, основываясь на анализе содержимого  области данных пакета.

Для начала мы решили собирать лог всех входящих пакетов, которые содержали бы в себе строчку rcon либо строчку с нашим паролем:

-A INPUT -p udp -m udp -m string -i eth0 --dport 27015:27020 -j ULOG  --string "наш_пароль_ркон" --algo kmp --to 65535 --ulog-prefix "RCON PASS" --ulog-cprange 100

-A INPUT -p udp -m udp -m string -i eth0 --dport 27015:27020 -j ULOG  --string "rcon" --algo kmp --to 65535 --ulog-prefix "RCON PASS" --ulog-cprange 100

Данные два правила проверяют входящие UDP пакеты с интерфейса eth0 идущие на порты серверов 27015 по 27020 на содержание в них строчки rcon или наш пароль. При нахождении, такой запрос целиком падает в лог файл по адресу /var/log/ulog/ .

Особого успеха данная рыбалка не принесла, ибо в логах мы видели содержимое пакетов с командами на перезагрузку сервера, но никакой информации о том, как был получен rcon пароль, какой командой мы так и не нашли.

В итоге, вся защита rcon’а свелась к 1 правилу iptables:

-A INPUT -p udp -m udp -m string -i eth0 --dport 27015:27020 -j DROP  --string "rcon" --algo kmp --to 65535

Данное правило, как и предыдущие два анализирует входящие UDP пакеты на интерфейсе eth0 идущие на порты серверов и в случае нахождения в них слова rcon – дропает данный пакет.

Т.к. наша система статистики работает на локальном интерфейсе сервера, то она не подпадает под данное правило. В итоге все rcon команды с внешней сети стали не доступны, но с локального интерфейса все Ок.

Просто и красиво.

Если Вам необходимо использовать rcon, то можно подправить данное правило и разрешить пакеты содержащие rcon с определённого IP адреса.

p.s. при участии админа pyatak

 

У кого возникнут вопросы, просьба задавать их на нашем форуме.


5
Дата: 28.03.2014 Прочитано: 2408 Категория: Мой HLDS сервер
Нет комментариев. Почему бы Вам не оставить свой?
Вы не можете отправить комментарий анонимно, пожалуйста войдите или зарегистрируйтесь.