IP 주소를 조사하는 방법: 실제 IP 3개, 판정 3가지

2026년 10월 19일 05:34 UTC에 우리는 세 개의 주소를 같은 파이프라인에 넣었고 서로 다른 세 가지 판정을 얻었습니다. Mullvad VPN 출구는 100점, block이었습니다. 검증된 AhrefsBot 주소는 Spamhaus에 등재되어 있어 59점, step_up이었습니다. DigitalOcean 서버는 12점, allow였습니다. 열하루 전에는 그 AhrefsBot 주소가 23점, allow였습니다.

아래에서는 열두 가지 검사를 순서대로, 각 단계에서 읽어야 할 필드, 우리가 조치에 사용하는 임계값, 악용 신고처, 그리고 모든 IP 조사의 법적 한계를 다룹니다.

IP 주소를 조사하는 방법: 주소 세 개, 판정 세 가지

같은 열두 가지 질문이 세 주소를 서로 다른 세 조치로 보냈고, 각각의 경우 하나의 신호가 결정을 내렸습니다. 다음은 우리 API에서 키 없이 조회하여 표시된 시각에 저장한 값이며, 편집하지 않았습니다.

우리의 구간은 25까지 allow, 50까지 review, 75까지 step_up, 75 초과는 block입니다. 검사 순서는 다음과 같습니다. 라우팅 가능 여부, 소유자, 네트워크 유형, 호스트명, 익명화 도구, 크롤러 또는 스캐너, 차단 목록, 점수, 결정, 신고, 만료와 법적 한계입니다.

가운데 행이 교훈입니다. 검증된 크롤러도 차단 목록에 오를 수 있으며, 우리 점수의 크롤러 감점도 이 주소를 allow에 머물게 하지 못했습니다.

시작하기 전에: 수동적으로 진행하고 IP가 나타난 위치를 기록하십시오

무언가를 조회하기 전에 경보의 맥락을 적어 두십시오. 시간대를 포함한 타임스탬프, 접근한 포트나 경로, 그리고 /wp-admin이나 /.env에 대한 탐색 시도 또는 로그인 실패 급증 같은 행동입니다. 이 맥락이 어떤 조회 못지않게 판정을 좌우합니다.

수동적으로 진행하십시오. 조회, 레지스트리, 평판 사이트를 사용하고, 해당 주소를 역으로 스캔하지 마십시오. 포트 스캔은 호스트 운영자에게 경계심을 줄 수 있으며, 허가 없이 네트워크를 스캔하는 것은 법이나 제공업체의 약관을 위반할 수 있습니다.

1단계: 라우팅 가능한 공인 주소입니까?

그 주소가 애초에 인터넷을 통해 도달할 수 있었는지 확인하십시오. threat.is_bogon과 threat.is_cgnat을 읽습니다. 보곤(bogon)은 사설 대역이나 예약 대역처럼 공인 인터넷에 나타나서는 안 되는 주소입니다. 인터넷 경계에서 이런 주소가 출발지로 보인다면 내부 트래픽, 잘못 구성된 프록시, 또는 위조된 패킷을 보고 있는 것이며, 이 파이프라인의 나머지는 적용되지 않습니다.

캐리어급 NAT(CGNAT) 주소는 라우팅은 가능하지만 공유됩니다. 하나의 모바일 또는 브로드밴드 주소가 한꺼번에 수백 명의 가입자를 담을 수 있으므로, 그 주소에 대해 내리는 결정은 모두에게 적용됩니다.

세 주소 모두 is_bogon이 false, is_cgnat이 false로 반환되었으므로 파이프라인을 계속 진행합니다.

2단계: 누구의 것입니까? ASN과 RDAP

소유자는 두 가지 기록에서 나옵니다. 주소를 광고하는 자율 시스템(AS)과 해당 블록의 레지스트리 기록입니다. 경로에 대해서는 asn.asn, asn.org, asn.rpki를 읽고, 등록 정보에 대해서는 whois.org, whois.netname, whois.registered, network.abuse_contact를 읽습니다.

