┗System∑Sec†ion┛

[ 책소개 ]

네트워크 프로그램을 통해 TCP/IP 프로토콜의 구조와 원리를 배우도록 구성되었다.

프로토콜의 특성이나 문제점, 운용 시에 주의해야 할 점을 경험할 수 있는 흥미로운 실험과

프로그램이 수록되어 있다. 

재미있게 네트워크 실험을 할 수 있도록 TCP/IP 프로토콜의 시큐리티적인 약점을 들추는 것 같은 
자극적인 프로그램이 몇 가지 포함되어 있다. 예를 들면, 특정 호스트를 통신 불능으로 만들어
버리는 프로그램이나 TCP의 커넥션을 아예 없애는 그런 프로그램도 있다. 

또한 이들 프로그램을 효과적으로 이용하기 위해서 Ethernet의 패킷을 모니터링하고, 헤더의 구조를 잘 알 수 있는 형식으로 표시하는 소프트웨어도 실었다. 이 패킷 모니터링 툴을 사용하면서 실험해 봄으로써 프로토콜이나 패킷 헤더에 관한 이해를 한층 깊게 할 수 있을 것이다.

[ 목차 ]

제1장 TCP/IP 프로토콜 스택 입문 

1.1 TCP/IP 프로토콜과 프로토콜 스택의 기초 

1.2 프로토콜 스택 자세히 알아보기 

1.3 프로토콜 스택의 실현 방법 

제2장 TCP/IP 프로토콜과 헤더의 구조 

2.1 프로토콜 헤더와 구조체 

2.2 Ethernet 

2.3 ARP(Address Resolution Protocol) 

2.4 IP(Internet Protocol) 

2.5 ICMP(Internet Control Message Protocol) 

2.6 UDP(User Datagram Protocol) 

2.7 TCP(Transmission Control Protocol) 

2.8 체크섬 

제3장 소켓 

3.1 소켓의 개요 

3.2 소켓에 사용되는 구조체 

3.3 소켓 시스템 콜에 따른 처리의 흐름 

3.4 소켓 시스템 콜 자세히 알아보기 

3.5 UDP에 의한 통신 

3.6 TCP에 의한 통신 

제4장 패킷 모니터링 실험

4.1 패킷 모니터링의 기초 지식 

4.2 데이터 링크 액세스 인터페이스 

4.3 패킷 모니터링 프로그램 

제5장 TCP/IP 통신의 식별 

5.1 IP 어드레스와 포트 번호 

5.2 호스트 스캔 프로그램 

5.3 TCP 포트 스캔 프로그램 

5.4 UDP 포트 스캔 프로그램 

제6장 ARP의 실험 

6.1 ARP란 

6.2 ARP를 사용한 실험 프로그램 

제7장 IP와 ICMP의 실험 

7.1 라우팅 테이블과 경로 제어 

7.2 redirect 프로그램 

7.3 scanroute 프로그램 

제8장 TCP의 실험 

8.1 TCP란 

8.2 TCP SYN 프로그램 

8.3 TCP RST 프로그램 

8.4 TCP JACK 프로그램 

제9장 IPv6에 의한 통신 실험 

9.1 IPv6란 

9.2 IPv6를 사용한 실험 프로그램

[ 빌트인 함수 ]

♧ gcc에는 표준 라이브러리에 있을 듯한 몇몇 함수가 빌트인 함수로 마련되어 있음.

최적화 방법에 따라 소스에 쓰인 것과 다른 코드를 생성할 경우 있다.

▷ 예를 들면 printf(3) 함수의 경우 다음과 같이 문자열을 출력하는 코드에서는 실행할 때

pirntf(3)의 형식 문자열을 해석할 수 없으므로 다음과 같이 puts(3)를 호출하는 코드를 생성.

▷ 기본적으로는 같은 동작을 하고 더 빠르게 실행될 듯한 코드가 생성되어 문제는 없으나,

LD_PRELOAD 등으로 오버라이드(override)해서 동작을 변경하고자 할 경우에는 주의 할

필요가 있다. 최적화를 통해 어떤 코드가 생성되는지 gcc/builtins.c에 프로그램 되어 있다.

[ 애트리뷰트 (__attribute__) ]

