Zabbix — замечательный продукт для администраторов крупных программно-аппаратных комплексов. Он настолько хорош, что может использоваться не только крупным бизнесом, но и средне-малым бизнесом, и даже в pet-проекте. В общем, у меня есть небольшой опыт работы с Zabbix'ом и я смело могу рекомендовать его к использованию.

Правда я не могу сказать, что понимаю "философию Zabbix'а". Несмотря на обширную подробную документацию на русском языке, мне было сложно погружаться в мир Zabbix'а — создавалось ощущение, что мы с разработчиками одни и те же вещи называем разными именами. Возможно потому, что Zabbix создавался админами для админов, а я всё-таки больше разработчик и пользователь.

Тем не менее, для запуска Zabbix'а и для мониторинга основных параметров компьютерных систем (процессор, память и т.п.) навыков обычного linux-пользователя хватает. Есть большое количество плагинов от сторонних разработчиков, расширяющих возможности Zabbix'а. Для моих нужд мне потребовалось настроить мониторинг Redis-сервера. Я немного покопался в коде имеющихся плагинов и на их примере выяснил, что архитектура Zabbix'а позволяет достаточно просто подключать к мониторингу любые параметры информационных систем, которые могут быть выражены в числовом виде.

Под катом — пример Zabbix-плагина с моим пояснением по терминологии Zabbix'а. Кому-то этот пример покажется наивным, ну а кому-то поможет проще освоиться с понятиями. В любом случае, Zabbix достаточно велик для того, чтобы ощупать его с разных сторон.

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

В ноябре 2018 года в ЛитРес создали отдел информационного обеспечения и пригласили руководить Андрея Юмашева. Последний год отдел помогает компании работать и развиваться и держит под контролем всю инфраструктуру. Но так было не всегда. Перед тем, как наладить работу, Андрей столкнулся с руинами: полуживой Nagios, условно живой Cacti и коматозный Puppet, мертвая Вики на 120 страниц, несвязные таблицы с задачами и списком железа, устаревшая архитектура, 340 бездействующих ядер, 2 Тбайта оперативной памяти и 17 Тбайт дискового пространства, которые почему-то не были записаны в инвентарных таблицах. Планы, которые не работают, сроки, которые срываются, рабочее окружение и инструменты, которых нет — все это ждало Андрея в новом проекте.



На DevOpsConf 2019 Андрей выступил с докладом, в котором на живых примерах показал, что стоит, а что не стоит делать, когда входишь в проект, которого еще не видел или плохо знаешь. Под катом дополненная версия рассказа — как правильно анализировать спектр проблем и выстроить план деятельности, как правильно рассчитать KPI и когда следует вовремя остановиться.

Отказоустойчивость и высокая доступность — большие темы, так что посвятим RabbitMQ и Kafka отдельные статьи. Данная статья о RabbitMQ, а следующая — о Kafka, в сравнении с RabbitMQ. Статья длинная, так что устраивайтесь поудобнее.

Рассмотрим стратегии отказоустойчивости, согласованности и высокой доступности (HA), а также компромиссы, на которые приходится идти в каждой стратегии. RabbitMQ может работать на кластере узлов — и тогда классифицируется как распределенная система. Когда речь заходит о распределенных системах, мы часто говорим о согласованности и доступности.

Эти понятия описывают, как система ведет себя при сбое. Сбой сетевого соединения, сбой сервера, сбой жесткого диска, временная недоступность сервера из-за сборки мусора, потеря пакетов или замедление сетевого соединения. Все это может привести к потере данных или конфликтам. Оказывается, практически невозможно поднять систему, одновременно и полностью непротиворечивую (без потери данных, без расхождения данных), и доступную (будет принимать операции чтения и записи) для всех вариантов сбоя.

