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

Самая короткая команда для проверки интернета: ping 1.1

Такая запись автоматически преобразуется в 1.0.0.1 Мало кто знает, что по стандарту ipv4 пропущенные октеты преобразуются в нули.

Почему-то это активно используется только в ipv6 типа fe20::baba

Вебинар "Ваша новая гиперконвергентная инфраструктура в 2026 году."

Переходите на гиперконвергентную инфраструктуру с уверенностью. Регистрируйтесь на AMA-сессию о платформе vStack и задайте все вопросы, которые вас волнуют.

Когда: 22 октября в 11.00 (МСК)

Мы поможем разобраться:

➖В чем выгода от внедрения vStack для вашей компании?
➖Чем платформа vStack отличается от конвергентных решений?
➖Как выглядит работа с платформой vStack?

Спикер: руководитель отдела по работе с партнерами Эльдар Новрузов.

Участие бесплатное по предварительной записи.

🔗 ЗАРЕГИСТРИРОВАТЬСЯ

От инцидента к контролю: как «Монитор» для 1С помогает ИТ-директору предупреждать сбои, а не тушить пожары

Что делать, если скорость проведения документов в 1С падает с трёх секунд до десяти минут? Обычно на этом этапе пользователи жалуются, сисадмины ищут узкие места, бизнес теряет время. Но есть и другой сценарий: когда проблему можно поймать до того, как она станет критичной.

14 октября в 12:00 на вебинаре «От инцидента к контролю» разберём, как инструмент «Монитор» для 1С помогает бизнесу предупреждать сбои, а не тушить пожары.

В программе:
— разбор ключевых функций «Монитора» (долгие запросы, блокировки, взаимоблокировки, ошибки технологического журнала, уведомления о событиях);
— демонстрация на реальном кейсе X-Com: «Скорость проведения документов в 1С упала с 3 секунд до 10 минут — как с помощью Монитора нашли проблемные места»;
— ответы экспертов на вопросы участников.

Спикеры:
— Андрей Бурмистров, 1С-эксперт по технологическим вопросам крупных внедрений;
— Леонид Дегтярёв, директор по информационным технологиям X-Com.

Все участники вебинара получат в подарок 30-дневную триал-версию 1С Монитора с бесплатной установкой от наших специалистов.

👉 Регистрируйтесь по ссылке

Просто напоминаю про багбаунти от Selectel с призами до 30 000 рублей

В центре внимания — сам образ, его конфигурация, скрипты для автоматизации, настройки операционной системы и Keycloak. Всё остальное, включая DDoS-атаки, фишинг и внешние угрозы, находится вне рамок мероприятия.

Количество участников ограничено: 30 человек, из которых будут выбраны 3 победителя. Регистрация уже открыта, стартуем в октябре — присоединяйтесь и покажите, на что вы способны! 

Призы:

1 место: 30 000 бонусных рублей

2 место: 20 000 бонусных рублей

3 место: 10 000 бонусных рублей

Как устроено под капотом

Мы сделали образ Keycloak в облаке Selectel. Он содержит docker-compose c Keycloak, Postgres, Nginx и скриптами бэкапов. Настраивается через cloud-init: все подставляется из user-data. Поддержка cron-задач, логика запуска, безопасность по умолчанию. Образ рассчитан на стабильную работу из коробки.

Внутри образа Nginx работает как обратный прокси, Certbot выпускает сертификаты. Есть cron-задачи для обновлений и создания дампов. Закрытые URL’ы, доступ по white-list — ради безопасности админского контура. Настройка происходит автоматически при запуске образа.

Zero Trust: почему мы все делаем это неправильно

За последние три года я и мои знакомые из сферы участвовали во внедрении Zero Trust в 12 компаниях разного масштаба. Пришли к неутешительному выводу: 90% организаций реализуют Zero Trust как более сложную версию VPN. Мы подменяем философию технологиями, забывая о фундаментальных принципах.

Миф об «упрощенной безопасности»

Многие верят, что Zero Trust — это просто замена VPN на ZTNA. На практике мы получаем распределенный VPN с более сложной аутентификацией. Настоящий Zero Trust требует пересмотра архитектуры приложений, а не просто установки шлюза доступа.

Я видел implementations, где:

