📚 네트워크 · 패킷 분석 › 04. 네트워크 장비 실습 — 198편
이전 글: 197. 네트워크 보안 아키텍처 · 다음 글: 199. 네트워크 장비 로그 분석
1. 개념
네트워크 장비 로그의 상당수는 공격이 아니라 장애·운영 이벤트입니다. 링크가 끊기고, CPU가 치솟고, 이중화 장비가 전환됩니다. 그런데 같은 로그가 공격의 결과이거나 공격을 가리는 연막일 수도 있습니다. 관제자는 "장애인가, 보안 이벤트인가, 둘 다인가"를 구분해야 합니다.
| 현상 | 장애로서의 원인 | 보안 이벤트로서의 가능성 |
|---|---|---|
| 링크 다운·업 반복 | 케이블·트랜시버 불량, 포트 설정 불일치 | 무단 장비 연결·분리, 물리 접근 |
| 세션(연결) 테이블 포화 | 정상 트래픽 급증, 테이블 크기 부족 | SYN Flood 등 자원 고갈형 DoS, 대량 스캔 |
| CPU·메모리 과부하 | 라우팅 재계산, 로그 폭주, 버그 | 장비 자체를 겨냥한 트래픽, 관리 포트 공격 |
| HA(이중화) 전환 | 주 장비 장애, 유지보수 | 장애 유발 후 다른 경로 노출 |
| MAC 주소 플래핑 | 루프, 이중 연결 설정 오류 | MAC 스푸핑, 무단 브리지 |
| 설정 변경 로그 | 정상 작업 | 관리자 계정 탈취 후 정책 변경 |
2. 동작 원리
장애와 보안 이벤트가 서로 이어지는 대표적인 연쇄입니다.
대량 트래픽 유입 (정상 급증 또는 DoS)
↓ 방화벽 세션 테이블 포화 / CPU 과부하
↓ 새 연결 드롭 → 서비스 장애 신고
↓ (경우에 따라) 로그 송신도 밀림 → SIEM 로그 공백
↓ 운영팀: 장애 조치 (재부팅, 예외 정책 추가, 바이패스)
↓ 조치 중 검사 공백·임시 허용 정책 발생 → 새로운 보안 위험인라인 보안장비는 과부하·장애 시 설정에 따라 검사 없이 통과(Fail-open) 할 수 있습니다(157. IPS란 무엇인가). 이 때문에 "장애 중에 무엇이 통과했는가"는 장애가 끝난 뒤에도 관제가 확인해야 할 질문으로 남습니다.
3. 주요 특징
장비 로그 문구는 제품마다 다르지만, 형태를 알아 두면 검색에 도움이 됩니다. 아래는 Cisco IOS 계열과 Linux 커널 메시지의 형식 예시(값은 환경마다 다름)입니다.
| 형식 예시 | 의미 |
|---|---|
%LINK-3-UPDOWN: Interface GigabitEthernet0/1, changed state to down | 물리 링크 상태 변화 |
%LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/1, changed state to down | 링크 프로토콜 상태 변화 |
%SYS-5-CONFIG_I: Configured from console by admin on vty0 (10.10.99.5) | 설정 변경 (계정·접속 위치 포함) |
%SW_MATM-4-MACFLAP_NOTIF: Host 000c.29aa.bbcc in vlan 10 is flapping between port Gi0/2 and port Gi0/3 | 같은 MAC이 여러 포트에서 학습됨 |
%PORT_SECURITY-2-PSECURE_VIOLATION: Security violation occurred ... | 포트 보안 위반(허용되지 않은 MAC) |
nf_conntrack: table full, dropping packet | Linux 연결 추적 테이블 포화 (커널 버전에 따라 앞부분 문구 다름) |
Cisco 형식의 %기능-심각도-이름에서 가운데 숫자는 syslog 심각도(0이 가장 심각)입니다. 심각도가 낮게(숫자가 크게) 찍힌 이벤트라도 보안상 중요할 수 있습니다. 설정 변경(SYS-5)이 그 예입니다.
장애와 공격을 구분할 때 함께 볼 정보입니다.
| 확인 항목 | 장애 쪽 근거 | 공격 쪽 근거 |
|---|---|---|
| 변경 관리 기록 | 예정된 작업과 시간 일치 | 작업 기록 없음 |
| 트래픽 출발지 분포 | 평소 사용자·서비스 분포 | 특정 출발지 집중, 처음 보는 출발지 다수 |
| 동시 발생 이벤트 | 하드웨어 오류, 전원 이벤트 | IDS Alert, 인증 실패, 설정 변경 |
| 계정·접속 위치 | 운영 담당자, 관리망 | 평소와 다른 계정·시간·출발지 |
4. 예시
실습 예시 — 방화벽 역할 Linux VM에서 장애성 지표를 확인하는 명령입니다(Rocky·Ubuntu 공통, conntrack 명령은 Rocky conntrack-tools, Ubuntu conntrack 패키지). 인터페이스는 예시(값은 환경마다 다름)입니다.
# 인터페이스 오류·드롭 카운터 (RX/TX errors, dropped)
ip -s link show ens33
# 링크 상태 변화 기록
journalctl -k --since "1 hour ago" | grep -iE "link (is )?(up|down)"
# 연결 추적 테이블 현재 사용량과 최대치
sudo conntrack -C
sysctl net.netfilter.nf_conntrack_max
# 테이블 포화 메시지 확인
journalctl -k | grep -i "nf_conntrack: table full"
# 상태별 연결 수 (SYN_RECV가 비정상적으로 많은지)
sudo conntrack -L -p tcp 2>/dev/null | awk '{print $4}' | sort | uniq -c | sort -rnconntrack -C 값이 nf_conntrack_max에 가까워지고 SYN_RECV 상태가 특정 목적지에 몰려 있다면, 정상 트래픽 급증보다 자원 고갈형 공격 가능성을 우선 검토합니다. 반대로 ESTABLISHED가 고르게 늘었다면 정상 사용량 증가일 가능성이 큽니다.
📷 [실습 화면 삽입 위치]
conntrack -C와nf_conntrack_max값을 나란히 확인하고, 상태별 연결 수 집계 결과가 출력된 화면
5. 보안 관점
- 장애 대응 중 만든 임시 조치(Any 허용 정책, IPS 바이패스, 로그 비활성화)는 대응 후 원복되지 않으면 그대로 보안 구멍이 됩니다.
- 공격자는 장애를 주의 분산용으로 쓸 수 있습니다. 운영팀이 장애에 집중하는 동안 다른 경로에서 실제 침투가 진행될 수 있습니다.
- 장비 CPU를 올리는 트래픽 중에는 장비 자신을 목적지로 하는 관리·제어 트래픽이 있습니다. 관리 인터페이스를 관리망으로 제한하는 이유입니다.
- MAC 플래핑과 포트 보안 위반은 L2 공격의 흔적일 수 있으므로 설정 오류로 단정하지 않습니다.
6. SOC 관점
관제자가 확인할 질문
- 이 장애 이벤트와 같은 시각에 변경 작업 일정이 있었는가?
- 장애 전후로 IDS Alert, 인증 실패, 설정 변경 로그가 있었는가?
- 장애 동안 로그 공백이 있었는가? 인라인 장비가 바이패스로 동작한 시간이 있었는가?
- 장애 조치로 추가된 임시 정책은 무엇이며 원복되었는가?
장애성 로그 수신 (링크 다운 / 테이블 포화 / HA 전환)
↓ 변경 관리 기록 대조
예정 작업 → 운영 이벤트로 기록, 임시 조치 원복 여부만 추적
예정 없음 → 트래픽 출발지 분포·동시 보안 이벤트 확인
→ 공격 정황 있으면 보안 사고로 에스컬레이션
→ 없으면 운영팀 전달 + 재발 모니터링오탐 주의: 장애 로그를 모두 보안 사고로 올리면 운영팀과의 신뢰가 떨어지고, 반대로 모두 장애로 넘기면 공격을 놓칩니다. 판단 근거(변경 기록, 출발지 분포, 동시 이벤트)를 남겨 두는 것이 중요합니다. 비정상 트래픽 판단은 06 영역 294. 비정상 Network Traffic 탐지에서 다룹니다.
7. 핵심 정리
- 네트워크 장비 로그의 상당수는 장애·운영 이벤트지만, 같은 로그가 공격의 결과이거나 연막일 수 있습니다.
- 링크 상태 변화, 세션 테이블 포화, CPU 과부하, HA 전환, MAC 플래핑, 설정 변경이 대표적인 판단 대상입니다.
- 변경 관리 기록, 트래픽 출발지 분포, 동시 보안 이벤트, 계정·접속 위치로 장애와 공격을 구분합니다.
- 장애 중 Fail-open·로그 공백·임시 허용 정책은 장애 후에도 확인해야 할 보안 위험입니다.
- Linux 장비에서는
ip -s link,conntrack -C, 커널 로그로 장애성 지표를 확인할 수 있습니다.
