VPN для обычных пользователей. Реальная необходимость или бесполезная опция?
В сети много статей про виртуальные частные сети (VPN): руководства по самостоятельной настройке, обзор технологии, примеры использования. Все они в той или иной степени рассчитаны на продвинутых пользователей, которые прекрасно осознают угрозы в современном информационном пространстве и целенаправленно выбирают тот или иной способ защиты.
Как же быть обычным пользователям? Что им угрожает? Нужен ли им вообще VPN?
Для ответа на эти вопросы достаточно собрать простейший тестовый стенд с точкой доступа Wi-Fi и анализатором трафика. Результат окажется очень занимательным.
Статья техническая, так что многим детали могут быть непонятны. Но выводы в конце статьи должны быть понятны всем :-)
В качестве хакерского оружия берем обычный компьютер со встроенным Wi-Fi адаптером. Включаем точку доступа, я использовал hostapd и dhcp3. Описаний по установке и настройке очень много (раз, два, три). Настраиваем шлюз в интернет. После этого устанавливаем Wireshark, запускаем захват трафика на беспроводном интерфейсе. К точке доступа подключаем мобильное устройство, в моем случае iPad. Эмулируем бесплатную точку доступа в кафе и расслабленного посетителя с мобильным устройством.
В данной статье мы не будем использовать подмену сертификатов и проксирование HTTPS трафика, а рассмотрим простейшие случаи прослушки HTTP. Все персональные данные в нижеприведенных дампах изменены.
Начнем со всеми «любимого» ВКонтактика (vk.com). Смотрим трафик пользователя при подключении:
[Содержимое запроса]
GET /login?role=fast&to=&s=1&__q_hash=bd8b2282f344a97ebe12b0c485952a6f HTTP/1.1
Host: m.vk.com
Connection: keep-alive
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Referer: http://m.vk.com/login?role=fast&to=&s=1&m=1&email=mail%40yandex.ru
User-Agent: Mozilla/5.0 (iPad; CPU OS 6_1_3 like Mac OS X) AppleWebKit/536.26 (KHTML, like Gecko) CriOS/26.0.1410.53 Mobile/10B329 Safari/8536.25
Accept-Encoding: gzip,deflate,sdch
Accept-Language: ru-RU,ru;q=0.8,en-US;q=0.6,en;q=0.4
Accept-Charset: windows-1251,utf-8;q=0.7,*;q=0.3
Cookie: remixlang=0; remixmdevice=768/1024/2/!!!!!!; remixstid=267699470; remixmid=; remixsid=; remixsid6=; remixgid=; remixemail=; remixpass=; remixapi_sid=; remixpermit=; remixsslsid=
JavaScript на клиенте вычисляет хэш от имени и пароля и шлет его в GET запросе. После этого сервер отвечает перенаправлением и устанавливает cookie:
[Содержимое запроса]
HTTP/1.1 302 Found
Server: nginx/1.2.4
Date: Mon, 03 Jun 2013 16:56:02 GMT
Content-Type: text/html; charset=windows-1251
Content-Length: 20
Connection: keep-alive
X-Powered-By: PHP/3.332
Pragma: no-cache
Cache-control: no-store
P3P: CP="IDC DSP COR ADM DEVi TAIi PSA PSD IVAi IVDi CONi HIS OUR IND CNT"
Set-Cookie: remixsid=c04f7b2295b3b54405205a4306d6511c6cd9857f33249c004121c; expires=Wed, 11-Jun-2014 05:01:34 GMT; path=/; domain=.vk.com
Set-Cookie: remixtemp_sid=; expires=Sun, 25-May-2014 15:48:33 GMT; path=/; domain=.vk.com
Location: /
Content-Encoding: gzip
Затем клиент переходит по указанной в редиректе ссылке с передачей установленных cookies
[Содержимое запроса]
GET / HTTP/1.1
Host: m.vk.com
Connection: keep-alive
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Referer: http://m.vk.com/login?role=fast&to=&s=1&m=1&email=mail%40yandex.ru
User-Agent: Mozilla/5.0 (iPad; CPU OS 6_1_3 like Mac OS X) AppleWebKit/536.26 (KHTML, like Gecko) CriOS/26.0.1410.53 Mobile/10B329 Safari/8536.25
Accept-Encoding: gzip,deflate,sdch
Accept-Language: ru-RU,ru;q=0.8,en-US;q=0.6,en;q=0.4
Accept-Charset: windows-1251,utf-8;q=0.7,*;q=0.3
Cookie: remixlang=0; remixmdevice=768/1024/2/!!!!!!; remixstid=267699470; remixmid=; remixsid6=; remixgid=; remixemail=; remixpass=; remixapi_sid=; remixpermit=; remixsslsid=; remixsid=c04f7b5995b3b54405205a4306d6511c6cd9558f33249c004121c; remixtemp_sid=
Этого достаточно, чтобы зайти «хакеру» под логином этого пользователя. Берем любой плагин для установки cookie (я использовал Cookies Manager+ для FF), прописываем remixlang, remixstid, remixsid из последнего дампа для сайта vk.com, переходим по ссылке https://vk.com/login?role=fast&to=&s=1&__q_hash=bd8b2282f344a97ebe12b0c485952a6f и все - вы в ленте пользователя.
Может быть приложение «ВКонтакте» для iPhone/iPad использует защищенное соединение? Нет, это не так. Анализатор трафика показывает HTTP POST запросы к API:
[Содержимое запроса]
POST /method/execute HTTP/1.1
Host: api.vk.com
Accept-Encoding: gzip
Content-Type: application/x-www-form-urlencoded; charset=utf-8
Content-Length: 266
Connection: keep-alive
Cookie: remixdt=-10800; remixrt=1; remixlang=3
User-Agent: 2.3.11 rv:10037 (iPad; iPhone OS 6.1.3; nb_NO)
code=var%20messages%20%3D%20API.messages.get%28%7Bfilters%3A1%7D%29%3B%20return%20%7Bunread%3Amessages%5B0%5D%7D%3B&api_id=2753915&access_token=ac43d874bd29351e2e2b20b0c671029edc84a48a715f97721111568443b5ba42f00a349b95f692e5727ec&sig=cb7ac6c6346bd26b762929efe0f711d1
Параметр access_token - это то, что можно использовать для авторизации под чужим именем.
Получается, что поклонникам «ВКонтакте» разумно подключаться только по HTTPS, но принудительное перенаправление с HTTP на HTTPS на серверах «ВКонтакте» не активировано. Так же приложение для Apple iOS использует HTTP, тут угроза постоянна. Без VPN подключаться к неизвестным сетям очень рискованно.
Смотрим дальше. «Живой Журнал» очень популярен среди творческой интеллигенции, дизайнеров и оппозиционеров. Для некоторых ведение блога в ЖЖ является основным средством заработка. Заходим на сайт ЖЖ с мобильного устройства под своим аккаунтом, смотрим трафик на нашем «хакерском» шлюзе.
[Содержимое запроса]
GET / HTTP/1.1
Host: www.livejournal.com
Connection: keep-alive
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
User-Agent: Mozilla/5.0 (iPad; CPU OS 6_1_3 like Mac OS X) AppleWebKit/536.26 (KHTML, like Gecko) CriOS/26.0.1410.53 Mobile/10B329 Safari/8536.25
Accept-Encoding: gzip,deflate,sdch
Accept-Language: ru-RU,ru;q=0.8,en-US;q=0.6,en;q=0.4
Accept-Charset: windows-1251,utf-8;q=0.7,*;q=0.3
Cookie: ljuniq=EQwqgJzEJVk0mqr%3A1370276381%3Apgstats0; ljmastersession=v2:u12213803:s119:a68UFciy4PP:g398155211a6adc80bc47746a28dbcb9146b6a257//1; ljloggedin=v2:u12213003:s119:t1370286730:gb4fd54e13950d47f0940aa78f3de73582ebd4c64; BMLschemepref=horizon; langpref=ru/1370272950; ljsession=v1:u12213803:s119:t1370275200:gf1c7f737342bcb5759c70a257cbf97acc9512731//1; PRUM_EPISODES=s=1370747384764&r=http%3A//www.livejournal.com/; __utma=48425145.515596637.1370276682.1370276682.1370281850.2; __utmb=48425145.1.10.1370281850; __utmc=48425145; __utmz=48425145.1370276682.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none)
Вот и все, все данные для несанкционированного подключения у нас есть. Достаточно прописать в браузере cookies для ljuniq, ljmastersession, ljloggedin и ljsession. После этого смело заходим на http://livejournal.com и пишем пост от имени жертвы.
И так практически для всех сервисов, использующих HTTP во время процесса авторизации пользователя.
Facebook, Twitter, Github, LinkedIn - молодцы, на их ресурсах авторизация только через HTTPS. То же самое касается почтовых систем Gmail и Yandex. Серьезные компании начинают всерьез задумываться о безопасности данных своих пользователей.
Хотя с Яндексом есть проблема. Заходим на http://partner.yandex.ru с мобильного устройства. Смотрим трафик на шлюзе. В процессе логина происходит переход на https://passport.yandex.ru, авторизация идет через HTTPS, устанавливаются cookie, но потом происходит перенаправление на http://partner.yandex.ru/registered с уже установленными cookie.
[Содержимое запроса]
GET /registered HTTP/1.1
Host: partner.yandex.ru
Connection: keep-alive
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
User-Agent: Mozilla/5.0 (iPad; CPU OS 6_1_3 like Mac OS X) AppleWebKit/536.26 (KHTML, like Gecko) CriOS/26.0.1410.53 Mobile/10B329 Safari/8536.25
Accept-Encoding: gzip,deflate,sdch
Accept-Language: ru-RU,ru;q=0.8,en-US;q=0.6,en;q=0.4
Accept-Charset: windows-1251,utf-8;q=0.7,*;q=0.3
Cookie: yandexuid=9257588111370282489; _ym_visorc=b; ys=udn.bXRzLZ1heA%3D%3D; yp=1685643738.udn.bXRzLW1heA%3D%3D; yandex_login=mail; my=YzYBSQA=; L=X3MKVQFiRwt/Ql9afF5hfnZBbwBCeHkXUypkHiQcHkwyOwFcRjh9JnMzKT0GXD0NSDVcdEMCUUB4XyEDqhpbNQ==.1620283888.9752.254668.6b58de4c285c135c1273a411170dba5c; Session_id=2:1685643738.-875.0.1121887.8:1370283888922:1422936785:15.0.1.1.0.73736.1393.a9075755a24d0d44ef3f216256625665
Ну и далее все печально, прописываем yandexuid, ys, yp,yandex_login, my, L, Session_id, заходим на http://partner.yandex.ru/registered и видим консоль администратора партнерской программы. Все остальные сервисы Яндекса тоже доступны, включая почту.
Для таких случаев оптимальным вариантом является использование VPN на мобильных устройствах. Крайне желательно выбирать решения с автоматическим подключением к VPN при любом исходящем трафике. Для iOS устройств такая технология называется VPN-on-Demand, для Android устройств - Always-on VPN.
[Для «хакера» весь VPN трафик выглядит очень скучно и однообразно, примерно вот так:]
No. Time Source Destination Protocol Info
95 7.372487 10.0.1.200 109.233.59.108 ESP ESP (SPI=0xc6ed086f)
Frame 95 (126 bytes on wire, 126 bytes captured)
Ethernet II, Src: 7c:fa:df:cb:d3:89 (7c:fa:df:cb:d3:89), Dst: HonHaiPr_23:f0:9a (0c:60:76:23:f0:9a)
Internet Protocol, Src: 10.0.1.200 (10.0.1.200), Dst: 109.233.59.108 (109.233.59.108)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
0000 00.. = Differentiated Services Codepoint: Default (0x00)
.... ..0. = ECN-Capable Transport (ECT): 0
.... ...0 = ECN-CE: 0
Total Length: 112
Identification: 0x38cd (14541)
Flags: 0x00
Fragment offset: 0
Time to live: 64
Protocol: UDP (0x11)
Header checksum: 0x8c93 [correct]
[Good: True]
[Bad : False]
Source: 10.0.1.200 (10.0.1.200)
Destination: 109.233.59.108 (109.233.59.108)
User Datagram Protocol, Src Port: ipsec-nat-t (4500), Dst Port: ipsec-nat-t (4500)
Source port: ipsec-nat-t (4500)
Destination port: ipsec-nat-t (4500)
Length: 92
Checksum: 0x0000 (none)
Good Checksum: False
Bad Checksum: False
UDP Encapsulation of IPsec Packets
Encapsulating Security Payload
ESP SPI: 0xc6ed086f
ESP Sequence: 54
Дополнительным преимуществом VPN является сокрытие адресов, которые посещал пользователь. Для прослушивающей стороны любая информация, даже просто история посещений, может быть полезна для дальнейшей атаки на пользователя. Если соединение идет через VPN, то подобная информация недоступна.
Администраторам серверов желательно все формы авторизации размещать на HTTPS страницах. Дополнительно рекомендуется добавлять заголовок Strict-Transport-Security с длительным сроком действия в ответы сервера. Это позволит избежать ситуации, описанной выше для partner.yandex.ru.
Получается, что самым обычным пользователям совершенно необходимы решения на базе VPN.
С моей точки зрения, наиболее удобно и оправдано использование решений на базе OpenVPN или IPSec. OpenVPN работает практически на всех платформах, но требует установки стороннего приложения на мобильное устройство. Поддержка IPSec встроена в базовую функциональность наиболее популярных мобильных платформ. В Apple iOS есть поддержка конфигурационных профилей, настройка VPN сводится к установке профиля на устройство. Об этом я писал в статье на Хабре.
Мой проект ruVPN.net был специально создан для защиты от описанных выше угроз. С июня началась коммерческая эксплуатация инфраструктуры VPN для Apple iOS устройств (iPhone, iPad) с поддержкой автоматического подключения (VPN-on-Demand). Подключайтесь, приглашайте друзей. Не пренебрегайте безопасностью ваших данных!
Как же быть обычным пользователям? Что им угрожает? Нужен ли им вообще VPN?
Для ответа на эти вопросы достаточно собрать простейший тестовый стенд с точкой доступа Wi-Fi и анализатором трафика. Результат окажется очень занимательным.
Статья техническая, так что многим детали могут быть непонятны. Но выводы в конце статьи должны быть понятны всем :-)
В качестве хакерского оружия берем обычный компьютер со встроенным Wi-Fi адаптером. Включаем точку доступа, я использовал hostapd и dhcp3. Описаний по установке и настройке очень много (раз, два, три). Настраиваем шлюз в интернет. После этого устанавливаем Wireshark, запускаем захват трафика на беспроводном интерфейсе. К точке доступа подключаем мобильное устройство, в моем случае iPad. Эмулируем бесплатную точку доступа в кафе и расслабленного посетителя с мобильным устройством.
В данной статье мы не будем использовать подмену сертификатов и проксирование HTTPS трафика, а рассмотрим простейшие случаи прослушки HTTP. Все персональные данные в нижеприведенных дампах изменены.
Начнем со всеми «любимого» ВКонтактика (vk.com). Смотрим трафик пользователя при подключении:
[Содержимое запроса]
GET /login?role=fast&to=&s=1&__q_hash=bd8b2282f344a97ebe12b0c485952a6f HTTP/1.1
Host: m.vk.com
Connection: keep-alive
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Referer: http://m.vk.com/login?role=fast&to=&s=1&m=1&email=mail%40yandex.ru
User-Agent: Mozilla/5.0 (iPad; CPU OS 6_1_3 like Mac OS X) AppleWebKit/536.26 (KHTML, like Gecko) CriOS/26.0.1410.53 Mobile/10B329 Safari/8536.25
Accept-Encoding: gzip,deflate,sdch
Accept-Language: ru-RU,ru;q=0.8,en-US;q=0.6,en;q=0.4
Accept-Charset: windows-1251,utf-8;q=0.7,*;q=0.3
Cookie: remixlang=0; remixmdevice=768/1024/2/!!!!!!; remixstid=267699470; remixmid=; remixsid=; remixsid6=; remixgid=; remixemail=; remixpass=; remixapi_sid=; remixpermit=; remixsslsid=
JavaScript на клиенте вычисляет хэш от имени и пароля и шлет его в GET запросе. После этого сервер отвечает перенаправлением и устанавливает cookie:
[Содержимое запроса]
HTTP/1.1 302 Found
Server: nginx/1.2.4
Date: Mon, 03 Jun 2013 16:56:02 GMT
Content-Type: text/html; charset=windows-1251
Content-Length: 20
Connection: keep-alive
X-Powered-By: PHP/3.332
Pragma: no-cache
Cache-control: no-store
P3P: CP="IDC DSP COR ADM DEVi TAIi PSA PSD IVAi IVDi CONi HIS OUR IND CNT"
Set-Cookie: remixsid=c04f7b2295b3b54405205a4306d6511c6cd9857f33249c004121c; expires=Wed, 11-Jun-2014 05:01:34 GMT; path=/; domain=.vk.com
Set-Cookie: remixtemp_sid=; expires=Sun, 25-May-2014 15:48:33 GMT; path=/; domain=.vk.com
Location: /
Content-Encoding: gzip
Затем клиент переходит по указанной в редиректе ссылке с передачей установленных cookies
[Содержимое запроса]
GET / HTTP/1.1
Host: m.vk.com
Connection: keep-alive
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Referer: http://m.vk.com/login?role=fast&to=&s=1&m=1&email=mail%40yandex.ru
User-Agent: Mozilla/5.0 (iPad; CPU OS 6_1_3 like Mac OS X) AppleWebKit/536.26 (KHTML, like Gecko) CriOS/26.0.1410.53 Mobile/10B329 Safari/8536.25
Accept-Encoding: gzip,deflate,sdch
Accept-Language: ru-RU,ru;q=0.8,en-US;q=0.6,en;q=0.4
Accept-Charset: windows-1251,utf-8;q=0.7,*;q=0.3
Cookie: remixlang=0; remixmdevice=768/1024/2/!!!!!!; remixstid=267699470; remixmid=; remixsid6=; remixgid=; remixemail=; remixpass=; remixapi_sid=; remixpermit=; remixsslsid=; remixsid=c04f7b5995b3b54405205a4306d6511c6cd9558f33249c004121c; remixtemp_sid=
Этого достаточно, чтобы зайти «хакеру» под логином этого пользователя. Берем любой плагин для установки cookie (я использовал Cookies Manager+ для FF), прописываем remixlang, remixstid, remixsid из последнего дампа для сайта vk.com, переходим по ссылке https://vk.com/login?role=fast&to=&s=1&__q_hash=bd8b2282f344a97ebe12b0c485952a6f и все - вы в ленте пользователя.
Может быть приложение «ВКонтакте» для iPhone/iPad использует защищенное соединение? Нет, это не так. Анализатор трафика показывает HTTP POST запросы к API:
[Содержимое запроса]
POST /method/execute HTTP/1.1
Host: api.vk.com
Accept-Encoding: gzip
Content-Type: application/x-www-form-urlencoded; charset=utf-8
Content-Length: 266
Connection: keep-alive
Cookie: remixdt=-10800; remixrt=1; remixlang=3
User-Agent: 2.3.11 rv:10037 (iPad; iPhone OS 6.1.3; nb_NO)
code=var%20messages%20%3D%20API.messages.get%28%7Bfilters%3A1%7D%29%3B%20return%20%7Bunread%3Amessages%5B0%5D%7D%3B&api_id=2753915&access_token=ac43d874bd29351e2e2b20b0c671029edc84a48a715f97721111568443b5ba42f00a349b95f692e5727ec&sig=cb7ac6c6346bd26b762929efe0f711d1
Параметр access_token - это то, что можно использовать для авторизации под чужим именем.
Получается, что поклонникам «ВКонтакте» разумно подключаться только по HTTPS, но принудительное перенаправление с HTTP на HTTPS на серверах «ВКонтакте» не активировано. Так же приложение для Apple iOS использует HTTP, тут угроза постоянна. Без VPN подключаться к неизвестным сетям очень рискованно.
Смотрим дальше. «Живой Журнал» очень популярен среди творческой интеллигенции, дизайнеров и оппозиционеров. Для некоторых ведение блога в ЖЖ является основным средством заработка. Заходим на сайт ЖЖ с мобильного устройства под своим аккаунтом, смотрим трафик на нашем «хакерском» шлюзе.
[Содержимое запроса]
GET / HTTP/1.1
Host: www.livejournal.com
Connection: keep-alive
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
User-Agent: Mozilla/5.0 (iPad; CPU OS 6_1_3 like Mac OS X) AppleWebKit/536.26 (KHTML, like Gecko) CriOS/26.0.1410.53 Mobile/10B329 Safari/8536.25
Accept-Encoding: gzip,deflate,sdch
Accept-Language: ru-RU,ru;q=0.8,en-US;q=0.6,en;q=0.4
Accept-Charset: windows-1251,utf-8;q=0.7,*;q=0.3
Cookie: ljuniq=EQwqgJzEJVk0mqr%3A1370276381%3Apgstats0; ljmastersession=v2:u12213803:s119:a68UFciy4PP:g398155211a6adc80bc47746a28dbcb9146b6a257//1; ljloggedin=v2:u12213003:s119:t1370286730:gb4fd54e13950d47f0940aa78f3de73582ebd4c64; BMLschemepref=horizon; langpref=ru/1370272950; ljsession=v1:u12213803:s119:t1370275200:gf1c7f737342bcb5759c70a257cbf97acc9512731//1; PRUM_EPISODES=s=1370747384764&r=http%3A//www.livejournal.com/; __utma=48425145.515596637.1370276682.1370276682.1370281850.2; __utmb=48425145.1.10.1370281850; __utmc=48425145; __utmz=48425145.1370276682.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none)
Вот и все, все данные для несанкционированного подключения у нас есть. Достаточно прописать в браузере cookies для ljuniq, ljmastersession, ljloggedin и ljsession. После этого смело заходим на http://livejournal.com и пишем пост от имени жертвы.
И так практически для всех сервисов, использующих HTTP во время процесса авторизации пользователя.
Facebook, Twitter, Github, LinkedIn - молодцы, на их ресурсах авторизация только через HTTPS. То же самое касается почтовых систем Gmail и Yandex. Серьезные компании начинают всерьез задумываться о безопасности данных своих пользователей.
Хотя с Яндексом есть проблема. Заходим на http://partner.yandex.ru с мобильного устройства. Смотрим трафик на шлюзе. В процессе логина происходит переход на https://passport.yandex.ru, авторизация идет через HTTPS, устанавливаются cookie, но потом происходит перенаправление на http://partner.yandex.ru/registered с уже установленными cookie.
[Содержимое запроса]
GET /registered HTTP/1.1
Host: partner.yandex.ru
Connection: keep-alive
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
User-Agent: Mozilla/5.0 (iPad; CPU OS 6_1_3 like Mac OS X) AppleWebKit/536.26 (KHTML, like Gecko) CriOS/26.0.1410.53 Mobile/10B329 Safari/8536.25
Accept-Encoding: gzip,deflate,sdch
Accept-Language: ru-RU,ru;q=0.8,en-US;q=0.6,en;q=0.4
Accept-Charset: windows-1251,utf-8;q=0.7,*;q=0.3
Cookie: yandexuid=9257588111370282489; _ym_visorc=b; ys=udn.bXRzLZ1heA%3D%3D; yp=1685643738.udn.bXRzLW1heA%3D%3D; yandex_login=mail; my=YzYBSQA=; L=X3MKVQFiRwt/Ql9afF5hfnZBbwBCeHkXUypkHiQcHkwyOwFcRjh9JnMzKT0GXD0NSDVcdEMCUUB4XyEDqhpbNQ==.1620283888.9752.254668.6b58de4c285c135c1273a411170dba5c; Session_id=2:1685643738.-875.0.1121887.8:1370283888922:1422936785:15.0.1.1.0.73736.1393.a9075755a24d0d44ef3f216256625665
Ну и далее все печально, прописываем yandexuid, ys, yp,yandex_login, my, L, Session_id, заходим на http://partner.yandex.ru/registered и видим консоль администратора партнерской программы. Все остальные сервисы Яндекса тоже доступны, включая почту.
Для таких случаев оптимальным вариантом является использование VPN на мобильных устройствах. Крайне желательно выбирать решения с автоматическим подключением к VPN при любом исходящем трафике. Для iOS устройств такая технология называется VPN-on-Demand, для Android устройств - Always-on VPN.
[Для «хакера» весь VPN трафик выглядит очень скучно и однообразно, примерно вот так:]
No. Time Source Destination Protocol Info
95 7.372487 10.0.1.200 109.233.59.108 ESP ESP (SPI=0xc6ed086f)
Frame 95 (126 bytes on wire, 126 bytes captured)
Ethernet II, Src: 7c:fa:df:cb:d3:89 (7c:fa:df:cb:d3:89), Dst: HonHaiPr_23:f0:9a (0c:60:76:23:f0:9a)
Internet Protocol, Src: 10.0.1.200 (10.0.1.200), Dst: 109.233.59.108 (109.233.59.108)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
0000 00.. = Differentiated Services Codepoint: Default (0x00)
.... ..0. = ECN-Capable Transport (ECT): 0
.... ...0 = ECN-CE: 0
Total Length: 112
Identification: 0x38cd (14541)
Flags: 0x00
Fragment offset: 0
Time to live: 64
Protocol: UDP (0x11)
Header checksum: 0x8c93 [correct]
[Good: True]
[Bad : False]
Source: 10.0.1.200 (10.0.1.200)
Destination: 109.233.59.108 (109.233.59.108)
User Datagram Protocol, Src Port: ipsec-nat-t (4500), Dst Port: ipsec-nat-t (4500)
Source port: ipsec-nat-t (4500)
Destination port: ipsec-nat-t (4500)
Length: 92
Checksum: 0x0000 (none)
Good Checksum: False
Bad Checksum: False
UDP Encapsulation of IPsec Packets
Encapsulating Security Payload
ESP SPI: 0xc6ed086f
ESP Sequence: 54
Дополнительным преимуществом VPN является сокрытие адресов, которые посещал пользователь. Для прослушивающей стороны любая информация, даже просто история посещений, может быть полезна для дальнейшей атаки на пользователя. Если соединение идет через VPN, то подобная информация недоступна.
Администраторам серверов желательно все формы авторизации размещать на HTTPS страницах. Дополнительно рекомендуется добавлять заголовок Strict-Transport-Security с длительным сроком действия в ответы сервера. Это позволит избежать ситуации, описанной выше для partner.yandex.ru.
Получается, что самым обычным пользователям совершенно необходимы решения на базе VPN.
С моей точки зрения, наиболее удобно и оправдано использование решений на базе OpenVPN или IPSec. OpenVPN работает практически на всех платформах, но требует установки стороннего приложения на мобильное устройство. Поддержка IPSec встроена в базовую функциональность наиболее популярных мобильных платформ. В Apple iOS есть поддержка конфигурационных профилей, настройка VPN сводится к установке профиля на устройство. Об этом я писал в статье на Хабре.
Мой проект ruVPN.net был специально создан для защиты от описанных выше угроз. С июня началась коммерческая эксплуатация инфраструктуры VPN для Apple iOS устройств (iPhone, iPad) с поддержкой автоматического подключения (VPN-on-Demand). Подключайтесь, приглашайте друзей. Не пренебрегайте безопасностью ваших данных!