• Микросервисы общаются через сервис‑меш внутри доверенной сети

• Базы данных остаются в общем сегменте

• Аутентификация сводится к проверке сертификатов

Это не Zero Trust. Это периметровая безопасность с дополнительными факторами аутентификации.

Проблема наследия

Legacy‑системы — главное препятствие для настоящего Zero Trust. Когда 70% бизнес‑логики работает на AS400 и Windows Server 2008, о сегментации на уровне приложений говорить не приходится. Мы создаем костыли: прокси, врапперы, шлюзы — все, что угодно, лишь бы не переписывать системы.

Данные против политик

Самый болезненный момент — управление данными. Zero Trust предполагает, что мы знаем:

• Какие данные где хранятся

• Кто имеет к ним доступ

• Как они перемещаются

В реальности у 80% компаний нет даже базовой классификации данных. Мы строим сложные политики доступа, не понимая, что именно защищаем.

Излюбленный человеческий фактор 2.0))))

Zero Trust не решает проблему социальной инженерии. Фишинг эволюционировал вместе с технологиями. Я наблюдал случаи, когда злоумышленники:

• Обходили MFA через усталость пользователя (push‑уведомления)

• Использовали легитимные OAuth‑приложения

• Крали сессии с доверенных устройств

Технологические разрывы

Рынок инструментов Zero Trust фрагментирован. Мы имеем:

• 5+ стандартов для device attestation

• 3 конкурирующих протокола для ZTNA

• Десятки несовместимых решений для микросегментации

Интеграция превращается в кошмар: Palo Alto Prisma, CrowdStrike Identity, Cisco Duo — каждый тянет одеяло на себя.

Культурный шок

Самое сложное в Zero Trust — изменить мышление команды. Админы привыкли к «доверенным сетям». Разработчики не хотят переписывать auth‑логику. Руководство требует быстрых результатов.

Я видел проекты, где после года внедрения:

• Сотрудники использовали корпоративные устройства для личных нужд

• Админы создавали бэкдоры для «удобства поддержки»

• Руководители требовали исключений из политик

Что в сухом остатке?

Zero Trust — это не продукт и не проект. Это бесконечный процесс переосмысления безопасности. Успешные implementations, которые я наблюдал, имели общие черты:

• Поэтапный переход (3-5 лет)

• Глубокая модернизация инфраструктуры

• Изменение процессов, а не только технологий

• Постоянное обучение и тестирование

Мы должны признать: не каждой компании нужен «полный» Zero Trust. Иногда достаточно микросегментации критических активов и строгого контроля доступа. Гонка за модным термином не должна подменять собой здравый смысл.

Сегодня я скорее рекомендую «Zero Trust mindset», чем конкретные технологии. Начинать стоит с инвентаризации активов, классификации данных и построения карты потоков. Технологии — вторичны.

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

Собственный VDI и протокол: подробности

Привет, Хабр! Мы расширяем портфель решений — теперь в нашей экосистеме есть новая функциональность виртуализации рабочих столов и приложений (VDI) в рамках интеграции продуктов zVirt и Termit. Благодаря ей заказчики могут прямо в пользовательском интерфейсе Termit настроить автоматическое создание групп виртуальных рабочих мест из шаблона. 

Это стало возможно благодаря глубокой интеграции с системой виртуализации zVirt. В интерфейсе Termit можно настроить сопряжение с zVirt, там же создать группу виртуальных рабочих мест, и в нее автоматически будут добавляться виртуальные машины, создаваемые в zVirt по заданному шаблону — “золотому образу”. Они также автоматически будут вводиться в домен. На стороне виртуализации нужно только настроить “золотой образ”, все остальные операции можно совершать в интерфейсе Termit.

VDI в наших продуктах обеспечивает возможность создания как сессионных, так и персонализированных виртуальных машин, а также поддерживает кроссплатформенность, многофакторную аутентификацию и SSO, протоколы X2Go, RDP и Loudplay, перенаправление устройств, различные ОС: Windows, Astra Linux, РЕД ОС, ОС Альт. Функциональность представлена как отдельно в рамках продукта Termit, так и в новом модуле платформы виртуализации zVirt Apps and Desktops.

