'snmpd'에 해당되는 글 3건

  1. 2009.05.31 시스템 및 네트워크 모니터링을 통한 보안 강화
  2. 2009.04.08 configuration file for the Net-SNMP SNMP agent (1)
  3. 2009.02.24 RRDTOOL을 이용한 모니터링 툴 CACTI (on FreeBSD)
2009. 5. 31. 16:01

시스템 및 네트워크 모니터링을 통한 보안 강화

시스템 네트워크 모니터링을 통한 보안 강화

 

 

                                            오늘과내일 넷센터 홍석범 (antihong@tt.co.kr)

 

 

1.        포트(Port) 개념과 포트 제어의 모든

2.        내부 시스템(호스트) 모니터링 소프트웨어 활용

3.        외부 시스템(네트워크) 모니터링 소프트웨어 활용

 


1.
포트의 개념과 포트 제어의 모든


시스템의
접속은 포트와 포트간의 통신이라고 정도로 포트의 의미는 매우 중요하다. 당연히 시스템의 모니터링을 위해서는 포트의 개념에 대한 이해가 매우 중요한데, 단순히 다음 파트에서 설명할 시스템 네트워크 모니터링 프로그램에 대한 사용 방법을 익히는 것도 좋지만 사전에 포트에 대한 기본적인 개념을 이해하고 있어야 각종 현상에 대한 이해 상황에 대한 즉각적인 대처가 가능하고, 또한 문제 발생시 원활히 처리를 있다.


이번
호에서는 서버를 운영하면서 자주 다루어지는 포트(Port) 개념과 포트 제어 방법에 대해 알아보도록 하겠다.

 

포트의 개념과 포트 분류의 원칙.

 

시스템간에 통신을 물리적인 전송선은 하나이지만 그것을 여러 개의 응용 프로그램들이 서로 나누어 사용하기 위해서 포트(Port) 라는 개념이 도입되었다. 시스템 내의 소켓(Socket) 사용하는 모든 프로세스는 별도의 포트 번호가 할당된 소켓을 갖게 되는데, 이것은 TCP/IP 지원하는 상위 계층의 응용 프로그램을 구분하기 위한 번호이다.


 
서버와 클라이언트간의 모든 네트워크는 일정화 규칙에 따라 포트를 이용해 통신을 하게 된다. 일반적으로 포트 번호로 16비트를 사용하며 사용 가능한 포트는 0번부터 65535 번까지인데 특히 0번부터 1023번까지를 특별히 Privileged Port 하고 1024번부터 65535 포트까지를 Unprivileged Port 라고 한다.  포트 바인딩등과 같은 소켓 프로그램을 이용하거나 80번을 사용하는 아파치 웹서버와 같이 데몬을 셋팅하여 특정한 포트를 점유하는 프로그램을 실행할 있는데, Privileged Port 영역내에 있는 포트를 이용하는 프로그램을 작동하려면 반드시 root 권한으로 작동하여야 한다. , 다른 말로 표현하면root 이외의 유저라면 1024번부터 65535번까지의 포트만을 생성(바인딩) 있는 것이다. 물론 root 권한으로는 0부터 1023 사이의 포트뿐만이 아니라 1024 포트 이후의 포트도 사용 가능하다. 그러나 root 권한으로 작동하는 대부분의 데몬들은 0번부터 1023 사이에 존재하고 1024 이후의 포트는 주로 일반 유저 권한으로 데몬을 실행하거나 클라이언트가 서버와 통신시 사용된다. 따라서 1024이후의 포트를 흔히 클라이언트 포트라고 부르기도 한다.


참고로
현재의 시스템에서 클라이언트가 사용  가능한 포트는

sysctl -a | grep local_port 확인 가능하며

sysctl -w net.ipv4.ip_local_port_range="32768 61000"  같은 명령어로 설정 변경이 가능하다.  클라이언트의 포트는 OSI 7 Layer 에서 7계층인 Application Layer 에서 결정되게 되는데, 예를 들어 브라우저를 이용해 http://www.tt.co.kr/ 이라는 서버를 접속하였다면 서버측에서는 www 포트인 80 포트가 반응하게 되고, 클라이언트에서는 브라우저에서  1024 이후의 임의의 포트를 할당하여 서로 통신이 되는 것이다.


PC
에서 telnet 이나 ftp 접속을 netstat –na 실행하여 클라이언트 PC에서 반응한 포트를 보면 1024이후의 포트에서 임의로 할당되는 것을 확인할 있을 것이다.


 
외에 Well Known Port 라는 것이 있는데, 이는 IANA 에서 TCP UDP 대해 정책적으로 할당한 포트로서 www  80,  SMTP 25,  telnet 23 등과 같이 통상적으로 약속한 프로토콜이 사용하는 포트에 대한 정의인데, 이는  /etc/services 파일에 규정되어 있다.


원리를 이용하여 아래의 문제를 풀어보도록 하자.


갑자기
서버에 과부하가 걸리고 있는 하여 ps aux 시스템의 프로세스 상황을 살펴 보니 아래와 같이 sendmail 프로세스가 많이 있는 것을 확인하였다.


그런데
, 아시다시피 sendmail 외부에서 서버로 보내어진 메일을 받는 역할(Local25 포트 작동, Foreign Unprivileged Port 작동) 내부에서 큐로 보내어진 메일을 외부로 발송하는 기능(Local Unpriviliged port 작동, Foreign 25 포트 작동) 있는데, 아래의 sendmail 프로세스는 가지 기능 전자와 같이 외부에서 내부로 보내어지고 있는 메일을 받는 프로세스일까? 아니면 후자와 같이 현재 서버에서 외부로 발송되는 메일을 처리하는 프로세스일까?
 

[root@www /root]# ps aux|grep sendmail

root      3425  0.0  0.2  2472 1256 ?        S    Aug10   0:10 sendmail: accepti

root     20818  0.0  0.2  2596 1520 ?        S    01:07   0:00 sendmail: server

root     24572  0.0  0.3  2728 1684 ?        S    01:32   0:00 sendmail: sevrer

root     24970  0.0  0.2  2596 1524 ?        S    01:34   0:00 sendmail: server

root     25811  0.0  0.2  2596 1524 ?        S    01:38   0:00 sendmail: server

root     13455  0.0  0.2  2472 1256 ?        S   Aug11   0:10 sendmail: accepti

root     23766  0.0  0.2  2344 1520 ?        S    01:07   0:00 sendmail: server

root     47932  0.0  0.2  2432 1524 ?        S    01:34   0:00 sendmail: server

root     98793  0.0  0.2  2342 1524 ?        S    01:38   0:00 sendmail: server

 

때의  해결책은

결과만으로는 없으며 아래와 같이 netstat 이용하면 된다.


Sendmail
작동한다면 Local 이든 Foreign이든 하나는 반드시 25 포트가 사용된다는 특징을 이용하면 된다. 

 

[root@www /root]# netstat -na|grep :25

tcp        0      0 0.0.0.0:25              0.0.0.0:*               LISTEN

tcp        0      0 211.47.65.56:25         211.47.66.71:3420       TIME_WAIT

tcp        0      0 211.47.65.56:25         198.6.49.12:36877       ESTABLISHED

tcp        0      0 211.47.65.56:25         211.119.130.90:3626     ESTABLISHED

tcp        0      0 211.47.65.56:25         210.121.167.112:3565    ESTABLISHED

tcp        0      0 211.47.65.56:25         210.111.91.130:4858     ESTABLISHED

tcp        0      0 211.47.65.56:25         128.134.24.193:4931     ESTABLISHED

tcp        0      0 211.47.65.56:25         211.54.29.139:1631      ESTABLISHED

tcp        0      0 211.47.65.56:25         203.25.16.2:2666        ESTABLISHED

tcp        0      0 211.47.65.56:25         211.54.29.139:1630      ESTABLISHED

tcp        0      0 211.47.65.56:25         192.198.165.17:51757    ESTABLISHED

tcp        0      0 211.47.65.56:25         210.219.250.207:2300    TIME_WAIT

tcp        0      0 211.47.65.56:25         210.106.207.100:1036    ESTABLISHED

tcp        0      0 211.47.65.56:25         134.239.84.2:4499       ESTABLISHED

tcp        0      0 211.47.65.56:25         202.119.208.10:42934    ESTABLISHED

 

결과를 보면 왼쪽에 보이는 것이 (Local)서버쪽의 IP:PORT 상태이며 오른쪽에 보이는 것이 (Foreign)원격지의 IP:PORT 상태이다. 상태를 보면 좌측의 서버(Local)측에서는 25 포트가 반응하고 있고, 우측의 원격지(Foreign)에서는 1024 이후의 포트중 임의의 포트 클라이언트 포트가 반응하고 있는 것을 확인할 있다.
 

이를 통해 현재의 상태는 외부(원격지) 에서 로컬 서버로 메일을 전송하고 있는 상태( 서버가 외부에서 발송된 메일을 받고 있는 상태)라는 것을 있다.
 

그리고 만약 아래와 같이 반대의 상황이라면 앞의 상황과는 반대로 외부의 원격지에서 25 포트가 반응하고 있으므로 내부 로컬에서 외부로 메일을 발송하고 있는 상태라는 것을 있다.

 

[root@www /root]# netstat -na|grep :25

tcp        0      0 0.0.0.0:25              0.0.0.0:*               LISTEN

tcp        0      0 211.47.65.56:38799         211.47.66.71:25       TIME_WAIT

tcp        0      0 211.47.65.56:43634         198.6.49.12:25       ESTABLISHED

tcp        0      0 211.47.65.56:43891         211.119.130.90:25     ESTABLISHED

tcp        0      0 211.47.65.56:7478         210.121.167.112:25    ESTABLISHED

tcp        0      0 211.47.65.56:1234         210.111.91.130:25     ESTABLISHED

tcp        0      0 211.47.65.56:2152         128.134.24.193:25     ESTABLISHED

tcp        0      0 211.47.65.56:3645        211.54.29.139:25      ESTABLISHED

tcp        0      0 211.47.65.56:3601         203.25.16.2:25        ESTABLISHED

 

포트 번호외에  프로토콜에 따라 TCP UDP 포트로도 분류할 있는데 telnet, sendmail, httpd 대부분의 프로토콜은 신뢰성이 보장되는 TCP 사용하나 DNS 특정 프로토콜의 경우 UDP 사용하거나 TCP UDP 함께 사용하는 경우도 있다.  UDP패킷은 TCP 패킷에 비해 헤더에 패킷의 순서에 대한 정보가 없기 때문에 패킷의 신뢰성 보다는 오버 헤드가 없고 빠른 속도를 필요로 쓰이며 시스템 이상에게 메시지를 전달하는 멀티 캐스트로 사용되기도 한다.

 

 

포트 점검 제어

 

그렇다면 내가 운영하는 서버에는 어떤 포트가 떠서 서비스 요청을 기다리고 있는지 있는 방법이 있을까?  간단히 검색하고자 하는 서버에 대해 포트 스캔을 보면 된다. 특정 포트가 반응하는지 여부는 여러 방법으로 확인 가능한데, 단순히 특정 포트로 telnet 접속하여(: telnet www.server.com 522) 접속이 되는지 여부를 확인하는 방법도 있고, 별도의 포트 스캔 전용 프로그램을 사용해도 된다. 포트 스캔을 위해 가장 권장할 만한 프로그램으로는 nmap 있는데, http://www.insecure.org/nmap/ 에서 tarball 형태의 소스를 다운로드 받아 설치하거나 http://rpmfind.net/ 에서 rpm 형태의 파일을 검색한 다운로드하여 사용하여도 된다.

nmap – p 1–65535 localhost 하면 현재 자신의 시스템에 어떤 포트가 있는지 모든 포트에 대해 확인 가능하다. 만약 아무런 옵션을 주지 않고 nmap localhost 실행하면 /etc/services 파일에 정의된 Well  Known Port 대해서만 스캔을 하게 되는 것을 주의하기 바란다.

또한 nmap -p 21,23,53,80 192.168.1.0/24 같이 스캔할 경우에는 192.168.1.0 대역( 192.168.1.1부터 192.168.1.254까지 모든 호스트) 대해  21,23,53,80 등의 특정 포트가 열려있는지에 대해서만 스캔을 하게 된다.

그런데, 스캔을 결과를 보니 자신이 못하는 이상한 포트가 있는 경우가 있다. 일반적으로 해킹을 후에는 이후에 원격에서도 쉽게 접속할 있도록 특정한 포트에 백도어를 설치하여 숨겨놓는 경우가 있으므로 백도어가 아닐까 의심하는 경우가 있는데, 포트를 사용하는 프로세스가 어떤 것인지 확인하는 방법과 포트를 죽이는 방법은 무엇일까?

.

 Port       State       Service

21/tcp     open        ftp

23/tcp     open        telnet

25/tcp     open        smtp

80/tcp     open        http

110/tcp    open        pop-3

1234/tcp   open        hotline

3306/tcp   open        mysql

4321/tcp   open        rwhois

7755/tcp   open        unknown

10101/tcp  open        unknown

 

만약 포트 스캔 결과 위와 같이 나왔을 경우 우측에 telnet, ftp 포트번호에 해당하는 서비스의 이름이 나오는데, 이는 단순히 스캔된 포트에 대하여 /etc/services 파일에 정의된 서비스명과 매치를 시켜 놓은 뿐이며  80 포트라고 해서 반드시 웹데몬이 아닐 수도 있음을 주의하기 바란다. 아울러 unknown 이라고 나온 것은 /etc/services파일에 정의되지 않은 포트이기 때문이다. 스캔 결과에서  10101 포트가 수상하여 10101 포트를 쓰고 있는 프로세스가 무엇인지 알고 싶은 경우 있는 방법은 아래와 같이 가지가 있다.

첫번째는 lsof 이용하는 방법이고, 두번째는 fuser 라는 명령어를 이용하는 방법이다.

명령어는 대부분의 시스템에서 기본적으로 이용 가능한데, 명령어가 실행되지 않으면 해당 패키지를 찾아 설치하면 된다. Lsof lsof 라는 패키지에, fuser psmisc 패키지에 포함되어 있다. 패키지는 http://rpmfind.net/ 에서 rpm 으로 다운로드 가능하다.

 

1)       lsof 이용시

lsof LiSt Open Files 약자로서 현재의 시스템에서 프로세스가 오픈하고 있는 모든 파일과 상세 정보를 보여주는데  lsof –i | grep 10101 하면 10101 포트를 사용하고 있는 프로세스를 확인할 있다. 만약 단순히 lsof 실행 파일만 다른 시스템에서 복사하여 사용하는 경우에는 –i 옵션이 제대로 작동하지 않는 수가 있는데, 이러한 경우에는  lsof > result.txt 실행하여 result.txt 파일의 결과를 참고해도 된다. 외에도 lsof 많은 다른 목적으로 사용되는 유용한 프로그램이므로 사용 방법을 익혀 두는 것이 좋다.

 

2)       fuser 이용시

fuser 특정한 파일이나 파일 시스템을 사용하고 있는 프로세스의 PID 보여주는 명령어로 fuser –n tcp 10101 같이 입력하면 10101 포트를 사용중인 프로세스ID 보여준다. 물론 UDP 포트일 경우에는 fuser –n  udp 53 같이 사용하면 된다.

이때 프로세스 ID 570번이라는 것을 확인했다면 PID 570번을 사용하는 프로세스를 확인하여야 하는데, 이는 ps 에서 보이는 결과로 확인을 하거나  ls –la /proc/570/ 결과중 exeà 가리키는 결과를 확인 하면 된다. exeà 가리키는 경로는 현재 실행 파일을 의미하며 cmdà 실행 파일이 참조하는 파일이나 디렉토리의 경로를 알려준다.

만약 exe à /home/user1/hacking/hacking* 이라고 되어 있으면 경로에 있는 파일이 10101 포트를 바인딩하고 있는 프로세스라는 것을 확인할 있다.

그리고 만약 프로세스가 정상적인 것이 아니라면 kill –9 570 (570 PID)  또는

 killall –9 –ev  hacking (hacking 프로세스 이름) 으로 해당 프로세스를 강제로(-9) 죽이면 포트도 닫히게 된다. 또는 커널 레벨에서 작동하는 패킷 필터링 툴인 ipchains(커널 2.2.X 기반) iptables(커널 2.4.X 기반) 이용하여 소스나 목적지 포트를 제어할 수도 있다.

들어오는 패킷에 대해서는 INPUT, 나가는 패킷에 대한 제어는 OUTPUT 그리고 소스 포트에 대한 제어는 –sport, 목적지 포트에 대해서는 –dport 이용하면 된다. 이를테면

# iptables –A INPUT –p tcp ! –sport 0:1023 –dport 25 –j ACCEPT

같은 경우 들어오는(INPUT) 패킷중 소스 포트가 0부터 1023 아닌(! –sport 0-1023) 1024부터 65535까지의 포트 그리고 목적지 포트는 25번인 패킷(--dport 25) 허용하겠다는 (-j ACCEPT) 의미 이다.

iptables 이용한 패킷 필터링에 대해서는 iptables 관련 문서나 글을 참고하기 바란다.

 

포트가 닫혔는지 여부는 “telnet localhost  port번호 확인하면 된다.

이외 netstat –lnp 같이 확인시에는 현재의 시스템에서 리슨(Listen)하고 있는 포트와 해당하는 프로그램의 목록을 쉽게 있다.

또한 아래의 사이트를 참조하면 특정한 포트 번호가 어떤 역할을 하는지에 대해서 상세한

정보를 얻을 있으니 특정 포트의 역할에 대해 궁금하신 분은 참고하기 바란다.

 

http://tantalo.net/ports/index.php3

http://advice.networkice.com/advice/Exploits/Ports/default.htm

http://www.chebucto.ns.ca/~rakerman/port-table.html

http://www.networksorcery.com/enp/nav0204.htm

http://www.practicallynetworked.com/sharing/app_port_list.htm

http://www.technotronic.com/tcpudp.html

 

 

 

 

 

 

 

2.     내부 시스템 모니터링 소프트웨어 활용

시스템에 문제가 발생했을 또는 발생 가능한 사고를 사전에 예방하기 위해서는 여러 가지 방법으로 시스템을 모니터링하고 또한 문제의 원인을 파악하여 문제를 해결하여야 하는 것이 시스템 관리자의 역할이다.  이번 파트에서는 간단한 명령어를 이용하여 호스트 시스템을 모니터링 있는 방법부터 각종 응응 프로그램을 이용하여 효율적으로 시스템을 모니터링하는 방법에 대해 알아보도록 하겠다.

 

간단한 명령어로 시스템 모니터링하기.

 

시스템 모니터링을 위해 가장 막강하면서도 간단한 프로그램으로는 앞에서 잠깐 설명한 netstat 있다. netstat 네트워크 연결정보, 라우팅 테이블, 인터페이스 정보등을 제공하며 그림과 같이 netstat –l 입력시 현재 시스템에서 리슨(Listen) 하고 있는 프로그램 포트 정보를 알려준다.

 


         < 그림1  netstat –l 실행 결과>

 

 

또한 SYN 패킷 요청만 보내는 서비스 거부 공격의 일종인 TCP SYN Flooding 공격(본지

7월호 SysAdmin “TCP SYN Flooding 공격의 원인과 해결책참고) 이나 아래와 같이

