Known weaknesses and caveats

There is currently no significantly advanced validation except that it builds, and the packages it draws from are unlikely to break without us knowing. This doesn't validate the efficacy of the tools in this container yet; it may be something added later.

ToDo

• Add actual testing other than just compiling staging tests.
• Safely add known virus files to the repository for scanning during e2e testing.
• Consider a consistent reporting system for e2e tests like this.
• Enact quarantine measure tests as well.

Disclaimer

You will also need to understand what a virus scanner's scope is; it is not an assertion that the machine is now considered safe after a scan. It's predominantly a measurement tool at best. It increases observability and allows some actions to be taken on detectable things. They aren't a tool for promising that a system is safe going forward. The IT staff should always consider the level of remediation steps needed to be taken at the time of positive detection.

Considerations

Do understand that when something is out of specification in a server, this is like 90% confidence to be working regularly. This tool can periodically scan a system's files in a way that should be less obvious to advanced attackers and less likely to be modified on a system as docker containers are cryptographically signed and jailed away from typical user space. The tool offers a run mode that can be used to enact quarantine measures. It is theoretical as it has not been actively tested in the current state. However, it's only a convenience function as you can pull which files to erase from the scan logs.

Usage

Create a directory and put this compose file mkdir -p /root/clam/

then nano /root/clam/docker-compose.yml

docker-compose.yml

version: '3.8'

services:
  clamav:
    image: git.nixc.us/colin/clam:production
    read_only: true
    volumes:
      - /:/scan
      - ./logs:/var/log/clamav
      - ./quarantine:/quarantine
    tmpfs:
      - /tmp
    deploy:
      resources:
        limits:
          cpus: '0.50' # Limit to 50% of a CPU
          memory: 512M  # Limit to 512 megabytes

Put this container in the crontab

crontab -e

Then add one of the below cron examples.

Once a Week

To run the job every Sunday at midnight:

0 0 * * 0 /usr/bin/docker compose -f /root/clam/docker-compose.yml up -d --pull --force-recreate clam

Once Every Two Weeks

Cron does not natively support a bi-weekly schedule directly. However, you can achieve this by specifying two days of the month, such as the 1st and 15th:

0 0 1,15 * * /usr/bin/docker compose -f /root/clam/docker-compose.yml up -d --pull --force-recreate clam

Once a Month

To run the job on the first day of every month at midnight:

0 0 1 * * /usr/bin/docker compose -f /root/clam/docker-compose.yml up -d --pull --force-recreate clam

Notes:

• Ensure that /usr/bin/docker is the correct path to your Docker binary. This path might vary depending on your system's configuration.
• Replace /root/clam with the actual directory path where your docker-compose.yml file is located.
• These cron jobs will pull the latest image and recreate the clam container according to the specified schedule. Ensure that this behavior aligns with your maintenance and update policies.