Denial of Service Attack Prevention and Mitigation for Secure Access in IoT GPS-based Intelligent Transportation Systems

Abstract

The widespread use of GPS tracking devices has made them an indispensable solution in various sectors such as transportation, logistics, and security. However, the complexity of cyber attacks such as denial of service (DoS) attacks have made these devices vulnerable, thereby compromising the security of the data and devices. This has a significant impact on business and applicable legislation related to essential services. In this paper, we propose the integration of security mechanisms and algorithms into the Teltonika IoT GPS tracking device’s firmware, including DoS protection to detect, prevent, and secure these devices against DoS cyber attacks.

1. Introduction

GPS tracking devices have become an essential component in numerous industries, allowing organizations to track their assets and monitor the movements of their employees or vehicles. However, these devices are prone to cyber attacks, which can jeopardize their precision, dependability, and security. Among the most substantial risks that GPS tracking devices face are denial of service (DoS) attacks. DoS attacks involve flooding the device or network with an excessive amount of traffic, rendering it inaccessible [1]. In the context of GPS tracking devices, a DoS attack can temporarily or permanently block the device from transmitting location and other sensitive data to the tracking platform, leading to service and device disruption and to substantial business losses and legal implications. Teltonika is a well-known producer of GPS tracking devices that are extensively used in various sectors [2,3]. Nevertheless, these devices are susceptible to DoS and other cyber attacks, as was shown in [4,5]. It is essential to incorporate mechanisms for prevention and detection (IPS/IDS) into the firmware of Teltonika GPS tracking devices to guarantee their security in real time and not depend on additional infrastructure, as can be observed in [6,7], to protect the device from DoS attacks. This will be considered an innovation related to IoT security and will improve the mobility, accessibility, response time, and scalability of secured IoT devices by integrating security mechanisms and algorithms directly into tracking device firmware. In this paper we will investigate the effects of DoS attacks on Teltonika GPS tracking devices and we will demonstrate and implement security mechanisms that can be embedded into their firmware to avert and identify these kinds of cyber attacks [8,9]. By integrating IPS/IDS mechanisms and algorithms, Teltonika GPS tracking devices can be made more robust against cyber attacks, providing organizations and individuals with the assurance that their GPS data and device are secured and available. This research is significant because cyber attacks on GPS tracking devices can lead to substantial business losses and can compromise the safety of individuals. By understanding the potential threats and the ways to prevent them, businesses can maintain their productivity and profitability, and individuals can trust the security of their assets and personal safety, including legislation requirements related to essential services [10,11,12].

2. State of the Problem

2.1. DoS and DDoS Attacks against IoT Tracking Devices

In the context of IoT tracking devices like Teltonika, a denial of service (DoS) attack can occur when a malicious actor floods the device with requests or data to overload or crash the device, rendering it unable to function properly. DoS attacks can take several forms, such as network-based attacks or application-based attacks, and can be launched from a single device or coordinated from a botnet of compromised devices (DDoS).

A distributed denial of service (DDoS) attack is a malicious cyber attack where multiple compromised computer systems or servers attack a target, such as a server, website, or other network resource, and cause a denial of service (DoS) for users of the targeted resource. The flood of incoming messages, connection requests, or malformed packets to the target system forces it to slow down or even crash and shut down, thereby denying service to legitimate users or systems. DDoS attacks exploit the specific capacity limits that apply to any network resources—such as the infrastructure that enables a IoT device’s functionality—and can emanate from the cumulative effect of a multitude of compromised computers, distributed globally, known as a botnet. This method distinguishes DDoS attacks from other denial of service (DoS) attacks, which generally use a single source. It is a prevalent and significant threat in cybersecurity, including IoT infrastructure, with motivations ranging from financial gain to political activism [1,13].

A distributed denial of service (DDoS) attack targeting IoT GPS tracker devices involves multiple compromised systems that collectively flood the network or servers supporting these devices, or directly flood devices from compromised connected servers, with excessive requests, data, or malformed packets. This orchestrated assault affects the network’s capacity, slowing down or completely disrupting the service and preventing the GPS trackers from transmitting location data effectively. Since IoT devices, like GPS trackers, often have limited processing power and security features, they are particularly vulnerable to such attacks. The impact of a DDoS attack on IoT GPS trackers can extend from individual device malfunction to broader disruptions in logistics, personal location tracking, and critical infrastructure monitoring. The motivations behind such attacks can range from commercial sabotage to creating widespread disruption in essential services reliant on real-time location data [14]. The attacks are performed in a similar way to the ones against generic computers over the Internet, but the impact can be greater due to limited device resources.

The goal of a DoS attack is to exhaust the device’s resources, such as CPU, memory, or network bandwidth, causing it to become unresponsive or even crash [13]. In the case of Teltonika GPS tracking devices, a DoS attack could block the device from transmitting location and other sensitive data or receiving commands from the server, resulting in a loss of real-time location tracking or other features. This could be particularly damaging for businesses or organizations that rely on GPS tracking for logistics or security purposes. Preventing DoS attacks on Teltonika GPS tracking devices and other IoT devices requires implementing measures like rate limiting and packet analysis, including size and packet inspection, to limit the impact of an attack and reduce the risk of compromise. Additionally, monitoring and alerting tools and functions can help detect and mitigate attacks in real time [15,16].

2.2. The Detection and Prevention Capabilities of IPS/IDS Mechanisms

