Циска тут осталась слегка за кадром, вы правы ) Powershell же здесь показан подробно как средство для решения основного вопроса — получения списка хостов.
Хочу заметить, основная идея данного топика — метод нахождения и последующей блокировки всех узлов Teamviewer, не более, но и не менее. Это первая публикация такого рода в интернете, до этого никто не задавался общим решением вопроса — в имеющихся ветках на форумах перечисляются только частные списки айпишников (которые, тем не менее, могут работать, о чём я сказал в тексте).
Вы правы, исторически юниксы были изначально заточены под администрирование из командной строки, и винда здесь в догоняющей позиции. Те же регэкспы появились только в powershell'е, а в юниксах они десятки лет. Да и иногда всё равно удобнее распарсить текстовый файл sed'ом.
Однако вот то, что по конвейеру передаются не просто текстовые данные, а объекты, со всеми их свойствами, у меня даже сейчас всё так же вызывает чувство радости типа «ух ты!». Хотя вроде уже и несколько лет прошло, а всё равно иногда радует. Не холивара ради, просто очень уж удобно.
Сейчас попробовал прямо в командной строке
> del 1.txt
> for /L %i in (1,1,16) do @ping -n 1 master%i.teamviewer.com | find «teamviewer.com» >> 1.txt
> del 2.txt
> for /F «tokens=2 delims=[]» %i in (1.txt) do @echo %i >> 2.txt
И на сортировке задумался — выбросить дубликаты, кажется, будет сложновато.
Также пинг дает единственный адрес хоста. Нужно разбирать вывод nslookup и подумать, как отличать Address от Addresses.
Так что беру cmd-шный for обратно — тут с нормальным скриптовым языком все проще будет.
скайп легко закрывается, если в инет разрешить только 80 порт через прокси, NAT udp и https не делать, кому надо скайп — открывать https на прокси.
торренты легко режутся на циске, объявляем нужные порты в class-map, выставляем нужные параметры в policy-map, в этом же policy-map создаем class-default и делаем ему скорость через police.
Шутите? Виндовыми средствами, конечно, можно соорудить политики по запуску, но, почитав, как народ массово с этим мучается, даже думать не хочу в эту сторону. Это геморрой и на этапе первоначального сбора хэшей, и при каждом обновлении софта. Могу ошибаться, конечно.
Ну, во-первых, чтобы пустить teamviewer через прокси, пользователю всё-таки нужно приложить кое-какие усилия (мы говорим про пользователя, поймите). По умолчанию программулина всё-таки ходит напрямую.
Во-вторых, мне не приходит в голову какой-либо метод общего вида, позволяющий узнавать, что вот такое-то соединение идёт через прокси. При необходимости придётся глушить адреса руками поодиночке, и это, да, сложнее, вы правы. Но это уже совсем-совсем другое дело и другой разговор.
проще всего принудительно всех на свой прокси зарулить. если с этим проблемы, то можно нетфильтром (iptables) резать соединения по проскакивающим в нём строкам — там прям открытым текстом много характерных строк вызелает. вот один пакетик из сессии для примера
Любопытный пакет, прямо-таки html-страничка в миниатюре. Спасибо, содержимое я не копал.
А на свой прокси всех зарулить — идея. Хотя на прошлой работе отдельные продвинутые пользователи ходили через всякие веб-анонимайзеры, и корпоративный прокси этому превентивно помешать не мог, поскольку браузер-то честно шёл через него.
Сейчас пытаюсь сообразить, а можно ли пройти через один (жестко заданный, корпоративный) прокси на другой? Ну, в смысле, не через браузер, а по портам. Хотя вон, Tor и Skype умеют.
анонимайзеры регэкспами блокируются, есть опубликованные большие списки.
Сейчас пытаюсь сообразить, а можно ли пройти через один (жестко заданный, корпоративный) прокси на другой?
вообще говоря да
у прокси-серверов есть метод CONNECT который не проксирует HTTP запрос, а просто открывает соединение к указанному адресу и порту, которым может быть порт следующего, каскадного прокси-сервера. чтобы такого не было, этот метод по дефолту оставляют разрешённым только для того, для чего он действительно жизненно необходим — это HTTPS, порт 443. поэтому-то этот порт так горячо любим всякими скайпиками, тимвиверами, торами, бесплатными открытыми опенвпнами — он обычно пролезает через прокси. я и сам так опенвпнился к своему серву, когда в билайне работал.
однако и у этой проблемы есть решение — ставят модуль к прокси-серверу, который подменяет SSL-сертификат и разбирает соединение на лету, эмулируя этот метод. решение так себе — и все серты сразу инвалидными становятся, и персональные сертификаты не будут работать, и приватность пользователя нарушена — но дело будет сделано.
Не знаю, как остальные браузеры, а Firefox сейчас вместо ругательств на неверный сертификат теперь стал просто блокировать такие адреса. Подозреваю, что Хром, Опера и даже IE тоже подтянутся, а может быть, кто-то и обогнал давно Мозиллу в этом в вопросе. Так что увы, это решение с подменой сертификатов скоро накроется, если ещё не.
Я вот думаю, а не собрать ли «белый список» сайтов с https, закрыв для остальных 443 порт нафиг? Крайняя мера, конечно.
ну или так, или же можно установить клиентам в браузеры свой удостоверяющий центр и тогда уже либо подписывать на лету сгенерённые доменные сертификаты, или использовать сертификат на очень широкий wildcard-домен — тут от конкретного софта зависит
Так правила-то отключаемые, в этом вся и вкусность. Зашёл на циску, деактивировал пункт, и соединения снова проходят. С удалением или блокировкой запуска программ так гибко и оперативно сделать не получилось бы.
Ай, там с оргстороны беда и разлад в этом вопросе. RDP предлагали (сами-то через него подключаемся), не понравилось. Программер сторонний, менять его бухгалтерия не даёт — это к вопросу про то, что работать с такими людьми не стали бы. Не будем о грустном.
Возвращаясь к политикам запрета запуска программ по хэшу — действительно можно отключить некий пункт и на клиентских машинах всё заработает через полминуты и без перезагрузки? Нет, правда интересно, просто по имеющимся описаниям это что-то громоздкое и неуклюжее.
«дать бухам почитать про трояны мониторящие клиент-банки и ворующие эцепешные ключики, и ненароком поинтересоваться, кто из них несет ответственность в случае «неправильного перевода на неизвестный счет»»
может и есть исключения, в 95% случаев бух ответит, что виноват будет сисадмин, который не проконтролировал, не обеспечил, не среагировал и т.д. и т.п.
я к безопасности и доступу в сеть извне подхожу по-другому:
1) запретить всё
2) подумать — нужно ли что-то?
3) обсудить и потребовать много бумажек на тему «нам нужно это, откройте пожалуйста»
4) подумать как бы не открыть лишнего
5) открыть только нужные приложения
собственно тогда вопрос «нужно закрыть приложение_Х» решается несколько проще :)
Как один из вариантов можно выпускать бухгалтеров через прокси, NAT им отключить. Оставить NAT лишь для клиент-банков на какие-то определенные destination-ip.
Автор виндовый админ? Чего-ж тогда ISA-сервер с клиентскими частями не настроите?
На ISA-firewall-е добавляете правило по ИМЕНИ ПРИЛОЖЕНИЯ и включаете/выключаете когда надо.
Teamviewer, powershell и циска