创建你的RedTeam基础架构

随着RedTeaming行业的发展，我们对构建可靠环境的需求也越来越高。至关重要的是要拥有维护健壮的基础架构的能力，该基础架构要保证一旦出现问题就可以重新创建，更重要的是，我们需要确保环境在部署时不会出现问题。

 

今天，我开始发布一系列文章中的第一篇，我们将采用DevOps团队流行的一些做法，并希望使用这些技术来帮助我们构建稳定且经过测试的基础架构。在本文中，我将快速回顾一下如何在代码中定义RedTeam基础架构，这些代码放在Git仓库中。但是，更重要的是，我们将继续研究环境不断变化和复杂性增加的测试方法，并逐步介绍如何将CI管道引入混合流程以帮助实现此测试的自动化。

管理我们的基础架构

长期以来，典型的RedTeam基础架构部署的构建都使用redirectors的概念进行了标准化。最基本的C2部署如下所示：

到目前为止，我们都了解了在选择C2框架之前使用重定向器的优势，使我们能够通过团队服务器控制客户敏感数据，并掩盖了真正的流量来源，同时允许快速重新创建这些一次性重定向器而无需需要拆除后端服务器。

那么，这一切如何管理？多年来，我已经看到了许多种不同的方式来部署环境。最常见的设置是手动部署每个组件的位置。对于AWS用户，这意味着需要通过管理控制台来创建EC2实例，通过SSH进入，为反向隧道配置SSH等。当然，一旦BlueTeam找到重定向器，实例就会被拆除，然后我就要重新配置新实例，依此类推...

这显然很烦人且容易出错，因此诞生自动化RedTeam基础架构部署的想法。我将从aws或az shell命令包装到脚本中，再到通过配置文件使用Terraform管理环境。

但是，在开始测试基础架构之前，我们实际上需要一些基础架构进行测试。

Terraform

首先，我们将专注于创建容纳我们资源的基础结构的过程。可能许多人都熟悉Terraform，它是Hashicorp的工具，Terraform允许您在云服务（例如AWS，Azure和DigitalOcean）上创建，更新和销毁基础架构。基础结构在HCL脚本中进行了描述，并在进行了设计之后，我们将其交给Terraform及其提供者来“ 实现 ”。

出于本文的目的，我们将创建一个非常简单的环境，其中包含2个充当重定向器的EC2实例。用于执行此操作的Terraform脚本通常如下所示：

provider "aws" {
  region = "eu-west-2"
}
variable "INSTANCE_NAMES" {
  default = {
    "0" = "Redirector-ShortHaul"
    "1" = "Redirector-LongHaul"
  }
}
variable "PUBLIC_KEY" {
  default = "./keys/terraformkey.pub"
}
variable "MANAGEMENT_IP" {
  default = "1.2.3.4/32"
}
resource "aws_key_pair" "terraformkey" {
  key_name   = "${terraform.workspace}-terraform-key"
  public_key = file("${var.PUBLIC_KEY}")
}
resource "aws_security_group" "redirector-sg" {
  name = "redirector-sg"
  # Allow HTTP inbound
  ingress {
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
    from_port   = 80
    to_port     = 80
  }
  # Allow HTTPS inbound
  ingress {
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
    from_port   = 443
    to_port     = 443
  }
  # Allow management from our management IP
  ingress {
    protocol    = "tcp"
    cidr_blocks = ["${var.MANAGEMENT_IP}"]
    from_port   = 22
    to_port     = 22
  }
  # Allow global outbound
  egress {
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
    from_port   = 0
    to_port     = 0
  }
}
data "aws_ami" "ubuntu" {
  most_recent = true
  filter {
    name   = "name"
    values = ["ubuntu/images/hvm-ssd/ubuntu-bionic-18.04-amd64-server-*"]
  }
  filter {
    name   = "virtualization-type"
    values = ["hvm"]
  }
  owners = ["099720109477"]
}
resource "aws_instance" "redirector" {
  ami           = data.aws_ami.ubuntu.id
  instance_type = "t2.micro"
  count         = length(var.INSTANCE_NAMES)
  key_name      = aws_key_pair.terraformkey.key_name
  vpc_security_group_ids = [
    "${aws_security_group.redirector-sg.id}",
  ]
  tags = {
    Name    = "${var.INSTANCE_NAMES[count.index]}"
    JobName = "${terraform.workspace}"
  }
}
output "redirector_ips" {
    description = "Public IP addresses of created redirectors"
    value = aws_instance.redirector.*.public_ip
}

