정보보안기사 | /etc 디렉토리 설정 파일 정리 — 역할과 관계

정보보안기사 | /etc 디렉토리 설정 파일 정리 — 역할과 관계

🗂️ 정보보안기사 | /etc 디렉토리 설정 파일 정리 — 역할과 관계

passwd · shadow · hosts · xinetd · PAM · rsyslog · crontab…
파일이 왜 이렇게 흩어져 있는지, 6개 기능 그룹으로 묶어서 관계까지 한번에 정리합니다.

#정보보안기사 #리눅스설정파일 #/etc디렉토리 #파일관계 #실기대비

📋 목차

  • 1. /etc 디렉토리 — 왜 설정 파일이 여기에 모여 있는가
  • 2. 기능 및 그룹과 파일 간 관계
  • 3. 그룹 ① 계정 및 인증 관리 — passwd · shadow · group · login.defs · pam.d/system-auth
  • 4. 그룹 ② 네트워크 이름 분석 — host.conf · hosts · resolv.conf
  • 5. 그룹 ③ 서비스 식별 — services
  • 6. 그룹 ④ 접근 제어 — hosts.allow · hosts.deny · xinetd.conf · xinetd.d/
  • 7. 그룹 ⑤ 신뢰 관계 — hosts.equiv
  • 8. 그룹 ⑥ 환경·스케줄·로그 — profile · crontab · rsyslog.conf
  • 9. 전체 정리표 — 17개 파일 한눈에 보기
  • 10. 실전 연습 문제 5선

1. /etc 디렉토리 — 왜 설정 파일이 여기에 모여 있는가

리눅스에서 /etc“Editable Text Configuration”의 약자로 해석되기도 하고, 역사적으로는 “et cetera(기타 등등)”에서 유래했습니다. 어떤 해석이든, 이 디렉토리의 역할은 명확합니다. 시스템 전역의 설정 파일이 집결하는 중앙 저장소입니다.

문제는 여기에 수백 개의 파일이 있다 보니, 정보보안기사 실기를 준비하면서 “이 파일이 왜 있는 거지?”, “이 파일은 저 파일이랑 어떤 관계지?”라는 혼란이 반복된다는 점입니다. 개별 파일을 하나씩 외우는 건 한계가 있습니다. 대신, 파일들이 맡고 있는 역할 그룹을 먼저 이해하면 자연스럽게 연결 관계가 보이기 시작합니다.

💡 이 글의 접근법

17개 파일을 6개 기능 그룹으로 분류합니다. 각 그룹 안에서 파일들이 어떻게 맞물려 작동하는지 — 즉 “연관 관계”를 중심으로 정리합니다. 개별 파일의 세부 설정값보다는, 왜 그 파일이 존재하는지에 집중합니다.


2. 기능 및 그룹 과 파일 간 관계

🗺️ 사용자가 시스템에 접근할 때 관여하는 파일 흐름
① 계정/인증 ② 이름 분석 ③ 서비스 식별 ④ 접근 제어 ⑤ 신뢰 관계 ⑥ 환경/스케줄/로그
그룹 ①
계정 및 인증
passwd · shadow · group · login.defs · pam.d/system-auth
그룹 ②
네트워크 이름 분석
host.conf · hosts · resolv.conf
그룹 ③
서비스 식별
services
그룹 ④
접근 제어
hosts.allow · hosts.deny · xinetd.conf · xinetd.d/
그룹 ⑤
신뢰 관계
hosts.equiv (+ ~/.rhosts)
그룹 ⑥
환경 · 스케줄 · 로그
profile · crontab · rsyslog.conf

이제 각 그룹 내에서 파일들이 어떻게 연결되는지 하나씩 풀어보겠습니다.


3. 그룹 ① 계정 및 인증 관리

사용자가 시스템에 로그인할 때 가장 먼저 동작하는 파일 그룹입니다. 이 5개 파일은 “이 사람이 누구인지 확인하고, 들여보낼지 결정하는” 과정을 분담합니다.

3-1. /etc/passwd & /etc/shadow — 계정 정보의 분리 저장

