Skip to main content
This project is currently in the design phase. The installation procedures described here are planning guidelines based on the conceptual architecture. Actual installation steps will be finalized during implementation.

Overview

This guide outlines the recommended installation order, deployment strategies, and architectural considerations for deploying the Enterprise SOC Architecture. Components must be installed in a specific sequence to satisfy dependencies.

Installation Order and Dependencies

Components should be installed in the order presented below to ensure dependencies are met at each stage.

Dependency Graph

Phase 1: Foundation
├── Operating System & Base Configuration
└── Network Configuration (VLANs, Firewall Rules)

Phase 2: Core Infrastructure  
├── Elasticsearch Cluster (storage layer)
│   └── Required by: Wazuh, TheHive, Logstash
└── Database Systems (MySQL/PostgreSQL)
    └── Required by: Zabbix, TheHive (alternative)

Phase 3: Data Pipeline
├── Logstash/Fluentd (log aggregation)
│   ├── Depends on: Elasticsearch
│   └── Required by: IDS/IPS, various log sources

Phase 4: Security Platform Core
├── Wazuh Manager
│   ├── Depends on: Elasticsearch
│   └── Required by: Wazuh Agents, integrations
└── Wazuh Dashboard
    └── Depends on: Wazuh Manager, Elasticsearch

Phase 5: Monitoring Systems
├── Zabbix Server
│   └── Depends on: Database (MySQL/PostgreSQL)
├── Prometheus
│   └── Standalone (minimal dependencies)
└── Grafana (optional)
    └── Data sources: Prometheus, Elasticsearch

Phase 6: Detection Layer
├── Snort/Suricata IDS
│   └── Depends on: Logstash (for alert forwarding)

Phase 7: Incident Response
├── TheHive
│   └── Depends on: Elasticsearch or Cassandra
└── Cortex (SOAR)
    └── Depends on: TheHive

Phase 8: Automation (Optional)
├── Terraform/PyInfra setup
│   └── For infrastructure as code management

Phase 9: Future Components (Long-term)
├── OPNsense Firewall
├── Honeypots on Proxmox
└── Tailscale VPN

Deployment Architecture Strategies

All-in-One Deployment

Use Case: Testing, proof of concept, small environments (less than 50 endpoints)Architecture:
  • Single server hosts all SOC components
  • Containers (Docker/Podman) or VMs for service isolation
  • Minimal high availability
Minimum Specifications:
  • CPU: 16 cores
  • RAM: 64 GB
  • Storage: 2 TB SSD
  • Network: 2x 1 Gbps NICs (management + monitoring)
Advantages:
  • Simple deployment and management
  • Lower hardware costs
  • Easy for testing and learning
Limitations:
  • No high availability
  • Limited scalability
  • Single point of failure
  • Resource contention between components
Single-server deployments are NOT recommended for production environments. Use only for testing or very small deployments.
Installation Approach:
# Example using Docker Compose
# All components defined in single docker-compose.yml

services:
  elasticsearch:
    image: elasticsearch:8.x
    # ... configuration
  
  wazuh-manager:
    image: wazuh/wazuh-manager:latest
    depends_on:
      - elasticsearch
  
  logstash:
    image: logstash:8.x
    depends_on:
      - elasticsearch
  
  # Additional services...

High Availability Considerations

Critical Components Requiring HA

1

Elasticsearch Cluster

HA Strategy: Multi-node cluster with replication
  • Deploy 3+ nodes (odd number for split-brain prevention)
  • Configure index replication (minimum 1 replica)
  • Use dedicated master-eligible nodes in large clusters
  • Implement cluster-level shard allocation awareness
Configuration Highlights:
# elasticsearch.yml
cluster.name: soc-elasticsearch
node.name: es-node-01
discovery.seed_hosts: ["es-node-01", "es-node-02", "es-node-03"]
cluster.initial_master_nodes: ["es-node-01", "es-node-02", "es-node-03"]

# Replication for HA
index.number_of_replicas: 1
Never run Elasticsearch in production with number_of_replicas: 0. Data loss will occur on node failure.
2

Wazuh Manager Cluster

HA Strategy: Master-worker cluster architecture
  • Deploy master node and one or more worker nodes
  • Agents connect to cluster (automatic failover)
  • Shared configuration and rules across cluster
  • Load balancer distributes agent connections
Setup:
  • Configure cluster in /var/ossec/etc/ossec.conf
  • Enable cluster mode and set cluster key
  • Configure node type (master/worker)
  • Use load balancer (HAProxy, nginx) for agent connections
3

Logstash Pipeline Redundancy

HA Strategy: Multiple pipeline instances with load balancing
  • Deploy 2+ Logstash instances
  • Use load balancer for input (if using Beats)
  • Configure persistent queues for data durability
  • Monitor pipeline throughput and backpressure
