OpenStack_(2) 환경 구성
MariaDB ~ KeyStone 배포 전

 

이번 작업은 컨트롤러 노드에서만 하면되고, 오픈스택 구성 시 설정하는 비밀번호는 쉽게 하기 위해서 그냥 openstack 으로 하겠습니다.

 

그전에 crudini 라는 ini 파일 수정할 때 사용하기 좋은 툴이 있는데요,, 설정파일 변경할 때 사용하니깐 좋더라구요. 

그래서 이번에도 깔아서 사용해봤습니다.

 

# Install crudini
yum install -y wget
wget https://github.com/pixelb/crudini/releases/download/0.9.3/crudini-0.9.3.tar.gz
tar xvf crudini-0.9.3.tar.gz
mv crudini-0.9.3/crudini /usr/bin/
pip3 install --user iniparse  
ln -s /usr/bin/python3 /usr/bin/python
rm -rf crudini-0.9.3 crudini-0.9.3.tar.gz

crudini를 사용하기 위해서 python이라는 명령어를 사용할 수 있어야 하는데, 만약 /usr/bin/python 라는 파일이 없다고 뜨면 심볼릭 링크를 설정해주면 됩니다!

 

사용법은 데이터베이스 설정 파일 사용할 떄 한번 보여 드리겠습니다.

 

 

 


 

# SQL 데이터베이스 설치 및 설정

- 대부분의 openstack 서비스들은 SQL 데이터베이스를 사용해서 정보를 저장한다.
- 보통 컨트롤러 노드에서 실행
- PostgreSQL을 포함하여 다른 SQL 데이터베이스 또한 지원 가능

yum install -y mariadb mariadb-server python3-PyMySQL

crudini --set /etc/my.cnf.d/openstack.cnf mysqld bind-address 10.177.13.30
crudini --set /etc/my.cnf.d/openstack.cnf mysqld default-storage-engine innodb
crudini --set /etc/my.cnf.d/openstack.cnf mysqld innodb_file_per_table on
crudini --set /etc/my.cnf.d/openstack.cnf mysqld max_connections 4096
crudini --set /etc/my.cnf.d/openstack.cnf mysqld collation-server utf8_general_ci
crudini --set /etc/my.cnf.d/openstack.cnf mysqld character-set-server utf8

cp /etc/my.cnf.d/openstack.cnf /etc/my.cnf.d/openstack.cnf.backup

systemctl restart mariadb.service
systemctl enable --now mariadb.service

mysql_secure_installation

 

crudini --set 이라는 명령어를 사용하면 아래와 같은 형식으로 설정 파일이 변경이 됩니다. 물론 vi 에디터를 사용하여 할 수도 있지만, 많은 설정을 해야할 때는 스크립트처럼 사용하면 유용하겠죠?

 

그리고 항상 설정파일은 백업을 해두셔야 좋습니다!

위 설정을 통해서 만들어진 설정파일입니다. 물론 오픈스택 메뉴얼에 다 나와있구요!

 

 

만약 데이터베이스 재시작이 안되면, selinux 때문일 수도 있으니, 재부팅 한번 하시고 진행하시면 됩니다.

 

 


 

 

# 메시지큐(RabbitMQ) 설치 및 설정

- openstack은 메시지 큐를 사용하여 서비스 간의 작업 및 상태정보를 조정
- 일반적으로 컨트롤러 노드에서 실행
- RabbitMQ, Qpid 등 여러 큐 서비스 지원하지만 대부분 배포판은 RabbitMQ를 지원한다.

 

yum install -y rabbitmq-server

#사용자 추가
rabbitmqctl add_user openstack openstack
rabbitmqctl set_permissions openstack ".*" ".*" ".*"

systemctl enable --now rabbitmq-server.service
systemctl restart rabbitmq-server.service

 

 

 

 


 

 

# Memcached 설치 및 설정
- 서비스를 위한 identity 서비스 인증 메커니즘에서는 토큰을 캐싱하기 위해서 memcached 사용
- 보통 컨트롤러 노드에서 사용
- 프로덕션 배포에서는 해당 구성요소에 대한 보안을 위하여 방화벽, 인증 및 암호화의 조합을 활성화 하는 것을 권장한다.

 

yum install -y memcached python3-memcached
cat /etc/sysconfig/memcached
sed -i 's/127.0.0.1/10.177.13.30/g' /etc/sysconfig/memcached
cp /etc/sysconfig/memcached /etc/sysconfig/memcached.backup

systemctl enable --now memcached.service
systemctl restart memcached.service

항상 crudini를 쓰는 것은 아니구요,,,필요할때만 사용합니다

그리고 설정파일은 백업!

 

 

 


 

# ETCD 설치 및 설정
- openstack 서비스들은 분산 키 잠금 관리, 구성 저장, 서비스가 살아있는지 다른 시나리오에 대한 지속적 추적을 위하여
안정적인 분산 키-값 저장소인 etcd를 사용한다.
- 보통 컨트롤러 노드에서 실행

 

yum install -y etcd

cat /etc/etcd/etcd.conf
cp /etc/etcd/etcd.conf /etc/etcd/etcd.conf.backup

설정 파일 확인 후에 백업 진행합니다.

 

etcd를 관리 네트워크를 통해서 다른 노드로부터 액세스할 수 있도록 하기 위해서 설정 파일을 변경해야합니다.

 

 

 

etcd.conf 파일에 url을 호스트네임으로 지정하니 에러가 뜨더군요..그래서 변수 설정을 해서 진행합니다.

 

CONTROLLER_IP=10.177.13.30
echo ${CONTROLLER_IP}

cat > /etc/etcd/etcd.conf << EOF
#[Member]
ETCD_DATA_DIR="/var/lib/etcd/default.etcd"
ETCD_LISTEN_PEER_URLS="http://${CONTROLLER_IP}:2380"
ETCD_LISTEN_CLIENT_URLS="http://${CONTROLLER_IP}:2379"
ETCD_NAME="controller"
#[Clustering]
ETCD_INITIAL_ADVERTISE_PEER_URLS="http://${CONTROLLER_IP}:2380"
ETCD_ADVERTISE_CLIENT_URLS="http://${CONTROLLER_IP}:2379"
ETCD_INITIAL_CLUSTER="controller=http://${CONTROLLER_IP}:2380"
ETCD_INITIAL_CLUSTER_TOKEN="etcd-cluster-01"
ETCD_INITIAL_CLUSTER_STATE="new"
EOF

systemctl enable --now etcd
systemctl restart etcd

 

변수로 삽입을 하면 자동으로 IP로 변환되기 때문에 자주 사용하는 방법입니다.

 

 

이상.

 

환경 설정은 끝났고, 다음부터는 서비스을 배포하도록 하겠습니다.

 



 

OpenStack_(1) 환경 구성
가상 머신 설치 및 설정 ~ 오픈스택 패키지 설치

 

 

 

 

 

 

VMware에서 네트워크 설정을 이렇게 해놨고, NAT 게이트웨이는 10.177.13.1로 설정했습니다.

Host-only는 내부 통신용이기 때문에 게이트웨이가 필요 없습니다.

 

 

Contoller 가상 머신 설정 입니다.

 

 

 

Compute 가상 머신 설정입니다.

 

 

다른 설정들은 하기 나름이니 중요한 부분만 다루도록 하겠습니다.

참고로 저는 아래와 같이 설정만 했습니다.

 

 

설치 전 네트워크 설정과 호스트네임 설정도 미리 해줍니다.

 

 

 

 


 

 

작업전에 CenOS8은 EOS가 된 OS이기 때문에, 레포지토리 경로 수정부터하고 진행합니다.

 

http://mirrorlist.centos.org -> http://vault.centos.org 로 변경해주시기만 하면됩니다.

 

저는 쉽게 작업하기 위해서 ssh로 접속해서 작업 진행했습니다.

 

mirrorlist 주석 처리, baseurl 주석 해제 후 경로 변경 해주시면 됩니다.

# repo 수정
cd /etc/yum.repos.d
sed -i 's/mirrorlist/#mirrorlist/g' ./CentOS-*
sed -i 's|#baseurl=http://mirror.centos.org|baseurl=http://vault.centos.org|g' ./CentOS-*
cat CentOS-Base.repo

yum clean all
yum install -y vim

 

이렇게 설치가 잘된다면 성공적으로 잘 하신겁니다!!

 

 


 

그 다음 해줘야할 것은 실습 환경을 원활하게 하기 위해서 selinux와 방화벽을 해제 하겠습니다.

위부터 현재 진행하고 있는 작업은 Controller와 Compute 모두 해줘야합니다.

 

selinux는 위 상태가 되도록 해야합니다.

 

방화벽도 해제해줍니다

 

# selinux & firewall 해제
getenforce
setenforce 0
getenforce 
sed -i 's/enforcing/disalbed/g' /etc/selinux/config
cat /etc/selinux/config

systemctl disable --now firewalld
systemctl status firewalld

 

 

 


 

 

이제 네트워크 설정을 해야합니다.

설치 전에 네트워크 설정을 해놨기 때문에, NAT 네트워크(ens160)은 자동으로 올라올 것이고, host-only만 켜주면 됩니다.이후 ip도 한번 확인해주시구요

# network 설정
ip a
nmcli con show
nmcli con up ens192

 

오픈스택 메뉴얼에도 나와있듯이 /etc/sysconfig/network-scripts/ifcfg-INTERFACE_NAME 파일을 아래와 같이 수정해주면 됩니다. 다른 부분은 수정안해도되고 아래의 부분만 수정하시면 됩니다.

DEVICE=INTERFACE_NAME
TYPE=Ethernet
ONBOOT="yes"
BOOTPROTO="none"

 

위 사진 처럼 말이죠 host-only 네트워크(ens192)도 동일하게 설정해줍니다.

 

 

 


 

이제는 /etc/hosts 에 controller와 compute의 IP와 호스트네임을 지정해줘야하는데요. 쉽습니다.

호스트네임으로 핑을 보냈을 때 잘 간다면 성공한 것입니다.

단 /etc/hosts 파일에 127.0.1.1이 localhost로 설정되어 있으면 주석처리 해주셔야합니다. 하지만 저는 안되있기 때문에 넘어가줍니다.

 

 

 


NTP 설정도 해야합니다.

일단 Controller에 정확한 시간을 맞춘 후에 Compute가 Controller를 바라보게 하면 됩니다.

# ntp

# Controller
timedatactl set-timezone Asia/Seoul
yum install -y chrony
vi /etc/chrony.conf
----
...
#pool 2.centos.pool.ntp.org iburst
server time.bora.net iburst
allow 192.168.99.0/24
...
---
systemctl restart chronyd
systemctl enable --now chronyd
timedatectl
chronyc sources -v

# Compute
yum install -y chrony
vi /etc/chrony.conf
----
...
#pool 2.centos.pool.ntp.org iburst
server controller iburst
...
---
systemctl restart chronyd
systemctl enable --now chronyd
timedatectl
chronyc sources -v

시간이 잘 맞는지만 확인해봅니다.

 

 

 

 

 


 

이제 본격적인 openstack 패키지를 받아야합니다.

모든 노드에서 이 작업을 해야합니다. 

OS 버전에 따라서 배포되는 openstack 패키지가 다르니 공식사이트에서 확인후에 패키지 추가 하시면 됩니다.

# 패키지 추가
yum install -y centos-release-openstack-ussuri
yum config-manager --set-enabled powertools

sed -i 's/mirrorlist/#mirrorlist/g' ./CentOS-*
sed -i 's|#baseurl=http://mirror.centos.org|baseurl=http://vault.centos.org|g' ./CentOS-*

yum upgrade -y

# 오픈스택 클라이언트 설치
yum install -y python3-openstackclient

 

 

 

패키지 추가 시에 이렇게 뜬다면 mirrorlist 때문에 그런 것 같습니다.

아까 레포지토리 설정했던 명령어 한번 더 입력해준 후에 upgrade 하면 정상적으로 될 것입니다.

 

 

다음 편에 mariadb부터 초기 환경 구성 진행하겠습니다.!

 

CentOS 8을 이용한 Openstack 환경 구성(1)

 

 

ansible을 이용하여 openstack 구성을 자동화하는 작업을 하려고 합니다. 그전에 메뉴얼 설치를 해봐야 수월하게 yaml 파일 코드를 작성할 수 있을 것으로 생각되 메뉴얼 설치를 진행하려 합니다.

 

openstack은 AWS, GCP, Azure 같은 퍼블릭 클라우드에서 사용하는 것을 입맛에 맞게 구성하여 사용할 수 있도록 하는 오픈소스 기반 클라우드 입니다.

 

자세한 내용은  openstack 공식 사이트에서 메뉴얼을 보시면 많은 도움이 됩니다.

설치도 아래 사이트에서 보고 추가적으로 덧붙여서 진행하는 것이니 참고바립니다.

https://docs.openstack.org/ko_KR/ 

 

OpenStack Docs: Korean

OpenStack 문서에 오신 것을 환영합니다 OpenStack이란? OpenStack은 클라우드 운영체제입니다. 데이터 센터의 컴퓨팅 자원, 스토리지 자원, 네트워크 자원의 대규모 풀을 제어합니다. 이런 것들은 모두

docs.openstack.org

 

 

Controller Node Component

- Nova

- Neutron

- Keystone

- Placement

- Horizon

- Glance

 

Compute Node Component

- Nova

- Neutron

