82 lines
3.4 KiB
Markdown
82 lines
3.4 KiB
Markdown
<!-- # build:0 -->
|
|
# 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
|
|
|
|
```yaml
|
|
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:
|
|
|
|
```cron
|
|
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:
|
|
|
|
```cron
|
|
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:
|
|
|
|
```cron
|
|
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.
|