Различия между версиями 1 и 14 (по 13 версиям)
Версия 1 от 2008-07-30 08:13:53
Размер: 10095
Редактор: eSyr
Комментарий:
Версия 14 от 2008-08-10 18:33:59
Размер: 13726
Редактор: George Tarasov
Комментарий:
Удаления помечены так. Добавления помечены так.
Строка 3: Строка 3:
Надо иметь две вещи в виду. Вещь первая: если вы хотите, чтобы какая-то сетевая служба при подкл. по сети спрашивала логин и парль (польз. уч. записью), то убедитесь, что он шифрует данные при передаче по сети. Какое был нарекание на mit magic cookie --- оно было недост. стйким. Надо, чтобы передачу никому нельзя был расшифрвать никому, крме вас. В новом мане по iptables, есть сводная табличка сервисов, которые уязвимы в этом смысле (ftp, telnet, http, ipmap, pop передают credentials в незашифр. виде, basic_auth передаёт ключи в незашифр. виде). От некоторых из этих служб следует тказываться. От телнета тказались совсем. От ftp пльз. лектор радеет, чтобы все отказались. Отказались от авториз. ftp. Есть замечательная утилита dsnif (?), лектор призывает почитать секцию description мана, там перечислены протоколы, из которых она выуживает пароли. Стоит иметь в виду следующее: если вы хотите, чтобы какая-то сетевая служба при подключении по сети спрашивала логин и пароль (пользовалась учетной записью), то вам необходимо убедиться, что она шифрует данные при передаче по сети и что это шифрование достаточно стойкое. Надо, чтобы передачу никому нельзя был расшифровать --- никому, кроме вас. В новом man iptables содержится сводная таблица сервисов, которые не отличаются надежностью в плане безопасности (ftp, telnet, http, ipmap, pop передают идентификационные данные в незашифрованном виде, basic_auth передаёт ключи в незашифрованном виде, а потом шифрует такими ключами). От некоторых из этих служб следует вообще отказаться, например, от telnet и от ftp с авторизацией. Есть замечательная утилита dsniff, в man'е которой в секции description перечислены протоколы, из которых она способна "выудить" пароли.
Строка 5: Строка 5:
К сжалению, лектр не будет расск. пр дноразовые пароли, поск. недовнедрил их в альте. К сожалению, в ALT Linux не применяются одноразовые пароли, и поэтому мы не станем о них рассказывать.
Строка 7: Строка 7:
Поэтому лектор перейдёт к взм. зашифрвать сам раффик. Если внутри протокола не предусм. шифрование, то попр. зашифр. передачу --- орг. секретный канал и гонять пароли в чистм виде. Разумное решение при усл, чт канал надёжен. Какие есть варианты в этм еле. К сожалению, лектор не очень знает ipv6, иначе бы он сослался бы на ipsec. он замечательно реализован в ipv4, но он не совсем изкоробоный, и кмплекс мер дост. сложный, и если сделать пару ошибок, то оно либ не заработает, лмбо секреты утекут. Поэтому стоит рассмотреть возможности, позволяющие зашифровать сам трафик. Если внутри протокола не предусмотрено шифрование, то можно попробовать зашифровать передачу --- организовать секретный канал и передавать пароли в чистом виде. Это разумное решение при условии, что канал надёжен. В этом случае стоило бы обратить внимание на ipsec, который замечательно реализован в ipv4, но он не работает "из коробки", и комплекс мер по его включению и настройке достаточно сложный, и если совершить какие-нибудь ошибки, то он либо не заработает, либо секретность не будет обеспечена.
Строка 9: Строка 9:
Поэтому будет рассм. SSL. SSl --- secure socket layer, это некая прослойка ежду паролем прикладным и транспортым (SSL). Есть некий аналог с уровнем представления ISO/OSI . Кгда мы дшли до урвня TCP, на вход вставляется шифрователь, на выхд --- дешифрватель. Мы закладываем в надёжный и зашифрванный канал. У этой штуки есть ручки на прикл. пртокол, что прилож. знало, что оно .исп. SSL. Собственно, это связано с тем, что у нас не исо/оси, и поэтому у нас есть https на 443 прту вместо http на 80 и так далее. С помощью утилиты stunnel можно сделать любе обычное соед. поверх SSL. Когда the bat не умел ssl, была методичка, как организовать его через stunnel ... . Много протоколов, в частности , http? imap, pop3, xmpp могут работать поверх ssl/ Из протоколов важно рассказать про SSL. SSL --- secure socket layer --- это некая прослойка между прикладным и транспортным уровнями сети. Есть некий аналог с уровнем представления ISO/OSI. В понятиях уровня TCP, на вход подается шифрователь, на выход --- дешифрователь, при этом используемый нами канал надежно зашифрован. У данного слоя есть выход на прикладной уровень, чтобы приложение знало, что оно использует SSL. Собственно, это связано с тем, что мы здесь не используем ISO/OSI, и поэтому у нас есть https на 443 порту вместо http на 80, и так далее. С помощью утилиты stunnel можно сделать любое "обычное" соединение поверх SSL, в частности, http, imap, pop3, xmpp могут работать поверх него.
Строка 11: Строка 11:
Главное дост. работы через ssl --- прзрачность для прикладного протокола. Мы пднимаем stunnel, и говорим приложению, что всё как было, так и есть. Главный недостаток --- как только эта схема перестаёт работать (как в случае ftp), так сразу мы упираемся в то, что приложение должно знать, что есть специальный прт, и внутри прикл. протокола нет спец. споособов упр. аутентификацией. Это всё за нас длжен делать уровень SSL. И прилож. обязано сделать это вместо stunnel. Есть другой способ, tls, он уже не явл. никаким промежуточным, это чисто модиф. прикл. урвня. Как это не смешно, TLS имеет гораздо больше ручек на прикл. уровне, и мжно много чего, чег в SSL сделать нельзя. Например, с SSL нельзя выдать разным сайтам на одном адресе выдать разные ключи. оск. на уровне ssl пикто о разных именах не знает, и у этих хостов один ip и дин ключ. На уровень tls это всё внедрено на уровень приложения. приложение ---> || SLL |||| TCP и тд. ||--->Internet--->|| TCP и тд. |||| SLL ||---> приложение
Строка 13: Строка 13:
В том же протоколе imap есть раширение start tls, эт команда протокола imap. С точки зрения прилож. tls --- часть прикл. протокола. Это команда уровня imap. Тоже отн. к pop3, ftp и тому же жабберу. Глвный нед. tls --- мы должны модиф. протокол прикл. уровня. Зат с помощью tls можно орг. ftp. Главное достоинство работы через ssl --- прозрачность со стороны прикладного протокола. После запуска stunnel приложение, работающее с каналом, "не заметит разницы" в своих действиях. Главный недостаток --- как только эта схема перестаёт работать (как в случае ftp), то сразу возникают проблемы - во-первых, приложение должно знать, что есть специальный порт, по которому надо слушать (нестандартный), и, во-вторых, внутри прикладного протокола нет специальных способов управления аутентификацией. За все это отвечает уровень SSL, и приложению придется организовать его самому в отсутствие stunnel. Есть другой способ, TLS, не являющийся промежуточным --- это модификация прикладного уровня. Соответственно, на прикладном уровне у его возможности гораздо шире, чем у SSL. Например, с SSL нельзя выдать разным сайтам на одном адресе выдать разные ключи. Поскольку на уровне SSL никто о разных именах не знает, то у этих хостов один и тот же ip и ключ. В TLS это вынесено на уровень приложения, то есть приложение решает, как шифровать и каким ключом. И, в отличие от SSL, когда протокол прикладного уровня не знает о его наличии, протоколам, поддерживающим TLS, известно, работает ли он в данный момент или нет.
Строка 15: Строка 15:
SSL. SSL это универс. туннелирование, TLS --- метод мдиф. пртокола ур. прилож. К примеру, в протоколе imap есть расширение, позволяющее включить TLS как команду самого протокола. С точки зрения приложения TLS --- часть прикладного протокола, команда уровня imap. Так же дела обстоят и в случае с pop3, ftp и xmpp. Главный недостаток TLS --- необходимость модификации протокола прикладного уровня. Но зато с его помощью можно защитить использование ftp.
Строка 17: Строка 17:
Как вобще всё это устрено: для тго, чтобы орг. вот этт метод шифр, исп. так. наз. ассим. шифрвание. Симметричное шифрование --- когда для дешифровки исп. тот же ключ, что и для шифрвки. Для ассим. шифр. исп. два ключа --- открытый и закрытый. С помощью любго из них можно расш., а зашифр. можно только с помощью закр. ключа. Для того, чтбы кто-то мог раш. данные, необх. ему отдать ткр. ключ, и он будет убеждён, что зашифровали их вы (если ключ не утёк). Это наз. электр. пдпись. Если вы шифр. ключом, то расшифр. их можн только закр. ключом. И это уже шифр. настоящее. В чём главное дост. ассим. шифр ---- вероятность утечки закр. ключа довольно низкая, так как этот ключ нигде не фигур. в акте передачи. Подводя итог, можно сказать, что SSL --- это универсальное туннелирование, а TLS --- метод модификации протокола уровня приложения.
Строка 19: Строка 19:
Недостаток главный ассим. метода --- вы должны иметь подтв. откр. ключи всех абонентов. Если вы не знаете, чт эт их ключи, т взм. след. ситуация: вы передаёте данные, шифр. их каким-то ключём, но он не тот, а тото, который вам подсунули. Человек в середине расш. данные, перешифр. их и передаёт дальше. =Устройство шифрования передачи=
Для того, чтобы организовать данный метод шифрования, используется так называемое асимметричное шифрование. При так называемом симметричном шифровании для расшифровки используется тот же ключ, что и для шифровки, а для используемого нами асимметричного шифрования используются два ключа --- открытый и закрытый. С помощью любого из них можно расшифровать, то что зашифровано с помощью другого ключа. Для того, чтобы кто-то мог расшифровать данные, необходимо передать ему открытый ключ, и он будет знать, что зашифровали их именно вы (если, конечно, ваш закрытый ключ надежно скрыт). Данный способ называется электронной подписью. Шифровка открытым ключом расшифровывается только с помощью закрытого --- это уже настоящее шифрование самих данных. Главное достоинство асимметричного шифрования ---- в том, что безопасность напрямую зависит только от сохранности закрытого ключа, а вероятность его утечки вообще-то довольно низка, так как этот ключ никак не фигурирует в акте передачи.
#что-то в том абзаце не так, вам так не кажется?? по поводу ключей...
Главный недостаток асимметричного метода --- вы должны иметь подтвержденные открытые ключи всех абонентов. Если вы не знаете, что это их ключи, то возможна следующая ситуация: вы передаёте данные, шифруете их каким-то ключём, но он не тот, который от того кому вы передаете, а тот, который вам подсунул человек сидящий где-то между вами. Человек в середине расшифровывает данные, перешифровывает их и передаёт дальше. Но такой человек должен перехватывать все пакеты между вами двоими. Но таких много. Есть маршрутизатор, а за ним еще маршрутизатор, и дальше тоже.
Строка 21: Строка 24:
Есть два варианта: вы долждны действ. убедиться в том, что ключ действ. тот самый.  ||компьютер Алисы|| ||компьютер Эвы (злоумышленник)|| 1. открытый ключ Боба ||компьютер Боба||
 || || 2. открытый ключ Эвы (выданный за ключ Боба) || || || ||
 || || 3. данные зашифрованные ключом Эвы || || || ||
 || || || || 4. теже данные зашифрованные ключом Боба || ||