- Cinder (Block Storage)

 

 

Cinder는 Block Storage 서비스를 제공하는 컴포넌트 인데, 원래는 Storage 노드를 따로 설치해서 하는 것을 권장하지만 지금은 테스트를 해볼 것인 관계로 Compute 노드와 같이 구성을 해보겠습니다.

 

또, Controller와 Compute 양쪽에 동일한 서비스가 있습니다. 바로 Nova, Neutron인데요.

각 서비스에 대한 역할이 정해져 있는데, 자세한 설명은 각 서비스를 설치할때 하는 걸로 하고 간단히 설명하자면

Nova -> 오픈스택 컴퓨팅 서비스로써, 클라우드 컴퓨팅 시스템을 호스팅하고 관리하는 서비스 입니다.

Neutron -> 오픈스택 네트워킹 서비스로써, 네트워크 인터페이스 장치를 생성하고 네트워크 연결을 위한 서비스 입니다.

 

 

같은 서비스지만 다른 역할을 하는데요,

우선, 컨트롤러와 컴퓨트는 Master-Worker 구조로, 예전에 k8s에서 한 것과 유사한 구조를 보입니다.

  • 컨트롤러 측 서비스 -> 전체를 관리하는 역할
  • 컴퓨트 측 서비스 -> 각 노드에서 실제 동작을 수행하는 역할

Nova를 비교해보자면,

  • 컨트롤러 측 -> API, Scheduler, Conductor, Novncproxy
  • 컴퓨트 측 -> Compute

Neutron

  • 컨트롤러 측 -> Server, DHCP-agent, Metadata-agent, L3-agent, Openvswitch-agent, ovs-cleanup
  • 컴퓨트 측 -> openvswtich-agent

 

정도로 볼 수 있습니다. 위에서 나온건 실제로 서비스를 구성할 때 설치 항목이나 설정하는 부분에서 확인이 가능합니다.

 

 

 

이제는 실제 구성을 어떻게 할 것인지를 확인해야합니다.

 

먼저, 오픈스택을 설치할 각 노드의 컴퓨팅 리소스를 정해보겠습니다.

 

- Controller Node: 2 코어, 4G 메모리, 100G 스토리지

- Compute Node: 4코어, 8G 메모리, 100G + 100G 스토리지(cinder 구성시 추가할 예정)

 

프로그램: VMware Workstaion 17 Pro

OS: CentOS 8

NIC * 2ea - (외부 - NAT + 내부 - hostonly)

- 외부 -> Contoller (10.177.13.30/24), Compute(10.177.13.40/24)

- 내부 -> Contoller(192.168.99.30/24), Compute(192.168.99.40/24)

 

이 정도로 정해놓고 환경 구성으로 진행해보겠습니다.

 

 

 

 

 

 

 

'클라우드 > Openstack' 카테고리의 다른 글

Openstack_(2) 환경 구성 마무리  (0) 2025.05.22
Openstack_(1) 환경 구성  (0) 2025.05.22

저번에 VPC를 구성하고 퍼블릭, 프라이빗 서브넷을 구축한 후에 IGW(인터넷 게이트웨이)까지 연결을 했습니다. 

아직 테스트까진 안헀는데요!! 오늘은 테스트하고 NAT 게이트웨이를 일반적으로  AWS에서 제공하는 NAT 게이트웨이가 아닌 인스턴스를 이용하여 구성해보겠습니다.

 

이렇게 구성하는 이유는?? 바로 비용 효율적인 측면 때문인데요.

클라우드를 사용하면 일시적으로 빠르고 쉽게 사용할 수 있다는 장점이 있습니다. 하지만 단점으로는 지속적으로 사용할 시 관리가 되지 않는다면 비용 폭탄을 받게 될 수도 있다는 단점이 있죠....! 그래서 프리티어가 끝난 저 또한 비용에 대해서 매우 민감합니다...ㅋㅋㅋ 

 

VPC 구성만으로는 비용이 나오지 않습니다.

EC2 인스턴스를 이용하면 컴퓨팅 비용(t2.micro 제외)과 EBS 볼륨에 대해서만 비용을 부과하고,

NAT 게이트웨이...비용이 생각보다 쌥니다...!

 

그럼 보안 그룹부터 구성을 해보겠습니다.

 

NAT 인스턴스 구성만 보실 분들은 4. NAT 게이트웨이 부터 보시면 됩니다.

 

1. 보안 그룹

보안 그룹(Security Group)은 AWS에서 인스턴스에 대한 인바운드 아웃바운트 트래픽을 제어하는 가상의 방화벽입니다.

물론 보안 그룹도 기본적으로 하나 생성이 되는데요. 저는 따로 생성을 해주겠습니다.

일반적으로 리눅스를 다운받고 테스트하기 위해서 VMware Workstation를 사용하는데요 이럴때는 firewalld, iptabels, ufw 와 같은 방화벽에 의해서 지배를 받습니다. 물론 어떤걸 사용하냐에 따라 다르겠지만요.

하지만 AWS같은 경우는 인스턴스에서 방화벽 설정을 해줄 필요 없이 쉽게 콘솔에서 설정이 가능하다는 것입니다.

 

보안 그룹의 특징

a) 인스턴스 기준 적용 (1차 보안 계층)

b) 룰에 대한 허용 규칙만 적용

c) 아웃바운드 요청에 대한 응답 자동 허용

d) 등록된 모든 규칙을 평가하여 트래픽 허용

e) 특정 그룹을 지정시에만 인스턴스에 적용

 

말이 점점 길어지는데요... AWS Network ACL과도 비교하고 싶지만,,, 그것은 나중에 심도깊게 가고 오늘은 실습 위주로 진행 해보겠습니다.

 

1) "보안 그룹 생성"

보안 그룹을 생성하면 인스턴스를 만들때 바로 사용할 수 있습니다. 테스트 용도로만 사용할 예정이니 한개만 생성해서 퍼블릭, 프라이빗 구분없이 SSH, ICMP 만 열어서 사용을 하도록 하겠습니다.

 

 

2. 키 페어

AWS EC2 인스턴스를 생성하고 ssh 접근을 하기 위해서는 password 방식을 사용하지 않고 공개키 방식을 사용합니다.

물론, password 방식을 사용하게끔 설정할 수 있지만 보안적으로 좋지 못합니다.

공개키는 암호학적인 부분인데, 공개키 알고리즘은 공개키와 개인키 두 개의 키쌍을 이용하여 함호화, 키 분재, 인증을 하는 방식입니다.

쉽게 설명하면 개인키는 말 그대로 서버의 주인이 가지고 있어야하는 키 입니다. 공개 키는 서버에 접근할 수 있어야 하는 사람에게 제공하게 됩니다.

공개 키는 암호화에 사용되고 개인 키는 복호화에 사용하여 올바른 공개키를 가지고 있는 사람이 공개키를 가지고 인증을 하면 접근을 허용하게 해주는 것입니다.

 

간단하니 바로 실습 진행합니다.

 

1) "키 페어 생성"

키 페어를 생성하기 위해서는 이제 VPC가 아니라 EC2로 접속해야합니다!

키 페어 유형은 공개키 알고리즘을 선택하는 것, 키 파일 형식은 어떤 방식으로 접근을 하냐에 따라 방식이 다릅니다.

putty로 접근을 하는 경우에는 .ppk를 선택하시면 됩니다.

 

키를 생성하면 testKey.pem 파일이 다운 받아집니다. 이 키파일 잃어버리지 않게 조심하고 잘 챙겨야합니다.

삭제를 하거나 잃어버리면 인스턴스로 접근을 할 수 없게 되니 주의!! 또 주의!!! 하셔야합니다.

 

생성하는건 생각보다 간단하죠?

 

 

3. EC2

EC2는 AWS에서 인스턴스 또는 EC2 인스턴스라고 불리우는데요 쉽게 생각하시면 가상머신입니다. 서버를 구성할 때 이 인스턴스로 구성을 하게 되죠. 

 

지금 생성하는 인스턴스는 퍼블릭 서브넷에 패치하여 인터넷이 잘 되는지 테스트하기 위함입니다.

 

1)  "인스턴스 시작" - 퍼블릭 서브넷

인스턴스 이름은 멋있는 원하는 이름으로 지정해주시고 저는 OS를 ubuntu로 해주었습니다. 다른 리눅스가 편하신 분들은 그걸로 진행하시면 됩니다.!!

인스턴스 유형은 인스턴스에 할당되는 하드웨어 부분을 선택할 수 있는 것인데요. 당연히 서버의 성능이 좋아지면 가격도 올라가겠죠?? t2.micro는 프리티어가 사용 가능하니 선택해줍니다!

키 페어 꼭 선택해주시구요. 

다음은 중요한 네트워크 설정입니다. "편집"을 눌러서 창을 크게 키워주세요.

퍼블릭 서브넷, 그리고 인터넷이 되려면.. 퍼블릭 IP 즉 공인 IP가 있어야겠죠? 인터넷 게이트웨이가 있다고 한들 공인 IP가 없으면 인터넷 안됩니다! 

그리고 보안 그룹은 이전에 생성한 보안 그룹으로 설정해 줍니다. 다 하셨으면  우측에 "인스턴스 시작"하여 생성 해줍니다.

 

 

2)  인스턴스 접속

저는 mobaXterm을 자주 이용합니다.

Remote host에는 인스턴스의 공인 IP, 그리고 username에는 ubuntu를 넣으시면 됩니다. 만약 amazon linux를 사용하시는 분은 username을 ec2-user로 하시면 됩니다. 

그리고 중요한 PEM 키를 넣어줘야겠죠? "Use private key"를 체크하여 키 페어(.pem)키의 경로를 입력해줍니다.

"OK"를 누른 후에 이런 창이 뜨면 "Accept"를 눌러줍니다.

성공적으로 접근했죠?? 이제 구글의 dns 주소인 8.8.8.8로 핑을 쏴봅니다.

잘됩니다. 참 간단하죠?

 

동일한 방법으로 프라이빗 서브넷에도 인스턴스를 하나 생성해주겠습니다. 

 

3)  "인스턴스 시작" - 프라이빗 서브넷

이전과 동일한 작업이지만 네트워크 설정만 달라집니다.

퍼블릭 서브넷 인스턴스를 생성할 때는 퍼블릭 IP를 활성화 해줬지만, 프라이빗 서브넷은 퍼블릭 IP가 있으면 안됩니다!! 이게 있으면,,,왜 프라이빗..? 그쵸? 

다 똑같이 진행하지만 퍼블릭 IP만 비활성화 해줍니다.

 

근데 여기서 하나 문제!! 퍼블릭 IP가 없으면 어떻게 프라이빗 서브넷에 있는 인스턴스에 접근합니까??

 

답은 Bastion 인스턴스를 생성해 접근하면 됩니다. Bastion은 jump server, jump box, jump host 등등 으로 불리우는 데요. 프라이빗 서브넷의 인스턴스에 접근하기 위한 일종의 게이트웨이 입니다. 프록시 서버랑은 살짝 다른 개념이에요~

 

Bastion은 주로 내부 네트워크 보안 접근을 제공하기 위해 사용되며, 외부 사용자가 내부 서버에 직접 접속하는 것을 방지합니다. 내부 서버로 들어가기 위한 중간 다리라고 생각하심 됩니다.

 

프록시 서버는 클라이언트와 서버 간의 통신을 중계하는 것입니다. 사용자의 요청을 대신하여 외부 서버와 통신하는 것이므로 Bastion과 차이가 있습니다~

 

4)  내부 인스턴스 접근

점프서버를 따로 생성해야 할까요..?? 아니요~ 이전에 테스트 용으로 만들어 놓은 인스턴스는 이제 Bastion 입니다...ㅋㅋ

ssh를 이용하여 접근해보죠 근데 그렇게 하기 위해서는 이 인스턴스에도 공개 키가 있어야겠죠?? 파일을 옮겨와 사용해보겠습니다. 

mobaXterm의 가장 유용한 기능 파일을 드래그만 하면 바로 가져올 수 있습니다..!

다른 방법은 그냥 testKey.pem 파일을 노트패드로 열어 복사해와도 됩니다!

 

이제 접근해보겠습니다. 그전에 내부 서버의 사설 IP를 확인해야겠죠?

인스턴스를 선택하면 아래 프라이빗 주소가 나옵니다.

testKey.pem 파일을 chmod를 이용해 600(-rw-------)으로 변경해주고 ssh 를 통해 접근해주니 성공적으로 접근했죠?

 

외부 핑테스트 까지 해보겠습니다.

네 트래픽이 나가지 않죠? 정상입니다. 오해하지 마세요!!

 

NAT 게이트웨이는 프라이빗 서브넷에 있는 인스턴스가 외부와 통신할 수 있게끔 도와줍니다. 하지만 따로 생성을 하지 않았죠??

 

이제 해보겠습니다.

 

 

 

4. NAT 게이트웨이

NAT게이트웨이는 퍼블릭 서브넷에 존재해야합니다. 프라이빗 서브넷의 인스턴스가 외부로 통신하게끔 도와주려면 NAT 게이트웨이도 공인 IP가 할당되어 있어야 하기 때문이죠

 

하지만 비용이 너무 비쌉니다. 그 해결법 중 하나가 인스턴스를 하나 생성해 마스커레이드 설정하여 NAT로 사용하는 것입니다.

