[리눅스 기초] NTP, 로그, 방화벽, SELinux, 쉘 스크립트

1. NTP 서버 관리와 시간 동기화

1-1. 시간 동기화가 중요한 이유

서버의 시간은 로그 분석과 보안 관리에서 중요한 역할을 한다. 서버의 시간이 정확하지 않으면 로그에 기록된 사건의 발생 시점을 파악하기 어렵고, 여러 서버의 로그를 비교하거나 장애 원인을 분석하는 데 문제가 생길 수 있다.

따라서 서버의 시간을 정확하게 유지하고, 외부 시간 서버와 동기화하는 것이 중요하다.

1-2. timedatectl

timedatectl은 리눅스 시스템의 시간과 시간대 설정을 확인하고 관리하는 명령어이다.

주요 확인 항목은 다음과 같다.

• Local time: 시스템의 현지 시간
• Universal time: 협정 세계시(UTC)
• RTC time: 하드웨어 시계 시간
• Time zone: 시스템에 설정된 시간대
• System clock synchronized: 시스템 시계의 동기화 여부
• NTP service: NTP 서비스의 활성화 여부

한국에서 서버를 운영한다면 일반적으로 Asia/Seoul 시간대를 사용한다.

시간대 설정과 실제 시간 동기화는 서로 다른 개념이다. 시간대를 한국으로 설정하더라도 시스템 시계 자체가 정확하다는 의미는 아니다.

1-3. Chrony와 NTP

NTP(Network Time Protocol)는 네트워크를 통해 서버 간 시간을 동기화하는 프로토콜이다.

리눅스에서는 Chrony를 사용해 시간 동기화를 관리할 수 있다.

• chrony.conf: 시간 동기화에 사용할 서버와 관련 설정을 관리하는 파일
• pool: 시간을 받아올 서버 풀을 지정하는 설정
• iburst: 초기 시간 동기화 과정에서 여러 요청을 빠르게 보내 동기화를 신속하게 진행하도록 하는 옵션
• chronyd: Chrony의 시간 동기화 서비스
• chronyc sources: 현재 사용 가능한 시간 동기화 소스를 확인하는 명령어

시간 동기화 소스의 상태를 확인하면 현재 어떤 서버가 기준 시간으로 선택되었는지 파악할 수 있다. 설정 파일을 변경했다면 서비스에 변경 사항이 반영되도록 해야 한다.

1-4. restart와 reload의 차이

서비스 설정을 변경한 후에는 변경 사항을 적용해야 한다.

• restart: 서비스를 재시작한다. 기존 프로세스가 종료되고 새로운 프로세스가 실행된다.
• reload: 서비스 프로세스를 종료하지 않고 설정을 다시 읽도록 한다. 지원 여부는 서비스에 따라 다르다.

프로세스 상태와 PID를 확인할 때는 ps 명령어를 사용할 수 있다.

 

2. 리눅스 로그 관리

2-1. 로그의 중요성

로그는 시스템에서 발생한 사건과 작업 내역을 기록한 데이터이다.

로그를 통해 다음과 같은 정보를 확인할 수 있다.

• 시스템 부팅 및 서비스 실행 기록
• 사용자 인증 및 SSH 접속 기록
• 관리자 권한 사용 기록
• 프로그램 오류 및 장애 발생 기록
• 시스템 보안과 관련된 이벤트

로그를 정확하게 분석하려면 서버의 시간이 올바르게 설정되어 있어야 한다.

2-2. journalctl과 /var/log

리눅스에서는 journalctl을 통해 systemd 저널에 수집된 로그를 조회할 수 있다.

한편 /var/log 디렉터리에는 시스템 및 서비스별 로그 파일이 저장된다. rsyslog와 같은 로그 관리 서비스는 설정에 따라 로그를 분류하고 파일에 기록한다.

주요 파일과 역할은 다음과 같다.

• /var/log: 로그 파일이 저장되는 주요 디렉터리
• /etc/rsyslog.conf: rsyslog의 로그 처리 및 저장 규칙을 설정하는 파일
• /var/log/secure: 인증, SSH 접속, sudo 사용 등 보안 관련 로그를 확인하는 파일
• /var/log/maillog: 메일 서비스 관련 로그 파일
• /var/log/cron: cron 작업 관련 로그 파일

