Linux Advanced Routing & Traffic Control HOWTO
Шрифт:
Другими словами, Политика Безопасности описывает ЧТО следует предпринять в том или ином случае, а защищенный канал (SA) – КАК получить данные.
Исходящие пакеты "подписываются" соответствующим SPI (КАК). Ядро использует его для нужд шифрования и аутентификации так, чтобы удаленный хост мог выполнить необходимые проверки и дешифрацию.
Ниже следует пример простой конфигурации, обеспечивающей передачу данных от 10.0.0.216 к 10.0.0.11 с аутентификацией, в зашифрованном виде. Обратите внимание на то, что в обратном направлении данные передаются в открытом виде. Это лишь первая версия примера и она не должна рассматриваться
Для хоста 10.0.0.216:
Для хоста 10.0.0.11, те же самые SA, но без политики безопасности:
В этой конфигурации попробуем дать команду ping 10.0.0.11 с хоста 10.0.0.216. В результате получим такой вывод от tcpdump:
Обратите внимание на то, как возвращается ответ на запрос – он передается в открытом виде. В то время как сам запрос не распознается утилитой tcpdump, но зато она показывает SPI для AH и ESP, которые инструктируют хост 10.0.0.11, КАК выполнить проверку подлинности и дешифровать данные.
Следует сделать несколько замечаний по поводу этих примеров. Такая конфигурация не обеспечивает достаточный уровень безопасности. Проблема состоит в том, что политика безопасности описывает только — ЧТО должен сделать хост 10.0.0.216 при передаче данных хосту 10.0.0.11 и КАК их передать, а для хоста 10.0.0.11 описывается КАК он может получить эти данные, но нет правил, описывающих ЧТО он должен предпринять при получении нешифрованных пакетов, идущих от 10.0.0.216!
Таким образом, если злоумышленник будет в состоянии выполнить "подмену" (spoofing) IP-адреса, то он сможет отправлять незашифрованные данные хосту 10.0.0.11, который примет их! Для устранения этой проблемы нужно прописать политику безопасности для хоста 10.0.0.11:
Это описание сообщает хосту 10.0.0.11, что весь входящий трафик от хоста 10.0.0.216 должен иметь подтверждение подлинности (AH) и должен быть зашифрован (ESP).
Ниже приводится полная конфигурация сетевых узлов 10.0.0.11 и 10.0.0.216, для двустороннего обмена данными. Полная конфигурация для хоста 10.0.0.216:
И
Обратите внимание — в этом примере использованы идентичные ключи шифрования для обоих направлений. Однако, это не является обязательным требованием.
Чтобы проверить только что созданную конфигурацию, достаточно дать команду setkey –D, которая выведет перечень контекстов защиты (виртуальных защищенных каналов) или setkey –DP, которая отобразит сконфигурированные политики безопасности.
7.2. Пример автоматического конфигурирования безопасного соединения между двумя хостами.
В предыдущем разделе, шифрование было сконфигурировано с применением простых ключей. По идее, чтобы обеспечить необходимый уровень безопасности, мы должны бы передавать сведения о конфигурации по надежным каналам. Если бы нам пришлось настраивать удаленный хост через telnet, то любое третье лицо запросто могло бы получить секретные сведения, и такая конфигурация будет далеко не безопасна.