Полностью защитить протокол общения пользователя с сервером можно только одним способом — шифрование трафика. Экзотические способы шифрования, а также создание различного вида тоннелей мы не рассматриваем. Только обычное SSL-шифрование протокола HTTP, которое поддерживает любой современный браузер — HTTPS.

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

И вот, учитывая это, возникает вопрос: если полностью защитить трафик мы не можем, то можем ли мы защитить хотябы самое важное? Например, пароль. В принципе, можем, но тоже не на 100%. Пароль можно хэшировать до передачи на сервер JavaScript-ом. Тогда перехватчик получить хэш. Он сможет по нему авторизоваться, но сам пароль не увидит. Правда, его можно подобрать брутфорсом. С шифрованием самого пароля (вместо хэширования) картина примерно та же, только реализация гораздо сложнее.

Давать возможность пользователю работать с сайтом по HTTPS можно, но заставлять нужно только тогда, когда шифрование реально необходимо: например, в интернет-банкинге. Дело в том, что у некоторых компаний могут быть закрыты исходящие соединения на 443-й порт, либо запрещен бинарный трафик.

HTTPS-трафик создает дополнительную нагрузку на сервер, прежде всего на процессор, а так же замедляет передачу информации пользователю. Этот еще два камня в его огород. Вывод: если нет острой необходимости, не нужно заставлять и, возможно, даже рекомендовать пользователю пользоваться HTTPS.

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

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

Именно так поступили в Яндексе. У них я подсмотрел способ определения доступности HTTPS. Подгружается JS с https://, который устанавливает флаг в DOM-модели страницы. Форма авторизации ведет себя по разному в зависимости от этого флага.

Хэшировать ли пароль? Это может иметь значение только в одном случае: если у пользователя один пароль на несколько сервисов. Тогда перехватчик не увидит пароля в открытом виде, чтобы использовать его на других сервисах. Но подобрать брутфорсом пароль все равно возможно. Только это уже не так тривиально, как подсмотреть в открытом виде. Так что если вы на стороне пользователя, постарайтесь пароль хэшировать до передачи.

А как делают другие?

Про Яндекс я уже рассказал. Добавлю, что пароль он передает в открытом виде и не пускает на главную страницу портала по HTTPS.

Mail.ru ведет себя как Яндекс, только их способа определения поддержки HTTPS я не нашел (хотя и не глубоко искал).

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

Facebook, как и Google, прекрассно работает по HTTPS. Авторизация по умолчанию защищенная. Пароль в открытом виде.

Вконтакте, Одноклассники, TUT.BY и Onliner.by по HTTPS не отвечают, защищенную авторизацию не предлагают, пароль идет в открытом виде.

oz.by по HTTPS предлагает принять самоподписанный сертификат, чтобы потом произвести редирект на HTTP. Пароль в открытом виде.

Вот такая статистика. Западные ресурсы и пользователи давно освоили основы безопасности в сети. Ведущие российские ресурсы защищают хотябы авторизацию пользователя. Ведущие белорусские ресурсы безопасность пользователей игнорируют полностью.

В прошлый раз я писал, что у меня ноутбук HP Compaq nx7300 с сетевой Broadcom BCM4311 802.11b/g WLAN (rev 01). Эта карточка числится в списке поддерживаемых драйвером bc43 при условии свежести ядра (2.6.24 или старше). Чтобы проверить, какая карта у вас, выполните команды:

update-pciids
lspci -nn

В выводе последней команды в конце у меня есть следующая строка:
10:00.0 Network controller [0280]: Broadcom Cor poration BCM4311 802.11b/g WLAN [14e4:4311] (rev 01)

Это и ест ь мой сетевой адаптер Broadcom BCM4311.

Поддерживаются карты:

• bcm4303 (802.11b-only chips, uses b43legacy)
• bcm4306 (Rev. 2 uses b43legacy, Rev. 3 uses b43)
• bcm4309 (only the 2.4GHz part)
• bcm4311 rev 1 / bcm4312
• bcm4311 rev 2 / bcm4312 (needs patches for 2.6.24)
• bcm4312 (only the 2.4GHz part)
• bcm4318

Для карты BCM4306 Rev 2 или для работы с лишь 802.11b режимом используется дрвйвер b43legacy. Во всех других случаях используется b43. Об установке b43 и поговорим :)

Для ядер 2.6.25 и выше надо выполнить лишь 2 следующие пачки команд, и все:

wget http://bu3sch.de/b43/fwcutter/b43-fwcutter-011.tar.bz2
tar xjf b43-fwcutter-011.tar.bz2
cd b43-fwcutter-011
make
cd ..

