☰

내 iptables 로그에 일부 TCP 재설정 패킷이 표시되는 이유는 무엇입니까?

tag-icon • tag-icon iptables tcp
내 iptables 로그에 일부 TCP 재설정 패킷이 표시되는 이유는 무엇입니까?

저는 Debian Jessie 서버에 몇 가지 기본적인 iptables 규칙을 추가하는 것부터 시작했습니다. 내 목표는 보안 및 학습 목적으로 네트워크 트래픽을 필터링하고 기록하는 것입니다. ICMP 패킷을 무시하고 다음은 내가 사용하는 규칙입니다.

# INPUT
-A INPUT -i lo -j ACCEPT
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -p tcp -j REJECT --reject-with tcp-reset

# OUTPUT
-A OUTPUT -o lo -j ACCEPT
-A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A OUTPUT -p udp -m udp --dport 53 -j ACCEPT
-A OUTPUT -p tcp -m tcp --dport 25 -j ACCEPT
-A OUTPUT -m limit -j LOG --log-prefix "UNKNOWN_OUTGOING: " --log-level 5

정책은 INPUT 및 OUTPUT 모두에 대해 ACCEPT로 설정됩니다.

이제 로그에는 발신 목록이 자주 표시됩니다.빠른 회복 시간패킷은 일반적으로 포트 80으로 전송됩니다. 여기 SRC IP는 내 서버에 속하며, 대상 IP는 다른 사람의 활동이 노출되지 않도록 부분적으로 편집되었습니다.

Aug 14 11:48:37 reynholm kernel: [81795.100496] UNKNOWN_OUTGOING: IN= OUT=ifext SRC=89.238.65.123 DST=108.162.[edited] LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=3594 DPT=80 WINDOW=0 RES=0x00 RST URGP=0

원인이 무엇인지 이해할 수 없습니다. SSH 및 MTA를 제외하고는 실행되는 응용 프로그램이 없습니다. 내 입력 때문인가요?거부하다규칙? 하지만 이러한 패킷을 출력에서 ​​처리하면 안 되나요?상태규칙?

아래는 패킷 중 하나와 이를 트리거한 것으로 보이는 연결 시도의 캡처입니다. 108.162.[edited]이전에는 내 서버 간에 패킷이 전송되지 않았습니다.

11:48:37.860337 IP (tos 0x0, ttl 60, id 0, offset 0, flags [DF], proto TCP (6), length 44)
    108.162.[edited].80 > 89.238.65.123.3594: Flags [S.], cksum 0x79bb (correct), seq 79911989, ack 235561828, win 29200, options [mss 1460], length 0
        0x0000:  4500 002c 0000 4000 3c06 7342 6ca2 0000  E..,..@.<.sBl...
        0x0010:  59ee 417b 0050 0e0a 04c3 5c35 0e0a 6364  Y.A{.P....\5..cd
        0x0020:  6012 7210 79bb 0000 0204 05b4 0000       `.r.y.........
11:48:37.860408 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40)
    89.238.65.123.3594 > 108.162.[edited].80: Flags [R], cksum 0x648e (correct), seq 235561828, win 0, length 0
        0x0000:  4500 0028 0000 4000 4006 6f46 59ee 417b  E..(..@[email protected]{
        0x0010:  6ca2 0000 0e0a 0050 0e0a 6364 0000 0000  l......P..cd....
        0x0020:  5004 0000 648e 0000                      P...d...

답변1

규칙에서 TCP RST 패킷이 생성됩니다.

-A INPUT -p tcp -j REJECT --reject-with tcp-reset

기본 정책(귀하의 경우 ACCEPT)은 체인의 어떤 규칙과도 일치하지 않는 패킷에만 적용됩니다. 패킷이 REJECT 대상이 있는 위 규칙과 일치하는 경우 기본 정책이 적용되지 않으며 ACCEPT 대신 거부됩니다(TCP RST 생성).

이 TCP RST는 규칙과 일치하지 않습니다.

-A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

이는 설정된 다른 연결과 아무 관련이 없으며 ESTABLISHED 연결의 일부가 아니기 때문입니다. 이는 귀하의 규칙과 경쟁을 계속해서 시행할 것입니다.

-A OUTPUT -m limit -j LOG --log-prefix "UNKNOWN_OUTGOING: " --log-level 5

그리고 로그에 남게 됩니다. 이러한 RST 패킷이 기록되는 것을 원하지 않으면 이 규칙을 일치하지 않도록 조정하거나 RST 패킷과 일치하도록 이전 규칙을 삽입하고 패킷이 여기에 도달하기 전에 일부 처리를 수행하십시오.

내가 알아차린 또 다른 점은 기록하는 첫 번째 패킷이 원격 네트워크 서버의 SYN/ACK 패킷이며, 서버에 대한 연결을 시작하기 위해 이전에 보낸 SYN 패킷에 원격 네트워크 서버가 응답하는 것처럼 보입니다. . 포트 80의 원격 호스트. 초기 SYN을 보내지 않았다면 연결이 "ESTABLISHED"와 일치하지 않을 것이라고 생각하지만, SYN을 보냈다면 연결이 "ESTABLISHED"와 일치해야 한다고 생각합니다. 이로 인해 RST가 일치하게 되는 규칙이 엉망이 될 수 있습니다.

답변2

@casey의 탁월한 답변 확장: 그 이유는 원격에서 오는 패킷에 SYN 및 ACK 플래그가 설정되어 있기 때문입니다. 이는 첫 번째 패키지에는 영향을 미치지 않습니다. iptables는 재설정 패킷이 초기 패킷과 관련된 것으로 간주하지 않습니다. 이는 명백히 말이 되지 않기 때문입니다.

다음 도구를 사용하여 효과를 재현할 수 있습니다 hping3. SYN/ACK 패킷 보내기를 사용합니다 hping3 -c 1 --syn --ack 89.238.65.123. 이 패킷에 대한 서버의 응답은 ACK 플래그를 설정하지 않으며 연결되지 않습니다.상태규칙(즉, 핑 전송과 관련이 없음). 결과는 로그 항목을 트리거합니다.

초기 요청에 ACK 플래그가 설정되지 않은 경우에는 그러한 효과가 발생하지 않습니다.

들어오는 잘못된 TCP 패킷을 필터링하고 삭제하여 로그 메시지를 제거했습니다.

-I INPUT 3 -m state --state INVALID -j DROP

답변3

이는 포트 스캔 시작의 일부인 것 같습니다.~에서원격 호스트의 tcp/80. 원격 호스트가 서비스 tcp/3594를 조사하고 시스템이 "아니요. 지금 떠나세요(RST)"라고 올바르게 표시합니다. 불행하게도 이는 인터넷에 연결된 시스템에서는 상당히 일반적인 현상입니다.

이를 설치하면 fail2ban호스트가 허용되지 않는 방식으로 시스템에 연결하려는 시도를 차단하는 데 매우 효과적입니다. 하지만 주의할 점이 있습니다. 포함된 예제 외부에서 구성하는 것은 쉽지 않습니다.

관련 정보