시스템 보안 · 취약점 › A. Linux 서버 보안 설정 · 8/50편 (전체 008/450)
학습 단계: 1단계 · 기본 개념
실습 표기: 이 글의 명령어·출력·로그는 로컬 VMware 테스트 VM(Rocky Linux 9 / Ubuntu 22.04) 기준의 「실습 예시」이며, IP·계정·호스트명은 가상의 값입니다.
선행 학습
1. 개념
root 접근 경로는 세 가지입니다. 각 경로마다 제한 방법과 남는 로그가 다르므로 경로별로 점검해야 합니다.
① 콘솔(tty) 직접 로그인 → login → "ROOT LOGIN ON tty1"
② SSH 직접 로그인 → sshd → "Accepted ... for root from IP"
③ 일반 계정 → su / sudo → su → "session opened for user root by admin1"
권장: ①은 비상용으로만, ②는 차단, ③은 관리자 그룹(wheel/sudo)만 허용③ 경로만 허용하면 "누가 root가 되었는지" 가 항상 개인 계정으로 남습니다. root 직접 로그인을 막는 가장 큰 이유가 이것입니다.
2. 왜 중요한가
- root로 직접 로그인하면 여러 관리자가 같은 계정을 쓰게 되어 행위자 식별(책임 추적성) 이 불가능해집니다.
- 인터넷에 노출된 SSH에 대한 무차별 대입은 대부분
root계정을 노립니다. - su를 누구나 쓸 수 있으면 root 비밀번호 하나만 유출돼도 모든 일반 계정이 root로 상승할 수 있습니다.
3. 핵심 명령어 / 설정
| 경로 | 설정 | 확인 |
|---|---|---|
| SSH | PermitRootLogin no (또는 prohibit-password) | sudo sshd -T | grep permitrootlogin |
| su | /etc/pam.d/su의 auth required pam_wheel.so use_uid | grep pam_wheel /etc/pam.d/su |
| 콘솔 | pam_securetty + /etc/securetty (Rocky 9은 기본 미사용) | grep securetty /etc/pam.d/login |
Rocky 9과 Ubuntu 22.04의 OpenSSH 기본값은 prohibit-password(키 인증만 허용)입니다. "키만 허용"도 root 직접 로그인이라는 점에 주의합니다.
4. 실습 (실습 예시)
# SSH root 로그인 차단 (drop-in 파일 사용)
echo 'PermitRootLogin no' | sudo tee /etc/ssh/sshd_config.d/01-root.conf
sudo sshd -t && sudo systemctl reload sshd # Ubuntu: systemctl reload ssh
sudo sshd -T | grep -i permitrootlogin
# su를 관리자 그룹으로 제한
sudo grep -n 'pam_wheel' /etc/pam.d/su
# auth required pam_wheel.so use_uid (Rocky: 주석 해제, wheel 그룹)
# auth required pam_wheel.so use_uid group=sudo (Ubuntu 예시)
# 테스트: wheel이 아닌 testuser로 su 시도 → 실패해야 정상drop-in 파일명을 01-로 시작하는 이유는 다음 편(009)에서 설명하는 "먼저 읽힌 값이 우선" 규칙 때문입니다.
5. 정상 상태
$ sudo sshd -T | grep -i permitrootlogin
permitrootlogin no
$ su - # testuser(비 wheel)로 실행
Password:
su: Permission deniedroot 사용 기록이 모두 by admin1(uid=1001) 같은 개인 계정 경유로 남는 상태가 정상입니다.
6. 이상 상태
$ sudo sshd -T | grep -i permitrootlogin
permitrootlogin yes
$ sudo grep -rn PermitRootLogin /etc/ssh/sshd_config.d/
/etc/ssh/sshd_config.d/00-tmp.conf:1:PermitRootLogin yes- 본 설정 파일은
no인데 실효값은yes→ 앞 순서의 drop-in 파일이 덮어씀 00-tmp.conf처럼 임시 파일처럼 보이는 이름은 은폐 목적일 수 있습니다.
7. 로그 분석 (분석 방법)
세 경로의 대표 로그입니다(가상의 예시 로그).
[SSH 직접] Oct 1 03:41:22 rocky9-web01 sshd[5120]: Accepted password for root from 192.168.56.50 port 50122 ssh2
[su 경유] Oct 1 10:31:02 rocky9-web01 su[4410]: pam_unix(su-l:session): session opened for user root(uid=0) by admin1(uid=1001)
[su 거부] Oct 1 10:33:40 rocky9-web01 su[4431]: FAILED SU (to root) testuser on pts/2
[콘솔] Oct 1 11:00:05 rocky9-web01 login[901]: ROOT LOGIN ON tty1| 로그 | 판단 |
|---|---|
SSH Accepted ... for root | 차단 정책 위반 → 즉시 확인 |
by admin1 | 행위자 식별 가능, 관리자 그룹 여부 확인 |
FAILED SU | 비인가 계정의 상승 시도 → 반복 여부 확인 |
ROOT LOGIN ON tty1 | 콘솔 접근 → 하이퍼바이저(VMware) 콘솔 접근 기록과 대조 |
8. SOC 관제 포인트
PermitRootLogin no환경에서 root SSH 성공 로그가 한 건이라도 있으면 설정 우회 또는 변경을 의미합니다.FAILED SU가 같은 계정에서 반복되면 비밀번호 추측 시도로 판단합니다.- 콘솔 root 로그인은 가상화 계층의 콘솔 접근 기록과 교차 확인합니다.
9. 탐지 규칙
<group name="local,root,">
<rule id="100150" level="12">
<if_sid>5715</if_sid>
<user>^root$</user>
<description>SSH root 직접 로그인 성공 (정책 위반)</description>
</rule>
</group>5715는 Wazuh의 "sshd: authentication success" 기본 룰입니다. Kibana에서는 rule.id : 5715 and data.dstuser : "root"로 과거 이력을 검색할 수 있습니다.
10. 대응 방법
- 초기 확인 — root 직접 로그인 성공 시각·출발지 IP·인증 방식(password/publickey)을 확인합니다.
- 범위 확인 — 해당 IP의 다른 서버 접속과 같은 시간대 설정 변경(
sshd_config.d)을 확인합니다. - 증거 확보 — sshd 설정 파일 사본,
secure/auth.log, 세션 이후 명령 기록을 보존합니다. - 차단/조치 — root 세션을 종료하고
PermitRootLogin no를 재적용, root 비밀번호·키를 교체합니다. - 재발 방지 — drop-in 디렉터리를 FIM에 포함하고 root SSH 성공 룰을 상시 운영합니다.
11. 핵심 정리
| 경로 | 제한 방법 / 핵심 로그 |
|---|---|
| SSH | PermitRootLogin no / Accepted ... for root |
| su | pam_wheel.so use_uid / FAILED SU |
| 콘솔 | 비상용 한정 / ROOT LOGIN ON tty |
| 원칙 | 개인 계정 → sudo/su 경유로 책임 추적성 확보 |
| 면접 포인트 | "prohibit-password도 root 직접 로그인이다" |
12. 다음 편 예고
다음 편 009. Linux 서버 보안 — sshd -T로 SSH 실효 설정 점검하기 에서는 설정 파일이 여러 개일 때 실제로 적용되는 SSH 설정을 sshd -T로 확인하는 방법을 다룹니다.
이전 편: 007. Linux 서버 보안 — sudo 로깅 강화 — logfile과 I/O 기록
📚 시리즈 전체 보기: 시스템 보안 · 취약점