export FIRMWARE_INSTALL_DIR=»/lib/firmware»
wget http://mirror2.openwrt.org/sources/broadcom-wl-4.150.10.5.tar.bz2
tar xjf broadcom-wl-4.150.10.5.tar.bz2
cd broadcom-wl-4.150.10.5/driver
sudo ../../b43-fwcutter-011/b43-fwcutter -w «$FIRMWARE_INSTALL_DIR» wl_apsta_mimo.o

Тем самым мы скачали и собрали b43-fwcutter, которому затем подсунули скачанный драйвер. Он его «вставил» в систему. Все, сетевая работает.

Про настройку сетевой читайте в старом посте.

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

Для решения этой задачи можно использовать общую базу данных, которая будет располагаться на хостинге. На сервере в локальной сети поднять сайт, указать для подключения к СУБД параметры доступа к база на удаленном сервере. Таким образом, у вас будут 2 одинаковых сайта, параллельно работающих с одним источником данных.

В принципе это обычная схема для балансировки нагрузки на фронтэнд (web-сервер). Практику много фронтэндов — один бэкэнд (база) применяют довольно часто, а следующий этап разделения нагрузки (когда уже СУБД не выдерживает напора) — кластеризация серверов баз данных. Но это лирическое отступление.

Следуюет учесть три нюанса. Во-первых, так как сервера у нас теперь два, время на них может быть разное. Следовательно при записи в базу временные показатели будут для серверов расходиться и может возникнуть путаница. Чтобы этого избежать, проще всего брать время из СУБД. Делать это надо естественно 1 раз за запрос (кэшировать), а не при каждой необходимости (при условии, что запрос выполняется не более 1 секунды; если больше, значит ваша система нуждается в оптимизации). Таким образом время на всех серверах будет синхронизировано по времени на сервере с СУБД.

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

Решить эту проблему можно через подключение к СУБД по защищенному SSL-протоколу. Популярные СУБД поддерживают SSL (MySQL, PgSQL). Подключение клиента к серверу через SSL поддерживают родные C API этих СУБД, и PHP MySQL/PgSQL API тоже. Но SSL не поддерживается PDO (во всяком случае я не нашел информацию о поддержке), который в настоящее время очень популярен и который следует использовать. По этому вариант подключения к базе через SSL отпадает.

Остается другой, довольно простой для использования и сложный для настройки вариант — перегон трафика между офисом и хостингом через VPN. Сам VPN я уже описывал в своем блоге. После поднятия VPN-тоннеля необходимо прописать роут на IP вашего сервера (того сервера, где находится СУБД) через виртуальный интерфейс VPN-соединения. Таким образом весь трафик между PHP и СУБД будет ходить по безопасному зашифрованному каналу.

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

Когда все проблемы решены, все что остается делать — это следить за тем, чтобы версии скриптов на серверах в сети и на офисе были одинаковыми, чтобы не повредить базу.

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

В своем блоге я опишу результат собственных изысканий по подъему wi-fi адаптера на ноутбуке HP Compac nx 7300 для дистрибутива Debian (etch). Стоит упомянуть, что вся информация актуальна на момент ноября 2008 года, и что все описанное ниже не претендует на «руководство», это лишь описание моих действий и результатов.

UPD: Внимание! В связи с выходом Debian 5.0 Lenny сначала прочитайте эту запись!

Гуглинг на тему моего wi-fi в Debian привел к замечательному описанию-руководству по поднятию беспроводной сети. В этом мануале рассказывается про установку драйверов для беспроводных адаптеров на базе чипсетов Broadcom 43xx и 1390. Вот как раз 4311 и установлен в ноутбук HP Compac nx7300.

Драйвера от Broadcom есть и под Linux, и под Windows. Для линукса есть даже 2 разных версии:

• Linux b43 / bcm43xx driver (начиная с ядра 2.6.24 его просто переименовали),
• Linux b43_legacy driver (отделен в ядре 2.6.24 для совместимости со старыми чипсетами).

Виндовый драйвер так же может работать в линуксе через известную программу NDISWrapper. Причем, забегая вперед, скажу, что именно с ним и пришлось работать.

Сначала требуется определить, какой сетевой адаптер используется. Как это сделать, написано в отдельном руководстве. Самый простой вариант — выполнить следующие команды:

update-pciids

lspci -nn

В выводе последней команды в конце у меня есть следующая строка:

10:00.0 Network controller [0280]: Broadcom Cor poration BCM4311 802.11b/g WLAN [14e4:4311] (rev 01)

Это и ест ь мой сетевой адаптер  Broadcom  BCM4311. Теперь пробуем заставить его работать. Стоит отметить, что до установки дров сетевой интерфейс wlan0 просто не существует, а диод на ноуте не горит и не включается кнопкой.

