Differences between revisions 1 and 2
Revision 1 as of 2008-07-30 05:13:53
Size: 10095
Editor: eSyr
Comment:
Revision 2 as of 2008-08-01 11:44:45
Size: 10179
Comment:
Deletions are marked like this. Additions are marked like this.
Line 3: Line 3:
Надо иметь две вещи в виду. Вещь первая: если вы хотите, чтобы какая-то сетевая служба при подкл. по сети спрашивала логин и парль (польз. уч. записью), то убедитесь, что он шифрует данные при передаче по сети. Какое был нарекание на mit magic cookie --- оно было недост. стйким. Надо, чтобы передачу никому нельзя был расшифрвать никому, крме вас. В новом мане по iptables, есть сводная табличка сервисов, которые уязвимы в этом смысле (ftp, telnet, http, ipmap, pop передают credentials в незашифр. виде, basic_auth передаёт ключи в незашифр. виде). От некоторых из этих служб следует тказываться. От телнета тказались совсем. От ftp пльз. лектор радеет, чтобы все отказались. Отказались от авториз. ftp. Есть замечательная утилита dsnif (?), лектор призывает почитать секцию description мана, там перечислены протоколы, из которых она выуживает пароли. Надо иметь две вещи в виду. Вещь первая: если вы хотите, чтобы какая-то сетевая служба при подклении по сети спрашивала логин и парль (пользовалась учетной записью), то убедитесь, что она шифрует данные при передаче по сети. Какое был нарекание на mit magic cookie --- оно было недостаточно шифростойким. Надо, чтобы передачу никому нельзя был расшифрвать никому, крме вас. В новом мане по iptables, есть сводная табличка сервисов, которые уязвимы в этом смысле (ftp, telnet, http, ipmap, pop передают credentials в незашифрованном виде, basic_auth передаёт ключи в незашифрованном виде). От некоторых из этих служб следует отказываться. От телнета отказались совсем. От ftp пльз. лектор радеет, чтобы все отказались. Отказались от авториз. ftp. Есть замечательная утилита dsnif (?), лектор призывает почитать секцию description мана, там перечислены протоколы, из которых она выуживает пароли.

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

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

К сжалению, лектр не будет расск. пр дноразовые пароли, поск. недовнедрил их в альте.

Поэтому лектор перейдёт к взм. зашифрвать сам раффик. Если внутри протокола не предусм. шифрование, то попр. зашифр. передачу --- орг. секретный канал и гонять пароли в чистм виде. Разумное решение при усл, чт канал надёжен. Какие есть варианты в этм еле. К сожалению, лектор не очень знает 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 могут работать поверх ssl/

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

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

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

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


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

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

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

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

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

Допустим, нет человека в середине. Тогда вы дст. неплохо гаранитрованы, что трафик защищён.


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

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

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

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

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

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

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)