서버구축 (WEB,DB)

클라우드 환경별 Wazuh 클러스터 매니저 구성 및 에이전트 등록 방법

날으는물고기 2024. 8. 31. 00:35

Wazuh를 설치하는 방법은 사용하는 환경에 따라 다를 수 있습니다. 여기서는 Amazon EKS(Elastic Kubernetes Service)를 사용하는 경우와 그 외의 Kubernetes 클러스터에 설치하는 경우에 대해서 구성하는 방법입니다.

EKS 클러스터에 Wazuh 설치

EKS 클러스터에 Wazuh를 설치하기 위해서는 AWS의 관리형 Kubernetes 서비스를 활용합니다. 다음은 EKS 클러스터에 Wazuh를 설치하는 단계별 가이드입니다.

1. EKS 클러스터 설정

EKS 클러스터를 설정해야 합니다. AWS CLI를 사용하여 클러스터를 생성할 수 있습니다.

# EKS 클러스터 생성
aws eks create-cluster \
    --name my-cluster \
    --role-arn arn:aws:iam::YOUR_ACCOUNT_ID:role/EKS-Role \
    --resources-vpc-config subnetIds=subnet-abc123,subnet-def456,securityGroupIds=sg-123456

2. kubectl 및 eksctl 설정

EKS 클러스터와 상호작용하기 위해 kubectl 및 eksctl을 설정해야 합니다.

# AWS CLI 구성
aws configure

# eksctl 설치 및 구성
brew tap weaveworks/tap
brew install weaveworks/tap/eksctl

# kubectl 설치
brew install kubectl

3. Wazuh Helm 차트 사용하여 설치

Wazuh Helm 차트를 사용하여 Wazuh를 설치할 수 있습니다.

# Helm 저장소 추가
helm repo add wazuh https://packages.wazuh.com/4.x/helm/

# Helm 저장소 업데이트
helm repo update

# Wazuh 설치
helm install wazuh wazuh/wazuh

Deploying Wazuh on Kubernetes using AWS EKS

일반 Kubernetes 클러스터에 Wazuh 설치

Kubernetes 클러스터에 Wazuh를 설치하는 방법도 유사합니다. EKS와는 다른 클러스터 설정 방법을 사용할 수 있습니다.

1. Kubernetes 클러스터 설정

Kubernetes 클러스터를 설정합니다. 예를 들어, Minikube를 사용할 수 있습니다.

# Minikube 클러스터 시작
minikube start

2. kubectl 설치 및 설정

Kubernetes 클러스터와 상호작용하기 위해 kubectl을 설치하고 설정합니다.

# kubectl 설치
brew install kubectl

# 클러스터에 연결
kubectl config use-context minikube

3. Wazuh 설치

Wazuh Helm 차트를 사용하여 설치할 수 있습니다.

# Helm 설치
brew install helm

# Helm 저장소 추가
helm repo add wazuh https://packages.wazuh.com/4.x/helm/

# Helm 저장소 업데이트
helm repo update

# Wazuh 설치
helm install wazuh wazuh/wazuh

공통 설치 후 구성

설치가 완료되면 Wazuh의 설정을 필요에 맞게 조정해야 합니다. 주요 설정 파일 및 자원들은 Helm 차트 값을 통해 구성할 수 있습니다.

Wazuh 구성 파일 예시

Helm 차트의 values.yaml 파일을 수정하여 설정을 변경할 수 있습니다.

# values.yaml 예시
wazuh:
  image:
    repository: wazuh/wazuh
    tag: "4.3.10"
  elasticsearch:
    hosts: "http://elasticsearch:9200"
  filebeat:
    output:
      elasticsearch:
        hosts: "http://elasticsearch:9200"

수정 후 다음 명령어로 설정을 적용합니다.

helm upgrade wazuh wazuh/wazuh -f values.yaml

이와 같이 Wazuh를 설치 및 구성하여 사용할 수 있습니다. EKS와 Kubernetes 클러스터에서 설치 과정은 유사하지만, 클러스터 설정 및 관리 방법에 차이가 있을 수 있습니다. 각각의 환경에 맞게 설정을 조정하여 사용하시기 바랍니다.

