▸ 제어판 > 정보센터 > 장치분석/공유기 네트워크 위치

 

애플의 AFP 지원 중단과 관련해 최근 macOS Tahoe 26.6.2 업데이트 이후 “서버에 연결” 이 안된다는 문의가 몇건 있었습니다. 확인결과 단순한 네트웍 문제 였으나 애플의 갑작스런 중단이 있을 경우 다음의 방법으로 접속 하시면 외부망 접속에 문제는 없을듯 합니다. 다만 AFP 접속과 사용때 보다 고용량 또는 동영상이나 큰 파일 사용시 AFP 에 비해 속도가 살짝 느리게 느껴 질 수 있으나 일반 사용에는 그렇게 큰 차이를 느끼지 않으실걸로 생각이 듭니다.

# AFP 대체 접속방법

윈도우 에서 RaiDrive 접속환경과 동일한 주소/포트를 사용하면 되므로 이미 설정이 되어 있는 회원(사) 께서는 ①~② 단계를 건너뛰고, 바로 서버연결 설정만 하시면 바로 접속이 되실 것 입니다.

① DSM > 패키지 센터 > webDAV Server > 설정/HTTPS 활성화 체크 / 포트입력

webDAV Server 가 설치가 안되어 있다면 모든 패키지 에서 설치 하시면 됩니다.  HTTP 는 가능하면 사용하지 마시고 HTTPS 만 사용하시면 됩니다. 포트를 입력하기전 사용중인 공유기에서 포트를 먼저 열어주시고 해당 포트를 넣어 주시면 됩니다.

② 제어판 > 파일서비스 > SMB/SMB 서비스 활성화 체크.......   그리고 권한이 없는 사용자로부터 공유 폴더 숨기기 체크 하셔야 최상위 폴더도 보이지 않으니 꼭 체크해 주세요.

 

③ Mac 에서 키보드 ( command+k) 누르면 아래 와 같이 서버에 연결이 뜹니다. 주소줄에 https://등록하신 DDNS 주소 또는 도메인 입력후:포트번호 입력 하시고 연결 누르시면 접속이 됩니다.

 

#AFP란 

AFP(Apple Filing Protocol)는 애플이 맥(macOS) 및 윈도우/NAS 등과의 네트워크 파일 공유 및 전송을 위해 자체 제작했던 네트워크 파일 공유 프로토콜입니다.

애플은 2013년 OS X 10.9 Mavericks 부터  기본(Default) 파일 공유 프로토콜을 AFP 에서 업계 표준인 SMB 2로 변경 하면서 AFP 중단을 서서히 시작 하였습니다.  그리고 2020년 macOS 11.0 Big Sur 에서 AFP 서버 기능이 공식 제거 하였습니다. 이 시점부터 맥 자체가 서버가 되어 파일 공유를 제공할 때 AFP를 사용할 수 없게 되었으며, APFS 포맷 볼륨 공유에서도 AFP 지원이 제외되었습니다.   Synology, QNAP 등 나스 파일 서버에 클라이언트로 접속하는 AFP 연결 기능 역시 차기 최신 macOS 및 NAS OS 업데이트 를 통해 단계적으로 완전 폐기(Deprecated) 단계에 진입하고 있습니다.  

#궁금하신 관련문의 사항은 070-8890-0504 로 문의 주시면 상세히 안내해 드립니다.

 

# DSM 7.4 업그레이드 후 NPM 뒤에서 운영되는 접속 로그  보안 플러그인 및 방문자 통계 도구 에서 공통 으로 발생하는 네트워크 계층 문제

고객사 에서 기존에 WebStation를 통해 웹사이트를 운영 하던중 DSM 7.4 업그레이드 이후 php7.4 미지원 으로 Docker 기반 웹서비스로 전환한 작업을 완료한 이후 발생한 외부 방문자의 실제 공인 IP가 웹서버까지 전달되지 않고 Docker 게이트웨이 주소인172.*.*.*로 기록되는 문제가 확인이 되었습니다. 이를 해결한 내용을 회원(사) 포함 공개로 전환해 공유 합니다.  본 문제는 발생은 Docker bridge를 통과하면서 실제 IP가 172.*.*.*로 바뀌어 하나로 표시 되는 문제로 그누보드, WordPress, PHP 자체 제작 사이트, Laravel·Node.js 등의 웹 애플리케이션, Immich 등... 각종 관리자 페이지와 API Nginx·Apache 접속 로그 보안 플러그인과 방문자 통계 도구 등 모두 영향을 받게 됩니다.

★ 확인 결과 Docker bridge 포트 전달 계층이 문제 였습니다.

외부 방문자

→ 공유기

→ NAS의 Docker 게시 포트

→ docker-proxy / bridge NAT

→ NPM

→ 내부 웹서버

1. 해결을 위해 host 네트워크의 HAProxy를 입구에 추가하고, 원본 IP를 PROXY protocol로 기존 NPM에 전달하도록 구성했습니다.

외부 방문자

→ host 모드 HAProxy

→ PROXY protocol

→ 기존 bridge 모드 NPM

→ Docker Nginx

→ PHP·그누보드

결과적으로 실제 방문자 IP 보존과 헤더 위조 차단을 모두 달성했습니다.

2. 기존 운영 구성

외부 요청은 다음과 같이 전달되고 있었습니다.

공유기 외부 80  → NAS 8080 → NPM 80

공유기 외부 443 → NAS 4443 → NPM 443

[ NPM 구성 ]

항목 - 기존설정

이미지 - jc21/nginx-proxy-manager:2.15.1

네트워크 - proxy-netbridge

관리 포트 - 81:81

HTTP - 8080:80

