Linux용 OpenSSH 보안 강화 가이드

SSH는 Linux 플랫폼에서 시스템 관리를 위해 가장 널리 사용되는 프로토콜 중 하나입니다. Unix, Linux 및 MacOS 기반의 많은 운영 체제에서 사용할 수 있습니다. 클라이언트-서버 모델을 기반으로 하며, 한 머신은 서버 구성 요소를 실행하고 다른 머신은 클라이언트 도구를 사용하여 접근합니다.

SSH는 어떻게 작동하나요?

클라이언트(ssh)는 서버에 요청을 보내 연결을 시작합니다. 서버는 서버 데몬(sshd)을 사용하여 들어오는 요청을 수신 대기합니다. 서버는 자신의 공개 키를 사용하여 연결하려는 클라이언트에게 자신을 인증합니다:

이러한 방식으로 클라이언트는 올바른 SSH 서버에 연결하고 있다는 것을 확신할 수 있습니다. 이렇게 되면 클라이언트는 서버에 접근할 수 있습니다. Windows 클라이언트를 사용하는 경우, 서버에 연결하기 위해 putty와 같은 도구를 사용해야 합니다. 클라이언트와 서버는 동일한 시스템에 설치될 수 있으며, 이는 클라이언트 도구를 사용하여 다른 머신에 접근하거나 시스템 자체가 다른 사람들이 접근할 수 있는 서버가 될 수 있음을 의미합니다. 이러한 경우 구성 파일은 동일한 디렉토리에 있지만 약간 다른 이름으로 배치됩니다. 디렉토리 위치는 ‘/etc/ssh’이며, ssh 클라이언트 구성 파일의 이름은 ‘ssh_config’이고 서버의 구성 파일 이름은 ‘sshd_config’입니다:

시스템에 두 파일이 모두 있는 경우, 어떤 파일을 구성해야 할지 신중하게 선택해야 합니다. 대부분의 경우, 시스템에 대한 잠재적 접근을 열어주는 서버를 보안하기 위해 구성해야 합니다.

먼저 서버에서 SSH 데몬 또는 sshd의 상태를 확인하는 것부터 시작합니다. 이렇게 하면 sshd가 실행 중인지 및 부팅 시 자동으로 시작되도록 활성화되어 있는지 확인할 수 있습니다. 아래 명령어로 sshd 상태를 확인할 수 있습니다:

$ systemctl status ssh.service

또는 아래 명령어를 사용할 수 있습니다:

$ systemctl status sshd.service

스크린샷에서 서비스가 활성화되고 사용 가능하다는 것을 확인할 수 있습니다. 지난 6시간 동안 실행되고 있습니다. 오른쪽 화살표를 눌러 터미널 뷰를 확장하면 기본 포트 22에서 수신 대기하고 있다는 것을 알 수 있습니다.

때때로 SSH를 사용하여 원격 시스템에 연결되어 있을 때 SSH 구성 파일을 변경합니다. 이러한 경우 재시작 명령 대신 다시 로드 명령을 사용해야 합니다. 이렇게 하면 연결이 끊어질 가능성이 줄어듭니다.

모범 사례를 사용한 SSH 구성

이제 SSH 서버 구성을 시작할 시간이라고 생각합니다. SSH 구성 파일을 수정하기 전에 기본 설정으로 파일의 백업을 만들어야 합니다:

$ sudo cp /etc/ssh/sshd_config ~/sshd_config.bkp

백업을 수행한 후, 기본 파일을 망가뜨려 SSH가 작동하지 않게 되더라도 백업 파일을 사용하여 정상으로 되돌릴 수 있습니다.

1. 기본 포트 변경

sshd 데몬은 기본적으로 서버의 포트 22에서 수신 대기합니다. 이 값을 다른 숫자로 변경하여 스크립트를 사용한 자동화된 공격의 범위를 줄이는 것이 좋습니다. 이 접근 방식은 보안을 통한 모호성이라고 합니다. 이를 위해 아래 파일을 열고 ‘#Port 22’라는 텍스트가 포함된 줄을 찾습니다.

$ sudo nano /etc/ssh/sshd_config