Строка 23: Строка 29:
Другой способ сост. в том, чт этт ткр. ключ попадает не прсто так, а подписанный с помощью какоог-нибудь из ткр. ключей, которые у вас есть. В случае GPG вы подпис. ключи людей, кторым доверяете. В случае веб-сайтов есть фирмы, бизнес кторых состоит в подписывании ключей. Проблема сост. в трёх вещах:
 * Если хотите пдпис. ключ, то надо заплатить деньги
 * Сущестуют технологии, дост. пртсые, которые ровно этим и занимаются --- подкл. корневой серт, с помощью которго подпис. на всё остальне
 * Третья прблема в том, что вы не мжете знать, подписан сайт или нет.
Строка 28: Строка 30:
Допустим, нет человека в середине. Тогда вы дст. неплохо гаранитрованы, что трафик защищён. Есть два варианта: вы должны действительно убедиться в том, что ключ действительно тот самый.

Другой способ состоит в том, что этот открытый ключ попадает к вам не просто так, а подписанный с помощью какого-нибудь из открытых ключей, которые у вас уже есть. В случае GPG вы подписываете ключи людей, которым доверяете. В случае web-сайтов есть фирмы, бизнес которых состоит в подписывании ключей. Проблема состоит в трёх вещах:
 * Если хотите подписать ключ, то надо заплатить деньги
 * Существуют технологии, достаточно простые, которые ровно этим и занимаются --- подключают корневой сертификат, с помощью которого подписаны на всё остальные. Например пришел системный администратор и подписал все известные сертификаты этим сертификатом.
 * Третья проблема в том, что вы не можете знать, подписан сайт или нет.

