Блог компании infowatch

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

Известно, что Postfix разработан как альтернатива Sendmail. ПО повышало производительность, обеспечивало устойчивость, гибкость и безопасность решения. Все основные Linux-дистрибутивы включают Postfix, в Mac OS X, начиная с версии 10.3, программа также используется вместо Sendmail.

Главные особенности

• Фокус Postfix в том, что можно начинать работу без приготовлений (базовые конфигурационные файлы включают в себя пару строк).
• Для эффективной фильтрации писем применяются регулярные выражения PCRE (Perl compatible regular expression).
• Программа Postfix совместима с Sendmail: файлы aliases и .forward имеют схожий формат и семантику.
• Postfix общается по протоколу ESMTP, поддерживает виртуальные домены и фильтрацию спама.
• Не используется язык подстановки адресов как в Sendmail. Вместо этого производится поиск в плоских файлах таблиц или базе данных MySQL.

Архитектура

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

Запуск и контроль всех процессов выполняет программа master. В ее конфиге master.cf -перечислены вспомогательные программы и информация о том, как и когда их нужно запустить.

Самые важные программы показаны в блок-схеме:



За прием почты на порту SMTP отвечает smtpd. Он же проверяет, авторизован ли клиент для отправки почты. Если письмо отправляется локально, через совместимость с /usr/lib/sendmail, файл будет записан в каталог /var/spool/postfix/maildrop. Этот каталог сканируется программой pickup, которая обрабатывает найденные файлы. Входящая почта обрабатывается программой cleanup. Она добавляет отсутствующие заголовки и переписывает адреса в соответствии с картами canonical и virtual. Прежде чем поместить письмо в очередь, incoming программа cleanup передает письмо программе trivial-rewrite, которая также выполняет незначительные исправления в адресах, добавляя домен и частично заполненный адрес.

Электронные письма, ожидающие доставки, находятся под управлением qmgr администратора очередей:

Incoming входящая почта;

Active доставляемая почта;

Deferred письма, доставка которых не осуществилась ранее;

Hold письма, заблокированные в очереди администратором;

Corrupt письма, которые невозможно прочитать.

Анализатор очередей обычно выбирает сообщение для обработки на основе алгоритма FIFO.

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

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

Отправка почты идет при поддержке trivial-rewrite, утилита qmgr принимает решение, куда должно быть отправлено сообщение. Решение о маршруте может быть аннулировано transport картой.

