Прячем фактическое место, где стоит сервер компании: практические методы и вопрос

в 12:02, , рубрики: информационная безопасность, он в домике, прячем сервер, системное администрирование, метки: ,

Привет! Я руковожу небольшим ИТ-аутсорсингом, и к нам в прошлом году обратилось сразу несколько клиентов с похожими задачами — сделать так, чтобы никто не узнал, где именно стоят сервера компании.

В первом случае это был строительный бизнес, у них одна из особенностей сферы в том, что на машинах не должно быть даже следов переписки, особенно перед тендерами. Поэтому у них RDP-ферма, а в офисе терминалы. Прятать надо было ядро. Во втором случае — сервисная компания, работающая с известными личностями (у них это просто слой безопасности, который они не считают лишним). В третьем — производство для нефтяной сферы, у которых по сфере нереальная недобросовестная конкуренция с забросом инсайдеров в чужие офисы.

Мы придумали вот такую схему:

Прячем фактическое место, где стоит сервер компании: практические методы и вопрос - 1

В центре — ядро, вокруг ядра — релей-серверы периметра (дешёвые машины-прокси, на каждой — свой сервис), дальше — терминалы конечных пользователей. Покритикуйте, пожалуйста, ну или попробуйте вычислить IP сервера ядра на примере в конце.

Зачем это нужно?

Общая идея в том, чтобы только владелец бизнеса и главный админ знали, где серверы физически расположены. Дома у заказчика, в подвале офиса, в гараже или в дата-центре в Германии или Туле… — не важно.

Естественно, крупный бизнес умеет решать такие задачи (или они вообще не встают по ряду причин развитой ИБ). А вот малый и средний — нет, и даже силами админа не всегда удаётся это сделать более-менее правильно. Поэтому и стучали к нам.

Идея защиты в том, что:
— Сложно найти IP сервера, поскольку для этого придётся захватить одну из релей-машин и роутер.
— Релей-машины управляются сервером роутинга, который защищён традиционным набором: антиDDoS, QoS, активная система предотвращения вторжений и так далее.
— Сами по себе релеи настолько слабы по ресурсам, что любая попытка протащить через них DDoS закончится обрыванием связи с узлом и поднятием в течение 5–6 минут другой релей-машины где-либо по миру.

Релеи берутся из случайных дешёвых хостингов (в том числе уже проверенных нами) и поднимаются автоматически из дашборда сервера роутинга. Доступа до этого дашборда у нас нет — мы делаем инсталляцию и показываем, что менять. После этого заказчик устанавливает новый пароль и указывает IP головного сервера. Подтверждается это открытым кодом, который мы передаём заказчику.

Естественно, слабое звено — админ. Но если его перекупают или заставляют стучать, всё равно мало что поможет.

Точки отдают стандартные сервисы типа почты, внутреннего сайта, мессенджера, терминалок, приложений типа 1С. В общем, то же самое, что два классических сервера, замурованных в подвал, но вместо IP «подвальных» друзей за каменной кладкой в конфиге пользовательского терминала — IP машин периметра.

В итоге образуется ситуация, когда:

  • Нельзя найти сервера ядра — то есть, например, нельзя украсть или забрать то, чего нет.
  • Роутер-сервер защищает от стандартных угроз и фильтрует нецелевой трафик.
  • У точки входа малая производительность — она ложится как плавкий предохранитель.

Подробнее:

Прячем фактическое место, где стоит сервер компании: практические методы и вопрос - 2

Мы пока доделываем кластеризацию — раундробин и репликацию роутер-сервера. Точки доступа принципиально недублируемые, потому что это очень простая и дешёвая штуковина — проще развернуть новую, чем дублировать.

Детали:

Инсталляция сервера-маршрутизатора

Инсталляция происходит автоматически, но в её процессе фактически происходит следующее:
• На чистой системе создаётся новый пользователь с sudo-привилегиями
• Отключается root.
• Устанавливаются OpenVPN, iptables-persistent, Prometheus, MongoDB, Nginx, скрипты управления, резервного копирования, мониторинга и т. п.
• Настраивается iptables.
• Настраивается Prometheus.
• Конфигурируются prometheus и node-exporter.
• Конфигурируются Nginx и MongoDB.
• Распаковываются и конфигурируются все скрипты, агенты и образы систем, которые будут задействованы на этапах инсталляции точек доступа и подключения защищаемых серверов.

От недобросовестной конкуренции — вполне себе защита. Вопрос в том, всё ли мы предусмотрели в своём велосипеде.

Ну и приглашаю попробовать проверить, где центральный сервер. Вот две машины с опубликованным на них web-приложением (в развёрнутом периметре есть ещё точки доступа):
45.32.154.167 — маршрут №1 к сайту.
151.236.15.175 — маршрут №2 к тому же самому сайту.

Если найдёте IP центрального сервера — с меня бутылка. Покажете, как именно нашли, — вторая. Контактная почта: binfini@yandex.ru

Автор: binfini

Источник

* - обязательные к заполнению поля


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js