I'm running an application called Ambar on a (Samba)fileserver. I want users in my network to be able to search for documents freely, and securely. Since Ambar runs on HTTP, and the server already has Apache on it from before, I decided to set up a reverse proxy to Ambar through port 443. Should be quite straight-forward, one might think, but no, apparently Ambar (running on Redis) says the following:
Possible SECURITY ATTACK detected. It looks like somebody is sending POST or Host: commands to Redis. This is likely due to an attacker attempting to use Cross Protocol Scripting to compromise your Redis instance. Connection aborted.
(taken from docker-compose logs).
I can reach the app's GUI, but I can't do anything there. That's a good thing anyway, since at least I know it's not a certificate issue..
This is my Apache-config:
LoadModule ssl_module modules/mod_ssl.so
<VirtualHost *:443>
ServerName ambar.internal
ProxyPreserveHost On
ProxyPass / http://ambar.internal:1000/
ProxyPassReverse / http://ambar.internal:1000/
SSLEngine on
SSLCertificateFile /etc/ssl/certs/ambar.crt
SSLCertificateKeyFile /etc/ssl/private/ambar.pem
</VirtualHost>
Edit: reverse-proxying with SSL/TLS activated from another machine does not work either.
Making manual modifications of Ambar packages isn't a great idea as the whole app comes with ready Docker containers. So my next attempt is to set up SSL in the docker-compose.yml
file, but shouldn't there be a way to accomplish this with good-ol' reverse proxying?
Here is my docker-compose.yml:
version: "2.1"
networks:
internal_network:
services:
db:
restart: always
networks:
- internal_network
image: ambar/ambar-mongodb:latest
environment:
- cacheSizeGB=2
volumes:
- /opt/ambar/db:/data/db
expose:
- "27017"
es:
restart: always
networks:
- internal_network
image: ambar/ambar-es:latest
expose:
- "9200"
environment:
- cluster.name=ambar-es
- ES_JAVA_OPTS=-Xms2g -Xmx2g
ulimits:
memlock:
soft: -1
hard: -1
nofile:
soft: 65536
hard: 65536
cap_add:
- IPC_LOCK
volumes:
- /opt/ambar/es:/usr/share/elasticsearch/data
rabbit:
restart: always
networks:
- internal_network
image: ambar/ambar-rabbit:latest
hostname: rabbit
expose:
- "15672"
- "5672"
volumes:
- /opt/ambar/rabbit:/var/lib/rabbitmq
redis:
restart: always
sysctls:
- net.core.somaxconn=1024
networks:
- internal_network
image: ambar/ambar-redis:latest
expose:
- "6379"
serviceapi:
depends_on:
redis:
condition: service_healthy
rabbit:
condition: service_healthy
es:
condition: service_healthy
db:
condition: service_healthy
restart: always
networks:
- internal_network
image: ambar/ambar-serviceapi:latest
expose:
- "8081"
environment:
- mongoDbUrl=mongodb://db:27017/ambar_data
- elasticSearchUrl=http://es:9200
- redisHost=redis
- redisPort=6379
- rabbitHost=amqp://rabbit
- langAnalyzer=ambar_en
webapi:
depends_on:
serviceapi:
condition: service_healthy
restart: always
networks:
- internal_network
image: ambar/ambar-webapi:latest
expose:
- "8080"
ports:
- "8080:8080"
environment:
- uiLang=en
- mongoDbUrl=mongodb://db:27017/ambar_data
- elasticSearchUrl=http://es:9200
- redisHost=redis
- redisPort=6379
- serviceApiUrl=http://serviceapi:8081
- rabbitHost=amqp://rabbit
frontend:
depends_on:
webapi:
condition: service_healthy
image: ambar/ambar-frontend:latest
restart: always
networks:
- internal_network
ports:
- "1000:80"
expose:
- "1000"
environment:
- api=http://192.168.123.123:8080
pipeline0:
depends_on:
serviceapi:
condition: service_healthy
image: ambar/ambar-pipeline:latest
restart: always
networks:
- internal_network
environment:
- id=0
- apiUrl=http://serviceapi:8081
- rabbit_host=amqp://rabbit
documentation:
depends_on:
serviceapi:
condition: service_healthy
image: ambar/ambar-local-crawler
restart: always
networks:
- internal_network
expose:
- "8082"
environment:
- name=documentation
- ignoreExtensions=.{exe,dll,rar,s,so}
- apiUrl=http://serviceapi:8081
volumes:
- /media/Documentation:/usr/data
docker-compose.yml
? – Michael Hampton Apr 2 '19 at 15:36docker-compose.yml
-file. Ambar itself is running on port 1000, didn't want to mix it up with port 80. – Oleg Apr 2 '19 at 15:48docker-compose.yml
, but both are a little strange in that they expose ports that don't need to be exposed. All of the containers defined are always accessible to each other; ports that should be exposed are only those that need to be accessible from outside (like port 80 to reach the frontend or 8080 for the API). I'd start by removing unnecessary exposed ports. I would probably also raise an issue about the example with the developers. – Michael Hampton Apr 2 '19 at 16:40