Intrusion detection is the process of monitoring network traffic and analyzing it for signs of possible intrusions, such as exploit attempts and incidents that may be imminent threats to the network. For its part, intrusion prevention is the process of performing intrusion detection and then stopping the detected incidents, typically achieved by dropping packets or terminating sessions. These security measures are available as intrusion detection systems (IDSs) and intrusion prevention systems (IPSs), which are part of network security measures taken to detect and stop potential incidents and are an included functionality within next-generation firewalls (NGFWs) [17].

An IDS/IPS monitors all traffic on the network to identify any known malicious behavior. One of the ways in which an attacker will try to compromise a network is by exploiting a vulnerability within a device or within software. An IDS/IPS identifies those exploit attempts and blocks them before they successfully compromise any endpoints within the network, including IoT devices and infrastructure. IDS/IPSs are necessary security technologies, both at the network edge and within the data center, precisely because they can stop attackers while they are gathering information about the network. Three IDS detection methodologies are typically used to detect incidents.

Signature-based detection compares signatures against observed events to identify possible incidents. This is the simplest detection method because it compares only the current unit of activity (such as a packet or a log entry to a list of signatures) using string comparison operations.

Anomaly based detection compares definitions of what is considered normal activity with observed events to identify significant deviations. This detection method can be very effective at spotting previously unknown threats.

Stateful protocol analysis compares predetermined profiles of generally accepted definitions of benign protocol activity for each protocol state against observed events to identify deviations [17]. A graphical representation of network-based and host-based IPS/IDS mechanisms is shown in Figure 1.

Intrusion detection systems (IDSs) and intrusion prevention systems (IPSs) constantly watch the network, identifying possible incidents, logging information about them, stopping the incidents, and reporting them to security administrators. In addition, some networks use an IDS/IPS for identifying problems with security policies and deterring individuals from violating security policies. IDS/IPSs have become a necessary addition to the security infrastructure of most organizations, including IoT infrastructures, precisely because they can stop attackers while they are gathering information about the network.

An intrusion detection system (IDS) is responsible for identifying attacks and techniques and is often deployed out of band in a listen-only mode so that it can analyze all traffic and generate intrusion events from suspect or malicious traffic. An intrusion prevention system (IPS) is deployed in the path of traffic so that all traffic must pass through the appliance to continue to its destination. Upon the detection of malicious traffic, the IPS breaks the connection and drops the session or traffic.

An IDS detects threats based on patterns of known exploits, malicious behaviors, and attack techniques. An effective IDS also detects the evasive techniques attackers use to hide exploits, such as remote procedure call (RPC) fragmentation, HTML padding, and other types of TCP/IP manipulation.

An IPS can prevent certain types of DDoS (distributed denial of service) attacks. For example, application denial of service (AppDoS) is one of the threat categories that an IPS functionality can identify and protect against [17]. However, volumetric DDoS threats require a dedicated and specific solution and implementation, as demonstrated in our experimental results, shown in Section 3.

The proposed IDS/IPS mechanism presented in this paper is designed to monitor the network for malicious traffic and potential security breaches and is implemented into Teltonika FMB firmware devices as a “security by design and by default” concept. The proposed mechanism includes IDS/IPS capabilities for DoS protection which will monitor the incoming traffic and compare it to known patterns of attack, anomalies, or custom indicators of compromise. If it detects any suspicious traffic, it raises an alert to notify the administrator of the possible threat [7]. The attacked FMB device will stop processing the existing suspicious traffic, ensuring the device protection during the attack, and will redirect the telemetry data to an alternative and redundant backup reception server, ensuring data transmission and device availability. On the other hand, the IPS/IDS is designed to actively detect and prevent the incoming DoS attacks by inspecting, filtering, alerting, and blocking network traffic in real time [18]. Figure 2 shows the IDS/IPS flow and its components:

To implement IDS/IPS capabilities and DoS protection in Teltonika device firmware, several approaches have been used, such as rate-limiting and packet validation mechanisms.

2.3. Proposed IDS/IPS Mechanism

The IDS/IPS algorithm examines all incoming packets to determine their validity. This assessment is based on packet size, integrity, and the arrival time interval. When a packet is deemed invalid, the invalid packet counter is increased; conversely, upon the receipt of a valid packet, the invalid packet counter is reset. Should the number of invalid packets received within a given timeframe exceed the predefined alert threshold, an alert is dispatched to the device’s backup server. Consequently, the device halts the processing of packets from the primary server and reroutes communication to the backup server. The flow diagram is illustrated in Figure 3.

3. Materials and Methods

In this paper, the test plan included two DoS attack scenarios on Teltonika FMB122 devices. Given that the FMB Teltonika GPS monitoring devices are usually behind NAT because their communication is conducted using mobile telephony or, respectively, GPRS communications, without exposed public IP addresses, the possibility of compromising the telemetry data reception server was considered, as well as compromising gateway-type devices (taking into account MITM attacks), as discussed in previous works [4,5], including the ISP area and other types of gateways that are in the communication path between the device and server.

For the vehicles to be able to communicate with other smart devices located in smart cities, they must be equipped with devices (IoT GPS trackers) that know how to collect and transmit telemetry data. Each piece of equipment has a specific codec that encodes the data stream in an encoded form, and decoding is the reverse process [4,5].

The Teltonika FMB122 solution is a compact and versatile GPS tracking device designed for various applications such as fleet management, asset tracking, and personal tracking. The device features the smallest and most powerful three-in-one function module on the market, TM2500. It contains the latest TELTONIKA LGA land grid array for the GSM/GNSS module. With an integrated QuadBand GSM/GPRS network and combined Bluetooth^® and GNSS technology, it allows users to communicate with modules and track variable assets at any location and any time they have signal coverage. It has integrated GSM/GPRS and GPS modules and a range of I/O interfaces, including digital/analog inputs and digital outputs.