Warning: spec.template.spec.affinity.podAntiAffinity.preferredDuringSchedulingIgnoredDuringExecution[0].podAffinityTerm.labelSelector: a null labelSelector results in matching no pod

기본 가이드로 구성을 진행 시 위와 같이 labelSelector가 빠져 있어 경고 메시지가 발생한 것으로 보입니다. podAffinityTerm에 labelSelector를 추가하여 문제가 발생하지 않도록 수정해 보겠습니다.

수정된 YAML 구성 파일

아래는 labelSelector를 추가한 수정된 구성 파일입니다.

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: wazuh-manager-worker
  namespace: wazuh
spec:
  replicas: 2
  selector:
    matchLabels:
      app: wazuh-manager
      node-type: worker
  serviceName: wazuh-cluster
  podManagementPolicy: Parallel
  template:
    metadata:
      labels:
        app: wazuh-manager
        node-type: worker
      name: wazuh-manager-worker
    spec:
      affinity:
        podAntiAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
            - weight: 100
              podAffinityTerm:
                labelSelector:
                  matchExpressions:
                    - key: app
                      operator: In
                      values:
                        - wazuh-manager
                topologyKey: kubernetes.io/hostname
      volumes:
        - name: config
          configMap:
            name: wazuh-conf
        - name: filebeat-certs
          secret:
            secretName: indexer-certs
  • labelSelector가 podAffinityTerm 내에 추가되었습니다.
  • matchExpressions를 사용하여 app: wazuh-manager 레이블을 가진 pod를 일치시켰습니다.

적용 방법

수정된 구성 파일을 적용하려면 아래 명령어를 사용하십시오.

kubectl apply -f your-modified-deployment.yaml

구성 파일이 성공적으로 적용되면, pod가 새로운 반-친화성 규칙에 따라 스케줄링되는지 확인하십시오.

배포 상태 확인

kubectl get pods -n wazuh -l app=wazuh-manager,node-type=worker

이 단계를 통해 labelSelector가 올바르게 지정되었는지 확인할 수 있습니다. 만약 여전히 문제가 발생한다면 로그를 통해 자세한 원인을 파악하고 추가적인 수정이 필요할 수 있습니다.

kubectl logs <pod-name> -n wazuh

이와 같이 수정된 구성을 적용하면 labelSelector와 관련된 경고를 해결하고 Wazuh의 설치 및 운영이 원활하게 진행될 것입니다.

Auto-scalable Wazuh Cluster with Docker-Compose

Minikube 설치하지 않고 Docker Desktop을 사용하여 Kubernetes를 활성화하고 구성하는 경우 아래 메세지가 발생할 수 있습니다.

Waiting for a volume to be created either by the external provisioner 'microk8s.io/hostpath' or manually by the system administrator. If volume creation is delayed, please verify that the provisioner is running and correctly registered.

이 오류 메시지는 Kubernetes 클러스터에서 PersistentVolume(PV)을 생성하는 동안 문제가 발생했음을 나타냅니다. 이 문제를 해결하려면 외부 프로비저너('microk8s.io/hostpath')가 올바르게 실행되고 등록되었는지 확인해야 합니다. Docker Desktop의 Kubernetes 설정에서 비슷한 문제가 발생할 수 있으므로, 이를 해결하는 방법을 안내해드리겠습니다.

1. StorageClass 및 PersistentVolume 확인

StorageClass와 PersistentVolume이 올바르게 설정되었는지 확인합니다. Docker Desktop에서 기본적으로 제공하는 StorageClass를 사용할 수 있습니다.

StorageClass 확인

기본 StorageClass가 올바르게 설정되어 있는지 확인합니다.

kubectl get storageclass

출력 결과에 hostpath 또는 standard와 같은 기본 StorageClass가 포함되어 있는지 확인합니다.

StorageClass 생성

기본 StorageClass가 없으면 다음과 같이 생성할 수 있습니다.

# storageclass.yaml
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: standard
provisioner: docker.io/hostpath
reclaimPolicy: Retain
volumeBindingMode: Immediate
kubectl apply -f storageclass.yaml

2. PersistentVolume 및 PersistentVolumeClaim 설정

PersistentVolume과 PersistentVolumeClaim이 올바르게 설정되었는지 확인합니다.

