Танцы с бубном, загрузка с Recovery HD (для FileVault2 нужно держать нажатым Cmd+R всё время до появления интерфейса восстановления).

Загрузка в Verbose Mode показала безрадостную картину с chksum error:

Physical volume status Failed:

Ситуация усугубилась переходом на FileVault2 с CoreStorage. Всё было бы ничего, но инструментов для восстановления LVM нет. Функция Restore Disk в Disk Utility закончилась с ошибками, восстановление невозможно:

Почему произошёл сбой, я не могу сказать. Последний рестарт системы был плановым, завершился нормально. Последнюю неделю я много экспериментировал с созданием/удалением томов CoreStorage на других дисках, но системный диск я не трогал, да и примонтированный том изменить было бы нельзя. Можно грешить на OS X beta 10.7.2, но и здесь доказательств нет. Зашифрованный том CoreStorage на втором диске работают без замечаний, сбой произошёл только на системном.

При поиске в Google я нашёл и других таких же “счастливчиков”. Не буду обобщать, технологии CoreStorage и FileVault2 многообещающи, но перед их включением рекомендую как следует подумать и делать бекапы Time Machine (как минимум) и регулярные клоны в SuperDuper! (как максимум).

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

Хочу порекомендовать заранее продумать Disaster Recovery Plan. Нужно знать, что потеряешь при подобной ситуации и эти потери минимизировать. Например, даже этот единственный потерянный документ остался бы, если бы я держал его в Dropbox.

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

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

Ноутбук подключен кабелем в LAN-порт Time Capsule (не надейтесь на WiFi, восстановление займёт намного больше времени). Приступим.

Включил ноутбук, нажал при старте Cmd+R для загрузки с Recovery HD. Через несколько секунд отпустил. Появилось окно ввода пароля. Не то. Мало жал на Cmd+R. Выключение, включение. На этот раз Cmd+R держал от момента появления серого экрана, продолжал при появлении яблочка, отпустил при появлении интерфейса Recovery HD.

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

Конфигурация Time Capsule, перевод File Sharing от индивидуальных учётных записей к общему диску. Перезагрузка Time Capsule. Попытка выбора для восстановления сетевого диска TC, тишина.

Запуск терминала. На общем диске есть каталоги пользователей, мой бекап находится в моём каталоге. Логично. Но программа восстановления такое не понимает. Ладно. В терминале перенёс каталог sparse bundle image с бекапом в корень общего диска. Повторил выбор диска для восстановления. Наконец-то, увиделись бекапы.

Лёгкая прострация, последний бекап был в июле:

Потом вспомнил, что я переименовывал раздел с Macintosh HD на Lion. Выбрал нужный раздел в выпадающем списке, последние бекапы есть. Начал восстановление – но куда восстанавливать? Раздел на системном диске отсутствует.

Запустил Disk Utility. Выбрал мой диск. Удалить и создать новый раздел система даёт, но при попытке применения изменений говорит о невозможности отмонтировать диск.

Короткое размышление. Логично – система загружена с Recovery HD на этом же диске, а переразбивка подразумевает удаление всех разделов.

Вспоминаю о “Lion Recovery Disk Assistant“, нахожу в завалах хлама флешку (2 GB хватило), устанавливаю на неё Recovery HD (на другом Lion! Если бы его не было, то пришлось бы поиграть в “Ханойскую башню”).

Включаю ноутбук, держу Option, выбираю Recovery HD с флешки. Disk Utility, переразбиваю диск, применяю. Работает. Выбираю восстановление с Time Capsule, выбираю нужный раздел, выбираю последний бекап. Понеслось. Time remaining 2h. Реально восстанавливалось порядка часа. 10 минут назад было “Time remaining 1h 10m”, и тут перезагрука. Загрузился, система работает. 10.7.2 beta, кстати – при установке обновлений заодно обновляется и Recovery HD.

Пока не знаю, буду ли я включать FileVault 2. Подожду, подумаю, может что придумаю.

Disk Utility пока не может работать с CoreStorage, поэтому приходится использовать командно-строковую утилиту diskutil.

Нахожу, какой раздел мне нужно перекодировать (Data):

$ diskutil list
/dev/disk2
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *500.1 GB   disk2
   1:                        EFI                         209.7 MB   disk2s1
   2:                  Apple_HFS Legacy                  50.0 GB    disk2s2
   3:                  Apple_HFS Data                    449.6 GB   disk2s3

Запускаю конвертирование, обязательно указываю ключевую фразу (данные не уничтожаются во время этой операции):

$ diskutil corestorage convert /dev/disk2s3 -stdinpassphrase
New passphrase for converted volume: **********
...
Finished CoreStorage operation on disk2s3 Data
Encryption in progress; use `diskutil coreStorage list` for status

С разделом можно работать сразу же, его шифрование производится в фоновом режиме. Процесс достаточно длительный. Я даже перевёл ноутбук в Sleep, не дождавшись окончания, но после просыпания шифрование продолжилось. Статус шифрования можно посмотреть командой (прогресс не виден, только статус Converting/Complete):

