[수퍼데몬 xinetd] 데몬실행모드 두가지( standalone 과 xinetd )

1. standalone 과 xinetd 의 차이점.
구분 : xinetd 환경 서비스                         :            독립( standalone ) 서비스
의미 : xinet 수퍼데몬에 의해 제어되는        : 독립적으로 실행되는 서비스들의 데몬
: 서비스들의 데몬                             :
실행방법 : 필요할 때에 xinetd 에 의해 수행됨: 독립적인 서비스를 위하여 항상 독립적으로
:                                               : 수행됨
데몬상주여부 : xinetd 에 의해 불리워진 후에 : 독립적인 서비스를 위하여 항상 메모리에 독립
: 서비스 완료후에는 종료됨     : 데몬으로 상주해 있음.
기타 : ” /etc/xinetd.d/서비스명 ” 으로된      :
: xinetd 제어파일이 존재함                  :
접근제어 : tcpd 에 의해 접근제어됨.            : tcpd 와는 무관하지만 자체 설정파일에 의해 접근
: ( /etc/hosts.allow, /etc/hosts.deny : 제어를 할 수도 있음.
: 파일로 접근제어 설정할 수 있음.        :
참고 : 독립적으로 실행되는 데몬들도 xinetd 환경으로 변경할 수 있으며 반대로 xinetd 환경에서
: 서비스되는 데몬들도 독립적인 실행모드로 변경할 수 있음.

2. Standalone 모드

– 독립적으로 실행이 되며 항상 메모리에 상주하여 서비스요청이 있을 때 언제든 바로 응답을 함.

– 즉, 빠른 응답속도를 요하는 경우에 이 모드를 이용함.

– 단점으로는 메모리에 항상 상주해 있으므로 메모리점유로 인하여 서버부하를 줌.

– ex) httpd, sendmail, named…..

3. xinetd 모드

– xinetd 모드로 실행되는 데몬은 xinetd 라는 특별한 데몬( 인터넷 수퍼데몬 ) 에 의해 관리되며, 필요한 경우에만 메모리로 적재( load ) 되어 실행이 되어 응답을 함.

– 즉, 빠른 응답속도를 요하지않는 경우에 이 모드를 이용함.

– 단점으로는 응답속도가 standalone 보다는 상대적으로 느리다는 것이고, 장점으로는 메모리에 항상 상주해 있는 것이 아니므로 standalone 모드보다 서버부하를 상대적으로 줄일 수 있음.

4. standalone 모드로만 실행되는 데몬들도 xinetd 모드로 변경실행이 가능하며 xinetd 모드로 실행이 되는 데몬들도 standalone 모드로 서비스하는 것 또한 가능함.

5. standalone 및 xinetd 모드 설정시 고려해야 할 사항

– 얼마나 많은 서비스요청을 받는가?

– 얼마나 자주 서비스요청을 받는가?

– 메모리 점유가 얼마나 되는가?

– 보안이 필요한 경우와 비교적 그렇지 않은 경우의 분석.

6. XINETD 수퍼데몬 서비스파일 주의사항

– /etc/xinetd.d/ 디렉토리내의 서비스파일들에 등록되어 있는 데몬들이 root 계정으로 실행되고 있는 꼭 확인을 해야함. 그렇지 않다면 의심을 해보아야 함.

– /etc/xinetd.d/ 디렉토리의 각 서비스파일들이 퍼미션에서 일반유저들에게 실행은 물론이고 읽기권한까지도 빼버려야 함.

– 이 파일이 일반유저들에게 읽기 권한이 있다면 해당서버에서 어떤 서비스를 하고 있는지를 모두 알수있기 때문이며 실행파일의 위치까지도 파악이 가능함.

– 더욱 우려되는 것은 서버관리자의 실수든 해킹된 것이든 /etc/xinetd.d/ 내의 파일들에게 쓰기( write ) 권한이 설정되어 있다면 어떤 프로그램이든지 만들어서 이 파일에 등록해 두면 root 의 권한으로 실행이 가능하게 됨.