Среди других обновлений релиза Termit 2.4 — улучшение пользовательского опыта и усиление безопасности. В частности, появилась возможность настройки перемещаемых профилей для Linux. Теперь, когда пользователь отключается от рабочего стола, все его актуальные настройки и изменения остаются в удаленном хранилище и при следующем подключении перемещаются за пользователем на новый сервер или виртуальную машину. Это позволяет сохранять единое рабочее окружение для сотрудников и снижает количество обращений в техподдержку.  

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

Кроме того, мы начали разработку собственного протокола доставки удаленного рабочего стола и терминального доступа. Он будет реализован внутренними силами и без использования Open Source.

Мы изучили существующие на рынке разработки и патенты, наняли сильных специалистов и в этом году начали разработку собственного протокола. Мы пишем его сами, не используем ни X2Go, ни SPICE, ни FreeRDP. Это в первую очередь UDP, но одновременно будет реализована и поддержка TCP. В протоколе “из коробки” будет поддержка виртуальных каналов и мультисессионности.

Бессерверные вычисления: почему ваш код может стать заложником провайдера

Бессерверная архитектура обещает не думать об инфраструктуре, но скрывает риски vendor lock-in, которые проявятся слишком поздно. Пока вы наслаждаетесь отсутствием серверов, ваша бизнес-логика медленно превращается в заложника облачного провайдера.

Проблема:

• Cold start в критичных приложениях достигает 10-15 секунд

• Стоимость непредсказуема при скачках нагрузки

• Локальная разработка и отладка превращаются в квест

Реальные кейсы:

python

# Проблема: разрыв между продакшеном и локальной средой
def lambda_handler(event, context):
    # На локальной машине работает
    # В AWS Lambda падает с таймаутом
    return expensive_operation()  # 25+ секунд

Что мониторим в бессерверной среде:

1. Performance

   • Холодные/горячие старты

   • Потребление памяти

   • Execution duration

2. Безопасность

   • Права IAM-ролей

   • Доступ к секретам

   • Цепочки вызовов функций

3. Экономика

   • Стоимость вызова

   • Количество параллельных исполнений

   • Использование сторонних сервисов

Когда бессервер оправдан:

• Обработка событий с неравномерной нагрузкой

• Фоновые задачи (генерация отчетов, ночные джобы)

• API с низким RPS

Альтернативы:

• Kubernetes + Knative — гибридный подход

• Cloudflare Workers — edge-вычисления

• Self-hosted FaaS — полный контроль

Вывод:
Бессерверные технологии — мощный инструмент, но требуют тщательного проектирования и постоянного мониторинга затрат. Прежде чем погружаться в serverless, оцените, готовы ли вы к зависимости от вендора и непредсказуемым расходам.

ITAMday 2025: играем и выигрываем с «Инферит ИТМен»

Привет, Хабр! 👋
Меня зовут Данила Трусов, я директор продукта «Инферит ИТМен».

31 октября в Москве пройдет юбилейная X конференция ITAMday 2025 — ключевое событие для специалистов по управлению ИТ-активами. Ежегодно она собирает сотни практиков и экспертов, чтобы обсудить лучшие кейсы, обменяться опытом и взглянуть в будущее индустрии.

В этом году я выступлю с докладом «Агрегация — это еще не все: почему рынку требуется отдельный класс инструментов дискаверинга с гибкой настройкой под любую инфраструктуру в 2025–2028 годах».

Мы разберем:

• почему российские вендоры и аналитики делают ставку именно на дискаверинг, а не на простую агрегацию;

• зачем отдельный класс решений по дискаверингу необходим для ITSM/ ITAM/ SAM;

• какие подходы позволяют добиться 100% прозрачности и безопасности инфраструктуры;

• на что обратить внимание при выборе и настройке решений enterprise-уровня;

• как сохранить мультивендорность при контроле ИТ-ландшафта.

А еще мы подготовили для участников активность от «Инферит ИТМен» — динамичный онлайн-квиз. Проверите знания, получите драйв и сможете выиграть крутые призы:

🎁 Главный приз — ноутбук бизнес-класса INFERIT Mercury 15.6" i5-1334U
🥈 Подарки за второе и третье место
📸 Отдельный приз победителю фотоконкурса

