정리 블로그

umask의 역할과 사용방법

Sungtaek, YOO — Thu, 20 Feb 2025 22:45:05 +0900

1. umask 역할

리눅스에서 umask는 새로 생성되는 파일이나 디렉토리의 기본 권한 설정을 제한하고, 보안성을 높이는 데 사용될 수 있다.

2. umask 설정 및 사용 이유

회사에서 서버의 보안 점검 심사가 진행되거나 isms와 같은 심사가 진행되면 서버의 보안 수준도 같이 진단받게 된다. 이 때, umask 적용 여부도 확인이 될 수 있다.

기본적으로 파일은 666, 디렉토리는 777 권한을 가지게 된다. 이 때, umask 설정이 022로 적용된다면 (보안성 강화를 위해 022 권고)

파일은 666 -> 644(rw-r--r--) 이 적용되고,

디렉토리는 777 -> 755(rwx-r-x-r-x)가 적용되므로, 보안성이 강화될 수 있다.

3. 적용 시, 주의 사항 및 참고 사항

umask를 신규로 적용하게 되면 기존에 생성된 파일과 폴더는 영향이 없으며, 적용 후 신규로 생성되는 파일부터 적용이 된다.

그리고 해당 권한은 리눅스 사용자별로 다르게 적용될 수 있으므로, 모든 사용자가 예외없이 적용되도록 적용할 필요가 있다.

그렇다고해서 너무 강하게 적용하면 어플리케이션이 특정 파일이나 디렉토리를 읽거나 실행해야할 때, 권한이 없어 에러가 발생할 수 있으니 주의하자.

4. 적용 방법

적용이 되었는지 여부는 커맨드창에서 umask를 입력하면 된다.

일시 적용: 현재 세션에서 umask 000

umask 000 적용 후 test.txt 파일을 생성, rw-rw-rw 권한을 가진 파일이 생성된 것을 볼 수 있다.

umask 022 설정 후 test2.txt 파일 생성 시, rw-r--r-- 권한을 가진 파일 생성.

영구 설정: 시스템의 기본 umask 값은 일반적으로 /etc/profile 또는 /etc/bashrc 파일에서 설정할 수 있으며, umask 022 을 라인에 추가해주면 된다.

AWS Athena를 활용한 ALB Connection Log 확인

Sungtaek, YOO — Thu, 4 Apr 2024 00:31:21 +0900

1. ALB Connection Log

-. 언제부터 생긴지는 모르겠으나, ALB에 Connection Log 가 새로 생겨있음

-. 새로 생긴 기능이라 그런지 Table 생성 쿼리가 공식문서에는 아직 안나와있음

-. 로그에는 클라이언트의 IP 주소 및 포트, 리스너 포트, 사용된 TLS 암호 및 프로토콜, TLS 핸드셰이크 지연 시간, 연결 상태, 클라이언트 인증서 세부 정보 등의 정보가 포함되므로, 연결 로그를 사용하여 요청 패턴을 분석하고 문제를 해결 가능

2. Connection Log 활성화 후 수집 내용