로그 파일을 실시간으로 확인하면 새로운 접속이나 작업이 발생했을 때 기록되는 내용을 확인할 수 있다.

2-3. 로그 심각도 수준

로그는 중요도에 따라 여러 수준으로 구분된다.

수준의미

emerg	시스템을 사용할 수 없는 긴급 상황
alert	즉각적인 조치가 필요한 상황
crit	치명적인 문제
err	오류 발생
warn	경고
notice	일반적인 중요 알림
info	정보성 메시지
debug	디버깅을 위한 상세 정보

로그 설정에서 *는 해당 시설(facility)에 속하는 모든 심각도 수준을 대상으로 한다.

예를 들어 인증 관련 로그를 별도 파일에 저장하도록 설정하면 SSH 접속이나 관리자 권한 사용 내역을 집중적으로 확인할 수 있다.

핵심은 로그를 단순히 저장하는 것에 그치지 않고, 목적에 맞게 분류하고 지속적으로 확인하는 것이다.

 

3. 방화벽 관리

3-1. 방화벽의 역할

방화벽은 네트워크 트래픽을 규칙에 따라 허용하거나 차단하는 보안 장치이다. 외부에서 서버로 들어오는 트래픽 중 필요한 것만 허용하고, 불필요하거나 허용되지 않은 접근은 차단한다.

온프레미스 환경에서는 서버의 방화벽을 직접 관리해야 하는 경우가 많다. AWS와 같은 클라우드 환경에서는 보안 그룹 등의 가상 방화벽 기능을 활용할 수 있다.

방화벽은 네트워크 보안의 중요한 1차 방어선이다.

3-2. firewall-cmd와 Zone

리눅스에서는 firewalld 서비스를 관리할 때 firewall-cmd 명령어를 사용할 수 있다.

방화벽 규칙은 서비스, 포트, 네트워크 인터페이스 등의 조건을 기준으로 설정할 수 있다.

Zone은 네트워크 환경과 보안 수준에 따라 방화벽 규칙을 구분하는 단위이다. Zone마다 허용할 서비스와 포트 등을 다르게 설정할 수 있다.

예를 들어 웹 서버용 Zone과 데이터베이스 서버용 Zone을 구분하면 각 서버의 역할에 맞게 접근을 제한할 수 있다.

3-3. 현재 설정과 영구 설정

방화벽 설정은 현재 적용 중인 설정과 영구 설정으로 구분된다.

• 현재 설정(Runtime): 현재 실행 중인 방화벽에 적용되는 설정이다.
• 영구 설정(Permanent): 재부팅 이후에도 유지되도록 저장하는 설정이다.

현재 설정만 변경하면 재부팅하거나 설정을 다시 불러오는 과정에서 변경 사항이 유지되지 않을 수 있다. 영구적으로 적용하려면 영구 설정도 함께 관리해야 한다.

영구 설정을 변경한 뒤에는 reload를 통해 실행 중인 방화벽에 반영할 수 있다. 이때 현재 설정에만 존재하던 변경 사항이 사라질 수 있으므로 두 설정의 차이를 이해해야 한다.

3-4. 서비스와 포트의 차이

방화벽에서는 서비스 이름으로 접근을 허용하거나 포트 번호를 직접 지정할 수 있다.

서비스 이름을 사용하면 해당 서비스에 필요한 규칙을 적용할 수 있고, 포트를 직접 지정하면 특정 프로토콜과 포트 번호를 기준으로 접근을 제어할 수 있다.

주요 포트 번호는 다음과 같다.

포트용도

22	SSH 원격 접속
80	HTTP 웹 통신
443	HTTPS 웹 통신
3306	MySQL/MariaDB 데이터베이스 통신

웹 서버 프로그램이 정상적으로 실행 중이어도 방화벽에서 HTTP 서비스나 해당 포트를 허용하지 않으면 외부에서 접속할 수 없다.

반대로 방화벽에서 포트를 열었다고 해서 서비스가 자동으로 실행되는 것은 아니다. 서비스 실행 상태와 방화벽 허용 규칙을 함께 확인해야 한다.

3-5. 파일 권한과 웹 접근

웹 서버가 파일을 제공하려면 해당 파일에 대한 접근 권한도 적절해야 한다.

