Tips
시놀로지 NAS 보안 점검을 시작한 건 아는 분의 NAS가 해킹당했다는 이야기를 들은 뒤였다.
내 NAS는 몇 년째 별문제 없이 돌아가고 있었다. 그래서 더 미뤘다. 잘 돌아가니 괜찮겠지 싶었던 것이다.
로그를 살펴본 범위에서는 낯선 성공 로그인을 찾지 못했다.
대신 정리할 설정이 꽤 있었다.
관리자 2단계 인증이 없었고, 방화벽은 활성화되어 있었지만 내가 만든 규칙이 없었다.
DSM도 오래된 버전을 쓰고 있었다.
점검하고 바꾸는 과정에서 웹사이트까지 잠깐 안 열렸다.
그때 확인한 내용을 정리했다.
보안 어드바이저를 실행하고 로그 센터의 연결 기록을 한 달치 살펴봤다.
실패 횟수만 세기보다 어느 서비스로 접속했는지, 성공 기록 중 내가 설명할 수 없는 접속이 있는지를 함께 봤다.
| 발견한 내용 | 확인한 곳 | 해석할 때 볼 점 |
|---|---|---|
| 하루 DSM 로그인 실패 9,000건 이상 | 로그 센터의 연결 기록 | 분산된 시도는 IP 차단만으로 모두 걸러지지 않는다. 성공 기록과 계정 보호도 함께 확인 |
| 직접 만든 방화벽 규칙 없음 | 제어판 → 보안 → 방화벽 | 규칙 목록과 인터페이스별 기본 허용·거부 동작을 함께 확인 |
| 관리자 2단계 인증 미설정 | 계정 보안 설정 | 관리자 계정마다 실제 인증 등록 여부 확인 |
| DSM 7.1 사용 | 제어판 → 업데이트 및 복원 | 모델별 지원 버전과 업데이트 경로, 패키지 호환성 확인 |
| 외부에 열린 WebDAV 포트 | 공유기 포트 포워딩과 외부 접속 확인 | 인터넷에서 직접 사용할 필요가 있는 서비스인지 검토 |
접속 실패가 많다는 사실만으로 침입 성공을 뜻하지는 않는다.
반대로 낯선 성공 로그인을 찾지 못했다고 침해가 없었다고 증명할 수도 없다.
기억나지 않는 관리자 계정이나 의심스러운 파일 변경까지 발견된다면 외부 접속을 제한하고 로그를 보존한 뒤 별도로 조사해야 한다.
실패 로그의 출발지가 공유기 주소로 찍혀 처음에는 공유기부터 의심했다.
내 경우에는 PC의 네트워크 드라이브 프로그램이 공인 주소로 접속하면서 예전 비밀번호를 반복해서 보내고 있었다.
공유기를 돌아 들어오는 접속이 공유기 주소로 보였던 것이다.
규칙적인 간격은 원인을 찾는 단서였다.
주기만 보고 봇이나 침입으로 단정하지 말고, PC의 자동 연결과 저장된 자격 증명, 공유기의 NAT 처리도 함께 확인해야 한다.
보안 설정을 한꺼번에 바꾸면 문제가 생겨도 원인을 찾기 어렵다.
나는 이메일 알림을 먼저 설정하고, 본인 계정의 인증을 등록한 다음 방화벽과 외부 노출을 정리했다.
원격에서 작업한다면 내부망으로 돌아올 수 있는 방법과 기존 관리자 세션을 확보한 뒤 진행하는 편이 좋다.
| 순서 | 작업 | 확인 기준 |
|---|---|---|
| 1 | 알림과 복구 수단 준비 | 테스트 알림 수신, 계정 이메일과 복구 방법 확인 |
| 2 | 내 관리자 계정에 2단계 인증 등록 | 새 창에서 비밀번호 다음 인증 단계가 나오는지 확인 |
| 3 | 다른 관리자 계정에 적용 범위 확대 | 각 사용자의 등록과 복구 준비 후 그룹 정책 적용 |
| 4 | 방화벽과 공유기 설정 정리 | 현재 관리 접속을 허용한 뒤 공개 서비스와 거부 정책 적용 |
| 5 | 자동 차단·계정 보호 확인 | 실패 횟수 기준과 정상 사용자 차단 해제 방법 확인 |
| 6 | DSM·패키지 업데이트 후 재검증 | 웹사이트, 파일 접속, 알림과 백업 상태 확인 |
DSM의 관리자 2단계 인증 강제 설정은 제어판 → 보안 → 계정에서 확인할 수 있다.
Synology 계정 보안 안내와 Secure SignIn 시작 안내를 기준으로, 알림 발송 설정과 개인 계정 이메일·긴급 인증 수단을 구분해 확인했다.
이메일 알림이 모든 인증 방식의 공통 전제라고 보면 안 된다.
내가 가장 크게 오해한 부분은 방화벽이었다.
활성화 체크만 보고 외부 접속도 막히겠거니 생각했다.
실제로는 어떤 출발지가 어떤 포트에 접근할 수 있는지, 아무 규칙에도 맞지 않았을 때 어떻게 처리하는지까지 정해야 한다.
2026년 11월 8일 확인한 DSM 방화벽 공식 문서는 우선순위에 따라 먼저 일치한 규칙을 적용하고, 일치 항목이 없으면 인터페이스의 기본 동작을 사용한다고 설명한다.
따라서 규칙이 비어 있다는 이유만으로 무조건 전체 허용이라고 단정할 수는 없다.
당시에는 대한민국 출발지를 허용하는 규칙도 사용했다.
다만 국가 제한은 IP의 위치 분류에 따른 보조 수단이다. 국내 IP나 VPN을 통한 시도까지 구분하지 못하므로, 관리 화면의 직접 노출을 줄이고 내부망·VPN 등 필요한 경로를 먼저 검토하는 편이 좋다.
방화벽을 바꾼 뒤 웹사이트가 열리지 않았다.
같은 날 DSM도 업데이트해서 처음에는 업그레이드부터 의심했다.
내 환경은 NAS의 nginx가 Docker 컨테이너로 요청을 넘기는 구조였고, 방화벽의 거부 정책과 컨테이너 통신 경로를 확인해야 했다.
내 경우에는 특정 대역을 허용하자 사이트가 다시 열렸다.
다만 이 범위 전체가 Docker 전용 네트워크인 것은 아니다.
다른 환경에서 그대로 복사할 설정값으로 쓰면 허용 범위가 지나치게 넓어질 수 있다.
Container Manager나 Docker 네트워크 설정에서 실제 사용하는 서브넷부터 확인해야 한다.
또한 포트를 공개한 컨테이너는 Docker가 만드는 방화벽·NAT 규칙의 영향을 받는다.
DSM 규칙만으로 모든 컨테이너 접근이 통제된다고 가정하지 말고, 포트 매핑과 외부 접속을 함께 확인해야 한다.
이 부분은 Docker의 방화벽 문서와 포트 공개 문서를 함께 참고했다.
나는 DSM 7.1에서 7.4로 올린 뒤 예전 PHP 패키지가 지원되지 않는 상태와 MariaDB의 수리 필요 표시를 만났다.
Web Station에 남아 있던 예전 사이트를 확인하는 계기가 됐다.
이 버전 경로를 다른 NAS에 그대로 적용할 수 있다는 뜻은 아니다.
Synology는 PHP 7.3·7.4·8.0 지원 종료 공지에서 DSM 7.3에 대한 영향을 안내하고 있다.
Web Station으로 사이트를 운영한다면 업그레이드 전에 해당 모델의 릴리스 노트, 사이트의 PHP 호환성, 필요한 확장과 데이터베이스 백업을 확인해야 한다.
패키지에 수리 표시가 뜨더라도 데이터가 포함된 패키지를 바로 지우지는 않는 편이 좋다.
DSM의 라우터 구성 화면은 공유기의 UPnP를 이용하는 방식이다.
공유기에서 UPnP를 사용하지 않으면 DSM 화면에서 설정이 실패할 수 있다.
그 오류만 보고 외부 포트가 모두 닫혔다고 판단하면 안 된다.
실제 공유기의 수동 포트 포워딩 목록을 따로 확인해야 한다.
Synology의 라우터 구성 문제 해결 안내도 호환되지 않는 환경에서는 공유기에서 직접 포트 포워딩을 설정하는 방법을 설명한다.
내가 사용하지 않는 관리 포트와 파일 서비스 포트가 남아 있는지 이쪽에서 다시 살폈다.
내 경우에는 업그레이드 뒤 QuickConnect가 비활성화되어 모바일 앱 접속도 확인해야 했다.
QuickConnect 사용 여부와 직접 포트 포워딩은 별도로 점검할 항목이다.
인증서도 접속할 주소와 일치하는지 살펴보고, 브라우저의 인증서 경고를 계속 무시하는 방식으로 해결하지 않는다.
자동 차단은 같은 IP의 반복 실패를 줄이는 데 도움이 되지만, 출발지를 나눠 시도하는 공격을 전부 막지는 못한다.
정상 사용자를 잘못 차단했을 때 해제할 방법과 저장된 옛 비밀번호를 보내는 앱도 함께 확인해야 한다.
지원되는 서비스에서는 계정 보호도 함께 확인할 수 있다.
IP 기준 차단과 계정 기준 보호의 적용 대상은 다르므로 DSM 보안·로그인 보호 사양을 확인하면 도움이 된다.
중요한 공유 폴더에는 스냅샷과 별도 백업도 필요하다.
Snapshot Replication은 모델과 파일 시스템 등의 조건을 확인해야 하며, 같은 NAS 안의 스냅샷만으로 별도 백업을 대신할 수는 없다.
Synology 백업 안내를 참고해 외부 장치나 다른 위치의 사본, 실제 복원 확인까지 함께 준비하면 좋다.
나처럼 설정을 해 두고 잊어버렸다면 방화벽 규칙 목록부터 다시 열어 볼 만하다.