Install Docker SWAG with open-appsec (locally managed)
open-appsec Docker SWAG integration is currently in "beta".
Prerequisites:
Linux machine with:
Docker and Docker Compose installed
Root Permissions
Deployment:
To deploy SWAG with open-appsec integration and manage open-appsec locally (declarative management) follow the steps below:
From within the directory which you want to use for the deployment: Download the initial declarative configuration file for open-appsec into new subfolder
./appsec-localconfig
:
Create a docker-compose.yaml file with the content below, it can be downloaded as follows:
Here's the content of the docker-compose.yaml file:
If you migrate from an existing Docker SWAG deployment to Docker SWAG with open-appsec make sure to make all adjustments you did in your existing docker-compose.yaml for SWAG also in the one above before deployment.
Also make sure to copy your existing SWAG configuration folder contents into ./swag-config
on the docker host.
Run the docker compose:
You will see output similar to the below:
Verify that “appsec-agent” and “swag-attachment” containers are both up and running by verifying their status in docker ps output:
Configure SWAG’s NGINX reverse proxy to forward traffic to your backend webserver(s). (if you don’t have experience with this, see SWAG docs: SWAG - LinuxServer.io)
To verify if the SSL certificate was successfully issued by Let's Encrypt you can use the following command to show logs of the swag-attachment container:
If certificate was successfully generated in Let’s Encrypt staging mode (recommended for testing, this will generate a non-trusted certificate only but allows for more failed validations before blocking for certain time) you should now change the following line in the docker-compose.yaml file (in the swag-attachment container specification) to disable staging mode and receive a valid, trusted certificate from Let’s Encrypt: Old value:
- STAGING=true
New value:- STAGING=false
Redeploy to apply the changes:
As SWAG also contains fail2ban as an additional security layer, you can check the fail2ban status and enabled “jails” as follows:
Output should be similar to the following, showing the fail2ban is setup with 5 jails by default:
You can read more about fail2ban here: fail2ban/fail2ban: Daemon to ban hosts that cause multiple authentication errors (github.com)
Congratulations, you have successfully deployed SWAG Secure Web Application Gateway integrated with:
open-appsec WAF for automatic, machine learning-based threat prevention
Let’s Encrypt SSL certificate
fail2ban preventing different types of brute-force attacks
Now all HTTP(S) requests that SWAG’s integrated NGINX proxy will forward to your backend web server(s) will be first automatically analyzed and protected by the open-appsec WAF.
Recommended next steps:
Connect your existing locally managed Docker SWAG with open-appsec deployment to the central open-appsec WebUI at https://my.openappsec.io: Connecting your deployment to the open-appsec central WebUI provides many benefits. Using the WebUI (SaaS) is optional and included in all editions, including open-appsec free community edition.
- Central WebUI for viewing/managing all open-appsec configuration and functionality
- Store and view your open-appsec security logs
- Monitor your open-appsec deployments
- Monitor learning status of each of your protected assets
- See learning progress and status
- Receive and manage tuning suggestions
- Get cloud-based shared learning between multiple agents (e.g. in HA scenario) You can find detailed instructions how to do this here: How to connect locally managed Docker SWAG with open-appsec to WebUI
You can check open-appsec agent status by running:
You will see output similar to the below:
Verify that open-appsec is preventing attacks: a) Make sure the SWAG NGINX reverse proxy is properly set-up to point to some web application backend (see more details here). The NGINX configuration for the SWAG container is located here (on docker host): ./swag-config/nginx/site-confs/default.conf (and in SWAG container it’s here: /config/nginx/site-confs/default.conf ) Note that for the following simulated attack you can also just run it against the default webpage SWAG returns after deployment and skip this step. b) Run following curl request to simulate an attack (replace with your SWAG container DNS name and Port)
Note: “-k” was added above so this would work even when still using a Let’s Encrypt “staging” certificate. You can alternatively use your web browser, just open the following URL:
If your policy is set to prevent in the local configuration file (default in the file used when following this guide), the request will be blocked with error 403 shown, otherwise it will be detected and you will only see it in the security logs.
c) You can view the resulting open-appsec security logs by running:
If required you can further configure open-appsec WAF’s settings using open-appsec’s local declarative policy, see docs for the local policy file configuration options here:
Last updated