[명령어] dmesg

# dmesg

: 커널 메세지 확인하여 1) OOME 발생 여부,  2)SYN Flooding 여부

즉, dmesg는 커널에서 발생하는 다양한 메시지(커널 메시지)들을 출력

 

# dmesg -T  // 시간 순 정렬

 

Q. 어떤 메시지를 봐야 할까?

 

1) OOME

● OOME (out of memory error)

: 가용할 메모리가 부족해서 더 이상 프로세스에게 할당해 줄 메모리가 없는 상황 (= 메모리 없다)

=> OOME 상황 발생하면 OOM Killer 동작시킴

 

● OOM Killer: 누군가 가지고 있는 메모리 회수

즉, 메모리 많이 사용하는 프로세스 종료

 

<진행 순서>

1) out of memory error

2) 프로세스 선택

3) 프로세스 종료

4) 시스템 안정화 (서비스 안정화 아님)

 

q. 어떻게 종료시킬 프로세스를 선택할까?

 

● 종료시킬 프로세스 선택 기준 = oom_score

=> oom_score 높은 프로세스 먼저 종료

 

● oom_score 확인 방법

ex)

# cd /proc/2526  // 2526: PID

# cat oom_score

(+) /proc: 프로세스 메타데이터 확인

 

● oome 발생 여부 확인 명령어

# dmesg -TL | grep -i oom

 

[실습] OOME 발생시키기

#include <stdlib.h>

int main(void) {
	void* ptr;
    while (1) {
    	ptr = malloc(1024 * 1024);
        if (ptr == NULL) {
        	break;  
        }
    }
    return 0;
}

 

2) SYN Flooding

● SYN Flooding: 공격자가 대량의 SYN 패킷만 보내서 소켓을 고갈시키는 공격

 

● TCP 3-way Handshake

 

(1) listen()

(2) SYN Backlog

-- X -->

(3) Listen Backlog

(4) accept() -> 애플리케이션

 

(설명) 클라이언트가 최종 ACK를 보내지 않는 경우,

SYN Backlog에 있는 소켓 정보가 넘어가지 않고 계속 쌓임

그 결과, 새로운 소켓 정보 드롭되어 새로운 연결 불가

 

<해결 방안>

● SYN Cookie: SYN 패킷의 정보를 바탕으로 쿠키 만듦, 그리고 그 값을 SYN+ACK의 시퀀스 번호로 만들어서 응답하는 것

쿠키값을 계산하여 타임 스탬프, IP 주소 등 확인 할 수 있음. 따라서 앞에서의 정보를 저장하지 않아도 됨

Listen Backlog를 통해서 바로 애플리케이션에 전달

 

SYN Cookie 동작하면 Listen Backlog에 소켓 정보 쌓지 않음

따라서 자원 고갈 현상 발생하지 않음

하지만 TCP Option 헤더를 무시하기 때문에 Windows Scaling 등 성능 향상을 위한 옵션이 동작하지 않음

 

SYN Flooding 발생하는 것 같을 때 SYN Cookie 동작함

SYN Flooding 공격에 의해 서비스가 불통 되는 것보다는 느려지는 게 나은 선택이 될 수 있음

 

# dmesg -TL | grep -i "syn flooding" 

 

<정리> 

#dmesg 명령어를 통해 OOME 혹은 SYN Flooding 공격 발생 여부 확인

1) OOME  발생 시, 더 많은 메모리 확보

2) SYN Flooding 공격 발생시, 방화벽 확인