Admin Maintenance
Once you’ve installed and configured Taranis to your needs, it is important to maintain the installation to make sure that everything keeps on running smoothly. This chapter introduces some aspects that are relevant for the day-to-day administration of Taranis.
Daily maintenance of your installation is pre-configured during the installation, but you may want to improve on that. To perform daily maintenance, you do not need to have root privileges: you need to be able to login as user 'taranis' (or the username you picked during installation).
Give yourself ssh access to that username for easy and safe access. The (new in 3.4.0) taranis command has many sub-commands (and there will be more in the future). Try taranis --help to list all sub-commands. Each of them also has a short help, for instance taranis db --help which shows the exact use and options.
Sub-commands which have to be run often, are grouped into three scripts which are triggered via cron. You may change their frequency in the crontab (crontab -e).
The three default groups of commands are:
~/var/cron.often Run (very) often, by default every five minutes.
For example to update the dashboard information.
~/var/cron.cycle Run at each collector cycle, by default every twenty minutes. This controls the collecting itself, running some back-end scripts, statistics collector, and so on.
~/var/cron.daily Daily maintenance, to update cve and cpe information, and more.
You may alter these scripts to your own likes: add, move, or disable steps, redirect output, etc. Do not forget to document the reason for your changes. Commands can be started by hand, for instance to debug them. When needed, the sub-commands will lock themselves to avoid accidents with critical activities. It is not required to block them in cron.
When there are many extensions to your installation, it may be clearer to create your own separate cron scripts.
(added in 3.5.0) You may choose to add to cron a (yearly) call to taranis send advisory-counts, which mails various statistics on created advisories in a certain period of time.
(added in 3.5.0) When you have sources which demand you to remove items after some time, you can use taranis db remove-items. It will remove the items and references to those items from the database. Of course, you loose some traceability with this move.
The item table can grow huge (hence slow), so you may want to archive items. Read more about that below.
Your Taranis instance is defined by the files in ~/var/ and the content of the database. When you move your instance to a new machine, they have to be moved as they are.
The (new) wrapper command psql will let you login to the database without the need to remember how access is configured.
When you change files in ~/etc/ you have to rerun taranis install: they define your installation. When your instance moves to a different machine, those files will change.
The files in ~/lib/ are produced during the installation process. They should not be modified by hand.
Beside the default OS and application logging, Taranis supports both system logging and Taranis specific application logging.
- Apache logging
- PostgreSQL logging
journalctl -t TARANIS- Logfiles under
/var/log/taranis/
You need to backup
- the database table
taranis, where most data is stored -
~taranis/where the code is stored
- restore the directory of user
taranis - as root:
cd ~taranis/sources/taranis-$version; bin/taranis install
PostgreSQL offers a function called vacuuming to, amongst others, allow for recovery and reuse of disk space occupied by updated or deleted rows. Taranis installation does not configure this.
You should either run the VACUUM command on the database regularly or turn on autovacuuming. Read the PostgreSQL documentation on VACUUM
Depending on the number of sources you add to Taranis and the number of items these sources generate, the list of items can grow pretty fast. Most items are not relevant anymore after a few weeks. When the "assess"-page of your Taranis is slow, you may decide to archive older items. The disadvantage is that those archived items can only found via ‘Advanced Search’.
Selecting items to get archived is based on a date. All items which were collected before some date are moved to separate database tables. Items that are linked to an analysis or dossier will not be archived, because this would hinder your analysis or dossier.
The following is an example of how to archive all data older than 14 days (run on the 10th of July 2017):
tar$ taranis db archive --before +14d Archiving records before 20170627 (+ 0s) 12:57:26 record count before archiving: [...] (+ 0s) 12:57:26 Collecting tagged items, to be excluded excluding 0 tagged items (+ 0s) 12:57:26 Archiving email records (table email_item) (+ 0s) 12:57:26 Delete archived email items (+ 0s) 12:57:26 Archiving feed records (table item) (+ 0s) 12:57:26 Deleting archived feed records (+ 0s) 12:57:26 Archiving identifiers (table identifier) (+ 0s) 12:57:26 Delete archived identifiers (+ 0s) 12:57:26 Completing transaction (+ 0s) 12:57:26 Re-analyze modified tables (+ 0s) 12:57:26 Archiving successfully completed! Record count after archiving: [...]
Once you archived items, that will become visible in the Dashboard. In the example below you can see that an archiving action took place at the beginning of March, which resulted in a reduction from 500k live items down to around 200k.
Figure: Database characteristics
As a security team, you should practice what you preach: keep your system up-to-date and install security and bug fixes as soon as they become available.
