target/strelka-uiStrelka Web UI pour la soumission et l'analyse de fichiers.
L'interface Web Strelka est un frontend de soumission de fichiers basé sur navigateur et API pour Strelka Enterprise File Scanner. Elle permet aux utilisateurs de soumettre des fichiers à un cluster Strelka et de consulter facilement les résultats historiques des réponses. L'interface Web Strelka prend en charge l'authentification LDAP et l'accès API, offrant un moyen sécurisé et flexible d'interagir avec le scanner Strelka. Ce document fournit des détails sur la configuration et l'utilisation de l'interface Web Strelka, ainsi que sur ses fonctionnalités et ses projets connexes.
L'interface de soumission de fichiers offre les fonctionnalités suivantes :
Par défaut, l'interface Strelka est configurée pour utiliser un déploiement minimal "quickstart" qui permet aux utilisateurs de tester le système. Ce déploiement cible une instance Strelka locale et démarre une base de données locale. Les utilisateurs pourront accéder à ce système avec le nom d'utilisateur / le mot de passe de leur choix. Pour plus d'informations sur le ciblage d'une instance Strelka distante, d'une base de données distante ou sur l'utilisation de LDAP pour l'authentification, voir la section Configuration supplémentaire :
Start or ensure Strelka cluster is ready and accessible.
See https://github.com/target/strelka for more information.
# Terminal 1
# From the ./strelka-ui directory
$ docker-compose -f docker-compose.yml up
1) Open A Browser
2) Navigate to 0.0.0.0:8080
3) Login with:
- Username: strelka
- Password: strelka
Cette section fournit des détails sur la façon de cibler une instance Strelka distante, une base de données distante pour le stockage et un serveur LDAP pour l'authentification, pour une utilisation plus sécurisée. Pour activer ces options, vous pouvez utiliser des variables d'environnement pour remplacer les valeurs par défaut.
La configuration du backend est fournie via des variables d'environnement et peut être définie statiquement dans ./app/config/config.py.
En local, la précédence de configuration est : System environment -> .env -> ./app/config/config.py.
Dans Docker, la précédence de configuration est : Docker environment -> System environment -> ./app/config/config.py.
Veuillez vous référer à ./app/example.env pour la configuration des variables d'environnement.
Les éléments suivants détaillent les éléments de configuration dans ./app/config/config.py.
Vous pouvez également définir une référence dans le tableau de soumission de l'interface pour permettre aux utilisateurs de basculer rapidement vers un site externe en fonction du request.id. En modifiant ./ui/src/config.js et en suivant l'exemple SEARCH_URL dans le tableau suivant, vous pouvez fournir aux utilisateurs un lien vers un site externe (p. ex., SIEM / logger). Assurez-vous que votre lien contient la chaîne <REPLACE> et l'interface remplacera cette chaîne par l'ID de requête du fichier concerné.
Champs de modification pris en charge dans ./ui/src/config.js :
| Field Name | Value | Example |
|---|---|---|
Si votre environnement réseau nécessite un bundle CA personnalisé (par exemple, un proxy d'inspection TLS d'entreprise), vous pouvez le fournir à la fois au moment de la construction et à l'exécution sans engager aucun fichier de certificat dans le dépôt.
Au moment de la construction — transmettez le chemin de votre bundle CA via CUSTOM_CA_CERT avant d'exécuter docker compose build. Le certificat est monté de manière éphémère à l'aide d'un secret BuildKit et n'est jamais écrit dans une couche d'image :
CUSTOM_CA_CERT=/path/to/your/ca-bundle.crt docker compose build
# or, combined with up:
CUSTOM_CA_CERT=/path/to/your/ca-bundle.crt docker compose up --build
Sur les réseaux ouverts où aucun CA personnalisé n'est nécessaire, omettez entièrement la variable — la construction se dégrade de manière gracieuse :
docker compose up --build
Au moment de l'exécution — le répertoire certs à la racine du projet est monté dans /certs à l'intérieur du conteneur en cours d'exécution. Placez votre bundle CA à cet endroit et définissez REQUESTS_CA_BUNDLE (et éventuellement SSL_CERT_FILE) dans ./app/strelka_ui/.env ou en tant que variable d'environnement Docker :
# ./app/strelka_ui/.env
REQUESTS_CA_BUNDLE=/certs/ca-bundle.crt
SSL_CERT_FILE=/certs/ca-bundle.crt
L'interface Strelka fournit également des routes API pour un accès scripté par les utilisateurs. Veuillez consulter les routes ci-dessous pour plus de détails :
Des exemples pour s'authentifier à l'API de l'interface Strelka, recueillir les statistiques de scan et soumettre un fichier à l'aide de requests Python se trouvent dans ./misc/examples/api_examples.py
La base de données utilise https://www.sqlalchemy.org/ comme ORM. Flask-Migrate est utilisé pour fournir les migrations de base de données via Alembic. Un fichier de script d'assistance, manage.py, est fourni pour aider aux tâches courantes de base de données.
Si vous créez une nouvelle base de données, ou si vous modifiez la base actuelle, vous devez effectuer les étapes suivantes - bien que ces commandes soient exécutées pour vous au démarrage du cluster :
Générer une nouvelle migration à partir des modifications du modèle :
Mettre à jour la base de données en utilisant la configuration de base de données actuelle
L'application backend est principalement composée des technologies suivantes :
L'interface frontend est une application React JS créée avec React et servie par Flask. L'interface utilise la bibliothèque Antd et Antd ProComponents, et le routage est géré par React Router.
Strelka UI et son code associé sont publiés sous les termes de la licence Apache 2.0.
| Field Name | Value | Required |
|---|
| STRELKA_HOST | Hôte Strelka (p. ex., 0.0.0.0) | Oui |
| STRELKA_PORT | Numéro de port Strelka (p. ex., 57314) | Oui |
| STRELKA_CERT | Chemin vers le certificat pour Strelka, si nécessaire (p. ex., /path/to/cert.pem) | Non |
| CA_CERT_PATH | Chemin vers les certificats CA pour LDAP, si nécessaire (p. ex., /path/to/ca_certs) | Non |
| VIRUSTOTAL_API_KEY | Clé API pour la recherche de hachage VirusTotal | Oui |
| VIRUSTOTAL_API_LIMIT | Limite du nombre de fichiers à analyser par VirusTotal (défaut : 30) | Oui |
| LDAP_URL | URL du serveur LDAP (p. ex., ldaps://ldap.example.com:636) | Non |
| LDAP_SEARCH_BASE | Base de recherche pour les requêtes LDAP (p. ex., DC=example,DC=com) | Non |
| LDAP_USERNAME_ORGANIZATION | Organisation du nom d'utilisateur pour les requêtes LDAP (p. ex., org//) | Non |
| LDAP_ATTRIBUTE_ACCOUNT_NAME_FIELD | Attribut LDAP pour le nom de compte (p. ex., sAMAccountName) | Non |
| LDAP_ATTRIBUTE_FIRST_NAME_FIELD | Attribut LDAP pour le prénom (p. ex., givenName) | Non |
| LDAP_ATTRIBUTE_LAST_NAME_FIELD | Attribut LDAP pour le nom de famille (p. ex., sn) | Non |
| LDAP_ATTRIBUTE_MEMBER_OF_FIELD | Attribut LDAP pour l'appartenance à un groupe (p. ex., memberOf) | Non |
| LDAP_ATTRIBUTE_MEMBER_REQUIREMENT_FIELD | Attribut LDAP pour l'exigence d'appartenance (p. ex., AD Attribute) | Non |
| STATIC_ASSET_FOLDER | Dossier de build pour l'interface (p. ex., build) | Oui |
| MIGRATION_DIRECTORY | Répertoire des migrations SQLAlchemy (p. ex., ./migrations) | Oui |
| DATABASE_USERNAME | Nom d'utilisateur de la base de données (p. ex., admin) | Oui |
| DATABASE_PASSWORD | Mot de passe de la base de données (p. ex., password123) | Oui |
| DATABASE_HOST | Nom d'hôte de la base de données (p. ex., db.example.com) | Oui |
| DATABASE_PORT | Numéro de port de la base de données (p. ex., 5432) | Oui |
| DATABASE_DBNAME | Nom de la base de données (p. ex., mydb) | Oui |
| API_KEY_EXPIRATION | Durée d'expiration de la clé API en jours (p. ex., 30) | Oui |
| SEARCH_URL |
| URL de recherche de l'application externe |
| Ex : https://search.com/?q=request.id= |
| SEARCH_NAME | Nom de recherche de l'application externe | Ex : Splunk |
| DEFAULT_EXCLUDED_SUBMITTERS | Utilisateurs par défaut à exclure de la vue du tableau des soumissions. Utile pour masquer les automatisations par défaut. | Ex : SearchBot |