웹 서버의 방화벽 설정이 올바르더라도 파일을 읽을 권한이 없으면 요청한 콘텐츠를 제공하지 못할 수 있다.

따라서 웹 접근 문제를 해결할 때는 다음 항목을 구분해서 확인해야 한다.

• 웹 서버 프로세스가 실행 중인지
• 방화벽에서 서비스 또는 포트를 허용하는지
• 웹 서버가 파일에 접근할 수 있는 권한이 있는지
• SELinux 보안 정책이 접근을 차단하고 있지 않은지

 

4. SELinux 보안 관리

4-1. SELinux란?

SELinux(Security-Enhanced Linux)는 기존의 리눅스 사용자 및 파일 권한과 별개로 추가적인 접근 제어를 제공하는 보안 시스템이다.

일반적인 파일 권한에서 접근이 허용되더라도 SELinux 정책에 위배되면 접근이 차단될 수 있다.

SELinux는 서비스의 역할과 파일의 유형 등을 기준으로 접근을 제한하여, 특정 서비스가 자신의 목적과 관련 없는 파일이나 자원에 접근하는 것을 방지한다.

예를 들어 Apache 웹 서버 프로세스와 웹 콘텐츠 디렉터리에 적절한 보안 컨텍스트를 부여하여 다른 서비스와의 접근을 분리할 수 있다.

4-2. 보안 컨텍스트와 유형(Type)

SELinux는 프로세스와 파일 등에 보안 컨텍스트를 부여한다.

보안 컨텍스트는 사용자, 역할, 유형 등의 정보를 포함하며, 이 중 **유형(Type)**은 접근 제어에서 특히 중요한 요소이다.

대표적인 유형은 다음과 같다.

• httpd_t: Apache 웹 서버 프로세스에 사용되는 유형
• httpd_sys_content_t: 웹 서버가 제공하는 콘텐츠에 사용하는 유형

웹 서버 프로세스의 유형과 파일의 유형이 보안 정책에 맞아야 정상적인 접근이 가능하다.

파일을 웹 디렉터리에 복사했다고 해서 항상 적절한 SELinux 컨텍스트가 부여되는 것은 아니다. 복사 방식에 따라 기존 컨텍스트가 유지될 수 있으며, 이 경우 웹 서버의 접근이 차단될 수 있다.

4-3. SELinux의 작동 모드

SELinux에는 세 가지 주요 모드가 있다.

모드설명

Enforcing	보안 정책을 적용하고 정책 위반 접근을 차단한다.
Permissive	정책 위반을 차단하지 않고 경고와 로그를 남긴다.
Disabled	SELinux 보안 정책을 사용하지 않는다.

setenforce 명령어로 실행 중인 모드를 Enforcing과 Permissive 사이에서 전환할 수 있다. Disabled 설정은 설정 파일을 통해 관리한다.

보안 관점에서는 SELinux를 무조건 비활성화하기보다 Enforcing 상태를 유지하면서 필요한 정책을 올바르게 설정하는 것이 중요하다.

4-4. semanage와 restorecon

SELinux의 파일 컨텍스트를 관리할 때 중요한 도구는 semanage와 restorecon이다.

• semanage: 파일 경로에 적용할 보안 컨텍스트 규칙 등을 관리한다.
• restorecon: 설정된 규칙에 따라 파일과 디렉터리의 보안 컨텍스트를 적용하거나 복구한다.

예를 들어 웹 콘텐츠 디렉터리를 기본 경로가 아닌 다른 경로로 변경했다면, 해당 경로에 적절한 SELinux 유형이 적용되도록 규칙을 설정해야 한다.

여기서 중요한 점은 규칙을 등록하는 것과 실제 파일에 적용하는 것이 서로 다른 단계라는 것이다.

semanage로 규칙을 설정하고, restorecon으로 적용한다.

또한 웹 서버의 콘텐츠 경로를 변경했다면 Apache 설정의 DocumentRoot도 실제 경로와 일치하도록 관리해야 한다.

4-5. SELinux와 포트의 관계

SELinux는 파일과 프로세스뿐 아니라 서비스가 사용하는 포트에도 유형을 적용한다.