기록이 말하지 않는 것에 주목하십시오. Mullvad 서버의 기록 어디에도 "Mullvad"라는 이름은 없습니다. Mullvad의 네트워크를 운영하는 회사인 31173 Services가 기재되어 있으며, whois.has_vpn_keywords는 false입니다. DigitalOcean의 whois.org는 "none"으로 돌아왔으므로 그 경우에는 ASN이 소유권을 알려 줍니다. 배경이 필요하다면 ASN이 네트워크에 대해 알려 주는 것을 참고하십시오.

저장된 기록이 부실하면 원본으로 가십시오. 등록 데이터는 다섯 개의 지역 인터넷 레지스트리에 있습니다. ARIN, RIPE NCC, APNIC, LACNIC, AFRINIC입니다. IANA의 RDAP 부트스트랩 파일은 어떤 대역을 어느 곳이 관리하는지 알려 줍니다. RDAP는 WHOIS의 구조화된 JSON 후속 규격입니다. 05:43 UTC에 5.39.1.230에 대한 RIPE의 RDAP 기록을 열었을 때, 더 작은 블록인 5.39.1.224/27이 나타났고 그 등록 조직이 Ahrefs Pte Ltd로 되어 있었습니다. 우리가 저장한 기록은 OVH의 더 큰 페일오버 블록을 반영합니다. 가장 구체적인 레지스트리 기록이 우선합니다.

3단계: 어떤 종류의 네트워크입니까?

네트워크 유형은 이후의 모든 신호에 맥락을 부여하므로, 평판 데이터보다 먼저 읽으십시오. 필드는 asn.asn_type, asn.user_type, asn.connection_type, detection.is_hosting, detection.is_mobile입니다.

세 주소 모두 호스팅 주소이지만 block으로 끝난 것은 하나뿐입니다. 호스팅은 맥락이지 유죄가 아닙니다. VPN 출구, 크롤러, 자체 CI 러너가 모두 데이터센터에 있습니다. 이것이 호스팅 IP가 사기의 증거가 아닌 이유입니다. AhrefsBot의 user_type이 search_engine_spider라는 점은 두 번째 주소가 크롤러라는 첫 번째 힌트입니다.

4단계: 호스트명은 무엇을 말합니까? 역방향 DNS와 FCrDNS

역방향 DNS는 블록 소유자가 설정한 호스트명을 반환하고, 정방향 확인 역방향 DNS(FCrDNS)는 그 호스트명이 같은 IP로 다시 확인되는지 검사합니다. network.ptr_record와 network.fcrdns_valid를 읽은 다음 직접 검사를 실행하십시오. 저장된 PTR은 실시간 DNS보다 뒤처질 수 있기 때문입니다. 다음은 2026년 10월 19일 05:42 UTC에 실행한 결과입니다.

AhrefsBot 주소는 실시간 FCrDNS를 통과하며, Ahrefs의 로봇 페이지는 크롤러 호스트명이 항상 ahrefs.com 또는 ahrefs.net으로 끝난다고 밝힙니다. 그러나 우리 API에는 이 주소의 PTR이 저장되어 있지 않으며, 그래서 나중에 no_ptr_datacenter가 작동합니다. 저장된 필드보다 실시간 실행 결과를 신뢰하십시오.

DigitalOcean 서버는 또 다른 실패 사례를 보여 줍니다. 우리 API에는 이 주소에 대해 무관한 제3자의 호스트명이 저장되어 있고, fcrdns_valid는 false이며, fcrdns_mismatch 방식이 작동합니다. 우리가 직접 실행한 dig -x는 PTR을 전혀 반환하지 않았으므로 저장된 이름은 오래된 것입니다. 이런 불일치는 약한 신호입니다. 작동한 방식은 단 두 가지뿐이었고, 그 주소는 여전히 12점을 받았습니다.

5단계: VPN, 프록시, Tor 출구 또는 릴레이입니까?

