Every KapsuleHost Server ships with a managed firewall that denies inbound traffic by default, plus brute-force protection, a web application firewall and automatic security patching, all controlled…

클라우드 서버 방화벽 및 보안 관리

모든 KapsuleHost 서버는 기본적으로 인바운드 트래픽을 거부하는 관리형 방화벽, 브루트포스 공격 방지, 웹 애플리케이션 방화벽 및 자동 보안 패칭을 갖추고 있으며, 이 모든 기능은 KPanel의 한 페이지에서 제어됩니다.

기본 설정은 새로운 서버가 어떤 조작을 하기 전에도 안전하도록 선택되었습니다. 이 위에 추가하는 것은 일반적으로 자신의 애플리케이션이 필요로 하는 포트뿐입니다. 이 가이드는 서버 관리 페이지 전체를 설명합니다. 방화벽이 한 섹션이고 다른 섹션들이 방화벽이 필요하지 않도록 하는 것들이기 때문입니다.

관리 페이지 열기

KPanel에 로그인합니다.
왼쪽 사이드바에서 Cloud Servers를 클릭한 후 서버를 클릭합니다.
페이지 상단의 작업 버튼에서 Management를 클릭합니다.

직접 주소는 /cloud-servers/<server-id>/management입니다. 페이지는 "방화벽, OS 패치, fail2ban 및 ModSecurity. 변경 사항은 SSH를 통해 몇 초 내에 적용됩니다."라고 설명합니다.

KPanel의 클라우드 서버에 대한 서버 관리 페이지

배너에 "Live apply unavailable. 변경 사항은 다음 프로비저닝 실행에 저장되지만 즉시 적용되지 않습니다"라고 표시되면 패널이 현재 서버에 연결할 수 없습니다. 설정은 여전히 저장되지만 아직 적용되지 않았습니다. 서버가 실행 중이고 도달 가능한지 확인하세요.

기본 방화벽 정책

Firewall (UFW) 섹션은 정책을 한 줄로 명시합니다: "Default-deny inbound. SSH (22) is always open. App-stack ports open automatically. Add custom rules below."

실제로 이는 다음을 의미합니다:

규칙이 허용하지 않는 한 아무것도 인터넷에서 서버에 도달할 수 없습니다.
포트 22는 항상 열려 있으므로 방화벽 변경으로 인해 머신에서 차단될 수 없습니다.
웹 애플리케이션의 경우 80 및 443과 같은 앱 스택이 필요로 하는 포트가 자동으로 열립니다.
서버에서의 아웃바운드 트래픽은 제한되지 않습니다.

사용자 정의 규칙이 없으면 섹션에 "No custom rules. Defaults: SSH + app-stack ports."라고 표시됩니다. 이는 구성이 누락된 것이 아니라 건강한 상태입니다.

사용자 정의 규칙 추가

기본 정책이 다루지 않는 포트에서 무언가를 실행할 때 규칙을 추가합니다: 3000의 Node 애플리케이션, 5432의 데이터베이스에 직접 연결, UDP 포트의 게임 또는 미디어 서버.

Firewall (UFW) 섹션을 엽니다.
Port 번호를 첫 번째 필드에 입력합니다. 유효한 값은 1에서 65535입니다.
TCP 또는 UDP를 선택합니다.
Allow 또는 Deny를 선택합니다.
Add를 클릭합니다.

규칙이 목록에 ALLOW 또는 DENY 배지와 포트 및 프로토콜과 함께 나타납니다(예: 3000/tcp). 관리 연결을 통해 몇 초 내에 서버로 푸시됩니다.

규칙을 제거하려면 행의 끝에 있는 X를 클릭합니다. Allow 규칙을 제거하면 해당 포트가 즉시 다시 닫힙니다.

데이터베이스 포트를 전체 인터넷에 노출하는 것은 서버가 손상되는 가장 일반적인 방법 중 하나입니다. 3306, 5432, 6379 또는 27017을 허용하기 전에 연결할 항목이 서버의 자체 루프백 인터페이스나 프라이빗 네트워크를 통해 데이터베이스에 도달할 수 있는지 묻기 바랍니다. 외부에서 진정으로 도달 가능해야 한다면 서비스 자체가 강력한 인증 및 암호화를 요구하는지 확인하세요.

먼저 규칙을 추가한 후 서비스를 시작합니다. 닫힌 포트 뒤에서 시작되는 서비스는 시작에 실패한 서비스와 정확히 같은 방식으로 손상되어 보이며, 잘못된 계층을 디버깅하느라 오랜 시간을 낭비할 수 있습니다.

앱 스택

App stack 섹션은 이 서버가 실행하는 애플리케이션의 종류를 플랫폼에 알려주므로 강화 프리셋이 이에 맞게 조정될 수 있습니다. 패널을 통해 애플리케이션을 설치하면 자동으로 설정됩니다.

인식되는 스택은 WordPress, WooCommerce, Ghost, Nextcloud, GitLab, Mattermost, 일반 웹 및 앱 스택 없음입니다. 섹션은 다음과 같이 설명합니다: "The hardening preset is tuned to your app. Installing an app from the marketplace auto-sets this."

스택은 자동으로 열리는 포트와 다른 보호 기능을 조정하는 방식에 영향을 미치며, 가장 눈에 띄게는 fail2ban에 영향을 미칩니다.

fail2ban

fail2ban은 인증 시도를 감시하고 계속 실패하는 주소를 차단합니다. 기본적으로 활성화되어 있으며 페이지는 다음과 같이 설명합니다: "Bans IPs that brute-force SSH. For WordPress sites, adds wp-login.php protection too."

