SSH Tunneling Part 3

Introduction

By now, you’re likely familiar with the critical role of the tunneling technique in effective pivoting during penetration tests, which is a key strategy in today’s ever-evolving cybersecurity landscape. In SSH Tunneling Part 2, we laid the groundwork by exploring essential concepts, tools, and use cases, and then examined advanced tunneling tactics along with their real-world applications. We successfully routed traffic from a client network to the Kali pentester machine through multiple jump systems by chaining proxies with tools like a simple SSH client. Additionally, we will build upon local and remote port forwarding to enable multiple systems to connect through various types of tunnels.

In Part 3, we will build on these concepts and explore advanced tunneling tactics through three real-world penetration testing scenarios. This installment will provide tactical insights on managing strict network segmentation, evading monitoring, and establishing connectivity without exposing direct connections. A key technique we will discuss is utilizing the SSH GatewayPorts option. This option allows forwarded ports to bind to external network interfaces, making them accessible to collaborators or external systems. This feature is invaluable for providing temporary access, especially when a VPN is unavailable, as it enables secure communication and resource sharing across segmented environments.

First Scenario: Enabling Multiple Systems to Connect Through Remote Port Forwarding Tunnels

In the first penetration testing scenario, we will focus on enabling multiple systems to connect to a remote server and seamlessly access a locally running service. We can achieve this through Remote port forwarding, which allows you to expose a service running on your local machine to multiple external systems by creating a tunnel through an intermediate SSH server. This scenario is especially useful when your local machine is behind a NAT, firewall, or a restrictive network that prevents direct connections.

Real-World Use Case:

Imagine a penetration testing scenario where your Kali machine is running a web-based tool (e.g., Updog) on port 9090, but it’s behind a firewall that blocks incoming connections. By setting up a remote port forwarding tunnel, you can expose the service on the SSH server’s port 9090, enabling your collaborators to access it from their systems by simply connecting to the remote server.

This approach simplifies collaboration, bypasses restrictive network controls, and ensures that the service remains accessible without directly exposing your local machine to the internet.

How It Works

  1. Remote SSH Server as the Endpoint:
    The remote server acts as the publicly accessible entry point. External systems connect to this server on a specified port.
  2. Traffic Redirection to Local Machine:
    Traffic received on the remote server’s port is forwarded through the SSH tunnel to the service running on your local machine.
  3. Enabling Access for Multiple Systems:
    By binding the remote port to 0.0.0.0, you allow the remote SSH server to listen on all its network interfaces, making the forwarded service accessible to multiple systems.

What is GatewayPorts?

GatewayPorts is an SSH server configuration directive that determines whether remote hosts can connect to forwarded ports created by remote port forwarding. By default, SSH allows port forwarding to bind only to the loopback address (127.0.0.1), restricting access to the forwarded port to the local machine. GatewayPorts enables or disables the ability to bind to non-loopback addresses (e.g., 0.0.0.0 or specific external IPs), making the forwarded port accessible from other systems.

GatewayPorts – Possible Values

  • no (default):
    • Forwarded ports are only available on the loopback interface (127.0.0.1).
    • This restricts connections to forwarded ports to the local machine.
    • Example: Only the SSH client machine can access localhost:port.
  • yes:
    • Forwarded ports are bound to all available network interfaces.
    • This allows remote hosts to connect to the forwarded ports.
    • Example:
      • ssh -o GatewayPorts=yes -L 0.0.0.0:8080:example.com:80 user@remote.server.com
      • Any machine that can reach the server can access server_ip:port.
  • clientspecified:
    • The SSH client can specify the binding behavior (whether the forwarded port binds to all interfaces or just 127.0.0.1) using the bind_address option in the SSH command.
    • Example:
      • ssh -fnC -R 0.0.0.0:9090:127.0.0.1:9090 Binds to the loopback interface only.
      • ssh -fNC -R 0.0.0.0:9090:0.0.0.0:9090 Binds all the interfaces.

Requirements for Other Computers to Access the Tunnel

  1. Remote Server Accessibility:
    • The remote server (Cloud SSH Server) must be accessible to other systems.
    • A firewall (UFW) must not restrict the port used for forwarding.
  2. Tunnel Configuration:
    • Ensure the remote server allows connections on the forwarded port (GatewayPorts must be set to yes in the SSH server configuration if you use SSH for the tunnel).
    • For example, in the sshd_config file: GatewayPorts no change it to yes and Restart the SSH service after making changes.
  3. Authorization:
    • The systems using the tunnel must have permission (network access, user access) to connect to the remote server and the port.
  4. Firewall Rules:
    • Ensure firewalls or security groups allow inbound traffic to the remote server on the forwarded port.
  5. Local Binding on the Remote Server:
    • By default, some remote forwarding setups bind only to localhost on the remote server. To make the forwarded port accessible to other systems, you must bind it to 0.0.0.0 (all interfaces) or a specific interface on the remote server. For example:
ssh -fNC -R 0.0.0.0:9090:127.0.0.1:9090 rbt

This command forwards traffic arriving at remote-server:9090 to 127.0.0.1:9090 on the source machine.

Remote Port Forwarding Tunnels In Action

We have to ensure the remote server allows connections on the forwarded port (GatewayPorts must be set to yes in the SSH server configuration if SSH is being used for the tunnel).

Restart the SSH service after making changes.

sudo systemctl restart ssh.service

Once the GatewayPorts directive is set to yes; we can create and share the tunnel for collaborations.

Second Scenario: Enabling Multiple Systems to Connect Through Local Port Forwarding Tunnel

The second penetration testing scenario focuses on enabling multiple systems to connect via local port forwarding, a versatile technique that securely exposes a local service to multiple remote systems through an SSH tunnel. In this scenario, we configure a local port forwarding tunnel to allow external systems to access a service running on your local machine, providing controlled access via the SSH server.

For example, imagine you have a service running on port 8834 (Nessus) on your local machine, and you need external systems to access it without directly exposing your machine to the internet. By setting up a local port forwarding tunnel, we can route connections through an intermediate SSH server, allowing secure access to the service.

Real-World Use Case:

In a similar scenario, let’s say you’re conducting a penetration test and need collaborators to access a tool running on a separate local Kali machine, such as a web dashboard for data analysis or Nessus. Instead of exposing your machine directly, you establish a local port forwarding tunnel via a secure SSH server. This allows other testers to connect to the SSH server and securely access the tool without needing direct access to your machine.

This approach provides enhanced security, flexibility, and control over service access, ensuring only authorized systems connect through the tunnel.

How It Works:

  1. SSH Server as a Gateway:
    The SSH server acts as the gateway for all external connections. Remote systems connect to the server, which forwards their traffic to your local machine.
  2. Local Service Accessibility:
    You bind the tunnel to a local port on your machine (e.g., 8080) and route incoming traffic through the SSH connection to the intended service. This shields your local machine’s IP address and direct exposure.
  3. Enabling Multiple Connections:
    Multiple systems can access the forwarded service via the SSH server by configuring the tunnel appropriately (using 0.0.0.0 or an external-facing interface on the server).

Requirements for Other Computers to Access the Tunnel

  1. Remote Server Accessibility:
    • The remote server (macOS) must be accessible to other systems.
    • A firewall (UFW) must not restrict the port used for forwarding.
  2. Tunnel Configuration:
    • Ensure the remote server (cloud server) allows connections on the forwarded port (GatewayPorts must be set to yes in the SSH server configuration if we use SSH for the tunnel).
    • For example, in the sshd_config file: GatewayPorts no change it to yes and Restart the SSH service after making changes.
  3. Authorization:
    • The systems using the tunnel must have permission (network access, user access) to connect to the remote server and the port
  4. Local Binding on the Remote Server:
    • By default, some remote forwarding setups bind only to localhost the remote server. To make the forwarded port accessible to other systems, you must bind it to 0.0.0.0 (all interfaces) or a specific interface on the remote server. For example:
ssh -fNC -L 0.0.0.0:8834:127.0.0.1:8834 rbt

The image below shows that the Nessus server only runs locally on the localhost interface.

Allowing incoming traffic to the macOS system

Local Port Forwarding Tunnels In Action

Third Scenario: Enabling Multiple Systems to Connect Through Dynamic Port Forwarding Tunnel

Dynamic port forwarding is a powerful tunneling technique that creates a flexible SOCKS proxy, allowing multiple systems to route their traffic through an SSH server. Unlike local or remote port forwarding, where specific ports and destinations are pre-defined, dynamic port forwarding provides a more general-purpose solution for redirecting network traffic. This flexibility makes it ideal for scenarios where access to multiple services or destinations is needed without requiring separate configurations for each one.

