클라우드 제공업체 식별: ASN, 가상화, 지연 핑거프린트 교차 감사

3중 핑거프린트 교차 검증으로 진짜 클라우드 제공업체를 식별합니다.

업데이트됨 2026-08-07 · CloudWorth

클라우드 제공업체 식별크로스 플랫폼 감사ASN가상화지연 핑거프린트CloudWorthSteal TimeVPS 오버셀링VPS 점검

ASN, 가상화, 지연 핑거프린트의 3중 검증으로 실제 클라우드 제공업체를 명확하게 식별합니다.

ASN 귀속으로 클라우드 업체 확인

클라우드 서버 한 대를 받으면, 가장 먼저 벤치마크부터 돌리지 마라. ASN 귀속을 먼저 확인하자 — 이건 크로스 플랫폼 감사에서 가장 '값싼' 수법이다. 명령어는 단 한 줄이다: whois $(curl -s ifconfig.me | grep -oE '([0-9]{1,3}\.){3}[0-9]{1,3}') 또는 그냥 curl ipinfo.io/asn을 실행하면 된다. 출력이 AS45102 Alibaba (US) Technology Co., Ltd.처럼 나오면, 업체가 즉시 드러난다.

하지만 함정도 적지 않다: 동일한 IP 대역이 여러 클라우드 업체에 의해 공유될 수 있다. 예를 들어 AWS와 CloudFront의 ASN이 겹칠 수 있고, CDN 노드는 종종 원본 서버의 옷을 입고 있다. 그러니 ASN 하나만 믿지 말고, 객체의 라우팅 데이터(예: BGP 프리픽스 히스토리)와 가상화 지문을 교차 검증해야 한다. ASN이 "Alibaba"로 표시되는데 가상화 계층이 KVM이고 지연 시간 곡선이 수상하다면, 주의를 기울여야 한다.

CloudWorth /app을 사용하면 ASN, 가상화 유형, steal time이라는 3계층 지문을 자동으로 수집할 수 있어, 수동으로 명령어를 조합할 필요가 없다. 다음 절에서는 가상화 식별에 대해 다루며, 바로 이어지는 내용이다.

가상화 유형 탐지

가상화 유형은 클라우드 서버에서 클라우드 공급자를 식별하는 두 번째 지문입니다. 동일한 IP 대역이 ASN을 공유할 수 있지만, 호스트 머신의 가상화 구현은 위장하기 어렵습니다. Linux에서는 먼저 systemd-detect-virt를 실행하는데, 이는 CPUID 및 DMI 정보를 읽습니다. KVM은 보통 kvm으로, Xen은 xen으로, OpenVZ는 openvz로 보고합니다. 그런 다음 lscpu로 Hypervisor vendor를 확인합니다. 일반적으로 클라우드 공급자는 실제 식별자를 노출합니다. 예를 들어 AWS의 Xen/KVM, 알리바바 클라우드와 텐센트 클라우드의 KVM 등입니다. 이상한 출력(예: Microsoft의 Hyper-V)이 나오면 Azure인지 아니면 셸 패널을 사용한 것인지 경계해야 합니다.

크로스 플랫폼 감사 시 Windows에서는 systeminfo로 BIOS 버전과 Model을 확인할 수 있습니다. macOS에서는 드물지만 sysctl -n machdep.cpu.features로 보조 판단이 가능합니다. 컨테이너화된 VPS는 docker 또는 lxc로 표시되며, 이러한 경우 오버세일 위험이 높으므로 Steal Time과 함께 추가 검증이 필요합니다. 이전에 크로스 플랫폼 감사 가이드를 작성한 적이 있으니 명령어를 함께 사용할 수 있습니다. 또한 CloudWorth 감지 도구에서 가상화 지문과 지연 시간 데이터를 교차 비교할 수도 있습니다.

ASN, 가상화, 지연 시간의 세 계층이 일치하면 클라우드 공급자는 사실상 숨을 수 없으며, '양의 머리를 걸고 개고기를 판매'하는 재판매 제품을 식별하기도 더 쉬워집니다.

지연 시간 핑거프린트 교차 검증

ASN과 가상화는 "누가 데이터 센터를 지었는지"를 알려주지만, 지연 시간 핑거프린트는 "이 머신이 지금 실제로 어떤 상태인지"를 알려줍니다. 클라우드 서버에서 클라우드 공급업체를 식별하는 교차 플랫폼 감사에서 저는 지연 시간을 물리 계층의 '거짓말 탐지기'로 보는 습관이 있습니다. 빛의 속도와 큐잉 효과는 속일 수 없기 때문에 위장하기 어렵습니다.

먼저 몇 가지 간단한 방법을 살펴보겠습니다:

• RTT 기저선 및 지터: 500회 연속 ping을 보내고 min/avg/max/mdev를 기록합니다. mdev가 장기간 5ms를 초과하면 이웃 또는 호스트 머신의 부하가 높다는 뜻입니다. avg가 같은 데이터 센터의 새 머신보다 현저히 높으면 과매출(oversubscription) 또는 경로 우회 가능성이 있습니다.
• TCP 핸드셰이크 지연 시간 vs ICMP 지연 시간: 일부 클라우드 공급업체는 ICMP를 별도로 속도 제한합니다. 이 경우 nc -vz host port 또는 curl -w를 사용하여 실제 핸드셰이크 지연 시간을 측정하세요. 둘 사이의 차이가 너무 크면 트래픽 셰이핑이 이루어지고 있다는 뜻입니다.
• Traceroute 마지막 홉: 끝에서 두 번째 홉이 공용 게이트웨이이고 마지막에 직접 사설 IP로 들어간다면 공유 호스트 머신일 가능성이 높습니다. 추가 홉이나 NAT 계층이 있다면 중계를 경계해야 합니다.

