Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Explanations:

  • tbd

Delimitation

The JS7 Logging Service is offered for convenience purposes as it allows to access log files of JS7 products from JOC Cockpit as a central point of view.

Due to limitations of the underlying Syslogd Protocol the JS7 Logging Service does not meet all requirements for security, resiĺience and high availability. The Logging Service is offered for convenience. However, the authoritative source of log output are log files created by the JS7 products.

Security

The Syslogd Protocoll does not specify authentication:

  • This translates to the fact that log messages can be faked by malicious 3rd-party components as the JS7 Logging Service cannot authenticate and reliably identify the source of log output.
  • Users are warned in case that they take action based on messages arriving with the JS7 Logging Service: severe messages that suggest immediate action should be verified from the JS7 product's log files.

The Syslogd Protocol is exposed to denial-of-service attacks:

  • Flooding of messages is a possible scenario for attacks that is not covered by the Syslogd Protocol.
  • The JS7 Logging Service will identify such scenarios and will shut down. The behavior is intended to keep the JOC Cockpit that operates the Logging Service free from DNS attacks.

Resilience

The Logging Service accepts messages sent via the UDP protocol only.

  • TCP connections are out of scope due to their blocking nature.
  • UDP messages can arrive in an sequence.

The Logging Service performs input sanitazation.

  • This includes that any log messages that include for example HTML tags, will be dropped.
  • Messages sent to the JS7 Logging Service have to be compliant to the above Log4j configuration and otherwise will be dropped..

High Availability

The JS7 Logging Service is subject to clustering of JOC Cockpit:

  • This allows the service to switch from a current JOC Cockpit instance to the next active JOC Cockpit instance.
  • Switching to a different host operating the then active JOC Cockpit instance includes that the hostname of the Logging Service will change,. Users are encouraged to set up a Proxy Service that will forward log messages to the active JOC Cockpit instance.

If no JOC Cockpit instance is active, then no log messages can be picked up:

  • In a situation when no JOC Cockpit instance is active UDP messages will be lost.
  • Periods of unavailability of JOC Cockpit can occur in case of fail-over and switch-over that take approx. 30s but can be prolonged if a larger number of orders is present.