데이터센터 스위치가 '같다'고 착각할 때 생기는 일 — Arista EOS CVE-2026-7473

이미지 출처: 재시도

대형 데이터센터 백본에서 트래픽을 분류하고 걸러내는 핵심 장비 중 하나가 Arista의 스위치, 그리고 그 위에서 도는 EOS(Extensible Operating System)임. 그런데 이 EOS에서 "두 값이 같은지 비교하는 과정"이 일부 요소를 빠뜨린 채 판단을 내려버리는 문제가 보고됨. 식별자는 CVE-2026-7473이고, 분류상 Incomplete Comparison with Missing Factors(불완전한 비교, CWE-1023 계열)에 해당함.

핵심 요약

• Arista EOS가 어떤 값을 검증할 때 비교에 필요한 일부 요소를 누락해, 본래 막아야 할 트래픽·요청을 통과시킬 수 있는 취약점임.
• 핵심 위험은 권한·필터·접근제어가 의도와 다르게 동작하는 "조용한 우회"이며, 시스템이 멈추지 않으니 눈치채기 어려움.
• 방어자는 벤더 권고 펌웨어로 올리는 것과 더불어, 비교 우회의 흔적을 로그·플로우 단에서 탐지하는 보강을 병행해야 함.

'불완전한 비교'가 대체 뭐길래

코드에서 무언가를 허용할지 말지 결정할 때는 보통 "이 값이 정해진 기준과 일치하는가?"를 따짐. 문제는 비교라는 게 보기보다 까다롭다는 점임. 예를 들어 어떤 식별자를 검사할 때 길이·접두어·소속·상태 같은 여러 요소를 모두 봐야 정확한데, 그중 한두 가지를 빠뜨리면 실제로는 다른 값인데도 "같다"고 통과시키는 상황이 생김. CWE-1023이 말하는 게 정확히 이거임. 모든 결정 요소를 보지 않고 일부만으로 동등하다고 판정해버리는 결함.

네트워크 OS 맥락에서 이게 왜 무서운가 하면, EOS는 ACL·라우팅 정책·세션 검증처럼 "통과/차단"을 끊임없이 판단하는 장비이기 때문임. 비교 한 군데가 헐거우면 막아야 할 패킷이 흘러 들어가거나, 검증을 통과하면 안 되는 요청이 받아들여질 수 있음. 공격자가 시스템을 부수는 게 아니라, 장비 스스로 "괜찮다"고 판단하게 만드는 형태라 더 까다로운 것임.

공격 재현 말고, 위협 모델로 보기

실행 가능한 페이로드를 만드는 건 이 글의 관심사가 아님. 대신 개념 수준에서 위협을 그려보면 이해가 빠름. 공격자는 정상적으로는 거부될 값을, 비교가 놓치는 '빠진 요소' 쪽으로 살짝 비틀어 만들어 봄. 검증 로직이 그 빠진 부분을 안 보니까, 겉보기엔 합법적인 값으로 통과함. 결과적으로 접근제어 우회·필터 회피 같은 형태로 나타날 가능성이 큼.

여기서 방어자가 기억할 포인트는 하나임. 이런 류의 결함은 크래시도, 경보도 안 울림. 장비는 평소처럼 멀쩡히 돌아가고, 단지 한 번씩 "통과시키면 안 될 것"을 통과시킬 뿐임. 그래서 가용성 지표만 보고 있으면 영영 모르고 지나갈 수 있음.

탐지와 완화는 이렇게

• 벤더 권고 버전으로 패치: 가장 먼저 할 일. Arista 보안 권고에서 영향받는 EOS 트레인과 수정 버전을 확인하고, 데이터센터 변경관리 절차에 맞춰 올리는 게 정공법임. 정확한 버전 범위는 벤더 공지를 기준으로 삼는 걸 추천함.
• 관리 평면 노출 최소화: 비교 우회를 노릴 만한 진입 표면을 줄이는 게 핵심임. 관리 인터페이스·API를 별도 관리망으로 분리하고, 신뢰된 출발지에서만 접근하도록 제한해두면 즉시 패치가 어려운 동안의 완충이 됨.
• 정책 효과를 직접 검증: "ACL이 설정돼 있다"가 아니라 "ACL이 실제로 막는다"를 주기적으로 확인해야 함. 차단되어야 할 트래픽을 통제된 환경에서 흘려보내 정말 떨어지는지 점검하는 합성 테스트를 운영 루틴에 넣어두면 우회를 조기에 잡을 수 있음.
• 플로우·로그 기반 이상 탐지: 평소 거부되던 경로로 흐르는 트래픽, 정책상 도달 불가능해야 할 세그먼트 간 통신을 NetFlow/sFlow나 시스로그로 모아 베이스라인과 비교함. "있어선 안 될 통신이 생겼다"가 가장 믿을 만한 신호임.
• 구성 무결성 모니터링: 장비 설정이 의도대로 유지되는지 형상관리로 추적하고, 변경 이력을 사람이 검토하는 절차를 둠. 우회가 설정 변조와 함께 오는 경우를 잡기 위함임.

마무리하며

이번 건은 화려한 원격 코드 실행도, 장비를 멈추는 자원 고갈도 아님. "비교 한 줄이 요소 하나를 놓쳤다"는, 어찌 보면 사소해 보이는 결함임. 그런데 그 사소함이 통과/차단을 매초 판단하는 백본 장비에서 일어났을 때의 무게는 결코 가볍지 않음. 개인적으로는 이런 '조용한 우회'형 취약점일수록, 패치 하나로 끝났다고 안심하기보다 "내 정책이 진짜로 막고 있나"를 검증하는 습관을 들이는 게 오래 가는 방어라고 생각함. 여러분의 네트워크에선 차단 규칙이 실제로 동작하는지, 오늘 한 번 확인해보는 건 어떨까요. 점검하다 막히는 부분 있으면 댓글로 같이 풀어봐요.