The Internet has grown from a few interconnections of trusted parties to an incredibly large network with many different use cases. While the Internet grew, threats emerged as well. Although there are many different threats on the Internet, Distributed Denial of Service (DDoS) attacks are a threat that keeps rising in the threat landscape. The asymmetry between adversaries and defenders is enormous - whereas DDoS attack can be started for less than 5$, DDoS prevention takes up the majority of operational cost in data centers and damages are in the billions. Thus, it is of vital importance that more effective methods of DDoS prevention are found and implemented to improve defensive effectiveness and to reduce costs. DDoS attacks consist of various types, but the largest share of DDoS attacks are of the subtype Distributed Reflected Denial of Service (DRDoS) attacks. Adversaries that execute DRDoS attacks use vulnerable servers to create incredibly large attacks and to stay anonymous. Previous work by Rossow showed us which vulnerable services are typically used for these DRDoS attacks, and how well these vulnerable services are exploitable for these attacks. However, we do not know why an adversary uses one vulnerable service but not another. Thus, this work fills that research gap by researching how adversaries react to differently configured vulnerable services, using a large scale experiment. This work shows that the amplification factor of a honeypot is a primary factor that determines whether an adversary will use a vulnerable server in an attack or not. This work also shows that attackers do not distinguish between regular vulnerable servers and their obvious honeypot counterparts. Furthermore, the response time of a system is of no influence, and some honeypots with packet loss attract fewer adversaries. Additionally, different attacks can be detected while using different service providers and geographical locations for honeypot deployment. Finally, the MD-honeypot framework that was developed for this research may be further developed into fully-fledged DRDoS mitigation software.

The E-Sports Game Arena will launch an esports cafe in the summer of 2017. At this location, the company wants to introduce membership cards to create a sense of community. The goal of the project was to explore the technological possibilities of such cards and to create a working prototype that makes use of these possibilities.

At the start of the project the assignment was still broad: explore the possibilities of a card system at the Arena. The first goal was to set a clear scope for the project by brainstorming with the client. After the brainstorm sessions, some ideas were selected while keeping factors like allotted time and technical practicality in mind. From these ideas, requirements were created to establish the essential functionalities necessary for the system. User scenarios were created to formulate the requirements in real world use cases to get a better understanding of the situations in which the system is used.

Following the design phase, the technical specification was constructed. Together with our client we decided that creating a proper software foundation for the card system was vital to this project, as it would later be expanded with other features and systems. Additionally, we created four prototype applications that make use of this foundation.

During the project, we analyzed the security aspects in detail by listing risks, possible attacks, and solutions that could be used to mitigate such attacks. For security solutions that were not implemented during the course of the project, we made recommendations as a guideline for future improvements.

This report also details the testing process used in this project, describing the use of testing frameworks and approaches. Then, the proceedings of the project with respect to its group members, the coach, the client, and the Software Improvement Group are evaluated. Afterward, the product as a whole is evaluated in retrospect, taking the project requirements into account.

Finally, a conclusion is made, evaluating the success of the project and giving our final recommendations. From this we can say that the project has been a success, as the success criteria have been met.