Допустим, нет человека в середине. Тогда у вас есть достаточно неплохая гарантия , что трафик защищён. Так как закрытый ключ есть только у вашего собеседника, если он не утек. При этом важно чтобы его не было только при первом подключении, так как вы запомните открытый ключ и если он появится потом то вы поймете что он там.
Строка 38: Строка 47:
|| 0 || 1 || 1 || 1 || || 1 || SergeyKorobkov, GeorgeTarasov, VsevolodKrishchenko || || || || 40 || 1 || 1 || 1 || || 1 || SergeyKorobkov, GeorgeTarasov, VsevolodKrishchenko || || ||

Безопасность: сетевая секретность

Стоит иметь в виду следующее: если вы хотите, чтобы какая-то сетевая служба при подключении по сети спрашивала логин и пароль (пользовалась учетной записью), то вам необходимо убедиться, что она шифрует данные при передаче по сети и что это шифрование достаточно стойкое. Надо, чтобы передачу никому нельзя был расшифровать --- никому, кроме вас. В новом man iptables содержится сводная таблица сервисов, которые не отличаются надежностью в плане безопасности (ftp, telnet, http, ipmap, pop передают идентификационные данные в незашифрованном виде, basic_auth передаёт ключи в незашифрованном виде, а потом шифрует такими ключами). От некоторых из этих служб следует вообще отказаться, например, от telnet и от ftp с авторизацией. Есть замечательная утилита dsniff, в man'е которой в секции description перечислены протоколы, из которых она способна "выудить" пароли.

