Synology Threat Prevention: 감지할 수 있는 것과 감지하지 못하는 것

Threat Prevention은 대다수의 사람들이 Synology NAS에서 웹사이트를 호스팅하기로 결정하는 순간 가장 먼저 찾는 패키지입니다. 라우터에 상주하며 방패 아이콘이 있고 대시보드에는 수백 건의 공격이 집계되므로 공개 사이트를 안전하게 지켜주는 도구처럼 보입니다. 저희는 보유한 모든 기기 앞에 있는 RT6600ax에서 이 패키지를 실행하고 있으며, 사용할 만한 가치가 있었습니다. 그러나 셀프 호스팅 웹사이트의 입장에서는 이 패키지가 본질에서 거의 완전히 벗어나 있기도 합니다.

이번 NAS Hosting 101 문서에서는 저희 라우터를 열어 실제 일주일간의 이벤트를 읽어보고, Threat Prevention이 볼 수 없었던 공격의 사례로 PHP2Shell을 사용하여 Threat Prevention이 어디서부터 도움을 줄 수 없는지 정확히 보여드립니다.

SynoPower Club 포인트: 저는 Synology 지원 부서에서 오래 일했으며, "이 공격을 막으려면 어떤 옵션을 켜야 하나요?"라는 질문을 끊임없이 받았습니다. 이는 올바른 본능이지만 잘못된 대상을 향한 것이었습니다. 제가 마침내 깨닫게 된 계기는 기능 소개 페이지 대신 우리 자신의 이벤트 목록을 읽었을 때였습니다. 이번 달에 우리 공유기가 기록한 모든 알림은 악성 페이로드가 포함된 요청이 아니라 평판이 나쁜 주소였습니다. 이 사실을 이해하고 나면, Threat Prevention에 봉인된 봉투에 담긴 트래픽을 검사해 달라고 요구하는 것을 멈추게 됩니다.

Threat Prevention이 Synology 라우터에서 실제로 하는 일 #

Threat Prevention은 Snort 및 Suricata 계보를 기반으로 구축된 침입 탐지 및 방지 시스템(IDPS)입니다. 라우터가 패킷을 전달할 때 패킷을 읽고 시그니처 세트와 비교하여 경고를 기록하거나 패킷을 차단합니다. 저희 RT6600ax의 시그니처 피드는 Emerging Threats 규칙 세트의 무료 계층인 ET Open이며, 매일 09:00에 정기적으로 업데이트됩니다.

이러한 설계 구조에서 세 가지 특성이 도출되며, 이 세 가지 모두 인터페이스의 그 어떤 체크박스보다 중요합니다:

• It can only examine packets the router forwards. Traffic that never crosses the routing engine is not slow to inspect, it is invisible.
• It can only match on bytes it can readThreat Prevention에는 TLS 가로채기 기능이 전혀 없으므로 암호화된 페이로드는 불투명합니다.
• It can only match signatures somebody else wrote. The interface exposes vendor classes to switch on and off, and nothing that accepts a rule you author yourself.

그 중 어느 것도 결함이 아닙니다. 네트워크 경계에 IPS를 두는 것은 합리적이고 유용한 일입니다. 실수하는 부분은 경계 영역이 웹사이트가 공격받는 위치라고 지레 짐작하는 것입니다.

Threat Prevention vs 웹 애플리케이션 방화벽 #

그 차이를 확인하는 가장 명확한 방법은 Threat Prevention을 웹 애플리케이션 방화벽(WAF)과 비교해 놓고, 각 시스템이 판단을 내릴 때 무엇을 가지고 있는지 확인해보는 것입니다. Threat Prevention은 패킷을 보유하고 있습니다. WAF는 복호화된 HTTP 요청을 보유하고 있습니다.

Question	Router IPS	Reverse-proxy WAF
그것이 달리는 곳	On the routing path, before TLS ends	At the edge, after TLS ends
What it inspects	Packet headers and any cleartext bytes	Method, path, headers, cookies, body
HTTPS traffic	Opaque	Fully readable
Rules you can add	Vendor classes on or off	Your own expressions, plus managed rulesets
Same-subnet traffic	Never seen	Not applicable, it is upstream of everything
Typical catch	Reputation hits, scans, cleartext exploits, outbound command and control	Injection, traversal, known CVE request shapes, credential stuffing, bots