이 단계는 누군가 그 주소 뒤에 숨어 있는지를 묻습니다. detection.is_vpn, is_proxy, is_tor, is_relay, vpn_provider, relay_provider, last_seen을 읽습니다.

Mullvad 서버는 Mullvad가 자사 앱을 위해 게시하는 서버 목록에 있으므로 vpn_confidence 95로 이름이 확인되었습니다. 이것이 VPN IP를 제공업체와 대응시키는 방법이며 한계가 있습니다. 목록에 없는 VPN은 프로브로 잡을 수는 있지만 이름은 알 수 없습니다. Tor의 경우 해당 주소를 Tor Project의 일괄 출구 목록과 비교하거나 Tor 출구 트래픽 탐지 가이드를 읽어 보십시오. iCloud Private Relay 같은 릴레이는 VPN이 아닙니다. 일반 브라우저 사용자의 트래픽을 전달하므로 우리 점수는 릴레이 주소에 60점의 상한을 두며, block에는 절대 이르지 못합니다.

6단계: 검증된 크롤러 또는 알려진 스캐너입니까?

검증된 크롤러는 운영자가 공개한 대역 목록에 있는 주소이고, 스캐너는 인터넷 전체를 탐색하는 인프라입니다. threat.crawler.verified, name, operator, verification_method를 읽은 다음 threat.is_scanner와 threat_types를 읽습니다.

AhrefsBot은 Ahrefs가 공개한 대역과 일치했으므로 운영자는 확정입니다. User-Agent가 Googlebot이라고 주장하는 모든 것에도 같은 처리가 필요합니다. 신뢰하기 전에 Googlebot이라고 주장하는 IP를 검증하십시오. 더 넓은 그림은 IP 주소로 봇 탐지하기에 있습니다.

네 번째 행은 05:34 UTC에 조회한 Ann Arbor의 Censys 스캐너입니다. is_scanner가 true, 점수 0, allow, 빈 detection_methods 목록이 반환되었습니다. 스캐너 플래그는 우리 점수를 움직이지 않으므로 직접 읽으십시오.

7단계: 차단 목록에 있습니까? 언제부터입니까?

차단 목록은 그 주소에서 악용이 관찰되었음을 기록하며, 등재 여부보다 날짜가 더 중요합니다. threat.is_abusive, is_spammer, is_botnet, dnsbl_sources를 읽습니다.

그다음 외부 출처를 수동적으로 확인하십시오.

• Spamhaus. ZEN은 Spamhaus의 무료 IP 차단 목록을 결합한 것이며, 해당 페이지는 등재 세부 정보를 위해 Spamhaus의 IP 및 도메인 평판 검사기로 안내합니다.
• AbuseIPDB. AbuseIPDB는 사용자가 제출한 악용 신고를 보여 줍니다. 총 건수가 아니라 신뢰 점수와 최근 신고의 날짜를 읽으십시오.
• VirusTotal. VirusTotal은 몇 개의 보안 업체가 그 주소를 플래그했는지와 그에 연결된 파일 또는 URL을 보여 줍니다.
• Shodan과 Censys. Shodan과 Censys는 이들의 스캔이 호스트에서 이미 발견한 실행 중 항목을 보여 주므로, 호스트를 건드리지 않고 열린 서비스를 확인할 수 있습니다.

최신성이 존재 여부를 이깁니다. 지난주의 등재는 중요하고, 여섯 달 전의 깨끗한 결과는 오늘에 대해 거의 아무것도 알려 주지 않습니다.

8단계: 점수와 작동한 방식을 읽으십시오

점수는 위의 모든 것을 날짜와 함께 종합한 것이며, scoring.detection_methods는 점수가 왜 그렇게 나왔는지 알려 줍니다. 다음은 이 플레이북에서 사용하는 그룹만 남기고 줄인 AhrefsBot 조회 결과이며, 값은 편집하지 않았습니다.

세 주소 모두에서 작동한 방식은 다음과 같습니다.