‘#Port 22’ 줄의 주석을 제거하고 ‘22’를 시스템에서 사용 중이지 않은 다른 포트 번호로 변경합니다. 우리는 ‘222’로 변경하고 서비스를 재시작했습니다. 이제 ‘p’ 옵션을 사용하여 새로운 포트를 지정하여 ssh 명령을 사용합니다:

$ ssh user@system_ip -p 222

2. 루트 사용자로 로그인 비활성화

루트는 시스템의 모든 리소스에 접근할 수 있는 궁극적인 사용자입니다. 엄격한 루트 접근이 필요하지 않은 경우, 서버에서 루트 로그인 기능을 비활성화해야 합니다. 이를 위해 위의 파일을 엽니다:

$ sudo nano /etc/ssh/sshd_config

그리고 ‘PermitRootLogin’ 매개변수를 ‘no’로 설정합니다. 이렇게 하면 루트 계정을 대상으로 하는 무작위 공격으로부터 서버가 보호됩니다. 기본 옵션은 ‘prohibit-password’로, 공개 키 인증을 기반으로 한 로그인을 허용하지만 비밀번호 기반 로그인을 거부합니다.

3. 프로토콜 버전 설정

SSH의 이전 프로토콜 버전은 1이며 SSH2에 비해 보안성이 떨어지고 서로 호환되지 않습니다. 서버에서 어떤 프로토콜 버전이 활성화되어 있는지 확인하려면 sshd_config 파일을 다시 열고 ‘Protocol’이라는 줄을 찾습니다:

$ cat /etc/ssh/sshd_config | grep ‘Protocol’

출력이 비어 있는 경우, OpenSSH는 아마도 버전 2를 사용하고 있을 것입니다. 이는 우리의 경우와 같았습니다. 또 다른 방법은 netcat 명령 유틸리티를 사용하는 것입니다:

$ nc localhost 22

샘플 출력:

SSH-2.0-OpenSSH_8.2p1 Ubuntu-4ubuntu0.4

출력에서 SSH2가 시스템에서 활성화되어 있음을 확인할 수 있습니다.

원격 서버가 어떤 프로토콜 버전을 실행하고 있는지 확인하려면 -Q(쿼리) 옵션을 사용하여 SSH 클라이언트를 통해 연결을 시도합니다:

$ ssh -Q protocol-version user@server_name

위 이미지는 Kali Linux에서 Ubuntu SSH 서버에 접근할 때 SSH 버전 2를 보여줍니다.

4. 비밀번호 복잡성

약한 비밀번호는 항상 악용될 가능성이 높으며, 빈 비밀번호는 더 쉽게 악용될 수 있습니다. 따라서 sshd_config 파일에서 PermitEmptyPasswords 옵션을 ‘no’로 설정해야 합니다. 마찬가지로 잘못된 비밀번호로 로그인 시도 횟수를 제한하여 무차별 대입 공격의 가능성을 줄여야 합니다. 이는 ‘MaxAuthTries’ 옵션을 3과 같은 작은 값으로 설정하여 달성할 수 있습니다.

위 그림에서 ‘MaxAuthTries’ 값을 3으로 설정했을 때, 세 번의 잘못된 비밀번호 입력 후 SSH가 거부되는 것을 볼 수 있습니다. 또 다른 주요 보안 측면은 로그인 시 공개 키 인증을 사용하는 것입니다. 키 기반 인증 모델은 무차별 대입 공격에 덜 취약합니다. 마찬가지로 PAM 인증 모듈을 사용하여 SSH 서버를 더욱 강화할 수 있습니다.

결론

이 가이드에서는 SSH 서버를 보호하기 위한 가장 중요한 사항을 다루고 이를 네 가지 주요 사항으로 요약했습니다. 이 가이드는 완전한 것은 아니지만, SSH 서버를 더욱 강화할 수 있는 더 많은 영역을 찾을 수 있습니다. 예를 들어, SSH를 통해 시스템을 사용하는 사용자에게 경고하는 배너 메시지를 추가할 수 있습니다. 비밀번호로 로그인을 거부하고 비밀번호 없는 로그인을 위해 키 기반 인증을 사용할 수도 있습니다. 또 다른 흥미로운 점은 SSH 사용자 수와 연결 시간을 제한할 수 있다는 것입니다.