Cloud Images sur AWS

• Vous pouvez facilement initialiser une nouvelle instance ou restaurer une instance TheHive précédente à l’aide des scripts inclus dans l’image.
• Les données sont stockées sur 3 volumes dédiés : un pour la base de données Cassandra (/var/lib/cassandra), un autre pour les pièces jointes de stockage (/opt/thp_data/files) et un dernier pour les index (/opt/thp_data/index).
• L’AMI est basée sur l’AMI officielle Ubuntu 20.04 LTS de Canonical.
• L’AMI est mise à jour chaque fois qu’une nouvelle version de TheHive est publiée : lancez simplement une nouvelle instance comme s’il s’agissait d’un container habituel.
• La migration depuis TheHive v3 est une opération manuelle longuement détaillée ici.
• La mise à niveau depuis l’AMI TheHive v4 est possible à l’aide d’un script fourni dans l’AMI. Si vous préférez migrer manuellement, le processus global de mise à niveau est documenté ici.

• L’application TheHive s’exécute en tant qu’utilisateur non privilégié nommé thehive et est disponible sur le port HTTP 9000 (et non HTTPS). Nous vous encourageons à ne jamais ouvrir ce port en dehors de votre VPC et à utiliser un équilibreur de charge public et/ou un proxy inverse pour gérer les sessions TLS avec les utilisateurs finaux. Étant donné que de nombreux utilisateurs de TheHive exécutent également des instances Cortex et MISP et que le bon équilibreur de charge/proxy inverse est évidemment celui que vous connaissez le mieux, nous avons choisi de ne pas en inclure un autre dans cette AMI.
• Pour inciter à utiliser https, TheHive est configuré pour utiliser des cookies sécurisés par défaut. La connexion à l’interface utilisateur en http échouera. Toute modification de ces paramètres reste possible dans les réglages : définissez play.http.session.secure = false dans /etc/thehive/application.conf. Vous devez redémarrer le service thehive pour que la modification soit effective.
• L’utilisateur sudoer par défaut est ubuntu et le service ssh écoute sur le port 22.
• Une tâche cron pour l’utilisateur thehive s’exécute toutes les nuits (@daily) pour sauvegarder la configuration de l’application sur le volume de données (/var/lib/cassandra/thehive/). Si vous souhaitez lancer une nouvelle instance à partir de données existantes, ce travail doit être exécuté au moins une fois après l’installation initiale pour restaurer également la configuration de l’application.

1. Lancez une instance depuis l’AMI.
2. Connectez-vous en SSH à l’instance avec l’utilisateur ubuntu.
3. Initialisez et formatez les volumes EBS supplémentaires (/dev/sdh, /dev/sdiand/dev/sdj). Notez que dans les instances basées sur Nitro, /dev/sdhm pourrait être disponible sous la forme /dev/nvme1n1. Plus d’informations sont disponibles dans la documentation des instances Amazon EBS et NVMe sur Linux.
4. Lancez le script d’initialisation de l’application avec les noms de périphériques de bloc de volumes de données EBS comme arguments, qui sont /dev/sdh, /dev/sdi et/dev/sdj si vous utilisez une configuration AMI par défaut. Si vous utilisez une instance basée sur Nitro, n’utilisez pas les noms NVME (comme /dev/nvme0n1). Exemple : /opt/thehive/ops/scripts/ops-thehive-init.sh /dev/sdh /dev/sdi /dev/sdj.
5. C’est fait ! TheHive est désormais disponible sur le port 9000. Le compte administrateur par défaut est « admin@thehive.local » avec le mot de passe « secret » (changez-le !).

Autrement, vous pouvez facilement effectuer les étapes 3 et 4 en fournissant des données utilisateur cloud-init à l’AMI au lancement. Dans l’exemple suivant, nous utilisons une instance m5 (basée sur Nitro), nous :

• lançons un script qui exposera les volumes externes, vus par l’instance comme /dev/nvme1n1 et /dev/nvme2n1, avec leurs noms de mappage de périphériques de bloc (/dev/sdh, /dev/sdi)
• partitionnons et formatons les volumes EBS en utilisant leurs noms de mappage de périphériques de bloc (/dev/sdh, /dev/sdi)
• lançons le script d’initialisation avec les noms de mappage des blocs EBS en argument (/dev/sdh, /dev/sdi, /dev/sdj)

