Comments 98
«Сам дизайн аутентификации WPA2-Enterprise это предмет отдельной статьи.» — надеюсь, она скоро выйдет? Тема очень интересная.
Поддерживаю. Очень интересно было бы почитать.
На самом деле именно с WPA2-Enterprise всё просто, 90% занимает планирование и настройка CA для раздачи сертификатов.
Автор, IMHO, намекает, что там такое же непаханное поле для ИБ, как и в других областях.
Планирование и настройка CA? Все что введено в домен, все уже с сертификатом и делать ничего не надо. А вот с принтерами и прочим, не поддерживающим 802.1x точно придётся что то делать. И если возникнет желание (а оно возникнет)
Для принтеров лучше всего выделить отдельный vlan, из которого запретить любой доступ.
Доступ в vlan принтеров открыть только принт-серверу, по нужным портам.
На портах принтеров включить port-security с оповещением мониторинг-системы по SNMP в случае блокировки порта.
В таком случае можно не заморачиваться с настройкой 802.1x на принтерах.
Доступ в vlan принтеров открыть только принт-серверу, по нужным портам.
На портах принтеров включить port-security с оповещением мониторинг-системы по SNMP в случае блокировки порта.
В таком случае можно не заморачиваться с настройкой 802.1x на принтерах.
Планирование и настройка CA — самая вершина айсберга. Гораздо больше времени потратится на решение вопросов с принтерами и теми кто так же не поддерживает 802.1x. Потом появится желание аутентифицировать не только рабочее место (это самое простое — ввели машину в домен, она тут же получила сертификат и прекрасно им аутентифицируется), но и пользователя. А заодно, в зависимости от того что за пользователь, совать его в тот или иной VLAN, а потребует пересмотр сетевой архитектуры. Потом найдется что нибудь все еще живущее под XP ( хотя сейчас уже проще с ним).
Но в любом случае не стоит преувеличивать — внедрение 802.1x не так страшно если не полениться и выпустить проект на внедрение, в начале которого просто перечислить все подключенное, а в теле по каждому типу прописать что делаем(впрочем это касается любого внедрения).
Но в любом случае не стоит преувеличивать — внедрение 802.1x не так страшно если не полениться и выпустить проект на внедрение, в начале которого просто перечислить все подключенное, а в теле по каждому типу прописать что делаем(впрочем это касается любого внедрения).
Осталось выяснить причем тут 802.1x с принтерами, если разговор был в контексте беспроводной сети.
Ну хотя бы потому что в статье автора речь про 802.1x идет в разделе «Противодействие «левым» устройствам» где обсуждается вопрос о мерах защиты в проводной сети.
Вот только первый комментарий в ветке про другой раздел :-)
А для 802.1x есть готовые решения, вроде Cisco ISE, но для их внедрения надо знать не меньше, чем для правильного ЦС на базе AD CS (см. комментарии).
А для 802.1x есть готовые решения, вроде Cisco ISE, но для их внедрения надо знать не меньше, чем для правильного ЦС на базе AD CS (см. комментарии).
WPA2-Enterprise одинаково применимо :-) ибо что в WiFi, что в лане один и тот же 802.1x. На заре XP приходилось на десктоп ставить Atherosовские WiFi дрова чтоб на лане появилась возможность включить 802.1x.
Что касается решений «из коробки» для аутентификации рабочих мест прекрасно работает связка MS AD + Radius + коммутатор с поддержкой 802.1x никаких «танцев с бубном» не нужно. Подняли Radius, натравили его на AD, на Radius натравили коммутатор, на рабочем месте подняли 802.1x. Если рабочее место в домене его авторизуют, нету в доме, нет авторизации. Впрочем тоже самое относится и к юзерам. Дополнительно можно присылать VLAN ID и коммутатор будет совать порт в соответствующий VLAN, но он должен быть на коммутаторе, должен быть в транке, его надо маршрутизировать. У XP была проблема связанная с тем что сначала авторизуется рабочее место, его суют в один VLAN там он получает адрес, потом приходит юзер, логингится, его перекладывают в другой VLAN и XP «забывало» еще раз получить адрес, уже в новом VLAN. Со второго (может быть и уже и с первого сервиспака проблема пофиксена).
Ну а дальше, как я уже говорил, начинается решение проблем с принтерами и прочим без поддержки 802.1x. Можно всех скопом засунуть в один Guest VLAN, как неавторизовавшихся (не очень секьюрно и есть проблемы), можно «взводить» на портах, куда оно подключено, MAC Security, но тогда при замене принтера надо еще и сетевой отдел беспокоить. В общем есть место для творчества :-)
Что касается решений «из коробки» для аутентификации рабочих мест прекрасно работает связка MS AD + Radius + коммутатор с поддержкой 802.1x никаких «танцев с бубном» не нужно. Подняли Radius, натравили его на AD, на Radius натравили коммутатор, на рабочем месте подняли 802.1x. Если рабочее место в домене его авторизуют, нету в доме, нет авторизации. Впрочем тоже самое относится и к юзерам. Дополнительно можно присылать VLAN ID и коммутатор будет совать порт в соответствующий VLAN, но он должен быть на коммутаторе, должен быть в транке, его надо маршрутизировать. У XP была проблема связанная с тем что сначала авторизуется рабочее место, его суют в один VLAN там он получает адрес, потом приходит юзер, логингится, его перекладывают в другой VLAN и XP «забывало» еще раз получить адрес, уже в новом VLAN. Со второго (может быть и уже и с первого сервиспака проблема пофиксена).
Ну а дальше, как я уже говорил, начинается решение проблем с принтерами и прочим без поддержки 802.1x. Можно всех скопом засунуть в один Guest VLAN, как неавторизовавшихся (не очень секьюрно и есть проблемы), можно «взводить» на портах, куда оно подключено, MAC Security, но тогда при замене принтера надо еще и сетевой отдел беспокоить. В общем есть место для творчества :-)
Я подумал вы про более глобальное, чтобы вести пользователя от подключения к порту до выхода в интернет. Не думаете написать статью про набивание шишек с 802.1X?
Ну в Core Network нет уже смысла применять какие либо меры, подразумевается, что порты мониторятся и подключение к ним невозможно в силу того что коммутаторы находятся в защищенном периметре (кроссовая/серверная).
Что касается шишек с 802.1x — я бы не сказал, что их там много, скорее нету вообще. Внимательное изучение документации на коммутаторы конкретного производителя дает ответы абсолютно на все вопросы. Кроме того в 802.1x, по счастью, все косяки без проблем исследуются тем же Wireshark, что обмен между коммутатором и радиусом, что обмен между хостом и коммутатором. Пошаговая инструкция, как правило, гарантия появления головной боли потом, когда рассыпется по той или иной причине и придется собирать назад.
Что касается вокруг лежащего — оно само всплывет в процессе, как те же, упомянутые мной, принтера. Сейчас специально поднял самый первый проект по внедрению аж 2005 года, актуален до сих пор, за исключением разделов про Windows 98/ME. Судя по проекту и по воспоминаниям, с ними шишек на стенде было набито не мало, 2000 и XP SP2, клиент встроенный, аутентификация по сертификатам поддерживается, работает «из коробки».
Что касается шишек с 802.1x — я бы не сказал, что их там много, скорее нету вообще. Внимательное изучение документации на коммутаторы конкретного производителя дает ответы абсолютно на все вопросы. Кроме того в 802.1x, по счастью, все косяки без проблем исследуются тем же Wireshark, что обмен между коммутатором и радиусом, что обмен между хостом и коммутатором. Пошаговая инструкция, как правило, гарантия появления головной боли потом, когда рассыпется по той или иной причине и придется собирать назад.
Что касается вокруг лежащего — оно само всплывет в процессе, как те же, упомянутые мной, принтера. Сейчас специально поднял самый первый проект по внедрению аж 2005 года, актуален до сих пор, за исключением разделов про Windows 98/ME. Судя по проекту и по воспоминаниям, с ними шишек на стенде было набито не мало, 2000 и XP SP2, клиент встроенный, аутентификация по сертификатам поддерживается, работает «из коробки».
Хотелось бы получить совет по двум вопросам, оба относятся к очень маленьким фирмам (менее 10 сотрудников) с одноранговой сетью. В 1 очередь
1) Что лучше и безопаснее использовать для удалённого доступа извне? Использую Litemanager Free, иногда люди сами запускают разово тимвьюер. Интернет на удалённой стороне как правило медленный, vnc через ssh или подобное думаю будет не рабочим вариантом.
2) Что посоветуете для удалённого доступа уже внутри сети? Командной строки достаточно. Я склоняюсь к freesshd (простая настройка, можно ставить батником или надиктовать инструкцию по телефону), но так же рассматриваю powershell (пока не получается по непонятной причине соединяться в нём по https, стандартный kerberos отпадает по причине отсутствия домена).
1) Что лучше и безопаснее использовать для удалённого доступа извне? Использую Litemanager Free, иногда люди сами запускают разово тимвьюер. Интернет на удалённой стороне как правило медленный, vnc через ssh или подобное думаю будет не рабочим вариантом.
2) Что посоветуете для удалённого доступа уже внутри сети? Командной строки достаточно. Я склоняюсь к freesshd (простая настройка, можно ставить батником или надиктовать инструкцию по телефону), но так же рассматриваю powershell (пока не получается по непонятной причине соединяться в нём по https, стандартный kerberos отпадает по причине отсутствия домена).
У меня вопрос по пункту 2.1.
Я бы с радостью использовал -all, но у нас есть крупный клиент, у которого почта управляется провайдером, а у провайдера железки письма пересылают от своего имени на почтовый сервер, и с этим никто из нас не в силах ничего поделать, в итоге приходится использовать ?all (рекомендация админов клиента, как сказали — тогда наши письма будут к ним доходить).
И про ?all в статье не написано — в чём тут минусы со стороны безопасности?
Просто в последнее время на некоторые почтовые ящики (около 5 — самые засвеченные, я так понимаю) приходят письма от них же. То есть, отправляют сами себе письма, как и написано в статье. По заголовку — отправлены с левого хоста. Да, такие письма попадают в спам автоматически, а вложения удаляются антивирусом, но сам факт беспокоит.
Я бы с радостью использовал -all, но у нас есть крупный клиент, у которого почта управляется провайдером, а у провайдера железки письма пересылают от своего имени на почтовый сервер, и с этим никто из нас не в силах ничего поделать, в итоге приходится использовать ?all (рекомендация админов клиента, как сказали — тогда наши письма будут к ним доходить).
И про ?all в статье не написано — в чём тут минусы со стороны безопасности?
Просто в последнее время на некоторые почтовые ящики (около 5 — самые засвеченные, я так понимаю) приходят письма от них же. То есть, отправляют сами себе письма, как и написано в статье. По заголовку — отправлены с левого хоста. Да, такие письма попадают в спам автоматически, а вложения удаляются антивирусом, но сам факт беспокоит.
SPF не особо полезен сам по себе, без DMARC:
https://habrahabr.ru/post/270159/#comment_8643345
https://habrahabr.ru/post/270159/#comment_8644311
https://habrahabr.ru/post/270159/#comment_8643345
https://habrahabr.ru/post/270159/#comment_8644311
Спасибо за ссылки (хотя вроде читал уже эту статью и комментарии к ней), но мой мозг пока так до конца и не въехал, как DMARC грамотно настроить (самостоятельно пытался разобраться, гуглил, но нужно объяснение «на пальцах», для лучшего понимания. Без этого пока не получается вникнуть). Есть у Вас в запасе ссылка, которая может помочь?
И правильно ли я понимаю, что у принимающей стороны должна быть встречная настройка — проверка DMARC?
И правильно ли я понимаю, что у принимающей стороны должна быть встречная настройка — проверка DMARC?
Это да, я имел ввиду тот случай, когда «настраивают» SPF (и DMARC), а фактически там шлак прописан.
?all — это еще хуже, чем ~all. Последнее хоть намекает, что письмо поддельное, а первое «разводит руками». Частичное спасение — проверка подписью DKIM. Частичное потому, что при общей неправильной политике DMARC ваши письма не будут доходить по получателей.
Нужно пересмотреть ваши маршруты почты, и четко определить, кто доверенный, исходя их этого писать DMARC.
Нужно пересмотреть ваши маршруты почты, и четко определить, кто доверенный, исходя их этого писать DMARC.
Для начала я бы хотел разобраться, что такое DMARC. В общих чертах понимаю, а в деталях — уже начинается «не понимаю».
Со своей стороны наши письма подписываются DKIM. Только опять же — это для получателя, он должен корректно обрабатывать и DKIM, и DMARC с SPF. Если я правильно понимаю.
А как избавиться от ?all, но чтобы клиент получал письма, при условии, что изменения возможны только с нашей, отправителя, стороны?
Со своей стороны наши письма подписываются DKIM. Только опять же — это для получателя, он должен корректно обрабатывать и DKIM, и DMARC с SPF. Если я правильно понимаю.
А как избавиться от ?all, но чтобы клиент получал письма, при условии, что изменения возможны только с нашей, отправителя, стороны?
С той стороны изменения тоже возможны, но только они ленятся. Надо продавливать эти изменения, хотябы через клиентов.
Простыми словами DMARC это объединение DKIM и SPF домена. Т.е одновременная их проверка, если не вдаваться в подробности и объяснять языком домохозяйки).
Т.е когда корректно настроили DKIM и SPF, то можно разместить в домене политики DMARC, все протестировать и подкрутить гайки еще, если необходимо.
Т.е когда корректно настроили DKIM и SPF, то можно разместить в домене политики DMARC, все протестировать и подкрутить гайки еще, если необходимо.
Вы не правы: ?all — просто утверждает что ваши пользователи могут быть за пределами вашей сети, он-же обеспечивает нормальную пересылку почты(forward), он-же ограничивает фривольную интерпретацию вашего SPFа у получающей стороны, и т.д. Собственно такие политики — стандартная практика научных/университетских учреждений.
Пара примеров:
# dig txt yale.edu
…
yale.edu. 10800 IN TXT «v=spf1 ip4:130.132.50.0/24 ip4:130.132.232.0/24 include:_spf.google.com include:spf.protection.outlook.com include:_spf.qualtrics.com ~all»
# dig txt princeton.edu
…
princeton.edu. 43200 IN TXT «v=spf1 ip4:128.112.128.212 ip4:128.112.128.213 ip4:128.112.128.214 ip4:128.112.128.215 ip4:128.112.128.216 ip4:140.180.223.12 ip4:140.180.223.155 ip4:140.180.223.156 mx ?all»
Пара примеров:
# dig txt yale.edu
…
yale.edu. 10800 IN TXT «v=spf1 ip4:130.132.50.0/24 ip4:130.132.232.0/24 include:_spf.google.com include:spf.protection.outlook.com include:_spf.qualtrics.com ~all»
# dig txt princeton.edu
…
princeton.edu. 43200 IN TXT «v=spf1 ip4:128.112.128.212 ip4:128.112.128.213 ip4:128.112.128.214 ip4:128.112.128.215 ip4:128.112.128.216 ip4:140.180.223.12 ip4:140.180.223.155 ip4:140.180.223.156 mx ?all»
>?all — просто утверждает что ваши пользователи могут быть за пределами вашей сети
SPF не предназначен для пользователей. Пользователи абсолютно легитимно авторизуются на Mail submission agent через SMTP с авторизацией, либо через веб-клиент из любой локации. SPF предназначен для получателя, чтобы тот смог оценить достоверность писем от вас.
>он-же обеспечивает нормальную пересылку почты(forward)
Тут сложнее. SPF по механизму действия ломает «классический» форвард, но с другой стороны, это в первую очередь проблема кривой настройки сервера-форвардера, а не владельца SPF.
Насчет примеров — намного лучше по некторым вопросам ни на кого не смотреть. Я не говорю, что в Вэльсе или Принстоне кривой SPF. Я имею в виду, что если они так сделали, это их решение, и почему они его приняли, мы не узнаем. Для другой системы подобная настройка может привести к легкому засылу фишинга.
SPF не предназначен для пользователей. Пользователи абсолютно легитимно авторизуются на Mail submission agent через SMTP с авторизацией, либо через веб-клиент из любой локации. SPF предназначен для получателя, чтобы тот смог оценить достоверность писем от вас.
>он-же обеспечивает нормальную пересылку почты(forward)
Тут сложнее. SPF по механизму действия ломает «классический» форвард, но с другой стороны, это в первую очередь проблема кривой настройки сервера-форвардера, а не владельца SPF.
Насчет примеров — намного лучше по некторым вопросам ни на кого не смотреть. Я не говорю, что в Вэльсе или Принстоне кривой SPF. Я имею в виду, что если они так сделали, это их решение, и почему они его приняли, мы не узнаем. Для другой системы подобная настройка может привести к легкому засылу фишинга.
«и почему они его приняли, мы не узнаем»:
Собственно я вам написал почему. У меня / у нас та-же ситуация: научное/университетское учреждение, почтовая система используется практически с момента создания протокола. За десятилетия складываются определенные традиции:
— почта ученых перенаправляется вслед за ними (они публикуют свои адреса в научных статьях)
— выпускники (алюмни) получают пожизненные адреса
и т.д.
Все это в разумных пределах конечно.
Видимо создатели SPF надеялись что весь инернет все переделает. Так обычно не бывает и в конкретном случае для прозрачного перехода требуются гигантские ресурсы при совершенно не очевидном/посредственном результате.
ПС С фишингом борются так-же как с обычным спамом. SPF в этом контексте имеет практически нулевую эффективность.
Собственно я вам написал почему. У меня / у нас та-же ситуация: научное/университетское учреждение, почтовая система используется практически с момента создания протокола. За десятилетия складываются определенные традиции:
— почта ученых перенаправляется вслед за ними (они публикуют свои адреса в научных статьях)
— выпускники (алюмни) получают пожизненные адреса
и т.д.
Все это в разумных пределах конечно.
Видимо создатели SPF надеялись что весь инернет все переделает. Так обычно не бывает и в конкретном случае для прозрачного перехода требуются гигантские ресурсы при совершенно не очевидном/посредственном результате.
ПС С фишингом борются так-же как с обычным спамом. SPF в этом контексте имеет практически нулевую эффективность.
Спасибо за интересную информацию.
Что же поделать, если SMTP и другие почтовые протоколы разрабатывали очень давно, когда все было белое и пушистое, авторизаций не было, спуфингом никто не занимался. Остается только добавлять костыли, которые будут все усложнять.
Добавлю небольшую историю про фейлы SPF. Мои коллеги нашли у одного очень крупного почтового сервиса, который предоставляет услуги типа «почта для вашего домена» интересный баг (передаю привет автору находки randomib). Есть домен с spf, где в конце стоит ~all, остальные настройки говорят сомнительным письмам строго валиться в спам. Так оно и происходит, за исключением одной ситуации. При отправке внутридоменного фишинга на групповой ящик рассылки происходит форвардинг письма сервисом самому себе, SPF приобретает статус pass вместо softfail. Письмо радостно попадает в инбокс как правильное. Производитель сервиса это багом не считает, говорит, сами смотрите заголовки, проверяйте DKIM. А строгий DKIM мало кто может сделать, так как назло найдется что-то, что его не умеет применять.
Но несмотря на это, рядовым компаниям все-таки стоит задуматься насчет SPF, у них наверняка нет пожизненных ящиков и прочих экзотических атрибутов.
Что же поделать, если SMTP и другие почтовые протоколы разрабатывали очень давно, когда все было белое и пушистое, авторизаций не было, спуфингом никто не занимался. Остается только добавлять костыли, которые будут все усложнять.
Добавлю небольшую историю про фейлы SPF. Мои коллеги нашли у одного очень крупного почтового сервиса, который предоставляет услуги типа «почта для вашего домена» интересный баг (передаю привет автору находки randomib). Есть домен с spf, где в конце стоит ~all, остальные настройки говорят сомнительным письмам строго валиться в спам. Так оно и происходит, за исключением одной ситуации. При отправке внутридоменного фишинга на групповой ящик рассылки происходит форвардинг письма сервисом самому себе, SPF приобретает статус pass вместо softfail. Письмо радостно попадает в инбокс как правильное. Производитель сервиса это багом не считает, говорит, сами смотрите заголовки, проверяйте DKIM. А строгий DKIM мало кто может сделать, так как назло найдется что-то, что его не умеет применять.
Но несмотря на это, рядовым компаниям все-таки стоит задуматься насчет SPF, у них наверняка нет пожизненных ящиков и прочих экзотических атрибутов.
«Но несмотря на это, рядовым компаниям все-таки стоит задуматься насчет SPF, у них наверняка нет пожизненных ящиков и прочих экзотических атрибутов. »:
SPF декларировать безусловно нужно хотя-бы потому что SPF используется большинством анти-спам систем и в случае отсутствия SPF записи, зачастую, применяются параметры хуже любой пермисив политики SPF. С дугой стороны я-бы поостерегся советовать не ставить "?all" или "~all": «рядовые компании» тоже пишут письма клиентам/партнерам. Эти письма будут/могут теряться при перенаправлениях возникающих регулярно и оправданно (компании покупают и продают, они сливаются и разделяются, возникают/исчезают филиалы, ребрендеринг и т.д.). Установка систем которые переписывают шапку или перепаковывают письмо — скорее исключение чем правило. Просто нужно помнить что мир не будет подстраиваться под «рядовые компании» и если нашей гипотетической «рядовой компании» важно/нужно держать связь с миром надо принимать мир таким как он есть.
PS Если хочется запретить письма с вашим «from»ом приходящие к вам из вне — просто запретите их на вашем MXе — это куда надежней.
SPF декларировать безусловно нужно хотя-бы потому что SPF используется большинством анти-спам систем и в случае отсутствия SPF записи, зачастую, применяются параметры хуже любой пермисив политики SPF. С дугой стороны я-бы поостерегся советовать не ставить "?all" или "~all": «рядовые компании» тоже пишут письма клиентам/партнерам. Эти письма будут/могут теряться при перенаправлениях возникающих регулярно и оправданно (компании покупают и продают, они сливаются и разделяются, возникают/исчезают филиалы, ребрендеринг и т.д.). Установка систем которые переписывают шапку или перепаковывают письмо — скорее исключение чем правило. Просто нужно помнить что мир не будет подстраиваться под «рядовые компании» и если нашей гипотетической «рядовой компании» важно/нужно держать связь с миром надо принимать мир таким как он есть.
PS Если хочется запретить письма с вашим «from»ом приходящие к вам из вне — просто запретите их на вашем MXе — это куда надежней.
Важно еще помнить.
Если вы в своем домене сделаете -all, то ваши письма не будут перенаправлены в случае, если у вашего получателя стоит forward писем с одного ящика на другой.
Поэтому чаще всего приходиться оставлять ~all
Если вы в своем домене сделаете -all, то ваши письма не будут перенаправлены в случае, если у вашего получателя стоит forward писем с одного ящика на другой.
Поэтому чаще всего приходиться оставлять ~all
И к сожалению, как минимум в 90% ничего из этого не выполнимо.
Начиная от *бухгалтерша тетя Глаша(да вообще любой юзер) не будет и недолжна заморачиваться, а вводить 123456 !* до *Apple ето круто и поэтому у нас все будет на Apple Extreme\etc*. В большинстве случаев просто найдут нового студента-типаадмина. Тут надо исправлять в мозгах в 1 очередь с софтом и так все давно известно
Начиная от *бухгалтерша тетя Глаша(да вообще любой юзер) не будет и недолжна заморачиваться, а вводить 123456 !* до *Apple ето круто и поэтому у нас все будет на Apple Extreme\etc*. В большинстве случаев просто найдут нового студента-типаадмина. Тут надо исправлять в мозгах в 1 очередь с софтом и так все давно известно
Не согласен. Я делал упор на то, что делается своими руками, и без дозакупок. Не уверен, что тетя Глаша у вас создает кривые групповые политики, и конфигурит ssh.
Задача безопасника/админа — организовать правильную настройку того, на что можно повлиять, а про остальное — вовремя и правильно донести риски тому, кто «выше». Если вы все сделали правильно — риски уже не ваши, вы сделали все, что от вас зависело.
Задача безопасника/админа — организовать правильную настройку того, на что можно повлиять, а про остальное — вовремя и правильно донести риски тому, кто «выше». Если вы все сделали правильно — риски уже не ваши, вы сделали все, что от вас зависело.
Тетя Глаша, конечно же, ничего не создает, но обязана(потому что хочет) войти под 123456, потому что *я не буду ничего запоминать сложного(или начнет постоянно «забывать») и конечно же раструбит пароль всем своим «девочкам» *, а также подключить Айфончик и чтоб айтюнс стоял и чтоб контакт играл и т.д. и т.п.
Я, в принципе, и имел ввиду что до подавляющего большинства это донести просто не возможно, как в анекдоте про собаку — «она же хочет, так дай ей». \
К ОГРОМЕННОМУ сожалению это суровая реальность почти всего, что не «жесткий „энтерпрайз… или нет хороших отношений напрямую с генеральным, а иначе вас просто заменят на “мальчика, который сказал, что все это можно, значит он умнее да и денег просит в 5 раз меньше, пиши короче по собственному». как то так :)
Я, в принципе, и имел ввиду что до подавляющего большинства это донести просто не возможно, как в анекдоте про собаку — «она же хочет, так дай ей». \
К ОГРОМЕННОМУ сожалению это суровая реальность почти всего, что не «жесткий „энтерпрайз… или нет хороших отношений напрямую с генеральным, а иначе вас просто заменят на “мальчика, который сказал, что все это можно, значит он умнее да и денег просит в 5 раз меньше, пиши короче по собственному». как то так :)
Выдайте тете Глаше токен с сертификатом, и ей логиниться будет даже проще, чем пароль набирать. Попутно «раструбить пароль девочкам» становится более затруднительно. Как раз этот текст выгодно отличается адекватными рекомендациями, из которых в конторе со средней руки бардаком можно выполнить очень многое.
Будет этот токен с сертификатом лежать возле монитора и гулять по девочкам. Как например закрытая цифровая подпись директора для взаимодействия с банк-клиентом, и с подписанным паролем на той же дискете ЧТОБЫ ЕГО НЕ ЗАБЫТЬ.
Да и пусть лежит. Внутренняя безопасность — отдельный большой вопрос, а вот для атакующего, не имеющего доступа к токену (любого внешнего, например) задача серьезно усложняется.
У токена есть ещё один большой плюс — проще установить ответственность, особенно в маленьких конторах. Лежит этот токен у директора в сейфе, отдал он его тёте Глаше — та может ходить; забрал — не может. Передала девочке — не может работать сама, ну и плюс для далёкого от ИТ директора передача токена — весомее и понятнее, чем разглашение пароля.
Поддерживаю.
У своих клиентов мы реализовали 90% того, что описано в этой замечальной статье. +802.1x и WPA2-Enterprise Wifi.
Необходимо докрутить NTLMv2 и WPAD., хотя, вроде они усилены или даже погашены. Надо будет еще раз проверить.
У своих клиентов мы реализовали 90% того, что описано в этой замечальной статье. +802.1x и WPA2-Enterprise Wifi.
Необходимо докрутить NTLMv2 и WPAD., хотя, вроде они усилены или даже погашены. Надо будет еще раз проверить.
Павел, большое спасибо за очень полезную статью.
Очень нравится ваш стиль изложения информации, — все понятно, ничего лишнего.
От себя хочу немного добавить.
Active Directory
Учетные записи локальных админов необходимо либо блокировать совсем при помощи механизма Restricted Groups, либо использовать механизм LAPS для ротации паролей.
Также, при помощи Restricted Groups необходимо регулировать состав привилегированных доменных и локальных групп (Domain Admins, Enterprise Admins, Schema admins, “Local” Administrators, Guests и так далее). При помощи этого же механизма необходимо очищать встроенные группы (Printer operators, backup operators и так далее), так как пользователь, входящий в данные группы наделяется очень большими правами и через его учетную запись возможно повышение привилегий.
Желательно удалять с контроллеров домена и других серверов GUI и WoW64. Не всегда такое возможно, но желательно.
В домене очень желательно настроить центральное хранилище ADMX-шаблонов.
Центральное логирование
В сети желательно выделить изолированный хост, на который все системы сети будут слать свои логи. К данному хосту должен быть по возможности закрыт любой сетевой удаленный доступ, чтобы уменьшить вероятность его взлома. Если это windows-система, она не должна быть подключена к домену и должна иметь самый строжайший профиль безопасности.
На данном хосте можно запускать анализаторы логов сразу для всех систем инфраструктуры. И в случае компрометации сети, можно будет понять, откуда и как был произведен взлом.
Сетевые устройства
На коммутаторах и маршрутизаторах хорошо бы подвергать автоматическому аудиту файлы конфигурации. Тот же сервер логирования, может периодически подключаться к данным устройствам и проверять была ли изменена конфигурация. Если была изменена, то обязательно высылать предупреждение о данном событии группе администраторов.
Единая аутентификация/авторизация
На всех сетевых устройствах желательно настроить единую аутентификацию/авторизацию. Связка Radius+NPS работает отлично, если есть AD.
DMARC
После того, как настроены и протестированы DKIM и SPF, очень желательно прописать для доменов компании DMARC настройки, чтобы уменьшить спуфинг адресов из ваших доменов.
Предложение
Может быть объединим усилия и напишем по каждой главе по отдельной статье?
Думаю, многим было бы узнать, как правильно развернуть взрослый PKI (с поднятием автономного ADCA, раздачей сертификатов для SubCA и т. д.), потом настроить WPA2-Enterprise, 802.1x.
Все, что вы описали, в моих системах реализовано и по некоторой части проектов есть документация.
Еще раз спасибо за статью.
Очень нравится ваш стиль изложения информации, — все понятно, ничего лишнего.
От себя хочу немного добавить.
Active Directory
Учетные записи локальных админов необходимо либо блокировать совсем при помощи механизма Restricted Groups, либо использовать механизм LAPS для ротации паролей.
Также, при помощи Restricted Groups необходимо регулировать состав привилегированных доменных и локальных групп (Domain Admins, Enterprise Admins, Schema admins, “Local” Administrators, Guests и так далее). При помощи этого же механизма необходимо очищать встроенные группы (Printer operators, backup operators и так далее), так как пользователь, входящий в данные группы наделяется очень большими правами и через его учетную запись возможно повышение привилегий.
Желательно удалять с контроллеров домена и других серверов GUI и WoW64. Не всегда такое возможно, но желательно.
В домене очень желательно настроить центральное хранилище ADMX-шаблонов.
Центральное логирование
В сети желательно выделить изолированный хост, на который все системы сети будут слать свои логи. К данному хосту должен быть по возможности закрыт любой сетевой удаленный доступ, чтобы уменьшить вероятность его взлома. Если это windows-система, она не должна быть подключена к домену и должна иметь самый строжайший профиль безопасности.
На данном хосте можно запускать анализаторы логов сразу для всех систем инфраструктуры. И в случае компрометации сети, можно будет понять, откуда и как был произведен взлом.
Сетевые устройства
На коммутаторах и маршрутизаторах хорошо бы подвергать автоматическому аудиту файлы конфигурации. Тот же сервер логирования, может периодически подключаться к данным устройствам и проверять была ли изменена конфигурация. Если была изменена, то обязательно высылать предупреждение о данном событии группе администраторов.
Единая аутентификация/авторизация
На всех сетевых устройствах желательно настроить единую аутентификацию/авторизацию. Связка Radius+NPS работает отлично, если есть AD.
DMARC
После того, как настроены и протестированы DKIM и SPF, очень желательно прописать для доменов компании DMARC настройки, чтобы уменьшить спуфинг адресов из ваших доменов.
Предложение
Может быть объединим усилия и напишем по каждой главе по отдельной статье?
Думаю, многим было бы узнать, как правильно развернуть взрослый PKI (с поднятием автономного ADCA, раздачей сертификатов для SubCA и т. д.), потом настроить WPA2-Enterprise, 802.1x.
Все, что вы описали, в моих системах реализовано и по некоторой части проектов есть документация.
Еще раз спасибо за статью.
Откуда вообще вот это миф про бухгалтеров и тем более 123456 в виндовой среде?
Если ИТ и просто менеджмент — вменяемый, то все будет хорошо. Речь конечно про более-менее крупные компании.
Если ИТ и просто менеджмент — вменяемый, то все будет хорошо. Речь конечно про более-менее крупные компании.
Хорошие рекомендации.Хотел дополнить про DMZ.
Вынос сервера в DMZ — пол дела. Большую проблему составляют обращения серверов из DMZ внутрь сети. Обычно для этого на DMZ-FW открывают маршрутизацию с конкретного IP:Port сервера в DMZ к конкретному IP:Port серверу внутри сети — то есть делают дырку в DMZ. С годами DMZ превращается в решето и теряет эффективность.
Для того, чтобы не делать дыры в DMZ-FW (по крайней мере радикально снизить их количество), связь между сервером в DMZ и сервером внутри сети делают через туннелирующий back connect, который может быть построен в виде VPN или SSH туннеля, где инициатором является сервер внутри сети.
Вынос сервера в DMZ — пол дела. Большую проблему составляют обращения серверов из DMZ внутрь сети. Обычно для этого на DMZ-FW открывают маршрутизацию с конкретного IP:Port сервера в DMZ к конкретному IP:Port серверу внутри сети — то есть делают дырку в DMZ. С годами DMZ превращается в решето и теряет эффективность.
Для того, чтобы не делать дыры в DMZ-FW (по крайней мере радикально снизить их количество), связь между сервером в DMZ и сервером внутри сети делают через туннелирующий back connect, который может быть построен в виде VPN или SSH туннеля, где инициатором является сервер внутри сети.
Сомнительное решение, лучше поставить нормальный FW с анализом протокола и выделить изоалированный VLAN для каждого сервера в DMZ.
В чем сомнительное?
VLAN под каждый сервер — уменьшит возможность использования дырок в DMZ другими серверами, но возможность использования будет зависеть от сетевого оборудования и средств виртуализации которыми вы пользуетесь. VPN/SSH — универсальное бесплатное решение.
Анализатор протокола — это здорово, но какой протокол вы собираетесь анализировать? TCP/HTTP? Анализатор протоколов очень узкоспециализированное решение, как универсальное решение его рассматривать нельзя.
Я бы сказал, что указанное вами решение — альтернативно и имеет свои плюсы и минусы.
VLAN под каждый сервер — уменьшит возможность использования дырок в DMZ другими серверами, но возможность использования будет зависеть от сетевого оборудования и средств виртуализации которыми вы пользуетесь. VPN/SSH — универсальное бесплатное решение.
Анализатор протокола — это здорово, но какой протокол вы собираетесь анализировать? TCP/HTTP? Анализатор протоколов очень узкоспециализированное решение, как универсальное решение его рассматривать нельзя.
Я бы сказал, что указанное вами решение — альтернативно и имеет свои плюсы и минусы.
В чем сомнительное?
В сложности настройки и необходимости ставить дополнительный софт на серверы.
Анализатор протоколов очень узкоспециализированное решение, как универсальное решение его рассматривать нельзя.
Он сейчас есть в любом NGFW, а раньше был в модуле IPS для ASA и других файрволов.
NGFW, IPS — это устройства, цена покупки которых (не считая подписок на обновления и тех. поддержку) измеряется в килобаксах. Конечно если у вас есть на это деньги — здорово. SSH/VPN туннели (как вариант OpenVPN) — бесплатны. Настройка back connect через SSH — занимает пару часов (практический опыт).
Скажите пожалуйста, в каком из указанных вами устройств производится анализ протокола процессинга платежных карт TIC / TCI? Вопрос риторический :)
Применение SSH/VPN — защищает трафик от изменений при движении по остальной сети.
Актуальна эта угроза или нет можно понять, если сможете точно ответить на вопрос, где физически у вас проходят трассы линий связи. Для организаций находящихся в бизнес центрах, да и еще на разных этажах, это вопрос более чем актуален.
Скажите пожалуйста, в каком из указанных вами устройств производится анализ протокола процессинга платежных карт TIC / TCI? Вопрос риторический :)
Применение SSH/VPN — защищает трафик от изменений при движении по остальной сети.
Актуальна эта угроза или нет можно понять, если сможете точно ответить на вопрос, где физически у вас проходят трассы линий связи. Для организаций находящихся в бизнес центрах, да и еще на разных этажах, это вопрос более чем актуален.
NGFW, IPS — это устройства, цена покупки которых (не считая подписок на обновления и тех. поддержку) измеряется в килобаксах.
Эти модули входят в состав устройств через которые компания выходит в интернет и даже на сервер с FreeBSD можно натянуть snort или ещё какой опенсорсный IPS/IDS.
Настройка back connect через SSH — занимает пару часов (практический опыт).
Как вы будете его настраивать на контроллере домена и куда вас пошлют админы с просьбой поставить туда OpenVPN?
И проблема никуда не денется — правило файрвола server1:* -> server2:53/UDP просто помещается внутрь туннеля и при взломе server1 доступ к server2:53/UDP у него остаётся.
Скажите пожалуйста, в каком из указанных вами устройств производится анализ протокола процессинга платежных карт TIC / TCI?
Для защиты процессинга наверняка есть свои решения.
Актуальна эта угроза или нет можно понять, если сможете точно ответить на вопрос, где физически у вас проходят трассы линий связи.
IPSec.
Эти модули входят в состав устройств через которые компания выходит в интернет...
Подавляющее число компаний в России выходит в Интернет через бытовые роутеры а-ля DlInk или Linux-box, а те кто побогаче ставит Cisco типа ISR 2800. Устройства подобного класса реализуют Statefull firewall не более.
К NGFW относятся устройства уверенно работающие с deep packet inspection например железки Palo Alto которые по заверению производителя могут отличить HTTPS трафик от IE от HTTPS трафика Chrome и т.д. Open Source решения подобного плана, чтобы «скачать из Интернета и работало» ( без необходимости допила и НИОКРа) я не видел.
Как вы будете его настраивать на контроллере домена и куда вас пошлют админы с просьбой поставить туда OpenVPN?
Единственный вариант, когда нужно из DMZ разрешать доступ к контролеру домена внутри сети — это когда RO DC (read only domain controller) из DMZ хочет реплицироваться с полнофункциональным доменом внутри сети. Остальные случаи небезопасны by design. Проблем поставить OpenVPN на контролеры домена я не вижу. Работать он может как сервис, если нормально настроить то и связь устойчиво держит.
И проблема никуда не денется
Back connect туннели не защищают сервера от взлома, они призваны избавить от необходимости создания дыр в DMZ FW (то есть правил, пример которых вы указали) между DMZ и внутренней сетью.
Для защиты процессинга наверняка есть свои решения.
Конечно есть, но это не массовый NGFW. Поэтому просто «анализатор протокола», который есть в массовых решениях позволит вам защитить только массовые протоколы — TCP, HTTP и некоторый ряд других. Но подчеркну еще раз это не универсальное решение.
IPSec.
IPSec в чистом виде для back connect не подойдет. Почему? В нем нет понятия сервера (как компьютера, ожидающего подключения со стороны других компьютеров), туннель строится как по запросу сервера 1 (DMZ), так и по запросу сервера 2 (вн. сеть). Рассмотрим случай когда между сервером 1 и сервером 2 долго нет сетевого обмена и по тайм-ауту (или по другим причинам) туннель упал. Затем сервер 1 понял, что он хочет что-то передать серверу 2 он пытается к нему обратится, но поскольку дыры в DMZ нет — сделать он это не может.
Open Source решения подобного плана, чтобы «скачать из Интернета и работало» ( без необходимости допила и НИОКРа) я не видел.
ИБ вообще штука недешевая, хотя ASA 5506-X стоит пару килобаксов и тоже что-то умеет.
Back connect туннели не защищают сервера от взлома, они призваны избавить от необходимости создания дыр в DMZ FW (то есть правил, пример которых вы указали) между DMZ и внутренней сетью.
Чем плохи правила на файрволе? У куча VPNов есть куча минусов — сложность, ненадёжность и отсутствие центральной точки контроля.
Это решение для подключения к сторонним оргазациям над которыми нет контроля. Например, чтобы избежать ситуации когда у подрядчика изменился IP-адрес и об этом забыли сообщить.
IPSec в чистом виде для back connect не подойдет.
Цитата была про защиту транспорта, с ней IPSec прекрасно справляется.
А вообще, лучше призвать в пост JDima и узнать мнение нормальных сетевиков.
Призвался.
imbasoft, странное предлагаете.
C какой стати? Можно завести политику вычищать все ни разу за полгода не сработавшие правила, и при выведении из эксплуатации хостов подтирать за ними правила. Даже если правила громоздятся — ничего особо страшного от этого нет, если на уровне доступа не давать спуфить адреса.
Что-что? Четыре фронта и четыре бекенда — это уже 16 туннелей городить, по четыре на хост? А что вообще даст этот туннель? И как ими централизованно управлять — например, ограничивать протоколы, исходя из того, что сервер в DMZ похакан?
imbasoft, странное предлагаете.
С годами DMZ превращается в решето и теряет эффективность
C какой стати? Можно завести политику вычищать все ни разу за полгода не сработавшие правила, и при выведении из эксплуатации хостов подтирать за ними правила. Даже если правила громоздятся — ничего особо страшного от этого нет, если на уровне доступа не давать спуфить адреса.
туннелирующий back connect
Что-что? Четыре фронта и четыре бекенда — это уже 16 туннелей городить, по четыре на хост? А что вообще даст этот туннель? И как ими централизованно управлять — например, ограничивать протоколы, исходя из того, что сервер в DMZ похакан?
С годами DMZ превращается в решето и теряет эффективность......C какой стати?
Под дырами в DMZ — подразумеваются легитимные «дыры» используемые легальными серверами для легальных целей. В вашем примере (если я вас правильно понял) есть фронт, который стоит в DMZ и есть back который находится внутри сети, причем фронт должен иметь возможность достучаться до бека. Для этого на DMZ FW вы разрешаете хождение трафика между фронтом в DMZ и бэокм внутри сети. Вот это правило я и называю дырой в DMZ.Если сеть растет (становится больше сервисов) таких правил становится все больше и больше.
Опасность дыры в том, взломанные сервера из DMZ могут ими воспользоваться, с помощью IP/MAC спуфинга для атак серверов внутри сети.
туннелирующий back connect… Что-что? Четыре фронта и четыре бекенда — это уже 16 туннелей городить, по четыре на хост? А что вообще даст этот туннель?
Подобный подход позволяет вообще не делать дырок в DMZ (то есть открытия маршрутизации из DMZ ко внутренней сети), а также защитить трафик от перехвата и модификации (ARP spoof и др MiTM-атак).
И как ими централизованно управлять
Не совсем понятно чем вы хотите управлять. Туннель строится на двух точках 1 — сервер в DMZ и 2 — сервер в внутрисети. Если сервер 1 похакан — управлять тунелями не надо, а надо восстанавливать контроль над сервером. Если имеется ввиду оперативная блокировка, то ее можно сделать на DMZ FW полностью заблокировав весь трафик до взломанного сервера.
взломанные сервера из DMZ могут ими воспользоваться, с помощью IP/MAC спуфинга для атак серверов внутри сети.
Ну уж от такого защититься на-а-амного проще, чем на каждое соединение городить по туннелю. Прямо на уровне порта реального или виртуального сервера. При желании и фильтрацию доступа можно там же организовать, чем, кстати, исключаются прыжки с одного сервера внутри DMZ на другой, и без головной боли с VACLами или pvlan'ами.
Подобный подход позволяет вообще не делать дырок в DMZ
Так ведь ничего особо не меняется (кроме надежности, которая очевидно падает). Туннель создает дырку, по которой будут обратные соединения. Туннелей будет много, катастрофически много.
а также защитить трафик от перехвата и модификации (ARP spoof и др MiTM-атак).
Все выпущенные где-то начиная с начала века более-менее приличные свитчи не позволят спуфить арп и делать mitm. Если правильно настроить. При наличии виртуализации и нормальных vswitch'ей всё даже проще.
Туннель строится на двух точках 1 — сервер в DMZ и 2 — сервер в внутрисети
Ок. У меня сотни серверов в DMZ и сотни серверов внутри сети. И бригада админов приложений, которые и с апачами-томкатами не всегда могут сладить, а заставить их оформить полную матрицу доступов для сервиса менее чем с третьей попытки вообще невозможно. Вы будете требовать от них поддерживать руками это нагромождение, когда иногда они забывают запустить сервис и орут про «файрвол дропает наш трафик»? Да весь бизнес после такого колом встанет.
Разрешить новому серверу мониторинга доступ к нескольким сотням серверов для вытягивания разных метрик — это надо несколько сотен новых туннелей городить? Кто этим будет заниматься? Это не поддается ручному сопровождению. В нормальном ентерпрайзе пяток разношерстных систем мониторинга точно найдется, и в любой данный момент времени что-нибудь новое наверняка будет тестироваться. Закладывать месяц на предоставление доступов?
Если сервер 1 похакан
Тут кстати тоже интересный момент. Туннель не позволит стороннему FW или IDS смотреть на обмен и видеть тревожные звоночки, к примеру — нехарактерные HTTP или SQL запросы. Обнаружить факт похаканья сервера в DMZ становится несколько сложнее. Незаметно поиметь только фронт проще, чем и фронт, и бек.
Ребята, Вы спорите об мягком и тёплом (=
у каждого из ваших примеров есть свои + и — Я с каждым из вас согласен, но применять это все нужно с умом
если у вас есть офис и конечное и статичное кол-во серверов, можно использовать
тунели для удобства it-support
если же у вас динамика в серверах (каждый день все меняется), то больше то меньше
нужно уже городить динамику(анализаторы, скрипты и прямые руки)
у каждого из ваших примеров есть свои + и — Я с каждым из вас согласен, но применять это все нужно с умом
если у вас есть офис и конечное и статичное кол-во серверов, можно использовать
тунели для удобства it-support
если же у вас динамика в серверах (каждый день все меняется), то больше то меньше
нужно уже городить динамику(анализаторы, скрипты и прямые руки)
Бест практики и глобальные тенденции подразумевают что сегодня практически любой коннект клиент-сервер или сервер-сервер завернут в TLS туннель (ну или как-либо иначе зашифрован). Что именно и как вы собираетесь анализировать?
Можно расшифровать при необходимости.
Вам не кажется что ваше «решение» хуже «проблемы»? У нас тут тоже кроме всего прочего ваш «расшифровать» стоит (тот самый за много сотен килобаксов). Были попытки пропихнуть эту функцию в продакшен… не прошло. Не буду расписывать — просто посмотрите топовые фаерволы за последний 10 лет и найдите хотя-бы один который (задним числом конечно) не оказался-бы критически дырявым — это общая проблема «черных ящиков». Нельзя своими руками ослаблять «реальную» защиту в борьбе с «гипотетическими» рисками.
Я же написал «при необходимости», в ентерпрайзе её испытывают и готовы платить.
А баги находят везде и задача ИБ в снижении рисков, так как невозможно создать абсолютно надёжное решение.
А баги находят везде и задача ИБ в снижении рисков, так как невозможно создать абсолютно надёжное решение.
Я надеялся что вы представите пример реалистичного сценария при котором экспозиция ключей шифрования третей стороне (= серьезное глобальное ослабление безопасности) компенсируется чем-либо другим (укрепляющим безопасность и невозможным получить другим способом (более простым и безопасным))
Безусловно оставим в стороне потребности вроде цензуры/шпионажа/контроля пользователей: такие сценарии изначально исходят из потребности ослабить безопасность до уровня допускающего внедрение «наблюдателя»…
Безусловно оставим в стороне потребности вроде цензуры/шпионажа/контроля пользователей: такие сценарии изначально исходят из потребности ослабить безопасность до уровня допускающего внедрение «наблюдателя»…
Например, мы хотим фильтровать трафик от всякой гадости через специальную железку. Или укрепить безопасность компании внедрив DLP-систему, чтобы пользователи не кидали рабочие файлы в дропбокс.
Ваш пример, по большому счету, опять из области «цензуры/шпионажа/контроля пользователей»: если ваши пользователи могут себе ставить «дропбокс» то они без труда себе поставят как «обходилку» вашего мониторинга так и нахватаются всякой другой малвари. Последняя кстати тоже успешно обходит все эти «специальные железки» уже не первый год банально интегрируя свой трафик в параметры тех-же GET/POST обычного веб-трафика.
Обеспечение безопасности рабочих станций надо на них и реализовывать — именно там где есть наиболее полная информация о контексте и адекватности того или иного действия пользователя. Если-бы эффективность ваших железок была-бы сколько-нибудь значимой то, я думаю, все страны уже давно бы скинулись на парочку: одна-бы уничтожила все вирусы а вторая весь спам ;-)
Обеспечение безопасности рабочих станций надо на них и реализовывать — именно там где есть наиболее полная информация о контексте и адекватности того или иного действия пользователя. Если-бы эффективность ваших железок была-бы сколько-нибудь значимой то, я думаю, все страны уже давно бы скинулись на парочку: одна-бы уничтожила все вирусы а вторая весь спам ;-)
Обходилки быстро и качественно ловятся и блокируются простым действием — ставим прокси и всех во внешний мир через него. На нем же обламывается малварь. А если вернемся к NGFW то сейчас они ещё по анализу того что в GET/POST положили, а также по тому какие FQDN пытается резолвить хост прекрасно детектирует зараженные малварью рабочие места.
Друзья, у нас возникла буйная дискуссия по поводу данного метода. Чтобы изложить свою точку зрения комментариев оказалось мало, поэтому подготовил отдельную статью
> Противодействие угону доменных учетных записей через mimikatz/wce…
> Против этих утилит есть меры разной степени эффективности, например, такие
К сожалению, в реальности толку от этих мер мало. Домен целиком на 2012 R2 c рабочими станциями на 8.1 и старше — явная экзотика, а все способы защиты на младших ОС подразумевают настройки на локальной машине, что, очевидно, полностью бесполезно против пользователя с правами локального админа (и вряд ли стоит рассчитывать, что человек, пользующийся mimikatz, не осилит изменение ключа реестра или запрет групповых политик). Так что по факту защита только одна — разные учетных записи для администрирования разных участков инфраструктуры.
> Обращение к SMB по именам и запрет использования NTLM
Ууу… а вот это проблема из проблем. Уж не помню, сколько раз мне хотелось придушить разработчиков всякого ПО, которые во второй декаде 21 века умеют только NTLM (некоторые ещё LDAP simple bind).
> Против этих утилит есть меры разной степени эффективности, например, такие
К сожалению, в реальности толку от этих мер мало. Домен целиком на 2012 R2 c рабочими станциями на 8.1 и старше — явная экзотика, а все способы защиты на младших ОС подразумевают настройки на локальной машине, что, очевидно, полностью бесполезно против пользователя с правами локального админа (и вряд ли стоит рассчитывать, что человек, пользующийся mimikatz, не осилит изменение ключа реестра или запрет групповых политик). Так что по факту защита только одна — разные учетных записи для администрирования разных участков инфраструктуры.
> Обращение к SMB по именам и запрет использования NTLM
Ууу… а вот это проблема из проблем. Уж не помню, сколько раз мне хотелось придушить разработчиков всякого ПО, которые во второй декаде 21 века умеют только NTLM (некоторые ещё LDAP simple bind).
1. «Сетевые диски как ярлыки.» — оно как бы может и хорошо и правильно с одной стороны, а с другой своевременные бэкапы справляются с этой напастью, а про них в статье забыли.
2. «Полностью изолированный гостевой WiF» поддерживаю, но и не гостевой я тоже бы изолировал. Внутри сети воздушки быть не должно (имхо), т.к. я не знаю пока невзлымываемых WIFI, а если они есть то не на долго, контролировать радиосети несравненно сложнее.
2. «Полностью изолированный гостевой WiF» поддерживаю, но и не гостевой я тоже бы изолировал. Внутри сети воздушки быть не должно (имхо), т.к. я не знаю пока невзлымываемых WIFI, а если они есть то не на долго, контролировать радиосети несравненно сложнее.
авторизация на WiFi только через WPA2-Enterprise, для того, чтобы каждый пользователь имел свои персональные, легко блокируемые учетные данные, которые контролируются централизованно
У Ruckus есть прекрасное решение с DPSK, когда устройству выдаётся персональный ключ с привязкой к MAC-адресу после самостоятельной регистрации.
По надёжности не хуже сертификатов — их всё равно можно упереть с правами админами через тот же mimikatz, а управляется из центральной панели где видно какое устройство кому принадлежит (в отличии от ADCS). Единственный минус в необходимости перерегистрации после истечения срока действия PSK, но для среды с зоопарком ОС и BYOD — это меньшее из зол.
Сервис https://www.ssllabs.com/ssltest/ имеет dev версию, которая прямо сейчас (в отличие от основной), например, детектит OpenSSL Padding Oracle vulnerability (CVE-2016-2107), понижая статус сервера с A+ до C.
По части винды опередили меня со статьей, сам думал примерно подобное описать.
И вот еще любимая картинка:
http://3.bp.blogspot.com/-fwCJdKDZQUc/Uh8axR2QJVI/AAAAAAAAMvQ/-eEyZz1aHlE/s1600/20%20SC.png
Но, как писал arkanoid — ваш домен всё равно поломают, в первую очередь)
И вот еще любимая картинка:
http://3.bp.blogspot.com/-fwCJdKDZQUc/Uh8axR2QJVI/AAAAAAAAMvQ/-eEyZz1aHlE/s1600/20%20SC.png
Но, как писал arkanoid — ваш домен всё равно поломают, в первую очередь)
Чем плох проброс портов?
Есть ресурсы для проверки открытости сети из вне?
Есть ресурсы для проверки открытости сети из вне?
1. тоже задаюсь вопросом по поводу проброса портов
2. я не ИБшник, но для мелких проверок пользуюсь сервисом Open Port Check Tool Для чего-то более серьёзного есть специальные утилиты аля nmap
2. я не ИБшник, но для мелких проверок пользуюсь сервисом Open Port Check Tool Для чего-то более серьёзного есть специальные утилиты аля nmap
— Плох тем, что:
1. Видно внутренние сервисы через инет. Их можно исследовать, вынимая скрытую информацию, вплоть до критическо значимой для потенциальной атаки. Их можно ломать, и, если нет изоляции типа DMZ, то привет вся внутренняя сеть, и дальнейшие атаки.
2. Без VPN с шифрованием — еще добавляется вероятность атаки типа Mitm на подключающегося во внутреннюю сеть через интернет. Тут и кражи прав доступа, и прослушка трафка, и другие прелести.
3. Если пробрасывать порт, и таким образом давать удаленный доступ, например, по RDP без VPN, вы не сможете устроить хороший разбор полетов в случае проблем. VPN же добавит в логи конкретное имя пользователя на сетевую железку, а они обычно более устойчивы к взломам, чем серверы.
— Ресурсы — google: nmap online. Можно делать самостоятельно от другого подключения к инету, но со сканом даже своего адреса надо аккуратнее, это не то, что можно легко советовать.
1. Видно внутренние сервисы через инет. Их можно исследовать, вынимая скрытую информацию, вплоть до критическо значимой для потенциальной атаки. Их можно ломать, и, если нет изоляции типа DMZ, то привет вся внутренняя сеть, и дальнейшие атаки.
2. Без VPN с шифрованием — еще добавляется вероятность атаки типа Mitm на подключающегося во внутреннюю сеть через интернет. Тут и кражи прав доступа, и прослушка трафка, и другие прелести.
3. Если пробрасывать порт, и таким образом давать удаленный доступ, например, по RDP без VPN, вы не сможете устроить хороший разбор полетов в случае проблем. VPN же добавит в логи конкретное имя пользователя на сетевую железку, а они обычно более устойчивы к взломам, чем серверы.
— Ресурсы — google: nmap online. Можно делать самостоятельно от другого подключения к инету, но со сканом даже своего адреса надо аккуратнее, это не то, что можно легко советовать.
Как внутренние сервисы видно? проброс идет только на нужный сервер и только нужного порта. В случае взлома первого фаервола, второй не окажется проблемой ибо они с высокой вероятностью будут одинаковыми, включая схожие настройки по портам. Не уверен, что вариант с двумя фаерволами в данном случае будет намного устойчивее. Тогда как мне кажется вариант для параноиков интереснее, но затратнее. Взлом сервиса по открытым портам возможен и тогда сети конечно будет хуже.
Если контора разбогатеет, то может два фаервола и возьму на заметку, но боюсь, боюсь это будет очень не скоро.
Найти бы ПО для поиска уязвимостей извне. Внутри сети и так в курсе, что все почти как швейцарский сыр.
Если контора разбогатеет, то может два фаервола и возьму на заметку, но боюсь, боюсь это будет очень не скоро.
Найти бы ПО для поиска уязвимостей извне. Внутри сети и так в курсе, что все почти как швейцарский сыр.
Одного сервиса, в общем случае, достаточно для полного контроля хоста.
Если взломанный сервер в DMZ, взломщику доступен только этот сервер и, возможно, сеть DMZ, если же он в LAN, у взломщика праздник.
По поводу «взлома первого фаервола»: каким это вы образом делаете эту ситуацию, которая должна быть гипотетической, настолько реальной?
Если взломанный сервер в DMZ, взломщику доступен только этот сервер и, возможно, сеть DMZ, если же он в LAN, у взломщика праздник.
По поводу «взлома первого фаервола»: каким это вы образом делаете эту ситуацию, которая должна быть гипотетической, настолько реальной?
Это все теория по поводу взлома фаервола. Хотя на некоторые судя по рассказам таки проходят любопытные. т.е. это не панацея похоже.
Запугали (точнее предупредили) статьей, теперь буду лениво думать (денег нет) где брать еще фаерволы и сетевые карты. Встроенные в материнки сетевые нагрузки не держат даже весьма средней :(
Запугали (точнее предупредили) статьей, теперь буду лениво думать (денег нет) где брать еще фаерволы и сетевые карты. Встроенные в материнки сетевые нагрузки не держат даже весьма средней :(
Если же наоборот, администратор один, то деактивируйте sudo (особенно в том случае, если у вас по каким-то причинам сохранился вход через ssh по паролю), и для администраторских задач используйте аккаунт root.По мне, так взаимоисключающие пункты.
Ну и конечно, классика — не работайте под рутом.
Можно как-нибудь обосновать, чем sudo не подоходит для одного администратора?
Это все-таки мое личное мнение, не пытаюсь его возвести в абсолютную истину. Я рассуждал так. Предположим наличие двух наиболее частых вариантов авторизации через ssh — по сертификату, и по паролю. Во втором случае, зная только один пароль пользователя, можно получить root. С сертификатом авторизация, конечно, спасет от такого сценария. Но. Есть вариант авторизации на консоли сервера (физ. доступ, IP KVM). Тогда даже с сертификатом на ssh sudo опять даст прямой root при авторизации через консоль. Конечно я привел много условностей, пароль root можно точно так же похитить, а консоль защитить, но все-же, отдельный root это дополнительный полуфактор авторизации.
Вопрос применения sudo/чистого root для одного админа, кмк, остается на совести конкретного администратора, его привычек, опыта и оценки других факторов защиты сервера. У sudo однозначно есть свои большие плюсы, которые лучше всего себя проявят в многопользовательском сервере.
Вопрос применения sudo/чистого root для одного админа, кмк, остается на совести конкретного администратора, его привычек, опыта и оценки других факторов защиты сервера. У sudo однозначно есть свои большие плюсы, которые лучше всего себя проявят в многопользовательском сервере.
Это ничего что с помощью sudo пароль root меняется на раз-два-три? Зачем его хранить в конверте в этом случае? Зачем его вообще знать?
Про пароли у ключей не написали. Ведь ключи можно скопировать.
Хранить в конверте на случай внезапной недоступности всех sudo пользователей и необходимости сделать что-то с рутовыми правами. Хотя, конечно, никаких особых преимуществ перед хранением в конверте пароля пользователя hkhftu5aw5765sfcv в группе sudo вроде нет.
Т.к. важен «разбор полетов» после инцидентов. Если у всех персональные учетки, при включенном аудите найти источник значительно проще, чем в случае, если толпа будет пользоваться одним общим root. Кто-то поменял пароль root из sudo — пожалуйста, только это инцидент. Знать root — на аварийные случаи, когда все владельцы персональных учеток внезапно кончились.
Пароли у ключей ssh это само собой, иначе это будет как пароль на бумажке под клавиатурой.
Пароли у ключей ssh это само собой, иначе это будет как пароль на бумажке под клавиатурой.
Как при отключенном WPAD, можно «Запретите прямой произвольный доступ в интернет для «пользовательской» сети»?
Вручную прописывать на хостах адрес прокси сервера?
А если это ноутбук директора который уехал в командировку, а после звонит с благим матом, что у него ничего не работает, потому что забыли убрать галочку в свойствах обозревателя?
Ок, если у вас стоит TMG со своим клиентом, а если простой Squid? И его не поставить в качестве прозрачного прокси сервера на шлюз?
Вручную прописывать на хостах адрес прокси сервера?
А если это ноутбук директора который уехал в командировку, а после звонит с благим матом, что у него ничего не работает, потому что забыли убрать галочку в свойствах обозревателя?
Ок, если у вас стоит TMG со своим клиентом, а если простой Squid? И его не поставить в качестве прозрачного прокси сервера на шлюз?
Атака через WPAD в общем случае возможна, когда он не настроен. Т.е. клиенты ищут прокси, а инфраструктура не предлагает сервер конфигурации. В этом случае возможно навязывание злоумышленником своего сервера. Чтобы ее предотвратить, можно либо отключить WPAD (там где прокси не было и не будет), либо настроить WPAD, для случаев, когда используется прокси.
Кстати, путешествующий за пределы офиса ноутбук из домена не самое лучшее решение для безопасности сети.
Кстати, путешествующий за пределы офиса ноутбук из домена не самое лучшее решение для безопасности сети.
А как вы относитесь (я имею ввиду не только личное отношение, но и, возможно, из практики) к технологиям port knocking, web-knocking и т.п. ?
Про iptables на линуксовых серверах никто не написал, ну, значит, я напишу.
Были случаи когда всевозможные сервисы открывали порты на всех интерфейсах сразу, а не только на localhost. Да ещё и без паролей. Так, любой желающий смог бы просканировать ваш сервер на предмет известных портов и скачать всё, что ему хочется. Из последнего можно вспомнить redis.
Вывод из этого простой: закрывайте всё, кроме того, что вам явно нужно.
Есть компания со своей ИТ-инфраструкторой которая (по старой дружбе) просит "проверить на дырки" эту же ИТ-инфраструктуру с обеих сторон:
- в LAN-e будет выделен доменный ПК с правами обычного юзера
- "с мира" будет предоставлен список внешних IP, которые использует компания
Вопрос: какие инструменты рекомендуют использовать "ведущие собаководы" для таких целей.
Насколько имеет смысл пытаться организовать очень бюджетную DMZ (скорее что-то на неё похожее) с помощью iptables?
Имеем машину с двумя интерфейсами — публичным и внутренним. Публично машина предоставляет http/https на стандартных портах для нескольких доменов, внутри стоит nginx, проксирующий запросы на разные публичные домены к соответствующим серверам (как правило nginx+php-fpm, за которыми ещё mysql/pgsql) во внутренней сети и работающий как https-endpoint для всех публичных доменов. Плюс крутится ssh для внутренней сети для администрирования. Имеет ли смысл настраивать на этой машине iptables, так, чтобы исходящие запросы во внутреннюю сеть были возможны только на обслуживаемые веб-сервера, внутренний DNS и больше никуда, входящие из внутренней сети только на ssh, входящие из внешней сети только на 80 и 443, а исходящие на внешнюю были невозможны (разве что ICMP и DNS, чтобы проверять работает ли канал провайдера)? Можно ли будет считать эту машину файерволом в вашем бюджетном варианте DMZ?
Имеет ли смысл настраивать подобным образом внутренние веб-сервера (те, которые как правило nginx+php-fpm) с одним интерфейсом во внутренней сети, чтобы принимали входящие только с «файерволла», а исходящие уходили только на базы (ну и подобные сервисы типа redis/rabbitmq). Ну и плюс ssh, ICMP, DNS и т. п. Можно ли будет считать эти сервера, находящимися в DMZ? Или, как вариант, все исходящие от них направлять на «файервол», который будет перенаправлять их (iptables или HAProxy) на базы, внутренние DNS и т. п.? Это больше будет похоже на DMZ?
Контекст вопроса: нам, разработчикам, администраторы для наших сервисов передают обычно поднятые машины с осью (обычно ubuntu) и, максимум, установленные с настройками по умолчанию сервисы типа nginx, php-fpm и т. д.(разве что реальные айпишки поставят в конфигах вместо 127.0.0.1 или файлового сокета), давая нам sudo аккаунты. И меня это несколько напрягает. Функционально я сервисы-то настраиваю, но в вопросах безопасности… Переживаю даже не потому, что меня могут обвинить в дырах в моем софте, через которые злоумышленники получат доступ во внутреннюю сеть, или в том, что недостаточно защитил её от проникновения через дыры в том же nginx, а потому что просто не хочу своими руками давать им доступ, если цена вопроса лишь настройка нескольких iptables на десяток строк на машинах, у которых я по факту реальный администратор, а администраторов номинальных этот вопрос мало заботит.
Имеем машину с двумя интерфейсами — публичным и внутренним. Публично машина предоставляет http/https на стандартных портах для нескольких доменов, внутри стоит nginx, проксирующий запросы на разные публичные домены к соответствующим серверам (как правило nginx+php-fpm, за которыми ещё mysql/pgsql) во внутренней сети и работающий как https-endpoint для всех публичных доменов. Плюс крутится ssh для внутренней сети для администрирования. Имеет ли смысл настраивать на этой машине iptables, так, чтобы исходящие запросы во внутреннюю сеть были возможны только на обслуживаемые веб-сервера, внутренний DNS и больше никуда, входящие из внутренней сети только на ssh, входящие из внешней сети только на 80 и 443, а исходящие на внешнюю были невозможны (разве что ICMP и DNS, чтобы проверять работает ли канал провайдера)? Можно ли будет считать эту машину файерволом в вашем бюджетном варианте DMZ?
Имеет ли смысл настраивать подобным образом внутренние веб-сервера (те, которые как правило nginx+php-fpm) с одним интерфейсом во внутренней сети, чтобы принимали входящие только с «файерволла», а исходящие уходили только на базы (ну и подобные сервисы типа redis/rabbitmq). Ну и плюс ssh, ICMP, DNS и т. п. Можно ли будет считать эти сервера, находящимися в DMZ? Или, как вариант, все исходящие от них направлять на «файервол», который будет перенаправлять их (iptables или HAProxy) на базы, внутренние DNS и т. п.? Это больше будет похоже на DMZ?
Контекст вопроса: нам, разработчикам, администраторы для наших сервисов передают обычно поднятые машины с осью (обычно ubuntu) и, максимум, установленные с настройками по умолчанию сервисы типа nginx, php-fpm и т. д.(разве что реальные айпишки поставят в конфигах вместо 127.0.0.1 или файлового сокета), давая нам sudo аккаунты. И меня это несколько напрягает. Функционально я сервисы-то настраиваю, но в вопросах безопасности… Переживаю даже не потому, что меня могут обвинить в дырах в моем софте, через которые злоумышленники получат доступ во внутреннюю сеть, или в том, что недостаточно защитил её от проникновения через дыры в том же nginx, а потому что просто не хочу своими руками давать им доступ, если цена вопроса лишь настройка нескольких iptables на десяток строк на машинах, у которых я по факту реальный администратор, а администраторов номинальных этот вопрос мало заботит.
Sign up to leave a comment.
Еще раз о том, как не сделать из своей сети «решето»