001. Linux 서버 보안 — 기본 보안 점검 항목과 하드닝 로드맵

Linux 서버 보안 Soc 리눅스 보안관제 보안점검 시스템 보안 · 취약점 시스템보안 하드닝

시스템 보안 · 취약점

목록 보기

1/150

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

선행 학습

1. 개념

서버 보안 설정(하드닝, Hardening) 은 서버가 해야 할 일만 하도록 기능·권한·노출면을 줄이는 작업입니다. 기존 「Linux 시스템 보안 기초」에서 개별 개념(계정, 권한, SSH, 감사)을 배웠다면, 이번 영역은 그 개념을 점검 항목 → 기대값 → 이상 징후 → 탐지 규칙 → 대응 으로 묶어 운영 관점에서 다룹니다.

하드닝 점검 항목은 크게 5개 축으로 나눌 수 있습니다.

            [ Linux 서버 하드닝 5축 ]
 ┌──────────┬──────────┬──────────┬──────────┬──────────┐
 │ ① 계정    │ ② 서비스  │ ③ 네트워크 │ ④ 로그    │ ⑤ 무결성  │
 │ 인증·권한 │ 프로세스  │ 포트·방화벽│ 감사·전송 │ 패키지·설정│
 └────┬─────┴────┬─────┴────┬─────┴────┬─────┴────┬─────┘
      └──────────┴────── 점검 결과 ──────┴──────────┘
                           ↓
                 기준선(Baseline) 저장
                           ↓
            변경 발생 → 로그 → SIEM → Alert → SOC

2. 왜 중요한가

침해사고의 상당수는 취약한 설정(기본 계정, 열린 관리 포트, 꺼진 감사 로그)에서 시작합니다. 공격 기법이 정교하지 않아도 설정이 약하면 침투가 쉬워집니다.
SOC 관점에서 하드닝은 탐지의 전제 조건입니다. auditd가 꺼져 있거나 로그가 원격으로 전송되지 않으면, 아무리 좋은 SIEM 룰도 볼 데이터가 없습니다.
하드닝 상태는 시간이 지나면서 무너집니다(설정 드리프트). 그래서 "한 번 설정"이 아니라 기준선 + 지속 점검 + 변경 탐지 구조가 필요합니다.

3. 핵심 명령어 / 설정

축	대표 점검 명령어	점검 대상
계정	`awk -F: '$3==0' /etc/passwd`, `sudo -l -U 사용자`	UID 0 중복, sudo 권한
서비스	`systemctl list-unit-files --state=enabled`	불필요 서비스
네트워크	`ss -tulpn`, `firewall-cmd --list-all`	리스닝 포트, 방화벽
로그	`systemctl is-active auditd rsyslog`, `auditctl -s`	감사·로그 수집 상태
무결성	`rpm -Va` / `debsums -s`	패키지 파일 변조

4. 실습 (실습 예시)

5축을 한 번에 훑는 1차 점검(triage) 예시입니다. 결과를 파일로 남겨 이후 편에서 기준선으로 사용합니다.

# 점검 결과 저장 디렉터리 (root 전용)
sudo install -d -m 700 /root/baseline
cd /root/baseline

# ① 계정
awk -F: '$3==0{print $1}' /etc/passwd            > 01_uid0.txt
# ② 서비스
systemctl list-unit-files --state=enabled --no-pager > 02_enabled_units.txt
# ③ 네트워크
ss -tulpnH                                         > 03_listen.txt
# ④ 로그
systemctl is-active auditd rsyslog systemd-journald > 04_log_services.txt
# ⑤ 무결성 (Rocky) / Ubuntu는 debsums -s
rpm -Va 2>/dev/null                                > 05_rpm_verify.txt
ls -l /root/baseline

5. 정상 상태

$ cat 01_uid0.txt
root
$ cat 04_log_services.txt
active
active
active

UID 0 계정은 root 하나뿐입니다.
감사·로그 서비스 3종이 모두 active 입니다.
rpm -Va 결과는 설정 파일(c 표시) 위주의 소수 변경만 존재합니다.

6. 이상 상태

