Home GCP - 방화벽 규칙
Post
Cancel

GCP - 방화벽 규칙

문제 상황

GCP-firewall1

이전에 고가용성 하둡클러스터를 GCP에서 구축해놨었는데, 오랜만에 접속해보려하니 디도스 공격을 실행하였다면서 해당 프로젝트가 전체 블락이 걸렸습니다.

뭔가 싶어서 메일을 들어가보니, 이미 이런 경고 메일이 와 있었습니다.

GCP-firewall2

핸드폰으로 메일오는걸 잘 봤어야했는데, 얼렁뚱땅 메일을 안읽고 넘겨버린 탓에 GCP에서 준 72시간의 유예시간이 지나버려 완전히 블락이 걸린듯 합니다.

블락 해제 관련헤서 어필을 보내봤는데, 별다른 조치를 취해주진 않았습니다. GCP측에서 어필을 받았고 검토한다고 해서 기다렸더니, 해당 프로젝트를 폐쇄한채로 분석해야된다고만 답변을 하더라구요.

그래서 해당 프로젝트를 삭제해달라고 어필을 하니 관련 절차를 알려주는데, 웃긴건 그 절차를 밟아도 프로젝트 삭제는 안해줍니다.

꽤 시간이 지났는데 그대로입니다. 폐쇄한채로 분석해야한다는게 이런거였나봅니다. 아니면 제가 뭔가 어필을 잘못했을 수도 있구요. 뭐가됐든 자연스럽게 삭제해주길 기다려야되는 거겠죠.

그래서 좀 짜증이 난 터에 혼자 왜 이런문제가 생겼을까 하고 잠깐 생각해봤습니다.

뭐 설치한 소프트웨어들에는 문제가 없을거고 클러스터링하면서 태그를 건드린 것 말고는 도저히 답이 없는거 같았습니다.

사실 태그 설정때 마스터 서버로 구축한 인스턴스는 외부 엑세스를 완전히 허용하긴 했었으니까요. 제 아이피로만 접근 가능하게 하려다가 잘안되서 그냥 바로 0.0.0.0/0을 때려박아버렸죠. 클러스터의 다른 인스턴스들은 내부적으로 통신이 가능하도록 태그를 걸어놨었기 때문에 문제가 생긴거라면 그곳말고는 없다는 생각이 들었습니다.

여기까지 생각이 닿으니 확실히 안일했던거같습니다. 방화벽을 함부로 막 열어두면 문제생긴다고 말은 자주 들었지만, 솔직히 전혀 와닿지 않아서 대충 넘기지 않았나싶습니다.

근데 이번 사태를 겪고나니 절실하게 깨달았습니다. 개인 프로젝트는 어떻게든 내 IP로만 엑세스가능하게 설정했어야했어야 했다는 사실을 말이죠. 그리고 당시에는 뭐 문제있겠나 싶어서 안일하게 진행했던 제 잘못이였다는 사실까지도요.

그래서 이 포스팅을 쓰게 됐습니다. GCP의 방화벽 설정에 대해서 좀더 자세히 공부함으로써 같은 실수를 반복하지 않도록하기 위해서말이죠. 물론 이 기회를 빌어 좀 더 명확하게 정리하고자하는 마음도 있구요.

VPC 방화벽 규칙 설정 in GCP

VPC란?

VPC(Virtual Private Cloud)에 대해 가볍게 이야기하고 넘어가자면, GCP같은 퍼블릭 클라우드 환경에서 사용할 수 있는 논리적으로 분리된 가상 네트워크입니다. 실제로 AWS, GCP, AZURE, NAVER CLOUD PLATFORM 등의 클라우드 플랫폼 서비스들이 모두 VPC 기능을 제공하고 있습니다.

GCP-firewall3

VPC는 다른 네트워크와 독립되어 있기 때문에 사용자가 자유롭게 네트워킹환경을 제어할 수 있고, 동시에 높은 보안성도 보장한다는 장점이 있습니다.

가령, 10개의 인스턴스가 만들어졌을 때, 5개는 하둡 클러스터로 구성해놓고 별도의 네트워킹 환경을 묶을 수 있다는 이야기입니다. 물론 각각의 인스턴트마다 VPC를 만들수도 있습니다.

이 이상의 자세한 설명은 GCP 홈페이지에 나와있는 설명으로 대신 하겠습니다.

