Red Hat Ansible Security Automation Guide

Red Hat Ansible Automation Platform 2.2

이 가이드에서는 Ansible을 사용하여 보안 이벤트를 식별하고 분류하고 대응하는 데 필요한 다양한 보안 프로세스를 자동화하고 스트리밍하는 절차를 제공합니다.

Red Hat Customer Content Services

초록

피드백 제공:
이 문서를 개선하거나 오류를 찾을 수 있는 제안이 있는 경우 문서 구성 요소를 사용하여 Ansible Automation Platform Jira 프로젝트에 문제를 생성하기 위해 에서 https://access.redhat.com 기술 지원에 문의하십시오.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 용어를 교체하기 위해 최선을 다하고 있습니다. 먼저 마스터(master), 슬레이브(slave), 블랙리스트(blacklist), 화이트리스트(whitelist) 등 네 가지 용어를 교체하고 있습니다. 이러한 변경 작업은 작업 범위가 크므로 향후 여러 릴리스에 걸쳐 점차 구현할 예정입니다. 자세한 내용은 CTO Chris Wright의 메시지를 참조하십시오.

1장. Ansible 보안 자동화를 통한 방화벽 정책 관리

보안 운영자는 Ansible 보안 자동화를 사용하여 여러 방화벽 정책을 관리할 수 있습니다. 소스 IP 주소가 대상 IP 주소에 액세스하는 것을 차단하거나 차단 해제하는 방화벽 규칙을 생성 및 삭제합니다.

1.1. 방화벽 정책 관리 정보

조직의 네트워크 방화벽은 보안 환경을 유지하기 위한 공격 및 중요한 구성 요소에 대한 첫 번째 위협 라인입니다. 보안 운영자는 보안 네트워크를 구성하고 관리하여 방화벽이 조직의 방화벽 정책에 정의된 인바운드 및 아웃바운드 네트워크 트래픽만 허용하도록 합니다. 방화벽 정책은 수신 및 발신 트래픽으로부터 네트워크를 보호하는 보안 규칙으로 구성됩니다.

다양한 제품 및 공급업체에서 여러 방화벽 규칙을 관리하는 것은 보안팀에서 어려움과 시간이 걸릴 수 있습니다. 복잡한 작업을 포함하는 수동 워크플로 프로세스로 인해 오류가 발생할 수 있으며 궁극적으로 애플리케이션의 의심 스러운 동작을 조사하거나 서버의 지속적인 공격을 중지하는 데 지연이 발생할 수 있습니다. 동일한 언어를 통해 보안 포트폴리오의 모든 솔루션을 자동화할 때 보안 애널리스트와 운영자 모두 일정 기간 내에 다양한 제품에 걸쳐 일련의 작업을 수행할 수 있습니다. 이 자동화된 프로세스는 보안 팀의 전반적인 효율성을 극대화합니다.

Ansible 보안 자동화는 다양한 공급 업체의 다양한 보안 기술과 상호 작용합니다. Ansible을 사용하면 보안 팀에서 다양한 제품, 인터페이스 및 워크플로우를 통합된 방식으로 관리하여 성공적인 배포를 생성할 수 있습니다. 예를 들어 보안 팀은 엔터프라이즈 방화벽과 같이 지원되는 기술의 IP 및 URL 차단 해제와 같은 작업을 자동화할 수 있습니다.

1.2. 방화벽 규칙 자동화

Ansible 보안 자동화를 사용하면 다양한 제품에 걸쳐 일련의 작업이 필요한 다양한 방화벽 정책을 자동화할 수 있습니다. acl_manager 역할과 같은 Ansible 역할을 사용하여 IP 또는 URL 차단 또는 차단 해제와 같은 여러 방화벽 장치에 대한 ACL(액세스 제어 목록)을 관리할 수 있습니다. 역할을 사용하면 알려진 파일 구조를 기반으로 관련 vars, 파일, 작업, 핸들러 및 기타 Ansible 아티팩트를 자동으로 로드할 수 있습니다. 역할에서 콘텐츠를 그룹화한 후 쉽게 재사용하고 다른 사용자와 공유할 수 있습니다.

아래 랩 환경은 더 복잡하고 추가 벤더별 툴을 포함할 수 있는 실제 엔터프라이즈 보안 아키텍처의 단순화된 예입니다. 이는 침입 경고를 수신하고 공격자의 IP 주소를 차단하는 acl_manger 역할을 사용하여 플레이북을 즉시 실행하는 일반적인 사고 대응 시나리오입니다.

전체 팀은 Ansible 보안 자동화를 사용하여 조사, 위협 인식 및 사고 대응 모두를 하나의 플랫폼에서 해결할 수 있습니다. Red Hat Ansible Automation Platform 은 보안 팀 내에서 쉽게 사용하고 재사용할 수 있는 인증된 컨텐츠 컬렉션을 제공합니다.