PersistentVolume 생성

# persistent-volume.yaml
apiVersion: v1
kind: PersistentVolume
metadata:
  name: wazuh-pv
spec:
  capacity:
    storage: 10Gi
  accessModes:
    - ReadWriteOnce
  hostPath:
    path: /mnt/data
  storageClassName: standard

PersistentVolumeClaim 생성

# persistent-volume-claim.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: wazuh-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi
  storageClassName: standard

YAML 파일 적용

kubectl apply -f persistent-volume.yaml
kubectl apply -f persistent-volume-claim.yaml

3. PVC 상태 확인 및 문제 해결

PVC가 올바르게 바인딩되었는지 확인합니다.

kubectl get pvc

PVC 상태가 Bound인지 확인합니다. 그렇지 않으면 추가적인 문제 해결이 필요합니다.

PV 상태 확인

PV 상태를 확인합니다.

kubectl get pv

PV 상태가 Available 또는 Bound인지 확인합니다. 그렇지 않으면 PV가 올바르게 생성되지 않았을 수 있습니다.

4. Provisioner 로그 확인

Provisioner가 올바르게 작동하는지 확인하기 위해 로그를 확인합니다.

kubectl logs <provisioner-pod-name> -n kube-system

Docker Desktop의 경우, 로그를 확인하여 프로비저너가 제대로 작동하고 있는지 확인해야 합니다.

5. Wazuh StatefulSet 적용

위의 설정이 완료된 후, Wazuh StatefulSet을 적용합니다.

# wazuh-statefulset.yaml
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: wazuh-manager-worker
  namespace: default
spec:
  replicas: 2
  selector:
    matchLabels:
      app: wazuh-manager
      node-type: worker
  serviceName: wazuh-cluster
  podManagementPolicy: Parallel
  template:
    metadata:
      labels:
        app: wazuh-manager
        node-type: worker
      name: wazuh-manager-worker
    spec:
      affinity:
        podAntiAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
            - weight: 100
              podAffinityTerm:
                labelSelector:
                  matchExpressions:
                    - key: app
                      operator: In
                      values:
                        - wazuh-manager
                topologyKey: kubernetes.io/hostname
      volumes:
        - name: config
          configMap:
            name: wazuh-conf
        - name: filebeat-certs
          secret:
            secretName: indexer-certs
        - name: wazuh-storage
          persistentVolumeClaim:
            claimName: wazuh-pvc
      containers:
      - name: wazuh-manager
        image: wazuh/wazuh
        volumeMounts:
          - mountPath: /var/ossec/data
            name: wazuh-storage
kubectl apply -f wazuh-statefulset.yaml

이 단계를 통해 PersistentVolume과 PersistentVolumeClaim을 올바르게 설정하고 Wazuh 설치 문제를 해결할 수 있습니다. 문제가 계속 발생하면 추가적인 로그 분석과 설정 검토가 필요할 수 있습니다.

 

위에서 설명했듯이 Mac에서 Docker Desktop을 사용하는 경우, Microk8s와 관련된 설정이 아닌 Docker Desktop의 기본 설정을 사용해야 합니다. Microk8s는 Ubuntu에서 주로 사용되는 경량 Kubernetes 배포판이며, Docker Desktop과는 다른 환경입니다. Docker Desktop의 Kubernetes 환경에서 올바르게 작동하도록 구성 파일을 수정해야 합니다.

Docker Desktop에서는 docker.io/hostpath 프로비저너를 사용하는 StorageClass를 설정해야 합니다. 아래는 Docker Desktop에서 사용할 수 있는 올바른 설정입니다.

1. StorageClass 설정

Docker Desktop에서 사용할 수 있는 StorageClass를 정의합니다.

# storageclass.yaml
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: wazuh-storage
provisioner: docker.io/hostpath
reclaimPolicy: Delete
volumeBindingMode: Immediate

2. PersistentVolume 및 PersistentVolumeClaim 설정

StorageClass 이름을 wazuh-storage로 맞춘 PersistentVolume과 PersistentVolumeClaim을 설정합니다.

# persistent-volume.yaml
apiVersion: v1
kind: PersistentVolume
metadata:
  name: wazuh-pv
