Перейти к содержанию

Как сделать диапазон ip-адресов исключений?


Рекомендуемые сообщения

Здравствуйе! У меня такая проблема, после установки Administration Kit 8.0.2048, и создания ip-диапазонов, на электронную почту мне посыпались сообщения от источников бесперебойного питаня такого содержания:

 

Name : APC

Location : MK3

Contact : Unknown

http://"ip адрес APC"

 

Serial # : ZA0618004382

Date: 11/18/2009

Time: 09:19:16

Code: 0x0004

 

Informational - System: Detected an unauthorized user attempting to access the SNMP interface from "ip адрес моего сервера администрирования в домене"...

 

Можно ли как то занести эти ip-адреса в какой нибудь список исключений, что бы он к ним не обращался? Или вообще дело не в этом? может у кого то была похожая ситуация... =) Спасибо заранее!

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

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

http://forum.kaspersky.com/index.php?showt...138435&st=0

 

Пользуйтесь поиском по тому разделу или гугловским по форуму

Да и там быстрее ответят...

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

Пожалуйста, войдите, чтобы комментировать

Вы сможете оставить комментарий после входа в



Войти
  • Похожий контент

    • Max132
      От Max132
      Добрый день! Не могу найти функцию добавления нежелательного почтового ящика, с которого осуществляется спам-рассылка, в ksc 13.2
      Есть ли там функция спам-фильтра не только для файлов, но и для почтовых адресов?
      По сути нужно просто заблокировать почту , но я не вижу подходящего раздела
    • AArsen
      От AArsen
      Добрый вечер! 
      KESL 12.1 настроена политика запрет всего по категориям. 
      Правилом выше размещаю разрешение, выбираю определенные категории и в поле пользователей выбираю пользователей поиском из AD. 
      К сожалению разрешающее правило таким образом сформированное не работает, подскажите, пожалуйста, если реализовывали, как организовать белый список пользователей, которым разрешены некоторые категории из запрещенных?
      Условно идти от обратного, запрещая не всем сотрудникам, не подходит из-за большого количества пользователей



    • kudryavtcev.as
      От kudryavtcev.as
      Не активен блок "исключения из проверки в KES 12.3."  Сам раздел активен, но при переходе по кнопке настройка, чтобы настроить параметры, там все заблокировано. Статус замочка в родительской политике открытый. Дочерних политик нет. Что может быть?
    • Jamer
      От Jamer
      добрый. заметил, что при копировании длинных наборов (в данном случае АПИ , адреса кошельков)  вставляется из буфера эта запись, но внутри часть подменятся выражением "TRC20_Address", например.  qRaq6Y2QfVNdVXK03kkpuTRC20_Addresscxq5lmF5w. если дробить на мелкие части, то копировать и вставить можно. но целиком никак. помогите найти вражину. благодарю.
      FRST.txtAddition.txt
       
      Сообщение от модератора thyrex Перенесено из этой темы
    • KL FC Bot
      От KL FC Bot
      Серьезные ИБ-инциденты порой затрагивают многих участников, зачастую и тех, кто повседневно не занимается вопросами ИТ и ИБ. Понятно, что в первую очередь усилия сосредоточиваются на выявлении, сдерживании и восстановлении, но, когда пыль немного осядет, наступает время для еще одного важного этапа реагирования — извлечения уроков. Чему можно научиться по итогам инцидента? Как улучшить шансы на успешное отражение подобных атак в будущем? На эти вопросы очень полезно ответить, даже если инцидент не принес существенного ущерба из-за эффективного реагирования или просто удачного стечения обстоятельств.
      Немного о людях
      Разбор инцидента важен для всей организации, поэтому к нему обязательно привлекать не только команды ИТ и ИБ, но также высшее руководство, бизнес-владельцев ИТ-систем, а также подрядчиков, если они были затронуты инцидентом или привлекались к реагированию. На встречах этой рабочей группы нужно создать продуктивную атмосферу: важно донести, что это не поиск виноватых (хотя ошибки будут обсуждаться), поэтому перекладывание ответственности и манипулирование информацией исказят картину, повредят анализу и ухудшат позицию организации в долгосрочной перспективе.
      Еще один важный момент: многие компании скрывают детали инцидента в страхе за репутацию или опасаясь повторной кибератаки по тому же сценарию. И хотя это вполне объяснимо и некоторые подробности действительно конфиденциальны, нужно стремиться к максимальной прозрачности в реагировании и делиться подробностями атаки и реагирования если не с широкой публикой, то как минимум с узким кругом коллег из сферы ИБ, которые могут предотвратить похожие атаки на свои организации.
       
      View the full article
×
×
  • Создать...