![[보안] 리눅스 서버 하드닝 전략 재점검 체크리스트](https://blog.pswq.net/wp-content/uploads/2026/08/linux-cve-spike-server-hardening-checklist-thumbnail.jpg)
목차
- 1. 최근 Linux CVE가 많이 보이는 이유부터 정리해보겠습니다
- 2. 리눅스 서버 하드닝 체크리스트, 우선순위는 이렇게 잡으시면 됩니다
- 3. 실전 구현 1단계: 패치 상태와 커널 노출 범위부터 확인합니다
- 4. 실전 구현 2단계: SSH와 네트워크부터 조입니다
- 5. 실전 구현 3단계: SELinux, AppArmor, systemd sandboxing으로 한 번 더 막습니다
- 6. 커널 노출면 줄이는 sysctl과 감사 로그도 같이 가야 합니다
- 7. ⚠️ 실제로 자주 겪는 문제와 트러블슈팅
- 8. 검증, 결과 확인, 그리고 다음 단계
- 정리: 지금 바로 다시 볼 체크포인트
- 참고한 공개 자료
리눅스 서버 하드닝 전략 재점검 체크리스트
요즘 보안 메일함 열어보면 심장이 조금 빨리 뛰죠. 특히 리눅스 서버 하드닝 관점에서 보면, 커널과 사용자 공간(User space, 커널 밖에서 도는 일반 프로세스) 취약점 공지가 꽤 자주 올라옵니다. 저도 홈랩이랑 운영 서버를 같이 굴리다 보니, 처음엔 “요즘 왜 이렇게 Linux CVE가 많아졌지?” 싶었거든요. 그런데 실제로 뜯어보니, 단순히 숫자만 늘었다기보다 공개 체계가 더 촘촘해진 부분, 그리고 실제로 빨리 패치해야 하는 취약점이 섞여 있더라고요.
특히 2024년 2월 13일에 kernel.org가 CVE Numbering Authority(CNA, CVE 번호 발급 권한 기관)로 추가된 뒤부터는 Linux 커널 취약점에 CVE가 더 체계적으로 붙기 시작했습니다. 거기에 CISA가 실제 악용 사례가 있는 Linux kernel 취약점들을 Known Exploited Vulnerabilities(KEV) 목록에 올리면서, “아, 이건 숫자 구경만 할 게 아니구나” 싶었거든요. 리눅스 보안은 결국 패치 속도만의 문제가 아니라, 노출면(Attack Surface, 공격 가능 면적)을 줄이는 운영 습관의 문제이기도 합니다.
커널, SSH, 방화벽, MAC 정책, 패치 자동화, 검증 흐름까지 한눈에 보여주는 개요 이미지입니다.
1. 최근 Linux CVE가 많이 보이는 이유부터 정리해보겠습니다
쉽게 말해, 요즘 보이는 “급증”은 두 가지가 섞여 있습니다. 발견과 공개가 더 적극적이 된 점, 그리고 실제 운영자가 체감할 정도로 대응 압박이 커진 점이 같이 온 겁니다.
| 구분 | 무슨 뜻인가 | 운영자가 봐야 할 포인트 |
|---|---|---|
| CVE 공개 체계 변화 | kernel.org가 2024-02-13부터 CNA 역할 수행 | 이전보다 커널 취약점이 더 잘 드러날 수 있음 |
| 실제 악용 사례 | CISA가 Linux kernel CVE를 KEV에 추가 | 패치 우선순위를 높게 잡아야 함 |
| 자동화된 버그 탐지 | fuzzing과 정적/동적 분석이 더 활발 | 작은 버그도 더 빨리 공론화됨 |
여기서 중요한 포인트가 있습니다. CVE 숫자가 늘었다 = 리눅스가 갑자기 위험해졌다로 바로 연결하면 좀 단순합니다. 제가 직접 홈랩 커널 업데이트 흐름을 따라가 보니까, 예전엔 배포판 공지 뒤에 숨어 지나가던 수정이 이제는 CVE로 더 명확하게 드러나는 경우도 꽤 있더라고요. 반대로, KEV에 들어간 건 진짜 우선순위가 다릅니다. 이건 “나중에 점검”이 아니라 즉시 확인 쪽입니다.
2. 리눅스 서버 하드닝 체크리스트, 우선순위는 이렇게 잡으시면 됩니다
저는 보통 패치, 접근 통제, 권한 축소, 관측성 순으로 봅니다. 이유는 간단하거든요. 멋진 보안 솔루션보다 먼저, 뚫릴 구멍을 줄이는 게 훨씬 싸고 빠릅니다.
- 커널과 패키지 업데이트 기준선 만들기: 지금 어떤 커널을 쓰는지, 보안 업데이트가 몇 건 밀렸는지 숫자로 확인합니다.
- SSH 노출면 줄이기: 비밀번호 로그인, root 직접 로그인, 불필요한 포트 노출을 먼저 줄입니다.
- 방화벽 기본 정책 정리: 허용 목록(Allowlist, 허용 대상만 열기) 방식으로 바꿉니다.
- SELinux/AppArmor 같은 MAC 적용: 뚫려도 옆으로 번지는 걸 막습니다.
- systemd sandboxing: 서비스 단위로 권한을 더 잘게 자릅니다.
- 감사 로그와 검증 루틴: 적용 후 확인하지 않으면 하드닝이 아니라 기분만 좋아지는 설정이 됩니다.
3. 실전 구현 1단계: 패치 상태와 커널 노출 범위부터 확인합니다
처음엔 이게 뭔가 싶었는데, 결국 출발점은 단순합니다. 무엇이 돌아가고 있는지 알아야 CVE 대응도 빠릅니다. 아래 명령은 제가 새 서버 잡으면 거의 습관처럼 먼저 칩니다.
uname -r
cat /etc/os-release
ss -tulpn
systemctl --failed
uname -r은 현재 커널 버전, ss -tulpn은 외부에 열려 있는 포트와 프로세스를 같이 보여줍니다. 여기서 예상 밖 포트가 보이면, 그 서버는 이미 서버 보안 강화 대상입니다.
Debian/Ubuntu 계열이면 보안 업데이트 확인은 이렇게 시작하시면 됩니다.
sudo apt update
apt list --upgradable
sudo unattended-upgrades --dry-run -d
RHEL 계열은 보통 이렇게 봅니다.
sudo dnf check-update
sudo dnf updateinfo list security
Ubuntu를 쓰신다면 Livepatch(재부팅 없이 일부 커널 보안 수정 적용)도 검토할 만합니다. 다만 Canonical 문서 기준으로 Livepatch만 믿고 장기간 재부팅을 미루면 안 됩니다. 지원되는 커널 ABI 범위와 재부팅 주기가 따로 있거든요. 실제로 써보니까 편하기는 한데, 이것도 결국 정식 커널 교체를 완벽히 대체할 수는 없더라고요.
4. 실전 구현 2단계: SSH와 네트워크부터 조입니다
제가 제일 먼저 손대는 부분입니다. CVE가 터졌을 때 제일 아쉬운 서버가 어떤 서버냐 하면, 패치가 늦은 서버보다도 불필요하게 다 열어둔 서버더라고요. 삽질 좀 했습니다 ㅎㅎ
sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak.$(date +%F)
sudoedit /etc/ssh/sshd_config
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
MaxAuthTries 3
AllowUsers adminops
적용 전에는 반드시 문법 검사를 하세요.
sudo sshd -t && sudo systemctl reload sshd
방화벽은 nftables 기준으로 아주 단순하게 시작하는 편이 좋습니다.
sudo mkdir -p /etc/nftables
sudoedit /etc/nftables.conf
#!/usr/sbin/nft -f
flush ruleset
table inet filter {
chain input {
type filter hook input priority 0;
policy drop;
iif lo accept
ct state established,related accept
tcp dport { 22, 80, 443 } accept
ip protocol icmp accept
ip6 nexthdr icmpv6 accept
}
chain forward {
type filter hook forward priority 0;
policy drop;
}
chain output {
type filter hook output priority 0;
policy accept;
}
}
sudo nft -f /etc/nftables.conf
sudo nft list ruleset
sudo systemctl enable --now nftables
SSH 접근 제한, 허용 포트 최소화, 상태 기반 방화벽 정책을 시각적으로 보여주는 이미지입니다.
5. 실전 구현 3단계: SELinux, AppArmor, systemd sandboxing으로 한 번 더 막습니다
Mandatory Access Control(MAC, 강제 접근 통제)은 초반엔 귀찮아 보여도, 사고 났을 때 진짜 값어치를 합니다. Red Hat 문서도 SELinux를 추가 보안 계층으로 설명하고 있고, Ubuntu 문서도 AppArmor를 경로 기반 MAC으로 안내합니다. 쉽게 말해 프로세스가 원래 해야 할 일만 하게 만드는 장치입니다.
RHEL 계열에서는 SELinux 상태를 먼저 확인하세요.
getenforce
sestatus
sudo setenforce 1
Ubuntu 계열에서는 AppArmor 상태를 확인합니다.
sudo apparmor_status
sudo aa-enforce /etc/apparmor.d/*
그리고 요즘 제가 자주 같이 보는 게 systemd-analyze security입니다. 서비스별 노출 점수를 빠르게 볼 수 있어서, 감으로 하드닝하는 느낌이 훨씬 줄어들더라고요.
sudo systemd-analyze security nginx.service
서비스 오버라이드(override)로 샌드박싱을 추가하는 예시는 아래처럼 시작하시면 됩니다.
sudo systemctl edit nginx.service
[Service]
NoNewPrivileges=yes
PrivateTmp=yes
ProtectSystem=strict
ProtectHome=yes
PrivateDevices=yes
RestrictSUIDSGID=yes
LockPersonality=yes
MemoryDenyWriteExecute=yes
RestrictAddressFamilies=AF_INET AF_INET6 AF_UNIX
SystemCallArchitectures=native
sudo systemctl daemon-reload
sudo systemctl restart nginx
sudo systemd-analyze security nginx.service
이거 실제로 써보니까 꽤 좋더라고요. 다만 여기서 중요한 건, 서비스별로 필요한 권한이 다르다는 점입니다. DB나 백업 에이전트는 너무 세게 조이면 바로 깨집니다.
6. 커널 노출면 줄이는 sysctl과 감사 로그도 같이 가야 합니다
리눅스 서버 하드닝에서 빠지기 쉬운 게 커널 파라미터와 로그입니다. 공격 자체를 막는 것도 중요하지만, 이상 징후를 빨리 보는 것도 중요하거든요.
sudoedit /etc/sysctl.d/99-hardening.conf
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.default.accept_redirects = 0
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.default.send_redirects = 0
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1
net.ipv4.tcp_syncookies = 1
kernel.kptr_restrict = 2
kernel.dmesg_restrict = 1
fs.protected_symlinks = 1
fs.protected_hardlinks = 1
sudo sysctl --system
감사 로그(audit log)도 최소한은 잡아두는 편이 좋습니다.
sudo apt install auditd -y || sudo dnf install audit -y
sudo systemctl enable --now auditd
sudo auditctl -w /etc/ssh/sshd_config -p wa -k ssh_config_change
sudo auditctl -w /etc/sudoers -p wa -k sudoers_change
sudo auditctl -w /usr/bin/sudo -p x -k sudo_exec
여기서 정말 중요한 포인트예요. 로그는 쌓는 것보다 어떤 이벤트를 보면 위험 신호로 판단할지가 더 중요합니다. SSH 설정 변경, sudo 실행 급증, 예상하지 못한 서비스 재시작 같은 건 바로 알아채야 하거든요.
프로세스 권한 최소화와 서비스 격리를 여러 층으로 적용하는 장면을 표현한 이미지입니다.
7. ⚠️ 실제로 자주 겪는 문제와 트러블슈팅
하드닝은 설정 넣는 순간보다, 그 뒤에 안 깨지게 만드는 과정이 더 어렵습니다. 저도 처음엔 자신 있게 적용했다가 웹 서비스가 파일 못 읽어서 502 띄운 적 있습니다.
- SELinux/AppArmor 적용 후 서비스 장애: 먼저 비활성화하지 말고 로그를 봅니다. SELinux는
/var/log/audit/audit.log, AppArmor는journalctl -xe나/var/log/syslog쪽부터 확인하세요. - systemd sandboxing 후 서비스 기동 실패:
ProtectSystem=strict,ProtectHome=yes가 자주 원인입니다. 서비스가 실제로 써야 하는 경로를ReadWritePaths=로 열어줘야 할 수 있습니다. - SSH 설정 변경 후 원격 접속 끊김: 운영 중인 세션을 유지한 상태에서 새 세션으로 테스트하고, 가능하면 콘솔 접근 수단을 남겨두세요.
- 방화벽 적용 후 내부 통신 장애: 모니터링, 백업, 노드 간 헬스체크 포트를 빼먹는 경우가 많습니다. 홈랩에서 Kubernetes 올릴 때 저도 이걸로 반나절 썼습니다.
그래서 저는 항상 한 번에 다 바꾸지 않고, 서비스 하나씩 묶어서 적용합니다. 보안 체크리스트는 체크만 하면 끝나는 문서가 아니라, 배포 순서를 정리하는 운영 문서여야 하더라고요.
8. 검증, 결과 확인, 그리고 다음 단계
설정이 들어갔으면 반드시 검증해야 합니다. 아래 정도는 최소 루틴으로 가져가면 좋습니다.
- 커널/패키지 버전 확인: 패치 적용 전후 버전 차이를 기록합니다.
- 포트 노출 재검사:
ss -tulpn결과를 저장해 비교합니다. - 서비스 샌드박스 점검:
systemd-analyze security로 전후 점수를 비교합니다. - 로그 확인: SELinux/AppArmor 거부 로그, audit 로그, 인증 로그를 같이 봅니다.
- 재부팅 리허설: 커널 업데이트 후 서비스가 정상 복구되는지 꼭 확인합니다.
uname -r
ss -tulpn
sudo systemd-analyze security
sudo journalctl -p warning -b
sudo ausearch -k ssh_config_change
제가 직접 해보니 가장 효과가 큰 건 화려한 솔루션이 아니라 패치 기준선 + SSH 제한 + 방화벽 기본 거부 + MAC + 서비스 샌드박스 이 5개였습니다. 드디어 됐다! 싶은 순간이 오긴 오는데, 사실 그 뒤가 더 중요합니다. 운영 환경은 계속 바뀌니까요.
적용 전후 비교 결과를 대시보드 형태로 보여주는 검증 이미지입니다.
정리: 지금 바로 다시 볼 체크포인트
- 리눅스 서버 하드닝은 CVE 개수보다 노출면 축소가 핵심입니다.
- kernel.org CNA 전환과 실제 악용 사례 공개를 보면, 공개량 증가와 실제 위험 신호를 구분해서 봐야 합니다.
- CVE 대응은 패치만이 아니라 SSH, nftables, SELinux/AppArmor, systemd sandboxing까지 묶어서 봐야 합니다.
- 검증 없는 하드닝은 절반짜리입니다. 적용 후 로그와 서비스 상태를 꼭 확인하세요.
다음 글에서는 systemd 서비스별 하드닝 템플릿을 좀 더 깊게 다뤄볼 예정입니다. 이전 글에서 다뤘던 로그 수집 파이프라인이 있으시면 그쪽과 묶어서 보셔도 좋고요.
패치, 접근 통제, MAC, 샌드박스, 로그 검증을 우선순위별로 정리한 요약 이미지입니다.
참고한 공개 자료
- CVE Program: kernel.org Added as CVE Numbering Authority
- NVD: CVE-2024-53150
- NVD: CVE-2024-53197
- Ubuntu Security Documentation: Security updates
- Ubuntu Livepatch: Kernels covered by Livepatch
- Red Hat Documentation: Getting started with SELinux
- Ubuntu Security Documentation: AppArmor
- systemd-analyze manual
- nftables wiki: Quick reference
![[Linux] SSH 하드닝 실전 가이드: 무단 접근 방어 5단계 보안 강화](https://blog.pswq.net/wp-content/uploads/2026/07/ssh-hardening-security-best-practices-case-study-thumbnail.jpg)