Установкой я занимался по порядку, описанному в статье. Принцип там такой: попробуйте сделать это, если не поможет, попробуйте это, если не поможет, попробуйте это и т.д.

Сразу отмечу, что ядро у меня 2.6.18 (т.е. меньше) 2.6.24, а значит b43_legacy и Native b43 driver рассматривать смысла нет вообще. Cтавим Native bcm43xx driver.

Руководство по установке этого драйвера начинается с этого места. Подзаголовки (option 1, 2, 3, 4, 5) — это этапные варианты установки драйвера. Последним пунктом идет установка Ndiswrapper’а. Я прошел все эти 6 уровней, адаптер заработал у меня только после установки  Ndiswrapper’а. Если у вас не адаптер BCM4311 в связке с linux kernel 2.6 .18, рекомендую попробовать все варианты по порядку (пройти этот увлекательный к вест :), иначе можете сразу приступать к установке  Ndiswrapper’а.

Если в конце концов у вас таки появилось устройство wlan0, поздравляю, драйвер установлен!

Но установить драйвер естественно мало. Надо еще настроить интерфейс. Так как я бродил несколькими обходными путями и произвел достаточно много действий при изучении этого вопроса, точно сейчас сказать сложно, какие из действий являются минимально-необходимыми. Но факт в том, что в файле /etc/networks/interfaces у меня сейчас следующие строки:

allow-hotplug wlan0

iface wlan0 inet static

wireless-essid ZyXEL

address 192.168.0.30

netmask 255.255.255.0

gateway 192.168.0.1

ZyXEL — точка доступа, IP понятны, вторая строка обозначает, что IP пр описаны статически, а не по DHCP. Так же есть файл /home/feedbee/wlan следующего содержания:

echo "Loading ndiswrapper..."

modprobe ndiswrapper

echo "Setting mode Managed..."

iwconfig wlan0 mode Managed

echo " -- Setting ESSID"

iwconfig wlan0 essid ZyXEL

echo " --Setting to channel 6..."

iwconfig wlan0 channel 6

echo " --Turning on managed mode..."

iwconfig wlan0 mode Managed

echo " --Setting encryption key"

iwconfig wlan0 key restricted E3374866EE

echo "Bringing up interface wlan0..."

ifconfig wlan0 up

echo "Disable interface eth0 to kill its routes. .."

ifconfig eth0 down

echo "--Setting routing..."

route add default wlan0

route add -net 81.25.32.0 netmask 255.255.255.0 gw 192.168.0.1 wlan0

Этот файл включает сетевой адаптер. Но до запуска файла адаптер дол жен быть включен физически, т.е. должен гореть синий диод на ноутбуке.

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

Строка iwconfig wlan0 key restricted E3 374866EE в файле обозначает, что используется WEP-шифрование.  E3374866EE — это ключ, который введен на точке (в HEX-формате). Для WEP-64 это 10 шестнадцатеричных цифр, для WEP-128 — 26. Если шифрование не используется, эту строчку можно просто убрать.

Если интерфейс wlan0 и соединение с точкой доступа поднялись, но пакеты на сеть не ходят (хосты не пингуются), разбирайтесь с роутами.

На самом деле — не совсем так. Да, зашифрованный трафик теоретически невозможно расшифровать, хотя опять таки теоретически при очень большой необходимости и желании, и такой трафик можно расшифровать, подобрав ключ. Однако для этого нужны такие затраты ресурсов, что актуальность взлома сохраняется только, наверное, на правительственном или военном уровне :)

При работе по защищенному соединению (самый просто пример — HTTPS) весь трафик между взаимодействующими точками в сети шифруется на стороне отправителя и дешифруется на стороне получателя. Шифруется трафик, идущий в обоих направлениях. Для того, чтобы его зашифровать и расшифровать нужна пара ключей (ассиметричное шифрование). Публичный ключ служит для зашифрования и передается получателю данных, а приватный — для дешифрования, он остается у отправителя. Таким образом, узлы, между которыми устанавливается SSL-соединение, обмениваются публичными ключами. Далее, для повышения производительности формируется единый ключ, который пересылается уже в зашифрованном виде и используется как для шифрации, так и для дешифрации на обеих сторонах (симметричное шифрование).

А как они это делают? Обычно — по тому же каналу, по которому далее будет идти защищенный трафик. Причем обмен ключами происходит в открытом режиме. В случае HTTPS ключ сервера связан с сертификатом, который пользователю предлагается просмотреть и принять. И вот этот сертификат как раз и может перехватить любой промежуточный сервер, на пути которого идет сертификат в открытом виде (прокси, роутер).

