Lab catalog
found 7 of 777 of 77loading…
Loading…
-
Too much is visible from the network The warehouse server runs a site, a database and an admin panel, and only the site and SSH should be visible from the network. Find what else is open to the outside and close it so that everything still works on the server itself, after a reboot too.~35 min not started
-
After the update A colleague installed security updates and the packages are new, yet the scanner still flags the server as vulnerable. Find the services running old code and restart only those.~25 min not started
-
A password can be anything Interns change their own passwords and the system accepts any of them, while guessing a password can go on forever. Introduce a password policy and a lockout after failed attempts without losing your own key login and sudo.~30 min not started
-
The brute force goes on Someone on the neighbouring machine keeps trying to log in to the server's SSH. fail2ban is installed and running, a colleague has even tuned it, and still there is no ban. Find out why and make sure the attacker gets banned and the administrator never does.~30 min not started
-
The service can do anything The helpdesk ticket service runs as root without a single restriction — that has to change before the security review. Restrict it with systemd so that it keeps taking and storing tickets.~25 min not started
-
The service is denied access The knowledge base moved to a new disk, and the service no longer sees the articles — even though the permissions are fine and the service user reads them directly. Find what denies the access and give it back to the service without weakening its protection.~20 min not started
-
The config changes by itself The portal settings keep reverting to someone else's, even though they were just fixed. Put an audit rule on the file, find from the events who rewrites it and with what, and stop it without touching anyone else.~20 min not started
No lab on the topic you need? Suggest a lab