🔗 매핑 관계
과거에는 passwd 파일 하나에 계정 정보와 암호가 함께 저장되었습니다.
보안 문제로 해시된 암호패스워드 에이징(Aging) 정보shadow로 분리되었습니다.
passwd의 패스워드 필드에는 x만 표시되고, 실제 인증 시에는 shadow를 참조합니다.
구분/etc/passwd/etc/shadow
역할계정 기본 정보 (UID, GID, 홈디렉토리, 셸)해시된 암호 + 패스워드 정책
권한644 (모든 사용자 읽기 가능)400 또는 000 (root만 접근)
포맷root:x:0:0:root:/root:/bin/bashroot:$6$hash:19000:0:99999:7:::
분리 이유passwd는 다른 프로그램이 UID/GID 조회용으로 읽어야 하므로 공개, 암호 해시는 격리
# /etc/passwd 포맷 (7개 필드, 콜론 구분)
사용자명:x:UID:GID:설명:홈디렉토리:로그인셸
root:x:0:0:root:/root:/bin/bash
nobody:x:65534:65534:Nobody:/:/sbin/nologin

# /etc/shadow 포맷 (9개 필드, 콜론 구분)
사용자명:해시암호:최종변경일:MIN:MAX:WARN:INACTIVE:EXPIRE:예약
root:$6$abc...:19723:0:90:7:30::
🎯 시험 출제 포인트
  • shadow 필드 순서: 최종변경일 → MIN(최소 사용일) → MAX(최대 사용일) → WARN(만료 경고일) → INACTIVE(비활성 유예일) → EXPIRE(계정 만료일)
  • shadow 파일 권한: 400 또는 000이 아니면 취약점 → “shadow 파일 퍼미션을 확인하라”는 서술형 단골
  • passwd에서 셸이 /sbin/nologin 또는 /bin/false이면 → 로그인 차단 목적의 시스템 계정

3-2. /etc/group — 그룹 기반 권한 부여

역할
/etc/group
시스템의 그룹 정보 + 해당 그룹에 속한 사용자 목록을 정의. 파일/디렉토리에 대한 그룹 권한(rwx 중 group 영역)의 기준이 됩니다.
passwd와의 관계
GID 연결
passwd의 4번째 필드(GID)가 이 파일의 그룹 ID를 참조. 사용자의 기본 그룹(primary group)을 결정합니다.
# /etc/group 포맷 (4개 필드)
그룹명:암호:GID:소속사용자목록
wheel:x:10:user1,user2
developers:x:1001:user1,user3

3-3. /etc/login.defs — 계정 생성 시 기본 정책

🔗 매핑 관계: login.defs → shadow
login.defsuseradd 명령으로 새 계정을 만들 때 적용되는 기본값 템플릿입니다.
여기서 지정한 PASS_MAX_DAYS, PASS_MIN_DAYS, PASS_MIN_LEN 등의 값이 → 새 계정의 shadow 파일 필드에 자동 반영됩니다.
즉, login.defs는 “정책의 원본”이고, shadow는 “정책이 적용된 결과”입니다.
# /etc/login.defs 주요 항목
PASS_MAX_DAYS   90      # 패스워드 최대 사용 기간 → shadow의 MAX 필드
PASS_MIN_DAYS   1       # 패스워드 최소 사용 기간 → shadow의 MIN 필드
PASS_MIN_LEN    8       # 패스워드 최소 길이
PASS_WARN_AGE   7       # 만료 경고 시작일 → shadow의 WARN 필드
UID_MIN         1000    # 일반 사용자 UID 시작 범위
UID_MAX         60000   # 일반 사용자 UID 끝 범위
ENCRYPT_METHOD  SHA512  # 암호 해시 알고리즘

3-4. /etc/pam.d/system-auth — 리눅스 인증의 심장

🔗 매핑 관계: PAM → 전체 인증 흐름 통제
사용자가 로그인을 시도하면 → PAM(Pluggable Authentication Modules)이 system-auth를 참조하여 인증을 수행합니다.
PAM은 passwd/shadow를 직접 읽는 것이 아니라, pam_unix.so 모듈을 통해 간접 참조합니다.
패스워드 복잡도, 계정 잠금, 인증 순서를 모두 이 파일 하나에서 통제합니다.
PAM 모듈역할설정 예시
pam_unix.so기본 UNIX 인증 (passwd/shadow 참조)auth required pam_unix.so
pam_cracklib.so패스워드 복잡도 검증password requisite pam_cracklib.so retry=3 minlen=8
pam_tally2.so로그인 실패 시 계정 잠금auth required pam_tally2.so deny=5 unlock_time=120
pam_faillock.sopam_tally2의 후속 모듈 (최신 배포판)auth required pam_faillock.so deny=5
🎯 시험 출제 포인트 — 그룹 ① 전체
  • “패스워드 에이징 정책이 실제로 저장되는 파일은?” → /etc/shadow
  • “새 계정 생성 시 패스워드 정책의 기본값을 지정하는 파일은?” → /etc/login.defs
  • “패스워드 5회 실패 시 계정을 잠그는 설정을 하는 파일은?” → /etc/pam.d/system-auth
  • 5개 파일의 작동 순서: login.defs(정책 정의) → useradd(계정 생성) → passwd/shadow/group(정보 저장) → PAM(인증 실행)

