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

Стоит иметь в виду следующее: если вы хотите, чтобы какая-то сетевая служба при подключении по сети спрашивала логин и пароль (пользовалась учетной записью), то вам необходимо убедиться, что она шифрует данные при передаче по сети и что это шифрование достаточно стойкое. Надо, чтобы передачу никому нельзя был расшифровать --- никому, кроме вас. В новом 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. Собственно, это связано с тем, что у нас не исо/оси, и поэтому у нас есть https на 443 порту вместо http на 80 и так далее. С помощью утилиты stunnel можно сделать любое обычное соединение поверх SSL. Много протоколов, в частности , 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 есть расширение: начать TLS, это команда протокола imap. С точки зрения приложения TLS --- часть прикладного протокола. Это команда уровня imap. Тоже относится к pop3, ftp и тому же xmpp. Главный недостаток TLS --- мы должны модифицировать протокол прикладного уровня. Зато с помощью TLS можно организовать ftp.

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

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


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

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

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

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

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


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

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

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

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

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

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

Level

Maintainer

Start date

End date

40

1

1

1

1

SergeyKorobkov, GeorgeTarasov, VsevolodKrishchenko


CategoryLectures CategoryPspo CategoryMpgu CategoryUneex