2025년 6월 5일 목요일

conntrack 세션을 이용한 iptables 최적화 및 관련 버그

 iptables 정책 적용 후에도 기존 세션이 남아 hit count를 업데이트 하고 있는 이슈를 맡게된 계기로

상태를 가진 세션 기반 방화벽처리에 대해 조사해보았다.


장애 대응 개요

1. iptables rule sequence 수정 후에도 수정 전 정책으로 패킷 카운팅 되고 있음을 확인

2. 해당 호스트는 PC ↔ eth0 (UTM) ↔ eth1 (UTM) ↔ 인터넷 의 구조로 PC 에 대한 라우터 역할을 수행하고 있었음

3. reply 패킷의 경우 원래  PREROUTING hook을 안타지만 인터넷 → PC 에 대한 reply 패킷은 PREROUTING → FORWARD → POSTROUTING hook을 타고 처리됨

4. rule 적용은 PREROUTING hook의 mangle table에서 orig 패킷만  적용됨

5. reply 패킷은 conntrack rule 에 의해 기존 conntrack table의 세션 마크를 재사용하도록 되어있음

5. rule 수정 후 reply 패킷이 PREROUTING hook을 탈 경우 수정한 rule 이 반영되지 않고 conntrack table의 세션 마크에 의해 수정전의 룰이 반영됨


재현 절차

다음 그림과 같이 모델링된 production 구성에서 정책 수정시 수정 전 정책으로 패킷 카운팅되는 문제가 발생했다.


먼저 정책 2개를 추가하고 icmp ping을 흘려보았다.

*mangle
-A PREROUTING -m fivetuple --msrc 100.1.1.0/24 -j MARK --set-mark 0x321002
-A PREROUTING -m fivetuple --msrc 100.1.1.0/24 -j MARK --set-mark 0x1e1001

30, 50 룰 icmp traffic

iptables -t mangle -L -vn
Chain PREROUTING (policy ACCEPT 8108 packets, 579K bytes)
 pkts bytes target     prot opt in     out     source               destination
            193 21954 CONNMARK   all  --  *      *       0.0.0.0/0            0.0.0.0/0           connmark match !0x0/0xffffffffffffffff CONNMARK restore
             49 11461 RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0           reply
            144 10493 RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0           connmark match 0x1/0x1
            165 11026 MARK       all  --  *      *       0.0.0.0/0            0.0.0.0/0           MARK set 0xfde80001
            105  7261 MARK       all  --  *      *       0.0.0.0/0            0.0.0.0/0           --msrc 192.168.1.0/24 MARK set 0x321002
            105  7261 MARK       all  --  *      *       0.0.0.0/0            0.0.0.0/0           --msrc 192.168.1.0/24 MARK set 0x1e1001
            105  7261 MARK       all  --  *      *       0.0.0.0/0            0.0.0.0/0           --msrc 192.168.1.0/24 MARK or 0xa000000000000
              0     0 MARK       icmp --  *      *       0.0.0.0/0            0.0.0.0/0           icmp type 13 MARK set 0x0
            165 11026 CONNMARK   all  --  *      *       0.0.0.0/0            0.0.0.0/0           CONNMARK save mask 0xffffffffffffffff


30 → 20, 50 → 30 룰 수정 후 traffic test (이 경우 우선순위가 낮은 30번 룰이 카운팅 되는 문제였다.)

iptables -t mangle -L -vn
Chain PREROUTING (policy ACCEPT 15377 packets, 1077K bytes)
 pkts bytes target     prot opt in     out     source               destination
            228 16008 CONNMARK   all  --  *      *       0.0.0.0/0            0.0.0.0/0           connmark match !0x0/0xffffffffffffffff CONNMARK restore
             16  1261 RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0           reply
            212 14747 RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0           connmark match 0x1/0x1
             77  4192 MARK       all  --  *      *       0.0.0.0/0            0.0.0.0/0           MARK set 0xfde80001
              5   323 MARK       all  --  *      *       0.0.0.0/0            0.0.0.0/0           --msrc 192.168.1.0/24 MARK set 0x1e1002
              5   323 MARK       all  --  *      *       0.0.0.0/0            0.0.0.0/0           --msrc 192.168.1.0/24 MARK set 0x141001
              5   323 MARK       all  --  *      *       0.0.0.0/0            0.0.0.0/0           --msrc 192.168.1.0/24 MARK or 0xa000000000000
              0     0 MARK       icmp --  *      *       0.0.0.0/0            0.0.0.0/0           icmp type 13 MARK set 0x0
             77  4192 CONNMARK   all  --  *      *       0.0.0.0/0            0.0.0.0/0           CONNMARK save mask 0xffffffffffffffff


룰을 수정하지 않아도 iptables 의 후순위 룰의 패킷수는 카운팅이 되었다.

mangle tables 에서는 access/drop/reject 에 대한 마킹만하고 실제 정책을 확인하여 패킷에 대한 drop 판단을 하는 곳은 filter tables이다. 그렇기 때문에 iptables의 결과는 문제가 없었다.

UTM 장비에서 packet counting 로직은 filter tables 에서 last time 을 업데이트하면 패킷 카운팅 결과를 출력하는 로직으로 구성되어있었다.


조사내역

1. 룰이 netfilter hook을 타고 이동하면서 정책이 적용되고 카운팅되는 로직 분석

2. 상태를 가진 세션의 경우 룰 변경 시 어떻게 상태를 유지하며 룰이 반영되는지



룰이 netfilter hook을 타고 이동하면서 정책이 적용되고 카운팅되는 로직 분석

iptables 의 경우 순차적으로 매칭하여 룰 개수 증가 시 성능이 급격하게 저하되는데 사내 UTM 장비의 경우 iptables-tng 코드를 패치하여 tuple 기반으로 hash table을 활용한 classify 기능을 추가하여 룰 개수가 많아져도 일정한 CPS를 유지하도록 하도록 개발되어있었다.

관련 개발 사항과 룰 적용 시 패킷이 netfilter hook에서 어떻게 처리되는지 분석해보았다.



상태를 가진 세션의 경우 룰 변경 시 어떻게 상태를 유지하며 룰이 반영되는지



댓글 없음:

댓글 쓰기

vrrp 장비 failover 시 sync 패킷 전송 중 panic 발생 오류

  vrrp 구성 (Active-Standby or Active-Active) 시 UTM 장비 failover 시 sync 패킷 전송 중 panic 발생하는 문제가 있었다. 외부 고객사에서 발생한 문제라 내부 재현은 불가능하여 코드 분석 레벨에서 se...