Uninstalling IDSTower¶

IDSTower leaves files in two places: on the IDSTower server, and on the Suricata hosts it manages. The installation script has no uninstall option, and removing the idstower package removes only the program itself, so remove IDSTower in this order:

Remove IDSTower from your managed hosts, from the web interface, while the IDSTower server is still running.
Remove the IDSTower server, or, if you run the Docker image, the container.

Before you start¶

Decide what happens to Suricata on your hosts. Deleting a cluster uninstalls Suricata where IDSTower installed it, and can leave an onboarded host’s Suricata stopped or without a configuration. Read what is removed before you delete a cluster whose hosts should keep running Suricata.
Copy appsettings.json to your home directory. Its Database section names the database and user you drop at the end, and removing the package deletes or renames the file. It also holds the EncryptionKey that protects the cluster keys and other secrets in the database, so a database backup is of no use without it. If you may come back, dump the database too:

$ sudo cp /opt/idstower/appsettings.json ~/appsettings.json.backup
$ sudo mysqldump -B [DatabaseName] -u [DatabaseUsername] -p > ~/IDSTower_backup_`date +%F_%H_%M_%S`.sql

Note

Replace [DatabaseName] and [DatabaseUsername] with the values from appsettings.json. The installation script uses IDSTower and idstower unless you chose others. Keep both files in your home directory, not in /opt/idstower, which you delete in step 3 of removing the server.

Remove IDSTower from your managed hosts¶

Do this first, while the IDSTower server still runs: the server is what connects to the hosts over SSH to clean them up.

To remove a whole cluster, open it and choose Cluster Actions > Delete Cluster. Repeat this for every cluster.
To remove some hosts only, use Remove From Cluster on the cluster’s Hosts tab, see Cluster Hosts Tab.

Both run the same clean-up on all the chosen hosts at once. If a host cannot be reached, the action reports a failure and IDSTower keeps the cluster and its hosts, although the hosts it did reach are already cleaned up. Tick Force remove unresponsive hosts in the dialog to remove the unreachable hosts from IDSTower anyway, then clean them up by hand.

What is removed from each host¶

It depends on how the cluster was created (see Deployment Types) and, for an onboarded cluster, on its management capabilities:

	Fresh Installation	Onboarded (Onboard Existing Suricata)
IDSTower’s cron jobs and scripts, `/etc/idstower/`, `/var/log/idstower/`	Removed	Removed
Suricata package	Uninstalled	Never uninstalled
Suricata services and configuration	IDSTower’s `suricata-instance-<name>.service` units stopped, disabled and deleted; `/etc/suricata/` deleted	With Configuration Management: as on Fresh. Without it: IDSTower’s rule-file and datasets/iprep blocks removed from each `suricata.yaml`; the services keep running, except that with Package Management `suricata.service` is stopped and disabled
Filebeat	Stopped and uninstalled; its service file and `/etc/filebeat/` deleted	With Package Management: stopped and uninstalled. With Configuration Management: its service file and `/etc/filebeat/` deleted

Warning

On onboarded hosts that should keep running Suricata or Filebeat after the cluster is deleted:

With Configuration Management, IDSTower removed the package’s own suricata.service and default configuration when it took the configuration over, and replaced them with its suricata-instance-<name>.service units and its files in /etc/suricata/. Deleting the cluster removes those replacements, so the package is left with neither. Copy /etc/suricata/ and the suricata-instance-*.service files (in /lib/systemd/system/ on Debian and Ubuntu, /usr/lib/systemd/system/ elsewhere) before you delete the cluster, or restore your original set-up afterwards from the pre-onboarding backup.
With Package Management but not Configuration Management, suricata.service is stopped and disabled. Start it again with sudo systemctl enable --now suricata.
Filebeat, with Configuration Management but not Package Management, loses /etc/filebeat/ and its service file but is not stopped, so it fails the next time it restarts.

The pre-onboarding backup is /var/lib/idstower/backups/suricata-pre-onboard-<timestamp>.tar.gz, with the configuration directory, rules directories and service files IDSTower found. IDSTower takes one by default each time it takes over a host’s configuration, when the host is onboarded with Configuration Management or when that capability is turned on later. The backup option can be turned off, so check with sudo ls /var/lib/idstower/backups/ that one exists, and use the newest.

