rConfig V8 Security Hardening: Enterprise Network Management Security Guide

Introduction

Administrative Responsibility

This document provides comprehensive security hardening guidance based on industry best practices. Implementation specifics must align with organizational security policies, compliance requirements, and risk management frameworks. Administrators are responsible for adapting these recommendations to their specific operational environment. Refer to the rConfig Terms of Service for additional information.

Security hardening represents a critical component of maintaining system integrity, confidentiality, and availability, particularly for network configuration management platforms like rConfig. In the current threat landscape, cyber risks continue to evolve, and even minor vulnerabilities can result in significant operational and security impacts. Comprehensive hardening procedures mitigate these risks, protect sensitive data, and ensure regulatory compliance.

rConfig maintains a strong security posture, with only three Common Vulnerabilities and Exposures (CVEs) throughout its history, all occurring in the legacy V3 version. This track record demonstrates the platform’s commitment to security excellence and continuous improvement.

This guide provides end-to-end security hardening procedures specifically tailored for rConfig deployments. While incorporating industry-standard best practices, all recommendations have been adapted to address rConfig’s specific architecture and operational requirements. Following these procedures will establish a robust security foundation against evolving threats.

Security Assessment and Risk Analysis

Prior to implementing hardening measures, conduct a comprehensive security assessment to identify existing vulnerabilities and establish baseline security metrics.

• Vulnerability Assessment: Deploy automated scanning tools such as Nessus, OpenVAS, or Qualys to identify system and infrastructure vulnerabilities systematically.
• Penetration Testing: Conduct periodic penetration testing exercises to simulate adversarial attacks and evaluate defensive capabilities.
• Compliance Auditing: Engage qualified external auditors to verify compliance with relevant frameworks including NIST Cybersecurity Framework, ISO 27001, and SOC 2 Type II.

Authentication and Access Control

rConfig provides enterprise-grade authentication capabilities, including local user management, Active Directory integration, and Single Sign-On (SSO) integration with identity providers. These features enable flexible deployment models while maintaining security requirements. Reference documentation:

• LDAP Configuration
• SSO Implementation Guide

The platform implements comprehensive Role-Based Access Control (RBAC), enabling administrators to enforce the Principle of Least Privilege effectively across the organization. For implementation guidance, consult the RBAC Documentation.

Authentication Hardening Procedures

• Multi-Factor Authentication (MFA): Mandate MFA for all user accounts, particularly privileged accounts with administrative access. Implement authentication mechanisms including time-based one-time passwords (TOTP), hardware security keys (e.g., YubiKey), or biometric authentication.
• Principle of Least Privilege (PoLP): Grant users and service accounts only the minimum permissions required to perform their assigned functions.
• Role-Based Access Control (RBAC): Implement RBAC across all system components, including databases, network services, and cloud infrastructure resources.
• Default Account Management: Remove or disable all default administrative and service accounts. These represent high-value targets for unauthorized access attempts.

Network Security Architecture

Network security serves as the primary perimeter defense layer. For rConfig deployments, the following network configuration is required:

• Outbound Network Requirements:

  • Port 80 (HTTP) and 443 (HTTPS) for standard web traffic
  • SSH and Telnet protocols as required for managed device communication
  • Outbound connectivity to rconfig.com (static IP) for version verification (recommended but optional)

• Inbound Network Requirements:

  • Port 80 (HTTP) and 443 (HTTPS) for web interface access
  • Port 21 (FTP) and Port 69/UDP (TFTP) for specific operational requirements

Network Hardening Measures

• Firewall Configuration and Network Segmentation: Deploy stateful firewalls to restrict network traffic to authorized services exclusively. Implement network segmentation strategies (e.g., separate internal, external, and DMZ zones) to contain potential breaches and prevent lateral movement.

• Intrusion Detection and Prevention Systems (IDPS): Deploy network-based IDPS solutions such as Snort, Suricata, or OSSEC to detect and block malicious network activity in real-time.

• Encrypted Communications: Require encrypted protocols for all remote access (VPN, SSL/TLS, SSH). Enforce encryption for internal communications where operationally feasible.

Server Hardening

For optimal security and performance, deploy rConfig on dedicated infrastructure rather than shared hosting environments. This configuration minimizes attack surface and prevents resource contention. The following hardening procedures apply to physical servers, virtual machines, and user endpoints:

System Management Responsibility

