본문 바로가기
IT Security/LINUX Basic

38. Linux - SNMPv1/v2를 사용한 서버 원격 모니터링

by Rosmary 2021. 9. 18.
728x90
반응형

 

 

 

 

 

업무 진행 중에 새로운 지식을 쌓게되는 경우에만 Linux 관련 글을 쓰게 되는 듯 하다. 조금 더 부지런하고 싶지만, 우선 돈을 벌어야 하니... 이번에 필자가 Linux 관련 포스팅을 진행할 주제는 SNMP다. 

 

 

1. SNMP란?

 

SNMP는 Small Network Management Protocol의 약자다. 쉽게 말하면 네트워크 상에 존재하는 서버, PC등을 관리하는 프로토콜이라고 보면 된다. 필자가 쉽게 설명했지만 아직까지는 감이 잘 오지 않을 것이다. 

 

필자가 네트워크 운영자라고 해보자. 네트워크 운영에 필요한 방화벽은 물론이거니와, 라우터, 스위치, 그리고 기타 솔루션 제품군까지 운영자가 관리해야하는 제품은 매우 많다. 문제는 이 장비들이 이상없이 잘 동작하고 있는지 주기적으로 점검을 진행해야하는데, 이를 위해 각 장비마다 SSH접속을 해서 서로 다른 명령어를 일일이 날리며 메모리나 디스크 사용량 등을 관리하는게 여간 귀찮은 일이 아닐 수 없다. 

 

이런 식으로 화면을 띄워서 하나씩 명령어를 날리며 상태를 살펴야된다.... 

 

이들을 하나의 서버에서 모니터링 할 수 있는 방법이 있을까?? 라는 물음에서 출발한 것이 바로 SNMP라고 보면 된다. 즉, SNMP Manager(서버)의 역할을 하는 Linux 또는 기타 OS 서버에서 SNMP Agent(클라이언트)가 설치된 모든 PC, 서버의 정보를 명령어 하나로 호출할 수 있도록 만든 것이 SNMP 프로토콜이다.

 

 

2. SNMP 통신

 

SNMP 프로토콜은 상황에 따라 서로 다른 포트를 사용한다. 우선 SNMP가 어떤 방식으로 모니터링 할 서버의 정보를 수집하는지 알아야한다. 크게 두 가지 방식이 있는데, 하나는 Manager에서 Agent로 정보를 요청하는 Polling 방식, 두 번재는 모니터링 대상 장비에서 이벤트 발생 시 Agent에서 Manager로 정보를 전송하는 Reporting 방식이다.

 

Polling의 경우, Agent 설치 장비의 UDP/161을 목적지로 통신이 진행된다. 요청을 받은 Agent도 UDP/161을 출발지로 Manager에게 정보를 전송한다. 반면, Event Reporting 방식은 Agent 설치 장비에 이슈 발생 시, Agent에서 Manager의 UDP/162 포트를 목적지로 에러에 대한 정보를 전송한다. 그림으로 그리면 대충 아래와 같은 모양이다. 

 

 

그럼, 지금부터 본격적으로 SNMP 관련 패키지를 Linux에 설치하고 동작을 확인해보자. 

 

 

 

3. SNMP 서비스 패키지 설치

 

SNMP는 크게 매니저와(모니터링 진행) 에이전트(모니터링 대상)로 나뉜다고 위에서 언급했다. 따라서 매니저와 에이전트가 SNMP 서비스 사용을 위해 설치해야 하는 패키지도 분리되어 있다.  에이전트 서비스를 위한 패키지는 net-snmp가 있으며, 매니저 서비스를 위한 패키지는 net-snmp-utils라는 이름으로 존재한다. 그러나 net-snmp의 경우, net-snmp-utils와 함께 매니저에 설치하는 경우가 대부분인데, 매니저로 동작하는 서버 역시 시스템 상황을 항시 확인해야 할 필요가 있기 때문이다.

 

필자는 테스트를 위해 VMware에 CentOS 7 2개를 올리고, 하나는 매니저, 하나는 에이전트로 동작하도록 설정하려 한다. 이 두 서버 모두 net-snmp 패키지를 설치하고, 추가로 매니저에는 net-snmp-utils 패키지를 설치해준다.

 

** SNMP 매니저 서버 IP   :  172.30.1.50(snmpmanger.rosmary.com)   -> net-snmp, net-snmp-utils 패키지 설치

** SNMP 에이전트 서버 IP:  172.30.1.15(snmpagent.rosmary.com)     ->  net-snmp 패키지 설치 

 

