'netstat'에 해당되는 글 2건

  1. 2006.08.11 Netstat 로 살펴본 TCP 상태 Trouble Shooting
  2. 2006.08.07 [PC보안] Netstat 명령어로 점검
engineering/Network Eng.2006. 8. 11. 13:36
출처 블로그 >   ◈ 쭌 날다 ◈  
원본 http://blog.naver.com/uliel7719/17866891

1. The three-way TCP handshake

TCP
장치들 사이에 논리적인 접속을 성립(establish)하기 위하여 three-way handshake 사용한다.

Client > Server : TCP SYN
Server > Client : TCP SYN ACK
Client > Server : TCP ACK

여기서 SYN 'synchronize sequence numbers', 그리고 ACK'acknowledgment' 약자이다.
이러한 절차는 TCP 접속을 성공적으로 성립하기 위하여 반드시 필요하다.

TCP
windowing 사용한다. (윈도우는 현재 네트웍 혼잡과 수신 용량에 따라 조정될 있는 데이터 플로우의 크기)

구체적인 TCP three-way handshake 과정은 다음과 같다.

요청 단말(클라이언트) 아래 요소를 포함하는 서버에게 TCP SYN 세그먼트를 송신
-
연결하고자하는 서버의 포트 번호
-
클라이언트의 Initial Sequence Number (ISN)
-
옵션인 Maximum Segment Size (MSS)


TCP SYN ACK
아래와 같은 SYN 정보를 가지고 있는 서버의 응답
-
서버의 ISN
-
클라이언트의 ISN + 1 대한 ACK
-
옵션인Maximum Segment Size (MSS)

서버의 SYN 대한 클라이언트의 ACK (TCP ACK)
-
서버의 ISN + 1

TCP
통한 TCP 통신의 분석 , MSS 접속 시간내에 다른 peer에게 알리며 MSS 옵션이 존재하지 않으면 디폴트로 536 bytes 사용한다는 사실을 명심하라. (이것은 디폴트 IP MTU 576 bytes에서 20-bytes IP 헤더와 20-bytes TCP 헤더를 값이다.)
옵션인 MSS 일반적으로 클라이언트와 서버 사이의 경로상의 Maximum Transmission Unit (MTU)에서 프로토콜 오버헤드를 값이며 네트웍 계층(Network Layer) 헤더를 포함하고 있다. 예를 들어, Ethernet 대하여 요구되는 MSS 1460 bytes 이며 IEEE 802.3 대한 것은 1452 bytes 이다. (8-byte LLC SNAP 헤더에 대해 허용) 만약 어떤 네트웍 사이에 MTU 대해 세그먼트 크기가 너무 크면 필요하지 않은 IP Fragmentation 발생할 있음에 주의하라.


2. TCP Retransmissions

TCP
수신자의 윈도우 크기에 따라서 다수의 TCP 패킷의 데이터를 전송하므로써 시작되며 수신자의 ACK 인지 되는 버퍼 크기 (윈도우 크기) 허용되는 비율만큼 계속 전송된다. 만약, TCP 세그먼트가 ACK 보지 못하고 패킷이 유실되면 송신자는 반드시 어떤 순차적인 세그먼트를 다시 보내야 한다.
하나의 TCP 패킷 재전송에 대해 오직 하나의 패킷에 대한 재전송으로 생각하지는 말아야 한다.

패킷 재전송이 발생하는 상황:

-
전송되는 TCP 세그먼트 혹은 되돌아온 ACK 스위치나 라우터에의해서 유실(dropped) 되는 경우
-
패킷이 전송하는 동안 손상될 (패킷은 CRC 에러를 가지고 있음)
-
패킷의 TCP 데이터 부분이 스위치나 라우터에 의해서 손상될 (TCP 체크섬 에러 발생)
-
수신자가 패킷을 버퍼에 저장할 없을
- TCP
세그먼트가 fragment 되고 fragment 손상되거나 유실(dropped) 될때
- ACK
너무 늦게 돌아오고 송신자가 하나 혹은 이상의 세그먼트를 재전송

만약 ACK 수신되지 않으면 세그먼트는 다시 전송하지만, 첫번째 대기 시간의 두배가 된다. TCP 스택은 접속의 round-trip 시간에 기반하여 초기 timeout 값을 동적으로 계산한다.
각각의 성공적인 재전송은 이전 시도의 두배로 연기된다. TCP 스택은 포기하기 전에 미리 정해진 시간 만큼 시도할 것이다. Windows 95/98/NT 상에서 디폴트 설정은 5번의 시도로 레지스트리상에 설정되어 있다.

Expert
시스템이 없는 Protocol Analyzer 가지고도 다음과 같은 3가지 순서에 따라 TCP 대한 재전송을 인지할 있다:

1. Analyzer
상의 display 버퍼상에서 통신하고 있는 IP 스테이션의 두쌍에 대한 필터를 적용한다.
2.
성공적으로 전송된 패킷 사이의 대략 1초의 3/1 해당하는 long delay 혹은 주요 delay들을 관찰한다.
3.
이전의 패킷에 대하여 전송하는 sequence number 체크한다. 오리지널 전송은 몇몇 패킷 이전에 위치할 있음을 명심하라.

