저는 커널 3.18.21과 MIPS의 일부 응용 프로그램이 포함된 임베디드 Linux 시스템을 실행하고 있습니다. Linux에서 iptables 및 ip6tables를 실행하면 다음과 같습니다.
iptables -A 입력 -p tcp --dport 80 -j 삭제
ip6tables -A 입력 -p tcp --dport 80 -j 삭제
http에는 tcp 포트 80이 사용됩니다. 그런 다음 이 Linux 서버(웹 서버 응용 프로그램이 실행 중임)에 대한 http 연결이 더 이상 작동하지 않는다는 것을 발견했습니다.
하지만 다음과 같이 natstat 명령을 실행하면:
netstat -tuln 네트워크 통계 grep 듣기 |
화면은 다음과 같습니다. (포트 80만 추출했습니다.)
tcp 0 0 :::80 :::* 들어보세요
이는 포트 80이 아직 열려 있다는 의미입니까? 그러면 왜 http를 사용하여 Linux에서 실행 중인 웹 서버에 액세스할 수 없습니까? (웹 서버 프로세스가 아직 실행 중인지 확인하고 확인했습니다.)
답변1
iptables애플리케이션이 TCP 또는 UDP 포트를 여는 것은 금지되지 않습니다(이로 인해 애플리케이션이 중단될 수 있음). 대신, 들어오는 패킷이 실제 포트에 도달하는 것을 차단합니다. 나가는 트래픽에 적용하면 일치하는 패킷이 실제로 전송되지 않을 수 있습니다.
를 사용하면 iptables ... -j DROP규칙과 일치하는 모든 패킷의 처리가 잠시 중단되어 사실상 응답 없이 패킷이 무시됩니다. 합법적인 TCP 연결의 경우 이로 인해 일반적으로 연결 시간이 초과될 때까지 발신자가 중단됩니다. 그러나 호스트는 여전히 ARP 요청에 응답해야 하기 때문에 스캐너는 여전히 호스트의 존재를 감지하고 포트를 "방화벽"으로 표시할 수 있습니다.
(스캐너가 동일한 네트워크 세그먼트에 있지 않은 경우 ARP 응답을 직접 관찰할 수는 없지만 대상 네트워크 세그먼트의 라우터가 ICMP "호스트. 도달할 수 없음"의 연결 시도에 응답하는지 확인하여 ARP 응답의 유무를 유추할 수 있습니다. 에러 메시지.
"호스트에 연결할 수 없음" 오류 없음 + TCP 재설정/ICMP 없음 "포트에 연결할 수 없음" = 포트가 방화벽으로 보호될 가능성이 높습니다. )
사용하는 경우 iptables ... -j REJECT규칙과 일치하는 모든 패킷이 처리됩니다.문제의 목적지 포트가 열리지 않은 것과 같습니다., 포트의 실제 상태에 관계없이. 이로 인해 방화벽 없이 닫힌 포트에 연결을 시도하는 경우처럼 일반적으로 TCP 재설정이나 ICMP 오류 응답 패킷이 원래 패킷의 보낸 사람에게 다시 전송됩니다. 이를 통해 발신자는 연결 거부를 감지할 수 있으므로 연결 시도가 더 빨리 실패할 수 있습니다. 스캐너의 경우 이러한 결과는 일반적인 "닫힌" 포트와 구별할 수 없어야 합니다.
발신자가 원본 패킷의 소스 IP 주소를 위조하는 경우 응답은 다른 호스트에 대한 서비스 거부 공격의 일부로 남용될 수 있지만 최신 운영 체제는 TCP 재설정/ICMP 전송 속도 및/또는 우선 순위를 줄입니다. 오류 패킷은 기본적으로 제한되어 있으므로 이는 큰 문제가 되지 않습니다.
답변2
iptables/nftables는 응용 프로그램이 [포트에서] 수신하는 것을 방지하지 않으며 방지할 수도 없습니다.