Forem: Andreas Brunner

Antivirus on AWS

Andreas Brunner — Tue, 09 Dec 2025 07:44:04 +0000

How can files on AWS be scanned for viruses? There is no built-in solution. But we can build our own using Lambda Functions and Layers.

Our solution involves packing the open-source antivirus engine ClamAV into a Lambda Layer and running the scan command from a Lambda Function.

This article only covers how to package ClamAV into a Lambda layer for use in Lambda functions.

Get the required ClamAV files

The first step in building the Lambda Layer is to obtain the necessary files from the RPM package in the Amazon Linux repository. To achieve this, we run a Dockerfile with the amazonlinux image and install ClamAV, then extract the files.

First, let's create a config file for ClamAV called freshclam.conf.

DatabaseMirror db.de.clamav.net database.clamav.net
CompressLocalDatabase no
ScriptedUpdates no
LogVerbose yes

Next, create a file called dockerfile.

Although AWS states that the package name clamav should point to the latest ClamAV version, it only does when you run dnf install. When calling the dnf download command still points to the outdated version 0.103.12. Thats why we download explicitly clamav1.4.

# © 2025 cloudxs GmbH. All rights reserved. / dockerfile 

FROM amazonlinux:2023

WORKDIR /home/build

RUN set -e

RUN echo "Prepping ClamAV"

RUN rm -rf bin
RUN rm -rf lib

RUN dnf update -y
RUN dnf install -y cpio \
                   dnf-plugins-core \
                   zip

RUN dnf download --arch x86_64 clamav1.4
RUN rpm2cpio clamav1.4-1*.rpm | cpio -vimd

RUN dnf download --arch x86_64 clamav1.4-lib
RUN rpm2cpio clamav1.4-lib*.rpm | cpio -vimd

RUN dnf download --arch x86_64 clamav1.4-update
RUN rpm2cpio clamav1.4-freshclam*.rpm | cpio -vimd

RUN dnf download --arch x86_64 json-c
RUN rpm2cpio json-c*.rpm | cpio -vimd

RUN dnf download --arch x86_64 pcre2
RUN rpm2cpio pcre*.rpm | cpio -vimd

RUN dnf download --arch x86_64 libtool-ltdl
RUN rpm2cpio libtool-ltdl*.rpm | cpio -vimd

RUN dnf download --arch x86_64 libxml2
RUN rpm2cpio libxml2*.rpm | cpio -vimd

RUN dnf download --arch x86_64 bzip2-libs
RUN rpm2cpio bzip2-libs*.rpm | cpio -vimd

RUN dnf download --arch x86_64 xz-libs
RUN rpm2cpio xz-libs*.rpm | cpio -vimd

RUN dnf download --arch x86_64 gnutls
RUN rpm2cpio gnutls*.rpm | cpio -vimd

RUN dnf download --arch x86_64 nettle
RUN rpm2cpio nettle*.rpm | cpio -vimd

RUN dnf download --arch x86_64 openldap
RUN rpm2cpio openldap*.rpm | cpio -vimd

RUN dnf download --arch x86_64 pcre
RUN rpm2cpio pcre*.rpm | cpio -vimd

RUN dnf download --arch x86_64 nss
RUN rpm2cpio nss*.rpm | cpio -vimd

RUN dnf download --arch x86_64 libssh2
RUN rpm2cpio libssh2*.rpm | cpio -vimd

RUN mkdir -p bin
RUN mkdir -p lib
RUN mkdir -p var/lib/clamav
RUN chmod -R 777 var/lib/clamav

COPY ./freshclam.conf .