Configuration:
# logstash.yml
queue.type: persisted
queue.max_bytes: 4gb
4

Database High Availability

HA Strategy: Database replication and clusteringFor MySQL/PostgreSQL (Zabbix, TheHive):
  • Master-slave replication
  • Automatic failover (using tools like Patroni for PostgreSQL)
  • Regular backups to separate storage
For Cassandra (TheHive alternative):
  • Multi-node cluster with replication factor 3
  • Distributed architecture provides natural HA
5

Application Load Balancing

HA Strategy: Load balancers for web interfacesComponents needing load balancing:
  • Wazuh Dashboard (multiple dashboard instances)
  • TheHive web interface
  • Grafana dashboards
Implementation options:
  • HAProxy (open source, highly recommended)
  • Nginx (reverse proxy + load balancing)
  • Cloud load balancers (ALB on AWS, Azure Load Balancer)
Example HAProxy config:
frontend wazuh_dashboard
    bind *:443 ssl crt /etc/ssl/certs/wazuh.pem
    default_backend wazuh_servers

backend wazuh_servers
    balance roundrobin
    option httpchk GET /
    server wazuh01 10.0.30.11:443 check ssl verify none
    server wazuh02 10.0.30.12:443 check ssl verify none

Backup and Disaster Recovery

High availability prevents service interruption, but backups protect against data loss, corruption, and disasters.
Backup Strategy:
ComponentBackup MethodFrequencyRetention
ElasticsearchSnapshot API to S3/NFSDaily30 days
Wazuh ConfigurationFile backup of /var/ossecDaily90 days
TheHive DatabaseDatabase dump or snapshotDaily90 days
Zabbix DatabaseMySQL/PostgreSQL dumpDaily30 days
Custom Rules/ScriptsGit repositoryOn changeIndefinite
System ConfigsConfiguration management (Terraform/Ansible)On changeIndefinite
Disaster Recovery Plan:
  1. Document recovery procedures for each component
  2. Test restoration quarterly (minimum)
  3. Maintain runbooks for critical failure scenarios
  4. Store backups off-site or in separate cloud region
  5. Define RTO/RPO (Recovery Time/Point Objectives) for each tier

Installation Steps by Component

Phase 1: Foundation

For all servers:
# Update system packages
sudo apt update && sudo apt upgrade -y  # Debian/Ubuntu
sudo yum update -y                       # RHEL/CentOS

# Install common dependencies
sudo apt install -y curl wget gnupg2 software-properties-common \
  apt-transport-https ca-certificates ntp

# Configure NTP for time synchronization
sudo systemctl enable ntp
sudo systemctl start ntp

# Configure firewall (example using ufw)
sudo ufw enable
# Add specific rules per component (see Network Setup guide)

# Set hostname appropriately
sudo hostnamectl set-hostname soc-component-name
Security hardening:
  • Disable root SSH login
  • Configure SSH key-based authentication
  • Enable automatic security updates
  • Install and configure fail2ban

Phase 2: Core Infrastructure

Installation (per node):
# Import Elasticsearch GPG key
wget -qO - https://artifacts.elastic.co/GPG-KEY-elasticsearch | \
  sudo gpg --dearmor -o /usr/share/keyrings/elasticsearch-keyring.gpg

# Add repository
echo "deb [signed-by=/usr/share/keyrings/elasticsearch-keyring.gpg] \
  https://artifacts.elastic.co/packages/8.x/apt stable main" | \
  sudo tee /etc/apt/sources.list.d/elastic-8.x.list

# Install Elasticsearch
sudo apt update && sudo apt install elasticsearch

# Configure cluster (edit /etc/elasticsearch/elasticsearch.yml)
# See Configuration guide for details

# Enable and start service
sudo systemctl daemon-reload
sudo systemctl enable elasticsearch
sudo systemctl start elasticsearch

# Verify cluster health
curl -X GET "localhost:9200/_cluster/health?pretty"
Save the auto-generated elastic superuser password during installation. It’s displayed once and needed for initial configuration.
For Zabbix and TheHive (if not using Elasticsearch/Cassandra):
# PostgreSQL installation (recommended)
sudo apt install postgresql postgresql-contrib

# Start and enable
sudo systemctl enable postgresql
sudo systemctl start postgresql

# Create databases
sudo -u postgres psql
CREATE DATABASE zabbix;
CREATE DATABASE thehive;
CREATE USER zabbix_user WITH PASSWORD 'secure_password';
CREATE USER thehive_user WITH PASSWORD 'secure_password';
GRANT ALL PRIVILEGES ON DATABASE zabbix TO zabbix_user;
GRANT ALL PRIVILEGES ON DATABASE thehive TO thehive_user;
\q