VPC 방화벽 규칙을 사용하면 지정한 구성을 기준으로 가상 머신(VM) 인스턴스 간의 연결을 허용하거나 거부할 수 있습니다. 사용 설정한 VPC 방화벽 규칙은 인스턴스의 구성 및 운영 체제와 상관없이 인스턴스를 보호할 수 있도록 항상 실행됩니다. 아직 시작하지 않은 인스턴스도 마찬가지입니다.
모든 VPC 네트워크는 분산형 방화벽으로 작동합니다. 방화벽 규칙은 네트워크 수준에서 정의되지만 연결은 인스턴스별로 허용되거나 거부됩니다. VPC 방화벽 규칙은 인스턴스와 다른 네트워크 사이뿐만 아니라 동일한 네트워크 내의 개별 인스턴스 간에 존재하는 것으로 생각할 수 있습니다.

방화벽 규칙 설정하기

GCP-firewall4

우선 좌측상단의 메뉴(三)를 누르고 에서 VPC 네트워크 > 방화벽을 클릭합니다.

GCP-firewall5

그리고 방화벽 규칙 만들기를 눌러줍니다


GCP-firewall6

이름에는 방화벽 규칙의 이름을 정해주는 것 입니다. 소문자, 숫자, 하이픈(-)만 사용이 가능합니다.

설명은 해당 방화벽 규칙에 대한 설명을 넣어주는 부분입니다. 필수 입력칸이 아니기 때문에 그냥 넘기셔도 무관합니다.

로그는 사용하게되면, 방화벽 규칙의 영향을 모니터링, 확인, 분석할 수 있습니다. 사용 안함이 디폴트고 관련하여 더 알고싶다면 공식홈페이지의 설명을 보면 됩니다.

우선순위는 말그대로 방화벽 규칙들의 우선순위를 설정하는 것 입니다. 0~65535사이의 정수값을 갖고 숫자가 낮을수록 높은 우선순위입니다. 디폴트는 1000입니다.

네트워크는 VPC방화벽 규칙을 적용할 네트워크를 의미합니다. default는 GCP에서 제공하는 기본 네트워크를 사용하겠다는 것을 의미하고, 만약 자신이 커스텀한 VPC 네트워크를 사용하고 싶다면 VPC 네크워크 만들기를 통해 생성 후 별도 지정이 가능합니다.

GCP-firewall7

참고로 보통 인스턴스를 처음 생성하면 GCP가 default 네트워크를 사용해 기본적으로 만들어 놓은 방화벽 규칙들이 있습니다. 가볍게 한가지만 보자면, SSH 통신을 위한 22번 포트가 0.0.0.0/0이라는 IP범위로 설정되어있습니다. 즉, 22번 포트가 모든 외부 접속에 열려있다는 것입니다.

그래서 맨처음 인스턴스를 만들고나서 별도의 설정없이도 내 로컬에서 해당 인스턴스에 SSH로 접속이 바로 가능한 것입니다.

GCP-firewall8

만약 SSH 방화벽 규칙에서 IP범위를 내 아이피로 수정하면, 내 로컬환경에서만 SSH로 해당 인스턴스에 접속이 가능하도록 설정이 가능합니다. 다만, 우선순위가 최후순위로 되어있기 때문에 다른 방화벽 규칙에서 22번포트에 이보다 높은 우선순위를 갖게하면 굳이 default ssh 방화벽 규칙을 건들지 않아도 됩니다.


GCP-firewall9

트래픽 방향은 이 방화벽 규칙을 해당 인스턴스에 들어오는 트래픽(수신)에 적용할 것인지 아니면 나가는 트래픽(송신)에 적용할 것인지를 결정하는 겁니다.

외부로부터 해당 인스턴스(서버)로 유입되는 트래픽은 인그레스(ingress)라고 하고, 해당 인스턴스(서버)에서 외부로 유출되는 트래픽을 이그레스(egress)라고 합니다. 이로인해 방화벽 규칙들은 어떤 트레픽 방향을 타겟으로 했는지에 따라 인그레스 규칙이나 이그레스 규칙이라고 불리기도 합니다.

추가로 인그레스는 인바운드라고 불리기도 하고, 이그레스는 아웃바운드라고 불리기도합니다.