为了确保我们可以运行基础架构的多个实例并且不会与其他参与资源冲突，我们通常通过以下方式创建新的Terraform工作空间：

terraform workspace new InsecureBank

但是在部署之前，让我们通过执行terraform plan来测试一切是否正常：

一旦我们对所有内容进行了检查，就可以移至terraform apply命令：

Terraform完成后，我们可以查询AWS并验证是否已创建服务器：

aws ec2 describe-instances --query 'Reservations[].Instances[].[Tags[?Key==`Name`].Value,InstanceType,PublicIpAddress]' --output json

接下来我们需要配置它们。这里不需要使用SSH，无需手动配置任何内容。相反，让我们看一下如何使这一步骤自动化。

Ansible

尽管有诸如Chef和Puppet之类的其他工具，但是Ansible仍然是我最喜欢的工具之一

因此，我们知道现在有2台在线服务器要配置。我们也知道它们的功能将是相同的，这意味着一个写得很好的Ansible脚本应该能够应用于每个环境。

让我们从创建工作区开始。我发现以下布局对此类项目很有用：

.
├── ansible.cfg
├── playbooks
│   └── 10_example.yml
├── roles
│   ├── requirements.yml
│   └── ubuntu-nginx
│       ├── ...
└── site.yml

这种布局的想法是提供存储我们的脚本和角色的位置，同时包括一个Ansible配置文件，该文件将提供存储规则的位置。

我尝试坚持创建Ansible角色来封装相似的配置区域，例如，对于这样的项目，我们将为以下区域创建单独的角色：

加强基础安装

安装Nginx以公开HTTP（S）C2

配置SSH以从我们的团队服务器进行访问

添加任何日志记录功能

显然，您可以根据需要自定义重定向器，但是在此示例中，我们将重点放在Web服务器角色上。我们的角色将非常简单，并涉及以下任务：

确保添加了所需的用户和组

安装NGINX

通过配置文件配置NGINX以进行反向代理

综上所述，我们的Ansible角色YAML可能看起来像这样：

---
- name: Ensure group "nginx" exists
  group:
    name: nginx
    state: present
- name: Add the user nginx
  user:
    name: nginx
    shell: /bin/nologin
    groups: nginx
- name: Install NGINX
  apt:
    name: nginx
    state: present
    update_cache: yes
- name: Add NGINX configuration from template
  template:
    src: default.conf.j2
    dest: /etc/nginx/conf.d/default.conf
    owner: root
    group: root
    mode: 0644
  notify: restart nginx

在这里，我们采取了一些简单的步骤来添加我们的nginx用户，安装NGINX并添加从模板制作的配置文件。我们可以使用脚本来应用它，例如：

---
 - hosts: redirector*
   become: yes
   gather_facts: no
   pre_tasks:
        - raw: test -e /usr/bin/python || (apt -y update && apt install -y python-minimal)
        - setup: # aka gather_facts
   roles:
        - redirector-nginx

构建角色和脚本后，通过terraform-inventory工具可以轻松地将Ansible角色应用于重定向器的过程，该工具使我们能够解析Terraform状态文件并动态构建Ansible库存。例如，通过上面的Ansible项目，我们可以使用以下方法来应用角色：

TF_STATE=../terraform ansible-playbook --inventory-file=/usr/local/bin/terraform-inventory -u ubuntu --private-key ../terraform/keys/terraformkey site.yml

我们将要测试两个方面。首先将是我们的Ansible角色，负责实际配置重定向器。第二个将是包含重定向器的AWS基础架构的部署，以及部署后实际AWS重定向器的状态。

使用Molecule测试Ansible

建立Ansible可能会很难，对我们来说幸运的是，有工具可以帮助测试Ansible，这也使我们可以从提高的开发速度。为此，我们将使用一个名为Molecule的框架。这个框架已经存在了一段时间，并且实质上允许您隔离地部署Ansible角色（例如，在Docker容器内），并在应用角色后使用TestInfra测试容器的状态。

首先，我们需要使用pip安装Molecule：

# Create our venv
python -m venv env
source ./env/bin/activate
# Install molecule
pip install --user molecule

安装完成后，我们将为Ansible角色构建一些测试。Molecule使用“scenarios”的概念来描述测试用例的**。让我们使用以下方法创建默认场景以测试NGINX角色：

cd rolename; molecule init scenario -r rolename

