5 ответов в этой теме

[LilIlyas]

Здравствуйте!

 

Установил агенты Dr.Web через инсталлятор каждый вручную, не по сети, на 20+ рабочих станциях, всё работало стабильно пару месяцев, но в один день рабочая станция пропала с "радара". IP адрес, hostname, пользователи Windows - никаких изменений не было в тот день, интернет на рабочей станции есть, ip-адрес пингуется, можно даже зайти в общие папки по сети, т.е. рабочая станция прекрасно себя чувствует, но вот что произошло с агентом (или может глюк какой то на сервере) и станция просто не отображается (обозначен серой иконкой, как будто станция не в сети). Так как впервые ставил сервер Dr.Web, не учел все тонкости и по глупости установил агенты без возможности их удаления, т.е. и самозащиту даже не отключить. Перепробовал способы через drwremover, инсталлятор которого есть в самом сервере - не удаляет, пишет про самозащиту. В целом компьютер работает стабильно уже месяц, но хотелось бы взять под контроль рабочую станцию обратно  .

 

Буду очень благодарен если посоветуете какие нибудь способы, я уже думаю может напрямую через витую пару их подключить между собой, серверный компьютер и рабочую станцию. Никак не понимаю почему он вдруг перестал его видеть. И буду отдельно благодарен если подскажите по каким критериям Сервер запоминает рабочую станцию и агента на нем, исключительно через IP и Mac адрес, или есть ещё показатели изменения которых могут выбить рабочую станцию с сервера.

 

p.s.

осознав свою ошибку дал возможность агентам удаляться, конечно надо было это делать раньше, но пришлось учится на своих ошибках, жаль что эти изменения коснутся моей проблемной рабочей станции, только тогда, когда она выйдет в сеть.

Сообщение было изменено LilIlyas: 28 Май 2025 - 00:11

[B.Chugunov]

Добрый день.
Отсутствие прав на удаление агента - это не ошибка. В плане ИБ это вполне себе оправданное действие. По крайней мере, если у Вас все пользователи на станциях имеют локальные права админа. 
Отсутствие связи агента с сервером - чаще всего гораздо меньшая проблема безопасности, чем возможность свободного удаления агента. Нужно просто уметь с этим работать и не впадать в панику =) 
В плане диагностики в первую очередь нужен C:\ProgramData\Doctor Web\Logs\es-service.log 
Можете скопировать оттуда в любой другой каталог и там открыть, посмотреть самостоятельно самые свежие события с пометками [ERR] или банальным поиском по "connect". Либо можете прилепить этот лог сюда. 
Ошибки подключения к серверу там будут явно видны невооруженным глазом. 
Пинги конечно хорошо, что ходят, но совсем не показательны. Правильнее проверять со станции до сервера через клиент Telnet в cmd:
telnet адрес_сервера 2193
Например:
telnet 192.168.1.1 2193 
Клиент telnet по умолчанию отключен и его нужно доустановить через штатные системные компоненты. Если не знаете, как это сделать, найдете в интернете с картинками за минуту. Перезагрузка станции для этого не требуется и все уже встроено в саму систему. 
btw, недоступность сервера по определенному порту конечно не единственная возможная причина отсутствия связи. Но если уж говорить про проверку маршрута и доступности сервера для агента, то так проверять правильнее. ICMP может вполне ходить, а вот порт TCP 2193 при этом может быть закрыт с любой из сторон.  

[LilIlyas]

В плане ИБ это вполне себе оправданное действие.

 

 

Это конечно да) Но новичку вроде меня так слепо доверять не стоило себе   

 

C:\ProgramData\Doctor Web\Logs\es-service.log 

 

 

Спасибо, я рассмотрю и может выложу сюда если не разберусь

 

Правильнее проверять со станции до сервера через клиент Telnet в cmd

 

 

По Telnet-у у меня возник вопрос касаемо его работы:
Установил Telnet через программы и компоненты на серверный компьютер, оттуда запустил команду telnet ip_проблемной_станции 2193 - 2193 это у нас DrWEB порт я так понимаю. Исходя из этого Telnet надо установить через программы и компоненты на проблемной станции тоже или нет? Просто у меня есть ещё десяток станций и я попробовал почти на всех прописать telnet 2193 и ни на один не подключился, хотя они стабильно работают и все подключены к серверу.

 

И в дополнении хотел уточнить - допустим если 2193 порт закрыт на проблемной станции, его можно как то открыть? Сегодня увы я не успел толком посмотреть на логи, но глянул на брандмауэр, который контролируется Dr.Web-ом, и исходя из этого если вопрос в порте то получится его как то "освободить"? 

Следуя инструкциям по открытию портов используя брандмауэр защитника Windows я добавил порт 2193, но результатов это как будто не дало. Или брандмауэр защитника Windows не в приоритете когда стоит Dr.Web?

[maxic]

LilIlyas, нет-нет. Вам с проблемной станции надо попробовать достучаться до сервера. Соединение инициирует не сервер, а агент, агент ищет сервер в сети и пытается на нем авторизоваться.

[basid]

Если на проблемной станции уже установлен PuTTY, то можно воспользоваться им. Телнет умееют и (гуёвый) putty и (консольный) plink.

В более-менее "свежей винде" (Windows 1809/Server 2019 и далее) можно и штатным curl-ом обойтись (подрезал вывод):

> curl -V
curl 8.9.1 (Windows) libcurl/8.9.1 Schannel zlib/1.3 WinIDN
Release-Date: 2024-07-31
Protocols: ... telnet ...
Features: ...

[B.Chugunov]

Правильнее проверять со станции до сервера через клиент Telnet в cmd

 

Сегодня увы я не успел толком посмотреть на логи

Это нужно сделать в первую очередь. Баловство с телнетом факультативно. Я просто посоветовал Вам, что на пинги обращать особого внимания не стоит. Вполне возможно, что дело совсем не в сетевой связности и порт открыт, а Вы занимаетесь диагностикой несуществующей проблемы и тратите время.