Оглавление:

• Работа с Hyper-V без домена
• Брандмауэр Hyper-V
• Диспетчер Hyper-V
• Удаленное управление дисками

Самое важное!

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

Файл образа сервера весит 1.65 Гб и называется

9200.16384.WIN8_RTM.120725-1247_X64FRE_SERVERHYPERCORE_EN-US-HRM_SHV_X64FRE_EN-US_DV5.ISO

Сразу после установки настройте сеть (пункт 8) и установите обновления (пункты 5 и 6). Если все прошло успешно, значит, можно двигаться дальше. Если нет - проверяйте, что и как. Призрком возможных проблем на этом этапе для вас является невозможность поставить обновления.

Работа с Hyper-V без домена

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

Добавьте локального администратора (пункт 3 конфигурации сервера, например "hyperadmin / hyperpwd"), чтобы не использовать администратора по-умолчанию). Такого же пользователя (можно не админа) надо добавить на машине, с которой будете подключаться через RDP. При создании пользователя на своей машине я в поле "Описание" так и написал: для подключения к HYPER-V 2012".

Брандмауэр Hyper-V

Так как в основном я планирую использовать консоль MMC для управления виртуальными машинами, то будет удобно предусмотреть дополнительную остнастку для управления брандмауэром сервера. Это сэкономит много времени, т.к. я не планирую заниматься регулярными правками правил - сервер должен просто работать. И держать в голове синтаксис PowerShell и CMD мне не хочется, хватит с меня и Linux. Поэтому я включу удаленный доступ к брандмауэру! Учитывая, что управлять сервером по-хорошему надо через выделенную для этого сеть (физически, VLAN), мой вариант не уменьшит общую безопасность. Как вариант, можно между хостом и сетью ставить программно-аппаратный брандмауэр, например, Mikrotik (без WiFi, конечно). Это совсем недорогое решение при приемлемой производительности и надежности.

Включить возможность удаленного управления брандмауэром можно выполнив консольную (все-таки никуда без консоли) команду:

netsh advfirewall firewall set rule group="Windows Firewall Remote Management" new enable=yes

После этого можно запустить на рабочей станции консоль mmc с правами "hyperadmin" и добавить оснастку "Брандмауэр Windows" (у меня в Windows 7 она называется "Брандмауэр Windows в режиме повышенной безопасности") и указать IP-адрес нашего сервера Hyper-V. Все :)

Но несмотря ни на что, консоль - самое надежное средство управления. Я все равно все выполняю в консоли, а смотрю, что к чему, в GUI в разделе "Наблюдение - брандмауэр". Просто я не собираюсь все держать в голове. И эта статья один из вариантов how-to для меня самого с вашими комментариями и дополнениями.

Диспетчер Hyper-V

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

Запускаем Диспетчер Hyper-V от имени пользователя "hyperadmin" и слева вверху нажимаем "Подключитсья к серверу". Опять же по IP.

Диспетчер Hyper-V в Windows 7 расчитан на управление Hyper-V 2008, а не 2012. Такие опции, как Live и Storage Migrations будут доступны только из Windows 8 (из Windows 7 через PowerShell - пожалуйста, но не через графический интерфейс). Поэтому я решил установить Windows 8 (триала достаточно, пока что) для сравнения "как оно работает" через Windows 8. Ничего так, появились возможности преобразования дисков VHD в VHDX, те же кнопочки миграций, про которые упоминал чуть выше. Ну, здорово, конечно, но если определиться с терминологией и знать, что вы точно хотите, то можно обойтись и PowerShell и старой доброй 7-кой (еще недавно так же говорили про "старую добрую XP-шку").

Чтобы диспетчер Hyper-V из Windows 8 показал вам список виртуальных машин, нужно скачать замечательный скрипт hvremote (http://archive.msdn.microsoft.com/HVRemote) и запустить его на рабочей станции с правами администратора:

cscript hvremote.wsf /mmc:enable
cscript hvremote.wsf  /AnonDCOM:grant

Можно еще проверить, все ли получилось:

cscript hvremote.wsf /show /target:имя_или_ip_вашего_hyper-v_сервера

Не парьтесь по поводу того, что он еще версии 0.7, которая еще может глючить в Windows 8 и 2012. Все работает! Вот теперь можно будет увидеть ваши виртуальные машины (когда мы их создадим, конечно).

Лирическое отступление для перехода к следующему разделуПодключились, радуемся, начинаем устанавливать гостевую виртуалку... Стоп! А как выбрать место под диск VHD для виртуалки? Диск на 500 Гб в процессе установки отформатирован не был - не нужно было. И сейчас я имею возможность размещать гостевые системы только на диск C:\. А диск-то 60 Гб всего. Т.е. всего-то нужно открыть диспетчер жестких дисков, отформатировать в NTFS и переназначить буквы дисков (DVD будет E:\, диск 500 Гб будет D:\ - я ненавижу, когда DVD висит между дисками :)). КАК ЭТО СДЕЛАТЬ???

Удаленное управление дисками

Для удаленного управления дисками (Disk Management), надо выполнить следующие шаги:

1. Запустить службу Virtual Disk Service (VDS) на сервере

Просмотр списка служб (service), названия которых начинаются на "R" с помощью PowerShell:
Get-Service -Name r*

Запуск службы VDS (Virtual Disk Services):

net start vds

Если потребуется, разрешите “Remote Volume Management” на клиентском компьютере (с которого будем управлять нашим сервером).

Если бы мы не отключили брандмауэр полностью, то дальше надо было бы выполнить пункт 2.

2. Разрешить "Управление дисками" (Disk Management).

Netsh advfirewall firewall set rule group=“Remote Volume Management” new enable=yes

Запускать консоль управления оснастками MMC необходимо от имени пользователя локального админа на нашем сервере (в нашем случае "hyperadmin / hyperpwd"):

В оснастке добавить "Управление дисками" (не локальный компьютер, а удаленный, например, по IP-адресу).

Ну, собственно, начальная рутина закончилась. Теперь можно спокойно создавать виртуальные машины. Диспетчер Hyper-V также надо запускать от имени "hyperadmin / hyperpwd".

Собственно, дальше все достаточно просто, тем более что дошедший до этого момента читатель, скорее всего, знает, что и для чего он делает и объяснять работу консоли в этой статье я не буду.

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

Источник: carantin2006.narod.ru

В этом тексте все ссылки ведут на postfix.org, который, к сожалению, на английском. Но сам по себе документ достаточно самодостаточен, поэтому можете особо не расстраиваться!

Введение

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

Темы, охваченные в документе:

• Управление пересылкой (relay), блокировка спам-а(junk mail), политики для отдельных пользователей (per-user policies)
• Ограничения, которые воздействуют на всю SMTP почту
• Списки ограничений для отдельных этапов SMTP соединения
• Отложенная обработка списков управления доступом к SMTP
• Опасное использование smtpd_recipient_restrictions
• Тестирование правил доступа к SMTP

Управление пересылкой (relay), блокировка спам-а(junk mail), политики для отдельных пользователей (per-user policies)

В далеком прошлом Интернет представлял из себя дружественную среду. Почтовые сервера без ограничений пересылали почту от кого угодно кому угодно. Сегодня спамеры создают проблемы для серверов, которые пересылают почту от произвольных клиентов (т.н. open relay сервера), так как в последствии эти сервера могут быть добавлены в антиспамерские черные списки (anti-spammer blacklists).