Apache 웹 서버는 일반적으로 HTTP 서비스에 허용된 포트를 사용한다. 웹 서버 설정에서 기존 포트를 다른 번호로 변경했을 때, 해당 포트가 SELinux의 허용 대상에 포함되지 않으면 서비스 실행이 실패할 수 있다.

이 경우 다음 항목을 확인해야 한다.

• 웹 서버 설정에서 지정한 포트 번호
• 방화벽에서 허용한 포트
• SELinux에서 HTTP 서비스에 허용한 포트 유형

웹 서버의 포트를 변경했다면 방화벽 규칙뿐 아니라 SELinux의 포트 정책도 확인해야 한다.

4-6. SELinux Boolean

SELinux Boolean은 보안 정책의 일부 기능을 켜거나 끄는 설정이다.

Boolean을 사용하면 전체 보안 정책을 비활성화하지 않고도 특정 동작을 허용하거나 제한할 수 있다.

현재 설정을 확인하고, 실행 중인 설정을 변경하거나 영구 설정을 적용할 수 있다. 영구 설정은 재부팅 이후에도 유지되도록 관리한다.

SELinux 문제를 해결할 때는 무조건 보안 기능을 끄는 것보다 필요한 유형, 포트, Boolean 설정을 확인하는 것이 중요하다.

 

5. 쉘과 쉘 스크립트

5-1. 쉘(Shell)이란?

리눅스의 핵심에는 운영체제의 자원을 관리하는 커널(Kernel)이 있다. 쉘은 사용자와 커널 사이에서 명령어를 해석하고 실행을 요청하는 인터페이스이다.

사용자가 터미널에 명령어를 입력하면 쉘이 이를 해석하고, 커널이나 관련 프로그램이 실제 작업을 수행한다. 이후 결과가 다시 사용자에게 전달된다.

대표적인 쉘로는 Bash가 있다.

5-2. 쉘 스크립트란?

쉘 스크립트는 여러 명령어를 파일에 작성하여 순서대로 실행할 수 있도록 만든 것이다.

반복적으로 수행하는 작업을 스크립트로 작성하면 작업을 자동화할 수 있다.

예를 들어 패키지 설치와 서비스 실행을 하나의 스크립트로 구성하면 여러 명령어를 매번 직접 입력하지 않아도 된다.

쉘 스크립트의 핵심 요소는 다음과 같다.

• 실행할 명령어: 자동화할 작업을 순서대로 작성한다.
• Shebang: 스크립트를 해석할 인터프리터를 지정한다. Bash 스크립트에서는 일반적으로 /bin/bash를 지정한다.
• 실행 권한: 스크립트를 실행 파일처럼 직접 실행하려면 적절한 실행 권한이 필요하다.
• 파일 위치: 자주 사용하는 명령어로 등록하려면 실행 경로에 파일을 배치하는 방법을 사용할 수 있다.

리눅스에서는 파일의 확장자보다 파일의 내용과 실행 권한이 중요하다. .sh 확장자를 사용한다고 해서 자동으로 실행 가능한 쉘 스크립트가 되는 것은 아니다.

 

6. 리눅스 사용자와 파일 권한

6-1. /etc/passwd와 UID

/etc/passwd는 리눅스 사용자 계정 정보를 저장하는 파일이다.

각 행에는 사용자 이름, UID, GID, 사용자 정보, 홈 디렉터리, 로그인 쉘 등의 정보가 포함된다.

UID(User ID)는 사용자를 식별하는 숫자이며, 리눅스는 이를 기반으로 사용자 권한을 관리한다.

특히 root 계정은 UID 0을 사용하며 시스템 전반에 강력한 권한을 가진다. 따라서 root 권한의 사용과 원격 접속을 적절히 제한하는 것이 중요하다.

6-2. 파일과 디렉터리 권한

리눅스의 기본 권한은 읽기(r), 쓰기(w), 실행(x)으로 구분된다.

파일과 디렉터리에서 권한의 의미는 다르다.

권한파일에서의 의미디렉터리에서의 의미

r	파일 내용을 읽을 수 있음	디렉터리의 파일 목록을 확인할 수 있음
w	파일 내용을 변경할 수 있음	파일 생성 및 삭제 등의 작업을 수행할 수 있음
x	파일을 실행할 수 있음	디렉터리에 접근하거나 내부 항목을 탐색할 수 있음

