네트워크에 대한 보안 인식이 점점 커지고 있습니다.
기존의 네트워크 보안이라고 한다면, IP주소 기반의 방화벽을 구성하는 것이 대부분이었습니다.
하지만 이제 많은 애플리케이션과 시스템들이 네트워크에 연결되고 있는 만큼 네트워크 스위치의 보안도 중요해지고 있습니다.
점점 네트워크가 복잡해지고 서로 연결되고 있는 만큼 각 스위치의 보안 설정에 대한 관심이 높아지고 있습니다.
Aruba CX(AOS-CX) 스위치 운영체제는 물리적 보안을 포함하여 Control Plane / Management Plane에 대한 보안 가이드를 제시합니다.
물리 보안
물리적 보안이라 함은 누군가 실제 스위치 장비에 물리적 접근을 했을 때 함부로 건들 수 없도록 하는 보안적 장치입니다.
스위치의 전면부에는 많은 포트와 버튼들이 있습니다. 이것을 함부로 건드리면 네트워크에 큰 장애나 이슈를 발생시킬 수 있습니다.
따라서 허가되지 않은 사용자가 접근하지 못하도록 스위치의 물리적 보안 기능을 활성화 하는 것이 좋습니다.

USB 저장소 및 블루투스 어댑터 연결 포트
사용하지 않는다면 포트를 비활성화 하는 것이 좋습니다.
블루투스를 통해 스위치에 접근할 때는 보안 인증 기능(SSH 등)을 활성화하여 함부로 접근하지 못하도록 합니다.
switch(config)# no usb
Reset 버튼 (Soft/Hard/Factory Reset)
Factory reset 기능이 필요할 경우 활성화하여 사용합니다.
switch(config)# front-panel-security factory-reset
This command will enable front-panel factory reset capability, where user can trigger factory-reset via reset button. This feature will remain enabled until it is disabled, or a factory-reset is performed.
Continue (y/n)?
Console 포트 (RJ-45 및 USB-C 포트)
Local 인증 또는 RADIUS, TACACS+ 등을 사용하여 AAA 기능을 활성화여 접근할 수 있도록 합니다.
switch(config)# aaa authentication login console <local/radius/tacacs>
switch(config)# aaa authorization commands console <local/tacacs>
switch(config)# aaa accounting all-mgmt console start-stop
Management Plane 보안
스위치 보안 운영 모드
AOS-CX 스위치는 두 가지 운영 모드를 지원합니다.
일반적인 상황에서 사용하는 Standard Mode와 OS의 보안이 강화된 Enhanced Secure Mode가 있습니다.
switch(config)# secure-mode <standard/enhanced>
switch(config)# secure-mode enhanced
This will set the switch into enhanced secure mode. Before enhanced secure mode is enabled, the switch must securely erase all customer data and reset to factory defaults. This will initiate a reboot and render the switch unavailable until the zeroization is complete.
Continue (y/n)?
Standard Mode에서는 별다른 제약이 없습니다만 Enhanced Secure Mode에서는 다음과 같은 제약사항이 존재합니다.
- Shell Mode 접근 불가
- Service OS의 다음 명령어 사용 제약
- Config-clear: startup-config 삭제 불가
- Password: 관리자(admin) 계정 패스워드 설정
- Sh: support shell 모드 실행
- Update: 펌웨어 이미지 업데이트
해당 모드는 이렇게 운영 OS의 민감한 부분의 접근을 제한할 수 있기 때문에 금융이나 국방, 정부 기관에서 사용을 권고합니다.
로컬 유저 그룹 및 역할 기반 접근 제어(RBAC)
AOS-CX 운영체제는 사용자(계정)를 역할에 맞게 구분하여 관리합니다.
즉 역할에 기반하여 사용할 수 있는 명령어나 접근할 수 있는 방법을 제한할 수 있습니다.
이러한 역할 기반 접근제어는 각 사용자별로 설정하지 않고 사용자 그룹(User Group)을 만들어서 설정합니다.
AOS-CX에서는 3가지 사용자 그룹을 기본적으로 제공합니다.
- Administrators: CLI와 REST API 접근에 대해 제한 없음
- Operators: 비보안정보에 대해서만 표시하도록 CLI와 REST API로 접속 제한. Web UI에서 보안 페이지는 접근 불가
- Auditors: CLI, REST API, Web UI 모두 감사 권한에 관련된 내용만 접근 (System → Log)
각 사용자별로 Priviliege Level과 역할(Role) 이름은 아래 표와 같습니다.
RBAC | Administrators | Operators | Auditors | |
RADIUS | Aruba-Admin-Role | Administrators | Operators | Auditors |
Aruba-Priv-Admin-User | 15 | 1 | 19 | |
Service-type | Administrative-User | NAS-Prompt-User | – | |
TACACS | Aruba-Admin-Role | Administrators | Operators | Auditors |
Priv-lvl | 15 | 1 | 19 |
이 세 가지 사용자 그룹 외에도 추가적으로 사용자 그룹을 생성할 수 있습니다.
최대 29개의 사용자 그룹을 추가할 수 있으며, 각 그룹당 1024개의 CLI 규칙을 정의할 수 있습니다.
switch(config)# user-group ex1
switch(config-usr-grp-ex1)# 10 deny cli command "show aaa .*"
switch(config-usr-grp-ex1)# 20 permit cli command "show .*"
switch(config-usr-grp-ex1)# exit
그룹에 정의할 수 있는 각 규칙들은 방화벽 정책과 동일하게 넘버링 순서대로 적용받습니다.
위 명령어 예시를 보면, show aaa로 시작하는 명령어는 사용할 수 없지만 그 외의 show 명령어는 사용할 수 있음을 의미합니다.
패스워드 제어(Password Control)
패스워드 인증을 설정함으로써 ServiceOS의 보안을 강화할 수 있습니다.
이 설정을 적용하면 admin 사용자로 ServiceOS Shell에 로그인할 때 CLI 또는 Web UI의 admin 비밀번호와 동일하게 입력해야 합니다.
switch(config)# system serviceos password-prompt
그리고 로컬 유저의 패스워드 보안 강화를 위해서..
- 기본적으로 로컬 유저의 패스워드는 Ciphertext로 표시됩니다.
- 패스워드는 SHA-512로 salt를 사용하여 해시되어 있습니다.
그리고 Config 파일에는 AES-256-GCM으로 암호화되어 저장되어 있습니다. - 기본으로 제공되거나 사용자가 지정한 export key를 사용하여 다른 스위치로 패스워드를 옮길 수 있습니다.
- 권장사항 – 기본으로 제공되는 Key가 아닌 새로 지정한 Key로 스위치간 패스워드를 교환할 것
switch(config)# service export-password
Enter password: ********
Confirm password: ********
switch(config)# show service export-password
Export password: custom
패스워드 복잡성 규칙
패스워드 복잡성을 설정하는 기능은 로컬 사용자의 패스워드를 설정할 때 복잡성을 적용하도록 강제하는 기능입니다.
해당 기능을 활성화하면 새로운 사용자를 만들거나 패스워드를 변경할 때 설정한 규칙들을 적용받습니다.
신규 사용자를 생성하거나 패스워드를 변경할 때 “ciphertext-password” 명령어를 사용할 수 없습니다.
ciphertext 패스워드는 패스워드 복잡성 확인할 수 없기 때문입니다.
복잡성 규칙을 만들 수 있는 옵션은 다음과 같습니다.
Switch(config)# password complexity
Switch(config-pwd-cplx)# ?
adjacent-char-type-count Configure the maximum number of adjacent characters
from a character set allowed
disable Disable password complexity enforcement
enable Enable password complexity enforcement
history-count Configure the number of previous passwords checked
to prevent reuse
lowercase-count Configure the minimum lowercase character count
minimum-length Configure the minimum password length
numeric-count Configure the minimum numeric character count
position-changes Configure the minimum number of positions that must
differ in the new password
special-char-count Configure the minimum special character count
uppercase-count Configure the minimum uppercase character count
각 옵션의 기본값과 설정 가능한 값은 아래 표와 같습니다.
규칙명 | 기본값(Default) | 설정 가능 범위 |
---|---|---|
Minimul Length (최소 길이) | 8 | 1 ~ 64 |
Position Changes (이전 패스워드와 달라야 하는 문자 수) | 8 | 1 ~ 64 |
Password History (이전 패스워드 기억) | 5 | 1 ~ 5 |
Minimum Numeric Character (최소 숫자 개수) | 1 | 0 ~ 64 |
Minimum Lowercase Character (최소 소문자 개수) | 1 | 0 ~ 64 |
Minimum Uppercase Character (최소 대문자 개수) | 1 | 0 ~ 64 |
Minimum Special Character (최소 특수문자 개수) | 1 | 0 ~ 64 |
Minimum Adjacent Character (최소 근접할 수 있는 동일 유형 문자 개수) | 0 | 0 ~ 63 |
Admin 패스워드 리셋
만약 스위치 admin 패스워드를 생각이 나지 않거나 잊어 버렸을 경우에 패스워드 초기화를 해야 할 수 있습니다.
이럴 때는 스위치에 물리적으로 접근하여 콘솔 케이블을 연결한 후에 스위치를 재부팅합니다.
스위치가 재부팅될 때 Service OS 콘솔모드로 부팅하도록 선택합니다.
Boot Profiles:
0. Service OS Console
1. Primary Software Image [FL.10.13.0001BH]
2. Secondary Software Image [FL.10.13.0005C]
만약 Service OS 접근시에 패스워드를 입력하도록 설정하지 않았다면 패스워드를 리셋할 수 있습니다.
SVOS> password
Enter password: ********
Confirm password: ********
Service OS 패스워드를 설정하여 로그인할 수 없다면, zeroize 명령어를 통해 스위치 초기화를 수행해야 합니다.
ServiceOS login: zeroize
This will securely erase all customer data, including passwords, and reset the switch to factory defaults. This action requires proof of physical access via a USB drive.
* Create a FAT32 formatted USB drive
* Create a file in the root directory of the USB drive named zeroize.txt
* Type the following serial number into the zeroize.txt file: xxxxxxxxxx
* Insert the USB drive into the target module
* Confirm the following prompt to continue Continue (y/n)?
AAA 설정
네트워크에서 AAA라 하면 Authentication(인증), Authorization(인가), Accounting(계정관리)를 말합니다.
즉, 사용자나 시스템이 네트워크를 통해 접속할 때 안전한 연결을 보장하기 위한 기법이라고 말할 수 있습니다.
AOS-CX 운영체제에서는 관리용 인터페이스를 통해 SSH나 Telnet, Web UI 등 원격 접속이나 콘솔 접속시 AAA 보안을 지원합니다.
사용자 계정 관리 | 로컬 인증 | TACACS+ | RADIUS |
---|---|---|---|
Authentication | Yes | Yes | Yes |
Authorization | Yes, RBAC | Yes, 명령어별 제어 및 RBAC | No |
Accounting | Yes | Yes | Yes |
접속한 사용자별로 관리용 인터페이스에 접근제어를 실시하기 위해서는 아래 내용을 참조해야 합니다.
- 기본적으로 스위치 사용자는 사용 가능한 모든 관리 인터페이스를 통해 스위치에 접근할 수 있습니다.
- 추가적으로 세분화하여 명령어에 대한 제어를 하기 위해서는 RBAC(역할 기반 접근제어)를 통해 적용할 수 있습니다.
- RBAC 적용시, CLI만 가능하며 Web-UI나 REST API 요청에 대한 제어는 불가합니다.
- 사용자 유형별로 사용자에게 특정 관리 인터페이스를 제공하는 권장 방법을 아래와 같습니다.
[로컬 모드]
switch(config)# no user admin1 management-interface ssh
switch(config)# show user-list management-interface
USER ENABLED MANAGEMENT INTERFACE(S)
------------------------------------------------------------
admin ssh,telnet,https-sever,console
admin1 telnet,https-server,console
[원격 RADIUS 또는 TACACS+]
Aruba-User-Mgmt-Interface = "ssh,telnet,https-server,console"
HPE에서는 각 역할에 따라 AAA를 활용하여 접근제어를 적용하는 가이드라인을 제시하고 있습니다.
위에서 언급했듯이 RBAC과 명령어별 권한 부여하는 것은 CLI와 Web UI 접속에 대해서만 적용할 수 있습니다.
따라서 이러한 허점을 이용하여 관리자는 REST API를 통해 인가되지 않은 작업을 수행할 수도 있습니다.
비인가 작업 및 접근을 차단하기 위해서, 자동화 관리자(Automtaion Admin)에 대해서만 REST API를 접속하도록 권장합니다.
- Network Admin: 네트워크 구성 작업을 허용
Aruba-Admin-Role = “network_admin”
Aruba-User-Mgmt-Interface = "ssh,telnet,console"
- Security Admin: 보안 구성 작업을 허용
Aruba-Admin-Role = “security_admin”
Aruba-User-Mgmt-Interface = "ssh,telnet,console"
- Automation Admin: REST API를 통해 자동화 작업 수행
Aruba-Admin-Role = “automation_admin”
Aruba-User-Mgmt-Interface = “https-server"
SSH 접근 보안
SSH로 접속시 보안을 강화하기 위해 Cipher나 MAC, 알고리즘에 대한 설정을 하도록 권장하고 있습니다.
switch(config)# ssh ciphers aes128-ctr, aes256-ctr, aes128-cbc, aes256-cbc
switch(config)# ssh macs hmac-sha2-256, hmac-sha2-512, hmac-sha1
switch(config)# ssh key-exchange-algorithms ecdh-sha2-nistp256, ecdh-sha2-nistp384, diffie-hellman-group14-sha1
switch(config)# ssh host-key-algorithms ecdsa-sha2-nistp256, ecdsa-sha2-nistp384,ecdsa-sha2-nistp521
switch(config)# ssh public-key-algorithms ecdsa-sha2-nistp256, ecdsa-sha2-nistp384, ecdsa-sha2-nistp521
그리고 SSH로 접속시에 인증키를 제한하여 특정 클라이언트에 대해서만 SSH 접속을 허용하도록 설정할 수 있습니다.
클라이언트 공개키를 추가하는 명령어는 다음과 같습니다.
Switch(config)# user admin authorized-key ecdsa-sha2-nistp256 E2VjZH...QUiCAk=root@switch
그리고 접속하는 클라이언트의 IP주소를 제한하는 방법도 보안을 추가하는 방법 중에 하나입니다.
switch(config)# ssh server allow-list
switch(config-ssh-al)# ip 10.10.0.0/16
switch(config-ssh-al)# ipv6 fd10::0/64
switch(config-ssh-al)# enable
Active SSH sessions will be terminated.
Do you want to continue (y/n)? y
switch(config-ssh-al)# exit
만약, SSH의 접속 포트를 기본 TCP 22에서 다른 포트로 변경하고 싶다면 아래 명령어를 사용합니다.
switch(config)# ssh server port 19222
다중 인증 (Two-factor Authentication)
ID와 패스워드만으로 인증하여 접속하는 것은 계정 분실이나 탈취 등으로 외부인이 접속할 수 있는 가능성이 있습니다.
이를 방지하기 위해서는 추가적인 인증 장치를 구성하여 비 인가자가 접속하는 것을 막을 수 있도록 보완할 수 있습니다.
로컬 사용자에 대한 사용 가능한 이중 인증(Two-factor authentication) 기법은 다음과 같습니다.
- 인증서 (로컬 인증)
- 인증서 내 사용자명 (로컬 인증)
- 사용자명 및 패스워드 (로컬 또는 원격 AAA 서버)
- 인가 (로컬 또는 원격 AAA 서버)
원격 사용자의 경우 사용 가능한 이중 인증 기법은 다음과 같습니다.
- 인증서 (로컬 인증)
- 인증서 내 사용자명 (RADIUS Authorized-Only 요청)
- 인가 (RADIUS)
- RadSec Only
기법 | Local Only | Local + Remote | Remote Only |
---|---|---|---|
관리 인터페이스 지원 | SSH | SSH | SSH & HTTPS |
X.509 인증서 인증 | 스위치에서 로컬로 구성된 TA 프로필을 사용하여 검증됨 | 스위치에서 로컬로 구성된 TA 프로필을 사용하여 검증됨 | 스위치에서 로컬로 구성된 TA 프로필을 사용하여 검증됨 |
인증서의 일반 이름 또는 주체 대체 이름에 있는 사용자 이름 유효성 검사 – 사용자 주체 이름 | 로컬 사용자 | 로컬 사용자 | 원격 RadSec 인가 요청 |
사용자 이름 및 패스워드 유효성 검사 | 로컬 사용자 | 원격 서버 | 유효성 검사 없음 |
인가 | 로컬 사용자 | 원격 서버 | 원격 서버 |
세션 관리
세션 관리란 콘솔 접속이나 SSH, Telnet 연결시 CLI 사용자 세션에 대한 별도의 설정을 적용하여 보안을 강화하는 것을 말합니다.
switch(config)# cli-session
switch(config-cli-session)# max-per-user 1
switch(config-cli-session)# timeout 10
switch(config-cli-session)# tracking-range 25
위 config는 보안을 위해 권고하는 구성입니다.
- 사용자별 CLI 세션 1개만 허용
- 네트워크 타임아웃의 시간은 5~10분 이내
그리고 스위치에 정상적으로 로그인하게 되면 아래와 같이 여러 정보를 알려줍니다.
이를 통해 가장 최근에 어떤 사용자가 언제, 어떻게(어디서) 접속했는지 알 수 있습니다.
Last login: 2025-04-23 08:06:57 from 16.242.163.65
User "admin" has logged in 36 times in the past 30 days
switch#
SNMP 액세스 보안
SNMP(Simple Network Management Protocol)은 대규모의 네트워크 환경에서 쉽게 관리하기 위한 방법 중 하나입니다.
네트워크 장비의 주요 성능과 기능을 모니터링하고 장애 발생시 관리자에게 알리거나 특정 부분을 설정할 수 있는 프로토콜입니다.
따라서, SNMP는 원격에서 여러 네트워크 장비들을 모니터링하기 위해 필요하지만 그만큼 보안 설정도 중요합니다.
SNMP 구성시에 권고하는 보안 설정은 아래와 같습니다.
- SNMP Community 값을 default 값으로 설정하지 않습니다.
Switch(config)# snmp-server community zerotrust
- 적절한 접근 권한과 접근 목록을 지정합니다.
switch(config-community)# access-level rw
switch(config-community)# access-list snmp_acl
- 보다 강력한 보안을 설정하기 위해서는 SNMPv1과 SNMPv2는 비활성화하여 SNMPv3만 사용합니다.
switch(config)# snmp-server snmpv3-only
- 안전한 인증 프로토콜(SHA224 이상)과 프라이버시 프로토콜을 사용합니다.
switch(config)# snmpv3 user myUser auth sha256 auth-pass plaintext myAuthPswrd priv aes256 priv-pass plaintext myPrivPswrd access-level ro
시간 동기화
많은 보안 프로토콜과 감사 기능은 시스템 시간에 의존합니다.
그리고 이 시간은 관리 네트워크 또는 신뢰할 수 있는 외부 시간 소스와 동기화합니다.
이를 위해 가장 일반적으로 사용되는 프로토콜 중 하나는 NTP(네트워크 시간 프로토콜)입니다.
따라서 보안 관리 프로토콜을 설정하기 전에 디바이스에서 NTP를 구성하고 사용하도록 설정해야 합니다.
여러 시간대에 걸쳐 있는 조직에서는 일반적으로 NTP를 사용하여 시간 시계를 동기화하고 각 장비의 현지 시간대를 UTC로 설정하는 것이 일반적입니다. 이러한 방식은 대륙에 떨어져 있을 수 있는 디바이스의 문제 해결 및 보안 감사에 도움이 됩니다.
switch(config)# ntp authentication
switch(config)# ntp authentication-key 1 md5 ntpauthkey
switch(config)# ntp server 10.100.1.254 prefer
switch(config)# ntp vrf mgmt
NTP 서버 구성에 대한 확인은 show ntp servers 명령어를 통해 확인할 수 있습니다.
switch# show ntp servers
------------------------------------------------
NTP SERVER KEYID MINPOLL MAXPOLL OPTION VER
------------------------------------------------
10.100.1.254 -- 6 10 none 4 prefer
10.80.2.219 -- 6 10 iburst 4 prefer(auto)
pool.ntp.org -- 4 4 iburst 4
------------------------------------------------
Control Plane 접근제어목록 (ACL)
Contol Plane은 장비의 관리와 라우팅 기능을 처리합니다.
그렇기 때문에 VRF 인터페이스에 IP주소가 바인딩되면, 스위치는 비인가 사용자나 장치로부터 접근될 수 있는 위험에 노출됩니다.
이러한 취약점을 막기 위해 해당 VRF(default/non-default/mgmt)의 Control Plane에 대해 ACL을 지정하는 것이 좋습니다.
특히나 NTP와 같은 ACL 정책을 적용할 수 없는 기능들에 설정하는 것을 권장합니다.
switch(config)# access-list ip CONTROLPLANE
switch(config-acl-ip)# 05 comment ALLOW SSH AND SNMP ON ADMIN SUBNET, BLOCK ALL OTHERS
switch(config-acl-ip)# 10 permit tcp 10.10.0.0/24 any eq 22
switch(config-acl-ip)# 20 permit udp 10.10.0.0/24 any eq 161
switch(config-acl-ip)# 30 permit udp 10.10.0.0/24 any eq 162
switch(config-acl-ip)# 40 deny tcp any any eq 22 log count
switch(config-acl-ip)# 50 deny udp any any eq 161 log count
switch(config-acl-ip)# 60 deny udp any any eq 162 log count
switch(config-acl-ip)# 990 comment ALLOW ANYTHING ELSE
switch(config-acl-ip)# 1000 permit any any any
switch(config)# apply access-list ip CONTROLPLANE control-plane vrf default
PKI 보안
관리자는 PKI (Public Key Infrastructure)기능을 통해 스위치의 디지털 서명을 관리할 수 있습니다.
스위치는 서버 역할을 하거나 TLS 암호화를 사용하여 서버와 통신할 때 인증서를 사용하여 클라이언트의 유효성을 검사합니다.
PKI를 사용하는 애플리케이션들을 아래와 같습니다.
- RadSec
- dot1x-supplicant
- EST Client
- Captive-portal
- syslog
- https-server
AOS-CX 스위치는 기본적으로 다음과 같은 사전 설치된 Leaf 인증서를 지원합니다.
- Local-cert: 자체 서명 부트 인증서 (Self-Signed boot Certificate) – 모든 애플리케이션에 대한 기본 인증서
- Device-Identity: 스위치 제조시 내장되어 802.1x, MACsec 또는 Aruba 클라우드 서비스 등에 사용
AOS-CX는 잠재적인 보안 위험을 피하기 위해 모든 애플리케이션에 대해 자체 서명 인증서 대신 신뢰할 수 있는 CA 서명 인증서를 사용할 것을 권장합니다. 인증서 등록 프로세스의 보안 및 무결성을 유지하기 위해 AOS-CX 스위치에서 지원되는 최소 TLS 버전은 TLS1.2입니다.
NDcPP당, TLS 연결을 설정하는 데 사용되는 피어 인증서는 피어 장치의 역할에 따라 확장 키 사용 필드가 클라이언트 인증 또는 서버 인증으로 설정되어 있어야 합니다.
switch(config)# tls check-key-usage
이렇게 AOS-CX 스위치의 보안을 강화하기 위한 가이드를 살펴보았습니다.
물리적 보안과 Management Plane의 보안 설정에 대한 내용에 대한 내용을 정리해보았습니다.
다음 포스팅에서는 Control Plane에 대한 보안 설정과 Supply Chain에 대한 내용을 다뤄보도록 하겠습니다.