!!  필자가 에이전트 서버는 net-snmp만 설치하는 것으로 작성했지만, net-snmp-utils도 같이 설치하는 것을 권장한다. 뒤에서 후술할 OID 확인을 위해 net-snmp-utils 패키지의 명령어가 필요하기 때문이다.

 

SNMP 매니저에 net-snmp 및 net-snmp-utils 패키지 설치 화면. 이전에 설치를 했다가 지운 탓에 의존성 패키지는 거의 보이지 않는다.

 

 

설치가 완료되고 나면, 매니저 서버는 snmpd와 snmpwalk라는 명령어가 사용가능하게 되며, 에이전트 서버는 snmpd 명령어만 사용가능하게 된다. 단, snmpd 명령어는 단순히 프롬프트만 떨어질 뿐 어떠한 결과도 돌려주지 않는다.

 

 

 

 

 

 

4. SNMP Agent 설정  (/etc/snmp/snmpd.conf)

 

매니저 서버는 snmpwalk 명령어(net-snmp_utils 패키지에 존재한다)를 통해 에이전트 서버의 정보를 수집한다. 하지만 에이전트는 매니저서버가 달라는 대로 무작정 정보를 전달해주지 않는다. 당연한 이야기지만, 외부에서 누군가가 함부로 내부 서버에 대한 정보를 탈취할 수도 있기 때문이다. 

 

이 때문에, 에이전트 서버는 자신의 정보를 전달받을 서버, 전달받을 정보 등을 기록하는 설정 파일을 가지고 있다. 대부분의 서비스 설정파일이 그렇듯이, snmpd 설정 파일도 /etc/ 폴더 아래에 위치한다. 경로는 아래와 같다.

 

** SNMPd 설정파일 경로: /etc/snmp/snmpd.conf

 

워낙 민감한 서버 정보 전달과 관련된 파일이다보니, root만 읽고 쓰는 것이 가능하다.

 

이 파일을 vi로 열고 들어가면 15번째 줄에 Access Control이라는 부분이 보이며, 이 아래에 다음과 같이 4 부분으로 구분할 수 있다.

 

 

이 4 부분을 하나씩 살펴보자. 

 

[Security]

먼저 Security를 설정하는 부분이다. 이 부분은 에이전트 서버로부터 정보를 들고 갈 수 있는 매니저 서버 IP, 그리고, 정보를 들고 갈 때 사용할 인증키(Community String) 값을 지정하는 부분이다. 포맷은 아래와 같다. 

 

com2sec      {Security_Name}    {매니저 서버IP 또는 Domain 주소}   {Community String 값}

** 붉은 글씨는 사용자가 임의로 지정해서 사용하면 된다.

** 매니저 서버의 Domain 주소는 DNS 또는 /etc/resolv.conf에 주소 정보가 등록되어야 사용가능하다. 자세한 것은 DNS 관련 포스팅를 참조하자.

 

 

[Group]

다음으로 위에서 설정한 Security를 그룹핑하는 설정을 진행한다. Group 작성 포맷은 아래와 같다.

 

group  {group_Name}    {SNMP 버전 설정}   {Security Name}

** 붉은 글씨는 사용자가 임의로 지정해서 사용하면 된다.

** SNMP 버전은 v1 또는 v2c 중 하나를 작성한다. 

** Security Name은 임의로 설정한 Security Name 중 하나를 입력한다.

 

예시로 작성된 설정 내용을 보면 NotConfigUser Security가 notConfigGroup에 포함되어 있음을 알 수 있다. 그룹명과 Security 이름 사이에 SNMP 버전을 작성하는 부분이 있는데, 기본적으로 v1과 v2c를 입력한다. 

 

[View]

세 번째는 view를 작성하는 부분이다. view는 매니저에서 에이전트 호출 시 기본적으로 보여주고자 하는 정보를 정의하는 부분이라고 보면 된다. 예시를 보면, subtree에 번호가 나열되어 있는 것이 보이는데, 상단의 것은 System 정보를 표시하는 번호(OID라고 한다. 조금 뒤에 설명한다)이고, 하단의 것은 System Uptime과 관련된 정보를 표시하는 번호다. 

 

즉, view는 기본적으로 에이전트의 정보 중 보여주고자 하는 정보만을 정의하는 부분이며, 이들 역시 view name을 통해 효율적인 관리를 진행한다. 포맷은 아래와 같다. 

 

view  {view_Name}   {정보 표시/제외 여부}     {표시(또는 제외)할 OID 번호}

** 붉은 글씨는 사용자가 임의로 지정해서 사용하면 된다.

** included, excluded 중 하나 입력

 

 

[권한]

