023. Linux 서버 보안 — 네트워크 sysctl 하드닝 점검

changseop lee·3일 전

시스템 보안 · 취약점 › A. Linux 서버 보안 설정 · 23/50편 (전체 023/450)
학습 단계: 2단계 · 설정 및 점검
실습 표기: 이 글의 명령어·출력·로그는 로컬 VMware 테스트 VM(Rocky Linux 9 / Ubuntu 22.04) 기준의 「실습 예시」이며, IP·계정·호스트명은 가상의 값입니다.

선행 학습

1. 개념

네트워크 sysctl은 커널이 패킷을 받고, 전달하고, 응답하는 방식을 정합니다. 라우터가 아닌 일반 서버는 "자기에게 온 패킷만 처리하고, 남의 패킷은 전달하지 않는다"가 기본 원칙입니다.

패킷 수신 (ens160)
   ↓
rp_filter      : 출발지 IP가 이 인터페이스로 들어올 수 있는 주소인가? (스푸핑 차단)
accept_redirects: ICMP redirect로 내 라우팅 테이블을 바꿔도 되는가?
accept_source_route: 출발지가 지정한 경로를 따를 것인가?
   ↓
목적지가 나인가? ── 아니오 → ip_forward=1 이면 다른 인터페이스로 전달 (라우터처럼 동작)
   └─ 예 → 처리 (tcp_syncookies: SYN 폭주 시 보호)
log_martians   : 말이 안 되는 출발지 주소(martian) 패킷을 로그로 남김

2. 왜 중요한가

  • ip_forward=1인 일반 서버는 공격자가 내부망으로 들어가는 중계점(피벗) 으로 쓰기 쉽습니다. H영역 「내부 확장 징후」의 핵심 지표 중 하나입니다.
  • ICMP redirect 수용은 중간자 공격(트래픽 우회)에 악용될 수 있습니다.
  • log_martians를 켜 두면 스푸핑·잘못된 라우팅 패킷이 로그로 남아 네트워크 이상을 서버에서도 관찰할 수 있습니다.

3. 핵심 명령어 / 설정

파라미터일반 서버 권장값
net.ipv4.ip_forward0
net.ipv4.conf.all.send_redirects / default.send_redirects0
net.ipv4.conf.all.accept_redirects / default.accept_redirects0
net.ipv4.conf.all.accept_source_route0
net.ipv4.conf.all.rp_filter1(strict) 또는 2(loose, 다중 경로 환경)
net.ipv4.conf.all.log_martians1
net.ipv4.tcp_syncookies1
net.ipv4.icmp_echo_ignore_broadcasts1

컨테이너·VPN·라우터 역할 서버는 ip_forward=1이 정상일 수 있으므로 서버 역할과 함께 판단합니다.

4. 실습 (실습 예시)

# 1) 런타임 값 확인
sysctl net.ipv4.ip_forward net.ipv4.conf.all.accept_redirects net.ipv4.conf.all.send_redirects \
       net.ipv4.conf.all.accept_source_route net.ipv4.conf.all.rp_filter \
       net.ipv4.conf.all.log_martians net.ipv4.tcp_syncookies

# 2) 하드닝 파일
sudo tee /etc/sysctl.d/91-net-hardening.conf <<'EOF'
net.ipv4.ip_forward = 0
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.default.send_redirects = 0
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.default.accept_redirects = 0
net.ipv4.conf.all.accept_source_route = 0
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.all.log_martians = 1
net.ipv4.tcp_syncookies = 1
EOF
sudo sysctl --system >/dev/null

# 3) 포워딩 관련 방화벽 NAT 규칙도 함께 확인
sudo nft list ruleset | grep -iE 'masquerade|dnat|snat'

5. 정상 상태

net.ipv4.ip_forward = 0
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.all.accept_source_route = 0
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.all.log_martians = 1
net.ipv4.tcp_syncookies = 1

웹 서버 역할에서 포워딩이 꺼져 있고 NAT 규칙이 없는 상태가 정상입니다.

6. 이상 상태

$ sysctl net.ipv4.ip_forward
net.ipv4.ip_forward = 1
$ sudo nft list ruleset | grep -i masquerade
		oifname "ens192" masquerade