HTTPS - 4443:443

데이터 - /volume1/docker/npm/data

인증서 - /volume1/docker/npm/letsencrypt

웹사이트와 SSL은 모두 정상이었지만 NPM이 받는 접속자의 주소가 실제 공인 IP가 아닌 172.*.*.*로 바뀜

3. 문제의 영향

웹사이트 서비스 자체에는 장애가 없었지만 다음 기능의 신뢰도가 떨어졌습니다.

• 관리자 페이지와 API Nginx·Apache 접속 로그 보안 플러그인과 방문자 통계 도구에 실제 방문자 IP 기록
• IP 기준 중복 방문자 판별
• 관리자 접속자 현황
• 공격자 및 비정상 접속 추적
• IP 차단과 접근 제어
• 국가·지역 기반 통계
• 보안 로그 분석

즉, 사이트는 정상적으로 열리지만 방문자 식별과 보안 기록이 부정확한 상태

4. 단순 헤더 설정으로 해결되지 않은 이유

일반적으로 다음 헤더를 사용해 실제 IP를 전달

proxy_set_header X-Real-IP $remote_addr;

proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

그러나 현재 환경에서는 NPM이 요청을 받기 전에 실제 IP가 이미 172.*.*.*로 변환됨

실제 IP

→ Docker 포트 전달 과정에서 172.*.*.*로 변경

→ NPM이 172.*.*.*만 인식

따라서 NPM이 전달할 수 있는 $remote_addr자체가 잘못된 상태였습니다. 

사라진 원본 IP는 Nginx나 PHP 설정만으로 복구할 수 없습니다.

또한 외부에서 다음 헤더를 임의로 보내는 테스트도 진행해 보았습니다.

X-Real-IP: 203.*.***.**

X-Forwarded-For: 198.**.***.**

기존처럼 전달 헤더를 무조건 신뢰하면 방문자가 가짜 IP를 기록하게 만들 수 있으므로 보안상 사용할 수 없었습니다.

5. host 모드 가능성 검증

운영 NPM을 바로 변경하지 않고, host 네트워크에서 18080포트로 동작하는 일회용 Nginx를 생성

LAN 테스트

Mac에서 접속한 결과:

192.168.*.102

Docker 게이트웨이가 아닌 Mac의 실제 내부 IP가 기록됐습니다.

5G/LTE 외부 테스트

스마트폰 Wi-Fi를 끄고 5G/LTE로 접속한 결과:

106.***.*.***

NAS의 공인 IP는 확인 결과 다음과 같았습니다.

211.***.**.***

테스트 Nginx 로그에는 스마트폰 LTE/5G의 실제 공인 IP인 106.***.*.***가 정확하게 기록됨을 확인 !!!!!!!!!!!!!!!!!!

이를 통해 다음 사실이 확인 되었습니다~~

• DSM 7.4가 원본 IP를 무조건 제거하는 것은 아님
• NAS 본딩이 원인은 아님
• host 네트워크에서는 원본 IP가 보존됨
• 실제 IP 손실은 Docker bridge 게시 포트 경로에서 발생

6. NPM 자체를 host 모드로 변경하지 않은 이유

NPM은 컨테이너 내부에서 기본적으로 다음 포트를 사용합니다.

80

81

443

하지만 NAS의 80/443은 DSM 시스템 nginx가 사용하고 있었습니다.

/usr/bin/nginx -c /etc/nginx/nginx.conf.run

DSM 시스템 nginx는 다음 기능과 연관될 수 있습니다.

• Web Station
• DSM 역방향 프록시
• Immich 테스트용 역방향 프록시
• Synology 웹 패키지
• MailPlus 웹 접속
• 인증서와 로그인 포털

따라서 NPM 자체를 host 모드로 바꾸면 DSM nginx와 포트 충돌이 발생합니다.

또한 host 모드 NPM은 기존 proxy-net의 Docker DNS와 컨테이너 이름 연결을 잃을 수 있습니다.

A사이트-nginx

B사이트-nginx

C사이트_server

이런 내부 컨테이너 이름을 계속 사용하려면 NPM은 기존 bridge 네트워크에 남아 있는게 안전하다는 판단.

7. 최종 해결 구조

NPM 앞에 host 네트워크의 HAProxy를 추가했습니다.

인터넷

→ 공유기

→ host 모드 HAProxy

→ PROXY protocol

→ bridge 모드 NPM

→ Docker 웹서버

▸ 포트 구성은 다음과 같이 변경 하였습니다.

 

NPM의 HTTP·HTTPS 포트는 이제 NAS 외부나 LAN에서 직접 접근할 수 없고, 로컬 HAProxy만 접근할 수 있습니다.

이 구조는 위조된 " PROXY protocol 요청이 외부에서 NPM으로 직접 들어오는 것도 막아줍니다. "

8. HAProxy 역할  ★★★★★

HAProxy는 HTTP나 HTTPS 내용을 수정하거나 인증서를 관리하지 않습니다.

주요 역할은 두 가지입니다.

1. host 네트워크에서 실제 외부 IP를 직접 수신
2. 원본 IP를 PROXY protocol v2에 넣어 NPM으로 전달

HTTP 경로:

HAProxy :8080

→ 127.*.*.*:18080

→ NPM :80

HTTPS 경로:

HAProxy :4443

→ 127.*.*.*:18443

→ NPM :443

HTTPS 암호화 종료, 인증서 선택, 도메인 분기, Force SSL 등의 기존 기능은 계속 NPM이 담당합니다.

9. NPM 변경 사항

NPM 2.15.1의 기본 템플릿은 다음과 같이 동작합니다.

listen 80;