Its firmware is written in the C programming language and is based on the FreeRTOS real-time operating system. The code is designed to control the device’s hardware components, including its GPS and mobile communication modules, and to manage the exchange of information between the device and the tracking platform. The firmware can be updated over the air (FOTA), allowing Teltonika to release updates to address security vulnerabilities and other functional issues [4,5].

An example of an IoT device used in this paper for the experimental results mentioned at Section 3 is shown in Figure 4.

The FMB122 model utilizes public encoding algorithms (such as Base64 or hexadecimal conversion) for data in transit, followed by decoding. For a better understanding of the encoding and decoding processes, we have summarized below an algorithm used by Teltonika devices for transmitting telemetry data.

The structure is as follows: X represents the longitude; Y represents the latitude; and altitude is expressed in meters above sea level. The angle is expressed in degrees, where 0 represents north, increasing by 1 unit in a clockwise direction; satellites are the number of visible satellites; and speed is expressed in km/h. The value 0 × 0000 is obtained when the GPS data are invalid. Longitude and latitude are integer values constructed from degrees (d), minutes (m), seconds (s), and milliseconds (ms), according to Formula (1), with precision p (10,000,000) [3,4,5].

Table 1. Codec 8 Extended elements.

Elements	Codec 8 Extended
Codec ID	0x8E
Length of the AVL Data IO Element	2 Bytes
Total Length of the AVL Data IO Count Element	2 Bytes
Length of the AVL Data IO Count Element	2 Bytes
Length of the AVL Data IO Element ID	2 Bytes
Variable-Size IO Elements	Variable-size elements

presents an example of 152 bytes sent using the Codec 8 Extended protocol.

$$\left(d+\frac{m}{60}+\frac{s}{3600}+\frac{ms}{\mathrm{3,600,000}}\right)\times p$$

(1)

The sizes of AVL (Automatic Vehicle Location) data elements in Codec 8 Extended have been extended to a length of 2 bytes, and a new variable type has been added, as is shown in Figure 5 [3].

The significance of these fields is as follows:

• 00000000—4 zeroes, 4 bytes;
• 0000005F—data length, 4 bytes;
• 8E—ID codec;
• 01—data number (1 record);
• 000000063C2C9FE—timestamp in miliseconds UnixTime Stamp (1713191278),
• GMT: Saturday, 14 January 2023 15:27:58;
• 00—priority;
• 0F0DCDE4—longitude 252,562,916 = 25, 2562916° N;
• 20959D30—latitude 546,676,016 = 54.6676016° E;
• 008A—altitude (138 m);
• 0000—angle (0);
• 06—6 visible satellites;
• 0000—speed 0 km/h;
• IO Elements:
• 0000—IO element ID of the generated event (in this case, when data are generated with 0000, this is not an event);
• 0006—6 elements in registered IO (total);
• 0001—1 IO element with a length of 1 Byte;
• 00EF—IO element ID = 239 (dec);
• 00—IO element value;
• 0001—1 IO element with a length of 2 Bytes;
• 0011—IO element ID = 17 (dec);
• 001E—IO element value;
• 0001—1 IO element with a length of 4 Bytes;
• 0010—IO element ID = 16 (dec);
• 0000CBDF—IO element value = 52,191 (dec);
• 0002—1 IO element with a length of 2 Bytes;
• 000B—IO element ID = 11 (dec);
• 000000003544C875—IO element value;
• 000E—IO element ID = 14 (dec);
• 0000000029BFE4D1—IO element value;
• 01—number of data packets (1 record);
• 0000D153—CRC-16, 4 Bytes (the first 2 are always 0).

An example of a data packet received by a telemetry server is shown in Figure 6.

The elements of the data packet are as follows:

• Data length: 00A1 or 161 Bytes (excluding the first 2 bytes).
• Packet identification: 0xCAFE 2 bytes.
• Unused byte: 00.
• Packet ID: 1B.
• IMEI length: 000F.
• Actual IMEI: 333536333037303432343431303133.
• Codec ID: 8E.
• Data number: 01.
• Timestamp: 0000013FEBDD19C8.
• Priority: 00.
• GPS data: 0F0E9FF0209A718000690000120000.

The decoder has two main parts: the decoding handler, known as AVL Data Packet Header, which contains the logic that validates the decoded message, extracts general information such as IMEI, and knows to send successful receipt messages (ACK messages) to the equipment in the event of successful decoding; and the decoder, which contains the logic for decoding message data (AVL data Packet).

The IoT module sends data to the server, and the server must respond with an acknowledgment of receipt. The data count is the number of encoded data entries (number of records). The codec ID is constantly 0x8E. The length of the data field is the byte length [codec ID, data count 2]. Data count 1 should always be equal to one byte, data count 2. The CRC-16 has 4 bytes, but the first two are zero, and the last two are the CRC-16 calculated for [codec ID, data count 2]. The minimum size of an AVL packet is 53 bytes (with all IO elements disabled). The server confirms its receipt of the data (2 data items) as 00000002. This is how the FMB122 communicates with the server and receives a response, as well as how the information is encoded and decoded [3,4,5].

Therefore, in these scenarios, the FMB devices can be subjected to a DoS attack by injecting malicious response packets using the TCP connection (TCP session hijacking) necessary for communication between the gateway or data reception server and the FMB device, following the compromise of the telemetry data reception server, ultimately affecting the availability of the FMB devices, while also possibly causing buffer overflow issues based on the DoS attack, as shown in the Section 3 results.