디렉터리의 내용을 확인하거나 내부 파일에 접근하려면 권한 조합이 중요하다. 특히 디렉터리의 읽기 권한과 실행 권한은 서로 다른 역할을 한다.

웹 서버에서 파일을 제공할 때도 파일 자체의 읽기 권한뿐 아니라 상위 디렉터리에 접근할 수 있는 권한이 필요하다.

6-3. umask와 기본 권한

umask는 새 파일이나 디렉터리를 생성할 때 기본 권한에서 제거할 권한을 지정한다.

일반적으로 리눅스에서 파일의 기본 권한 기준은 666, 디렉터리는 777이다. 여기에 umask가 적용되어 실제 생성 권한이 결정된다.

예를 들어 umask가 022라면 일반 파일은 644, 디렉터리는 755 권한으로 생성된다.

따라서 umask는 새로 생성되는 파일과 디렉터리의 기본 접근 수준을 관리하는 중요한 설정이다.

 

7. KISA 서버 취약점 점검 핵심

서버 보안 점검에서는 계정 관리와 인증 정책을 확인하는 것이 중요하다.

주요 점검 항목은 다음과 같다.

• root 계정의 원격 접속 제한: SSH 설정에서 root의 직접 원격 로그인을 제한한다.
• 패스워드 정책: 비밀번호 최대 사용 기간, 최소 길이, 만료 전 경고 기간 등을 적절하게 설정한다.
• 사용자 계정 관리: /etc/passwd의 사용자 정보와 UID 등을 확인하여 계정을 관리한다.
• 시큐어 코딩: JavaScript와 Python 등의 애플리케이션을 개발할 때 보안 취약점을 예방하는 코딩 가이드를 준수한다.

서버의 보안은 방화벽만으로 완성되지 않는다. 계정과 인증 정책, 파일 권한, 서비스 설정, 애플리케이션의 취약점을 함께 관리해야 한다.

 

8. 웹 서버와 HTTP/HTTPS

8-1. 클라이언트와 서버

웹 통신은 클라이언트의 요청(Request)과 서버의 응답(Response)을 중심으로 이루어진다.

클라이언트가 웹 페이지나 리소스를 요청하면 서버는 요청을 처리하고 결과를 응답한다. 웹 서버를 운영할 때는 서비스 실행 여부뿐 아니라 네트워크 연결, 방화벽, 파일 권한, 보안 정책을 함께 확인해야 한다.

8-2. HTTP 응답 코드

HTTP 응답 코드는 요청 처리 결과를 나타낸다.

응답 코드의미

200	요청이 정상적으로 처리됨
300번대	리다이렉션 등 추가적인 처리가 필요함
400번대	클라이언트 요청과 관련된 오류
404	요청한 페이지나 리소스를 찾을 수 없음
500번대	서버에서 요청을 처리하는 중 오류가 발생함

웹 페이지에 접근할 수 없을 때는 응답 코드와 서버 로그를 함께 확인하면 문제 원인을 파악하는 데 도움이 된다.

8-3. HTTP와 HTTPS의 차이

HTTP는 기본적으로 통신 내용을 암호화하지 않는다. 따라서 네트워크에서 통신 내용을 관찰할 수 있는 환경에서는 전송되는 정보가 노출될 위험이 있다.

HTTPS는 TLS를 사용해 통신 내용을 암호화하고, 인증서를 통해 서버의 신원을 확인할 수 있도록 한다.

• HTTP: 통신 내용을 암호화하지 않는 프로토콜
• HTTPS: TLS를 통해 통신을 보호하는 HTTP
• SSL/TLS 인증서: 서버 인증과 보안 통신 설정에 사용되는 인증서

HTTPS는 통신 내용의 기밀성과 무결성을 보호하고, 서버 인증을 지원하는 데 중요한 역할을 한다.

8-4. sitemap.xml과 웹 정보

sitemap.xml은 웹 사이트의 주요 페이지와 URL 정보를 검색 엔진 등에 전달하기 위해 사용하는 파일이다.

사이트 구조를 파악하는 데 도움이 되므로 외부에 공개되는 페이지 정보를 적절히 관리해야 한다. 다만 사이트맵에 URL이 포함되어 있다는 사실 자체가 해당 페이지의 취약성을 의미하는 것은 아니다.