Indeni 6.4.9 is now generally available
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.
The table below shows the list of audit log entries.
| Type | Audit Log Entry |
|---|---|
| Issues | Configuration created |
| Configuration changed | |
| Rule disabled | |
| Analysis | Custom report created/deleted |
| Custom report changed | |
| Devices | Device 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 | |
| Settings | EULA 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.
| Templates | Default Rules |
|---|---|
| High Availability Risks | Cluster 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 risks | NTP 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 Point | Aggressive 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 LTM | Audit 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 Networks | High 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.