현재 선택한 정보보안 과정

정보보안기사 필기 이론 학습

이론 목록으로 돌아가기

네트워크 진단 도구와 출력 해석

주소·이웃·경로·소켓을 차례로 확인하고 ping과 traceroute 결과의 한계를 구분합니다.

예상 읽기 5

1. 진단 도구는 확인할 대상을 먼저 정한다

네트워크 장애는 주소 설정, 같은 링크의 전달, 라우팅, 서비스 상태 중 어느 단계에서 생겼는지 나누어 확인한다. 다음은 대표적인 조회 명령이다. 실제 인터페이스 이름과 주소는 환경마다 다르다.

확인 대상Windows 예Linux 예알 수 있는 것
IP·마스크·게이트웨이ipconfig /allip address, ip route로컬 설정과 경로
IPv4 이웃 매핑arp -aip neigh다음 홉 IP와 MAC의 대응
라우팅 테이블route print, netstat -rip route목적지별 다음 홉
ICMP 응답pingpingEcho 요청·응답의 왕복 여부
경로의 중간 홉tracerttracerouteTTL 만료 응답으로 관찰한 경로
소켓·연결 상태netstat -anoss -tuna대기 포트, 연결 주소와 TCP 상태
실제 패킷별도 캡처 도구tcpdump헤더와 송수신 흐름

Linux의 ifconfig도 기존 자료에 등장하지만 ipconfig는 Windows 명령이다. arp -a는 ARP 캐시를 보여 주며 RARP를 실행하는 명령이 아니다. RARP의 주소 요청 원리는 ARP·RARP·ICMP의 역할에서 구분한다.

2. ping 성공과 서비스 성공은 다르다

ping은 ICMP Echo Request와 Echo Reply를 이용한다. TCP·UDP 포트가 열렸는지를 직접 검사하지 않는다.

CODE코드 영역 안에서 좌우로 이동할 수 있습니다.
Reply from 198.51.100.20: bytes=32 time=18ms TTL=51

time=18ms는 이 요청·응답의 왕복 시간이며, TTL=51은 수신한 패킷의 남은 TTL이다. 초기 TTL과 경로를 모르므로 이 값 하나로 상대 운영체제를 확정할 수 없다.

  • IP로 성공하고 이름으로 실패: DNS 설정·이름 오타 등을 우선 확인한다.
  • ping은 성공하지만 웹 접속은 실패: TCP 포트, 방화벽 정책, 웹 서비스 상태를 확인한다.
  • ping 실패: 호스트 중단뿐 아니라 ICMP 차단·손실 가능성도 있다.

Windows의 ping /n 4 주소와 Linux의 ping -c 4 주소는 각각 4회 요청하는 예다. 같은 옵션 문자가 운영체제마다 같은 뜻인 것은 아니다.

3. traceroute의 별표를 해석한다

TTL을 1부터 늘려 보낸 탐색 패킷에 대해 중간 라우터가 ICMP Time Exceeded를 반환하면 홉을 알 수 있다. Windows tracert는 ICMP Echo를 사용하며, 다른 traceroute 구현은 UDP·ICMP·TCP 등을 사용할 수 있다.

CODE코드 영역 안에서 좌우로 이동할 수 있습니다.
1  192.0.2.1       1 ms
2  203.0.113.1     5 ms
3  *  *  *
4  198.51.100.20  18 ms

3번 홉에서 응답이 없어도 목적지인 4번이 응답했으므로, 3번 장비가 패킷을 전혀 전달하지 못했다고 단정할 수 없다. 응답 차단·응답률 제한·손실 등이 원인일 수 있다. 결과는 관찰 시점의 경로 단서이며 공격자의 실제 출발지를 밝히는 역추적 결과와 다르다.

4. 대기 포트와 연결 상태를 읽는다

다음은 학습용 소켓 출력이다.

CODE코드 영역 안에서 좌우로 이동할 수 있습니다.
TCP  0.0.0.0:443        0.0.0.0:0           LISTENING
TCP  192.0.2.10:53000   198.51.100.20:443   ESTABLISHED

첫 줄은 로컬의 모든 IPv4 주소에서 443번 포트의 연결을 받도록 대기한다는 뜻이다. 방화벽까지 허용되었다는 의미는 아니다. 127.0.0.1:443으로만 대기하면 다른 호스트가 그 소켓에 직접 접속할 수 없다.

둘째 줄은 TCP 연결이 수립되었다는 뜻이며, 로그인 성공이나 암호화까지 보장하지 않는다. SYN-RECEIVED가 대량 누적되면 미완료 연결을, CLOSE-WAIT가 오래 남으면 로컬 응용의 종료 처리를 확인한다. TIME-WAIT은 정상 종료 후에도 나타난다. 자세한 상태와 플래그는 TCP·UDP와 연결·순서 제어에서 이어서 확인한다.

5. 주소에서 패킷까지 확인 순서를 연결한다

192.0.2.10/24가 다른 망의 서버에 접속할 때 다음 순서로 좁혀 본다.

  1. 로컬 주소·마스크·게이트웨이 설정을 확인한다.
  2. 목적지에 적용되는 경로와 다음 홉을 찾는다.
  3. 같은 링크에 있는 다음 홉의 ARP 매핑을 확인한다.
  4. ICMP 응답과 중간 홉을 참고하되 무응답을 곧바로 장애로 확정하지 않는다.
  5. 대상 서비스의 대기 상태와 방화벽 정책을 확인한다.
  6. 여전히 원인이 불명확하면 패킷으로 SYN·응답·오류 흐름을 확인한다.

이 순서는 원인을 나누어 보는 방법이지 모든 환경에 강제되는 단일 절차는 아니다. tcpdump의 저장·읽기와 필터 해석은 패킷 분석과 Pcap 활용에서 다룬다.

스스로 확인하기

개념 확인 문제

문제를 누르면 바로 아래에서 정답과 해설을 확인할 수 있습니다.

01ping은 성공하지만 HTTPS 접속은 실패할 수 있는가?
정답 및 해설

그렇다. ICMP Echo 왕복은 TCP 443 허용이나 웹 응용의 정상 동작을 보장하지 않는다.

02중간 홉은 별표인데 마지막 목적지가 응답했다면 그 홉의 전달 장애로 확정할 수 있는가?
정답 및 해설

아니다. 중간 홉이 탐색 응답을 제한했을 수 있다. 별표는 제한 시간 안에 응답받지 못했다는 관찰이다.