[Linux] dmesg - 리눅스 커널 로그 메세지 확인하기 (OOME, SYN Flooding)

해당 포스팅은 인프런 "리눅스 성능 분석 시작하기" 를 수강하고 정리한 글입니다 :)

• 리눅스 기반 os 에서 돌아가는 서버 시스템의 성능 측정 및 장애 대응에 대한 학습 내용 정리 글 입니다.

 

💡 리눅스 성능 분석의 기본 명령어

명령어	역할
uptime	시스템 가동 시간, Load Average 확인
dmesg	커널 메세지 확인 (OOME 발생 여부, SYN Flooding 여부)
free	메모리 사용 현황 확인
df	디스크 여유 공간 및 inode 공간 확인
top	프로세스들의 상태, CPU 사용률, 메모리 사용률 확인
netstat	네트워크 연결 정보 확인
tcpdump	네트워크 트러블 슈팅 분석을 위한 패킷 수집 명령어

 

 

 

---

✅ dmesg 명령어

• dmesg는 커널에서 발생하는 다양한 메시지들을 출력하는 명령어 입니다.
• 리눅스 커널이란 (Kernel), 리눅스 운영체제(OS)의 주요 구성 요소이자 컴퓨터 하드웨어와 프로세스를 잇는 핵심 인터페이스로 시스템의 모든 것을 완전히 제어하는 프로그램입니다.
• 커널도 하나의 소프트웨어이기 때문에, 커널의 요러 요소들에서 나오는 메세지들을 dmesg 명령어로 꺼내서 볼수 있습니다.

 

dmesg -T (T옵션은 타임스탬프를 보기좋게 바꿔주는 옵션)

dmesg -T

 

---

❓ dmesg 출력문 중 무엇을 봐야할까?

→ 성능분석과, 트러블 슈팅의 관점에서 봐야할 2가지

1. OOME (Out-Of-Memory Error) 메세지
2. SYN Flooding

---

👏🏻 1. OOME 란

• 가용한 메모리가 부족해서 더이상 프로세스에게 할당해 줄 메모리가 없는 상황 (메모리가 없다.)
• OOME 상황이 오면 커널에서는 OOM Killer 를 동작 시킵니다.
• OOM Killer가 동작과정
  1. 메모리가 꽉차서 프로세스에 할당할 수 없는 상황이기 때문에
  2. 다른 프로세스를 종료(kill)해 메모리 자원을 커널에게 돌려주어서
  3. → 다른 프로세스에게 할당한다.

 

✔️ 커널의 관점에서 OOME 상황 해결 과정

1. OOM 상황 발생
2. 프로세스 선택(kill 할)
3. 프로세스 종료
4. 시스템 안정화 (서비스가 안정되는게 아닌, 메모리를 확보에서 시스템을 안정시킴)

 

✔️ 커널은 어떻게 종료 시킬 프로세스를 선택할까❓

1) oom_score 란

• OOM Killer가 종료시킬 프로세스를 선택하는 기준
• 스코어가 높은 프로세스가 더 먼저 종료됩니다.

 

2) oom score 확인 방법

cd /proc/2526
cat oom_score

• proc : 프로세스들의 메타데이터를 볼 수 있는 폴더
• 2526 : 확인할 프로세스 번호

→ 해당 폴더로 들어가 "cat oom_score" 명령어로 확인한 666 점이 oom_score 입니다.
→ grep 2526 으로 들어가 확인한 프로세스들 -bash : 단순 쉘 스크립트 파일 입니다.
→ OOM Killer 가 발생하면 쉘스크립트 종료! 메모리 확보!

 

✔️ dmesg OOME 확인 방법

• dmesg -T | grep -i oom
• oom 이 떴던 시간과 커널 메세지를 잡아서 확인할 수 있다

 

---

 

👏🏻 2. SYN Flooding 이란

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

 

✔️ SYN Flooding 이 일어나는 과정

TCP 3-way handshake (연결을 맺기 위한 과정)

1. 처음 Client 에서 SYN 요청을 보내 - 연결 요청 신호를 보냅니다.
2. Server 에서 SYN 요청을 보내면 SYN + ACK 를 보내 연결을 허가하고
3. 다시 Client 에서 ACK 를 보내 establish 가 됩니다. (연결)

TCP 3-way handshake 시 커널에서 일어나는 일

1. listen( ) : system call로 소켓이 열림
2. SYN Backlog : SYN 패킷을 받았을 때 SYN Backlog 에 SYN 패킷을 저장 시킴
3. Listen Backlog : ACK 를 받았을 떄 SYN Backlog 에 저장 SYN 패킷을 → Listen Backlog 로 옮김
4. accept() : accept() System Call 을 통해 실제 어플리케이션에게 통신의 처리권을 위임 → HTTP 등등 연결 시작

↓

 

악의적인 사용자가 SYN 패킷만을 계속 보낼때

• SYN Backlog의 허용 용량이 가득차고 (Listen Backlog 로 가지 않아서)
• 신규로 들어오는 요청인 SYN 패킷을 받지못해 연결을 하지 못하는 상황이 발생한다.

SYN Flooding

 

✔️SYN Cookie

• SYN Flooding 을 대비해 리눅스 커널에는 SYN Cookie 가 존재합니다.
• SYN Cookie 란 SYN 패킷 정보들을 바탕으로 쿠키를 만들어 SYN + ACK 의 시퀀스 번호로 만들어 응답합니다.
• 따라서 SYN Backlog에 저장하지않고 Cookie값으로 계산(IP 주소 등의 정보가 담김) 하여 요청 연결을 확인합니다.

→ SYN Cookie 가 동작하면 SYN Backlog 에 SYN 패킷을 쌓지 않기때문에, 자원 고갈 현상이 발생하지 않습니다.
→ 하지만 TCP Option 헤더를 무시하기 때문에, Windows Scalling 같은 성능 향샹 옵션이 동작하지 않습니다.

 

✔️ dmesg SYN Flooding 확인 방법

• dmesg -T | grep -i "syn flooding"
• 요즘은 SYN Flooding 공격이 잘 발생하지 않지만 그래도 dmesg 를 통해 확인할 수 있다!

 

---

📌정리

• ✔️ dmesg 명령어를 통해 커널 환경에서 OOME 에러 혹은 SYN Flodding 공격 발생등의 메세지들을 확인할 수 있습니다.
• ✔️ OOME 에러라면 메모리 누수를 확인하거나 추가 메모리를 확보하여 성능을 향상시킬 수 있습니다.
• ✔️ SYN Flooding 공격이 발생했다면 방화벽을 확인하여 사전에 차단하거나, SYN Cookie를 사용하여 서비스는 정상적으로 작동되도록 유지할 수 있습니다.