ITAMday — это не только про доклады и нетворкинг, но и про живые впечатления. Будет азартно, полезно и кто-то уйдет домой с ноутбуком под мышкой 😉

📅 Когда: 31 октября 2025
📍 Где: Radisson Blu Олимпийский, Москва

Жду вас на ITAMday 2025 — на своем докладе и в квизе от «Инферит ИТМен»!

Контейнеры не панацея: скрытые затраты на содержание Kubernetes, о которых молчат вендоры

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

Что не учитывают при внедрении:

• Эффективность нод: В среднем 35-40% ресурсов простаивают "на всякий случай"

• Стоимость сетей: Service mesh + CNI добавляют 15-20% к потреблению CPU

• Трудозатраты: 1 инженер на 3-5 кластеров — утопия для средних компаний

Реальные метрики из практики:

bash

# Анализ утилизации за 3 месяца
kubectl top nodes | awk '{sum += $3} END {print "Средняя загрузка:", sum/NR "%"}'
# Результат: 41% по CPU, 28% по памяти

Где теряем деньги:

1. Overprovisioning
   "На всякий случай" развертываем на 200% больше ресурсов

2. Сложность мониторинга
   Требуется отдельный стек: Prometheus + Grafana + Alertmanager

3. Безопасность
   Pod Security Policies, network policies — +20% к времени развертывания

Когда Kubernetes оправдан:

• 50+ микросервисов

• Непредсказуемая нагрузка

• Команда из 3+ DevOps инженеров

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

• Nomad — проще оркестратор без привязки к контейнерам

• Docker Swarm — для простых сценариев

• Managed k8s — если нет своей экспертизы

Вывод:
Kubernetes — мощный инструмент, но не серебряная пуля. Прежде чем прыгать в эту экосистему, посчитайте TCO и убедитесь, что сложность управления не съест всю экономию от контейнеризации.

#Kubernetes #DevOps #контейнеризация #TCO #микросервисы

А как у вас с реальной утилизацией ресурсов в k8s? Делитесь наблюдениями в комментариях.

Записки параноика: почему Zero Trust — это не мода, а новая реальность для ИТ-инфраструктуры

Современные угрозы больше не останавливаются на периметре. Атаки стали целевыми, изощренными и часто исходят изнутри. Традиционный подход «замок и ров» безнадежно устарел.

Почему Zero Trust — это не просто buzzword:

• 68% компаний сталкивались с инцидентами внутренних угроз

• Среднее время обнаружения нарушителя в сети — 207 дней

• Традиционные VPN стали главным вектором атак в 2024

Как мы внедряли Zero Trust без переписывания всей инфраструктуры:

Сегментация на микроуровне:

yaml

# Instead of: Allow 10.0.0.0/8
# We use: 
- name: db-access
  source: app-server-01
  destination: postgres-01
  port: 5432
  auth: mTLS + service-account

Service Mesh вместо VPN:

• Istio для взаимной аутентификации сервисов

• Автоматическое шифрование всего трафика

• Детальный контроль доступа на уровне L7
  
  Непрерывная верификация:

bash

# Проверка целостности хостов каждые 30 сек
sudo attestation-agent verify --policy strict

Технические вызовы, с которыми столкнулись:

• Производительность: Overhead Istio ~3ms на hop

• Сложность отладки: Трассировка запросов через 5+ сервисов

• Миграция: Постепенный перенос legacy-систем

Метрики после 6 месяцев работы:

• Время сдерживания атаки сократилось с часов до минут

• Количество инцидентов снизилось на 73%

• Audit trail для compliance стал детализированным

Ключевые инсайты:

1. Начинайте с идентификации — без точной инвентаризации сервисов ничего не выйдет

2. Поэтапное внедрение — от критичных workload к периферии

3. Автоматизация политик — ручное управление не масштабируется

Zero Trust — это не продукт, а архитектурный принцип. И да, он требует изменений в менталитете команды больше, чем в технологиях.

Post-Quantum Cryptography: тихая революция в инфраструктуре, которую нельзя игнорировать

Пока большинство обсуждает ИИ, в мире криптографии происходит настоящая революция. NIST утвердил первые стандарты постквантовой криптографии, и это потребует фундаментальных изменений в ИТ-инфраструктуре уже в ближайшие 2–3 года.

