Как узнать, когда в последний раз использовалась политика брандмауэра JUNOS SRX
Есть ли способ узнать, когда в последний раз использовалась политика в брандмауэрах JUNOS SRX?
Мне нужно удалить устаревшие политики с устройства. Одним из способов является сравнение количества попаданий двух снимков, которые были сделаны в промежуток х дней. Но я чувствую, что это очень грубый способ делать вещи.
1 ответ
Я проверял CLI, но мы можем получить максимально возможное количество обращений (что не является показателем последнего использования политики)
Может быть, вы могли бы иметь вспомогательные файлы журнала только включая журналы RTFLOW SESSION CREATE
Затем периодически может запускаться сценарий "Входящие" и обновлять файл с содержимым "политика-имя-последняя-наблюдаемая-метка времени".
Эти журналы также будут включены в "сообщения", но, если брандмауэр довольно занят и генерирует много системных журналов, мы можем потерять некоторую информацию, если junos сжимает файл сообщений из-за достижения максимального размера (если мы не запустим скрипт очень часто… но как насчет воздействия на устройство?)
Потенциально это может сработать, но у меня есть некоторые опасения:
- Влияние на устройство с точки зрения производительности
- Если SRX много работает, вспомогательный файл журнала будет заполняться быстрее, а выполнение скрипта будет длиться дольше
- Это будет работать только с "сейчас" (поскольку мы реализуем сценарий), я не вижу прошлого, я думаю
- Ведение политики требуется для политики (по крайней мере, сеанс init или закрытие сеанса, чем создание файла журнала с правильными сообщениями системного журнала). Альтернативно, сценарий находится в автономном режиме, и мы периодически получаем вспомогательный файл журнала с внешнего сервера; таким образом мы берем на себя задачу разбора файла журнала на устройстве, поскольку вся "грязная работа" будет выполняться нашим внешним сервером (этот подход требует, чтобы наше устройство было доступно с помощью модуля SCP python, который доступен в PyEz упаковка)