계정·접근·패치

장비를 누가, 어떻게, 얼마나 안전하게 운영하는가

이 모듈은 장비 기술적 보호조치의 3-A 영역을 다룹니다. P1에서 본 결함 14건 중 6건이 이 페이지에 연결됩니다 — 결함 #1·#2·#3(계정), #4·#5(접근), #10(패치)입니다. 각 항목은 ①문제 ②취약 판정 ③설정(Cisco IOS 예시) ④증빙의 4단 구조로 다룹니다. Cisco IOS 예시는 명령 구문 학습용이며, 실제 장비 벤더(Juniper·Arista·Huawei 등)에서는 동등한 설정으로 치환합니다.

§3-1. 계정 관리

3-1-① 기본 패스워드 변경

• 문제: 출고 시 기본 패스워드(cisco, admin 등)를 그대로 두면 인터넷 공개 자료 한 줄로 장비가 노출됩니다. 패스워드 변경 의무를 벤더 매뉴얼이 아닌 정책 문서에서 명시적으로 못 박아야 합니다.
• 취약 판정: 기본값 사용, 동일 모델·동일 출하 시점의 일괄 적용 흔적, 패스워드 자리에 enable password 평문 잔존.
• 설정(Cisco IOS):

! 개인별 계정 생성 (Type 5 = MD5 해시; 신형 IOS는 algorithm-type으로 Type 8/9 권장)
username <id> secret <pw>

! 로컬 인증 fallback (AAA 장애 대비)
aaa authentication login default local

• 증빙: show running-config | include username 출력에 개인별 계정만 보이고, enable secret이 평문(enable password)보다 우선 적용됨을 show running-config | include enable로 확인합니다.

3-1-② 패스워드 복잡성

• 문제: 짧거나 단일 문자류로 된 패스워드는 오프라인 크랙에 무력합니다. 패스워드 정책이 서버에만 적용되고 장비는 빠져 있는 경우가 가장 흔합니다.
• 취약 판정: 길이 8 미만, 영문 단일 클래스, 정기 변경 주기 미정의.
• 설정(Cisco IOS):

! 최소 길이
security passwords min-length 8

! 평문 저장 금지
service password-encryption

! enable은 Type 5/9/10 해시만 허용
enable secret <pw>

• 증빙: show running-config | include password에 min-length 8과 service password-encryption이 동시에 보이고, show running-config | include enable에 secret만(평문 enable password 부재) 보입니다.

3-1-③ 패스워드 암호화 저장

• 문제: enable password는 기본적으로 평문(Type 0)으로 저장되고, service password-encryption을 적용해도 Type 7(가역적 Vigenère 방식)이라 평문과 거의 동급입니다. 설정 백업 파일이 한 번 새면 즉시 복호화됩니다.
• 취약 판정: enable password 존재, username … password …(Type 7) 잔존, 설정 백업이 평문으로 보존됨.
• 설정(Cisco IOS):

! enable secret은 해시로 저장 (기본 Type 5 = MD5; 신형 IOS는 algorithm-type으로 Type 8/9 권장)
enable secret <pw>

! 사용자 계정도 secret 사용 (password 키워드는 Type 7)
username <id> secret <pw>

! service password-encryption은 Type 7 난독화(약함, enable secret 대체 불가) — 평문 어깨너머 노출만 완화
service password-encryption

• 증빙: show running-config에서 enable password 줄이 0건이고, show running-config | include username의 모든 계정이 secret(Type 5/9)으로 저장됩니다.

3-1-④ 계정 잠금 임계값

• 문제: 로그인 실패가 무제한이면 무차별 대입(brute force) 으로 평문 인증을 깰 수 있습니다. SSH가 안전해 보여도 인증 단계 앞단의 무제한 시도는 위험합니다.
• 취약 판정: 로그인 실패 횟수 제한 부재, 실패 로그 미수집, 잠금 정책 미적용.
• 설정(Cisco IOS):

! 60초 동안 5회 실패 시 60초간 차단
login block-for 60 attempts 5 within 60

! 차단 중에는 로깅 강화
login on-failure log
login on-success log

• 증빙: show login failures 출력에 누적 실패 횟수가 보이며, 동일 IP에서 5회 실패 후 차단이 시작됩니다. Syslog로 중앙 수집(P5 로그 관리)까지 연결합니다.

3-1-⑤ 사용자별 계정 부여

