AskFront 포럼

@busker Ramdisk 자체는 그렇지만, Wget으로 긁어주는 것은, 캐시를 생성해 주기 위함입니다.
PHP를 사용하는 경우, FastCGI등을 사용하거등요 :)

일반 CDN을 사용할 때도 캐시를 생성해 줄만 합니다.
1순위도 캐시 2순위도 캐시입니다 :)

@busker 맞습니다.
미션크리티컬 하게 가용성이 중요한게 아니라면, 정상종료가 중요합니다.

@busker 님 안녕하세요!
가입 인사 카테고리는 아쉽게도 아직 없습니다.
조금 부끄럽기도 해서요.

@busker 님께 필요한 정보가 있는 포럼이 되도록 노력하겠습니다 :)

입동이 다가오고 있습니다.
늘 감기 조심하시고, 따뜻하게 입고 다니세요 :)
또한, 편안한 밤 보내시길 기원합니다.

감사합니다.

@imageschool 네 맞습니다. 보통 혼용해서 사용합니다. :)
IDE는 사용 안합니다 :) vscode가 IDE라면 사용하는 거겠네요 :)

@imageschool navystack으로 컨테이너 관리하다가 너무 복잡해져서, 컨테이너 용으로 github를 별도로 분리했습니다.
혹시 관련된 활용방법이 필요하시다면 https://github.com/netvpc 를 확인해보세요 :)

@imageschool 님 Traefik에서 신뢰할수 있는 프록시 옵션이 없어서 404를 반환한 것 같네요.
혹시 트래픽을 프록시 뒤에 배치할 때는 관련된 설정이 필요합니다.

트래픽과 관련된 오류는 아니었지만 잘 해결되어 다행입니다.

docker-compose로 개발할 때는 여러가지로 상황에 맞추어 진행하는 편입니다.

1. 번역을 할 때, 특정 파일만 수정해서 진행해야한다고 하면, 바인드 마운트를 바탕으로 컨테이너를 실시간으로 조정합니다. 이것 저것 개발 환경이라도 설치하기 귀찮기도 하고요. (그래서 대부분 제가 만든 컨테이너는 UID:PID 매핑이 되어있습니다.) 파일 권한 오류는 부차적인 옵션이구용
2. 동일한 의존성을 유지해야하거나, 특정한 오류를 감지해야한다면, 컨테이너를 사용하는 편입니다. (재현성)
3. 수정은 해야겠고 관련 의존성을 개발환경에 설치하기 싫을 때 사용합니다. docker exec를 사용해서 수정합니다.
4. 최종적으로 완성된 코드를 배포하는 용도로 사용을 합니다.

@imageschool 괜찮으시다면, 정보는 마스킹 하셔서 한번 docker-compose.yml 첨부 부탁드립니다.

또한 살짝 우려 되는 부분이

navystack - rhymix 질문 에서 @imageschool 님이 말했습니다:

lightsail instance 셋업 및 433 (udp/tcp), 80(tcp) port 열기

라고 하셨는데 443 포트가 맞는지 확인 부탁드립니다.

@imageschool 님 안녕하세요?
우선 많이 답답하셨을 것 같네요.

IP나 도메인으로 들어갔을 때,

이 페이지가 나온다는 말씀이신거죠?

라이믹스 컨테이너가 traefik-network로 올바르게 연결되었는지 확인한번 해보시겠어요?
트래픽 자체가 도커 네트워크를 활용하는 방법을 사용하기 때문에, traefik-network에 참여 되어있어야 합니다.

또한, 대시보드 페이지에서 올바르게 인식 되었는지 확인 가능합니다.

참고하신 문서는 Python기준이고, 사용하신 스크립트는 node.js 기반입니다.

Node.js는 기본적으로 설치되어있습니다.
재현이 안되는데, 로그 첨부부탁드립니다.

Intel의 그래픽 아키텍처는 CPU 내장 그래픽(iGPU)와 독립형 그래픽(dGPU)으로 나뉘며, 내장 그래픽은 주로 Intel Core 프로세서에 통합되어 있습니다. 최근에는 "Intel Arc"라는 이름으로 독립형 GPU도 출시되었습니다. 아래는 Intel의 그래픽 아키텍처 및 코덱 지원 현황을 정리한 것입니다.