점검 결과	왜 의심하는가
`01_uid0.txt`에 `root` 외 계정(예: `sysbak`)	UID 0 백도어 계정 가능성
`auditd`가 `inactive`	감사 로그 공백 → 공격 흔적 은폐 가능
`03_listen.txt`에 `0.0.0.0:4444` 같은 미식별 포트	비인가 서비스·백도어 리스너
`rpm -Va`에서 `/usr/bin/ps`가 `S.5....T.`	시스템 바이너리 변조(크기·해시·시간 변경)

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

하드닝 점검 자체도 로그를 남깁니다. 아래는 점검 중 root 권한 명령이 실행된 흔적입니다(가상의 예시 로그).

Oct  1 09:02:11 rocky9-web01 sudo[2311]:  admin1 : TTY=pts/0 ; PWD=/home/admin1 ; USER=root ; COMMAND=/usr/bin/install -d -m 700 /root/baseline
Oct  1 09:02:30 rocky9-web01 sudo[2340]:  admin1 : TTY=pts/0 ; PWD=/root/baseline ; USER=root ; COMMAND=/usr/bin/rpm -Va

필드	의미	분석 포인트
`admin1`	sudo 실행 사용자	점검 담당자 계정인지
`TTY=pts/0`	원격 터미널(SSH)	접속 출발지와 연결해 확인
`COMMAND`	실제 실행 명령	점검 계획과 일치하는지

점검 행위와 공격자의 정찰 행위는 명령어가 비슷합니다. 누가, 언제, 승인된 작업인지로 구분합니다(자세한 정찰 흔적 분석은 C영역 「Linux 정보 노출 및 수집」에서 다룹니다).

8. SOC 관제 포인트

5축 각각에 대해 "꺼지면 안 되는 것" 목록을 정의합니다: auditd, rsyslog, firewalld, SELinux(Enforcing).
점검 명령 실행 로그를 보고 점검 일정·담당자와 일치하는지 확인합니다.
하드닝 결과는 Alert가 아니라 자산 상태 정보로 SIEM에 적재해 두면, 사고 분석 시 "당시 서버 상태"를 증거로 쓸 수 있습니다.

9. 탐지 규칙

Wazuh는 감사 서비스 중지, UID 0 계정 추가 같은 하드닝 붕괴 이벤트를 룰로 탐지할 수 있습니다. 이 영역에서 단계적으로 만들 커스텀 룰의 예고편입니다.

<!-- /var/ossec/etc/rules/local_rules.xml (예시) -->
<group name="local,hardening,">
  <rule id="100100" level="10">
    <if_sid>550</if_sid>
    <field name="file">/etc/passwd</field>
    <description>계정 파일(/etc/passwd) 변경 탐지 - UID 0 추가 여부 확인 필요</description>
  </rule>
</group>

550은 Wazuh FIM의 "Integrity checksum changed" 기본 룰입니다. 이를 부모로 삼아 중요 파일만 높은 레벨로 올리는 방식이 이 영역의 기본 패턴입니다.

10. 대응 방법

초기 확인 — 5축 1차 점검 결과에서 기대값과 다른 항목을 표시합니다.
범위 확인 — 같은 이미지·템플릿으로 만든 다른 서버도 동일한 차이가 있는지 확인합니다.
증거 확보 — 점검 결과 파일과 관련 로그(/var/log/secure, audit.log)를 해시와 함께 보존합니다.
차단/조치 — 비인가 계정 잠금, 미식별 서비스 중지 등 영향도를 고려해 조치합니다.
재발 방지 — 점검 결과를 기준선으로 저장하고, 변경을 SIEM에서 탐지하도록 등록합니다.

11. 핵심 정리

구분	핵심 내용
하드닝 정의	필요한 기능만 남기고 노출면·권한을 최소화
5축	계정 · 서비스 · 네트워크 · 로그 · 무결성
SOC 연결	하드닝은 탐지의 전제 조건 (로그가 없으면 탐지 불가)
핵심 원칙	기준선 → 지속 점검 → 변경 탐지
면접 포인트	"하드닝 붕괴(auditd 중지 등) 자체가 침해 징후"

12. 다음 편 예고

다음 편 002. Linux 서버 보안 — 보안 설정 기준선(Baseline) 만들기 에서는 오늘 저장한 점검 결과를 비교 가능한 기준선(Baseline) 으로 만드는 방법을 다룹니다.

📚 시리즈 전체 보기: 시스템 보안 · 취약점

changseop lee

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

다음 포스트