Tutor HuntResources Network Security Resources
Real-time Streaming Protocol (rtsp) Performance & Security In Video Streaming
The Real-Time Streaming Protocol (RTSP) is a protocol for creating and managing time-synchronized streams for multimedia communications.
Date : 04/08/2023
Author Information
Uploaded by : Zakir
Uploaded on : 04/08/2023
Subject : Network Security
REAL-TIME STREAMING PROTOCOL (RTSP) PERFORMANCE SECURITY IN VIDEO STREAMING Supervisors: DR. Taufiq Asyhari AUTHOR: Zakir Ullah Mahsood (S21155671)
Degree: MSC CYBER SECURITY
DEPARTMENT: SCHOOL OF COMPUTING DIGITAL TECHNOLOGY DISSERTATION REPORT WRITING
Date: 12/09/2022 `
Abstract In the current era, most of the traffic through Web (desktop and mobile) has been increasing significantly. In the future, its predicted that nearly three-quarters of the traffic will be video in the upcoming years.(Zhang et al., 2014) Multimedia communications are one of the most demanding services in terms of quality, reliability, and network efficiency. In this work, we will present a comparative security and performance evaluation of the real-time streaming protocol (RTSP) for the on-demand and live streaming of the video over 4g, Wi-Fi, and then possibly with 5g network connections. The real-time streaming protocol (RTSP) is an application-level protocol that is used to determine the video streaming servers via play and pause capabilities.(Schulzrinne et al., 1998) RTSP also controls the delivery of data over real-time properties. In this work, we will also analyze and determine the problem with video streaming, in which factors such as latency, frame rate, packet losses, timing variation, and degradation of video quality will be identified.(Zhang et al., 2014)How to assess the serving performance of an RTSP streaming media server is an essential research subject since RTSP is extensively utilized in a range of streaming media applications and streaming service providers want to choose a high-performance streaming media server to suit their requirements.(Uitto Heikkinen, 2021) This article gives a way for creating and putting into practice a Performance Testing Utility for RTSP Streaming Server and offers a thorough study of the performance metrics of streaming media applications.(Mutchima Sanguansat, 2010). The tool primarily examines a multimedia server`s performance while providing a high number of concurrent streams and quantifies the statistics of various performance parameters based on the results of various stress tests. The program uses a multi-thread technique to establish numerous pseudo-terminal instances to imitate a particular number of concurrent users delivering RTSP signals.(Lohan et al., n.d. Mutchima Sanguansat, 2010) It also accepts media flow via a special IP address, analyses RTP packets, and counts the associated server performance metric value. Experiments demonstrate the tool`s efficacy and precision.We will also determine and identify the transmission of video streaming to be more secure while keeping the above factors in mind and mitigating the risks associated with video streaming. To summarize, we will need to incorporate security techniques, which could be security encryption, extra processing of intrusion detection systems, or an extra layer of authentication. All the experiments will be validated which will help us in determining the security and the performance of the video streaming using the Real-Time Streaming Protocol. Keywords: RTSP, cyber-security.5g, Video Streaming, Performance Security, applications of RTSP Acknowledgement I want to start by sincerely thanking my supervisor, DR. Taufiq Asyhari, for his ongoing support of my master`s dissertation, as well as for his patient direction and vast expertise. I want to thank them for their insightful criticism and support as well as for asking challenging questions that inspired me to broaden the scope of my project and consider it from a variety of angles. They also exposed me to direct interactions with university PHD students, which were extremely helpful in providing the project with the necessary inputs and feedback.Finally, I want to express my gratitude to every one of my family members and friends that helped me with this effort. Table of ContentsAbstract.................................................................................................... PAGEREF _Toc109948383 h 2 08D0C9EA79F9BACE118C8200AA004BA90B02000000080000000E0000005F0054006F0063003100300039003900340038003300380033000000 Acknowledgments...................................................................................... PAGEREF _Toc109948384 h 3 08D0C9EA79F9BACE118C8200AA004BA90B02000000080000000E0000005F0054006F0063003100300039003900340038003300380034000000 Table of Contents...................................................................................... PAGEREF _Toc109948385 h 4 08D0C9EA79F9BACE118C8200AA004BA90B02000000080000000E0000005F0054006F0063003100300039003900340038003300380035000000 Table of Figures......................................................................................... PAGEREF _Toc109948386 h 5 08D0C9EA79F9BACE118C8200AA004BA90B02000000080000000E0000005F0054006F0063003100300039003900340038003300380036000000 List of Tables............................................................................................. PAGEREF _Toc109948387 h 5 08D0C9EA79F9BACE118C8200AA004BA90B02000000080000000E0000005F0054006F0063003100300039003900340038003300380037000000 Chapter 1. Introduction............................................................................... 61 Background......................................................................................... 7
1.1 Aim Objectives……………………………………………………………………...7
1.2 Project Philosophy …………………………………………………………………...81.3. Research Question........................................................................... 91.4 Overview of Dissertation Our Results.............................................. 91.5 How to Read this Dissertation.......................................................... 10Chapter 2. Methodology........................................................................... 102.1 Quantitative Methodology................................................................ 102.2 System Development Methodology................................................... 11 2.2.1 Benefits Limitations................................................................. 13
2.2.2 Theoretical Background............................................................. 14
2.2.3 Security Aspects of the RTSP server…………………………………………14 2.3 Literature Review Methodology........................................................ 15
Chapter 3. Literature Review.................................................................... 15
Chapter 4. System
Development Architecture............................................ 18
4.1 RTSP Server Architecture:............................................................... 18
4.1.1 Workflow…………………………………………………………………………...18
4.2 Client-Side Architecture................................................................... 20
Chapter 5. Evaluation and
Testing of the System....................................... 24
5.1 General Classification of attack........................................................ 24
5.1.1 DOS Http overload attack.............................................................. 25
5.1.2 Layer attack................................................................................. 25
5.2 Implemention of attack..................................................................... 26
5.1 Mitigation of attack.......................................................................... 28
Chapter 6. Discussion of
Results.............................................................. 29
6.1 Testing Results of
Normal video Streaming VS During Attack............ 29
6.2
DDOS bandwidth flooding attacks on RTSP Server:………………………………30
6.3 Performance Evaluation using Machine Learning Algorithm……………………..31
6.3.1 Experimental results for test dataset………………………………………………31
Chapter 7. Conclusion and
Future Work.................................................... 33
Table of Figures
Figure 2.1 Incremental model
…………………………………………………………………………...….13
Figure 4.1 RTSP SERVER
PORTS…………………………………………………………………………..19
Figure 4.1.2 Server Running on FFMPEG…….…………………………………………………………...19
Figure 4.2 RTSP Server Architecture.……………………...…………………………………………....20
Figure
4.3 Data collection and data records in phpmyadmin...……………………………………….24
Figure 5.1.2 Fig 5.1.2: HTTP Get Flood Attack………………....……………………………………….25
Figure 5.2 HTTP Flood Attack Overload.py file.……………………………………………………….26
Figure 5.2.1: Attack Started.……………………………………………………...……………………….27
Figure 5.2.2: Attack Completed…………………………………………………...……………………….27
Figure 5.2.3 HTTP Flood Attack corrupted frames and latency.…..……………………………….28
Figure 6.1(A) Normal Stream test via 4g Network………………...……..…………………………….29
Figure 6.1(B) Normal Stream test via WIFI ………………………………..…………………………….29
Figure 6.2 Network under attack ……..………………………………………………………………….30
Figure 6.2.1 RTSP server during attack ……..………………………………………………………….31
List of Tables
TOC h z c "Table" Table 1:Distribution
for test dataset 32
Table 2:feature selection of
attributes 32
Table 3:precision of classifiers 32
Table 4:Detection of classifiers 32
Table 5:fmeasure of classifiers 32
Chapter 1. Introduction
The Real-Time
Streaming Protocol (RTSP) is a protocol for creating and managing
time-synchronized streams for multimedia communications.
RTSP 2.0 is a
two-way request-and-response protocol that controls how media resources are
provided from the provider to the user after establishing a context for those
resources. The three main parts of RTSP are session establishment, media
delivery control, and an extensibility mechanism. The protocol provides a
complete solution for client-controlled real-time media delivery and is based
on a few assumptions regarding functionality that currently exists. RTSP uses
text-based requests and responses, and the message bodies of these messages may
include binary data. An RTSP request`s method line, which identifies the
protocol, version, and resource to be used, comes first. An RTSP client uses
the hostname element of the URI to get the IPv4 or IPv6 address of the RTSP
server. A URI is used to identify the resource. Other RTSP headers come after
the method line. Each of these lines ends with two consecutive carriages return
line feed (CRLF) character pairs. If a message body is present, it is followed
by two CRLF character pairs, and a message header indicates how long it should
be. RTSP responses start with a response line that contains the protocol and version,
followed by a status code and a reasonable sentence, much like HTTP responses.
RTSP messages are sent between the client and server using a trustworthy
transport protocol. According to RTSP 2.0, clients and servers must implement
TCP and TLS over TCP as the needed transports for RTSP messages. RTSP
playback is not supported by iOS or Android smartphones
Within the
next 3 years, monthly global data will surpass 26 exabytes, with the
introduction of a 5g network and the expansion of the network rapidly it is
predicted that half of the world network traffic will be focusing on multimedia
communications such as video streaming (Sloman et al, 2015). According
to the characteristic of the streaming protocol in multimedia communications,
in this work, we will identify and address some of the security issues by
running different proposed attacks against the RTSP. Many Challenges were
identified such as high bit rate, delay requirements, latency, packet losses,
network congestion, and good video quality, which are indeed
critically important customer experience performance metrics nonetheless,
without security, the video material is vulnerable to attackers when it
contains sensitive or private data.
Media stream encryption can keep personal or
commercial information out of the hands of criminal actors. As RTSP protocol is
designed same as HTTP Protocol thus bad implementation related to exploit
vulnerabilities which can occur during streaming media. The vulnerabilities may
be mechanism. This
article suggests a method for creating and implementing a security layer for
RTSP-based Streaming Servers. We will also assess the protocol`s performance
and accuracy both during the attack phase and during the security
implementation phase.
1. Background:
In
this section, we will define the background of the real-time streaming
protocol. RFC 2326 contains information on RTSP, which was developed by the
Internet Engineering Task Force (IETF) in April 1998. It quickly became popular
because it allowed users to stream music and videos over the Internet without
having to download anything to a client`s device. The amount of time and
resources it saved thrilled everyone! Local area networks, where delivery
delays and losses are modest and regular, are where RTSP originated. It also
provides a number of other solutions. When the server needed to control
delivery to the client, RTSP was created and developed. Therefore, the server
handled all logic, including the decision of what to send when and to whom. The
client needed to be as simple and plain as possible, while the server needed to
be as complex as possible. The situation drastically altered after we switched
to the HLS and DASH protocols. The server was now more straightforward, but the
client was suddenly more complex. However, it was discovered that the
capabilities of intelligent monitoring of the RTSP server`s delivery had
vanished into oblivion. Nowadays, most RTSP servers are IP cameras that are
unaware of the RTSP capabilities that were developed decades ago. This suggests
that customer input is mostly unimportant. Everything is OK if the client gets
the data otherwise, there are problems. RTSP was created along with telephony.
It was based on already on-the-market, extremely successful technologies, but
we significantly updated them: SDP for content information transfer RTCP for
signalling the quality of data delivery (QoS) and RTP for data delivery. RTP
and RTCP were created about 25 years ago, but they have still been used the
same way in the de facto standard for real-time communication, WebRTC.This
should give you an idea of how successful these solutions are. They had all
they needed to remain financially stable to this day, even back then! RTSP used
to be the industry standard for streaming audio and video. However, adaptive
bitrate HTTP-based technology eventually eclipsed RTSP and RTMP. Today, IP
cameras are still utilized in video surveillance, and RTSP is still used for
signal capture. It is crucial to understand that RTSP for television and RTSP
for IP cameras are two different protocols. Only outdated systems that are
still in use support RTSP for television. Real time streaming protocol (RTSP)
was introduced in 1996-97 by Anup Rao of Netscape communications.
1.1
Aim Objectives:
The goal of the study is to use a streaming protocol
on multi-media communication to improve the video quality and improve its
security.
The above aim raises the following objectives:
·
Conducting and
analysing the RTSP protocol`s security measures in terms of performance in the
multi-media Communications
· To
improve the specific challenges such as high latencies, packet losses and
trade-off between security and performance with respect to RTSP based
multimedia communication
· Conducting Quantitative
research with RTSP protocol in the labs to experiment data analysis and improve
the security by carrying out attacks to test the security and performance of
video streaming
1.2
Project
Philosophy:
Project philosophy is
connected to assumptions, the nature and knowledge of the research, and the
method of knowledge production. The three-test driven
phenomenon—interpretivism, positivism, and pragmatism—will be used in this
study. As we will be focusing more on the performance and the security of the
Real time streaming protocol for video streaming. The Research will be based on
the data which will be taken from the manual steps that will be performed in
the Initial phases of the project where different parameters such as latency,
jitter, framerate etc will be analysed when using different network
connections. This work will be related to positivism because it will be highly
structured with medium to large data samples and will include the quantitative methodology.
Once the project is
in the middle phase, we will be doing the result analysis and evaluation of the
RTSP protocol that will include in-depth investigations. In the later stages
where the transmission of the protocol will be made secured, we will be
implementing security protocol using the best practices to achieve secure
communication for the end-users.
1.3
Research
Questions:
The
below research questions will be addressed as a part of the project proposal:
1)
How can we analyse
and implement Real time streaming protocol RTSP with respect to security and
the performance in video streaming?
2)
What are the
challenges and difficulties that can be faced during video streaming, keeping
in mind parameters such as video quality, bitrate, framerate, and packet loss?
3)
How can we secure the
transmission of media when using the real-time streaming protocol RTSP?
1.4
Overview
of Dissertation Our Results
This dissertation presents a
systematic approach to utilize different methodologies to design, develop and
evaluate a prototype which would support the enhancement of video streaming
regarding the RTSP protocol. The Overview of the project is divided into difference
chapters and then explained later in the respective chapters. The main message
of this report is: RTSP Protocol, RTSP protocol secure transmission, Security
layer and its performance metrics.
The dissertation is organized as follows:
Chapter 2 will be based on the methodology. That is going to include
system development methodology and literature methodology and the benefits and
limitations. Chapter 3 will be completely including the literature review which
has been studied during our research phase. This will include all the past work
done in the RTSP protocol and multimedia communications. This will describe our
work and its relation to the literature of the research.
Chapter 4 will be related to experiment analysis this chapter will
include the client and server-side setup. Configuration of client and
server-side multimedia protocols. The data collection.
Chapter 5 demonstrates the results evaluations and the testing of the
system during the attacks and during the implementation of the security
protocols.
Chapter 6 will demonstrate the future work that can be done in the
relative field and will demonstrate the results from chapter 5.
Chapter 7 presents conclusions and future work, and then followed by
reference, appendix, and screenshots.
1.5
How to
Read this Dissertation
The opening chapter summarises each topic
succinctly and explains in detail how the findings of each chapter relate to
one another. Since each chapter in this thesis is distinct from the others and
may stand alone, they can all be read separately. The reader is also expected
to have a foundational understanding of programming, machine learning, network
communications, and cyber security.
Chapter
2. Methodology
This
Chapter will contain the system development methodology, the literature review
methodology and its background.
2.1
Quantitative Methodology:
Quantitative
methodology refers to the process of collecting and analysing
data
that is numerical (Base and Methods, 2022). In this work we will mostly depend on the
quantitative methodology as we will be measuring the accuracy, latency, packet
losses, bitrate, and other performance metrics. The following phases
will be covered in the quantitative methodology these are:
a)
Project Development methodology: We will be using an efficient project
model called the iterative or incremental model to ensure flexibility for
requirement and implementation changes which will help us to deliver the project on time
with quality. The failure of the project can be reduced when using the
incremental model as stated by (Nilsson and Wilson, 2012).
b)
Types of attack: We
will be testing out the security of the RTSP protocol on both the client side
and server side by using different attacks such as DDoS, unauthorized access,
man-in-the-middle attacks, brute force attacks, automated dictionary attacks,
etc. once the tests are done, we will then take further steps to ensure that we
can mitigate these risks associated with the video streaming.
c)
Testbed development:
Testbed Development is the process in which a particular element is tested in
an isolated fashion (Fortier and
Michel, 2022). Testbed development methodology will help us to test all the
different phases in an incremental way.
d)
Creating New
Dataset: The dataset will be created
based on the performance calculations of Real Time Streaming Protocol (RTSP)
when using a different network such as Wi-Fi, 4g, and 5g connections.
e)
Validation of the results using machine
learning: During the project, we will also be using the Weka
simulator and perform the tests to calculate and measure the performance, and
accuracy of the protocol when implementing the security layer.
f)
Evaluation
and Result Findings: Findings from the result and evaluating the
algorithms using accuracy matrix and identifying the extracted patterns using
simulation techniques. This will include some of the performance metrics that
will be used for the validation and evaluation. These are 1) Accuracy, Packet
loss, Latency, bit rate, etc. In addition to the quantitative evaluation,
functional testing and analysis will also be done to ensure that the
experiments done, and the security layer implemented satisfies the requirement
specification.
2.2 System
Development Methodology:
We must consider what will happen for the
remainder of the project while selecting the suitable and acceptable technique.
As a result, we must adopt an approach that is required for bigger projects. To
disperse the job for better purposes, the technique must be a step-by-step
procedure. This project, which is a form of quantitative study, will include a
significant amount of literature research on existing streaming standards and
protocols as well as how scholars have identified and approached RTSP protocol
performance metrics. Incremental
model is the method chosen for this project. Since incremental model is a process
where requirements are divided into standalone modules and is primarily
designed for software development models, it offers the adaptability needed for
this project. The incremental model is a more flexible strategy based on
scientific research.
The incremental model, which is more focused on
the facts, in this model, each phase goes through the requirements, design,
development, implementation, and testing phases where every module would
release and add function to the previous releases and this process flows until
the outcome is achieved. This strategy enables the reconfiguration of certain
project components during weekly or monthly meetings with the supervisor,
allowing for subsequent re-planning based on an assessment of the product`s
current state of execution. As stated in this paper, the primary objective of
this project is to add a security layer to the RTSP protocol and evaluate its
performance to utilize it to gauge latency and visual quality for multimedia
communications.
The
First phase of the incremental model will start with gathering the requirements.
In this phase we will start and gather requirements from research databases
such as IEEE, Google Scholar and go through the literature reviews. This will
also include the flow to correctly setup the client and server side for the
multimedia communications. In this phase, we will primarily identify and define
our objectives and propose a prototype that is secured for transmission.
The
second phase will start with the design and development. In the designing part
we will be concentrating on the client-side architecture where we will have to
establish a function to log the data from the stream and then store it in the
database for further experiments. This will help us to determine and evaluate
the results which will be performed on the client side. The server side will be
setup using Open-CV python library with nginx server. This will help us to
transmit the stream and therefore develop a secure layer for the transmission
to avoid backdoor attacks or other emerging attacks.
In the
third phase we will start working on the testing of both the client and server-side
architectures. The testing will be done separately and the data from the
experiments will be saved for future experiments. In this phase we will be
testing the security and performance and log out the results to apply a machine
learning model which can evaluate the different parameters and give us the
result. The last phase will be for the implementation where the end product
would be tested out. This will include the implementation of the security layer
and the attacks that would be performed on the RTSP server. The result of this
implementation will help us to understand the system and its vulnerabilities
that can be exposed to the outer world. The feedback would be provided by the
supervisor and necessary measure would be taken to secure and produce the best
prototype for video streaming using different cameras and network connection
such as 4g and possibly 5g network. For the purpose of doing a critical
analysis of the data for this project, neither interviews nor questionnaires
are needed. As a result, this project will accomplish a number of its goals.
First, a significant amount of literature research will be conducted in the
fields of network communication, RTSP security protocols, latency and
performance metrics, the application layer of RTSP protocols, and specifically
investigating how specific RTSP protocols can be used to support efficient and
secure video streaming operation. The second and most important step is
determining the security aspect that will allow us to develop a secure video
streaming protocol capable of recording feeds from cameras via 4G, 5G, and
WI-FI networks. The project`s most time-consuming section will be this one. A
feasibility analysis for the deployment may be conducted once a security layer
has been built. The only purpose of this feasibility study will be to simulate
the performance metrics. Most likely, a Python and Javascri pt library will be
used. In order to make sure the server is safe and figure out how well it
works, it will be subjected to new attacks.
FIG 2.1 Incremental Model
2.2.1 Benefits Limitations:
The incremental model will be a great fit for
larger and complex projects. We use the incremental model when the requirements
are complex and clear. The benefits of
using incremental model are:
1.
When it comes to error finding and identifying
errors, it’s easy to work on.
2.
Incremental model is completely easy to test, and
then debug.
3.
Incremental model is flexible when it comes to
handling things and projects
4.
Its less costly to change
While on the other hand we can also see the
incremental model has some drawbacks to which are discussed below:
1.
Before starting it would need a good design and
planning.
2.
It needs a clear and complete requirement of the
whole system before the system can be broken incrementally.
3.
The total cost of the incremental model is more
likely going to be increased if the definition of the actual system isn’t
understood before.
2.2.2 Theoretical
Background:
For the development of this project, we have used the Go language
for the RTSP server. The RTSP server has been developed in the Go language,
which runs the server for us. We chose Python and the OpenCV Python framework
for the client side. The GO language, which is also mostly referred to as
Golang, is an open-source computer programming language designed and developed
by Google. It was initially built by Google because things in Google were
getting more complex due to the codebase architecture within Google. The Golang
was first introduced into the market by a renowned programming team known as
Robert Grasmere, Rob Pike, and Ken Thompson. Because of the nature of C++,
Golang was released to the public in 2009 as an open-source framework that was
primarily used in server-side programming, data science, and cloud-based
programming. As the market started to grow, many big giants, such as Twitch,
Netflix, and Drobox, started using Golang.
Python and a Python library called OpenCV have been used
for the client side of the project. OpenCV is an open-source platform that is
used in computer vision and machine learning software. It was designed solely
for the purpose of providing a common infrastructure for state-of-the-art
computer vision and machine learning algorithms. This library has more than
2000+ algorithms that include camera movements, classifying human actions in
videos, displaying streams, and much more. To store the data from the client
side and to perform different experiments on the data, we have used a
relational database language called MYSQL. MySQL is the query language that
inserts, selects, deletes, and updates records in the database. With the help
of a server-side language, we will store the data from the client side in the
MYSQL database and then later perform different experiments on the data using a
machine learning model. These experiments will enable us to check the data and
evaluate the results after performing cyber-attacks during the live streaming.
This will give us an accurate result of the performance parameters, such as
latency, frame rate, average fps, delay, and other performance metrics, so we
can see how the RTSP server is doing when using different network connections
and different security protocols.
2.2.3 Security Aspects of the RTSP Server:
Once we are done with setting
up the environment for the client and server side, we will then proceed with
the cyber security aspects of the project. In this module, we will try to use
different attacks on our RTSP server and then expose the vulnerabilities and
flaws in the server. These attacks can be session hijacking, pass word sniffing,
man-in-the-middle attacks, dos attacks, brute force attacks, and all the other
emerging attacks. These attacks would then give us an overview of the RTSP
server`s performance, and we could identify how the RTSP server works when it
is attacked. In this module, we will also be focusing on the different security
parameters and see how we can upgrade the security of the RTSP server. As
mentioned by (Ohuchani et al. 2011), all devices running on the RTSP protocol
can be extremely vulnerable to potential attacks since the RTSP service uses
default usernames and pass words. As again mentioned by (Lohan et al., n.d.,) if
an attack is carried out successfully, an attacker can control the intended
system. Cyber-attacks on IP cameras or other cameras through RTSP usually
represent a threat to the security of devices. With the increase of the
Internet of Things, it is true that there will be more large-scale attacks on
the RTSP servers in the future.
2.3 Literature Review Methodology:
The
literature review methodology will involve the previous research papers to
conduct a critical review and to identify the gaps in the performance
security of the Real time streaming protocol. This will include the research
questions, the sources that are going to be searched, strategy, action plan,
and the criteria selection. This will include the papers taken from the
databases such as IEEE, Google Scholar, Springer, Science Direct, ACM digital library,
and sources in which other RTSP papers are published. The search terms will
include the performance of RTSP protocol in video streaming, security
applications of RTSP protocol in video streaming, RTSP Protocol Cyber security,
Performance of RTSP protocol using 4g, 5g Wi-Fi network, etc.
Chapter 3. Literature Review
For this research
proposal, several literature reviews were studied to understand the background,
methodology, and research gaps in the Real Time Streaming Protocol (RTSP)
performance and security in the field of video streaming.
around 97% of performance when using the
RTSP protocol with RTCP and RTP protocols together.
(Yogesh
et all, 2018) explains the security of the different protocols when it comes to
video streaming applications. The author focuses mostly on internet-connected
IP cameras that are accessible to everyone on the internet. Using the firmware
images provided by the manufacturer on their own websites, he analyses the
devices nonetheless, his 0-day vulnerabilities are proven on live devices. In
addition, the author demonstrates how easy it is to find and exploit
vulnerabilities in the chosen cameras using the available tools. The author
selected ten D-Link Camera devices running a web server on a Light TPD
server. The attackers discovered a series of vulnerabilities that exposed
the devices` administrator pass words, allowed them to access a scri pt running as
root, and contained a remote code execution flaw.
(Prokofiev A.O. et all ,2017) developed a proactive intrusion detection
system which was specifically used to find out the vulnerabilities in the RTSP
devices widely used on the Internet of things. For the security of the RTSP
devices the author has developed honeypot which is going to allow and
investigate the cybercriminal behaviour or stop the unauthorized access. The
main results of the developed IDS and the common queries sent by cybercriminals
to interact with the system through RTSP were identified.
(Liu et al., 2010) in the
paper, Design, and Implementation of Performance
Testing Utility for RTSP Streaming Media Server reveals that the performance
metrics of the video streaming and the author proposes an approach to tackle
the different factors such as RTSP signals, RTSP packets, and counts the
related performance metrics from the server. The experiment in the paper
validates the efficiency and accuracy of the tool. A closer look into the other
literature reveals that there are a wide variety of research studies and
applications of RTSP protocol for different multimedia communications.
(Aloman et
al., 2015) has proposed a comparative performance evaluation of the streaming
protocol (RTSP) on 4g and Wi-Fi which has been done under different network
conditions in terms of the QoE. The author however states that the RTSP
protocol uses the non-standardized parametric process for comparative purposes
in which RTSP performs better than most of the video streaming protocols in
starting the video playback but at the expense of the QoE (Quality of user
experience) due to packet losses.
Another
literature review has been studied regarding the RTSP protocol security in
which the author (Liu et al., 2019)
has proposed an authorization model which can
mitigate the risks of malicious monitoring, modification, and terminating of
sessions as well server disguise, etc. People expect to speed, pause, and stop
when watching video streams and videos online, and in cases like these the
security is usually compromised which is becoming more and more prominent.
(Xin et al. 2008), the author proposed a
framework for real-time streaming protocol-based applications to determine the
performance. This was based on the four modules that include: an identification
protocol module, an application layer management session module, an attack
model module, and an attack analysis module. The performance measured is dependent
on the time delay between the attack occurred and its detection.
In this
project, we will work on the security aspects of establishing a secure RTSP
protocol in video streaming and mitigate the risks associated with RTSP-based
streams keeping in mind the performance metrics such as latency, packet losses,
and network congestion.
Chapter
4. System Development Architecture
In this chapter we will cover the Server-side architecture,
the client-side architecture, and the data analysis as well the data collection
techniques.
4.1 RTSP Server Architecture:
As we know that RTSP is an application-level system
that transmits data from devices by communicating directly with the server.
(Posey, 2022) When a user or a program tries to stream video from a remote
source, the client device sends an RTSP request to the server to get
information on the choices that are available. These options include pausing
the video, playing it, and recording it. The server will then deliver the
request list in RTSP format. Once the client is aware of how to make any kind
of request, it will submit a request for a media descri ption to the streaming
server. The server will then respond with a descri ption of the media that the
client has requested. After the client has sent a setup request, the server
will respond with specific information about the transport mode. After the
setup process is done, the client will start the streaming process by telling
the server to send the bitstream, which is a sequence of binary digits, using the
transport mode that was set up in the setup request. (Posey, 2022) Due to the
fact that RTP is an application layer protocol, it is constructed on top of
either TCP/IP or UDP. We use the lightweight UDP protocol and RTCP packets to
handle congestion control because TCP often has a lot of extra overhead
(because it has its own ways to handle congestion) and because UDP is simpler.
An accumulator variable is declared inside the class
and is increased by the length of each new packet that is received through UDP.
This allows for the number of bytes that have been received to be calculated.
The percentage of lost packets is calculated using two additional parameters:
the total number of anticipated packets and the cumulative number of packets
that have already been lost. Each time the actual sequence number of a packet
is discovered to be different from the predicted sequence number, the value of
the variable that tracks the cumulative number of lost packets is increased by
one. The counting number is used to determine the anticipated number of
packets. However, if part of the packets is lost and seqnum is larger than the
counting number, the expected number of packets is determined by the maximum
number of packets that were received. According to what was said previously,
the total number of bytes received is used to calculate the video data rate.
This pace is determined by the amount of time that the video is actively being
played and does not consider the amount of time that the video is pausing. The
client keeps track of the amount of time that has passed by measuring the
amount of time that has passed between each packet that it has received and
adding those times together. After then, this is used for the purpose of
computing the total data rate statistic.
4.1.1 Workflow:
The RTSP server is running on nginx and has been
created using the Golang programming language. The first step is to run the
RTSP server, but before running RTSP server its quite important to download all
the libraries and setup the path environment variables in the system. Once the
RTSP server started running on the Port 8554 that’s the default port of RTSP to
stream videos from camera or from other URL. The below screenshot shows that
the RTSP server is running and with that we can also see the remaining ports
which are open for other protocols.
FIG 4.1 RTSP server PORTs
As we can see that the RTSP listener is opened on
the port 8554 (TCP) and port 8000 for UDP/RTP and 8001 for UDP/RTCP. Once the
RTSP server is all set the next step was to stream the video. I used Visual
Studio code to run the GoLang code and stream the video using the pythons
OpenCV library. On a new terminal we ran the command ffmpeg -re -stream_loop -1
-i production.mp4 -c copy -f rtsp rtsp://localhost:8554/mystream which started
to stream the video from the producer.py file. The screenshot below confirms
that the video can be seen executing from running the above command.
FIG 4.1.1 Server Running on FFMPEG
Upon success, I started to run the video using the
VLC media player and the video started to run. VLC is a media player that can
stream the Videos in the client side for us. The overall flow can be seen in
the diagram below can show us how the stream from the server can be viewed in
the client side. As RTSP itself cannot be tested our tried out in the browsers,
to that we started to convert the stream from the RTSP to HLS, so that it can
be seen in the browser and the metrics can be fetched and stored in database
for further experiments.
FIG: 4.1.2 RTSP server architecture (Raj, 2019)
4.2
Client-Side Architecture
As explained above we are using
the client-side architecture to make requests to the server which can take the
stream by sending different commands such as play, pause, stop, describe etc. When
a client submits packets in accordance with the RTCP protocol, the information
about the quality of service may be sent back to the server. In addition to
that there is also implementation for statistics and performance optimizations
and to evaluate the latency, jitter, lost frames, packet losses, and the total
seconds delay before and after an attack on the RTSP server. The
development of the class FrameSynchronizer addresses the client-side problem of
grouping frames that were sent using out-of-order sequence numbers. To address
the issue, we use this class. This is achieved using a buffer, which keeps
track of the difference between the expected and received sequence numbers. If
there is a discrepancy, it will buffer the frame and insert several copies of
the just-shown frame into the empty space. I have created a set of labels and
performance metrics which are going to be stored in a MySQL database through an
API. The labels and the parameters which we will be storing in database are the
record type, duration, dropped frames, corrupted frames, latency, playback
rate, avg latency, and the max processes. Integration of optimization and
performance metrics has been integrated into the client. To do this, I came up
with a whole new class that takes the place of an RTCP packet and is named RTCP
packet. The RTCP protocol is built on top of the UDP transport protocol so that
there will be as minimal overhead as is humanly achievable. When compared to
RTP, the number of RTCP packets that are sent via UDP is much lower. This
change was made to cut down on the amount of overall load. On the server side,
the class known as Congestion Controller is the one that oversees managing
congestion. This responsibility falls on the server. It does frequent checks of
the statistics feedback from the client (through RTCP packets), and based on
the findings of those checks, it adjusts the rate at which it sends RTP packets
to the client. This is done so that the client receives the optimal amount of
data. There are four different levels of congestion, ranging from one to four,
and they are represented by the variable referred to as congestion Level. At
level 0, there is no sign of any congestion in the system. The client is
responsible for sending an RTCP packet, which contains a field called fraction
Lost. This data is extensively used as the foundation for the computations that
are used to determine the congestion level. The library and framework used for
the client side is called HLS, the stream is first converted from RTSP to hls
and then it runs on the browser which can give us the parameters.
Working Process of client
side:
As we know to run rtsp stream
in the browser we need to convert the stream into hls or other video streaming
protocol that has native support in browsers for the stream, therefore in the
case of RTSP, which doesn’t have any native support in the browsers, but we can
use media players such as vlc to stream our videos from IP cameras through RTSP
Protocol. The first thing is to install the FFMPEG tool.
i) FFMPEG:
The first step is to install ffmpeg. FFMPEG is a powerful tool that can handle
different multimedia files. Once ffmpeg is installed and the environment
variables are setup we then need to convert the rtsp URL to hls.
ii) Streaming
the video on the browser:
As
mentioned above for the client side we are using an hls plugin that can stream
the video for us in the browser. Upon converting the rtsp link to hls we can
see that the stream is running on HLS in the client side.
iii) Submitting
the data from client to DB through a submit button:
A
button labelled "Submit data" has been added to the client HLS to
enable users to evaluate the functionality of the data which is sent to the
MySQL database. When the submit button is clicked, the output of the server`s
response should be sent to the database. When using the Session technique, it is
important to keep in mind that the SETUP request must have been sent in the
past for the server to be in the INIT state. This is a prerequisite for the
method. Screenshot of the hls goes here.
Fig 4.2: client hls statistics
Fig 4.2.1: client hls main dashboard
Fig 4.2.2: client hls statistics submit data
to db
4.3 Data Collection technique and analysis:
For collection of the data, we
have simply used a query language called MySQL. The data is fetched from the client
side hls and then when clicking on the submit button the data is sent to the
database for further evaluation. As we are aware that sending data continuously
to database in a matter on nano seconds can result in a complete crash of db.,
so we have used a quite traditional approach which can store the data for us in
the MySQL database and later we can convert the data into .arf file and start
our experiments and evaluation on the data. The database stores the values of
duration type, latency, record type and frame rates, and the corrupted frames.
The data can be exported manually to a csv file first and after that we can convert
the data into an .arf file which we can use for the further experimental
processes. This data will be taken in two phases, the first phase will have the
data through a normal video stream and the second phase will involve the data
during the cyber-attack stage i.e when an attack is performed on the real time
streaming protocol server. We can see the screenshot below that contains the
columns names and the data that has been stored in there.
Fig 4.3: Data collection and data records in php my admin
Chapter 5.
Evaluation and Testing of the System
In this Chapter we will discuss the type of attack
we have chosen, the security parameter we have implemented and, we will discuss
the results of the system.
5.1
General Classification of Attack:
When it
comes to choosing one of the emerging attacks, initially we were looking to go
with 2 attacks that we knew is going to help us out in the penetration testing
of the RTSP server were: 1) MITM which is the main in the middle attack and the
second one was the DOS (Denial of service attack) to test out the RTSP server. So,
for this Project I have gone with the http overflood or also know as dos attack
to test out the RTSP server. It may be difficult to tell the difference between
attack traffic and regular traffic, particularly in the case of an application
layer assault, such as a botnet carrying out an HTTP Flood attack on a victim`s
server. In this kind of attack, the traffic being sent is at the application
layer. Because each bot in a botnet sends what seems to be valid network
requests, the traffic generated by the botnet is not faked and may appear to
have originated from a "regular" source. The application layer
assaults the need for an adaptable approach that includes the capacity to block
traffic based on specific rule sets, which may change on a frequent basis.
Tools like a well-configured web application firewall (WAF) may reduce the
quantity of fake traffic that is sent to the origin server, which in turn
reduces the severity of the DDoS attack significantly. When dealing with
various types of assaults, such as SYN floods or reflection attacks, such as
NTP amplification, there are ways that may be utilised to drop the traffic
reasonably effectively, if the network in question has enough capacity to take
them in. Unfortunately, most networks are unable to handle an amplification
assault of 300 Gbps, and even fewer networks are equipped to appropriately
route and service the number of application layer requests that may be
generated by an L7 attack.
5.1.1
DOS (DENIAL OF SERVICE):
The term “
Denial of Service” (or “DOS”) refers to an assault in which the resources of a
server are depleted by overwhelming it with many requests. This sort of assault
is almost never carried out by a single person but rather always with the
assistance of networks of automated software programmes known as botnets. (Gonzalez
et all,2017).
5.1.2
Layer Attacked:
The Layer
we have attacked is the OSI Models Layer 7 called application layer. Because it
is the OSI layer that is nearest to the end user, Layer 7 is the one that the
user and the OSI application layer interface with directly while using a
software program. Communication with this layer is open to any software
applications that make use of a communicative component. Standard application
layer duties include determining the availability of resources, locating
potential communication partners, and organising communication between those
partners. When finding communication partners for an application with data to
communicate with, the application layer is responsible for determining their
identity as well as whether they are accessible. When determining the
availability of resources, the application layer is responsible for determining
whether a sufficient network or the required communication is there. To get
everything in sync, the application layer needs to coordinate and manage all
the communication between applications. The method we have used is called the
basic HTTP Flood, these attacks, which are also known as basic HTTP
flooding attacks, are exactly what their name implies they are. In this case,
we have made use of our IP location and assets within the same range (this kind
of attack is considerably less severe than volumetric assaults) to repeatedly
access the same server. In a normal situation, the server would end up crashing
because it would be unable to cope with the sudden rise in the number of requests.
Fig 5.1.2: HTTP Get Flood Attack
5.2
Implementation of Attack:
As we know
that, using Dos attacks or any attack is illegal but for this project purpose
we are using in on our own server and using the IP address of my work internet.
We have used a python scri pt which will
send requests to the specific URL over and over again. In python, we have a
library called sockets, when sending messages across a network, sockets and the
socket APIs are used. They make possible a type of communication between
different processes (IPC). The network might be a logical one that is local to
the computer, or it could be one that is physically linked to a network that is
external to the computer and has its own links to other networks. The libraries we will need to do a
successfully http overflood attack we will need the following libraries:
Once we are done with the installation of the libraries, we will then find
the target IP-address and the port we want to attack which in this case will be
8554 that’s the port on which the real time streaming protocol server and
stream is going to run. Because it is the function that launches the assault,
this attack function will be the one that is carried out in each of our
separate threads. It begins a loop that will never finish, and while it is
operating, it will repeatedly send an HTTP request to the target, create a
socket for that target, and connect to that target. All these actions are
performed while the loop is active. If we are attempting to connect to a
different port, it is only natural that we will also need to modify the sort of
request that we send in order to do so successfully. After that we will open a
terminal where our file overload.py resides and run the command python3
overload.py which will start our scri pt. As we are using Node js for our
client-side streaming and to fetch data from the stream and store it in DB,
during the http overflood attack we will send multiple threads and check the
performance of the streaming. We can see the below screenshot where the attack
is happening on the server:
Fig
5.2.1: Attack Started
The time
we will have to put the duration of the attack, in threads I am going to send
500 threads in the 60 seconds and the url which is showing my ip address and
the port will the base64 url of the rtsp stream. The moment attack is started
we can send its starts to send the requests and payload size in the below
screenshot:
Fig 5.2.2: HTTP Flood Attack Started
We can see the payload sizes in the above
screen and if we look at our client side, it has started to overload the client
side with large number of requests that has started to corrupt and drop the
frames and latency can be seen and delay of the video stream too:
Fig 5.2.3: HTTP Flood Attack corrupted frames
and latency
Fig 5.2.4: HTTP Flood Attack corrupted frames and latency
So now we can clearly confirm that the attack is happening, and the
frames has started to drop.
5.3 Mitigation of the Layer 7 HTTP GET overload attack:
There are three ways to mitigate the layer 7
http overload attack and create a secure transmission between client and
server-side streaming. These are implementation of captcha, using ai or machine
learning for behaviour analytics, and web application firewall. During the video streaming using RTSP
protocol, I have gone with the WAF, known as web application firewall.
WAF:
Utilizing a complex firewall that is
purpose-built for the protection of online applications is one method for preventing
unauthorised access to web applications from the outside world. An advanced WAF
can manage, filter, and analyse the traffic coming from a variety of sources. The
application firewalls are dependent on rules and policies that can be amended
and updated in a quick and straightforward manner. It is possible that because
of this, it will respond to assaults more quickly. A WAF is our best bet when
it comes to protecting against DdoS assaults, particularly layer 7 attacks.
This is especially true for layer 7 attacks. Managed WAFs perform an Inspection
of layer 7 traffic and report any potentially malicious activity in the log
file. Through the log files we may then choose to block the traffic to stop it
from interfering with our services. As we know by default the rtsp streams
doesn’t use any username or pass word for every RTSP stream which can also be
vulnerable to attacks or when a username or pass word is inserted for a stream
someone might capture the credentials and see the stream using tools such as
Wireshark or fiddler therefore we have used hashing and encryption for the
username and pass words and also we have use a WAF firewall from GitHub which
can give us the extra security layer to protect the stream for any sort of bot
attacks and overload attacks.
Chapter 6. Results
and Machine Learning Algorithm
In this section I will perform the
discussion of the results using machine learning algorithm and compare the
results from normal stream and during the network attack stream.
6.1 Testing Results of Normal video
Streaming VS During Attack:
As in
the above chapters we have already discussed about how the stream works and the
evaluation, during the results analysis, we started to stream a video on the
RTSP server and then that was read in the client side. We streamed the video
for at least 10 minutes so that we can fetch as much data as we can and then
perform our machine learning algorithm to see what and how we are achieving the
accuracy or performance metrics. The below figure indicates the normal stream
evaluation results:
Fig6.1(A) Normal Stream test via 4g
Network Fig
6.1(B) Normal Stream test via WIFI
Figure 6.1(A) indicates that during the
testing with 4g network we can see that the latency was measure around 60 to
100 while the no of dropped frames and buffer size can be seen that they have
been started from 25ms and going to above 100 which indicates that the rtsp
server can be seen performing a little slower compared to using wife with a
higher speed. The above figure 6.1(B) tells us that when using a fast internet
or Wi-Fi the results can be seen normal and lag free, but only once the buffer
size has been gone up where we increase the number of clients receiving the
stream. In that duration the buffer size went directly from 50 to over 300 and
then it started to become normal, and the delay was minimized too. So, in
future if we use a 5g network the result can be greater and the stream can be
streamed normally without any delays although if the clients are increased too.
So, from this figure we can indicate and confirm that the RTSP stream on 4g, Wi-Fi
and 5g devices will perform normally and lag free.
6.2 DDOS
bandwidth flooding attacks on RTSP Server:
In this
research paper “Uninterrupted Video Surveillance in the Face of an Attack” the
authors have used a Blackbox approach on the standalone streaming server and
client using vlc to analyse the dynamics of the network which therefore results
in the exhausting of resources, such as network bandwidth, jitter, and delay.
The authors (Jagannadh Vempati et all.. ,2018) has performed a Dos attack on
the streaming server and then they have added a micro firewall rule that
contains two parameters, rate and burst size, which regulate the operation of
the streaming. These parameters are responsible for controlling the network
traffic. The observed traffic volume serves as the basis for the selection of
these parameters. If the traffic matches the profile that was provided, there
are two different sorts of policy measures that may be carried out. They
achieve this by (i) discarding the packet since it does not match the profile,
and (ii) lowering the DSCP value of the packet to match one that has a lower
priority. The results after implementing the firewall and during the attack
stages shows that the latency and jitter and the results during when the
network is under attack shows packet losses dropped frames, latency in delay in
the video streaming.
Fig 6.2 Network under attack (Jagannadh
Vempati et all.. ,2018)
The above
figure shows that when the network is under attack, we can clearly see the
effect of the attack on the server in seconds and therefore when it comes to
video streaming services, its very important to have a normal video streaming
quality for better user experiences. In
comparison to that, when the attack was actually performed on the RTSP
streaming server and we did a little different attack through using a get and
post session overload attack, the quality of the video and also the effect of
the user experiences in real time was affected too. We can see the results in
the below charts that explains the analysis in chart form:
Fig 6.2.1 RTSP server during attack
By looking at the above chart we
can confirm that the attack heavily effects the video streaming services and
can result in delay jitter as well packet losses. In the paper as mentioned
above the technique they used to mitigate or stop the attack and there feedback
method only improves actual traffic conditions. Except for the parallel path,
where there is a little latency, the network achieves a steady state in real
time in all these situations. There might be a delay because of how long it
takes to set up the link. Despite being a crucial QoS feature for video
streaming, we did not account for RTP latency when using this method since we
did not see a substantial change in the delay. We used a UDP flood to mimic a
distributed denial-of-service (DDoS) assault. In our approach, the micro
firewall rule monitors for certain types of traffic and, if it detects video
data, it continues to do so without any delays. This approach is inappropriate
for data transmission since the rate at which information is transferred may be
hard to predict. Moreover, prioritising data transmission is not a good idea.
By eliminating the low-profile traffic scenario, we were able to stabilise the
network again, but we were unable to actively stop the attack.
6.3 Performance Evaluation using Machine
Learning Algorithm:
In this research we have used certain
machine learning algorithms, such as random tree, bayes, and random forest to
determine the accuracy of these algorithms in to the normal and attack classes.
We have used weka tool which is going to be used to perform the method best
first search method on a correlation-based feature selection and we will use
the precision, recall and f-measure parameters on our RTSP dataset which is
divided into two main classes called normal and attack classes.
6.3.1 Experimental results for test
dataset:
As I have mentioned above that I have used
WEKA tool for my research which is an open-source ML scri pting software
developed in JAVA by the University of Waikato New Zealand (Hall et al, 2009),
the below table shows the different classes and the samples given to perform
these experiments.
No of Samples |
|
Normal |
400 |
Attack (DOS) |
400 |
|
|
CBFS (Using Best first Method) |
Record type |
Duration |
Dropped Frames |
Corrupted Frames |
Latency |
Target Latency |
Table 1: Distribution for test dataset Table 2: Feature Selection of attributes
We did the experiment using the correlation-based
feature selection (CFS) with best first search method in other to remove the features
which are irrelevant. Our RTSP Video streaming dataset contains around 17
attributes and we have performed feature selection on the attributes using CFS,
now we are left with 6 attributes which can be seen in the table 2. As
mentioned above that the parameter we will target are going to be Accuracy(precision)
= TP/TP+FP and detection rate or recall is considered as the number of attacks
detected by the proposed algorithm and detection Rate is calculated as TP/TP+FN
and F-Measure = 2*P*R/P+R. (Modi Jain, 2016). Our
First detection technique was based on precision of classifiers in which we
analysed j48 Random Forest, NaiveBayes algorithms to check the precision on the
Normal and Attack class. The below table indicates the precision of different
classifiers:
Random Forest % |
NaiveBayes% |
Class |
|
0.999 |
0.999 |
0.985 |
DOS(Attack) |
0.979 |
0.984 |
0.993 |
Normal |
0.989 |
0.9915 |
0.989 |
Weighted.Avg |
Table3:
Precision of classifiers
As we can see from the table 3 all the
three techniques against the classes attack and normal shows that Random Forest
performs the best and has the highest precision in classifying the record type
attribute in the label named class. As far the detection rate (recall) of the classifiers
algorithm is concerned we can confirm that j48 has the highest detection rate
followed by random forest as shown in the below table:
Random Forest % |
NaiveBayes% |
Class |
|
0.994 |
0.997 |
0.999 |
DOS(Attack) |
0.989 |
0.964 |
0.985 |
Normal |
0.9915 |
0.9805 |
0.992 |
Weighted.Avg |
Table4:
Detection of classifiers
Now in the table no 5 we can see the
F-Measure of classifiers in which we can see that the j48 outperforms the other
two.
J48
% |
Random
Forest % |
NaiveBayes% |
Class
|
0.999 |
0.987 |
0.993 |
DOS(Attack) |
1.000 |
0.964 |
0.992 |
Normal |
0.999 |
0.9875 |
0.992 |
Weighted.Avg |
So, from this we can confirm that the
experiment which was done using the 3 classification techniques with the CFS
for attribute selection using the BFS (Best first search) method alongside
10-fold cross validation.
Chapter 7. Conclusion and Future Work
If the defensive technologies
against the rapidly growing cyber threat are not reviewed, researchers predict
a catastrophic increase in the number of cyberattacks (Kotsiantis, Zaharakis
Pintelas, 2007). As a result, there won`t be any place on the internet
where users` sensitive information may be kept safe. To protect against several
different types of attempts to breach a network`s security, this research
focuses on the performance and security of the RTSP protocol, applying advanced
machine learning algorithms. The accuracy of three distinct classification
methods used in the RTSP dataset was compared, and the results are presented.
We conducted an experiment on the performance of the multimedia communication
protocol known as the Real-time Streaming Protocol (RTSP), in addition to the
security of the protocol itself. A closed local network environment served as
the setting for the experiment, which was carried out with the intention of
determining the level of performance and security offered by an RTSP media
stream. The performance of the stream was evaluated by using metrics such as
latency, delay, and jitter in both the normal and DoS attack environments.
After that, the dataset was logged in and exported into a CSV format to convert
it into the ARFF format for further classification by making use of several
different machine learning algorithms. The evaluation of the stream revealed
the existence of a vulnerability in the real-time streaming protocol server. As
a result, we carried out a DoS attack on the server to test its security
controls. However, the attacks had a significant impact on both the latency and
the server. As a result, latency increased to levels that were up to 30% higher
than normal. In the end, the streaming was terminated because of the payload on
the server. The research questions that were related to both performance and
security were therefore solved by the fact that we need to implement standard
security controls such as micro firewalls and assign encrypted usernames and
pass words to the URL if we are running the stream through the IP address of the
capturing devices. This was the solution to the research questions that were
related to both performance and security. The implementation of the
classification machine learning algorithm indicated that the results
demonstrated that such an algorithm can identify an attack in the stream`s
characteristics dataset. This was shown by the results of the implementation.
Lastly, it was found that the detection rate, precision, and F-measure
parameters of the classification algorithm were 98%, 99%, and 99%. We can conclude
that j48 offers a greater degree of accuracy on the dataset that was taken
based on the outcomes of the work that was done. This shows that a machine
learning-based intrusion detection system can be successfully added to an RTSP
server-based video stream without hurting the stream`s overall performance. For
future we can test out the stream using 5g network and with that we can implement
standard micro firewalls that can protect the stream It is necessary to do more
research on the application of recommended security measures in order to assess
the differences in the stream performance metrics values after deployment. In
the future, we`ll include operations and development expenses, as well as the
probability and associated costs of an attack`s impact.
References
Jagannadh Vempati, Ram Dantu, Mark Thompson, Uninterrupted
Video Surveillance in the Face of an Attack. 2018 17th IEEE International
Conference On Trust, Security And Privacy In Computing And Commmunications/
12th IEEE International Conference On Big Data Science And Engineering Abdulazeez,
H. K., Khamiss, N. N., Ahmed, S. M. (2022a). OPTIMAL ADAPTATION OF
INTERNET VIDEO STREAMING. In Journal of Engineering Science and Technology
(Vol. 17, Issue 2). Aloman,
A., Ispas, A. I., Ciotirnae, P., Sanchez-Iborra, R., Cano, M. D. (2016).
Performance Evaluation of Video Streaming Using MPEG DASH, RTSP, and RTMP in
Mobile Networks. Proceedings - 2015 8th IFIP Wireless and Mobile Networking
Conference, WMNC 2015, 144–151. https://doi.org/10.1109/WMNC.2015.12 Arunachalam,
M., Patil, A. M., Uke, N., Lal, J. D., Sonawane, V. R., Rajagopal, R.
(2022). A Real-Time 3D Video Streaming System Using SRTP AND RTSP Protocol. IJCSNS
International Journal of Computer Science and Network Security, 22(6),
620. https://doi.org/10.22937/IJCSNS.2022.22.6.76 Cmpe.
(2009). RTSP Protocol Focus on SECURITY 2009 Samuel MONY-Philippe SAWADOGO. Effective
IP Camera Video Surveillance With Motion Detection and Cloud Services.
(n.d.). https://www.researchgate.net/publication/358749439 Hatem
Mohammed, A., Kadir Mahamad, A., Saon, S. (n.d.). Evolution of
Information, Communication and Computing Systems (EICCS) https A Study of
Island Network Performance for Streaming Protocols. IEEE
Communications Magazine •. (2007). Lanphier
Westerlund Ericsson M Stiemerling, R. M. (2016). Real-Time Streaming
Protocol Version 2.0. http://www.rfc-editor.org/info/rfc7826. Liu,
Y., Zhong, G. H., Liu, Y., He, H. Q., Wang, F. R. (2008). The research
of streaming media mutual digest authentication model based on RTSP protocol. Proceedings
of the 2008 International Conference on Wavelet Analysis and Pattern
Recognition, ICWAPR, 2, 838–842.
https://doi.org/10.1109/ICWAPR.2008.4635893 Lohan,
F., Defée, I., Vlad, M. (n.d.). The Architecture of an Integrated
RTSP, RTP and SDP Library. Mutchima,
P., Sanguansat, P. (2010). A novel approach for measuring video
similarity without threshold and its application in sports video
categorization. Proceedings - 2010 1st International Conference on
Pervasive Computing, Signal Processing and Applications, PCSPA 2010,
868–872. https://doi.org/10.1109/PCSPA.2010.215 Rasanen,
J., Altonen, A., Mercat, A., Vanne, J. (2021). Open-source RTP Library
for End-To-End Encrypted Real-Time Video Streaming Applications. Proceedings
- 23rd IEEE International Symposium on Multimedia, ISM 2021, 92–96.
https://doi.org/10.1109/ISM52913.2021.00023 Santos-González,
I., Rivero-García, A., Molina-Gil, J., Caballero-Gil, P. (2017).
Implementation and analysis of real-time streaming protocols. Sensors
(Switzerland), 17(4). https://doi.org/10.3390/s17040846 Schulzrinne,
H., Rao, A., Lanphier, R. (1998). Rfc 2326 Title Real Time Streaming
Protocol (RTSP) Author. https://www.hjp.at/doc/rfc/rfc2326.html Seralathan,
Y., Oh, T. T., Jadhav, S., Myers, J., Jeong, J. P., Kim, Y. H., Kim, J.
N. (2018). IoT security vulnerability: A case study of a Web camera. International
Conference on Advanced Communication Technology, ICACT, 2018-February,
172–177. https://doi.org/10.23919/ICACT.2018.8323686 Uitto,
M., Heikkinen, A. (2021). Evaluation of live video streaming performance
for low latency use cases in 5G. 2021 Joint European Conference on Networks
and Communications and 6G Summit, EuCNC/6G Summit 2021, 431–436.
https://doi.org/10.1109/EuCNC/6GSummit51104.2021.9482605 Uitto,
M., Heikkinen, A. (2022). Evaluating 5G uplink performance in low
latency video streaming. 2022 Joint European Conference on Networks and
Communications 6G Summit (EuCNC/6G Summit), 393–398.
https://doi.org/10.1109/EuCNC/6GSummit54941.2022.9815703 Watequlis
Syaifudin, Y., Fahrur Rozi, I., Ariyanto, R., Rohadi4, E., Adhisuwignjo,
S. (2018). Study of Performance of Real Time Streaming Protocol (RTSP) in
Learning Systems. International Journal of Engineering Technology,
7(4.44), 216. https://doi.org/10.14419/ijet.v7i4.44.26994 Zhang,
Y., Hong, Z., Lv, N. (2014). A High QS RTSP Server’s
Architecture and Implementation Based On Android. http://www.ffmpeg.org/download.html, C. Wan and C. Chen, "Research and
Implementation of Low-Latency Streaming Media Transmission System," 2021
IEEE 21st International Conference on Communication Technology (ICCT), 2021,
pp. 787-791, doi: 10.1109/ICCT52962.2021.9657994. Esteve Brotons, M.J.,
Santiago Cabello, M.A. and García-Rodríguez, J., 2022. Live TV Streaming
Latency Measurement Using YOLO. In International Work-Conference on
the Interplay Between Natural and Artificial Computation (pp.
203-212). Springer, Cham. .
Shraddha, J. Rahul, S. Rishikesh, A. Poorvi, “DREAM: A Data Streaming
Application Using RTP/RTSP in a Local Network”, International Journal of Engineering
Science and Computing, vol. 6, issue no. 3, 2016 ZHU, S., YANG, J. and TANG, Z., 2009. Algorithm study of
proxy integration method based on RTSP controlling of streaming media
server. Journal of Computer Applications, 29(4), pp.1076-1078. Fortier, P. and Michel, H., 2022. Testbed. [online]
https://www.sciencedirect.com/topics/computer-science/testbed. Available at:
Santos-González, I., Rivero-García, A., Molina-Gil, J. and
Caballero-Gil, P., 2017. Implementation and Analysis of Real-Time Streaming
Protocols. Sensors, 17(4), p.846. Posey,
B. (2022). What is Real Time Streaming Protocol (RTSP)? - Definition from
WhatIs.com. [online] SearchVirtualDesktop. Available at: https://www.techtarget.com/searchvirtualdesktop/definition/Real-Time-Streaming-Protocol-RTSP. Raj
Kumar 2016 Available at https://docs.openrtsp.com/
[accessed 27th July 2022] Jazi,
H.H., Gonzalez, H., Stakhanova, N. and Ghorbani, A.A. (2017). Detecting
HTTP-based application layer DoS attacks on web servers in the presence of
sampling. Computer Networks, 121, pp.25–36.
doi:10.1016/j.comnet.2017.03.018. A.N.,
Prof.Dr.B., Mehta, B., Modak, T. and Chaudhary, V. (2017). Protecting Web
Servers from Distributed Denial of Service Attacks. IJARCCE, 6(3),
pp.659–662. doi:10.17148/ijarcce.2017.63154. www.wallarm.com.
(n.d.). Layer 7 DDoS Attacks: ️ Methods and Ways of Mitigation.
[online] Available at: https://www.wallarm.com/what/layer-7-ddos-attacks [Accessed
6 Sep. 2022]. Vempati, J., Dantu, R. Thompson, M., 2018.
Uninterrupted video surveillance in the face of an attack. 2018 17th IEEE
International Conference on Trust, Security And Privacy In Computing And
Communications/ 12th IEEE International Conference On Big Data Science And
Engineering (TrustCom/BigDataSE). Chibuzor
John Ugochukwu, E. O Bennett 2018. An Intrusion Detection System Using
Machine Learning Algorithm. International Journal of Computer Science and
Mathematical Theory ISSN 2545-5699 Vol. 4 No.1 2018
Glossary
RTSP:
Real-Time Streaming Protocol
SRTP: Secure Real-time Streaming
Protocol
QoE: Quality of Experience
GDPR: General Data Protection Regulation
IEEE:
Institute of electrical and electronics engineers
HTTP: Hypertext Transfer Protocol
This resource was uploaded by: Zakir