Extremely Agile

# cd /etc/yum.repos.d
# wget http://download.openvz.org/openvz.repo
# rpm --import  http://download.openvz.org/RPM-GPG-Key-OpenVZ

# yum install ovzkernel

title OpenVZ (2.6.8-022stab029.1)
        root (hd0,0)
        kernel /vmlinuz-2.6.8-022stab029.1 ro root=/dev/sda5
        initrd /initrd-2.6.8-022stab029.1.img

# On Hardware Node we generally need
# packet forwarding enabled and proxy arp disabled
net.ipv4.ip_forward = 1
net.ipv6.conf.default.forwarding = 1
net.ipv6.conf.all.forwarding = 1
net.ipv4.conf.default.proxy_arp = 0

# Enables source route verification
net.ipv4.conf.all.rp_filter = 1

# Enables the magic-sysrq key
kernel.sysrq = 1

# We do not want all our interfaces to send redirects
net.ipv4.conf.default.send_redirects = 1
net.ipv4.conf.all.send_redirects = 0

SELINUX=disabled

# yum install vzctl vzquota

# yum install vzctl.x86_64 vzquota.x86_64

# /sbin/service vz start

# ln -s /vz/template/cache/centos-5-x86.tar.gz /vz/template/cache/centos-5.tar.gz

# vzctl create 1011

# vzctl set 1011 --hostname 1011.xxxx.re.kr --save

# vzctl set 1011 --ipadd 10.0.0.11 --save

# vzctl set 1011 --nameserver 1.2.3.4 --save

# vzctl set 1011 --userpasswd root:rootpasswd

# vzctl start 1011

# iptables -t nat -A POSTROUTING -s 10.0.0.0/24 -o eth0 -j SNAT --to 192.168.5.4

그리고 나서는 firewall 설정을 변경해줘야 합니다.

# /sbin/iptables -A RH-Firewall-1-INPUT -s 10.0.0.0/24 -j ACCEPT
# /sbin/iptables-save > /etc/sysconfig/iptables
# /sbin/service iptables restart

간혹 VE 안에서 DNS가 안되는 경우가 있는데, 그런 경우가 발생하면 강제로 DNS 포트를 개방해야합니다.

# /sbin/iptables -A RH-Firewall-1-INPUT -p udp --dport 53 -j ACCEPT

각각의 컨테이너에 프로그램을 깔때는 vzctl exec를 사용하면 편합니다.

# vzctl exec 1011 yum -y install gcc autoconf automake

# vzctl set 1011 --kmemsize $((2752512*2)):$((2936012*2)) --save

원래 글을 잘라서 쓰는 걸 좋아하지 않는데, 제가 번역이다 뭐다 좀 바빴습니다. 양해해 주세요. ^^; 오늘은 저번에 마무리 짓지 못한 나머지 부분을 써 볼까 합니다.

Kprobes에 세 가지 정도의 kernel probe가 준비되어 있다는 이야기는 했습니다. 이 중 커널로부터 뭔가 쓸만한 정보를 알아내는 데 가장 활용도가 높은 것은 Jprobe입니다. 커널 함수를 Hooking할 수 있을 뿐 아니라, 그 함수에 전달되는 인자들까지 살펴볼 수가 있거든요. Jprobe는 다음과 같이 선언합니다. 구조체죠.

#include <linux/kprobes.h>

...

static struct jprobe my_probe = {
    .kp.addr = (kprobe_opcode_t *) udp_sendmsg,
    .entry = (kprobe_opcode_t *) inst_udp_sendmsg
};

udp_sendmsg는 커널 함수의 이름입니다. inst_udp_sendmsg는 후킹 함수의 이름입니다. inst_udp_sendmsg는 udp_sendmsg가 받는 인자들을 똑같이 받도록 정의되어야 합니다. 가령 udp_sendmsg는 다음과 같이 선언되어 있습니다.

// linux/udp.h
void udp_sendmsg(struct kiocb* iocb, struct sock* sk, struct msghdr* msg, size_t len);

그러므로 inst_udp_sendmsg는 다음과 같이 정의되어야 합니다.

static void inst_udp_sendmsg(
    struct kiocb* iocb,
    struct sock* sk,
    struct msghdr* msg,
    size_t len)
{
    ...
    jprobe_return();
}

이 함수의 제일 마지막에서 jprobe_return()을 호출하고 있다는 것을 유의해 보십시다. 이 함수를 호출하지 않으면, 후킹 함수가 1회 실행된 뒤에는 (그러니까 inst_udp_sendmsg가 실행된 뒤에) 커널이 hang되어 아무 작업도 할 수 없는 상태가 되므로 주의해야 합니다.

