Verbeter de beveiliging van je applicaties op AWS, deel I

Beveiliging dient top prioriteit te zijn voor iedere onderneming, niet alleen voor on-premise maar ook voor off-premise of cloud instances

Beveiliging is een erg actueel onderwerp voor de meeste ondernemingen om hun activa the beschermen zeker naar aanleiding van de recente malware aanvallen op basis van WannaCry ransomeware dat ons eens en temeer aantoonde dat de meeste netwerken nog steeds erg gevoelig zijn voor aanvallen via het Internet. Het beschermen van je infrastructuur dient daarom ook top prioriteit te zijn van elke onderneming die zich blootsteld aan het Internet, dit geldt niet alleen voor on-premise instances maar ook voor off-premise of cloud instances zoals AWS.

Het plannen van de architectuur van de oplossing met beveiliging in gedachten is hetgeen we dienen te doen alsvorens we een on-premise of cloud instance in gevaar brengen door hem aan het Internet te koppelen.

In dit artikel zullen ingaan op het onderwerp hoe we de beveiliging van onze applicaties gehost in AWS kunnen aanscherpen. Dit klingt alsof AWS beveiligingsrisico's heeft, niets is echter minder waar AWS heeft prima beveiligingsmechanismen om uw cloud instances te beschermen tegen risicos, echter is niet iedereen hiervan op de hoogte en het starten van een instance of cluster instance is binnen enkele seconden gedaan wat deze instances gevoelig maakt voor aanvallen als er geen additionele maatregelen worden getroffen.

Waarschijnlijk de meesten onder ons zijn op de hoogte van functionaliteiten zoals VPN en direct connect om op een beveiligde manier te connecteren aan een AWS instance, echter niet iedereen is in staat om hiervan gebruik te maken.

De meesten van ons connecteren aan een AWS instance via SSH nadat deze is opgebracht.

Vanwege het gebrek aan beveiligingskennis en niet wetende wat AWS voor ons kan automatiseren als we een instance opbrengen, kunnen onze applicaties risicos lopen. AWS is niet in staat om onze applicatie netwerk infrastructuur en de manier waarop we onze applicaties aan het internet willen koppelen te voorspellen. Hiervoor zijn we zelf verantwoordelijk en dit is dan ook waarom het plannen van een architectuur belangrijk is alvorens ook maar een instance te starten.

Default als we een instance opbrengen maakt AWS een Virtual Private Cloud, Subnets voor availability zones voor de gekozen Region, Networks, Security Groups, Route tables, Internet Gateways etc. aan. Deze subnets zijn direct verbonden via een route met de Internet Gateway, dus de instance is direct verbonden met het Internet. Een Security Group verbonden met de instance zorgt ervoor dat elke machine via SSH over TCP port 22 kan communiceren met deze instance.

Hieronder zien we een voorbeeld van een dergelijke default setup waarbij twee instances in een zekere availability zone van een region direct zijn verbonden met het Internet.

 

 

De enige beveiliging die hier van toepassing is op de instance die verbonden is aan het Internet is een handshake middels een publiek certificaat (Key-Pair). Dus iedereen kan via SSH aan deze instance connecteren, het enige dat men benodigd om toegang te verkrijgen tot deze instance is het certificaat.

Omdat hackers over het algemeen erg slim en creatief zijn en dit wetende, kan ik mij zo voorstellen dat het niet lang zal duren alvorens zij een manier hebben gevonden om een dergelijke beveiliging te omzeilen. Dit betekend dat we additionele maatregelen zullen moeten treffen om het hen moeilijker te maken, hiertoe zullen we onze applicatie instances niet meer direct verbinden met het Internet.

Wij adviseren om twee subnets aan te maken, een publiek en een privaat subnet. Het publieke subnet is effectief een Demilitarized Zone of DMZ en voorziet in toegang van en naar het Internet, hiervoor is een route table geconnecteerd met de Internet Gateway. Elke instance die we nu opstarten binnen het publieke subnet zal direct verbonden zijn met het Internet via een publiek ip adres. Om ervoor te zorgen dat dit een vast adres is kunnen we gebruik maken van elastic ips. Default is de gehele instance verbonden met het Internet, om dit te limiteren kunnen we gebruik maken van Security Group welke kunnen worden toegepast op de instance in het publieke subnet welke het inkomend en uitgaand verkeer kan limiteren, in ons geval willen we alleen poort 22 openen voor inkomend SSH verkeer.

 

Het private subnet, zal onze applicatie instances bevatten die niet direct aan het Internet verbonden dienen te zijn, hiervoor kunnen we een lokale routing tabel aanmaken die het verbiedt om aan devices to connecteren zowel in het private of het publieke subnet.

Omdat we onze instances in het private subnet up to date willen houden met software patches en/of nieuwe software packages benodigen we een Internet connectie om deze te kunnen downloaden. We kunnen dit op een beveiligde manier garanderen middels een NAT Gateway in ons publieke subnet, toegang tot het Internet wordt geregeld middels het specificeren van een route tussen een NAT Gateway en de Internet Gateway.

Omdat de NAT Gateway binnenkomend Internet verkeer blokkeerd hebben we een manier nodig om ons private subnet te betreden om zodoende onze applicatie instances in dit subnet te kunnen onderhouden. Om dit mogelijk te maken benodigen we een instance binnen het publieke subnet, aan deze instance wordt vaak gerefereerd middels de naam Bastion Server of Jumpbox. Het idee hiervan is dat we eerst middels middels SSH moeten inloggen op deze instance in het publieke netwerk alsvorens we middels SSH in onze instances in het private subnet kunnen springen. Deze sprong kan worden geautomatiseerd en addtionele beveiliging kan worden toegepast middels een reverse proxy waardoor de certificaten die benodigd zijn om onze instances in het private subnet te kunnen benaderen niet hoeven te worden opgeslagen op de Bastion Server in ons private netwerk.

De naam Bastion stamt af van een structuur welke beschermd tegen bedreigingen van buitenaf, ze werden gebruikt voor verdediging en om mogelijke vijanden buiten te houden. Hetzelfde concept is van toepassing voor de interne netwerken van bedrijven, wij willen indringers van buiten of het Internet niet laten penetereren in ons interne of private netwerk maar de deur hiertoe voor hen sluiten.

Bastion.JPG

Door het toepassen van een publiek en private subnet en een Bastion Server dient de aanvaller twee hordes te nemen alvorens hij toegang kan krijgen tot onze applicaties en data en mogelijke schade kan veroorzaken.

We kunnen de beveiliging verder aanscherpen door niet het default poort nummer voor SSH te gebruiken en niet onnodige poorten te openen, ook kunnen we slechts beperkte machines toegang geven om via SSH een verbinding te maken met het publieke subnet, daarnaast kunnen we de optie sluiten om SSH via de default ec2-user toe te staan, in plaats hiervan kunnen we een andere gebruiker aanmaken etc.

Ik hoop dat dit artikel bijdraagd aan een betere begrip van de potentiele risicos die men loopt als men zonder beveiliging in gedachten of kennis hiervan een AWS instance gaat starten.

In mijn volgende blogs zal ik proberen de setup meer in detail proberen uit te leggen en daarnaast laten zien hoe we gebruik kunnen maken van automation in combinatie met AWS.

Ronald Span

Founder of Scalar Data, over 20 years of experience in a variety of national and international IT projects in different roles, development, consultancy, pre-sales, management and business development. Scalar Data is helping organizations to implement their big data strategy.