Once a potential attack is detected, the IDS/IPS mechanism can take several actions to protect the device, by not processing the malicious traffic, alerting the administrator of the possible threat to limit the impact of the attack, and redirecting traffic to a backup server to avoid data loss from the device to the telemetry server. Overall, implementing IDS/IPS mechanisms in Teltonika device firmware can provide real-time protection against DoS cyber attacks [12,13]. The rate-limiting mechanism implemented in this solution is designed to control the processing of incoming packets based on time intervals and certain validation checks. The rate-limiting mechanism is a combination of time-based control and packet validation, supplemented by a monitoring system that triggers alerts and switches server configurations in response to unusual traffic patterns. This design helps in maintaining stable and secure communication, preventing the system from being overwhelmed by too frequent or malformed packets. The packet validation mechanism in this solution involves several checks to ensure the integrity and appropriateness of the packets being processed. This mechanism is crucial for maintaining the reliability and security of the system.

The packet validation mechanism in the solution is designed to ensure that each packet meets specific size and content criteria before being processed. By combining size validation, content checking, and an invalid packet counter that triggers alerts, the system effectively guards against processing potentially harmful or non-compliant packets, thereby maintaining the integrity and security of the communication process.

The experimental part of this study was created in a virtual environment, using virtualization technologies based on Oracle VirtualBox 7.0.18, both for the server side and for the FMB IoT device part. The communication between the FMB device and the telemetry data reception server was simulated using Debian Linux 12 virtual machines and implementations, automations, and integrations in Python 3.11.2 for the server side and C for the FMB IoT device client and firmware part.

The DoS attack utilized TCP Session Hijacking methods. TCP is a reliable and ordered protocol that ensures the delivery and integrity of data packets between two endpoints on a network. TCP uses a three-way handshake to establish a connection and assigns a sequence number and an acknowledgment number to each packet to track the order and confirmation of the transmission. A TCP session is identified by a four-tuple: a source IP address, source port, destination IP address, and destination port. TCP session hijacking involves manipulating these elements to trick the endpoints into believing that they are communicating with each other while the attacker intercepts or modifies the data. Attackers can use various methods and tools to perform TCP session hijacking depending on their level of access to the network. Blind hijacking involves guessing the sequence and acknowledgment numbers without seeing them, but this is difficult and can lead to disruption or termination of the connection. Alternatively, spoofing and sniffing enable the attacker to redirect traffic between endpoints to their device, allowing them to capture and analyze packets [19].

The tools, methods, and technologies employed in this experiment were based on the use of specially created Python custom scripts for injecting malicious packets and for receiving data on the server. Additionally, Debian Linux virtual machines were used for the reception server, router, and simulation of FMB devices. The DoS attack topology and infrastructure configuration is shown in Figure 7. The Scapy library was utilized for sending DoS-type packets and tcpdump was used for packet capture and traffic analysis, whilst the IDS/IPS algorithm was written in C. Additional details can be found in this section.

During the experiment, DoS attacks were simulated and initiated on the FMB IoT device, considering the scenario of compromising the telemetry data reception server and the gateways, as well as the infrastructure, up to the FMB device. In the attack, TCP session hijacking methodologies were used to inject the payload into the active connection between the FMB device, including the gateway, and the telemetry data reception server, leading to a lack of data processing by the FMB device due to the large number of packets sent in a unit of time, while also possibly causing a buffer overflow issue due to the size of the modified response packets [19].

A graphical topology of the proposed DoS attack on the Teltonika FMB devices is shown in Figure 7.

The server part, for telemetry data reception and communication with the FMB device, was written in Python, as can be seen in Figure 8, using the Codec 8 Extended communication protocol, including the data acquisition settings available on the FMB devices [3,20].

The function parse_teltonika_packet is responsible for parsing a packet of data received from a client, adhering to the Teltonika Codec 8 Extended protocol format.

It first ensures that the data packet received is long enough to be a valid packet, based on the protocol’s specifications. It checks the first 4 bytes of the data to ensure they match the expected preamble (four 0 bytes). The next 4 bytes represent the length of the data field, which is extracted using the struct.unpack function. After parsing, the function returns a dictionary containing parsed values, such as the preamble and other relevant information from the packet.

The handle_client function is the core of handling a client connection in a multithreaded server environment. It listens for data from the connected client and uses parse_teltonika_packet to parse the received data. If the data are successfully parsed without raising a ValueError, the server sends back an acknowledgment response to the client and properly handles exceptions, ensuring the client connection is closed in case of errors or when data processing is completed.

Every time a packet is received from the FMB device and tries to connect to the server, a new thread is started, and the packet is processed by the handle_client function. The parse_teltonika_packet function is used to decode and verify the packet’s content to make the simulation as realistic as possible.

The start_server() function sets up and prompts the server to start listening to incoming connections. It creates a socket and binds it to a specified port (1111) to listen for incoming TCP connections. The server listens for connections, with a capacity to queue up to 5 connection requests. Each accepted connection is handled in a separate thread using handle_client, allowing multiple client connections to be processed concurrently. The number_of_packets variable suggests a mechanism for keeping track of the number of processed packets.

The server is designed to receive, parse, and respond to network packets following a specific protocol (Teltonika Codec 8 Extended), including data acquisition settings [3,20]. The server operates in a multithreaded manner, allowing the simultaneous handling of multiple client connections. Its key functionalities include rigorous packet validation, error handling, and sending appropriate responses to clients, all crucial for maintaining reliable and secure network communication. A delay in packet processing was also introduced in order to simulate a production environment in which the server will need some time to process the information that has been received before confirming with a reply.

The client part of the FMB device was written in C, as can be seen in Figure 9, using the Codec 8 Extended protocol available on the Teltonika FMB devices, for communication with the reception server [3].

