DevOps 도구 및 베스트 프랙티스 마스터 - DevOps 지식 허브 DevOps 도구 및 베스트 프랙티스 마스터 - DevOps 지식 허브

SSH 서버 보안 강화를 위한 10가지 필수 모범 사례

더 안전한 인증, 최소 권한 접근, 방화벽 규칙, 속도 제한, 업데이트 및 로그 확인을 통해 SSH 서버를 보호하세요.

SSH 서버 보안 강화를 위한 10가지 필수 모범 사례

SSH(Secure Shell)는 일반적으로 서버의 정문 역할을 합니다. 이 문이 약한 비밀번호, 직접적인 루트 로그인 또는 전체 인터넷 트래픽을 허용한다면 공격자가 빠르게 찾아낼 것입니다.

이 가이드는 일반적인 Linux 배포판에서 OpenSSH에 적용할 수 있는 10가지 실용적인 SSH 서버 보안 강화 단계를 제공합니다. 각 변경 사항을 테스트하는 동안 하나의 작업 세션을 열어 두어 방화벽 규칙이나 구성 편집으로 새 로그인이 차단되는 경우 복구할 수 있도록 하세요.

1. 기본 SSH 포트 변경

기본 SSH 포트는 22입니다. 이는 전 세계적으로 알려져 있으며 취약한 서버를 찾는 자동화된 봇에 의해 지속적으로 스캔됩니다. 기본 포트를 변경하면 간단하지만 효과적인 난독화 계층을 제공합니다. 자체적으로 보안 조치는 아니지만 자동 스캔의 노이즈를 크게 줄이고 많은 기회주의적 공격을 피하는 데 도움이 됩니다.

포트를 변경하려면 일반적으로 /etc/ssh/sshd_config에 있는 sshd_config 파일을 편집하세요.

sudo nano /etc/ssh/sshd_config

Port 22 줄을 찾아(또는 없는 경우 추가) 22를 비표준, 할당되지 않은 포트 번호(예: 2222, 49152-65535는 사용자/동적 포트)로 변경하세요.

#Port 22
Port 2222

SSH를 다시 시작하기 전에 방화벽에서 새 포트를 허용하세요. 그런 다음 포트 22에 대한 접근을 제거하기 전에 새 포트에서 새 로그인을 테스트하세요.

# UFW(Uncomplicated Firewall)의 경우:
sudo ufw allow 2222/tcp
sudo ufw reload

# Firewalld의 경우:
sudo firewall-cmd --permanent --add-port=2222/tcp
sudo firewall-cmd --reload

sudo sshd -t
sudo systemctl restart sshd

팁: 구성 변경을 테스트하는 동안 항상 하나 이상의 SSH 세션을 열어 두세요. 잠기면 활성 세션에서 변경 사항을 되돌릴 수 있습니다.

2. 루트 로그인 비활성화

SSH를 통한 직접 루트 로그인은 매우 권장되지 않습니다. root 사용자는 제한 없는 권한을 가지므로 공격자의 주요 대상이 됩니다. 공격자가 루트 액세스 권한을 얻으면 시스템을 완전히 제어할 수 있습니다. 대신 일반 권한이 없는 사용자로 로그인한 다음 sudo를 사용하여 관리 작업을 수행하세요.

sshd_config에서 PermitRootLogin 지시문을 찾아 no로 설정하세요.

PermitRootLogin no

저장하고 SSH 서비스를 다시 시작하세요:

sudo systemctl restart sshd

3. 키 기반 인증 사용

비밀번호 기반 인증은 특히 사용자가 약한 비밀번호를 선택하는 경우 무차별 대입 공격 및 사전 공격에 취약합니다. SSH 키 기반 인증은 훨씬 더 안전한 대안입니다. 서버에 저장된 공개 키와 로컬 시스템에 보관된 개인 키의 쌍을 사용합니다. 일치하는 개인 키를 가진 클라이언트만 인증할 수 있습니다.

키 기반 인증 구현 단계(간략히):

  1. 로컬 시스템에서 키 쌍 생성:

    ssh-keygen -t ed25519 -C "[email protected]"
    • ed25519는 고정 키 크기의 현대적이고 안전한 알고리즘입니다. rsa도 일반적입니다. RSA를 사용하는 경우 ssh-keygen -t rsa -b 4096과 같은 큰 키를 생성하세요.

  2. 공개 키를 서버에 복사:

    ssh-copy-id -i ~/.ssh/id_ed25519.pub user@your_server_ip

    또는 서버에서 로그인하려는 사용자의 ~/.ssh/authorized_keys에 ~/.ssh/id_ed25519.pub의 내용을 수동으로 추가하세요.

  3. 서버에서 올바른 권한 확인:

    • ~/.ssh 디렉토리: 700(소유자만 rwx)
    • ~/.ssh/authorized_keys 파일: 600(소유자만 rw)
    chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

