소개
스캐너를 사용하기 전에 주소, 이름, 네트워크 경로, 서비스 포트를 구분해야 합니다. 이들은 서로 다른 관찰이며 한 계층의 성공이 다른 계층의 성공을 입증하지 않습니다.
이 실습은 Kali 환경 안에 로컬 DNS 서버와 웹 서비스를 제공합니다. 게이트웨이를 스캔하거나 공개 대상에 의존하지 않고 네트워크를 살펴보고 교육용 이름을 해석하고 TCP 리스너를 확인합니다.
주소, 경로, 루프백 도달 가능성 확인하기
이 단계에서는 Kali 컨테이너의 네트워크를 살펴보고 제한된 로컬 연결 경로를 테스트합니다.
준비된 셸에 들어가 작업 공간을 선택하세요.
kali
cd /home/labex/project
IP 주소는 네트워크 엔드포인트를 식별합니다. 인터페이스는 시스템과 네트워크의 연결이며, 경로는 특정 주소로 가는 트래픽의 이동 방향을 설명합니다. 컨테이너에는 자체 네트워크 보기가 있으므로 호스트 설정을 가정하지 말고 이 환경을 확인하세요.
ip는 Linux 네트워크를 살펴봅니다. -brief 옵션은 인터페이스 주소의 간결한 보기를 요청합니다.
ip -brief address
루프백 인터페이스인 lo와 127.0.0.1을 찾아보세요. 루프백 트래픽은 이 네트워크 환경 안에 머뭅니다. 다른 인터페이스와 주소는 달라질 수 있습니다. /8이나 /16 같은 접두사는 주소의 네트워크 범위를 설명하며 서비스 포트가 아닙니다.
경로를 살펴보세요.
ip route
default 항목이 있다면 더 구체적으로 일치하는 경로가 없을 때 사용됩니다. 게이트웨이를 스캔하거나 경로를 바꿀 필요는 없습니다.
ping은 도달 가능성 탐사 패킷을 보냅니다. -c 3은 자동으로 끝나도록 테스트를 세 번으로 제한합니다.
ping -c 3 127.0.0.1
응답과 최종 패킷 요약이 나와야 합니다. 정확한 시간은 달라집니다. ping 응답은 이 탐사에 대한 응답을 받았음을 보여 주며 특정 TCP 서비스가 수신 대기 중임을 확인하지 않습니다.
이미 배운 출력 리디렉션으로 인터페이스 관찰 내용을 저장하세요.
ip -brief address > interfaces.txt
cat interfaces.txt
저장된 보기에는 루프백 인터페이스와 그 주소가 포함되어야 합니다.
교육용 DNS 서버로 이름 해석하기
이 단계에서는 로컬 DNS 서버를 사용해 이름 해석과 서비스 연결을 구분합니다.
DNS는 이름을 레코드로 변환합니다. A 레코드는 IPv4 주소를 담습니다. 이 실습은 127.0.0.1의 포트 5353에 DNS 서버와 로컬 이름 training-web.test를 제공합니다. 공개 DNS 서비스는 필요하지 않습니다.
dig는 DNS를 조회합니다. @127.0.0.1은 서버를 선택하고, -p 5353은 기본값과 다른 DNS 포트를 선택합니다. 다음 인수는 이름이며 A는 IPv4 주소 레코드를 요청합니다.
dig @127.0.0.1 -p 5353 training-web.test A
응답 섹션에는 이름과 주소 127.0.0.1이 표시되어야 합니다. DNS도 포트를 사용합니다. 여기서 포트 5353은 응답이 가리키는 웹 서비스가 아니라 교육용 DNS 서버에 속합니다.
+short 표시 옵션은 응답 데이터만 출력합니다. 더 작은 결과를 저장하세요.
dig @127.0.0.1 -p 5353 +short training-web.test A > dns-answer.txt
cat dns-answer.txt
예상 출력:
127.0.0.1
시스템 이름 조회는 DNS를 직접 조회하는 대신 로컬 파일을 사용할 수도 있습니다. getent hosts는 시스템에 설정된 호스트 조회 방식으로 이름을 질의합니다.
getent hosts localhost
출력은 localhost를 루프백 주소와 연결하며 IPv6 ::1일 수도 있습니다. 이는 dig로 제공된 DNS 서버를 명시적으로 조회하는 것과 다릅니다. 이름 해석이 성공하면 주소를 얻습니다. 필요한 서비스가 그 주소에서 사용 가능한지는 여전히 확인해야 합니다.
리스너를 살펴보고 TCP 포트 테스트하기
이 단계에서는 주소를 특정 전송 프로토콜 및 서비스 포트와 연결합니다.
포트는 주소의 전송 엔드포인트를 식별합니다. TCP는 연결을 설정하며 UDP는 같은 연결 핸드셰이크 없이 데이터그램을 보냅니다. 서비스 포트 번호만으로 어떤 애플리케이션이나 취약점이 있는지 입증할 수 없습니다.
ss는 소켓 정보를 표시합니다. -l은 수신 대기 소켓, -t는 TCP를 선택하고 -n은 주소와 포트 번호를 숫자로 유지합니다.
ss -ltn
로컬 엔드포인트 127.0.0.1:8080을 찾으세요. 제공된 교육용 웹 서비스에 속합니다. 이 주소는 서비스를 컨테이너의 루프백으로 제한합니다. -t 대신 -u로 UDP 소켓을 따로 확인하세요.
ss -lun
교육용 DNS 엔드포인트는 포트 5353을 사용합니다. TCP와 UDP는 별도의 포트 공간을 가지므로 같은 번호를 두 프로토콜에서 사용할 수 있습니다.
연습 서비스의 TCP 리스너 행만 저장하세요. 패턴에는 더 긴 숫자와 구별하도록 포트 앞의 콜론과 뒤의 공백이 포함됩니다.
ss -ltn | grep ':8080 ' > service-listener.txt
cat service-listener.txt
행에는 LISTEN과 127.0.0.1:8080이 있어야 합니다. 간격과 큐 값은 달라질 수 있습니다.
Ncat은 애플리케이션 데이터를 보내지 않고 TCP 연결을 테스트할 수 있습니다. -v는 상태를 출력하고 -z는 대화형 데이터 세션 대신 연결 검사를 요청합니다.
ncat -vz 127.0.0.1 8080
상태는 연결 성공을 보고해야 합니다. 이는 선택한 TCP 포트가 현재 연결을 받는다는 증거이며 아직 HTTP 응답을 검증하지는 않습니다. HTTP 자체는 이후 실습에서 확인합니다.
요약
인터페이스와 경로를 살펴보고 횟수가 제한된 도달 가능성 테스트를 보내고 로컬 DNS를 조회하고 TCP 및 UDP 리스너를 확인하고 TCP 연결 하나를 테스트했습니다. 성공적인 이름 해석과 네트워크 도달 가능성을 애플리케이션 수준의 동작과 구분했습니다.



