Firewall design and implementation generally require the presence of a subsystem that is responsible for accountability. This subsystem stores information on user and administrator activities performed on or through the firewall and must be configurable to provide exactly the amount and type of information needed, which, on the other hand, is usually defined by the corporate IT Security policy.
This requirement in computer systems is typically fulfilled by a logging subsystem. Logging is the act of collecting information about events in the system. The result of logging can be the following.
one or more log files (binary or text-based files)
the console
rows in a database table if logging is set up to use a database as the output store
These log files are archived for event-tracking purposes. Apart from a simple, automated archiving procedure, however, these log files must be continuously analyzed. Logging records, (quasi) real-time user and system activities, that is, a continuous analysis, is capable of detecting malicious user activities or system malfunctions as they take place, thereby allow for an effective and quick response policy.
In security-sensible systems, such as the Zorp firewall, logging must be a system–wide action, that is, all the relevant components of the system provide logging information, or log entries. There must be therefore a central component, a logging subsystem, that collects log entries from the various system components and organizes them into a log file of some format (the term file is used literally here and does not necessarily mean a text or binary file: it is simply the output of logging that can be a database, the console or some input queue on another machine). It would not be practical nor economical for all the components to manage their own log files. It would waste system resources (more open file handles, database connections or network sessions, depending on the output destination used) and would make analysis cumbersome (hunting for information in several separate log files that would probably be syntactically incompatible).
In Zorp, centralization is elevated to a higher level: the logs of the central logging subsystem on all machines are unified on a network-wide dedicated central logging machine. This way, log analysis, reporting and archiving is simpler even for larger networks with many entities providing logging capabilities.
These requirements have, in part, long been targeted by the Unix syslog subsystem. For decades, syslog was the ultimate central logging subsystem for Unix and Linux machines. It is an old and rather unreliable technology and lacks some flexibility and security features that are required in today's demanding network and security environments. Therefore, a replacement service called syslog-ng, where "ng" stands for "next generation", has been created. The syslog-ng application inherited all the concepts, features and most of the naming conventions from syslog and enhanced it with several new features targeting flexibility and security requirements. Zorp uses syslog-ng as its logging subsystem.
The following sections include a short introduction to the concepts of syslog-ng, and describe how ZMS works with syslog-ng and how this subsystem can be managed with ZMC.
Published on May 30, 2024
© BalaSys IT Ltd.
Send your comments to support@balasys.hu