Назад | Перейти на главную страницу

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • Что еще мне следует рассмотреть?

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

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

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

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

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

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