Wazuh(OSSEC) 운영에 대한 상세 설명 및 기본적인 운영 예시

1. Endpoint Detection and Response (EDR)

Endpoint Detection and Response(EDR)은 위협이나 보안 침해를 나타낼 수 있는 활동을 모니터링하는 도구와 애플리케이션의 집합입니다. EDR 도구와 애플리케이션의 주요 기능은 다음과 같습니다.

일반 취약점 점검: 기기에 대한 감사 수행
프로액티브 모니터링: 무단 로그인, 브루트 포스 공격, 권한 상승과 같은 의심스러운 활동 모니터링
데이터 시각화: 복잡한 데이터와 이벤트를 깔끔한 그래프로 시각화
정상 운영 행동 기록: 이상 탐지에 도움

2. Wazuh 개요

Wazuh는 2015년에 만들어진 오픈 소스, 무료 EDR 솔루션입니다. 다양한 보안 기능을 제공하며, 특히 다음과 같은 기능을 갖추고 있습니다.

실시간 보안 정보와 이벤트 관리 (SIEM)
규정 준수 감사
침입 탐지
취약점 탐지 및 관리

3. Wazuh 에이전트

에이전트 역할: 시스템의 이벤트와 프로세스를 기록하는 기기를 에이전트라고 합니다. 에이전트는 인증 및 사용자 관리와 같은 기기에서 발생하는 이벤트와 프로세스를 모니터링합니다.
로그 수집: 에이전트는 이러한 로그를 Wazuh와 같은 지정된 수집기로 오프로드하여 처리합니다.

4. Wazuh 에이전트 배포

Wazuh는 에이전트 배포 과정을 안내하며, 이를 위해 다음과 같은 사전 요구사항을 충족해야 합니다.

운영 체제: 에이전트가 설치될 운영 체제의 종류와 버전 (Linux, Windows, 등)
Wazuh 서버 주소: 로그를 전송할 Wazuh 서버의 주소(DNS 엔트리 또는 IP 주소)
에이전트 그룹: 에이전트를 그룹으로 분류하여 관리할 수 있음

예시: Windows에서 Wazuh 에이전트 설치

# PowerShell에서 실행
Invoke-WebRequest -Uri https://packages.wazuh.com/4.x/windows/wazuh-agent-4.x.x.msi -OutFile wazuh-agent.msi
Start-Process -FilePath .\wazuh-agent.msi -ArgumentList /quiet

5. Wazuh 취약점 평가 및 보안 이벤트

Wazuh의 취약점 평가 모듈은 에이전트의 운영 체제에 설치된 애플리케이션과 그 버전을 주기적으로 스캔할 수 있는 강력한 도구입니다. 이를 통해 보안 관리자는 다음과 같은 작업을 수행할 수 있습니다.

취약점 스캔 주기 설정: 기본적으로 5분 간격으로 스캔
취약점 알림 설정: 중요한 취약점이 발견되면 즉시 알림 전송

예시: Vim 버전 취약점 탐지 (CVE-2019-12735)

# 취약점 스캔 결과 예시
{
  "agent": {
    "id": "001",
    "name": "agent-01"
  },
  "vulnerabilities": [
    {
      "cve": "CVE-2019-12735",
      "package": "vim",
      "version": "8.1.0875",
      "severity": "High",
      "status": "Open"
    }
  ]
}

6. Wazuh 정책 감사

Wazuh는 에이전트의 구성을 감사하고 모니터링하며 이벤트 로그를 프로액티브하게 기록할 수 있습니다. 이는 다양한 프레임워크와 법규를 기반으로 한 감사 점수를 제공합니다.

예시: MITRE, NIST, GDPR에 대한 정책 감사 점수

# 정책 감사 결과 예시
{
  "agent": {
    "id": "001",
    "name": "agent-01"
  },
  "frameworks": {
    "MITRE": 85,
    "NIST": 90,
    "GDPR": 88
  }
}

7. Wazuh 로그인 모니터링

Wazuh의 보안 이벤트 모니터는 성공적 및 실패한 인증 시도를 모두 기록할 수 있습니다. 예를 들어, 무단 로그인 시도 또는 성공적인 로그인 이벤트를 감지하여 알림을 생성합니다.

예시: 로그인 이벤트 모니터링

