Scenario: "Saint John": what is writing to this log file?
Level: Easy
Type: Fix
Access: Public
Description: A developer created a testing program that is continuously writing to a log file /var/log/bad.log and filling up disk. You can check for example with tail -f /var/log/bad.log. This program is no longer needed. Find it and terminate it. Do not delete the log file.
Test: The log file size doesn't change (within a time interval bigger than the rate of change of the log file).
The "Check My Solution" button runs the script /home/admin/agent/check.sh, which you can see and execute.
Description: A Python app serving simulated bank data runs as root and listens on port 20280. The app is managed by supervisor and cannot be stopped or reconfigured to use a different port.
An internal legacy monitoring system expects the service to be available on port 80, but the app is hardcoded to 20280 for security and legacy reasons. Your task is to make the service accessible on port 80 locally.
Description: There is a Python WSGI web application file at /home/admin/wsgi.py , the purpose of which is to serve the string "Hello, world!". This file is served by a Gunicorn server which is fronted by an nginx server (both servers managed by systemd). So the flow of an HTTP request is: Web Client (curl) -> Nginx -> Gunicorn -> wsgi.py . The objective is to be able to curl the localhost (on default port :80) and get back "Hello, world!", using the current setup.
Test:curl -s http://localhost returns Hello, world! (serving the wsgi.py file via Gunicorn and Nginx)
Description: A developer put an important password on his webserver localhost:5000 . However, he can't find a way to recover it. This scenario is easy to to once you realize the one "trick".
Find the password and save it in /home/admin/mysolution , for example: echo "somepassword" > ~/mysolution
Description: There are two pods: "logger" and "logshipper" living in the default namespace. Unfortunately, logshipper has an issue (crashlooping) and is forbidden to see what logger is trying to say. Could you help fix Logshipper?
Do not change the K8S definition of the logshipper pod. Use "sudo".
Because k8s takes a minute or two to change the pod state initially, the check for the scenario is made to fail in the first two minutes.
Description: There is an nginx service running on port 443, it is the main web server for the company and looks like a new employee has deployed some changes to the configuration of supervisor and now it is not working as expected.
If you try to access curl -k https://bekasi it should return Hello SadServers! but for some reason it is not.
You cannot modify files from the /home/admin/bekasi folder in order to pass the check.sh
Description: (You can learn about Linux Libraries before starting this scenario).
The Linux shared library liblzma.so has been compromised (the real compromised XZ Utils liblzma has not been used). The liblzma.so at the path /usr/lib/x86_64-linux-gnu/liblzma.so.5.2.5 is the good one. Consider the same library liblzma.so.5.2.5 at other paths as compromised or malicious (ideally we would have used other real versions with different checksums).
Find all instances of this "malicious" liblzma library (remember, it's the same library but in different directory locations) and make it so none of the running processes use it, while the applications "webapp" and "jobapp" (both of which managed by systemd) still run properly (eg, stopping those applications is not a solution).
Test:lsof | grep liblzma.so.5 returns only the liblzma in the path: /usr/lib/x86_64-linux-gnu/liblzma.so.5.2.5
The "Check My Solution" button runs the script /home/admin/agent/check.sh, which you can see and execute.
Description: A developer created a script /home/admin/readdb.py that tests access to a database. Without modifying the readdb.py file, change the database so that running the script returns the string "John Karmack".
There is a web server (Caddy) on HTTP port :80 but curl http://127.0.0.1 doesn't work. Find out what's wrong and make the necessary fixes so the web server returns a URL.
Note: as a limitation, the file /home/admin/db_connector.py must not be modified so that the challenge is considered solved properly. The web server has to respond on the IP address 127.0.0.1; not only on "localhost".
Test: The command curl http://127.0.0.1 returns a URL address.
The "Check My Solution" button runs the script /home/admin/agent/check.sh, which you can see and execute.
Description: A Python web application running on port 5000 from the /opt directory is experiencing severe performance issues; every request takes more than 5 seconds to complete. The application is supposed to use the redis-server cache service for speed.
Your mission is to diagnose the performance bottleneck and restore the application to its normal, fast response time.
Do not change the Python application file slow_app.py.
Test:curl localhost:5000 returns Data from FAST cache!
The "Check My Solution" button runs the script /home/admin/agent/check.sh, which you can see and execute.
"Singara": Docker and Kubernetes web app not working.
Scenario: "Singara": Docker and Kubernetes web app not working.
Level: Hard
Type: Fix
Access: Email
Description: There's a k3s Kubernetes install you can access with kubectl. The Kubernetes YAML manifests under /home/admin have been applied. The objective is to access from the host the "webapp" web server deployed and find what message it serves (it's a name of a town or city btw). In order to pass the check, the webapp Docker container should not be run separately outside Kubernetes as a shortcut.
Test:curl localhost:8888 returns a value from the webapp deployed Kubernetes pod.
Description: There is a RabbitMQ (RMQ) cluster defined in a docker-compose.yml file.
Bring this system up and then run the producer.py script in such a way that is able to send messages to RMQ. In particular you have to send the message "hello-lwc".
- RMQ is a queuing system: messages are put in the queue with a "producer" and they are taken out from the other side by a "consumer". The queue name has to be the same for both.
- To send the message "hello-lwc": python3 ~/producer.py hello-lwc. Should return Message sent to RabbitMQ. "IncompatibleProtocolError" means RMQ is not working properly.
- To test consuming it: python3 ~/consumer.py, this will retrieve the next message from the queue and print it. Once everything is working send more than one message so there's at least one in the queue when the validation runs.
- Do not change the consumer.py and producer.py files; if you do the Check My Solution will fail.
Test:python3 ~/consumer.py returns hello-lwc
See /home/admin/agent/check.sh for the exact test.
Description: There is a web server on :5000 with a form. POSTing the correct form password into this web service will return a secret.
Save this secret provided by the web page (not the password you sent to it) to /home/admin/mysolution, for example: echo "SecretFromWebSite" > ~/mysolution
TIP: a developer worked on the web server code in this VM, using the same 'admin' account.
