iptables의 모든 소스에서 RELATED,ESTABLISHED를 수락하는 것이 "너무 개방적"인 것으로 간주됩니까?

나는 ESTABLISHED 및 RELATED 트래픽이 너무 개방적이라고 생각하지 않습니다. RELATED는 생략할 수 있지만 ESTABLISHED는 반드시 허용해야 합니다. 두 트래픽 클래스 모두 conntrack 상태를 사용합니다.

ESTABLISHED 다른 규칙에 의해 연결이 확인되었습니다. 이로 인해 단방향 규칙 구현이 훨씬 간단해졌습니다. 이를 통해 동일한 포트에서만 계속 거래할 수 있습니다.

RELATED 연결은 다른 규칙을 통해서도 확인됩니다. 많은 프로토콜에서는 작동하지 않습니다. 다시 말하면 규칙 구성이 훨씬 간단해집니다. 또한 적용 시 올바른 연결 순서를 보장합니다. 이는 실제로 규칙을 더욱 안전하게 만듭니다. 이렇게 하면 다른 포트에 연결할 수 있지만 해당 포트는 FTP 데이터 연결과 같은 관련 프로세스의 일부만 될 수 있습니다. 허용되는 포트는 프로토콜별 conntrack 모듈에 의해 제어됩니다.

ESTABLISHED 및 RELATED 연결을 허용하면 방화벽에서 허용할 새 연결에 집중할 수 있습니다. 또한 반환 트래픽은 허용하지만 새로운 연결은 허용하지 않는 규칙 위반을 방지합니다.

포트 1337의 프로그램을 안전하지 않은 것으로 분류했으므로 루트가 아닌 전용 사용자 ID를 사용하여 프로그램을 실행해야 합니다. 이렇게 하면 누군가가 앱을 해킹하고 향상된 액세스 권한을 얻을 경우 발생할 수 있는 피해가 제한됩니다.

포트 1337의 연결은 포트 22에 원격으로 액세스하는 데 사용될 가능성이 없지만 포트 1337에 대한 연결은 포트 22에 대한 연결을 프록시하는 데 사용될 수 있습니다.

SSH가 철저하게 보호되는지 확인하고 싶을 수도 있습니다.

• 방화벽 제한 외에도 호스트.허용을 사용하여 액세스를 제한할 수 있습니다.
• 루트 액세스를 방지하거나 최소한 키 사용을 요구하고 authenticate_keys 파일에서 액세스를 제한하십시오.
• 감사 로그인에 실패했습니다. 로그 스캐너는 비정상적인 활동에 대한 정기적인 보고서를 보낼 수 있습니다.
• 반복적인 액세스 실패 시 자동으로 액세스를 차단하려면 fall2ban과 같은 도구를 사용하는 것이 좋습니다.

ESTABLISHED 및 RELATED는 "상태 저장" 패킷 필터링의 기능으로, 필터링은 정적 규칙 집합뿐만 아니라 패킷이 고려되는 컨텍스트에 따라 달라집니다. 연결이 제대로 작동하려면 ESTABLISHED가 필요하고 관련 ICMP 메시지를 얻으려면 RELATED가 필요합니다. 상태 저장 필터링을 사용하면 정적 "상태 비저장" 규칙보다 더 정확한 필터링이 가능합니다.

먼저 ESTABLISHED를 살펴보겠습니다. 예를 들어 포트 22의 TCP를 생각해 보세요. 개시자(클라이언트)는 을( SYN를 ) 보냅니다 serverIPaddr:22. 서버가 SYN+ACK클라이언트로 돌아갑니다. 이제 클라이언트가 보낼 차례입니다 . "일치" ACK만 허용하려면 서버의 필터링 규칙이 어떻게 되어야 할까요 ? ACK일반적인 무상태 규칙은 다음과 같습니다.

-A INPUT --proto tcp --port 22 -j ACCEPT

이는 해당 국가의 규칙보다 더 자유롭습니다. 예를 들어 상태 비저장 규칙은 임의의 TCP 세그먼트를 허용 ACK하거나 FIN먼저 연결을 설정하지 않고 허용합니다. 포트 스캐너는 운영 체제 지문 채취를 위해 이 동작을 이용할 수 있습니다.

