VPS 악용 신고 메일의 의미와 대응 방법

VPS 악용 신고의 실체

VPS 악용 신고는 귀하의 IP 주소에서 발생한 트래픽에 대한 보고서입니다. 이 보고서는 해당 IP 대역에 등록된 악용 담당 연락처로 전달된 뒤, 호스트를 거쳐 귀하에게 전달되며 답변을 위한 기한이 주어집니다. 등록된 연락처는 해당 주소 공간을 보유한 기업의 것이므로, 귀하의 서버에 대한 보고서를 가장 먼저 읽는 사람은 귀하가 아닐 가능성이 매우 높습니다. 귀하의 호스트는 IP 주소와 타임스탬프를 귀하의 계정과 대조하여 보고서를 전달합니다.

이 통지서가 귀하가 고의로 무언가를 했다는 증거는 아닙니다. 신고자가 가진 유일한 식별자는 IP 주소뿐입니다. 03:00에 스팸을 발송하는 침해된 애플리케이션은 03:00에 스팸을 발송하는 사람과 동일한 보고서를 생성합니다. 이것이 바로 답변이 중요한 이유입니다. 귀하는 해당 트래픽의 출처가 무엇인지, 그리고 어떤 조치를 취했는지에 대해 답변을 요구받는 것입니다.

누가 보고서를 보내며, 어떻게 귀하의 호스트에 도달하는가

모든 공인 IP 대역은 RIPE NCC, ARIN, APNIC, LACNIC, AFRINIC과 같은 지역 인터넷 레지스트리(RIR)에 등록됩니다. 각 등록 정보에는 악용 사례(abuse) 담당 연락처가 게시되어 있으며, 보고서는 이 주소로 발송됩니다. 보고자가 확인하는 것과 동일한 레코드를 직접 조회할 수 있습니다.

whois 203.0.113.10 | grep -iE 'netname|descr|abuse'

RIPE 레코드에는 abuse-c: 역할 객체가 포함되어 있으며, 여기에 abuse-mailbox: 항목이 있습니다. ARIN 레코드에는 OrgAbuseEmail:가 포함되어 있습니다. 여기에 게시된 주소로 불만 사항이 접수되므로, 귀하의 서버에 관한 보고서가 귀하의 메일함이 아닌 호스트 업체로 전달되는 것입니다.

보고서를 제출하는 주체는 대개 기계입니다. 다음 네 가지 유형이 거의 모든 사례를 차지합니다.

• 자동화된 스캐너 및 허니팟: 기계가 귀하의 IP로부터의 연결 시도를 기록하고, 로그 발췌본을 첨부하여 보고서를 제출합니다.
• 메일 서비스 제공업체가 운영하는 피드백 루프(FBL): 수신자가 스팸 버튼을 누르면, 기계가 해석할 수 있도록 설계된 구조화된 메일 형식인 ARF(abuse reporting format)로 메시지 사본이 반송됩니다.
• 저작권 대리인: 토렌트 스웜을 감시하거나 공개 URL을 크롤링한 뒤, 파일명, 귀하의 IP, UTC 기준 타임스탬프가 포함된 DMCA(디지털 밀레니엄 저작권법) 통지서를 발송합니다.
• 차단 목록 운영자 및 네트워크 엔지니어: 자신의 로그에서 문제가 된 부분을 발췌하여 짧은 메일을 보냅니다.

대부분의 초기 보고서는 자동으로 생성되므로, 답장으로 논쟁을 벌이는 것은 아무런 도움이 되지 않습니다. 무엇이 실행 중이었고 언제 중단되었는지와 같은 사실 관계를 제시하는 것이 모든 문제를 해결합니다.

통지서에 마감 기한이 명시된 이유

귀하의 호스트 역시 임대 자원입니다. 해당 주소 공간은 상위 통신 사업자 뒤에 위치하며, 타인이 운영하는 평판 데이터베이스 내에 포함되어 있습니다. 응답이 없는 신고는 귀하의 단일 주소가 아닌 전체 블록의 점수를 높이므로, 통지서에 기재된 마감 기한은 하위로 전달되는 압박입니다. 통지서에 명시된 기간을 확인하고 이를 실제 기한으로 간주하십시오.

미응답 사례에 문제가 발생할 경우, 일반적으로 null route가 적용되어 해당 IP로 향하는 트래픽이 상위 단에서 차단되거나 인스턴스가 정지됩니다. 이러한 조치를 유발하는 것은 대개 초기 사건 자체가 아니라 침묵입니다. 특정 호스트가 수행하는 조치와 그 시점은 해당 호스트의 정책과 통지서 자체에 명시되어 있습니다. 이 두 문서만이 인용할 가치가 있으므로, 포럼에서 주장하는 제공업체의 허용 범위에 근거하여 행동하지 마십시오.

