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

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에 맞는 설정으로 변경하면 문제가 해결될 것입니다. 안전하게 보존하기 위해 주요 폴더와 파일 용도는 다음과 같습니다.

주요 폴더 및 파일

경로	설명
`/var/ossec/etc/`	🔹 Wazuh 설정 파일 디렉토리 (핵심 설정 정보)
`/var/ossec/etc/ossec.conf`	🔹 Wazuh의 주요 설정 파일 (매니저, 에이전트, 규칙 등)
`/var/ossec/etc/internal_options.conf`	🔹 내부 설정 파일 (성능 튜닝 및 내부 기능 조정)
`/var/ossec/etc/client.keys`	🔹 에이전트 등록 키 정보 (이전 환경 유지 시 필수)
`/var/ossec/queue/`	🔹 Wazuh Manager의 내부 큐 (에이전트 통신 데이터 포함)
`/var/ossec/var/`	🔹 실행 중인 로그 및 이벤트 데이터 저장소
`/var/ossec/logs/`	🔹 Wazuh 로그 파일 (운영 중 발생한 로그)
`/var/ossec/ruleset/`	🔹 기본 및 사용자 정의 룰셋 저장 디렉토리
`/var/ossec/integrations/`	🔹 통합 스크립트 및 외부 연동 설정
`/var/ossec/active-response/`	🔹 액티브 응답 스크립트 (자동 차단 기능 등)
`/var/ossec/stats/`	🔹 Wazuh 통계 정보
`/var/ossec/wodles/`	🔹 Wazuh 모듈 (wodle) 디렉토리
`/var/ossec/database/`	🔹 Wazuh 내부 데이터베이스 (SQLite 기반 데이터 저장소)

모든 핵심 파일을 아카이브하여 한 번에 백업할 수도 있습니다.

sudo tar -czvf wazuh-manager-backup.tar.gz /var/ossec/etc /var/ossec/ruleset /var/ossec/database /var/ossec/queue /var/ossec/var /var/ossec/logs /var/ossec/integrations /var/ossec/wodles

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 설정

Docker Desktop 열기.
Preferences(설정) 클릭.
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 에이전트가 매니저에 성공적으로 등록되고, 매니저와 에이전트 간의 통신이 보안된 상태로 이루어집니다. 인증 키를 사용한 등록 절차를 통해 에이전트의 신뢰성을 보장할 수 있습니다.

Wazuh는 로그를 모니터링할 때 설정된 로그 파일에서 데이터를 수집하고 분석하는데, 로그 양이 많아지면 내부 큐(Buffer)가 초과될 수 있습니다.

Wazuh에서 큐 초과가 발생하는 이유

로그 입력 속도(ingestion rate)가 너무 높음
- Wazuh의 logcollector가 설정된 파일에서 로그를 읽고 처리하는데, 로그 발생량이 많으면 처리 속도를 초과하여 큐가 가득 찰 수 있음.
Wazuh Manager의 이벤트 처리 속도가 느림
- Wazuh Agent가 많은 로그를 보낼 경우, Wazuh Manager가 이를 빠르게 처리하지 못하면 queue가 넘쳐서 일부 로그가 손실될 수 있음.
네트워크 대역폭 제한
- Wazuh Agent와 Manager 간의 네트워크 속도가 느리거나 지연이 발생하면, 데이터가 적체되면서 큐가 초과됨.
디스크 I/O 병목
- Wazuh가 많은 로그 파일을 감시할 때, 디스크 I/O 성능이 낮으면 로그 수집 속도가 저하될 수 있음.

큐 초과 발생 시 확인해야 할 로그 및 설정

Wazuh Agent에서 로그 확인
- Queue is full, some events may be lost 같은 메시지가 있다면 큐 초과 문제 발생
```
cat /var/ossec/logs/ossec.log | grep queue
```
Wazuh Manager의 큐 상태 확인
- var/ossec/queue/alerts/ 경로에 쌓이는 로그가 많아지는지 확인
- Wazuh가 빠르게 처리하지 못하는 로그가 대기 중이라면 문제 발생 가능
로그 수집 속도 제한 설정 (logcollector)
- /var/ossec/etc/ossec.conf 파일에서 logcollector 설정을 조정
```
<localfile>
 <log_format>syslog</log_format>
 <location>/var/log/syslog</location>
 <queue_size>50000</queue_size>  
</localfile>
```
- queue_size 값을 늘려서 로그 손실을 방지