• 문제: admin·root 같은 공용 계정을 여러 사람이 공유하면, 퇴직·직무변경 시 즉시 회수가 어렵고 누가 무엇을 했는지 식별이 불가능합니다. 결함 #1의 정체입니다.
• 취약 판정: 공용 계정 공유, AAA 서버 미연동, 로컬 계정이 인증의 유일한 수단.
• 설정(Cisco IOS):

! AAA 활성화 (반드시 먼저 — 이 명령 없이 뒤의 aaa authentication/authorization은 무효)
aaa new-model

! TACACS+ 서버 1·2 순서
tacacs server PRIMARY
address ipv4 10.10.1.20
key <shared-key>
tacacs server SECONDARY
address ipv4 10.10.1.21
key <shared-key>

! 콘솔/VTY 모두 TACACS 우선, 실패 시 로컬
aaa authentication login default group tacacs+ local
aaa authorization exec default group tacacs+ local
aaa accounting exec default start-stop group tacacs+

• 증빙: AAA 서버 인증 로그에서 개인별 username이 보이고, show aaa servers 출력에 TACACS+ 서버 두 대가 등록되어 있습니다. AAA 서버 장애 시 로컬 백업 계정으로 비상 로그인 가능 여부를 점검표에 기록합니다.

3-1-⑥ 명령어별 권한 수준

• 문제: 모든 운영자가 privilege 15이면 조회만 필요한 인원도 변경 가능하고, 변경 행위자를 좁혀서 가려낼 수 없습니다. 결함 #3의 정체입니다.
• 취약 판정: 전원 privilege 15, 명령어별 권한 분리 없음, show running-config조차 인가 필요.
• 설정(Cisco IOS):

! 레벨 1(조회) — 로그인 직후 기본
! 레벨 5(운영) — show/ping 등 가벼운 진단
privilege exec level 5 show running-config
privilege exec level 5 show ip interface brief
privilege exec level 5 ping

! 레벨 15(변경) — enable 진입
enable secret level 15 <pw>

! enable 명령 자체도 레벨 인가 대상
privilege exec level 15 enable

• 증빙: show privilege로 현재 권한 레벨이 보이고, show running-config | include privilege에 명령어별 레벨 분리가 기록됩니다. AAA 환경에서는 aaa authorization commands까지 더해 명령어 단위 인가·회계를 닫습니다.

§3-1 실무 포인트

AAA 연동이 사실상 유일한 근본 해법입니다 — 개인별 계정·명령어 인가·명령어 단위 회계(Accounting)를 한꺼번에 해결합니다. AAA 서버 장애 시 접속 불가를 대비해 로컬 백업 계정을 설계합니다(aaa authentication login default group tacacs+ local). 권한 수준은 1(조회)·5(운영)·15(변경)처럼 최소 2단계는 나눕니다. 퇴직·직무변경 시 계정 회수 절차는 2026 개편안의 현장 실증형 심사에서 직접 시연을 요구할 수 있습니다.

§3-2. 접근 관리

3-2-① VTY 접근 ACL

• 문제: VTY(Virtual Teletype) 라인에 ACL이 없으면 내부망 어디서나 장비로 접속할 수 있어, 한 곳이 뚫리면 모든 장비가 노출됩니다. 결함 #4의 정체입니다.
• 취약 판정: line vty에 access-class 부재, 표준 ACL 대역이 0.0.0.0/0.
• 설정(Cisco IOS):

! 관리자 대역만 허용 (점프호스트/관리망)
access-list 10 permit 10.10.1.0 0.0.0.255
access-list 10 deny any log

line vty 0 4
access-class 10 in
transport input ssh
exec-timeout 5 0
login authentication default

• 증빙: show ip access-lists 10에 permit·deny 규칙이 보이고, show running-config | section line vty에 access-class 10 in이 적용됩니다. 무단 대역에서 ssh 시도 → 거부 로그를 Syslog로 수집합니다.

3-2-② 안전한 프로토콜

• 문제: Telnet은 평문이라 스니핑 한 번에 자격 증명 탈취입니다. SSH로 바꿔도 v1만 허용하면 MITM(중간자 공격)에 취약합니다.
• 취약 판정: transport input telnet 또는 all, SSHv1 허용, 호스트키 길이 1024-bit.
• 설정(Cisco IOS):

! 호스트키 2048-bit 이상
crypto key generate rsa modulus 2048

! SSH 버전 강제
ip ssh version 2

! vty는 SSH만 허용 (Telnet/SSH v1 차단)
line vty 0 4
transport input ssh

