Publishing Internal APIs from DMZ Without Direct LAN Connections: Five Tested Architectures

When an API gateway resides in the DMZ but security policies forbid outbound connections into the LAN, organizations must adopt alternative patterns to expose internal services synchronously. The article examines five production-ready approaches built on the NEOMSA APIM platform, ranging from custom request-reply logic over Kafka to zero-code solutions using ActiveMQ Artemis and experimental reverse HTTP in HAProxy. Each pattern is evaluated against criteria such as the need for DMZ-to-LAN firewall rules, volume of custom code, support for streaming responses, and measured performance. Load tests on the Artemis-based bridge reached 50 requests per second with a 95th percentile latency of approximately 100 ms, while the Kafka implementation required roughly 2,500 lines of Java to emulate missing reply semantics. The analysis highlights trade-offs in operational complexity, vendor support implications, and security posture, particularly the benefit of preventing any outbound initiation from the DMZ.

HabrOctober 8, 2026Translated from Russian

Read at source

When an API gateway is placed in the DMZ and corporate security policy prohibits any connections from the DMZ into the internal LAN, the most obvious proxying pattern becomes impossible. Business requirements nevertheless demand that consumers receive synchronous HTTP responses, making a full rewrite of integration contracts prohibitively expensive.

Over the past year the team at Neoflex evaluated five architectural options on the NEOMSA APIM platform, which is built on WSO2 components including the gateway, Micro Integrator, and developer portal. Three patterns reached working laboratory environments, one underwent full load testing, and the remaining two were validated through architecture reviews and security approvals.

Variant 1: Custom request-reply over Kafka

Kafka is deployed in the DMZ. The gateway writes requests to a topic; an internal Micro Integrator instance connects outbound to consume them, invokes the target system, and publishes replies to a second topic. Because Kafka lacks native reply-to semantics, the team implemented correlation, partition-based routing, dead-letter handling, and offset management in approximately 2,500 lines of Java packaged as a custom mediator. The solution works but introduces significant maintenance obligations and removes centralized policy enforcement.

Variant 2: JMS request-reply with ActiveMQ Artemis

Replacing Kafka with ActiveMQ Artemis eliminates all custom code. Both sides use standard JMS mediators inside Micro Integrator. The broker handles correlation identifiers, message expiration, and selective consumption. Load tests demonstrated a sustained 50 requests per second with 95th-percentile latency near 100 ms. Limitations include the inability to stream large or unknown-size responses and the requirement for idempotency keys on state-changing operations.

Variant 3: Reverse HTTP via HAProxy

An internal node initiates a persistent HTTP/2 connection to the DMZ gateway; roles are then reversed so the gateway treats the tunnel as an upstream. No DMZ-to-LAN firewall rule is required, no custom code is written, and the call remains ordinary synchronous HTTP. The mechanism is still marked experimental in HAProxy 2.9+, requiring careful configuration of connection reuse and keep-alive parameters.

Variant 4 & 5: Dual gateways with narrow DMZ-to-LAN rule

When security permits a tightly scoped rule allowing mTLS-authenticated traffic on specific ports, two simpler topologies become viable: a single management plane controlling gateways in both zones, or two independent NEOMSA APIM installations. Both preserve full policy, throttling, and key-management capabilities in one administrative domain.

The decisive question for any organization facing the same constraint is whether a narrow DMZ-to-LAN firewall exception with mutual certificate authentication can be obtained. The answer immediately eliminates or validates half of the candidate architectures.

HAProxy WSO2 NEOMSA APIM ActiveMQ Artemis Micro Integrator

ShareX Facebook LinkedIn Reddit

Meridian digestThe week's most consequential security stories, distilled into one briefing.See the digest

More in Other

Other

Detecting Suspicious Processes in Linux: How to Investigate Unknown Services, Network Connections and Startup Tasks

This practical guide helps Blue Team beginners investigate unexpected resource usage, unknown network connections, and processes that restart after reboot on Linux systems. It explains how to examine running processes with ps and top, identify executable paths via /proc, and review network sockets using ss and lsof without installing additional tools. The article covers checking systemd services with systemctl, reviewing cron jobs and timers, auditing SSH keys, and correlating events from journalctl logs. Emphasis is placed on gathering multiple indicators rather than jumping to conclusions about compromise, as high CPU usage or unfamiliar services can stem from legitimate misconfigurations or maintenance tasks. Readers learn safe evidence preservation steps if suspicious activity is confirmed, including logging observations and avoiding immediate reboots that could destroy forensic data.

HabrOct 28, 2026Translated from Russian

Other

TLS Fingerprinting Explained: From Handshakes in TLS 1.2/1.3 to JA3, JA4, HTTP/2 Analysis and uTLS Evasion

The article provides an in-depth examination of how TLS handshakes reveal client identity even before any HTTP data is sent. It traces the evolution from early SSL versions developed by Netscape to modern TLS 1.3, highlighting how elliptic curve cryptography and AEAD ciphers reduced latency while increasing observability challenges for defenders. Detailed breakdowns show why JA3 hashes became unreliable due to GREASE randomization and extension ordering changes, prompting the shift to the more robust JA4+ family that uses sorted, GREASE-resistant blocks for stable fingerprints. The piece also covers HTTP/2 fingerprinting signals and practical tools such as uTLS in Go for mimicking browser TLS stacks and Finch for traffic analysis. Real Wireshark captures of Client Hello packets to GitHub illustrate how Cloudflare and WAF systems detect scripted clients despite matching User-Agent headers. Overall, the content serves as both a historical overview and a hands-on guide for security engineers working on bot mitigation and traffic obfuscation.

HabrOct 27, 2026Translated from Russian

Other

Centralized Secret Management: Comparing Eight Tools for DevOps and Spring Boot Applications

The article examines the challenges of managing secrets such as passwords, API tokens, and SSH keys across development, CI/CD pipelines, and production environments. It explains how centralized secret registries solve issues like scattered .env files, outdated credentials, and lack of audit trails while emphasizing that delivery mechanisms to applications must be chosen separately. Key concepts including static versus dynamic credentials, leases, rotation, and machine identities are defined to help teams implement least-privilege access. The review compares Infisical, HashiCorp Vault, OpenBao, Doppler, 1Password CLI, Bitwarden Secrets Manager, Passbolt, and Yandex Lockbox across deployment models, offline support, and integration options. Special attention is given to CLI run commands that avoid plaintext files, Spring Cloud Vault integration, and the trade-offs between SaaS convenience and self-hosted control. Practical recommendations focus on separating developer and machine access as well as development and production environments.

HabrOct 27, 2026Translated from Russian