Introduction
When we talk about security, and in particular, malware defenses, we spend a lot of time focusing on the capabilities of a product or an entire security stack. We want to know what types of malware a solution covers to get a sense of how effective that solution is. But beyond that, and something that’s not always obvious, is exactly how a solution “sees” the traffic. Now I’m not talking about decryption. Clearly that needs to happen somewhere in the stack for the malware solutions to actually be useful. What I’m referring to though is how traffic actually gets TO the security stack. For an Internet-facing web application that’s usually obvious – it’s routed to an IP address, it's TCP-based, it's wrapped in TLS encryption, and it's application layer HTTP. Client browsers send a request that’s routed across the Internet, arriving at a firewall, and then transported internally to a web server, maybe passing through a load balancer, proxy server, WAF and/or DDoS solution to get there. In any case, this describes a common “reverse proxy” scenario.
But this is not the ONLY way that malware security solutions are employed. For example, in an enterprise scenario, it is just as important to apply defenses to the outbound flow for traffic leaving the network to the Internet (or perhaps other business units). But in a forward proxy, the how isn’t always as obvious. To get traffic to the security stack, SSL Orchestrator natively supports inbound and outbound flows, layer 3 (standard routing), layer 2 (bump-in-the-wire), and explicit HTTP proxy. You can also turn on WCCP, BGP, OSPF and others to enable dynamic routing, and WPAD and Proxy PAC files to enable dynamic proxying. You can deploy SSL Orchestrator inline of the traffic flow, or “on-a-stick”. You can even deploy SSL Orchestrator as a load balanced solution for greater scale, using another BIG-IP or even ECMP*. Truth be told, most other TLS visibility products only handle a small subset of those just listed.
But there is something I subtly didn’t mention. SSL Orchestrator supports explicit proxy for HTTP/HTTPS traffic. An explicit proxy is a type of proxy that the client is aware of and must target directly. The proxy creates a TCP connection to another server behind the firewall on the client’s behalf, usually employed when the client is not permitted to establish TCP connections to outside servers directly. This would be the proxy server settings in your browser configuration. The native HTTP explicit proxy support is fine for anything a browser needs to talk to, but there may be scenarios where a proxy server is required in an environment for other protocols. For that, the “Socket Secure” (SOCKS) protocol could be a reasonable option. SOCKS isn’t built into the SSL Orchestrator configuration, but BIG-IP has had it forever, and as you’ve no doubt heard me say a few times the flexibility of the BIG-IP platform prevails. In this article I’m going to show just how easy it is to enable a SOCKS proxy listener for SSL Orchestrator. Let’s go see what that looks like!
SSL Orchestrator Use Case: Integrating SOCKS Proxy
To start, it’s important to understand that SSL Orchestrator creates an HTTP explicit forward proxy with two virtual servers:
The first is the actual proxy virtual server. This contains the IP address and port that the client will configure in its proxy settings. All proxied traffic from clients will enter through this virtual server. The second is the TCP tunnel virtual server. This is where SSL Orchestrator decryption and service chaining magic happens. This virtual server listens on an internal “tunnel” VLAN provided by the proxy virtual. Traffic enters through the proxy virtual and is forwarded (wrapped) through the TCP tunnel virtual. The TCP tunnel virtual server is basically identical to a transparent proxy, but that’s just listening internally for traffic.
To create a SOCKS proxy implementation, we are simply going to:
- Create the SOCKS proxy virtual server configuration manually
- Create an SSL Orchestrator transparent proxy topology
- Add the internal proxy tunnel VLAN to the resulting transparent proxy virtual server(s)
In the same way that the native HTTP explicit proxy works, traffic will enter the SOCKS proxy VIP and wrap around to the TCP tunnel (transparent proxy) virtual server that the SSL Orchestrator created for us.
Licensing and Version Requirements
The beauty here is that you simply need SSL Orchestrator to do this. The SOCKS proxy profile is a function of Local Traffic Manager, which is also included in the standalone SSL Orchestrator license. As for versions, your best bet is any SSL Orchestrator version 9.0 or higher. It will certainly work with earlier versions, but in those you’ll need to disable configuration strictness. Versions 9.0 and above remove this requirement.
Configuring a SOCKS Proxy
To build a SOCKS proxy virtual server, you’ll need a DNS resolver, TCP tunnel, SOCKS profile, and a virtual server:
- DNS resolver: In the BIG-IP UI, under Network – DNS Resolvers – DNS Resolver List, click Create. Give this DNS resolver a name and then click Finished. Now click to edit this resolver, move to the Forward Zones tab, and click Add.
- Name: enter a single period (“.”, without the quotes)
- Address: enter the IP address of a DNS nameserver
- Service Port: enter the listening port of that DNS nameserver (almost always 53)
- Click Add to complete.
- TCP tunnel: In the BIG-IP UI, under Network – Tunnels – Tunnel List, click Create. Give this tunnel a name.
- Profile: tcp-forward
- Click Finished to complete.
- SOCKS profile: In the BIG-IP UI, under Local Traffic – Profiles – Services – SOCKS, click Create. Give the SOCKS profile a name.
- Protocol Versions: select the required versions to support, usually just Socks5
- DNS Resolver: select the previously created DNS resolver
- IPv6: enable this if IPv6 is required
- Route Domain: set this if a unique (non-zero) route domain is required
- Tunnel Name: select the previously create TCP tunnel
- Default Connect Handling: set to Deny
- Click Finished to complete
- SOCKS virtual server: In the BIG-IP UI, under Local Traffic – Virtual Servers – Virtual Server List, click Create. Give the virtual server a name.
- Source: 0.0.0.0/0
- Destination Address/Mask: enter the proxy IP address that clients will access
- Service Port: enter the port for this SOCKS proxy instance
- SOCKS Profile: select the previously created SOCKS profile
- VLANs and Tunnels: select the client facing VLAN
- Source Address Translation: set to None
- Address Translation: set to enabled
- Port Translation: set to enabled
- Click Finished to complete.
This is all that you really must do to create the SOCKS proxy configuration. The next step is to create the TCP tunnel virtual server(s), and for that, we’ll let SSL Orchestrator do the work.
Configuring SSL Orchestrator
You’re going to create an L3 Outbound SSL Orchestrator topology. This will minimally create one TCP forward proxy listener, but you also can create separate listeners for other StartTLS protocols (i.e., SMTP, IMAP, POP3, FTPS). In the interest of brevity, we won’t go through the entire topology configuration in detail. For deeper insights into all of the available settings, hop on over to the SSL Orchestrator deployment guide: https://clouddocs.f5.com/sslo-deployment-guide/. The following will serve as a skeleton for the full topology workflow. In the SSL Orchestrator UI, under Configuration, start a new topology configuration.
- Topology Properties: provide a name and select L3 Outbound.
- SSL Configurations: set your CA certificate key chain.
- Services List: create the security services
- Service Chain List: create the service chain(s) and attach the services as required
- Security Policy: adjust the security policy as required
- Interception Rule: select any VLAN (we will modify this later). Optionally select addition L7 Interception Rules for FTP, IMAP, POP3, and SMTP.
- Egress Settings: select SNAT as required, and select gateway settings as required
Review the settings and then deploy this configuration. If you’re on a version of SSL Orchestrator older than 9.0, you will need to disable strictness on the new topology. This is the little lock icon to the far right of the listed topology. Note that you’ll need to leave this unlocked, and any changes you make outside of the SSL Orchestrator configuration could be overwritten if you re-deploy the topology. In versions 9.0 and higher, the strictness lock has been removed, so you can freely make the required SOCKS proxy modifications.
Once the SSL Orchestrator topology is deployed, head over to Local Traffic – Virtual Servers – Virtual Server List in the BIG-IP UI. You will potentially see a lot of new virtual servers here. Most will have names that correspond to the security services you created, prefixed with “ssloS_”. But you’re looking for virtual servers that are prefixed with “sslo_” and then the name of the topology you just created. For example, if you named the topology “test”, you would see a virtual server named “sslo_test-in-t-4”. This is the standard transparent proxy (TCP tunnel) virtual. If you opted to create the additional L7 interception rules, you’ll see separate virtual servers for each of these. Again, for example, “sslo_test-pop3-4”, would represent the POP3 tunnel listener.
To enable the SOCKS proxy, edit each of these “sslo_” virtual servers and replace the existing selected VLAN with the TCP tunnel you created in the above SOCKS proxy configuration steps. That should be it. Configure a client to point to your SOCKS proxy and test. That traffic should arrive at the SOCKS proxy virtual server, and then wrap back through the respective TCP tunnel virtual. The SSL Orchestrator configuration on that tunnel will handle decryption and service chaining to the security stack.
Testing your SOCKS Proxy
Now, if you’re reading this article, you’re either the highly motivated, super inquisitive type, which is awesome by the way, and/or have a real need to implement a SOCKS proxy for your decrypted malware security stack. For the latter, you probably already have a set of tools that needs a proxy to get to the Internet, so you can use those to test. But if you don’t, I’ve taken the liberty to add a few below to get you started. Nothing fancy here, just some simple command line utilities to test your new SSL Orchestrator SOCKS proxy implementation. Let’s also assume for examples below that the SOCKS proxy is configured to listen at 10.1.10.150:2222. We’ll use the set of test services at rebex.net to try these out. When a password is required, it’s ‘password’.
SSH:
ssh -o ProxyCommand='nc -X5 -x 10.1.10.150:2222 %h %p' demo@test.rebex.netSFTP
sftp -o ProxyCommand='nc -v -x10.1.10.150:2222 %h %p' demo@test.rebex.netHTTP and HTTPS
curl -vk --socks5 10.1.10.150:2222 https://www.example.comFTP and FTPS (implicit)
curl --socks5 10.1.10.150:2222 -1 -v --disable-epsv --ftp-skip-pasv-ip -u demo --ftp-ssl -k ftps://test.rebex.net:990/pub/example/readme.txt -o readme.txtCaveats
As you can tell, we’re just swapping out the HTTP explicit proxy front end for a SOCKS proxy front end. This layer’s job is primarily to establish the client’s server-side TCP socket (on the client’s behalf), and then forward everything through the established tunnel. All of the SSL Orchestrator magic happens inside that tunnel. The SOCKS proxy itself does not introduce any new constraints. It’ll work with mostly any protocol that an SSL Orchestrator L3 Outbound topology will handle. The only significant caveats are:
- BIG-IP cannot decrypt outbound SSH (and SFTP). It can, however, be service chained.
- BIG-IP's FTP profile does not support passive mode FTP through a SOCKS proxy configuration. To get FTP traffic to flow, remove the FTP virtual server configuration from the SSL Orchestrator topology (sslo_xxxx-ftp-4). This removes the FTP profile and allows the use of SSL Orchestrator as a SOCKS proxy for FTP. Note also that for a standard explicit outbound SSL Orchestrator topology, passive FTP works correctly with the FTP virtual server and FTP profile.
- Active mode FTP is not supported in any outbound proxy configuration.
Resources
Below is a small list of resources to further your SSL Orchestrator and SOCKS proxy education:
- Not that you’ll need any of this to implement the above solution, but if you just want to get nerdy with details on how SOCKS works, try this: https://en.wikipedia.org/wiki/SOCKS.
- If you have any questions about setting up SSL Orchestrator, the official deployment guide is your friend: https://clouddocs.f5.com/sslo-deployment-guide/.
- To see a full list of test services available at rebex.net, see the following: https://test.rebex.net.
Summary
And there you have it. In just a few steps you’ve configured your SSL Orchestrator solution to work as a SOCKS proxy, and along the way you have hopefully recognized some of the immense flexibility at your command.
