랜섬웨어 관련 NagiosXI 모니터링

2017년도엔 보안 관련해서 Ransomware에 대한 내용이 많이 들리는듯 합니다. 이 글을 쓰는 중에도 보면, Ransomware 때문에 고생하시는분들이 많아지는거 같아서 씁슬하네요. 오늘은 Randomware 대응 관련 보안 관리 모니터에 대해서 이야기를 해볼까 합니다. 기초적인 보안에 대한 내용이라고 보면 될듯 하네요. 보안을 이야기 하면 많은 분들이 불편이라는 단어를 먼저 생각 할거 같은데요, 보안과 편리안 사용 두마리의 토끼를 다 잡는다면 좋겠지만, 많은 기업들이 보안을 이유로, 몇몇 과정을 더 거치게 만드는 추가적인 프로세스를 만들어 사용하고 있습니다.

저도 오늘 이 글을 쓰기 이전에, 제가 운용하는 Blog의 시스템 보안 로그를 한번 쭉 확인했더니, 참 놀라운 부문이 있었습니다. Blog는 외부 방화벽에서 8080를 통해서, 내부 방화벽을 거쳐 80port로만 서비스 하도록 설정되어 있고, 외부에서는 SSH로 접속을 하지 못하게 막혀 있었습니다. 그런데 시스템 로그에서는 SSH로 root 혹은 다양한 계정으로 접속 시도한 흔적이 있었습니다. 방화벽을 뚫고 들어왔을까요? 아니면 Web Server 의 PHP 의 Security Hole을 통해서 들어왔을까요?

로그 내용에 6/4일 부터 6/14일 10일동안 Password가 틀려서 session 종료된 로그 내용이 7250건이 넘게 있었습니다. IP의 위치들을 보니, 정말 다양한 국가의 IP가 있었는데, 이중에 중국의 IP가 단연 집요하게 접속 시도 했던 흔적들이 많이 있네요, 다행이 Root Password 가 아주 복잡해서 Login 된 흔적은 없었구요,  만약 외부에서 누군가 들어왔었다면 Blog의 내용은 이미 먼나라?에 가있었을지도 모르겠군요, 그래서 시스템의 기본 SSHD daemon 의 Service port를 22에서 다른것으로 변경 하였습니다. 이후에도 동일하게 변경된 port로 SSH 접속을 시도 하는 로그가 생기는지 확인을 해봐야 할거 같네요..

Ransomware에 관련한 여러 Web Site를 보면, 기본적으로 항상 backup 은 별도의 시스템에 분리된 망을 통해서 진행 해야 하며, Windows 공유를 기본적으로 off 해놓으라는 내용이 대부분인듯 합니다. 초기엔 Windows Client를 통해서 파일 서버의 내용을 Access 가 되면 이를 통해서 암호화를 진행 하는 형태 였다면, 최근 KISA에서 정확한 내용의 보고서가 나와바야 알겠지만, 최근의 한 감염 형태는 Linux의 ELF Binary 까지 그 범위가 확장되어서, 보안에 대한 불안함은 더 커져 가는듯 합니다.

아래의 두가지 경로가 될거 같은데요, 먼저 내부의 Windows PC를 감염시켜서, 내부의 Linux 의 root 권한을 확보 하는 방법혹은 외부에서, 서비스 하고 있는 Linux Server의 Secure Hole을 통해서 Root 권한을 획득하는 방법등이 있는데, 어느 쪽의 시나리오 간에, 빠른 원인 규명이 되어 빠른 시일내에 보안 패치가 되어야 할듯 합니다.

  • 외부 비 인가자 접속 PC –> 관리 Window Client –> Linux Server
  • 외부 비 인가자 접속 PC –> Linux Server

기본적으로 별도로 관리하는 리눅스 박스가 있다면, root password는 복잡하게, 즉 특수문자, 숫자, 대소문자 섞어서, 10자 이상 사용하는것이 좋을거 같구요, SSH Port는 무조건 변경, 그리고 시스템 로그에 auth.log / secure.log 의 내용을 보고 접속 시도해서 실패한 내용이 5줄 이상 나오면, Nagios XI를 통해서, Secure Alert를 받아 볼수 있도록 설정해서 사용하는 것도 필요 할듯 합니다.

추가로, Backup 의 경우 CIFS를 활용하지 말고, USB HDD로 별도로 혹은 TAPE으로 별도로 해주고, Network 으로 Sync 할려고 한다면 SSH + RSYNC를 섞어서 해주는것이 보안상 좀더 그림이 좋아보일듯 합니다. 방화벽도, 내부 Backup 서버에서, Source Server로 Out-Bound 형태로 접속해서 Backup 을 진행 하도록 하는 설계도 고려 해봐야 할거 같구요. Source Server 에서 Backup Server로는 접속 못하게 중간에 F/W하나 정도는 있는것이 좋을듯 하네요…

