Cloud Images sur Azure

• Basée sur l’image officielle Ubuntu 20.04 LTS de Canonical.
• L’image peut être utilisée avec n’importe quelle version de TheHive v5.x. Vous pouvez simplement mettre à jour une variable locale avec la version TheHive souhaitée pour la mettre à jour chaque fois qu’une nouvelle version est publiée !
• Les données TheHive/Cortex sont stockées sur deux disques dédiés, pas dans le système de fichiers racine. Pour cela, vous devez attacher deux disques de données persistants au lancement sur le LUN 0 (pour les données) et le LUN 1 (pour Docker). La taille minimale recommandée du volume est de 32 Go par volume. Si vous installez Cortex sur une instance distincte, appliquez simplement la même configuration sur la deuxième instance.
• Le système d’exploitation Ubuntu sous-jacent est renforcé et il n’y a pas de filtrage réseau. Il n’y a pas de surprises iptables à l’intérieur de l’image pour éviter tout conflit avec les groupes de sécurité.
• La migration depuis TheHive v4 est possible à l’aide de notre script de migration intégré à l’image.

• TheHive est disponible sur le port http 9000 et Cortex, lorsqu’il est déployé parallèlement, est disponible sur le port http 9001 (c’est http et NON https). Inutile de dire que nous vous encourageons à ne jamais ouvrir ces ports en dehors de votre réseau virtuel et à utiliser un équilibreur de charge public et/ou un proxy inverse pour gérer les sessions TLS avec les utilisateurs finaux.
• Pour inciter à utiliser https, TheHive et Cortex sont configurés par défaut pour utiliser des cookies sécurisés. La connexion à leurs interfaces utilisateur respectives en http échouera. Un remplacement de cela reste possible dans la configuration (pour TheHive, définissez play.http.session.secure = false dans /opt/thp_data/nomad/tasks/thehive/application.conf ; pour Cortex, définissez play.http.session.secure = false et play.filters.csrf.cookie.secure = false dans /opt/thp_data/nomad/tasks/cortex/application.conf). Vous devez redémarrer le(s) service(s) thehive et/ou cortex pour que la modification soit effective.

1. Lancez une instance à partir de l’image et attachez deux disques persistants : le disque de données sur le LUN 0 et le LUN du disque docker.
2. Définissez le nom d’utilisateur administrateur sur azureuser.
3. Fournissez le script d’amorçage cloud-init suivant pour configurer l’instance (vous devez mettre à jour au moins la valeur application.baseUrl pour TheHive dans cet exemple) :

#cloud-config

disk_setup:

  /dev/disk/azure/scsi1/lun0:

    table_type: gpt

    layout: True

    overwrite: True

  /dev/disk/azure/scsi1/lun1:

    table_type: gpt

    layout: True

    overwrite: True

fs_setup:

  - device: /dev/disk/azure/scsi1/lun0

    partition: auto

    filesystem: ext4

  - device: /dev/disk/azure/scsi1/lun1

    partition: auto

    filesystem: ext4

write_files:

    - path: /opt/strangebee/ops/templates/nomad/tasks/thehive/application.conf.d/service.conf

      content: |

           application.baseUrl="https://thehive.mydomain.com/thehive"

           play.http.context="/thehive"

    - path: /opt/strangebee/ops/templates/nomad/tasks/cortex/application.conf.d/service.conf

      content: |

           play.http.context="/cortex"

runcmd:

    - [ /opt/strangebee/ops/scripts/ops-launch.sh, "-t 1", "-c 0", "-p /dev/sdh", "-d /dev/sdi" ]

Vous pouvez personnaliser davantage ce script selon vos besoins. Dans l’exemple ci-dessus, nous :

• partitionnons et formatons les disques de données connectés sur LUN 0 et LUN 1
• lançons le script d’initialisation avec les noms de mappage du disque de données cible comme argument (/dev/sdh et /dev/sdi) – le script montera automatiquement le disque LUN 0 sur /dev/sdh et le disque LUN 1 sur /dev/sdi
• installons uniquement TheHive (à cause des paramètres « -t 1 », « -c 0 » lors de l’appel du script ops-launch.sh)

Pour installer TheHive et Cortex sur la même instance, utilisez « -t 1 », « -c 1 ».

Pour installer Cortex uniquement sur une autre instance, utilisez « -t 0 », « -c 1 ».

