simscan

목적
Qmail-scanner(perl)에 비해 c로 작성된 simscan 의 성능 테스트 및 장단점
perl scanner 사용시 서버의 로드가 많이 높아지는 부분을 해소해 보고자 함

다운로드 위치
http://sourceforge.net/projects/simscan/
필요한 것들
Ripmime(첨부파일을 필터링 하고자 한다면 필요하다)
Qmail-queue패치
Clamav(바이러스메일 체크)
Spamassassin
Trophie(or sophie)-옵션으로 설치 가능

– 설치 –
위의 다운로드 위치에서 소스를 다운로드 받는다.
먼저 clamav와 spamassassin을 설치하도록 한다.
simscan소스를 풀고 소스 디렉토리로 이동

 

Shell# groupadd simscan
Shell# adduser –g simscan –r –d /var/qmail/simscan –M –s /sbin/nologin simscan

Shell# ./configure 필요 옵션
Shell# make
Shell# make install-strip

 

 

옵션 설명
–enable-user=유저명 (simscan을 유저를 셋팅한다. 기본값으로 simscan)
–enable-clamav=y|n (clamav 를 이용한 스캐닝. 기본값으로 y 이다.)
–enable-clamdscan=clamdscan의 PTAH
–enable-custom-smtp-reject=y|n (바이러스 이름을 포함하여 리턴 메시지를 보내도록한다)
주의 – 위의 옵션을 사용하기 위해서는 소스디렉토리/contrib/qmail-queue-custom-error.patch 의 패치를
Qmail에 해주어야 한다. 또한 나중에 설명되는 옵션중에 하나인 –enable-dropmsg 의 값이 y이면 안된다.)
–enable-per-domain=y|n ( 많은 도메인에 대해서 메일서비스를 하고 있으며 각각에 대한 simscan 의 설정을
하고자 한다면 y를 택하도록 한다.)
–enable-attach=y|n ( 첨부파일에 대해서 체크를 할 것인지의 여부를 정한다. /var/qmail/control/ssattach 파일안에 필터링할 파일명이나 확장자를 넣어주면 된다.)
–enable-spam=y|n (스팸메일에 대한 필터링을 할 것인지에 대한 옵션이다. 스팸어세신에 의해서 status 가 YES인 메일에 대해서는 반송을 하게 될것이다.)
–enable-spam-passthru=y|n ( 스팸 어세신에서 붙은 status값을 무시하고 그냥 통과시키고자 할 경우에 사용한다. 이는 나중에 procmail 이나 maildrop으로 스팸 편지함이나 별도의 디렉토리에 스팸 메일을 저장하고자 한다면 유용하게 사용될 수 있을 것이다.)
–enable-spam-hits=점수 (기본값으로 10 이 셋팅되며 스팸 어세신에서 정한 값을 넣으면 될 것이다.)
–enable-spamc=PTAH (spamc 바이너리파일의 위치를 잡아준다. 자동으로 잡을것이다…^^)
–enable-spamc-args (spamc 에 필요한 옵션을 지정할 수 있다. 필자의 경우에 퍼포먼스를 위해 spamd 를 소켓을 사용하게 하였으며 소켓의 위치는 /tmp/spamd 였다, 쌍따옴표로 지정한다는 점에 주의 하라)
Ex) –enable-spamc-args=”-U /tmp/spamd”
–enable-dropmsg=y|n (스팸 메일에 대한 메시지를 sender 에게 보내지 않겠다는 옵션이다.)
–enable-quarantinedir=디렉토리위치( 스팸,바이러스 메일을 따로 저장해둘 디렉토리를 지정한다)
–enable-received=y|n ( 메일헤더에 received를 추가할 것인지에 대한 옵션이다. 버전정보 및 처리시간이 기록되어진다.)

-필자의 경우의 configure
./configure –enable-spam –enable-per-domain –enable-attach –enable-received=y –enable-spamassassin-path=/usr/bin/spamassassin –enable-spam-hits=5.1 –enable-spamc-args=”-U /tmp/spamd”

컴파일 및 설치가 완료 되었다면 이제 큐메일의 run 파일을 고치도록 한다.
필자의 run 파일의 내용이다.

#!/bin/sh
QMAILQUEUE="/var/qmail/bin/simscan"
#QMAILQUEUE="/var/qmail/bin/qmail-scanner-queue.pl"
export QMAILQUEUE
Q_UID=`id -u qmaild`
Q_GID=`id -g qmaild`
exec /usr/local/bin/softlimit -m 55000000 /usr/local/bin/tcpserver -vHRl 0 -x /etc/tcp.smtp.cdb -u $Q_UID -g $Q_GID 0 25 /var/qmail/bin/qmail-smtpd spamgw.linuxstudy.pe.kr /bin/checkpassword /bin/true 2>&1

 

 

