Comments 20
В качестве имени домена локальной сети, как правило, используется уже зарегистрированный домен сайта, почты и т.п.
Достаточно спорное утверждение. Гораздо чаще используются раздельные имена, IMHO.
От использования раздельных имён открывается отдельная уязвимость — кто-то может зарегистрировать этот самый "отдельный" домен, после чего "поймать" те же самые WPAD-запросы от какого-нибудь корпоративного ноутбука, оказавшегося за пределами домена.
Подскажите, как Вы себе видите регистрацию домена domain.local ?
Видимо, никак (а вот domain.lan может быть в будущем перехвачен). Если ноутбук оказался в вашей WiFi-сети, то можно перехватить DNS-запрос, но в таком случае ничего не помешает и HTTP перехватить без всяких настроек прокси.
С другой стороны, rfc6762 предписывает такие адреса резолвить через 224.0.0.251, что может открыть новый вектор атаки в каких-нибудь экзотических случаях. Кстати, а rfc6762 вообще кто-то следует?
Если внутри сети оказалось чужое устройство, то это печально. Особенно, если нет NAP/NAC или White-Listing. Поверхность атаки расширяется существенно. Но при грамотной настройке сетей и инфраструктуры ещё не смертельно.
rfc6762 - пришлось гуглить, даже не помнил про такой. Думаю, что .local это больше инерция и "традиция", чем осознанный выбор у многих.
Не туда
Согласен, у нас в компании имя домена тож различается.
под нормальным зарегистрированном доменом первого уровня (.ru, .com и т.д.), но организации, владеющей AD, не принадлежащим (не зарегистрированным или принадлежащим посторонним). Но чаще — таки да, используется домен второго уровня в фиктивной зоне верхнего уровня (.local, .loc и т.д).
А современная (AFAIK, но, по меньшей мере — недавняя) официальная рекомендация Microsoft — использовать домен, зарегистрированный на организацию, владеющую AD. Можно — тот же домен, что и для внешних ресурсов, организовав раздельное разрешение имен (split DNS).
Но следуют ей не только лишь все. Потому что, например, это создает трудности с доступом к своему же веб-сайту изнутри локальной сети, если сайт размещен где-то снаружи: контроллеры домена, если их специально не попросить так не делать (через настройку локатора имен контролеров домена в групповой политике), регистрируют на себя запись A с именем домена AD, и запросы на имя домена идут на них.
Легко сказать, что разработчики и администраторы обязаны защищать те или иные корпоративные ресурсы. Однако у этих специалистов совершенно другие функциональные обязанности и компетенции. Системный администратор — не специалист по информационной безопасности. Та же история с разработчиками.
Все таки «защищать»(хотя любой разработчик, который делает этот функционал, должен знать что нельзя использовать слабые алгоритмы хеширования, ну предположим что это осталось легаси 15 летней давности с MD5 каким-нибудь) и выкладывать в публичный доступ репозиторий с кодом и базой не одно и то же. Хуже могло быть только залитый готовый шел какой-нибудь или баннер на главной с логином/паролем от админки.
Поддерживаю. Если разработчики и системные администраторы вменяемые, то 1) будут использовать best practice решения 2) следовать политике информационной безопасности.
А если они творят такую дичь, как в статье ( база в гите, выставленные наружу тестовые среды в основном домене, репы, открытые снаружи всем ветрам) то, тут явно что-то не так с ИБ и с самими админами/разрабами. Либо с процессами.
Так что же можно было сделать для предотвращения этой утечки?
Разберём ваши рекомендации по пунктам:
1. Обязательно регулярно проводить внешние и внутренние пентесты. Тестирование на проникновение является необходимой мерой для предотвращения утечек;
- хорошая рекомендация, поддерживаю.
2. Автонастройка системного прокси через WPAD используется по-умолчанию в WIN10. Необходимо отключать этот функционал, если он не нужен;
- бить по рукам за такое сразу, отключать через GPO, верно.
3 .Необходимо запретить клиентам внутренней сети ходить на внешние ресурсы. Меньше прав - меньше проблем;
- а Вы точно ИБ компания? Может лучше дать людям работать, поработав сначала самим над настройками межсетевых экранов?
4. Необходимо контролировать целостность корпоративных ресурсов, а также наблюдать за логами доступа;
- Красиво сказано, но совершенно не раскрыто. Может быть речь про настройку и включение аудита и его мониторинг?
5. Необходимо настроить DHCP/DNS так, чтобы домен target.ru определялся, как ресурс во внутренней сети, а не во внешней.
- Использовать split DNS, либо если уж "так получилось", нормально настроить зоны пересылки
Если в файлах журнала имеются запросы следующего вида: /autodiscover.xml, /autodiscover/autodiscover.xml
- то кроме того, что кто-то ищет Exchange сервер с почтовым доменом, совпадающим с доменом сайта это ничего не значит.
Контроллер домена в службе активного каталога представляет из себя DNS и DHCP сервер.
Неверно. Контроллер домена в AD совсем не обязательно представляет из себя сервер DHCP, и наоборот.
Злоумышленник, контроллируя содержимое файла wpad.dat, может установить адрес внешнего mitmproxy сервера для модификации или пассивного прослушивания всего исходящего из корпоративной сети трафика.
И что? Mitmproxy, чтобы расшифровывать трафик соединения с сервером вынужен при установке соединения SSL/TLS предъявлять браузеру самопальный сертификат. И тут возникает вопрос — а почему это браузер должен доверять этому сертификату? Просто так браузер этому сертификату доверять не будет, сочтет его неверным, а для подключения к сайту с неверным сертификатом современные браузеры нужно довольно настойчиво уговаривать: пользователь этот процесс не заметить не может. А добавить эти сертификаты в список доверенных — это, вообще-то, требует отдельного взлома, контролировать wpad.dat для этого совершенно недостаточно.
Так что либо исправляйте статью, либо объясните, где именно я был не прав, либо ожидайте (его пока нет, но будет) минус к оценке за низкий технический уровень, вполне обоснованный.
Коллеги, давайте договоримся вести диалог в конструктивной форме. Если есть вопросы, то задавайте их корректно, пожалуйста. Впредь различного рода ультиматумы (объясняйте или поставлю минус), сомнения в компетентности или другие оскорбительные сообщения - будут игнорироваться. Мы не претендуем на звание "мистеров всезнаек" и можем где-то ошибаться. Все мы люди. Вы тоже где-то можете ошибаться. Помогите, подскажите, если мы где-то ошиблись - в нормальной форме. Все что мы пишем - основано на реальных кейсах. Ничего не выдумано именно с подобными вещами мы встречались в своей практике.
По поводу mitmproxy. Да, действительно сертификат используется самоподписанный. Никто и не говорил, что это стелс техника, но все же она работает. Когда браузеру подсовывается самоподписанный сертификат - он выдает диалоговое сообщение, мол "хотите или нет использовать сей сертификат". Как правило рядовые пользователи сети не обращают на это внимание (если сотрудников не обучали основам ИБ) и просто соглашаются использовать такой сертификат.
По поводу доменов типа some.local. Вы удивитесь но довольно часто компании используют локальный домен такой же как и внешний. Возможно вашей компании повезло и у них есть Вы. ) Но не каждый хороший сисадмин должен быть хорошим ИБшником равно как и наоборот. Системы усложняются и задача системного администратора следить за тем, чтоб стабильно работали сервисы обслуживающие бизнес процессы. Задача специалиста по ИБ следить за тем, чтоб на территорию не проникали злоумышленники. Опять же это все в общих чертах.
Если есть вопросы, то задавайте их корректно, пожалуйста.
Это были не вопросы, это были замечания.
Коли вы решили их проигнорировать — имеете право.
Как правило рядовые пользователи сети не обращают на это внимание
Не обратить внимание на предупреждения крупными буквами сложно. И уж, в любом случае, считаю, что нужно было хотя бы упомянуть, что проблемы могут быть только в случае явного пренебрежения теми правилами безопасности в интернете, про которые твердят на каждом шагу. Иначе ваш текст вводит в заблуждение: преувеличивает реальную опасность.
Вы удивитесь, но большая часть рядовых пользователей не обращают внимания на предупреждения и на автомате нажимают кнопку "Далее". Мы не пытались ввести в заблуждение никого. По нашей практике 30-40% процентов пользователей попадаются. Это достаточно большой процент. Но в какой-то степени вы правы. Позже доработаем статью и внесем ремарку.
Вы удивитесь, но большая часть рядовых пользователей не обращают внимания на предупреждения и на автомате нажимают кнопку «Далее».
Не удивился бы, но там теперь (по крайней мере, в Edge и Firefox) недостаточно просто нажать кнопку «Далее»: там нужно нажать не самую очевидную кнопку — «Дополнительно», а потом ещё и нажать на небезопасную ссылку где-то на странице. Сделать это на автомате, если по первому разу — это надо очень упрямый автомат иметь.
Да и не по первому разу. Меня, к примеру, эти манипуляции при отладке свеженаписанного веб-приложения обычно достают настолько, что я не ленюсь добавлять нужный сертификат (он там чаще самоподписанный) в корневые доверенные.
Утечка домена. Как мы получили доступ к корпоративной переписке через оставленный .git и wpad.dat