특정 데몬의 접속 요청을 독점해 버리는 Connect Flooding 공격도 감지 (netstat –na|grep EST) 있다.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 


     < 그림2.  Connect Flood 공격 감지 화면>

 

netstat –s 각종 프로토콜에 대한 통계를 있으며 netstat –r 라우팅 상황(route 명령어와 동일) netstat –i 인터페이스 상태를 점검(ifconfig 동일) 있다.  기타  netstat 이용 방법에 대해서는 man 페이지를 참고하기 바란다.

또는 tcpdump 사용할 수도 있다. Tcpdump 사용하여 특정 포트나 IP 에서의 패킷을 모니터링하여 패킷이 오가는지 여부를 점검하여 네트워크 장애시 문제 해결을 위해 활용할 있다.  이를테면 소스IP 192.168.1.30 고객이 서버에 접속이 된다고 한다면   tcpdump src 192.168.1.30 으로 띄워 놓은 패킷이 오가는지 접속 여부를  모니터링해  있을 것이다.

기타 tcpdump 아래와 같이 활용이 가능하다.

tcpdump port 80              # 80 포트로 오가는 패킷을 모니터링

  tcpdump src 192.168.1.1        # 192.168.1.1 소스로 하는 패킷을 모니터링

  tcpdump dst 211.3.4.5          # 211.3.4.5 목적지로 하는 패킷을 모니터링

  tcpdump host 211.3.4.5         # 소스나 목적지가 211.3.4.5 패킷을 모니터링

tcpdump net 211.3.4.0/24       # 소스나 목적지가  211.3.4.0 대역

( 211.3.4.1부터 211.3.4.254까지) 패킷을 모니터링

 

또한   tcpdump -a port 23 같이 사용할 경우에는 아래와 같이 telnet 접속을 스니핑 하는 용도로 사용될 수도 있다.

 

22:23:33.957216 eth0 > target.com.telnet > source.com.47034: P 83:90(7) ack 74 win 5792 <nop,nop,timestamp 34471591 12102054> (DF) [tos 0x10]

                          E^P ^@ ; .. w  @^@  @^F  r : .. /  A j

                         .. /  B 2 ^@^W .... ....  a ) .... ....

                         ..^X ^V..  J ~ ^@^@ ^A^A ^H^J ^B^M ....

                         ^@.. ....  l o  g i  n :

22:24:15.101414 eth0 > target.com.telnet > source.com.47034: P 102:112(10) ack 84 win 5792 <nop,nop,timestamp 34475706 12106168> (DF) [tos 0x10]

 

                          E^P ^@ > ....  @^@  @^F  r - .. /  A j

                         .. /  B 2 ^@^W .... ....  a < .... ....

                         ..^X ^V.. .... ^@^@ ^A^A ^H^J ^B^N ^N..

                         ^@.. ....  P a  s s  w o  r d  :

tcpdump  이용에 대한 추가적인 정보에 대해서는man 페이지나 http://www.tcpdump.org/ 참고하기 바란다.  추가적으로, 많이 사용하는 프로그램으로 ps 라는 명령어가 있다. Ps Process Status 약자로 시스템의 프로세스 상태를 모니터링할 있는데 주로 ps auxw 옵션을 주어 사용하면 각종 정보를 모니터링 있다. 특히 어떤 프로세스가 cpu 메모리를 많이 사용하는지 등의 정보를 확인할 있다.

netstat tcpdump 그리고 ps 명령어 사용법만 알고 있어도 대부분의 모니터링과 문제 발생시 해결을 있으며 이들 프로그램은 다른 툴의 기본이 되는 프로그램이므로 명령어의 사용법에 대해 확실히 숙지하는 것이 좋다. 

 

 포트 스캔 감지 프로그램 활용

 

원격지 시스템의 정보를 얻기 위해 공격자들이 제일 먼저 사용하는 방법이 바로 포트 스캔이다. 포트 스캔을 통해서 시스템의 열린 포트를 알아내어 어떤 서비스를 하고 있는지 있을 뿐만 아니라 운영체제, uptime 등의 정보도 얻을 있으며 정보를 토대로 시스템의 대략적인 보안 수준도 추측할 있다.  떄문에  서버 관리자 입장에서 포트 스캔을 당했다 함은 차후에 침해를 받을 있는 가능성이 있다는 것을 뜻하므로 포트 스캔을 감지하고 이에 대해 대처할 있는 프로그램을 필요로 한다.

포트 스캔을 감지하거나 차단하는 프로그램은 많이 있는데, RTSD 라는 프로그램을 추천한다. RTSD Real Time Scan Detector 약자로 한국정보보호진흥원(certcc.or.kr)에서 공개한 프로그램인데, 실시간으로 클라이언트와 서버의 포트가 상호 반응하는 관계를 보여주거나 포트 스캔으로 감지시 해당하는 내용을 관리자에게 통보해 주기도 한다.

프로그램은 http://www.certcc.or.kr/cvirc/y2kvirus/down/RTSD/register.html 에서 다운로드 가능하며 압축 해제후 Makefile rule.h 파일을 수정해 주면 된다.

Makefile 에서는 SunOS 관련 설정인 LIBS   = -lsocket -lnsl –lpcap 주석 처리하고 대신

주석되어 있는 리눅스의 #LIBS = -lpcap 주석을 삭제한다. 그리고 rule.h 파일에서는

#define IGNET "and not src net 192.168.1" 같이 스캔을 무시할 네트워크 대역을 정의하고 #define IGPORT "and not (port 80 or 110 or 20 or 21 or 25)" 같이 일반적으로 접속이 많아서 포트 스캔으로 감지하지 않을 포트를 or 나열해 주면 된다.

변경이 끝난후 make 실행하면 아래와 같이 가지를 묻게 된다.

[기관명]:-> 에는 자신의 기관이나 상호명을 입력하고(:오늘과내일)

    [스캔공격 탐지를 보고받을 E-mail 주소(Default root)]:->   포트 스캔 감지시 공격 탐지 정보를 받을 E-mail 주소를 기입하면 된다.(:antihong@tt.co.kr)

[스캔공격 탐지를 CERTCC-KR 보고하시겠습니까(Y/N, Default Y)]:->    Y 설정시에는 스캔 공격 정보를 CERTCC-KR에도 함께 발송하여 포트스캔 공격 사실을 신고하게 된다.

이후 make 생성된 RTSD 실행 파일에 –d 옵션을 주어 ./RTSD –d 실행하면 백그라운드로 작동하게 된다.

 

아래는 실제 포트 스캔을 감지시 관리자에게 발송되는 메일 예이다.

 

[01/09/26 01:02:09]
[Scan Attack] From 192.168.1.2:34814  To 210.40.65.5:2503
[Scan Attack] From 192.168.1.2:34815  To 210.40.65.5:12294
[Scan Attack] From 192.168.1.2:34816  To 210.40.65.5:6813
[Scan Attack] From 192.168.1.2:34817  To 210.40.65.5:10197
[Scan Attack] From 192.168.1.2:34818  To 210.40.65.5:8144

 

RTSD 간단하면서도 훌륭한 기능을 제공하지만, 다른 포트 스캔 감지 프로그램처럼 Passive 모드에서의 FTP 데이터 전송을 포트 스캔으로 인식하는 문제가 있으며 엄격하게 설정을 적용하였을 경우 정상적인 접속도 포트 스캔으로 간주하는 경우가 있기도 하므로 각자의 상황에 따라 모니터링후 룰을 적당히 적용하여 사용하면 된다.

이외 Inetd 모드에서 작동하는 Klaxon (http://www.eng.auburn.edu/users/doug/second.html) 이나 RTSD 비슷한 기능을 가진Scanlogd(http://www.openwall.com/scanlogd/) 그리고, 실시간으로 포트 스캔을  감지하여 Tcp Wrapper ipchains 등을 이용하여 포트 스캔을 하는 소스IP 차단하는 강력한 기능을 가진 PortSentry (http://www.psionic.com/abacus/portsentry/)  있다. 특히 PortSentry 경우 스캔을 하는 소스 IP 실시간으로 차단하는 기능이 있는데, 소스 IP 위조하여 스캔할 경우 문제가 있으니 정책 설정시 주의하여야 한다.

 

 

 

로그 모니터링 프로그램 활용

 

리눅스등 *NIX 계열이 Windows 계열에 비해 다른점은 로그에 대한 정책을 설정할 있고 많은 로그를 남길 있다는 점이다. 따라서 로그 정보를 효율적으로 모니터링하고 관리하는 것이 서버 관리자의  중요한 임무중 하나이다. 그러나 끝도 없이 쌓여가는 로그를 일일이 분석한다는 것은 거의 불가능에 가까우므로 이를 효과적으로 관리하여야 필요성이 제기된다.  이를 위해 로그를 관리해 주는 몇몇 프로그램에 대해 간단히 소개를 하겠다.

로그 모니터링 프로그램을 활용하기에 앞서 시스템에서 로그를 남기는 방식에 대해 먼저 이해를 하여야 하는데, 이에 대해서는 본지 8월호의 Focus Part2 ” 로그파일관리 자세히 소개되었으므로 로그 관련 글을 먼저 참고하기 바란다.

 

# Logcheck

Logcheck 실시간으로 로그 파일을 분석하여 사전에 해킹 시도등 비정상적인 상황이라고  정의된 내용이 로그에 남을 경우 해당 로그의 내용을 관리자에게 메일로 발송해 준다. 실시간 로그 체크는 logtail 이라는 프로그램을 이용하는데, 프로그램은 프로세스에 상주하여 실행되면서 체크한 로그 파일의 끝부분을 기억하고 있다가 새로운 로그의 내용이 추가될 때마다 계속적으로 로그 체크를 하게 된다.

Logcheck http://www.psionic.com/abacus/logcheck 에서 다운로드 하여

압축 해제 압축이 풀린 디렉토리에서 make linux 실행하면 설정 파일과 실행 파일이 자동으로 /usr/local/etc/ /usr/local/bin/ 디렉토리에 설치가 완료된다.

이후 /etc/crontab 파일에

00 * * * * root /bin/sh /usr/local/etc/logcheck.sh

같이 추가 설정하여 시간마다 logcheck 자동으로 실행하도록 한다.

이때 logcheck.sh 파일에서 SYSADMIN=antihong@tt.co.kr 부분을 이상 발생시 수신할

자신의 e-mail 주소로 변경해 주면 된다.

그리고

 /etc/logcheck/logcheck.hacking       // 해킹공격 관련 메시지

 /etc/logcheck/logcheck.ignore         // 해킹관련 로그에서 무시할 패턴

 /etc/logcheck/logcheck.violations      // 부적절한 보안관련 메시지

 /etc/logcheck/logcheck.violations.ignore // 부적절한 보안관련 로그에서 무시할 패턴

파일을 자신의 상황에 맞게 적절히 수정하여 사용하면 된다.

 

 # Swatch

Swatch 역시 Logcheck 비슷하게 로그 파일을 모니터링하다가 사용자가 지정한 패턴이 확인되었을 해당 내용을 메일로 발송하거나 벨소리를 내거나, 특정 스크립트를 실행하도록 있는 기능이 있으며 사용 방법에 대한 자세한 내용은  http://oit.ucsb.edu/~eta/swatch/ 참고하기 바란다.

 

 # Colorlog

이름에서도 있듯이 복잡한 로그 파일을 메시지의 내용에 따라 색을 다르게 하여 보여주는 프로그램으로서 사용 방법이 매우 쉽다.

 http://www.resentment.org/projects/colorlogs/ 에서 관련 파일을 다운로드하여 압축해제 colorlogs.conf 에서 모니터링할 이벤트(메시지) 색을 적절히 설정 (기본설정을 그대로 사용해도 무방하다.)  /etc/ 디렉토리로 옮긴

cat /var/log/messages | /usr/local/Colorlogs/colorlogs.pl  같이 실행하면 로그 파일에서 보안적으로 특별히 문제가 되는 부분만 다른 색으로 보여주어 로그 파일을 한눈에 쉽게 관리가 가능하다.

그리고 로그를 모니터링하여야 서버가 많을 경우 로그 서버를 별도로 운영하여 모든 로그를 서버에 몰아서 한꺼번에 관리할 수도 있다.

로그 서버를 운영하려면 먼저 로그를 보낼 서버의 /etc/syslog.conf 파일을 열어

authpriv.*      @logserver.tt.co.kr 같이 설정후 syslogd 재실행하고

로그를 받을 로그 서버에서는 별도의 설정 변경 없이  기존의 syslogd kill한 후 /usr/sbin/syslogd -m 0 -r –h 를 실행해 주면 된다. 이후 로그 서버의 /var/log/secure 를 보면 아래와 같이 여러 서버의 로그가 한꺼번에 저장되는 것을 확인할 수 있다.

 

Sep  8 18:34:50 192.168.1.30 ipop3d[544]: connect from 211.47.64.90

Sep  8 18:34:50 192.168.1.72 ipop3d[29281]: connect from 211.107.196.139

Sep  8 18:34:50 192.168.3.2 ipop3d[30311]: connect from 211.118.155.221

Sep  8 18:34:50 192.168.3.55 ipop3d[25460]: connect from 211.47.64.90

Sep  8 18:34:51 192.168.2.100 ipop3d[27111]: connect from 128.134.0.8

 

위와 같이 원격지 서버의 IP 대신 호스트 이름이 남도록 하려면 로그 서버의 /etc/hosts 파일에

 

192.168.3.55          www50

192.168.3.2           www16

와 같이 호스트 이름을 정의해 주면 IP 대신 쉽게 구분이 가능한 호스트 이름으로 남게 된다.

 

Sep  8 18:34:50 www34 ipop3d[544]: connect from 211.47.64.90

Sep  8 18:34:50 www28 ipop3d[29281]: connect from 211.107.196.139

Sep  8 18:34:50 www16 ipop3d[30311]: connect from 211.118.155.221

Sep  8 18:34:50 www50 ipop3d[25460]: connect from 211.47.64.90

Sep  8 18:34:51 www26 ipop3d[27111]: connect from 128.134.0.8

 백도어 점검하기

 

공격자들이 시스템을 공격하여 일정 권한을 획득한 후에는 차후에 다시 쉽게 들어올 있도록 자신만이 알고 있는 백도어(BackDoor) 만들어 두는 습성이 있다. 백도어는 여러 방식으로 구현 가능한데,  간단히 쉘을 복사해 두는 전통적인 방법부터 최근에는 커널 기반의 루트킷(RootKit) 까지 방식이 갈수록 교묘하고 고도화해지고 있어 백도어가 설치되어 있는지 여부를 점검하는 것이 매우 어렵다. 특히 보안에 그리 익숙하지 않은 초보 서버 관리자에게는 더더욱 그러한데, 이를 위해  아주 쉬우면서도 유용한 백도어 점검 프로그램인 chkrootkit 이라는 프로그램을 소개하고자 한다.  프로그램은 호스트내에서 t0rn 이나 라면 바이러스, 라이온 바이러스등 20여가지의 최근의 각종 루트킷 설치 여부를 점검해 주며 ifconfig, ps , netstat 변조되기 쉬운 40여가지의 바이너리 프로그램의 변조 여부를 체크해 준다.

프로그램을 이용하려면 먼저 http://www.chkrootkit.org/ 에서 최신 버전의 tarball 파일을 다운로드하여 압축 해제후 압축 해제한 디렉토리에서 make sense 실행하여 컴파일해 주기만 하면 모든 설치는 완료된다.

체크 방법은 가지로 있다. 첫번째는 chkrootkit 설치된 디렉토리에서

# ./chkrootkit 실행해 주면 자동으로 시스템을 검색하여 루트킷이나 파일 변조 여부를 알려준다.  세밀한 분석을 하고자 경우에는 # ./chkrootkit -x | more 같이 strings 이용하여 바이너리 파일을 직접 분석할 수도 있다.

또한 ./chkproc -v Hidden Process 여부도 확인 가능하다. Hidden Process 실제 프로세스에 떠서 작동하고는 있지만 ps auxw 등으로는 보이지 않는 것으로 이는 ps 에서 보이는 프로세스 정보와 /proc/pid/ 정보와 비교하여 ps 에서 보이지 않는 숨겨진 프로세스가 있는지 여부를 조사하는 방법으로 매우 유용하다. 하지만 짧은 시간에 많은 접속이 있는 웹서버등의 시스템의 경우 짧은 시간에 많은 프로세스가 죽었다 살았다를 반복하므로 잘못된 정보가 출력될 수도 있으므로 여러 실행해 보아야 한다.

 

파일 시스템 무결성 감시 프로그램

 

 # Fcheck

현재의 파일 시스템이 무결한 상태라고 판단하였을 경우 파일이나 파일 시스템의 무결성을 체크하기 위해 매번 프로그램을 실행할 수는 없다. 또한 chkrootkit 경우 일부 프로그램에 대해서만 체크를 하므로 상시적으로 모든 파일 시스템의 무결성을 체크하는 모니터링 프로그램을 필요로 하게 된다. 이러한 목적으로 파일이나 파일 시스템의 무결성을 모니터링 있는 프로그램으로는 Tripwire 가장 많이 알려져 있다.  Tripwire 설정예는 본지 9월호에서 다루어졌으므로  여기에서는 Tripwire 비해 간단한 설정으로도 막강한 기능을 제공하는 Fcheck 라는 프로그램을 소개하고자 한다.

Fcheck 지정한 디렉토리나 파일에 대한 각종 정보를 데이터베이스로 보관하고 있다가 정해진 시간마다 시스템을 체크하여 현재의 데이터 베이스 정보와 비교하여 파일 변조 여부를 모니터링하는 프로그램으로 빠른 속도와 간단한 사용 방법으로 사용을 권장하는 프로그램이다.  Fcheck http://www.geocities.com/fcheck2000/fcheck.html

 에서 다운로드하여 압축 해제후 fcheck 라는 실행 파일과 fcheck..cfg 라는 설정파일 이렇게 두개 파일만 수정해 주면 된다. 먼저 fcheck 파일에서 $config 부분을 $config="/usr/local/fcheck/fcheck.cfg"; 같이 fcheck 설치된 디렉토리로 변경하고

 

fcheck.cfg 파일을 열어

Directory = /bin/       #  무결성을 모니터링할 디렉토리

Directory = /usr/bin/   #  무결성을 모니터링할 디렉토리

Exclusion              #  모니터링을 제외할 디렉토리나 파일

Database =  /usr/local/fcheck/data/data.dbf    # 파일 시스템에 대한

데이터 베이스가 저장될 파일의 경로 

TimeZone= GMT-9     # Timezone 설정

 

과 같이 설정후 fcheck –ac 를 한번 실행해 주면 현재의 파일 시스템 정보를 데이터 베이스화 하여 지정한 파일에 저장한다. 현재의 파일 시스템 데이터베이스 정보를 근거로 이후에 변경되는 파일 시스템의 정보를 비교하므로 현재의 파일 시스템은 무결해야 한다.

아울러 /var 등과 같이 로그 파일이 있어 파일 시스템 정보가 자주 변경되는 파티션이나 파일은 모니터링할 디렉토리에 지정하지 않는 것이 좋다.  이후 fcheck –a 를 실행하면 현재의 파일 시스템 정보와 비교하여 추가나 삭제 또는 변경된 내용이 있을 경우 변경된 내용을 알려주고, 패키지 업데이트등 변경된 정보가 정상적인 경우에는 fcheck –ac 로 데이터 베이스를 업데이트 하여야 한다.

아래는 /usr/bin .hack 이라는 파일을 생성 후 fcheck –a 를 실행해 본 결과이다.

ADDITION: [www.tt.co.kr] /usr/bin/.hack

        Inode   Permissons      Size    Created On

        275505  -rw-r--r--      0       Sep 06 01:28 2001

 위와 같이 파일이 추가되었음을 알 수 있다. 파일의 정보가 변경시에는 ADDITION 대신 WARNING 이라는 메시지가 뜨고 파일이 삭제되었을 경우에는 DELETION 이라고 나타난다.

fcheck 에는 자동 메일통보등의 기능이 없으므로 이 작업을 매일 자동으로 하고 싶으면 /etc/cron.daily/ 디렉토리에 아래와 같은 실행 스크립트를 뱔도로 설정하여 실행하면 된다.

 

 

 

 

#!/usr/bin/perl

 

$TASK = `/usr/local/fcheck/fcheck -a|grep Inode`;  # 설치한 자신의 경로에 맞게 설정.

$HOSTNAME = `/bin/hostname`;

$TO_MAIL      = 'antihong@tt.co.kr';   # 이상 발견시 통보를 받을 e-mail 주소를 입력.

$SUBJECT      = "$HOSTNAME File 변조 확인";  # 통보받을 메일의 제목을 지정.

$MAIL_PROGRAM  = "/usr/sbin/sendmail";

if ($TASK){

  $TASK_CONFIRM = `/usr/local/fcheck/fcheck -a`;  #  자신의 경로에 맞게 설정.

&task_confirm;

}

sub task_confirm{

open(MAIL, "|$MAIL_PROGRAM -t");

    print MAIL "To: $TO_MAIL \n";

    print MAIL "Subject: $SUBJECT \n\n";

    print MAIL "Host: $HOSTNAME \n";

    print MAIL "$TASK_CONFIRM \n";

close(MAIL);

 }

 

위와 같이 설정 후에는 매일 자동으로 파일 시스템의 무결성을 체크하여 변경된 정보가 있을 경우에는  변경된 내용을 관리자에게 메일로 통보해 주게 된다.

만약 통보된 변화가 정상적인 것이라면 “fcheck –ac” 명령을 이용하여 데이터 베이스를 새로운 정보로 업데이트 하면 된다.

 

  # sXid

suid sgid s비트가 설정된 디렉토리나 파일은 보안상 매우 중요하다는 것을 잘 알고 있을 것이다. 따라서 suid sgid가 설정된 파일이나 디렉토리의 무결성에 대해서만 별도로 모니터링하는 프로그램을 필요로 한다면  sXid 라는 프로그램을 추천한다.

이 프로그램은 위에서 설명한 fcheck 와 작동하는 방식이 유사하다. cron을 이용하여 정기적으로 suid/sgid 를 모니터링하여 기본적으로 시스템에서 suid sgid 가 설정되어 있는  디렉토리나 파일에 어떤 변화가 있는지 체크를 한다.  파일이나 디렉토리가 새롭게 생기거나 또는 비트나 다른 모드를 변경했을 경우 sXid 는 그 변화에 대해  e-mail등으로 보고를 하게 된다.  일단 설치가 되면 자동으로 모든 일을 처리하므로 일일이 신경 쓰지 않아도 된다.

먼저 ftp://marcus.seva.net/pub/sxid/sxid_4.0.1.tar.gz 에서 파일을 다운로드 받아

압축 해제후 압축해제된 디렉토리에서 ./configure ; make ; make install 를 실행하면  설치가 완료된다.

실행 파일은 /usr/local/bin/sxid 이고 설정 파일은 /usr/local/etc/sxid.conf 인데, 특별히 변경할 부분은 없고 단지 EMAIL = “antihong@tt.co.kr부분만 정보 변경시 통지를 받을 자신의 e-mail 로 변경하면 된다.

그리고 /etc/cron.daily/ 디렉토리에

#/bin/sh

/usr/local/bin/sxid

와 같이 파일을 만들어 두면 매일 자동으로 sxid 를 실행하여 모니터링 결과를 메일로 발송해 준다.

 

패킷 모니터링 프로그램

 

앞에서 tcpdump netstat 등을 이용하여 간단히 패킷이나 세션을 모니터링하는 방법에 대해 알아보았다. 그러나 위 프로그램의 경우 직관적으로 패킷 모니터링을 하기에는 한계가 많으므로 iptraf 라는 별도의 패킷 모니터링 프로그램을 추천하고자 한다.

 Iptraf 는 작고 가벼우면서도 강력한 기능을 제공하는 프로그램으로서 네트워크에서 나가고 들어오는 모든 요청을 실시간으로 모니터링하는데, 각 호스트, 포트, 프로토콜등에 대한 세부적인 정보를 제공한다. Iptraf http://iptraf.seul.org/ 에서 파일을 다운로드후 압축을 해제하여 ./Setup 만 실행해 주면 설치가 완료된다.

설치된 디렉토리에서 iptraf 를 바로 실행하면 IP 트래픽, 인터페이스 통계, LAN station 모니터등 메뉴식으로 각종 정보를 쉽게 볼 수 있으며 프로토콜별로 필터링 기능도 제공한다. iptraf -d eth0 -B  와 같이 Background 로 작동시에는 기본적으로 /var/log/iptraf 디렉토리에 매 5분마다 각 프로토콜의 사용량, 트래픽등의 정보가 출력된다.

    < 그림3. iptraf IP Traffic 모니터 > 

 

 

 

 

 

 

 

 

 

 

 


               < 그림4. iptraf 를 이용한 프로토콜별 통계>

 

 

 

 

 

 

 

 

 

 

 

 

           < 그림5. iptraf 를 이용한 Port 별 통계>

 

            

가상 호스팅 도메인 모니터링

 

 

서버에 여러 개의 도메인을 설치하여 웹호스팅을 하는 경우 각각의 도메인에 대해

트래픽이나 하루 접속자 수등을 모니터링 해야 필요성이 제기된다.  특히 웹호스팅을 전문적으로 하는 업체에서는 필수 기능이라 있는데도 불구하고 실제로 방법이 알려져 있지 않아 일일이 수작업으로 모니터링을 하거나 아예 모니터링을 포기해야 하는 경우가 많다.  서버 전체에 대해 트래픽을 관리하려면 서버에 snmpd 데몬을 띄우고 mrtg 설치하여 모니터링하면 된다. 방법은 본지에서도 여러 소개되었으므로 관련 기사(본지 8월호 focus) 참고하시기 바란다. 아울러 서버에 여러 도메인을 설치하여 가상 웹호스팅을 서비스 하고 있는  경우 각각의 도메인에 대해 트래픽을 관리할 있는 방법은 가지가 있지만 일일이 직접 프로그램을 코딩해야 하므로 가장 쉽고 효과적인  방법으로 mod_throttle  이라는 아파치 모듈을 이용하는 방법을 추천한다.   아파치 모듈은 가상 호스트별로, 디렉토리별로, 위치(Locations)별로 또는 유저에 따라 서버의 로드를 낮추거나 대역폭을 낮추기 위해 개발되었다.  이를 통해 각각의 가상 호스팅 도메인에 대해  접속 속도를 조절하거나 일정 제한을 초과할 경우에는 접속 요청을 거부할 수도 있다.   설치를 하려면 아파치 웹서버에 모듈로 포함시키거나 정적으로 포함시켜야 하는데, 결국 아파치 컴파일을 다시 하여야 한다.

먼저 http://www.snert.com/Software/mod_throttle/mod_throttle312.tgz 에서 관련 소스 파일을 다운로드하여 압축을 해제한다.

DSO 모듈을 빌드하기 위해서는 아파치 소스 디렉토리에서 아래와 같이 한다.

cd (path to)/mod_throttle-3.1

make install

 

권장하는 방법으로, 스태틱하게 모듈을 빌드하려면 아파치 소스 디렉토리에서 컴파일시 아래와 같이 mod_throttle 모듈에 추가하도록 한다.

./configure --prefix=/usr/local/apache --activate-module=src/modules/php4/libphp4.a

--add-module=../mod_throttle-3.1.2/mod_throttle.c

  설정은 php4 mod_throttle 아파치에 모듈로 설정하는 화면이다.

아파치 컴파일을 완료한 생성된 /usr/local/apache/bin 디렉토리에서 httpd -l 실행하여 mod_throttle.c 모듈에 포함되었는지 여부를 확인한다. 모듈로 포함되었음이 확인되면

일단 설치는 완료되었으니  이제 본격적으로 httpd.conf 설정을 보도록 하겠다.

 

# 공통설정부분

<Location /throttle-status>

Order deny,allow

Deny from all

Allow from 192.168.1.0/255.255.255.0 

</Location>

위는 throttle-status 설정하였을 경우 http://domain.com/throttle-status/ 접속시 모든 도메인에 대한 트래픽이나 접속자수등의 중요한 정보가 그대로 노출되므로 throttlee-status 대해 특정 IP 대역에서만 (위의 경우 192.168.1.0 대역에서만)  접근이 가능하도록 제한하는 설정이다.

 

# 일반 설정 부분.

<IfModule mod_throttle.c>

ThrottlePolicy None          // 기본적으로는 None 으로 설정한다.

<Location /throttle-status>

SetHandler throttle-status      // throttle-me 등도 있는데, throttle-status 필요하다.

</Location>

</IfModule>

 

참고로 throttle-me http://domain.com/throttle-me/ 접속시 domain.com 이라는 하나의 도메인에 대해서만 정보를 확인할 있도록 하는 방법이다. http://domain.com/throttle-status/ 접속시에는 모든 가상 도메인에 대해 정보를 있게 된다.

 

# 가상 호스트 설정 부분. 

<VirtualHost data1.tt.co.kr)

