[Born2beRoot] 뭐가 뭔지 모르겠지만 아무튼 정리하는 글

hyeojung·2021년 6월 18일

42Seoul

목록 보기

14/16

0. 서론

글을 시작하기에 앞서, Mandatory 파트에서 요구하는 세팅을 하는 데까지는 아래의 글을 사정없이 모조리 참조했음을 밝힌다. 너무 정리를 잘해주셔서 여기 나와 있는 대로만 하면 아무것도 모르는 상태여도 세팅하는 것 자체는 가능하다.

born2beroot 삽질의 흔적
https://tbonelee.tistory.com/m/16

이 글에서는 세팅 과정에서 발생하는 이슈보다는 과제 제출 후 디펜스할 때 필요한 내용들을 정리해 보려고 한다!

1. Apt vs Aptitude

1.1. Apt

Advanced Packaging Tool의 줄임말로, 소프트웨어 패키지를 관리하는 무료 오픈소스 소프트웨어이다.
GUI가 없고, 사용자가 패키지를 업그레이드할 때 자동으로 가장 중요한 패키지를 업그레이드하고 가장 덜 중요한 패키지를 남겨둔다.

(명령어)apt와 apt-get, apt-cache의 차이점
APT는 데비안의 패키지 시스템을 일컫는 말이고, 이 APT를 준수해 패키지 관리의 목적으로 만들어진 툴이 apt-get, aptitude, apt-cache 등이다.
그런데 이렇게 여러 툴이 생기고 리눅스 유저들이 자주 쓰는 커맨드들이 다양한 툴에 흩어져 있다 보니 점점 문제가 발생했다. 이를 해결하기 위해 apt-get이나 apt-cache 등에서 리눅스 유저들에게 필요한 기능과 옵션들만을 넣은 (명령어)apt가 탄생했다.

1.2. Aptitude

Apt에 GUI를 추가하여 사용자가 패키지 관리를 보다 편리하게 할 수 있도록 만든 high-level 패키지 매니저이다.
주요 패키지 작업 과정을 자동화하여 apt보다 쉽게 작업할 수 있도록 해 준다.

1.3. 차이점

apt는 low-level, aptitude는 high-level 패키지 매니저이다. apt는 다른 하이 레벨 패키지 매니저에 의해 사용될 수 있다.
aptitude는 사용하지 않는 패키지를 자동으로 제거해주는 반면 apt는 추가적인 옵션(ex. autoremove, -auto-remove)이 필요하다.
apt에서 각각 upgrade와 dist-upgrade로 쓰이던 커맨드는 safe-upgrade와 full-upgrade로 바뀌었다.
aptitude는 apt-get 외에 apt-cache, apt-mark 등의 툴도 같이 사용한다.
aptitude는 검색에서 조금 다른 쿼리 신택스를 사용한다. (apt-cache와 비교했을 때)
aptitude는 why와 why-not 커맨드를 통해 특정 패키지를 설치할 때 어떤 것이 요구되고, 어떤 것과 충돌하는지 확인할 수 있다.
apt는 설치, 제거, 업데이트 과정에서 충돌이 있는 경우 그냥 불가능하다고만 하는 반면 aptitude는 다른 대안을 제시해 준다.

참고한 글

http://ubuntu.or.kr/viewtopic.php?p=71143
https://www.tecmint.com/difference-between-apt-and-aptitude/

2. SELinux와 AppArmor

2.1. SELinux (CentOS)

Security-Enhanced Linux의 줄임말
레드햇 계열 (RHEL, Fedora, CentOS)
MAC 적용 (전통적인 Linux 는 DAC)
시스템 전체에 보안 설정

+) SELinux 사용 개념

대상 (사용자, 응용프로그램, 프로세스 등) -> 주체 (subject)
개체 (파일 및 소켓, 디렉토리, 장치) -> 객체 (object)
레이블 (객체에 붙는 메타데이터) -> 확장된 속성을 지원하는 파일 시스템 필요
정책 (대상과 객체에 대한 접근 권한 구조를 정의)