또 한 가지 주의할 것이 있군요. Jprobe를 정의할 때 구조체의 .kp.addr에 커널 함수의 이름(다시 말해, 커널 함수의 주소, 즉 포인터)을 저장하고 있음을 보실 수 있는데요. 커널 모듈을 컴파일하다 보면 컴파일러가 "그 함수의 정의를 찾을 수 없다"는 오류 메시지를 출력하는 경우를 간혹 보게 됩니다.

그런 경우에는 함수의 이름 대신 함수의 주소를 직접 넘겨주는 방법을 쓰는 것이 제일 속편합니다. 커널에 정의되어 있는 함수들의 주소는 어디 있냐면 (inline 함수 제외) /boot 아래에 있습니다. 이 아래에 보면 System.map-2.6.18-1.2798.fc6과 같은 파일이 있는데, 이 파일을 열어보면 커널 함수들과, 그 함수들의 주소가 전부 적혀 있습니다.

그러니 사실 jprobe를 정의할 때 이렇게 해도 됩니다.

static struct jprobe my_probe = {
    .kp.addr = (kprobe_opcode_t *) 0xc05e7c29,            // 정확한 값은 아닙니다. 대충 적었습니다.
    .entry = (kprobe_opcode_t *) inst_udp_sendmsg
};

이 방법보다 좀 더 우아한 방법으로는 kallsyms_lookup_name()이라는 다른 커널 함수를 사용하는 방법도 있는데, 간혹가다가 컴파일해 보면 이 함수의 정의를 찾을 수 없다고 불평하는 메시지가 나올 때도 있습니다. -_-; 그러니 그냥 속편하게, System.map 파일을 참고하는 것이 제일 나을 것입니다.

아무튼 이렇게 하면, (1) 커널을 후킹하는 함수를 정의하고 (2) 그 함수가 특정 커널 함수 실행 직전에 실행되도록 하여 (3) 그 함수에 전달되는 인자의 값을 검사할 수 있습니다.

가령 위에서 예로 든 예제 함수의 경우, UDP 패킷의 목적지 주소를 알아내고 싶다면 다음과 같이 하면 됩니다.

static void inst_udp_sendmsg(
    struct kiocb* iocb,
    struct sock* sk,
    struct msghdr* msg,
    size_t len)
{
    struct inet_sock* up = (struct inet_sock*)sk;
    printk("destination address = %u\n", ntohl(up->daddr) );

    jprobe_return();
}

자. 그런데 JProbe를 하나 정의한 것만으로는 사실 불충분하구요. 이 프로브를 커널에 명시적으로 심어주는 register_jprobe를 호출해 주어야 비로서 프로브가 커널 함수 호출을 hooking할 수 있게 됩니다. 이 함수 호출 형식은 모든 JProbe 프로브들에 대해서 동일하니까, 다음과 같이 매크로를 정의해두면 좀 편리하게 써먹을 수 있을 것 같습니다.

