010. Linux 서버 보안 — SSH 암호 알고리즘·KEX 설정 점검

changseop lee·3일 전

시스템 보안 · 취약점 › A. Linux 서버 보안 설정 · 10/50편 (전체 010/450)
학습 단계: 2단계 · 설정 및 점검
실습 표기: 이 글의 명령어·출력·로그는 로컬 VMware 테스트 VM(Rocky Linux 9 / Ubuntu 22.04) 기준의 「실습 예시」이며, IP·계정·호스트명은 가상의 값입니다.

선행 학습

1. 개념

SSH 연결은 사용자 인증 전에 알고리즘 협상을 합니다. 양쪽이 지원 목록을 교환하고, 공통 항목 중 클라이언트 우선순위가 가장 높은 것을 선택합니다.

Client                                    Server
  │── KEXINIT (kex, cipher, mac 목록) ──→ │
  │←─ KEXINIT (kex, cipher, mac 목록) ─── │
  │        공통 알고리즘 선택               │
  │── 키 교환 (예: curve25519-sha256) ──→ │
  │←──────── 암호화 채널 수립 ───────────→ │
  │          이후 사용자 인증 시작           │

점검 대상은 KexAlgorithms, Ciphers, MACs, HostKeyAlgorithms 네 항목입니다.

2. 왜 중요한가

  • diffie-hellman-group1-sha1, CBC 모드 암호, hmac-md5 같은 오래된 알고리즘은 알려진 약점이 있어 취약점 진단에서 지적됩니다.
  • SOC 관점에서는 협상 실패 로그가 유용합니다. 오래된 스캐너·자동화 도구는 구형 알고리즘을 제시하는 경우가 많아, 클라이언트 특성을 추정하는 단서가 됩니다.
  • Rocky 9은 시스템 전체 암호 정책(crypto-policies)이 sshd 알고리즘을 결정하므로 sshd_config만 보면 안 됩니다.

3. 핵심 명령어 / 설정

확인명령
서버 실효 알고리즘sudo sshd -T | grep -E '^(kexalgorithms|ciphers|macs) '
OpenSSH 지원 목록ssh -Q kex, ssh -Q cipher, ssh -Q mac
Rocky 시스템 정책update-crypto-policies --show
실제 협상 결과ssh -vv 서버 exit 2>&1 | grep 'kex: algorithm'

4. 실습 (실습 예시)

# 서버 실효값 확인
sudo sshd -T | grep -E '^(kexalgorithms|ciphers|macs) ' | tr ',' '\n' | head -30

# Rocky: 시스템 암호 정책 확인
update-crypto-policies --show          # DEFAULT

# 테스트 클라이언트 VM에서 협상 결과 확인
ssh -vv admin1@192.168.56.10 exit 2>&1 | grep -E 'kex: algorithm|cipher:'

# Ubuntu: 약한 알고리즘만 제외하는 예 (/etc/ssh/sshd_config.d/10-crypto.conf)
# KexAlgorithms -diffie-hellman-group14-sha1
# MACs -hmac-sha1,hmac-sha1-etm@openssh.com

목록 앞에 -를 붙이면 기본 목록에서 해당 항목만 제외합니다(OpenSSH 7.5 이상).

5. 정상 상태

debug1: kex: algorithm: curve25519-sha256
debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none

chacha20-poly1305나 aes256-gcm 같은 AEAD 암호는 MAC이 내장되어 <implicit>로 표시됩니다.

6. 이상 상태

$ sudo sshd -T | grep ^ciphers
ciphers aes128-cbc,3des-cbc,aes256-ctr
$ update-crypto-policies --show
LEGACY
  • CBC 계열·3DES가 허용되고 시스템 정책이 LEGACY로 낮춰져 있음
  • 구형 장비 호환을 위해 일시적으로 낮추는 경우가 있지만, 누가 언제 바꿨는지 기록이 없다면 이상 징후로 봅니다.

7. 로그 분석 (분석 방법)

