리눅스 커널 로그에서 SYN 반복 유입 확인과 대응

리눅스 커널 로그에서 SYN 반복 유입 확인과 대응 절차

커널 로그에 특정 포트로 TCP SYN 패킷이 짧은 시간에 반복 기록되는 경우는 흔히 포트 스캔, 오탐(정상 헬스체크/클라이언트 재시도), 또는 SYN Flood 성격의 비정상 트래픽으로 나뉩니다.
실제 사용 시에는 “차단했나/허용했나”보다 먼저, 해당 포트의 서비스 노출 여부와 연결 성립(3-way handshake) 여부를 구분해서 보는 게 핵심입니다.

• 핵심 포인트: SYN 반복 = 공격 단정 금지
• 우선순위: 노출 여부 → 연결 성립 여부 → 발생 원인
• 대응: 증상 완화(레이트리밋/차단) + 근본 원인(노출/라우팅/정책)

※ 요청에 따라 IP/포트/MAC 등 식별값은 예시로 대체했습니다.

개요

아래 로그는 리눅스 커널(방화벽 로깅 규칙)에서 특정 인터페이스로 유입되는 TCP 패킷을 기록한 형태입니다. 로그 문자열에 SYN 플래그가 포함되어 있고, 목적지 포트(DPT)로 동일/유사 값이 반복되어 나타납니다.

운영 환경에서는
“SYN이 많다”는 사실만으로 장애/침해를 확정하지 않고,
① 외부에 노출된 포트인지,
② 실제 서비스 프로세스가 리스닝 중인지,
③ SYN-ACK까지 나가는지(연결 성립되는지),
④ 특정 출발지에 편중되는지
순서로 확인하는 것이 안전합니다.

환경

대상 시스템(예시)

• OS: Linux (커널 로그 출력)
• 네트워크 인터페이스: enpXsY (예: enp4s0f0)
• 방화벽: iptables 또는 nftables 기반 로깅 규칙(커널 로그 프리픽스 포함)
• 로그 수집: syslog/journald 등

로그 특징(예시)

• 프리픽스: SYNAP_9000_TCPIN=... (정책/룰명)
• 플래그: SYN 표시
• 목적지 포트: DPT=9000 반복
• 출발지 포트: SPT 값이 매번 달라짐(일반적인 클라이언트 에페머럴 포트)

증상

대표 증상은 다음 중 하나 또는 복합으로 나타납니다.

• 커널 로그에 동일 목적지 포트로 SYN 유입이 다수 기록됨
• 특정 출발지 IP에서만 반복되거나, 다수 IP로 분산되어 들어옴
• 서비스 포트가 외부에 노출되어 있다면 접속 실패/지연/세션 고갈 징후가 동반될 수 있음

로그 예시(식별값 대체)

Apr 15 09:55:25 host kernel: SYNAP_9000_TCPIN=eth0 OUT= MAC=xx:xx:xx:xx:xx:xx SRC=10.0.0.10 DST=192.0.2.20 LEN=52 TOS=0x00 PREC=0x00 TTL=126 ID=20635 DF PROTO=TCP SPT=50084 DPT=9000 WINDOW=65535 RES=0x00 SYN URGP=0
Apr 15 09:55:25 host kernel: SYNAP_9000_TCPIN=eth0 OUT= MAC=xx:xx:xx:xx:xx:xx SRC=10.0.0.10 DST=192.0.2.20 LEN=52 TOS=0x00 PREC=0x00 TTL=126 ID=20636 DF PROTO=TCP SPT=18499 DPT=9000 WINDOW=65535 RES=0x00 SYN URGP=0
Apr 15 09:56:29 host kernel: SYNAP_9000_TCPIN=eth0 OUT= MAC=xx:xx:xx:xx:xx:xx SRC=10.0.0.10 DST=192.0.2.20 LEN=52 TOS=0x00 PREC=0x00 TTL=126 ID=40511 DF PROTO=TCP SPT=33564 DPT=9000 WINDOW=65535 RES=0x00 SYN URGP=0