두 제품은 경쟁 관계가 아닙니다. 동일한 여정의 서로 다른 구간을 담당하며, 셀프 호스팅 사이트에는 첫 번째보다 두 번째 제품이 훨씬 더 필요합니다. 저희는 두 제품을 모두 운영하며, 각각에서 완전히 다른 역할을 기대합니다.

자사 라우터에서 일주일간 발생한 595건의 이벤트 분석 #

2026년 10월 25일 기준 저희 운영 라우터의 Threat Prevention 개요 화면입니다. 7일 동안 595건의 악성 이벤트가 발생했으며, 그중 75건은 심각도가 높음(High)이었습니다. 마치 홍수를 막아내는 장벽처럼 보입니다.

해당 화면의 두 가지 세부 사항은 헤드라인 숫자보다 더 중요한 의미를 지닙니다. 첫째는 잠재적 위협 목록에 단 하나의 기기만 나타나며, 그것은 TLS를 종료하고 MailPlus를 실행하는 기기인 REVERSE_MAIL이라는 점입니다. 둘째는 녹색 체크 표시 옆의 시그니처 날짜입니다. 이제 단일 이벤트를 열어 실제로 어떤 규칙이 작동했는지 읽어보십시오.

분류 Misc Attack, 심각도 Medium, 상태 Alert, 시그니처 이름 ET CINS Active Threat Intelligence Poor Reputation IP group 24. 규칙 본문을 열어보면 alert ip로 시작하고 긴 IP 주소 목록이 나옵니다. 이는 블록리스트 조회입니다. HTTP 요청의 그 어떤 부분도 읽히지 않았는데, 읽을 수 있는 구조가 아니었기 때문입니다. 두 번째 대상인 Virtual DSM 호스트를 상대로 이벤트를 샘플링했을 때도 그룹 번호만 다른 동일한 유형의 규칙을 확인했습니다.

따라서 일주일간의 솔직한 요약은 이렇습니다: 라우터는 이미 대외적 평판이 좋지 않은 주소로부터 온 수백 건의 연결을 인식했습니다. 이는 진정으로 유용합니다. 그러나 이는 웹 공격 탐지가 아니며, 595라는 숫자를 웹 공격 탐지 건수인 것처럼 해석해서는 안 됩니다.

4단계로 Threat Prevention 점검하기 #

Threat Prevention을 전적으로 신뢰하기 전에 10분을 투자하여 자체 네트워크에서 실제로 어떤 작업을 수행하는지 확인해보십시오. 아래의 모든 단계는 읽기 전용이며 아무것도 변경하지 않습니다.

Threat Prevention이 제 역할을 톡톡히 하는 분야 #

저희는 미신이나 맹신 때문에 Threat Prevention을 켜두는 것이 아닙니다. 저희 인프라 스택의 다른 어떤 도구도 대체할 수 없는 4가지 작업을 이 패키지가 수행합니다.

• Outbound command and control. This is the strongest case by far. A compromised device has to call home, that call has to leave through the router, and a good share of it is still either cleartext or aimed at a known address. Our router ships the Malware Command and Control Activity class with 3,450 of 3,498 rules enabled, and the Domain Observed Used for C2 class with 7,157 of 7,202.
• Cleartext protocols from the internet. Our mail server answers on port 25, and SMTP is cleartext until STARTTLS. That is real inspectable traffic, and it is no accident that the mail host is the one device our events list keeps naming.
• Scanning and reconnaissance. Port sweeps and fingerprinting are recognised by connection behaviour rather than by payload, so encryption does not hide them.
• Visibility. A searchable log of who knocked and with what reputation is worth having, even when every entry is only a reputation hit. It is monitoring value, and it should be counted as monitoring value rather than as protection.

이 4가지 작업의 공통점은 그 중 어느 것도 웹사이트에 대한 직접적인 공격이 아니라는 점입니다.

사이트 소유자가 Threat Prevention에 잘못된 기대를 하는 이유 #