This technique is particularly valuable in penetration testing or secure browsing scenarios, where multiple systems need to access various resources through the SSH server, helping bypass network restrictions or mask the origin of the traffic. While dynamic port forwarding is an efficient collaboration tool, each pentester must set up its tunnel to maintain security and accountability.

Real-World Use Case

Imagine a penetration test where a team needs to access multiple internal systems on a client’s network from a single Kali machine. By creating a SOCKS proxy through dynamic port forwarding, you can configure your tools, whether browsers, scanners, or exploit frameworks, to route their traffic through the proxy. Other team members can also use the same SOCKS proxy to reach the client’s internal systems, enabling collaborative efforts without exposing direct connections.

While this scenario is convenient, it’s essential that each tester creates their own dynamic tunnel. This ensures individual accountability, auditability, and the security of each tester’s activities within the client network. Sharing a tunnel could expose multiple team members to potential risks, particularly in case of an attack on one of the systems.

How It Works

  1. SOCKS Proxy Creation: Dynamic port forwarding sets up a SOCKS proxy on a specific local machine port. The proxy intercepts outgoing network requests and forwards them through the SSH tunnel to their intended destinations.
  2. Traffic Redirection: External systems (such as your team members’ machines) can configure their network settings or applications to use the SOCKS proxy. This effectively redirects their traffic through the SSH tunnel, masking their original source and enabling access to restricted or internal network resources.
  3. Multi-System Connectivity: By sharing the SOCKS proxy configuration, multiple systems can route traffic through the same SSH server. This allows testers to connect to various destinations dynamically without needing individual port forwarding setups. However, ensuring that the proxy is only shared with trusted individuals and that security best practices are maintained is essential.
  4. Once the tunnel is set up, we must provide the pentesters with the SOCKS proxy details to configure in their tools.
    • Proxy Address: <macOS-machine-ip>
    • Proxy Port: <1080>

Requirements for Other Computers to Access the Tunnel

  1. Remote Server Accessibility:
    • The remote server (macOS) must be accessible to other systems.
    • A firewall (UFW) must not restrict the port used for forwarding (1080).
  2. Tunnel Configuration:
    • Ensure the remote server (cloud server) allows connections on the forwarded port (GatewayPorts must be set to yes in the SSH server configuration if we use SSH for the tunnel).
    • For example, in the sshd_config file: GatewayPorts no change it to yes and Restart the SSH service after making changes.
  3. Authorization:
    • The systems using the tunnel must have permission (network access, user access) to connect to the remote server and the port
  4. Local Binding on the Remote Server:
    • By default, some remote forwarding setups bind only to localhost the remote server. To make the forwarded port accessible to other systems, you must bind it to 0.0.0.0 (all interfaces) or a specific interface on the remote server. For example:

Best Practices and Considerations

  • Individual Tunnels: Each pentester should ideally set up their own dynamic SSH tunnel to maintain security, flexibility, and accountability.
  • Access Control: If we decide to share the proxy, ensure it’s restricted to specific, trusted systems to minimize exposure. Always use firewall rules or IP whitelisting to limit access to the proxy on the remote server (macOS).
    • sudo ufw allow from <coworker-ip> to any port 1080
  • Anonymity and Privacy: Dynamic port forwarding helps mask the origin of the traffic, but the responsibility lies with each pentester to ensure their connections are secure and anonymous. It’s always safer to use your tunnel for critical tasks. However, if we still want to create it, the below command can be used.
ssh -fNC -D 0.0.0.0:1080 rbt

Conclusion

In this post, we’ve built on the foundation established in Part 1 and Part 2, exploring advanced SSH tunneling tactics through real-world penetration testing scenarios. By applying methods like remote, local, and dynamic port forwarding, along with leveraging features like SSH GatewayPorts, we’ve navigated common challenges such as bypassing strict network segmentation, enabling secure collaboration, and maintaining access to critical services without exposing direct connections.

This technique is more than theoretical; they’re practical solutions that allow penetration testers to efficiently navigate complex, segmented networks while avoiding detection and overcoming security defenses. Whether it’s facilitating secure communication across isolated environments, aiding collaboration, or enabling access to restricted services, mastering these skills is key to staying ahead of increasingly sophisticated defense measures.

As security infrastructures continue to evolve, this tunneling technique will remain crucial for penetration testers seeking to conduct thorough and effective assessments. Keep following along as we continue to push the boundaries, diving deeper into advanced strategies in the next posts.

Detections & Mitigations

Detection and Mitigations

Share the Post:

Table of Contents

Subscribe To Our Blog

Light