4. 그룹 ② 네트워크 이름 분석 (DNS Resolution)

사용자가 도메인 이름을 입력했을 때, 시스템이 그것을 IP 주소로 변환하는 과정에 관여하는 파일 그룹입니다. 이 세 파일은 확인 순서가 정해져 있으며, 그 순서 자체가 시험에 나옵니다.

🔄 이름 분석 순서 (반드시 암기)
① /etc/host.conf → 순서 결정 ② /etc/hosts → 로컬 조회 ③ /etc/resolv.conf → 외부 DNS 질의
🔗 3개 파일의 매핑 관계
host.conforder hosts,bind라고 설정되어 있으면 → 시스템은 먼저 /etc/hosts를 확인합니다.
hosts에서 매칭되는 레코드가 없으면 → resolv.conf에 지정된 외부 DNS 서버에 질의합니다.
현대 배포판에서는 host.conf 대신 /etc/nsswitch.conf가 이 순서를 제어하기도 합니다.
파일역할포맷 / 설정 예시
/etc/host.conf이름 분석 순서를 지정order hosts,bind
multi on
/etc/hosts로컬 정적 매핑 (도메인→IP)127.0.0.1 localhost
192.168.1.10 myserver
/etc/resolv.conf외부 DNS 서버 주소nameserver 8.8.8.8
nameserver 168.126.63.1
⚠️ 보안 위협: 파밍(Pharming) 공격

공격자가 /etc/hosts 파일을 변조하면, 사용자가 정상 도메인을 입력해도 가짜 IP(피싱 사이트)로 연결됩니다. DNS 서버를 경유하기 전에 로컬 hosts 파일을 먼저 참조하기 때문에, 이 파일이 변조되면 DNS 보안과 무관하게 공격이 성립합니다.

“파밍 공격 시 가장 먼저 변조를 시도하는 파일은?” → /etc/hosts (단골 출제)


5. 그룹 ③ 서비스 식별

5-1. /etc/services — 포트 번호의 전화번호부

핵심 역할
서비스명 ↔ 포트 번호 매핑
이 파일은 “ssh = 22번 포트”, “http = 80번 포트”처럼 이름과 번호를 연결하는 참조 테이블입니다. 포트를 열거나 서비스를 실행하는 기능은 전혀 없습니다.
누가 참조하나?
xinetd · netstat · 방화벽
xinetd가 service telnet 블록을 읽을 때, “telnet = 23번 포트”라는 정보를 이 파일에서 가져옵니다. netstat -an 결과에서 포트 번호를 서비스명으로 표시할 때도 참조됩니다.
# /etc/services 포맷
ftp-data  20/tcp
ftp       21/tcp
ssh       22/tcp
telnet    23/tcp
smtp      25/tcp
dns       53/tcp
dns       53/udp
http      80/tcp
pop3      110/tcp
https     443/tcp
🎯 시험 출제 포인트
  • “포트 번호와 서비스명을 매핑하는 파일은?” → /etc/services
  • 이 파일 자체는 실행 기능 없음 — “services 파일을 수정하면 포트가 열린다”는 함정 선지 주의
  • Well-known 포트: FTP 20/21, SSH 22, Telnet 23, SMTP 25, DNS 53, HTTP 80, POP3 110, IMAP 143, HTTPS 443

6. 그룹 ④ 서비스 접근 제어 (TCP Wrapper & xinetd)

외부에서 특정 서비스(Telnet, FTP, SSH 등)로 접속을 시도할 때 거치는 검문소입니다. 이 그룹의 핵심은 TCP Wrapper와 xinetd의 작동 순서를 이해하는 것입니다.

6-1. /etc/hosts.allow & /etc/hosts.deny — TCP Wrapper

🔒 TCP Wrapper 평가 순서 (반드시 암기)
① /etc/hosts.allow 확인 → 매칭되면 허용 (끝)
② /etc/hosts.deny 확인 → 매칭되면 차단 (끝)
③ 둘 다 미매칭 기본 정책: 허용
# 화이트리스트 방식 (가장 안전, 가장 많이 출제)