verified_crawler는 우리 점수에서 28.5점을 깎는 면책 신호이며(신뢰도 0.95에서는 30점 감점), 그래도 두 개의 차단 목록 방식과 스팸 등재를 상쇄하기에는 충분하지 않았습니다. 평판은 이력이며 점수는 그 스냅샷입니다. IP 평판이 형성되는 방식을 참고하십시오.

9단계: IP, 프리픽스, ASN 중 무엇을 차단할지 결정하십시오

점수 구간을 조치에 대응시킨 다음, 그 조치가 미치는 범위를 선택하십시오. 다음은 우리가 실제로 조치할 판정입니다.

조치의 범위도 조치만큼 중요합니다. 일회성이면 IPv4 주소 하나를 차단하십시오. IPv6의 경우 한 고객이 보통 /64 전체를 제어하므로 주소 하나 대신 IPv6 /64를 차단하십시오. ASN 전체는 실제 사용자가 접속하지 않는 호스팅 네트워크에만 차단하고, 이동통신사나 CGNAT 대역에는 절대 적용하지 마십시오.

강제 차단보다 속도 제한과 챌린지를 선호하십시오. 차단은 다음 주에 그 주소를 받는 사람에게도 영향을 줍니다. fail2ban 같은 도구로 로그에서 차단을 자동화하는 것은 별개의 주제입니다. 어떤 신호가 어떤 공격을 막는지는 어떤 IP 신호가 어떤 공격을 막는가를 참고하십시오.

10단계: 악용 IP를 해당 네트워크의 악용 신고 연락처에 신고하십시오

악용 신고는 레지스트리 기록에서 나온 network.abuse_contact의 주소로 보내십시오.

형용사가 아니라 증거를 보내십시오. 시간대를 포함한 타임스탬프, 로그 라인, 목적지 호스트와 포트, 그리고 트래픽이 한 행동입니다. 다른 방어자들도 볼 수 있도록 AbuseIPDB에도 등록하십시오.

11단계: IP 판정은 얼마나 오래 유지됩니까?

판정은 몇 달이 아니라 며칠 동안 유지되며, 우리는 판정이 바뀌는 것을 직접 지켜보았습니다. 2026년 10월 8일에 웹 스크래핑 관련 글을 위해 5.39.1.230을 조회했습니다. crawler.verified가 true, is_abusive가 true, 점수 23, allow였고, 방식은 abusive_listed, datacenter_blocklisted, no_ptr_datacenter, verified_crawler였습니다.

2026년 10월 19일 05:34:32 UTC에 같은 주소는 59점, step_up을 반환했습니다. 같은 크롤러, 같은 검증된 대역, 같은 운영자입니다. 방식에서 달라진 것은 목록에 추가된 known_spammer이며, 오늘의 조회는 is_spammer가 true이고 dnsbl_sources에 zen.spamhaus.org가 있음을 보여 줍니다. 10월 8일에는 이 두 필드를 기록하지 않았으므로, 스팸 등재가 점수에 새로 반영되었다는 것만 알 뿐 Spamhaus가 등재한 날은 알지 못합니다. 검증된 크롤러 감점은 여전히 적용되었으나 충분하지 않았습니다. 열하루 만에 이 주소는 두 개의 구간을 넘어갔습니다.

우리의 위협 피드와 크롤러 대역 파일은 모두 매일 갱신되므로, 판정은 하룻밤 사이에도 바뀔 수 있습니다. 규칙은 이렇습니다. 모든 판정에 날짜를 함께 저장하고, 피드 갱신 주기보다 오래된 판정에 따라 조치하기 전에 조회를 다시 실행하십시오. 플래그는 판정이 아니며, 판정은 만료됩니다.

12단계: IP 주소 뒤에 있는 사람을 찾을 수 있습니까?

아니요. IP 주소는 사람이 아니라 네트워크로 이어집니다. 주소와 시각을 가입자와 대조할 수 있는 것은 ISP나 호스트뿐이며, 이는 귀하나 우리가 아니라 법원 명령 같은 법적 절차에 따라서만 공개됩니다.