1. Intel GPU 아키텍처 및 모델 정리

1.1. Intel 내장 그래픽 (iGPU) 아키텍처 및 모델

아키텍처	세대	내장 그래픽 모델	대표 CPU 시리즈	출시 연도
Ivy Bridge	3세대	Intel HD Graphics 2500 / 4000	Core i3-3xxx, i5-3xxx, i7-3xxx	2012
Haswell	4세대	Intel HD Graphics 4200 / 4400 / 4600	Core i3-4xxx, i5-4xxx, i7-4xxx	2013
Broadwell	5세대	Intel HD Graphics 5300 / 5500 / 6000	Core M-5xxx, i3-5xxx, i5-5xxx, i7-5xxx	2014-2015
Skylake	6세대	Intel HD Graphics 510 / 520 / 530	Core i3-6xxx, i5-6xxx, i7-6xxx	2015
Kaby Lake	7세대, 8세대	Intel UHD Graphics 620 / 630	Core i3-7xxx, i5-7xxx, i7-7xxx, i3-8xxx	2016-2018
Coffee Lake	8세대, 9세대	Intel UHD Graphics 630	Core i3-8xxx, i5-8xxx, i7-8xxx, i9-9xxx	2017-2019
Ice Lake	10세대	Intel Iris Plus Graphics G4 / G7	Core i3-10xx, i5-10xx, i7-10xx	2019
Tiger Lake	11세대	Intel Iris Xe Graphics	Core i3-11xx, i5-11xx, i7-11xx	2020
Alder Lake	12세대	Intel UHD Graphics 770 / 730	Core i3-12xx, i5-12xx, i7-12xx, i9-12xx	2021-2022
Raptor Lake	13세대	Intel UHD Graphics 770	Core i5-13xx, i7-13xx, i9-13xx	2022

1.2. Intel 독립형 그래픽 (dGPU) 아키텍처 및 모델 (Intel Arc 시리즈)

아키텍처	시리즈 세대	모델명	목표 시장	출시 연도
Alchemist	Intel Arc A 시리즈	Arc A380, A750, A770	게이밍, 콘텐츠 크리에이션	2022

2. Intel GPU 코덱 지원 현황

2.1. Intel 그래픽 코덱 지원 (아키텍처별)

아키텍처	H.264 인코딩/디코딩	H.265/HEVC 인코딩/디코딩	VP8 인코딩/디코딩	VP9 인코딩/디코딩	AV1 인코딩	AV1 디코딩
Ivy Bridge	✅ (디코딩)	❌	❌	❌	❌	❌
Haswell	✅ (디코딩)	❌	❌	❌	❌	❌
Broadwell	✅ 인코딩/디코딩	❌	❌	❌	❌	❌
Skylake	✅ 인코딩/디코딩	✅ 인코딩/디코딩	❌	❌	❌	❌
Kaby Lake	✅ 인코딩/디코딩	✅ 인코딩/디코딩	❌	✅ 디코딩 지원	❌	❌
Coffee Lake	✅ 인코딩/디코딩	✅ 인코딩/디코딩	❌	✅ 디코딩 지원	❌	❌
Ice Lake	✅ 인코딩/디코딩	✅ 인코딩/디코딩	❌	✅ 디코딩 지원	❌	❌
Tiger Lake	✅ 인코딩/디코딩	✅ 인코딩/디코딩	❌	✅ 인코딩/디코딩	❌	✅
Alder Lake	✅ 인코딩/디코딩	✅ 인코딩/디코딩	❌	✅ 인코딩/디코딩	❌	✅
Raptor Lake	✅ 인코딩/디코딩	✅ 인코딩/디코딩	❌	✅ 인코딩/디코딩	❌	✅
Alchemist	✅ 인코딩/디코딩	✅ 인코딩/디코딩	❌	✅ 인코딩/디코딩	✅	✅

참고: Intel Arc (Alchemist 아키텍처)는 AV1 인코딩 및 디코딩을 지원하는 최초의 Intel 독립형 그래픽 시리즈

