이 아웃바운드 iptables 방화벽에 어떤 문제가 있나요?

2024-7-9 • tag-icon

사용하는 다양한 포트에서 아웃바운드 연결만 허용하여 보안을 유지하려는 메일 서버가 있습니다. 인바운드 규칙이 제대로 작동하고 있으며 VM 호스트에서 처리됩니다.

나는 이것에 대해 많은 것을 알 수 없었고 아래 스크립트는 거의 작동하지만 패킷을 삭제하고 있습니다. 예를 들어 포트 993의 경우:

Mar 25 16:08:11 lorina kernel: [200590.714226] IPTables-Dropped: IN= OUT=ens18 SRC=[local IP here] DST=[remote IP here] LEN=148 TOS=0x00 PREC=0x00 TTL=64 ID=37253 DF PROTO=TCP SPT=993 DPT=14826 WINDOW=243 RES=0x00 ACK PSH FIN URGP=0

스크립트는 다음과 같습니다. ens19는 LAN 인터페이스(열어두고 싶습니다)이고 ens18은 WAN입니다.

iptables -A OUTPUT -o lo -p all -j ACCEPT
iptables -A OUTPUT -o ens19 -p all -j ACCEPT
iptables -A OUTPUT -p icmp -j ACCEPT
iptables -A OUTPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -p tcp --dport 53 -j ACCEPT
iptables -A OUTPUT -p udp --dport 53 -j ACCEPT
iptables -A OUTPUT -p udp -m owner --uid-owner systemd-timesync -j ACCEPT

ip6tables -A OUTPUT -o lo -p all -j ACCEPT
ip6tables -A OUTPUT -p icmpv6 -j ACCEPT
ip6tables -A OUTPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
ip6tables -A OUTPUT -p tcp --dport 53 -j ACCEPT
ip6tables -A OUTPUT -p udp --dport 53 -j ACCEPT
ip6tables -A OUTPUT -p udp -m owner --uid-owner systemd-timesync -j ACCEPT

while read h; do
        ip6tables -A OUTPUT -m conntrack --ctstate NEW -d $h -j ACCEPT &> /dev/null
        iptables -A OUTPUT -m conntrack --ctstate NEW -d $h -j ACCEPT
done < /usr/local/etc/hosts-to-allow.list

while read p; do
        ip6tables -A OUTPUT -m conntrack --ctstate NEW -p tcp --dport $p -j ACCEPT
        iptables -A OUTPUT -m conntrack --ctstate NEW -p tcp --dport $p -j ACCEPT
done < /usr/local/etc/ports-to-allow.list

ip6tables -A OUTPUT -o ens18 -j LOGGING
ip6tables -A LOGGING -m limit --limit 2/min -j LOG --log-prefix "IPTables-Dropped: " --log-level 4
iptables -A OUTPUT -o ens18 -j LOGGING
iptables -A LOGGING -m limit --limit 2/min -j LOG --log-prefix "IPTables-Dropped: " --log-level 4

iptables -A OUTPUT -o ens18 -j REJECT
ip6tables -A OUTPUT -o ens18 -j REJECT

흥미로운 각주

이러한 규칙으로 인해 삭제된 패킷은 정상일 수 있으며 여전히 가끔 표시됩니다. Ubuntu 지원 포럼에서 Doug S라는 사용자가 이에 대한 설명을 제공했습니다.

귀하의 로그 줄 예는 "NEW"가 아닌 패킷에 대한 것입니다. 줄 끝에 있는 TCP 플래그를 보면 알 수 있습니다.

내 추측으로는 이것이 이미 닫혀 잊혀진 TCP 세션에서 느린 패킷인 것 같습니다. 그렇지 않으면 RELATED,ESTABLISHED 경로를 통과했을 것입니다.

이는 라우터 및/또는 패킷 이동의 다른 항목에 따라 iptables에서 많이 발생합니다. 왜? TCP 연결의 경우 Linux는 세션의 어느 쪽이든 단일 양방향 FIN-ACK 핸드셰이크(연결을 CLOSE_WAIT 상태로 설정)를 통해 연결 종료를 시작할 수 있는 "반이중" 닫기 시퀀스를 사용하는 경향이 있습니다. 완전한 4방향 FIN-ACK 핸드셰이크.

무슨 일이 일어나고 있는지 확인하려면 항상 플래그를 관찰하세요. 내 생각엔 당신이 괜찮은 것 같아요

지금까지 오늘의 /var/log/syslog 파일에는 "RES=0x00 ACK FIN URGP=0"으로 끝나는 115개의 항목이 있으며 그 중 93개는 내 LAN에서 온 것입니다.

답변1

귀하의 ports-to-allow.list에 포트 993이 포함되어 있는 것 같습니다. 이것이 바로 귀하가 인용한 로그 항목을 예상하지 못한 이유입니다. 그러나 화이트리스트에 포트 목록을 사용하는 것 같습니다.목적지포트는 로그에 993으로 표시되지만원천차단된 패킷의 포트입니다.

답변1

관련 정보