HTTPS를 사용하여 멀티 서버 보안 엔진 설치를 확보하십시오-리눅스-php.cn

Secure A Multi-Server Security Engine Installation With HTTPS 이 튜토리얼의 두 번째 부분은 멀티 서버 크라우드 스크 보안 엔진의 설치를 설정하고 보호하는 방법을 설명합니다. 첫 번째 부분에서는 여러 서버에서 Crowdsec 보안 엔진을 설정하는 방법을 설명합니다. 그 중 하나는 부모 서버 역할을하고 다른 두 서버는 경고를 전달합니다.

이 섹션에서는 이전 멀티 서버 보안 엔진 설치에서 일반 텍스트 HTTP 통신으로 인한 보안 문제를 해결합니다. 이 문제를 해결하려면 암호화 된 채널을 통해 보안 엔진 간의 통신을 설정하는 것이 좋습니다. 이 솔루션을 사용하면 Server 2 또는 Server 3을 사용하면 서버 1의 ID를 신뢰하고 중간에 사람의 공격을 피할 수 있습니다.

자체 서명 인증서를 사용하는 인증서 생성

먼저 인증서를 만들어야합니다. 이것은 단일 라인 명령을 따라 달성 할 수 있습니다 :

현재 보안 엔진은 시작시 개인 키에 대한 비밀번호를 요청할 수 없습니다. 따라서 보안 엔진을 시작하거나 다시로드 할 때마다 개인 키를 수동으로 해독하거나 암호화되지 않은 키를 저장하도록 선택할 수 있습니다. 어느 쪽이든, 비밀번호를 삭제하려면 다음 명령을 사용할 수 있습니다.

그런 다음 보안 엔진이 시작된 후 암호화되지 않은 키 파일을 안전하게 삭제할 수 있습니다.

보안 엔진을 구성하여 자체 서명 된 인증서

를 사용하여 서버 1에서 생성 된 인증서를 사용하려면 보안 엔진을 구성해야합니다. 아래와 같이, 다음 발췌문의 섹션의 및 옵션은 생성 된 인증서 파일로 설정됩니다.

openssl req -x509 -newkey rsa:4096 -keyout encrypted-key.pem -out cert.pem -days 365 -addext "subjectAltName = IP:172.31.100.242"

로그인 후 복사

클라이언트에서 구성 변경은 두 파일 모두에서 발생합니다. 먼저,

로 를 설정하여 자체 서명 된 인증서를 수락하려면 를 수정하십시오.

또한 이러한 변경 사항을 반영하려면 파일에서 http를 https로 변경해야합니다. 이 작은 변경은 세 서버 (서버 1, 서버 2 및 서버 3) 모두에서 수행해야합니다.

openssl rsa -in encrypted-key.pem -out key.pem

로그인 후 복사

참고 :

서버 1을 로그 프로세서로 사용하는 경우이 서버 에서이 LAPI 구성을 수행해야합니다.

사이드 참고 : /etc/crowdec/config.yaml 분명히, 자체 서명 된 인증서를 사용하면 LAPI 서버의 소유권에 대한 보증을 제공하지 않습니다. 서비스를 사용하는 서버 (이 설정에서 서버 2 또는 서버 3)는 여전히 중간의 공격에 취약하지만 적어도이 설정은 암호화 된 통신을 제공합니다. 이것이 api.server 인증서 tls.cert_file에 의해 발행 된 인증서 Let 's Encrypt 또는 Amazon ACM과 같은 서비스는 tls.key_file 또는 로컬 DNS 서버에 추가 할 수있는 완전한 자격을 갖춘 도메인 이름에 대한 인증서를 발행하여

문제를 해결할 수 있습니다. 그런 다음이 지정된 완전한 자격을 갖춘 도메인 이름으로 를 채울 수 있습니다.

api:
  server:
    log_level: info
    listen_uri: 10.0.0.1:8080
    profiles_path: /etc/crowdsec/profiles.yaml
    online_client: # Crowdsec API credentials (to push signals and receive bad 

    tls:
      cert_file: /etc/crowdsec/ssl/cert.pem
      key_file: /etc/crowdsec/ssl/key.pem

