Differences between revisions 21 and 22
Revision 21 as of 2008-08-14 19:26:20
Size: 14085
Comment:
Revision 22 as of 2008-08-14 19:41:24
Size: 14632
Comment:
Deletions are marked like this. Additions are marked like this.
Line 3: Line 3:
Многочисленные сетевые службы используют идентификацию пользователя по имени (логину) и паролю. Многочисленные сетевые службы используют идентификацию пользователя по имени (логину) и паролю. Однако для того, чтобы пользователь мог передать свой пароль, охранив его в секрете от третьих лиц, следует убедиться, что он шифруется при передаче по сети и что это шифрование достаточно стойкое. Необходимо достичь того, чтобы передачу никому нельзя было расшифровать --- никому, кроме сетевого сервиса, которому этот пароль и высылается. В противном случае ожидать, что где-то на пути от клиента до службы на одном из компьютеров пароль может быть "подcмотрен".
Line 5: Line 5:
Стоит иметь в виду следующее: если вы хотите, чтобы какая-то сетевая служба при подключении по сети спрашивала логин и пароль (пользовалась учетной записью), то вам необходимо убедиться, что она шифрует данные при передаче по сети и что это шифрование достаточно стойкое. Надо, чтобы передачу никому нельзя был расшифровать --- никому, кроме вас. В документации man iptables содержится сводная таблица сервисов, которые не отличаются надежностью в плане безопасности (ftp, telnet, http, ipmap, pop передают идентификационные данные в незашифрованном виде, basic_auth передаёт ключи в незашифрованном виде, а потом шифрует такими ключами). От некоторых из этих служб следует вообще отказаться, например, от telnet и  от ftp с авторизацией. Есть замечательная утилита dsniff, в man'е которой в секции description перечислены протоколы, из которых она способна "выудить" пароли. В документации man iptables содержится сводная таблица сервисов, которые не отличаются надежностью в плане безопасности. К ним относятся ftp, telnet, http, ipmap и pop3 --- все они передают идентификационные данные в незашифрованном виде.
## В оригинале было просто
basic_auth. Я не нашел подтверждания что оно так работает в HTTP.
## Обычная авторизация в протоколе http, называемая basic_auth,
передаёт ключи в незашифрованном виде, а потом шифрует остальные данные этими ключами, что так же небезопасно.
От некоторых из этих небезопасных служб следует вообще отказаться, например, от telnet и от ftp с авторизацией пользователя. Есть замечательная утилита dsniff, в документации к которой ({{{man nsniff}}}) в секции description перечислены протоколы, из которых она способна "выудить" пароли.
Line 13: Line 16:
##приложение ---> || SLL |||| TCP и тд. ||--->Internet--->|| TCP и тд. |||| SLL ||---> приложение
Line 16: Line 18:
Главное достоинство работы через ssl --- прозрачность со стороны прикладного протокола. После запуска stunnel приложение, работающее с каналом, "не заметит разницы" в своих действиях. Главный недостаток --- как только эта схема перестаёт работать (как в случае ftp), то сразу возникают проблемы - во-первых, приложение должно знать, что есть специальный порт, по которому надо слушать (нестандартный), и, во-вторых, внутри прикладного протокола нет специальных способов управления аутентификацией. За все это отвечает уровень SSL, и приложению придется организовать его самому в отсутствие stunnel. Есть другой способ, TLS, не являющийся промежуточным --- это модификация прикладного уровня. Соответственно, на прикладном уровне у его возможности гораздо шире, чем у SSL. Например, с SSL нельзя выдать разным сайтам на одном адресе выдать разные ключи. Поскольку на уровне SSL никто о разных именах не знает, то у этих хостов один и тот же ip и ключ. В TLS это вынесено на уровень приложения, то есть приложение решает, как шифровать и каким ключом. И, в отличие от SSL, когда протокол прикладного уровня не знает о его наличии, протоколам, поддерживающим TLS, известно, работает ли он в данный момент или нет. Главное достоинство работы через SSL --- прозрачность со стороны прикладного протокола. После запуска stunnel приложение, работающее с каналом, "не заметит разницы" в своих действиях. Главный недостаток --- как только эта схема перестаёт работать (как в случае ftp), то сразу возникают проблемы - во-первых, приложение должно знать, что есть специальный порт, по которому надо слушать (нестандартный), и, во-вторых, внутри прикладного протокола нет специальных способов управления аутентификацией. За все это отвечает уровень SSL, и приложению придется организовать его самому в отсутствие stunnel. Есть другой способ, TLS, не являющийся промежуточным --- это модификация прикладного уровня. Соответственно, на прикладном уровне у его возможности гораздо шире, чем у SSL. Например, с SSL нельзя выдать разным сайтам на одном адресе выдать разные ключи. Поскольку на уровне SSL никто о разных именах не знает, то у этих хостов один и тот же ip и ключ. В TLS это вынесено на уровень приложения, то есть приложение решает, как шифровать и каким ключом. И, в отличие от SSL, когда протокол прикладного уровня не знает о его наличии, протоколам, поддерживающим TLS, известно, работает ли он в данный момент или нет.

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

Многочисленные сетевые службы используют идентификацию пользователя по имени (логину) и паролю. Однако для того, чтобы пользователь мог передать свой пароль, охранив его в секрете от третьих лиц, следует убедиться, что он шифруется при передаче по сети и что это шифрование достаточно стойкое. Необходимо достичь того, чтобы передачу никому нельзя было расшифровать --- никому, кроме сетевого сервиса, которому этот пароль и высылается. В противном случае ожидать, что где-то на пути от клиента до службы на одном из компьютеров пароль может быть "подcмотрен".

В документации man iptables содержится сводная таблица сервисов, которые не отличаются надежностью в плане безопасности. К ним относятся ftp, telnet, http, ipmap и pop3 --- все они передают идентификационные данные в незашифрованном виде.

От некоторых из этих небезопасных служб следует вообще отказаться, например, от telnet и от ftp с авторизацией пользователя. Есть замечательная утилита dsniff, в документации к которой (man nsniff) в секции description перечислены протоколы, из которых она способна "выудить" пароли.

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

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

ssl01.png

Главное достоинство работы через 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

50

1

1

1

1

SergeyKorobkov, GeorgeTarasov, VsevolodKrishchenko


CategoryLectures CategoryPspo CategoryMpgu CategoryUneex

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