2.2. AppArmor (Debian)

Application Armor의 줄임말
SUSE 계열 (SUSE Linux), 데비안 계열(Debian, Ubuntu)
MAC 적용 (전통적인 Linux 는 DAC)
개별 응응프로그램을 보호하는 일에 집중, 응용프로그램 단위의 보안 모델 구현

Apparmor는 데비안 os 사용시 자동으로 설치되고 크게 2가지 옵션으로 파일 접근을 제어할 수 있다.
enforce 모드 : 허가되지 않은 파일에 접근하는 것을 거부하는 모드
complain 모드 : 실질적으로 보안을 제공하는 것은 아님. 대신 어플리케이션이 해야 할 행동이 아닌 다른 행동을 하는 경우에 앱아머는 로그를 남겨준다(중지하지는 않음).

보안모델

DAC (임의접근제어, Discretionary Access Control)
: 소유자가 사용자 또는 그룹이 자원에 접근하는 것을 조절 (소유자 자유재량)
: 주체(소유자)가 객체(파일)를 제어
: 계정과 소유권에만 기반

MAC (강제접근제어, Mandatory Access Control)
: 정의된 정책을 활용해 사용자와 프로세스의 행동을 제어
: 파일의 유형, 사용자의 역할, 프로그램의 기능과 신뢰도, 데이터의 민감성과 무결성 고려

2.3. 공통점과 차이점

둘 다 security framework
SELinux는 IBM/RedHat 계열에서 선호되고 같은 계열의 CentOS와 같은 운영체제에서 사용된다. 나머지는 AppArmor사용
SELinux는 policy file과 right file system을 통해 작동, AppArmor는 policy file만으로 작동. SELinux가 조금 더 복잡하고 표준화하여 설정하기 어려운 단점.
데비안에는 기본적으로 깔려 있으나 깔려 있지 않다면 "apt install apparmor apparmor-utils"을 통해 설치 가능.
"aa-enabled" 명령어 통해 활성화 여부 확인 가능
앱아머는 정책 파일을 통해 어떤 어플리케이션이 어떤 파일/경로에 접근 가능한지 허용해준다.
enforce모드와 complain 모드 두 가지 존재
enforce 모드 : 허가되지 않은 파일에 접근하는 것을 거부하는 모드
complain 모드 : 실질적으로 보안을 제공하는 것은 아님. 대신 어플리케이션이 해야 할 행동이 아닌 다른 행동을 하는 경우에 앱아머는 로그를 남겨준다(중지하지는 않음).
"sudo aa-status"통해 현재 상태 확인 가능(enforced, complain, unconfined)
"ps auxZ | grep -v '^unconfined'" 통해 현재 앱아머에 의해 제한된 실행 파일 확인 가능
파일에 라벨을 적용하는 것에 기반하는 SELinux와는 달리, AppArmor는 파일 경로를 통해 작동
비슷한 접근법을 취하긴 하지만 SELinux는 경로 대신 아이노드 번호로 파일 시스템 객체들을 구별
ex) 하드 링크가 생성됐을 때 아이노드에 참조되는 데이터가 같을 것이기 때문에 SELinux가 계속 새로 생성된 하드 링크에 대한 접근을 거부하는 것과 달리 AppArmor에서는 접근 가능

참고한 글

https://2infinity.tistory.com/59
https://ko.wikipedia.org/wiki/AppArmor

3. CentOS vs Debian

레드햇과 데비안은 모두 리눅스를 기반으로 하고 있지만 배포하는 곳이 다르고 어디에 최적화가 잘 되어 있는지가 조금씩 차이난다.

3.1. CentOS (레드햇 계열)

