기존 모니터링 도입에서 가장 번거로운 일 #

모니터링 툴을 도입할 때, 가장 많은 공수가 소요되는 것은 초기 설정이 아니라「기기별 등록 작업」입니다.

Zabbix나 기타 SIEM에서도 새로운 기기를 모니터링 대상에 추가할 때마다 “호스트 등록→템플릿 선택→파서 설정→테스트→운영 적용”의 절차가 필요합니다. 10대면 2~3인일, 100대면 20~30인일이 소요됩니다. 게다가 기기가 증감할 때마다 이 작업이 발생합니다.

BASTION에서는 이 공정 자체를 없앴습니다.

시스템의 전체 구조 #

다음 5단계가 전부 자동으로 실행됩니다.

즉, 기기가 syslog를 전송하기 시작한 후 최단 15분 후에는 모니터링 리포트가 Slack에 전달됩니다.

단계 1: rsyslog에 의한 디렉토리 자동 생성 #

BASTION의 rsyslog는 수신한 syslog의 발신 호스트명별로 디렉토리를 자동 생성합니다.

/var/log/remote/
  호스트명A/2026/04/Security-Auditing.log
  호스트명B/2026/04/sshd.log
  호스트명C/2026/04/filterlog.log
  ...

새로운 기기가 syslog를 전송하기 시작하면 설정 변경 없이 디렉토리가 생성됩니다. 이것이 모든 자동화의 시작점입니다.

단계 2: 신규 호스트 자동 검출 #

검출 스크립트가 1일 1회, 디렉토리 목록을 이전 리스트와 비교합니다.

여기서 중요한 것은「무엇을 모니터링할 것인가」가 아니라 「무엇을 제외할 것인가」를 관리한다는 역발상입니다. 기존 서버나 네트워크 기기（이미 summarize.sh에서 개별적으로 파싱 처리를 작성한 것）는 제외 리스트에 넣어두고, 그 외는 전부 “신규 클라이언트”로 처리합니다.

# 제외 리스트（서버/NW 기기의 호스트명 패턴）
EXCLUDE_HOSTS="기존서버1|기존서버2|기존FW|..."

# /var/log/remote/ 의 호스트 목록에서 제외 리스트를 제외
# → 남은 것이 신규 클라이언트

검출 결과에 따라 Slack에 알림을 보냅니다.

단계 3: LLM에 의한 자동 분류 #

여기가 핵심입니다. 신규 호스트가 검출되면 해당 호스트의 로그 파일에서 샘플（상위 5개 파일×마지막 20행）을 추출하여 LLM에 분류를 요청합니다.

무엇을 판정하는가 #

다음 9개 카테고리로 분류합니다.

LLM에 분류 요청 #

GPUStack（로컬 LLM 서버）의 OpenAI 호환 API에 직접 요청을 전송합니다. 프롬프트에는 호스트명, 로그 파일 목록, 로그 샘플을 첨부하고, JSON 형식으로 분류 결과를 반환하도록 지시합니다.

# 분류 요청(개요)
curl -s -X POST "${GPUSTACK_URL}/v1/chat/completions" \
  -H "Authorization: Bearer ${API_KEY}" \
  -d '{
    "model": "qwen2.5-14b-instruct",
    "messages": [{
      "role": "system",
      "content": "You are a device classifier. Classify this host..."
    }, {
      "role": "user",  
      "content": "Hostname: XXX\nLog files: ...\nSample: ..."
    }],
    "temperature": 0.1
  }'

# → 응답 예시
{
  "category": "win_client",
  "confidence": "high",
  "os_detail": "Windows 10/11 desktop",
  "reasoning": "Security-Auditing logs with LogonType 2..."
}

LLM의 응답에서 JSON 부분을 추출하여 디바이스 레지스트리에 등록합니다.

단계 4: 템플릿 기반 모니터링 #

디바이스 레지스트리 #

분류 결과는 JSON 파일(디바이스 레지스트리)에 축적됩니다.

{
  "devices": [
    {
      "hostname": "CLIENT-001",
      "category": "win_client",
      "template": "win_client.sh",
      "confidence": "high",
      "os_detail": "Windows 10/11 desktop",
      "active": true
    },
    ...
  ],
  "exclude_hosts": ["기존 서버1", "기존 FW", ...],
  "last_scan": "2026-04-21T06:00:00+09:00"
}

