네트워크 보안: 정보 목록화(Footprinting & Scanning)

1. 목표 식별 및 정보 수집 시작 – “IP 추적”

🔹  1-1. IP 주소 추적

• 공격 대상이 누구인지 확인하는 첫걸음은 그 대상의 IP를 찾는 것
• ip-tracker.org 같은 사이트를 통해 특정 IP에 대한 정보를 조회할 수 있음
• 단, VPN이나 프록시 서버를 사용할 경우 정확한 정보 추적이 어려움
• 예: 우리 학교에서 접속하면 KT 인터넷 회선으로 인식됨

🔹 1-2. P2P 서비스에서의 IP 노출

2-1. P2P 서비스란?

Peer-to-Peer 기반으로 작동하는 메신저, 음성통화, 파일 공유 서비스 등

• 카카오톡, 스카이프, 토렌트 같은 P2P(사용자 간 직접 연결) 서비스는 IP가 상대방에게 노출될 수 있음

 

• 메시지는 서버 경유 → IP 노출 없음
• 하지만 파일 전송/음성통화는 직접 연결로 이루어져 IP가 노출됨

---

2. 목록화(Footprinting) – “ 공격 준비를 위한 정보 수집 ”

🔹2-1. 풋프린팅(Footprinting)

• "발자국" → 공격 대상에 대한 공개 정보와 비공개 정보 수집을 총칭
• 공공 데이터, 검색 엔진, SNS 등도 활용 가능

🔹2-2. 사회공학(Social Engineering)

• 인간의 심리나 실수를 이용하여 정보 탈취
• 예: 친구끼리 계정 정보를 공유, 비밀번호를 포스트잇에 적어놓음
• 전체 해킹 중 상당수가 이 기법에 기반

🔹2-3. 수집 대상 예시

• 사용자 계정 이름
• 비밀번호를 유추하기 위한 사용자 관련 정보
• 협력사/계열사의 보안 허점 확인

---

3. 스캔(Scanning) – “시스템을 직접 탐색보자”

🔹3-1. 스캔이란?

• 네트워크를 통해 실제 시스템이 존재하는지, 어떤 서비스가 열려 있는지 조사
• 기본 원리는 “요청을 보내고 응답을 분석” ex) 전화기 눌러보기처럼 요청-응답 구조
• Ping, ICMP, TCP, UDP 등 다양한 프로토콜을 이용

---

🔹3-2. ICMP 기반 스캔 

기본 Ping (Echo Request/Reply)

• Echo Request (Type 8) → Echo Reply (Type 0) 받으면 시스템 활성 확인

다른 ICMP 기법

• Timestamp (Type 13, 14): 시스템 시간 확인
• Information Request/Reply (Type 15, 16): 오래된 방식
• Address Mask Request/Reply (Type 17, 18): 서브넷 마스크 획득

요약: Ping이 막힌 경우 ICMP의 다른 Type을 이용해 우회 가능

---

🔹3-3. TCP (연결지향형)기반 스캔

1.  TCP Open 스캔 (-sT)

• 기본적인 포트 오픈 확인 방식 (3-way handshake)
• 막을 수 x 100% 가능

TCP Open 스캔 (-sT)

2. TCP Half Open스캔  (sS) (스텔스 스캔)

 

• 대상 포트가 열려 있으면 → SYN-ACK 응답
• 공격자는 ACK을 보내지 않고 바로 RST(Reset) 전송
  → 연결을 완전히 열지 않고 종료
  → 그래서 “Half-Open”이라 부름

 

• 연결을 완료하지 않아 로그가 남지 않음
• 대표적 스텔스 스캔

 3. FIN / NULL / XMAS 스캔 (스텔스 스캔)

• FIN: 열린 포트는 응답 없음, 닫힌 포트는 RST패킷 돌아옴
• NULL: Flag 없이 패킷 전송 → 우회 목적
• XMAS: 모든 플래그 설정 (비정상 패킷) → 방화벽 우회 목적

4.  ACK 패킷 이용한 스캔

• 포트 상태가 아닌 방화벽 존재 유무 확인용
• RST 응답 분석 → 열린 포트/필터 여부 판단
• 열린 포트: TTL 값이 64 이하인 RST패킷, 윈도우가 0이 아닌 임의의 값을 가진 RST 패킷이 돌아옴
• 닫힌 포트: TTL값이 일정하게 큰 값, 윈도우 크기가 0인 RST 패킷