리눅스에는 iptalbes나 netfilter와 같은 유용한 네트워크 기능이 많고 커널단에서 NAT와 같은 기능이 지원합니다. 많은 트래픽을 보내야한다면 그냥 NAT 게이트웨이를 쓰는 편이 더 좋겠지만 테스트용 서버일 경우에는 안정성이나 성능이 크게 상관없기 때문에, 진행해보겠습니다.

 

하지만 약간 손이 가는 작업이라면, 고가용성을 위해서 MultiAZ를 사용하는 경우에는 각 AZ 마다 생성을 해줘야한다는 점!!

 

여기서부터는 좀 복잡합니다!

https://docs.aws.amazon.com/ko_kr/vpc/latest/userguide/work-with-nat-instances.html

 

프라이빗 리소스가 VPC 외부에서 통신할 수 있도록 지원 - Amazon Virtual Private Cloud

이 페이지에 작업이 필요하다는 점을 알려 주셔서 감사합니다. 실망시켜 드려 죄송합니다. 잠깐 시간을 내어 설명서를 향상시킬 수 있는 방법에 대해 말씀해 주십시오.

docs.aws.amazon.com

AWS에서 제공하는 docs 입니다. 참고하셔서 작업하시면 됩니다.

 

저는 이전에 프라이빗은 2c 퍼블릭은 2a에 만들어서 얼릉 2c에 퍼블릭 서브넷을 만들어 보겠습니다.

빠르게 2c에 퍼블릭 서브넷을 생성하고 라우팅 테이블에 추가하였고, 인스턴스까지 생성했습니다.

보안 그룹도 NAT 인스턴스에 맞게 설정해줬습니다. 위 가이드 docs 사이트에 AWS에서 권장하는 보안그룹 설정이 있으니 참고하시면 됩니다.

 

 

1)  서버 사전 작업

# set root passwd
sudo passwd

# update && upgrade 
sudo apt update && sudo apt upgrade -y

# install net-tools
sudo apt install -y net-tools

업그레이드 되면 재부팅 해주시면 됩니다!!

# reboot
sudo reboot

 

 

2)  IP Forwading과 마스커레이딩 활성화

# enable ip forwarding
sudo sysctl -w net.ipv4.ip_forward=1
또는
/proc/sys/net/ipv4/ip_forward 값을 1로 변경

하지만 둘다 영구적으로 활성화되는 것이 저장되지 않는다.

# 영구 활성화
sudo vi /etc/sysctl.conf

ip_forward 부분 주석 해제

# 구성 파일 적용
sudo sysctl -p

# 마스커레이딩 활성화할 인터페이스 확인
netstat -i

# 마스커레이딩 활성화
sudo /sbin/iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

# 저장
sudo /sbin/iptables-save

 

3)  소스/대상 확인 변경

라우터에는 Reverse Path Forwarding이라는 개념이 있는데, 기본적으로 쓸데없는 패킷이 라우터간에 왔다 갔다 돌아나오는 것을 방지하도록 설정되어 있습니다.

인스턴스로 NAT를 사용하려면 이것을 비활성화 해야합니다. 그렇지 않으면 다 잘 되있어도 패킷이 오지 않습니다.!

이렇게 설정 후 저장 해줍니다.

 

4)  라우팅 테이블 편집

위 작업까지 다 했다면 라우팅 테이블 편집을 하면 됩니다.

프라이빗 라우팅 테이블을 선택해주고 라우팅 편집을 해야합니다.

모든 IP를 대상으로 nat 인스턴스를 선택해줍니다. -> 변경사항 저장

 

 

5)  테스트

이제 테스트만 남았습니다. 위 사진은 프라이빗 서브넷에 있는 10.0.10.10의 IP를 가지고 있는 인스턴스입니다. 물론 이전에는 통신이 안됬는데요. 설정을 하고나니 이제 통신이 되는 모습입니다.

 

이렇게 인스턴스를 통해서 NAT 게이트웨이를 구성했습니다. AWS docs에 자세한 설명도 있으니 잘 참고해서 직접 실습해보시면 도움 많이 될 것 같습니다.

 

오랜만에 블로그 글을 씁니다~~

이전에 클라우드 교육을 받은 적이 있는데요. 이전에 배운것을 까먹으면 안되기 때문에 다시 차근차근 블로그에 작성하며 이전 기억을 되살려 보려고 합니다. 

 

오늘은 AWS를 처음 이용하는 초심자에게 적합하게 쉽게 설명하며 수동으로 VPC 구성을 해보려합니다. 요즘은 VPC 구성을 자동으로 해주긴하지만 "그래도"!! 수동으로 구성하는 것이 기본이기 때문에 빠질 수 없겠죠?

기초부터 천천히 한 번 시작해보겠습니다

 

 

1. 리전 (Region)

클라우드를 사용하는데 리전이라는 말을 많이 사용하는데요. AWS가 전 세계에 가지고 있는 데이터 센터의 물리적 위치를 리전이라고 합니다.

콘솔에서도 확인할 수 있는데요. 이것들이 리전을 나타내죠 서울도 있고 가까운 오사카에도 리전이 있는 것으로 보입니다.

 

 

2. 가용영역(AZ)

각 리전에는 가용영역이라고 하는 격리된 위치의 여러 개의 데이터센터를 가지고 있습니다. 가용성(서버가 지속적으로 유지하는 것을 보장하는 것)이 보장되기 위해서 데이터센터가 하나만 있으면 안되겠죠?? 보조로 두 세개는 있어야 한다는 것입니다.

쉽게 설명하자면 안경을 하나만 사용하는데 안경이 부서지면 예비 안경이 있어야 합니다. 안경을 착용하는 사람은 공감하겠지만 1개만 가지고 있지는 않죠?? 이렇게 생각하면 쉽습니다!

그래서 나중에 직접 실습해볼때 보겠지만 서울에는 4개의 가용영역이 있습니다. 각각 다른 지역의 데이터센터에서 자원을 사용하는 것이죠.

 

 

3. VPC(Virtual Private Cloud)

AWS를 사용할 줄 안다면 필수적으로 알아야하는 개념인데요.

VPC는 클라우드 환경에서 퍼블릭과 프라이빗으로 논리적으로 독립된 네트워크 영역을 의미합니다. VPC 안에는 서브넷, 라우팅테이블, 인터넷 게이트웨이, NAT 게이트웨이, 보안 그룹 등등 다양한 구성요소로 이루어져있습니다.

 

좀 쉽게 하려면 네트워크에 대한 부분이 깊게는 아니더라도 좀 알고 있어야 이해가 쉽게 될 것 같습니다.

실습을 위주로 설명을 계속 진행하겠습니다.

!실습!

1. VPC 생성을 눌러줍니다!

 

2. "VPC 만" 을 선택하고 아래와 같이 설정해줍니다.

여기서 "VPC 등"을 선택하면 자동으로 서브넷과 라우팅 테이블을 다 구성해줍니다. 저희는 수동으로 할 것 이기 때문에 "VPC 만"으로 설정해줍니다.

 

IPv4 CIDR은 사용할 사설 IP 대역대를 설정해주는 것인데요. 10.0.0.0/16 으로 설정하여 10.0.0.1 ~ 10.0.255.255 총 65534 개를 사용할 수 있도록 해줍니다.

잘 생성된 모습입니다. 이제 바로 서브넷으로 가봅시다.

 

그리고 수동으로 구성할 땐 이 순서를 잘 기억해 주셔야합니다!

 

 

4. 서브넷(Subnet)

서브넷은 서브네트워크를 줄임말입니다. IP 네트워크의 논리적인 영역을 부분적으로 나눈 하위 망을 말하는 것이죠.

10.0.0.0/16은 65534개를 사용할 수 있다고 했습니다. 여기서 서버는 10대만 있으면 되는데 10.0.0.0/16을 하면 IP가 낭비되겠죠?? 그것을 방지하기 위해서 각 서브넷으로 논리적으로 IP를 나눠주는 것입니다.

 

예시, 10.0.0.0/16 은 10.0.0.0 ~ 10.0.0.1 ~ 10.0.255.255 입니다. 

A subnet (10.0.0.0/24) => 10.0.0.0 ~ 10.0.0.255 까지  사용 가능합니다.

B subnet (10.0.10.0/24) => 10.0.10.0 ~ 10.0.0.255 까지 사용 가능합니다.

 

VPC에서 할당한 IP 대역대를 벗어나지 않고 서브넷으로 논리적으로 한번 더 나눠 주는 것이죠. VPC CIDR를 벗어나지 않는다면 서브넷을 몇개로 나눠도, 몇 개를 생성해도 상관없습니다. 다만 관리적인 측면에서도 생각을 해야하죠.

 

그래서 서브넷은 인터넷에 노출되어 있는 퍼블릭 서브넷과 인터넷에 노출되어 있지 않고 숨겨져있는 프라이빗 서브넷으로 나눠집니다.  여기서도 중요한 것이 있는데, 진행하면서 계속 설명을 해드리겠습니다~!!

 

 

!실습!

1. "서브넷 생성"을 눌러줍니다.

 

2. 이전에 생성한 VPC를 선택해줍니다.

 

이제 서브넷을 생성할 건데요 저는 그냥 간단히 2개만 생성해 보겠습니다.

 

쉽게 작업을 하기 위해서는 네이밍 작업도 중요합니다.

첫 번째 서브넷은 public 서브넷으로 설정을 하기 위해서 pub라는 네이밍을 해줍니다. SB는 subnet입니다.

가용영역은 ap-northeast-2a로 설정해줍니다. 지정해주지 않으면 랜덤으로 배치되니 꼭 확인해주셔야합니다!

 

그리고 아까 가용역역에 대해서 설명했었죠? 서브넷을 생성할 때 가용영역에 대한 항목이 있습니다.

2a,2b,2c,2d 즉, 서울 리전에는 4개의 가용영역이 있다. 이렇게 설명이 가능하고, 고가용성 보장을 위해서는 서브넷을 서로 다른 가용영역에 배치를 해야합니다.

 

두 번째 서브넷 입니다. CIDR는 10.0.10.0/24로 설정해줍니다. 가용영역은 ap-northeast-2c 입니다.

이후 서브넷을 생성해줍니다.

 

잘 생성되었습니다.

 

 

4. 인터넷 게이트웨이(Internet GateWay)

인터넷 게이트웨이는 VPC와 인터넷간의 논리적인 연결입니다. 1개의 VPC당 1개의 IGW만 연결이 가능하며 IGW가 연결이 되어 있지않다면 그 서브넷은 폐쇠망 즉, 인터넷이 되지 않습니다.

인터넷 게이트웨이는 양방향으로 연결을 지원하기 때문에 외부 인터넷에서 퍼블릭 서브넷의 퍼블릭 IP로도 정상적인 통신이 가능한 것이죠!

 

 

!실습!

1. "인터넷 게이트웨이 생성"을 눌러줍니다.

 

2. 네이밍 후 "인터넷 게이트웨이 생성"을 눌러줍니다.

처음 생성하면 상태가 Detached 로 되어 있습니다. 이유는 VPC와 연결을 아직 시켜주지 않아서 그런것ㅇ비니다. 당황하지 말고 계속 진행합니다.

 

 

2. 작업 -> VPC 연결 -> test-vpc 선택

이제 정상적으로 Attached 가 되었습니다. VPC에 IGW가 붙었다는 말이죠. 하지만 붙이기만 해서는 안됩니다!!

라우팅 테이블에 추가해줘야 퍼블릭 서브넷에 인터넷이 되겠죠?

 

5. 라우팅 테이블(Routing Table)

VPC를 생성하면 자동으로 가상 라우터가 생성됩니다. 이 가상 라우터에는 각각 분리된 네트워크의 주소(VPC)를 나타낼 수 있는 라우팅 테이블이 정의되어 있는데요.

참, 라우터는 데이터 패킷을 목적지로 최적의 경로로 전송시켜주는 장치입니다. 최적의 경로를 지정해주는 것이 라우팅 테이블에 정의되어 있지요. 자세한 내용은 검색을 해서 찾아보기를 추천드립니다...!

 

 

처음에는 기본으로 생성되는 라우팅 테이블이 있지만, 실습을 위해서 따로 설정해줄 것입니다.

 

 

!실습!

1. "라우팅 테이블 생성"을 눌러줍니다.

기본적으로 생성되어 있는 라우팅 테이블이 있는데요 무시하고 새로 두개를 만들어줄것입니다.

이렇게 라우팅 테이블이 잘 생성되었습니다. 여기서 중요한 내용을 알려드리겠습니다.

 

 

지금 생성한 서브넷과 라우팅 테이블에 pub과 pri 이라고 네이밍을 해줬습니다. 그럼 네이밍을 해준 것만으로 퍼블릭 서브넷과 프라이빗 서브넷이 자동으로 설정될까요??

 

답은 아닙니다. 서브넷이 퍼블릭과 프라이빗으로 나눠지는 것은 바로 인터넷과 통신할 수 있도록 도와주는 게이트웨이인 IGW(인터넷 게이트웨이) 유무에 따라서 나눠집니다.

 

즉, 라우팅 테이블IGW가 들어가 있다면. 퍼블릭 서브넷 으로 분류

라우팅 테이블에 프라이빗 서브넷이 외부와 통신할 수 있도록 도와주는 NAT 게이트웨이에 들어가 있다면 프라이빗 서브넷으로 분류 됩니다.

 

