3484 IJSTR©2020
www.ijstr.org
Web Forensic On Kubernetes Cluster Services
Using Grr Rapid Response Framework
Imam Riadi, Rusydi Umar, Andi Sugandi
Abstract: Deploying and scaling containerized applications in Kubernetes cluster services are growing more popular in today's Continuous Integration / Continuous Deployment (CI/CD) software engineering. They not only need to be secured from malicious activities but also have to be handled properly especially when Internet attacks happen. This attacks could bring harm and losses lots of money and efforts funded by corporations. Fortunately, Internet attacks such DDoS usually leaves traces in the form of log files, those will give practitioners valuable information to identify and analyse. This paper discusses the investigation using Grr Rapid Response framework on containerized web applications that are running inside Kubernetes cluster. This paper simulates DDoS attacks (executed on Windows computer) by sending hundreds of request packets to containerized web applications inside cluster services (Kubernetes cluster is running on Ubuntu Linux operating system), henceforth Grr Rapid Response framework is used to investigate the accident. This research has successfully acquired log files from web server inside Kubernetes cluster, and network status in Windows computer as important digital evidence.
Index Terms: Forensics, Network, Kubernetes, Cluster, Grr Rapid Response, Web.
—————————— ◆ ——————————
1.
INTRODUCTION
Deploying microservices will gain maximum benefits if they are implemented through containers technology such as provided by Docker and scaled automatically by Kubernetes cluster service[1], so failing single part (micro-service) will not put the whole applications down. The management of containers and their scaling features are administered by Kubernetes cluster services. Currently, Kubernetes is leading cluster services since 2017. At least, the deployments have increased 85% until October 2018[2] by Google GCP as shown in Fig. 1.
While Kubernetes is growing popular by now, cybercrime over the Internet still happen to containerized web applications that are running inside cluster services[3]. Those attacks on the Internet include Teardrop, TCP SYN flood, smurf, IP spoofing, session hijacking, UDP Flood, Flood ping, and DDoS[4]. DDoS attack causes containerized web applications cannot be accessed by customers. This is because of cyber-attacks that interferes network or services that operating system deliver, such as databases, web server[5], and the application itself.
Resulting part of (or even the whole) computer resources to be temporarily or permanently unavailable. When those DDoS attacks happen, they should be responded by appropriate tools so practitioners or incident response team are able to investigate it properly. Grr Rapid Response (GRR) framework is a comprehensive tool to provide practitioner a complete and reliable incident response investigation and analysis of Internet attack (such as DDoS), in live[6] and remote[7] mechanism. It is completely different like it[8] usually does on mobile devices to investigate and analyse digital evidence on WhatsApp application. GRR framework has two main parts: client and server. GRR client (agent program that is running on the attacked computer) is installed and deployed on a victim computer, later this computer will be investigated and analysis by activating a polling of GRR Frontend Server to works, then ask GRR Server what tasks should be done afterward. The tasks are such searching web server log files, and downloading them, or reading status of network interfaces. The second part is GRR server[9] that manages other components (GRR Frontend, GRR Workers, and GRR AdminUI, Flow, and Hunt) so investigation process will take place in a secure and proper manner.
The reasons why choosing GRR framework are the complete and reliable features provided when investigating digital evidence of web server (running inside cluster services), with quick responses and remotely through computer networks.
Digital forensics activities involved in this research begins by installing GRR server on a Linux server. It then produces three types of GRR client programs afterward (for Linux, Windows, and Mac OS version). Then, GRR client program for Linux
• Imam Riadi is a lecturer at Department of Information System,
Universitas Ahmad Dahlan, Yogyakarta, Indonesia. E-mail: [email protected]
• Rusydi Umar is a lecturer at Department of Informatics, Universitas Ahmad Dahlan, Yogyakarta, Indonesia. E-mail: [email protected]
• Andi Sugandi is currently pursuing a master degree program
in Department of Informatics, Universitas Ahmad Dahlan,
Yogyakarta, Indonesia. E-mail:
3485
(DEB or RPM) is installed on a Node Worker that runs containerized web application inside cluster services. This web application and its TCP port (31065) are exposed to the public network. Another GRR client program (for Windows version) then installed on Windows computer acts as both another GRR client and an attacker running DDoS script.
Web Server (port: 31605) in Node Worker will be attacked by Windows computer using DDoS technique. After practitioners know the attack, they will activate GRR Server to send GRR Tasks through two different Flows[9], and send it to each GRR clients to start investigating the evidence. One Flow to search for web server log files on Node Worker (Linux) file system, and another Flow to retrieve network status on Windows computer (using Netstat tool), in order to obtain origin identity of the attacker and the timestamps of the accident. The resulted investigations on each client are then sent to GRR server to analysis and review.
2
LITERATURE
REVIEW
2.1 Grr Rapid Response Researches
Today's researches related to Grr Rapid Response framework are the following. The research in [10] discussed the triage of investigating digital evidence at the enterprise environment using GRR framework. In [11] proposed scalable storage on GRR framework. The research in [12] is discussing network forensics on gaining digital evidence by using GRR framework in the healthcare setting and organizations in general.
2.2 Network Architecture
This research is using network architecture shown in Fig. 2.
Fig. 2 consists of a single GRR server, three GRR clients: first GRR client on Windows computer (attacker), the last two GRR clients (Ubuntu computer) are: one act as victim (uad-worker) and another one as a Node Master of Kubernetes cluster service, that manages containerized web applications.
3 METHODS
This research uses the National Institute of Standards and Technology (NIST)[13] as a forensic method, consisting of forensic stages: acquisition, examination, utilization, and review, as illustrated in Fig. 3.
3.1 Acquisitions
At the beginning of the research, we start by identifying data sources. This includes activity in identifying and collecting data that need to be investigated. Table 1 and Table 2 are (respectively) hardware and software specifications used in this reseach.
Table 3 show pairs of hostname and IP address that will be
TABLE1
HARDWARE INFORMATION
TABLE2
SOFTWARE INFORMATION
Fig. 2. Netwok architecture overview, consisting of GRR server, GRR clients, and Kubernetes clusters service.
3486 IJSTR©2020
www.ijstr.org
used to communicate among the member of the network.
3.2 Examination
When data that is coming from GRR Client is retrieved, the following step is examining it. This includes identifying, collecting, and organizing the relevant information expected from the data received in GRR Server.
3.3 Utilization
Utilization step is about the process required to prepare and present information after the examination step finished. The GRR framework way that relates to this utilization process is provided by the implementation[9] of GRR Flows.
3.4 Review
Reviewing steps are including the processes to identify policy, procedural errors, and other issues that may need to be remedied and evaluated.
4 RESULT
AND
DISCUSSION
There are criteria of the analyzed parameters regarding of results and analysis processes that has been done. Those are used to clarify what the expected results from data that has
been collected, as seen in Table 4.
Digital forensics activities in this research are using the following steps (based on NIST method) to indentified digital evidence (in the form of log files) produced by a web server that is running inside Kubernetes cluster services.
4.1 Acquisitions
There are preparations that have to be done first before starting acquisition processes, based on the scenario illustrated previously in Fig. 2. These preparations are:
1. All main components of GRR server (Worker, AdminUI,
and FrontEnd) are already running on the server computer.
2. All GRR client programs are already running on each particular computers.
3. Initiate Kubernetes cluster[14] and Flannel on Node Master, and join Node Worker to the cluster.
4. Run containerized web applications[15] inside Kubernetes cluster services by using Kubernetes kubeadm[16] command to create deployments and services.
5. Run DDoS script on Windows computer (attacker), give the parameters: destination IP address of victim computer (192.168.100.19) and the port number (31065).
6. Run investigation processes on GRR Server WebUI.
The acquisition step is to run the GRR program in each particular hosts. Make it sure by accessing the front page of the GRR Server WebUI as illustrated in Fig. 4 and Fig. 5.
TABLE3
HOSTNAME AND IPADDRESS
TABLE4
PARAMETERS FOR ANALYSIS PROCESS
Fig.4. Hostnames detected by in GRR AdminUI: uad (Node Master) and uad-worker (Node Worker)
3487
4.1.1 Acquisition on Node Worker
In the acquisition in Node worker, we must provide ArtifactCollectorFlow: dockerlogs.yml[17] so GRR Flow can retrieve Docker Logs inside Kubernetes cluster services. After we finishing the process of acquisition Node Worker, the next step is to collect other digital evidence from the view of the attacker (Windows 10).
4.1.2 Acquisition on Windows
To prove that the attacker was coming from this Windows 10 computer, we can use Netstat of GRR Flow Artifact to collect valuable network information of the interface card on the particular computer.
4.2 Examination
In this examine step, we begin the examination process on all GRR clients.
4.2.1 Examination on Node Worker
Examination process on Node Worker begins by choosing which data is related to DDoS that attacks web server inside Kubernetes cluster services.
4.2.2 Examination on Windows
In the Manage launched Flows menu, we can examine network information on the computer that runs DDoS script. After this, we begin to utilize the examined data in the following steps.
4.3 Utilization
GRR Server provides an easy interface through GRR WebUI. This will help the practitioner to get appropriate information from all GRR clients: Node Worker, and Windows 10.
4.3.1 Utilization on Windows
We have to elaborate data examined from the next step and utilize it with the information shown in Fig. 6.
This elaboration should be taken to make sure that the origin identity of the attacker was coming from Windows 10 (192.168.100.10). In Fig. 4, it tells that the origin identity of the attacker was coming from IP address 192.168.100.10, as we expected.
4.3.2 Utilization on Node Worker
Kubernetes Logs[18] has the ability to read the system log (output and error log) inside a log file on the host file system through the inner working of Docker Logs[19], and it is implementing the utilization process in this research. In Fig. 7, we can successfully collect and display the digital evidence inside log files that were coming from Docker Logs on GRR client (Node Worker).
Unfortunately, the source IP address information in the log file (shown in Fig. 7) doesn’t match with IP address retrieved from the utilization results in Windows computer (Netstat Flow Message). The source IP address is as if not coming from the origin computer, it should 192.168.100.10 (IP address attacker), but it is 10.244.1.1. In networking feature inside Kubernetes cluster, 10.244.1.1 is known as a Flunnel[20] router IP address (bridged network interface in Kubernetes Node) that is used to communicate between Pods (10.244.1.x) inside Kubernetes Nodes. Web request coming from client outside Pods (Windows IP address: 192.168.100.10) to containerized web apps in Kubernetes Pod (destinated Kubernetes Node: 192.168.100.19) will be forwarded by Flannel router (10.244.1.1) and send it to the real destination (10.244.1.4). Because of ServiceType chosen in this research is NodePort, so packets sent to Kubernetes Node will be modified, the source IP in packet will change to Flunnel router IP address, not from originated address (Source NAT)[21]. So the source IP seen in the target Kubernetes Pod will not be the original source IP of the client.
Fig.7. Utilization result of LinuxDockerFiles Response Message.
3488 IJSTR©2020
www.ijstr.org
4.4 Review
From the investigation results in this research, IP addresses (source and destination), port numbers, and timestamps are successfully received by GRR framework to determine digital evidence coming from web server log[22] files (reviewed in Table 5) in computer victim (Node Worker) and Netstat in computer attacker (Windows 10, as reviewed in Table 6).
5
CONCLUSION
The investigation processes in this paper build conclusion that GRR framework has successfully achieved the digital evidence in log files (consists of IP addresses, port number, and timestamps) from containerized web applications running inside Kubernetes cluster, and network status from Windows computer.
REFERENCES
[1] Hasselbring, Wilhelm, and Guido Steinacker. "Microservice architectures for scalability, agility, and reliability in e-commerce." 2017 IEEE International Conference on Software Architecture Workshops (ICSAW). IEEE, 2017.
[2] Datadog. “8 emerging trends in container orchestration”, https://www.datadoghq.com/container-orchestration, 2019.
[3] Modak, Arsh, et al. "Techniques to Secure Data on Cloud: Docker Swarm or Kubernetes?." 2018 Second International Conference on Inventive Communication and Computational Technologies (ICICCT). IEEE, 2018. [4] Fadlil, Abdul, Imam Riadi, and Sukma Aji. "Review of
detection DDOS attack detection using naive bayes classifier for network forensics." Bulletin of Electrical Engineering and Informatics 6.2 (2017): 140-148.
[5] Mualfah, Desti, and Imam Riadi. "Network Forensics For Detecting Flooding Attack On Web Server." International
Journal of Computer Science and Information Security 15.2 (2017): 326.
[6] Rusydi Umar, Anton Yudhana, and Muhammad Nur Faiz. "Experimental analysis of web browser sessions using live forensics method." International Journal of Electrical and Computer Engineering (IJECE) 8.5 (2018): 2951-2958. [7] Mazdadi, Muhammad Itqan, I. Riadi, and A. Luthfi. "Live
Forensics on RouterOS using API Services to Investigate Network Attacks." International Journal of Computer Science and Information Security (IJCSIS) 15.2 (2017). [8] Umar, Rusydi, Imam Riadi, and Guntur Maulana Zamroni.
"A Comparative Study of Forensic Tools for WhatsApp Analysis using NIST Measurements." Int. J. Adv. Comput. Sci. Appl 8.12 (2017): 69-75.
[9] Cohen, Michael I., Darren Bilby, and Germano Caronni. "Distributed forensics and incident response in the enterprise." digital investigation 8 (2011): S101-S110. [10]Moser, Andreas, and Michael I. Cohen. "Hunting in the
enterprise: Forensic triage and incident response." Digital Investigation 10.2 (2013): 89-98.
[11]Cruz, Flavio, Andreas Moser, and Michael Cohen. "A scalable file based data store for forensic analysis." Digital Investigation 12 (2015): S90-S101.
[12]Acharya, Subrata, William Glenn, and Matthew Carr. "A GRReat framework for incident response in healthcare." 2015 IEEE International Conference on Bioinformatics and Biomedicine (BIBM). IEEE, 2015.
[13]Grance, Tim, and Suzanne Chevalier. Guide to Computer and Network Data Analysis: Applying Forensic Techniques to Incident Response: Draft. US Department of Commerce, Technology Administration, National Institute of Standards and Technology, 2005.
[14]Delnat, Wito, et al. "K8-Scalar: a workbench to compare autoscalers for container-orchestrated services (Artifact)." Schloss Dagstuhl-Leibniz-Zentrum fuer Informatik, 2018. [15]Cloud Native Computing Foundation, "Translate a Docker
Compose File to Kubernetes Resources",
https://kubernetes.io/docs/tasks/configure-pod-container/translate-compose-kubernetes, 2019.
[16]Shah, Jay, and Dushyant Dubaria. "Building Modern Clouds: Using Docker, Kubernetes & Google Cloud Platform." 2019 IEEE 9th Annual Computing and Communication Workshop and Conference (CCWC). IEEE, 2019.
[17]Sunardi, Imam Riadi and Andi Sugandi. “Forensic Analysis of Docker Swarm Cluster using Grr Rapid Response Framework.” International Journal of Advanced Computer Science and Applications(IJACSA), 10(2). 2019.
[18]Cloud Native Computing Foundation. "Logging Architecture",
https://kubernetes.io/docs/concepts/cluster-administration/logging , 2019.
[19]Docker Inc., “View logs for a container or service.”, https://docs.docker.com/config/containers/logging, 2017. [20]Red Hat, Inc., "Flannel is a network fabric for containers,
designed for Kubernetes", https://github.com/coreos/flannel, 2019.
[21]Cloud Native Computing Foundation, "Source IP for Services
with Type=NodePort",
https://kubernetes.io/docs/tutorials/services/source-ip/#source-ip-for-services-with-type-nodeport, 2019.
[22]Gao, Yang, Yan Ma, and Dandan Li. "Anomaly detection of malicious users' behaviors for web applications based on web logs." 2017 IEEE 17th International Conference on Communication Technology (ICCT). IEEE, 2017.
TABLE5
REVIEWING THE INVESTIGATION RESULT OF WEB LOG FILES
TABLE6
