Rules of a Wargame

• Rules of a Wargame
  • general
  • condensed
  • cycle tasks
  • compromise
  • team leads
  • game timeline
    • pre-game
    • game start (~7 days)
    • game cycle (up to 1 week)
    • post-game
  • an example game
  • misc stuff

general

The purpose of this game is to gain experience in securing servers by setting up and protecting services from real attackers and compromising servers by attacking the services set up by your attackers. Also, fun is involved.

condensed

The game boils down to this:

• There are teams and each team has a server
• From time to time all teams must install some services
• All teams try to compromise other teams' servers
• Once all boxes are owned by one team, game is over

cycle tasks

1. The game consists of a series of "cycles".
2. Each game cycle begins with all teams coming up with a "cycle task". Examples of a cycle tasks could be:
   • Set up a public SSH server with possible gcc usage (hard)
   • Set up anonymous FTP with uploads enabled (medium)
   • Allow users register to upload (PHP?) homepages (hard)
   • Run some obscure old service (medium)
   • Run a web server with forum software (easy)
   • Run a custom service of team's choice (depends)
3. You should choose a task that you can implement securely but the other teams might implement insecurely.
4. All game tasks must be fulfilled by all teams during the game cycle.
5. All game tasks (unless specified otherwise) must be set up so that the other teams have access to the service.
6. All game tasks must be running with reasonable responsiveness and stability.
7. The complexity of the cycle task should be enough to keep the teams busy for a couple of days but should not require effort longer than a week.
8. The tasks for the first cycle(s) should be easier, so that they could be implemented in a couple of days.

compromise

1. When you compromise another machine you are allowed lock it down (kill services, firewall it, etc) for a maximum of 12h.
2. During this time you can secure the box as much as you wish.
3. After those 12h hours have passed, you have to put the box online again with the all the services that were required to run on it running.
4. You must announce when you are ready to the game host, who will start the clock of 24h that you have to keep the services running.
5. After 24h have passed without anyone owning the box back, the box will be taken out of the game.

team leads

1. Each team has a leader.
2. The team leaders are responsible for team's communication. They have to ensure that:
   1. communication channels are set up (mailing list, irc, wiki - as required)
   2. strategy is discussed, planning takes place (ideas, tasks)
   3. all team members know what they should do (roles, tasks, progress)
   4. all team members are aware of game progress (updates to team)
   5. all team members are having fun
   6. Most importantly: keep the game moving and the whole team working.
3. Are responsible for communication with the game host.
4. Team leads can request changes in infrastructure/admin part of the game (port forwards, machine setups).
5. Get to boss other people around and claim all the credit :).

game timeline

pre-game

1. Game is announced.
2. Players register for game.
3. Target number of players reached, registration closed.
4. All players are contacted and asked their possible team preferences and willingness to play.
5. Team leads are selected and contacted by host, teams assigned, communications set up.

game start (~7 days)

1. A real-time meeting should be organized at before the beginning (on IRC for example) - to agree on plans, roles, strategies. Further meeting times should be agreed upon.
2. Some useful pointers to focus on:
   • Attacking - who, how (cycle tasks)
   • Hardening - who, against what
   • Service setup - who, who else
   • Regular status updates - from players, from team lead
3. A forum or wiki to keep track of ideas, configurations, tasks, players, roles and so on is highly recommended.
4. Team leads submit a task for the first game cycle to the game host. The first task should be easy.
5. For the game start time, no agression can take place.
6. There has to be sufficient evidence to support any case of agression. A penalty will be given to offending team if agression is reasonably proven.
7. Teams are given their root passwords (and ssh ports, IP) for their machines at the same time on team mailing list.
8. At this point everyone may log in, start preparing for the first game cycle.

game cycle (up to 1 week)

1. The length of the cycle is decided and announced to teams on the mailinglist with the list of tasks for the cycle.
2. All teams fulfill the cycle tasks while exploiting other teams.
3. Based on the progress during the cycle teams select new tasks to further advance their attacks.
4. Team leads announce they have finished the tasks to game host.
5. Team leads submit tasks for the next game cycle during 24h.
6. A new cycle starts.