각각의 패킷 사이의 long delta 시간과 주요 delay 지시되는 패킷 재전송을 확인하라.
이러한 패킷 재전송의 증거는 패킷내의 sequence number 동일하다는 것으로 증명될 있다.
, TCP 패킷 재전송은 sequence number 동일하다는 것을 의미한다.

가지 경우, Analyzer 버퍼 상에 그런 재전송이 발생하는 지에 대한 실마리가 이미 있다.
가지 가능성은 다음과 같다.

-
이전 세그먼트 혹은 ACK CRC 에러를 가지고 있다. (Ethernet)
-
토큰링 상에서 스테이션은 대략 2초후에 소프트 에러를 보고한다.
-
이전 패킷에서 TCP 체크섬 에러는 가능한 브리지 혹은 라우터의 손상을 나타낸다.
-
이전 패킷의 TCP 체크섬 에러와 현재 패킷이 재전송되고 있는 패킷은 송신자의 문제이다.
(
예를 들면, TCP 체크섬이 올바르게 계산되지 않을 있다.)
-
유실되거나 지연된 ACK 있을 경우, Analyzer 다른 세그먼트로 이동해서 문제를 정확하게 지적해야 한다.

만약 특정한 서버나 워크스테이션에서 많은 수의 TCP 재전송이 의심되면 netstat 명령어를 사용할 있다.
Netstat
명령의 일반적인 사용 (netstat –r)으로 라우팅 정보 - 예를들면 서버나 워크스테이션과 연관된 라우터등의 route table 얻을 있다. Netstat 명령으로 또한 “netstat –s” 사용하여 프로토콜 통계에 대한 정보를 얻을 있다. Windows 95/98/NT 상의 netstat 명령은 특정 프로토콜을 명시할 있다.
예를 들어, “netstat –s –p tcp” 명령으로 특정 NT 서버의 대한 다음과 같은 정보들을 얻을 있다.

C:\>netstat -s -p tcp

TCP Statistics

Active Opens = 204
Passive Opens = 734
Failed Connection Attempts = 2
Reset Connections = 263
Current Connections = 2
Segments Received = 44759
Segments Sent = 26058
Segments Retransmitted = 15

Active Connections

Proto Local Address Foreign Address State
TCP elca:1123 64.12.24.58:5190 ESTABLISHED
TCP elca:1549 203.231.222.194:pop3 TIME_WAIT
TCP elca:1553 203.231.222.194:pop3 TIME_WAIT
TCP elca:31510 test.iworld.co.kr:1635 ESTABLISHED

상기의 netstat 예제를 보면 26,058 TCP 세그먼트가 서버에 의해 전송되었고 15개의 재전송이 발생하였다. 이것은 1% 보다 작다. 만약, 퍼센트가 이보다 높아진다면 다음 순서는 Analyzer 서버의 세그먼트에 Tapping하여 TCP 트래픽을 조사해야 한다.

Sniffer Expert System
Symptom 설명

-
중요도: Minor

-
현상: 메시지는 특정 TCP 패킷의 순서 번호가 이전 것과 비교하여 같거나 작을 , 이전에 이미 전송된 TCP 세그먼트에 대한 ACK 신호를 받지 못하여 시간 초과 상태에서 해제되었던 패킷이 재전송되었을 경우에 발생한다.

-
원인:
.
네트웍 트래픽이 정체되었을 경우
.
수신하는 스테이션이 과부하 상태인 경우
.
라우터가 과부하 상태이거나 다른 이유로 전송지연이 되는 경우
. ACK
신호를 보냈지만 유실된 경우
.
원래의 패킷이나 ACK 손상을 입은 경우
. ACK
신호가 늦은 경로로 전송되었을 경우
. IP
조각을 읽어버린 경우
.
네트워크의 완결성에 문제가 있는 경우

# netstat -an

LISTEN

서버의 데몬이 떠서 접속 요청을 기다리는 상태 (서버 애플리케이션에서 수동적 열기로 연결 요청을 기다리고 있는 상태)

SYN-SENT

로컬의 클라이언트 어플리케이션이 원격 호스트에 연결을 요청한 상태 (원격 호스트에 능동적인 개설 요청(능동적 열기))

SYN_RECEIVED

서버가 원격 클라이언트로부터 접속 요구를 받아 클라이언트에게 응답을 하였지만 아직 클라이언트에게 확인 메시지는 받지 않은 상태 (네트워크 통한 연결요청 받음(수동적 열기))

ESTABLISHED

3 Way-Handshaking 완료된 서로 연결된 상태

FIN-WAIT1

능동적 닫기(active close) 요청을 상태

CLOSE-WAIT

수동적 닫기를 하고 있는 상태로 FIN 종결 세그먼트를 수신하고 이에 대한 확인 메시지를 전송한 상태