활성 상태로 둡니다. 이는 페이지에서 가장 저렴한 보호이며, 성능에 비용이 들지 않으며, 지속적인 비밀번호 추측 시도의 배경 잡음을 완전히 없애줍니다. WordPress 또는 WooCommerce 스택에서는 로그인 양식도 보호하며, 이것이 실제로 WordPress에 대한 대부분의 공격이 이루어지는 곳입니다.

ModSecurity, 웹 애플리케이션 방화벽

ModSecurity는 HTTP 요청을 OWASP Core Rule Set과 비교하여 검사하고 공격처럼 보이는 요청에 플래그를 지정합니다. KapsuleHost 서버에서는 탐지 전용 모드로 시작합니다: "OWASP Core Rule Set in DetectionOnly mode by default. Logs suspicious traffic without blocking; flip to active mode in your server once tuned."

탐지 전용은 올바른 시작점입니다. Core Rule Set은 철저하고 실제 애플리케이션에서 일부 합법적인 요청이 규칙과 일치할 것입니다. 탐지 전용으로 한동안 실행하고 로그를 읽으며 자신의 트래픽이 트리거하는 규칙을 파악한 후 서버 내에서 차단으로 전환하세요.

먼저 조정하지 않고 차단을 활성화하면 자신의 사이트가 손상될 수 있습니다. 리치 텍스트가 있는 양식 제출, 파일 업로드 및 특이한 페이로드가 있는 API 클라이언트가 일반적인 손실입니다. 전환하기 전에 로그를 확인하세요.

OS 자동 패칭

보안 업데이트가 자동으로 적용됩니다. 섹션은 보안망을 설명합니다: "Security updates applied automatically. Snapshot-protected: a server snapshot is taken before each run, with automatic rollback if the server becomes unreachable after reboot."

토글 아래에 두 가지 설정이 있습니다:

Allow automatic reboot when a kernel update needs it (only during quiet hours below). 커널 업데이트는 재부팅 후에만 적용됩니다. 이를 끄면 커널 패치가 설치되지만 직접 재부팅할 때까지 활성화되지 않습니다.
Quiet window (UTC), 시작 시간과 종료 시간입니다. 재부팅은 그 안에만 발생합니다. 대상자에게 가장 조용한 시간으로 설정하고 필드가 로컬 시간이 아닌 UTC임을 기억하세요.

자동 패칭을 켜둡니다. 손상된 서버의 압도적인 다수는 몇 주 전에 발표된 패치가 있는 소프트웨어를 실행 중입니다. 자동 롤백이 있는 사전 패치 스냅샷은 업데이트가 무언가를 깰 수 있다는 일반적인 이의가 이미 처리됨을 의미합니다.

패치 히스토리 및 지금 패치 실행

Patch history 섹션은 각 실행을 RUNNING, SUCCESS, ROLLED_BACK, FAILED 또는 SKIPPED 상태, 업데이트된 패키지 수, 서버 재부팅 여부 및 시작 시간으로 나열합니다.

일정을 기다리지 않고 즉시 패치하려면 Run patch now를 클릭합니다. 확인은 다음과 같이 읽습니다: "A snapshot is created first. The server stays online except for a brief reboot if a kernel update needs it."

ROLLED_BACK 항목은 보안망이 역할을 한 것을 의미합니다: 서버가 재부팅 후 깔끔하게 돌아오지 않았으므로 사전 패치 스냅샷이 복원되었습니다. Cloud Server Snapshots을 참조하여 이러한 스냅샷의 작동 방식을 확인하세요.

합리적인 기본 설정

대부분의 서버에서는 이것이 전체 보안 구성입니다:

설정	권장
방화벽	활성, 기본 규칙, 앱이 필요로 하는 포트만
fail2ban	활성
ModSecurity	활성, 로그를 읽을 때까지 탐지 전용
OS 자동 패칭	활성, 조용한 시간에 재부팅 허용
SSH 인증	키, 비밀번호 아님

마지막 행은 이 페이지에 없지만 나머지보다 훨씬 더 중요합니다. Connecting to Your Cloud Server With SSH를 참조하세요.

문제 해결

"Could not load management config." 패널이 이 서버의 설정을 읽을 수 없습니다. 다시 로드하고 서버가 존재하며 프로비저닝되었는지 확인합니다.

"Port must be 1-65535." 포트 필드는 해당 범위의 정수를 가집니다. 범위 및 서비스 이름은 여기에서 허용되지 않습니다.

내 규칙이 저장되었지만 아무것도 변경되지 않았습니다. "Live apply unavailable" 배너를 찾으세요. 표시되면 변경 사항이 저장되지만 아직 서버로 푸시되지 않았습니다.

한 네트워크에서는 서비스에 도달할 수 있지만 다른 네트워크에서는 불가능합니다. 이는 일반적으로 서버의 방화벽이 아니라 자신의 아웃바운드 방화벽입니다. 여기서 규칙을 변경하기 전에 다른 연결에서 테스트합니다.

패치 실행이 FAILED로 표시됩니다. 행의 오류 메시지를 읽습니다. 전체 디스크가 가장 일반적인 원인입니다. 공간을 확보하고 Run patch now를 클릭합니다.

합법적인 트래픽이 차단되기 시작했습니다. ModSecurity를 차단 모드로 전환한 경우 탐지 전용으로 다시 설정하고 로그를 읽으며 다시 시도하기 전에 규칙을 식별합니다.

방화벽 규칙이 적용을 거부하거나 허용한 서비스에서 차단된 경우 서버 이름, 포트 및 예상 도달 항목과 함께 support@kapsulehost.com으로 이메일을 보냅니다.

Kapsule Orbit 클라우드 서버 방화벽 및 보안 관리