15 KiB

Raw Blame History

3. 사용자·인증 서버·주소 필터·SNMP·SSL

S01. 사용자 계정과 포트 권한

관리자 운영 → 사용자 계정 → 사용자 추가. 시험 ID demo_operator, 역할 포트 운영자, 시험 비밀번호, 사용 상태와 CH01 권한을 설정해 저장합니다. CH02 권한은 주지 않습니다. 그룹을 사용한다면 그 그룹의 권한도 확인합니다.
사용자 표의 수정 / 비밀번호 / 삭제가 겹치지 않고 클릭되는지 확인합니다. 창 폭을 줄여도 작업 버튼을 사용할 수 있는지 확인합니다.
관리자 창을 유지하고 별도 비공개 창에서 새 계정으로 로그인합니다. 초기 비밀번호 변경 화면이 나오면 변경을 완료합니다.
CH01 접속·송수신은 허용되고 CH02는 거부되는지 확인합니다. 포트 운영자에게 로그 메뉴가 표시되지 않는지 확인합니다. 주소창으로 /logs/ports, /logs/system, /logs/links에 접근해도 로그 원문이 표시되지 않아야 합니다.
관리자로 돌아와 계정을 수정하고 재로그인해 변경된 권한을 확인합니다. 비밀번호에서 시험 암호를 바꾼 뒤 새 암호로 로그인합니다. 이전 암호 실패 시험은 한 번만 합니다.
시험 계정을 삭제하고 새 로그인이 불가능한지 확인합니다. 실제 사용 관리자 계정을 삭제하지 않습니다.

통과: UI 배치 정상 + 역할·채널 권한 적용 + 암호 변경·삭제 실제 반영. 실패: 이전 로그인 세션을 닫고 새 세션에서 확인, 그룹/개별 포트 권한 비교. 원복: 시험 계정·그룹 정리, 기존 계정은 변경 전 권한 복구.

본인 암호 시험: 좌측 비밀번호 변경에서 현재 비밀번호·새 비밀번호·확인을 입력해 저장하고 재로그인합니다. 확인값 불일치는 저장되지 않아야 합니다. 암호는 UI 정책을 충족하게 정하고 기록물에 쓰지 않습니다.

S02. RADIUS / TACACS

준비: 외부 서버에 장비를 클라이언트로 등록하고 장비의 실제 출발 IP·공유 Secret을 맞춥니다. 외부 전용 시험 사용자는 장비 로컬 사용자에 같은 ID로 만들지 않습니다. 로컬 인증 성공을 외부 인증 성공으로 오인하지 않기 위해서입니다.

UI: 관리자 운영 → 인증 서버	RADIUS 탭	TACACS 탭
사용	RADIUS 사용 켬	TACACS 사용 켬
서버 주소	실제 인증 서버 IP	실제 인증 서버 IP
인증 포트	서버와 동일. 기존 시험 환경은 `1645`; 서버가 1812면 1812	서버와 동일. 일반 시험값 `49`
공유 Secret	서버의 장비 클라이언트 항목과 동일	서버 설정과 동일
응답 타임아웃	`5`초 예시	`5`초 예시
외부 사용자 기본 역할	포트 운영자 등 시험할 역할	포트 운영자 등 시험할 역할

하나의 인증 방식부터 켜고 적용합니다. 사용하지 않는 방식의 기존 상태는 기록합니다.
서버 관리 화면 또는 서버 로그를 열고 시험 시작 시각을 기록합니다. 기존 Docker 시험 환경을 쓰는 경우 해당 RADIUS/TACACS 컨테이너의 Logs 탭을 열면 됩니다. 서버가 현재 실행 중인지는 별도로 확인합니다.
비공개 브라우저에서 외부 전용 사용자와 올바른 CAPTCHA로 로그인합니다.
장비 로그인 성공과 동시에 서버에서 해당 사용자·장비 출발 IP의 인증 성공 로그를 확인합니다. RADIUS는 Access-Accept, 거부 시험은 Access-Reject 등 서버가 출력하는 결과를 기록합니다.
새 세션에서 비밀번호만 한 번 틀려 로그인 거부와 서버의 거부 로그를 확인합니다. CAPTCHA 오류는 외부 인증 거부 시험으로 세지 않습니다.
시험 서버를 잠시 정지하거나 시험용 접근만 차단합니다. 외부 전용 계정이 성공하지 않는지, 준비해 둔 로컬 관리자로 관리 복구가 가능한지 확인합니다. 서버를 복구해 외부 로그인이 다시 되는지 확인합니다.
포트 인증도 필요하면 포트 설정 → 동작 설정 1 → 인증 방식 RADIUS/TACACS로 지정하고 Reverse SSH/Telnet 신규 세션에서 같은 시험을 반복합니다. 웹 로그인만으로 포트 인증까지 통과 처리하지 않습니다.