listen 443 ssl;

real_ip_header X-Real-IP;

전용 이미지를 생성해 다음과 같이 변경했습니다.

listen 80 proxy_protocol;

listen 443 ssl proxy_protocol;

real_ip_header proxy_protocol;

패치 대상:

/app/templates/_listen.conf

/app/templates/default.conf

/app/templates/letsencrypt-request.conf

/etc/nginx/conf.d/default.conf

/etc/nginx/nginx.conf

기존에 생성돼 있던 NPM Proxy Host 설정도 시작 스크립트에서 자동 변환하도록 구성했습니다.

따라서 다음 상황에서도 PROXY protocol 설정이 유지됩니다.

• NPM 컨테이너 재생성
• NAS 재부팅
• Proxy Host 수정 및 저장
• 새로운 Proxy Host 생성
• Let’s Encrypt 인증서 발급·갱신
• 기본 호스트 응답

10. 주요 파일 위치

/volume1/docker/npm/compose.yaml

/volume1/docker/npm/compose.proxyproto.yaml

/volume1/docker/npm/haproxy/haproxy.cfg

/volume1/docker/npm/proxyproto/Dockerfile

/volume1/docker/npm/proxyproto/proxyproto-entrypoint.sh

/volume1/docker/npm/data

/volume1/docker/npm/letsencrypt

전환 전 백업:

/volume1/docker/npm/backups/manual/

NPM 폴더 전체가 Hyper Backup 대상이므로 새 HAProxy 설정과 전용 이미지 파일도 함께 백업됩니다.

11. 최종 검증 결과

전체 도메인

A사이트 :  HTTP=200

B사이트 :  HTTP=200

C사이트 :  HTTP=200

D사이트 :  HTTP=200

컨테이너

npm          running / healthy

npm-haproxy  running / healthy

실제 5G/LTE IP 전달

NPM 로그:

[Client 106.***.*.***]

내부 웹서버 로그:

106.***.*.***

두 계층에 동일한 LTE 공인 IP가 기록됐습니다.

IP 위조 테스트

요청에 가짜 헤더를 포함했습니다.

X-Real-IP: 203.0.113.77

X-Forwarded-For: 198.51.100.88

결과:

NPM:        127.*.*.*

내부 Nginx: 127.*.*.*

가짜 IP는 모두 무시되고 PROXY protocol이 전달한 실제 접속 주소만 사용됐습니다.

Nginx 설정 검사

syntax is ok

test is successful

PROXY protocol이 누락된 80/443수신 설정도 존재하지 않습니다.

12. 운영 시 주의사항  ★★★★★

공유기 포트포워딩 유지

다음 설정을 그대로 유지해야 합니다.

외부 80  → NAS 8080

외부 443 → NAS 4443

NPM 내부 포트를 직접 외부에 공개하지 않기

다음 포트는 반드시 loopback 상태를 유지해야 합니다.

127.*.*.*:18080

127.*.*.*:18443

외부 또는 LAN 전체에 공개하면 PROXY protocol 위조 가능성이 생길 수 있습니다.

▸ NPM 버전 업그레이드

이번 작업한 회원사 전용 이미지는  Nginx Proxy Manager 2.15.1 버전에 맞춰져 있습니다.

향후 NPM을 업데이트할 때 원본 이미지만 바로 교체하면 절대!!!!!!  안 됩니다. 새 버전에서 다음 항목을 먼저 확인해야 합니다.

• NPM 템플릿 경로 변경 여부
• listen구문 변경 여부
• nginx.conf구조 변경 여부
• Let’s Encrypt 임시 설정 변경 여부
• 전용 Dockerfile 재빌드
• 독립 테스트 컨테이너 검증
• 실제 전환 전 백업

그리고 장애 시 우선 확인 확인 할 부분......

cd /volume1/docker/npm

docker compose ps

docker logs --tail 100 npm

docker logs --tail 100 npm-haproxy

docker exec npm nginx -t

포트 확인:

netstat -lntp |

grep -E ':(81|8080|4443|18080|18443) '

13. 최종 마무리를 하면서...

이번 고객사 웹사이트 문제는 단순 Nginx 헤더 수정으로 해결 할 수 있는 문제가 아니었습니다.  

실제 IP가 NPM에 도달하기 전에 Docker bridge 계층에서 이미 사라졌기 때문입니다.

해결의 핵심은 다음 세 가지였습니다.

1. host 모드에서 실제 공인 IP가 보존되는지 확인
2. NPM을 host 모드로 바꾸지 않고 HAProxy만 host 모드로 운영
3. 신뢰할 수 있는 PROXY protocol을 사용해 기존 NPM으로 원본 IP 전달 

 

 

 

 

 

▸ 주요 특징 및 감염 대상

- 감염 규모: 현재 전 세계 4,000대 이상의 구형 라우터를 감염시켰으며, 피해 기기의 약 48.5%가 한국에 집중된 것으로 나타났습니다.

- C 기반 변종: 성능이 낮은 구형 라우터를 주로 겨냥합니다.

- Go 기반 변종: NAS(네트워크 결합 스토리지) 시스템을 타깃으로 하며, IP 및 DNS 스캐닝, 내부 네트워크 정찰 등 고급 침투 기능을 수행합니다.

▸ 대응 및 예방 수칙

- 장비 교체: 수명이 종료된(EOS) 구형 라우터 및 NAS는 보안 업데이트가 지원되지 않으므로 최신 기기로 교체해야 합니다.

- 설정 변경: 교체가 어려운 경우 최신 펌웨어를 적용하고, 관리자 계정의 비밀번호를 강력한 고유 문자열로 변경합니다.

