This Dockerfile provides an instance of CRITs behind uWSGI. This image merely wraps CRITs up for those who want to deploy via Docker. In order to fully deploy CRITs, you will have to provide your own MongoDB server, as well as a reverse proxy such as nginx or Apache HTTP Server.
- CRITs web application is served via uWSGI.
- Dependencies for most CRITs services have already been installed, making them available for your usage.
- Does not add any user accounts.
- Does not install any SSL certificates.
- Does not provide MongoDB.
- tcp/8080 - http-socket - uWSGI native HTTP-socket protocol
- tcp/8001 - uwsgi-socket - uWSGI Socket protocol
Dependencies for the following services have been installed, so they are available for usage. Some of them require a bit more configuration, as CRITs does not provide a way to configure services from the CLI.
Configuration settings you'll need to change:
- basedir: /data/chopshop
Configuration settings you'll need to change:
- basedir: /data/chopshop
The following have not been enabled, yet, for one reason or another.
Just want to take CRITs for a spin? Try out our development environment.
NOTE: under no circumstances should this procedure be used as a short-cut to a production deployment. Rather, it was created simply as a means to make development of this Docker image easier. Following this procedure will result in an instance of CRITs with the following security issues:
- SSL is disabled.
- Session cookies do not have the 'secure' attribute.
- CRITs will have an empty SECRET_KEY.
git clone https://github.com/justfalter/docker-crits.git
In the root of the source tree, bring up the environment using docker-compose:
docker-compose up -d
It's usually something like dockercrits_crits_1. You can find out by running the following:
docker-compose ps
You can find details on how to add a user here.
You can log into your new CRITs instance at http://localhost:8080.
That's it!
A production environment should consist of the following:
- A MongoDB server instance.
- An SSL-enabled HTTP service that acts as a reverse proxy for your CRITs application container.
- The CRITs application container.
The CRITs wiki already has information on setting up a production-grade CRITs install, so please read that over.
There many sources on the internet for installing MongoDB. Just know that the MongoDB server will be running outside of the CRITs application container.
Security consideration: Make sure that your MongoDB server is not accessible outside of your network.
You may know this already, but Docker makes it pretty easy to set up a MongoDB container. I'm not suggesting that this is the best way to run MongoDB, but it certainly is a way.
Create a data-volume-only container for MongoDB:
docker run -d --name crits_mongodb_data mongo:2.6 /bin/true
Note: The data-volume-only container will exit, immediately, which is to be expected. Despite this, fight the urge to delete it, as this is where your MongoDB data resides. It exists to make it easier to upgrade to a new version of MongoDB without having to worry about losing all of your data. It might be hard to wrap your head around at first, but if you spend any amount of time working with Docker containers, you'll appreciate the value of using a data-volume-only container.
Now, we create the actual MongoDB container. Replace IP_ADDRESS with the IP address of one of your network interfaces (such as eth0). This will be the same IP address that we configure CRITs to use when for communicating with MongoDB.
docker run --restart="always" -d --name crits_mongodb --volumes-from=crits_mongodb_data -p IP_ADDRESS:27017:27017 mongo:2.6
Security consideration: Make sure that your CRITs application container service is not accessible directly accessible outside of your network. It should only be accessible via the secured reverse proxy.
Security consideration: Traffic between the reverse proxy and the CRITs container is not encrypted. Be mindful of the networks that your data is traversing!
- Make a directory somewhere on your Docker host computer that will contain the CRITs configuration file(s).
mkdir /opt/crits-config
- Copy config/database_example.py to your, but name it database.py.
cp config/database_example.py /opt/crits-config/database.py
- Edit database.py, following the instructions within. Minimally, you'll be editing MONGO_HOST and SECRET_KEY. You can find some additional information about this here: CRITs wiki instructions on editing database.py. Save your changes to database.py before moving on.
Now we start up the CRITs container. We'll be mounting the configuration directory we created, earlier, as /config within the container. Replace IP_ADDRESS with the IP address of one of your network interfaces (such as eth0). This will be the IP address that you will provide to your reverse proxy, later on.
If you intend to proxy via the HTTP protocol, then expose TCP port 8080. If you intend to use the uWSGI's socket protocol, expose TCP port 8001.
docker run --restart="always" -d --name crits --volume /opt/crits-config:/config -p IP_ADDRESS:8080:8080 justfalter/crits:latest
Security consideration: Make sure that the IP address that you bind the CRITs application container to is not publicly accessible!
If you ever need to make any changes to database.py, just edit the file within the your configuration directory (ex: /opt/crits-config/database.py), and restart the CRITs container.
See Creating the default collections for MongoDB.
See Adding a user.
Now, you'll set up your reverse proxy. It's up to you as to what you use as a reverse proxy. You can find an example of using nginx in within contrib/nginx.
Regardless of what you use as a reverse proxy, you should always keep the following things in mind:
- It communicates with your CRITs application using plain HTTP. Configure it to talk to the CRITs container's IP and port-number that you assigned, earlier.
- It only accepts HTTPS traffic on the public side. If your reverse proxy is not using SSL, then the sessionid cookies that CRITs creates will not work, as they have the secure flag on them.
- Be sure to bump up the maximum upload/POST size to 1 gigabyte (or whatever you want to be the upper-bound for uploads).
- It must send set the following HTTP headers when passing requests to the CRITs container:
- Host - this must be the original Host HTTP header that was requested of the reverse proxy. Failing to set this will result in the browser redirecting to weird places.
- X-Forwarded-Proto - this should be https, matching your reverse proxy's protocol.
- X-Forwarded-For - This relays to the CRITs all the proxies that the request has passed through, but more importantly the original IP address of the client making the request. This is important if the audit logs are to be accurate.
Some of the initial configuration of CRITs occurrs via the command-line, usually with the manage.py script. Since CRITs is running within a Docker container, you'll have to do things slightly differently.
The working directory of your CRITs container is /data/crits. In this directory, you'll find the ever-so-useful manage.py script. Running this script is pretty simple:
docker exec -ti CRITS_CONTAINER_NAME python manage.py
Just replace CRITS_CONTAINER_NAME with the name of your CRITs container.
This should only be run once, when you initially set up CRITs.
docker exec -ti CRITS_CONTAINER_NAME python manage.py create_default_collections
Addding an administrator user:
docker exec -ti CRITS_CONTAINER_NAME python manage.py users --adduser --administrator --username USERNAME -e EMAIL_ADDRESS
When this command succeeds, it'll spit out a temporary password for the account.
If you don't want to add an administrator, simply remove the --administrator from the command.
docker exec -ti CRITS_CONTAINER_NAME python manage.py users --reset --username USERNAME
Dropping the mongodb data:
docker exec -ti crits_mongodb mongo crits --verbose --eval "db.dropDatabase()"