#define REGISTER_JPROBE(obj) \
    do { \
        if ( register_jprobe(&obj) < 0 ) { \
            printk("registration operation for " #obj " has failed\n"); \
        } \
    } while ( 0 )

#define UNREGISTER_JPROBE(obj) unregister_jprobe(&obj)

이 매크로들은 이전 글에서 설명했던 init_module() 함수와 cleanup_module() 함수에서 다음과 같이 사용합니다.

int init_module(void)
{
    REGISTER_JPROBE(my_probe);
    ...
    return 0;
}

void cleanup_module(void)
{
    UNREGISTER_JPROBE(my_probe);
}

자. 이렇게 하면 커널 프로브를 심는 모듈을 정의하고, 사용할 수 있습니다. 생각보다 어렵지 않습니다. KProbe나 Kretprobe도 이와 비슷한 방식으로 사용이 가능합니다. 나중에 그에 관해서는 따로 소개할 기회가 있을것 같군요. 오늘은 이정도로 마무리 하겠습니다.

Kprobes는 Linux 커널을 hooking하여, 동적으로 프로브(Probe)를 심을 수 있게 해 주는 기술입니다. Solaris 진영에서는 이와 유사한 기술로 Dtrace라는 것을 제공하고 있습니다만, 아직까지는 리눅스에는 그에 필적할 정도의 커널 hooking/probing 메커니즘은 없습니다. Dtrace는 D라는 프로그래밍 언어까지 제공하고 있죠. 최근 Dprobes와 같이 좀 더 동적인 probing 기술을 개발하고 있는 것 같습니다만, 거기까지는 공부해 보지 못했습니다.

커널 후킹을 하기 위해서는 커널 모듈(kernel module)이라는 것을 만들어야 합니다. 커널 모듈을 만드는 것은 그다지 어려운 일이 아닙니다. 레드햇이라면 우선 kernel-devel 이라는 RPM이 설치되어 있어야 합니다. 그 RPM이 설치되어 있다고 치고, 다음과 같은 Makefilie을 만듭니다.

# Makefile
#
#
# make -C path/to/kernel/src M=`pwd` modules

obj-m := kprobebio.o

위의 Makefile은 kprobebio.c라는 커널 모듈 소스 코드를 컴파일하기 위한 것입니다. 이 소스 코드와 이 Makefile이 있을 때, 다음과 같이 make를 때리게 되면 이제 모듈 코드가 컴파일됩니다.

%> make  -C /lib/modules/`uname -r`/build M=`pwd` modules

모듈 코드를 만드는 것도 크게 어려운 일은 아닙니다. 다음과 같은 기본 골격을 가지면 됩니다.

#include <linux/module.h>
...
int init_module(void)
{
...
}

void cleanup_module(void)
{
...
}

MODULE_LICENSE("GPL");

init_module()은 커널 모듈을 초기화하는 작업을 정의하는 함수입니다. cleanup_module()은 반대로 커널 모듈을 메모리에서 내릴 때 필요한 정리 작업을 정의하는 함수입니다. 이 함수들을 입맛에 맞게 고쳐서, 나름대로의 커널 모듈을 정의할 수 있습니다. 컴파일이 끝난 모듈을 커널에 붙이려면 다음과 같이 하면 됩니다.

%> /sbin/insmod kprobebio.ko

이렇게 하면 커널 모듈을 커널에 붙여 돌릴 수 있습니다.

자. 이제 커널 모듈을 만드는 방법을 알았으니, 실제로 커널 모듈과 KProbes를 사용해 Linux 커널을 후킹하는 방법을 살펴보겠습니다. 그런데, 커널을 후킹하려면, 커널에 어떤 함수들이 존재하는지를 알 필요가 있습니다. 그런데, 커널에 존재하는 함수의 종류와 이름은 커널 버전마다 조금씩 차이가 나는데다 굉장히 많기 때문에, 꼼꼼히 살펴보려고 작정하고 달려들더라도 분석 자체가 힘겹습니다. 커널 소스를 받아서 설치한다고 해도, 그 코드를 vi로 일일이 브라우징하다 보면 곧 포기하게 되죠. ctags같은것을 활용하려고 해도, 코드 자체가 너무 방대해서 무리일 때가 많아요.

그러므로, 커널 소스가 올라오는 웹 사이트를 참고하는 것이 좋습니다. http://lxr.linux.no/ 같은 사이트가 그 중 가장 쓸만한 사이트입니다. 이 사이트에 접속하면 첫 화면에 Browse the code라는 섹션이 있습니다. 이 사이트에서 Linux 2.6.11 and Later 링크를 클릭하면 버전에 맞는 소스 코드를 브라우징 할 수 있습니다. 이 사이트에는 이것 말고도 다양한 버전의 OS 소스 코드가 있습니다. 이 사이트의 좋은 점은, 함수 이름에 대해 인덱스가 걸려 있어서, 링크를 따라 브라우징이 가능하다는 점입니다. 가령 어떤 함수의 실제 코드를 보고 싶으면, 그 함수가 사용된 곳에서 함수 이름을 클릭하면 됩니다. 그러면 그 함수가 정의된 곳으로 데려다 주죠. 같은 이름의 함수가 많을 경우에는 그 함수들의 목록을 보여줍니다. 그 중에서 하나를 고르면 됩니다.

각설하고, 다음은 Kprobes 관련된 자료 중 쓸만한 것들입니다.

1. kprobes를 사용한 커널 디버깅
2. Linux Technology Center: Kernel Probes
3. Kprobes를 사용한 커널 디버깅
4. Gaining insight into the Linux® kernel with Kprobes
5. Linux Kernel Documentation :: kprobes.txt

기타 커널 관련 자료들 중에 봐두면 좋을 것들
1. Linux Kernel : The linkely/unlikely macros

Kprobes 로 심을 수 있는 커널 프로브로는 Kprobe, Jprobe, Kretprobe 등이 있습니다. 이들 각각은 그 용도가 조금씩 다릅니다. Kprobe는 가장 일반적인 프로브로, 특정한 커널 함수가 호출되기 전에 호출됩니다. Jprobe는 같은 용도이긴 한데, 함수에 전달되는 인사들 까지 검사할 수 있습니다. Kretprobe는 함수의 반환값을 알아보기 위한 프로브입니다. 저는 주로 Jprobe를 사용하여 커널을 후킹하고, 함수 인자값을 검사하는 작업을 했습니다. Jprobe를 잘 활용하면, 커널에 대한 디버깅도 OS 중단 없이 해나갈 수 있습니다. prink같은 것을 코드 안에 일일이 삽입해야 할 필요도 줄어들기 때문에 더 편합니다.

다음 글에서는, 실제로 이들 프로브들을 사용해 커널을 후킹하는 방법과 그 사례를 살펴보겠습니다.