Question About RITA Config Logs

[flaeckli]

Hello Everyone
I was Trying to install RITA with the defualt configuration, but when I run the command "test-Config" i Get the result "Failed to connect to database: no reachable servers"
The MongoDB is on the Same Server as the Rita Server. I was able to connecto to the mongoDB with mongosh.
In my Point of view there is Something wrong with the RITA Config.
I tried to find RITA Error Logs, but wasn't able to find them.
Can anyone provide me the path for it?
kind Regards

[Zalgo2462]

Hello, please post your RITA configuration file which is located at /etc/rita/config.yaml.

Please ensure that the connection string in that file (this line) matches the one you use to connect with mongosh

[daltonhamilton]

I have the same problem.

[daltonhamilton]

I also find it odd that when I run:
rita import ./2024-01-22/ test

that is does not create any log data in /var/lib/rita/logs
I have even set the log level to debug (3)

[daltonhamilton]

Here is my config.yaml.
I can issuse "mongosh mongodb://localhost:27017" and it connects and gives me the prompt.
Any ideas?

This section configures the connection to the MongoDB server and the database name to use

MongoDB:

See https://docs.mongodb.com/manual/reference/connection-string/

ConnectionString: mongodb://localhost:27017

Example with authentication. Be sure to change the AuthenticationMechanism as well.

ConnectionString: mongodb://xxxx:[email protected]:27017

Accepted Values: null, "SCRAM-SHA-1", "MONGODB-CR", "PLAIN"

Since Mongo version 3.0 the default authentication mechanism is SCRAM-SHA-1

AuthenticationMechanism: null

The time in hours before RITA's connection to MongoDB times out. 0 waits indefinitely.

SocketTimeout: 2

For encrypting data on the wire between RITA and MongoDB

TLS:
Enable: false
#If set, RITA will verify the MongoDB certificate's hostname and validity
VerifyCertificate: false
#If set, RITA will use the provided CA file instead of the system's CA's
CAFile: null

This database holds information about the procesed files and databases.

MetaDB: MetaDatabase

Rolling:

This is the default number of chunks to keep in rolling databases.

This only is used if the --numchunks command argument isn't supplied.

DefaultChunks: 24

LogConfig:

LogLevel

3 = debug

2 = info

1 = warn

0 = error

LogLevel: 3

LogPath is the path for Rita's logs. Make sure permissions are set accordingly.

Logs will only be written here if LogToFile is true

RitaLogPath: /var/lib/rita/logs

LogToFile: true
LogToDB: true

UserConfig:

Number of days before checking for a new version of RITA.

A value of zero here will disable checking.

UpdateCheckFrequency: 14

Filtering:

These are filters that affect the import of connection logs. They

currently do not apply to dns or http logs.

A good reference for networks you may wish to consider is RFC 5735.

https://tools.ietf.org/html/rfc5735#section-4

Example: AlwaysInclude: ["192.168.1.2/32"]

This functionality overrides the NeverInclude and InternalSubnets

section, making sure that any connection records containing addresses from

this range are kept and not filtered

AlwaysInclude: []

Example: NeverInclude: ["255.255.255.255/32"]

This functions as a whitelisting setting, and connections involving

ranges entered into this section are filtered out at import time

NeverInclude:
- 0.0.0.0/32 # "This" Host RFC 1122, Section 3.2.1.3
- 127.0.0.0/8 # Loopback RFC 1122, Section 3.2.1.3
- 169.254.0.0/16 # Link Local RFC 3927
- 224.0.0.0/4 # Multicast RFC 3171
- 255.255.255.255/32 # Limited Broadcast RFC 919, Section 7
- ::1/128 # Loopback RFC 4291, Section 2.5.3
- fe80::/10 # Link local RFC 4291, Section 2.5.6
- ff00::/8 # Multicast RFC 4291, Section 2.7

Example: InternalSubnets: ["10.0.0.0/8","172.16.0.0/12","192.168.0.0/16"]

This allows a user to identify their internal network, which will result

in any internal to internal and external to external connections being

filtered out at import time. Reasonable defaults are provided below

but need to be manually verified against each installation before enabling.

InternalSubnets:
- 10.0.0.0/8 # Private-Use Networks RFC 1918
- 172.16.0.0/12 # Private-Use Networks RFC 1918
- 192.168.0.0/16 # Private-Use Networks RFC 1918

