У нас есть два сервера:

1) 1.1.1.1 - основной сервер (файлы, почта, что угодно иное), пользователь user1.
2) 2.2.2.2 - сервер, на котором хранятся резервные копии, пользователь user2.

Считаем, что раньше вы не настраивали доступ по ssh к серверам по ключам, а используете пароли. Заодно от паролей избавимся.

Идея: находясь на сервере 2.2.2.2, мы запускаем процесс копирования данных с основного сервера 1.1.1.1 (к себе, на 2.2.2.2).

Проверяем коннект ssh с паролем

Если мы с сервера 2.2.2.2 не сможем с паролем соединиться по ssh к 1.1.1.1, то дальше можно и не продолжать.

Готовим почву

На серверах установим rsync:

yum install xinetd rsync

Редактируем конфиг xinetd для rsync:

nano /etc/xinetd.d/rsync

...
disable = no
# flags         = IPv6
...

Создадим отдельного пользователя rsync без домашней директории и /sbin/nologin. Да, я люблю вместо общего nobody для важных задач создавать отдельных пользователей. Никогда не знаешь наперед, когда придется анализировать, что и где глючит.

Редактируем (создаем) минимальный конфиг rsync на сервере 1.1.1.1:

nano /etc/rsyncd.conf

uid = rsync
gid = rsync
use chroot = true
max connections = 5
pid file = /var/run/rsyncd.pid
motd file = /etc/rsync.motd

# Logging
log file = /var/log/rsyncd.log
transfer logging = true
log format = %t %a %m %f %b
syslog facility = local3
timeout = 300

service xinetd restart

Проверим:

netstat -lnpt | grep 873
tcp        0      0 :::873         :::*       LISTEN      16269/xinetd

Ок, xinetd слушает порт rsync и при запросе запустит его.

 

На сервере 2.2.2.2 (с которого будем коннектится) сгенерируем сертификат для доступа без пароля:

# ssh-keygen -f ~/.ssh/id_rsa -q -P "" -b 4096

где:

• -q - silense
• -f - имя файла ключа
• -P "" - пустой пароль
• -b 4096 - размер ключа, бит

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

# cat ~/.ssh/id_rsa.pub
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDLVDBIpdpfePg/a6h8au1HTKPPrg8wuTrjdh0QFVPpTI4KHctf6/
FGg1NOgM++hrDlbrDVStKn/b3Mu65//tuvY5SG9sR4vrINCSQF++a+YRTGU6Sn4ltKpyj3usHERvBndtFXoDxsYKR
CtPfgm1BGTBpoSl2A7lrwnmVSg+u11FOa1xSZ393aaBFDSeX8GlJf1SojWYIAbE25Xe3z5L232vZ5acC2PJkvKctz
vUttJCP91gbNe5FSwDolE44diYbNYqEtvq2Jt8x45YzgFSVKf6ffnPwnUDwhtvc2f317TKx9l2Eq4aWqXTOMiPFA5
ZRM/CF0IJCqeXG6s+qVfRjB root@cloudads

На сервере 1.1.1.1 (откуда будем копировать файлы).

Скопируем этот ключ на сервер 1.1.1.1, на который будем логиниться, в директорию пользователя user1, под которым будем логинитсья, в файл ~/.ssh/authorized_keys file.

Если директории .ssh на 1.1.1.1 не существует, создадим ее:

mkdir ~/.ssh
chmod 0700 ~/.ssh
touch ~/.ssh/authorized_keys
chmod 0644 ~/.ssh/authorized_keys

В файл ~/.ssh/authorized_keys копируем содержимое публичного ключа, созданного на сервере 2.2.2.2 (файл id_rsa.pub) и перезапускаем sshd:

# service sshd restart

Все, мы готовы проверить соединение с 2.2.2.2 на 1.1.1.1 по ssh:

ssh -i /home/user2/.ssh/id_rsa -p 22 user1@1.1.1.1

Если соединение прошло, можно двигаться дальше. Если нет - надо обязательно понять, где проблема (firewall, ошибка copy/paste ключа, забыли restart sshd, что-то еще).

Запускаем rsync через ssh