간소화된 보안 랩 환경

추가 리소스

Ansible 역할에 대한 자세한 내용은 docs.ansible.com에 대한 역할을 참조하십시오.

1.2.1. 새 방화벽 규칙 생성

acl_manager 역할을 사용하여 소스 IP 주소가 대상 IP 주소에 액세스하지 못하도록 하는 새 방화벽 규칙을 생성합니다.

사전 요구 사항

  • Ansible 2.9 이상이 설치되어 있어야 합니다.
  • Check Point Management 서버에 액세스하여 새 정책을 적용할 수 있습니다.

절차

  1. ansible-galaxy 명령을 사용하여 acl_manager 역할을 설치합니다. 

    $ ansible-galaxy install ansible_security.acl_manager

  2. 새 플레이북을 생성하고 다음 매개 변수를 설정합니다. 예를 들어, 소스 개체, 대상 개체, 두 개체 간의 액세스 규칙 및 관리 중인 실제 방화벽 간의 액세스 규칙 (예: Check Point) 

    - name: block IP address
  hosts: checkpoint
  connection: httpapi

  tasks:
    - include_role:
        name: acl_manager
        tasks_from: block_ip
      vars:
        source_ip: 172.17.13.98
        destination_ip: 192.168.0.10
        ansible_network_os: checkpoint

  3. 플레이북 $ ansible-navigator run --ee false <playbook.yml>을 실행합니다.

    새 방화벽 규칙이 있는 플레이북

검증

소스 IP 주소가 대상 IP 주소에 액세스하지 못하도록 하는 새 방화벽 규칙이 생성되었습니다. MGMT 서버에 액세스하여 새 보안 정책이 생성되었는지 확인합니다.

추가 리소스

역할 설치에 대한 자세한 내용은 Galaxy에서 역할 설치를 참조하십시오.

1.2.2. 방화벽 규칙 삭제

acl_manager 역할을 사용하여 보안 규칙을 삭제합니다.

사전 요구 사항

  • Ansible 2.9 이상이 설치되어 있어야 합니다.
  • 방화벽 MGMT 서버에 액세스하여 새 정책을 시행합니다.

절차

  1. ansible-galaxy 명령을 사용하여 acl_manager 역할을 설치합니다. 

    $ ansible-galaxy install ansible_security.acl_manager

  2. CLI를 사용하여 acl_manger 역할로 새 플레이북을 생성하고 매개변수(예: 소스 오브젝트, 대상 오브젝트, 두 오브젝트 간 액세스 규칙)를 설정합니다. 

    - name: delete block list entry
  hosts: checkpoint
  connection: httpapi

    - include_role:
        name: acl_manager
        Tasks_from: unblock_ip
      vars:
        source_ip: 192.168.0.10
        destination_ip: 192.168.0.11
        ansible_network_os: checkpoint

  3. 플레이북 $ ansible-navigator run --ee false <playbook.yml>을 실행합니다.

    삭제된 방화벽 규칙이 있는 플레이북

검증

방화벽 규칙을 삭제했습니다. MGMT 서버에 액세스하여 새로운 보안 정책이 제거되었는지 확인합니다.

추가 리소스

역할 설치에 대한 자세한 내용은 Galaxy에서 역할 설치를 참조하십시오.

2장. Ansible을 사용하여 네트워크 침입 탐지 및 예방 시스템 자동화

Ansible을 사용하여 IDPS(Intrusion Detection and Prevention System)를 자동화할 수 있습니다. 이 가이드의 목적을 위해 Snort를 IDPS로 사용합니다. Ansible 자동화 허브를 사용하여 자동화된 워크플로우를 생성하기 위해 작업, 역할 및 모듈과 같은 콘텐츠 컬렉션을 사용합니다.

2.1. 요구 사항 및 사전 요구 사항

Ansible을 사용하여 IDPS 자동화를 시작하기 전에 IDPS를 성공적으로 관리하는 데 필요한 적절한 설치 및 구성이 있는지 확인하십시오.

  • Ansible 2.9 이상을 설치했습니다.
  • SSH 연결 및 키가 구성됩니다.
  • IDPS 소프트웨어(Snort)가 설치 및 구성되어 있습니다.
  • 새 정책을 적용하려면 IDPS 서버(Snort)에 액세스할 수 있습니다.

2.1.1. IDPS 설치 확인

추가 리소스

Snort가 성공적으로 구성되었는지 확인하려면 sudo 를 통해 전화하고 버전을 요청하십시오. 

  $ sudo snort --version

   ,,_     -*> Snort! <*-
  o"  )~   Version 2.9.13 GRE (Build 15013)
  ""    By Martin Roesch & The Snort Team: http://www.snort.org/contact#team
        Copyright (C) 2014-2019 Cisco and/or its affiliates. All rights reserved.
        Copyright (C) 1998-2013 Sourcefire, Inc., et al.
        Using libpcap version 1.5.3
        Using PCRE version: 8.32 2012-11-30
        Using ZLIB version: 1.2.7