이제 "관련"을 살펴 보겠습니다. 이는 ICMP 메시지, 주로 오류 메시지에 사용됩니다. 예를 들어, 서버에서 클라이언트로의 패킷이 삭제되면 오류 메시지가 서버로 전송됩니다. 이 오류 메시지는 이전에 설정된 연결과 "관련"되어 있습니다. RELATED 규칙이 없으면 일반적으로 들어오는 오류 메시지(컨텍스트 없이)를 허용하거나 많은 사이트의 일반적인 관행처럼 ICMP를 완전히 삭제하고 전송 계층에서 시간 초과를 기다려야 합니다. (이것은 IPv6에 대한 나쁜 생각입니다. ICMPv6는 기존 IP에서 ICMP가 수행하는 것보다 IPv6에서 더 중요한 역할을 합니다.)

-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT이는 방화벽 구성에 너무 많은 시간을 소비하고 싶지 않은 사용자에게 좋은 기본값이며 항상 상당히 안전할 가능성이 높습니다. 그러나 실제 정책은 Linux 커널에 맡깁니다.

고려하다:

1. 모든 프로토콜은 로컬 시스템에서 시작되는 한 허용됩니다.
2. 모든 프로토콜과 메시지는 로컬 시스템에서 시작한 연결 및 프로토콜과 관련된 한 허용됩니다.

특히 커널이 기존 연결과 "관련" 있다고 간주할 수 있는 모든 ICMP 메시지 유형을 허용합니다. 이것이 정확히 무엇을 의미하는지 커널 소스 코드에서 확인하지는 않았지만 문서를 즉시 사용할 수 없으며 대부분의 ICMP 메시지 유형은 불필요하며 잠재적으로 해로울 수 있습니다. 따라서 보다 합리적인 선택은 다음과 같습니다.

-A INPUT -p tcp -m state --state ESTABLISHED -j ACCEPT
-A INPUT -p icmp --icmp-type 3 -m state --state RELATED -j ACCEPT
-A INPUT -p icmp --icmp-type 11 -m state --state RELATED -j ACCEPT
-A INPUT -p icmp --icmp-type 12 -m state --state RELATED -j ACCEPT

이는 "대상 도달 불가"(유형 3), "시간 초과"(유형 11) 및 "매개변수 문제"(유형 12) 제어 메시지에 대해 TCP 프로토콜에 대한 연결 및 ICMP 프로토콜에 대한 관련 연결 설정만 허용합니다. 예를 들어, 이는 이전 연결과 "관련"되어 있다고 간주하기 때문에 커널이 새 TCP 연결을 허용하는 것을 방지합니다(그러나 결코 그렇게 하지 않을 수도 있음).

내가 아는 한 이것들은 유일한 것이다.ICMP 메시지 유형관련 연결을 수락하는 것이 도움이 될 것입니다. 유형 11 제어 메시지는 TCP 경로 추적 기능의 사용을 허용합니다 traceroute -T.

IPv6의 상황은 ICMPv6을 사용하기 때문에 더욱 복잡합니다. 내 로컬 컴퓨터에서 사용하기 위해 당분간은 아웃바운드 인터페이스의 모든 IPv6 트래픽을 삭제하겠습니다. 보안을 유지하려면 더 많은 노력이 필요하고 내 ISP는 현재 이 작업을 수행할 필요가 없기 때문입니다. 서버를 구성하는 경우 비슷한 방식으로 구성하려고 합니다.

후손을 위해 입력 체인에 ICMP 유형 0 및 9 제어 메시지를 허용하고 핑(0/8) 및 IPv4 라우터 요청을 위해 출력 체인에 ICMP 유형 8 및 10 제어 메시지를 허용하는 것이 유용할 수도 있다는 점을 언급하겠습니다. (9/10) 일. 에코 응답이나 라우터 광고 메시지를 수락하는 데는 응답이 필요하지 않으므로 시스템 상태를 쿼리하는 데 사용할 수 없으므로 추가 보안 문제가 발생해서는 안 됩니다.

iptables -A INPUT -p icmp --icmp-type 0/0 -j ACCEPT
iptables -A INPUT -p icmp --icmp-type 9/0 -j ACCEPT
iptables -A OUTPUT -p icmp --icmp-type 8/0 -j ACCEPT
iptables -A OUTPUT -p icmp --icmp-type 10/0 -j ACCEPT