1. NVIDIA GPU 아키텍처 및 모델 정리

1.1. 주요 GeForce GPU 아키텍처 및 모델

아키텍처	대표 시리즈	시리즈 세대	주요 모델	노트북 모델	출시 연도
Tesla	GeForce 8000, 9000	GeForce 8000, 9000	8800 GTX, 9800 GT	없음	2006-2008
Fermi	GeForce 400, 500	GeForce 400, 500	GTX 480, GTX 580	없음	2010-2011
Kepler	GeForce 600, 700	GeForce 600, 700	GTX 680, GTX 780 Ti	GTX 680M, GTX 780M	2012-2013
Maxwell	GeForce 900	GeForce 900	GTX 970, GTX 980 Ti	GTX 980M	2014-2015
Pascal	GeForce 10	GeForce 10	GTX 1080 Ti, GTX 1070	GTX 1080 Max-Q, GTX 1050 Ti	2016-2017
Turing	GeForce 16, RTX 20	GeForce 16, RTX 20	GTX 1660 Ti, RTX 2080 Ti	RTX 2070 Super Max-Q, GTX 1660 Ti	2018-2019
Ampere	GeForce RTX 30	GeForce RTX 30	RTX 3090, RTX 3080, RTX 3070	RTX 3080 Laptop, RTX 3060	2020-2021
Ada Lovelace	GeForce RTX 40	GeForce RTX 40	RTX 4090, RTX 4080, RTX 4070 Ti	RTX 4080 Laptop, RTX 4060	2022-현재

1.2. 주요 Quadro GPU 아키텍처 및 모델

아키텍처	대표 시리즈	시리즈 세대	주요 모델 (데스크탑)	노트북 모델	출시 연도
Tesla	Quadro FX 시리즈	Quadro FX 시리즈	Quadro FX 5800	없음	2008-2010
Fermi	Quadro 4000, 5000, 6000	Quadro 4000, 5000, 6000	Quadro 4000, Quadro 5000	Quadro 5010M	2010-2011
Kepler	Quadro K 시리즈	Quadro K 시리즈	Quadro K5000, K6000	Quadro K3100M, K5100M	2012-2013
Maxwell	Quadro M 시리즈	Quadro M 시리즈	Quadro M4000, M5000, M6000	Quadro M5000M, M3000M	2015-2016
Pascal	Quadro P 시리즈	Quadro P 시리즈	Quadro P4000, P5000, P6000	Quadro P4200, P3200	2017-2018
Turing	Quadro RTX 시리즈	Quadro RTX 시리즈	Quadro RTX 4000, RTX 5000, RTX 8000	Quadro RTX 3000, RTX 5000 Max-Q	2019-2020
Ampere	NVIDIA RTX 시리즈	NVIDIA RTX 시리즈	RTX A4000, RTX A5000, RTX A6000	RTX A3000, A2000	2021-현재

2. NVIDIA GPU 코덱 지원 현황

2.1. GeForce 및 Quadro 코덱 지원 (아키텍처별)

아키텍처	대표 시리즈	H.264 인코딩/디코딩	H.265/HEVC 인코딩/디코딩	VP8 인코딩/디코딩	VP9 인코딩/디코딩	AV1 인코딩	AV1 디코딩
Tesla	GeForce 8000, 9000 / Quadro FX 시리즈	❌ 디코딩만 지원	❌	❌	❌	❌	❌
Fermi	GeForce 400, 500 / Quadro 4000, 5000, 6000	❌ 디코딩만 지원	❌	❌	❌	❌	❌
Kepler	GeForce 600, 700 / Quadro K 시리즈	✅ 인코딩/디코딩 지원	❌	❌	❌	❌	❌
Maxwell	GeForce 900 / Quadro M 시리즈	✅ 인코딩/디코딩 지원	✅ 디코딩만 지원 (Maxwell 2세대)	❌	❌	❌	❌
Pascal	GeForce 10 / Quadro P 시리즈	✅ 인코딩/디코딩 지원	✅ 인코딩/디코딩 지원	❌	✅ 디코딩만 지원	❌	❌
Turing	GeForce 16, RTX 20 / Quadro RTX 시리즈	✅ 인코딩/디코딩 지원	✅ 인코딩/디코딩 지원	❌	✅ 인코딩/디코딩 지원	❌	❌
Ampere	GeForce RTX 30 / NVIDIA RTX 시리즈	✅ 인코딩/디코딩 지원	✅ 인코딩/디코딩 지원	❌	✅ 인코딩/디코딩 지원	❌	✅ 디코딩 지원
Ada Lovelace	GeForce RTX 40	✅ 인코딩/디코딩 지원	✅ 인코딩/디코딩 지원	❌	✅ 인코딩/디코딩 지원	✅	✅

