Защита: Логирование аномалий и Rate Limiting

Ограничение скорости (Rate Limiting) в Go — это базовая мера защиты, позволяющая отсечь автоматизированный перебор. Правильно настроенный лимит не даст таким инструментам, как sqlmap, работать в полную силу. Кроме того, активный мониторинг аномалий позволяет вовремя заметить попытку взлома и пресечь её на корню.

Важно понимать границы применимости: rate limiting и аномалия-детекция — это «слой обнаружения» в стратегии Defense in Depth. Они не закрывают уязвимость как таковую — для этого нужны параметризованные запросы. Но они дают время на реакцию: пока атакующий потратит часы или дни на медленный обход rate limit, SOC увидит аномалию в дашборде, заблокирует IP, сообщит команде разработки, та выкатит fix. Без detection-слоя атака может пройти за минуты, и данные окажутся в darknet раньше, чем кто-то заметит.

Аналогия: представь периметр банка. Сейф (Prepared Statements) — это последняя линия защиты. Бронированные двери (валидация ввода) — следующий слой. Камеры наблюдения и охранник, который замечает «слишком много людей одинаковой комплекции пытаются войти в нерабочее время» — это и есть rate limiting + anomaly detection. Камеры не останавливают грабителя физически, но дают возможность охране среагировать до того, как он доберётся до сейфа.

Разберем, как «поймать за руку» автоматический сканер на уровне вашего Go-приложения.

---

1. Механика: Распознавание роботов

У автоматических инструментов есть свои характерные признаки:

1. User-Agent: По умолчанию он прямо заявляет о программе (хотя это легко изменить).

2. Аномально высокая частота: Десятки запросов в секунду от одного IP — это явный признак работы скрипта, а не человека.

3. Цепочка ошибок: Перед успешной атакой сканер неизбежно генерирует множество ошибок 404 или 500, прощупывая структуру базы.

4. Систематический перебор параметров: атакующий с sqlmap-ом проверяет каждый query-параметр на каждом endpoint по очереди — ?id=1, ?id=1', ?id=1 AND 1=1, ?id=1 AND 1=2. Это создаёт характерный паттерн в логах, который трудно спутать с человеческой активностью. У живого пользователя нет причин тестировать 50 разных вариантов значения одного параметра за 30 секунд.

5. Подозрительный referer/origin: запросы, приходящие напрямую без referer'а или с referer'ом на внешний домен, особенно при попытке POST на форму регистрации/логина — сильный сигнал.

---

2. Реализация Rate Limiting в Go

В экосистеме Go есть отличные инструменты для ограничения трафика (например, golang.org/x/time/rate). Вот как это выглядит в Fiber:

// ✅ ЗАЩИТА: Ограничение количества запросов
config := limiter.Config{
    Max:        10,              // Не более 10 запросов в окно времени
    Expiration: 1 * time.Minute, // Окно — 1 минута
    KeyGenerator: func(c *fiber.Ctx) string {
        return c.IP() // Ограничение по каждому IP
    },
}
app.Use(limiter.New(config))

С таким ограничением sqlmap будет заблокирован почти мгновенно, превращая стремительную атаку в бесконечно долгое ожидание.

Параметры под нагрузку: для публичного API общий лимит часто ставят 100 req/min/IP; для login/registration endpoints — 5 попыток в минуту с экспоненциальной задержкой после первой неудачи; для admin-endpoints — 30 req/min плюс обязательный allowlist по IP. Для аутентифицированных пользователей лимит может быть по user_id, не по IP — это закрывает обход через сменные прокси при scrap-атаках.

Распределённый rate limiting: одного локального лимита в Fiber middleware недостаточно для multi-pod deployment в Kubernetes — каждый pod считает свой лимит, и атакующий может умножить разрешённый rate на количество pods, если попадает на разные через Service load balancer. Решение — использовать Redis-based limiter (например, github.com/ulule/limiter с Redis store) или вынести лимиты на edge (Nginx limit_req_zone, Cloudflare Rate Limiting).

---

3. Таблица аномалий: Что искать в логах

Поведение	Вероятная причина	Действие
100+ запросов в минуту	Автоматическое сканирование	Временная блокировка IP
Циклические серверные ошибки	Подбор SQL-нагрузки	Уведомление службы безопасности
Специфические User-Agent	Работа известных сканеров	Автоматический бан

---

4. Граница эффективности сетевой защиты

Rate Limiting — это не панацея. Хакер может использовать прокси-серверы для смены IP или настроить атаку на сверхмедленную скорость. Однако сетевые лимиты отсекают 95% массовых автоматических атак, делая взлом дороже и сложнее для злоумышленника.

Типичный workaround атакующего — sqlmap --delay 30 --threads 1 --proxy http://... через сеть из 1000 ротирующихся IP. Скорость падает на порядки, но атака остаётся выполнимой. Защита от этого требует поведенческой аномалия-детекции: если 1000 разных IP за 24 часа делают по 5 запросов каждый, и эти запросы все нацелены на параметр ?id=, это вписывается в lateral attack pattern. ML-based WAF (AWS WAF Anti-DDoS, Cloudflare Bot Management) умеют такие паттерны различать, но настройка требует tuning под конкретное приложение и понимания baseline-трафика.

---

Логирование и ограничение скорости — это ваша система раннего оповещения. Вместе с использованием Prepared Statements они превращают ваше Go-приложение в неприступную крепость, где атака становится либо невозможной технически, либо слишком заметной для администраторов.

Полный стек защиты выглядит так: WAF на edge (Cloudflare, AWS WAF) → rate limiting в Go middleware → валидация типа и whitelisting identifiers → Prepared Statements для всех VALUE-параметров → least privilege для database user → network policy запрещающая egress БД-pod в интернет → SIEM собирает все логи и алертит на аномалии. Каждый слой может быть пробит атакующим, но обход всех семи требует ресурсов APT-уровня. Для среднего bug bounty hunter или ransomware-группы это становится дороже, чем потенциальная выгода — и они переключаются на менее защищённую цель.

Соответствие стандартам: OWASP API Security Top 10 — API4:2023 Unrestricted Resource Consumption; PCI-DSS 6.6 «Address new threats and vulnerabilities» косвенно требует rate limiting; NIST CSF DE.CM-1 «Network monitoring» обязывает детектировать аномалии в сетевом трафике.

Мы подошли к концу образовательного пути по SQL-инъекциям в Go. После финального квиза вы будете полностью готовы применять эти знания в разработке безопасных приложений!