Server egress filtering limits the connections a server initiates to other systems. For a public web application, permit the destinations needed for its job and block other outbound connections by default. This can restrict routes used to download attacker tools or contact attacker-controlled infrastructure after an application compromise.
In a November 6, 2026 Microsoft Threat Intelligence report on ARTEX abuse, Microsoft says the Storm-3358 intrusion cluster began targeting financial organizations in October 2026. ARTEX is an AI framework that can carry out sequences of attack tasks. Microsoft observed web application exploitation and downloads of remote-access trojans, malware that gives an attacker control of a system. November 6 is the report date, not the start of those attacks.
The practical question for an IT manager responsible for a customer portal is specific: which new internet connections should that server be allowed to make? Restricting those paths addresses part of the activity after compromise. The application still needs its vulnerabilities fixed, credentials protected, and suspicious activity investigated.
Separate replies to customers from new outbound connections
A customer connects to your website, and the server sends a response over that connection. Separately, the server might initiate a new connection to a delivery-status service, software repository, or attacker-controlled download site. These are different policy decisions.
A stateful firewall tracks established connections. It can therefore distinguish traffic belonging to an allowed session from a new connection the server initiates, subject to its configuration. Restricting new outbound connections need not stop the website from replying to customers. NIST's firewall guidance, published in September 2009, explains stateful inspection and recommends blocking inbound and outbound traffic that policy has not expressly permitted.
The permission should describe the server's work. “Allow outbound port 443” identifies a port commonly used for HTTPS, the encrypted form of the web protocol, but leaves the destination unrestricted if the rule says “any.” An attacker-controlled service can use that same port. Encryption protects a connection's contents in transit; it does not establish a business reason for making the connection.
Compare three policies for the same portal
Consider a hypothetical logistics company's customer portal. Its server queries a carrier's delivery-status service, sends notifications through the company's internal mail relay, and receives software through an approved update process. Assume its new internet connections pass through a managed gateway.
Allow web connections to any internet destination
This makes many services easy to reach, including ones the application does not need. It also permits a new connection to an unrelated download server on an allowed port. If an attacker gains command execution on the portal, a port-only rule supplies little restriction on where that connection can go. Other inspection controls may still act, but the outbound permission itself is broad.
Allow only the required external destinations
Give the portal a defined path to the carrier's documented service destinations and the approved update destinations. Keep notification delivery on its internal relay path. Deny other new internet connections. An attempted connection to an unrelated download host would then fail at the policy boundary, provided no other rule or route permits it.
This design needs maintained destination information. A service can use changing addresses or shared hosting infrastructure. Confirm what the actual firewall can distinguish: an address, a hostname, an application, or a more specific request. Allowing an entire shared hosting provider may grant far more access than the one business service requires.
Move a dependency behind a controlled intermediary
Where the software supports it, use a designated update repository or a restricted outbound proxy instead of giving the portal general download access. The intermediary makes the approved external connections, and the portal's direct internet permissions can be reduced further.
The intermediary needs its own restrictive policy and maintenance. A proxy that lets the portal request any destination merely relocates the broad permission. This option adds an operational dependency, so choose it when the application supports the route and the organization can operate it reliably.
For this hypothetical portal, the useful starting proposal is the second design, with the third evaluated for its update process. It preserves delivery-status queries while removing unrelated outbound destinations. Network Box USA's Managed Unified Threat Management (UTM+) service combines firewall policy, application identification, logging, updates, and managed operational support. For traffic on the agreed gateway path, that work can turn the application's dependency list into maintained access rules and evidence for investigating denied connections. Confirm the supported matching methods and change responsibilities during service design.
Preserve the dependencies that keep the server secure
Build the permitted list from application documentation, owner knowledge, and observed traffic together. Include name resolution, time synchronization, certificate checks, monitoring, licensing, scheduled jobs, and updates where required. A quiet observation period may omit a dependency used only during maintenance or recovery.
Update traffic deserves particular care. As a vendor-specific example, Microsoft's Windows Update security documentation describes multiple connections and certificate-pinned metadata exchanges that must pass through Transport Layer Security (TLS) proxies without interception. It also explains why fixed destination address lists are unsuitable for those changing endpoints. Follow the guidance for the actual updater and deployed operating system; this example does not establish identical behavior in every server or Network Box USA deployment.
Use an approved pilot and change window. Exercise a real delivery-status lookup, a harmless notification, and the update workflow. Separately attempt a harmless connection to a controlled test destination outside the permitted set and confirm the intended denial. Include policy paths for Internet Protocol versions 4 and 6 (IPv4 and IPv6) where used, and agree rollback conditions before changing production.
Keep the remaining attack paths in view
A compromised application may misuse an allowed service or return stolen information over an existing customer-facing connection. Outbound restrictions also do not govern internal paths that bypass the gateway. Egress filtering reduces reachable destinations; it is one layer alongside application repair, access control, and investigation. Our virtual-patching explanation covers the separate relationship between an inbound protective rule and fixing the application.
The application owner identifies dependencies, maintains the software, and approves the business impact of restrictions. The managed gateway operator implements and reviews the agreed network policy. To evaluate that boundary for your public application, contact our team with the server's outbound dependencies, traffic path, and maintenance requirements.