SystemD 서비스 보안 강화 (Hardening)

(roguesecurity.dev)

5P by GN⁺ 4일전 | ★ favorite | 댓글 1개

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 환경의 관리자가 활용할 경우 보안 수준 향상에 큰 도움이 됨
"완벽함보다 실용성"을 우선으로, 업무와 환경에 맞는 범위 내에서 부분적으로라도 적용하는 것을 권장

▲

GN⁺ 4일전 [-]

Hacker News 의견

자동화된 systemd 서비스 하드닝을 strace 프로파일링을 통해서 구현할 수 있다는 점이 흥미롭다고 생각함
https://github.com/desbma/shh
- 내가 찾아낸 좋은 방법이 있는데, ProtectSystem=을 예제에선 사용하지 않았지만
  TemporaryFileSystem=/:ro, BindReadOnly=/usr/bin/binary /lib /lib64 /usr/lib usr/lib64 와 같이 하면
  원하는 바이너리와 읽기 원하는 경로만 포함시킬 수 있음
  ProtectSystem=은 현재 이 동작과 호환되지 않음
  더 자세한 내용은 여기 참고
- 이 방식이 에러 발생 시 이메일을 보내는 등 추가 동작이 필요한 서비스에는 문제가 될 수 있다고 생각함
어제 올라온 systemd 하드닝 관련 글에 비해 훨씬 현실적이며 바로 적용 가능한 좋은 팁들이 많음
내가 어제 글 댓글에서 더 실제적인 예시를 들려주려고 노력했었는데, 오늘 글은 실질적인 내용을 멋지게 잘 정리해서 systemd로 격리와 보안을 빠르고 쉽게 강화할 수 있는 방법들을 알려줌
훌륭한 글이라고 생각함
어제 글도 참고로 남김
https://us.jlcarveth.dev/post/hardening-systemd.md
https://news.ycombinator.com/item?id=44928504
- 사이트 인증서 이슈를 수정해주면 좋겠음
  일부 브라우저에서는 인증서 오류 때문에 접근 자체가 불가능함
공유해줘서 고마움
systemd-analyze를 --user 플래그와 함께 사용하면 systemd 사용자 유닛의 보안을 확인할 수 있음("systemd-analyze --user security")
컨테이너를 Podman으로 이전하면서 systemd를 더 많이 쓰기 시작했고, 이 툴이 systemd 유닛/컨테이너 서비스의 보안 향상에 많은 도움이 될 것임
예전 init 스크립트는 모두 제각각이라서 이런 일관된 강화 작업이 불가능했음
- 물론 기존 init 스크립트로도 이런 강화 작업을 할 수 있긴 하지만, systemd는 커널의 좋은 기능들을 표준적이고 일관된 방법으로 쉽게 쓸 수 있게 도와줌
  나는 리눅스에 비교적 늦게 입문해서 systemd 없는 시스템을 상상하기 힘들고, systemd 없는 시스템은 다루기 너무 불편했음
  최근엔 "unshare"라는 툴을 발견해서 /nix 전체를 RW로 다시 마운트하는 등의 실험을 다른 프로세스에 영향 없이 할 수 있었음
  systemd는 사용성이 다소 투박하긴 하지만 대안은 솔직히 내게는 Windows뿐이라고 생각함
왜 리눅스 배포판에서 이런 보안 스위치를 기본적으로 더 많이 활성화하지 않는지 궁금함
보수적으로 강화하는 데에 단점이 있나 생각함
많은 사용자에게는 세팅이 너무 많고 복잡할 수 있음
- 너무 공격적으로 세팅을 변경하면 의도치 않게 기존 설정이 깨질 수 있음
  예를 들어 NetworkManager를 강화했다면 IPv4, IPv6 모두 연결되는지, dns=systemd-resolved와 dns=default 모드가 정상 동작하는지, ModemManager와 셀룰러 연동, openvpn이나 cisco anyconnect 플러그인, NetworkManager-dispatcher hook 등 다양한 부분을 일일이 검증해야 함
  또 얼마나 많은 배포판 관리자가 자신이 관리하는 패키지의 스위치를 어느 정도까지 바꿔도 사용자 환경 0.01% 이상이 깨지지 않는지 확신할 수 있는지도 문제임
  이러한 플래그를 배포판에서 관리하면 업스트림 릴리즈 때마다 호환성 이슈가 덤으로 따라오고, 반대로 업스트림이 설정하면 하위 호환성 때문에 더 신중하게만 쓸 수밖에 없음