4. 비밀번호 인증 비활성화

필요한 모든 사용자에 대해 키 기반 인증을 성공적으로 설정하고 테스트한 후에는 비밀번호 인증을 완전히 비활성화해야 합니다. 이렇게 하면 무차별 대입 비밀번호 공격이 불가능해져 SSH 보안에서 가장 약한 연결 고리가 제거됩니다.

sshd_config에서 PasswordAuthentication을 no로 설정하세요.

PasswordAuthentication no
KbdInteractiveAuthentication no

일부 배포판에서는 PAM 또는 키보드 대화형 인증이 비활성화하지 않으면 여전히 비밀번호를 요구할 수 있습니다. 기존 세션을 닫기 전에 새 터미널로 테스트하세요.

저장하고 SSH 서비스를 다시 시작하세요:

sudo systemctl restart sshd

경고: 액세스가 필요한 모든 사용자에 대해 키 기반 인증이 올바르게 작동하는지 확인하기 전에는 절대 비밀번호 인증을 비활성화하지 마세요. 그렇지 않으면 서버에서 잠길 위험이 있습니다.

5. 사용자 액세스 제한

기본적으로 서버의 모든 사용자 계정은 SSH를 통해 로그인을 시도할 수 있습니다. 특정 사용자 또는 그룹으로 SSH 액세스를 제한하여 공격 표면을 최소화할 수 있습니다.

sshd_config에서 AllowUsers 또는 AllowGroups 지시문을 사용하세요.

특정 사용자(예: adminuser, devuser)만 허용하려면:

AllowUsers adminuser devuser

특정 그룹(예: sshusers)의 구성원만 허용하려면:

AllowGroups sshusers

팁: 여러 사용자가 있는 경우 AllowGroups를 사용하는 것이 일반적으로 더 좋습니다. SSH 액세스 전용 그룹을 만들고 승인된 사용자를 추가하세요.

sudo groupadd sshusers
sudo usermod -aG sshusers adminuser
sudo usermod -aG sshusers devuser

변경 후 저장하고 SSH를 다시 시작하세요.

6. SSH 키에 강력한 암호 사용

키 기반 인증은 강력하지만 개인 키는 여전히 중요한 자산입니다. 공격자가 로컬 시스템에 액세스하면 개인 키를 훔칠 수 있습니다. 강력한 암호는 개인 키를 암호화하여 사용하기 전에 암호를 해제해야 합니다. 이는 키가 잘못된 손에 들어가더라도 보호하는 추가 보안 계층을 제공합니다.

SSH 키를 생성할 때(3단계에서) 암호를 묻는 메시지가 표시됩니다. 다른 비밀번호와 다른 길고 복잡하며 기억하기 쉬운 암호를 선택하세요.

7. 연결 속도 제한 구현(Fail2Ban)

키 기반 인증을 사용하더라도 SSH 서버는 여전히 연결 시도에 노출됩니다. Fail2Ban과 같은 도구는 SSH 로그를 적극적으로 모니터링하여 동일한 IP 주소에서 반복된 로그인 실패 시도를 감지하고 방화벽 규칙을 사용하여 해당 IP 주소를 설정된 기간 동안 자동으로 차단할 수 있습니다.

설치(Debian/Ubuntu 예시):

sudo apt update
sudo apt install fail2ban

Fail2Ban은 기본 SSH 규칙으로 즉시 작동하지만 jail.conf를 jail.local에 복사하고 편집하여 구성을 사용자 지정할 수 있습니다.

sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
sudo nano /etc/fail2ban/jail.local

jail.local 내에서 [sshd] 섹션의 bantime, findtime 및 maxretry를 조정할 수 있습니다.

[sshd]
enabled = true
port = 2222 # 새 SSH 포트
logpath = %(sshd_log)s
maxretry = 3
bantime = 1h
findtime = 10m

구성 변경 후 Fail2Ban을 다시 시작하세요:

sudo systemctl restart fail2ban

8. SSH 서버 소프트웨어 업데이트 유지

