세상에 뿌려진 사랑만큼....

IEEE 802.3ad와 ECMP over OSPF같은 프로토콜을 사용하여 복수의 회선을 번갈아 가면서 쓰는 방법입니다.
님께서 질문하신 서버를 복수로 두는 것은 SLB라 합니다.
Server Load Balance....
이것은 일반 스위치에서는 안되구 L4스위치에서 가능합니다.
즉, 서버를 두개두고(물론 이 두개간은 미러가 되어야겠지요) 사용자가 접근할때
서버1,2를 번갈아 가면서 접속시키는 것입니다.

비교되는 것이 FLB로서 Firewall Load Balance입니다.
물론 방법은 같습니다.
(출처 : '네트워크 용어중에 NLB가 무엇인지요?' - 네이버 지식iN)

솔라리스 10 버전에서 IPMP는 아래처럼 기존에 IP주소가 3개를 사용했던 것과 달리 1개로 가능합니다.
실제 vmware상에서 테스트 해 본 결과 상당히 만족스런 결과를 얻었습니다. ^^
pcn interface는 공식적으로 ipmp를 지원하지 않는것으로 나와 있으나 잘 되네요..

썬에서 공식적으로 Link-Based Failure Detection 지원하는 network interface는 다음과 같습니다.
     -> hme, eri, ce, ge, bge, qfe, dmfe

Link-Based Failure Detection 지원하지 않는 네트윅 카드는 될 수 있으면 쓰지 않는게 좋겠죠?
 하지만 문제점은 링크가 끊기면 바로 failover 되버린다는것 단순히 네트윅 이중화만 되어 있다면
문제가 되지 않겠지만, Cluster가 깔린 서버라면 문제가 좀 커지겠죠? failover되는시간(DB,AP)만큼 서비스를
못하는 현상이 있을수 있습니다.
더 공부해봐야겠지만, DLPI IFF_RUNNING flag 부분을 더 삽질해서 공부하면 좋은 결과가 나올꺼라
생각됩니다 ^^
아마 기존 probe-based 방식처럼 failover 되는 시간을 수정하는 부분이 있을거라 생각됩니다. ^^
찾아보고 있으면 추가로 업뎃하겠습니다.

아래부터는 다음 카페에서 가져온 글 입니다. ^^
===========================================================================* 출처 : http://cafe.daum.net/osschool (조재구 강사님 카페, 야옹스님이 쓴 글)


기존 sol9이하버전까지는 IPMP 적용 시 failover가 실행되기 위해서는 최소 3개의 IP Address가 필요했지용...

Sol10부터는 link based Failure Detection 이라는 data link layer 점검층을 이용하여 1개의 IP Address만 사용하여도 fail over, fail back이 지원됩니다.

(기존은 방식은 probe based Failure Detection으로 application layer 점검층을 이용)

구 분  Link_based Failure Detection  Probe_based Failure Detection IPAddress수             1         3   지원 OS      Solaris 10 이상 Solaris 8 이상   점검 층       data link layer application layer   점검 방법    DLPI IFF_RUNNING flag              ICMP

아래내용은 Sunsolve에서 발췌한 내용입니다...

Most of the informations are already documented in the IP Services/IPMP part of the Solaris System Administration Guide (816-4554). This document is a short summary of failure detection types with additional/typical/recommended configuration examples using Link-based failure detection only. Even though link-based failure detection was supported before Solaris 10 (since DLPI link up/down notifications are supported by used network driver), it is now possible to use this failure detection type without any probing (probe-based failure detection).


Contents:

1. Types of Failure Detection

1.1. Link-based Failure Detection
1.2. Probe-based Failure Detection

2. Configuration Examples using Link-based Failure Detection only

2.1. Single Interface

2.2. Multiple Interfaces

2.2.1. Active-Active
2.2.1.1. Two Interfaces
2.2.1.2. Two Interfaces + logical
2.2.1.3. Three Interfaces

2.2.2. Active-Standby
2.2.2.1. Two Interfaces
2.2.2.2. Two Interfaces + logical

3. References

1. Types of Failure Detection
1.1. Link-based Failure Detection

Link-based failure detection is always enabled (supposed to be supported by the interface), whether optional probe-based failure detection is used or not. As per PSARC/1999/225 network drivers do send asynchronous DLPI notifications DL_NOTE_LINK_DOWN (link/NIC is down) and DL_NOTE_LINK_UP (link/NIC is up). The UP and DOWN notifications are used in IP to set and clear the IFF_RUNNING flag which is, in the absence of such notifications, always set for an interface that is up. Failure detection software will immediately detect changes to IFF_RUNNING. These DLPI notifications were implemented to network drivers by and by, and supported by almost all of them since Solaris 10.

With link-based failure detection, only the link between local interface and the link partner is been checked on hardware layer. Neither IP layer nor any further network path will be monitored!

