Docker for windows – centos8(php, httpd) 설치

Centos 8.1.1911 이 배포 되었다.

당장 OS 를 올릴 필요는 없지만 새로운 OS 가 추후에는 사용이 될것이기 때문에

Docker 환경에서 연습이 필요로 하다고 판단되어 Windows for Docker 를 이용하여 컨테이너를 생성하여 설치 테스트 및 작동 테스트를 해보았다 ‘ㅅ’a

사전에 c 드라이브를 분배 하여 w 드라이브에 workspace 를 생성 하였으며 컨테이너 웹 디렉토리와 연결한다. (windows 환경에서 php 개발 편의성)

 

물론 Docker 부분만 제외 한다면 Centos 8 에서 같은 방법으로 설치가 가능하다.

 

docker 에 centos 8 공식 이미지를 통해 컨테이너 생성을 한다.

 

Remi’s 레포지토리 추가 및 php 7.3 설치 (httpd 는 의존성에 의해 OS 기본 제공 되는 2.4.37이 설치 된다.)

 

apache 설정 (웹 디렉토리는 /var/www/html 으로 진행 하였음.)

 

php-fpm 설정

 

php.ini 설정 (파일 업로드 100M 와 숏코드만 사용 만 수정)

 

apache 및 php-fpm 시작 및 활성화

 

docker hub: https://hub.docker.com/r/san0123/centos8-apache24-php73

도커 이미지(latest)의 경우 php-fpm 이 아닌 libphp7.so 으로 httpd-profork 방식으로 설정 되어 있다. (ssl, http2 등 사용 불가)

php 7.4 : https://hub.docker.com/r/san0123/centos8-apache24-php74


ps. MariaDB 10.4 설치

mariadb 는 centos 에서 10.3.17 이 제공되지만 업데이트는 잘되지 않기 때문에 mariadb 에서 제공 되는 repo를 추가하고 설치한다.

 

mariadb 시작 및 활성화

 

 

정보보호 관리체계(ISMS) – centos 서버 패치

Information Security Management System(ISMS) / 한국 정보보호 관리체계 인증(K-ISMS)

사실 처음 공부를 시작할때 개발자 vs 엔지니어 로 고민 했던 사람들이 많았다.

그런 우리의 고민을 모든 날려버린 직업이 발생하는데 바로 DevOps 이다.

개발자에게 엔지니어의 역할을 맞기거나 엔지니어에 개발을 요구 하는…

 

그래서 숙련 되지 않는 엔지니어를 위해서(혹은 개발자지만 엔지니어 역량이 요구되는 직무인 사람) 서버 기본 보안 설정에 대한 글을 포스팅 하게 되었다.

(ISMS 혹은 K-ISMS 에 필요한 포스팅을 했을때 블로그에 해당 링크를 통해 유입 되는 사람이 많다.)

 

사실 한국 과학기술정보통신부에서 발행하는 문서 “201712_주요정보통신기반시설_기술적_취약점_분석평가_가이드” 에 따라

centos 7 에서 설정해줘야 하는 부분만 스크립트로 작성 하였다.

 

“계정이 존재하지 않는 GID 금지 / 홈 디렉토리의 존재 관리” 항목은 보여줄뿐 수동으로 맞추어야 한다.

 

가이드 라인 문서중 apache / NFS / ftp / sendmail 은 사용 여부에 따라 추가적인 보안 조치를 해야 한다.

아래는 가이드 라인 문서에 따른 점검 항목 및 centos 에서의 처리 방법 예제 이다.(hwp 로 제작된 pdf 라서 복사가 안됨….)

일반적으로 문제 없음 = centos 7 기본 설치 상태에서 문제가 이미 없거나 설치 되지 않는 서비스 및 명령어

스크립트 = 올려둔 스크립트로 패치가 되는 경우

스크립트(list 수동) = 올려둔 스크립트 실행시 관리자가 인지 할 수 있도록 리스트 출력 (관리자 개입 수정 필요)

서버 관리자 숙지 = 일회성이 아닌 지속 적으로 관리자가 신경 써야 하는 부분

위험 수용 = 사이드 라인을 따라 갈 경우 서버에 장애 발생

서비스에 따라 개별 설정 필요 = 서버 목적에 따라 설치시 별도로 보안 점검이 필요로 하는 부분

Let’s encrypt – ACMEv1 지원 종료

Let’s encrypt 에서 API (ACMEv1) 을 종료할 계획을 발표 했다.

오늘 관련 메일을 수신 받았고 내용을 확인해 봤을때 아래와 같다.

2019년 11월 – 신규 어카운트 사용 불가 (기 등록 계정[메일주소]은 사용 가능)

2020년 6월 – 신규 도메인 발급 불가 (기존 도메인 renew 만 가능)

2021년 초 – 지원 종료 (사용 불가)

https://community.letsencrypt.org/t/end-of-life-plan-for-acmev1/88430

 

간단히 말해서 ACMEv2 주소를 ACMEv1 대신 사용하면 된다.

ACMEv2 의 경우 2018년 3월에 공개가 되었으며 STAR(*) 인증서 발급을 지원한다.

 