메일서버 재시작

메일 테스트
메일을 보내보고 도착한 메일을 열었을 때 헤더에 다음과 같은 라인이 존재하는지 확인해 보자
필자의 경우에 –enable-received=y 를 주었기 때문에
Received: by simscan 1.1.0 ppid: 18392, pid: 18393, t: 0.0957s
scanners: clamav: 0.84rc1/m:30/d:813 spam: 3.0.2
가 있으며 스팸어세신의 점수를 5.1로 주었기 때문에 아래와 같이 헤더가 추가되어 있다.
X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on test
X-Spam-Level:
X-Spam-Status: No, score=0.4 required=5.1 tests=AWL,NO_REAL_NAME autolearn=no
version=3.0.2

메일이 위의 헤더를 가지고 있다면 정상적으로 simscan이 작동한다.

-간단Tip-
Clamav 와의 연동시 퍼미션 문제가 나올 경우에 아래와 같이 clamav 유저를 simscan 의 그룹으로 추가해 준다.
Shell# usermod –G simscan clamav

각 도메인 별 설정(simcontrol)
*enable-per-domain옵션을 주고 설치했을 경우에만 적용된다.

Shell# cat /var/qmail/control/simcontrol
postmaster@example.com:clam=yes,spam=no,attach=.txt:.com
example.com:clam=no,spam=yes,attach=.mp3
:clam=yes,spam=yes,spam_hits=20.1
Shell#/var/qmail/bin/simscanmk

첨부파일 필터링

Shell# cat /var/qmail/control/ssattach
.exe
.jpeg
.pif
.scr
.vbs

 

 

Qmail-scanner 와 simscan 의 장단점 비교
비교는 어디까지나 필자의 경험상으로 작성된 것이면 상황에 따라 또는 설정에 따라 얼마든지 달라질 수 있다.
-테스트 방법-
A 호스트에서 웹 프로그램으로 첨부파일 100k 짜리와 함께 간단한 메시지를 100통 발송
스캐너가 설치된 B 서버의 메일 메시지에 남은 시간을 계산하여 평균값을 냈다.
로컬 전송의 수치를 기본값과 100을 주었을 때를 비교해 보았다.

Simscan Qmail-scanner 비고
메시지 처리시간 평균 1.6665 5.42134148 concurrencylocal의 기본값 사용
메시지 처리시간 평균 1.8093 5.25143428 Concurrencylocal값 100사용
로그 파일 별도 로그가 없음
smtp로그에 같이 남음 별도 로그 남기기 쉬움 Simscan의 경우에 별도로 sender 의 아이피 정보나 기타 필요한 정보를 따로 저장하지 않기 때문에 소스를 수정하던지 다른 방법으로 자동 필터링 시스템을 생각해야 할 것 같다.

전체적으로 c 로 작성된 simscan이 메시지 처리 능력에서는 다소 앞선 듯 보이기는 한다.
하지만 qmail-scanner 의 경우에는 perl로 작성되어 있어서 원하는 대로 쉽게 수정이 가능하다는 장점이 있을것이다.

Mysql 튜닝정보

mysql 관련하여 가장 간단하게 튜닝할 수 있는 버퍼관련 정보와 튜닝 관련된 내용을 적어봅니다.

내용중에 잘못된 부분이 있으면 의견 바랍니다.

