로그·기능·이동통신

운영의 흔적을 어떻게 남기는가

이 모듈은 장비 기술적 보호조치의 3-B 영역을 다룹니다. P1에서 본 결함 14건 중 5건이 이 페이지에 연결됩니다 — 결함 #7·#8·#9(로그), #11(SNMP·불필요서비스), #14(미사용 인터페이스)입니다. P4는 “장비를 누가, 어떻게 안전하게 운영하는가”였다면, P5는 그 운영의 흔적을 어떻게 남기는가를 봅니다. 각 항목은 ①문제 ②취약 판정 ③설정(Cisco IOS 예시) ④증빙의 4단 구조로 다룹니다. Cisco IOS 예시는 명령 구문 학습용이며, 실제 장비 벤더(Juniper·Arista·Huawei 등)에서는 동등한 설정으로 치환합니다.

§3-4. 로그 관리

3-4-① 원격 로그서버

• 문제: 장비 내부 버퍼는 재부팅 시 소실됩니다. 공격자가 흔적을 지우려 재부팅을 트리거해도, 원격 로그서버에는 사본이 남습니다. 결함 #7의 핵심입니다.
• 취약 판정: logging host 미설정, logging buffered만 사용, 원격서버 도달 불가 시 자동 버퍼 fallback 미설정.
• 설정(Cisco IOS):

! 원격 로그서버 지정 (UDP 514 기본)
logging host 10.10.1.50

! 전송 레벨 (informational 권장 — debug는 과다)
logging trap informational

! 원본(source-interface) 고정 — NAT 환경에서 로그 소스 IP 일관성
logging source-interface GigabitEthernet0/0

! 버퍼도 충분히 크게 (아래 3-4-② 참고)
logging buffered 16384 informational

• 증빙: show logging 출력에 10.10.1.50가 보이고, show running-config | include logging에 logging host와 logging trap이 함께 나옵니다. 원격서버에서 해당 장비의 syslog 수신이 5분 안에 보이는지로 동작 검증합니다.

3-4-② 로깅 버퍼

• 문제: 버퍼가 너무 작으면 트래픽 피크 시 로그가 덮어쓰기됩니다. Syslog 수신이 잠시 끊기는 사이의 흔적도 잃지 않으려면 버퍼가 충분해야 합니다. 본 데모 config의 before는 이 항목에서 양호(16,384)로 설정되어 있습니다 — 다만 기본 디폴트(4,096)가 그대로 남는 장비가 흔한 1차 결함입니다.
• 취약 판정: logging buffered 미설정, 16,384 미만, informational 미만 레벨로 덮어쓰기.
• 설정(Cisco IOS):

! 16,384 바이트 + informational 레벨 (기본 4,096은 트래픽 피크에 취약)
logging buffered 16384 informational

• 증빙: show logging 첫 줄에 버퍼 크기(16384 bytes)가 보입니다. 버퍼가 가득 찰 때의 동작(logging on + 원격 fallback)이 보장되어야 합니다.

3-4-③ 로깅 레벨

• 문제: logging trap이 없으면 기본값(debugging)이 그대로 전송되어 트래픽이 폭주하거나, 반대로 너무 낮춰 필요한 이벤트가 누락됩니다.
• 취약 판정: logging trap 미설정, debugging·warning 등 부적절 레벨.
• 설정(Cisco IOS):

! informational(6) — 운영상 권장 (debug는 평상시 과다)
logging trap informational

! facility는 local0~local7 — 원격서버의 facility별 라우팅과 일치
logging facility local3

• 증빙: show running-config | include logging에 logging trap informational이 보이고, 원격서버의 facility 매핑(예 rsyslog의 local3.*)과 일치합니다.

3-4-④ NTP

• 문제: 시각이 어긋나면 로그 상관분석이 불가능합니다. 같은 시각에 발생한 두 이벤트가 다른 장비에서 다른 시각으로 기록되면 인과관계가 끊깁니다. 결함 #8의 핵심입니다.
• 취약 판정: ntp server 미설정, 인증 없이 평문 NTP 사용, NTP 서버 자체의 시각 무결성 미검증.
• 설정(Cisco IOS):

! 신뢰 NTP 서버 (내부 stratum-1/2 또는 공인 NTP)
ntp server 10.10.1.10
ntp server time.xenorix.local prefer

! NTP 인증 (스푸핑 방지)
ntp authenticate
ntp authentication-key 1 md5 <shared-key>
ntp trusted-key 1

• 증빙: show ntp status에 clock synchronized, stratum 값이 보이고, show ntp associations에 등록 서버가 *(현재 동기 대상)로 표시됩니다.

3-4-⑤ 타임스탬프

• 문제: uptime 기반 타임스탬프는 재부팅 후 초기화되어 사후 분석이 불가능합니다. NTP를 맞춰도 timestamp 형식이 uptime이면 시각 정보가 사라집니다.
• 취약 판정: service timestamps log uptime, service timestamps log datetime 미설정.
• 설정(Cisco IOS):