The hex_string_to_bytes function converts a hexadecimal string to a binary representation. It computes the length of the provided hexadecimal string. It allocates memory for the binary representation of the hex string and converts each pair of hexadecimal characters to a byte of binary data and then returns the length of the binary data array.

The send_tcp_packet function sends a TCP packet to a specified server and port. It first converts the provided hex data string to binary using the hex_string_to_bytes function and then creates a TCP socket. It sets up the server address using the provided IP and port and connects to the server, and then sends the binary data over the socket.

The main function of the program runs an infinite loop that repeatedly sends TCP packets to a server and uses a while loop to continuously send packets every 60 s, using sleep. It defines the hex packet data and server details (IP and port) and calls send_tcp_packet to send the hex packet to the specified server.

This code is structured to regularly send data packets over a network from the FMB device client to a specific telemetry server. Its primary use case could be in scenarios where periodic data transmission is required, such as in a monitoring or data collection system, and it is designed to run indefinitely, sending packets every 60 s.

4. Results

An experimental TCP session hijacking Python script was created using Scapy [19,21]. This is a Python program that enables the user to send, sniff, dissect, and forge network packets. This capability allows the construction of tools that can probe, scan, or attack networks. In other words, Scapy is a powerful interactive packet manipulation program. It can forge or decode packets from a wide number of protocols, send them on the wire, capture them, match requests and replies, and much more. It can easily handle most classical tasks like scanning, tracerouting, probing, unit tests, attacks, or network discovery. It can replace hping, arpspoof, arp-sk, arping, p0f, and even some parts of Nmap, tcpdump, and tshark. It also performs very well on a lot of other specific tasks that most other tools cannot handle, like sending invalid frames, injecting your own 802.11 frames, combining techniques (VLAN hopping+ARP cache poisoning, VoIP decoding on WEP-encrypted channels), etc. The idea is simple. Scapy mainly does two things: sending packets and receiving answers. After defining a set of packets, it sends them, receives answers, matches requests with answers, and returns a list of packet couples (request, answer) and a list of unmatched packets. This has a big advantage over tools like Nmap or hping, that an answer is not reduced to open, closed, or filtered, but is the whole packet. On top of this can be built more high-level functions. For example, one that performs a traceroute and gives as a result only the start TTL of the request and the source IP of the answer. Another one pings a whole network and gives the list of the machines answering. Another one performs a portscan and returns a LaTeX report [21]. In our experiment, we used the Scapy library to alter and send packets to perform the DoS attack using open TCP connections between the FMB device and the telemetry data reception server; see Figure 10.

This Python script uses Scapy, a powerful interactive packet manipulation library, which enables network traffic capture and programmatic packet generation. The script captures specific TCP packets and generates forged responses [19].

The pkt_to_json function converts a packet captured by Scapy into a JSON-like structure. The function extracts various fields from the packet (e.g., Ethernet, IP, TCP headers) and organizes them into a JSON-formatted structure, which is useful for the easier handling and analysis of packet data within the Python script. The start function initiates packet sniffing on a specified network interface and uses the sniff function to capture packets that match a certain filter criterion (in this case, TCP packets on port 1111 to the host 10.0.100.5) using the core of the script, where network monitoring starts. When a packet is captured that matches the filter, the inject function is called, with the packet as a parameter.

The inject function processes each packet captured by the start function and generates a response and converts the packet to a JSON-like format for processing, and then checks if the destination IP of the packet matches the server_ip. If so, its calls the forge_response function to create a spoofed packet and sends it using the sendp function. This acts as a callback function for packet manipulation. It is where the logic for deciding whether to respond to a packet and how to craft that response is implemented.

The forge_response function creates a forged response packet to the received packet and constructs a new Ethernet layer by switching the source and destination, a new IP layer by switching the source and destination IPs, and a new TCP layer by switching the source and destination ports and adjusting TCP flags and sequence/acknowledgment numbers. It attaches a payload (read from payload.bin) to the TCP layer used to create a response packet that appears to originate from the original packet’s destination, effectively spoofing a reply. During communication, the injector script from the receiving server is introduced, which injects packets into the communication between the server and client. The Scapy library is used to intercept packets received from the device, and then it generates a TCP session hijacking attack through the inject function [19].

The script sets up a packet sniffing and manipulation mechanism that listens for specific TCP traffic and responds with forged packets in this TCP session hijacking experiment, concluding in a DoS attack. Also, a payload consisting of a large data packet was used, which was injected into the TCP connection and sent to the FMB device to simulate the DoS attack, by altering the size of the packets from 4 bytes to 1400 bytes and increasing the number of packets per second, causing malfunctions in the way the FMB device is handling incoming packets (see Figure 11).

This is how normal telemetry data packets are received from the server by the client, without being altered, with the received response of the FMB device being ‘\x00\x00\x00\x0x’, according to the Teltonika Codec 8 Extended communication and encoding protocol, as shown in Figure 12.

How the server communicates and replies, within parameters, to the FMB IoT device is shown in Figure 13, according to the Teltonika Codec 8 Extended communication and encoding protocol.

A security issue arises when the considered compromised telemetry server initiates a test simulation DoS attack using TCP session hijacking on a Teltonika FMB IoT GPS client device, as is shown in Figure 14, using the TCP injector described in Figure 9.

How the FMB device client is compromised and receives the payload, including malicious packets, over the TCP connection and port 1111 is presented in Figure 15.

The FMB device is compromised, and the telemetry data reception server loses communication with it, as in Figure 16.