$ diskutil coreStorage list
...
        Logical Volume Family 3E0D6C21-4178-4597-9F79-91E13A02E6FA
        ----------------------------------------------------------
        Sequence:               6
        Encryption Status:      Unlocked
        Encryption Type:        AES-XTS
        Encryption Context:     Present
        Conversion Status:      Converting
        Has Encrypted Extents:  Yes
        Conversion Direction:   forward

Когда шифрование завершится, “Conversion Status:” станет “Complete”.

Сделал замеры производительности до и после шифрования, результаты приведены ниже.

Последовательное и случайное чтение/запись небольших файлов

Без шифрования

С шифрованием

Скорость операций случайного чтения/записи почти не изменилась. Последовательных – изменилось незначительно. Интересно приведение скорости записи после шифрованию к нормальному виду (на первом графике скорость записи выше скорости чтения). Возможно шифрование привело к дефрагментации диска.

Чтение/запись больших файлов размером от 1 до 10 MB

Без шифрования

С шифрованием

Скорость изменилась незначительно, на глаз до 4-7%. Всплеск скорости записи после шифрования вероятно вызвано эффектом кеширования, добавляемым подсистемой шифрования.

Чтение/запись больших файлов размером от 10 до 100 MB

Без шифрования

С шифрованием

Кривые чтения и записи стали отличаться, на мой взгляд из-за большей ресурсоёмкости шифрования записи. Скорость записи ухудшилась на 15%, чтения – на 5%.

Чтение/запись файла 200 MB

Без шифрования

С шифрованием

Скорость записи ухудшилась на 8%, чтения – на 2%.

Вывод

При включении шифрования AES-XTS на жёстком диске 5400 rpm в ноутбуке с процессором Core 2 Duo без поддержки команд AES-NI наблюдается ухудшение скорости записи до 15%, а скорости чтения – до 8%. Что вполне приемлемо как плата за безопасность данных.

После включения FileVault 2 на моём ноутбуке пришло время создания очередного клона диска с данными (пока незашифрованного) и я решил совместить приятное с полезным – сравнить время создания клона одного и того же раздела на одинаковые внешние USB-диски.

На первом диске я создал логический том CoreStorage с шифрованием AES-XTS, на втором – без шифрования. И сделал два клона оригинального незашифрованного раздела с данными на 350 GB.

Замечу, что тестирование не отражает реальное падение производительности на шифрование данных – скорость упирается в производительность USB-интерфейса. Но для конкретного случая оно достаточно интересно.

На раздел с шифрованием клонирование шло 3 часа и 26 минут с эффективной скоростью 26.12 MB/s:

На раздел без шифрования – 3 часа и 23 минуты с эффективной скоростью 26.41 MB/s:

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

К сожалению, пока Disk Utility не поддерживает работу с томами CoreStorage, и зашифрованные разделы нужно создавать вручную.

Пока только при настройке диска для Time Machine я видел возможность включения шифрования:

Я, как и у многие люди, связанные с системным администрированием, немного параноик. Я считаю, что мои данные хотят украсть. Пусть они реально никому, кроме меня (“и множества злоумышленников, которые спят и видят, как получить мои фотографии, подборку музыки и фильмов, и…”, – это слова моего внутреннего параноика) и не нужны, но защититься не помешает.

Что произойдёт, если ноутбук украдут?

Самый простой случай – вор сразу же переформатирует диск и поставит чистую версию операционной системы. Останется купить новый ноутбук, восстановиться из Time Machine и спокойно продолжить работу. Этот сценарий характерен для умного вора, который знает о функции “Find My Mac” и о системе Pray.

Но есть другой случай – вор или глуп, или любопытен. Если глуп, то начнёт пользоваться ноутбуком, не трогая систему. Недавняя история поимки такого вора описана в статье “Why you don’t steal from a hacker“. Всё закончилось плачевно для вора и отлично для владельца ноутбука.

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

Начнёт изучать документы, ключи доступа, попробует добраться до Keychain, посмотрит историю команд в shell и возможно наткнётся на пароль (в моей практике был случай, когда очень быстрый коллега в сессии излишне любопытного пользователя вбивал пароль администратора, но вбил не в поле запроса пароля, а просто в shell, и пароль администратора попал в .history). Пароль в клиническом случае может быть единым для системы и для базы 1Password. Можно дальше не продолжать. А дальше – или проникновение, или шантаж.

Надеюсь, вы не думаете, что запрос пароля при входе в систему кого-то остановит? Firmware Password (по крайней мере раньше) сбрасывался фокусом с вынимаем одной из нескольких планок памяти, а затем очисткой PRAM. Потом – single user mode, пара команд, и пароль изменён. Если же не хочется возиться с Firmware Password, то диск вынимается из ноутбука, подключается к другому компьютеру и доступ ко всем данным получен.