♧ 함수에 애트리뷰트를 덧붙여 선언하면

함수에 특별한 의미를 부여하거나 함수호출을 최적화 할 수 있다.

▶ 애트리뷰트 선언 2가지 방법

▶ 함수에 관한 애트리뷰트에는 다음과 같은 것들이 있다.

[ 레이블(label) 참조 ]

♧ C에서는 그다지 사용되지 않지만 goto로 점프할 위치를 지정할 때 레이블을 사용.

▷ GCC에서 레이블은 &&로 참조하고 void *형 함수에 대입할 수 있다.

이와 같이 레이블을 변수에 대입할 수 있기 때문에 변수 값에 따라 점프할 위치를 변경하도록

하는 코드는 레이블로의 참조를 요소로 갖는 배열로도 구현할 수 있다.

레이블을 &&로 참조한 값은 void *에 대입할 수 있는 포인터형이므로 뺄셈으로 오프셋을

얻을 수 있다. 따라서 다음과 같은 코드를 작성할 수 있다.

#include <stdio.h>

void func() {

printf("");

printf("");

printf("");

}

% gcc -o fpic-no-pic.s -S fpic.c

% gcc -fPIC -o fpic-pic.s -S fpic.c

% gcc -shared -o fpic-no-pic.so fpic.c

% gcc -shared -fPIC -o fpic-pic.so fpic.c

[ PIC와 비 PIC 공유 라이브러리의 성능 비교 ]

♧ 위 예에서는 비 PIC 버전은 실행 시에(동적 링크 시에) 5개의 주소가

재배치 되어야 한다고 했다. 그러면 재배치 수가 매우 커지면 어떻게 될 것인가?

공유 라이브버리를 PIC버전과 비 PIC버전printf()를 천만 번 호출 ( 셸 스크립트로 실행 비교)

▶ 다음 셸 스크립트를 실행하면 printf()를 천만 번 호출하는 공유 라이브러리를

비 PIC버전과 PIC 버전으로 만들고, 각각을 링크한 실행 파일 fpic-no-pic와 fpic-pic를 생성.

비 PIC 버전이 첫 회 2.15초, 두 번째 이후에는 약 0.55초가 걸리고,

PIC 버전은 최초 0.02초, 두 번째 이후에는 0.00초가 되었다.

☞ main()의 내용은 없으므로 비 PIC 버전은 동적 링크할 때

재배치에 2.15 ~ 0.55초를 필요로 함을 알 수 있다.

실행 환경은 Xeon 2.8GHz + Debian GNU/리눅스 sarge + GCC 3.3.5이다.

▷ 비 PIC 버전의 단점은 실행할 때 재배치에 시간이 걸린다는 점만이 아니다.

재배치가 필요한 부분의 코드를 재작성 하기 위해

『텍스트 섹션 내의 재배치가 필요한 페이지를 로드 → 재작성

→ copy on write 발생 → 다른 프로세스와 텍스트를 공유할 수 없음』

이라는 사태가 발생. 즉, 여기서는 텍스트(프로그램 코드)를 다른 프로세스와

공유할 수 있는 『공유』라이브러리의 주요한 장점이 사라지고 만다.

한편, 비 PIC 버전의 fpic-no-pic.so 와 PIC 버전의 fpic-pic.so 파일 크기를 비교하면,

전자는 268MB, 후자는 134MB로 크게 차이가 난다. readelf -S로 섹션 데이터를 보면

다음과 같은 차이가 있다.

비 PIC 버전은 코드(.text) 크기는 PIC 버전보다 작지만, 재배치에 필요한 정보(.rel.dyn)가

상당한 용량을 차지.

[ 정리 ]

여기서는 공유 라이브러리를 작성할 때 PIC로 컴파일 해야 하는 필요성에 대해 알아보았다.

비 PIC 공유 라이브러리를 작성할 수는 있지만 실행할 때 재배치에 시간이 소요되고 다른

프로세스와 코드(.text)를 공유할 수 없는 커다란 단점이 있다. 따라서 공유 라이브러리를

작성할 때는 .c 파일을 PIC로 컴파일 하도록 한다.

[ .o 파일을 모아서 링크할 경우 ]

▷ 우선 a.c와 b.c가 동일한 이름의 func()함수 정의

