ReconBF: HP Enterprise's Read-Only Security Scanner That Checks What Your Hardening Scripts Forgot

Hook

Most security scanners tell you about vulnerable packages or open ports. ReconBF asks a different question: did you actually compile that binary with stack protection, and is your kernel really enforcing ASLR?

Context

System hardening guides are everywhere—CIS benchmarks, STIG checklists, DevSec Ansible roles—but verification is manual and error-prone. You can follow a 200-step hardening procedure, deploy it across your infrastructure, and still have no programmatic way to confirm that every setting stuck, especially after kernel updates or configuration drift.

ReconBF emerged from HP Enterprise's need to validate hardening at scale without disrupting production systems. Unlike vulnerability scanners that look for known CVEs or configuration management tools that enforce state, ReconBF operates in pure read-only mode, checking the actual runtime security posture of Linux systems. It bridges the gap between "we deployed the hardening playbook" and "the system is actually hardened," checking everything from compiler flags baked into binaries to kernel security features that might have been disabled by a rogue sysctl change.

Technical Insight

ReconBF's architecture separates test logic from system interrogation through a clean abstraction layer. Each security check is a self-contained module that inherits from a base TestModule class, making the codebase extensible without modifying core infrastructure. Tests are organized by category—sysctl, applications, files, kernel—and each returns structured results with pass/fail states and human-readable explanations.

The module system is elegantly simple. Here's how a typical security check is structured:

from reconbf.modules import test_class
from reconbf.lib import test_module
from reconbf.lib.result import Result, GroupTestResult

@test_class
class KernelASLRCheck(test_module.TestModule):
    name = "Kernel ASLR Configuration"
    
    def run_tests(self, config):
        results = GroupTestResult()
        
        # Check sysctl setting
        aslr_value = self._read_sysctl('kernel.randomize_va_space')
        
        if aslr_value == '2':
            results.add_result("ASLR fully enabled", Result.PASS)
        elif aslr_value == '1':
            results.add_result("ASLR partially enabled (libs only)", Result.FAIL)
        else:
            results.add_result("ASLR disabled", Result.FAIL)
            
        return results

What makes ReconBF particularly valuable is its binary analysis capability. While most hardening scanners check configuration files, ReconBF actually inspects compiled binaries to verify they were built with security features. It uses Python's ELF parsing capabilities to check for stack canaries, position-independent executable (PIE) compilation, RELRO (relocation read-only) protections, and other compiler-level hardening flags. This catches a class of problems that configuration scanners miss entirely—like discovering that a critical daemon was compiled without stack protection because someone used the wrong build flags three years ago.

The tool's configuration system uses JSON files to define test suites and parameters, allowing teams to codify their specific security baselines:

{
  "name": "Production Server Baseline",
  "tests": [
    {
      "module": "reconbf.modules.test_sec",
      "test": "TestKernelModules",
      "config": {
        "blacklist": ["dccp", "sctp", "rds", "tipc"]
      }
    },
    {
      "module": "reconbf.modules.test_sysctl",
      "test": "TestSysctl",
      "config": {
        "required": {
          "net.ipv4.conf.all.accept_source_route": "0",
          "net.ipv4.conf.default.accept_source_route": "0",
          "net.ipv4.tcp_syncookies": "1"
        }
      }
    }
  ]
}

This configuration-as-code approach means your security baseline becomes version-controlled and reproducible. Teams can maintain different profiles for different server roles—web servers get one configuration checking for specific Apache/Nginx hardening, database servers get another validating PostgreSQL or MySQL security settings.

The output system deserves mention for its pragmatism. ReconBF can export results as CSV for spreadsheet analysis, JSON for programmatic consumption, or HTML for human review. The --display flag controls verbosity: all shows every check, fail shows only problems, overall gives a summary, and notpass includes both failures and checks that couldn't run (usually due to missing information). This last mode is crucial for troubleshooting—it tells you when a test couldn't execute, which often indicates a deeper problem like missing kernel config access.

One architectural choice that stands out is the deliberate decision to avoid any write operations. ReconBF never attempts remediation, never modifies files, and never changes system state. This makes it safe to run in production during business hours without change approval processes. The trade-off is that it won't fix anything—it's purely an assessment tool—but that constraint is exactly what makes it trustworthy for production use.

Gotcha

ReconBF's biggest limitation is right in the README: it's not designed to detect sophisticated attackers. The tool uses straightforward file reads and system calls that a competent rootkit would trivially bypass. If an attacker has kernel-level access, they can make ReconBF see whatever they want. This isn't a weakness per se—it's just not the tool's purpose. ReconBF validates hardening configurations, not integrity or active compromise.

The other significant limitation is test coverage for modern systems. With only 47 GitHub stars and unclear maintenance status, it's uncertain whether ReconBF includes checks for recent kernel security features like Lockdown LSM, or modern container security configurations. Before adopting it, you'll need to audit the test modules to ensure they cover your required security controls. Some tests also produce ambiguous results when system information is unavailable—if the kernel config isn't accessible at /proc/config.gz or /boot/config-*, certain checks simply can't run, leaving gaps in your assessment. The tool reports these as "not passed" rather than failures, which requires manual investigation to determine if it's a scanning limitation or actual missing hardening.

Verdict

Use if: You need to validate Linux hardening at scale without risking production stability, want to codify security baselines as version-controlled test suites, or need to verify binary-level protections (stack canaries, PIE, RELRO) that configuration scanners miss. It's particularly valuable for validating golden images before deployment or conducting periodic drift detection on running systems. Skip if: You need active threat detection, rootkit scanning, or integrity monitoring—ReconBF is purely a configuration validator. Also skip if you require Windows/macOS support, need checks for very recent kernel features, or want automated remediation. For those cases, look at Lynis for broader coverage with active maintenance, OpenSCAP for compliance framework integration, or Ansible/Chef hardening cookbooks if you want enforcement rather than just detection.