NAS에서 사이트를 호스팅할 때 요청 경로에는 일반적으로 리버스 프록시가 포함됩니다. 저희의 경로 구조는 다음과 같으며, 이 구조가 모든 것을 결정짓습니다:

• The visitor reaches Cloudflare, which answers most requests from cache and inspects the rest in cleartext.
• What is left crosses the router, 여기서 Threat Prevention은 암호화된 TLS 스트림만 볼 수 있을 뿐 그 이상은 보지 못합니다.
• 그만큼 reverse proxy NAS terminates TLS and forwards plain HTTP to the machine that runs the site.
• That last hop is on the same subnet, so the frame goes through a switch and the router is not in the path.

이 네 줄을 함께 읽으면 함정이 분명해집니다. 요청이 읽을 수 있는 형태로 존재하는 유일한 구간은 최종 홉뿐이며, 이는 라우터가 관찰할 수 없는 유일한 구간입니다. 라우터가 관찰할 수 있는 모든 곳에서 요청은 암호화되어 있습니다. 이러한 모순을 해결하는 체크박스는 없으며, Threat Prevention이 조용하다고 해서 작동에 실패한 것이 아닙니다. 구조적으로 읽을 수 없는 트래픽에 대해 정확하게 보고하고 있을 뿐입니다.

이것이 Threat Prevention을 특정 사이트로 지정해도 작동하지 않는 이유이기도 합니다. 이 패키지는 호스트 이름이 아니라 라우터 인터페이스에 바인딩됩니다. Host 헤더를 전혀 볼 수 없기 때문에 연결이 어떤 사이트에 속해 있는지에 대한 개념이 없습니다.

PHP2Shell이 라우터에서 감지되지 않은 세 가지 이유 #

CVE-2026-109618 및 CVE-2026-109619로 추적되는 인증 전 원격 코드 실행 취약점 쌍인 PHP2Shell은 2026년 10월 20일에 유출되었으며 다음 날 업스트림에서 패치되었습니다. 이는 많은 사람들이 라우터 IPS가 막아주기를 기대하는 바로 그런 문제이며, 왜 방어할 수 없었는지 명확히 짚어볼 필요가 있습니다.

첫째, 라우터가 감시하는 모든 구간에서 트래픽이 암호화되어 있었습니다. The exploit lives in the HTTP request, and the HTTP request only exists in the clear after TLS has been terminated, which happens downstream of the router on a hop the router never carries.

둘째, 활성화할 수 있는 Threat Prevention 시그니처가 존재하지 않습니다. We checked again on 25 October 2026 and found no published Snort or Emerging Threats rule for either CVE. Our feed is ET Open, the free tier, which lags the commercial set, and the Self-Defined Policy screen accepts no rule of your own. So even an operator who knew precisely what to match for had nowhere to put it.

셋째, 가장 근본적인 이유로 이 공격에는 일치시킬 페이로드 형태가 없습니다. The chain takes two requests. The first has to push PHP into exhausting its memory limit, which makes the engine abandon a request through a path that skips cleanup and leaves some global state behind. The second request is ordinary, and it is the one that reaches a stale pointer and turns into code execution.

첫 번째 요청은 바이트 시퀀스가 아니라 얼마나 많은 메모리를 소비하는지에 의해 정의되며, 대용량 업로드, 거대한 JSON 본문, 깊은 배열, 정규식의 긴 문자열 모두 해당됩니다. 두 번째 요청에는 악성 바이트가 전혀 포함되어 있지 않습니다. IPS는 패킷별 및 플로우별로 결정합니다. 이전 요청에서 다음 요청으로 오염된 상태를 전달하는 워커 프로세스의 모델을 가지고 있지 않으며, 바로 여기에 이 버그가 존재합니다.