Phase 3-7: Component Installation

Detailed installation procedures for each component (Wazuh, Logstash, Snort/Suricata, Zabbix, Prometheus, TheHive, Cortex) will be provided in component-specific documentation. The key is to follow the installation order defined in the dependency graph above.
General installation pattern:
  1. Add official package repository
  2. Install package via package manager
  3. Configure component (see Configuration guide)
  4. Enable and start systemd service
  5. Verify component health and connectivity
  6. Integrate with dependent components

Phase 8: Automation Tools

Terraform (for infrastructure provisioning):
# Install Terraform
wget https://releases.hashicorp.com/terraform/latest/terraform_linux_amd64.zip
unzip terraform_linux_amd64.zip
sudo mv terraform /usr/local/bin/

# Verify installation
terraform version

# Initialize SOC infrastructure code
mkdir -p ~/soc-terraform
cd ~/soc-terraform
terraform init
PyInfra (for configuration management):
# Install PyInfra
pip3 install pyinfra

# Create deployment scripts
mkdir -p ~/soc-pyinfra
# Add deployment scripts for SOC components

Post-Installation Validation

1

Component Health Checks

Verify each component is running and accessible:
# Elasticsearch
curl -X GET "localhost:9200/_cluster/health"

# Wazuh Manager
sudo systemctl status wazuh-manager

# Check all systemd services
sudo systemctl status elasticsearch wazuh-manager logstash \
  zabbix-server prometheus
2

Connectivity Testing

Test network connectivity between components:
# From Logstash to Elasticsearch
curl -X GET "http://elasticsearch-host:9200"

# From Wazuh agent to manager
telnet wazuh-manager-host 1514

# Test all required ports from Network Setup guide
3

Data Flow Verification

Confirm data flows through the pipeline:
  • Deploy test Wazuh agent and verify events in Elasticsearch
  • Send test syslog message to Logstash and check indexing
  • Trigger test IDS alert and verify in Wazuh dashboard
  • Create test incident in TheHive and verify storage
4

Dashboard Access

Verify all web interfaces are accessible:
  • Wazuh Dashboard: https://wazuh-host/
  • TheHive: http://thehive-host:9000/
  • Zabbix: http://zabbix-host/
  • Prometheus: http://prometheus-host:9090/
  • Grafana (if deployed): http://grafana-host:3000/

Troubleshooting Common Issues

Symptoms: Nodes don’t discover each otherSolutions:
  • Verify discovery.seed_hosts contains all node IPs
  • Check firewall allows port 9300 between nodes
  • Ensure cluster.name is identical on all nodes
  • Verify network connectivity: ping and telnet between nodes
  • Check logs: /var/log/elasticsearch/
Symptoms: Agents show as disconnected in dashboardSolutions:
  • Verify firewall allows ports 1514 and 1515 to manager
  • Check agent configuration: cat /var/ossec/etc/ossec.conf
  • Verify manager address is correct in agent config
  • Check manager logs: /var/ossec/logs/ossec.log
  • Restart agent: sudo systemctl restart wazuh-agent
Symptoms: System running out of memorySolutions:
  • Verify JVM heap is set to 50% of system RAM (max 31 GB)
  • Check heap settings: /etc/elasticsearch/jvm.options
  • Monitor heap usage: curl localhost:9200/_nodes/stats/jvm
  • Reduce replica count or index retention if needed
  • Consider adding more nodes to distribute load
Symptoms: High packet drop rate in Suricata/Snort statsSolutions:
  • Increase AF_PACKET buffer size (Suricata)
  • Enable multi-threading in IDS configuration
  • Verify NIC is in promiscuous mode: ip link show
  • Check if SPAN session is overloading sensor
  • Consider hardware upgrade or additional sensors

Installation Checklist

Before marking installation complete:
  • All components installed in correct order
  • Systemd services enabled and running
  • Inter-component connectivity verified
  • Web dashboards accessible
  • Test data flows through entire pipeline
  • High availability configured (if production)
  • Backup procedures implemented and tested
  • Firewall rules validated
  • TLS/SSL certificates installed
  • Documentation updated with actual configuration
  • Monitoring of SOC infrastructure itself enabled
  • Team trained on basic operations

Next Steps

With components installed:
  1. Proceed to detailed Configuration of each component
  2. Deploy agents and sensors to production endpoints
  3. Configure alerting rules and correlation logic
  4. Develop incident response playbooks
  5. Begin security event monitoring and tuning
Installation is just the beginning. Plan for 2-4 weeks of tuning and optimization before considering the SOC fully operational.

Build docs developers (and LLMs) love