Решение хорошее, пользовались, но сравнение в заголовке не достаточно корректное.
GFI LANguard в данном случае более мощное средство, т.к. помимо общедоступных уязвимостей «по словарю» может проверять наличие (и автоматически устанавливать) обновлений и патчей, т.к. именно неактуальное ПО в большинстве случаев является целью для атакующих, а также проводить подробную инвентаризацию аппаратного и программного обеспечения с возможностью сравнивать результат с предыдущими отчетами для выявления несанкционированно установленного ПО или внешних устройств передачи данных.
Это я к тому, что запускать клевые сканеры, не значит делать что-то «защищенее», а иногда даже наоборот — делать что-то более уязвимым, и как примеры все эти навороты с «автоапдейтами» ЛанГуарда, Касперским или DLP системами, которые настроены на использование доменной учетки с привелегиями локального админа для рабочек/серверов в сети с NTLM 8)
Поэтому иногда лучше без этих изысков с «автообновлениями». Тем более, что никто, по хорошему, не даст ставить автоапдейты на продакшн сервера 8)
Потому и нужно использовать открытые операционные системы. Лучше Linux =)
Там нет NTLM, протоколы управления шифруются, ровно как и обновления проходят проверку при помощи PGP.
И можно держать свой локальный репозиторий, полностью контролируя сборку и версию различных пакетов.
Но почему именно админа-то? По идее большинство пользователей имеют обычные права пользователя. Ведь через их профиль и будет атака. А используя сканер с правами админа мы сами делаем щель чуть шире.
Но вот задал я вопрос одному товарищу с over 2000 линуксовых тачек в корпоративной сети такой вопрос.
Допустим где-нибуть у юзера заведется маленький несанкционированный самописный исполняемый модуль, будет сидеть себе полезное дело делать.
Что-то есть, что отреагирует на такую ситуацию?
Под винду, например, полуавтоматизированных систем антируткитового и поведенческого анализа хватает. (в силу того что ней традиционно повышен интерес).
Что используете на таком количестве linux-ов?
В силу четко очерченных прав пользователя, его самописный скрипт максимум в пределах его домашней папки порезвится. Насколько я знаком с Linux, права настраиваются более гибко и надежно нежели в винде. Имхо, конечно.
Уважаемый товарищ, сливший мне карму, поясните ниже, пожалуйста, что вас не устроило.
Что пассивный сканер в сети распознает подозрительную активность вне зависимости от операционной системы?
Или то что запрет на запуск из директории пользователя решает большинство проблем?
Я очень хочу почитать мнение эксперта в данном вопросе.
Я например выборочно сканирую по отдельным известным адресам с включением локальных проверок… Сканировать все подряд таким способом, все-таки слишком долго. А так как набор ПО на рабочих станциях и серверах стандартизирован. Если найдется проблема на 1, то она будет присутствовать и на других с большой вероятностью.
Что касается самого вектора атаки. То уж если случилось такое событие как проникновение хакера, и закрепление его в сети, такое что он сможет подкачивать себе спец софт на взломанную тачку. То это тушите свет. Способов и без релея найдется вагон и тележка, даже если не будет активных сканеров в сети.
Можно категорически не согласиться с настройками сканирования?
Вы используете только ICMP Ping, но отключаете даже TCP.
Админы часто отключают ICMP Echo-Request и вы рискуете исключить все важные объекты из списка сканирования.
При тестировании на проникновение хорошим тоном считается сканировать именно через nmap и не сканировать через ICMP.
Конечно можно не согласится. :)
В данном посте идет речь о сканировании именно своих сетей на предмет проблем. И вы, как владелец сети, наверняка знаете где ICMP включен, а где нет.
Естественно, если у вас запрет ICMP, то вы перенастроите Openvas под эти условия.
Ну, это да.
Только, на мой взгляд, при проверке нужно думать как хакер и действовать как хакер.
А то слишком предвзято получается.
В погоне за скоростью сканирования можно многое упустить.
Сегодня ставил копию сканера под любимым debian-ом.
При первом старте комманды openvas-certdata-sync выскочил косячок
cannot open /usr/share/openvas/cert/cert_db_init.sql: No such file
Решение простое blog.hikerell.com/index.php?load=read&id=4
Использование сканера уязвимостей OpenVAS