Чтобы далее «читать» весь трафик пользователя, промежуточный сервер подменяет сертификат на свой. Т.е. он просто сам подключается к клиенту со своим сертификатом, и в то же время подключается к удаленному серверу. Клиенту приходит «левый» сертификат от сервера-злоумышленника, а браузер сообщает пользователю об опасности (такие сертификаты всегда не подписаны). У пользователя остается выбор: принять сертификат и работать с сайтом, либо отказаться его принимать, но и работать с сайтом тогда уже не получится. Иногда пользователи вообще игнорируют содержимое сертификатов и машинально принимают любые переданные им.

Если пользователь принимает сертификат-подделку, то трафик будет идти по следующей схеме:

клиент <= SSL-соединение => сервер-прослушка <= SSL-соединение => сервер назначения

Т.е. промежуточный сервер будет получать весь ваш «защищенный» трафик в открытом виде. Стоит также заметить, что передача сертификата происходит в начале каждой сессии HTTPS.

В случае защищенного SSH при первом соединении с сервером на клиенте сохраняется ключ сервера, а на сервере — ключ клиента. Эти ключи передаются между данными клиентом-сервером только один раз, при первом подключении. Если в этом случае SSH-трафик попытаются перехватить, то и клиент, и сервер откажут в соединении из-за несоответствия ключей. Так как ключи можно перенести между клиентом и сервером обходным путем (по защищенному каналу или на внешнем носителе), этот способ соединения является относительно безопасным. Его могут лишь заблокировать, заставив пользователя работать в открытую.

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

Но пути спасения от тотальной слежки есть. Через установленное SSH-соединение можно направлять любой нужный трафик, который с SSH-сервера будет уже в открытом виде идти на конечную точку. Этот способ называется SSH-туннелинг (tunneling). Так можно обезопасить прохождение трафика по незащищенному каналу, но имеет смысл такой подход только при наличии доверенного сервера с поднятым и настроенным на туннелинг SSH-демоном. Причем организовать это достаточно просто. SSH-клиент подключается к серверу, настраивается на прослушку любого данного порта на локальной машине. Этот клиент будет предоставлять услугу SOCKS5-прокси, т.е. его использование можно настроить в любом браузере, почтовых программах, IM-ах и т.д. Через SSH-туннель пакеты попадают на сервер, а с него уходят на целевой сервер. Схема получается следующая:

[localhost: клиент <=> proxy] <== SSH-соединение ==> сервер <=> целевой сервер

Другой способ защиты трафика — VPN-канал. В использовании он проще и удобнее SSH-туннелинга, но в первичной установке и настройке сложнее. Основное удобство этого способа в том, что в программах не нужно прописывать прокси. А некоторый софт и вовсе прокси не поддерживает, следовательно только VPN и подойдет.

На практике есть два варианта работы. Первый — покупка VPN-акканута, который продается специально для этих целей (шифрование трафика по небезопасному каналу). В этом случае продаются обычно аккаунты, соединяться с которыми надо по протоколам PPTP (обычный VPN, который реализован, например, в Windows) или L2TP. Купить такой аккаунт можно, например, на russianproxy.ru.

Второй вариант — покупка VDS-сервера (виртуальный выделенный сервер) с любым дистрибутивом линукса на борту и поднятие на нем VPN-сервера. Один из самых популярных российских провайдеров — firstvds.ru. Его главное преимущество — низкие цены (акцентирую внимание на то, что серверы в России; если подойдет американский сервер, есть, например, vpsland.com, только не забывайте про заокеанские пинги). На VDS ставят OpenVPN-сервер, а на компьютере поднимается OpenVPN-клиент. Для Windows есть даже гуишная версия клиента.

Если вы решите использовать вариант с OpenVPN, то есть простая пошаговая инструкция по поднятию сервера, как раз для firstVDS с Debian на борту. Установить клиента еще проще, особенно под Windows. Отметить стоит только один нюанс. Если весь трафик требуется пустить по созданному VPN-соединению, то требуется прописать default gateway на шлюз VPN (параметр redirect-gateway в конфиге клиента), а если только часть трафика (на определенные хосты), то можно прописать обычные статические маршруты на данные хосты (по IP; например, route add -p 81.25.32.25 10.7.0.1).

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

Таким образом, SSH- и VPN-соединения могут практически полностью гарантировать безопасность вашего трафика при перемещении по незащищенному каналу. Единственная проблема, которая может возникнуть в этом случае, — это запрет на SSL-трафик на корпоративном файрволе. Если SSL-трафик разрешен хотябы на один любой порт (обычно дефолтный 443), то вы уже потенциально можете поднять и SSH-тонель, и VPN-соединение, настроив соответствующего демона на вашем VDS на этот порт.