我们看一下内部，将会看到类似以下的内容：

.
└── default
    ├── Dockerfile.j2
    ├── INSTALL.rst
    ├── molecule.yml
    ├── playbook.yml
    └── tests
        ├── test_default.py
        └── test_default.pyc

对于这种情况，我们的测试将添加到test_default.py Python脚本中，并将使用TestInfra框架。但是在开始之前，我们应该花一些时间通过Molecular.yml文件配置场景。由于我通常偏爱基于Ubuntu的服务器，因此我想确保测试在相似的环境中运行。为此，我们只需将“平台”部分更新为：

platforms:
  - name: instance
    image: ubuntu:18.04

接下来，让我们创建一些简单的测试来展示此框架的功能。我们知道此角色将部署NGINX，因此，作为一个很好的起点，我们可以进行测试以确保在我们的角色运行后实际安装了NGINX，如下所示：

def test_nginx_installed(host):
    nginx = host.package("nginx")
    assert nginx.is_installed

我们还想确保在应用角色时NGINX实际上正在运行：

def test_nginx_running(host):
    nginx = host.service("nginx")
    assert nginx.is_running

带有反向代理信息的自定义配置又如何呢？好吧，让我们添加一些检查以确保一旦应用角色，我们的配置实际上就存在：

def test_nginx_configuration(host):
    passwd = host.file("/etc/nginx/conf.d/default.conf")
    assert passwd.contains("proxy_pass")
    assert passwd.user == "nginx"
    assert passwd.group == "nginx"
    assert passwd.mode == 0o644

将此添加到我们的Molecule测试用例后，让我们开始快速测试以确保所有功能都适用：

molecule test

现在，在我们的情况下，我们可能会看到以下内容：

这意味着测试失败了，因为我们的NGINX配置文件是root拥有的，并且我们的测试正在寻找nginx的用户，所以让我们更新测试以反映这一点：

def test_nginx_configuration(host):
    passwd = host.file("/etc/nginx/conf.d/default.conf")
    assert passwd.contains("proxy_pass")
    assert passwd.user == "root"
    assert passwd.group == "root"
    assert passwd.mode == 0o644

希望当我们重新运行测试时，我们将看到如下所示：

在我们继续测试Ansible角色之前，值得一提的是在开发工作流程中使用Molecule的另一个优势。我发现，使用Ansible开发的痛苦之一是您必须进行许多调整才能使工作按预期进行，然后清理环境并重复进行。幸运的是，Molecule公开了Molecular converge命令，该命令使您可以在不运行任何测试的情况下将Ansible角色应用于Docker容器。这意味着您可以继续将角色应用于容器，以确保其在开发过程中按预期进行。

InSpec

InSpec是Chef的创造者提供的一个很棒的工具，它使我们能够根据所需状态测试已部署的基础架构。从可用的CIS基准测试到验证某个环境中已修补了漏洞，InSpec有许多用途。我们想使用InSpec来确保我们部署的基础架构满足许多简单的要求：

1.我们只公开HTTP和HTTPS端口吗？

2.SSH是否可用于我们的管理IP？

3.NGINX是否已在两个重定向器上启动并运行？

4.我们的反向代理配置是否应用于重定向器？

在确定了这些简单的测试用例之后，让我们创建一组InSpec测试以验证我们部署的基础架构是否符合我们的期望。

首先，我们需要初始化我们的AWS测试，我们可以使用以下方法进行测试：

inspec init profile --platform aws aws_tests

这将创建一个模板，其布局如下：

.
├── README.md
├── attributes.yml
├── controls
│   └── example.rb
├── inspec.lock
└── inspec.yml

在本文中，我们将使用example.rb来介绍Terraform构建的AWS环境的一些测试。

如果我们专注于确保重定向器处于联机状态，并且我们的安全组仅公开公开HTTP/S，而隐藏SSH，则最终会出现一系列测试用例，例如：

title "AWS"
describe aws_ec2_instance(name: 'Redirector-LongHaul') do
  it { should exist }
end
describe aws_ec2_instance(name: 'Redirector-ShortHaul') do
  it { should exist }
end
describe aws_security_group(group_name: 'redirector-sg') do
  it { should exist }
  it { should allow_in(port: 80, ipv4_range: '0.0.0.0/0') }
  it { should allow_in(port: 443, ipv4_range: '0.0.0.0/0') }
  it { should allow_in(port: 22, ipv4_range: '1.2.3.4/32') }
