인증 로그는 로그인 시도, 권한 변경 및 세션 활동을 설명하는 데 도움이 됩니다. 보안에 민감한 증거지만 한 줄만으로 사용자의 의도를 확정하거나 계정 침해를 입증할 수 있는 경우는 드뭅니다.
로깅 · 레슨 5
인증 로깅
리눅스 인증 레코드를 찾고 해석하며 안전하게 연관 지어 분석하는 방법을 알아봅니다.
인증 레코드 찾기
Debian 계열 syslog 설정은 보통 인증 이벤트를 /var/log/auth.log로 라우팅하고, Red Hat 계열 설정은 흔히 /var/log/secure를 사용합니다. systemd 저널은 같은 이벤트를 유닛 및 프로세스 메타데이터와 함께 보존할 수 있으며, 중앙 로깅 시스템이 권위 있는 사본을 보관할 수도 있습니다.
로컬 대상을 찾고 관련 서비스를 조회합니다.
$ sudo journalctl -u ssh.service --since '1 hour ago'
$ sudo less /var/log/auth.log
SSH 유닛 이름은 ssh.service 또는 sshd.service일 수 있습니다. 이러한 레코드에는 계정과 접근 세부 정보가 드러나므로 일반적으로 권한으로 접근을 제한합니다.
리눅스 인증 이벤트는 항상 어디에 저장되어야 합니까?
이벤트 해석하기
전통적인 레코드는 다음과 같은 내용을 담을 수 있습니다.
Jan 31 10:37:50 icebox pkexec: pam_unix(polkit-1:session): session opened for user root by (uid=1000)
이 레코드는 시간, 호스트, 이벤트를 내보낸 프로그램, PAM 모듈과 서비스, 요청한 세션 사용자 및 출발 UID를 식별합니다. 이것만으로 UID 1000 뒤의 실제 사람을 식별하거나 악의적인 작업임을 입증할 수는 없습니다. 사고 당시 유효했던 계정 레코드에서 UID를 확인하고 터미널, 원격 주소, 세션 및 주변 이벤트와 연관 지어 분석합니다.
이 레코드에서 uid=1000이 확립하는 사실은 무엇입니까?
성공과 실패 조사하기
제한된 시간 범위에서 허용된 시도와 거부된 시도를 모두 검색합니다. SSH에서는 연결 소스, 인증 방식, 대상 계정, 세션 열기와 닫기 및 서비스 재시작도 조사합니다. 반복되는 실패는 사용자 실수, 오래된 자격 증명을 사용하는 자동화, 스캔 또는 공격일 수 있으며 빈도만으로 하나의 원인을 선택할 수 없습니다.
last와 lastb는 유지되고 있는 wtmp 및 btmp 레코드를 요약할 수 있지만, 이 바이너리 데이터베이스에도 자체 보존 및 무결성 한계가 있습니다. 저널 또는 syslog 레코드 및 중앙 소스와 교차 확인하십시오.
반복되는 로그인 실패는 어떤 정보와 연관 지어야 합니까?
증거 보존 및 대응
사고가 의심되면 호스트 시간과 시간대를 기록하고 원본 로그와 메타데이터를 보존하며 내보낸 사본을 보호합니다. 증거를 원본에서 직접 편집하지 마십시오. 계정 잠금, 방화벽 변경 및 세션 종료는 정상적인 접근을 중단하거나 공격자에게 대응 사실을 알릴 수 있으므로 사고 대응 절차를 따르고 복구 경로를 유지합니다.
조사 중 인증 증거는 어떻게 다뤄야 합니까?
레슨 완료
인증 로깅 완료
이제 하나의 레코드가 입증하는 범위를 과장하지 않고 인증 이벤트를 조사할 수 있습니다.
로컬에 설정된 인증 로그 대상을 찾습니다.
맥락 속에서 신원, 서비스, 방식 및 세션 필드를 해석합니다.
보존된 여러 소스에서 실패 및 성공 활동을 연관 지어 분석합니다.
증거를 보존하고 운영에 영향을 주는 대응 작업을 조율합니다.