FIN-WAIT2

로컬에서 종결(FIN)세그먼트를 전송하였고 원격 시스템에서 이에 대한 확인메시지를 수신하였지만 원격 애플리케이션이 작업을 종료하지 않아 원격 호스트 종결 세그먼트를 기다리는 상태

LAST_ACK

FIN 종결 요청을 받고 로컬에서도 회선 종결에 합의하여 종결을 요청(FIN) 상태로 이에 대한 확인 메시지가 수신되면 회선이 종결됨

TIME-WAIT

연결은 종료되었지만 분실되었을지 모를 느린 세그먼트를 위해 당분간 소켓을 열어놓은 상태

CLOSING

로컬 TCP FIN_WAIT_1에서 설명한대로 FIN 종결 세그먼트를 전송하였고, LAST_ACK에서 설명한대로 원격 시스템의 종결 세그먼트도 수신하였지만 FIN_WAIT_1 단계에서 전송한 세그먼트에 대한 확인 메시지(ACK) 수신하지 못한 상태로 보통 확인 메시지가 전송 도중 분실되었다는 것을 나타냄. (흔하지 않지만 주로 확인 메시지가 전송도중 분실된 상태)

UNKOWN

소켓의 상태에 대해서 확인이 안되는 경우

CLOSED

완전히 종료, 회선 종결.



- 출처: Elca Ryu (AnalysisMan.com)

Posted by theYoungman
engineering/Network Eng.2006. 8. 7. 13:21

Command 모드에서 netstat를 사용하여 PC내의 악성 코드 여부를 확인할 수도 있다.

1. [시작버튼] > [실행]을 눌러서 cmd 라고 입력하여 Command 창을 띄운다.
<참고: CTRL+R 을 누르면 [실행]창이 바로 뜬다.>
<또 참고: Windows 98에서는 cmd 가 아니라 command 라고 해야 command 창이 나온다.>

2. netstat   -an
명령어를 치면 아래 그림과 같은 메시지가 출력된다.


앞에 보이는 IP주소(Local Address)는 로컬시스템(내 PC)의 IP주소이며 뒤의 IP주소(Foreign Address)는 나와 네트워크로 연결이 이루어진 시스템의 IP주소이다.  (IP뒤의 ":숫자" 들은 포트 번호이다.)netstat 명령어는 현재 시스템과 네트워크로 연결이 이루어진 상태를 보여주는 명령어다.

자, 이제 분석 방법이다!(FPORT 블로그에서는 존댓말을 썼었는데 왜 갑자기 반말쓰냐고 욕하지는 마세요;)

먼저 위 메시지의 맨 끝 필드인 State 필드를 보자. ESTABLISHED는 연결되어있는 상태를 말하며 CLOSED는 이미 연결이 끊어졌음을 말한다. LISTENING은 현재 시스템에서 열려있는 포트를 말한다.

일단 LISTENING 이라고 되어있는 놈들은 본다. IP주소는 0.0.0.0으로 된 놈들이 많고 내 IP주소 몇개 안될것이다.

<참고: 0.0.0.0(네트워크 IP) - 이놈을 인식하지 못하면 인터넷을 못한다.>

<또 참고: 127.0.0.1(LocalHost IP) - 이놈은 자기를 스스로 가리킬때 사용하는 주소이다.>

Local Address 필드의 IP는 중요하지 않다. 어차피 거기는 내 컴퓨터의 정보만 나오니까. 중요한것은 LISTENING으로 되어있는, 다시말하면 "열려있는 포트"번호이다.

내 컴퓨터에 몇번 포트들이 열려있는지 살펴본 후에, 만일 그 포트로 접속한 놈이 있다면 90%는 뭔가 이상한 거라고 생각하면 된다.

예를 들어,

0.0.0.0:445           0.0.0.0:0               LISTENING
.                         .                         .
.                         .                         .
.                         .                         .
150.2.50.14:445     68.235.32.153:4461  ESTABLISHED


이렇게 보였다고 하자, 445 번 포트(0.0.0.0:445)가 현재 열려(LISTENING)있음을 알 수 있고,

아래에는 내 445번 포트로(150.2.50.14:445) 웬 68.235.32.153 이라는 놈이 접속(ESTABLISHED)했다는 것이 확 드러났다.

일반 개인 컴퓨터 이므로 누가 내 컴퓨터로 들어올일은 거의 없다! (P2P로 내 컴퓨터의 폴더가 공유되어 있다면 몰라도..)

아무튼 이런식으로 분석을 하면 되겠다.

그 외의 것들은 죄다 내가 상대방 컴퓨터로 접속한것을 나타내는 것이기 때문에 무시해도 된다. 물론, Reverse 해킹 방식이 있기는 하지만, 그걸 개인 컴퓨터에 적용할 정도로 무식한 크래커는 없을것이다.

내용출처 : [직접 서술] 직접 서술
(출처 : '[PC보안]  Netstat 명령어로 점검' - 네이버 지식iN)

Posted by theYoungman