071. 계정 · 인증 보안 — invalid user와 계정 열거 시도 판별

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

선행 학습

• 020. 계정 · 인증 보안 — SSH 인증 실패 로그 분석
• 071. 계정 · 인증 보안 — brute-force 징후

1. 개념

계정 열거는 "어떤 계정이 실제로 존재하는가"를 알아내는 정찰 단계입니다. 공격자는 흔한 계정명 사전으로 로그인을 시도하고, 서버 반응으로 존재 여부를 추정합니다.

존재하지 않는 계정:  Invalid user oracle / Failed password for invalid user oracle
존재하는 계정:        Failed password for devops (invalid user 없음)
   │
   └─ 이 차이로 "oracle은 없고 devops는 있다"를 알아냄 = 열거

시도 계정명의 성격
 사전형: oracle, test, admin, user, git, jenkins, postgres, ubuntu ...  (흔한 이름)
 표적형: 실제 직원명·조직 규칙 계정(gildong.hong, it_admin) → 내부 정보 보유 의심

2. 왜 중요한가

• 열거는 brute-force의 준비 단계입니다. 존재하는 계정을 먼저 찾아 그 계정에 추측을 집중합니다(072편).
• 사전형 열거는 인터넷에 노출된 서버에 흔한 자동화지만, 표적형 열거(실제 직원명·내부 규칙 계정)는 내부 정보를 아는 공격자를 시사해 위험도가 높습니다.
• 열거 시도 계정명 목록은 공격자가 가진 정보 수준을 보여주는 단서입니다.

3. 핵심 명령어 / 설정

확인	명령
invalid user 계정명	sudo grep 'Invalid user' /var/log/secure | awk '{print $(NF-3)}' | sort | uniq -c | sort -rn
출발지별 시도 계정 수	출발지별 고유 계정명 집계
사전형 vs 표적형	계정명이 흔한 이름인지, 조직 규칙인지
존재 계정 적중	invalid 없이 Failed password for <user>로 바뀐 계정
시간 분포	짧은 시간 집중 = 자동화

4. 실습 (실습 예시)

LOG=/var/log/secure        # Ubuntu: /var/log/auth.log
# 1) 시도된 비존재 계정명 Top
sudo grep 'Invalid user' $LOG | awk '{for(i=1;i<=NF;i++)if($i=="user"){print $(i+1);break}}' | sort | uniq -c | sort -rn | head -20

# 2) 출발지별 고유 계정 수 (분산 열거 식별)
sudo grep 'Invalid user' $LOG | sed -E 's/.*user ([^ ]+) from ([0-9.]+).*/\2 \1/' | sort -u | awk '{c[$1]++} END{for(i in c) print c[i], i}' | sort -rn | head

# 3) 표적형 의심: 조직 계정 규칙과 일치하는 시도 (예: 이름.성 형식)
sudo grep 'Invalid user' $LOG | grep -E 'user [a-z]+\.[a-z]+ ' | head

5. 정상 상태

      2 test
      1 admin
$ (출발지별) 2 192.168.56.90

간헐적인 흔한 이름 시도 소수만 있는 상태로, 인터넷 배경 소음 수준입니다(내부망이라면 이것도 확인 대상).

6. 이상 상태

     18 oracle
     15 test
     14 admin
     12 git
      9 jenkins
      2 gildong.hong
      2 it_admin
$ (출발지별 고유 계정 수) 48 192.168.56.77

• 한 출발지(.77)가 48개 계정명을 시도 → 대규모 사전 열거
• 사전형(oracle, git, jenkins) + 표적형(gildong.hong, it_admin) 혼재 → 조직 정보 일부 보유 의심
• 072편에서 이 중 실존 계정(devops 등)으로 추측이 이어졌는지 확인

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

열거에서 표적 확정으로 넘어가는 흐름입니다(가상의 예시 로그).

02:09:50 sshd: Invalid user oracle from 192.168.56.77
02:09:51 sshd: Invalid user jenkins from 192.168.56.77
02:09:53 sshd: Invalid user it_admin from 192.168.56.77
02:10:05 sshd: Failed password for devops from 192.168.56.77   ← invalid 없음 = devops 실존
02:10:41 sshd: Failed password for devops from 192.168.56.77
02:10:44 sshd: Accepted password for devops from 192.168.56.77

단계	의미
다수 Invalid user	사전 열거
it_admin 표적형 시도	내부 규칙 추정
Failed ... devops(invalid 아님)	devops 실존 확인
이후 추측·성공	열거 → 표적 → 돌파

8. SOC 관제 포인트

• Invalid user 시도 계정명을 집계해 사전형/표적형을 구분합니다. 표적형은 우선순위를 높입니다.
• 출발지별 고유 계정 수로 대규모 열거를 탐지합니다.
• 열거 직후 실존 계정으로 바뀐 시도(invalid → 그냥 Failed)를 072편으로 넘깁니다.

9. 탐지 규칙

<group name="local,syssec_b,authentication,">
  <rule id="101190" level="10" frequency="10" timeframe="120">
    <if_matched_sid>5710</if_matched_sid>
    <same_source_ip />
    <description>단일 출발지의 다수 비존재 계정 시도(계정 열거)</description>
  </rule>
</group>

5710은 Wazuh의 "non existent user" 룰입니다. 표적형(조직 계정명) 탐지는 직원 계정 명명 규칙을 CDB 리스트로 만들어 매칭하면 내부 정보 기반 공격을 가려낼 수 있습니다.

10. 대응 방법

1. 초기 확인 — 시도된 계정명을 집계해 사전형/표적형과 출발지를 확인합니다.
2. 범위 확인 — 열거 이후 실존 계정으로 추측이 이어졌는지(072편), 다른 서버 열거를 확인합니다.
3. 증거 확보 — invalid user 로그와 집계 결과를 보존합니다.
4. 차단/조치 — 출발지 차단, 표적형에 등장한 실존 계정 보호 조치를 진행합니다.
5. 재발 방지 — 계정 열거 상관 룰과 조직 계정명 CDB 매칭을 운영합니다.

11. 핵심 정리

구분	핵심 내용
열거	invalid user 반응 차이로 실존 계정 추정
사전형	oracle, test, admin 등 흔한 이름(배경 소음·자동화)
표적형	직원명·조직 규칙 계정 → 내부 정보 보유 의심
판별	출발지별 고유 계정 수, 계정명 성격
면접 포인트	"표적형 열거는 내부 정보를 아는 공격자 신호"

12. 다음 편 예고

다음 편 072. 계정 · 인증 보안 — brute-force 징후 — 빈도·분포 분석 에서는 찾아낸 계정을 추측하는 brute-force 징후 — 빈도·분포 분석을 다룹니다.

---

이전 편: 070. 계정 · 인증 보안 — SSH 인증 실패 로그 분석
📚 시리즈 전체 보기: 시스템 보안 · 취약점