InfoGrab Docs

강화 - 운영 체제 권고 사항

요약

일반적인 강화 지침은 주요 강화 문서에 설명되어 있습니다. 전반적인 보안을 향상시키기 위해 기본 운영 체제를 구성할 수 있습니다. 클라이언트 액세스(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

방화벽 규칙#

방화벽 규칙의 경우 기본 사용을 위해 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 주소 범위를 추가해야 합니다.

iptables 또는 ufw를 사용하여 호스트별로 포트 80 및 443 액세스를 구현하고 적용하는 것이 허용되며, 그렇지 않으면 GCP Google Compute 또는 AWS 보안 그룹을 통한 클라우드 기반 방화벽 규칙이 이를 적용해야 합니다. 다른 모든 포트는 차단되거나 특정 범위로 제한되어야 합니다. 포트에 대한 자세한 내용은 패키지 기본값을 참조하세요.

GitLab 인스턴스에서 아웃바운드 연결 허용#

아웃바운드 및 인바운드 설정을 모두 확인하세요:

  • 방화벽 및 HTTP/S 프록시 서버는 포트 443에서 https://를 사용하여 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 주소 또는 특정 클래스 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

강화 - 운영 체제 권고 사항

원문 보기
요약

일반적인 강화 지침은 주요 강화 문서에 설명되어 있습니다. 전반적인 보안을 향상시키기 위해 기본 운영 체제를 구성할 수 있습니다. 클라이언트 액세스(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

방화벽 규칙#

방화벽 규칙의 경우 기본 사용을 위해 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 주소 범위를 추가해야 합니다.

iptables 또는 ufw를 사용하여 호스트별로 포트 80 및 443 액세스를 구현하고 적용하는 것이 허용되며, 그렇지 않으면 GCP Google Compute 또는 AWS 보안 그룹을 통한 클라우드 기반 방화벽 규칙이 이를 적용해야 합니다. 다른 모든 포트는 차단되거나 특정 범위로 제한되어야 합니다. 포트에 대한 자세한 내용은 패키지 기본값을 참조하세요.

GitLab 인스턴스에서 아웃바운드 연결 허용#

아웃바운드 및 인바운드 설정을 모두 확인하세요:

  • 방화벽 및 HTTP/S 프록시 서버는 포트 443에서 https://를 사용하여 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 주소 또는 특정 클래스 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