end

确保通过aws configure命令或环境变量配置了您的AWS配置文件，并且我们可以使用我们的默认配置文件运行InSpec测试，其中包括：

cd test-aws; inspec exec . -t aws://

希望一切顺利，我们应该看到我们收到了InSpec的确认，确认所有内容都输出：

但是我们的重定向器配置又如何呢？我们怎么知道我们的Ansible角色实际上已被应用？这很容易检查，我们可以使用以下方法创建模板：

inspec init profile redirectors

并添加一些测试用例，类似于上面的测试：

title "Service Config"
describe service('nginx') do
  it { should be_installed }
  it { should be_enabled }
  it { should be_running }
end
describe service('ssh') do
  it { should be_installed }
  it { should be_enabled }
  it { should be_running }
end
describe file('/etc/nginx/conf.d/default.conf') do
    its('content') { should match %r{proxy_pass } }
end

并通过以下方式运行：

inspec exec . -t ssh://ubuntu@HOST -i ./keys/remotekey

这里有一个与我们的预期测试不匹配的NGINX配置文件的示例。快速修复Ansible角色或InSpec测试，我们应该看到所有内容都可以输出：

太好了，让我们确认到目前为止的内容...我们拥有可创建基础架构的Terraform脚本。我们有Ansible脚本和角色，可以提供重定向程序。我们进行了分子测试，以使我们能够快速开发和验证我们的角色，最后，我们进行了InSpec测试，以确保完全按照我们的期望来创建基础架构。

将管道和内容联动

我们现在可以解决所有问题，并且我们相信我们的角色和基础架构将按期望的方式工作。但是，我们如何确保每次有人对这些组件中的任何一个进行更改时，下次我们启动或重新启动环境时，一切都能顺利运行？在开发环境中，CI已成为控制代码的有用实践。通过强制在推送到Git服务器时运行测试，我们可以确保将代码更改合并到Master中不会在下次部署时造成中断。

为了创建我们的CI管道，我们将使用Gitlab，这是我当前选择的托管Git服务器。Gitlab不仅是托管我们的Git仓库的好地方，而且还充当CI / CD平台，使我们能够通过Gitlab Runners执行测试，构建和部署。

那么CI到底是什么？CI的意思是“持续集成”，这是一种通过大量自动化测试不断将开发人员所做的更改合并到稳定分支中的实践，以确保推送的提交不会破坏任何内容。这个想法是，通过使用测试在合并期间保持质量水平。

为了将测试的每个阶段联系在一起，我们需要在gitlab-ci.yml文件中描述每个阶段，该文件位于项目的根目录中。这将使我们能够构建流水线，可用于通过Git推送进行测试，过渡到暂存环境，并通过一系列验证步骤来确保基础结构完全符合我们的期望。

我们管道的每个阶段将定义为：

测试–通过Molecule测试Ansible

测试– Terraform HCL验证

阶段–部署到测试环境

预配–使用Ansible预配已部署的服务器

验证–测试环境的InSpec验证

清理–拆除基础设施

让我们从定义各个管道阶段开始，将每个阶段分解为如何在gitlab-ci.yml文件中表示：

stages:
  - test
  - stage
  - provision
  - validate
  - cleanup

在这里，我们定义了管道的每个阶段，我们可以将它们匹配到上面定义的步骤。接下来，我们需要从Terraform开始，告诉Gitlab在每个阶段做什么：

terraform_validate:
  image: 
    name: hashicorp/terraform:light
    entrypoint:
      - '/usr/bin/env'
      - 'PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin'
  stage: test
  script:
    - cd terraform 
    - terraform init
    - terraform validate

这里的想法很简单，如果基本的Terraform配置没有输出，我们不想继续进行其他步骤，因此我们在继续之前执行一个简单的验证步骤。

完成此阶段后，我们将开始为Ansible运行测试：

molecule_tests:
  image: docker:latest
  stage: test
  before_script:
    - apk update && apk add --no-cache docker
      python3-dev py3-pip docker gcc git curl build-base
      autoconf automake py3-cryptography linux-headers
      musl-dev libffi-dev openssl-dev openssh
    - docker info
    - python3 --version
  script:
    - pip3 install ansible molecule docker
    - cd ansible/roles/ubuntu-nginx
    - molecule test