Три года назад мы опубликовали статью Оборудование ВКС для переговорных комнат. Она стала результатом труда и сборником экспертизы не одного человека, а нескольких компаний, специализирующихся многие годы на интеграции сложных решений видео-конференц-связи. На первый взгляд, ВКС и телефония — имеют много общего: общие задачи, схожий состав оборудования и аналогичная архитектура решений. Но, в реальности, с точки зрения интегратора — расчет и реализация проекта по видео-конференц-связи существенно отличается от телефонизации.

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

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

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

• Почему я не могу поставить в этой переговорной комнате обычную веб-камеру?
• Насколько эта камера сможет увеличить председателя?
• А если мы телевизор придвинем к столу, ближние участники попадут в кадр?
• Хватит ли чувствительности этого спикерфона на нашу комнату?

Даже обладая пониманием параметров комнаты и оборудования, непросто совместить их в визуальный образ, не прибегая к реальной установке оборудования в комнате.

[Прим. переводчика. Материал статьи относится к Windows Server 2003/2003R2/2008/2008R2, но большинство из описанного справедливо и для более поздних версий ОС]

Всем привет! Уоррен снова здесь, и этот пост в блоге представляет собой подборку наиболее распространенных проблем DFSR, с которыми я столкнулся за последние несколько лет. Цель этого поста — перечислить распространенные ошибки в конфигурации DFSR, из-за которых возникают эти проблемы, и уберечь вас от совершения аналогичных ошибок. Знать, чего делать не следует, так же важно, как знать, что нужно делать. Многие из описанных пунктов связаны с другими темами, поэтому для углубленного изучения вопроса предоставлены соответствующие ссылки.

Часть 1. Про CPU
Часть 3. Про Storage

В этой статье поговорим про счетчики производительности оперативной памяти (RAM) в vSphere.
Вроде бы с памятью все более однозначно, чем с процессором: если на ВМ возникают проблемы с производительностью, их сложно не заметить. Зато если они появляются, справиться с ними гораздо сложнее. Но обо всем по порядку.

Если вы администрируете виртуальную инфраструктуру на базе VMware vSphere (или любого другого стека технологий), то наверняка часто слышите от пользователей жалобы: «Виртуальная машина работает медленно!». В этом цикле статей разберу метрики производительности и расскажу, что и почему «тормозит» и как сделать так, чтобы не «тормозило».

Буду рассматривать следующие аспекты производительности виртуальных машин:

• CPU,
• RAM,
• DISK,
• Network.

Начну с CPU.

Для анализа производительности нам понадобятся:

• vCenter Performance Counters – счетчики производительности, графики которых можно посмотреть через vSphere Client. Информация по данным счетчикам доступна в любой версии клиента (“толстый” клиент на C#, web-клиент на Flex и web-клиент на HTML5). В данных статьях мы будем использовать скриншоты из С#-клиента, только потому, что они лучше смотрятся в миниатюре:)
• ESXTOP – утилита, которая запускается из командной строки ESXi. С ее помощью можно получить значения счетчиков производительности в реальном времени или выгрузить эти значения за определенный период в .csv файл для дальнейшего анализа. Далее расскажу про этот инструмент подробнее и приведу несколько полезных ссылок на документацию и статьи по теме.

СДСМ закончился, а бесконтрольное желание писать — осталось.



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

Этой статьёй я начну серию о том, как мне видится автоматизация.
По ходу дела разберёмся с этапами автоматизации, хранением переменных, формализацией дизайна, с RestAPI, NETCONF, YANG, YDK и будем очень много программировать.
Мне означает, что а) это не объективная истина, б) не безоговорочно лучший подход в) мой взгляд даже в ходе движения от первой к последней статье может поменяться — честно говоря, от стадии черновика до публикации я переписывал всё полностью дважды.

В Visual Studio 2017 Update 15.9 мы добавили возможность экспорта и импорта рабочей нагрузки и выбора компонентов в файл конфигурации установки Visual Studio. Разработчики могут импортировать эти файлы в новые или существующие установки. Проверка этих файлов в ваших исходных репозиториях позволяет легко ими делиться. Однако разработчикам все еще нужно импортировать их, чтобы получить необходимые функции.