! 절대시각 + 밀리초 + 타임존 표시
service timestamps log datetime msec localtime show-timezone
service timestamps debug datetime msec localtime show-timezone

• 증빙: show logging 출력 줄이 *Mar 1 12:34:56.789 KST: 형식으로 보입니다. uptime 기반(5w2d:)이 아니어야 합니다.

3-4-⑥ 접속·명령어 기록

• 문제: “누가, 언제, 어떤 명령을 실행했는가”는 결함의 인과 추적에 필수입니다. AAA 인증을 적용해도 회계(Accounting)가 없으면 누가 무엇을 했는지 영원히 모릅니다. 결함 #8·#9와 결합됩니다.
• 취약 판정: aaa accounting commands 미적용, start-stop 누락, TACACS+ 서버만 인증하고 회계는 로컬.
• 설정(Cisco IOS):

! 모든 명령어(15 = privilege 15) 시작/종료 이벤트 기록
aaa accounting commands 15 default start-stop group tacacs+

! exec 세션도 함께 (login/logout 시각)
aaa accounting exec default start-stop group tacacs+

! 네트워크 이벤트(예: ACL 변경)도 회계
aaa accounting network default start-stop group tacacs+

• 증빙: TACACS+ 서버의 회계 로그(tac_plus의 accounting log)에 사용자별 명령어·시각이 보입니다. 1차 점검 시 샘플 명령 3개를 골라 회계 로그와 1:1 대조합니다.

§3-4 실무 포인트

로그는 “많이 남기는 것”보다 “사후 분석에 쓸 수 있게 남기는 것”이 목표입니다. 시각 동기화(NTP) + 절대시각(datetime) + 원격서버 + 회계 4축이 모두 갖춰져야 인과 추적이 가능합니다. 로그 검토 자체가 결함 #9의 통제 항목입니다 — 자동 수집 + 일/주간 검토 절차 + 이상 징후 에스컬레이션 규칙을 정책 문서에 못 박습니다.

§3-5. 기능 관리

3-5-① SNMP community

• 문제: public·private는 모든 자료에 공개된 디폴트입니다. RW(읽기/쓰기) community는 장비 설정을 외부에서 바꾸는 통로가 됩니다. 결함 #11의 핵심입니다.
• 취약 판정: public·private 사용, RW community 사용, ACL 없는 RO community, SNMPv1/v2c 평문 사용.
• 설정(Cisco IOS):

! SNMPv3 (평문 v2c는 비권장 — v3 + auth + priv)
snmp-server group NOC-GROUP v3 priv

! 사용자별 auth(해시) + priv(AES)
snmp-server user nocops NOC-GROUP v3 auth sha <auth-pw> priv aes 128 <priv-pw>

! v2c 호환이 필요하면 — RO + ACL + 복잡한 community
snmp-server community Cx7pQ2 RO 20

! 접근 제한
access-list 20 permit host 10.10.1.30
access-list 20 deny any log

• 증빙: show snmp community에 Cx7pQ2(또는 v3 사용자)만 보이고, show snmp group에 v3 그룹이 등록됩니다. 외부에서 public·private로 GET 요청 시 거부되는지로 동작 검증합니다.

3-5-②~⑥ 불필요 서비스 5그룹

• 공통 판정 기준: 활성인데 정책상 불필요하면 결함입니다. “어차피 내부망이라 괜찮다”는 판정 근거가 될 수 없습니다 — 내부 침해 시 가로채기·재배포의 통로가 됩니다.
• 설정(Cisco IOS):

! 원격관리
no ip http server
no ip http secure-server

! 레거시 진단
no service tcp-small-servers
no service udp-small-servers

! 정보유출
no cdp run

! 라우팅·ICMP
no ip source-route
no ip gratuitous-arps

! 스푸핑 방지 (인터페이스 단위)
interface GigabitEthernet0/0
ip verify unicast source reachable-via rx

• 증빙: show running-config | include (cdp|http|small-servers|source-route)에 차단 명령이 보이고, 외부 스캐너로 포트 80/443/tcp-small-servers/CDP가 노출되지 않는지로 검증합니다.

3-5-⑦ 미사용 인터페이스 (L2)

• 문제: 사용하지 않는 스위치 포트는 물리적 침투의 출입구입니다. 임의의 노트북을 꽂아 802.1X 없이 내부망에 진입하거나, DHCP Spoofing·ARP Spoofing의 발판으로 쓰입니다. 결함 #14의 핵심입니다.
• 취약 판정: 미사용 포트 shutdown 미적용, Port Security 미적용, DHCP Snooping/DAI 미적용, BPDU Guard 미적용, Native VLAN 변경 미적용, DTP 비활성 미적용.
• 설정(Cisco IOS):

! 사용 중인 포트 (운영 정의)
interface GigabitEthernet1/0/1
switchport mode access
switchport access vlan 10
spanning-tree portfast
spanning-tree bpduguard enable
ip dhcp snooping limit rate 15

