Интересное о Google

Опубликовано Опубликовано в рубрике Безопасность

  

Знаете ли вы, что G00gle подслушивает вас на смартфоне и не скрывает этого. Он может подслушивать вас в любое время, когда вы об этом даже не подозреваете! И не только тогда, когда вы разговариваете по телефону, но и когда телефон лежит просто рядом, скажем в кармане. Однако вы можете легко справиться с этой, кажущейся на первый взгляд, непростой задачей!

Обращайте внимание на вашу активность в аккаунте https://myactivity.google.com/myactivityПройдя по данной ссылке, вы сможете следить за своей активностью в аккаунте в любой момент времени. А вот по этой ссылке — https://myaccount.google.com/activitycontrolsвы можете контролировать, что создателю android слушать, а что нет. Это очень просто и удобно!

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

 

от DNS к DNSSEC

Опубликовано Опубликовано в рубрике WEB, Безопасность

Почти каждое обращение к информационным ресурсам Интернета начинается со взаимодействия с доменной системой имен DNS. Будь то посещение веб-сайта, обмен почтовыми сообщениями или общение в социальной сети, для определения фактического нахождения ресурса, а именно его IP-адреса, необходима DNS. Эта система обеспечивает трансляцию имени ресурса (например, facebook.com) в его IP-адрес (2a03:2880:f129:83:face:b00c::25 de), необходимый для установления связи.

Система DNS является иерархической и распреде­ленной. Каждый из компонентов доменного имени обслуживается независимым оператором, а трансляция имени происходит посредством последовательного обращения к серверам, обслуживающим базы данных этих имен, или «зон», за ответом. Ответом может быть или указание на сервер, обслуживающий следующий компонент имени (т.н. реферрал), или окончательный ответ.

  • Рис. 1 Уязвимые места DNS.

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

Для того чтобы лучше понять важность обеспечения безопасности DNS, рассмотрим, насколько уязвима система в целом. Различные уязвимые места системы показаны на рисунке 1, а методы защиты — на рисунке 2.

Первый вопрос — насколько защищен собственно процесс подготовки данных, редактирования и создания зоны DNS. Ошибочные данные, умышленно или случайно оказавши­еся в зоне, например, неправильные адреса веб-сайта или почтовых серверов, будут переданы пользователю в ответ на его запрос независимо от использования протоколов защиты DNS, таких как DNSSEC. В данном случае значение имеет уровень внутренней безопасности и защищенности процесса.

Данные также могут быть модифицированы при передаче от мастер-сервера ко вторичным DNS-серверам, обслужи­вающим зону. Сегодня для проверки целостности передачи данных используется протокол TSIG (Transaction SIGnature), описанный в стандарте IETF RFC 2845 «Secret Key Transaction Authentication for DNS (TSIG)».

Ответы от DNS-серверов также могут быть модифици­рованы в процессе передачи в Интернете, но, пожалуй, наибольшую опасность представляет попадание непра­вильных данных в кэш итеративных резолверов — так называемое отравление кэша. Дело в том, что продолжи­тельность жизни данных в кэше, определяемая параметром TTL записи ресурса (например, IP-адрес веб-сайта), может быть достаточно значительной. Это означает, что в течение всего этого времени при модификации данных кэша пользователи будут получать подложные ответы. Более того, внедрение подложных данных в кэш резолвера не представляет особого труда, как было продемонстрировано Дэном Камински в 2008 году. С тех пор в программное обеспечение большинства стандартных резолверов были введены изменения, усложняющие проведение атаки, но только DNSSEC является единственным эффективным методом защиты, поскольку позволяет криптографически проверить аутентичность данных перед загрузкой их в кэш.

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

Рис. 2 Методы защиты DNS.

Наконец, ответы резолвера на запросы клиентов могут быть также модифицированы. DNSSEC здесь не поможет, если пользователь не производит проверку подлинности ответов самостоятельно, а полагается на резолвер. Правда, канал между резолвером и пользователем как правило находится под административным контролем сервис-провайдера или администратора корпоративной сети, и зачастую имеет высокую степень защиты, напри­мер, с помощью VPN.

Эффективным средством противостояния послед­ствиям модификации данных DNS является применение расширений безопасности DNS, разработанных в рамках IETF (Internet Engineering Task Force, www.ietf.org) и получивших название DNSSEC.

Как защитить DNS?

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

В рамках IETF были расширены возможности стандартно­го протокола DNS для решения проблемы аутентичности и целостности данных. Эти расширения получили название DNSSEC. Основная спецификация DNSSEC содержится в стандартах IETF RFC4033, RFC4034, RFC4035 и RFC5155.