또한 이는 당시 널리 알려졌던 완화 조치의 한계를 보여줍니다. 그 조치는 PHP 구성에서 session.upload_progress를 끄는 것이었습니다. 이는 두 번째 CVE에 도달하는 잘 설명된 한 가지 방법을 제거해주며, 실제로 패치할 수 없는 기기에서는 안 하는 것보다 낫습니다. 하지만 이는 근본적인 해결책이 아닙니다. 메모리 소모는 그 한 가지 기능으로만 발생하는 것이 아니며, 이 설정은 CVE-2026-109618과 전혀 무관합니다. 우리는 단 하나의 호스트에서 임시방편으로 이 방법을 사용했고, 이를 해결책이 아닌 시간을 번 것으로 간주했습니다. 패치 방법에 대한 자세한 내용은 당사의 PHP2Shell write-up.

설계상 Fail Open의 허점, 그리고 메일 서비스 장애를 겪은 날 #

Threat Prevention을 신뢰할 수 있는 제어 장치로 처리하기 전에 알아두어야 할 속성이 하나 더 있습니다. 권장되는 기본 모드는 네트워크 안정성 우선 모드이며, 인터페이스는 돌려 말하지 않고 그 의미를 밝히고 있습니다. 트래픽이 처리 용량을 초과하면 대기 중인 패킷이 필터링 없이 우회됩니다. 대안인 보안 우선 모드는 대신 이러한 패킷을 차단(drop)하고 문제가 해결될 때까지 연결이 불안정할 것이라고 경고합니다.

이는 가정용 라우터에 합리적인 기본값입니다. 그러나 이는 가장 강력하게 작동하기를 바라는 바로 그 순간에 Threat Prevention이 가장 약해진다는 것을 의미합니다. 트래픽 폭주(flood)는 필터링하고 싶은 대상인 동시에 용량을 초과하게 만드는 원인이기 때문입니다.

다른 오류 모드도 기록에 남아 있습니다. 2026년 8월 2일, 누군가 Linux에서는 전혀 작동할 수 없는 Windows PHP-CGI 버그 익스플로잇으로 당사의 역방향 프록시를 116회 공격했습니다. Threat Prevention은 자신의 상태가 꼬일 정도로 많은 패킷을 삭제(drop)한 다음, 자신이 방어하고 있던 바로 그 기기의 아웃바운드 트래픽조차 거부하기 시작했습니다. 메일 큐가 멈췄고 증상은 DNS 오류와 똑같았습니다. 라우터를 재부팅하니 해결되었습니다. 프록시에는 아무것도 도달하지 않았기 때문에 프록시 액세스 로그에는 아무것도 나타나지 않았습니다. 구조적으로 성공할 수 없었던 공격이었음에도 불구하고, 공격을 막아야 할 장치 때문에 시스템 중단이 발생하고 말았습니다.

목록에 있는 활성화 개수를 살펴보세요. Web Application Attack은 6,010개 규칙 중 5,928개가 활성 상태로 표시되며, 관심 있는 다른 클래스에서도 비율이 비슷합니다. 클래스를 켠다고 해서 내부의 모든 규칙이 켜지는 것은 아니며, 인터페이스에서는 누락된 나머지 규칙이 무엇인지 확인할 방법을 제공하지 않습니다.

전면에 프록시를 두고 원본 서버 접근 제한하기 #

NAS에서 웹사이트를 제공하는 경우 라우터가 할 수 없는 역할을 수행하는 제어 기능은 리버스 프록시 WAF입니다. 저희는 Cloudflare를 사용하며, 그 이유는 브랜드보다는 위치 때문입니다. TLS가 엣지에서 종료되므로 차단 여부를 결정하는 순간 전체 요청을 읽을 수 있습니다. 메서드, 경로, 쿼리, 헤더, 쿠키 및 본문 모두 규칙에 활용할 수 있습니다.

이것이 바로 PHP2Shell 방어 기능이 라우터가 아닌 프록시에 먼저 적용된 이유입니다. CVE가 공개되었을 때 관리형 규칙 세트는 이틀 내에 두 취약점에 대한 7개 규칙을 확보했고, 저희가 자체 컨테이너 재빌드를 완료하기 전에 저희가 운영하는 4개 존 모두에 적용되었습니다. Threat Prevention 피드에는 이와 동등한 규칙이 전혀 나타나지 않았으며, 5일이 지난 후에도 설치 가능한 공개 Snort 또는 Emerging Threats 규칙이 여전히 없습니다.