В Visual Studio 2019 была добавлена автоматическая установка недостающих компонентов. Подробности под катом!

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

Существует несколько вариантов решения данной задачи:

1. Использование единого пароля на всех компьютерах. Пароль может устанавливаться либо во время деплоя с помощью MDT или SCCM, либо с помощью предпочтений групповых политик после деплоя. Обычно при таком подходе пароль никогда не меняется, а значит рано или поздно утечет (при увольнении администратора или пользователь может подглядеть ввод пароля), при этом скомпрометированный пароль дает доступ ко всем ПК в организации.
2. Единоразовая установка уникального пароля на каждом ПК. Обычно происходит при деплое. Вариантов масса — начиная от ручной генерации случайного пароля и сохранении его в системе учета паролей (Keepass, OnePassword, Excel), заканчивая автоматической генерацией пароля по алгоритму известному администраторам, где входными данными является имя ПК. Зная алгоритм, администратор может на месте рассчитать пароль и авторизоваться на любом ПК. Минусы примерно аналогичны варианту 1: Уволенный администратор сохраняет возможность войти на любой ПК, зато при компрометации пароля пользователем он получает доступ только к одному ПК, а не ко всем сразу.
3. Использование системы, которая будет автоматически генерировать случайные пароли для каждого ПК и менять их по установленному расписанию. Минусы предыдущих вариантов тут исключены — скомпрометированный пароль будет изменен по расписанию, и уволенный администратор через некоторое время не сможет авторизоваться на ПК даже если и украдет действующую на момент увольнения базу паролей.

Одной из таких систем является LAPS, установку и настройку которой мы разберем в этой статье.

После нескольких месяцев разработки, готов представить новую версию приложения для удаленного управления – Aspia.

Предыдущая статья на Хабре вызвала большой интерес у многих читателей к разработке и я постарался сделать релиз новой версии максимально интересным.

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

Если кто-то еще не слышал, то сообщаем: в уходящем году компания Veeam Software реализовала поддержку резервного копирования и восстановления виртуальных машин на платформе Nutanix Acropolis Hypervisor (AHV). Для этого был разработан специальный компонент инфраструктуры Veeam Backup – вспомогательный прокси-сервер (proxy appliance), который получил красивое имя собственное Veeam Availability for Nutanix AHV.

Он представляет собой виртуальный модуль, позволяющий бэкапить и восстанавливать ВМ на кластерах Nutanix AHV, задействуя возможности Veeam Backup & Replication. Решение функционирует на уровне гипервизора: без внедрения агентов в гостевую ОС создает бэкап ВМ на уровне образа, по состоянию на текущий момент времени (включая ОС, данные приложений и пр.) и сохраняет в репозиторий Veeam.

Из этих бэкапов затем можно восстанавливаться по любому сценарию: восстанавливать всю ВМ целиком либо отдельные диски, файлы, объекты приложений. Поддерживается и восстановление в облако Microsoft Azure, и экспорт дисков, и мгновенное восстановление в ВМ на платформе Hyper-V.

Всех заинтересовавшихся прошу под кат.

14 декабря будет запущена новая «Test lab» — лаборатория тестирования на проникновение, имитирующая работу реальной корпоративной сети, в которой каждый желающий сможет проверить свои навыки тестирования на проникновение. Поскольку порог вхождения для выполнения всех заданий лаборатории достаточно высокий, мы решили выпустить небольшой гайд для начинающих по работе с Kali Linux 2018.4 — одним из самых популярных пентест-дистрибутивов, разработанного как преемник BackTrack и основного на Debian.

Всем привет! Я работаю в Veeam над проектом Veeam Agent for Linux. С помощью этого продукта можно бэкапить машину с ОС Linux. «Agent» в названии означает, что программа позволяет бэкапить физические машины. Виртуалки тоже бэкапит, но располагается при этом на гостевой ОС.

