F5 Logging left on in BigDB

This is a real life sample alert from indeni

Description:

The logging database keys have been altered more than 60 minutes ago and have not been reverted to the default settings yet. Excessive logging for long periods of time may impact performance and stability.

Altered BigDB Logging Keys:

log.arp.level (Default: Warning)
log.config.level (Default: Error)

Manual Remediation Steps:

Revert the logging settings. Review SOL13455.

How does this alert work?

indeni checks the current setting of each database key relevant to logging. The current setting is retrieved by running “tmsh show running-config sys db <key>” for each key. If the settings are changed from the known defaults, an alert is issued.

Check Point Alert of the Week: Sync redundancy should use a bond interface, not separate interfaces

A different need for redundancy.This is a real life alert from indeni

Description:

Sync redundancy should no longer be implemented using separate interfaces. This signature has been made possible with the help of Valeri Loukine.

Manual Remediation Steps:

Replace the separate sync interfaces with one bond interface. Read SK92804 and CCMA’s blog post on this.

How does this alert work?

indeni uses “cphaprob -a if” to determine the NICs used in clustering. If two NICs show up as the sync (secure) NICs, the alert is issued.

Zabbix vs indeni Comparison. Proactive Monitoring vs Automated in-Depth Root Cause Analysis

Zabbix is a great tool. I’ve had the pleasure of encountering it at several of our customers’ sites and have seen it in action. It’s one of those tools that can really scale and give you the ability to see your entire estate – servers, database, network devices – and even quickly respond to certain events.

I’ve been recently asked “How does Zabbix specifically compare with indeni?” and thought I’ll spend the time to write up this post, in case others find it useful.

If one looks at the list of features on Zabbix’s website, they include this (as of Oct 29 2014):

Proactive Monitoring
Improve the quality of your services and reduce operating costs by avoiding downtime.

Looking more closely at Proactive Monitoring, you will find that Zabbix aids Proactive Monitoring by alerting (duh), allowing an automated response (nice), a means of escalating alerts (like forwarding an email), a way of recording notes on an alert (how is this proactive?) and useful information on the host (nice). In my view – none of this is proactive. To be proactive, you need to get notified (an alert) before something breaks and take action to solve it.

From Mirriam-Webster dictionary, Proactive means:
acting in anticipation of future problems, needs, or changes

So while Zabbix touts Proactive Monitoring, it does nothing of the sort. It doesn’t let you act ahead of future problems.

And THAT is the main problem indeni is solving for Zabbix users. indeni identifies problems before they result in downtime and lets users take action on them. We try to make indeni’s alerts as actionable as possible. Whenever we (or one of our users) see an alert isn’t actionable enough, we improve on it. At the end of the day, it’s all down to the knowledge base indeni holds.

Bottom line for Zabbix users: keep your existing system (and investment) going and add indeni to gain true proactivity. Don’t worry, indeni can report back into Zabbix (vis SNMP Traps) so you don’t need two dashboards.

Only one way to find out which tool is best. Try us out for free and see the difference in coverage and visibility only indeni can provide. 

Knowledge-Driven IT

At indeni, we’ve always been big believers in the need to use knowledge to get the job done. Since we’ve started, five years ago, we’ve built an impressive platform for consuming data and information and turning it into usable knowledge. Then, we’ve built a separate platform, that serves as the basis of the product installed in our customers’ environments, that utilizes that knowledge.

Both platforms are ever-expanding and changing, as our aspirations cause us to set higher and higher goals.

Today, I’d like to take the opportunity to announce our ultimate goal: Knowledge-Driven IT. It’s not just networks anymore, it’s anything related to making computing environments work flawlessly.

We believe information technology has evolved over the past few decades to the point it can no longer work with just a mix of humans and simple tools. The world’s knowledge must be put to work in an intelligent way to get the job done. To deal with the ever-growing gap between complexity of activity vs head count in the IT space, knowledgable systems must be produced.

indeni is the first solution to herald the arrival of the Knowledge-Driven IT. We’re excited to be pioneers in this space and hope to have others join us soon.

Let’s change the world!

Check Point Alert of the Week: Stateful Inspection disabled, possible security risk

This is a real life sample alert from indeni

Description:

The Stateful Inspection feature on this firewall has been disabled. Since Stateful Inspection is a core element of the behavior of modern firewalls, this may mean a severe security gap exists. For more information, read Why Turning Off Stateful Inspection On Your Check Point Firewall Is Bad on Hurricane Labs’ website.

This signature has been made possible with the help of Lindsay Hill.

Manual Remediation Steps:

Re-enable Stateful Inspection under Global Parameters. Be careful when doing so as it may break traffic that was allowed previously.

How does this alert work?

indeni connects to the servers managing the Check Point firewalls (SmartCenter / Security Management / Provider-1 / MDM) and parses the policy files (such as objects_5_0.C). It looks for the flag for the stateful inspection and if it’s false, alerts.

How to Keep a Bouncer Healthy – Comparing Algosec/Firemon/Tufin vs indeni

