SENG: Application-grained Firewall Policies using TEE-based Traffic-to-App Attribution

Gateway routers operate network firewalls at the perimeter of consumer and enterprise networks to centrally govern all network communication and perform packet filtering. That way, gateway firewalls isolate internal from external networks, control access across internal subnetworks, and block communication to and from suspicious network addresses.

Firewalls typically leverage port and IP information or data from client-side agents to identify sender or receiver applications. That way, firewalls aim at permitting communication to and from known applications and services while denying unknown, potentially malicious network traffic (e.g., by malware). For example, standard ports like 443 and 993 would be associated with encrypted HTTP web and IMAP mail communication respectively.

However, existing traffic-to-application attribution methods are too coarse-grained and unreliable to securely prevent malicious network communication. Attackers can spoof port addresses, steal the identity of trusted applications by performing process injection, or compromise client-side firewall agents to manipulate application identifiers. The underlying root causes are that existing attribution methods do not protect the client applications and their network traffic against local system-level attackers, and do not use secure, unforgeable application identifiers. Therefore, trusted traffic-to-app attribution remains an open challenge of gateway firewalls, especially when considering strong client-side attackers.

To address this challenge, we introduce SENG, a gateway-located service coupled with client-side runtimes. SENG protects client applications and their traffic against strong system-level attackers and exposes hardware-based identifiers of them to the gateway. That way, the gateway can perform secure traffic-to-app attribution, even if the client hosts have been compromised. With SENG, network admins can then securely enforce per-application firewall policies at the perimeter using existing firewalls.
The client-side SENG Runtimes shield unmodified applications inside hardware-based trusted execution environments (TEEs), e.g., Intel SGX user space enclaves, using a library OS. That way, the code and data of the apps are isolated from system-level attacks (e.g., process injection attempts). In addition, the runtimes add secure TCP/IP stacks and DTLS modules into the application enclaves. The modules securely manage the network connections of the applications inside the enclaves and tunnel their traffic to the gateway-located SENG Server---protecting their communication against client and network attackers.
The SENG Server accepts the DTLS tunnel connections of the client-side runtimes and is responsible for performing the traffic-to-app attribution. The server uses the remote attestation protocol supported by the client TEEs to identify the exact hash of a shielded application and assign its runtime instance a unique enclave IP address. That way, the SENG Server can link the traffic to and from the DTLS tunnel connections exactly to the respective shielded client application. To expose the application identity to the gateway firewall, the SENG Server picks the enclave IPs from application-specific IP subnetworks. As a result, the gateway firewall can identify the type of a sender/receiver application based on the IP addresses, and therefore enforce app-specific firewall policies.

1. Define per-application IP subnetworks and inform the SENG Server about the list of associated applications (attestation hashes).
2. Replace the host IP subnetworks in firewall rules with the respective application-specific subnetworks.

For example, app subnetworks could group the most recent versions of browsers that are free of known vulnerabilities, or they could be restricted to SQL clients with TLS support. That way, existing firewalls can seamlessly enforce per-application rules on the app-specific subnetworks. Furthermore, as the SENG Server can distinguish between unshielded and shielded (tunneled) network traffic and attribute it to the corresponding application, the gateway can easily block network traffic by unprotected or unknown, potentially malicious applications and services.

We have implemented and evaluated a prototype of SENG for Linux with Intel SGX enclaves and the Graphene-SGX (now: Gramine) library OS. For more information on SENG, please check out the corresponding research paper that has been published at the USENIX Security conference 2020.

Optional Extensions

We have implemented an alternative client-side component which does not rely on a library OS, which is called SENG-SDK. SENG-SDK loses the support for unmodified Linux applications provided by a TEE library OS, but achieves better performance for server applications, e.g., the NGINX web server.
We have also implemented an optional extension to the Linux Netfilter and iptables firewall framework and the SENG Server, called SENG-Netfiler. SENG-Netfiler enables the direct specification of app-grained firewall policies via new iptables rule specifiers, which are then enforced by a Netfilter extension module. SENG-Netfilter provides better usability and does not require application-specific IP subnetworks---which decreases network fragmentation---but is tailored to the Netfilter/iptables firewall.
Finally, we have also implemented an alternative prototype of the SENG Server. While the original server prototype is implemented as a single-threaded C++ server, the SENG Go-Server is multi-threaded and implemented in the Go language.

All SENG prototypes, including the SENG-SDK, SENG-Netfilter, and SENG Go-Server, have been released as open-source projects on Github.