spec:
  capacity:
    storage: 10Gi
  accessModes:
    - ReadWriteOnce
  hostPath:
    path: /mnt/data
  storageClassName: wazuh-storage
# persistent-volume-claim.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: wazuh-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi
  storageClassName: wazuh-storage

3. 설정 적용

수정된 YAML 파일을 적용합니다.

kubectl apply -f storageclass.yaml
kubectl apply -f persistent-volume.yaml
kubectl apply -f persistent-volume-claim.yaml

4. Wazuh StatefulSet 업데이트

StatefulSet에서 PVC를 사용하도록 설정합니다.

# wazuh-statefulset.yaml
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: wazuh-manager-worker
  namespace: default
spec:
  replicas: 2
  selector:
    matchLabels:
      app: wazuh-manager
      node-type: worker
  serviceName: wazuh-cluster
  podManagementPolicy: Parallel
  template:
    metadata:
      labels:
        app: wazuh-manager
        node-type: worker
      name: wazuh-manager-worker
    spec:
      affinity:
        podAntiAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
            - weight: 100
              podAffinityTerm:
                labelSelector:
                  matchExpressions:
                    - key: app
                      operator: In
                      values:
                        - wazuh-manager
                topologyKey: kubernetes.io/hostname
      volumes:
        - name: config
          configMap:
            name: wazuh-conf
        - name: filebeat-certs
          secret:
            secretName: indexer-certs
        - name: wazuh-storage
          persistentVolumeClaim:
            claimName: wazuh-pvc
      containers:
      - name: wazuh-manager
        image: wazuh/wazuh
        volumeMounts:
          - mountPath: /var/ossec/data
            name: wazuh-storage

5. 적용 및 확인

수정된 StatefulSet을 적용합니다.

kubectl apply -f wazuh-statefulset.yaml

PVC가 올바르게 바인딩되었는지 확인합니다.

kubectl get pvc
kubectl get pv
kubectl get pods -n default

이 단계를 통해 Docker Desktop의 Kubernetes 환경에서 Wazuh를 실행할 수 있습니다. Microk8s와 관련된 설정을 제거하고 Docker Desktop에 맞는 설정으로 변경하면 문제가 해결될 것입니다. PersistentVolume(PV) 및 PersistentVolumeClaim(PVC)이 모두 정상적으로 생성되고 바인딩이 되었는데, 또 다른 오류 메시지를 받고 있는 경우, 몇 가지 추가적인 문제 해결 단계를 확인해보겠습니다.

1. Namespace 확인

우리가 사용하는 모든 리소스가 동일한 네임스페이스에 속해 있는지 확인합니다. 현재 PV와 PVC는 wazuh 네임스페이스에 있습니다. StatefulSet이나 다른 리소스도 동일한 네임스페이스에 있는지 확인합니다.

2. StatefulSet 상태 확인

StatefulSet이 정상적으로 생성되고 실행되고 있는지 확인합니다.

kubectl get statefulsets -n wazuh

StatefulSet의 상태를 확인하고, 만약 오류가 발생한 경우, describe 명령어를 통해 자세한 내용을 확인합니다.

kubectl describe statefulset <your-statefulset-name> -n wazuh

3. Pod 상태 확인

Pod가 정상적으로 실행되고 있는지 확인합니다.

kubectl get pods -n wazuh

Pod의 상태가 Running인지 확인하고, 그렇지 않은 경우 describe 명령어를 통해 자세한 내용을 확인합니다.

kubectl describe pod <your-pod-name> -n wazuh

4. 이벤트 확인

Kubernetes 이벤트를 통해 추가적인 문제를 파악할 수 있습니다.

kubectl get events -n wazuh

5. 로그 확인

Pod의 로그를 확인하여 문제가 무엇인지 파악할 수 있습니다.

kubectl logs <your-pod-name> -n wazuh

6. StorageClass 프로비저너 확인

StorageClass에서 사용 중인 프로비저너가 올바르게 작동하고 있는지 확인합니다. Docker Desktop에서는 docker.io/hostpath 프로비저너를 사용해야 합니다.

kubectl get storageclass wazuh-storage -o yaml