# 로그인 시도 감지
{
  "timestamp": "2024-07-17T12:34:56Z",
  "agent": {
    "id": "001",
    "name": "agent-01"
  },
  "event": {
    "type": "authentication",
    "status": "failed",
    "user": "unknown_user"
  }
}

8. Windows 로그 수집

Windows 운영 체제에서는 다양한 작업과 이벤트가 기록됩니다. Wazuh 에이전트를 사용하여 Sysmon이 기록한 이벤트를 수집하여 Wazuh 관리 서버로 전송할 수 있습니다.

예시: Sysmon 설정 및 로그 수집

# Sysmon 설정 파일 (detect_powershell.xml)
<Sysmon schemaversion="4.10">
  <EventFiltering>
    <ProcessCreate onmatch="include">
      <Image condition="is">C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe</Image>
    </ProcessCreate>
  </EventFiltering>
</Sysmon>

# Sysmon 설치 및 설정 적용
Sysmon64.exe -accepteula -i detect_powershell.xml

# Wazuh 에이전트 구성 파일 (ossec.conf)
<agent>
  <name>agent-01</name>
  <address>192.168.1.100</address>
  <protocol>tcp</protocol>
</agent>

9. Linux 로그 수집

Linux 에이전트에서 로그를 캡처하는 과정은 Windows 에이전트와 유사합니다. Wazuh의 로그 수집 서비스를 사용하여 어떤 로그를 Wazuh 관리 서버로 전송할지 지시하는 항목을 에이전트에 생성합니다.

예시: Apache2 로그 수집

# Wazuh 규칙 파일 (0250-apache_rules.xml)
<group name="apache,">
  <rule id="100100" level="5">
    <decoded_as>json</decoded_as>
    <description>Apache2 Access Log</description>
    <match>access_log</match>
  </rule>
</group>

# 에이전트 구성 파일 (ossec.conf)
<localfile>
  <log_format>apache</log_format>
  <location>/var/log/apache2/access.log</location>
</localfile>

10. Linux에서 명령어 감사

Wazuh는 Debian/Ubuntu 및 CentOS 운영 체제에서 실행되는 에이전트에 auditd 패키지를 설치하여 시스템에서 특정 작업과 이벤트를 모니터링하고 이를 로그 파일에 기록합니다.

예시: Auditd 설정

# Auditd 규칙 추가
echo '-w /etc/passwd -p wa -k passwd_changes' >> /etc/audit/rules.d/audit.rules

# Wazuh 에이전트 구성 파일 (ossec.conf)
<localfile>
  <log_format>audit</log_format>
  <location>/var/log/audit/audit.log</location>
</localfile>

11. Wazuh API

Wazuh 관리 서버는 명령 줄에서 상호 작용할 수 있는 풍부하고 광범위한 API를 제공합니다.

예시: API 인증 및 사용

# Wazuh API 인증
curl -u wazuh:wazuh -k -X GET "https://wazuh-manager:55000/security/user/authenticate" -H "Content-Type: application/json"

# Wazuh API 사용 예시 (에이전트 목록 가져오기)
curl -u wazuh:wazuh -k -X GET "https://wazuh-manager:55000/agents" -H "Content-Type: application/json"

12. Wazuh 보고서 생성

Wazuh는 에이전트에서 발생한 이벤트에 대한 요약된 분석을 제공하는 보고서 모듈을 갖추고 있습니다.

예시: 보안 이벤트 보고서 생성

# 보안 이벤트 보고서 생성
curl -u wazuh:wazuh -k -X GET "https://wazuh-manager:55000/reports/security/events?from=2024-07-16T00:00:00Z&to=2024-07-17T00:00:00Z" -H "Content-Type: application/json"

# 보고서 예시
{
  "total_alerts": 79,
  "alerts": [
    {
      "agent": {
        "id": "001",
        "name": "agent-01"
      },
      "timestamp": "2024-07-17T12:34:56Z",
      "event": {
        "type": "authentication",
        "status": "failed",
        "user": "unknown_user"
      }
    }
  ]
}

Wazuh 운영과 관련된 주요 기능과 절차의 포괄적인 내용으로, 보안 관리자의 역할을 지원하는 데 유용합니다. Wazuh를 효과적으로 사용하기 위해 각 모듈과 기능을 심도 있게 이해하고 적용하는 것이 중요합니다.

