군만두의 IT 개발 일지

[스터디15] 05. 서버 기반 워드프레스 & 서버리스 웹사이트 구축 본문

학습일지

[스터디15] 05. 서버 기반 워드프레스 & 서버리스 웹사이트 구축

mandus 2026. 8. 6. 00:47

목차

    22장. 외부 공격을 보호하는 방화벽 서비스 파악하기

    AWS WAF는 웹 애플리케이션을 외부 공격으로부터 보호하는 방화벽 서비스다. 아마존 클라우드프론트, 애플리케이션 로드 밸런서 같은 서비스에 연결해 사용하며, 들어온 요청이 악의적인 공격인지 검토하고 필요에 따라 차단한다.

    22-1 보안 그룹과 AWS WAF의 차이

    AWS는 허용하지 않은 사용자의 접근을 막기 위해 보안 그룹을 제공한다. 보안 그룹은 EC2, RDS에 설정하며 네트워크 계층과 전송 계층에서 효율적인 보호 기능을 제공한다. 하지만 보안 그룹은 IP만을 제한하므로, 사용자가 개발한 애플리케이션을 외부 공격으로부터 보호하기에는 부족하다.

    구분 보안 그룹 AWS WAF
    통제 기준 IP 주소와 포트를 기준으로 접근을 제한한다. IP 주소, HTTP 헤더, 요청 본문, URI 등 요청의 내용을 검사한다.
    연결 대상 EC2, RDS 등에 설정한다. 클라우드프론트, 애플리케이션 로드 밸런서 등에 연결한다.

    22-2 요청 처리 흐름과 적용 패턴

    애플리케이션 로드 밸런서에 AWS WAF를 도입했다면 요청은 다음 순서로 처리된다.

    • 보안 그룹 판단: 로드 밸런서의 보안 그룹이 허용하는 요청인지 먼저 판단하고, 허용하지 않는다면 요청을 거부한다.
    • WAF 검토: 허용된 요청이라면 AWS WAF에서 악의적인 공격인지 검토한다.
    • 로깅: 모든 요청과 대응은 클라우드워치로 로깅되며, 아마존 S3에 로그를 보존해 공격 시도를 추적하고 분석할 수 있다.
    • 요청 전달: 검토 결과 문제가 없다면 웹 애플리케이션으로 요청을 보낸다.

    아마존 클라우드프론트를 사용하는 경우에는 두 가지 패턴을 생각해볼 수 있다.

    패턴 구성
    패턴 1 클라우드프론트가 OAI로 S3를 지정하고, 클라우드프론트에 AWS WAF를 설정해 특정 IP의 접근을 차단·허용하며 외부 공격을 탐지하고 방어한다.
    패턴 2 로드 밸런서와 클라우드프론트로 웹 애플리케이션을 운용하는 환경으로, 클라우드프론트에만 AWS WAF를 설정하거나 두 서비스 모두에 설정한다.

    더 높은 보안을 고려한다면 두 서비스 모두에 설정하는 것이 좋다. 하지만 대부분의 트래픽이 클라우드프론트를 통해 유입된다면 클라우드프론트에만 적용해도 충분히 효과적이며, 두 곳에 각각 설정하면 비용이 증가하므로 비용 효율 측면에서는 클라우드프론트 단독 적용이 유리하다.

    22-3 AWS WAF의 주요 5가지 기능

    기능 설명
    애플리케이션에 대한 공격 방어 IP 주소, HTTP 헤더, 요청 본문, 사용자 지정 URI 등의 기준에 따라 통신을 필터링하는 규칙을 생성한다.
    IP 제한으로 인한 무단 액세스 차단 의심스럽거나 악의적인 IP 주소로부터의 통신을 미리 차단해 웹 애플리케이션을 보호한다.
    DDoS 공격 대책 일정 시간 내 액세스 횟수가 요율 기준 규칙의 임곗값을 초과하면 해당 IP 주소의 액세스를 일시적으로 제한한다.
    악의적인 봇 대책 스크레이퍼, 스캐너, 크롤러 같은 봇을 모니터링하고, 검색 엔진 봇을 비롯한 정상적인 봇만 허용하도록 설정한다.
    계정의 무단 로그인 방지 애플리케이션의 로그인 페이지를 모니터링하고 도난당한 자격 증명으로 로그인하는지 확인한다.

    22-4 관리형 규칙과 커스텀 규칙

    AWS WAF를 생성하는 것만으로는 위 기능이 동작하지 않는다. 방어하고자 하는 트래픽을 걸러낼 규칙이 필요하며, AWS에서 미리 만들어 제공하는 규칙 집합이 관리형 규칙이다. 관리형 규칙을 사용하면 규칙을 직접 만드는 복잡한 과정을 생략할 수 있다. 자주 사용되는 관리형 규칙 중 필수로 도입을 권장하는 규칙은 다음과 같다.

    규칙명 용도 용량
    Amazon IP reputation list 아마존 내부 위협 인텔리전스를 기반으로 만든 규칙 25
    Core rule set 일반 웹 애플리케이션에 적용하는 규칙 700
    Known bad inputs 무단 액세스 및 취약성 악용과 관련된 입력 패턴을 차단하는 규칙 200
    SQL database SQL 데이터베이스의 악용을 방지하는 규칙 200

    그 외 Admin protection, Anonymous IP list, PHP·WordPress application, Linux·POSIX·Windows operating system 규칙은 구성하려는 환경이나 OS에 맞춰 선택한다. 예를 들어 워드프레스를 이용하는 웹사이트라면 WordPress application 규칙을 추가해 취약점을 보완한다.

    • WCU: 웹 ACL 용량 단위(web ACL capacity units)로, 각 규칙은 고유한 용량을 가진다.
    • 용량 제한: 설정할 수 있는 규칙의 최대 용량은 5000WCU이며, 1500WCU를 초과하는 용량에 대해서는 추가 요금이 청구된다.
    • 커스텀 규칙: 관리형 규칙 외에 사용자가 직접 규칙을 만들 수 있으며, IP 세트, 규칙 빌더, 규칙 그룹으로 나누어 생성한다.
    커스텀 규칙 설명
    IP 세트 특정 IP의 요청에 대한 허용 또는 차단 액션을 구현한다.
    규칙 빌더 헤더, 국가, IP 같은 검사 필드나 XSS, SQL 인젝션 같은 조건을 선택하고, 여러 조건을 AND·OR로 연결해 규칙 하나를 생성한다.
    규칙 그룹 작성한 규칙을 담는 독자적인 그룹으로, 사전에 만들고 등록해 설정한다.

    22-5 클라우드포메이션으로 AWS WAF 도입하기

    OAI로 S3를 지정한 클라우드프론트에 AWS WAF를 연결하고 Amazon IP reputation list, Known bad inputs, SQL database 세 가지 관리형 규칙을 적용하는 실습이다. 데이터베이스는 없지만 테스트 환경이므로 필수 규칙 항목인 SQL database도 추가한다. 스택은 WAF.yml → CloudFront.yml 순서로 생성한다.

    리소스 타입 주요 속성
    AWS::WAFv2::WebACL AWS WAF를 생성한다. DefaultAction으로 규칙에 해당하지 않는 요청의 허용·거부를 정하고, 클라우드프론트에 도입하므로 Scope에 CLOUDFRONT를 입력한다. VisibilityConfig로 클라우드워치 메트릭과 샘플링된 요청 정보 모니터링을 활성화하며, 샘플링은 필터링한 웹 요청 중 일부를 선택해 자세히 분석하는 기능이다.
    Rules 관리형 규칙을 추가한다. Priority로 우선순위를 정하며, 우선순위 순서로 일치하는 항목을 찾을 때까지 평가하고 없다면 DefaultAction에 따라 요청을 처리한다.
    AWS::WAFv2::LoggingConfiguration AWS WAF의 로그 저장소를 지정한다. ResourceArn에 WAF의 Arn을, LogDestinationConfigs에 로그를 저장할 S3 버킷의 Arn을 지정한다.

    여기서 짚고 넘어갈 점은 OverrideAction의 Count다. 관리형 규칙은 일치하는 항목이 있으면 요청을 차단하지만, Count를 지정하면 허용 또는 차단 동작을 무효화하고 해당 요청이 몇 번 발생하는지만 센다. 이를 통해 악의적인 트래픽이 얼마나 자주 발생하는지 모니터링하고, 자주 요청되는 공격은 차단하며 불필요한 규칙은 제거할 수 있다.

    또한 애플리케이션 로드 밸런서는 리전을 선택할 수 있지만 클라우드프론트는 리전이 버지니아 북부로 고정된 글로벌 서비스이므로, AWS WAF 스택도 반드시 버지니아 북부에서 생성해야 한다. 생성 후에는 WAF 콘솔의 [리소스 및 보호]에서 규칙과 로깅 설정을 확인할 수 있으며, 대시보드에서는 AWS Threat Intelligence가 2주간의 허용된 트래픽 패턴을 분석해 트래픽 특성, 규칙 특성, 봇, DDoS 방식 네 가지 범주의 지표를 제공한다. (AWS WAF 콘솔 UI는 2025년 6월 기준으로 변경되었으므로 이전 자료와 화면이 다를 수 있다.)

    23장. 네트워크 트래픽 로깅 서비스 파악하기

    VPC 플로우 로그는 VPC에서 전송되고 수신되는 트래픽에 대한 정보를 수집하는 기능이다. 사용자가 VPC를 거쳐 서브넷의 EC2 인스턴스에 접속하면, 그 결과를 하나의 로그로 가공해 아마존 S3나 클라우드워치 로그에 보존한다. 보존한 로그를 바탕으로 AWS에서 구축한 네트워크 구성이 의도한 대로 작동하는지 검토하고 분석할 수 있다.

    23-1 VPC 플로우 로그의 활용 목적

    • 보안 진단: 네트워크가 보안 요건대로 동작하는지 확인하거나 진단한다.
    • 네트워크 통신 문제 조사: 트래픽을 모니터링할 수 있으므로, 서버에 접속할 수 없는 경우 트래픽이 어디까지 도달하는지 확인해 통신 문제를 해결한다.
    • 위협 탐지: AWS 계정에서 악의적인 활동이 있는지 모니터링하는 아마존 가드듀티의 데이터 소스로 활용한다.

    23-2 VPC 플로우 로그 필드

    막상 취득한 로그를 살펴보면 값이 공백으로 나열되어 있어 각 필드가 무엇을 의미하는지 이해하기 어렵다. 필드의 의미를 알면 로그 데이터를 보다 효과적으로 분석하고 활용할 수 있다.

    필드 설명
    version VPC 플로우 로그 버전으로, 기본 형식이면 2가 출력되고 커스텀 형식이면 해당 버전이 표시된다.
    account-id 트래픽이 기록되는 네트워크 인터페이스의 12자리 AWS 계정 ID를 나타낸다.
    interface-id 트래픽이 기록되는 네트워크 인터페이스의 ID를 표시한다.
    srcaddr·dstaddr 트래픽이 시작된 소스 주소와 목적지 주소를 표시한다.
    srcport·dstport 트래픽이 시작된 소스 포트와 목적지 포트를 표시한다.
    protocol 인터넷 할당 번호 기구(IANA)가 할당한 프로토콜 식별 번호를 표시한다.
    packets·bytes 전송된 패킷 수와 바이트 수를 표시한다.
    start·end 첫 번째 패킷과 마지막 패킷이 수신된 시간을 UNIX초로 표시한다.
    action 트래픽이 허용되면 ACCEPT, 거부되면 REJECT가 표시된다.
    log-status 로그가 성공적으로 생성되면 OK, 트래픽이 없으면 NODATA, 트래픽은 있지만 로그 생성을 생략하면 SKIPDATA를 표시한다.

    보안 및 네트워크 트래픽 분석 관점에서는 각 필드를 다음과 같이 활용한다.

    • srcaddr, dstaddr: 비정상적인 IP나 악성 IP와의 통신, 내부 리소스 간 잘못된 통신 패턴을 확인한다.
    • srcport, dstport: 일반적이지 않은 포트 혹은 악성 포트를 확인한다.
    • protocol: 사용 중인 서비스에서 부적절한 프로토콜 사용을 감지한다.
    • action: 의심스러운 트래픽을 식별하거나 보안 그룹에서 거부된 트래픽을 분석한다.
    • bytes, packets: 비정상적으로 큰 데이터 전송이나 DDoS 공격 같은 비정상 트래픽을 식별한다.
    • start, end: 특정 시간대의 비정상적인 활동을 파악한다.

    23-3 클라우드포메이션으로 로그 수집하기

    EC2 인스턴스를 생성해 접속한 후, VPC 플로우 로그에서 생성된 로그를 확인하는 실습이다. VPC → 보안 그룹 → EC2 → CloudFront → VPC-Flow-Logs 순서로 스택을 생성하며, VPC-Flow-Logs 스택을 만들 때 VpcId 파라미터로 앞서 생성한 VPC를 선택하고 중복되지 않는 버킷 이름을 입력한다.

    • Type: AWS::EC2::FlowLog를 입력해 VPC 플로우 로그를 생성한다.
    • LogDestinationType·LogDestination: 로그를 보존할 리소스로 s3를 선택하고, 보존할 S3 버킷의 Arn을 지정한다.
    • ResourceId·ResourceType: 트래픽을 모니터링할 VPC를 지정한다. VPC 이외에도 NetworkInterface, Subnet, TransitGateway 등을 모니터링할 수 있다.
    • TrafficType: 허용된 트래픽만(ACCEPT), 모든 트래픽을(ALL), 거부된 트래픽만(REJECT) 모니터링할지 선택하며, 실습에서는 ALL로 설정한다.

    생성한 플로우 로그는 VPC 콘솔의 [플로우 로그] 탭에서 확인할 수 있으며, [대상 이름]을 클릭하면 로그가 보존된 S3 버킷으로 이동한다. 로그는 gz 파일로 압축되어 다운로드되므로 압축을 풀면 앞서 살펴본 필드 순서대로 기록된 트래픽을 확인할 수 있다. 로그가 수집되어 있지 않다면 EC2 인스턴스에 접속을 시도하거나 curl, sudo yum update -y 같은 명령어를 실행해 트래픽을 발생시킨다.

    24장. IP 주소를 관리하기 위한 서비스 파악하기

    관리형 접두사 목록은 하나 이상의 IP 주소가 포함된 IP 주소의 집합이다. IP 주소를 지정하는 보안 그룹과 라우팅 테이블에서 사용되며, 이를 활용해 보안 그룹과 라우팅 테이블을 보다 쉽게 구성하고 유지 관리할 수 있다.

    24-1 관리형 접두사 목록이 필요한 이유

    SSH 통신을 허용하는 IP 주소가 4개라면 보안 그룹에 4개의 규칙을 추가하면 된다. 하지만 IP 주소가 사용 환경에 따라 20개에서 30개, 그 이상으로 늘어나면 관리에 문제가 생긴다.

    • 복잡성: IP 주소마다 별도의 규칙을 추가해야 하므로 규칙 수가 늘어나면서 보안 그룹 구성이 복잡해진다.
    • 작업량: 여러 보안 그룹에 같은 변경 사항을 적용해야 할 경우 작업량이 급증한다.
    • 가시성: 많은 규칙으로 인해 전체 구성을 한눈에 파악하기 어려워진다.

    관리형 접두사 목록을 사용하면 허용하고자 하는 주소는 목록에서 관리하고, 보안 그룹에는 관리형 접두사 목록 단 하나의 규칙만 추가하면 된다. n개의 규칙이 하나로 줄어들므로 체계적인 관리와 확장성, 재사용성, 가독성 향상을 기대할 수 있다.

    24-2 고객 관리형 접두사 목록과 AWS 관리형 접두사 목록

    구분 설명
    고객 관리형 접두사 목록 사용자가 직접 IP 주소를 지정하고 관리하는 집합으로, 사용자가 직접 커스텀하고 생성 및 삭제할 수 있다.
    AWS 관리형 접두사 목록 AWS 서비스의 IP 주소 범위의 집합으로, AWS에서 생성하므로 사용자가 직접 커스텀하거나 수정, 삭제할 수 없다.

    사용 가능한 AWS 관리형 접두사 목록은 아마존 클라우드프론트, 아마존 다이나모DB, AWS 그라운드 스테이션, 아마존 라우트53, 아마존 S3, 아마존 S3 익스프레스 원 존, 아마존 VPC 래티스다. AWS 관리형 접두사 목록도 고객 관리형과 마찬가지로 보안 그룹과 라우팅 테이블에 사용할 수 있으며, 예를 들어 클라우드프론트에서 EC2로 접속하는 구성이라면 클라우드프론트의 접두사 목록을 사용해 접근을 제한할 수 있다.

    24-3 클라우드포메이션으로 접두사 목록 적용하기

    고객 관리형 접두사 목록을 생성하고 보안 그룹에 추가하는 실습이다. VPC → AWS_Managed_Prefix_List → Security_Group 순서로 스택을 생성하며, 별도의 파라미터 설정값이 없으므로 기본값을 유지한 채 생성한다.

    리소스 타입 주요 속성
    AWS::EC2::PrefixList 고객 관리형 접두사 목록을 생성한다. AddressFamily에 IPv4 혹은 IPv6의 주소 타입을, Entries에 관리할 IP 주소를 입력하며, MaxEntries로 목록에 추가할 최대 IP 주소 수를 지정한다. 실습에서 입력한 IP 주소는 테스트를 위한 임의의 주소다.
    SecurityGroupIngress 보안 그룹에서 허용할 IP 주소를 정의하는 속성으로, SourcePrefixListId에 고객 관리형 접두사 목록을 추가한다. 이로써 목록에 있는 IP 주소는 22번 포트로 접속할 수 있게 된다.

    생성 결과는 VPC 콘솔의 [관리형 접두사 목록]에서 확인할 수 있다. [항목]에서는 목록이 관리하는 IP 주소를, [연결]에서는 해당 목록을 사용하는 리소스를 확인한다. 보안 그룹의 인바운드 규칙을 보면 이전에는 4개의 IP 주소에 대해 각각 규칙을 설정해야 했으나, 이제는 단 하나의 규칙만으로 22번 포트를 관리할 수 있어 구성이 간편해지고 유지 관리가 쉬워진다.

     

    이 글은 『AWS 잘하는 개발자 되기』책을 학습한 내용을 정리한 것입니다.
    Comments