- 기능 차단: 외부에서 접속 가능한 원격 관리 패널 및 인터넷 노출 관리 페이지 기능은 비활성화해야 합니다. (예: ipTIME 의 경우 공유기 접속/보안관리 메뉴 에서 활성화 여부 확인)

 

지원이 종료된 구형 디링크(D-Link) 공유기 수천 대를 감염시켜 해커의 공격 중계 서버로 이용하는 신종 봇넷이 발견됐다. 확인된 감염 장비의 절반 가까이가 한국에 있는 것으로 조사돼 국내 이용자의 점검이 필요하다.

치안신 엑스랩은 지난 6월 17일 공개한 분석에서 ‘아리스팅어(AryStinger)’로 이름 붙인 악성코드가 전 세계 공유기 최소 4,300대를 감염시켰다고 밝혔다. 이 수치는 구형 RTL819X 계열 칩을 사용한 공유기만 집계한 결과다. 별도로 발견된 네트워크 저장장치(NAS) 감염 규모는 포함되지 않았다.

엑스랩은 3월 12일 인터넷 위협 탐지 과정에서 아리스팅어를 처음 확인했다. 공격자는 CVE-2013-3307과 CVE-2016-5681 등 오래전에 공개된 취약점을 이용해 공유기를 감염시켰다. 4월 26일에는 CVE-2025-11837을 악용해 NAS를 공격하는 변종도 포착됐다.

주요 감염 제품은 디링크 DIR-850L과 DIR-818LW였다. 전체 감염 장비 중 DIR-850L이 75%, DIR-818LW가 13%를 차지했다. DIR-816L, DIR-818L, DWR-118, DIR-817LW 등 다른 구형 제품에서도 감염 흔적이 발견됐다.

국가별로는 한국이 48.45%로 가장 높은 비중을 차지했다. 중국은 31.82%, 스웨덴은 6.4%, 말레이시아는 3.5%, 싱가포르는 2.5%로 집계됐다. 감염 장비 두 대 중 한 대가 한국에 있는 셈이다.

아리스팅어는 일반적인 디도스 공격용 봇넷과 작동 목적이 다르다. 감염된 공유기를 인터넷과 내부망을 조사하는 정찰 거점이자 공격 트래픽을 우회하는 프록시 서버로 사용한다. 공격자는 자신의 실제 인터넷 주소와 위치를 숨긴 채 감염 장비를 통해 다른 시스템을 스캔하거나 침입을 시도할 수 있다.

감염된 각 장비는 공격 명령을 수행하는 ‘실행기’ 역할을 한다. 공격자는 대규모 인터넷 조사 작업을 여러 개의 작은 작업으로 나눈 뒤 감염 장비에 분산시킨다. 수천 대의 공유기가 서로 다른 인터넷 주소와 도메인을 동시에 조사하기 때문에 짧은 시간 안에 공격 대상을 찾을 수 있다.

악성코드는 감염 장비의 맥 주소, 장치 이름, 공인·사설 인터넷 주소, 운영체제 버전, CPU 구조 등 시스템 정보를 수집해 명령제어 서버로 전송했다. 이후 장비별 식별번호를 부여받고 새로운 작업 명령을 기다렸다.

공격자는 공유기에 드롭베어(Dropbear) 경량 SSH 서버를 설치해 지속적인 원격 접속 통로도 만들었다. 방화벽 설정을 변경해 특정 포트를 열고, 공유기가 재부팅되거나 네트워크 환경이 달라진 뒤에도 원격 제어를 이어갈 수 있도록 설계했다.

아리스팅어는 감염 공유기를 이용한 트래픽 중계와 터널링 기능도 제공했다. 이를 이용하면 공격자가 발생시킨 악성 트래픽이 피해자의 공유기에서 나온 것처럼 보이게 할 수 있다. 수사기관이나 보안업체가 실제 공격자를 추적하기 어렵게 만드는 수법이다.

사용자에게 직접적인 피해를 줄 수 있는 기능도 확인됐다. 공격자가 공유기의 DNS 설정을 바꾸면 이용자가 정상적인 인터넷 주소를 입력해도 피싱 사이트나 악성코드 유포 페이지로 이동할 수 있다. 공유기를 통과하는 인터넷 트래픽을 감시해 계정 정보와 내부 통신 내용을 수집할 가능성도 있다.

NAS를 겨냥한 표준형 변종은 구형 공유기용 악성코드보다 기능이 많았다. 고(Go) 언어로 제작됐으며 IP·DNS·웹서비스 검색과 내부망 정찰, 원격 명령 실행, 추가 악성코드 실행 기능을 갖췄다.

공격자는 에프스캔(Fscan), 케이서브도메인(Ksubdomain), 에이치티티피엑스(Httpx), 티엘에스엑스(Tlsx) 등 공개 보안 점검 도구를 악성코드에 결합했다. 감염된 NAS를 통해 내부 시스템과 실행 중인 서비스, 열린 포트, 취약점을 조사한 뒤 결과를 외부 서버로 전송했다.

NAS 변종은 셸 명령뿐 아니라 고, 자바, 파이썬 소스코드도 내려받아 실행할 수 있었다. 운영체제와 장비 구조에 맞춰 별도의 실행파일을 만들지 않고 공격 기능을 바꿀 수 있다는 의미다. 다만 장비에 해당 언어 실행 환경이 없으면 추가 설치가 필요하고, 명령과 파일 흔적이 남아 탐지될 가능성이 커진다.

아리스팅어의 DNS 검색 기능이 대량의 질의를 발생시키는 디도스 공격에 사용될 가능성도 제기됐다. 실제 DNS 공격에 사용된 흔적은 확인되지 않았다.

