원하는 액세스 권한을 부여하기 위해 ACL을 이런 방식으로 구성해야 하는 이유는 무엇입니까?

원하는 액세스 권한을 부여하기 위해 ACL을 이런 방식으로 구성해야 하는 이유는 무엇입니까?

ER605 라우터의 보조 네트워크가 있는데, 이는 연결된 장치인 라즈베리 파이를 격리하는 데 사용됩니다. 나는 이를 사용하여 의심스러운 소스(예: 시댁에서 영구적으로 악성 코드에 감염된 컴퓨터)로부터 들어오는 파일을 격리하고 검사합니다. pi에 액세스하고 스캔한 파일을 기본 네트워크로 추출할 수 있어야 합니다. 액세스를 위해 VNC를 사용하고 SMB 공유를 통해 확인된 파일을 내 QNAP NAS에 직접 넣을 계획입니다.

ACL 규칙 5는 격리 네트워크에서 기본 네트워크로의 통신을 차단합니다. 기본 네트워크에서 격리 파이로 VNC를 가져오기 위해 처음에는 규칙 4를 추가했는데 충분하지 않았습니다(온라인 읽기에서는 반환 메시지에 ACL이 필요하다고 제안함). 그래서 VNC 서비스를 참조하는 규칙 3 버전을 추가했습니다. 그래도 실패했어요. 즉흥적으로 소스와 대상 포트를 교환하고 규칙 #3을 VNC 서비스에서 VNC 이중으로 변경하는 VNC_duplex 서비스 정의를 생성하려고 시도했는데 viola VNC가 작동했습니다!

이것이 효과가 있어서 매우 기쁘지만 왜 그런지, 안전한지 확실하지 않습니다. ACL 규칙 3이 악성 스크립트가 라즈베리 파이의 모든 포트에서 내 기본 네트워크의 모든 장치에 있는 포트 5900으로 메시지를 보낼 수 있도록 허용한다는 점을 이해한 것이 맞습니까? 이것을 이해하는 의미론적 방법은 무엇이며, 이를 더욱 안전하게 만들 수 있습니까?

내 네트워크 및 VLAN:

여기에 이미지 설명을 입력하세요

여기에 이미지 설명을 입력하세요

액세스 권한을 분할/부여하려는 네트워크 영역을 설명하기 위해 일부 IP 범위도 설정했습니다.

여기에 이미지 설명을 입력하세요

여기에 이미지 설명을 입력하세요

내 서비스 유형(마지막 4개는 내가 직접 입력한 사용자 정의임):

여기에 이미지 설명을 입력하세요

마지막으로 내 ACL은 다음과 같습니다.

여기에 이미지 설명을 입력하세요

답변1

온라인 읽기에서는 반환 메시지에 ACL이 필요하다고 제안했기 때문에 VNC 서비스를 참조하는 규칙 3 버전을 추가했지만 여전히 실패했습니다. 즉흥적으로 소스와 대상 포트를 교환하고 규칙 #3을 VNC 서비스에서 VNC 이중으로 변경하는 VNC_duplex 서비스 정의를 만들려고 시도했는데 viola VNC가 작동했습니다!

Pi가 컴퓨터에 응답을 보내면,Pi가 소스입니다.

'반환' 패킷에는 Pi의 IP 주소가 "소스 IP"로 있을 뿐만 아니라 해당 포트 번호도 있습니다.파이 측에서"소스 포트"로.

Connection:        192.168.0.PC:54321 <--> 192.168.2.10:5900

Packets from PC:   src = 192.168.0.PC:54321, dst = 192.168.2.10:5900
Packets from Pi:   src = 192.168.2.10:5900, dst = 192.168.0.PC:54321

방화벽의 모든 원래 서비스 템플릿은 "앞으로" 방향으로만 정의됩니다. 예를 들어 "VNC" 템플릿은 대상 포트로 5900과 일치합니다. 설명된 대로 VNC 서버를 대상으로 하는 패킷에만 일치하고 '반환' 패킷에는 일치하지 않습니다.