▷ main.c에서 func() 호출.

▶ 위 세 파일을 각각 컴파일해서 실행.

☞ 정적으로 링크하려 하면 func() 함수가 여러 개 존재하므로 링커에서 에러를 출력.

이 에러 덕분에 예상외의 func() 함수가 호출되는 문제를 사전에 피해갈 수 있다.

[ 라이브러리를 생성해서 링크할 경우 ]

♧ 앞에서와 동일한 소스코드 a.c와 b.c에서 ar을 사용해

정적 라이브러리를 생성하면 링크할 때 에러가 발생하지 않는다.

그 이유는 링커와 달리 오브젝트 파일로 아카이브를 생성하는

ar 명령은 심볼 충돌을 검사하지 않기 때문.

▶ 생성된 실행 파일 a.out을 실행

☞ 실행해 보면 a.c의 func()를 호출함을 알 수 있다.

이는 링크할 때 libfoo.a에 있는 두 func() 중에 a.c의 함수를 b.c의 함수보다 먼저 찾기 때문.

▶ 정적 라이브러리 libfoo.a를 ar 명령으로 생성할 때

인자의 순서를 a.o b.o에서 b.o a.o로 변경하면 b.o의 func()가 호출.

▶ 또한 a.c와 b.c를 이용해 각각 정적 라이브러리를 만든 경우에도 링크할 때는

에러가 발생하지 않는다. 이때 gcc에 넘긴 liba.a와 libb.a의 순서를 반대로 하면

b.c의 func()를 호출하게 된다.

▶ 마찬가지로 a.c와 b.c로 각각 동적 공유 오브젝트 생성해서 링크하면

에러는 발생하지 않는다. 아래 예에서는 a.so의 func()가 호출.

링크할 때 명령행 인자의 a.so와 b.so의 순서를 바꾸면 b.so의 func() 함수를 먼저 찾게 된다.

동적 링크할 때는 기본적으로 먼저 발견한 심볼 정의가 사용된다.

▷ GNU C Library의 주요 개발 구성원인 울리히 드레퍼가 작성한

『How to write Shared Libraries』 에는 다음과 같이 기술 되어 있다.

[ C++와 같은 이름의 클래스 ]

C++에서 동일 심볼 문제는 예상치 않은 멤버 함수를 호출하는 문제를 야기한다.

소비세를 계산하는 s.{h, cpp}라는 소스코드와 이를 이용한 main.cpp가 있다고 하자.

▷ a.h 작성

▷ a.cpp 작성

▷ main.cpp 작성

▶ 위 소스코드 컴파일, 링크해서 실행하면 apple: 105라는 메시지 출력.

여기서 별도로 개발된 b.cpp가 존재하고 같은 이름의 클래스 Tax가 구현되어 있다고 하자.

b.cpp내의 Tax 클래스의 용도는 a.cpp와는 전혀 다르다.

▷ b.cpp 작성

▶ 그리고 b.cpp를 b.so로 컴파일하고 불행히도 b.so, a.so, main.so 순으로

링크된다면 성가신 일이 발생한다.

이번 실행 결과는 apple: 10이다.

이는 Tax 객체의 생성자로 b.so 내의 Tax::Tax()가 호출되고, Tax 객체의 멤버함수로서

a.so 내의 Tax::tax()가 호출되었기 때문이다.

즉, 예상외의 생성자가 호출되어 버그의 원인이 되었다.

☞ 프로그램이 거대해질수록 발생가능성이 커진다.

따라서 namespace를 사용해서 충돌을 피해갈 필요가 있다.

심볼을 하나의 파일 내에 모두 넣는다면 이름 없는 namespace를 사용해도 될 것이다.

예를 들면 b.cpp 전체를 snamespace { … }로 둘러싸면 위와 같은 문제는 발생하지 않는다.

[ weak 심볼 ]

♧ 첫머리에서 .o 파일을 모아서 링크할 때는 동일한 이름의 심볼 충돌이 확인 했다.

그러나 weak 심볼이 존재하면 애기는 달라진다.

다음과 같은 프로그램 main.cpp를 생각해보자.

▶ 컴파일 실행하면 256 출력.

여기에 main.cpp와는 전혀 별개로 개발된 다음과 같은 a.cpp가 있다.

