ICACT20220162 Slide.23
[Big slide for presentation]
[YouTube] |
Chrome Text-to-Speach Click!! |
 |
That’s all.
Thank you very much for your kind attention!
|
|
ICACT20220162 Slide.22
[Big slide for presentation]
[YouTube] |
Chrome Text-to-Speach Click!! |
 |
This figure shows the configuration of a firewall system with two OpenFlow switches. In order to avoid the situation where the lower OpenFlow switch is overloaded during an attack and alert messages from the IDS do not reach the OpenFlow controller quickly enough, we are considering introducing another OpenFlow switch dedicated to forwarding alert messages.
We are also considering introducing multiple IDSs to distribute the load among them.
|
|
ICACT20220162 Slide.21
[Big slide for presentation]
[YouTube] |
Chrome Text-to-Speach Click!! |
 |
Firewall systems cooperating with IDS and SDN attract much attention due to their flexibility but cooperation is not so easy.
So, in our study, instead of using a log monitoring tool and the REST API to feed alert messages from the IDS to the SDN controller, we proposed our method that uses syslog and Packet-In messages.
Our experimental results confirm that our proposed method can effectively reduce the total latency since the packet mirroring from the IDS until the flow table in the OpenFlow switch is changed.
For the future work, to support larger networks, multiple OpenFlow switches should be introduced for forwarding the Packet-In message as shown in the next slide.
|
|
ICACT20220162 Slide.20
[Big slide for presentation]
[YouTube] |
Chrome Text-to-Speach Click!! |
 |
Finally, I will conclude this presentation.
|
|
ICACT20220162 Slide.19
[Big slide for presentation]
[YouTube] |
Chrome Text-to-Speach Click!! |
 |
The results shown in previous slides are summarized here.
Compared with the conventional method, we confirmed the proposed method reduced the total latency by about 170 ms.
Since the attack detection time is dominant, further reduction of latency can be expected as the performance of IDS improves.
|
|
ICACT20220162 Slide.18
[Big slide for presentation]
[YouTube] |
Chrome Text-to-Speach Click!! |
 |
Finally, we show the difference between the proposed method and the conventional method.
The time intervals between when an attack packet was mirrored and when a FlowMod command was issued were 410.0 ms for the proposed method and 580.8 ms for the conventional method, a difference of about 170 ms.
|
|
ICACT20220162 Slide.17
[Big slide for presentation]
[YouTube] |
Chrome Text-to-Speach Click!! |
 |
Next, we show the difference between the proposed method and the comparison method.
The time intervals between when an attack packet was mirrored and when the IDS sends an alert message were 397.9 ms for the proposed method and 484.0 ms for the comparison method, a difference of about 90 ms. This difference represents the overhead required for the log monitoring tool to inspect the log file.
|
|
ICACT20220162 Slide.16
[Big slide for presentation]
[YouTube] |
Chrome Text-to-Speach Click!! |
 |
First, we show the difference between the conventional method and the comparison method.
The time intervals between when an attack packet was mirrored and when the IDS sends an alert message were 563.5 ms for the conventional method and 484.0 ms for the comparison method. The difference was about 80 ms. The reason for this relatively large difference is that in the conventional method, swatch requires invocation time of curl command.
The time intervals between when the IDS sends an alert message and when a FlowMod command was issued were 17.2 ms for the conventional method and 12.6 ms for the comparison method. The difference was about 5 ms. This implies TCP connection establishment overhead required in the conventional method.
|
|
ICACT20220162 Slide.15
[Big slide for presentation]
[YouTube] |
Chrome Text-to-Speach Click!! |
 |
Then, I will discuss the evaluation results of three prototype firewall systems.
|
|
ICACT20220162 Slide.14
[Big slide for presentation]
[YouTube] |
Chrome Text-to-Speach Click!! |
 |
This table shows the flow tables of the OpenFlow switch in the initial state and after the attack.
Initially, the flow table is configured to forward packets between ports 1 and 2, while mirroring them to port 3. When a SYN flood attack is performed on port 80 of TCP, a flow entry is added to drop the target packets based on the source and destination IP addresses and the destination port number.
|
|
ICACT20220162 Slide.13
[Big slide for presentation]
[YouTube] |
Chrome Text-to-Speach Click!! |
 |
This figure shows the configuration of the proposed method. The IDS program “snort” sends syslog messages directly to the OpenFlow switch, which forwards them to the OpenFlow controller in the form of Packet-In.
|
|
ICACT20220162 Slide.12
[Big slide for presentation]
[YouTube] |
Chrome Text-to-Speach Click!! |
 |
For comparison, we also implemented a prototype firewall system with the configuration shown in this figure. In this system, the attack detection method is the same as the conventional method, but the alert notification method is different. That is, UDP packets are send to the OpenFlow switch by the log monitoring tool “swatch”, and then they are forwarded to the OpenFlow controller in the form of Packet-In. This makes it possible to distinguish between latency caused by log monitoring and that caused by REST API.
|
|
ICACT20220162 Slide.11
[Big slide for presentation]
[YouTube] |
Chrome Text-to-Speach Click!! |
 |
The following three slides show the configuration of the three types of firewall systems used in the experiments. This slide shows the configuration using the conventional method.
The log monitoring tool “swatch” watches the log file and sends blocking requests to Ryu via REST API.
|
|
ICACT20220162 Slide.10
[Big slide for presentation]
[YouTube] |
Chrome Text-to-Speach Click!! |
 |