해결 방법

1. 불필요한 로그 필터링

너무 많은 로그 파일을 모니터링하지 않도록 설정 최적화
특정 로그 패턴만 감시하도록 규칙 수정
/var/ossec/ruleset/rules/에서 rules.xml을 수정하여 중요 로그만 분석

2. Agent에서 로그 입력량 제한

/var/ossec/etc/ossec.conf에서 logcollector의 max_lines 조정

<logcollector>
 <max_lines>200</max_lines>  <!-- 한 번에 처리하는 최대 라인 조정 -->
</logcollector>

3. Wazuh Manager의 큐 크기 확장

/var/ossec/etc/internal_options.conf 수정

queue_size=104857600  # 기본값보다 증가 (100MB)

4. 네트워크 대역폭 확인 및 튜닝

Wazuh Agent에서 Manager로 전송 속도가 제한되는지 확인
필요시 ossec.conf에서 frequency 값을 조정하여 로그 전송 주기 변경

5. Wazuh 클러스터 구성 고려

너무 많은 로그를 하나의 Wazuh Manager에서 처리하기 어려우면 클러스터링 고려
여러 개의 Wazuh Manager를 배포하여 로드를 분산 가능

Wazuh에서 많은 로그 파일을 감시할 경우, 로그의 양이 너무 많아지면 큐가 초과될 가능성이 높음. 이를 방지하려면 불필요한 로그를 필터링하고, 큐 크기 조정 및 전송 속도 최적화가 필요함. 필요하다면 Wazuh 클러스터를 고려하여 확장하는 것도 좋은 방법입니다.

Wazuh의 rules.xml 최적화와 실제 로그 수집량 관계

rules.xml을 최적화하더라도 Wazuh가 모니터링하는 로그 파일 자체에서 들어오는 로그 양이 많다면 큐 초과 현상이 발생할 수 있습니다. rules.xml은 수집된 로그를 필터링하여 Alert를 줄이는 역할을 하지만, 실제 로그 수집량에는 영향을 주지 않습니다.

Wazuh에서 로그 수집 흐름

logcollector가 로그 파일을 감시하여 데이터를 수집
- /var/log/syslog, /var/log/auth.log 등의 설정된 파일에서 로그를 읽어옴
수집된 로그를 내부 큐로 저장
- 로그가 들어오는 속도 > 처리 속도라면 큐가 넘칠 가능성이 있음
rules.xml에서 로그를 분석하여 알람(alert) 생성
- 규칙과 일치하는 로그만 Alert로 생성됨
- 하지만 Alert가 줄어들더라도, 로그 수집 자체가 많으면 큐 초과 문제는 그대로 발생

큐 초과 문제를 해결하는 방법

1. 로그 수집 속도를 줄이기

ossec.conf에서 logcollector의 frequency 설정을 조정

   <localfile>
      <log_format>syslog</log_format>
      <location>/var/log/syslog</location>
      <frequency>10</frequency>  <!-- 로그 읽는 주기 (초) -->
   </localfile>

frequency 값을 늘리면 Wazuh가 로그를 읽는 간격이 늘어나므로 부담 감소

max_lines 설정으로 한 번에 처리하는 로그 수 제한

   <logcollector>
      <max_lines>100</max_lines>  <!-- 기본값보다 감소 -->
   </logcollector>

한 번에 너무 많은 로그를 읽지 않도록 제한

2. 큐 크기 증가 (queue_size)

queue_size 설정 조정 (internal_options.conf 수정)

   queue_size=209715200  # 기본 50MB에서 200MB로 증가

큐 크기를 늘려서 초과 발생을 방지

3. 불필요한 로그 수집 제한

ignore 옵션을 사용하여 특정 로그 제외

   <localfile>
      <log_format>syslog</log_format>
      <location>/var/log/syslog</location>
      <ignore>.*DEBUG.*</ignore>  <!-- DEBUG 로그 제외 -->
      <ignore>.*Failed password.*</ignore>  <!-- 특정 이벤트 제외 -->
   </localfile>