통과: 정상/거부/서버 복구가 서버 로그와 일치. 실패: 서버 무로그는 경로·방화벽·포트·등록 출발 IP, 거부 로그는 사용자·Secret·서버 정책부터 확인합니다. 원복: 원래 인증 방식·포트 인증 설정 복구 및 시험 서버 정상화. 현재 UI에는 ‘장애 시 인증’ 선택 항목이 없습니다. 화면에 없는 스위치를 조작하는 절차는 없습니다.

S03. 주소 필터 — PC를 구분해서 시험

client address is denied by management address filter는 사용자 암호가 틀렸다는 뜻이 아니라 접속 출발 주소가 필터에 거부됐다는 뜻입니다.

예: 관리 PC A가 192.168.0.100일 때 블랙리스트에 192.168.0.0/24를 넣으면 A도 포함됩니다. 192.168.0.101/32는 해당 PC 한 대입니다. 필터 주소에 장비 192.168.0.223을 넣어 PC 차단을 시험하지 않습니다.

IPv4 블랙리스트

A와 B 각각 ipconfig로 유선 IP를 확인하고, 두 PC 모두 현재 정상 로그인되는지 먼저 확인합니다.
A에서 관리자 운영 → 주소 필터 → IPv4를 엽니다. 전체 사용 여부·모드·기존 규칙을 기록합니다. 시험은 다른 규칙의 영향을 구분할 수 있는 상태에서 합니다.
블랙리스트 모드를 선택합니다. 규칙에 B의 실제 IPv4/32, 프로토콜 전체, 규칙 사용 켬을 설정합니다. 목적지 포트는 UI 고정값 0을 유지합니다.
규칙을 저장하고 주소 필터 전체 사용을 켜서 적용합니다. A를 포함한 /24 규칙이 활성화돼 있지 않은지 확인합니다.
B의 새 브라우저 세션에서 로그인합니다. 거부 문구 또는 해당 프로토콜 차단을 확인합니다. 동시에 A에서 페이지를 새로 열어 관리가 되는지 확인합니다.
해당 시험 규칙을 끄거나 제거하고 적용한 뒤 B에서 다시 로그인합니다.

통과: B만 거부, A 유지, 규칙 해제 후 B 복구. HTTP만 지정해 시험한다면 B의 HTTP와 HTTPS를 각각 새 연결로 비교합니다. HTTPS까지 막혔다면 다른 전체 규칙이 있는지 확인합니다.

IPv4 화이트리스트

블랙리스트 시험을 원복하고 모드를 화이트리스트로 준비합니다.
A의 실제 IPv4/32 허용 규칙을 먼저 저장합니다. 전체 프로토콜·사용 상태를 확인한 뒤 전체 필터를 활성화합니다.
A의 새 세션은 성공하고 목록에 없는 B는 거부되는지 확인합니다.
B의 /32도 허용 목록에 추가해 적용하고 B의 새 로그인 성공을 확인합니다.
시험 전 모드·규칙·전체 사용 여부로 복구합니다.

MAC 필터

동일 L2 망의 시험 PC B에서 ipconfig /all로 장비에 연결된 유선 어댑터의 물리적 주소를 확인합니다.
주소 필터의 MAC 탭에서 그 값을 UI 형식에 맞춰 등록합니다. 블랙리스트부터 시작해 B 거부/A 허용/규칙 해제 후 B 복구를 확인합니다.
화이트리스트는 A MAC 허용을 먼저 등록한 뒤 동일하게 시험합니다.

