Вы просматриваете данные журнала вашего сервера? Если нет, то вам лучше начать! Хотя большинство людей не придают большого значения журналам, они могут предоставить вам много ценной информации, которая позволит вам отличить хороших и плохих участников, чтобы вы могли реагировать, когда ваш сервер подвергается атаке.

В декабре прошлого года мне посчастливилось посетить OWASP Global AppSec US 2021. Это мероприятие помогло мне понять, насколько ценными могут быть данные журналов. Возьмем, к примеру, ошибку «404 — Not Found»:

  • Это может быть связано с неправильными ссылками на странице, и в этом случае вы можете найти источник ошибки, проверив заголовок страницы «referer». Другой распространенной причиной таких ошибок является устаревшая запись DNS с IP-адресом вашего сервера, которую кто-то забыл стереть. В любом случае, это распространенная ошибка, которая не критична, хотя ее следует исправить.
  • 404 также можно использовать для обнаружения злоумышленников, таких как зонды, пытающиеся выявить уязвимости сервера (например, вредоносные скрипты). Если вы начинаете видеть растущее число ошибок 404 с определенного IP-адреса, проверяющих такие записи, как «/PHPMyAdmin/» или «/admin/», вы можете легко заблокировать их на своем брандмауэре TCP уровня 4 (заблокировать связь TCP на некоторое время) или заблокировать их на уровне запроса (уровень 7) в вашем веб-приложении.

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

Но вы можете извлечь гораздо больше из вашего сервера. Злоумышленники могут исследовать действительные URL-адреса, пытаясь обмануть ваш сервер, добавить параметры запроса, заголовки запроса, параметры тела и т. д. Предполагая, что ваш сервер защищен должным образом и выдает «400 Bad Request» всякий раз, когда делается недопустимая попытка, он также может предоставлять данные чтобы помочь вам держать плохих актеров в страхе.

Перечислим несколько полезных кодов:

  • «400 Bad Request» (попытки сделать то, что вы не должны делать)
  • «401 Unauthorized» (неудачные входы в систему, недоступные страницы)
  • «403 Forbidden» (вы делаете то, что вам не разрешено)
  • «404 Not Found» (может быть фишинг для открытой двери)
  • (…)
  • «500 Internal Server Error» (какая-то неприятная ошибка привела к сбою запроса. Вы должны изучить это)
  • «502 Bad Gateway» (какая-то проблема с вашим сервером)

Просмотрев определенные коды состояния, вы можете получить полезные данные. Вы также можете использовать другие источники. Позвольте мне перечислить несколько:

  • Отпечатки пальцев TCP. Подобно nmap во время TCP-соединения, эта функция позволяет определить операционную систему, исследуя пакеты, полученные во время установления соединения (SYN/SYN-ACK/ACK). Обратите внимание, что эта информация теряется во время TCP-маршрутизации при использовании облачных сервисов, поскольку для ее получения вам необходимо получить доступ к исходному TCP-соединению.
  • Отпечатки пальцев SSL. Эта функция позволяет создавать подпись, которая идентифицирует уникальность SSL, которая может идентифицировать многочисленные ботнеты, поскольку разные реализации клиентов SSL имеют разные подписи, шифры, расширения и эллиптические кривые. Вот пример:
    769,47–53–5–10–49161–49162–49171–49172–50–56–19–4,0–10–11,23–24–25,0
  • Порядок заголовков HTTP — существует известный порядок заголовков для каждого браузера. Если вы можете сопоставить браузеры с порядком их заголовков, вы можете определить любого злоумышленника, пытающегося (плохо) выдать себя за браузер. Многие известные компании, такие как Akamai, используют проверку порядка заголовков HTTP для блокировки аномальных запросов.
  • Заголовок агента пользователя — эта функция может предоставить сведения о семействе браузеров, версии, операционной системе и другие соответствующие данные.
  • IP-адрес — может использоваться для определения страны, региона, обратного DNS-сервера IP-адреса, ASN и поиска в сети, хотя эти проверки следует выполнять в автономном режиме, поскольку они занимают некоторое время. Затем вы можете вывести часовой пояс, чтобы сравнить его с часовым поясом на стороне клиента (браузера) и обнаружить прокси и VPN.
  • Прошел ли пользователь проверку подлинности 2FA/Captcha? Он авторизован? —Ответы на эти вопросы позволят вам определить плохие запросы на основе выбросов, поэтому рекомендуется всегда иметь под рукой соответствующие данные.
  • Снятие отпечатков пальцев на стороне клиента. Это позволяет отличать поддельные браузеры от настоящих на основе поведения браузера.