No test addresses are required for link-based failure detection.

For more informations, please refer to Solaris 10 System Administration Guide:
IP Services >> IPMP >> 30. Introducing IPMP (Overview) >> Link-Based Failure Detection

1.2. Probe-based Failure Detection

Probe-based failure detection is performed on each interface in the IPMP group that has a test address. Using this test address, ICMP probe messages go out over this interface to one or more target systems on the same IP link. The in.mpathd daemon determines which target systems to probe dynamically:

all default routes on same IP link are used as probe targets.

all host routes on same IP link are used as probe targets. ( Configuring Target Systems)

always neither default nor host routes are available, in.mpathd sends out a all hosts multicast to 224.0.0.1 in IPv4 and ff02::1 in IPv6 to find neighbor hosts on the link.

Note: Available probe targets are determined dynamically, so the daemon in.mpathd has not to be re-started.

The in.mpathd daemon probes all the targets separately through all the interfaces in the IPMP group. The probing rate depends on the failure detection time (FDT) specified in /etc/default/mpathd (default 10 seconds) with 5 probes each timeframe. If 5 consecutive probes fail, the in.mpathd considers the interface to have failed. The minimum repair detection time is twice the failure detection time, 20 seconds by default, because replies to 10 consecutive probes must be received.

Without any configured host routes, the default route is used as a single probe target in most cases. In this case the whole network path up to the gateway (router) is monitored on IP layer. With all interfaces in the IPMP group connected via redundant network paths (switches etc.), you get full redundancy. On the other hand the default router can be a single point of failure, resulting in 'All Interfaces in group have failed'. Even with default gateway down, it could make sense to not fail the whole IPMP group, and to allow traffic within the local network. In this case specific probe targets (hosts or active network components) can be configured via host routes. So it is question of network design, which network path you do want to monitor.

A test address is required on each interface in the IPMP group, but the test addresses can be in a different IP test subnet than the data address(es). So private network addresses as specified by rfc1918 (e.g. 10/8, 172.16/12, or 192.168/16) can be used as well.

For more informations, please refer to Solaris 10 System Administration Guide:
IP Services >> IPMP >> 30. Introducing IPMP (Overview) >> Probe-Based Failure Detection

2. Configuration Examples using Link-based Failure Detection
An IPMP configuration typically consists of two or more physical interfaces on the same system that are attached to the same IP link. These physical interfaces might or might not be on the same NIC. The interfaces are configured as members of the same IPMP group.

A single interface can be configured in its own IPMP group. The single interface IPMP group has the same behavior! as an IPMP group with multiple interfaces. However, failover and failback cannot occur for an IPMP group with only one interface.

The following message does tell you, that this is link-based failure detection only configuration. It is reported for each interface in the group.

/var/adm/messages
in.mpathd[144]: [ID 975029 daemon.error] No test address configured on interface ce0; disabling probe-based failure detection on it

So in this configuration it is not an error, but more a confirm!ation, that the probe-based failure detection has been disabled correctly.

2.1. Single Interface

/etc/hostname.ce0
192.168.10.10 netmask + broadcast + group ipmp0 up

# ifconfig -a
ce0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 4
inet 192.168.10.10 netmask ffffff00 broadcast 192.168.10.255
groupname ipmp0
ether 0:3:ba:93:90:fc

2.2. Multiple Interfaces

2.2.1. Active-Active

2.2.1.1. Two Interfaces

/etc/hostname.ce0
192.168.10.10 netmask + broadcast + group ipmp0 up

/etc/hostname.ce1
group ipmp0 up

# ifconfig -a
ce0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 4
inet 192.168.10.10 netmask ffffff00 broadcast 192.168.10.255
groupname ipmp0
ether 0:3:ba:93:90:fc
ce1: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 5
inet 0.0.0.0 netmask ff000000 broadcast 0.255.255.255
groupname ipmp0
ether 0:3:ba:93:91:35

2.2.
1.2. Two Interfaces + logical

/etc/hostname.ce0
192.168.10.10 netmask + broadcast + group ipmp0 up \
addif 192.168.10.11 netmask + broadcast + up

/etc/hostname.ce1
group ipmp0 up

# ifconfig -a
ce0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 4
inet 192.168.10.10 netmask ffffff00 broadcast 192.168.10.255
groupname ipmp0
ether 0:3:ba:93:90:fc
ce0:1: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 4
inet 192.168.10.11 netmask ffffff00 broadcast 192.168.10.255
ce1: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 5
inet 0.0.0.0 netmask ff000000 broadcast 0.255.255.255
groupname ipmp0
ether 0:3:ba:93:91:35

2.2.1.3. Three Interfaces

/etc/hostname.ce0
192.168.10.10 netmask + broadcast + group ipmp0 up