- 이 질문은 "왜 배포판에서 기본적으로 MAC(SELinux 등)을 강하게 안 쓰는가?"와 비슷함
  sshd 같은 것도 더 제한을 두는 게 좋긴 하지만
  1. 적용을 위한 초기 개발 비용
  2. 각종 사용자 환경마다 벌어지는 버그 리포트 처리 비용
  3. 배포판/업스트림 변화에 맞춘 지속 관리 비용
    이런 것 때문에 메이저 배포판에서는 부담이 큼
    SELinux, AppArmor도 마찬가지로 유지 관리자들이 투자 대비 효과를 낮게 보는 경우가 많음
- 핵심 시스템 서비스의 정상 동작을 각 파라미터마다 일일이 통합 테스트할 역량이나 리소스가 없는 것도 큰 이유임
  관련 대화
  https://news.ycombinator.com/item?id=29995566
  systemd-analyze security 결과가 배포판별로 다름
  desbma/shh는 strace로 수집한 내용을 SyscallFilter 등 단위별 룰로 자동 생성해주는데, SELinux의 audit2allow와 유사함
  하지만 strace를 운영 환경에 설치하는 것은 논란이 가능함
  https://github.com/desbma/shh
- 나도 잘 모르겠지만, 일부 세팅은 새로 추가된 것들이라 많은 사용자가 잘 모를 수도 있음
  systemd 고수만 있는 게 아니고, 설정을 켜면 이전 버전 systemd에서 정상 동작하지 않을 위험도 있음
  SELinux, AppArmor 등 다양한 기능이 있지만, 많은 배포판이나 개발자, 사용자들이 굳이 필요하다고 느끼지 않아서 자동 적용이 어려운 부분임
보안 강화를 위한 옵션이 너무 많아서, 일반적인 서비스별 하드닝 예시를 모아둔 저장소가 있으면 좋겠다고 생각함
사용자들이 공통적으로 적용하는 강화 스크립트를 활용하는 경우가 많은데, 의외로 권한을 더 넓게 설정해야 예외 상황이 발생하지 않음을 발견하게 됨
- nixpkgs같이 업스트림 지원이 부족한 배포판에서 패키징할 때는
  메인스트림 배포판에서 어떻게 패키징 및 하드닝하는지 참고하는 게 제일 유용함
  그런 하드닝 방법들이 보통 충분히 테스트된 경우가 많으니, postgresql 등 강화 예시가 궁금하다면 Debian, Ubuntu, RHEL 패키지에서 출발하는 게 좋음
systemd가 제공하는 훌륭한 보안 기능 중 하나가 크리덴셜 관리임
이를 통해 환경 변수나 파일 시스템에 저장하는 것보다 더 안전하게 애플리케이션에 자격 증명을 전달할 수 있음
Vault 등이 없는 환경, 예를 들어 개인 프로젝트에선 항상 이 방법을 선호함
해당 기능과 연동되는 Go 패키지도 직접 만듦
systemd에서의 credentials
credential-go 패키지
- nodejs나 npm처럼 2줄짜리 코드도 패키지로 만드는 문화 같다고 생각함
  실제로는
```
dir, err := os.Getenv("CREDENTIALS_DIRECTORY")
cred, err := os.ReadFile(filepath.Join(dir, "name"))
```
  left-pad보다도 복잡하지 않음
  Go 커뮤니티에서는 원래 의존성을 줄이고, 불필요한 추상화(함수 호출 등)를 피하는 게 미덕이었던 것으로 아는데
  이런 간단한 동작은 다들 즉석에서 직접 작성하곤 했었음
- 이 credential 전달방식이 포크된 자식 프로세스까지 자격 증명 상속을 어떻게 막는지 궁금함
정말 유용한 글임
systemd 각 옵션 리스트와, "man을 참고하고 행운을 빈다" 같은 조언도 마음에 들음
systemd는 정말 훌륭해서 내 서버에 적극 배포하고 싶음
사소한 팁이지만 제목 표기에서 systemd의 올바른 표기는 systemd임
SystemD, system D, system d 등이 아닌 systemd가 맞음
이유는 system daemon이어서, 유닉스/리눅스 전통대로 소문자 d로 끝나는 이름을 쓴 것임
- 흥미로운 사실임
  나는 보통 systemD로 부르는 걸 많이 봤는데 왜 그렇게 널리 쓰였는지 궁금함
systemd에서 syscall 이슈를 디버깅하는 팁이 정말 유용함

답변달기