1/13/2007

[Linux] Daemon (Linux Server Security)

1. chkconfig


- chkconfig 명령을 사용해서도 서비스를 활성화하고 비활성화할 수 있다. chkconfig --list 명령을 사용하여 시스템 서비스 목록과 런레벨 0-6에서 서비스의 시작 또는 정지 여부를 볼 수 있다.

- chkconfig 명령은 xinetd가 관리하는 서비스에 즉시 적용된다. 예를 들어 xinetd가 실행 중이며 finger가 비활성화된 상태에서 chkconfig finger on 명령을 실행한다면 xinetd를 수동으로 재시작 할 필요가 없이 finger는 즉시 활성화된다.

- 하지만 다른 서비스에 대한 변경 사항은 chkconfig 사용 후 즉시 적용되지 않기 때문에 service daemon stop 명령을 사용하여 개별 서비스를 정지하거나 시작해야 한다. 여기에서 daemon은 정지할 서비스 이름이다. 서비스를 시작하거나 재시작하기 위해서는 stop을 start 또는 restart를 사용하면 된다.

- 서비스들의 상태를 확인하는 명령은 다음과 같다.

# chkconfig --list
syslog 0:off 1:off 2:on 3:on 4:on 5:on 6:off
netfs 0:off 1:off 2:off 3:on 4:on 5:on 6:off
network 0:off 1:off 2:on 3:on 4:on 5:on 6:off
random 0:off 1:off 2:on 3:on 4:on 5:on 6:off
rawdevices 0:off 1:off 2:off 3:on 4:on 5:on 6:off
pcmcia 0:off 1:off 2:on 3:on 4:on 5:on 6:off
saslauthd 0:off 1:off 2:off 3:off 4:off 5:off 6:off
keytable 0:off 1:on 2:on 3:on 4:on 5:on 6:off
gpm 0:off 1:off 2:on 3:on 4:on 5:on 6:off
autofs 0:off 1:off 2:off 3:on 4:on 5:on 6:off
iptables 0:off 1:off 2:on 3:on 4:on 5:on 6:off
irda 0:off 1:off 2:off 3:off 4:off 5:off 6:off
sshd 0:off 1:off 2:on 3:on 4:on 5:on 6:off
portmap 0:off 1:off 2:off 3:on 4:on 5:on 6:off
nfs 0:off 1:off 2:off 3:off 4:off 5:off 6:off
nfslock 0:off 1:off 2:off 3:on 4:on 5:on 6:off
sendmail 0:off 1:off 2:on 3:on 4:on 5:on 6:off
rhnsd 0:off 1:off 2:off 3:on 4:on 5:on 6:off
crond 0:off 1:off 2:on 3:on 4:on 5:on 6:off
xinetd 0:off 1:off 2:off 3:on 4:on 5:on 6:off

xinetd based services:
chargen-udp: off
rsync: off
chargen: off
daytime-udp: off
daytime: off
echo-udp: off
echo: off
services: off
servers: off
time-udp: off
time: off
sgi_fam: on

- 특정 서비스의 상태를 보려면 뒤에 서비스의 이름을 적어주면 된다.

# chkconfig --list network
network 0:off 1:off 2:on 3:on 4:on 5:on 6:off

- 특정 서비스를 삭제하거나 추가 할 때는 다음과 같이 명령을 내려주면 된다.

# chkconfig --del portmap
# chkconfig --add portmap

- 여기서 한 가지 주의할 사항은 chkconfig 명령으로 서비스를 지운다 하더라도 실제 서비스를 하는 스크립트 파일은 삭제되지 않는다는 것이다. 삭제되는 파일은 /etc/rc.d/rc[0-6].d에 있는 링크된 파일이기 때문에 실제 스크립트가 있는 /etc/rc.d/init.d에 있는 서비스 스크립트는 삭제되지 않는다.

