- systemd는 강력한 서비스 관리 기능을 제공하지만 기본 설정은 보안보다는 사용성에 최적화되어 있어 별도의 하드닝 옵션 적용이 필요함
-
systemd-analyze security 명령어를 통해 전체 서비스 또는 특정 서비스의 보안 노출 지표를 분석하고 우선순위를 정할 수 있음
- 서비스 단위에서 적용할 수 있는 다양한 보안 옵션이 존재하며, 이는 /etc/systemd/system/ServiceName.service.d/override.conf 등을 통해 개별적으로 수정 가능함
- 주요 옵션에는 ProtectSystem, PrivateTmp, NoNewPrivileges, SystemCallFilter, MemoryDenyWriteExecute 등 프로세스 권한과 자원 접근을 제한하는 항목이 포함됨
- 완벽한 보안을 목표로 하기보다는 외부 노출 서비스를 우선적으로 하드닝하여 위험을 줄이고, self-hosting 환경에서도 큰 효과를 볼 수 있음
systemd 개요
- systemd는서비스 관리에서 매우 완성도 높고 견고한 방식을 제공함
- 하지만 보안보다는 즉시 사용성을 우선시해 기본 설정이 느슨하게 되어 있음
- 본 문서는 systemd 서비스 유닛과 podman quadlet에 적용할 수 있는 여러 보안 강화 옵션을 소개하여 침해 가능성을 줄이고, 침해 발생 시 피해 범위를 최소화하고자 함
- 모든 서비스에 일괄 적용하는 가이드가 아니며, 각각의 서비스 특성과 요구 기능에 맞는 개별 실험과 로그 확인, 조정이 필요함
- 인프라 보안 책임은 전적으로 운영자에게 있으며, 본 문서는 참고 도구임
systemd 보안 분석
-
systemd-analyze security 명령어로 전체 서비스 보안 상태를 확인하거나 특정 서비스(예: sshd.service)의 세부 설정을 분석할 수 있음
- 출력에는 체크 여부, 기능 이름, 설명, Exposure 점수가 포함되어 있으며 Exposure가 높을수록 위험도가 큼
- 보안 옵션은 [Service] 섹션(systemd) 또는 [Container] 섹션(podman quadlet)에 추가 설정 가능함
-
systemctl edit ServiceName.service를 통해 override 파일을 만드는 방식이 권장되며, 실패 시 필요한 권한을 확인 후 조정해야 함
서비스 보안 옵션
- systemd는 다양한 보안 옵션 키워드를 제공하며 man systemd.exec 5, man capabilities 7 등을 통해 확인 가능함
- 대표적인 보안 관련 옵션
-
ProtectSystem → 파일시스템을 읽기 전용으로 제한하는 옵션임
-
ProtectHome → /home, /root, /run/user 접근 차단 옵션임
-
PrivateDevices → 물리 장치 접근 차단, /dev/null 등 가상 장치만 허용하는 옵션임
-
ProtectKernelTunables, ProtectKernelModules, ProtectKernelLogs → 커널 자원 접근 차단 옵션임
-
NoNewPrivileges → setuid/setgid 등을 통한 신규 권한 획득 방지 옵션임
-
MemoryDenyWriteExecute → 쓰기 및 실행 가능한 메모리 동시 사용 차단, 일부 JIT 언어에는 문제 발생 가능성 있음
-
SystemCallFilter → 허용할 시스템 콜을 제한하는 옵션임, 위반 시 프로세스 종료 또는 EPERM 반환 가능함
각 옵션 설명
-
ProtectSystem: strict 설정 시 전체 파일시스템을 읽기 전용 마운트, /dev, /proc, /sys는 별도 보호 옵션 필요
-
ReadWritePaths: 일부 경로만 다시 쓰기 가능하게 설정
-
ProtectHome: /home, /root, /run/user 접근 차단
-
PrivateDevices: 물리 장치 접근 비활성화, /dev/null 등 Pseudo 장치만 허용
-
ProtectKernelTunables: /proc, /sys를 읽기 전용 처리
-
ProtectControlGroups: cgroup 읽기 전용 접근만 허용
-
ProtectKernelModules: 커널 모듈 명시적 로딩 금지
-
ProtectKernelLogs: 커널 로그 버퍼 접근 제한
-
ProtectProc: invisible 설정 시 타 사용자 소유 프로세스를 /proc/에서 숨김
-
ProcSubset: 특정 PID관련 항목 외 내용 /proc에서 차단
-
NoNewPrivileges: setuid, setgid, 파일 시스템 capability를 통한 새로운 권한 상승 차단
-
ProtectClock: 시스템/하드웨어 클럭 쓰기 차단
-
SystemCallArchitectures: native 설정 시 x86-64 등 네이티브 syscall만 허용
-
RestrictNamespaces: 컨테이너 특화 네임스페이스 제한
-
RestrictSUIDSGID: 파일 setuid, setgid 비트 설정 차단
-
LockPersonality: 실행 도메인 변경 방지 (구형 어플리케이션 등에만 필요)
-
RestrictRealtime: 실시간 스케줄링 제한 (일부 특수 목적 서비스만 필요)
-
RestrictAddressFamilies: 허용하는 소켓 주소 패밀리 제한 (예: AF_INET, AF_INET6, AF_UNIX 등 지정)
-
MemoryDenyWriteExecute: 쓰기+실행 가능한 메모리영역 추가 생성 차단 (JIT 사용 서비스는 주의)
-
ProtectHostname: sethostname, setdomainname syscall 사용 금지
-
SystemCallFilter: 서비스별 syscall 허용/차단 설정, 세밀하게 필터링 가능
- 그룹, 개별 syscall, 허용/차단 방식 등 조정 가능
- 위반 시 종료 대신 EPERM 등 오류코드 반환 설정도 지원
- 전체 목록은 systemd-analyze syscall-filter 또는 man systemd.exec(5) 통해 확인 가능
-
~ 접두사로 리스트 전체 음수화 가능 (예: CapabilityBoundingSet=~CAP_SETUID 등)
SystemCallFilter 제한 조정 과정
-
auditd를 이용해 서비스 실패 시 어떤 syscall이 차단됐는지 로그 확인 가능
-
sudo ausearch -i -m SECCOMP -ts recent 실행 후, syscall 값 확인
- 해당 syscall 혹은 관련 그룹을 SystemCallFilter에 추가하여 순차적으로 문제 해결 가능
보안 강화 적용 우선순위 및 운영 팁
- 모든 서비스에 전부 적용할 필요는 없음
- 위협 모델과 위험 관리가 핵심, 특히 외부 노출 서비스(httpd, nginx, ssh 등)는 필수 고려
- 커스텀 커맨드, timer 유닛(구 cron 대체) 등도 선제 적용이 효과적임
- 복잡하지 않은 서비스일수록 미세한 조정 가능성이 높음
체크리스트: 추천 보안 옵션 조합 (초기 적용 우선순위)
-
ProtectSystem=strict
-
PrivateTmp=yes
-
ProtectHome=yes 또는 ProtectHome=tmpfs
-
ProtectClock=yes, ProtectKernelLogs=yes, ProtectKernelModules=yes
-
RestrictSUIDGUID=yes
-
UMask=0077
-
LockPersonality=yes
-
RestrictRealtime=yes
-
MemoryDenyWriteExecute=yes
-
DynamicUser=yes 또는 User를 root 이외의 특정 사용자로 지정
- 위 항목들은 일반적으로 서비스에 거의 지장 없이 사용할 수 있는 조합
- 추가로 syscall 필터링(SystemCallFilter)까지 적용하려면 상세 테스트 필요
Traefik 예시 설정
- 컨테이너 기반 Traefik 서비스를 systemd quadlet으로 실행하며, 보안 옵션을 다수 적용한 사례임
-
ProtectSystem=full, ProtectHome=yes, SystemCallFilter=@system-service @mount @privileged 등 적용
-
CapabilityBoundingSet=~CAP_SETUID CAP_SETPCAP로 특정 권한 제거
-
RestrictAddressFamilies=AF_INET AF_INET6 AF_UNIX AF_NETLINK 등 네트워크 접근 제한 적용
결론
- systemd 보안 강화 옵션은 유닉스 계열 시스템 관리자라면 도구 상자에 하나쯤 넣어둘 만한 실용적 수단임
- 완벽한 보안책이 아니라 리스크를 줄이는 도구로 활용해야 하며, 모든 서비스에 무분별한 보안 설정을 적용할 필요는 없음
- 특히 self-hosting 환경의 관리자가 활용할 경우 보안 수준 향상에 큰 도움이 됨
- "완벽함보다 실용성"을 우선으로, 업무와 환경에 맞는 범위 내에서 부분적으로라도 적용하는 것을 권장