제한: 라우터를 경유하면 장비가 보는 MAC이 원격 PC MAC과 다를 수 있습니다. 이 경우 PC의 MAC을 넣고 원격 차단을 보장할 수 없습니다. 같은 L2 시험망을 사용합니다.

이미 차단된 경우

암호를 반복 입력하지 않습니다. 다른 허용된 PC가 있으면 그 PC로 로그인해 문제 규칙을 끄고 적용합니다.
허용 PC가 없으면 시리얼 관리 콘솔에서 복구합니다. 이 프로젝트 배포의 설정 파일은 /var/lib/tera-api/auth.json입니다. 파일에는 인증 정보가 있으므로 내용을 화면에 공개하지 않습니다.
콘솔 작업자는 해당 파일을 별도 백업하고 API 서비스를 정지한 뒤 address_filters.enabled만 false로 변경, JSON 유효성 확인 후 기존 API 서비스를 재시작합니다. 실제 서비스 관리 방식은 장비 구성에서 확인해야 하며 확인하지 않은 서비스명을 실행하지 않습니다.
A에서 웹에 재접속해 문제 CIDR/MAC 규칙을 수정합니다. A 허용과 B 시험 계획을 다시 확인한 다음 필요한 필터 정책을 복구합니다. 복구를 위해 공장 초기화부터 할 필요는 없습니다.

기록: A/B의 실제 출발 IP·MAC, 규칙 화면, 각각의 허용/거부 화면. 현재 설정을 읽지 않고 과거 차단 규칙이 아직 남아 있다고 단정하지 않습니다.

S04. SNMP Agent 조회

SNMP 조회는 PC가 장비의 UDP 161로 요청하는 시험입니다. 장비가 PC UDP 162로 보내는 Trap은 알림 절차에서 별도로 시험합니다.

v2c

UI: 관리자 운영 → SNMP	입력 예시
SNMP 사용	켬
장비 위치(sysLocation)	`DEMO-RACK-A`
관리자 연락처(sysContact)	시험 담당자 연락처
SNMP v1 / v2c / v3	끔 / 켬 / 끔
Read Community	별도로 정한 시험 Community

적용 후 Net-SNMP가 설치된 PC에서 아래 명령을 실행합니다. 꺾쇠 자리는 실제 값으로 교체합니다. 도구가 없으면 SNMP 조회 프로그램에 Target IP, UDP 161, v2c, Community, 같은 OID를 입력하고 GET합니다.

snmpget -v2c -c "<Read Community>" 192.168.0.223 1.3.6.1.2.1.1.6.0
snmpget -v2c -c "<Read Community>" 192.168.0.223 1.3.6.1.2.1.1.3.0

첫 응답이 DEMO-RACK-A인지 확인합니다. 둘째 uptime을 잠시 후 다시 조회해 증가하는지 확인합니다.
UI에서 위치를 DEMO-RACK-B로 바꿔 적용하고 첫 명령을 반복해 변경된 실제 응답을 확인합니다.
틀린 Community로 조회하면 정상 데이터가 반환되지 않는지 확인합니다. SNMP 사용을 끄고 적용해 조회 불가, 다시 켜서 조회 복구도 확인합니다.

통과: UI 설정 변경과 실제 GET 응답 일치. 실패: UDP 161 경로·버전·Community·필터 확인. TCP 연결 검사만으로 SNMP를 판정하지 않습니다.

v3

SNMP v3와 v3 사용자 사용을 켭니다. 사용자 demo_snmp, 접근 권한 읽기, 인증 SHA-1, 암호화 AES, 각각의 키를 설정하고 적용합니다. 여기서는 도구 간 비교가 쉬운 시험 조합을 사용하며 운영 정책은 별도로 선택합니다.
PC 조회 도구에서 v3, 사용자, authPriv, SHA-1/AES와 동일 키를 지정합니다. Net-SNMP 예시는 다음과 같습니다.

snmpget -v3 -l authPriv -u demo_snmp -a SHA -A "<인증 키>" -x AES -X "<암호화 키>" 192.168.0.223 1.3.6.1.2.1.1.6.0

위치 응답을 확인하고, 잘못된 키로는 같은 데이터가 반환되지 않는지 비교합니다. v2c를 끄고 v2c 요청 불가/v3 요청 성공도 확인합니다.