어떤 식으로 서브넷이 나눠지고 나눠지는 기준이 무엇인지에 따라 정확히 확인하고 설명할 줄 알 필요가 있습니다.

 

 

2. "test-pub-RT"에 IGW 경로 추가하기

현재는 퍼블릭 서브넷에 IGW가 라우팅 테이블에 추가되어 있지 않은 것을 확인할 수 있는데요. 작업을 해보겠습니다.

 

 

3. "라우팅 편집" -> "라우팅 추가"

 

라우팅 추가를 해줬습니다. 대상은 0.0.0.0/0으로 설정해줍니다. 의미는 모든 IP의 접근을 허용하겠다. 라는 의미입니다. 

후에 인터넷 게이트웨이를 눌러주면 생성했던 인터넷 게이트웨이가 뜨는 것을 확인할 수 있습니다.

이후에 "변경 사항 저장"을 눌러줍니다.

이제 이 라우팅 테이블은 인터넷 게이트웨이가 포함이 되어 있습니다. 그럼 이 라우팅 테이블을 퍼블릭 서브넷에 연결시켜줘야겠죠?!!

 

헷갈릴 수도 있겠지만 모든 것이 논리적으로 나눠져있고 그것을 연결을 시켜주는 것입니다.

 

 

 

4. "서브넷 연결" -> "서브넷 연결 편집" -> 퍼블릭 서브넷 선택

여기서 퍼블릭 서브넷을 선택해줍니다. 

프라이빗 서브넷은 선택하시면 안됩니다!!! 그럼 프라이빗이 프라이빗이 아니게됩니다....!

그리고 VPC 만들 때 생성된 - 이름을 가진 기본 라우팅 테이블에서 퍼블릭 라우팅 테이블을 기본으로 설정해줍니다.

 

이제 깔끔하네요!

 

 

오늘은 여기까지하고 다음 포스트에서는 NAT 게이트웨이 부터 진행을 해보도록 하겠습니다.

 

 

'클라우드' 카테고리의 다른 글

AWS EC2 인스턴스를 이용해 NAT 구성하기  (2) 2024.10.02

항목 중요도: 상

 

3.12. Sendmail 버전 점검

  • 점검 내용: 취약한 버전의 Sendmail 서비스 이용 여부 점검
    • Sendmail 서비스의 경우 최신 버전 이하 대부분의 버전에서 취약점이 보고되고 있기 때문에 O/S 관리자, 서비스 개발자가 패치 적용에 다른 서비스 영향 정도를 파악하고 주기적인 패치 적용 정책을 수립하여 적용함
  • 점검 목적: Sendmail 서비스 사용 목적 검토 및 취약점이 없는 버전의 사용 유무 점검으로 최적화된 Sendmail 서비스의 운영
  • 보안 위협: 취약점이 발견된 Sendmail 버전의 경우 버퍼 오버플로우 공격에 의한 시스템 권한 획득 및 주요 정보 요출 가능성이 있다
# Sendmail 서비스 실행 여부 점검
ps -ef | grep -i 'sendmail'

# Sendmail 버전 점검
nc localhost 25

# 조치 방법
Sendmail 서비스를 사용하지 않을 경우 -> 서비스 중지, 재부팅 후 다시 시작하지 않도록 시작스크립트 변경
Sendmail 서비스를 사용할 경우 -> 패치 관리 정책 수립 후 주기적인 패치 적용

 

 

3.13. 스팸 메일 릴레이 제한

  • 점검 내용: SMTP 서버의 릴레이 기능 제한 여부 점검
    • SMTP(Simple Mail Transfer Protocol): 인터넷상에서 이메일을 전송할 때 이용하게 되는 표준 통신 규약이다. SMTP에 의해 전자 메일을 발신하는 서버를 SMTP 서버 라고 한다
  • 점검 목적: 스팸 메일 서버로의 악용 방지 및 서버 과부하의 방지를 위함
  • 보안 위협: SMTP 서버의 릴레이 기능을 제한하지 않는 경우, 악의적인 사용목적을 가진 사용자들이 스팸메일 서버로 사용하거나 DoS 공격의 대상이 될 수 있음
# SMTP 서비스 사용 여부 및 릴레이 제한 옵션 확인
ps -ef | grep sendmail | grep -v "grep"
cat /etc/mail/sendmail.cf | grep "R$\" | grep -i "relaying denied"

# 조치 방법
1. vi /etc/mail/sendmail.cf

2. 아래와 같은 조치를 취한다
(전) #R$* $#error $@ 5.7.1 $: "550 Relaying denied"
(후) R$* $#error $@ 5.7.1 $: "550 Relaying denied"

3. 특정 IP, domain, Email Address 및 네트워크에 대한 sendmail 접근 제한 확인(없을 시 생성)
cat /etc/mail/access
ex)
localhost,localdomain	RELAY
localhost				RELAY
127.0.0.1				RELAY
spam.com				REJECT

4. 수정했거나 생성했을 경우 DB 파일 생성
makemap hash /etc/mail/access.db < /etc/mail/access

 

 

3.14. 일반 사용자의 Sendmail 실행 방지

  • 점검 내용: SMTP 서비스 사용 시 일반 사용자의 q 옵션 제한 여부 점검
  • 점검 목적: 일반 사용자의 q 옵션을 제한하여 Sendmail 설정 및 메일큐를 강제적으로 drop 시킬 수 없게 하여 비인가자에 의한 SMTP 서비스 오류 방지
  • 보안 위협: 일반 사용자가 q 옵션을 이용하여 메일큐, Sendmail 설정을 보거나 메일큐를 강제적으로 drop 시킬 수 있어 악의적으로 SMTP 서버의 오류를 발생시킬 수 있음
# SMTP 서비스 사용 여부 및 restricqrun 옵션 확인
ps -ef | grep -i 'sendmail' | grep -v 'grep'
grep -v '^ *#' /etc/mail/sendmail.cf | grep -i 'privacyoptions'

# 조치 방법
1. vi 편집기를 사용하여 sendmail.cf 설정파일 열기
2. O PrivacyOptions= 설정 부분에 restrictqrun 옵션 추가
(전) O PrivacyOptions=authwarnings, novrfy, noexpn
(후) O PrivacyOptions=authwarnings, novrfy, noexpn, restrictqrun

3. Sendmail 서비스 재시작

 

 

3.15. DNS 보안 버전 패치

  • 점검 내용: BIND 최신버전 사용 유무 및 주기적 보안 패치 여부 점검
    • BIND(Berkeley Internet Name Domain): BIND는 BSD 기반의 유닉스 시스템을 위해 설계된 DNS로 서버와 resolver 라이브러리로 구성되어 있음.
    • 네임서버는 클라이언트들이 이름 자원들이나 객체들에 접근하여, 네트워크 내의 다른 객체들과 함께 정보를 공유할 수 있게 해주는 네트워크 서비스로 사실상 컴퓨터 네트워크 내의 객체들을 위한 분산 데이터베이스 시스템이다
  • 점검 목적: 취약점이 발표되지 않은 BIND 버전의 사용을 목적으로 함
  • 보안 위협: 최신버전 이하의 버전에서는 서비스 거부 공격, 버퍼오버플로우 및 DNS 서버 원격 침입 등의 취약성이 존재함
# DNS 서버 사용 및 BIND 버전 확인
ps -ef | grep -i 'named'
named -v

# 조치 방법
DNS 서비스 사용 X -> 서비스 중지
DNS 서비스 사용 O -> 패치 관리 정책을 수립하여 주기적으로 패치 적용

 

 

3.16. DNS Zone Transfer 설정

  • 점검 내용: Secondary Name Server로만 Zone 정보 전송 제한 여부 점검
    • DNS Zone Transfer는 Primary Name Server와 Secondary Name Server 간에 Zone 정보를 일관성 있게 유지하기 위하여 사용하는 기능
  • 점검 목적: 허가되지 않은 사용자에게 Zone Transfer를 제한함으로써 호스트 정보, 시스템 정보 등 정보 유출의 방지를 목적으로 함
  • 보안 위협: 비인가자 Zone Transfer를 이용해 Zone 정보를 전송받아 호스트 정보, 시스템 정보, 네트워크 구성 형태등의 많은 정보를 파악할 수 있음
<DNS 서비스를 사용할 경우>
# DNS서비스 사용 시 /etc/named.conf 파일의 allow-transfer 및 xfrnets 확인
ps -ef | grep -i 'named' | grep -v 'grep'
cat /etc/named.conf | grep 'allow-transfer'
cat /etc/named.conf | grep 'xfrnets'

# BIND8 DNS 설정 수정 예
Options {
			allow-transfer (존 파일 전송을 허용하고자 하는 IP;);
};

# BINd4.9 DNS 설정 수정예
Options
			xfrnets 허용하고자 하는 IP
            

<DNS 서비스를 사용하지 않는 경우>
# DNS 서비스 데몬 확인 (DNS 동작 SID 확인)
ps -ef | grep 'named'

# 조치 방법
kill -9 [PID]

 

3.17. 웹 서비스 디렉터리 리스팅 제거

  • 점검 내용: 디렉터리 검색 기능의 활성화 여부 점검
  • 점검 목적: 외부에서 디렉터리 내의 모든 파일에 대한 접근 및 열람을 제한함을 목적으로 한다
  • 보안 위협: 디렉터리 검색 기능이 활성화 되어 있을 경우, 사용자에게 디렉터리 내의 파일이 표시되어 웹 서버의 구조 및 백업파일, 소스파일, 중요한 공개되어서는 안되는 파일들이 노출될 수 있다
# Indexes 옵션 사용 여부 확인
cat /[apache home]/conf/httpd.conf | grep -i 'indexes'

# 조치 방법
1. vi /[apache home]/conf/httpd.conf

2. 설정된 모든 디렉터리의 Options 지시자에서 Indexes 옵션 제거
(수정 전)
<Directory />
 	Options Indexes FollowSymLinks
	AllowOverride None
 	Order allow, deny
 	Allow from all
</Directory>

(수정 후)
<Directory />
 	Options FollowSymLinks -> Indexes 삭제 또는 -Indexes
	AllowOverride None
 	Order allow, deny
 	Allow from all
</Directory>

 

3.18. 웹 서비스 웹 프로세스 권한 제한

  • 점검 내용: Apache 데몬이 root 권한으로 구동되는지 여부 점검
  • 점검 목적: Apache 데몬을 root 권한으로 구동하지 않고 별도의 권한으로 구동함으로 써 침해사고 발생 시 피해 범위 확산 방지를 목적으로 함
  • 보안 위협: 웹 서비스 데몬을 root 권한으로 실행 시 웹 서비스가 파일을 생성 수정하는 과정에서 웹 서비스에 해당하지 않는 파일도 root 권한에 의해 쓰기가 가능하며 공격자의 공격에 의해 root 권한이 노출 될 수 있음
# Apache 데몬 구동 권한 (User 및 Group) 확인
vi /[aoache_home]/conf/httpd.conf

# 조치 방법
1. 데몬 User & Group 변경 -> root 가 아닌 별도의 계정으로 변경
* 웹 서비스 실행 계정은 로그인이 불가능하도록 쉘 제한 필수!

User [root가 아닌 별도 계정]
Group [root가 아닌 별도 계정]

2. apache 서비스 재시작

 

3.19. 웹 서비스 상위 디렉터리 접근 금지

  • 점검 내용: ".."와 같은 문자 사용 등으로 상위 경로로 이동이 가능한지 여부 점검
  • 점검 목적: 상위 경로 이동 명령으로 비인가자의 특정 디렉터리에 대한 접근 및 열람을 제한하여 중요 파일 및 데이터 보호를 목적으로 함
  • 보안 위협: 상위 경로로 이동하는 것이 가능할 경우 접근하고자 하는 디렉터리의 하위 경로에 접속하여 상위경로로 이동함으로 써 악의적인 목적을 가진 사용자의 접근이 가능해진다
# AllowOverride 지시자 Authconfig 옵션 확인
cat /[apache_home]/conf/httpd.conf | grep -i 'allowoverride'


# 조치 방법
1. vi /[apache_home]/conf/httpd.conf

2. 설정된 모든 디렉터리의 AllowOverride 지시자에서 Authconfig 옵션 설정
(수정 전)
<Directory “/usr/local/apache2/htdocs”>
 	AllowOverride None
 	Allow from all
</Directoty>
 
 (수정 후)
 <Directory "/usr/local/apach2/htdocs">
 	AllowOverride Authconfig
    Allow from all
 </Directory>
 
 3. 사용자 인증을 설정할 디렉터리에 .htaccess 파일 생성 (아래 내용 삽입)
 AuthName "디렉터리 사용자 인증"
 AuthType Basic
 AuthUserFile /usr/local/apache/test/.auth
 Require valid-user
 
 4. 사용자 인증에 사용할 아이디 및 패스워드 생성
 htpasswd -c /usr/local/apache/test/.auth test
 Password 설정
 
 5. 변경된 설정 내용 저장을 위해 Apache 세몬 재시작
 
 **
 해당 설정이 적용된 디렉터리 내 파일들은 아이디/패스워드 인증절차 없이는 접속이 불가능하며,
 대회 서비스 인 경우 해당 디렉터리에 대한 외부자의 접근 필요성을 검토 후 적용해야함

 

 