4. Wazuh 클러스터 구성 고려

단일 Wazuh Manager에서 너무 많은 로그를 감당할 수 없다면 클러스터링 고려
여러 개의 Wazuh Manager를 배포하여 로그 분석을 분산 가능

✅ rules.xml을 최적화해도 실제 수집되는 로그량이 많으면 큐 초과 발생 가능
✅ 해결 방법: frequency, max_lines, queue_size 조정 & 불필요한 로그 제외
✅ 규모가 크다면 Wazuh 클러스터 구성 고려

즉, rules.xml은 Alert를 줄일 뿐이지 로그 수집량 자체를 제한하지 않으므로, 로그 입력 속도를 직접 관리해야 합니다.

Wazuh에서 모니터링하는 특정 파일의 로그량을 제한하는 방법이 있습니다. 특히 audit 로그의 수집량을 제한하여 다른 중요한 로그의 수집을 보장하려면 다음과 같은 방법을 사용할 수 있습니다.

특정 파일별로 로그 수집량 제한하는 방법

1. logcollector에서 특정 파일의 읽기 주기 조정 (`frequency`)

Wazuh의 logcollector는 특정 파일에서 로그를 읽는 주기(frequency)를 설정할 수 있습니다.
audit 로그만 더 긴 주기로 읽게 조정하면, 다른 로그들의 수집이 방해받지 않습니다.

설정 방법 (/var/ossec/etc/ossec.conf)

<localfile>
   <log_format>audit</log_format>
   <location>/var/log/audit/audit.log</location>
   <frequency>30</frequency>  <!-- 30초마다 읽음 (기본값: 1) -->
</localfile>

<localfile>
   <log_format>syslog</log_format>
   <location>/var/log/syslog</location>
   <frequency>5</frequency>  <!-- 다른 로그는 5초마다 읽음 -->
</localfile>

✅ audit 로그는 30초마다 읽고, 다른 로그는 5초마다 읽도록 설정
✅ 다른 로그 수집이 밀리지 않도록 audit 로그의 우선순위를 낮춤

2. 특정 파일의 최대 수집 라인 제한 (max_lines)

한 번에 읽을 수 있는 최대 로그 줄 수를 조정하여 audit 로그가 너무 많은 경우 일부를 버리도록 설정할 수 있습니다.

설정 방법 (/var/ossec/etc/ossec.conf)

<logcollector>
   <log_format>audit</log_format>
   <location>/var/log/audit/audit.log</location>
   <max_lines>50</max_lines>  <!-- 한 번에 50줄만 읽음 -->
</logcollector>

<logcollector>
   <log_format>syslog</log_format>
   <location>/var/log/syslog</location>
   <max_lines>200</max_lines>  <!-- 다른 로그는 200줄까지 읽음 -->
</logcollector>

✅ audit 로그는 한 번에 50줄만 읽고, 다른 로그는 200줄까지 읽도록 제한
✅ audit 로그가 많아도 일부가 자동으로 소실되면서 다른 로그의 수집을 보장

3. 불필요한 audit 로그 제외 (ignore 옵션 활용)

Audit 로그는 많은 시스템 이벤트를 포함하므로, 중요하지 않은 로그를 필터링하여 수집량을 줄일 수 있습니다.

예제 설정 (/var/ossec/etc/ossec.conf)

<localfile>
   <log_format>audit</log_format>
   <location>/var/log/audit/audit.log</location>
   <ignore>.*AVC.*</ignore>  <!-- SELinux AVC 로그 제외 -->
   <ignore>.*syscall.*</ignore>  <!-- syscall 이벤트 제외 -->
</localfile>

✅ 불필요한 이벤트를 제외하여 로그 수집량을 줄임
✅ 예: SELinux 관련 로그 제외, 특정 syscall 이벤트 제외

4. Wazuh Manager의 큐 크기 확장 (queue_size)

Audit 로그가 많으면 큐가 가득 차서 다른 로그 수집이 중단될 수 있음
이를 방지하려면 Wazuh Manager의 큐 크기를 증가시켜야 합니다.

설정 방법 (/var/ossec/etc/internal_options.conf)

queue_size=209715200  # 기본값보다 증가 (200MB)