С помощью DNSSEC пользователь имеет возможность убедиться, что полученные данные не были модифи­цированы в процессе публикации и передачи. Другими словами, убедиться в том, что данные, содержащиеся в ответе на запрос DNS, в точности соответствуют данным в зоне для запрашиваемого доменного имени.

В рамках стандартного подхода к информационной без­опасности рассматриваются три основных аспекта данных — их конфиденциальность, целостность и доступность. Целью технологии DNSSEC является защита целостности данных, а точнее, обеспечение возможности проверки целостности данных. Конфиденциальность не является требованием в DNS, а доступность обеспечивается путем усиления инфраструктуры — например, использования технологии аникаст. Кстати, при использовании аникаст вопросы аутентичности и целостности данных встают еще острее, увеличивая ценность DNSSEC.

DNSSEC основан на криптографии с использованием открытых ключей. Администратор зоны подписывает все записи зоны своей цифровой подписью. Там же админи­стратор публикует и открытый ключ, соответствующий этой цифровой подписи. Таким образом, путем проверки подлинности цифровой подписи и ее принадлежности администратору зоны пользователь может убедиться в целостности и аутентичности полученных данных.

Подлинность открытого ключа удостоверяет администра­тор родительской зоны путем включения в зону т.н. записи DS, представляющей собой хэш открытого ключа дочерней зоны. Разумеется, эта запись заверена цифровой подписью администратора этой родительской зоны. Его же ключ удостоверяется администратором зоны верхнего уровня — и так далее, пока не будет достигнута так называемая точка доверия (trust anchor) — ключ, которому пользователь абсолютно доверяет. В DNSSEC таким ключом является ключ корневой зоны «.».

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

К счастью, цепочка доверия DNSSEC полностью соответ­ствует структуре делегирования имен, поэтому процесс построения цепочки доверия и разрешения имен происхо­дит одновременно. На рисунке 3 показана цепочка доверия в DNSSEC.

Из рисунка, кстати, видно, что в DNSSEC используются два типа ключей – так называемый ключ KSK (Key Signing Key, ключ подписи ключей) и ключ ZSK (ключ подписи зоны). Первый является ключом долговременного пользования и, соответственно, более сильным в криптографическом плане. Именно хэш ключа KSK «экспортируется» в родительскую зону в виде записи DS, устанавливая тем самым цепочку доверия. Ключ ZSK служит для подписания записей самой зоны. Ключ ZSK удостоверяется администратором домена путем подписи его ключом KSK. Поскольку в изменении ZSK задействован только администратор домена, этот процесс может (и должен) происходить достаточно часто.

Еще одной важной особенностью DNSSEC является то, что он позволяет удостовериться, что запрошенное имя не существует. Другими словами, при запросе разрешения несуществующего имени пользователю будет возвращен криптографически заверенный ответ, указывающий на отсутствие запрашиваемой записи в зоне. Для этого в DNSSEC используются технологии NSEC и NSEC3 (ru.wikipedia.org/wiki/DNSSEC).

В то же время DNSSEC не является панацеей. Даже если полученные адреса серверов являются правильными, обмен данными может быть перехвачен или перена­правлен с использованием уязвимых мест системы маршрутизации. Также DNSSEC не обеспечивает шифрова­ние данных, здесь необходима другая, довольно широко распространенная технология TLS (Transport Layer Security), использующая цифровые сертификаты X.509, на которой базируется протокол HTTPS. Наконец, DNSSEC не спасет от гомографии, когда имя сервера внешне очень похоже на другое имя, но на самом деле использует другие симво­лы, например, «1» и «l».

И все же, использование DNSSEC совместно с другими средствами защиты существенно усиливает их эффек­тивность. Например, в противоположность сертификатам доменных имен, используемых в TLS/HTTPS, цепь дове­рия в DNSSEC следует цепочке делегирования доменов и, таким образом, основана на деловых отношениях, существующих при регистрации доменов.

DANE

Внедрение DNSSEC также открывает новые возмож­ности. Например, решить проблемы, связанные с сертификатами для проверки достоверности веб- или почтовых серверов и обмена информацией с использо­ванием защищенного протокола TLS. Так называемая система Web-PKI.

