패킷을 들여다 보면 IP 또는 TCP ,UDP 헤더 체크섬(Header Checksum)이 올바르지 않다고
나오는 경우를 보았을 것이다. 와이어샤크를 통해 보았다면, 헤더 체크섬 부분이
Incorrect 로 되어 있고, 어떤 값이 되어야 할지를 알려준다.
헤더 체크섬은 전송중에 깨질 수도 있기 때문에
기본적으로 패킷의 헤더를 보호하기 위해 만들어진 것이다. IP 헤더의 경우를 보면 2바이트(16비트)로
구성되어 있고, 네트워크를 이동하는 각 홉 에서(예를 들면, 라우터 통과) 체크섬을 검증한다.
체크섬이 올바르지 않으면 네트워크 장비는 해당 패킷을 버리게 될 것이다. 네트워크를 거치는 과정에서
체크섬은 재 계산되고 업데이트를 하게된다.
최근의 와이어샤크에서는 헤더 체크섬 값 계산은 기본적으로 disabled 되어 있다. 와이어샤크의 이전인
이더리얼만 해도 기본적으로 체크섬 값을 계산하였지만, 아무래도 이 계산 자체도
퍼포먼스에 영향을 주기 때문에 disabled 되어 있다. 와이어샤크로 열었을때
[validation disabled] 라고 이 기능을 사용하지 않고 있으므로 우측을 클릭해
Protocol References 에서 아래 내용을 체크해 주면 된다. (참고로, IP 헤더에
대해서는 기본적으로 enabled 되어 있다)
- Validate the TCP checksum if possible
- Validate the UDP checksum if possible
헤더의 체크섬 값이 0x0000 으로 되어 있는 경우도 나타나는 경우가 있다.
Header checksum: 0x0000 [incorrect, should be 0x????]
[그림] IP 헤더 Checksum 오류
이럴 경우 네트워크 장비나 기타 원인에 의해 헤더 체크섬 값이 계산되지 않았거나
또는 의도적으로 빠지는 경우도 있다. UDP 프로토콜을 정의한 RFC 768 를 보면
체크섬 값이 제로로 채워져 있는 경우는 보내는 측 쪽에서 계산되지 않는 경우라 정의하고 있다.
이외 나의 경험상 악성코드와 같은 의도적으로 만들어지는 패킷에서도 이런 경우를 종종
볼 수 있었다. 특히 2003~2004년 경에 발생한 악성코드에서 많이 체크섬 값을 계산하지 않는
경우가 많았는데 트래픽을 더욱 많이 생성하기 위해서 약간의 연산이 들어가는 이런 계산 부분도
생략한 것으로 보인다. 물론 제작자의 실수로 인한 부분도 있었을 것이다.
대부분은 정상적으로 체크섬을 계산하기 때문에 계산되지 않은 헤더가 있다면
패킷을 전송한 지점에서의 문제 (애플리케이션 제작 오류, 네트워크 카드 오류, 의도적으로 생성된
악의적 트래픽 등) 그리고, 네트워크 전송장비등이 이유가 있을 것이다.
아마 많은 경우가 전송된 지점의 문제가 아닐까 한다. 전체 덤프된 패킷에서
이렇게 발생되는 비중을 살펴보고 한 단계식 찾아들어가면 원인은 찾을 수 있을 것이다.