#cloud-config
bootcmd:
- [ /usr/sbin/nvme-to-block-mapping ]
fs_setup:
- filesystem: ext4
device: '/dev/sdh'
partition: auto
overwrite: false
- filesystem: ext4
device: '/dev/sdi'
partition: auto
overwrite: false
- filesystem: ext4
device: '/dev/sdj'
partition: auto
overwrite: false
runcmd:
- [ /opt/thehive/ops/scripts/ops-thehive-init.sh, /dev/sdh, /dev/sdi, /dev/sdj ]

Vous pouvez également provisionner le tout à l’aide de Terraform ; consultez notre référentiel GitHub pour un exemple de code détaillé.

1. Lancez une instance à partir de l’AMI et basez les volumes EBS supplémentaires (/dev/sdh, /dev/sdi et /dev/sdj par défaut) sur les instantanés de volume TheHive EBS existants pour la base de données Cassandra (/dev/sdh), les pièces jointes de stockage (/dev/sdi) et l’index de la base de données (/dev/sdj).
2. Connectez-vous en SSH à l’instance avec l’utilisateur ubuntu.
3. Lancez le script de restauration TheHive avec les noms de périphériques de bloc de volumes de données EBS comme arguments, qui sont /dev/sdh, /dev/sdi et /dev/sdj si vous utilisez une configuration AMI par défaut. Si vous utilisez une instance basée sur Nitro, n’utilisez pas les noms NVME (comme /dev/nvme1n1). Exemple : /opt/thehive/ops/scripts/ops-thehive-restore.sh /dev/sdh /dev/sdi /dev/sdj.
4. C’est fait ! TheHive est désormais disponible sur le port 9000 (ou sur le port personnalisé que vous aviez configuré) avec toute votre configuration, vos utilisateurs et vos données existants.

Sinon, vous pouvez facilement effectuer l’étape 3 en fournissant des données utilisateur cloud-init à l’AMI au lancement. Dans l’exemple suivant, nous utilisons une instance m5 (basée sur Nitro), nous :

• lançons le script de restauration avec les noms de mappage de blocs EBS comme arguments (/dev/sdh, /dev/sdi et /dev/sdj).

#cloud-config
runcmd:
- [ /opt/thehive/ops/scripts/ops-thehive-restore.sh, /dev/sdh, /dev/sdi, /dev/sdj ]

Vous pouvez également provisionner le tout à l’aide de Terraform ; consultez notre référentiel GitHub pour un exemple de code détaillé.

• Basé sur l’AMI officielle Ubuntu 20.04 de Canonical.
• L’AMI est mise à jour chaque fois qu’une nouvelle version de Cortex est publiée : lancez simplement une nouvelle instance comme s’il s’agissait d’un container.
• Les données Cortex et les images Docker (pour les analyseurs et les répondeurs) sont stockées sur deux volumes EBS dédiés, et non dans le système de fichiers racine. Dans cet esprit, l’AMI créera deux volumes de données EBS persistants au lancement qui ne seront pas supprimés à la fin de l’instance. Ceci a pour objectif que vos données ne soient pas perdues accidentellement. Les volumes seront chiffrés avec votre clé KMS par défaut.
• Le volume de données Cortex (/dev/sdh) est dimensionné par défaut à 30 Go ; le volume Docker (/dev/sdi) est dimensionné à 20 Go par défaut.

• L’application Cortex s’exécute en tant que cortex d’utilisateur non privilégié et est disponible sur le port HTTP 9001 (et non HTTPS). Nous vous encourageons à ne jamais ouvrir ce port en dehors de votre VPC et à utiliser un équilibreur de charge public et/ou un proxy inverse pour gérer les sessions TLS avec les utilisateurs finaux. Étant donné que de nombreux utilisateurs de Cortex exécutent également des instances TheHive et MISP et que le bon équilibreur de charge/proxy inverse est évidemment celui que vous connaissez le mieux, nous avons choisi de ne pas en inclure un autre dans cette AMI. Nous fournissons plus d’informations sur l’utilisation d’AWS Application Load Balancer ou des proxys inverses dans notre guide d’utilisation détaillé de Cortex AMI.
• L’utilisateur sudo-er par défaut est ubuntu et le service ssh écoute sur le port 22.
• La configuration Cortex est configurée pour rechercher des analyseurs personnalisés sous /opt/cortexneurons/analyzers et des répondeurs personnalisés sous /opt/cortexneurons/responders.
• Une tâche cron pour le cortex utilisateur s’exécute toutes les nuits (@daily) pour sauvegarder la configuration de l’application et les analyseurs personnalisés/répondeurs personnalisés sur le volume de données (/var/lib/elasticsearch/cortex/). Si vous souhaitez lancer une nouvelle instance à partir de données existantes, cette tâche doit être exécutée au moins une fois après l’installation initiale pour restaurer la configuration de l’application ainsi que les analyseurs/répondeurs personnalisés.

