Security Logging

mbox series (HSG, CMG, HSA, mlog) have extensive support for user access and system audit logging, via syslogs. Syslogs are classified into different severity (Emegency, Alert, Critical, Error, Warning, Notice, Informational, debugging) and facilities etc. 

Many regulations, such as the Sarbanes-Oxley Act, PCI DSS, HIPAA, etc, require organizations to implement comprehensive security measures, which often include collecting and analyzing logs from many different sources. Syslog has long become a industry standard to collect logs from different sources. More details on syslog can be searched online.

This document focuses on mbox's support for security logging, either as a syslog collector (eg. HSG/mlog) or syslog client. Depending on the deployment requirements, mbox can run in either (or both) of two modes:

• syslog collector. Syslog collector receives either self-originated or incoming logs from external hosts (log clients) via standard syslog protocol, then collector parses the received logs and inserts into SQL database, making the binary logs reachable from intuitive GUI and ready for archival etc. 

  • HSG by default has the ability to store user access logs locally, but with limited storage space, usually no more than 10GB available for storing logs, which is usually enough to store archived user access logs for up to 90 days. 

  • We also have dedicated collector appliances to function as syslog collector (mlog series: LOG-500, LOG-1000, LOG-2000). mlog appliances are special variants of mbox models with additional SSD/HDD storage capacity.  mlog series are typically deployed as central logging warehouse to consolidate logs from all devices within customer networks. Any devices supporting standard syslog protocol can potentially export their logs to mlog collector. NOTE, there're 3rd-party opensource software converters to convert Windows Event Log into syslog to export to mlog as well. 

  • HSG/mlog also come with a nice built-in loganalyzer/GUI to display live incoming logs, with sophisticated searching functions for investigation and compliance reporting purposes. NOTE: CMG & HSA can not function as a log collector.

• syslog client. Syslog clients are basically devices generating message in syslog format and export the logs to external syslog server/collector. 

  • NOTE: all mbox product families (CMG, HSG, HSA) can be configured as syslog client, track network packets, generate user access logs and export as syslog messages to local (in the case of HSG) or external syslog server (mlog or other 3rd-party syslog server).

Below samples show different type of logs supported by mbox gateways.

Firewall access logs. This is generated by firewall, by inspecting up to transport layer (layer 4) of each packet. Below is a raw sample firewall log output

URL access logs. This is generated by web proxy, by tracking each user browsing session, with the full URL path for each request.

Note this is applicable only for HTTP based traffic. mbox proxy doesn't intercept HTTPS traffic. As an alternative, you can consider DNS logging for tracking HTTPS requests, but unlike proxy logs, DNS logs don't track the full URL path. Below is a raw sample URL log output

DNS access logs. This is enabled by default for HSG/CMG/HSA.

DNS log tracks all requests, for both http/https based URL requests and all other applications (eg. even mobile apps requests), but not up to the full URL path. It's a very effective method and commonly used by many other products for user behavior analytics and URL filtering (eg. SafeDNS and OpenDNS). Below is a raw sample DNS log output

DHCP logs. DHCP logging is enabled by default. This log captures user device DHCP request and mbox offer/reply to device, which is important to track mapping of device NAME, MAC and IP.

RADIUS session logs. RADIUS session logging is available for HSG only and it's enabled by default. It captures user device authentication and connections requests on a per connection basis. 

When a device is configured to export syslogs to an external syslog server, we call it syslog client.  HSG can function as both log server/collector and log client (NOTE: CMG and HSA work as log clients only). Different vendor products have their own syntax in tracking firewall access logs and enabling syslog exports, please consult respective product guide. 

This section focuses on firewall access logging and how to export out logs for CMG/HSG/HSA.

Configuration steps for a log client:

1. Enable firewall access logging  (CMG, HSG, HSA). NOTE: DNS logging, DHCP logging, and HSG RADIUS logging are enabled on by default.

2. Configure log-out rules to export out logs

1. ENABLE FIREWALL ACCESS LOGGING

We use firewall-access rules to log each packet passing through mbox, eg.

It is important to know that HSG/HSA maintain a separate set of firewall rules for each hotspot instance, so we enable logging using hotspot-access rules under each hotspot instance.

