Защита Linux-сервера компании: что обязан знать IT-директор офиса до 50 рабочих мест

Привет! Меня зовут Семёнов Евгений Сергеевич, и я директор АйТи Фреш. Уже пятнадцать лет я, что называется, «вожусь» с серверами московских компаний. Важно понимать, эта статья не для системных администраторов, а скорее для IT-директора или собственника бизнеса. Если вы арендуете VPS под 1С, корпоративный сайт или почту, вам будет полезно разобраться, на какие моменты должен обращать внимание ваш подрядчик. Здесь не будет сложных кодовых листингов, только конкретика, чтобы вы могли задавать правильные вопросы и не попасть в ситуацию, когда хостер вдруг блокирует ваш сервер за рассылку спама.

Зачем эта статья руководителю, а не сисадмину

Только за последние два года мне четыре раза звонили IT-директора крупных клиентов — и каждый раз в панике, с одним и тем же вопросом: «Хостер прислал письмо, что наш сервер участвует в ботнете, что делать?». В трёх случаях из четырёх причина оказалась до банальности проста: VPS был арендован два года назад, его кто-то настроил «на скорую руку», а потом про него просто забыли. Никто не занимался обновлением пакетов, не проверял логи, не следил, что кто-то уже успел проникнуть туда через элементарную уязвимость в плагине WordPress.

Знаете, я глубоко убеждён: IT-директор совсем не обязан знать, как настроить sshd_config. Но вот что он точно обязан — это понимать, какие вопросы задать своему подрядчику и как убедиться, что работа действительно выполнена. Иначе получается так: вы платите за абонентку, а когда наступает «момент истины», выясняется, что на сервере нет ни бэкапов, ни мониторинга, ни актуальных обновлений. По сути, это просто услуга на бумаге, и ничего больше.

Из чего состоит правильная защита Linux-сервера

Hardening — это такой профессиональный термин, по-русски его называют «укрепление». Но это не какая-то одна волшебная кнопка в панели управления. Это целый комплекс, состоящий из 7–8 шагов. Я сейчас простыми словами расскажу вам, что входит в каждый из них и почему это так важно для вашего бизнеса.

Когда я приезжаю к новым клиентам на аудит и начинаю спрашивать об этих 8 пунктах, то, честно говоря, в среднем 5–6 из них либо вообще отсутствуют, либо сделаны «для галочки». Самое, наверное, больное место — это бэкапы. Я уже даже не припомню, когда в последний раз видел реально работающий бэкап с полноценной проверкой восстановления у клиента, который пришёл ко мне «на аудит». Все, конечно, говорят, что бэкап есть, но стоит попросить восстановить, скажем, файл недельной давности — и тут же выясняется: архив битый, или его вообще нет, или к нему отсутствует пароль.

SSH — главная дверь, через которую угоняют серверы

SSH, или Secure Shell, — это такой протокол, через который администратор подключается к серверу, чтобы управлять им. По умолчанию он «торчит» наружу в интернет на 22 порту, и будьте уверены, каждые 5 минут к нему ломятся боты со всего мира, пытаясь подобрать популярные пароли. На сервере, который не был должным образом подготовлен, я регулярно вижу от 10 до 15 тысяч попыток входа в сутки. Это очень много!

Что ваш подрядчик должен сделать с SSH:

• Запретить вход под root. У root неограниченные права, и если бот его подберёт — вы потеряли всё. Должен быть отдельный пользователь с правами повышения привилегий.
• Отключить вход по паролю. Только по ключу — это длинный криптографический файл, который перебрать невозможно за разумное время.
• Сменить порт (опционально). Не защита, но фильтр шума: 95% автоматических ботов сканируют только 22 порт.
• Ограничить список пользователей, которые в принципе могут подключаться по SSH. Не админ — не входишь.

Вот вам простая, но очень показательная проверка для IT-директора: попросите своего подрядчика показать количество SSH-логинов в логе за последний день. Если вы видите там только логины админов вашей компании — отлично! А вот если там мелькают сотни странных IP-адресов из Китая, Бразилии или Нидерландов — это тревожный звоночек: ваш SSH явно не защищён.

Файрвол: что слушает сервер из интернета

Знаете, каждая открытая дверь — это всегда потенциальная уязвимость. Ваш сервер должен слушать только те порты, которые действительно необходимы для его нормальной работы:

• 80 и 443 — для веб-сервера, если на нём сайт.
• SSH — для админов, желательно только из вашей офисной сети.
• 1С-порт (если сервер 1С) — только из локальной сети или VPN.
• Почтовые порты 25, 465, 587, 993 — только если сервер реально отдаёт почту.

