강화 - 운영체제 권장 사항
GitLab v19.5요약
일반적인 강화 지침은 주요 강화 문서에 설명되어 있습니다. 전반적인 보안을 강화하기 위해 기본 운영체제를 구성할 수 있습니다. 클라이언트 액세스(GitLab 인스턴스 또는 기본 운영체제에 대한 액세스)를 위한 SSH 키 생성 권장 사항을 몇 가지 소개합니다.
일반적인 강화 지침은 주요 강화 문서에 설명되어 있습니다.
전반적인 보안을 강화하기 위해 기본 운영체제를 구성할 수 있습니다. GitLab Self-Managed와 같은 통제된 환경에서는 추가 단계가 필요하며, 실제로 특정 배포 환경에서는 이러한 구성이 필수인 경우가 많습니다. 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-compliant Key"
SSH 서버 구성#
운영체제 수준에서 SSH 액세스를 허용하는 경우(일반적으로 OpenSSH를 통해) sshd_config
파일의 구성 옵션 예시는 다음과 같습니다(정확한 위치는 운영체제에 따라 다를 수 있지만
일반적으로 /etc/ssh/sshd_config 입니다).
#
# Example sshd config file. This supports public key authentication and
# turns off several potential security risk areas
#
PubkeyAuthentication yes
PasswordAuthentication yes
UsePAM yes
UseDNS no
AllowTcpForwarding no
X11Forwarding no
PrintMotd no
PermitTunnel no
PermitRootLogin no
# Allow client to pass locale environment variables
AcceptEnv LANG LC_*
# Change default of 120 seconds to 60
LoginGraceTime 60
# override default of no subsystems
Subsystem sftp /usr/lib/openssh/sftp-server
# Protocol adjustments, these would be needed/recommended in a FIPS or
# FedRAMP deployment, and use only strong and proven algorithm choices
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
이 설정은 OpenSSH에 적용됩니다.
인스턴스에서 gitlab-sshd가 Git SSH 트래픽도 처리하는 경우 알고리즘을 별도로 구성합니다.
자세한 내용은
SSH 알고리즘 구성을 참고합니다.
방화벽 규칙#
방화벽 규칙의 경우 기본 사용을 위해서는 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 로만 제한합니다.
이상적으로는 GitLab Self-Managed 인스턴스를 설치하는 경우, 설치가 시작되기 전에 액세스를 관리자와 설치 담당자로 제한한 상태로 방화벽 규칙을 적용하고, 인스턴스가 설치되어 제대로 강화된 이후에만 사용자를 위한 추가 IP 주소 범위를 추가해야 합니다.
호스트별로 포트 80과 443 액세스를 구현하고 적용하는 데에는 iptables 또는 ufw
사용이 적합하며, 그렇지 않으면 GCP Google Compute 나 AWS Security Groups를 통한 클라우드
기반 방화벽 규칙 사용으로 이를 적용해야 합니다. 다른 모든 포트는 차단하거나 최소한 특정
범위로 제한해야 합니다. 포트에 대한 자세한 내용은
패키지 기본값을 참고합니다.
GitLab 인스턴스에서의 아웃바운드 연결 허용#
아웃바운드 및 인바운드 설정을 모두 확인합니다.
- 방화벽과 HTTP/S 프록시 서버는
https://를 사용하는 포트443에서cloud.gitlab.com및customers.gitlab.com으로의 아웃바운드 연결을 허용해야 합니다. 이 호스트들은 Cloudflare로 보호됩니다. Cloudflare가 게시하는 IP 범위 목록에 있는 모든 IP 주소로의 트래픽을 허용하도록 방화벽 설정을 업데이트합니다. - HTTP/S 프록시를 사용하려면
gitlab_workhorse와gitlab_rails모두에 필요한 웹 프록시 환경 변수가 설정되어 있어야 합니다. - 다중 노드 GitLab 설치 환경에서는 모든 Rails 및 Sidekiq 노드에 HTTP/S 프록시를 구성합니다.
- GitLab Self-Managed에서 GitLab Duo를 구성하려면 GitLab 인스턴스에서 GitLab Duo 로의 아웃바운드 연결을 허용합니다.
방화벽 추가 설정#
외부 액세스가 필요한 다양한 서비스(예: Sidekiq)가 활성화되어 네트워크 액세스를 열어야 할 수 있습니다. 이러한 유형의 서비스는 특정 IP 주소나 특정 Class C로 제한합니다. 계층화된 추가 예방 조치로서, 가능하면 이러한 추가 서비스를 GitLab 내 특정 노드나 서브 네트워크로 제한합니다.
커널 조정#
커널 조정은 /etc/sysctl.conf를 편집하거나 /etc/sysctl.d/ 안의 파일 중 하나를 편집하여
수행할 수 있습니다. 커널 조정으로 공격 위협을 완전히 제거할 수는 없지만, 보안 계층을 하나
더 추가할 수 있습니다. 다음 설명은 이러한 조정의 장점 일부를 설명합니다.
## Kernel tweaks for sysctl.conf ##
##
## The following help mitigate out of bounds, null pointer dereference, heap and
## buffer overflow bugs, use-after-free etc from being exploited. It does not 100%
## fix the issues, but seriously hampers exploitation.
##
# Default is 65536. Higher values provide stronger protection against NULL-pointer dereference exploits.
# Use 4096 only if required for application compatibility, as it reduces the range of protected low memory addresses.
vm.mmap_min_addr=4096
# Default is 0, randomize virtual address space in memory, makes vuln exploitation
# harder
kernel.randomize_va_space=2
# Restrict kernel pointer access (for example, cat /proc/kallsyms) for exploit assistance
kernel.kptr_restrict=2
# Restrict verbose kernel errors in dmesg
kernel.dmesg_restrict=1
# Restrict eBPF
kernel.unprivileged_bpf_disabled=1
net.core.bpf_jit_harden=2
# Prevent common use-after-free exploits
vm.unprivileged_userfaultfd=0
# Mitigation CVE-2024-1086 by preventing unprivileged users from creating namespaces
kernel.unprivileged_userns_clone=0
## Networking tweaks ##
##
## Prevent common attacks at the IP stack layer
##
# Prevent SYNFLOOD denial of service attacks
net.ipv4.tcp_syncookies=1
# Prevent time wait assassination attacks
net.ipv4.tcp_rfc1337=1
# IP spoofing/source routing protection
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 redirection protection
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