По умолчанию, Postfix использует умеренно строгий подход к пересылке почты. Postfix пересылает почту только от клиентов из дружественных сетей (trusted networks) или для доменов, пересылка почты которым разрешена явно. Для ознакомления с поведением Postfix по умолчанию читайте описание параметра smtpd_recipient_restrictions, а также документацию, на которую ссылается указанное описание.

Большинство возможностей по управлению доступом к SMTP серверу Postfix направлены на борьбу со спамом.

• С ориентацией на протокол. Некоторые средства управления доступом к серверу SMTP блокируют почту от клиентов, которые нестрого придерживаются протокола SMTP. Таким образом, блокируются плохо реализованные и/или плохо настроенные спамерские программы, равно как и почтовые черви, которые пользуются собственной нестандартной реализацией SMTP клиента. Средства контроля, ориентированные на протокол, теряют эффективность со временем, так как спамеры и авторы вирусов учатся читать документы RFC.

• Ориентированные на черные списки. Некоторые средства управления доступом к SMTP серверу опрашивают черные списки (blacklists), в которых хранится информация о "плохих" сайтах таких, как открытые релэи (open mail relays), открытые WEB-прокси сервера, скомпрометированные домашние компьютеры, которые удаленно управляемы криминалитетом. Эффективность черных списков зависит от их полноты и актуальности (современости) информации (up to date).

• Ориентация на повышение требований. Некоторые средства управления доступом к SMTP серверу позволяют поднять планку требований для клиента, либо заставляя клиента выполнять больше работы (greylisting, серые списки), либо проводя дополнительные проверки (SPF[Sender Policy Framework] и проверку адресов отправителя/получателя). Серые списки и политики SPF реализованы вне Postfix и являются темой документа SMTPD_POLICY_README. Проверка адресов отправителя/получателя описана в документе ADDRESS_VERIFICATION_README.

К сожалению, все средства борьбы со спамом могут ошибаться, отвергая легитимные письма. Это может быть серьезной проблемой для сервера, обрабатывающего почту для большого количества пользователей. Для одних пользователей неприемлемо получение хоть одного письма спама, в то время как для других одно ошибочно отвергнутое легитимное сообщение может обернуться трагедией. Так как нет определенной политики, которая бы удовлитворяла пожеланиям всех без исключения пользователей, Postfix поддерживает разные ограничения по доступу к SMTP серверу для разных пользователей. Эта возможность описана в документе RESTRICTION_CLASS_README.

Ограничения, которые воздействуют на всю SMTP почту

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

• Встроенные ограничения по содержимому header_checks(проверки заголовка) и body_checks (проверки содержимого письма), которые описаны в документе BUILTIN_FILTER_README. Эти проверки производятся во время приема почты, до помещения письма в очередь входящих сообщений (incoming queue).

• Внешняя (посредством сторонних программ) проверка содержимого до помещения в очередь, которая описана в документе SMTPD_PROXY_README . Эта проверка выполняется во время приема почты, до помещения письма в очередь входящих сообщений (incoming queue).

• Требование к клиентам отсылать команду HELO или EHLO перед использованием команды MAIL FROM или ETRN. Это может вызвать проблемы при работе с "доморощенными" почтовыми клиентами. По этой причине ограничение отключено по умолчанию ("smtpd_helo_required = no").

• Запрет некорректного синтаксиса в командах MAIL FROM или RCPT TO. Это может вызвать проблемы при работе с "доморощенными" или древними почтовыми клиентами. По этой причине требование отключено по умолчанию ("strict_rfc821_envelopes = no").

• Запрет использования синтаксиса адресов RFC 822 (пример: "MAIL FROM: the dude <dude@example.com>").

• Запрет использования адресов, которые не заключены в угловые скобки <> (пример: "MAIL FROM: dude@example.com").

• Отклонение писем с несуществующим адресом отправителя. Эта форма фильтрации "на входе" может помочь в борьбе с "червями" и спамерами, но может вызвать проблемы при работе с "доморощенными" почтовыми клиентами, которые отсылают письма с несуществующим адресом отправителя. По этой причине данной ограничение отключено по умолчанию ("smtpd_reject_unlisted_sender = no").

• Отклонение писем с несуществующим адресом получателя. Эта форма фильтрации "на входе" помогает содержать почтовую очередь свободной от сообщений MAILER-DAEMON, которые не могут быть доставлены. Это ограничение включено по умолчанию ("smtpd_reject_unlisted_recipient = yes").

Списки ограничений для отдельных этапов SMTP соединения

Postfix позволяет задавать списки ограничений для каждого этапа SMTP диалога. Отдельные ограничения описаны на странице документации postconf(5) .

Примеры простых списков ограничений:

/etc/postfix/main.cf:
    # Разрешить соединения только от дружественных (trusted) сетей.
    smtpd_client_restrictions = permit_mynetworks, reject

    # Не общаться с почтовыми системами, которые не знают имени своего хоста.
    smtpd_helo_restrictions = reject_unknown_hostname

    # Не принимать почту от доменов, которые не существуют.
    smtpd_sender_restrictions = reject_unknown_sender_domain

    # "Белые" списки. Локальные клиенты могут указывать любого получателя. Другие клиенты не могут.
    smtpd_recipient_restrictions = permit_mynetworks, reject_unauth_destination

    # Блокировать клиентов, которые начинают общаться рано.
    smtpd_data_restrictions = reject_unauth_pipelining

    # Проверять квоты на объем почты, обращаясь к внешним сервисам. 
    smtpd_end_of_data_restrictions = check_policy_service unix:private/policy

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

# "Белые" списки. Локальные клиенты могут указывать любого получателя. Другие клиенты не могут.
    smtpd_recipient_restrictions = permit_mynetworks, reject_unauth_destination

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

Название списка ограничений	Статус	Эффект результата REJECT или DEFER
smtpd_client_restrictions	Опционален	Отклонять все команды клиента
smtpd_helo_restrictions	Опционален	Отклонять на основании информации HELO/EHLO
smtpd_sender_restrictions	Опционален	Отклонять на основании информации MAIL FROM
smtpd_recipient_restrictions	Необходим	Отклонять на основании информации RCPT TO
smtpd_data_restrictions	Опционален	Отклонять команду DATA
smtpd_end_of_data_restrictions	Опционален	Отклонять после получения команды END-OF-DATA
smtpd_etrn_restrictions	Опционален	Отклонять команду ETRN

Отложенная обработка списков управления доступом к SMTP

Ранние версии Postfix выполняли действия, предусмотренные списками ограничений доступа к SMTP, настолько рано, насколько это возможно. Список ограничения клиентов (client restriction list) проверялся перед тем, как Postfix отсылал приветствие "220 $myhostname..." SMTP клиенту. Список smtpd_helo_restrictions обрабатывался перед тем, как Postfix отвечал на команду HELO (EHLO). Список smtpd_sender_restrictions обрабатывался перед ответом на команду MAIL FROM. И так далее. Эта практика оказалась весьма сложной в применении.

Текущие версии Postfix откладывают обработку списков ограничения для клиентов, отправителей и HELO до получения команды RCPT TO или ETRN. Это поведение контролируется параметром smtpd_delay_reject. Списки ограничений обрабатываются в правильном порядке (client, helo, etrn) или (client, helo, sender, recipient, data, end-of-data). Когда список ограничений (например, client) выдает результат REJECT или DEFER, обработка последующих списков (пример: helo, sender, и т.д.) не выполняется.

В то время как был добавлен параметр smtpd_delay_reject, в Postfix также была введена поддержка смешанных списков ограничений, которые комбинируют информацию о клиенте, отправителе, получателе и информацию команд helo, etrn.

Преимущества отложенной обработки списков ограничений и смешанных списков:

• Некоторые SMTP клиенты не ожидают негативных ответов на ранних этапах SMTP сессии. Когда плохие новости откладываются до ответа на RCPT TO, клиент уходит, что и требуется, а не висит до разрыва соединения по таймауту, или, хуже того, входит в бесконечный цикл соединение-отказ-соединение.

• Postfix может регистрировать больше полезной информации. Например, когда Postfix отклоняет имя или адрес клиента и ждет команды RCPT TO, он получает информацию о адресе отправителя и получателя. Это полезнее, чем регистрация имени хоста и IP адреса клиента вкупе с полным незнанием того, чья почта была заблокирована.

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

Опасное использование smtpd_recipient_restrictions

Теперь читатель может спросить, зачем нужны списки ограничений client, helo или sender, если их обработка откладывается до команды RCPT TO или ETRN. Некоторые люди рекомендуют помещать ВСЕ ограничения в список smtpd_recipient_restrictions. К сожалению, это может привести к слишком доверчивому поведению SMTP сервера Postfix. Как это возможно?

Цель списка smtpd_recipient_restrictions - это управление тем, как Postfix отвечает на команду RCPT TO. Если список ограничения выдает результат REJECT или DEFER, то адрес получателя отклоняется, что и требуется. Если результат - PERMIT, то адрес получателя принимается. И здесь следует ждать сюрпризов.

Вот пример, который иллюстрирует вышеуказанную ситуацию:

1 /etc/postfix/main.cf:
2     smtpd_recipient_restrictions = 
3         permit_mynetworks
4         check_helo_access hash:/etc/postfix/helo_access
5         reject_unknown_hostname
6         reject_unauth_destination
7 
8 /etc/postfix/helo_access:
9     localhost.localdomain PERMIT

В 5-ой строке отклоняется почта от всех клиентов, которые не указывают правильное имя хоста в команде HELO. В строках 4-ой и 9-ой сделано исключение для некоторого клиента, который представляется, как "HELO localhost.localdomain".

Проблема этой конфигурации в том, что список smtpd_recipient_restrictions выдает результат PERMIT для ЛЮБОГО хоста, который анонсирует себя, как "localhost.localdomain". В результате, Postfix становится открытым релэем (open relay) для всех таких машин.

Чтобы избежать подобных недоразумений со списком smtpd_recipient_restrictions, вам следует помещать ограничения, не связанные с адресом получателя (non-recipient restrictions), ПОСЛЕ ограничения reject_unauth_destination, а не до него. В примере выше ограничение для HELO должно быть размещено ПОСЛЕ reject_unauth_destination, или, еще лучше, поместить ограничение HELO в список smtpd_helo_restrictions, где оно не вызовет проблем.

Тестирование правил доступа к SMTP

В Postfix имеются несколько возможностей, которые помогают тестировать правила доступа к SMTP:

• soft_bounce

  Это средство заменяет действия SMTP сервера REJECT на DEFER (попытаться позже). Это позволяет оставлять сообщения в очереди, которые в противном случае были бы возвращены отправителю. Укажите "soft_bounce = yes" в файле main.cf, чтобы предотвратить постоянное отклонение почты SMTP сервером Postfix. С этой целью Postfix заменит все коды ответов 5xx на 4xx.

• warn_if_reject

  Эта возможность позволяет заменить действия SMTP сервира REJRCT на замечания (warnings). Вместо отклонения команды клиента Postfix регистрирует, что он собирался отвергнуть. Укажите "warn_if_reject" в списке ограничений доступа к SMTP перед тем ограничением, которое вы хотите протестировать без реального отклонения почты.

• XCLIENT

  Благодаря этой возможности (Postfix 2.1 и последующие версии) авторизованные SMTP клиенты могут имитировать другие системы, таким образом вы можете проводить ралистичные тесты правил доступа к SMTP серверу Postfix. Примеры использования XCLIENT для тестирования правил доступа содержатся в документе XCLIENT_README.

Любопытная статья, немного из разряда мирового заговора. Не думаю, что это правда на 100%, но в качестве познавательно-развлекательного чтения приятно читать.

Источник: xakep.ru.

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

Еще до официального анонса новых процессоров Intel с поддержкой аппаратной виртуализации (в начале 2007 года) я задумал использовать эти чипы для создания единой вычислительной системы на базе нескольких серверов, которая стала бы для ОС и прикладных программ единой вычислительной установкой с SMP-архитектурой. Для этого требовалось написать компактный гипервизор с нестандартным функционалом, главной особенностью которого было бы не разделение ресурсов единой вычислительной установки между разными ОС, а наоборот, объединение ресурсов нескольких вычислительных машин в единый комплекс, которым бы управляла одна ОС. При этом ОС не должна была даже догадываться, что имеет дело не с единой системой, а с несколькими серверами. Аппаратура виртуализации предоставляла такую возможность, хотя изначально не предназначалась для решения подобных задач. Собственно, система, в которой аппаратура виртуализации применялась бы длявысокопроизводительных вычислений, не создана до сих пор, а уж в то время я вообще был первопроходцем в этой области.

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

Поскольку система виртуализации для этой цели получилась нестандартной и выглядела как полностью автономный компактный программный модуль (объем кода не более 40–60 Кб), язык как-то не поворачивался называть ее гипервизором, и я стал использовать термин "гипердрайвер", поскольку он более точно передавал суть функционального предназначения системы. Серийного оборудования с аппаратурой виртуализации в то время еще не было, однако благодаря сотрудничеству с фирмой "Крафтвей" я имел доступ к предсерийным образцам процессоров и материнских плат с поддержкой виртуализации, которые еще не выпускались официально (так называемым сэмплам, которые фирма Intel любезно предоставляет своим партнерам по бизнесу). Поэтому работа закипела на этом "сэмпловом" оборудовании.

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

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

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

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

Первым делом заменил процессоры, но это не помогло. На материнских платах в то время аппаратура виртуализации была только в биосе, где она инициализировалась во время включения сервера, поэтому я начал сравнивать биосы на материнских платах (однотипных платах с сэмплами) — все совпадало до байта и номера самого биоса. Я впал в ступор и, уже не зная, что делать, применил последнее средство — "метод тыка". Чего я только не делал, уже не думая, а просто комбинируя, и в конце концов тупо скачал биосы с официального сайта Intel и переписал их заново в материнские платы, после чего все заработало…

Моему удивлению не было предела: номер биоса был тем же самым, образы биоса совпадали побайтно, но по какой-то причине серийные материнские платы заработали только тогда, когда я залил в них такой же биос, взятый сайта Intel. Значит, причина все-таки в материнских платах? Но единственное их отличие было в маркировке: на сэмплах было написано Assembled Canada, а на серийных платах — Assembled China. Стало ясно, что платы из Китая содержат дополнительные программные модули, прошитые в биосе, а стандартные программы анализа эти модули не увидели. Они, видимо, тоже работали с аппаратурой виртуализации и, соответственно, имели возможность скрыть истинное содержимое биоса. Стала понятна и причина зависаний моего гипердрайвера на этих китайских платах: две программные системы одновременно работали с одной и той же аппаратурой виртуализации, которая не позволяла разделять свои ресурсы. Мне захотелось разобраться с этим зловредным биосом, причем без всякой задней мысли о "закладках", "бэкдорах", "недокументированных возможностях", был просто академический интерес, и не более того.