/etc/hostname.ce1
group ipmp0 up

/etc/hostname.bge1
group ipmp0 up

# ifconfig -a
bge1: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 3
inet 0.0.0.0 netmask ff000000 broadcast 0.255.255.255
groupname ipmp0
ether 0:9:3d:11:91:1b
ce0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 4
inet 192.168.10.10 netmask ffffff00 broadcast 192.168.10.255
groupname ipmp0
ether 0:3:ba:93:90:fc
ce1: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 5
inet 0.0.0.0 netmask ff000000 broadcast 0.255.255.255
groupname ipmp0
ether 0:3:ba:93:91:35

2.2.2. Active-Standby

2.2.2.1. Two Interfaces

/etc/hostname.ce0
192.168.10.10 netmask + broadcast + group ipmp0 up

/etc/hostname.ce1
group ipmp0 standby up

# ifconfig -a
ce0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 4
inet 192.168.10.10 netmask ffffff00 broadcast 192.168.10.255
groupname ipmp0
ether 0:3:ba:93:90:fc
ce0:1: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 4
inet 0.0.0.0 netmask ff000000 broadcast 0.255.255.255
ce1: flags=69000842<BROADCAST,RUNNING,MULTICAST,IPv4,NOFAILOVER,STANDBY,INACTIVE> mtu 0 index 5
inet 0.0.0.0 netmask 0
groupname ipmp0
ether 0:3:ba:93:91:35

2.2.2.2. Two Interfaces + logical

/etc/hostname.ce0
192.168.10.10 netmask + broadcast + group ipmp0 up \
addif 192.168.10.11 netmask + broadcast + up

/etc/hostname.ce1
group ipmp0 standby up

# ifconfig -a
ce0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 4
inet 192.168.10.10 netmask ffffff00 broadcast 192.168.10.255
groupname ipmp0
ether 0:3:ba:93:90:fc
ce0:1: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 4
inet 192.168.10.11 netmask ffffff00 broadcast 192.168.10.255
ce0:2: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 4
inet 0.0.0.0 netmask ff000000 broadcast 0.255.255.255
ce1: flags=69000842<BROADCAST,RUNNING,MULTICAST,IPv4,NOFAILOVER,STANDBY,INACTIVE> mtu 0 index 5
inet 0.0.0.0 netmask 0
groupname ipmp0
ether 0:3:ba:93:91:35

*테스트 방법

# if_mpadm -d ce0

ce0 interface를 offline

ce1으로 fail over



# if_mpadm -r ce0

ce0 interface를 online

ce1에서 ce0로 fail back

개요: 100Mb 패스트이더넷 802.3 auto-negotiation를 처리하는 방법
상세설명:
htm와 qfe 100BaseT 인터페이스상에서 auto-negotiation 문제를 줄이기 위한
몇가지 처리 가이드라인과 정보는 무엇인가?

100Mb auto-negotiation 문제가 생길 때는 대개 제거 처리 문제이다.
여기에 모든 가능한 경우가 있다:

1. 좋지않은 케이블! ( 다른 환경과 nics와 케이블 길이는 다양한 결과를 야기시킬 수 있다)
2. 스위치가 802.3u auto-negotiation를 충족시키지 못해서, 속도와 듀플렉스를
일치시키고 강하게 한다.
3. Ultra Flash PROM 업데이트를 하지 않았다.
4. hme / qfe 드라이버 패치를 하지 않았다.
5. 스위치는 firmware/Version 업데이트를 요구한다.
6. 링크 파트너사이에서의 autoneg 양립 또는 패러랠 감지 문제/실패는
속도를 빠르게 하고 듀플렉스 모드를 요구한다.
7. 링크 파트너상의 100Mb 포트 하드웨어 문제 ( 스위치 - 허브 - 라우터 ).
8. Ultra 마더보드 또는 패스트이더넷 카드상의 100Mb 포트 하드웨어 문제

----------------

정보와 유의 :

케이블은 검증되고 시험된 분류 5 100Mb이여야 한다.
정상적으로 분류 5 케이블 시험기 / 한쌍(pair) 스캐너는 분류5
케이블링과 패치 패널로 설치된 100BaseT를 검사하기 위해 사용된다.

링크 속도, 모드 설정, auto-negotiation 설정을 검사하고 확인하기 위해서.
( 만약 qfe를 사용한다면 - "hme"장치가 언급된 곳을 "qfe"로 대체한다.)

# ndd -set /dev/hme instance 0
# ndd -get /dev/hme link_status
0 = link down 1 = link up
# ndd -get /dev/hme link_speed
0 = 10 Meg 1 = 100 Meg
# ndd -get /dev/hme link_mode
0 = half duplex 1 = full duplex

