Avaliação e Teste SUSE® Security

Aplicativos de Exemplo

Depois de implantar os componentes SUSE® Security, você pode avaliá-los usando os aplicativos de teste de exemplo que fornecemos. Estes estão localizados no repositório 'nvbeta no Docker Hub.

Um ambiente de teste típico baseado em Kubernetes teria um nó mestre e de dois a três nós de trabalho. Você pode controlar se os pods de aplicação e os contêineres SUSE® Security são implantados em um nó mestre (desativado por padrão).

Plano de Teste do Kubernetes

Para implantar uma aplicação de múltiplas camadas usando Nginx, Nodejs e Redis, use os exemplos abaixo (na ordem abaixo). Esses podem precisar ser editados para implantação no OpenShift, Rancher e outras ferramentas baseadas em Kubernetes.

Crie um namespace de demonstração

kubectl create namespace demo

O exemplo abaixo usa apiVersion: apps/v1 exigido pelo Kubernetes 1.16+.

Crie o serviço e a implantação do Redis usando este 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

Crie o serviço e a implantação do Nodejs usando este 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

Crie o serviço e a implantação do Nginx usando este 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

Para acessar o serviço Nginx-webui externamente, encontre a porta aleatória atribuída a ele (mapeada para a porta 80) pelo NodePort:

kubectl get svc -n demo

Em seguida, conecte-se ao endereço IP público/porta de um dos nós do Kubernetes, por exemplo, http://(public_IP):(NodePort)

Depois de implantar SUSE® Security, você pode executar tráfego de teste através dos aplicativos de demonstração para gerar as regras de lista branca e, em seguida, mover todos os serviços para o modo Monitorar ou Proteger para ver violações e ataques.

Gerando Violações de Rede no Kubernetes

Para gerar uma violação a partir de um pod nodejs, encontre um pod:

kubectl get pod -n demo

Então, tente algumas violações (substitua node-pod-name):

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

Ou encontre o endereço IP interno de outro pod de nó, como 172.30.2.21 no exemplo abaixo, para conectar de um nó a outro:

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

Gerar uma Ameaça/Ataque

Para simular um ataque, faça login em um contêiner e tente um ataque de ping:

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

Use o IP interno de outro pod de nó:

ping 172.30.2.21 -s 40000

Para todos os itens acima, você pode visualizar os eventos de segurança no console SUSE® Security Mapa de Atividade de Rede, bem como na aba de Notificações.

Testes de Proteção de Processos e Arquivos

Tente várias atividades de processo e arquivo acessando um contêiner e executando comandos como apt-get update, ssh, scp ou outros. Qualquer atividade de processo ou acesso a arquivos não permitido gerará alertas nas Notificações.

Escaneamento de Registro e Controle de Admissão

Um teste popular é configurar o escaneamento de imagens de um registro em Ativos → Registros. Após a conclusão da varredura, configure uma regra de Controle de Admissão na Política. Certifique-se de habilitar os Controles de Admissão e definir uma regra para Negar quando houver altas vulnerabilidades em uma imagem. Então, escolha uma imagem que tenha altas vulnerabilidades e tente implantá-la no Kubernetes. A implantação será bloqueada no modo Proteger e você verá um evento nas Notificações → Riscos de Segurança.

Testes de controle de admissão mais avançados podem ser realizados usando diferentes critérios em regras ou combinando critérios.

Implantar Outro Aplicativo

O aplicativo de demonstração Guestbook do Kubernetes também pode ser implantado no Kubernetes. Recomenda-se implantá-lo em seu próprio namespace para que você possa ver a filtragem baseada em namespace no console SUSE® Security.

Plano de teste nativo do Docker

Após implantar os componentes SUSE® Security e o(s) aplicativo(s) de exemplo, você poderá Descobrir, Monitorar e Proteger os contêineres em execução. O plano de teste abaixo fornece sugestões para gerar violações em tempo de execução do comportamento permitido do aplicativo e escanear contêineres em busca de vulnerabilidades.

SUSE® Security Plano de Teste

Se o link acima não funcionar, você pode baixá-lo do nosso site usando a senha nv1851blvd.

SUSE® Security também pode detectar ameaças aos seus contêineres, como ataques DDOS. Se você executar uma ferramenta para gerar tais ataques em seus contêineres, esses resultados aparecerão na Atividade de Rede e no Painel.

Por exemplo, um simples comando de ping com alta carga mostrará o ataque Ping.Death no console. Para tentar isso, faça o seguinte no endereço IP de um dos contêineres (IP interno do contêiner).

ping <container_ip> -s 40000

No Kubernetes, você pode fazer isso a partir de qualquer nó, incluindo o mestre. Em outros ambientes, pode ser necessário estar logado no nó onde o contêiner está em execução.