| Octopussy | |
| Developer: | Sebastien Thebert and others |
| Released: | December 2005[1] |
| Latest Release Version: | 1.0.16 |
| Latest Release Date: | [2] |
| Programming Language: | Perl, ASP |
| Operating System: | Linux |
| Genre: | Log analysis, security software |
| License: | GPLv2 |
Octopussy, also known as 8Pussy, is a free and open-source computer-software which monitors systems, by constantly analyzing the syslog data they generate and transmit to such a central Octopussy server (thus often called a SIEM solution).[3] Therefore, software like Octopussy plays an important role in maintaining an information security management system within ISO/IEC 27001-compliant environments.
Octopussy has the ability to monitor any device that supports the syslog protocol, such as servers, routers, switches, firewalls, load balancers, and its important applications and services. The main purpose of the software is to alert its administrators and users to different kinds of events, like system outages, attacks on systems or errors in applications.[4] However, unlike Nagios or Icinga, Octopussy is not a state-checker and therefore problems cannot be resolved within the application. The software also makes no prescription whatsoever on which messages must be/must not be analyzed. As such, Octopussy can be seen as less powerful than other popular commercial software in the same category (event monitoring and log analysis).[5]
Octopussy is compatible with many Linux system distributions like Debian, Ubuntu, OpenSUSE, CentOS, RHEL and even meta-distributions as Gentoo or Arch Linux. Although Octopussy was originally designed to run on Linux, it could be ported to other Unix variants like FreeBSD with minimal effort. Octopussy has extensive report generating features and also various interfaces to other software, like e.g. NSCA (Nagios), Jabber/XMPP and Zabbix. With the help of software like Snare even Windows EventLogs can be processed.[6]
Octopussy is licensed under the terms of the GNU General Public License.
Although Octopussy is free and open-source software it has a variety of characteristics also found in some professional enterprise applications like Splunk, SAWMILL or Kiwi Syslog.
At the time of writing, Octopussy comes with the following set of features:
Some of the (meta-)services supported by/known by Octopussy are:
Apache 2, BIND, BSD Kernel, BSD PAM, BSD System, Cisco Routers (ASR), Cisco Switches, ClamAV, DenyAll Reverse Proxy, DRBD, F5 BigIP, Fortinet FW, HP-Tools, Ironport MailServer, Juniper Netscreen FW, Juniper Netscreen NSM, LDAP, Linux AppArmor, Linux Auditd, Linux IPTables, Linux Kernel, Linux PAM, Linux System, Monit, MySQL, Nagios, Neoteris/Juniper FW, NetApp NetCache, Postfix, PostgreSQL, Samba, Samhain, SNMPd, Squid, SSHd, Syslog-ng, TACACS, VMware ESX(i), Windows Snare Agent, Windows System, Xen ...[7]
Events receivable from services and thus processible by Octopussy include:
The software requires RSYSLOG installed on the syslog-server and expects systems that are monitored to run one of the numerous available syslog services, like e.g. syslogd/klogd, RSYSLOG or syslog-ng.[8]
The software further depends on the Apache 2 HTTP Server installed, with Apache::ASP, Mod_Perl and Mod_SSL. Octopussy also requires a MySQL DBMS (actual database is installed/copied during Octopussy setup) as well as a recent Perl interpreter installed on the operating system, with a variety of Perl modules from CPAN (e.g. Crypt::PasswdMD5, DBD::mysql, JSON, Unix::Syslog, XML::Simple).[9] A comprehensive list of those modules can be found within the software packages/archives README.txt file. In addition to that NSCD and RRDtool are a requirement. RRDtool aids in the creation of graphs that will be displayed on the Octopussy dashboard or shown on a per-device/per-service level.[10]
Octopussy receives syslog messages via syslog protocol and therefore behaves passively, not running any type of network agent on the remote machines under monitoring/surveillance.[11] Octopussy completely conforms to RfC 3164 and RfC 3195 of the IETF, describing syslog as the logging mechanism in Unix-like/BSD operating systems.[12] [13] That especially includes the internal representation of the facility and severity-principle where applicable.
The software is driven by a semi-stateful event correlation engine. This means that the engine records and thus knows its internal state, but only uses it to some extent to link together logically related elements for the same device, in order to draw a conclusion (i.e. to generate an alert). In Octopussy the semi-stateful correlation engine, with its so called sliding window (a shifting window being the logical boundary of a number of events during a certain period of time), is capable of comparing known past events with present ones based on a limited number of comparative values.
The Octo-Dispatcher is the component used by the Octopussy software to receive syslog lines from RSYSLOG and dispatch them into device directories.[14] Every device registered and activated within Octopussy gets its syslog messages assigned to it depending on the device name. Noteworthy is also the adjacent Octo-Replay component, which is the program used by the Octopussy software to replay log messages for some device or service (it receives and processes recognized logs and puts them back into the incoming directory).
The Octo-Parser and Octo-Uparser are two of Octopussy's most important core components. The Octo-Parser is the program used by the Octopussy software to parse logs in syslog format for each device registered within Octopussy.[15] It basically uses a regex-engine and commences pattern matching on incoming syslog messages. The Octo-Uparser is restarted every time device's services are changed, to check if previously received "unknown" log messages can be associated with a service.
In some cases Octo-Pusher is also called in advance to process non-syslog messages incoming from some devices. In that regard, the device setting "asynchronous" is helpful to process such log messages, after they were sent to an Octopussy server using e.g. FTP, rsync or SSH/SCP.
The Octopussy interface (GUI) is the default user-interface and provides configuration management, device and service management as well as alert definition and therefore extends the Octopussy core components. Devices are displayed in tabular form on the Devices page, with the following descriptors as a minimum: hostname, IP address, log type, device model/type, FQDN and OS.
Hence, the interface (Octo-Web) mainly provides access to other Octopussy core components like Octo-Commander, Octo-Message-Finder, Octo-Reporter and Octo-Statistic-Reporter. The Octopussy front-end/GUI is written in Perl 5, employing Apache::ASP to structure and display content.[16]
In addition to that, Octopussy core services can also be accessed from the operating system shell. That represents a convenient way for administrators to start/stop services or make fundamental configuration changes.
The Octopussy RRD graph generator is a core component of the software and installed by default. Since the generation of such graphs is very resource intensive administrators may opt to disable it on an Octopussy syslog server with a less powerful CPU and a low amount of RAM. The generated RRD graphs displays the activity of all active services for monitored devices, highly depending on the specific service. After a restart of the Octopussy software or during operation, Octo-Dispatcher and Octo-Parser will always process syslog messages in their buffer and queue first and RRD graph generation is delayed.[17] Octo-RRD further depends on Octo-Scheduler, to execute the Octopussy::Report function in order to generate syslog activity RRD graphs, that have been scheduled previously. Finally Octo-Sender has the capability to send report data to arbitrary recipients.
There is a plug-in/module system in Octopussy, which is mainly geared towards the modification of Octopussy reports. Such a plug-in consists out of a description file, which defines the plug-in name and functions, and a code file with perl code to process the actual data.[18]
There are also extensions for software related to Octopussy, like e.g. a Nagios plug-in that checks the Octopussy core services (i.e. Octo-Dispatcher, Octo-Scheduler, etc.) as well as the Octopussy parser states and log partitions.[19]
The creation of new services and service patterns presents the most important way to extend Octopussy without making changes to the source code. However, since patterns are outlined as simplified regular expressions, administrators should have at least some basic knowledge about regex in general. It is further strongly recommended to build on already existing services and also understand the meaning of a message objects' basic fields, which are message ID, pattern, log level, taxonomy, table and rank.[20]
Usually the logs wizard is used to search the system for unrecognized syslog messages per device to generate new service patterns. During the process the creation of patterns should be in a way that enables Octopussy to distinguish messages based on their severity and taxonomy.[21]