Проблема:

Современные алгоритмы (RSA, ECC) могут быть взломаны квантовыми компьютерами в обозримом будущем. Миграция на PQC — не вопрос «если», а вопрос «когда».

Что меняется:

• Размер ключей увеличивается в 5-10 раз

• Процессоры испытывают нагрузку на 30-50% выше

• TLS-хендшейки становятся значительно объемнее

Наши тесты с OpenSSH 9.8:

bash

# Стандартный ключ Ed25519: 68 байт
# PQC-ключ Dilithium3: 1842 байта
# Рост трафика при подключении: ~2700%

Практические рекомендации:

1. Аудит инфраструктуры:

python

# Скрипт для поиска уязвимых сервисов
import ssl
for protocol in ['TLSv1.2', 'TLSv1.3']:
    ctx = ssl.create_default_context()
    ctx.set_ciphers(protocol)

2. План миграции:

• 2025: Тестирование гибридных схем (PQC + традиционные алгоритмы)

• 2026: Перевод внутренних сервисов

• 2027: Полный переход для внешних endpoint

3. Аппаратные требования:

• CPU с поддержкой AVX2/AVX-512

• Увеличение буферов сетевых карт

• +30% к оперативной памяти для сертификатов

Метрики производительности после перехода:

• 📉 Throughput VPN: снижение на 15%

• 📈 Потребление CPU: рост на 40%

• ⏱️ Время TLS-хендшейка: +80 мс

Вывод:

Откладывание перехода на PQC аналогично игнорированию проблемы Y2K в 90-х. Уже сегодня нужно начинать тестирование и планирование, чтобы избежать хаотичной миграции под давлением регуляторов.

Уже проводили тесты с постквантовыми алгоритмами? Делитесь результатами в комментариях — соберем статистику по разным конфигурациям.

Когда TLS 1.3 ломает мониторинг: тонкая настройка под новые протоколы

С переходом на TLS 1.3 многие системы мониторинга внезапно "ослепли". Старые методы перехвата трафика перестали работать, а бизнес требует полной видимости. Разбираем, как адаптировать мониторинг под современные стандарты безопасности.

Проблема:

• eSNI и Encrypted Client Hello шифруют метаданные подключения

• PFS (Perfect Forward Secrecy) делает историческую расшифровку трафика невозможной

• 70% инструментов мониторинга показывают "encrypted traffic" вместо полезных метрик

Решение через eBPF:

bash

# Вместо SSL-инспекции - анализ системных вызовов
sudo bpftrace -e 'tracepoint:syscalls:sys_enter_connect {
    printf("%s → %s:%d\n", comm, args->uservaddr, args->port);
}'

Наша реализация:

1. Мониторинг на уровне ядра - eBPF-программы для анализа сокетов

2. Анализ временных метрик - latency между SYN и ACK без расшифровки содержимого

3. Косвенные метрики - количество новых соединений, размер передаваемых данных

Конфигурация для Prometheus:

yaml

- job_name: 'ebpf_metrics'
  static_configs:
    - targets: ['node-exporter:9100']
  metrics_path: /ebpf
  params:
    module: [tcp_tracer]

Результаты:

• Обнаружили 40% неоптимальных TLS-хендшейков

• Снизили время диагностики проблем с подключением с 25 до 3 минут

• Соответствуем требованиям GDPR и PCI DSS (без декриптации трафика)

Вывод:
Современный мониторинг требует смещения фокуса с инспекции содержимого на анализ метаданных и поведенческих паттернов. Безопасность и наблюдательность больше не противоречат друг другу.

#eBPF #TLS1.3 #мониторинг #кибербезопасность #observability

Какие подходы к мониторингу зашифрованного трафика используете вы? 

Grafana: когда красивые графики становятся рабочим инструментом

Все мы видели скриншоты дашбордов Grafana с красочными графиками. Но когда красивая визуализация становится реальным инструментом мониторинга, а не просто картинкой для отчёта?

Проблема типового подхода:

• Собираем все метрики подряд — «на всякий случай»

• Создаём дашборды с 20+ графиками, где невозможно найти нужную информацию

• Система есть, а пользы нет