5. TCP 세그먼트 단편화 (-f)

• TCP 헤더를 쪼개어 전송해 방화벽 탐지 우회
  • 1번 패킷: IP 주소만 포함
  • 2번 패킷: 포트 정보만 포함

6. 속도 기반 우회

• 짧은 시간에 많은 패킷 전송 → IDS/방화벽 과부하
• 반대로 아주 느리게 전송해 IDS/IPS가 공격으로 인식하지 못함

nmap -sS -T0 192.168.4.129  # 매우 느리게 스캔
nmap -sS -T5 192.168.4.129  # 매우 빠르게

 

 

---

 

🔹3-4. UDP 스캔

• 열린 포트 → 아무 응답 없음
• 닫힌 포트 → ICMP Unreachable
  → 응답 없으면 열린 포트일 수 있으나 신뢰도 낮음

 

 

---

정리표

스캔기법	포트  열림 응답	포트 닫힘 응답
TCP Connect (-sT)	SYN-ACK → ACK (연결됨)	RST
TCP SYN (-sS)	SYN-ACK → RST (스텔스)	RST
FIN / NULL / XMAS	응답 없음	RST
UDP (-sU)	응답 없음 또는 어플리케이션 응답	ICMP Port Unreachable
ACK (-sA)	RST (판단 불가)	응답 없음 (필터링 가능성)

 

---

4. 실습

 실습 환경 구성

• 공격자/대상 시스템: Ubuntu & Windows (가상 머신으로 구성)
• VM 프로그램: VirtualBox, VMware Player 등
• 도구: fping, nmap, hping3, sing 등

---

 실습 도구 요약

fping	IP 범위를 핑하여 활성화된 호스트만 빠르게 탐지
nmap -sT	TCP Open 스캔
nmap -sS	TCP Stealth 스캔 (로그 없음)
nmap -f	패킷 단편화 옵션으로 방화벽 우회

fping 예시

$ fping -q -a -s -g 192.168.4.0/24

nmap 예시

$ nmap -sT 192.168.4.129
$ nmap -sS 192.168.4.129
$ nmap -f 192.168.4.129

---

5. 운영체제 정보 탐지

🔹배너 그래빙

• FTP, SMTP, Telnet 등에서 접속 시 나오는 배너 메시지를 이용해 OS 식별

$ telnet 192.168.4.129 21

🔹TCP/IP 반응 분석

• OS마다 TCP 반응 패턴이 다름
• 예: 윈도우는 시퀀스 넘버를 시간 기반으로 생성, 리눅스는 랜덤

---

6. 방화벽 존재 여부 탐지

방화벽이란?

• 네트워크 접근 제어 장비로, 허용된 트래픽만 통과시키고 나머지는 차단
• 주로 IP 주소, 포트 번호, 프로토콜, 플래그 등의 조건을 기반으로 필터링
• 보안의 최전선에 위치하지만, 스캔 기법을 통해 회피하거나 우회 가능

🔹Traceroute 활용 탐지

traceroute는 TTL(Time To Live)을 점점 늘려가며 라우터 경로를 추적하는 명령어 이다.

 

도중에 *이 표시되는 구간이 있다면:

1.  해당 홉에서 ICMP Time Exceeded 메시지를 차단했거나,
2.  방화벽이 존재하는 경우일 수 있음

traceroute 192.168.4.129

분석 포인트: 어느 지점에서 응답이 끊기는가?

 

🔹firewalk 도구를 이용한 ACL 추론

 

방화벽 뒤에 위치한 서버의 포트 오픈 여부를 파악할 수 있는 고급 도구

 

• 방화벽 또는 라우터가 어떤 포트/프로토콜을 허용하고 차단하는지 파악하기 위한 도구
• 내부망에 직접 접근하지 않고도, 방화벽이 열어놓은 포트를 역으로 추측할 수 있음

 

*ACL: access conntrol list

 

기본 원리:

firewalk는 TTL(Time To Live)을 조작한 패킷을 전송하여, 특정 포트에 대해 방화벽이 패킷을 통과시키는지 여부를 확인함

• TTL을 방화벽 바로 뒤 까지만 도달하도록 조절한 후,
• ICMP Time Exceeded 메시지를 분석

 

동작 순서:

1. TTL 설정하여 방화벽을 탐지, 방화벽이 탐지 되면 TTL 값을 방화벽 바로 뒤에 있는 시스템까지 도달하도록 조절 (TTL+1)
2. 특정 포트 번호로 패킷 전송

