Комментарии 47
Великий китайский файервол заблокировал ESNI, а мы по старинке перебираем IP? Нет, спасибо, все что явно не разрешено — запрещено. Хочешь HTTPS до сайтов кроме списка — обоснуй, добавим.
С технической стороны на «почему?» босса разумно предоставить Allow List, расчетную стоимость обслуживания каждой записи и коммерческое предложение DPI.
С организационной стороны, разумно рекомендовать боссу издать приказ с запретом и установить ответственность за нарушение.
Ngfw Вам в помощь, нет денег на оборудование — пускай сами еб@ться с этим. В крайнем случае можно что то на виртуальной намутить типа usergate или ideco
Тогда проще сразу весь интернет заблокировать, ведь 99% сайтов работать и так не будет.
Обычно такой подход (белые списки) показатель или ну очень сильно заточенной на безопасность организации или признак «мамкиного админа», который в книжках за 1997 год прочитал «про это», а на практике так и не пробовал (никого не хочу обидеть).
Вы попробуйте разрешить работу с каким-то сайтом, где публикуются журналы (платная подписка). Там, чтобы показать вам контент, данные подгружаются с большого количества других доменов. Причем половина из них — технические домены и их имена могут меняться (cdn). Я уже молчу, что на нужных по работе сайтах будут ссылки на ютуб и прочие общие сайты (которые нужны пользователю, заходящему на этот сайт).
При современном интернете (доступном с любого утюга) запрет на посещение левых сайтов может быть продиктован только безопасностью. А это решается значительно дешевле, проще, быстрее и лучше, чем белые списки (особенно с cdn, ага)
Правильный вариант (имхо) — мониторинг ПК сотрудников + орг. выводы
Люди должны понимать, что так делать нельзя, а если не понимают, то надо выявлять и показывать, что так делать нельзя
Метод linux админа — «а че, у вас можно запускать всяку херь, не прописанную в selinux?»
Метод MTCRE или CCNA — «а че, у вас __снаружи__ на х.з. какой порт клиента может коххектится х.з. кто х.з откуда?»
После того, как я в своей жизни прошел все 3 метода, я пришел к 4-му.
«Шеф, это не техническая, это административная проблема! Зачем они это делают? Ну не фильмы ве они смотрят, а работу работают. Шеф, ты порешай вопрос, почему в рабочее время народ не успевает сделать работу.»
Метод MTCRE или CCNA — «а че, у вас __снаружи__ на х.з. какой порт клиента может коххектится х.з. кто х.з откуда?»
Так ведь это же исходящее соединение от софтины на компе до сервера разработчиков софтины. И уже к серверу подключаются клиентом. Соответственно, сетевое железо это не посчитает входящим соединением и не отрежет.
мне больше нравятся два других способа:
- Установить приложение удаленного доступа, прописать пароль для подключения и запретить удалять приложение, изменять настройки и подключаться с другим паролем. Пароль никому не сказать
- Запретить пользователям установку приложений и разрешить запуск приложений только из тех мест, что разрешены
Но чаще всего проблема возникает с «необычными пользователями» — разработчиками/программистами/техподдержкой и пр. Тем, кому приходится давать права на запуск от админа (в том или ином виде). Не все разработчики, даже в 2020 понимают, что программа не должна требовать прав админа для своей штатной работы. Например, медицинские программы, идущие с дорогим оборудованием вообще, по ощущениям, писались студентами на коленке в год выхода windows xp.
Это не техническая, а административная проблема. Решается мониторингом запущенных процессов/портов и соответствующими оргвыводами
…
и мониторить выполнение приказа.
Смотрите, статья соответствует теме (хотя ProcessMonitor-ом и скриптом это бы нашлось быстрее и универсальнее). А вот комментарии говорят о том, что не все понимают, что это не механизм обеспечения запрета удаленного доступа. Это частная задача. Невозможно техническими средствами гарантированно ограничить удаленный доступ к своему ПК в обычной корпоративной сети* *(без dlp и прочего).
Количество стороннего ПО, которое может предоставлять доступ к ПК много. Оно появляется ежеминутно. Достаточно просто погуглить и установить его просто «накликав». Более того, есть сырцы того же vnc, которые скомпилировать сможет и школьник (со своим портом и названием процесса). Таким образом, выбирать «любимчика» (как сказано в статье) — это решение частной задачи, не имеющей никакого отношения к ИБ. Умные «несогласные» выберут редкоиспользуемый софт, на который никто не обратит внимание. Кстати, известный софт удаленного доступа более безопасен (с точки зрения его неправомерного использования третьими лицами), нежели кустарные поделки.
Кроме того, сейчас большое количество ПО имеет или может иметь встроенный функционал удаленного доступа. Банальный пример — хром. Сейчас скайп позволяет демонстрировать свой рабочий стол. А кто гарантирует, что при обновлении версии скайпа не станет доступна возможность управлять этим столом? А тот же зум?
Один из главных механизмов обеспечения безопасности это административные меры. Кроме шуток. А для того, чтобы люди относились к этому серьезно — есть механизм контроля по выполнению этих мер. Это мониторинг. После нескольких разговоров с руководством, «неспрошальщики» перестанут делать глупости.
ps блокировать по ip это плохой вариант, т.к. anydesk может в любое время что-то поменять в своей cdn а вы потом будете искать — почему не открывается какая-то менюшка рабочего сайта
, дейстивие. Про печальный опыт блокировки могу поделиться, как-то блокируя ссылки вредоносных сайтов дошли мы до серверов amazon, и сразуже вылезли прблемы с Viber-ом. Нет абсолютных вариантов решения проблем, это как игра в шашки, раз-два и ты ничего не понял как это получилось (и проиграл:)… Шахматы отдадим почтовым системам.
Про pfsense и не только — forum.netgate.com/topic/120102/proxmox-ceph-zfs-pfsense-и-все-все-все/
Зы. Для блокировки по ДНС достаточно завернуть все dns запросы от клиентов на адрес pfsense. И уже на нем запрещать доступ. Но остается вопрос с DoH.
У них для этих целей выделено специальное доменное имя:
relays.net.anydesk.com
оно резолвится в 391 ip-адрес специально чтобы нам удобнее было блокировать работу Anydesk'а))
В 2022 попробовал - уже не резолвится.
Нашел так - https://www.virustotal.com/gui/domain/relays.net.anydesk.com/relations
А почему вы для ip-адресов AnyDesk прописывали несуществующий маршрут, а не добавляли блокирующее правило дла фаерволла (netsh..)?
сути процесса не меняет,
но моя причина чисто "религиозная": как только начинаются проблемы на машине сразу освобождайся от антивируса и файрвола :) - это нормальные условия для тестирования.
история с маршрутами более топорная НО рабочая,
кстати прикладная программа может себя в файрволе добавлять в исключения, тем более программа такой направленности (+ проблема моей лени + и тимвиер я так "шлепал" и сбросить если что все маршруты могу до адекватного состояния)
Кстати, не знаете как в Windows из консоли добавить программу в исключения системного фаерволла? Можно в личку.
netsh advfirewall firewall add rule name="My Application" dir=in action=allow program="C:\MyApp\MyApp.exe" enable=yes
взято с самого.... https://docs.microsoft.com/ru-ru/troubleshoot/windows-server/networking/netsh-advfirewall-firewall-control-firewall-behavior
думаю с action Вы разберетесь.......
применение подобного это хороший прикладной уровень, кстати сейчас всех присаживают на PowerShell - меньше неожиданностей,
а системные утилиты уже делают из версии в версию несовместимыми, соотвенно если программа написана "правильно" можно незаметно ядро подменить программе, и она ничего не почувствует.
А наши хитрости - это заплатки на тонущем корабле - эффективные, но не для каждых.
Анализ возможности блокировки приложения для удаленного управления компьютером по сети, на примере AnyDesk