RUN cp usr/bin/clamscan usr/bin/freshclam bin/.
RUN cp -R usr/lib64/* lib/.
RUN cp freshclam.conf bin/freshclam.conf

# Copy some libraries separately
RUN cp /lib64/libcurl* lib/.
RUN cp /lib64/libcrypt* lib/.
RUN cp /lib64/libnss* lib/.
RUN cp /lib64/libunistring* lib/.
RUN cp /lib64/libgcrypt* lib/.
RUN cp /lib64/libssl* lib/.
RUN cp ./usr/lib64/libssh2* lib/.
RUN cp /lib64/libidn2* lib/.
RUN cp /lib64/libnghttp2* lib/.
RUN cp ./usr/lib64/libsmime3* lib/.

RUN yum install shadow-utils.x86_64 -y

RUN groupadd clamav
RUN useradd -g clamav -s /bin/false -c "Clam Antivirus" clamav
RUN useradd -g clamav -s /bin/false -c "Clam Antivirus" clamupdate

RUN LD_LIBRARY_PATH=./lib ./bin/freshclam --config-file=bin/freshclam.conf

RUN zip -r9 clamav_lambda_layer.zip bin
RUN zip -r9 clamav_lambda_layer.zip lib
RUN zip -r9 clamav_lambda_layer.zip var
RUN zip -r9 clamav_lambda_layer.zip etc

The Dockerfile above creates a new container with ClamAV and all its required libraries in a ZIP archive within the container. This means we need to extract it. For this, we have a bash script called build.sh that builds the container, runs it, copy the layer.zip and extract into a directory called layer.

#!/bin/bash

# © 2025 cloudxs GmbH. All rights reserved. / build.sh 

set -e

rm -rf ./layer
mkdir layer

docker build -t clamav -f Dockerfile --progress=plain .
docker run --name clamav clamav
docker cp clamav:/home/build/clamav_lambda_layer.zip .
docker rm clamav
mv clamav_lambda_layer.zip ./layer

pushd layer
unzip -n clamav_lambda_layer.zip
rm clamav_lambda_layer.zip
popd

Now, all the files we need to run ClamAV in a Lambda function are in the directory called layer.

Create the Lambda Layer

Of course, deploying Lambda Functions and Lambda Layers depend a lot on the IAC tool you use. We use SST, which is Pulumi under the hood.

To create a Lambda Layer with SST or Pulumi, all you need to do is package the layer directory from the previous step. Our deployment looks similar to this.

const avLayerOutputDir = 'workspaces/antivirus/lambda/clamav_bin/layer';  
const layerAvBinaries = new aws.lambda.LayerVersion(
  `clamav-bin-${$app.stage}`,
  {
    layerName: `clamav-bin-${$app.stage}`,
    code: $asset(avLayerOutputDir),
    compatibleRuntimes: ['nodejs20.x', 'nodejs22.x'],
  },
);

CI/CD pipeline

We build and deploy the Lambda Layer in an Azure DevOps pipeline. To improve pipeline speed, we implemented a caching step. In order to make proper use of the caching, we need to know the most current ClamAV version. The following fragment is the build stage of our pipeline.

variables:
  - name: CACHE_HIT_LAMBDA_LAYER
    value: 'false'

pool:
  vmImage: ubuntu-latest

stages:
  - stage: Build
    jobs:
      - job: build_lambda_layer
        displayName: Build Lambda Layer
        steps:
          - bash: bash getClamavVersion.sh
            displayName: Get ClamAV version
            workingDirectory: $(System.DefaultWorkingDirectory)/workspaces/antivirus/lambda/clamav_bin

          - task: Cache@2
            displayName: Cache lambda layer
            inputs:
              key: 'amazonlinux | "$(Agent.OS)" | "Clamav $(clamav_version)"'
              path: $(System.DefaultWorkingDirectory)/workspaces/antivirus/lambda/clamav_bin/layer
              cacheHitVar: CACHE_HIT_LAMBDA_LAYER

          - bash: bash build.sh
            displayName: Build lambda layer
            workingDirectory: $(System.DefaultWorkingDirectory)/workspaces/antivirus/lambda/clamav_bin
            condition: ne(variables.CACHE_HIT_LAMBDA_LAYER, 'true')

          - script: ls -lisah
            displayName: List files in the working directory
            workingDirectory: $(System.DefaultWorkingDirectory)/workspaces/antivirus/lambda/clamav_bin/layer

          - publish: $(System.DefaultWorkingDirectory)/workspaces/antivirus/lambda/clamav_bin/layer
            artifact: layer

The first step in the build job calls the script getClamavVersion.sh. This script runs the amazonlinux container, gets the latest clamav version and writes it into an pipeline variable.

#!/bin/bash
# © 2025 cloudxs GmbH. All rights reserved. / getClamavVersion.sh 

AZLINUX_IMAGE="amazonlinux:2023"
CLAMAV_PKG="clamav1.4"

docker run --rm $AZLINUX_IMAGE bash -c "CAVERSION=\$(dnf info $CLAMAV_PKG | grep Version | awk -F: '{print $2}');

echo \"##vso[task.setvariable variable=clamav_version]\$CAVERSION\""

How to use

We use a separate scheduled Lambda function to download the new Antivirus definitions every three hours and upload them to S3. Afterwards a second Lambda gets triggered, that moves the AV Definitions to EFS. Since Lambda has a limit of 500MB storage, we need the EFS anyway to handle larger files.

The EFS is mounted as well to the Scanning Lambda function, so that we have the definitions available. The Scanning Lambda function gets triggered by S3 PutObject events. Due to the memory limits of AWS Lambda, we only scan files up to 2GB.

const PATH_TO_FRESHCLAM = 'freshclam';
const PATH_TO_CLAMAV = 'clamscan';
const FRESHCLAM_CONFIG = '/opt/bin/freshclam.conf';
const FRESHCLAM_WORK_DIR = process.env.FRESHCLAM_WORK_DIR || '/tmp';
const TMP_AVDEFINITION_DIR = '/tmp/avdefinitions';

/**
 * Updates the definitions using freshclam.
 *
 * It will download the definitions to the current work dir.
 */
