리눅스 3.7 커널 릴리즈: TCP Fast Open, vxLan 지원

리눅스 3.7 커널이 12월10일에 릴리즈 되었다. 이번 릴리즈는 ARM 64비트 아키텍쳐를 지원하고 서명된 커널 모듈, Btrfs 파일시스템 업데이트, strace 후의 새로운 "perf trace" 도구, 서버측면의 TCP Fast Open 기능, 안정적인 NFS 4.1 등 많은 기능이 업데이트 되었다.

눈에 띄는 변화는 ARM 멀티 플랫폼과 64 비트 지원이다. 싱글 ARM 커널 이미지로 여러 하드웨어에서 부팅이 가능해 졌다. ARM 플랫폼을 지원하도록 배포할때 더욱 쉬워지게 된 것이다.

보안적으로는 서명된 커널모듈을 지원해서, 올바르게 서명되지 않은 모듈은 커널에 로드하지 못하도록 한 것이다. 이 기능은 루트킷등을 이용해 모듈을 추가할 수 없도록 해 보안적으로도 상당히 유용한 기능이다.

네트워크 관점으로 보면 서버 측면에서 TCP Fast Open 을 지원한다. 이미 이 기능은 3.6 커널에서 추가된 것이나 이번 릴리즈는 서버측을 지원하는 것이다. TCP 연결을 맺을때 "Fast Open" 은 더욱 최적화하여 페이지 로드시 4% ~ 41% 정도 속도 향상을 가져온다. 물론 사용되는 환경마다 다르지만 말이다. 이 기능은 추후 블로그에서 다시 한번 소개할 예정이다.

또한 SMBv2 를 지원하고(시험적인 기능) NFS 4.1 이 오랜 기간을 끝내고 드디어 안정 버전으로 릴리즈 되었다. NFS 4.1 의 주 기능은 pNFS 라 하여 패러랠 NFS 을 지원한다. 이로 인해 분산된 여러 서버들 간의 파일시스템에 패러랠한 접근이 가능하다. UDP 프로토콜을 통해 레이어 2 이더넷 패킷을 전송할 수 있는 터널링 프로토콜 vxlan 을 지원한다. vxlan 은 가상화된 환경에서 터널링된 네트워크 환경을 지원하는데 주로 이용된다. VLAN 은 4096 개로 제한되었지만 이것은 24bit 로 확장되어 훨씬 많은 개수를 지원하게 된다. 이것또한 블로그에서 추후 언급할 예정이다.

마지막으로 네트워킹 관점의 변화된 주요 내용은 다음과 같다

• loopback: set default MTU to 64K (commit)
• Providing protocol type via system.sockprotoname xattr of /proc/PID/fd entries (commit)
• Use a per-task frag allocator (commit)
• Netfilter
  • Add protocol-independent NAT core (commit)
  • Add IPv6 MASQUERADE target (commit)
  • Add IPv6 NETMAP target (commit)
  • Add IPv6 REDIRECT target (commit)
  • Add IPv6 NAT support (commit)
  • Support IPv6 in FTP NAT helper (commit)
  • Support IPv6 in IRC NAT helper (commit)
  • Support IPv6 in SIP NAT helper (commit)
  • Support IPv6 in amanda NAT helper (commit)
  • Add stateless IPv6-to-IPv6 Network Prefix Translation target (commit)
  • Remove xt_NOTRACK (commit)
• Near Field Communication (NFC): Add an Link Layer Control (LLC) Core layer to HCI (commit), add an shdlc llc module to llc core(commit), LLCP raw socket support (commit)
• bonding: support for IPv6 transmit hashing (and TCP or UDP over IPv6), bringing IPv6 up to par with IPv4 support in the bonding driver (commit)
• team: add support for non-Ethernet devices (commit)
• gre: Support GRE over IPv6 (commit), add GSO support (commit), add GRO capability (commit)
• packet: Diag core and basic socket info dumping (commit)
• ethtool: support for setting MDI/MDI-X state for twisted pair wiring (commit)
• ppp: add 64-bit stats (commit)
• Add generic netlink support for tcp_metrics (commit)

[참고]
1. 리눅스 커널 3.7 릴리즈
http://kernelnewbies.org/Linux_3.7

이더넷상의 프로토콜 오버헤드는 얼마나 될까?

네트워크 상에서의 프로토콜 오버헤드에 대한 글이 있어서 소개해 본다. 우리가 사용하고 있는 이더넷과 프로토콜 스택상에서 얼마나 빨리 전송할 수 있을지, 얼마나 많은 대역폭을 사용하는지 가늠해 볼 수 있다. 다음은 프로토콜 오버헤드를 이더넷, 기가비트 이더넷, ATM, POS 등으로 나누어 소개한 자료이다.

주소 : http://sd.wareonearth.com/~phil/net/overhead/

예를 들어 이더넷의 프레임 포맷을 살펴보면,