! 미사용 포트 — 5단계 잠금
interface range GigabitEthernet1/0/2 - 48
shutdown
switchport mode access
switchport access vlan 999            ! blackhole VLAN
spanning-tree bpduguard enable
spanning-tree guard root
switchport port-security maximum 2
switchport port-security violation restrict
switchport nonegotiate                  ! DTP 차단
no cdp enable

! 글로벌 (DHCP Snooping + DAI)
ip dhcp snooping
ip dhcp snooping vlan 10
ip arp inspection vlan 10

• 증빙: show ip interface brief | include down에 미사용 포트가 administratively down으로 보이고, show port-security에 모든 포트가 Secure-down입니다. 임의 노트북을 미사용 포트에 연결해도 내부망 진입이 차단되는지로 현장 시연이 가장 강한 증빙입니다.

§3-6. 이동통신 보안

이동통신은 유선 장비 보안의 연장선에 더해 가입자 정보·시그널링·운용 트래픽의 우선순위가 다른 차원으로 적용됩니다. 본 절은 15분 산문으로 핵심만 짚고, 별도 심화 과정(2026년 개편안)에서 RAN·Core·운용관리망을 다룹니다.

3-6-① 보호 대상 우선순위

1. 가입자 인증 정보(최우선): LTE HSS(Home Subscriber Server) / 5G UDM(Unified Data Management). SIM 자격증명·키(Ki/OP/OPc)·가입자 프로파일이 집중 저장됩니다. DB 자체 암호화 + 접근통제 + 감사 로그가 필수입니다.
2. 시그널링 평면: LTE Diameter(S6a/S1-AP) / 5G SBI(HTTP2/Service-Based Interface). 평문 시그널링은 위치·IMSI 노출의 통로가 됩니다 — TLS/Diameter 암호화 적용이 권고입니다.
3. 운용 관리망(O&M): NMS/EMS 트래픽, 원격 업그레이드, 로그 수집. 유선망과 분리된 별도 대역 + 점프호스트 + 4-eyes 원칙이 표준입니다.

3-6-② 통제 항목 (요약)

• RAN(NodeB/eNB/gNB): 물리적 접근 통제, 펌웨어 무결성 검증, 시그널링 암호화 활성화.
• 전송 구간: Backhaul은 IPsec/MACsec, 동기식 Ethernet(SyncE)·PTP 시각 동기화.
• Core(5G): AMF/SMF/UPF 분리, SBI 간 mTLS, Network Slice 격리, NEF/API 게이트웨이 인증·인가.
• 운용 관리망: NMS 서버는 운영 트래픽과 물리·논리 분리, 2-factor 인증 + audit log + 외부 USB 차단.

[강의직전확인] 이동통신 보안 개편안에서 별도 장이 신설될 수 있습니다 — 본 페이지의 15분 산문은 개편안의 첫 단추 역할이며, 별도 장의 추가 시 본 절은 P5의 “기초 정렬”로 흡수될 예정입니다. 최신 안내는 과정 시작 직전 공지합니다.

§3-7. 종합 시연 — ConfigAudit 위젯

아래 위젯은 취약 config(before) 를 24항목으로 자동 감사하고, 조치 config(after) 와의 diff까지 한 화면에서 보여 줍니다. 좌측 카테고리 칩으로 영역을 좁히고, before/after 토글로 조치 전·후를 즉시 비교할 수 있습니다. 본 데모의 before/after는 모두 가상 config이며, 실제 환경 적용 전 벤더 문서로 명령을 검증해야 합니다.

§3-7 ①~③ 월요일 3가지 점검

1. 상위 10개 show run 점검: show running-config | include (enable|password|secret|aaa|access-class|transport|exec-timeout|logging|cdp|cdp|http|small-servers|verify) — 24항목의 핵심 키워드를 한 번에 훑습니다. 누락된 줄이 결함의 1차 신호입니다.
2. VTY ACL · NTP 전장비 점검: show running-config | section line vty로 0~4 라인에 access-class·transport input ssh가 있는지, show ntp status로 전장비 시각 동기화 상태를 확인합니다.
3. 방화벽 Any 정책 회수: 방화벽의 any → any 허용 규칙을 모두 찾고(show running-config | include any), 정책상 필요한지 재검토해 불필요 회수합니다. 이 절차가 P3(방화벽·Snort)와 P5(로그·기능)의 연결점입니다.

§관통축 닫기 — 이 페이지가 닫는 결함

결함 14건을 인증기준 64개 체계에 대응시킨 전체 매핑은 P6(전체 매핑표 보기)에서 다룹니다.

§3-7 닫기 — 5개 결함을 한 번에

P5는 “운영의 흔적을 어떻게 남기는가” 를 다룹니다. 결함 #7·#8·#9는 로그의 3축(원격서버·시각동기화·검토절차)이고, #11은 불필요한 통로의 차단(SNMP·5그룹), #14는 물리 출입구의 잠금(미사용 인터페이스)입니다. 위 위젯이 그 5개 결함의 현재 상태를 24항목 감사로 한 번에 보여 주고, 조치 후의 diff로 변경 근거를 남깁니다. 매핑 전체와의 연동은 P6(전체 매핑표 보기)에서 확인하실 수 있습니다.