SIEM을 구축할 때 가장 먼저 결정해야 할 것은 분산 아키텍처입니다. 이를 위해 사용 가능한 자원과 보안 운영 센터(SOC)의 필요성을 분석해야 합니다.

고려해야 할 질문들

몇 개의 호스트를 모니터링할 것인가? (100, 1000, 또는 10000 호스트)
상용 도구를 위한 예산이 있는가?
인프라가 얼마나 이질적인가?
보안 경고만 필요한가, 아니면 감사 목적을 위한 지속적인 이벤트 로그가 필요한가?
어떤 수준의 세밀함을 추구하는가?
어떤 응답 시간을 원하는가? 실시간 알림이 필요한가?
솔루션을 개선/조정할 시간이 있는가, 아니면 즉시 100% 작동하는 솔루션이 필요한가?

오픈 소스와 상용 도구의 선택

오픈 소스를 선택하면 라이선스 비용은 절감할 수 있지만, 이를 조정하고 관리할 인력을 고용해야 합니다. 상용 도구와 지원을 선택하면 더 간편하지만 비용이 증가합니다.

첫 번째 아키텍처: ELK + Elastalert

초기 아키텍처는 각 호스트에 로그/이벤트 전달기(예: Filebeat)를 실행하여 데이터를 Logstash 수집기로 보내고, Logstash가 이를 파싱하고 풍부하게 한 후, Elasticsearch에 저장합니다. Kibana를 통해 이를 시각화할 수 있습니다.

하지만 이 아키텍처에는 수작업이 많이 필요하고, 발견된 중요한 이벤트를 자동으로 기록하지 않는 문제가 있습니다. 이를 해결하기 위해 Elastalert를 추가하여 특정 이벤트 쿼리에 대해 알림을 받도록 했습니다.

알림 시스템

Elastalert는 특정 쿼리에 대한 알림을 제공합니다. 우리는 긴급 알림을 위한 Slack 채널과 기록을 위한 이메일 인박스를 사용했습니다. 더 나아가 Sigma 규칙 프로젝트를 사용하여 다양한 포맷으로 변환 가능한 표준 규칙을 정의했습니다.

두 번째 아키텍처: Wazuh 통합

Wazuh는 오픈 소스 호스트 침입 탐지 시스템(HIDS)으로, 처리 부하를 줄여줍니다. 각 호스트에 Wazuh 에이전트를 설치하고, 여러 Wazuh 관리자가 이벤트를 수신합니다. 이는 Logstash를 대체하여 처리 부하를 줄이고, 경고만 SIEM으로 전달합니다.

Wazuh의 규칙 처리기는 특정 이벤트에 대한 규칙을 정의하여 빠르게 매칭합니다. 이를 통해 간단한 규칙은 Wazuh에서, 세부적인 규칙은 Elastalert에서 처리하도록 하여 성능과 세밀함의 균형을 맞췄습니다.

최종 아키텍처는 다음과 같습니다.

Wazuh를 사용하여 빠른 규칙 매칭 및 기본적인 경고 처리
Elastalert와 Sigma 규칙을 사용하여 특정한 악성 이벤트 감지
Slack과 이메일 인박스를 통한 알림 및 기록
Jira 통합을 통한 이슈 추적

이 아키텍처는 다양한 환경과 운영 체제에서 수천 대의 호스트를 모니터링하고, 실시간 알림을 받을 수 있으며, 오픈 소스 규칙을 구현하고 맞춤형 규칙을 작성할 수 있도록 합니다.

추가 고려 사항

실패를 대비한 설계: 여러 Wazuh 관리자와 다양한 환경 설정
트래픽 분산: Nginx 또는 DNS 로드 밸런서를 사용하여 연결 분산
네트워크 오버헤드 분석: 적절한 지역에서 관리자 사용
Wazuh 에이전트 서비스의 시작 및 중지 모니터링
주기적인 레드팀 연습: Mitre의 Att&ck 프레임워크와 Red Canary의 Atomic Tests 사용
Sigma와 Wazuh 규칙의 업데이트
커뮤니티 규칙 외에 자체 규칙 작성 및 확장

이 모든 과정을 통해, 비용 효율적인 SIEM을 구축하고 운영할 수 있으며, 보안 및 감사 목적을 위한 자동화된 탐지, 추적 및 문서화 기능을 갖출 수 있습니다.

원문 : https://medium.com/@4ghora

