IPSec для трафика локальной сети: основные соображения?
Это продолжение моего Шифрования абсолютно всего... вопроса.
Важный: это не о более обычной настройке IPSec, где вы хотите зашифровать трафик между двумя локальными сетями.
Моя основная цель - зашифровать весь трафик в локальной сети небольшой компании. Одним из решений может быть IPSec. Я только начал изучать IPSec, и прежде чем я решу использовать его и углублюсь в него, я хотел бы получить представление о том, как это может выглядеть.
Есть ли хорошая кроссплатформенная поддержка? Он должен работать на клиентах Linux, MacOS X и Windows, серверах Linux и не должен требовать дорогого сетевого оборудования.
Могу ли я включить IPSec для всей машины (чтобы не было другого входящего / исходящего трафика) или для сетевого интерфейса, или это определяется настройками брандмауэра для отдельных портов /...?
Могу ли я легко забанить не IPSec IP-пакеты? А также трафик IPSec "Мэллори", который подписан каким-то ключом, но не нашим? Моя идеальная концепция - сделать так, чтобы в локальной сети не было такого IP-трафика.
Для внутреннего трафика локальной сети: я бы выбрал "ESP с аутентификацией (без AH)", AES-256, в "режиме транспорта". Это разумное решение?
Для трафика LAN-Internet: как он будет работать с интернет-шлюзом? Буду ли я использовать
- "Туннельный режим" для создания туннеля IPSec от каждой машины до шлюза? Или я мог бы также использовать
- "Транспортный режим" до шлюза? Причина, по которой я спрашиваю, заключается в том, что шлюз должен был бы иметь возможность дешифровать пакеты, поступающие из локальной сети, поэтому для этого ему понадобятся ключи. Возможно ли это, если адрес назначения не является адресом шлюза? Или я должен был бы использовать прокси в этом случае?
Есть ли что-то еще, что я должен рассмотреть?
Мне просто нужен краткий обзор этих вещей, а не очень подробные инструкции.
3 ответа
- Есть ли хорошая кроссплатформенная поддержка? Он должен работать на клиентах Linux, MacOS X и Windows, серверах Linux и не должен требовать дорогого сетевого оборудования.
У меня нет особого опыта в этом, так как у меня в основном есть системы Linux, но я действительно работал с Windows 2000 (это было некоторое время назад). У него была проблема с тем, что IPsec не удалось пересмотреть новый сеансовый ключ после того, как было передано некоторое количество байтов (это должно происходить автоматически), поэтому через некоторое время соединение оборвалось, и я никогда не удосужился покопаться в нем в дальнейшем. Это, вероятно, работает намного лучше в наши дни.
- Могу ли я включить IPSec для всей машины (чтобы не было другого входящего / исходящего трафика) или для сетевого интерфейса, или это определяется настройками брандмауэра для отдельных портов /...?
Как это работает (или, скорее, как мне удалось заставить его работать), вы определяете, что машина foo должна использовать только IPsec для машин bar, baz и yow. Любой трафик с этих компьютеров и на них теперь защищен и так же надежен, как и эти машины. Любой другой трафик не является IPsec и работает нормально.
- Могу ли я легко забанить не IPSec IP-пакеты? А также трафик IPSec "Мэллори", который подписан каким-то ключом, но не нашим? Моя идеальная концепция - сделать так, чтобы в локальной сети не было такого IP-трафика.
Трафик IPsec разрешен только для тех " политик " IPsec, которые вы определяете, поэтому любая случайная машина не может отправлять пакеты IPsec - должна существовать политика IPsec, соответствующая этим пакетам.
- Для внутреннего трафика локальной сети: я бы выбрал "ESP с аутентификацией (без AH)", AES-256, в "режиме транспорта". Это разумное решение?
Ага. Говорят о полном отказе от AH, потому что он избыточен - вы можете использовать ESP с NULL-шифрованием с тем же эффектом.
- Для трафика LAN-Internet: как он будет работать с интернет-шлюзом? Буду ли я использовать
- "Туннельный режим" для создания туннеля IPSec от каждой машины до шлюза? Или я мог бы также использовать
Я бы выбрал этот вариант. Поскольку я сам не контролирую шлюз, и трафик в любом случае будет зашифрован вне моей сети, так что я действительно не вижу насущной необходимости.
Internet traffic to hosts which does not use IPsec must be seen as possibly being intercepted - there's little point in encrypting on the local LAN when your ISP or your ISP's ISP can listen to the same packets unencrypted.
- "Transport mode" to the gateway? The reason I ask is, that the gateway would have to be able to decrypt packages coming from the LAN, so it will need the keys to do that. Is that possible, if the destination address isn't the gateway's address? Or would I have to use a proxy in this case?
As I understand it, that does not work - you would need a proxy.
- Is there anything else I should consider?
See if you can use something sensible like OpenPGP keys instead of X.509 certificates. I use X.509 since that was the only thing supported by the IPsec keying daemon I first used, and I haven't had the energy to look into redoing it all. But I should, and I will, someday.
PS Me and an associate held a lecture on IPsec in 2007, it may be of help to clarify some concepts.
Это звучит как перебор. Я не могу сказать, что когда-либо слышал о том, чтобы кто-то шифровал весь трафик в своей локальной сети. Какова ваша мотивация вождения для этого?
IPSec отлично подходит для подключения к ненадежным сетям (т. Е. Веб-DMZ и т. Д.), А также к сетям, которые разделены межсетевыми экранами. Приложения, использующие протоколы RPC (например, Microsoft AD и т. Д.), Любят использовать большие диапазоны портов, которые не сочетаются с брандмауэрами. В локальной сети ваши преимущества зависят от ряда факторов.
Это не серебряная пуля, и она не обязательно упростит сетевую безопасность. Это поможет вам управлять услугами в Интернете или других ненадежных сетях без огромных инвестиций в сетевое оборудование.
Если вы делаете это как упражнение или учебный опыт, это нормально, но ничто из того, что вы опубликовали до этого момента, не дает веских аргументов в пользу того, о чем вы говорите.