제공업체 선택보다 더 중요한 경고 사항이 하나 있습니다. 전면 프록시는 우회할 수 없는 경우에만 효과가 있습니다. 원본 주소가 공용 인터넷에 직접 응답하면 이를 발견한 누구나 작성된 모든 엣지 규칙을 건너뛰게 됩니다. 원본 서버의 포트 443을 프록시 네트워크 범위로 제한하고, 해당 범위를 하드코딩하기보다 제공업체 엔드포인트에서 동적으로 가져오며, 주소로 직접 사이트에 요청을 보내 제한이 제대로 되었는지 확인하세요. 당사의 전체 구성 및 이 레이어 뒤에 있는 4개 레이어는 다음에 설명되어 있습니다. the five layers we run.

Threat Prevention 제한 사항 및 보안 참고 사항 #

Threat Prevention은 라우터에 외부 저장 장치가 필요하며 모든 모델에서 지원되는 것은 아니므로 이를 중심으로 계획을 세우기 전에 하드웨어 지원 여부를 확인하세요. 또한 이 엔진은 라우터에서 가장 많은 작업을 수행하는 요소이며, 소비자용 제품에서는 처리량 제한(병목)이 될 가능성이 가장 높은 구성 요소입니다. 마케팅 수치를 신뢰하기보다 적용 전후를 측정해 보세요.

개요 화면의 모든 숫자는 차단된 공격 횟수가 아니라 시그니처 일치 횟수로 취급하세요. 이 두 가지는 서로 다릅니다. 아무것도 성공하지 못했을 스캐너에 대한 평판 감지 건수는 총계를 부풀리고, 평온한 한 주가 지났다고 해서 엔진이 읽을 수 없는 HTTPS 트래픽에 대한 안전을 보장해주지는 않습니다.

Threat Prevention에서는 심각도만큼이나 상태가 중요합니다. "고위험 패킷 자동 드롭"은 고위험 대역에만 작동하므로 중간 심각도 항목은 기록되고 전달됩니다. 인터페이스에 Alert(경고)라고 표시되면 패킷이 전달되었음을 의미합니다.

시그니처 피드는 하나의 공급망입니다. ET Open은 일정에 따라 업데이트되며 상용 규칙 세트보다 뒤처지고, 며칠 된 취약점에 대해 아무런 규칙도 제공하지 않을 수 있습니다. 데이터베이스가 최신 상태라고 보고하는 대시보드는 피드와 일치한다는 의미일 뿐, 현재 악용되고 있는 위협을 피드가 포함하고 있다는 의미는 아닙니다.

이 중 어떤 것도 패치를 대체할 수는 없습니다. 여기서 논의된 모든 레이어는 취약점을 실제로 해결하는 유일한 방법인 영향받는 소프트웨어 업데이트를 위한 시간을 벌어줄 뿐입니다. PHP2Shell의 경우 이는 새로운 PHP 패키지와 다시 빌드된 컨테이너를 의미했으며, 그 어떤 네트워크 제어도 이를 대신할 수 없었습니다.

마지막으로, 보안 권고를 읽은 후 모든 클래스를 활성화하려는 유혹을 참으십시오. Misc activity와 같은 클래스에는 주로 노이즈를 생성하고 유용한 클래스에 필요한 용량을 소모하는 수천 개의 저가치 규칙이 포함되어 있습니다. 실제로 확인하게 되는 조용하고 잘 조정된 이벤트 목록이 결국 무시하게 되는 시끄러운 목록보다 낫습니다.

자주 묻는 질문 #

참고 자료 및 비디오 튜토리얼 #

위에서 설명한 모든 내용의 기본 출처와 시간을 들여 볼 만한 3가지 가이드입니다.

• Synology 지식 센터: Threat Prevention covers requirements, modes and model support.
• Synology-SA-26:14 lists the fixed PHP package versions for DSM, including the 7.4 build.
• Synology Statement on PHP2Shell names the affected packages and the one that needs a manual update.
• Cloudflare WAF managed rules explains how managed rulesets are versioned and deployed.
• 클라우드플레어 IP 범위 is the endpoint to read when locking an origin to the proxy instead of hard-coding addresses.