2. CONFIGURE LOGGING OUTPUT RULES

log-output rule defines what type of logs to export out and to which servers (using log-output xx command). If there're multiple log-output rules, they work in top-down sequences.

• <ACL Number> defines sequence of output rules. It is like firewall rules, processed from top-down, once a log is matched with an upper rule, it will not be processed by lower rules. So it's important to plan the rules sequence when we have many rules. 

• <collector-ip> specifies the IP address of external syslog collector (eg. LOG-500). Note if there's firewall in between, firewall needs to open UDP/514 for the traffic to pass through.

• <filter> defines filtering rules based on syslog fields to determine the matched logs to export. below is a list of available options:

  • msg <text> filter by messages containing configured text

  • fac <facility> filter by facility (eg. local1, local2, local3, local4...up to local7)

  • prio filter by log priority/severity (eg. ALERT, NOTICE, INFO, etc), containing the configured priority.

  • tag filter by syslogtag, containing the configured text.

  • all send all logs

In real practice, if we are unsure which filter options to use, we use "all" first, then mbox will export out all the logs. After we study the logs from syslog collector GUI and decide what field to use for filtering, we will tune the log-out rules for better control.

NOTE: 

1. once you configure mbox as log client, the matched logs will be sent out and not locally available any more (can't even see from CLI also).

2. If you're keeping local logs for HSG, do NOT configure log-out rules for HSG. Just enable logging and configure local log-server.

Example 1: Enable logging on CMG

For CMG, If we want to log the access details (packets passing/denied through mbox firewall), we need to use the "permit-log/deny-log" action option. 

Below is an example for CMG.

Example 2: Enable logging on HSG

For HSG, because each hotspot context maintains its own set of firewall rules, we need to enable "permit-log" within hotspot context.

Example 3: Enable CLI commands logging

It's possible to log CLI commands typed by engineers, and send to external log collector for audit reference purposes.

Example 4: Enable firewall logging on HSA

For HSA, If we want to log the access details (packets passing/denied through mbox firewall), we use the "permit-log/deny-log" action option. 

When mbox is configured as a syslog collector/server (HSG or mlog), it can receive and store logs exported from local or any external devices, via standard syslog protocols. The syslogs are parsed and stored in local SQL database, accessible by GUI for analysis and exportable to external csv files etc.

Configuration steps for a log collector (log-server):

1. Enable MySQL service

2. Enable log server

3. Configure log-input rules to determine what types of logs to receive

NOTES:

• collector local firewall rules (firewall-input) must permit incoming UDP/514 protocol

• We can configure extremely granular filtering rules (log-input xx) to accept logs from allowable hosts, or what type of logs we want to accept, or only accept logs containing particular text patterns etc etc.

• We can configure log-input rules for complex scenarios. The log-input rules work like firewall rules, and match from top down.

Configuration EXAMPLES:

INFO: refer to attached complete sample config files for a primary syslog collector (with HA configured).

When HSG/mlog is configured as a log collector, it comes with intuitive GUI for administrators to view live logs, search historical records and archive logs for compliance or future forensic investigation purposes.

mlog is able to collect and store all logs from external systems via syslog protocol. HSG typically stores locally generated logs (Please refer to this link for the logs that can be generated by HSG).

There're a few tabs under this menu

• "Live" shows the latest incoming raw logs. 

  • It's auto-refreshed/updated every 5 seconds by default, however It's possible to change/adjust the refresh interval manually, 

  • Click on "Pause" to freeze the fresh for investigation purpose. 

  • Filter by different contents to only see the target "interesting" logs.

  • Mouseover or click on a message line to view full message details 

• "Search" allows administrator to search historical logs based on various filtering criterion, and it's possible to export and print the search results into csv. The depth of searchable logs depends on how much raw logs you configured to keep in the SQL database (refer to "Keep raw logs locally" value in next tab).

• "Archive" allows administrator to retain historical logs for compliance or forensic investigations. NOTE, if you've configured CLI for log archival, the GUI setting will superseded CLI setting (eg. CLI config won't take effect once GUI setting is configured). It's recommended to use GUI to configure log archival.

  • "Archive log data into daily or hourly files (run nightly)". This option defines how raw logs are archived. By default the raw logs are collected and stored in local SQL database, viewable & searchable from GUI. When the logs are archived, they are exported out from SQL database into compressed csv files. The primary purpose of "archive" is to reduce storage space. when the same log contents are exported/converted from SQL to zipped csv files, typically the storage space will be reduced by 20 times. You can click to switch export in "Daily Files" or "Hourly Files". If the archival file sizes are expected to be very huge, then it's better to choose "Hourly Files". For example, an mlog can collect more than 20GB logs per day, and the compressed csv file can be 1GB in size. It will be very hard to download and unzip the archived files later when it comes to investigation. However, in most case, "Daily Files" will be just enough. For a typical network with up to 2000 users, the daily file won't be more than 50MB, which is still quite manageable.

  • Keep raw logs locally (recommend 1 day)* This option defines how much raw logs to store in SQL database. The raw logs can be viewed and searched using GUI for immediate investigation purposes. However raw logs usually consume large storage, and this is dangerous for HSG which has limited disk space. So It's highly recommended to minimize this value. However, mlog would have large local storage (with additional HDD) so you can slightly put this value higher. 