약한 알고리즘만 제시한 클라이언트는 협상 단계에서 거절됩니다(가상의 예시 로그).

Oct  1 05:12:44 rocky9-web01 sshd[6021]: Unable to negotiate with 192.168.56.77 port 41822: no matching key exchange method found. Their offer: diffie-hellman-group1-sha1,diffie-hellman-group-exchange-sha1 [preauth]
Oct  1 05:12:45 rocky9-web01 sshd[6023]: Unable to negotiate with 192.168.56.77 port 41824: no matching cipher found. Their offer: aes128-cbc,3des-cbc [preauth]
필드분석
[preauth]인증 전 단계 → 계정 시도 이전
Their offer클라이언트가 제시한 목록 = 클라이언트 종류 추정 단서
짧은 간격 반복여러 조합을 시도하는 자동화 도구 가능성

같은 IP가 다른 포트·서버로 접근하는지 네트워크 로그와 연결합니다(291. Port Scan 탐지 참고).

8. SOC 관제 포인트

  • Unable to negotiate는 실패 로그라 무시하기 쉽지만, 내부망에서 발생하면 구형 자산이나 정찰 도구를 의미할 수 있습니다.
  • update-crypto-policies --set LEGACY 실행은 변경관리 대상으로 관리합니다.
  • 진단 결과(약한 암호 허용)는 자산 정보로 SIEM에 등록해 둡니다.

9. 탐지 규칙

<rule id="100170" level="5">
  <decoded_as>sshd</decoded_as>
  <match>Unable to negotiate with</match>
  <description>SSH 알고리즘 협상 실패(구형 클라이언트/정찰 도구 가능성)</description>
</rule>
<rule id="100171" level="9" frequency="5" timeframe="60">
  <if_matched_sid>100170</if_matched_sid>
  <same_source_ip />
  <description>동일 IP의 SSH 협상 실패 반복</description>
</rule>

단건은 낮은 레벨, 같은 IP 반복은 상향하는 빈도 기반 패턴입니다. 적용 전 wazuh-logtest로 디코더가 srcip를 추출하는지 확인해야 same_source_ip가 동작합니다.

10. 대응 방법

  1. 초기 확인 — 협상 실패 IP와 제시 알고리즘 목록으로 클라이언트 유형을 추정합니다.
  2. 범위 확인 — 해당 IP의 다른 포트·서버 접근을 방화벽/IDS 로그에서 확인합니다.
  3. 증거 확보 — sshd 로그와 crypto-policies 설정 상태를 보존합니다.
  4. 차단/조치 — 허용된 약한 알고리즘을 제거하고 정책을 DEFAULT 이상으로 복원합니다.
  5. 재발 방지 — 암호 정책을 기준선에 포함하고 협상 실패 반복 룰을 운영합니다.

11. 핵심 정리

구분핵심 내용
점검 4항목KexAlgorithms · Ciphers · MACs · HostKeyAlgorithms
Rocky 특징crypto-policies가 시스템 전체 알고리즘 결정
약한 예group1-sha1, CBC, 3DES, hmac-md5
탐지 로그Unable to negotiate ... Their offer [preauth]
면접 포인트"협상 실패 로그의 Their offer로 클라이언트를 추정"

12. 다음 편 예고

다음 편 011. Linux 서버 보안 — SSH 접근 제어 — AllowUsers·AllowGroups·Match 에서는 누가 SSH로 들어올 수 있는지 정하는 AllowUsers·AllowGroups·Match 접근 제어를 다룹니다.


이전 편: 009. Linux 서버 보안 — sshd -T로 SSH 실효 설정 점검하기
📚 시리즈 전체 보기: 시스템 보안 · 취약점

profile
코드에 숨겨진 위협을 읽고 AI로 보안의 미래를 설계합니다. 프론트엔드 개발 경험을 자산 삼아 더 견고하고 지능적인 보안 운영 시스템을 구축해 나가는 과정을 기록합니다

0개의 댓글