방화벽 처리 결과수신 결과의미

포트를 허용한 경우	ICMP Time Exceeded	패킷이 방화벽을 통과했고, 목적지에서 TTL이 0이 되어 traceroute 과정처럼 icmp time exceeded 응답이 도착
포트를 차단한 경우	응답 없음	패킷이 차단되었기 때문에 목적지에 도달하지 않음

✅ 응답이 오면 → 그 포트는 방화벽에서 허용

❌ 응답이 없으면 → 차단된 포트

1. 방화벽이 허용한 포트 → 목적지에서 ICMP Time Exceeded 발생
2. 차단된 포트 → 응답 없음

firewalk -S 192.168.4.1 -d 192.168.4.129 -p 80

 

 

전체 요약: 방화벽 탐지/우회 전략 표

기법	목적	설명
traceroute	방화벽 위치 추정	TTL 응답 끊기는 위치 확인
ACK 스캔	필터링 여부 판단	RST 여부로 판단
firewalk	방화벽 포트 허용 추론	TTL+ICMP 응답으로 추론
패킷 단편화	우회	헤더 쪼개기
NULL/FIN/XMAS	우회	비정상 플래그 조합
속도 조절	우회	IDS 탐지 우회 또는 과부하 유도

 

 

traceroute vs 방화벽 탐지 (firewalk 등) – 차이점 정리

---

Traceroute와 방화벽 탐지(Firewalk 등)는 둘 다 TTL(Time To Live)을 이용하지만, 그 목적과 해석하는 응답 방식이 완전히 다르다.

 

 1. 목적의 차이

구분	traceroute	방화벽 탐지(firewalk 등)
목적	목적지까지의 경로(라우터 위치)를 추적	**방화벽의 열림/차단을 추적
관심 대상	경유하는 라우터/게이트웨이의 IP	특정 포트가 방화벽을 통과하는지 여부
결과 해석	경로상에 위치한 중간 홉(Hop)의 IP 나열	포트가 열려 있는지, 차단되었는지 여부 분석

---

 2. 동작 원리 비교

📍 traceroute의 작동 원리

1. 처음 TTL = 1로 설정하여 패킷 전송
2. 첫 번째 라우터에서 TTL=0 → ICMP Time Exceeded 응답
3. TTL=2, TTL=3… 증가시키며 각 경유지 라우터로부터 응답 수신

 핵심: TTL을 1씩 늘리며 중간 경로를 추적

---

🔥 firewalk(방화벽 탐지)의 작동 원리

1. TTL을 방화벽을 막 통과하는 TTL값으로 설정
   (예: 방화벽이 2번째 홉이면 TTL=3 사용)
2. 특정 포트로 TCP/UDP 패킷 전송
3. 응답 분석:
   • ICMP Time Exceeded 응답 수신 → 방화벽이 해당 포트를 허용
   • 응답 없음 → 방화벽이 해당 포트를 차단

 핵심: TTL을 고정하고, 포트 허용 여부를 간접 확인

---

 3. 응답 분석 방식의 차이

구분traceroutefirewalk (방화벽 탐지)

TTL 초과 응답	중간 경로를 식별하기 위한 신호	방화벽이 허용했음을 의미
응답 없음	라우터가 응답하지 않음 → 해당 경로에 블록이 존재	방화벽이 해당 포트를 차단한 것
최종 목적지 응답	DNS 해석 완료 / 연결 완료 등	해당 없음 (목적지에 닿게 하지 않음)

 

 

---

 

예상문제

 

✅ 문제 1. (서술형)

🔹 문제

Firewalk 도구의 동작 원리를 TTL(Time To Live)과 ICMP 메시지의 상호작용을 중심으로 설명하시오.

✅ 모범 답안

Firewalk는 네트워크 내 방화벽 또는 라우터의 포트 필터링 정책을 추론하기 위한 도구로, TTL(Time To Live)과 ICMP 메시지를 활용한다.

1. 먼저 traceroute를 통해 **방화벽의 위치(TTL 값)**를 추정한다.
2. 이후 TTL 값을 방화벽보다 1 높게 설정하여 패킷을 전송한다. 이 TTL 설정은 패킷이 방화벽을 막 통과해서 목적지까지 도달하게 만든다.
3. 만약 방화벽이 해당 포트를 허용했다면, 패킷은 목적지에 도달하고 TTL이 0이 되며 ICMP Time Exceeded 메시지를 반환한다.
4. 반대로 방화벽이 해당 포트를 차단하면, 목적지에 도달하지 못하고 응답이 없다.

