IPSec для трафика локальной сети: основные соображения?

Это продолжение моего Шифрования абсолютно всего ... вопроса.

Важный : это не о более обычной настройке IPSec, где вы хотите зашифровать трафик между двумя локальными сетями.

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

• Есть ли хорошая кроссплатформенная поддержка? Он должен работать на клиентах Linux, MacOS X и Windows, серверах Linux и не должен требовать дорогостоящего сетевого оборудования.

• Можно ли включить IPSec для всей машины (чтобы не было другого входящего / исходящего трафика) или для сетевого интерфейса, или это определяется настройками брандмауэра для отдельных портов / ...?

• Могу ли я легко забанить не IPSec IP-пакеты? А также трафик IPSec "Мэллори", который подписан каким-то ключом, но не нашим? Моя идеальная концепция - сделать так, чтобы в локальной сети не было такого IP-трафика.

• Для внутреннего трафика локальной сети: я бы выбрал «ESP с аутентификацией (без AH)», AES-256, в «режиме транспорта». Это разумное решение?

• Для LAN-интернет-трафика: как он будет работать с интернет-шлюзом? Буду ли я использовать

  • «Туннельный режим» для создания туннеля IPSec от каждой машины до шлюза? Или я мог бы также использовать
  • «Транспортный режим» до шлюза? Причина, по которой я спрашиваю, заключается в том, что шлюз должен был бы иметь возможность дешифровать пакеты, поступающие из локальной сети, поэтому для этого ему понадобятся ключи. Возможно ли это, если адрес назначения не является адресом шлюза? Или я должен был бы использовать прокси в этом случае?

• Есть ли что-то еще, что я должен рассмотреть?

Мне просто нужен краткий обзор этих вещей, а не очень подробные инструкции.

• Есть ли хорошая кроссплатформенная поддержка? Он должен работать на клиентах Linux, MacOS X и Windows, серверах Linux и не должен требовать дорогостоящего сетевого оборудования.

Я на самом деле не имеют большого опыта работы с этим, как я в основном имеют системы Linux, но я получил это в основном работает на 2000 машины Windows , (это было некоторое время назад). У него была проблема с тем, что IPsec не удалось пересмотреть новый сеансовый ключ после того, как было передано некоторое количество байтов (это должно происходить автоматически), поэтому через некоторое время соединение разорвалось, и я никогда не удосужился покопаться в нем в дальнейшем. Это, вероятно, работает намного лучше в наши дни.

• Можно ли включить IPSec для всей машины (чтобы не было другого входящего / исходящего трафика) или для сетевого интерфейса, или это определяется настройками брандмауэра для отдельных портов / ...?

Как это работает (точнее, как мне удалось заставить его работать), вы определяете, что машина foo должна использовать только IPsec для машин bar , baz и yow . Любой трафик с этих компьютеров и на них теперь защищен и так же надежен, как и эти машины. Любой другой трафик не IPsec и работает нормально.

• Могу ли я легко забанить не IPSec IP-пакеты? А также трафик IPSec "Мэллори", который подписан каким-то ключом, но не нашим? Моя идеальная концепция - сделать так, чтобы в локальной сети не было такого IP-трафика.

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

• Для внутреннего трафика локальной сети: я бы выбрал «ESP с аутентификацией (без AH)», AES-256, в «режиме транспорта». Это разумное решение?

Ага. Говорят о полном отказе от AH, потому что это избыточно - вы можете использовать ESP с NULL-шифрованием с тем же эффектом.

• Для LAN-интернет-трафика: как он будет работать с интернет-шлюзом? Буду ли я использовать
  • «Туннельный режим» для создания туннеля IPSec от каждой машины до шлюза? Или я мог бы также использовать

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

Интернет-трафик к хостам, которые не используют IPsec, должен рассматриваться как возможно перехваченный - нет смысла шифровать в локальной сети, когда ваш провайдер или провайдер вашего провайдера могут прослушивать те же пакеты в незашифрованном виде.

• «Транспортный режим» до шлюза? Причина, по которой я спрашиваю, заключается в том, что шлюз должен был бы иметь возможность дешифровать пакеты, поступающие из локальной сети, поэтому для этого ему понадобятся ключи. Возможно ли это, если адрес назначения не является адресом шлюза? Или я должен был бы использовать прокси в этом случае?

Насколько я понимаю, это не работает - вам нужен прокси.

• Есть ли что-то еще, что я должен рассмотреть?

Посмотрите, можете ли вы использовать что-то разумное, например ключи OpenPGP, вместо сертификатов X.509. Я использую X.509, так как это была единственная вещь, поддерживаемая демоном IPsec keying, который я впервые использовал, и у меня не было сил, чтобы разобраться во всем этом. Но я должен и буду когда-нибудь.

PS Я и его коллега провели лекцию по IPsec в 2007 году, это может помочь прояснить некоторые концепции.

Это звучит как перебор. Я не могу сказать, что когда-либо слышал, чтобы кто-то шифровал весь трафик в своей локальной сети. Какова ваша мотивация вождения для этого?

IPSec отлично подходит для подключения к ненадежным сетям (т. Е. Веб-DMZ и т. Д.), А также к сетям, которые разделены межсетевыми экранами. Приложения, использующие протоколы RPC (например, Microsoft AD и т. Д.), Любят использовать большие эфемерные диапазоны портов, которые не сочетаются с брандмауэрами. В локальной сети ваши преимущества зависят от ряда факторов.

Это не серебряная пуля, и она не обязательно упростит сетевую безопасность. Это поможет вам управлять услугами в Интернете или других ненадежных сетях без огромных инвестиций в сетевое оборудование.

Если вы делаете это как упражнение или учебный опыт, это нормально, но ничто из того, что вы опубликовали до этого момента, не дает веских аргументов в пользу того, о чем вы говорите.