Boring Disclaimer Stuff
The OH-PP protocol being proposed in this post is notional. That means it does not exist in any production environment, in any lab environment, or in any development environment know to the author. This post is for entertainment and thought provocation. Any development of the protocol described in this article should follow the applicable clauses and requests.
Introducing OH-PP
Zero trust is great in theory but in practice is leaves much to be desired. This is exacerbated by vendors that have mutually exclusive definitions and implementations and vague recommendations and guidelines that are difficult to implement. This is a great stomping ground for a would-be advanced persistent threat (APT). An APT could leverage the false sense of security that an entity has been lulled into with the goal of total system bastardization and molestation. In this post I will propose the Outbound Honey-Proxy Protocol (OH-PP). OH-PP is a protocol that can be leveraged to identify threats from the inside using dynamically provisioned cloned instances that leverage an image/snapshot/checkpoint template. OH-PP uses a client-side module to authenticate out-bound connections from end-point devices based on user, protocol, port, and destination.
OH-PP Architecture & Operation
OH-PP is a server service that can be run on a stand-alone device or integrated as a service on a network device such as a switch. A client side module is required on user devices. The client side module intercepts requests for access to resources that are outside of the local VM or physical end-point device and forwards the request to the OH-PP server. The OH-PP server receives the request, validates the identity of the requestor then validates the recipient of the request. Upon successful validation the OH-PP server streams the recipient the payloads. If the request is unsuccessful the OH-PP server forwards the request to a dynamically provisioned image (on a remote server or internally on smaller deployments). The dynamically provisioned image is an interactive replica of the requested resource and permits security folks, investigators, and others the opportunity to be both alerted and provided observational opportunities into the actions of unauthorized activities. Once the connection is closed by the requestor a log of all actions taken is saved to a dated log-book and the image is destroyed.
OH-PP: Diving A Little Deeper
The client-side OH-PP module creates a network forwarding rule in the firewall that redirects all out-bound traffic to the OH-PP Client port. The OH-PP client port creates a connection request and forwards the request to the specified IP address, the address of the load-balancers in front of the OH-PP server pool. The OH-PP client port connection request is build by creating a TCP packet that holds the identity of the logged-in requester, the identity being used to request the remote service (ex. admin account for SSH), the remote resource being requested (by IP, FQDN, or URL), the local and remote ports, the local network, and the remote network that owns the resource. This packet is forwarded to the OH-PP pool through a dynamically created SSH tunnel.
OH-PP Processing
Upon receipt of the request the OH-PP server determines if
- the requesting port is permitted outbound requests for a particular service. Should port 35434 be requesting DNS records?
- the “logged-in” identity is permitted to use the identity being used to request the resource. For instance, is SallyRC permitted to use John.Admin to login to the DHCP server.
- either identity is permitted access to the remote network. Are either SallyRC or John.Admin allowed to access the GumDropBellyButton network?
- the requesting network is permitted to access the remote network. Is the CavityCorners network authorized to interact with the GumDropBellyButton network?
- if the requesting network is permitted connections to the recipient resource.
If any of the connection request checks fails an alert is triggered and forwarded to the administration team while the connection request is forwarded to the dynamic resource replication repository. The dynamic replication repository “spins up” a replica of the requested resource inside a container with imitation data. All actions the requestor performs on the dynamic replica is logged and monitored while any “added” data (downloads and all data not native to the image) is encrypted, hashed, and saved in an “evidence” container. The evidence container is password protected using a pre-defined administrator password.
OH-PP Rules
If any of the connection request checks fails an alert is triggered and forwarded to the administration team. If the OH-PP server is in “full-learning” mode all connections are permitted and rules are dynamically created to permit every connection once “Full Restriction” is implemented. This mode is not intended to be used outside of a lab or test network where quickly generating rules is required to begin testing with little to no configuration. The “Assisted Learning” mode builds a table of connections that have been created over the last seven (7) days in priority order. The list specifies the number of connection requests, the requesting network, and remote network. The administrators can drill down to see the requesting identities and ports for greater granularity and specificity. In this mode the administrator click an “Permit” or “Block” button in the “Rule Action” column to create a rule based on these aggregated connections. In the “partial Restriction” mode the Administrator can create broad or specific rules. Broad rules are rules that do not have all data points defined whereas specific rules have every data point defined for every connection. The “Full Restriction” mode only permits connections that have fully developed specific rules. The fully developed specific rules can be created by manually entering each data-point for each rule or they can be provisioned from the “drilled down” table that lists all connections that have take place for the previous 7 days.
OH-PP Configurations
The OH-PP server requires a certificate for authentication with the OH-PP clients. This can be a PKI or internal certificate. The second step in configuring OH-PP is defining any network exceptions. It is recommended that organizations create an exception for the public IP space to permit users access to the internet from any network and identity on ports 443 and 80. If there are specific internal or external IP address ranges or networks that should be blocked due to internal policy they can be removed from this blanket exception. The third step is to permit OH-PP the ability to query the active identities in the identity repository (AD, Cloud provider identity store, etc.) by providing pertinent information to OH-PP. Number four on the list is creating the OH-PP dynamic images. This can be performed on the local OH-PP device but is better suited to a pool of dedicated devices for all but the most minimal of deployments. The OH-PP image pool houses a partition with the baseline templates. That partition is the most essential portion of OH-PP. The images must be identical to the requested resource with the exception of the data within the image. The directory names and structures should be identical but the data files should only contain imitation data that is similar to production data but which has no production data. Again, no production data should ever be used in OH-PP images. Number five on the list is to connect the OH-PP server pool to the OH-PP image pool. The final step is to implement the rules and begin analyzing the internal infiltrators and abusers.
OH-PP’s Good & Bad
OH-PP can assist in detecting threats that have compromised internal resources, to include identities, but it is not perfect. OH-PP can be mis-configured in a way that permits too great of access to unauthorized identities. Likewise, OH-PP can be too restrictive and prevent the flow of appropriate traffic. On the client devices, if the OH-PP modules are not protected and made difficult to identify an attacker may be cognizant of it’s presence. This may act as a deterrent to many attackers but it could also instill a false security bravado in implementing entities as the most determined attackers will determine ways to abuse this protocol. This protocol is not a panacea, it is only one tool in the tool box that is designed to work harmoniously with other protocols.
An OH-PP Summary
A notional protocol OH-PP be, but it may thwart attackers and let defender see, detailed completion of set-up is key, if your network data is stolen don’t blame me. Zero trust may be great, but it comes a little late, the flood is still pouring through the gate, it is time for the next generation of devices designed to abate. OH-PP may weaken the stream of attacks but not if it doesn’t gets programmed asap. This post was fun, but I gotta run. This post is only to make you think, is zero trust really the hacker-proof link? Thank you for reading and enjoy pondering my OH-PP.