086. 계정 · 인증 보안 — 공유 계정·기본 계정 위험 분석

changseop lee·3일 전

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

선행 학습

1. 개념

공유 계정은 여러 사람이 같은 자격증명으로 쓰는 계정(팀 공용 ops, 기본 ubuntu)입니다. 가장 큰 문제는 누가 무엇을 했는지 구분할 수 없다는 것, 즉 책임 추적성(accountability)의 상실입니다.

개인 계정 모델:  hong → sudo → root   (로그: "hong이 했다")
공유 계정 모델:  ops(5명 공용) → root (로그: "ops가 했다" → 5명 중 누구?)

기본 계정(배포판·클라우드 이미지)
 ubuntu, centos, ec2-user, admin, pi ...
 → 이름이 알려져 있어 brute-force·열거의 1순위 표적(071편)

2. 왜 중요한가

  • 공유 계정은 사고 시 행위자를 특정할 수 없어 대응·책임 규명이 막힙니다. auid로 추적해도 "ops"까지만 나옵니다.
  • 기본 계정은 이름이 공개되어 있어 자동화 공격의 표적입니다. 많은 서버가 같은 기본 계정명을 써서 하나의 사전으로 광범위하게 시도됩니다.
  • 공유 계정의 비밀번호는 퇴직·이동 후에도 공유되어 회수가 어렵습니다.

3. 핵심 명령어 / 설정

점검방법
공유 계정 식별여러 출발지·여러 사람이 쓰는 계정(last의 출발지 다양성)
기본 계정 존재getent passwd ubuntu centos ec2-user admin pi
기본 계정 상태셸·비밀번호·SSH 키
전환 방안개인 계정 생성 + sudo, 공유 계정 잠금
추적 보완불가피하면 접속 전 개인 식별(점프호스트·키별 주석)

4. 실습 (실습 예시)

# 1) 기본 계정 존재·상태
for u in ubuntu centos ec2-user admin pi user guest; do
  getent passwd $u >/dev/null && echo "$u: $(sudo passwd -S $u 2>/dev/null | awk '{print $2}') shell=$(getent passwd $u|cut -d: -f7)"
done

# 2) 한 계정을 여러 출발지가 쓰는지 (공유 의심)
for u in ops deploy; do
  getent passwd $u >/dev/null && { echo "== $u 출발지"; last -i $u 2>/dev/null | grep -oE '[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+' | sort | uniq -c; }
done

# 3) 공유 계정 키별 주석으로 사용자 구분 (개선책)
for u in ops; do h=$(getent passwd $u|cut -d: -f6); sudo ssh-keygen -lf "$h/.ssh/authorized_keys" 2>/dev/null; done

5. 정상 상태

ubuntu: LK shell=/sbin/nologin
ec2-user: LK shell=/sbin/nologin
== ops 출발지
(개인 계정 체제로 ops 없음)

기본 계정은 잠겨 있고(LK), 공유 계정 대신 개인 계정+sudo 체제인 상태가 정상입니다.

6. 이상 상태

admin: PS shell=/bin/bash
== ops 출발지
     40 192.168.56.5
     22 192.168.56.6
     18 192.168.56.7
  • 기본 admin 계정이 활성(비밀번호+셸) → brute-force 표적이자 공유 가능성
  • ops 계정이 3개 출발지에서 사용 → 여러 사람 공유 → 사고 시 행위자 특정 불가
  • 공유 계정에 brute-force 성공이 섞이면, 정상 공유 사용과 탈취를 구분하기 더 어려움

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

공유 계정의 추적 한계를 보여주는 예시입니다(가상의 예시 로그).

02:10:44 sshd: Accepted password for ops from 192.168.56.77
02:11:30 sudo: ops : USER=root ; COMMAND=/bin/bash
type=USER_LOGIN auid=ops ses=12 addr=192.168.56.77
→ auid=ops 까지만 추적 가능. "실제 사람"은 알 수 없음
   (개인 계정이었다면 auid=hong 으로 특정 가능)
구분개인 계정공유 계정
auid개인 식별공유명까지만
사고 대응해당 개인 조치전원 비밀번호 교체
책임 규명가능불가

공유 계정은 탈취돼도 "원래 여러 명이 쓰던 것"과 구분이 어려워, 027·028편의 이상 탐지도 정확도가 떨어집니다.

8. SOC 관제 포인트

  • 공유 계정·활성 기본 계정을 식별해 개인 계정+sudo로 전환하거나 잠급니다.
  • 불가피한 공유 계정은 최소한 키별 주석·점프호스트로 접속 전 개인을 식별합니다.
  • 기본 계정명은 열거·brute-force 표적이므로 잠금·이름 변경·감시를 적용합니다.

9. 탐지 규칙

<group name="local,syssec_b,authentication,">
  <rule id="101330" level="10">
    <if_sid>5715</if_sid>
    <list field="dstuser" lookup="match_key">etc/lists/default-accounts</list>
    <description>배포판 기본 계정(ubuntu/centos/admin 등) 로그인 성공</description>
  </rule>
</group>

default-accounts CDB 리스트에 기본 계정명을 넣어 로그인·시도를 탐지합니다. 공유 계정의 다출발지 사용은 028편(다출발지 로그인)과 겹치므로, 공유 계정은 그 룰의 예외가 아니라 별도 관리 대상으로 둡니다.

10. 대응 방법

  1. 초기 확인 — 공유 계정·활성 기본 계정과 각 계정의 사용 출발지·사용자 수를 확인합니다.
  2. 범위 확인 — 공유 계정의 로그인에 이상(비관리망·새벽)이 섞였는지, 기본 계정 공격 시도를 확인합니다.
  3. 증거 확보 — 공유 계정 사용 로그·키 목록, 기본 계정 상태를 보존합니다.
  4. 차단/조치 — 개인 계정 전환·공유 계정 잠금·기본 계정 비활성화를 진행합니다.
  5. 재발 방지 — 기본 계정 로그인 탐지와 공유 계정 전환 계획을 운영합니다.

11. 핵심 정리

구분핵심 내용
공유 계정여러 사람 공용 → 책임 추적성 상실
기본 계정ubuntu/centos/admin 등 → 공격 표적(071편)
해결개인 계정+sudo 전환, 공유 계정 잠금
불가피 시키별 주석·점프호스트로 개인 식별
면접 포인트"공유 계정은 auid로도 사람을 특정할 수 없다 — 추적성 상실"

12. 다음 편 예고

다음 편 087. 계정 · 인증 보안 — sudo 권한 상승 이상 징후 에서는 권한이 비정상적으로 오르는 sudo 권한 상승 이상 징후를 다룹니다.


이전 편: 085. 계정 · 인증 보안 — 서비스 계정 대화형 로그인 탐지
📚 시리즈 전체 보기: 시스템 보안 · 취약점

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

0개의 댓글