위 명령어를 통해 StorageClass의 설정을 다시 확인합니다.

7. StatefulSet 구성 파일 예시

StatefulSet이 올바르게 구성되어 있는지 다시 한번 확인합니다.

# wazuh-statefulset.yaml
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: wazuh-manager-worker
  namespace: wazuh
spec:
  replicas: 2
  selector:
    matchLabels:
      app: wazuh-manager
      node-type: worker
  serviceName: wazuh-cluster
  podManagementPolicy: Parallel
  template:
    metadata:
      labels:
        app: wazuh-manager
        node-type: worker
    spec:
      affinity:
        podAntiAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
            - weight: 100
              podAffinityTerm:
                labelSelector:
                  matchExpressions:
                    - key: app
                      operator: In
                      values:
                        - wazuh-manager
                topologyKey: kubernetes.io/hostname
      volumes:
        - name: wazuh-storage
          persistentVolumeClaim:
            claimName: wazuh-pvc
      containers:
      - name: wazuh-manager
        image: wazuh/wazuh
        volumeMounts:
          - mountPath: /var/ossec/data
            name: wazuh-storage

8. PVC와 PV의 상태 재확인

PVC와 PV가 올바르게 연결되어 있는지 다시 한번 확인합니다.

kubectl describe pvc wazuh-indexer-wazuh-indexer-0 -n wazuh
kubectl describe pvc wazuh-manager-master-wazuh-manager-master-0 -n wazuh
kubectl describe pvc wazuh-manager-worker-wazuh-manager-worker-0 -n wazuh
kubectl describe pv pvc-50ebfda7-2993-4ced-93e9-871b5516a80d -n wazuh
kubectl describe pv pvc-60dd1152-3096-4d69-94ae-8d6016c42c4e -n wazuh
kubectl describe pv pvc-b5ce5843-6c89-40a6-a3b3-a8a9f8012b56 -n wazuh

이 단계를 통해 추가적인 문제를 파악하고 해결할 수 있습니다.

Configuration management of Wazuh endpoints using Ansible

system call filters failed to install 오류는 주로 컨테이너 환경에서 OpenSearch와 같은 검색 엔진을 실행할 때 발생할 수 있습니다. OpenSearch는 특정 시스템 호출 필터를 요구하며, 이는 보안 강화를 위한 것입니다. 그러나 이러한 필터가 Docker Desktop 또는 Kubernetes 환경에서 올바르게 설치되지 않는 경우가 있습니다.

이 문제를 해결하기 위해 system_call_filter를 비활성화할 수 있습니다. 이는 보안 측면에서 다소 위험할 수 있지만, 개발 환경에서는 유용할 수 있습니다. 다음은 OpenSearch 구성 파일에서 해당 설정을 비활성화하는 방법입니다.

1. ConfigMap 수정

Wazuh Indexer의 설정 파일을 포함하는 ConfigMap을 수정합니다. opensearch.yml 파일에서 bootstrap.system_call_filter 설정을 비활성화해야 합니다.

# wazuh-configmap.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: wazuh-indexer-config
  namespace: wazuh
data:
  opensearch.yml: |
    cluster.name: wazuh-cluster
    network.host: 0.0.0.0
    bootstrap.memory_lock: false
    node.name: ${HOSTNAME}
    path.data: /usr/share/opensearch/data
    path.logs: /usr/share/opensearch/logs
    discovery.seed_hosts: ["wazuh-indexer"]
    cluster.initial_master_nodes: ["wazuh-indexer"]
    bootstrap.system_call_filter: false  # 추가된 부분

2. ConfigMap 적용

수정된 ConfigMap을 적용합니다.

kubectl apply -f wazuh-configmap.yaml

3. StatefulSet 재시작

ConfigMap 변경 사항을 적용하기 위해 Wazuh Indexer StatefulSet을 재시작합니다.

kubectl rollout restart statefulset wazuh-indexer -n wazuh

로그 확인

재시작 후, Wazuh Indexer의 로그를 다시 확인하여 문제가 해결되었는지 확인합니다.

kubectl logs <wazuh-indexer-pod-name> -n wazuh

위 단계를 통해 system_call_filter 문제를 해결할 수 있습니다.