post-game

1. When all the the machines are owned by a single team the game ends.
2. All team leads must submit a timeline/overview/documentation of the game. The purpose of this is to amuse/educate future players or watchers (the documents will get posted on the game site). The report should contain the following:
   • how the game started, how the communication was set up
   • how the box was secured
   • what plans did you have for offence
   • for each cycle: which tasks you proposed and why, how you implemented the tasks, how you attacked, how you defended
   • for each time you compromised a box: how you did it, how they could have prevented it
   • for each time you got compromised: why and how did it happen, what could have been done to prevent it
   • comments/opinions/stuff learned

an example game

For an illustrative example, let's imagine there are 2 teams: "tacos" and "nachos". The game may unfold a bit like this:

1. All players get an email with the details of the game
2. The players introduce themselves (and their abilities, ideas) on the team mailing list and possibly get together on IRC for a meeting
3. The players log on to their respective team boxes - taco and nacho - and secure them
4. First cycle:
   1. For first task, tacos propose "an httpd server"
   2. Nachos propose "an ftpd server"
   3. Tasks are accepted by game host and announced as official tasks for the cycle
   4. Both nachos and tacos install an httpd server and an ftpd server. With their sshd, they both have 3 services running.
   5. Neither team is able to compromise the other team's box
   6. First cycle complete, new cycle tasks requested by game host.
5. Second cycle:
   1. Tacos propose that the ftpd server must accept anonymous uploads/downloads.
   2. Nachos propose a forum running on the httpd.
   3. Tasks accepted, announced.
   4. Both teams reconfigure their ftpd and install a fourm on their httpd.
   5. Neither team is able to compromise the other team's box, but Nachos get php shell running on Tacos' webserver.
   6. Second cycle complete, new tasks requested.
6. Third cycle:
   1. Tacos propose "a service to view manpages connecting to TCP port 1000. It must include the ability to scroll and search through a manpage and request different manpages during one session."
   2. Nachos propose "an automatic online ability to register specific users for the ftpd, that have their own private directory".
   3. Tasks accepted, announced, implemented.
   4. Tacos almost get into Nachos box through their insecure man pager. However, Nachos are able to misuse the user creation script with their webserver privileges and overwrite the password of one Tacos' players. They get root by using sudo and own Tacos.
7. Compromise mode
   1. Nachos kick Tacos off their box and secure it for 12h
   2. Nachos put all services back online for 24h
   3. Tacos are unable to get their box back
8. Game over
9. All teams submit their detailed and interesting game reports

misc stuff

General points and rules of conduct

1. Don't pester machines that are not part of the game.
2. Don't do heavy computing on the machines (compiling kernel, apache, etc - the machines are virtual).
3. It is NOT forbidden to use some amount of intelligent DOS as long as it does not affect the whole setup badly.
4. You are not allowed to run full virtualization (xen/qemu/vmware) on your (already virtual) boxes. OS-level partitioning systems (chroots/jails/etc) are allowed.
5. In the beginning of the game, only http connections are allowed from team boxes towards the Internet. This limitation can be lifted upon request (to enable mail reports, ftp downloads, etc).
6. Access to the machine's serial console (and reset button) is available upon request. This access is not to be used to avoid the game LAN.
7. A mailing list is provided for all teams at the beginning of the game. It should allow communication despite of likely time zone/free time availabilty differences between the team members.
8. Be sure that your email address accepts mail from p6drad-teel.net as you will not receive the game announcement otherwise.
9. The game server is located in eastern europe ATM. Try pinging p6drad-teel.net for an idea of what you'll be connecting.
10. Setting up/securing/researching/exploiting services takes time and effort. When you register, be prepared for a game that will go on for weeks.
11. These rules are a work in progress. If you have ideas how to make the game more interesting/playable - speak out!