Безопасность и анонимность в сети - часть 6
t.me/nightbiznesХеш-функции
Чтобы обменяться ключами согласования с Бобом защищенным образом, нам нужно аутентифицировать Боба. Если бы между нами, посередине, сидел бы кто-либо другой, то он мог бы отправить нам открытый ключ, выдавая себя за Боба, или он мог бы имитировать открытый ключ Боба в тот момент, когда мы запрашиваем его у Боба, или когда мы пытаемся скачать его с сайта.
Так что вы не можете просто взять открытый ключ и считать, что это настоящий ключ. Сначала нам нужно аутентифицировать, что это настоящий ключ, и это приводит нас к другим криптографическим технологиям, речь идет о хеш-функциях и цифровых подписях, которые помогают обеспечивать аутентификацию или легитимность отправителей и получателей.
Давайте посмотрим на изображение, видим здесь входные данные, алгоритм или функцию хеширования и выходные данные. Хеш-функция принимает входные данные любого размера. Это может быть имейл, файл, слово, в нашем случае это слово "fox"/"лиса", и происходит конвертация данных при помощи хеш-функции в следующий вид: строка символов фиксированного размера. И эти значения, возвращенные хеш-функцией, имеют короткое название: хеш или хеш-сумма, или дайджест сообщения, или как тут указано, дайджест.
Далее, есть очень важная особенность хеш-функции - вы не можете конвертировать из хеша обратно в изначальные входные данные. Это односторонняя хеш-функция и для нее не нужны ключи. Вам лишь нужны входные данные, хеш-функция, и затем вы получаете результирующие выходные данные, которые всегда имеют фиксированный размер в зависимости от вида функции, которую вы используете.
Это обеспечивает целостность и позволяет обнаружить непреднамеренные модификации. Это не обеспечивает конфиденциальность, аутентификацию, это не позволяет определить наличие преднамеренной модификации.
Есть много примеров хеш-функций: MD2, MD4, MD5, HAVAL, SHA, SHA-1, SHA-256, SHA-384, SHA-512, Tiger и так далее. В наше время, если вы подбираете криптографическую систему, вам стоит использовать SHA-256 и выше, я имею ввиду SHA-384 и SHA-512.
====================
TrueCrypt v7.1a Hashes
====================
SHA256
========
Давайте я покажу вам несколько примеров того, как это используется на практике.
Окей, здесь у нас TrueCrypt, если не знаете, то это решение для полного шифрования диска, а здесь у нас файл, который мы скачиваем. Выделенное мной - это результирующий хеш, полученный в результате хеширования данного файла с применением алгоритма SHA-256. Когда вы скачиваете этот файл, то при помощи этой хеш-суммы можно удостовериться, что этот файл не изменялся, т.е. он обладает целостностью.
Есть инструменты, которые вы можете скачать, чтобы делать это. Одним из таких инструментов является Quick Hash, и я могу выбрать файл, например, установочный файл Chrome, перетащить его сюда, и мы видим здесь хеш этого файла Chrome для SHA-1, 256, 512. Вы можете заметить, что с увеличением этих цифр в алгоритме хеширования, длина хеша становится все больше, поскольку это длина в битах.
SHA-1 - короткий, 256, 512 и MD5, который слаб и не должен использоваться вообще.
Так что это является способом подтверждения того, что файл, который вы скачали, сохранил свою целостность.
Смышленые ребята зададутся вопросом: "Что, если файл, который я собираюсь скачать, уже скомпрометирован?" Допустим, вот у нас вебсайт дистрибутива Tails, позже мы еще поговорим о нем. Допустим, я хочу скачать Tails и вот ссылка для скачивания, здесь указан хеш этого файла, однако, если веб-сайт скомпрометирован, то это означает, что злоумышленники могли подменить данный файл для загрузки и добавить к нему что-либо, знаете, троян или что-то для слежки за мной, и они также могли подменить и контрольную сумму.
Итак, этот хеш ничего не значит. Он не поможет обнаружить преднамеренную модификацию файла. Нам нужно что-то еще для удостоверения, что данный сайт - это в действительности официальный сайт дистрибутива Tails. И здесь мы подходим к сертификатам, цифровым подписям и другим средствам.
Другой способ использования хешей, с которым вы познакомитесь, это хеширование паролей. Когда вы вводите пароль на веб-сайте или в операционной системе, крайне плохой способ хранить этот пароль в базе данных, поскольку если эта база данных окажется скомпрометированной, то и ваш пароль окажется скомпрометирован.
Что должно происходить - так это преобразование вашего пароля посредством функции формирования ключа пароля в хеш. Здесь у нас примеры преобразования пароля администратора в хеш в операционной системе Windows, и эти хеши хранятся в базе данных SAM внутри Windows. Позже мы обсудим эту базу и как она может быть скомпрометирована, но сейчас я лишь хотел привести пример использования хешей.
Следующий способ использования хешей - это включение заранее согласованного совместно используемого секретного ключа в сообщение, а затем хеширование этого сообщения, это называется HMAC, или код аутентификации (проверки подлинности) сообщений, использующий хеш-функции. Этот механизм обеспечивает аутентификацию и целостность, потому что у нас есть заранее согласованный ключ и у нас есть хеш, мы используем их комбинацию. Не беспокойтесь особо о деталях. Это лишь еще одна технология, используемая в криптосистемах, которую вам совершенно не обязательно пока что понимать в деталях.
Цифровые подписи
Теперь перейдем к цифровым подписям. Цифровая подпись - это значение хеша. Это результат работы хеш-функции с фиксированным размером, который зашифрован закрытым ключом отправителя с целью создания цифровой подписи или подписанного сообщения. С технической точки зрения цифровая подпись - это отметка, подтверждающая лицо, которое подписало сообщение. Это выдача гарантии на объект, который был подписан с ее помощью.
Если объект шифрования подписан цифровой подписью, то обеспечена аутентификация, потому что объект зашифрован при помощи закрытого ключа, шифровать которым может только владелец этого закрытого ключа. Это и есть аутентификация.
Она обеспечивает невозможность отказа от авторства, поскольку, повторюсь, использован закрытый ключ отправителя. И она обеспечивает целостность, поскольку мы хешируем.
Цифровая подпись может быть использована, например, в программном обеспечении. Может использоваться для драйверов внутри вашей операционной системы.
Может использоваться для сертификатов и подтверждать, что подписанные объекты исходят именно от того лица, которое указано в сертификате, и что целостность данных этих объектов была сохранена, то есть никаких изменений они не претерпели.
Давайте пойдем посмотрим на тот установочный файл Chrome, в свойства файла. Вы можете сделать это в любой операционной системе или версии Windows. Откроем вкладку цифровые подписи. Кликнем на подпись. Уже можем увидеть некоторые детали. И смотрим на сертификат.
Что мы здесь видим. Сертификат выдан: кому - Google, кем - VeriSign. Итак, VeriSign - это компания, чей закрытый ключ был использован для цифровой подписи этой программы. VeriSign сообщает: "Данное программное обеспечение легитимно и оно не подвергалось модификации". Здесь написано: "Сертификат предназначен для удостоверения того, что программное обеспечение исходит от разработчика программного обеспечения, программное обеспечение защищено от модификации после его выпуска". Чтобы узнать, действующая ли это цифровая подпись, или нет, нам нужно повернуть изначальный процесс в обратную сторону.
Итак, у нас есть цифровая подпись или подписанное сообщение, или подписанное программное обеспечение, далее мы используем открытый ключ отправителя, в нашем случае это будет VeriSign, для дешифрования, чтобы узнать хеш, который вы затем сможете верифицировать самостоятельно. У вас будет значение хеша, оно будет получено из цифровой подписи. Затем вы можете взять этот файл, прогнать его через такой же алгоритм хеширования и сравнить полученные хеши. Вы сможете проверить, что программное обеспечение сохранило целостность. Если говорить о программах, то все это происходит фоном и верифицируется без вашего ведома.
Если верификация не проходит, вы получаете сообщения с предупреждениями. Наверняка вы уже встречались с ними. Вот пример такого сообщения: "Windows не может верифицировать издателя данного драйвера". Это означает, что либо он не имеет цифровой подписи, либо ваша операционная система не доверяет VeriSign.
Когда мы будем рассматривать сертификаты, то узнаем, почему вы можете доверять или не доверять VeriSign. Windows 10 представила новую технологию под названием Device Guard, которая является способом использования цифровых подписей для фиксации того, что операционная система будет исполнять, а что нет. Device Guard позволит запуститься лишь определенным видам подписанных файлов, в теории вредоносные программы, "крысы" или трояны не смогут запуститься, поскольку они не подписаны.
Есть, конечно, и способы обхода этой технологии, и мы обсудим их позже, тем не менее, Device Guard является одним из слоев защиты.
Давайте пройдемся по этому материалу еще раз, потому что я уверен, некоторым все это может показаться довольно-таки трудным для восприятия. Итак, значение хеша, которое было зашифровано с применением закрытого ключа отправителя или выпуска ПО. Это цифровая подпись.
Это обеспечивает аутентификацию, неотказуемость и целостность. А если вы зашифруете что-либо и вдобавок снабдите это цифровой подписью, то вы сможете добиться конфиденциальности наряду с аутентификацией, неотказуемостью и целостностью.
Цифровые подписи удостоверяют, что программа или что-либо другое получены от определенного лица или издателя, и они защищают программное обеспечение или сообщения от их модификации после того, как они были изданы или отправлены.
Уровень защищенных cокетов SSL и безопасность транспортного уровня TLS
SSL и TLS используют все криптографические технологии, которые мы уже прошли, включая симметричные и асимметричные алгоритмы, хеши, цифровые подписи, коды аутентификации сообщений (MAC), для создания рабочего протокола обеспечения безопасности. SSL и TLS - это криптографические протоколы, созданные для обеспечения безопасности коммуникаций в сети или в Интернете.
SSL - это более старый протокол шифрования, а TLS более новый, однако люди до сих пор называют их одним названием - SSL, что немного раздражает и вводит в заблуждение. Множество сайтов по-прежнему используют старый SSL из-за вопросов совместимости, даже при условии, что из-за этого возникают проблемы в безопасности.
Примером использования TLS является HTTPS в URL-адресе веб-сайта. Но TLS может быть использован с любым другим протоколом типа FTP или в виртуальных частных сетях. Он используется не только с HTTP и не только для работы с веб-сайтами. TLS очень важен для безопасности и приватности в Интернете, поскольку это наиболее часто используемый способ шифрования данных в Интернете. TLS обеспечивает приватность, потому что с его помощью шифруются данные, и обеспечивает целостность, потому что он использует имитовставки, то есть коды аутентификации сообщений (MAC), во время обмена данными между двумя приложениями.
Например, когда ваш веб-браузер, приложение, обменивается данными с вашим интернет-банком, их приложением, коммуникация шифруется по принципу end-to-end от вашего приложения до их приложения при помощи TLS.
TLS поддерживает средства защиты конфиденциальности или приватности, аутентификации и целостности. Соединение приватно, потому что симметричный алгоритм, например AES, который мы обсуждали, используется для шифрования передаваемых данных. Ключи для этого симметричного шифрования генерируются уникальным образом для каждого соединения, и они основаны на секретном ключе, согласованном в начале сеанса.
Сервер и клиент согласовывают детали, какой алгоритм шифрования и криптографические ключи они будут использовать перед тем, как первый байт данных будет отправлен. Согласование совместно используемого секретного ключа не может быть считано злоумышленником, даже атакующим, находящимся посередине соединения.
Соединение также надежно в том, что атакующий не может модифицировать коммуникацию во время согласования и при этом остаться незамеченным.
Идентификационные данные лиц, обменивающихся данными, могут быть аутентифицированы при помощи криптографии с открытым ключом, сертификатов и цифровых подписей. Подобная аутентификация может использоваться по усмотрению, но в целом она обязательна для как минимум одной стороны, обычно для сервера, то есть веб-сайтов, которые вы посещаете. И я расскажу вам больше на эту тему, когда мы доберемся до сертификатов.
Соединение надежно, потому что каждое передаваемое сообщение проходит проверку целостности сообщения при помощи кодов аутентификации сообщений (MAC) с целью предотвращения невыявленной потери или изменения данных в процессе их передачи.
TLS поддерживает множество различных способов по обмену ключами, шифрованию данных и аутентификации целостности сообщений, многие из тех алгоритмов и технологий, которые мы уже обсуждали. И все же, в конечном итоге, безопасная конфигурация TLS включает в себя множество настраиваемых параметров, и не все из них позволяют использовать средства защиты приватности, аутентификации и целостности.
Теперь давайте обратимся к статье в Википедии на тему безопасности транспортного уровня, на этом сайте дано великолепное описание TLS. Видим здесь различные поддерживаемые способы обмена ключами, шифрования данных и аутентификации целостности ключей.
И первое, что мы видим здесь, это аутентификация и обмен ключами, а также различные поддерживаемые алгоритмы. Если вы припоминаете, мы говорили об асимметричных алгоритмах, так вот это именно они. Видим здесь RSA, Диффи-Хеллман — RSA, Диффи-Хеллман на эллиптических кривых и так далее.
Лучше всего использовать Диффи-Хеллмана с эфемерными ключами — RSA (с прямой секретностью), либо Диффи-Хеллмана на эллиптических кривых с эфемерными ключами — RSA (с прямой секретностью), или же Диффи-Хеллмана на эллиптических кривых с эфемерными ключами — алгоритм цифровых подписей на основе эллиптических кривых ECDSA (с прямой секретностью). В общем-то, проблема в том, что у вас и выбор-то не всегда есть. Сервер поддерживает определенные аутентификацию и методы согласования ключей, и если вы хотите обмениваться с ним данными, то вам придется использовать то, что он предлагает. Причина, по которой лучше использовать эти способы, в том, что они используют протокол Диффи-Хеллмана для обмена ключами, что позволяет обеспечить такое свойство приватности, как "прямая секретность", здесь это указано.
Это свойство дает гарантию, что ваши сеансовые ключи не будут скомпрометированы, даже если закрытый ключ сервера скомпрометирован. Это достигается тем, что уникальный сеансовый ключ генерируется для каждой сессии, которую пользователь инициирует. Даже компрометация единичного сеансового ключа не повлияет ни на какие данные, за исключением того обмена в том определенном сеансе, который защищался конкретно этим ключом.
Совершенная прямая секретность - это прогресс в вопросах по защите данных на транспортном уровне. Ее значимость увеличилась с момента появления таких уязвимостей, как Heartbleed. Итак, совершенная прямая секретность на деле означает, что если сервер, с которым вы общаетесь, скомпрометирован, и их закрытый ключ скомпрометирован, то все ваши предыдущие сеансы общения не могут быть дешифрованы, поскольку вы использовали протокол Диффи-Хеллмана для согласования сеансовых ключей, а они используются лишь в течение короткого промежутка времени.
Если мы спустимся ниже, то увидим используемые симметричные алгоритмы.
Когда мы говорим о сеансовых ключах, то мы имеем ввиду ключи, которые используются непосредственно для шифрования данных, потому что симметричные ключи быстрее. И помните, мы говорили об AES, что выбор AES - это хороший вариант? В этой таблице мы видим его и различные другие виды алгоритмов симметричного шифрования.
Нам показано, какие из них защищенные, а какие нет, по причине различного рода уязвимостей или слабых мест, и вот почему я рекомендовал вам использовать AES.
Здесь вы можете заметить, что есть какие-то другие аббревиатуры в комбинации с AES. Вам не нужно особо волноваться на этот счет. Это называется "режимом использования". Это различные способы для AES по скремблированию или шифрованию данных, которые не имеют особого значения в нашем случае для предмета нашего обсуждения. Достаточно знать, что вы используете AES и длину в битах, мы уже разобрались в этом вопросе.
Здесь вы также можете увидеть различные версии SSL. Собственно говоря, и это приводит многих людей в замешательство, первая версия SSL - это 2.0, самая ранняя версия из всех представленных в этой таблице, следующая версия - это SSL 3.0, далее идет TLS 1.0 Обратите внимание, следом за тройкой для SSL идет единица для TLS.
Итак, TLS 1.3 - это самая последняя и наиболее защищенная версия, но она наименее совместима с браузерами. Когда вы используете TLS, вам реально стоит использовать TLS 1.0 или выше. Видим здесь, какие из них защищенные, а какие нет. Обратите внимание, что если вы используете TLS 1.0, то даже несмотря на AES, тут указано "Зависит от воздействия".
Давайте спустимся еще ниже. Здесь мы видим хеши, а также имитовставки (MAC), которые используются с целью сохранения целостности данных. MD5 не стоит использовать, SHA1 определенно уже устарел, и нам стоит начать использовать актуальные версии SHA, а именно 256 и 384. Однако по причинам совместимости, они могут быть использованы не во всех случаях.
Предпринимались попытки скомпрометировать и подорвать аспекты безопасности, так что протокол TLS был несколько раз пересмотрен в ответ на развивающиеся угрозы безопасности и для выявления слабостей и уязвимостей. Примерами таких угроз были: Beast, Crime, Poodle, Logjam, все с интересными названиями.
Можете погуглить на этот счет и поискать детали, если интересно, а результатом всего этого стало то, что разработчикам пришлось обновлять браузеры и серверные реализации SSL, чтобы справиться с атаками и защититься от этих уязвимостей.
Перейдем к следующей таблице, здесь мы видим список версий Firefox. В этой строке Firefox версий с 27-й по 33-ю. И вы можете увидеть уязвимости Beast, Crime, Poodle, Freak, Logjam. А если мы посмотрим на версии от 36-й до 38-й, то они подвержены уязвимости Logjam. Если будем смотреть на все более старые версии, то увидим, что они становятся все более и более подверженными различным слабостям и уязвимостям, вот почему вам следует использовать самую последнюю версию браузера, где это возможно. Серверы и сайты, на которые вы заходите, также должны быть обновлены до последних версий.
И все дело в том, что вы не можете всегда контролировать это. И если вам нужна приватность, максимальная приватность, и вы знаете, что ваш сервер не защищен, либо уязвим перед некоторыми из этих вещей, поскольку он, возможно, использует TLS 1.0, то вы должны понимать, что нельзя взаимодействовать с ним, поскольку это будет небезопасно и неприватно.
Совокупность алгоритмов, используемая для TLS/SSL, называется Cipher suite (рус."Набор шифров"). Полезно знать самые сильные и наиболее совместимые наборы шифров. Вместо того, чтобы дать вам их список, я покажу вам ресурсы, где их искать. Таким образом вы сможете при необходимости найти самый актуальный набор шифров, который будет наиболее защищенным и совместимым. Если сегодня я дам вам готовый список, завтра может появиться новая уязвимость, и она сделает порядок недействительным.
Пожалуй, один из лучших сайтов для поиска хорошего Cipher suite с совместимостью, или даже самый лучший сайт, который я только знаю, это Mozilla.org, и люди, стоящие за Firefox.
Что мы здесь видим, это список из Cipher suite в порядке убывания приоритета. Выделяю наиболее актуальный (ECDHE-ECDSA-AES256-GCM-SHA384), а вот наименее оптимальный, но все же сильный (ECDHE-RAS-AES128-SHA256). Плюс здесь указаны все наилучшие варианты, такие как версия TLS, тип сертификата, подпись сертификата и так далее.
Если подняться выше, то увидим совместимость этих шифров. Это самые старые совместимые клиенты, которые смогут работать с этими шифрами. Так что это и вправду отличный список сильнейших шифров, таких, которые вам стоит использовать в приоритете.
Также, если спуститься вниз, то здесь есть список, предназначенный для повышенной совместимости. Если вы ищите список, который будет работать с большим количеством клиентов, то это хороший вариант.
Спустимся еще ниже... Вот здесь, указаны все шифры. Еще ниже, видим вообще наиболее совместимый список, который будет работать с реально старыми клиентами.
https://mozilla.github.io/server-side-tsl/ssl-config-generator
Если вам нужно сконфигурировать сервер, то ознакомьтесь с этим. Это реально крутой инструмент. Если мы выберем нужный вид сервера... Итак, здесь выбираем сервер. Допустим, это Apache. Может быть, вам нужна устаревшая версия, или промежуточная, или актуальная, и затем нам выдается конфигурация. Видим здесь, что все уже настроено для нас. Не хотим SSLv3, TLSv1 или TLSv1.1 Так что он будет работать с TLSv1.2, и вот все наборы шифров. Этот инструмент сделал все красиво. Так что, да, это действительно классно.
http://waekdh.org/sysadmin.html
https://www.grc.com/miscfiles/SChannel_Cipher_Suites.txt
Другой сайт для поиска хорошего списка с шифронаборами - это weakdh.org Вот один набор. И другой сайт я бы порекомендовал от Стива Гибсона, вот его список в формате, подходящем для серверов Windows. Это также хороший список в порядке приоритетности с наборами шифров.
SSLStrip
Любой атакующий, который может расположиться между источником и адресатом трафика, здесь у нас источник, здесь адресат, этот атакующий может совершить атаку вида “Man in the middle” (рус. "Человек посередине"). Одна из подобных атак, которая требует весьма небольших навыков и ресурсов, называется SSL stripping (рус. "Снятие SSL"). Атакующий выступает в роли прокси здесь и подменяет зашифрованные HTTPS-соединения на HTTP-соединения.
http://www.thoughtcrime.org/software/ssltrip/
И есть бесплатный инструмент для проведения таких атак, называется SSLStrip, который работает с HTTP, использующим SSL. Он создан парнем по имени Moxie Marlinspike, это достаточно широко известный исследователь в области безопасности.
Давайте подумаем, как, собственно говоря, мы попадаем на HTTPS веб-сайты. Есть пара основных способов, как это можно сделать. Вот первый способ. Вбиваем в адресную строку браузера адрес сайта, на который хотим зайти и нажимаем Enter.
В большинстве случаев мы не набираем https://. Что происходит далее: мы отправляемся на HTTP веб-сайт, а затем сервер дает нам так называемый 302-й редирект и отправляет нас на эту HTTPS-версию веб-сайта.
Другой способ попасть на HTTPS веб-сайты - это переход по ссылке. Допустим, я нашел что-нибудь в Google, получил ссылку, и мы видим, что это HTTPS-ссылка, и затем она приводит нас прямиком на HTTPS-версию Facebook.
Как работает SSLStrip. Он выступает в роли прокси, который ищет эти два вида событий: 302-е редиректы и переходы по HTTPS-ссылкам, а затем проксирует эти соединения. Итак, вы устанавливаете исходное HTTP-соединение, оно достигает сервера, сервер отвечает: "Вообще-то нет, это должно быть HTTPS-соединение", и отправляет вас обратно.
SSLStrip здесь проксирует ответ от веб-сервера, имитируя ваш браузер, и отправляет вам обратно HTTP-версию сайта. Сервер никогда не заметит отличий. Он думает, что общается с вами. Он верит, что это - ваш браузер. И что вы увидите - это будет практически неотличимо от подлинного сайта.
Чтобы произвести эту атаку, вам нужно быть посередине. Вам нужно иметь возможность видеть трафик, чтобы вы могли его разобрать. А находиться посередине чьего-либо трафика не всегда так просто. Это зависит от того, где вы находитесь.
Если вы в чужой сети, например, на работе или в интернет-кафе, в сети интернет-провайдера, владельцы этих сетей, они контролируют эти сети, так что они находятся посередине. По этой причине они могут произвести подобного рода атаку. Однако это не очень искусная атака, поскольку вы можете заметить отсутствие HTTPS. При проведении целевой атаки правительство вполне может использовать этот метод, однако это весьма маловероятно, и еще более низка вероятность того, что они решат делать это для массовой слежки, разве что это не какое-нибудь там небольшое диктаторское правительство, которое занимается подобными вещами, ведь это довольно-таки простейшая форма атаки, эффективная при небольших ресурсах, низкоквалифицированных атакующих, а не атака по-настоящему государственного уровня.
Рандомному киберпреступнику, сидящему где-то на удалении от вас, будет достаточно трудно попасть в середину вашего трафика. Не очень-то много есть механизмов, чтобы осуществить это, и поэтому, более вероятно, что такой атакующий попытается вместо этого атаковать ваш клиент, ведь это попросту легче сделать, а люди всегда идут по легкому пути, избегая сложного. И если они совершают атаку на ваш клиент и попали в ваш клиент, завладели им, то им не нужно снимать SSL, поскольку они и так смогут увидеть ваши данные, ведь они уже в вашем клиенте.
Другой интересный способ для проведения этой атаки - когда атакующий находится в вашей локальной сети, так что это либо происходит по Ethernet-кабелю, либо по беспроводной связи через Wi-Fi. Они могут обмануть вашу машину и заставить ее отправлять трафик через них, и это известно как ARP-спуфинг, или ARP-отравление. Атакующий посылает ARP-пакеты, имитируя шлюз жертвы по умолчанию.
Это работает, потому что у Ethernet нет механизмов для аутентификации, нет этого функционала, поэтому любая машина в принципе может отправить то, что называется ARP-пакетом, и сообщить, что она - одна из машин в этой сети, например, шлюз или маршрутизатор, и это приводит к тому, что вы начинаете отправлять свой трафик через фейковый маршрутизатор, который затем переправляет его, попутно снимая SSL, и после этого переправляет трафик обратно к вам, как мы уже видели.
http://www.irongeek.com/i.php?page=security/AQuickIntrotoSniffers
Если вы хотите больше узнать об ARP-спуфинге, я бы порекомендовал этот веб- сайт, он довольно-таки хорош. Вот небольшая схема, на ней атакующий говорит: "Смотри, я маршрутизатор", и трафик начинает ошибочно идти через него. В Kali есть инструменты под названием Ettercap и Arpspoof, и конечно же, SSLStrip, которые позволяют вам совершать подобного рода атаки.
http://www.oxid.it/cain.html
И есть инструмент под названием Cain & Abel, вот адрес сайта, вы можете использовать его под Виндой.
http://www.thoughtcrime.org/software/ssltrip/
А это сайт инструмента SSLStrip, тут перечислены команды, как работать с ним.
И все, что вам нужно для выполнения SSL stripping или ARP-спуфинга если вы в локальной сети, все это доступно в Kali. Тут приведены команды, которые следует запускать, все предельно просто.
Здесь включение ip_forward, внесение некоторых изменений в iptables, чтобы HTTP-трафик перенаправлялся на SSLStrip. Запуск SSLStrip, тут нужно указать порт. И далее включение arpspoof, где вы говорите целевой машине отправлять ее трафик вам. В общем, можете поэкспериментировать с этим в Kali, если есть желание.
Еще один интересный способ снятия SSL - это установка подставной точки доступа. Она может быть затем настроена для автоматического снятия SSL. Подставная точка доступа - это когда вы подключаетесь к Wi-Fi сети, а владелец этой Wi-Fi сети пытается вас атаковать, это подставная или поддельная точка доступа. И вы можете настроить эту точку доступа для снятия SSL точно таким же образом, как мы обсуждали, потому что вновь атакующий находится посередине, ведь вы подключаетесь через него.
Собственно говоря, вы можете купить оборудование, которое будет делать это за вас. Это WiFi Pineapple. Есть и другие версии, но я бы порекомендовал взять его в аэропорт или другое людное место, включить, поднять открытую сеть, говорящую "Бесплатный WiFi" или что-нибудь типа того, и вы будете поражены полученным количеством паролей от Facebook, Google и многих других сайтов. Люди попросту не замечают снятие SSL.
Пожалуй, стоит отметить, что когда вы делаете снятие SSL, это означает, что соединение перестает быть зашифрованным, и следовательно вы можете видеть все содержимое трафика, то есть у вас появляется возможность красть имена пользователей и пароли, и попросту наблюдать за всем тем, чем занимается определенный человек.
Давайте теперь подумаем, что можно сделать для предотвращения всего этого? Что ж, на клиентской стороне вы можете попытаться замечать те случаи, когда у вас отсутствует HTTPS, но если вы будете заняты, то вряд ли сможете это заметить. И тем не менее, вам следует обращать на это внимание.
Более надежный метод - это использование туннеля или шифрованного туннеля, так чтобы снятие SSL стало невозможно, поскольку трафик, который вы отправляете, будет зашифрован иным способом.
Например, можно использовать SSH туннелирование.
Можно использовать VPN-технологию типа IPsec. А вообще, стоит обратить внимание на end-to-end шифрование, и мы поговорим об этом позже.
Помимо всего прочего, вам лучше не подключаться к сомнительным сетям без использования туннелирования или VPN или шифрования, потому что это именно то, что может произойти, если у вас их нет. Ваш SSL может быть снят и весь ваш трафик станет открытым. В этом курсе мы также обсудим виртуальные частные сети VPN.
Наличие ARP-спуфинга и сниффинга в вашей локальной сети можно в определенной степени обнаружить, и есть пара инструментов для примера, которые вы можете использовать. Это Arpwatch. Он мониторит вашу Ethernet-сеть на наличие ARP-спуфинга или отравления. И есть другой инструмент, это Sniffdet, он обнаруживает тех, кто наблюдает за сетевым трафиком.
Что касается серверной стороны, и я выведу это на экран, у вас может не быть контроля за серверной стороной, но я полагаю, в некоторых случаях, такой контроль имеется. Есть возможность активации строгой безопасности передачи данных по протоколу HTTP, сокращенно HSTS, этот механизм использует особый заголовок для принудительного использования браузером только лишь HTTPS-трафика.
Это работает только если вы ранее посещали сайт, и затем ваш клиент фактически запоминает, что данный сайт принимает исключительно HTTPS-трафик. А вот пример того, как я снял SSL и получил сообщение об ошибке, потому что на этом сайте была активирована строгая транспортная безопасность HTTP.
Другим способом предотвращения снятия SSL или ARP-спуфинга и отравления является использование виртуальных локальных сетей и другие формы изоляции сетей.
Виртуальная локальная сеть предотвращает перемещение трафика из одного сегмента сети в другой сегмент сети при помощи коммутатора и особых тегов. Если вам это интересно, погуглите виртуальные локальные сети VLAN.
Также можно иметь полную изоляцию сети при условии, что атакующий не находится в этой же физической сети, потому что вы и ваш трафик не будете проходить через атакующего, вы будете использовать разные сетевые коммутаторы или проходить через разные маршрутизаторы, и понятно, что атакующий не сможет получить доступ к вашему трафику.
Вы также можете использовать файрволы для предотвращения перемещения трафика в определенных направлениях, вы можете настроить WiFi таким образом, чтобы получить изоляцию при помощи конфигурации вашей точки доступа, и вы можете поднять раздельные WiFi-сети, например, гостевую сеть, или сеть 1 и сеть 2, и эти две сети не смогут видеть трафик друг друга. В общем, есть множество вещей, которые вы можете сделать на сетевом уровне. Мы более подробно рассмотрим эти вопросы, когда будем говорить о вашей локальной сети и WiFi.