Locked Shields 2024

Objective / Target audience #

This post is aimed in particular at cybersecurity students at ENSIBS who are likely to be working on the Locked Shields event again.

I’ll try to retrace the various stages chronologically, whether on the school side or on the NATO side, while giving my point of view on the events in order to give future students a clearer idea and advise them as best I can.

I’ll be concentrating mainly on the organizational description and relatively little on the technical side, for the simple reason that I’m not authorized to share a lot of information (certain equipment, scenarios or vulnerabilities are reused every year for the exercise).

Of course, this post isn’t just for ENSIBS students, anyone curious about what goes on behind the scenes is welcome to read on.

Introduction #

In the final year of cyber defense engineering studies at ENSIBS, all students are required to complete a project on the theme of their choice for approximately 5 months.

Some choose to carry out a research project, others to develop a solution, it’s not surprising to see projects turn into start-ups after graduation and to be honest that was one of my ideas too.

I wanted to be part of a project that was more significant than the university field, but to do that you first have to choose a project.

2 possible solutions:

• Propose a subject yourself and have it validated by teachers (the subject must necessarily be related to cybersecurity).
• Choose a project from the list proposed by the teachers, an extract of which is shown below (in french):

It was while we were sharing this list that some teachers announced a partnership between the ENSIBS and the University of Tallinn (Estonia). We were told that one group would have the chance to take part in the organization of Locked Shields this year, and that to get this place you’d have to be motivated!

What’s Locked Shields? #

Considered the world’s largest cyber security exercise, Locked Shields is organized every year by the NATO Cooperative Cyber Defence Centre of Excellence (CCDCOE) and the University of Tallinn to train NATO teams.

The exercise pits Blue Teams against Red Teams. The Red Teams play the role of attackers, their objective being to compromise the infrastructures of the Blue Teams. The Blue Teams’ mission is to defend the computer systems in real time of a fictitious country simulated by over 5000 systems. The name of this country: “Berylia”.

The aim of the exercise is to strengthen ties between NATO member countries and train them in the event of coordinated cyberattacks.

Not surprising, given that the CCDCOE was created in the wake of a Russian cyberattack against Estonia in 2007: Le Monde

The (dream) team #

Before you can even select a project, you have to put together a team of 4 to 5 people!

As it turned out, I quickly found some motivated comrades to join me in this project. After some discussion, we now had a team:

• Tanguy Pascal
• Benjamin Guillouzo (BenJ)
• Benjamin Reichling (Ben)
• Me 😎

Several teams were also interested in Locked Shields, so the teachers asked us to choose a 2nd project in case we weren’t selected.

We thought the teachers would give us a short motivational interview, and we were ready.

But in the end, no motivational interview took place, and I don’t think that was in the teachers’ plans. Rather, their goal was to wait for us to sort things out between students, so they set a deadline.

Our strategy was simple: not to propose any backup solution and bury our heads in the sand to force the choice of our team.

Well, believe it or not, all the other teams proposed a 2nd project and ended up going for this one.

Effective strategy → we recommend it.

We were now officially selected to take part in the Locked Shields organization (thanks to talent)!

Practical information #

Plannings #

All projects are subject to a schedule decided by the school, which is divided into milestones (“jalon” in french). At the end of each milestone, we have to make a presentation of our progress to the teachers and hand over our source code.

Not surprising for a university project, but what’s special about this project is that in addition to the school schedule, we also have to respect the NATO schedule.

Here’s what the schedules look like, roughly speaking:

Things to remember about these schedules:

• There is only one information meeting on the NATO side, after which any questions or requests must be addressed directly to the contacts.
  • These contacts don’t respond very quickly → requests/questions must be planned in advance.
  • It’s important to listen carefully at this meeting, as a lot of information is given orally.
  • Don’t hesitate to ask the people in charge at this meeting to find out exactly what role is given to your team.
• There’s little time between the NATO briefing and the school’s first milestone.
• Milestone number 4 marks the end of development on the school side, but it is still possible to continue for a few weeks on the NATO side, even if this is not recommended, as a lot of work is required of students on the school side during this period.
• Incomplete work or work that does not fully meet NATO’s specifications will be rejected during the validation phase and will not be used during the exercise!

Travel to Tallinn #

As you’d expect, it’s possible to attend NATO meetings physically or by videoconference.

The school cannot send all group members at the same time, and in our case only one member could go per meeting. So there are usually 2 trips planned:

• The first for the information meeting
• The second for the exercise, if the project is accepted.