기본적으로 certbot 의 경우 실행시 자동으로 업데이트를 한다. (renew 에서도)

그러므로 API 주소만 단순히 ACMEv2 을 사용하면 동일 하게 사용할 수 있다.

( https://acme-v01.api.letsencrypt.org/directory –> https://acme-v02.api.letsencrypt.org/directory )

 

인증서 만료일은 아래와 같이 certbot-auto 명령어와 openssl 명령어로 확인할 수 있다.

 

테스트 결과 renrwal 폴더 안의 conf 파일의 기존 ACMEv1 주소를 ACMEv2 으로 변경하면 정상적으로 갱신이 가능하다.

아울러서 v2 의 경우 다중의 end point 를 통해 http 인증을 진행 한다. 기존에 1개의 아이피 에서 인증을 진행했지만 8 곳 에서 http 인증을 진행하는것으로 확인 되었다 ‘ㅅ’a

물론 이 end point 의 경우 유동 적일 수 있다.

 

인증서 취소 & 인증서 삭제

 

MDS / Zombie Load 취약점

Intel CPU 에서 또다른 취약점인 MDS 취약점이 공개 되었다.

심각도는 impotant 이며 CVE-2018-11091, CVE-2018-12126, CVE-2018-12127, CVE-2018-12130 항목이다.

KISA 공지 사항: https://www.boho.or.kr/data/secNoticeView.do?bulletin_writing_sequence=35030

 

CPU 캐쉬내 데이터는 적재한 프로세스가 아닌 다른 프로세스에서 엑세스 할 수 있는 취약점이다.

 

중요도가 높다보니 취약점 패지가 이미 배포 되어 yum 업데이트만으로 해결이 가능하다.

업데이트 항목이 kernel 과 intel-microcode 다 보니 재부팅이 필요 하다.

 

음 AWS 서비스의 경우 아래와 같이 안내 되어 있다.

https://aws.amazon.com/ko/security/security-bulletins/AWS-2019-004/

AWS has designed and implemented its infrastructure with protections against these types of bugs, and has also deployed additional protections for MDS

All EC2 host infrastructure has been updated with these new protections, and no customer action is required at the infrastructure level

 

뭐 AWS 인프라 레벨에서 MDS 취약점을 처리 하였으니 유져가 EC2 호스트에서 별도로 조취할 필요가 없다고 한다 🙂

랄라~

CAA 설정

SSL 암호화 를 적용을 하게 되면 공격자가 데이터를 직접 열어보거나 변조가 어렵다.

다만 Man In Middle Attack 만 가능할 뿐이다.

 

MIMT 공격은 중간에 패킷을 가로채서 endpoint으로 재전송을 할수 있겠다.

이는 프로그래밍 단에서 한번만 작동을 하도록 하면 되기 때문에 큰 문제가 되기 어렵다.

 

다만 다른 CA (인증서 발급 기관) 에서 같은 도메인을 가지고 인증서를 발급했다면 패킷을 변조하여 전송이 가능하다.

즉 클라이언트 A 가  인증업체D 에서 발급 받은 인증서로 운영 되는 B 회사의 서버에 접속하려고 할때

공격자 C 가 다른 인증서 발급 업체인 E 에서 발급 받아 패킷을 가로채서 서비스 하거나, 변조해서 엔드포인트로 전송을 할수 있다.

aaaaaaaaaaaaaaaaaaaaaaaa

때문에 이러한 공격에 대비하기 위해 HTTP Public Key Pinning (HPKP) 혹은 Certification Authority Authorization (CAA)

를 설정 하여 막을 수 있다.

 

이는 브라우져 에서도 지원해야 막을 수 있기 때문에 꼭 막힌다는 보장이 되지는 않다.

chrome 의 경우 현재 HPKP 를 지원한다.

다만 HPKP 의 경우 인증서에서 pin을 생성하고 그것을 http header 에 추가 하여 진행하기 때문에 인증서가 교체 될 경우 문제가 발생할 소지가 높다.

물론 백업 키를 생성하여 추가 등록을 한다지만 아슬아슬한게 사실이다 ‘ㅅ’a

 

CAA 의 경우 각 CA 들이 CAA 검증 이후 인증서 발급을 하도록 결의 했고 실행하고 있다.

때문에 CAA를 등록하는 것만으로 자신의 도메인의 인증서를 다른 업체를 통해서 재발급이 어렵다고 본다. ‘ㅅ’a

(물론 자신의 경우엔 인증서 발급업체의 변경을 고려 할때 1~2일전에 미리 CAA 값을 추가 해두어야 하겠다.)

 

CAA 레코드는 아래와 같이 설정한다. (let’s encrypt 일 경우)

CAA 의 맨 마지막에 지정되는 벤더 값은 각 인증서 발급업체에서 안내 되고 있다.

issue 의 경우 해당 도메인의 발급 권한을 지정한 회사(letsencrtpt.org)에 부여(0)한다.

issuewild 의 경우 해당 도메인 및 하위(서브) 도메인의 발급 권한을 지정한 회사(letsencrtpt.org)에 부여(0)한다.

 

AWS ROUTE53 서비스에서는 하나의 레코드 세트에 여러줄을 입력 한다.

2019-04-08_154055_001