ServerAdmin antihong@tt.co.kr

DocumentRoot /home/data/public_html

ServerName data1.tt.co.kr

ThrottlePolicy Volume 300M 1d      //하루에 전송량 300M

ThrottlePolicy Request 1000 1d       //하루에 히트수 1000 제한

ThrottleClientIP 100 volume 200 300   // 로그를 100K 남기며 300초간 200K 전송량 제한

</VirtualHost>

 

위와 같이 설정 전송량이나 히트수등을 초과하면 data1.tt.co.kr 접속시 원래의 페이지가 아닌 503 에러 화면이 뜨게 되며, ErrorDocument 503  /~user/ redirect 설정을 추가해 주면 트래픽 초과시  503에러화면 대신 /~user/index.html 파일을 보여 주도록 한다. 따라서 파일에 트래픽이나 히트수등의 초과에 대한 경고문등 적당한 메시지 화면을 만들면 된다.

 

그리고 아래와 같이 설정시에는,

 

# 일반 설정 부분.

<IfModule mod_throttle.c>

ThrottlePolicy Volume 300M 1d

<Location /throttle-status>

SetHandler throttle-status

</Location>

</IfModule>

 

# 가상 호스트 설정 부분. 

<VirtualHost data2.tt.co.kr)

ServerAdmin antihong@tt.co.kr

DocumentRoot /home/data2/public_html

ServerName data2.tt.co.kr

ThrottlePolicy Volume 500M 1d    // 하루에 전송량 500M

</VirtualHost>

 

위와 같이 설정시 별도로 제한을 설정하지 않은 모든 도메인은 하루 전송량이 1

300메가로 제한되지만 data2.tt.co.kr 500메가로 제한된다.

모든 설정에 대한 관리는 http://www.mydomain.com/throttle-status 에서 가능하며

보다 자세한 이용 방법은 http://www.snert.com/Software/mod_throttle/ 참고하기 바란다.

또한 http://www.snert.com/Software/mod_watch/ 모듈을 이용하면 기능외에 가상 도메인별로 인바운드, 아웃 바운드되는 트래픽을 mrtg 그래프로도 있다.


 

 

   < 그림5. 실제 throttle-status 작동 화면 >

 

 

 

 

 

3.외부 시스템(네트워크) 모니터링 소프트웨어 활용

호스트 기반의 보안이 운영체제에 의존하여 하나의 호스트에 대한 각종 보안 정책 모니터링 설정을 의미하는 것이라면 네트워크 보안은 운영 체제에 관계없이 네트워크 패킷에 대한 정책 설정을 의미한다. 파트에서는 개념 뿐만이 아니라 넓은 의미의 외부 시스템 보안을 포함하여 각종 네트워크 모니터링 방법에 대해 알아보도록 하자.

 

 

스니핑(Sniffing) 모니터링

 

동일 네트워크에 대형의 시스템들이 몰려있는 웹호스팅 업체나 IDC등에서는 스니핑 공격에 매우 유의하여야 한다. 취약한 하나의 시스템에서만 관리자 권한을 획득하여 스니핑을 돌린다면 전체 네트워크를 장악하는 것은 시간 문제이기 때문이다.

일반적으로 스니핑이 작동하고 있다면 인터페이스 카드가 PROMISC 모드(우리말로 무차별 모드라고 한다.) 변하게 된다.  Promisc 모드로 설정되어야 상의 모든 트래픽을 받아들일 있기 때문이다.  시스템 내부에서 스니핑이 작동하고 있는지의 여부는 단순히 ifconfig -a|grep PROMISC 이더넷 카드에 PROMISC 설정되어 있는지를 쉽게 확인할 있으나 시스템 외부에서 여부를 확인하기는 쉽지 않다.

대부분의 문서에서는 인터페이스 카드가 Promisc 설정되어 있다면 스니핑이 돌고 있다고 밝히고 있지만, 실제로 시스템에 따라 기본적으로 Promisc 설정되는 경우도 있으므로 PROSMIC 설정되어 있다고 해서 반드시 스니핑이 작동하고 있는 것은 아니다.

네트워크에서 스니핑이 작동하는지 여부를 모니터링 있는 가지 프로그램이 있는데, 추천하고 싶은 프로그램으로 Sentinel 이나 Antisniff 그리고 관련 프로그램으로 ARPWATCH 있다.

