## 5 Results and Discussion  
The proposed scheme is tested in an environment where a number of IoT devices are attached to a home router. These devices, the home router, C&C server, DNS server, victim server, etc. are all attached to the same LAN. However, in practice, this is not the case, and they could be attached to different LANs. However, the location of these networking entities does not affect the overall concept of the proposed system. The experimental setup of the proposed scheme is depicted in Figure 4.  
Figure 4: Testbed used in experimenting with the proposed system. As the C&C server is available on the same LAN, we download the malicious code to one of the IoT devices to infect it. This is simply done by running malicious code on any of the IoT devices. Once the IoT device is infected with malicious code, it is then connected to the home router via the gateway. In order to design a common gateway to format the traffic to be understandable over the internet, we used a switch and configured it as a gateway. This switch is further attached to the home router. Each home appliance is attached to a Raspberry Pi 4.0 module with 4 GB of RAM and a Quad-core 64-bit processor. Similarly, the specifications of the home router used for the experiment are: dual Gigabit Ethernet ports, dual USB 3.0 ports, Raspberry Pi Compute Module 4, 4 GB RAM, 32 GB eMMC, and a Quad-core 64-bit processor. The traffic passing through the home router is captured with Wireshark at different times. Figure 5 shows the main open dataset representation, which was captured after the infected IoT devices launched a DDoS attack on the victim server. As depicted in Figure 5, the infected IoT devices send a huge amount of SYN packets to the victim server without waiting for the acknowledgment message from the server. This slows down the working of the victim sever in providing services to legitimate IoT devices. In order to check that the victim server failed to fulfill the services of the benign IoT devices, a benign IoT device is selected to send a request to the victim server to obtain the required services. However, as the victim server is busy responding to the infected devices, the benign IoT device will never get a chance to receive the services from the victim server. Finally, the victim server will reset and stop listening to new requests once its cache is clear and ready to receive new messages. In the case of the IoT scenario, the data generated from each device have high preferences. For example, if a camera detects an abnormal behavior of the main gate and tries to send this urgent data to the homeowner. However, the router is busy providing the services to the infected device, which may cause a delay in sending the information to the homeowner on time. Finally, it may result in something unwanted occurring, or damage to the house. Figure 5: A SYN flood attack on the victim server. The statistics of the packets generated during the attack are shown in Figure 6. This statistic helps us in screening the packets in the future. In addition, a profile for each IoT device could be built by saving the statistics of each IoT device traffic in the log. For example, based on the packet statistics of each IoT device, we can build an appropriate and suitable traffic generation profile. The traffic generation profile can help in reducing the limitation of the system in terms of blocking normal traffic. For example, we can set a high packet generation threshold for a camera during a specific time of the day. The packet size of streaming data is always greater than that of normal packets and thus we can set the camera to transmit information in a specific period. For example, if a camera is scheduled to send the packet during a specific time, then the router rules could be changed to avoid scanning packets based on the pre-defined threshold of 50 packets. In the case of a camera, the threshold could be increased to 100, etc.