Wazuh Logcollector에서 발생하는 "Error during select()-call due to [(4)-(Interrupted system call)]" 오류는 시스템 호출이 인터럽트에 의해 중단될 때 발생하는 오류입니다. 이 오류는 컨테이너 환경 또는 Kubernetes 설정 문제로 인해 발생할 수 있습니다.

1. Wazuh 구성 파일 수정

Wazuh 구성 파일을 확인하고 필요에 따라 수정합니다. 예를 들어, ossec.conf 파일에서 Logcollector 설정을 확인하고 수정합니다.

<ossec_config>
  <global>
    <logcollector>
      <disabled>no</disabled>
    </logcollector>
  </global>
</ossec_config>

2. Kubernetes 리소스 재확인 및 재배포

Wazuh 관련 Kubernetes 리소스를 재확인하고, 필요하다면 재배포합니다. 구성 파일이 올바른지 확인합니다.

ConfigMap 확인

# wazuh-configmap.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: wazuh-config
  namespace: wazuh
data:
  ossec.conf: |
    <ossec_config>
      <global>
        <logcollector>
          <disabled>no</disabled>
        </logcollector>
      </global>
    </ossec_config>

ConfigMap 적용

수정된 ConfigMap을 적용합니다.

kubectl apply -f wazuh-configmap.yaml

Wazuh StatefulSet 재시작

kubectl rollout restart statefulset wazuh-manager-worker -n wazuh

3. 호스트 시스템 확인 및 설정

호스트 시스템의 리소스 사용량을 확인하고, 필요한 경우 리소스를 조정합니다. 특히 메모리와 CPU 사용량을 확인합니다.

kubectl top nodes
kubectl top pods -n wazuh

4. Docker Desktop 설정 확인

Docker Desktop 설정을 확인하여 리소스 제한을 조정합니다.

Docker Desktop 설정

  1. Docker Desktop 열기.
  2. Preferences(설정) 클릭.
  3. Resources(리소스) 탭에서 CPU, Memory, Disk 등의 리소스 제한을 조정.

5. Kubernetes 로그 확인

Kubernetes 이벤트 로그를 확인하여 추가적인 문제를 파악합니다.

kubectl get events -n wazuh

6. 네트워크 문제 확인

네트워크 설정을 확인하고, 네트워크 문제로 인해 시스템 호출이 중단되지 않는지 확인합니다. 네트워크 정책이나 방화벽 설정을 점검합니다.

kubectl describe pod <wazuh-pod-name> -n wazuh

위 단계를 통해 Wazuh Logcollector의 오류를 해결할 수 있습니다.

 

Wazuh Manager 환경이 준비되었다면 이제 에이전트를 설치하고 매니저에 등록하는 과정은 운영 체제마다 조금씩 다르며, 이 과정에서는 CentOS, Windows, MacOS 세 가지 운영 체제에서의 설정 방법을 각각 설명하겠습니다.

CentOS에서 Wazuh 에이전트 설치 및 매니저 등록

1. Wazuh 리포지토리 추가

sudo rpm --import https://packages.wazuh.com/key/GPG-KEY-WAZUH
cat << EOF | sudo tee /etc/yum.repos.d/wazuh.repo
[wazuh]
gpgcheck=1
gpgkey=https://packages.wazuh.com/key/GPG-KEY-WAZUH
enabled=1
name=Wazuh repository
baseurl=https://packages.wazuh.com/4.x/yum/
protect=1
EOF

2. Wazuh 에이전트 설치

sudo yum install wazuh-agent -y

3. 매니저 IP 주소 설정

/var/ossec/etc/ossec.conf 파일에서 <server> 태그 안에 Wazuh 매니저의 IP 주소를 입력합니다.

<agent_config>
  <name>Wazuh</name>
  <server>
    <address>MANAGER_IP_ADDRESS</address>
  </server>
</agent_config>

4. 에이전트 등록을 위한 인증 키 생성 (매니저 측)

매니저 서버에서 인증 키를 생성합니다. 다음 명령어를 사용하여 인증 키를 생성합니다.