export function updateAVDefinitonsWithFreshclam() {
  try {
    execSync('ls -lisah /opt');
    const executionResult = execSync(
      `${constants.PATH_TO_FRESHCLAM} --config-file=${constants.FRESHCLAM_CONFIG} --datadir=${constants.TMP_AVDEFINITION_DIR}`,
      { cwd: '/opt' }
    );

    generateSystemMessage('Update message');
    console.log(executionResult.toString());

    if (executionResult.stderr) {
      generateSystemMessage('stderr');
      console.log(executionResult.stderr.toString());
    }

    return true;
  } catch (err) {
    console.log(err);
    return false;
  }
}

/**
 * Function to scan the given file. This function requires ClamAV and the definitions to be available.
 * This function does not download the file so the file should also be accessible.
 *
 * Three possible case can happen:
 * - The file is clean, the clamAV command returns 0 and the function return "CLEAN"
 * - The file is infected, the clamAV command returns 1 and this function will return "INFECTED"
 * - Any other error and the function will return null; (falsey)
 *
 * @param pathToFile Path in the filesystem where the file is stored.
 */
export function scanLocalFile(pathToFile) {
  try {
    execSync(
      `${constants.PATH_TO_CLAMAV} -v -a --stdout --database=${constants.EFS_AVDEFINITION_DIR}/ '${constants.FRESHCLAM_WORK_DIR}/tmp/${pathToFile}'`
    );

    generateSystemMessage('SUCCESSFUL SCAN, FILE CLEAN');

    return constants.STATUS_CLEAN_FILE;
  } catch (err) {
    // Error status 1 means that the file is infected.
    if (err.status === 1) {
      generateSystemMessage('SUCCESSFUL SCAN, FILE INFECTED');
      return constants.STATUS_INFECTED_FILE;
    } else {
      generateSystemMessage('-- SCAN FAILED --');
      console.log(err);
      return constants.STATUS_ERROR_PROCESSING_FILE;
    }
  }
}


/**
 * Uploads the AV definitions to S3 bucket.
 */
export async function uploadAVDefinitions() {
  const uploadPromises = constants.CLAMAV_DEFINITIONS_FILES.map((filenameToUpload) => {
    generateSystemMessage(`Upload updated definitions for file ${filenameToUpload}`);

    const options = {
      Bucket: constants.CLAMAV_BUCKET_NAME,
      Key: `${constants.PATH_TO_AV_DEFINITIONS}/${filenameToUpload}`,
      Body: fs.createReadStream(path.join(constants.TMP_AVDEFINITION_DIR, filenameToUpload)),
    };

    const data = client
      .send(new PutObjectCommand(options))
      .then((data) => {
        generateSystemMessage(`Upload finished ${filenameToUpload}`);
        return data;
      })
      .catch((err) => {
        generateSystemMessage(`Error uploading ${filenameToUpload}`);
        console.log(err);
      });
    return data;
  });

  return await Promise.all(uploadPromises);
}

We hope this article helps anyone who is facing the challenges of packaging the ClamAV antivirus in a Lambda Layer.

Sincerely, Andy from cloudxs GmbH

Intune appends «/qn ALLUSERS=1»

Andreas Brunner — Fri, 11 Nov 2022 09:31:23 +0000

Are you trying to run a Powershell script as an Intune install command and you have the string .msi in it and realized that your command fails, because Intune automatically modifies it? Here is the thing. As soon as Intune finds .msi in your install command, it appends /qn ALLUSERS=1 on its own. Even if they had good intentions to implement this, when we want to run a powershell script, they break our command.

Here is our install command in the Intune Administration GUI.

And here you see what is executed on the client.

If you have named arguments in your Powershell script, the command will break. Powershell will throw an error because it does not know any parameter «/qn» or «ALLUSERS=1».

Here is an example. If you have the following Install command, you will get an error.

powershell -executionpolicy bypass -file .\installer.ps1 -myMSI "https://domain.com/myMsiPackage.msi"

The trick is to use unnamed arguments in your script. In the following example, we removed -myMSI.