В прошлом году у одного моего клиента, стоматологической клиники, я обнаружил на их веб-сервере открытый порт 27017. Это была база MongoDB без пароля! Оказалось, кто-то из бывших разработчиков когда-то поднял её для тестов и благополучно забыл закрыть. В итоге через неё произошла утечка персональных данных 4000 пациентов клиники. К счастью, мы успели всё закрыть до того, как об этом узнал Роскомнадзор, иначе штраф мог составить до 500 000 рублей согласно 152-ФЗ.

Обязательно запросите у подрядчика результат проверки открытых портов с внешнего IP. Обычно такой отчёт умещается на одной странице. Если в этом списке найдётся что-то непонятное — не стесняйтесь, задавайте вопросы!

Автоматические обновления: единственный способ не отстать от хакеров

Регулярно в любом софте обнаруживаются уязвимости. Разработчики выпускают патч, и буквально в течение 24–72 часов автоматические сканеры уже начинают пробовать атаковать всех, кто ещё не успел обновиться. Если ваш подрядчик обновляет серверы вручную и делает это раз в квартал, то между выходом патча и его установкой может пройти до 90 дней. И весь этот огромный временной промежуток вы остаётесь совершенно беззащитными.

Правильная схема: unattended-upgrades на Debian/Ubuntu — это встроенный механизм, который скачивает и применяет обновления безопасности автоматически каждую ночь. Настроил один раз — дальше работает. Раз в неделю мне на почту падает отчёт, какие пакеты обновились на каждом сервере клиентов; просматриваю за две минуты и сплю спокойно.

Вот вам контрольный вопрос для подрядчика: «Какая средняя задержка между выходом security-патча и его установкой на наш сервер?». Если вам ответят, что больше суток — у вас, к сожалению, проблема.

Бэкапы: единственное, что спасёт после взлома

Представьте: ваш сервер взломали, скомпрометировали, или, что ещё хуже, зашифровали ransomware-вирусом. В такой ситуации у вас, по сути, остаётся только один путь: уничтожить сервер и развернуть всё заново, используя бэкап. Именно поэтому бэкап обязательно должен соответствовать «правилу 3-2-1»:

• 3 копии данных — рабочая база и две резервных.
• 2 разных носителя — например, внутренний диск сервера и внешний S3-хранилище.
• 1 копия офсайт — то есть физически в другом ЦОДе или регионе.

В АйТи Фреш мы подходим к делу серьёзно: для каждого клиентского сервера мы создаём целых три типа бэкапов. Первый — инкрементный, делается каждый час и хранится 24 часа. Второй — ежедневный, его мы храним 30 дней. И третий — ежемесячный, который остаётся у нас целый год. Кроме того, раз в квартал я лично провожу настоящие учения по восстановлению: просто беру случайный сервер из списка наших клиентов и проверяю, что бэкап действительно работает и данные восстанавливаются. За 15 лет моей практики я полностью восстанавливал клиентские системы 14 раз. Последний такой случай был в феврале 2026-го, когда у одной юридической фирмы шифровальщик «зацепил» файловый сервер. Мы справились: восстановили всё за 2 часа 40 минут, при этом потеря данных составила всего 35 минут (это время от последнего инкремента до момента шифрования).

Мониторинг: чтобы узнавать о проблемах раньше клиентов

Сервер без мониторинга — это чистой воды игра в русскую рулетку. Вы узнаете о том, что сайт «лёг», только тогда, когда вам позвонит первый разозлённый клиент. Правильная конфигурация — это когда настроены Zabbix или Prometheus + Grafana. Они собирают метрики каждые 30 секунд и, как только что-то идёт не так, немедленно шлют алерт в Telegram.

За чем мониторинг должен следить как минимум:

• Доступность сервера (ping каждую минуту с двух разных точек).
• Загрузка CPU, RAM, диска (алерт при 85%).
• Доступность ключевых сервисов (HTTPS, 1С, почта).
• Состояние бэкапов (был ли последний бэкап, и его размер).
• Сертификаты SSL (алерт за 14 дней до истечения).
• Подозрительная активность (резкий рост трафика, странные процессы).