! 죽은 알고리즘 비활성 (SSHv2 컴플라이언스)
ip ssh time-out 60
ip ssh authentication-retries 3

• 증빙: show ip ssh 출력에 SSH Enabled - version 2.0, show crypto key mypubkey rsa에 2048-bit 키가 보입니다. Telnet 포트(23) 차단 확인은 P3(방화벽) 영역의 점검표로 연결합니다.

3-2-③ 세션 타임아웃

• 문제: 로그인 후 자리비움 상태로 세션이 무한 유지되면, 누군가 지나가다 명령을 실행해도 본인이 한 것처럼 남습니다. 결함 #14(미사용 계정·인터페이스)와 결합되면 더 위험합니다.
• 취약 판정: exec-timeout 0 0 또는 설정 누락, 콘솔·VTY 간 불일치.
• 설정(Cisco IOS):

! 콘솔 라인
line console 0
exec-timeout 5 0
login authentication default

! VTY 라인
line vty 0 4
exec-timeout 5 0

! AUX 라인
line aux 0
no exec
transport input none

• 증빙: show running-config | section line 출력에서 exec-timeout 5 0이 타임아웃이 필요한 라인(con/vty)에 적용됨이 보입니다. AUX 라인(line aux 0)은 no exec + transport input none으로 비활성화하므로 exec-timeout이 적용되지 않습니다. 5분 후 세션이 끊기는지 현장에서 5분 대기 시연이 가장 강한 증빙입니다.

3-2-④ 동시 접속 세션 제한

• 문제: 한 장비에 동시에 여러 명이 붙으면 변경 행위자 식별이 어렵고, 한 사람이 점유하면 다른 운영자가 잠깁니다. 동시 접속은 VTY 전 라인(0~15)을 통제하고 쓰지 않는 라인은 명시적으로 비활성하는 것이 출발점입니다.
• 취약 판정: 장비가 제공하는 전체 VTY 라인(예: 0~15)이 모두 접속을 받도록 열려 있어, 정책상 필요한 수준으로 동시 세션 상한을 축소하지 않은 상태. 즉 관리 접속이 장비 최대치(예: 16개 세션)까지 허용됩니다.
• 설정(Cisco IOS):

! 사용 라인(0~4): SSH + ACL + 타임아웃
line vty 0 4
transport input ssh
access-class 10 in
exec-timeout 5 0

! 미사용 라인(5~15): 모든 프로토콜 차단
line vty 5 15
transport input none

• 증빙: show running-config | section line vty에서 515가 transport input none임을 확인합니다. 이렇게 하면 인바운드 VTY 접속이 라인 0~4의 5개로 제한됩니다(515는 transport input none으로 어떤 프로토콜도 안 받음). 이것이 “동시 접속 제한”의 실제 구현입니다. 무차별 대입 완화(login block-for)는 동시 접속 제한과 다른 축이며, 3-1-④에서 다룹니다.

3-2-⑤ 보조 포트(AUX)

• 문제: AUX 포트는 출하 시 활성화돼 있는 경우가 많고, 모뎀·원격 콘솔로 다시 살아나기도 합니다. 평문 세션이라 노출 위험이 매우 높습니다.
• 취약 판정: line aux 0에 exec 활성, transport input이 기본값.
• 설정(Cisco IOS):

line aux 0
no exec
transport input none
no password

• 증빙: show running-config | section line aux에 no exec와 transport input none이 보입니다. 물리 포트 자체에 비활성화 스티커를 붙이는 것이 보조 증거입니다.

3-2-⑥ 로그온 경고 배너

• 문제: 배너가 없으면 법적 추적이 어렵고(미인가 접근이 “시스템 점검 중”으로 둔갑), 시스템 정보(버전·기관명)가 노출되면 공격자에게 사전 정찰 자료를 줍니다.
• 취약 판정: banner login 부재, 배너에 버전·기관명 표기, “Welcome” 표기(법적 이슈).
• 설정(Cisco IOS):

! 로그인 전 배너 (모뎀·콘솔 접속 시점에 표시)
banner login ^C
Authorized access only. All activities are monitored and recorded.
Disconnection is recommended if you are not an authorized user.
^C

! 로그인 후(motd)는 미사용 — 로그인 시점에 이미 인증이 끝난 상태이므로 추적 가치 낮음
no banner motd

• 증빙: show running-config | include banner에 banner login만 보이고 버전·기관명이 없습니다. “Welcome” 사용 금지는 법무 검토에서 자주 지적되는 사안입니다.