일치 시 작업은 이 방화벽규칙을 차단하는 목적으로 사용할 건지 허용하는 용도로 사용할 건지를 정하는 겁니다. 만약 거부라면, 지금 설정하는 모든 조건이 충족되는 접근에 대해 차단이 이루어집니다.

대상은 이 방화벽 규칙을 적용할 대상을 말하고 총 세가지의 옵션이 존재합니다.

대상 이름내용
네트워크의 모든 인스턴스해당 네트워크의 모든 인스턴스에 적용
지정된 대상 태그해당 태그를 가진 인스턴스에만 적용
지정된 서비스 계정사용자 계정 단위로 적용

대상 태그에는 이 방화벽 규칙을 사용위해 사용할 태그명을 작성합니다. 이 태그명은 자신이 해당 방화벽 규칙을 적용할 인스턴스의 세부옵션 → 수정 → 네트워크 태그에 입력할 수 있습니다. 이 태그가 적힌 인스턴스는 해당 방화벽 규칙이 적용됩니다.

GCP-firewall10

GCP-firewall11

GCP-firewall12

지금은 방화벽 규칙 이름과 태그명이 같지만 달라도 상관없습니다. 다만 한가지 기억해야할 건, 태그명이 훨씬 더 중요하다는 사실입니다. 왜냐면 직접적으로 방화벽 규칙을 인스턴스에 적용할 때 사용하는건 태그명이기 때문입니다.


소스필터는 트래픽 방향에 따른 필터를 의미하고 소스 필터에는 세가지 유형이 존재합니다.

소스필터 이름내용
IP범위트래픽의 IP범위를 지정하여 필터링
소스태그태그를 이용한 필터링
서비스 계정사용자 계정으로 필터링

GCP-firewall13

지금은 인그레스(수신)로 설정을 했기 때문에 인스턴스로 들어오는 IP or 태그 or 계정을 필터한다는 것을 의미합니다.

GCP-firewall14

반대로 앞선 트래픽 방향에서 이그레스(송신)로 설정을 했다면, 일종의 목적지를 설정하게됩니다. 이 경우에는 특이하게 IP로만 소스필터를 하도록 되어있습니다. 즉, 소스필터를 태그나 계정으로 고를 수 없다는 것입니다.

소스(대상) IPv4 범위는 소스필터에 적용할 IP를 직접 지정하는 부분입니다. 0.0.0.0/0으로 하면 모든 접근을 허용하겠다는 의미고, 특정아이피를 적으면 그 아이피에 대해서만 필터를 적용하겠다는 의미입니다.

트래픽방향이 인그래스이고 소스필터에서 태그나 계정을 선택했다면, IP가 아닌 태그나 계정을 지정할 수 있습니다.


GCP-firewall15

프로토콜 및 포트는 어떤 프로토콜과 어떤 포트에 대해 해당 방화벽 규칙을 적용할 건지를 설정하는 부분입니다. 모두 허용과 지정된 프로토콜 및 포트라는 두가지 옵션을 가지고 있습니다.

모두 허용 옵션은 앞서 IP필터에 사용한 IP의 모든 포트를 허용한다는 뜻인데 일반적으로 거의 사용하지 않습니다.

실제로 GCP는 권장사항 중에 하나로 최소 권한 원칙이라는 내용을 포함시켰는데, 기본적으로 모든 트래픽은 차단하고 필요한 특정 트래픽만 허용할 것을 권장하는 내용입니다. 여기에는 필요한 프로토콜 및 포트로만 규칙을 제한하는 것이 포함됩니다.

지정된 프로토콜 및 포트 옵션은 자신이 원하는 프로토콜과 포트를 지정할 수 있게 해주는 옵션입니다. 우리가 사용하는 대부분의 소프트웨어는 TCP를 사용하기 때문에 거의 대부분의 상황에서 TCP를 쓰게 될겁니다. 포트를 지정할 때는 하나만 입력도 가능하지만 범위로도 입력이 가능합니다.


모든 설정이 끝났다면 만들기를 누르면 됩니다. 그리고 원하는 인스턴스의 설정에 들어가 태그를 추가해주면 됩니다. 이 과정은 앞서 대상태그부분에서 언급했기때문에 여기서 마치도록 하겠습니다.

This post is licensed under CC BY 4.0 by the author.

이코테 Ch.3 DFS/BFS (3)

GCP - All open된 GCP 프로젝트 방화벽 체크 및 슬랙 알림 설정