✅ 큐 크기를 증가하여 audit 로그로 인해 다른 로그가 밀리는 문제 해결

5. auditd 설정 변경하여 불필요한 이벤트 최소화

Audit 로그가 너무 많다면, auditd에서 기록하는 이벤트 자체를 줄이는 것도 방법입니다.

설정 방법 (/etc/audit/auditd.conf)

max_log_file = 100  # 로그 파일 크기 제한 (MB)
num_logs = 5  # 로그 파일 개수 제한
flush = incremental_async  # 비동기 처리로 성능 개선

불필요한 audit rule 줄이기 (/etc/audit/rules.d/audit.rules)

-a never,exit -F arch=b64 -S mknod,mknodat
-a never,exit -F arch=b64 -S open,openat

기록할 필요 없는 audit 이벤트를 제외하여 Wazuh에 들어오는 로그 양 자체를 줄임

audit 로그가 많아서 큐가 초과되는 경우, 아래 방법을 적용하면 문제를 해결할 수 있습니다.
1️⃣ 파일별로 로그 읽기 주기(frequency)를 조정하여 audit 로그의 우선순위를 낮춤
2️⃣ 파일별로 최대 읽기 줄 수(max_lines)를 제한하여 audit 로그 일부가 자동으로 손실되도록 설정
3️⃣ 불필요한 audit 로그를 ignore 옵션으로 제외하여 수집량 자체를 줄임
4️⃣ Wazuh Manager의 큐 크기(queue_size)를 늘려서 audit 로그로 인해 다른 로그가 밀리는 문제 해결
5️⃣ auditd 설정을 변경하여 audit 로그의 발생량 자체를 조절

이렇게 하면 audit 로그가 많더라도, 다른 중요한 로그가 정상적으로 수집될 수 있도록 조정할 수 있습니다.

Wazuh Agent의 journald 로그 전송 문제 분석 및 해결 방안

1. journald 로그가 멈추는 원인 가능성

Systemd Journal API 관련 문제
- systemd-journald가 오래 실행되면 내부 버퍼 문제가 발생할 수 있음
- journald의 내부 상태가 손상되거나 과부하 상태일 가능성
- journalctl --verify 실행 시 오류가 발생하는지 확인 필요
Wazuh logcollector의 journald 핸들링 문제
- logcollector 프로세스가 journald에서 새로운 로그를 가져오지 못하는 현상
- logcollector가 journald의 로그를 처리하는 중 특정 조건에서 이벤트 스트림이 끊길 가능성
- logcollector.c:2123 at w_input_thread(): DEBUG: (9005): Skipping is not the owner of the journal log. → Wazuh Agent의 권한 문제 가능성
journald 로그가 멈추는 특정 트리거 확인
- logcollector.debug=2 상태에서 journalctl -f를 실행하여 비교
- journald가 특정 시점 이후 새로운 로그를 기록하지 않는다면, journald 자체 문제
- journalctl --vacuum-time=1d 실행하여 오래된 로그 삭제 후 변화 확인

2. 디버깅 기본 점검

journald 서비스 상태 확인
- journalctl --verify에서 오류 발생 시 journald 로그 파일이 손상되었을 가능성이 있음.
- systemctl restart systemd-journald 로 재시작 후 다시 확인.
```
sudo systemctl status systemd-journald
sudo journalctl --verify
```
Wazuh logcollector가 journald 로그를 읽는지 확인
- 실시간으로 journald 로그가 수집되는지 확인.
```
sudo journalctl -f | grep wazuh
```

journald 로그 크기 확인 및 정리

journald 로그가 너무 커서 새 로그를 기록하지 못하는 경우

sudo journalctl --disk-usage
sudo journalctl --vacuum-size=500M  # 500MB 이상일 경우 삭제
sudo journalctl --vacuum-time=7d    # 7일 이상된 로그 삭제

3. Wazuh Agent 설정 변경

internal_options.conf 설정 변경
- agent.debug=2 및 logcollector.debug=2를 설정하면 상세 로그 확인 가능
```
sudo nano /var/ossec/etc/internal_options.conf
```
```
agent.debug=2
logcollector.debug=2
```
- 변경 후 Wazuh Agent 재시작
```
sudo systemctl restart wazuh-agent
```
journald 필터 옵션 제거 후 테스트
- 기존 설정에서 _SYSTEMD_UNIT 필터를 제거하여 모든 journald 로그를 수집
```
<localfile>
  <log_format>journald</log_format>
  <location>journald</location>
</localfile>
```
- 특정 필터링이 문제를 유발하는지 확인