참고: Ada Lovelace 아키텍처 기반의 GPU는 AV1 인코딩 및 디코딩을 모두 지원하는 최초의 NVIDIA 아키텍처

1. AMD APU 및 CPU 모델 목록

코드네임	모델명	코드번호	내장 그래픽 코드 네임
카베리 (Kaveri)	A10, A8, A6	-	Radeon R5/R7 시리즈
고다바리 (Godavari)	A10, A8, A6	-	Radeon R5/R7 시리즈
카리조 (Carrizo)	FX, A10, A8, A6	-	Radeon R5/R7 시리즈
브리스톨 릿지 (Bristol Ridge)	A12, A10, A8, A6	-	Radeon R5/R7 시리즈
레이븐 릿지 (Raven Ridge)	2400G, 2200G	2400G	Radeon RX Vega 11 Graphics
		2200G	Radeon RX Vega 8 Graphics
피카소 (Picasso)	3400G, 3200G	3400G	Radeon RX Vega 11 Graphics
		3200G	Radeon RX Vega 8 Graphics
르누아르 (Renoir)	4750G, 4650G, 4350G	4750G	Radeon Graphics (8 CU)
		4650G	Radeon Graphics (7 CU)
		4350G	Radeon Graphics (6 CU)
루시엔 (Lucienne)	5700U, 5500U, 5400U (노트북)	5700U	Radeon Graphics (8 CU)
		5500U	Radeon Graphics (7 CU)
		5400U	Radeon Graphics (6 CU)
세잔 (Cezanne)	5700G, 5600G, 5300G	5700G	Radeon Graphics (8 CU)
		5600G	Radeon Graphics (7 CU)
		5300G (OEM)	Radeon Graphics (6 CU)
바르셀로 (Barcelo)	5825U, 5625U, 5425U (노트북)	5825U	Radeon Graphics (8 CU)
		5625U	Radeon Graphics (7 CU)
		5425U	Radeon Graphics (6 CU)

2. 최신 AMD 내장 그래픽 코덱 지원 현황

내장 그래픽 코드 네임	코드네임 / 제품군	아키텍처	H.264/H.265/HEVC	AV1
Radeon Graphics (2 CU)	라파엘 (Raphael) (CPU)	RDNA2	인코딩/디코딩 지원	디코딩만 지원
Radeon 610M	드래곤 레인지 (Dragon Range), 렘브란트 (APU)	RDNA2	인코딩/디코딩 지원	디코딩만 지원
Radeon 660M	렘브란트 (Rembrandt) (APU)	RDNA2	인코딩/디코딩 지원	디코딩만 지원
Radeon 740M	피닉스 (Phoenix) (APU)	RDNA3	인코딩/디코딩 지원	인코딩/디코딩 지원
Radeon 760M	피닉스 (Phoenix) (APU)	RDNA3	인코딩/디코딩 지원	인코딩/디코딩 지원
Radeon 780M	피닉스 (Phoenix) (APU)	RDNA3	인코딩/디코딩 지원	인코딩/디코딩 지원

3. 내장 그래픽별 코덱 지원 여부

내장 그래픽	아키텍처	H.264 인코딩/디코딩	H.265/HEVC 인코딩/디코딩	VP9 디코딩	AV1 인코딩	AV1 디코딩	JPEG 디코딩
Radeon 740M	RDNA3	✅	✅	✅	✅	✅	✅
Radeon 760M	RDNA3	✅	✅	✅	✅	✅	✅
Radeon 780M	RDNA3	✅	✅	✅	✅	✅	✅
Radeon Graphics (2 CU)	RDNA2	✅	✅	✅	❌	✅	❌
Radeon 610M	RDNA2	✅	✅	✅	❌	✅	❌
Radeon 660M	RDNA2	✅	✅	✅	❌	✅	❌

