Logwatch는 그러지 않으면 풀리지 않는 문제를 풉니다. 서버의 모든 로그를 대신 읽고 지난 하루의 요약을 보내 줍니다. auth.log와 웹 서버 로그를 매일 훑는 사람은 없지만, 아침에 메일 하나를 읽는 일은 해낼 수 있습니다.

알려진 문제. 첫 메시지가 수백 줄로 오고, 두 번째는 대충 훑고, 일주일 뒤에는 메일 규칙이 그것들을 별도 폴더로 보내며, 그것으로 감시는 끝납니다. 원인은 거의 언제나 기본 설정이고, 고치는 데 10분이 걸립니다.

설치와 설정을 바꾸는 자리

sudo apt install logwatch

당신의 값을 어디에 두느냐가 중요합니다. 파일 /usr/share/logwatch/default.conf/logwatch.conf는 건드리면 안 됩니다 — 패키지가 업데이트될 때 덮어써집니다. 당신의 파일은 /etc/logwatch/conf/logwatch.conf입니다. 비어 있어도 되며, 바꾸는 것만 적으면 충분합니다.

Output = mail
Format = html
MailTo = admin@example.com
Detail = Low
Range = yesterday

상세 수준이 모든 것을 결정한다

Detail은 0부터 10까지의 값이나 Low, Med, High라는 단어를 받습니다. 차이는 엄청납니다. High에서는 보고서에 모든 연결과 모든 요청이 들어가고, Low에서는 합계와 이상만 들어갑니다.

실무는 이렇습니다. 전체적으로는 Low, 그리고 정말로 신경 쓰는 서비스에 대해서만 골라서 상세도를 올립니다. 서비스별 설정은 /etc/logwatch/conf/services/에 들어갑니다 — 예컨대 Detail = High 한 줄을 담은 sshd.conf 파일.

확인 기준: 보고서는 화면 하나나 하나 반에 들어가야 합니다. 그보다 길면 읽히기를 그만둡니다 — 게을러서가 아니라, 삼백 줄의 일상 속에서 이탈이 보이지 않기 때문입니다.

아침까지 기다리지 않고 결과를 보려면:

sudo logwatch --detail Low --range today --output stdout

Debian 12의 빈 SSH 섹션

최근 시스템의 별도 함정입니다. Logwatch는 /var/log의 텍스트 파일을 읽는데, Debian 12와 Ubuntu 24.04는 더 이상 기본으로 rsyslog를 설치하지 않습니다 — 파일 /var/log/auth.log가 아예 없고 모든 것이 systemd 저널로 갑니다. 보고서는 여전히 성실하게 오지만, 가장 중요한 섹션인 SSH 로그인은 비어 나오거나 아예 없습니다.

확인은 1초입니다.

ls -l /var/log/auth.log

파일이 없으면 rsyslog를 설치하거나, 이 머신의 Logwatch가 불완전한 그림을 보여 준다는 것을 받아들여야 합니다. 빈 섹션은 「아무 일도 없었다」로 읽히기 쉽고, 그것이 가장 위험한 결과입니다.

메일이 가는 곳

「보고서가 오지 않는다」의 두 번째로 흔한 원인. 서버에 메일 발송이 설정돼 있지 않은 것입니다. Logwatch는 메시지를 시스템 에이전트에 넘기고, 에이전트는 그것을 아무 데도 보내지 않으며, 메시지는 아무도 들여다보지 않는 root의 지역 메일함에 쌓입니다.

sudo cat /var/mail/root | tail -50

선택지는 둘입니다. 외부 SMTP 릴레이를 통한 발송을 설정하거나, 메일을 아예 쓰지 않고 보고서를 파일로 쓰거나.

Output = file
Filename = /var/log/logwatch/report.txt

두 번째가 더 정직합니다. 아무도 전달하지 못하는 메일은 감시의 환상을 만들지만, 디스크의 파일은 적어도 열어 볼 수 있습니다.

보고서에서 무엇을 읽을 것인가

유용한 순서대로:

  • sshd. 성공한 로그인 — 누가, 어디서. 수천 건의 실패가 아니라 바로 성공한 것들입니다. 실패는 배경이고, 낯선 주소에서의 로그인은 설명이 필요합니다;
  • sudo와 pam_unix. 누가 권한을 올렸고 누가 사용자를 만들었는가;
  • Disk Space. 차오르는 디스크를 미리 경고하는 한 줄;
  • cron. 나타난 작업과 실패한 작업;
  • http. 404 응답의 급증은 대개 경로 탐색이고, 500의 급증은 당신의 무언가가 망가졌다는 뜻입니다;
  • 서버가 메일을 보낸다면 postfix. 늘어나는 발신 대기열은 서버가 스팸 릴레이로 쓰이게 됐다는 전형적인 표시입니다.

한계

Logwatch는 경보가 아니라 지난 하루의 요약입니다. 밤에 당신을 깨우지 않고 정의상 뒤처집니다. 새벽의 일일 작업에서 돌며 어제를 다루니까요. 「지금 무언가 벌어지고 있다」에는 적합하지도 않고 그럴 의도도 없습니다.

그 힘은 다른 데 있습니다 — 평범한 하루의 모습을 보여 준다는 것. 한 달을 읽고 나면 실패한 로그인이 평소 몇 건인지, 사이트가 요청을 얼마나 받는지, 메일이 얼마나 나가는지 알게 되고, 그중 어느 수치가 두 배가 되면 임계값도 규칙도 없이 곧바로 눈에 들어옵니다. 그래서 보고서는 메일 폴더가 아니라 눈에 들어오는 자리에 두는 편이 좋습니다. 그것이 한 페이지에서 어떤 모습인지는 아래 데모에서.