레드햇은 기업화된 배포판으로 RPM(RedHat Package Manager) 시스템을 사용하여 패키지를 관리하는데 주로 rpm이란 명령어를 이용한다. rpm은 확장자를 가진 컴파일이 완료된 바이너리 파일을 시스템에 설치하고 또 설치된 패키지들을 관리, 제거할 수 있게 한다. 패키지 매니저는 YUM/DNF를 사용한다. 레드햇 계열의 장점은 쉬운 설치이다.

하지만 레드햇과 같은 rpm 계열 배포판들의 단점은 의존성 있는 패키지들을 유연성 있게 처리하지 못한다는 것이다. 일일이 rpm 파일을 조사하여 의존성 있는 패키지들을 알아보고 인터넷을 돌아다니면서 찾아내서 사용자가 설치해 주어야 한다.

+) CentOS는 레드햇이 공개한 RHEL을 가져와서 레드햇의 브랜드와 로고만 제거하고 무료 배포한 배포본으로, 문제 발생 시 레드햇이 아닌 커뮤니티를 통해 지원되므로 패치가 다소 느림

3.2. Debian

데비안은 배포되고 있는 리눅스 중 서버의 안정성이 높고 포함하고 있는 패키지도 많다. 데비안은 deb라는 패키지들을 쓰는데 이 패키지를 관리하는 몇 패키지 매니저(dpkg, apt 등)을 가지고 있어 패키지 설치 시 의존성에 걸려 있는 패키지들을 자동으로 알려주고 설치하며 설정 파일들을 생성해준다. 또한 이 패키지들은 지정된 서버에 리스트가 있어 리스트를 업데이트 해주고 apt를 이용하여 설치 명령을 주면 자동으로 지정 서버에서 받아 시스템에 다운 후 설치해준다.

하지만 데비안 역시 패키지의 업데이트가 느리다는 단점이 존재한다. 어떤 프로그램이 정식으로 릴리즈되어도 보통 몇 주가 지나야 패키지가 나오고 소스 리스트에 업데이트된다.
하지만 오래된 만큼 CentOS에 비해서는 커뮤니티에 강점이 있다.

참고한 글

https://knucordingmonster.tistory.com/1
https://satto.tistory.com/entry/CentOS-%EB%A6%AC%EB%88%85%EC%8A%A4-%EC%9E%A5%EB%8B%A8%EC%A0%90

4. LVM

LVM(Logical Volume Manager)는 리눅스 안에서 하나의 디스크를 여러 파티션으로 분할해서 파일 시스템을 이용해 특정 디렉터리와 연결시켜 사용한다. 파티션을 논리적인 개념인 볼륨으로 나눠서 더 유동적으로 디스크의 용량을 관리할 수도 있다.
볼륨은 기본적으로 단일 파티션에 상주하게 되지만 다수의 파티션을 하나의 볼륨으로 관리할 수도 있다. 그래서 여러 개의 파티션을 합치거나 분할하기에 용이하다.

파티션
LVM은 디스크를 파티션이라는 논리적인 크기로 분할 / 통합해서 사용한다. 하나의 디스크를 여러 개로 분할하기도 하고 여러 개의 디스크를 하나의 파티션으로 통합하기도 한다.
파티션은 고정적이고 물리적인 개념이 강하며 한 번 크기를 설정하면 변경하거나 추가하기 힘들고 OS는 각 파티션을 별도의 디스크처럼 인식한다.
볼륨
파일 시스템으로 포맷된 디스크 상의 저장 영역이라고도 하며 파티션과 비슷한 개념이지만 엄연히 다르다.
볼륨은 디스크의 단일 파티션에 상주하게 되며 파티션보다 논리적으로 유동적이다. LVM은 하나의 디스크를 여러 개의 파티션으로 나누어 사용한다. 이때 볼륨은 파티션마다 하나씩 존재하기도 하고, 여러 파티션에 하나만 존재할 수도 있다.