Example: AlwaysIncludeDomain: ["mydomain.com","*.mydomain.com"]

This functionality overrides the NeverIncludeDomain

section, making sure that any connection records containing domains

that match this list are kept and not filtered

NOTE: When using wildcards, make sure the added entry is in quotes,

ie, '*.mydomain.com'. Only subdomain wildcarding

(asterisk as the prefix) is supported

AlwaysIncludeDomain: []

Example: NeverIncludeDomain: ["mydomain.com","*.mydomain.com"]

This functions as a whitelisting setting, and connections involving

ranges entered into this section are filtered out at import time

NOTE: When using wildcards, make sure the added entry is in quotes,

ie, '*.mydomain.com'. Only subdomain wildcarding

(asterisk as the prefix) is supported

NeverIncludeDomain: []

FilterExternalToInternal will ignore any entries where communication

is occurring from an external host to an internal host

FilterExternalToInternal: true

BlackListed:
Enabled: true

These are blacklists built into rita-blacklist. Set these to false

to disable checks against them.

feodotracker.abuse.ch: true

This is the name of the database which will be created as a master list of

blacklisted ips and hostnames by rita-blacklist

BlacklistDatabase: "rita-bl"

These are custom blacklists that you may define. They are lists of either

file paths or urls. These custom blacklists are expected to be simple,

line separated text documents containing a list of blacklisted entries.

Example: CustomIPBlacklists: ["$HOME/.rita/myIPBlacklist.txt"]

myIPBlacklist.txt would look like this:

192.168.0.1

10.10.174.1

Lists containing both IPv4 and IPv6 addresses are acceptable

CustomIPBlacklists: []

Lists containing hostnames, domain names, and FQDNs are acceptable

CustomHostnameBlacklists: []

Beacon:
Enabled: true

The default minimum number of connections used for beacons analysis.

Any two hosts connecting fewer than this number will not be analyzed. You can

safely increase this value to improve performance if you are not concerned

about slow beacons.

Note: Since analyzing hosts that have fewer than at least one connection per

hour could significantly increase both the analysis time and the number

of false positives, 23 is the minimum allowed value for this field.

DefaultConnectionThresh: 23

The score is currently comprised of a weighted average of 4 subscores.

While we recommend the default setting of 0.25 for each weight,

these weights can be altered here according to your needs.

The sum of all the floating point weights must be equal to 1.

TimestampScoreWeight: 0.25
DatasizeScoreWeight: 0.25
DurationScoreWeight: 0.25
HistogramScoreWeight: 0.25

The number of hours seen in a connection graph representation of a beacon must

be greater than this threshold for an overall duration score to be calculated.

Default value: 6

DurationMinHoursSeen: 6

This is the minimum number of hours seen in a connection graph representation

of a beacon for the consistency subscore of duration to score at 100%

Default value: 12 (half the day)

DurationConsistencyIdealHoursSeen: 12

The histogram score has a subscore that attempts to detect multiple

flat sections in a connection graph representation of a beacon. The

variable below controls the bucket size for grouping connections. This

is expressed as a percentage of the largest connection count. For example,

if the max connection count is 400 and this variable is set to 0.05 (5%),

the bucket size will be 20 (400*0.05=20). As you make this variable

larger, the algorithm becomes more forgiving to variation.

Default value 0.05

HistogramBimodalBucketSize: 0.05

This is the number of buckets that can be considered outliers and dropped

from the calculation.

Default value: 1

HistogramBimodalOutlierRemoval: 1

This is the minimum number of hours seen in a connection graph representation

of a beacon before the bimodal subscore score is used.

Default value: 11 (sets the minimum coverage to just below half of the day)

HistogramBimodalMinHoursSeen: 11

BeaconSNI:
Enabled: true

The default minimum number of connections used for beacons SNI analysis.

Any two hosts connecting fewer than this number will not be analyzed. You can

safely increase this value to improve performance if you are not concerned

about slow beacons.

Note: Since analyzing hosts that have fewer than at least one connection per

hour could significantly increase both the analysis time and the number

of false positives, 23 is the minimum allowed value for this field.

DefaultConnectionThresh: 23

The score is currently comprised of a weighted average of 4 subscores.