귀사의 시스템에 접촉한 주소를 조사하고, 네트워크에서 멈추며, 누구의 신원을 밝히거나 스캔하려 하지 마십시오. 지리적 위치 또한 근사치입니다. 우리의 세 조회는 주소를 Frankfurt, Paris, North Bergen에 위치시켰는데, 이는 데이터센터를 도시 수준으로 특정할 뿐 번지 수준의 주소가 아닙니다.

다음 경보에서 같은 파이프라인을 실행하십시오

경보 대기열에서 다음 주소를 가져와 경보 맥락을 옆에 두고 같은 조회를 실행해 보십시오. 열두 가지 검사를 자동화하려면 조회 API 문서에서 시작하십시오.

키 없는 조회는 분당 30건으로 제한되며, 이 제한은 엄격합니다. 1분 안의 30번째 요청이 이미 429를 반환하고 호출자 IP를 두 시간 동안 차단합니다. 스크립트에는 무료 키를 사용하십시오. 모든 필드를 포함해 하루 1,500건의 조회가 가능합니다. 조회를 대규모로 SIEM에 연동하는 것은 바쁜 대기열을 위한 다음 단계입니다.

자주 묻는 질문

의심스러운 IP 주소는 어떻게 조사합니까?

수동적으로, 순서대로 진행하십시오. 라우팅 가능한 공인 주소인지 확인하고, 소유자와 네트워크 유형을 파악하고, 호스트명, 익명화 도구 및 크롤러 플래그를 확인하고, 차단 목록 등재 여부와 날짜를 읽은 뒤, 점수에 따라 조치하고 날짜를 기록하십시오.

IP 주소가 악성인지 어떻게 확인할 수 있습니까?

단일 검사로는 증명할 수 없습니다. Spamhaus 같은 현재 등재 여부, AbuseIPDB의 최근 악용 신고, 익명화 도구 플래그를 확인한 다음, 해당 주소가 귀사의 시스템에서 실제로 한 행동과 견주어 보십시오. 플래그는 그 주소에서 악용이 관찰되었다는 뜻이지, 이번 요청이 악용이라는 뜻이 아닙니다.

IP 주소 뒤에 있는 사람을 찾을 수 있습니까?

혼자서는 불가능합니다. IP는 네트워크 운영자로 이어질 뿐이며, 주소와 시각을 가입자와 대조할 수 있는 것은 그 운영자뿐입니다. 운영자는 이를 귀하가 아니라 법적 절차에 따라서만 공개합니다. 대신 해당 네트워크의 악용 신고 연락처에 신고하십시오.

IP, 프리픽스, ASN 전체 중 무엇을 차단해야 합니까?

일회성이면 IPv4 주소 하나를 차단하고, IPv6는 단일 주소가 아니라 /64를 차단하며, ASN 전체는 실제 사용자가 접속하지 않는 호스팅 네트워크에만 차단하십시오. 하나의 주소가 많은 사용자를 담을 수 있으므로 모바일이나 CGNAT 대역은 차단하지 마십시오.

검증된 크롤러는 항상 안전하게 허용해도 됩니까?

아닙니다. AhrefsBot의 5.39.1.230은 2026년 10월 19일에 Ahrefs가 공개한 대역과 일치했지만 Spamhaus ZEN에도 등재되어 있었고 59점, step_up을 받았습니다. 검증은 그 주소를 누가 운영하는지 알려 줄 뿐, 그 대역이 깨끗하다는 뜻은 아닙니다.

IP 조사 결과는 얼마나 오래 유효합니까?

몇 달이 아니라 며칠입니다. 같은 AhrefsBot 주소가 2026년 10월 8일에는 23점, allow였고 10월 19일에는 59점, step_up이었습니다. 오래된 판정에 따라 조치하기 전에 조회를 다시 실행하고, 모든 판정에 날짜를 함께 저장하십시오.