10 шокирующих секретов аудита безопасности SMB, которые спасут ваш бизнес

Вступление

Малый и средний бизнес (SMB) часто воспринимается как «мягкая цель» для киберпреступников. Ограниченный бюджет, нехватка специалистов и отсутствие чётко выстроенных процессов делают такие компании уязвимыми. По данным Verizon Data Breach Investigations Report 2023, более 60 % всех утечек данных происходят в организациях с численностью до 500 сотрудников. Поэтому вопрос аудита безопасности становится не роскошью, а необходимостью.

В этой статье я, как технический блогер‑аналитик, подробно разберу популярный пост из Reddit, где автор делится своей «проверенной» методикой аудита SMB. Мы переведём и оживим его содержание, проанализируем комментарии, выделим типичные проблемы и предложим практические решения. В конце – готовый пример кода на Python, который поможет автоматизировать часть проверок.

И, как обещал, завершу вступление японским хокку, отражающим суть защиты:

Тихий щит в ночи,
Взгляд зоркий — враг не пройдёт,
Свет в темноте.

Пересказ оригинального Reddit‑поста

Автор поста – опытный аудитор, который несколько лет подряд проверял безопасность небольших компаний. Устав каждый раз «изобретать велосипед», он собрал в один документ ключевые пункты аудита и решил поделиться ими с сообществом. По его словам, 80 % проблем можно обнаружить, проверив лишь 20 % самых важных областей.

Список дел делится на четыре крупные группы:

1. Периметр сети (точка входа большинства атак)

• Проверка правил файрвола – искать «any/any», неиспользуемые правила и правила старше двух лет.
• Аудит открытых портов – если порт открыт без веской причины, его закрывают.
• Настройки VPN – включён ли split‑tunneling? Требуется ли многофакторная аутентификация?
• Фильтрация DNS – удивительно, сколько компаний всё ещё обходятся без неё.

2. Идентификация и доступ (Identity & Access)

• Аудит учётных записей администраторов – кто имеет права Domain Admin и почему?
• Сервисные учётные записи – когда менялся пароль? (обычно «никогда»).
• Покрытие MFA – не только почта, но и VPN, RDP, облачные админ‑порталы.
• Учётные записи уволенных сотрудников – сверка с HR‑списком.

3. Защита конечных точек (Endpoint Security)

• EDR/AV – 100 % покрытие или есть пробелы?
• Соответствие патч‑менеджменту – особое внимание к публично‑доступным сервисам и критическим уязвимостям.
• Права локального администратора – кто их имеет и нужны ли они?
• Политика использования USB/съёмных носителей.

4. Резервное копирование и восстановление (Backup & Recovery)

• Соответствие правилу 3‑2‑1 (три копии, два типа носителей, одна копия оф‑лайн).
• Тест восстановления – когда последний раз проверяли, что резервные копии действительно восстанавливаются?
• Air‑gapped/immutable‑резервные копии – защита от вымогательского ПО.
• Показатели RTO/RPO – знает ли бизнес, сколько времени может простоять система и какой объём данных может потеряться.

Автор также перечислил «то, что часто упускают»:

• Фильтрация исходящего трафика (egress filtering).
• Логирование DNS‑запросов.
• Сегментация сети.
• Физическая безопасность серверных помещений.

И привёл типичные находки, которые встречаются «каждый раз»:

1. Сервисные учётные записи с правами Domain Admin и паролем вида companyname+year.
2. Отсутствие фильтрации egress.
3. Резервные копии существуют, но никогда не тестировались.
4. Уволенные сотрудники всё ещё имеют активные учётные записи.
5. «Временные» правила файрвола, оставшиеся от пяти летней давности.

Суть проблемы: хакерский подход и основные тенденции

Хакеры, как правило, ищут «самый лёгкий» путь в сеть. Периметр – первая линия обороны, но часто он построен «по‑старому»: открытые порты, устаревшие правила файрвола и отсутствие фильтрации исходящего трафика. После проникновения они используют сервисные учётные записи с широкими правами, а отсутствие MFA делает процесс «прокачки» привилегий почти автоматическим.

Тенденции 2023‑2024 годов подтверждают, что:

• Более 70 % атак начинаются с компрометации VPN‑сессий (по данным Palo Alto Networks 2023 Threat Report).
• Сервисные учётные записи с постоянными паролями – главный источник «привилегированных» утечек (по CISA).
• Недостаток логирования DNS‑трафика часто мешает быстро обнаружить «домашние» атаки, когда вредоносный код использует DNS‑туннелирование.

Детальный разбор проблемы с разных сторон

Техническая сторона

1. Файрвол и правила – «any/any» открывает всё без ограничений. Даже если правило «не используется», оно остаётся в конфигурации и может стать точкой входа при ошибке в другом правиле.

2. VPN‑конфигурация – split‑tunneling позволяет трафику обходить корпоративный контроль, а отсутствие MFA делает процесс входа уязвимым к фишингу.

3. Сервисные учётные записи – часто создаются один раз и забываются. Пароли «company2022» легко угадываются.

4. EDR/AV – покрытие 100 % редко достигается, но даже частичное покрытие лучше, чем отсутствие.

Организационная сторона

1. Отсутствие процессов – без чёткой политики управления изменениями новые правила в файрволе остаются «временными» навсегда.

2. Коммуникация с HR – если IT не получает актуальный список уволенных, учётные записи остаются активными.

3. Культура тестирования – многие компании считают, что наличие резервных копий уже гарантирует восстановление, но без тестов это лишь иллюзия.

Экономическая сторона

Небольшие бюджеты часто заставляют руководителей откладывать «дорогие» решения (например, EDR) в пользу «антивирусов», которые уже не способны противостоять современным угрозам. Однако, как показывает практика, небольшие инвестиции в автоматизацию аудита (скрипты, готовые шаблоны) окупаются за счёт снижения риска простоя.

Практические примеры и кейсы

Кейс 1. «Скрытый DNS‑трафик»

Компания X не вела журналирование DNS‑запросов. Хакер использовал DNS‑туннель для exfiltration данных. После внедрения dnsmasq с включённым логированием, команда SOC обнаружила десятки запросов к недавно зарегистрированным доменам в 03:00 недели. Это позволило быстро изолировать заражённый хост.

Кейс 2. «Временные правила файрвола»

В компании Y администратор в 2018 году создал правило «any/any» для быстрой миграции сервиса. Через пять лет правило осталось, и в 2023 году злоумышленник использовал его для доступа к базе данных, минуя IDS.

Эти примеры подчёркивают, насколько важно регулярно проверять «забытые» элементы инфраструктуры.

Экспертные мнения из комментариев

«Thank you for this list. Although it does give me a headache because I know how many things most clients /IT miss. YIKES» – reilogix

Автор подчёркивает, что список действительно раскрывает масштаб проблем, с которыми сталкиваются большинство клиентов.

«Saved. I've been a solo admin most of my career; you wouldn't believe how many things don't get finished, or get forgotten because of interruptions - aka "other duties as assigned".» – IronicEnigmatism

Соло‑администраторы часто перегружены, поэтому автоматизация и чек‑листы становятся спасением.

«The DNS query logging point is massively underrated. Had a situation where we only caught a compromised endpoint because it was making weird DNS lookups to freshly registered domains at 3am. Without those logs we'd have had zero visibility into the lateral movement. Also worth adding certificate management to the list, expired internal certs have caused more outages in environments I've audited than actual security incidents.» – ruibranco

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

«>unlocked server rooms, no visitor logs SMBs don't have server rooms. We have server closets that you can't fit into lmao» – TheJesusGuy

Здесь высмеивается реальность небольших компаний: «серверные комнаты» часто представляют собой небольшие шкафы, но физическая защита всё равно важна.

«Since I got many messages requesting the templates, I've put them here: riskbits[.]net/templates, I hope this comment won't bring the post down or get me banned, wish me good luck!» – Arch0ne

Автор делится готовыми шаблонами, что подтверждает практическую ценность чек‑листов.

Возможные решения и рекомендации