Дело в том, что выдачей этих X.509-сертификатов занимаются несколько сотен независимых удостоверяю­щих центров (УЦ), которые используют данные третьих сторон (например, данные от компаний-регистраторов) для верификации прав пользования доменным именем. Конкретный список доверенных УЦ определяется производителями веб-браузеров – такими компаниями, как Google, Apple, Mozilla Foundation и т.д. Хотя в выборе УЦ они руководствуются требованиями CA/Browser Forum, а также результатами аудита WebTrust Task Force  и ETSI , в основном этот процесс закрыт и непрозрачен.

В Web-PKI все УЦ, корневые сертификаты которых установлены в браузере пользователя, имеют право выдавать сертификаты для любого доменного имени и при этом имеют одинаковый уровень доверия. Любой из этих корневых сертификатов является так называемой точкой доверия (trust anchor, TA). Это значит, что УЦ с недостаточ­ным качеством проверок прав владения именем является «слабым звеном» всей системы. Злоумышленник может использовать такой УЦ для получения конкурирующего сертификата для уже существующего чужого имени или сертификата для несуществующего имени. Даже флаг­маны индустрии оказываются уязвимы – так, компания Symantec на протяжении нескольких лет генерировала сертификаты для несуществующих имен, с просроченным сроком действия и другими нарушениями требований CA/ Browser Forum.

Дело усугубляется еще и тем, что корневые УЦ часто делегируют полномочия выдачи сертификатов подчинен­ным УЦ. В результате в Интернете существует большое количество доверенных УЦ, качество регистрационных процессов которых проверить практически невозможно.

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

Здесь на помощь приходит DNS. Действительно, если владелец имени или зоны контролирует публикацию такой важной информации, как IP-адреса сайтов, почтовых серверов, обслуживающих домен, и т.п., почему бы не создать новую запись, с помощью которой владелец смог бы указать на сертификат, который следует использовать при обращении к сайту, почтовому серверу и т.д.? Разумеет­ся, эта запись должна быть защищена, и DNSSEC выполняет эту функцию.

Разработка и стандартизация соответствующих прото­колов велась в рамках рабочей группы IETF DANE. DANE позволяет владельцу домена указать, какой сертификат TLS/SSL должно использовать приложение или служба для подключения к вашему сайту. Для этого используется запись TLSA, стан­дартизованная в RFC6698 “The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA” и RFC7671 «The DNS-Based Authentication of Named Entities (DANE) Protocol: Updates and Operational Guidance”.

Основой DANE является новая запись ресурса TLSA. Эта запись с доменным именем хоста и содержит инструкции по использованию TLS/SSL-сертификата при доступе к сервису по указанному порту и протоколу.

Давайте чуть подробнее остановимся на поле «Исполь­зование сертификата». Это поле определяет проверки, которые браузер с поддержкой DANE должен выполнить перед принятием решения об использовании сертификата, полученного от веб-сайта. Эти проверки схематично отображены на рис. 4.

Значение 0 (PKIX-TA) указывает, что путь валидации полу­ченного сертификата, или открытого ключа, в зависимости от значения поля «Селектор», должен проходить через сертификат, указанный в поле «Данные, ассоциированные с сертификатом». Это может быть как корневой, так и под­чиненный сертификат, но в любом случае путь валидации должен заканчиваться точкой доверия, зарегистрированной в пользовательском браузере.

Значение 1 (PKIX-EE) накладывает ограничение на серти­фикат, полученный от веб-сервера. Он (или его открытый ключ) должен соответствовать «данным, ассоциированным с сертификатом». При этом сертификат должен пройти проверку, используя путь валидации к одной из точек доверия браузера.

Значение 2 (DANE-TA) применяется для определения сертификата, который должен использоваться в качестве новой точки доверия при валидации сертификата, полученного от веб-сервера. Этот метод также называют «утверждением точки доверия», поскольку он позволяет владельцу доменного имени указать точку доверия, которая не входит в стандартную коллекцию TA пользова­тельского браузера.

Наконец, значение 3 (DANE-EE) определяет метод, когда сертификат (или его открытый ключ), полученный от сервера, должен совпадать с сертификатом, указанным в записи TLSA. Этот метод позволяет владель­цу доменного имени использовать собственные сертификаты без при­влечения сторонних УЦ. Этот метод отличается от PKIX-EE тем, что не требует дополнительной валидации сертификата через путь доверия.