4. Vega 및 Radeon Graphics 시리즈 (구형 내장 그래픽)

내장 그래픽	코덱 종류	H.264 인코딩/디코딩	H.265/HEVC 인코딩/디코딩	VP8 인코딩/디코딩	VP9 인코딩/디코딩	AV1 디코딩
Radeon 6 Graphics	✅	✅	✅	❌	✅	❌
Radeon 7 Graphics	✅	✅	✅	❌	✅	❌
Radeon 8 Graphics	✅	✅	✅	❌	✅	❌
Radeon Vega 8 Graphics	✅	✅	✅	❌	✅	❌
Radeon Vega 11 Graphics	✅	✅	✅	❌	✅	❌

5. 추가 설명 (코덱 지원 현황)

아키텍처	내장 그래픽 모델명	H.264 인코딩/디코딩	H.265/HEVC 인코딩/디코딩	VP9 디코딩	AV1 인코딩	AV1 디코딩
RDNA3 기반	Radeon 780M, 760M, 740M	✅	✅	✅	✅	✅
RDNA2 기반	Radeon 660M, 610M, Raphael	✅	✅	✅	❌	✅
Vega 및 이전 Radeon Graphics 시리즈	Radeon Vega 8 Graphics, Radeon Vega 11 Graphics, Radeon Graphics 시리즈 ( 6, 7, 8 )	✅	✅	✅	❌	❌

깨알 홍보를 해보자면, https://github.com/NavyStack/ipranges 프로젝트를 참고해보세요.
전부 막아버리고 특정 대역은 허용하는 방식으로 사용중입니다.

github 같은 경우, 개인적인 필요에 의해서 Workflows 등 여러가지로 나누어 두었는데, 나머지는 아직 나눌 필요성이 없어서 Merge는 안했습니다. 시간이 되면 조금 더 보완해 보겠습니다.

안녕하세요! @hjjh745 님,

시놀로지 NAS 보안 강화에 대해 고민하고 계신 것 같네요. 방화벽 설정이 꼭 필요한지 궁금해 하시는 것 같아서, 이 부분을 좀 더 쉽게 설명해드릴게요.

우선 공유기와 NAS의 역할에 대해 간단히 말씀드리면, 공유기는 집이나 회사에서 인터넷을 여러 기기로 나누어주는 장치이고, NAS는 데이터를 저장하고 공유하는 장치입니다. 많은 사람들이 NAS를 공유기에 연결해서 사용하죠.

1. 그럼, 공유기만 있으면 NAS에 방화벽 설정이 필요 없을까요?

많은 분들이 "내가 공유기를 사용하니까 굳이 NAS에서 따로 방화벽을 설정할 필요가 없겠지?"라고 생각할 수 있어요. 하지만 사실은 그렇지 않습니다. 그 이유는 아래와 같습니다.

1. 공유기의 방화벽은 보통 외부에서 들어오는 공격을 막아주는 역할을 합니다. 즉, 인터넷을 통해 외부에서 누군가 당신의 네트워크에 접근하려고 할 때, 공유기가 이를 막아주죠. 그래서 외부 공격에 대한 1차적인 보호는 어느 정도 받을 수 있습니다.

2. 하지만 문제는 내부에서도 발생할 수 있습니다. 만약 내부 네트워크(같은 와이파이에 연결된 기기들) 중 하나가 해킹되거나 악성코드에 감염되면, 이 감염된 기기가 NAS에 접근할 가능성이 생길 수 있죠. 또는 의도치 않게 다른 사람이 NAS에 접근하게 되는 경우도 있을 수 있습니다.

3. 또한 공유기에서 충분하고 완전한 방화벽 설정을 지원하지 않는 경우가 많습니다. 공유기마다 설정 옵션에 차이가 있고, 일부 공유기는 방화벽 규칙이 제한적일 수 있죠. 이런 경우 NAS의 방화벽을 이용해 더 복잡한 규칙을 적용해, 외부 및 내부 네트워크에서 NAS에 접근할 수 있는 범위를 정밀하게 설정할 수 있습니다.