Теперь давайте перейдем к самой интересной части: иллюстрация вышеизложенного с использованием плагина для Fastify:

Приведенный ниже код создает подключаемый модуль Fastify, который мы можем использовать для сбора информации о запросах. Затем вы можете отправить эту информацию на сервер журналов (например, сервер Logstash) для сбора данных поверх него в режиме реального времени или в автономном режиме.

Во-первых, вам просто нужно зарегистрировать свой плагин:

import requestInfoPlugin from "./plugins/request-info-plugin";
(...)
// serviceName: service that generate info
// publicPrefix is the public path used to call this service
// when behind a load balancer
fastifyInstance.register(requestInfoPlugin, 
   { serviceName, publicPrefix });

Исходный код плагина:

Этот код создаст переменную с именем requestInfo в контексте Fastify, которая содержит все данные, собранные из этого запроса:

  • serviceName: служба, сгенерировавшая информацию
  • ip: IP-адрес источника (вероятно, IP-адрес балансировщика нагрузки)
  • realIp: реальный IP-адрес удаленного клиента, полученный от балансировщика нагрузки.
  • reqId: уникальный идентификатор запроса от Fastify.
  • метод: GET, POST, (…)
  • path: путь запроса (с префиксом publicPrefix)
  • хост: имя хоста из заголовков запроса.
  • ua: строка пользовательского агента
  • UAH: хеш пользовательского агента
  • uai: информация об агенте пользователя из компонента ua-parser-js
  • ssl: строка подписи SSL из https://github.com/phuslu/nginx-ssl-fingerprint, которая вставляет заголовок в запрос.
  • sslh: хэш подписи SSL.
  • referer: строка реферера
  • ac: принять строку заголовка
  • ach: принять хеш-строку заголовка
  • хо: строка; // строка порядка заголовков с буквой, представляющей каждый найденный заголовок;

Вдобавок к этим данным вы должны добавить код статуса ответа, информацию об обратном IP, информацию ASN, пользователя, вошедшего в систему, пользователя, прошедшего капчу, (…) и любую информацию, которая позволяет определить, какие запросы хорошие, а какие плохие (будьте изобретательны! ).

Как только вы начнете регистрировать данные и анализировать их, вы должны найти некоторые достойные закономерности и, надеюсь, дойти до точки, где вы сможете реагировать на угрозы в режиме реального времени, что является конечной целью!

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

  • Какие семейства/версии браузеров поражают мой сервер? Есть ли несколько отпечатков пальцев SSL для каждого браузера? У всех одинаковый порядок заголовков?
  • Сколько запросов у меня обычно бывает на страну? Любые аномальные всплески в вышеуказанных переменных?

Ответив на эти вопросы, создайте наборы правил белого и черного списков для своих серверов.

Доступ к этим данным — это первый шаг к созданию собственного WAF (брандмауэра веб-приложений). То есть по возможности динамически блокировать аномальные запросы (и только после того, как вы настроите свой белый список).

В дополнение к приведенным выше рекомендациям вы должны применять ограничения скорости:

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

Далее вы можете заранее защитить свой сервис от внешних атак и сделать его более безопасным. Создание WAF (брандмауэров веб-приложений) важно, поскольку — и из-за SSL-шифрования — брандмауэры больше не могут защищать серверы от атак веб-запросов. Для их создания сначала нужно собрать необходимые данные.

Я надеюсь, что это поможет вам понять важность данных и вдохновит вас попробовать что-то новое. Если вы хотите углубиться в эту тему, ниже я перечислил несколько проектов и источников из проектов с открытым исходным кодом. Спасибо!

Ссылки:

Отпечатки пальцев SSL:
https://github.com/salesforce/ja3
https://github.com/fooinha/nginx-ssl-ja3 (Nginx SSL-отпечатки)

О порядке заголовков http:
https://sansec.io/research/http-header-order-is-important

Защита сервера Nginx:
https://www.nginx.com/blog/nginx-app-protect-denial-of-service-blocks-application-level-dos-attacks/

Отпечатки пальцев на стороне клиента:
https://abrahamjuliot.github.io/creepjs/
https://github.com/abrahamjuliot/creepjs (исходный код)

Хотите работать в Pipedrive?

В настоящее время мы набираем сотрудников на несколько разных должностей в разных странах/городах.

Посмотрите и посмотрите, подходит ли вам что-то

Позиции включают в себя:

  • Младший разработчик
  • Инженер-программист в DevOps Tooling
  • Backend, Full-Stack, iOS-инженеры
  • Инженер автоматизации
  • И еще несколько