새 VPS에서 Lynis를 처음 돌리면 대개 60 언저리의 숫자와, 무엇부터 손대야 할지 알 수 없는 긴 제안 목록이 나옵니다. 좋은 소식: 80에서 85는 하룻저녁의 작업이고, 대부분의 단계는 겉치레가 아니라 정말 할 만한 것들입니다. 나쁜 소식: 마지막 15점은 임대한 가상 머신에서는 닿을 수 없으며, 그것을 쫓는 것은 실수입니다.

이 index가 보여 주는 것과 보여 주지 않는 것

hardening index는 가중치를 포함해 통과한 검사가 전체에서 차지하는 비율입니다 — 안전성의 백분율이 아닙니다. Lynis는 삼백 개쯤의 검사를 돌리고 서로 다른 두 목록을 냅니다. 진짜 문제처럼 보이는 warnings와, 개선할 수 있는 것들인 suggestions입니다. 언제나 경고부터 시작하세요. 보통 몇 건뿐입니다.

100점은 나오지 않습니다. 어떤 제안은 시스템을 설치할 때의 결정을 요구하고(/home, /tmp, /var의 별도 파티션), 어떤 것은 VPS에는 없는 부트로더 접근을 요구하며, 몇몇은 서로 모순됩니다. 그리고 자신의 index를 남의 것과 비교하는 일은 무의미합니다. Lynis는 머신에서 돌아가는 것에 대해 점수를 깎기 때문입니다. 돌아가는 서비스가 하나 늘 때마다 열린 포트가 하나, 자체 설정이 하나, 새 제안이 열 개쯤 늘어납니다. 그래서 높은 숫자는 SSH 말고는 아무것도 돌지 않는 곳에서 더 자주 보입니다. 사이트와 데이터베이스와 메일이 있는 실가동 서버라면 85는 좋은 결과입니다.

root로 실행하세요

sudo lynis audit system

sudo 없이는 Lynis가 시스템 파일이 필요한 모든 검사를 건너뛰고 더 낮은 index를 보고합니다 — 서버가 나빠서가 아니라 검사가 보이지 않았기 때문입니다. 보고서는 /var/log/lynis-report.dat에, 읽기 좋은 로그는 /var/log/lynis.log에 기록됩니다.

출력의 각 줄은 검사 식별자로 시작합니다. 예를 들어 SSH-7408이나 KRNL-6000. 바로 그 식별자로 설명도 찾고 검사를 끄는 방법도 찾습니다 — 그 모양을 기억해 두세요. 아래의 모든 것이 이것을 중심으로 돕니다.

실제로 숫자를 움직이는 것

SSH (SSH-7408). 가장 무거운 덩어리입니다. 검사 하나가 열 개 넘는 매개변수를 동시에 봅니다. sshd_config 전체를 고치지 마세요. 패키지 업데이트가 작업을 지우지 못하도록 별도 파일을 두세요.

sudo tee /etc/ssh/sshd_config.d/10-hardening.conf <<'EOF'
PermitRootLogin no
PasswordAuthentication no
MaxAuthTries 3
MaxSessions 2
X11Forwarding no
AllowTcpForwarding no
ClientAliveInterval 300
ClientAliveCountMax 2
LogLevel VERBOSE
TCPKeepAlive no
EOF
sudo sshd -t && sudo systemctl reload ssh

서비스를 다시 읽기 전의 sshd -t는 필수입니다. 세션이 열려 있는 동안 설정에서 저지른 실수는 당신을 밖에 남겨 둡니다. 그리고 PasswordAuthentication no를 넣기 전에, 키가 정말 작동하는지 — 열려 있는 두 번째 터미널에서 — 확인하세요.

커널 매개변수 (KRNL-6000). 이 검사는 스무 개쯤의 sysctl 값을 봅니다. 그것들을 위한 파일:

sudo tee /etc/sysctl.d/99-hardening.conf <<'EOF'
kernel.dmesg_restrict = 1
kernel.kptr_restrict = 2
kernel.sysrq = 0
fs.protected_hardlinks = 1
fs.protected_symlinks = 1
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.all.log_martians = 1
EOF
sudo sysctl --system

없는 도구들. 제안의 상당 부분은 그저 「없는 것을 설치하라」입니다. auditd(시스템 이벤트 기록), aide(파일 무결성), debsums(패키지 무결성), unattended-upgrades(자동 보안 업데이트), sysstat와 acct(프로세스 회계), 악성코드 검사기. 각각이 제안을 한둘 닫아 주지만 점수 때문에 설치하지는 마세요. 그것들이 없으면 사고 이후에 아무것도 되짚을 수 없습니다.

수고 대비 효과가 좋은 작은 것들. /etc/login.defs의 umask 027, 같은 파일의 비밀번호 유효기간, /etc/issue와 /etc/issue.net의 배너, root만 읽을 수 있는 컴파일러(chmod 700 /usr/bin/gcc). 배너에 대해 솔직히 말하자면, 안전에는 아무 기여도 하지 않습니다. 법적 형식일 뿐입니다 — 다만 점수는 확실히 줍니다.

login.defs의 함정 하나

sed로 줄을 바꿔 umask를 고치면 파일에 UMASK 줄이 여러 개 남는 일이 흔합니다. 그러면 Lynis는 값을 세지 않고, 설정은 된 것처럼 보이는데 검사 AUTH-9328은 계속 빨간 채로 남습니다. 수정 뒤 확인하세요.

grep -c '^UMASK' /etc/login.defs

정확히 하나여야 합니다. 그 파일의 다른 모든 매개변수도 마찬가지입니다.

오탐과 그것을 제대로 잠재우는 법

어떤 경고는 당신의 서버에 전혀 해당되지 않습니다. 살아 있는 예: 어느 대형 업체의 VPS에서 검사 PKGS-7388이 보안 저장소를 찾지 못했다고 보고합니다 — 저장소가 미러 파일 참조와 함께 deb822 형식으로 기술돼 있고 Lynis는 익숙한 형태를 찾고 있기 때문일 뿐입니다. 보안 업데이트는 멀쩡히 도착하고 있습니다.

이것은 보고서에서 줄을 지우는 것이 아니라 프로파일로 잠재웁니다. 프로파일 파일의 확장자는 .prf입니다(.prof가 아닙니다 — 여기서 30분을 잃기 쉽습니다). 자신의 규칙은 /etc/lynis/custom.prf로 갑니다.

skip-test=PKGS-7388
skip-test=KRNL-5788

규칙은 하나. 각 줄 옆에는 왜 그 검사를 건너뛰는지 적은 주석이 필요합니다. 반년 뒤에는 해당되지 않아서 껐는지, 고치기가 번거로워서 껐는지 기억하지 못할 테니까요 — 그리고 그 둘의 차이가 바로 핵심입니다.

하지 말아야 할 것

숫자를 쫓지 마세요. 불편한 검사를 끄면 index는 쉽게 부풀고, 어느 수준을 넘어서면 그것이 유일한 길이기도 합니다 — 다만 서버가 그것으로 더 안전해지지는 않습니다. 유용한 것은 다른 쪽입니다. 자신의 값을 기록하고 그 변화를 지켜보는 것. 업데이트 뒤나 누군가 설정을 고친 뒤에 떨어진 index는 그 절대적 크기보다 훨씬 값진 신호입니다.

바로 그래서 Lynis는 한 번이 아니라 일정에 따라 돌리고, 비교할 것이 남도록 보고서를 보관할 가치가 있습니다. 한 페이지에 모으면 어떤 모습인지는 아래 데모에서: index, 검사 식별자가 붙은 경고 목록, 그리고 지난 실행 이후 무엇이 바뀌었는지.