Hardening - 운영 체제 권장사항
일반적인 강화 가이드라인은 주요 강화 문서에 개요되어 있습니다.
전체적인 보안을 강화하기 위해 기본 운영 체제를 구성할 수 있습니다. 자체 관리 GitLab 인스턴스와 같이 통제된 환경에서는 추가 단계가 필요하며 특정 배포에 종종 필수적입니다. FedRAMP가 그러한 배포의 예입니다.
SSH 구성
SSH 클라이언트 구성
클라이언트 액세스(일반적으로 GitLab 인스턴스 또는 기본 운영 체제)의 경우 SSH 키 생성에 대한 몇 가지 권장 사항이 있습니다. 첫 번째는 전형적인 SSH 키입니다.
ssh-keygen -a 64 -t ed25519 -f ~/.ssh/id_ed25519 -C "ED25519 키"
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만 허용해야 합니다(안전 제한으로), 다른 방화벽으로 다른 곳에서 액세스가 제한되더라도.
이상적인 상태에서 자체 관리 인스턴스를 설치하는 경우에는 설치가 시작되기 전에 방화벽 규칙을 구현하고 관리자 및 설치자의 액세스를 제한하고, 인스턴스가 설치되어 적절하게 강화된 후에 사용자의 추가 범위만 추가해야 합니다.
iptables 또는 ufw를 사용하여 호스트 단위로 포트 80 및 443에 액세스를 구현하고 강제하는 것은 허용됩니다. 그렇지 않으면 GCP Google Compute나 AWS 보안 그룹을 통한 클라우드 기반의 방화벽 규칙을 사용하여 이를 시행해야 합니다. 다른 모든 포트는 차단되거나 특정 범위로 제한되어야 합니다. 포트에 대한 자세한 정보는 패키지 기본값을 참조하세요.
방화벽 추가
외부 액세스가 필요한 다양한 서비스들이 활성화될 수 있으며(예: Sidekiq), 네트워크 액세스가 열려야 할 수 있습니다. 이러한 종류의 서비스를 특정 IP 주소나 특정 클래스 C에 제한하거나 가능한 경우 GitLab의 특정 노드나 서브네트워크로 제한하세요.
커널 조정
커널 조정은 /etc/sysctl.conf를 편집하거나 /etc/sysctl.d/에 있는 파일 중 하나를 수정하여 수행할 수 있습니다. 커널 조정은 공격 위협을 완전히 제거하지는 않지만 추가적인 보안 계층을 추가합니다. 다음 노트는 이러한 조정에 대한 몇 가지 이점을 설명합니다.
## sysctl.conf의 커널 튜닝 ##
##
## 다음은 경계를 벗어나거나 널 포인터 역참조, 힙 및 버퍼 오버플로우 버그를 완화시키는 데 도움이 되는 것들이며, 사용 후에도 100% 안전하지 않을 수 있음
문제 해결, 그러나 심각한 취약점으로 인한 제한
#
기본값은 65536이며, 악용에 사용되는 메모리 문제를 완화하는 데 4096이 도움이 됩니다
vm.mmap_min_addr=4096 # 기본값은 0이며, 메모리의 가상 주소 공간을 무작위화하여 취약점 악용을 어렵게 합니다. kernel.randomize_va_space=2 # Exploit 지원을 위한 커널 포인터 액세스 제한(for example, cat /proc/kallsyms) kernel.kptr_restrict=2 # dmesg에서 verbose 커널 오류를 제한 kernel.dmesg_restrict=1 # eBPF 제한 kernel.unprivileged_bpf_disabled=1 net.core.bpf_jit_harden=2 # 일반적인 use-after-free exploit 방지 vm.unprivileged_userfaultfd=0
네트워킹 조정
#
IP 스택 레이어에서 일반적인 공격 방지
#
SYNFLOOD 거부 서비스 공격 방지
net.ipv4.tcp_syncookies=1 # 시간 대기 암살(assassination) 공격 방지 net.ipv4.tcp_rfc1337=1 # IP spoofing/source routing 보호 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 보호 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 ```
<!– ## Troubleshooting
사전에 예상할 수 있는 어떤 문제 해결 단계도 포함하세요. 설정을 할 때나 무언가를 변경하거나 업그레이드할 때 발생할 수 있는 문제를 사전에 알고 있는 경우, 그것들도 설명하는 것이 중요합니다. 잘못될 수 있는 일들을 생각해보고 이를 여기에 포함하세요. 이것은 지원 요청을 최소화하고 알고 있는 질문이 있는 문서의 주석을 피하기 위해 중요합니다.
각 시나리오는 세 번째 수준의 제목이 될 수 있습니다. 예를 들어 ### 오류 메시지 X 받기. 문서를 작성할 때 추가할 것이 없는 경우에는 미래에 더 추가할 수 있도록 이 섹션은 그대로 두되 주석 처리하여 나둠
도움말