과거 Wazuh Manager에서는 에이전트가 Enrollment(authd) 방식으로 스스로 자동 등록할 수 있었습니다. 그러나 이 과정에서 다음과 같은 문제가 발생할 수 있었습니다.

이미 유효한 키를 보유한 에이전트가 다시 Enrollment를 시도하여 중복 등록이 발생할 수 있었습니다.
이로 인해 Manager에서 불필요한 키가 생성되거나 관리가 복잡해질 수 있었습니다.

Wazuh 버전 4.0.0부터 도입된 Enrollment 기능은 에이전트 등록을 보다 쉽게 자동화해주지만, 위와 같은 중복 등록 현상이 잠재적인 문제로 지적되었습니다. 이러한 배경에서 아래와 같은 개선 사항이 추가되었습니다.

Authd 인증 방식의 주요 변경 사항

Wazuh Manager의 Authd 인증 방식은 다음과 같이 동작이 개선되었습니다.

이전 동작

에이전트가 Enrollment 시도를 하면 항상 Manager는 새로운 키를 생성하여 발급했습니다.
이미 등록된 에이전트가 재등록을 시도해도 새로운 키가 발급되었고, 중복 키가 생성될 수 있었습니다.

개선된 동작

에이전트가 이미 유효한 키를 가지고 있는 경우, Enrollment 시도 시 Manager(Authd)는 새로운 키 발급을 거부합니다.
Manager 측에서 이미 해당 에이전트의 키가 존재하면 중복 키 생성을 하지 않습니다.
Manager에서 새로운 키 생성 여부를 명확하게 통제할 수 있습니다.

실무적인 장점

중복 키 방지: 이미 등록된 에이전트가 실수나 자동화 프로세스 상의 오류로 재등록 시도를 해도, 중복 키가 생성되지 않게 됩니다.
보안 향상: 무분별한 키 재발급이 방지되어 관리가 명확해지고, 등록된 에이전트 관리 체계가 일관적으로 유지됩니다.
관리 용이성: 키의 중복이나 혼란을 방지하여 키 관리가 용이해지고, Wazuh 클러스터 환경에서도 보다 효율적인 관리가 가능합니다.

Wazuh Manager를 운영하는 보안 관리자는 다음과 같은 관점에서 관리 및 점검을 수행해야 합니다.

점검 포인트

Manager 내 등록된 에이전트 리스트 주기적 점검
```
/var/ossec/bin/agent_control -l
```
특정 에이전트의 키 유효성 확인
```
/var/ossec/bin/manage_agents -l
```
Authd의 로그 점검 (에이전트 Enrollment 실패 시도 기록 확인)
```
tail -f /var/ossec/logs/ossec.log | grep "authd"
```

보안 가이드라인

Manager의 Authd 설정에서 Enrollment 기능의 보안성을 높이기 위해 IP 제한(use_source_ip), 에이전트 Enrollment 제한 옵션(force_insert) 등을 적절히 설정합니다.
불필요한 키 생성을 막기 위해 반드시 Manager의 Authd 설정 파일을 점검하고 다음 옵션이 권장 사항으로 설정되어 있는지 확인합니다.

설정 파일 예시 (/var/ossec/etc/ossec.conf 내 설정)

<ossec_config>
  <auth>
    <disabled>no</disabled>
    <port>1515</port>
    <use_source_ip>yes</use_source_ip> <!-- IP 기반 제한 -->
    <force_insert>no</force_insert> <!-- 중복 등록 방지 -->
    <purge>yes</purge> <!-- 자동 삭제 옵션 -->
  </auth>
</ossec_config>

에이전트에서 Enrollment가 실패하면 Manager의 기존 키가 유효한지부터 확인하여 추가적인 불필요한 작업을 방지합니다.

위와 같이 변경된 인증(Authd) 방식으로 인해 Wazuh 환경의 관리성과 보안성이 향상됩니다.

변경된 사항의 핵심 요약

Wazuh는 에이전트 자동 등록(Enrollment) 프로세스를 통해 에이전트 등록을 간소화했으나, 기존에는 에이전트가 이미 유효한 키를 보유하고 있어도 다시 등록 요청을 하면 중복된 키를 재발급하는 문제가 있었습니다. 이를 해결하기 위해 Wazuh 버전 4.2.0부터 Authd의 동작 방식을 아래와 같이 개선했습니다.