To monitor data traffic during the DoS attack, data packets are captured using the tcpdump tool, where, before the initiation of the attack, the received data are 4-bit size packets, as shown in Figure 17.

After the initiation of the attack, the monitored traffic shows packets of large sizes, exceeding the allowed limit, specifically 1400 bytes (see Figure 18).

Also, during the monitoring of the traffic, many packets per unit of time are identified, as shown in Figure 19. They indicate a DoS attack; these packets are rejected by the device but are still reaching it and need to be processed.

This presented security issue involves implementing IPS/IDS capabilities at the FMB firmware level, which includes the protection of FMB devices against DoS attacks, which could also lead to potential buffer overflow at the device level, thereby affecting the integrity and availability of data and GPS-based IoT infrastructures for intelligent transportation systems, representing a significant risk to IoT device security [1,7].

The security solution was designed to implement protection mechanisms and show us how to detect and respond to a DoS attack in an IoT GPS tracking device such as Teltonika, using its IDS/IPS capabilities and protection as part of the FMB firmware client device. The code presented in Figure 20 also covers a possible buffer overflow scenario caused by this kind of attack.

The send_alert function is responsible for handling the scenario in which an alert needs to be sent due to certain conditions being met (like the accumulation of a certain number of invalid packets).

After switching servers, it calls the alert_server, which handles the actual alerting mechanism. The specifics of this alerting involve logging and sending a network message, which is achieved by triggering an external process.

The check_packet function validates incoming packets based on several criteria such as the minimum_send_period variable, which is checked against the time_diff variable; if it is higher the packet is considered too frequent and invalid.

The packet data must not be greater than 4 bytes, and its content must meet specific criteria (first three bytes 0x00 and the last byte must not be null).

If the packet is valid (the function check_packet returns 0), the code inside the if statement executes. If the packet is invalid (check_packet returns −1), the if condition fails and the packet is not processed.

If the packet is invalid, the invalid_packets counter increases. When this counter reaches the alert_threshold, the send_alert function is triggered, and the counter is reset (referring to IDS capabilities for DoS).

The minimum_send_period calculation is a way to dynamically set a threshold for data transmission frequency based on the operational context and with an added constraint to further limit the rate of data sending, according to Formula (2):

$$M_p=\frac{min\left({SP}_s,{SP}_m\right)}{2}$$

(2)

The function min is used to compare send_period_moving and send_period_stop. These two variables represent different time periods, likely configured based on the operational context of the device or system (e.g., a GPS tracker might have different sending periods when moving vs. when stationary). The send_period_moving could be the time interval (in milliseconds, seconds, or another unit) at which the device sends data when it is moving. The send_period_stop is the time interval at which the device sends data when it is stationary. The min function returns the smaller of these two values. If send_period_moving is less than send_period_stop, it will be chosen, and vice versa. This step ensures that the more frequent sending period (i.e., the smaller interval) is used for the next part of the calculation. Determining the shortest period, it finds the smaller of the two provided periods. The minimum period is halved and then converted to milliseconds. This halving serves as a form of rate limiting or debouncing, ensuring that packets are not processed too frequently.

This helps in managing the data flow and could be essential for optimizing network traffic, especially in scenarios involving multiple devices or limited network resources.

The system monitors network packets and checks their validity based on their size, content, and frequency of arrival. An alert is triggered in the backup telemetry server if the number of invalid packets reaches a certain threshold and main server stops processing the malicious traffic. The system may switch between a main server and a backup server based on the given conditions, according to the presented solution, for security reasons. The log results can be seen in Figure 21.

The previous logs demonstrate how the system actively monitors potentially malicious traffic patterns, validates packets, and takes measures to maintain FMB IoT device integrity and availability in the face of a suspected DoS attack. The system’s ability to switch to a backup server during a potential attack is a key feature for ensuring its continuity and resilience.

To evaluate our solution, we employed two test scenarios that included performance metrics [22]. In the first scenario, we executed the injector.py script from the virtual server machine to a virtual device running standard firmware. In the second scenario, we performed the same operation on a virtual device operating with modified firmware. During both test scenarios, the script was executed 100 times over a period of 300 s with 20 s interruptions, stopping and restarting the injector script every 20 s to initiate a new session.

From these test scenarios, we gathered the following data to assess the feasibility of our solution: the number of packets sent from the server machine, the number of packets received by the router, the number of packets received by the device, the number of packets processed by the device, the number of packets deemed invalid by the device, the number of replies the device was able to send back to the server and/or the backup server, the time interval before the device detected an attack and redirected traffic to the backup server, and the CPU and memory usage of the device.

During the attack simulations, in the first scenario, approximately 15,320 packets were sent during each attack. Of these, 2559 packets were received by the router machine, and 2548 packets were received by the device machine. In test cases involving standard firmware on the device, the server did not receive any normal replies from the device. Instead, the device received the payload each time in place of the normal acknowledgment packet from the server, indicating that the attack’s efficiency was 100%. Consequently, the device had to process the payload packet each time.

Additionally, we observed that the average CPU usage on the device increased by 9.5%, and its average memory consumption increased by 15%. The conclusions drawn from the simulated attacks in the first scenario are as follows: the device completely lost communication with the server, consistently received the payload packet instead of the standard acknowledgment packet from the server, and had to expend more CPU and memory resources to process the incoming attack packets.

In the second set of attack simulation scenarios, where the device was operating with the modified firmware that incorporated our solution, an average of 16,920 packets were sent during each attack. Of these, 2540 packets were received by the router machine, and 2340 packets were received by the device machine. The attack was accurately detected in each run of the scenario, resulting in an accuracy rate of 100%. The average detection time was 1200 milliseconds, after which the device switched communication to the backup server and maintained this communication until the attack scenarios were completed.