Нужно сказать, что параллельно с внедрением аппаратуры виртуализации Intel радикально обновила чипсет. Этот чипсет, получивший номер 5000х, выпускается в нескольких модификациях до сих пор. Южный мост этого чипсета, 631xESB/632xESB I/O Controller Hub, к которому подключены флеш-микросхемы с биосом, практически в неизменном виде выпускается с 2007 года и используется в качестве базового чипа почти для всех серверов в двухсокетном исполнении. Я скачал даташит на южный мост, прочел описание и просто обалдел. Оказывается, к этому новому южному мосту подключаются три микросхемы флеш-памяти: первая представляет собой стандартный биос, вторая выделена под программы процессора сетевого контроллера, а третья предназначена для интегрированного в южный мост блока ВМС.

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

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

Чтобы не быть голословным, привожу выдержку из документации на этот южный мост:

• ARC4 processor working at 62.5 MHz speed.
• Interface to both LAN ports of Intel® 631xESB/632xESB I/O Controller Hub allowing direct connection to the net and access to all LAN registers.
• Cryptographic module, supporting AES and RC4 encryption algorithms and SHA1 and MD5 authentication algorithms.
• Secured mechanism for loadable Regulated FW.

Применение иностранных криптографических средств с длиной ключа более 40 бит запрещено на территории России законодательно, а тут — пожалуйста! — в каждом сервере Intel криптомодуль с неизвестными ключами длиной 256 бит. Более того, эти ключи использовались для шифрования программ, зашитых в микросхемы материнской платы на этапе производства.

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

После ознакомления с документацией я насторожился, а когда обнаружил, что работоспособность гипердрайвера восстанавливается как раз после перепрошивки флеш-микросхемы блока ВМС, даже не удивился. Разбираться дальше без специальных стендов было невозможно, так как криптография полностью перекрывала возможности реверса кода для ВМС. Документации на внутреннюю архитектуру этого интегрированного ВМС я не нашел, в даташите на южный мост Intel описала только интерфейсные регистры для управления этим блоком по стандартным методам доступа, в результате чего получился классический "черный ящик".

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

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

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

Руки были связаны, но "мои мысли, мои скакуны" не давали мне покоя, было непонятно, зачем эти сложности и как все это сделано. Если у тебя есть возможность разместить собственное ПО в памяти блока ВМС, зачем тебе вся эта морока с центральным процессором? Разумной причиной могло быть только то, что решаемая задача требовала контролировать текущий вычислительный контекст на центральном процессоре. Очевидно, что уследить за обрабатываемой информацией на основной вычислительной системе, используя только периферийный низкоскоростной процессор с частотой 60 МГц, невозможно. Таким образом, похоже, задача этой нелегальной системы состояла в съеме информации, обрабатываемой на основной вычислительной установке, с помощью средств аппаратуры виртуализации. Дистанционно управлять всей нелегальной системой, конечно, удобнее с процессора блока ВМС, поскольку он имеет собственный независимый доступ к сетевым адаптерам на материнской плате и собственные МАС- и IP-адреса. Вопрос "как это сделано?" имел более академический характер, поскольку кто-то умудрился создать гипервизор, умеющий разделять ресурсы аппаратуры виртуализации с другим гипервизором и делающий это корректно для всех режимов, кроме реального режима работы ЦП. Сейчас такими системами уже никого не удивишь, но тогда, пять лет назад, они воспринимались как чудо, кроме того, скорость эмуляции поражала — программно эмулировать хост без значительных потерь в быстродействии было невозможно.

Для пояснения придется немного углубиться в теорию. Архитектура систем виртуализации Intel и AMD не предполагает наличия на платформе сразу нескольких гипервизоров, однако запущенный первым гипервизор может эмулировать для гипервизоров, которые запускаются после, работу на реальном оборудовании виртуализации. В этом случае все гипервизоры, запущенные вслед за первым, работают в эмулируемой среде хоста. Этот принцип я называю "правом первой ночи". Его можно легко реализовать с помощью специальных обработчиков в корневом хосте, при этом режим задачи существенно не изменится, а хосты вторичных гипервизоров будут выполняться в режиме задачи для корневого хоста. Режим эмуляции организовать не сложно, однако с быстродействием возникают проблемы. Аппаратура виртуализации работает в основном с блоком VMCB (VMCS), программы хоста постоянно обращаются к этому блоку, а на каждое такое обращение требуется 0,4–0,7 мкс. Скрыть такую программную эмуляцию хоста для системы виртуализации Intel практически невозможно, слишком много команд виртуализации придется эмулировать программно через выходы в корневой хост, вместо того чтобы выполнять их на реальном оборудовании.

Расскажу немного о различиях между архитектурами виртуализации. Системы аппаратной виртуализации от Intel и AMD совершенно не похожи друг на друга. Главное архитектурное отличие этих систем состоит в режиме работы хоста. В системе AMD хост работает с отключенной аппаратурой виртуализации, то есть его программы выполняются на реальном процессоре. Виртуализация вторичного хоста в системах от AMD требует виртуализации только команды VMRUN (можно считать, что других команд нет). Работа с управляющим VMCB-блоком в архитектуре AMD происходит через обычные команды обращения к оперативной памяти, что позволяет контролировать с помощью вторичного хоста только выполнение команд VMRUN и подправлять при необходимости VMCB-блок перед реальным входом в режим задачи. Удлинить цикл обработки события в два раза еще можно, и на платформе AMD такая эмуляция жизнеспособна. В системе виртуализации Intel все гораздо сложнее. Для доступа к VMCB-блоку используются специальные команды VMREAD и VMLOAD, которые нужно обязательно виртуализировать. Обычно обработчики хоста десятки, если не сотни раз обращаются к полям VMCB-блока, и каждую такую операцию нужно эмулировать. При этом заметно, что скорость падает на порядок, это очень неэффективно.

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

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

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

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

Надо заметить, что фирма Intel активно совершенствует аппаратуру виртуализации. Если первая ревизия аппаратуры, с которой я начал работать, имела номер 7, то описываемая ситуация произошла на 11-й ревизии, то есть приблизительно за год ревизия обновлялась дважды (ревизии почему-то имеют только нечетные номера). Так вот, на ревизии с номером 11 условия выходов в хост по состоянию задачи для аппаратуры виртуализации существенно расширились, в соответствии с чем в VMCB-блоке даже было введено новое управляющее поле. Когда появились сэмпловые процессоры с этой ревизией аппаратуры виртуализации, мне захотелось испытать новые возможности на практике. Я усовершенствовал гипердрайвер за счет новых возможностей 11-й ревизии аппаратуры виртуализации, установил сэмпловый процессор на серийную плату из Китая, в которой все уже работало без замечаний, и начал отладку. Новые возможности аппаратуры никак себя не проявили, и я опять впал в прострацию, греша на сэмпловый процессор и документацию. Через некоторое время материнская плата потребовалась для другой задачи, и я, возобновив эксперименты, для подстраховки переставил процессоры с 11-й ревизией аппаратуры виртуализации на канадский сэмпл. Каково же было мое удивление, когда на этом сэмпле все заработало!

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

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

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

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

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

