Server configuration¶

Caldera’s configuration file is located at conf/default.yml.

If the server is run without the --insecure option, CALDERA will use the file located at conf/local.yml.

The existing default.yml¶

The YAML configuration file contains all the configuration CALDERA requires to boot up. An example configuration file is below:

port: 8888
plugins:
  - sandcat
  - stockpile
  - compass
  - terminal
  - response
users:
  red:
    admin: admin
    red: admin
  blue:
    blue: admin
api_key: ADMIN123
exfil_dir: /tmp
reports_dir: /tmp
crypt_salt: REPLACE_WITH_RANDOM_VALUE
app.contact.http: http://0.0.0.0:8888
app.contact.tcp: 0.0.0.0:7010
app.contact.udp: 0.0.0.0:7011
app.contact.websocket: 0.0.0.0:7012

A few key things to note:

Port: the port you serve CALDERA on
Plugins: the list of all loaded plugins. A plugin must be in this list to be available when CALDERA is running. Adding a plugin to this list will result in that plugin’s hook.py file getting called when CALDERA boots up.
Users: the username/password credentials of all accounts you want to access the CALDERA login page. Users can either be in the red or blue group.
API_KEY: a password to use when accessing CALDERA programmatically.
Exfil_dir: the directory to use when an ability exfiltrates files from the agent, sending them back to CALDERA. Any file(s) posted to the /file/upload endpoint will end up in this directory.
Reports_dir: the directory to save all reports when the server shuts down
app.contact.http: the http location you want HTTP agents (like Sandcat) to connect to.
app.contact.tcp: the TCP socket you want reverse-shell agents (like Manx) to connect to.
app.contact.udp: the UDP socket you want UDP agents (like Manx) to connect to
app.contact.websocket: the websocket port agents can connect to

Adding your own config file¶

By default, CALDERA will use the default.yml file that is included with CALDERA, but this can be overridden by taking by creating your own local.yml file and saving it in the conf/ directory. The name of the config file to use can also be specified with the -E flag when starting the server.

Caldera will choose the configuration file to use in the following order:

A config specified with the -E or --environment command-line options. For instance, if started with python caldera.py -E foo, CALDERA will load it’s configuration from conf/foo.yml.
conf/local.yml: Caldera will prefer the local configuration file if no other options are specified.
conf/default.yml: If no config is specified with the -E option and it cannot find a conf/local.yml configuration file, CALDERA will use its default configuration options.

Enabling LDAP login¶

CALDERA can be configured to allow users to log in using LDAP. To do so add an ldap section to the config with the following fields:

dn: the base DN under which to search for the user
server: the URL of the LDAP server, optionally including the scheme and port
user_attr: the name of the attribute on the user object to match with the username, e.g. cn or sAMAccountName. Default: uid
group_attr: the name of the attribute on the user object to match with the group, e.g. MemberOf or group. Default: objectClass
red_group: the value of the group_attr that specifies a red team user. Default: red

For example:

ldap:
  dn: cn=users,cn=accounts,dc=demo1,dc=freeipa,dc=org
  server: ldap://ipa.demo1.freeipa.org
  userattr: uid
  group_attr: objectClass
  red_group: organizationalperson

This will allow the employee user to log in as uid=employee,cn=users,cn=accounts,dc=demo1,dc=freeipa,dc=org. This user has an objectClass attribute that contains the value organizationalperson, so they will be logged in as a red team user. In contrast, the admin user does not have an objectClass of organizationalperson so they will be logged in as a blue team user.

Note that adding the ldap section will disable any accounts listed in the users section of the config file; only LDAP will be used for logging in.