Шифрование абсолютно всего, даже внутри локальной сети
Кто-нибудь уже пробовал такой подход? Я действительно рассматриваю это: вместо того, чтобы полагаться на IDS на основе сети и т. Д., Каждый пакет должен использовать шифрование, которое было инициировано сертификатом, выданным моим собственным CA.
- Каждый клиент получает уникальный сертификат клиента
- Каждый сервер получает уникальный сертификат сервера
- Каждый сервис дополнительно требует авторизации.
И SSL и SSH будет в порядке. Доступ в Интернет будет осуществляться через SSL-туннель к шлюзу.
Это возможно? Создает ли это практические проблемы? Как это можно сделать и обеспечить? Как вы думаете?
Подробнее
Моя цель - упростить концепцию безопасности локальной сети - я пока не уверен, что это безумная идея! Но я чувствую, что защитить сервер HTTPS или SSH от интернет-угроз (если используется взаимная аутентификация) иногда проще, чем отслеживать все, что может случиться в диком мире локальной сети.
В незашифрованной локальной сети я чувствую, что действительно трудно быть на шаг впереди потенциального злоумышленника из-за таких угроз, как:
- Низкоуровневые атаки, такие как подмена ARP, кража портов, ...
- Доступ к WLAN (например, каждому разработчику будет разрешен доступ к серверу SVN из (W)LAN - я не думаю, что это будет через VPN...)
=> Для простоты не проще ли сделать предположение, что в локальной сети всегда есть злоумышленник?
=> Могу ли я в конечном итоге упростить концепцию безопасности локальной сети (небольшой компании), рассматривая ее как глобальную сеть? Или я бы скорее усложнил это?
IPSec и альтернативы
IPSec звучит очень многообещающе, но я бы также заинтересовался альтернативами IPSec - индивидуальным использованием SSL/SSH для каждой службы и созданием Stunnel для шлюза? Может быть, вы используете Kerberos?... Каковы преимущества IPSec или других?
Если вы можете помочь мне лучше понять IPSec, пожалуйста, посмотрите мой дополнительный вопрос, посвященный IPSec.
6 ответов
Я использую IPsec здесь для всего. Причина в том, что большинство атак в любом случае совершаются инсайдерами - мышление плохой стороны / хорошей стороны ошибочно. (Если кто-то убежит с серверами, он может повеселиться, пытаясь сломать полное шифрование диска, так что проблем тоже нет.)
Также забавно использовать telnet, NIS, NFS и FTP без каких-либо забот - похоже на старые добрые времена!:-)
IPSec является стандартом для этого. Это происходит в разных формах, и в нем много слов.
Я рекомендую это руководство для IPSec, чтобы вы начали.
У вас есть модель угроз, когда ожидается беспрепятственный доступ к вашей локальной сети? Если это так, то да, развертывание IPSEC на всех конечных точках, вероятно, то, что вам нужно.
Тем не менее, в большинстве моделей угроз достаточно защиты периметра, так что вы можете игнорировать инфраструктуру локальной сети как дешевый метод доступа.
Картина изменится, если у вас установлен WiFi, вам понадобится что-то между сетями WiFi и проводными сетями, чтобы гарантировать отсутствие утечки информации по этому маршруту.
Что касается окон, то вы ищете изоляцию домена и сервера. Вы можете играть с ним, используя этот labcast
Мой план реализации окон по умолчанию для новой установки включает это. В Windows нетрудно настроить и предлагает много дополнительной безопасности (и в действительности нет никакого "дополнительного" администрирования, вам может понадобиться еще несколько групп безопасности).
NAP не требует IPsec (или даже PKI - это только если вы хотите запустить собственный режим). SCCM - это дополнительный продукт - для изоляции домена и сервера ничего не требуется. NAP в первую очередь предназначен для отправки "работоспособной" информации о клиенте, и если этот клиент не проходит проверку "работоспособности", он откладывается только для связи с серверами исправления. Работоспособность определяется как требования к исправлениям: настройки AV, настройки безопасности и т. Д. Конечно, вы можете использовать SCCM для настройки IPSEC, но это не является обязательным требованием.
С изоляцией домена и сервера у меня нет возможности проверить это "здоровье"- и это не главное. Когда он настроен, я шифрую трафик и дополнительно гарантирую, что серверам и клиентам разрешено общаться только с серверами и клиентами, необходимыми для этой бизнес-функции (например, рабочие станции HR являются единственными рабочими станциями, которым разрешено взаимодействовать с сервером HR).).
Термин безопасности - "защита данных в пути". Да, есть группы, которые делают это, и да, в некотором смысле это упрощает безопасность локальной сети. IPSEC и IPv6 могут быть использованы для поддержки этого.
Дополнительным понятием является "защита данных в покое", что означает шифрование ваших дисков.
Не знаю, какие системы и инфраструктуру вы используете, но Microsoft System Center Config Manager (SCCM) имеет компонент защиты доступа к сети (NAP), который делает именно то, что вам нужно.
Он PKI шифрует весь трафик клиент-сервер и помещает неаутентифицированные машины в то, что фактически является DMZ, где они не могут общаться с любым сервером / машиной / системой, которые специально не настроены для работы в этой DMZ. Он также может позволить предварительно проверить уровень исправлений компьютеров, настройки антивируса, безопасности и т. Д., Прежде чем разрешить их в основную локальную сеть (очевидно, в этом случае у вас будет один или два сервера обновлений в DMZ).
Пошаговые инструкции по настройке для демонстрации / тестирования здесь.