[수퍼데몬 xinetd] 인터넷 수퍼데몬( xinetd ) 이란?

1. 수퍼데몬( xinetd ) 개론

– XINETD 는 인터넷 수퍼데몬( Internet Super Daemon ) 을 의미하는 것으로서  SENDMAIL, HTTPD 등과 같이 리눅스 시스템에서 실행되는 하나의 데몬임.

– 하지만 SENDMAIL, HTTPD 등과는 달리 리눅스 서버에서 서비스되는 여러가지 데몬들을 제어하면서 각각의 서비스들의 연결을 담당하고 있음.

2. 수퍼데몬( xinetd ) 의 특징

– xinetd 는 inetd 상위버전으로 레드햇 7.0 이후 버전부터 사용됨.

– 각각의 서비스별로 별도의 파일에 설정이 가능함.( /etc/xinetd.d/* 파일들 )

– xinetd 에서 가지고 있던 접근제어기능을 가지고 있음.

– tcp_wrapper 를 내장하고 있기 때문에 접근제어를 할 수 있음.

– 접속시도 횟수로 접근제어를 할 수 있으므로 무차별 서비스거부공격( DoS )을 방지할 수 있음.

– 동일한 IP 를 가진 호스트에서 동시 접속수를 제어하여 접근제어를 할 수 있음.

– xinetd 에서 제어되는 각 서비스들에 대한 syslog 로깅 레벨 설정가능.

– 접속하는 클라이언트들의 서비스 이용시간을 기록할 수 있음.

– 서비스를 거부하거나 서비스 접근제어가 되었을 겨우에 상세로그를 기록함.

월드비전…

오늘…내가 후원하는 아동(마나나 필라)에게 편지를 썼다.

무슨 말을…어떻게 적어야 할까…

한참을 고민하고 또 고민했지만….한번 적기 시작하니..나중에는 여백이 모자랐다.

눈이 참 아름다운 아이다.

사진을 처음 봤을 때부터 정이 갔다.

처음 시작한 후원의 인연. 끝까지 이어나갈 수 있으면 좋겠다.

마나나 필라….아프지 말고 항상 건강하며 언제 어디서나 노력하는 그런 아이로 자라나길..

그리고….우리 둘 사이를 이어준 인연의 끈에 감사한다.

[로그 관리 및 분석] logrotate

logrotate.conf 샘플

logrotate의 설정디렉토리 /etc/logrotate.d/에 있는 여러개의 파일중 syslog파일의 일부이다.

물론, 이 설정을 /etc/logrotate.conf 파일내에 있어도 마찬가지 결과를 얻을 수 있다.

위의 설정을 설명하면 다음과 같다.

/var/log/messages
대상로그파일, 즉, logrotate에 의해서 작업될 로그파일을 절대패스로 지정해둔 것이다.
그리고, 그 다음의 “{” 부터 “}”까지는 이 로그파일에 대한 개별적인 설정이 된다.

monthly
대상로그파일(/var/log/messages)을 순환시킬 주기이며, monthly이므로 한달에 한번씩 이 파일이 순환(rotate)되게 된다.
뒤에서 설명하게되겠지만 참고로 순환주기에는 daily, weekly, monthly등이 있다. 이에 대한 설명은 뒤에서 자세히 다루게 된다.

compress
순환(rotate)된 파일이 gzip에 의해서 압축이 된다. 반대의 옵션은 nocompress이며 압축을 하지 않게 된다.
(기우겠지만, 순환되어 새로 생성되어 저장되고 있는 로그파일은 압축이 되지 않는다.)

rotate 2
순환되는 파일갯수를 지정한다. 0부터 시작하게되며 위의 예에서 monthly로 지정했기 때문에 2달간 로그파일이 저장되어 있게된다.

mail
순환되어 지정된 갯수를 지나게되는 로그파일은 지정된 메일주소로 메일로 보내지게 된다.
메일을 보내지 않으려면 nomail이라고 하면 된다.

errors
지정된 log파일의 logrotate작업시에 에러가 발생을 하면 지정된 메일주소로 메일을 발송하게 된다.

postrotate/endscript
이것은 지정된 로그파일에 logrotate작업이 끝나고 난 이후에 실행할 작업을 설정해둔 것이다.
대부분 이부분에 설정되는 작업은 rotate된 로그파일의 데몬을 재시작시키는 작업이다.
반대의 작업을 하려면 즉, logrotate작업 전에 실행할 작업이 있다면
postrotate/endscript대신에 prerotate/endscript를 사용하면 된다.

6. logrotate 주요옵션

(참고 : “man logrotate” 해서 보면 logrotate에 대한 옵션이 굉장히 많다. 아래에 소개해드리는 옵션은 자주사용하는 옵션이거나 필자의 견해로 보아 중요하다고 생각되는 옵션을 설명드린 것이므로 이외의 옵션에 대해서 알고자 한다면 man page를 참조바란다. )

-f, –force

강제순환시킨다. 이 옵션은 새로운 항목을 추가한 후에 로그파일을 순환시키거나 옛날 로그파일이 이미 삭제되어 새로운 로그파일이 생성되어 로그기록이 계속되고 있을 경우에 유용한 옵션이다.

-s, –state <statefile>

기본 상황파일인 /var/lib/logrotate.status 파일대신에 지정한 state파일을 사용한다.

–usage

logrotate의 기본 사용법을 간단히 보여준다.

compress

순환되는 로그파일을 gzip으로 압축하게된다. nocompress와는 반대.

nocompress

순환되는 로그파일의 압축을 하지 않는다. 반대는 compress

create mode owner group

순환되어  생성되는 로그파일의 파일퍼미션(mode)과 소유자(owner), 그리고 그룹소유자(group)를 지정한 것이다.
(예, create root 600 wheel)

daily

로그파일을 매일주기로 순환시킨다.

weekly

로그파일을 매주주기로 순환시킨다.

monthly

로그파일을 한달주기로순환시킨다.

errors address

logrotate작업시에 에러가 발생한다면 지정된 메일주소로 메일을 보내게 된다.

extension ext

logrotate 실행후에 순환되어 생성되는 파일의 이름뒤에 확장자로 붙일 확장자명을 지정한다.
만약 compress라는 옵션으로 gzip으로 압축을 했다면 gz라가 확장자 뒤에 붙게된다.
예를 들면 compress라는 옵션과 함께 “extension ext”옵션이 주어졌다면 logrotate실행후에 생성되는 파일은 messages.0.ext.gz과 같은 모양새를 갖게되는 것이다

ifempty

로그파일이 비어있는 경우에도  rotate(순환)을 하게된다. 기본값이다.

notifempty

ifempty와는 반대로 로그파일이 비어있을 경우에는 순환을 하지 않는다.

mail address

logrotate작업후에 이전로그파일을 지정된 메일주소로 메일을 보낸다. (특정한 경우의 로그파일은 보내지 않을 수도 있다. )

postrotate/endscript

logrotate작업 이후에 지정된 작업(스크립트)을 실행한다.

prerotate/endscript

logrotate작업 이전에 지정된 작업(스크립트)을 실행한다.

rotate count

logrotate의 실행결과 순환되는 파일들의 총 갯수라고 이해하자.
즉, logrotate의 결과 삭제되거나 지정된 주소로 메일로 보내지기전의 총 파일갯수라고 이해하면 된다.
그리고 rotate 0로 설정하고 나면 이전파일은 순환과 함께 삭제되어 버린다.

size size

logrotate의 결과 순환된 결과 파일사이즈가 지정한 크기를 넘지 않도록 한다.
지정하는 방법은 100k, 100M등으로 용량단위를 붙여서  지정하면 된다.