Operating system and server management remains the customer’s exclusive responsibility. While rConfig provides deployment scripts, configuration guides, and security recommendations, customers must ensure compliance with organizational policies regarding patch management, system updates, and security standards. Security is a shared responsibility model requiring customer adherence to enterprise security practices.

Operating System Security

• Attack Surface Reduction: Remove unnecessary software packages, system services, and runtime components to minimize potential attack vectors.
• Patch Management: Maintain current security patches for operating systems, applications, and third-party dependencies. Implement automated patch management solutions such as OSSEC, WSUS, or yum-cron.
• Mandatory Access Control: For Linux environments, configure SELinux (Security-Enhanced Linux) or AppArmor to enforce mandatory access control policies.
• Service Hardening: Disable unnecessary network services and protocols (e.g., FTP, Telnet), maintaining only operationally required services.
• SSH Hardening: Configure SSH to disable root login, require key-based authentication, and implement connection rate limiting to prevent brute-force attacks.

SELinux Configuration

Note: By default, rConfig installation scripts disable SELinux based on common deployment practices - because not all organizations utilize SELinux. Organizations utilizing SELinux should implement the following configuration to enable rConfig operation under SELinux enforcement.

• Enable Enforcing Mode: Configure SELinux in enforcing mode for maximum security posture.

  • Execute: setenforce 1
  • For persistent configuration, modify /etc/selinux/config and set SELINUX=enforcing

• SELinux Policy Configuration: Define security policies restricting access to authorized files, processes, and network ports.

  • HTTPD Network Connectivity: Enable Apache network access: setsebool -P httpd_can_network_connect 1
  • HTTPD Unified Context: Enable template modification capabilities: setsebool -P httpd_unified 1

• Audit Log Monitoring: Regularly review SELinux audit logs at /var/log/audit/audit.log to identify unauthorized access attempts and policy violations.

• Policy Refinement: Utilize audit2allow to develop custom policies while minimizing operational disruption:

  ausearch -m avc -ts today | audit2allow -M my_policy
  semodule -i my_policy.pp

Scheduler and Worker Processes

From V8.4.1, nothing in rConfig runs as root. Horizon, the scheduler and the SNMP trap receiver all run as the web server user (apache on RHEL family systems, www-data on Ubuntu):

• Scheduler: one line in the web user’s crontab, written by the deploy script. Root’s crontab must not run schedule:run.
• Horizon: the Supervisor program horizon with user= set to the web user. The deploy writes its config as a root-owned 0644 file (/etc/supervisord.d/horizon_supervisor.ini on RHEL, /etc/supervisor/conf.d/horizon_supervisor.conf on Ubuntu), never a symlink into the rConfig folder.
• SNMP trap receiver: the systemd service rconfig-snmptrap, run as the web user.

Check the scheduler line:

# RHEL family
sudo crontab -u apache -l | grep schedule:run
# Ubuntu
sudo crontab -u www-data -l | grep schedule:run

* * * * * cd /var/www/html/rconfig8/current && php artisan schedule:run >> /dev/null 2>&1

The Worker Privilege health check and sudo php artisan rconfig:check-worker-user confirm all of this. See Worker Privilege for every message and its fix.

Keep root out of the scheduler

Do not add schedule:run to root’s crontab, and do not run php artisan schedule:run or health:check by hand as root. A root run leaves root-owned files in storage and raises the Worker Privilege warning for 15 minutes.

Storage Permissions

The storage folder holds saved device configs, which often contain secrets. From V8.4.1, rConfig keeps other local users out of it:

What	Mode
New folders rConfig creates under storage	0750
Device config files while rConfig writes them	0640
Saved device config files	0440

The deploy script no longer runs chmod 755 on storage. Configs saved by earlier versions are usually 0444 in 0755 folders, readable by every account on the host, and keep those modes until you run rconfig:set-config-permissions:

cd /var/www/html/rconfig8/current

# See how many files and folders would change
sudo php artisan rconfig:set-config-permissions --dry-run

# Set them
sudo php artisan rconfig:set-config-permissions

It sets saved configs to 0440 and their folders to 0750 under data, tempdir and policy_reports. It is safe to re-run: anything already correct is left alone. See rconfig:set-config-permissions for every option.

The Security & privileges card on Settings > System Management > System Optimization checks three folders:

