The bakery that told strangers too much
A bakery puts its website online. Nobody breaks in. But anyone can see which software it runs, read a backup file and list a folder of supplier names.
The settings were the ones the software came with. Safe defaults are the first job of anyone who ships a server.
By the end of this lesson
Note
I can review a web server's settings against a checklist.
Key words
| Word | What it means | Example |
|---|---|---|
| Hardening | changing settings so a system gives away and allows less | |
| Header | a line of facts that travels with a web reply | |
| Status code | the number that says how a request went | 404 |
| Default | the setting used when nobody chose one | |
| Attack surface | everything that a stranger can reach | |
| Reload | make a server read its settings again, without stopping |
The cells students fill in are left blank in this preview.
A server answers with more than a page
Every reply from a web server carries a status code and some headers. The code says how it went: 200 worked, 404 not found, 405 method not allowed.
Headers can say too much. Each fact a stranger learns makes your attack surface a little bigger.
Your lab has a bakery's web server called web. These three Runs only look at what it says.
Read the headers of a reply
curl -s -I http://webShown here, not run. Create a free account to press Run and type it into your own lab’s terminal.
Ask for a page that is not there
curl -s -o /dev/null -w "%{http_code}\n" http://web/nothing-hereShown here, not run. Create a free account to press Run and type it into your own lab’s terminal.
Try a method a static site refuses
curl -s -o /dev/null -w "%{http_code}\n" -X DELETE http://web/Shown here, not run. Create a free account to press Run and type it into your own lab’s terminal.
A review compares settings with a checklist
To harden a server, read its settings line by line and ask the same questions each time. Does it say too much? Does it allow too much? Does it keep a record?
A default is written to make a server easy to start, not safe to leave. The table lists some common risks.
Worked example: a review checklist
| Setting | Risk | Safer choice |
|---|---|---|
| Old protocol versions | Known weaknesses can be used | Allow only the newer ones |
| No limit on upload size | One user fills the disk | Set a limit that fits |
| Logging switched off | Nobody can see what happened | Keep the logs |
| Any site may call the API | Other sites read your data | Name the sites allowed |
The cells students fill in are left blank in this preview.
A shop's settings to review
server {
listen 443 ssl;
server_name books.example.com;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
client_max_body_size 0;
access_log off;
add_header Access-Control-Allow-Origin *;
location / {
proxy_pass http://127.0.0.1:3000;
}
}A common mistake
Warning
Many people think hiding the version number makes a server secure. It only hides one clue. A stranger can still try every known fault. Hide the clue and also keep the software up to date and remove what should not be there.
Test a change, then reload
nginx refuses a reload with a bad file and keeps its old settings, but a restart fails. So you test the file first. nginx has a test that reads the settings and says whether they are valid.
Only then do you reload, which makes the running server read the new settings without dropping a visitor.
A check script turns each rule of the checklist into a pass or a fail, so a machine can repeat the review. The lab has one, and it is yours to use after the lesson.
Test the settings, change nothing
docker exec web nginx -tShown here, not run. Create a free account to press Run and type it into your own lab’s terminal.
Ask which version is running
docker exec web nginx -vShown here, not run. Create a free account to press Run and type it into your own lab’s terminal.
Going further
Add a seventh rule to your lint_config after the assignment: client_max_body_size with a size above 100m is big-upload-limit. Sizes end in k or m.
Write two tests of your own, one for client_max_body_size 500m; and one for client_max_body_size 2m;, and check that only the first gives a finding.