# /etc/hosts.deny — 먼저 전체 차단
ALL: ALL

# /etc/hosts.allow — 필요한 것만 열기
sshd: 192.168.1.0/255.255.255.0
in.telnetd: 10.10.10.
vsftpd: 172.16.0.
⚠️ 시험 함정 주의

TCP Wrapper는 모든 서비스에 적용되는 것이 아닙니다. libwrap 라이브러리를 링크한 데몬에만 적용됩니다.

확인 방법: ldd /usr/sbin/sshd | grep libwrap

6-2. /etc/xinetd.conf & /etc/xinetd.d/ — 슈퍼 데몬

🔗 TCP Wrapper → xinetd 작동 순서
외부 접속 요청이 들어오면 → TCP Wrapper(hosts.allow/deny)가 먼저 IP를 검사합니다.
TCP Wrapper를 통과하면 → xinetd가 해당 서비스를 기동합니다.
xinetd 자체에도 접근 제어 기능(only_from, no_access)이 내장되어 있어 2중 필터가 가능합니다.
전체 설정
/etc/xinetd.conf
모든 하위 서비스에 공통 적용되는 기본값(defaults)을 정의. 로그 설정, 동시 접속 수 등.
개별 서비스
/etc/xinetd.d/서비스명
telnet, ftp 등 각 서비스별 설정 파일이 디렉토리 내에 개별 존재. 서비스 활성화/비활성화 제어.
# /etc/xinetd.d/telnet — 블록 구조
service telnet
{
    disable     = no              # 서비스 활성화
    socket_type = stream          # TCP
    wait        = no              # 다중 접속 허용
    user        = root
    server      = /usr/sbin/in.telnetd
    only_from   = 192.168.1.0/24  # 허용 IP 대역
    no_access   = 192.168.1.100   # 차단 IP
    log_on_failure += USERID HOST # 실패 시 로깅
}
🎯 시험 출제 포인트 — 그룹 ④ 전체
  • TCP Wrapper 평가 순서: allow → deny → 기본 허용
  • 화이트리스트 공식: deny에 ALL: ALL → allow에 필요한 IP만 등록
  • xinetd 핵심 항목: disable, only_from, no_access, socket_type, server
  • 작동 순서: TCP Wrapper 통과 → xinetd 기동 (순서 자체가 시험 문제)

7. 그룹 ⑤ 신뢰 관계 (Trust Relationship)

7-1. /etc/hosts.equiv & ~/.rhosts

시스템 전체
/etc/hosts.equiv
rlogin, rsh 같은 r-command 서비스 사용 시, 패스워드 없이 접속을 허용하는 호스트를 시스템 전체 레벨에서 지정합니다.
사용자 개별
~/.rhosts
특정 사용자의 홈 디렉토리에 존재하며, 해당 사용자에 대해서만 신뢰 호스트를 지정합니다.
⚠️ 취약점 진단 핵심 항목

파일 내용에 + 기호가 있으면 → “모든 호스트에서 패스워드 없이 접속 허용”을 의미합니다. 취약점 진단 시 가장 먼저 확인하는 항목 중 하나입니다.

조치: 파일 자체를 삭제하거나, + 기호를 제거하고 필요한 호스트만 명시적으로 등록합니다.

🎯 시험 출제 포인트
  • “r-command 서비스의 신뢰 관계를 설정하는 파일은?” → /etc/hosts.equiv (시스템 전체) / ~/.rhosts (사용자 개별)
  • + 기호 = 모든 호스트 허용 (심각한 보안 취약점)
  • 주요 취약점 진단 가이드(KISA 등)에서 “불필요한 r-command 서비스 비활성화”가 필수 점검 항목

8. 그룹 ⑥ 시스템 환경 · 스케줄링 · 로그

이 그룹은 “사용자 로그인 후”에 동작하는 파일들입니다. 환경 설정, 예약 작업, 감사 로그 — 시스템 운영의 기반이 되는 3가지 기능을 담당합니다.

8-1. /etc/profile — 시스템 전역 환경 설정