Row	Folder	Fails when	Warns when
Storage folder	/var/www/html/rconfig8/current/storage	Other users can write to it
rConfig storage folder	…/storage/app/rconfig	Other users can write to it
Config folder	…/storage/app/rconfig/data	Other users can write to it	Other users can read or list it

Each row prints the path and its mode, for example /var/www/html/rconfig8/current/storage/app/rconfig/data is 0755, so any local user can list the saved device configs., and the command that fixes it.

Fix a world-readable config folder. Run the command the row shows. It sets the folder, every folder below it and every saved config:

cd /var/www/html/rconfig8/current
sudo php artisan rconfig:set-config-permissions

rconfig:clear-all also warns at the end of its run if it finds saved configs other users can read.

Fix a storage folder other users can write to:

sudo chmod o-w /var/www/html/rconfig8/current/storage
sudo chmod o-w /var/www/html/rconfig8/current/storage/app/rconfig

Refresh the System Optimization page to recheck.

Never open storage to every user

Do not run chmod -R 755, 775 or 777 on storage, and do not change saved configs back to 0644. If the web server cannot read a file, fix its owner (chown apache:apache, or www-data:www-data on Ubuntu), not its mode.

Redis Hardening

rConfig uses Redis for its job queue, cache, and sessions. Horizon workers read jobs from the queue and run them, so anyone who can write to Redis can make a worker run code. Requiring a Redis password is the control that closes this. Binding Redis to 127.0.0.1 is not enough on its own: any local process can still reach a loopback listener.

From V8.4.1, the Redis Auth health check and the redis_auth row on System Settings >> System Optimization report whether Redis requires a password. Check and secure it from the rConfig folder:

cd /var/www/html/rconfig8/current
php artisan rconfig:redis-security-check
php artisan rconfig:redis-secure

rconfig:redis-secure generates a strong password, writes it to REDIS_PASSWORD in .env, requires it on the live Redis, saves it to the Redis config file, and restarts Horizon, the queue workers, and the SNMP trap handler. It is safe to re-run, and rolls .env back if Redis rejects the change. See Redis Authentication for every message and how to fix it.

• Shared Redis: If other rConfig nodes use the same Redis, the command prints a warning and those nodes are locked out until REDIS_PASSWORD is copied to their .env and they are restarted.
• Persist the password: If the command warns that CONFIG REWRITE failed, add requirepass to the Redis config file by hand so the password survives a Redis restart.
• Keep Redis off the network: Leave Redis bound to 127.0.0.1 with protected mode on, and never expose port 6379 through the host firewall. This limits who can reach it, but does not replace the password.
• Keep the password off the command line: Use redis-cli --askpass or the REDISCLI_AUTH environment variable rather than redis-cli -a, which leaks the password to shell history and the process list.
• Protect .env: The Redis password lives in .env alongside the application encryption key. Keep the file readable only by root and the web server user.
• Rotate after exposure: If you suspect the password has leaked, run php artisan rconfig:redis-secure --force to replace it.

Credential Security

• Secure Password Storage: Implement cryptographically secure hashing algorithms (e.g., bcrypt, Argon2) for password storage.
• Password Policy Enforcement: Establish and enforce password complexity requirements including minimum length, character diversity, and rotation policies.
• User Interface Security:
  • Configure secure input controls for credential entry, disabling browser auto-completion and clipboard operations.
  • Implement CAPTCHA or equivalent challenge-response mechanisms to prevent automated brute-force attacks.
• Secrets Management: Utilize enterprise secrets management solutions (e.g., AWS Secrets Manager, HashiCorp Vault) for API keys and system credentials.
• Session Security: Configure session cookies with secure, HTTP-only, and SameSite attributes to prevent session hijacking.

Data Protection and Encryption

Comprehensive data protection requires encryption for both data in transit and data at rest:

• Transport Encryption: Implement TLS/SSL encryption for all network communications. Ensure HTTPS enforcement across all web interfaces and API endpoints. Maintain current TLS certificates issued by trusted certificate authorities. New installs run on plain HTTP. From V8.4.1, sudo php artisan rconfig:ssl-self-signed switches to HTTPS with a self-signed certificate in one step, which you can later replace with a trusted one. Reference: SSL Configuration Guide.
• Storage Encryption: Deploy full-disk encryption (e.g., LUKS for Linux, BitLocker for Windows) for all storage volumes containing sensitive data. Implementation details: Configuration Encryption.
• Database Security: Implement encryption for sensitive database fields and enforce strong authentication for database access. rConfig encrypts credentials and sensitive data by default, with encryption keys stored in the .env file. This file requires secure backup procedures. Ensure regular encrypted database backups.
• Backup Encryption: Encrypt all backup media, both on-site and off-site storage, to protect data confidentiality in case of unauthorized access.