While we recommend the default setting of 0.25 for each weight,

these weights can be altered here according to your needs.

The sum of all the floating point weights must be equal to 1.

TimestampScoreWeight: 0.25
DatasizeScoreWeight: 0.25
DurationScoreWeight: 0.25
HistogramScoreWeight: 0.25

The number of hours seen in a connection graph representation of a beacon must

be greater than this threshold for an overall duration score to be calculated.

Default value: 6

DurationMinHoursSeen: 6

This is the minimum number of hours seen in a connection graph representation

of a beacon for the consistency subscore of duration to score at 100%

Default value: 12 (half the day)

DurationConsistencyIdealHoursSeen: 12

The histogram score has a subscore that attempts to detect multiple

flat sections in a connection graph representation of a beacon. The

variable below controls the bucket size for grouping connections. This

is expressed as a percentage of the largest connection count. For example,

if the max connection count is 400 and this variable is set to 0.05 (5%),

the bucket size will be 20 (400*0.05=20). As you make this variable

larger, the algorithm becomes more forgiving to variation.

Default value 0.05

HistogramBimodalBucketSize: 0.05

This is the number of buckets that can be considered outliers and dropped

from the calculation.

Default value: 1

HistogramBimodalOutlierRemoval: 1

This is the minimum number of hours seen in a connection graph representation

of a beacon before the subscore score is used.

Default value: 11 (sets the minimum coverage to just below half of the day)

HistogramBimodalMinHoursSeen: 11

BeaconProxy:
Enabled: true

The default minimum number of connections used for beacons proxy analysis.

Any two hosts connecting fewer than this number will not be analyzed. You can

safely increase this value to improve performance if you are not concerned

about slow beacons.

Note: Since analyzing hosts that have fewer than at least one connection per

hour could significantly increase both the analysis time and the number

of false positives, 23 is the minimum allowed value for this field.

DefaultConnectionThresh: 23

The score is currently comprised of a weighted average of 3 subscores.

While we recommend the default setting of 0.333 for each weight,

these weights can be altered here according to your needs.

The sum of all the floating point weights must be equal to 1

TimestampScoreWeight: 0.333
DurationScoreWeight: 0.333
HistogramScoreWeight: 0.333

The number of hours seen in a connection graph representation of a beacon must

be greater than this threshold for an overall duration score to be calculated.

Default value: 6

DurationMinHoursSeen: 6

This is the minimum number of hours seen in a connection graph representation

of a beacon for the consistency subscore of duration to score at 100%

Default value: 12 (half the day)

DurationConsistencyIdealHoursSeen: 12

The histogram score has a subscore that attempts to detect multiple

flat sections in a connection graph representation of a beacon. The

variable below controls the bucket size for grouping connections. This

is expressed as a percentage of the largest connection count. For example,

if the max connection count is 400 and this variable is set to 0.05 (5%),

the bucket size will be 20 (400*0.05=20). As you make this variable

larger, the algorithm becomes more forgiving to variation.

Default value 0.05

HistogramBimodalBucketSize: 0.05

This is the number of buckets that can be considered outliers and dropped

from the calculation.

Default value: 1

HistogramBimodalOutlierRemoval: 1

This is the minimum number of hours seen in a connection graph representation

of a beacon before the subscore score is used.

Default value: 11 (sets the minimum coverage to just below half of the day)

HistogramBimodalMinHoursSeen: 11

DNS:
Enabled: true

UserAgent:
Enabled: true

Strobe:

This sets the maximum number of connections between any two given hosts that are stored.

Connections above this limit will be deleted and not used in other analysis modules. This will

also trigger an entry in the strobe module. A lower value will reduce import & analysis time and

hide more potential false positives from other modules. A higher value will increase import &

analysis time, increase false positives, but reduce the risk of false negatives.

Note: Since this value must be low enough to ensure that documents that store

arrays based off of connections will not grow beyond 16MB in size, the maximum value allowed

for this field is:

86400 - One connection every second for 24 hours

ConnectionLimit: 86400

[BohraDJayesh]

The issue is related to the MongoDB version. The current RITA does not support the latest MongoDB version, so please uninstall MongoDB using the official guide and reinstall version 4.2, as listed in the requirements section of RITA.
You can find the official installation guide for MongoDB 4.2 on Ubuntu here.