Implementing F5 NGINX STIGs: A Practical Guide to DoD Security Compliance
Introduction In today’s security-conscious environment, particularly within federal and DoD contexts, Security Technical Implementation Guides (STIGs) have become the gold standard for hardening systems and applications. For organizations deploying NGINX—whether as a web server, reverse proxy, or load balancer—understanding and implementing NGINX STIGs is critical for maintaining compliance and securing your infrastructure. This guide walks through the essential aspects of NGINX STIG implementation, providing practical insights for security engineers and system administrators tasked with meeting these stringent requirements. Understanding STIGs and Their Importance STIGs are configuration standards created by the Defense Information Systems Agency (DISA) to enhance the security posture of DoD information systems. These guides provide detailed technical requirements for securing software, hardware, and networks against known vulnerabilities and attack vectors. For NGINX deployments, STIG compliance ensures: Protection against common web server vulnerabilities Proper access controls and authentication mechanisms Secure configuration of cryptographic protocols Comprehensive logging and auditing capabilities Defense-in-depth security posture Key NGINX STIG Categories Access Control and Authentication Critical Controls: The STIG mandates strict access controls for NGINX configuration files and directories. All NGINX configuration files should be owned by root (or the designated administrative user) with permissions set to 600 or more restrictive. # Verify permissions sudo chmod 600 /etc/nginx/nginx.conf Client Certificate Authentication: For environments requiring mutual TLS authentication, NGINX must be configured to validate client certificates: # Include the following lines in the server {} block of nginx.conf: ssl_certificate /etc/nginx/ssl/server_cert.pem; ssl_certificate_key /etc/nginx/ssl/server_key.pem; # Enable client certificate verification ssl_client_certificate /etc/nginx/ca_cert.pem; ssl_verify_client on; # Optional: Set verification depth for client certificates ssl_verify_depth 2; location / { proxy_pass http://backend_service; # Restrict access to valid PIV credentials if ($ssl_client_verify != SUCCESS) { return 403; } } Certificate Management: All certificates must be signed by a DoD-approved Certificate Authority Private keys must be protected with appropriate file permissions (400) Certificate expiration dates must be monitored and renewed before expiry Cryptographic Protocols and Ciphers One of the most critical STIG requirements involves configuring approved cryptographic protocols and cipher suites. Approved TLS Versions: STIGs typically require TLS 1.2 as a minimum, with TLS 1.3 preferred: ssl_protocols TLSv1.2 TLSv1.3; FIPS-Compliant Cipher Suites: When operating in FIPS mode, NGINX must use only FIPS 140-2 validated cipher suites: ssl_ciphers 'TLS_AES_256_GCM_SHA384:TLS_AES_128_GCM_SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256'; ssl_prefer_server_ciphers on; Logging and Auditing Comprehensive logging is mandatory for STIG compliance, enabling security monitoring and incident response. Required Log Formats: log_format security_log '$remote_addr - $remote_user [$time_local] ' '"$request" $status $body_bytes_sent ' '"$http_referer" "$http_user_agent" ' '$request_time $upstream_response_time ' '$ssl_protocol/$ssl_cipher'; access_log /var/log/nginx/access.log security_log; error_log /var/log/nginx/error.log info; Key Logging Requirements: Log all access attempts (successful and failed) Capture client IP addresses and authentication details Record timestamps in UTC or local time consistently Ensure logs are protected from unauthorized modification (600 permissions) Implement log rotation and retention policies Pass Security Attributes via a Proxy STIGs require implementation of security attributes to implement security policy for access control and flow control for users, data, and traffic: # Include the "proxy_pass" service as well as the "proxy_set_header" values as required: proxy_pass http://backend_service; proxy_set_header X-Security-Classification "Confidential"; proxy_set_header X-Data-Origin "Internal-System"; proxy_set_header X-Access-Permissions "Read,Write"; Request Filtering and Validation Protecting against malicious requests is a core STIG requirement: # Limit request methods if ($request_method !~ ^(GET|POST|PUT|DELETE|HEAD)$) { return 405; } # Request size limits client_max_body_size 10m; client_body_buffer_size 128k; # Timeouts to prevent slowloris attacks client_body_timeout 10s; client_header_timeout 10s; keepalive_timeout 5s 5s; send_timeout 10s; # Rate limiting limit_req_zone $binary_remote_addr zone=req_limit:10m rate=10r/s; limit_req zone=req_limit burst=20 nodelay; SIEM Integration Forward NGINX logs to SIEM platforms for centralized monitoring: # Syslog integration error_log syslog:server=siem.example.com:514,facility=local7,tag=nginx,severity=info; access_log syslog:server=siem.example.com:514,facility=local7,tag=nginx NGINX Plus Specific STIG Considerations Organizations using NGINX Plus have additional capabilities to meet STIG requirements: Active Health Checks upstream backend { zone backend 64k; server backend1.example.com; server backend2.example.com; } match server_ok { status 200-399; header Content-Type ~ "text/html"; body ~ "Expected Content"; } server { location / { proxy_pass http://backend; health_check match=server_ok; } } JWT Authentication For API security, NGINX Plus can validate JSON Web Tokens: location /api { auth_jwt "API Authentication"; auth_jwt_key_file /etc/nginx/keys/jwt_public_key.pem; auth_jwt_require exp iat; } Dynamic Configuration API The NGINX Plus API must be secured and access-controlled: location /api { api write=on; allow 10.0.0.0/8; # Management network only deny all; # Require client certificate ssl_verify_client on; } Best Practices for STIG Implementation Start with Baseline Configuration: Use DISA's STIG checklist as your starting point and customize for your environment. Implement Defense in Depth: STIGs are minimum requirements; layer additional security controls where appropriate. Automate Validation: Use configuration management and automated scanning to maintain continuous compliance. Document Deviations: When technical controls aren't feasible, document risk acceptances and compensating controls. Regular Updates: STIGs are updated periodically; establish a process to review and implement new requirements. Testing Before Production: Validate STIG configurations in development/staging before deploying to production. Monitor and Audit: Implement continuous monitoring to detect configuration drift and security events. Conclusion Achieving and maintaining NGINX STIG compliance requires a comprehensive approach combining technical controls, process discipline, and ongoing vigilance. While the requirements can seem daunting initially, properly implemented STIGs significantly enhance your security posture and reduce risk exposure. By treating STIG compliance as an opportunity to improve security rather than merely a checkbox exercise, organizations can build robust, defensible NGINX deployments that meet the most stringent security requirements while maintaining operational efficiency. Remember: security is not a destination but a journey. Regular reviews, updates, and continuous improvement are essential to maintaining compliance and protecting your infrastructure in an ever-evolving threat landscape. Additional Resources DISA STIG Library: https://public.cyber.mil/stigs/ NGINX Security Controls: https://docs.nginx.com/nginx/admin-guide/security-controls/ NIST Cybersecurity Framework: https://www.nist.gov/cyberframework Have questions about implementing NGINX STIGs in your environment? Share your challenges and experiences in the comments below.
DISA OCSP responder sometimes producing errors
Hi, not sure if there are others that have this issue, it seems sporadic. I’m using BigIP v13.1.1 OCSP will sometimes fail and users will fail to login, and it will fail for a random duration of time which makes me think it may be an issue with DISA's OCSP servers. It doesn't happen daily. I have a pretty standard APM setup. No HA, nothing weird. My VPE: Start -> On Demand Cert (request) -> OCSP (/Common/DISA_OCSP, cert type user) -> etc etc -> For my OCSP config I have default settings with the Certificate Authority file as the DOD CA bundle and Verify other is the DOD Email CA bundle. Everything is checked besides Ignore AIA and Trust Other. The error in /var/log/apm is: OCSP Auth agent: Failure status ‘Error querying OCSP responsder *(<-this is a typo in the error)* host (ocsp.disa.mil) path (/)’ Looking at my email cert, it looks like I have two different AIAs. One is a crl.disa.mil url pointing at my CA's DODEMAILCA cer file, the other is ocsp.disa.mil. Can anyone recommend a more stable way to configure this?US FEDERAL: DISA UCCO APL Certification
Great news! We have finally been posted to the Defense Information Systems Agency (DISA) Unified Capability (UC) Approved Product List (APL), as an IA Tool. The certification covers all F5 BIG-IP platforms (VE through Viprion) running a minimum of TMOS 11.6. The certification Memo can be found at the following link: DISA UC APL F5 Approval Memo Anyone that has been through the now defunct DoD Information Assurance Certification and Accreditation Process (DIACAP) or DoD Information Technology Security Certification and Accreditation Process (DITSCAP) in the past (1) knows it’s a party, and (2) may know that F5 BIG-IP used to be classified as a “Content Switch / Load Balancer with an OS of Other Network OS.” With the new APL certification, F5 is now classified as an IA tool. While the Certification and Accreditation process will look pretty much the same, things concerning the F5 are starting to change quite a bit. Change 1. F5 Military Unique Deployment Guide. This document helps identify and configure the BIG-IP base configuration required to pass IA scans. Change 2. There is much better clarification on which STIGS apply to F5 BIG-IP, and stronger guidance on how to configure your platform in adherence to STIG and Security Requirements Guidelines (SRG). Change 3. There is also the new National Institute of Standards and Technology (NIST) Risk Management Framework (RMF) process (DoD Instruction 8501.01). We didn’t have anything to do with this, but its new, and its important to know that we are in line with this process. Getting Started To start preparing the F5 BIG-IPs on your network, you should reach out to your account team to acquire a copy of the Military Unique Deployment Guide (MUDG), which details the proper base configuration. The MUDG can be acquired from any member of the F5 Federal team. However, due to sensitive information, a copy of the Information Assurance Assessment Package (IAAP) must be acquired directly from the Unified Capability Certification Office (UCCO), details on this information is located within the DISA UC APL Certification Memo. Next, Apply STIG/SRG. These are currently in process, but the MUDG is sufficient to lock the appliance down to pass initial IA scans. Draft STIG Release Guidance -Update: Final F5 STIG / SRG released, see below. There have been a lot of questions lately on the release of the Draft STIGS for BIG-IP. The important things to note are as follows: First and foremost, do not apply draft STIGS. These are drafts and not yet final. Do not start applying draft STIGS in production environments. Draft STIGS are subject to change. Finally, do not apply draft STIGS. To access and review the Draft STIGS, you can find them at the following location: http://iase.disa.mil/stigs/net_perimeter/network-infrastructure/Pages/network-overview.aspx Final STIG/SRG Release Guidance There have been a lot of questions lately on the release of the Final STIGS / SRGS for BIG-IP. The important things to note are as follows: It is important to first follow and apply the guidance provided in the Military Unique Deployment Guide v1.2 (MUDGv1.2). If you have any questions or concerns regarding the guidance or text in the F5 Final STIGS, do not hesitate to reach out to your account team. To access the Final F5 STIGS, you can find them at the following location: http://iase.disa.mil/stigs/net_perimeter/network-infrastructure/Pages/other.aspx Need Help? Contact Federal [at] F5.com.
