하드닝 - 운영 체제 권고 사항
일반적인 하드닝 가이드라인은 주요 하드닝 문서에 개요되어 있습니다.
전반적인 보안성을 높이려면 기본 운영 체제를 설정할 수 있습니다. Self-Managed형 GitLab 인스턴스와 같은 관리되는 환경에서는 추가 단계가 필요하며, 특정 배포에는 필수적입니다. FedRAMP는 그러한 배포의 예입니다.
SSH 구성
SSH 클라이언트 구성
클라이언트 접근(또는 GitLab 인스턴스 또는 기본 운영 체제)에 대해 SSH 키 생성을 위한 몇 가지 권고 사항이 있습니다. 첫 번째는 일반적인 SSH 키입니다.
ssh-keygen -a 64 -t ed25519 -f ~/.ssh/id_ed25519 -C "ED25519 Key"
FIPS(연방 정보 처리 표준) 호환 SSH 키를 사용하려면 다음을 사용하세요.
ssh-keygen -t rsa -b 4096 -f ~/.ssh/id_rsa -C "RSA FIPS 호환 키"
SSH 서버 구성
운영 체제 수준에서 SSH 액세스를 허용하는 경우(일반적으로 OpenSSH를 통해), sshd_config 파일의 구성 옵션 예시는 다음과 같습니다(실제 위치는 운영 체제에 따라 달라질 수 있지만 일반적으로 /etc/ssh/sshd_config에 있습니다).
#
# 예시 sshd 구성 파일. 이는 공개 키 인증을 지원하며
# 여러 잠재적 보안 위험 영역을 해제합니다
#
PubkeyAuthentication yes
PasswordAuthentication yes
UsePAM yes
UseDNS no
AllowTcpForwarding no
X11Forwarding no
PrintMotd no
PermitTunnel no
# 클라이언트가 로케일 환경 변수를 전달할 수 있도록 함
AcceptEnv LANG LC_*
# 기본값 무시(서브시스템 없음)
Subsystem sftp /usr/lib/openssh/sftp-server
# 프로토콜 조정, FIPS 또는
# FedRAMP 배포에서 필요하며 강력하고 검증된 알고리즘만 사용
Protocol 2
Ciphers aes128-ctr,aes192-ctr,aes256-ctr
HostKeyAlgorithms ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521
KexAlgorithms ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521
Macs hmac-sha2-256,hmac-sha2-512
방화벽 규칙
방화벽 규칙의 경우 기본 사용을 위해 TCP 포트 80 및 443만 열어야 합니다. 기본적으로 원격에서 컨테이너 레지스트리에 액세스를 위해 5050 포트가 열려 있지만, 보안 강화된 환경에서는 이는 다른 호스트에 존재하거나 일부 환경에서는 아예 열리지 않을 것입니다. 따라서 권장되는 것은 80 및 443 포트만 열고, 80 포트는 반드시 443로 리디렉션해야 합니다.
FedRAMP와 같이 완전히 강화된 또는 격리된 환경의 경우 방화벽 규칙을 조정하여 해당 네트워크에서만이 접근할 수 있도록 모든 포트를 제한해야 합니다. 예를 들어, IP 주소가 192.168.1.2이고 모든 인증된 클라이언트가 또한 192.168.1.0/24에 있는 경우, 포트 80 및 443에 대한 접근 권한을 192.168.1.0/24로만 제한해야 합니다(안전상의 제한으로), 다른 방화벽에서 다른 곳에서도 액세스가 제한되었더라도 말이죠.
이상적으로, Self-Managed형 인스턴스를 설치할 때 관리자와 설치자만 액세스할 수 있도록 방화벽 규칙을 구현하고 설치를 마친 후에 사용자의 추가적인 IP 주소 범위만 추가해야 합니다.
iptables나 ufw의 사용은 호스트당 포트 80 및 443에 대한 액세스를 시행하고 제한하는 데 허용됩니다. 그렇지 않은 경우 GCP Google Compute나 AWS 보안 그룹을 통해 클라우드 기반의 방화벽 규칙 사용이 이를 시행해야 합니다. 다른 모든 포트는 차단하거나 특정 범위로만 제한해야 합니다. 포트에 대한 자세한 정보는 패키지 기본값을 참조하세요.
방화벽 추가
외부 액세스가 필요한 여러 서비스가 활성화될 수 있으며(예: Sidekiq), 이러한 유형의 서비스를 특정 IP 주소나 특정 Class C로 제한해야 합니다. 가능한 경우 GitLab의 특정 노드나 하위 네트워크로 이러한 추가 서비스를 제한하는 것이 좋습니다.
커널 조정
커널 조정은 /etc/sysctl.conf을 편집하거나, /etc/sysctl.d/의 파일 중 하나를 편집하여 수행할 수 있습니다. 커널 조정은 공격 위협을 완전히 제거하지는 않지만 추가적인 보안 계층을 추가합니다. 다음 노트는 이러한 조정이 가져다주는 일부 이점을 설명합니다.
## sysctl.conf 커널 수정 사항 ##
##
## 다음은 경계를 벗어나거나 널 포인터 역참조, 힙 및
## 버퍼 오버플로우 버그, 사용 후 메모리 등을 방지하는 데 도움이 됩니다.
## 이는 100% 문제를 해결하지는 않지만, 공격을 현저히 방해합니다.
##
# 기본값은 65536이며, 악용에 사용되는 메모리 문제를 완화해줍니다
vm.mmap_min_addr=4096
# 기본값은 0이며, 메모리의 가상 주소 공간을 무작위로 설정하여 취약한 공격을 어렵게 만듭니다
kernel.randomize_va_space=2
# 공격 지원을 위한 커널 포인터 액세스를 제한합니다(예: cat /proc/kallsyms)
kernel.kptr_restrict=2
# dmesg에 대한 간편한 커널 오류를 방지합니다
kernel.dmesg_restrict=1
# eBPF 제한
kernel.unprivileged_bpf_disabled=1
net.core.bpf_jit_harden=2
# 일반 사용 후 메모리 공격 방지
vm.unprivileged_userfaultfd=0
## 네트워킹 수정 사항 ##
##
## IP 스택 레이어에서의 일반적인 공격 방지
##
# SYN FLOOD 거부 서비스 공격 방지
net.ipv4.tcp_syncookies=1
# Time-wait assassination 공격 방지
net.ipv4.tcp_rfc1337=1
# IP 위장/출발지 라우팅 보호
net.ipv4.conf.all.rp_filter=1
net.ipv4.conf.default.rp_filter=1
net.ipv6.conf.all.accept_ra=0
net.ipv6.conf.default.accept_ra=0
net.ipv4.conf.all.accept_source_route=0
net.ipv4.conf.default.accept_source_route=0
net.ipv6.conf.all.accept_source_route=0
net.ipv6.conf.default.accept_source_route=0
# IP 리다이렉션 보호
net.ipv4.conf.all.accept_redirects=0
net.ipv4.conf.default.accept_redirects=0
net.ipv4.conf.all.secure_redirects=0
net.ipv4.conf.default.secure_redirects=0
net.ipv6.conf.all.accept_redirects=0
net.ipv6.conf.default.accept_redirects=0
net.ipv4.conf.all.send_redirects=0
net.ipv4.conf.default.send_redirects=0
도움말