4. 시스템 및 서비스 문제 해결

journald 재시작
- journalctl -f가 정상적으로 동작하는지 확인.
```
sudo systemctl restart systemd-journald
```
Wazuh Agent 권한 확인
- logcollector가 journald에 접근할 수 있는지 확인
```
sudo usermod -a -G systemd-journal wazuh
sudo systemctl restart wazuh-agent
```
- 적용 후 journalctl -f에서 로그 수집 여부 확인
Wazuh Agent 환경 변수 확인
- WAZUH_HOME 환경 변수가 정상적으로 설정되어 있는지 확인:
```
echo $WAZUH_HOME
```
- WAZUH_HOME이 없다면 /etc/profile에 추가:
```
export WAZUH_HOME=/var/ossec
source /etc/profile
```

5. 결론 및 대응책

단기 해결책

Wazuh Agent가 journald 로그를 가져오지 않는 경우, systemctl restart wazuh-agent로 문제 해결 가능.
journalctl --vacuum-time=1d로 오래된 journald 로그를 정리하여 문제 완화.
usermod -a -G systemd-journal wazuh 명령어로 wazuh 사용자 권한 문제 해결 가능.

장기 해결책

journald와 logcollector 간 버그 가능성이 존재하므로 최신 Wazuh 버전이 나오면 업데이트 필요.
journald 로그를 별도 파일(/var/log/journal.log)에 저장하도록 설정하고, Wazuh에서 이를 직접 읽도록 변경 가능.

추가 조사 필요 사항

GitHub 이슈에서 Wazuh 개발팀이 공식적으로 문제를 인지하고 있으며, 패치가 필요한 문제일 가능성이 있음.
특정 Wazuh Agent에서만 문제가 발생하는 경우, 동일한 환경(디스크, CPU, 메모리, journald 설정)인지 비교 필요.

점검 항목	명령어 또는 조치
journald 상태 확인	`systemctl status systemd-journald`
journald 로그 검증	`journalctl --verify`
journald 디스크 사용량 확인	`journalctl --disk-usage`
오래된 로그 정리	`journalctl --vacuum-time=7d`
Wazuh Agent 디버그 모드 활성화	`agent.debug=2`, `logcollector.debug=2` 설정 후 재시작
Wazuh Agent 재시작	`systemctl restart wazuh-agent`
journald 필터 제거 후 테스트	`_SYSTEMD_UNIT` 필터 제거 후 재시작
Wazuh Agent 권한 추가	`usermod -a -G systemd-journal wazuh`
환경 변수 확인	`echo $WAZUH_HOME`

위 조치를 수행한 후에도 동일한 문제가 발생하면, Wazuh 공식 GitHub 이슈를 계속 모니터링하고 필요 시 최신 패치를 적용하는 것이 가장 안전한 방법입니다. internal_options.conf 파일은 Wazuh의 내부 동작을 제어하는 다양한 설정을 포함하고 있습니다. 이 파일은 /var/ossec/etc/internal_options.conf에 위치하며, 기본적으로 수동으로 설정해야 합니다. 아래는 Wazuh 4.9.0 기준으로 설정 가능한 모든 옵션들의 목록입니다.

Agent 관련 설정

옵션	기본값	설명
`agent.buffer_size`	51200	에이전트가 매니저로 전송할 이벤트의 버퍼 크기 (바이트)
`agent.remote_conf`	1	매니저에서 에이전트 설정을 원격 업데이트 가능 여부 (1=활성화, 0=비활성화)
`agent.tcp_keepalive`	1	에이전트가 TCP keep-alive 메시지를 보내는지 여부
`agent.connection_timeout`	10	에이전트가 매니저 연결 시도 시 타임아웃 시간 (초)
`agent.max_eps`	500	초당 최대 이벤트 전송 제한 (EPS)

Logcollector 관련 설정