powershell -executionpolicy bypass -file .\installer.ps1 "https://domain.com/myMsiPackage.msi"

Now, at the top of your script, don’t catch the parameters with a param() block. Catch them with the $args array. The installer.ps1 would start with the following line.

$myMSI = $args[0]
# $myMSI will contain -> https://domain.com/myMsiPackage.msi

# the rest can be ignored
# $args[1] will contain -> /qn
# $args[2] will contain -> ALLUSERS=1

Very easy if you know how.

Create a Rest API with AWS API Gateway, a Lambda function and a RDS Aurora Cluster deployed by CDK

Andreas Brunner — Mon, 02 Aug 2021 08:41:31 +0000

Alright, I admit, the title of this blog post is rather long. But hey, the advantage is that you already know exactly what we're going to cover in this article. Since we believe that AWS CDK is one of the most advanced tools available today for implementing infrastructure as code on AWS, this article contains only CDK code fragments.

Please note, this is not a complete step-by-step guide. We only want to document the code fragments required to create and connect the AWS resources needed for a Rest API that talks to a RDS database. We assume that you are already familiar with CDK and know how to implement the following fragments into your CDK stacks. And, just to mention that, in our real-world application, we divide resources among different stacks (e.g. a network stack, a database stack, etc.). However, for the sake of simplicity, this will be excluded here.

Ready? Let's dive into it.

VPC

Our database has to be connected to a VPC. That's why we first create VPC and add the needed VPC Interface Endpoints to it.

/* nodejs modules */
import * as ec2 from '@aws-cdk/aws-ec2';

......

/* create a vpc */
const vpc = new ec2.Vpc(this, 'vpc', {
  ...
});

/* Secrets Manager Endpoint */
vpc.addInterfaceEndpoint('sm',{
  service: ec2.InterfaceVpcEndpointAwsService.SECRETS_MANAGER
});

/* RDS Data API Endpoint */
vpc.addInterfaceEndpoint('rds_data',{
  service: ec2.InterfaceVpcEndpointAwsService.RDS_DATA
});

Database

Next, we add the construct to create our database cluster. Please note, the following example creates a cluster that meets our own specific needs. You will probably need to adjust the cluster properties.

/* nodejs modules */
import { SubnetType } from "@aws-cdk/aws-ec2";
import * as rds from '@aws-cdk/aws-rds';


/* RDS - Aurora - database */
const dbCluster  = new rds.ServerlessCluster(this, 'database', {
  engine: rds.DatabaseClusterEngine.auroraPostgres({version: rds.AuroraPostgresEngineVersion.VER_10_12}),
  vpc: vpc,
  vpcSubnets: {
    subnetType: SubnetType.ISOLATED
  },
  defaultDatabaseName: 'mydatabase',
  enableDataApi: true,  /* this is important ! */
  removalPolicy: cdk.RemovalPolicy.RETAIN,
});

If we create a database cluster with this high level construct, the admin account for accessing the database is created automatically and the credentials are stored in the Secrets Manager.

Here's a little side note. For our application we needed to add cross-region secret replication to the automatically generated secret. It took us some efforts to achieve it, but finally we made it. The first line grabs the CloudFormation node of the secret from the clusters child nodes. Once we have that, the addReplicationRegion can easily be called.

const secret = dbCluster.node.children.filter((child) => child instanceof rds.DatabaseSecret)[0] as rds.DatabaseSecret;
secret.addReplicaRegion('us-east-1');

Alright. What's next?

Lambda function

Let us create a Lambda function that is capable of talking to our database. Our Lambda function will be connected to the same VPC as the database, it will get two environment variables (ARN of the database cluster and ARN of the secret) and we extend the timeout by a few seconds.

Now check out the last line in the following fragment. That's why we love CDK. One single line of code and all the IAM permissions for the Lambda function needed to be able to connect to the database are set exactly as we need it, including the permissions to grab the admin credentials from Secrets Manager.

/* nodejs modules */
import * as lambda from '@aws-cdk/aws-lambda';

const lambdaHandler = new lambda.Function(this, 'myLambdaFunction',{
  runtime: lambda.Runtime.NODEJS_14_X,
  code: lambda.Code.fromAsset('./lib/lambda/myLambdaFunction'),
  handler: 'index.handleApiRequest',
  vpc: vpc,
  environment: {
    'dbClusterArn': dbCluster.clusterArn,
    'secretArn': secret.secretArn
  },
  timeout: cdk.Duration.seconds(30)
});

/* grant permissions to access the RDS Data API */
dbCluster.grantDataApiAccess(lambdaHandler);