What stays on every host:

IDSTower’s SSH public key, in the ~/.ssh/authorized_keys file of the SSH user IDSTower connected as.
If you added the hosts with an SSH password and a user other than root, the passwordless sudo rule IDSTower added for that user to /etc/sudoers.
Suricata’s log files, by default in /var/log/suricata/, and the pre-onboarding backups in /var/lib/idstower/backups/.
The package repositories added to install Suricata and Filebeat, on Fresh Installation hosts and on onboarded hosts with Package Management.
On Debian 11 (Bullseye) hosts, /etc/apt/sources.list.d/00-idstower-debian-archive-security.sources, which takes Debian 11’s security updates from archive.debian.org. IDSTower writes it when it validates the host and when it applies the host’s configuration, whatever the cluster’s capabilities, when the host needs it, and leaves it in place when IDSTower is uninstalled. Keeping it keeps apt able to install security updates on the host; deleting it is safe.

To remove IDSTower’s SSH key once the host is in no IDSTower cluster any more, run this as the SSH user IDSTower connected as. IDSTower’s keys all end with the comment IDSTower-Cluster; the command removes every one of them and keeps a copy of the file as authorized_keys.bak:

$ sed -i.bak '/ IDSTower-Cluster$/d' ~/.ssh/authorized_keys

To remove the sudo rule, open /etc/sudoers with visudo and delete the lines from # BEGIN Section Automatically Added by IDSTower to # END Section Automatically Added by IDSTower:

$ sudo visudo

Cleaning up a host by hand¶

For a host you removed with Force remove unresponsive hosts, or once the IDSTower server is gone, remove IDSTower’s cron jobs, scripts and directories yourself. The first command keeps a copy of root’s crontab in /root/crontab.bak:

$ sudo sh -c 'crontab -l > /root/crontab.bak && sed "/^#Ansible: IDSTower /,+1d" /root/crontab.bak | crontab -'
$ sudo rm -rf /etc/idstower /var/log/idstower /var/run/idstower/detection-content-pending
$ sudo rm -f /etc/suricata/suricata_rules_update.sh /etc/suricata/suricata_indicators_update.sh /etc/suricata/suricata_logs_deletion.sh

On a Fresh Installation host, or an onboarded one with Configuration Management (read the warning above first), also stop and delete IDSTower’s Suricata services and configuration, then uninstall the suricata and filebeat packages if you no longer need them:

$ for unit in /lib/systemd/system/suricata-instance-*.service /usr/lib/systemd/system/suricata-instance-*.service; do [ -e "$unit" ] || continue; sudo systemctl disable --now "$(basename "$unit")"; sudo rm -f "$unit"; done
$ sudo systemctl daemon-reload
$ sudo rm -rf /etc/suricata

On an onboarded host without Configuration Management, delete from each instance’s suricata.yaml the blocks IDSTower added, from # BEGIN IDSTower managed rule-files to # END IDSTower managed rule-files and from # BEGIN IDSTower managed datasets/iprep config to # END IDSTower managed datasets/iprep config.

In every case, remove the SSH key and the sudo rule as described above.

Remove the IDSTower server¶

Stop and disable the IDSTower service

$ sudo systemctl disable --now idstower.service

Remove the IDSTower package

on Ubuntu/Debian:

$ sudo apt-get purge -y idstower
$ sudo systemctl daemon-reload

purge also deletes /opt/idstower/appsettings.json; apt-get remove keeps it.

on CentOS/RHEL/RockyLinux/AlmaLinux/OracleLinux/Amazon Linux:

$ sudo dnf remove -y idstower
$ sudo systemctl daemon-reload

Use yum on systems without dnf. RPM keeps an edited appsettings.json as /opt/idstower/appsettings.json.rpmsave.

Delete what the package leaves behind

Removing the package deletes neither the files IDSTower created while it ran nor the idstower system user. /opt/idstower still holds the HTTPS certificate and its key in /opt/idstower/certs/, and userdel -r also deletes the user’s home directory, /home/idstower:

$ sudo rm -rf /opt/idstower /var/log/idstower /var/cache/idstower
$ sudo userdel -r idstower

Remove the IDSTower package repository

on Ubuntu/Debian:

$ sudo rm -f /etc/apt/sources.list.d/idstower.list /usr/share/keyrings/idstower.gpg
$ sudo apt-get update

on CentOS/RHEL/RockyLinux/AlmaLinux/OracleLinux/Amazon Linux:

$ sudo rm -f /etc/yum.repos.d/idstower.repo

Drop the IDSTower database, and its user if it has one of its own

Warning

This permanently deletes all IDSTower data: clusters, rules, indicators, users and settings. Take the backup described in Before you start first if you may need it again.

$ sudo mariadb -u root -p -e "DROP DATABASE IF EXISTS IDSTower;"

Drop the database user only if it was created for IDSTower alone: never root, and never an account that other applications use. The installation script creates 'idstower'@'localhost'; SELECT User, Host FROM mysql.user; lists the accounts if you are not sure.

$ sudo mariadb -u root -p -e "DROP USER IF EXISTS 'idstower'@'localhost';"

Use the database name and user from appsettings.json if they differ from these defaults, and run the commands on the database server if it is a different machine. The MariaDB root password the installation script generated is in its credentials file (see step 7).

Remove MariaDB, only if nothing else uses it

on Ubuntu/Debian:

$ sudo apt-get purge -y mariadb-server

on CentOS/RHEL/RockyLinux/AlmaLinux/OracleLinux/Amazon Linux:

$ sudo dnf remove -y mariadb-server

The package is mariadb105-server on Amazon Linux 2023, and MariaDB-server if the installation script added the MariaDB repository (/etc/yum.repos.d/mariadb.repo, which you can then delete too). Removing the package normally leaves MariaDB’s data directory, /var/lib/mysql, in place: delete it to remove every database on the server for good.

Remove the remaining leftovers you no longer need

The credentials file IMPORTANT_idstower_installation_script_generated_credentials, in the directory you ran the installation script from (or your home directory, if that one was not writable), and the installation log /tmp/idstower-install-XXXXXXXX.log, which holds the same credentials. They include the MariaDB root password: if you keep MariaDB, store it somewhere safe first. Running the installation script again from the same directory reuses the credentials file.
The firewall rules for HTTP and HTTPS, if nothing else on the server needs them. With UFW:
```
$ sudo ufw delete allow 80/tcp
$ sudo ufw delete allow 443/tcp
```
With firewalld:
```
$ sudo firewall-cmd --zone=public --permanent --remove-service=http
$ sudo firewall-cmd --zone=public --permanent --remove-service=https
$ sudo firewall-cmd --reload
```
If firewalld was not running during the installation, the rules were written with firewall-offline-cmd; remove them with sudo firewall-offline-cmd --zone=public --remove-service=http and the same for https.
Ansible, sshpass and rsync, if nothing else uses them. The IDSTower package marks them as manually installed, so they are not removed automatically. On Ubuntu 22.04 and on RHEL 10 and its rebuilds, the installation script installed Ansible with pip: remove it with sudo python3 -m pip uninstall ansible ansible-core, using python3.12 in place of python3 on RHEL 9, its rebuilds and Oracle Linux 8. Elsewhere, remove the ansible and ansible-core packages with your package manager.
The extra package repositories the installation script added, unless something else on the server was installed from them: on Debian, the backports repository /etc/apt/sources.list.d/<codename>-backports.list, and on Debian 12 also /etc/apt/sources.list.d/ansible.list with its key /usr/share/keyrings/ansible-archive-keyring.gpg; on the RHEL family, EPEL (the epel-release package, oracle-epel-release-el10 on Oracle Linux 10).

Remove IDSTower running on Docker¶

First remove IDSTower from your managed hosts, as for any other installation. Then remove the container and the image:

$ docker stop [container]
$ docker rm [container]
$ docker image rm idstower/idstower:[tag]

If you started it with Docker Compose, docker compose down in the project’s directory stops and removes the container instead.

The image declares no volumes, so removing the container removes everything IDSTower stored inside it. What stays is outside the container:

The database. Drop it as in step 5 above, using the Database__Name you passed to the container. Drop the Database__Username account only if it was created for IDSTower alone: never root, and never an account that other applications use.
Any file you mounted into the container, such as the HTTPS certificate.
The encryption key, the EncryptionKey you passed to the container. Keep it with the database backup if you may come back.