This is an annotated server.config.yaml with complete explanations
for all options currently available.
The values you see are the default values that will be used when the
option is omitted.
This is the version of the Velociraptor binary used to generate
this configuration file. It simply annotates the produced file and
can not be changed. When Velociraptor loads the configuration file,
this field will be updated so for example `velociraptor config
show` will update this to the present version.
The Client block will be copied into the client.config.yaml and it
is expected to be used by clients. It contains no secrets and can
be embedded into clients. The server must also have this block as
it needs to refer to client specific information sometimes.
These are the root CA certs the client will trust. This is
needed when going through a MITM proxy. Certificates are in PEM
format one after the next. Certificates do not have to have the
CA basic constraint!
Clients may connect to servers which use a self-signed certificate.
This list allows to specify a set of certificate thumbprints (SHA256)
which are used to validate TLS server certificates.
Fingerprints can be generated with the OpenSSL command line utility:
openssl s_client -connect www.google.com:443 < /dev/null | openssl x509 -fingerprint -sha256 -noout
Certificate thumbprints may or may not include colon characters. Capitalization
of the hex digits is ignored by Velociraptor. A thumbprint of any of the
forms used below (or combinations thereof) is fine.
Velociraptor supports several ways of verifying TLS certificates. The
certificate_verification_mode specifies which of the three modes is applied.
Currently, three modes are available:
PKI (the default):
verify TLS certs against public CA lists, the list of additional root_certs (see above),
and the built-in CA cert
PKI_OR_THUMBPRINT:
the same as PKI with the addition that certificates which have a thumbprint that is
present in certificate_thumbprints will be accepted as well
THUMBPRINT_ONLY:
Velociraptor only accepts certificates which have a matching thumbprint in
certificate_thumbprints. All other certificates will be rejected. This mode is
also known as certificate pinning.
By default velociraptor uses TLS 1.3 to secure it's
communications. Some networks use a MITM TLS proxy which does
not support more secure protocols so this setting can be
applied to make the server allow lower TLS versions.
A list of one or more URLs the clients will try to connect
to. When all connections fail the client will back off for a
while. Clients will choose one of these at random so it is a good
way of acheiving fault tolerance and load balancing.
A URL to a proxy that will be used to connect to the server. Some
environments have egress filtering requiring Velociraptor to use
a proxy to be able to reach the server. NOTE: We do not support
PAC based proxy configurations or Windows domain authentication -
you might need to add an allow rule to the proxy config to allow
the Velociraptor server URL without authentication.
The Internal Velociraptor CA certificate used to verify the
server certificates. Do not change this! This will be generated
by the config wizard and can not be replaced. It is only used
internally.
-----BEGIN CERTIFICATE-----
Generated by the config wizard!!!
-----END CERTIFICATE-----
This is a shared secret between servers and clients. The server
will refuse to communicate with clients having the wrong nonce.
The nonce is used to group clients into Org Groups - so clients
from different orgs have different nonce.
The following are the locations to write the writeback file- this
file is used to keep client state (See Writeback section). In the
default configuration, writeback files persist across
uninstall/reinstall cycles to keep the client id consistent. If
you don't want this you can change the location of the writeback
to be inside the inside the tempdir_windows directory (it will be
removed on uninstall).
This is the directory Velociraptor will use for temporary
files. If not specified or not writable, Velociraptor will use
the $TMP or $TEMP env variable.
Number of seconds to wait before polling. Typically Velociraptor
connections are persistent but will force a re-connection every
max_poll seconds to refresh the connection. NOTE that typically
Velociraptor reuses TCP connections so this only applies to the
HTTP transactions, i.e. The TCP connections are always up.
If this is set, the nanny will exit if we are not able to send
messages to the server within this many seconds. NOTE - even a
failed connection will reset the counter, the nanny will only fire
if the client has failed in some way - e.g. the communicator is
stopped for some reason
The default max time to wait before we send partial VQL
results. This setting is used to ensure we dont send too many
small requests by batching the rows into time batches.
Maximum number of concurrent queries the client will allow
(default 2). This ensures we do not overwhelm the client by
scheduling too many concurrent queries. NOTE: Queries marked as
URGENT will skip this control and run anyway.
If set the client will hard exit when it uses this much memory (in
bytes). This is a safety feature to prevent runaway process -
ensure this is not set too low.
Clients will send a Server.Internal.ClientInfo message to the
server every this many seconds. This helps to keep the server info
up to date about each client. This should not be sent too
frequently. The default is 1 day (86400 seconds).
When a collection starts on the client, the client writes a
checkpoint file so it can detect when it crashed previously and
restarted. If this option is set we disable client checkpoints
and so we can not report to the server when the client crashes
while collecting an artifact.
These settings are used by the `velociraptor service install`
command. We typically do not use this as we prefer to distribute
MSI packages via package management systems.
If this setting is true, Velociraptor will expect the server to
use self signed TLS certificates. The client will verify the TLS
connection by checking that the server certificate is signed by
the Velociraptor internal CA. With this setting it is possible to
use an IP address for the server URL (not recommended though)
It is possible to pre-label clients using the configuration
file. The server will add these labels to the clients
automatically upon enrollment. This allows different client
packages to be distributed in the real world and have them
automatically identified.
Velociraptor keeps a local buffer file to store query results
while they are being shipped across the network. There are two
types of buffers - an in memory buffer and a local file based
buffer file. When the buffer is exceeded the query is paused so
it is important to have reasonable size available for the buffer
file to prevent queries taking too long (and possibly timing
out).
This section configures the API service. The API server accepts
connections from the GUI gRPC gateway, as well as connections from
the gRPC API clients (e.g. with pyvelociraptor).
This is the hostname used to connect to - it is used here to copy
into new api client configuration files to assist gRPC API
connections (e.g. pyvelociraptor).
Do not change this. It is the common name of the certificate that
will be trusted to be from the GUI. ACL checks will be disabled
for all connections from this name.
Allows the GUI to start with no encryption - **WARNING** This only
makes sense if you have TLS proxy in front. In fact the GUI **will
not work** without a TLS proxy because the CSRF cookie is still
set to secure only.
A list of CIDR addresses from permitted networks. If this is not
set, permit all connections to the GUI from anywhere. This is
useful when you want to limit access to the GUI by IP address but
still allow access to clients from any IP, while running both the
frontend and GUI on the same port (normally port 443)
Header defined by the proxy containing the remote address. This
header will be used in the allowed_cidr matching if specified.
NOTE: Only use this if you do have a reverse proxy in front of
the server. Otherwise an attacker can simply send this header
to pretend to come from any IP address. If this setting is
specified we take the src address from the header, otherwise
from the remote IP address. Default is not set.
The type of links. Currently:
sidebar: This link will appear in the sidebar navigation menu
context: Will appear as part of the context (right click) menu
For context menu the value in the cell can be relayed to the
target URL. This setting controls the encoding of the value
and the parameter to attach it to.
Bind the GUI to this port. By default: For self signed SSL the
GUI will be bound to the localhost only! For Let's Encrypt
deployments the GUI will be bound on 0.0.0.0 making it accessible
from anywhere.
When the Velociraptor server starts for the first time, the
server can create the following initial user with admin level
access. This is designed to automate deployment and allow users
to sign in immediately to the GUI. You can remove these accounts
or change their ACLs/Roles later.
Name of this authenticator to show in the GUI (e.g company
name). Note that you can provide many OIDC authenticators as
part of the multi authenticator so having a name here helps keep
them recognizable.
Certs authenticator: If a user presents a certificate but does
not exist in the system, the user will automatically receive a
default role. If this is not set the user will be rejected and
you will have to manually add the user to a role before they are
allowed.
This is the internal Velociraptor CA configuration. It is needed to
sign new API keys. Secure deployments can remove this part of the
config and safely store it offline.
This allows the frontends to listen on plain HTTP - It is useful
if you have SSL offloading (e.g. ngix). This is not configured by
the wizard - you will need to manually configure it. You better
know what you are doing here!
A proxy setting to use - Velociraptor needs to connect to download
tools. This setting will force it to go out over this proxy. NOTE-
If you dont want to allow outbound connections, just set this to
an non existent setting (e.g. http://127.0.0.1:3128).
These are used to secure the client/server communications - Even
when using external TLS certificates! This certificate must be
signed by the Velociraptor root CA in all cases
(tls_certificate_filename for that). If using an external TLS
configuration this layer of encryption happens **in addition** to
the external TLS certificates.
If you want to use your own certificates for TLS as an alternative
to Autocert, then you can set those here. These certificates will
be used for TLS on both the frontend and GUI. NOTE: We expect
these to be proper certificates - i.e. NOT self signed. If you
want to use certificates issued by another CA you will also need
to add that CA cert to the Frontend.Crypto.root_certs and
Client.Crypto.root_certs field.
Be sure to set Client.use_self_signed_ssl=false when you set this.
If configured, Velociraptor will attempt to update the dynamic
DNS server with its public IP address. Currently we only support
Google Domains although other providers may also work.
Header defined by the proxy containing the remote address. If this
is not set we use the remote IP address from the TCP
connection. This setting is needed if you have a reverse proxy in
front of the server.
The user that the frontend should run as. If set we refuse to run
as a different user. This is normally set by the ubuntu deb
package as it is running as a low priv user called
"velociraptor". This setting is important as it stops users from
running velociraptor as root with sudo - doing this will break the
velociraptor datastore when it creates files only readable by
root.
A regular expression that if matches any log messages from the
client's query represent a failure of the collection. Marking the
collection as failed can highlight potential problems with the VQL
so this regex tries to detect common issues (e.g. Symbol not
found) to draw attention to failures.
Sets resource limitations on the server. These parameters
represent the set of tunable parameters you can use to optimize
performance on loaded servers.
The rate at which we notify clients of new work (e.g. a new hunt
is started). Slower notification rate helps to slow dows the
swarm effect and reduced load on the server.
The maximum number of concurrent client connections we can
process. Concurrency limits helps to ensure the server is not
overloaded serving too many clients at the same time.
Concurrency refers to the actual serving time of a client
(i.e. time taken to read the response and write to the
datastore), not the total number of clients served by
server. Default is number of cores * 2.
The maximum time a client will be waiting for a concurrency slot
before timing out. A small value will result in many
reconnections under load and may degrade performance.
This setting controls the size of various LRU caches in the
frontend (e.g. the session key cache, client info cache). This
number should be larger than the number of actual clients or
else the system will see high CPU load from cache misses.
Bandwidth control: Per client and global rates in
bytes/sec. This is useful for low bandwidth deployments where we
want to ensure Velociraptor does not saturate slow links. The
bandwidth limitation caps the total bandwidth used by the server
per client and globally.
Wait time for collecting events from clients - smaller means
less latency to respond to client events but also means more
TLS handshake and network overheads due to frequent POST.
Minions batch updates to the master so as to minimize RPC as
much as possible, this controls how often these batches are
flushed to the master (default 10 sec).
Number of seconds before expiring client info cache
entries. Default (0) means do not expire at all. Expiring
client info from cache too frequently can result in a lot more
IO. Default size of this cache is the expected_clients above.
The journal files are used to queue messages between event
generators and event consumers when the consumer is unable to
drain these quickly enough. The setting specifies the maximum
size of the file - when it is exceeded, the file will be
truncated and events will be lost. Default is 1gb
Larger result sets and uploads are stored in the
filestore_directory. This is usually the same as the location
setting but it can be different to keep larger slower storage
options away from smaller and faster data.
When using a master/minion setup it is necessary to have the
Master and Minion nodes use different filesystem
implementations. These more specific parameters can control
datastore implementations on the master and minion separately.
Cap directories to this size after reporting error - this should
not happen normally but may happen if the deployment has been very
active or due to a bug!
Set to the min required disk space. When we fall below this
available disk space, we refuse to write files. This avoids the
possibility of writing corrupted files. Default is 50mb. Set to -1
to disable disk space monitoring.
How many mutations to queue up ahead of busy writers. By
default 0 means writes will be blocked until they are handed
off to a writer thread. Set to -1 to disable asynchronous
writes.
The MemcacheFileDataStore separates writers into a writing
pool. These set the number of writer threads in that pool.
Number of writing threads - increase for high latency
filesystems (default 100).
How long to delay writes so they can be combined. This applies for
writing result sets - we keep the writes in memory for min_age
seconds in order to combine further writes. If another write
occurs to the same result sets the TTL is extended and writes are
delayed. However, once we reach max_age, a write is forced. The aim
is to keep combining separate writes as much as possible into larger
writes but at the same time prevent frequently written files from
never flushing to disk.
MemcacheFileDataStore will cache small files in memory to improve
efficiency. This is the maximum size of the cache.
Maximum size of memcache lru (default 10000)
If this is set the logs will be separated into different
components (eg. Frontend, GUI, Audit etc). This makes it easier
to find the source of the log messages
This controls the Monitoring server (i.e. Prometheus) If you have a
monitoring service like Grafana or Data Dog then change this server
to bind to 0.0.0.0 and point your scraper at it.
When starting without any command line parameters, this argv array
will be used as if it was typed on the command line. This is a way
to get Velociraptor to automatically execute a function as
startup when used without parameters.
Load these artifact definitions into the binary at startup. NOTE:
These definitions are considered "built-in" which will ensure they
can not be modified at runtime.
The format of these fields is an artifact definition - so the
following description also covers artifact definitions more
generally.
Artifacts can specify third party tools to load. Velociraptor
will attempt to fetch these tools when a user wants to collect
this artifact. Velociraptor will push the tool to the endpoint
so the artifact may use it.
As an alternative to a url we allow scrapping of GitHub
releases using the github API. NOTE: When this method is
specified, the file will always be served locally.
Once the tool is added with the above fields, the following
fields are used to keep state on it.
The URL we serve the tool from when we serve locally. If this
is empty we just let the endpoint download its own tool from
the url above.
The name of the cached file on the endpoint. This file will
persist and can be accessed again if this tool is needed in
future. If the file is missing (or has the wrong hash), then it
will be downloaded again.
If the artifact specifies a precondition the client will
evaluate this query before evaluating the main artifact. If the
precondition returns no rows (ie. FALSE) then the artifact will
not be collected. You can use the precondition to protect
incompatible clients from collecting the artifact (usually the
OS condition).
A default value for the parameter. NOTE: Parameters are
always strings so this field needs to be the string
representation of the type - e.g. "10" rather than 10.
The type of this parameter. Currently one of:
string, regex, yara, upload, int, int64, integer, timestamp,
csv, artifactset, json, json_array, bool, choices
This is used to obfuscate artifact names when sending to the
client. NOTE: This is currently not very robust - i.e. it does not
hide the artifact names very well - you should not name artifacts
in a sensitive way.
Normally notebook queries timeout in 10 minutes (can not be
changed from within the notebook). This is done to reduce load on
the server. If you want to increase notebook timeout you can
change this.
When running on a shared server notebook calculations can
increases memory use and affect other users. The following
settings control notebook calculations to ensure they do not use
too much memory. You should set the following in accordance with
the VM settings of the server with a small margin of safety.
When calculating a new cell we do not start calculation until the
process memory is smaller than the low memory mark.
If set we actively notify all clients as soon as event table is
changed. This causes a lot of load on large deployments so it is
off by default. It means that you will need to wait for the client
to reconnect before it receives updates to its event table
(usually about 5 min). When running `velociraptor gui` we set this
to true in order to get a responsive GUI.
When viewing the VFS on a client we create objects in the data
store to facilitate the GUI navigation. If the directory is too
large the GUI performance suffers so we truncate the directory at
this size (default 1000 files).
The number of rows to keep in memory during a group by
operation. Once this is exceeded we switch to disk mode which
is a lot slower but has no memory limitations. Default 30000
If these are set we enforce VQL to only have the specified allowed
VQL plugins and functions. This is a way to harden the server by
removing potentially sensitive functionality to allow only
approved VQL plugins to run.
The Velociraptor server may be placed into "lockdown" mode. While in
lockdown mode certain permissions are denied - even for
administrators. This additional protection mode helps to mitigate
the case when a Velociraptor administrator's account is
compromised. The server can be taken out of lockdown mode by setting
lockdown to false and restarting the server.