3.20. 웹 서비스 불필요한 파일 제거

  • 점검 내용: Apache 설치 시 기본으로 생성되는 불필요한 파일의 삭제 여부 점검
    • 불필요한 파일: 샘플파일, 메뉴얼 파일, 임시 파일, 테스트 파일, 백업 파일
  • 점검 목적: Apache 설치 시 디폴트로 설치되는 불필요한 파일을 제거함을 목적으로 함
  • 보안 위협: htdocs 디렉터리 내에 메뉴얼 파일은 시스템 관련 정보를 노출하거나 해킹에 악용될 수 있다
# 불필요한 파일 및 디렉터리 조재 여부 확인
ls -al /usr/local/apache2/htdocs/manual
ls -al /usr/local/apache2/manual

# 조치 방법
1. ls 명령어로 확인된 메뉴얼 디렉터리 및 파일 제거
rm -rf /usr/local/apache2/htdocs/manual
rm -rf /usr/local/apache2/manual

2. 삭제 후 다시 확인 후, 추가적인 웹서비스 운영에 필요하지 않은 파일이나 디렉터리가 있을 시 제거

 

3.21. 웹서비스 링크 사용금지

  • 점검 내용: 심볼릭 링크, Alias 사용 제한 여부 점검
    • 심볼릭 링크: 윈도우 운영체제의 lnk, 바로가기 아이콘과 비슷하다
    • 링크 파일 생성 시 파일 내용은 존재하지 않으나 사용자가 파일을 요청하면 링크가 가리키고 있는 원본 데이터에서 데이터를 가져와 전달
    • 직접 원본을 가리키지 않고 원본 데이터를 가리키는 포인터를 참조함으로써 원본데이터가 삭제, 이동 수정 되면 사용이 불가함
  • 점검 목적: 무분별한 심볼릭 링크, aliases 사용제한으로 시스템 권한의 탈취 방지를 목적으로 한다
  • 보안 위협: 웹 루트 폴더(DocumentRoot)에 root 디렉터리를 링크하는 파일이 있으며, 디렉터리 인덱싱 기능이 차단되어 있어도 root 디렉터리 열람이 가능함
# Options 지시자에서 FollowSymLinks 옵션 제거
cat /[Apache_home]/conf/httpd.conf | grep -i 'options'

# 조치 방법
1. vi /[Apache_home]/conf/httpd.conf

2. 설정된 모든 디렉터리의 Options 지시자에서 FollowSymLinks 옵션 제거
(수정 전)
<Directory />
	Options Indexes FollowSymLinks
    AllowOverride None
    Order allow, deny
    Allow from all
</Directory>

(수정 후)
<Directory />
	Options Indexes -> FollowSymLinks 삭제 또는 -FollowSymLinks
    AllowOverride None
    Order allow, deny
    Allow from all
</Directory>

 

3.22. 웹 서비스 파일 업로드 및 다운로드 제한

  • 점검 내용: 파일 업로드 및 다운로드 사이즈 제한 여부 점검
    • 불필요한 업로드와 다운로드: 내부 정책에 맞지 않는 업로드와 다운로드를 말함, 예를 들어 5Mb 이상의 대용량 파일이나 확장자를 화이트 리스트 방식으로 제한함
  • 점검 목적: 기반 시설 특성상 원칙적으로 파일 업로드 및 다운로드를 금지하고 있지만 불가피하게 필요할 시, 용량 사이즈를 제한함으로 써 불필요한 업로드와 다운로드를 방지해 서버의 과부하 예방 및 자원을 효율적으로 관리하기 위함
  • 보안 위협: 악의적 목적을 가진 사용자가 반복 업로드 및 웹 쉘 공격 등으로 시스템 권한을 탈취하거나 대용량 반복 업로드로 서버 자원을 고갈시키는 공격의 위험이 있음
# LimitRequestBody 파일 사이즈 용량 제한 설정 여부 확인 -> 업로드 및 다운로드는 5Mb를 넘지 않도록 설정을 권고
cat /usr/local/apache2/conf/httpd.conf | grep -i 'limit'

# 조치 방법
1. vi /usr/local/apache2/conf/httpd.conf

2. 설정된 모든 디렉터리의 LimitRequestBody 지시자에서 파일 사이즈 용량 제한 설정
<Directory />
LimitRequestBody 5000000 (* “/” 는 모든 파일 사이즈를 5M로 제한하는 설정 - 단위:byte)
</Directory>

 

3.23. 웹서비스 영역의 분리

  • 점검 내용: 웹 서버의 루트 디렉터리 와 OS의 루트 디렉터리를 다르게 지정했는지 점검
  • 점검 목적: 웹 서비스 영역과 시스템 영역을 분리시켜서 웹 서비스의 침해가 시스템 영역으로 확장될 가능성을 최고화 하기 위함
  • 보안 위협: 웹 서버의 루트 디렉터리와 OS의 루트 디렉터리를 다르게 지정하기 않았을 경우, 비인가자가 웹 서비스를 통해 해킹을 성공할 경우 시스템 영역까지 접근이 가능해서 피해가 확장 될 수 있음
# DocumentRoot의 별도 디렉터리 지정 여부 확인
cat /[Apache_home]/conf/httpd.conf | grep -i 'documentroot'
DocumentRoot "/usr/local/apache/htdocs" or
DocumentRoot "/usr/local/apache2/htdocs" or
DocumentRoot "/var/www/html"

위의 3개의 경로가 아닌 별도의 디렉터리로 변경

# 조치 방법
1. vi /[Apache_home]/conf/httpd.conf

2. 확인 후 위의 3개의 경로중 하나가 아닌 별도의 디렉터리로 변경

 

항목 중요도: 상

 

3.1. Finger 서비스 비활성화

  • 점검 내용: finger 서비스 비활성화 여부 점검
    • Finger(사용자 정보 확인 서비스): who 명령어가 현재 사용중인 사용자들에 대한 간단한 정보만 보여주는데 반해 finger 명령은 옵션에 따른 시스템에 등록된 사용자 뿐만아니라 네트워크를 통하여 연결되어 있는 다른 시스템에 등록된 사용자들에 대한 자세한 정보를 보여준다
  • 점검 목적: Finger를 통해서 네트워크 외부에서 해당 시스템에 등록된 사용자 정보를 확인할 수 있어 비 인가자에게 사용자 정보가 조회되는 것을 차단하고자 함
  • 보안 위협: 비인가자에게 사용자 정보가 조회되어 패스워드 공격을 통한 시스템 권한 탈취 가능성이 있으므로 사용하지 않는다면 서비스를 중지해야한다
# 확인
# 1. inetd 일 경우
finger stream tcp nowait bin /usr/bin/fingerd
fingerd 주석처리 확인