아웃바운드 스팸: 내가 보내지 않은 메일을 VPS가 발송하는 이유

귀하의 IP가 스팸 트랩으로 메일을 발송했거나, 수신자가 귀하의 메일을 스팸으로 신고했다는 보고가 접수된 경우입니다. 대부분의 사례는 다음 네 가지 원인에서 발생합니다. 속도 제한이 없는 메일 폼을 가진 웹 애플리케이션, 유출되어 타인이 사용하는 SMTP 자격 증명, 허용되지 않은 호스트를 중계하는 메일 서버, 뉴스레터 애플리케이션의 탈취된 로그인 계정입니다. 침해된 발송자는 일반적으로 큐에 나타나므로 큐부터 확인하십시오.

sudo postqueue -p | tail -n 20
sudo postqueue -p | grep -c '^[0-9A-F]'

인식할 수 없는 주소로 수천 개의 메시지가 큐에 쌓여 있다면 해당 서버가 메일을 발송하고 있는 것입니다. 다음으로 누가 인증했는지 확인하십시오.

sudo grep -o 'sasl_username=[^ ]*' /var/log/mail.log | sort | uniq -c | sort -rn | head

다른 계정보다 압도적으로 많은 발송 횟수를 기록한 계정이 유출된 자격 증명입니다. /var/log/mail.log 파일이 존재하지 않는다면 시스템에 rsyslog가 설치되지 않은 것이며, 동일한 내용을 다음 명령으로 저널에서 확인할 수 있습니다. sudo journalctl -t postfix --since '2 days ago'

인증된 기록이 없다면 로컬 프로세스가 발송자입니다. 릴레이 규칙과 열려 있는 연결을 확인하십시오.

sudo postconf -n | grep -E 'mynetworks|inet_interfaces|relay'
sudo ss -tnp state established '( dport = :25 )'

기본 설정된 Debian 또는 Ubuntu의 Postfix는 외부인을 위해 메일을 중계하지 않습니다. mynetworks 설정을 수동으로 전체 호스팅 서브넷으로 확장하면 오픈 릴레이가 되는데, 이 경우 해당 서브넷의 다른 모든 사용자가 귀하의 서버를 통해 메일을 보낼 수 있게 되기 때문입니다. 메일 서버가 아닌 프로세스가 25번 포트에 연결되어 있다면 이는 스크립트가 독자적으로 메일을 보내는 것이며, 이는 보통 침해된 PHP 애플리케이션에서 발생하는 현상입니다.

조사를 시작하기 전에 메일 흐름을 중단하고 증거를 보존하십시오.

sudo systemctl stop postfix
sudo tar czf /root/mailqueue.tgz -C /var/spool postfix

sudo postsuper -d ALL 명령은 큐를 비우지만, 동시에 무엇이 발송되었는지에 대한 기록도 삭제하므로 먼저 복사본을 확보하십시오. 그 후 애플리케이션이 보유한 모든 자격 증명을 교체하고, 애플리케이션을 업데이트하며, 침입자가 남긴 흔적을 찾으십시오. 스팸 사고와 서버 침해는 대부분 동일한 사건이므로, 단순히 큐를 비우는 것에 그치지 말고 해킹된 VPS 복구 절차를 따라 조치를 취하십시오.

포트 스캔과 무차별 대입 공격: 침해된 컨테이너의 모습

이 보고서에는 다른 운영자의 로그에서 발췌한 내용이 포함되어 있으며, 다음과 같은 형태를 띱니다.

sshd[2841]: Invalid user admin from 203.0.113.10 port 51992

원인은 거의 항상 방화벽으로 보호되고 있다고 믿었던 서비스에 있습니다. Docker가 흔한 사례입니다. -p 6379:6379 플래그로 포트를 공개하면 DOCKER-USER 및 nat 체인에 규칙이 작성됩니다. 이 규칙들은 ufw 규칙보다 먼저 평가되므로 ufw deny 6379은 이를 차단하지 못하며, 데이터베이스는 전 세계 인터넷을 향해 응답하게 됩니다.

sudo ss -ltnp
sudo iptables -S DOCKER-USER
docker ps