따라서, Firewalk는 TTL 조작과 ICMP 응답 여부를 기반으로 특정 포트가 방화벽을 통과할 수 있는지(허용 여부)를 간접적으로 판단할 수 있다.

---

✅ 문제 2. (응답 해석형)

🔹 문제

다음 결과로 어떤 포트가 열려 있는지, 어떤 서비스인지 쓰시오.

포트 번호응답 결과

22	ICMP Time Exceeded 수신
23	응답 없음
80	ICMP Time Exceeded 수신
443	응답 없음

---

✅ 모범 답안

(1) 방화벽이 허용한 포트:

• 22, 80번 포트는 ICMP Time Exceeded 응답을 받았으므로 허용됨
• 23, 443번 포트는 응답이 없으므로 차단됨

(2) 포트 별 대표 서비스:

포트서비스

22	SSH
23	Telnet
80	HTTP
443	HTTPS

→ 허용된 서비스: SSH(22), HTTP(80)
→ 차단된 서비스: Telnet(23), HTTPS(443)

---

✅ 문제 3. (TCP 헤더 기반 해석)

🔹 문제

TTL=5, Destination Port=25, 응답=ICMP Time Exceeded

---

✅ 모범 답안

(1) 방화벽이 허용한 포트 번호:

• TTL 설정 후 ICMP Time Exceeded 응답을 받았으므로, 패킷이 방화벽을 통과해 목적지에 도달했음을 의미한다.
  → 따라서 25번 포트는 방화벽에 의해 허용되어 있다.

(2) 포트 25의 서비스:

• SMTP (Simple Mail Transfer Protocol) → 이메일 전송 서비스

→ 정답: SMTP(25번 포트)는 방화벽에 의해 허용되어 있다.

---

✅ 문제 4. (참/거짓 OX 판단)

문항정답해설

(1) Firewalk는 TTL 값을 점차 늘려가며 경로를 추적한다.	❌	TTL은 고정값으로 사용된다. 점차 늘리는 건 traceroute 방식이다.
(2) Firewalk는 ICMP Echo Request/Reply를 이용해 서비스 상태를 확인한다.	❌	ICMP Echo는 ping에서 사용되고, Firewalk는 ICMP Time Exceeded 메시지를 분석한다.
(3) ICMP Time Exceeded 응답이 돌아오면, 해당 포트는 방화벽을 통과한 것으로 판단할 수 있다.	✅	응답이 왔다는 것은 TTL이 0이 되었고, 패킷이 목적지에 도달했음을 의미함.
(4) TCP 패킷의 SYN 플래그는 Firewalk 분석에서 의미가 없다.	❌	SYN은 서비스 요청의 의사 표시로, 어떤 포트를 테스트하고 있는지를 명확히 하기 위해 필요하다.

---

 

Kerberos 인증 과정 – 흐름 제시 및 비밀키 식별 문제

---

 

다음은 사용자 A가 서비스 서버 S에 접속하기 위해 Kerberos 인증 절차를 수행하는 과정이다.
각 단계의 설명을 참고하여 (①)~(⑤)에 들어갈 정확한 비밀키 값을 기호로 작성하시오.
(※ 사용할 수 있는 키 기호: K_A,    K_TGS,     K_S,     K_C/TGS,     K_C/S)

 

[Kerberos 인증 흐름]

1. 사용자 A는 자신의 ID를 **Authentication Server (AS)**에게 전송하여 인증을 요청한다.
2. AS는 아래 두 정보를 사용자에게 전달한다.
   • TGS 세션키: K_C,TGS
     → (①)으로 암호화되어 사용자에게 전달된다.
   • TGT (Ticket Granting Ticket) = {A, 주소, 유효기간, K_C,TGS}
     → (②)으로 암호화됨
3. 클라이언트는 TGT와 Authenticator = {A, 타임스탬프}를 암호화하여
   TGS에게 보낸다.
   TGS는 이를 확인한 후 다음 정보를 응답으로 전달한다:
   • SS 세션키: K_C,S
     → (③)으로 암호화되어 사용자에게 전달됨
   • Service Ticket (티켓_S) = {A, 주소, 유효기간, K_C,S}
     → (④)으로 암호화됨
