Network Function Virtualization (NFV) promises the benefits of reduced infrastructure, personnel, and management costs by outsourcing network middleboxes to the public or private cloud. Unfortunately, running network functions in the cloud entails security challenges, especially for complex stateful services. In this paper, we describe our experiences with hardening the king of middleboxes - Intrusion Detection Systems (IDS) - using Intel Software Guard Extensions (Intel SGX) technology. Our IDS secured using Intel SGX, called SEC-IDS, is an unmodified Snort 3 with a DPDK network layer that achieves 10Gbps line rate. SEC-IDS guarantees computational integrity by running all Snort code inside an Intel SGX enclave. At the same time, SEC-IDS achieves near-native performance, with throughput close to 100 percent of vanilla Snort 3, by retaining network I/O outside of the enclave. Our experiments indicate that performance is only constrained by the modest Enclave Page Cache size available on current Intel SGX Skylake based E3 Xeon platforms. Finally, we kept the porting effort minimal by using the Graphene-SGX library OS. Only 27 Lines of Code (LoC) were modified in Snort and 178 LoC in Graphene-SGX itself.
Network Function Virtualization (NFV) is a growing trend to move middleboxes such as switches, load-balancers, and firewalls from private networks into the cloud [1]. This allows companies to significantly reduce their infrastructure costs and ease resource management. The conundrum, however, is how to protect confidentiality and integrity of network functions once they are outsourced to a possibly adversarial cloud [2].
Adding protections to outsourced network functions is no easy task. To highlight its complexity, we focus on the “king of middleboxes” -Intrusion Detection Systems (IDS’s) -and discuss how current research efforts fail to protect them. In particular, we dissect Snort3 -the most popular and mature open-source IDS [3].
First, IDS’s are complex software systems that detect network attacks by analyzing all traffic against a set of signature-, protocol-, and anomaly-based rules. For example, Snort® decodes network packets, reassembles streams, maintains flow states, runs them through a string of protocol-and application-specific detectors, performs complex pattern matching, and signals alarms on suspicious traffic. Unfortunately, state-of-the-art crypto-scheme solutions for securing middleboxes such as BlindBox [4] and Embark [5] cannot support this rich IDS functionality.
Second, due to the aforementioned complexity of IDS’s, it is undesirable to build a new system from scratch or to introduce intrusive changes in the existing codebase. Snort® has seven library dependencies, with 1 million LoC of C/C++ code; rewriting or modifying it for security purposes would be too time-consuming and error-prone. This requirement for legacy code support renders the whole middlebox-framework line of research [6][7][8][9] unsuitable for IDS’s.
Third, IDS’s must sustain high line rates of 10-40Gbps, e.g., a typical deployment of Snort® spawns many threads to achieve desired throughput. This requirement is at odds with software-based cryptographic solutions that inevitably degrade performance [4,5]. The better alternative is to use hardware support such as Intel® SGX [10] that provides integrity and confidentiality guarantees to applications while maintaining acceptable performance.
These three requirements dictated our approach to harden IDS’s for security with the example of Snort®. To side step the complexity of Snort®, we put its entire functionality inside the Intel® SGX enclave and require (almost) no code modifications. For performance, we keep the DPDK packet acquisition layer and the packets themselves outside of the enclave and feed pointers to them to Snort® via lockless ring buffers. We call the final system SEC-IDS.
The porting effort was kept minimal by using the Graphene-SGX library OS [11]: only 27 LoC were modified in Snort® and 1,205 LoC in the DPDK layer. We also resolved minor challenges of Snort®-DPDK separation and trusted clocks along the way, leading to 178 changed LoC in Graphene-SGX.
Our evaluation shows that SEC-IDS achieves near-native speed on workloads where Snort® state fits into Intel® SGX’s Enclave Page Cache (EPC), with throughput close to 100% of vanilla Snort®. Larger workload sizes can be accommodated with future versions of Intel® SGX, where the EPC size is expected to grow.
In this work, we describe the challenges of achieving near-native performance for Intel® SGX-hardened IDS (or indeed any highperformant complex application) as well as justify our design choices. In particular, we provide guidelines on cleanly separating trusted and untrusted parts of the application and avoid expensive system calls.
Intel® SGX. The Intel® Software Guard Extensions (SGX) is an ISA extension for recent Intel® CPUs that provides confidentiality and integrity protections for sensitive parts of applications [10]. With Intel® SGX, the code and data to be protected are put inside an Intel® SGX enclave -a region of memory that is opaque to all other software including privileged OS/hypervisor. The code inside the enclave can execute almost all CPU instructions (see important exceptions below) and can access data both inside and outside of enclave. Any attempt to access enclave data from outside of the enclave fails.
At the hardware level, a handful of new x86 instructions were introduced to initialize, start, resume, and exit an enclave. When in enclave mode, the CPU disallows context switches to kernel (i.e., syscall and int instructions). Thus, when an interrupt or a system call happens, an enclave is first exited, the interrupt/syscall is handled by the kernel, and the enclave is resumed. Since an enclave exit is an expensive operation, this execution pattern leads to high performance overheads [12,13].
Another currently unsupported instruction is rdtsc, the low-overhead relative time source [14,15]. Unfortunately, a lot of real-world software relies on this instruction, usually through library or system calls such as gettimeofday and clock_gettime. The usual (but not se
This content is AI-processed based on open access ArXiv data.