옵션	기본값	설명
`logcollector.remote_commands`	0	원격 명령 실행 허용 여부 (1=활성화, 0=비활성화)
`logcollector.remote_commands_timeout`	5	원격 명령 실행 타임아웃 (초)
`logcollector.queue_size`	8192	로그 수집 시 내부 큐 크기 (이벤트 수)
`logcollector.max_fd`	512	logcollector가 감시할 최대 파일 디스크립터 수
`logcollector.force_reload`	1	파일이 변경될 경우 logcollector 자동 재시작 여부

Syscheck (FIM) 관련 설정

옵션	기본값	설명
`syscheck.sleep`	2	파일 검사 간격 (초)
`syscheck.scan_on_start`	yes	Wazuh 시작 시 초기 검사 수행 여부
`syscheck.alert_new_files`	yes	새로운 파일 생성 시 알림 여부
`syscheck.prefilter_cmd_timeout`	1	사전 필터링 명령 실행 제한 시간 (초)
`syscheck.prefilter_max_lines`	1000	사전 필터링 시 최대 분석할 줄 수

Rootcheck (보안 점검) 관련 설정

옵션	기본값	설명
`rootcheck.sleep`	5	점검 간격 (초)
`rootcheck.database_path`	`/var/ossec/queue/rootcheck/db`	Rootcheck 데이터베이스 저장 경로
`rootcheck.timeout`	60	루트킷 검사 제한 시간 (초)

Agent-Manager 통신 관련 설정

옵션	기본값	설명
`remoted.queue_size`	131072	매니저가 수락할 최대 이벤트 수
`remoted.receive_timeout`	10	매니저가 에이전트의 메시지를 기다리는 최대 시간 (초)
`remoted.send_timeout`	10	매니저가 응답을 보내는 최대 시간 (초)
`remoted.verify_msg_id`	1	메시지 ID 검증 활성화 여부

Wazuh 모듈 관련 설정

옵션	기본값	설명
`wazuh_modules.debug`	0	Wazuh 모듈의 디버그 레벨 (0=비활성, 1~2=활성)
`wazuh_modules.debug_file`	`ossec.log`	디버그 로그 저장 파일
`wazuh_modules.remote_commands`	0	원격 명령 실행 허용 여부

Vulnerability Detector 관련 설정

옵션	기본값	설명
`vulnerability.scan_on_start`	1	Wazuh 시작 시 취약점 점검 여부
`vulnerability.feed_timeout`	1800	취약점 DB 피드 업데이트 시간 (초)

General Debugging 관련 설정

옵션	기본값	설명
`agent.debug`	0	에이전트 디버그 활성화 여부 (0~2)
`logcollector.debug`	0	logcollector 디버그 활성화 여부 (0~2)
`syscheck.debug`	0	syscheck 디버그 활성화 여부 (0~2)
`remoted.debug`	0	remoted 디버그 활성화 여부 (0~2)
`rootcheck.debug`	0	rootcheck 디버그 활성화 여부 (0~2)
`vulnerability.debug`	0	취약점 탐지 디버그 활성화 여부 (0~2)

특정 기능 관련 설정

옵션	기본값	설명
`maild.send_email`	1	이메일 알림 발송 여부
`maild.queue_size`	1024	메일 큐 크기
`authd.port`	1515	에이전트 인증 포트
`authd.use_source_ip`	1	에이전트 인증 시 소스 IP 사용 여부

고급 설정 (실험적 기능)

옵션	기본값	설명
`logcollector.udp_port`	514	logcollector의 UDP 포트
`logcollector.tcp_port`	10514	logcollector의 TCP 포트
`logcollector.netflow_enabled`	0	Netflow 분석 활성화 여부

설정 변경 적용 방법

internal_options.conf 파일 수정 후 저장:

sudo nano /var/ossec/etc/internal_options.conf

Wazuh 서비스 재시작:
```
sudo systemctl restart wazuh-agent
```

이 설정들을 활용하여 Wazuh의 동작을 최적화할 수 있습니다. Wazuh Manager에서 shared 디렉터리를 활용하여 룰을 배포할 때, 특정 호스트에만 적용할 수도 있습니다.

Wazuh의 공유 설정(shared) 구조를 보면,

/var/ossec/etc/shared/ → 모든 에이전트에 배포
/var/ossec/etc/shared/<group_name>/ → 특정 그룹에 배포
/var/ossec/etc/shared/<hostname>/ → 특정 호스트에만 배포 가능

