Skip to content

CYCLOPS

The Cyderes CNAP Logging & Operations Server (CYCLOPS) is a virtual appliance built to manage various containerized applications on a Cyderes-managed Kubernetes cluster that enables data forwarding to security analytics platforms like Cyderes CNAP, GCP's Chronicle, and Azure Sentinel. Customers are provided a VM appliance from Cyderes to deploy into their environment. Once online, the node enrolls into the Cyderes-managed configuration management system, loads necessary dependencies, and applications are deployed onto the CYCLOPS Kubernetes cluster.

CYCLOPS can perform as a single node cluster or can be linked with additional nodes to form a High Availability (HA) cluster. This cluster runs in the customer's environment, typically on a virtualization platform (VMware, Hyper-V, KVM, etc) or in a cloud computing environment such as AWS, GCP, or Azure. Kubernetes runs on top of this CYCLOPS. Kubernetes is a container orchestration platform that allows for simplified container deployments, zero downtime configuration updates, load balancing, high availability, and autoscaling.

From CYCLOPS, Cyderes will deploy containerized applications including our data forwarder technologies, logging/metrics collection for CYCLOPS, CYCLOPS management agents, and some Kubernetes components.

Scope and Sizing

The CYCLOPS size is derived from a combination of 'Events per Second' and data types that will be configured. Data types are defined as differentiated sources of information. For example, EDR, DNS, and DHCP are all separate data types.

Cyderes recommends CYCLOPS be deployed with at least 4 CPU, 16 GB of RAM, and 100 GB of disk space. This sizing allows for CYCLOPS to be instantly capable to accept new data types or features to be added. CYCLOPS is also flexible enough to be sized up or down depending on deployment scenario with the following guidelines:

Resource Amount Per
CPU 2 10,000 EPS
RAM 1.5 GB Data Type
HDD 50 GB minimum

Cyderes recommends following VMware documentation when choosing network interfaces: https://kb.vmware.com/s/article/1001805

Deployment

Cyderes can provide an OVA or similarly packaged virtual appliance or an AWS/GCP/Azure image. The package contains a base Linux operating system with enough necessary dependencies to bootstrap the system and establish initial contact with the Cyderes. The package can be deployed as often as needed to build additional nodes.

  • If utilizing an AWS AMI image, please provide Cyderes with AWS account numbers and regions to share the AMI to.
  • If utilizing a GCP Compute Image, please provide Cyderes the Admin account address or service account email address that will be given the Compute Image User role in the Cyderes project and can be used to create a copy of the Cyderes CYCLOPS image within your project.
  • If utilizing an Azure Shared Image, please provide Cyderes the appropriate Tenant ID.

IMPORTANT: Please provide Cyderes with the hostname(s) set for the forwarder(s). Providing a unique name that specifically identifies each forwarder will help our team get them provisioned as quickly as possible and help troubleshoot any issues in the future. Please ensure there are no spaces, underscores, or special characters other than a dash in the unique hostname(s).

Why deploy a forwarder?

Cyderes can handle log ingestion directly in our cloud-hosted forwarders, requiring no on-premise deployments of log collectors whatsoever. However, some customers appreciate having a centralized CYCLOPS log forwarder within a given on-premise environment. Additionally, some customers have legacy systems which cannot communicate over TLS, and having an on-premise forwarder allows the customer to limit the unencrypted traffic to the local network since the CYCLOPS log forwarder handles the encrypted traffic upstream back to Cyderes.

Connectivity Requirements

Notes:

  • A static/reserved IP address is required for proper appliance functionality.
  • If there is TLS/SSL interception enabled, please also bypass for the domains listed below.
  • If required, a custom DNS server may be used in place of 8.8.8.8 and 8.8.4.4.
  • *.cyderes.io port 123 must be used for NTP.
  • Broad opening of sub-domains to .cyderes.cloud and .cyderes.io is encouraged due to changing infrastructure.

If a health check port is required for a load balancer to function properly, please set the health check probe port to 10250, which is a metrics port for the Kubernetes cluster.

Destination Port Direction Use
gcr.io TCP/443 External Outbound Docker Image Management
*.googleapis.com TCP/443 External Outbound Telemetry (High Bandwidth)
googleapis.l.google.com TCP/443 External Outbound Authentication
accounts.google.com TCP/443 External Outbound Authentication
*.cyderes.cloud TCP/443 External Outbound CYCLOPS Management
*.cyderes.io TCP/123,443 UDP/123 External Outbound NTP
sm-ext-01.cyderes.cloud TCP/4505,4506 External Outbound CYCLOPS Management
8.8.8.8 TCP/53, UDP/53 External Outbound DNS
8.8.4.4 TCP/53, UDP/53 External Outbound DNS
Data sources TCP/30000-32767, UDP/30000-32767 Local Inbound
Product Specific Connections
cyderes.siemplifycloud.com TCP/443 External Outbound Siemplify
malachiteingestion-pa.googleapis.com TCP/443 External Outbound Chronicle Ingestion