로그인 후 복사

이것은 작동하며

옵션이 설정되는 것을 방지합니다. DNS 구성이 신뢰되는 한 클라이언트와 서버 간의 통신이 조작되지 않도록하지만 여전히 해결 방법으로 간주되어야합니다. InsecureSkipVerify pki 사용 SSL Public Key Infrastructure (PKI) 구성 및 관리 프로세스는이 자습서의 범위 내에 있지 않지만 공식 OpenSSL 문서를 확인하는 것이 좋습니다. 간단한 PKI 솔루션은이 보안 엔진 설정의 요구를 충족시키기에 충분합니다.

OpenSSL 문서에 따르면 언급 할 가치가있는 것들이 있습니다.

Crowdsec TLS 시나리오에서 사용하려면 Crowdsec LAPI 서버의 IP에 해당하는 대체 이름이있는 인증서 요청을 발행해야합니다. 이는 인증서 요청에 대해 OpenSSL을 호출 할 때 SAN 환경 변수를 찾아서 수행 할 수 있습니다 (OpenSSL Simple PKI Scheme의 3.3 단계 참조).

Crowdsec 보안 엔진을 시작하기 전에 루트 인증서의 공통 부분 및 서명 된 인증서 (OpenSSL Simple PKI 체계의 4.5 단계에서 생성 된 번들 파일)를 로컬 인증서 저장소에 추가해야합니다. 이 설정에서는 LAPI 서버에 연결해야합니다. 이를 수행하는 방법에는 여러 가지가 있습니다. Golang 소스 코드는 예상 인증서의 위치를 지정하거나 SystemD 서비스 파일의
환경 변수를 사용하여 보안 엔진을 시작할 때 인증서를 찾을 위치를 지정할 수 있습니다.
Crowdsec 및 TLS 인증에 대한 지침을 업데이트합니다 이 기사가 처음 출판 된 후, 우리는 보안 엔진에 새로운 기능을 추가했으며, 이제 TLS의 통신을 보호 할뿐만 아니라 인증서 인증을 보장 할 수 있습니다. 공식 문서에서는 보안 엔진 또는 보안 엔진 및 치료 구성 요소간에 TLS 인증에 인증서를 사용하는 방법을 보여주는 좋은 예를 찾을 수 있습니다.

openssl req -x509 -newkey rsa:4096 -keyout encrypted-key.pem -out cert.pem -days 365 -addext "subjectAltName = IP:172.31.100.242"

로그인 후 복사

결론 이 기사는 다양한 크라우드 스펙 보안 엔진 설치 간의 커뮤니케이션을 보호하는 방법에 중점을 둡니다. 고려 된 유스 케이스는 개인 네트워크에서 보안 엔진 설치이지만 인터넷 통신을 통해 공개 네트워크에도 배포 될 수도 있습니다. 이 경우 타사 인증서는 문제를 쉽게 해결할 수 있습니다.

필요에 따라, 우리는 보안 엔진 간의 안전한 TLS 통신을 달성하기위한 세 가지 다른 방법, 즉 자체 서명 인증서를 사용하고, 인증서 당국이 발행 한 인증서를 사용하고, SSL 공개 키 인프라를 사용하는 세 가지 방법을 제안합니다. SSL_CERT_FILE 첫 번째 솔루션 (자체 서명 된 인증서 사용)은 인증없이 암호화 된 의사 소통을 보장하려는 상황에만 적합합니다. 두 번째 솔루션은 로컬 DNS 해상도를 수정할 수있을 때만 고려할 수 있습니다. 세 번째 솔루션은 가장 복잡하지만 대부분의 사용 사례에 적합하며 보안 문제가 심각 할 때 최선의 선택 일 수 있습니다.

이 튜토리얼이 도움이되기를 바랍니다. 읽어 주셔서 감사합니다. 계속 지켜봐주세요!