在这里，我们将使用docker：latest映像以及“ Docker-in-Docker”服务，以允许Molecule启动运行Molecule测试所需的其他容器。值得注意的是，在此阶段，我们正在管道阶段执行过程中安装Molecule框架。我不建议您在自己的管道中执行此操作，因为这样做是为了演示执行Molecule所需的操作。实际上，您将托管具有所有预配置内容的Docker映像，以加快测试速度。

一旦我们的管道达到了这个阶段，我们就已经验证了Terraform文件在语法上是正确的，并且我们的Ansible角色通过了每个创建的测试，因此接下来，我们将把基础架构部署到AWS作为过渡环境进行进一步测试：

deploy_stage:
  image: 
    name: hashicorp/terraform:light
    entrypoint:
      - '/usr/bin/env'
      - 'PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin'
  stage: stage
  script:
    - cd terraform
    - terraform init
    - terraform apply --auto-approve
  artifacts:
    paths:
      - terraform/terraform.tfstate
    expire_in: 1 day

与之前的Terraform阶段相似，我们只是使用Hashicorp的Terraform Docker映像来提供Terraform工具，但是在Terraform运行之后，我们希望将状态文件保留为工件。工件可以使我们从一个阶段公开文件，并提供将创建的文件传递到管道的后续阶段的能力，这意味着在这种情况下，我们可以将Terraform tfstate文件传递给以后进行清理。

现在，我们已在重定向环境中部署了重定向器，我们需要使用Ansible进行配置：

provision_stage:
  stage: provision
  when: delayed
  start_in: 30 seconds
  image: 
    name: hashicorp/terraform:light
    entrypoint:
      - '/usr/bin/env'
      - 'PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin'
  before_script:
    - apk add ansible
    - wget https://github.com/adammck/terraform-inventory/releases/download/v0.9/terraform-inventory_0.9_linux_amd64.zip -O /tmp/terraform-inventory_0.9_linux_amd64.zip
    - unzip /tmp/terraform-inventory_0.9_linux_amd64.zip -d /usr/bin/; chmod 700 /usr/bin/terraform-inventory
  script:
    - cd terraform; terraform init; cd ..
    - cd ansible; chmod 600 .
    - chmod 600 ../terraform/keys/terraformkey
    - ANSIBLE_HOST_KEY_CHECKING=False TF_STATE=../terraform ansible-playbook --inventory-file=/usr/bin/terraform-inventory -u ubuntu --private-key ../terraform/keys/terraformkey site.yml

同样，您通常将创建一个Docker映像以加快此阶段，并根据需要添加“ terraform-inventory”工具。

在配置了重定向器之后，我们将针对AWS环境运行我们先前设计的InSpec测试：

inspec_tests:
  stage: validate
  image: 
    name: chef/inspec:4.18.51
    entrypoint:
    - '/usr/bin/env'
    - 'PATH=/usr/local/bundle/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin'
  before_script:
    - apk add jq
  script:
    - inspec --chef-license=accept-silent
    - cd inspec
    - inspec exec redirectors -t "ssh://ubuntu@$(jq '.redirector_ips.value[0]' -r ../terraform/output.json)" -i ../terraform/keys/terraformkey
    - inspec exec redirectors -t "ssh://ubuntu@$(jq '.redirector_ips.value[1]' -r ../terraform/output.json)" -i ../terraform/keys/terraformkey

最后，一旦一切完成，我们将自己清理环境：

cleanup:
  when: always
  image: 
    name: hashicorp/terraform:light
    entrypoint:
    - '/usr/bin/env'
    - 'PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin'
  stage: cleanup
  script:
    - cd terraform
    - terraform init
    - terraform destroy --auto-approve

您可能会在这里注意到when：always语句。这仅表示即使上一个阶段失败，该阶段也将运行。即使测试失败，这也使我们有机会清理过渡环境，以避免积累不必要的AWS费用。

当我们将gitlab-ci.yml文件放在一起时，会得到如下所示的内容：

image: docker:latest
services:
  - docker:dind
cache:
  key: ${CI_COMMIT_REF_SLUG}
  paths:
  - terraform/.terraform
stages:
  - test
  - stage
  - provision
  - validate
  - cleanup
terraform_validate:
  image: 
    name: hashicorp/terraform:light
    entrypoint:
      - '/usr/bin/env'
      - 'PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin'
  stage: test
  script:
    - cd terraform 
    - terraform init
    - terraform validate