By observing the packets received by the main and backup servers, we determined that, on average, two packets were lost in communication with the device during the attack out of a total of 60 packets that should have been received given the 5 s sending interval. This translates to an average packet loss of 3.3%. Considering that, under normal operation, the delay between packets sent to the server would be significantly higher (it is recommended to be between 60 and 120 s), its efficiency would be improved, with an average of one packet lost during an attack, equating to a 1.6% packet loss. This corresponds to a 98.4% efficiency in preventing communication loss.

Further analysis of the packets received by the device revealed that an average of three payload packets were received before the alert was triggered and communication was redirected to the backup server. Finally, examining the resource consumption of the device, we observed an average increase of 2% in CPU usage and a 5% increase in memory usage.

The obtained results are summarized in

Table 2. IDS/IPS performance metrics.

Parameter Measured	Value Obtained
The scenarios’ context
Executions	100 times
Period	300 s
Interruptions	20 s
Injection interval	20 s
Scenario 1
Sent packets	15,320
Packets received by the router	2559
Packets received by the device	2458
Attack efficiency	100%
CPU usage increase	9.5%
Average memory consumption increase	15%
Communication	lost
Scenario 2 (including IDS/IPS algorithm)
Sent packets	16,920
Packets received by the router	2540
Packets received by the device	2340
Attack detection rate	100%
Attack average detection time	1200 ms
IDS/IPS efficiency	98.4%
Average CPU usage	2%
Average memory usage	5%
Communication	kept and switched to the backup server

.

5. Discussion

IoT tracking devices, such as Teltonika, are used in a variety of critical applications, such as tracking ambulances, police cars, and other emergency vehicles, as well as in logistics, fleet management, and asset tracking. In such applications, the tracking device must be always reliable and available to ensure the safety and security of people, systems, data, and assets. We researched the importance of integrating security mechanisms and algorithms that include IPS/IDS capabilities, specifically for DoS protection, into Teltonika firmware for IoT GPS tracking devices. We began by discussing the vulnerabilities and threats that exist for these types of devices, including the potential for DoS attacks that could compromise the availability of the device.

Our proposed future work will be to develop integrated intelligent algorithms to monitor, detect, alert, and prevent complex cyber attacks in real time on IoT devices that also include the new generation of communication and 5G technologies. We plan to discuss the results and how they can be interpreted from the perspective of previous studies and of our working hypotheses. The findings and their implications should be discussed in the broadest context possible. Future research directions may also be highlighted.

5.1. Real-World Applications and Scenarios

The proposed integration of intrusion detection systems (IDSs) and intrusion prevention systems (IPSs) into the firmware of GPS tracking devices holds significant promise for enhancing the security and reliability of IoT deployments across various real-world applications.

Intelligent transportation systems utilize IoT GPS tracking devices to monitor and manage the movement of vehicles, ensuring efficient and safe transportation. The integration of IDS/IPS mechanisms is crucial in preventing denial of service (DoS) attacks that could disrupt communication between vehicles and control centers. In smart cities, GPS trackers installed on public buses communicate real-time location data to a central management system. A DoS attack could incapacitate these devices, leading to a loss of service visibility, delays, and potential safety hazards. By embedding IDS/IPS into the firmware, each device autonomously detects and mitigates attack attempts, ensuring continuous operation and data integrity.

Emergency vehicles, such as ambulances and fire trucks, rely on GPS tracking for their dispatch and coordination. The ability to maintain a secure and uninterrupted communication link is critical for timely responses to emergencies. During a city-wide emergency, an ambulance’s GPS tracker could be targeted by a DoS attack aimed at disrupting its connection to the dispatch center. With the proposed IDS/IPS integration, the device could identify the attack, switch to a backup communication server, and continue transmitting its location, ensuring that the ambulance reaches the emergency site without delay.

Logistics companies depend on GPS tracking to monitor and optimize their fleet operations, track shipments, and ensure timely deliveries. Security breaches can lead to significant operational disruptions and financial losses. A logistics company’s fleet is equipped with GPS trackers to monitor vehicle locations and routes. A coordinated DDoS attack on these devices could lead to a loss of tracking capability, delays, and the potential theft of goods. Embedded IDS/IPS mechanisms can detect abnormal traffic patterns, block malicious packets, and maintain secure communication, thereby safeguarding logistics operations.

Asset tracking involves monitoring high-value assets in transit or storage using GPS devices. Ensuring the security and availability of tracking data is paramount to prevent theft and loss. A company uses GPS trackers for high-value asset tracking during transportation. An attacker initiates a DoS attack to block the transmission of location data, intending to intercept the assets. An IDS/IPS firmware integration can detect and mitigate the attack, rerouting communication to a secure backup server, ensuring the continuous tracking of the assets.

Critical infrastructure such as power grids, water supply systems, and communication networks use IoT devices for monitoring and management. Securing these systems against cyber attacks is essential to prevent large-scale disruptions to critical services and sectors. IoT GPS devices monitor a power grid’s maintenance vehicles. A DoS attack on these devices could prevent timely maintenance and lead to power outages. An IDS/IPS integration ensures that the GPS devices can continue to function correctly under attack, maintaining the reliability and security of the power grid.

5.2. Advantages and Disadvantages of the Proposed Algorithm