에이전트가 이미 유효한 키를 가지고 있는 경우 등록 요청 시 해당 키의 해시(Hash)를 전송하고, Manager는 이 해시값을 통해 이미 등록된 에이전트인지 확인합니다.
이미 Manager에 존재하는 키와 일치하는 해시가 있다면, Manager는 추가 키 발급을 거부하여 중복 등록을 방지합니다.
기존의 #ping 로직(키 여부 확인용)은 더 이상 불필요하여 폐기되었습니다.

에이전트 측면에서의 변경사항

이제 에이전트가 Enrollment를 시도할 때 다음 두 가지 경우로 나뉩니다.

키가 없는 경우
- 에이전트가 키를 가지고 있지 않다면 기존처럼 단순히 Enrollment를 시도하여 새 키를 요청합니다.
기존에 키가 있는 경우 (새로 추가된 기능)
- 에이전트가 이미 키를 보유하고 있다면, Enrollment 요청 시 명령어에 추가로 키의 해시값을 포함합니다.
- 전송 형식 예시: K:<key_hash_value>
- 해시값 계산은 Wazuh 내부에서 공유된 메소드로 수행됩니다.

매니저(Manager) 측면에서의 변경사항

Manager(Authd)는 에이전트로부터 전달된 키의 해시값을 통해 다음 동작을 수행합니다.

키 해시 파싱 (w_auth_parse_data)
에이전트의 등록 요청에서 K: 옵션을 파싱하여 키 해시를 추출합니다.
키 유효성 검사 (w_auth_validate_data)
추출된 키 해시를 Manager 내부에서 기존 키와 비교하여 중복 여부를 확인합니다.
중복 키 발견 시 동작
- 이미 등록된 키와 해시가 일치하면, Manager는 등록을 거부하며, 에이전트가 이미 유효한 키를 보유하고 있음을 로그로 알립니다.
- 만약 키가 존재하지 않거나 해시가 다르다면, 새로운 키를 정상적으로 발급합니다.

클러스터 환경에서의 변경 사항

Wazuh Manager가 클러스터로 동작할 경우에도 위와 동일한 논리가 적용되며, Worker 노드에서 Master 노드로 전달할 때도 해시값을 JSON 형태로 포함하여 전달합니다.

클러스터 환경 등록 요청 예시(JSON 형태)
{ "name": "agent_name", "ip": "agent_ip", "key_hash": "<key_hash_value>" }

Master Authd에서 수신된 JSON 데이터의 key_hash 값을 기존 키들과 비교하여 중복 여부를 판단합니다.

기술적 실제 활용 예시

Agent에서의 동작 변경 (Enrollment 프로세스)

키가 없는 최초 등록 시: /var/ossec/bin/agent-auth -m manager_ip

이미 등록된 키가 존재할 경우 (해시 자동 포함)

# 에이전트가 자동으로 수행
/var/ossec/bin/agent-auth -m manager_ip -K:<자동으로 생성된 키해시>

Manager(Authd) 로그 확인

에이전트가 중복된 키로 재등록을 시도했을 때 로그 메시지 예시

tail -f /var/ossec/logs/ossec.log | grep authd

출력 예

INFO: Agent 'agent_name' with IP '1.2.3.4' already has a valid key. Enrollment rejected.

주요 파일 및 설정 위치

Manager (Authd)

Authd 설정 파일 위치: /var/ossec/etc/ossec.conf

주요 옵션 예시

<auth>
<disabled>no</disabled>
<port>1515</port>
<use_source_ip>yes</use_source_ip> <!-- IP 기반 제한 -->
<force_insert>no</force_insert>    <!-- 중복 등록 방지 -->
</auth>

에이전트 (Agent) 키 저장 위치

키 파일
```
/var/ossec/etc/client.keys
```

변경된 기능의 이점 및 활용 사례

장점

중복 키 발급 방지로 에이전트 키 관리의 복잡성 감소
자동화 환경에서의 불필요한 에이전트 중복 등록 방지
에이전트 관리의 보안성과 투명성 향상

활용 사례

수백~수천대 이상의 에이전트를 운용 중인 환경에서 네트워크 문제로 인한 에이전트 재등록 이슈 방지
클라우드 자동화 환경(Auto Scaling 등)에서 중복된 에이전트 등록 요청이 많을 때 효과적으로 관리 가능

추가로 폐기된 사항 (Deprecation)

