Безопасное развертывание ElasticSearch сервера

После успешного перехода c MongoDB полнотекстового поиска на ElasticSearch, мы успели запустить несколько новых сервисов работающих на Elastic'е, расширение для браузера и в общем и целом, я был крайне доволен миграцией.

Но в бочке меда, оказалась одна ложка дегтя — примерно через месяц после конфигурации и успешной работы, LogEntries / NewRelic в один голос закричали о том, что сервер поиска не отвечает. После логина на дешбоард Digital Ocean'a, я увидел письмо от поддержки, что сервер был приостановлен в связи с большим исходящим UPD трафиком, что скорее всего свидетельствовало о том, что сервер скомрометирован.

DigitalOcean предоставил линк на инструкции, что надо делать в таком случае. Но самое интересно было в комментариях, почти все кто пострадал от атак в последние время, имели развернутый ElasticSeach кластер с открытым 9200 портом. Злоумышленники пользовались уязвимостями Java и ES, получали доступ к серверу и первращали его в составную часть какой нибудь bot-сети.

Мне предстояло восстановить сервер с нуля, но в этот раз я не буду таким наивным, сервер будет надежно защищен. Я опишу свой сетап использующий Node.js, Dokku / Docker, SSL.

Почему так?

Не смотря на всю мощь ElasticSearch, в нем не предусмотрено никаких внутренних средств защиты и авторизации, все нужно делать самому. Тут есть хорошая статья на эту тему.

Злоумышленники (скорее всего) пользуются уязвимостью динамических скриптов эластика, поэтому — если они не используются (как в моем случае) их рекомендуют отключать.

И наконец, открытый 9200 порт это как приманка, его нужно закрыть.

Какой будет план?

Мой план был такой — поднять «чистый» Digital Ocean дроплет, развернуть Elastic Search внутри Docker контейнера (даже если инстанс будет скомпрометирован, все что нужно будет сделать, перезапустить контейнер), закрыть 9200/9300 для доступа из вне и сервить весь трафик к эластику через Node.js прокси сервер, с простой моделью авторизации, через «shared secret».

Поднимаем новый дроплет

DigitalOcean предоставляет заранее подготовленный образ с Dokku/Docker на борту на Ubuntu 14, поэтому имеет смысл сразу выбрать его. Как обычно, поднятие новой машины занимает пару десятков секунд и мы готовы к работе.

Разворачиваем ElasticSearch в контейнере

Первое что нам нужно, это Docker образ с ElasticSearch. Несмотря на то, что для Dokku существуют несколько плагинов, я решил пойти путем самостоятельной установки, так мне показалось будет проще с конфигурацией.

Образ для Elastic'а уже готов и тут есть хорошие инструкции по его применению.

$ docker pull docker pull dockerfile/elasticsearch

Как только образ загрузится, мы должны приготовить том, который будет внешним для работающего контейнера (даже в том случае, если контейнер остановится и будут перезапущен, данные будут хранится на файловой системе хоста).

$ cd /
$ mkdir elastic

В этом фолдере мы создадим конфигурационный файл, elasticsearch.yml. В моем случае он очень простой, у меня кластер из одной машины, поэтому меня удовлетворяют все настройки по умолчанию. Но, как было сказано выше, небходимо отключить динамические скрипты.

$ nano elasticsearch.yml

Который будет состоять только из одной строчки,

script.disable_dynamic: true

После этого можно запускать сервер. Я создал простой скрипт, для на время конфигурации и отладки, может понадобится перезапускать несколько раз,

docker run --name elastic -d -p 127.0.0.1:9200:9200 -p 127.0.0.1:9300:9300 -v /elastic:/data dockerfile/elasticsearch /elasticsearch/bin/elasticsearch -Des.config=/data/elasticsearch.yml

Обратите внимание на, -p 127.0.0.1:9200:9200, тут мы «привязываем» использование 9200 только с localhost. Я потратил несколько часов в попытках конфигурации iptables и закрытия 9200/9300 портов, безрезультатно. Благодаря помощи darkproger and @kkdoo все заработало как надо.

-v /elastic:/data will маппит том контейрера /data в локальный /elastic.

Проксирующий Node.js сервер