• 6 바이트 목적지 주소
• 6 바이트 출발지 주소
• 필요시 이용되는 4바이트의 802.1q VLAN 태그 (옵션)
• 2 바이트 길이/타입
• 46-1500 바이트 데이터 (페이로드)
• 4 바이트 CRC

로 구성되어 있다. 이더넷의 오버헤드 요소를 살펴보면 ,

  12 gap + 8 preamble + 14 header + 4 trailer = 38 bytes/packet w/o 802.1q
  12 gap + 8 preamble + 18 header + 4 trailer = 42 bytes/packet with 802.1q

로 된다. VLAN 태그가 없이도 38 바이트 사용하는 경우 42 바이트가 된다. 이더넷 페이로드를 포함한 데이터 비율은 다음과 같이 된다:

  1500/(38+1500) = 97.5293 %   w/o 802.1q tags
  1500/(42+1500) = 97.2763 %   with 802.1q tags

1) 이더넷상의 TCP 전송

 헤더 압축은 없다고 가정
 IPv4 헤더에 20 바이트 또는 IPv6 헤더에 40 바이트 추가
 TCP 헤더 20 바이트 추가
 TCP 타임스탬프 옵션 값 12 바이트 추가
 이더넷을 통한 최대 TCP 페이로드 데이터 전송률은 다음과 같다:

  (1500-40)/(38+1500) = 94.9285 %  IPv4, minimal headers
  (1500-52)/(38+1500) = 94.1482 %  IPv4, TCP timestamps
  (1500-52)/(42+1500) = 93.9040 %  802.1q, IPv4, TCP timestamps
  (1500-60)/(38+1500) = 93.6281 %  IPv6, minimal headers
  (1500-72)/(38+1500) = 92.8479 %  IPv6, TCP timestamps
  (1500-72)/(42+1500) = 92.6070 %  802.1q, IPv6, ICP timestamps

2) 이더넷상의 UDP 전송

 IPv4 헤더에 20 바이트 또는 IPv6 헤더에 40 바이트 추가
 UDP 헤더 8바이트 추가
 이더넷을 통한 최대 UDP 페이로드 데이터 전송률은 다음과 같다:

  (1500-28)/(38+1500) = 95.7087 %  IPv4
  (1500-28)/(42+1500) = 95.4604 %  802.1q, IPv4
  (1500-48)/(38+1500) = 94.4083 %  IPv6
  (1500-48)/(42+1500) = 94.1634 %  802.1q, IPv6

이렇게 소개하고 있다. 이외 기가비트 이더넷은 점보 프레임을 사용하는 경우 최대 전송은 990.042 Mbps 이며, 점보 프레임 없이는 941.482 Mpbs 이다. 이론적으로만 보면 점보 프레임을 사용하는 경우가 전송률 면에서 더 유리하다. 점보프레임은 얼마전 블로그에서 소개한 적이 있으니 참고해 보길 바란다.

프로토콜 오버헤드를 참고 삼아 알아두면 좋을것 같다.

[참고]
1. Protocol Overhead
http://sd.wareonearth.com/~phil/net/overhead/
2. 점보프레임(Jumbo Frame)으로 전송속도 높이기
http://www.packetinside.com/2012/03/jumbo-frame.html

첫번째 CaseStudy, 어느 기업의 급격한 UDP 트래픽 증가

첫번째 CaseStudy 를 소개한다. 어떤 것을 소개할까 하다, 일반 기업에서 발생한 사례 하나를 소개해

보고자 한다. 흔히 요새는 알수없는 트래픽이 급격히 증가하면, 이거 악성코드에 의한 것이 아닐까 하고

생각하는 경우가 많다. 과거와는 달리 악성코드에 의한 트래픽 영향을 겪어 봐서 그런가 이런 의심부터

시작하고 분석을 거기에 초점을 맞추는 경우가 있다.

이번 Case도 누가 해킹하여 발생한 것이 아니냐, 악성코드를 심어 놓은 것이 아니냐 하는 의견이 있었다.

일단 분석대상인 이 패킷에는 다음과 같은 다양한 트래픽이 포함되어 있었다.

- ARP

- NetBIOS

- UDP

- 일반 사용 트래픽 (웹 과 같은)

그중에서도 가장 유독 눈에 띄게 관찰되는 부분이 UDP 였다. 그런데 증상은 항상 지속적으로 나타나지

않는다는 점이며, 일시적으로 나타났다 사라진다고 한다. 사실 지속적 증상없이 이렇게 일시적으로만

나타나는 경우가 분석에 제일 곤란한 부분이다.

패킷파일은 우선 와이어샤크로 분석을 진행했다. Protocol Hierarchy Statistics 로 발생한 트래픽을 살펴보니

UDP 의 사용이 가장 컸고, 그래프를 만들어 살펴봐도 위 그림과 같이 UDP 가 차지하는 비중이 꽤 높게 나타났다. 전체적인 관점에서 보다보면 이 외에도 다른것 까지도 다 의심의 범위에 속하긴 하였지만,