1. Lancez une instance depuis l’AMI.
2. Connectez-vous en SSH à l’instance avec l’utilisateur ubuntu.
3. Initialisez et formatez les volumes EBS supplémentaires (/dev/sdh et /dev/sdi). Notez que dans les instances basées sur Nitro, /dev/sdh et /dev/sdi peuvent être disponibles sous la forme /dev/nvme1n1 et /dev/nvme2n1. Plus d’informations sont disponibles dans la documentation des instances Amazon EBS et NVMe sur Linux.
4. Lancez le script d’initialisation de l’application avec les noms de périphériques de bloc de volume de données EBS comme arguments, à savoir /dev/sdh et /dev/sdi si vous utilisez une configuration AMI par défaut. Si vous utilisez une instance basée sur Nitro, n’utilisez pas les noms NVME (comme /dev/nvme1n1). Exemple : /opt/cortex/ops/scripts/ops-cortex-init.sh /dev/sdh /dev/sdi.
5. C’est fait ! Cortex est désormais disponible sur le port 9001. Vous pouvez créer le compte administrateur lors de la première connexion à l’application.

Autrement, vous pouvez facilement effectuer les étapes 3 et 4 en fournissant des données utilisateur cloud-init à l’AMI au lancement. Dans l’exemple suivant utilisant une instance m5 (basée sur Nitro), nous :

• lançons un script qui exposera les volumes externes, vus par l’instance comme /dev/nvme1n1 et /dev/nvme2n1, avec leurs noms de mappage de périphériques de bloc (/dev/sdh, /dev/sdi)
• partitionnons et formatons les volumes EBS en utilisant leurs noms de mappage de périphériques de bloc (/dev/sdh, /dev/sdi)
• lançons le script d’initialisation avec les noms de mappage des blocs EBS comme arguments (/dev/sdh et /dev/sdi et non /dev/nvme0n1 et /dev/nvme1n1)

#cloud-config

bootcmd:

    - [ /usr/sbin/nvme-to-block-mapping ]

fs_setup:

    - filesystem: ext4

      device: '/dev/sdh'

      partition: auto

      overwrite: false

    - filesystem: ext4

      device: '/dev/sdi'

      partition: auto

      overwrite: false

runcmd:

    - [ /opt/cortex/ops/scripts/ops-cortex-init.sh, /dev/sdh, /dev/sdi ]

Vous pouvez également provisionner le tout à l’aide de Terraform ; consultez notre référentiel GitHub pour un exemple de code détaillé.

1. Lancez une instance à partir de l’AMI et basez les volumes EBS supplémentaires (/dev/sdh et /dev/sdi par défaut) sur les données Cortex existantes et les instantanés de volumes Docker.
2. Connectez-vous en SSH à l’instance avec l’utilisateur ubuntu.
3. Lancez le script de restauration Cortex avec les noms de périphériques de bloc de volume de données EBS comme arguments, qui sont /dev/sdh et /dev/sdi si vous utilisez une configuration AMI par défaut. Si vous utilisez une instance basée sur Nitro, n’utilisez pas les noms NVME (comme /dev/nvme1n1). Exemple : /opt/cortex/ops/scripts/ops-cortex-restore.sh /dev/sdh /dev/sdi.
4. C’est fait ! Cortex est désormais disponible sur le port 9001 (ou sur le port personnalisé que vous avez configuré) avec toute votre configuration, vos utilisateurs et vos données existants. Les analyseurs et répondeurs personnalisés stockés sous /opt/cortexneurons sont également automatiquement restaurés et leurs exigences pip sont réinstallées.

Autrement, vous pouvez facilement effectuer l’étape 3 en fournissant des données utilisateur cloud-init à l’AMI au lancement. Dans l’exemple suivant utilisant une instance m5 (basée sur Nitro), nous :

• lançons le script de restauration avec les noms de mappage des blocs EBS comme arguments (/dev/sdh et /dev/sdi et non /dev/nvme1n1 et /dev/nvme2n1)

#cloud-config

runcmd:

    - [ /opt/cortex/ops/scripts/ops-cortex-restore.sh, /dev/sdh, /dev/sdi ]

Vous pouvez également provisionner le tout à l’aide de Terraform ; consultez notre référentiel GitHub pour un exemple de code détaillé.