# ls -al /etc/rc.d/* grep portmap
-rwxr-xr-x 1 root root 1898 Feb 25 2003 portmap
lrwxrwxrwx 1 root root 17 Feb 4 13:36 K87portmap -> ../init.d/portmap
lrwxrwxrwx 1 root root 17 Feb 4 13:36 K87portmap -> ../init.d/portmap
lrwxrwxrwx 1 root root 17 Feb 4 13:36 K87portmap -> ../init.d/portmap
lrwxrwxrwx 1 root root 17 Feb 4 13:36 S13portmap -> ../init.d/portmap
lrwxrwxrwx 1 root root 17 Feb 4 13:36 S13portmap -> ../init.d/portmap
lrwxrwxrwx 1 root root 17 Feb 4 13:36 S13portmap -> ../init.d/portmap
lrwxrwxrwx 1 root root 17 Feb 4 13:36 K87portmap -> ../init.d/portmap

# chkconfig --del portmap
# ls -al /etc/rc.d/* grep portmap
-rwxr-xr-x 1 root root 1898 Feb 25 2003 portmap

- 다음 명령은 특정 런레벨에서 특정 서비스를 시작하거나 정지시키는 명령이다. 런레벨은 여러 개를 같이 적어줄 수 있다.

# chkconfig --level 3 network off
# chkconfig --level 345 network on


2 xinetd


- xinetd(eXtended InterNET services daemon)은 침입에 대해 우수한 보안을 제공하며 서비스 부인(Denial of Services)공격의 위험을 감소시킨다. 이는 잘 알려진 inetd 와 tcpd 를 함께 사용하는 것과 같이 주어진 머신에 대한 접근 권한 설정을 가능케 하지만 더욱 많은 기능을 제공할 수 있다.

- xinetd는 슈퍼데몬으로서 자신이 관리하는 서비스로 연결 요청이 들어오면 해당 서비스를 깨워 연결 요청을 한 사용자에게 서비스를 하도록 해준다. 예전 inetd도 같은 기능을 하였는데 보안상 문제점이 많아 tcp _wrapper를 같이 사용하곤 하였다. 위의 그림에서처럼 xinetd는 tcp_wrapper의 기능까지 가지고 있다.

- xinetd의 기본 설정 파일은 /etc/xinetd.conf이고 xinetd가 관리하는 서비스들은 /etc/xinetd.d에 위치한다.

2.1 /etc/xinetd.conf
- /etc/xinetd.conf

defaults
{
attribute operator value(s)
...
}

- 정의된 각 속성은 이후에 기술되는 모든 서비스에 대해 제공된 값을 유지하는데 따라서 only_from 속성에 서버에 접속할 수 있는 인가된 주소들을 열거할 수 있다

only_from = 192.168.1.0/24 192.168.5.0/24 192.168.10.17

- 이후에 선언된 모든 서비스는 목록에 포함된 주소의 머신으로부터의 접근만을 허용할 것이다. 그러나 이러한 디폴트 값은 각 서비스에 대해 수정될 수 있는 반면 매우 위험하다. 사실 간단하고 안전하게 서비스를 제공하기 위해서는 디폴트 값을 정의하지 않고 각 서비스 내에서 추후 이들을 변경하는 것이 더욱 좋다.

- 예를 들면 접근 권한의 경우 가장 간단한 정책은 모든 서비스에 대한 접근을 거절하고 다음에 서비스를 원하는 이들에게만 각 서비스에 대해 접근을 허용하는 것이다. tcp_wrapper를 이용할 때 이는 ALL:ALL@ALL을 포함하는 hosts.deny 파일과 단지 인가된 서비스 및 주소를 제공하는 hosts.allow 파일을 사용해서 이루어진다.

- 설정 파일의 서비스를 기술하는 각 절은 다음과 같다:

service service_name
{
attribute operator value(s)
...
}

- ‘=’, ‘+=”과 “-=” 세 연산자가 허용 가능한데 대부분의 속성들은 이에 고정된 값을 할당하는데 사용되는 “=” 연산자만 지원한다. “+=” 연산자는 값들의 목록에 조항을 추가하는 반면 “-=” 연산자는 이 조항을 제거한다.

- ex) xinetd.conf

