모든 KapsuleHost 서버에는 기본적으로 인바운드 트래픽을 거부하는 관리형 방화벽과 브루트 포스 공격 방지, 웹 애플리케이션 방화벽, 자동 보안 패칭이 포함되어 있으며, 이 모든 것은 KPanel의 한 페이지에서 제어됩니다.
기본값은 새로운 서버가 설정하기 전에도 안전하도록 선택되었습니다. 그 위에 추가하는 것은 일반적으로 자신의 애플리케이션이 필요로 하는 포트뿐입니다. 이 가이드는 전체 서버 관리 페이지를 안내합니다. 방화벽이 이 페이지의 한 섹션이고, 다른 섹션들이 방화벽이 필요 없도록 하는 것들이기 때문입니다.
관리 페이지 열기
- KPanel에 로그인합니다.
- 왼쪽 사이드바에서 Cloud Servers를 클릭한 후 서버를 클릭합니다.
- 페이지 상단의 작업 버튼에서 Management를 클릭합니다.
직접 주소는 /cloud-servers/<server-id>/management입니다. 이 페이지는 "Firewall, OS patches, fail2ban, and ModSecurity. Changes apply over SSH within seconds."라고 설명합니다.
배너에 "Live apply unavailable. Changes will save to the next provisioning run but won't take effect immediately"라고 표시되면 패널이 지금 서버에 연결할 수 없습니다. 설정은 여전히 저장되지만 아직 적용되지 않았습니다. 서버가 실행 중이고 도달 가능한지 확인하십시오.
기본 방화벽 정책
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, Generic web, 그리고 No app stack입니다. 섹션은 다음과 같이 설명합니다: "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으로 서버 이름, 포트 및 도달할 것으로 예상하는 것을 포함하여 이메일을 보내십시오.