소프트웨어 취약점은 지속적으로 발견되고 패치됩니다. 오래된 SSH 데몬 소프트웨어(OpenSSH)를 실행하면 알려진 익스플로잇에 노출될 수 있습니다. OpenSSH 서버 패키지를 포함한 서버 소프트웨어를 정기적으로 업데이트하는 것은 보안 취약점을 패치하는 데 중요합니다.

# Debian/Ubuntu의 경우:
sudo apt update && sudo apt upgrade

# CentOS/RHEL의 경우:
sudo yum update
# 또는
sudo dnf update

적절한 경우 시스템이 보안 업데이트를 자동으로 적용하도록 구성하거나 수동 업데이트를 위한 일정을 수립하세요.

9. 의심스러운 활동에 대한 SSH 로그 모니터링

강력한 예방 조치가 있더라도 경계가 중요합니다. 비정상적인 패턴, 로그인 실패 시도 또는 무단 액세스 시도를 감지하기 위해 SSH 인증 로그를 정기적으로 검토하세요. 이는 잠재적인 침해 또는 진행 중인 공격을 식별하는 데 도움이 됩니다.

SSH 로그는 일반적으로 다음 위치에 있습니다:

  • /var/log/auth.log (Debian/Ubuntu)
  • /var/log/secure (CentOS/RHEL)
  • journalctl 사용(systemd 시스템):
    sudo journalctl -u sshd -f

반복된 인증 실패, 비정상적인 IP 주소에서의 로그인 또는 익숙하지 않은 사용자의 성공적인 로그인을 찾으세요. Logwatch 또는 Elastic Stack(ELK)과 같은 도구는 대규모 환경에서 로그 분석 및 알림을 자동화할 수 있습니다.

10. 액세스를 제한하는 방화벽 규칙 구성

방화벽은 첫 번째 방어선입니다. 기본적으로 명시적으로 노출해야 하는 서비스를 제외한 모든 수신 트래픽을 차단해야 합니다. SSH의 경우 선택한 포트(예: 2222)에서만, 이상적으로는 특정 신뢰할 수 있는 IP 주소 또는 네트워크에서만 연결을 허용하는 것을 의미합니다.

UFW(Uncomplicated Firewall) 예시:

특정 IP 주소 192.168.1.100에서 포트 2222로 SSH 허용:

sudo ufw allow from 192.168.1.100 to any port 2222

특정 서브넷 192.168.1.0/24에서 SSH 허용:

sudo ufw allow from 192.168.1.0/24 to any port 2222

Firewalld(CentOS/RHEL) 예시:

특정 IP 주소 192.168.1.100에서 포트 2222로 SSH 허용:

sudo firewall-cmd --permanent --zone=public --add-rich-rule='rule family="ipv4" source address="192.168.1.100" port port=2222 protocol="tcp" accept'
sudo firewall-cmd --reload

경고: 동적 IP 주소에서 서버를 관리하는 경우 엄격한 방화벽 규칙에 주의하세요. 더 넓은 범위에서의 액세스를 허용하거나 VPN을 사용해야 할 수 있습니다.

추가 보안 강화 팁

필수 가지 외에도 더 큰 보안을 위해 다음 지시문을 고려하세요:

  • MaxAuthTries: 연결당 인증 시도 횟수를 제한합니다. 기본값은 6입니다. 낮추면(예: 3) 무차별 대입 가능성이 줄어듭니다. sshd_config에서 설정.
    MaxAuthTries 3
  • LoginGraceTime: 사용자가 인증할 수 있는 시간을 제한합니다. 기본값은 2분입니다. 낮추면(예: 30s) 느린 공격의 시간이 줄어듭니다.
    LoginGraceTime 30s
  • ClientAliveInterval 및 ClientAliveCountMax: 유휴 SSH 세션이 무기한 열려 있는 것을 방지합니다. ClientAliveInterval은 X초마다 keepalive 메시지를 보냅니다. ClientAliveCountMax 응답이 누락되면 연결이 종료됩니다.
    ClientAliveInterval 300
ClientAliveCountMax 2
  • Banner: 인증 전에 경고 메시지를 표시합니다. 이는 잠재적인 무단 사용자에게 법적 고지를 제공합니다.
    Banner /etc/issue.net
    원하는 경고 메시지로 /etc/issue.net 파일을 만드세요.

실용적인 요점

가장 큰 위험을 제거하는 변경 사항부터 시작하세요: 루트 로그인 비활성화, SSH 키 요구, 연결할 수 있는 사용자 제한, 가능한 경우 소스 네트워크 제한. 현재 세션을 닫기 전에 sshd -t 및 새 로그인 세션으로 모든 변경 사항을 테스트하세요.