LangTailor페이지 목차
이 페이지에서 검색
EIS
이 페이지에 묻기
EIS · 현재 차시와 목차 본문에서만 찾아 답합니다. 답을 지어내지 않고 해당하는 대목을 그대로 보여 주며, 여기에 없으면 없다고 알려 드립니다.
생성형 AI가 아니라 이 페이지 본문을 찾아 그대로 보여 주는 방식입니다. 외부로 나가는 요청이 없습니다.
EIS · SECURITY
EIS
생성 수정
정보보안기사의 시스템·네트워크·애플리케이션 보안과 암호·관리·실기 내용을 개념의 경계와 실습으로 연결합니다.
29개 문서 · 1 · 시스템보안 · 5 / 29
04 · 시스템 보안 대응기술
지도 위치 : 1과목 · README 4장의 ③ 영역(시스템) — 영역 층의 대응기술 쪽. 03번 노트 공격의 짝 | 출제기준: 3. 시스템 보안위협 및 공격에 대한 예방과 대응 > 1. 시스템보안 대응기술 | 이전: 03 시스템 보안위협과 공격기법 | 다음: 05 시스템 분석 도구와 보안 솔루션 출제 빈도 : ⭐⭐ (회당 약 3.3문항 — 출제분석.md) · 변화 – (이전 2.9 → 현행 3.6, 소폭 상승) · ⚠️ 신규 범위 포함 (클라우드 보안 설정, RELRO) 세세항목 : 보안설정, 인증강화, 보안패치, 클라우드 보안 등 관리적 보안 · 시스템 파일 위·변조 방지, 유출방지, 접근통제, 접근제어, 로그분석, 이벤트 분석 등 기술적 보안
이 노트를 다 읽으면
- 하드닝(Hardening)이 무엇이고, 계정 · 서비스 · 공유 · 패치 의 네 가지 정리가 왜 기본인지 말할 수 있다.
- 리눅스 패스워드 정책(PAM 복잡도 · 계정 잠금)과 윈도우 암호 · 계정 잠금 정책을 설정 항목으로 말할 수 있다.
- TCP Wrapper의
hosts.allow·hosts.deny우선순위를 판정하고, iptables 규칙 한 줄을 해석할 수 있다. - 메모리 보호(ASLR · DEP/NX · 스택 가드 · RELRO)가 03번 노트의 어떤 공격을 막는지 짝지을 수 있다.
- 무결성 점검이 무엇을(해시 · 권한 · 시각) 보는지, TMOUT · 배너 · WORM 저장소의 목적을 말할 수 있다.
- 클라우드 보안 설정(퍼블릭 차단 · MFA · 보안그룹)의 기본 점검 항목을 말할 수 있다.
0. 이 노트의 판별 축
| # | 축 | 왼쪽 (0) | 오른쪽 (1) | 이 축으로 갈리는 것 | 큰 축 (README 5장) |
|---|---|---|---|---|---|
| 1 | 언제 작동하나 | 사전 예방 (못 들어오게 · 못 터지게) | 사후 탐지 (들어온 것을 찾기) | 하드닝 · 패치 · 메모리 보호 ↔ 무결성 점검 · 로그 분석 | ④ 예방 ↔ 탐지 · 대응 |
| 2 | 기본값이 허용인가 거부인가 | 블랙리스트 (막을 것만 거부) | 화이트리스트 (허용할 것만 허용) | hosts.deny 일부 ↔ ALL:ALL 후 예외 허용 · 기본 정책 DROP | 이 노트의 축 |
| 3 | 거부를 어떻게 하나 | DROP (조용히 버림) | REJECT (거부 응답을 보냄) | iptables DROP ↔ REJECT · TCP Wrapper | 이 노트의 축 |
| 4 | 무엇을 지키나 | 못 바꾸게 (예방) | 바뀌었는지 확인 (탐지) | 접근통제 · 권한 ↔ 무결성 점검(Tripwire) | ② 무결성 |
| 5 | 누가 책임지나 | 클라우드 제공자 | 클라우드 고객(설정) | 하이퍼바이저 ↔ 퍼블릭 차단 · MFA · 보안그룹 | 01번 노트의 책임 공유 |
이 노트의 질문은 "03번 노트의 공격을 어떻게 미리 막고, 뚫렸을 때 어떻게 알아채는가" 입니다. README 5장 ① 축의 오른쪽(방어)이고, 대부분 ④ 축의 예방 쪽에 놓이되 무결성 점검 · 로그 분석만 탐지 쪽입니다. 앞에서 배운 접근통제 원리(17번 노트)가 여기서 운영체제의 구체적 설정(TCP Wrapper · iptables · 권한)으로 나타납니다.
1. 하드닝 — 공격 표면 줄이기
하드닝 (Hardening, 시스템 강화) — [사전 예방 활동]인데, [ 불필요한 것을 없애고 설정을 안전하게 바꿔 공격 표면을 줄인다 ]는 점에서 사고 뒤 원본을 되살리는 백업 · 복구와 구별된다. ⚠️ 백업은 하드닝 활동이 아닙니다 (사후 대응). 하드닝의 네 기둥:
| 기둥 | 리눅스 | 윈도우 |
|---|---|---|
| ① 계정 정리 | 불필요 · 중복 UID 0 계정 제거, 로그인 셸 /sbin/nologin, 최소 권한 | 기본 계정(Guest) 비활성, 관리자 이름 변경, 불필요 계정 삭제 |
| ② 서비스 정리 | 안 쓰는 데몬 중지(systemctl disable), xinetd disable=yes | 불필요 서비스 중지, 레지스트리 자동 실행 점검 |
| ③ 공유 정리 | — | 기본 관리 공유 제거 (아래), 불필요 공유 해제 |
| ④ 패치 | yum/dnf update 정기 적용 | Windows Update, WSUS |
# 윈도우 기본(관리) 공유 확인과 제거
C:\> net share # C$, ADMIN$, IPC$ 등 목록
C:\> net share C$ /delete # 공유 하나 해제
🔍 읽는 포인트 : C$ · ADMIN$ · IPC$는 윈도우가 자동으로 만드는 기본(관리) 공유 입니다. 널 세션(03번 노트)과 원격 접근에 악용되므로 점검 대상입니다. 재부팅하면 다시 생기므로 레지스트리(AutoShareServer=0)로 막습니다.
# 윈도우 익명(널 세션) 접근 제한
HKLM\SYSTEM\CurrentControlSet\Control\Lsa\RestrictAnonymous = 1
📝 기출 포인트 — "하드닝 활동이 아닌 것 = 백업",
net share로 기본 공유 제거 (3회), 서버 보안 수칙(최소 권한)의 적절성 판단이 반복됩니다.
2. 인증 강화 — 계정 · 패스워드 정책
2.1 패스워드 정책
| 항목 | 뜻 |
|---|---|
| 복잡도 | 길이(최소 8자 이상 권장), 대/소문자 · 숫자 · 특수문자 조합 |
| 최대 사용 기간 | 주기적 변경(만료) |
| 최소 사용 기간 | 너무 자주 바꿔 되돌리는 것 방지 |
| 재사용 제한(history) | 최근 N개 패스워드 재사용 금지 |
| 계정 잠금 임계값 | 로그인 N회 실패 시 계정 잠금(무차별 대입 방어) |
# 리눅스 PAM — 패스워드 복잡도 (pam_pwquality / pam_cracklib)
password requisite pam_pwquality.so minlen=8 lcredit=-1 ucredit=-1 dcredit=-1 ocredit=-1 retry=3
🔍 읽는 포인트 : minlen=8은 최소 길이, lcredit=-1은 소문자 최소 1자 (음수 = 최소 개수), ucredit·dcredit·ocredit은 대문자 · 숫자 · 특수문자. retry=3은 3번까지 다시 입력.
# 리눅스 PAM — 계정 잠금 (pam_faillock)
auth required pam_faillock.so preauth deny=5 unlock_time=600
🔍 읽는 포인트 : 5회 실패하면 600초 (10분) 잠급니다. 윈도우도 같은 개념을 로컬 보안 정책의 계정 잠금 정책 (잠금 임계값 · 기간 · 초기화 시간)으로 설정합니다. 구체적 기준값(예: 10회 이하, 600초 이하)은 KISA 주요정보통신기반시설 취약점 분석·평가 가이드 를 시험 전 확인하세요(출제 원천이지만 판정 수치는 개정될 수 있음 — 확인 필요).
2.2 접근 · 세션 제한
| 항목 | 설정 | 목적 |
|---|---|---|
| root 직접 원격 접속 금지 | SSH PermitRootLogin no | root를 노린 무차별 대입 차단(일반 계정 로그인 후 su/sudo) |
| 세션 타임아웃 | 리눅스 환경변수 TMOUT (초), SSH ClientAliveInterval | 자리 비움 시 자동 로그아웃(ISMS-P도 요구) |
| 접속 배너 | /etc/issue(로컬), /etc/issue.net (원격/네트워크), /etc/motd(로그인 후) | 경고 문구 표시 · 버전 정보 숨김 |
| 신뢰 호스트 제거 | /etc/hosts.equiv, ~/.rhosts 사용 금지 | 패스워드 없는 r-명령 접속 차단 |
| X 서버 접근통제 | xhost(IP 기반) ↔ xauth (.Xauthority 키 기반, 더 안전) | 원격 X 애플리케이션 제어 |
📝 기출 포인트 — PAM 복잡도(
minlen·lcredit등)와 계정 잠금(deny·unlock_time), TMOUT , 윈도우 암호 · 계정 잠금 정책, 배너 파일(issue · issue.net · motd), xhost ↔ xauth가 최근 매회 1~2문항 나옵니다.
3. 접근통제 — TCP Wrapper와 iptables
3.1 TCP Wrapper
TCP Wrapper — [호스트 기반 접근통제]인데, [ 서비스에 들어오는 연결을 hosts.allow · hosts.deny의 IP · 호스트 목록으로 거른다 ]는 점에서 패킷 단위로 거르는 방화벽(iptables)과 구별된다. 접근 기록은 /var/log/secure에 남습니다(02번 노트).
# /etc/hosts.allow
sshd : 192.168.10. # 이 대역은 SSH 허용
# /etc/hosts.deny
ALL : ALL # 그 외 전부 거부
🔍 읽는 포인트 : 판정 순서는 ① hosts.allow를 먼저 보고 맞으면 허용 , ② 없으면 hosts.deny를 보고 맞으면 거부 , ③ 둘 다 없으면 허용 입니다. 그래서 deny에 ALL:ALL을 두고 allow에 예외만 적는 화이트리스트 방식(축 2)이 안전합니다. ⚠️ 최신 RHEL 8/9 등은 TCP Wrapper(tcp_wrappers)를 제거하고 firewalld 를 쓰도록 바뀌었습니다 — 시험은 개념(allow 우선)을 묻지만 실무 환경은 다를 수 있습니다.
3.2 iptables
iptables — [리눅스 호스트 방화벽]인데, [ 커널의 netfilter를 이용해 패킷을 체인별 규칙으로 통제한다 ]는 점에서 연결 요청만 거르는 TCP Wrapper와 구별된다.
| 기본 체인 | 시점 |
|---|---|
| INPUT | 이 시스템으로 들어오는 패킷 |
| OUTPUT | 이 시스템에서 나가는 패킷 |
| FORWARD | 이 시스템을 통과 하는 패킷(라우팅) |
| 타깃 | 뜻 | 축 3 |
|---|---|---|
| ACCEPT | 허용 | — |
| DROP | 조용히 버림 (응답 없음) — 포트가 닫혔는지조차 알기 어려움 | 왼쪽 |
| REJECT | 버리되 거부 응답(ICMP 등)을 보냄 | 오른쪽 |
| LOG | 기록만 하고 다음 규칙으로 | — |
# 특정 IP의 HTTP(80)만 거부 응답과 함께 차단
iptables -A INPUT -s 203.0.113.5 -p tcp --dport 80 -j REJECT
# 들어오는 ICMP(ping) 조용히 차단
iptables -A INPUT -p icmp --icmp-type echo-request -j DROP
# 기본 정책을 거부로 두고 필요한 것만 허용 (화이트리스트)
iptables -P INPUT DROP
iptables -A INPUT -p tcp --dport 22 -s 192.168.10.0/24 -j ACCEPT
# 규칙 저장 / 목록 보기
iptables-save > /etc/sysconfig/iptables
iptables -L -n -v
🔍 읽는 포인트 : -A(규칙 추가) 체인 -s(출발지) -p(프로토콜) --dport(목적지 포트) -j(타깃) 순서로 읽습니다. 위 첫 줄은 "203.0.113.5가 보내는 80 포트 TCP를 거부 응답과 함께 차단". -P는 기본 정책 (규칙에 안 걸린 나머지). sysctl로 커널 파라미터를 바꿔 ICMP 응답을 끄기도 합니다(net.ipv4.icmp_echo_ignore_all=1).
📝 기출 포인트 — iptables(8회)가 1과목 대응기술 최다입니다. 규칙의 차단 방향 해석 , 기본 체인 3개 , REJECT ↔ DROP (특히 "ICMP 거부 응답 = REJECT"), 목록 출력 옵션(
-L), 규칙 저장이 반복됩니다. TCP Wrapper는 allow 우선순위 판정 문제가 단골입니다.
4. 메모리 보호 — 03번 공격의 짝 ⭐
03번 노트의 버퍼 오버플로우 · 포맷 스트링 · Heap Spray를 막는 운영체제 · 컴파일러 수준의 방어입니다.
| 보호 기법 | 막는 방식 | 주로 막는 공격 |
|---|---|---|
| 스택 가드 / 스택 카나리 | 복귀 주소 앞에 카나리 값 을 두고, 함수 종료 시 변조됐는지 검사 | 스택 버퍼 오버플로우 |
| 스택 실드 | 복귀 주소의 사본 을 따로 저장해 두고 비교 | 스택 버퍼 오버플로우 |
| ASLR (주소 공간 배치 무작위화) | 스택 · 힙 · 라이브러리 주소를 매 실행마다 무작위로 → 공격자가 주소를 예측 못 함 | BOF · RTL · Heap Spray |
| DEP / NX 비트 | 데이터 영역(스택 · 힙)에서 코드 실행을 금지 | 주입한 셸코드 실행(단, RTL·ROP로 우회 시도됨) |
| RELRO ⚠️ 신규 | 바이너리의 GOT 등 재배치 섹션을 읽기 전용 으로 만들어 변조 방지 | GOT 덮어쓰기 |
# 리눅스 ASLR 설정 확인/변경
$ cat /proc/sys/kernel/randomize_va_space
2 # 0=끔, 1=스택·라이브러리 무작위화, 2=힙까지 전체 무작위화(권장)
$ sysctl -w kernel.randomize_va_space=2
🔍 읽는 포인트 : 2가 가장 강한 설정 (힙까지), 0은 ASLR 끔입니다. 안전한 함수 사용(strcpy→strncpy)과 시큐어 코딩(16번 노트)은 애초에 넘치지 않게 하는 근본 대책이고, 위 기법들은 넘쳐도 악용을 어렵게 하는 다층 방어입니다.
📝 기출 포인트 — "버퍼 오버플로우 방어 기법이 아닌 것"(ASLR · 스택가드 · NX가 맞고 엉뚱한 것이 오답),
randomize_va_space값의 의미, DEP/NX가 막는 공격, RELRO(신규)가 나옵니다.
5. 무결성 · 로그 · 파일 보호 (사후 탐지)
무결성 점검 — [탐지 활동]인데, [ 중요 파일의 현재 상태(해시 · 권한 · 소유자 · 크기 · 시각)를 기준값(baseline)과 비교해 변조를 찾는다 ]는 점에서 변조를 미리 막는 접근통제와 구별된다(축 4). 대표 도구는 Tripwire (05번 노트)로, 처음에 깨끗한 상태의 해시 DB를 만들어 두고 주기적으로 대조합니다.
| 무결성 점검이 보는 속성 | 비고 |
|---|---|
| 해시값(체크섬) | 내용이 1비트라도 바뀌면 달라짐 — 핵심 |
| 권한 · 소유자 · 그룹 | 퍼미션 변조 탐지 |
| 크기 · inode · 링크 수 | |
| 시각(mtime · ctime) | 변경 시각 |
⚠️ 점검 대상에서 /etc/passwd 같은 중요 파일을 빼면 안 됩니다 (공격자가 가장 노리는 파일). "무결성 점검 대상에서 passwd를 제외한다"는 오답입니다.
| 로그 · 파일 보호 | 핵심 |
|---|---|
| 원격 로그 서버 | syslog @서버(02번 노트) — 공격자가 로컬 로그를 지워도 원본이 남음 |
| WORM 저장소 | Write Once Read Many — 한 번 쓰면 수정 불가 → 로그 위변조 방지 |
| 파일 암호화 | 윈도우 EFS (파일·폴더 단위, NTFS), BitLocker (볼륨 전체, 복구키) — 유출 방지 |
| 변경 불가 속성 | 리눅스 chattr +i(수정 불가), +a(추가만) — 로그에 유용 |
- EFS ↔ BitLocker : EFS는 파일 · 폴더 단위 암호화(NTFS 기능, 사용자 키), BitLocker는 볼륨(드라이브) 전체 암호화(복구키 · TPM 연계). 단위가 다른 것이 핵심입니다.
📝 기출 포인트 — 무결성 점검(4회)은 " 확인 항목이 아닌 것 ", "passwd 제외는 틀림(Tripwire)"이 단골입니다. WORM 저장소 , EFS ↔ BitLocker 암호화 단위 차이 , TMOUT이 최근 나왔습니다.
6. 클라우드 보안 설정 ⚠️ 신규 범위
01번 노트의 책임 공유 모델에서 고객 몫 (축 5)에 해당하는 설정 점검입니다. 실제 클라우드 사고의 대부분이 설정 오류입니다.
| 점검 항목 | 내용 |
|---|---|
| 퍼블릭 접근 차단 | 객체 스토리지(S3 등)를 인터넷 전체 공개로 두지 않기 — 가장 흔한 유출 원인 |
| 계정 보호(MFA) | 관리자 · root 계정에 다중 인증(MFA) 적용, 루트 계정 일상 사용 금지 |
| 최소 권한(IAM) | 사용자 · 역할에 꼭 필요한 권한만 |
| 보안그룹 · 방화벽 | 인바운드 · 아웃바운드 규칙을 꼭 필요한 포트 · 출발지로 제한(가상 방화벽) |
| 백업 · 암호화 | 저장 데이터 암호화, 백업(RDS 등) 활성화 |
| 네트워크 분리 | 퍼블릭 서브넷 ↔ 프라이빗 서브넷 구분, 접근 로그 활성화 |
💡 클라우드 보안 인증제도( CSAP )와 클라우드컴퓨팅법은 22번 노트에서 다룹니다. 여기서는 "설정을 어떻게 안전하게 하는가" 가 범위입니다.
📝 기출 포인트 — 2025년에 "AWS 서브넷 · S3 퍼블릭 차단 · IAM MFA · RDS 백업 · 보안그룹 아웃바운드" 설정을 묻는 문제가 나왔습니다. 클라우드 보안 특성 설명 중 틀린 것 고르기도 있습니다.
7. 실기 연결
수행준거 2.1 "운영체제 보안설정 점검과 보완하기" (계정 · 권한 · 로그 · 원격접속 · 패치)와 2.2 "서비스 보안설정 점검" (불필요 서비스 제거, 공유 점검)에 정확히 대응합니다. 대응기술은 "점검 → 보완" 서술형으로 나옵니다.
자주 나오는 형태
- iptables 규칙 몇 줄을 주고 "어떤 트래픽이 차단/허용되는가" 또는 "특정 IP의 특정 포트만 거부하도록 규칙 작성"
hosts.allow·hosts.deny를 주고 "이 IP의 접속은 허용되는가" → allow 우선 판정- 취약한 설정(root 원격 허용, TMOUT 미설정, world-writable 파일)을 주고 "문제점과 조치"
- "버퍼 오버플로우 대응책을 운영체제 · 컴파일러 · 코드 수준으로 나눠 쓰시오" → ASLR · DEP/NX · 스택 가드 / 안전한 함수
- 무결성 점검 도구가 확인하는 속성 나열
하드닝 점검표(발췌)
| 항목 | 확인 | 조치 |
|---|---|---|
| root 원격 접속 | SSH PermitRootLogin | no로 변경 |
| 세션 타임아웃 | echo $TMOUT | /etc/profile에 TMOUT=600 |
| 불필요 공유 | net share | /delete + 레지스트리로 자동 생성 차단 |
| 계정 잠금 | PAM pam_faillock | deny · unlock_time 설정 |
| 접근통제 | hosts.deny / iptables | 기본 거부 후 예외 허용 |
| 무결성 | Tripwire DB | 기준값 생성 · 정기 비교 |
| 클라우드 | 스토리지 공개 여부 · MFA | 퍼블릭 차단 · MFA 적용 |
💡 서술형은 "현재 상태(취약) → 보안 목표 → 설정 변경 명령/값" 세 줄 틀로 쓰면 감점이 적습니다.
8. 확인 문제
문제 1. 다음 중 시스템 하드닝 활동으로 보기 어려운 것은? ① 불필요한 서비스 중지 ② 기본 관리 공유 제거 ③ 정기 데이터 백업 ④ 사용하지 않는 계정 삭제
문제 2. iptables 타깃 중 패킷을 버리되 거부 응답(ICMP)을 보내는 것은? ① ACCEPT ② DROP ③ REJECT ④ LOG
문제 3. TCP Wrapper에서 hosts.allow에 sshd : 192.168.10., hosts.deny에 ALL : ALL이 있을 때 192.168.10.5의 SSH 접속은?
① 거부된다 ② 허용된다 ③ 로그만 남고 거부된다 ④ 두 파일이 충돌해 오류가 난다
문제 4. /proc/sys/kernel/randomize_va_space 값이 0 이라는 것의 의미는?
① ASLR이 힙까지 전체 적용됨 ② ASLR이 꺼져 있음 ③ DEP가 켜져 있음 ④ 스택 가드가 설정됨
문제 5. 다음 중 버퍼 오버플로우 대응 기법이 아닌 것은? ① 스택 가드(카나리) ② ASLR ③ DEP/NX ④ 포맷 스트링
문제 6. 파일 무결성 점검에서 확인하는 속성으로 보기 어려운 것은? ① 파일의 해시값 ② 파일의 권한과 소유자 ③ 파일의 최종 수정 시각 ④ 파일을 연 사용자의 비밀번호
문제 7. 윈도우 EFS와 BitLocker의 차이로 옳은 것은? ① EFS는 볼륨 전체, BitLocker는 파일 단위 ② EFS는 파일·폴더 단위, BitLocker는 볼륨 전체 ③ 둘 다 FAT32에서만 동작한다 ④ 둘 다 네트워크 전송을 암호화한다
문제 8. 클라우드 보안 설정 점검 항목으로 적절하지 않은 것은? ① 객체 스토리지의 퍼블릭 접근 차단 ② 관리자 계정에 MFA 적용 ③ 하이퍼바이저 커널 패치를 고객이 직접 적용 ④ 보안그룹 아웃바운드 규칙 제한
정답과 해설
| # | 정답 | 해설 (판별 축) |
|---|---|---|
| 1 | ③ | 백업은 사후 대응 (축 1 오른쪽)이라 하드닝(사전 예방)에 들지 않습니다. 나머지는 공격 표면을 줄입니다. |
| 2 | ③ | REJECT는 거부 응답을 보냄(축 3 오른쪽). DROP은 조용히 버립니다. |
| 3 | ② | allow를 먼저 보고 맞으면 허용합니다(192.168.10. 대역 일치). deny의 ALL:ALL은 그 뒤에 봅니다. |
| 4 | ② | 0 = ASLR 끔, 1 = 스택·라이브러리, 2 = 힙까지 전체. |
| 5 | ④ | 포맷 스트링은 공격 기법 입니다(03번 노트). 나머지는 메모리 보호 기법. |
| 6 | ④ | 무결성 점검은 파일의 해시·권한·시각 등 상태 를 봅니다. 사용자 비밀번호는 점검 속성이 아닙니다. |
| 7 | ② | EFS = 파일·폴더 단위(NTFS), BitLocker = 볼륨 전체(복구키). 단위 차이가 핵심입니다. |
| 8 | ③ | 하이퍼바이저·커널은 제공자 책임 (축 5)입니다. 나머지는 고객이 설정할 몫입니다. |
부록 A. 스스로 확인하기
| # | 질문 | 답이 있는 곳 |
|---|---|---|
| 1 | 하드닝의 네 기둥은? 백업이 하드닝이 아닌 이유는? | 1 |
| 2 | 윈도우 기본 공유 세 가지와 제거 명령은? | 1 |
| 3 | PAM 계정 잠금에서 deny와 unlock_time은 무엇인가? | 2.1 |
| 4 | TMOUT · issue.net · xauth는 각각 무엇을 위한 것인가? | 2.2 |
| 5 | TCP Wrapper의 allow/deny 판정 순서는? | 3.1 |
| 6 | iptables 기본 체인 3개와 DROP ↔ REJECT 차이는? | 3.2 |
| 7 | 스택 가드 · ASLR · DEP/NX는 각각 어떤 공격을 막는가? | 4 |
| 8 | randomize_va_space 0 · 1 · 2의 의미는? | 4 |
| 9 | 무결성 점검이 보는 속성 네 가지는? passwd를 빼면 안 되는 이유는? | 5 |
| 10 | WORM 저장소와 원격 로그 서버는 각각 무엇을 막는가? | 5 |
| 11 | EFS와 BitLocker의 암호화 단위 차이는? | 5 |
| 12 | 클라우드에서 고객이 책임질 설정 항목을 세 개 들면? | 6 |
부록 B. 자주 하는 실수 · 함정
| 실수 | 바로잡기 |
|---|---|
| "백업도 하드닝이다" | ❌ 백업은 사후 대응 . 하드닝은 사전 예방 |
| "DROP과 REJECT는 같다" | ❌ DROP은 무응답, REJECT는 거부 응답 |
| "TCP Wrapper는 deny를 먼저 본다" | ❌ allow가 우선 . allow에 맞으면 허용 |
| "iptables INPUT은 나가는 패킷" | ❌ INPUT = 들어오는, OUTPUT = 나가는, FORWARD = 통과 |
| "randomize_va_space는 1이 가장 강하다" | ⚠️ 2 가 힙까지 전체 무작위화 |
| "DEP/NX만 있으면 BOF가 완전히 막힌다" | ⚠️ RTL·ROP로 우회 시도됨 → 여러 기법을 함께 |
| "포맷 스트링은 BOF 대응 기법이다" | ❌ 포맷 스트링은 공격 (03번 노트) |
| "무결성 점검 대상에서 passwd는 빼야 한다" | ❌ 가장 중요한 점검 대상 |
| "EFS는 디스크 전체를 암호화한다" | ❌ 그건 BitLocker. EFS는 파일·폴더 단위 |
| "클라우드는 제공자가 보안을 다 한다" | ❌ 설정·계정·데이터는 고객 몫 |
부록 C. AI · NotebookLM 복습 프롬프트
이 04번 노트만 근거로 4지선다 8문제를 내줘.
하드닝 네 기둥, iptables(DROP/REJECT·체인·규칙 해석), TCP Wrapper allow 우선순위, 메모리 보호(ASLR/DEP/스택가드)와 randomize_va_space, 무결성 점검, 클라우드 설정은 반드시 포함해줘.
iptables 규칙이나 hosts.allow/deny를 주고 해석하는 문제를 하나 넣어줘.
내가 답하면 채점하고, 오답은 노트 0절의 판별 축과 절 번호를 근거로 설명해줘.