# cat /etc/xinetd.conf
defaults
{
instances = 60
log_type = SYSLOG authpriv
log_on_success = HOST PID
log_on_failure = HOST
cps = 25 30
only_from = 192.168.1.0/24
}
includedir /etc/xinetd.d

Flags
- IDONLY : 시별 서버를 갖는 클라이언트로부터의 접속만을 허용
- NORETRY : 실패한 경우 새로운 프로세스의 분기를 피한다
- NAMEINARGS : server_args 속성의 첫 번째 인수를 server 에 대한 argv[0] 로 사용하는데, 이는 inetd 에서와 같이 server 속성을 tcpd 로 하고 다음에 서버 이름 및 그 인수로 server_args를 써놓음으로써 tspd사용을 허용한다.

log_type
- SYSLOG selector [level] : syslogd 가 daemon, auth, user 또는 local0-7 중에서 선택할 수 있도록 한다
- FILE[max_size[absolute_max_size]] : 지정된 파일이 로깅 정보를 받는데, 두 옵션은 파일 크기 한계를 설정한다. 파일 크기가 한계값에 도달하면 우선 메시지를 syslogd에 보내고 다음에 이 서비스에 대한 로깅을 중지한다(일반적인 파일 또는 디폴트로 고정되어 있다면 다양한 서비스들이 관련될 수 있다.)

log_on_success
서버가 구동할 때 여러 가지 정보가 기록될 수 있다.
- PID : 서버의 PID(내부 xinetd 서비스라면 PID 는 0의 값을 갖는다)
- HOST : 클라이언트 주소
- USERID : 식별 프로토콜을 정의하는 RFC1413 에 따른 원격 사용자의 아이덴티티
- EXIT : 프로세스 종료 상태
- DURATION : 세션 지속 기간

log_on_failure
xinetd 는 서버가 자원 부족 또는 접근 규칙 때문에 구동할 수 없을 때 다양한 정보를 기록할 수 있다.
- HOSTID, USERID : 위와 동일
- ATTEMPT : 접근 시도를 기록하며 다른 값이 적용되자마자 실행되는 자동 옵션
- RECORD : 클라이언트에 대한 얻을 수 있는 모든 정보를 기록한다.

Nice
nice 명령어와 같이 서버 우선권을 변경한다.

no_access
이 서비스에 접근할 수 없는 클라이언트 목록

only_from
인가된 클라이언트 목록. 이 속성에 값이 부여되지 않는다면 서비스에 대한 접근이 거절된다.

port
서비스와 관련된 포트. /etc/service 파일에 정의되어 있다면 이들 포트 넘버는 서로 일치되어야 한다.

protocol
지정된 프로토콜은 /etc/protocol 파일에 존재해야 하는데 프로토콜이 지정되지 않으면 디폴트 프로토콜이 사용된다.

server
서버 경로

server_Args
서버에 주어지는 인수

socket_type
stream(TCP), dgram(UDP), raw(IP direct access) 또는 seqpacket()

type
xinetd 는 세가지 유형의 서비스를 다룰 수 있다
1. RPC : /etc/rpc 파일에 정의되어 있는데 그다지 잘 작동되지 않는다
2. INTERNAL : echo, time, daytime, chargen 및 discard 와 같은 xinetd 가 직접적으로 다루는 서비스
3. UNLISTED : /etc/rpc 또는 /etc/service파일에 정의되어 있지 않은 서비스

wait
쓰레드에 대한 서비스 동작을 정의하는데 두 가지 값이 허용될 수 있다
- yes : 단일 쓰레드 서비스로 이 유형의 접속은 단 하나만이 서비스될 수 있다.
- no : 정의된 최대 한계에 따라 각각의 새로운 서비스 요청에 대해 xinetd는 새로운 서버를 구동한다. 디폴트로 이 한계는 무제한이다.

cps
들어오는 접속 수를 제한하는데, 첫 번째 인수는 숫자 자체이다. 한계숫자를 넘을 때 두 번째 인수로 제공되는 주어진 시간(초) 동안 서비스가 비활성화된다.

