199. 네트워크 장비 로그 분석

📚 네트워크 · 패킷 분석 › 04. 네트워크 장비 실습 — 199편
이전 글: 198. 네트워크 장비 장애와 보안 이벤트 · 다음 글: 200. SOC 관점의 네트워크 장비 이벤트 분석

1. 개념

네트워크 장비 로그 분석은 스위치, 라우터, 방화벽, 보안장비가 남긴 로그를 모아 시간순으로 정리하고, 의미 있는 변화나 이상을 찾는 작업입니다. 분석의 품질은 도구보다 수집 단계의 품질(빠짐없이 모였는가, 시각이 맞는가, 장비를 구분할 수 있는가)에 크게 좌우됩니다.

대부분의 네트워크 장비는 syslog로 로그를 보냅니다. syslog에는 두 가지 대표 형식이 있습니다.

형식	헤더 구성	형식 예시(값은 환경마다 다름)
RFC 3164 (BSD syslog)	PRI, 시각(연도·타임존 없음), 호스트, 메시지	<189>Sep 30 10:15:32 sw01 %LINK-3-UPDOWN: ...
RFC 5424	PRI, 버전, ISO 8601 시각(타임존 포함), 호스트, 앱 이름, 프로세스 ID, 메시지 ID, 구조화 데이터, 메시지	<189>1 2026-09-30T10:15:32.123+09:00 sw01 - - - - %LINK-3-UPDOWN: ...

PRI 값은 Facility × 8 + Severity입니다. 예를 들어 <189>는 189 = 23 × 8 + 5이므로 Facility 23(local7), Severity 5(Notice)입니다. 네트워크 장비는 기본 Facility로 local7을 쓰는 경우가 많습니다(제품 기본값은 확인 필요).

---

2. 동작 원리

중앙 수집부터 분석까지의 흐름입니다.

[스위치 / 라우터 / 방화벽]  NTP로 시각 동기화, syslog 송신 (UDP/TCP 514)
    ↓ 관리망
[rsyslog 수집 서버]  송신 IP 제한 → 장비별·날짜별 파일로 저장
    ↓
[분석]  ① 범위 정하기 (시간·장비)
        ② 집계 (장비별·심각도별·메시지 유형별 건수)
        ③ 평소와 다른 부분 찾기 (급증, 처음 보는 메시지, 설정 변경)
        ④ 다른 로그와 연결 (IDS, 서버, 인증 로그) → 타임라인
    ↓ SIEM으로 전달 (정규화·상관 분석은 196편)

RFC 3164 형식은 시각에 연도와 타임존이 없어 수집 서버가 받은 시각으로 보정하거나, 장비가 메시지 안에 타임존을 넣도록 설정해야 합니다. 여러 장비의 로그를 합칠 때 가장 흔한 실수가 타임존 차이입니다.

---

3. 주요 특징

syslog 심각도 8단계(RFC 5424)입니다.

값	이름	네트워크 장비 로그 예
0	Emergency	시스템 사용 불가
1	Alert	즉시 조치 필요
2	Critical	하드웨어 치명 오류, 일부 보안 위반
3	Error	링크 다운 등 오류
4	Warning	MAC 플래핑 경고, 임계치 근접
5	Notice	설정 변경, 링크 프로토콜 상태 변화
6	Informational	세션 생성·종료, 정책 허용·차단(제품에 따라)
7	Debug	디버그 출력 (운영에서는 보통 끔)

분석을 어렵게 만드는 수집 문제와 대응입니다.

문제	증상	대응
시각 불일치	원인보다 결과가 먼저 기록됨	모든 장비 NTP 동기화, 타임존 포함 형식
호스트 구분 불가	호스트명이 기본값이거나 IP만 기록	장비 호스트명 설정, 송신 IP 기준 파일 분리
전송 유실	특정 시간대 로그 공백	TCP 전송, 수집 서버 상태 감시
송신 레벨 설정	필요한 메시지가 아예 안 옴	장비의 송신 심각도 기준 확인

---

4. 예시

실습 예시 — rsyslog 수집 서버(Rocky·Ubuntu 모두 rsyslog 기본 설치)를 구성하고 장비 로그를 집계하는 흐름입니다. 대역·경로는 예시(값은 환경마다 다름)입니다.