hme 드라이버가 autoneg와 적절한 수용능력을 알릴 준비가 되었는지 중복 검사한다.
( 모든 것이 1이여야 한다)
# ndd -set /dev/hme instance 0
# ndd /dev/hme adv_100fdx_cap
# ndd /dev/hme adv_100hdx_cap
# ndd /dev/hme adv_10fdx_cap
# ndd /dev/hme adv_10hdx_cap
# ndd /dev/hme adv_autoneg_cap

연결 파트너 능력이 어떻게 설정되느지 검사하기 위해서:

연결 파트너를 위한 파라미터들을 덤프한다

( 이 레지스터들은 연결의 다른쪽에서 받은 정보로부터 설정된다 [ 스위치, 트랜스시버..])

인스턴스 수를 설정한다 (인스턴스는 인터페이스 이름과 일치한다)
# ndd -set /dev/hme instance 0
이제 이들을 위한 파라미터 값들을 덤프하거나 획득한다:
# ndd -get /dev/hme lp_autoneg_cap
# ndd -get /dev/hme lp_100fdx_cap
# ndd -get /dev/hme lp_100hdx_cap
# ndd -get /dev/hme lp_10fdx_cap
# ndd -get /dev/hme lp_10hdx_cap

이들을 위한 값들은 파트너(당신이 플러그인한 스위치)가 알리는 것이다.
1 = enabled/capable 0 = not enabled/not capable

만약 lp_autoneg_cap 레지스터가 0이면 = 이것은 Link-partner/Hub가 802.3u auto-negotiation
adv_autoneg_cap이 사용못하거나 충족되지 않거나, 또는 감지되지 않는다는 표시이다.
firmware/patch 업그레이드를 위해 케이블링, 연결 파트너 HW, 또는 필수장비를 한곳에 모은다.

만약 연결 한쪽이 패러랠 감지에 실패하면 속도와 모드가 필요할 것이다.

# ndd -set /dev/hme instance # <--- set to the Interface in Question

( #=0 for hme0)
# ndd -set /dev/hme adv_100fdx_cap 1 <--- force ON 100Mb full duplex
# ndd -set /dev/hme adv_100hdx_cap 0 <--- force OFF 100Mb half duplex
# ndd -set /dev/hme adv_10fdx_cap 0 <--- force OFF 10Mb full duplex
# ndd -set /dev/hme adv_10hdx_cap 0 <--- force OFF 10Mb half duplex
# ndd -set /dev/hme adv_autoneg_cap 0 <--- force OFF autonegotiation
(FORCE mode)
or /etc/system:
set hme:hme_adv_autoneg_cap=0
set hme:hme_adv_100fdx_cap=1
set hme:hme_adv_100fdx_cap=1

qfe 드라이버: Quad 패스트이더넷:

같은 절차가 gfe 드라이버에 적용된다 ( substitute /dev/qfe for /dev/hme)

# ndd -set /dev/qfe adv_autoneg_cap 0

vge 드라이버: Vector Gigabit:

단지 풀-듀플렉스에서만 autonegotiation를 기본값으로 설정한다.
auto-negotiation은 꺼질 수 있다.

# ndd -set /dev/vge link_negotiation 0

ge 드라이버: GEM Gigabit:

기본값은:

adv_1000autoneg_cap : 1
adv_1000fdx_cap : 1
adv_1000hdx_cap : 1
adv_pauseTX : 0
adv_pauseRX : 1
# ndd -set /dev/ge adv_1000autoneg_cap 0
# ndd -get /dev/hme lp_autoneg_cap

만약 연결 파트너 (스위치)가 auto-negotiation를 지원하지 않는 경우에
100 Mbps에 대한 패러랠 감지를 성공한다면 그 드라이버에 의해 100 Mbps 반-듀플렉스가
선택되어야 한다. 더우기, 원하는 속도와 듀플렉스를 얻기 위해서는 속도와 듀플렉스 모두를
강하게 해야 한다(100MbFDX).

더 많은 정보는 Sunsolve 문서들과 유사한 Sun Adapter Installation와 사용자 가이드에 언급된다.

infodoc 16070 하나 이상의 hme 인터페이스를 위해 hme 파라미터를 설정하는 방법
infodoc 16728 어떻게 100baseT 이더넷 auto-negotiation이 작동하는가? 그리고 hme와 qfe 드라이브
기본값은 무엇인가?
infodoc 16144 HME 카드는 100mb에서 어떻게 작동하게 하는가(full-duplex).
srdb 16143 HME 카드는 10mb에서 어떻게 작동하게 하는가(full-duplex).
srdb 13206 네트웍 속도를 100 Mbps로 하기
srdb 12605 풀 듀플렉스는 선 이더넷 드라이버들을 지원한다.
infodoc 16017 hme 인터페이스는 10BaseT 또는 100BaseT에서 실행되고 있는가?

APPLIES TO: Operating Systems/Solaris/Solaris 2.x

Multi-processing
여러 개의 CPU에서 동시에 여러 개의 프로세스가 수행
Ex) Dual CPU

