Есть, на их основе в AD реализовано делегирование. Однако это вещь довольно опасная даже по сравнению с интерактивным логином — было бы достаточно чтобы любой пользователь
хотя бы по SMB ткнулся в сломанный терминальный сервер (даже если он вообще прав не имеет на этом RDSH), чтобы от его имени авторизоваться в любом сервисе, к которому разрешено делегирование (а их будет много, это ж терминальный сервер).
Поэтому, наверное SSO через CredSSP Default Credentials Delegation посчитали оптимальным в свое время. Ну, а теперь вот Remote Credential Guard.
Если речь про SSO, то Kerberos не позволит уйти дальше сеанса на сервере, так как ограничивает авторизацию одной конечной точкой, и, в общем-то, в этом почти весь его смысл и есть. То есть, сервер проверил что вы это вы, а вот ваш сеанс на этом сервере уже не сможет на еще одном сервере прозрачно авторизоваться. Прощайте все сетевые ресурсы. Такой режим кстати есть начиная с 2012, называется Restricted Admin Mode.
А так вообще Kerberos вполне себе используется, но только для проверки подлинности сервера вместо сертификатов (если проходит Kerberos, кривой сертификат игнорится).
Еще начиная с 2016 есть режим Remote Credential Guard, но и клиент и сервер должны быть поддерживаемой версии, и это по сути дополнительная обертка над Kerberos.
С нашей «цифровизацией» ключи ЭЦП прибывают сейчас на предприятия лавинообразно, поэтому и захотелось свой кейс описать.
Что касается лицензий — постепенно ПО переходит на облачную проверку лицензирования, пусть не всё сразу — но это в том числе те отличия, которые могут быть одним из аргументов при выборе нового / планировании апгрейдов. Вендоры всегда балансируют между защитой от пиратов и отказоустойчивостью, но, как правило, именно у «облачных» лицензий есть достаточно лояльный grace period, зачастую измеряющийся в неделях.
А USB ключи, наоборот, чаще проверяются многократно прямо во время работы защищаемого ПО.
Так что, зачастую, совсем уйти нельзя, но постепенно минимизировать риски возможно.
А что если навернется это счастье, а то и ключи с собой заберет?
Мне гораздо больше нравится идея вытащить ключи ЭЦП с токенов и загружать в профили нужных пользователей на терминальниках. Сразу становится гораздо лучше с отказоустойчивостью. Безопасность при этом вполне обеспечивается разделением пространства терминальных сессий, для параноиков можно VDI. Уж точно не хуже сильно нестандартной железки, которая у вас, как я понял, вообще в интернет напрямую смотрит (!).
От лицензионных же ключей просто по мере возможности нужно уходить — отказы ключей 1С «на 300» случались, и такое по-быстрому не решается. При этом, программные лицензии при всей своей небесспорности, по-крайней мере, дают 2 попытки моментального восстановления. Кстати, их можно сейчас на аппаратный ключ завязать, скрестив ежа с ужом и обеспечив как возможность легкой замены железа, так и использование резервных PIN в случае отказа ключа.
А ко мне какой-то вялый DDoS летит с их адресов. TCP SYN пакеты на все открытые tcp порты, по всем адресам. Заметил только по переполнению таблицы NAT, там большое время жизни записей, а так никакой заметной нагрузки.
До этого пару дней назад что-то похожее было с подсетей какого-то турецкого банка, который судя по турецким новостям в тот день тоже лежал…
Интересно, что это? Может, издержки маршрутизации? Для намеренной атаки совсем слабо.
Не, я не из идеального мира, но из мира людей, применяющих политики назначения прав пользователей, чтобы доменные админы не заходили случайно куда не следует.
Первую часть не понял. Петя собирает все что есть в lsass, а дальше если у вас из этого списка кто-то вхож на другие рабочие станции как админ, то Петя приезжает и на них тоже.
NotPetya помимо эксплойта EternalBlue использовал mimikatz чтобы вытащить из памяти lsass lm-хэши локальных администраторов, и дальше пробовал с ними ходить по сети. Например, вот здесь есть об этом.
А чем плох встроенный администратор? Тривиально ведь найти на машине всех остальных. Разве что UAC у него выключен по умолчанию. Так ведь включить можно, да и вообще согласно Microsoft «UAC is not a security feature».
Опасные вы вещи говорите — все ведь ровно наоборот.
Именно потому что привилегии локального админа сравнительно легко достижимы, они должны быть изолированы в пределах одной рабочей станции. Иначе повысившись на одной станции можно по всей сети расползтись — что наглядно всем желающим и продемонстрировал NotPetya еще полтора года назад.
Только не забудьте защитить атрибут объекта, в котором пароль будете хранить, а то обычные поля компьютерных объектов по умолчанию весь домен может читать. А после этого сделать какой-то тул для просмотра этого атрибута, потому что в ADUC его видно не будет.
А еще что-то придумать для клиентов, которые не постоянно онлайн, чтобы не пропускали время запуска скрипта.
А также не забудьте открыть везде порты, чтобы COM-RPC работал с сервера, на котором скрипт запускается, к клиентам — а то по умолчанию, например, клиенты общаются с контроллером домена только в режиме pull.
Ну и как следует защитить учетную запись, от которой запускается скрипт — прав у нее в сети будет немало.
Или можно вместо всей этой головной боли использовать LAPS, официальное и поддерживаемое (бесплатное) решение от Microsoft.
А кэширование учетных данных на рабочих станциях при этом включено или выключено? Если выключено, то у вас нет аварийного входа в случае, если нет связи с доменом. Если включено, то креативный пользователь mimikatz может натворить больших дел у вас в сети — см NotPetya.
При добавлении RADIUS клиента в NPS поддерживается CIDR-синтаксис в поле «адрес». Можно сразу всю подсеть с точками добавить как одного клиента.
NAT, конечно, оригинально, но…
Спасибо, подробно и доходчиво. А расскажите, пожалуйста, что-нибудь про производительность в режиме расшифровки SSL? Как показала практика, у некоторых вендоров с этим большая-большая беда — включая, скажем, отнюдь недешевые Checkpoint и Palo Alto.
Причем конкретные цифры никто не публикует, в отличие, например, от производительности IPS. А между тем, без расшифровки SSL DPI-фичи на 443 порту толком работать просто не будут, и весь NGFW превращается в тыкву.
CXы на прошивке от Microsoft — Lync Phone Edition, её развитие прекращено и через пару лет она будет снята с поддержки окончательно. Даже прошивку с заменой названия Lync на Skype for business для них не выпустили. Сам софт специфический, очень много функций зарыты в меню, мало физических кнопок.
Snom есть один (800й) тоже на LPE, с теми же ограничениями, а все остальные (700е) на собственной UC firmware, которую они перестали развивать осенью прошлого года, и из партнерской программы с MS вышли.
Так что из современных остались только VVXы, да Аудиокодес. По опыту ценник на них обоих заметно выше. VVX600 стоит около 30 000Р, а T48 — условно, 15. VVX310 — около 13 000, а T42 — 8 000. При этом свои грабли и тараканы в Поликомах тоже есть.
Софт не требуется, а просто предлагается как опция. То есть, можно и без него. Просто какие-то действия удобнее в софте делать, поэтому логично объединить софтфон с телефоном.
А отличие от гарнитуры есть — лучше качество звука, громкий спикерфон, можно звонить без компьютера, физические кнопки под рукой, ну и далее в том же духе. Насколько это необходимо, каждый решает для себя сам. У нас, например, большая часть абонентов обходятся без аппаратов, но какое-то их количество все равно нужно.
Хорошие аппараты для SfB, в целом. Есть опыт с двумя старшими моделями.
Есть один неприятный минус — нельзя нормально сохранить контакт с городским телефонным номером. Либо отображается один номер без имени, либо email-адрес и имя, но номера телефона вообще не будет. Можно, конечно, сохранить в локальные контакты, но это, во-первых, идеологически неверно, а во-вторых, при сохранении локального контакта почему-то не работает шикарная экранная клавиатура на 48ом. То есть имя-фамилию нужно набирать на цифровой клавиатуре.
Ноги этой проблемы растут, судя по всему, из полного отсутствия интеграции с контактами в Exchange, поэтому, видимо, и решить никак не могут.
В остальном довольно убедительные аппараты — интерфейс 48ого субъективно нагляднее, логичнее, и удобнее, чем у VVX600, и это при стоимости ниже, чем VVX410, который вообще сравнения в таком разрезе не выдерживает, ибо по меню замучаешься прыгать.
Особых глюков не замечено, основные функции все есть, качество спикерфона на уровне VVXов (!). Техподдержка на yealink.com отвечает, работает, и финскит потихоньку найденные легкие баги.
Snom от развития поддержки SfB отказались, так что из конкурентов остались недешевые Поликомы с отпиленным начисто в РФ SRTP, да Аудиокодес. Причем последние совсем не впечатлили, от интерфейса до качества звука.
Только вот HTTPS вы не поломаете, подменив DHCP. А с WPAD — как оказалось, частично можете.
В любой недоверенной сети DHCP и DNS могут быть скомпрометированы, так что никакая безопасность на них строится не должна — и не строится, см. HTTPS/SSL/TLS.
1С — конечно, лишь инструмент, но у меня есть ощущение, что сама экосистема 1С крайне проблемная. Тот факт, что отношения с разработкой у подавляющего большинства компаний начинаются с легкой коррекции учета в готовой конфигурации силами одного из тысяч безруких «программистов», портит весь рынок.
С одной стороны, рабочие конфигурации зачастую сильно и крайне костыльно изменены на момент прихода грамотных людей, а с другой стороны формируется устойчивый спрос на людей НЕ грамотных, так как «ну тут же только один отчетик изменить». И когда потом дело до ходит до комплексной автоматизации, во-первых нужно всё выкидывать и начинать заново, а во-вторых, нормальных исполнителей днем с огнем не сыскать, кругом сплошь специалисты по костылям и велосипедам.
К тому же, полная изоляция от мирового сообщества лишает 1С влияния как современных технических новшеств, так и импортных веяний в области управления проектами / культуры внедрения автоматизации / ведения бизнеса интеграторами. Не всегда это влияние было бы положительным, но тем не менее, в целом, его явственно не хватает.
Устройство нишевое, конечно, но определенные преимущества просматриваются.
Например, процесс обеспечения fault tolerance не зависит от прикладного кода, а это значит, что:
— Кривой апгрейд/патч софта не сломает FT
— Различные приложения защищаются одинаково, то есть пропадает необходимость обходить и вообще учитывать особенности конкретных реализаций HA/FT в разном софте.
— Можно защищать софт, не имеющий FT. На самом деле, тру-FT, когда данные не теряются вообще, переключение происходит мгновенно, и нет потери производительности, доступен далеко не всегда.
хотя бы по SMB ткнулся в сломанный терминальный сервер (даже если он вообще прав не имеет на этом RDSH), чтобы от его имени авторизоваться в любом сервисе, к которому разрешено делегирование (а их будет много, это ж терминальный сервер).
Поэтому, наверное SSO через CredSSP Default Credentials Delegation посчитали оптимальным в свое время. Ну, а теперь вот Remote Credential Guard.
https://docs.microsoft.com/en-us/windows-server/remote/remote-desktop-services/clients/remote-desktop-web-client-admin
А так вообще Kerberos вполне себе используется, но только для проверки подлинности сервера вместо сертификатов (если проходит Kerberos, кривой сертификат игнорится).
Еще начиная с 2016 есть режим Remote Credential Guard, но и клиент и сервер должны быть поддерживаемой версии, и это по сути дополнительная обертка над Kerberos.
Что касается лицензий — постепенно ПО переходит на облачную проверку лицензирования, пусть не всё сразу — но это в том числе те отличия, которые могут быть одним из аргументов при выборе нового / планировании апгрейдов. Вендоры всегда балансируют между защитой от пиратов и отказоустойчивостью, но, как правило, именно у «облачных» лицензий есть достаточно лояльный grace period, зачастую измеряющийся в неделях.
А USB ключи, наоборот, чаще проверяются многократно прямо во время работы защищаемого ПО.
Так что, зачастую, совсем уйти нельзя, но постепенно минимизировать риски возможно.
Мне гораздо больше нравится идея вытащить ключи ЭЦП с токенов и загружать в профили нужных пользователей на терминальниках. Сразу становится гораздо лучше с отказоустойчивостью. Безопасность при этом вполне обеспечивается разделением пространства терминальных сессий, для параноиков можно VDI. Уж точно не хуже сильно нестандартной железки, которая у вас, как я понял, вообще в интернет напрямую смотрит (!).
От лицензионных же ключей просто по мере возможности нужно уходить — отказы ключей 1С «на 300» случались, и такое по-быстрому не решается. При этом, программные лицензии при всей своей небесспорности, по-крайней мере, дают 2 попытки моментального восстановления. Кстати, их можно сейчас на аппаратный ключ завязать, скрестив ежа с ужом и обеспечив как возможность легкой замены железа, так и использование резервных PIN в случае отказа ключа.
До этого пару дней назад что-то похожее было с подсетей какого-то турецкого банка, который судя по турецким новостям в тот день тоже лежал…
Интересно, что это? Может, издержки маршрутизации? Для намеренной атаки совсем слабо.
Не, я не из идеального мира, но из мира людей, применяющих политики назначения прав пользователей, чтобы доменные админы не заходили случайно куда не следует.
Первую часть не понял. Петя собирает все что есть в lsass, а дальше если у вас из этого списка кто-то вхож на другие рабочие станции как админ, то Петя приезжает и на них тоже.
А чем плох встроенный администратор? Тривиально ведь найти на машине всех остальных. Разве что UAC у него выключен по умолчанию. Так ведь включить можно, да и вообще согласно Microsoft «UAC is not a security feature».
Именно потому что привилегии локального админа сравнительно легко достижимы, они должны быть изолированы в пределах одной рабочей станции. Иначе повысившись на одной станции можно по всей сети расползтись — что наглядно всем желающим и продемонстрировал NotPetya еще полтора года назад.
А еще что-то придумать для клиентов, которые не постоянно онлайн, чтобы не пропускали время запуска скрипта.
А также не забудьте открыть везде порты, чтобы COM-RPC работал с сервера, на котором скрипт запускается, к клиентам — а то по умолчанию, например, клиенты общаются с контроллером домена только в режиме pull.
Ну и как следует защитить учетную запись, от которой запускается скрипт — прав у нее в сети будет немало.
Или можно вместо всей этой головной боли использовать LAPS, официальное и поддерживаемое (бесплатное) решение от Microsoft.
NAT, конечно, оригинально, но…
Причем конкретные цифры никто не публикует, в отличие, например, от производительности IPS. А между тем, без расшифровки SSL DPI-фичи на 443 порту толком работать просто не будут, и весь NGFW превращается в тыкву.
Snom есть один (800й) тоже на LPE, с теми же ограничениями, а все остальные (700е) на собственной UC firmware, которую они перестали развивать осенью прошлого года, и из партнерской программы с MS вышли.
Так что из современных остались только VVXы, да Аудиокодес. По опыту ценник на них обоих заметно выше. VVX600 стоит около 30 000Р, а T48 — условно, 15. VVX310 — около 13 000, а T42 — 8 000. При этом свои грабли и тараканы в Поликомах тоже есть.
А отличие от гарнитуры есть — лучше качество звука, громкий спикерфон, можно звонить без компьютера, физические кнопки под рукой, ну и далее в том же духе. Насколько это необходимо, каждый решает для себя сам. У нас, например, большая часть абонентов обходятся без аппаратов, но какое-то их количество все равно нужно.
Есть один неприятный минус — нельзя нормально сохранить контакт с городским телефонным номером. Либо отображается один номер без имени, либо email-адрес и имя, но номера телефона вообще не будет. Можно, конечно, сохранить в локальные контакты, но это, во-первых, идеологически неверно, а во-вторых, при сохранении локального контакта почему-то не работает шикарная экранная клавиатура на 48ом. То есть имя-фамилию нужно набирать на цифровой клавиатуре.
Ноги этой проблемы растут, судя по всему, из полного отсутствия интеграции с контактами в Exchange, поэтому, видимо, и решить никак не могут.
В остальном довольно убедительные аппараты — интерфейс 48ого субъективно нагляднее, логичнее, и удобнее, чем у VVX600, и это при стоимости ниже, чем VVX410, который вообще сравнения в таком разрезе не выдерживает, ибо по меню замучаешься прыгать.
Особых глюков не замечено, основные функции все есть, качество спикерфона на уровне VVXов (!). Техподдержка на yealink.com отвечает, работает, и финскит потихоньку найденные легкие баги.
Snom от развития поддержки SfB отказались, так что из конкурентов остались недешевые Поликомы с отпиленным начисто в РФ SRTP, да Аудиокодес. Причем последние совсем не впечатлили, от интерфейса до качества звука.
В любой недоверенной сети DHCP и DNS могут быть скомпрометированы, так что никакая безопасность на них строится не должна — и не строится, см. HTTPS/SSL/TLS.
С одной стороны, рабочие конфигурации зачастую сильно и крайне костыльно изменены на момент прихода грамотных людей, а с другой стороны формируется устойчивый спрос на людей НЕ грамотных, так как «ну тут же только один отчетик изменить». И когда потом дело до ходит до комплексной автоматизации, во-первых нужно всё выкидывать и начинать заново, а во-вторых, нормальных исполнителей днем с огнем не сыскать, кругом сплошь специалисты по костылям и велосипедам.
К тому же, полная изоляция от мирового сообщества лишает 1С влияния как современных технических новшеств, так и импортных веяний в области управления проектами / культуры внедрения автоматизации / ведения бизнеса интеграторами. Не всегда это влияние было бы положительным, но тем не менее, в целом, его явственно не хватает.
Например, процесс обеспечения fault tolerance не зависит от прикладного кода, а это значит, что:
— Кривой апгрейд/патч софта не сломает FT
— Различные приложения защищаются одинаково, то есть пропадает необходимость обходить и вообще учитывать особенности конкретных реализаций HA/FT в разном софте.
— Можно защищать софт, не имеющий FT. На самом деле, тру-FT, когда данные не теряются вообще, переключение происходит мгновенно, и нет потери производительности, доступен далеко не всегда.