ss -ltnp에서 0.0.0.0 또는 [::]에 바인딩된 모든 서비스는 공인 IP 주소에서 수신 대기 중입니다. 호스트에서만 접근이 필요한 경우에는 루프백 주소인 -p 127.0.0.1:6379:6379에 바인딩하십시오. 데이터베이스를 어디에 배치할지는 별개의 결정 사항이며, Docker에서 데이터베이스를 실행할지 호스트에서 실행할지에 대한 내용은 해당 문서를 참조하십시오.

현재 서버에서 스캔이 진행 중인지 확인하려면 다음 명령을 사용합니다.

sudo ss -tnp state syn-sent

다양한 목적지로 향하는 다수의 하프 오픈(half-open) 연결은 아웃바운드 스캔이 진행 중임을 의미합니다. 커널 로그가 nf_conntrack: table full, dropping packet로 가득 차는 것 또한 같은 현상을 다른 관점에서 보여줍니다. 이는 서버가 정상적인 범위를 벗어나 과도하게 많은 연결을 시도하고 있다는 뜻입니다.

침해된 컨테이너는 정리하려 하지 말고 재구축하십시오. 컨테이너 내부에서 무엇이 변경되었는지 완벽히 파악할 수 없으므로, 신뢰할 수 있는 이미지로 재구축하고 신뢰할 수 있는 데이터만 복원한 뒤 해당 컨테이너가 보유했던 키를 교체(rotate)해야 합니다.

저작권 통지: 실제로 확인된 파일

DMCA 통지는 URL 또는 토렌트 정보 해시, 귀하의 IP 주소, UTC 기준 타임스탬프를 명시합니다. 대부분의 사례는 두 가지 원인으로 발생합니다. 미디어 파일이 포함된 디렉터리를 웹 서버가 공개적으로 나열하고 있거나, 다운로드가 완료된 후에도 토렌트 클라이언트가 시딩(seeding)을 계속하는 경우입니다.

타임스탬프를 액세스 로그와 대조하십시오. nginx의 combined 로그 형식은 9번째 필드에 상태 코드를, 7번째 필드에 요청 경로를 기록합니다:

sudo grep '14/Aug/2026:03' /var/log/nginx/access.log | awk '{print $9, $7}' | sort | uniq -c | sort -rn | head

아무것도 전송되지 않았다고 결론 내리기 전에 서버 시간을 확인하십시오. 통지는 UTC 기준이지만 로그는 서버의 시간대를 사용하므로, 몇 시간의 시차로 인해 잘못된 시간대를 검색하여 거짓 음성(false negative) 결과를 얻을 수 있습니다:

timedatectl
sudo timedatectl set-timezone UTC

그다음 원인을 해결하십시오. 파일을 삭제하거나 접근을 제한하고, nginx location 블록에서 autoindex off; 설정을 사용하여 디렉터리 나열 기능을 끄십시오. 또한 토렌트 클라이언트는 공용 인터페이스가 아닌 다른 인터페이스에 바인딩하십시오. 해당 파일명, 조치 내용, 조치를 취한 시간을 명시하여 회신하십시오. 만약 청구 내용 자체가 잘못되었다고 판단된다면, 이는 귀하와 발신자 사이의 법적 문제이며 통지서에 이의 제기 방법이 명시되어 있습니다. 호스팅 업체는 이를 결정하는 주체가 아니므로, 정당성을 주장하는 티켓을 보내도 해결되지 않습니다.

블랙리스트 등재: 아웃바운드 메일이 작동하지 않는 이유

이 문제는 대개 수신되는 메일이 전혀 없는 상태로 나타납니다. 아웃바운드 메일이 단순히 수신 거부되며, 반송 메일에 그 이유가 포함됩니다.

554 5.7.1 Service unavailable; Client host [203.0.113.10] blocked using zen.spamhaus.org

IP의 4개 옥텟을 역순으로 배치하고 리스트의 존을 쿼리하여 등재 여부를 확인하십시오.

dig +short 10.113.0.203.zen.spamhaus.org

응답이 비어 있다면 해당 리스트에 등재되지 않은 것입니다. 127.0.0.x 응답은 등재된 상태를 의미하며, 마지막 옥텟은 일치하는 서브리스트를 나타냅니다. 127.255.255.x 범위의 응답은 쿼리가 답변되지 않고 거부되었음을 의미합니다. 이는 대개 무료 서비스를 제공하지 않는 대형 공용 리졸버를 통해 쿼리가 전송되었기 때문입니다. 서버 자체 리졸버에서 다시 실행하여 정확한 결과를 얻으십시오.

