SSH Brute Force 공격이 Linux 서버에 미치는 영향과 분석 방법

Linux 서버의 SSH 포트를 인터넷에 공개해 두면 어느 순간부터 /var/log/auth.log 또는 /var/log/secure에 수많은 로그인 실패 기록이 남는 것을 볼 수 있다.

Failed password for root from 203.0.113.10 port 52144 ssh2
Failed password for invalid user admin from 203.0.113.10 port 52201 ssh2
Invalid user oracle from 198.51.100.20 port 41432

관리자가 접속한 적도 없는 IP에서 root, admin, oracle 같은 계정으로 로그인 시도가 반복된다면 SSH Brute Force 공격일 가능성이 높다.

SSH Brute Force는 단순히 비밀번호를 계속 틀리는 공격으로만 생각하기 쉽다. 하지만 서버에서는 공격자가 접속을 시도할 때마다 TCP Connection 생성, SSH 프로토콜 협상, 사용자 인증, 로그 기록 등의 작업이 실제로 발생한다.

공격 규모가 커지면 보안 문제뿐 아니라 서버 Connection과 CPU, 로그, SSH 관리 접속에도 영향을 줄 수 있다.

이번 글에서는 SSH Brute Force 공격이 발생했을 때 Linux 서버 내부에서 어떤 일이 일어나는지와 실제 운영 환경에서 어떻게 분석하고 대응해야 하는지를 살펴본다.

1. SSH Brute Force 공격은 왜 계속 발생할까?

인터넷에 공개된 서버는 자동화된 스캐너의 탐색 대상이 된다.

공격자는 특정 서버만 골라서 공격하기보다 많은 IP 대역을 자동으로 검색하면서 SSH 서비스가 열려 있는 서버를 찾는 경우가 많다.

SSH의 기본 포트인 TCP 22번이 열려 있으면 이후 흔히 사용하는 계정과 비밀번호 조합을 반복해서 입력한다.

대표적인 대상은 다음과 같다.

root
admin
ubuntu
oracle
test
user

여기서 중요한 점은 로그인 시도 하나가 단순히 ID와 비밀번호 문자열만 서버에 전달하는 작업이 아니라는 것이다.

공격자가 SSH 인증 단계까지 도달하려면 먼저 서버와 TCP Connection을 만들어야 한다.

공격 Client
     │
     │ TCP 3-Way Handshake
     ▼
Linux Kernel
     │
     ▼
TCP Connection 생성
     │
     ▼
sshd
     │
     ▼
SSH 인증 시도

따라서 SSH Brute Force는 보안 로그만의 문제가 아니라 Linux 네트워크 Connection과도 연결된 문제다.

2. SSH 로그인 한 번에 서버 내부에서는 어떤 일이 일어날까?

클라이언트가 SSH 접속을 시작하면 Linux Kernel이 먼저 TCP 연결을 처리한다.

TCP 3-Way Handshake가 완료되면 연결은 일반적으로 ESTABLISHED 상태가 되고 이후 sshd가 SSH 프로토콜을 처리한다.

과정을 단순화하면 다음과 같다.

TCP Connection 생성
        ↓
SSH 프로토콜 협상
        ↓
암호화 방식 협상
        ↓
Key Exchange
        ↓
사용자 인증
        ↓
로그인 성공 또는 실패
        ↓
로그 기록

정상적인 관리자가 몇 번 SSH에 접속하는 정도라면 서버에 미치는 영향은 거의 없다.

하지만 여러 IP에서 짧은 시간 동안 수백 또는 수천 번의 연결과 인증 시도가 발생하면 이야기가 달라진다.

서버는 새로운 TCP 연결을 받아야 하고 sshd는 인증 전 연결을 관리하면서 SSH 협상과 인증 작업을 반복해야 한다. 로그인에 실패하면 해당 내용도 로그에 기록된다.

따라서 공격량이 많아질수록 네트워크 Connection, sshd 처리량, CPU 사용량, 로그 발생량이 함께 증가할 수 있다.

3. SYN Flood와 SSH Brute Force는 무엇이 다를까?

SSH Brute Force를 분석할 때 SYN Flood와 혼동하지 않는 것이 중요하다.