리눅스에서 디스크를 사용하는 가장 기본적인 방법은 디스크를 파티션으로 나누어 각각의 디렉터리에 파일 시스템으로 마운트 한 뒤 지정된 위치에 데이터를 저장해서 사용하는 것이다.
(디스크 → 파티션 → 볼륨그룹 → 논리그룹 → 파일시스템(/home))

디스크를 좀 더 유연하게 사용하기 위해 물리적인 파티션을 논리적인 볼륨으로 바꿔서 사용한다. LVM에서는 여러 파티션을 하나의 논리적인 볼륨으로 묶은 뒤 다시 필요한 크기만큼 나눠서 사용할 수 있다.

LVM을 적용하게 되면 디스크를 변경, 추가할 때 물리적인 부분을 건드릴 필요가 없어 여러 디스크를 하나로 뭉쳐서 사용할 수도 있고 하나의 디스크를 여러 디스크인 것처럼 나누어 사용할 수도 있다.
사용 중인 파티션의 크기를 바꿀 수도 있고 디스크를 추가한 뒤 간단한 작업을 통해 용량을 확장시킬 수도 있다.

4.1. LVM의 구성

PV(Physical Volume)
- 물리적 볼륨으로 디스크를 LVM에서 사용할 수 있게 변환하는 작업
- 디스크의 파티션을 PV로 초기화시켜 일정한 크기의 PE로 구성
VG(Volume Group)
- PV가 모여 만들어진 그룹
- 물리적인 일정한 크기의 PE로 구성된 PV들이 모여 VG가 만들어짐
- VG는 다시 LV로 할당할 수 있는 공간을 말하기도 함
PE(Physical Extent)
- PV에서 나누어 사용하는 블록
- 보통 1PE의 크기는 4MB이며 VG가 새롭게 나누는 논리적인 LV의 LE와 1:1 대응
LV(Logical Volume)
- VG에서 사용자가 필요한 만큼 할당되서 만들어지는 공간
- 논리적인 파티션이라고 볼 수 있으며 이는 다시 LE로 나누어짐
LE(Logical Extent)
- LV가 나누어진 일정한 크기의 블록으로 물리적 크기인 PE와 1:1 대응

물리적인 크기를 논리적인 크기로 바꿔서 분할, 결합이 더 유연하다.
물리적 크기인 PE는 논리적 크기인 LE와 1:1 맵핑하게 된다.

참고한 글

https://velog.io/@dogfootbirdfoot/Born2beRoot2
https://doosil87.github.io/linux/2019/08/01/VG,PV,LV.html

5. SSH

Secure Shell로 컴퓨터와 컴퓨터가 인터넷과 같은 Public Network를 통해 서로 통신할 때(주로 원격지에 있는 컴퓨터를 안전하게 제어하기 위해) 보안적으로 안전하게 통신을 하기 위해 사용하는 프로토콜 또는 이 프로토콜을 사용하는 프로그램들을 의미한다.

SSH 클라이언트와 SSH 서버의 관계로 상호작용하면서 SSH 서버가 설치된 운영체제를 제어한다. 클라이언트와 서버 사이에는 강력한 암호화 방법을 통해서 연결되어 있기 때문에 데이터를 중간에서 가로채도 해석 할 수 없는 암호화된 문자만이 노출된다.

Secure Shell이라는 이름에서 알 수 있듯이 SSH는 보안을 염두에 두고 만들어진 프로토콜이다. (유닉스/리눅스에서의 shell과 이름이 같지만, 이러한 종류의 shell은 아니다.) SSH 프로토콜은 다음과 같은 인증(Authentication), 암호화(Encryption), 무결성(Integrity), 압축(Compression) 등을 제공한다.