🔗 실행 순서: /etc/profile → 사용자 개별 설정
사용자가 로그인하면 → /etc/profile가장 먼저 실행됩니다. (시스템 전역 환경변수)
그 다음 → 각 사용자 홈 디렉토리의 ~/.bash_profile~/.bashrc 순서로 실행됩니다.
/etc/profile모든 사용자에게 공통 적용, 개인 설정 파일은 해당 사용자에게만 적용.
# /etc/profile 보안 관련 주요 설정
umask 022          # 기본 파일 생성 권한 마스크
TMOUT=300          # 300초(5분) 무응답 시 자동 로그아웃
PATH=/usr/bin:/bin # 기본 실행 경로
export PATH TMOUT
🎯 시험 출제 포인트
  • umask 022 → 파일 기본 권한 644(666-022), 디렉토리 기본 권한 755(777-022)
  • TMOUT → 세션 타임아웃 설정. “무응답 시 자동 로그아웃 설정 방법은?” 서술형 단골
  • 실행 순서: /etc/profile~/.bash_profile~/.bashrc

8-2. /etc/crontab — 시스템 예약 작업

🔗 매핑 관계: /etc/crontab vs 사용자 cron
/etc/crontab → 시스템(root) 기준의 예약 작업. 실행 사용자를 명시적으로 지정합니다.
/var/spool/cron/사용자명 → 일반 사용자의 개별 크론 작업. crontab -e로 편집.
/etc/cron.allow, /etc/cron.deny → 크론 사용 접근 제어 파일.
# /etc/crontab 포맷 (7개 필드 — 사용자 필드 포함)
# 분  시  일  월  요일  사용자  명령어
0    3   *   *   0    root    /usr/sbin/logrotate
30   2   1   *   *    root    /scripts/monthly-backup.sh

# 일반 사용자 cron (6개 필드 — 사용자 필드 없음)
# 분  시  일  월  요일  명령어
*/5  *   *   *   *    /home/user/check.sh
💡 cron.allow / cron.deny 동작 방식

cron.allow가 존재하면 → 이 파일에 등록된 사용자만 cron 사용 가능 (화이트리스트)

cron.allow가 없고 cron.deny만 존재하면 → deny에 등록된 사용자만 차단, 나머지 허용

둘 다 없으면 → 배포판마다 다름 (RHEL: root만 / Debian: 전체 허용)

8-3. /etc/rsyslog.conf — 로그 관리의 컨트롤 타워

🔗 매핑 관계: rsyslog.conf → /var/log/ 디렉토리
rsyslog.conf는 어떤 종류의 로그를 어디에 저장할지 결정하는 라우팅 룰입니다.
이 설정에 따라 → 인증 로그는 /var/log/secure, 메일 로그는 /var/log/maillog, 시스템 로그는 /var/log/messages로 분배됩니다.
과거에는 syslog.conf였으나, 현대 배포판에서는 rsyslog.conf로 대체되었습니다. 포맷은 호환됩니다.
# /etc/rsyslog.conf 룰 포맷
# Facility.Priority    Action(저장 위치)

authpriv.*             /var/log/secure      # 인증 관련 모든 로그
mail.*                 /var/log/maillog     # 메일 관련 모든 로그
cron.*                 /var/log/cron        # 크론 실행 로그
*.emerg                :omusrmsg:*          # 긴급 로그 → 모든 사용자에게 전송
*.info;mail.none       /var/log/messages    # info 이상, 메일 제외
구분Facility (로그 종류)Priority (심각도, 낮음→높음)
주요 값auth, authpriv, cron, daemon, kern, mail, user, local0~7debug → info → notice → warning → err → crit → alert → emerg
시험 포인트“인증 관련 로그의 Facility는?” → authpriv“가장 높은 Priority는?” → emerg
특수 표기* = 모든 Facility/Priority, none = 해당 Facility 제외, ; = 복수 조건 연결
🎯 시험 출제 포인트 — 그룹 ⑥ 전체
  • /etc/profile: umaskTMOUT 설정 방법 서술형
  • /etc/crontab: 시스템 크론(7필드) vs 사용자 크론(6필드) 차이, cron.allow/deny 동작 방식
  • /etc/rsyslog.conf: Facility.Priority 문법, Priority 순서(debug~emerg), 침해사고 시 /var/log/ 확인

9. 전체 매핑 정리표 — 17개 파일 한눈에 보기