기존에 존재했던 #ping 로직은 Authd에서 키 존재 유무를 직접 판단하기 때문에 더 이상 필요 없어졌습니다.
Enrollment 과정에서의 #ping 로직은 앞으로 사용되지 않습니다.

위 내용을 기반으로 변경된 사항을 Authd 관리 프로세스를 최적화하여 보다 효율적인 Wazuh 환경 관리를 진행하고, Wazuh Manager의 인증(Authd) 설정 항목에 대한 활용 방법입니다.

인증(auth) 섹션 개요

<auth> 섹션은 Wazuh Manager에서 에이전트 등록(Enrollment) 및 인증(Authd) 서비스를 구성하는 데 사용되는 옵션을 정의합니다. 위치는 다음과 같습니다.

/var/ossec/etc/ossec.conf

기본적인 설정 예시는 다음과 같습니다.

<auth>
  <disabled>no</disabled>
  <remote_enrollment>yes</remote_enrollment>
  <port>1515</port>
  <use_source_ip>no</use_source_ip>
  <force>
    <enabled>yes</enabled>
    <disconnected_time enabled="yes">1h</disconnected_time>
    <after_registration_time>1h</after_registration_time>
    <key_mismatch>yes</key_mismatch>
  </force>
  <purge>yes</purge>
  <use_password>no</use_password>
  <ciphers>HIGH:!ADH:!EXP:!MD5:!RC4:!3DES:!CAMELLIA:@STRENGTH</ciphers>
  <ssl_verify_host>no</ssl_verify_host>
  <ssl_manager_cert>etc/sslmanager.cert</ssl_manager_cert>
  <ssl_manager_key>etc/sslmanager.key</ssl_manager_key>
  <ssl_auto_negotiate>no</ssl_auto_negotiate>
</auth>

주요 옵션

disabled
- Authd 데몬(authd) 활성화 여부
- 기본값: no (활성화)
- 허용값: yes, no
remote_enrollment
- 에이전트 등록 요청을 수신할 TLS 포트 활성화 여부
- 기본값: yes
- 허용값: yes, no
port
- Authd 데몬에서 에이전트 등록 요청을 받기 위한 TCP 포트
- 기본값: 1515
ipv6 (4.4.0 이상)
- IPv6 지원 활성화 여부
- 기본값: no
use_source_ip
- 등록되는 에이전트 IP를 자동으로 설정할지 여부
- 기본값: no

강제 등록 옵션 (force)

중복된 이름/IP 에이전트 발생 시 기존 에이전트를 강제로 교체할지 여부를 결정합니다.

<force>
  <enabled>yes</enabled>
  <disconnected_time enabled="yes">1h</disconnected_time>
  <after_registration_time>1h</after_registration_time>
  <key_mismatch>yes</key_mismatch>
</force>

enabled
- 강제 등록 여부 설정
- 기본값: yes
disconnected_time
- 일정 시간 동안 연결이 끊어진(disconnected) 에이전트만 교체하도록 설정
- 기본값: 1h (1시간 이상 연결이 끊어진 경우 교체 허용)
- 속성: enabled="yes" (비활성화 시 연결 상태에 관계없이 교체)
after_registration_time
- 에이전트가 등록된 지 일정 시간 이상 지난 경우에만 교체를 허용
- 기본값: 1h
key_mismatch
- 에이전트가 가지고 있는 키가 Manager의 키와 다를 경우 교체
- 기본값: yes

기타 인증 옵션

purge
- 에이전트 삭제 시 클라이언트 키 파일(client.keys)에서 키를 완전 삭제할지 여부
- 기본값: yes
use_password
- 에이전트 등록 시 비밀번호(shared password) 인증 사용 여부
- 기본값: no
- 활성화 시, /var/ossec/etc/authd.pass 파일에서 공유 패스워드를 읽음

SSL/TLS 관련 옵션

SSL/TLS를 사용하여 보안을 강화할 때 사용하는 옵션들입니다.

ssl_agent_ca
- 클라이언트 검증을 위한 CA 인증서 경로
ssl_verify_host
- 클라이언트 IP를 SSL 인증서의 Common Name과 비교 검증 여부
- 기본값: no
ssl_manager_cert
- SSL 인증서(server certificate) 경로
- 기본값: etc/sslmanager.cert
ssl_manager_key
- SSL 키(server key) 경로
- 기본값: etc/sslmanager.key
ssl_auto_negotiate
- SSL/TLS 메소드 자동 협상 활성화 여부
- 기본값: no (기본 TLS 1.2만 허용)
ciphers
- SSL/TLS 통신 시 사용할 암호화 알고리즘(Cipher Suite)
- 기본값: HIGH:!ADH:!EXP:!MD5:!RC4:!3DES:!CAMELLIA:@STRENGTH