sudo /var/ossec/bin/manage_agents
  • manage_agents 스크립트를 실행하면 메뉴가 나타납니다. 여기서 A를 선택하여 새로운 에이전트를 추가합니다.
  • 에이전트의 이름과 그룹을 입력한 후, 인증 키가 생성됩니다.
  • 생성된 인증 키를 저장해 두십시오. 나중에 에이전트 등록에 필요합니다.

5. 에이전트에서 인증 키를 사용해 매니저에 등록

에이전트 측에서 다음 명령어를 사용하여 매니저에 등록합니다.

sudo /var/ossec/bin/agent-auth -m MANAGER_IP_ADDRESS -P AUTH_KEY
  • 여기서 MANAGER_IP_ADDRESS는 매니저의 IP 주소이며, AUTH_KEY는 앞서 매니저에서 생성한 인증 키입니다.

6. 에이전트 시작 및 자동 시작 설정

sudo systemctl enable wazuh-agent
sudo systemctl start wazuh-agent

Windows에서 Wazuh 에이전트 설치 및 매니저 등록

1. Wazuh 에이전트 설치 파일 다운로드 및 설치

Wazuh 공식 웹사이트에서 Windows 에이전트 설치 파일을 다운로드합니다. Wazuh Windows Agent.

설치 파일을 실행하여 설치합니다. 설치 중 Configuration options 단계에서 매니저의 IP 주소를 입력합니다.

2. 매니저에서 인증 키 생성

매니저에서 다음 명령어로 인증 키를 생성합니다.

sudo /var/ossec/bin/manage_agents
  • Windows 에이전트를 위한 인증 키를 생성합니다. 생성된 키를 기록해 두십시오.

3. 에이전트에서 인증 키를 사용해 매니저에 등록

Windows 에이전트에서 agent-auth.exe를 사용하여 매니저에 등록합니다. cmd.exe를 관리자 권한으로 열고 다음 명령어를 입력합니다.

cd "C:\Program Files (x86)\ossec-agent\"
agent-auth.exe -m MANAGER_IP_ADDRESS -P AUTH_KEY
  • MANAGER_IP_ADDRESS는 매니저의 IP 주소, AUTH_KEY는 매니저에서 생성한 인증 키입니다.

4. 에이전트 서비스 시작 및 자동 시작 설정

설치 후 Wazuh 에이전트 서비스가 자동으로 시작됩니다. 수동으로 시작하려면 서비스 관리에서 Wazuh Agent 서비스를 시작할 수 있습니다.

macOS에서 Wazuh 에이전트 설치 및 매니저 등록

1. Homebrew 설치 (설치되지 않은 경우)

Homebrew가 설치되어 있지 않다면, 다음 명령어로 설치합니다.

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

2. Wazuh 에이전트 설치

brew tap wazuh/wazuh
brew install wazuh-agent

3. 매니저에서 인증 키 생성

매니저에서 인증 키를 생성합니다.

sudo /var/ossec/bin/manage_agents
  • macOS 에이전트를 위한 인증 키를 생성합니다. 생성된 키를 기록해 두십시오.

4. 에이전트에서 인증 키를 사용해 매니저에 등록

macOS 에이전트에서 다음 명령어를 사용하여 매니저에 등록합니다.

sudo /usr/local/bin/agent-auth -m MANAGER_IP_ADDRESS -P AUTH_KEY
  • MANAGER_IP_ADDRESS는 매니저의 IP 주소, AUTH_KEY는 매니저에서 생성한 인증 키입니다.

5. 에이전트 시작 및 자동 시작 설정

sudo /usr/local/bin/wazuh-control start
sudo launchctl load /Library/LaunchDaemons/com.wazuh.agent.plist

매니저에서 에이전트 상태 확인

모든 운영 체제에서 에이전트를 매니저에 등록한 후, 매니저에서 다음 명령어로 에이전트의 상태를 확인할 수 있습니다.

sudo /var/ossec/bin/agent_control -l

위의 모든 절차를 완료하면 Wazuh 에이전트가 매니저에 성공적으로 등록되고, 매니저와 에이전트 간의 통신이 보안된 상태로 이루어집니다. 인증 키를 사용한 등록 절차를 통해 에이전트의 신뢰성을 보장할 수 있습니다.

728x90
저작자표시 비영리 동일조건