Системное администрирование *

Если вы когда-либо выставляли сервис в интернет и смотрели на логи — вы знаете, что происходит в первые минуты. Сканеры, боты, перебор паролей. Firewall помогает, но не всегда. VPN — хорошо, но не всегда удобно и сами протоколы в России к примеру хорошо работают. А что если сервер будет просто отказывать в соединении всем, у кого нет нужного криптографического сертификата — ещё до того, как они увидят страницу логина? Это и есть mTLS.

В статье разберём: что такое mTLS и как работает рукопожатие, как это связано с Zero Trust, от каких атак защищает и где принципиально бессилен, какие риски несёт сама PKI-инфраструктура и где чаще всего ошибаются при реализации. В конце — практика: как мы в Opensophy сделали mtls.sh, bash-скрипт для управления mTLS-сертификатами под Traefik, и почему архитектура «промежуточный CA на каждого клиента» позволяет мгновенно отзывать доступ без CRL и OCSP в Traefik.

Статья будет полезна всем, кто хочет защитить свои сервисы — будь то домашняя лаборатория, панели управления вроде Proxmox или Portainer/Dokploy, внутренние API или любой сервис, который не должен быть доступен всем подряд. Если коротко: если вы выставляете что-то в интернет и не хотите, чтобы туда мог зайти кто угодно — mTLS для этого и существует.

Господа подрядчики, интеграторы, техподдерживатели, к вам обращаюсь. Возможно приходилось сталкиваться с ситуацией, когда надо срочно причинить немного добра, но для этого кровь из носу нужен дамп транзитного трафика. Некоторые вендоры позволяют через cli снифануть и записать результат в файлик *.cap прям на флешку маршрутизатора. А вот дальше проблема: доступа по FTP/SFTP/SCP к файловой системе нет, а счастье-то вот оно лежит, руку протяни, но достать не получается.

Петров уволился, ноутбук исчез. На складе соседнего офиса нашли 12 нераспакованных ноутбуков. При инвентаризации обнаружили сервер, о котором никто не знал. Знакомо? Разбираем, почему Excel и 1С не справляются с учётом оборудования при росте компании и как выглядит нормальный процесс — с пошаговым планом перехода.

Разбираем настройку отказоустойчивого балансировщика 3proxy для n8n в Docker. Фиксим DNS-затупы на 26 секунд через внутренний резолвер 127.0.0.11 и решаем проблему Permission denied внутри контейнера через запуск от пользователя 0:0. Внутри — готовый docker-compose и конфиг для балансировки пула внешних прокси.

У меня дома стоит роутер Keenetic с USB-диском на 2 ТБ. Долгое время он работал просто как сетевое хранилище — файлы лежат, Transmission на роутере крутится, всё вроде бы работает. Но дефолтный интерфейс Transmission выглядит как привет из 2009 года, управлять им с телефона неудобно, а посмотреть скачанное на телевизоре — вообще отдельный квест.

Однажды вечером решил это исправить. Итог — три Docker-контейнера, которые поднимаются одной командой, и теперь выглядит это так:

Некоторое время назад я был участником команды, реализующей решение, на базе которого можно развернуть internal development platform. В первую очередь мы ориентировались на крупный enterprise с командами разработки от 150 человек, которым важны унификация, контроль, снижение когнитивной нагрузки на команды, безопасная разработка и т.д. Сегодня же хотел бы поделиться своими рассуждениями о платформах разработки немного под другим углом — не с учётом команд и процессов разработки (IDP всё-таки заточены в первую очередь решать проблемы в этой области), а с точки зрения зрелости самого разрабатываемого решения. 

Эта статья — попытка порассуждать о существующих платформах разработки для самых маленьких и не только через призму эволюции создаваемого продукта в контексте его постепенного развития от прототипа до полноценного Enterprise-решения с сотнями клиентов. Разберу какие решения могут быть использованы на том или ином этапе развития, сделаю небольшой вывод и задам свои вопросы.

Контента по информационной безопасности стало много. Проблема в том, что количество давно перестало означать качество. Большинство материалов твердит, что «угрозы растут» и «защита необходима», но почти не отвечает на главный вопрос - как именно работает атака. Получается странная ситуация. Информации много, понимания мало.

Идея SEBERD IT Base появилась как попытка это исправить. Не через очередную подборку новостей или пересказ документации, а через разбор механики. Того, что происходит внутри атаки на уровне действий, протоколов и логики.

Про главные страницы и почему я не стал делать обычную

Честно говоря, я никогда не читаю главные страницы сайтов. Совсем. Мне нужна конкретная информация. Я открываю поиск, иду по прямой ссылке или через навигацию. Главная страница большинства проектов - маркетинговый буклет для тех, кто ещё не решил, нужен ли ему этот сайт вообще. Красивый заголовок, три иконки с преимуществами, кнопка «Начать» и раздел «Нам доверяют».

