Представляем заключительную часть цикла по основам процедурной безопасности, дорогие опсекисты! Ранее мы прошли 4 из 5 шагов: опредилили, что нужно защитить и от кого, поняли, куда могут ударить и оценили, стоит ли конкретная уязвимость защиты.

Сегодня у нас заключительный шаг, когда у многих он, к сожалению, первый и единственный — меры противодействия. Заключается он в ответе на вопрос: «как закрыть уязвимости для нейтрализации угроз?» Ответим на этот вопрос для наших примеров.

📌 Криптотрейдер После 4-го шага у нашего трейдера остались лишь уязвимости с низкими рисками: подсматривание и болтовня, фиксить которые нет смысла. Поздравляем его: можно не отвлекаться от непосредственной работы на бирже на лишние телодвижения, а в случае наступления маловероятного сценария атаки его выручат стандартные процедуры авторизации биржи и её техпод.

📌 Арендатор сервера Здесь риски оказались высокими для обеих уязвимостей: известных цензору сигнатур VPN и стандартных настроек сервера. Фиксим:

1. Защита от цензора

  • берем менее известных хостеров для снижения вероятности блокировки VPN по IP
  • протоколы VPN берем маскирующиеся под то, у чего ниже шанс попасть под блокировку: например, HTTPS (XTLS-RealityOpenConnect)
  • порты VPN используем стандартные для маскируемого сервиса: 443 для HTTPS
  • желательно гонять только TCP (UDP-поток параллельно на тот же сервер может вызвать подозрения)
  • в качестве сайта для маскировки выбираем что-то часто посещаемое с забугорным доменом и что вряд ли заблокируют: например, yandex.com, samsung.com, microsoft.com

2. Защита от ботов залётных кулхацкеров

  • в /etc/ssh/sshd_config явно отключаем вход рута, вход по паролю, вход всех, кроме нашего юзера, меняем порт 22 на другой.
  • в конфиге UFW по адресу /etc/ufw/before.rules меняем ICMP-echo-request с ACCEPT на DROP, ставим дефолтные запрет на все входящие и разрешение всех исходящих, добавляем отдельные разрешительные правила для всех протоколов на все направления, в т.ч. кастомный порт SSH и порты VPN.

Это базовая (20%) настройка безопасности, но её хватит для большинства (80%) вероятных угроз. Вы наверняка заметили, что большая часть работы (4/5 шагов) в OPSEC — подготовка к действию. Любой опытный хакер подтвердит, что 90% их работы — разведка или рекогносцировка. Идя от обратного, мы применяем тот же подход, но из-за простоты примеров может показаться, что подготовку можно пропустить.

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

Чётко описав свои вычисления, вы кратно поднимаете шансы провести их правильно и не потратить впустую ресурсы на потенциальную работу над ошибками, например. И это ещё не лучший пример, т.к. в счёте в уме вы ещё сознательно работаете, а расчёт необходимых мер безопасности происходит вообще бессознательно, иррационально = чаще всего неправильно.

ИМХО:  Делайте строго по алгоритму сейчас, и через какое-то время практики вместо моментальных решений, основанных на бессознательном стремлении защитить всё и от всего, вы будете так же быстро получать куда более рациональные решения и не будете тратить свои ресурсы на ерунду. Поменьше полагайтесь на наше любимое «авось» и осознанно подходите к безопасности ваших операций, а удачи пусть желают ваши друзья, в том числе редакция. Что же, удачи вашей деятельности (с надеждой, что вы не торгуете людьми)!

Свежее