Как мы построили эффективный мониторинг:

1. Инфраструктура сбора данных

text

Prometheus → Grafana (визуализация)
Loki → Grafana (логи)
Alertmanager → Grafana (алерты)

Один стек — единая картина происходящего.

2. Три уровня дашбордов:

• Оперативный (NOC): 3-5 ключевых метрик — доступность, ошибки, нагрузка

• Тактический (инженеры): детализация по сервисам + связанные логи

• Стратегический (руководство): SLA, бизнес-метрики, тренды

3. Пример полезного дашборда для веб-сервиса:

sql

- HTTP-коды ответов (1xx, 2xx, 3xx, 4xx, 5xx) 
- Latency: p50, p95, p99
- Rate of errors (> 5%)
- SLO: доступность за последний час

4. Интеграция логов и трейсов:
Теперь не просто видим, что latency вырос, а сразу находим причину в логах конкретного микросервиса.

Реальные результаты:

• Время диагностики инцидентов сократилось с 40 до 8 минут

• Количество ложных алертов уменьшили в 5 раз

• Единая система вместо 3 разных инструментов мониторинга

Ошибки, которых стоит избегать:

1. Не создавайте дашборды «для галочки»

2. Настройте meaningful алерты, а не «disk usage > 90%»

3. Используйте единый стек данных (метрики + логи + трейсы)

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

А какие подходы к мониторингу используете вы? Делитесь кейсами в комментариях!

#grafana #мониторинг #prometheus #loki #devops #sre

Когда мониторинг слепнет: почему 90% алертов — это ложные срабатывания и как с этим жить

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

Проблема ложных срабатываний

• 📊 15% нагрузки на Zabbix/Prometheus — сбор и обработка бесполезных метрик

• ⏰ До 3 часов в день senior-инженеры тратят на фильтрацию алертов

• 🔕 68% инженеров признаются, что пропускали важные уведомления из-за "алертной усталости"

Почему это происходит

1. Мониторим всё подряд — собираем метрики "на всякий случай"

2. Неправильные пороги — одинаковые thresholds для dev и prod

3. Отсутствие бизнес-логики — система не понимает контекст сбоя

Решение: умный мониторинг

# Вместо этого:
alert: CPU > 90%

# Мониторим так:
alert: 
  condition: CPU > 90% 
  and LoadAverage > 5
  and duration > 5m
  and business_impact = true

Что внедрили у себя

1. Сезонные пороги — разные thresholds в рабочее/нерабочее время

2. Корреляцию событий — не алертим о высокой нагрузке, если это время бэкапов

3. Бизнес-метрики — мониторим не "доступность сервера", а "доступность оплаты"

Результаты через 3 месяца

• ✅ Снизили количество алертов в 7 раз

• ✅ 98% срабатываний требуют реакции

• ✅ Время реакции на реальные инциденты сократилось с 25 до 8 минут

Вывод
Мониторинг должен говорить, когда бизнес теряет деньги, а не когда у сервера чихнул процессор. Лучше 10 точных алертов, чем 1000 мусорных.

А как у вас с алертами? Тоже тонете в ложных срабатываниях?

#мониторинг #zabbix #prometheus #алерты #devops #sysadmin

P.S. В комментах жду ваши кейсы борьбы с алертной усталостью — соберем лучшие практики!

Надёжный пароль - это может быть плохо.

Надысь пил пиво, и была мне мысль. Если у нас есть юзвера, и они сами себе придумывают пароли, а мы им устанавливаем ограничения типа "8 знаков и обязательно с цифрами" - то значимая часть этих юзеров будет придумывать пароль, минимально подходящий под эти правила. Таким образом, если мы опасаемся брутфоса (а зачем ещё нужны сложные пароли?) а атакующему нужно сбрутить не конкретного юзверя, а хоть кого-нибудь, то ограничения пойдут атакующему на пользу.

• Стоит минимальная длина 6 знаков - перебираем только 6 знаков и переходим к следующему пользователю.

• Требуются обязательно буквы и цифры - перебираем варианты с 1-2 цифрами в конце, переходим к следующему.

• Требуются буквы, цифры, знаки препинания, не менее 4-х разных видов - это вообще лафа. Ставлю свою недопитую бутылку пива, что хоть у одного юзера будет пароль ABCD1234!@#$. Генерируем список тупых паролей под правила и брутим только по нему.