Note: If the CYCLOPS is setup in HA (High Availability) cluster where multiple nodes are deployed, following is required to be open between those nodes for cluster communications

Port Type Description
443 TCP https
6443 TCP kube proxy
9099 TCP Canal/Flannel livenessProbe/readinessProbe
9100 TCP Prometheus metrics
10254 TCP Ingress controller livenessProbe/readinessProbe
10250 TCP kubelet API
8472 UDP Canal/Flannel VXLAN overlay networking
4789 UDP Flannel VXLAN overlay networking on Windows cluster

Architecture Diagram

cyclops

Generally, for each data type that is sent to CYCLOPS, a new TCP and UDP listener service will be configured to accept the data. The listener service ports will begin at 30000 and be incremented to accommodate additional data types as needed. For example, if there are two data types being sent over syslog, there would be two listener services on 30000 TCP/UDP and 30001 TCP/UDP.

Cyderes recommends utilizing TCP for sending syslog traffic whenever possible as this can help guarantee reliable log delivery.

CYCLOPS will function best when deployed in a load balanced environment to ensure maximum availability. The load balancer should distribute traffic on any TCP or UDP port to allow for new data types listeners on CYCLOPS to be added at any time.

High Availability

CYCLOPS supports two layers of high availability and load balancing.

  1. Node/VM Layer - Multiple CYCLOPS log forwarder instances can be run as a cluster within a customer-managed load balancer targeting each CYCLOPS forwarder instance. This also allows the customer to scale CYCLOPS out horizontally as well as vertically to meet their needs.

  2. Container Layer - By default, each CYCLOPS log forwarder leverages Kubernetes to load-balance multiple instances of the log forwarder service within multiple containers. This enables Cyderes to perform ZDD (zero downtime deployments) updates and meet our High Availability objectives, even on single node CYCLOPS cluster deployments.

Buffering, Resiliency, and Continuity of Log Flow

First, Cyderes recommends, whenever possible, customers to configure their systems to queue logs locally as a first layer of resiliency should that system become unable to contact the CYCLOPS log forwarder (e.g. a firewall misconfiguration or routing failure within the customer's environment).

Second, CYCLOPS forwarders leverage in-memory queuing of all incoming log data for times when they cannot communicate upstream to Cyderes, which is sufficient in most cases due to the reliability and high availability of Google Chronicle and the Google Cloud Platform (GCP). See Scope and Sizing above to ensure the deployment allocates sufficient RAM.

Security Considerations

Cyderes employs industry standard distributed configuration management and diagnostic solutions which instruct our CYCLOPS forwarders deployed within customer environments to establish outbound-only connections to Cyderes (e.g. Salt/Ansible). In the rare situation where an engineer must manually log into a forwarder, that engineer must successfully authenticate via Cyderes' managed MFA SSO before gaining access to the forwarder’s terminal shell within the customer environment via the outbound connection to Cyderes, at which point the engineer may perform connectivity diagnostics and Operating System level commands or actions to ensure the healthy status of the log ingestion and forwarding. The CYCLOPS forwarders do not allow inbound connectivity (e.g. SSH) for management or interactive control.

For environments with high security or regulatory concerns, Cyderes recommends deploying the forwarder in a DMZ (i.e. a firewall in between the CYCLOPS forwarder and the internal systems in question) as depicted in the architecture diagram above, allowing the internal systems to connect through the firewall to the CYCLOPS forwarders on the specific ports associated with the relevant data types, but no connectivity from the forwarder to the internal network; only allow internet-bound egress traffic to the resources listed above. This should remove the forwarder from the regulatory or high security compliance scope while maintaining a high level of availability for log collection.

For protection of data in transit, CYCLOPS can accept connections with a minimum of TLS 1.2 (TLS 1.0, 1.1, and all SSL versions are not enabled by default). For customers with legacy systems that cannot send logs over encrypted channels, CYCLOPS forwarders can also be configured to listen on specific ports for plaintext syslog (see the Why deploy a forwarder? section above). All outgoing communication from the CYCLOPS forwarders to Cyderes are encrypted over HTTPS using TLS 1.3.

VMware Configuration Reference:

https://kb.vmware.com/s/article/1004099