인증(Authentication)
사용자와 서버를 인증한다. 사용자는 SSH 서버에 접속할 때 신분을 증명해야 하는데, 전통적인 패스워드 인증 방식과 더불어 RSA, DSA등 공개키 방식의 인증 방법도 지원한다. 또한 SSH 클라이언트는 처음 접속한 서버의 키를 저장함으로써 서버가 변경되었을 경우에도 이를 판별할 수 있다.
암호화(Encryption)
보통의 다른 서버/클라이언트 방식의 접속과 달리 SSH는 네트워크를 통해 전달되는 데이터를 암호화한다. 그래서 누군가 중간에서 데이터를 가로채더라도 내용을 알 수가 없다. 3DES, blowfish 등의 대칭키 방식의 암호화 방식을 제공하고 새로운 암호화 기법을 추가할 수 있게 설계되어 있다.
무결성(Integrity)
네트워크를 통해 받은 데이터가 변경되지 않았음을 보장한다. 누군가 데이터를 가로채서 다른 정보를 보내는 것을 방지할 수 있다. MAC(Message Authentication Code)을 통해 이를 구현하고 있다.
압축(Compression)SSH 연결을 통해 보낸 데이터를 압축 할 수 있다. SSH 클라이언트/서버 사이에서 데이터를 보내기 전에 압축하고 이를 암호화해서 전송한다. 데이터를 받는 쪽에서는 복호화(decryption)한 후 압축을 해제함으로써 구현한다.

5.1. SSH의 사용 예

대표적인 사용 예로는 1. 데이터 전송과 2. 원격 제어 등이 있다.

데이터 전송의 예로는 원격 저장소인 github을 들 수 있는데, 소스 코드를 원격 저장소인 github에 푸쉬할 때 우리는 SSH를 이용해 파일을 전송하게 된다.

원격 제어의 예로는 AWS와 같은 클라우드 서비스를 들 수 있다. 우리는 AWS의 인스턴스 서버에 접속해 해당 머신에 명령을 내리기 위하여 SSH를 통해 접속한다.

보통 사용자들은 ssh를 telnet 대용으로 많이 사용한다. 보안상 문제가 많은 telnet 대용으로 ssh를 사용하는 것은 훌륭한 선택이라 할 수 있다. 사용법도 telnet과 아주 비슷하다. 리눅스의 경우 보통 SSH 클라이언트와 서버가 이미 설치되어 있다.

5.2. Private Key & Public Key

SSH는 다른 컴퓨터와 통신을 하기 위해 접속을 할 때 우리가 일반적으로 사용하는 비밀번호 입력을 통한 접속을 하지 않는다. 기본적으로 SSH는 한 쌍의 Key를 통해 접속하려는 컴퓨터와 인증 과정을 거치게 되는데, 이 한 쌍의 Key가 바로 Private Key와 Public Key이다. ssh-keygen 명령어를 통해 생성할 수 있다.

Public Key
단어 뜻 그대로 공개되어도 비교적 안전한 Key로, 이 Public Key를 통해 메시지를 전송하기 전 암호화를 하게 된다. Public Key로는 암호화는 가능하지만 복호화는 불가능하다.
Private Key
절대로 외부에 노출되어서는 안되는 Key로 본인의 컴퓨터 내부에 저장하게 되어 있다. 이 Private Key를 통해 암호화된 메시지를 복호화할 수 있다.

Private Key와 Public Key를 통해 다른 컴퓨터와 통신을 하기 위해서는 먼저 Public Key를 통신하고자 하는 컴퓨터에 복사하여 저장한다.
그리고 요청을 보내는 클라이언트 사이드 컴퓨터에서 접속 요청을 할 때 응답하는 서버 사이드 컴퓨터에 복사되어 저장된 Public Key와 클라이언트 사이드에 해당 Public Key와 쌍을 이루는 Private Key와 비교를 하여 서로 한 쌍의 Key인지 아닌지를 검사한다.

이 과정을 통해 서로 관계를 맺고 있는 Key라는 것이 증명되면 비로소 두 컴퓨터 사이에 암호화된 채널이 형성되어 Key를 활용해 메시지를 암호화하고 복호화하며 데이터를 주고받을 수 있게 된다.

5.3. SSH Tunneling (SSH Forwarding)