해석 포인트
SPT가 계속 바뀌는 것은 “클라이언트가 여러 번 시도”하거나 “스캔 도구가 포트를 두드리는” 상황에서 흔합니다.
반면 SRC가 다수로 바뀌며 동시에 들어오고, 서버가 응답하느라 자원이 급격히 증가한다면 SYN Flood 성격을 의심할 여지가 커집니다.

1차 점검

1차 점검은 “지금 당장 위험/장애가 진행 중인지”를 빠르게 가르는 단계입니다.

1) 해당 포트가 실제로 열려 있는지

• 서버에서 프로세스 리스닝 여부 확인(예: ss -lntp, lsof -i)
• 로드밸런서/방화벽/보안장비 정책에서 외부 노출 여부 확인

2) 연결이 성립되는지(3-way handshake)

• SYN만 들어오고 SYN-ACK/ACK가 이어지지 않으면 스캔/오탐/차단 상황 가능성
• 연결 성립이 늘어나며 SYN_RECV가 급증하면 리스크가 커짐

3) 트래픽 편중 여부

• 특정 SRC 단일 IP에 편중: 내부 시스템의 재시도/오류 클라이언트/특정 스캐너 가능
• 다수 SRC 분산: 대규모 스캔 또는 분산 공격 가능

심화 분석

1차 점검에서 “단순 로그 증가”를 넘어 원인을 좁히는 단계입니다.

1) 로그 프리픽스(룰명) 기준으로 정책 확인

• SYNAP_9000_TCPIN 같은 프리픽스는 보통 iptables/nftables 룰에 지정된 로그 태그입니다.
• 해당 룰이 “허용 전 로깅”인지, “차단 전 로깅”인지에 따라 해석이 달라집니다.

2) 패킷 캡처로 실제 흐름 확인

• SYN 유입이 실제로 얼마나 되는지, 서버가 SYN-ACK을 내보내는지 확인
• TTL/옵션/윈도우 크기 패턴이 일정하면 자동화 도구 트래픽일 수 있음

3) 서비스 관점 원인 후보 정리

• 정상 트래픽(헬스체크/모니터링/배치)이 실패하여 재시도 루프에 빠진 경우
• 외부 노출된 관리 포트/테스트 포트가 스캔 대상이 된 경우
• 보안장비/라우팅 변경 직후 우회 경로로 유입이 증가한 경우

관리자 입장에서
“이 포트가 왜 인터넷/사내에서 접근 가능한 상태인가?”가 가장 큰 비용 절감 포인트입니다.
불필요 포트 노출을 제거하면, 방어/탐지/장애 대응 비용이 함께 내려갑니다.

복구

복구는 “즉시 완화”와 “구조적 해결”을 나눠서 진행하는 것이 안정적입니다.

즉시 완화(단기)

• 단일 출발지 편중이면 해당 대역 임시 차단(운영 영향 고려)
• 레이트 리밋 적용(동일 포트/동일 출발지 기준)
• 불필요 로그 폭주 방지(로깅 레벨/샘플링/제한 적용)

구조적 해결(중기)

• 해당 포트를 외부에서 접근할 필요가 없다면 접근 경로 자체를 제거(ACL/보안그룹/방화벽 정책)
• 관리/내부용 포트는 VPN/점프호스트/사내망으로만 제한
• 서비스가 필요하다면 WAF/L4 정책, 커널 튜닝(SYN backlog, syncookies) 등 방어 레이어 보강

재발 방지

• 노출 포트 정기 점검: 자산 기준으로 “열려 있는 포트 목록”을 주기적으로 비교
• 로그 기준 알림: 특정 프리픽스/포트 기준으로 단위 시간당 임계치 알림 설정
• 정상 트래픽 화이트리스트: 헬스체크/모니터링 출발지 대역을 관리하고 변경 이력 추적
• 변경관리: 라우팅/방화벽 정책 변경 시, 예상 유입 포트/대역을 사전에 검증

요약
SYN 반복 유입은 “현상”이고, 원인은 스캔/오탐/공격/정상 재시도까지 폭이 넓습니다.
실무 기준으로 보면, 포트 노출 여부와 연결 성립 여부를 먼저 가르면 대응이 훨씬 빨라집니다.