Теперь нужно запустить проксирующий Node.js сервер, который будет сервить трафик от/к localhost:9200 во внеший мир, безопасно. Я сделал маленький проект, основанный на http-proxy, названный elastic-proxy, он очень простой и вполне может быть переиспользанным в других проектах.

$ git clone https://github.com/likeastore/elastic-proxy
$ cd elastic-proxy

Сам код сервера,

var http = require('http');
var httpProxy = require('http-proxy');
var url = require('url');

var config = require('./config');
var logger = require('./source/utils/logger');

var port = process.env.PORT || 3010;
var proxy = httpProxy.createProxyServer();

var parseAccessToken = function (req) {
  var request = url.parse(req.url, true).query;
  var referer = url.parse(req.headers.referer || '', true).query;

  return request.access_token || referer.access_token;
};

var server = http.createServer(function (req, res) {
  var accessToken = parseAccessToken(req);

  logger.info('request: ' + req.url + ' accessToken: ' + accessToken + ' referer: ' + req.headers.referer);

  if (!accessToken || accessToken !== config.accessToken) {
      res.statusCode = 401;
      return res.end('Missing access_token query parameter');
  }

  proxy.web(req, res, {target: config.target});
});

server.listen(port, function () {
  logger.info('Likeastore Elastic-Proxy started at: ' + port);
});

Он проксирирует все реквесты и «пропускает» лишь те, которые указывают access_token как параметр запроса. access_token конфигурируется на сервере, через переменную окружения PROXY_ACCESS_TOKEN.

Так сервер уже сконфигурирован для Dokku, то все что остается сделать, это «пушуть» исходники и Dokku развернет новый сервис.

$ git push master production

После деплоймента, идем на сервер и конфигурируем токен доступа,

$ dokku config proxy set PROXY_ACCESS_TOKEN="your_secret_value"

Я также хотел, чтобы все шло через SSL, с Dokku этого очень легко добиться, копируем server.crt и server.key в /home/dokku/proxy/tls.

Перезапускаем прокси, чтобы применить последние изменения, убедимся что все ок, перейдя по ссылке https://search.likeastore.com — если все хорошо, он выдаст:

Missing access_token query parameter

Связываем контейнеры Proxy и ElasticSeach

Нам нужно связать два контейнера между собой, первый с Node.js прокси, второй собственно с ElasticSearch. Мне очень понравился dokku-link плагин, который делает как раз, то что нужно. Установим его,

$ cd /var/lib/dokku/plugins
$ git clone https://github.com/rlaneve/dokku-link

И после установки связываем прокси с эластиком,

$ dokku link proxy elastic

После этого прокси нужно будет еще раз перезапустить. Если все хорошо, то перейдя по ссылке https://proxy.yourserver.com?access_token=your_secret_value, мы увидем ответ от ElasticSearch,

{
  status: 200,
  name: "Tundra",
  version: {
      number: "1.2.1",
      build_hash: "6c95b759f9e7ef0f8e17f77d850da43ce8a4b364",
      build_timestamp: "2014-06-03T15:02:52Z",
      build_snapshot: false,
      lucene_version: "4.8"
  },
  tagline: "You Know, for Search"
}

Подстраиваем клиент

Осталось сконфигурировать клиент таким образом, чтобы на все реквесты к серверу он передавал access_token. Для Node.js приложения это выглядит вот так,

var client = elasticsearch.Client({
  host: {
      protocol: 'https',
      host: 'search.likeastore.com',
      port: 443,
      query: {
          access_token: process.env.ELASTIC_ACCESS_TOKEN
      }
  },
  requestTimeout: 5000
});

Теперь можно перезапустить приложение, убедится что все работает как нужно… и выдохнуть.

Послесловие

Данный сетап, сработал (и работает сейчас) для Likeastore на отлично. Однако с течением времени, я увидел некий overhead, данного подхода. Скорее всего, можно избавится от проксируещего сервера, и сконфигурировать nginx c basic-authorization, с upstream в доккер контейнер, также с поддержкой SSL.

Также, хорошей идей, наверняка будет держать Elastic в private network, и все реквесты к нему делать через API приложения. Это может быть не очень удобно с точки зрения разработки, но более надежно с точки зрения безопасности.

ЗЫ. Это пересказ на русском моего поста из личного блога.

Автор: alexbeletsky

Источник