간단한 스크립트를 실행해 보겠습니다:

for i in {1..200}; do ping -c 1 -W 1 YOUR_IP | grep -o 'time=.*' ; sleep 0.2; done | awk -F'=' '{print $2}' | sort -n | awk '{a[NR]=$1} END {print "min="a[1], "max="a[NR], "med="a[int(NR/2)]}'

min/med/max를 추출하고 중앙값과 최대값의 차이가 지나치게 크지 않은지 확인합니다.

그런 다음 지연 시간 핑거프린트를 ASN 및 가상화 결과와 함께 교차 검증합니다. 예를 들어 ASN이 Tencent Cloud를 표시하고 가상화가 KVM이라면 네트워크가 깨끗해야 합니다. 그러나 ping 평균 지연 시간이 같은 리전의 다른 Tencent Cloud보다 30ms 높고 지터가 크다면 서둘러 주문하지 마세요. IP가 콜드 스탠바이 세그먼트에 속하거나 CDN에 직접 흡수되었을 가능성이 높습니다. 반대로 지연 시간이 매우 낮지만 ASN을 찾을 수 없다면 단지 엣지 액세스 계층일 수 있으므로 TCP 핑거프린트와 인증서를 추가로 확인해야 합니다.

최종적으로 ASN 소속, 가상화 유형, 지연 시간 특성의 세 가지 행으로 구성된 표를 만들어 세 가지가 서로 확인되어야만 "이 클라우드 공급업체가 진짜다"라고 안심할 수 있습니다.

크로스 플랫폼 감사 체크리스트

AWS, Azure, 알리바바 클라우드, 텐센트 클라우드 중 어디서 구매하든, 클라우드 서버에서 클라우드 제공업체를 식별하는 방법론은 동일합니다. 먼저 ASN 귀속을 확인하고, 다음으로 가상화 유형을 살펴본 다음, 마지막으로 지연 시간 핑거프린트로 교차 검증합니다. 아래의 크로스 플랫폼 감사 체크리스트는 제가 VPS를 구매하기 전에 반드시 실행하는 단계이며, 다른 사람의 '이 머신이 도대체 어느 회사 것인지'를 감정하는 데에도 적용됩니다.

1. ASN 및 라우팅 소속

먼저 whois 또는 온라인 도구로 IP의 ASN을 조회하고 조직 이름을 기록합니다. 주의: 클라우드 공급자가 ASN을 공유하는 것은 흔한 일입니다. 예를 들어 AWS와 일부 프록시가 AS 16509를 공유합니다. 따라서 ASN은 첫 번째 레이어일 뿐이며, 단정지을 수 없습니다. 또한 traceroute를 사용하여 마지막 홉이 CDN 엣지 노드가 아닌 클라우드 공급자의 백본 네트워크에 도달하는지 확인해야 합니다. 함정 방지 팁: IP 소속이 CDN 업체로 표시되지만 지연 시간이 매우 낮고 라우팅이 대상 데이터 센터로 직접 연결된다면, 대부분 CDN이 원본 서버에서 콘텐츠를 가져오는(오리진 풀) 경우이며, 원본 서버가 아닙니다.

2. 가상화 및 시스템 지문

서버에 로그인한 후 systemd-detect-virt 또는 dmidecode -s system-manufacturer를 사용하여 가상화 유형을 확인합니다. AWS는 주로 Xen/KVM이고, Azure는 Hyper-V이며, 阿里云와 腾讯云는 대부분 KVM입니다. 명령어는 배포판에 따라 차이가 있습니다. Debian/Ubuntu는 systemd-detect-virt를 권장하며, CentOS/RHEL에서는 virt-what을 설치해야 할 수 있습니다. 플랫폼 간 비교 시 여러 대의 머신에서 hypervisor 식별자를 일괄 감지하는 작은 스크립트를 작성할 수 있습니다.

3. 지연 지문과 Steal Time

ping 지연과 ICMP TTL은 이웃 부하를 드러낼 수 있습니다: 같은 IDC 내에서 지연 지터가 크고 vmstat의 st(steal time)가 자주 5%를 초과한다면, 물리 머신의 초과 판매가 심각하다는 뜻입니다. mtr로 지속적으로 라우팅 변화를 관찰하고, /proc/stat의 steal 필드를 함께 확인하면 구매 전에 오버셀링 위험을 간접적으로 판단할 수 있습니다. 이 방법은 AWS와 국내 클라우드 모두에 적용할 수 있으며, 임계값만 약간 조정하면 됩니다.

마지막으로 ASN 귀속, 라우팅 홉 수, 가상화 유형, Steal Time 평균, 지연 표준편차 목록을 내보냅니다. 다섯 열의 데이터를 대조하면 실제 클라우드 제공업체가 거의 드러납니다. 이는 온라인에서 IP 귀속만 보거나 벤치마크 점수만 보는 것보다 훨씬 신뢰할 수 있으며, 플랫폼 간 비교도 쉽습니다. CloudWorth의 감사 도구와 함께 사용하면 보고서를 자동으로 생성할 수 있습니다.