jperezduerto.info
Security in depth · Unit 26
Pivoting, proxies, and network boundaries
Follow how connections cross intermediaries, while keeping routes, policy, and application identity separate.
ATT&CK TA0008 Lateral Movement
Helpful before thisInitial access and credentialsPrivilege escalation
After this lesson you can
- Distinguish forwarding, application proxies, and network tunnels.
- Explain why reachability and source address do not establish application authority.
- Review an intended connection using route, network policy, and application permission.
Lessons in this unit
Browse 4 lessons in this topic
- A route is not a permissionRead three access checks without confusing connectivity, identity, and resource authority.4 min
- A bastion concentrates a boundaryReview a recovery access plan without losing the controls a gateway normally provides.4 min
- Temporary access needs closureCompare a support deadline with the actual closure of access and sessions.4 min
- Observe the whole access pathBuild a careful explanation from gateway and destination records with different meanings.4 min
A community centre lets staff use an approved gateway to reach an internal records service. The gateway provides a connection path, but it does not automatically give every staff member permission to read every record. This distinction is the heart of the lesson.
In incident analysis, pivoting describes using an intermediate system’s connectivity to reach elsewhere. Similar communication mechanisms also support legitimate remote access and service delivery. Understanding the architecture helps defenders spot unnecessary paths and explain what the destination actually trusted.
Three questions for one connection
Start with three independent questions: Does a route exist? Does network policy permit this communication? Does the application authorize this caller and operation?
A route can exist while a firewall blocks the traffic. A permitted connection can reach a login page while the application denies access. An account might have application permission but no usable network path from its present location.
These checks are a teaching model, not a complete troubleshooting checklist. DNS, protocol compatibility, service health, authentication, device requirements, and other conditions can also affect a real request.
Similar mechanisms, different boundaries
A port forward carries a selected connection through an intermediary. A proxy handles communication on a client’s behalf and may understand the application protocol. A tunnel carries traffic within another communication channel. Product terminology overlaps, so diagrams and observed behavior are more useful than labels alone.
Some proxies terminate a client connection and create a separate connection to the destination. That can change where encryption ends, which certificates are checked, and what each side records. Encryption between client and gateway does not, by itself, establish encryption from gateway to service.
A VPN may route selected IP traffic rather than join the client to the destination’s local network. Routing and bridging are different arrangements; neither automatically grants access to every resource.
A network address is not an account
Our fictional gateway has a local service account. The records service might see the gateway’s source address while authenticating the staff member’s application credentials. Those are two different observations.
Other designs use a gateway’s own service identity or explicitly delegate a user’s identity. Do not assume which arrangement applies. Record the original caller, intermediary process identity, network source, and identity accepted by the destination.
Forwarded address headers can help reconstruct a path only when the receiving system trusts the correct intermediary and handles those headers safely. A client-supplied address claim is not proof of identity.
Protocol support needs its own evidence
A mechanism that carries TCP does not automatically carry UDP or ICMP. However, “SOCKS is always TCP-only” is also incorrect: SOCKS5 defines UDP support, while specific clients, servers, or forwarding implementations may support only a subset.
Likewise, success over IPv4 says little about IPv6 policy. Name resolution may occur at the client or an intermediary depending on the design. When reviewing a failure, identify the actual protocol and observation point before concluding that the destination is unavailable.
Segmentation is an enforced policy
Segmentation controls communication between parts of an environment. It becomes useful when a team can explain which service needs each allowed path, which identities may use it, and how exceptions expire.
An approved records connection is not automatically a segmentation failure. A finding needs evidence that an intended boundary or requirement was violated. Private addressing, a gateway, and an encrypted tunnel are each insufficient substitutes for destination authorization.
A clear review recommends bounded destinations, appropriate authentication, application permissions, and useful logs. It also identifies the owner of temporary access and how its removal is verified. That turns a complicated network picture into understandable control decisions.
EXPLORE THE CONCEPT
Three checks for a fictional connection
Adjust the simplified checks. Then compare the evidence needed for each layer.
Route unavailable
There is no usable network path in this model. An application's permission settings do not create that path.
Network policy denies
A route exists, but the relevant network control denies this communication. That result says nothing by itself about whether the application account has permission.
Application authorization
A reachable service still checks the caller and operation. In this simplified model all three checks must pass; real services can impose additional conditions.
A simplified learning model. It connects to no systems and uses no real data.
Terms you met
Check yourself
No timer. No penalties. Read the explanation and try again whenever you like.
This lesson’s questions have changed. Your reading progress is saved; review the updated questions.
-
A service sees a gateway's network address. What follows about the authenticated account?
Show the answer
Correct answer: It depends on whether the design forwards, reauthenticates, or delegates identity. Network source and application identity are distinct evidence.
-
A route exists but a firewall denies the connection. Which statement fits?
Show the answer
Correct answer: The network policy blocked a path that otherwise exists. Routing and permission to communicate are separate checks.
-
Which statement about SOCKS5 is accurate?
Show the answer
Correct answer: The protocol defines UDP support, but implementations vary. Verify actual client and server capabilities rather than inferring them from the name.
-
A gateway-to-service path is allowed by a documented requirement. Is its existence a finding by itself?
Show the answer
Correct answer: No; a finding needs evidence of a weakness or violated boundary. Useful connectivity can be deliberate; assess its permissions and controls.
Try it
- WriteA fictional helpdesk connects through a managed gateway to a records service. The service records the gateway’s network address but rejects the helpdesk account. Draw the client, gateway, and service. Mark which connection worked and which authorization failed, then propose a record that would identify the original user.