The first trip takes place during the school period, so you’ll need to make sure you don’t miss any tests or make them up.

The exercise takes place during the company period, so you’ll need to take days off or make arrangements with your employer.

The school will reimburse you for your travel expenses, but don’t count on them to help you book planes/trains/hotels - you’ll have to find them on your own, and make sure you keep the receipts.

Beginning of the project #

At the start of the project, we had no information at all. This was the first thing that surprised us, neither we nor our teachers had received any indication whatsoever. Overall, before the information meeting you have no idea where to start.

Fortunately, it wasn’t long before the first briefing took place. It was Ben who flew out and represented us there ✈️

On his return, we learned that we were now part of the Green Team (development team). Our mission is to develop a WebSSO.

A WebSSO is a web application that allows users to authenticate themselves once to access multiple online services. Once authenticated, the user receives an authentication token (token), which is used to access other services integrated into the SSO system.

Our WebSSO must meet the following requirements:

• Be configurable and deployable via an Ansible playbook.
• Be able to interconnect with an Azure AD environment via LDAPS.
• Support the OpenID Connect or SAML protocol to act as an Identity Provider.
• Multiple Selenium test profiles to verify WebSSO functionality
• Time permitting: add a “vulnerable ‘ configuration to the playbook, so that the ’secure” or “vulnerable” version can be deployed at any time for the exercise.

Of course, there’s also the deployment of the WebSSO in the infrastructure set up by Locked Shields and the interconnection between the different teams, not to mention the recurring progress presentations and all the other courses/projects on the school side.

Solution selection #

The first thing we did was to choose an SSO, for which we tested 3 solutions:

The test consisted in deploying SSO (without playbook) and checking the interconnection with a Windows Server 2022 via LDAP. We had little time to carry out this test, and only succeeded with LemonLDAP. This solution also presented an Ansible playbook that we could use as a basis, which is why we chose it.

Furthermore, this open-source solution is French!

First difficulties #

None of the team had implemented a WebSSO before, and our knowledge of Ansible was very limited, so we had to learn!

Fortunately LemonLDAP documentation is quite big. It’s easy to get lost in all these pages, so here’s a list of the ones we found most useful:

• Presentation of the tool and its components (still essential)
• LDAP module and MiniHowTo (for interconnection with AD)
• Identity Provider (in particular the SAML / OpenID pages)
• CLI configuration examples
• List of variables

Playbook development #

I’m going to skim over the technical part rather quickly and only talk about the Ansible playbook and the LDAPS interconnection, as this is the part I’ve been working on.

The initial playbook #

LemonLDAP is composed of 3 elements:

• Handler: Checks whether the user is authorized to use SSO, and gives access to the Portal or not. It is also responsible for verifying the data sent by the user and protecting applications (anti XSS sanitizer, anti SQL injection, etc.).
• Portal: Used to authenticate users, it enables access to multiple applications from a single point of entry.
• Manager: Used to manage LemonLDAP configuration, it is dedicated to administrators.

The basic playbook supplied with LemonLDAP is fairly straightforward:

  - name: Install LemonLDAP
    hosts: localhost
    become: yes
    roles:
      - role: ansible-lemonldap
        lemonldap_domain: mysuper.domain
        lemonldap_webserver: "nginx"

• hosts: indicates the IP or FQDN of the machines on which LemonLDAP should be installed
• become: indicates Ansible whether or not to use administrator rights
• lemonldap_domain: indicates the domain name used by the LDAP directory
• lemonldap_webserver: indicates the web server you wish to use → it’s possible to use nginx or apache.

This playbook lets you install the LemonLDAP tool, a web server and configure them for a particular domain name. However, it still lacks the interconnection with the LDAP directory, which is what we’re going to do.

LDAP interconnection #

We need to specify certain parameters for the manager, including the protocol and the service account that will be used to authenticate users.

The problem is that these parameters must be set on a web administration page that manages the manager, yet we want to control the deployment and configuration of LemonLDAP directly from the Ansible playbook.

To resolve this problem, our playbook will configure the manager directly from the LemonLDAP CLI and set these parameters using Ansible variables.

This is how our playbook now looks:

  - name: Install LemonLDAP
    hosts: localhost
    become: yes
    roles:
      - role: ansible-lemonldap
        lemonldap_domain: mysuper.domain
        lemonldap_webserver: "apache"
    vars:
      - ldap_server_ip: "ldap://192.168.1.2"
      - ldap_port: 389
      - ldap_verification: "none"
      - ldap_timeout: 120
      - ldap_base: "dc=mysuper,dc=domain"
      - ldap_account: "cn=websso,cn=users,dc=mysuper,dc=domain"
      - ldap_password: "SuperP@ssw0rd!"

