Syslog
시스로그 · Syslog protocol
는 장비와 프로그램이 이벤트를 공통 형식으로 전달하는 로그 프로토콜 계열이다. 메시지 형식과 ·· 같은 전송 방식은 별도의 선택이며 각각의 전달 보장을 구분해야 한다.
밑줄 용어에 마우스를 올리거나, 키보드로 선택하거나, 터치하면 설명을 볼 수 있습니다.
01무엇이고, 어떤 일을 하나
- 여러 장비의 로그를 중앙 수집 위치로 전달한다.
- ·와 발생 호스트·프로그램 정보를 표현한다.
- 중계기와 큐를 통해 장애 시 수집 흐름을 관리한다.
02어떤 순서로 동작하나
- 발생 내용 구성
송신자가 ·로 를 만들고 시각·호스트·응용 정보와 메시지를 구성한다. 형식은 VERSION과 구조화 데이터 등 필드의 문법을 정한다.
- 전송 경계 부여
선택한 ·· 경로로 전달한다. 는 바이트 스트림이므로 처럼 메시지 경계를 정하는 방식이 필요하며 보안 전송 여부는 별도 구성이다.
- 수신과 중계
수집기나 중계기가 메시지를 받아 필드와 조건에 따라 저장·전달한다. 송신자가 주장한 호스트명, 실제 연결 출처, 발생 시각과 수신 시각을 구분한다.
- 저장과 손실 확인
원문 식별자·큐 상태·최종 검색 결과를 대조한다. 연결 성공이나 송신 성공은 최종 저장 성공과 같지 않고, 자체에는 전달 확인이 없다.
03먼저 알아둘 용어와 구성요소
- ×8+로 계산하는 우선순위 값.
- 메시지의 발생 기능 계열을 나타내는 분류.
- 긴급도 0부터 디버그 7까지의 수준.
- 에서 메시지 앞에 바이트 길이를 붙여 경계를 구분하는 방식.
- VERSION·HEADER··MSG로 구성한 메시지 형식을 정의한 문서.
- 이름과 매개변수 형태로 구조화 정보를 표현하는 영역.
- 인증된 암호화 채널을 제공하며 메시지 문법 자체와는 별도다.
- 메시지 수준의 응답을 제공하는 로그 전달 프로토콜로 기본 와 동일하지 않다.
SSH 인증 로그와 서비스 로그를 사건 단위로 묶기
시간··세션 필드를 따라 로그 줄의 의미를 구분하고 원인을 과장하지 않는다.
실습 구성과 전제
- 로그 파일의 읽기 전용 작업 사본을 사용하고 원본 시각·시간대·해시를 기록한다.
- 서로 다른 가 섞인 출력은 화면 순서만으로 한 사건이라고 합치지 않는다.
인증과 세션의 서로 다른 메시지를 나눈다
- Accepted password는 인증 수락, opened는 세션 시작, closed는 세션 종료의 단서다. -logind의 세션 번호와 sshd PID를 연결해 순서를 좁힌다.
- 로그인 성공이 정당한 사용자였다는 의미는 아니다. 허가된 계정·출발지·시간 범위와 함께 조사한다.
원본 크기로 보기 ↗- sshd의 Accepted password·pam_unix session opened/closed와 logind 메시지가 같이 보인다.
- 각 줄에 PID와 Session 번호가 있어 한 화면 안에서도 서로 다른 세션을 분리할 수 있다.
확인 기준출발지 주소만 같다고 다른 PID의 사건을 하나로 합치지 않는다.
서비스 메시지의 주체를 먼저 확인한다
- 질의· 세션· 정리 작업이 섞인 에서는 프로그램 태그를 먼저 읽는다. grep 문자열 하나로 추출한 출력도 다른 프로그램의 줄을 포함할 수 있다.
- Started·Deactivated successfully는 서비스 수명주기 정보다. 그 자체를 침해나 장애로 분류하지 않는다.
shelljournalctl -u sshd --since '2026-06-01 00:00:00' --until '2026-06-02 00:00:00' --no-pager journalctl -u ssh --since today --no-pager배포판에 따라 서비스 이름은 sshd 또는 ssh다. 날짜는 자신의 시험 범위로 바꾼다.
원본 크기로 보기 ↗- named·systemd·phpsessionclean 메시지가 같은 시간축에 섞여 있다.
- 성공적으로 종료된 작업과 DNS 질의를 구분할 수 있다. 서로 인접한 줄이라는 이유만으로 인과관계를 만들면 안 된다.
확인 기준서비스별 시간 범위로 다시 조회해 앞선 오류와 후속 상태를 확인한다.
관찰 사실과 가설을 분리한다
- 보고서에는 '인증 수락 기록이 있다'와 '계정 탈취가 의심된다'를 구분해 쓴다. 후자는 계정 소유자 확인·접근 대상·후속 증거를 더 요구한다.
- 시각이 어긋나면 시간대와 시간 동기화 상태를 먼저 확인하고 원본 로그는 수정하지 않는다.
확인 기준한 문장마다 뒷받침하는 로그와 아직 확인되지 않은 조건을 남긴다.
실습에서 확인한 동작 원리
- 로그의 프로그램·PID·세션이 사건 묶음의 기준이다.
- 성공 메시지는 정상 사용자라는 보증이 아니며 종료 메시지는 공격 증거가 아니다.
TCP 수신 설정과 수집된 웹 로그를 한 경로로 읽기
수신 포트, 머리말, 웹 서버의 원래 메시지를 구분하여 전달 실패와 애플리케이션 오류를 가려낸다.
실습 구성과 전제
- 격리 실습망의 송신기와 수신기에서 시간대·호스트 이름·전송 포트를 기록한다.
- 이 실습의 514/ 예시는 평문 수신이다. 를 적용하려면 인증서와 스트림 드라이버 등 별도 설정이 필요하다.
수신 모듈과 소켓이 같은 조건인지 확인하기
- imtcp 모듈은 연결에서 메시지를 받는 입력 모듈이다. 모듈을 불러오는 행과 실제 514번 포트를 여는 input 행이 모두 있어야 의도한 수신 구성이 된다.
- 설정 파일이 존재하는 것, 문법 검사가 통과하는 것, 현재 가 포트를 열고 있는 것은 별개다. 문법 검사 뒤 실제 LISTEN 소켓과 방화벽 경로를 확인한다.
bashrsyslogd -N1 ss -lntp현재 설정의 문법과 수신 소켓을 조회한다. 설정 검사만으로 서비스가 재시작되지는 않는다.
원본 크기로 보기 ↗- module(load="imtcp")와 input(type="imtcp" port="514")가 함께 보인다. 입력 모듈과 수신 포트가 각각 지정되어 있다.
- 이 부분에는 TLS 인증서나 암호화 모드 지정이 보이지 않는다. TCP라는 이유만으로 암호화 전송이라고 할 수 없다.
확인 기준설정 검사 결과와 514/ LISTEN이 일치해야 수신 준비가 됐다고 판단한다.
고유 표식 한 건을 보내 저장 경로를 찾기
- 다른 이벤트와 구별되는 lab-event-001 같은 표식을 보내고, 송신 시각·수신 시각·저장 파일에서 같은 문자열을 찾는다. 재전송 시험에서는 같은 이벤트의 중복 저장 여부도 센다.
- 수신 파일의 머리말 뒤에는 원래 애플리케이션 메시지가 그대로 들어갈 수 있다. 외부 호스트명과 내부 시간 문자열은 서로 다른 필드이므로 하나의 으로 무리하게 합치지 않는다.
bashlogger --tcp --server 127.0.0.1 --port 514 --tag lab-source 'lab-event-001'수신기 자체의 로컬 입력 확인 예. 원격 경로 시험은 자신이 관리하는 수신기 주소로 바꿔 별도로 진행한다.
원본 크기로 보기 ↗- 각 행의 앞에는 Jun 9 시각, localhost, httpd-access가 있고 그 뒤에 대괄호로 감싼 Apache 요청 시각이 다시 나타난다.
- 같은 수집 파일에서 GET 요청의 상태 코드 500과 정적 파일 요청의 304가 함께 보인다. 수집 파일에 기록됐다는 사실과 웹 요청 성공 여부는 별도다.
확인 기준표식이 없으면 송신→포트→ruleset→action→파일 권한 순으로 좁힌다. 웹 500을 전송 실패로 분류하지 않는다.
Severity와 웹 상태 코드의 의미를 분리하기
- 는 0이 가장 긴급하고 7이 디버그인 메시지 분류다. HTTP 500의 숫자와 같은 척도가 아니며, 전달된 메시지 내용만 보고 를 임의로 바꾸면 안 된다.
- 필터가 범위를 제한하면 전달은 됐어도 선택한 저장 action에는 남지 않을 수 있다. 수신 원본과 최종 파일에서 표식을 비교하여 필터에 의한 누락인지 판단한다.
원본 크기로 보기 ↗- 표에는 emerg 0부터 debug 7까지 여덟 단계가 나온다. 숫자가 커질수록 더 긴급해지는 구조가 아니다.
- notice는 5, info는 6으로 별도 행이다. 정상 동작 중에도 주목할 사건과 일반 정보 메시지를 나누어 분류할 수 있다.
확인 기준내용의 HTTP 상태 코드, , 최종 저장 action을 각각 기록하면 누락과 애플리케이션 장애를 혼동하지 않는다.
실습에서 확인한 동작 원리
- 연결 성립과 로그 파일 저장 사이에는 입력·필터·action·파일 권한 단계가 있다.
- 머리말과 원래 메시지를 함께 보존하면 전송 경로와 애플리케이션 사건을 나중에 다시 해석할 수 있다.
04예제로 따라가기
- 대상 메시지: ASCII 메시지 <134>1 - h a - - - ok를 사용한다. 문자들이 모두 1바이트이므로 전체 -MSG 길이는 21바이트다.
- 프레임 생성: 길이 방식의 전송 표현은 21 뒤 공백과 21바이트 메시지다. 길이 숫자와 공백은 -MSG 길이에 포함하지 않는다.
- 부분 수신: 첫 recv에 21 과 메시지 앞부분만 오면 수집기는 완료로 처리하지 않고 남은 바이트 수를 유지한다.
- 완료 판정: 메시지 21바이트가 모두 모이면 한 레코드를 전달한다. 같은 recv에 다음 프레임이 붙어 있으면 남은 버퍼에서 다음 길이를 읽는다.
- 다중 바이트: MSG의 ok를 한글 가로 바꾸면 2바이트 대신 3바이트가 들어간다. 같은 글자 수 변화로 계산하지 않고 전체 바이트 길이를 다시 구한다.
05혼동하기 쉬운 점과 확인 기준
- 프레이밍 불일치: 송신기의 과 수신기의 줄바꿈 방식을 먼저 비교한다. 성공은 애플리케이션 메시지 경계 일치까지 보장하지 않는다.
- 길이 계산: 인코딩 전 문자 수로 길이를 작성했는지 본다. ASCII 로그는 통과하고 한글 로그만 깨지는 패턴은 중요한 단서다.
- 큐와 저장: 입력 수신·ruleset 전달·action queue·파일 저장을 나누어 본다. 연결 상태만으로 최종 파일 적재를 판정하지 않는다.
06상세 노트 · 실습 자료
헤더 구조, 설정 예시, 수치 계산과 수업 캡처는 아래 노트에서 이어집니다.
함께 보는 학습 자료
아래 공식 자료를 본문의 개념·예제와 함께 읽어 보세요. 자료별로 확인할 위치와 관찰할 내용을 적었습니다.
RFC 6587: TCP Syslog 메시지 경계
MSG-LEN SP -MSG 구조를 읽어 한 번의 수신과 한 건이 같지 않은 이유를 설명한다.
- MSG-LEN은 문자 수가 아닌 octet 수
- 길이 숫자와 구분 공백을 세는 범위
- 줄바꿈 구분 방식이 본문 개행과 충돌하는 경우
공식 문서 · 표준
기초 개념과 동작 설명을 대조한 자료입니다. 제품 버전과 실제 설정에 따른 차이는 본문 및 원문에서 확인하세요.