외부 키 요청(key_request) 옵션 (4.4.0 이상)

Manager 외부에서 키 생성 로직을 실행할 수 있는 기능입니다.

<key_request>
  <enabled>yes</enabled>
  <exec_path>/usr/bin/python /home/script.py</exec_path>
  <socket>/path/to/socket</socket>
  <timeout>60</timeout>
  <threads>1</threads>
  <queue_size>1024</queue_size>
</key_request>

enabled: 기능 활성화 여부 (yes/no)
exec_path: 키 요청 처리할 외부 스크립트 경로
socket: Unix 소켓을 이용할 경우 소켓 경로
timeout: 응답 최대 대기 시간(초)
threads: 요청 처리에 사용할 쓰레드 수
queue_size: 외부 키 요청 처리 큐의 최대 크기

안전한 운영을 위한 설정 예시

<auth>
  <disabled>no</disabled>
  <remote_enrollment>yes</remote_enrollment>
  <port>1515</port>
  <use_source_ip>yes</use_source_ip> <!-- 소스 IP 명시적 사용 -->
  <force>
    <enabled>yes</enabled>
    <disconnected_time enabled="yes">24h</disconnected_time>
    <after_registration_time>1h</after_registration_time>
    <key_mismatch>yes</key_mismatch>
  </force>
  <purge>yes</purge>
  <use_password>yes</use_password> <!-- 비밀번호 인증 추가 권장 -->
  <ssl_verify_host>yes</ssl_verify_host>
  <ssl_auto_negotiate>yes</ssl_auto_negotiate> <!-- 자동 협상 활성화 -->
  <ciphers>HIGH:!ADH:!EXP:!MD5:!RC4:!3DES:!CAMELLIA:@STRENGTH</ciphers>
</auth>

설정 변경 시 Manager를 반드시 재시작하여 적용 확인 필요.
주기적인 에이전트 키 관리 및 로그 모니터링 수행 권장.
SSL 옵션 활성화 시 반드시 SSL 인증서 및 키 유효성 점검 필요.

위 정보를 참고하여 Wazuh의 Authd 구성 및 보안 관리를 체계적으로 운영할 수 있습니다.

728x90

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

Wazuh(OSSEC) 운영에 대한 상세 설명 및 기본적인 운영 예시

Wazuh(OSSEC) 운영에 대한 상세 설명 및 기본적인 운영 예시

1. Endpoint Detection and Response (EDR)

2. Wazuh 개요

3. Wazuh 에이전트

4. Wazuh 에이전트 배포

5. Wazuh 취약점 평가 및 보안 이벤트

6. Wazuh 정책 감사

7. Wazuh 로그인 모니터링

8. Windows 로그 수집

9. Linux 로그 수집

10. Linux에서 명령어 감사

11. Wazuh API

12. Wazuh 보고서 생성

고려해야 할 질문들

오픈 소스와 상용 도구의 선택

첫 번째 아키텍처: ELK + Elastalert

알림 시스템

두 번째 아키텍처: Wazuh 통합

추가 고려 사항

Authd 인증 방식의 주요 변경 사항

실무적인 장점

점검 포인트

보안 가이드라인

변경된 사항의 핵심 요약

에이전트 측면에서의 변경사항

매니저(Manager) 측면에서의 변경사항

클러스터 환경에서의 변경 사항

기술적 실제 활용 예시

Agent에서의 동작 변경 (Enrollment 프로세스)

Manager(Authd) 로그 확인

주요 파일 및 설정 위치

Manager (Authd)

에이전트 (Agent) 키 저장 위치

변경된 기능의 이점 및 활용 사례

장점

활용 사례

추가로 폐기된 사항 (Deprecation)

인증(auth) 섹션 개요

주요 옵션

강제 등록 옵션 (force)

기타 인증 옵션

SSL/TLS 관련 옵션

외부 키 요청(key_request) 옵션 (4.4.0 이상)

안전한 운영을 위한 설정 예시

관련글

댓글

티스토리툴바