· about 30 minutes · runs on ubuntu-26.04-automation · unrated
An unrated lab. It runs on your machine with no account and no network, and everything about it — the faults, the checks, the hints and the reference solution — is in the repository. An attempt on it is recorded on your profile and never moves a rating: only rated labs do. Rated and unrated labs.
This machine runs Ollama with qwen2.5:0.5b for the team's internal chat page,
https://chat.internal.example. To make the page work, someone set Ollama to listen on every
address and to accept requests from any web origin. nginx on port 8080 was meant to be the way in.
The monthly network scan found port 11434 answering anyone on the office network: it lists the models, runs them, and would pull new ones on request. Ollama has no passwords of its own.
The team's account for the proxy is team; its password is in /root/team-password.
What is expected, and graded:
http://127.0.0.1:8080/ asks for a password: no credentials, or wrong ones, get 401; team with
the right password gets the model list.https://chat.internal.example,
coming through the proxy with the password, can.You have root through sudo. Everything must still hold after a reboot.
The machine is checked, rebooted, and checked again. A check passes only if it passes both times.
| Check | Objective |
|---|---|
| 01_ollama_listens_only_on_loopback | Keep an unauthenticated model server off the network |
| 02_the_proxy_asks_for_the_team_password | Put a password in front of it for the people who should use it |
| 03_only_the_chat_page_may_call_from_a_browser | Allow exactly the web page that needs it to call it from a browser |
Where the lab's hints send you, level by level, as you ask for them (h, then l opens a journal section in the TUI).
4 questions on the same topic, in the lab's Theory tab. They never affect the lab's grade. Three of them, to answer here:
What does Ollama do to check who is calling its API?
Nothing: it has no authentication, so whoever reaches the port can list, run, pull and delete models
The key in ~/.ollama identifies the server to ollama.com; it does not authenticate clients. Access control belongs to the network (bind to 127.0.0.1) and to a proxy in front, which can require a password or token.
https://github.com/ollama/ollama/blob/main/docs/faq.mdx
ollama.service sets OLLAMA_HOST=127.0.0.1:11434, yet ss shows Ollama on *:11434. Where is the other value most likely set, and how do you see it?
In a drop-in under /etc/systemd/system/ollama.service.d/; systemctl cat ollama shows the unit and every drop-in
Drop-ins are applied after the unit file, so a later Environment= for the same variable wins. systemctl cat prints the unit followed by each drop-in with its path; systemctl show -p Environment shows the result. Services do not read /etc/environment or shell startup files.
man 5 systemd.unit (drop-in directories) · man 1 systemctl
A browser page at https://chat.internal.example calls Ollama through nginx and gets 403, while curl without an Origin header gets 200. What is refusing it?
Ollama: nginx forwards the browser's Origin header, and Ollama accepts only its own local origins plus OLLAMA_ORIGINS
Ollama checks the Origin header and answers 403 to origins it does not allow; curl sends none. nginx passes client headers on unchanged. Add the page's origin to OLLAMA_ORIGINS (never *), or have the proxy handle cross-origin requests itself. Missing credentials would be 401.
https://github.com/ollama/ollama/blob/main/docs/faq.mdx · https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/CORS