Differences between revisions 6 and 7
Revision 6 as of 2008-08-01 13:40:43
Size: 12395
Comment:
Revision 7 as of 2008-08-01 13:58:16
Size: 12784
Comment:
Deletions are marked like this. Additions are marked like this.
Line 5: Line 5:
К сожалению, лектр не будет расск. пр одноразовые пароли, поскольку недовнедрил их в альте. К сожалению, в ALT Linux не применяются одноразовые пароли, и поэтому рассказа о них не будет.
Line 7: Line 7:
Поэтому лектор перейдёт к взм. зашифрвать сам раффик. Если внутри протокола не предусм. шифрование, то попр. зашифр. передачу --- орг. секретный канал и гонять пароли в чистм виде. Разумное решение при усл, чт канал надёжен. Какие есть варианты в этм еле. К сожалению, лектор не очень знает ipv6, иначе бы он сослался бы на ipsec. он замечательно реализован в ipv4, но он не совсем изкоробоный, и кмплекс мер дост. сложный, и если сделать пару ошибок, то оно либ не заработает, лмбо секреты утекут. Поэтому лектор перейдёт к возможности зашифровать сам трафик. Если внутри протокола не предусмотрено шифрование, то можно попробовать зашифровать передачу --- организовать секретный канал и гонять пароли в чистом виде. Разумное решение при условии, что канал надёжен. Какие есть варианты в этом случае. К сожалению, лектор не очень знает ipv6, иначе бы он сослался бы на ipsec. Он замечательно реализован в ipv4, но он не работает совсем из коробки, и комплекс мер по его включению и настройке достаточно сложный, и если сделать пару ошибок, то оно либо не заработает, либо секреты утекут.
Line 9: Line 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, это некая прослойка между паролем прикладным и транспортым (SSL). Есть некий аналог с уровнем представления ISO/OSI . Когда мы дошли до уровня TCP, на вход вставляется шифрователь, на выход --- дешифрватель. Мы закладываем в надёжный и зашифрованный канал. У этой штуки есть ручки на уровне прикладного протокола, что приложение знало, что оно использует SSL. Собственно, это связано с тем, что у нас не исо/оси, и поэтому у нас есть https на 443 порту вместо http на 80 и так далее. С помощью утилиты stunnel можно сделать любое обычное соединение поверх SSL. Когда the bat не умел ssl, была методичка, как организовать его через stunnel ... . Много протоколов, в частности , http, imap, pop3, xmpp могут работать поверх SLL.

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

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

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

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

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

Поэтому будет рассмотрим SSL. SSl --- secure socket layer, это некая прослойка между паролем прикладным и транспортым (SSL). Есть некий аналог с уровнем представления ISO/OSI . Когда мы дошли до уровня TCP, на вход вставляется шифрователь, на выход --- дешифрватель. Мы закладываем в надёжный и зашифрованный канал. У этой штуки есть ручки на уровне прикладного протокола, что приложение знало, что оно использует SSL. Собственно, это связано с тем, что у нас не исо/оси, и поэтому у нас есть https на 443 порту вместо http на 80 и так далее. С помощью утилиты stunnel можно сделать любое обычное соединение поверх SSL. Когда the bat не умел ssl, была методичка, как организовать его через stunnel ... . Много протоколов, в частности , http, imap, pop3, xmpp могут работать поверх SLL.

приложение


> || SLL || TCP и тд. ||


>Internet


>|| TCP и тд. || SLL ||


> приложение

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

В том же протоколе imap есть раширение start tls, это команда протокола imap. С точки зрения прилож. tls --- часть прикл. протокола. Это команда уровня imap. Тоже отн. к pop3, ftp и тому же жабберу. Глвный нед. tls --- мы должны модиф. протокол прикл. уровня. Зат с помощью tls можно орг. ftp.

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

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


вероятность утечки закрытого ключа довольно низкая, так как этот ключ нигде не фигурирует в акте передачи.

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

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

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

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

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

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

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

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

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

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

  • Если хотите подписать ключ, то надо заплатить деньги

* Существуют технологии, достаточно простые, которые ровно этим и занимаются --- подключают корневой сертификат, с помощью которого подписаны на всё остальные

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

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


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

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

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

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

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

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

Level

Maintainer

Start date

End date

0

1

1

1

1

SergeyKorobkov, GeorgeTarasov, VsevolodKrishchenko


CategoryLectures CategoryPspo CategoryMpgu CategoryUneex

PspoClasses/080729/04NetworkSecurity (last edited 2008-10-04 08:13:07 by VsevolodKrishchenko)