NOTE, all raw logs older than the configured x day here will be purged from SQL database. If you need to investigate incidents happened earlier than the configured x day, you would refer to archival files. So please make sure you set the right values to "Keep archived files locally", in order to meet compliance requirements.

• • Keep archived files locally (optional)* This setting defines how long (or how many) archived files (the compressed csv files) you want to keep in the local storage, and the archival files are listed/shown in GUI so you can download and unzip to view the raw logs when it comes to investigation or reporting. Please be sure to set this value to compliant to local cyber security regulations. Many countries require to keep minimum 90 days of firewall/URL access logs for public Internet access. 

NOTE, HSG default storage disk space can store data up to 20GB (including user accounts, profiles, session records, firewall access logs, etc). For a large mall or F&B chain with 150 outlets, the typical daily archival file size is 50MB, therefore 90 days of archival storage is about 5GB. So the default disk size would be sufficient. However, extra disk space can be customized upon request.

• • Backup archived files to external FTP Server (runs nightly). This optional features give you the flexibility to store archival files into external FTP server. You can combine above setting (keep archived files locally) together, eg. store x days of local archival files so that you can easily download from GUI and at the same time store all archival files to FTP server so that you can keep for as long as needed. This option is extremely important if you have large amount of logs and must minimize local archival files. Exporting to external FTP eliminates all the storage constraints (potentially unlimited, eg. if you use a huge & cheap NAS storage).

HSG/mlogs comes with a log analyzer engine that tracks all incoming live logs, compares each log against the predefined rules, and alarms once a rule is triggered (log pattern is matched to a rule). The engine runs every one minute to analyze latest raw logs. The alarms are shown in GUI and sent out to emails at the same time.

• "Engine" allows administrator to turn on/off engine. Note turning on log analyzer enginer with large amount of rules and logs will impact system performance.

• "Alarms" shows abnormal events triggered by alarms rules. It means certain log patterns are matched, eg. access to prohibited websites or destinations.

• "Rules" defines the patterns that you want to match certain conditions.

  • "Logical Operator, and/or" If you have multiple matching Criteria, and means ALL criteria must be matched to trigger an alarm; or means EITHER one of the criteria matched will trigger an alarm.

  • "Criteria" sets what fields/contents of the raw log patterns to match. You can match by time, host, or certain contents of the log message (see above screenshot).

  • "Action" allows you to add emails to send alarms

View local logs from CLI

mbox is by default enabled with local logging, to view locally generated logs (usually for troubleshooting purpose), issue below command:

NOTE:

• This command only shows real-time logs, for troubleshooting purposes. mbox doesn't keep any historical local logs. If we need historical logs, we have to export logs to an external log server/collector, or enable local "security log-server"

• if we want to view firewall logs etc from local console/ssh, we still need to enable access logging, discussed in this section. But don't output/export to an external server.

• if an mbox is configured as a log client (export logs out to external log collector), the exported logs will not appear in this command. We need to view exported logs from the log server/collector.