Multi-tasking
하나의 CPU에서 동시에 둘 이상의 작업을 수행
Ex) 한글을 사용하면서 동시에 웹 브라우저를 실행시킴

Multi-threading
하나의 프로세스내에서 여러 개의 스레드가 작업을 수행
Ex) 스타트를 하면서 정찰과 자원획득, 건물 건축을 동시에 수행
모든 활동들이 하나의 스레드로 작동함

Denial of Service에 대해서

1 개요

Denial of Service란 multi-tasking을 지원하는 운영체제에서 발생할 수 있는 공격 방법으로서 구체적으로 한 사용자가 시스템의 리소스를 독점(hogging)하거나, 모두 사용해 버리거나, 파괴하여서 이 시스템이 다른 사용자들에게 올바른 서비스를 제공하지 못하게 만드는 것을 말한다. 그러므로 시스템의 정상적인 수행에 문제를 야기시키는 모든 행위를 denial of service(DoS) 공격이라고 부르기 때문에 이를 위해서는 매우 다양한 방법이 존재할 수 있다. 여기서 한가지 재미 있는 사실은 이러한 DoS가 고의적으로 발생할 수도 있지만 사용자의 의도와는 상관없이 실수로 발생 할 수도 있다는 사실이다.

비록 denial of service는 시스템에 치명적인 문제(루트 권한의 획득, 시스템이나 사용자 데이타의 파괴나 변조)를 끼치지는 못하지만 시스템의 정상적인 수행에 문제(네트웍이나 시스템 서비스등의 마비)를 야기시킴으로써 사용자들의 많은 불편을 주게 된다. 그러므로 시스템 관리자들은 denial of service가 고의적으로 발생했던 실수로 발생하게 되었든 이를 재빨리 감지하여 신속히 문제를 해결함으로써 사용자들에게 적절한 서비스를 제공할 수 있게 해주어야 한다. 하지만 대부분의 denial of service공격의 특징이 공격을 감지하여 이를 막기가 매우 어렵다는 것이므로 이 공격의 심각도를 가히 인식할 수 있겠다.

참고로 이 문서에서 논의되는 denial of service는 모두 고의적으로 발생하였다고 가정함으로써 denial of service 공격(attack)과 혼용하여 사용하겠고 앞으로는 denial of service는 DoS로 줄여서 말하겠다. 여기서 예로 사용되는 소스들은 인터넷에서 얻을 수 있는 것들로써 출처가 분명한 것들은 가능하면 만든 사람의 이름을 명시하고 있다.

2 Denial of Service 공격(Attack)의 유형

대부분의 전문가들이 구분하기를 DoS공격을 다음과 같이 두가지 유형으로 나누고 있다.

*외부에서의 공격

*내부에서의 공격

DoS 공격에 있어서 관심이 되고 있는 부분은 대부분이 내부에서의 공격보다는 외부에서 공격이고 실제로 공격 방법을 살펴보면 내부에서의 공격은 간단한 스크립트 몇 줄로써도 가능한데 비해서 외부에서의 공격은 좀더 복잡하고 고도의 기술을 요하고 있다. 또한 내부에서의 공격은 이미 그 시스템에 계정을 가지고 있어야만 가능하기 때문에 DoS가 시스템의 루트 권한을 획득하는 공격법이 아니라는 것을 고려한다면 큰 의미를 가질 수 있다고 볼 수는 없다. 하지만 일반 사용자의 권한으로 시스템을 마비시킬 수 있다는 사실 자체는 관과할 수 없음에 분명하다.

2.1 내부에서의 공격

대부분의 내부에서의 공격은 시스템이 보유하고 있는 리소스를 점유하거나 모두 고갈시켜 버림으로써 가능해 진다. 실제로 이를 위해서는 간단한 C 코드나 셸 스크립트를 이용하여 가능하다. 하지만 이러한 공격 방법의 문제점은 반드시 시스템에 계정을 가지고 있어야 한다는 사실이다. 대부분의 침입자들이 시스템을 침입할 경우 일단 루트를 먼저 획득하는 데 관심을 가지기 때문에 내부에서의 공격은 사실상 고의에 의해서라기보다는 사용자들의 실수로 인해서 발생하는 경우가 대부분이라고 볼 수 있다.

아래의 간단한 예들을 통해서 DoS 공격이 어떻게 가능해지는지 살펴 보도록 하자. 주의할 점은 DoS 공격에는 아래에서 소개되는 예제 말고도 다른 수 많은 방법이 존재한다는 사실이다.

1. 디스크 채우기