먼저 mysql의 경우에 두가지의 메모리 설정이 있다는 점을 먼저 알아둬야 합니다.
mysql의 경우 global 변수와 session 변수(또는 thread 변수) 두 가지 변수로 메모리를 컨트롤 합니다.
척 보면 아시겠지만 global 변수의 경우 mysql 데몬이 구동이 되면서 설정하는 변수들이며
session변수(per thread변수)는 client 가 접속할 때 마다 부여가 되는 변수 입니다.
따라서 메모리를 적절하게 부여하지 않으면 동시 접속시 과다한 메모리 할당으로 시스템에 문제가 발생할 수 있습니다.
자세한 변수들은 아래 페이지에서 확인할 수 있습니다.
변수 적용 범위가 both 인 경우에는 global로 설정하면 per thread변수와 같이 적용이 됩니다.
따라서 가급적으로 both인 변수들은 global 에 설정하지 말고  따로 mysql 서버에 접속하여 set 명령으로 할당하기를 권장합니다.
즉 /etc/my.cnf 에 both인 변수가 설정이 되는 경우를 주의 깊게 보시는게 좋을 것 같습니다.
1. mysql server 에 할당할 메모리 계산
global memory+(동시접속자수(max_connections* session buffers) ): 시스템에 장착된 물리 메모리의 60%~80% 이하로 설정하는것이 좋다고 합니다.
예를 들면 DB 데이터 사이즈가 5G 라고 가정하면 디스크IO 를 줄이기 위해서 DB 전체를 global 버퍼에 넣고 약 300개의 동시처리를 하겠다면 대략 global buffer(6G정도)+(300* session버퍼들의 합)을 보고 서버에 적정한 메모리도 알수 있습니다.
일단 모든 OS는 메모리가 빵빵한게 최고입니다.^^
2.  변수 및 적정값
innodb 를 위주로 설명드리겠습니다.
값들을 설정할때는 mysql서버에 접속후 show variable 과 show status(show global status,show session status) 명령으로 서버 상태를 확인하면서 적절한 값을 찾아내시면 됩니다.
가급적 mysql서버가 구동이 된지 1~2일 지나서 status들이 갱신이 되어 있는 상태에서 확인을 하시는게 좋습니다.
max_connections – mysql서버에 접속할수 있는 최대 client갯수입니다. 1번 메모리를 할당량을 참고 해서 적절한 숫자로 설정하시면 됩니다. show global status like ‘Threads_created%’; 하시면 mysql server에 최대로 생성됐던 클라이언트 수를 확인할 수 있습니다.
show status 결과중에서 Com_XXX 로 시작하는 값들은 모두 mysql 쿼리와 관련된 값이라고 보시면 됩니다.
create table,delete,insert,replace,select,show tables,show triggers,update 등등을 확인할 수 있으며
DB 서버가 읽기가 많은지 쓰기가 많은지 확인하면 됩니다.
그리고 다음으로 Handler_XXX 로 시작되는 값들은 튜닝에 중요한 정보를 제공해 주므로 반드시 한번씩 확인해보시기 바랍니다.
특히 아래의 값들은 잘 확인해 보시기 바랍니다.
* Handler_read_prev,Handler_read_rnd,Handler_read_rnd_next
위의 값들의 값이 시간에 따라서 계속 증가한다면 DB 테이블들이 설계가 잘못되어 있다고 보시면 됩니다.
특히 read_rnd 나 read_rnd_next의 경우에는 index 를 사용하지 않는 테이블들을 조인할 경우나 index key 없이 select 하는 경우등
이므로 테이블들 구조와 DB프로그램의 쿼리문들을 잘 살펴보시기 바랍니다.
* Key_xx 은 MyISAM DB와 관계 되는 값으로(Innodb에도 영향을 주는지는 확인하지 못했으니 확인부탁드립니다.)
Key_reads/Key_read_requests 를 계산해서 캐시 hit rate를 계산 할수 있습니다.
값이 높을수록 캐시가 잘되고 있다는 이야기 입니다.
Key_reads 값이 높다면 Key_buffer_size가 작다는 이야기 이므로 적당히 늘려주시면 됩니다.
* Qcache_XXX 값들은 query cache와 관계되는 값들로 아래의 값들을 유심히 확인해보시면 됩니다.
반복되는 쿼리에 대해서는 캐시에 저장했다가 응답하므로써 반응 속도도 높아집니다.
쿼리캐시 hir rate = Qcache_hits/(Qcache_hits+Com_select) 를 계산해서 100%에 근접한지 확인해보시면 됩니다.
mysql 서버를 막 시작하고 나서는 서버에 쿼리들이 실행이 안된 상태이므로 캐시히트률은 아주 작다는 점을 알아두시기 바랍니다.
서버에 DB프로그램에서 사용하는 쿼리를 계속 날려보시면 히트률이 증가하는것을 볼 수 있습니다.
* sort_buffer_size – status 값중에서 Sort_merge_passes값을 확인해서 이 값들이 계속 증가한다면 sort_buffer_size가 작다는 이야기 이므로 늘려주시면 됩니다. 제가 직 접확인해 본 결과 sort_buffer_size 가 커지면 디비 서버 성능이 상당히 감소 합니다.
따라서 가급적이면 global 변수보다는 session 변수로 할당을 해주시는것이 좋습니다.
Sort_merge_passes 값이 안늘어나는 상태까지 메모리를 줄여서 다른 곳에 할당해 주시면 됩니다.
ex) SET SESSION sort_buffer_size=값(my-innodb-heavy-4G.cnf 기본값이 8M입니다.)
벤치마크 테스트 결과입니다. 처리속도가 상당히 차이가 많이 납니다. QPS(query per sec)는 초당 처리한 쿼리갯수 입니다.
8M : QPS – 7506.51
32M; QPS – 4001.56
* Select_full_join, Select_range_check – show staus 결과 값이 0  이상인 경우에는 쿼리상 index 가 없이 table을 scan 하고 있다는 이야기 입니다.
따라서 이런 경우에는 반드시 테이블들이 index가 정상적으로 되어 있는지  및 DB프로그램에서 잘못된 join을 하고 있는지 확인해야 합니다.
* innodb_buffer_pool_size(global) – innodb를 위한 메모리 사이즈 입니다. DB전용 서버로 사용한다면 물리적인 메모리의 80%정도까지
잡아서 사용하시면 됩니다. 메모리에 모든 DB가 올라가 있는 경우 DB 데이터에 엑세스 할때 disk I/O를 최대한 줄일 수 있습니다.
아래는 테이블 레코드 1000만건에 대한 select,insert,update 시의 io 입니다. read가 0 인것을 보실 수 있습니다.
io.jpg
* innodb_log_file_size(global) – innodb는 기본적으로 buffer에서 동작을 하며 모든 입출력의 관한 내용은 log 파일에 남기고
로그 파일이 모두 차면 실제 DB데이터 파일인 ibdataX 에 기록을 합니다. 따라서 로그 파일이 작으면 ibdata파일에 기록하는 횟수가 증가하게 됩니다. 사이즈를 키우면 IO를 줄일 수 있으나 사이즈가 커지면 디비가 크래시 됐을때 복구하는 시간이 길어집니다.
적당한 계산법은 사이트들 마다 조금씩 다릅니다만  innodb_buffer_full_size 의 25% 정도 설정하라고들 합니다.
* key_buffer_size(global) – MyISAM 테이블의 index 블럭 사이즈 입니다. MYISAM 만 사용한다면 서버의 물리적인 메모리에서 25%정도 할당하시면 됩니다. 이 값은 너무 크게 설정하시면 디비가 시작할때 디비를 읽으면서 페이징을 하게 되어 시간이 오래 걸리면서 시작이 됩니다.
* table_cache(global) – 모든 스레드에서 열린 테이블의 갯수 입니다. show status 결과중에서 opened_tables 값이 계속 증가하거나  flush tables 명령을 가끔 내리는 경우라면 table_cache 변수를 늘려주시면 성능 향상에 도움이 됩니다.
* thread_cache_size(global) – 쓰레드를 재사용하기 위한 값입니다. 클라이언트가 DB접속을 종료하더라도 쓰레드를 종료하지 않고 캐시에 저장하여 재사용하게 됩니다. 쓰레드생성비용을 줄일 수 있습니다. 접속이 많은 경우라면 아래와 같이 계산해서 캐시 효과를 누릴 수 있습니다.
쓰레드 캐시 히트률 계산 = 100-((Threads_created/Connections)*100)
* query_cache_size(global) – 쿼리 결과를 캐싱하기 위한 메모리양 입니다. 기본값으로 0  으로 잡혀 있으며 query_cache_type 이 0(캐시를 하지 않음)으로 되어 있어도 메모리는 할당됩니다.
* max_heap_table_size(session) – heap테이블 사이즈를 지정합니다.
* tmp_table_size(session)  –  임시테이블 사이즈를 지정합니다.
위의 두 값은 disk IO와도 밀접한 관계가 있습니다. 기본적으로 heap,temp 테이블은 메모리에 생성하지만 사이즈가 초과되면 디스크에 생성하게 됩니다. created_tmp_disk_tables 와 created_tmp_tables 값으로 설정이 가능합니다.
* read_buffer_size(session) – 쓰레드당 full tables scan 을 하는 경우에 사용함.
큰 테이블이 많거나 범위에 대해서 scan 하는 경우 적당한 값으로 늘려줌
* join_buffer_size(session) – index 를 타지 않는 join할 경우에 사용함. 기본적으로 index없이 join하는 경우는 자제해야 하므로
쿼리를 수정하는 것이 나을듯 합니다.