2024-03-11T23:59:59.187088Z [CLIENT-IP-숨김] 4704 443 TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256 0.012 "-" - - Success
2024-03-11T23:59:59.203439Z [CLIENT-IP-숨김] 51214 443 TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256 0.013 "-" - - Success
2024-03-11T23:59:59.210184Z [CLIENT-IP-숨김] 61194 443 TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256 0.004 "-" - - Success
2024-03-11T23:59:59.215868Z [CLIENT-IP-숨김] 54444 443 TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256 0.003 "-" - - Success
2024-03-11T23:59:59.241786Z [CLIENT-IP-숨김] 56294 443 TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256 0.007 "-" - - Success
2024-03-11T23:59:59.242564Z [CLIENT-IP-숨김] 60949 443 TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256 0.009 "-" - - Success
2024-03-11T23:59:59.258342Z [CLIENT-IP-숨김] 62395 443 TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256 0.042 "-" - - Success
2024-03-11T23:59:59.263639Z [CLIENT-IP-숨김] 41166 443 TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256 0.004 "-" - - Success
2024-03-11T23:59:59.287119Z [CLIENT-IP-숨김] 44380 443 TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256 0.010 "-" - - Success
2024-03-11T23:59:59.290264Z [CLIENT-IP-숨김] 54454 443 TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256 0.003 "-" - - Success
2024-03-11T23:59:59.292470Z [CLIENT-IP-숨김] 56314 443 TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256 0.008 "-" - - Success
2024-03-11T23:59:59.318069Z [CLIENT-IP-숨김] 51230 443 TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256 0.013 "-" - - Success
2024-03-11T23:59:59.333857Z [CLIENT-IP-숨김] 38647 443 TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256 0.000 "-" - - Success
2024-03-11T23:59:59.340725Z [CLIENT-IP-숨김] 56328 443 TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256 0.005 "-" - - Success
2024-03-11T23:59:59.345163Z [CLIENT-IP-숨김] 54462 443 TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256 0.005 "-" - - Success
2024-03-11T23:59:59.369386Z [CLIENT-IP-숨김] 50565 443 TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256 0.009 "-" - - Success
2024-03-11T23:59:59.372092Z [CLIENT-IP-숨김] 51232 443 TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256 0.012 "-" - - Success
2024-03-11T23:59:59.378269Z [CLIENT-IP-숨김] 48360 443 TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256 1.445 "-" - - Success
2024-03-11T23:59:59.385046Z [CLIENT-IP-숨김] 56348 443 TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256 0.006 "-" - - Success
2024-03-11T23:59:59.407253Z [CLIENT-IP-숨김] 4705 443 TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256 0.010 "-" - - Success
2024-03-11T23:59:59.408600Z [CLIENT-IP-숨김] 60956 443 TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256 0.020 "-" - - Success
2024-03-11T23:59:59.415877Z [CLIENT-IP-숨김] 56642 443 TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256 0.032 "-" - - Success
2024-03-11T23:59:59.417354Z [CLIENT-IP-숨김] 44388 443 TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256 0.004 "-" - - Succes