제외 신청은 호스팅 업체가 아닌 리스트 운영자의 사이트에서 진행해야 합니다. 등재 원인을 먼저 해결하지 않으면 소용이 없습니다. 등재를 유발한 트랩이 다음 메시지 발송 시 다시 등재하기 때문입니다. 이후 메일 흐름을 결정하는 요소는 두 가지가 더 있습니다. IP에 대한 역방향 DNS 이름인 PTR 레코드는 호스팅 업체가 관리하므로, 동일한 주소로 다시 해석되는 이름을 설정해 달라고 요청하고 해당 이름을 HELO로 사용하십시오. 또한 이전 사용자가 사용하던 주소를 재할당받은 경우 본인이 생성하지 않은 이력이 남아 있을 수 있습니다. DNS를 수정하며 일주일을 보내기 전에 이 점을 먼저 문의하는 것이 좋습니다. SPF(sender policy framework)와 DKIM(domainkeys identified mail) 레코드를 올바르게 설정하고, 이를 결합하는 DMARC 정책을 구성하는 방법은 Mailcow를 이용한 자체 메일 서버 운영 가이드에서 처음부터 끝까지 다룹니다.

악용 메일이 업무의 일부인 릴레이 인프라

Tor exit node, 공개 VPN 또는 타인을 위한 프록시를 운영한다면, 본인이 생성하지 않은 트래픽에 대한 불만 제기는 일반적인 운영 비용의 일부입니다. 핵심은 서버가 해킹당한 것처럼 보이지 않고, 릴레이로서의 정체성을 명확히 드러내는 것입니다. 역방향 DNS(reverse DNS)를 설명적인 이름으로 설정하고, 포트 80에서 해당 주소의 정체를 설명하는 간단한 안내 페이지를 제공하십시오. 악용 관련 메일이 오면 동일한 설명으로 신속하게 답변하고, 소프트웨어에서 제공하는 정책을 활용하여 신고가 가장 많이 발생하는 포트를 차단하십시오. 해당 서비스를 별도의 IP 주소에서 운영하고, 이상적으로는 별도의 인스턴스에서 실행하여 특정 주소에 null route가 적용되더라도 웹 애플리케이션이 함께 중단되지 않도록 하십시오. 시작하기 전에 호스팅 업체에 문의하십시오. 허용 범위는 회사와 IP 대역에 따라 다르며, 이는 포럼 게시글이 아닌 호스팅 업체에 직접 확인해야 할 사항입니다. VPS에서 Tor exit node 운영하기 문서에서 exit policy와 안내 페이지에 대한 상세 내용을 확인할 수 있습니다.

티켓을 종료하기 위한 대응 방법

• 사람이 직접 읽는 연락처를 게시하십시오. RFC 2142에 따라 abuse@ 및 postmaster@ 주소를 도메인에 설정하면 신고자가 가장 먼저 연락을 시도합니다. 해당 메일함은 보호 대상 서버가 아닌 다른 곳에 호스팅하십시오. 서버가 정지되면 정지 통보 메일을 수신할 수 없기 때문입니다.
• 신고에 대응할 수 있도록 로그를 충분히 보관하십시오. 7일 주기로 로그가 순환된다면 12일 전의 트래픽 신고에는 대응할 수 없습니다. journalctl --disk-usage를 확인하고, /etc/systemd/journald.conf에서 MaxRetentionSec=90d를 설정한 뒤 sudo systemctl restart systemd-journald을 실행하십시오. 웹 및 메일 로그는 /etc/logrotate.d/에 따라 자체적인 주기로 순환됩니다.
• 서버 시간을 UTC로 유지하십시오. 그래야 신고서의 타임스탬프와 로그의 타임스탬프가 일치하여 별도의 계산 과정이 필요 없습니다.
• 불만을 유발하는 서비스와 절대 잃어서는 안 되는 서비스를 분리하십시오. 메일은 한 주소로, 웹 애플리케이션은 다른 주소로, 릴레이 서비스는 별도의 인스턴스로 분리합니다. 특정 IP에 대한 조치는 그 뒤에 있는 모든 서비스에 대한 조치와 같습니다.
• 조사가 완료되지 않았더라도 정해진 기한 내에 답변하십시오. 구체적인 시간을 명시한 중간 답변만으로도 1차 대응으로는 충분합니다.

대부분의 티켓을 종료시킬 수 있는 첫 답변은 간결하고 구체적이어야 합니다.

Received, thank you. Confirmed at 09:14 UTC.
Source: a contact form in our web app that allowed unauthenticated sending.
Action: form disabled, Postfix stopped, all SMTP credentials rotated 09:31 UTC.
Evidence: mail queue and logs preserved for 90 days if you need them.
Next: patched app redeployed by 18:00 UTC today. I will confirm here.

