대상 OS: Debian 12 (bookworm)

침해사고는 항상 눈에 띄는 알람으로 시작하지 않습니다.
어느 날부터 서버가 ‘조금’ 이상해졌는데, 원인을 못 찾는 경우가 더 흔하죠.
이럴 때 도움이 되는 접근 중 하나가 “정기적으로, 같은 기준으로, 루트킷/이상 징후를 훑어보는 것”입니다.
RKHunter(rkhunter)는 오래된 도구지만, 베이스라인과 예외(오탐)를 잘 관리하면 지금도 ‘기본 위생 점검’으로 꽤 쓸만합니다.

이 글은 Debian 12에서 rkhunter를 설치하고, 초기 베이스라인을 만든 뒤, 오탐을 줄이고, cron으로 정기 점검을 자동화하며, 결과를 어떻게 해석하고 후속 조치를 밟을지까지 운영 관점으로 정리합니다.

---

1) RKHunter를 어디에 쓰면 좋은가(현실적인 기대치)

1) 침해 여부를 100% 판정하는 ‘결정타’가 아니라, 이상 징후를 빠르게 찾는 ‘체크리스트’로 쓴다

2) 정기 점검 결과가 누적되면, 평소와 다른 변화(새 바이너리, 권한 변화, 의심 설정)가 더 잘 보인다

3) 다른 계층(로그/EDR/무결성/AIDE/패치)과 함께 쓸 때 가치가 올라간다

주의
- 공격자가 커널/유저랜드를 깊게 장악했다면, rkhunter 자체가 속을 수 있습니다.
- 따라서 rkhunter는 “사후 포렌식/대응의 보조 도구”이며, 단독 방어 수단이 아닙니다.

---

2) 설치 및 기본 파일 구조 확인

1) 설치

sudo apt update
sudo apt -y install rkhunter

2) 버전/설정 파일 확인

rkhunter --versioncheck || true
sudo ls -la /etc/rkhunter.conf /etc/rkhunter.conf.d 2>/dev/null || true
sudo ls -la /var/lib/rkhunter 2>/dev/null || true

3) 로그 위치 확인

sudo ls -la /var/log/rkhunter.log 2>/dev/null || true
sudo tail -n 60 /var/log/rkhunter.log 2>/dev/null || true

---

3) 첫 실행 전에 해야 하는 것: 업데이트 + 베이스라인

RKHunter는 “지금 서버가 정상”이라는 전제가 있어야 베이스라인이 의미가 있습니다.
따라서 초기 세팅은 ‘클린한 시점’(신규 구축 직후, 또는 충분히 검증된 상태)에 하는 것이 좋습니다.

1) 데이터베이스/시그니처 업데이트

sudo rkhunter --update

2) 초기 설정 파일 업데이트(배포판 패키지와 정합)

sudo rkhunter --propupd

`--propupd`는 파일 속성(permissions/sha 등) 기준선을 갱신하는 동작을 포함할 수 있으므로, 무조건 자주 돌리면 “침해로 바뀐 것도 정상으로 학습”할 수 있습니다.
초기/승인된 변경 시점에만 실행하는 것을 권장합니다.

---

4) 1회 수동 점검(기본 동작 확인)

1) 대화형 경고를 피하고, 결과를 로그로 남기기

sudo rkhunter --check --sk

2) 요약 확인(경고/의심 수)

sudo grep -E "Warning:|Found|Summary" /var/log/rkhunter.log | tail -n 80

3) 점검이 오래 걸리거나 멈추는 느낌이면

sudo tail -n 200 /var/log/rkhunter.log

---

5) 오탐 줄이기(운영에서 제일 중요한 파트)

rkhunter를 “한 번 돌려보고 경고가 많아서 버리는” 경우가 많습니다.
하지만 오탐을 잘 정리하면, 이후에는 ‘진짜 이상’만 남게 됩니다.

1) 경고가 나온 항목을 먼저 분류

- 정상 변경(패키지 업데이트, 설정 변경)
- 환경 특성(컨테이너/커스텀 커널/특수 파일시스템)
- 정말 의심(정체불명 바이너리, 권한 이상, 숨김 파일)

2) 승인된 정상 변경이라면 예외 규칙으로 관리

rkhunter는 /etc/rkhunter.conf 또는 conf.d에 예외를 둘 수 있습니다.
환경마다 필요한 예외가 달라 “무작정 예외를 늘리기”는 위험합니다.

운영 팁
- 예외를 추가하기 전에 반드시 ‘왜 경고가 났는지’ 근거를 확보하세요.
- 예외 목록은 티켓/커밋으로 남겨 변경 이력을 관리하세요.

---

6) cron 자동화: 정기 점검을 습관이 아니라 시스템으로

Debian 패키지는 기본적으로 cron 실행이 포함되는 경우가 있습니다.
먼저 현재 스케줄을 확인하세요.

1) cron 설정 확인

sudo ls -la /etc/cron.daily | grep -i rkhunter || true
sudo ls -la /etc/cron.* | sed -n '1,120p'

2) 직접 주기/옵션을 통제하고 싶다면(예: 주 1회, 새벽)

간단히 cron.weekly에 래퍼 스크립트를 둘 수 있습니다.

sudo tee /etc/cron.weekly/rkhunter-check >/dev/null /dev/null || true

3) 최근 변경 흔적(시간) 확인

sudo find /path/to -maxdepth 2 -type f -printf '%TY-%Tm-%Td %TH:%TM %u %g %p\n' 2>/dev/null | tail -n 50

4) 네트워크/프로세스/로그와 교차 확인

sudo ss -tnp | head -n 80
ps aux --sort=-%cpu | head -n 30
sudo journalctl -u ssh -n 200 --no-pager

RKHunter는 “이상 후보”를 준 것이고, 판정은 다른 근거와 함께 해야 합니다.

---

8) 베이스라인 갱신(--propupd)은 언제 해야 하나

이 기능은 매우 유용하지만, 잘못 쓰면 위험합니다.

1) 해야 하는 시점

- OS 패키지 업데이트/커널 업데이트 등 ‘승인된 변경’ 직후
- 서버가 정상임이 확실하고, 변경 내역이 문서화된 상태

2) 하면 안 되는 시점

- 침해가 의심되는 순간
- 원인이 불명확한 이상 징후가 있는 상태

3) 운영 표준

- propupd는 정기 자동화하지 말고, “변경관리” 이벤트로만 수행

---

9) 추천 조합(같이 하면 효과가 커지는 것)

1) AIDE(파일 무결성)

2) journald sealing/중앙 로그 수집

3) SSH 하드닝/관리망(VPN)

4) 패치 자동화(보안 업데이트)

rkhunter는 이 조합 속에서 “가벼운 정기 점검” 역할로 두는 것이 가장 효율적입니다.

---

마무리

Debian 12에서 rkhunter를 잘 쓰는 핵심은 간단합니다.
- 클린한 시점에 베이스라인을 만들고
- 오탐을 최소한으로 정리해 ‘의미 있는 경고’만 남기고
- cron으로 정기 점검을 자동화하며
- 결과를 다른 로그/증거와 교차해 해석하는 것

이렇게 운영하면 rkhunter는 “한 번 돌려보고 버리는 도구”가 아니라, 작은 비용으로 침해 징후를 더 빨리 잡는 루틴이 됩니다.