The advantages of implementing the presented algorithm include the integration of IDS/IPS mechanisms directly into the firmware of IoT GPS trackers, significantly enhancing security. It provides a real-time detection and prevention of cyber attacks, particularly DoS and DDoS attacks. This ensures that devices can autonomously identify and mitigate threats, reducing the risk of data breaches and service disruptions. Each device manages its own security autonomously, reducing dependency on centralized monitoring systems. This decentralized approach allows for a scalable expansion of IoT networks without overburdening central systems, ensuring continuous operation even if parts of the network are compromised. By preventing DoS attacks, the proposed algorithm ensures the continuous availability of the critical services provided by IoT devices. This is crucial for transportation, logistics, and emergency services, where uninterrupted service is essential. The proposed algorithm is designed to be lightweight, minimizing its impact on device performance. Efficient resource utilization ensures that security measures do not significantly degrade the operational efficiency of the IoT devices. Over-the-air (FOTA) updates allow for the rapid deployment of security patches and updates. This ensures that devices can quickly adapt to new threats and maintain up-to-date security measures without requiring manual intervention.

The potential disadvantages of adopting the presented algorithm are related to IoT devices typically having limited processing power and memory. While the algorithm is designed to be efficient, there may still be scenarios where resource constraints limit its effectiveness, particularly in devices with very minimal hardware capabilities. Integrating IDS/IPS mechanisms into the firmware requires sophisticated programming and thorough testing. This adds complexity to the development and maintenance of IoT devices, potentially increasing development time and costs. As a network of IoT devices grows, its cumulative processing and memory requirements can increase. This may necessitate further optimization of the algorithms and potentially more powerful hardware to handle the increased load. Intrusion detection systems can sometimes generate false positives, flagging legitimate traffic as malicious. This can lead to unnecessary alerts and interruptions to service, which could be problematic in critical applications. In the proposed solution, the proposed algorithm utilizes backup servers that ensure availability even in the event of false positive alerts. While FOTA updates are advantageous, they also carry risks if not managed properly.

Impact: an improperly managed update could introduce vulnerabilities or disrupt the normal operation of devices.

6. Conclusions

The implementation of IDS/IPS mechanisms in IoT infrastructures and GPS monitoring devices plays an important role in ensuring data security and service availability in the event of DDoS attacks. Given the technical limitations of these devices, the implementation of IDS/IPS mechanisms at the firmware level has succeeded in mitigating the effects of DDoS attacks while maintaining the security of the data and the availability of IoT devices.

Furthermore, by integrating these security measures directly into the firmware, organizations can proactively defend against potential vulnerabilities without significantly impacting the performance or functionality of IoT devices. This approach is particularly beneficial in resource-constrained environments, where traditional security solutions may be impractical.

To conclude, the strategic deployment of IDS/IPS in IoT and GPS monitoring infrastructure not only fortifies the security landscape but also paves the way for safer, more reliable digital ecosystems. By prioritizing these advanced protective measures, we can enhance the resilience of our interconnected devices to an increasingly hostile cyber environment.

The proposed solution, integrating IDS/IPS mechanisms directly into the firmware of Teltonika GPS tracking devices, presents a scalable framework for broader IoT deployments. The key features that facilitate its scalability include decentralized security management, efficient resource utilization, and robust update mechanisms.

By embedding security mechanisms within the device’s firmware, each device can autonomously handle intrusion detection and prevention. This decentralized approach reduces dependency on centralized servers, allowing for seamless network expansion as new devices are added. Autonomous security management minimizes the risk of a single point of failure, enhancing the overall resilience of the IoT infrastructure.

Its rate-limiting and packet validation mechanisms are designed to efficiently handle high volumes of traffic, which is essential for environments with numerous interconnected devices. This solution includes optimized algorithms that ensure minimal impact on device performance, even as the network scales.

The firmware can be updated over the air (FOTA), ensuring that security patches and updates can be deployed quickly and efficiently across all devices in the network. This capability is crucial for maintaining security integrity as new threats emerge and for ensuring that all devices operate with the latest security enhancements.

As the number of devices increases, the cumulative processing and memory requirements may rise. It is essential to continuously optimize IDS/IPS algorithms to minimize resource consumption. Implementing lightweight and adaptive security protocols can help maintain device performance while providing robust security.

High network traffic volumes could potentially lead to congestion and latency issues. Employing advanced traffic management techniques, such as load balancing and dynamic bandwidth allocation, can mitigate these effects. Ensuring that the network infrastructure supports scalable bandwidth and latency requirements is vital for maintaining performance. Coordinating firmware updates across many devices can be challenging. Developing a reliable and efficient update distribution system that can handle simultaneous updates without overloading the network is crucial.

Implementing staged rollouts and rollback capabilities can help manage updates more effectively and reduce the risk of widespread disruptions. As IoT deployments expand, the variety and sophistication of potential cyber threats also increase. Continuously monitoring threat landscapes and updating IDS/IPS mechanisms to adapt to new attack vectors is necessary. Incorporating machine learning and AI-driven security analytics can enhance our ability to detect and respond to emerging threats in real time.

In conclusion, the proposed solution offers a scalable and effective framework for securing IoT deployments. By addressing potential challenges related to resource constraints, network traffic management, firmware update coordination, and evolving security threats, this approach ensures that IoT networks can expand securely and efficiently.

By integrating IDS/IPS mechanisms directly into the firmware of GPS tracking devices, organizations can significantly enhance the security and reliability of their IoT deployments across various real-world applications. This proactive approach ensures that IoT devices remain secure, resilient, and capable of maintaining critical operations even in the face of sophisticated cyber attacks.

Although the experiments were carried out based on a specific firmware platform used in the intelligent transportation systems domain, the DoS attack prevention techniques presented in this paper can be implemented by other IoT systems that exchange data over the Internet.