2. 그래서 NAS의 방화벽이 중요한 이유는?

1. NAS에서 직접 방화벽을 설정해 두면, 누가 NAS에 접근할 수 있는지를 더 세밀하게 관리할 수 있습니다. 예를 들어, NAS의 방화벽 규칙을 설정하면 특정 기기나 특정 IP 주소에서만 NAS에 접근할 수 있도록 제한할 수 있죠.

이렇게 하면 외부뿐만 아니라 내부 네트워크에서도 안전을 더 강화할 수 있습니다.

2. 또한, NAS에 방화벽을 설정하면 접속 기록을 남기고 확인할 수 있는 기능이 있어서, 누가 언제 NAS에 접근하려 했는지를 확인할 수 있습니다. 이는 만약 문제가 발생했을 때 원인을 파악하는 데 큰 도움이 됩니다.

따라서 NAS의 방화벽 설정은 단순히 외부 공격을 막는 것 이상의 보호막 역할을 하게 됩니다.

3. 요약하자면

• 공유기 방화벽은 외부로부터의 공격을 1차적으로 막아줍니다.

• 하지만 NAS 방화벽을 설정하면 내부 네트워크에서 발생할 수 있는 위협도 차단할 수 있고, 더 세밀한 접근 통제를 할 수 있습니다.

• 추가로, NAS에 어떤 기기가 접근하려고 했는지 기록을 확인할 수 있어 보안 모니터링이 가능합니다.

4. 결론

결론적으로, 공유기를 사용하더라도 NAS에 따로 방화벽을 설정하는 것은 보안을 한층 강화하는 중요한 방법입니다. 다만, 다른 모든 상황과 마찬가지로 여러 가지 상충되는 요소가 있을 수 있으니, 사용 환경에 맞게 적절하게 고려하셔서 설정하시면 될 것 같습니다.

도움이 되었으면 좋겠습니다. 고맙습니다.

현재 권한을 제한한 계정을 사용하는 것도 보안을 강화하는 데 중요한 요소가 될 수 있습니다.
현재 저는 아래와 같이 사용하고 있습니다.

1. 최고 관리자 계정(Askfront) : 이 계정은 시스템 전반에 대한 모든 권한을 가지고 있으므로, 가능한 한 자주 사용하지 않고 필요할 때만 접근하고 있습니다. 이 계정에 접근하는 빈도를 줄임으로써 보안 위협에 노출될 가능성을 낮출 수 있습니다.

2. 전역 중재자 계정(NavyStack): 이 계정은 제한된 권한을 가지며, 일상적인 관리 작업에만 사용됩니다. 권한이 제한된 계정을 사용하는 것은 만약 계정이 침해되더라도 피해 범위를 최소화할 수 있는 중요한 보안 조치라고 생각합니다.

이와 같은 권한 분리 및 제한된 계정 사용은 최소 권한 원칙(Principle of Least Privilege)을 따르는 사례입니다.
이를 통해 불필요한 위험을 줄이고, 계정이 침해되더라도 시스템 전체에 미치는 영향을 최소화할 수 있습니다.

보안에 대해서는 여러 의견과 상충이 있습니다. 가장 적합한 방법을 선택하셔서 사용하시기를 권장합니다. :)

개인적으로 연락 드렸습니다.
해결됨으로 표시하고 종료하겠습니다. :)

안녕하세요?
각자의 관점에 따라 이 문제에 대해 다양한 의견이 있을 수 있지만, 일반적인 관점에서 포인트를 정리해 보겠습니다.

1. 포트 변경의 의미

• 기본 포트(예: 80, 443, 22, 5000, 5001 등)를 사용하는 것은 널리 알려져 있기 때문에, 공격자가 해당 포트를 대상으로 무작위 대입 공격(브루트 포스 공격)이나 취약점 스캐닝을 시도할 가능성이 높습니다.
• 포트를 변경하면 이러한 자동화된 스캔을 피할 수 있을 가능성이 높아지지만, 이는 보안을 강화하는 "숨기는 방법"에 불과합니다. 즉, 포트를 변경함으로써 공격자가 해당 서비스를 찾기 어렵게 만드는 것은 보안층을 하나 더 추가하는 것이지만, 근본적인 보안 대책이 될 수는 없습니다.