위 그림에서처럼 Host A에는 SSH 클라이언트가 설치되어 있고 Host B에는 SSH 서버가 설치되어 있다고 하자. SSH 클라이언트를 통해 SSH 서버에 접속을 하면 둘 사이에 연결이 이루어지는데 이 연결 통로를 터널이라고 한다. 암호화 등을 통해 터널처럼 외부로부터 이 연결을 보호하기 때문이다. 그래서 터널링이라고 부른다.
여기서 중요한 사실은 이러한 SSH를 통해 만든 터널을 다른 애플리케이션이 이용할 수가 있다는 것이다. 이러한 일을 가능하게 하는 것이 포트 포워딩(Port Forwarding)이란 기술이므로 포워딩이라고도 부른다.

포트 포워딩(Port Forwarding)이란?

포트 포워딩 또는 포트 매핑(Port Mapping)은 컴퓨터 네트워크에서 패킷이 라우터나 방화벽과 같은 네트워크 게이트웨이를 지나는 동안 하나의 IP 주소와 포트 번호 결합의 통신 요청을 다른 곳으로 넘겨주는 네트워크 주소 변환(NAT)의 응용 기술이다.
포트 포워딩은 원격 컴퓨터가 근거리 통신망(LAN) 내에 위치한 특정 컴퓨터나 서비스에 연결할 수 있게 한다.
로컬 포트 포워딩, 원격 포트 포워딩, 동적 포트 포워딩 등으로 나눌 수 있으며 로컬 포트 포워딩이 가장 일반적으로 ssh 클라이언트의 연결이 ssh 서버를 통해 전달된 후 대상 서버로 전달된다.

자세한 내용은 https://help.ubuntu.com/community/SSH/OpenSSH/PortForwarding 참조

터널을 이용한다는 것은 곧 암호화 등의 SSH의 장점을 모두 사용할 수 있다는 것을 의미한다. 즉, 암호화를 지원하지 않는 프로그램을 안전하게 사용할 수 있다는 것이다. (참고로 TCP를 사용하는 프로그램만 지원하고 UDP 등 다른 프로토콜은 지원하지 않는다.)

위 그림에서, Host A의 application client가 Host B의 application server로 접속할 때에 일반적으로는 직접 접속(direct connection)을 한다. 하지만 SSH 터널링을 이용하면 application client가 SSH 클라이언트에 접속을 하고 필요한 데이터를 SSH 서버를 통해 application server에 전달한다. 즉 그림에서처럼 forwarded connection을 하게 된다. 터널링은 SSH 클라이언트가 SSH 서버에 접속되어 있을 때에만 유효하고, 연결 시에만 설정할 수 있다.

로컬 포트 포워딩 (Local Port Forwarding)

위에서 언급했던 로컬 포트 포워딩은 리눅스 클라이언트에서는 다음과 같은 형식의 명령어를 통해 사용할 수 있다.

$ ssh -L포트번호1:호스트명:포트번호2 서버명

포트번호1은 SSH 클라이언트가 검사(Listen)하고 있을 포트번호를 지정하는 것이다. 보통 포트번호1은 1024부터 65535사이의 임의의 숫자로 지정한다. 1부터 1023까지의 포트는 예약된 포트로 보통 수퍼유저만이 지정할 수 있기 때문이다.

이 포트번호1로 데이터가 왔을 때 SSH 클라이언트가 SSH 서버로 데이터를 전송하고, SSH 서버는 이 데이터를 다시 호스트명의 포트번호2로 데이터를 보내준다. 이때 이 호스트명은 서버입장에서의 호스트명이다.

Local port forwarding을 사용하면 Host A의 SSH 클라이언트는 사용자가 지정한 로컬 포트를 검사(Listen)하고 있게 된다. Application client가 이 포트로 접속을 하면 SSH 클라이언트는 이 데이터를 Host B에 있는 SSH 서버에 전송하고, 다시 SSH 서버가 application server로 전송하는 것을 보여준다.