4. 클라이언트는 티켓_S와 새로운 Authenticator = {A, 타임스탬프}를
   **서비스 서버(S)**에게 전송한다.
5. 서버는 인증이 완료되었음을 표시하기 위해
   받은 Authenticator의 타임스탬프를 **(⑤)**으로 암호화하여 클라이언트에게 다시 전송한다.

---

 

답안

 

번호	암호화된 내용	암호화에 사용된 비밀키
①	K_C,TGS	K_A (사용자 A의 비밀키)
②	TGT	K_TGS (TGS의 비밀키)
③	K_C,S	K_C,TGS (사용자와 TGS 간 세션키)
④	티켓_S	K_S (서비스 서버 S의 비밀키)
⑤	타임스탬프	K_C,S (사용자와 서버 간 세션키)

Kerberos 인증 흐름에서 각 암호화 단계는 해당 메시지의 수신자만 복호화할 수 있도록 구성되며,
누가 복호화할지를 기준으로 어떤 비밀키를 사용하는지 판단해야함

 

 

 

1️⃣ 사용자 A → Authentication Server (AS)
2️⃣ AS → 사용자 A
3️⃣ 사용자 A → TGS
4️⃣ TGS → 사용자 A
5️⃣ 사용자 A → 서버 S
6️⃣ 서버 S → 사용자 A

 

1️⃣ 사용자 A → AS: TGT 요청(사용자 ID)
    ↓
2️⃣ AS → A: TGS 세션키 {K_C/TGS, TGT} (암호화: K_A)
            TGT = {A, K_C/TGS, etc} (암호화: K_TGS)
    ↓
3️⃣ A → TGS: TGT + Authenticator
    ↓
4️⃣ TGS → A: SS 세션키 {K_C/S, Ticket_S} (암호화: K_C/TGS)
            Ticket_S = {A, K_C/S} (암호화: K_S)
    ↓
5️⃣ A → S: Ticket_S + Authenticator
    ↓
6️⃣ S → A: {타임스탬프} (암호화: K_C/S)

 

1️⃣ 사용자 A → 인증 서버(AS):
    “안녕하세요, 제 ID는 A입니다. 인증해 주세요!”

2️⃣ 인증 서버(AS → 사용자 A):
    “알겠습니다! 여기 TGS랑 대화할 수 있는 세션키와
    **TGT(티켓)**를 드릴게요.”

• 이 응답은 전체가 사용자의 비밀번호 기반 키로 암호화되어 있어, 사용자만 열어볼 수 있음
• 이 안에는:
  • TGS 세션키 (사용자와 TGS가 대화할 때 사용할 암호 키)
  • TGT (사용자가 인증되었다는 증명서. TGS만 읽을 수 있도록 암호화되어 있음)

---

3️⃣ 사용자 A → 티켓 발급 서버(TGS):
    “여기 제 티켓(TGT)과 인증서(Authenticator, 현재 시간 + 내 ID)가 있어요!”

4️⃣ TGS → 사용자 A:
    “확인됐습니다! 이제 서비스 서버랑 통신할 수 있는 세션키와
    서비스 서버에게 줄 티켓(Ticket_S)을 드릴게요.”

• 이 응답은 TGS와 공유한 세션키로 암호화되어 있음 (사용자만 열 수 있음)
• 이 안에는:
  • 서비스 서버용 세션키
  • 서비스 티켓 (서비스 서버만 열 수 있게 암호화됨)

---

5️⃣ 사용자 A → 서비스 서버(S):
    “여기 제 티켓(Ticket_S)이랑 제 인증서(Authenticator)입니다!”

6️⃣ 서비스 서버(S → 사용자 A):
    “확인 완료! 응답을 보내드릴게요.
    (이건 당신이 보낸 시간정보를 암호화한 거예요)”

• 이 응답은 사용자와 공유한 세션키로 암호화됨
• 인증이 끝났음을 알림

---

✅ 핵심 요약

 

단계	주고받는 정보	암호화 키
AS → 사용자	TGS 세션키 + TGT	사용자 비밀번호 기반 키
TGT 내부	사용자 ID, TGS 세션키 등	TGS의 비밀키
TGS → 사용자	서비스 세션키 + 서비스 티켓	클라이언트-TGS 세션키
서비스 티켓 내부	사용자 ID, 서비스 세션키	서비스 서버의 비밀키
서비스 응답	사용자 인증서의 타임스탬프	클라이언트-서비스 세션키