카테고리 Archives: Server engineering

AWS 서버 발생 로그의 분리 보관 (amazon-cloudwatch-agent)

서버내 dbus -> rsyslogd 에 의해 수집된 시스템 로그는 /var/log 아래에 파일 형태로 저장 된다.

이는 /etc/logrotate.conf 설정에 따라 서버내에 보관이 된다.

 

다만 보관된 파일의 파일 형태로 저장되어 있기 때문에 구조만 알고 있다면 파일을 삭제 하거나 변조 할 수 있으므로

추후 추적을 용의 하게 하기 위해, 데이터 무결성을 보장하기 위해, 혹은 다중의 서버의 데이터를 모아서 보관 하기위해 log 콜렉팅을 하는것이 일반적인 보안 방법 이다.

 

단순한 rsyslogd 를 이용한 udp 푸시 및 graylog collecting 은 기존에 설명을 했지만

AWS 상에서는 CloudWatch Log 라는 기능을 제공 한다 이를 통해 지표 형태로 보거나 알람 설정등을 할 수 있다.

 

서버에서는 CloudWatch log 쪽으로 데이터를 넣어주는 프로그램을 설치해서 운용 하며 이후

Log 파일의 안전한 분리 보관, 보관 주기 설정, 알람 설정 등을 웹 콘솔상에서 편하게 진행할 수 있다.

 

기존에 centos 7 에서는 yum 을 이용하여 awslogs 라는 프로그램을 설치하여 같은 기능을 사용하고 있었으나

Rockylinux 8 에서는 dnf 패키지가 없는 관계로 RPM 설치를 필요로 한다.


AWS 웹콘솔 에서 IAM 메뉴의 Role (역할) 을 생성 하고 권한을 부여 한다. (중간에 권한은 지정하지 않고 생성 하고 추후 인라인 정책으로 생성 한다.)

2022-04-08_161452 2022-04-08_161613 2022-04-08_162326

 

인라인 정책을 생성 한다. (생성한 정책이 다른 계정 이나 역할에 공통으로 부여할 필요하 있으면 일반 정책 생성 후 연결 한다.)

2022-04-08_162608 2022-04-08_163101 2022-04-08_163232

위 json 정책은 ap-northeast-2 (서울) 리전에 로그 를 쌓는 기능만 허용 하는것으로 제한 하였다.

 

생성된 Role (역할) 을 필요한 EC2에 연결 한다.

2022-04-08_164417 2022-04-08_164648

 

위에서 이야기 했지만 yum(dnf) 설치가 RockyLinux 8 에서 되지 않는다. 때문에 AWS 에서 배포 하는 rpm 파일을 가지고 설치를 진행 한다. (amazon-cloudwatch-agent  설치 메뉴얼)

 

편리하게 사용하라고 대화식 명령어를 실행 하도록 되어 있다.
/opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-config-wizard

하지만 문답 형식의 영어를 읽기도 귀찮고(어렵고) Role (정책)을 부여하여 키없이 로그를 쌓게 하고자 했으나

스크립트에서는 필수적으로 Access Key/Secret Key 를 입력 해야 하는 부분이 있기 때문에 스크립트로 진행이 어렵다.

때문에 /opt/aws/amazon-cloudwatch-agent/bin/config.json 파일을 직접 수정 해 준다. (amazon-cloudwatch-agent 설정 메뉴얼)

위 예제는 apache, php, nginx 등을 dnf(yum) 설치를 한경우 일반 적인 log 포멧의 timestamp를 인식 하도록 정리한 것이다. (secure, message 로그 및 apache, nginx, php-fpm 로그)

필요에 따라 수정을 해서 사용 하도록 한다.

 

이후 다음 명령어로 설정된 config.json 을 점검 하고 문제가 없다면 자동으로 서비스가 시작된다.

 

웹 콘솔 에서 Cloudwatch > 로그 그룹에서 보관 기간 을 설정 하고 로그 데이터가 잘 적재 되고 있는지 확인 한다.

2022-04-08_1810182022-04-08_1649512022-04-08_181557

springboot 의 systemd 설정 및 rsyslog 설정

스프링부트로 작성이 된 프로그램을 systemd 를 이용한 데모나이즈를 위해 아래와 같이 생성 한다. (가장 기본적인 부분..)

 

위와 같이 설정 파일을 생성 한뒤에 아래와 같은 명령어로 실행 할 수 있다.

 

위와 같이 실행을 할 경우 발생하는 로그는 CentOS 7 기준 /var/log/messages 파일에 누적이 된다.

가만히 두면 messages 파일이 엄청 커지거나 섞여 있어서 로그 확인에 에로 사항이 발생하게 된다.

때문에 다음 와 같이 /etc/rsyslog.d/30-springboot.conf 파일을 생성 하여 분리 하도록 한다.

 

rsyslog 를 재시작 한다.


PS1. 로그 순환 설정

 

rsyslog 에서 생성하는 별도의 파일을 새롭게 선언 되었기 때문에 logrotate 가 안되면 파일이 무한 증식 하게 되므로 아래와 같이 순환 설정을 하여

1달동안 보관 되고 삭제 되도록 설정 한다. (생성만 해두면 다음 주기에 적용됨..재시작할 필요는 없음.)


PS2. 프로그램 배포계정에 특정 데몬의 콘트롤 권한만 부여(sudo 이용) 하는 방법.

 

배포계정에 systemctl 을 이용 하여 특정 데몬을 콘트롤 할수 있는 권한을 부여 한다.

 

배포 계정은 아래와 같이 부여된 명령어를 root 와 같은 권한으로 실행이 가능 하다.

 

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 시작 및 활성화

 

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 호스트에서 별도로 조취할 필요가 없다고 한다 🙂

랄라~

bash 스크립트의 실행 속도(간격) 한계

bash 로 작성된 스크립트의 경우 anacron 혹은 crond 에 의존하여 작동을 한다.

때문에 지정 할 수 있는 최소 시간은 1분이다.

즉 1분에 1회만 실행이 가능하다.

 

필요에 따라 5초 혹은 10초 단위 마다 재 실행 이 가능한 경우가 발생했다. (push 메세지 전송이라든가..)

 

이 한계를 넘기 위해 아래와 같이 작성하여 지정된 $TERM 동안 sleep 을 하고 excute-job 펑션을 재실행 하도록 작성 한다.

1~6 값을 지정함에 따라 알맞은 $TERM을 sleep 하고 재 실행 하게 된다.