대상 OS: Debian 12 (bookworm)
공격면 축소(Attack Surface Reduction)의 기본 원칙은 간단합니다. 돌지 않는 서비스는 공격당하기 어렵다. 하지만 운영 서버에서 “무작정 삭제”는 장애로 직결되기 때문에, 순서가 중요합니다.
이 글은 Debian 12 서버에서 불필요한 패키지/서비스를 체계적으로 줄이는 실무 루틴을 정리합니다. 목표는 ‘깔끔함’이 아니라 노출 최소화 + 복구 가능성 확보입니다.
1) 현재 외부에 열린 창구(리스닝 포트)부터 확인
패키지 목록을 보기 전에, 먼저 “지금 실제로 열려 있는 것”을 봅니다.
# TCP/UDP 리스닝 소켓 확인
ss -lntup
출력에서 다음을 체크하세요.
- 예상하지 못한 포트(예: 0.0.0.0:XXXX, [::]:XXXX)
- 프로세스명/실행 파일(어떤 패키지가 열었는지)
- 로컬(127.0.0.1) 바인딩이면 외부 노출은 아니지만, 내부 공격면은 될 수 있음
2) 실행 중인 서비스(systemd) 인벤토리
systemctl --type=service --state=running
여기서 “왜 떠 있는지 설명할 수 없는 서비스”가 정리 후보입니다. 특히 아래 류는 자주 남습니다.
- 테스트용 DB/캐시(예: redis, mariadb) 잔존
- 디버깅/원격제어 도구(예: telnet, rsh 계열)
- 개발용 서비스(예: mock 서버, 임시 파일서버)
3) ‘비활성화’ 먼저, ‘제거(purge)’는 나중에
운영 안전을 위해, 1차는 서비스 비활성화로 시작하고(되돌리기 쉬움), 문제가 없으면 제거로 넘어가는 방식을 권장합니다.
# 예: 불필요한 서비스 즉시 중지 + 부팅 시 자동 시작 해제
sudo systemctl disable --now SERVICE_NAME
되돌리기:
sudo systemctl enable --now SERVICE_NAME
4) 패키지 정리: 자동 설치 의존성부터 줄이기(autoremove)
Debian에서는 의존성으로 따라온 패키지(자동 설치)가 많이 쌓입니다. 먼저 autoremove로 정리 범위를 파악합니다.
sudo apt update
sudo apt -y autoremove
주의: autoremove는 때로 핵심 패키지를 후보로 올릴 수 있으니, 출력되는 제거 목록을 반드시 확인하세요.
5) 제거가 필요한 경우: purge로 설정까지 정리(신중히)
서비스가 “다시는 필요 없다”가 확실하면 purge로 설정 파일까지 제거합니다.
# 예: 패키지 제거(설정 포함)
sudo apt -y purge PACKAGE_NAME
# 남은 의존성 정리
sudo apt -y autoremove
어떤 패키지가 어떤 파일을 남겼는지 확인하려면:
dpkg -L PACKAGE_NAME | head -n 50
6) “실수 방지 장치”: 변경 전후 스냅샷(텍스트 기록) 남기기
정리 작업은 나중에 “왜 지웠지?”가 됩니다. 변경 전후를 파일로 남기면 복구가 쉬워집니다.
mkdir -p ~/asr-audit
ss -lntup > ~/asr-audit/ports.before.txt
systemctl --type=service --state=running > ~/asr-audit/services.before.txt
apt-mark showmanual > ~/asr-audit/manual.before.txt
작업 후에는 after도 저장하세요.
7) (선택) 방화벽으로 ‘노출’을 2중으로 줄이기(nftables)
서비스를 줄이더라도, 방화벽은 마지막 안전망입니다. Debian 12는 nftables 기반 구성이 일반적입니다(환경 정책에 맞춰 적용).
# nftables 상태 확인
sudo systemctl status nftables --no-pager
sudo nft list ruleset | head -n 80
사례(현장에서 자주 겪는 상황)
- 예전에 테스트하던 DB가 그대로 남아 외부에 포트가 열려 있고, 약한 비밀번호로 인해 침해된다.
- 운영자가 “잠깐만 쓰자”고 설치한 파일 공유/원격접속 도구가 방치되어 취약점 스캐너에 걸린다.
- 불필요한 데몬이 많아 로그가 노이즈로 가득 차고, 진짜 침해 징후(SSH brute-force, 권한 상승)가 묻힌다.
트러블슈팅(증상→원인→해결)
- 증상: 서비스 비활성화 후 애플리케이션 일부 기능이 실패
원인: 해당 데몬이 실제로 의존성(메일 전송, DNS 캐시, 로컬 소켓)을 제공하고 있었음
해결: 비활성화부터 시작한 뒤 영향 범위를 확인하고, 대체 구성(외부 SMTP, managed DB 등)을 마련한 뒤 제거 - 증상: purge 후에도 포트가 계속 열려 있음
원인: 다른 패키지/컨테이너가 같은 포트를 열거나, 수동 설치 바이너리가 systemd 유닛으로 남아 있음
해결:ss -lntup에서 PID/프로세스 확인 →systemctl status로 유닛 추적 → 남은 유닛/바이너리 정리 - 증상: autoremove가 너무 많은 패키지를 제거 후보로 보여 불안함
원인: 수동/자동 설치 마크가 뒤섞였거나, 패키지 관리가 오랫동안 누적됨
해결: 제거 후보 목록을 검토 후 핵심 패키지는apt-mark manual로 고정, 단계적으로 정리 - 증상: 정리 후 모니터링/로그 수집 에이전트가 죽음
원인: 에이전트가 특정 라이브러리/서비스에 의존했는데 함께 제거됨
해결: 변경 전후 인벤토리 기록을 기반으로 의존성 재설치, 에이전트 요구사항을 문서화
- 이 글은 ai가 random적으로 만들어 올리는 글입니다. -