안랩 XTG

개요

대상 사용자: AhnLab XTG 방화벽을 운영하면서 트래픽 차단 내역·보안 탐지·관리자 활동을 소나에서 확인해야 하는 보안 담당자와 인프라 운영자입니다.

이 앱은 XTG가 시스로그로 보내는 로그를 로그 유형별로 나누어 적재합니다. 적재된 로그로 다음과 같은 업무를 수행할 수 있습니다.

• 방화벽이 차단한 트래픽의 출발지·목적지·사유를 조회하고 상위 항목을 집계합니다.
• IPS, 안티바이러스, 웹 필터 등 보안 기능이 탐지한 이벤트를 유형별로 확인합니다.
• 관리자 로그인과 사용자 계정 상태 변화를 추적해 감사 근거로 활용합니다.

기본 개념·용어

주요 화면·메뉴 경로

수집한 로그는 설치 시 지정한 FW_XTG로 시작하는 테이블에 적재됩니다. 이 매뉴얼의 쿼리 예제는 테이블 이름을 FW_XTG로 표기하므로, 다른 이름을 쓴 경우 해당 이름으로 바꿔 실행하세요.

작업 시나리오

시나리오 1: 차단 트래픽 상위 출발지 조회

목적: 방화벽이 최근 차단한 트래픽을 출발지 기준으로 집계해, 반복적으로 차단되는 호스트나 스캔 시도를 찾아냅니다.

사전 조건:

• 설치 매뉴얼의 시스로그 수집 설정이 완료되어 FW_XTG 테이블에 로그가 적재되고 있어야 합니다.
• XTG에서 트래픽 차단 로그(2102) 전송이 활성화되어 있어야 합니다.

수행 절차:

1. 분석 > 쿼리로 이동합니다.
2. 아래 쿼리를 입력하고 실행합니다.

table FW_XTG
| search _time >= now() - 1h and _schema == "xtg-traffic-deny"
| stats count as blocked by src_ip, dst_ip, dst_port, action
| sort limit=20 -blocked

3. 특정 출발지를 자세히 보려면 src_ip 조건을 추가해 다시 조회합니다.

table FW_XTG
| search _time >= now() - 1h and _schema == "xtg-traffic-deny" and src_ip == "192.0.2.1"
| fields _time, src_ip, dst_ip, dst_port, protocol, action, description
| sort limit=50 -_time

결과 확인:

결과가 있으면 다음과 같은 형태로 나옵니다.

• 조회 기간에 차단이 없었다면 결과는 0건입니다. 0건 자체는 정상입니다.
• blocked는 집계된 차단 건수입니다. 한 출발지가 여러 목적지 포트로 반복 차단되면 포트 스캔을 의심할 수 있습니다.
• 3단계의 상세 조회 결과에서 description 값을 보면 차단 근거를 알 수 있습니다.

실패 대응:

시나리오 2: 사용자 계정 상태 변화 추적

목적: 계정 잠금이나 강제 로그아웃이 발생한 사용자를 찾아 계정 탈취 시도나 정책 오적용 여부를 확인합니다.

사전 조건:

• XTG 로그 정의서 v1.1.1을 사용하는 기종이어야 합니다. 사용자 이벤트(2405)는 v1.1.1에서 추가된 로그 유형입니다.
• XTG에서 사용자 이벤트 로그 전송이 활성화되어 있어야 합니다.

수행 절차:

1. 분석 > 쿼리로 이동합니다.
2. 최근 하루 동안의 사용자 이벤트를 유형별로 집계합니다.

table FW_XTG
| search _time >= now() - 1d and _schema == "xtg-user-event"
| stats count as cnt by type, level
| sort -cnt

3. 계정 잠금과 강제 로그아웃만 추려 대상 사용자를 확인합니다.

table FW_XTG
| search _time >= now() - 1d and _schema == "xtg-user-event" and in(type, "USER_LOCKED", "FORCED_LOGOUT")
| fields _time, type, level, user, user_name, user_ip, client_device_name, description
| sort limit=50 -_time