그룹파일한 줄 역할연관 파일/작동 순서시험 빈도
① 계정
인증
/etc/passwd계정 기본 정보 (UID, GID, 셸)shadow와 쌍 (암호 분리)★★★
/etc/shadow해시 암호 + 패스워드 에이징login.defs의 정책이 반영됨★★★
/etc/group그룹 정보 + 소속 사용자passwd의 GID 참조★★☆
/etc/login.defs계정 생성 시 기본 정책 템플릿→ shadow 필드에 반영★★★
/etc/pam.d/system-auth인증 모듈 설정 (PAM)passwd/shadow를 간접 참조★★★
② 이름
분석
/etc/host.conf이름 분석 순서 결정hosts → resolv.conf 순서 지정★★☆
/etc/hosts로컬 정적 도메인↔IP 매핑host.conf에 의해 우선 참조됨★★★
/etc/resolv.conf외부 DNS 서버 주소 지정hosts에서 미발견 시 질의★★☆
③ 서비스
식별
/etc/services포트 번호 ↔ 서비스명 매핑xinetd, netstat 등이 참조★★☆
④ 접근
제어
/etc/hosts.allowTCP Wrapper 허용 목록allow → deny 순서로 평가★★★
/etc/hosts.denyTCP Wrapper 차단 목록allow에 없으면 deny 확인★★★
/etc/xinetd.conf슈퍼 데몬 전체 기본 설정TCP Wrapper 통과 후 작동★★★
/etc/xinetd.d/개별 서비스별 설정 파일 디렉토리xinetd.conf 하위 확장★★★
⑤ 신뢰
관계
/etc/hosts.equivr-command 패스워드 없는 접속 허용~/.rhosts와 사용자/시스템 구분★★★
⑥ 환경
스케줄
로그
/etc/profile시스템 전역 환경변수 (umask 등)→ ~/.bash_profile → ~/.bashrc★★★
/etc/crontab시스템 예약 작업 (root 기준)/var/spool/cron/과 역할 분리★★★
/etc/rsyslog.conf로그 라우팅 룰 (어디에 저장할지)→ /var/log/ 디렉토리에 분배★★★

10. 실전 연습 문제 5선

Q1 새 계정 생성 시 패스워드 최대 사용 기간을 90일로 설정하려면 어떤 파일의 어떤 항목을 수정해야 하는가? 그리고 이 설정이 실제로 저장되는 파일은?
→ /etc/login.defs의 PASS_MAX_DAYS 90 설정. 계정 생성 시 /etc/shadow의 MAX 필드에 반영됨. login.defs = 정책 원본, shadow = 정책 적용 결과. 이미 생성된 계정에는 chage -M 90 사용자명으로 직접 변경 필요.
Q2 시스템에서 도메인 이름을 IP로 변환할 때, /etc/hosts와 DNS 서버 중 어느 것을 먼저 참조하는가? 그 순서를 결정하는 파일은?
→ /etc/host.conf (또는 /etc/nsswitch.conf)에서 순서를 결정. 일반적으로 hosts 파일을 먼저 참조한 후 DNS 서버에 질의. host.conf에 order hosts,bind 설정 시 /etc/hosts → /etc/resolv.conf(DNS) 순. 파밍 공격은 이 순서를 악용하여 hosts 파일을 먼저 변조.
Q3 TCP Wrapper에서 SSH 접속을 192.168.1.0/24 대역에서만 허용하고, 나머지는 모두 차단하는 설정을 hosts.allow와 hosts.deny에 각각 작성하시오.
→ /etc/hosts.allow: sshd: 192.168.1.0/255.255.255.0 | /etc/hosts.deny: ALL: ALL deny에서 전체 차단 후 allow에서 필요 대역만 허용하는 화이트리스트 방식. allow가 deny보다 먼저 평가되므로 이 순서로 동작.
Q4 /etc/hosts.equiv 파일에 + 기호만 기재되어 있다면, 보안상 어떤 문제가 있으며 조치 방법은?
→ 모든 호스트에서 패스워드 없이 원격 접속이 허용됨. 파일 삭제 또는 + 기호 제거 후 필요 호스트만 명시적으로 등록. r-command(rlogin, rsh)를 통한 비인가 접근의 원인. 근본 조치는 r-command 서비스 자체를 비활성화하고 SSH로 대체하는 것.
Q5 rsyslog.conf에서 인증 관련 모든 레벨의 로그를 /var/log/secure에 저장하는 설정을 작성하시오. 또한 Priority가 가장 높은 레벨은?
→ authpriv.* /var/log/secure | Priority가 가장 높은 레벨은 emerg (시스템 사용 불가 수준) Facility = authpriv (인증), Priority = * (모든 레벨). Priority 순서: debug < info < notice < warning < err < crit < alert < emerg.