a.cpp 내에도 클래스 Foo가 구현되어 있다.

▶ 컴파일한 a.o가 불행히 main에 링크된다면 매우 성가신 일이 발생한다.

☞ 이번 실행 결과는 256이 아니라 제곱수인 65536이 출력 되었다.

이때는 링크 순서가 main.o, a.o 또는 a.o, main.o 둘 다 상관 없이 결과는 변하지 않는다.

main.cpp 내에 정의된 생성자 Foo::Foo(int)가 아니라 a.cpp 내의 Foo::Foo(int)가

사용된 것은 분명하지만, 이런 문제가 발생하는 이유는 무엇일까?

▶ 〔weak 심볼〕이란 무엇인가?

원인은 main.o에 포함된 Foo::Foo(int)는 weak 심볼이고

a.o에 포함된 Foo::Foo(int)는 weak 심볼이 아니기 때문이다.

▷ 아래의 nm 출력 결과에서 W로 표시된 것이 weak 심볼을 나타내는 표시이다.

☞ weak 심볼에 관해서는 『Linkers & Loaders』(john R. Levine 저, Morgan Kaufmaun)

의 6장에 다음과 같이 설명되어 있다.

즉, a.o에 일반적인(비weak 인) 정의가 존재하므로 main.o에 있는

Foo::Foo(int)의 weak 정의는 무시되었다는 것이다.

일단 이 문제를 피해가려면 이름 없는 namespace를 사용해 링키지 링크를 막는 것이

효과적이다. 구체적으로 main.cppㅇ듸 클래스 Foo { … }주위에 namespace { … }로 둘러싼다.

▶ weak 정의와 중복 코드 제거

그런데 왜 main.o Foo::Foo(int) 및 Foo::Func()는 weak 정의가 되는 것일까?

그 이유는 g++는 인라인 함수를 weak 정의로서 컴파일 하기 때문이다.

(클래스 정의 내의 함수정의는 표준 C++ 규격에 따라 인라인 함수로 간주)

따라서 weak 정의는 .o파일 내의 .gnu.linkonce.t.*라는 이름의 섹션에 배치된다.

.gnu.linkonce.t.*는 링크할 때 중복 코드 제거에 사용되는 섹션이다.

클래스 정의는 대개의 경우 .h 파일 내에 기술되고,

.h 파일은 여러 개의 .cpp 파일에 #include 된다. 이 때문에 각각의 .o 파일에

포함된 weak 정의를 링크할 때 하나로 모을 필요가 있다.

인라인 함수가 weak 정의로 되는 것은 이 때문이다.

[ C/C++와 심볼명 ]

▷ 아래의 dbg 함수를 C/C++컴파일러로 각각 컴파일해 보자.

# C 컴파일 :: gcc -W -Wall -c dbg.c

# C++ 컴파일 :: g++ -W -Wall -c dbg.c

▷ C컴파일 / 심볼명 확인

▷ C++컴파일 / 심볼명 확인

▷ 컴파일해서 생성된 오브젝트 파일에 포함된 심볼명.

☞ C 컴파일러로 함수를 컴파일 하면 기본적으로는 함수명이 그대로 심볼명이 된다.

시스템 환경에 따라서는 심볼명이 "dbg"가 아니라 "_dbg"가 될 경우도 있지만 크게 다르지는 않다.

한편, C++ 컴파일러로 함수를 컴파일한 경우 함수가 속한 이름공간(namespace) 정보

또는 함수 인자의 자료형 정보가 심볼명에 포함되어 나타난다.

[ C++에서 C함수 호출하기 ]

▶ dbg.c를 C컴파일러로 컴파일한 후 C++로 작성된 함수(sample.cpp)에서 호출해 보자.

① sample.cpp 작성

② sample.cpp 컴파일, 링크하면 정상적으로 실행 파일이 생성/실행

이상 없이 C++함수(sample.cpp)에서 C함수(dbg)를 호출 하였다.

☞ sample.cpp의 『extern "C"』가 포인트다.

▶ 『extern "C"』의 유무에 따라 sample.o의 변화.

① 『extern "C"』가 있을 경우.

② 『extern "C"』가 없을 경우.

☞ ②에서 "sample.o"는 "_z3dbgPKc"라는 심볼을 참조하지만,