Suricata를 이용한 IDS/IPS 구축하기

Suricata란?

Suricata is a high performance Network IDS, IPS and Network Security Monitoring engine. Open Source and owned by a community run non-profit foundation, the Open Information Security Foundation (OISF). Suricata is developed by the OISF and its supporting vendors.

대충 요약하자면 OISF에서 개발되어진 고성능의 네트워크IDS,IPS,NSM 엔진이라는 이야기다.
정말 고성능인지는 각자 테스트 해보기를 바란다.
10Gbps트래픽에서 9000개의 룰로 운영되는 suricata IDS 시스템에서 약 4%의 packet drop 만 생기도록 구성한 사례들도 있다.

 

용어정리
*IDS – Intrusion detection system(침입탐지 시스템)
*IPS – Intrusion prevention systems(침입방지 시스템)

사전준비

suricata는 다양한 OS를 지원한다. 필자의 경우 CentOS6 Linux 시스템에 설치하였다.
리눅스를 이용해서 쓸만한 IDS/IPS시스템을 구축해 보도록 하자.
  • OS: CentOS6.6
  • Network Card:2EA 이상(단독 서버에서만 구동한다면 1개여도 상관은 없다)
  •  적절한 사양의 PC 또는 서버(실제 운영해 보면 알겠지만 트래픽에 따라 메모리나 CPU사용이 제법 많이 필요한 경우가 많다)