결과 확인:

결과가 있으면 다음과 같은 형태로 나옵니다.

• 조회 기간에 계정 잠금·강제 로그아웃이 없었다면 결과는 0건입니다. 0건 자체는 정상이며, 수집 여부는 2단계 집계 쿼리에 다른 유형이 나오는지로 판단합니다.
• 같은 계정에 USER_LOCKED가 짧은 간격으로 반복되면 비밀번호 대입 시도를 의심할 수 있습니다.
• user_ip와 client_device_name으로 평소 사용하지 않던 단말에서의 접근인지 판단합니다.

실패 대응:

시나리오 3: 목적지 도메인 기준 트래픽 조회

목적: 특정 도메인으로 향한 트래픽을 찾아 허용·차단 여부와 사용량을 확인합니다.

사전 조건:

• 트래픽 허용(2101) 또는 트래픽 차단(2102) 로그가 적재되어 있어야 합니다.
• 도메인 값은 XTG가 목적지 도메인을 식별한 경우에만 채워집니다.

수행 절차:

1. 분석 > 쿼리로 이동합니다.
2. 목적지 도메인별 트래픽을 집계합니다.

table FW_XTG
| search _time >= now() - 1h and in(_schema, "xtg-traffic-allow", "xtg-traffic-deny") and isnotnull(domain)
| stats count as sessions, sum(total_bytes) as bytes by domain, _schema
| sort limit=20 -bytes

3. 특정 도메인의 세션을 상세 조회합니다.

table FW_XTG
| search _time >= now() - 1h and domain == "example.com"
| fields _time, src_ip, dst_ip, dst_port, app, action, domain, dst_domain, total_bytes
| sort limit=50 -_time

결과 확인:

결과가 있으면 다음과 같은 형태로 나옵니다.

• 도메인 값을 보내지 않는 환경에서는 결과가 0건입니다. 0건 자체는 정상입니다.
• domain과 dst_domain에는 같은 값이 들어갑니다. 어느 쪽으로 조회해도 결과는 동일합니다.

실패 대응:

주의사항

• 목적지 도메인은 두 필드에 중복 저장됩니다: 로그 정의서 v1.1.1의 destination_domain_name은 domain과 dst_domain 양쪽에, destination_domain_id는 domain_id와 dst_domain_id 양쪽에 같은 값으로 저장됩니다. 이전 버전으로 이미 구축한 쿼리·대시보드가 계속 동작하도록 domain을 유지하면서, 출발지·목적지를 구분하는 표준 필드명인 dst_domain을 함께 제공하기 위한 것입니다. 두 필드를 합산하면 중복 집계되므로 한쪽만 사용하세요.
• v1.0.1 형식 장비에는 신규 필드가 생성되지 않습니다: dst_domain, src_floating_ip, dst_floating_ip, session_action, proxy_session_type, app_ 접두 카운터, xff_ip는 v1.1.1 형식으로 로그를 보내는 장비에서만 채워집니다. 기종이 섞인 환경에서는 이 필드로 조회할 때 일부 장비의 로그가 누락될 수 있습니다.
• 미분류 로그 확인: 앱이 모르는 로그 유형 ID가 유입되면 _schema 값이 unknown인 상태로 적재되며 본문은 파싱되지 않습니다. 아래 쿼리로 주기적으로 점검하세요.

table FW_XTG
| search _time >= now() - 1d and _schema == "unknown"
| stats count as cnt by log_type_id
| sort -cnt

관련 문서

• 설치 매뉴얼 — 시스로그 수집기 설정 및 지원 로그 유형
• xtg-traffic-allow — 트래픽 허용 로그 필드 정의
• xtg-traffic-deny — 트래픽 차단 로그 필드 정의
• xtg-user-event — 사용자 이벤트 로그 필드 정의