Для защиты от описанной ситуаций был реализован FileVault. В первой версии пользовательский домашний каталог помещался в зашифрованный контейнер (sparse bundle image), ключом к которому служил пользовательский пароль. Не зная пароля, контейнер невозможно было открыть. Не нужно исключать возможность угадывания пароля, но если пароль был сложным, то данные были в полной безопасности.

За безопасность нужно платить. Для того, чтобы сделать резервную копию данных в Time Machine, нужно было выйти из учётной записи. Сделать выборочное восстановление через интерфейс Time Machine было нельзя. Включение шифрования ухудшало производительность файловых операций порой на 50%. Были и другие мелкие сложности.

В OS X Lion вошла улучшенная версия – FileVault 2, система шифрования полного диска, использующая алгоритм XTS-AES 128.

В процессе изучения вопроса я обращался к статьям MacFixIt “About FileVault 2 in OS X 10.7 Lion” и ArsTechnica “File system changes in Lion“.

Желающие разобраться с математическими моделями могут прочитать документ “IEEE P1619TM/D16 Standard for Cryptographic Protection of Data on Block-Oriented Storage Devices” и “Не такой уж ты и страшный, XTS-AES“.

Незашифрованными остаются раздел с EFI (интересующихся процессом обычной загрузки отсылаю к статье “Процесс загрузки Apple Mac Intel“) и Recovery HD:

$ diskutil list
/dev/disk0
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *160.0 GB   disk0
   1:                        EFI                         209.7 MB   disk0s1
   2:          Apple_CoreStorage                         159.2 GB   disk0s2
   3:                 Apple_Boot Recovery HD             650.0 MB   disk0s3

1. После инициализации “железа” EFI находит Recovery HD и передаёт управление загрузчику /System/Library/CoreServices/boot.efi, находящемуся на этом разделе.
2. У загрузчика есть два варианта – запустить EfiLoginUI из com.apple.boot.x и показать стартовый экран с запросом пароля входа, или же, если была нажата комбинация Option-R – оболочку восстановления системы из com.apple.recovery.boot.
3. Ключи для расшифровки диска хранится в файле EncryptedRoot.plist.wipekey в каталоге /com.apple.boot.x/System/Library/Caches/com.apple.corestorage. Пользовательский пароль расшифровывает ключи к диску, находящийся в этом файле. Дальше они хранится в памяти, расшифровка содержимого диска производится “на лету”. Каждый раз при изменении пользовательского пароля, добавлении нового пользователя и подобных операциях EncryptedRoot.plist.wipekey перегенерируется.

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

Производительность дисковых операций при включенном FileVault 2 согласно тестам Anandtech ухудшается не более, чем на 20-30%, что вполне приемлемо. Однако стоит учитывать, что есть зависимость от процессора и диска. Новые процессоры Intel используют наборы инструкций AES-NI для ускорения работы с AES Intel® Advanced Encryption Standard Instructions (AES-NI) и с шифрованием диска справляются лучше, чем старые процессоры Core 2 Duo. Решение каждый принимает сам на основании собственного железа.

При краже Mac’а получить доступ к данным будет практически невозможно (при условии сложного пароля и неочевидных ответов на вопросы восстановления ключа в Apple). Придётся просто купить новый Mac и особо не беспокоиться о компрометации паролей и использовании данных.

Time Machine работает теперь без необходимости выхода из учётной записи. Теперь нужно беречь данные Time Machine, а лучше размещать их в зашифрованном разделе (как это сделать, описано в статье Mac OS X Lion FileVault 2 and Time Machine External Drive Encryption).

Из “особенностей” нужно помнить, что при загрузке с зажатым Option раздел “Recovery HD” будет недоступен, для загрузки с него нужно удерживать комбинацию клавиш Command-R.

Активация

Активация FileVault 2 проста. System Preferences/Security & Privacy/FileVault, Click the lock to make changes, Turn On FileVault. Обязательно нужно в надёжном и обязательно зашифрованном месте сохранить ключ и ответы на вопросы восстановления ключа (если выбрали его сохранение в Apple). Система предложит перезагрузиться. Сразу же при загрузке будет запрошен ваш пароль и после входа вы сразу же сможете работать. Ждать часами завершения шифрования раздела не нужно, эта операция производится в фоновом режиме пока вы полноценно работаете:

С запуском iCloud появится возможность “Find My Mac”, в которой по аналогии с “Find My iPhone/iPad” при появлении Mac в сети можно отобразить сообщение с воспроизведением звукового сигнала, заблокировать Mac или даже уничтожить содержимое зашифрованного диска (могу предположить, что удаляются ключи шифрования и диск становится бесполезным массивом данных):