마지막 부분은 권한과 관련된 부분이다. SNMP를 통해 서버의 정보를 읽을 수도 있지만, 매니저에서 에이전트의 특정 값을 변화시키도록 하는 것도 가능하다. 즉, 매니저 서버에서 에이전트 서버에 읽기/쓰기 권한을 지정하는 부분이라고 보면 된다. 포맷은 아래와 같다.

 

access    {group_name}    {context}    {sec.model}    {sec.level}   {prefix}   {read권한}  {write권한}   {notif권한}

** group_name은 위에서 설정한 group명, 즉 매니저 서버에 대한 정보를 작성하는 부분이다.

** context는 우리말로 문맥이라고 해석이 되는데, 요청한 정보에서 특정 문구와 일치하는 부분이 있는지 확인하는 설정 내용인 듯 하다. 필수로 입력해야 하는 사항은 아니며 빈 값("")으로 보통 사용하는 듯 하다. 

** sec.model은 SNMP 버전을 나타낸다. v1, v2c, any 중 사용하고자 하는 버전을 입력한다.

** sec.level은 SNMPv1/v2 사용 시, non_auth값으로 지정하여 사용한다. 

** prefix는 Context와 연관이 있는 설정값이다. context의 값과 정확히 일치하는 정보를 표시할지 결정한다. exact 또는 prefix로 설정한다.

** 각 권한은 읽기, 쓰기, 서버 이슈 발생 시 매니저 서버의 UDP/162로 정보를 전달하는 권한을 지정하는 부분이다. 권한을 주지 않고자 한다면 none을, 특정 view에 권한을 주고자 한다면 view_name을 작성해주면 된다.

 

 

 

 

5. MiB와 OID

 

SNMP를 사용하면서 반드시 접하는 개념 중 하나가 바로 MiB와 OID이다. 이들은 각각 Management Information Base, Object IDentifier의 줄임말인데, 사실상 이 둘은 동일한 것을 가리키며 이름만 다르다. MiB와 OID는 서버에서 SNMP로 제공할 정보를 정의한 일종의 데이터베이스라고 보면 된다. 먼저 MiB에 대해 알아보고, 그 다음으로 OID에 대해 알아보자.

 

 

[MiB]

리눅스에서 SNMP로 정보를 제공할 MiB 파일들은 /usr/share/snmp/mibs 경로로 이동하면 확인할 수 있다.

이 경로에 나타나는 파일들이 MiB 파일들이며 일반 텍스트 파일로 정의되어 있다. MiB는 제공할 정보의 종류 또는 기능에 따라 여러 파일로 나누어진다. 가령 예를 들어, 이 경로 내에 위차한 IP-MIB.txt 파일은 시스템의 IP 및 interface 관련 정보를 제공하기 위한 내용이 정의되어 있다.

 

말로는 어려우니 파일 하나를 열어보자. 위에서 설명한 IP-MIB.txt 파일을 cat이나 vi로 열어보면, 가장 아래쪽에 이 MiB에서 사용가능한 객체명들이 정의되어 있다. 

 

 

매니저에서 에이전트의 특정 정보를 MiB를 사용하여 호출할 때, MiB명::객체명으로 호출하게 된다. 예를 들어, IP-MIB에는 서버의 인터페이스 정보를 표시하는 ipAdEntAddr이라는 객체가 존재하는데, 매니저에서 에이전트 서버에서 이 정보를 보고자 하는 경우, MiB를 IP-MIB::ipAdEntAddr로 호출하면 된다.

 

[OID]

OID는 글자로 표현된 MiB를 숫자 형태로 나타낸 것이라 보면 된다. 이 OID 값은 서버 OS 종류에 따라 각기 다르기 떄문에, 제조사에 문의를 해서 받아야만 하는 값이다. 다행히 Linux는 오픈 소스 OS라, 이 정보가 인터넷에 돌아다니기도 하고, net-snmp-utils 내에 존재하는 명령어로 이 구조를 보는 것도 가능하다. 

 

OID는 일종의 트리 구조로 구성되어 있다. net-snmp-utils 패키지가 설치된 매니저 서버에서 아래의 명령어를 치면 일종의 트리 구조가 화면에 쭈루룩 출력되는 것을 볼 수 있다.

 

# 명령어:  snmptranslate -Tp

 

snmp 설정파일에서 View 부분을 정의할 때, .1.3.x.x.x.와 같은 숫자가 입력된 것을 예시에서 보았을 것인데, 이 숫자를 이 트리로부터 획득할 수 있다. view의 예시를 다시 보면, 숫자 1.3.6.1.2.1.1은 서버의 System에 대한 전체 내용을 의미하며, 1.3.6.1.2.1.25.1.1은 시스템 Uptime과 관련된 부분을 의미하게 된다.

 