설치

  1. EPEL repository추가
    rpm -Uvh http://dl.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-8.noarch.rpm
    
  2. 소스빌드를 위한 기본 패키지 설치
    yum -y install libpcap libpcap-devel libnet libnet-devel pcre \ pcre-devel gcc gcc-c++ automake autoconf libtool make libyaml \ libyaml-devel zlib zlib-devel file-devel
    

     

     

  3. IPS mode(NFQUEUE) 지원을 위한 패키지 설치
    나중에 다시 설명하겠지만 suricata 를 IPS모드로 동작하는 방법은 리눅스에서는 2가지 방법이 있다.
    Netfilter queue를 이용하는 방식(iptables)과 AF_PACKET를 이용하는 방식이 있다.

    yum -y install libnetfilter_queue libnetfilter_queue-devel \
    libnfnetlink libnfnetlink-devel
  4. Suricata build & install

    wget http://www.openinfosecfoundation.org/download/suricata-2.0.8.tar.gz
    tar -xvzf suricata-2.0.8.tar.gz
    cd suricata-2.0.8
    ./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var 
    make 
    make install-full
  5. 기본환경설정 확인 및 수정
    suricata 환경설정 파일은 기본적으로 /etc/suricata/suricata.yaml에 위치하고 있다.
    몇 가지 중요한 부분들을 수정하여 사용하도록 하자

    • host-mode:auto(suricata가 설치된 호스트를 IDS 모드 또는 IPS 모드로 사용할 것인지 지정한다)

      침입탐지용으로만 사용한다면 sniffer-only, 침입방지용으로 사용한다면 router로 지정해주면 된다.보통은 그냥 auto모드로 두고 데몬을 구동할 때 옵션으로 설정하는 경우가 많다.

    • pid-file: /var/run/suricata.pid(suricata 데몬의 pid 위치를 지정한다)
    • default-log-dir: /var/log/suricata/ (로그 디렉토리 설정)
    • ouputs: (로그 저장에 관련된 설정들이 들어있다.특히 나중에 mysql같은 데이터베이스에 로그를 남기고자 한다면 barnyard2 를 이용하여 남길 수 있다.이런 경우 unified2 형태로 로그를 남겨야 한다.)
    • drop: (IPS모드로 구동할때 룰에 의해서 drop된 로그를 저장하게 한다.)
    • af-packet: (IPS모드 중 하나인 af-packet 모드로 사용하고자 하는 경우 옵션들이다.)
    • cuda: (nvidia GPU을 이용해서 패킷 처리를 가속하기 위한 옵션이다.)
    • default-rule-path: (룰 파일의 위치를 지정한다.)
    • vars: (suricata 엔진에서 사용할 환경변수들이다. 이 변수들을 이용해서 룰파일에서도 사용한다.)
  6. 테스트 룰 삽입
    vi /etc/suricata/rules/drop.rules
    alert icmp 핑을 날릴호스트의 IP주소 any -> any any (msg:"ALERT test ICMP ping";
     icode:0; itype:8; classtype:trojan-activity; sid:99999998; rev:1;)
    192.168.2.126호스트에서 suricata로 ping 을 날리면 로그에 남는다
    alert icmp 192.168.2.126 any -> any any (msg:"ALERT test ICMP ping";
     icode:0; itype:8; classtype:trojan-activity; sid:99999998; rev:1;)

     

  7. suricata 실행 및 확인
    일단 기본적으로 IDS 모드로 구동해 본다.
    -i 다음에는 패킷들을 처리할 인터페이스를 넣어주도록 한다.

    suricata -c /etc/suricata/suricata.yaml -i eth0

    아래의 init파일을 /etc/init.d/suricata로 복사해두고 데몬 제어를 하는것이 편할 것 이다.
    suricata_init