Я решил не делать такой главной. Вместо неё стоит живая лента угроз. Это агрегатор, который тянет актуальные данные через RSS и API с десятка источников. Он работает с лентами в форматах RSS/Atom и структурированными ответами сервисов, а не парсит чужой HTML вручную.

Источники:

И снова здравствуйте. В прошлый раз мы подробно разбирали технологию частотной синхронизации SyncE, в позапрошлый пробежались по верхушкам профиля G.8275.2 ATR. Сегодня же с интересом будем препарировать никем неиспользуемый базовый протокол IEEE 1588v2 или PTPv2 Default Profile. Планируется много любопытного: поностальгируем о былых деньках, натянем STP на маршрутизаторы, всем миром извинимся перед афроамериканцами, заглянем в миллион дампов, устанем смотреть картинки, как следует изучим всю матчасть, поднаберемся нужных словечек, чтобы уже в следующем акте со всей необходимой теоретической базой че-нить куда-нить внедрить и даже по траблшутить.

Я технический лидер. Обычно моя работа не в том, чтобы писать код руками, а в том, чтобы запускать сложные hardware/software-проекты с нуля, собирать архитектуру, принимать ключевые технические решения, выстраивать команду и доводить систему до MVP в условиях неопределённости.

Я работаю на стыке механики, электроники, разработки и AI, связывая это в единый контур.

При этом я не владею языками программирования как разработчик.

Именно поэтому этот проект оказался для меня особенно интересным. Это был не просто внутренний бот, а практический эксперимент: можно ли, оставаясь в роли техлида и архитектора, собрать рабочий software-продукт через агентную разработку, не теряя в качестве решений, управляемости и инженерном здравом смысле.

Короткий ответ: да, можно.

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

Любой инфраструктурный проект, будь то внедрение системы виртуализации, миграция со статической маршрутизации на динамическую, разработка модуля 1С или даже ремонт в квартире является проектом, который нужно структурировать, чтобы ответить на вопросы «что мне сделать?», «зачем мне это делать?», «что я хочу увидеть в конечном результате?» и только после этого «как мне это сделать, чтобы ничего не сломать?». В противном случае получится ситуация из анекдота «… один сломал, второй потерял…» и наш проект останется далеким от желаемого результата.

Таким образом мы подходим к пониманию основных этапов ИТ-проектирования.

DNS — неотъемлемая и очень важная часть инфраструктуры, о которой иногда забывают. Порой её воспринимают как нечто само собой разумеющееся, что просто всегда есть и работает. Вспоминают о ней обычно при странных багах, которые сложно диагностировать, или авариях, которые рушат всю инфраструктуру на часы.

Некоторое время назад я добрался до задачи рефакторинга DNS инфраструктуры — чтобы сделать её проще, удобнее и надежнее. В этой статье я хочу поделиться своим опытом и расскажу, как у нас получилось сделать внутренний распределенный DNS и управлять им как кодом.

Иногда случается такая задача: за непродолжительное время нужно проверить или продемонстрировать работу сетевого оборудования с авторизацией через tacacs. На стенде, с не очень большим количеством устройств (в пределах пары десятков). Но на вопрос про «подключение виртуалки с tacacs+» выясняется, что в текущих реалиях – никак. А вариант «оставить на пару недель свой ноут» (на котором есть VmWare WS с нужной виртуалкой) ну совсем не прельщает.

Эта статья описывает, как внедрить TACACS.NET на Windows в рамках стенда: от базовой настройки до проверки работоспособности и типовых моментов, которые всплывают при первом запуске. Ориентирована на системных инженеров и администраторов, которым нужно быстро перейти от «чистого Windows» к конфигурации для работы на стенде.

В современной ИТ-инфраструктуре источники событий разрознены: firewall, серверы, АРМ, облако – все они формируют собственные потоки данных. Уже на их основе можно создать единую картину киберинцендента. Для этой задачи подойдет SIEM-система (Security Information and Event Management). Она помогает объединять логи в единое окно контроля, коррелировать разрозненные события и выявлять скрытые атаки, которые невозможно заметить при изолированном анализе. В итоге вместо хаотичных данных команда получает основу для оперативного реагирования и соблюдения регуляторных требований.

Однако нередко после внедрения SIEM превращается в дорогостоящее хранилище логов, которое не подвергается анализу со стороны командой. В этом материале ответим на несколько вопросов о данном типе решений: кому и зачем оно нужно, как правильно настроить систему и как определить ее эффективность. Подробнее расскажет Илья Куриленко, заместитель генерального директора по развитию компании «Анлим», центра компетенций по информационной безопасности.