즉, 호스트명(hostname)과 동일한 폴더를 생성하여 룰을 넣으면 해당 에이전트에만 적용됩니다.

특정 호스트에만 룰 배포하는 방법

1. 특정 호스트 폴더 생성

mkdir -p /var/ossec/etc/shared/<hostname>

예를 들어, 특정 에이전트 server01에만 룰을 배포하려면

mkdir -p /var/ossec/etc/shared/server01

2. 해당 호스트 폴더에 룰 추가

해당 폴더에 rules.xml을 추가합니다.

cp custom_rules.xml /var/ossec/etc/shared/server01/

3. Wazuh Manager 재시작

설정을 적용하기 위해 Wazuh Manager를 재시작합니다.

systemctl restart wazuh-manager

4. 에이전트에서 룰이 적용되었는지 확인

에이전트에서 적용된 룰을 확인합니다.

cat /var/ossec/logs/ossec.log | grep 'Loading rules'

또는

cat /var/ossec/etc/rules/local_rules.xml

해당 룰이 적용되었는지 확인합니다.

5. 특정 호스트만 룰을 받는지 확인하는 방법

ls /var/ossec/queue/rootcheck/<agent-id>

여기에 해당 룰이 배포되었는지 확인할 수 있습니다.

✅ 호스트명(hostname) 폴더를 만들면 특정 에이전트에만 룰을 배포할 수 있음
✅ 폴더 구조

/var/ossec/etc/shared/ → 모든 에이전트
/var/ossec/etc/shared/<group_name>/ → 특정 그룹
/var/ossec/etc/shared/<hostname>/ → 특정 호스트

✅ Wazuh Manager 재시작 후 적용됨
✅ 에이전트에서 적용 확인 가능

이 방법을 사용하면 특정 서버에만 맞춤형 룰을 배포할 수 있습니다. OSSEC/Wazuh에서 원격 업그레이드(remote upgrade) 기능을 사용하려면, agent-upgrade 설정을 올바르게 구성해야 합니다. 특히 CA 인증서를 사용하여 에이전트와 매니저 간의 보안 통신을 보장해야 합니다.

매니저에서 에이전트 인증서 배포 가능 여부

일반적으로, Wazuh 매니저는 자동으로 인증서를 에이전트에 배포하는 기능을 제공하지 않습니다. 그러나 SSH나 다른 파일 전송 방법을 활용하여 인증서를 배포할 수 있습니다.

1. 매니저에서 직접 배포 (수동 또는 자동화)

매니저에서 각 에이전트의 /var/ossec/etc/ 경로에 인증서를 배포할 수 있습니다. 이를 위해 다음 방법을 고려할 수 있습니다.

1) Ansible을 이용한 배포

Ansible을 사용하면 여러 에이전트에 일괄적으로 파일을 배포할 수 있습니다.

예제: copy 모듈을 이용한 인증서 배포

- name: Deploy Wazuh CA certificate to agents
  hosts: agents
  tasks:
    - name: Copy CA certificate to agent
      copy:
        src: /var/ossec/etc/wpk_root.pem
        dest: /var/ossec/etc/wpk_root.pem
        owner: wazuh
        group: wazuh
        mode: '0644'

실행

ansible-playbook -i inventory deploy_cert.yml

2) SCP 또는 Rsync 사용 (단순 배포)

에이전트가 SSH를 허용하는 경우, 다음과 같이 scp 명령으로 배포할 수 있습니다.

scp /var/ossec/etc/wpk_root.pem root@agent-ip:/var/ossec/etc/wpk_root.pem

또는 여러 에이전트에 rsync를 활용할 수도 있습니다.

rsync -avz /var/ossec/etc/wpk_root.pem agent-user@agent-ip:/var/ossec/etc/

3) Wazuh API를 활용한 배포 (간접적인 방법)

Wazuh API를 활용하면 스크립트 방식으로 원격에서 파일을 배포할 수 있습니다. 하지만 기본적으로 Wazuh API는 파일 배포 기능이 없으므로, 특정 커맨드를 실행하는 방식으로 배포할 수 있습니다.

2. CA 인증서가 배포되었는지 확인