Помню, одному клиенту в 2025 году я настроил алерт на резкий рост исходящего трафика. И вот, спустя три месяца, ночью мне прилетает сообщение в Telegram — сервер «льёт» наружу 500 Мбит/с! Я тут же зашёл, посмотрел и увидел: кто-то через уязвимость в старом плагине загрузил скрипт DDoS-атаки. Я оперативно остановил процесс, всё почистил и накатил патчи. Клиент даже не заметил, что у него что-то произошло. А без мониторинга мы бы узнали об этом, скорее всего, из письма хостера, где был бы счёт за перерасход трафика на 80 000 рублей.

Реальная цена защиты — гораздо меньше, чем цена восстановления

По моей практике, средний счёт за восстановление после серьёзного инцидента — будь то компрометация, ransomware или утечка данных — для офиса до 50 рабочих мест обычно колеблется от 250 000 до 800 000 рублей. В эту сумму входят расследование инцидента, полная переустановка систем, восстановление из бэкапов, юридические консультации по 152-ФЗ, а иногда даже выкуп ключа дешифрования. И это мы ещё не говорим о репутационных потерях, простое бизнеса и, конечно же, ваших нервах.

Для наглядности давайте сравним: правильная настройка одного VPS обойдётся клиенту разово в 12 000–18 000 рублей, плюс ежемесячно 3 000–5 000 рублей за сопровождение в рамках абонентки. То есть, годовое обслуживание по защите сервера будет стоить примерно 50 000–80 000 рублей. Подумайте об этом: всего один-единственный серьёзный инцидент окупает эту защиту минимум на 5 лет вперёд.

Чек-лист для разговора с вашим подрядчиком

Возьмите эту страницу, распечатайте её и пройдитесь по каждому пункту с тем человеком, который сейчас обслуживает ваши серверы. И вот важный момент: все ответы должны быть письменными. Если ваш специалист уверенно всё рассказывает на словах, но наотрез отказывается прислать скриншоты или отчёты, скажем, в Telegram — это очень плохой знак, имейте в виду.

1. Покажите, что root-логин по SSH запрещён на всех серверах.
2. Покажите список открытых портов с внешнего IP — расскажите, зачем нужен каждый.
3. Какая средняя задержка между выходом security-обновления и его установкой?
4. Покажите последний удачный тест восстановления из бэкапа — с датой и результатом.
5. Покажите дашборд мониторинга — какие метрики собираются, какие алерты настроены.
6. Покажите рейтинг Lynis или аналогичной утилиты аудита (норма — 80+ из 100).
7. Покажите журнал входов в SSH за последний месяц — кто, откуда, когда.

Если хотя бы на один из этих вопросов вы не получите внятного ответа, это значит, что у вас есть риск, и теперь вы об этом знаете. Дальше уже решение за вами: либо вы добавляете эти работы в SLA с текущим подрядчиком, либо начинаете искать другого специалиста, который умеет всё это делать «в стандартной комплектации».

FAQ — частые вопросы IT-директоров

Кто отвечает, если арендованный VPS попал в ботнет?

С точки зрения хостера — арендатор, то есть юрлицо. Хостер просто заблокирует сервер и пришлёт уведомление о нарушении AUP. Финансовая ответственность за рассылку спама или DDoS-участие лежит на компании, поэтому защита сервера — обязанность вашего IT-подрядчика, а не хостера.

Достаточно ли встроенного фаервола хостера?

У большинства московских хостеров (Selectel, Timeweb, RuVDS) есть базовый сетевой фаервол на уровне панели — он закрывает порты на входе. Но он не защищает от компрометации через слабый пароль SSH, уязвимый веб-движок или забытый майнер. Нужен полный комплекс: hardening ОС, fail2ban, автообновления, мониторинг.

Сколько стоит правильная защита одного VPS?

Разовая настройка hardening для одного Debian/Ubuntu сервера под ключ — от 8 000 до 18 000 руб. в зависимости от ролей сервера (просто веб или 1С + почта + БД). Дальнейшее ежемесячное сопровождение в рамках абонентки — 2 500–5 000 руб. за сервер.

Как часто надо обновлять сервер?

Критические обновления безопасности — автоматически в течение суток после выхода. Плановые обновления ОС — раз в квартал с тестированием. Major-апгрейд (например, Debian 11 → 12) — раз в 2–3 года, обязательно с предварительным бэкапом и окном простоя.

Можно ли проверить работу подрядчика, не будучи технарём?

Да. Запросите три отчёта: вывод утилиты Lynis (рейтинг должен быть 80+), список открытых портов на сервере (должно быть только то, что вам нужно — обычно SSH, 80, 443), и журнал последних логинов. Если подрядчик не может это предоставить за 30 минут — он не настраивал hardening.