Я все рассказал и показал, однако не был уверен, что технический специалист все понял. Эти так называемые технические специалисты по уровню своей компетенции мало отличаются от менеджеров. Однако он обещал доложить обо всем руководству. Не знаю, сделал ли он это, но никакой ответной реакции от Intel так и не последовало, все ушло как в песок. Работа в "Крафтвее" к тому времени завершилась, и я начал новый проект в фирме, связанной с системами информационной безопасности. Руководитель этой фирмы, с которым я поделился своими "открытиями", принял мои слова всерьез. В связи с этим было решено выйти на руководство Центра защиты информации и спецсвязи ФСБ. Эта структура в составе ФСБ занимается обеспечением информационной безопасности в стране и регулирует деятельность государственных и коммерческих организаций, которые имеют отношение к защите информации. Она также регламентирует меры по защите информации для госструктур и коммерческих фирм, обрабатывающих секретную и конфиденциальную информацию. Фирма, в которой я в то время работал, поддерживала с Центром официальные контакты, чтобы сертифицировать и лицензировать свои коммерческие проекты, поэтому организовать встречу на уровне специалистов было достаточно просто. Предполагалось, что эксперты Центра сообщат о своем мнении руководству, и если после этого руководство сочтет нужным выслушать нас, то следующим этапом будет встреча на более высоком уровне.

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

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

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

В общем, результат первой встречи оставил неприятный осадок, и я в самом мрачном настроении ожидал развития событий. Месяца через полтора нас пригласили уже в сам Центр защиты информации и спецсвязи, чтобы мы продемонстрировали обнаруженную нами закладку. На этот раз послушать нас собрались не рядовые сотрудники, а руководители и ведущие специалисты (по крайней мере, так они представились). Встреча превратилась в лекцию, меня внимательно слушали практически три часа, было видно, что они впервые слышат то, о чем я им рассказываю. Я перечислил новые уязвимости платформы х86, показал закладку и рассказал, как ее детектировать, ответил на множество вопросов. В конце нас поблагодарили, сказали, что тему нужно развивать в рамках специальных НИР, и на этом мы и расстались.

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

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

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

Когда все было готово, руководство фирмы опять вышло на ФСБ с предложением посмотреть работу нашей собственной закладки и убедиться в том, что технологии виртуализации представляют реальную угрозу. Но посмотреть на нашу закладку в деле никто не захотел, с самого верха поступила команда (я так и не узнал, чье именно это было распоряжение) с нами больше не общаться. Главные борцы за информационную безопасность не захотели нас слушать. Тогда, уже практически ни на что не надеясь, фактически для очистки совести, мы попытались донести информацию о проблеме до пользователей систем информационной безопасности. Мы связались с "Газпромом", чтобы проинформировать специалистов компании о современных угрозах для распределенных систем управления технологическими процессами. Удалось организовать встречу с руководством службы корпоративной защиты и управления комплексными системами безопасности этой корпорации. Специально для них была подготовлена более наглядная версия закладки с упрощенным командным интерфейсом. Закладка активировалась после загрузки на компьютер текстового файла, содержимое которого включало два слова — "Газпром" и "стоп", — расположенных в произвольном порядке. После этого компьютер умирал, но не сразу, а с задержкой в пять минут. Естественно, можно было сделать задержку и на сутки, но тогда мы бы не уложились во время, отведенное для демонстрации. Сотрудники "Газпрома" посетовали на низкий уровень информационной безопасности и заявили, что это не их дело, поскольку они руководствуются требованиями и правилами, которые устанавливает ФСБ. Круг замкнулся, стало понятно, что эту монолитную систему "информационной безответственности" не пробить.

За три с лишним года, которые прошли с тех пор, я ни разу не слышал, чтобы кто-нибудь говорил об аппаратуре виртуализации как об инструменте проникновения в целевые системы. Парадокс? Не думаю. Специфика темы в том, что мы узнаем только о провальных технологиях. О технологиях, которые не обнаружены, мы не знаем, а их авторы, конечно, молчат.

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

____________________

Добавил уже от себя еще ссылки на тему виртуализации и безопасности:

• Три поколения Intel vPro (thg.ru)
• Красная пилюля - аппаратная виртуализация в контексте информационной безопасности (vmgu.ru)
• Виртуальная Матрешка (vmgu.ru)

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

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

• Active UNDELETE
  Сайт программы: http://www.active-undelete.com/
  Стоимость лицензии: от $40.
   
• Ontrack EasyRecovery
  Сайт программы: http://www.krollontrack.com/data-recovery/
  Стоимость лицензии: от 7000 рублей.
   
• Zero Assumption Recovery
  Сайт программы: http://www.z-a-recovery.com/rus-index.html
  Стоимость лицензии: 500 рублей.

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

Сразу скажу, что в лидеры вышли Ontrack EasyRecovery и Zero Assumption Recovery.

1-е место. Zero Assumption Recovery восстановил самое большое количество фотографий, но при этом не сохранил данные о времени создания. А это для фотографий достаточно важно, особенно если их много. Также надо учитывать, что как только я увидел, что режим восстановления фотографий полнофункционален, я ограничился им. Возможно, в других режимах восстановления удаленных данных Zero Assumption Recovery сработал бы лучше. Также учитывайте, что эта программа стоит дешевле всех! В данной компании соотношение цена/качество просто зашкаливает. Правда, немного напрягает сайт без телефона и пр. Но это и есть цена вопроса ;)

2-е место. Ontrack EasyRecovery в режиме Raw recovery (другие режимы не помогли) показал чуть-чуть меньше фотографий, чем Zero Assumption Recovery. Зато Ontrack EasyRecovery сохранил данные о времени создания фотографий. Но цена!!!

Аутсайдер. Active UNDELETE сработал хуже всех (ну, примерно в 10 раз меньше восстановленных фотографий). Зато он показал оригинальные имена и время создания фотографий.

Вот такая маленькая статейка. В итоге выделился явный лидер: Zero Assumption Recovery при стоимости всего 500 рублей. Даже немного жаль, что мне нет необходимости что-то восстанавливать для себя - купил бы. Мало ли что? Удачи!

Последнее изменение: 03 апреля 2013 года.

Вступление

Это первая статья по настройке почтового сервера на Linux в составе Dovecot 2.0.9, Postfix 2.6.6, базой данных MySQL, интерфейсом администрирования PostfixAdmin, веб-интерфейсом к почте RoundCube и все это на CentOS 6.3.

Вообще, эту и все связанные с ней статьи я пишу для того, чтобы задокументировать всякие тонкости, с которыми я сталкивался при настройке почтового сервера на CentOS. А заодно уж и поделюсь с общественностью приобретенным опытом. Несмотря на то, что все в этой статье прошло проверку не раз и не два, вы должны понимать, что от релиза к релизу что-то чуть-чуть меняется, от того, прописано у вас имя хоста или нет, где-то что-то может сработать не так, как здесь написано. Директория /var/log/ должна стать вашим хорошим знакомым :) В этом нет ничего страшного.

Я уже где только не предлагал - скажу еще раз - есть отличный проект iRedMail.org, с помощью которого вы можете легко и просто установить все, что описано ниже и даже намного больше. Я тестировал этот продукт, мне понравилось. По-крайней мере, вы получаете на своем любимом дистрибутиве работающий почтовый сервер. И не за 2-3 дня, а сразу. А зачем я тогда писал эту  и сопутствующие статьи? Мне не нужны антиспамы и прочее для внутреннего корпоративного сервера. Мне не нужны куча привязок и заморочек, так что обновить что-либо достаточно непросто. Наконец, я хочу понимать, что происходит в моем сервере.

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

Оглавление

1. Установка базы данных MySQL, в которой будем хранить настройки пользователей, список доменов и пр.
2. Установка веб-сервера Apache для доступа к инструментам управления почтовым сервером
3. Установка PostfixAdmin для управления почтовым сервером (пользователи, виртуальные домены и др.).
4. Postfix - МТА, отвечает за доставку почты (SMTP).
5. Dovecot - IMAP, POP3, авторизация, хранение почты.

Итак, поехали!

Предварительная настройка сети в CentOS