SYN Flood는 TCP 3-Way Handshake가 완료되기 전 단계의 연결을 대량으로 발생시켜 서버의 SYN Queue를 압박하는 공격이다.

SYN
 ↓
SYN_RECV
 ↓
Handshake 미완료

반면 SSH Brute Force는 일반적으로 TCP 연결을 정상적으로 완료한 뒤 SSH 인증 단계까지 들어온다.

TCP Handshake 완료
        ↓
ESTABLISHED
        ↓
SSH 프로토콜 처리
        ↓
ID / Password 인증 실패

따라서 SSH 로그인 실패 로그가 많다고 해서 반드시 SYN_RECV Connection도 많아지는 것은 아니다.

SYN_RECV가 비정상적으로 증가한다면 TCP 연결 단계의 공격을 확인해야 하고, TCP 연결은 정상적으로 만들어지는데 SSH 인증 실패가 급증한다면 SSH 인증 단계의 공격을 의심해야 한다.

이 차이를 이해해야 장애 분석 방향을 제대로 잡을 수 있다.

4. 실제 서버에서는 어떤 증상이 나타날까?

소규모 SSH Brute Force라면 인증 실패 로그만 증가하고 실제 서비스에는 거의 영향이 없을 수 있다.

하지만 공격 규모가 커지면 다음과 같은 현상이 발생할 수 있다.

SSH 인증 실패 로그 급증
sshd 관련 처리 증가
SSH Connection 증가
CPU 사용량 상승
로그 파일 크기 증가
관리자의 SSH 접속 지연
새로운 SSH 연결 거부

특히 sshd에는 아직 인증이 완료되지 않은 Connection이 무제한으로 들어오는 것을 방지하기 위한 제어 기능이 있다.

공격으로 인증 전 연결이 많아지면 새로운 연결이 제한될 수 있고, 상황에 따라 정상적인 관리자의 SSH 접속에도 영향을 줄 수 있다.

그렇다고 Failed password 로그 몇백 개만 보고 서버 장애라고 판단해서는 안 된다.

실제 운영에서는 공격의 존재보다 먼저 공격이 서버 자원과 정상 서비스에 영향을 주고 있는지를 확인해야 한다.

5. SSH Brute Force는 어떻게 분석할까?

가장 먼저 인증 로그를 확인한다.

Ubuntu나 Debian 계열에서는 주로 다음 파일을 사용한다.

grep "Failed password" /var/log/auth.log

RHEL 계열에서는 환경에 따라 /var/log/secure에서 확인할 수 있다.

grep "Failed password" /var/log/secure

systemd journal을 사용한다면 다음과 같이 최근 기록을 볼 수도 있다.

journalctl -u sshd --since "1 hour ago"

여기서 중요한 것은 실패 기록이 존재하는지를 보는 것이 아니라 어떤 IP에서 얼마나 많은 시도가 발생하고 있는지 확인하는 것이다.

예를 들어 인증 실패 Source IP를 집계할 수 있다.

grep "Failed password" /var/log/auth.log \
| awk '{print $(NF-3)}' \
| sort \
| uniq -c \
| sort -nr \
| head

특정 IP에서 짧은 시간 동안 수백 번 이상 실패가 발생한다면 자동화된 공격을 의심할 수 있다.

로그 다음에는 현재 TCP Connection을 확인한다.

ss -tn | grep ':22'

그리고 SYN 단계에 Connection이 과도하게 쌓여 있는지도 확인한다.

ss -tn state syn-recv

SSH 공격과 서버 부하가 실제로 연관되어 있는지 확인하려면 프로세스와 CPU도 같이 본다.

ps -eo pid,ppid,pcpu,pmem,cmd --sort=-pcpu | grep '[s]shd'

top

이렇게 로그 → TCP Connection → 프로세스 → 시스템 자원 순서로 확인하면 단순한 로그인 스캔인지 실제 서버에 영향을 주는 공격인지 판단하기 쉬워진다.

6. SSH Brute Force는 어떻게 막아야 할까?

가장 좋은 방법은 공격 IP를 발견할 때마다 하나씩 차단하는 것이 아니다.

가능하다면 SSH 인증 구조 자체를 강화해야 한다.