К сожалению, в ALT Linux не применяются одноразовые пароли, и поэтому мы не станем о них рассказывать.

Поэтому стоит рассмотреть возможности, позволяющие зашифровать сам трафик. Если внутри протокола не предусмотрено шифрование, то можно попробовать зашифровать передачу --- организовать секретный канал и передавать пароли в чистом виде. Это разумное решение при условии, что канал надёжен. В этом случае стоило бы обратить внимание на ipsec, который замечательно реализован в ipv4, но он не работает "из коробки", и комплекс мер по его включению и настройке достаточно сложный, и если совершить какие-нибудь ошибки, то он либо не заработает, либо секретность не будет обеспечена.

Из протоколов важно рассказать про SSL. SSL --- secure socket layer --- это некая прослойка между прикладным и транспортным уровнями сети. Есть некий аналог с уровнем представления ISO/OSI. В понятиях уровня TCP, на вход подается шифрователь, на выход --- дешифрователь, при этом используемый нами канал надежно зашифрован. У данного слоя есть выход на прикладной уровень, чтобы приложение знало, что оно использует SSL. Собственно, это связано с тем, что мы здесь не используем ISO/OSI, и поэтому у нас есть https на 443 порту вместо http на 80, и так далее. С помощью утилиты stunnel можно сделать любое "обычное" соединение поверх SSL, в частности, http, imap, pop3, xmpp могут работать поверх него.