Вдохновением для этой статьи послужил мой доклад на конференции Linux Piter, который я решил оформить в виде статьи для всех интересующихся хабражителей.

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

Всех заинтересовавшихся прошу под кат!

Очередная статья в серии «Инструменты мониторинга Logicify» рассказывает о Grafana. Это программное средство мы используем для визуализации и анализа данных как внутренних, так и внешних проектов. Статья может быть полезна техническим директорам, разработчикам, DevOps, системным администраторам, менеджерам проектов, а также всем заинтересованным лицам.

RouterOS очень мощный инструмент в руках профессионалов и ответственных специалистов. Но в руках новичков или тех, кто делает всё на «и так сойдёт» Mikrotik начинает жить своей жизнью и превращается в ноду ботнета.

Ещё в мае 2018 я писал статью с рекомендациями как защитить свой Микротик.

Как ни странно, но в сети до сих пор тысячи «открытых» роутеров Mikrotik и армия ботнета пополняется.

Я в свободное от работы и отдыха время искал уязвимые устройства по всей сети и делал настройки в соответствии со своими рекомендациями, то есть добавлял правила фаервола, которые закрывали доступ к роутеру не из локальной сети. В комментариях писал информацию об уязвимости и оставлял адрес телеграм-канала @router_os, где можно было мне задать интересующие вопросы (у нормального админа они должны были появиться).



С мая по сегодняшний день я «вырвал» из лап ботнета более 100 тысяч устройств Mikrotik.

Учитывая то, что я не могу выступить на MUM 2018 в Москве, то свой доклад я решил опубликовать на habr.com

Всем привет!

Сегодня я хотел бы с вами поделиться информацией как можно достаточно легко и быстро с помощью технологии Group Policy Preferences (GPP) (Она доступна с Windows Server 2008) создавать и мапить пользовательские личные папки на сервере.

Данный процесс можно разбить на несколько основных этапов

• Создание и настройка прав на корневую папку в которой будут храниться папки пользователей
• Создание папки для пользователя
• Мапинг сетевого диска для пользователей

На DevOps есть по крайней мере два устоявшихся взгляда — со стороны системных администраторов и со стороны разработчиков. Первые обычно хвастаются тем, что используют Chef/Puppet/Ansible/Docker c 200X года, вторые считают, что DevOps либо изжил себя и ведет к NoOps, либо что «я завернул всё в контейнер, а дальше как пойдёт».

Бизнес при этом читает про DevOps в статьях и надеется, что ребята снизу разберутся, что с ним делать. При этом самого DevOps не происходит, бизнес не похож на Google, компания не становится бирюзовой, люди не создают новых подходов для проверки гипотез в мире.

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

В основе материала — расшифровка доклада Александра osminog Титова с нашей октябрьской конференции DevOops 2017.

Здравствуйте! Я почти 10 лет работаю в сфере ИТ и ИБ, всегда интересовался практической безопасностью, в настоящее время работаю пентестером. За все время работы я постоянно сталкивался с типовыми ошибками в настройках и дизайне инфраструктуры. Ошибки эти чаще всего досадные, легко устранимые, однако быстро превращают сеть в полигон для взлома. Порой кажется, что где-то специально учат так настраивать, насколько часто они встречались. Это и побудило меня написать данную статью, собрав все самое основное, что может улучшить защищенность.

В этой статье я не буду рассказывать про использование сложных паролей, максимального ограничения прав доступа, смене учетных записей по умолчанию, обновлению ПО, и других «типовых» рекомендациях. Цель статьи – рассказать о самых частых ошибках в настройках, заставить администраторов и специалистов ИБ задуматься над вопросом – «а все ли в моей сети хорошо?», а также показать, как можно оперативно прикрыть те или иные типовые уязвимости, используя встроенные или бесплатные средства, не прибегая к дополнительным закупкам.

Инструкций-рецептов намеренно не прикладываю, так как многое ищется очень легко по ключевым словам.