2. 보안의 근본적인 요소

• HTTPS/TLS 사용: HTTPS를 사용해 통신을 암호화하고, 와일드카드 인증서 등을 사용하여 인증된 연결을 보장하는 것은 포트 변경보다 훨씬 중요한 보안 대책입니다.
• 강력한 인증: 강력한 비밀번호와 이중 인증(2FA), 하드웨어 보안키 같은 추가적인 인증 메커니즘을 사용하는 것이 포트 변경보다 훨씬 더 큰 보안 이점을 제공합니다.
• 방화벽 및 접근 제어: 특정 IP나 IP 범위에서만 접근을 허용하는 등의 네트워크 접근 제어를 설정하는 것이 포트 변경보다 더 효과적일 수 있습니다.
  ** 관련된 프로젝트로 깃허브 Ipranges를 진행중입니다. 필요하시다면 참고하시기 바랍니다.

3. 포트 변경의 장단점

• 장점: 포트 변경은 기본적인 스캐닝 도구나 봇넷이 탐지하는 것을 어느 정도 방지할 수 있습니다. 이로 인해 표적이 될 가능성을 줄일 수 있습니다.
• 단점: 포트 변경이 보안을 강화하는 것처럼 보일 수 있지만, 숙련된 공격자에게는 여전히 탐지할 수 있습니다. 포트를 변경하는 것 만으로는 근본적인 보안 취약점을 해결할 수 없습니다. (nmap과 같은 도구로 직접 스캔 가능)

4. 결론

• 포트를 변경하는 것은 보안 대책의 일환으로 고려할 수 있지만, 이는 "보안 강화"가 아닌 "보안 숨김" 전략입니다. 주요 보안 요소로 HTTPS, 강력한 인증, 방화벽 규칙 설정 등 근본적인 보안 대책을 우선시하는 것이 좋습니다.
• 포트를 변경하는 것이 추가적인 보안층으로 작용할 수는 있지만, 이로 인해 방심해서는 안 되며, 다른 중요한 보안 조치를 소홀히 해서는 안 됩니다.

따라서 포트 변경은 추가적인 보안층으로서 고려할 수 있지만, 이를 보안의 핵심으로 삼기보다는 보다 근본적인 보안 조치에 집중하는 것이 바람직합니다.

---

참고)

1. well-known port로 약속한 포트가 있습니다.
   HTTP의 경우 80(RFC 2616), HTTPS의 경우 443(RFC 7540)입니다.
   5000, 5001의 경우 시놀로지에서 지정한 포트입니다.

If the port is empty or not given, port 80 is assumed.
만일 포트가 비어 있거나 지정되지 않은 경우, 포트 80으로 가정합니다.

대부분 이런 식으로 가정되어 있어, 포트 번호 생략해도 접속이 가능합니다.

2. 강력한 인증을 추가하는 방법에는 하드웨어 보안키가 있습니다. YubiKey와 같은 것을 고려할 수 있습니다. (FIPS 140과 같은 규정을 준수합니다.)

3. 저의 경우에는요? 하드웨어 보안키 사용하고, 약속된 포트 그대로 사용합니다.

이 글에서는 Let's Encrypt에서 제공하는 TLS/SSL 인증서를 사용하여 PostgreSQL 서버를 설정하는 방법을 설명합니다.

1.postgresql.conf 파일 준비하기

postgresql.conf의 파일은 git clone으로 진행하시면 하실 필요가 없습니다. (덮어 쓰기가 됩니다.)

전체 코드는 Github NavyStack/pgsql-docker에서 확인하실 수 있습니다.

docker run -i --rm postgres cat /usr/share/postgresql/postgresql.conf.sample > postgresql.conf

2.인증서 준비하기

2.1 클라우드플레어 API 키 준비하기 (해당하는 경우) (CF_Token)

클라우드플레어 API 키 발급 페이지로 이동하여 API키를 발급합니다.

그 후,

export CF_Token="<token>"