dbg.o에 포함된 심볼은 단지 "dbg"로 "_z3dbgPKc"는 심볼은 어디에도 없다.

▷ 따라서 『extern "C"』를 넣지 않으면 다음과 같이 링크할 때 실패하게 된다.

이와 같이 C++에서 C함수를 호출할 때 『extern "C"』가 중요한 역할을 한다.

▶ 〔주의〕 extern "C"를 붙이면 인자의 자료형 일치 여부를 검사하지 않는다.

① sample.cpp의 dbg자료형 변경.

② 컴파일, 링크, 실행.

☞ 정상적으로 링크는 되지만 생성된 실행 파일은 정상적으로 실행 되지 않는다.

▶ 〔왜! 링크는 성공한 것일까?〕

sample.o가 참조하고 있는 것은 어디까지나 자료형 정보를 포함하지 않은 심볼 "dbg"로,

dbg.o에 포함되어 있는 심볼명과 일치하기 때문이다.

"링크에 성공하면 잘못된 자료형으로 함수가 호출되지 않는다."라고 생각하기 쉽지만,

C++라도 extern "C"를 사용한 부분인 경우에 한해서는 그렇지 않다.

이는 컴파일러에서 자료형을 검사하는 안전성 수준이 C언어 수준으로 저하되기 때문이다.

▷ 이러한 문제를 미연에 방지하려면 C언어 측의 헤더 파일을

C++에서도 이용할 수 있도록 준비해 두어야 한다.

예를 들면, 아래의 dbg.h와 같은 헤더 파일을 작성하는 것이 바람직하다.

[ C에서 C++함수 호출하기 ]

▷ 이번에는 반대로 C에서 C++ 함수를 호출해 보도록 하자.

『최대공약수를 구하는 함수』를 Boost C++ Library를 이용해

C++로 간단히 구현하고, 그 함수를 C에서 호출해 보자.

▶ 〔중요한 점 두가지〕
º C++함수를 C 링키지(extern "C")로 컴파일.

º 링크는 gcc가 아닌, g++로 수행.

▷ C++측 구현

▷ C++함수를 호출하는 C프로그램은 특별히 달라진 것이 없다.

▶ 컴파일, 실행.

〔 주의 사항 〕

▶ C++함수는 C함수로 예외 처리를 넘겨서는 안됨.

C언어에서 호출되는 C++함수를 작성할 때는 C++의 예외가 C함수로 도달하지 않도록 주의.

C++의 예외가 C언어로 작성된 함수에 도달된 경우의 함수 동작에 대해 C++표준 규격에는

명확히 정의되어 있지 않다. 예를 들면 GCC에서는 프로세스가 이상 종료되는 현상이 나타남.

C++ 함수에서 명시적인 예외를 throw하지 않도록 신경 쓰는 것은 물론,

▷ 다음과 같은 점도 충분히 주의해야 한다.

º new 연산자가 std::bad_alloc 예외를 throw할 가능성

º std::vector의 멤버 함수 at에서 std::out_of_range 예외를 throw할 가능성

▶ 함수 포인터를 다루는 C함수에 주의.

C함수 내부에서 C++의 예외가 발생하는 것을 막을 수 없는 경우가 있다.

다음과 같이 표준 C의 qsort함수를 C++에서 사용한 경우를 생각해 보자.

☞ qsort 함수에 인자로 넘긴 비교함수 compar가 예외를 throw하기 때문에

qsort함수내부에서 C++의 예외가 발생하게 된다. GCC를 사용할 경우에

이와 같은 경우라도 프로세스가 이상 종료되지 않기 위해서는 아래와 같이

qsort 함수를 "-fexceptions"옵션을 지정해서 컴파일 해야 한다.

일반적으로 함수 포인터를 다루는 C함수는 -fexceptions옵션을 지정해서 컴파일해야

오류가 발생하지 않는다. glibc의 Makefile을 보면 이러한 함수(qsort, bsearch 등)는 이 옵션을

지정해서 컴파일 하도록 되어 있다.

#include <stdio.h>

void test() { }

int main() {

return 0;

}

#include <stdio.h>

void func() { }

    int main() {

    printf ("%p\n", &func);

    return 0;

}