molecule_tests:
  image: docker:latest
  stage: test
  before_script:
    - apk update && apk add --no-cache docker
      python3-dev py3-pip docker gcc git curl build-base
      autoconf automake py3-cryptography linux-headers
      musl-dev libffi-dev openssl-dev openssh
    - docker info
    - python3 --version
  script:
    - pip3 install ansible molecule docker
    - cd ansible/roles/ubuntu-nginx
    - molecule test
deploy_stage:
  image: 
    name: hashicorp/terraform:light
    entrypoint:
      - '/usr/bin/env'
      - 'PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin'
  stage: stage
  script:
    - cd terraform
    - terraform init
    - terraform apply --auto-approve
    - terraform output --json > output.json
  artifacts:
    paths:
      - terraform/terraform.tfstate
      - terraform/output.json
    expire_in: 1 day
provision_stage:
  when: delayed
  start_in: 30 seconds
  image: 
    name: hashicorp/terraform:light
    entrypoint:
      - '/usr/bin/env'
      - 'PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin'
  stage: provision
  before_script:
    - apk add ansible
    - wget https://github.com/adammck/terraform-inventory/releases/download/v0.9/terraform-inventory_0.9_linux_amd64.zip -O /tmp/terraform-inventory_0.9_linux_amd64.zip
    - unzip /tmp/terraform-inventory_0.9_linux_amd64.zip -d /usr/bin/; chmod 700 /usr/bin/terraform-inventory
  script:
    - cd terraform; terraform init; cd ..
    - cd ansible; chmod 600 .
    - chmod 600 ../terraform/keys/terraformkey
    - ANSIBLE_HOST_KEY_CHECKING=False TF_STATE=../terraform ansible-playbook --inventory-file=/usr/bin/terraform-inventory -u ubuntu --private-key ../terraform/keys/terraformkey site.yml
inspec_tests:
  stage: validate
  image: 
    name: chef/inspec:4.18.51
    entrypoint:
    - '/usr/bin/env'
    - 'PATH=/usr/local/bundle/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin'
  before_script:
    - apk add jq
  script:
    - inspec --chef-license=accept-silent
    - cd inspec
    - inspec exec test-aws -t aws:// 
    - inspec exec redirectors -t "ssh://ubuntu@$(jq '.redirector_ips.value[0]' -r ../terraform/output.json)" -i ../terraform/keys/terraformkey
    - inspec exec redirectors -t "ssh://ubuntu@$(jq '.redirector_ips.value[1]' -r ../terraform/output.json)" -i ../terraform/keys/terraformkey
cleanup_stage:
  when: always
  image: 
    name: hashicorp/terraform:light
    entrypoint:
    - '/usr/bin/env'
    - 'PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin'
  stage: cleanup
  script:
    - cd terraform
    - terraform init
    - terraform destroy --auto-approve

提交到项目后，我们将看到现在可以使用我们的管道，该管道将在每次推送时执行。一旦有人向您的基础架构提交提交，您将收到一个消息，表明一切都已正常：

网络安全学习资源分享:

给大家分享一份全套的网络安全学习资料，给那些想学习 网络安全的小伙伴们一点帮助！

对于从来没有接触过网络安全的同学，我们帮你准备了详细的学习成长路线图。可以说是最科学最系统的学习路线，大家跟着这个大的方向学习准没问题。

因篇幅有限，仅展示部分资料，朋友们如果有需要全套《网络安全入门+进阶学习资源包》，需要点击下方链接即可前往获取 

读者福利 | CSDN大礼包：《网络安全入门&进阶学习资源包》免费分享（安全链接，放心点击）

同时每个成长路线对应的板块都有配套的视频提供： 

 大厂面试题

视频配套资料&国内外网安书籍、文档

当然除了有配套的视频，同时也为大家整理了各种文档和书籍资料

所有资料共282G，朋友们如果有需要全套《网络安全入门+进阶学习资源包》，可以扫描下方二维码或链接免费领取~  

读者福利 | CSDN大礼包：《网络安全入门&进阶学习资源包》免费分享（安全链接，放心点击）

特别声明：

此教程为纯技术分享！本教程的目的决不是为那些怀有不良动机的人提供及技术支持！也不承担因为技术被滥用所产生的连带责任！本教程的目的在于最大限度地唤醒大家对网络安全的重视，并采取相应的安全措施，从而减少由网络安全而带来的经济损失。

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处：/a/653043.html

如若内容造成侵权/违法违规/事实不符，请联系我们进行投诉反馈qq邮箱809451989@qq.com，一经查实，立即删除！

相关文章

