Предположим, что «Server-A» - это Windows Server v2008, который скоро будет физически выведен из эксплуатации.
Предыстория: нет никаких сведений о том, использует ли кто-либо сервер-A или нет. Нам нужен список, чтобы связаться с потребителями-клиентами, чтобы получить их согласие перед выводом из эксплуатации. Учитывая это, как нам собрать активную инвентаризацию зависимостей с точки зрения веб-запросов, обращений к папкам, триггеров заданий и т. Д.?
(1) Я могу сослаться на журнал IIS, чтобы получить список клиентских запросов, если сервер используется в качестве веб-сервера. Есть ли другой способ дважды проверить веб-запросы и где я могу собрать соответствующие данные, такие как IP, DNS, время последнего запроса так что.
(2) Аналогичным образом, как мы можем проверить использование общих папок? Я имею в виду, имеет ли какой-либо клиент / приложение / задание доступ к общим папкам, созданным на сервере-A? Есть ли функция аудита?
(3) Как мы можем отслеживать триггеры для запланированных заданий на сервере A? Да, можно сослаться на журналы заданий. Есть ли сервер Windows, который позволяет нам эту информацию?
Будем признательны, если кто-нибудь поделится лучшими практиками для этих сценариев.
Если это то, что вам нужно делать на регулярной основе, я бы порекомендовал инструмент сетевого анализатора. Их на рынке несколько. У меня есть опыт ExtraHop.
По сути, эти устройства находятся в вашей сети и втягивают каждый пакет, который проходит через ваши коммутаторы (вы подаете его через свои коммутаторы или отводы ваших исходящих каналов). Затем они дают вам полное представление о том, что происходит в сети для любого хоста в вашей сети. (некоторые могут делать гораздо более причудливые вещи, чем это).
Если что-то вроде сетевого анализатора выходит за рамки вашего бюджета (а это будет для многих малых и средних предприятий), вы можете включить NetFlow на своем коммутаторе. Для небольшого хоста вам потребуется довольно регулярная выборка, но, по сути, если у вас есть что-то, потребляющее пожарный шланг NetFlow, вы можете получать отчеты о сеансах, которые видит коммутатор.
Это даст вам обзор потоков в сети, чтобы вы могли видеть, что хост A потреблял 50 Мбит / с трафика на хост B в течение определенного периода времени. (Если у вас есть NetFlow полностью вниз, вы даже можете увидеть, куда ушел трафик после того, как он покинул хост B, если хост B - это устройство, которое перенаправляет трафик).
Это не даст вам понимания, которое может дать инструмент сетевого анализа, поскольку эти инструменты выполняют глубокую проверку пакетов и просматривают имена пользователей, запрашивают данные и т. Д. Но это отличное начало, когда вы идете вслепую и не знаете, что происходит. в сети.
Позвольте мне попытаться ответить на ваш вопрос:
1) Не уверен, почему вы спрашиваете об этом, поскольку вы уже знаете, что можете ссылаться на журнал IIS, и большая часть запрошенной информации там (исходный IP-адрес, время последнего запроса). В качестве альтернативы вы можете попробовать использовать Wireshark для захвата номера порта веб-службы, как предлагается в №2.
2) Вы можете попробовать использовать Wireshark для захвата следующих портов, используемых общей папкой Windows (SMB).
TCP: 139 445
UDP: 137 138
Установите программное обеспечение на сервер для захвата трафика. Вы можете получить помощь Вот на фильтре захвата Wireshark.
3) Не уверен, какие подробности вы запрашиваете, но задания расписания можно найти в Планировщике заданий в Windows, дату и время последнего запуска, статус последнего запуска, историю и другую информацию.
Надеюсь, мой ответ поможет :)
Есть ли другой способ дважды проверить веб-запросы и где я могу собрать соответствующие данные, такие как IP, DNS, время последнего запроса и т. Д.
Журналы IIS - правильное место для поиска этого. Только убедитесь, что все приложения их пишут (иногда отключаются).
(2) Аналогичным образом, как мы можем проверить использование общих папок?
Самого (простого) аудита не существует (кроме журналы аудита), но вы можете использовать Get-SmbConnection регулярно проверять (использование здесь).
Как мы можем отслеживать триггеры для запланированных заданий на сервере A?
Вы можете просто посмотреть запланированные задачи (и их историю). Нет функции «показать мне все удаленные триггеры, которые указывают на меня», это было бы немного сложно.