$ ip -br addr
ens160  UP  192.168.56.10/24
ens192  UP  10.10.20.5/24
  • 웹 서버가 두 네트워크(서비스망 192.168.56.0/24, 내부망 10.10.20.0/24)에 연결되어 있고, 포워딩 + masquerade가 켜짐
  • 외부에서 이 서버를 거쳐 내부망 10.10.20.0/24로 접근 가능한 경로가 생긴 상태 → 내부 확장 징후로 즉시 분석

7. 로그 분석 (분석 방법)

포워딩 활성화와 martian 패킷 로그입니다(가상의 예시 로그).

type=EXECVE msg=audit(1759731000.111:2001): argc=3 a0="sysctl" a1="-w" a2="net.ipv4.ip_forward=1"
type=NETFILTER_CFG msg=audit(1759731005.220:2004): table=nat:5 family=2 entries=1 op=nft_register_rule pid=8401 comm="nft"
Oct  1 13:05:12 rocky9-web01 kernel: IPv4: martian source 10.10.20.30 from 192.168.56.77, on dev ens160
Oct  1 13:05:12 rocky9-web01 kernel: ll header: 00000000: 00 0c 29 aa bb cc 00 0c 29 11 22 33 08 00
시각이벤트의미
13:03:20ip_forward=1라우터 기능 활성화
13:03:25nat 테이블 규칙 추가주소 변환(NAT) 설정
13:05:12martian source서비스망 인터페이스로 내부망 출발지 주소 패킷 유입 → 비정상 라우팅

같은 시간대 네트워크 측 로그에서 이 서버를 경유한 내부망 접속 흔적을 함께 확인합니다(296. Alert와 Firewall Log 연계 참고).

8. SOC 관제 포인트

  • ip_forward 값은 서버 역할별 기대값을 정해 두고 다르면 즉시 확인합니다.
  • sysctl -w ...ip_forward=1과 NAT 규칙 추가가 짧은 간격으로 이어지면 피벗 구성 시도로 판단합니다.
  • martian source 로그가 갑자기 늘면 스푸핑 또는 라우팅 변경을 의심합니다.

9. 탐지 규칙

<group name="local,network_sysctl,">
  <rule id="100290" level="12">
    <if_group>audit</if_group>
    <match>net.ipv4.ip_forward=1</match>
    <description>IP 포워딩 활성화(피벗 구성 가능성)</description>
  </rule>
  <rule id="100291" level="6">
    <match>kernel: IPv4: martian source</match>
    <description>martian 패킷 수신</description>
  </rule>
</group>

/proc/sys/net/ipv4/ip_forward에 직접 쓰는 방식도 있으므로 런타임 값 정기 수집(002편 방식)을 병행합니다.

10. 대응 방법

  1. 초기 확인 — 포워딩 값·NAT 규칙·인터페이스 구성과 변경 시각을 확인합니다.
  2. 범위 확인 — 이 서버를 경유한 내부망 접속을 방화벽·연결 로그(conntrack -L, ss -tn)로 확인합니다.
  3. 증거 확보 — sysctl 값, nft 규칙셋, audit 로그, 연결 목록을 보존합니다.
  4. 차단/조치 — ip_forward=0 복원, NAT 규칙 삭제, 관련 외부 IP 차단을 진행합니다.
  5. 재발 방지 — 역할별 네트워크 sysctl 기대값을 기준선에 넣고 포워딩 활성화 룰을 운영합니다.

11. 핵심 정리

파라미터일반 서버 기대값 / 의미
ip_forward0 / 1이면 피벗 경로 가능
accept_redirects0 / ICMP로 라우팅 변경 차단
rp_filter1 / 출발지 스푸핑 차단
log_martians1 / 비정상 출발지 패킷 기록
면접 포인트"ip_forward=1 + masquerade = 내부 확장 준비 신호"

12. 다음 편 예고

다음 편 024. Linux 서버 보안 — 보안 패치·업데이트 상태 점검 에서는 알려진 취약점을 막는 기본기인 보안 패치·업데이트 상태 점검을 다룹니다.


이전 편: 022. Linux 서버 보안 — 커널 보안 파라미터(sysctl) 하드닝
📚 시리즈 전체 보기: 시스템 보안 · 취약점

profile
코드에 숨겨진 위협을 읽고 AI로 보안의 미래를 설계합니다. 프론트엔드 개발 경험을 자산 삼아 더 견고하고 지능적인 보안 운영 시스템을 구축해 나가는 과정을 기록합니다

0개의 댓글