아래의 방식은 임의의 파일을 만들어서 파일 시스템을 가득차게 하는 방식이다. 소스코드를 보면 알 수 있듯이 임의의 파일을 열고나서(open) 그 파일을 unlink시킨다. 이 부분에 대해서는 아래의 메뉴얼 페이지를 유심히 읽어 볼 필요가 있다.

unlink() removes the directory entry named by the pathname pointed to by path and decrements the link count of the file referred to by that entry. If this entry was the last link to the file, and no process has the file open, then all resources associated with the file are reclaimed. If, however, the file was open in any process, the actual resource reclamation is delayed until it is closed, even though the directory entry has disappeared.

unlink시킨 후에 파일의 크기를 무한정 증가시킴으로써 파일 시스템을 가득차가 함으로써 시스템을 마비 상태로 만들게 된다.

/*  Creates massive files with no Inode info, making deletion difficult */

/*  The files do not appear under du or ls b/c they have no dir entries */

/*#include <io.h>

#include <stdio.h>

#include <process.h>

*/

#include <stdio.h>

#include <sys/file.h>

void main()

{

int ifd;

char buf[8192];

ifd=open("./attckfil",O_WRONLY|O_CREAT,0777);

unlink("./attckfil");

while(1)

        write(ifd,buf,sizeof(buf));

}

해결 방안으로는 문제의 프로세스를 알아내어서 죽이는 방법뿐이다. 하지만 이 경우에 문제의 프로세스를 알아내는 것은 매우 어렵다. 왜냐하면 ps나 다른 방법을 이용하여 문제의 프로세스를 알아내려고 하여도 시스템이 거의 정상적이지 못하기 때문에 이러한 방법을 적용시키려고 하여도 잘 동작하지 않는다는 사실 때문이다. 그러므로 어쩔 수 없는 경우에는 최후의 방법으로 시스템을 다시 시작하게 하는것도 하나의 방법일 수 있다. 이 경우 프로세스가 죽게 되면 늘어났던 파일도 자연적으로 사라지게 되므로 파일 시스템이 다시 정상적으로 돌아오게 된다(이는 운영체제의 경우에 따라 차이가 있을 수 있다고 본다). 이를 위한 대비책으로 각 사용자들에 대해서 quota를 할당하는 것도 하나의 좋은 방법이 될 수 있다. 하지만 이 tmp 디렉토리와 같이 여러 사용자 프로세스들이 공동으로 사용하는 디렉토리에 이 공격을 한다면 quota를 할당하는 것 또한 무용지물이 된다.

2. 메모리 고갈

아래의 예제는 메모리 리소스를 고갈시킴으로써 시스템을 마비시키는 코드이다. 이는 실제 메모리를 모두 사용한 후에 스왑(swap) 공간까지 모두 잡아 먹다가 결국에는 몇 초 안에 시스템이 제공할 수 있는 모든 메모리를 고갈시킴으로서 심지어는 ps까지 동작하지 않게 하여 프로세스를 죽이는 일조차 하지 못하게 된다.

매우 간단한 예제이므로 쉽게 이해할 수 있을 것이고 실제로 이러한 방식의 DoS는 누구나 프로그래밍을 하다가 한번쯤은 경험할 수 있는 경우이므로 자세한 설명은 생략하겠다.

/* For information use only.  Watch as your avg. CPU and MEM use climb to */

/* new heights...                                                         */

/* daemon9@netcom.com                                                     */

#include<stdio.h>

void main()

{

char c;

while(1)

        c=malloc(1000);

}

해결방안으로는 메모리가 모두 고갈된 후에는 더 이상 메모리를 할당 받을 수 없기 때문에 다른 프로세스(ex. hanterm or xterm)를 죽여서 약간의 메모리를 확보한 다음 ps를 이용하여 문제의 프로세스를 죽이는 것이다. 하지만 이 방법이 모든 UNIX에서 가능한 것이 아니고 시스템이 따라서 완전히 죽어버리는 경우도 있음을 기억하기 바란다. 물론 문제의 프로세스를 알아내는 방법은 관리자의 재량에 맏길 수 밖에 없다. 프로세스가 죽게 되면 잡혔던(allocated) 메모리가 모두 사용 가능하게(free)되므로 다시 시스템이 정상적으로 돌아오게 된다. 이는 운영체제가 반드시 제공해야할 특징중의 하나이므로 대부분의 UNIX에서 지원되리라고 본다. 문제의 프로세스를 찾아내는 방법이 곤란할 경우 최후의 방법으로 시스템을 다시 시작하게하는 방법이 있을 수 있겠다.

3. 모든 프로세스 죽이기

아래의 예제는 존재하는 모든 프로세스를 죽이는 방법이다. 이는 init 프로세스에 SIGTERM 시그날을 보냄으로써 가능하다.

#define SIGTERM 15 /*software termination signal from kill */