OID 값을 MIB로 확인하고 싶은 경우, 아래의 명령어를 사용하면 된다.

# 명령어:  snmptranslate {OID값}

 

즉, OID 1.3..6.1.2.1.25.1.1는 MiB 파일 HOST-RESOURCES-MIB.txt 내의 객체 hrSystemUptime과, 1.3.6.1.2.1.1은 SNMPv2-MIB.txt 파일 내 system 객체와 동일하다는 의미다. 

 

그럼, 본격적으로 매니저와 에이전트 설정을 진행하여 결과를 확인해보도록 하자.

 

 

 

6. 실습

 

SNMP 매니저 서버에서 매니저 서버 자신 및 에이전트 서버로부터 정보를 수집한다고 가정해보자. 필자는 매니저 서버만 모니터링 대상인 두 서버의 정보를 받도록 설정하려 한다. 

 

먼저 필자는 두 서버의 Security 를 아래와 같이 정의했다. Manager는 System Uptime 정보를, Agent는 인터페이스 정보 전체를 받아오도록 아래와 같이 설정했다.

 

[매니저 서버 SNMP 설정]

 

[ 에이전트 서버 설정 ]

 

설정이 완료되면 두 서버 모두 systemctl restart snmpd로 서비스를 재기동하여 설정 내용을 적용하자.

SNMP 매니저 서버에서 각 서버의 정보를 확인하기 위한 명령어는 net-snmp-utils 패키지 내에 존재하는 snmpwalk다. snmpwalk 명령어의 사용법은 아래와 같다.

 

# 명령어: snmpwalk -v {snmp 버전}  -c {Community String값}  {에이전트 서버 IP}  

 

결과는 아래와 같다. 

 

[ 매니저 서버 Uptime 정보 확인 ]

서버가 동작한 지 6분 12초가 지나는 것으로 snmp에 나타난다. 실제 uptime도 6분으로 찍히는 것이 보인다.

[ 에이전트 서버 인터페이스 정보 확인 ]

 

 

 

6. 실습 2

 

이제 필자는 매니저 서버에서 조금 다른 방식으로 서버의 정보를 호출해보려 한다. 지금까지 snmpwalk 명령어 사용 시, 별도의 MiB, OID 지정 없이도 view에 정의된 값을 불러올 수 있었는데, 이들은 특정 깊이 이상의 트리 구조로 OID 값이 더해질 경우, 그 결과가 제대로 나타나지 않는다는 단점이 있다(왜 이런지는 필자도 조금 더 찾아봐야할 듯 하다). 따라서 세부 정보를 확인할 때는 snmpwalk 명령어 뒤에 OID 또는 MiB 정보를 명시하여 정말 필요한 정보만 추출하는 방식으로 사용한다.

 

필자가 에이전트 서버의 인터페이스 IP 정보만 추출한다고 하자. 1.3.6.1.2.1.4라는 인터페이스 정보를 포함하는 OID가 view에 정의되어 있었지만, 이보다 깊이 들어가는 자료는 view 기본 값으로 출력이 불가하다. 이 인터페이스 IP 정보만 포함하는 OID는 1.3.6.1.2.1.4.20.1.1이며, 이 값을 snmpwalk 명령어 뒤에 명시해주면 서버의 IP 정보만 추출할 수 있다.

 

이 OID 값을 Mib로 변환하면 IP-MIB::ipAdEntAddr이 되는데, MiB값을 snmpwalk 명령어 뒤에 붙이더라도 동일한 결과가 나타남을 알 수 있다.

 

 


이번 포스팅에서는 SNMP가 무엇인지, 관련 개념(MiB, OID), 그리고 SNMP의 설정과 결과가 어떻게 나타나는지에 대해 작성해보았다. 위에서 작성한 내용처럼, SNMP는 에이전트 서버 정보의 읽기만 가능한 것이 아니라, 에이전트에서 이벤트 발생 시, 자동으로 매니저로 정보를 전송하는 것과 모니터링 대상 서버의 정보를 변경하는 것도 가능하다. 하지만 지면과 시간 관계 상, 필자는 정보를 불러 읽어오는 부분만 이번 포스팅에서 작성했다. 추후 시간이 날 경우, 쓰기 관련된 내용도 한 번 진행해보려 한다(언제가 될 지는 모르겠다...).

 

 

마지막으로 자주 사용할 법한 CentOS7의 MiB와 OID 참고표를 첨부하며 이번 포스팅을 마무리한다.

 

 

Fin.

반응형

댓글