← All challenges
mediumsecurity~50 min

Lock down the server subnet without locking yourself out

Write an ACL that enforces a precise access policy, in the right place and direction, respecting the implicit deny.

Scenario

Security wants the server subnet locked down. Today the router routes between the LAN and the server subnet with no filter, so every host reaches the server on every port. Enforce this policy:

  • Any host on the LAN may reach server 10.0.2.10 on TCP 80 (web).
  • Only the admin host (10.0.1.20) may reach the server on TCP 22 (SSH).
  • Every other host is denied SSH to the server.
  • Nothing else on the network should break.

Topology

  • LAN 10.0.1.0/24: the user host 10.0.1.10 and the admin host 10.0.1.20
  • Server subnet 10.0.2.0/24: server 10.0.2.10, listening on 80, 443, and 22
  • The router routes between the two subnets; everything is reachable with no filter yet.

Your job

Write the extended ACL, apply it on the right interface and direction, and get the ordering right so the policy holds and you neither lock out the admin nor break unrelated traffic.

What "done" looks like

A user host reaches the server on TCP 80, SSH to the server is denied from ordinary users but still works from the admin host, and nothing else breaks.

Teaches: ACL ordering, direction, the implicit deny, and the classic "don't lock yourself out" lesson.

Tooling

Arista cEOS (native ACL syntax matches what learners study). Free fallback: nftables on a Linux router. Validate syntax on first deploy.

What gets checked

Your solution is verified against each of these:

  • A user host can reach the server (10.0.2.10) on TCP 80
  • A user host is denied other access to the server subnet (e.g. TCP 22)
  • The admin host retains access to the server

Solve it in the browser lab

No setup, no install. Open a live lab: configure each device in the editor or its Cisco IOS terminal, run show/ping/traceroute (or test from the hosts), and watch the network react. The in-house engine grades your fix instantly and issues your proof the moment every check passes.

Open the lab →

Prefer your own lab?

  1. Build the fix locally. New to the tooling? See setting up your lab.
  2. Push your topology file, device configs, and any playbooks to a public repo (GitHub or GitLab).
  3. Submit the repo link. We review it by hand, confirm it works, and issue your proof page.
Submit your solution →