SRX Services Gateway
SRX Services Gateway

Alarm/notication around schedule srx policy

‎02-10-2018 06:45 AM

Im sure most of you that works with firewall have come across all this rules that was done like 5 years ago that was supposed to be temporary (have comments like will be removed after 20/2 2012 etc) Im looking into using the schedule future for srx policys to at least have some way of reduce them in the future. But from what i have seen they dont make any kind of larm in the logs when the date has expired?

It would be good to have some kind of alarm that can send a email when the rule is expired so it can be removed from the ruleset. 

Do i need some kind of slax script for this or is it possible to turn on logging when rules are expired?

4 REPLIES 4
SRX Services Gateway

Re: Alarm/notication around schedule srx policy

‎02-10-2018 08:04 AM

You can use policy schedulers to activate and then turn off a policy on specific date/times.

 

set schedulers scheduler NAME start-date 2018-03-01.00:00 stop-date 2018-04-01.00:00

set security policies from-zone green to-zone red policy NAME scheduler-name NAME

 

 

Steve Puluka BSEET - Juniper Ambassador
IP Architect - DQE Communications Pittsburgh, PA (Metro Ethernet & ISP)
http://puluka.com/home
Highlighted
SRX Services Gateway

Re: Alarm/notication around schedule srx policy

[ Edited ]
‎02-10-2018 08:33 AM

Oh when i saw my message now i see how unclear i was, sorry about that.

 

Yes i know of that future, what i mean that i was wondering if there was any way to also have an alarm/loggmsg when the scheduele of the policy has reached its end date. Or is there a logg msg generated per default that i have missed?

SRX Services Gateway

Re: Alarm/notication around schedule srx policy

‎02-11-2018 09:24 AM

Interesting question.  I ran a quick test in my lab and confirmed your findings that the standard scheduler does not log to the messages queue.

 

It does log to trace options if they are enabled.

set security policies traceoptions file policytrace.log
set security policies traceoptions flag all

 

scheduler:

set schedulers scheduler TEMP start-date 2018-02-12.00:08 stop-date 2018-02-12.00:10

 

Logs:

show log policytrace.log
Feb 12 00:08:18 Scheduler callback TEMP at time [1518394080]
Feb 12 00:08:18 Activating policy [5], flag [1]
Feb 12 00:08:18 policy_ui_entry_get_by_id: Get policy 5 in lsys 0
Feb 12 00:08:18 Looking for Activating scheduler TEMP with next time 1...
Feb 12 00:08:18 scheduler [TEMP] currently started, need a stop.
Feb 12 00:08:18 Activating scheduler TEMP with next time [1518394200] type[1]
Feb 12 00:08:18 Scheduler callback setting : TEMP at time [1518394200]
Feb 12 00:10:18 Scheduler callback TEMP at time [1518394200]
Feb 12 00:10:18 Activating policy [5], flag [0]
Feb 12 00:10:18 policy_ui_entry_get_by_id: Get policy 5 in lsys 0
Feb 12 00:10:18 Looking for Activating scheduler TEMP with next time 1...
Feb 12 00:10:18 scheduler [TEMP] currently stopped, need a start.

 

trace logs can be sent to syslog that you have configured under system by adding this to the same address

set system tracing destination-override syslog host 192.168.1.1

 

The operational commands show the current status of any schedulers

 

Before it is used but still pending:

root@none> show schedulers
Scheduler name: TEMP, State: inactive
  Next activation: Mon Feb 12 00:08:00 2018

 

during the schedule
root@none> show schedulers    
Scheduler name: TEMP, State: active
  Next deactivation: Mon Feb 12 00:10:00 2018

 

when no longer pending per schedule

root@none> show schedulers       
Scheduler name: TEMP, State: unused

 

Steve Puluka BSEET - Juniper Ambassador
IP Architect - DQE Communications Pittsburgh, PA (Metro Ethernet & ISP)
http://puluka.com/home
SRX Services Gateway

Re: Alarm/notication around schedule srx policy

‎02-11-2018 10:14 AM
Hmm, we want this on our big clusters with over 10k rules. Im not sure having traceoption enabled like that is such a good idea? It seems like there needs to be some kind of script that regular goes and check for disabled scheduales nd then generate a log

It would be good to have some kind of larm so we remember to remove them from the policys for real.