приложение ---> || SLL |||| TCP и тд. ||--->Internet--->|| TCP и тд. |||| SLL ||---> приложение

Главное достоинство работы через ssl --- прозрачность со стороны прикладного протокола. После запуска stunnel приложение, работающее с каналом, "не заметит разницы" в своих действиях. Главный недостаток --- как только эта схема перестаёт работать (как в случае ftp), то сразу возникают проблемы - во-первых, приложение должно знать, что есть специальный порт, по которому надо слушать (нестандартный), и, во-вторых, внутри прикладного протокола нет специальных способов управления аутентификацией. За все это отвечает уровень SSL, и приложению придется организовать его самому в отсутствие stunnel. Есть другой способ, TLS, не являющийся промежуточным --- это модификация прикладного уровня. Соответственно, на прикладном уровне у его возможности гораздо шире, чем у SSL. Например, с SSL нельзя выдать разным сайтам на одном адресе выдать разные ключи. Поскольку на уровне SSL никто о разных именах не знает, то у этих хостов один и тот же ip и ключ. В TLS это вынесено на уровень приложения, то есть приложение решает, как шифровать и каким ключом. И, в отличие от SSL, когда протокол прикладного уровня не знает о его наличии, протоколам, поддерживающим TLS, известно, работает ли он в данный момент или нет.

К примеру, в протоколе imap есть расширение, позволяющее включить TLS как команду самого протокола. С точки зрения приложения TLS --- часть прикладного протокола, команда уровня imap. Так же дела обстоят и в случае с pop3, ftp и xmpp. Главный недостаток TLS --- необходимость модификации протокола прикладного уровня. Но зато с его помощью можно защитить использование ftp.

Подводя итог, можно сказать, что SSL --- это универсальное туннелирование, а TLS --- метод модификации протокола уровня приложения.

=Устройство шифрования передачи= Для того, чтобы организовать данный метод шифрования, используется так называемое асимметричное шифрование. При так называемом симметричном шифровании для расшифровки используется тот же ключ, что и для шифровки, а для используемого нами асимметричного шифрования используются два ключа --- открытый и закрытый. С помощью любого из них можно расшифровать, то что зашифровано с помощью другого ключа. Для того, чтобы кто-то мог расшифровать данные, необходимо передать ему открытый ключ, и он будет знать, что зашифровали их именно вы (если, конечно, ваш закрытый ключ надежно скрыт). Данный способ называется электронной подписью. Шифровка открытым ключом расшифровывается только с помощью закрытого --- это уже настоящее шифрование самих данных. Главное достоинство асимметричного шифрования


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

  • компьютер Алисы

    компьютер Эвы (злоумышленник)

    1. открытый ключ Боба

    компьютер Боба

    2. открытый ключ Эвы (выданный за ключ Боба)

    3. данные зашифрованные ключом Эвы

    4. теже данные зашифрованные ключом Боба

Есть два варианта: вы должны действительно убедиться в том, что ключ действительно тот самый.

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

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

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


Сведения о ресурсах

Готовность (%)

Продолжительность (ак. ч.)

Подготовка (календ. ч.)

Полный текст (раб. д.)

Предварительные знания

Level

Maintainer

Start date

End date

40

1

1

1

1

SergeyKorobkov, GeorgeTarasov, VsevolodKrishchenko


CategoryLectures CategoryPspo CategoryMpgu CategoryUneex

PspoClasses/080729/04NetworkSecurity (последним исправлял пользователь VsevolodKrishchenko 2008-10-04 11:13:07)