먼저 SSH Key 기반 인증을 사용하는 방법을 고려할 수 있다.

Key 인증이 정상적으로 구성된 환경이라면 비밀번호 인증을 비활성화함으로써 비밀번호를 반복 입력하는 형태의 공격 위험을 크게 줄일 수 있다.

PubkeyAuthentication yes
PasswordAuthentication no
PermitRootLogin no

다만 운영 서버에서는 기존 SSH 세션을 종료하기 전에 새로운 설정으로 실제 접속이 가능한지 반드시 확인해야 한다.

설정 문법도 점검한다.

sshd -t

관리자 IP나 VPN 대역을 알고 있다면 방화벽이나 클라우드 Security Group에서 SSH 접근 Source를 제한하는 방법도 효과적이다.

Internet
   │
   ▼
Firewall / Security Group
   │
   ├─ 허용된 관리 IP → SSH 허용
   │
   └─ 기타 IP → 차단

가능한 환경이라면 공격 트래픽이 sshd에 도달하기 전에 차단하는 것이 가장 단순하다.

OpenSSH의 MaxAuthTries, LoginGraceTime, MaxStartups 설정도 확인할 수 있다.

MaxAuthTries는 Connection당 허용할 인증 시도 횟수와 관련되고, LoginGraceTime은 인증을 완료할 때까지 허용하는 시간을 제한한다.

MaxStartups는 아직 인증되지 않은 동시 SSH Connection을 제어한다.

현재 적용된 값은 다음과 같이 확인할 수 있다.

sshd -T | grep -E 'maxauthtries|maxstartups|logingracetime'

이 값들은 무조건 낮추는 것이 좋은 것이 아니다. 여러 관리자가 동시에 접속하거나 자동화 시스템이 SSH를 사용하는 서버라면 정상 연결까지 차단될 수 있기 때문에 실제 운영 환경을 기준으로 결정해야 한다.

Fail2ban처럼 반복적인 로그인 실패 IP를 자동으로 차단하는 도구를 추가적인 방어 수단으로 사용할 수도 있다.

7. SSH 포트만 변경하면 해결될까?

SSH 기본 포트인 22번을 다른 포트로 변경하면 22번만 무작위로 스캔하는 자동화 봇의 접근을 줄일 수 있다.

따라서 인증 로그가 눈에 띄게 줄어드는 효과는 있을 수 있다.

하지만 이것을 근본적인 보안 대책으로 생각해서는 안 된다.

공격자가 포트 스캔을 수행하면 다른 포트에서 실행 중인 SSH 서비스도 찾을 수 있기 때문이다.

SSH 포트 변경은 공격 노출과 불필요한 로그를 줄이는 보조적인 방법이고, 실제 보안의 중심은 Key 인증, 접근 가능한 Source IP 제한, root 직접 로그인 제한과 같은 인증 및 접근 제어에 두는 것이 좋다.

8. 정리

SSH Brute Force 공격이 발생하면 서버에서는 단순히 비밀번호 확인만 이루어지는 것이 아니다.

먼저 TCP Connection이 만들어지고 이후 SSH 프로토콜 협상과 사용자 인증, 실패 로그 기록 등의 과정이 반복된다.

따라서 공격 규모가 커지면 SSH 인증 실패뿐 아니라 Connection 증가, sshd 처리 증가, CPU와 로그 사용량 증가, 정상적인 SSH 접속 지연까지 나타날 수 있다.

실제 장애 분석에서는 다음 흐름으로 접근하면 된다.

SSH 인증 실패 확인
        ↓
공격 Source IP 분석
        ↓
TCP Connection 상태 확인
        ↓
sshd 및 CPU 상태 확인
        ↓
정상 서비스 영향 확인
        ↓
SSH 인증 및 접근 정책 강화

핵심은 Failed password 로그가 많다는 사실만 보는 것이 아니다.

공격이 TCP 연결 단계에서 발생하는지, SSH 인증 단계에서 발생하는지, 그리고 실제 서버 자원에 어떤 영향을 주고 있는지를 구분해야 한다.

이렇게 접근하면 SSH Brute Force를 단순한 보안 경고가 아니라 Linux 서버의 Connection과 인증 처리 구조라는 관점에서 분석할 수 있다.