1. Внедрить чек‑лист аудита – использовать готовый шаблон (например, из комментария Arch0ne) и адаптировать под свою инфраструктуру.
2. Автоматизировать проверку правил файрвола – скрипты, которые ищут «any/any», неиспользуемые правила и правила старше 2 лет.
3. Включить MFA на всех критических сервисах – VPN, RDP, облачные админ‑порталы, почту.
4. Регулярно тестировать восстановление из резервных копий – минимум раз в квартал, проверяя не только наличие, но и возможность восстановления.
5. Внедрить логирование DNS и egress‑фильтрацию – использовать решения типа Cisco Umbrella или открытые альтернативы (Pi-hole с логированием).
6. Сегментировать сеть – отделить рабочие станции, серверы, гостевой Wi‑Fi и системы управления.
7. Обеспечить физическую безопасность – замки, видеонаблюдение, журнал посещений даже для небольших шкафов.
8. Управление сервисными учётными записями – менять пароли минимум раз в 90 дней, хранить их в менеджере секретов.
9. Проводить обучение персонала – фишинг‑тренинги, правила работы с USB‑устройствами.
10. Отслеживать RTO/RPO – согласовать с бизнес‑руководством и регулярно проверять соответствие.

Прогноз развития ситуации

С учётом роста количества удалённых сотрудников и ускоренного перехода к облачным сервисам, в ближайшие 3‑5 лет мы увидим усиление требований к MFA и к защите VPN‑концентраторов. Появятся более доступные решения для автоматизации аудита (SaaS‑платформы, которые сканируют правила файрвола и генерируют отчёты). Кроме того, законодательные инициативы (например, российский закон о защите персональных данных) будут требовать от SMB доказательства наличия резервных копий и их тестирования, что сделает процесс аудита обязательным, а не добровольным.

Практический пример кода на Python

Ниже – простой скрипт, который подключается к файрволу Cisco ASA (через SSH), получает список правил и ищет потенциально опасные «any/any». Скрипт легко адаптировать под другие устройства, заменив команду получения правил.

import paramiko
import re

def get_firewall_rules(host: str, username: str, password: str) -> list:
    """
    Подключается к файрволу по SSH и возвращает список правил в виде словарей.
    
    Args:
        host: IP‑адрес или DNS‑имя устройства.
        username: Имя пользователя с правами чтения конфигурации.
        password: Пароль пользователя.
    
    Returns:
        Список правил, где каждое правило – словарь с полями protocol, src, dst, port.
    """
    # Создаём SSH‑клиент
    client = paramiko.SSHClient()
    client.set_missing_host_key_policy(paramiko.AutoAddPolicy())
    client.connect(hostname=host, username=username, password=password, timeout=10)

    # Выполняем команду, выводящую правила (для ASA это 'show access-list')
    stdin, stdout, stderr = client.exec_command('show access-list')
    output = stdout.read().decode('utf-8')
    client.close()

    rules = []
    # Пример строки правила: access-list outside_access_in extended permit tcp any any eq 80
    pattern = re.compile(
        r'access-list\s+\S+\s+extended\s+(permit|deny)\s+(\S+)\s+(\S+)\s+(\S+)\s+eq\s+(\d+)', re.IGNORECASE)

    for line in output.splitlines():
        match = pattern.search(line)
        if match:
            action, protocol, src, dst, port = match.groups()
            rules.append({
                'action': action.lower(),
                'protocol': protocol.lower(),
                'src': src.lower(),
                'dst': dst.lower(),
                'port': port
            })
    return rules

def find_any_any_rules(rules: list) -> list:
    """
    Ищет правила, где указаны любые протоколы и любые порты.
    
    Args:
        rules: Список правил, полученных из функции get_firewall_rules.
    
    Returns:
        Список подозрительных правил.
    """
    suspicious = []
    for rule in rules:
        if rule['protocol'] == 'any' and rule['port'] == 'any':
            suspicious.append(rule)
    return suspicious

# ------------------- Пример использования -------------------
if __name__ == '__main__':
    # Параметры подключения (в реальном проекте лучше хранить в безопасном хранилище)
    HOST = '192.0.2.10'
    USER = 'audit_user'
    PASS = 'StrongP@ssw0rd!'

    all_rules = get_firewall_rules(HOST, USER, PASS)
    risky_rules = find_any_any_rules(all_rules)

    if risky_rules:
        print('Найдены потенциально опасные правила any/any:')
        for r in risky_rules:
            print(f"{r['action'].upper()} {r['protocol'].upper()} {r['src']} -> {r['dst']}:{r['port']}")
    else:
        print('Опасных правил any/any не обнаружено.')

Скрипт демонстрирует, как автоматизировать один из пунктов аудита – проверку правил файрвола на наличие «any/any». Его можно расширить, добавив проверку возраста правила, поиск неиспользуемых записей и генерацию отчёта в формате CSV.