Организация использования Mail.Ru агента в корпоративной сети

2 мая 2011 г.

Mail.Ru агент (далее — MRA) стал распространенным способом обмена сообщениями в некоторых регионах России и СНГ.
Однако, очевидно, что его использование идет вразрез с обеспечением информационной безопасности организации. Как часто бывает, там, где им уже пользуются, отключить его полностью крайне трудно из-за криков а-ля «У нас там все клиенты!!!»

Чем же опасен MRA?

Передача текстовых сообщений

  • с помощью текстовых сообщений возможна передача конфиденциальной информации, а также прием «вредной» информации (например, ссылки на вредоносное ПО)
  • с помощью текстовых сообщений возможно манипулирование сотрудниками со стороны социальных инженеров


Передача файлов

  • с помощью этой функции из сети компании может уйти конфиденциальная информация, а в сеть компании может попасть «вредная» информация (например, вредоносное ПО, замаскированное под «смотри-какой-классный-прикол-я-нашел»)

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

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

Этапы реализации

  1. Исследование протокола обмена сообщениями MRA.
  2. Разрешение использования только обмена текстовыми сообщениями.
  3. Перехват текстовых сообщений, курсирующих между компанией и внешним миром, а также внутри компании.

Этап 1. Краткое исследование протокола обмена сообщениями MRA

Описание протокола для разработчиков, а также заголовочный файл с прототипами функций можно найти на странице http://agent.mail.ru/ru/developers/protocol.html.
При близком рассмотрении был составлен шаблон пакета, содержащего текстовое сообщение MRA.
Небольшая выдержка из официального описания:
MMP бинарный протокол. Все числовые данные передаются как четырехбайтные целые НЕ в сетевом формате, т. е. первым идет старший байт, последним младший. Четырехбайтовые беззнаковые целые обозначаются UL.
Текстовые данные передаются с префексированной длиной, т. е. сначала UL, а потом строка (в кодировке windows-1251) длины UL без завершающего нуля. Обозначение в дальнейшем — LPS.
LPS
По полочкам разложили. Перейдем к интересующим моментам:

  • в передаваемом сообщении поле mesg содержит значение 0x00001008;
  • в принимаемом сообщении поле mesg содержит значение 0x00001009;

И вдруг выясняется, что хотя в текстовом описании протокола и присутствует информация о функции MRIM_CS_FILE_TRANSFER, занимающейся передачей файлов, в заголовочном файле ее прототип отсутствует (как и прототипы многих других функций). Говорим громкое «спасибо» разработчикам Wireshark’а
Не буду приводить дампы, скажу сразу:

  • флаги сообщения (значение поля flags) при передаче и приеме файла одинаковы и равны 0x00001026.

В результате мы имеем информацию о том, как распознать нужные нам виды сообщений.

Этап 2. Разрешение использования только обмена текстовыми сообщениями MRA

Итак, определившись со структурой пакета, пойдем дальше.
MRA использует для своей работы следующие порты:

  • 2042 – используется при подключении к серверу для получения адреса наименее загруженного в данный момент сервера обмена сообщениями;
  • 2041 – основной порт, по которому происходит обмен сообщениями;
  • 443 – стало модно использовать этот порт, хотя данные, передаваемые через него ничем не отличаются от данных, передаваемых по порту 2041.

Сервера MRA находятся в следующих диапазонах:

  • 94.100.176.0/20
  • 217.69.128.0/20

Собранных сведений достаточно для осуществления злодейского плана…

  1. Настраиваем корпоративный прокси на пропускание пакетов по портам 2041 и 2042 в диапазоны 94.100.176.0/20 и 217.69.128.0/20.
  2. Настраиваем фаерволл на отброс пакетов, идущих в диапазоны 94.100.176.0/20 и 217.69.128.0/20, если пакет является пакетом MRA и содержит флаги передачи файла.

1. Прокси

Тут кому как нравится, я использую squid в связке с ubuntu, синтаксис правил для него описан не раз.

2. Фаерволл

Опять же, кто что использует, я приведу правила для iptables, запущенного на прокси.
# Creating MRA Chain
iptables -N MRA_Packets
# ******************** MRA_Packet Chain **************************
# Так мы отбрасываем пакет, записав предварительно IP и время в лог для «ата-та»
iptables -A MRA_Packets -m u32 --u32 "52=0x26100000" -j LOG --log-prefix "MRA File Transferring: " --log-level 7
iptables -A MRA_Packets -m u32 --u32 "52=0x26100000" -j DROP

# ********************* INPUT Chain ***************************
# Так мы определяем, что это пакет MRA
iptables -A INPUT -m u32 --u32 "40=0xEFBEADDE" -j MRA_Packets
# ********************* OUTPUT Chain ***************************
# Так мы определяем, что это пакет MRA
iptables -A OUTPUT -m u32 --u32 "40=0xEFBEADDE" -j MRA_Packets

Этап 3. Перехват сообщений MRA

Перехват сообщений не особо сложен, так как:
• спецификация протокола доступна;
• мы выпускаем агента только по «чистым» портам.
Свою реализацию опишу как-нибудь в следующий раз

Теги: рубрика Интернет