Мы будем копировать файлы /data/* с сервера 1.1.1.1 на сервер 2.2.2.2 в папку /backup/.

Формат простой: rsync [опции] [откуда] [куда]

rsync -avz -e "ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null" --progress 1.1.1.1:/data/data.zip /backup/

или так:

rsync -avz -e "ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null" --progress user1@1.1.1.1:/data/* /backup/

или даже так:

rsync -avz -e "ssh -p 22" --progress user1@1.1.1.1:/data/* /backup/

-e "ssh ..." - указываем, что хотим все передавать по ssh;
-p 22 - указываем порт, на котором работает ssh на сервере 1.1.1.1;
-a, --archive – архивный режим, включает рекурсивное копирование и сохранение прав и владельца;
-v - расширенный вывод;
-z - использовать компрессию данных;
user1 - локальный пользователь сервера 1.1.1.1, настроенный на логин по ssh по ключу.

Естественно, пользователь user1 должен иметь права доступа в /data/.

Вот и все. После копирования проверим, создался ли файл на сервере 2.2.2.2:

ls -al /backup/

Взято здесь.

Разделы:

• Winbox. Пожалуй, самое удобное средство настройки Mikrotik. Включает консоль и GUI.
• INPUT
• NAT
  •    Проброс портов
  •    Перенаправление трафика, адресованного одному ip, на другой ip
  •    Ловим любителей чужого ssh
• Готовый вариант настройки firewall для защиты роутера от внешнего интернет

Вместо вступления

Итак, имеем роутер Mikrotik, например, очень популярный RB951G-2HnD.

Считаем, что внутренняя сеть осталась нетронутой (192.168.88.0/24), IP роутера 192.168.88.1, внешний интерфейс ether1-gateway.

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

Доступ к терминалу через WinBox

Огромное преимущество WinBox состоит в том, что даже если сетевой адаптер компьютера, с которого вы подключаетесь к Mikrotik, находится в другой подсети (ну, настройка у вас такая), то WinBox все равно сможет подключиться к роутеру - по mac. Если вы еще не установили WinBox, самое время это сделать! В браузере открываем веб-интерфейс роутера и находим почти в самом низу ссылочку WinBox.

Запускаем WinBox и выбираем New Terminal.

Дальше все как в нормальных взрослых железках, по tab автодополнение команд и др. Вам понравится!

При вводе команд учтите, что внесенные изменения применяются сразу же, поэтому не заблокируйте сами себя. После ввода команд новые правила будут доступны для редактирования через WinBox или веб-интерфейс. Порядок правил имеет значение - выполняются сверху вниз. Где бы вы ни взяли сами команды, сначала посмотрите, что они делают!

Цепочка INPUT работает тогда, когда данные предназначены роутеру (его ip адресу). Когда мы что-то настраиваем для этой цепочки, мы в первую очередь защищаем сам роутер (ssh, telnet, веб-интерфес и др.) от взлома. Пожалуй, больше всего внимания требует именно эта цепочка. Общий принцип построения правил: явно запрещаем что-то (например, все новые соединения из интернета ;)) или явно что-то разрешаем (например, удаленный ssh), остальное запрещаем.

Цепочка FORWARD работает тогда, когда данные проходят через роутер, например, когда ваш локальный компьютер хочет открыть сайт ya.ru. Всякие блокировки на этом этапе защищают вас, например, от того, что зараженный компьютер в вашей локальной сети начнет рассылать спам или учавствовать в DDOS. Т.е. каждый банк-клиент, IM-месенджер и куча другого софта требуют своих особых разрешений, то если вы не защищаете банк от хакеров, то мы просто запретим некоторые наиболее распространенные виды трафика, которые используются зараженными компьютерами. А так весь проходящий из локалки в интернет (но не наоборот!) мы разрешим.

Цепочка OUTPUT работает тогда, когда данные генерятся на самом роутере и идут наружу. Например, для запросов DNS. Эту цеопчку по сути нам нет смысла фильтровать. Почти.

Цепочка forward позволяет нам разрешать или не разрешать проходящий трафик, а вот за то, какой трафик и куда мы будем перенаправлять, отвечают цепочки SRCNAT и DSTNAT.

Цепочка SRCNAT (Source NAT) предназначена для трафика, условно названного "наружу". Изменяется адрес источника (source) на адрес внешнего интерфейса. Например, чтобы дать возможность клиентам локальной сети посещать сайты в интернет.

Цепочка DSTNAT (Destination NAT) определяет как будет проходить "входящий" трафик. Роутер изменит адрес назначения (destination). Например, можно сделать доступным из вне веб сервер, размещенный в локальной сети.

INPUT

Минимальный набор правил - сделать недоступным из вне внешний интерфейс роутера.

/ip firewall filter
add chain=input connection-state=invalid action=drop comment="drop invalid connections"
add chain=input connection-state=related action=accept comment="allow related connections"
add chain=input connection-state=established action=accept comment="allow established connections"
add chain=input action=drop comment="drop everything else" in-interface=ether1-gateway

где в последнем правиле мы запрещаем весь входящий трафик на внешнем интрфейсе. Не играйтесь настройками удаленно! Легко лишить себя доступа к роутеру.

Далее, по мере надобности, можно будет помещать разрешающие правила перед последним запрещающим.

NAT

IP -> Firewall - NAT.  По-умолчанию, nat уже включен.Это правило "маскарадинга":

/ip firewall nat add chain=srcnat action=masquerade out-interface=ether1-gateway

Исходящий интерфейс (out-interface) всегда внешний, смотрящий и интернет (или просто в другую сеть, если у вас все непросто). В принципе, минимально этих правил nat и input уже достаточно. Учтите, что если у вас цепочка forward по-умолчанию блокирует все, что возможно, то надо добавить соответствующее правило:

/ip firewall filter add chain=forward out-interface=ether1-gateway

Примеры

Проброс портов

Предположим, вам надо сделать доступным веб-сервер (tcp/80), запущенный на локальной машине с IP 192.168.88.22.

/ip firewall nat add action=dst-nat chain=dstnat dst-port=80 in-interface=ether1-gateway protocol=tcp to-addresses=192.168.88.22 to-ports=80

Все бы ничего, но скорее всего, у вас включен firewall, который режет все, что не соответствует политике партии. Тогда надо разрешить forward пакетов:

/ip firewall filter add chain=forward protocol=tcp dst-port=80 action=accept

Это правило надо переместить повыше, т.е. ближе к началу списка правил.

Перенаправление трафика, адресованного одному ip, на другой ip

Если вам надо все подключения на один ip-адрес переадресовать другому ip-адресу:

/ip firewall nat add action=netmap chain=dstnat protocol=tcp dst-address=192.168.88.3 to-addresses=192.168.4.200

Ждем и давим, как блох любителей чужого ssh

Если мы не используем ssh для работы с Mikrotik, то нам может быть мало просто отключить ssh в IP -> Services. Если мы не пользуемся ssh, значит, любая попытка коннекта по ssh - вражеская!

Следующее правило добавляет IP-адреса источников (action=add-src-to-address-list), которые подключаются к 22 порту, в список ssh_blacklist, на 60 минут. Само это правило ничего не блокирует, просто заносит в черную книжечку:

/ip firewall filter
add chain=input protocol=tcp dst-port=22 address-list=ssh_blacklist action=add-src-to-address-list address-list-timeout=60m comment="record ssh brute forcers" disabled=no log=yes log-prefix=" --- SSH ATTEMPT --- "

А вот теперь, имея на руках список хулиганов (ssh_blacklist), можно банить им либо только работу с ssh, либо вообще любые действия в сторону нашего микротика:

/ip firewall filter
add chain=input protocol=tcp src-address-list=ssh_blacklist action=drop comment="drop ssh brute forcers"

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

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

Настройка с помощью скрипта

Вводить каждое правило firewall с консоли руками очень быстро может надоесть, к тому же готовый скрипт легко сохранить "на память". В открытом WinBox выбираем System -> Scripts. В текстовом редакторе готовим скрипт правил, копируем его и жмем Run Script. Потом можно что-то добавить по мелочи, что-то подправить, а может и опять скриптом все...

Приведу пример скрипта настройки firewall:

/ip firewall filter

# INPUT
add chain=input connection-state=invalid action=drop comment="drop invalid connections"
add chain=input connection-state=related action=accept comment="allow related connections"
add chain=input connection-state=established action=accept comment="allow established connections"

# ext input

# local input
add chain=input src-address=192.168.88.0/24 action=accept in-interface=!ether1-gateway

# drop all other input
add chain=input action=drop comment="drop everything else"

# OUTPUT
add chain=output action=accept out-interface=ether1-gateway comment="accept everything to internet"
add chain=output action=accept out-interface=!ether1-gateway comment="accept everything to non internet"
add chain=output action=accept comment="accept everything"

# FORWARD
add chain=forward connection-state=invalid action=drop comment="drop invalid connections" 
add chain=forward connection-state=established action=accept comment="allow already established connections"
add chain=forward connection-state=related action=accept comment="allow related connections"
	
add chain=forward src-address=0.0.0.0/8 action=drop
add chain=forward dst-address=0.0.0.0/8 action=drop
add chain=forward src-address=127.0.0.0/8 action=drop
add chain=forward dst-address=127.0.0.0/8 action=drop
add chain=forward src-address=224.0.0.0/3 action=drop
add chain=forward dst-address=224.0.0.0/3 action=drop

# (1) jumping
add chain=forward protocol=tcp action=jump jump-target=tcp
add chain=forward protocol=udp action=jump jump-target=udp
add chain=forward protocol=icmp action=jump jump-target=icmp

# (3) accept forward from local to internet
add chain=forward action=accept in-interface=!ether1-gateway out-interface=ether1-gateway
   comment="accept from local to internet"

# (4) drop all other forward
add chain=forward action=drop comment="drop everything else"

# (2) deny some types common types
add chain=tcp protocol=tcp dst-port=69 action=drop comment="deny TFTP"
add chain=tcp protocol=tcp dst-port=111 action=drop comment="deny RPC portmapper"
add chain=tcp protocol=tcp dst-port=135 action=drop comment="deny RPC portmapper"
add chain=tcp protocol=tcp dst-port=137-139 action=drop comment="deny NBT"
add chain=tcp protocol=tcp dst-port=445 action=drop comment="deny cifs"
add chain=tcp protocol=tcp dst-port=2049 action=drop comment="deny NFS"
add chain=tcp protocol=tcp dst-port=12345-12346 action=drop comment="deny NetBus"
add chain=tcp protocol=tcp dst-port=20034 action=drop comment="deny NetBus"
add chain=tcp protocol=tcp dst-port=3133 action=drop comment="deny BackOriffice"
add chain=tcp protocol=tcp dst-port=67-68 action=drop comment="deny DHCP"

add chain=udp protocol=udp dst-port=69 action=drop comment="deny TFTP"
add chain=udp protocol=udp dst-port=111 action=drop comment="deny PRC portmapper"
add chain=udp protocol=udp dst-port=135 action=drop comment="deny PRC portmapper"
add chain=udp protocol=udp dst-port=137-139 action=drop comment="deny NBT"
add chain=udp protocol=udp dst-port=2049 action=drop comment="deny NFS"
add chain=udp protocol=udp dst-port=3133 action=drop comment="deny BackOriffice"

add chain=icmp protocol=icmp icmp-options=0:0 action=accept comment="echo reply"
add chain=icmp protocol=icmp icmp-options=3:0 action=accept comment="net unreachable"
add chain=icmp protocol=icmp icmp-options=3:1 action=accept comment="host unreachable"
add chain=icmp protocol=icmp icmp-options=3:4 action=accept comment="host unreachable fragmentation required"
add chain=icmp protocol=icmp icmp-options=4:0 action=accept comment="allow source quench"
add chain=icmp protocol=icmp icmp-options=8:0 action=accept comment="allow echo request"
add chain=icmp protocol=icmp icmp-options=11:0 action=accept comment="allow time exceed"
add chain=icmp protocol=icmp icmp-options=12:0 action=accept comment="allow parameter bad"
add chain=icmp action=drop comment="deny all other types"

# (5) drop all other forward
add chain=forward action=drop comment="drop (2) everything else"

Обратите внимание: этот скрипт не привязан к внешнему IP или MAC или чему-то уникальному. Его можно брать и использовать. Если вы ничего не меняли в своем роутере и обновили до версии 6.* после покупки, вам на всякий случай следует проверить название внешнего интерфейса и убедиться, что внутренняя сеть 192.168.88.0/24. И все.

ether1-gateway - внешний интерфейс, первый по счету. Это его имя по-умолчанию. Остальные порты - внутренние.

В секции ext input ничего нет - мне не нужно, чтобы кто-то подключался к роутеру. Если вам необходим удаленный доступ к роутеру, скажем, по ssh, то впишите команду:

add chain=input protocol=tcp dst-port=22 action=accept in-interface=ether1-gateway comment="allow remote ssh"

В секции OUTPUT хватило бы и последней команды (add chain=output action=accept comment="accept everything"), но для интереса я немного разделил по исходящим интерфейсам. Теперь при беглом просмотре будет видно, есть ли вообще трафик от роутера, и если есть, куда он идет - наружу или в локалку. Скажем, увидим, что был трафик наружу, уточним правила по протоколам (tcp, udp, icmp). Если будет еще интереснее, можно будет поставить правило для логирования определенного вида трафика. Особо не увлекайтесь, все-таки роутер не имеет кучи места под логи. Да и лишний раз напрягать слабенький процессор тоже не очень.

Последнее правило (5) никогда не будет выполняться, я его добавил сюда специально, чтобы продемонстрировать работу jump. Последнее правило для цепочки forward будет (4) drop.

Т.е. предположим, мы запросили исходящее соединение с удаленным ssh-сервером (т.е. из локальной сети через через цепочку forward, протокол tcp, dst-port 22). Дойдя до блока (1) jumping, выполнится переход в (2) deny для tcp. Т.к. в цепочке tcp нет решения по поводу tcp/22, то выполнение вернется к (3), которое выполнит forward нашего пакета. Если наш пакет не удовлетворит требованиям (3), следующее за ним правило (4) блокирует его.

Наглядно это очень интересно смотреть, когда в окне Firewall видишь счетчик пакетов по правилам.

Если вы начали подозревать, что 100500 правок выполняют уже невесть что, просто выделяете все правила брандмауэра и нажимаете delete. Затем снова Run Script ;)

Чтобы не листать всю простыню, можно отфильтровать листинг правил по цепочкам (фильтр вверху справа):

Запаситесь терпением, не экспериментируйте в состоянии ночного анабиоза и второпях. В принципе, это все.

Внимание! PPTP признан небезопасным, поэтому настраивайте VPN на L2TP/IPSec. Естественно, тоже на Mikrotik. Но если вас это не смущает (и для истории), продолжайте читать дальше.

Допустим, сегодня первое апреля один юзер все время посещает vkontakte.ru и нет никаких сил это терпеть.

Совсем кстати у нас установлен и работает Squid и и мы полны решимости приколоться бороться!

Открываем /etc/squid/squid.conf и вписываем в него такие строчки:

acl vkuser src 192.168.1.122
acl vkontakte dstdomain vkontakte.ru
http_access deny vkuser vkontakte
deny_info http://google.com vkontakte

# service squid restart

Если кратко, пользователь с IP 192.168.1.122 при попытке набрать домен vkontakte.ru будет перенаправлен на поиск новой работы.

Вот и все, всем хорошего настроения!

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

«Под семью печатями»

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

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

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

Так что у нас для вас только один утешительный вывод: если вы активно переписываетесь через iMessage — можете спать спокойно, она «под семью печатями».

Сила шифра в iMessage

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

Во-первых, в основы шифрованния iMessage лежит протокол XMPP, а для доставки уведомлений используется APNS – Apple Push Notification Service. Стоит отметить, что этот протокол используют и другие системы, но Apple как всегда шагнула дальше и намного его модифицировала, потому, что в сравнении с оппонентами где размер уведомления не должен превышать 256 байтов, у Apple же все намного проще, поскольку сообщения не подвержены ограничениям и могут достигать больших размеров.

Касательно шифрования сообщения, мы поведаем вам это в более упрощенном и доступном варианте. При отправке сообщения –iPhone, iPad или Mac сначала устанавливают соединение с серверами iMessage которое защищено шифрованием TLS и дальше процесс происходит следующим образом: устройство с iOS 5 (или более новой) и сервер обмениваются между собой сертификатами, проверяя их подлинность и если каждая из проверок успешна с обеих сторон — только после этого устанавливается соединение.

Хитрости от iMessage

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

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

Также наблюдается интересная специфика касательно файлов, где сохранение их формата зависит от используемого канала для пересылки. То есть суть такова, если для пользователей не доступен Wi-Fi, а устройства находятся в 3G/2G сети, то пересылаемые изображения аудиозаписи меняют свой формат, а именно сжимаются до определенных пикселей и к размеру не больше 500 Кб. Это значит что файл, который должен получить адресат будет отконвертирован независимо от исходных характеристик. Но если оба собеседника, так сказать находятся в зоне Wi-Fi, то вложения не потерпят никаких изменений и будут доставлены в своем первозданном виде.

iMessage — убийцы SMS, так ли это?

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

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

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

А как утверждают независимые эксперты, в этом нет ничего такого. Apple всего лишь сделала услугу iMessage ответом на популярную услугу обмена сообщениями RIM BlackBerry Messenger, во многом благодаря которой производитель Канады смог привлечь больше клиентов к своим изделиям. Да и те же Google, Microsoft и Samsung работают над представлением своих собственных служб для передачи текстовых сообщений.

В любом случае каждый из вас делает свой выбор в пользу тех или иных услуг. Просто если вы являетесь обладателем девайса с iOS 5, то здесь, как говорится, «к гадалке не ходи»— вы пользователь SMS от Apple, поэтому теперь вы смогли еще раз убедится в преимуществах этой услуги в сравнении с услугами от мобильных операторов. Ну если же вы не пользовались iMessage, теперь вы точно сделаете ставку на эту услугу и явно не прогадаете.

Послесловие

То, что безопасность iMessage непосильна для спецслужб... Я к этому отношусь скептически. Тем более что информация об этом получена не от открытого сообщества (мол, исходники проанализировали, все ок), а исходя из того, что спецслужбы организовали утечку информации, что iMessage безопасен - дескать, шлите, хомячки, ваши секреты, мы бессильны. На их месте я бы сделал точно так же ))

Я не могу сказать, что очень переживаю, что американцы тратят свои налоги на чтение моей переписки с шефом и женой, но когда я пользуюсь Skype, iMessage, Gmail, то всегда имею ввиду, что даже если это не прочитают сразу онлайн (не тот у меня уровень угрозы США), то когда-нибудь где-нибудь это может быть использовано, хотя бы по причине подбора пароля к почте ))

Вот оригинал, откуда я это стащил :)

Т.к. PowerShell основан на .Net Framework, то вместе с PowerShell придется установить (вкючить) и его тоже, равно как и поддержку 32-битных приложений в 64-битных версиях Windows:

dism /online /enable-feature:NetFx2-ServerCore
dism /online /enable-feature:MicrosoftWindowsPowerShell
dism /online /enable-feature:NetFx2-ServerCore-WOW64

После этого можно запускать PowerShell одноименной командой PowerShell:

PowerShell Management Library for Hyper-V

По адресу http://pshyperv.codeplex.com/ лежит утилитка для упрощения администрирования виртуальных машин с описанием возможностей прямо на первой же странице. Почему не использовать? Также посмотрите эту страницу.

Полезное для PowerShell

Управление службами с помощью Power Shell: http://blog.wadmin.ru/2011/10/powershell-lessons-manage-services/.

На этой официльной странице на technet описаны командлеты, которые присутствуют по-умолчанию.

Оглавление:

• Работа с 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 рублей. Даже немного жаль, что мне нет необходимости что-то восстанавливать для себя - купил бы. Мало ли что? Удачи!