Привет, Хабр! Меня зовут Алексей, и я продолжаю копаться в беспроводных технологиях. В прошлый раз мы настраивали Wi-Fi в OpenWrt для максимальной стабильности и покрытия. Сегодня я хочу поговорить о другой, не менее увлекательной теме - мониторинге беспроводного эфира с помощью легедарного роутера TP-Link MR3020.Многие скажут: «Зачем мне это? У меня и так всё работает». А я отвечу: возможности, которые открываются, могут удивить. Давайте сразу к делу.

В апреле 2026 года мы выпускаем обновление Ideco NGFW Novum. Это плановый релиз, в котором развиваются пять направлений: централизованное управление, защита DNS, управление удалённым доступом, SD-WAN и кластеризация. Ниже разбираем, что именно изменилось и какие задачи это решает.

Привет, друзья!  В начале года на Хабре проходил конкурс Heavy Digital: авторы рассказывали о том, как IT помогают заводам, где «трубы дымят и мужики в куртках бегают». Строительная отрасль – не менее heavy, здесь мужики в касках укладывают бетон и забивают сваи под фундамент. А еще всю проектную документацию при подаче на госэкспертизу теперь надо подписывать усиленной квалифицированной электронной подписью (УКЭП), и это серьёзная IT-задача.

В статье я подготовил подробную инструкцию для всех этапов: как настроить систему документооборота, установить  криптопровайдер, получить сертификат УКЭП и подписать документ.

Меня зовут Сергей Усов. В Газпромбанке я в составе небольшой команды занимаюсь развитием и сопровождением корпоративной BI-системы на базе решения Sigla Vision (российский форк FineBI).

Мы хотим поделиться практическими наработками с сообществом пользователей Sigla Vision / FineBI — сделать работу с системой удобнее и облегчить жизнь администраторам. При этом часть наших подходов может пригодиться и тем ИТ-специалистам (разработчикам, дата-инженерам, аналитикам), которые сопровождают работу технических систем, имеющих в своем составе БД с репозиториями метаданных. Описанные решения являются общеинженерными и могут быть применены не только к корпоративным аналитическим системам.

Это первая статья из цикла, посвященного нашему опыту администрирования Sigla Vision.

Релиз nxs-universal-chart 2.8.3 был более двух лет назад и за это время многое поменялось: Ingress Nginx ушел на покой, GitOps по факту стал стандартом управления инфраструктурой, а AI все сильнее входит в наши жизни. Все эти изменения не могли пройти мимо и заставили нас задуматься о том, как адаптировать наши подход и технологии DevOps к вызовам нового времени.

Результатом этих размышлений стал релиз новой версия nxs-universal-chart v3.x: из универсального набора встроенных шаблонов мы постарались превратить его в модульную платформу для поставки приложений в Kubernetes с упором на надежность и современные практики CI/CD процессов.

Всем привет, на связи Пётр, инженер компании Nixys и по совместительству maintainer проекта nxs-universal-chart. В этой статье я расскажу как мы переработали изначальную идею и какие нововведения в чарте это за собой повлекло.

В распределенной системе понять, что именно произошло во время выполнения запроса, бывает сложнее, чем исправить саму ошибку. Логи показывают события по отдельности, метрики — общую динамику, но без связки между ними картина остается фрагментарной. Мы решили выстроить наблюдаемость на базе OpenTelemetry и использовать Sentry для анализа трейсов.

Микросервисная архитектура решает проблему масштабируемости, но почти всегда создает новую — потерю прозрачности. Один пользовательский запрос может пройти через десяток сервисов, очереди, сторонние API и фоновые процессы. Если где-то возникает ошибка, найти ее источник без полноценной трассировки — задача на часы, а иногда и на дни.

Чтобы избежать этого, мы выстраиваем связку OpenTelemetry + Sentry. OpenTelemetry позволяет стандартизировать сбор телеметрии, а Sentry — централизовать ее анализ. В результате появляется целостная картина работы системы.

Введение в OpenTelemetry: traces, metrics, logs

OpenTelemetry объединяет три типа телеметрии — логи, метрики и трейсы — и задает для них спецификации.

Трассировки. Трейс показывает, как выполнялся конкретный пользовательский запрос. Запрос разбивается на шаги, каждый шаг в терминологии трассировки называется span, они фиксируются с указанием времени начала и окончания. В итоге можно увидеть не просто факт ошибки, а последовательность действий, которая к ней привела.

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

Один AI-агент может закрывать работу одного специалиста. Следующий шаг - собрать из таких агентов конвейер.

Pipeline Triad Pattern - это модель enterprise-разработки, где каждый этап SDLC проходит через тройку ролей: Создатель, Критик, Арбитр. Не один “суперагент”, а цепочка специализированных троек с человеческим контролем в нескольких ключевых точках.

Рассказываю, как устроен такой конвейер, чем он отличается от CI/CD, сколько стоит и где у него реальные пределы.