에이전트에서 다음 명령을 실행하여 파일이 올바르게 배포되었는지 확인합니다.

ls -l /var/ossec/etc/wpk_root.pem

정상적으로 출력되면 배포가 완료된 것입니다.

3. 배포 후 에이전트에서 설정 적용

에이전트에서 설정이 정상적으로 반영되었는지 확인하고, 필요하면 Wazuh 에이전트를 재시작합니다.

systemctl restart wazuh-agent

또는

/var/ossec/bin/wazuh-control restart

4. 원격 업그레이드 실행

모든 에이전트가 CA 인증서를 정상적으로 받았다면, 이제 매니저에서 원격 업그레이드를 실행할 수 있습니다.

/var/ossec/bin/agent_upgrade -a <AGENT_ID>

또는 전체 에이전트 업그레이드

/var/ossec/bin/agent_upgrade -a all

Wazuh 매니저는 기본적으로 CA 인증서를 자동 배포하지 않음
Ansible, SCP, Rsync 등을 이용해 인증서를 에이전트에 배포 가능
배포 후 에이전트를 재시작해야 적용됨
원격 업그레이드를 실행하면 정상적으로 작동

자동화가 필요하다면 Ansible 플레이북을 활용하는 것이 가장 효율적인 방법입니다. Wazuh 매니저의 shared 설정을 통해 agent-upgrade 설정을 배포할 수 있는지 확인해 보면, 기본적으로 agent.conf를 이용한 공유 설정 배포는 가능합니다.

1. Shared 설정을 통한 적용 가능 여부

Wazuh의 공유 설정(Shared Configuration) 기능은 agent.conf 파일을 통해 에이전트에 정책을 배포하는 기능입니다.
이 기능은 /var/ossec/etc/shared/ 디렉토리를 이용하여 여러 에이전트에 공통 설정을 적용할 수 있습니다.

agent.conf를 통한 공유 설정 가능 항목 (예시)

<syscheck> (무결성 검사)
<rootcheck> (루트킷 검사)
<localfile> (로그 모니터링)
<command> (원격 명령 실행)
<wodle> (Wazuh 모듈 설정)

위와 같은 공식적으로 지원되는 설정들은 /var/ossec/etc/shared/에 agent.conf 파일을 생성하여 적용할 수 있습니다.

2. agent-upgrade 설정을 shared 방식으로 적용하려면?

shared 디렉토리를 통해 개별 파일 배포
agent.conf를 통해 직접 agent-upgrade 설정을 배포할 수 없다면, 매니저의 shared 디렉토리를 활용하여 ossec.conf의 특정 부분을 덮어씌우는 방법을 사용할 수 있습니다.

매니저의 shared 디렉토리에 ossec.conf에 포함될 설정 파일 생성
```
mkdir -p /var/ossec/etc/shared/default/
```

agent-upgrade.xml 파일을 생성하여 ossec.conf에 포함될 설정을 추가

nano /var/ossec/etc/shared/default/agent-upgrade.xml

내용 추가

<agent-upgrade>
  <ca_verification>
    <enabled>yes</enabled>
    <ca_store>/var/ossec/etc/wpk_root.pem</ca_store>
    <ca_store>/var/ossec/etc/certificate.pem</ca_store>
    <ca_store>wpk_root.pem</ca_store>
  </ca_verification>
</agent-upgrade>

에이전트에서 해당 설정을 ossec.conf에 포함하도록 설정
Wazuh는 shared 디렉토리에 있는 파일을 자동으로 동기화하지만, agent-upgrade.xml을 ossec.conf에 자동으로 합치지는 않습니다.
따라서 에이전트에서 직접 해당 파일을 ossec.conf에 추가하는 스크립트를 사용할 수 있습니다.
에이전트에서 스크립트 실행
에이전트에서 다음 명령어를 실행하여 agent-upgrade.xml을 ossec.conf에 병합
```
cat /var/ossec/etc/shared/default/agent-upgrade.xml >> /var/ossec/etc/ossec.conf
```
에이전트 재시작
```
systemctl restart wazuh-agent
```

이 방법을 사용하면 agent.conf에서 직접 지원하지 않는 설정도 원격으로 관리할 수 있습니다.

728x90

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