2. Netzwerksicherheit · 실제 시험 Abschnitt 2.1
2.1. Multiple Choice
네트워크 MC 8개를 시험지의 a–h 순서와 문구 그대로 학습합니다.
이 페이지는 비슷한 주제를 임의로 다시 묶지 않고 실제 시험지의 Chapter → subsection → 소문제 순서를 그대로 따릅니다.
ACTUAL EXAM · VERBATIM TRANSCRIPT
시험지 원문 1:1 전사
아래 내용은 해설자가 바꿔 쓴 요약이 아닙니다. 실제 시험 전사본의 문장·순서·수치·배점·코드·표를 그대로 두고, Markdown 기호만 읽기 쉬운 제목·표·코드 모양으로 표시했습니다.
2.1. Multiple Choice (16 Punkte)
Bitte kreuzen Sie für jede der folgenden Aussagen „Wahr“ oder „Falsch“ an.
Nur eine der beiden Auswahlmöglichkeiten ist richtig.
Jede korrekte Antwort gibt zwei Punkte und erfordert keine weitere Begründung.
| Nr. | Wahr | Falsch | Aussage |
|---|---|---|---|
| a) | ☐ | ☐ | DDoS ist eine spezielle Variante des DoS, bei der der Angreifer mehrere Opfer gleichzeitig angreift (statt nur ein Opfer). |
| b) | ☐ | ☐ | Auch eine betrügerische Webseite kann ein gültiges TLS-Zertifikat haben. |
| c) | ☐ | ☐ | BGP-Nachrichten von Autonomen Systemen können falsche Informationen enthalten. |
| d) | ☐ | ☐ | DNS over HTTPS (DoH) verhindert einen DNS-Cache-Poisoning-Angriff auf den Resolver. |
| e) | ☐ | ☐ | Wenn eine Firewall alle ausgehenden Ports außer Port 53 blockiert, können nur DNS-Anfragen durchkommen und deshalb keine Daten abfließen. |
| f) | ☐ | ☐ | Ein Angreifer hat ein Mailkonto attacker@example.com und versendet darüber eine Mail mit gespooftem Absender ceo@example.com. Wenn der empfangende Server SPF (Sender Policy Framework) verwendet, erkennt er, dass der Absender gespooft ist. |
| g) | ☐ | ☐ | NSEC-Records können zum Auflisten der vorhandenen Domänen verwendet werden. |
| h) | ☐ | ☐ | Wenn Sie korrekt Tor verwenden, weiß Ihr externer Resolver dennoch, mit welcher Domäne Sie sich verbinden wollen. |
근거: CSS_Altklausur_WiSe_2526.pdf 및 computersystemsicherheit_wise25-26_questions_only.md · Abschnitt 2.1
VISUAL MAP
네트워크 MC 보호 범위 확인 왼쪽에서 오른쪽으로 읽은 뒤 아래 실제 소문제에서 같은 순서를 반복합니다.- 01 기술 식별
- 02 보호 대상
- 03 보호 구간
- 04 우회·반례
- 05 판정
FIXED SOLVING METHOD
이 묶음의 고정 풀이 순서
- 문장의 프로토콜 또는 공격 이름을 찾습니다.
- 보호 목표가 기밀성·무결성·인증·가용성 중 무엇인지 적습니다.
- 기술이 실제로 보호하는 통신 구간을 그립니다.
- 공격자가 다른 필드·포트·경로를 쓸 수 있는지 확인합니다.
- 전체 문장을 W/F로 판정합니다.
ZERO-BASE CONCEPT LESSONS
이 묶음을 풀기 전에 필요한 개념
카드를 열고 닫는 방식 대신 한 방향으로 이어지는 글로 구성했습니다. 비유 → 용어의 쉬운 뜻 → 실제 작동 → 시험에서의 경계 순서로 천천히 읽으세요.
기초 개념 01
네트워크에서 누가 누구에게 무엇을 보내는가
먼저 장면으로 이해해 봅시다. IP address가 아파트 건물 주소라면 port는 몇 호인지, protocol은 택배 봉투를 어떤 양식으로 쓰는지, router는 다음 물류 센터를 고르는 역할에 가깝다.
이제 전문 용어를 붙이면 다음과 같습니다. Packet은(는) 네트워크에서 header와 payload를 갖고 전달되는 데이터 단위입니다. IP address은(는) IP 계층에서 출발지와 목적지 host/interface를 식별하는 주소입니다. Port은(는) 한 host 안에서 어떤 application/service가 데이터를 받을지 구분하는 번호입니다. Protocol은(는) 통신 참여자가 message 형식과 순서를 해석하기로 합의한 규칙입니다.
실제 시스템에서는 이렇게 작동합니다. 네트워크는 여러 장치가 정해진 protocol에 따라 packet 또는 message를 주고받는 시스템이다. Client는 서비스를 요청하는 쪽, server는 서비스를 제공하는 쪽이다. IP address는 네트워크에서 장치를 찾는 주소이고 port는 한 장치 안에서 어떤 프로그램과 통신할지 구분하는 번호다. Router는 목적지 네트워크를 보고 packet을 다음 경로로 전달한다.
- 송신자와 수신자를 먼저 적는다.
- 출발지·목적지 IP와 port를 구분한다.
- 중간 장치가 내용을 읽는지 단순히 전달하는지 구분한다.
- 응답이 어느 방향으로 돌아오는지 그린다.
여기서 넘지 말아야 할 경계: 하나의 port 번호가 그 port를 이용하는 데이터의 의미까지 보장하지는 않는다.
08. Packet·주소·계층 독립 강의 →기초 개념 02
DoH와 DNSSEC는 서로 다른 문제를 해결한다
먼저 장면으로 이해해 봅시다. DoH는 전화번호부 안내원에게 가는 통화를 도청하기 어렵게 암호화한 전화선이고, DNSSEC는 전화번호부 항목 자체에 발행 기관의 위조하기 어려운 도장을 찍는 것이다.
이제 전문 용어를 붙이면 다음과 같습니다. DoH은(는) DNS over HTTPS로 client와 resolver 사이 DNS message를 HTTPS 안에 암호화합니다. DNSSEC은(는) DNS record에 대한 signature chain으로 data origin과 integrity를 검증하는 확장입니다. Authenticity은(는) 받은 정보가 주장된 권한 있는 출처에서 왔는지를 확인하는 성질입니다. Transport encryption은(는) 통신 구간에서 제3자가 내용을 읽거나 쉽게 바꾸지 못하게 하는 보호입니다.
실제 시스템에서는 이렇게 작동합니다. DNS over HTTPS(DoH)는 사용자와 선택한 resolver 사이의 DNS message를 HTTPS 안에 넣어 전송한다. 주변 Wi-Fi나 단순한 중간 관찰자가 질문을 쉽게 읽거나 바꾸기 어렵게 하지만 resolver 자체는 질문을 본다. DNSSEC는 DNS record에 digital signature를 붙여 resolver가 authoritative data의 출처와 무결성을 검증하게 한다.
- 공격자가 사용자와 resolver 사이에 있는지 resolver의 cache를 공격하는지 구분한다.
- DoH는 transport privacy를, DNSSEC는 signed data validation을 제공한다.
- DoH만으로 악성 resolver나 poisoned cache의 거짓 답을 자동 검증하지는 못한다.
여기서 넘지 말아야 할 경계: HTTPS를 사용한다는 이유만으로 DNS answer의 진위성이 자동 보장된다고 쓰면 안 된다.
10. DoH·DNSSEC·Amplification 독립 강의 →기초 개념 03
DNSSEC의 ‘없음’ 증명과 NSEC zone walking
먼저 장면으로 이해해 봅시다. 명부에 ‘김 다음은 박이며 그 사이 이름은 없음’이라고 서명해 주면 거짓 부재를 막을 수 있지만, 그 문장을 계속 모으면 전체 명부 순서를 재구성할 수 있다.
이제 전문 용어를 붙이면 다음과 같습니다. NSEC은(는) DNSSEC에서 어떤 이름이 존재하지 않음을 서명된 형태로 증명하는 record입니다. Authenticated denial은(는) 요청한 DNS 이름이나 type이 없다는 사실을 검증 가능하게 답하는 기능입니다. Zone walking은(는) NSEC의 다음 이름 정보를 반복 따라가며 zone의 이름 목록을 추론하는 작업입니다. NSEC3은(는) 이름을 hash한 형태로 부재 증명을 제공해 단순 zone walking을 어렵게 하는 대안입니다.
실제 시스템에서는 이렇게 작동합니다. DNSSEC는 존재하는 record뿐 아니라 ‘이 이름은 존재하지 않는다’는 답도 인증해야 한다. NSEC record는 정렬된 다음 domain name과 현재 이름에 존재하는 record type을 알려 주어 두 이름 사이에는 다른 이름이 없음을 증명한다. 이 next-name 연결을 반복해서 따라가면 zone에 존재하는 이름을 열거하는 zone walking이 가능할 수 있다.
- 존재하지 않는 이름을 질의해 signed denial response를 받는다.
- NSEC의 next domain name을 읽는다.
- 다음 이름 주변을 다시 질의해 다음 NSEC를 얻는다.
- 처음으로 돌아올 때까지 반복해 공개 zone 이름을 수집한다.
여기서 넘지 말아야 할 경계: Zone walking은 DNSSEC 서명을 깨는 공격이 아니라 인증된 부재 증명에 포함된 정보를 열거에 재사용하는 부작용이다.
기초 개념 04
TLS certificate가 확인하는 것과 확인하지 않는 것
먼저 장면으로 이해해 봅시다. 건물 등기와 열쇠가 맞는지는 확인하지만 그 건물 안 가게가 좋은 물건을 파는지까지 보증하는 것은 아닌 것과 같다.
이제 전문 용어를 붙이면 다음과 같습니다. Certificate은(는) domain 이름 같은 identity와 public key를 CA의 signature로 연결한 전자 문서입니다. CA은(는) Certificate Authority로, 정해진 검증 뒤 certificate에 서명하는 신뢰 기관입니다. Certificate chain은(는) server certificate에서 browser가 신뢰하는 root CA까지 이어지는 서명 관계입니다. Hostname verification은(는) 접속한 domain 이름이 certificate에 허용된 이름과 일치하는지 확인하는 절차입니다.
실제 시스템에서는 이렇게 작동합니다. Certificate는 특정 domain name과 public key를 연결하고 Certificate Authority(CA)가 그 연결을 확인했다는 서명된 문서다. Browser는 접속한 domain이 certificate의 이름과 맞는지, 신뢰하는 CA가 서명했는지, 유효 기간과 서명 체인이 맞는지 검사한다. 이것은 현재 연결 상대가 그 domain의 private key를 가졌다는 근거를 주지만 사업자의 정직성이나 상품 품질을 보증하지 않는다.
- URL의 hostname과 certificate의 SAN 이름을 비교한다.
- CA signature와 trust chain을 확인한다.
- Server가 certificate public key에 대응하는 private key를 가졌음을 handshake에서 증명한다.
- Domain control과 사람·회사에 대한 도덕적 신뢰를 구분한다.
여기서 넘지 말아야 할 경계: 사기 사이트도 자신이 통제하는 domain에 대해서는 valid certificate를 받을 수 있다.
13. TLS certificate·Domain validation·CA 독립 강의 →ACTIVE RECALL
이 페이지를 닫기 전 확인
- DDoS의 distributed는 누구를 가리키나요?
- DoH와 DNSSEC의 보호 목표 차이는?
- 유효한 TLS 인증서가 사이트의 정직성을 보증하나요?
QUESTION-BY-QUESTION COMMENTARY
실제 시험 소문제별 해설
시험지의 번호와 순서를 그대로 유지했습니다. 각 항목을 열어 원문 → 쉬운 개념 설명 → 이번 문제의 단계별 풀이 → 답안 → 함정 순서로 읽으세요.
ACTUAL EXAM SUBSECTION 2.1
2.1. Multiple Choice
8개 학습 항목 · 16점
2.1 a) DDoS는 공격자가 하나의 Opfer가 아니라 여러 Opfer를 동시에 공격하는 DoS의 특수한 형태다. Wahr/Falsch? 기존 71문항 학습 번호 17 · 2점 Wahr/Falsch
2.1 a) · 실제 시험 원문
한국어로 요구사항만 풀어 읽기
DDoS는 공격자가 하나의 Opfer가 아니라 여러 Opfer를 동시에 공격하는 DoS의 특수한 형태다. Wahr/Falsch?
TERMS FOR 2.1 a)
이 소문제의 중요한 용어부터 이해하기
전문 용어를 알고 있다고 가정하지 않습니다. 아래 정의의 굵은 용어를 문제 문장 속 같은 단어와 바꾸어 읽은 뒤 풀이로 넘어가세요.
네트워크에서 header와 payload를 갖고 전달되는 데이터 단위입니다.
IP 계층에서 출발지와 목적지 host/interface를 식별하는 주소입니다.
한 host 안에서 어떤 application/service가 데이터를 받을지 구분하는 번호입니다.
통신 참여자가 message 형식과 순서를 해석하기로 합의한 규칙입니다.
공격자로부터 지키려는 대상입니다. 파일, 비밀번호, 서비스 가용성, 사람의 개인정보가 모두 asset이 될 수 있습니다.
허가받지 않은 사람이 내용을 읽지 못하게 하는 기밀성입니다.
데이터나 시스템이 허가 없이 바뀌지 않았음을 보장하려는 무결성입니다.
정당한 사용자가 필요할 때 서비스와 데이터에 접근할 수 있는 가용성입니다.
이 소문제만을 위한 0부터 시작하는 미니 강의
아래 설명은 이 과목의 선행 지식을 가정하지 않습니다. 개념 → 비유의 대응 → 눈으로 읽는 구조 → 작은 예제 순서로 읽은 뒤 실제 시험 풀이로 넘어가세요.
1 · 먼저 알아야 할 개념
가용성(Availability, Verfügbarkeit)은 허가된 사용자가 필요할 때 서비스를 쓸 수 있다는 보안 목표다. 서버가 살아 있어도 회선, CPU, 메모리, 연결 테이블 중 하나가 고갈되어 정상 요청을 처리하지 못하면 가용성이 깨진다.
DoS(Denial of Service)는 이런 자원을 고갈시키거나 오류를 일으켜 서비스를 못 쓰게 하는 공격의 큰 범주다. 공격 트래픽이 많다는 사실만으로 DDoS가 되는 것은 아니며, 한 공격 장비가 수행하면 여전히 DoS일 수 있다.
DDoS(Distributed DoS)의 Distributed는 공격 트래픽의 발생원이 여러 네트워크와 장비에 분산되어 있다는 뜻이다. 공격자는 감염된 PC·서버·IoT 장비의 집합인 botnet을 원격 조종하여 한 표적에 동시에 요청을 보낼 수 있다.
따라서 공격원 수와 피해자 수는 서로 다른 축이다. 수천 개 bot이 서버 한 대를 공격하면 DDoS이고, 한 장비가 여러 서버를 차례로 공격한다고 해서 피해자가 여럿이라는 이유만으로 DDoS가 되지는 않는다.
2 · 일상 장면으로 먼저 잡기
공연장 입구 하나에 정상 관객이 들어가려는데, 서로 다른 도시에서 온 수천 명이 동시에 그 입구만 막아서는 장면
비유의 경계 현실의 DDoS는 사람 수만의 문제가 아니라 대역폭, 상태 테이블, 애플리케이션 비용 등 여러 자원을 노리며 source IP spoofing이나 reflection도 사용할 수 있다.
서로 다른 위치에서 요청 생성
모든 요청이 같은 서비스로 집중
대역폭·연결·CPU 고갈
응답 실패, 가용성 상실
왼쪽의 source가 여러 개인지 먼저 보고, 오른쪽 피해자 수는 DDoS 정의와 분리해서 읽는다.
스마트 카메라 300대가 도서관 예약 서버 하나를 공격하는 경우
주어진 것과 목표 Eve가 감염시킨 카메라 300대와 정상 이용자가 쓰는 library.example 서버 한 대가 있다. 이 상황이 DoS인지 DDoS인지 판단한다.
Eve가 300대 카메라에 동시에 library.example로 요청을 반복하라고 명령한다.
왜? 공격 트래픽의 실제 발생원을 여러 장비로 분산하기 위해서다.
중간 결과 서로 다른 300개 위치에서 한 서버로 요청이 몰린다.
서버의 연결 처리 한도와 회선 용량을 공격 요청이 채운다.
왜? 제한된 자원을 소진하면 정상 요청을 지연시키거나 실패시킬 수 있다.
중간 결과 학생의 정상 예약 요청이 timeout 된다.
공격원과 피해자 수를 따로 센다.
왜? DDoS의 정의 기준은 분산된 공격원이지 여러 피해자가 아니기 때문이다.
중간 결과 공격원 300개, 피해 서비스 1개이므로 DDoS라고 결론 낸다.
예제 결론 피해 서버가 하나여도 공격 트래픽이 다수의 분산 장비에서 오므로 DDoS다.
실제 시험으로 옮기기 시험 문장의 mehrere Opfer를 여러 공격원으로 바꾸어 읽어야 한다. 문장이 피해자 수를 정의 기준으로 삼았으므로 Falsch다.
이번 문제는 이 단계로 풀어야 했습니다
먼저 문제에서 직접 주어진 값과 최종적으로 구할 값을 분리합니다. 그다음 각 값·용어·경로를 왜 선택했는지 확인하며, 앞 단계의 중간 결과를 다음 단계의 입력으로 사용합니다.
먼저 문제를 식과 조건으로 정리하기
계산을 시작하기 전에 주어진 것과 구할 것을 분리합니다. 그다음 아래 관계식을 위에서 아래로 사용하면, 숫자가 어디서 왔는지 놓치지 않을 수 있습니다.
강사가 문제의 요구사항을 쉬운 말로 바꾸면
시험 문장이 요구하는 것: DDoS는 공격자가 하나의 Opfer가 아니라 여러 Opfer를 동시에 공격하는 DoS의 특수한 형태다. Wahr/Falsch?
이 문제의 풀이 전략: 이 소문제에서는 보안 목표 찾기 → D의 주어 확인 → 한 피해자 반례 만들기 → 문장 전체 판정 순서로 진행합니다. 마지막에는 ‘DDoS는 여러 분산된 공격원이 하나 또는 여러 표적의 가용성을 공격하는 DoS다.’라는 교정 기준으로 답을 다시 확인합니다.
문제에서 주어진 정보
DDoS는 공격자가 하나의 Opfer가 아니라 여러 Opfer를 동시에 공격하는 DoS의 특수한 형태다. Wahr/Falsch?
DoS와 DDoS 모두 정상 사용자가 서비스를 못 쓰게 하므로 직접 겨냥하는 목표는 Verfügbarkeit다.
기밀성이나 무결성이 아니라 가용성을 적었는가?
최종적으로 구해야 하는 것
앞부분의 'DDoS는 DoS의 변형'은 맞지만, 뒷부분의 정의가 틀렸으므로 전체는 Falsch다.
정답은 Falsch다. DDoS에서 분산된 것은 피해자가 아니라 공격 트래픽을 발생시키는 장비들이다. 많은 bot이 하나의 서버나 서비스만 공격해도 DDoS가 성립한다. 따라서 여러 Opfer를 동시에 공격해야 한다는 시험 문장의 정의가 틀렸다.
사용할 공식·판정 관계
보안 목표 찾기 → D의 주어 확인 → 한 피해자 반례 만들기 → 문장 전체 판정
왼쪽의 source가 여러 개인지 먼저 보고, 오른쪽 피해자 수는 DDoS 정의와 분리해서 읽는다.
보안 목표 찾기
구체적으로 DoS와 DDoS 모두 정상 사용자가 서비스를 못 쓰게 하므로 직접 겨냥하는 목표는 Verfügbarkeit다.
여기서 검산 기밀성이나 무결성이 아니라 가용성을 적었는가?
다음 단계로 여기서 확인한 내용을 다음 ‘D의 주어 확인’ 단계의 출발점으로 사용합니다.
D의 주어 확인
구체적으로 Distributed가 수식하는 것은 공격을 만들어 내는 sources, 예를 들면 botnet의 장비들이다.
여기서 검산 distributed victims라고 바꾸어 쓰지 않았는가?
다음 단계로 여기서 확인한 내용을 다음 ‘한 피해자 반례 만들기’ 단계의 출발점으로 사용합니다.
한 피해자 반례 만들기
구체적으로 10,000개 bot이 웹서버 하나만 공격해도 전형적인 DDoS가 성립한다.
여기서 검산 문장의 여러 Opfer 조건이 필수가 아님을 반례가 보여 주는가?
다음 단계로 여기서 확인한 내용을 다음 ‘문장 전체 판정’ 단계의 출발점으로 사용합니다.
문장 전체 판정
구체적으로 앞부분의 'DDoS는 DoS의 변형'은 맞지만, 뒷부분의 정의가 틀렸으므로 전체는 Falsch다.
여기서 검산 부분적으로 맞는 표현 때문에 Wahr를 고르지 않았는가?
다음 단계로 앞 단계의 결과를 모아 채점 가능한 최종 답안으로 정리합니다.
정답과 해설
정답은 Falsch다. DDoS(Distributed Denial of Service)는 여러 공격 시스템이 보통 하나의 목표 서비스나 Opfer의 Verfügbarkeit를 떨어뜨리는 DoS 변형이다. 여러 Opfer를 동시에 공격한다는 것이 정의의 핵심이 아니다.
정답이 이렇게 되는 이유
정답은 Falsch다. DDoS에서 분산된 것은 피해자가 아니라 공격 트래픽을 발생시키는 장비들이다. 많은 bot이 하나의 서버나 서비스만 공격해도 DDoS가 성립한다. 따라서 여러 Opfer를 동시에 공격해야 한다는 시험 문장의 정의가 틀렸다.
초보자가 가장 자주 뒤집는 지점
잘못된 생각 피해 사이트가 여러 개면 Distributed이므로 DDoS다.
왜 틀렸나 피해자 수는 공격원의 분산 여부를 알려 주지 않는다. 한 공격 장비가 여러 사이트를 공격하는 상황도 가능하다.
고쳐 말하면 DDoS는 여러 분산된 공격원이 하나 또는 여러 표적의 가용성을 공격하는 DoS다.
한 문제만 더: 개념이 정말 연결됐는지 확인
질문 한 노트북이 회사 서버 20대를 공격하고, 감염 PC 5,000대가 쇼핑몰 서버 한 대를 공격한다. 어느 쪽이 정의상 DDoS인가?
정답 두 번째다. 피해자는 한 곳이지만 공격 트래픽 source가 감염 PC 5,000대로 분산되어 있다.
이 문제의 오답 함정
이 소문제를 점수로 바꾸는 6개의 작은 훈련
해설을 닫은 상태에서 1번부터 수행하세요. 정답을 읽은 직후보다 직접 문제 지도를 만들고 답을 꺼낸 뒤 채점할 때 기억이 더 정확해집니다. 작성 내용과 복습 판정은 이 브라우저에 자동 저장됩니다.
해설을 보지 말고 주어진 정보 → 구할 것 → 사용할 공식·판정 관계를 한 줄씩 복원하세요.
막힐 때만 첫 단서 열기
DDoS의 첫 D는 victim 수가 아니라 공격원이 어디에 분산되어 있는지를 가리킨다.
DDoS는 공격자가 하나의 Opfer가 아니라 여러 Opfer를 동시에 공격하는 DoS의 특수한 형태다. Wahr/Falsch?
정답 문장만 말하지 말고 근거·중간값·메시지 흐름 중 이 문항에 필요한 것을 빈 종이에 남기세요.
작성한 뒤에만 아래 기준을 열고, 실제로 쓴 항목만 체크하세요.
답안 작성 후 채점 기준 열기
답안 슬롯 자가 점검 — 실제로 말하거나 쓴 항목만 체크하세요.
0/3 slots
조건 변형: 원문의 강한 표현(예: muss, immer, vollständig)을 조건부 표현으로 하나 고쳐 쓰고, 그 변경 뒤에는 판정이 왜 달라지거나 유지되는지 반례와 함께 설명하세요.
고칠 답안: Distributed를 여러 피해자로 해석하기
복구 힌트: DDoS의 첫 D는 victim 수가 아니라 공격원이 어디에 분산되어 있는지를 가리킨다.
오답의 첫 잘못된 전제를 한 줄로 지우고, 올바른 조건과 결론을 두 줄로 다시 쓰세요.
채점 전 예상과 실제 채점 결과가 달랐는지 확인한 뒤 상태를 남기세요. ‘숙달’은 근거와 중간 과정까지 무힌트로 재현했을 때만 선택합니다.
모든 훈련을 마친 뒤 핵심 정답 다시 확인
정답은 Falsch다. DDoS(Distributed Denial of Service)는 여러 공격 시스템이 보통 하나의 목표 서비스나 Opfer의 Verfügbarkeit를 떨어뜨리는 DoS 변형이다. 여러 Opfer를 동시에 공격한다는 것이 정의의 핵심이 아니다.
2.1 b) 사기성 Webseite도 gültiges TLS-Zertifikat를 가질 수 있다. Wahr/Falsch? 기존 71문항 학습 번호 18 · 2점 Wahr/Falsch
2.1 b) · 실제 시험 원문
한국어로 요구사항만 풀어 읽기
사기성 Webseite도 gültiges TLS-Zertifikat를 가질 수 있다. Wahr/Falsch?
TERMS FOR 2.1 b)
이 소문제의 중요한 용어부터 이해하기
전문 용어를 알고 있다고 가정하지 않습니다. 아래 정의의 굵은 용어를 문제 문장 속 같은 단어와 바꾸어 읽은 뒤 풀이로 넘어가세요.
Browser와 server 사이 전송 내용을 암호화하고 변조를 탐지하며 보통 server를 인증하는 통신 보호입니다.
작은 예: HTTPS는 네트워크 도청을 줄이지만 URL이 browser history나 server log에 남는 문제까지 없애지는 않습니다.
네트워크에서 header와 payload를 갖고 전달되는 데이터 단위입니다.
IP 계층에서 출발지와 목적지 host/interface를 식별하는 주소입니다.
한 host 안에서 어떤 application/service가 데이터를 받을지 구분하는 번호입니다.
통신 참여자가 message 형식과 순서를 해석하기로 합의한 규칙입니다.
domain 이름 같은 identity와 public key를 CA의 signature로 연결한 전자 문서입니다.
Certificate Authority로, 정해진 검증 뒤 certificate에 서명하는 신뢰 기관입니다.
server certificate에서 browser가 신뢰하는 root CA까지 이어지는 서명 관계입니다.
이 소문제만을 위한 0부터 시작하는 미니 강의
아래 설명은 이 과목의 선행 지식을 가정하지 않습니다. 개념 → 비유의 대응 → 눈으로 읽는 구조 → 작은 예제 순서로 읽은 뒤 실제 시험 풀이로 넘어가세요.
1 · 먼저 알아야 할 개념
HTTPS는 HTTP 통신을 TLS로 보호한다. TLS는 통신 내용을 도청하기 어렵게 하는 기밀성, 전송 중 변경을 탐지하는 무결성, 그리고 보통 접속한 서버의 도메인 인증을 제공한다.
TLS 인증서에는 bob.net 같은 도메인 이름, 공개키, 유효기간, 발급한 인증기관(CA), CA의 전자서명 등이 들어간다. 브라우저는 접속 hostname이 인증서의 SAN에 있는지, 기간이 유효한지, 신뢰하는 CA까지 서명 chain이 이어지는지 확인한다.
많은 인증서는 신청자가 해당 도메인을 제어한다는 Domain Validation을 통과하면 발급된다. 예를 들어 CA가 지정한 token을 특정 HTTP 경로에 놓거나 DNS record에 넣게 한다.
이 검증은 '이 신청자가 이 도메인을 제어한다'는 기술적 사실을 다룬다. 사업자가 정직한지, 상품이 진짜인지, 페이지가 phishing인지, 웹 애플리케이션에 취약점이 없는지는 인증서의 검증 범위가 아니다.
2 · 일상 장면으로 먼저 잡기
우체국이 어떤 주소의 우편함 열쇠를 가진 사람에게 그 주소로 가는 봉투용 공식 도장을 내주는 장면
비유의 경계 현실의 인증서는 공개키와 도메인을 암호학적으로 묶으며 브라우저가 여러 검사를 수행한다. 단순 주소 확인보다 기술적으로 강하지만 운영자의 선량함을 심사하지 않는다는 경계는 같다.
접속 hostname, CA signature chain, 유효기간, 서버의 private-key proof
브라우저↔해당 서버 구간의 기밀성·무결성
운영자 정직성, 상품 진위, phishing 여부, 앱 취약점
주소창의 실제 domain 철자와 의도한 조직이 맞는지 확인
기술적 신원·채널 검증과 사람·사업의 신뢰성을 서로 다른 열로 읽는다.
가짜 경품 사이트가 자기 도메인 인증서를 정상 발급받는 경우
주어진 것과 목표 Eve가 prize-login.example을 등록하고 방문자의 비밀번호를 훔치는 페이지를 운영한다. 인증서가 유효할 수 있는지 판단한다.
Eve가 prize-login.example의 DNS와 웹서버를 설정한다.
왜? 자기 소유 도메인이므로 CA의 domain-control challenge에 응답할 수 있다.
중간 결과 CA가 요청한 token을 올바른 경로에 제공한다.
CA가 challenge를 확인하고 prize-login.example과 Eve의 공개키를 묶은 인증서에 서명한다.
왜? CA가 확인한 조건은 도메인 제어권이기 때문이다.
중간 결과 브라우저가 신뢰하는 유효 인증서가 생긴다.
피해자가 정확히 그 도메인에 접속해 비밀번호를 입력한다.
왜? TLS는 피해자와 Eve 서버 사이 전송을 안전하게 만들 뿐 페이지의 목적을 판단하지 않는다.
중간 결과 비밀번호는 도청자에게는 숨겨지지만 사기꾼 Eve에게 안전하게 전달된다.
예제 결론 사기 사이트라는 속성과 유효 TLS 인증서라는 속성은 동시에 성립할 수 있다.
실제 시험으로 옮기기 시험에서는 gültig를 '정직함 인증'으로 확대하지 말고 domain·key binding과 안전한 채널의 범위로 제한해 Wahr를 고른다.
이번 문제는 이 단계로 풀어야 했습니다
먼저 문제에서 직접 주어진 값과 최종적으로 구할 값을 분리합니다. 그다음 각 값·용어·경로를 왜 선택했는지 확인하며, 앞 단계의 중간 결과를 다음 단계의 입력으로 사용합니다.
먼저 문제를 식과 조건으로 정리하기
계산을 시작하기 전에 주어진 것과 구할 것을 분리합니다. 그다음 아래 관계식을 위에서 아래로 사용하면, 숫자가 어디서 왔는지 놓치지 않을 수 있습니다.
강사가 문제의 요구사항을 쉬운 말로 바꾸면
시험 문장이 요구하는 것: 사기성 Webseite도 gültiges TLS-Zertifikat를 가질 수 있다. Wahr/Falsch?
이 문제의 풀이 전략: 이 소문제에서는 gültig의 기술 조건 정의 → 사기성의 대상 분리 → 가능한 반례 적용 → 판정 순서로 진행합니다. 마지막에는 ‘유효 인증서는 도메인·키와 채널을 검증하지만 사이트의 선량함을 인증하지 않는다.’라는 교정 기준으로 답을 다시 확인합니다.
문제에서 주어진 정보
사기성 Webseite도 gültiges TLS-Zertifikat를 가질 수 있다. Wahr/Falsch?
유효 인증서는 접속 도메인이 인증서에 포함되고 신뢰 CA chain·기간 검사가 통과한다는 뜻이다.
자물쇠를 사이트 평판 배지로 해석하지 않았는가?
최종적으로 구해야 하는 것
사기 사이트도 자기 도메인에 대한 valid certificate를 가질 수 있으므로 Wahr다.
정답은 Wahr다. TLS 인증서는 도메인 이름과 공개키의 binding 및 신뢰 CA의 서명을 확인하는 수단이다. 이는 브라우저가 그 도메인의 서버와 보호된 채널을 만드는 데 도움을 주지만, 운영자의 정직성이나 페이지 내용의 안전성을 보장하지 않는다. 공격자도 자신이 통제하는 phishing 도메인에는 정상적인 유효 인증서를 받을 수 있다.
사용할 공식·판정 관계
gültig의 기술 조건 정의 → 사기성의 대상 분리 → 가능한 반례 적용 → 판정
기술적 신원·채널 검증과 사람·사업의 신뢰성을 서로 다른 열로 읽는다.
gültig의 기술 조건 정의
구체적으로 유효 인증서는 접속 도메인이 인증서에 포함되고 신뢰 CA chain·기간 검사가 통과한다는 뜻이다.
여기서 검산 자물쇠를 사이트 평판 배지로 해석하지 않았는가?
다음 단계로 여기서 확인한 내용을 다음 ‘사기성의 대상 분리’ 단계의 출발점으로 사용합니다.
사기성의 대상 분리
구체적으로 betrügerisch는 페이지 내용이나 운영자의 행위를 가리키며 공개키·도메인 binding과 다른 속성이다.
여기서 검산 기술 검증과 도덕적 판단을 분리했는가?
다음 단계로 여기서 확인한 내용을 다음 ‘가능한 반례 적용’ 단계의 출발점으로 사용합니다.
가능한 반례 적용
구체적으로 공격자는 자기 phishing 도메인을 합법적으로 등록하고 그 도메인의 HTTP/DNS challenge를 통과할 수 있다.
여기서 검산 인증서가 반드시 위조되어야 사기가 가능하다고 가정하지 않았는가?
다음 단계로 여기서 확인한 내용을 다음 ‘판정’ 단계의 출발점으로 사용합니다.
판정
구체적으로 사기 사이트도 자기 도메인에 대한 valid certificate를 가질 수 있으므로 Wahr다.
여기서 검산 시험 표에는 Wahr 하나만 표시하는가?
다음 단계로 앞 단계의 결과를 모아 채점 가능한 최종 답안으로 정리합니다.
정답과 해설
정답은 Wahr다. TLS certificate는 보통 해당 domain name에 대한 public key binding과 private key possession을 검증한다. 웹사이트가 사기인지, 상품이 진짜인지, 운영자가 윤리적인지는 인증서만으로 보장되지 않는다.
정답이 이렇게 되는 이유
정답은 Wahr다. TLS 인증서는 도메인 이름과 공개키의 binding 및 신뢰 CA의 서명을 확인하는 수단이다. 이는 브라우저가 그 도메인의 서버와 보호된 채널을 만드는 데 도움을 주지만, 운영자의 정직성이나 페이지 내용의 안전성을 보장하지 않는다. 공격자도 자신이 통제하는 phishing 도메인에는 정상적인 유효 인증서를 받을 수 있다.
초보자가 가장 자주 뒤집는 지점
잘못된 생각 주소창에 자물쇠가 보이면 그 사이트는 진짜 회사이고 안전하다.
왜 틀렸나 자물쇠는 현재 표시된 도메인과의 TLS 연결을 뜻한다. 사용자가 철자가 비슷한 공격자 도메인에 접속했는지는 별도로 확인해야 한다.
고쳐 말하면 유효 인증서는 도메인·키와 채널을 검증하지만 사이트의 선량함을 인증하지 않는다.
한 문제만 더: 개념이 정말 연결됐는지 확인
질문 attacker-bank.example의 소유자가 그 도메인용 유효 인증서를 제시한다. 이것만으로 실제 은행이 운영한다는 사실이 증명되는가?
정답 아니다. 인증서는 attacker-bank.example과 키의 관계를 확인할 뿐 실제 은행과의 조직적 관계를 증명하지 않는다.
이 문제의 오답 함정
이 소문제를 점수로 바꾸는 6개의 작은 훈련
해설을 닫은 상태에서 1번부터 수행하세요. 정답을 읽은 직후보다 직접 문제 지도를 만들고 답을 꺼낸 뒤 채점할 때 기억이 더 정확해집니다. 작성 내용과 복습 판정은 이 브라우저에 자동 저장됩니다.
해설을 보지 말고 주어진 정보 → 구할 것 → 사용할 공식·판정 관계를 한 줄씩 복원하세요.
막힐 때만 첫 단서 열기
인증서가 확인하는 것은 '누구의 키인가'이지 '좋은 사이트인가'가 아니다.
사기성 Webseite도 gültiges TLS-Zertifikat를 가질 수 있다. Wahr/Falsch?
정답 문장만 말하지 말고 근거·중간값·메시지 흐름 중 이 문항에 필요한 것을 빈 종이에 남기세요.
작성한 뒤에만 아래 기준을 열고, 실제로 쓴 항목만 체크하세요.
답안 작성 후 채점 기준 열기
답안 슬롯 자가 점검 — 실제로 말하거나 쓴 항목만 체크하세요.
0/3 slots
조건 변형: 원문의 강한 표현(예: muss, immer, vollständig)을 조건부 표현으로 하나 고쳐 쓰고, 그 변경 뒤에는 판정이 왜 달라지거나 유지되는지 반례와 함께 설명하세요.
고칠 답안: 초록 자물쇠를 사이트 신뢰성 전체로 확대하기
복구 힌트: 인증서가 확인하는 것은 '누구의 키인가'이지 '좋은 사이트인가'가 아니다.
오답의 첫 잘못된 전제를 한 줄로 지우고, 올바른 조건과 결론을 두 줄로 다시 쓰세요.
채점 전 예상과 실제 채점 결과가 달랐는지 확인한 뒤 상태를 남기세요. ‘숙달’은 근거와 중간 과정까지 무힌트로 재현했을 때만 선택합니다.
모든 훈련을 마친 뒤 핵심 정답 다시 확인
정답은 Wahr다. TLS certificate는 보통 해당 domain name에 대한 public key binding과 private key possession을 검증한다. 웹사이트가 사기인지, 상품이 진짜인지, 운영자가 윤리적인지는 인증서만으로 보장되지 않는다.
2.1 c) Autonomous System의 BGP-Nachrichten에는 false information이 들어갈 수 있다. Wahr/Falsch? 기존 71문항 학습 번호 19 · 2점 Wahr/Falsch
2.1 c) · 실제 시험 원문
한국어로 요구사항만 풀어 읽기
Autonomous System의 BGP-Nachrichten에는 false information이 들어갈 수 있다. Wahr/Falsch?
TERMS FOR 2.1 c)
이 소문제의 중요한 용어부터 이해하기
전문 용어를 알고 있다고 가정하지 않습니다. 아래 정의의 굵은 용어를 문제 문장 속 같은 단어와 바꾸어 읽은 뒤 풀이로 넘어가세요.
네트워크에서 header와 payload를 갖고 전달되는 데이터 단위입니다.
IP 계층에서 출발지와 목적지 host/interface를 식별하는 주소입니다.
한 host 안에서 어떤 application/service가 데이터를 받을지 구분하는 번호입니다.
통신 참여자가 message 형식과 순서를 해석하기로 합의한 규칙입니다.
하나의 관리 정책 아래 운영되는 IP network 집합이며 AS 번호로 식별됩니다.
`203.0.113.0/24`처럼 연속된 IP 주소 범위를 나타냅니다.
어떤 prefix로 가는 route와 path 정보를 이웃 AS에 알리는 message입니다.
해당 route가 거쳐 온 AS 번호의 순서로 loop 방지와 route 선택에 사용됩니다.
이 소문제만을 위한 0부터 시작하는 미니 강의
아래 설명은 이 과목의 선행 지식을 가정하지 않습니다. 개념 → 비유의 대응 → 눈으로 읽는 구조 → 작은 예제 순서로 읽은 뒤 실제 시험 풀이로 넘어가세요.
1 · 먼저 알아야 할 개념
인터넷은 하나의 조직이 운영하는 단일 네트워크가 아니라 많은 Autonomous System(AS)의 연결이다. ISP, 대학, 대기업 같은 한 운영 주체가 공통 라우팅 정책으로 관리하는 네트워크 집합에 AS 번호(ASN)가 붙는다.
IP prefix는 주소 범위를 나타낸다. 예를 들어 10.10.10.0/24는 앞 24비트가 같은 주소 256개의 범위를 뜻하며, BGP는 개별 사용자 주소보다 이런 prefix의 도달 가능성을 AS 사이에 광고한다.
BGP announcement 또는 UPDATE는 '이 prefix로 가는 경로를 내가 알고 있다'는 reachability 정보와 AS_PATH 같은 path attributes를 이웃 AS에 보낸다. AS_PATH에는 광고가 지나온 AS들이 들어가 loop 방지와 경로 선택에 쓰인다.
기본 BGP는 이웃이 광고한 prefix의 소유 권한이나 전체 경로의 진실성을 자동으로 완전 검증하지 않는다. 오설정, route leak, 고의적인 prefix hijacking 때문에 문법상 정상인 메시지 안에 거짓 정보가 들어갈 수 있다.
2 · 일상 장면으로 먼저 잡기
도시 간 도로 안내 방송에서 한 도시가 '박물관으로 가는 길은 나를 통과하면 된다'고 이웃 도시에 알리는 장면
비유의 경계 실제 BGP 경로 선택은 단순 최단 도시 수만 보지 않고 local preference, 사업 관계, MED 등 정책을 함께 사용한다.
권한 없는 prefix와 짧아 보이는 AS_PATH 광고
이웃에게서 받은 후보 route 저장
정책과 attributes로 한 경로 선택
피해 prefix 트래픽이 AS50으로 이동
메시지 수신, 후보 저장, 경로 선택, 실제 forwarding의 네 상태를 순서대로 본다.
AS50이 AS10의 연구소 prefix를 자기 것처럼 광고하는 경우
주어진 것과 목표 정상 소유자 AS10은 203.0.113.0/24를 광고한다. 권한 없는 AS50도 같은 prefix를 이웃 AS30에 광고한다.
AS50이
prefix=203.0.113.0/24, AS_PATH=AS50인 UPDATE를 AS30에 보낸다.왜? AS30이 자신을 그 prefix의 origin으로 믿게 만들기 위해서다.
중간 결과 AS30의 RIB-In에 문법상 사용할 수 있는 후보 경로가 들어온다.
AS30이 정상 경로와 AS50 경로를 정책에 따라 비교한다.
왜? BGP는 여러 후보 중 best path를 선택해야 한다.
중간 결과 추가 검증이 없고 AS50 경로가 선호되면 트래픽이 AS50으로 향한다.
운영자가 ROA를 확인한다.
왜? 해당 prefix를 origin할 권한이 어느 ASN에 있는지 검증하기 위해서다.
중간 결과 ROA가 AS10만 허용한다면 AS50 광고는 RPKI-invalid로 판정할 수 있다.
예제 결론 BGP 메시지 형식이 올바르다는 사실은 그 안의 prefix 권한과 경로 주장이 참이라는 보장이 아니다.
실제 시험으로 옮기기 시험 문장은 'können'이라고 가능성을 묻는다. prefix hijacking 한 사례만으로 거짓 정보가 포함될 수 있으므로 Wahr다.
이번 문제는 이 단계로 풀어야 했습니다
먼저 문제에서 직접 주어진 값과 최종적으로 구할 값을 분리합니다. 그다음 각 값·용어·경로를 왜 선택했는지 확인하며, 앞 단계의 중간 결과를 다음 단계의 입력으로 사용합니다.
먼저 문제를 식과 조건으로 정리하기
계산을 시작하기 전에 주어진 것과 구할 것을 분리합니다. 그다음 아래 관계식을 위에서 아래로 사용하면, 숫자가 어디서 왔는지 놓치지 않을 수 있습니다.
강사가 문제의 요구사항을 쉬운 말로 바꾸면
시험 문장이 요구하는 것: Autonomous System의 BGP-Nachrichten에는 false information이 들어갈 수 있다. Wahr/Falsch?
이 문제의 풀이 전략: 이 소문제에서는 메시지 내용 회상 → 검증 범위 확인 → 구체 반례 → 판정 순서로 진행합니다. 마지막에는 ‘기본 BGP UPDATE는 reachability 주장이고, 별도 검증 없이는 그 주장이 항상 참이라고 보장되지 않는다.’라는 교정 기준으로 답을 다시 확인합니다.
문제에서 주어진 정보
Autonomous System의 BGP-Nachrichten에는 false information이 들어갈 수 있다. Wahr/Falsch?
BGP announcement는 최소한 destination IP prefix와 AS_PATH/origin 정보를 전달한다.
DNS 주소 응답과 혼동하지 않았는가?
최종적으로 구해야 하는 것
오설정 또는 공격으로 false prefix/origin/path 정보가 포함될 수 있으므로 Wahr다.
정답은 Wahr다. BGP announcement는 prefix reachability와 AS_PATH 같은 경로 정보를 이웃 AS에 전달한다. 기본 BGP는 그 AS가 prefix를 광고할 권한과 모든 path 요소의 진실성을 완전하게 검증하지 않는다. 따라서 오설정, route leak, prefix hijacking으로 잘못된 정보가 들어갈 수 있다.
사용할 공식·판정 관계
메시지 내용 회상 → 검증 범위 확인 → 구체 반례 → 판정
메시지 수신, 후보 저장, 경로 선택, 실제 forwarding의 네 상태를 순서대로 본다.
메시지 내용 회상
구체적으로 BGP announcement는 최소한 destination IP prefix와 AS_PATH/origin 정보를 전달한다.
여기서 검산 DNS 주소 응답과 혼동하지 않았는가?
다음 단계로 여기서 확인한 내용을 다음 ‘검증 범위 확인’ 단계의 출발점으로 사용합니다.
검증 범위 확인
구체적으로 기본 BGP만으로는 광고한 AS가 그 prefix를 실제로 origin할 권한이 있는지 완전히 인증하지 않는다.
여기서 검산 모든 UPDATE가 자동으로 신뢰 CA 서명을 받는다고 가정하지 않았는가?
다음 단계로 여기서 확인한 내용을 다음 ‘구체 반례’ 단계의 출발점으로 사용합니다.
구체 반례
구체적으로 권한 없는 AS666이 다른 AS의 prefix를 자기 origin처럼 광고하는 prefix hijacking이 가능하다.
여기서 검산 거짓 정보가 들어갈 수 있다는 실제 경로를 제시했는가?
다음 단계로 여기서 확인한 내용을 다음 ‘판정’ 단계의 출발점으로 사용합니다.
판정
구체적으로 오설정 또는 공격으로 false prefix/origin/path 정보가 포함될 수 있으므로 Wahr다.
여기서 검산 können이라는 가능 명제를 정확히 읽었는가?
다음 단계로 앞 단계의 결과를 모아 채점 가능한 최종 답안으로 정리합니다.
정답과 해설
정답은 Wahr다. 기본 BGP는 어떤 AS가 prefix reachability 또는 AS_PATH를 광고할 때 그 정보가 항상 참인지 강하게 검증하지 않는다. 그래서 prefix hijack, sub-prefix hijack, AS_PATH manipulation 같은 공격이 가능하다.
정답이 이렇게 되는 이유
정답은 Wahr다. BGP announcement는 prefix reachability와 AS_PATH 같은 경로 정보를 이웃 AS에 전달한다. 기본 BGP는 그 AS가 prefix를 광고할 권한과 모든 path 요소의 진실성을 완전하게 검증하지 않는다. 따라서 오설정, route leak, prefix hijacking으로 잘못된 정보가 들어갈 수 있다.
초보자가 가장 자주 뒤집는 지점
잘못된 생각 BGP는 인터넷 핵심 프로토콜이므로 모든 announcement가 인증되어 참이다.
왜 틀렸나 프로토콜 문법 검사와 내용의 권한 검증은 다르다. 추가적인 RPKI/ROV나 filtering이 없으면 거짓 origin 광고가 퍼질 수 있다.
고쳐 말하면 기본 BGP UPDATE는 reachability 주장이고, 별도 검증 없이는 그 주장이 항상 참이라고 보장되지 않는다.
한 문제만 더: 개념이 정말 연결됐는지 확인
질문 ROA가 203.0.113.0/24의 origin으로 AS10만 허용하는데 AS50이 같은 /24를 origin하면 ROV 결과는 무엇인가?
정답 RPKI-invalid다. ROA가 존재하지만 origin ASN이 허가된 AS10과 다르다.
이 문제의 오답 함정
이 소문제를 점수로 바꾸는 6개의 작은 훈련
해설을 닫은 상태에서 1번부터 수행하세요. 정답을 읽은 직후보다 직접 문제 지도를 만들고 답을 꺼낸 뒤 채점할 때 기억이 더 정확해집니다. 작성 내용과 복습 판정은 이 브라우저에 자동 저장됩니다.
해설을 보지 말고 주어진 정보 → 구할 것 → 사용할 공식·판정 관계를 한 줄씩 복원하세요.
막힐 때만 첫 단서 열기
BGP hijack 문제에서 공격자는 거짓으로 무엇을 announce하는가?
Autonomous System의 BGP-Nachrichten에는 false information이 들어갈 수 있다. Wahr/Falsch?
정답 문장만 말하지 말고 근거·중간값·메시지 흐름 중 이 문항에 필요한 것을 빈 종이에 남기세요.
작성한 뒤에만 아래 기준을 열고, 실제로 쓴 항목만 체크하세요.
답안 작성 후 채점 기준 열기
답안 슬롯 자가 점검 — 실제로 말하거나 쓴 항목만 체크하세요.
0/3 slots
조건 변형: 원문의 강한 표현(예: muss, immer, vollständig)을 조건부 표현으로 하나 고쳐 쓰고, 그 변경 뒤에는 판정이 왜 달라지거나 유지되는지 반례와 함께 설명하세요.
고칠 답안: BGP 메시지가 모두 인증된다고 가정하기
복구 힌트: BGP hijack 문제에서 공격자는 거짓으로 무엇을 announce하는가?
오답의 첫 잘못된 전제를 한 줄로 지우고, 올바른 조건과 결론을 두 줄로 다시 쓰세요.
채점 전 예상과 실제 채점 결과가 달랐는지 확인한 뒤 상태를 남기세요. ‘숙달’은 근거와 중간 과정까지 무힌트로 재현했을 때만 선택합니다.
모든 훈련을 마친 뒤 핵심 정답 다시 확인
정답은 Wahr다. 기본 BGP는 어떤 AS가 prefix reachability 또는 AS_PATH를 광고할 때 그 정보가 항상 참인지 강하게 검증하지 않는다. 그래서 prefix hijack, sub-prefix hijack, AS_PATH manipulation 같은 공격이 가능하다.
2.1 d) DNS over HTTPS(DoH)는 Resolver에 대한 DNS-Cache-Poisoning-Angriff를 막는다. Wahr/Falsch? 기존 71문항 학습 번호 20 · 2점 Wahr/Falsch
2.1 d) · 실제 시험 원문
한국어로 요구사항만 풀어 읽기
DNS over HTTPS(DoH)는 Resolver에 대한 DNS-Cache-Poisoning-Angriff를 막는다. Wahr/Falsch?
TERMS FOR 2.1 d)
이 소문제의 중요한 용어부터 이해하기
전문 용어를 알고 있다고 가정하지 않습니다. 아래 정의의 굵은 용어를 문제 문장 속 같은 단어와 바꾸어 읽은 뒤 풀이로 넘어가세요.
Browser와 server 사이 전송 내용을 암호화하고 변조를 탐지하며 보통 server를 인증하는 통신 보호입니다.
작은 예: HTTPS는 네트워크 도청을 줄이지만 URL이 browser history나 server log에 남는 문제까지 없애지는 않습니다.
domain 이름을 IP 주소 등 resource record로 찾아주는 분산 이름 시스템입니다.
client 대신 여러 DNS server에 질의해 최종 답을 찾아주는 server입니다.
이전에 받은 DNS 답을 일정 시간 저장해 재사용하는 공간입니다.
DNS record를 cache에서 얼마나 오래 재사용할 수 있는지 나타내는 시간값입니다.
DNS over HTTPS로 client와 resolver 사이 DNS message를 HTTPS 안에 암호화합니다.
DNS record에 대한 signature chain으로 data origin과 integrity를 검증하는 확장입니다.
받은 정보가 주장된 권한 있는 출처에서 왔는지를 확인하는 성질입니다.
이 소문제만을 위한 0부터 시작하는 미니 강의
아래 설명은 이 과목의 선행 지식을 가정하지 않습니다. 개념 → 비유의 대응 → 눈으로 읽는 구조 → 작은 예제 순서로 읽은 뒤 실제 시험 풀이로 넘어가세요.
1 · 먼저 알아야 할 개념
사용자 기기의 stub resolver는 보통 recursive resolver에게 도메인 이름의 IP를 찾아 달라고 요청한다. Recursive resolver는 root, TLD, authoritative nameserver에 질의하고 얻은 결과를 사용자에게 돌려준다.
Resolver는 같은 질문을 반복하지 않도록 Resource Record를 TTL 동안 cache한다. Cache poisoning은 공격자가 위조 DNS 답을 resolver가 진짜로 받아들이게 하여, 예를 들어 bank.example을 공격자 IP로 저장하게 만드는 공격이다.
DoH(DNS over HTTPS)는 주로 client와 선택한 DoH resolver 사이의 DNS 질의·응답을 HTTPS/TLS 안에 넣는다. 이 구간의 도청과 on-path 변조를 어렵게 하지만, TLS endpoint인 resolver는 질의 내용을 보고 답을 만든다.
DNSSEC는 zone owner가 DNS data에 서명하고 validating resolver가 신뢰 chain을 검사하게 한다. 즉 DoH는 전송 통로 보호, DNSSEC는 DNS record의 출처·무결성 검증이라는 서로 다른 질문에 답한다.
2 · 일상 장면으로 먼저 잡기
잠긴 배송차가 서류를 사무실까지 운반하고, 사무실은 서류의 관공서 도장을 따로 확인하는 장면
비유의 경계 DoH의 TLS는 실제로 endpoint 인증과 기밀성·무결성을 제공하지만, 그 endpoint가 보유한 DNS 데이터의 진실성까지 자동 보증하지는 않는다.
DoH: query/response 전송의 기밀성·무결성
DoH만으로 저장 데이터의 진실성 보장 안 됨
DNSSEC: 서명 chain으로 origin·integrity 검사
Upstream 위조 응답이 cache에 유입될 수 있는 지점; DoH의 직접 보호 밖
화살표의 어느 구간을 보호하는지와 저장된 데이터가 누구에게 서명됐는지를 분리해서 읽는다.
안전한 DoH 채널로 오염된 답을 받는 경우
주어진 것과 목표 Laptop L은 Resolver R과 DoH를 사용한다. 공격자가 이전에 R의 cache에 shop.example→203.0.113.66이라는 거짓 A record를 넣었다.
L이 HTTPS로 암호화된 DoH query
shop.example A?를 R에 보낸다.왜? 로컬 Wi-Fi가 query를 읽거나 바꾸지 못하게 하기 위해서다.
중간 결과 L↔R 전송 구간은 TLS로 보호된다.
R이 cache를 검사해 오염된 203.0.113.66을 찾는다.
왜? 유효 TTL의 cache hit이면 upstream nameserver에 다시 묻지 않기 때문이다.
중간 결과 R의 내부 상태에는 여전히 거짓 값이 선택된다.
R이 그 값을 DoH response로 L에 돌려준다.
왜? DoH는 R이 만든 payload를 안전하게 전달하는 역할이기 때문이다.
중간 결과 거짓 DNS 답이 변조 없이 안전하게 L에 도착한다.
서명된 zone에서 R이 DNSSEC validation을 수행했다고 가정해 비교한다.
왜? record의 출처를 검증하는 별도 메커니즘을 보기 위해서다.
중간 결과 위조 답은 유효한 RRSIG를 만들지 못해 거부될 수 있다.
예제 결론 DoH만으로 resolver cache의 내용이 참이라고 보장할 수 없으며 DNSSEC validation과 resolver 보안이 별도로 필요하다.
실제 시험으로 옮기기 문장의 공격 지점은 'auf den Resolver'다. client↔resolver 통로 보호를 resolver cache 자체의 만능 보호로 확대했으므로 Falsch다.
이번 문제는 이 단계로 풀어야 했습니다
먼저 문제에서 직접 주어진 값과 최종적으로 구할 값을 분리합니다. 그다음 각 값·용어·경로를 왜 선택했는지 확인하며, 앞 단계의 중간 결과를 다음 단계의 입력으로 사용합니다.
먼저 문제를 식과 조건으로 정리하기
계산을 시작하기 전에 주어진 것과 구할 것을 분리합니다. 그다음 아래 관계식을 위에서 아래로 사용하면, 숫자가 어디서 왔는지 놓치지 않을 수 있습니다.
강사가 문제의 요구사항을 쉬운 말로 바꾸면
시험 문장이 요구하는 것: DNS over HTTPS(DoH)는 Resolver에 대한 DNS-Cache-Poisoning-Angriff를 막는다. Wahr/Falsch?
이 문제의 풀이 전략: 이 소문제에서는 DoH endpoint 표시 → 공격 대상 표시 → 보호 성질 비교 → 맞는 방어 연결 → 판정 순서로 진행합니다. 마지막에는 ‘DoH는 client-resolver 전송 보호이고 DNSSEC는 DNS 데이터 출처 검증이다.’라는 교정 기준으로 답을 다시 확인합니다.
문제에서 주어진 정보
DNS over HTTPS(DoH)는 Resolver에 대한 DNS-Cache-Poisoning-Angriff를 막는다. Wahr/Falsch?
DoH가 직접 보호하는 양 끝은 DNS client와 DoH recursive resolver다.
authoritative server까지 모든 DNS 구간이 자동으로 DoH라고 그리지 않았는가?
최종적으로 구해야 하는 것
DoH가 resolver cache poisoning을 일반적으로 막는다는 명제는 과도하므로 Falsch다.
정답은 Falsch다. DoH는 DNS client와 DoH resolver 사이의 transport를 HTTPS로 보호하여 그 구간의 도청·변조를 줄인다. 그러나 resolver가 upstream에서 받은 거짓 데이터를 cache하는 공격이나 resolver 자체의 compromise를 자동으로 막지 않는다. DNS record의 origin authenticity와 integrity 검증에는 DNSSEC가 더 직접적인 방어다.
사용할 공식·판정 관계
DoH endpoint 표시 → 공격 대상 표시 → 보호 성질 비교 → 맞는 방어 연결 → 판정
화살표의 어느 구간을 보호하는지와 저장된 데이터가 누구에게 서명됐는지를 분리해서 읽는다.
DoH endpoint 표시
구체적으로 DoH가 직접 보호하는 양 끝은 DNS client와 DoH recursive resolver다.
여기서 검산 authoritative server까지 모든 DNS 구간이 자동으로 DoH라고 그리지 않았는가?
다음 단계로 여기서 확인한 내용을 다음 ‘공격 대상 표시’ 단계의 출발점으로 사용합니다.
공격 대상 표시
구체적으로 문장의 cache poisoning 대상은 resolver가 TTL 동안 저장하고 재사용하는 DNS record다.
여기서 검산 client의 로컬 packet 변조와 resolver cache 오염을 구분했는가?
다음 단계로 여기서 확인한 내용을 다음 ‘보호 성질 비교’ 단계의 출발점으로 사용합니다.
보호 성질 비교
구체적으로 TLS transport가 안전해도 resolver가 이미 믿은 거짓 answer를 그대로 암호화해 보낼 수 있다.
여기서 검산 암호화된 데이터와 진짜 데이터를 같은 뜻으로 쓰지 않았는가?
다음 단계로 여기서 확인한 내용을 다음 ‘맞는 방어 연결’ 단계의 출발점으로 사용합니다.
맞는 방어 연결
구체적으로 서명된 zone의 위조 record 검증에는 DNSSEC-validating resolver가 더 직접적이다.
여기서 검산 DNSSEC가 기밀성을 제공한다고 잘못 쓰지 않았는가?
다음 단계로 여기서 확인한 내용을 다음 ‘판정’ 단계의 출발점으로 사용합니다.
판정
구체적으로 DoH가 resolver cache poisoning을 일반적으로 막는다는 명제는 과도하므로 Falsch다.
여기서 검산 DoH의 로컬 구간 보호 효과까지 없다고 과장하지 않았는가?
다음 단계로 앞 단계의 결과를 모아 채점 가능한 최종 답안으로 정리합니다.
정답과 해설
정답은 Falsch로 학습한다. DoH는 client와 resolver 사이 DNS 질의를 HTTPS로 보호해 도청/변조를 줄인다. 그러나 resolver 자체가 권한 DNS 응답을 받아 cache에 저장하는 과정의 poisoning을 자동으로 막지는 않는다. DNS 데이터의 출처 인증에는 DNSSEC가 더 직접적이다.
정답이 이렇게 되는 이유
정답은 Falsch다. DoH는 DNS client와 DoH resolver 사이의 transport를 HTTPS로 보호하여 그 구간의 도청·변조를 줄인다. 그러나 resolver가 upstream에서 받은 거짓 데이터를 cache하는 공격이나 resolver 자체의 compromise를 자동으로 막지 않는다. DNS record의 origin authenticity와 integrity 검증에는 DNSSEC가 더 직접적인 방어다.
초보자가 가장 자주 뒤집는 지점
잘못된 생각 HTTPS라는 이름이 있으므로 DNS 답의 내용도 항상 공식 authoritative data다.
왜 틀렸나 TLS는 선택한 resolver가 보낸 bytes를 보호한다. Resolver가 가진 내용이 이미 거짓이면 그 거짓도 안전한 채널로 전달된다.
고쳐 말하면 DoH는 client-resolver 전송 보호이고 DNSSEC는 DNS 데이터 출처 검증이다.
한 문제만 더: 개념이 정말 연결됐는지 확인
질문 카페 Wi-Fi가 노트북과 resolver 사이 평문 DNS response를 바꾸려는 공격과, resolver cache가 upstream 위조 응답으로 오염되는 공격 중 DoH가 직접 막는 쪽은?
정답 첫 번째다. DoH는 노트북↔resolver TLS 구간의 on-path 변조를 막지만 resolver cache 오염 전체를 해결하지 않는다.
이 문제의 오답 함정
이 소문제를 점수로 바꾸는 6개의 작은 훈련
해설을 닫은 상태에서 1번부터 수행하세요. 정답을 읽은 직후보다 직접 문제 지도를 만들고 답을 꺼낸 뒤 채점할 때 기억이 더 정확해집니다. 작성 내용과 복습 판정은 이 브라우저에 자동 저장됩니다.
해설을 보지 말고 주어진 정보 → 구할 것 → 사용할 공식·판정 관계를 한 줄씩 복원하세요.
막힐 때만 첫 단서 열기
DoH가 암호화하는 구간은 어디에서 어디까지인가?
DNS over HTTPS(DoH)는 Resolver에 대한 DNS-Cache-Poisoning-Angriff를 막는다. Wahr/Falsch?
정답 문장만 말하지 말고 근거·중간값·메시지 흐름 중 이 문항에 필요한 것을 빈 종이에 남기세요.
작성한 뒤에만 아래 기준을 열고, 실제로 쓴 항목만 체크하세요.
답안 작성 후 채점 기준 열기
답안 슬롯 자가 점검 — 실제로 말하거나 쓴 항목만 체크하세요.
0/3 slots
조건 변형: 원문의 강한 표현(예: muss, immer, vollständig)을 조건부 표현으로 하나 고쳐 쓰고, 그 변경 뒤에는 판정이 왜 달라지거나 유지되는지 반례와 함께 설명하세요.
고칠 답안: HTTPS라는 이름만 보고 DNS 데이터 전체가 인증된다고 생각하기
복구 힌트: DoH가 암호화하는 구간은 어디에서 어디까지인가?
오답의 첫 잘못된 전제를 한 줄로 지우고, 올바른 조건과 결론을 두 줄로 다시 쓰세요.
채점 전 예상과 실제 채점 결과가 달랐는지 확인한 뒤 상태를 남기세요. ‘숙달’은 근거와 중간 과정까지 무힌트로 재현했을 때만 선택합니다.
모든 훈련을 마친 뒤 핵심 정답 다시 확인
정답은 Falsch로 학습한다. DoH는 client와 resolver 사이 DNS 질의를 HTTPS로 보호해 도청/변조를 줄인다. 그러나 resolver 자체가 권한 DNS 응답을 받아 cache에 저장하는 과정의 poisoning을 자동으로 막지는 않는다. DNS 데이터의 출처 인증에는 DNSSEC가 더 직접적이다.
2.1 e) Firewall가 outgoing ports 중 Port 53만 허용하면 DNS-Anfragen만 통과하므로 data exfiltration은 불가능하다. Wahr/Falsch? 기존 71문항 학습 번호 21 · 2점 Wahr/Falsch
2.1 e) · 실제 시험 원문
한국어로 요구사항만 풀어 읽기
Firewall가 outgoing ports 중 Port 53만 허용하면 DNS-Anfragen만 통과하므로 data exfiltration은 불가능하다. Wahr/Falsch?
TERMS FOR 2.1 e)
이 소문제의 중요한 용어부터 이해하기
전문 용어를 알고 있다고 가정하지 않습니다. 아래 정의의 굵은 용어를 문제 문장 속 같은 단어와 바꾸어 읽은 뒤 풀이로 넘어가세요.
네트워크에서 header와 payload를 갖고 전달되는 데이터 단위입니다.
IP 계층에서 출발지와 목적지 host/interface를 식별하는 주소입니다.
한 host 안에서 어떤 application/service가 데이터를 받을지 구분하는 번호입니다.
통신 참여자가 message 형식과 순서를 해석하기로 합의한 규칙입니다.
domain 이름을 IP 주소 등 resource record로 찾아주는 분산 이름 시스템입니다.
client 대신 여러 DNS server에 질의해 최종 답을 찾아주는 server입니다.
이전에 받은 DNS 답을 일정 시간 저장해 재사용하는 공간입니다.
DNS record를 cache에서 얼마나 오래 재사용할 수 있는지 나타내는 시간값입니다.
이 소문제만을 위한 0부터 시작하는 미니 강의
아래 설명은 이 과목의 선행 지식을 가정하지 않습니다. 개념 → 비유의 대응 → 눈으로 읽는 구조 → 작은 예제 순서로 읽은 뒤 실제 시험 풀이로 넘어가세요.
1 · 먼저 알아야 할 개념
IP address가 네트워크 장비의 주소라면 TCP/UDP port는 그 장비 안에서 어느 애플리케이션이 통신을 받을지 구분하는 번호다. DNS는 일반적으로 UDP 53을 쓰고 큰 응답이나 일부 작업에는 TCP 53도 쓴다.
단순 firewall은 source·destination IP, protocol, port 같은 header를 보고 트래픽을 허용하거나 막는다. Destination port가 53이라는 사실은 payload가 DNS 형식을 띤다는 단서일 뿐, 그 DNS 사용 목적이 정상이라는 보증은 아니다.
DNS query의 QNAME에는 사용자가 정한 여러 label이 들어갈 수 있다. Malware는 훔친 bytes를 Base32나 hex로 바꾸고
조각.공격자도메인형태의 subdomain에 넣어 정상 DNS query처럼 외부로 보낼 수 있다.공격자가 자신의 domain과 authoritative nameserver를 통제하면 최종 query가 그 서버에 도착할 때 subdomain label을 log로 읽고 원본 데이터를 복원할 수 있다. 이를 DNS exfiltration이라고 하며, response에도 명령을 넣으면 DNS tunneling 기반 command-and-control이 될 수 있다.
2 · 일상 장면으로 먼저 잡기
검문소가 '서류 봉투'만 통과시키지만 밀수꾼이 비밀 문장을 서류의 수신인 이름 칸에 잘라 적어 보내는 장면
비유의 경계 실제 DNS 형식에는 label 길이와 전체 이름 길이 제한이 있고 전송량도 낮다. 그러나 작은 조각을 여러 query로 보내면 유출 통로로는 충분할 수 있다.
비밀을
chunk.evil.example로 encoding형식상 DNS query를 정상 재귀 전달
QNAME label을 수신·기록
Port 53만 보고 허용하면 의미를 놓침
Packet의 port가 아니라 payload가 어느 최종 수신자에게 어떤 정보를 전달하는지 화살표 끝까지 추적한다.
직원 번호 7351을 DNS 이름으로 빼내기
주어진 것과 목표 감염 PC H는 외부 TCP/UDP 연결이 차단되어 있지만 조직 resolver R로 가는 DNS만 허용된다. Eve는 evil.example의 authoritative server A를 운영한다.
H가
7351을 hex 또는 Base32 문자열로 만들고01-37333531.evil.example을 질의한다.왜? DNS가 허용하는 문자로 데이터를 qname label 안에 운반하기 위해서다.
중간 결과 H→R에 destination port 53인 정상 형태의 query가 생긴다.
R이 cache miss 후 evil.example의 authoritative server A까지 재귀 조회를 수행한다.
왜? R은 임의 subdomain의 정답을 얻으려면 해당 zone의 공식 server에 물어야 한다.
중간 결과 R→A query에 인코딩된 label
01-37333531이 그대로 포함된다.A가 query log에서 label을 저장하고 Eve가 decode한다.
왜? A는 TLS가 없어도 자신에게 온 DNS 이름 전체를 볼 수 있고 공격자는 순서 번호로 조각을 합칠 수 있다.
중간 결과 Eve가 원래 직원 번호 7351을 복원한다.
Firewall 판정을 다시 확인한다.
왜? 모든 packet이 port 53이었는데도 정보가 외부 서버까지 갔는지 검산하기 위해서다.
중간 결과 Port 제한만으로 data exfiltration 불가능이라는 결론이 깨진다.
예제 결론 정상 프로토콜의 필드도 비밀 데이터를 운반할 수 있으므로 port 53만 열었다고 유출이 불가능해지지 않는다.
실제 시험으로 옮기기 시험 문장에서 'nur DNS-Anfragen'과 'deshalb keine Daten' 사이의 잘못된 추론을 DNS tunneling 반례로 끊고 Falsch를 고른다.
이번 문제는 이 단계로 풀어야 했습니다
먼저 문제에서 직접 주어진 값과 최종적으로 구할 값을 분리합니다. 그다음 각 값·용어·경로를 왜 선택했는지 확인하며, 앞 단계의 중간 결과를 다음 단계의 입력으로 사용합니다.
먼저 문제를 식과 조건으로 정리하기
계산을 시작하기 전에 주어진 것과 구할 것을 분리합니다. 그다음 아래 관계식을 위에서 아래로 사용하면, 숫자가 어디서 왔는지 놓치지 않을 수 있습니다.
강사가 문제의 요구사항을 쉬운 말로 바꾸면
시험 문장이 요구하는 것: Firewall가 outgoing ports 중 Port 53만 허용하면 DNS-Anfragen만 통과하므로 data exfiltration은 불가능하다. Wahr/Falsch?
이 문제의 풀이 전략: 이 소문제에서는 Port의 의미 제한 → 데이터 삽입 위치 → Sender와 receiver 추적 → 유출 성립 확인 → 판정 순서로 진행합니다. 마지막에는 ‘Port 53 허용은 DNS 형식의 통로를 열며, 그 안의 covert data를 막으려면 중앙 resolver, logging, payload 분석과 endpoint 방어가 추가로 필요하다.’라는 교정 기준으로 답을 다시 확인합니다.
문제에서 주어진 정보
Firewall가 outgoing ports 중 Port 53만 허용하면 DNS-Anfragen만 통과하므로 data exfiltration은 불가능하다. Wahr/Falsch?
Port 53은 DNS 애플리케이션을 식별하는 관례이지 payload가 이름 해석에만 사용된다는 보증이 아니다.
port 번호와 데이터 의미를 같은 것으로 취급하지 않았는가?
최종적으로 구해야 하는 것
DNS tunneling/exfiltration이라는 반례가 있으므로 문장은 Falsch다.
정답은 Falsch다. Firewall이 port 53만 허용해도 DNS query 자체가 임의 데이터를 운반할 수 있다. Malware는 탈취 데이터를 subdomain label에 인코딩하고, recursive resolver를 거쳐 공격자가 통제하는 authoritative nameserver로 보내 복원할 수 있다. 따라서 port 기반 egress filtering만으로 data exfiltration을 배제할 수 없다.
사용할 공식·판정 관계
Port의 의미 제한 → 데이터 삽입 위치 → Sender와 receiver 추적 → 유출 성립 확인 → 판정
Packet의 port가 아니라 payload가 어느 최종 수신자에게 어떤 정보를 전달하는지 화살표 끝까지 추적한다.
Port의 의미 제한
구체적으로 Port 53은 DNS 애플리케이션을 식별하는 관례이지 payload가 이름 해석에만 사용된다는 보증이 아니다.
여기서 검산 port 번호와 데이터 의미를 같은 것으로 취급하지 않았는가?
다음 단계로 여기서 확인한 내용을 다음 ‘데이터 삽입 위치’ 단계의 출발점으로 사용합니다.
데이터 삽입 위치
구체적으로 Malware는 탈취 정보를
encoded-data.attacker.example의 subdomain label에 넣을 수 있다.여기서 검산 구체적으로 어느 DNS field에 값이 실리는지 썼는가?
다음 단계로 여기서 확인한 내용을 다음 ‘Sender와 receiver 추적’ 단계의 출발점으로 사용합니다.
Sender와 receiver 추적
구체적으로 감염 host가 resolver에 보내고, resolver는 공격자 authoritative server까지 같은 QNAME을 전달한다.
여기서 검산 공격자가 왜 자기 authoritative zone을 필요로 하는지 설명했는가?
다음 단계로 여기서 확인한 내용을 다음 ‘유출 성립 확인’ 단계의 출발점으로 사용합니다.
유출 성립 확인
구체적으로 공격자 server는 query log의 label을 모아 decode하므로 외부 일반 port가 막혀도 데이터가 나간다.
여기서 검산 단순 encoding을 encryption이라고 부르지 않았는가?
다음 단계로 여기서 확인한 내용을 다음 ‘판정’ 단계의 출발점으로 사용합니다.
판정
구체적으로 DNS tunneling/exfiltration이라는 반례가 있으므로 문장은 Falsch다.
여기서 검산 DNS traffic 자체에 데이터가 없다는 전제를 제거했는가?
다음 단계로 앞 단계의 결과를 모아 채점 가능한 최종 답안으로 정리합니다.
정답과 해설
정답은 Falsch다. Port 53을 열면 DNS처럼 보이는 traffic이 지나갈 수 있지만, 공격자는 query name이나 TXT record 같은 DNS payload에 데이터를 인코딩할 수 있다. port만 보는 firewall은 protocol semantics와 payload 목적을 충분히 검증하지 못한다.
정답이 이렇게 되는 이유
정답은 Falsch다. Firewall이 port 53만 허용해도 DNS query 자체가 임의 데이터를 운반할 수 있다. Malware는 탈취 데이터를 subdomain label에 인코딩하고, recursive resolver를 거쳐 공격자가 통제하는 authoritative nameserver로 보내 복원할 수 있다. 따라서 port 기반 egress filtering만으로 data exfiltration을 배제할 수 없다.
초보자가 가장 자주 뒤집는 지점
잘못된 생각 Port 53이면 운영체제가 오직 도메인 이름만 보내도록 강제하므로 다른 데이터는 못 나간다.
왜 틀렸나 도메인 이름의 label도 공격자가 선택하는 bytes를 표현할 수 있고, firewall이 그 의미를 검사하지 않을 수 있다.
고쳐 말하면 Port 53 허용은 DNS 형식의 통로를 열며, 그 안의 covert data를 막으려면 중앙 resolver, logging, payload 분석과 endpoint 방어가 추가로 필요하다.
한 문제만 더: 개념이 정말 연결됐는지 확인
질문 외부 host의 port 53 직접 접근을 막고 내부 resolver만 허용하면
secret.attacker.example유출이 완전히 사라지는가?정답 반드시 그렇지 않다. 내부 resolver가 attacker.example의 authoritative server로 재귀 query를 전달할 수 있으므로 비정상 QNAME 탐지와 domain 정책도 필요하다.
이 문제의 오답 함정
이 소문제를 점수로 바꾸는 6개의 작은 훈련
해설을 닫은 상태에서 1번부터 수행하세요. 정답을 읽은 직후보다 직접 문제 지도를 만들고 답을 꺼낸 뒤 채점할 때 기억이 더 정확해집니다. 작성 내용과 복습 판정은 이 브라우저에 자동 저장됩니다.
해설을 보지 말고 주어진 정보 → 구할 것 → 사용할 공식·판정 관계를 한 줄씩 복원하세요.
막힐 때만 첫 단서 열기
Firewall가 보는 것이 port number뿐이면, payload 안의 의미까지 알 수 있을까?
Firewall가 outgoing ports 중 Port 53만 허용하면 DNS-Anfragen만 통과하므로 data exfiltration은 불가능하다. Wahr/Falsch?
정답 문장만 말하지 말고 근거·중간값·메시지 흐름 중 이 문항에 필요한 것을 빈 종이에 남기세요.
작성한 뒤에만 아래 기준을 열고, 실제로 쓴 항목만 체크하세요.
답안 작성 후 채점 기준 열기
답안 슬롯 자가 점검 — 실제로 말하거나 쓴 항목만 체크하세요.
0/3 slots
조건 변형: 원문의 강한 표현(예: muss, immer, vollständig)을 조건부 표현으로 하나 고쳐 쓰고, 그 변경 뒤에는 판정이 왜 달라지거나 유지되는지 반례와 함께 설명하세요.
고칠 답안: Port 53 traffic은 항상 정상 DNS라고 가정하기
복구 힌트: Firewall가 보는 것이 port number뿐이면, payload 안의 의미까지 알 수 있을까?
오답의 첫 잘못된 전제를 한 줄로 지우고, 올바른 조건과 결론을 두 줄로 다시 쓰세요.
채점 전 예상과 실제 채점 결과가 달랐는지 확인한 뒤 상태를 남기세요. ‘숙달’은 근거와 중간 과정까지 무힌트로 재현했을 때만 선택합니다.
모든 훈련을 마친 뒤 핵심 정답 다시 확인
정답은 Falsch다. Port 53을 열면 DNS처럼 보이는 traffic이 지나갈 수 있지만, 공격자는 query name이나 TXT record 같은 DNS payload에 데이터를 인코딩할 수 있다. port만 보는 firewall은 protocol semantics와 payload 목적을 충분히 검증하지 못한다.
2.1 f) attacker@example.com 계정으로 ceo@example.com spoofed sender mail을 보내면, receiving server가 SPF(Sender Policy Framework)를 사용할 때 spoofed sender임을 인식한다. Wahr/Falsch? 기존 71문항 학습 번호 22 · 2점 Wahr/Falsch
2.1 f) · 실제 시험 원문
한국어로 요구사항만 풀어 읽기
attacker@example.com 계정으로 ceo@example.com spoofed sender mail을 보내면, receiving server가 SPF(Sender Policy Framework)를 사용할 때 spoofed sender임을 인식한다. Wahr/Falsch?
TERMS FOR 2.1 f)
이 소문제의 중요한 용어부터 이해하기
전문 용어를 알고 있다고 가정하지 않습니다. 아래 정의의 굵은 용어를 문제 문장 속 같은 단어와 바꾸어 읽은 뒤 풀이로 넘어가세요.
네트워크에서 header와 payload를 갖고 전달되는 데이터 단위입니다.
IP 계층에서 출발지와 목적지 host/interface를 식별하는 주소입니다.
한 host 안에서 어떤 application/service가 데이터를 받을지 구분하는 번호입니다.
통신 참여자가 message 형식과 순서를 해석하기로 합의한 규칙입니다.
SMTP 전달 과정에서 반송 주소로 사용되는 발신 domain이며 화면의 From header와 다를 수 있습니다.
한 domain이 어떤 IP를 자신의 mail sender로 허용하는지 DNS에 게시하는 정책입니다.
사용자 mail 화면에 주로 표시되는 발신자 주소입니다.
공격자가 다른 주체의 주소나 identity인 것처럼 꾸미는 행위입니다.
이 소문제만을 위한 0부터 시작하는 미니 강의
아래 설명은 이 과목의 선행 지식을 가정하지 않습니다. 개념 → 비유의 대응 → 눈으로 읽는 구조 → 작은 예제 순서로 읽은 뒤 실제 시험 풀이로 넘어가세요.
1 · 먼저 알아야 할 개념
Email 한 통에는 눈에 보이는 작성자와 SMTP 배달 과정의 발신 정보가 따로 있다. 메일 앱에 표시되는
From:header는 메시지 내용의 일부이고,MAIL FROM또는 Return-Path는 반송에 쓰이는 SMTP envelope sender다.SPF(Sender Policy Framework)는 domain owner가 DNS TXT record에 그 domain의 메일을 보낼 수 있는 IP나 server를 게시하는 방식이다. 수신 mail server는 실제 TCP 연결을 건 발송 server의 IP와 envelope sender 또는 HELO domain의 SPF policy를 비교한다.
따라서 SPF가 답하는 질문은 '이 sending IP가 이 domain을 대표해 SMTP mail을 보낼 수 있는가?'다. '로그인한 attacker@example.com 사용자가 Header From에 ceo@example.com을 쓸 권한이 있는가?'라는 개별 mailbox authorization은 직접 검사하지 않는다.
DKIM은 domain key로 header/body에 서명하고, DMARC는 보이는 Header From domain과 SPF 또는 DKIM domain의 alignment 및 처리 정책을 다룬다. 그러나 attacker와 ceo가 같은 example.com domain 안에 있으면 개별 local-part 권한은 여전히 발송 server의 계정 정책이 강제해야 한다.
2 · 일상 장면으로 먼저 잡기
회사 우편실이 공식 트럭 번호판은 확인하지만, 그 트럭에 실린 편지의 발신자 칸에 어느 직원 이름을 써도 되는지는 별도 사내 규칙인 장면
비유의 경계 실제 SPF 평가에는 HELO, MAIL FROM, DNS mechanism과 pass/fail 정책이 있으며 forwarding 같은 추가 문제가 있다. 비유는 IP/domain 인증과 개인 주소 권한이 다르다는 핵심만 보여 준다.
공식 example.com server IP인가? SPF의 핵심 입력
SPF policy를 고를 domain과 반송 주소
사용자가 보는 ceo@example.com; SPF 단독으로 개인 권한 확인 안 함
attacker@example.com; 발송 server가 별도로 권한 강제
같아 보이는 주소도 envelope, header, 로그인 상태 중 어느 층의 값인지 분리해서 읽는다.
공식 example.org 메일 서버를 이용한 내부 주소 사칭
주어진 것과 목표 Mallory는 staff@example.org 계정으로 공식 발송 server M에 로그인한다. M이 Header From 제한을 잘못 설정해 director@example.org를 허용한다.
Mallory가
From: director@example.org인 메일을 M을 통해 보낸다.왜? 수신자 화면에 director가 작성한 것처럼 보이게 하려는 것이다.
중간 결과 메시지 header와 실제 로그인 계정이 다르다.
수신 server R이 연결 source IP를 확인하고 example.org의 SPF TXT policy를 조회한다.
왜? SPF는 M의 IP가 envelope domain에 허가됐는지 평가한다.
중간 결과 M은 공식 server이므로 SPF pass가 될 수 있다.
R이 SPF 결과와 보이는 Header From을 비교해 한계를 확인한다.
왜? SPF pass가 개별 mailbox 작성자 증명인지 판단하기 위해서다.
중간 결과 SPF만으로 Mallory와 director 중 실제 작성자를 식별할 수 없다.
M에서 인증 계정별 허용 From 주소를 강제한다.
왜? 동일 domain 내부 local-part 사칭을 source에서 차단하기 위해서다.
중간 결과 staff 계정의 director 주소 사용이 거부된다.
예제 결론 공식 sending host를 사용한 동일 domain 내부 사칭은 SPF만으로 반드시 탐지되지 않는다.
실제 시험으로 옮기기 시험의 attacker@example.com과 ceo@example.com은 domain이 같다. SPF가 individual local-part를 확인한다고 가정하지 말고 Falsch를 고른다.
이번 문제는 이 단계로 풀어야 했습니다
먼저 문제에서 직접 주어진 값과 최종적으로 구할 값을 분리합니다. 그다음 각 값·용어·경로를 왜 선택했는지 확인하며, 앞 단계의 중간 결과를 다음 단계의 입력으로 사용합니다.
먼저 문제를 식과 조건으로 정리하기
계산을 시작하기 전에 주어진 것과 구할 것을 분리합니다. 그다음 아래 관계식을 위에서 아래로 사용하면, 숫자가 어디서 왔는지 놓치지 않을 수 있습니다.
강사가 문제의 요구사항을 쉬운 말로 바꾸면
시험 문장이 요구하는 것: attacker@example.com 계정으로 ceo@example.com spoofed sender mail을 보내면, receiving server가 SPF(Sender Policy Framework)를 사용할 때 spoofed sender임을 인식한다. Wahr/Falsch?
이 문제의 풀이 전략: 이 소문제에서는 두 From 분리 → 실제 sending host 확인 → 검사 질문 적용 → 결과 판단 → 판정 순서로 진행합니다. 마지막에는 ‘SPF pass는 허가된 server에서 해당 envelope domain을 사용했다는 뜻이지 ceo@example.com 개인 작성자 증명이 아니다.’라는 교정 기준으로 답을 다시 확인합니다.
문제에서 주어진 정보
attacker@example.com 계정으로 ceo@example.com spoofed sender mail을 보내면, receiving server가 SPF(Sender Policy Framework)를 사용할 때 spoofed sender임을 인식한다. Wahr/Falsch?
보이는 `From: ceo@example.com`과 SPF가 주로 평가하는 SMTP envelope domain을 구분한다.
Header From 문자열 자체를 SPF가 서명한다고 쓰지 않았는가?
최종적으로 구해야 하는 것
시험 문장은 Falsch이며, 개별 From 권한은 발송 server 정책이 강제해야 한다.
정답은 Falsch다. SPF는 실제 sending IP가 SMTP envelope sender domain에 허가된 server인지 검사한다. attacker@example.com이 example.com의 공식 발송 server를 이용하면 SPF는 통과할 수 있으며, SPF만으로 Header From의 ceo@example.com local-part 사용 권한을 확인하지 못한다. 동일 domain 내부 사칭을 막으려면 발송 server가 로그인 계정별 From 주소를 강제해야 한다.
사용할 공식·판정 관계
두 From 분리 → 실제 sending host 확인 → 검사 질문 적용 → 결과 판단 → 판정
같아 보이는 주소도 envelope, header, 로그인 상태 중 어느 층의 값인지 분리해서 읽는다.
두 From 분리
구체적으로 보이는
From: ceo@example.com과 SPF가 주로 평가하는 SMTP envelope domain을 구분한다.여기서 검산 Header From 문자열 자체를 SPF가 서명한다고 쓰지 않았는가?
다음 단계로 여기서 확인한 내용을 다음 ‘실제 sending host 확인’ 단계의 출발점으로 사용합니다.
실제 sending host 확인
구체적으로 attacker는 example.com의 정상 계정과 공식 outgoing server를 사용할 수 있으므로 연결 IP가 SPF에 authorized일 수 있다.
여기서 검산 공격자가 반드시 외부 VPS에서 직접 보낸다고 가정하지 않았는가?
다음 단계로 여기서 확인한 내용을 다음 ‘검사 질문 적용’ 단계의 출발점으로 사용합니다.
검사 질문 적용
구체적으로 SPF는 '이 IP가 example.com을 보낼 수 있는가'를 보고 '이 사용자가 ceo local-part 권한이 있는가'는 보지 않는다.
여기서 검산 domain 단위와 mailbox 단위 인증을 분리했는가?
다음 단계로 여기서 확인한 내용을 다음 ‘결과 판단’ 단계의 출발점으로 사용합니다.
결과 판단
구체적으로 공식 server라면 SPF pass도 가능하므로 spoofing을 반드시 erkennt한다는 주장은 성립하지 않는다.
여기서 검산 가능성과 보장을 구분했는가?
다음 단계로 여기서 확인한 내용을 다음 ‘판정’ 단계의 출발점으로 사용합니다.
판정
구체적으로 시험 문장은 Falsch이며, 개별 From 권한은 발송 server 정책이 강제해야 한다.
여기서 검산 DMARC가 같은 domain 내부 모든 사칭을 자동 해결한다고 덧붙이지 않았는가?
다음 단계로 앞 단계의 결과를 모아 채점 가능한 최종 답안으로 정리합니다.
정답과 해설
정답은 Falsch로 학습한다. SPF는 주로 envelope sender/HELO domain에 대해 sending host가 허가되었는지를 확인한다. 공격자가 같은 example.com의 합법 mail infrastructure를 통해 보내거나 header From만 ceo@example.com처럼 조작하면, SPF alone은 ceo identity spoof를 항상 잡지 못한다. header From alignment까지 보려면 DKIM/DMARC 같은 추가 메커니즘이 중요하다.
정답이 이렇게 되는 이유
정답은 Falsch다. SPF는 실제 sending IP가 SMTP envelope sender domain에 허가된 server인지 검사한다. attacker@example.com이 example.com의 공식 발송 server를 이용하면 SPF는 통과할 수 있으며, SPF만으로 Header From의 ceo@example.com local-part 사용 권한을 확인하지 못한다. 동일 domain 내부 사칭을 막으려면 발송 server가 로그인 계정별 From 주소를 강제해야 한다.
초보자가 가장 자주 뒤집는 지점
잘못된 생각 SPF pass는 화면에 보이는 보낸 사람이 실제 그 mailbox 주인이라는 뜻이다.
왜 틀렸나 SPF는 sending host와 envelope domain의 관계를 인증하며 사람이나 개별 local-part를 인증하지 않는다.
고쳐 말하면 SPF pass는 허가된 server에서 해당 envelope domain을 사용했다는 뜻이지 ceo@example.com 개인 작성자 증명이 아니다.
한 문제만 더: 개념이 정말 연결됐는지 확인
질문 외부 VPS가
MAIL FROM:<ceo@example.com>으로 직접 보내고 그 VPS IP가 example.com SPF에 없다면 SPF는 무엇에 도움이 되는가?정답 수신 server가 unauthorized sending IP를 SPF fail로 판정하는 데 도움을 준다. 그래도 실제 거부·격리 여부는 수신 정책과 DMARC 등에 달려 있다.
이 문제의 오답 함정
이 소문제를 점수로 바꾸는 6개의 작은 훈련
해설을 닫은 상태에서 1번부터 수행하세요. 정답을 읽은 직후보다 직접 문제 지도를 만들고 답을 꺼낸 뒤 채점할 때 기억이 더 정확해집니다. 작성 내용과 복습 판정은 이 브라우저에 자동 저장됩니다.
해설을 보지 말고 주어진 정보 → 구할 것 → 사용할 공식·판정 관계를 한 줄씩 복원하세요.
막힐 때만 첫 단서 열기
SPF가 검사하는 Absender는 사용자가 메일 앱에서 보는 From과 항상 같은가?
attacker@example.com 계정으로 ceo@example.com spoofed sender mail을 보내면, receiving server가 SPF(Sender Policy Framework)를 사용할 때 spoofed sender임을 인식한다. Wahr/Falsch?
정답 문장만 말하지 말고 근거·중간값·메시지 흐름 중 이 문항에 필요한 것을 빈 종이에 남기세요.
작성한 뒤에만 아래 기준을 열고, 실제로 쓴 항목만 체크하세요.
답안 작성 후 채점 기준 열기
답안 슬롯 자가 점검 — 실제로 말하거나 쓴 항목만 체크하세요.
0/3 slots
조건 변형: 원문의 강한 표현(예: muss, immer, vollständig)을 조건부 표현으로 하나 고쳐 쓰고, 그 변경 뒤에는 판정이 왜 달라지거나 유지되는지 반례와 함께 설명하세요.
고칠 답안: SPF를 사람 identity 인증으로 오해하기
복구 힌트: SPF가 검사하는 Absender는 사용자가 메일 앱에서 보는 From과 항상 같은가?
오답의 첫 잘못된 전제를 한 줄로 지우고, 올바른 조건과 결론을 두 줄로 다시 쓰세요.
채점 전 예상과 실제 채점 결과가 달랐는지 확인한 뒤 상태를 남기세요. ‘숙달’은 근거와 중간 과정까지 무힌트로 재현했을 때만 선택합니다.
모든 훈련을 마친 뒤 핵심 정답 다시 확인
정답은 Falsch로 학습한다. SPF는 주로 envelope sender/HELO domain에 대해 sending host가 허가되었는지를 확인한다. 공격자가 같은 example.com의 합법 mail infrastructure를 통해 보내거나 header From만 ceo@example.com처럼 조작하면, SPF alone은 ceo identity spoof를 항상 잡지 못한다. header From alignment까지 보려면 DKIM/DMARC 같은 추가 메커니즘이 중요하다.
2.1 g) NSEC-Records는 존재하는 Domains를 enumerate/listing하는 데 사용될 수 있다. Wahr/Falsch? 기존 71문항 학습 번호 23 · 2점 Wahr/Falsch
2.1 g) · 실제 시험 원문
한국어로 요구사항만 풀어 읽기
NSEC-Records는 존재하는 Domains를 enumerate/listing하는 데 사용될 수 있다. Wahr/Falsch?
TERMS FOR 2.1 g)
이 소문제의 중요한 용어부터 이해하기
전문 용어를 알고 있다고 가정하지 않습니다. 아래 정의의 굵은 용어를 문제 문장 속 같은 단어와 바꾸어 읽은 뒤 풀이로 넘어가세요.
domain 이름을 IP 주소 등 resource record로 찾아주는 분산 이름 시스템입니다.
client 대신 여러 DNS server에 질의해 최종 답을 찾아주는 server입니다.
이전에 받은 DNS 답을 일정 시간 저장해 재사용하는 공간입니다.
DNS record를 cache에서 얼마나 오래 재사용할 수 있는지 나타내는 시간값입니다.
DNS over HTTPS로 client와 resolver 사이 DNS message를 HTTPS 안에 암호화합니다.
DNS record에 대한 signature chain으로 data origin과 integrity를 검증하는 확장입니다.
받은 정보가 주장된 권한 있는 출처에서 왔는지를 확인하는 성질입니다.
통신 구간에서 제3자가 내용을 읽거나 쉽게 바꾸지 못하게 하는 보호입니다.
이 소문제만을 위한 0부터 시작하는 미니 강의
아래 설명은 이 과목의 선행 지식을 가정하지 않습니다. 개념 → 비유의 대응 → 눈으로 읽는 구조 → 작은 예제 순서로 읽은 뒤 실제 시험 풀이로 넘어가세요.
1 · 먼저 알아야 할 개념
DNSSEC는 DNS record의 기밀성을 제공하는 기술이 아니라, record가 권한 있는 zone에서 왔고 바뀌지 않았다는 authenticity와 integrity를 서명으로 검증하는 기술이다.
존재하지 않는 이름에 단순히 NXDOMAIN만 보내면 공격자가 그 응답을 위조할 수 있다. DNSSEC는 '이 이름이 실제로 없다'는 사실도 서명해 증명해야 하며 이를 authenticated denial of existence라고 한다.
NSEC record는 canonical order에서 현재 존재 이름 다음에 오는 존재 이름과 현재 이름에 존재하는 RR type bitmap을 포함한다. 두 존재 이름 사이에 질의 이름이 들어가면 그 이름이 없음을 서명된 범위로 증명할 수 있다.
하지만 next-name 연결을 반복해서 따라가면 zone의 공개된 이름들을 한 바퀴 열거할 수 있다. 이 부작용을 zone walking이라 하며 NSEC3는 plain name 대신 hash를 사용해 이를 어렵게 하지만 예측 가능한 이름은 사전 대입으로 찾을 수 있다.
2 · 일상 장면으로 먼저 잡기
공식 서명된 안내판마다 '이 집 다음 실제 집은 저 집'이라고 적힌 마을길을 차례로 따라가는 장면
비유의 경계 실제 canonical ordering과 wildcard·empty non-terminal 처리는 더 복잡하다. 또한 이름 열거는 정찰 정보 노출이지 곧바로 host 침해를 뜻하지 않는다.
NSEC → mail.lab.example
NSEC → vpn.lab.example
NSEC → lab.example
pointer를 따라 존재 이름과 type 수집
각 NSEC의 '현재 이름 → 다음 존재 이름' 화살표가 다시 출발점으로 돌아올 때까지 따라간다.
작은 lab.example zone을 NSEC로 순회하기
주어진 것과 목표 Zone에는
lab.example,mail.lab.example,vpn.lab.example세 이름이 있고 각 NSEC가 다음 이름을 가리킨다.lab.example의 NSEC에서 next namemail.lab.example을 읽는다.왜? NSEC가 다음 존재 이름을 명시해야 사이 이름의 부재를 증명할 수 있기 때문이다.
중간 결과 첫 번째 새 hostname을 알게 된다.
mail.lab.example주변을 질의해 다음 NSEC를 받는다.왜? 체인의 다음 pointer를 계속 얻기 위해서다.
중간 결과 next name
vpn.lab.example과 mail의 RR type bitmap을 알게 된다.vpn.lab.example의 NSEC를 확인한다.왜? 체인이 apex로 돌아오는지 확인해 열거를 끝내기 위해서다.
중간 결과 next가 다시
lab.example이면 세 이름의 순환 목록이 완성된다.각 NSEC의 type bitmap을 함께 기록한다.
왜? 이름뿐 아니라 A, MX 같은 존재 record 종류도 정찰 정보가 되기 때문이다.
중간 결과 공개 zone 구조의 목록을 얻는다.
예제 결론 NSEC의 next-name 정보는 부재 증명에 필요하지만 반복 조회하면 존재 domain을 enumerate할 수 있다.
실제 시험으로 옮기기 시험 문장은 'können'을 묻는다. NSEC chain을 이용한 zone walking이 가능하므로 Wahr다.
이번 문제는 이 단계로 풀어야 했습니다
먼저 문제에서 직접 주어진 값과 최종적으로 구할 값을 분리합니다. 그다음 각 값·용어·경로를 왜 선택했는지 확인하며, 앞 단계의 중간 결과를 다음 단계의 입력으로 사용합니다.
먼저 문제를 식과 조건으로 정리하기
계산을 시작하기 전에 주어진 것과 구할 것을 분리합니다. 그다음 아래 관계식을 위에서 아래로 사용하면, 숫자가 어디서 왔는지 놓치지 않을 수 있습니다.
강사가 문제의 요구사항을 쉬운 말로 바꾸면
시험 문장이 요구하는 것: NSEC-Records는 존재하는 Domains를 enumerate/listing하는 데 사용될 수 있다. Wahr/Falsch?
이 문제의 풀이 전략: 이 소문제에서는 NSEC의 본래 목적 → 노출 필드 찾기 → 반복 동작 연결 → 보안 영향 제한 → 판정 순서로 진행합니다. 마지막에는 ‘NSEC는 부재를 인증하지만 next-name chain 때문에 zone walking이 가능하다.’라는 교정 기준으로 답을 다시 확인합니다.
문제에서 주어진 정보
NSEC-Records는 존재하는 Domains를 enumerate/listing하는 데 사용될 수 있다. Wahr/Falsch?
서명된 범위로 특정 DNS name 또는 record type이 없음을 검증하는 authenticated denial이다.
NSEC를 DNS 암호화 record라고 쓰지 않았는가?
최종적으로 구해야 하는 것
NSEC records를 domain listing에 사용할 수 있으므로 Wahr다.
정답은 Wahr다. NSEC는 이름의 부재를 인증하기 위해 정렬 순서상 다음 존재 이름을 공개한다. 공격자는 이 next-name pointer를 반복해서 따라가며 zone의 존재 domain과 일부 RR type을 열거할 수 있다. 이를 zone walking이라 하며, DNSSEC 서명을 깨는 공격이 아니라 NSEC 설계의 정보 노출 부작용이다.
사용할 공식·판정 관계
NSEC의 본래 목적 → 노출 필드 찾기 → 반복 동작 연결 → 보안 영향 제한 → 판정
각 NSEC의 '현재 이름 → 다음 존재 이름' 화살표가 다시 출발점으로 돌아올 때까지 따라간다.
NSEC의 본래 목적
구체적으로 서명된 범위로 특정 DNS name 또는 record type이 없음을 검증하는 authenticated denial이다.
여기서 검산 NSEC를 DNS 암호화 record라고 쓰지 않았는가?
다음 단계로 여기서 확인한 내용을 다음 ‘노출 필드 찾기’ 단계의 출발점으로 사용합니다.
노출 필드 찾기
구체적으로 NSEC에는 canonical order의 next existing domain name과 RR type bitmap이 들어간다.
여기서 검산 단순 NXDOMAIN 문자열만 있다고 가정하지 않았는가?
다음 단계로 여기서 확인한 내용을 다음 ‘반복 동작 연결’ 단계의 출발점으로 사용합니다.
반복 동작 연결
구체적으로 공격자는 다음 이름을 다시 질의해 또 다음 pointer를 받고 zone apex로 돌아올 때까지 반복한다.
여기서 검산 한 번의 응답이 아니라 chain traversal임을 설명했는가?
다음 단계로 여기서 확인한 내용을 다음 ‘보안 영향 제한’ 단계의 출발점으로 사용합니다.
보안 영향 제한
구체적으로 그 결과 hostname enumeration과 정찰이 가능하지만 DNSSEC key가 깨지거나 host가 자동 침해되는 것은 아니다.
여기서 검산 정보 노출과 시스템 침해를 구분했는가?
다음 단계로 여기서 확인한 내용을 다음 ‘판정’ 단계의 출발점으로 사용합니다.
판정
구체적으로 NSEC records를 domain listing에 사용할 수 있으므로 Wahr다.
여기서 검산 NSEC3의 완화 가능성을 NSEC 정답과 뒤섞지 않았는가?
다음 단계로 앞 단계의 결과를 모아 채점 가능한 최종 답안으로 정리합니다.
정답과 해설
정답은 Wahr다. DNSSEC의 NSEC record는 존재하지 않는 이름을 인증해서 부정하기 위해 다음 existing name 정보를 제공한다. 이 구조 때문에 attacker가 연속적으로 질의하면 zone walking으로 존재하는 domain/name들을 나열할 수 있다.
정답이 이렇게 되는 이유
정답은 Wahr다. NSEC는 이름의 부재를 인증하기 위해 정렬 순서상 다음 존재 이름을 공개한다. 공격자는 이 next-name pointer를 반복해서 따라가며 zone의 존재 domain과 일부 RR type을 열거할 수 있다. 이를 zone walking이라 하며, DNSSEC 서명을 깨는 공격이 아니라 NSEC 설계의 정보 노출 부작용이다.
초보자가 가장 자주 뒤집는 지점
잘못된 생각 DNSSEC는 DNS 정보를 보호하므로 NSEC도 domain 이름을 암호화해 숨긴다.
왜 틀렸나 DNSSEC의 핵심은 공개 데이터의 authenticity와 integrity이지 기밀성이 아니다. NSEC는 오히려 다음 존재 이름을 평문으로 제공한다.
고쳐 말하면 NSEC는 부재를 인증하지만 next-name chain 때문에 zone walking이 가능하다.
한 문제만 더: 개념이 정말 연결됐는지 확인
질문 NSEC3가 plain hostname 대신 hash를 연결하면 zone 이름의 기밀성이 완벽히 보장되는가?
정답 아니다. 직접 읽기는 어려워지지만
mail,vpn,admin처럼 예측 가능한 후보는 hash 사전 대입으로 복원될 수 있다.이 문제의 오답 함정
이 소문제를 점수로 바꾸는 6개의 작은 훈련
해설을 닫은 상태에서 1번부터 수행하세요. 정답을 읽은 직후보다 직접 문제 지도를 만들고 답을 꺼낸 뒤 채점할 때 기억이 더 정확해집니다. 작성 내용과 복습 판정은 이 브라우저에 자동 저장됩니다.
해설을 보지 말고 주어진 정보 → 구할 것 → 사용할 공식·판정 관계를 한 줄씩 복원하세요.
막힐 때만 첫 단서 열기
존재하지 않는 이름을 증명하려면 DNSSEC는 어떤 이웃 이름 정보를 보여 주는가?
NSEC-Records는 존재하는 Domains를 enumerate/listing하는 데 사용될 수 있다. Wahr/Falsch?
정답 문장만 말하지 말고 근거·중간값·메시지 흐름 중 이 문항에 필요한 것을 빈 종이에 남기세요.
작성한 뒤에만 아래 기준을 열고, 실제로 쓴 항목만 체크하세요.
답안 작성 후 채점 기준 열기
답안 슬롯 자가 점검 — 실제로 말하거나 쓴 항목만 체크하세요.
0/3 slots
조건 변형: 원문의 강한 표현(예: muss, immer, vollständig)을 조건부 표현으로 하나 고쳐 쓰고, 그 변경 뒤에는 판정이 왜 달라지거나 유지되는지 반례와 함께 설명하세요.
고칠 답안: DNSSEC가 있으니 enumeration도 무조건 막는다고 생각하기
복구 힌트: 존재하지 않는 이름을 증명하려면 DNSSEC는 어떤 이웃 이름 정보를 보여 주는가?
오답의 첫 잘못된 전제를 한 줄로 지우고, 올바른 조건과 결론을 두 줄로 다시 쓰세요.
채점 전 예상과 실제 채점 결과가 달랐는지 확인한 뒤 상태를 남기세요. ‘숙달’은 근거와 중간 과정까지 무힌트로 재현했을 때만 선택합니다.
모든 훈련을 마친 뒤 핵심 정답 다시 확인
정답은 Wahr다. DNSSEC의 NSEC record는 존재하지 않는 이름을 인증해서 부정하기 위해 다음 existing name 정보를 제공한다. 이 구조 때문에 attacker가 연속적으로 질의하면 zone walking으로 존재하는 domain/name들을 나열할 수 있다.
2.1 h) Tor를 korrekt 사용해도 externer Resolver는 사용자가 어떤 Domain에 접속하려는지 안다. Wahr/Falsch? 기존 71문항 학습 번호 24 · 2점 Wahr/Falsch
2.1 h) · 실제 시험 원문
한국어로 요구사항만 풀어 읽기
Tor를 korrekt 사용해도 externer Resolver는 사용자가 어떤 Domain에 접속하려는지 안다. Wahr/Falsch?
TERMS FOR 2.1 h)
이 소문제의 중요한 용어부터 이해하기
전문 용어를 알고 있다고 가정하지 않습니다. 아래 정의의 굵은 용어를 문제 문장 속 같은 단어와 바꾸어 읽은 뒤 풀이로 넘어가세요.
네트워크에서 header와 payload를 갖고 전달되는 데이터 단위입니다.
IP 계층에서 출발지와 목적지 host/interface를 식별하는 주소입니다.
한 host 안에서 어떤 application/service가 데이터를 받을지 구분하는 번호입니다.
통신 참여자가 message 형식과 순서를 해석하기로 합의한 규칙입니다.
domain 이름을 IP 주소 등 resource record로 찾아주는 분산 이름 시스템입니다.
client 대신 여러 DNS server에 질의해 최종 답을 찾아주는 server입니다.
이전에 받은 DNS 답을 일정 시간 저장해 재사용하는 공간입니다.
DNS record를 cache에서 얼마나 오래 재사용할 수 있는지 나타내는 시간값입니다.
이 소문제만을 위한 0부터 시작하는 미니 강의
아래 설명은 이 과목의 선행 지식을 가정하지 않습니다. 개념 → 비유의 대응 → 눈으로 읽는 구조 → 작은 예제 순서로 읽은 뒤 실제 시험 풀이로 넘어가세요.
1 · 먼저 알아야 할 개념
Tor는 사용자의 트래픽을 guard, middle, exit relay를 거치는 회로로 전달한다. Guard는 사용자 IP를 보지만 보통 최종 목적지를 모르고, exit는 최종 목적지를 보지만 사용자의 원래 IP를 직접 보지 않는 식으로 지식을 분리한다.
일반 인터넷 domain에 접속하려면 어느 시점에는 DNS resolution이 필요하다. Tor Browser를 올바르게 사용하면 browser가 운영체제의 평소 local·ISP·public resolver에 그 domain을 직접 질의하지 않고, 이름 해석 요청을 Tor 회로를 통해 exit 쪽으로 보낸다.
사용자의 평소 외부 resolver가 방문 domain query를 받는다면 웹 연결만 Tor로 보내고 DNS는 밖으로 보낸 DNS leak에 가깝다. 일반 browser의 잘못된 proxy 설정이나 Tor 밖에서 직접 연결하는 DoH·보조 앱이 이런 누출을 만들 수 있다.
다만 exit relay 또는 exit-side resolver는 일반 domain 이름을 볼 수 있다. 시험의 'Ihr externer Resolver'는 사용자가 평소 쓰는 외부 resolver를 뜻하는 문맥으로 읽어 Falsch로 판정하되, exit-side resolver와 구분해야 정확하다.
2 · 일상 장면으로 먼저 잡기
여행자가 고향 전화번호 안내소에는 목적지를 묻지 않고 봉인된 요청을 여러 중계소로 보내 마지막 도시의 안내소가 주소를 찾는 장면
비유의 경계 Tor는 traffic correlation, 로그인에 의한 신원 노출, browser fingerprinting을 자동 제거하지 않는다. 또한 exit 쪽은 목적 domain을 볼 수 있다.
domain 요청을 Tor 회로 안으로 보냄
정상 Tor 사용 시 query 없음
각 relay가 제한된 endpoint 정보만 봄
domain은 보지만 원래 client IP와 직접 연결하지 못함
누가 domain을 보는지뿐 아니라 그 관찰자가 사용자의 원래 IP도 함께 아는지를 나누어 읽는다.
Tor Browser와 일반 proxy 설정의 DNS 차이
주어진 것과 목표 User U가 news.example에 접속한다. 평소 ISP resolver Rlocal과 Tor exit 측 resolver Rexit가 있다.
Tor Browser가 hostname resolution 요청을 Tor proxy에 넘긴다.
왜? 운영체제의 일반 DNS가 news.example을 직접 조회하지 않게 하기 위해서다.
중간 결과 Rlocal에는 news.example query가 나타나지 않는다.
요청이 guard와 middle을 거쳐 exit 쪽에 도착한다.
왜? 각 relay가 사용자와 목적지를 동시에 알기 어렵게 지식을 분리하기 위해서다.
중간 결과 Exit 또는 Rexit가 news.example을 resolve한다.
Exit가 얻은 IP로 목적 server에 연결한다.
왜? 일반 인터넷 domain의 실제 destination에 도달해야 하기 때문이다.
중간 결과 목적 server는 source로 exit IP를 보고 사용자의 원래 IP를 직접 보지 않는다.
비교로 일반 browser가 system DNS Rlocal에 먼저 묻는 잘못된 구성을 본다.
왜? DNS leak의 관찰 가능성을 확인하기 위해서다.
중간 결과 Rlocal이 사용자 IP와 news.example을 연결해 볼 수 있어 privacy가 약해진다.
예제 결론 올바른 Tor Browser 사용에서는 사용자의 평소 외부 resolver가 방문 domain을 DNS query로 알아서는 안 되며, exit 쪽 관찰자만 domain을 볼 수 있다.
실제 시험으로 옮기기 시험 문맥의 resolver를 사용자의 resolver로 고정하고 Falsch를 선택한다. 설명형 답이라면 exit-side resolver caveat를 한 문장 덧붙인다.
이번 문제는 이 단계로 풀어야 했습니다
먼저 문제에서 직접 주어진 값과 최종적으로 구할 값을 분리합니다. 그다음 각 값·용어·경로를 왜 선택했는지 확인하며, 앞 단계의 중간 결과를 다음 단계의 입력으로 사용합니다.
먼저 문제를 식과 조건으로 정리하기
계산을 시작하기 전에 주어진 것과 구할 것을 분리합니다. 그다음 아래 관계식을 위에서 아래로 사용하면, 숫자가 어디서 왔는지 놓치지 않을 수 있습니다.
강사가 문제의 요구사항을 쉬운 말로 바꾸면
시험 문장이 요구하는 것: Tor를 korrekt 사용해도 externer Resolver는 사용자가 어떤 Domain에 접속하려는지 안다. Wahr/Falsch?
이 문제의 풀이 전략: 이 소문제에서는 Resolver의 정체 고정 → 정상 DNS 경로 → 관찰 상태 확인 → 경계 조건 → 판정 순서로 진행합니다. 마지막에는 ‘Tor는 사용자의 평소 resolver로 DNS가 새는 것을 막고, exit 쪽 관찰자가 domain과 원래 client IP를 동시에 직접 보지 못하게 한다.’라는 교정 기준으로 답을 다시 확인합니다.
문제에서 주어진 정보
Tor를 korrekt 사용해도 externer Resolver는 사용자가 어떤 Domain에 접속하려는지 안다. Wahr/Falsch?
문맥의 `Ihr externer Resolver`를 사용자가 평소 쓰는 ISP/public resolver로 해석한다.
Exit-side resolver와 같은 존재로 합치지 않았는가?
최종적으로 구해야 하는 것
올바른 사용인데 사용자의 resolver가 domain을 안다는 문장은 Falsch이며, 그런 현상은 DNS leak이다.
정답은 시험 문맥에서 Falsch다. Tor Browser를 올바르게 사용하면 DNS resolution도 Tor 회로를 통해 exit 쪽에서 수행하므로 사용자의 평소 external resolver가 방문 domain query를 받지 않는다. 그 resolver가 query를 본다면 DNS leak을 의심해야 한다. 다만 exit-side resolver는 domain을 볼 수 있지만 보통 이를 사용자의 원래 IP와 직접 연결해 알지는 못한다.
사용할 공식·판정 관계
Resolver의 정체 고정 → 정상 DNS 경로 → 관찰 상태 확인 → 경계 조건 → 판정
누가 domain을 보는지뿐 아니라 그 관찰자가 사용자의 원래 IP도 함께 아는지를 나누어 읽는다.
Resolver의 정체 고정
구체적으로 문맥의
Ihr externer Resolver를 사용자가 평소 쓰는 ISP/public resolver로 해석한다.여기서 검산 Exit-side resolver와 같은 존재로 합치지 않았는가?
다음 단계로 여기서 확인한 내용을 다음 ‘정상 DNS 경로’ 단계의 출발점으로 사용합니다.
정상 DNS 경로
구체적으로 Tor Browser는 일반 domain의 resolution을 Tor circuit을 통해 remote 처리하도록 넘긴다.
여기서 검산 Browser가 먼저 system DNS에 평문 query한다고 그리지 않았는가?
다음 단계로 여기서 확인한 내용을 다음 ‘관찰 상태 확인’ 단계의 출발점으로 사용합니다.
관찰 상태 확인
구체적으로 사용자 resolver는 query를 받지 않으므로 방문 domain을 DNS log로 직접 알지 못한다.
여기서 검산 Tor 사용 사실과 방문 domain 자체를 구분했는가?
다음 단계로 여기서 확인한 내용을 다음 ‘경계 조건’ 단계의 출발점으로 사용합니다.
경계 조건
구체적으로 Exit 또는 exit-side resolver는 domain을 볼 수 있지만 원래 client IP와 직접 결합해 보지 못한다.
여기서 검산 어떤 resolver도 domain을 절대 못 본다고 과장하지 않았는가?
다음 단계로 여기서 확인한 내용을 다음 ‘판정’ 단계의 출발점으로 사용합니다.
판정
구체적으로 올바른 사용인데 사용자의 resolver가 domain을 안다는 문장은 Falsch이며, 그런 현상은 DNS leak이다.
여기서 검산 문맥상 의도와 caveat를 모두 보존했는가?
다음 단계로 앞 단계의 결과를 모아 채점 가능한 최종 답안으로 정리합니다.
정답과 해설
정답은 Falsch로 학습한다. korrekt Tor 사용에서는 application이 SOCKS/Tor 경로를 통해 이름 해석을 맡기며, 로컬/외부 resolver로 DNS query가 새면 DNS leak이다. 다만 exit node 또는 목적지 쪽 관찰자는 접속 domain을 볼 수 있는 상황이 있을 수 있으므로 resolver visibility와 exit visibility를 구분해야 한다.
정답이 이렇게 되는 이유
정답은 시험 문맥에서 Falsch다. Tor Browser를 올바르게 사용하면 DNS resolution도 Tor 회로를 통해 exit 쪽에서 수행하므로 사용자의 평소 external resolver가 방문 domain query를 받지 않는다. 그 resolver가 query를 본다면 DNS leak을 의심해야 한다. 다만 exit-side resolver는 domain을 볼 수 있지만 보통 이를 사용자의 원래 IP와 직접 연결해 알지는 못한다.
초보자가 가장 자주 뒤집는 지점
잘못된 생각 Tor를 쓰면 전 세계 어떤 DNS resolver도 목적 domain을 볼 수 없다.
왜 틀렸나 일반 domain을 IP로 바꾸려면 exit 쪽에서 resolution이 필요해 exit 또는 exit-side resolver가 domain을 볼 수 있다.
고쳐 말하면 Tor는 사용자의 평소 resolver로 DNS가 새는 것을 막고, exit 쪽 관찰자가 domain과 원래 client IP를 동시에 직접 보지 못하게 한다.
한 문제만 더: 개념이 정말 연결됐는지 확인
질문 Tor Browser로 접속하는 동안 ISP DNS log에
news.examplequery가 사용자 IP와 함께 나타났다. 이는 정상 기대 상태인가?정답 아니다. 다른 앱이나 잘못된 proxy/DoH 설정으로 DNS가 Tor 밖으로 나간 leak을 의심해야 한다.
이 문제의 오답 함정
이 소문제를 점수로 바꾸는 6개의 작은 훈련
해설을 닫은 상태에서 1번부터 수행하세요. 정답을 읽은 직후보다 직접 문제 지도를 만들고 답을 꺼낸 뒤 채점할 때 기억이 더 정확해집니다. 작성 내용과 복습 판정은 이 브라우저에 자동 저장됩니다.
해설을 보지 말고 주어진 정보 → 구할 것 → 사용할 공식·판정 관계를 한 줄씩 복원하세요.
막힐 때만 첫 단서 열기
Tor Browser가 DNS를 OS resolver에게 그대로 맡긴다면 그건 정상 Tor privacy일까?
Tor를 korrekt 사용해도 externer Resolver는 사용자가 어떤 Domain에 접속하려는지 안다. Wahr/Falsch?
정답 문장만 말하지 말고 근거·중간값·메시지 흐름 중 이 문항에 필요한 것을 빈 종이에 남기세요.
작성한 뒤에만 아래 기준을 열고, 실제로 쓴 항목만 체크하세요.
답안 작성 후 채점 기준 열기
답안 슬롯 자가 점검 — 실제로 말하거나 쓴 항목만 체크하세요.
0/3 slots
조건 변형: 원문의 강한 표현(예: muss, immer, vollständig)을 조건부 표현으로 하나 고쳐 쓰고, 그 변경 뒤에는 판정이 왜 달라지거나 유지되는지 반례와 함께 설명하세요.
고칠 답안: exit node가 볼 수 있는 정보와 local resolver가 볼 수 있는 정보를 섞기
복구 힌트: Tor Browser가 DNS를 OS resolver에게 그대로 맡긴다면 그건 정상 Tor privacy일까?
오답의 첫 잘못된 전제를 한 줄로 지우고, 올바른 조건과 결론을 두 줄로 다시 쓰세요.
채점 전 예상과 실제 채점 결과가 달랐는지 확인한 뒤 상태를 남기세요. ‘숙달’은 근거와 중간 과정까지 무힌트로 재현했을 때만 선택합니다.
모든 훈련을 마친 뒤 핵심 정답 다시 확인
정답은 Falsch로 학습한다. korrekt Tor 사용에서는 application이 SOCKS/Tor 경로를 통해 이름 해석을 맡기며, 로컬/외부 resolver로 DNS query가 새면 DNS leak이다. 다만 exit node 또는 목적지 쪽 관찰자는 접속 domain을 볼 수 있는 상황이 있을 수 있으므로 resolver visibility와 exit visibility를 구분해야 한다.