SSH 거부 규칙이 SSH를 허용합니까?

SSH 거부 규칙이 SSH를 허용합니까?

저는 아래와 같이 NACL 인바운드/아웃바운드 규칙을 할당하는 AWS VPC를 배우고 있습니다. 지금은 모든 IP에 대해 수행하고 있습니다.

Rule #    Type           Allow/Deny
100       All Traffic    Allow
200       SSH            Deny
 *        All Traffic    Deny


Outbound
Rule #    Type           Allow/Deny
100       SSH            Deny
200       All Traffic    Allow
 *        All Traffic    Deny

규칙에 따라 더 낮은 숫자가 먼저 평가되고 아웃바운드 규칙에서 SSH를 거부했기 때문에 내 SSH가 어떻게 작동하는지 궁금합니다. AWS에서 규칙이 실제로 어떻게 작동하는지 설명할 수 있는 사람이 있습니까?

답변1

인바운드 규칙 # 100(200은 사실상 무시됨)과 나가는 규칙이 이미 설정된 SSH 연결과 일치하지 않기 때문에 들어오는 SSH 트래픽이 허용됩니다...


기반AWS 설명서:

네트워크 ACL은 상태 비저장입니다. 즉, 허용된 인바운드 트래픽에 대한 응답은 아웃바운드 트래픽 규칙의 적용을 받습니다(그 반대의 경우도 마찬가지).

  • 인바운드 규칙

제가 볼 때 규칙의 순서가 잘못된 것 같습니다.

Rule #    Type           Allow/Deny
100       All Traffic    Allow
200       SSH            Deny
 *        All Traffic    Deny

규칙 100을 사용하여 모든 트래픽을 허용하므로 규칙 200은 언제든지 활용되지 않으므로 이는 의미가 없습니다(트래픽은 이미 규칙 100을 기반으로 허용되므로 규칙 200에 대해 아무것도 "남지" 않습니다). 더 많은 의미가 순서가 다르다고 생각합니다(ssh 서비스를 거부하려는 경우:

Rule #    Type           Allow/Deny
100       SSH            Deny
200       All Traffic    Allow
 *        All Traffic    Deny
  • 배 밖으로

다음은 규칙 번호가 낮은 SSH 트래픽입니다.

Rule #    Type           Allow/Deny
100       SSH            Deny
200       All Traffic    Allow
 *        All Traffic    Deny

그러면 SSH에 대한 트래픽이 거부되고 나머지는 허용됩니다...

유형 SSH는 포트 TCP/22를 사용하는 트래픽입니다. 이는 일반적으로 대상 포트로 사용됩니다. SSH 서버에 접속하려는 경우 TCP/22에 연결하지만 소스 포트는 TCP/X입니다. 여기서 X는 "무작위로"(실제로는 아니지만 간단하게 무작위로 말함) 선택되어 >10000이라고 가정합니다.

서버가 연결에 응답하면 대상 포트는 "귀하의" TCP/X이므로 규칙이 이 트래픽과 일치할 필요가 없습니다.

대상 TCP/22를 사용하는 나가는 트래픽은 대상이 다른 장치에 있는 서버에서 시작되고 아직 SSH 연결이 설정되지 않은 연결입니다.

답변2

호스트에 대한 모든 트래픽을 허용하지만 SSH 아웃바운드는 거부합니다.

내가 아는 한 NACL은 심층 패킷 검사를 수행하지 않습니다. 이는 프로토콜이 해당 프로토콜에 대한 단순한 별칭임을 의미합니다.할당된 포트.

SSH를 시도하는 것과 같은 정말 이상한 일을 하지 않는 한~에서포트 22, 인바운드 SSH 세션은 괜찮을 것입니다.

관련 정보