ACL 규칙 3이 악성 스크립트가 라즈베리 파이의 모든 포트에서 내 기본 네트워크의 모든 장치에 있는 포트 5900으로 메시지를 보낼 수 있도록 허용한다는 점을 이해한 것이 맞습니까?

아니요. 허용되는 것은 그 반대입니다. 스크립트가 메시지를 보낼 수 있도록 허용합니다.포트 5900에서라즈베리 파이에서어떤 항구로든기본 네트워크에 있습니다. ("소스 포트 = 5900"의 '소스'정말로 의미한다패킷의 소스.)

연결의 소스 포트 이후~할 수 있다(원하는 경우) 임의로 선택될 수 있습니다. 이는 기본 네트워크가 누구에게나 활짝 열려 있음을 의미합니다.알고 있다이 예외의 존재에 대해; 그들이 해야 할 일은 OS에 로컬 포트 ​​5900에 연결을 바인딩하도록 요청하는 것뿐입니다. (그러나 반면에 소스 포트는 일반적으로 무작위로 지정되고 범위는 5900을 훨씬 넘어서 시작하므로그렇지 않다이 예외에 대해 알고 있는 사람이 우연히 이를 발견할 가능성은 거의 없습니다.)

이것을 이해하는 의미론적 방법은 무엇입니까?

"출처"는 실제로 개인의 출처를 의미합니다.패킷, 전체 연결이 아닙니다. (실제로 포트는 패킷의 "전송 계층" 주소의 일부로 거의 간주될 수 있으며 실제로 다른 여러 비 IP 프로토콜에서는 문자 그대로 주소의 일부였습니다.)

각 포트는 각 IP 주소가 특정 엔드포인트와 연결되는 것과 같은 방식으로 특정 엔드포인트와 연결됩니다. Pi에 연결하는 경우 Pi의 '반환' 패킷이 계속 표시될 것으로 예상하지 않습니다. Pi의 IP 주소를 "대상"으로 지정하며 포트 번호에도 동일하게 적용됩니다.

더 안전하게 만들 수 있을까요?

일반적인 접근 방식은 이러한 반사 ACL을 완전히 피하고상태 저장방화벽. 대부분의 라우터는 활성 연결("상태" 또는 "흐름")을 추적할 수 있습니다.~해야 한다일반적인 1:다 NAT를 구현하는 경우 이를 수행하십시오. 방화벽 필터에는 "설정된" 연결에 해당하는 모든 패킷을 허용하거나(iptables/nftables에서와 같이) 그러한 패킷을 암시적으로(pf에서와 같이) 허용하는 특수 규칙이 있을 수 있습니다.

ER603은 상태 저장 ACL에 대한 지원을 얻은 것 같습니다.펌웨어 2.1에서. (사람들은 효과가 없다고 말하는 것 같습니다.)

만약 너라면~ 해야 하다상태 비저장 ACL을 사용하는 경우 대체 접근 방식은 다음과 같은 '반환' 패킷만 허용하는 것입니다.TCP "ACK" 플래그세트. TCP 연결의 초기 패킷절대다른 모든 패킷에는 이 플래그가 설정되어 있습니다. 모든 포트에서 TCP ACK 패킷을 허용하는 단일 규칙만 있으면 충분합니다.

당연히 이 접근 방식은 TCP에서만 작동합니다. 상태 추적 없이는 UDP에 대해 많은 작업을 수행할 수 없습니다. 단, 반사 ACL이 만드는 허점을 누구도 발견하지 못하기를 바랍니다.

ICMP '반환' 패킷도 허용하는 또 다른 규칙이 있어야 합니다(예: 에코 응답 및 다양한 ICMP '오류' 메시지 –최소한"조각화가 필요함"을 허용해야 하지만 "접근할 수 없음"과 같은 다른 오류도 허용하는 것이 좋습니다.

관련 정보