여기서는 일단 범위가 UDP 로 조금은 좁혀진 상태에서 이야기 하도록 한다.

UDP 를 살펴보니 두가지 종류 형태의 UDP가 관찰되었다.

- DATA 가 256 바이트인 UDP 이며 255.255.255.255 로 브로드 캐스트 주소 (목적지)

- Payload 를 1400 바이트로 채운 UDP

패킷파일 화면 일부를 보면 아래와 같이 이상하게 보일만큼 단시간내에 많은 내용이 있었다.

워낙에 많은 데이타 이다 보니 주욱 대충 살펴보면 DATA 상에서는 의심스러운 문자열 같은건 발견하지 못했다.

여러분도 아시겠지만, 데이터가 아주 큰 경우는 세밀하게 분석하자면 한도 끝도 없다. 전체적인 관점에서

먼저 살피는데, 알수없는 문자열들의 조합으로만 이루어져 있어 눈에 잘 들어오지가 않는다. 그런데 필자의

눈에 하나 잡힌 것이 있었다. 바로 아래와 같은 문자열이다.

헤더 첫 부분에서 JFIF 라는 문자열이다. 검색해 보았더니, JPEG File Interchange Format 이란다. 그럼 이미지 형태의 데이터가 아닐까 추측을 해 보았다.

왜 이렇게 더 생각할 수 있었던 이유는 이 패킷을 전달받은 곳이, 하드웨어적인 영상을 찍는 업체였기 때문이다. 그럼 느낌이 오지 않는가 ?

- 일시적으로 UDP 패킷이 크게 증가하는데,

- UDP 페이로드가 JFIF 관련한 것이고

- 패킷덤프를 뜬 곳이 이런 영상 관련 업체라는 점.

일단 UDP Follow Stream 을 통해 연결된 패킷을 모으고, 해당 데이터를 바이너리로 저장해 보았다. 물론, UDP 와 관련한 헤더는 수동으로 제거 시켜버렸다. 그리고 이미지 뷰어를 통해 살펴보니, 아래와 같은 이미지가 나타난다.

아니, 이건 무엇인가? 얼핏봐도 이미지 파일인걸로 추정해 볼 수 있으며, 사무실 형태의 윤곽이 잡힌다. 문제해결에 실마리가 될 결정적 단서가 될수도 있는 것이다. 전달된 UDP 데이터를 완벽하게 복원하지는 않았지만, 대략 복구해 낸 것으로도 이미지임을 알 수 있었다. 이렇게 분석해 낸 정보로 정리했는데, 확인 결과

개발자들의 테스트가 사무용 네트워크에서 일어나며 트래픽이 크게 발생된 것이었다.

즉, 발생된 내부에서는 내부 개발자들에 의한 일시적인 트래픽 증가로 의심하지 않았고,

다른 분석가들에 의해 내부 해킹되어 악성코드가 심어져 있어 통신에 의해 일시적으로 공격명령을 내린다는

형태의 가설이 설정되어 있었던 것이다. 처음 분석 의뢰를 받았을때, 그런 사전 정보를 기준으로 하다보니

혼란스러운 부분이 있었다.  결과의 원인을 해킹/악성코드 이슈로 정의해 놓고 분석을 하다 보니, 모든 관련된

것을 그쪽으로 맞춰 생각하기 쉬어질 수 있다.  

실제로 분석을 하다 보면 내부의 원인에 의해 발생되는 문제가 크다. 해당 담당자들이 내부에서 발생되는

트래픽을 정확히 이해하고 있다면 좀더 빠른 접근을 통해 해결될 수 있었을 텐데, 아쉬운 부분이기도 하다.

내부적으로 우선 발생한 것이 아닌지 면밀한 조사가 선행되어야 분석이 빨라지게 된다. 의뢰받아

분석을 하는 분석가 입장에서는 그곳의 네트워크 구성과, 어떤 형태의 트래픽이 발생되는지 등등의 형태를

모르기 때문이다. 그러므로 처음부터 분석해 나가며 하나씩 다 파악해야 하다보니 분석이 더디어 지게 된다.

물론, 특징적인 형태가 한눈에 보인다면 쉽게 해결될 수도 있겠지만, 엄청난 트래픽 데이터와 싸우려면

여간 지치는게 아니다. 하여튼 이번 CaseStudy 사례는 기업에서 급격히 발생한 UDP 트래픽이 있었고,

초기에 다른분석가들에 의해 악성코드에 의한 것으로 좁혀졌지만, 실제 패킷 포렌직을 통해서 확인해 보니

내부 개발자들에 의해 발생된 트래픽으로 확인이 된 것이다.

어떻게 첫번째 CaseStudy 가 여러분들에게 도움이 되었는지 모르겠다.

[참고]

1. JPEG File Interchange Format

http://en.wikipedia.org/wiki/JPEG_File_Interchange_Format