Towards An SDN Assisted IDS

Robert Sutton1 , Robert Ludwiniak1 , Nikolaos Pitropakis1 , Christos Chrysoulas1 , and Tasos Dagiuklas2
1
School of Computing, Edinburgh Napier University, Edinburgh, United Kingdom
2
School of Engineering, London South Bank University, London, United Kingdom
Email:[email protected], {r.ludwiniak,n.pitropakis,c.chrysoulas}@napier.ac.uk, [email protected]

Abstract—Modern Intrusion Detection Systems are able to based on the usecases of the IDPS can be rerouted away from
identify and check all traffic crossing the network segments that the normal traffic path and pushed through another IDPS that
they are only set to monitor. Traditional network infrastructures is tuned specifically to inspect the specific segment of the
use static detection mechanisms that check and monitor specific
types of malicious traffic. To mitigate this potential waste of traffic. In this way, an IDPS can have a very small ruleset
resources and improve scalability across an entire network, we and pass traffic in the least possible time as multiple rules
propose a methodology which deploys distributed IDS in a are not checked against every packet passing the sensor, thus
Software Defined Network allowing them to be used for specific minizing the overhead. As a modern network has virtualised
types of traffic as and when it appears on a network. The core infrastructure, it may also be possible to make IDPS decisions
of our work is the creation of an SDN application that takes
input from a Snort IDS instances, thus working as a classifier on individual sensor load and to even dynamically provision
for incoming network traffic with a static ruleset for those new virtual IDPS sensors as required. This is feasible as
classifications. Our application has been tested on a virtualised indications of load being fed to the forwarding tables via traps
platform where it performed as planned holding its position for from IDPS fed back into the controller API. This results in an
limited use on static and controlled test environments. improvement by placing the sensor at a network bottleneck as
Index Terms—SDN, IDS, Network Security
means smaller loads of network traffic are being inspected by
I. I NTRODUCTION more IDPS [2].
Traditional networks have a static architecture which is The aim of our work was to design and develop a system
decentralized and complex. The needs of modern society that leverages the configurability of an SDN to divert traffic
lead towards networks that have more flexibility and easy of some interesting nature out to an Intrusion Detection
troubleshooting. Software Defined Networks (SDN) are the System (IDS) system for inspection. The motivation behind
answer to the aforementioned problem, used to centralise our work is two fold: a) a network segment might be too
the expensive, computationally inefficient elements of traffic busy for a single IDS sensor to cope with the load; and b)
routing and forwarding from the conventional practice of the majority of traffic over a link is known to be safe and
having these elements present on every forwarding device can be discounted, or cannot be inspected and therefore can
in a network [1]. SDN abstracts these processes away from be manually selected not to be inspected by an IDS. For the
the forwarding devices and handles them by using a network shake of our experimentations SNORT [3] has been used,
controller to keep track of the network infrastructure and one of the most common and well-supported IDS platforms
calculate forwarding paths which are then communicated back available. We can also take advantage of the previous work
to the forwarding devices. surrounding its performance, capabilities and variations on
In a conventional network, Network Intrusion Detection and deployment including in a distributed environment and with
Prevention Systems (IDPS) are placed at strategic points in the use in an SDN.
network over which the majority of the traffic will traverse
The contributions of our work can be summarised as fol-
to offer them the best chance at identifying malicious traffic.
lows:
IDPS usually add latency to the network traffic and the more • The creation of a testbed network using an SDN vSwitch,
complex the inspection of any given packet is, the more time a controller for the same, one or more IDS and a device
the packet is delayed on its journey. For a large, aggregated to run SNORT.
network link, which would otherwise seem to be the best place • The forwarding of suspicious data into an SDN controller
to place such a security mechanism, the latter configuration that itself then pushes data to specific points on an SDN
causes the potential for inefficiency and slowdowns of the for inspection.
traffic along with the risk of missing packets, thus indicating • The evaluation of the performance levels of the SDN, and
a security issue. the IDS being used to inspect traffic.
To mitigate this, IDPS devices can often be deployed in The rest of the paper is organised as follows: Section II briefly
a more distributed design, with sensors being placed around describes the related literature, while Section III analyses our
the network and reporting security events back to a central experimental setup. Section IV describes the implementation
sensor or controller. Traffic classified as worthy of inspection of our methodology and provides the evaluation of our exper-
978-1-6654-4399-9/21/31.00© 2021 IEEE imental setup, and the applied mechanisms and technologies.
Finally, Section V draws the conclusions giving some pointers that watches logs coming from the honeypot, thus generating
for future work. Snort rules from them and performing checks.
The authors of [14] present a system which is a self-
II. L ITERATURE R EVIEW
contained Snort IDS, IPS and database for historic traffic
A. SDN and Attacks and alerts. Their work use dynamic rule creation and redirec-
Hakiri et al. [4] provide an excellent overview of SDN and tion to honeypot servers. Kirill Shipulin [15] discusses some
its present challenges when it comes to networking. In [2], techniques for IDS bypassing and specifically for overloading
Ibrahim et al. review several other works in SDN and IDS. an IDS CPU with crafted requests against poorly designed
Giotis et al [5] note that related literature seems to concentrate signature rules. The work by Yuan et al. [16] describes a
heavily on DDoS attacks and their detection and mitigatio system to load-balance traffic across a distributed Network
while pointing out the control plane overloading as part of Intrusion System (NIDS) infrastructure in response to network
these detection mechanisms. Papadogiannakis et al. [6] suggest load and the load of individual IDS components. The authors
that there is sufficient time for a detection mechanism to be argue that a single IDS on a large and busy network segment
successful while alerting other system. However, this seems can be vulnerable to packet loss and as a result of that some
too slow to prevent certain attacks which have short lifespan, form of distributed IDS setup is imperative.
resulting in late detection of a threat which will have already Vallentin et al. [17] propose a system comprised of a
been propagated. commodity grade array of Bro (now Zeek) sensors [18] which
Jantila et al. [7] take the findings of the previous works one are used to share the load of monitoring of a busy network.
step further by discussing an SDN classification application This system uses some SDN-like features to achieve its task.
which prevents DDoS against a webserver. They score the As an example the authors created a hashing algorithm to
interactions of the webserver and feed this information back determine to which of the Bro sensors a traffic flow should
through an SDN controller to the flow tables of the switching be send, as a result of the hash, thus the destination MAC
fabric. However, the specific methodology as it is web based of the packets is rewritten and sent to the chosen sensor.
it produces delays not meeting real world needs. Shin et Another interesting element of this work is the presence of
al. [8] detail an application development framework, namely the orchestration element that is responsible for starting and
FRESCO for security services within an SDN. They note that stopping sensor nodes as well as monitoring for failures and
there is limited functionality within an SDN for embedded bringing backup sensors into function. From another point of
security functions and attempt to mitigate that by adding state view Pitropakis et al. [19] gather intelligence from multiple
databases, providing the framework with support for security sensors and and correlate it with open source intelligence to
modules and interaction externally via an API, and enhancing face more advanced threats.
what they believe is a very simplistic approach for feeding C. Snort Performance
back responses to the SDN. Alhomoud et al. [20] compare Snort and Suricata over
AlEroud et al. [9] focus on attacks against the SDN itself in- several levels of traffic load on two different host operating
stead of attacks flowing over the SDN. Their work investigates systems and one virtualised environment. The work shows a
the limits of an SDN when only inspecting the packet headers clear advantage of Snort over Suricata on almost all of the
while achieving good detection rates over attack traffic. Xing criteria selected for comparison. In [21], the authors discuss
et al [10] focus on measuring the performance of an IDS the issue of categorising Snort rules into a useful set for
sited away from a controller, with the end goal of providing specific administrators in large environments. The authors
mitigation from the IDS to the SDN. Their work investigates argue that the current classification schemes as provided by
mitigations such as blocking, quarantine and redirection to a the default Snort installation are poor, lacking detail and
deep packet inspection device, but solely on a cost to the SDN formalisation, thus making it difficult to find an appropriate
basis. Chung et al. [11] have a setup in their IDS devices which set of rules tuned for a test or environment.
is being transparently placed in front of tenants in a cloud More recently, Bul’ajoul et al. [22] studied the performance
environment. Their traffic classification is performed on traffic of the Snort IDS and this performances variation to the
to and from tenants and from untrusted networks. If necessary addition of Quality of Service (QoS) on the legacy network
the traffic can be inspected fully by a transparent IDS in its equipment that is feeding a Snort sensor. They found that
path or subject to other countermeasures as appropriate to the the switch fed the sensor traffic as fast as the forwarding
classification. would allow and this led to Snort dropping huge amounts of
B. IDS packets in the rush to queue and process them. To partially
Ajaeiya et al. [12] propose a solution with an IDS inte- address this issue the authors experimented with multiple Snort
grated within an SDN controller where they classify flows sensors connected to a switch and forwarded traffic to each
and apply coarse entries into the flow-tables based on these based on ACLs (Access Control Lists) within the switch.
classifications. From another point of view Sagala et al. [13] Their experimentations proved that by using one sensor each
attempt to integrate an honeypot setup alongside an IDS where for UDP, TCP and ICMP traffic, they were able to bring
the honeypot is feeding a ruleset to the IDS based on the down the processing time to a third of that with a single
behaviour observed upon itself. In specific they create a system sensor. From a similar point of view, Bechtolsheim et al. [23]
leverage similar ideas but move the network infrastructure down to be checked based on the nature of the flows that are
away from legacy network equipment and ideally away from observed coming into the switch or to the destination servers.
using slower features of switches such as QoS and ACLs. To resolve this issue another Python 3 program has been
Papadogiannakis et al. [6] propose an interesting take on developed to take a parsed list of destination ports against the
improving the performance of an IDS by selectively either rule files theyre specified in. Soon afterwards these files would
ignoring or discarding packets from possible inspection. They be selected and added them into a Snorts configuration file for
state that most security incidents are going to be detected in inclusion in the rules the traffic was checked against. After
the initial few thousand bytes of a network flow and that it is careful consideration we decided that a reasonable criteria for
unwise and possibly damaging to the efficiency of an IDS to choosing a specific Snort instance to work on a set of traffic
spend inspection time on flows that last for much longer than with a set of rules should be the similiarity of the destination.
this, giving VoIP, streaming, P2P traffic and file transfers as This is broadly in line with choosing rules that would only
examples. Vasiliadis et al. [24] use the CUDA architecture for be applicable to the services being targeted of interest to an
executing Snort, naming their system Gnort. They managed administrator or analyst.
to transfer large volume of the computational overhead to the Test Network and Server Infrastructure: Our platform
GPU, thus speeding up the efficiency of the NIDS, reducing of choice was a GNS3-hosted infrastructure. Because of the
at the same time the overhead on the CPU. selected platform, VMs prepared for the controller, Snort sen-
Our work differs from all the previous approaches because sors, generator and receiver machines could be built and tested
we are aware of the attacks a network under inspection may independently and then imported into the GNS3 project con-
be subject to as signatures may already be in place on one or taining an OVS vSwitch (with management features) docker
more Snort sensors to provide the detection for the attacks. container running on the GNS3 VM. This should then persist
The QoS element is out of the scope of our work and instead over many iterations of testing. The network has been set out
we focus on the distribution of the detection overhead over in a very basic layout as shown in Fig. 1. This configuration
more sensors rather than letting one sensor take as long as it allows traffic to be sent from the source host to the destination
needs to complete the task. We do not send data to a Snort host via the vSwitch. All the devices on the network also
sensor but the data are mirrored off to one or more sensors have a back- channel connection to a NAT cloud to allow for
as appropriate aiming for the native acceleration of the traffic device updates and traffic that has no requirement to be routed
throughput. Additionally, the goal of our work is to distribute through the SDN. This is an effective managed network for
the detection over more sensors rather than letting one sensor the virtual hosts. The only traffic that will be traversing the
do it as it needs more time to complete the task. We are also vSwitch will be the test traffic. API calls to the controller
making a diversion from the ACL approach by adding flows and controller management and GUI will be sent on the
into the forwarding table per flow on a controller, rather than management network.
per frame with an ACL. For larger flows this should represent Controller and flow manipulation: During the initializa-
a time and processing saving. tion of the testbed, particualar emphasis has been given to
directing traffic from the generator machine to the receiver
III. E XPERIMENTAL S ETUP machine via the vSwitch. This is an easy step, because by
Before explaining our experimental setup in detail, it is default the GNS3 vSwitch works as a standard Layer 2 switch
considered necessary to discuss the use of two tools that had even without being connected to an external controller (Ryu)
an important role. The first one is PySnorter a tool for routing [25]. The GNS3 vSwitch container allows connections to a
traffic to dedicated Snort instances which is written in Python controller or a controller network via one of the virtual ports.
3. Its functionality can be summarized as: a) Monitoring In our case, a VM running the OF controller has been directly
an alert file from a Snort instance behaving as a classifier; connected to this port. The vSwitch was configured with the
b) Pulling in information from the alert; and c) Using the IP address of the controller and once the controller service
information in the alert to generate a REST API command that was starting, then the control of the switchs features was
is then sent to the controller. The aim of PySnorter is to have handed over to the controller. Although Ryu provides a lot
a very generic Snort instance always listening for suspicious of functionalities related to our work, it does not focus on
traffic, which then generates alarms capable of sending off the separating traffic amongst Snort instances.
traffic to other Snort instances where the ruleset is specific to it. Traffic is passed freely amongst the devices, only limited
The latter functionality is hoped to reduce the amount of rules by the basic network constraints of the devices such as
that are checked against traffic for which there is no chance MTU/MSS and the virtual throughput of the vSwitch and the
of a match, thus reducing the likelihood of missed packets in hosts performing the generator and receiver roles. To begin
the IDS process and accelerating the traffic inspection. classifying and redirecting traffic to IDS devices relevant to
The expectation for any production environment will vary the monitored traffic, it should be mirrored off to an initial
based on the exact requirements so it is rather uncertain IDS. This required a manual flow to be added to the switch.
whether a fully automated system of applying rules to Snort Snort Triage Device: The Snort process has been config-
instances is useful or desirable. For the shake of our exper- ured through a file to both point at the relevant rules file
iments, it is useful if the volume of rules could be broken and also output the alerting in a format that is compatible
 Fig. 1. Initial network setup for POC