DANE может использоваться не только при взаимодействии с веб-серверами. Например, защита передачи данных между почтовыми серверами является чрезвычайно важной. При этом часто используется протокол TLS, но аутентичность сертификата сервера представляет еще большую проблему, чем в случае с Web-PKI. DANE и здесь окажет администраторам почтовых серверов неоценимую услугу, делая почтовую систему в целом более защищенной. Более подробно о проблематике защиты передачи почтовых сообщений между транспортными почтовыми агентами (Mail Transport Agent, MTA) и о применении DANE в этом случае для защиты протокола SMTP описано в RFC7672 “SMTP Security via Opportunistic DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS)”.

Другие протоколы приложений, например, IMAP или XMPP, могут также использовать DANE. Обсуждение использования DANE в этих случаях можно найти в RFC 7673 “Using DNS-Based Authentication of Named Entities (DANE) TLSA Records with SRV Records”.

 

Другими словами, DNSSEC+DANE обладают существенным потенциалом обеспечения защищенности коммуникаци­онной инфраструктуры Интернета на уровне приложений. Основной проблемой является внедрение этих технологий. Дело в том, что их полноценное использование зависит от усилий многих сторон, интересы которых не обязательно совпадают. Так, например, даже если владелец доменного имени заинтересован в его защите с помощью DNSSEC и DANE, его успех зависит от многих факторов, находящихся вне его контроля:

  • внедрен ли DNSSEC в родительской зоне?
  • поддерживает ли регистратор доменов DNSSEC и DANE (включение в зону соответствующих записей, а также записи защищенного делегирования DS в родительской зоне)?
  • выполняет ли резолвер пользователя валидацию DNSSEC?
  • поддерживает ли пользовательское приложение (веб-браузер, почтовый сервер) протокол DANE?

