Translated ['.github/pull_request_template.md', 'src/README.md', 'src/pe

2026-07-28 22:51:09 -07:00 · 2025-01-01 23:58:29 +00:00
parent 20ad0aabbd
commit 018d2d2250
220 changed files with 2116 additions and 2160 deletions
@@ -4,9 +4,9 @@

 ## Introduction

-Kubernetes에서는 기본 동작이 **같은 노드에 있는 모든 컨테이너 간의 연결을 허용**하는 것으로 관찰됩니다. 이는 네임스페이스 구분에 관계없이 적용됩니다. 이러한 연결은 **Layer 2** (이더넷)까지 확장됩니다. 결과적으로, 이 구성은 시스템을 취약점에 노출시킬 수 있습니다. 특히, **악의적인 컨테이너**가 같은 노드에 있는 다른 컨테이너에 대해 **ARP 스푸핑 공격**을 실행할 가능성을 열어줍니다. 이러한 공격 중에 악의적인 컨테이너는 다른 컨테이너를 위한 네트워크 트래픽을 기만적으로 가로채거나 수정할 수 있습니다.
+Kubernetes에서는 기본 동작이 **같은 노드에 있는 모든 컨테이너 간의 연결을 허용**하는 것으로 관찰됩니다. 이는 네임스페이스 구분에 관계없이 적용됩니다. 이러한 연결은 **Layer 2** (이더넷)까지 확장됩니다. 결과적으로, 이 구성은 시스템을 취약점에 노출시킬 수 있습니다. 특히, **악의적인 컨테이너**가 같은 노드에 위치한 다른 컨테이너에 대해 **ARP 스푸핑 공격**을 실행할 가능성을 열어줍니다. 이러한 공격 중에 악의적인 컨테이너는 다른 컨테이너를 위한 네트워크 트래픽을 속여 가로채거나 수정할 수 있습니다.

-ARP 스푸핑 공격은 **공격자가 허위 ARP** (주소 확인 프로토콜) 메시지를 로컬 영역 네트워크에 전송하는 것을 포함합니다. 이로 인해 **공격자의 MAC 주소가 네트워크의 합법적인 컴퓨터 또는 서버의 IP 주소와 연결**됩니다. 이러한 공격이 성공적으로 실행된 후, 공격자는 전송 중인 데이터를 가로채거나 수정하거나 심지어 중단할 수 있습니다. 공격은 OSI 모델의 Layer 2에서 실행되므로, Kubernetes에서 이 레이어의 기본 연결성이 보안 문제를 제기합니다.
+ARP 스푸핑 공격은 **공격자가 지역 네트워크를 통해 위조된 ARP** (주소 확인 프로토콜) 메시지를 전송하는 것을 포함합니다. 이로 인해 **공격자의 MAC 주소가 네트워크의 합법적인 컴퓨터 또는 서버의 IP 주소와 연결**됩니다. 이러한 공격이 성공적으로 실행된 후, 공격자는 전송 중인 데이터를 가로채거나 수정하거나 심지어 중단할 수 있습니다. 공격은 OSI 모델의 Layer 2에서 실행되므로, Kubernetes에서 이 레이어의 기본 연결이 보안 문제를 일으킵니다.

 4대의 머신이 생성될 시나리오는 다음과 같습니다:

@@ -98,20 +98,20 @@ kubectl exec -it mysql bash -- bash -c "apt update; apt install -y net-tools; ba
 ```
 ## 기본 Kubernetes 네트워킹

-여기 소개된 네트워킹 주제에 대한 더 많은 세부정보는 참조를 확인하세요.
+여기서 소개된 네트워킹 주제에 대한 더 많은 세부정보는 참조를 확인하세요.

 ### ARP

 일반적으로 **노드 내의 pod-to-pod 네트워킹**은 모든 pod를 연결하는 **브리지**를 통해 가능합니다. 이 브리지는 “**cbr0**”라고 불립니다. (일부 네트워크 플러그인은 자체 브리지를 설치합니다.) **cbr0는 ARP** (주소 확인 프로토콜) 해상도도 처리할 수 있습니다. 들어오는 패킷이 cbr0에 도착하면 ARP를 사용하여 목적지 MAC 주소를 확인할 수 있습니다.

-이 사실은 기본적으로 **같은 노드에서 실행되는 모든 pod**가 **통신**할 수 있다는 것을 의미합니다. 같은 노드의 다른 pod와 (네임스페이스와 관계없이) 이더넷 수준(계층 2)에서 통신할 수 있습니다.
+이 사실은 기본적으로 **같은 노드에서 실행되는 모든 pod**가 **같은 노드의 다른 pod와 통신**할 수 있음을 의미합니다 (네임스페이스와는 무관하게) 이더넷 수준(계층 2)에서.

 > [!WARNING]
 > 따라서, **같은 노드의 pod 간에 ARP 스푸핑 공격을 수행할 수 있습니다.**

 ### DNS

-Kubernetes 환경에서는 일반적으로 kube-system 네임스페이스에서 1개(또는 그 이상)의 **DNS 서비스가 실행되고** 있습니다:
+Kubernetes 환경에서는 일반적으로 kube-system 네임스페이스에서 1개(또는 그 이상)의 **DNS 서비스가 실행되고** 있는 것을 찾을 수 있습니다:
 ```bash
 kubectl -n kube-system describe services
 Name:              kube-dns
@@ -143,16 +143,16 @@ Endpoints:         172.17.0.2:9153
 cat /etc/resolv.conf
 nameserver 10.96.0.10
 ```
-그러나 **pod는** 그 **주소**에 어떻게 가야 할지 **모릅니다**. 이 경우 **pod 범위**는 172.17.0.10/26입니다.
+그러나, pod는 이 **주소**에 어떻게 가야 할지 **모릅니다**. 이 경우 **pod 범위**는 172.17.0.10/26입니다.

-따라서 **pod는 10.96.0.10 주소로 DNS 요청을 보낼 것입니다**, 이는 cbr0에 의해 **172.17.0.2로 변환됩니다**.
+따라서, pod는 **주소 10.96.0.10**으로 **DNS 요청**을 보낼 것이며, 이는 cbr0에 의해 **172.17.0.2**로 **변환**됩니다.

 > [!WARNING]
-> 이는 **pod의 DNS 요청**이 **항상** **서비스 IP를 엔드포인트 IP로 변환하기 위해 브리지로** 간다는 것을 의미합니다. DNS 서버가 pod와 같은 서브네트워크에 있더라도 말입니다.
+> 이는 pod의 **DNS 요청**이 **항상** **브리지**로 가서 **서비스 IP를 엔드포인트 IP로 변환**한다는 것을 의미합니다. DNS 서버가 pod와 같은 서브네트워크에 있더라도 말입니다.
 >
-> 이를 알고, **ARP 공격이 가능하다는 것을 알면**, 노드의 **pod**는 **서브네트워크** 내의 **각 pod**와 **브리지** 간의 **트래픽을 가로챌 수** 있으며, DNS 서버로부터의 **DNS 응답을 수정할 수** 있습니다 (**DNS 스푸핑**).
+> 이를 알고, **ARP 공격이 가능하다는** 것을 알면, 노드의 **pod**는 **서브네트워크** 내의 **각 pod**와 **브리지** 간의 **트래픽을 가로챌 수** 있으며, DNS 서버로부터의 **DNS 응답을 수정**할 수 있습니다 (**DNS 스푸핑**).
 >
-> 게다가, **DNS 서버**가 **공격자와 같은 노드에 있다면**, 공격자는 클러스터 내의 어떤 pod의 **모든 DNS 요청을 가로챌 수** 있으며 (DNS 서버와 브리지 간), 응답을 수정할 수 있습니다.
+> 게다가, **DNS 서버**가 공격자와 **같은 노드에** 있다면, 공격자는 클러스터 내의 어떤 pod의 **모든 DNS 요청을 가로챌 수** 있으며 (DNS 서버와 브리지 간), 응답을 수정할 수 있습니다.

 ## 같은 노드의 pods에서 ARP 스푸핑

@@ -233,16 +233,16 @@ arpspoof -t 172.17.0.9 172.17.0.10
 ```
 ## DNS Spoofing

-이미 언급했듯이, **DNS 서버 포드와 동일한 노드에서 포드를 손상시키면**, **ARPSpoofing**을 사용하여 **브리지와 DNS** 포드 간에 **MitM**을 수행하고 **모든 DNS 응답을 수정**할 수 있습니다.
+이미 언급했듯이, 만약 당신이 **DNS 서버 포드와 같은 노드에 있는 포드를 손상시키면**, 당신은 **MitM**을 **ARPSpoofing**을 사용하여 **브리지와 DNS** 포드와 함께 **모든 DNS 응답을 수정**할 수 있습니다.

-테스트를 위한 정말 좋은 **도구**와 **튜토리얼**이 있습니다: [**https://github.com/danielsagi/kube-dnsspoof/**](https://github.com/danielsagi/kube-dnsspoof/)
+당신은 [**https://github.com/danielsagi/kube-dnsspoof/**](https://github.com/danielsagi/kube-dnsspoof/)에서 이를 테스트할 수 있는 정말 멋진 **도구**와 **튜토리얼**을 가지고 있습니다.

-우리의 시나리오에서는, **공격자 포드에** **도구**를 **다운로드**하고 **스푸핑**하려는 **도메인**이 포함된 \*\*`hosts`라는 이름의 파일을 생성**합니다:
+우리의 시나리오에서는, **공격자 포드**에 **도구**를 **다운로드**하고 **스푸핑**하려는 **도메인**으로 \*\*`hosts`라는 이름의 파일을 생성**하세요:
 ```
 cat hosts
 google.com. 1.1.1.1
 ```
-우분투-희생자 머신에 공격을 수행합니다:
+ubuntu-victim 머신에 공격을 수행하십시오:
 ```
 python3 exploit.py --direct 172.17.0.10
 [*] starting attack on direct mode to pod 172.17.0.10
@@ -260,13 +260,13 @@ dig google.com
 google.com.		1	IN	A	1.1.1.1
 ```
 > [!NOTE]
-> 만약 당신이 자신의 DNS 스푸핑 스크립트를 만들려고 한다면, **DNS 응답을 수정하는 것만으로는** **작동하지 않을 것입니다**, 왜냐하면 **응답**은 **악성** **포드**의 **src IP** 주소를 가질 것이고 **수락되지 않을 것입니다**.\
-> 당신은 피해자가 DNS 요청을 보낸 **DNS**의 **src IP**로 **새로운 DNS 패킷**을 생성해야 합니다 (이는 172.16.0.2와 같은 것이며, 10.96.0.10은 K8s DNS 서비스 IP이고 DNS 서버 IP가 아닙니다. 이에 대한 자세한 내용은 소개에서 다룹니다).
+> 만약 당신이 자신의 DNS 스푸핑 스크립트를 만들려고 한다면, **DNS 응답만 수정하는 것**은 **작동하지 않을 것입니다**, 왜냐하면 **응답**은 **악성** **pod**의 **src IP** 주소를 가질 것이고 **수락되지 않을 것입니다**.\
+> 당신은 피해자가 DNS 요청을 보낸 **DNS**의 **src IP**로 **새 DNS 패킷**을 생성해야 합니다 (이는 172.16.0.2와 같은 것이며, 10.96.0.10은 K8s DNS 서비스 IP이고 DNS 서버 IP가 아닙니다. 이에 대한 자세한 내용은 소개에서 다룹니다).

 ## 트래픽 캡처

 도구 [**Mizu**](https://github.com/up9inc/mizu)는 Kubernetes를 위한 간단하면서도 강력한 API **트래픽 뷰어**로, 마이크로서비스 간의 **모든 API 통신**을 **보기** 위해 사용되어 디버그 및 회귀 문제 해결에 도움을 줍니다.\
-선택한 포드에 에이전트를 설치하고 그들의 트래픽 정보를 수집하여 웹 서버에 표시합니다. 그러나 이를 위해서는 높은 K8s 권한이 필요하며 (그리고 그리 은밀하지 않습니다).
+선택한 pod에 에이전트를 설치하고 그들의 트래픽 정보를 수집하여 웹 서버에 표시합니다. 그러나 이를 위해서는 높은 K8s 권한이 필요하며 (그리고 매우 은밀하지는 않습니다).

 ## 참고자료