На свежеустановленной системе (например, из дистрибутива minimal, без X-Window) перед началом настройки проверьте настройки сети:

> ifconfig

Если сетевой интерфейс не активен (в выводе только lo), то надо подправить файл:

# vi /etc/sysconfig/network-scripts/ifcfg-eth0

a) адрес сети получаем через DHCP (пример):

DEVICE="eth0"
BOOTPROTO="dhcp"
NM_CONTROLLED="yes"
ONBOOT="yes"
TYPE="Ethernet"

б) адрес сети установлен вручную (пример): 

DEVICE="eth0"
BOOTPROTO="static"
NM_CONTROLLED="yes"
ONBOOT="yes"
TYPE="Ethernet"
IPADDR=192.168.1.2
NETMASK=255.255.255.0
BROADCAST=192.168.1.255
NETWORK=192.168.1.0
NOZEROCONF=yes

DNS-сервер: 

# vi /etc/resolv.conf

nameserver 127.0.0.1
nameserver your_provider_dns_ip

Шлюз по-умолчанию:

# vi /etc/sysconfig/network

GATEWAY=192.168.1.1

После этого перезагрузите компьютер и попробуйте пропинговать, например, yandex.ru. Если все ок, идем дальше, непосредственно к программному обеспечению.

1. Установка MySQL

Как вариант, посмотрите здесь.

1.1 Установка и минимальная настройка

# yum install mysql-server mysql-devel
# service mysqld start
# /usr/bin/mysql_secure_installation

На этом шаге:

1) установили пароль на root:

Set root password? [Y/n] y
New password: mySQL_passWord

2) удалили анонимный вход:

Remove anonymous users? [Y/n] y
 ... Success!

3) ограничили вход только localhost:

Disallow root login remotely? [Y/n] y
 ... Success!

4) удалили тестовую базу и безпарольный вход:

Remove test database and access to it? [Y/n] y
 - Dropping test database...
 ... Success!
 - Removing privileges on test database...
 ... Success!
 
 5) обновили новые настройки:
 Reload privilege tables now? [Y/n] y
 ... Success!

1.2 Создание базы данных для Postfix и Dovecot

[root@localhost ~]# mysql -p
Enter password:

mysql> CREATE DATABASE mail;
mysql> CREATE USER 'postfix'@'localhost' IDENTIFIED BY 'postfixPassword';
mysql> GRANT ALL PRIVILEGES ON `mail`.* TO 'postfix'@'localhost';
mysql> exit

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

Следующий шаг: установка веб-сервера.

2. Установка Apache

Собственно, сам веб-сервер:

> yum install httpd

Необходимые библиотеки:

> yum install php
> yum install php-mysql
> yum install php-mbstring
> yum install php-imap

3. Установка PostfixAdmin

Скачиваем архив с сайта (на 03.04.12 это будет версия 2.3.5):

> cd /var/www/html
> wget http://downloads.sourceforge.net/project/postfixadmin/postfixadmin/postfixadmin-2.3.5/postfixadmin-2.3.5.tar.gz
> tar xvfz postfixadmin-2.3.5.tar.gz

Получаем папку /var/www/html/postfixadmin-2.3.5/

Дальше создадим ссылку на эту версию postfixadmin и отредактируем файл начальной конфигурации PostfixAdmin:

> ln -s /var/www/html/postfixadmin-2.3.5/ /var/www/html/postfixadmin/
> nano /var/www/html/postfixadmin/config.inc.php

В файле изменяем:

$CONF['configured'] = true; // По-умолчанию, false
$CONF['database_name'] = 'mail'; // По-умолчанию, postfix
$CONF['database_password'] = 'postfixPassword'; // Пароль от пользователя postfix в базе данных.
$CONF['encrypt'] = 'dovecot:CRAM-MD5';

Закрываем файл, перезапускаем веб-сервер:

> service httpd restart

Открываем в браузере адрес вида: http://почтовый_сервер/postfixadmin/setup.php

Запоминаем пароль от настроек PostfixAdmin ("postfixAdminPassword") и жмем "Generate password hash".

Получаем ответ:

If you want to use the password you entered as setup password, edit config.inc.php and set
$CONF['setup_password'] = '785c37b013896e6d19dc57ecec:60965d6fe4d785c37b013a65a9836bf877aceecb';

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

Я введу email "admin@mailserver.local" и пароль "adminPassword".

Пробуем залогиниться со страницы: http://почтовый_сервер/postfixadmin/

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

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

Теперь самое время перейти к главному - к установке и настройке собственно почтового сервера.

Начем, пожалуй, с сервера SMTP - Postfix.

 Бонус!!! Лучше всего ставить после установки Postfix и Dovecot.

Ставим Roundcubemail

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

Сразу могу порекомендовать оригинал инструкции по установке Roundcubemail.

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

> mkdir /var/www/html/webmail
> cd /var/www/html/webmail
> wget http://downloads.sourceforge.net/project/roundcubemail/roundcubemail/0.7.2/roundcubemail-0.7.2.tar.gz
> tar xvfz roundcubemail-0.7.2.tar.gz
> mv roundcubemail-0.7.2 roundcubemail
> rm roundcubemail-0.7.2.tar.gz
> cd /var/www/html/webmail/roundcubemail

Ок, у нас есть заготовка по адресу /var/www/html/webmail/roundcubemail/

Копируем оригиналы конфигов (мало ли что?):

> cp config/db.inc.php.dist config/db.inc.php
> cp config/main.inc.php.dist config/main.inc.php

Создаем базу данных Roundcubemail:

> mysql -p
Enter password:

mysql> CREATE DATABASE roundcubemail;
mysql> CREATE USER 'roundcubemail'@'localhost' IDENTIFIED BY 'roundCubePassword';
mysql> GRANT ALL PRIVILEGES ON `roundcubemail`.* TO 'roundcubemail'@'localhost';
mysql> exit

Правим config/main.inc.php:

$rcmail_config['default_host'] = 'localhost';
$rcmail_config['imap_auth_type'] = PLAIN;
$rcmail_config['smtp_server'] = '';
$rcmail_config['enable_installer'] = true; (после установки изменить на false!!!)

Правим config/db.inc.php:

$rcmail_config['db_dsnw'] = 'mysql://roundcubemail:roundCubePassword@localhost/roundcubemail';

Ставим необходимые расширения php:

yum -y install php-dom php-intl

Пользователь, от имени которого запускается веб-сервер, должен иметь возможность записывать в директории temp и logs:

# chown -R apache:apache /var/www/html/webmail/roundcubemail/logs
# chown -R apache:apache /var/www/html/webmail/roundcubemail/temp
# ls -al /var/www/html/webmail/roundcubemail/

Запускаем установщик http://почтовый_сервер/webmail/roundcubemail/installer/

Инициализируем базу данных нажатием кнопки «Initialize Database».
Проверяем отправку и авторизацию стандартными средствами Roundcubemail.

На этом этапе может быть будут всякие мелочи, их лучше решить сразу и не идти дальше. Например, если у вас пароли не PLAIN, а, скажем, MD5 или еще как, у вас могут возникнуть проблемы. В принципе, именно из-за этого я был вынужден отказаться от шифрования паролей. Мы все-таки состыковываем кучу софта (веб-морду, dovecot, postfix, mysql, потом возможно еще что-то), и различия в терминах алгоритмов шифрования и др. делают работу с зашифрованными паролями настолько трудной, что я пока забил на это. Если кто-то знает работающую схему шифрования паролей, в комментариях напишите об этом и опишите как вы это сделали. Мы работаем для себя и для всех, по крайней мере, на этом сайте!