이 경우는 모든 프로세스를 죽이기 위해서는 루트 권한을 가지고 있어야 한다. 그러므로 사실은 침입자가 시스템에 침입을 한 후 이미 루트 권한을 획득한 후에야 가능한 방법이다. 그러므로 이는 침입 후 사용자나 시스템의 데이타를 파괴하는 방법은 아니지만 시스템을 사용 불능상태로 만드는 방법이므로 루트 권한 획득 후 할 수 있는 일중에서 그래도 상당히 얌전한 것으로 생각 할 수도 있다.

관련되 메뉴얼의 내용은 다음과 같다.

To shut the system down and bring it up single user the super-user may send the initialization process a TERM (terminate) signal by `kill 1'; see init(8). To force init to close and open terminals according to what is currently in /etc/ttytab use `kill -HUP 1' (sending a hangup signal to process 1).

init terminates multi-user operations and resumes single-user mode if sent a terminate (SIGTERM) signal: use `kill -TERM 1'. If there are processes outstanding which are deadlocked (due to hardware or software failure), init does not wait for them all to die (which might take forever), but times out after 30 seconds and prints a warning message.

이는 다음과 같은 간단한 스크립트로써 가능해 진다.

# run as root to kill all processes

#!/bin/sh

sync

kill -15 1

해결책으로는 시스템을 다시 재 가동하는 방법이 있다.

4. 프로세스 만들기

아래의 예제는 시스템의 프로세스 테이블을 모두 고갈(full) 시킴으로써 이루어지는 공격 방법이다. 일반적으로 커널이 만들어질때 가능한 프로세스의 수를 한정시켜 놓게 되는데 이때 이 정해진 수를 넘어서게 되면 프로세스 테이블이 모두 고갈되면서 시스템의 모든 서비스가 거의 중단되게 된다. 실제로 테스트해 본 결과 시스템을 정상화시키기 위해서 재시동을 시키게 되는 상태가 되었다.

/* Will paralyze some systems */

void main()

{

        while(1) fork();

}

또는

void main()

{

        fork();

        main();

}

이 경우에는 그때그때의 상황에 따라 관리자가 능동적으로 대처하도록 하자. 한 예로 그 문제의 프로세스를 알아내어 죽이는 것인데 이 방법이 어려울 경우에는 시스템을 재시동시키는 수 밖에 없다.

앞에서 소개한 간단한 예들은 인터넷에서 쉽게 구할 수 있는 내부에서 공격에 해당되는 수많은 예들중에서 몇가지 대표적인 것만을 골라 보았다. 이 예들에서 알 수 있듯이 내부에서의 공격은 모두가 시스템이 가기고 있는 리소스를 독점하여서 문제를 야기시키고 있는데 이러한 방법들의 공통적인 문제점은 시스템의 재시동을 재외하고는 현재로서는 확실한 해결책이 없다는 것이다. 운영체제가 보다 더 안전하게(robust) 설계되는 것이 이 문제의 근본적인 해결책이라고 생각된다.

2.2 외부에서의 공격

외부에서 시도되는 DoS 공격은 내부에서의 공격과는 달리 사용자의 실수에 의해서 발생될 수도 있는 여지를 가지고 있지 않다. 이 경우에는 거의 대부분이 실제 목표로하는 시스템을 공격할 목적으로 행해지게 된다.

대부분의 외부에서의 공격은 운영체제에서 제공하는 네트웍 기능을 이용하여 이루어지게 되는데 거의 모든 경우가 특정 포트를 관찰(listen)하고 있는 프로세스를 마비시키거나 오동작하게 하여 시스템의 전체적인 네트웍 기능을 마비시키는 것이다.

외부에서의 공격을 접근 방법에 의해서 임의로 분류해 보았다. 크게 세가지로 나누어 보았는데 서로가 겹치는 부분이 있기 때문에 이 분류가 반드시 옳다고 볼 수는 없다.

응용 프로그램 수준

응용 프로그램 수준이라면 sendmail, talkd, inetd, httpd 등의 응용 프로그램의 정상적인 동작을 하지 못하게 함으로써 시스템의 네트웍 기능을 마비시키는 것이다.

1. Mail Storm(sendmail)

이 경우는 한 호스트에 계속 메일을 보냄으로서 그 호스트의 메일 시스템을 마비시는 것이다. 한 호스트에 집중적으로 메일을 보내면 시스템이 미처 메일을 처리하기도 전에 계속 메일이 오기 때문에 /var/spool/mqueue에 쌓여서 시스템의 부하를 가증시키게 된다. 결국 이로 인해서 시스템의 기능을 마비시키게 되는 것이다. Sun sendmail의 경우에는 시스템의 부하에 상관없이 계속 메일을 받지만 BSD sendmail의 경우에는 시스템의 부하가 어느 정도 올라가 메일을 받는 작업을 중단하게 되므로 가능하면 BSD sendmail을 이용하는 것을 추천하고 싶다.

메일 폭풍이 발생하였을 경우에 이를 위한 해결방안으로는 메일을 보내는 곳과 그 사용자 아이디를 알아내어서(오고 있는 메일의 머리(head)부분을 보면 이 메일이 어디서 오고 있는지를 알 수 있다) 작업을 중단시키게 하거나 현재 시스템의 메일 서비스를 중단하게 하는 방법 뿐이다. 이는 현재 실행중인 sendmail 데몬의 실행을 중단시킴으로써 가능하다.

2. Java Applet

Java applet의 경우에는 실제로 applet 자체가 클라이언트로 전송되어 동작하게 되므로 실제로 클라이언트의 CPU나 메모리를 사용하게 된다. 그러므로 침입자가 CPU나 메모리 리소스를 고갈시키는 applet을 만들어 놓았을때 이 applet이 클라이언트로 전송되어 동작하게 되면 순식간에 클라이언트는 시스템이 마비상태에 이르게 된다. 그래도 이 공격 방법은 침입자가 직접 원하는 호스트를 고르는 것이 아니라 덧을 치고 기다리는 입장이므로 클라이언트가 접속을 할 경우에만 이루어 질 수 있다. 실제로 인터넷에 이러한 applet이 많이 존재하고 있으므로 Java applet을 받아온 후 시스템이 이상한 동작을 하게되면 한번쯤 의심을 해보는 것이 좋다. 이 방법에 대해서는 뾰족한 대안이 없다고 말할 수 있겠다. 추가로 Java applet은 DoS말고도 다른 많은 보안 문제점을 가지고 있는것으로 알려져 있다. 문제점에 대해서는 Java applet의 동작원리를 이해하고 있다면 쉽게 생각해 볼 수 있을 것이다.

3. inetd

inetd 4.1 혹은 인터넷 슈퍼 서버라고도 불리는 이 데몬의 기능은 거의 모든 유닉스에서 공통적인 기능을 수행하도록 구현되어 있다. 그러므로 이 데몬을 올바로 동작하지 못하게 만들 경우에 일반적으로 그 시스템의 네트웍 기능은 거의 마비된다고 볼 수 있다. 그러므로 DoS 공격에서 이 데몬을 공격하여 기능을 상실하게 만드는 침입자는 매우 영리한 침입자라고 볼 수 도 있겠다. 실제로 Solaris 2.4에서 이 버그가 발견되기도 하여 패치가 나오기도 한 경우가 있었다.

그리고 추가로 inetd.conf에는 아래와 같은 내용을 담고 있다.

#

# Echo, discard, daytime, and chargen are used primarily for testing.

#

echo    stream  tcp     nowait  root    internal

echo    dgram   udp     wait    root    internal

discard stream  tcp     nowait  root    internal

discard dgram   udp     wait    root    internal

daytime stream  tcp     nowait  root    internal

daytime dgram   udp     wait    root    internal

chargen stream  tcp     nowait  root    internal

chargen dgram   udp     wait    root    internal

여기서 정의 되어있는 echo, discard, daytime, chargen은 위어서도 설명되어 있겠지만 테스트를 위해서 만들어져 있기 때문에 실제로는 필요하지 않으며, DoS 공격에 이용되기 쉽다. 그러므로 보안을 위해서 이 부분들을 코멘트로 처리하는 것이 좋다. 실제로 이들에 대해서 UDP 패킷 스톰(storm)에 의해 공격당하는 방법이 소개되어 CA-96.01.UDP_service_denial에서 경고하기도 하였다.

패킷 수준

응용 프로그램 수준 보다는 조금더 낮은 수준에서 이루어지는 공격 방법이 될 수 있겠는데 실제로 TCP/IP, 이더넷 층에서 이루어지는 공격방법으로 분류할 수가 있겠다. 이 경우는 실제로 이 층에서 돌아다니는 패킷들을 임의로 조작하여서 목표로 하는 시스템의 네트웍 기능을 마비시키게 하는 것이다. 이는 대부분이 운영체제의 TCP/IP 모듈을 거쳐서 정상적으로 데이타가 패킷형태로 만들어져 전송 되는것이 아니라 SOCK_RAQ(raw socket)를 이용하여 공격자가 직접 임의의 페킷을 조작하여 만들어 보내는 식으로 구현되고 있는데 여기에 대해서는 뚜렷한 대응책이 없다.

이때는 프로토콜과 네트웍 층에 심도있는 이해가 필요하므로 뛰어난 침입자의 경우에 가능한 공격법이지만 이를 위한 소스들을 인터넷이서 쉽게 구할 수 있으므로 요즘에는 초보자들에 의해서도 많이 이루어지고 있다. 이 공격의 대표적인 예로는 SYN Flooding 공격을 들 수 있다.