2.2 클라우드플레어 계정 ID 확인하기 (해당하는 경우) (CF_Account_ID)

클라우드플레어 대시보드에 접속하면 주소창 주소의 끝에 CF_Account_ID가 나옵니다.

그 후,

export CF_Account_ID="<id>"

acme.sh 를 통해서 발급 할 것이므로 ACME.SH를 설치합니다.

curl https://get.acme.sh | sh -s email=admin@askfront.com

source /home/$USER/.bashrc

acme.sh

2.인증서 발급하기

acme.sh --issue --dns dns_cf -d heno.kr -d *.host.heno.kr --force --server letsencrypt

3. postgres 컨테이너 올리기

3.1. postgresql.conf 파일을 인증서의 경로 및 파일이름에 맞게 수정합니다.

기본적으로 전부 주석처리 되어있으므로 파일의 원하는 곳에 입력합니다.

ssl = on
ssl_cert_file = 'fullchain.cer'
ssl_key_file = 'heno.kr.key'
ssl_prefer_server_ciphers = on

3.2. pg_hba.conf 파일을 필요에 따라 수정합니다.

기본적으로 전부 주석처리 되어있으므로 파일의 원하는 곳에 입력합니다.

hostssl    all    all    0.0.0.0/0    md5

3. docker-compose.yml 파일을 적절하게 수정합니다.

services:
  postgres:
    container_name: postgres_container
    image: postgres:16-bookworm
    ports:
      - 5432:5432
    volumes:
      - ./data:/var/lib/postgresql/data
      - ./logs:/var/log/postgresql
      - ./postgresql.conf:/var/lib/postgresql/data/postgresql.conf
      # - ./pg_hba.conf:/var/lib/postgresql/data/pg_hba.conf
      - /home/ubuntu/.acme.sh/heno.kr_ecc/heno.kr.key:/var/lib/postgresql/data/heno.kr.key
      - /home/ubuntu/.acme.sh/heno.kr_ecc/fullchain.cer:/var/lib/postgresql/data/fullchain.cer
      - /var/lib/pgsql/data
    environment:
      - POSTGRES_DB=postgres
      - POSTGRES_PASSWORD=postgres
      - POSTGRES_USER=postgres
      - PGDATA=/var/lib/postgresql/data
      - PGSSLMODE=require

docker compose up -d

4. Postgres 접속하기

아래의 SQL문을 실행해서 TLS로 연결중인지 확인합니다.

SELECT * from pg_catalog.pg_stat_ssl

PostgreSQL의 자체적인 접속을 포함해서 나오네요

조금 더 자세하게 보려면 아래의 SQL 문을 실행합니다.

SELECT ssl.pid, usename, datname, ssl, client_addr, backend_type, wait_event
FROM pg_catalog.pg_stat_ssl ssl, pg_catalog.pg_stat_activity a
WHERE ssl.pid = a.pid

안녕하세요?
답변이 늦어졌네요. 죄송하게 생각하고 있습니다.
NodeBB 라고 하는 Node 기반 CMS입니다.
Docker 사용한 도커이미지는 아래 깃허브에서 확인하실 수 있습니다. :)

https://github.com/navystack/nodebb-docker

@ljr10 님, 안녕하세요?

우선 PXE를 사용하시려면 DHCP에서 넘겨주는 작업이 필요합니다.
일부 메인보드에서는 수동으로 설정해서 바로 부팅하는 방법도 있지만 지극히 극소수입니다.

여러가지 방법이 있겠지만, 가장 간단하게 사용하시는 방법은 공유기에서 넘겨주는 방법이 있습니다.
저는 Asus공유기를 사용하고 있고, 셸 스크립트를 지원해서 간단하게 아래와 같이 스크립트를 짜서 넣었습니다. (물론 재부팅하면 스크립트를 다시 걸어주어야 합니다. :) )

일반 사용자가 PXE를 많이 사용하지 않아 관련된 정보가 많이 없을 수 있지만, Asus공유기를 사용하신다면 아래의 스크립트를 사용해보시겠어요?

• https://github.com/NavyStack/asus-pxe
• iventoy 공식문서
• 관련 명세 RFC4578

고맙습니다.