모니터링 템플릿 #

각 카테고리에 대응하는 템플릿 스크립트를 준비하고 있습니다. 템플릿은 두 개의 함수를 제공합니다.

# templates/win_client.sh

# 요약 출력(summarize.sh에서 호출됨)
template_summarize_win_client() {
    # 인증 이상, PowerShell, USB, 계정 변경 카운트
}

# 상세 분석(analyze-detail.sh에서 호출됨)
template_detail_win_client() {
    # 로그인 실패의 단말별 내역, 특권 로그온 상세, LOLBin 탐지...
}

기존의 summarize.sh(정기 분석 스크립트) 끝부분에 디바이스 레지스트리를 읽어 템플릿을 동적으로 호출하는 블록을 추가하고 있습니다.

# summarize.sh 끝부분에 추가
jq -r '.devices[] | select(.active==true) | ...' device-registry.json \
| while read HOST CATEGORY TEMPLATE; do
    source "templates/${TEMPLATE}"
    template_summarize_${CATEGORY} "$HOST" ...
done

기존의 하드코딩 부분에는 전혀 손대지 않고 추가만으로 확장하고 있습니다.

단계 5: 완전 자동화의 결과 #

초기 스캔에서 14대의 Windows 클라이언트를 자동 검출했습니다. LLM이 각 단말의 로그 샘플을 읽고 “Security-Auditing 로그에 로그온 이벤트가 있음 → Windows 클라이언트”로 판정했습니다. win_client 템플릿이 자동 적용되어 인증 이상, PowerShell 실행, USB 연결, 계정 변경의 4개 카테고리 모니터링이 즉시 시작되었습니다.

LLM 분류의 정확도 #

14대 중 13대가 confidence: high로 정확하게 분류되었습니다. 1대만 confidence: high로 “win_server”로 판정되었지만 실제로는 Windows 클라이언트였습니다. 호스트명에 서버를 연상시키는 문자열이 포함된 것이 원인으로 추정됩니다.

win_client와 win_server의 모니터링 템플릿은 공통으로 되어 있어 실제 피해는 없습니다. 다만 카테고리의 정확성이 중요한 경우 디바이스 레지스트리의 category 필드를 수동으로 수정하는 재정의 기능을 검토 중입니다.

기존 모니터링과의 공존 #

BASTION에서는 이미 방화벽, 인증 기반, 로드밸런서, 스위치, 웹 서버의 분석 처리를 summarize.sh에 하드코딩하고 있습니다. 자동 분류 대상은 이러한 기존 장비를 제외한 나머지입니다.

이미 작동하는 것을 망가뜨릴 위험은 감수하지 않습니다. 향후 기존의 하드코딩 부분도 템플릿화하여 통합할 수 있지만, 현 시점에서는 “기존 장비=하드코딩”, “신규 장비=템플릿 자동 적용”의 이중 구조입니다.

향후 확장 #

현재는 win_client 템플릿과 범용(unknown) 템플릿 2종류이지만, 고객 도입 시마다 템플릿이 늘어나게 됩니다.

템플릿 라이브러리가 늘어날수록 “syslog를 향하게만 하면” 대응 가능한 장비의 범위가 넓어지며, 이것이 그대로 축적형 경쟁 우위가 됩니다.

정리 #

BASTION의 자동 기기 분류는 rsyslog의 디렉토리 자동 생성 → 호스트 검출 → LLM 로그 분류 → 템플릿 자동 적용 → 모니터링 시작을 전자동으로 수행합니다. syslog의 대상을 설정하는 것만으로 기기의 종별 판정도 모니터링 규칙의 선택도 단말의 증감 관리도 자동화됩니다.

기존 모니터링 도입에서의 최대 병목인 “기기별 등록·설정”을 구조적으로 없애는 구조입니다. 10대든 100대든 사람의 작업은 동일합니다(syslog 대상의 1줄 설정만). “모르는 사이에 모니터링 대상 외의 기기가 늘어나 있었다”는 문제가 구조적으로 발생하지 않습니다.