2024最新版本激活Typora，1.8.10.0版本可用

2024最新版本激活Typora，1.8.10.0版本可用

​实测可用日期为：2024-05-28 目前最新版本 1.8.10.0 也是可以实现激活的 注：免修改注册表、不用修改时间，更不需要破解补丁 01、下载&安装 Typora 文件 从官网下载最新版本的 Typora，并安装 或者阿里云盘： htt…
阅读更多...
Linux漏洞SSL/TLS协议信息泄露漏洞(CVE-2016-2183) - 非常危险(7.5分) 解决办法！升级openssl

Linux漏洞SSL/TLS协议信息泄露漏洞(CVE-2016-2183) - 非常危险(7.5分) 解决办法！升级openssl

漏洞情况 详细描述 TLS是安全传输层协议，用于在两个通信应用程序之间提供保密性和数据完整性。 TLS, SSH, IPSec协商及其他产品中使用的IDEA、DES及Triple DES密码或者3DES及 Triple 3DES存在大约四十亿块的生日界，这可使远程攻击者通过Sweet32攻击&…
阅读更多...
如何更好进行多媒体展厅设计

如何更好进行多媒体展厅设计

1、明确设计目标 在展厅之前要明确设计目标，这包括了展厅的主题、目的和受众等，以及希望通过展厅传达的信息和形象。只有明确了设计目标，才能有针对性地进行设计，确保展厅的效果符合预期。 2、合理规划空间布局 空间布局要合理规划…
阅读更多...
Android Service 启动流程

Android Service 启动流程