После прохождения тестов Roundcube напишет вам такое:

After completing the installation and the final tests please remove the whole installer folder from the document root of the webserver or make sure that enable_installer option in config/main.inc.php is disabled.

These files may expose sensitive configuration data like server passwords and encryption keys to the public. Make sure you cannot access this installer from your browser.

Запрещаем повторную переустановку приложения в main.inc.php:

$rcmail_config['enable_installer'] = false;

Удаляем установщик:

# rm -f -r /var/www/html/webmail/roundcubemail/installer

Заходим по адресу http://почтовый_сервер/webmail/roundcude/ и наслаждаемся web интерфейсом.

Обратите внимание: доступ через веб-сайт к каталогу config должен быть запрещен!. Для этого надо в конфиге Apache изменить "AllowOverride None" на "AllowOverride All", чтобы файл .htaccess, поставляемый вместе с Roundcube, заработал.

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

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

Защищенный документ Word сохранить как HTML

Запустите программу Microsoft Word, выполните команду «Файл» – «Открыть» либо нажмите кнопку «Открыть» на стандартной панели инструментов. Выберите документ, который необходимо разблокировать. Чтобы убрать защиту документа Word, выполните команду «Файл» – «Сохранить как». Выберите место сохранения, тип файла установите «Веб-страница» и нажмите «Ок». После этого можно выполнить снятие защиты документа Word.

Откройте папку, в которую вы сохранили документ как веб-страницу. Этот файл будет иметь расширение HTML. Щелкните правой кнопкой мыши на этом документе, выберите команду «Открыть с помощью», чтобы убрать защиту документа, выберите программу Notepad. Найдите с помощью команды «Поиск по» в коде документа следующий тэг: <w:UnprotectPassword>, в этом тэге, в свою очередь, найдите строку, она будет выглядеть приблизительно таким образом: w:nprotectPassword>ABCDEF01</w:UnprotectPassword>. Между тэгами и будет пароль для изменения документа. Чтобы убрать пароль из документа, скопируйте его в буфер обмена, далее откройте документ в программе Word и разблокируйте, используя найденный пароль.

HEX-редактор снимет защиту!

Также можно открыть документ в шестнадцатеричном редакторе, найти значение пароля, перезаписать его четырьмя 0x00. Далее откройте документ в Word, и используйте пустой пароль, чтобы убрать защиту документа.

Снять защиту с документа путем [DOC ->] DOCX -> ZIP -> DOCX

[DOC ->] означает, что если вам надо снять защиту с документа, уже в формате DOCX, то этот шаг можно пропустить и сразу менять расширение файла на ZIP.

Сохраните документ в формате .docx. Измените расширение файла на .zip (вызовите контекстное меню на файле, нажмите «Переименовать», удалите .docx, вместо этого впишите .zip). Откройте полученный архив, выделите файл settings.xml, нажмите кнопку «Извлечь». Откройте данный файл с помощью текстового редактора, найдите следующий тег <w:documentProtection ... />, удалите его. Далее добавьте файл settings.xml в архив, подтвердите замену файла. Переименуйте архив в файл с расширением .docx. Откройте документ в программе Word – защита снята.

Источник: kakprosto.ru

PS: Кстати, аналогично снимается защита и с документов Exel.

Автор: Иванов Илья, сайт http://bozza.ru, дата публикации 28.03.2012.

Задача: нужно объединить несколько компьютеров в сеть. Но при этом один из компьютеров подключен в Москве через ADSL, а другой в Берлине... Все без внешних IP. За этими компьютерами сидят ваши хорошие знакомые - юрист и повар. Объснять им, что такое VPN - себе дороже :) Я не придумал ситуации, в которой этих людей может быть надо объединить в сеть... ну, например, погамиться в какую-нибудь игру, но не на публичном сервере. Вот!

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

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

Готовим виртуальную сеть в Hamachi

Нам нужно создать VPN сеть поверх интернета. причем максимально просто и удобно. Открываем сайт https://secure.logmein.com/RU/products/hamachi/, регистрируемся и входим в свой аккаунт. Нам даже не потребуется скачивать Hamachi на наш компьютер (по крайней мере, сразу не потребуется).

Выбираем "Создать сети" и создаем ячеистую сеть с именем "my_test_bozza_network":

Устанавливаем базовые настройки для вашей сети:

• добавлять членов сети только из веб-интерфейса
• придумываем пароль (в нашем случае он не потребуется, но все равно придумываем!)
• выбираем бесплатную подписку на 5 хостов

Ок, наша сеть готова, надо добавить в нее хосты - наших друзей!

Щелкаем "Мои сети" (слева), потом "Добавить клиента". Выбираем пункт "Развернуть LogMeIn Hamachi на удаленном компьютере (компьютерах)":

Далее мы указываем количество планируемых установок программы-клиента Hamachi на компьютеры друзей (3 установки), указываем, чтобы они сразу становились членами сети "my_test_bozza_network":

На следующей странице вы получите ссылку вида https://secure.logmein.com/hamachi/ih1.asp?lang=ru&c=0023023020320302032030сссссссссс, которую надо любым способом передать вашим друзьям, например, по почте. Когда ваши друзья откроют эту ссылку в своем браузере, они смогут скачать и установить уже настроенный клиент.

Удаленный клиент ставит у себя необходимое ПО

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

После нажатия на кнопку "Продолжить" будет предложено скачать Hamachi в виде установочного пакета на свой компьютер. Соглашаемся, запускаем, далее, далее, ставим галочку "Добавить ярлык на рабочий стол", оставляем галочку "Запустить Hamachi". Получим:

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

Вот пример того, как может выглядеть клиент 2:

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

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

Послесловие

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

Скачать Hamachi можно со страницы https://secure.logmein.com/RU/products/hamachi/. Это лучше, чем скачивать Hamachi с других источников, т.к. вы скачиваете не просто программу, а программу, которая будет объединять ваши компьютеры (читайте, приватные данные) через интернет. Думайте сами, где вероятнее всего не подцепить вирус или шпиона.

Все-таки внесу-ка немного сумятицы. Дело в том, что несмотря на заверения программы-производителя LogMein о шифровании стойкими ключами, о неподкупности сотрудников и надежности физически изолированных серверов (это я взял из руководства по безопасности Hamachi, на англ. языке, называется "LogMein Белай книга по безопасности" - хехе, назвали бы ее "Черной Книгой Великого Хакера"), фактически весь начальный трафик все равно идет через их сервера. Т.е. они представляют собой широко разрекламированный MIM (Man in the Middle). Что это такое, объяснять уже почти никому не надо. Вот и получается, что либо надо просто им довериться или пользоваться только для домашних целей, что я и описал выше.

Если вам бедет необходимо создавать такие фишки для работы, все-таки более предпочтительным все еще можно считать настройку своего VPN-сервера (например, OpenVPN) и раздавать клиентам готовые конфиги. Это сложнее, не спорю. Но это 100% ваш сервер. Ну вот, немного пофлудил, буду ждать отзывов и комментариев!

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

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

Пример 1: вывод открытых портов в linux:

$ sudo lsof -P -i
COMMAND     PID     USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
rdiffweb    518     root    5u  IPv4  16947      0t0  TCP 192.168.2.30:8080 (LISTEN)
sshd        549     root    3u  IPv4  16398      0t0  TCP *:22 (LISTEN)
sshd        549     root    4u  IPv6  16400      0t0  TCP *:22 (LISTEN)
nginx       555     root    8u  IPv4  10996      0t0  TCP *:18081 (LISTEN)
nginx       556 www-data    8u  IPv4  10996      0t0  TCP *:18081 (LISTEN)
nginx       557 www-data    8u  IPv4  10996      0t0  TCP *:18081 (LISTEN)