Sentinel 설치하려면 미리  패킷 캡처 라이브러리인 Libnet 1.0 libpcap 설치되어야 하는데, 각각 (http://www.packetfactory.net/Projects/libnet) (ftp://ftp.ee.lbl.gov/libpcap-0.4.tar.Z) 에서 다운로드 받아 압축 해제 압축이 풀린 디렉토리에서 ./configure; make ; make install 설치하면 된다.  그리고 Sentinel http://www.packetfactory.net/Projects/sentinel/  에서 다운로드 가능하며 다운로드하여 압축 해제   압축이 풀린 디렉토리에서 make all 컴파일하여 설치하면 된다.  현재 Sentinel 원격지 시스템에서 스니핑이 작동하는지 여부를 감지하는 방법은 3가지가 있는데,  방법은 각각 DNS test,  Etherping test,  ARP test이다.

 

먼저 각각의 방법이 가능한 원리에 대해 간단히 살펴보면, 우선 DNS test 경우 목적지 서버에 위조된 연결 요청을 보내어, 일반적인 스니핑 프로그램이 요청받은 시스템의 IP 주소를 역리졸브(Inverse DNS lookup) 한다는 특징을 이용하여 DNS 트래픽을 감시하여 스니핑을 감지하는 방법이다.

Etherping test 목적지에 ping 보낼 목적지의 IP 맞지만 목적지의MAC 주소는 존재하지 않는 정보로 하여 Icmp Echo Packet 보내어 응답이 오는지를 감시하는 방법으로 대부분의 정상적인 시스템에서는 MAC 정보가 올바르지 않기 때문에 패킷을 DROP 하지만 promiscuous mode 설정된 시스템에서는 응답을 한다는 특징을 이용하여 감시하는 방법이다.  마찬가지로 ARP test 역시 IP 맞지만 목적지의 MAC 주소를 다르게 하여 ARP 요구를 보내는 방법으로 Promisc 모드가 아닌 경우에는 패킷이 목적지까지 없으므로 목적지에서는 응답하지 않지만 Promisc 모드인 경우에는 모든 패킷을 받아들이므로 결국 응답한다는 특징을 이용하여 감시하는 방법이다.

각각의 방식에 대한 실행 방법예는 아래와 같다.

 

./sentinel -a -t 192.168.1.2                 # ARP 테스트

./sentinel -d -f 1.1.1.1 -t 192.168.1.2         # DNS 테스트

./sentinel -e -t 192.168.1.2                 # Etherping 테스트

./sentinel -t 192.168.1.2 -f 1.1.1.1 -d -a –e     # 3개의 테스트를 동시에  수행

 

위와 같이 실행시

Results: 192.168.1.2 tested positive to etherping test.

같이 탐지 결과가 positive 나오면  Promisc 모드로 설정되었다는 의미이므로 해당 인터페이스의 PROMISC 여부를 조사하여야 한다.

 

아울러 Antisniff 경우 http://www.securitysoftwaretech.com/antisniff/ 에서 다운로드 가능하며 리눅스 버전과 아울러 윈도우 버전의 프로그램도 이용 가능하다. 테스트 방법은 위의 Sentinel 비슷하며 추가적으로 Latency test 라는 방법이 있는데, 방법은 스니핑이 작동시 무차별 모드로 설정되어 있어 로컬 네트워크상의 모든 트래픽을 받아들이느라 로드가 높아진다는 점을 이용해 불필요한 트래픽을 전송하여 시스템의 응답 시간이 길어지는지 여부를 조회하는 재미있는(?) 방법으로 아직까지는 100% 신뢰할 수는 없는 방법이며 계속적으로 개선중인 기능이다.

 

윈도우 버전의 경우 테스트하는 IP 대역을 지정하여 한꺼번에 검사가 가능하고  검사 결과에 대해 각종 통계도 있으며, 얼마의 주기로 테스트를 것인지를 시간대별, 날짜별, 주별로 정할 있는 예약 기능 검사 결과가 변경시 메일로 발송하거나 음악이 나오게 하는 등의 알람 기능도 있어 편리하게 사용이 가능하다.

 


                  < 그림6. Antisniff 이용한 체크결과 화면>

 

 

 

끝으로 이와 관련하여 권장할 만한 프로그램으로 ARPWATCH 있다.

프로그램은 ARP 트래픽을 모니터링하여 MAC 주소와 IP 매칭을 감시하는 프로그램으로 정보가 변경되거나 새로운 MAC 주소가 확인시에는 해당하는 내용을 관리자에게 메일로 통보하게 된다. ARPWATCH 이용시 MAC 주소나 ARP 이용하는 공격에 대한 대응에 매우 유용하다.  ARPWATCH 패킷 캡처 라이브러리인 libpcap 사용하므로 먼저 ftp://ftp.ee.lbl.gov/libpcap.tar.Z  파일을 다운로드하여 압축 해제후 ./configure; make ; make install libcap 프로그램을 설치한다. 설치되지 않으면 http://rpmfind.net/ 에서 rpm 으로 다운로드하여 설치도 가능하다. 라이브러리가 설치되면  ftp://ftp.ee.lbl.gov/ 에서 arpwatch 프로그램을 다운로드 하여 압축 해제 설치 전에 addresses.h 파일을 열어 

#define WATCHER "antihong@tt.co.kr"

#define WATCHEE "arpwatch (Arpwatch)"

같이 변경된 ARP 정보 발견시 메일을 수신할 e-mail 주소와 발송시 발신자 정보를 정의한다.  변경 압축 해제한 디렉토리에서 ../configure; make ; make install 설치를 하면 된다.

 설치 이후 같은 디렉토리에서 touch arp.dat 파일을 생성 ./arpwatch –d 실행하면 현재 네트워크의 MAC 정보와 IP 정보를 매칭하여 arp.dat 파일에 데이터 베이스쌍을 생성한다.

데이터 베이스 생성이 완료된 ./arpwatch 실행하여 두면 실시간으로 ARP 트래픽을 체크하여 새로운MAC 정보가 추가되거나 MAC 정보가 변경되는 현재의 데이터 베이스 정보와 다른 정보가 발견 시에는 앞에서 지정한 관리자에게 해당하는 내용에 대해 통보를 하고 데이터 베이스를 갱신하게 된다.

아래는 MAC 정보가 변경시 관리자에게 메일로 통보된 내용의 예이다.

 

     hostname: arp.tt.co.kr

     ip address: 192.168.1.1

     ethernet address: 0:0:1c:2:38:18

     ethernet vendor: JDR Microdevices generic, NE2000 drivers

     old ethernet address: 0:50:bf:30:fe:50

     old ethernet vendor: <unknown>

     timestamp: Monday, April 23, 2001 21:49:08 +0900

     previous timestamp: Monday, April 23, 2001 20:11:47 +0900

     delta: 1 hour

 

 

 네트워크에서 특정 문자열 탐지하기

 

얼마전까지 많은 서버에 피해를 주었던 코드레드 바이러스는 Windows NT Windows 2000  IIS 서버만 공격하는 것으로 알려져 있지만 실제로 웹서버의 버전과는 관계 없이 80 포트로 무차별적인 접속시도를 하여 기반의 스위칭이나 라우터등 일부 네트워크 장비가  다운 되는 등의 문제가 있었다. 또한 아파치 서버의 경우 로그를 남겨 놓았을 경우 서버에 많은 로그를 남기어 디스크가 Full 되는 경우도 있었다. 코드 레드의 경우 서버의 로그 파일을 보면 공격지 IP 확인할 있지만 일일이 서버의 로그파일을 남기거나 분석하지 않고도 네트워크상에서 특정 문자열로 탐지가 가능하다.

이는 ngrep 이라는 툴을 이용하면 된다.   ngrep 네트워크에 전송되는 트래픽에서 특정

문자열이나 텍스트만을 검색하는 막강한 기능을 가진 프로그램으로 코드 레드의 경우  기본

적으로 default.ida 파일을 요구하므로 문자열을 요구하는 패킷을 검색하면 된다.

 

# ngrep -qt ".ida\?" tcp port 80

 2001/09/05 18:50:34.514746 211.192.184.151:3441 -> 211.40.15.176:80 [A]

  GET /default.ida?XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

 

위의 경우 211.192.184.151 에서 211.40.15.176 서버로 코드레드 시도를 하고 있는 것을 있다.   이처럼 ngrep 네트워크상의 패킷에서 특정 문자열만을 뽑아냄으로써 이를 응용한다면 모든 네트워크 모니터링 프로그램이 그러하듯이 막강한 스니핑 툴로도 악용이 가능하다.  만약 네트워크상에서

# ngrep  -wi  'user|pass'  tcp port 110 같이 입력하였다면 잠시 아래와 같이

interface: eth0 (211.40.165.43/255.255.255.0)

filter: ip and ( tcp port 110 )

match: ((^user|pass\W)|(\Wuser|pass$)|(\Wuser|pass\W))

 

T 61.73.202.236:26129 -> 211.40.165.43:110 [AP]

  USER admin..

 

T 61.73.202.236:26129 -> 211.40.165.43:110 [AP]

  PASS qwert!23a..

 

pop3 접속하는 Id /pw 그대로 노출되는 것을 확인할 있을 것이다. 물론 위와 같이 110 외에 다른 Port 스니핑도 가능하다. Ngrep 패킷 라이브러리를 사용하므로 프로그램 설치에 앞서 앞에서 설명한 libpcap 먼저 설치한

http://www.packetfactory.net/projects/ngrep/ 에서 ngrep 다운로드하여 압축 해제후 압축 해제한 디렉토리에서 ./configure; make  설치하면 된다. 또는 http://rpmfind.net/ 에서 rpm 형태의 파일을 직접 다운로드하여 설치하여도 된다.

# ngrep -q 'sex|porno' 같이 실행 시에는 네트워크내 패킷에서 sex porno 라는 문자열이 포함된 트래픽을 찾아주는 여러 가지로 활용이 가능하니 구체적인 이용에 대한 안내는 홈페이지를 참고하기 바란다.

 

 mrtg 메일서버 모니터링 하기

 

mrtg 이용하여 서버나 라우터의 트래픽이나 데이터 전송량을 모니터링 하는 방법은 많이 소개되었으니 이번에는 메일 서버에서 각종 정보를 mrtg 통계내어 확인하는 방법을 살펴보도록 하자. 일단 메일 서버의 각종 통계 데이터는 sendmail 에서 제공하는 mailstats 라는 프로그램을 이용하면 되는데, mailstats /var/log/sendmail.st 파일을 참고하므로 sendmail.cf 에서 설정이 주석 처리되지는 않았는지 확인하여 주석이 되어있으면 주석을 제거하고,  /var/log 디렉토리에 sendmail.st 파일을 생성한 sendmail 재시작해 주면 파일에 관련 정보가 생성된다.

그리고 메일서버의 정보를 mrtg 보려면 mrtg-mailstatus 라는 별도의 프로그램을 필요로 하는데, 프로그램은 http://www.infocom.com/~littell/software/mrtg-mailstats.html 에서 관련 파일을 다운로드하여 설치 아래와 같이 mrtg 위한 cfg 파일을 만든 mrtg 실행해 주면 된다.

 

# 설정은 하루에 전송되는 smtp.tt.co.kr 서버의 메일개수를 mrtg 보여준다.

 

Target[mail.tt.co.kr]:`/usr/local/mrtg/mrtg-mailstats -s smtp.tt.co.kr`

Title[mail.tt.co.kr]: E-mail 개수

YLegend[mail.tt.co.kr]: Sent mail number

 

# 이 설정은 smtp.tt.co.kr 서버의 하루전송 메일 트래픽을 mrtg 로 보여준다.

Target[mail.tt.co.kr]: `/usr/local/mrtg/mrtg-mailstats -b -s smtp.tt.co.kr -p 2525`
MaxBytes[mail.tt.co.kr]: 1250000
Title[mail.tt.co.kr]: Remote Mail Traffic
PageTop[mail.tt.co.kr]: <H1>Remote Mail Traffic</H1>

 

그리고 메일 서버에서는 /etc/services 파일에

smtp-stats      2525/tcp        snmp-stats 추가하고

/etc/inetd.conf

smtp-stats      stream  tcp     nowait  nobody  /usr/sbin/tcpd       /usr/sbin/mailstats

같이 추가하면 된다.

설정이 끝난 5 간격으로 정기적으로 실행하여 주기 위해 /etc/crontab 파일을 열어

0-59/5 * * * * root run-parts /usr/local/mrtg/run/mrtg  mail.cfg  같이 추가해 주면 5분마다 자동으로 실행하여 아래와 같이 그래프를 생성하게 된다. 아래의 경우 하루 평균 5000여통이 메일이 전송되고 있는 것을 있다.

기타 Mrtg 사용방법에 대해 궁금하신 분은 본지 8월호 part3 “시스템 모니터링과 자동화하기 참고하거나  http://www.mrtg.org/ 또는  http://www.mrtg.co.kr/ 참고하기 바란다..

 


 

    < 그림7. 전송되는 메일 개수를 mrtg 화면>

 

 

 mrtg 로 네트워크 속도 모니터링하기

 

추가적으로, mrtg 를 활용하여 특정 네트워크와의 접속 속도등을 모니터링하는 방법을 알아보도록 하자. 이를 위해서는  mrtg-ping-probe 라는 별도의 프로그램을 사용하면 되는데, 이 프로그램을 이용하면 특정 호스트 사이의 ping 소요 시간, 패킷 로스등을 그래프로 볼 수 있다. 이 프로그램은 http://pwo.de/projects/mrtg/  에서 해당 파일을 다운로드 후 압축 해제하여 아래와 같이 mrtg 위한 cfg 파일을 만든 역시 mrtg 실행해 주면 된다.

 

Title[www.bora.net]: ping

MaxBytes[www.bora.net]: 5000

AbsMax[www.bora.net]: 10000

Target[www.bora.net]:`/usr/local/mrtg/mrtg-ping/mrtg-ping-probe www.bora.net

YLegend[www.bora.net]: Round Trip Time

ShortLegend[www.bora.net]: ms

Legend1[www.bora.net]: Maximum Round Trip Time in Milli Second

Legend2[www.bora.net]: Minimum Round Trip Time in Milli Second

Legend3[www.bora.net]: Maximal 5 Minute Maximum Round Trip Time

Legend4[www.bora.net]: Maximal 5 Minute Minimum Round Trip Time

WithPeak[www.dacom.co.kr]: ymwd

 

위 설정은 실제로 필자의 네트워크에서 www.bora.net 과의 ping 결과를 모니터링하기 위한 설정으로 위와 같이 설정 후 /etc/crontab

0-59/5 * * * * root run-parts /usr/local/mrtg/run/mrtg  ping.cfg 같이 설정해 주면 5분마다 ping 소요 시간을 모니터링하게 되고 다른 ISP와의 네트워크 속도는 Target 부분에서 www.bora.net www.kornet.net 등과 같이 모니터링하고자 하는 ISP로 적절히 변경하여 주면 된다.

위와 같이 설정후 mrtg 를 실행해 주면 아래와 같이 ping 으로 소요되는 시간을 그래프로 보여주게 된다.  아래의 경우 16시와 오전 0시를 전후로 네트워크에 장애가 있어 ping 수치가 갑자기 높아진 것을 알 수 있다.

 

 

    < 그림8.
ISP 와의 ping 결과를 mrtg로 본 화면>

 

 침입탐지 시스템(IDS) 운영하기

 

2001년은 IDS(Intrusion Detection System) 의 해라고 해도 무방할 정도로 IDS  에 대한 많은 솔루션의 개발과 관련 정보 교류가 있었던 해였다. 리눅스에서는 SNORT 라는 공개 프로그램이 가장 유명하고 또 많이 사용되는 IDS인데, snort 는 실시간으로 트래픽 분석과 패킷 로깅을 수행하는 네트워크 기반의 IDS(NIDS) 로 버퍼 오버플로우, 포트스캔, CGI, OS Fingerprinting 등의 룰을 이용하여 각종 접근 시도를 실시간으로 감지하는 기능을 가지고 있다. 또한 각종 플러그인 프로그램이나 응용 프로그램을 이용하여 확장된 이용이 가능하다. SNORT 를 사용하려면 먼저 ftp://ftp.ee.lbl.gov/libpcap.tar.Z 에서 libpcap 라이브러리를 설치후 http://www.snort.org/ 에서  Snort 관련 파일을 다운로드 하여 아래와 같이

# ./configure

# make

# make install 로 설치하면 된다. 

각종 룰은 설치시 기본적으로 제공되는 룰을 사용하여도 되고 홈페이지에서 지속적으로 갱신되는  rule을 다운로드 받아 snort.conf 설정에 include 하여 추가 설정해도 된다.

그리고 Snort IDS가 탐지하는 각종 로그 파일이 저장될 디렉토리인 /var/log/snort 를 생성한 후  

# ./snort -d -l /var/log/snort -c snort.conf -A full -D 로 실행하면 실시간으로 트래픽을 분석하여 각종 침입탐지 룰에 해당하는 내용들이 로그 파일에 기록되게 된다. 

tail  –f  /var/log/alert 보면 실시간으로 탐지가 되는 내용을 있다.

그러나 로그 파일들이 너무 많고 복잡하여 일일이 분석하기가 어려우므로 쉽게 분석할 있도록 별도의 플러그인 프로그램을 이용할 있다.

http://www.snort.org/downloads.html 참고하면 많은 관련 프로그램들이 있으니 참고하기 바란다. 많이 사용되는 프로그램으로는 기반에서 침입 탐지 분석이 가능한 Snortsnarf 라는 프로그램이 유명하다.

프로그램은 http://www.silicondefense.com/software/snortsnarf/ 에서 다운로드 가능하며 파일을 다운로드 압축을 해제하고  아래와 같이

# cp -a include/*  /usr/lib/perl5/site_perl/5.x.0/ 복사하고

  # cp cgi/* /usr/local/apache/cgi-bin/ 으로 복사한다. 그리고  Time-modules 디렉토리로 이동한    perl Makefile.PL ;  make ;  make test ; make install Time 모듈을 설치한다.

 

실행은 ./snortsnarf.pl -rulesdir /usr/local/snort-1.8.1-RELEASE -rulesfile /usr/local/snort-1.8.1-RELEASE/snort.conf -d /usr/local/apache/htdocs/snort /var/log/snort/alert  /var/log/snort/portscan.log  /var/log/snort/log

start.sh 같은 줄의 스크립트 파일로 만들어 실행하면 로그 파일을 분석하여 분석 결과를 HTML 파일로 변환하여 준다. 이때의 실행 경로는 자신의 경로에 맞게 수정하면 된다.  Snortsnarf 작동하는 실제 예제는

http://www.silicondefense.com/software/snortsnarf/example/index.html 에서 참고할 있다.

파일 무결성 체크, 네트워크 상태 점검, 침입탐지 시스템등의 기능을 통합하여 웹기반으로 한꺼번에 관리가 가능한 상용 NMS IDS 수준의 DEMARC라는 프로그램도 있다.  프로그램은 리눅스 기타 유닉스 계열에서 작동하며 Snort 1.8 이상 , Mysql 3.23 이상 기타 CGI, DBI, DBD::mySQL등의 perl 모듈을 필요로 하며   프로그램에 대한 자세한 설치 방법 사용에 대해서는 http://www.demarc.org/ 참고하기 바란다.

 

 < 그림9. SnortSnarf 실행 화면 >

 

 

일반적으로 IDS (1)방화벽 앞단,  (2)방화벽 뒷단,  (3)호스트 앞단등에 설치 가능한데,

통상적으로 방화벽(침입차단 시스템) 단의 스위칭에서 모니터링하며 더미 허브일 경우에는 관계 없지만 스위치의 경우 별도의 미러링 포트를 통해 실시간으로 탐지하게 된다. 그러므로  대용량의 트래픽 환경에서도 패킷을 잃지 않고 탐색하는지 여부가 IDS 성능에 크게 좌우를 하게 된다.

또한 호스트 기반의 IDS 비해 이러한 네트워크 기반의 IDS 모든 네트워크 트래픽을 탐지, 분석하여야 하므로 일정 정도의 네트워크 부하를 유발하게 되는 단점도 있다.

 

 

 SMTP Relay 모니터링하기

 

스팸 메일은 어제 오늘의 문제가 아닐 정도로 사회적으로도 문제가 되고 있다.

일반적으로 스팸 메일은 Relay 허용된 메일 서버를 이용하여 무차별적으로 보내어지는데, 이를 통해 스팸 메일을 보내느라 시스템에 불필요한 로드가 올라가고 많은 트래픽을 소모하게 된다. 최근에는 Relay 허용된 메일서버를 자동으로 검색하여 이를 알려주는 사이트가 생겨나기도 했는데, 자신이 관리하는 서버중에 Relay 허용된 메일 서버는 없는지 검색해 보도록 하자. 일반적으로 SMTP 사용하는 sendmail 경우 sendmail.cf 파일에서 Relay 여부를 설정하는데, 관리하는 서버가 많을 경우에는 일일이 확인해 없으므로 아래와 같이 SMTP Relay 여부를 확인할 있는 스크립트를 사용할 것을 추천한다. 스크립트는

http://www.unicom.com/sw/rlytest/rlytest 에서 다운로드할 있으며 파일을 서버에 check.cgi 저장하여  ./check.cgi tt.co.kr 같이 실행하면 해당 서버(tt.co.kr) 에서 Relay 허용되는지 여부를 알려준다.

 

1)

[root@www relay]# ./check.cgi  tt.co.kr

Connecting to tt.co.kr ...

<<< 220 www10.tt.co.kr ESMTP Today and Tomorrow(http://tt.co.kr/)

>>> HELO relay.tt.co.kr

<<< 250 www10.tt.co.kr Hello [211.47.65.15], pleased to meet you

>>> MAIL FROM:<nobody@tt.co.kr>

<<< 250 2.1.0 <nobody@tt.co.kr>... Sender ok

>>> RCPT TO:<root@relay.tt.co.kr>

<<< 550 5.7.1 <root@relay.tt.co.kr>... Relaying denied.

check.cgi: relay rejected - final response code 550

 

와와 같은 경우에는 Relay 허용되지 않는 경우(reject)이며

 

[root@www relay]# ./check.cgi mailserver.tt.co.kr

 

Connecting to 210.34.6.193 ...

<<< 220  mailserver.tt.co.kr  IMS SMTP Receiver Version 0.83 Ready

>>> HELO relay.tt.co.kr

<<< 250 OK

>>> MAIL FROM:<nobody@[210.34.6.193]>

<<< 250 nobody@[210.34.6.193] OK

>>> RCPT TO:<root@relay.tt.co.kr>

<<< 250 root@relay.tt.co.kr OK

>>> DATA

<<< 354 Ready for data

>>> (message body)

<<< 250 Message received OK

>>> QUIT

<<< 221 mailserver.tt.co.kr closing

check.cgi: relay accepted - final response code 221

 

위와 같은 경우는 Relay   허용된 경우(accept)임을 있다.

그런데, 일일이 모든 서버에 대해 위와 같이 확인해 보기도 귀찮고 하니 아래와 같이 일정 IP 대역의 서버를 모두 조회하여 Relay 허용되는 메일 서버가 확인되면 관리자에게 해당 서버에 대한 정보를 메일로 발송할 있도록 스크립트를 짜서 설정할 있다.

 
#!/usr/bin/perl
 
# check SMTP relaying or not between some IP ranges. 
 
$TO_MAIL      = 'antihong@tt.co.kr';   //Relay 가 허용되는 서버 발견시 발송될 E-mail
$SUBJECT      = "[경고] Relay Allowed";  // 발송될 메일의 제목
$MAIL_PROGRAM  = "/usr/sbin/sendmail";
 
for($i=1;$i<=254;++$i){                  // Relay 를 조회할 IP 대역 끝자리
$TASKS[$i] = `./check.cgi 201.12.211.$i`;    // Relay 를 조회할 IP 대역
if ($TASKS[$i] =~ /accept/){
 &scan_print;
 }
}
 
sub scan_print {
open(MAIL, "|$MAIL_PROGRAM -t");
    print MAIL "To: $TO_MAIL \n";
    print MAIL "Subject: $SUBJECT \n";
    print MAIL "Content-type: text/html\n\n";
    print MAIL "<p>\n";
    print MAIL "SMTP RELAY Allowed <b>201.12.211.$i</b> Server\n";
close(MAIL);
}
위 스크립트를 relay.cgi 로 저장하고 
http://www.unicom.com/sw/rlytest/rlytest 에서 다운받은 파일을 check.cgi 로 저장하여  

두 개 파일을 같은 디렉토리에 두고 relay.cgi 를 각자의 IP 대역 환경에 맞도록 변경후 ./relay.cgi & 로 백그라운드로 실행하면 해당 IP 대역(위의 경우에는 201.12.211.0 대역)을 조회하여 Relay 가 허용된 서버를 발견시 서버의 IP 에 대한 정보를 지정한 E-mail 로 발송하게 된다. relay.cgi 에서는 조회할 IP 대역, 통보받을 e-mail 주소만 변경하여 사용하면 된다. 또한 서버의 환경이 자주 변경된다면 while 문을 사용하여 무한 루프로 작동하게 하거나 cron 에 설정하여 정기적으로 Relay 여부를 점검할 수 있도록 할 수도 있다.

만약 Relay 가 허용된 서버를 확인하였을 때는 /etc/mail/sendmail.cf

(또는 /etc/sendmail.cf) 파일을 열어

# anything else is bogus

R$*                     $#error $@ 5.7.1 $: "550 Relaying denied"

부분이 주석되어 있는지 확인한 후 주석이 되어 있으면 주석을 삭제한 후 sendmail 을 재가동하면 Relay 가 거부된다.

 

  원격에서 보안 취약점 점검하기

 

보안에 조금이라도 관심있는 리눅서라면 SATAN 이나 SAINT등의 프로그램 이름을 들어보았을 것이다. 이러한 종류의 프로그램은 원격에서 시스템이나 네트워크의 보안 취약점을 점검하기 위한 프로그램인데, 어떤 목적으로 사용되느냐에 따라 시스템 점검이 아니라 악용이 되어 시스템을 침해하기 위한 수단으로 사용되어  때때로 문제가 된 적도 있었다.

최근에 사용되는 취약점 점검 프로그램중에서는 원격지에서 쉽게 보안  취약점을 점검할 수 있는 프로그램으로 Nessus(http://www.nessus.org/)  를 추천한다. Nessus 는 컨설팅업체에서 보안 컨설팅을 하고자 할 때 사용하기도 하는 프로그램으로 nessus에 대해서는 본지 9월호에 스캐너를 이용한 시스템 검사2” 에서 자세히 설명되었으므로 간단히 소개만 하겠다.

Nessus 의 가장 큰 특징중 하나는 다른 프로그램과 달리 서버와 클라이언트 구조로 이루어졌다는 것이다. 서버에서는 600여개의 각종 플러그인등이 설치되며 클라이언트에서 서버로 접속을 하여 정해진 룰에 따라 원격지의 취약점을 점검하는 것이다. 여러 방법이 가능하지만 여기에서는 리눅스에 nessus 서버를 설치하고 윈도우에 클라이언트 프로그램을 설치하여 취약점을 점검하는 법을 알아보도록 하겠다. (물론 리눅스에 서버와 클라이언트를 모두 설치해도 된다.) 

 < 그림10.  Nessus 서버-클라이언트 구조>

 

Nessus는 자체적으로 스캔을 위해 nmap 을 사용하므로 사전에nmap 이 설치되어 있거나 없을 경우에는  http://www.insecure.org/nmap/ 에서 nmap 을 다운로드 하여 설치하여야 한다. Nessus 서버나 클라이언트 설치법은 매우 쉽다.  단지 설치하고자 하는 서버에서

# lynx -source http://install.nessus.org | sh  만 실행 후 묻는 질문에 적절히 답을 하거나 엔터만 치면 설치 및 셋팅이 완료된다.

(Are you behind a web proxy ? [y/n] 에서 프록시가 없을 경우 n으로 답하면 다운로드 및 설치를 시작한다.)  다운로드가 끝나면 자동으로 시스템 체크 및 컴파일까지 수행하며 잠시후 설치가 완료되면  /usr/local/sbin/ 에 관련 파일들이 설치된다.

 

# /usr/local/sbin/nessus-adduser 를 실행 후

   login : linuxwork

   Authentication method : 입력 없이 엔터

Source host or network  : nessusd 에 접속할 클라이언트IP 또는 IP 대역을 입력한다.여기에서는 취약점을 점검할 윈도우 프로그램을 설치할 PC IP IP 대역을 지정한다. (: 192.168.1.3 또는 192.168.1.0/24)

 One time password : linuxwork입력후 Ctrl-D 를 누르면 된다.

# /usr/local/sbin/nessus-update-plugins   // 플러그인 업데이트를 하고

# /usr/local/sbin/nessusd -D       // nessusd를 데몬 모드로 실행하면

서버에서의 설정은 끝났다.

 

이제  http://www.nessus.org/win32.html 에서 원도우용 클라이언트 프로그램을 받아 윈도우에 설치 후 bin 디렉토리에 있는 nessus.exe 를 실행하면 로그인 화면이 뜨는데, Port Encrption 은 그대로 두고 Nessusd Host에 데몬이 설치된 서버의 IP, Login 에 방금 추가 설정한 아이디로  로그인하면 된다.

이후 플러그인 메뉴에서 취약점을 점검할 내용을 선택한 후 Target selection 에서 스캔을 할 대상 서버의 IP IP 대역을 설정 후 Start the scan 을 클릭하면 취약점 점검을 위한 스캐닝을 시작한다.

취약점 점검이 끝나면 모든 정보를 종합하여 어떤 부분이 취약한지와 또한 어떻게 패치하고 대처하여야 하는지에 대하여 결과에 대해 리포트를 작성해 보여주고 이 결과 보고서는 HTML이나  ASCⅡ등 원하는 형태로 선택하여 저장할 수 있다. 자신의 서버에는 어떠한 취약점이 있는지 각자 nessus 로 점검을 해 보기 바란다.

추가적인 Nessus 이용 방법에 대해서는 http://nessus.org/ 를 참고하기 바란다.

 

 

 

 

 

 

 

 

 

 

 

 

 

 


                 < 그림11. Nessus 의 취약점 점검 결과>

 

 

 시스템 및 네트워크 장애 모니터링 

 

관리하는 서버가 많아지다 보면 특정 데몬이 작동하지 않거나 시스템이 다운되었을 경우 알 수 있는 방법이 없다. 심지어 출근해서 서버를 모니터링해 보면 퇴근 이후 줄곧 서버가 다운되어 있는 경우도 있는데, 고객으로부터 항의가 들어오고 나서야 확인이 가능하게 된다. 이를 위해 주기적이고 지속적으로 시스템을 모니터링하여 특정 서비스나 시스템이 다운시에는 다운 여부를 알려줄 수 있는 시스템 및 네트워크 모니터링 프로그램을 필요로 하게 된다.

일반적으로 이러한 프로그램은 NMS(Network Management System) 또는 SMS(System Management System) 라는 이름으로 매우 고가에 판매되고 있는데, 많은 기능을 제공하면서도 부담 없이 사용 가능한 프로그램으로 가장 추천할 만한 것으로는 와츠업(Whatsup)이라는 제품이 있다. 이 프로그램은 WS_FTP 를 제작한 Ipswitch 라는 업체에서 제작하여 배포하는 프로그램으로 유료 버전은 가격이 고가이지만( 110만원정도) 30일 무료 체험 버전을 다운로드 받아 기능의 제한 없이 사용 가능하다. 쉬우면서도 강력한 기능으로 국내외 회선 업체나 IDC 등에서도 시스템이나 네트워크를 감시하기 위해 실제로 많이 사용되는 제품이다. 이 프로그램은

http://www.ipswitch.com/Products/WhatsUp/index.htmlhttp://solvnt1.solvithightech.co.kr/ipswitch/WhatsUp/  에서 다운로드하여 실행하면 사용 가능하며 지정된 서버나 네트워크가 접속되지 않거나 특정 서비스(sendmail, http)가 작동하지 않을 경우에는 그림과 같이 해당 아이콘의 색이 변하면서 사운드 알람 , 비퍼, 페이저, 이메일, 음성 메시지로 해당 시스템이나 네트워크가 다운되었음을 통지하게 된다. 또한 로그 파일에 관련 정보를 저장하여 차후에 각종 통계를 위한 기능으로 사용할 수도 있다. 실제로 필자가 테스트해 보았을 경우에는 시스템이 다운 후 몇 초만에 다운 여부를 알려주었다.  이 프로그램의 한 가지 단점이라면 리눅스가 아닌 원도우에서 작동하는 프로그램이라는 점이며 이와 비슷한 프로그램으로 리눅스에서 작동하는 프로그램을 원한다면

http://www.opennms.org/ 를 참고하기 바란다.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 


                < 그림12. 와츠업 프로그램 작동 예제>

 

 

 

    라우터에서 네트워크 모니터링하기

 

리눅스와는 직접적으로 관련은 없지만 네트워크에서는 빠질 수 없는 장비가 바로  라우터이므로 간략히 소개만 하도록 하겠다. 라우터를 다룰 수 있는 환경이 된다면 직접 따라 해 보는 것도 좋지만 그렇지 않은 경우라면 참고만 하기 바란다.

네트워크를 크게 WAN 구간과 LAN구간으로 나눈다면 WAN 구간의 통신은 라우터라는 장비를 통한 라우팅 프로토콜을 통해 이루어지게 된다. (참고로 LAN 구간에서는 IP 주소와 MAC 주소를 서로 매칭시켜주는 ARP 라는 프로토콜이 매우 중요하다.)

어차피 내부 네트워크가 외부 네트워크와  인터넷 통신을 하려면 라우터라는 장비를 반드시 거치게 되어 있으므로 모든 트래픽의 관문이라 할 수 있는 라우터에서의 네트워크 모니터링은 매우 효과적이며 효율적이다.  라우터에서 사용되는 명령어와 기능은 매우 많지만 가장 대표적인 기능중 몇 가지만 소개를 하겠다.

아래는 가장 많이 사용되는 Cisco 라우터에서 특정 회선의 패킷을 모니터링하는 IP Accounting  예제를 보여준다.

 

ROUTER#conf t                                 // config 모드로 변경

ROUTER(config)#int serial1                    // serial1번 라인 선택

ROUTER(config-if)#ip accounting               // ip accounting 기능 설정

ROUTER#show ip accounting                       // ip accounting 결과 보기

   Source           Destination              Packets               Bytes

 211.17.47.11     65.192.28.33                     2                 120

 211.17.45.28     209.85.13.32                     1                  60

 211.17.45.184    216.32.243.7                     1                  44

 211.17.47.112    198.41.3.54                      5                 212

 211.17.45.34     198.41.0.4                       2                  98

 211.17.46.4      209.247.164.36                   1                 112

 211.17.47.13     216.239.46.140                  42               56431

 211.17.45.193    207.112.224.10                  53               79122

 211.17.45.166    212.187.59.97                   14               21000

 211.17.45.4      205.152.37.254                   1                 115

 211.17.45.187    216.87.103.212                  19               28500

 

위의 IP Accounting serial1 번 회선을 통해 라우팅되는 목적지ip 와 소스ip그리고 각 패킷의 양과 사이즈등의 정보를 보여준다. 만약 특정 목적지(Destination) 나 소스(Source) 에서의 트래픽이 특별히 많을 경우에는 서비스 거부공격(DoS)이나 분산 서비스 거부 공격(DdoS) 여부를 의심해 보아야 한다.

 

 

아래는 netflow 설정 예제를 보여준다.

 

ROUTER#conf t                            // config  모드로 변경

ROUTER(config)#int serial1               // serial1 번 라인 선택

ROUTER(config-if)#ip route-cache flow    // netflow 기능 설정

ROUTER#show ip cache flow                  // netflow 결과 보기

IP packet size distribution (360715 total packets):

   1-32   64   96  128  160  192  224  256  288  320  352  384  416  448  480

   .000 .832 .036 .007 .007 .006 .013 .005 .004 .011 .008 .007 .009 .006 .004

 

    512  544  576 1024 1536 2048 2560 3072 3584 4096 4608

   .004 .003 .007 .004 .017 .000 .000 .000 .000 .000 .000

 

IP Flow Switching Cache, 4456704 bytes

  159 active, 65377 inactive, 50342 added

  789091 ager polls, 0 flow alloc failures

  last clearing of statistics never

Protocol         Total    Flows   Packets Bytes  Packets Active(Sec) Idle(Sec)

--------         Flows     /Sec     /Flow  /Pkt     /Sec     /Flow     /Flow

TCP-Telnet           1      0.0        10    55      0.0      71.6      15.6

TCP-FTP            916      0.0         3    47      0.0       3.9       8.8

TCP-FTPD            12      0.0         5   500      0.0       6.3       5.4

TCP-WWW          27967      0.0         9    92      0.0       7.0       4.6

TCP-SMTP          2555      0.0        11   221      0.0       7.8       4.4

TCP-other         1219      0.0         4   180      0.0       4.4       8.5

UDP-DNS          14424      0.0         2    64      0.0       6.7      13.8

UDP-NTP             22      0.0         1    76      0.0       0.0      13.1

UDP-other         4733      0.0         1   152      0.0       0.6      14.4

ICMP               714      0.0         7   300      0.0       8.1      14.6

Total:           52563      0.0         6   104      0.0       6.3       8.3

 

위와 같은 설정은 netflow 라 하는데, 위의 경우 serial1 번 회선을 통해 라우팅되는 패킷 사이즈별로 트래픽 상황과 각 프로토콜별로 분류된 상황을 모니터링할 수 있다.

이외 access-list 를 이용한 강력한 접근 제어 및 기타 여러 모니터링 방법이 있으니 관심 있는 분은 라우터 관련 서적이나 매뉴얼을 참고하여 구체적인 설정 방법을 익히기 바란다.





Trackback 0 Comment 0
2009. 4. 8. 16:47

configuration file for the Net-SNMP SNMP agent

SNMPD.CONF

Section: Net-SNMP (5)
Updated: 08 Feb 2002
Index Return to Main Contents
 

NAME

snmpd.conf - configuration file for the Net-SNMP SNMP agent  

DESCRIPTION

The Net-SNMP agent uses one or more configuration files to control its operation and the management information provided. These files (snmpd.conf and snmpd.local.conf) can be located in one of several locations, as described in the snmp_config(5) manual page.

The (perl) application snmpconf can be used to generate configuration files for the most common agent requirements. See the snmpconf(1) manual page for more information, or try running the command:

snmpconf -g basic_setup

There are a large number of directives that can be specified, but these mostly fall into four distinct categories:

*
those controlling who can access the agent
*
those configuring the information that is supplied by the agent
*
those controlling active monitoring of the local system
*
those concerned with extending the functionality of the agent.

Some directives don't fall naturally into any of these four categories, but this covers the majority of the contents of a typical snmpd.conf file. A full list of recognised directives can be obtained by running the command:

snmpd -H
 

AGENT BEHAVIOUR

Although most configuration directives are concerned with the MIB information supplied by the agent, there are a handful of directives that control the behaviour of snmpd considered simply as a daemon providing a network service.
agentaddress [<transport-specifier>:]<transport-address>[,...]
defines a list of listening addresses, on which to receive incoming SNMP requests. See the section LISTENING ADDRESSES in the snmpd(8) manual page for more information about the format of listening addresses.
The default behaviour is to listen on UDP port 161 on all IPv4 interfaces.
agentgroup {GROUP|#GID}
changes to the specified group after opening the listening port(s). This may refer to a group by name (GROUP), or a numeric group ID starting with '#' (#GID).
agentuser {USER|#UID}
changes to the specified user after opening the listening port(s). This may refer to a user by name (USER), or a numeric user ID starting with '#' (#UID).
leave_pidfile yes
instructs the agent to not remove its pid file on shutdown. Equivalent to specifying "-U" on the command line.
maxGetbulkRepeats NUM
Sets the maximum number of responses allowed for a single variable in a getbulk request. Set to 0 to enable the default and set it to -1 to enable unlimited. Because memory is allocated ahead of time, sitting this to unlimited is not considered safe if your user population can not be trusted. A repeat number greater than this will be truncated to this value.
This is set by default to -1.
maxGetbulkResponses NUM
Sets the maximum number of responses allowed for a getbulk request. This is set by default to 100. Set to 0 to enable the default and set it to -1 to enable unlimited. Because memory is allocated ahead of time, sitting this to unlimited is not considered safe if your user population can not be trusted.
In general, the total number of responses will not be allowed to exceed the maxGetbulkResponses number and the total number returned will be an integer multiple of the number of variables requested times the calculated number of repeats allow to fit below this number.
Also not that processing of maxGetbulkRepeats is handled first.
 

SNMPv3 Configuration

SNMPv3 requires an SNMP agent to define a unique "engine ID" in order to respond to SNMPv3 requests. This ID will normally be determined automatically, using two reasonably non-predictable values - a (pseudo-)random number and the current uptime in seconds. This is the recommended approach. However the capacity exists to define the engineID in other ways:
engineID STRING
specifies that the engineID should be built from the given text STRING.
engineIDType 1|2|3
specifies that the engineID should be built from the IPv4 address (1), IPv6 address (2) or MAC address (3). Note that changing the IP address (or switching the network interface card) may cause problems.
engineIDNic INTERFACE
defines which interface to use when determining the MAC address. If engineIDType 3 is not specified, then this directive has no effect.
The default is to use eth0.
 

ACCESS CONTROL

snmpd supports the View-Based Access Control Model (VACM) as defined in RFC 2575, to control who can retrieve or update information. To this end, it recognizes various directives relating to access control. These fall into four basic groups.  

SNMPv3 Users

createUser [-e ENGINEID] username (MD5|SHA) authpassphrase [DES|AES] [privpassphrase]
MD5 and SHA are the authentication types to use. DES and AES are the privacy protocols to use. If the privacy passphrase is not specified, it is assumed to be the same as the authentication passphrase. Note that the users created will be useless unless they are also added to the VACM access control tables described above.
SHA authentication and DES/AES privacy require OpenSSL to be installed and the agent to be built with OpenSSL support. MD5 authentication may be used without OpenSSL.
Warning: the minimum pass phrase length is 8 characters.
SNMPv3 users can be created at runtime using the snmpusm(1) command.
Instead of figuring out how to use this directive and where to put it (see below), just run "net-snmp-config --create-snmpv3-user" instead, which will add one of these lines to the right place.
This directive should be placed into the /var/net-snmp/snmpd.conf file instead of the other normal locations. The reason is that the information is read from the file and then the line is removed (eliminating the storage of the master password for that user) and replaced with the key that is derived from it. This key is a localized key, so that if it is stolen it can not be used to access other agents. If the password is stolen, however, it can be.
If you need to localize the user to a particular EngineID (this is useful mostly in the similar snmptrapd.conf file), you can use the -e argument to specify an EngineID as a hex value (EG, "0x01020304").
If you want to generate either your master or localized keys directly, replace the given password with a hexstring (preceeded by a "0x") and precede the hex string by a -m or -l token (respectively). EGs:
[these keys are *not* secure but are easy to visually parse for
counting purposes. Please generate random keys instead of using
these examples]

createUser myuser SHA -l 0x0001020304050607080900010203040506070809 AES -l 0x00010203040506070809000102030405
createUser myuser SHA -m 0x0001020304050607080900010203040506070809 AES -m 0x0001020304050607080900010203040506070809
Due to the way localization happens, localized privacy keys are expected to be the length needed by the algorithm (128 bits for all supported algorithms). Master encryption keys, though, need to be the length required by the authentication algorithm not the length required by the encrypting algorithm (MD5: 16 bytes, SHA: 20 bytes).
 

Traditional Access Control

Most simple access control requirements can be specified using the directives rouser/rwuser (for SNMPv3) or rocommunity/rwcommunity (for SNMPv1 or SNMPv2c).
rouser USER [noauth|auth|priv [OID | -V VIEW [CONTEXT]]]
rwuser USER [noauth|auth|priv [OID | -V VIEW [CONTEXT]]]
specify an SNMPv3 user that will be allowed read-only (GET and GETNEXT) or read-write (GET, GETNEXT and SET) access respectively. By default, this will provide access to the full OID tree for authenticated (including encrypted) SNMPv3 requests, using the default context. An alternative minimum security level can be specified using noauth (to allow unauthenticated requests), or priv (to enforce use of encryption). The OID field restricts access for that user to the subtree rooted at the given OID, or the named view. An optional context can also be specified, or "context*" to denote a context prefix. If no context field is specified (or the token "*" is used), the directive will match all possible contexts.
rocommunity COMMUNITY [SOURCE [OID | -V VIEW [CONTEXT]]]
rwcommunity COMMUNITY [SOURCE [OID | -V VIEW [CONTEXT]]]
specify an SNMPv1 or SNMPv2c community that will be allowed read-only (GET and GETNEXT) or read-write (GET, GETNEXT and SET) access respectively. By default, this will provide access to the full OID tree for such requests, regardless of where they were sent from. The SOURCE token can be used to restrict access to requests from the specified system(s) - see com2sec for the full details. The OID field restricts access for that community to the subtree rooted at the given OID, or named view. Contexts are typically less relevant to community-based SNMP versions, but the same behaviour applies here.
rocommunity6 COMMUNITY [SOURCE [OID | -V VIEW [CONTEXT]]]
rwcommunity6 COMMUNITY [SOURCE [OID | -V VIEW [CONTEXT]]]
are directives relating to requests received using IPv6 (if the agent supports such transport domains). The interpretation of the SOURCE, OID, VIEW and CONTEXT tokens are exactly the same as for the IPv4 versions.

In each case, only one directive should be specified for a given SNMPv3 user, or community string. It is not appropriate to specify both rouser and rwuser directives referring to the same SNMPv3 user (or equivalent community settings). The rwuser directive provides all the access of rouser (as well as allowing SET support). The same holds true for the community-based directives.

More complex access requirements (such as access to two or more distinct OID subtrees, or different views for GET and SET requests) should use one of the other access control mechanisms. Note that if several distinct communities or SNMPv3 users need to be granted the same level of access, it would also be more efficient to use the main VACM configuration directives.  

VACM Configuration

The full flexibility of the VACM is available using four configuration directives - com2sec, group, view and access. These provide direct configuration of the underlying VACM tables.
com2sec [-Cn CONTEXT] SECNAME SOURCE COMMUNITY
com2sec6 [-Cn CONTEXT] SECNAME SOURCE COMMUNITY
map an SNMPv1 or SNMPv2c community string to a security name - either from a particular range of source addresses, or globally ("default"). A restricted source can either be a specific hostname (or address), or a subnet - represented as IP/MASK (e.g. 10.10.10.0/255.255.255.0), or IP/BITS (e.g. 10.10.10.0/24), or the IPv6 equivalents.
The same community string can be specified in several separate directives (presumably with different source tokens), and the first source/community combination that matches the incoming request will be selected. Various source/community combinations can also map to the same security name.
If a CONTEXT is specified (using -Cn), the community string will be mapped to a security name in the named SNMPv3 context. Otherwise the default context ("") will be used.
com2secunix [-Cn CONTEXT] SECNAME SOCKPATH COMMUNITY
is the Unix domain sockets version of com2sec.
group GROUP {v1|v2c|usm} SECNAME
maps a security name (in the specified security model) into a named group. Several group directives can specify the same group name, allowing a single access setting to apply to several users and/or community strings.
Note that groups must be set up for the two community-based models separately - a single com2sec (or equivalent) directive will typically be accompanied by two group directives.
view VNAME TYPE OID [MASK]
defines a named "view" - a subset of the overall OID tree. This is most commonly a single subtree, but several view directives can be given with the same view name (VNAME), to build up a more complex collection of OIDs. TYPE is either included or excluded, which can again define a more complex view (e.g by excluding certain sensitive objects from an otherwise accessible subtree).
MASK is a list of hex octets (optionally separated by '.' or ':') with the set bits indicating which subidentifiers in the view OID to match against. If not specified, this defaults to matching the OID exactly (all bits set), thus defining a simple OID subtree. So:
view iso1 included .iso 0xf0
view iso2 included .iso
view iso3 included .iso.org.dod.mgmt 0xf0
would all define the same view, covering the whole of the 'iso(1)' subtree (with the third example ignoring the subidentifiers not covered by the mask).
More usefully, the mask can be used to define a view covering a particular row (or rows) in a table, by matching against the appropriate table index value, but skipping the column subidentifier:
view ifRow4 included .1.3.6.1.2.1.2.2.1.0.4 0xff:a0
Note that a mask longer than 8 bits must use ':' to separate the individual octets.
access GROUP CONTEXT {any|v1|v2c|usm} LEVEL PREFX READ WRITE NOTIFY
maps from a group of users/communities (with a particular security model and minimum security level, and in a specific context) to one of three views, depending on the request being processed.
LEVEL is one of noauth, auth, or priv. PREFX specifies how CONTEXT should be matched against the context of the incoming request, either exact or prefix. READ, WRITE and NOTIFY specifies the view to be used for GET*, SET and TRAP/INFORM requests (althought the NOTIFY view is not currently used). For v1 or v2c access, LEVEL will need to be noauth.
 

Typed-View Configuration

The final group of directives extend the VACM approach into a more flexible mechanism, which can be applied to other access control requirements. Rather than the fixed three views of the standard VACM mechanism, this can be used to configure various different view types. As far as the main SNMP agent is concerned, the two main view types are read and write, corresponding to the READ and WRITE views of the main access directive. See the 'snmptrapd.conf(5)' man page for discussion of other view types.
authcommunity TYPES COMMUNITY [SOURCE [OID | -V VIEW [CONTEXT]]]
is an alternative to the rocommunity/rwcommunity directives. TYPES will usually be read or read,write respectively. The view specification can either be an OID subtree (as before), or a named view (defined using the view directive) for greater flexibility. If this is omitted, then access will be allowed to the full OID tree. If CONTEXT is specified, access is configured within this SNMPv3 context. Otherwise the default context ("") is used.
authuser TYPES [-s MODEL] USER [LEVEL [OID | -V VIEW [CONTEXT]]]
is an alternative to the rouser/rwuser directives. The fields TYPES, OID, VIEW and CONTEXT have the same meaning as for authcommunity.
authgroup TYPES [-s MODEL] GROUP [LEVEL [OID | -V VIEW [CONTEXT]]]
is a companion to the authuser directive, specifying access for a particular group (defined using the group directive as usual). Both authuser and authgroup default to authenticated requests - LEVEL can also be specified as noauth or priv to allow unauthenticated requests, or require encryption respectively. Both authuser and authgroup directives also default to configuring access for SNMPv3/USM requests - use the '-s' flag to specify an alternative security model (using the same values as for access above).
authaccess TYPES [-s MODEL] GROUP VIEW [LEVEL [CONTEXT]]
also configures the access for a particular group, specifying the name and type of view to apply. The MODEL and LEVEL fields are interpreted in the same way as for authgroup. If CONTEXT is specified, access is configured within this SNMPv3 context (or contexts with this prefix if the CONTEXT field ends with '*'). Otherwise the default context ("") is used.
setaccess GROUP CONTEXT MODEL LEVEL PREFIX VIEW TYPES
is a direct equivalent to the original access directive, typically listing the view types as read or read,write as appropriate. (or see 'snmptrapd.conf(5)' for other possibilities). All other fields have the same interpretation as with access.
 

SYSTEM INFORMATION

Most of the information reported by the Net-SNMP agent is retrieved from the underlying system, or dynamically configured via SNMP SET requests (and retained from one run of the agent to the next). However, certain MIB objects can be configured or controlled via the snmpd.conf(5) file.  

System Group

Most of the scalar objects in the 'system' group can be configured in this way:
sysLocation STRING
sysContact STRING
sysName STRING
set the system location, system contact or system name (sysLocation.0, sysContact.0 and sysName.0) for the agent respectively. Ordinarily these objects are writeable via suitably authorized SNMP SET requests. However, specifying one of these directives makes the corresponding object read-only, and attempts to SET it will result in a notWritable error response.
sysServices NUMBER
sets the value of the sysServices.0 object. For a host system, a good value is 72 (application + end-to-end layers). If this directive is not specified, then no value will be reported for the sysServices.0 object.
sysDescr STRING
sysObjectID OID
sets the system description or object ID for the agent. Although these MIB objects are not SNMP-writable, these directives can be used by a network administrator to configure suitable values for them.
 

Interfaces Group

interface NAME TYPE SPEED
can be used to provide appropriate type and speed settings for interfaces where the agent fails to determine this information correctly. TYPE is a type value as given in the IANAifType-MIB, and can be specified numerically or by name (assuming this MIB is loaded).
 

Host Resources Group

This requires that the agent was built with support for the host module (which is now included as part of the default build configuration on the major supported platforms).
ignoreDisk STRING
controls which disk devices are scanned as part of populating the hrDiskStorageTable (and hrDeviceTable). The HostRes implementation code includes a list of disk device patterns appropriate for the current operating system, some of which may cause the agent to block when trying to open the corresponding disk devices. This might lead to a timeout when walking these tables, possibly resulting in inconsistent behaviour. This directive can be used to specify particular devices (either individually or wildcarded) that should not be checked.
Note:
Please consult the source (host/hr_disk.c) and check for the Add_HR_Disk_entry calls relevant for a particular O/S to determine the list of devices that will be scanned.
The pattern can include one or more wildcard expressions. See snmpd.examples(5) for illustration of the wildcard syntax.
skipNFSInHostResources true
controls whether NFS and NFS-like file systems should be omitted from the hrStorageTable (true or 1) or not (false or 0, which is the default). If the Net-SNMP agent gets hung on NFS-mounted filesystems, you can try setting this to '1'.
storageUseNFS [1|2]
controls how NFS and NFS-like file systems should be reported in the hrStorageTable. as 'Network Disks' (1) or 'Fixed Disks' (2) Historically, the Net-SNMP agent has reported such file systems as 'Fixed Disks', and this is still the default behaviour. Setting this directive to '1' reports such file systems as
 

Process Monitoring

The hrSWRun group of the Host Resources MIB provides information about individual processes running on the local system. The prTable of the UCD-SNMP-MIB complements this by reporting on selected services (which may involve multiple processes). This requires that the agent was built with support for the ucd-snmp/proc module (which is included as part of the default build configuration).
proc NAME [MAX [MIN]]
monitors the number of processes called NAME (as reported by "/bin/ps -e") running on the local system.
If the number of NAMEd processes is less than MIN or greater than MAX, then the corresponding prErrorFlag instance will be set to 1, and a suitable description message reported via the prErrMessage instance.
Note:
This situation will not automatically trigger a trap to report the problem - see the DisMan Event MIB section later.
If neither MAX nor MIN are specified (or are both 0), they will default to infinity and 1 respectively ("at least one"). If only MAX is specified, MIN will default to 0 ("no more than MAX").
procfix NAME PROG ARGS
registers a command that can be run to fix errors with the given process NAME. This will be invoked when the corresponding prErrFix instance is set to 1.
Note:
This command will not be invoked automatically.
The procfix directive must be specified after the matching proc directive, and cannot be used on its own.

If no proc directives are defined, then walking the prTable will fail (noSuchObject).  

Disk Usage Monitoring

This requires that the agent was built with support for the ucd-snmp/disk module (which is included as part of the default build configuration).
disk PATH [ MINSPACE | MINPERCENT% ]
monitors the disk mounted at PATH for available disk space.
The minimum threshold can either be specified in Kb (MINSPACE) or as a percentage of the total disk (MINPERCENT% with a '%' character), defaulting to 100Kb if neither are specified. If the free disk space falls below this threshold, then the corresponding dskErrorFlag instance will be set to 1, and a suitable description message reported via the dskErrorMsg instance.
Note:
This situation will not automatically trigger a trap to report the problem - see the DisMan Event MIB section later.
includeAllDisks MINPERCENT%
configures monitoring of all disks found on the system, using the specified (percentage) threshold. The threshold for individual disks can be adjusted using suitable disk directives (which can come either before or after the includeAllDisks directive).
Note:
Whether disk directives appears before or after includeAllDisks may affect the indexing of the dskTable.
Only one includeAllDisks directive should be specified - any subsequent copies will be ignored.
The list of mounted disks will be determined when the agent starts using the setmntent(3) and getmntent(3), or fopen(3) and getmntent(3), or setfsent(3) and getfsent(3) system calls. If none of the above system calls are available then the root partition "/" (which is assumed to exist on any UNIX based system) will be monitored. Disks mounted after the agent has started will not be monitored.

If neither any disk directives or includeAllDisks are defined, then walking the dskTable will fail (noSuchObject).  

System Load Monitoring

This requires that the agent was built with support for either the ucd-snmp/loadave module or the ucd-snmp/memory module respectively (both of which are included as part of the default build configuration).
load MAX1 [MAX5 [MAX15]]
monitors the load average of the local system, specifying thresholds for the 1-minute, 5-minute and 15-minute averages. If any of these loads exceed the associated maximum value, then the corresponding laErrorFlag instance will be set to 1, and a suitable description message reported via the laErrMessage instance.
Note:
This situation will not automatically trigger a trap to report the problem - see the DisMan Event MIB section later.
If the MAX15 threshold is omitted, it will default to the MAX5 value. If both MAX5 and MAX15 are omitted, they will default to the MAX1 value. If this directive is not specified, all three thresholds will default to a value of DEFMAXLOADAVE.
If a threshold value of 0 is given, the agent will not report errors via the relevant laErrorFlag or laErrMessage instances, regardless of the current load.

Unlike the proc and disk directives, walking the walking the laTable will succeed (assuming the ucd-snmp/loadave module was configured into the agent), even if the load directive is not present.

swap MIN
monitors the amount of swap space available on the local system. If this falls below the specified threshold (MIN Kb), then the memErrorSwap object will be set to 1, and a suitable description message reported via memSwapErrorMsg.
Note:
This situation will not automatically trigger a trap to report the problem - see the DisMan Event MIB section later.
If this directive is not specified, the default threshold is 16 Mb.
 

Log File Monitoring

This requires that the agent was built with support for either the ucd-snmp/file or ucd-snmp/logmatch modules respectively (both of which are included as part of the default build configuration).
file FILE [MAXSIZE]
monitors the size of the specified file (in Kb). If MAXSIZE is specified, and the size of the file exceeds this threshold, then the corresponding fileErrorFlag instance will be set to 1, and a suitable description message reported via the fileErrorMsg instance.
Note:
This situation will not automatically trigger a trap to report the problem - see the DisMan Event MIB section later.
A maximum of 20 files can be monitored.

If no file directives are defined, then walking the fileTable will fail (noSuchObject).

logmatch NAME PATH CYCLETIME REGEX
monitors the specified file for occurances of the specified pattern REGEX.
A maximum of 50 files can be monitored.

If no logmatch directives are defined, then walking the logMatchTable will fail (noSuchObject).  

ACTIVE MONITORING

The usual behaviour of an SNMP agent is to wait for incoming SNMP requests and respond to them - if no requests are received, an agent will typically not initiate any actions. This section describes various directives that can configure snmpd to take a more active role.  

Notification Handling

trapcommunity STRING
defines the default community string to be used when sending traps. Note that this directive must be used prior to any community-based trap destination directives that need to use it.
trapsink HOST [COMMUNITY [PORT]]
trap2sink HOST [COMMUNITY [PORT]]
informsink HOST [COMMUNITY [PORT]]
define the address of a notification receiver that should be sent SNMPv1 TRAPs, SNMPv2c TRAP2s, or SNMPv2 INFORM notifications respectively. See the section LISTENING ADDRESSES in the snmpd(8) manual page for more information about the format of listening addresses. If COMMUNITY is not specified, the most recent trapcommunity string will be used.
If the transport address does not include an explicit port specification, then PORT will be used. If this is not specified, the well known SNMP trap port (162) will be used.
Note:
This mechanism is being deprecated, and the listening port should be specified via the transport specification HOST instead.
If several sink directives are specified, multiple copies of each notification (in the appropriate formats) will be generated.
Note:
It is not normally appropriate to list two (or all three) sink directives with the same destination.
trapsess [SNMPCMD_ARGS] HOST
provides a more generic mechanism for defining notification destinations. SNMPCMD_ARGS should be the command-line options required for an equivalent snmptrap (or snmpinform) command to send the desired notification. The option -Ci can be used (with -v2c or -v3) to generate an INFORM notification rather than an unacknowledged TRAP.
This is the appropriate directive for defining SNMPv3 trap receivers. See http://www.net-snmp.org/tutorial/tutorial-5/commands/snmptrap-v3.html for more information about SNMPv3 notification behaviour.
authtrapenable {1|2}
determines whether to generate authentication failure traps (enabled(1)) or not (disabled(2) - the default). Ordinarily the corresponding MIB object (snmpEnableAuthenTraps.0) is read-write, but specifying this directive makes this object read-only, and attempts to set the value via SET requests will result in a notWritable error response.
 

DisMan Event MIB

The previous directives can be used to configure where traps should be sent, but are not concerned with when to send such traps (or what traps should be generated). This is the domain of the Event MIB - developed by the Distributed Management (DisMan) working group of the IETF.

This requires that the agent was built with support for the disman/event module (which is now included as part of the default build configuration for the most recent distribution).

Note:
The behaviour of the latest implementation differs in some minor respects from the previous code - nothing too significant, but existing scripts may possibly need some minor adjustments.
iquerySecName NAME
agentSecName NAME
specifies the default SNMPv3 username, to be used when making internal queries to retrieve any necessary information (either for evaluating the monitored expression, or building a notification payload). These internal queries always use SNMPv3, even if normal querying of the agent is done using SNMPv1 or SNMPv2c.
Note that this user must also be explicitly created (createUser) and given appropriate access rights (e.g. rouser). This directive is purely concerned with defining which user should be used - not with actually setting this user up.
monitor [OPTIONS] NAME EXPRESSION
defines a MIB object to monitor. If the EXPRESSION condition holds (see below), then this will trigger the corresponding event, and either send a notification or apply a SET assignment (or both). Note that the event will only be triggered once, when the expression first matches. This monitor entry will not fire again until the monitored condition first becomes false, and then matches again. NAME is an administrative name for this expression, and is used for indexing the mteTriggerTable (and related tables). Note also that such monitors use an internal SNMPv3 request to retrieve the values being monitored (even if normal agent queries typically use SNMPv1 or SNMPv2c). See the iquerySecName token described above.
EXPRESSION
There are three types of monitor expression supported by the Event MIB - existence, boolean and threshold tests.
OID | ! OID | != OID
defines an existence(0) monitor test. A bare OID specifies a present(0) test, which will fire when (an instance of) the monitored OID is created. An expression of the form ! OID specifies an absent(1) test, which will fire when the monitored OID is delected. An expression of the form != OID specifies a changed(2) test, which will fire whenever the monitored value(s) change. Note that there must be whitespace before the OID token.
OID OP VALUE
defines a boolean(1) monitor test. OP should be one of the defined comparison operators (!=, ==, <, <=, >, >=) and VALUE should be an integer value to compare against. Note that there must be whitespace around the OP token. A comparison such as OID !=0 will not be handled correctly.
OID MIN MAX [DMIN DMAX]
defines a threshold(2) monitor test. MIN and MAX are integer values, specifying lower and upper thresholds. If the value of the monitored OID falls below the lower threshold (MIN) or rises above the upper threshold (MAX), then the monitor entry will trigger the corresponding event.
Note that the rising threshold event will only be re-armed when the monitored value falls below the lower threshold (MIN). Similarly, the falling threshold event will be re-armed by the upper threshold (MAX).
The optional parameters DMIN and DMAX configure a pair of similar threshold tests, but working with the delta differences between successive sample values.
OPTIONS
There are various options to control the behaviour of the monitored expression. These include:
-D
indicates that the expression should be evaluated using delta differences between sample values (rather than the values themselves).
-d OID
-di OID
specifies a discontinuity marker for validating delta differences. A -di object instance will be used exactly as given. A -d object will have the instance subidentifiers from the corresponding (wildcarded) expression object appended. If the -I flag is specified, then there is no difference between these two options.
This option also implies -D.
-e EVENT
specifies the event to be invoked when this monitor entry is triggered. If this option is not given, the monitor entry will generate one of the standard notifications defined in the DISMAN-EVENT-MIB.
-I
indicates that the monitored expression should be applied to the specified OID as a single instance. By default, the OID will be treated as a wildcarded object, and the monitor expanded to cover all matching instances.
-i OID
-o OID
define additional varbinds to be added to the notification payload when this monitor trigger fires. For a wildcarded expression, the suffix of the matched instance will be added to any OIDs specified using -o, while OIDs specified using -i will be treated as exact instances. If the -I flag is specified, then there is no difference between these two options.
See strictDisman for details of the ordering of notification payloads.
-r FREQUENCY
monitors the given expression every FREQUENCY seconds. By default, the expression will be evaluated every 600s (10 minutes).
-S
indicates that the monitor expression should not be evaluated when the agent first starts up. The first evaluation will be done once the first repeat interval has expired.
-s
indicates that the monitor expression should be evaluated when the agent first starts up. This is the default behaviour.
Note:
Notifications triggered by this initial evaluation will be sent before the coldStart trap.
-u SECNAME
specifies a security name to use for scanning the local host, instead of the default iquerySecName. Once again, this user must be explicitly created and given suitable access rights.
notificationEvent ENAME NOTIFICATION [-n] [-i OID | -o OID ]*
defines a notification event named ENAME. This can be triggered from a given monitor entry by specifying the option -e ENAME (see above). NOTIFICATION should be the OID of the NOTIFICATION-TYPE definition for the notification to be generated.
If the -n option is given, the notification payload will include the standard varbinds as specified in the OBJECTS clause of the notification MIB definition. This option must come after the NOTIFICATION OID (and the relevant MIB file must be available and loaded by the agent). Otherwise, these varbinds must be listed explicitly (either here or in the corresponding monitor directive).
The -i OID and -o OID options specify additional varbinds to be appended to the notification payload, after the standard list. If the monitor entry that triggered this event involved a wildcarded expression, the suffix of the matched instance will be added to any OIDs specified using -o, while OIDs specified using -i will be treated as exact instances. If the -I flag was specified to the monitor directive, then there is no difference between these two options.
setEvent ENAME [-I] OID = VALUE
defines a set event named ENAME, assigning the (integer) VALUE to the specified OID. This can be triggered from a given monitor entry by specifying the option -e ENAME (see above).
If the monitor entry that triggered this event involved a wildcarded expression, the suffix of the matched instance will normally be added to the OID. If the -I flag was specified to either of the monitor or setEvent directives, the specified OID will be regarded as an exact single instance.
strictDisman yes
The definition of SNMP notifications states that the varbinds defined in the OBJECT clause should come first (in the order specified), followed by any "extra" varbinds that the notification generator feels might be useful. The most natural approach would be to associate these mandatory varbinds with the notificationEvent entry, and append any varbinds associated with the monitor entry that triggered the notification to the end of this list. This is the default behaviour of the Net-SNMP Event MIB implementation.
Unfortunately, the DisMan Event MIB specifications actually state that the trigger-related varbinds should come first, followed by the event-related ones. This directive can be used to restore this strictly-correct (but inappropriate) behaviour.
Note:
Strict DisMan ordering may result in generating invalid notifications payload lists if the notificationEvent -n flag is used together with monitor -o (or -i) varbind options.
If no monitor entries specify payload varbinds, then the setting of this directive is irrelevant.
linkUpDownNotifications yes
will configure the Event MIB tables to monitor the ifTable for network interfaces being taken up or down, and triggering a linkUp or linkDown notification as appropriate.
This is exactly equivalent to the configuration:
notificationEvent  linkUpTrap    linkUp   ifIndex ifAdminStatus ifOperStatus
notificationEvent linkDownTrap linkDown ifIndex ifAdminStatus ifOperStatus

monitor -r 60 -e linkUpTrap "Generate linkUp" ifOperStatus != 2
monitor -r 60 -e linkDownTrap "Generate linkDown" ifOperStatus == 2
defaultMonitors yes
will configure the Event MIB tables to monitor the various UCD-SNMP-MIB tables for problems (as indicated by the appropriate xxErrFlag column objects).
This is exactly equivalent to the configuration:
monitor -o prNames -o prErrMessage "process table" prErrorFlag != 0
monitor -o memErrorName -o memSwapErrorMsg "memory" memSwapError != 0
monitor -o extNames -o extOutput "extTable" extResult != 0
monitor -o dskPath -o dskErrorMsg "dskTable" dskErrorFlag != 0
monitor -o laNames -o laErrMessage "laTable" laErrorFlag != 0
monitor -o fileName -o fileErrorMsg "fileTable" fileErrorFlag != 0

In both these latter cases, the snmpd.conf must also contain a iquerySecName directive, together with a corresponding createUser entry and suitable access control configuration.  

DisMan Schedule MIB

The DisMan working group also produced a mechanism for scheduling particular actions (a specified SET assignment) at given times. This requires that the agent was built with support for the disman/schedule module (which is included as part of the default build configuration for the most recent distribution).

There are three ways of specifying the scheduled action:

repeat FREQUENCY OID = VALUE
configures a SET assignment of the (integer) VALUE to the MIB instance OID, to be run every FREQUENCY seconds.
cron MINUTE HOUR DAY MONTH WEEKDAY OID = VALUE
configures a SET assignment of the (integer) VALUE to the MIB instance OID, to be run at the times specified by the fields MINUTE to WEEKDAY. These follow the same pattern as the equivalent crontab(5) fields.
Note:
These fields should be specified as a (comma-separated) list of numeric values. Named values for the MONTH and WEEKDAY fields are not supported, and neither are value ranges. A wildcard match can be specified as '*'.
The DAY field can also accept negative values, to indicate days counting backwards from the end of the month.
at MINUTE HOUR DAY MONTH WEEKDAY OID = VALUE
configures a one-shot SET assignment, to be run at the first matching time as specified by the fields MINUTE to WEEKDAY. The interpretation of these fields is exactly the same as for the cron directive.
 

EXTENDING AGENT FUNCTIONALITY

One of the first distinguishing features of the original UCD suite was the ability to extend the functionality of the agent - not just by recompiling with code for new MIB modules, but also by configuring the running agent to report additional information. There are a number of techniques to support this, including:
*
running external commands (exec, extend, pass)
*
loading new code dynamically (embedded perl, dlmod)
*
communicating with other agents (proxy, SMUX, AgentX)
 

Arbitrary Extension Commands

The earliest extension mechanism was the ability to run arbitrary commands or shell scripts. Such commands do not need to be aware of SNMP operations, or conform to any particular behaviour - the MIB structures are designed to accommodate any form of command output. Use of this mechanism requires that the agent was built with support for the ucd-snmp/extensible and/or agent/extend modules (which are both included as part of the default build configuration).
exec [MIBOID] NAME PROG ARGS
sh [MIBOID] NAME PROG ARGS
invoke the named PROG with arguments of ARGS. By default the exit status and first line of output from the command will be reported via the extTable, discarding any additional output.
Note:
Entries in this table appear in the order they are read from the configuration file. This means that adding new exec (or sh) directives and restarting the agent, may affect the indexing of other entries.
The PROG argument for exec directives must be a full path to a real binary, as it is executed via the exec() system call. To invoke a shell script, use the sh directive instead.
If MIBOID is specified, then the results will be rooted at this point in the OID tree, returning the exit statement as MIBOID.100.0 and the entire command output in a pseudo-table based at MIBNUM.101 - with one 'row' for each line of output.
Note:
The layout of this "relocatable" form of exec (or sh) output does not strictly form a valid MIB structure. This mechanism is being deprecated - please see the extend directive (described below) instead.
In either case, the exit statement and output will be cached for 30s after the initial query. This cache can be flushed by a SET request of the integer value 1 to the MIB instance versionClearCache.0.
execfix NAME PROG ARGS
registers a command that can be invoked on demand - typically to respond to or fix errors with the corresponding exec or sh entry. When the extErrFix instance for a given NAMEd entry is set to the integer value of 1, this command will be called.
Note:
This directive can only be used in combination with a corresponding exec or sh directive, which must be defined first. Attempting to define an unaccompanied execfix directive will fail.

exec and sh extensions can only be configured via the snmpd.conf file. They cannot be set up via SNMP SET requests.

extend [MIBOID] NAME PROG ARGS
works in a similar manner to the exec directive, but with a number of improvements. The MIB tables (nsExtendConfigTable etc) are indexed by the NAME token, so are unaffected by the order in which entries are read from the configuration files. There are two result tables - one (nsExtendOutput1Table) containing the exit status, the first line and full output (as a single string) for each extend entry, and the other (nsExtendOutput2Table) containing the complete output as a series of separate lines.
If MIBOID is specified, then the configuration and result tables will be rooted at this point in the OID tree, but are otherwise structured in exactly the same way. This means that several separate extend directives can specify the same MIBOID root, without conflicting.
The exit status and output is cached for each entry individually, and can be cleared (and the caching behaviour configured) using the nsCacheTable.
extendfix NAME PROG ARGS
registers a command that can be invoked on demand, by setting the appropriate nsExtendRunType instance to the value run-command(3). Unlike the equivalent execfix, this directive does not need to be paired with a corresponding extend entry, and can appear on its own.

Both extend and extendfix directives can be configured dynamically, using SNMP SET requests to the NET-SNMP-EXTEND-MIB.  

MIB-Specific Extension Commands

The first group of extension directives invoke arbitrary commands, and rely on the MIB structure (and management applications) having the flexibility to accommodate and interpret the output. This is a convenient way to make information available quickly and simply, but is of no use when implementing specific MIB objects, where the extension must conform to the structure of the MIB (rather than vice versa). The remaining extension mechanisms are all concerned with such MIB-specific situations - starting with "pass-through" scripts. Use of this mechanism requires that the agent was built with support for the ucd-snmp/pass and ucd-snmp/pass_persist modules (which are both included as part of the default build configuration).
pass [-p priority] MIBOID PROG
will pass control of the subtree rooted at MIBOID to the specified PROG command. GET and GETNEXT requests for OIDs within this tree will trigger this command, called as:
PROG -g OID
PROG -n OID
respectively, where OID is the requested OID. The PROG command should return the response varbind as three separate lines printed to stdout - the first line should be the OID of the returned value, the second should be its TYPE (one of the text strings integer, gauge, counter, timeticks, ipaddress, objectid, or string ), and the third should be the value itself.
If the command cannot return an appropriate varbind - e.g the specified OID did not correspond to a valid instance for a GET request, or there were no following instances for a GETNEXT - then it should exit without producing any output. This will result in an SNMP noSuchName error, or a noSuchInstance exception.
Note:
The SMIv2 type counter64 and SNMPv2 noSuchObject exception are not supported.
A SET request will result in the command being called as:
PROG -s OID TYPE VALUE
where TYPE is one of the tokens listed above, indicating the type of the value passed as the third parameter.
If the assignment is successful, the PROG command should exit without producing any output. Errors should be indicated by writing one of the strings not-writable, or wrong-type to stdout, and the agent will generate the appropriate error response.
Note:
The other SNMPv2 errors are not supported.
In either case, the command should exit once it has finished processing. Each request (and each varbind within a single request) will trigger a separate invocation of the command.
The default registration priority is 127. This can be changed by supplying the optional -p flag, with lower priority registrations being used in preference to higher priority values.
pass_persist [-p priority] MIBOID PROG
will also pass control of the subtree rooted at MIBOID to the specified PROG command. However this command will continue to run after the initial request has been answered, so subsequent requests can be processed without the startup overheads.
Upon initialization, PROG will be passed the string "PING\n" on stdin, and should respond by printing "PONG\n" to stdout.
For GET and GETNEXT requests, PROG will be passed two lines on stdin, the command (get or getnext) and the requested OID. It should respond by printing three lines to stdout - the OID for the result varbind, the TYPE and the VALUE itself - exactly as for the pass directive above. If the command cannot return an appropriate varbind, it should print print "NONE\n" to stdout (but continue running).
For SET requests, PROG will be passed three lines on stdin, the command (set) and the requested OID, followed by the type and value (both on the same line). If the assignment is successful, the command should print "DONE\n" to stdout. Errors should be indicated by writing one of the strings not-writable, wrong-type, wrong-length, wrong-value or inconsistent-value to stdout, and the agent will generate the appropriate error response. In either case, the command should continue running.
The registration priority can be changed using the optional -p flag, just as for the pass directive.

pass and pass_persist extensions can only be configured via the snmpd.conf file. They cannot be set up via SNMP SET requests.  

Embedded Perl Support

Programs using the previous extension mechanisms can be written in any convenient programming language - including perl, which is a common choice for pass-through extensions in particular. However the Net-SNMP agent also includes support for embedded perl technology (similar to mod_perl for the Apache web server). This allows the agent to interpret perl scripts directly, thus avoiding the overhead of spawning processes and initializing the perl system when a request is received.

Use of this mechanism requires that the agent was built with support for the embedded perl mechanism, which is not part of the default build environment. It must be explicitly included by specifying the '--enable-embedded-perl' option to the configure script when the package is first built.

If enabled, the following directives will be recognised:

disablePerl true
will turn off embedded perl support entirely (e.g. if there are problems with the perl installation).
perlInitFile FILE
loads the specified initialisation file (if present) immediately before the first perl directive is parsed. If not explicitly specified, the agent will look for the default initialisation file /usr/local/share/snmp/snmp_perl.pl.
The default initialisation file creates an instance of a NetSNMP::agent object - a variable $agent which can be used to register perl-based MIB handler routines.
perl EXPRESSION
evaluates the given expression. This would typically register a handler routine to be called when a section of the OID tree was requested:
perl use Data::Dumper;
perl sub myroutine { print "got called: ",Dumper(@_),"\n"; }
perl $agent->register('mylink', '.1.3.6.1.8765', \&myroutine);
This expression could also source an external file:
perl 'do /path/to/file.pl';
or perform any other perl-based processing that might be required.
 

Dynamically Loadable Modules

Most of the MIBs supported by the Net-SNMP agent are implemented as C code modules, which were compiled and linked into the agent libraries when the suite was first built. Such implementation modules can also be compiled independently and loaded into the running agent once it has started. Use of this mechanism requires that the agent was built with support for the ucd-snmp/dlmod module (which is included as part of the default build configuration).
dlmod NAME PATH
will load the shared object module from the file PATH (an absolute filename), and call the initialisation routine init_NAME.
Note:
If the specified PATH is not a fully qualified filename, it will be interpreted relative to /usr/local/lib/snmp/dlmod, and .so will be appended to the filename.

This functionality can also be configured using SNMP SET requests to the UCD-DLMOD-MIB.  

Proxy Support

Another mechanism for extending the functionality of the agent is to pass selected requests (or selected varbinds) to another SNMP agent, which can be running on the same host (presumably listening on a different port), or on a remote system. This can be viewed either as the main agent delegating requests to the remote one, or acting as a proxy for it. Use of this mechanism requires that the agent was built with support for the ucd-snmp/proxy module (which is included as part of the default build configuration).
proxy [-Cn CONTEXTNAME] [SNMPCMD_ARGS] HOST OID [REMOTEOID]
will pass any incoming requests under OID to the agent listening on the port specified by the transport address HOST. See the section LISTENING ADDRESSES in the snmpd(8) manual page for more information about the format of listening addresses.
Note:
To proxy the entire MIB tree, use the OID .1.3 (not the top-level .1)

The SNMPCMD_ARGS should provide sufficient version and administrative information to generate a valid SNMP request (see snmpcmd(1)).

Note:
The proxied request will not use the administrative settings from the original request.

If a CONTEXTNAME is specified, this will register the proxy delegation within the named context in the local agent. Defining multiple proxy directives for the same OID but different contexts can be used to query several remote agents through a single proxy, by specifying the appropriate SNMPv3 context in the incoming request (or using suitable configured community strings - see the com2sec directive).

Specifying the REMOID parameter will map the local MIB tree rooted at OID to an equivalent subtree rooted at REMOID on the remote agent.  

SMUX Sub-Agents

The Net-SNMP agent supports the SMUX protocol (RFC 1227) to communicate with SMUX-based subagents (such as gated, zebra or quagga). Use of this mechanism requires that the agent was built with support for the smux module, which is not part of the default build environment, and must be explicitly included by specifying the '--with-mib-modules=smux' option to the configure script when the package is first built.
Note:
This extension protocol has been officially deprecated in favour of AgentX (see below).
smuxpeer OID PASS
will register a subtree for SMUX-based processing, to be authenticated using the password PASS. If a subagent (or "peer") connects to the agent and registers this subtree then requests for OIDs within it will be passed to that SMUX subagent for processing.
A suitable entry for an OSPF routing daemon (such as gated, zebra or quagga) might be something like
smuxpeer .1.3.6.1.2.1.14 ospf_pass
smuxsocket <IPv4-address>
defines the IPv4 address for SMUX peers to communicate with the Net-SNMP agent. The default is to listen on all IPv4 interfaces ("0.0.0.0"), unless the package has been configured with "--enable-local-smux" at build time, which causes it to only listen on 127.0.0.1 by default. SMUX uses the well-known TCP port 199.

Note the Net-SNMP agent will only operate as a SMUX master agent. It does not support acting in a SMUX subagent role.  

AgentX Sub-Agents

The Net-SNMP agent supports the AgentX protocol (RFC 2741) in both master and subagent roles. Use of this mechanism requires that the agent was built with support for the agentx module (which is included as part of the default build configuration), and also that this support is explicitly enabled (e.g. via the snmpd.conf file).

There are two directives specifically relevant to running as an AgentX master agent:

master agentx
will enable the AgentX functionality and cause the agent to start listening for incoming AgentX registrations. This can also be activated by specifying the '-x' command-line option (to specify an alternative listening socket).
agentXPerms SOCKPERMS [DIRPERMS [USER|UID [GROUP|GID]]]
Defines the permissions and ownership of the AgentX Unix Domain socket, and the parent directories of this socket. SOCKPERMS and DIRPERMS must be octal digits (see chmod(1) ). By default this socket will only be accessible to subagents which have the same userid as the agent.

There is one directive specifically relevant to running as an AgentX sub-agent:

agentXPingInterval NUM
will make the subagent try and reconnect every NUM seconds to the master if it ever becomes (or starts) disconnected.

The remaining directives are relevant to both AgentX master and sub-agents:

agentXSocket [<transport-specifier>:]<transport-address>[,...]
defines the address the master agent listens at, or the subagent should connect to. The default is the Unix Domain socket "/var/agentx/master". Another common alternative is tcp:localhost:705. See the section LISTENING ADDRESSES in the snmpd(8) manual page for more information about the format of addresses.
Note:
Specifying an AgentX socket does not automatically enable AgentX functionality (unlike the '-x' command-line option).
agentXTimeout NUM
defines the timeout period (NUM seconds) for an AgentX request. Default is 1 second.
agentXRetries NUM
defines the number of retries for an AgentX request. Default is 5 retries.

net-snmp ships with both C and Perl APIs to develop your own AgentX subagent.  

OTHER CONFIGURATION

override [-rw] OID TYPE VALUE
This directive allows you to override a particular OID with a different value (and possibly a different type of value). The -rw flag will allow snmp SETs to modify it's value as well. (note that if you're overriding original functionality, that functionality will be entirely lost. Thus SETS will do nothing more than modify the internal overridden value and will not perform any of the original functionality intended to be provided by the MIB object. It's an emulation only.) An example:
override sysDescr.0 octet_str "my own sysDescr"
That line will set the sysDescr.0 value to "my own sysDescr" as well as make it modifiable with SNMP SETs as well (which is actually illegal according to the MIB specifications).
Note that care must be taken when using this. For example, if you try to override a property of the 3rd interface in the ifTable with a new value and later the numbering within the ifTable changes it's index ordering you'll end up with problems and your modified value won't appear in the right place in the table.
Valid TYPEs are: integer, uinteger, octet_str, object_id, counter, null (for gauges, use "uinteger"; for bit strings, use "octet_str"). Note that setting an object to "null" effectively delete's it as being accessible. No VALUE needs to be given if the object type is null.
More types should be available in the future.

If you're trying to figure out aspects of the various mib modules (possibly some that you've added yourself), the following may help you spit out some useful debugging information. First off, please read the snmpd manual page on the -D flag. Then the following configuration snmpd.conf token, combined with the -D flag, can produce useful output:

injectHandler HANDLER modulename
This will insert new handlers into the section of the mib tree referenced by "modulename". The types of handlers available for insertion are:
stash_cache
Caches information returned from the lower level. This greatly help the performance of the agent, at the cost of caching the data such that its no longer "live" for 30 seconds (in this future, this will be configurable). Note that this means snmpd will use more memory as well while the information is cached. Currently this only works for handlers registered using the table_iterator support, which is only a few mib tables. To use it, you need to make sure to install it before the table_iterator point in the chain, so to do this:


                  injectHandler stash_cache NAME table_iterator

If you want a table to play with, try walking the nsModuleTable with and without this injected.

debug
Prints out lots of debugging information when the -Dhelper:debug flag is passed to the snmpd application.
read_only
Forces turning off write support for the given module.
serialize
If a module is failing to handle multiple requests properly (using the new 5.0 module API), this will force the module to only receive one request at a time.
bulk_to_next
If a module registers to handle getbulk support, but for some reason is failing to implement it properly, this module will convert all getbulk requests to getnext requests before the final module receives it.
dontLogTCPWrappersConnects
If the snmpd was compiled with TCP Wrapper support, it logs every connection made to the agent. This setting disables the log messages for accepted connections. Denied connections will still be logged.
Figuring out module names
To figure out which modules you can inject things into, run snmpwalk on the nsModuleTable which will give a list of all named modules registered within the agent.
 

Internal Data tables

table NAME
add_row NAME INDEX(ES) VALUE(S)
 

NOTES

o
The Net-SNMP agent can be instructed to re-read the various configuration files, either via an snmpset assignment of integer(1) to UCD-SNMP-MIB::versionUpdateConfig.0 (.1.3.6.1.4.1.2021.100.11.0), or by sending a kill -HUP signal to the agent process.
o
All directives listed with a value of "yes" actually accept a range of boolean values. These will accept any of 1, yes or true to enable the corresponding behaviour, or any of 0, no or false to disable it. The default in each case is for the feature to be turned off, so these directives are typically only used to enable the appropriate behaviour.

Trackback 11 Comment 1
  1. Favicon of https://blog.pages.kr 날으는물고기 2009.04.08 16:59 신고 address edit & del reply

    원문 출처 : http://www.net-snmp.org/docs/man/snmpd.conf.html

2009. 2. 24. 11:05

RRDTOOL을 이용한 모니터링 툴 CACTI (on FreeBSD)

제  목 : RRDTOOL을 이용한 모니터링 툴 CACTI (on FreeBSD)
작성자 : 정경환 (환건 : WHAN_GUN : http://www.whangun.com)
작성일 : 2005년 9월 6일


디자인이 심심하기 그지없는 MRTG에서 벗어나 좀 더 컬러풀한 RRDTOOL에 끌린 환건. 그래서 RRDTOOL을 이용한 모니터링 툴을 알아보던 중 황보진호(좋은진호)님께서 운영하시는 커피닉스(coffeenix)에서 cacti라는 툴을 알게되었다. 그게 한 6개월인가 8개월 전으로 기억한다.


백문이 불여일견 아니던가? cacti의 모습이 궁금하신 분은 아래의 사이트에 가서 확인하자.
http://www.cacti.net/ (공식 사이트)
http://www.cacti.net/screenshots.php (스크린샷)


여기에 가면 cacti를 쓰고있는 사이트들의 실제 cacti 자료를 볼 수 있다.
http://cacti.net/sites_that_use_cacti.php


웹브라우저를 이용해 공유기 설정을 쉽게 할 수 있듯 cacti도 한 번 설치해 놓으면 웹브라우저를 통해 누구나 쉽게 snmp를 지원하는 장비를 모니터링 할 수 있다. 라우터, 허브, 서버(에 snmp설치 필요) 모두 가능하다.


자 그럼 설치를 시작해보자.


우선 FreeBSD상에서 cacti를 돌리기 위해서는 snmp 툴이 필요하다. ucd-snmp 4.x 와 net-snmp 5.x 둘 중에 하나를 설치해야 한다. (ucd-snmp가 5.x대로 오면서 이름이 net-snmp로 바뀜)


# cd /usr/ports/net-mgmt/net-snmp
# make install clean


설치를 마쳤는가? 설치 끝부분의 안내메세지 대로 /etc/rc.conf에 다음의 내용을 추가한다.

 

snmpd_enable="YES"
snmpd_flags="-a -p /var/run/snmpd.pid"
snmptrapd_enable="YES"
snmptrapd_flags="-a -p /var/run/snmptrapd.pid"


/usr/local/etc/rc.d/ 밑에 snmpd.sh 와 snmptrapd.sh 파일이 생겼을 것이다. 이것들이 서버 시동시에 자동으로 snmp를 띄워주는 역할을 한다.


이제 rrdtool을 설치하러 가자. rrdtool은 1.0.x대 버젼과 1.2.x대 버젼이 있는데 우리는 1.0.x대 버젼을 쓰기로 하자. (1.2.x 도 문제없이 잘 작동하지만 그래프 모양이 이쁘지가 않다 -_-;;)


# cd /usr/ports/net/rrdtool10
# make install clean


끝났다. 다음 cacti를 설치하러 가자. 2005년 9월 6일 현재 최신 버젼은 0.8.6f 이다.


# cd /usr/ports/net/cacti
# make install clean


설치 끝에 우리가 해야할 7단계를 영어로 설명해 놓았다.

 

1: Create the MySQL database:
# mysqladmin --user=root create cacti


2: Create a mysql user/password for cacti:
(change user and/or password if requered)
# echo "GRANT ALL ON cacti.* TO cactiuser at localhost IDENTIFIED BY 'cactiuser'; FLUSH PRIVILEGES;" | mysql


3: Import the default cacti database:
# mysql cacti < /usr/local/share/cacti/cacti.sql


4: Edit share/cacti/include/db-settings.php:
Specify the MySQL user, password and database for your cacti configuration.


5: Add a line to your /etc/crontab file similar to:
*/5 * * * * cacti /usr/local/bin/php /usr/local/share/cacti/poller.php > /dev/null 2>&1


6: Add alias in apache config for the cacti dir:
Alias /cacti "/usr/local/share/cacti/"


7: Open cacti login page in your web browser and login with admin/admin


1: MySQL 데이터베이스 만들기:
# mysqladmin --user=root -p create cacti
(-p를 붙여줘야 root 패스워드를 물어보게 된다)


2: cacti를 위한 MySQL 아이디와 패스워드 만들기
(필요하다면 아이디와 패스워드는 변경해도 좋다)
GRANT ALL ON cacti.* TO cactiuser at localhost IDENTIFIED BY 'cactiuser'; FLUSH PRIVILEGES;
(원본 설명대로 해도되고 mysql -uroot -p 를 실행해서 mysql client 로 들어가서 바로윗줄대로 입력해도 된다)


입력을 다 했으면 다시 쉘로 나와서


3: 기본 cacti 데이터베이스 불러들이기:
# mysql -ucacti -p cacti < /usr/local/share/cacti/cacti.sql


4: /usr/local/share/cacti/include/db-settings.php 수정하기:
MySQL 관련설정을 cacti 데이터베이스 계정에 맞게 설정해준다.


5: /etc/crontab 파일에 아래와 같이 추가해 준다:
*/5 * * * * cacti /usr/local/bin/php /usr/local/share/cacti/poller.php > /dev/null 2>&1


6: 아파치 설정 파일에 cacti 디렉토리 Alias 설정하기:
Alias /cacti "/usr/local/share/cacti/"


7: cacti 로그인 페이지를 웹브라우저에서 불러들여 ID : admin PW admin 으로 로그인 하자:

 


여기까지 마쳤다면 설치가 거의 끝났다고 보아도 무방하다. 이제 /usr/local/share/snmp/snmpd.conf 파일 설정과 웹브라우저에서 cacti 그래프를 설정해 주기만 하면 된다.


/usr/local/share/snmp 디렉토리에 보면 snmpd.conf.example 파일이 하나 있다. snmpd.conf 로 복사해 주고나서 수정을 해 주면 되는데 딱히 어려운 것은 없으니 그냥 보고 해도 될것이나 혹시나 해서 필자의 설정치를 올려놓는다.

 

root@www.k1004.net /usr/local/share/snmp# cat snmpd.conf
##################################################################
#
# snmpd.conf
#
# $Id: snmpd.conf,v 1.6 2004/03/21 02:53:06 matt Exp $
#
##################################################################
# SECTION: System Information Setup
#
#  This section defines some of the information reported in
#  the "system" mib group in the mibII tree.

# syslocation: The [typically physical] location of the system.
#  Note that setting this value here means that when trying to
#  perform an snmp SET operation to the sysLocation.0 variable will make
#  the agent return the "notWritable" error code. IE, including
#  this token in the snmpd.conf file will disable write access to
#  the variable.
#  arguments: location_string

syslocation "Seoul, Korea"

# syscontact: The contact information for the administrator
#  Note that setting this value here means that when trying to
#  perform an snmp SET operation to the sysContact.0 variable will make
#  the agent return the "notWritable" error code. IE, including
#  this token in the snmpd.conf file will disable write access to
#  the variable.
#  arguments: contact_string

syscontact whangun[at}hothothotmail.com

 

##################################################################
# SECTION: Access Control Setup
#
#  This section defines who is allowed to talk to your running
#  snmp agent.

# rwuser: a SNMPv3 read-write user
#  arguments: user [noauth|auth|priv] [restriction_oid]

#rwuser password-goes-here

# rouser: a SNMPv3 read-only user
#  arguments: user [noauth|auth|priv] [restriction_oid]

rouser monitoring noauth

# rocommunity: a SNMPv1/SNMPv2c read-only access community name
#  arguments: community [default|hostname|network/bits] [oid]

rocommunity monitoring localhost
rocommunity monitoring 203.252.160.111

# rwcommunity: a SNMPv1/SNMPv2c read-write access community name
#  arguments: community [default|hostname|network/bits] [oid]

rwcommunity password-goes-here localhost
rwcommunity password-goes-here 203.252.160.111


##################################################################
# SECTION: Monitor Various Aspects of the Running Host
#
#  The following check up on various aspects of a host.

# proc: Check for processes that should be running.
#   proc NAME [MAX=0] [MIN=0]

#   NAME: the name of the process to check for. It must match
#        exactly (ie, http will not find httpd processes).
#   MAX:  the maximum number allowed to be running. Defaults to 0.
#   MIN:  the minimum number to be running. Defaults to 0.

#  The results are reported in the prTable section of the UCD-SNMP-MIB tree
#  Special Case: When the min and max numbers are both 0, it assumes
#  you want a max of infinity and a min of 1.

proc sshd 10 1
proc httpd 10 3
proc imapd 0 1
proc mysqld 1 1

# disk: Check for disk space usage of a partition.
#  The agent can check the amount of available disk space, and make
#  sure it is above a set limit.

#   disk PATH [MIN=100000]

#   PATH: mount path to the disk in question.
#   MIN:  Disks with space below this value will have the Mib's errorFlag set.
#       Can be a raw byte value or a percentage followed by the %
#       symbol. Default value = 100000.

#  The results are reported in the dskTable section of the UCD-SNMP-MIB tree

disk /   20%
disk /usr 10%
disk /var 10%
disk /tmp 10%
disk /home 10%

# load: Check for unreasonable load average values.
#  Watch the load average levels on the machine.

#   load [1MAX=12.0] [5MAX=12.0] [15MAX=12.0]

#   1MAX:  If the 1 minute load average is above this limit at query
#        time, the errorFlag will be set.
#   5MAX:  Similar, but for 5 min average.
#   15MAX: Similar, but for 15 min average.

#  The results are reported in the laTable section of the UCD-SNMP-MIB tree

load 12 12 12

 

##################################################################
# SECTION: Extending the Agent
#
#  You can extend the snmp agent to have it return information
#  that you yourself define.

# exec: run a simple command using exec()
#  arguments: [oid] name /path/to/executable arguments

#exec  WebHits "/usr/local/sbin/logmonster" " -d -r -q"

# sh: run a simple command using system()
#  arguments: [oid] name command arguments
#  similar to exec, but implemented using system() instead of exec()

#  For security reasons, exec should be preferred.

sh  WebHits /usr/local/sbin/logmonster "-d -r -q"
sh  MailDeliv /usr/local/sbin/maillogs "send"
sh  MailSMTP /usr/local/sbin/maillogs "smtp"
sh  MailPOP3 /usr/local/sbin/maillogs "pop3"
sh  MailIMAP /usr/local/sbin/maillogs "imap"
sh  MailRBL  /usr/local/sbin/maillogs "rbl"
sh  MailWeb  /usr/local/sbin/maillogs "webmail"
sh  MailSpam /usr/local/sbin/maillogs "spamassassin"
sh  MailQS   /usr/local/sbin/maillogs "qmailscanner"
sh  MysqlType /usr/local/sbin/mysqlstatus.pl "type"
sh  MysqlQueries /usr/local/sbin/mysqlstatus.pl "queries"
sh     ApacheStats /usr/local/sbin/apastat.pl "localhost"
#sh  MbmonTemp /usr/local/sbin/mbmonstatus.pl "temp"
#sh  MbmonVolt /usr/local/sbin/mbmonstatus.pl "volt"
#sh  MbmonFan /usr/local/sbin/mbmonstatus.pl "fan"


처음 cacti를 사용하면서 한 가지 애먹은게 바로 이 부분이다.


rouser monitoring noauth

# rocommunity: a SNMPv1/SNMPv2c read-only access community name
#  arguments: community [default|hostname|network/bits] [oid]

rocommunity monitoring localhost
rocommunity monitoring 203.252.160.111


monitoring 이라고 되어있는데 cacti 설정에는 monitoring이 기본값이 아니기 때문에 snmp를 못찾는 상황이 발생했었다 -_-;


이제 웹브라우저를 통해 cacti 페이지에 로그인을 하자.
필자의 경우 cacti.whangun.com 으로 설정해 놓았다.


왼쪽에 Configuration 밑에 Settings를 눌러 설정페이지로 간다.
SNMP Utility Version 과 RRDTool Utility Version 부분의 버젼이 맞게 설정되어 있는지 확인한 후에 SNMP Version을 2로 해주고 SNMP Community 부분을 monitoring으로 해준다. 아까 snmpd.conf에서 설정한 바로 그 값이다.


SNMP Port Number 는 기본값이 161이므로 그대로 두고 저장을 누르자.


General 탭은 끝났고 Path 탭에서 경로가 제대로 설정되어 있는지 확인한 후에 왼쪽에 Management 섹션에서 Devices를 눌러보자.


여기서 우측 상단에 Add버튼을 눌러 자신의 호스트를 입력을 하자. 혹시 필요할까 싶어 설정이 완료된 필자의 서버 설정치를 적어둔다.

 

WHANGUN.COM (localhost)
SNMP Information
System: FreeBSD www.k1004.net 4.11-RELEASE-p11 FreeBSD 4.11-RELEASE-p11 #0: Tu i386
Uptime: 315735
Hostname: www.k1004.net


Description : WHANGUN.COM
Hostname : localhost
Host Template : ucd/net SNMP Host
SNMP Community : monitoring
SNMP Version : v2
SNMP Port : 161


Associated Graph Templates 부분과 Associated Data Queries부분은 Add를 눌러 추가를 하면 되는데 필자의 셋팅은 다음과 같다.

 

Associated Graph Templates

Graph Template Name Status
1) ucd/net - CPU Usage Is Being Graphed (Edit)  
2) ucd/net - Memory Usage Is Being Graphed (Edit)  
3) Unix - Load Average Is Being Graphed (Edit)  
4) Unix - Logged in Users Is Being Graphed (Edit)  
5) Unix - Ping Latency Is Being Graphed (Edit)  
6) Unix - Processes Is Being Graphed (Edit) 


Associated Data Queries

Data Query Name Debugging Re-Index Method Status
1) SNMP - Get Processor Information (Verbose Query) Verify All Fields Success [1 Item, 1 Row]   
2) SNMP - Interface Statistics (Verbose Query) Verify All Fields Success [14 Items, 2 Rows]   
3) Unix - Get Mounted Partitions (Verbose Query) Verify All Fields Success [0 Items, 0 Rows]

 

설정을 저장하고 Create 섹션의 New Graphs 로 가자. 여기에서 그래프를 추가해 주면 이제 끝나게 된다. 기본적으로 담겨있는 그래프 외에도 Cacti 사이트에는 여러가지 그래프들의 스크립트가 올라와 있으므로 추가해서 쓸 수도 있음을 기억하자.


다 되었으면 이제 Graph 탭에서 확인해 보자. 왼쪽에 자기 호스트 이름을 눌러주는 센스도 잊지 말 것. (트리를 누르지 않고 바로 그래프가 보이게 하려면 우측 상단에 Setting로 가서 Default View Mode 값을 List View로 설정하고 저장하면 된다)


그래프들이 잘 보인다면 성공! 아니라면 삽질의 길로!
안된다면 Cacti 공식 사이트에 있는 도큐먼트를 참고해 보도록 하자.


http://www.cacti.net/documentation.php
http://www.cacti.net/downloads/docs/html/install_unix.html


Trackback 1 Comment 0