주요 감염 제품은 이미 제조사의 지원이 끝난 상태다. 디링크는 DIR-818L과 DIR-818LW 지원을 2017년 종료했으며, DIR-850L도 지원 종료 제품으로 분류했다. 지원이 끝난 제품은 새로운 취약점이 발견돼도 보안 업데이트를 받기 어렵다.

DIR-850L과 DIR-818LW는 과거 에이브이레콘(AVrecon) 악성코드에도 감염됐던 제품이다. 디링크는 2026년 3월 24일 미국 연방수사국(FBI)의 경고 내용을 인용해 이들 공유기가 주거용 프록시 서버로 악용되고 있다며 제품 교체를 권고했다.

단순 재부팅만으로 악성코드가 제거됐다고 판단해서는 안 된다. 공격자가 펌웨어를 변조하거나 업데이트 기능을 끈 경우 감염 상태가 유지될 수 있다. 관리자 비밀번호 변경과 초기화만으로 문제를 해결하기 어려운 이유다.

해당 제품을 사용하는 가정과 기업은 먼저 모델명과 펌웨어 버전을 확인해야 한다. 지원이 끝난 공유기는 인터넷 연결을 해제하고 보안 업데이트가 제공되는 제품으로 교체하는 것이 안전하다.

즉시 교체하기 어렵다면 제조사가 마지막으로 제공한 펌웨어를 적용하고 관리자 계정에 강력한 고유 비밀번호를 설정해야 한다. 외부 원격 관리 기능과 인터넷에 노출된 관리 페이지는 꺼야 한다. 와이파이 암호도 기존 관리자 비밀번호와 다르게 설정할 필요가 있다.

아리스팅어를 운영하는 공격 조직은 아직 확인되지 않았다. 악성코드 통신에 ‘2024’라는 문자열이 포함돼 있지만, 실제 공격이 2024년부터 시작됐다는 증거는 발견되지 않았다. 현재 확인된 사실만으로 특정 국가나 해킹 조직과 연결하기는 어렵다.

출처 : 데일리시큐

러시아 연방보안국 제16센터, 취약한 라우터 검색해 설정파일 탈취

시스코 스마트 인스톨·SNMP·알려진 취약점 이용해 핵심 네트워크 침투

통신·에너지·금융·정부·의료기관에 장비 점검과 구형 프로토콜 차단 권고

 

러시아 정부와 연계된 해킹 조직이 전 세계에 노출된 라우터와 네트워크 장비를 공격해 주요 기반시설 내부망에 침투하고 있다는 공동 경보가 나왔다.

미국과 영국, 캐나다, 호주, 뉴질랜드를 비롯한 12개국 사이버보안·정보기관은 2026년 7월 13일 러시아 정부 지원 해킹에 대비한 네트워크 장비 보안 권고문을 공개했다. 이번 권고문 작성과 승인에는 18개 기관이 참여했다.

공동 권고문은 러시아 연방보안국(FSB) 제16센터 소속 해커들이 보안 설정이 미흡하거나 취약점이 남아 있는 네트워크 장비를 지속해서 공격하고 있다고 밝혔다. 특정 기관을 정해 침투하기보다 인터넷에서 취약한 장비를 대규모로 찾은 뒤 공격하는 방식이다.

주요 공격 대상은 통신, 방위산업, 에너지, 금융, 정부기관, 의료·공공보건 분야다. 정부기관 중에서는 보안 인력과 예산이 상대적으로 부족한 지방정부와 지역 공공기관이 특히 위험한 대상으로 지목됐다.

#기본 비밀번호 사용하는 SNMP 장비 집중 탐색

공격자는 단순 네트워크 관리 프로토콜(SNMP)이 외부에 노출된 인터넷 주소를 먼저 검색했다. 기본값이나 쉽게 추측할 수 있는 ‘커뮤니티 문자열’을 인증정보로 사용하는 장비가 주요 표적이었다.

커뮤니티 문자열은 SNMP 장비에 접근할 때 사용하는 일종의 공동 비밀번호다. 구형 장비에서는 ‘public’이나 ‘private’ 같은 기본값이 그대로 사용되는 사례가 많다. 외부에서 접속할 수 있고 쓰기 권한까지 허용돼 있으면 공격자가 라우터 설정을 바꾸거나 정보를 빼낼 수 있다.

러시아 해커들은 프록시 서버를 거쳐 출발지 주소를 위조한 SNMP 설정 요청을 보냈다. 요청에는 라우터가 자체 설정정보를 파일로 복사하도록 지시하는 객체 식별자(OID)가 포함됐다.

명령을 받은 장비는 설정정보를 ‘config.bkp’ 또는 ‘output.txt’와 같은 파일로 저장했다. 공격자는 해당 파일을 간이 파일 전송 프로토콜(TFTP)이나 파일 전송 프로토콜(FTP)을 통해 자신들이 관리하는 가상서버 또는 이미 장악한 서버로 전송했다.

라우터 설정파일에는 내부 네트워크 구성, 장비 계정, 접속정보, 암호화된 비밀번호, 관리 서버 주소 등이 포함될 수 있다. 공격자는 이를 분석해 내부망 구조를 파악하고 추가 침투 경로를 찾을 수 있다.

#시스코 장비 취약점과 관리 기능도 악용

공격자는 SNMP 설정 오류만 이용하지 않았다. 시스코(Cisco) 장비의 알려진 취약점과 시스코 스마트 인스톨(Cisco Smart Install) 기능, 네트워크 장비 관리용 웹 화면도 공격에 사용했다.

공동 권고문은 공격에 악용된 취약점으로 CVE-2018-0171과 CVE-2008-4128을 제시했다.