Database Platform Security

Customer Responsibility

Database infrastructure security remains entirely the customer’s responsibility. rConfig applications connect to customer-managed database instances, requiring comprehensive hardening of the database platform and surrounding infrastructure.

Securing the database platform hosting rConfig data requires attention to multiple security layers:

Database Server Hardening

• Operating System Hardening: Apply identical OS hardening procedures to database servers as outlined in the Server and Endpoint Hardening section.
• Database Service Configuration:
  • Disable unnecessary database features and modules (e.g., xp_cmdshell in SQL Server, file_priv in MySQL)
  • Configure database services to operate under dedicated service accounts with minimal privileges
  • Remove or disable default database accounts and sample databases
  • Configure appropriate connection timeout values to prevent resource exhaustion

Database Network Security

• Network Isolation: Deploy database servers in isolated network segments (database tier) separate from application and web tiers.
• Port Security:
  • Modify default database ports where operationally feasible (MySQL 3306, PostgreSQL 5432)
  • Implement firewall rules restricting database port access to authorized application servers exclusively
  • Enforce database connection encryption (SSL/TLS) for all connections
• Connection Management: Configure maximum concurrent connection limits to prevent denial-of-service conditions.

Database Access Controls

• Privilege Separation: Create dedicated database accounts for distinct application functions with minimum required privileges.
• Connection Security: Configure connection strings requiring SSL/TLS and certificate validation.
• Audit Logging: Enable comprehensive database audit logging for:
  • Authentication failures
  • Privilege escalation attempts
  • Data Definition Language (DDL) modifications
  • Bulk data operations

Database Backup Security

• Backup Encryption: Encrypt all database backups using industry-standard encryption algorithms.
• Backup Storage: Store encrypted backups in secure locations physically separated from production database infrastructure.
• Backup Validation: Conduct regular backup restoration tests to verify data integrity and recovery procedures.
• Access Control: Implement strict access controls for backup media and authenticate all backup system access.

Monitoring and Alerting

Integration Requirements

Effective security monitoring requires integration with organizational Security Information and Event Management (SIEM), log management platforms, and alerting infrastructure. Correlate rConfig monitoring data with security events across the enterprise environment for comprehensive threat detection.

Comprehensive monitoring and alerting capabilities are essential for security incident detection and system health maintenance:

Infrastructure Monitoring

• System Resource Monitoring:

  • Monitor CPU utilization patterns for anomalous activity indicating potential cryptocurrency mining or malicious processes
  • Track memory consumption with alerts for rapid memory growth patterns
  • Monitor storage utilization and I/O patterns
  • Configure alerts for system service failures or unexpected process restarts

• Network Traffic Analysis:

  • Monitor outbound connections from rConfig servers for unauthorized destinations
  • Track data transfer volumes and patterns to detect potential data exfiltration
  • Implement alerting for connections to known malicious IP addresses or command-and-control infrastructure
  • Monitor for lateral movement attempts within the network

• File System Integrity:

  • Implement File Integrity Monitoring (FIM) for critical system files and directories
  • Monitor rConfig application directories for unauthorized modifications
  • Track configuration file changes, particularly .env files containing encryption keys
  • Alert on creation of suspicious files or directories

Security Event Monitoring

• Authentication Monitoring:

  • Log and alert on failed authentication attempts, particularly patterns indicating brute-force attacks
  • Monitor for anomalous login times or geographic locations
  • Track privilege escalation events
  • Alert on multiple concurrent sessions for individual user accounts

• Application Security Monitoring:

  • Analyze web server access logs for suspicious patterns or attack signatures
  • Monitor database query patterns for potential SQL injection attempts
  • Alert on API usage anomalies or rate limit violations
  • Monitor unauthorized access attempts to privileged endpoints

Log Management

• Centralized Log Collection: Forward all rConfig system logs to centralized SIEM infrastructure for correlation and analysis.
• Log Retention: Maintain log retention periods compliant with organizational and regulatory requirements.
• Event Correlation: Implement correlation rules to identify attack patterns across multiple systems and data sources.
• Automated Response: Configure automated response actions for critical security events (e.g., account lockouts, service isolation, incident ticket creation).

