Document that a firewall is required
jonathanf opened this issue · comments
Updated description
Some services configured by this repository listen insecurely on public interfaces. There's an assumption from AWS that the hosting provider has a firewall which blocks all public access, by default, until the administrator opens specific ports. That's clearly not true for some major providers like DigitalOcean.
We should:
- Document that a firewall blocking public access to all ports except 80 and 443 is absolutely required
- If possible, change the network configuration so that nothing except NGINX accepts connections on a public interface.
Original report
Hi,
In past days, I deploy a KoboCollect server in a droplet in DigitalOcean, now forward a security issue report for your consideration:
Hi there,
We've received a notification from 3rd party security researchers, the Shadowserver Foundation, that your Droplet at xxx.xxx.xxx.xxx is running a Redis instance configured in a way that may be insecure.
This configuration that was reported to us can allow attackers to gain local access to your Droplet, as well as the ability to read, change, or destroy any data hosted in your Redis instance. This issue could result in severe security breaches, and we strongly urge you to take immediate action to secure your Redis instance. We have several resources available to help you secure your server.
For securing your Redis instance on Ubuntu, refer to this tutorial: https://do.co/redis-security-ubuntu-1404
For securing your Redis instance on CentOS, refer to this tutorial: https://do.co/redis-security-centos-7
We also offer Cloud Firewalls – available in all regions at no additional cost – to protect your Droplet from traffic attempting to access it without permission. Learn more about Cloud Firewalls here: https://do.co/intro-to-cloud-firewalls
The security of all systems in our network is extremely important to us and we strongly encourage you to review your configuration promptly.
Regards, Security Operations Center DigitalOcean
considering also the fact that:
- ubuntu server default firewall solution (UFW) and docker don't go well together (docker export rules are applied before firewall filter rules) so the open ports would be accessible even with a filter-all UFW rule
- to overcome the previous problem an hack has to be applied to iptable rules
- I've tried to modify the .override.yml after --setup to avoid containers talking to each other through the host bridge (.private aliases) but I failed on my first try just by editing *.override.yml files.
it means that kobo-docker is a no-go on a single server full-stack solution without an external firewall
I do understand that the exposed ports are for HA setup, but I'd consider to ask user in kobo-install first
Hi, I'm having the same problem but with the MongoDB container (such as issue # 250).
I ask: Is there any progress or solution to this problem? I have a kobotoolbox installation and DigitalOcean sends me emails every time indicating that the MongoDB installation is unsafe.
Hi,
We were having the same issue on our production server and fixed it by making some small changes on both docker-compose...overwrite.yml files.
Our solution is to explicitly put all containers in the same network instead of one network for the front and one for the back.
Just be sure to use the proper internal domain names used by the frontend containers in the aliases section.
The only issue now is that run.py --stop
doesn't remove the fontend containers anymore, you need to stop them manually
# docker-compose.backend.master.override.yml
# For public, HTTPS servers.
version: '2.1'
networks:
kobo-fe-network:
driver: bridge
services:
postgres:
# ports:
# - 5432:5432
networks:
kobo-fe-network:
aliases:
- postgres.kobo.private
mongo:
# ports:
# - 27017:27017
networks:
kobo-fe-network:
aliases:
- mongo.kobo.private
redis_main:
# ports:
# - 6379:6379
networks:
kobo-fe-network:
aliases:
- redis-main.kobo.private
redis_cache:
# ports:
# - 6380:6380
networks:
kobo-fe-network:
aliases:
- redis-cache.kobo.private
# docker-compose.frontend.override.yml
# For public, HTTPS servers.
version: '3'
services:
kobocat:
environment:
- ENKETO_PROTOCOL=https
- KC_UWSGI_WORKERS_COUNT=2
- KC_UWSGI_CHEAPER_WORKERS_COUNT=1
- NGINX_PUBLIC_PORT=80
- KC_UWSGI_MAX_REQUESTS=512
- KC_UWSGI_CHEAPER_RSS_LIMIT_SOFT=134217728
kpi:
environment:
- KPI_UWSGI_WORKERS_COUNT=2
- KPI_UWSGI_CHEAPER_WORKERS_COUNT=1
- NGINX_PUBLIC_PORT=80
- KPI_UWSGI_MAX_REQUESTS=512
- KPI_UWSGI_CHEAPER_RSS_LIMIT_SOFT=134217728
- SECURE_PROXY_SSL_HEADER=HTTP_X_FORWARDED_PROTO, https
nginx:
environment:
- NGINX_PUBLIC_PORT=80
ports:
- 8080:80
networks:
kobo-fe-network:
aliases:
- kobo2.kobo.internal
- kobocat.kobo.internal
- enketo.kobo.internal
enketo_express:
networks:
kobo-fe-network:
external:
name: kobo-docker_kobo-fe-network
@JVLance, as you may know, we are a small team and we have a lot to do.
We don't have any ETA to provide but we want to find a reliable solution and release it as soon as we can.
Maybe you can get some help from other users at https://community.kobotoolbox.org/c/kobo-install.