From 2732e4681f5a7650b62bf39637f3e5b44ee9170e Mon Sep 17 00:00:00 2001 From: "Jonathan D.A. Jewell" <6759885+hyperpolymath@users.noreply.github.com> Date: Mon, 24 Aug 2026 08:40:40 +0100 Subject: [PATCH] refactor: migrate repository documentation from Markdown to AsciiDoc --- ARCHITECTURE.adoc | 48 ++ ARCHITECTURE.md | 47 -- CHANGELOG.adoc | 400 +++++---- CHANGELOG.md | 234 ------ CODE_OF_CONDUCT.adoc | 175 ++++ CODE_OF_CONDUCT.md | 171 ---- CONTRIBUTING.adoc | 3 + CONTRIBUTING.md | 3 - GOVERNANCE.adoc | 60 ++ GOVERNANCE.md | 60 -- MAINTAINERS.adoc | 201 ++++- MAINTAINERS.md | 183 ----- PROJECT_SUMMARY.adoc | 583 +++++++++++++ PROJECT_SUMMARY.md | 633 -------------- PROOF-NEEDS.adoc | 52 ++ PROOF-NEEDS.md | 43 - RSR_COMPLIANCE.adoc | 353 ++++++++ RSR_COMPLIANCE.md | 378 --------- SECURITY.adoc | 307 +++++++ SECURITY.md | 316 ------- TEST-NEEDS.adoc | 42 + TEST-NEEDS.md | 35 - TOPOLOGY.md => TOPOLOGY.adoc | 39 +- TPCF.adoc | 466 +++++++++++ TPCF.md | 482 ----------- docs/tech-debt-2026-05-26.adoc | 66 ++ docs/tech-debt-2026-05-26.md | 60 -- hinfo_loc_fluctuator/README.adoc | 115 +++ hinfo_loc_fluctuator/README.md | 109 --- hinfo_loc_fluctuator_ada/README.adoc | 361 ++++++++ hinfo_loc_fluctuator_ada/README.md | 346 -------- .../docs/ENTERPRISE_FEATURES.adoc | 756 +++++++++++++++++ .../docs/ENTERPRISE_FEATURES.md | 773 ------------------ hinfo_loc_fluctuator_ada/docs/USE_CASES.adoc | 543 ++++++++++++ hinfo_loc_fluctuator_ada/docs/USE_CASES.md | 505 ------------ llm-warmup-dev.adoc | 19 + llm-warmup-dev.md | 16 - llm-warmup-user.adoc | 19 + llm-warmup-user.md | 16 - 39 files changed, 4352 insertions(+), 4666 deletions(-) create mode 100644 ARCHITECTURE.adoc delete mode 100644 ARCHITECTURE.md delete mode 100644 CHANGELOG.md create mode 100644 CODE_OF_CONDUCT.adoc delete mode 100644 CODE_OF_CONDUCT.md create mode 100644 CONTRIBUTING.adoc delete mode 100644 CONTRIBUTING.md create mode 100644 GOVERNANCE.adoc delete mode 100644 GOVERNANCE.md delete mode 100644 MAINTAINERS.md create mode 100644 PROJECT_SUMMARY.adoc delete mode 100644 PROJECT_SUMMARY.md create mode 100644 PROOF-NEEDS.adoc delete mode 100644 PROOF-NEEDS.md create mode 100644 RSR_COMPLIANCE.adoc delete mode 100644 RSR_COMPLIANCE.md create mode 100644 SECURITY.adoc delete mode 100644 SECURITY.md create mode 100644 TEST-NEEDS.adoc delete mode 100644 TEST-NEEDS.md rename TOPOLOGY.md => TOPOLOGY.adoc (88%) create mode 100644 TPCF.adoc delete mode 100644 TPCF.md create mode 100644 docs/tech-debt-2026-05-26.adoc delete mode 100644 docs/tech-debt-2026-05-26.md create mode 100644 hinfo_loc_fluctuator/README.adoc delete mode 100644 hinfo_loc_fluctuator/README.md create mode 100644 hinfo_loc_fluctuator_ada/README.adoc delete mode 100644 hinfo_loc_fluctuator_ada/README.md create mode 100644 hinfo_loc_fluctuator_ada/docs/ENTERPRISE_FEATURES.adoc delete mode 100644 hinfo_loc_fluctuator_ada/docs/ENTERPRISE_FEATURES.md create mode 100644 hinfo_loc_fluctuator_ada/docs/USE_CASES.adoc delete mode 100644 hinfo_loc_fluctuator_ada/docs/USE_CASES.md create mode 100644 llm-warmup-dev.adoc delete mode 100644 llm-warmup-dev.md create mode 100644 llm-warmup-user.adoc delete mode 100644 llm-warmup-user.md diff --git a/ARCHITECTURE.adoc b/ARCHITECTURE.adoc new file mode 100644 index 0000000..1c0a7a6 --- /dev/null +++ b/ARCHITECTURE.adoc @@ -0,0 +1,48 @@ +== Architecture + +=== Overview + +This repository follows a modular, maintainable architecture designed +for clarity, scalability, and long-term sustainability. + +=== Directory Structure + +.... +. +├── src/ # Source code +├── tests/ # Test suites +├── docs/ # Documentation +├── scripts/ # Utility scripts +├── config/ # Configuration files +├── LICENSE # License file +├── LICENSES/ # Full license texts +└── README.adoc # Project documentation +.... + +=== Design Principles + +* *Separation of Concerns*: Each module has a single responsibility +* *Testability*: Code is written to be easily testable +* *Documentation*: All public APIs are documented +* *Configuration*: Environment-specific settings are externalized + +=== Dependencies + +* External dependencies are minimized and clearly declared +* Version pinning is used for reproducibility + +=== Security Considerations + +* Sensitive data is never committed to the repository +* Secrets are managed through environment variables or secure vaults +* Regular dependency audits are performed + +=== Maintainability + +* Code follows consistent style guidelines +* Pull requests require review and CI checks +* Issues and discussions are tracked transparently + +''''' + +_Last updated: 2026-07-18_ diff --git a/ARCHITECTURE.md b/ARCHITECTURE.md deleted file mode 100644 index 607e3d8..0000000 --- a/ARCHITECTURE.md +++ /dev/null @@ -1,47 +0,0 @@ -# Architecture - -## Overview - -This repository follows a modular, maintainable architecture designed for clarity, scalability, and long-term sustainability. - -## Directory Structure - -``` -. -├── src/ # Source code -├── tests/ # Test suites -├── docs/ # Documentation -├── scripts/ # Utility scripts -├── config/ # Configuration files -├── LICENSE # License file -├── LICENSES/ # Full license texts -└── README.adoc # Project documentation -``` - -## Design Principles - -- **Separation of Concerns**: Each module has a single responsibility -- **Testability**: Code is written to be easily testable -- **Documentation**: All public APIs are documented -- **Configuration**: Environment-specific settings are externalized - -## Dependencies - -- External dependencies are minimized and clearly declared -- Version pinning is used for reproducibility - -## Security Considerations - -- Sensitive data is never committed to the repository -- Secrets are managed through environment variables or secure vaults -- Regular dependency audits are performed - -## Maintainability - -- Code follows consistent style guidelines -- Pull requests require review and CI checks -- Issues and discussions are tracked transparently - ---- - -*Last updated: 2026-07-18* diff --git a/CHANGELOG.adoc b/CHANGELOG.adoc index dd2a898..61d21c5 100644 --- a/CHANGELOG.adoc +++ b/CHANGELOG.adoc @@ -1,235 +1,227 @@ -// SPDX-License-Identifier: CC-BY-SA-4.0 -= Changelog - -All notable changes to the HINFO-LOC Fluctuator project will be documented in this file. - -The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/), -and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html). - -== [Unreleased] - -=== Added -- RSR (Rhodium Standard Repository) compliance framework -- `.well-known/` directory with RFC 9116 security.txt, ai.txt, humans.txt -- Comprehensive governance documents (SECURITY.md, CONTRIBUTING.md, CODE_OF_CONDUCT.md, MAINTAINERS.md) -- TPCF (Tri-Perimeter Contribution Framework) documentation -- Justfile for modern build automation -- Dual licensing (MIT + Palimpsest v0.8) -- RSR compliance self-verification script - -=== Changed -- Updated documentation to reflect Silver Tier RSR compliance (77%) - -== [2.0.0] - 2025-11-22 - -=== Added - Enterprise Features - -**Extended DNS Records** (~500 lines) -- Support for 20+ DNS record types (A, AAAA, MX, NS, CNAME, PTR, TXT, SPF, DKIM, DMARC, CAA, TLSA, SSHFP, APL, SRV, NAPTR, DS, DNSKEY, NSEC, NSEC3) -- IPv4/IPv6 address parsing and conversion -- Zone file format generation for all record types -- APL record CIDR matching for IP-based access control -- DNS topology modes (Standard, Split-Horizon, Primary-Primary, Hidden-Primary) -- AXFR configuration for zone transfers - -**Firewall Management** (~460 lines) -- Dynamic port rotation with time-based algorithm - - Algorithm: `port = base_port + (unix_timestamp / interval) % range` - - Maintainers can calculate current port offline -- Service scheduling with time windows (MX, RSS, NNTP) -- Support for 4 firewall backends (firewalld, iptables, nftables, pf) -- Maintenance window tracking and enforcement -- Port knocking setup -- IPv4/IPv6 protocol mode control -- Emergency lockdown and recovery operations - -**Security Headers** (~500 lines) -- HTTP security header generation (HSTS, CSP, X-Frame-Options, Referrer-Policy, Permissions-Policy, COEP, COOP, CORP) -- Diagnostic mode - real stack visible only to authorized IPs with secret token -- Server/X-Powered-By obfuscation with randomized fake values -- CSP nonce generation for inline scripts -- Web server configuration generation (nginx, Apache, PHP) -- HINFO record synchronization for consistent fake stacks -- All experimental security headers - -**Zero-Trust SDP** (~470 lines) -- Software-Defined Perimeter architecture (NIST SP 800-207 compliant) -- Single Packet Authorization (SPA) processing framework -- Multi-factor authentication support -- Device posture validation (OS version, antivirus, firewall, encryption, patch level) -- Session management with continuous verification and re-authentication -- Policy evaluation and enforcement -- Micro-segmentation for network isolation -- Security event logging - -**Protocol Management** (~450 lines) -- SNMP v1/v2c/v3 support with security warnings for insecure versions -- NETCONF server implementation (RFC 6241, recommended over SNMP) -- RESTCONF RESTful API support (RFC 8040) -- gNMI modern gRPC-based protocol (recommended) -- Prometheus/OpenMetrics metrics export -- Security validation and protocol recommendations -- Firewall and SDP integration - -**Master Configuration** (~450 lines) -- 5 deployment profiles (Development, Staging, Production, Honeypot, Research) -- Configuration validation with comprehensive security checks -- Security posture reporting -- Configuration file operations (INI, YAML, JSON export) -- Hot reload - apply configuration changes without restart -- Migration from legacy config format -- Configuration comparison and diff generation -- Emergency configurations (lockdown, recovery, minimal safe modes) - -=== Added - Documentation - -- `ENTERPRISE_FEATURES.md` - Comprehensive enterprise feature guide (350+ lines) -- `examples/production_config.yaml` - Production configuration example (310 lines) -- `PROJECT_SUMMARY.md` - Complete project transformation summary -- Updated `CLAUDE.md` with implementation status -- Updated root `README.md` with enterprise features overview - -=== Changed - -- Project evolved from basic HINFO/LOC fluctuation to full enterprise DNS security platform -- Total codebase: 2,000 → 16,000+ lines -- Core modules: 6 → 20 (14 new modules) - -== [1.0.0] - 2025-11 (Previous Work) - -=== Added - Core Features - -**Type-Safe DNS Records** (~140 lines) -- HINFO record support (CPU, OS) -- LOC record support (latitude, longitude, altitude) -- Compile-time bounds checking for all geographic coordinates -- DNS classes (IN, CH, HS) -- TTL range constraints (1-604800 seconds) - -**Authentication Module** (~110 lines) -- Permission levels (None, Read-Only, Modify-Local, Modify-Remote, Admin) -- Session timeout (30 minutes default) -- Constant-time password comparison (timing attack prevention) -- Replay attack detection (nonce-based) - -**Randomization Engine** (~200 lines) -- CSV parser for location data -- Random selection from data pools -- Configurable randomization intervals - -**Text User Interface** (~350 lines) -- Interactive menu system -- ANSI color support -- Permission-based menu filtering -- Login screen - -**Zone File Writer** (~180 lines) -- BIND-format zone file generation -- SOA record generation -- RFC 1912 serial format (YYYYMMDDnn) -- Atomic file writes - -**Logger** (~150 lines) -- Thread-safe audit logging -- Protected types for concurrent access -- Structured log entries - -**Scheduler** (~150 lines) -- Scheduled auto-fluctuation with Ada tasking -- Start/Stop/Pause/Resume control -- Configurable intervals - -**DNS UPDATE Framework** (~120 lines) -- RFC 2136 dynamic update framework +== Changelog + +All notable changes to the HINFO-LOC Fluctuator project will be +documented in this file. + +The format is based on https://keepachangelog.com/en/1.0.0/[Keep a +Changelog], and this project adheres to +https://semver.org/spec/v2.0.0.html[Semantic Versioning]. + +=== [Unreleased] + +==== Added + +* RSR (Rhodium Standard Repository) compliance framework +* `+.well-known/+` directory with RFC 9116 security.txt, ai.txt, +humans.txt +* Comprehensive governance documents (SECURITY.md, CONTRIBUTING.md, +CODE_OF_CONDUCT.md, MAINTAINERS.md) +* TPCF (Tri-Perimeter Contribution Framework) documentation +* Justfile for modern build automation +* Dual licensing (MIT + Palimpsest v0.8) +* RSR compliance self-verification script + +==== Changed + +* Updated documentation to reflect Silver Tier RSR compliance (77%) + +=== [2.0.0] - 2025-11-22 + +==== Added - Enterprise Features + +*Extended DNS Records* (~500 lines) - Support for 20+ DNS record types +(A, AAAA, MX, NS, CNAME, PTR, TXT, SPF, DKIM, DMARC, CAA, TLSA, SSHFP, +APL, SRV, NAPTR, DS, DNSKEY, NSEC, NSEC3) - IPv4/IPv6 address parsing +and conversion - Zone file format generation for all record types - APL +record CIDR matching for IP-based access control - DNS topology modes +(Standard, Split-Horizon, Primary-Primary, Hidden-Primary) - AXFR +configuration for zone transfers + +*Firewall Management* (~460 lines) - Dynamic port rotation with +time-based algorithm - Algorithm: +`+port = base_port + (unix_timestamp / interval) % range+` - Maintainers +can calculate current port offline - Service scheduling with time +windows (MX, RSS, NNTP) - Support for 4 firewall backends (firewalld, +iptables, nftables, pf) - Maintenance window tracking and enforcement - +Port knocking setup - IPv4/IPv6 protocol mode control - Emergency +lockdown and recovery operations + +*Security Headers* (~500 lines) - HTTP security header generation (HSTS, +CSP, X-Frame-Options, Referrer-Policy, Permissions-Policy, COEP, COOP, +CORP) - Diagnostic mode - real stack visible only to authorized IPs with +secret token - Server/X-Powered-By obfuscation with randomized fake +values - CSP nonce generation for inline scripts - Web server +configuration generation (nginx, Apache, PHP) - HINFO record +synchronization for consistent fake stacks - All experimental security +headers + +*Zero-Trust SDP* (~470 lines) - Software-Defined Perimeter architecture +(NIST SP 800-207 compliant) - Single Packet Authorization (SPA) +processing framework - Multi-factor authentication support - Device +posture validation (OS version, antivirus, firewall, encryption, patch +level) - Session management with continuous verification and +re-authentication - Policy evaluation and enforcement - +Micro-segmentation for network isolation - Security event logging + +*Protocol Management* (~450 lines) - SNMP v1/v2c/v3 support with +security warnings for insecure versions - NETCONF server implementation +(RFC 6241, recommended over SNMP) - RESTCONF RESTful API support (RFC +8040) - gNMI modern gRPC-based protocol (recommended) - +Prometheus/OpenMetrics metrics export - Security validation and protocol +recommendations - Firewall and SDP integration + +*Master Configuration* (~450 lines) - 5 deployment profiles +(Development, Staging, Production, Honeypot, Research) - Configuration +validation with comprehensive security checks - Security posture +reporting - Configuration file operations (INI, YAML, JSON export) - Hot +reload - apply configuration changes without restart - Migration from +legacy config format - Configuration comparison and diff generation - +Emergency configurations (lockdown, recovery, minimal safe modes) + +==== Added - Documentation + +* `+ENTERPRISE_FEATURES.md+` - Comprehensive enterprise feature guide +(350+ lines) +* `+examples/production_config.yaml+` - Production configuration example +(310 lines) +* `+PROJECT_SUMMARY.md+` - Complete project transformation summary +* Updated `+CLAUDE.md+` with implementation status +* Updated root `+README.md+` with enterprise features overview + +==== Changed + +* Project evolved from basic HINFO/LOC fluctuation to full enterprise +DNS security platform +* Total codebase: 2,000 → 16,000+ lines +* Core modules: 6 → 20 (14 new modules) + +=== [1.0.0] - 2025-11 (Previous Work) + +==== Added - Core Features + +*Type-Safe DNS Records* (~140 lines) - HINFO record support (CPU, OS) - +LOC record support (latitude, longitude, altitude) - Compile-time bounds +checking for all geographic coordinates - DNS classes (IN, CH, HS) - TTL +range constraints (1-604800 seconds) + +*Authentication Module* (~110 lines) - Permission levels (None, +Read-Only, Modify-Local, Modify-Remote, Admin) - Session timeout (30 +minutes default) - Constant-time password comparison (timing attack +prevention) - Replay attack detection (nonce-based) + +*Randomization Engine* (~200 lines) - CSV parser for location data - +Random selection from data pools - Configurable randomization intervals + +*Text User Interface* (~350 lines) - Interactive menu system - ANSI +color support - Permission-based menu filtering - Login screen + +*Zone File Writer* (~180 lines) - BIND-format zone file generation - SOA +record generation - RFC 1912 serial format (YYYYMMDDnn) - Atomic file +writes + +*Logger* (~150 lines) - Thread-safe audit logging - Protected types for +concurrent access - Structured log entries + +*Scheduler* (~150 lines) - Scheduled auto-fluctuation with Ada tasking - +Start/Stop/Pause/Resume control - Configurable intervals + +*DNS UPDATE Framework* (~120 lines) - RFC 2136 dynamic update framework - TSIG authentication specification (needs crypto library) -=== Added - Data Files +==== Added - Data Files -- `machines.txt` - 68 CPU types (Intel, AMD, ARM, historical, fictional) -- `operating_systems.txt` - 77 operating systems (Linux, BSD, Windows, historical, fictional) -- `locations.csv` - 52 geographic locations (data centers, exotic locations) +* `+machines.txt+` - 68 CPU types (Intel, AMD, ARM, historical, +fictional) +* `+operating_systems.txt+` - 77 operating systems (Linux, BSD, Windows, +historical, fictional) +* `+locations.csv+` - 52 geographic locations (data centers, exotic +locations) -=== Added - Build System +==== Added - Build System -- GNAT project file (`hinfo_loc_fluctuator.gpr`) -- Makefile with debug, release, prove targets -- Security flags always enabled (`-gnoto`, `-fstack-check`, `-gnatVa`) -- SPARK verification mode +* GNAT project file (`+hinfo_loc_fluctuator.gpr+`) +* Makefile with debug, release, prove targets +* Security flags always enabled (`+-gnoto+`, `+-fstack-check+`, +`+-gnatVa+`) +* SPARK verification mode -=== Added - Documentation +==== Added - Documentation -- `README.md` - Main project documentation (450+ lines) -- `USE_CASES.md` - 6 detailed scenarios (honeypot, incident response, security research, privacy, testing, quantum server) -- `CLAUDE.md` - Project context for AI sessions +* `+README.md+` - Main project documentation (450+ lines) +* `+USE_CASES.md+` - 6 detailed scenarios (honeypot, incident response, +security research, privacy, testing, quantum server) +* `+CLAUDE.md+` - Project context for AI sessions -== [0.1.0] - 2025-11-Earlier (Initial Prototype) +=== [0.1.0] - 2025-11-Earlier (Initial Prototype) -=== Added +==== Added -- Elixir prototype (reference implementation, not recommended for production) -- Basic HINFO/LOC fluctuation concept -- Proof of concept for DNS record randomization +* Elixir prototype (reference implementation, not recommended for +production) +* Basic HINFO/LOC fluctuation concept +* Proof of concept for DNS record randomization ---- +''''' -== Upcoming Releases +=== Upcoming Releases -=== [2.1.0] - Planned (Q1 2026) +==== [2.1.0] - Planned (Q1 2026) -**Focus**: Testing & Integration +*Focus*: Testing & Integration -- Unit test framework (target: 70%+ coverage) -- Integration tests with mock DNS server -- CI/CD pipeline (.gitlab-ci.yml) -- Nix reproducible builds (flake.nix) -- RSR self-verification -- Gold Tier RSR compliance (86%+) +* Unit test framework (target: 70%+ coverage) +* Integration tests with mock DNS server +* CI/CD pipeline (.gitlab-ci.yml) +* Nix reproducible builds (flake.nix) +* RSR self-verification +* Gold Tier RSR compliance (86%+) -=== [2.2.0] - Planned (Q2 2026) +==== [2.2.0] - Planned (Q2 2026) -**Focus**: Production Hardening +*Focus*: Production Hardening -- Real cryptographic hashing (bcrypt/Argon2) -- TSIG authentication with crypto library -- SPA packet encryption/decryption -- Real DNS server integration testing (BIND, PowerDNS, NSD) -- Actual firewall command execution (tested and hardened) +* Real cryptographic hashing (bcrypt/Argon2) +* TSIG authentication with crypto library +* SPA packet encryption/decryption +* Real DNS server integration testing (BIND, PowerDNS, NSD) +* Actual firewall command execution (tested and hardened) -=== [3.0.0] - Planned (Q3 2026) +==== [3.0.0] - Planned (Q3 2026) -**Focus**: Formal Verification +*Focus*: Formal Verification -- SPARK annotations on security-critical modules -- Formal verification of `secure_auth.ads` -- Formal verification of `sdp_controller.ads` -- Mathematical proof of correctness -- Platinum Tier RSR compliance (90%+) +* SPARK annotations on security-critical modules +* Formal verification of `+secure_auth.ads+` +* Formal verification of `+sdp_controller.ads+` +* Mathematical proof of correctness +* Platinum Tier RSR compliance (90%+) ---- +''''' -== Version Numbering +=== Version Numbering -We use [Semantic Versioning](https://semver.org/): +We use https://semver.org/[Semantic Versioning]: -- **MAJOR**: Incompatible API changes, breaking changes -- **MINOR**: New features, backward-compatible -- **PATCH**: Bug fixes, backward-compatible +* *MAJOR*: Incompatible API changes, breaking changes +* *MINOR*: New features, backward-compatible +* *PATCH*: Bug fixes, backward-compatible -**Special Tags**: -- `-alpha`: Early development, unstable -- `-beta`: Feature complete, testing phase -- `-rc1`, `-rc2`: Release candidates +*Special Tags*: - `+-alpha+`: Early development, unstable - `+-beta+`: +Feature complete, testing phase - `+-rc1+`, `+-rc2+`: Release candidates ---- +''''' -== Links +=== Links -- **Repository**: https://github.com/Hyperpolymath/resource-record-fluctuator -- **Releases**: https://github.com/Hyperpolymath/resource-record-fluctuator/releases -- **Issues**: https://github.com/Hyperpolymath/resource-record-fluctuator/issues -- **Security**: See [SECURITY.md](SECURITY.md) +* *Repository*: +https://github.com/Hyperpolymath/resource-record-fluctuator +* *Releases*: +https://github.com/Hyperpolymath/resource-record-fluctuator/releases +* *Issues*: +https://github.com/Hyperpolymath/resource-record-fluctuator/issues +* *Security*: See SECURITY.md ---- +''''' -**Maintained by**: See [MAINTAINERS.md](MAINTAINERS.md) -**License**: MIT + Palimpsest v0.8 (see [LICENSE](LICENSE)) +*Maintained by*: See MAINTAINERS.md *License*: MIT + Palimpsest v0.8 +(see LICENSE) diff --git a/CHANGELOG.md b/CHANGELOG.md deleted file mode 100644 index 89e462a..0000000 --- a/CHANGELOG.md +++ /dev/null @@ -1,234 +0,0 @@ -# Changelog - -All notable changes to the HINFO-LOC Fluctuator project will be documented in this file. - -The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/), -and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html). - -## [Unreleased] - -### Added -- RSR (Rhodium Standard Repository) compliance framework -- `.well-known/` directory with RFC 9116 security.txt, ai.txt, humans.txt -- Comprehensive governance documents (SECURITY.md, CONTRIBUTING.md, CODE_OF_CONDUCT.md, MAINTAINERS.md) -- TPCF (Tri-Perimeter Contribution Framework) documentation -- Justfile for modern build automation -- Dual licensing (MIT + Palimpsest v0.8) -- RSR compliance self-verification script - -### Changed -- Updated documentation to reflect Silver Tier RSR compliance (77%) - -## [2.0.0] - 2025-11-22 - -### Added - Enterprise Features - -**Extended DNS Records** (~500 lines) -- Support for 20+ DNS record types (A, AAAA, MX, NS, CNAME, PTR, TXT, SPF, DKIM, DMARC, CAA, TLSA, SSHFP, APL, SRV, NAPTR, DS, DNSKEY, NSEC, NSEC3) -- IPv4/IPv6 address parsing and conversion -- Zone file format generation for all record types -- APL record CIDR matching for IP-based access control -- DNS topology modes (Standard, Split-Horizon, Primary-Primary, Hidden-Primary) -- AXFR configuration for zone transfers - -**Firewall Management** (~460 lines) -- Dynamic port rotation with time-based algorithm - - Algorithm: `port = base_port + (unix_timestamp / interval) % range` - - Maintainers can calculate current port offline -- Service scheduling with time windows (MX, RSS, NNTP) -- Support for 4 firewall backends (firewalld, iptables, nftables, pf) -- Maintenance window tracking and enforcement -- Port knocking setup -- IPv4/IPv6 protocol mode control -- Emergency lockdown and recovery operations - -**Security Headers** (~500 lines) -- HTTP security header generation (HSTS, CSP, X-Frame-Options, Referrer-Policy, Permissions-Policy, COEP, COOP, CORP) -- Diagnostic mode - real stack visible only to authorized IPs with secret token -- Server/X-Powered-By obfuscation with randomized fake values -- CSP nonce generation for inline scripts -- Web server configuration generation (nginx, Apache, PHP) -- HINFO record synchronization for consistent fake stacks -- All experimental security headers - -**Zero-Trust SDP** (~470 lines) -- Software-Defined Perimeter architecture (NIST SP 800-207 compliant) -- Single Packet Authorization (SPA) processing framework -- Multi-factor authentication support -- Device posture validation (OS version, antivirus, firewall, encryption, patch level) -- Session management with continuous verification and re-authentication -- Policy evaluation and enforcement -- Micro-segmentation for network isolation -- Security event logging - -**Protocol Management** (~450 lines) -- SNMP v1/v2c/v3 support with security warnings for insecure versions -- NETCONF server implementation (RFC 6241, recommended over SNMP) -- RESTCONF RESTful API support (RFC 8040) -- gNMI modern gRPC-based protocol (recommended) -- Prometheus/OpenMetrics metrics export -- Security validation and protocol recommendations -- Firewall and SDP integration - -**Master Configuration** (~450 lines) -- 5 deployment profiles (Development, Staging, Production, Honeypot, Research) -- Configuration validation with comprehensive security checks -- Security posture reporting -- Configuration file operations (INI, YAML, JSON export) -- Hot reload - apply configuration changes without restart -- Migration from legacy config format -- Configuration comparison and diff generation -- Emergency configurations (lockdown, recovery, minimal safe modes) - -### Added - Documentation - -- `ENTERPRISE_FEATURES.md` - Comprehensive enterprise feature guide (350+ lines) -- `examples/production_config.yaml` - Production configuration example (310 lines) -- `PROJECT_SUMMARY.md` - Complete project transformation summary -- Updated `CLAUDE.md` with implementation status -- Updated root `README.md` with enterprise features overview - -### Changed - -- Project evolved from basic HINFO/LOC fluctuation to full enterprise DNS security platform -- Total codebase: 2,000 → 16,000+ lines -- Core modules: 6 → 20 (14 new modules) - -## [1.0.0] - 2025-11 (Previous Work) - -### Added - Core Features - -**Type-Safe DNS Records** (~140 lines) -- HINFO record support (CPU, OS) -- LOC record support (latitude, longitude, altitude) -- Compile-time bounds checking for all geographic coordinates -- DNS classes (IN, CH, HS) -- TTL range constraints (1-604800 seconds) - -**Authentication Module** (~110 lines) -- Permission levels (None, Read-Only, Modify-Local, Modify-Remote, Admin) -- Session timeout (30 minutes default) -- Constant-time password comparison (timing attack prevention) -- Replay attack detection (nonce-based) - -**Randomization Engine** (~200 lines) -- CSV parser for location data -- Random selection from data pools -- Configurable randomization intervals - -**Text User Interface** (~350 lines) -- Interactive menu system -- ANSI color support -- Permission-based menu filtering -- Login screen - -**Zone File Writer** (~180 lines) -- BIND-format zone file generation -- SOA record generation -- RFC 1912 serial format (YYYYMMDDnn) -- Atomic file writes - -**Logger** (~150 lines) -- Thread-safe audit logging -- Protected types for concurrent access -- Structured log entries - -**Scheduler** (~150 lines) -- Scheduled auto-fluctuation with Ada tasking -- Start/Stop/Pause/Resume control -- Configurable intervals - -**DNS UPDATE Framework** (~120 lines) -- RFC 2136 dynamic update framework -- TSIG authentication specification (needs crypto library) - -### Added - Data Files - -- `machines.txt` - 68 CPU types (Intel, AMD, ARM, historical, fictional) -- `operating_systems.txt` - 77 operating systems (Linux, BSD, Windows, historical, fictional) -- `locations.csv` - 52 geographic locations (data centers, exotic locations) - -### Added - Build System - -- GNAT project file (`hinfo_loc_fluctuator.gpr`) -- Makefile with debug, release, prove targets -- Security flags always enabled (`-gnoto`, `-fstack-check`, `-gnatVa`) -- SPARK verification mode - -### Added - Documentation - -- `README.md` - Main project documentation (450+ lines) -- `USE_CASES.md` - 6 detailed scenarios (honeypot, incident response, security research, privacy, testing, quantum server) -- `CLAUDE.md` - Project context for AI sessions - -## [0.1.0] - 2025-11-Earlier (Initial Prototype) - -### Added - -- Elixir prototype (reference implementation, not recommended for production) -- Basic HINFO/LOC fluctuation concept -- Proof of concept for DNS record randomization - ---- - -## Upcoming Releases - -### [2.1.0] - Planned (Q1 2026) - -**Focus**: Testing & Integration - -- Unit test framework (target: 70%+ coverage) -- Integration tests with mock DNS server -- CI/CD pipeline (.gitlab-ci.yml) -- Nix reproducible builds (flake.nix) -- RSR self-verification -- Gold Tier RSR compliance (86%+) - -### [2.2.0] - Planned (Q2 2026) - -**Focus**: Production Hardening - -- Real cryptographic hashing (bcrypt/Argon2) -- TSIG authentication with crypto library -- SPA packet encryption/decryption -- Real DNS server integration testing (BIND, PowerDNS, NSD) -- Actual firewall command execution (tested and hardened) - -### [3.0.0] - Planned (Q3 2026) - -**Focus**: Formal Verification - -- SPARK annotations on security-critical modules -- Formal verification of `secure_auth.ads` -- Formal verification of `sdp_controller.ads` -- Mathematical proof of correctness -- Platinum Tier RSR compliance (90%+) - ---- - -## Version Numbering - -We use [Semantic Versioning](https://semver.org/): - -- **MAJOR**: Incompatible API changes, breaking changes -- **MINOR**: New features, backward-compatible -- **PATCH**: Bug fixes, backward-compatible - -**Special Tags**: -- `-alpha`: Early development, unstable -- `-beta`: Feature complete, testing phase -- `-rc1`, `-rc2`: Release candidates - ---- - -## Links - -- **Repository**: https://github.com/Hyperpolymath/resource-record-fluctuator -- **Releases**: https://github.com/Hyperpolymath/resource-record-fluctuator/releases -- **Issues**: https://github.com/Hyperpolymath/resource-record-fluctuator/issues -- **Security**: See [SECURITY.md](SECURITY.md) - ---- - -**Maintained by**: See [MAINTAINERS.md](MAINTAINERS.md) -**License**: MIT + Palimpsest v0.8 (see [LICENSE](LICENSE)) diff --git a/CODE_OF_CONDUCT.adoc b/CODE_OF_CONDUCT.adoc new file mode 100644 index 0000000..1c12b3d --- /dev/null +++ b/CODE_OF_CONDUCT.adoc @@ -0,0 +1,175 @@ +== Contributor Covenant Code of Conduct + +=== Our Pledge + +We as members, contributors, and leaders pledge to make participation in +our community a harassment-free experience for everyone, regardless of +age, body size, visible or invisible disability, ethnicity, sex +characteristics, gender identity and expression, level of experience, +education, socio-economic status, nationality, personal appearance, +race, caste, color, religion, or sexual identity and orientation. + +We pledge to act and interact in ways that contribute to an open, +welcoming, diverse, inclusive, and healthy community. + +=== Our Standards + +Examples of behavior that contributes to a positive environment for our +community include: + +* Demonstrating empathy and kindness toward other people +* Being respectful of differing opinions, viewpoints, and experiences +* Giving and gracefully accepting constructive feedback +* Accepting responsibility and apologizing to those affected by our +mistakes, and learning from the experience +* Focusing on what is best not just for us as individuals, but for the +overall community + +Examples of unacceptable behavior include: + +* The use of sexualized language or imagery, and sexual attention or +advances of any kind +* Trolling, insulting or derogatory comments, and personal or political +attacks +* Public or private harassment +* Publishing others’ private information, such as a physical or email +address, without their explicit permission +* Other conduct which could reasonably be considered inappropriate in a +professional setting + +=== Enforcement Responsibilities + +Community leaders are responsible for clarifying and enforcing our +standards of acceptable behavior and will take appropriate and fair +corrective action in response to any behavior that they deem +inappropriate, threatening, offensive, or harmful. + +Community leaders have the right and responsibility to remove, edit, or +reject comments, commits, code, wiki edits, issues, and other +contributions that are not aligned to this Code of Conduct, and will +communicate reasons for moderation decisions when appropriate. + +=== Scope + +This Code of Conduct applies within all community spaces, and also +applies when an individual is officially representing the community in +public spaces. Examples of representing our community include using an +official e-mail address, posting via an official social media account, +or acting as an appointed representative at an online or offline event. + +=== Enforcement + +Instances of abusive, harassing, or otherwise unacceptable behavior may +be reported to the community leaders responsible for enforcement at +security@example.com (replace with actual contact). + +All complaints will be reviewed and investigated promptly and fairly. + +All community leaders are obligated to respect the privacy and security +of the reporter of any incident. + +=== Enforcement Guidelines + +Community leaders will follow these Community Impact Guidelines in +determining the consequences for any action they deem in violation of +this Code of Conduct: + +==== 1. Correction + +*Community Impact*: Use of inappropriate language or other behavior +deemed unprofessional or unwelcome in the community. + +*Consequence*: A private, written warning from community leaders, +providing clarity around the nature of the violation and an explanation +of why the behavior was inappropriate. A public apology may be +requested. + +==== 2. Warning + +*Community Impact*: A violation through a single incident or series of +actions. + +*Consequence*: A warning with consequences for continued behavior. No +interaction with the people involved, including unsolicited interaction +with those enforcing the Code of Conduct, for a specified period of +time. This includes avoiding interactions in community spaces as well as +external channels like social media. Violating these terms may lead to a +temporary or permanent ban. + +==== 3. Temporary Ban + +*Community Impact*: A serious violation of community standards, +including sustained inappropriate behavior. + +*Consequence*: A temporary ban from any sort of interaction or public +communication with the community for a specified period of time. No +public or private interaction with the people involved, including +unsolicited interaction with those enforcing the Code of Conduct, is +allowed during this period. Violating these terms may lead to a +permanent ban. + +==== 4. Permanent Ban + +*Community Impact*: Demonstrating a pattern of violation of community +standards, including sustained inappropriate behavior, harassment of an +individual, or aggression toward or disparagement of classes of +individuals. + +*Consequence*: A permanent ban from any sort of public interaction +within the community. + +=== HINFO-LOC Fluctuator Specific Guidelines + +==== Technical Discussions + +* *Be patient* with newcomers to Ada, DNS, or security topics +* *Explain clearly* when discussing type safety, memory safety, or +formal verification +* *Share knowledge* about security best practices without gatekeeping +* *Accept mistakes* - this is a learning project for many contributors + +==== Security Research + +* *Respect responsible disclosure* - see SECURITY.md for vulnerability +reporting +* *No malicious behavior* - this tool is for defense, not attack +* *Ethical use only* - honeypots, incident response, privacy enhancement +* *No weaponization* - don’t use for DDoS, data exfiltration, or harm + +==== Contribution Quality + +* *Ask questions* before making large changes +* *Follow Ada style guide* - we value readable, maintainable code +* *Test your changes* - at minimum, ensure it compiles +* *Document security impact* - if your code touches auth, SDP, or +firewall logic + +==== Emotional Safety + +This project values psychological safety and well-being: + +* *Reversibility matters* - we support experimentation without fear +* *No blame culture* - mistakes are learning opportunities +* *Mental health is important* - take breaks, it’s okay to step away +* *Work-life balance* - we’re a hobby project, not a job + +See also: *Emotional Temperature Metrics* in our research documentation + +=== Attribution + +This Code of Conduct is adapted from the +https://www.contributor-covenant.org[Contributor Covenant], version 2.1, +available at +https://www.contributor-covenant.org/version/2/1/code_of_conduct.html. + +Community Impact Guidelines were inspired by +https://github.com/mozilla/diversity[Mozilla’s code of conduct +enforcement ladder]. + +For answers to common questions about this code of conduct, see the FAQ +at https://www.contributor-covenant.org/faq. Translations are available +at https://www.contributor-covenant.org/translations. + +''''' + +*Last Updated*: 2025-11-22 diff --git a/CODE_OF_CONDUCT.md b/CODE_OF_CONDUCT.md deleted file mode 100644 index 8634100..0000000 --- a/CODE_OF_CONDUCT.md +++ /dev/null @@ -1,171 +0,0 @@ -# Contributor Covenant Code of Conduct - -## Our Pledge - -We as members, contributors, and leaders pledge to make participation in our -community a harassment-free experience for everyone, regardless of age, body -size, visible or invisible disability, ethnicity, sex characteristics, gender -identity and expression, level of experience, education, socio-economic status, -nationality, personal appearance, race, caste, color, religion, or sexual -identity and orientation. - -We pledge to act and interact in ways that contribute to an open, welcoming, -diverse, inclusive, and healthy community. - -## Our Standards - -Examples of behavior that contributes to a positive environment for our -community include: - -* Demonstrating empathy and kindness toward other people -* Being respectful of differing opinions, viewpoints, and experiences -* Giving and gracefully accepting constructive feedback -* Accepting responsibility and apologizing to those affected by our mistakes, - and learning from the experience -* Focusing on what is best not just for us as individuals, but for the overall - community - -Examples of unacceptable behavior include: - -* The use of sexualized language or imagery, and sexual attention or advances of - any kind -* Trolling, insulting or derogatory comments, and personal or political attacks -* Public or private harassment -* Publishing others' private information, such as a physical or email address, - without their explicit permission -* Other conduct which could reasonably be considered inappropriate in a - professional setting - -## Enforcement Responsibilities - -Community leaders are responsible for clarifying and enforcing our standards of -acceptable behavior and will take appropriate and fair corrective action in -response to any behavior that they deem inappropriate, threatening, offensive, -or harmful. - -Community leaders have the right and responsibility to remove, edit, or reject -comments, commits, code, wiki edits, issues, and other contributions that are -not aligned to this Code of Conduct, and will communicate reasons for moderation -decisions when appropriate. - -## Scope - -This Code of Conduct applies within all community spaces, and also applies when -an individual is officially representing the community in public spaces. -Examples of representing our community include using an official e-mail address, -posting via an official social media account, or acting as an appointed -representative at an online or offline event. - -## Enforcement - -Instances of abusive, harassing, or otherwise unacceptable behavior may be -reported to the community leaders responsible for enforcement at -security@example.com (replace with actual contact). - -All complaints will be reviewed and investigated promptly and fairly. - -All community leaders are obligated to respect the privacy and security of the -reporter of any incident. - -## Enforcement Guidelines - -Community leaders will follow these Community Impact Guidelines in determining -the consequences for any action they deem in violation of this Code of Conduct: - -### 1. Correction - -**Community Impact**: Use of inappropriate language or other behavior deemed -unprofessional or unwelcome in the community. - -**Consequence**: A private, written warning from community leaders, providing -clarity around the nature of the violation and an explanation of why the -behavior was inappropriate. A public apology may be requested. - -### 2. Warning - -**Community Impact**: A violation through a single incident or series of -actions. - -**Consequence**: A warning with consequences for continued behavior. No -interaction with the people involved, including unsolicited interaction with -those enforcing the Code of Conduct, for a specified period of time. This -includes avoiding interactions in community spaces as well as external channels -like social media. Violating these terms may lead to a temporary or permanent -ban. - -### 3. Temporary Ban - -**Community Impact**: A serious violation of community standards, including -sustained inappropriate behavior. - -**Consequence**: A temporary ban from any sort of interaction or public -communication with the community for a specified period of time. No public or -private interaction with the people involved, including unsolicited interaction -with those enforcing the Code of Conduct, is allowed during this period. -Violating these terms may lead to a permanent ban. - -### 4. Permanent Ban - -**Community Impact**: Demonstrating a pattern of violation of community -standards, including sustained inappropriate behavior, harassment of an -individual, or aggression toward or disparagement of classes of individuals. - -**Consequence**: A permanent ban from any sort of public interaction within the -community. - -## HINFO-LOC Fluctuator Specific Guidelines - -### Technical Discussions - -- **Be patient** with newcomers to Ada, DNS, or security topics -- **Explain clearly** when discussing type safety, memory safety, or formal verification -- **Share knowledge** about security best practices without gatekeeping -- **Accept mistakes** - this is a learning project for many contributors - -### Security Research - -- **Respect responsible disclosure** - see SECURITY.md for vulnerability reporting -- **No malicious behavior** - this tool is for defense, not attack -- **Ethical use only** - honeypots, incident response, privacy enhancement -- **No weaponization** - don't use for DDoS, data exfiltration, or harm - -### Contribution Quality - -- **Ask questions** before making large changes -- **Follow Ada style guide** - we value readable, maintainable code -- **Test your changes** - at minimum, ensure it compiles -- **Document security impact** - if your code touches auth, SDP, or firewall logic - -### Emotional Safety - -This project values psychological safety and well-being: - -- **Reversibility matters** - we support experimentation without fear -- **No blame culture** - mistakes are learning opportunities -- **Mental health is important** - take breaks, it's okay to step away -- **Work-life balance** - we're a hobby project, not a job - -See also: **Emotional Temperature Metrics** in our research documentation - -## Attribution - -This Code of Conduct is adapted from the [Contributor Covenant][homepage], -version 2.1, available at -[https://www.contributor-covenant.org/version/2/1/code_of_conduct.html][v2.1]. - -Community Impact Guidelines were inspired by -[Mozilla's code of conduct enforcement ladder][Mozilla CoC]. - -For answers to common questions about this code of conduct, see the FAQ at -[https://www.contributor-covenant.org/faq][FAQ]. Translations are available at -[https://www.contributor-covenant.org/translations][translations]. - -[homepage]: https://www.contributor-covenant.org -[v2.1]: https://www.contributor-covenant.org/version/2/1/code_of_conduct.html -[Mozilla CoC]: https://github.com/mozilla/diversity -[FAQ]: https://www.contributor-covenant.org/faq -[translations]: https://www.contributor-covenant.org/translations - ---- - -**Last Updated**: 2025-11-22 diff --git a/CONTRIBUTING.adoc b/CONTRIBUTING.adoc new file mode 100644 index 0000000..dab29bd --- /dev/null +++ b/CONTRIBUTING.adoc @@ -0,0 +1,3 @@ +== Contributing + +See CONTRIBUTING.adoc for full contribution guidelines. diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md deleted file mode 100644 index bf6cd14..0000000 --- a/CONTRIBUTING.md +++ /dev/null @@ -1,3 +0,0 @@ -# Contributing - -See [CONTRIBUTING.adoc](CONTRIBUTING.adoc) for full contribution guidelines. diff --git a/GOVERNANCE.adoc b/GOVERNANCE.adoc new file mode 100644 index 0000000..9b836fb --- /dev/null +++ b/GOVERNANCE.adoc @@ -0,0 +1,60 @@ +== Governance + +=== Overview + +This project is governed by the following principles and structures to +ensure transparent, inclusive, and effective decision-making. + +=== Roles and Responsibilities + +==== Maintainers + +Maintainers are responsible for: - Reviewing and merging pull requests - +Managing releases and versioning - Ensuring code quality and standards - +Triaging issues and bug reports - Community engagement and support + +==== Contributors + +Contributors are expected to: - Follow the code of conduct - Submit +well-documented pull requests - Write tests for new functionality - +Maintain existing tests - Update documentation as needed + +=== Decision Making + +==== Minor Changes + +* Can be made by any maintainer +* Include bug fixes, documentation updates, dependency updates + +==== Major Changes + +* Require discussion in issues or pull requests +* Include new features, architectural changes, API changes +* Need approval from at least 2 maintainers + +==== Breaking Changes + +* Require RFC (Request for Comments) process +* Need approval from majority of maintainers +* Must include migration guide + +=== Code of Conduct + +All participants are expected to follow our Code of Conduct. Violations +can be reported to the maintainers. + +=== Communication + +* *Issues*: For bug reports and feature requests +* *Discussions*: For questions and general discussion +* *Pull Requests*: For code contributions + +=== Licensing + +All contributions are made under the terms of the repository’s LICENSE +file. By submitting a pull request, you agree to license your +contributions accordingly. + +''''' + +_Last updated: 2026-07-18_ diff --git a/GOVERNANCE.md b/GOVERNANCE.md deleted file mode 100644 index e27364c..0000000 --- a/GOVERNANCE.md +++ /dev/null @@ -1,60 +0,0 @@ -# Governance - -## Overview - -This project is governed by the following principles and structures to ensure transparent, inclusive, and effective decision-making. - -## Roles and Responsibilities - -### Maintainers - -Maintainers are responsible for: -- Reviewing and merging pull requests -- Managing releases and versioning -- Ensuring code quality and standards -- Triaging issues and bug reports -- Community engagement and support - -### Contributors - -Contributors are expected to: -- Follow the code of conduct -- Submit well-documented pull requests -- Write tests for new functionality -- Maintain existing tests -- Update documentation as needed - -## Decision Making - -### Minor Changes -- Can be made by any maintainer -- Include bug fixes, documentation updates, dependency updates - -### Major Changes -- Require discussion in issues or pull requests -- Include new features, architectural changes, API changes -- Need approval from at least 2 maintainers - -### Breaking Changes -- Require RFC (Request for Comments) process -- Need approval from majority of maintainers -- Must include migration guide - -## Code of Conduct - -All participants are expected to follow our Code of Conduct. Violations can be reported to the maintainers. - -## Communication - -- **Issues**: For bug reports and feature requests -- **Discussions**: For questions and general discussion -- **Pull Requests**: For code contributions - -## Licensing - -All contributions are made under the terms of the repository's LICENSE file. -By submitting a pull request, you agree to license your contributions accordingly. - ---- - -*Last updated: 2026-07-18* diff --git a/MAINTAINERS.adoc b/MAINTAINERS.adoc index 48d9781..812bf42 100644 --- a/MAINTAINERS.adoc +++ b/MAINTAINERS.adoc @@ -1,47 +1,186 @@ -// SPDX-License-Identifier: CC-BY-SA-4.0 -= Maintainers -:toc: preamble +== Maintainers -This document lists the maintainers of this project and their responsibilities. +This document lists the current maintainers of the HINFO-LOC Fluctuator +project and describes the governance structure. -== Current Maintainers +=== Current Maintainers -[cols="2,3,2",options="header"] -|=== -| Name | Role | Contact +==== Perimeter 1: Core Maintainers -| Jonathan D.A. Jewell -| Lead Maintainer -| https://github.com/hyperpolymath[@hyperpolymath] +[width="100%",cols="16%,18%,13%,37%,16%",options="header",] +|=== +|Name |GitHub |Role |Areas of Focus |Since +|Hyperpolymath |https://github.com/Hyperpolymath[@Hyperpolymath] +|Project Lead, Architecture |Overall project direction, Ada +implementation, enterprise features |2025-11 |=== -== Responsibilities +=== Governance Model + +This project uses the *Tri-Perimeter Contribution Framework* (TPCF) with +three levels of access: + +==== Perimeter 1: Core Maintainers (Above) + +* *Responsibilities*: +** Merge pull requests to main +** Create releases +** Set project direction +** Manage CI/CD and credentials +** Nominate Perimeter 2 members +* *Decision Making*: Consensus-based (currently single maintainer) + +==== Perimeter 2: Trusted Contributors (None Currently) + +* *Responsibilities*: +** Review pull requests (blocking) +** Triage issues +** Label and assign issues +** Mentor new contributors +* *How to Join*: Nominated by Perimeter 1 after 5+ quality contributions + +==== Perimeter 3: Community Sandbox (Everyone) + +* *Responsibilities*: +** Submit pull requests +** Review others’ work (informal) +** Report bugs and suggest features +** Help other contributors +* *How to Join*: Just start contributing! + +See TPCF.md for detailed framework documentation. + +=== Areas of Expertise + +We’re looking for contributors with expertise in: + +==== Core Development + +* *Ada/SPARK*: Type-safe systems programming, formal verification +* *DNS Protocols*: RFC implementation, BIND/PowerDNS/NSD +* *Security Architecture*: Zero-trust, SDP, cryptography + +==== Enterprise Features + +* *Firewall Management*: firewalld, iptables, nftables, pf +* *Network Protocols*: NETCONF, RESTCONF, gNMI, SNMP +* *Security Headers*: HTTP security, obfuscation techniques + +==== Operations + +* *Testing*: Unit tests, integration tests, fuzz testing +* *CI/CD*: GitLab CI, GitHub Actions +* *Packaging*: Nix, system packages (apt, yum, pacman) + +==== Documentation + +* *Technical Writing*: Clear, comprehensive documentation +* *Use Cases*: Security research, honeypot deployment +* *Translation*: Non-English documentation (future) + +=== Becoming a Maintainer + +==== Path to Perimeter 2 (Trusted Contributor) -Maintainers are responsible for: +*Requirements*: 1. 5+ merged pull requests 2. Demonstrated understanding +of project goals 3. Consistent code quality 4. Active participation in +reviews 5. Nomination by Perimeter 1 member 6. Acceptance by consensus -* Reviewing and merging pull requests -* Triaging issues and feature requests -* Ensuring code quality and security standards -* Managing releases and versioning -* Upholding the project's code of conduct +*Benefits*: - Formal review rights (blocking PRs) - Issue triage and +labeling - Recognition in project documentation - Input on project +direction -== Becoming a Maintainer +==== Path to Perimeter 1 (Core Maintainer) -Contributors who demonstrate: +*Requirements*: 1. 6+ months as Perimeter 2 contributor 2. Significant +contributions to codebase 3. Deep understanding of architecture 4. +Demonstrated leadership 5. Invitation by existing Perimeter 1 members 6. +Unanimous approval by Perimeter 1 + +*Benefits*: - Merge rights to main branch - Release creation - CI/CD +configuration - Access to project credentials - Equal voice in +governance decisions + +=== Responsibilities + +==== All Maintainers + +* *Code Quality*: Maintain high standards for type safety, memory +safety, security +* *Reviews*: Provide timely, constructive code reviews +* *Communication*: Respond to issues and PRs within 1 week +* *Documentation*: Keep docs up-to-date +* *Community*: Foster welcoming, inclusive environment +* *Security*: Follow responsible disclosure, prioritize security + +==== Perimeter 1 Specific + +* *Releases*: Create and publish releases (semantic versioning) +* *Security*: Respond to vulnerability reports within 48 hours +* *Direction*: Set technical direction and roadmap +* *Nominations*: Identify and nominate Perimeter 2 candidates +* *CI/CD*: Maintain build pipeline and testing infrastructure + +=== Decision-Making Process + +==== Minor Decisions + +* Code style, formatting +* Bug fixes +* Documentation improvements +* *Process*: Any maintainer can approve and merge + +==== Major Decisions + +* New features +* Breaking changes +* Dependency additions +* Architecture changes +* *Process*: Consensus among Perimeter 1 (currently single maintainer) + +==== Critical Decisions + +* License changes +* Governance changes +* Code of Conduct modifications +* *Process*: Unanimous approval by Perimeter 1 + community discussion +period (2 weeks) + +=== Removing Maintainers + +Maintainers may be removed due to: + +* *Inactivity*: No participation for 6+ months (voluntary step-down +encouraged) +* *Code of Conduct Violations*: Serious or repeated violations +* *Security Negligence*: Intentional or reckless security issues +* *Lack of Consensus*: Persistent disagreement with project direction + +*Process*: 1. Private discussion among Perimeter 1 2. Attempt to resolve +issues 3. Vote (unanimous for Perimeter 1 removal) 4. Public +announcement (if appropriate) 5. Graceful transition of responsibilities + +=== Emeritus Maintainers + +Former maintainers who stepped down in good standing: + +[cols=",,,",options="header",] +|=== +|Name |GitHub |Tenure |Contributions +|(None yet) |- |- |- +|=== -* Consistent, high-quality contributions -* Understanding of the project's goals and standards -* Constructive participation in discussions -* Commitment to the project's long-term health +=== Contact -May be invited to become maintainers at the discretion of existing maintainers. +* *General Questions*: Open a GitHub issue +* *Private Concerns*: security@example.com +* *Governance Questions*: maintainers@example.com (future) -== Decision Making +=== Acknowledgments -* Routine decisions (bug fixes, minor improvements) can be made by any maintainer -* Significant changes require discussion and consensus among maintainers -* Breaking changes or major features should be discussed in issues before implementation +We’re grateful to all contributors, regardless of perimeter level. Every +contribution matters! -== Contact +''''' -For questions about project governance, open an issue or contact the maintainers listed above. +*Last Updated*: 2025-11-22 *Next Review*: 2026-05-22 (6 months) diff --git a/MAINTAINERS.md b/MAINTAINERS.md deleted file mode 100644 index 49f0c60..0000000 --- a/MAINTAINERS.md +++ /dev/null @@ -1,183 +0,0 @@ -# Maintainers - -This document lists the current maintainers of the HINFO-LOC Fluctuator project and describes the governance structure. - -## Current Maintainers - -### Perimeter 1: Core Maintainers - -| Name | GitHub | Role | Areas of Focus | Since | -|------|--------|------|----------------|-------| -| Hyperpolymath | [@Hyperpolymath](https://github.com/Hyperpolymath) | Project Lead, Architecture | Overall project direction, Ada implementation, enterprise features | 2025-11 | - -## Governance Model - -This project uses the **Tri-Perimeter Contribution Framework** (TPCF) with three levels of access: - -### Perimeter 1: Core Maintainers (Above) -- **Responsibilities**: - - Merge pull requests to main - - Create releases - - Set project direction - - Manage CI/CD and credentials - - Nominate Perimeter 2 members - -- **Decision Making**: Consensus-based (currently single maintainer) - -### Perimeter 2: Trusted Contributors (None Currently) -- **Responsibilities**: - - Review pull requests (blocking) - - Triage issues - - Label and assign issues - - Mentor new contributors - -- **How to Join**: Nominated by Perimeter 1 after 5+ quality contributions - -### Perimeter 3: Community Sandbox (Everyone) -- **Responsibilities**: - - Submit pull requests - - Review others' work (informal) - - Report bugs and suggest features - - Help other contributors - -- **How to Join**: Just start contributing! - -See [TPCF.md](TPCF.md) for detailed framework documentation. - -## Areas of Expertise - -We're looking for contributors with expertise in: - -### Core Development -- **Ada/SPARK**: Type-safe systems programming, formal verification -- **DNS Protocols**: RFC implementation, BIND/PowerDNS/NSD -- **Security Architecture**: Zero-trust, SDP, cryptography - -### Enterprise Features -- **Firewall Management**: firewalld, iptables, nftables, pf -- **Network Protocols**: NETCONF, RESTCONF, gNMI, SNMP -- **Security Headers**: HTTP security, obfuscation techniques - -### Operations -- **Testing**: Unit tests, integration tests, fuzz testing -- **CI/CD**: GitLab CI, GitHub Actions -- **Packaging**: Nix, system packages (apt, yum, pacman) - -### Documentation -- **Technical Writing**: Clear, comprehensive documentation -- **Use Cases**: Security research, honeypot deployment -- **Translation**: Non-English documentation (future) - -## Becoming a Maintainer - -### Path to Perimeter 2 (Trusted Contributor) - -**Requirements**: -1. 5+ merged pull requests -2. Demonstrated understanding of project goals -3. Consistent code quality -4. Active participation in reviews -5. Nomination by Perimeter 1 member -6. Acceptance by consensus - -**Benefits**: -- Formal review rights (blocking PRs) -- Issue triage and labeling -- Recognition in project documentation -- Input on project direction - -### Path to Perimeter 1 (Core Maintainer) - -**Requirements**: -1. 6+ months as Perimeter 2 contributor -2. Significant contributions to codebase -3. Deep understanding of architecture -4. Demonstrated leadership -5. Invitation by existing Perimeter 1 members -6. Unanimous approval by Perimeter 1 - -**Benefits**: -- Merge rights to main branch -- Release creation -- CI/CD configuration -- Access to project credentials -- Equal voice in governance decisions - -## Responsibilities - -### All Maintainers - -- **Code Quality**: Maintain high standards for type safety, memory safety, security -- **Reviews**: Provide timely, constructive code reviews -- **Communication**: Respond to issues and PRs within 1 week -- **Documentation**: Keep docs up-to-date -- **Community**: Foster welcoming, inclusive environment -- **Security**: Follow responsible disclosure, prioritize security - -### Perimeter 1 Specific - -- **Releases**: Create and publish releases (semantic versioning) -- **Security**: Respond to vulnerability reports within 48 hours -- **Direction**: Set technical direction and roadmap -- **Nominations**: Identify and nominate Perimeter 2 candidates -- **CI/CD**: Maintain build pipeline and testing infrastructure - -## Decision-Making Process - -### Minor Decisions -- Code style, formatting -- Bug fixes -- Documentation improvements -- **Process**: Any maintainer can approve and merge - -### Major Decisions -- New features -- Breaking changes -- Dependency additions -- Architecture changes -- **Process**: Consensus among Perimeter 1 (currently single maintainer) - -### Critical Decisions -- License changes -- Governance changes -- Code of Conduct modifications -- **Process**: Unanimous approval by Perimeter 1 + community discussion period (2 weeks) - -## Removing Maintainers - -Maintainers may be removed due to: - -- **Inactivity**: No participation for 6+ months (voluntary step-down encouraged) -- **Code of Conduct Violations**: Serious or repeated violations -- **Security Negligence**: Intentional or reckless security issues -- **Lack of Consensus**: Persistent disagreement with project direction - -**Process**: -1. Private discussion among Perimeter 1 -2. Attempt to resolve issues -3. Vote (unanimous for Perimeter 1 removal) -4. Public announcement (if appropriate) -5. Graceful transition of responsibilities - -## Emeritus Maintainers - -Former maintainers who stepped down in good standing: - -| Name | GitHub | Tenure | Contributions | -|------|--------|--------|---------------| -| (None yet) | - | - | - | - -## Contact - -- **General Questions**: Open a GitHub issue -- **Private Concerns**: security@example.com -- **Governance Questions**: maintainers@example.com (future) - -## Acknowledgments - -We're grateful to all contributors, regardless of perimeter level. Every contribution matters! - ---- - -**Last Updated**: 2025-11-22 -**Next Review**: 2026-05-22 (6 months) diff --git a/PROJECT_SUMMARY.adoc b/PROJECT_SUMMARY.adoc new file mode 100644 index 0000000..bf1a824 --- /dev/null +++ b/PROJECT_SUMMARY.adoc @@ -0,0 +1,583 @@ +== HINFO-LOC Fluctuator - Complete Project Summary + +=== Executive Summary + +What started as a hobby DNS record randomization tool has been +transformed into a *comprehensive enterprise-grade DNS security and +infrastructure management platform* with zero-trust access control, +advanced obfuscation, and modern management protocols. + +*Built with Ada* for maximum security, type safety, and formal +verification potential. + +''''' + +=== Project Transformation + +==== Original Scope + +* Randomize HINFO (CPU/OS) and LOC (geographic) records +* Security-focused Ada implementation +* Basic TUI and data pools +* ~2,000 lines of code + +==== Current Scope + +* *Enterprise DNS security platform* +* Zero-trust access control (SDP) +* Firewall integration with time-based access +* Port rotation and service scheduling +* Security header obfuscation +* Modern management protocols (NETCONF/RESTCONF/gNMI) +* *~10,000+ lines of code* (specifications + documentation) + +''''' + +=== What Was Built + +==== Phase 1: Foundation (Original) + +*Core Modules (14 files):* 1. `+dns_records.ads/adb+` - Type-safe +HINFO/LOC records 2. `+secure_auth.ads/adb+` - Authentication with +permission levels 3. `+randomizer.ads/adb+` - Data loading and random +generation with CSV parser 4. `+tui.ads/adb+` - Interactive text user +interface 5. `+main.adb+` - Entry point with command-line parsing + +*Build System:* - GNAT project file with security flags always enabled - +Makefile with debug/release/prove targets - Overflow checking even in +release builds + +*Data:* - 68 CPU types (machines.txt) - 77 operating systems +(operating_systems.txt) - 52 geographic locations (locations.csv) + +*Advanced Features:* - Zone file writer (BIND format) with SOA +generation - Logging system (thread-safe with protected objects) - +Configuration system (INI format) - Scheduled fluctuation (Ada tasking) + +*Documentation:* - README.md (comprehensive user guide) - USE_CASES.md +(detailed scenarios) - CLAUDE.md (AI context documentation) + +*Total:* ~4,000 lines of Ada code + documentation + +''''' + +==== Phase 2: Enterprise Platform (NEW) + +*Extended DNS Records Module* (`+dns_records_extended.ads+`): - *20+ DNS +record types:* - Address: A, AAAA, PTR - Delegation: NS, CNAME - Mail: +MX, SPF, DKIM, DMARC - Service: SRV, NAPTR - Security: CAA, TLSA (DANE), +SSHFP - Access Control: APL (CIDR-based) - DNSSEC: DS, DNSKEY, NSEC, +NSEC3 - IPv4/IPv6 protocol toggle (Dual-Stack, IPv4-Only, IPv6-Only, +Disabled) - DNS topology modes (6 types including Split-Horizon, +Hidden-Primary) - AXFR configuration with TSIG authentication - Complete +IPv4/IPv6 address handling + +*Firewall Manager* (`+firewall_manager.ads+`): - *Backend support:* +firewalld, iptables, nftables, pf - Time-based maintenance windows with +IP restrictions - *Port rotation* (4 strategies): 1. Sequential (10000, +10001, 10002…) 2. Random (pseudorandom from pool) 3. Time-Based +(maintainers calculate offline: +`+port = base + (timestamp/interval) % range+`) 4. Pre-Shared Key +(algorithm with secret) - Service scheduling for MX, RSS, NNTP, SSH - +Stateful vs stateless firewall rules - Port knocking integration - +IPv4/IPv6 firewall toggle - Emergency lockdown/recovery modes + +*Security Headers* (`+security_headers.ads+`): - *Server obfuscation +modes:* - Hidden (don’t send header) - Obfuscated (send fake value, +randomized) - Diagnostic (real value only to authorized IPs with secret +token) - Standard (real value to everyone) - X-Powered-By hiding - *All +security headers:* - HSTS (Strict-Transport-Security) - CSP +(Content-Security-Policy) with nonce generation - X-Frame-Options - +X-Content-Type-Options - Referrer-Policy - Permissions-Policy (all +features configurable) - Experimental: COEP, COOP, CORP, Expect-CT, NEL +- Integration with HINFO for consistent fake stack - Nginx/Apache/PHP +configuration generation - Diagnostic mode for maintainers + +*Software-Defined Perimeter* (`+sdp_controller.ads+`): - *Cloud Security +Alliance SDP architecture* - Single Packet Authorization (SPA): - +Encryption: AES-256-GCM, ChaCha20-Poly1305 - HMAC: SHA256, SHA512, +SHA3-256 - Anti-replay with nonces - *Zero-trust policy engine:* - Trust +levels: Untrusted → Device Verified → User Authenticated → Posture Valid +→ Full Trust - Device posture validation (OS version, AV, firewall, disk +encryption, patch level) - Continuous authentication (periodic +re-verification) - Identity-based access (user + device + MFA) - Session +management with automatic firewall cleanup - Micro-segmentation for +network isolation - Access policies with time/IP/user/device/service +restrictions - Integration with firewall for dynamic rules + +*Protocol Manager* (`+protocol_manager.ads+`): - *SNMP* (with warnings, +disabled by default): - v1/v2c marked insecure - v3 with +encryption/authentication - *NETCONF* (RFC 6241) - Recommended: - +XML-based over SSH - Candidate configuration - Confirmed commit - +Rollback support - MFA support - *RESTCONF* (RFC 8040) - Recommended: - +RESTful API over HTTPS - Client certificate auth - OAuth2 support - Rate +limiting - CORS configuration - *gNMI* - Modern alternative: - +gRPC-based management - Streaming telemetry - JSON IETF encoding - mTLS +authentication - *Prometheus/OpenMetrics:* - Metrics export endpoint - +Bearer token auth - Client certificates - Security levels: Insecure, +Basic, Strong, Zero-Trust - SDP integration for all management access + +*Master Configuration* (`+master_config.ads+`): - *Deployment modes:* +Development, Staging, Production, Honeypot, Research - *Environment +types:* Local, CI/CD, Internal, DMZ, Public, Air-Gapped - Configuration +profiles with presets - Validation with security posture checking - +YAML/JSON import/export - Hot configuration reload (no restart) - +Configuration diff and comparison - Migration planning - *Emergency +configurations:* - Lockdown (close everything) - Recovery (minimal safe +access) - Minimal-Safe (basic functionality) - Backward compatibility +with simple config + +*Total:* ~3,000 additional lines of Ada specifications + +''''' + +=== Documentation + +==== User Documentation + +[arabic] +. *README.md* (root) - Project overview with enterprise features +. *README.md* (Ada) - Complete user guide +. *USE_CASES.md* - Detailed scenarios (6 use cases) +. *ENTERPRISE_FEATURES.md* - Comprehensive enterprise guide (350+ lines) +. *CLAUDE.md* - AI context and project rationale + +==== Example Configurations + +[arabic] +. *config.ini.example* - Simple configuration template +. *production_config.yaml* - Enterprise configuration (310 lines) +* Zero-trust SDP setup +* SSH port rotation +* Security header obfuscation +* Service scheduling +* NETCONF/RESTCONF configuration +* Complete firewall rules +* Logging and monitoring +* Backup and recovery +* Emergency procedures + +==== Developer Documentation + +* Inline code comments throughout +* Security warnings in headers +* TODO comments for future work +* Architecture diagrams +* Integration examples + +*Total:* ~2,000+ lines of documentation + +''''' + +=== Key Features Matrix + +[cols=",,",options="header",] +|=== +|Feature |Core |Enterprise +|HINFO/LOC Fluctuation |✅ |✅ +|Extended DNS Records (20+ types) |❌ |✅ +|IPv4/IPv6 Toggle |❌ |✅ +|Firewall Integration |❌ |✅ +|Port Rotation |❌ |✅ +|Service Scheduling |❌ |✅ +|Security Headers |❌ |✅ +|Server Obfuscation |❌ |✅ +|Diagnostic Mode |❌ |✅ +|Zero-Trust SDP |❌ |✅ +|SPA (Single Packet Auth) |❌ |✅ +|Device Posture Validation |❌ |✅ +|Micro-Segmentation |❌ |✅ +|NETCONF Support |❌ |✅ +|RESTCONF Support |❌ |✅ +|gNMI Support |❌ |✅ +|Prometheus Metrics |❌ |✅ +|Master Configuration |❌ |✅ +|Hot Reload |❌ |✅ +|Emergency Lockdown |❌ |✅ +|=== + +''''' + +=== Use Case Examples + +==== 1. Public Web Server with Zero-Trust + +*Scenario:* Secure public web server with maintainer access + +*Configuration:* + +[source,yaml] +---- +deployment: + mode: production + environment: public_internet + +sdp: + enabled: true # Zero-trust access + default_deny: true + +firewall: + port_rotation: + ssh: + strategy: time_based + base_port: 10000 + rotation_interval: 3600 # Hourly + +security_headers: + server_header: + mode: obfuscated + randomize: true + diagnostic_mode: true + diagnostic_token: "" + +protocols: + snmp: false + netconf: true +---- + +*Result:* - All ports closed by default - SSH port rotates every hour +(maintainers calculate offline) - SPA required for access - Server +headers obfuscated - Real stack visible to maintainers with secret token +- Managed via NETCONF (not SNMP) + +==== 2. Advanced Honeypot + +*Scenario:* Deception-focused honeypot deployment + +*Configuration:* + +[source,yaml] +---- +deployment: + mode: honeypot + +fluctuation: + hinfo_enabled: true # CPU/OS changes + loc_enabled: true # Location changes + quantum_server_mode: true + +service_scheduling: + mx: + scheduled: true + windows: weekdays:09:00-17:00 + ssh: + port_rotation: true + +security_headers: + server_header: + mode: obfuscated + randomize: true +---- + +*Result:* - HINFO: CPU/OS changes hourly - LOC: Geographic location +changes every 30 min - MX: Accepts mail only 9am-5pm weekdays - SSH: +Port rotates every 2 hours - Server headers randomized - Appears +unstable/misconfigured to attackers - Extended engagement time + +==== 3. Enterprise Internal Server + +*Scenario:* Internal application server with strict access control + +*Configuration:* + +[source,yaml] +---- +deployment: + mode: production + environment: internal_network + +sdp: + enabled: true + continuous_verify: true + posture: + antivirus_required: true + disk_encrypted: true + patch_level_days: 30 + +firewall: + maintenance_windows: + - description: "Weekly maintenance" + days: saturday + time: 02:00-06:00 + allowed_ips: [192.168.1.0/24] + +protocols: + netconf: true + restconf: true + metrics: + prometheus: true + auth_required: true +---- + +*Result:* - Zero-trust for all access - Device posture checked before +access - Continuous re-authentication - Maintenance window on Saturdays +- Managed via NETCONF/RESTCONF - Prometheus metrics with auth + +''''' + +=== Security Advantages + +==== Compile-Time Safety (Ada) + +[source,ada] +---- +-- Type system prevents invalid values +type Latitude_Degrees is delta 0.000001 range -90.0 .. 90.0; + +-- Compiler GUARANTEES this cannot compile: +Bad_Lat : Latitude_Degrees := 100.0; -- ERROR at compile time + +-- Compare to Python/JavaScript: +lat = 100.0 # Accepted, fails later (or worse, silently wrong) +---- + +==== Runtime Safety + +* Overflow checking always enabled (`+-gnato+`) +* Stack checking (`+-fstack-check+`) +* Validity checking (`+-gnatVa+`) +* Constant-time comparison (timing attack prevention) +* Bounded strings (no buffer overflows) + +==== Defense in Depth + +[arabic] +. *Network Layer:* SDP with SPA, firewall rules +. *Transport Layer:* TLS/mTLS for all management +. *Application Layer:* Authentication, authorization, session management +. *Data Layer:* Input validation, type safety +. *Monitoring Layer:* Comprehensive logging, metrics export + +==== Zero-Trust Architecture + +* Default deny all +* Continuous verification +* Device posture validation +* Micro-segmentation +* Identity-based access +* Session timeouts + +''''' + +=== File Structure + +.... +resource-record-fluctuator/ +├── .gitignore +├── LICENSE (MIT with security disclaimer) +├── README.md (✅ Enterprise features documented) +├── CLAUDE.md (AI context) +├── PROJECT_SUMMARY.md (This file) +│ +├── hinfo_loc_fluctuator/ (Elixir reference, not recommended) +│ ├── README.md (Why Ada was chosen) +│ └── lib/dns_records.ex (Basic example) +│ +└── hinfo_loc_fluctuator_ada/ (MAIN IMPLEMENTATION) + │ + ├── src/ (Ada source code) + │ ├── main.adb (Entry point) + │ │ + │ │ # Core modules + │ ├── dns_records.ads/adb (Original HINFO/LOC) + │ ├── secure_auth.ads/adb (Authentication) + │ ├── randomizer.ads/adb (Randomization + CSV parser) + │ ├── tui.ads/adb (Text UI) + │ │ + │ │ # Advanced features + │ ├── zone_writer.ads/adb (BIND zone files) + │ ├── logger.ads/adb (Thread-safe logging) + │ ├── config.ads/adb (INI configuration) + │ ├── scheduler.ads/adb (Ada tasking) + │ ├── dns_update.ads/adb (RFC 2136 framework) + │ │ + │ │ # Enterprise modules (NEW) + │ ├── dns_records_extended.ads (ALL DNS types) + │ ├── firewall_manager.ads (Firewall integration) + │ ├── security_headers.ads (Header obfuscation) + │ ├── sdp_controller.ads (Zero-trust SDP) + │ ├── protocol_manager.ads (NETCONF/RESTCONF/gNMI) + │ └── master_config.ads (Enterprise config) + │ + ├── data/ (Sample data) + │ ├── machines.txt (68 CPUs) + │ ├── operating_systems.txt (77 OSes) + │ └── locations.csv (52 locations) + │ + ├── docs/ (Documentation) + │ ├── USE_CASES.md (Detailed scenarios) + │ └── ENTERPRISE_FEATURES.md (🆕 Enterprise guide) + │ + ├── examples/ (Example configurations) + │ └── production_config.yaml (🆕 Complete example) + │ + ├── bin/ (Executables - gitignored) + ├── obj/ (Build artifacts - gitignored) + │ + ├── hinfo_loc_fluctuator.gpr (GNAT project) + ├── Makefile (Build automation) + ├── config.ini.example (Simple config template) + └── README.md (Complete user guide) +.... + +''''' + +=== Metrics + +==== Code Statistics + +*Ada Specifications (.ads):* - Core modules: 7 files, ~1,200 lines - +Advanced features: 7 files, ~1,000 lines - Enterprise modules: 6 files, +~2,300 lines - *Total specifications: 20 files, ~4,500 lines* + +*Ada Bodies (.adb):* - Core modules: 7 files, ~1,500 lines - Advanced +features: 7 files, ~1,500 lines - Enterprise bodies: (TBD - frameworks +complete) - *Total bodies: 14 files, ~3,000 lines* + +*Data Files:* - 3 files, 200+ entries + +*Documentation:* - 7 markdown files, ~3,500 lines - 1 YAML example, 310 +lines - Inline comments, ~1,000 lines - *Total documentation: ~4,800 +lines* + +*Grand Total: ~12,300 lines* (code + docs + config + data) + +==== Commit History + +[arabic] +. `+833b411+` - Initial CLAUDE.md +. `+199f6cf+` - CLAUDE.md comprehensive update +. `+776fd7a+` - Core Ada implementation (2,071 lines) +. `+5fb176f+` - Advanced features (1,960 lines) +. `+b8cb224+` - DNS UPDATE + infrastructure (1,113 lines) +. `+1cf3614+` - .gitignore fix +. `+7efa8d5+` - *Enterprise platform (3,048 lines)* +. `+a18de3e+` - README update with enterprise features + +*Total: 8 commits, comprehensive transformation* + +''''' + +=== Technology Stack + +==== Core Technologies + +* *Ada 2012* - Primary language +* *GNAT* - Compiler (FSF GNAT or AdaCore) +* *SPARK* - Optional formal verification +* *Make* - Build automation + +==== Supported Integrations + +* *Firewall:* firewalld, iptables, nftables, pf +* *Web Servers:* nginx, Apache +* *Languages:* PHP (stack hiding) +* *Metrics:* Prometheus, OpenMetrics +* *Management:* NETCONF, RESTCONF, gNMI +* *DNS:* BIND, PowerDNS, NSD (via zone files) + +==== Protocols & Standards + +* DNS: RFC 1034, 1035, 1876, 2136, 2845, 8482 +* Security: NIST SP 800-207 (Zero Trust) +* SDP: Cloud Security Alliance SDP v2.0 +* Management: RFC 6241 (NETCONF), RFC 8040 (RESTCONF) +* DNSSEC: RFC 4033, 4034, 4035 +* Security Headers: W3C standards + +''''' + +=== Compliance & Standards + +*Supported Frameworks:* - NIST Zero Trust Architecture (SP 800-207) - +Cloud Security Alliance SDP - PCI DSS (firewall + access control) - +HIPAA (access controls + audit logging) - SOC 2 (security controls + +monitoring) + +*Security Certifications Supportable:* - ISO 27001 (Information +Security) - Common Criteria (EAL with SPARK proofs) + +''''' + +=== Future Implementation + +==== Immediate (Frameworks Complete) + +* Implement .adb bodies for enterprise modules +* DNS UPDATE wire format encoding +* TSIG cryptographic signing +* UDP/TCP socket communication +* bcrypt/Argon2 password hashing +* Integration with existing TUI + +==== Medium-Term + +* SPARK formal verification proofs +* Unit test suite +* Integration test framework +* Performance benchmarks +* Ncurses-based enhanced TUI +* API server implementation + +==== Long-Term + +* Web-based management UI +* Clustering support +* High-availability configuration +* Plugin system +* Multi-tenancy support + +''''' + +=== Success Metrics + +*For Original Scope:* ✅ Type-safe DNS records ✅ Security-focused +implementation ✅ Comprehensive documentation ✅ Working TUI ✅ Build +system ✅ Sample data + +*For Enterprise Scope:* ✅ All DNS record types specified ✅ Firewall +integration designed ✅ Port rotation strategies defined ✅ Security +header obfuscation complete ✅ Zero-trust SDP architecture specified ✅ +Modern protocol support (NETCONF/RESTCONF/gNMI) ✅ Master configuration +system ✅ Enterprise documentation (350+ lines) ✅ Production +configuration example (310 lines) ✅ Migration path documented + +*Achievement:* 🎯 *200% of original scope delivered* + +''''' + +=== Conclusion + +What began as a hobby project to randomize deprecated DNS records has +evolved into a *comprehensive enterprise-grade DNS security and +infrastructure management platform* with: + +* *Zero-trust access control* (CSA SDP) +* *Advanced obfuscation* (DNS + HTTP headers) +* *Modern management* (NETCONF/RESTCONF/gNMI) +* *Comprehensive firewall integration* (4 backends) +* *Port rotation and service scheduling* +* *All DNS record types* (20+) +* *Enterprise configuration management* +* *Production-ready architecture* + +All built with *Ada* for maximum security and type safety, with +specifications complete for ~12,000+ lines of code and documentation. + +The platform is now ready for: 1. Implementation body completion 2. +Testing and validation 3. Production deployment 4. Security auditing 5. +Formal verification (SPARK) + +*This represents unheard-of levels of potential* for DNS security, +infrastructure management, and zero-trust access control - all while +maintaining the original "`quantum server`" charm! 🐱⚛️ + +''''' + +*Project Status:* ✅ *Specifications Complete, Ready for Implementation* + +*Security Posture:* ⭐⭐⭐⭐⭐ *Enterprise-Grade* + +*Documentation:* 📚 *Comprehensive* + +*Future Potential:* 🚀 *Unlimited* diff --git a/PROJECT_SUMMARY.md b/PROJECT_SUMMARY.md deleted file mode 100644 index 81c2cc7..0000000 --- a/PROJECT_SUMMARY.md +++ /dev/null @@ -1,633 +0,0 @@ -# HINFO-LOC Fluctuator - Complete Project Summary - -## Executive Summary - -What started as a hobby DNS record randomization tool has been transformed into a **comprehensive enterprise-grade DNS security and infrastructure management platform** with zero-trust access control, advanced obfuscation, and modern management protocols. - -**Built with Ada** for maximum security, type safety, and formal verification potential. - ---- - -## Project Transformation - -### Original Scope -- Randomize HINFO (CPU/OS) and LOC (geographic) records -- Security-focused Ada implementation -- Basic TUI and data pools -- ~2,000 lines of code - -### Current Scope -- **Enterprise DNS security platform** -- Zero-trust access control (SDP) -- Firewall integration with time-based access -- Port rotation and service scheduling -- Security header obfuscation -- Modern management protocols (NETCONF/RESTCONF/gNMI) -- **~10,000+ lines of code** (specifications + documentation) - ---- - -## What Was Built - -### Phase 1: Foundation (Original) - -**Core Modules (14 files):** -1. `dns_records.ads/adb` - Type-safe HINFO/LOC records -2. `secure_auth.ads/adb` - Authentication with permission levels -3. `randomizer.ads/adb` - Data loading and random generation with CSV parser -4. `tui.ads/adb` - Interactive text user interface -5. `main.adb` - Entry point with command-line parsing - -**Build System:** -- GNAT project file with security flags always enabled -- Makefile with debug/release/prove targets -- Overflow checking even in release builds - -**Data:** -- 68 CPU types (machines.txt) -- 77 operating systems (operating_systems.txt) -- 52 geographic locations (locations.csv) - -**Advanced Features:** -- Zone file writer (BIND format) with SOA generation -- Logging system (thread-safe with protected objects) -- Configuration system (INI format) -- Scheduled fluctuation (Ada tasking) - -**Documentation:** -- README.md (comprehensive user guide) -- USE_CASES.md (detailed scenarios) -- CLAUDE.md (AI context documentation) - -**Total:** ~4,000 lines of Ada code + documentation - ---- - -### Phase 2: Enterprise Platform (NEW) - -**Extended DNS Records Module** (`dns_records_extended.ads`): -- **20+ DNS record types:** - - Address: A, AAAA, PTR - - Delegation: NS, CNAME - - Mail: MX, SPF, DKIM, DMARC - - Service: SRV, NAPTR - - Security: CAA, TLSA (DANE), SSHFP - - Access Control: APL (CIDR-based) - - DNSSEC: DS, DNSKEY, NSEC, NSEC3 -- IPv4/IPv6 protocol toggle (Dual-Stack, IPv4-Only, IPv6-Only, Disabled) -- DNS topology modes (6 types including Split-Horizon, Hidden-Primary) -- AXFR configuration with TSIG authentication -- Complete IPv4/IPv6 address handling - -**Firewall Manager** (`firewall_manager.ads`): -- **Backend support:** firewalld, iptables, nftables, pf -- Time-based maintenance windows with IP restrictions -- **Port rotation** (4 strategies): - 1. Sequential (10000, 10001, 10002...) - 2. Random (pseudorandom from pool) - 3. Time-Based (maintainers calculate offline: `port = base + (timestamp/interval) % range`) - 4. Pre-Shared Key (algorithm with secret) -- Service scheduling for MX, RSS, NNTP, SSH -- Stateful vs stateless firewall rules -- Port knocking integration -- IPv4/IPv6 firewall toggle -- Emergency lockdown/recovery modes - -**Security Headers** (`security_headers.ads`): -- **Server obfuscation modes:** - - Hidden (don't send header) - - Obfuscated (send fake value, randomized) - - Diagnostic (real value only to authorized IPs with secret token) - - Standard (real value to everyone) -- X-Powered-By hiding -- **All security headers:** - - HSTS (Strict-Transport-Security) - - CSP (Content-Security-Policy) with nonce generation - - X-Frame-Options - - X-Content-Type-Options - - Referrer-Policy - - Permissions-Policy (all features configurable) - - Experimental: COEP, COOP, CORP, Expect-CT, NEL -- Integration with HINFO for consistent fake stack -- Nginx/Apache/PHP configuration generation -- Diagnostic mode for maintainers - -**Software-Defined Perimeter** (`sdp_controller.ads`): -- **Cloud Security Alliance SDP architecture** -- Single Packet Authorization (SPA): - - Encryption: AES-256-GCM, ChaCha20-Poly1305 - - HMAC: SHA256, SHA512, SHA3-256 - - Anti-replay with nonces -- **Zero-trust policy engine:** - - Trust levels: Untrusted → Device Verified → User Authenticated → Posture Valid → Full Trust - - Device posture validation (OS version, AV, firewall, disk encryption, patch level) - - Continuous authentication (periodic re-verification) -- Identity-based access (user + device + MFA) -- Session management with automatic firewall cleanup -- Micro-segmentation for network isolation -- Access policies with time/IP/user/device/service restrictions -- Integration with firewall for dynamic rules - -**Protocol Manager** (`protocol_manager.ads`): -- **SNMP** (with warnings, disabled by default): - - v1/v2c marked insecure - - v3 with encryption/authentication -- **NETCONF** (RFC 6241) - Recommended: - - XML-based over SSH - - Candidate configuration - - Confirmed commit - - Rollback support - - MFA support -- **RESTCONF** (RFC 8040) - Recommended: - - RESTful API over HTTPS - - Client certificate auth - - OAuth2 support - - Rate limiting - - CORS configuration -- **gNMI** - Modern alternative: - - gRPC-based management - - Streaming telemetry - - JSON IETF encoding - - mTLS authentication -- **Prometheus/OpenMetrics:** - - Metrics export endpoint - - Bearer token auth - - Client certificates -- Security levels: Insecure, Basic, Strong, Zero-Trust -- SDP integration for all management access - -**Master Configuration** (`master_config.ads`): -- **Deployment modes:** Development, Staging, Production, Honeypot, Research -- **Environment types:** Local, CI/CD, Internal, DMZ, Public, Air-Gapped -- Configuration profiles with presets -- Validation with security posture checking -- YAML/JSON import/export -- Hot configuration reload (no restart) -- Configuration diff and comparison -- Migration planning -- **Emergency configurations:** - - Lockdown (close everything) - - Recovery (minimal safe access) - - Minimal-Safe (basic functionality) -- Backward compatibility with simple config - -**Total:** ~3,000 additional lines of Ada specifications - ---- - -## Documentation - -### User Documentation -1. **README.md** (root) - Project overview with enterprise features -2. **README.md** (Ada) - Complete user guide -3. **USE_CASES.md** - Detailed scenarios (6 use cases) -4. **ENTERPRISE_FEATURES.md** - Comprehensive enterprise guide (350+ lines) -5. **CLAUDE.md** - AI context and project rationale - -### Example Configurations -1. **config.ini.example** - Simple configuration template -2. **production_config.yaml** - Enterprise configuration (310 lines) - - Zero-trust SDP setup - - SSH port rotation - - Security header obfuscation - - Service scheduling - - NETCONF/RESTCONF configuration - - Complete firewall rules - - Logging and monitoring - - Backup and recovery - - Emergency procedures - -### Developer Documentation -- Inline code comments throughout -- Security warnings in headers -- TODO comments for future work -- Architecture diagrams -- Integration examples - -**Total:** ~2,000+ lines of documentation - ---- - -## Key Features Matrix - -| Feature | Core | Enterprise | -|---------|------|------------| -| HINFO/LOC Fluctuation | ✅ | ✅ | -| Extended DNS Records (20+ types) | ❌ | ✅ | -| IPv4/IPv6 Toggle | ❌ | ✅ | -| Firewall Integration | ❌ | ✅ | -| Port Rotation | ❌ | ✅ | -| Service Scheduling | ❌ | ✅ | -| Security Headers | ❌ | ✅ | -| Server Obfuscation | ❌ | ✅ | -| Diagnostic Mode | ❌ | ✅ | -| Zero-Trust SDP | ❌ | ✅ | -| SPA (Single Packet Auth) | ❌ | ✅ | -| Device Posture Validation | ❌ | ✅ | -| Micro-Segmentation | ❌ | ✅ | -| NETCONF Support | ❌ | ✅ | -| RESTCONF Support | ❌ | ✅ | -| gNMI Support | ❌ | ✅ | -| Prometheus Metrics | ❌ | ✅ | -| Master Configuration | ❌ | ✅ | -| Hot Reload | ❌ | ✅ | -| Emergency Lockdown | ❌ | ✅ | - ---- - -## Use Case Examples - -### 1. Public Web Server with Zero-Trust - -**Scenario:** Secure public web server with maintainer access - -**Configuration:** -```yaml -deployment: - mode: production - environment: public_internet - -sdp: - enabled: true # Zero-trust access - default_deny: true - -firewall: - port_rotation: - ssh: - strategy: time_based - base_port: 10000 - rotation_interval: 3600 # Hourly - -security_headers: - server_header: - mode: obfuscated - randomize: true - diagnostic_mode: true - diagnostic_token: "" - -protocols: - snmp: false - netconf: true -``` - -**Result:** -- All ports closed by default -- SSH port rotates every hour (maintainers calculate offline) -- SPA required for access -- Server headers obfuscated -- Real stack visible to maintainers with secret token -- Managed via NETCONF (not SNMP) - -### 2. Advanced Honeypot - -**Scenario:** Deception-focused honeypot deployment - -**Configuration:** -```yaml -deployment: - mode: honeypot - -fluctuation: - hinfo_enabled: true # CPU/OS changes - loc_enabled: true # Location changes - quantum_server_mode: true - -service_scheduling: - mx: - scheduled: true - windows: weekdays:09:00-17:00 - ssh: - port_rotation: true - -security_headers: - server_header: - mode: obfuscated - randomize: true -``` - -**Result:** -- HINFO: CPU/OS changes hourly -- LOC: Geographic location changes every 30 min -- MX: Accepts mail only 9am-5pm weekdays -- SSH: Port rotates every 2 hours -- Server headers randomized -- Appears unstable/misconfigured to attackers -- Extended engagement time - -### 3. Enterprise Internal Server - -**Scenario:** Internal application server with strict access control - -**Configuration:** -```yaml -deployment: - mode: production - environment: internal_network - -sdp: - enabled: true - continuous_verify: true - posture: - antivirus_required: true - disk_encrypted: true - patch_level_days: 30 - -firewall: - maintenance_windows: - - description: "Weekly maintenance" - days: saturday - time: 02:00-06:00 - allowed_ips: [192.168.1.0/24] - -protocols: - netconf: true - restconf: true - metrics: - prometheus: true - auth_required: true -``` - -**Result:** -- Zero-trust for all access -- Device posture checked before access -- Continuous re-authentication -- Maintenance window on Saturdays -- Managed via NETCONF/RESTCONF -- Prometheus metrics with auth - ---- - -## Security Advantages - -### Compile-Time Safety (Ada) - -```ada --- Type system prevents invalid values -type Latitude_Degrees is delta 0.000001 range -90.0 .. 90.0; - --- Compiler GUARANTEES this cannot compile: -Bad_Lat : Latitude_Degrees := 100.0; -- ERROR at compile time - --- Compare to Python/JavaScript: -lat = 100.0 # Accepted, fails later (or worse, silently wrong) -``` - -### Runtime Safety - -- Overflow checking always enabled (`-gnato`) -- Stack checking (`-fstack-check`) -- Validity checking (`-gnatVa`) -- Constant-time comparison (timing attack prevention) -- Bounded strings (no buffer overflows) - -### Defense in Depth - -1. **Network Layer:** SDP with SPA, firewall rules -2. **Transport Layer:** TLS/mTLS for all management -3. **Application Layer:** Authentication, authorization, session management -4. **Data Layer:** Input validation, type safety -5. **Monitoring Layer:** Comprehensive logging, metrics export - -### Zero-Trust Architecture - -- Default deny all -- Continuous verification -- Device posture validation -- Micro-segmentation -- Identity-based access -- Session timeouts - ---- - -## File Structure - -``` -resource-record-fluctuator/ -├── .gitignore -├── LICENSE (MIT with security disclaimer) -├── README.md (✅ Enterprise features documented) -├── CLAUDE.md (AI context) -├── PROJECT_SUMMARY.md (This file) -│ -├── hinfo_loc_fluctuator/ (Elixir reference, not recommended) -│ ├── README.md (Why Ada was chosen) -│ └── lib/dns_records.ex (Basic example) -│ -└── hinfo_loc_fluctuator_ada/ (MAIN IMPLEMENTATION) - │ - ├── src/ (Ada source code) - │ ├── main.adb (Entry point) - │ │ - │ │ # Core modules - │ ├── dns_records.ads/adb (Original HINFO/LOC) - │ ├── secure_auth.ads/adb (Authentication) - │ ├── randomizer.ads/adb (Randomization + CSV parser) - │ ├── tui.ads/adb (Text UI) - │ │ - │ │ # Advanced features - │ ├── zone_writer.ads/adb (BIND zone files) - │ ├── logger.ads/adb (Thread-safe logging) - │ ├── config.ads/adb (INI configuration) - │ ├── scheduler.ads/adb (Ada tasking) - │ ├── dns_update.ads/adb (RFC 2136 framework) - │ │ - │ │ # Enterprise modules (NEW) - │ ├── dns_records_extended.ads (ALL DNS types) - │ ├── firewall_manager.ads (Firewall integration) - │ ├── security_headers.ads (Header obfuscation) - │ ├── sdp_controller.ads (Zero-trust SDP) - │ ├── protocol_manager.ads (NETCONF/RESTCONF/gNMI) - │ └── master_config.ads (Enterprise config) - │ - ├── data/ (Sample data) - │ ├── machines.txt (68 CPUs) - │ ├── operating_systems.txt (77 OSes) - │ └── locations.csv (52 locations) - │ - ├── docs/ (Documentation) - │ ├── USE_CASES.md (Detailed scenarios) - │ └── ENTERPRISE_FEATURES.md (🆕 Enterprise guide) - │ - ├── examples/ (Example configurations) - │ └── production_config.yaml (🆕 Complete example) - │ - ├── bin/ (Executables - gitignored) - ├── obj/ (Build artifacts - gitignored) - │ - ├── hinfo_loc_fluctuator.gpr (GNAT project) - ├── Makefile (Build automation) - ├── config.ini.example (Simple config template) - └── README.md (Complete user guide) -``` - ---- - -## Metrics - -### Code Statistics - -**Ada Specifications (.ads):** -- Core modules: 7 files, ~1,200 lines -- Advanced features: 7 files, ~1,000 lines -- Enterprise modules: 6 files, ~2,300 lines -- **Total specifications: 20 files, ~4,500 lines** - -**Ada Bodies (.adb):** -- Core modules: 7 files, ~1,500 lines -- Advanced features: 7 files, ~1,500 lines -- Enterprise bodies: (TBD - frameworks complete) -- **Total bodies: 14 files, ~3,000 lines** - -**Data Files:** -- 3 files, 200+ entries - -**Documentation:** -- 7 markdown files, ~3,500 lines -- 1 YAML example, 310 lines -- Inline comments, ~1,000 lines -- **Total documentation: ~4,800 lines** - -**Grand Total: ~12,300 lines** (code + docs + config + data) - -### Commit History - -1. `833b411` - Initial CLAUDE.md -2. `199f6cf` - CLAUDE.md comprehensive update -3. `776fd7a` - Core Ada implementation (2,071 lines) -4. `5fb176f` - Advanced features (1,960 lines) -5. `b8cb224` - DNS UPDATE + infrastructure (1,113 lines) -6. `1cf3614` - .gitignore fix -7. `7efa8d5` - **Enterprise platform (3,048 lines)** -8. `a18de3e` - README update with enterprise features - -**Total: 8 commits, comprehensive transformation** - ---- - -## Technology Stack - -### Core Technologies -- **Ada 2012** - Primary language -- **GNAT** - Compiler (FSF GNAT or AdaCore) -- **SPARK** - Optional formal verification -- **Make** - Build automation - -### Supported Integrations -- **Firewall:** firewalld, iptables, nftables, pf -- **Web Servers:** nginx, Apache -- **Languages:** PHP (stack hiding) -- **Metrics:** Prometheus, OpenMetrics -- **Management:** NETCONF, RESTCONF, gNMI -- **DNS:** BIND, PowerDNS, NSD (via zone files) - -### Protocols & Standards -- DNS: RFC 1034, 1035, 1876, 2136, 2845, 8482 -- Security: NIST SP 800-207 (Zero Trust) -- SDP: Cloud Security Alliance SDP v2.0 -- Management: RFC 6241 (NETCONF), RFC 8040 (RESTCONF) -- DNSSEC: RFC 4033, 4034, 4035 -- Security Headers: W3C standards - ---- - -## Compliance & Standards - -**Supported Frameworks:** -- NIST Zero Trust Architecture (SP 800-207) -- Cloud Security Alliance SDP -- PCI DSS (firewall + access control) -- HIPAA (access controls + audit logging) -- SOC 2 (security controls + monitoring) - -**Security Certifications Supportable:** -- ISO 27001 (Information Security) -- Common Criteria (EAL with SPARK proofs) - ---- - -## Future Implementation - -### Immediate (Frameworks Complete) -- Implement .adb bodies for enterprise modules -- DNS UPDATE wire format encoding -- TSIG cryptographic signing -- UDP/TCP socket communication -- bcrypt/Argon2 password hashing -- Integration with existing TUI - -### Medium-Term -- SPARK formal verification proofs -- Unit test suite -- Integration test framework -- Performance benchmarks -- Ncurses-based enhanced TUI -- API server implementation - -### Long-Term -- Web-based management UI -- Clustering support -- High-availability configuration -- Plugin system -- Multi-tenancy support - ---- - -## Success Metrics - -**For Original Scope:** -✅ Type-safe DNS records -✅ Security-focused implementation -✅ Comprehensive documentation -✅ Working TUI -✅ Build system -✅ Sample data - -**For Enterprise Scope:** -✅ All DNS record types specified -✅ Firewall integration designed -✅ Port rotation strategies defined -✅ Security header obfuscation complete -✅ Zero-trust SDP architecture specified -✅ Modern protocol support (NETCONF/RESTCONF/gNMI) -✅ Master configuration system -✅ Enterprise documentation (350+ lines) -✅ Production configuration example (310 lines) -✅ Migration path documented - -**Achievement:** 🎯 **200% of original scope delivered** - ---- - -## Conclusion - -What began as a hobby project to randomize deprecated DNS records has evolved into a **comprehensive enterprise-grade DNS security and infrastructure management platform** with: - -- **Zero-trust access control** (CSA SDP) -- **Advanced obfuscation** (DNS + HTTP headers) -- **Modern management** (NETCONF/RESTCONF/gNMI) -- **Comprehensive firewall integration** (4 backends) -- **Port rotation and service scheduling** -- **All DNS record types** (20+) -- **Enterprise configuration management** -- **Production-ready architecture** - -All built with **Ada** for maximum security and type safety, with specifications complete for ~12,000+ lines of code and documentation. - -The platform is now ready for: -1. Implementation body completion -2. Testing and validation -3. Production deployment -4. Security auditing -5. Formal verification (SPARK) - -**This represents unheard-of levels of potential** for DNS security, infrastructure management, and zero-trust access control - all while maintaining the original "quantum server" charm! 🐱⚛️ - ---- - -**Project Status:** ✅ **Specifications Complete, Ready for Implementation** - -**Security Posture:** ⭐⭐⭐⭐⭐ **Enterprise-Grade** - -**Documentation:** 📚 **Comprehensive** - -**Future Potential:** 🚀 **Unlimited** diff --git a/PROOF-NEEDS.adoc b/PROOF-NEEDS.adoc new file mode 100644 index 0000000..3571282 --- /dev/null +++ b/PROOF-NEEDS.adoc @@ -0,0 +1,52 @@ +== PROOF-NEEDS.md + +=== Current State + +* *LOC*: ~9,350 +* *Languages*: Ada, Idris2, Zig, Nickel +* *Existing ABI proofs*: `+src/abi/*.idr+` (template-level) +* *Dangerous patterns*: None detected + +=== What Needs Proving + +==== DNS Record Manipulation (hinfo_loc_fluctuator_ada/src/) + +* `+dns_records.adb/ads+`, `+dns_records_extended.adb/ads+` — DNS record +creation and modification +* `+dns_update.adb/ads+` — DNS update protocol +* Prove: generated DNS records conform to RFC specifications (RFC 1035, +etc.) +* Prove: DNS updates are idempotent or safely retryable + +==== Authentication (hinfo_loc_fluctuator_ada/src/secure_auth.adb) + +* Secure authentication for DNS updates +* Prove: authentication tokens are never transmitted in cleartext +* Prove: authentication failure results in no DNS modifications + +==== Firewall Management (hinfo_loc_fluctuator_ada/src/firewall_manager.adb/ads) + +* Firewall rule manipulation during DNS fluctuation +* Prove: firewall rules always return to a safe state after fluctuation + +==== Scheduler (hinfo_loc_fluctuator_ada/src/scheduler.adb/ads) + +* Timed DNS fluctuation +* Prove: scheduler never produces overlapping fluctuation windows + +==== SDP Controller (hinfo_loc_fluctuator_ada/src/sdp_controller.adb/ads) + +* SDP (Software-Defined Perimeter) control +* Prove: SDP state is consistent with DNS state after fluctuation + +=== Recommended Prover + +* *SPARK* (natural fit — Ada code can be annotated with SPARK contracts) +* *Idris2* for ABI layer + +=== Priority + +*HIGH* — Network security tool manipulating DNS records and firewall +rules. Incorrect fluctuation could cause service outages or security +exposures. SPARK annotations on the Ada code would be the most effective +approach. diff --git a/PROOF-NEEDS.md b/PROOF-NEEDS.md deleted file mode 100644 index 0d305a0..0000000 --- a/PROOF-NEEDS.md +++ /dev/null @@ -1,43 +0,0 @@ -# PROOF-NEEDS.md - - -## Current State - -- **LOC**: ~9,350 -- **Languages**: Ada, Idris2, Zig, Nickel -- **Existing ABI proofs**: `src/abi/*.idr` (template-level) -- **Dangerous patterns**: None detected - -## What Needs Proving - -### DNS Record Manipulation (hinfo_loc_fluctuator_ada/src/) -- `dns_records.adb/ads`, `dns_records_extended.adb/ads` — DNS record creation and modification -- `dns_update.adb/ads` — DNS update protocol -- Prove: generated DNS records conform to RFC specifications (RFC 1035, etc.) -- Prove: DNS updates are idempotent or safely retryable - -### Authentication (hinfo_loc_fluctuator_ada/src/secure_auth.adb) -- Secure authentication for DNS updates -- Prove: authentication tokens are never transmitted in cleartext -- Prove: authentication failure results in no DNS modifications - -### Firewall Management (hinfo_loc_fluctuator_ada/src/firewall_manager.adb/ads) -- Firewall rule manipulation during DNS fluctuation -- Prove: firewall rules always return to a safe state after fluctuation - -### Scheduler (hinfo_loc_fluctuator_ada/src/scheduler.adb/ads) -- Timed DNS fluctuation -- Prove: scheduler never produces overlapping fluctuation windows - -### SDP Controller (hinfo_loc_fluctuator_ada/src/sdp_controller.adb/ads) -- SDP (Software-Defined Perimeter) control -- Prove: SDP state is consistent with DNS state after fluctuation - -## Recommended Prover - -- **SPARK** (natural fit — Ada code can be annotated with SPARK contracts) -- **Idris2** for ABI layer - -## Priority - -**HIGH** — Network security tool manipulating DNS records and firewall rules. Incorrect fluctuation could cause service outages or security exposures. SPARK annotations on the Ada code would be the most effective approach. diff --git a/RSR_COMPLIANCE.adoc b/RSR_COMPLIANCE.adoc new file mode 100644 index 0000000..ced65f6 --- /dev/null +++ b/RSR_COMPLIANCE.adoc @@ -0,0 +1,353 @@ +== RSR Compliance Assessment + +*Project*: HINFO-LOC Fluctuator *Assessment Date*: 2025-11-22 *RSR +Framework Version*: 1.0 (Rhodium Standard Repository) *Target Tier*: +Bronze → Silver → Gold + +''''' + +=== Executive Summary + +*Current Compliance Level*: *Bronze (Partial)* → Upgrading to *Silver* + +The HINFO-LOC Fluctuator demonstrates strong foundational security and +type safety through Ada 2012, but lacks critical RSR governance and +community documentation. This assessment identifies gaps and provides an +implementation roadmap. + +''''' + +=== RSR 11-Category Compliance Matrix + +[width="100%",cols="10%,28%,22%,20%,20%",options="header",] +|=== +|# |Category |Status |Score |Notes +|1 |*Type Safety* |✅ COMPLETE |10/10 |Ada 2012 compile-time type +checking, range constraints + +|2 |*Memory Safety* |✅ COMPLETE |10/10 |No buffer overflows, ownership +model, zero `+unsafe+` + +|3 |*Documentation* |⚠️ PARTIAL |5/10 |README exists, missing governance +docs + +|4 |*.well-known/* |❌ MISSING |0/10 |No security.txt, ai.txt, +humans.txt + +|5 |*Build System* |⚠️ PARTIAL |6/10 |GNAT+Makefile, no Justfile/Nix + +|6 |*Testing* |⚠️ PARTIAL |4/10 |No unit tests, no RSR self-verification + +|7 |*TPCF* |❌ MISSING |0/10 |No Tri-Perimeter framework + +|8 |*Dependencies* |✅ GOOD |8/10 |Zero external deps (GNAT stdlib only) + +|9 |*Licensing* |⚠️ PARTIAL |5/10 |MIT only, no Palimpsest option + +|10 |*Formal Verification* |⚠️ READY |7/10 |SPARK-ready, not yet proven + +|11 |*Security Features* |✅ EXCELLENT |9/10 |SDP, port rotation, +obfuscation, zero-trust +|=== + +*Overall Score*: *64/110 (58%)* → Bronze Tier *Target Score*: *85/110 +(77%)* → Silver Tier + +''''' + +=== Detailed Category Analysis + +==== 1. Type Safety ✅ (10/10) + +*Strengths:* - Ada 2012 with full compile-time type checking - +Range-constrained types prevent invalid states: +`+ada type Latitude_Degrees is delta 0.000001 range -90.0 .. 90.0; type TTL_Seconds is range 0 .. 2_147_483_647;+` +- Bounded strings prevent buffer overflows - Enum types for state +machines (no magic numbers) + +*RSR Requirements Met:* - [x] Strong static typing - [x] No implicit +conversions - [x] Compile-time bounds checking - [x] No runtime type +errors + +*Evidence*: `+src/dns_records.ads+`, `+src/dns_records_extended.ads+` + +''''' + +==== 2. Memory Safety ✅ (10/10) + +*Strengths:* - Ada ownership model (no double-free, use-after-free) - No +`+unsafe+` blocks anywhere in codebase - Stack checking enabled: +`+-fstack-check+` - Validity checking: `+-gnatVa+` - Overflow checking: +`+-gnato+` (ALWAYS enabled, even in release) + +*RSR Requirements Met:* - [x] No buffer overflows - [x] No +use-after-free - [x] No data races (Ada protected types) - [x] No null +pointer dereferences + +*Evidence*: `+hinfo_loc_fluctuator.gpr+` (lines 16-25), `+src/*.adb+` + +''''' + +==== 3. Documentation ⚠️ (5/10) + +*Strengths:* - ✅ README.md (comprehensive, 450+ lines) - ✅ CLAUDE.md +(project context for AI sessions) - ✅ USE_CASES.md (6 detailed +scenarios) - ✅ ENTERPRISE_FEATURES.md (350+ lines) - ✅ +PROJECT_SUMMARY.md (transformation history) + +*Gaps:* - ❌ SECURITY.md (vulnerability reporting) - ❌ CONTRIBUTING.md +(contribution guidelines) - ❌ CODE_OF_CONDUCT.md (community standards) +- ❌ MAINTAINERS.md (project governance) - ❌ CHANGELOG.md (version +history) + +*Action Required*: Create missing governance documents + +''''' + +==== 4. .well-known/ Directory ❌ (0/10) + +*Gaps:* - ❌ `+security.txt+` (RFC 9116) - security contact, PGP keys - +❌ `+ai.txt+` - AI training policies - ❌ `+humans.txt+` - attribution, +credits + +*Action Required*: Create `+.well-known/+` directory with all three +files + +''''' + +==== 5. Build System ⚠️ (6/10) + +*Strengths:* - ✅ GNAT project file (`+hinfo_loc_fluctuator.gpr+`) - ✅ +Makefile with multiple targets (debug, release, prove) - ✅ Security +flags always enabled + +*Gaps:* - ❌ `+justfile+` (modern build automation) - ❌ `+flake.nix+` +(Nix reproducible builds) - ❌ CI/CD pipeline (.gitlab-ci.yml or +.github/workflows) + +*Action Required*: Add Justfile and Nix flake + +''''' + +==== 6. Testing ⚠️ (4/10) + +*Strengths:* - Code structured for testability - SPARK verification +mentioned + +*Gaps:* - ❌ No unit tests (0 test files) - ❌ No integration tests - ❌ +No RSR self-verification - ❌ No test coverage metrics + +*Action Required*: Add unit tests and RSR compliance checker + +''''' + +==== 7. TPCF (Tri-Perimeter Contribution Framework) ❌ (0/10) + +*Gaps:* - ❌ No perimeter definitions - ❌ No graduated access model - +❌ No contribution tiers + +*Recommendation*: Start with *Perimeter 3 (Community Sandbox)* - fully +open + +*Action Required*: Create TPCF.md defining perimeters + +''''' + +==== 8. Dependencies ✅ (8/10) + +*Strengths:* - Zero external dependencies - Only uses GNAT Ada runtime +(standard library) - No package manager dependencies - Offline-capable +(mostly) + +*Minor Gaps:* - Some modules assume network access (DNS UPDATE, firewall +commands) - Could be fully offline with mock implementations + +*RSR Alignment*: Strong (minimal dependencies = good) + +''''' + +==== 9. Licensing ⚠️ (5/10) + +*Current State:* - ✅ MIT License (permissive) - ✅ Clear license file + +*Gaps:* - ❌ No Palimpsest v0.8 dual licensing option - ❌ No +contributor license agreement + +*Action Required*: Add Palimpsest as alternative license + +''''' + +==== 10. Formal Verification ⚠️ (7/10) + +*Strengths:* - SPARK-ready codebase (mentioned in docs) - +Security-critical modules identified - Prove mode in build system + +*Gaps:* - ❌ No actual SPARK annotations - ❌ No verified contracts - ❌ +No proof obligations satisfied + +*Potential*: HIGH (Ada/SPARK is ideal for formal verification) + +*Action Required*: Add SPARK contracts to `+secure_auth.ads+`, +`+sdp_controller.ads+` + +''''' + +==== 11. Security Features ✅ (9/10) + +*Strengths:* - ✅ Zero-Trust SDP (NIST SP 800-207) - ✅ Port rotation +with time-based algorithm - ✅ Security header obfuscation - ✅ +Diagnostic mode (authorized-only access) - ✅ Constant-time password +comparison - ✅ Session timeout and replay protection - ✅ +NETCONF/RESTCONF over SNMP - ✅ Multi-factor authentication support + +*Minor Gap:* - ⚠️ Demo credentials (must be replaced for production) + +*RSR Alignment*: Exceptional (exceeds typical requirements) + +''''' + +=== Compliance Tier Definitions + +==== Bronze Tier (50-69%) + +*Requirements:* - Basic documentation (README) - Type/memory safety - +Open source license - Build system + +*Current*: 58% ✅ + +==== Silver Tier (70-84%) + +*Additional Requirements:* - Governance docs (SECURITY, CONTRIBUTING, +CODE_OF_CONDUCT) - .well-known/ directory - TPCF framework - Basic +testing + +*Target*: 77% (achievable) + +==== Gold Tier (85-100%) + +*Additional Requirements:* - Formal verification - 100% test coverage - +CI/CD pipeline - Nix reproducibility - RSR self-verification + +*Future Goal*: 90%+ + +''''' + +=== Implementation Roadmap + +==== Phase 1: Silver Tier Upgrade (Priority 1) ⏱️ 2-4 hours + +*Tasks:* 1. ✅ Create RSR_COMPLIANCE.md (this file) 2. Create +SECURITY.md (vulnerability reporting) 3. Create CONTRIBUTING.md +(contribution guide) 4. Create CODE_OF_CONDUCT.md (Contributor Covenant) +5. Create MAINTAINERS.md (governance structure) 6. Create CHANGELOG.md +(version history) 7. Create `+.well-known/security.txt+` (RFC 9116) 8. +Create `+.well-known/ai.txt+` (AI policies) 9. Create +`+.well-known/humans.txt+` (attribution) 10. Create TPCF.md (Perimeter 3 +- Community Sandbox) 11. Add Palimpsest v0.8 to LICENSE 12. Create +`+justfile+` (build automation) + +*Expected Score After Phase 1*: 85/110 (77%) → *Silver Tier* + +==== Phase 2: Gold Tier Preparation (Priority 2) ⏱️ 1-2 weeks + +*Tasks:* 1. Add unit tests (target: 70%+ coverage) 2. Create RSR +self-verification script 3. Add `+flake.nix+` (Nix reproducible builds) +4. Add CI/CD pipeline (.gitlab-ci.yml) 5. SPARK annotations on +security-critical modules 6. Integration testing with mock DNS server + +*Expected Score After Phase 2*: 95/110 (86%) → *Gold Tier* + +==== Phase 3: Platinum Excellence (Priority 3) ⏱️ Ongoing + +*Tasks:* 1. 100% test coverage 2. Full SPARK formal verification 3. +Security audit 4. Performance benchmarks 5. Multi-architecture CI +(x86_64, ARM64, RISC-V) + +''''' + +=== Quick Wins (Immediate Actions) + +These can be done in *under 30 minutes* and boost score significantly: + +[arabic] +. *+5 points*: Create `+.well-known/+` directory (10 min) +. *+8 points*: Create SECURITY.md (5 min) +. *+4 points*: Create CODE_OF_CONDUCT.md (2 min - use Contributor +Covenant template) +. *+3 points*: Create CONTRIBUTING.md (10 min) +. *+3 points*: Create CHANGELOG.md (5 min) + +*Total Quick Win Impact*: +23 points → *64 to 87* (79%) → *Silver Tier* + +''''' + +=== Compliance Verification Checklist + +Run this checklist after Phase 1: + +[source,bash] +---- +# Documentation +[ ] README.md exists and is comprehensive +[ ] SECURITY.md exists with contact info +[ ] CONTRIBUTING.md exists with guidelines +[ ] CODE_OF_CONDUCT.md exists (Contributor Covenant) +[ ] MAINTAINERS.md exists with governance +[ ] CHANGELOG.md exists with version history +[ ] LICENSE includes MIT + Palimpsest v0.8 + +# .well-known/ +[ ] .well-known/security.txt (RFC 9116 compliant) +[ ] .well-known/ai.txt (AI training policies) +[ ] .well-known/humans.txt (attribution) + +# Build System +[ ] Justfile with 10+ recipes +[ ] Makefile exists +[ ] GNAT project file exists +[ ] All security flags enabled + +# TPCF +[ ] TPCF.md defines perimeters +[ ] Perimeter 3 (Community Sandbox) documented + +# Testing +[ ] Unit tests exist (even if minimal) +[ ] RSR self-verification script + +# Type/Memory Safety +[ ] No unsafe blocks +[ ] Compile-time type checking +[ ] Overflow checking always on +[ ] Stack checking enabled +---- + +''''' + +=== References + +* *RSR Framework*: rhodium-minimal example repository +* *TPCF*: Tri-Perimeter Contribution Framework (Perimeters 1-3) +* *Palimpsest License*: v0.8 (dual licensing with MIT) +* *RFC 9116*: security.txt standard +* *NIST SP 800-207*: Zero Trust Architecture +* *Ada 2012*: ISO/IEC 8652:2012 +* *SPARK*: High Integrity Software + +''''' + +=== Conclusion + +The HINFO-LOC Fluctuator has *exceptional technical foundations* (type +safety, memory safety, security features) but lacks *governance and +community documentation* required for Silver Tier RSR compliance. + +*Immediate Action*: Implement Phase 1 (Silver Tier Upgrade) to reach +*77% compliance* within 2-4 hours. + +*Long-term Vision*: Gold Tier (86%+) with formal verification and +comprehensive testing. + +''''' + +*Next Steps*: See implementation tasks tracked in todo list. diff --git a/RSR_COMPLIANCE.md b/RSR_COMPLIANCE.md deleted file mode 100644 index 5f59201..0000000 --- a/RSR_COMPLIANCE.md +++ /dev/null @@ -1,378 +0,0 @@ -# RSR Compliance Assessment - -**Project**: HINFO-LOC Fluctuator -**Assessment Date**: 2025-11-22 -**RSR Framework Version**: 1.0 (Rhodium Standard Repository) -**Target Tier**: Bronze → Silver → Gold - ---- - -## Executive Summary - -**Current Compliance Level**: **Bronze (Partial)** → Upgrading to **Silver** - -The HINFO-LOC Fluctuator demonstrates strong foundational security and type safety through Ada 2012, but lacks critical RSR governance and community documentation. This assessment identifies gaps and provides an implementation roadmap. - ---- - -## RSR 11-Category Compliance Matrix - -| # | Category | Status | Score | Notes | -|---|----------|--------|-------|-------| -| 1 | **Type Safety** | ✅ COMPLETE | 10/10 | Ada 2012 compile-time type checking, range constraints | -| 2 | **Memory Safety** | ✅ COMPLETE | 10/10 | No buffer overflows, ownership model, zero `unsafe` | -| 3 | **Documentation** | ⚠️ PARTIAL | 5/10 | README exists, missing governance docs | -| 4 | **.well-known/** | ❌ MISSING | 0/10 | No security.txt, ai.txt, humans.txt | -| 5 | **Build System** | ⚠️ PARTIAL | 6/10 | GNAT+Makefile, no Justfile/Nix | -| 6 | **Testing** | ⚠️ PARTIAL | 4/10 | No unit tests, no RSR self-verification | -| 7 | **TPCF** | ❌ MISSING | 0/10 | No Tri-Perimeter framework | -| 8 | **Dependencies** | ✅ GOOD | 8/10 | Zero external deps (GNAT stdlib only) | -| 9 | **Licensing** | ⚠️ PARTIAL | 5/10 | MIT only, no Palimpsest option | -| 10 | **Formal Verification** | ⚠️ READY | 7/10 | SPARK-ready, not yet proven | -| 11 | **Security Features** | ✅ EXCELLENT | 9/10 | SDP, port rotation, obfuscation, zero-trust | - -**Overall Score**: **64/110 (58%)** → Bronze Tier -**Target Score**: **85/110 (77%)** → Silver Tier - ---- - -## Detailed Category Analysis - -### 1. Type Safety ✅ (10/10) - -**Strengths:** -- Ada 2012 with full compile-time type checking -- Range-constrained types prevent invalid states: - ```ada - type Latitude_Degrees is delta 0.000001 range -90.0 .. 90.0; - type TTL_Seconds is range 0 .. 2_147_483_647; - ``` -- Bounded strings prevent buffer overflows -- Enum types for state machines (no magic numbers) - -**RSR Requirements Met:** -- [x] Strong static typing -- [x] No implicit conversions -- [x] Compile-time bounds checking -- [x] No runtime type errors - -**Evidence**: `src/dns_records.ads`, `src/dns_records_extended.ads` - ---- - -### 2. Memory Safety ✅ (10/10) - -**Strengths:** -- Ada ownership model (no double-free, use-after-free) -- No `unsafe` blocks anywhere in codebase -- Stack checking enabled: `-fstack-check` -- Validity checking: `-gnatVa` -- Overflow checking: `-gnato` (ALWAYS enabled, even in release) - -**RSR Requirements Met:** -- [x] No buffer overflows -- [x] No use-after-free -- [x] No data races (Ada protected types) -- [x] No null pointer dereferences - -**Evidence**: `hinfo_loc_fluctuator.gpr` (lines 16-25), `src/*.adb` - ---- - -### 3. Documentation ⚠️ (5/10) - -**Strengths:** -- ✅ README.md (comprehensive, 450+ lines) -- ✅ CLAUDE.md (project context for AI sessions) -- ✅ USE_CASES.md (6 detailed scenarios) -- ✅ ENTERPRISE_FEATURES.md (350+ lines) -- ✅ PROJECT_SUMMARY.md (transformation history) - -**Gaps:** -- ❌ SECURITY.md (vulnerability reporting) -- ❌ CONTRIBUTING.md (contribution guidelines) -- ❌ CODE_OF_CONDUCT.md (community standards) -- ❌ MAINTAINERS.md (project governance) -- ❌ CHANGELOG.md (version history) - -**Action Required**: Create missing governance documents - ---- - -### 4. .well-known/ Directory ❌ (0/10) - -**Gaps:** -- ❌ `security.txt` (RFC 9116) - security contact, PGP keys -- ❌ `ai.txt` - AI training policies -- ❌ `humans.txt` - attribution, credits - -**Action Required**: Create `.well-known/` directory with all three files - ---- - -### 5. Build System ⚠️ (6/10) - -**Strengths:** -- ✅ GNAT project file (`hinfo_loc_fluctuator.gpr`) -- ✅ Makefile with multiple targets (debug, release, prove) -- ✅ Security flags always enabled - -**Gaps:** -- ❌ `justfile` (modern build automation) -- ❌ `flake.nix` (Nix reproducible builds) -- ❌ CI/CD pipeline (.gitlab-ci.yml or .github/workflows) - -**Action Required**: Add Justfile and Nix flake - ---- - -### 6. Testing ⚠️ (4/10) - -**Strengths:** -- Code structured for testability -- SPARK verification mentioned - -**Gaps:** -- ❌ No unit tests (0 test files) -- ❌ No integration tests -- ❌ No RSR self-verification -- ❌ No test coverage metrics - -**Action Required**: Add unit tests and RSR compliance checker - ---- - -### 7. TPCF (Tri-Perimeter Contribution Framework) ❌ (0/10) - -**Gaps:** -- ❌ No perimeter definitions -- ❌ No graduated access model -- ❌ No contribution tiers - -**Recommendation**: Start with **Perimeter 3 (Community Sandbox)** - fully open - -**Action Required**: Create TPCF.md defining perimeters - ---- - -### 8. Dependencies ✅ (8/10) - -**Strengths:** -- Zero external dependencies -- Only uses GNAT Ada runtime (standard library) -- No package manager dependencies -- Offline-capable (mostly) - -**Minor Gaps:** -- Some modules assume network access (DNS UPDATE, firewall commands) -- Could be fully offline with mock implementations - -**RSR Alignment**: Strong (minimal dependencies = good) - ---- - -### 9. Licensing ⚠️ (5/10) - -**Current State:** -- ✅ MIT License (permissive) -- ✅ Clear license file - -**Gaps:** -- ❌ No Palimpsest v0.8 dual licensing option -- ❌ No contributor license agreement - -**Action Required**: Add Palimpsest as alternative license - ---- - -### 10. Formal Verification ⚠️ (7/10) - -**Strengths:** -- SPARK-ready codebase (mentioned in docs) -- Security-critical modules identified -- Prove mode in build system - -**Gaps:** -- ❌ No actual SPARK annotations -- ❌ No verified contracts -- ❌ No proof obligations satisfied - -**Potential**: HIGH (Ada/SPARK is ideal for formal verification) - -**Action Required**: Add SPARK contracts to `secure_auth.ads`, `sdp_controller.ads` - ---- - -### 11. Security Features ✅ (9/10) - -**Strengths:** -- ✅ Zero-Trust SDP (NIST SP 800-207) -- ✅ Port rotation with time-based algorithm -- ✅ Security header obfuscation -- ✅ Diagnostic mode (authorized-only access) -- ✅ Constant-time password comparison -- ✅ Session timeout and replay protection -- ✅ NETCONF/RESTCONF over SNMP -- ✅ Multi-factor authentication support - -**Minor Gap:** -- ⚠️ Demo credentials (must be replaced for production) - -**RSR Alignment**: Exceptional (exceeds typical requirements) - ---- - -## Compliance Tier Definitions - -### Bronze Tier (50-69%) -**Requirements:** -- Basic documentation (README) -- Type/memory safety -- Open source license -- Build system - -**Current**: 58% ✅ - -### Silver Tier (70-84%) -**Additional Requirements:** -- Governance docs (SECURITY, CONTRIBUTING, CODE_OF_CONDUCT) -- .well-known/ directory -- TPCF framework -- Basic testing - -**Target**: 77% (achievable) - -### Gold Tier (85-100%) -**Additional Requirements:** -- Formal verification -- 100% test coverage -- CI/CD pipeline -- Nix reproducibility -- RSR self-verification - -**Future Goal**: 90%+ - ---- - -## Implementation Roadmap - -### Phase 1: Silver Tier Upgrade (Priority 1) ⏱️ 2-4 hours - -**Tasks:** -1. ✅ Create RSR_COMPLIANCE.md (this file) -2. Create SECURITY.md (vulnerability reporting) -3. Create CONTRIBUTING.md (contribution guide) -4. Create CODE_OF_CONDUCT.md (Contributor Covenant) -5. Create MAINTAINERS.md (governance structure) -6. Create CHANGELOG.md (version history) -7. Create `.well-known/security.txt` (RFC 9116) -8. Create `.well-known/ai.txt` (AI policies) -9. Create `.well-known/humans.txt` (attribution) -10. Create TPCF.md (Perimeter 3 - Community Sandbox) -11. Add Palimpsest v0.8 to LICENSE -12. Create `justfile` (build automation) - -**Expected Score After Phase 1**: 85/110 (77%) → **Silver Tier** - -### Phase 2: Gold Tier Preparation (Priority 2) ⏱️ 1-2 weeks - -**Tasks:** -1. Add unit tests (target: 70%+ coverage) -2. Create RSR self-verification script -3. Add `flake.nix` (Nix reproducible builds) -4. Add CI/CD pipeline (.gitlab-ci.yml) -5. SPARK annotations on security-critical modules -6. Integration testing with mock DNS server - -**Expected Score After Phase 2**: 95/110 (86%) → **Gold Tier** - -### Phase 3: Platinum Excellence (Priority 3) ⏱️ Ongoing - -**Tasks:** -1. 100% test coverage -2. Full SPARK formal verification -3. Security audit -4. Performance benchmarks -5. Multi-architecture CI (x86_64, ARM64, RISC-V) - ---- - -## Quick Wins (Immediate Actions) - -These can be done in **under 30 minutes** and boost score significantly: - -1. **+5 points**: Create `.well-known/` directory (10 min) -2. **+8 points**: Create SECURITY.md (5 min) -3. **+4 points**: Create CODE_OF_CONDUCT.md (2 min - use Contributor Covenant template) -4. **+3 points**: Create CONTRIBUTING.md (10 min) -5. **+3 points**: Create CHANGELOG.md (5 min) - -**Total Quick Win Impact**: +23 points → **64 to 87** (79%) → **Silver Tier** - ---- - -## Compliance Verification Checklist - -Run this checklist after Phase 1: - -```bash -# Documentation -[ ] README.md exists and is comprehensive -[ ] SECURITY.md exists with contact info -[ ] CONTRIBUTING.md exists with guidelines -[ ] CODE_OF_CONDUCT.md exists (Contributor Covenant) -[ ] MAINTAINERS.md exists with governance -[ ] CHANGELOG.md exists with version history -[ ] LICENSE includes MIT + Palimpsest v0.8 - -# .well-known/ -[ ] .well-known/security.txt (RFC 9116 compliant) -[ ] .well-known/ai.txt (AI training policies) -[ ] .well-known/humans.txt (attribution) - -# Build System -[ ] Justfile with 10+ recipes -[ ] Makefile exists -[ ] GNAT project file exists -[ ] All security flags enabled - -# TPCF -[ ] TPCF.md defines perimeters -[ ] Perimeter 3 (Community Sandbox) documented - -# Testing -[ ] Unit tests exist (even if minimal) -[ ] RSR self-verification script - -# Type/Memory Safety -[ ] No unsafe blocks -[ ] Compile-time type checking -[ ] Overflow checking always on -[ ] Stack checking enabled -``` - ---- - -## References - -- **RSR Framework**: rhodium-minimal example repository -- **TPCF**: Tri-Perimeter Contribution Framework (Perimeters 1-3) -- **Palimpsest License**: v0.8 (dual licensing with MIT) -- **RFC 9116**: security.txt standard -- **NIST SP 800-207**: Zero Trust Architecture -- **Ada 2012**: ISO/IEC 8652:2012 -- **SPARK**: High Integrity Software - ---- - -## Conclusion - -The HINFO-LOC Fluctuator has **exceptional technical foundations** (type safety, memory safety, security features) but lacks **governance and community documentation** required for Silver Tier RSR compliance. - -**Immediate Action**: Implement Phase 1 (Silver Tier Upgrade) to reach **77% compliance** within 2-4 hours. - -**Long-term Vision**: Gold Tier (86%+) with formal verification and comprehensive testing. - ---- - -**Next Steps**: See implementation tasks tracked in todo list. diff --git a/SECURITY.adoc b/SECURITY.adoc new file mode 100644 index 0000000..19ff8a1 --- /dev/null +++ b/SECURITY.adoc @@ -0,0 +1,307 @@ +== Security Policy + +=== Supported Versions + +We currently support the following versions with security updates: + +[width="99%",cols="24%,60%,16%",options="header",] +|=== +|Version |Supported |Notes +|2.x.x |:white_check_mark: |Current development (enterprise features) +|1.x.x |:white_check_mark: |Basic HINFO/LOC fluctuation +|< 1.0 |:x: |Prototype/experimental only +|=== + +=== Reporting a Vulnerability + +*DO NOT* open public GitHub issues for security vulnerabilities. + +==== Preferred Reporting Methods + +[arabic] +. *GitHub Security Advisories* (Recommended) +* Navigate to +https://github.com/Hyperpolymath/resource-record-fluctuator/security/advisories/new +* Provides private communication channel +* Supports CVE assignment +. *Email* +* Send to: security@example.com (replace with actual contact) +* Include "`HINFO-LOC SECURITY`" in subject line +* PGP key: https://github.com/Hyperpolymath.gpg (if available) +. *security.txt* +* See `+.well-known/security.txt+` for canonical contact information +* Compliant with RFC 9116 + +==== What to Include + +Please provide: + +* *Description*: What is the vulnerability? +* *Impact*: What can an attacker do? +* *Affected Component*: Which module/file? +* *Reproduction*: Steps to reproduce +* *Proposed Fix*: If you have one (optional) +* *CVE Request*: Do you want a CVE assigned? + +==== Response Timeline + +We aim to: + +* *Acknowledge* your report within *48 hours* +* *Confirm* the vulnerability within *7 days* +* *Develop a fix* within *14-30 days* (depending on severity) +* *Publish advisory* after fix is deployed or 90 days (whichever is +sooner) + +==== Severity Levels + +[width="99%",cols="30%,42%,28%",options="header",] +|=== +|Severity |Response Time |Examples +|*Critical* |24 hours |Remote code execution, privilege escalation +|*High* |7 days |Authentication bypass, data exfiltration +|*Medium* |14 days |DoS, information disclosure +|*Low* |30 days |Minor issues, hardening opportunities +|=== + +=== Security Features + +This project implements multiple layers of security: + +==== 1. Type Safety (Ada 2012) + +*Protection Against:* - Buffer overflows - Integer overflows - Type +confusion - Null pointer dereferences + +*Implementation:* + +[source,ada] +---- +type Latitude_Degrees is delta 0.000001 range -90.0 .. 90.0; +type TTL_Seconds is range 0 .. 2_147_483_647; +---- + +*Compiler Flags (Always On):* - `+-gnato+`: Overflow checking - +`+-fstack-check+`: Stack overflow protection - `+-gnatVa+`: Validity +checking - `+-gnatwe+`: Warnings as errors + +==== 2. Memory Safety + +*Protection Against:* - Use-after-free - Double-free - Memory leaks - +Data races + +*Implementation:* - Ada ownership model (no manual memory management) - +Protected types for thread-safe access - Zero `+unsafe+` blocks in +entire codebase + +==== 3. Authentication & Authorization + +*Module*: `+secure_auth.ads/adb+` + +*Features:* - Permission levels (None, Read-Only, Modify-Local, +Modify-Remote, Admin) - Session timeout (30 minutes default) - +Constant-time password comparison (timing attack prevention) - Replay +attack detection (nonce-based) + +*⚠️ WARNING*: Demo credentials exist for development. *MUST* be changed +before deployment. + +==== 4. Zero-Trust Architecture + +*Module*: `+sdp_controller.ads/adb+` + +*Features:* - Software-Defined Perimeter (SDP) - Single Packet +Authorization (SPA) - Continuous verification - Device posture +validation - Multi-factor authentication support + +*Standards:* - NIST SP 800-207 (Zero Trust Architecture) - CSA SDP +Specification v2.0 + +==== 5. Firewall Integration + +*Module*: `+firewall_manager.ads/adb+` + +*Features:* - Dynamic port rotation (SSH, services) - Time-based +maintenance windows - CIDR-based access control (APL records) - +Emergency lockdown/recovery modes + +==== 6. Security Headers + +*Module*: `+security_headers.ads/adb+` + +*Features:* - Server header obfuscation - Diagnostic mode (authorized +IPs only) - HSTS, CSP, X-Frame-Options - COEP, COOP, CORP (experimental +headers) + +==== 7. Protocol Security + +*Module*: `+protocol_manager.ads/adb+` + +*Features:* - SNMP v1/v2c *DISABLED* by default (insecure) - +NETCONF/RESTCONF/gNMI recommended over SNMP - TLS required for all +management protocols - Security validation and warnings + +=== Known Security Limitations + +==== Demo Credentials + +*Risk*: HIGH *Status*: DOCUMENTED + +The codebase includes demo credentials for development/testing: + +[source,ada] +---- +-- src/secure_auth.adb +-- ⚠️ DEMO CREDENTIALS - CHANGE BEFORE DEPLOYMENT +---- + +*Mitigation*: Clearly documented in README, CLAUDE.md, and inline +comments. + +*Action Required*: Replace with bcrypt/Argon2 hashed passwords before +production. + +==== No Real Cryptography (Yet) + +*Risk*: MEDIUM *Status*: PLANNED + +Currently missing: + +* bcrypt/Argon2 password hashing +* TSIG authentication (RFC 2845) - needs crypto library +* SPA packet encryption (needs AES-256-GCM, ChaCha20-Poly1305) + +*Mitigation*: Framework is ready, needs crypto library integration. + +*Timeline*: Phase 2 (Gold Tier) + +==== DNS Server Integration Untested + +*Risk*: MEDIUM *Status*: FRAMEWORK COMPLETE + +DNS UPDATE (RFC 2136) framework is implemented but not tested with real +servers. + +*Mitigation*: Extensive logging, firewall rules only logged (not +executed) by default. + +*Action Required*: Integration testing with BIND/PowerDNS/NSD. + +=== Security Audit Status + +[cols=",,,",options="header",] +|=== +|Audit Type |Status |Last Audit |Next Audit +|*Code Review* |✅ Ongoing |2025-11-22 |Continuous +|*SPARK Verification* |🔄 Planned |N/A |2026 Q1 +|*Penetration Test* |❌ Not Yet |N/A |After v2.0 +|*Dependency Audit* |✅ Clean |2025-11-22 |Quarterly +|=== + +*Dependencies*: ZERO external dependencies (GNAT stdlib only) + +=== Secure Development Practices + +==== Build Security + +[arabic] +. *Always-On Safety Checks* ++ +.... +-gnato # Overflow checking +-fstack-check # Stack protection +-gnatVa # Validity checking +.... +. *Security Flags in Release* +* Assertions enabled even in release builds +* No unsafe optimizations + +==== Code Review + +* All changes reviewed before merge +* Security-critical modules flagged for extra scrutiny +* SPARK verification planned for auth/SDP modules + +==== Testing + +* Unit tests (planned) +* Integration tests (planned) +* Fuzz testing (planned for DNS packet parsing) + +=== Security Hall of Fame + +We recognize security researchers who responsibly disclose +vulnerabilities: + +[cols=",,,,",options="header",] +|=== +|Date |Researcher |Vulnerability |Severity |Bounty +|TBD |TBD |TBD |TBD |TBD +|=== + +*Note*: We do not currently offer monetary bounties but provide public +credit and gratitude. + +=== Safe Harbor + +We consider security research conducted under this policy to be: + +* *Authorized* under applicable anti-hacking laws (CFAA, etc.) +* *Exempt* from DMCA Section 1201 restrictions +* *Lawful, helpful, and appreciated* + +We *will not* pursue legal action if you: + +* Follow responsible disclosure (report to us privately) +* Allow 90-day window for fix before public disclosure +* Do not access/exfiltrate user data +* Do not harm availability (no DoS attacks on production systems) + +=== Security Best Practices for Users + +If deploying this software: + +[arabic] +. *Change Demo Credentials* +* Replace all demo passwords +* Generate unique secrets for production +. *Enable SDP (Zero-Trust)* +* Use Software-Defined Perimeter for all access +* Require Multi-Factor Authentication +. *Disable Insecure Protocols* +* No SNMP v1/v2c +* Use NETCONF/RESTCONF/gNMI +. *Firewall Configuration* +* Enable port rotation for SSH +* Use time-based maintenance windows +* Restrict by CIDR (APL records) +. *Logging* +* Enable audit logging +* Enable security logging +* Monitor for anomalies +. *Keep Updated* +* Subscribe to security advisories +* Apply patches promptly +* Test updates in staging first + +=== Security Contact + +* *Primary*: +https://github.com/Hyperpolymath/resource-record-fluctuator/security/advisories/new +* *Email*: security@example.com +* *PGP*: https://github.com/Hyperpolymath.gpg +* *security.txt*: `+.well-known/security.txt+` (RFC 9116) + +=== References + +* *NIST SP 800-207*: Zero Trust Architecture +* *CSA SDP Specification v2.0*: Software-Defined Perimeter +* *RFC 2136*: DNS Dynamic Updates +* *RFC 2845*: TSIG (Transaction Signatures) +* *RFC 9116*: security.txt +* *Ada 2012*: ISO/IEC 8652:2012 +* *SPARK*: High Integrity Software + +''''' + +*Last Updated*: 2025-11-22 *Next Review*: 2026-05-22 (6 months) diff --git a/SECURITY.md b/SECURITY.md deleted file mode 100644 index 58a8176..0000000 --- a/SECURITY.md +++ /dev/null @@ -1,316 +0,0 @@ -# Security Policy - -## Supported Versions - -We currently support the following versions with security updates: - -| Version | Supported | Notes | -| ------- | ------------------ | ----- | -| 2.x.x | :white_check_mark: | Current development (enterprise features) | -| 1.x.x | :white_check_mark: | Basic HINFO/LOC fluctuation | -| < 1.0 | :x: | Prototype/experimental only | - -## Reporting a Vulnerability - -**DO NOT** open public GitHub issues for security vulnerabilities. - -### Preferred Reporting Methods - -1. **GitHub Security Advisories** (Recommended) - - Navigate to https://github.com/Hyperpolymath/resource-record-fluctuator/security/advisories/new - - Provides private communication channel - - Supports CVE assignment - -2. **Email** - - Send to: security@example.com (replace with actual contact) - - Include "HINFO-LOC SECURITY" in subject line - - PGP key: https://github.com/Hyperpolymath.gpg (if available) - -3. **security.txt** - - See `.well-known/security.txt` for canonical contact information - - Compliant with RFC 9116 - -### What to Include - -Please provide: - -- **Description**: What is the vulnerability? -- **Impact**: What can an attacker do? -- **Affected Component**: Which module/file? -- **Reproduction**: Steps to reproduce -- **Proposed Fix**: If you have one (optional) -- **CVE Request**: Do you want a CVE assigned? - -### Response Timeline - -We aim to: - -- **Acknowledge** your report within **48 hours** -- **Confirm** the vulnerability within **7 days** -- **Develop a fix** within **14-30 days** (depending on severity) -- **Publish advisory** after fix is deployed or 90 days (whichever is sooner) - -### Severity Levels - -| Severity | Response Time | Examples | -|----------|---------------|----------| -| **Critical** | 24 hours | Remote code execution, privilege escalation | -| **High** | 7 days | Authentication bypass, data exfiltration | -| **Medium** | 14 days | DoS, information disclosure | -| **Low** | 30 days | Minor issues, hardening opportunities | - -## Security Features - -This project implements multiple layers of security: - -### 1. Type Safety (Ada 2012) - -**Protection Against:** -- Buffer overflows -- Integer overflows -- Type confusion -- Null pointer dereferences - -**Implementation:** -```ada -type Latitude_Degrees is delta 0.000001 range -90.0 .. 90.0; -type TTL_Seconds is range 0 .. 2_147_483_647; -``` - -**Compiler Flags (Always On):** -- `-gnato`: Overflow checking -- `-fstack-check`: Stack overflow protection -- `-gnatVa`: Validity checking -- `-gnatwe`: Warnings as errors - -### 2. Memory Safety - -**Protection Against:** -- Use-after-free -- Double-free -- Memory leaks -- Data races - -**Implementation:** -- Ada ownership model (no manual memory management) -- Protected types for thread-safe access -- Zero `unsafe` blocks in entire codebase - -### 3. Authentication & Authorization - -**Module**: `secure_auth.ads/adb` - -**Features:** -- Permission levels (None, Read-Only, Modify-Local, Modify-Remote, Admin) -- Session timeout (30 minutes default) -- Constant-time password comparison (timing attack prevention) -- Replay attack detection (nonce-based) - -**⚠️ WARNING**: Demo credentials exist for development. **MUST** be changed before deployment. - -### 4. Zero-Trust Architecture - -**Module**: `sdp_controller.ads/adb` - -**Features:** -- Software-Defined Perimeter (SDP) -- Single Packet Authorization (SPA) -- Continuous verification -- Device posture validation -- Multi-factor authentication support - -**Standards:** -- NIST SP 800-207 (Zero Trust Architecture) -- CSA SDP Specification v2.0 - -### 5. Firewall Integration - -**Module**: `firewall_manager.ads/adb` - -**Features:** -- Dynamic port rotation (SSH, services) -- Time-based maintenance windows -- CIDR-based access control (APL records) -- Emergency lockdown/recovery modes - -### 6. Security Headers - -**Module**: `security_headers.ads/adb` - -**Features:** -- Server header obfuscation -- Diagnostic mode (authorized IPs only) -- HSTS, CSP, X-Frame-Options -- COEP, COOP, CORP (experimental headers) - -### 7. Protocol Security - -**Module**: `protocol_manager.ads/adb` - -**Features:** -- SNMP v1/v2c **DISABLED** by default (insecure) -- NETCONF/RESTCONF/gNMI recommended over SNMP -- TLS required for all management protocols -- Security validation and warnings - -## Known Security Limitations - -### Demo Credentials - -**Risk**: HIGH -**Status**: DOCUMENTED - -The codebase includes demo credentials for development/testing: - -```ada --- src/secure_auth.adb --- ⚠️ DEMO CREDENTIALS - CHANGE BEFORE DEPLOYMENT -``` - -**Mitigation**: Clearly documented in README, CLAUDE.md, and inline comments. - -**Action Required**: Replace with bcrypt/Argon2 hashed passwords before production. - -### No Real Cryptography (Yet) - -**Risk**: MEDIUM -**Status**: PLANNED - -Currently missing: - -- bcrypt/Argon2 password hashing -- TSIG authentication (RFC 2845) - needs crypto library -- SPA packet encryption (needs AES-256-GCM, ChaCha20-Poly1305) - -**Mitigation**: Framework is ready, needs crypto library integration. - -**Timeline**: Phase 2 (Gold Tier) - -### DNS Server Integration Untested - -**Risk**: MEDIUM -**Status**: FRAMEWORK COMPLETE - -DNS UPDATE (RFC 2136) framework is implemented but not tested with real servers. - -**Mitigation**: Extensive logging, firewall rules only logged (not executed) by default. - -**Action Required**: Integration testing with BIND/PowerDNS/NSD. - -## Security Audit Status - -| Audit Type | Status | Last Audit | Next Audit | -|------------|--------|------------|------------| -| **Code Review** | ✅ Ongoing | 2025-11-22 | Continuous | -| **SPARK Verification** | 🔄 Planned | N/A | 2026 Q1 | -| **Penetration Test** | ❌ Not Yet | N/A | After v2.0 | -| **Dependency Audit** | ✅ Clean | 2025-11-22 | Quarterly | - -**Dependencies**: ZERO external dependencies (GNAT stdlib only) - -## Secure Development Practices - -### Build Security - -1. **Always-On Safety Checks** - ``` - -gnato # Overflow checking - -fstack-check # Stack protection - -gnatVa # Validity checking - ``` - -2. **Security Flags in Release** - - Assertions enabled even in release builds - - No unsafe optimizations - -### Code Review - -- All changes reviewed before merge -- Security-critical modules flagged for extra scrutiny -- SPARK verification planned for auth/SDP modules - -### Testing - -- Unit tests (planned) -- Integration tests (planned) -- Fuzz testing (planned for DNS packet parsing) - -## Security Hall of Fame - -We recognize security researchers who responsibly disclose vulnerabilities: - - - -| Date | Researcher | Vulnerability | Severity | Bounty | -|------|------------|---------------|----------|--------| -| TBD | TBD | TBD | TBD | TBD | - -**Note**: We do not currently offer monetary bounties but provide public credit and gratitude. - -## Safe Harbor - -We consider security research conducted under this policy to be: - -- **Authorized** under applicable anti-hacking laws (CFAA, etc.) -- **Exempt** from DMCA Section 1201 restrictions -- **Lawful, helpful, and appreciated** - -We **will not** pursue legal action if you: - -- Follow responsible disclosure (report to us privately) -- Allow 90-day window for fix before public disclosure -- Do not access/exfiltrate user data -- Do not harm availability (no DoS attacks on production systems) - -## Security Best Practices for Users - -If deploying this software: - -1. **Change Demo Credentials** - - Replace all demo passwords - - Generate unique secrets for production - -2. **Enable SDP (Zero-Trust)** - - Use Software-Defined Perimeter for all access - - Require Multi-Factor Authentication - -3. **Disable Insecure Protocols** - - No SNMP v1/v2c - - Use NETCONF/RESTCONF/gNMI - -4. **Firewall Configuration** - - Enable port rotation for SSH - - Use time-based maintenance windows - - Restrict by CIDR (APL records) - -5. **Logging** - - Enable audit logging - - Enable security logging - - Monitor for anomalies - -6. **Keep Updated** - - Subscribe to security advisories - - Apply patches promptly - - Test updates in staging first - -## Security Contact - -- **Primary**: https://github.com/Hyperpolymath/resource-record-fluctuator/security/advisories/new -- **Email**: security@example.com -- **PGP**: https://github.com/Hyperpolymath.gpg -- **security.txt**: `.well-known/security.txt` (RFC 9116) - -## References - -- **NIST SP 800-207**: Zero Trust Architecture -- **CSA SDP Specification v2.0**: Software-Defined Perimeter -- **RFC 2136**: DNS Dynamic Updates -- **RFC 2845**: TSIG (Transaction Signatures) -- **RFC 9116**: security.txt -- **Ada 2012**: ISO/IEC 8652:2012 -- **SPARK**: High Integrity Software - ---- - -**Last Updated**: 2025-11-22 -**Next Review**: 2026-05-22 (6 months) diff --git a/TEST-NEEDS.adoc b/TEST-NEEDS.adoc new file mode 100644 index 0000000..c810fa0 --- /dev/null +++ b/TEST-NEEDS.adoc @@ -0,0 +1,42 @@ +== TEST-NEEDS: resource-record-fluctuator + +=== CRG Grade: C — ACHIEVED 2026-04-04 + +=== Current State + +[cols=",,",options="header",] +|=== +|Category |Count |Details +|*Source modules* |1 |Elixir: dns_records.ex +|*Unit tests* |0 |None +|*Integration tests* |0 |None +|*E2E tests* |0 |None +|*Benchmarks* |0 |None +|*Fuzz tests* |0 |placeholder.txt only +|=== + +=== What’s Missing + +==== EVERYTHING + +* [ ] 1 source file, 0 tests of any kind +* [ ] No ExUnit test file +* [ ] No DNS record manipulation tests +* [ ] No tests for HINFO/LOC record fluctuation logic + +==== Aspect Tests + +* [ ] *Security*: DNS record manipulation with zero security tests – DNS +poisoning scenarios untested +* [ ] *Error handling*: No tests for malformed records, invalid DNS data + +==== Self-Tests + +* [ ] No self-diagnostic mode + +=== FLAGGED ISSUES + +* *1 Elixir source file, 0 tests* – completely untested +* *fuzz/placeholder.txt* – fake fuzz testing claim + +=== Priority: P1 (HIGH) diff --git a/TEST-NEEDS.md b/TEST-NEEDS.md deleted file mode 100644 index 1c22a6c..0000000 --- a/TEST-NEEDS.md +++ /dev/null @@ -1,35 +0,0 @@ -# TEST-NEEDS: resource-record-fluctuator - -## CRG Grade: C — ACHIEVED 2026-04-04 - -## Current State - -| Category | Count | Details | -|----------|-------|---------| -| **Source modules** | 1 | Elixir: dns_records.ex | -| **Unit tests** | 0 | None | -| **Integration tests** | 0 | None | -| **E2E tests** | 0 | None | -| **Benchmarks** | 0 | None | -| **Fuzz tests** | 0 | placeholder.txt only | - -## What's Missing - -### EVERYTHING -- [ ] 1 source file, 0 tests of any kind -- [ ] No ExUnit test file -- [ ] No DNS record manipulation tests -- [ ] No tests for HINFO/LOC record fluctuation logic - -### Aspect Tests -- [ ] **Security**: DNS record manipulation with zero security tests -- DNS poisoning scenarios untested -- [ ] **Error handling**: No tests for malformed records, invalid DNS data - -### Self-Tests -- [ ] No self-diagnostic mode - -## FLAGGED ISSUES -- **1 Elixir source file, 0 tests** -- completely untested -- **fuzz/placeholder.txt** -- fake fuzz testing claim - -## Priority: P1 (HIGH) diff --git a/TOPOLOGY.md b/TOPOLOGY.adoc similarity index 88% rename from TOPOLOGY.md rename to TOPOLOGY.adoc index ac070b4..9ff3c75 100644 --- a/TOPOLOGY.md +++ b/TOPOLOGY.adoc @@ -1,12 +1,8 @@ - - - +== [quantum (sic)] DNS Fluctuator — Project Topology -# [quantum (sic)] DNS Fluctuator — Project Topology +=== System Architecture -## System Architecture - -``` +.... ┌─────────────────────────────────────────┐ │ SECURITY ANALYST │ │ (TUI Interface / Admin CLI) │ @@ -41,11 +37,11 @@ │ Makefile Automation .machine_readable/ │ │ SPARK Verification 0-AI-MANIFEST.a2ml │ └─────────────────────────────────────────┘ -``` +.... -## Completion Dashboard +=== Completion Dashboard -``` +.... COMPONENT STATUS NOTES ───────────────────────────────── ────────────────── ───────────────────────────────── CORE FLUCTUATOR (ADA) @@ -67,25 +63,26 @@ REPO INFRASTRUCTURE ───────────────────────────────────────────────────────────────────────────── OVERALL: █████████░ ~90% Core stable, Proofs maturing -``` +.... -## Key Dependencies +=== Key Dependencies -``` +.... Type Spec (Ada) ───► Random Engine ────► Zone Generator ──► BIND Update │ │ │ │ ▼ ▼ ▼ ▼ Posture Valid ───► SDP Controller ───► Firewall Rule ──► Port Rotation -``` +.... -## Update Protocol +=== Update Protocol This file is maintained by both humans and AI agents. When updating: -1. **After completing a component**: Change its bar and percentage -2. **After adding a component**: Add a new row in the appropriate section -3. **After architectural changes**: Update the ASCII diagram -4. **Date**: Update the `Last updated` comment at the top of this file +[arabic] +. *After completing a component*: Change its bar and percentage +. *After adding a component*: Add a new row in the appropriate section +. *After architectural changes*: Update the ASCII diagram +. *Date*: Update the `+Last updated+` comment at the top of this file -Progress bars use: `█` (filled) and `░` (empty), 10 characters wide. -Percentages: 0%, 10%, 20%, ... 100% (in 10% increments). +Progress bars use: `+█+` (filled) and `+░+` (empty), 10 characters wide. +Percentages: 0%, 10%, 20%, … 100% (in 10% increments). diff --git a/TPCF.adoc b/TPCF.adoc new file mode 100644 index 0000000..f536832 --- /dev/null +++ b/TPCF.adoc @@ -0,0 +1,466 @@ +== Tri-Perimeter Contribution Framework (TPCF) + +*Project*: HINFO-LOC Fluctuator *Framework Version*: 1.0 *Last Updated*: +2025-11-22 + +''''' + +=== Overview + +The *Tri-Perimeter Contribution Framework* (TPCF) is a graduated trust +model that balances openness with security. It defines three concentric +perimeters of access, each with different responsibilities and +privileges. + +*Philosophy*: We welcome all contributors while protecting critical +infrastructure. Trust is earned through consistent, quality +contributions over time. + +''''' + +=== The Three Perimeters + +.... +┌────────────────────────────────────────────────────────┐ +│ Perimeter 3: Community Sandbox (Everyone) │ +│ ┌──────────────────────────────────────────────────┐ │ +│ │ Perimeter 2: Trusted Contributors │ │ +│ │ ┌────────────────────────────────────────────┐ │ │ +│ │ │ Perimeter 1: Core Maintainers │ │ │ +│ │ │ - Merge to main │ │ │ +│ │ │ - Create releases │ │ │ +│ │ │ - CI/CD configuration │ │ │ +│ │ └────────────────────────────────────────────┘ │ │ +│ │ - Formal review rights │ │ +│ │ - Issue triage │ │ +│ └──────────────────────────────────────────────────┘ │ +│ - Fork & PR │ +│ - Informal reviews │ +│ - Bug reports │ +└────────────────────────────────────────────────────────┘ +.... + +''''' + +=== Perimeter 3: Community Sandbox + +*Who*: Everyone (you!) + +*No Approval Needed*: Just start contributing! + +==== Access Rights + +* ✅ Fork the repository +* ✅ Submit pull requests +* ✅ Comment on issues and PRs +* ✅ Review others’ code (informal feedback) +* ✅ Report bugs +* ✅ Suggest features +* ✅ Participate in discussions + +==== Restrictions + +* ❌ Cannot merge to main branch +* ❌ Cannot create releases +* ❌ Cannot modify CI/CD configuration +* ❌ Cannot access project credentials + +==== Responsibilities + +* *Quality*: Submit well-tested, documented code +* *Code of Conduct*: Follow community guidelines +* *Security*: Report vulnerabilities responsibly (see SECURITY.md) +* *Communication*: Be respectful and constructive + +==== Typical Activities + +* Fix bugs +* Add features +* Improve documentation +* Write tests +* Help other contributors +* Translate documentation (future) + +*Time Commitment*: None! Contribute when you can. + +''''' + +=== Perimeter 2: Trusted Contributors + +*Who*: Regular contributors with proven track record + +*How to Join*: Nominated by Perimeter 1 after meeting requirements + +==== Requirements + +[arabic] +. *5+ merged pull requests* of good quality +. *Demonstrated understanding* of project goals and architecture +. *Consistent code quality* (type safety, memory safety, security) +. *Active participation* in code reviews (informal) +. *Community positive behavior* (helpful, respectful) +. *Nomination* by a Perimeter 1 maintainer +. *Acceptance* by consensus of Perimeter 1 + +==== Access Rights + +*Everything in Perimeter 3, plus:* + +* ✅ *Formal review rights* (blocking pull requests) +* ✅ *Issue triage* (label, assign, close) +* ✅ *Priority access* for questions and guidance +* ✅ *Recognition* in project documentation +* ✅ *Input on roadmap* and technical direction + +==== Restrictions + +* ❌ Cannot merge to main (Perimeter 1 only) +* ❌ Cannot create releases (Perimeter 1 only) +* ❌ Cannot modify CI/CD (Perimeter 1 only) + +==== Responsibilities + +* *Reviews*: Provide timely, constructive reviews (within 1 week) +* *Triage*: Help manage issue backlog +* *Mentorship*: Guide new contributors (Perimeter 3) +* *Quality*: Maintain high standards +* *Availability*: Responsive to mentions and assignments + +==== Typical Activities + +* Review pull requests (formal, blocking) +* Triage incoming issues +* Label and categorize issues +* Mentor new contributors +* Participate in technical discussions +* Help with release testing + +*Time Commitment*: ~2-4 hours/week + +==== Path to Perimeter 2 + +*Example Timeline*: + +* *Month 1-2*: Submit first PR, get comfortable with codebase +* *Month 3-4*: 3-5 PRs merged, start informal reviews +* *Month 5-6*: 5+ PRs, active in community, nominated for Perimeter 2 +* *Month 7+*: Trusted Contributor status granted + +*Recognition*: Announced in release notes and listed in MAINTAINERS.md + +''''' + +=== Perimeter 1: Core Maintainers + +*Who*: Project maintainers (see MAINTAINERS.md) + +*How to Join*: Invited by existing Perimeter 1 members + +==== Requirements + +[arabic] +. *6+ months* as Perimeter 2 contributor +. *Significant contributions* to codebase and community +. *Deep understanding* of architecture and design decisions +. *Demonstrated leadership* in reviews, mentoring, direction-setting +. *Long-term commitment* to project +. *Invitation* by existing Perimeter 1 members +. *Unanimous approval* by all Perimeter 1 maintainers + +==== Access Rights + +*Everything in Perimeter 2, plus:* + +* ✅ *Merge to main branch* +* ✅ *Create releases* and version tags +* ✅ *Modify CI/CD* configuration +* ✅ *Access credentials* (DNS servers, test infrastructure) +* ✅ *Equal voice* in governance decisions +* ✅ *Emergency powers* (lockdown, rollback) + +==== Responsibilities + +* *Merges*: Review and merge pull requests +* *Releases*: Create and publish releases (semantic versioning) +* *Security*: Respond to vulnerability reports within 48 hours +* *Direction*: Set technical direction and roadmap +* *Governance*: Participate in decision-making +* *Nominations*: Identify and nominate Perimeter 2 candidates +* *Infrastructure*: Maintain CI/CD, testing, deployment +* *Community*: Foster welcoming, inclusive environment + +==== Typical Activities + +* Merge pull requests +* Create releases +* Respond to security reports +* Set roadmap and milestones +* Configure CI/CD +* Manage project credentials +* Make governance decisions +* Nominate/promote contributors + +*Time Commitment*: ~5-10 hours/week + +==== Path to Perimeter 1 + +*Example Timeline*: + +* *Month 1-6*: Perimeter 2 contributor, consistent high-quality work +* *Month 7-12*: Increased responsibilities, technical leadership +* *Month 12-18*: Invitation to Perimeter 1, evaluation period +* *Month 18+*: Full Perimeter 1 maintainer + +*Recognition*: Announced publicly, listed prominently in MAINTAINERS.md + +''''' + +=== Governance and Decision-Making + +==== Minor Decisions + +*Examples*: Code style, bug fixes, documentation improvements + +*Process*: Any Perimeter 1 maintainer can approve and merge + +*Timeframe*: Immediate to 1 week + +==== Major Decisions + +*Examples*: New features, breaking changes, dependency additions, +architecture changes + +*Process*: Consensus among Perimeter 1 maintainers + +*Timeframe*: 1-2 weeks + +*Steps*: 1. Proposal document (issue or RFC) 2. Discussion period (1 +week minimum) 3. Perimeter 1 consensus check 4. Implementation (if +approved) + +==== Critical Decisions + +*Examples*: License changes, governance changes, Code of Conduct +modifications + +*Process*: Unanimous approval by Perimeter 1 + community discussion + +*Timeframe*: 2-4 weeks + +*Steps*: 1. Formal proposal (RFC document) 2. Community discussion +period (2 weeks) 3. Perimeter 1 vote (unanimous required) 4. +Implementation (if approved) 5. Public announcement + +''''' + +=== Perimeter Transitions + +==== Promotion (Perimeter 3 → 2) + +*Initiated by*: Perimeter 1 maintainer (nomination) + +*Process*: 1. Perimeter 1 member identifies candidate 2. Private +discussion among Perimeter 1 3. Consensus reached (simple majority) 4. +Invitation sent to candidate 5. Candidate accepts 6. Public announcement +7. Update MAINTAINERS.md + +*Timeline*: 1-2 weeks after nomination + +==== Promotion (Perimeter 2 → 1) + +*Initiated by*: Existing Perimeter 1 members + +*Process*: 1. Private discussion among all Perimeter 1 2. Unanimous +approval required 3. Invitation sent to candidate 4. Candidate accepts +5. Evaluation period (1-3 months with trial access) 6. Final +confirmation 7. Public announcement 8. Update MAINTAINERS.md + +*Timeline*: 2-4 months after initial discussion + +==== Demotion or Removal + +*Reasons*: - Inactivity (6+ months, voluntary step-down encouraged) - +Code of Conduct violations - Security negligence - Loss of consensus + +*Process* (Perimeter 2): 1. Private discussion among Perimeter 1 2. +Attempt to resolve issues 3. Simple majority vote 4. Private +notification 5. Public announcement (if appropriate) 6. Graceful +transition + +*Process* (Perimeter 1): 1. Private discussion among remaining Perimeter +1 2. Attempt to resolve issues 3. Unanimous vote (excluding person in +question) 4. Private notification 5. Public announcement 6. Graceful +transition of responsibilities + +''''' + +=== Security Considerations + +==== Perimeter 3 (Untrusted) + +*Assumption*: Code is potentially malicious + +*Protections*: - All PRs reviewed before merge - No direct commit access +- No CI/CD access - No credential access + +==== Perimeter 2 (Trusted, Limited) + +*Assumption*: Code is well-intentioned but may have bugs + +*Protections*: - Cannot merge own PRs without Perimeter 1 approval - No +CI/CD access - No credential access - Review rights are advisory, not +final + +==== Perimeter 1 (Trusted, Full) + +*Assumption*: Fully trusted, but still reviewed + +*Protections*: - Consensus required for major changes - Peer review +still encouraged - Audit logs for all merges - Emergency rollback +capability + +''''' + +=== Emotional Safety and Well-Being + +TPCF is designed to support contributor well-being: + +==== Perimeter 3: Safe Experimentation + +* *Low stakes*: PRs can be rejected without stigma +* *Learning environment*: Mistakes are teaching moments +* *No pressure*: Contribute at your own pace +* *Reversibility*: Easy to fork and try different approaches + +==== Perimeter 2: Growth and Mentorship + +* *Recognition*: Your contributions are valued +* *Voice*: Input on technical direction +* *Mentorship*: Help newcomers, share knowledge +* *Balance*: No obligation if life gets busy + +==== Perimeter 1: Sustainable Leadership + +* *Shared responsibility*: No single point of failure +* *Burnout prevention*: Encourage breaks, step-down if needed +* *Work-life balance*: This is a hobby project, not a job +* *Emeritus status*: Step down gracefully with honor + +See also: *Emotional Temperature Metrics* in research documentation + +''''' + +=== Comparison to Other Models + +[width="100%",cols="18%,42%,40%",options="header",] +|=== +|Model |TPCF Equivalent |Key Difference +|*Benevolent Dictator* |Perimeter 1 (single) |TPCF supports +multi-maintainer consensus + +|*Committer Model* |Perimeter 2 |TPCF separates review rights from merge +rights + +|*Meritocracy* |All Perimeters |TPCF explicitly defines merit criteria +and transition paths + +|*Do-ocracy* |Perimeter 3 |TPCF adds graduated trust levels +|=== + +''''' + +=== FAQ + +==== Can I skip Perimeter 3 if I have experience? + +No. Everyone starts in Perimeter 3. This allows us to evaluate fit with +our specific project goals, security standards, and community culture. + +==== How long does it take to reach Perimeter 2? + +Typically 3-6 months of consistent contributions. Quality matters more +than quantity. + +==== Can I be in Perimeter 2 of multiple projects? + +Yes! TPCF is project-specific. Your status in one project doesn’t affect +others. + +==== What if I disagree with a Perimeter 1 decision? + +Open discussion is encouraged! Respectfully explain your position. If +consensus can’t be reached, Perimeter 1 makes the final call, but +dissenting opinions are documented. + +==== Can I lose Perimeter status? + +Yes, due to inactivity or violations. However, we strongly prefer +voluntary step-down and always attempt to resolve issues before removal. + +==== Is this just bureaucracy? + +No! TPCF clarifies expectations, reduces ambiguity, and makes the path +to maintainership transparent. It actually reduces bureaucracy by +defining clear processes. + +''''' + +=== Examples from HINFO-LOC Fluctuator + +==== Perimeter 3 Success Story + +*Scenario*: New contributor fixes typo in documentation + +*Process*: 1. Fork repo, fix typo 2. Submit PR 3. Perimeter 1 reviews, +suggests minor improvement 4. Contributor updates PR 5. Merged within 24 +hours + +*Outcome*: Contributor encouraged, documentation improved + +==== Perimeter 2 Candidate + +*Scenario*: Contributor has submitted 6 PRs over 4 months + +*Contributions*: - Added unit tests for DNS_Records module - Improved +error handling in Randomizer - Wrote comprehensive SPARK contracts for +Secure_Auth - Reviewed 10+ other PRs (informal) - Helped 3 new +contributors + +*Nomination*: - Perimeter 1 nominates to Perimeter 2 - Consensus reached +- Contributor accepts, becomes Trusted Contributor - Announced in next +release notes + +==== Perimeter 1 Decision + +*Scenario*: Should we add DNSSEC support? + +*Process*: 1. Community member proposes in issue 2. 2-week discussion +period 3. Perimeter 1 evaluates (complexity, maintenance burden, +security impact) 4. Consensus: Yes, but as optional feature in v3.0 5. +Roadmap updated + +''''' + +=== Acknowledgments + +TPCF is inspired by: - *Apache Software Foundation* (committer model) - +*Rust Project* (working groups) - *Python* (core developers, PEPs) - +*CSA SDP* (perimeter-based security) + +''''' + +=== References + +* *MAINTAINERS.md*: Current perimeter assignments +* *CONTRIBUTING.md*: How to contribute +* *CODE_OF_CONDUCT.md*: Community standards +* *SECURITY.md*: Security reporting + +''''' + +*Questions?* Open an issue with the `+governance+` label or contact +maintainers. + +''''' + +*Next Review*: 2026-05-22 (6 months) diff --git a/TPCF.md b/TPCF.md deleted file mode 100644 index 8544d2b..0000000 --- a/TPCF.md +++ /dev/null @@ -1,482 +0,0 @@ -# Tri-Perimeter Contribution Framework (TPCF) - -**Project**: HINFO-LOC Fluctuator -**Framework Version**: 1.0 -**Last Updated**: 2025-11-22 - ---- - -## Overview - -The **Tri-Perimeter Contribution Framework** (TPCF) is a graduated trust model that balances openness with security. It defines three concentric perimeters of access, each with different responsibilities and privileges. - -**Philosophy**: We welcome all contributors while protecting critical infrastructure. Trust is earned through consistent, quality contributions over time. - ---- - -## The Three Perimeters - -``` -┌────────────────────────────────────────────────────────┐ -│ Perimeter 3: Community Sandbox (Everyone) │ -│ ┌──────────────────────────────────────────────────┐ │ -│ │ Perimeter 2: Trusted Contributors │ │ -│ │ ┌────────────────────────────────────────────┐ │ │ -│ │ │ Perimeter 1: Core Maintainers │ │ │ -│ │ │ - Merge to main │ │ │ -│ │ │ - Create releases │ │ │ -│ │ │ - CI/CD configuration │ │ │ -│ │ └────────────────────────────────────────────┘ │ │ -│ │ - Formal review rights │ │ -│ │ - Issue triage │ │ -│ └──────────────────────────────────────────────────┘ │ -│ - Fork & PR │ -│ - Informal reviews │ -│ - Bug reports │ -└────────────────────────────────────────────────────────┘ -``` - ---- - -## Perimeter 3: Community Sandbox - -**Who**: Everyone (you!) - -**No Approval Needed**: Just start contributing! - -### Access Rights - -- ✅ Fork the repository -- ✅ Submit pull requests -- ✅ Comment on issues and PRs -- ✅ Review others' code (informal feedback) -- ✅ Report bugs -- ✅ Suggest features -- ✅ Participate in discussions - -### Restrictions - -- ❌ Cannot merge to main branch -- ❌ Cannot create releases -- ❌ Cannot modify CI/CD configuration -- ❌ Cannot access project credentials - -### Responsibilities - -- **Quality**: Submit well-tested, documented code -- **Code of Conduct**: Follow community guidelines -- **Security**: Report vulnerabilities responsibly (see SECURITY.md) -- **Communication**: Be respectful and constructive - -### Typical Activities - -- Fix bugs -- Add features -- Improve documentation -- Write tests -- Help other contributors -- Translate documentation (future) - -**Time Commitment**: None! Contribute when you can. - ---- - -## Perimeter 2: Trusted Contributors - -**Who**: Regular contributors with proven track record - -**How to Join**: Nominated by Perimeter 1 after meeting requirements - -### Requirements - -1. **5+ merged pull requests** of good quality -2. **Demonstrated understanding** of project goals and architecture -3. **Consistent code quality** (type safety, memory safety, security) -4. **Active participation** in code reviews (informal) -5. **Community positive behavior** (helpful, respectful) -6. **Nomination** by a Perimeter 1 maintainer -7. **Acceptance** by consensus of Perimeter 1 - -### Access Rights - -**Everything in Perimeter 3, plus:** - -- ✅ **Formal review rights** (blocking pull requests) -- ✅ **Issue triage** (label, assign, close) -- ✅ **Priority access** for questions and guidance -- ✅ **Recognition** in project documentation -- ✅ **Input on roadmap** and technical direction - -### Restrictions - -- ❌ Cannot merge to main (Perimeter 1 only) -- ❌ Cannot create releases (Perimeter 1 only) -- ❌ Cannot modify CI/CD (Perimeter 1 only) - -### Responsibilities - -- **Reviews**: Provide timely, constructive reviews (within 1 week) -- **Triage**: Help manage issue backlog -- **Mentorship**: Guide new contributors (Perimeter 3) -- **Quality**: Maintain high standards -- **Availability**: Responsive to mentions and assignments - -### Typical Activities - -- Review pull requests (formal, blocking) -- Triage incoming issues -- Label and categorize issues -- Mentor new contributors -- Participate in technical discussions -- Help with release testing - -**Time Commitment**: ~2-4 hours/week - -### Path to Perimeter 2 - -**Example Timeline**: - -- **Month 1-2**: Submit first PR, get comfortable with codebase -- **Month 3-4**: 3-5 PRs merged, start informal reviews -- **Month 5-6**: 5+ PRs, active in community, nominated for Perimeter 2 -- **Month 7+**: Trusted Contributor status granted - -**Recognition**: Announced in release notes and listed in MAINTAINERS.md - ---- - -## Perimeter 1: Core Maintainers - -**Who**: Project maintainers (see MAINTAINERS.md) - -**How to Join**: Invited by existing Perimeter 1 members - -### Requirements - -1. **6+ months** as Perimeter 2 contributor -2. **Significant contributions** to codebase and community -3. **Deep understanding** of architecture and design decisions -4. **Demonstrated leadership** in reviews, mentoring, direction-setting -5. **Long-term commitment** to project -6. **Invitation** by existing Perimeter 1 members -7. **Unanimous approval** by all Perimeter 1 maintainers - -### Access Rights - -**Everything in Perimeter 2, plus:** - -- ✅ **Merge to main branch** -- ✅ **Create releases** and version tags -- ✅ **Modify CI/CD** configuration -- ✅ **Access credentials** (DNS servers, test infrastructure) -- ✅ **Equal voice** in governance decisions -- ✅ **Emergency powers** (lockdown, rollback) - -### Responsibilities - -- **Merges**: Review and merge pull requests -- **Releases**: Create and publish releases (semantic versioning) -- **Security**: Respond to vulnerability reports within 48 hours -- **Direction**: Set technical direction and roadmap -- **Governance**: Participate in decision-making -- **Nominations**: Identify and nominate Perimeter 2 candidates -- **Infrastructure**: Maintain CI/CD, testing, deployment -- **Community**: Foster welcoming, inclusive environment - -### Typical Activities - -- Merge pull requests -- Create releases -- Respond to security reports -- Set roadmap and milestones -- Configure CI/CD -- Manage project credentials -- Make governance decisions -- Nominate/promote contributors - -**Time Commitment**: ~5-10 hours/week - -### Path to Perimeter 1 - -**Example Timeline**: - -- **Month 1-6**: Perimeter 2 contributor, consistent high-quality work -- **Month 7-12**: Increased responsibilities, technical leadership -- **Month 12-18**: Invitation to Perimeter 1, evaluation period -- **Month 18+**: Full Perimeter 1 maintainer - -**Recognition**: Announced publicly, listed prominently in MAINTAINERS.md - ---- - -## Governance and Decision-Making - -### Minor Decisions - -**Examples**: Code style, bug fixes, documentation improvements - -**Process**: Any Perimeter 1 maintainer can approve and merge - -**Timeframe**: Immediate to 1 week - -### Major Decisions - -**Examples**: New features, breaking changes, dependency additions, architecture changes - -**Process**: Consensus among Perimeter 1 maintainers - -**Timeframe**: 1-2 weeks - -**Steps**: -1. Proposal document (issue or RFC) -2. Discussion period (1 week minimum) -3. Perimeter 1 consensus check -4. Implementation (if approved) - -### Critical Decisions - -**Examples**: License changes, governance changes, Code of Conduct modifications - -**Process**: Unanimous approval by Perimeter 1 + community discussion - -**Timeframe**: 2-4 weeks - -**Steps**: -1. Formal proposal (RFC document) -2. Community discussion period (2 weeks) -3. Perimeter 1 vote (unanimous required) -4. Implementation (if approved) -5. Public announcement - ---- - -## Perimeter Transitions - -### Promotion (Perimeter 3 → 2) - -**Initiated by**: Perimeter 1 maintainer (nomination) - -**Process**: -1. Perimeter 1 member identifies candidate -2. Private discussion among Perimeter 1 -3. Consensus reached (simple majority) -4. Invitation sent to candidate -5. Candidate accepts -6. Public announcement -7. Update MAINTAINERS.md - -**Timeline**: 1-2 weeks after nomination - -### Promotion (Perimeter 2 → 1) - -**Initiated by**: Existing Perimeter 1 members - -**Process**: -1. Private discussion among all Perimeter 1 -2. Unanimous approval required -3. Invitation sent to candidate -4. Candidate accepts -5. Evaluation period (1-3 months with trial access) -6. Final confirmation -7. Public announcement -8. Update MAINTAINERS.md - -**Timeline**: 2-4 months after initial discussion - -### Demotion or Removal - -**Reasons**: -- Inactivity (6+ months, voluntary step-down encouraged) -- Code of Conduct violations -- Security negligence -- Loss of consensus - -**Process** (Perimeter 2): -1. Private discussion among Perimeter 1 -2. Attempt to resolve issues -3. Simple majority vote -4. Private notification -5. Public announcement (if appropriate) -6. Graceful transition - -**Process** (Perimeter 1): -1. Private discussion among remaining Perimeter 1 -2. Attempt to resolve issues -3. Unanimous vote (excluding person in question) -4. Private notification -5. Public announcement -6. Graceful transition of responsibilities - ---- - -## Security Considerations - -### Perimeter 3 (Untrusted) - -**Assumption**: Code is potentially malicious - -**Protections**: -- All PRs reviewed before merge -- No direct commit access -- No CI/CD access -- No credential access - -### Perimeter 2 (Trusted, Limited) - -**Assumption**: Code is well-intentioned but may have bugs - -**Protections**: -- Cannot merge own PRs without Perimeter 1 approval -- No CI/CD access -- No credential access -- Review rights are advisory, not final - -### Perimeter 1 (Trusted, Full) - -**Assumption**: Fully trusted, but still reviewed - -**Protections**: -- Consensus required for major changes -- Peer review still encouraged -- Audit logs for all merges -- Emergency rollback capability - ---- - -## Emotional Safety and Well-Being - -TPCF is designed to support contributor well-being: - -### Perimeter 3: Safe Experimentation - -- **Low stakes**: PRs can be rejected without stigma -- **Learning environment**: Mistakes are teaching moments -- **No pressure**: Contribute at your own pace -- **Reversibility**: Easy to fork and try different approaches - -### Perimeter 2: Growth and Mentorship - -- **Recognition**: Your contributions are valued -- **Voice**: Input on technical direction -- **Mentorship**: Help newcomers, share knowledge -- **Balance**: No obligation if life gets busy - -### Perimeter 1: Sustainable Leadership - -- **Shared responsibility**: No single point of failure -- **Burnout prevention**: Encourage breaks, step-down if needed -- **Work-life balance**: This is a hobby project, not a job -- **Emeritus status**: Step down gracefully with honor - -See also: **Emotional Temperature Metrics** in research documentation - ---- - -## Comparison to Other Models - -| Model | TPCF Equivalent | Key Difference | -|-------|-----------------|----------------| -| **Benevolent Dictator** | Perimeter 1 (single) | TPCF supports multi-maintainer consensus | -| **Committer Model** | Perimeter 2 | TPCF separates review rights from merge rights | -| **Meritocracy** | All Perimeters | TPCF explicitly defines merit criteria and transition paths | -| **Do-ocracy** | Perimeter 3 | TPCF adds graduated trust levels | - ---- - -## FAQ - -### Can I skip Perimeter 3 if I have experience? - -No. Everyone starts in Perimeter 3. This allows us to evaluate fit with our specific project goals, security standards, and community culture. - -### How long does it take to reach Perimeter 2? - -Typically 3-6 months of consistent contributions. Quality matters more than quantity. - -### Can I be in Perimeter 2 of multiple projects? - -Yes! TPCF is project-specific. Your status in one project doesn't affect others. - -### What if I disagree with a Perimeter 1 decision? - -Open discussion is encouraged! Respectfully explain your position. If consensus can't be reached, Perimeter 1 makes the final call, but dissenting opinions are documented. - -### Can I lose Perimeter status? - -Yes, due to inactivity or violations. However, we strongly prefer voluntary step-down and always attempt to resolve issues before removal. - -### Is this just bureaucracy? - -No! TPCF clarifies expectations, reduces ambiguity, and makes the path to maintainership transparent. It actually reduces bureaucracy by defining clear processes. - ---- - -## Examples from HINFO-LOC Fluctuator - -### Perimeter 3 Success Story - -**Scenario**: New contributor fixes typo in documentation - -**Process**: -1. Fork repo, fix typo -2. Submit PR -3. Perimeter 1 reviews, suggests minor improvement -4. Contributor updates PR -5. Merged within 24 hours - -**Outcome**: Contributor encouraged, documentation improved - -### Perimeter 2 Candidate - -**Scenario**: Contributor has submitted 6 PRs over 4 months - -**Contributions**: -- Added unit tests for DNS_Records module -- Improved error handling in Randomizer -- Wrote comprehensive SPARK contracts for Secure_Auth -- Reviewed 10+ other PRs (informal) -- Helped 3 new contributors - -**Nomination**: -- Perimeter 1 nominates to Perimeter 2 -- Consensus reached -- Contributor accepts, becomes Trusted Contributor -- Announced in next release notes - -### Perimeter 1 Decision - -**Scenario**: Should we add DNSSEC support? - -**Process**: -1. Community member proposes in issue -2. 2-week discussion period -3. Perimeter 1 evaluates (complexity, maintenance burden, security impact) -4. Consensus: Yes, but as optional feature in v3.0 -5. Roadmap updated - ---- - -## Acknowledgments - -TPCF is inspired by: -- **Apache Software Foundation** (committer model) -- **Rust Project** (working groups) -- **Python** (core developers, PEPs) -- **CSA SDP** (perimeter-based security) - ---- - -## References - -- **MAINTAINERS.md**: Current perimeter assignments -- **CONTRIBUTING.md**: How to contribute -- **CODE_OF_CONDUCT.md**: Community standards -- **SECURITY.md**: Security reporting - ---- - -**Questions?** Open an issue with the `governance` label or contact maintainers. - ---- - -**Next Review**: 2026-05-22 (6 months) diff --git a/docs/tech-debt-2026-05-26.adoc b/docs/tech-debt-2026-05-26.adoc new file mode 100644 index 0000000..a62a38a --- /dev/null +++ b/docs/tech-debt-2026-05-26.adoc @@ -0,0 +1,66 @@ +== Tech-Debt Audit — resource-record-fluctuator — 2026-05-26 + +*Source:* estate-wide automated scan 2026-05-26. *Companion:* +https://github.com/hyperpolymath/standards/tree/main/docs/audits[`+hyperpolymath/standards+` +2026-05-26-estate-*-debt audits]. *Combined severity:* `+2026-05-22+`. + +This file records the _raw findings_ — it does not by itself fix the +debt. Each section ends with a '`Recommended next move`' line; closing +the debt is follow-up work. + +=== 1. Proof debt + +Scanner counted the following markers in proof-bearing files of this +repo: + +.... +files= 31 | Coq-Axm/Adm= 0 | Lean-srry/ax= 0 | Agda-pst= 0 | Idr-blv= 0 | Idr-prtl= 0 | Fstr-asm= 0 | TODO= 0 | Unsafe= 0 +.... + +*Total markers:* 0. *Severity:* `+>00+`. + +*Recommended next move:* none — no proof-debt markers detected. + +=== 2. Licence debt + +[cols=",",options="header",] +|=== +|Field |Value +|LICENSE file |`+LICENSE+` +|SPDX header |`+MPL-2.0+` +|Manifest licence |`+NONE+` +|Body classifier |`+Palimp-MPL-2.0+` +|Severity |`+ok+` +|=== + +*Recommended next move:* none for licence. + +=== 3. Documentation debt + +[cols=",",options="header",] +|=== +|Field |Value +|README lines |357 +|`+docs/+` files |1 +|`+docs/+` LoC |36 +|CHANGELOG.md |Y +|CONTRIBUTING.md |Y +|CODE_OF_CONDUCT.md |Y +|SECURITY.md |Y +|Severity |`+readme=357 docs=1/36+` +|=== + +=== Cross-references + +* Estate proof-debt audit: +`+hyperpolymath/standards/docs/audits/2026-05-26-estate-proof-debt.md+` +* Estate licence-debt audit: +`+hyperpolymath/standards/docs/audits/2026-05-26-estate-licence-debt.md+` +* Estate documentation-debt audit: +`+hyperpolymath/standards/docs/audits/2026-05-26-estate-documentation-debt.md+` + +''''' + +🤖 Generated by Claude Code estate-wide tech-debt scan (2026-05-26). +This file is informational — closing the debt is follow-up work owned by +the maintainer. diff --git a/docs/tech-debt-2026-05-26.md b/docs/tech-debt-2026-05-26.md deleted file mode 100644 index 24ff307..0000000 --- a/docs/tech-debt-2026-05-26.md +++ /dev/null @@ -1,60 +0,0 @@ - - -# Tech-Debt Audit — resource-record-fluctuator — 2026-05-26 - -**Source:** estate-wide automated scan 2026-05-26. -**Companion:** [`hyperpolymath/standards` 2026-05-26-estate-*-debt audits](https://github.com/hyperpolymath/standards/tree/main/docs/audits). -**Combined severity:** `2026-05-22`. - -This file records the *raw findings* — it does not by itself fix the debt. Each section ends with a 'Recommended next move' line; closing the debt is follow-up work. - -## 1. Proof debt - -Scanner counted the following markers in proof-bearing files of this repo: - -``` -files= 31 | Coq-Axm/Adm= 0 | Lean-srry/ax= 0 | Agda-pst= 0 | Idr-blv= 0 | Idr-prtl= 0 | Fstr-asm= 0 | TODO= 0 | Unsafe= 0 -``` - -**Total markers:** 0. **Severity:** `>00`. - -**Recommended next move:** none — no proof-debt markers detected. - -## 2. Licence debt - -| Field | Value | -|---|---| -| LICENSE file | `LICENSE` | -| SPDX header | `MPL-2.0` | -| Manifest licence | `NONE` | -| Body classifier | `Palimp-MPL-2.0` | -| Severity | `ok` | - -**Recommended next move:** none for licence. - -## 3. Documentation debt - -| Field | Value | -|---|---| -| README lines | 357 | -| `docs/` files | 1 | -| `docs/` LoC | 36 | -| CHANGELOG.md | Y | -| CONTRIBUTING.md | Y | -| CODE_OF_CONDUCT.md | Y | -| SECURITY.md | Y | -| Severity | `readme=357 docs=1/36` | - - -## Cross-references - -- Estate proof-debt audit: `hyperpolymath/standards/docs/audits/2026-05-26-estate-proof-debt.md` -- Estate licence-debt audit: `hyperpolymath/standards/docs/audits/2026-05-26-estate-licence-debt.md` -- Estate documentation-debt audit: `hyperpolymath/standards/docs/audits/2026-05-26-estate-documentation-debt.md` - ---- - -🤖 Generated by Claude Code estate-wide tech-debt scan (2026-05-26). This file is informational — closing the debt is follow-up work owned by the maintainer. diff --git a/hinfo_loc_fluctuator/README.adoc b/hinfo_loc_fluctuator/README.adoc new file mode 100644 index 0000000..98ddfbb --- /dev/null +++ b/hinfo_loc_fluctuator/README.adoc @@ -0,0 +1,115 @@ +== Elixir Prototype (Reference Only) + +*⚠️ NOT RECOMMENDED FOR PRODUCTION* + +This directory contains an initial Elixir prototype of the HINFO-LOC +Fluctuator. It was created as a proof-of-concept but *was replaced with +the Ada implementation* for security reasons. + +=== Why Not Elixir? + +While Elixir is an excellent language for many applications, the +HINFO-LOC Fluctuator was specifically rewritten in Ada because: + +==== Security Requirements + +[arabic] +. *Memory Safety*: This tool modifies critical DNS infrastructure +* Ada prevents buffer overflows at compile time +* Elixir (BEAM VM) provides runtime protection but less formal +guarantees +. *Type Safety*: DNS records have strict format requirements +* Ada enforces bounds at compile time: +`+type Latitude_Degrees is delta 0.000001 range -90.0 .. 90.0;+` +* Elixir relies on runtime validation +. *Formal Verification*: SPARK (Ada subset) allows mathematical proof of +correctness +* Critical for security-sensitive DNS modifications +* Not available in Elixir ecosystem +. *Overflow Checking*: Ada checks for integer overflow in all builds +* `+-gnato+` flag ensures arithmetic safety +* Elixir has arbitrary precision integers but different guarantees + +==== The Decision Point + +The original conversation: + +.... +User: "I'm concerned about security since this modifies DNS infrastructure." + +Response: "You're absolutely right. Let's use Ada instead." +.... + +This was the correct decision. DNS is critical infrastructure, and the +additional compile-time safety of Ada is worth the trade-off in +developer convenience. + +=== What This Prototype Was + +A basic Elixir implementation with: - Simple HINFO/LOC record structures +- Random generation from data files - Basic CLI interface + +*Missing* (compared to Ada version): - Compile-time type safety - +Overflow checking - Authentication system - Permission model - SPARK +verification capability + +=== The Ada Advantage + +Compare these approaches: + +==== Elixir (Runtime Validation) + +[source,elixir] +---- +defmodule DNSRecords do + def create_loc(lat, lon, alt) when lat >= -90 and lat <= 90 and + lon >= -180 and lon <= 180 do + # Runtime check - fails at runtime if violated + %LOC{latitude: lat, longitude: lon, altitude: alt} + end +end +---- + +==== Ada (Compile-Time Guarantee) + +[source,ada] +---- +type Latitude_Degrees is delta 0.000001 range -90.0 .. 90.0; +type Longitude_Degrees is delta 0.000001 range -180.0 .. 180.0; + +-- Compiler PREVENTS creation of invalid values +-- No runtime check needed - guaranteed by type system +---- + +=== Should You Use This? + +*No.* Use the Ada implementation in `+hinfo_loc_fluctuator_ada/+`. + +This Elixir code exists only as: 1. Historical reference 2. +Demonstration of the design evolution 3. Example of why language choice +matters for security + +=== If You Really Want Elixir… + +If you absolutely need an Elixir implementation: + +[arabic] +. Add extensive runtime validation everywhere +. Use Dialyzer for static analysis +. Implement comprehensive property-based testing (PropCheck) +. Add overflow checking manually +. Never use in production without security audit +. Consider why you’re not using the Ada version + +=== License + +Same as main project. Use at your own risk. + +=== Recommendation + +*Use the Ada implementation.* Your DNS infrastructure will thank you. + +''''' + +_"`With great power comes great responsibility. With DNS modification +comes great type safety requirements.`"_ diff --git a/hinfo_loc_fluctuator/README.md b/hinfo_loc_fluctuator/README.md deleted file mode 100644 index ee778c8..0000000 --- a/hinfo_loc_fluctuator/README.md +++ /dev/null @@ -1,109 +0,0 @@ -# Elixir Prototype (Reference Only) - -**⚠️ NOT RECOMMENDED FOR PRODUCTION** - -This directory contains an initial Elixir prototype of the HINFO-LOC Fluctuator. It was created as a proof-of-concept but **was replaced with the Ada implementation** for security reasons. - -## Why Not Elixir? - -While Elixir is an excellent language for many applications, the HINFO-LOC Fluctuator was specifically rewritten in Ada because: - -### Security Requirements - -1. **Memory Safety**: This tool modifies critical DNS infrastructure - - Ada prevents buffer overflows at compile time - - Elixir (BEAM VM) provides runtime protection but less formal guarantees - -2. **Type Safety**: DNS records have strict format requirements - - Ada enforces bounds at compile time: `type Latitude_Degrees is delta 0.000001 range -90.0 .. 90.0;` - - Elixir relies on runtime validation - -3. **Formal Verification**: SPARK (Ada subset) allows mathematical proof of correctness - - Critical for security-sensitive DNS modifications - - Not available in Elixir ecosystem - -4. **Overflow Checking**: Ada checks for integer overflow in all builds - - `-gnato` flag ensures arithmetic safety - - Elixir has arbitrary precision integers but different guarantees - -### The Decision Point - -The original conversation: - -``` -User: "I'm concerned about security since this modifies DNS infrastructure." - -Response: "You're absolutely right. Let's use Ada instead." -``` - -This was the correct decision. DNS is critical infrastructure, and the additional compile-time safety of Ada is worth the trade-off in developer convenience. - -## What This Prototype Was - -A basic Elixir implementation with: -- Simple HINFO/LOC record structures -- Random generation from data files -- Basic CLI interface - -**Missing** (compared to Ada version): -- Compile-time type safety -- Overflow checking -- Authentication system -- Permission model -- SPARK verification capability - -## The Ada Advantage - -Compare these approaches: - -### Elixir (Runtime Validation) -```elixir -defmodule DNSRecords do - def create_loc(lat, lon, alt) when lat >= -90 and lat <= 90 and - lon >= -180 and lon <= 180 do - # Runtime check - fails at runtime if violated - %LOC{latitude: lat, longitude: lon, altitude: alt} - end -end -``` - -### Ada (Compile-Time Guarantee) -```ada -type Latitude_Degrees is delta 0.000001 range -90.0 .. 90.0; -type Longitude_Degrees is delta 0.000001 range -180.0 .. 180.0; - --- Compiler PREVENTS creation of invalid values --- No runtime check needed - guaranteed by type system -``` - -## Should You Use This? - -**No.** Use the Ada implementation in `hinfo_loc_fluctuator_ada/`. - -This Elixir code exists only as: -1. Historical reference -2. Demonstration of the design evolution -3. Example of why language choice matters for security - -## If You Really Want Elixir... - -If you absolutely need an Elixir implementation: - -1. Add extensive runtime validation everywhere -2. Use Dialyzer for static analysis -3. Implement comprehensive property-based testing (PropCheck) -4. Add overflow checking manually -5. Never use in production without security audit -6. Consider why you're not using the Ada version - -## License - -Same as main project. Use at your own risk. - -## Recommendation - -**Use the Ada implementation.** Your DNS infrastructure will thank you. - ---- - -*"With great power comes great responsibility. With DNS modification comes great type safety requirements."* diff --git a/hinfo_loc_fluctuator_ada/README.adoc b/hinfo_loc_fluctuator_ada/README.adoc new file mode 100644 index 0000000..aaaab12 --- /dev/null +++ b/hinfo_loc_fluctuator_ada/README.adoc @@ -0,0 +1,361 @@ +== HINFO-LOC Fluctuator - Quantum Server™ + +DNS record randomization tool for deprecated HINFO (host info) and LOC +(geographic location) records. Built with Ada for maximum security and +type safety. + +=== 🎯 Purpose + +*Amusing Applications:* - "`Quantum Server`" - make your server appear +to exist in multiple locations simultaneously - Confuse network +reconnaissance tools - Entertainment and demonstration + +*Serious Security Uses:* - Honeypot obfuscation (make honeypots appear +to move locations/change hardware) - Attack response and deception +technology - Privacy enhancement for public-facing DNS records - +Security research and education + +*Important:* HINFO and LOC records are deprecated per RFC 8482 - that’s +precisely the point! These records are rarely used in production, making +them ideal for experimental security techniques without affecting +critical services. + +=== ✨ Features + +==== Implemented ✅ + +* *Type-Safe DNS Records* +** HINFO records (CPU + Operating System) +** LOC records (Geographic location with altitude) +** Compile-time bounds checking prevents invalid values +** TTL range: 1-604800 seconds (1 second to 7 days) +** Latitude: -90° to +90° with 6 decimal precision +** Longitude: -180° to +180° with 6 decimal precision +** Altitude: -100,000m to 42,849,672m (Dead Sea to space) +* *Security-First Design* +** Permission system: None → Read-Only → Modify-Local → Modify-Remote → +Admin +** Session management with automatic 30-minute timeout +** Constant-time password comparison (prevents timing attacks) +** Replay attack detection using nonces +** All compiler safety checks enabled even in release builds +** No buffer overflows possible (Ada memory safety) +* *Randomization Engine* +** Load CPU types from `+data/machines.txt+` (68 included) +** Load OS names from `+data/operating_systems.txt+` (77 included) +** Load locations from `+data/locations.csv+` (52 included) +** Full CSV parser implementation +** Generate random HINFO and LOC records +** "`Quantum Server`" mode (generates both simultaneously) +* *Interactive TUI* +** Menu-driven interface with ANSI colors +** Login screen with permission-based access +** Pool management and status display +** Record generation and preview +* *Build System* +** GNAT project file with multiple build modes +** Makefile with convenient targets +** Debug, Release, and SPARK verification modes +** Overflow checking ALWAYS enabled + +==== Not Yet Implemented ❌ + +* DNS UPDATE (RFC 2136) for remote server modification +* TSIG authentication (RFC 2845) for secure updates +* Zone file writer for local mode (BIND format) +* Scheduled auto-fluctuation with Ada tasking +* Configuration file support (TOML/YAML) +* API/webhook triggers +* Production-grade crypto (bcrypt/Argon2) +* SPARK formal verification proofs + +=== 🚀 Quick Start + +==== Prerequisites + +* GNAT Ada compiler (FSF GNAT or AdaCore GNAT Community Edition) +* Make (for build automation) +* Linux/Unix environment (or WSL on Windows) + +==== Installation + +[source,bash] +---- +# Clone the repository +git clone +cd resource-record-fluctuator/hinfo_loc_fluctuator_ada + +# Build the project +make + +# Run the program +./bin/hinfo_loc_fluctuator +---- + +==== Demo Credentials + +*⚠️ WARNING: These are DEMO credentials with simplified crypto!* + +[cols=",,",options="header",] +|=== +|Username |Password |Permission Level +|admin |any |Full access (Admin) +|user |any |Read-only access +|operator |any |Local modifications +|=== + +*MUST be replaced before any real deployment!* + +=== 📖 Usage + +==== Interactive Mode (Default) + +[source,bash] +---- +./bin/hinfo_loc_fluctuator +---- + +[arabic] +. Login with demo credentials +. Load data pools (Option 1) +. Generate random records (Option 3) +. Try "`Quantum Server`" mode (Option 4) + +==== Command-Line Options + +[source,bash] +---- +./bin/hinfo_loc_fluctuator --help # Show help +./bin/hinfo_loc_fluctuator --version # Show version +./bin/hinfo_loc_fluctuator --interactive # Explicit interactive mode +---- + +==== Building Different Modes + +[source,bash] +---- +make debug # Debug build (default) +make release # Optimized build (safety checks still enabled!) +make prove # SPARK verification mode +make verify # Run SPARK formal verification +make clean # Clean build artifacts +make install # Install to /usr/local/bin (requires sudo) +---- + +=== 📂 Project Structure + +.... +hinfo_loc_fluctuator_ada/ +├── src/ +│ ├── dns_records.ads/adb # Type-safe DNS record definitions +│ ├── secure_auth.ads/adb # Authentication and session management +│ ├── randomizer.ads/adb # Data loading and random generation +│ ├── tui.ads/adb # Text user interface +│ └── main.adb # Entry point +├── data/ +│ ├── machines.txt # 68 CPU types +│ ├── operating_systems.txt # 77 operating systems +│ └── locations.csv # 52 geographic locations +├── hinfo_loc_fluctuator.gpr # GNAT project file +├── Makefile # Build automation +├── README.md # This file +└── docs/ + └── USE_CASES.md # Detailed use case scenarios +.... + +=== 🔧 Configuration + +==== Adding Custom CPUs/Operating Systems + +Edit `+data/machines.txt+` or `+data/operating_systems.txt+`: + +.... +# One entry per line +# Lines starting with # are comments + +Intel-Core-i9 +AMD-Ryzen-9 +Apple-M2 +# Add your custom entries here +.... + +==== Adding Custom Locations + +Edit `+data/locations.csv+`: + +[source,csv] +---- +# Format: latitude,longitude,altitude_meters,description +37.7749,-122.4194,16,San Francisco Data Center +51.5074,-0.1278,11,London Data Center +# Add your custom locations here +---- + +=== 🛡️ Security Considerations + +==== Compile-Time Safety + +Ada’s type system prevents entire classes of bugs: + +[source,ada] +---- +type Latitude_Degrees is delta 0.000001 range -90.0 .. 90.0; +-- Compiler GUARANTEES latitude is valid - no runtime check needed +---- + +==== Enabled Security Flags + +Even in release builds: - `+-gnato+`: Overflow checking on all +arithmetic - `+-fstack-check+`: Stack overflow detection - `+-gnatVa+`: +Validity checking for all data - `+-gnata+`: Assertions enabled + +==== Current Limitations + +*⚠️ CRITICAL SECURITY WARNINGS:* + +[arabic] +. *Demo Credentials*: Hardcoded credentials with placeholder hashes +. *Simplified Crypto*: Password comparison uses demo implementation +. *No DNS Integration*: Cannot actually modify DNS servers yet +. *No TSIG*: Secure DNS updates not implemented + +*DO NOT deploy this to production without:* - Replacing authentication +with bcrypt/Argon2 - Implementing proper DNS UPDATE with TSIG - Security +audit and penetration testing - Removing demo credentials + +=== 🎓 Use Cases + +See docs/USE_CASES.md for detailed scenarios: + +* Honeypot deployment obfuscation +* Incident response and threat hunting +* Security research and education +* Privacy enhancement for public services +* Testing and development environments +* "`Quantum Server`" demonstrations + +=== 📚 Technical Details + +==== DNS Records Supported + +*HINFO (Host Information) - RFC 1035* - CPU field: Hardware/architecture +type - OS field: Operating system name - Deprecated per RFC 8482 +(intentional!) + +*LOC (Location) - RFC 1876* - Latitude/Longitude in decimal degrees - +Altitude in meters above WGS84 ellipsoid - Size and precision fields +(horizontal/vertical) - Deprecated per RFC 8482 (intentional!) + +==== Type Safety Examples + +[source,ada] +---- +-- TTL must be 1-604800 seconds (enforced at compile time) +type TTL_Seconds is range 1 .. 604_800; + +-- Latitude must be -90.0 to +90.0 degrees +type Latitude_Degrees is delta 0.000001 range -90.0 .. 90.0; + +-- These guarantees cannot be violated - compiler prevents it! +---- + +==== Permission Hierarchy + +.... +None < Read_Only < Modify_Local < Modify_Remote < Admin +.... + +Each level inherits permissions from lower levels. + +=== 🔬 Development + +==== Running Tests + +[source,bash] +---- +make test # Quick test build cycle +make verify # SPARK formal verification +---- + +==== Code Style + +Follows standard Ada conventions: - Types: +`+Mixed_Case_With_Underscores+` - Variables: +`+lower_case_with_underscores+` - Constants: +`+UPPER_CASE_WITH_UNDERSCORES+` + +==== Contributing + +[arabic] +. Maintain type safety - don’t use unchecked conversions +. Keep security flags enabled +. Document "`why`" not "`what`" in comments +. Test with actual DNS servers when available + +=== 📋 Roadmap + +==== Phase 1: Core (Complete ✅) + +* [x] DNS record types +* [x] Authentication system +* [x] Randomization engine +* [x] Interactive TUI +* [x] Build system +* [x] Sample data + +==== Phase 2: DNS Integration (In Progress) + +* [ ] DNS UPDATE (RFC 2136) implementation +* [ ] TSIG authentication (RFC 2845) +* [ ] Zone file writer (BIND format) +* [ ] Test with real DNS servers + +==== Phase 3: Advanced Features + +* [ ] Configuration file support +* [ ] Scheduled fluctuation (Ada tasking) +* [ ] Logging system +* [ ] API/webhook triggers +* [ ] Ncurses-based enhanced TUI + +==== Phase 4: Production Hardening + +* [ ] bcrypt/Argon2 password hashing +* [ ] SPARK formal verification +* [ ] Security audit +* [ ] Unit test suite +* [ ] Performance optimization + +=== 🐛 Known Issues + +[arabic] +. *CSV Parser*: Simple implementation, doesn’t handle quoted commas +. *Demo Auth*: Uses placeholder hashes, not real crypto +. *Chaos/Hesiod Classes*: Rarely supported by DNS servers +. *No DNS Communication*: Cannot actually update servers yet + +=== 📄 License + +{empty}[Specify your license here - MIT, GPL, etc.] + +=== 🙏 Acknowledgments + +* RFCs 1034, 1035, 1876, 2136, 2845, 8482 +* Ada community for security-focused language design +* GNAT compiler team for excellent tooling + +=== 📞 Contact + +{empty}[Your contact information or GitHub profile] + +''''' + +=== Fun Fact + +The "`Quantum Server`" concept is inspired by quantum superposition - +your server simultaneously exists as an Intel Xeon in San Francisco AND +an ARM processor in Tokyo. Schrödinger would approve! 🐱⚛️ + +*Remember:* With great power comes great responsibility. Use this tool +ethically and legally. Always obtain proper authorization before +modifying DNS infrastructure. diff --git a/hinfo_loc_fluctuator_ada/README.md b/hinfo_loc_fluctuator_ada/README.md deleted file mode 100644 index 6ce0897..0000000 --- a/hinfo_loc_fluctuator_ada/README.md +++ /dev/null @@ -1,346 +0,0 @@ -# HINFO-LOC Fluctuator - Quantum Server™ - -DNS record randomization tool for deprecated HINFO (host info) and LOC (geographic location) records. Built with Ada for maximum security and type safety. - -## 🎯 Purpose - -**Amusing Applications:** -- "Quantum Server" - make your server appear to exist in multiple locations simultaneously -- Confuse network reconnaissance tools -- Entertainment and demonstration - -**Serious Security Uses:** -- Honeypot obfuscation (make honeypots appear to move locations/change hardware) -- Attack response and deception technology -- Privacy enhancement for public-facing DNS records -- Security research and education - -**Important:** HINFO and LOC records are deprecated per RFC 8482 - that's precisely the point! These records are rarely used in production, making them ideal for experimental security techniques without affecting critical services. - -## ✨ Features - -### Implemented ✅ - -- **Type-Safe DNS Records** - - HINFO records (CPU + Operating System) - - LOC records (Geographic location with altitude) - - Compile-time bounds checking prevents invalid values - - TTL range: 1-604800 seconds (1 second to 7 days) - - Latitude: -90° to +90° with 6 decimal precision - - Longitude: -180° to +180° with 6 decimal precision - - Altitude: -100,000m to 42,849,672m (Dead Sea to space) - -- **Security-First Design** - - Permission system: None → Read-Only → Modify-Local → Modify-Remote → Admin - - Session management with automatic 30-minute timeout - - Constant-time password comparison (prevents timing attacks) - - Replay attack detection using nonces - - All compiler safety checks enabled even in release builds - - No buffer overflows possible (Ada memory safety) - -- **Randomization Engine** - - Load CPU types from `data/machines.txt` (68 included) - - Load OS names from `data/operating_systems.txt` (77 included) - - Load locations from `data/locations.csv` (52 included) - - Full CSV parser implementation - - Generate random HINFO and LOC records - - "Quantum Server" mode (generates both simultaneously) - -- **Interactive TUI** - - Menu-driven interface with ANSI colors - - Login screen with permission-based access - - Pool management and status display - - Record generation and preview - -- **Build System** - - GNAT project file with multiple build modes - - Makefile with convenient targets - - Debug, Release, and SPARK verification modes - - Overflow checking ALWAYS enabled - -### Not Yet Implemented ❌ - -- DNS UPDATE (RFC 2136) for remote server modification -- TSIG authentication (RFC 2845) for secure updates -- Zone file writer for local mode (BIND format) -- Scheduled auto-fluctuation with Ada tasking -- Configuration file support (TOML/YAML) -- API/webhook triggers -- Production-grade crypto (bcrypt/Argon2) -- SPARK formal verification proofs - -## 🚀 Quick Start - -### Prerequisites - -- GNAT Ada compiler (FSF GNAT or AdaCore GNAT Community Edition) -- Make (for build automation) -- Linux/Unix environment (or WSL on Windows) - -### Installation - -```bash -# Clone the repository -git clone -cd resource-record-fluctuator/hinfo_loc_fluctuator_ada - -# Build the project -make - -# Run the program -./bin/hinfo_loc_fluctuator -``` - -### Demo Credentials - -**⚠️ WARNING: These are DEMO credentials with simplified crypto!** - -| Username | Password | Permission Level | -|----------|----------|------------------| -| admin | any | Full access (Admin) | -| user | any | Read-only access | -| operator | any | Local modifications | - -**MUST be replaced before any real deployment!** - -## 📖 Usage - -### Interactive Mode (Default) - -```bash -./bin/hinfo_loc_fluctuator -``` - -1. Login with demo credentials -2. Load data pools (Option 1) -3. Generate random records (Option 3) -4. Try "Quantum Server" mode (Option 4) - -### Command-Line Options - -```bash -./bin/hinfo_loc_fluctuator --help # Show help -./bin/hinfo_loc_fluctuator --version # Show version -./bin/hinfo_loc_fluctuator --interactive # Explicit interactive mode -``` - -### Building Different Modes - -```bash -make debug # Debug build (default) -make release # Optimized build (safety checks still enabled!) -make prove # SPARK verification mode -make verify # Run SPARK formal verification -make clean # Clean build artifacts -make install # Install to /usr/local/bin (requires sudo) -``` - -## 📂 Project Structure - -``` -hinfo_loc_fluctuator_ada/ -├── src/ -│ ├── dns_records.ads/adb # Type-safe DNS record definitions -│ ├── secure_auth.ads/adb # Authentication and session management -│ ├── randomizer.ads/adb # Data loading and random generation -│ ├── tui.ads/adb # Text user interface -│ └── main.adb # Entry point -├── data/ -│ ├── machines.txt # 68 CPU types -│ ├── operating_systems.txt # 77 operating systems -│ └── locations.csv # 52 geographic locations -├── hinfo_loc_fluctuator.gpr # GNAT project file -├── Makefile # Build automation -├── README.md # This file -└── docs/ - └── USE_CASES.md # Detailed use case scenarios -``` - -## 🔧 Configuration - -### Adding Custom CPUs/Operating Systems - -Edit `data/machines.txt` or `data/operating_systems.txt`: - -``` -# One entry per line -# Lines starting with # are comments - -Intel-Core-i9 -AMD-Ryzen-9 -Apple-M2 -# Add your custom entries here -``` - -### Adding Custom Locations - -Edit `data/locations.csv`: - -```csv -# Format: latitude,longitude,altitude_meters,description -37.7749,-122.4194,16,San Francisco Data Center -51.5074,-0.1278,11,London Data Center -# Add your custom locations here -``` - -## 🛡️ Security Considerations - -### Compile-Time Safety - -Ada's type system prevents entire classes of bugs: - -```ada -type Latitude_Degrees is delta 0.000001 range -90.0 .. 90.0; --- Compiler GUARANTEES latitude is valid - no runtime check needed -``` - -### Enabled Security Flags - -Even in release builds: -- `-gnato`: Overflow checking on all arithmetic -- `-fstack-check`: Stack overflow detection -- `-gnatVa`: Validity checking for all data -- `-gnata`: Assertions enabled - -### Current Limitations - -**⚠️ CRITICAL SECURITY WARNINGS:** - -1. **Demo Credentials**: Hardcoded credentials with placeholder hashes -2. **Simplified Crypto**: Password comparison uses demo implementation -3. **No DNS Integration**: Cannot actually modify DNS servers yet -4. **No TSIG**: Secure DNS updates not implemented - -**DO NOT deploy this to production without:** -- Replacing authentication with bcrypt/Argon2 -- Implementing proper DNS UPDATE with TSIG -- Security audit and penetration testing -- Removing demo credentials - -## 🎓 Use Cases - -See [docs/USE_CASES.md](docs/USE_CASES.md) for detailed scenarios: - -- Honeypot deployment obfuscation -- Incident response and threat hunting -- Security research and education -- Privacy enhancement for public services -- Testing and development environments -- "Quantum Server" demonstrations - -## 📚 Technical Details - -### DNS Records Supported - -**HINFO (Host Information) - RFC 1035** -- CPU field: Hardware/architecture type -- OS field: Operating system name -- Deprecated per RFC 8482 (intentional!) - -**LOC (Location) - RFC 1876** -- Latitude/Longitude in decimal degrees -- Altitude in meters above WGS84 ellipsoid -- Size and precision fields (horizontal/vertical) -- Deprecated per RFC 8482 (intentional!) - -### Type Safety Examples - -```ada --- TTL must be 1-604800 seconds (enforced at compile time) -type TTL_Seconds is range 1 .. 604_800; - --- Latitude must be -90.0 to +90.0 degrees -type Latitude_Degrees is delta 0.000001 range -90.0 .. 90.0; - --- These guarantees cannot be violated - compiler prevents it! -``` - -### Permission Hierarchy - -``` -None < Read_Only < Modify_Local < Modify_Remote < Admin -``` - -Each level inherits permissions from lower levels. - -## 🔬 Development - -### Running Tests - -```bash -make test # Quick test build cycle -make verify # SPARK formal verification -``` - -### Code Style - -Follows standard Ada conventions: -- Types: `Mixed_Case_With_Underscores` -- Variables: `lower_case_with_underscores` -- Constants: `UPPER_CASE_WITH_UNDERSCORES` - -### Contributing - -1. Maintain type safety - don't use unchecked conversions -2. Keep security flags enabled -3. Document "why" not "what" in comments -4. Test with actual DNS servers when available - -## 📋 Roadmap - -### Phase 1: Core (Complete ✅) -- [x] DNS record types -- [x] Authentication system -- [x] Randomization engine -- [x] Interactive TUI -- [x] Build system -- [x] Sample data - -### Phase 2: DNS Integration (In Progress) -- [ ] DNS UPDATE (RFC 2136) implementation -- [ ] TSIG authentication (RFC 2845) -- [ ] Zone file writer (BIND format) -- [ ] Test with real DNS servers - -### Phase 3: Advanced Features -- [ ] Configuration file support -- [ ] Scheduled fluctuation (Ada tasking) -- [ ] Logging system -- [ ] API/webhook triggers -- [ ] Ncurses-based enhanced TUI - -### Phase 4: Production Hardening -- [ ] bcrypt/Argon2 password hashing -- [ ] SPARK formal verification -- [ ] Security audit -- [ ] Unit test suite -- [ ] Performance optimization - -## 🐛 Known Issues - -1. **CSV Parser**: Simple implementation, doesn't handle quoted commas -2. **Demo Auth**: Uses placeholder hashes, not real crypto -3. **Chaos/Hesiod Classes**: Rarely supported by DNS servers -4. **No DNS Communication**: Cannot actually update servers yet - -## 📄 License - -[Specify your license here - MIT, GPL, etc.] - -## 🙏 Acknowledgments - -- RFCs 1034, 1035, 1876, 2136, 2845, 8482 -- Ada community for security-focused language design -- GNAT compiler team for excellent tooling - -## 📞 Contact - -[Your contact information or GitHub profile] - ---- - -## Fun Fact - -The "Quantum Server" concept is inspired by quantum superposition - your server simultaneously exists as an Intel Xeon in San Francisco AND an ARM processor in Tokyo. Schrödinger would approve! 🐱⚛️ - -**Remember:** With great power comes great responsibility. Use this tool ethically and legally. Always obtain proper authorization before modifying DNS infrastructure. diff --git a/hinfo_loc_fluctuator_ada/docs/ENTERPRISE_FEATURES.adoc b/hinfo_loc_fluctuator_ada/docs/ENTERPRISE_FEATURES.adoc new file mode 100644 index 0000000..eb69701 --- /dev/null +++ b/hinfo_loc_fluctuator_ada/docs/ENTERPRISE_FEATURES.adoc @@ -0,0 +1,756 @@ +== Enterprise Features Guide + +=== Overview + +The HINFO-LOC Fluctuator has been expanded into a comprehensive *DNS +Security and Infrastructure Management Platform* with enterprise-grade +features for zero-trust access, dynamic firewall control, and advanced +obfuscation. + +=== Table of Contents + +[arabic] +. link:#extended-dns-records[Extended DNS Records] +. link:#firewall-integration[Firewall Integration] +. link:#port-rotation[Port Rotation] +. link:#security-headers[Security Headers] +. link:#software-defined-perimeter[Software-Defined Perimeter] +. link:#protocol-management[Protocol Management] +. link:#service-scheduling[Service Scheduling] +. link:#configuration[Configuration] + +''''' + +=== Extended DNS Records + +==== Supported Record Types + +*Basic Address Records:* - `+A+` (IPv4) and `+AAAA+` (IPv6) with +protocol toggle - `+PTR+` (Reverse DNS) + +*Delegation and Aliasing:* - `+NS+` (Name Server) - `+CNAME+` (Canonical +Name) + +*Mail Records:* - `+MX+` (Mail Exchange) with time-based scheduling - +`+SPF+` (Sender Policy Framework) - `+DKIM+` (DomainKeys Identified +Mail) - `+DMARC+` (Domain-based Message Authentication) + +*Service Records:* - `+SRV+` (Service Location) with enable/disable +toggle - `+NAPTR+` (Naming Authority Pointer) + +*Security Records:* - `+CAA+` (Certification Authority Authorization) - +`+TLSA+` (DANE - DNS-based Authentication) - `+SSHFP+` (SSH Fingerprint) +- `+APL+` (Address Prefix List) for CIDR-based access control + +*DNSSEC:* - `+DS+` (Delegation Signer) - `+DNSKEY+` (DNS Public Key) - +`+NSEC+` / `+NSEC3+` (Next Secure) + +==== IPv4/IPv6 Protocol Toggle + +[source,ada] +---- +Set_IP_Protocol_Mode (Dual_Stack); -- Both IPv4 and IPv6 +Set_IP_Protocol_Mode (IPv4_Only); -- IPv4 only +Set_IP_Protocol_Mode (IPv6_Only); -- IPv6 only +Set_IP_Protocol_Mode (Disabled); -- Neither (diagnostic) +---- + +==== DNS Topology Modes + +Supported configurations: - *Standard*: Single primary, multiple +secondaries - *Split-Horizon*: Different views for internal/external - +*Primary-Primary*: Multi-master replication - *Hidden Primary*: Primary +not publicly visible - *Secondary-Only*: Read-only secondary - *Stealth +Secondary*: Secondary not listed in NS records + +==== AXFR Configuration + +[source,ini] +---- +[dns_topology] +mode=hidden_primary +axfr_enabled=true +axfr_tsig_required=true +allowed_transfer_ips=192.168.1.10/32,10.0.0.5/32 +---- + +''''' + +=== Firewall Integration + +==== Supported Firewall Backends + +* *firewalld* (Linux, recommended) +* *iptables* (Linux, direct) +* *nftables* (Linux, modern) +* *pf* (BSD) + +==== Time-Based Access Control + +Define maintenance windows with IP restrictions: + +[source,ada] +---- +type Maintenance_Window is record + Window : Time_Window; -- Start/End times + Description : "Weekly maintenance"; + Allowed_IPs : [192.168.1.0/24, 10.0.0.0/8]; + Ports : [22, 443, 8443]; +end record; +---- + +==== Stateful vs Stateless Rules + +* *Stateful*: Connection tracking (default) +* *Stateless*: No tracking (faster, less secure) + +==== Firewall Zones (firewalld) + +* Drop, Block, Public, External, DMZ, Work, Home, Internal, Trusted + +''''' + +=== Port Rotation + +==== SSH Port Rotation Strategies + +*1. Time-Based* (maintainers can calculate independently): + +[source,ini] +---- +[port_rotation] +service=ssh +strategy=time_based +base_port=10000 +port_range=1000 +rotation_interval=3600 # 1 hour +---- + +*Algorithm* (shared with maintainers): + +.... +current_port = base_port + (unix_timestamp / rotation_interval) % port_range +.... + +*Example*: If base=10000, range=1000, interval=3600: - At 00:00 UTC: +Port 10000 + (timestamp/3600) % 1000 - Maintainers can calculate this +offline + +*2. Pre-Shared Key* (algorithm with secret): + +.... +current_port = base_port + hash(PSK + datetime) % port_range +.... + +*3. Sequential*: 10000, 10001, 10002, … + +*4. Random*: Pseudorandom from pool + +==== Service Port Rotation + +Apply to any service: - SSH - Admin panels - Management interfaces - +Custom services + +''''' + +=== Security Headers + +==== Server Obfuscation Modes + +*1. Hidden*: Don’t send header at all + +[source,ini] +---- +[security_headers] +server_header_mode=hidden +---- + +*2. Obfuscated*: Send fake value + +[source,ini] +---- +server_header_mode=obfuscated +server_fake_value=Apache/2.4.41 (Unix) +randomize_fake=true +---- + +*3. Diagnostic*: Show real to authorized IPs only + +[source,ini] +---- +server_header_mode=diagnostic +server_real_value=nginx/1.21.0 +diagnostic_ips=192.168.1.100/32,10.0.0.5/32 +---- + +*4. Standard*: Show real to everyone (not recommended) + +==== X-Powered-By Obfuscation + +[source,ini] +---- +[security_headers] +powered_by_mode=hidden # Recommended +# OR +powered_by_mode=obfuscated +powered_by_fake=PHP/7.4.3 +---- + +==== Diagnostic Mode + +Access real stack info with secret token: + +.... +GET /diagnostics?token= +X-Diagnostic-Token: +.... + +Response (JSON): + +[source,json] +---- +{ + "server": "nginx/1.21.0", + "php_version": "8.1.2", + "framework": "Laravel 9.0", + "database": "PostgreSQL 14.1", + "modules": [...], + "security_headers": {...] +} +---- + +==== Standard Security Headers + +All modern security headers supported: - HSTS +(Strict-Transport-Security) - CSP (Content-Security-Policy) with nonces +- X-Frame-Options - X-Content-Type-Options - Referrer-Policy - +Permissions-Policy + +==== Experimental Headers + +* COEP (Cross-Origin-Embedder-Policy) +* COOP (Cross-Origin-Opener-Policy) +* CORP (Cross-Origin-Resource-Policy) +* Expect-CT (being deprecated) +* NEL (Network Error Logging) + +==== Integration with HINFO Records + +Keep server headers consistent with HINFO DNS records: + +[source,ada] +---- +Sync_With_HINFO( + Config => Security_Header_Set, + HINFO_CPU => "Intel-Xeon", + HINFO_OS => "Ubuntu-22.04" +); +---- + +Now both DNS and HTTP headers show consistent (fake) stack. + +''''' + +=== Software-Defined Perimeter (SDP) + +==== Zero-Trust Architecture + +Implements Cloud Security Alliance SDP specification: + +[arabic] +. *Default Deny*: All ports closed by default +. *Single Packet Authorization (SPA)*: Encrypted knock sequence +. *Identity-Based Access*: User + device authentication +. *Continuous Verification*: Periodic re-authentication +. *Micro-Segmentation*: Network isolation + +==== Single Packet Authorization (SPA) + +Encrypted authentication in single UDP packet: + +.... +[SPA Packet] → SDP Controller → Validates → Opens Firewall +.... + +*Encryption*: AES-256-GCM, ChaCha20-Poly1305 *HMAC*: SHA256, SHA512, +SHA3-256 + +==== Device Posture Validation + +Requirements before access: - OS version minimum - Antivirus running - +Firewall enabled - Disk encryption - Patch level current - Custom checks + +==== Trust Levels + +Progressive trust with continuous verification: 1. Untrusted (default) +2. Device Verified (certificate valid) 3. User Authenticated (MFA +passed) 4. Posture Valid (security checks passed) 5. Full Trust (all +requirements met) + +==== Access Policies + +[source,ada] +---- +type Access_Policy is record + Policy_Name : "Admin SSH Access"; + Required_Trust : Full_Trust; + Allowed_Users : "alice,bob"; + Allowed_Groups : "admins"; + Time_Restrictions : Weekdays_Business_Hours; + Source_CIDR : [192.168.1.0/24]; + Destination : "server.example.com"; + Ports : [22]; + Protocol : "tcp"; + Session_Duration : 3600; -- 1 hour + Continuous_Verify : true; -- Re-check every 5 min +end record; +---- + +==== Micro-Segmentation + +Network segments with isolation: + +.... +[Public DMZ] ←X→ [Application Tier] ←X→ [Database Tier] + ↓ (SDP only) ↓ (SDP only) ↓ (SDP only) + Allowed via policy enforcement +.... + +==== Session Management + +Active sessions with automatic expiry and firewall cleanup. + +''''' + +=== Protocol Management + +==== Recommended: NETCONF/RESTCONF/gNMI + +*NOT SNMP* (insecure, deprecated for new deployments) + +==== SNMP Configuration (if required) + +*⚠️ WARNINGS:* - SNMPv1/v2c send community strings in plaintext - ONLY +use SNMPv3 with encryption - Better: Use NETCONF, RESTCONF, or gNMI +instead + +[source,ini] +---- +[snmp] +enabled=false # Disabled by default +warn_insecure=true +require_v3_only=true + +[snmp_v3] +enabled=false +security_name=admin +auth_protocol=SHA-256 +auth_password= +priv_protocol=AES256 +priv_password= +allowed_ips=192.168.1.100/32 +read_only=true +---- + +==== NETCONF (Recommended) + +XML-based configuration over SSH: + +[source,ini] +---- +[netconf] +enabled=true +port=830 +ssh_host_key=/etc/ssh/ssh_host_rsa_key +capabilities=base-1.1,candidate,confirmed-commit,validate +auth_method=publickey +require_mfa=true +allowed_ips=192.168.1.0/24 +max_sessions=10 +session_timeout=600 +---- + +==== RESTCONF (Recommended) + +RESTful API over HTTPS: + +[source,ini] +---- +[restconf] +enabled=true +port=443 +base_path=/restconf +auth_method=client_certificate +tls_version=1.3 +certificate=/etc/ssl/server.crt +private_key=/etc/ssl/server.key +client_ca=/etc/ssl/client-ca.crt +rate_limit=100 # requests per minute +accept_json=true +---- + +==== gNMI (Modern Alternative) + +gRPC-based management: + +[source,ini] +---- +[gnmi] +enabled=true +port=9339 +tls_enabled=true +certificate=/etc/ssl/gnmi.crt +private_key=/etc/ssl/gnmi.key +encoding=JSON_IETF +subscribe=true # Streaming telemetry +get_enabled=true +set_enabled=false # Read-only +---- + +==== Prometheus/OpenMetrics + +Metrics export: + +[source,ini] +---- +[metrics] +enabled=true +protocol=prometheus +port=9090 +metrics_path=/metrics +auth_required=true +auth_token= +client_certs=true +rate_limit=60 +---- + +''''' + +=== Service Scheduling + +==== Time-Based Service Availability + +Open services only during specific windows: + +==== MX (Mail) Scheduling + +Accept mail only during business hours: + +[source,ini] +---- +[service_schedule_mx] +enabled=true +service=smtp +port=25 +protocol=tcp +windows=weekdays:08:00-18:00,saturday:09:00-13:00 +randomized=false +---- + +==== RSS Feed Scheduling + +Make RSS available only at intervals: + +[source,ini] +---- +[service_schedule_rss] +enabled=true +service=http +port=80 +path=/rss +windows=hourly:00-05 # First 5 minutes of every hour +randomized=true # Add random offset +---- + +==== NNTP Scheduling + +News server with randomized access: + +[source,ini] +---- +[service_schedule_nntp] +enabled=true +service=nntp +port=119 +protocol=tcp +randomized=true +random_window_duration=300 # 5 minutes +random_interval=3600 # Every hour, random 5-min window +---- + +==== Why Schedule Services? + +*Security Benefits:* 1. Reduced attack surface (service not always +available) 2. Makes scanning harder (port appears closed most of time) +3. Deception value (appears misconfigured to attackers) + +*Use Cases:* - Honeypot obfuscation - Maintenance windows - Rate +limiting - Resource management + +''''' + +=== Configuration + +==== Configuration Hierarchy + +[arabic] +. *Simple Config* (`+config.ini+`) - Basic settings +. *Master Config* (`+master_config.yaml+`) - Enterprise features +. *Runtime Overrides* - API or command-line + +==== Deployment Profiles + +*Development*: - All features enabled - Verbose logging - Diagnostics +available - Insecure protocols allowed (for testing) + +*Staging*: - Production-like - Testing features enabled - Moderate +logging + +*Production*: - Maximum security - Minimal exposure - Audit logging - +Insecure protocols disabled + +*Honeypot*: - Deception-focused - Fluctuation enabled - Service +scheduling active - Extensive logging + +*Research*: - Experimental features - All protocols enabled - Detailed +metrics + +==== Example Master Config + +[source,yaml] +---- +deployment: + mode: production + environment: public_internet + instance_name: prod-dns-01 + +dns: + topology: hidden_primary + ip_protocol_mode: dual_stack + dnssec_enabled: false + +fluctuation: + hinfo_enabled: true + loc_enabled: true + quantum_server_mode: true + +firewall: + backend: firewalld + port_rotation_enabled: true + ssh_port_rotation: true + +security_headers: + server_header_mode: obfuscated + powered_by_mode: hidden + diagnostic_mode_enabled: true + hsts_enabled: true + csp_enabled: true + +sdp: + enabled: true + spa_encryption: AES_256_GCM + default_deny: true + continuous_verify: true + +protocols: + snmp_allowed: false + netconf_preferred: true + restconf_enabled: true + gnmi_enabled: true + +service_scheduling: + mx_scheduled: false + ssh_port_rotation: true + +logging: + audit_logging: true + security_logging: true + syslog_server: syslog.example.com +---- + +==== Validation + +Configuration is validated on load: + +.... +✓ Security posture: Strong +✗ Warning: SNMPv2c enabled (insecure) +✓ Firewall: Configured correctly +✓ SDP: Zero-trust enabled +! Note: Consider enabling DNSSEC +.... + +''''' + +=== Integration Examples + +==== Example 1: Public Web Server with SDP + +.... +1. Client requests access via SPA packet +2. SDP validates: user + device + posture +3. Firewall opens port 443 for client IP only +4. HTTPS connection established +5. Security headers sent (obfuscated) +6. After session timeout, firewall closes +.... + +==== Example 2: Honeypot with Full Deception + +.... +DNS Records: +- HINFO: Changes every hour (random CPU/OS) +- LOC: Changes every 30 min (random location) +- MX: Only accepts mail 9am-5pm weekdays +- SSH: Port rotates every 2 hours (10000-10999) + +Security Headers: +- Server: Randomized (Apache, nginx, IIS, etc.) +- X-Powered-By: Hidden + +Result: Attacker sees inconsistent, unstable target +.... + +==== Example 3: Secure Admin Access + +.... +SSH Access: +- Port rotates every hour (time-based algorithm) +- SDP required (user + device authentication) +- Firewall only opens during maintenance windows +- Source IP must be in approved CIDR +- Continuous posture verification + +Maintainers: +- Calculate current SSH port offline +- Send SPA packet +- Port opens for 1 hour +- SSH as normal +.... + +''''' + +=== Best Practices + +==== Security + +[arabic] +. *Always use SDP* for sensitive services +. *Disable SNMPv1/v2c* - use NETCONF or gNMI +. *Enable DNSSEC* for production +. *Use time-based port rotation* for admin access +. *Obfuscate all server headers* +. *Enable audit logging* + +==== Performance + +[arabic] +. *Use stateful firewall* for normal traffic +. *Use stateless firewall* for high-performance scenarios +. *Limit service scheduling* to non-critical services +. *Cache DNS records* appropriately + +==== Operational + +[arabic] +. *Test in staging* before production +. *Document maintenance windows* +. *Keep emergency recovery config* handy +. *Monitor SDP session logs* +. *Regular security audits* + +''''' + +=== Troubleshooting + +==== Port Rotation + +*Problem*: Can’t SSH after port rotation + +*Solution*: Calculate current port: + +[source,python] +---- +import time +base_port = 10000 +rotation_interval = 3600 # 1 hour +port_range = 1000 + +current_port = base_port + (int(time.time()) // rotation_interval) % port_range +print(f"Current SSH port: {current_port}") +---- + +==== SDP Access + +*Problem*: SPA packet not opening firewall + +*Check*: 1. Correct shared key? 2. Clock synchronized (NTP)? 3. Client +IP in allowed CIDR? 4. Device posture valid? 5. User authenticated? + +==== Service Scheduling + +*Problem*: Service not available during window + +*Check*: 1. Correct timezone configured? 2. Firewall rules applied? 3. +Service actually running? 4. Check logs for schedule evaluation + +''''' + +=== Security Considerations + +==== Threats Mitigated + +✅ Port scanning (ports rotate/close) ✅ Service fingerprinting (headers +obfuscated) ✅ Geographic tracking (LOC fluctuates) ✅ Stack +fingerprinting (HINFO fluctuates) ✅ Unauthorized access (SDP + +firewall) ✅ Timing attacks (constant-time operations) ✅ Replay attacks +(SPA nonces) + +==== Threats NOT Mitigated + +❌ DDoS attacks (need separate DDoS protection) ❌ Application-level +vulnerabilities ❌ Social engineering ❌ Insider threats (partial +mitigation via audit logs) ❌ Zero-day exploits + +==== Compliance + +Features support: - NIST Zero Trust Architecture (SP 800-207) - CSA +Software-Defined Perimeter - PCI DSS (firewall + access control +requirements) - HIPAA (access controls + audit logging) - SOC 2 +(security controls + monitoring) + +''''' + +=== Migration Guide + +==== From Simple Config + +[arabic] +. Install enterprise modules +. Run migration tool: +`+migrate_config simple_config.ini master_config.yaml+` +. Review generated configuration +. Test in staging +. Deploy to production + +==== Incremental Adoption + +Don’t enable everything at once: + +*Phase 1*: Extended DNS records *Phase 2*: Firewall integration *Phase +3*: Security headers *Phase 4*: Port rotation *Phase 5*: Service +scheduling *Phase 6*: SDP (zero-trust) *Phase 7*: Protocol management + +''''' + +=== Support and Resources + +* *Documentation*: See `+docs/+` directory +* *Examples*: See `+examples/+` directory +* *Issue Tracker*: [GitHub Issues] +* *Security*: security@example.com + +''''' + +*Remember*: With great power comes great responsibility. Test thoroughly +before production deployment! diff --git a/hinfo_loc_fluctuator_ada/docs/ENTERPRISE_FEATURES.md b/hinfo_loc_fluctuator_ada/docs/ENTERPRISE_FEATURES.md deleted file mode 100644 index d332b0c..0000000 --- a/hinfo_loc_fluctuator_ada/docs/ENTERPRISE_FEATURES.md +++ /dev/null @@ -1,773 +0,0 @@ -# Enterprise Features Guide - -## Overview - -The HINFO-LOC Fluctuator has been expanded into a comprehensive **DNS Security and Infrastructure Management Platform** with enterprise-grade features for zero-trust access, dynamic firewall control, and advanced obfuscation. - -## Table of Contents - -1. [Extended DNS Records](#extended-dns-records) -2. [Firewall Integration](#firewall-integration) -3. [Port Rotation](#port-rotation) -4. [Security Headers](#security-headers) -5. [Software-Defined Perimeter](#software-defined-perimeter) -6. [Protocol Management](#protocol-management) -7. [Service Scheduling](#service-scheduling) -8. [Configuration](#configuration) - ---- - -## Extended DNS Records - -### Supported Record Types - -**Basic Address Records:** -- `A` (IPv4) and `AAAA` (IPv6) with protocol toggle -- `PTR` (Reverse DNS) - -**Delegation and Aliasing:** -- `NS` (Name Server) -- `CNAME` (Canonical Name) - -**Mail Records:** -- `MX` (Mail Exchange) with time-based scheduling -- `SPF` (Sender Policy Framework) -- `DKIM` (DomainKeys Identified Mail) -- `DMARC` (Domain-based Message Authentication) - -**Service Records:** -- `SRV` (Service Location) with enable/disable toggle -- `NAPTR` (Naming Authority Pointer) - -**Security Records:** -- `CAA` (Certification Authority Authorization) -- `TLSA` (DANE - DNS-based Authentication) -- `SSHFP` (SSH Fingerprint) -- `APL` (Address Prefix List) for CIDR-based access control - -**DNSSEC:** -- `DS` (Delegation Signer) -- `DNSKEY` (DNS Public Key) -- `NSEC` / `NSEC3` (Next Secure) - -### IPv4/IPv6 Protocol Toggle - -```ada -Set_IP_Protocol_Mode (Dual_Stack); -- Both IPv4 and IPv6 -Set_IP_Protocol_Mode (IPv4_Only); -- IPv4 only -Set_IP_Protocol_Mode (IPv6_Only); -- IPv6 only -Set_IP_Protocol_Mode (Disabled); -- Neither (diagnostic) -``` - -### DNS Topology Modes - -Supported configurations: -- **Standard**: Single primary, multiple secondaries -- **Split-Horizon**: Different views for internal/external -- **Primary-Primary**: Multi-master replication -- **Hidden Primary**: Primary not publicly visible -- **Secondary-Only**: Read-only secondary -- **Stealth Secondary**: Secondary not listed in NS records - -### AXFR Configuration - -```ini -[dns_topology] -mode=hidden_primary -axfr_enabled=true -axfr_tsig_required=true -allowed_transfer_ips=192.168.1.10/32,10.0.0.5/32 -``` - ---- - -## Firewall Integration - -### Supported Firewall Backends - -- **firewalld** (Linux, recommended) -- **iptables** (Linux, direct) -- **nftables** (Linux, modern) -- **pf** (BSD) - -### Time-Based Access Control - -Define maintenance windows with IP restrictions: - -```ada -type Maintenance_Window is record - Window : Time_Window; -- Start/End times - Description : "Weekly maintenance"; - Allowed_IPs : [192.168.1.0/24, 10.0.0.0/8]; - Ports : [22, 443, 8443]; -end record; -``` - -### Stateful vs Stateless Rules - -- **Stateful**: Connection tracking (default) -- **Stateless**: No tracking (faster, less secure) - -### Firewall Zones (firewalld) - -- Drop, Block, Public, External, DMZ, Work, Home, Internal, Trusted - ---- - -## Port Rotation - -### SSH Port Rotation Strategies - -**1. Time-Based** (maintainers can calculate independently): -```ini -[port_rotation] -service=ssh -strategy=time_based -base_port=10000 -port_range=1000 -rotation_interval=3600 # 1 hour -``` - -**Algorithm** (shared with maintainers): -``` -current_port = base_port + (unix_timestamp / rotation_interval) % port_range -``` - -**Example**: If base=10000, range=1000, interval=3600: -- At 00:00 UTC: Port 10000 + (timestamp/3600) % 1000 -- Maintainers can calculate this offline - -**2. Pre-Shared Key** (algorithm with secret): -``` -current_port = base_port + hash(PSK + datetime) % port_range -``` - -**3. Sequential**: 10000, 10001, 10002, ... - -**4. Random**: Pseudorandom from pool - -### Service Port Rotation - -Apply to any service: -- SSH -- Admin panels -- Management interfaces -- Custom services - ---- - -## Security Headers - -### Server Obfuscation Modes - -**1. Hidden**: Don't send header at all -```ini -[security_headers] -server_header_mode=hidden -``` - -**2. Obfuscated**: Send fake value -```ini -server_header_mode=obfuscated -server_fake_value=Apache/2.4.41 (Unix) -randomize_fake=true -``` - -**3. Diagnostic**: Show real to authorized IPs only -```ini -server_header_mode=diagnostic -server_real_value=nginx/1.21.0 -diagnostic_ips=192.168.1.100/32,10.0.0.5/32 -``` - -**4. Standard**: Show real to everyone (not recommended) - -### X-Powered-By Obfuscation - -```ini -[security_headers] -powered_by_mode=hidden # Recommended -# OR -powered_by_mode=obfuscated -powered_by_fake=PHP/7.4.3 -``` - -### Diagnostic Mode - -Access real stack info with secret token: -``` -GET /diagnostics?token= -X-Diagnostic-Token: -``` - -Response (JSON): -```json -{ - "server": "nginx/1.21.0", - "php_version": "8.1.2", - "framework": "Laravel 9.0", - "database": "PostgreSQL 14.1", - "modules": [...], - "security_headers": {...] -} -``` - -### Standard Security Headers - -All modern security headers supported: -- HSTS (Strict-Transport-Security) -- CSP (Content-Security-Policy) with nonces -- X-Frame-Options -- X-Content-Type-Options -- Referrer-Policy -- Permissions-Policy - -### Experimental Headers - -- COEP (Cross-Origin-Embedder-Policy) -- COOP (Cross-Origin-Opener-Policy) -- CORP (Cross-Origin-Resource-Policy) -- Expect-CT (being deprecated) -- NEL (Network Error Logging) - -### Integration with HINFO Records - -Keep server headers consistent with HINFO DNS records: - -```ada -Sync_With_HINFO( - Config => Security_Header_Set, - HINFO_CPU => "Intel-Xeon", - HINFO_OS => "Ubuntu-22.04" -); -``` - -Now both DNS and HTTP headers show consistent (fake) stack. - ---- - -## Software-Defined Perimeter (SDP) - -### Zero-Trust Architecture - -Implements Cloud Security Alliance SDP specification: - -1. **Default Deny**: All ports closed by default -2. **Single Packet Authorization (SPA)**: Encrypted knock sequence -3. **Identity-Based Access**: User + device authentication -4. **Continuous Verification**: Periodic re-authentication -5. **Micro-Segmentation**: Network isolation - -### Single Packet Authorization (SPA) - -Encrypted authentication in single UDP packet: - -``` -[SPA Packet] → SDP Controller → Validates → Opens Firewall -``` - -**Encryption**: AES-256-GCM, ChaCha20-Poly1305 -**HMAC**: SHA256, SHA512, SHA3-256 - -### Device Posture Validation - -Requirements before access: -- OS version minimum -- Antivirus running -- Firewall enabled -- Disk encryption -- Patch level current -- Custom checks - -### Trust Levels - -Progressive trust with continuous verification: -1. Untrusted (default) -2. Device Verified (certificate valid) -3. User Authenticated (MFA passed) -4. Posture Valid (security checks passed) -5. Full Trust (all requirements met) - -### Access Policies - -```ada -type Access_Policy is record - Policy_Name : "Admin SSH Access"; - Required_Trust : Full_Trust; - Allowed_Users : "alice,bob"; - Allowed_Groups : "admins"; - Time_Restrictions : Weekdays_Business_Hours; - Source_CIDR : [192.168.1.0/24]; - Destination : "server.example.com"; - Ports : [22]; - Protocol : "tcp"; - Session_Duration : 3600; -- 1 hour - Continuous_Verify : true; -- Re-check every 5 min -end record; -``` - -### Micro-Segmentation - -Network segments with isolation: - -``` -[Public DMZ] ←X→ [Application Tier] ←X→ [Database Tier] - ↓ (SDP only) ↓ (SDP only) ↓ (SDP only) - Allowed via policy enforcement -``` - -### Session Management - -Active sessions with automatic expiry and firewall cleanup. - ---- - -## Protocol Management - -### Recommended: NETCONF/RESTCONF/gNMI - -**NOT SNMP** (insecure, deprecated for new deployments) - -### SNMP Configuration (if required) - -**⚠️ WARNINGS:** -- SNMPv1/v2c send community strings in plaintext -- ONLY use SNMPv3 with encryption -- Better: Use NETCONF, RESTCONF, or gNMI instead - -```ini -[snmp] -enabled=false # Disabled by default -warn_insecure=true -require_v3_only=true - -[snmp_v3] -enabled=false -security_name=admin -auth_protocol=SHA-256 -auth_password= -priv_protocol=AES256 -priv_password= -allowed_ips=192.168.1.100/32 -read_only=true -``` - -### NETCONF (Recommended) - -XML-based configuration over SSH: - -```ini -[netconf] -enabled=true -port=830 -ssh_host_key=/etc/ssh/ssh_host_rsa_key -capabilities=base-1.1,candidate,confirmed-commit,validate -auth_method=publickey -require_mfa=true -allowed_ips=192.168.1.0/24 -max_sessions=10 -session_timeout=600 -``` - -### RESTCONF (Recommended) - -RESTful API over HTTPS: - -```ini -[restconf] -enabled=true -port=443 -base_path=/restconf -auth_method=client_certificate -tls_version=1.3 -certificate=/etc/ssl/server.crt -private_key=/etc/ssl/server.key -client_ca=/etc/ssl/client-ca.crt -rate_limit=100 # requests per minute -accept_json=true -``` - -### gNMI (Modern Alternative) - -gRPC-based management: - -```ini -[gnmi] -enabled=true -port=9339 -tls_enabled=true -certificate=/etc/ssl/gnmi.crt -private_key=/etc/ssl/gnmi.key -encoding=JSON_IETF -subscribe=true # Streaming telemetry -get_enabled=true -set_enabled=false # Read-only -``` - -### Prometheus/OpenMetrics - -Metrics export: - -```ini -[metrics] -enabled=true -protocol=prometheus -port=9090 -metrics_path=/metrics -auth_required=true -auth_token= -client_certs=true -rate_limit=60 -``` - ---- - -## Service Scheduling - -### Time-Based Service Availability - -Open services only during specific windows: - -### MX (Mail) Scheduling - -Accept mail only during business hours: - -```ini -[service_schedule_mx] -enabled=true -service=smtp -port=25 -protocol=tcp -windows=weekdays:08:00-18:00,saturday:09:00-13:00 -randomized=false -``` - -### RSS Feed Scheduling - -Make RSS available only at intervals: - -```ini -[service_schedule_rss] -enabled=true -service=http -port=80 -path=/rss -windows=hourly:00-05 # First 5 minutes of every hour -randomized=true # Add random offset -``` - -### NNTP Scheduling - -News server with randomized access: - -```ini -[service_schedule_nntp] -enabled=true -service=nntp -port=119 -protocol=tcp -randomized=true -random_window_duration=300 # 5 minutes -random_interval=3600 # Every hour, random 5-min window -``` - -### Why Schedule Services? - -**Security Benefits:** -1. Reduced attack surface (service not always available) -2. Makes scanning harder (port appears closed most of time) -3. Deception value (appears misconfigured to attackers) - -**Use Cases:** -- Honeypot obfuscation -- Maintenance windows -- Rate limiting -- Resource management - ---- - -## Configuration - -### Configuration Hierarchy - -1. **Simple Config** (`config.ini`) - Basic settings -2. **Master Config** (`master_config.yaml`) - Enterprise features -3. **Runtime Overrides** - API or command-line - -### Deployment Profiles - -**Development**: -- All features enabled -- Verbose logging -- Diagnostics available -- Insecure protocols allowed (for testing) - -**Staging**: -- Production-like -- Testing features enabled -- Moderate logging - -**Production**: -- Maximum security -- Minimal exposure -- Audit logging -- Insecure protocols disabled - -**Honeypot**: -- Deception-focused -- Fluctuation enabled -- Service scheduling active -- Extensive logging - -**Research**: -- Experimental features -- All protocols enabled -- Detailed metrics - -### Example Master Config - -```yaml -deployment: - mode: production - environment: public_internet - instance_name: prod-dns-01 - -dns: - topology: hidden_primary - ip_protocol_mode: dual_stack - dnssec_enabled: false - -fluctuation: - hinfo_enabled: true - loc_enabled: true - quantum_server_mode: true - -firewall: - backend: firewalld - port_rotation_enabled: true - ssh_port_rotation: true - -security_headers: - server_header_mode: obfuscated - powered_by_mode: hidden - diagnostic_mode_enabled: true - hsts_enabled: true - csp_enabled: true - -sdp: - enabled: true - spa_encryption: AES_256_GCM - default_deny: true - continuous_verify: true - -protocols: - snmp_allowed: false - netconf_preferred: true - restconf_enabled: true - gnmi_enabled: true - -service_scheduling: - mx_scheduled: false - ssh_port_rotation: true - -logging: - audit_logging: true - security_logging: true - syslog_server: syslog.example.com -``` - -### Validation - -Configuration is validated on load: - -``` -✓ Security posture: Strong -✗ Warning: SNMPv2c enabled (insecure) -✓ Firewall: Configured correctly -✓ SDP: Zero-trust enabled -! Note: Consider enabling DNSSEC -``` - ---- - -## Integration Examples - -### Example 1: Public Web Server with SDP - -``` -1. Client requests access via SPA packet -2. SDP validates: user + device + posture -3. Firewall opens port 443 for client IP only -4. HTTPS connection established -5. Security headers sent (obfuscated) -6. After session timeout, firewall closes -``` - -### Example 2: Honeypot with Full Deception - -``` -DNS Records: -- HINFO: Changes every hour (random CPU/OS) -- LOC: Changes every 30 min (random location) -- MX: Only accepts mail 9am-5pm weekdays -- SSH: Port rotates every 2 hours (10000-10999) - -Security Headers: -- Server: Randomized (Apache, nginx, IIS, etc.) -- X-Powered-By: Hidden - -Result: Attacker sees inconsistent, unstable target -``` - -### Example 3: Secure Admin Access - -``` -SSH Access: -- Port rotates every hour (time-based algorithm) -- SDP required (user + device authentication) -- Firewall only opens during maintenance windows -- Source IP must be in approved CIDR -- Continuous posture verification - -Maintainers: -- Calculate current SSH port offline -- Send SPA packet -- Port opens for 1 hour -- SSH as normal -``` - ---- - -## Best Practices - -### Security - -1. **Always use SDP** for sensitive services -2. **Disable SNMPv1/v2c** - use NETCONF or gNMI -3. **Enable DNSSEC** for production -4. **Use time-based port rotation** for admin access -5. **Obfuscate all server headers** -6. **Enable audit logging** - -### Performance - -1. **Use stateful firewall** for normal traffic -2. **Use stateless firewall** for high-performance scenarios -3. **Limit service scheduling** to non-critical services -4. **Cache DNS records** appropriately - -### Operational - -1. **Test in staging** before production -2. **Document maintenance windows** -3. **Keep emergency recovery config** handy -4. **Monitor SDP session logs** -5. **Regular security audits** - ---- - -## Troubleshooting - -### Port Rotation - -**Problem**: Can't SSH after port rotation - -**Solution**: Calculate current port: -```python -import time -base_port = 10000 -rotation_interval = 3600 # 1 hour -port_range = 1000 - -current_port = base_port + (int(time.time()) // rotation_interval) % port_range -print(f"Current SSH port: {current_port}") -``` - -### SDP Access - -**Problem**: SPA packet not opening firewall - -**Check**: -1. Correct shared key? -2. Clock synchronized (NTP)? -3. Client IP in allowed CIDR? -4. Device posture valid? -5. User authenticated? - -### Service Scheduling - -**Problem**: Service not available during window - -**Check**: -1. Correct timezone configured? -2. Firewall rules applied? -3. Service actually running? -4. Check logs for schedule evaluation - ---- - -## Security Considerations - -### Threats Mitigated - -✅ Port scanning (ports rotate/close) -✅ Service fingerprinting (headers obfuscated) -✅ Geographic tracking (LOC fluctuates) -✅ Stack fingerprinting (HINFO fluctuates) -✅ Unauthorized access (SDP + firewall) -✅ Timing attacks (constant-time operations) -✅ Replay attacks (SPA nonces) - -### Threats NOT Mitigated - -❌ DDoS attacks (need separate DDoS protection) -❌ Application-level vulnerabilities -❌ Social engineering -❌ Insider threats (partial mitigation via audit logs) -❌ Zero-day exploits - -### Compliance - -Features support: -- NIST Zero Trust Architecture (SP 800-207) -- CSA Software-Defined Perimeter -- PCI DSS (firewall + access control requirements) -- HIPAA (access controls + audit logging) -- SOC 2 (security controls + monitoring) - ---- - -## Migration Guide - -### From Simple Config - -1. Install enterprise modules -2. Run migration tool: `migrate_config simple_config.ini master_config.yaml` -3. Review generated configuration -4. Test in staging -5. Deploy to production - -### Incremental Adoption - -Don't enable everything at once: - -**Phase 1**: Extended DNS records -**Phase 2**: Firewall integration -**Phase 3**: Security headers -**Phase 4**: Port rotation -**Phase 5**: Service scheduling -**Phase 6**: SDP (zero-trust) -**Phase 7**: Protocol management - ---- - -## Support and Resources - -- **Documentation**: See `docs/` directory -- **Examples**: See `examples/` directory -- **Issue Tracker**: [GitHub Issues] -- **Security**: security@example.com - ---- - -**Remember**: With great power comes great responsibility. Test thoroughly before production deployment! diff --git a/hinfo_loc_fluctuator_ada/docs/USE_CASES.adoc b/hinfo_loc_fluctuator_ada/docs/USE_CASES.adoc new file mode 100644 index 0000000..8eb5b4a --- /dev/null +++ b/hinfo_loc_fluctuator_ada/docs/USE_CASES.adoc @@ -0,0 +1,543 @@ +== HINFO-LOC Fluctuator - Detailed Use Cases + +This document provides comprehensive scenarios for using the HINFO-LOC +Fluctuator in various security, research, and educational contexts. + +=== Table of Contents + +[arabic] +. link:#honeypot-deployment-obfuscation[Honeypot Deployment Obfuscation] +. link:#incident-response-and-deception[Incident Response and Deception] +. link:#security-research-and-education[Security Research and Education] +. link:#privacy-enhancement[Privacy Enhancement] +. link:#testing-and-development[Testing and Development] +. link:#quantum-server-demonstrations[Quantum Server Demonstrations] + +''''' + +=== Honeypot Deployment Obfuscation + +==== Scenario: Moving Honeypot Illusion + +*Objective:* Make honeypots appear to physically move locations to +confuse attackers and extend engagement time. + +*Setup:* + +[source,bash] +---- +# Configure honeypot DNS records +honeypot.example.com. IN HINFO "Intel-Xeon" "Ubuntu-22.04-LTS" +honeypot.example.com. IN LOC 37.7749 N 122.4194 W 16m +---- + +*Implementation:* + +[arabic] +. *Deploy* multiple honeypots at different locations +. *Configure* HINFO-LOC Fluctuator to randomize records every 6-24 hours +. *Monitor* attacker behavior as apparent location/hardware changes +. *Analyze* whether attackers notice and how they react + +*Expected Attacker Behavior:* + +* Initial reconnaissance shows Ubuntu server in San Francisco +* Returns 12 hours later: now appears to be Windows in London +* Confusion: "`Did I attack the right server? Did they migrate?`" +* Extended engagement as attacker investigates changes + +*Benefits:* + +* Increases time attackers spend on honeypots +* Reveals attacker persistence and methodology +* Makes honeypot detection harder (inconsistent fingerprints) +* Provides rich behavioral data + +*Security Considerations:* + +* Ensure actual honeypot services match apparent OS +* Coordinate changes across multiple DNS record types +* Log all fluctuations for correlation with attack patterns + +''''' + +=== Incident Response and Deception + +==== Scenario: Active Response to Ongoing Attack + +*Objective:* Confuse and misdirect attackers during active incident +response. + +*Setup:* + +When attack detected on `+server.company.com+`: + +*Phase 1: Misdirection* + +.... +# Make server appear to be in different location +server.company.com. LOC -33.8688 S 151.2093 E 58m # Sydney +.... + +*Phase 2: Hardware Change* + +.... +# Make server appear to have different architecture +server.company.com. HINFO "ARM-Cortex-A72" "Alpine-Linux" +.... + +*Phase 3: "`Migration`"* + +.... +# Suggest server moved to cloud provider +server.company.com. LOC 47.6062 N 122.3321 W 56m # AWS us-west-2 +server.company.com. HINFO "Intel-Xeon" "Amazon-Linux-2" +.... + +*Implementation Steps:* + +[arabic] +. *Detect* attack in progress (IDS/IPS alerts) +. *Isolate* real server from network +. *Deploy* honeypot with same IP +. *Fluctuate* DNS records to suggest instability +. *Monitor* attacker adaptation strategies +. *Collect* threat intelligence + +*Deception Tactics:* + +* Rapid location changes suggest panic/misconfiguration +* OS changes suggest desperate remediation attempts +* Creates doubt in attacker’s reconnaissance data +* Buys time for forensics and containment + +*Metrics to Track:* + +* Time until attacker abandons target +* Number of re-reconnaissance attempts +* Changes in attack methodology +* Tools/techniques revealed during confusion + +''''' + +=== Security Research and Education + +==== Scenario: Teaching DNS Reconnaissance Countermeasures + +*Objective:* Demonstrate how DNS records can be weaponized for both +offense and defense. + +*Lab Exercise:* + +*Part 1: Passive Reconnaissance* + +Students query HINFO/LOC records: + +[source,bash] +---- +dig honeypot.lab.edu HINFO +dig honeypot.lab.edu LOC +---- + +Initial results: + +.... +honeypot.lab.edu. HINFO "Intel-Pentium-4" "Windows-XP-SP3" +honeypot.lab.edu. LOC 42.3601 N 71.0589 W 43m # Boston +.... + +*Part 2: Temporal Analysis* + +Students repeat queries 1 hour later: + +.... +honeypot.lab.edu. HINFO "AMD-EPYC" "Ubuntu-Server-23.04" +honeypot.lab.edu. LOC 51.5074 N 0.1278 W 11m # London +.... + +*Learning Objectives:* + +[arabic] +. DNS records can lie +. Temporal consistency is not guaranteed +. Need multiple information sources for fingerprinting +. Automated tools can be deceived + +*Discussion Questions:* + +* How does this affect OSINT workflows? +* What other DNS records could be manipulated? +* How would you detect this deception? +* Legal and ethical implications? + +*Advanced Exercise:* + +Students implement detection: + +[source,python] +---- +# Detect fluctuating records +def detect_fluctuation(domain, samples=10, interval=300): + """Query domain every 5 minutes, detect changes""" + records = [] + for i in range(samples): + hinfo = query_hinfo(domain) + loc = query_loc(domain) + records.append((hinfo, loc)) + time.sleep(interval) + + # Analyze consistency + return analyze_variance(records) +---- + +''''' + +=== Privacy Enhancement + +==== Scenario: Obscuring Public Server Location + +*Objective:* Prevent location-based targeting of public services while +maintaining functionality. + +*Challenge:* + +Your organization runs public services (web, email, etc.) and wants to: +- Prevent attackers from knowing physical location - Avoid targeted +physical attacks on data centers - Maintain service availability - +Comply with data sovereignty requirements + +*Solution:* + +*Multi-Layer Approach:* + +[arabic] +. *Anycast* for actual routing (standard practice) +. *HINFO/LOC Fluctuation* for reconnaissance obfuscation +. *Consistent CNAME* records for service discovery + +*Implementation:* + +[source,bash] +---- +# Service discovery (consistent) +www.example.com. CNAME frontend.cdn.example.com. + +# Frontend servers (fluctuating) +frontend.cdn.example.com. HINFO +frontend.cdn.example.com. LOC + +# Actual servers (not in DNS) +internal-node-01.example.com. A 10.x.x.x # Private IP +---- + +*Fluctuation Schedule:* + +* Change HINFO: Every 4-8 hours +* Change LOC: Every 2-6 hours +* Avoid patterns (randomize intervals) + +*Benefits:* + +* Reconnaissance returns different data each time +* Physical location obscured +* Automated scanners confused +* Manual analysis more difficult + +*Limitations:* + +* Doesn’t prevent direct IP geolocation +* Services must actually be distributed for full effectiveness +* Privacy benefit is defense-in-depth, not primary protection + +''''' + +=== Testing and Development + +==== Scenario: Multi-Region Load Balancer Testing + +*Objective:* Test application behavior with servers in different +geographic regions without deploying globally. + +*Setup:* + +Developer wants to test how application handles: - Different time zones +- Various OS configurations - Geographic distribution - Latency +variations + +*Traditional Approach:* + +Deploy to 10 regions = $$$ expensive + +*Fluctuator Approach:* + +[arabic] +. Deploy to ONE region +. Use HINFO-LOC Fluctuator to simulate others +. Test application logic that queries DNS + +*Test Scenarios:* + +*Scenario A: Time Zone Handling* + +.... +# Simulate Tokyo server +app-server.dev. LOC 35.6762 N 139.6503 E 40m +# Test: Does app correctly handle JST time zone? +.... + +*Scenario B: OS-Specific Bugs* + +.... +# Simulate Windows deployment +app-server.dev. HINFO "Intel-Xeon" "Windows-Server-2022" +# Test: Does monitoring assume Linux-specific metrics? +.... + +*Scenario C: Geographic Distribution* + +.... +# Simulate multi-region deployment +node1.dev. LOC 37.7749 N 122.4194 W 16m # San Francisco +node2.dev. LOC 51.5074 N 0.1278 W 11m # London +node3.dev. LOC 1.3521 N 103.8198 E 15m # Singapore +# Test: Does load balancer make sane decisions? +.... + +*Benefits:* + +* Rapid testing without infrastructure costs +* Identify logic bugs before deployment +* Validate monitoring and alerting +* Test failover scenarios + +''''' + +=== Quantum Server Demonstrations + +==== Scenario: Conference Talk / Marketing + +*Objective:* Demonstrate "`quantum`" server concept for +entertainment/education. + +*Setup for Live Demo:* + +[source,bash] +---- +# The "Quantum Server" exists in superposition +quantum.demo.com. HINFO +quantum.demo.com. LOC +---- + +*Demo Script:* + +*Slide 1: Classical Server* + +.... +$ dig quantum.demo.com HINFO +quantum.demo.com. HINFO "Intel-Xeon" "Ubuntu-22.04" + +$ dig quantum.demo.com LOC +quantum.demo.com. LOC 37.7749 N 122.4194 W 16m +.... + +"`This is a classical server. It exists in one place, with one +configuration.`" + +*Slide 2: Quantum Observation* + +Wait 30 seconds, query again: + +.... +$ dig quantum.demo.com HINFO +quantum.demo.com. HINFO "ARM-Cortex-A72" "Alpine-Linux" + +$ dig quantum.demo.com LOC +quantum.demo.com. LOC 51.5074 N 0.1278 W 11m +.... + +"`Upon observation, the quantum state collapses differently! The server +is now ARM-based in London!`" + +*Slide 3: Superposition* + +.... +$ watch -n 5 'dig quantum.demo.com HINFO LOC' +.... + +"`The server exists in SUPERPOSITION - simultaneously all possible +hardware in all possible locations!`" + +*Audience Reaction:* + +* Technical audience: Appreciates the DNS humor +* Non-technical: Impressed by "`quantum`" technology +* Security professionals: Understands deception value + +*Key Message:* + +"`While we can’t actually achieve quantum computing with DNS records, we +CAN achieve something useful: making attackers uncertain about what +they’re targeting.`" + +''''' + +=== Advanced Use Cases + +==== Scenario: Threat Intelligence Gathering + +*Objective:* Create honeypot network that reveals attacker tool +capabilities. + +*Setup:* + +Deploy honeypots with fluctuating records and monitor: + +[arabic] +. *Which attackers notice changes?* +* Sophisticated adversaries vs. script kiddies +* Manual vs. automated reconnaissance +. *How do they react?* +* Re-scan with different tools +* Attempt to correlate multiple data sources +* Abandon target as "`unstable`" +. *What tools do they use?* +* Which query DNS records during attacks? +* Time between queries (automation interval) +* Query patterns reveal tool fingerprints + +*Data Collection:* + +.... +Timestamp | Source IP | Query Type | Result | TTL +----------|-----------|------------|--------|---- +10:00:00 | 1.2.3.4 | HINFO | Xeon | 300 +10:05:00 | 1.2.3.4 | LOC | SF | 300 +10:10:00 | 1.2.3.4 | HINFO | ARM | 300 <- Noticed change! +10:10:05 | 1.2.3.4 | A | ... | ... <- Investigating +10:10:10 | 1.2.3.4 | TXT | ... | ... <- Thorough scan +.... + +*Analysis:* + +* Attackers who re-query show higher sophistication +* Quick detection indicates automated tool with good caching +* Lack of reaction suggests records ignored (valuable data!) + +==== Scenario: Bug Bounty Honeypot + +*Objective:* Attract bug bounty hunters to honeypots instead of +production. + +*Setup:* + +.... +# Production (boring, stable) +prod.company.com. HINFO "Intel-Xeon" "RHEL-8" +prod.company.com. LOC + +# Bug bounty target (exciting, unstable) +bounty.company.com. HINFO +bounty.company.com. LOC +.... + +*Strategy:* + +[arabic] +. Make bounty target appear "`misconfigured`" +. Fluctuating records suggest poor security practices +. Attracts researchers to intended target +. Protects production from excessive testing + +*Benefits:* + +* Researchers focus on designated systems +* Production remains stable +* Still find real bugs (in honeypot infrastructure) +* Reduces noise in production logs + +''''' + +=== Ethical and Legal Considerations + +==== When NOT to Use This Tool + +[arabic] +. *Defrauding users* - Don’t lie about service locations if legally +required to disclose +. *Violating ToS* - Check DNS provider terms of service +. *Active attacks* - Don’t use for offensive operations without +authorization +. *Compliance violations* - GDPR, HIPAA, etc. may require accurate +location data + +==== When It’s Appropriate + +[arabic] +. *Authorized pentesting* - With proper scope and authorization +. *Your own infrastructure* - You control the DNS +. *Research networks* - Lab environments +. *Honeypots* - Explicitly designed for deception +. *Educational demos* - With proper disclosure + +==== Best Practices + +[arabic] +. *Document* all fluctuation policies +. *Audit log* every DNS change +. *Coordinate* with legal/compliance teams +. *Disclose* in security policy if appropriate +. *Monitor* for unintended consequences + +''''' + +=== Measuring Effectiveness + +==== Metrics for Success + +*Honeypot Engagement:* - Average time attackers spend on honeypot - +Number of return visits - Depth of reconnaissance performed - Tools and +techniques revealed + +*Deception Effectiveness:* - Percentage of attackers who notice changes +- Time to detection of fluctuation - Behavioral changes after detection +- Abandonment rate + +*Privacy Protection:* - Variance in published location data - Difficulty +of determining true location - Correlation with actual infrastructure + +*Research Value:* - Number of unique attacker profiles identified - Tool +fingerprints collected - Threat intelligence quality - +Publication/presentation opportunities + +==== Data to Collect + +.... +{ + "timestamp": "2024-01-15T10:30:00Z", + "domain": "honeypot.example.com", + "previous_hinfo": "Intel-Xeon Ubuntu-22.04", + "new_hinfo": "ARM-Cortex-A72 Alpine-Linux", + "previous_loc": "37.7749,-122.4194,16", + "new_loc": "51.5074,-0.1278,11", + "queries_since_change": 45, + "unique_sources": 12, + "detected_by": ["1.2.3.4", "5.6.7.8"], + "average_ttl_respected": "67%" +} +.... + +''''' + +=== Conclusion + +The HINFO-LOC Fluctuator is a versatile tool for security research, +honeypot deployment, privacy enhancement, and education. The key to +effective use is understanding that DNS records are *informational*, not +*authoritative* - and information can be crafted to serve defensive +purposes. + +Remember: *Always use ethically, legally, and with proper +authorization.* + +For questions or to share your use cases, contact [your contact info +here]. diff --git a/hinfo_loc_fluctuator_ada/docs/USE_CASES.md b/hinfo_loc_fluctuator_ada/docs/USE_CASES.md deleted file mode 100644 index ad01510..0000000 --- a/hinfo_loc_fluctuator_ada/docs/USE_CASES.md +++ /dev/null @@ -1,505 +0,0 @@ -# HINFO-LOC Fluctuator - Detailed Use Cases - -This document provides comprehensive scenarios for using the HINFO-LOC Fluctuator in various security, research, and educational contexts. - -## Table of Contents - -1. [Honeypot Deployment Obfuscation](#honeypot-deployment-obfuscation) -2. [Incident Response and Deception](#incident-response-and-deception) -3. [Security Research and Education](#security-research-and-education) -4. [Privacy Enhancement](#privacy-enhancement) -5. [Testing and Development](#testing-and-development) -6. [Quantum Server Demonstrations](#quantum-server-demonstrations) - ---- - -## Honeypot Deployment Obfuscation - -### Scenario: Moving Honeypot Illusion - -**Objective:** Make honeypots appear to physically move locations to confuse attackers and extend engagement time. - -**Setup:** -```bash -# Configure honeypot DNS records -honeypot.example.com. IN HINFO "Intel-Xeon" "Ubuntu-22.04-LTS" -honeypot.example.com. IN LOC 37.7749 N 122.4194 W 16m -``` - -**Implementation:** - -1. **Deploy** multiple honeypots at different locations -2. **Configure** HINFO-LOC Fluctuator to randomize records every 6-24 hours -3. **Monitor** attacker behavior as apparent location/hardware changes -4. **Analyze** whether attackers notice and how they react - -**Expected Attacker Behavior:** - -- Initial reconnaissance shows Ubuntu server in San Francisco -- Returns 12 hours later: now appears to be Windows in London -- Confusion: "Did I attack the right server? Did they migrate?" -- Extended engagement as attacker investigates changes - -**Benefits:** - -- Increases time attackers spend on honeypots -- Reveals attacker persistence and methodology -- Makes honeypot detection harder (inconsistent fingerprints) -- Provides rich behavioral data - -**Security Considerations:** - -- Ensure actual honeypot services match apparent OS -- Coordinate changes across multiple DNS record types -- Log all fluctuations for correlation with attack patterns - ---- - -## Incident Response and Deception - -### Scenario: Active Response to Ongoing Attack - -**Objective:** Confuse and misdirect attackers during active incident response. - -**Setup:** - -When attack detected on `server.company.com`: - -**Phase 1: Misdirection** -``` -# Make server appear to be in different location -server.company.com. LOC -33.8688 S 151.2093 E 58m # Sydney -``` - -**Phase 2: Hardware Change** -``` -# Make server appear to have different architecture -server.company.com. HINFO "ARM-Cortex-A72" "Alpine-Linux" -``` - -**Phase 3: "Migration"** -``` -# Suggest server moved to cloud provider -server.company.com. LOC 47.6062 N 122.3321 W 56m # AWS us-west-2 -server.company.com. HINFO "Intel-Xeon" "Amazon-Linux-2" -``` - -**Implementation Steps:** - -1. **Detect** attack in progress (IDS/IPS alerts) -2. **Isolate** real server from network -3. **Deploy** honeypot with same IP -4. **Fluctuate** DNS records to suggest instability -5. **Monitor** attacker adaptation strategies -6. **Collect** threat intelligence - -**Deception Tactics:** - -- Rapid location changes suggest panic/misconfiguration -- OS changes suggest desperate remediation attempts -- Creates doubt in attacker's reconnaissance data -- Buys time for forensics and containment - -**Metrics to Track:** - -- Time until attacker abandons target -- Number of re-reconnaissance attempts -- Changes in attack methodology -- Tools/techniques revealed during confusion - ---- - -## Security Research and Education - -### Scenario: Teaching DNS Reconnaissance Countermeasures - -**Objective:** Demonstrate how DNS records can be weaponized for both offense and defense. - -**Lab Exercise:** - -**Part 1: Passive Reconnaissance** - -Students query HINFO/LOC records: -```bash -dig honeypot.lab.edu HINFO -dig honeypot.lab.edu LOC -``` - -Initial results: -``` -honeypot.lab.edu. HINFO "Intel-Pentium-4" "Windows-XP-SP3" -honeypot.lab.edu. LOC 42.3601 N 71.0589 W 43m # Boston -``` - -**Part 2: Temporal Analysis** - -Students repeat queries 1 hour later: -``` -honeypot.lab.edu. HINFO "AMD-EPYC" "Ubuntu-Server-23.04" -honeypot.lab.edu. LOC 51.5074 N 0.1278 W 11m # London -``` - -**Learning Objectives:** - -1. DNS records can lie -2. Temporal consistency is not guaranteed -3. Need multiple information sources for fingerprinting -4. Automated tools can be deceived - -**Discussion Questions:** - -- How does this affect OSINT workflows? -- What other DNS records could be manipulated? -- How would you detect this deception? -- Legal and ethical implications? - -**Advanced Exercise:** - -Students implement detection: -```python -# Detect fluctuating records -def detect_fluctuation(domain, samples=10, interval=300): - """Query domain every 5 minutes, detect changes""" - records = [] - for i in range(samples): - hinfo = query_hinfo(domain) - loc = query_loc(domain) - records.append((hinfo, loc)) - time.sleep(interval) - - # Analyze consistency - return analyze_variance(records) -``` - ---- - -## Privacy Enhancement - -### Scenario: Obscuring Public Server Location - -**Objective:** Prevent location-based targeting of public services while maintaining functionality. - -**Challenge:** - -Your organization runs public services (web, email, etc.) and wants to: -- Prevent attackers from knowing physical location -- Avoid targeted physical attacks on data centers -- Maintain service availability -- Comply with data sovereignty requirements - -**Solution:** - -**Multi-Layer Approach:** - -1. **Anycast** for actual routing (standard practice) -2. **HINFO/LOC Fluctuation** for reconnaissance obfuscation -3. **Consistent CNAME** records for service discovery - -**Implementation:** - -```bash -# Service discovery (consistent) -www.example.com. CNAME frontend.cdn.example.com. - -# Frontend servers (fluctuating) -frontend.cdn.example.com. HINFO -frontend.cdn.example.com. LOC - -# Actual servers (not in DNS) -internal-node-01.example.com. A 10.x.x.x # Private IP -``` - -**Fluctuation Schedule:** - -- Change HINFO: Every 4-8 hours -- Change LOC: Every 2-6 hours -- Avoid patterns (randomize intervals) - -**Benefits:** - -- Reconnaissance returns different data each time -- Physical location obscured -- Automated scanners confused -- Manual analysis more difficult - -**Limitations:** - -- Doesn't prevent direct IP geolocation -- Services must actually be distributed for full effectiveness -- Privacy benefit is defense-in-depth, not primary protection - ---- - -## Testing and Development - -### Scenario: Multi-Region Load Balancer Testing - -**Objective:** Test application behavior with servers in different geographic regions without deploying globally. - -**Setup:** - -Developer wants to test how application handles: -- Different time zones -- Various OS configurations -- Geographic distribution -- Latency variations - -**Traditional Approach:** - -Deploy to 10 regions = $$$ expensive - -**Fluctuator Approach:** - -1. Deploy to ONE region -2. Use HINFO-LOC Fluctuator to simulate others -3. Test application logic that queries DNS - -**Test Scenarios:** - -**Scenario A: Time Zone Handling** -``` -# Simulate Tokyo server -app-server.dev. LOC 35.6762 N 139.6503 E 40m -# Test: Does app correctly handle JST time zone? -``` - -**Scenario B: OS-Specific Bugs** -``` -# Simulate Windows deployment -app-server.dev. HINFO "Intel-Xeon" "Windows-Server-2022" -# Test: Does monitoring assume Linux-specific metrics? -``` - -**Scenario C: Geographic Distribution** -``` -# Simulate multi-region deployment -node1.dev. LOC 37.7749 N 122.4194 W 16m # San Francisco -node2.dev. LOC 51.5074 N 0.1278 W 11m # London -node3.dev. LOC 1.3521 N 103.8198 E 15m # Singapore -# Test: Does load balancer make sane decisions? -``` - -**Benefits:** - -- Rapid testing without infrastructure costs -- Identify logic bugs before deployment -- Validate monitoring and alerting -- Test failover scenarios - ---- - -## Quantum Server Demonstrations - -### Scenario: Conference Talk / Marketing - -**Objective:** Demonstrate "quantum" server concept for entertainment/education. - -**Setup for Live Demo:** - -```bash -# The "Quantum Server" exists in superposition -quantum.demo.com. HINFO -quantum.demo.com. LOC -``` - -**Demo Script:** - -**Slide 1: Classical Server** -``` -$ dig quantum.demo.com HINFO -quantum.demo.com. HINFO "Intel-Xeon" "Ubuntu-22.04" - -$ dig quantum.demo.com LOC -quantum.demo.com. LOC 37.7749 N 122.4194 W 16m -``` - -"This is a classical server. It exists in one place, with one configuration." - -**Slide 2: Quantum Observation** - -Wait 30 seconds, query again: - -``` -$ dig quantum.demo.com HINFO -quantum.demo.com. HINFO "ARM-Cortex-A72" "Alpine-Linux" - -$ dig quantum.demo.com LOC -quantum.demo.com. LOC 51.5074 N 0.1278 W 11m -``` - -"Upon observation, the quantum state collapses differently! The server is now ARM-based in London!" - -**Slide 3: Superposition** - -``` -$ watch -n 5 'dig quantum.demo.com HINFO LOC' -``` - -"The server exists in SUPERPOSITION - simultaneously all possible hardware in all possible locations!" - -**Audience Reaction:** - -- Technical audience: Appreciates the DNS humor -- Non-technical: Impressed by "quantum" technology -- Security professionals: Understands deception value - -**Key Message:** - -"While we can't actually achieve quantum computing with DNS records, we CAN achieve something useful: making attackers uncertain about what they're targeting." - ---- - -## Advanced Use Cases - -### Scenario: Threat Intelligence Gathering - -**Objective:** Create honeypot network that reveals attacker tool capabilities. - -**Setup:** - -Deploy honeypots with fluctuating records and monitor: - -1. **Which attackers notice changes?** - - Sophisticated adversaries vs. script kiddies - - Manual vs. automated reconnaissance - -2. **How do they react?** - - Re-scan with different tools - - Attempt to correlate multiple data sources - - Abandon target as "unstable" - -3. **What tools do they use?** - - Which query DNS records during attacks? - - Time between queries (automation interval) - - Query patterns reveal tool fingerprints - -**Data Collection:** - -``` -Timestamp | Source IP | Query Type | Result | TTL -----------|-----------|------------|--------|---- -10:00:00 | 1.2.3.4 | HINFO | Xeon | 300 -10:05:00 | 1.2.3.4 | LOC | SF | 300 -10:10:00 | 1.2.3.4 | HINFO | ARM | 300 <- Noticed change! -10:10:05 | 1.2.3.4 | A | ... | ... <- Investigating -10:10:10 | 1.2.3.4 | TXT | ... | ... <- Thorough scan -``` - -**Analysis:** - -- Attackers who re-query show higher sophistication -- Quick detection indicates automated tool with good caching -- Lack of reaction suggests records ignored (valuable data!) - -### Scenario: Bug Bounty Honeypot - -**Objective:** Attract bug bounty hunters to honeypots instead of production. - -**Setup:** - -``` -# Production (boring, stable) -prod.company.com. HINFO "Intel-Xeon" "RHEL-8" -prod.company.com. LOC - -# Bug bounty target (exciting, unstable) -bounty.company.com. HINFO -bounty.company.com. LOC -``` - -**Strategy:** - -1. Make bounty target appear "misconfigured" -2. Fluctuating records suggest poor security practices -3. Attracts researchers to intended target -4. Protects production from excessive testing - -**Benefits:** - -- Researchers focus on designated systems -- Production remains stable -- Still find real bugs (in honeypot infrastructure) -- Reduces noise in production logs - ---- - -## Ethical and Legal Considerations - -### When NOT to Use This Tool - -1. **Defrauding users** - Don't lie about service locations if legally required to disclose -2. **Violating ToS** - Check DNS provider terms of service -3. **Active attacks** - Don't use for offensive operations without authorization -4. **Compliance violations** - GDPR, HIPAA, etc. may require accurate location data - -### When It's Appropriate - -1. **Authorized pentesting** - With proper scope and authorization -2. **Your own infrastructure** - You control the DNS -3. **Research networks** - Lab environments -4. **Honeypots** - Explicitly designed for deception -5. **Educational demos** - With proper disclosure - -### Best Practices - -1. **Document** all fluctuation policies -2. **Audit log** every DNS change -3. **Coordinate** with legal/compliance teams -4. **Disclose** in security policy if appropriate -5. **Monitor** for unintended consequences - ---- - -## Measuring Effectiveness - -### Metrics for Success - -**Honeypot Engagement:** -- Average time attackers spend on honeypot -- Number of return visits -- Depth of reconnaissance performed -- Tools and techniques revealed - -**Deception Effectiveness:** -- Percentage of attackers who notice changes -- Time to detection of fluctuation -- Behavioral changes after detection -- Abandonment rate - -**Privacy Protection:** -- Variance in published location data -- Difficulty of determining true location -- Correlation with actual infrastructure - -**Research Value:** -- Number of unique attacker profiles identified -- Tool fingerprints collected -- Threat intelligence quality -- Publication/presentation opportunities - -### Data to Collect - -``` -{ - "timestamp": "2024-01-15T10:30:00Z", - "domain": "honeypot.example.com", - "previous_hinfo": "Intel-Xeon Ubuntu-22.04", - "new_hinfo": "ARM-Cortex-A72 Alpine-Linux", - "previous_loc": "37.7749,-122.4194,16", - "new_loc": "51.5074,-0.1278,11", - "queries_since_change": 45, - "unique_sources": 12, - "detected_by": ["1.2.3.4", "5.6.7.8"], - "average_ttl_respected": "67%" -} -``` - ---- - -## Conclusion - -The HINFO-LOC Fluctuator is a versatile tool for security research, honeypot deployment, privacy enhancement, and education. The key to effective use is understanding that DNS records are **informational**, not **authoritative** - and information can be crafted to serve defensive purposes. - -Remember: **Always use ethically, legally, and with proper authorization.** - -For questions or to share your use cases, contact [your contact info here]. diff --git a/llm-warmup-dev.adoc b/llm-warmup-dev.adoc new file mode 100644 index 0000000..10cf109 --- /dev/null +++ b/llm-warmup-dev.adoc @@ -0,0 +1,19 @@ +== LLM Warmup — resource-record-fluctuator (Developer) + +=== What is resource-record-fluctuator? + +See README.adoc for overview. + +=== Key Commands + +* `+just setup+` — set up development environment +* `+just build+` — build the project +* `+just test+` — run tests +* `+just doctor+` — diagnose issues +* `+just heal+` — attempt auto-repair + +=== Quick Context + +* License: PMPL-1.0-or-later +* Part of hyperpolymath ecosystem +* See EXPLAINME.adoc for architecture diff --git a/llm-warmup-dev.md b/llm-warmup-dev.md deleted file mode 100644 index f6bf007..0000000 --- a/llm-warmup-dev.md +++ /dev/null @@ -1,16 +0,0 @@ -# LLM Warmup — resource-record-fluctuator (Developer) - -## What is resource-record-fluctuator? -See README.adoc for overview. - -## Key Commands -- `just setup` — set up development environment -- `just build` — build the project -- `just test` — run tests -- `just doctor` — diagnose issues -- `just heal` — attempt auto-repair - -## Quick Context -- License: PMPL-1.0-or-later -- Part of hyperpolymath ecosystem -- See EXPLAINME.adoc for architecture diff --git a/llm-warmup-user.adoc b/llm-warmup-user.adoc new file mode 100644 index 0000000..731a66f --- /dev/null +++ b/llm-warmup-user.adoc @@ -0,0 +1,19 @@ +== LLM Warmup — resource-record-fluctuator (User) + +=== What is resource-record-fluctuator? + +See README.adoc for overview. + +=== Key Commands + +* `+just setup+` — set up development environment +* `+just build+` — build the project +* `+just test+` — run tests +* `+just doctor+` — diagnose issues +* `+just heal+` — attempt auto-repair + +=== Quick Context + +* License: PMPL-1.0-or-later +* Part of hyperpolymath ecosystem +* See EXPLAINME.adoc for architecture diff --git a/llm-warmup-user.md b/llm-warmup-user.md deleted file mode 100644 index 2ce006c..0000000 --- a/llm-warmup-user.md +++ /dev/null @@ -1,16 +0,0 @@ -# LLM Warmup — resource-record-fluctuator (User) - -## What is resource-record-fluctuator? -See README.adoc for overview. - -## Key Commands -- `just setup` — set up development environment -- `just build` — build the project -- `just test` — run tests -- `just doctor` — diagnose issues -- `just heal` — attempt auto-repair - -## Quick Context -- License: PMPL-1.0-or-later -- Part of hyperpolymath ecosystem -- See EXPLAINME.adoc for architecture