Доставка с помощью SMTP осуществляется, конечно, smtp-программой. Lmtp осуществляет локальную пересылку почты по протоколу LMTP, использующим семантику ESMTP (https://tools.ietf.org/html/rfc2033). LMTP изменен так, что для управления локальной очередью почтовый сервер не нужен.

Задача local локальная доставка почты. Программа распознает в таблице aliases и выполняет инструкции из файла .forward получателя. Сообщения могут быть направлены по другому адресу, переданы внешней программе на обработку или сохраниться в почтовых папках пользователей.

Программа virtual доставляет письма в виртуальные почтовые ящики ящики, представляющие собой адреса назначения. Наконец, программа pipe реализует доставку через внешние программы.

Взаимодействие между пользователем и системой обработки регулируется утилитами:

sendmail, mailq, newaliases интерфейс совместимости postfix и sendmail.

[root@iwtm611 ~]# sendmail user@example.com
from test@test.com
user@example.com
HI!!!
.

Поставьте "." И нажмите Enter sendmail попытается отправить письмо.

postfix запускает и прекращает работу системы обработки почты;

[root@iwtm611 ~]# postfix status
postfix/postfix-script: the Postfix mail system is running: PID: 16765

postalias создает и модифицирует таблицы псевдонимов;

postmap создает, модифицирует, запрашивает таблицы преобразований;

cat /etc/postfix/transport

onedomain.ru smtp:10.1.2.10
twodomain.ru smtp:10.1.3.10

postmap /etc/postfix/transport

postalias /etc/postfix/aliases

Утилиты фактически создают индексированные карты файлов. Повторить запуск при изменениях в файлах aliases и transport;

Postcat напечатает содержимое файла из очереди;

[root@iwtm611 ~]# postcat -qv 96987C3CFB40
postcat: name_mask: all
postcat: inet_addr_local: configured 2 IPv4 addresses
postcat: inet_addr_local: configured 2 IPv6 addresses
*** ENVELOPE RECORDS deferred/9/96987C3CFB40 ***


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

[root@iwtm611 ~]# postqueue -p
-Queue ID- --Size-- ----Arrival Time---- -Sender/Recipient-------
956FAC3CFB46 2311 Mon Jul 27 19:50:05 MAILER-DAEMON
(connect to 10.70.85.12[10.70.85.12]:25: No route to host)
user@domain.ru

Postconf инструментальное средство, позволяющее конфигурировать postfix- конфиг main.cf. Без аргументов выводит все параметры в текущей конфигурации. Если передать значение параметра выведет значение этого параметра. С ключом d напечатает default-настройки, а не сконфигурированные.

[root@iwtm611 ~]# postconf virtual_mailbox_limit
virtual_mailbox_limit = 51200000

С ключом n напечатает только значения, отличные от типовых.

Главным файлом Postfix является main.cf. Он конфигурирует серверные программы и определяет таблицы преобразований, на которые содержит ссылки. Содержит более 300 параметров. Для запуска почтового сервера в средней организации достаточно лишь несколько из них. В документацию рекомендуется включать лишь параметры, содержащие нестандартные значения.

Базовая возможная настройка

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

Второй вариант null клиент. Система не выполняет локальную доставку, а направляет исходящую почту на указанный почтовый сервер. При этом конфиге указывается несколько параметров: mydomain определяющий домен компьютера; myorigin определяющий почтовый домен, добавляемый к почтовым адресам. Третьим параметром будет mydestination, определяющий локальные почтовые домены (они же canonical домены). Если домен получателя соответствует mydestination, письмо доставит программа local (при условии что файла .forward не найдено). Если в mydestination несколько записей, они рассматриваются как псевдонимы одного домена. Null клиенту локальная доставка не нужна, поэтому параметр mydestination пустой. Также программа local проведет поиск псевдонима адреса в таблицах alias_maps. Наконец, параметр relayhost оповещает Postfix о том, что нелокальные сообщения нужно посылать на указанный компьютер, а не адресатам. Квадратные скобки говорят о том, что указанная строка обрабатывается как имя компьютера, то есть A не MX запись DNS. Null клиент не должен получать почту с других систем комментируем строчку smtpd в файле master.cf программа smtpd не запустится.

Преобразования и виртуальные домены

Аспекты поведения Postfix определяются использованием таблиц поиска, отражающих ключи как значения тип: путь или просто как списки. Например, таблица alias_maps:dbm:/etc/mail/aliases.

Обратите внимание, синтаксис ключ: значение обеспечивает совместимость с Sendmail.

Помимо традиционного файла базы данных бинарного формата dbm, источником данных для таблицы преобразований может быть ldap, regexp выражения, postgres, Mysql и многое другое.

Если вам нужно обслуживать почтовый домен, то можно сделать это тремя путями:

Указать домен в mydestination доставка пойдет по схеме, описанной выше;

Указать домен в параметре virtual_alias_domains. Домен получит собственное адресное пространство. Потребуется обеспечить возможность преобразования адресов в реальные (карта virtual_alias_maps);

Указать домен в virtual_mailbox _domains. Здесь также будет собственное именное пространство. Но управление списком пользователей будет независимым от системных учеток. Потребуется указать параметр virtual_mailbox _maps c таблицей действительных пользователей в домене.

Защита и доступ

Postfix защищает себя на нескольких уровнях. Большинство серверных Postfix-программ могут выполняться в среде с измененным корневым каталогом (chroot). Они являются отдельными программами без связи Родитель-дочерний. Ни одна из них не имеет бита setuid. Каталог, в который направлена почта, открыт для записи группе postdrop, для нее программа postdrop setgid.

Что касается доступа, почтовые домены ретранслируют почту на сторонние адреса только для надежных агентов. Открытая ретрансляция с неизвестных адресов, как известно, не сулит ничего хорошего. Postfix по умолчанию закрыт как ретранслятор. Стандартные настройки сильно ограничены, возможно вам придется ослаблять ограничения. Доступы конфигурируются списками ограничения доступа access restriction list. Важнейшим параметром будет smtpd_recipient_restrictions, так как адресом получателя куда проще управлять. По крайней мере, можно установить локальный ли он.

Вот список ограничений для проверки ретрансляции:

Check_client_address проверяет адрес ПК клиента;

Check_recipient_access проверяет почтовый адрес получателя;

Permit_mynetworks предоставляет доступ к адресам в параметре mynetworks;

Reject_anauth_destination отклоняет почту для нелокальных получателей ретрансляция отсутствует.

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

Черные списки основаны на информации из DNS разрешаются директивой reject_rhsbl_sender после указывается DNS-сервер, также reject_rbl_client , только проверяет имя PC, а не доменное имя.

Фильтрация для проверки самого Body письма Postfix использует regexp выражения в реальном времени. А также может передавать сообщения другим программам. Postfix поддерживает SpamAssasin и фильтры подобного рода.

До сих пор в версиях Posfix удавались лишь DDOS атаки.

Отладка

Если возникла проблема с почтой, первым делом можно заглянуть в журнальные файлы Posfix. Каждая Postfix-программа регистрирует запись в журнале для обработанного сообщения.

Идентификатор письма 96987C3CFB40 общий для каждой строки. Postfix присвоит его, как только сообщение попадает в систему и никогда не изменяет. Таким образом, при поиске в журнале можно сосредоточиться на поиске ID, затем с помощью grep отследить маршрут.

[root@iwtm611 ~]# tailf /var/log/maillog

Jul 27 20:00:08 iwtm611 postfix/smtp[8576]: 96987C3CFB40: to=<user@domain.ru>, relay=none, delay=603, delays=600/0.06/3/0, dsn=4.4.1, status=deferred (connect to 10.70.85.12[10.70.85.12]:25: No route to host)

Jul 27 20:00:08 iwtm611 postfix/error[8585]: 98640C3CFB4D: to=<user@domain.ru>, relay=none, delay=603, delays=600/3.1/0/0, dsn=4.4.1, status=deferred (delivery temporarily suspended: connect to 10.70.85.12[10.70.85.12]:25: No route to host)

Jul 27 20:00:08 iwtm611 postfix/error[8585]: 98E5CC3CFB77: to=<user@domain.ru>, relay=none, delay=603, delays=600/3.1/0/0.01, dsn=4.4.1, status=deferred (delivery temporarily suspended: connect to 10.70.85.12[10.70.85.12]:25: No route to host)

Jul 27 20:00:08 iwtm611 postfix/error[8585]: 99C8DC3CFB62: to=<user@domain.ru>, relay=none, delay=603, delays=600/3.1/0/0, dsn=4.4.1, status=deferred (delivery temporarily suspended: connect to 10.70.85.12[10.70.85.12]:25: No route to host)

Другим местом поиска является сама очередь. Утилита postqueue p (или аналогичный вывод mailq) печатает содержимое очереди.

[root@iwtm611 ~]# mailq

-Queue ID- --Size-- ----Arrival Time---- -Sender/Recipient-------

90190C3B9B9F 2242 Mon Jul 27 19:50:05 MAILER-DAEMON

(connect to 10.70.85.12[10.70.85.12]:25: No route to host)

user@domain.ru

95E96C3CFB5A 2307 Mon Jul 27 19:50:05 MAILER-DAEMON

(delivery temporarily suspended: connect to 10.70.85.12[10.70.85.12]:25: No route to host)

user@domain.ru

956FAC3CFB46 2311 Mon Jul 27 19:50:05 MAILER-DAEMON

(delivery temporarily suspended: connect to 10.70.85.12[10.70.85.12]:25: No route to host)

user@domain.ru

96987C3CFB40 2311 Mon Jul 27 19:50:05 MAILER-DAEMON

(delivery temporarily suspended: connect to 10.70.85.12[10.70.85.12]:25: No route to host)

user@domain.ru

97944C3CFB5E 2311 Mon Jul 27 19:50:05 MAILER-DAEMON

(delivery temporarily suspended: connect to 10.70.85.12[10.70.85.12]:25: No route to host)

user@domain.ru

postcat qv 96987C3CFB40 Найдет письмо по ID, покажет заголовок и дополнительную информацию:
[root@iwtm611 ~]# postcat -qv 96987C3CFB40

postcat: name_mask: all

postcat: inet_addr_local: configured 2 IPv4 addresses

postcat: inet_addr_local: configured 2 IPv6 addresses

*** ENVELOPE RECORDS deferred/9/96987C3CFB40 ***

message_size: 2311 201 1 0 2311

message_arrival_time: Mon Jul 27 19:50:05 2020

create_time: Mon Jul 27 19:50:05 2020

.

regular_text: Return-Path: <user@domain.ru>

regular_text: Received: from Vvpc (unknown [10.254.1.250])

regular_text: by iwtm611.local (Postfix) with ESMTP id BCB42C3CFB62

regular_text: for <usr111@test.com>; Thu, 2 Jul 2020 12:48:45 +0300 (MSK)

regular_text: MIME-Version: 1.0

regular_text: From: user@domain.ru

regular_text: To: usr111@test.com

regular_text: Date: 2 Jul 2020 12:48:40 +0300

regular_text: Subject: test

regular_text: Content-Type: text/plain; charset=utf-8

regular_text: Content-Transfer-Encoding: base64

regular_text: Message-Id: <20200702094845.BCB42C3CFB62@iwtm611.local>

regular_text: --BCB42C3CFB62.1595868605/iwtm611.local--

*** HEADER EXTRACTED deferred/9/96987C3CFB40 ***

*** MESSAGE FILE END deferred/9/96987C3CFB40 ***

qshape новый инструмент свежих версий показывает сводную статистику содержимого и подводит итог количество минут, в течение которых сообщение отправляется. Например, для итога по домену отправителя запустите qshape s, а отклоненные письма можно посмотреть через параметр qshape deferred.



В примере таблицы можно увидеть, что 4 сообщения на gmail висят в очереди более 120 минут.

Рикошет вызывается параметром soft_bounce. Это конфигурационный параметр. Postfix будет отправлять временные сообщения при отправке сообщений об ошибках типа: user_unknown или relay_denied. Это эффективное средство, позволяющее отслеживать местонахождение сообщения после изменений конфигурации и не терять их. Все, что вы отклоните, в конечном итоге вернется отправителю. Не забудьте это отключить после завершения проверки.

Для проверки доступа в Postfix есть расширение xclient, имитирующее отправку сообщений из другого места. Включается в main.cf параметром smtpd_autorized_xclient_hosts.

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

Автор: Галиулин Тимур GTRch

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

Последние 3 года я работаю системным аналитиком в группе компаний InfoWatch и в этой статье я хочу поделиться с вами практиками работы с требованиями, которые мы используем. Компания занимается разработкой Enterprise-продуктов для снижения рисков информационной безопасности, защиты и анализа корпоративных данных. К таким продуктам выдвигаются высокие требования, касающиеся их надёжности, производительности, отказоустойчивости, а так же требования для сертификации. В силу особенностей рынка информационной безопасности наши решения не являются облачными, а устанавливаются on-site у клиента. Поэтому мы работаем в режиме выпуска больших релизов несколько раз в год. Чтобы прийти к назначенной цели и сократить сроки релиза, мы работаем по принципам, заложенным в методологии Agile. Для старта разработки мы не готовим абсолютно детальные системные требования, а начинаем с высокоуровневого описания самых важных аспектов новой функциональности. То есть, принимаем решения, которые больше всего влияют на объем и сложность доработок и дают команде разработки необходимую информацию для старта работ по проектированию архитектуры и написанию кода (для небольших фич). Затем, по ходу разработки, постепенно детализируем требования и доводим их до уровня детализации, достаточного для написания подробных тест-кейсов. Такой подход позволяет не тратить много времени на старт работ и снизить риски того, что требования придется значительно перерабатывать, если выявятся какие-то новые технические ограничения.

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

Требования к разрабатываемому продукту основная зона ответственности системного аналитика. Практики, описанные ниже, направлены на упрощение работы с требованиями и, как следствие, на упрощение процесса разработки продукта:

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

Документирование и версионирование требований

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

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

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

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

Оповещение об изменениях в требованиях

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

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

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

• реализация может не соответствовать требованиям;
• ожидаемый результат тестирования может не соответствовать требованиям и реализации;
• документация может не соответствовать реализации.

До недавнего времени наша команда аналитиков оповещала всех заинтересованных об изменениях в требованиях следующим образом: после внесения изменений в требования, оставляли комментарий к задаче, отправляли письмо, которое содержит ссылку на задачу, ссылку на требования и краткое описание изменений. В конце прошлого года мы автоматизировали этот процесс: доработали issue-tracker (используем JIRA) и теперь после внесения изменений в требованиях мы в задаче, в рамках которой эти изменения были внесены, нажимаем кнопку Оповестить об изменениях, выбираем заинтересованные команды и делаем краткое описание изменений:

Скриншот 1


Письмо, которое автоматически генерируется после нажатия на кнопку Отправить оповещение, имеет следующее представление и содержит всю необходимую информацию:

Скриншот 2


Помимо письма в задаче остается комментарий с аналогичной информацией.

Ревью новых требований

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

Для этого мы так же доработали issue-tracker, добавили отдельный тип задачи Ревью, которая запускается ответственным аналитиком по каждой фиче на всех руководителей команд. Руководители самостоятельно или, делегируя своим подчиненным, делают вычитку требований, задают вопросы или вносят уточнения через комментарии и согласовывают внесенные изменения.

Скриншот 3

Митинги/собрания/статусы

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

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

Обсуждение/решение открытых вопросов

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

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

Поэтому я предпочитаю решать вопросы в дискуссии голосом, то есть созвониться и обсудить, о чем-то договориться. Звонок поможет выяснить, правильно ли вы поняли контекст, сразу задать вопросы и получить ответы. Голос передает интонацию, позволяет расставить правильные акценты, обратить внимание на то, что действительно важно. Плюс, общение голосом экономит время всех участников и позволяет сконцентрироваться на конкретной теме, так как общение голосом (а не в чате), требует проявить участие и понимание для решения вопроса.

Протоколирование обсуждений

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

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

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

Валидация нового функционала

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

Презентация нового функционала

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

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

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

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

Автор: Венера Аббясова AbbyasovaVenera

* Все картинки для статьи взяты из открытого доступа в сети Интернет.

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

Все изменения в требованиях к новой фиче на одной странице

Мы разрабатываем сложные Enterprise-продукты, которые тиражируются для сотен корпоративных заказчиков. В одном из наших продуктов больше ста функциональных модулей и у каждого модуля есть отдельный документ с требованиями. Фичи нового релиза, как правило, затрагивают несколько (от 3 до 20) функциональных модулей.



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

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



Примерно так это выглядит в жизни:



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

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


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



Делается это с помощью стандартных макросов Отчёт о свойствах страницы и Свойства страницы.

Трассировка требований

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

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



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

Для этого мы используем стандартную функциональность меток в Confluence и макрос Результаты поиска.

Версионирование требований по релизам

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



Так выглядит в жизни переключение между версиями релизов:

Комментирование

Для работы с комментариями мы используем плагин Talk.



Его плюсы:

• Можно видеть комментарии и отвечать на них в режиме редактирования документа. Это очень удобно, когда надо вносить правки в требования по результатам ревью
• Нет проблем с параллельным комментированием (особенно если вы планируете переход с MS Word + Sharepoint: не нужно блокировать документ целиком), требования может рецензировать одновременно вся проектная команда
• Если комментарий оставляют на странице с фичей в блоке с Multi Excerpt, он автоматически появляется в исходном документе требований

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

От стандартного функционала комментирования в Confluence мы отказались, потому что у него были критичные для нас минусы:

• Нельзя использовать в связке с плагином Multi Excerpt
• Не видно комментариев в режиме редактирования документа
• Пропадают комментарии, если изменить текст, к которому они были привязаны

Создание диаграмм и мокапов

Сначала мы использовали MS Visio и экспортировали схемы в растровый формат, а затем загружали в Confluence. Такой подход был неудобен актуальность схем приходится поддерживать в двух местах, для этого нужно слишком много действий.

Как оказалось, в Confluence есть множество плагинов для работы с разного рода графическими объектами (диаграммы, схемы, мокапы и пр). Balsamiq Wireframes for Confluence и Draw.io Diagrams for Confluence позволяют редактировать графические объекты, не выходя из Confluence. На данный момент эти плагины почти полностью покрывают наши потребности.

Базовые возможности

Кратко расскажу о базовых возможностях, которые предоставляет Confluence (как и большинство других вики-систем). Чтобы не пересказывать документацию, ограничусь списком того, чем мы в основном пользуемся:

• Сравнение версий документов. Можно быстро понять, как менялась функциональность от релиза к релизу.
• Параллельное редактирование одного документа и автоматическое разрешение конфликтов. Ревью документа могут делать одновременно несколько человек и при этом не нужно ждать своей очереди, пока документ заблокирован на редактирование другим сотрудником (как было, когда мы использовали Sharepoint и требования хранились в виде Word-файлов).
• Шаблоны документов. Мы создали шаблоны по всем основным типам документов (функциональный модуль, фича, протокол совещания)
• Гибкие возможности разграничения доступа (вплоть до уровня страницы). Это удобно, например, для аутсорсных сотрудников, которым нельзя предоставлять доступ сразу ко всем требованиям
• Экспорт документов в различные форматы. Очень выручает в тех редких случаях, когда возникает необходимость передачи документов наружу.
• Интеграция с JIRA. Можно автоматически вставлять статус задач, сроки согласований и прочей информации из тикетов JIRA.

Переход с MS Word

Есть несколько неочевидных вещей, с которыми почти сразу сталкиваешься после перехода с Word на Confluence.

Нумерация заголовков

Чтобы добавить автоматическую нумерацию заголовков, нужно обрамить текст макросом Numbering headings.

Гиперссылка на раздел

Чтобы внутри документа сослаться на какую-нибудь часть документа или заголовок раздела, нужно сначала добавить макроc Anchor (в русской локализации он называется Анкер), а затем добавить гиперссылку на него из нужной части документа.

Цвет фона текста

Сделать нестандартное визуальное оформление текста, в частности выделить фон текста
заливкой, можно с помощью Markdown-разметки (Вставить -> Разметка, Markdown).




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

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

На этом всё. Задавайте вопросы в комментариях!

P.S. Статья основана на базе доклада Лайфхаки Confluence для разработки требований на конференции Analyst Days, видео версию этого доклада можно посмотреть по этой ссылке.

Автор статьи: Ильшат Габдуллин g1r

Давным-давно, когда трава была зеленее, а интернет безопаснее, в ИТ родилась инициатива Web Based Enterprise Management (WBEM). Первоначально спонсируемая в 1996 году такими компаниями как Cisco Systems, Intel и Microsoft, она получила широкое распространение и реализацию на различных платформах: от MAC OS до Redhat. WBEM четко документирован, основан на стандартах Интернета и представляет собой иной подход к управлению системами, отличный, например, от SNMP протокола.

Адаптация WBEM для Windows получила название WMI (Windows management interface) и впервые была представлена в Windows XP. Нам известно, что системы обновляются быстрее, чем их компоненты и многие уязвимости, бывшие ранее удобным инструментом управления, кочуют из версии в версию. В этой статье я хочу описать как выполняются задачи WMI и как избежать потенциальных рисков.

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

(Get-WmiObject Win32_OperatingSystem -EnableAllPrivileges).Win32Shutdown(5)

(GWMI -Class Win32_Service -Filter name='WinRM' -ComputerName Server).StopService()

Кроме того, на удаленной машине эти действия выполнить так же просто, как на локальной достаточно написать имя нужной машины в пути к WMI-объекту.

Пространство имен WMI это раздел репозитория WMI, который призван группировать классы и объекты WMI по назначению, плюс, определять атрибуты безопасности при доступе к классам и объектам в каждом таком контейнере. Все пространства имен начинаются с корня, который в WMI обозначается ключевым словом root. После имени корня через косую черту указывается пространство имен. Пространства имен могут быть вложенными. Большинство интересных классов и объектов размещается в пространстве имен root/CIMv2.

Одно из существующих в Windows пространств имен WMI может быть выбрано по умолчанию. Это означает, что если вы попытаетесь подключиться к этому хосту, не указав пространство имен, то вы автоматически будете подключены к выбранному по умолчанию. В стандартной инсталляции Windows по умолчанию выбрано пространство root\cimv2.

Технология WMI предназначена для администраторов Windows, и вся система безопасности в WMI устроена так, чтобы с помощью сценариев WMI пользователь мог на заданном ПК выполнить лишь те действия, на которые ему даны разрешения/привилегии. Это так называемые привилегии по умолчанию. Так реализуется безопасность WMI на уровне операционной системы: если пользователю на уровне операционной системы не дана привилегия перезагружать компьютер, то и с помощью WMI он и не сможет этого сделать.

Дополнительные политики безопасности в WMI реализованы на уровне пространств имен протокола Distributed СОМ (DCOM) распределенной объектной модели компонентов. Чтобы более подробно рассмотреть эти типы безопасности WMI, кратко напомню основные общие понятия, связанные с безопасностью в Windows. А основана эта безопасность на именах пользователей и их паролях.

О разрешениях WMI

Когда в Windows создается пользователь, его системной учетной записи присваивается уникальный идентификатор безопасности (Security IDentifier или SID). На основе SID для пользователя формируется маркер доступа (Access Token), в который также добавляется список групп, членом которых является пользователь и список привилегий, которыми он обладает (например, остановка служб или выключение компьютера). Этот маркер доступа присваивается также всем процессам, которые запускает пользователь. В это время каждый объект операционной системы, доступ к которому определяет система безопасности файл, либо процесс, либо служба или что-то ещё, имеет дескриптор безопасности (Security Descriptor, SD). В этом дескрипторе, в свою очередь, хранится список контроля доступа (Access Control List, ACL) для этого объекта.

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

На уровне пространств имен механизм безопасности WMI соответствует общей модели безопасности Windows. Каждое пространство имен может иметь собственный дескриптор безопасности, на котором хранится список контроля доступа (ACL).

Каждая запись списка контроля доступа (Access Control Entry, АСE) содержит информацию о том, какие разрешения имеет определенный пользователь при выполнении различных операций в этом пространстве имен.

А вот и список разрешений при работе с пространством имен:

Выполнение методов (Execute Methods). Позволяет вызывать методы классов из определенного пространства имен. Будет ли метод выполнен или произойдет отказ, зависит от того, имеет ли пользователь разрешение на выполнение этой операции в системе.

Полная запись (Full Write). Разрешает создавать и модифицировать подпространства имен, системные классы и экземпляры классов.

Частичная запись (Partial Write). Открывает возможность создавать и модифицировать любые статические классы и экземпляры несистемных классов.

Запись поставщика (Provider Write). Позволяет записывать в репозиторий CIM классы провайдеров WMI и экземпляры этих классов.

Включить учетную запись (Enable Account). Предоставляет право чтения пространства имен WMI. Пользователи с этим разрешением, могут запускать на локальном компьютере сценарии, которые читают данные WMI.

Включить удаленно (Remote Enable). Разрешает пользователям получить доступ к пространству имен WMI на удаленном компьютере. По умолчанию этим разрешением обладают только администраторы, обычные пользователи не могут получать данные WMI с удаленных машин.

Прочесть безопасность (Read Security). Дает право читать дескриптор безопасности для пространства имен WMI без возможности его модификации.

Изменение правил безопасности (Edit Security). Позволяет изменять дескриптор безопасности для пространства имен WMI.

Все эти записи списка контроля доступа хранятся в репозитории WMI. Разрешения WMI для конкретного пространства имен применяются ко всем подпространствам имен и классам, которые определены в этом пространстве (наследуются ими). Собственные же разрешения безопасности для отдельного класса WMI определить нельзя.

О настройке по умолчанию

В Windows группа администраторов обладает всеми разрешениями из таблицы выше, а для остальных пользователей включена учетная запись (Enable Account), разрешено вызывать методы (Execute Methods) и записывать в CIM экземпляры классов провайдеров (Provider Write).

Администратор может изменить разрешения для определенных пользователей с помощью утилиты для настройки параметров WMI (оснастка wmimgmt.msc консоли управления ММС).

Скриншот 1.


Для доступа к инфраструктуре WMI на удаленном компьютере используется вышеуказанный протокол DCOM. Пользователь запускает сценарий или подключается к WMI с помощью специальных утилит и выступает в качестве клиента, а объект WMI, к которому идет обращение, является сервером. Чтобы определить, какой маркер доступа будет применяться при работе с WMI на удаленном компьютере, используются стандартные уровни имперсонации протокола DCOM.

Об имперсонации или Impersonation Levels

По-русски звучит несколько коряво. Что такое имперсонация и зачем она нужна? Это метод, при котором для подключения к ресурсу процесс или система должны использовать не свой контекст безопасности, а учетные данные другого субъекта безопасности.

Представьте некая служба, запущенная в контексте безопасности LocalSystem, должна выполнить действие от лица другой учетной записи (например, от лица текущего зарегистрированного на компьютере пользователя). В этом случае службе необходимо создать специальный маркер доступа (Access Token), описывающий контекст безопасности той учетной записи, под которой мы хотим выполнить указанное действие.

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

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

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

Представьте: пользователь подключается не напрямую к базе данных, а через веб-приложение на третьем сервере. Для осуществления такого подключения веб-приложение должно получить от субъекта безопасности (нашей службы) маркер доступа с правом делегирования это позволит веб-приложению использовать маркер доступа субъекта безопасности уже при подключении к базе данных.

В случае с WMI делегирование может выглядеть так: мы, работая на станции администратора, подключаемся по WMI к некому серверу и запускаем на нем процесс с помощью метода Execute класса Win32_Process. Этот процесс не что иное, как другой скрипт WMI, который подключается к ещё одному хосту в сети для того, чтобы совершить какие-то действия. Если мы не воспользуемся делегированием, то на конечной машине скрипт будет запущен в контексте безопасности учетной записи промежуточного сервера, что далеко не всегда желаемо. С другой стороны, подобная ситуация с делегированием в реальной жизни случается достаточно редко.

Об уровнях Impersonation Levels

Анонимный доступ (Anonymous). Объект-сервер не имеет права получить информацию о пользователе или процессе, который обращается к данному объекту (иными словами, объект не может олицетворить клиента). Этот уровень олицетворения в WMI не используется.

Идентификация (Identify). Объект-сервер может запросить маркер доступа, связанный с клиентом, но не может произвести олицетворение.

В сценариях WMI этот уровень олицетворения используется редко, в этом случае нельзя запускать сценарии WMI на удаленных машинах.

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

Делегирование (Delegate). Объект на сервере, к которому обращается клиент, может обратиться от имени клиента к другому объекту на другом сервере. Делегирование позволяет сценарию использовать на удаленной машине маркер доступа запустившего его пользователя. Тот же маркер используется для доступа к объектам WMI на других рабочих станциях. Применение данного уровня олицетворения связано с потенциальным риском, делегирование в сценариях WMI следует применять только в случае особой необходимости.

Выбираемый по умолчанию уровень олицетворения зависит от версии WMI на целевом компьютере. В версиях WMI ниже 1.5 по умолчанию используется уровень Идентификация (Identify), в версии WMI 1.5 и выше Олицетворение (Impersonate). При необходимости можно изменить уровень олицетворения по умолчанию для этого необходимо записать наименование нужного уровня (например, impersonate или Delegate) в ключ реестра
HKEY_LOCAL_MACHINE\Software\Microsoft\Wbem\Scripting\Default Impersonation Level.

Скриншот 2.


Протокол DCOM также предоставляет возможность запросить для соединения WMI определенный уровень аутентификации (проверки подлинности) и конфиденциальности:

Отсутствует (None). Проверка подлинности отсутствует.

По умолчанию (Default). Для выбора уровня проверки подлинности используются стандартные настройки безопасности. Рекомендуется использовать именно этот уровень, так как к клиенту будет применен уровень проверки подлинности, который задается сервером.

Подключений (Connect). Клиент проходит проверку подлинности только во время подключения к серверу. После того как соединение установлено, никаких дополнительных проверок не производится.

Вызовов(Call). Клиент проходит проверку подлинности в начале каждого вызова, во время приема запросов сервером. При этом заголовки пакетов подписываются, однако сами данные (содержимое пакетов), передаваемые между клиентом и сервером, не подписываются и не шифруются.

Пакет (Pkt). Проверке подлинности подвергаются все пакеты данных, которые поступают серверу от клиентов. Как и при проверке подлинности на уровне вызовов, заголовки пакетов подписываются, но не шифруются. Сами пакеты не подписываются и не шифруются.

Целостности пакетов (Pktlntegrity). Все пакеты данных проходят проверку подлинности и целостности. Проверяется, что содержимое пакета не было изменено во время передачи от клиента серверу. При этом данные подписываются, но не шифруются.

Привилегии (PktPrivacy). Все пакеты данных проходят проверку подлинности и целостности, при этом данные подписываются и шифруются, что обеспечивает конфиденциальность передаваемых данных.

Администраторам Windows хорошо известны настройки безопасности системы, доступные в консоли безопасности системы и групповых политиках домена и раздел User Right Assignments (привилегии пользователей). Ряд действий с операционной системой можно проделать только при наличии у пользователя или группы, куда он входит, той или иной привилегии. К таким действиям, например, относятся: перезагрузка системы (завершение её работы), восстановление состояния системы из резервной копии или смена системного времени.

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

Резюме

Что предлагается сделать для обеспечения безопасности WMI-подключений:

1. Изменить уровень имперсонации для критичных сервисов (Скриншот 2).
2. Настроить разрешения wmimgmt.msc (Скриншот 1).
3. Изменить репозиторий по умолчанию. Это может нарушить сценарий шаблонных атак.

4. Изменить группы лиц с возможностями удаленного запуска и активации WMI через утилиту DCOMCNFG



5. Чтобы запустить WMI пользователь должен быть членом группы administrators либо DCOM users. Также должна быть доступна служба remote registry.

6. Настроить файервол входящие подключения к DCOM идут по 135 TCP-порту и (имеют?) динамический диапазон RPC.



В заключение хочу сказать следующее: WMI дает скорость, мощь и легкость запуска команд на удаленных хостах, а SQL based-семантика команд делает его легким для освоения.

В интернете очень много информации о взломах и WMI-атаках, ведь они вписываются в нынешний атакующий тренд использование нативных инструментов взлома системы наряду с telnet NTP и DNS. Наша задача этот тренд уловить и найти методы противодействия уже заложенные в систему.

Автор: Галиулин Тимур GTRch

Предисловие

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

Изменения начального набора

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



У данного комбинезона внутри имеются 6 выступов разного размера. Крайний левый и крайний правый большого размера, они нажимают выключатели кнопочного типа на самой игрушке. Для работы модификаций мы срезали выступы большего размера обычными кусачками-бокорезами.

Модификации

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

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



Модификация, условно названная нами цветок:



Модификация, условно названная нами вертолёт:



Модификация, условно названная нами колокольчик:



Модификация, условно названная нами молоток:



Модификация, условно названная нами пингвинёнок:



Модификация, условно названная нами листок:



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

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

Вывод

Электронное устройство-игрушка Лего Супер Марио это сложное устройство, которое, тем не менее, поддаётся модификациям, доступным широкому кругу потребителей.

Автор: Шамиль Саитов Nikodim_Tychoblin