Now we provide you with some sample content of the Lambda function itself (./lib/lambda/myLambdaFunction/index.ts). Please note that this code is not suitable for production! It is just a demo to show you how to run a simple SQL command on a database and return the result.

import { APIGatewayProxyEvent, APIGatewayProxyResult } from 'aws-lambda';
import * as AWS from 'aws-sdk';

export const handleApiRequest = async (event: APIGatewayProxyEvent): Promise<APIGatewayProxyResult> => {

  // prepare SQL command
  const sqlParams = {
    secretArn: process.env.secretArn,
    resourceArn: process.env.dbClusterArn,
    sql: 'select * from myDemoTable;',
    database: 'mydatabase',
    includeResultMetadata: true
  } as AWS.RDSDataService.ExecuteStatementRequest;

  const rdsData = new AWS.RDSDataService();
  const result = await rdsData.executeStatement(sqlParams, (err, data) => {
    if (err){
      console.log(err);
    } else {
      console.log(data);
    }
  }).promise();


  return {
    statusCode: 200,
    body: JSON.stringify({
      message: 'command completed successfully',
      result: result,
      event: event
    }),
  };
};

If you run a test on this Lambda function you should already be able to run SQL commands and get the result back.

API Gateway

Now there is only one piece missing, our Rest API. You may won't believe how easy we can create our API with CDK. Check this out.

/* nodejs module */
import * as apigw from '@aws-cdk/aws-apigateway';


/* create an API */
const apiDemo = new apigw.RestApi(this, 'demoApi');

/* add a resource to the API and a method to the resource */
const demo = apiDemo.root.addResource('demo');
demo.addMethod('GET', new apigw.LambdaIntegration(lambdaHandler));

Three lines of code and we have an API with a /demo resource and a GET method and a Lambda function attached to it. And what about the permissions for invoking the Lambda? Everything is set up automatically. Isn't it awesome?

If you want to add one or more request parameters to a method, have a look at the following PUT sample. This was tricky to figure out and hidden very well in the documentation. In addition, we can add a RequestValidator that already checks at the API Gateway whether the request parameter was passed correctly. This has the advantage that we don't have to implement such a check in the Lambda function and it prevents unnecessary Lambda invocations.

Of course, you can also validate the payload of the requests. Check out the great post by Davide de Paolis.

    const stringParamValidator = new apigw.RequestValidator(this, 'stringParamValidator', {
      restApi: apiDemo,
      requestValidatorName: `stringParamValidator`,
      validateRequestParameters: true
    });

    demo.addMethod('PUT', new apigw.LambdaIntegration(lambdaHandler), {
      requestParameters: {
        'method.request.querystring.myparameter': true
      },
      requestValidator: stringParamValidator
    });

Again a side note. The aws-apigateway module has another class that could make it even easier to create Lambda backed Rest APIs. You may want to read about it here.

And here is another addition to the API Gateway topic. In our real-world application, we needed a private Rest API. If you are curious about how to create a private Rest API, one that is accessable only within a VPC, here is our API construct with a policy attached.

/* API Gateway endpoint, only for private Rest APIs needed */
const apigwEndpoint = vpc.addInterfaceEndpoint('apiGw', {
  service: ec2.InterfaceVpcEndpointAwsService.APIGATEWAY
});



/* private API Gateway */
const api = new apigw.RestApi(this, 'demoApi', {
  endpointConfiguration: {
    types: [apigw.EndpointType.PRIVATE],
    vpcEndpoints: [apigwEndpoint]
  },
  policy: new iam.PolicyDocument({
    statements: [
      new iam.PolicyStatement({
          effect: iam.Effect.ALLOW,
          principals: [new iam.AnyPrincipal()],
          actions: ["execute-api:Invoke"],
          //the following creates a reference to the RestAPI itself
          resources: [cdk.Fn.join('', ['execute-api:/', '*'])]
      }),
      new iam.PolicyStatement({
        effect: iam.Effect.DENY,
        principals: [new iam.AnyPrincipal()],
        actions: ["execute-api:Invoke"],
        resources: [cdk.Fn.join('', ['execute-api:/', '*'])],
        conditions: {
          "StringNotEquals": {
            "aws:sourceVpc": vpc.vpcId
          }
        }
      })
    ]
  })
});

Summary

Since it took us a couple of hours to figure this all out, we hope that with this article we can help you get your CDK application up and running faster.

As the fragments are copied out of a much more complex application, we cannot guarantee that an error has not crept in. If something is not working properly or you have any additions, we would appreciate it if you let us know.

Best regards and happy coding.

Andy / cloudxs