sudo systemctl 을 통해 서비스가 적극적으로 실행되고 있는지 확인합니다. 

$ sudo systemctl status snort
● snort.service - Snort service
   Loaded: loaded (/etc/systemd/system/snort.service; enabled; vendor preset: disabled)
   Active: active (running) since Mon 2019-08-26 17:06:10 UTC; 1s ago
  Main PID: 17217 (snort)
   CGroup: /system.slice/snort.service
           └─17217 /usr/sbin/snort -u root -g root -c /etc/snort/snort.conf -i eth0 -p -R 1 --pid-path=/var/run/snort --no-interface-pidfile --nolock-pidfile
[...]

Snort 서비스가 적극적으로 실행되지 않으면 systemctl restart snort 로 다시 시작한 후 상태를 다시 확인합니다.

서비스가 현재 실행되고 있는지 확인한 후 CTRL 및 D 를 동시에 누르거나 명령줄에서 exit 를 입력하여 Snort 서버를 종료합니다. 모든 추가 상호 작용은 Ansible 제어 호스트에서 Ansible을 통해 수행됩니다.

2.2. Ansible을 사용하여 IDPS 규칙 자동화

IDPS를 자동화하려면 ids_rule 역할을 사용하여 Snort 규칙을 생성하고 변경합니다. snort는 네트워크 트래픽을 분석하고 지정된 규칙 세트와 비교하는 규칙 기반 언어를 사용합니다.

다음 랩 환경은 Ansible 보안 자동화 통합의 방식을 보여줍니다. "Attacker"라는 시스템은 IDPS가 실행 중인 대상 시스템에서 잠재적인 공격 패턴을 시뮬레이션합니다.

실제 설정에는 다른 공급업체 및 기술이 포함되어 있습니다.

Ansible 보안 자동화 통합 샘플

2.2.1. 새 IDPS 규칙 생성

추가 리소스

ids_rule 역할을 사용하여 IDPS에 대한 규칙과 서명을 관리합니다. 예를 들어 방화벽에 대한 이전 공격과 일치하는 특정 패턴을 찾는 새 규칙을 설정할 수 있습니다.

참고

현재 ids_rule 역할은 Snort IDPS만 지원합니다.

사전 요구 사항

  • Snort 서버를 변경하려면 root 권한이 필요합니다.

절차

  1. ansible-galaxy 명령을 사용하여 ids_rule 역할을 설치합니다. 

    $ ansible-galaxy install ansible_security.ids_rule

  2. add_snort_rule.yml 이라는 새 플레이북 파일을 만듭니다. 다음 매개변수를 설정합니다. 

    - name: Add Snort rule
  hosts: snort

  3. become 플래그를 추가하여 Ansible이 권한 에스컬레이션을 처리하는지 확인합니다. 

    - name: Add Snort rule
  hosts: snort
  become: true

  4. 다음 변수를 추가하여 IDPS 공급자의 이름을 지정합니다. 

    - name: Add Snort rule
  hosts: snort
  become: true

  vars:
    ids_provider: snort

  5. 플레이북에 다음 작업 및 작업별 변수(예: 규칙, Snort 규칙 파일 및 규칙 상태 - 현재 또는 absent)를 추가합니다. 

    - name: Add Snort rule
  hosts: snort
  become: true

  vars:
    ids_provider: snort

  tasks:
    -  name: Add snort password attack rule
       include_role:
         name: "ansible_security.ids_rule"
       vars:
         ids_rule: 'alert tcp any any -> any any (msg:"Attempted /etc/passwd Attack"; uricontent:"/etc/passwd"; classtype:attempted-user; sid:99000004; priority:1; rev:1;)'
         ids_rules_file: '/etc/snort/rules/local.rules'
         ids_rule_state: present

    Tasks는 대상 머신을 변경하는 구성 요소입니다. 이러한 작업을 정의하는 역할을 사용하므로 include_role 이 필요한 유일한 항목입니다.

    ids_rules_file 변수는 local.rules 파일에 대해 정의된 위치를 지정하는 반면, ids_rule_state 변수는 규칙이 존재하지 않는 경우 생성되어야 함을 나타냅니다.

  6. 다음 명령을 실행하여 플레이북을 실행합니다. 

    $ ansible-navigator run add_snort_rule.ym --mode stdout

    Playbook을 실행하면 새로 생성된 규칙 외에도 모든 작업이 실행됩니다. 플레이북 출력은 PLAY, TASK, RUNNING HANDLER 및 PLAY RECAP을 확인합니다.

검증

IDPS 규칙이 성공적으로 생성되었는지 확인하려면 SSH를 사용하여 Snort 서버에 연결하고 /etc/snort/rules/local.rules 파일의 내용을 확인합니다.

법적 공지

Copyright © 2023 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.