013. Linux 서버 보안 — 불필요한 서비스 식별과 비활성화

changseop lee·5일 전

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

선행 학습

1. 개념

불필요한 서비스 정리는 공격 표면(attack surface) 을 줄이는 가장 효과적인 하드닝입니다. 실행되지 않는 서비스는 취약점이 있어도 악용될 수 없기 때문입니다.

판단 기준은 "설치되어 있는가"가 아니라 "이 서버의 역할에 필요한가" 입니다.

서비스 목록 수집
   ↓
역할 매핑 (웹 서버라면 httpd, sshd, chronyd, rsyslog, auditd ...)
   ↓
역할에 없는 서비스 → 담당자 확인 → disable → 필요 시 mask
   ↓
결과를 기준선(units.txt)에 반영

2. 왜 중요한가

  • 기본 설치에 포함된 cups(프린터), avahi-daemon(mDNS) 같은 서비스는 서버에서 거의 쓰이지 않지만 네트워크 포트를 열 수 있습니다.
  • 공격자는 지속성을 위해 새 서비스를 등록하거나, 꺼져 있던 서비스를 다시 켜기도 합니다. 정리된 목록이 있어야 이런 변화가 보입니다.
  • disable은 부팅 시 자동 시작만 막습니다. 다른 유닛의 의존성으로 다시 시작될 수 있으므로 확실히 막으려면 mask를 씁니다.

3. 핵심 명령어 / 설정

명령용도
systemctl list-unit-files --type=service --state=enabled부팅 시 자동 시작 서비스
systemctl list-units --type=service --state=running현재 실행 중
systemctl list-units --type=socket소켓 활성화 유닛(요청 시 시작)
systemctl disable --now 서비스중지 + 자동 시작 해제
systemctl mask 서비스/dev/null 링크로 시작 자체 차단
systemctl cat 서비스유닛 파일 위치와 내용 확인

4. 실습 (실습 예시)

# 1) 활성 서비스와 소켓 목록
systemctl list-unit-files --type=service --state=enabled --no-legend | awk '{print $1}'
systemctl list-units --type=socket --no-legend

# 2) 예: 서버에 불필요한 서비스 정리
for s in cups avahi-daemon rpcbind; do
  systemctl is-enabled $s 2>/dev/null && sudo systemctl disable --now $s
done
sudo systemctl mask avahi-daemon.socket 2>/dev/null

# 3) 결과 확인
systemctl is-enabled cups avahi-daemon rpcbind 2>&1

서비스 이름은 배포판·설치 옵션에 따라 다르므로, 정리 전 반드시 담당자와 역할을 확인합니다.

5. 정상 상태

$ systemctl list-unit-files --type=service --state=enabled --no-legend | awk '{print $1}'
auditd.service
chronyd.service
crond.service
firewalld.service
httpd.service
rsyslog.service
sshd.service

역할(웹 서버)과 관리 필수 서비스만 남아 있는 상태입니다.

6. 이상 상태

$ systemctl list-unit-files --type=service --state=enabled --no-legend | awk '{print $1}'
...
dbus-update.service
telnet.socket
$ systemctl cat dbus-update.service | grep ExecStart
ExecStart=/usr/local/bin/.dbus-update
  • 시스템 서비스처럼 보이는 이름(dbus-update)이지만 실행 파일이 /usr/local/bin의 숨김 파일 → 지속성 백도어 의심 (F영역에서 상세 분석)
  • telnet.socket 활성화 → 평문 원격 접속 경로가 열림

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

서비스 활성화는 systemd와 auditd에 흔적을 남깁니다(가상의 예시 로그).

type=PATH msg=audit(1759716000.120:1301): item=1 name="/etc/systemd/system/multi-user.target.wants/dbus-update.service" nametype=CREATE key="systemd_units"
Oct  1 08:00:01 rocky9-web01 systemd[1]: Reloading.
type=SERVICE_START msg=audit(1759716002.004:1305): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=dbus-update comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
흔적의미
multi-user.target.wants/ 링크 생성systemctl enable 실행 = 부팅 시 자동 시작 등록
systemd[1]: Reloading.daemon-reload (유닛 파일 추가·변경 후 필요)
SERVICE_START unit=...실제 서비스 시작

auid=4294967295는 "로그인 사용자 없음(unset)"으로 systemd가 시작했음을 뜻합니다. 누가 enable 했는지는 링크 생성 이벤트의 auid로 확인합니다.

8. SOC 관제 포인트

  • /etc/systemd/system/ 아래 유닛 파일 생성과 *.wants/ 링크 생성은 지속성 탐지의 핵심 지점입니다.
  • 서비스 이름보다 ExecStart 경로(/tmp, /dev/shm, 숨김 파일, /usr/local/bin)를 봅니다.
  • 활성 서비스 목록을 기준선과 매일 비교합니다.

9. 탐지 규칙

# auditd: 유닛 파일 경로 감시
-w /etc/systemd/system/ -p wa -k systemd_units
-w /usr/lib/systemd/system/ -p wa -k systemd_units
<rule id="100200" level="9">
  <if_sid>554</if_sid>
  <field name="file">^/etc/systemd/system/</field>
  <description>신규 systemd 유닛/링크 생성: $(file)</description>
</rule>

패키지 설치 시에도 유닛이 생성되므로, 같은 시각 dnf/apt 로그가 있으면 정상 가능성을 먼저 검토합니다.

10. 대응 방법

  1. 초기 확인 — 신규·재활성 서비스의 유닛 파일 내용과 ExecStart 경로를 확인합니다.
  2. 범위 확인 — 같은 실행 파일·유닛 이름이 다른 서버에도 있는지 검색합니다.
  3. 증거 확보 — 유닛 파일과 실행 파일 사본(해시 포함), audit 로그를 보존합니다.
  4. 차단/조치 — 서비스를 중지·mask 하고 실행 파일을 격리합니다.
  5. 재발 방지 — 역할별 허용 서비스 목록을 기준선으로 관리하고 유닛 경로를 감시합니다.

11. 핵심 정리

구분핵심 내용
판단 기준설치 여부가 아니라 서버 역할에 필요한가
disable vs mask자동 시작 해제 vs 시작 자체 차단
지속성 흔적/etc/systemd/system/*.wants/ 링크 생성
확인 포인트서비스 이름보다 ExecStart 경로
면접 포인트"SERVICE_START의 auid는 unset → enable한 사람은 링크 생성 이벤트로"

12. 다음 편 예고

다음 편 014. Linux 서버 보안 — 열린 포트 기준선 비교 점검 에서는 서비스가 연 리스닝 포트를 기준선과 비교해 변화를 찾는 방법을 다룹니다.


이전 편: 012. Linux 서버 보안 — SSH 세션·인증 시도 제한 설정
📚 시리즈 전체 보기: 시스템 보안 · 취약점

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

0개의 댓글