§3-2 실무 포인트

관리망 + 점프호스트(PAM) 구조가 정답입니다 — VTY ACL에 점프호스트 IP만 허용하면 모든 접속이 세션 녹화되어 결함 #4·#5가 동시에 해결됩니다. SSH 설정 시 흔한 누락은 호스트키 길이(2048 이상)·구형 알고리즘 비활성·ip ssh time-out입니다. 배너에 “Welcome”을 쓰면 안 되는 이유(법적 이슈 포함)를 짚습니다.

§3-3. 패치 관리

3-3-① 취약 판정

• 문제: 최신 보안패치·벤더 권고 미적용, EoS/EoL(End of Support/End of Life) 장비 운영은 결함 #10의 정체입니다. 패치는 단순히 “적용”이 아니라 판단 → 적용 → 미적용 근거 → 재점검의 사이클로 운영해야 합니다.
• 취약 판정 기준:
  • 자산목록에 모델·OS 버전·EoS 일자 컬럼 부재
  • 벤더 보안권고(PSIRT) 미구독
  • 패치 미적용 시 위험수용 근거 미문서화
  • EoL 장비가 운영 환경에 잔존

3-3-② 실무 프로세스 (4단계)

1. 자산 등록: 모델·OS 버전·EoS 일자 컬럼이 포함된 자산목록(cMDB 등)에 신규 장비를 등록합니다. 미등록 장비는 점검 대상에서 누락됩니다(결함 #13과 같은 형태).
2. 권고 수집: 벤더 보안권고(PSIRT)를 담당자 지정 후 구독 채널(메일·RSS·포털)에서 수집합니다. 영향도 판정은 CVSS 점수 + 노출 자산의 업무 영향을 곱합니다.
3. 적용 결정: 영향도 판정 → 적용 여부 결정 → 미적용 시 위험수용 근거 문서화(이게 없어서 결함). 미적용 자체가 위법은 아니지만, 근거 없는 미적용은 결함입니다.
4. 적용·검증: 테스트 환경에서 사전 검증 → 변경관리 승인 → 적용 → 검증 → 롤백 계획 수립 및 훈련. 검증 단계에서 미적용이 의심스러우면 즉시 롤백할 수 있어야 합니다.

3-3-③ 최대 애로와 대응

• 서비스 중단: 패치 적용 시 가장 큰 저항은 운영 중단 우려입니다. 대응은 ①이중화 순차 업그레이드(페일오버 후 한 쪽씩) ②정기 점검창구(Maintenance Window) 사전 공지 ③소규모 반복 적용(전체 한 번이 아니라 10%씩)입니다.
• EoL 장비의 딜레마: EoL이면 벤더 패치가 나오지 않습니다. 교체 계획을 위험수용 문서와 함께 제시하고, 그 기간을 1년 단위로 검토합니다. 임의 연장 금지.
• 권고 과부하: 매주 수십 건의 권고가 쏟아지면 전부 적용은 불가능합니다. 우선순위 기준(CVSS·노출 자산·업무 영향)을 정책 문서에 못 박습니다.

3-3-④ 증빙 데모

show version 출력에서 버전 확인 → 벤더 권고 목록과 대조하는 것이 표준 데모입니다.

! Cisco IOS 버전 확인
show version

! 예: Cisco IOS Software, C2900 Software (C2900-UNIVERSALK9-M), Version 15.7(3)M5
!     ↑ 이 버전이 벤더 권고 목록의 어느 CVE에 노출되는지 대조

! 설치된 feature/license 확인 (권고 대상 모듈 매칭용)
show running-config | include feature
show license feature

증빙은 (현재 버전 + 영향 권고 ID + 적용/미적용 결정 + 적용일자 + 검증 결과)의 다섯 가지가 한 세트로 묶입니다. 이 세트가 없으면 “적용했다”는 한 줄 주장이 됩니다.

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

P1에서 본 결함 14건 중 이 페이지가 닫는 6건은 다음과 같습니다. 각 행은 P1의 결함 표에서 발췌한 것이며, 자세한 결함 맥락은 P1 페이지에서 확인합니다.

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

정리 — 이 모듈의 한 줄

“장비 보안의 90%는 ‘누가, 어떻게, 얼마나 안전하게’ 접속하느냐의 운영 절차에서 결정됩니다.” — 이 한 줄이 P4의 결론이며, P5(로그·기능·이동통신)에서 그 운영의 흔적을 어떻게 남기는지를 다시 봅니다.