Many of our users work in the information security operations departments of mid-size to very large enterprises. As such, they regularly work with Check Point firewalls (which indeni supports), When you work with a firewall, you need to make sure the rule base matches the organization’s security policies.

To help with that, there are companies such as Algosec, Firemon and Tufin, that have developed solutions for monitoring changes in the rule base and building a workflow around the on-going work done with it. While I hope these companies will excuse me for referring to them as a group (I’m sure each of them considers itself as the best in class, rightfully so), we see them as a group because they fulfill a certain need.

indeni fulfills a very different need. The best way to understand it is to imagine the firewall being a bouncer at a party. The Algosec/Firemon/Tufin solutions help make sure the bouncer knows who to let in and who not to. indeni makes sure the bouncer stays alive, healthy, and can do his/her job.

Therefore, every user of Algosec/Firemon/Tufin should look into indeni. We are complimentary solutions that together ensure your firewall will achieve the security goals you have set for it while at the same time ensuring the firewall doesn’t become a source of traffic loss and downtime.

Note that there is one major difference in the way indeni is set up: indeni must be able to reach every single firewall on the network directly. Connecting to the management servers (such as Check Point’s Provider-1/MDM) is not sufficient for indeni to be able to truly analyze the health of the firewalls.

Another difference is that indeni isn’t directed solely at security devices. indeni can cover the networking aspects of routers and switches (not just ACLs) as well as devices like F5’s load balancers. Adding this entire variety of devices to indeni’s analysis engine will allow you to identify cross-device issues. For example, a Check Point firewall cluster failover can go very wrong if the routers around it are dropping GARP replies. We identify that as part of our on-going analysis and are unique in that capability.

Bottom line: if you are an Algosec/Firemon/Tufin customer, you should seriously look into indeni as a means of providing you an overall solution for getting your job done. It takes just 45 minutes to see indeni in action on your network.

F5 Node availability issue detected

This is a real life sample alert from indeni

Description:

Node availability issue detected. Please see additional information below.

Affected nodes:

10.10.16.20 (/Common/10.10.16.20) – the URL “/alivetest” returned error code 404.

Manual Remediation Steps:

You should inspect the node availability state and act according to it’s status.

For help on how monitoring of nodes works, refer to Configuring Monitors and SOL12531.

How does this alert work?

indeni checks the status of the monitors using “list /ltm monitor” as well as collecting data on its own directly (running a ping on the LTM device if the monitor is an ICMP one, running curl if the monitor is HTTP, etc.). This allows indeni to provide not only the status but also what has failed.

Check Point Alert of the Week: Certain 10Gb NICs in use may deliver slow performance

This is a real life sample alert from indeni

Description:

Certain 10Gb NICs on this device are using a driver known as IXGBE and a feature called Receive Side Coalescing. The version of the current driver used on this device is buggy and may result in slower performance. More information on the bug is available on Redhat’s website (Bug 680998) and Check Point’s SK102713.

Manual Remediation Steps:

Contact Check Point technical support and ask for the jumbo fix that resolves this situation. Mention SK102713 and SK62847.

How does this alert work?

indeni is kept up to date on immediate critical issues by scouring hundreds of different sources. In the case above, once the faulty driver was identified it was added to the list of issues to look for. indeni uses various outputs from ethtool (such as “ethtool -i”, “ethtool -c” and others) to determine that the problematic driver and feature is in use with the relevant NICs.

Bridgian and indeni joining hands in Minnesota

indeni is proud to be partnering with Bridgian as a Platinum partner in Minnesota.

Each week more and more customers, partners and distributors are approaching indeni to understand our new paradigm for keeping networks running. It is only with such visionaries as Pat Waters and Kate O’Shea at the helm of forward thinking Value Added Resellers can we realize the unprecedented explosion in interest we are now facing.

Bridgian has very quickly shown that being a VAR is not just about waiting for a renewal, but rather really understanding customer pain, and selecting from a wealth of products out there to help customers reduce that pain. Such vision from our partners has helped fuel our growth across the US and as such partnering with Bridgian is a natural step for us.

If you are considering proactive maintenance for your firewall and are based in Minnesota, I recommend giving them a call. Pat is always on hand to explain why every Check Point customer should be looking at indeni as well to make sure their organization gets the most stable security solution possible.

I am truly excited to be working with Bridgian in Minnesota to help bring a much needed new paradigm in network management to such an important market.

F5® Alert of the Week: BIG-IP device has changes pending synchronization

This is a real life sample alert from indeni

Description:

The configuration has changed but the changes haven’t synced between all devices in the group.
Here’s the ConfigSync sync status details:
/Common/jcnj-adc2.mycompany.com: connected (for 1660289 seconds)
/Common/device-grp1 (Changes Pending): Changes pending
– Recommended action: Synchronize /Common/jcnj-adc1 to group /Common/device-grp1

Manual Remediation Steps:

Sync the configuration by running “run sys config-sync” under tmsh.

This version of BIG-IP supports automatic syncing too. If you use that feature, you may want to ensure the synced configuration is saved. Refer to SOL14624.

How does this alert work?

indeni retrieves the current configuration sync status by running “tmsh show /cm sync-status”.