Business Continuity and Disaster Recovery

Enterprise Feature

This section applies to rConfig Vector and Enterprise customers requiring high availability and comprehensive disaster recovery capabilities for mission-critical network management operations.

Enterprise business continuity planning ensures operational resilience during both planned maintenance and unexpected disruptions:

rConfig High Availability Support

rConfig Vector and Enterprise editions include native support for high availability and disaster recovery architectures. For detailed implementation guidance, consult the High Availability Configuration Guide. Contact rConfig support for assistance with specific business continuity requirements.

High Availability Architecture

• Redundancy and Load Balancing:

  • Deploy multiple rConfig application servers in active-active configuration behind load balancers
  • Implement database clustering or master-replica replication for database high availability
  • Utilize shared storage solutions or database replication to maintain data consistency across instances
  • Configure automated failover mechanisms with comprehensive health checks

• Geographic Distribution:

  • Consider multi-site deployments for geographically distributed organizations
  • Implement database replication across sites with replication lag monitoring
  • Ensure secure network connectivity between sites

Disaster Recovery Planning

• Recovery Objectives:

  • Define Recovery Time Objectives (RTO) specifying acceptable downtime thresholds
  • Establish Recovery Point Objectives (RPO) defining maximum acceptable data loss
  • Document detailed recovery procedures with step-by-step instructions
  • Conduct regular disaster recovery exercises and maintain current documentation

• Backup and Restoration:

  • Implement automated, encrypted backups of application data and system configurations
  • Maintain backups in multiple geographic locations including off-site facilities
  • Conduct monthly backup integrity testing and restoration procedures
  • Document bare-metal recovery procedures for complete system reconstruction

Operational Continuity

• Change Management:

  • Establish formal change management procedures for system updates and maintenance
  • Schedule maintenance windows during minimal-impact periods
  • Implement rolling update procedures maintaining service availability
  • Maintain emergency rollback procedures

• Incident Response:

  • Define escalation procedures for system outages and security incidents
  • Maintain current stakeholder contact information
  • Establish communication protocols for system status notifications
  • Document post-incident review processes for continuous improvement

Monitoring and Testing

• Availability Monitoring:

  • Implement comprehensive uptime monitoring with external monitoring services
  • Configure automated health checks for all system components
  • Establish alerting thresholds aligned with RTO requirements
  • Monitor key performance indicators (KPIs) for system health

• Recovery Testing:

  • Conduct quarterly disaster recovery exercises with complete system restoration
  • Perform annual business continuity exercises involving all stakeholders
  • Test failover procedures under controlled conditions
  • Document and remediate issues identified during testing exercises

Documentation and Training

• Operational Documentation:

  • Maintain comprehensive operational runbooks for all administrative tasks
  • Document custom configurations and third-party integrations
  • Maintain current emergency contact lists and escalation procedures
  • Ensure documentation accessibility during outage scenarios

• Personnel Training:

  • Provide regular training on disaster recovery procedures
  • Cross-train multiple personnel on critical system operations
  • Conduct tabletop exercises for incident response scenarios
  • Maintain current technical certifications for key personnel

Related Installation Guides:

• rConfig V8 Professional Installation
• rConfig Vector Server Installation
• rConfig Vector Agent Installation

Backup Strategy

To protect against ransomware, hardware failures, and other threats, implement comprehensive backup strategies. While rConfig provides basic backup functionality for convenience, this feature cannot protect against compromised storage systems or infrastructure failures. Organizations must implement enterprise backup solutions aligned with corporate data protection policies to ensure business continuity.

CRITICAL: Enterprise Backup Requirements

Enterprise environments MUST implement comprehensive backup and recovery strategies:

• Database Backups: Create complete database backups including all configuration data, device inventories, compliance records, and historical data
• System Snapshots: Take full system snapshots or virtual machine snapshots for virtualized deployments
• Configuration Files: Backup all rConfig configuration files, custom scripts, integration configurations, and encryption keys
• Backup Validation: Test backup restoration procedures regularly. Untested backups represent unverified recovery capabilities
• Recovery Documentation: Maintain documented, tested recovery procedures accessible to operations personnel

Production systems must not be updated without verified, tested backups. System failures, data corruption, or compatibility issues during updates can result in extended downtime and data loss in enterprise environments.

Verify completion of all enterprise backup procedures with your system administrator or backup team before proceeding with system changes.