При получении команды блокировки (как только Mac станет доступен через Интернет) компьютер перезагружается, после чего запрашивается 6-ти значный код (вспомнился [троян Trojan.Win32.Buzus.hjzy](http://av-school.ru/desc/a-2117.html), который портит MBR и требует денег за код разблокировки):

Удобно, не так ли?

Если же вы организованы и не хотите терять производительность в угоду безопасности, то достаточно создать зашифрованный sparse bundle image и хранить секретные данные там. Я описывал процесс в статье “Работа с зашифрованными образами с помощью Knox (за деньги) и без него (бесплатно)“.

А именно двухэтапную аутентификацию и вход с помощью паролей приложений.

Это то, чего мне сильно не хватало. Задумайтесь на секунду, что вы потеряете с утерей учётной записи Gmail. И подумайте, сколько раз и в каких приложениях вы выдавали свои имя пользователя и пароль. Вероятнось компрометации увеличивается со временем использования.

А вот если включить двухэтапную аутентификацию, то кроме пароля будет запрошен краткосрочный код подтверждения, который генерируется, например, приложением Google Authenticator под iPhone, Android, Blackberry или получается по SMS, а если такой возможности временно нет, то есть несколько резервных кодов.

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

Кстати, приложение Google Authenticator под iPhone в отличие от конкурентов выглядит нормально, а не как поделка шестиклассника.

Я пользуюсь этими функциями уже месяца два и очень доволен. И вот пару дней назад у меня возникла простая мысль – а можно ли настроить двухэтапную аутентификацию для доступа к серверам по ssh?

После краткого изучения вопроса я нашёл статью “Two-factor SSH authentication via Google secures Linux logins“. Там описывается Fedora Linux, но инструкция легко адаптируется к той же Ubuntu 11.04, которую использую я.

Процесс таков:

$ sudo apt-get install subversion
$ sudo yum install libpam-dev
$ mkdir -p ~/tmp
$ cd ~/tmp
$ hg clone https://google-authenticator.googlecode.com/hg/ google-authenticator/
$ cd google-authenticator/libpam/

Компилирую с дополнительным флагом LDFLAGS, потому что иначе была бы ошибка “undefined reference to `dlopen’”:

$ LDFLAGS=-ldl make
$ sudo make install
$ sudo cp pam_google_authenticator.so /lib64/security
$ sudo cp google-authenticator /usr/local/bin

Редактирую конфигурацию PAM для sshd:

$ sudo vim /etc/pam.d/sshd

После строки

auth       required     pam_env.so envfile=/etc/default/locale

добавляю

auth       required     pam_google_authenticator.so

На сервере обязательно должен работать NTP, одноразовые коды генерируются синхронно.

Генерирую коды, текст сохраняю на память, там будут резервные коды на случай недоступности Google и URL с QR-кодом для настройки Google Authenticator

$ google-authenticator

Открываю выданный URL, сканирую QR-код в приложении Google Authenticator.

Правлю конфигурацию sshd, включая параметры ChallengeResponseAuthentication и UsePAM:

$ sudo vim /etc/ssh/sshd_config
ChallengeResponseAuthentication yes
UsePAM yes

Рестарт sshd:

$ sudo service ssh restart

Проверяю работу:

$ ssh ctrld@server
Verification code:
Password:
Welcome to Ubuntu 11.04 (GNU/Linux 2.6.38-10-generic x86_64)

Если неправильно ввести пароль, то доступа не будет:

$ ssh ctrld@udev
Verification code:
Password:
Verification code:
Password:
Verification code:

Одна особенность, решение которой я не искал – если других пользователей не настроена двухэтапная аутентификация, то их в систему по паролю не пустит:

sshd[7188]: error: PAM: Cannot make/remove an entry for the specified session for ctrld1 from 192.168.98.9
sshd(pam_google_authenticator)[7192]: Failed to read "/home/ctrld1/.google_authenticator"

Если настроена авторизация по публичному ключу, то двухэтапная аутентификация не производится.

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

Спасибо Google.

Зачем iPhone пытается соединиться с сетью передачи данных, если SMS ходят далеко не по IP, а MMS у меня не настроены?

Изучив вопрос, я выяснил, что при открытии Messages.app никакого обмена, кроме как с сервером Mobile.Me, не ведётся. Отключил синхронизацию контактов Mobile.Me – надпись перестала появляться.

Всё логично – при запуске Messages.app нужно убедиться, что контакты актуальны, и если они синхронизируются с Mobile.Me/Exchange/Google, то iPhone пытается соединиться с этими серверами. А если соединиться невозможно из-за отсутствия пакетного сервиса в метро, то обновление не пройдёт и выдастся сообщение, которое привело к моему желанию разобраться с этим вопросом.

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

Итак, у меня есть очень секретная финансовая информация, которую я доверил iBank:

Я знаю, что iBank можно закрыть паролем, поэтому ставлю длинный и сложный пароль:

Выхожу из iBank и иду спокойно заниматься своими делами, ведь мои данные надёжно защищены:

В это время к моему Mac’у подходит злоумышленник (это буду я же — не правда ли, это похоже на шизофрению). Даже если Mac заблокирован, но на нём не задействован FileVault, то процесс удлинится только на короткое время.

Запускает Terminal.app и выполняет несколько команд (для этого нужно лишь немного знать SQL):

$ sqlite3 topsecret.ibank/accountsData.ibank

sqlite> SELECT ZACCOUNT.Z_PK AS AccountNumber,
   ...> ZACCOUNT.ZNAME AS Name,
   ...> ZACCOUNT.ZTOTALBALANCE AS Balance,
   ...> ZCURRENCY.ZNAME AS Currency
   ...> FROM ZACCOUNT INNER JOIN ZCURRENCY ON ZACCOUNT.ZCURRENCY = ZCURRENCY.Z_PK
   ...> WHERE ZACCOUNT.ZTYPE is not null;

74|Наличные|-149990|Ukrainian Hryvnia

sqlite> SELECT ZTRANSACTION.ZTITLE, ZTRANSACTION.ZNOTE, ZLINEITEM.ZAMOUNT
   ...> FROM ZTRANSACTION INNER JOIN ZLINEITEM ON ZTRANSACTION.Z_PK = ZLINEITEM.ZTRANSACTION
   ...> WHERE ZLINEITEM.ZACCOUNT=74;

Balance Adjust||10
Очень секретная транзакция|Нельзя, чтобы кто-то увидел|-150000

За несколько минут злоумышленник узнал всю информацию по состоянию счетов и все транзакции.

Если злоумышленник ленив и не знает SQL, то он может скопировать файл topsecret.ibank/accountsData.ibank, потом создать базу iBank без пароля и подставить украденный файл. iBank даже не подумает запросить пароль.

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

Вывод прост. Если вы беспокоитесь за свои данные, то используйте шифрование FileVault или хотя бы помещайте конфиденциальную информацию в запароленые и закриптованые контейнеры SparseBundle Image, это можно проделать даже ничего не зная о Terminal.app — я описывал процесс в статье «Работа с зашифрованными образами с помощью Knox (за деньги) и без него (бесплатно)».

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

P.S. Если вы хотите поработать с базами SQLite без терминала, то обратите внимание на Navicat for SQLite (есть бесплатная Lite-версия для некоммерческого использования) — на мой взгляд она гораздо удобнее и лучше, чем Base и SQLiteManager.

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

На сайте сервиса сказано: “Secure transfers. Your notes are encrypted when they synchronize. Don’t settle for anything less.” Доверяй, но проверяй.

Недоверие небеспочвенное – Evernote в базовой версии шифрует только процесс авторизации, но сами заметки ходят по сети в открытом виде и их несложно перехватить по сети (в premium-версии все данные шифруются).

Запускаю Wireshark (вернее tshark из его поставки).

Сначала идёт запрос к DNS:

 0.957316 192.168.98.10 -> 192.168.98.1 DNS Standard query A simple-note.appspot.com
 0.967915 192.168.98.10 -> 192.168.98.1 DNS Standard query AAAA simple-note.appspot.com
 1.008348 192.168.98.1 -> 192.168.98.10 DNS Standard query response CNAME appspot.l.google.com A 74.125.43.141
 1.076173 192.168.98.1 -> 192.168.98.10 DNS Standard query response CNAME appspot.l.google.com

А потом идёт обмен с сервером, используя https (http/ssl), который является зашифрованным:

 7.594300 192.168.98.10 -> 74.125.43.141 TCP 51408 > https [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=3 TSV=690668493 TSER=0 SACK_PERM=1
 7.645497 74.125.43.141 -> 192.168.98.10 TCP https > 51408 [SYN, ACK] Seq=0 Ack=1 Win=5672 Len=0 MSS=1430 SACK_PERM=1 TSV=1824563333 TSER=690668493 WS=6
 7.645582 192.168.98.10 -> 74.125.43.141 TCP 51408 > https [ACK] Seq=1 Ack=1 Win=524280 Len=0 TSV=690668493 TSER=1824563333
 7.646058 192.168.98.10 -> 74.125.43.141 SSL Client Hello
 7.693433 74.125.43.141 -> 192.168.98.10 TCP https > 51408 [ACK] Seq=1 Ack=171 Win=6784 Len=0 TSV=1824563381 TSER=690668493
 7.693440 74.125.43.141 -> 192.168.98.10 TLSv1 Server Hello
 7.694298 74.125.43.141 -> 192.168.98.10 TLSv1 Certificate, Server Hello Done
 7.694355 192.168.98.10 -> 74.125.43.141 TCP 51408 > https [ACK] Seq=171 Ack=1723 Win=524280 Len=0 TSV=690668494 TSER=1824563381
 7.707143 192.168.98.10 -> 74.125.43.141 TLSv1 Client Key Exchange
 7.707186 192.168.98.10 -> 74.125.43.141 TLSv1 Change Cipher Spec
 7.707199 192.168.98.10 -> 74.125.43.141 TLSv1 Encrypted Handshake Message
 7.764833 74.125.43.141 -> 192.168.98.10 TCP https > 51408 [ACK] Seq=1723 Ack=357 Win=7872 Len=0 TSV=1824563453 TSER=690668494
 7.765683 74.125.43.141 -> 192.168.98.10 TLSv1 Change Cipher Spec, Encrypted Handshake Message
 7.765751 192.168.98.10 -> 74.125.43.141 TCP 51408 > https [ACK] Seq=357 Ack=1770 Win=524280 Len=0 TSV=690668494 TSER=1824563453
 7.766131 192.168.98.10 -> 74.125.43.141 TLSv1 Application Data
 7.766232 192.168.98.10 -> 74.125.43.141 TLSv1 Application Data
 7.813571 74.125.43.141 -> 192.168.98.10 TCP https > 51408 [ACK] Seq=1770 Ack=731 Win=8896 Len=0 TSV=1824563502 TSER=690668494
 8.111805 74.125.43.141 -> 192.168.98.10 TLSv1 Application Data, Application Data, Application Data, Application Data
 8.111879 192.168.98.10 -> 74.125.43.141 TCP 51408 > https [ACK] Seq=731 Ack=2412 Win=524016 Len=0 TSV=690668498 TSER=1824563800
...

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

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

На этот раз продемонстрирую этот подход на примере программы Knox, написанной компанией Agile Web Solutions, создателем 1Password. Knox за $34.95 реализует интерфейс к штатной возможности Mac OS X – Sparse Bundle Disk Image, позволяющей хранить данные в зашифрованных контейнерах, и при этом не заморачиваться с FileVault, который кроме высокой степени защиты ухудшает производительность системы и усложняет резервное копирование.

1Password просто обязан стоять на каждом Mac’е. А вот Knox – необязательно, если вы хоть немного дружите с Terminal или знаете, что такое Disk Utility. Поясню на примерах (также вы можете посмотреть статью “Использование Sparse Bundle Image для хранения базы данных Yojimbo, или как уменьшить объём бекапа“).

Итак, Knox находится в MenuBar и позволяет создавать, подключать, делать резервные копии контейнеров. Сами файлы находятся в ~/Documents/Knox.

Доступны такие общие настройки:

Удобство – в возможности подключать нужные образы при старте, а также подключать их по необходимости из меню.

Но если открыть System Preferences/Accounts/Login Items и перетащить туда файл образа из Finder, то при старте он будет открыт после ввода пароля (пароль можно сохранить в Keychain, и тогда образ подключится без лишних вопросов):

Терминология может быть запутанной. Давайте примем, что все эти названия – синонимы: Vault, Sparse Bundle Disk Image, контейнер, зашифрованный образ.

Создание нового образа (Vault) в Knox:

То же самое – в Disk Utility (File/New disk image):

Или же – в Terminal:

$ hdiutil create -size 100m -type SPARSEBUNDLE -imagekey \
  sparse-band-size=4096 -fs JHFS+X -volname Secret -layout GPTSPUD \
  ~/Documents/Secret

Смотрим настройки Vault в Knox:

Полезная функция – Compact, которая освобождает данные, которые были удалены. В Terminal это делается командой:

$ hdiutil compact ~/Documents/Secret.sparsebundle

Возможности изменения размера образа в Knox я не увидел.

В Disk Utility это можно сделать в Images/Resize:

В Terminal:

$ hdiutil resize -size 200m ~/Documents/Secret.sparsebundle

В Knox упрощена процедура создания резервных копий:

Без Knox нужно писать скрипты, или же просто сделать симлинк в Dropbox или использовать утилиту Apple MobileMe Backup.

Spotlight Control в Knox мне лично неинтересен, я и так знаю, что находится в моих Vault. Уверен, что управлять индексированием можно и из Terminal, но как это сделать, искать не буду.

Как вы видите, платить $34.95 за Knox совсем необязательно, все функции реализуемы бесплатно. Но если вы не хотите тратить время на работу с системными командами, то утилита Knox вполне хороша. По крайней мере с ней вы будете уверены, что ваши данные не попадут в чужие руки. Однако не забывайте, что если вы запомните пароль к Vault в Keychain, и оставите включённой автоматический вход без запроса пароля в систему, то даже 256-битное шифрование не поможет. Думайте – это полезно.

Вчера я упомянул, что на VPN-сервере (Mac OS X) нельзя настроить одновременно L2TP VPN Server и Back To My Mac. Подтвержу это скриншотами.

Back To My Mac выключен:

Соединение устанавливается:

Но если Back To My Mac включен:

То соединение не устанавливается:

Это единственное изменение, которое я проводил.

В документации Apple сказано:

If you wish to enable NAT port forwarding to L2TP VPN servers at private addresses on your AirPort Extreme or Time Capsule network, first ensure that MobileMe is disabled in AirPort Utility. If you configure NAT port forwarding to L2TP VPN servers at private addresses with MobileMe enabled, the setting for port forwarding to the servers will be ignored.”

Если вам нужен и Back to My Mac, и VPN-сервер, то используйте PPTP VPN. Хоть он и менее безопасный, но он работает в такой конфигурации.

Немного деталей. Вот процесс установки соединения без Back To My Mac:

45.599012 109.162.11.133 -> 192.168.98.2 ISAKMP Identity Protection (Main Mode)
45.601468 192.168.98.2 -> 109.162.11.133 ISAKMP Identity Protection (Main Mode)
46.058368 109.162.11.133 -> 192.168.98.2 ISAKMP Identity Protection (Main Mode)
46.069876 192.168.98.2 -> 109.162.11.133 ISAKMP Identity Protection (Main Mode)
46.438942 109.162.11.133 -> 192.168.98.2 ISAKMP Identity Protection (Main Mode)
46.439629 192.168.98.2 -> 109.162.11.133 ISAKMP Identity Protection (Main Mode)
47.738940 109.162.11.133 -> 192.168.98.2 ISAKMP Quick Mode
47.741256 192.168.98.2 -> 109.162.11.133 ISAKMP Quick Mode
47.938956 109.162.11.133 -> 192.168.98.2 ISAKMP Quick Mode
48.177831 109.162.11.133 -> 192.168.98.2 ESP ESP (SPI=0x0c380875)
48.200824 192.168.98.2 -> 109.162.11.133 ESP ESP (SPI=0x0d034052)
...
50.379150 192.168.98.2 -> 109.162.11.133 ESP ESP (SPI=0x0d034052)
50.417807 109.162.11.133 -> 192.168.98.2 ESP ESP (SPI=0x0c380875)
52.650222 192.168.98.2 -> 109.162.11.133 ISAKMP Informational
53.650658 192.168.98.2 -> 109.162.11.133 ISAKMP Informational

А вот – с ним:

 5.492165 109.162.11.133 -> 192.168.98.2 ISAKMP Identity Protection (Main Mode)
 8.492130 109.162.11.133 -> 192.168.98.2 ISAKMP Identity Protection (Main Mode)
11.475359 109.162.11.133 -> 192.168.98.2 ISAKMP Identity Protection (Main Mode)
14.532159 109.162.11.133 -> 192.168.98.2 ISAKMP Identity Protection (Main Mode)

При включении Back To My Mac производится маппинг портов 5353 и 4500 в запросах NAT-PMP Map UDP Request, поэтому L2TP-сервер не может обслуживать запросы, идущие на порт 4500 (IKE NAT Traversal), и в итоге соединение не устанавливается.

Напоследок приведу трейсы при включении и отключении Back To My Mac.

Включаю Back To My Mac

 28.815152 192.168.98.2 -> 109.162.11.133 UDPENCAP NAT-keepalive
 33.488924 192.168.98.2 -> 192.168.98.1 NAT-PMP External Address Request
	NAT Port Mapping Protocol, External Address Request
	    Version: 0
	    Opcode: External Address Request (0)

 33.489063 192.168.98.2 -> 192.168.98.1 SSDP M-SEARCH * HTTP/1.1
	 M-SEARCH * HTTP/1.1\r\n
	     [Expert Info (Chat/Sequence): M-SEARCH * HTTP/1.1\r\n]
	         [Message: M-SEARCH * HTTP/1.1\r\n]
	         [Severity level: Chat]
	         [Group: Sequence]
	     Request Method: M-SEARCH
	     Request URI: *
	     Request Version: HTTP/1.1
	 Host:239.255.255.250:1900\r\n
	 ST:urn:schemas-upnp-org:service:WANIPConnection:1\r\n
	 Man:"ssdp:discover"\r\n
	 MX:3\r\n
	 \r\n

 33.489094 192.168.98.2 -> 192.168.98.1 NAT-PMP Map UDP Request
	NAT Port Mapping Protocol, Map UDP Request
	    Version: 0
	    Opcode: Map UDP Request (1)
	    Reserved: 0
	    Internal Port: 5353
	    Requested External Port: 5353
	    Requested Port Mapping Lifetime: 7200

 33.489109 192.168.98.2 -> 192.168.98.1 SSDP M-SEARCH * HTTP/1.1
	 M-SEARCH * HTTP/1.1\r\n
	     [Expert Info (Chat/Sequence): M-SEARCH * HTTP/1.1\r\n]
	         [Message: M-SEARCH * HTTP/1.1\r\n]
	         [Severity level: Chat]
	         [Group: Sequence]
	     Request Method: M-SEARCH
	     Request URI: *
	     Request Version: HTTP/1.1
	 Host:239.255.255.250:1900\r\n
	 ST:urn:schemas-upnp-org:service:WANPPPConnection:1\r\n
	 Man:"ssdp:discover"\r\n
	 MX:3\r\n
	 \r\n

 33.489134 192.168.98.2 -> 192.168.98.1 NAT-PMP Map UDP Request
	NAT Port Mapping Protocol, Map UDP Request
	    Version: 0
	    Opcode: Map UDP Request (1)
	    Reserved: 0
	    Internal Port: 4500
	    Requested External Port: 4500
	    Requested Port Mapping Lifetime: 7200

 33.489148 192.168.98.2 -> 192.168.98.1 SSDP M-SEARCH * HTTP/1.1
	 M-SEARCH * HTTP/1.1\r\n
	     [Expert Info (Chat/Sequence): M-SEARCH * HTTP/1.1\r\n]
	         [Message: M-SEARCH * HTTP/1.1\r\n]
	         [Severity level: Chat]
	         [Group: Sequence]
	     Request Method: M-SEARCH
	     Request URI: *
	     Request Version: HTTP/1.1
	 Host:239.255.255.250:1900\r\n
	 ST:urn:schemas-upnp-org:service:WANIPConnection:1\r\n
	 Man:"ssdp:discover"\r\n
	 MX:3\r\n
	 \r\n

 33.493555 192.168.98.1 -> 192.168.98.2 ICMP Destination unreachable (Port unreachable)
 33.493559 192.168.98.1 -> 192.168.98.2 ICMP Destination unreachable (Port unreachable)
 33.493723 192.168.98.1 -> 192.168.98.2 ICMP Destination unreachable (Port unreachable)
 	Destination port: ssdp (1900)

 33.493962 192.168.98.1 -> 192.168.98.2 NAT-PMP External Address Response
    Version: 0
    Opcode: External Address Response (128)
    Result Code: Success (0)
    Seconds Since Start of Epoch: 13283
    External IP Address: 111.222.111.222 (111.222.111.222)

 33.502106 192.168.98.1 -> 192.168.98.2 NAT-PMP Map UDP Response
	 Version: 0
	 Opcode: Map UDP Response (129)
	 Result Code: Success (0)
	 Seconds Since Start of Epoch: 13283
	 Internal Port: 5353
	 Mapped External Port: 32773
	 Port Mapping Lifetime: 7200

 33.510384 192.168.98.1 -> 192.168.98.2 NAT-PMP Map UDP Response
	 Version: 0
	 Opcode: Map UDP Response (129)
	 Result Code: Success (0)
	 Seconds Since Start of Epoch: 13283
	 Internal Port: 4500
	 Mapped External Port: 32774
	 Port Mapping Lifetime: 7200

Отключаю Back To My Mac

  3.936568 192.168.98.2 -> 192.168.98.1 NAT-PMP Map UDP Request
	  Version: 0
	  Opcode: Map UDP Request (1)
	  Reserved: 0
	  Internal Port: 4500
	  Requested External Port: 32774
	  Requested Port Mapping Lifetime: 0

  3.936664 192.168.98.2 -> 192.168.98.1 SSDP M-SEARCH * HTTP/1.1
	  M-SEARCH * HTTP/1.1\r\n
	      [Expert Info (Chat/Sequence): M-SEARCH * HTTP/1.1\r\n]
	          [Message: M-SEARCH * HTTP/1.1\r\n]
	          [Severity level: Chat]
	          [Group: Sequence]
	      Request Method: M-SEARCH
	      Request URI: *
	      Request Version: HTTP/1.1
	  Host:239.255.255.250:1900\r\n
	  ST:urn:schemas-upnp-org:service:WANPPPConnection:1\r\n
	  Man:"ssdp:discover"\r\n
	  MX:3\r\n
	  \r\n

  3.938951 192.168.98.1 -> 192.168.98.2 ICMP Destination unreachable (Port unreachable)
	Destination port: ssdp (1900)
  3.943055 192.168.98.1 -> 192.168.98.2 NAT-PMP Map UDP Response
	  Version: 0
	  Opcode: Map UDP Response (129)
	  Result Code: Success (0)
	  Seconds Since Start of Epoch: 13310
	  Internal Port: 4500
	  Mapped External Port: 32774
	  Port Mapping Lifetime: 0

  6.038227 192.168.98.2 -> 192.168.98.1 NAT-PMP Map UDP Request
	  Version: 0
	  Opcode: Map UDP Request (1)
	  Reserved: 0
	  Internal Port: 5353
	  Requested External Port: 32773
	  Requested Port Mapping Lifetime: 0

  6.038303 192.168.98.2 -> 192.168.98.1 SSDP M-SEARCH * HTTP/1.1
	  M-SEARCH * HTTP/1.1\r\n
	      [Expert Info (Chat/Sequence): M-SEARCH * HTTP/1.1\r\n]
	          [Message: M-SEARCH * HTTP/1.1\r\n]
	          [Severity level: Chat]
	          [Group: Sequence]
	      Request Method: M-SEARCH
	      Request URI: *
	      Request Version: HTTP/1.1
	  Host:239.255.255.250:1900\r\n
	  ST:urn:schemas-upnp-org:service:WANIPConnection:1\r\n
	  Man:"ssdp:discover"\r\n
	  MX:3\r\n
	  \r\n

  6.040599 192.168.98.1 -> 192.168.98.2 ICMP Destination unreachable (Port unreachable)
  	Destination port: ssdp (1900)

  6.043605 192.168.98.1 -> 192.168.98.2 NAT-PMP Map UDP Response
	  Version: 0
	  Opcode: Map UDP Response (129)
	  Result Code: Success (0)
	  Seconds Since Start of Epoch: 13310
	  Internal Port: 5353
	  Mapped External Port: 32773
	  Port Mapping Lifetime: 0