Всё сказал. Что делать с этой мыслью я не знаю, так что нате вам её.

Подборка обучающих материалов по Docker и Kubernetes

Привет, Хабр! Сегодня пятница, поэтому я снова со своей нерегулярной подборкой полезных материалов для начинающих специалистов. На этот раз несу статьи о Docker и Kubernetes. Как обычно: все бесплатно, без регистрации и смс. Читайте и практикуйте.

Первые шаги в Kubernetes

Здесь 12 статей примерно на два часа чтения. Будет полезно, если нужно освоить базу: что такое K8s, какие задачи помогает решить, основные понятия, с чего начать, как работать с контейнерами и настроить мониторинг.

Docker с нуля: как работают контейнеры и зачем они нужны

Эта подборка из шести статей — ваш гид в мир контейнеризации. Вы узнаете, что такое Docker, как запускать контейнеры, собирать образы и использовать Docker Compose, а еще разберетесь, чем эта технология отличается от Kubernetes. Все материалы подкреплены практическими примерами и будут понятны начинающим. На полное изучение уйдет менее двух часов.

Основы безопасности в Docker-контейнерах

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

Квиз: основы работы с базами данных

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

Пройти квиз

Не забудьте поделиться результатами в комментариях!

Кажется я опять удалил бэкап из бакета... А нет, у меня ж стоит блокировка 😮‍💨

Добавили в S3 новую функцию — блокировку объектов (Object Lock). Теперь можно зафиксировать, или по-айтишному — «залочить» версии объектов так, что их нельзя удалить или изменить в течение заданного времени. Даже админу бакета.

👌 Идеально для архивов, резервных копий и важных логов.

Есть несколько режимов:

GOVERNANCE — «админ может удалять, а другие нет»

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

COMPLIANCE — «тут и админ бессилен»

Объекты остаются нетронутыми до конца срока блокировки, даже если у вас админские права

Без глобальной защиты — «по дефолту»

Блокировка версий объектов не будет устанавливаться в бакете

⚙️ Подробности в доке →

Ну все, осталось только включить блокировку в настройках →

Как создать шаблон в Zabbix

Многим знаком Zabbix, помогающий мониторить и отслеживать состояние сетевых узлов, серверов и сервисов. Этот инструмент представляет собой open-source систему, которая поддерживает сбор метрик с различных устройств, анализ данных и оповещение при возникновении проблем. Благодаря своим функциям Zabbix позволяет автоматизировать мониторинг, гибко управлять конфигурациями и интегрировать сторонние решения.

А однo из ключевых инструментов — использование шаблонов, работа с которыми упрощает отслеживание и контроль сетевых узлов и серверов. Шаблоны помогают быстро настраивать группы хостов, синхронизировать мониторинг и минимизировать ручную работу. Подробнее о работе с пользовательскими шаблонами в Zabbix, их настройке и привязке к хосту рассказали в базе знаний Рег.облака.

19 сентября — СУБД-митап Tantor JAM

Митап от разработчика СУБД Tantor Postgres и машин баз данных Tantor XData пройдет в Москве. Это отличный повод встретиться для всех, кто интересуется развитием российских СУБД и будущим сферы управления корпоративными данными.

Регистрация завершена

В программе мероприятия:

• Стратегия «Тантор Лабс» на 3 года;

• Новая версия платформы Tantor — ведущего enterprise-решения для администрирования и мониторинга любых БД на основе PostgreSQL;

• Новинки СУБД Tantor Postgres для более высокой производительности и защищённости данных;

• Инструментарий для управления интеграциями и загрузкой данных, осуществления миграций с минимумом даунтайма;

• Особое внимание будет уделено Tantor XData — первой российской машине баз данных от вендора СУБД, созданной для самых сложных промышленных задач, высоконагруженных защищённых систем и крупномасштабной аналитики в стратегически важных отраслях.

Митап пройдет 19 сентября 2025 г. на 40-м этаже башни Mercury Space по адресу: Москва, 1-й Красногвардейский проезд, 15. Регистрация участников стартует в 12.00.

Будем рады видеть вас и ваших коллег!