CVE-2018-0171은 시스코 스마트 인스톨 클라이언트 기능에서 발생하는 취약점이다. 공격자가 조작된 메시지를 보내 장비에 서비스 거부를 일으키거나 임의 코드를 실행할 수 있다.

CVE-2008-4128은 지원이 끝난 구형 시스코 장비에 영향을 주는 취약점이다. 장비를 교체하지 않고 계속 운영하는 조직이 공격에 노출될 수 있다.

러시아 연방보안국 제16센터와 연계된 활동은 보안업계에서 버서크 베어(Berserk Bear), 에너제틱 베어(Energetic Bear), 크라우칭 예티(Crouching Yeti), 드래곤플라이(Dragonfly), 고스트 블리자드(Ghost Blizzard), 스태틱 툰드라(Static Tundra) 등의 이름으로 추적돼 왔다.

기관들은 각 보안기업이 공격자를 분류하는 기준이 달라 이 명칭들이 모두 정확히 같은 조직을 뜻하는 것은 아니라고 설명했다.

이번에 공개된 공격 방식은 러시아 해킹 조직만 사용하는 기술도 아니다. 중국 연계 조직으로 지목된 솔트 타이푼(Salt Typhoon) 등 다른 국가 지원 해킹 조직도 인터넷에 노출된 라우터와 보안장비를 초기 침투 경로로 이용해 왔다. 공동 권고문은 이번 방어조치를 적용하면 유사한 공격을 함께 차단할 수 있다고 강조했다.

#SNMPv1·v2 끄고 관리 기능 외부 노출 차단해야

공동 권고문은 시스코 스마트 인스톨 기능을 사용하지 않는 장비에서는 즉시 비활성화하라고 권고했다.

SNMPv1과 SNMPv2도 사용을 중단하고 인증과 통신내용 암호화를 지원하는 SNMPv3로 전환해야 한다. SNMPv3는 ‘authPriv’ 방식과 장비가 지원하는 최신 암호화 알고리즘을 적용하는 것이 좋다.

업무상 구형 SNMP를 계속 사용해야 한다면 기본 커뮤니티 문자열을 모두 변경해야 한다. 쓰기 권한은 차단하고 읽기 전용 권한만 허용해야 한다. 접속 가능한 관리 장비와 주소도 접근제어목록(ACL)으로 제한해야 한다.

네트워크 장비의 로컬 계정에는 장비마다 다른 강력한 비밀번호를 설정해야 한다. 시스코 장비에서는 사용자 인증정보 보호에 해시 유형 8을 사용하고, 평문 저장이나 보호 수준이 낮은 유형 0·4·7은 피해야 한다.

일상적인 장비 관리는 중앙 인증 서버를 통해 처리하고, 로컬 계정 로그인은 비상 상황으로 제한해야 한다. 중앙 인증에는 가능한 경우 다중인증을 적용해야 한다. 평소 사용하지 않던 계정이나 조직의 계정 이름 규칙과 맞지 않는 인증정보가 발견되면 즉시 조사해야 한다.

#TFTP·SMI·SNMP 포트 인터넷 접근 제한

외부에서 접근할 필요가 없는 장비 관리용 포트도 차단해야 한다.

권고문은 TFTP에 사용하는 UDP 69번, 시스코 스마트 인스톨에 사용하는 TCP 4786번, SNMP에 사용하는 UDP 161·162번, SNMPv3에 사용하는 TCP·UDP 10161·10162번 포트를 인터넷에서 접근하지 못하도록 설정하라고 밝혔다.

업무상 포트를 열어야 한다면 허용된 관리 장비만 접속할 수 있도록 제한하고 통신기록을 집중 감시해야 한다. 관리 트래픽은 가능하면 일반 업무망과 분리된 별도 관리망에서 처리해야 한다.

SNMP 설정 요청 가운데 장비 설정파일 복사나 외부 전송을 지시하는 OID가 포함됐는지도 확인해야 한다. 침입탐지시스템(IDS)에 관련 탐지 규칙을 추가하면 공격자가 라우터 설정을 외부 서버로 보내려는 시도를 조기에 찾을 수 있다.

네트워크 장비의 소프트웨어와 펌웨어는 최신 상태로 유지해야 한다. 제조사 지원이 종료된 장비는 보안 업데이트를 받을 수 없으므로 현재 지원되는 제품으로 교체해야 한다.

인터넷에 노출된 장비를 파악하지 못하는 문제도 점검해야 한다. 공격표면관리(ASM) 도구 등을 이용해 외부에서 접근 가능한 라우터와 관리 화면, 열린 포트, 기본 비밀번호, 알려진 취약점을 정기적으로 확인할 필요가 있다.

라우터는 외부 인터넷과 내부 네트워크를 연결하는 핵심 장비다. 공격자가 라우터를 장악하면 정상적인 통신을 감시하거나 트래픽을 우회시키고, 내부 시스템 공격을 위한 발판으로 활용할 수 있다.

이번 공동 경보는 새로운 공격 기술보다 기본 설정 관리의 중요성을 다시 확인시켰다. 구형 SNMP, 기본 비밀번호, 불필요하게 열린 관리 포트, 지원이 끝난 장비를 그대로 두는 것만으로 국가 지원 해킹 조직에 내부망 진입 경로를 제공할 수 있다.

국내 보안담당자들도 인터넷에 노출된 라우터와 스위치, 방화벽 등 네트워크 장비를 다시 점검해야 할 상황이다.

