Pixi-CRS가 클라우드로 이동 - 3부: Microsoft Azure DevOps

Pixi-CRS를 옮긴 두 번째 클라우드 공급자는 Microsoft Azure DevOps: https://dev.azure.com/ 입니다.

이것은 "Pixi-CRS가 클라우드로 이동"시리즈의 세 번째 블로그 게시물입니다.

Pixi-CRS가 Microsoft Azure DevOps 파이프라인에서 보이는 방식은 다음과 같습니다.



위 이미지에서 Azure DevOps의 Pixi-CRS CI 파이프라인이 Azure DevOps > Pixi-CRS > 파이프라인으로 구성되어 있음을 알 수 있습니다.

Pixi-CRS 파이프라인 코드

파이프라인 뒤의 코드를 찾을 수 있습니다here.
Azure DevOps 파이프라인 코드는 리포지토리의 루트 디렉터리에 있는 azure-pipeline.yml 파일에 작성됩니다. Azure DevOps에서 새 파이프라인 프로젝트를 만드는 것은 매우 쉽습니다.

이 azure-pipelines.yml 파일을 자세히 살펴보겠습니다.

아래에서 다른 단계를 설명하겠습니다. 그러나 제공된 yaml 파일의 주석에서도 설명을 제공합니다.

# Azure DevOps azure-pipelines.yml

trigger:
# Branch to trigger
- master

stages:

# Start the OWASP ModSecurity Core Rule Set and Pixi with its DB with docker-compose
# OWASP ModSecurity Core Rule Set Container (Apache Reverse Proxy)
# owasp/modsecurity-crs
# See https://coreruleset.org/
# ModSecurity Tuning:
# See https://www.netnea.com/cms/apache-tutorial-8_handling-false-positives-modsecurity-core-rule-set/
- stage: StartContainersAndTests
  jobs:
  - job: BuildJob
    steps:
      # Debugging
      # - script: pwd
      # - script: ls
      - task: DockerCompose@0
        displayName: Start Pixi and CRS
        inputs:
          containerregistrytype: 'Container Registry'
          dockerComposeFile: '**/docker-compose.yaml'
          action: 'Run a Docker Compose command'
          dockerComposeFileArgs: |
            CRSPORTHTTP=8080
            PROXYLOCATION=http://app:8000/
          dockerComposeCommand: 'up -d'

      # Application Tests with Testcafe
      # skip-js-errors because of: Uncaught Error: Bootstrap tooltips require Tether
      # Another way: https://devexpress.github.io/testcafe/documentation/continuous-integration/azure-devops.html
      # Debugging
      #- script: docker ps
      - script: docker run --volume /home/vsts/work/1/s/testcafe/tests_container_ip/:/tests testcafe/testcafe --skip-js-errors 'chromium:headless --no-sandbox'
        displayName: Run Testcafe Tests without and with CRS

      # Show Full error.log
      - script: docker exec crs cat /var/log/apache2/error.log
        displayName: Show ModSecurity logs

      # ModSecurity Log Analysis:
      # Fail if ModSecurity log is not empty
      # Show ModSecurity logs of Testcafe Tests
      # If not empty -> Repair your application OR
      #              -> ModSecurity Tuning:
      # See https://www.netnea.com/cms/apache-tutorial-8_handling-false-positives-modsecurity-core-rule-set/ OR
      #              -> GitHub issue: https://github.com/SpiderLabs/owasp-modsecurity-crs
      - script: if docker exec crs cat /var/log/apache2/error.log | grep ModSecurity | grep -vi MyEvilWAFTest | grep -v 949110 | grep -v 980130 | grep msg; then echo "False Positive Found! Aborting!" && exit 1 ; else echo "ModSecurity Logs empty. This is good!"; fi
        displayName: Fail if ModSecurity logs are not empty

      # Fail if ModSecurity log does not contain WAF Test String "MyEvilWAFTest"
      # That means CRS is not working properly or test was aborted.
      - script: if docker exec crs cat /var/log/apache2/error.log | grep ModSecurity | grep MyEvilWAFTest; then echo "WAF Test String Found. This is good!"; else echo "WAF Test String not Found! Aborting!" && exit 1; fi
        displayName: Fail if WAF Test String is missing in ModSecurity logs

파이프라인 단계

Pixi 및 CRS 시작

하나의 docker-compose up 명령으로 Pixi와 CRS를 시작합니다. Docker 또는 docker-compose를 설치할 필요가 없으며 이미 제공됩니다. 그러나 예를 들어 dockerComposeFileArgs와 같은 몇 가지 항목을 구성해야 합니다.
그런 다음 dockerComposeCommand "up -d"로 Pixi와 CRS를 시작합니다.

테스트카페 테스트

이제 CRS와 Pixi가 실행 중이므로 Testcafe 테스트를 수행합니다. 이번에는 testcafe/testcafe Docker 컨테이너로 테스트를 실행할 수 있습니다. 테스트는 이 컨테이너에 쉽게 탑재할 수 있습니다.
다시 말하지만 먼저 Pixi를 직접 테스트한 다음 CRS를 통해 Pixi를 테스트합니다. 또한 악성 문자열로 CRS 자체를 테스트합니다. 우리는 WAF가 이를 차단하는지 확인하고 싶습니다.

테스트의 경우 Testcafe Docker 컨테이너 내부에서 호출하기 때문에 http://172.17.0.1:8000을 통해 Pixi를 호출하고 http://172.17.0.1:8080을 통해 CRS를 호출합니다.

Testcafe 테스트 결과는 다음과 같습니다.

결과 확인

결국 결과를 확인합니다. CRS Docker 컨테이너 내부의 ModSecurity 로그를 살펴봅니다.
이는 합법적인 테스트에서 오탐지가 발생하지 않았음을 확인하는 중요한 단계입니다. 또한 악의적인 테스트가 기록되었는지 확인합니다.

방아쇠

Pixi-CRS는 CI 파이프라인이고 리포지토리에 푸시할 때마다 Azure DevOps 파이프라인 프로젝트를 실행하려고 하므로 푸시 이벤트에 대한 트리거를 구성해야 합니다.
azure-pipeline.yml 파일의 "trigger: -master"항목을 통해 이를 추가했습니다.

언급할 사항

Pixi-CRS는 CI 파이프라인이고 CD 부분은 제가 설정하지 않았습니다.
이번 블로그 포스트에서는 CI 부분만 보여드리고자 했습니다. 또한 훨씬 더 많은 Azure DevOps 옵션을 사용할 수 있다는 것도 알고 있습니다. 하지만 이 블로그 게시물에서는 간단하게 유지하고 Pixi-CRS CI 부분에 집중하고 싶었습니다.

다음 블로그 게시물

다음 블로그 게시물에서는 Google Cloud Platform에서 Pixi-CRS 파이프라인에 대해 알아봅니다.