스토리지 서버의 사용 편리성때문에 탐색기에 E:\ 이런식으로 붙여놓고 사용하는 경우가 많을거 같은데, 가능 하다면, CIFS 볼륨을 Read Only로 놓고 사용하면, 윈도우에서 직접적으로 파일 변형하는것을 막을수 있을듯 하지만 파일을 수정해야 하는경우, 불편 하겠죠, 그래서 읽고 써야 하는 파일들이 필요한경우와, 읽기만 해도 되는 볼륨을 나누어서 사용하면, 모든 데이터를 암호화 하기 어렵게 만들수도 있을것입니다.

Nagios XI 에서는 Windows의 DISK Queue Activity를 모니터링 해서 사용율이 비정상적으로 많은경우 이를 경고 하여, 시스템의 내용을 볼수 있도록 해주고 있다. 또한 리눅스에서도 Disk의 사용율이 많은경우 마찬가지로 모니터링 해서 이상징후를 알수 있도록 하는 방법도 있습니다.

요약하자면…

  1. Email 내용 열어볼때에, 첨부된 내용을 함부로 열어 보지 않아야 하며
  2. 운영체제에 Volume Shadow Copy를 두어, 운영체재 통으로 복구하는 방법
  3. 지속적인 별도의 분리된 망을 통한 백업 운용 하는 방법
  4. Crypto 관련 실행 파일이 실행이 안되도록, Windows Policy 에 적용
  5. 제한된 쓰기 가능한 네트웍 볼륨 운용

아래의 Table은 gaic.org 에서 발췌한 내용입니다. 보시면, 각 부문에서 어떻게 대응해야 하는지 어떠한 부문으로 암호화를 막을수 있는지, Table 로 정리 해놓은것입니다. 도움이 되셨으면 좋겠네요..

마지막으로, 보안 관련해서 Linux 에 Open된 혹은 접속된 TCP/UDP 를 확인 하는 방법을 잠깐 정리하고 마무리 하도록 하죠, 기본적으로 netstat을 사용하면, 열려있는 포트가 어떤 PID를 사용하는데, 이런경우 문제의 PID를 죽일수가 있는데, 간혹 보면 PID가 없는경우가 있습니다.

# netstat -lptu | awk '{if ($NF == "-")print $0}'
tcp        0      0 0.0.0.0:43797           0.0.0.0:*               LISTEN      -
tcp        0      0 0.0.0.0:nfs             0.0.0.0:*               LISTEN      -
tcp6       0      0 [::]:39910              [::]:*                  LISTEN      -
tcp6       0      0 [::]:nfs                [::]:*                  LISTEN      -
udp        0      0 0.0.0.0:nfs             0.0.0.0:*                           -
udp        0      0 0.0.0.0:41994           0.0.0.0:*                           -
udp6       0      0 [::]:nfs                [::]:*                              -
udp6       0      0 [::]:36738              [::]:*                              -

포트가 열여 있는데, 이것이 어떤 PID를 사용하는지 안나오죠, 이럴경우, rpcinfo -p 를 하면, 이 포트가 어떠한 서비스에서 사용하는지를 볼수 있습니다.

# rpcinfo -p 
   program vers proto   port  service
    100000    4   tcp    111  portmapper
    100000    3   tcp    111  portmapper
    100000    2   tcp    111  portmapper
    100000    4   udp    111  portmapper
    100000    3   udp    111  portmapper
    100000    2   udp    111  portmapper
    100005    1   udp  20048  mountd
    100024    1   udp  33231  status
    100005    1   tcp  20048  mountd
    100024    1   tcp  58513  status
    100005    2   udp  20048  mountd
    100005    2   tcp  20048  mountd
    100005    3   udp  20048  mountd
    100005    3   tcp  20048  mountd
    100003    3   tcp   2049  nfs
    100003    4   tcp   2049  nfs
    100227    3   tcp   2049  nfs_acl
    100003    3   udp   2049  nfs
    100003    4   udp   2049  nfs
    100227    3   udp   2049  nfs_acl
    100021    1   udp  41994  nlockmgr
    100021    3   udp  41994  nlockmgr
    100021    4   udp  41994  nlockmgr
    100021    1   tcp  43797  nlockmgr
    100021    3   tcp  43797  nlockmgr
    100021    4   tcp  43797  nlockmgr

보안 관련해서는 OS 부문에 Kernel 을 포함한 여러 서비스 관련하여, 가능하면 최신의 보안 FIX를 반영해야 안정적으로 운용하는데 있어 도움이 될것입니다. 오늘은 보안 관련 이야기 로 이런 저런 내용들을 두서 없이 한번 정리 해보았습니다. 혹시 위의 내용중에 오류가 있으면 언제든지 댓글 부탁드립니다.

답글 남기기

이메일은 공개되지 않습니다. 필수 입력창은 * 로 표시되어 있습니다.