SNMP v1·v2와 기본 커뮤니티 문자열 사용 여부를 확인하고, 가능한 장비는 인증과 암호화를 지원하는 SNMP v3로 전환해야 한다. 외부에서 접근할 필요가 없는 SNMP·TFTP·시스코 스마트 인스톨 포트는 차단하고, 장비 설정파일과 관리자 계정이 승인 없이 변경되지 않았는지도 살펴봐야 한다.

제조사 지원이 끝난 장비는 보안 패치를 받을 수 없기 때문에 교체 계획을 세워야 한다. 의심스러운 설정 변경이나 설정파일 외부 전송 기록이 발견되면 장비 한 대만 초기화하는 데 그치지 말고, 해당 장비를 거쳐 내부망까지 침투했는지 조사한 뒤 KISA 등 관계기관에 신고해야 한다.

출처 : 데일리시큐

네트워크에 연결된 장치와 서비스가 별도의 설정 없이 상호 자동으로 인식하고 통신할 수 있게 돕는 네트워크 프로토콜이며, 주로 UPnP 환경에서 활용됩니다.  시놀로지의 나스의 경우 초기 설치를 위해 기본 으로 활성화 되어 있습니다.  설치시 웹브라우저에 " find.synology.com " 으로 Windows 네트워크 홈 공간에서 시놀로지 NAS가 자동으로 검색 되도록 하기 위함 입니다.

 

▸ 주요 특징

- 자동 탐색 기능: DHCP나 DNS 서버 설정 없이 로컬 네트워크 내 장치(나스, 프린터, 공유기, 스마트 TV 등)를 쉽게 찾게 해줍니다.

- 동작 방식: 주로 UDP 포트 1900과 멀티캐스트 주소(239.255.255.250)를 사용해 메시지를 송수신합니다.

- 주요 메시지: 장치가 존재를 알리는 notify와 서비스를 찾는 M-search 방식을 사용합니다.

- 미디어 서버 (DLNA/UPnP 스트리밍)기능: 시놀로지 '미디어 서버' 패키지를 설치하면 내부적으로 SSDP 기능이 자동으로 활성화됩니다.

▸ 보안 취약점 (SSDP DDoS 공격)

- 반사 증폭 공격: 공격자는 취약점이 있는 SSDP 장비들을 악용해 출발지 IP를 위조한 요청을 보내고, 장비들로부터 수십 배 큰 응답 트래픽을 특정 피해자에게 집중시켜 서버를 마비시킬 수 있습니다.

- 대응 방안: 불필요한 외부망의 UDP 1900 포트 접근을 차단하고 공유기나 장비의 UPnP 기능을 점검이 필요 합니다.  시놀로지 나스 에서 이를 방지하기 위해 제어판 > 보안 > 보호 / 서비스 거부(Dos) 보호 / DoS 보호 활성화 를 반드시 활성화 시켜 주세요.

# 공유기가 바뀌더라도 이전 공유기의 IP를 그대로 사용려면?

인터넷 서비스 제공업체(ISP) KT, LG+, SKT 등은 모든 네트웍 장비는 각각의 식별번호인 MAC 주소를 가지고 있습니다.   DHCP 서버는 이 MAC 주소를 인식하여 유동 IP를 할당해 주며  할당된 IP는 수십일 또는 아주 특별한 경우를 제외하고 계속 유지되어 집니다.  만약 공유기를 오랫동안 꺼둔다면??  통신사 서버는 할당된 서버가 사용되지 않고 있다 판단하여 다른 사용자에게 할당하게 됩니다.

# 기존 공유기가 IP 사용하기 위한 설정방법

ipTIME 예시 (다른 회사 공유기도 거의 동일)

1.  먼저 사용하고 있는  공유기 접속 > 네트워크 관리 > 인터넷 설정 정보 > 외부 IP 주소 하단의 WAN MAC 주소 복사

2. 기존의 공유기 통신사 모뎀에서 분류 및 차단

3.  새공유기  접속 공유기 접속 > 네트워크 관리 > 인터넷 설정 정보 > 외부 IP 주소 하단의 WAN MAC 에 기존의 MAC 주소 붙여넣기

4. 통신사 모뎀 전원을 껀후 30초 쯤 지나 다시 켜기 

위의 단계데로 진행하면 기존에 사용했던 유동 IP 를 그대로 할당받아 사용이 가능합니다.   주의할점은 전원 종료후 너무 오랫동안 연결하지 않으면 위에 설명했든 IP를 다른 사용자 에게 할당하게 되므로 가능하면 최단시간에 진행 하시는게 좋습니다.

# 시놀로지 나스 맥(Mac) 에서 사용시 끊김 현상 해결 방법

▶︎ 2-1 DSM 접속 > 제어판 > 파일 서비스 > SMB / 고급설정 > " Opportunistic Locking 활성화 " 체크 해제

① PC 에서 설정방법 :  윈도우 시작 버튼 우클릭 > 장치 관리자 > 네트워크 어댑터/NSA와 직결된 랜카드 더블클릭 > 전원관리 / " 전원을 절약하기 위해 컴퓨터가 이 장치를 끌 수 있음 " 체크 해제

② Mac 에서 설정방법 :  시스템 설정 > 배터리/전원 > (맨하단)의  " 옵션... "  클릭 > " 디스플레이가 꺼져 있을 때 전원 어댑터 사용 시 컴퓨터를 자동으로 잠자지 않게 하기 " 체크 후 완료 클릭 