Once the server is connected to the domain, all you have to do is enter the right information in the playbook, and any AD user can now authenticate on LemonLDAP!

Now it’s time to switch to LDAPS by installing a TLS certificate on the AD. If the certificate is self-signed, then the playbook’s parameter ldap_verification must be set to false (as it will not be able to verify the certification authority).

By changing the parameter ldap_port to 636 and ldap_ip to ldaps://[ip], everything is ready for the LDAPS connection.

We now have an operational Ansible playbook for automatically deploying LemonLDAP on a Linux server and making the LDAPS interconnection with the AD.

(It sounds simple, but it took us several months to achieve this result!)

Improvements #

I could have stopped at this point, but I thought it was a shame that the home page didn’t come with the Locked Shields colors.

That’s why I’ve added the possibility to change the application’s background, logo and favicon with some playbook variables. Here’s an example:

Finally, you may have noticed that the password for the service account is entered in clear text in the playbook. As it is not possible to use a gMSA (service account managed by the AD), we had to find a solution to erase all traces of this account’s credentials.

The chosen solution was to generate no logs and delete all files from the Ansible playbook once the other tasks had been completed. This action is controlled by the delete_files variable.

Here’s an example of a playbook with all the variables built in:

  - name: Install LemonLDAP
    hosts: localhost
    become: yes
    no_log: True
    roles:
      - role: ansible-lemonldap
        lemonldap_domain: mysuper.domain
        lemonldap_webserver: "apache"
    vars:
      - ldap_server_ip: "ldaps://192.168.1.2"
      - ldap_port: 636 
      - ldap_verification: "none"
      - ldap_timeout: 120
      - ldap_base: "dc=mysuper,dc=domain"
      - ldap_account: "cn=websso,cn=users,dc=mysuper,dc=domain"
      - ldap_password: "SuperP@ssw0rd!"
      - main_logo: "logo.png"
      - favicon: "favicon.ico"
      - background: "background.png"
      - activate_SAML: "yes"
      - delete_files: "yes"

Architectures #

We can represent this playbook in the following logical architectures (in french):

1. The user is trying to access a web application but does not have a session cookie.
2. The application’s web server redirects the user to the LemonLDAP server (this may be the same server). The handler checks that the user can use SSO, and if so, the user is redirected to the portal.
3. User authenticates on portal, service account requests LDAP server
4. LDAP directory verifies user credentials and returns response to portal
5. If authentication fails, the user must retry; if successful, the portal provides the user with a session cookie.
6. The user can access the application with this session cookie.

GitHub repositories #

Obviously, this playbook alone only authenticates users on the WebSSO. To give them access to third-party applications, you need to set up this server as an Identity Provider. This is the role of Tanguy’s playbook. You can find our playbooks on the following GitHub repositories.

Validation of the project #

This marks the end of the project’s development. At this stage, we had to prepare the school’s final presentation. This one is special because:

• only 1 slide is allowed
• 1 minute per student is allowed

We therefore had 4 minutes to present the project, a very interesting exercise which forced us to simplify and to highlight only the most important points.

On the NATO side, we submitted the source code and documentation, so all we had to do was wait for the CCDCOE’s decision. It’s a long and stressful wait, given the amount of time spent on this work, which will potentially not be used at all during the exercise.

After a few weeks, we learned that our project had been selected and that our WebSSO would indeed be used!

Very happy with these news, we now had to decide which of us would go on site for the exercise, and we decided that Ben would once again take this role ✈️

The exercise went off without a hitch, and here are the final rankings:

1. 🥇 Latvia with a team made up of NATO entities
2. 🥈 Finland-Poland
3. 🥉 Estonia-France

Conclusion #

Participating in the organization of Locked Shields was a great experience!

I was able to deepen my knowledge in many areas, including Ansible, Active Directory and Identity Providers.

However, beyond the technical aspects, this project taught me the importance of organization and collaboration. Working with international teams highlighted the importance of communication and coordination to achieve common goals. These skills are essential for success in large-scale projects such as this, and are the most valuable lesson of this experience.

I sincerely hope that this collaboration between ENSIBS, Tallinn University and CCDCOE will continue, offering other students this wonderful opportunity.

I also hope that you have enjoyed this post and that it has answered all your questions. On my side, I really enjoyed writing it!