This slide shows the hardware and software specifications used in the implementation of the prototype firewall system.
As for hardware, we used a total of four Raspberry Pi 2 Model B’s for the client, the server, the machine including the OpenFlow controller and the OpenFlow switch, and the IDS.
As for software, we used Ryu as the OpenFlow controller and snort as the IDS. As an attack tool, we used hping3 to perform a SYN flood attack.
|
|
ICACT20220162 Slide.09
[Big slide for presentation]
[YouTube] |
Chrome Text-to-Speach Click!! |
 |
Next, I would like to explain implementation of the proposed system.
|
|
ICACT20220162 Slide.08
[Big slide for presentation]
[YouTube] |
Chrome Text-to-Speach Click!! |
 |
This figure shows the system configuration and operation of the proposed method.
In this method, the IDS sends alert messages via the syslog protocol, and when the OpenFlow switch receives them, it forwards them to the OpenFlow controller as Packet-In. The OpenFlow controller analyzes the syslog message, identifies the traffic to be blocked, and let the OpenFlow switch block it using the FlowMod command.
Thus, since no log monitoring tools nor REST APIs are used, this method can considerably reduce latency compared with conventional methods.
|
|
ICACT20220162 Slide.07
[Big slide for presentation]
[YouTube] |
Chrome Text-to-Speach Click!! |
 |
This figure shows the system configuration and operation of the conventional method.
In this method, the IDS records an alert message to the log file, and when the log monitoring tool finds the traffic to be blocked, it alerts the OpenFlow controller to block it using the REST API. The OpenFlow controller issues the FlowMod command to let the OpenFlow switch block the target traffic.
This operation generates two types of latency: one is the latency caused by log monitoring, which is the time interval from when the IDS records an alert message to the log file to when the log monitoring tool recognizes it, and the other is the latency caused by TCP connection establishment because the log monitoring tool communicates with the OpenFlow controller using the REST API over TCP.
|
|
ICACT20220162 Slide.06
[Big slide for presentation]
[YouTube] |
Chrome Text-to-Speach Click!! |
 |
Next, I would like to explain the proposed method in detail.
In the following explanation, we will use OpenFlow, the most popular SDN framework.
|
|
ICACT20220162 Slide.05
[Big slide for presentation]
[YouTube] |
Chrome Text-to-Speach Click!! |
 |
The objectives of our research are as follows.
The first objective is to develop an easy way to cooperate with IDS and SDN. For this purpose, we use syslog messages as a northbound interface. Since most IDSs can output syslog message by default, they can be integrated into firewall systems as are.
The second objective is to develop a faster method for the blocking operation. By not using log monitoring tools, the latency of monitoring log messages is eliminated. Also, by using syslog messages via UDP protocol as the northbound interface, we can eliminate the latency for establishing TCP connections in case of using the conventional REST API.
|
|
ICACT20220162 Slide.04
[Big slide for presentation]
[YouTube] |
Chrome Text-to-Speach Click!! |
 |
The pros and cons of this type of firewall systems are as follows.
One of the advantage of this type of firewall systems is its flexibility. For example, it is easy to run multiple IDSs in parallel to reduce the load among them, or to change the inspection type depending on the type of traffic. In addition, it is possible not only to block suspicious communications but also to direct them to honeypots.
On the other hand, it is not so easy to cooperate with IDS and SDN. Most IDS products don’t provide a northbound interface and cannot notify alert messages to the SDN controller directly. Therefore, a log monitoring tool is necessary to find the alert messages in the log file recorded by the IDS, and if it detects any anomaly traffic, it reports this traffic to the SDN controller usually using REST API. With the intervention of the log monitoring tool, there is a large latency in the blocking operation.
|
|
ICACT20220162 Slide.03
[Big slide for presentation]
[YouTube] |
Chrome Text-to-Speach Click!! |
 |
Today, firewall systems are essential to protect ICT resources in the organization from malicious accesses.
There are many kinds of firewall systems on the market, but they are often expensive and not flexible.
On the other hand, firewall systems cooperating with IDS and SDN attract much attention recently.
IDS stands for Intrusion Detection System. It is normally used to monitor all packets and when it detects anomaly traffic from the Internet, it alerts the administrator or other security devices to such traffic.
SDN stands for Software Defined Network. It consists of an SDN controller and some SDN switches and provides easier and more flexible network management.
In such a firewall system, the IDS monitors the mirrored packets and when it detects anomaly traffic from the Internet, it alerts the SDN controller to this traffic. The SDN controller configures the SDN switch to block this traffic. From the viewpoint of the SDN controller, the communication interface for the application program, in this case the IDS, is called the northbound interface, and the communication interface for the SDN switch is called the southbound interface.
|
|
ICACT20220162 Slide.02
[Big slide for presentation]
|
Chrome Text-to-Speach Click!! |
 |
First of all, I will explain the introduction of our research.
|
|
ICACT20220162 Slide.01
[Big slide for presentation]
[YouTube] |
Chrome Text-to-Speach Click!! |
 |
I am Nariyoshi Yamai from Tokyo University of Agriculture and Technology, Japan.
I would like to present our research entitled “Quick Blocking Operation of Firewall System Cooperating with IDS and SDN”.
|