각 필드별 값은 AWS 공식 document 확인(https://docs.aws.amazon.com/ko_kr/elasticloadbalancing/latest/application/load-balancer-connection-logs.html)

3. Athena Table 생성 쿼리

CREATE EXTERNAL TABLE IF NOT EXISTS alb_conn_logs (
    time string,
    client_ip string,
    client_port int,
    listener_port int,
    tls_protocol string,
    tls_cipher string,
    tls_handshake_latency double,
    leaf_client_cert_subject string,
    leaf_client_cert_validity string,
    leaf_client_cert_serial_number string,
    tls_verify_status string
)
PARTITIONED BY
(
    day STRING
)
ROW FORMAT SERDE 'org.apache.hadoop.hive.serde2.RegexSerDe'
WITH SERDEPROPERTIES (
'serialization.format' = '1',
'input.regex' =
    '([^ ]*) ([^ ]*) ([0-9]*) ([0-9]*) ([A-Za-z0-9.-]*) ([^ ]*) ([-.0-9]*) \"([^\"]*)\" ([^ ]*) ([^ ]*) ([^ ]*)')
LOCATION 's3://<S3-LOCATION>/AWSLogs/<ACCOUNT-NUMBER>/elasticloadbalancing/<REGION>/'
TBLPROPERTIES
(
    "projection.enabled" = "true",
    "projection.day.type" = "date",
    "projection.day.range" = "2023/11/27,NOW",
    "projection.day.format" = "yyyy/MM/dd",
    "projection.day.interval" = "1",
    "projection.day.interval.unit" = "DAYS",
    "storage.location.template" = "s3://<S3-LOCATION>/AWSLogs/<ACCOUNT-NUMBER>/elasticloadbalancing/<REGION>/${day}"
)

Redis 삭제 모니터링 과정

Sungtaek, YOO — Sun, 10 Mar 2024 21:18:25 +0900

1. Redis 삭제 준비

-. 불필요한 리소스를 삭제하다보면 Redis를 삭제하는 경우가 생긴다.

Redis의 경우, 일반 AWS 리소스와는 달리 'Stop'이 없다. 오직 'Delete'만 가능할뿐..

리소스 삭제 전 실제 사용되고 있지 않은 리소스인지 검증이 필요하다.

아래와 같은 프로세스로 삭제를 진행하였다.

-. 보안그룹 차단하여, 고립시킨 후 서비스 이상여부를 체크. 최종적으로 Redis에 접근하여 모니터링해본다.

며칠 간 특이사항이 없다면 삭제 수행

2. 삭제를 위한 작업

-. 우선 삭제 진행에 앞서, 내가 사용하고 있는 Redis는 이미 EOS가 지난 Redis였다. (강제 버전 업그레이드 연기..)

따라서, AWS 콘솔을 통한 작업이 불가하였음

(In/Out bound가 아무것도 포함되지 않은 보안그룹으로 변경 시, 위와 같은 에러 발생)

2-1. 특정 서버에 aws cli를 설치

2-2. cli 명령어를 통한 보안그룹 변경(access key 사용)

aws elasticache modify-replication-group --replication-group-id dev-cache --security-group-ids sg-0911cf6ffe

2-3. redis-cli 설치

yum install -y gcc

wget http://download.redis.io/redis-stable.tar.gz && tar xvzf redis-stable.tar.gz && cd redis-stable && make

cp src/redis-cli /usr/bin/

2-4. 모니터링 수행

redis-cli -h [endpoint] -p [port]

3. 참고 사항

-. redis-cli를 수행하는 서버에서 redis 클러스터로 통신이 가능하게 보안그룹이 설정되어있어야 한다.

gitlab 버전 업그레이드(docker -compose)

Sungtaek, YOO — Sun, 25 Feb 2024 12:53:52 +0900

1. docker-compose??

docker-compose를 사용하는 이유는 Docker를 사용하면서 도커 수행 시,

부여해야할 많은 옵션을 docker-compose.yaml 파일로 정리해서 손쉽게 기동할 수 있다는 장점이 있다.

docker-compose up -d
docker-compse down

또는, 프로세스 기동 시, 여러개의 서비스가 같이 기동되어야하는 경우, 한 번의 기동으로 여 러 서비스를 같이 기동할 수 있다.

(예를들면 프로세스가 기동될 때, nginx, db를 띄워야하는 경우에 같이 정의하여, 'depends_on:' 설정을 수행할 수 있음)

2. gitlab 버전 업그레이드를 수행한 이유?

보안 이슈로 인해...버전 업그레이드가 필요했다.

3. gitlab 버전 업그레이드별 경로?

gitlab 홈페이지를 방문하면 '현재 버전' -> '희망 버전'으로 업그레이드 시, 어떤 버전을 거쳐야하는지가 명시되어 있다.

(16 버전 -> 16 버전으로 업그레이드하였으므로 저의 경우에는 해당사항 없이 바로 업그레이드)

4. 업그레이드 방법

간단하다. doker-compose.yaml 파일 수정하고, yaml파일내 버전 변경해주면 된다.

version: '3.6'
services:
  web:
    image: 'gitlab/gitlab-ee:16.7.3-ee.0'
    restart: always
    hostname: 'gitlab.your-domain.com'
    environment:
      GITLAB_OMNIBUS_CONFIG: |
        external_url 'https://gitlab.your-domain.com'
    ports:
      - '80:80'
      - '443:443'
      - '10022:22'
    expose:
      - 22
    volumes:
      - '/etc/gitlab:/etc/gitlab'
      - '/var/log/gitlab:/var/log/gitlab'
      - '/var/opt/gitlab:/var/opt/gitlab'
    command: /bin/sh
    command: sh -c "apt update && apt-get install locales && localedef -f UTF-8 -i en_US en_US.UTF-8 && /assets/wrapper"

위와 같이 image 행에서 버전 변경해주고, 재기동을 수행해주면 된다.

docker-compose up -d
docker-compse down

해당 작업을 수행해주면 gitlab이 서비스를 다시 올리면서 image 버전을 참고해, 해당버전을 기동하기때문에 git pull 등을 수행할 필요는 없다.

추가로 gitlab 버전에 따라 변경되는 부분이 있다면, gitlab이 기동되고, 백그라운드에서 내부적으로 마이그레이션을 수행하게 된다(gitlab 웹콘솔 접근해보면 나와있음!)

5. docker-compose를 사용하지 않으면?

docker를 다시 기동하면서 필요한 옵션값들을 수동으로 모두 입력해야하고, gitlab의 경우에는 gitlab 하나만 기동하면 되므로 큰 상관은 없지만, 위에서 언급한 사항처럼 여러개 서비스가 기동되어야 한다면 기동 순서에 따라 문제가 발생할 수 있음(ex. db가 기동되기 전에 was가 기동되는 경우 커넥션 에러 발생 가능)

AWS Console을 통한 EKS 버전 업데이트(1.22->1.25)

Sungtaek, YOO — Sun, 13 Aug 2023 18:36:44 +0900

1. 작업 순서

-. Cluster Version Update → NodeGroup Version Update(노드그룹 업데이트 진행 시, 노드 버전 순차적 업데이트 수행됨)

2. 목적

-. EKS 버전 EOS에 따른 버전 업그레이드(EOS 버전 1.22)

3. 참고 사항

-. 1.22 → 1.25 로 한번에 버전 업데이트는 불가하며, 1.22→ 1.23→ 1.24→ 1.25 순으로 순차 업데이트 진행 필요

-. Cluster&Node Group 버전이 한 단계 업데이트될 때마다 Event, Pod 상태 등 확인 필요

-. Add-on으로 Driver 설치 버전 확인이 필요하고, add-on으로 설치한 게 아니라, helm 등 다른 방식으로 설치한 경우, AWS 콘솔에서 확인이 불가능하며, 삭제 후 add-on으로 설치 혹은 직접 driver 버전 업데이트 등의 프로세스로 작업이 필요함

4. 작업 내용

[Route53] 다른 AWS 계정 Private Hosted Zone 쿼리

Sungtaek, YOO — Sun, 27 Nov 2022 20:24:53 +0900

1. 목적

-. A계정의 EC2에서 B계정의 내부 DNS 쿼리가 필요했고, Public DNS로 노출시키고 싶지 않았음(보안 등의 이슈를 위해)

2. 필요한 정보

a. A 계정 Route53의 Hosted Zone ID
b. A 계정 IAM 사용자 및 Access Key(일회성)
c. B 계정 VPC 사용 리전, ID
d. B 계정 IAM 사용자 및 Access Key(일회성)

3. 진행 방법

-. A 계정에서 Admin 권한(편의상)의 IAM 사용자로 Access key를 발급하고,
Local에서 CLI 환경 준비

-. A 계정의 Route53을 B계정의 리소스가 쿼리할 수 있도록 허용

aws route53 create-vpc-association-authorization --hosted-zone-id <A 계정 Route53의
Hosted zone> --vpc VPCRegion=<B 계정의 VPC 리전>,VPCId=<B 계정의 VPC ID> --profile sun
gtaek.yoo-security

-. B 계정의 IAM Access key로 A 계정 Route53 연결

aws route53 associate-vpc-with-hosted-zone --hosted-zone-id 
<A 계정 Route53의 Hosted zone> --vpc VPCRegion=<B 계정의 VPC 리전>,
VPCId=<B 계정의 VPC ID> --region ap-northeast-2 --profile sungtaek.yoo

4. 완료 확인

-. 설정대로 진행이 완료되었으면, 설정한 VPC 환경내 인스턴스에서 nslookup 시, 확인 가능

B 계정 서버에서 A 계정 Route53에 등록된 Private 영역 쿼리 가능!!

혹은,

-. A 계정의 Route53 콘솔에서도 확인가능

이렇게까지 사용할 이유는 대부분의 경우, 없으시겠지만 혹시나 필요하신 분이 있을 수 있어 내용을 공유합니다.

[CloudWatch] LogGroup으로 로그 보내기

Sungtaek, YOO — Tue, 9 Aug 2022 00:01:34 +0900

1. 목적

인스턴스에서 발생하는 로그(ex. /var/log/message)를 보기좋게 백업하고 확인할 수 있는 방법 중 하나는 LogGroup으로 로그를 전달하는 방법이다.

2. 권한 주기

권한을 주는 방법은 생각나는 건, 두 가지이다.

첫째, EC2에 Role을 추가하기. 내가 진행하려는 것은 인스턴스에서 LogGroup으로 로그를 전송하는 것이기 때문에 인스턴스에서 진행하는 것으로 설명 진행.

둘째, 액세스키 생성 후 인스턴스에서 configure 설정하여, LogGroup으로 로그를 전송하는 방법.

3. awslogs 설치

설치는 yum을 통해 진행하면 되므로 간단하다.

yum install -y awslogs

3. conf 파일 설정 변경해주기

첫째.

/etc/awslogs/awscli.conf

파일의 설정을 변경해준다.

변경은 region 을 변경해주면 끝. 리전은 내가 사용하는 리전으로 변경해주면 됨.

둘째.

/etc/awslogs/awslog.conf

이 설정에서는 약간의 커스터마이징(?)이라 해야하나. 어쨋거나 할 수 있다.

이번 테스트에서는 time_zone을 LOCAL로 추가했고, 인스턴스내 어떤 파일을 보낼 것인지를 설정하는 부분.

아래에서는 'file'을 보면 /var/log/messages 파일을 보내게 되어있다.

log_group_name은 로그그룹에 미리 생성해준 LogGroup 이름을 입력해주면 된다.

log_stream_name은 로그그룹에 어떤 이름으로 파일을 남기는지에 대한 부분이고, 인스턴스id와 인스턴스의ip를 표시하게 하였다.

** 빠뜨리면 안되는 것이, awslogs 서비스를 실행시켜야한다.

service awslogs start

4. 결과물

설정을 완료하고, 서비스도 정상적으로 실행시키면 위와 같은 형식으로 로그 확인이 가능하다.

인스턴스에 연결된 볼륨이 어떤 EBS인가

Sungtaek, YOO — Mon, 8 Aug 2022 23:17:02 +0900

1. 목적

인스턴스에 EBS 볼륨이 많이 연결 되어있는 경우, 볼륨크기 조정과 같이 특정 디스크를 수정하고자 하는 EBS가 무엇인지 알아보기 힘들다. 볼륨의 크기(GB)가 다른 경우에는 EBS 볼륨 크기로 찾아볼 수 있으나, 동일한 볼륨크기가 여러개인 경우에는 더 알아보기 힘들다.

2. 찾을 수 없는 볼륨(EBS ID)

'df -hT' 명령어를 입력해도 알 수 없음.

'lsblk' 명령어를 통해서도 알 수 없음

fstab에서도 알 수 없음

'fdisk -l' 명령어로도 확인 불가

3. 어떻게 확인할 수 있나?

우선 어떤 디스크를 확인할 것인지 알아볼 것.

위 캡처를 기준으로 nvme1n1 볼륨이 어떤 EBS인지 확인해보고자 한다면,

아래 명령어를 입력한다.

sudo /sbin/ebsnvme-id /dev/nvme1n1

자, 이렇게 'vol'로 시작 하는 볼륨의 ID가 나온다.

그럼, 콘솔에서 어떤 볼륨인지를 확인하면 된다.

[Route53] 가중치 기반 라우팅 정책 적용

Sungtaek, YOO — Wed, 27 Apr 2022 23:22:42 +0900

1. Route53의 가중치 기반 라우팅 적용

-. 가중치 기반 라우팅(Weighted Routing Policy) 적용은 각 서버를 물리적으로 다른 호스트에서 운영할 경우에 적용할 수 있습니다. 예를들어 'IDC를 사용하고 있는 상황에서 클라우드에 서버를 신규로 생성하였고, 완전 클라우드로 이전하기에는 리스크가 있다고 판단하는 경우'(?)도 있을 수 있을거고..혹은 '클라우드에만 서버를 올려서 사용하기 불안하여, IDC와 혼합하여 사용하겠다' 등의 상황이 있겠지만..

해당 라우팅 정책은 각자 목적에 맞게 사용하시면 되겠습니다..

2. Weighted Routing Policy 적용하기

-. 해당 정책을 적용하기 위해서는 레코드 타입이 모두 A 타입으로 생성이 필요합니다.(CNAME과 섞어서 사용해보려하였으나, 레코드를 생성하는 부분에서 에러가 발생하여 생성되지 않음 확인)

레코드 설정은 아래와 같이 진행해주면 됩니다.

->Routing Policy는 Weighted 로 설정.

->Record ID는 고유한 이름으로 설정하도록 하며, 이름 태그로 생각하면 됩니다.(설정하지 않으면 생성이 안됨)

Weight는 두 개의 레코드 비율을 다르게 줄 수 있습니다. 화면에 보이는지 모르겠으나, 0-255까지 숫자를 입력할 수 있으며, 1번 레코드에 10, 2번 레코드에 20을 넣으면 1:2 비중으로 인입됩니다.(0을 넣으면 해당 서버로는 인입이 없음)

3. 테스트 결과

-. curl을 이용하여 총 10번의 테스트를 진행해보았을 때, 신기하게 5번 5번의 횟수로 각 서버에 연결되었습니다. 저의 경우, Weight를 각 10으로 설정해주었고, 직접 테스트해보시면 4번 6번의 결과정도가 출력될 수도 있습니다.

4. Simple Rounting Policy로 A레코드를 2개해볼까?

-. Simple Routing으로 입력되는지 테스트를 해보고자 하였으나...아쉽게도 해당 라우팅 정책으로는 1개 이상이 추가되지 않았습니다.

위와 같이 라우팅 정책이 'Weighted'로 설정되지 않고, 'Simple' 정책으로는 동일한 레코드네임이 입력되지 않습니다.

Simple Policy로 동일한 레코드네임 두 개를 입력했을 때, 발생.

[CloudFront] Invalidation(무효화) 적용하기

Sungtaek, YOO — Tue, 26 Apr 2022 18:18:37 +0900

1. Invalidation 수행 목적

-. 해당 작업을 수행하는 목적은 캐싱 시간이 길게 설정되어있는 경우, 원본(Origin)에서 데이터를 변경하게 되더라도 CF 는 변경 전 값을 계속 캐싱하게 됩니다. TTL 시간동안 Origin 값을 가져오지 않아 변경된 데이터가 출력되지 않습니다.
따라서, 수동으로 CF에 원본 값을 재배포하고자 하는 경우 사용하게 됩니다.

2. Invalidation 수행 방법

1) AWS 콘솔에서 CloudFront 서비스로 이동 후 사용중인 Distributions 선택

2) 특정 Distribution 선택 후 Invalidation 선택

3) Create Invalidation 선택하여, Object path 입력

특정 경로에 대한 Invalidation이 적용되며, 'Create invalidation'을 누르는 즉시 적용됩니다. 해당 작업이 완료되기 전까지는 기존 값을 캐싱합니다.