쓰기 권한: ‘읽기/쓰기’ 선택만으로 모든 OID가 SET 가능한 것은 아닙니다. 이 배포는 sysLocation을 에이전트 설정 파일로 생성하므로 해당 OID SET 성공을 필수 합격 기준으로 잡지 않습니다. 쓰기 시험은 에이전트가 지원하는 쓰기 가능한 OID·원래 값이 확인된 경우 별도 실시합니다. 확인되지 않았다면 ‘쓰기 미실시’로 기록합니다.

원복: 원래 버전·사용자·키·위치·연락처·사용 상태 복구. 명령 기록과 캡처에서 키/Community를 가립니다.

S05. SSL 생성과 실제 HTTPS 인증서 확인

사용자가 만든 화면은 다음 입력 예시입니다. 생성 화면만으로 활성 인증서 교체까지 확인된 것은 아닙니다.

UI: 관리자 운영 → SSL 인증서 → 새로 만들기	값
인증서 ID	자동 표시 `device-192-168-0-223` 예시
공통 이름(CN)	`192.168.0.223`
국가(C)	`KR`
조직(O)	`TERA-TEST`
나머지 선택 항목	필요 없으면 비움

이미 생성했다면 중복 생성하지 말고 인증서 탭에서 해당 항목을 찾습니다. 없으면 위 값으로 생성합니다.
현재 활성 인증서를 기록합니다. 활성 인증서에서 만든 항목 선택 → 적용.
목록에서 선택한 인증서의 상태·유효 기간·키 보유 여부를 확인합니다.
새 브라우저 창으로 **https://192.168.0.223/**에 접속합니다. HTTP 페이지로 성공 판정하지 않습니다.
브라우저 주소창의 사이트 정보에서 인증서 보기를 열어 Subject의 CN, 조직, 발급자, 유효 기간, SAN의 접속 IP를 확인합니다. 생성한 값과 실제 제공 인증서가 같아야 합니다.
HTTPS로 로그인하고 메뉴 하나를 열어 정상 동작을 확인합니다. 이전 인증서가 보이면 기존 연결을 닫고 새 세션에서 다시 확인합니다.

통과: 실제 HTTPS가 제공한 인증서 내용과 생성값 일치 + HTTPS 로그인. 자체 서명이라 신뢰 경고가 생기는 것과 만료·주소 불일치는 구분합니다. 경고가 없는 시연을 원하면 해당 PC가 신뢰하는 CA가 발급하고 접속 주소가 SAN에 포함된 인증서를 사용해야 합니다.

실패: 장비 시간·접속 주소·활성 선택·개인키·443 연결 확인. 원복: 원래 인증서를 활성화해 HTTPS에서 다시 비교합니다. 원복 확인 전에 기존 인증서를 삭제하지 않습니다.

S06. SSL 가져오기 / CSR

가져오기: 서명된 PEM 인증서와 대응 개인키를 준비합니다. SSL 인증서 → 가져오기에서 인증서 파일, 개인 키 파일, 암호화된 키라면 키 비밀번호를 선택 → 가져오기. 키를 생략하려면 장비에 대응 키가 이미 있어야 합니다. 목록에 추가된 것과 실제 활성화를 구분하고 S05의 활성화·HTTPS 비교를 반복합니다. 다른 키 조합으로 시험한다면 적용이 거부되거나 활성화할 수 없는 상태인지 확인하고 기존 활성 인증서가 유지되는지 확인합니다.

CSR: CSR 내보내기에서 키가 있는 인증서를 선택하고 CN·조직·이메일을 확인한 뒤 내보냅니다. 내려받은 파일에 BEGIN CERTIFICATE REQUEST가 있는지 확인합니다. CA에 제출해 서명 인증서를 받은 뒤 가져오기·활성화·HTTPS 비교까지 해야 발급 적용 시험이 끝납니다. CSR 다운로드 자체는 CA 발급 완료가 아닙니다.

원복: 원래 활성 인증서로 복귀하고 시험용 인증서만 정리합니다. 개인키를 시연 자료나 저장소에 첨부하지 않습니다.

15 KiB Raw Blame History