Subscribe to the Blog

Get articles sent directly to your inbox.

We have added audit log to give you visibility to who has changed what, where and when. We have made changes to help you create reports like device health posture, high availability readiness, security risks and vendor recommended best practices. We’ve added a cold-standby server in case the active primary server is lost, you can quickly activate the standby server.

Onwards to more tidbits about what’s changed with 6.4.9:

Audit log

An audit log is critical to understand what has changed and determine what may have caused interruption to a service. An audit log provides you visibility to changes to Indeni allowing you to restore service quickly.

We are pleased to announce audit logging for Indeni 6.4.9. The audit log stream is the admin activity log and user activity log. Admin activity log contains entries for actions that modify the service such as new backup schedule, disabling rules, changing thresholds, adding LDAP authentication, etc. User activity includes user logon attempts and logon failures.

Interacting with audit logs

You can see a high-level overview of all your audit logs from the user interface. Click on any entry to display a detail view of that event, as shown below.

audit log Indeni dashboard

The table below shows the list of audit log entries.

TypeAudit Log Entry
IssuesConfiguration created
Configuration changed
Rule disabled
AnalysisCustom report created/deleted
Custom report changed
DevicesDevice added/removed
Device changed
Device credential added/deleted
Device credential changed
Device suspended/resumed
Backup schedule added/deleted
Backup schedule changed
Label added/removed
Label changed
SettingsEULA accepted
License uploaded
Integration added/deleted
Integration changed
New LDAP group added/deleted
LDAP group updated
New user added/removed
User information changed
User login successful
User login failed
System upgraded

Custom Report Enhancement

In this release, we added templates to make it easier to create reports. Templates are effectively a list of rules that we group them to support a use case.

Use cases:
1) High Risk devices
This template consists of a sample list of issues where a device may require attention.
2) High Availability readiness
This template consists of a list of rules where Indeni verifies consistency among cluster members.
3) Regulatory Compliance/Security risks
This template consists of a list of common compliance and security rules to check for insecure protocols, password strengths, known vulnerabilities and generally security related best practices.
4) Vendor Best practices
These templates consist of a list of best practices recommended by Check Point, F5 and Palo Alto Networks. Implementing these recommended best practices can avoid unplanned outages.

The table below captures the default rules associated with each template.

TemplatesDefault Rules
High Availability RisksCluster down
OS version mismatch across cluster members
Network interface mtu does not match across cluster members
NTP servers used do not match across cluster members
Static routing table does not match across cluster members
OS name mismatch across cluster members
Bond/LACP interface down
Cluster has preemption enabled
Configuration changed on standby member
HA interfaces not receiving traffic
Timezone mismatch across cluster members
Cluster configuration not synced
Connected networks do not match across cluster members
Features enabled do not match across cluster members
Regulatory Compliance & Security risksNTP servers configured do not match requirement
DNS servers configured do not match requirement
OS/Software version does not match requirement
Users defined do not match requirement
LDAP fingerprint not trusted
Telnet is enabled on the device
SNMPv2c/v1 used
Repeated failed login attempts by a user
SNMP configured with community public
Hotfixes installed do not match requirement
Syslog servers in use
Weak cipher used with SSL profiles
Weak security protocol used with SSL profiles
Enforcing Strong Password Selection is not enabled
SNMPv3 is not enabled
SNMPv2 configuration security best practices are not applied
SNMPv3 is not configured according to the best security practices
Configuration Mismatch (Check Point Gaia)
Device is vulnerable to SWEET32
SSL Ticketbleed vulnerability (CVE-2016-9244)
Spectre and Meltdown vulnerable
Best Practices - Check PointAggressive Aging Enabled
Firewall policy in Initial Policy
No firewall policy loaded
pnote(s) down
No firewall policy loaded
In CoreXL a single core shouldn’t handle both interface interrupts and fw worker
RADIUS server uid is not 0
Signature update status
ClusterXL CCP mode mismatch across cluster members
CoreXL cores-enabled mismatch across cluster members
PBR rules mismatch across cluster members
SecureXL configuration mismatch across cluster members
Errors found in $FWDIR/conf/ipassignment.conf
Cluster ID settings conflict
Routes defined in clish/webUI are missing
Best Practices - F5 LTMAudit logging is disabled
Non-functioning geo-ip database
IP geolocation database not up to date
Virtual server using a TCP profile with a high idle timeout
Fallback host used in HTTP profile
SNAT pool near maximum allocated
Unencrypted cookie persistence profiles found
Self IP port lockdown is set to default
Compression profile gzip level too high
Service check approaching
iRule(s) uses the deprecated matchclass command
Weak cipher used with SSL profiles
Automap enabled
Default Action On Service Down used
Weak security protocol used with SSL profiles
Precompressed content-type found in HTTP Compression profile
Default node monitor is not configured
Best Practices Palo Alto NetworksHigh neighbor discovery (ND) cache usage
High utilization of generic dataplane pool
Logs are being discarded
Debug mode enabled
High log DB usage
Packet Drop Counter Increasing
User-Id Agent Down
URL Cloud not connected
Wildfire Cloud not connected

Cold Standby

The new cold standby feature is a technique for improving reliability and mitigating risks by preparing an idle backup in the event the primary indeni server fails for any reasons. Data from the primary system will be backup automatically and content is synced from the primary server to the standby server regularly. This is to ensure a quick switchover in case the primary server is unavailable for any reason.

For more information about the new cold standby capability, please refer to the Indeni 6.0 User Guide – Cold Standby.

As always, if you have questions or comments, we’re here to help.