Friday, September 8, 2017

Juniper Space Security Director Policy Hit Counts Not Updated Automatically

Issue Symptons:
  • Normally, each firewall rule on the SRX auto-updates a snmp counter for hit-count, regardless of whether 'count' is configured or not.  Juniper Space Security Director periodically polls these OIDs and updates the hit-count.   
  • In Junper Space 16.1 R1, the issue found is unable to view policy hit counts from Juniper Space Security Director, but SRX itself is keep updating. 

Actions Taken:
  • Verify Security Appliance Policy Hits from Command line
[email protected]> show security policies hit-count 

Logical system: root-logical-system
 Index   From zone        To zone           Name           Policy count
 1       Vlan2              Vlan1        Baramondi_Monitor 0            
 2       Vlan2              Vlan1        10             4428         
 3       Vlan2              Vlan1        50             0            
 4       Vlan2              Vlan1        40             11136        
 5       Vlan2              Vlan1        default-logdrop 0            
 6       Vlan2              Vlan1        53             2007         
 7       Vlan2              Vlan1        54             0            
 8       Vlan2              Vlan1        55             0            
 9       Vlan2              MGMT              6              538          
 10      Vlan2              MGMT              23             0            
 11      Vlan2              MGMT              74             2            
 12      Vlan2              MGMT              default-logdrop 81           
 13      Office              Vlan1        default-logdrop 0            
 14      Office              Vlan1        60             447          
 15      Office              Vlan1        Office_Archive    0            
 16      Office              Vlan1        58             0            
 17      Office              Vlan1        Baramondi_Monitor-1 0            
 18      Office              MGMT              Office_Archive-1  0            
 19      Office              MGMT              default-logdrop 0            
 20      Vlan1       Vlan2               Baramondi_Rules 0            
 21      Vlan1       Vlan2               VA             0            
 22      Vlan1       Vlan2               A_Office_2_Vlan2    292          
 23      Vlan1       Vlan2               default-logdrop 1696         
 24      Vlan1       Office               VA-1           0            
 25      Vlan1       Office               Baramondi_Rules-1 0            
 26      Vlan1       Office               Device-Zone-1  0            
 27      Vlan1       Office               4              1299         
 28      Vlan1       Office               default-logdrop 0            

It is clearly there is hit counts on SRX itself, but they are not being pulled/pushed into Space. Log collecter has beenconfigured and it is receiving logs from this SRX.

  • Let Juniper Space manually probe latest policy hits
From Firewall Policies page, you can manually 

  • This is a known issue reported in 16.1R1 version and the workaround to resolve this issue is the following:

From Space CLI run the following command:

mysql -ujboss -pnetscreen sm_db -e "update RuntimePreferencesEntity set value='2' where name='POLICY_HIT_COUNT_MAX_SUBJOBS_PER_NODE';" 

Space release 16.1R2.7 (381623)

Last login: Fri Sep  8 15:27:35 2017 from

Welcome to the Junos Space network settings utility.

Initializing, please wait

Junos Space Settings Menu

1> Change Password
2> Change Network Settings
3> Change Time Options
4> Retrieve Logs
5> Security
6> Expand VM Drive Size
7> (Debug) run shell

A> Apply changes
Q> Quit
R> Redraw Menu

Choice [1-7,AQR]: 7

[sudo] password for admin: 
[[email protected] ~]# 
[[email protected] ~]# 
[[email protected] ~]# 
[[email protected] ~]# mysql -ujboss -pnetscreen sm_db -e "update RuntimePreferencesEntity set value='2' where name='POLICY_HIT_COUNT_MAX_SUBJOBS_PER_NODE';"
Warning: Using a password on the command line interface can be insecure.
[[email protected] ~]# 


First, identify which node has the vip (eth0:0).  Check each node with the following:
# ifconfig eth0:0
Recommended restart process (only if JBOSS restart is needed):
1.     Stop processes on all JBOSS nodes
# service jmp-watchdog stop
servicejboss stop
service jboss-dc stop
Note: jboss-dc is only active on VIP node, but the command won't do any harm

2.     Confirm if JBOSS has been turned off
# service jboss status

3.     Start services on the vip node
# service jmp-watchdog start
Note: watchdog starts other processes

4.     After you can login, start services on all of the other nodes
# service jmp-watchdog start

[[email protected] ~]# service jmp-watchdog stop
[[email protected] ~]# service jboss stop
found and stop jboss
[[email protected] ~]# service jboss-dc stop
stop domain controller
[[email protected] ~]# service jboss status
jboss is stopped
[[email protected] ~]# service jmp-watchdog start
jmp-watchdog running
[[email protected] ~]# ifconfig eth0:0
eth0:0    Link encap:Ethernet  HWaddr C6:18:6F:1B:3E:DB  
          inet addr:  Bcast:  Mask:

Notes: Just got confirmation. It is a bug and it wont be fixed until Juniper Space 17.2.

No comments:

Post a Comment

NetSec Youtube Videos