Suppose your web server is compromised tomorrow. Which other devices can it reach? The answer helps determine whether an incident stays within one service or puts more of the business at risk. A patch protects against a known vulnerability. A well planned network also limits the possible consequences.
Our example is a fictional customer portal: people sign in, view orders and download documents. The application needs a defined database connection. That does not mean it also needs access to NAS administration, the backup server or the virtualisation host. This distinction must be enforced technically.
A compromised service uses the paths available to it
A vulnerability may allow unauthorised code to run with the web application’s permissions. What happens next depends on network rules, service accounts, stored credentials and further vulnerabilities, among other factors. Being reachable does not mean that access will succeed. Nor does a compromised web server automatically take over the entire LAN.
The risk grows when reachable internal services meet excessive permissions. An attacker then has fewer boundaries to cross. This possible spread to other systems is known as lateral movement. It therefore makes sense to design the network on the assumption that an application has already been compromised.
Network A: the portal sits in a flat business network
In the first design, the portal, database, file storage and administrative interfaces share a network. The perimeter firewall restricts incoming connections. Internally, however, broad permissions or insufficient separation leave more systems reachable from the web server than its work requires.
A shared administrator account makes matters worse. So does a mounted backup directory with write access, or powerful credentials stored in the application directory. A working backup offers little reassurance if the compromised service can also change its administration or every backup copy.
Network B: zones and rules limit connections
In the second design, internet requests first reach a defined frontend or reverse proxy. It may contact the required application in a separate web segment. The application receives only the necessary connection to a specified database destination. Administration, backups and other internal services occupy separate zones; unnecessary access from the web segment is blocked.
A VLAN divides a network logically. Control over the connections determines whether it becomes an effective security boundary. Overly permissive inter-VLAN routing largely reconnects those separate networks. Additional filtering between individual workloads may also be needed within a VLAN.
OPNsense or Sophos Firewall are possible platforms for suitable rules, alongside other appropriate products. What matters is the specific source, destination, service, ownership and verified implementation. Interfaces and available functions differ between platforms. A product name alone does not describe a tested security architecture.
Reverse proxies and WAFs remain part of the protection
A reverse proxy can consolidate public access, handle TLS connections and direct requests to selected backends. HAProxy supports HTTP and TCP modes for these purposes, among others. This does not imply a general proxy function for arbitrary protocols. An upstream web application firewall can identify and reject certain malicious web requests.
These components do not replace secure applications, prompt updates or restrictive backend access. Incorrect rules or another reachable entry point may bypass protections. In our example, an application compromised behind the proxy must therefore still be limited to the destinations it explicitly needs.
Consider outgoing and internal traffic
The key question is not just who may connect to the web server. Where may the server initiate connections itself? Can it reach the NAS management interface? Does it need to contact arbitrary internet destinations? Which internal services do other containers actually require?
Outgoing traffic, or egress, needs a plan covering name resolution, time synchronisation, updates and external interfaces. Necessary destinations receive specific permissions. Communication between internal systems, often called east-west traffic, also needs clear rules. IPv6 and alternative routes must respect the same intended separation.
A connection plan records the source, destination, required service, purpose and responsible person. Both allowed and blocked paths are then tested under controlled conditions. Logs and monitoring should reveal unexpected successful connections as well as suspicious blocked attempts. A rule without verified effects is not yet reliable evidence.
VMs and containers need appropriate boundaries
A virtual machine has its own guest operating system; containers typically share their host’s kernel. Both models require suitable networking and permissions. Proxmox VE provides firewall rules for hosts and guests. Which layers and functions take effect also depends on the firewall backend and the settings actually enabled.
With Docker, containers on the same bridge network can communicate. Outgoing connections are not automatically restricted to public destinations. Published ports can create additional entry points. In host network mode, containers share the host’s network namespace, so there is no separate network isolation.
Extra privileges, unnecessary host mounts and access to the Docker socket can greatly increase the impact of an incident. Separate application networks, minimal permissions, appropriate host firewall rules and controlled DNS and egress paths therefore belong together. Again, the configuration that actually takes effect is decisive.
A manageable starting point for smaller businesses
- Inventory services: document public applications, dependencies and responsible people.
- Define zones: separate public workloads, data, administration and backups according to protection needs.
- Justify connections: allow only defined sources, destinations and services; block the rest where operationally appropriate.
- Secure administration: use trusted access paths, suitable VPN and MFA methods, and separate accounts.
- Include operations: plan updates, central logs, alerts and independently protected backups with tested recovery.
- Verify the result: review rules regularly, time-limit exceptions and retest after changes.
Changes need preparation, a suitable maintenance window and a way back. A blanket block can interrupt legitimate applications or your own administrative access. Record dependencies first, make the transition under controlled conditions, then verify business functions with the people responsible.
One application falling need not bring down the network behind it
Our PHP2Shell articles on responding to PHP vulnerabilities and AI-assisted inventory work provide the immediate context. The additional review of NAS, Docker and public services leads to a lasting architecture question: which connections and permissions does each service really need?
DAXS supports inventory work, communication planning, implementation and verifiable operations. Whether an application runs locally, in a private cloud or on a public cloud platform, its security boundaries must fit its actual requirements. Let us discuss your specific environment.
Sources: OPNsense: rules and stateful filtering · Sophos Firewall: zones, rules and logging · HAProxy: HTTP and TCP modes · Docker: bridge networks · Docker: host network mode · Docker: daemon, permissions and security boundaries · Proxmox VE: firewall documentation · NCSC: contain incidents and protect administration and backups.