Отрицательный ответ на хотя бы один из приведенных выше вопросов сведет на нет защиту, предоставляемую этими технологиями. Этим объясняются весьма невысокие цифры внедрения этих технологий: процент внедрения DNSSEC не превышает пары процентов (есть исключения – например, в Германии уровень внедрения достиг 12% (https://eggert.org/meter/dnssec)), а проникновение DANE (записей TLSA) в этих подписанных зонах и того меньше – он составляет всего 1,8%. Использование DNSSEC (валидация ответов) находится на уровне 15%, во многом благодаря широкому использованию открытого резолвера Google (Google Public DNS), который осуществляет валида­цию ответов по умолчанию.

Однако не стоит отчаиваться. Знание этих возможностей — уже шаг в правильном направлении. Пользовательский интерес к защищенному DNS является существенным стимулом для внедрения сервис-провайдером DNSSEC и осуществления валидации запросов. Требования под­держки DNSSEC и DANE владельцев доменных имен будут рано или поздно услышаны регистраторами и операторами доменов.

 

http://internetinside.ru/zashhishhennyy-dns/  Автор: Андрей Робачевский

Что такое утечка DNS-запросов при использовании VPN?

Опубликовано Опубликовано в рубрике Безопасность

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

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

Без VPN ваше устройство обычно использует DNS-серверы, предоставляемые вашим интернет-провайдером. Оператор DNS-сервера, а также любой человек, у которого есть возможность прослушивать ваш сетевой трафик, могут увидеть полный список веб-сайтов и используемых вами приложений. Поэтому, разворачивая безопасную инфраструктуру вам надо позаботиться о двух собственных DNS серверах.

 

Как происходит утечка DNS-запросов при использовании VPN?

Может произойти одно из двух:

  1. Ваше устройство отправляет DNS-запросы за пределы туннеля VPN.
  2. Ваше устройство отправляет DNS-запросы через туннель VPN, но не к собственным DNS-серверам.

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

 

Разоблачение валотильности на ПАМП

Опубликовано Оставить комментарийОпубликовано в рубрике Безопасность

Всем привет. Разберем очень популярный вид крипто мошенничества в телеграме — ПАМП каналы.

Памп — это искусственное увеличение курса какой-либо криптовалюты, простыми словами — интенсивный рост цены (монет).

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

 

Админ вбрасывает криптовалютную пару, которую планируют пампить и в которой он уже открыл ордера на продажу.

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

Вот например типичная инструкция по работе с чатом при пампе, которая отправляется всем участникам группы:

ОСНОВНАЯ ИДЕЯ: За некоторое время до пампа сделать новостной вброс в чат о том, что известный человек/организация намерен вложить крупную сумму денег в случайную криптовалюту, и вот-вот станет известен результат, куда же будет совершено вливание.

«НОВОСТЬ» ДЛЯ ПАМПА : Не для кого не секрет, что Сбербанк активно внедряет блокчейн и даже вызвал дефицит видеокарт осенью. Герман Греф неоднократно заявлял, что Сбербанк имеет свой «инкубатор» по работе с блокчейном. Так вот, по инсайдерской информации, на биржах уже торгуются- тестируются несколько монет из Блокчейн инкубатора Сбербанка, и сегодня будет выбрана официальная монета сбербанка! С привязкой к карте Сбера!!! Это будет бомба! Ввод и вывод любой криптовалюты, через банкоматы Сбера. И эта же монета будет использоваться для внутренних транзакций банка. Рост гарантирован. Презентация для СМИ пройдет 19 января. До этого момента есть шанс заскочить по минимальной цене и подняться после оф. презентации.

РАБОТА С ЧАТОМ ДО ПАМПА: За некоторое время до пампа (предположительно минут за 15-20) во всех чатах нужно написать сообщение подобного содержания:

«Сбербанк планирует запустить собственную монету» «Про криптовалюты давно Греф говорит, не удивительно» «Говорят, Сбербанк запускает свою Крипту» и.т.д.

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

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

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

Вывод: ПАМП каналы — развод, не участвуйте в пампах, легких денег не бывает.

Как противостоять Wi-Fi взломщикам

Опубликовано Оставить комментарийОпубликовано в рубрике FEED, Безопасность

Как любопытные мошенники получают доступ к беспроводной сети?

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

Проверка подлинности беспроводной сети

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

 

Защита WEP

WEP-это аббревиатура проводного эквивалента конфиденциальности. Он был разработан для стандартов IEEE 802.11 WLAN. Его цель заключалась в том, чтобы обеспечить конфиденциальность, эквивалентную той, которая обеспечивается проводными сетями. WEP работает путем шифрования данных, передаваемых по сети, чтобы защитить его от прослушивания.

Проверка подлинности WEP

Открытая система проверки подлинности (СОАС) – это методы, предоставляет доступ к аутентификации станция запросила в зависимости от настроенной политики доступа.

Общий ключ аутентификации (SKA) – Этот метод отправляет зашифрованный вызов станции, запрашивающей доступ. Станция шифрует вызов с его ключом, то отвечает. Если зашифрованный вызов соответствует значению точки доступа, то предоставляется доступ.

Уязвимость WEP

WEP имеет существенные недостатки и уязвимости в дизайне.

Целостность пакетов проверяется с помощью циклической проверки избыточности (CRC32). Проверка целостности CRC32 может быть скомпрометирована путем захвата по крайней мере двух пакетов. Биты в зашифрованном потоке и контрольной сумме могут быть изменены злоумышленником таким образом, чтобы пакет был принят системой проверки подлинности. Это приводит к несанкционированному доступу к сети.WEP использует алгоритм шифрования RC4 для создания потоковых шифров. Сайфер входной поток состоит из исходной величины (IV) и секретным ключом. Длина от первоначальной стоимости (IV) составляет 24 бита, в то время как секретный ключ может быть 40 бит и 104 бита. Общая длина как начального значения, так и секрета может быть либо 64 бит, либо 128 бит.

Более низкое возможное значение секретного ключа позволяет легко взломать его.Слабые комбинации начальных значений недостаточно шифруются. Это делает их уязвимыми для атак.WEP-шифрование на основе паролей; это делает его уязвимым для словарных атак.Управление ключами-это плохо реализуется. Изменение ключей, особенно в больших сетях является сложной задачей. WEP не предоставляет централизованной системы управления ключами.Начальные значения можно использовать повторно

Из-за этих недостатков безопасности WEP был устарел в пользу WPA

 

Защита WPA

WPA является аббревиатурой Wi-Fi защищенный доступ. Это протокол безопасности, разработанный компанией Wi-Fi в ответ на недостатки, выявленные в WEP. Он используется для шифрования данных в беспроводных локальных сетей 802.11. Он использует более высокие начальные значения 48 бит вместо 24 битов, которые использует WEP. Он использует временные ключи для шифрования пакетов.

Слабости WPA

  1. Реализация предотвращения столкновений может быть нарушена
  2. Он уязвим к отказу от attacksPre-share услуги используйте клавиши фраз.
  3. Слабые пароли уязвимы для атак с использованием словаря.

 

Итак, разобрав два вида шифрования, теперь разберем, как же ломается Wi-Fi сети.

WEP для взлома

Взлом (cracking) — это процесс использования слабых мест безопасности в беспроводных сетях и получения несанкционированного доступа. Крекинг WEP относится к эксплойтам в сетях, использующих WEP для реализации средств управления безопасностью. Есть в основном два типа взлома, а именно;

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

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

 

WEP эксплоиты

  • Aircrack– сетевой сниффер и WEP взломщик. Можно скачать с http://www.aircrack-ng.org/
  • WEPCrack-это программа с открытым исходным кодом для взлома секретных ключей 802.11 WEP. Это реализация атаки FMS. http://wepcrack.sourceforge.net/
  • Kismet — это может включать в себя сниффер скрытых  и открытых  беспроводных сетей для  обнаружения возможных вариантов вторжений. http://www.kismetwireless.net/
  • WebDecrypt-этот инструмент использует активные атаки словаря для взлома клавиш WEP. Он имеет свой генератор ключей и реализует пакетные фильтры. http://wepdecrypt.sourceforge.net/

 

WPA эксплоиты

Для проверки подлинности WPA использует 256 общих ключей или парольной фразы. Короткие пароли уязвимы для словарных атак и других атак, которые могут быть использованы для взлома паролей. Следующие инструменты можно использовать для взлома ключей WPA.

  • Коровья лепешка– этот инструмент используется для взлома предварительных ключей (PSK) с помощью брутфорс-атаки. http://wirelessdefence.org/Contents/coWPAttyMain.htm
  • Cain & Abel– этот инструмент может использоваться для декодирования захваченных файлов  из других программ при помощи снифферов, таких как Wireshark. Файлы захвата могут содержать WEP или WPA-PSK закодированные кадры. http://www.softpedia.com/get/Security/Decrypting-Decoding/Cain-and-Abel.shtml

 

Общие типы атак

  1. Сниффер (Sniffing) —  включает перехват пакетов по мере их передачи по сети. Собранные данные затем могут быть расшифрованы с помощью таких инструментов, как Каин & Абель.
  2. Атака «Человек в середине» (Man in the Middle MITM) – это подслушивание в сети для захвата конфиденциальной информации.
  3. Отказ в обслуживании атаки (Denial of Service Attack) – основной целью этой атаки является отказ законным пользователям сетевых ресурсов.
  4. FataJack может быть использован для выполнения этого типа атаки.

Взломы ключей беспроводной сети с WEP/WPA

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

Мы предоставим вам основную информацию, которая поможет вам противостоять терпеливым хакерам. Backtrack разработан на основе операционной системы Linux. Он разработан на основе последней версии Ubuntu. Backtrack поставляется с набором инструментов безопасности. Backtrack могут быть использованы для сбора информации, оценки уязвимости и совершения взломов между другими объектами.

Некоторым из популярных средств, что отступать уже включает;

  • Metasploit
  • приложение Wireshark
  • Aircrack-ng
  • NMapOphcrack

Для взлома ключей беспроводной сети требуется терпение и ресурсы, упомянутые выше. Как минимум, вам понадобятся следующие инструменты

  • Беспроводной сетевой адаптер с возможностью ввода пакетов (аппаратное обеспечение)
  • Операционная система Kali. Вы можете скачать его здесь https://www.kali.org/downloads/Be в радиусе целевой сети.

Если пользователи целевой сети активно используют и подключаются к ней, то ваши шансы на взлом ее будут значительно улучшены.

Достаточное знание операционных систем Linux и рабочих знаний Aircrack и его различных скриптов.

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

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

Как защитить беспроводные сети

При минимизации атак на беспроводную сеть организация может принять следующие политики

  1. Изменение паролей по умолчанию, которые поставляются с помощью hardwareEnabling доступ механизма проверки подлинности к сети может быть ограничено, разрешая только зарегистрированные MAC-адреса.
  2. Использование сильных клавиш WEP и WPA-PSK, сочетание символов, числа и символов снижает вероятность взлома клавиш с помощью словаря и грубой силы атаки.
  3. Программное обеспечение брандмауэра также может помочь уменьшить несанкционированный доступ.

Хакерская Активность: Взломать Пароль Беспроводной Сети

В этом случае мы будем использовать Каина и Авеля, чтобы расшифровать сохраненные пароли беспроводных сетей в Windows. Мы также предоставим полезную информацию, которая может быть использована для взлома WEP и WPA ключей беспроводных сетей.

Декодирование паролей беспроводной сети, хранящихся в Windows

Скачать Каин и Авель по ссылке, приведенной выше.

Открыть Каин и Авель

Убедитесь, что вкладка Декодеры выбрана, а затем нажмите на беспроводную пароли из меню на левой стороне

Нажмите на кнопку со знаком плюс

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

Декодер покажет тип шифрования, SSID и пароль, который был использован.