현재 파악된 사실과 아직 확인 중인 사항을 명확히 밝히십시오. 침묵은 서버가 관리되지 않는다는 신호로 간주되며, 관리되지 않는 서버는 에스컬레이션 절차를 밟게 됩니다. 이러한 작업이 본인의 책임인지 여부는 구매한 상품에 따라 다르며, 이것이 관리형 및 비관리형 VPS 호스팅의 차이입니다. 비관리형 플랜에서는 사용자가 곧 보안 팀입니다.

성공적으로 처리되었을 때의 모습

남용 신고는 무엇보다 먼저 라우팅 문제입니다. 특정 주소에 대한 신고는 해당 주소의 관리 책임자에게 전달되며, 문제를 해결할 수 있는 담당자에게까지 이어집니다. 관리자가 제어할 수 있는 부분은 연락처 주소, 로그 보관 기간, IP별 서비스 분할 방식, 그리고 회신 속도입니다. 이 요소들을 올바르게 설정하면 대부분의 신고는 한 번의 교환으로 종료됩니다. 이러한 습관은 VPS 호스팅의 안전성 여부라는 더 큰 문제도 해결합니다. 아무도 감시하지 않는 서버가 결국 타인의 로그에 남게 되기 때문입니다.

FAQ

남용 신고를 받으면 VPS가 해킹당한 것입니까?

반드시 그렇지는 않지만, 가장 먼저 확인해야 할 가능성입니다. 신고는 귀하의 IP에서 트래픽이 발생했다는 사실만을 증명합니다. 외부로 발송되는 스팸이나 포트 스캔은 계정 소유자보다는 침해당한 애플리케이션이나 컨테이너에서 발생하는 경우가 훨씬 많습니다. 따라서 다른 작업을 수행하기 전에 sudo postqueue -p로 메일 큐를 확인하고 sudo ss -ltnp으로 리스닝 소켓을 점검하십시오. 저작권 및 차단 목록 관련 통지는 성격이 다릅니다. 이는 대개 귀하가 의도적으로 실행 중인 서비스와 관련이 있습니다.

남용 통지에 답변할 기한은 얼마나 됩니까?

기한은 수신한 통지문에 명시되어 있으며, 호스트와 신고 유형에 따라 다릅니다. 저작권 및 스팸 트랩 관련 신고는 대개 기한이 가장 짧습니다. 명시된 시간을 엄격히 준수해야 하며, 원인을 파악하는 중이라도 기한이 지나기 전에 짧은 중간 답변을 보내야 합니다. 티켓을 처리하는 담당자에게 중요한 것은 사람이 대응하고 있으며 문제가 되는 트래픽이 중단되었다는 사실입니다.

제 IP가 차단 목록에 올랐습니다. 호스트가 이를 삭제해 줄 수 있습니까?

아니요. 목록 삭제는 해당 목록을 운영하는 주체가 직접 사이트에서 수행하며, 호스트는 그들의 데이터베이스를 제어할 수 없습니다. 호스트는 IP의 역방향 DNS 이름인 PTR 레코드를 제어할 수 있으므로, 이와 동시에 PTR 레코드 수정을 요청하는 것이 좋습니다. 스팸 트랩은 다음 메시지가 발송되면 다시 귀하를 목록에 올릴 것이므로, 삭제 요청을 하기 전에 발송 문제를 먼저 해결하십시오.

호스트에게 실제로 무슨 일이 일어났는지 알려야 합니까?

티켓을 종결할 수 있을 만큼의 정보, 즉 문제의 원인이 무엇이었고 언제 중단되었는지는 알려야 합니다. 포렌식 보고서나 사용자의 데이터를 제출할 의무는 없습니다. 모호한 답변은 짧은 답변보다 나쁩니다. 무엇이 변경되었는지 확인할 수 없는 담당자는 해당 건을 해결된 것으로 처리할 이유가 없기 때문입니다.

스캐너에서 보낸 자동화된 신고를 무시해도 됩니까?

아니요. 자동화된 신고는 누적되며, 동일한 IP에 대한 반복적인 신고는 호스트의 전체 주소 블록에 대한 평판 점수를 낮춥니다. 이것이 작은 문제를 심각한 사안으로 키우는 원인입니다. 답변은 한 문단이면 충분합니다. 자동화된 신고 시스템은 답변을 읽지 않겠지만, 호스트 측의 티켓 담당자는 이를 읽습니다. 그 담당자가 귀하의 인스턴스에 대한 조치를 결정하는 사람입니다.