Évaluation et tests SUSE® Security

Applications d’exemple

Après avoir déployé les SUSE® Security composants, vous pouvez les évaluer en utilisant les applications de test d’exemple que nous fournissons. Celles-ci se trouvent dans le dépôt 'nvbeta sur docker hub.

Un environnement de test typique basé sur Kubernetes aurait un nœud maître et deux à trois nœuds de travail. Vous pouvez contrôler si les pods d’application et les conteneurs SUSE® Security sont déployés sur un nœud maître (désactivé par défaut).

Plan de test Kubernetes

Pour déployer une application multi-niveaux utilisant Nginx, Nodejs et Redis, utilisez les exemples ci-dessous (dans l’ordre ci-dessous). Ceci peut nécessiter des modifications pour le déploiement sur OpenShift, Rancher et d’autres outils basés sur Kubernetes.

Créer un espace de noms de démonstration

kubectl create namespace demo

L’exemple ci-dessous utilise apiVersion: apps/v1 requis par Kubernetes 1.16+.

Créer le service et le déploiement Redis en utilisant ce yaml :

apiVersion: v1
kind: Service
metadata:
  name: redis
  namespace: demo
spec:
  ports:
  - port: 6379
    protocol: "TCP"
    name: "cluster-tcp-6379"
  clusterIP: None
  selector:
    app: redis-pod

---

apiVersion: apps/v1
kind: Deployment
metadata:
  name: redis-pod
  namespace: demo
spec:
  selector:
    matchLabels:
      app: redis-pod
  template:
    metadata:
      labels:
        app: redis-pod
    spec:
      containers:
      - name: redis-pod
        image: redis

Créer le service et le déploiement Nodejs en utilisant ce yaml :

apiVersion: v1
kind: Service
metadata:
  name: node
  namespace: demo
spec:
  ports:
  - port: 8888
    protocol: "TCP"
    name: "cluster-tcp-8888"
  clusterIP: None
  selector:
    app: node-pod

---

apiVersion: apps/v1
kind: Deployment
metadata:
  name: node-pod
  namespace: demo
spec:
  selector:
    matchLabels:
      app: node-pod
  replicas: 3
  template:
    metadata:
      labels:
        app: node-pod
    spec:
      containers:
      - name: node-pod
        image: nvbeta/node

Créer le service et le déploiement Nginx en utilisant ce yaml :

apiVersion: v1
kind: Service
metadata:
  name: nginx-webui
  namespace: demo
spec:
  ports:
    - port: 80
      name: webui
      protocol: TCP
  type: NodePort
  selector:
    app: nginx-pod

---

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-pod
  namespace: demo
spec:
  selector:
    matchLabels:
      app: nginx-pod
  template:
    metadata:
      labels:
        app: nginx-pod
    spec:
      containers:
      - name: nginx-pod
        image: nvbeta/swarm_nginx
        ports:
        - containerPort: 80
          protocol: TCP

Pour accéder au service Nginx-webui de l’extérieur, trouvez le port aléatoire qui lui est attribué (mappé au port 80) par le NodePort :

kubectl get svc -n demo

Puis connectez-vous à l’adresse IP publique/port de l’un des nœuds Kubernetes, par exemple http://(public_IP):(NodePort)

Après avoir déployé SUSE® Security, vous pouvez faire passer du trafic de test à travers les applications de démonstration pour générer les règles de liste blanche, puis déplacer tous les services en mode Monitor ou Protection pour voir les violations et les attaques.

Génération de violations réseau sur Kubernetes

Pour générer une violation à partir d’un pod nodejs, trouvez un pod :

kubectl get pod -n demo

Ensuite, essayez quelques violations (remplacez node-pod-name) :

kubectl exec node-pod-name curl www.google.com -n demo

Ou trouvez l’adresse IP interne d’un autre pod node, comme 172.30.2.21 dans l’exemple ci-dessous, pour vous connecter d’un nœud à un autre :

kubectl exec node-pod-name curl 172.30.2.21:8888 -n demo

Générez une menace/attaque

Pour simuler une attaque, connectez-vous à un conteneur, puis essayez une attaque par ping :

kubectl exec -it node-pod-name bash -n demo

Utilisez l’IP interne d’un autre pod node :

ping 172.30.2.21 -s 40000

Pour tout ce qui précède, vous pouvez consulter les événements de sécurité dans la carte d’activité réseau de la console SUSE® Security, ainsi que dans l’onglet Notifications.

Tests de protection des processus et des fichiers

Essayez diverses activités de processus et de fichiers en exécutant des commandes telles que apt-get update, ssh, scp ou d’autres dans un conteneur. Toute activité de processus ou accès à un fichier non autorisé générera des alertes dans les Notifications.

Analyse de registre et contrôle d’admission

Un test populaire consiste à configurer l’analyse d’images d’un registre dans les Actifs → Registres. Après la fin de l’analyse, configurez une règle de contrôle d’admission dans la stratégie. Assurez-vous d’activer les contrôles d’admission et de définir une règle pour refuser lorsqu’il y a de fortes vulnérabilités dans une image. Ensuite, choisissez une image ayant de fortes vulnérabilités et essayez de la déployer sur Kubernetes. Le déploiement sera bloqué en mode Protection et vous verrez un événement dans les Notifications → Risques de sécurité.

Des tests de contrôle d’admission plus avancés peuvent être effectués en utilisant différents critères dans les règles, ou en combinant des critères.

Déployez une autre application

L’application de démonstration Kubernetes Guestbook peut également être déployée sur Kubernetes. Il est recommandé de la déployer dans son propre espace de noms afin que vous puissiez voir le filtrage basé sur l’espace de noms dans SUSE® Security la console.

Plan de test natif Docker

Après avoir déployé les SUSE® Security composants et l’application(s) exemple, vous pourrez découvrir, surveiller et protéger les conteneurs en cours d’exécution. Le plan de test ci-dessous fournit des suggestions pour générer des violations du comportement autorisé de l’application et scanner les conteneurs pour détecter des vulnérabilités.

SUSE® Security Plan de test

Si le lien ci-dessus ne fonctionne pas, vous pouvez le télécharger depuis notre site web en utilisant le mot de passe nv1851blvd.

SUSE® Security peut également détecter des menaces pour vos conteneurs telles que des attaques DDOS. Si vous exécutez un outil pour générer de telles attaques sur vos conteneurs, ces résultats apparaîtront dans l’activité réseau et dans le tableau de bord.

Par exemple, une simple commande ping avec une charge utile élevée affichera l’attaque Ping.Death dans la console. Pour essayer cela, faites ce qui suit à l’adresse IP de l’un des conteneurs (IP interne du conteneur).

ping <container_ip> -s 40000

Dans Kubernetes, vous pouvez le faire depuis n’importe quel nœud, y compris le maître. Dans d’autres environnements, vous devrez peut-être être connecté au nœud où le conteneur s’exécute.