# /etc/rsyslog.d/10-remote.conf — 관리망(10.10.99.0/24) 장비 로그를 장비별 파일로 저장
module(load="imudp")
input(type="imudp" port="514")
module(load="imtcp")
input(type="imtcp" port="514")

template(name="PerHost" type="string" string="/var/log/remote/%FROMHOST-IP%/%$YEAR%-%$MONTH%-%$DAY%.log")
if $fromhost-ip startswith '10.10.99.' then {
    action(type="omfile" dynaFile="PerHost")
    stop
}

sudo rsyslogd -N1                      # 설정 문법 검사
sudo systemctl restart rsyslog
# Rocky
sudo firewall-cmd --permanent --add-port=514/udp --add-port=514/tcp && sudo firewall-cmd --reload
# Ubuntu
sudo ufw allow from 10.10.99.0/24 to any port 514

장비 쪽 송신 설정 예시입니다(Cisco IOS 계열, 명령은 장비·버전에 따라 다름).

service timestamps log datetime msec localtime show-timezone
ntp server 10.10.99.1
logging host 10.10.99.10
logging trap informational

수집된 로그를 집계합니다.

# 장비별 로그 건수
sudo find /var/log/remote -name "2026-09-30.log" -exec wc -l {} +

# Cisco 형식 메시지 유형(%기능-심각도-이름)별 건수
sudo grep -hoE "%[A-Z0-9_]+-[0-7]-[A-Z0-9_]+" /var/log/remote/*/2026-09-30.log | sort | uniq -c | sort -rn | head

# 설정 변경만 추려 시간순 확인
sudo grep -h "CONFIG_I" /var/log/remote/*/2026-09-30.log | sort

📷 [실습 화면 삽입 위치] /var/log/remote/ 아래 장비 IP별 디렉터리 구조와, 메시지 유형별 건수 집계 결과 화면

---

5. 보안 관점

• UDP syslog는 출발지 위조가 쉽고 암호화되지 않습니다. 수집 서버에서 송신 IP를 제한하고, 가능하면 관리망 안에서만 주고받으며, 필요하면 TLS 전송을 검토합니다.
• 수집 서버는 모든 장비의 기록을 가진 고가치 대상입니다. 접근 권한 최소화, 무결성 보존(해시·쓰기 제한), 보관 기간 정책이 필요합니다.
• 장비의 로그 송신 설정이 바뀌거나 꺼지는 것 자체가 보안 이벤트입니다. 장비별 "마지막 수신 시각"을 감시합니다.
• 디버그 레벨 로그를 운영 중 켜면 장비 부하가 늘고 민감한 정보가 기록될 수 있습니다.

---

6. SOC 관점

관제자가 확인할 질문

• 분석 대상 시간에 모든 관련 장비의 로그가 빠짐없이 있는가? 공백 구간은 없는가?
• 장비들의 시각이 같은 기준(NTP·타임존)인가? 로그 시각이 수집 서버 수신 시각인지 장비 기록 시각인지 구분했는가?
• 평소 없던 메시지 유형이 나타났거나, 특정 메시지가 급증했는가?

분석 요청 (시간 범위 + 관련 장비)
    ↓ 장비별 로그 존재·공백 확인
    ↓ 시각 기준 통일 (타임존 보정)
    ↓ 메시지 유형별 집계 → 평소와 비교
    ↓ 이상 항목을 다른 로그(IDS·서버·인증)와 연결 → 타임라인

오탐 주의: 심각도 숫자만으로 우선순위를 정하면 설정 변경(Notice) 같은 중요한 이벤트를 놓칩니다. 메시지 유형별로 보안 중요도를 따로 정의해 두는 것이 좋습니다. 방화벽 로그의 필드 분석은 06 영역 273. Firewall Log 분석에서 다룹니다.

---

7. 핵심 정리

• 네트워크 장비 로그 분석의 품질은 수집 단계(누락 없음, 시각 일치, 장비 구분)에 좌우됩니다.
• syslog는 RFC 3164와 RFC 5424 형식이 있으며, PRI는 Facility × 8 + Severity입니다.
• rsyslog 수집 서버에서 송신 IP를 제한하고 장비별·날짜별 파일로 저장하면 분석이 쉬워집니다.
• 집계(장비별·메시지 유형별) → 평소와 비교 → 다른 로그와 연결 순서로 분석합니다.
• 로그 송신 중단, 설정 변경 같은 이벤트는 심각도 숫자와 관계없이 보안상 중요합니다.