在早些年学习Android的时候，对Service有过总结，但是主要是如何去使用，注意事项，startService和bindService的区别。 Android Service_public int onstartcommand(intent intent, int flags-CSDN博客 但是今天从源码来总结下fram…
阅读更多...
六西格玛培训的讲师应该具备哪些能力？

六西格玛培训的讲师应该具备哪些能力？

六西格玛培训的讲师作为专业知识的传授者和实践经验的分享者，其能力水平的高低直接决定了培训效果的好坏。那么，一个优秀的六西格玛培训讲师应该具备哪些能力呢？深圳天行健企业管理咨询公司解析如下： 首先，六西格玛培训…
阅读更多...
HT46R002 贴片 SOP8 经济型AD型OTP MCU单片机芯片

HT46R002 贴片 SOP8 经济型AD型OTP MCU单片机芯片

HT46R002在智能家居中的具体应用案例可以包括以下几个方面： 1. 智能照明控制：可以用于控制LED灯的亮度和色温，甚至可以通过手机APP远程控制开关和调节灯光效果。 2. 环境监测：用于监测室内温度、湿度、空气质量等，当检…
阅读更多...
四川易点慧电商抖音小店：引领潮流，打造电商新标杆

四川易点慧电商抖音小店：引领潮流，打造电商新标杆

在数字化浪潮席卷全球的今天，电子商务以其独特的魅力和优势，正逐渐成为推动经济发展的重要力量。四川易点慧电子商务有限公司抖音小店，作为电商领域的一股新生力量，以其创新的经营理念和卓越的服务品质，迅速赢得了市场…
阅读更多...
解析智慧物流园区系统的多方位优势

解析智慧物流园区系统的多方位优势

智慧物流园区系统是基于物联网、大数据、人工智能等先进技术的应用系统，旨在实现物流园区的高效、智能化管理。随着物流行业的快速发展，传统物流园区已经无法满足日益增长的需求。智慧物流园区系统的出现填补了现有物流园区管理的空白，带来了…
阅读更多...
香橙派AI Pro测评--ROS及激光SLAM

香橙派AI Pro测评--ROS及激光SLAM

文章目录 前言一、外形与质感二、软件测评1. 系统界面2. ROS安装3. ROS节点测试4. SLAM算法测试 总结 前言 今天刚收到了官方寄来的“香橙派 AI Pro”开发板，这篇文章将会对香橙派 AI Pro的外形、质感、运行速度进行一个测评，然后我会在这个开发板上安装…
阅读更多...
0基础学习小红书博主IP特训营，37天 教你从小白到KOL（13节）

0基础学习小红书博主IP特训营，37天 教你从小白到KOL（13节）

课程内容： 1 第一课:如何做好博主账号定位 .mp4 2 第一课作业,html 3 第二课:如何打造小红书爆款笔记(一)_.mp4 4 第二课:如何打造小红书爆款笔记(二).mp4 5 第二课作业,html 6 第三课:如何高效搭建选题库 .mp4 7 第三课作业,html 8 第四课:破解流量玄学&am…
阅读更多...
新零售数据中台：打造智能商业运营的核心引擎_光点科技

新零售数据中台：打造智能商业运营的核心引擎_光点科技

随着数字化转型的浪潮席卷全球，新零售行业正在经历一场前所未有的革新。在这一过程中，“新零售数据中台”逐渐成为企业构建智能商业运营的核心引擎。本文将重点介绍新零售数据中台的概念、其在新零售中的作用，以及如何通过数据中台实现商业价…
阅读更多...
UIAbility的使用

UIAbility的使用

UIAbility概述 UIAbility是一种包含用户界面的应用组件，主要用于和用户进行交互。UIAbility也是系统调度的单元，为应用提供一系列的窗口，应用在这些窗口里绘制用户交互界面。 每一个UIAbility实例，都对应于一个最近任务列表中的任…
阅读更多...
【外汇天眼】市场如战场：交易中的攻防艺术

【外汇天眼】市场如战场：交易中的攻防艺术

交易的成功如同生活，急功近利反而有害无益。在交易中，许多投资者常常面临亏损，急于挽回损失，频繁操作，结果却往往是越亏越多。交易需要耐心，不能急于一时，更不能与市场赌气。交易和生活一样&…
阅读更多...
832. 翻转图像 - 力扣

832. 翻转图像 - 力扣

1. 题目 给定一个 n x n 的二进制矩阵 image ，先 水平 翻转图像，然后 反转 图像并返回 结果 。 水平翻转图片就是将图片的每一行都进行翻转，即逆序。 例如，水平翻转 [1,1,0] 的结果是 [0,1,1]。 反转图片的意思是图片中的 0 全部被…
阅读更多...
软件项目管理 - 作业集合

软件项目管理 - 作业集合

软件项目管理 - 作业集合 作业一 1、项目与日常运作的主要区别有哪些？ 项目：为提供一项独特产品、服务或成果所做的临时性努力 运作：连续不断周而复始的活动 项目是一次性的，日常运作是重复进行的； 项目是以目标为导…
阅读更多...
揭秘成绩等级背后的逻辑：小明的语文分数转换记

揭秘成绩等级背后的逻辑：小明的语文分数转换记

新书上架~👇全国包邮奥~ python实用小工具开发教程http://pythontoolsteach.com/3 欢迎关注我👆，收藏下次不迷路┗|｀O′|┛ 嗷~~ 目录 一、引言 二、成绩等级转换规则 三、小明的语文成绩转换过程 四、总结与展望 一、引言 在…
阅读更多...
2024 年“泰迪杯”A 题：生产线的故障自动识别与人员配置--第四题（用遗传算法解决生产线排班问题--matlab代码）

2024 年“泰迪杯”A 题：生产线的故障自动识别与人员配置--第四题（用遗传算法解决生产线排班问题--matlab代码）

问题背景： 问题四：根据实际情况，现需要扩大生产规模，将生产线每天的运行时间从 8 小时增加 到 24 小时不间断生产，考虑生产线与操作人员的搭配，制定最佳的操作人员排班方案，要求满足以下条件&am…
阅读更多...
香橙派Orange AI Pro 初体验

香橙派Orange AI Pro 初体验

什么是香橙派 ？ 香橙派（Orange Pi）是深圳市迅龙软件有限公司旗下的开源产品品牌。它专注于为全球个人和企业提供高性价比的开源硬件、开源软件以及OEM/ODM服务。香橙派已经迭代了30多款产品，形成了涵盖开源硬件、开源软件、开源芯…
阅读更多...
vue3主题切换按钮与功能实现

vue3主题切换按钮与功能实现

代码: <template><div class"slideThree"><label class"theme-switch"><inputtype"checkbox"class"checkbox"v-model"isChecked"change"setTheme"id"slideThree"name"check…
阅读更多...
三品软件：打造高效安全的图文档管理体系

三品软件：打造高效安全的图文档管理体系

在数字化转型的浪潮中&#xff0c;工程设计单位和企业设计部门面临着电子图文档管理的巨大挑战。随着电子图纸和文档数量的激增&#xff0c;如何有效组织、管理和共享这些资源&#xff0c;成为提升工作效率和保障信息安全的关键。本文将探讨当前图文档管理面临的问题&#xff0…
阅读更多...
最新文章

Copyright @ 2022~2023