Log4j på AWS

I AWS bruger vi selvfølgelig præcis den samme software, som typisk kører alle andre steder.

Heldigvis er fokus på gentagelighed og automatisering fundamentet for Cloud. Det er ikke altid, at der er brug for adgang til et On-Prem datacenter. Hvis der er, er kommunikationen stærkt kontrolleret. i.e. kald til ldap bliver ikke nødvendigvis routet rundt i netværket, hvis man ikke specifikt har brug for det.

For det første, skal man evaluere, hvilke AWS services man egentlig bruger, og om de fremgår af Update for Apache Log4j2 Issue (CVE-2021-44228). Listen fortæller, hvilke services AWS allerede har opdateret, og hvilke tilfælde man selv skal være opmærksom.

Da en angriber typisk kommer “udefra”, skal man se på snitfladen ind imod ens systemer. “First line of defence” kan være WAF & Shield. Man kan altså filtrere suspekte kald helt væk, så de aldrig rammer ens applikationer.

Dét bringer os til den enkelte platform eller applikation. Infrastructure as Code er en typisk strategi og i situationer som denne, får man virkelig udnyttelse af dét arbejde, man har lagt dér. En justering af software, så man bruger de seneste pakker og en efterfølgende udrulning af nye pakker, kan være foruroligende enkel. Det er en proces, man udfører jævnligt, og den nuværende situation er ikke anderledes, end dét man normalt gør.

Et eksempel kunne være brugen af AWS Kinesis, til streaming af data. Selvom ens anvendelse af awskinesis-agent ikke er eksponeret ud af Amazon’s netværk, kan det være rart nok at have denne agent opdateret.

Da vi benytter os meget af automatisering i forbindelse med AWS, har det været meget enkelt at følge med og rulle nye versioner af software og maskiner ud i takt med situationens udvikling.

Hvis du har yderligere spørgsmål, så kontakt Conscia og læs eventuelt tidligere blogposts:

Referencer:

https://en.wikipedia.org/wiki/Infrastructure_as_code
https://github.com/awslabs/amazon-kinesis-agent
https://github.com/cisagov/log4j-affected-db
https://aws.amazon.com/security/security-bulletins/AWS-2021-006/
https://aws.amazon.com/blogs/security/using-aws-security-services-to-protect-against-detect-and-respond-to-the-log4j-vulnerability/
https://alas.aws.amazon.com/AL2/ALAS-2021-1730.html