C’est fait ! TheHive est désormais disponible (pour votre équilibreur de charge ou proxy inverse) sur le port 9000 et Cortex sur le port 9001, s’il est également installé. Le compte administrateur par défaut sur les deux applications est admin avec un mot de passe secret (changez-le !).

N’oubliez pas d’accéder aux applications via un système https accessible sur Internet, tel qu’un proxy inverse ou un équilibreur de charge. Dans notre exemple, TheHive est disponible sur https://thehive.mydomain.com/thehive et Cortex sur https://thehive.mydomain.com/cortex.

Vous pouvez également provisionner le tout à l’aide de Terraform.

Consultez notre référentiel GitHub pour le code de déploiement clé en main, y compris un réseau virtuel SecOps complet avec une passerelle d’application https.

• Basé sur l’image officielle Ubuntu 20.04 LTS de Canonical.
• L’image 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 conteneur !
• Les données Cortex sont stockées sur des disques dédiés, pas dans le système de fichiers racine. Dans cette optique, vous devez connecter deux disques de données persistants sur le LUN 0 (pour la base de données) et le LUN 1 (pour les images Docker) au lancement (30 Go chacun recommandés).
• Le système d’exploitation Ubuntu sous-jacent est renforcé et il n’y a pas de filtrage réseau. Il n’y a pas de surprises iptables à l’intérieur de l’image pour éviter tout comportement conflictuel avec les groupes de sécurité.

• L’application Cortex s’exécute en tant qu’utilisateur cortex non privilégié et est disponible sur le port http 9001 (c’est http et NON https). Inutile de dire que nous vous encourageons à ne jamais ouvrir ce port en dehors de votre réseau virtuel 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 image.
• 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.
• Un cronjob pour l’utilisateur cortex 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 afin de restaurer également la configuration de l’application et les analyseurs/répondeurs personnalisés.

1. Lancez une instance à partir de l’image et attachez deux disques de données sur LUN 0 et LUN 1.
2. Connectez-vous en SSH à l’instance avec un utilisateur sudoer.
3. Initialisez et formatez les disques de données supplémentaires (LUN 0 et LUN 1).
4. Lancez le script d’initialisation de l’application avec les noms des disques de données cibles comme arguments. Exemple : /opt/cortex/ops/scripts/ops-cortex-init.sh /dev/sdh /dev/sdi (le script montera automatiquement les disques LUN 0 et LUN 1 sur /dev/sdh et /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.

Alternativement, vous pouvez facilement effectuer les étapes 3 et 4 en fournissant un script d’amorçage cloud-init au lancement. Dans l’exemple suivant, nous :

• partitionnons et formatons les disques de données connectés sur LUN 0 et LUN 1
• améliorons la graine aléatoire avec polliniser (car nous générerons une clé secrète dans le processus d’initialisation)
• et enfin, nous lançons le script d’initialisation avec les noms de mappage du disque de données cible comme arguments (/dev/sdh et /dev/sdi) – le script montera automatiquement le disque LUN 0 sur /dev/sdh et le LUN 1 sur /dev/ sdi.

#cloud-config

disk_setup:

  /dev/disk/azure/scsi1/lun0:

    table_type: gpt

    layout: True

    overwrite: True

  /dev/disk/azure/scsi1/lun1:

    table_type: gpt

    layout: True

    overwrite: True

fs_setup:

  - device: /dev/disk/azure/scsi1/lun0

    partition: none

    filesystem: ext4

  - device: /dev/disk/azure/scsi1/lun1

    partition: none

    filesystem: ext4

random_seed:

    file: /dev/urandom

    command: ["pollinate", "--server=https://entropy.ubuntu.com/"]

    command_required: true

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’initialisation.

1. Lancez une instance à partir de l’image et attachez les disques de données Cortex existants sur les LUN 0 et LUN 1 (nous vous recommandons de toujours créer d’abord des instantanés de disque).
2. Connectez-vous en SSH à l’instance avec un utilisateur sudoer.
3. Lancez le script de restauration Cortex avec les noms des disques de données comme arguments, qui sont /dev/sdh et /dev/sdi si vous utilisez la configuration par défaut. 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 un script bootstrap cloud-init au lancement. Dans l’exemple suivant, nous :

• lançons le script de restauration avec les noms des disques de données comme arguments (/dev/sdh et /dev/sdi)

#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 de mise à jour/migration/restauration.