TABLE I The SDN device runs within a docker container on the GNS3
PCAP FILES FROM CONSECUTIVE NMAPS VM which also handles the links between the two.
Filename Nmap Duration (s) Filesize (kB) kB/sec For the next series of runs, it has been decided to also
nmapRun1 342.14 53058 155.08 add in the Ryu controller to manage the switch. The Ryu
nmapRun2 347.76 52903 152.13
nmapRun3 347.36 52936 152.40
controller was initiated and four more runs of the tests have
nmapRun4 350.50 55050 157.06 been executed. The first test had to be abandoned at 20 minutes
with what pySnorter parser. From this point on the pySnorter when the nmap process on the attacking machine reaches
software has been constantly watching for new elements being 100%. Other than that, the other three runs are broadly similar
added to the alerts file specified in the Snort.conf file. If an to the previous runs without the controller.
alert has been triggered, a new REST request has been created According to our initial assumption the pySnorter tool is
within pySnorter using the fields passed in the Snort alert to able to have as input a Snort alert file and divert traffic
direct that category of traffic to another port on the vSwitch. accordingly to one or more other network endpoints. In our
There, a Snort instance with rules specific to issues and case, it is a Snort sensor. pySnorter in its present format
vulnerabilities associated with TCP port 445 (or SMB/CIFS) depends on quite a lot of manual editing when being moved
is ready and waiting to begin more intensive inspection on from environment to environment and when the features of
traffic that has a closer match to its ruleset. This proves that the infrastructure change, such as the address of the SDN
subsets of interesting network traffic can be arbitrarily passed controller and the makeup of the vSwitch depending on the
to destinations on the SDN for inspection by network security port numbering and the switch and bridge IDs that the REST
devices. In this case, this is a Snort instance. requests are then aimed at.
There is also the issue of the timeout period in the wait
IV. I MPLEMENTATION AND E VALUATION between checking for additional lines added to the alerts file
The performance measurements for different variations of from the Snort process. This has been originally set to a tenth
passing traffic though Snort instances were initiated by se- of a second, but in a higher throughput network, this reading
lecting a fixed packet of data between two hosts that could might be inadequate. In later experiments the timing has been
be repeated over and again to make sure that the traffic sent changed to a hundredth of a second, but again, there exist
was useful for the purposes of tracking differences in the networks for which several alerts could conceivably be missed
infrastructure surrounding the endpoints. First we selected the within this time period.
nmap tool against our target which is vulnerable to metasploit.
Our tests have been able to prove that pySnorter is capa-
For the initial runs of this test, traffic has been captured by
ble of splitting traffic over several IDS sensors. During the
the host at the receiving end of the conversation to allow
implementation of our work lots of nmap, nping and hping
to both check that the behaviour is consistent over the runs
have been performed across a vSwitch with and without a
and to allow analysis of the resultant traffic to produce some
controller combined with and without Snort hosts monitoring
per-Snort rulesets in later tests or future work. The tests has
diverted traffic. In every experimentation within the limits of
been configured to also generate a PCAP for each run. It is
the infrastructure it was proved that Snort did not face any type
interesting to note the differences in capture sizes over these
of failure in its primary task of monitoring all traffic passing
runs as depicted in Table I.
There is not a direct correlation between the time taken to over the wire.
perform the scan either way. From the tests, it can be observed As previously discussed we made use of GNS3, hosting
there is a variation of up to eight (8) seconds for the scan time its own containers within the GNS3 VM as well as VMWare
and 2MB for the captures. All these tests have produced with Workstation VMs built and running in the machine running
an SDN switch in between the hosts and no attached controller. GNS3. GNS3 proved to be a good choice, as there was a
pre-built vSwitch container within GNS3 and GNS3 handled [4] A. Hakiri, A. Gokhale, P. Berthou, D. C. Schmidt, and T. Gayraud,
much of the network inter connectivity between the devices. “Software-defined networking: Challenges and research opportunities for
future internet,” Computer Networks, vol. 75, pp. 453–471, 2014.
However, GNS3 was responsible for lots of troubleshooting [5] K. Giotis, C. Argyropoulos, G. Androulidakis, D. Kalogeras, and
during the process of connecting it with the VM Workstation V. Maglaris, “Combining openflow and sflow for an effective and scal-
network (ESXi). Consequently, we made a decision to change able anomaly detection and mitigation mechanism on sdn environments,”
Computer Networks, vol. 62, pp. 122–136, 2014.
the Snort instances to multiple Snort processes running on [6] A. Papadogiannakis, M. Polychronakis, and E. P. Markatos, “Improving
a single machine, but taking care to each monitor a single the accuracy of network intrusion detection systems under load using
interface and to be pinned to a separate CPU thread. As it selective packet discarding,” in Proceedings of the third European
workshop on system security, 2010, pp. 15–21.
turned out, we managed to reduce the overhead for an analyst [7] S. Jantila and K. Chaipah, “A security analysis of a hybrid mechanism
and infrastructure engineer by having to only maintain a single to defend ddos attacks in sdn,” Procedia Computer Science, vol. 86, pp.
machine for varied Snort processing. 437–440, 2016.
[8] S. W. Shin, P. Porras, V. Yegneswara, M. Fong, G. Gu, M. Tyson et al.,
V. C ONCLUSIONS A ND F UTURE W ORK “Fresco: Modular composable security services for software-defined
We have made an attempt to develop a system that takes networks,” in 20th Annual Network & Distributed System Security
Symposium. Ndss, 2013.
advantage of one of the strong points of SDN, the ease to be [9] A. AlEroud and I. Alsmadi, “Identifying cyber-attacks on software
configured, to divert suspicious traffic to an IDS system for defined networks: An inference-based intrusion detection approach,”
inspection. A virtualized network has been setup where Snort Journal of Network and Computer Applications, vol. 80, pp. 152–164,
2017.
has been used as our main IDS. Eventually instead of different [10] T. Xing, D. Huang, L. Xu, C.-J. Chung, and P. Khatkar, “Snortflow:
instances of Snort, we have made use of multiple Snort A openflow-based intrusion prevention system in cloud environment,”
processes running concurrently on the same infrastructure and in 2013 second GENI research and educational experiment workshop.
IEEE, 2013, pp. 89–92.
diverted the traffic depending on its nature. [11] C.-J. Chung, P. Khatkar, T. Xing, J. Lee, and D. Huang, “Nice: Network
Our main tool pySnorter has managed to meet our needs by intrusion detection and countermeasure selection in virtual network
diverting traffic between the Snort sensors. However, it could systems,” IEEE transactions on dependable and secure computing,
vol. 10, no. 4, pp. 198–211, 2013.
be enhanced and grown to do more than it does at the present, [12] G. A. Ajaeiya, N. Adalian, I. H. Elhajj, A. Kayssi, and A. Chehab,
which is scanning for alterations to an alert file and generate “Flow-based intrusion detection system for sdn,” in 2017 IEEE Sym-
REST requests to a controller from the content of the alert posium on Computers and Communications (ISCC). IEEE, 2017, pp.
787–793.
outputs. It would be possible to change its functionality, thus [13] A. Sagala, “Automatic snort ids rule generation based on honeypot log,”
making it able to communicate to several SDN devices instead in 2015 7th International Conference on Information Technology and
of just a single. It could also mitigate a known attack as well Electrical Engineering (ICITEE). IEEE, 2015, pp. 576–580.
[14] G. Ahmed, M. N. A. Khan, and M. S. Bashir, “A linux-based idps using
as just monitor for them; a flow identified by one of the tiered snort,” Computer Fraud & Security, vol. 2015, no. 8, pp. 13–18, 2015.
Snort instances in these tests could have a set of rules marked [15] K. Shipulin, “We need to talk about ids signatures,” Network Security,
up in such a manner to generate a flow to be added with drop vol. 2018, no. 3, pp. 8–13, 2018.
[16] W. Yuan, J. Tan, and P. D. Le, “Distributed snort network intrusion
actions on the SDN device(s) closest to the source of the newly detection system with load balancing approach,” in Proceedings of the
classified malign traffic. International Conference on Security and Management (SAM). The
Our future work includes the addition of a large internet- Steering Committee of The World Congress in Computer Science,
Computer , 2013, p. 1.
facing links along with a series of small gigabit capable [17] M. Vallentin, R. Sommer, J. Lee, C. Leres, V. Paxson, and B. Tierney,
devices to be used as Snort sensors and a larger SDN (with “The nids cluster: Scalable, stateful network intrusion detection on
more than 5 physical ports) that would allow to slice up commodity hardware,” in International Workshop on Recent Advances
in Intrusion Detection. Springer, 2007, pp. 107–126.
incoming traffic into much more specific slices that could have [18] D. Andrews, J. Behn, D. Jaksha, J. Seo, M. Schneider, J. Yoon, S. J.
customised Snort instances waiting to inspect traffic. At this Matthews, R. Agrawal, and A. S. Mentis, “Exploring rnns for analyzing
point the entire testing setup could be rerun and this would zeek http data,” in Proceedings of the 6th Annual Symposium on Hot
Topics in the Science of Security, 2019, pp. 1–2.
generate more interesting performance testing results. [19] N. Pitropakis, E. Panaousis, A. Giannakoulias, G. Kalpakis, R. D.
Also it would be interesting to repeat the work emphasising Rodriguez, and P. Sarigiannidis, “An enhanced cyber attack attribution
on Snort because the SDN parts were really a small subset framework,” in International Conference on Trust and Privacy in Digital
Business. Springer, 2018, pp. 213–228.
of our testbed and there are opportunities for way more [20] A. Alhomoud, R. Munir, J. P. Disso, I. Awan, and A. Al-Dhelaan,
experimentation to bee done in regarding the performance of “Performance evaluation study of intrusion detection systems,” Procedia
Snort and other IDS. Additionally, we want to take advantage Computer Science, vol. 5, pp. 173–180, 2011.
[21] L. Etienne, “Malicious traffic detection in local networks with snort,”
of solutions such as Vasiliadis et al. [24], where transferring Tech. Rep., 2009.
the overhead of any IDS and the SDN controllers to the GPU [22] W. Bul’ajoul, A. James, and M. Pannu, “Improving network intrusion
would greatly benefit the future IT infrastructures. detection system performance through quality of service configuration
and parallel technology,” Journal of Computer and System Sciences,
R EFERENCES vol. 81, no. 6, pp. 981–999, 2015.
[1] I. F. Akyildiz, A. Lee, P. Wang, M. Luo, and W. Chou, “A roadmap [23] A. V. Bechtolsheim and D. R. Cheriton, “Access control list processing
for traffic engineering in sdn-openflow networks,” Computer Networks, in hardware,” Apr. 23 2002, uS Patent 6,377,577.
vol. 71, pp. 1–30, 2014. [24] G. Vasiliadis, M. Polychronakis, and S. Ioannidis, “Parallelization and
[2] J. Ibrahim, “Sdn-based intrusion detection system literature review,” characterization of pattern matching using gpus,” in 2011 IEEE Interna-
2017. tional Symposium on Workload Characterization (IISWC). IEEE, 2011,
[3] M. Roesch et al., “Snort: Lightweight intrusion detection for networks.” pp. 216–225.
in Lisa, vol. 99, no. 1, 1999, pp. 229–238. [25] Ryu, “Simple Switch SNORT,” 2014.