# 2. xinetd 일 경우
ls -alL /etc/xinted.d/* | egrep "echo finger"

# 조치 방법
# inetd 일 경우
1. 주석처리
(전) finger stream tcp nowait bin /usr/bin/fingerd
(후) #finger stream tcp nowait bin /usr/bin/fingerd

2. inetd 서비스 재시작
ps -ef | grep 'inetd'
kill -HUP [PID]

# xinted 일 경우
1. vi /etc/xinted.d/finger

2. 아래와 같이 설정 (Disable = yes 설정)
service finger
{
	socket_type = stream
    wait = no
    user = nobody
    server = /usr/sbin/in.fingerd
    diable = yes
}

3. xinted 서비스 재시작
systemctl restart xinted

 

3.2. Anonymous FTP 비활성화

  • 점검 내용: 익명 FTP 접속 허용 여부 점검
    • Anonymous FTP: 파일 전송을 위해서는 원칙적으로 상대방 컴퓨터를 사용할 수 있는 계정이 필요하나, 누구든지 계정없이 anonymous 또는 ftp 로그인명과 임의의 비밀번호를 사용하여 ftp를 실행시킬 수 있음
  • 점검 목적: 실행중인 FTP 서비스에 익명 FTP 접속이 허용되고 있는지 확인하여 접속허용을 차단하는 것을 목적으로 함
  • 보안 위협: Anonymous FTP를 사용시 anonymous 계정으로 로그인 후 디렉터리에 쓰기 권한이 설정되어 있다면 악의적인 사용자가 local exploit을 사용하여 시스템에 대한 공격이 가능하다
# 확인 -> /etc/passwd 파일에 ftp 계정 존재 여부 확인
cat /etc/passwd | grep -i 'ftp'

# 조치 방법
1. 일반 FTP -> /etc/passwd에서 ftp 또는 anonymous 계정 삭제
userdel ftp 

2. ProFTP -> conf/proftpd.conf 파일의 anonymous 관련 설정 중 User, Useralias 항목 주석처리
<Anonymous ~ftp>  -> anonymous 설정 구간
# User	ftp		  -> anonymous로 사용되는 계정
Group	ftp
# UserAlias	anonymous ftp -> 별칭으로 사용되는 계정
</Anonymous>

3. vsFTP
vsFTP 설정파일 (/etc/vsftpd/vsftpd.conf 또는 /etc/vsftpd.conf)에서 anonymous_enable=no 로 설정

 

3.3. r 계열 서비스 비활성화

  • 점검 내용: r-command 서비스 비활성화 여부 점검
    • r-command: 인증 없이 관리자의 원격접속을 가능하게 하는 명령어들로 rsh(remsh), rlogin, rexec, rsync 등이 있음
  • 점검 목적: r-command 사용을 통한 원격 접속은 NET Backup 또는 클러스터링 등 용도로 사용되기도 하나, 인증 없이 관리자 원격접속이 가능하여 이에 대한 보안위협을 방지하고자 함
  • 보안 위협: rsh, rlogin, rexec 등의 명령어를 이용하여 원격에서 인증절차 없이 터미널 접속 및 쉘 명령어를 실행이 가능
# 확인
# rsh, rlogin, rexec (shell, login, exec) 서비스 구동 확인
ls -alL /etc/xinted.d/* | egerp "rsh|rlogin|rexec" | egrep -v "grep|klogin|kshell|kexec"

# 조치 방법
1. vi 편집기를 이용해 /etc/xinetd.d/ 디렉터리 내 rlogin,rsh,rexec 파일 열기
2. 아래와 같이 설정 (Disable=yes 설정)
/etc/xinted.d/rloing 파일
/etc/xinted.d/rsh 파일
/etc/xinted.d/rexec 파일

service rlogin
{
	socket_type = stream
    wait = no
    user = nobody
    log_on_success += USERID
    log_on_failure += USERID
    server = /usr/sbin/in.fingerd
    diable = yes
}

3. xinted 서비스 재시작
systemctl restart xinted

4. r-command 사용시 보안 설정 -> 2.13. 참고

 

3.4. crond 파일 소유자 및 권한 설정

  • 점검 내용: cron 관련 파일의 권한 적절성 점검
    • cron 시스템: 특정 작업이 정해진 시간에 주기적이고 반복적으로 실행하기 위한 데몬 및 설정
    • cron.allow: 사용자 ID를 등록하면 등록된 사용자는 crontab 명령어 사용이 가능
    • cron.deny: 사용자 ID를 등록시 등록된 사용자는 crontab 명령어 사용 불가능
  • 점검 목적: 관리자 외 cron 서비스를 사용할 수 없도록 설정하고 있는지 점검하는 것을 목적으로 함
  • 보안 위협: root 외 일반 사용자에게도 crontab 명령어를 사용할 수 있도록 할 경우, 고의 또는 실수로 불법적인 예약 파일을 실행으로 시스템 피해를 일으킬 수 있음
# 확인
1. cron 관련 파일 권한 확인
ls -al /usr/bin/crontab

2. 점검 파일 확인
/etc/
- crontab -> 예약 작업 등록 파일
- cron.hourly -> 시간 단위
- cron.daily -> 일 단위
- cron.weekly -> 주 단위
- cron.monthly -> 월 단위
- cron.allow -> 명령어 허용 유저
- cron.deny -> 명령어 차단 유저

3. 사용자별 설정된 cron 작업 목록 확인
/var/spool/cron
/var/spool/cron/crontabs

# 조치 방법
## 공통 설정
1. crontab 일반 사용자 권한 삭제 (crontab 명령어는 SUID 설정이 되어있음 -> 설정 제거)
ls -al /usr/bin/crontab
chmod 750 /usr/bin/crontab

2. cron 관련 설정파일 소유자 및 권한 설정
chown root <cron 관련 파일>
chmod 640 <cron 관련 파일>

## 일반 사용자에게 crontab을 허용하는 경우
1. /etc/cron.d/cron.allow 및 /etc/cron.d/cron.deny 파일의 소유자 및 권한 변경
chown root /etc/cron.d/{cron.allow, cron.deny}
chmod 640 /etc/cron.d/{cron.allow, cron.deny}

2. /etc/cron.d/cron.allow 및 /etc/cron.d/cron.deny 파일에 사용자 등록

 

3.5. DoS 공격에 취약한 서비스 비활성화

  • 점검 내용: 사용하지 않은 DoS 공격에 취약한 서비스의 실행 여부 점검
    • DoS(Denial of Service attack): 시스템을 악의적으로 공격해 해당 시스템의 자원을 부족하게하여 원래 의도된 용도로 사용하지 못하게 하는 공격
  • 점검 목적: 시스템 보안성을 높이기 위해 취약점이 많이 발표된 echo, discard, daytime, chargen, ntp,snmp 등 서비스를 중지함
  • 보안 위협: 해당 서비스가 활성화 되어 있는 경우 시스템 정보 유출 및 DoS 공격의 대상이 될 수 있음
# 조치 방법
1. vi 편집기를 사용해 /etc/xinted.d 디렉터리 내에 echo, discard, daytime, chargen 파일 열기
2. 아래와 같이 설정
/etc/xinted.d/echo 파일(echo-dgram, echo-stream)
/etc/xinted.d/discard 파일(discard-dgram, discard-stream)
/etc/xinted.d/daytime 파일(daytime-dgram, daytime-stream)
/etc/xinted.d/chargen 파일(chargen-dgram, chargen-stream)

service echo
{
	diable = yes
    id = echo-stream
    type = internal
    wait = no
	socket_type = stream  
}

3. xinted 서비스 재시작
systemctl restart xinted

 

3.6. NFS 서비스 비활성화

  • 점검 내용: 불필요한 NFS 서비스 사용 여부 점검
    • NFS(Network File System): 원격 컴퓨터의 파일 시스템을 로컬 시스템에 마운트하여 로컬 파일 시스템처럼 사용할 수 있는 프로그램
    • 원칙적으로 사용지 금지되어 있지만, 불가피하게 사용될 경우 3.7 과 같이 접근 통제를 해야함
  • 점검 목적: NFS 서비스는 한 서버의 파일을 많은 서비스 서버들이 공유하여 사용할 때 많이 이용되는 서비스이지만 이를 이용한 침해사고 위험성이 높으므로 사용하지 않는 경우 중지해야함
  • 보안 위협: 서버의 디스크를 클라이언트와 공유하는 서비스로 적정한 보안설정이 안되어 있다면, 불필요한 파일 공유로 인한 유출위험이 있다
# 확인 (NFS 서비스 데몬 확인, NFS 동작 SID 확인)
ps -ef | egrep "nfs|statd|lockd"

# 조치 방법
1. NFS 서비스 데몬 중지
kill -9 [PID]

2. 시동 스크립트 삭제 또는 스크립트 이름 변경
ls -al /etc/rc.d/rc*.d/* | grep nfs
mv /etc/rc.d/rc2.d/s60nfs /etc/rc.d/rc2.d/_s60nfs

*shomount, share,exportfs 명령어를 사용하여 마운트 되어있는 디렉터리 확인, 설정 여부 확인 하여 
디렉터리가 존재하지 않을 경우에 서비스 중지가 가능하다

 

3.7. NFS 접근 통제

  • 점검 내용: NFS 사용시 허가된 사용자만 접속할 수 있도록 접근 제한 설정 적용 여부 점검
    •  NFS 서비스 사용 금지가 원칙이나 불가피하게 사용이 필요한 경우 NFS v2,v3는 평문으로 전송되는 취약점이 존재하기 때문에 암호화되는 v4 사용을 권장한다
  • 점검 목적: 접근 권한이 없는 비인가자의 접근을 통제함
  • 보안 위협: 접근 제한 설정이 적절하지 않을 경우 인증철자 없이 비인가자의 디렉터리나 파일의 접근이 가능하며, 해당 공유 시스템에 원격으로 마운트하여 중요 파일을 변조하거나 유출할 위험이 있음
# 확인
/etc/exports

# 조치 방법 (설정 예문)
1. /etc/exports 파일에 접근 가능한 호스트명 추가
ex) /stand host1(또는 IP 주소) host2

2. 접속 시 인증 및 클라이언트 권한 nobody 설정
vi /etc/exports
/stand host1 (root_squash)
() 옵션에 인증되지 않은 액세스를 허용하는 'insecure' 구문 설정 금지

3. NFS 서비스 재구동
/etc/exportfs -u
/etc/exportfs -a

 

3.8. automountd 제거

  • 점검 내용: automountd 서비스 데몬의 실행 여부 점검
    • automountd: 클라이언트에서 자동으로 서버에 마운트 시키고 일정 시간 사용하지 않으면 umount 시켜주는 기능을 말함
    • RPC(Remote Procedure Call): 별도의 원격 제어를 위한 코딩없이 다른 주소 공간에서 함수나 프로시저를 실행할 수 있게 하는 프로세스 간 프로토콜
  • 점검 목적: 로컬 공격자가 automountd 데몬에 RPC를 보낼 수 있는 취약점이 존재하기 때문에 해당 서비스가 실행중일 경우 서비스를 중지 시키기 위함
  • 보안 위협: 파일 시스템의 마운트 옵션을 변경하여  root 권한을 획득할 수 있으며, 로컬 공격자가 automountd 프로세스 권한으로 임의의 명령 실행 가능하다
# 확인
ps -ef | grep automount(or autofs)

# 조치 방법
1. automountd 서비스 데몬 중지
kill -9 [PID]

2. 시동 스크립트 삭제 또는 스크립트 이름 변경
ls -al /etc/rc.d/rc*.d/* | grep automount(or autofs)
mv /etc/rc.d/rc2.d/S28automountd /etc/rc.d/rc2.d/_S28automountd

# 조치 시 영향
NFS 및 Samba 서비스에서 사용시 automound 사용 여부 확인이 필요하고, 적용 시 CDROM의 자동 마운트는 이뤄지지 않는다

 

3.9. RPC 서비스 확인

  • 점검 내용: 불필요한 RPC 서비스의 실행 여부 점검
    • 불필요한 RPC 서비스: rcp.cmsd, rpc,ttdbserverd, sadmind, rusersd, walld, sprayd, statd, rpc.nisd, rexd, rpc.pcnfsd, rpc.statd, rpc.ypupdated, rpc.rquotad, kcms_server, cashefsd
  • 점검 목적: 다양한 취약점(버퍼 오버플로우, DoS, 원격 실행 등)이 존재하는 RPC 서비스를 점검하여 해당 서비스를 비활성화 하도록 함
  • 보안 위협: 버퍼 오버 플로우(Buffer Overflow), DoS, 원격 실행 등의 취약성이 존재하는 RPC 서비스를 통해 비인가자의 root 권한 획득 및 침해사고 발생 위험이 있으므로 서비스를 중지하여야함
# /etc/xinted.d/ 디렉터리 내 서비스별 파일 비활성화 여부 확인
vi /etc/xinted.d/<servire_file_name>

# 조치 방법
1. vi 편집기를 이용해 불필요한 RPC 서비스 파일 열기
2. 아래와 같이 설정 (Disable = yes 설정)
service finger
{
	disable = yes
    socket_type = stream
    wait = no
}

3. xinted 서비스 재시작
systemctl restart xinted

 

3.10. NIS, NIS+ 점검

  • 점검 내용: 안전하지 않은 NIS 서비스의 비활성화, 안전한 NIS+ 서비스의 활성화 여부 점검
    • NIS 주 서버는 정보표를 소유하여 NIS 대응 파일들로 변환하고, 이 대응 파일들이 네트워크를 통해 제공됨으로 써 모든 컴퓨터에 정보가 갱신되도록 함. 네트워크를 통한 공유로부터 관지라와 사용자들에게 일관성있는 시스템 환경을 제공함
  • 점검 목적: 안전하지 않는 NIS 서비스를 비활성화 하고 안전한 NIS+ 서비스를 활성화 하여 시스템 보안 수준을 향상하고자함
  • 보안 위협: 보안상 취약한 서비스인 NIS를 사용하는 경우 비인가자가 타시스템의 root 권한 획득이 가능하므로 사용하지 않는 것이 바람직하다, 허나 사용해야하는 경우 사용자 정보보안에 많은 문제를 내포하고 있는 NIS 보단 NIS+ 사용을 권장한다
# NIS, NIS+ 서비스 구동 확인
ps -ef | egrep "ypserv|ypbind|ypxfrd|rpc.yppasswdd|rpc.ypupdated"

# 조치 방법
1. NIS 서비스 데몬 중지
kill -9 [PID]

2. 시동 스크립트 삭제 또는 스크립트 이름 변경
ls -al /etc/rc.d/rc*.d/* | egrep "ypserv|ypbind|ypxfrd|rpc.yppasswdd|rpc.ypupdated”
mv /etc/rc.d/rc2.d/S73ypbind /etc/rc.d/rc2.d/_S73ypbind

 

3.11. tftp,talk 서비스 비활성화

  • 점검 내용: tftp,talk 등의 서비스를 사용하지 않거나 취약점이 발표된 서비스 활성화 여부 점검
  • 점검 목적: 안전하지 않거나 불필요한 서비스를 제거함 으로서 시스템 보안성 및 리소스의 효율적 운영
  • 보안 위협: 사용하지 않는 서비스나 취약점이 발표된 서비스 운용 시 공격 시도 가능
# tftp,talk,ntalk 서비스 활성화 여부 확인
ls -al /etc/xinted.d/ | grep -i 'tftp|talk|ntalk"

# 조치 방안
1. vi 편집기능 이용해 /etc/xinted.d/ 디렉터리내 tftp,talk,ntalk 파일 열기
2. 아래와 같이 설정
/etc/xinted.d/tftp 파일
/etc/xinted.d/talk 파일
/etc/xinted.d/ntalk 파일

service tftp
{
	socket_type = dgram
    protocol = udp
    wait = yes
    user = root
    server = /usr/sbin/in.tftpd
    server_args = -s /tftpboot
	disable = yes 
}

3. xinted 재시작
systemctl restart xinted

 

항목 중요도: 상

 

2.1. root 홈, PATH 디렉터리 권한 및 패스 설정

  • 점검 내용: root 계정 PATH 환경 변수에 "."가 포함되어 있는지 점검
  • 점검 목적: 비인가자가 불법적으로 생성한 디렉터리 및 명령어를 우선으로 실행되지 않도록 설정하기 위해 환경변수 점검이 필요
  • 보안 위협: root 계정의 환경 변수에 정상적인 명령어(ex. ls, mv, cp등)의 디렉터리 경로보다 현재 디렉터리를 지칭하는 "." 표시가 우선하면 현재 디렉터리에 변조된 명령어가 삽입되었을때 악의적인 기능이 실행될 수 있다
# 확인 명령어
echo $PATH

# 조치 방법
root 계정의 환경 변수 설정파일(/.profile,/.cshrc)과 /etc/profile 등에서 환경변수에 포함되어있는 "."를 마지막으로 이동시킨다

vi /etc/profile

PATH=.:$PATH:$HOME/bin -> PATH=$PATH:$HOME/bin:.


* Unix의 환경변수 실행 순서
1. /etc/profile
2. root의 계정 환경변수 파일
3. 일반 계정의 환경변수 파일


# 쉘에 따라 참조되는 환경 설정파일
/bin/sh -> /etc/profile, $HOME/.profile
/bin/csh -> $HOME/.cshrc, $HOME/.login, /etc/.login
/bin/ksh -> /etc/profile, $HOME/.profile, $HOME/kshrc
/bin/bash -> /etc/profile, $HOME/.bash_profile

 

 2.2. 파일 및 디렉터리 소유자 설정

  • 점검 내용: 소유자가 불분명한 파일이나 디렉터리가 존재하는지 여부를 점검
  • 점검 목적: 소유자가 존재하지 않는 파일 및 디렉터리를 삭제 및 관리하여 임의의 사용자가 해당 파일을 열람, 수정하는 행위를 사전에 차단하기 위해서임
  • 보안 위협: 소유자가 존재하지 않는 파일의 UID와 동일한 값으로 특정 계정의 UID 값을 변경하면 해당 파일의 소유자가 되어 모든 작업이 가능해짐
# 확인 명령어
find / -nouser -print
find / -nogroup -print

소유자 및 그룹이 없는 파일은 파일 속성 해당 필드에 숫자로 표시됨
ex) rwxr-xr-x 500 500 test.txt

# 조치 방법
소유자가 존재하지 않은 파일 및 디렉터리 삭제 또는 소유자 변경

1. 삭제
rm <file_name>

2. 필요시, 소유자 변경
chown <user_name_> <file_name>

 

2.3. /etc/passwd 파일 소유자 및 권한 설정

  •  점검 내용: /etc/passwd 파일 권한 적절성 점검
    • /etc/passwd: 사용자의 ID, PW, UID, GID, Home Directory, Shell INFO 를 담고 있는 파임
  • 점검 목적: /etc/passwd 파일의 임의적인 변경을 차단하기 위함을 통해 비인가자가 권한을 상승하는 것을 막기 위함
  • 보안 위협: 관리자 외 사용자가 /etc/passwd/ 파일을 수정한다면 사용자 정보를 변조하여 쉘 변경, 사용자 추가 및 삭제, root를 포함한 사용자 권한 획득 가능
# 확인 명령어 및 확인 사항
ls -al /etc/passwd

1. 파일의 소유자가 root 인지 확인
2. 파일의 권한이 644 이하가 아닌 경우

# 조치 방법
chown root /etc/passwd
chmod 644 /etc/passwd

 

2.4. /etc/shadow 파일 소유자 및 권한 설정

  • 점검 내용: /etc/shadow 파일 권한 적절성 점검
    • /etc/shadow: 시스템에 등록된 모든 계정의 패스워드를 암호화된 형태로 저장 및 관리하고 있는 파일
  • 점검 목적: /etc/shadow 파일을 관리자만 제어할 수 있게하여 비인가자들의 접근을 차단해야함
  • 보안 위협: shadow 파일은 패스워드를 암호화하여 저장하고 있다. 해당 파일의 암호화된 해시값을 복호화(크래킹)하여 비밀번호 탈취가 가능함
# 명령어 및 확인 사항
ls -al /etc/shadow

1. 파일 소유자가 root 인지
2. 파일 권한이 400이 아닌 경우

# 조치 방법
chown root /etc/shadow
chmod 400 /etc/shadow

 

2.5. /etc/hosts 파일 소유자 및 권한 설정

  • 점검 내용: /etc/hosts 파일의 권한 적절성 점검
    • /etc/hosts
      • IP와 Hostname을 매핑하는 파일, 일반적으로 인터넷으로 외부 통신 시 주소를 찾기 위해서 DNS 보다 hosts 파일을 먼저 참조한다
      • 문자열 주소로 부터 IP 주소를 수신받는 DNS 서버와는 달리, 파일 내 직접 문자열 주소와 IP 주소를 매칭하여 기록, DNS 서버 접근 이전에 우선적으로 확인 후 문자열이 hosts 파일 내부에 존재할 시 그 문자열에 매핑되어있는 IP 주소로 연결된다
    • Pharming(파밍): 사용자 DNS 또는 hosts 파일을 변조함으로써 정상적인 사이트로 오인하여 접속하도록 유도한 뒤 개인정보를 탈취하는 기법
  • 보안 위협: hosts 파일에 비인가자의 쓰기 권한이 존재할 경우, 악의적인 시스템의 IP를 등록하여, 정상적인 DNS를 우회하여 악성사이트로 유도하는 파밍 공격등에 악용될 수 있다
# 확인 및 확인 사항
ls -al /etc/hosts

1. 소유자가 root가 아닌지 확인
2. 파일 권한이 600 이하가 아닌 경우

# 조치 사항
chown root /etc/hosts
chmod 600 /etc/hosts

# 조치 시 영향
hosts 권한을 600으로 변경 -> 일반 사용자 권한으로 사용이 불가
hosts 파일에 시스템 정보가 설정되어있는 경우 hosts 파일을 참조하는 서비스를 확인하여 조치를 취해야함

 

2.6. /etc/(x)inetd.conf 파일 소유자 및 권한 설정

  • 점검 내용: /etc/(x)inetd.conf 파일 권한 적절성 점검
    • (x)inted (슈퍼데몬): 자주 사용하지 않는 서비스가 상시 실행되어 메모리를 점유하는 것을 방지하기 위해 슈퍼데몬(데몬의 데몬)에 자주 사용하지 않는 서비스를 등록, 요청 시에만 해당 서비스를 실행시키고 요청이 끝나면, 서비스를 종료하는 일을 한다
  • 점검 목적: 파일의 관리자만 제어할 수 있게 하여 비인가자들의 임의적인 파일 변조를 방지
  • 보안 위협: (x)inetd.conf 파일에 소유자외 쓰기 권한이 부여된 경우, 등록된 서비스를 변조하거나 악의적인 서비스(프로그램)을 등록할 수 있음
# 확인 및 확인 사항
ls -al /etc/inetd.conf

ls -al /etc/xinetd.conf
ls -al /etc/xinetd.d/*

1. Linux는 운영체제 버전에 따라 inetd 또는 xinetd를 사용하고 있으므로 사용하고 있는 데몬 확인이 필요하다
2. 소유자가 root 인지
3. 파일 권한이 600이 아닌 경우

# 조치 사항
chown root /etc/inetd.conf
chmod 600 /etc/inetd.conf

chown root /etc/xinetd.conf
chmod 600 /etc/xinetd.conf

2.7. /etc/syslog.conf 파일 소유자 및 권한 설정

  • 점검 내용: /etc/syslog.conf 파일 권한 적절성 점검
    • /etc/syslog.conf: syslogd 데몬 실행 시 참조되는 설정 파일로 시스템 로그 기록의 종류, 위치 및 Level을 설정할 수 있다
  • 점검 목적: /etc/syslog.conf 파일 권한 적절성을 점검하여, 비인가자의 임의적 설정파일 변조를 방지하기 위함
  • 보안 위협: syslog.conf 파일의 설정 내용을 참조하여 로그의 저장위치가 노출, 로그를 기록하지 않도록 설정, 대량의 로그를 기록하게하여 시스템 과부하를 유도할 수 있다
# 확인 및 확인 사항
ls -al /etc/syslog.conf

1. 파일 소유자가 root 인지
2. 파일 권한이 640이 아닌 경우

# 조치 방법
chown root /etc/syslog.conf
chmod 640 /etc/syslog.conf

# 조치 시 영향
root,bin,sys등 시스템에서 사용하는 계정이 아닌 일반 계정에게 소유 권한이 부여되지 않도록 해야한다

 

2.8. /etc/services 파일 소유자 및 권한 설정

  • 점검 내용: /etc/services 파일 권한 적절성 점검
    • /etc/services: 서비스 관리를 위해 사용되는 파일, 해당 파일에 서버에서 사용하는 모든 포트들에 대해 정의되어있고, 필요 시 기본 포트 사용을 변경하여 네트워크 서비스를 운용할 수 있다
  • 점검 목적: 비인가자들의 임의적인 파일 변조를 방지하기 위함
  • 보안 위협: services 파일의 접근권한이 적절하지 않을 경우 비인가 사용자가 운영포트를 변경, 정상적인 서비스를 제한하거나, 허용되지 않은 포트를 오픈하여 악성 서비스를 의도적으로 실행 할 수 있다
# 확인 및 확인 사항
ls- la /etc/services

1. 파일의 소유자가 root가 아니거나
2. 파일 권한이 644가 아닌 경우 

# 조치 방법
가능 소유자: root,bin,sys

chown root /etc/services
chmod 644 /etc/services

 

2.9. SUID, SGID 설정 파일 점검

  • 점검 내용: 불필요하거나 악의적인 파이레 SUID, SGID 설정 여부 점검
    • SUID: 설정된 파일 실행 시, 특정 작업 수행을 위하여 일시적으로 파일 소유자 권한을 얻게 된다
    • SGID: 설정된 파일 실행 시 , 특정 작업 수행을 위하여 일시적으로 파일 소유 그룹 권한을 얻게 된다
  • 점검 목적: 불필요한 SUID,SGID 설정 제거로 악의적인 사용자의 권한상승을 방지하기 위함
  • 보안 위협: SUID,SGID 파일의 접근권한이 적절하지 않을 경우 SUID, SGID 설정된 파일로 특정 명령어를 실행하여 root 권한 획득 가능
# 확인
ls -alL <check_file] | awk '{print $1}' | grep -i 's'
find / -type f -perm -4000 2> /dev/null

# 조치 방법
1. 불필요한 SUID, SGID 설정된 바이너리 제거
2. 애플리케이션에서 생성한 파일이나, 사용자가 임의로 생성한 파일이 의심스럽거나 특이한 파일 발견 시  SUID 제거 필요
3. 필요 시  특정 그룹에서만 사용하도록 설정

SUID 제거
chmod -s <file_name>

주기적 감사
find / -user root -type f \( -perm -04000 -o -perm -02000 \) -xdev -exec ls -al {} \;

필요 시 특정 그룹에서만 사용 가능하도록 제한적인 설정(임의의 그룹만 가능
/usr/bin/chgrp <group_name> <setuid_file_name>
/usr/bin/chmod 4750 <setuid_file_name>

# 조치 시 영향
SUID 제거 시 OS 및 운용 프로그램 등 서비스 정상작동 유무 확인 필요

 

 

2.10. 사용자, 시스템 시작 파일 및 환경파일 소유자 및 권한 설정

  • 점검 내용: 홈 디렉터리 내의 환경변수 파일에 대한 소유자 및 접근 권한이 관리자 또는 해당 계정으로 설정되어 있는지 점검
    • 환경 변수 파일 종류
      • .profile
      • .kshrc
      • .cshrc
      • .bashrc
      • .bash_profile
      • .login
      • .serc
      • .netrc 등
  • 점검 목적: 환경 변수 조작으로 인한 보안 위험을 방지
  • 보안 위협: 홈 디렉터리 내의 사용자 파일 및 사용자별 시스템 시작파일 등과 같은 환경 변수 파일의 접근 권한 설정이 적절하기 않을 경우 비인가자와 환경변수 파일을 변조하여 정상 사용중인 사용자의 서비스가 제한 될 수 있음
# 확인 및 확인 사항
ls -l <home_directory_pathfile>

1. 파일 소유자가 root 또는 해당 꼐정으로 설정되어있는지 확인
2. 소유자 이외의 사용자에게 쓰기 권한이 부여되어 있는지 확인

# 조치 방법
1. 소유자 변경
chown <user_name> <file_name>

2. 일반 사용자 쓰기 권한 제거 방법
chmod o-w <file_name>

 

2.11. world writable 파일 점검

  • 점검 내용: 불필요한 world writable 파일 존재 여부 점검
    • world writable: 파일의 내용응 소유자나 그룹외 모든 사용자게 대해 쓰기가 허용된 파일(권한 777(rwxrwxrwx))
  • 점검 목적: world writable 파일을 이용한 시스템 접근 및 악의적인 코드 실행 방지
  • 보안 위협: 시스템 파일과 같은 중요파일에 설정이 될 경우, 일반 사용자 및 비인가된 사용자가 해당 파일을 임의로 수정, 삭제가 가능해진다
# 확인
find / -type f -perm -2 -exec ls -al {} \;

# 조치 방법
파일 존재 여부를 확인하고 불필요한 경우 제거

1. 일반 사용자 쓰기 권한 제거 방법
chmod o-w <file_name>

2. 파일 삭제 방법
rm -rf <file_name>

 

2.12. /dev에 존재하지 않는 device 파일 점검

  • 점검 내용: 존재하지 않는 device 파일 존재 여부 점검
    • /dev 디렉터리: 논리적 장치 파일을 담고 있는 /dev는 /devices 디렉터리에 있는 물리적 장치 파일에 대한 심볼릭 링크이다.
    • 예로 들어, rmt0를 rmto로 잘못 입력한 경우 rmto 파일이 새로 생성되는 것과 함게 디바이스 이름 입력 오류 시 root 파일 시스템이 에러를 일으킬 때까지 /dev 디렉터리에 계속해서 파일을 생성함
  • 점검 목적: 실제 존재하지 않는 디바이스를 찾아 제거함으로써 root 파일 시스템 손상 및 다운 등의 문제를 방지
  • 보안 위협: 공격자는 rootkit 설정파일들을 서버 관리자가 쉽게 발견하지 못하도록 /dev에 device 파일인 것 처럼 위장하는 수법을 많이 사용
# 확인
find /dev -type f -exec ls -al {} \;

# 조치 방법
확인 후 major,minor  number를 가지지 않는 device일 경우 삭제

 

2.13. $HOME/.rhosts, hosts.equiv 사용금지

  • 점검 내용: /etc/hosts.equiv 파일 및 .rhosts 파일 사용자를 root 또는 해당 계정으로 설정한 뒤 권한을 600으로 설정하고 해당파일 설정에 '+' 설정(모든 호스트 허용)이 포함되지 않도록 설정되어 있는지 점검
    • 'r'command: 인증 없이 관리자의 원격접속을 가능케하는 명령어들로 rsh(remsh),rlogin,rexec 등이 있으며, 포트번호 512,513,514(TCP)를 사용한다
  • 점검 목적: 'r'command 사용을 통한 원격 접속은 인증 없이 관리자 원격접속이 가능하므로 서비스 포트를 차단해야함
  • 보안 위협
    • rlogin, rsh 등과 같은 'r' command의 보안 설정이 적용되지 않은 경우, 원격지의 공격자가 관리자 권한으로 목표 시스템상의 임의의 명령을 수행시킬 수 있고, 중요 정보 유출 및 시스템 장애를 유발 시킬 수 있다. 또한 공격자의 백도어 등으로 활용이 가능함
    • r-command(rlogin,rsh등) 서비스의 접근 통제에 관련된 파일로 권한설정을 미 적용한 경우 서비스 사용 권한을 임의로 등록하여 무단 사용을 가능케함
# 확인
1. 파일 소유자 및 권한 확인
ls -al /etc/hosts.equiv
ls -al $HOME/.rhosts

2. 계정 별 '+' 부여 적절성 확인
cat /etc/hosts.equiv
cat $HOME/.rhosts

/etc/hosts.equiv -> 서버 설정 파일
$HOME/.rhosts -> 개별 사용자의 설정 파일

# 확인 사항
1. /etc/hosts.equiv 및 $HOME/.rhosts 파일의 소유자가 root 인지
2. 파일 권한이 600이 아닌 경우

# 조치 방법
1. /etc/hosts.equiv 및 $HOME/.rhosts 파일의 소유자를 root 또는 해당 계정으로 변경
chown root /etc/hosts.equiv
chown <user> $HOME/.rhosts

2. /etc/hosts.equiv 및 $HOME/.rhosts 파일의 권한을 600 이하로 변경
chmod 600 /etc/hosts.equiv
chmod 600 $HOME/.rhosts

3. /etc/hosts.equiv 및 $HOME/.rhosts 파일에서 '+'를 제거하고 허용 호스트 및 계정 등록
cat /etc/hosts.equiv (or $HOME/.rhosts)

+ + 모든 호스트의 계정 신뢰
+ test 모든 호스트의 test 계정을 신뢰
Web1 + Web1 호스트의 모든 계정을 신뢰

 

2.14. 접속 IP 및 포트 제한

  • 점검 내용: 허용할 호스트에 대한 접속 IP 주소 제한 및 포트 제한 설정 여부 점검
    • TCP Wrapper: 네트워크 서비스에 관련된 트래픽을 제어하고 모니터링 할 수 있는 UNIX 기반 방화벽 툴
    • IPFilter: UNIX 계열에서 사용하는 공개형 방화벽 프로그램으로써 Packet Filter로 시스템 및 네트워크 보안에 아주 강력한 기능을 보유한 프로그램
    • IPtables: 리눅스 커널 방화벽이 제공하는 테이블들과 그것을 저장하는 체인, 규칙들을 구성할 수 있게 해주는 응용프로그램
  • 점검 목적: 허용한 호스트만 서비스를 사용하게 하여 서비스 취약점을 이용한 외부 공격을 방지하기 위함
  • 보안 위협: 허용할 호스트에 대한 IP 및 포트제한이 적용되지 않은 경우, Telnet, FTP와 같은 보안에 취약한 네트워크 서비스를 통해 불법적인 접근 및 시스템 침해사고 발생 가능
# 확인
1. TCP Wrapper 사용할 경우
All deny 적용 확인 및 접근 허용 IP 적절성 확인
cat /etc/hosts.deny
cat /etc/hosts.allow

2. IPtables 사용할 경우
iptables -L

# 조치 방법
OS에 기본적으로 제공하는 방화벽 애플리케이션이나 TCP Wrapper와 같은 호스트별 서비스 제한 애플리케이션을 사용하여
접근 허용 IP 등록

## IPtables 사용하는 경우
1. iptables 명렁어를 통해 접속할 IP 및 포트 정책 추가 (ex. SSH)
iptables -A INPUT -p tcp -s 192.168.1.0/24 --dport 22 -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -j DROP

2. 설정 저장
/etc/rc.d/init.d/iptables save

## IPfilter 사용하는 경우
1. vi 편집기를 이용해 /etc/ipf/ipf.conf 파일 열기

2. 접속할 IP 및 포트 정책 추가 (ex. SSH)
pass in quick proto tcp from 192.168.1.0/24 to any port = 22 keep state
block in quick proto tcp from any to any port = 22 keep state

## TCP Wrapper 사용하는 경우
1. vi 편집기를 이용해 /etc/hosts.deny (파일 없을 시 생성)
2. 신규 삽입 (ALL Deny 설정)
(before) 설정 없음
(after) ALL:ALL

3. vi 편집기를 이용해 /etc/hosts.allow (파일 없을 시 생성)
(before) 설정 없음
(after) sshd : 192.168.0.148, 192.168.0.6
  • TCP Wrapper 접근 제어 가능 서비스
    • SYSTAT,FINGER,FTP,TELNET,RLOGIN,RSH,TALK,EXEC,TFTP,SSH
  • TCP Wrapper는 다음 두 파일에 의해 접근이 제어 됨
    • /etc/hosts.deny -> 시스템 접근을 제한할 IP 설정
    • /etc/hosts.allow -> 시스템 접근을 허용할 IP 설정
    • 위의 두 파일이 존재하지 않을 시 == 모든 접근 허용

 

항목 중요도 : 상 

 


 

1.1 root 계정 원격 접속 제한

 

- 점검 내용 : 시스템 정책에 root 계정의 원격터미널 접속 차단 설정이 적용되어있는지 적용

- 점검 목적 : 관리자 계정 탈취로 인한 시스템장악을 방지기 위해 외부 비인가자의 root 계정 접근 시도를 원천적으로 차단하기 위함

- 보안 위협 : root 계정은 운영체제의 모든 기능을 설정 및 변경 가능 -> root 계정을 탈취하여 외부에서 원격으로 시스템 장악 및 각종 무작위 대입 공격으로 인한 root 계정 사용 불가 위협

- 판단 기준 : 원격 터미널 서비스 사용을 하고 있는지? 만약 사용한다면 root 계정의 직접 접속을 차단 했는지?

- 조치 방법 : 원격 접속 시 root 계정으로 접속할 수 없도록 설정 파일 수정

확인 사항
cat /etc/ssh/sshd_config | grep -i 'permit'

# 변경 전
#PermitRootLogin prohibit-password
# 변경 후 -> ssh 서비스 재시작
PermitRootLogin no

sudo systemctl restart ssh

 

 


1.2 패스워드 복잡성 설정

 

- 점검 내용 : 시스템 정책에 있는 사용자(root 및 일반 사용자 포함) 패스워드 복잡성 관련 설정이 되어있는지 점검

- 점검 목적 : 패스워드 복잡성에 대해 점검하여 비인가자의 공격(무작위 대입 공격, 사전 대입 공격 등)에 대비가 되어있는지 확인

- 보안 위협 : 복잡성 설정이 되어있지 않은 패스워드는 사회공학적인 유추가 가능할 수 있으며, 암호화된 패스워드 해쉬값을 비인가자의 공격으로 단시간에 패스워드 크렉을 가능케함

- 판단 기준 : 패스워드 최소 길이가 8자리 이상인가?, 영문,숫자,특수문자 최소 입력 기능이 설정되어 있는가?

- 조치 방법 : 계정과 유사하지 않은 8자 이상의 영문, 숫자, 특수문자의 조합으로 암호 설정 및 패스워드 복잡성 옵션 설정

# 확인
cat /etc/security/pwquality.conf


# 설정 예시
password requisite pam_cracklib.so try_first_pass retry=3 minlen=8 lcredit=-1 
ucredit=-1 dcredit=-1 ocredit=-1

# 설정값 설명
-1 : 반드시 해당하는 문자를 포함시켜야 함
권장 값
lcredit=-1 // 최소 소문자 요구 -> 소문자 최소 1자 이상 요구
ucredit=-1 // 최소 대문자 요구 -> 대문자 최소 1자 이상 요구
dcredit=-1 // 최소 숫자 요구 -> 최소 숫자 1자 이상 요구
ocredit=-1 // 최소 특수 문자 요구 -> 최소 특수 문자 1자 이상 요구
minlen=8 // 최소 패스워드 길이 설정 -> 최소 8자리 이상 설정
difok=N // 기존 패스워드와 비교 -> 기본 값 10 (50%)

 

- 부적절한 패스워드 유형

  1. 사전에 나오는 단어나 이들의 조합

  2. 길이가 너무 짧거나, 공백인 패스워드

  3. 기보드 자판의 일련의 나열 ex) abcd,qwerty,etc

  4. 사용자 계정 정보에서 유추 가능한 단어들 ex) 지역명, 부서명, 계정명, 이니셜,  root, rootroot, root123, admin 등

 

- 패스워드 관리 방법

  1. 영문, 숫자, 특수문자를 조합하여 계정명과 상이한 8자 이상의 패스워드 설정 (아래 문자 종류 중 2종류 이상을 조합, 최소 10자리 이상 또는, 3종류 이상을 조합하여 최소 8자리 이상 길이로 구성)

    1.1 영문 대문자 (26개)

    1.2 영어 소문자 (26개)

    1.3 숫자 (10개)

    1.4 특수 문자 (32개)

  2. 시스템마다 상이한 패스워드 사용

  3. 패스워드를 기록해 놓을 경우 변형하여 기록

 

- 조치 시 영향 : 패스워드 변경 시 Web,WAS,DB 연동 구간에서 문제가 발생할 수 있으므로 연동 구간에 미칠 수 있는 영향을 고려해야한다

 


1.3 계정 잠금 임계값 설정

 

-  점검 내용 : 사용자 계정 로그인 실패 시 계정잠금 임계값이 설정되어 있는지 점검

- 점검 목적 : 계정 탈취 목적의 무작위 대입 공겨 시 해당 계정을 잠금하여 인증 요청에 응답하는 리소스 낭비를 차단, 대입 공격으로 인한 비밀번호 노출 공격을 무력화하기 위함

- 보안 위협 : 패스워드 탈취 공격의 인증 요청에 대해 설정된 패스워드와 일치할 때 까지 지속적으로 응답해 해당 계정의 패스워드가 유출될 수 있음

- 판단 기준 : 계정 임계값이 10회 이하의 값으로 설정되어 있는가?

1. vi 편집기를 이용해 /etc/pam.d/system-auth 파일 열기
2. 아래와 같이 수정 또는 신규 삽입
auth required /lib/security/pam_tally.so deny=5 unlock_time=120 no_magic_root
account required /lib/security/pam_tally.so no_magic_root reset

no_magic_root: root에게는 패스워드 잠금 설정을 적용하지 않음
deny=5: 5회 입력 실패 시 패스워드 잠금
unlock_time: 계정 잠김 후 마지먹 계정 실패 시간부터 설정된 시간이 지나면 자동 계정 잠김 해제 (단위:초)
reset: 접속 시도 성공 시 실패한 횟수 초기화

 

- 조치 시 영향 : pam.d/system-auth의 내용 수정 시 해당 라이브러리가 실제 존재하는지 확인이 필요하다, pam_tally.so 파일이 존재 하지 않으면 모든 계정 로그인이 안되는 장애가 발생될 수 있다

 


1.4 패스워드 파일 보호

- 점검 내용: 시스템의 사용자 계정 정보가 저장된 /etc/passwd, /etc/shadow에 사용자 계정 패스워드가 암호호되어 저장되어 있는지 점검

- 점검 목적 : 오래된 시스템의 경우 /etc/passwd 파일에 패스워드가 평문으로 저장되므로, 사용자 계정 패스워드가 암호화되어 저장되어 있는지 점검하여 비인가자의 패스워드 파일 접근시에도 안전하게 관리 되고 있는지 확인하기 위함

- 보안 위협: 사용자 계정 패스워드가 저장된 파일이 유출 또는 탈취 시 평문으로 저장된 패스워드 정보 노출될 수 있음

- 판단 기준 : 쉐도우 패스워드를 사용하는가?, 패스워드를 암호화해서 저장해놓았는가?

# 1) /etc/shadow 파일의 패스워드 암호화 존재 확인
ls /etc

# 2) /etc/passwd 파일 내 두번째 필드가 "x" 표시 되어있는지 확인하기
cat /etc/passwd
root:x:0:0:root:/root:/bin/bash

 

웹 해킹 실습을 위한 컨테이너 환경을 구축하기 위해서 Ubuntu 22.04 Desktop 이미지를 미리 다운 받았습니다

그리고 가상머신을 실행 시키기 위해 저는 VMware Workstation을 활용했습니다

 

1. 가상머신 설치

File -> New Virtual Machine 을 선택해줍니다

Custom 선택

이미지 파일은 나중에 넣어줍니다

이름은 아무렇게나 정해주고 경로도 그냥 그대로 나두고 Next 눌러줍니다

프로세스는 코어를 2개로 해줍니다. 그래야 더 성능이 좋습니다~~

메모리는 그냥 2048MB = 2GB 로 설정해줍니다

혹시나 설치하다가 너무 느리거나 하면 4096MB으로 설정해주고 나중에 다시 2048MB로 변경해주시면 됩니다!

네트워크는 NAT로 설정해줍니다 이후 나머지는 그냥 Next 계속 눌러주시면 됩니다

하드디스크 설정은 20GB에 싱글 디스크로 설정해줍니다

마지막 확인 창에서 Customize Hardware를 눌러 이제 이미지 파일을 넣어줍니다

이렇게 말이죠~

이후 Finish를 누르고 가상머신을 실행 시켜 줍니다

 

2. Ubuntu Configuration

Install Ubunutu

그냥 기본으로 하고 Continue 눌러줍니다

그리고 Minimal installation 으로 설정하고 Continue 해줍니다. 기본적인 것만 있으면 되니깐요!

 

건들지말고 Install Now 해줍니다

Continue

하고싶은 이름으로 정해서 continue 해줍니다 기다려주면 우분투가 재부팅 한다는 창을 눌러주면 재부팅이 됩니다!

 

 

 

 

3. Docker Install

이제 docker를 설치해주겠습니다

# apt 업데이트
sudo apt update -y

# 필요한 패키지 설치
sudo apt install -y apt-transport-https ca-certificates curl software-properties-common

# docker 공식 GPG키 추가하기
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg

# docker 공식 저장소 apt에 추가
echo "deb [signed-by=/usr/share/keyrings/docker-archive-keyring.gpg] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

# 업데이트 후 docker 및 containerd.io 설치
sudo apt update -y
sudo apt install docker-ce docker-ce-cli containerd.io -y

# sudo 없이 docker 명령어 실행 가능하게 하는 명령어
sudo usermod -aG docker $USER

# 재부팅 후에도 도커 계속 실행되게 하는 명령어
sudo systemctl enable --now docker

# 이후 재부팅 
sudo reboot

 

sudo 없이 docker를 실행하는 것은 설정해주고 재부팅을 한번 해줘야 적용이 됩니다!

4. OWASP Juice Shop Setup

# 도커허브에서 이미지 불러오기
docker pull bkimminich/juice-shop

# 컨테이너 실행
docker run -it --rm -p 3000:3000 bkimminich/juice-shop

3000으로 포트포워딩이 되었으니 kali linux에서 10.10.10.15:3000 으로 접속해보겠습니다

 

접속이 잘되죠??

 

사실 그냥 kali에서 컨테이너 환경 구축하고 직접 실행해도되는데,, 오랜만에 작은 인프라라도 구축을 해보고 싶어서 한번 시도해봤습니다. 

이제 컨테이너 환경으로 실습 환경 구축은 이렇게 진행하면 되겠네요~!!

+ Recent posts