где:
-P - не резолвить номера портов в стандартные названия (например, если порт 443, то не писать https, а именно 443);
-i - отображать сетевые соединения (Internet socket files)

Пример 2: объединение опций

Например, нужно показать сетевые соединения, связанные с процессом nginx.

$ sudo lsof -c nginx -i

выдаст длинную портянку данных, в которых явно будут лишние сведения. Почему? Потому что lsof выдал объединенный вывод: и по опции -i, и по опции -c nginx. 

Если нужно объединение опций по принципу && в программировании, то нужно указать опцию -a:

$ sudo lsof -c nginx -a -i
COMMAND PID     USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
nginx   555     root    8u  IPv4  10996      0t0  TCP *:18081 (LISTEN)
nginx   556 www-data    8u  IPv4  10996      0t0  TCP *:18081 (LISTEN)
nginx   557 www-data    8u  IPv4  10996      0t0  TCP *:18081 (LISTEN)
nginx   558 www-data    8u  IPv4  10996      0t0  TCP *:18081 (LISTEN)
nginx   559 www-data    8u  IPv4  10996      0t0  TCP *:18081 (LISTEN)

А вот это то, что нужно.

В данном случае вывод равнозначен такой команде:

$ sudo lsof -i | grep nginx
nginx       555     root    8u  IPv4  10996      0t0  TCP *:18081 (LISTEN)
nginx       556 www-data    8u  IPv4  10996      0t0  TCP *:18081 (LISTEN)
nginx       557 www-data    8u  IPv4  10996      0t0  TCP *:18081 (LISTEN)
nginx       558 www-data    8u  IPv4  10996      0t0  TCP *:18081 (LISTEN)
nginx       559 www-data    8u  IPv4  10996      0t0  TCP *:18081 (LISTEN)

Но это лишь в данном случае. Но если забыть про опцию -c, то grep может выручить.

Другие примеры с lsof:

• lsof -i 4 -a -p 1234 (просмотр всех соединений IPv4, открытых процессом с PID = 1234)
• lsof /dev/hd4 (Список открытых файлов на устройстве /dev/hd4)
• lsof /dev/cdrom (Список процессов, работающих с CD ROM)
• lsof -c ssh (Список подключений по ssh)
  Опция -c  показывает все открытые файлы, которые используются процессами, имя которых начинается с заданной строки.
   
• lsof -ni | grep ssh (Еще один способо получить список подключений по ssh)
  
  выдаст нечто вроде
  
  sshd 2599 root 3u IPv6 8613 TCP *:22 (LISTEN)
sshd 3924 root 3u IPv6 9286804 TCP 10.8.0.181:22->10.8.0.178:nat-stun-port (ESTABLISHED)
sshd 3926 myuser 3u IPv6 9286804 TCP 10.8.0.181:22->10.8.0.178:nat-stun-port (ESTABLISHED)
sshd 15109 root 3u IPv6 10572657 TCP 10.8.0.181:22->10.8.0.178:4461 (ESTABLISHED)
sshd 15111 myuser 3u IPv6 10572657 TCP 10.8.0.181:22->10.8.0.178:4461 (ESTABLISHED)
sshd 22818 root 3u IPv6 10632880 TCP 10.8.0.181:22->10.8.0.178:8151 (ESTABLISHED)
sshd 22820 myuser 3u IPv6 10632880 TCP 10.8.0.181:22->10.8.0.178:8151 (ESTABLISHED)

DIG

Команда доступна для unix-систем.

Формат: dig имя_домена тип_записи

Пример:

$ dig bozza.ru mx
; <<>> DiG 9.3.6-P1-RedHat-9.3.6-16.P1.el5 <<>> bozza.ru mx
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49089
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 6

;; QUESTION SECTION:
;bozza.ru.                      IN      MX

;; ANSWER SECTION:
bozza.ru.               7200    IN      MX      10 mx.yandex.ru.

;; AUTHORITY SECTION:
bozza.ru.               2824    IN      NS      ns2.usedns.com.
bozza.ru.               2824    IN      NS      ns1.usedns.com.

;; ADDITIONAL SECTION:
mx.yandex.ru.           2636    IN      A       93.158.134.89
mx.yandex.ru.           2636    IN      A       213.180.204.89
mx.yandex.ru.           2636    IN      A       77.88.21.89
mx.yandex.ru.           2636    IN      A       87.250.250.89
ns2.usedns.com.         1258    IN      A       77.234.201.212
ns1.usedns.com.         2848    IN      A       78.111.80.5

Видно, что единственная запись MX это mx.yandex.ru. Другой вопрос, что у mx.yandex.ru есть не один IP ;)

HOST

Команда доступна для unix-систем.

Формат: host -t тип_записи имя_домена

Пример:

$ host -t mx bozza.ru
bozza.ru mail is handled by 10 mx.yandex.ru.

Кратко и по делу.

NSLOOKUP

Команда доступна в unix и windows системах.

Пример:

$ nslookup 
> set querytype=MX
> bozza.ru
Server:        192.168.0.1
Address:       192.168.0.1

Non-authoritative answer:
bozza.ru         MX preference = 10, mail exchanger = mx.yandex.ru

bozza.ru         nameserver = ns1.usedns.com
bozza.ru         nameserver = ns2.usedns.com
ns2.usedns.com   internet address = 77.234.201.212
ns1.usedns.com   internet address = 78.111.80.5

Вводить команду чуть дольше, зато не надо заходить в консоль unix-системы, если вы работаете в Windows.

Online проверка MX

Если не интересно выполянть команды в консоли, можно воспользоваться online сервисом проверки MX записей. Например, http://mxtoolbox.com. 

Он проверит, подсветит зелененьким, если все ок, предложит проверить в black list и др.

На странице http://mxtoolbox.com/NetworkTools.aspx сервис предложит вам кучу разных проверок (PTR, A, TXT, ping, header analizer и многие др.).

Но! Не всегда этот сервис выдаст вам те же результаты, что и проверка с консоли вашего сервера, т.к. чаще всего проверки начинаются тогда, когда что-то идет не так, а идти не так может как у "них", так и у "вас". А "у вас" лучше проверять с консоли того сервера, где возможны неполадки.

*****

Идею для этой заметки взял тут (неплохой, кстати, питерский хостинг).

Если по каким-то причинам вы хотите установить в сети вашей организации браузер, отличный от IE, то на выбор есть, само собой, Opera, Mozilla Firefox и Google Chrome. Я не буду, ясное дело, даже пытаться сравнить эти браузеры - это вопрос религии. Но с точки зрения регулярной поддержки установленного у пользователей софта тут есть о чем подумать. А именно о том, сколько усилий вам придется прилагать для того, чтобы устанавливать регулярно (а в последнее время прямо-таки с пугающим ускорением) выходящие новые версии браузеров. Дома вы, скорее всего, сидите под админом, софт сам справляется, вы только соглашаетесь. А на работе все иначе - не дай Бог у большинства юзеров будут права администратора! Часть юзеров все равно вынуждены будут сидеть под админами (локальными, не доменными!!!), ну а что насчет той армии, которая ничего не соображая, давит на все "ок", которым вы оградили все и вся, но софт-то надо обновлять! Ведь через дырявый браузер даже без прав админа, даже с антивирусом, пусть даже с лицензионной Windows, они рано или поздно, словят какую-нибудь гадость.

Продолжение следует...