instances
동시에 작동할 수 있는 동일 유형 서버의 최대수를 정의한다.

max_load
서버에 대한 최대 부하(예를 들어 2 또는 2.5)를 나타내는데, 이 한계를 넘는 경우 이 서버에 대한 요청은 거절된다.

per_source
동일 호스트로부터의 서버 접속수를 제한하는 정수 또는 UNLIMITED


2.2 /etc/xinetd.d/* (service)
- /etc/xinetd.d/* (service)

# cat /etc/xinetd.d/telnet
service telnet
{
disable = yes
flags = REUSE
socket_type = stream
wait = no
user = root
server = /usr/sbin/in.telnetd
log_on_failure += USERID
}

- xinetd.conf에서 많은 속성들의 값을 설정할 수 있는데 only_from, no_access, log_on_success, log_on_failure 등 어떤 속성들은 디폴트 절 및 각 서비스 절에 제공된 값들을 동시에 보유한다.

- IP 주소에 기초하여 머신에 대한 접근을 제어하는 only_from 과 no_access 두 속성이 있는데 우선 후자를 이용하여 다음과 설정한다.

no_access = 0.0.0.0/0

- 이는 서비스 접근을 완전히 막는다. 그러나 모든 사람에게 예를 들어 echo(ping) 접근을 허용하려면 echo 서비스를 다음과 같이 설정한다.

only_from = 0.0.0.0/0

- 다음은 이 설정을 통해 얻는 로깅 메시지이다.

Sep 17 15:11:12 charly xinetd[26686] : Service=echo-stream: only_from list and no_access list match equally the address 192.168.1.1.

- 명확하게 접근 제어가 두 속성에 포함된 주소 목록을 비교함으로써 이루어진다. 클라이언트 주소가 두 목록 모두에 일치할 때는 덜 일반적인 속성 값에 의해 접근 제어가 이루어진다. 위와 같이 속성 값이 동일한 경우 xinetd 는 접속 선택 및 거절을 할 수 없으며, 이러한 모호함을 피하기 위해서는 다음과 속성을 설정해야 한다.

only_from = 192.0.0.0/8

- 더욱 손쉬운 해결방법은 다음과 같은 속성 설정을 통해 접근 제어를 하는 것이다.

only_from =

- 속성 값을 주지 않았다고 해서 모든 접속이 실패하는 것은 아니며, 따라서 모든 서비스는 이와 동일한 속성에 의해 접근을 허용한다.

- 다음은 ftp 서비스에 대한 예제이다.

service ftp
{
socket_type = stream
wait = no
user = root
server = /usr/sbin/in.ftpd
server_args = -l
instances = 4
access_times = 7:00-12:30 13:30-21:00
nice = 10
only_from = 192.168.1.0/24
}

- 시간 제한은 물론 로컬 네트워크 상에서만 접근이 가능하도록 설정한 것이다.


3. inetd vs Standalone


- inetd 방식과 standalone 방식은 시스템의 성능 문제에 있어서 서로 상반되는 모습을 보인다.inetd는 메모리의 낭비가 적어 시스템에 무리를 주지 않지만 속도가 느리다는 단점이 있고, standalone 방식은 속도는 빠르지만 항상 프로세스가 대기를 해야 하기 때문에 서버에 부하를 많이 주게 된다. 그래서 비교적 연결 요청이 적은 TELNET이나 FTP는 xinetd를 통해서 서비스를 하고 연결 요청이 많은 HTTP는 standalone 방식으로 서비스 하는 것이 좋다.

- 만약 포털 사이트의 웹 서버가 xinetd방식이라면 사용자들은 원활한 서비스를 받을 수 없을 것이다. 그리고 FTP나 TELNET이 standalone 방식이라면 잘 사용하지 않는 프로세스가 계속 메모리만 차지하고 있어 비효율적이다. 하지만 모든 서비스가 꼭 정해져 있는 것이 아니라 관리자가 잘 판단해서 결정해야 할 것이다.