169.254.X.X 인터넷 공유기의 없이 DHCP 할당받지 못하는 상황에서 IP 표준(RFC 3927)의 기본 서브넷 마스크 255.255.0.0  으로 링크 로컬(Link-Local) IP를 자동 할당 받아 사용할때 무조건 하셔야 연결 끊김 없이 사용이 가능합니다.  간혹,  서브넷 마스크를 255.255.255.0 으로 해야 한다는 글들이 있지만 굳이 세번째를 255 로 맞춰주지 않아도 됩니다.  위의 제목처럼 공유기 유/무와 상관없이 다양한 환경에서 자동 접속이 되도록 사용자(클라이언트) PC/노트북에 DHCP 로 자동 할당 받도록 하는게 훨씬 편리 합니다.

★ 2대 이상의 나스, 서버 등등...  하나의 스위처에 모두 연결하고 하나의 케이블을 통해 멀리 떨어진 반대편 다른 스위처 에서 신호를 분리해 각각 접속할 때도 위의 서브넷 마스크를 활용/응용하여 작업하면 서로 다른 2대의 이상의 나스에 접속이 가능합니다.  단 CAT.6A 이상의 케이블과 10Gbps 를 지원하는 스위처를 사용해야 속도 저하 현상없이 사용이 가능합니다.

 

# 시놀로지 맥 연결끊김현상 해결 방법

# 시놀로지 윈도우 에서 연결 끊김현상 해결 방법

# 나스 연결 지속하게 하는 방법 

# 링크 로컬(Link-Local) IP 끊기지 않게 설정하기

1. 백업하려는 도메인의 자격 증명으로 Google Admin console에 로그인합니다.
2. 앱 > Google Workspace로 이동합니다.
   
3. 드라이브 및 문서를 클릭합니다.
   
4. 기능 및 응용 프로그램을 클릭합니다.
   
5. Drive SDK 섹션을 클릭하고 Drive SDK API로 사용자가 Google Drive에 액세스하도록 허용을 체크합니다. 저장을 클릭합니다.
   

2. 서비스 키 생성

1. 도메인 슈퍼 관리자로 Google Developers Console에 로그인합니다.
2. 팝업 창 오른쪽 상단에서 프로젝트 선택을 클릭한 후 새 프로젝트를 클릭합니다.¹
   
3. 프로젝트 이름을 입력하고 생성을 클릭합니다.
   
4. 방금 생성한 프로젝트를 엽니다.
   
5. 네비게이션 메뉴를 클릭하고 APIs & Services > 라이브러리로 이동합니다.
   
6. 다음 API를 검색하여 하나씩 활성화합니다: Admin SDK API, Google People API, Gmail API, Google Calendar API, Google Drive API.
   
7. 네비게이션 메뉴를 클릭하고 IAM & Admin > Service Accounts로 이동합니다.
   
8. + 서비스 계정 만들기를 클릭합니다.
   
9. 서비스 계정 이름을 입력하고 생성을 클릭합니다.
   
10. 역할로 프로젝트 > 소유자를 선택하고 계속을 클릭합니다.
    
11. 선택 필드는 생략하고 완료를 클릭합니다.
    
12. 서비스 계정 목록 페이지로 자동 이동합니다. 새로 생성된 계정을 찾습니다. 작업에서 을 클릭하고 키 관리를 선택합니다.
    
    아래와 같은 창이 나타나면, 스크린샷에 표시된 "비활성화" 링크를 클릭하거나 네비게이션 메뉴 > 조직 정책에서 서비스 계정 키 생성 비활성화를 찾아 정책을 비활성으로 설정합니다. 완료 후 Service Accounts 탭으로 돌아갑니다.
    
13. 키 추가 > 새 키 만들기를 클릭합니다.
    
14. 팝업 창에서 키 유형으로 JSON을 선택하고 생성을 클릭합니다.
    
15. 키가 자동으로 컴퓨터에 저장됩니다. 닫기를 클릭합니다.²
    
16. 세부정보로 이동하여 고유 ID를 복사해 Notepad에 붙여넣습니다.³
    
17. 백업하려는 도메인의 자격 증명으로 Google Admin console에 로그인합니다.
18. 보안 > 액세스 및 데이터 제어 > API 제어로 이동합니다.
    
19. 페이지 하단에서 도메인 전체 위임 관리를 클릭합니다.
    
20. 새로 추가를 클릭합니다.
    
21. 팝업 창에서 다음 정보를 입력하고 승인을 클릭합니다:
    • 클라이언트 ID: 16단계에서 복사한 고유 ID를 붙여넣습니다.
    • OAuth 범위: 아래 내용을 복사하여 붙여넣습니다:
      https://www.googleapis.com/auth/admin.directory.user, https://www.googleapis.com/auth/admin.directory.domain.readonly, https://www.googleapis.com/auth/drive, https://mail.google.com, https://www.googleapis.com/auth/calendar, https://www.googleapis.com/auth/contacts, https://www.googleapis.com/auth/contacts.other.readonly, https://sites.google.com/feeds, https://www.googleapis.com/auth/tasks
22. 이제 로컬에 저장된 키(14단계에서 생성됨)를 사용하여 Active Backup for Google Workspace에서 작업을 생성할 수 있습니다. 이 문서에서 단계별 안내를 제공합니다.

1. 물리적 케이블 연결 및 IP 설정

DSM 설정: 제어판 > 네트워크 > 네트워크 인터페이스

• LAN 1 (내부망): 공유기 또는 내부 네트워크 스위치에 연결 (예: 192.168.0.☐)

• LAN 2 (외부망): 공인 IP를 직접 받거나, 웹 서버용 DMZ 설정이 된 별도 포트에 연결 (예: 192.168.100.☐  또는 통신가 모뎀에서 공인 IP 바로 연결)

 

LG U+ 의 공유기 접속...  특별히 설정하신게 없다면 192.168.219.1 로 접속, DMZ 설정을 눌렀을때,