IPSec для локального трафіку: основні міркування?

Це продовження мого шифрування абсолютно всього ... питання.

Важливо : мова йде не про звичайніші налаштування IPSec, де потрібно зашифрувати трафік між двома локальними мережами.

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

• Чи є хороша міжплатформна підтримка? Він повинен працювати на Linux, MacOS X та клієнтах Windows, серверах Linux, і він не повинен вимагати дорогого мережевого обладнання.

• Чи можу я ввімкнути IPSec для всієї машини (щоб не було іншого трафіку, що надходить / виходить), або для мережевого інтерфейсу, або це визначається настройками брандмауера для окремих портів / ...?

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

• Для внутрішнього трафіку LAN: я вибрав би "ESP з аутентифікацією (без AH)", AES-256, в "Транспортному режимі". Це розумне рішення?

• Для LAN-Інтернет-трафіку: як би це працювало з Інтернет-шлюзом? Чи б я користувався

  • "Тунельний режим" для створення тунелю IPSec від кожної машини до шлюзу? Або я можу також використовувати
  • "Транспортний режим" до шлюзу? Причина, яку я запитую, полягає в тому, що шлюз повинен був би мати можливість розшифровувати пакети, що надходять з локальної мережі, тому для цього знадобляться ключі. Це можливо, якщо адреса призначення не є адресою шлюзу? Або я мав би використовувати проксі в цьому випадку?

• Чи є ще щось, що я повинен розглянути?

Мені дуже просто потрібен короткий огляд цих речей, не дуже детальні інструкції.

• Чи є хороша міжплатформна підтримка? Він повинен працювати на Linux, MacOS X та клієнтах Windows, серверах Linux, і він не повинен вимагати дорогого мережевого обладнання.

Я не маю великого досвіду з цим, оскільки в основному у мене є системи Linux, але я в основному працював на машині Windows 2000 (це було певний час тому). У мене виникла проблема, що IPsec не зміг повторно узгодити новий ключ сеансу після того, як була передана деяка кількість байтів (це повинно відбуватися автоматично), тому з’єднання через деякий час перервалося, і я ніколи не можу потурбуватися копатися в ньому далі. Напевно, це працює набагато краще сьогодні.

• Чи можу я ввімкнути IPSec для всієї машини (щоб не було іншого трафіку, що надходить / виходить), або для мережевого інтерфейсу, або це визначається настройками брандмауера для окремих портів / ...?

Як це працює (а точніше, як мені вдалося змусити його працювати), ви визначаєте, що машина foo повинна використовувати тільки IPsec для машин bar , baz та yow . Будь-який трафік з цих машин і до них тепер безпечний і наділений таким же надійним, як і ці машини. Будь-який інший трафік не є IPsec і працює нормально.

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

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

• Для внутрішнього трафіку LAN: я вибрав би "ESP з аутентифікацією (без AH)", AES-256, в "Транспортному режимі". Це розумне рішення?

Так. Говорять про те, щоб повністю залишити AH, оскільки це зайве - ви можете використовувати ESP з шифруванням NULL з тим же ефектом.

• Для LAN-Інтернет-трафіку: як би це працювало з Інтернет-шлюзом? Чи б я користувався
  • "Тунельний режим" для створення тунелю IPSec від кожної машини до шлюзу? Або я можу також використовувати

Я вибрав би такий варіант. Оскільки я не контролюю сам шлюз, і трафік все одно буде незашифрований за межами моєї мережі, тому я не відчуваю нагальної потреби.

Інтернет-трафік для хостів, який не використовує IPsec, слід сприймати як перехоплений - мало сенсу шифрувати в локальній локальній мережі, коли ваш Інтернет-провайдер або провайдер Інтернет-провайдера можуть слухати ті самі пакети в незашифрованому вигляді.

• "Транспортний режим" до шлюзу? Причина, яку я запитую, полягає в тому, що шлюз повинен був би мати можливість розшифровувати пакети, що надходять з локальної мережі, тому для цього знадобляться ключі. Це можливо, якщо адреса призначення не є адресою шлюзу? Або я мав би використовувати проксі в цьому випадку?

Як я розумію, це не працює - вам знадобиться проксі.

• Чи є ще щось, що я повинен розглянути?

Перевірте, чи можете ви використовувати щось таке розумне, як ключі OpenPGP замість сертифікатів X.509. Я використовую X.509, оскільки це було єдине, що підтримується демоном клавішного IPsec, який я вперше використав, і у мене не було сил розглянути все, щоб переробити це все. Але я повинен, і я стану, коли-небудь.

PS Я та його співробітник провели лекцію про IPsec у 2007 році, можливо, це допоможе з’ясувати деякі поняття.

Це звучить трохи як надмірність. Я не можу сказати, що я чув, щоб хтось шифрував увесь трафік у своїй локальній мережі. Яка мотивація водіння для цього?

IPSec чудово підходить для підключення до ненадійних мереж (тобто веб-DMZs тощо), а також всередині і мереж, відокремлених між брандмауерами. Програми, які використовують протоколи RPC (наприклад, Microsoft AD тощо), люблять використовувати високі діапазони ефемерних портів, які не з'єднуються між брандмауерами. У межах локальної мережі ваші переваги залежать від ряду факторів.

Це не срібна куля, і це не обов’язково спрощує мережеву безпеку. Це допоможе вам керувати послугами в Інтернеті чи інших ненадійних мережах, не вкладаючи величезних вкладень у мережеве обладнання.

Якщо ви робите це як вправу чи досвід навчання, це добре, але нічого, що ви розмістили до цього моменту, не є переконливим аргументом робити те, про що ви говорите.