[apache 2.4+] authz_core:error AH01630: client denied by server configuration

authz_core:error AH01630: client denied by server configuration
apache 2.4+ 의 mod_authz_core 모듈 사용시 error log에 기록됨. 

<Directory></Directory>에 추가함

Require all granted 모든 접근에 대해 제한을 두지 않습니다. 
Require all denied 모든 접근에 대해 제한합니다.
Require env env-var 해당 환경 변수만 허용합니다.
Require method http-method 해당하는 HTTP 메소드(GET/POST등)만 허용합니다.
Require expr expression 표현식이 참일때만 허용합니다.
Require user userid 사용자 아이디에 해당할때만 허용합니다
Require group group-name 해당하는 그룹만 허용합니다.
Require valid-user 허가된 사용자만 허용합니다.


참고: http://www.lovelgw.com/Blog/314


Xlib: connection to ":0.0" refused by server oracle

Xlib: connection to ":0.0" refused by server

이 에러의 경우 에러 메세지는 remote 시스템 또는 windows의 terminal창에서 GUI환경의 Application을 실행하였을때 발생 하며 아래와 같은메시지가 출력 됩니다.

Xlib: connection to ":0.0" refused by server
Xlib: Client is not authorized to connect to Server
Error: Can't open display: :0.0

위의 에러가 발생하면 remote 시스템 또는 windows의 terminal창에서 login한 후 아래의 명령을 실행하여 local 시스템이 remote 시스템의 access control list에 포함 되도록 한다.

# xhost "local-system-hostname"

예) local 시스템의 hostname이 "bigom"이라면 아래와 같이 지정한다.

# xhost  test
cat being added to access control list

특정한 호스트 외에 다른 모든 시스템을 access control list 에 추가하려면 아래와 같이 지정한다.

# xhost +
access control disabled, clients can connect from any host



Posted by BAGE (출처: http://blog.bagesoft.com/705)

Conntrack 방지 방법 (ip_conntrack 제한값) CentOS

출처 : http://blog.pages.kr/704

다음은 /var/log/messages 의 내용이다. Netfilter의 conntrack 하나당 228 byte가 필요하고 최대 32760개가 가능하다는 것이다.  (약 10M)

Oct  7 15:15:22 host kernel: ip_conntrack version 2.4 (4095 buckets, 32760 max) – 228 bytes per conntrack

만약 32760이 넘으면 어떻게 될까? 다음과 같이 패킷이 drop이 된다.

Oct  7 15:16:42 host kernel: ip_conntrack: table full, dropping packet.

이런 문제는 웹 서버와 같이 동시에 수 많은 connection을 처리해야 하는 경우에 발생할 수 있고 ab와 같은 stress 발생기를 사용하는 경우에도 발생할 수 있다. 이 문제에 대한 해결책은?

  1. netfilter를 사용하지 않는다.
  2. conntrack를 최대 개수를 늘린다.
  3. iptables raw table를 이용해서 특정 패킷은 conntrack을 하지 않는다.
  4. TCP 연결과 같이 각 상태별 TTL 값을 조절해서 볼 일이 끝난 연결은 빨리빨리 conntrack에서 제거한다.

 각 경우에 대해서 좀 더 자세히 알아보자.

1. netfilter를 사용하지 않는다.

보안을 신경쓰지 않아도 된다면 그래도 좋다.

#service iptables stop

2. conntrack의 최대 개수를 늘린다.

아래와 같이 하면 가능하다.

echo “100000″ > /proc/sys/net/ipv4/ip_conntrack_max

3. NOTRACK

다음은 웹 서버(80)로 오가는 패킷은  conntrack 하지 않도록 하는 규칙이다. 들어오고 나가는 패킷 모두에 대해서 규칙을 넣어주어야 한다는 사실에 주의하시길.

# input packet to serveriptables -t raw -A PREROUTING -p tcp --dport 80 -j NOTRACK# output packet from serveriptables -t raw -A OUTPUT -p tcp --sport 80 -j NOTRACK

“cat /proc/net/ip_conntrack”이나 iptstate를 실행해도 이제 더 이상 80번 포트로 오가는 패킷을 기록되지 않게 된다. 당연히 NAT는 할 수 없고 “-m state –state NEW” 와 같은 stateful inspection 규칙은 사용할 수 없게 된다. raw table은 conntrack이나 filter 앞에 위치하며 packet의 내부 정보에 UNTRACKED를 표시해 둔다. 이 정보는 -m state –state UNTRACKED 의 규칙을 사용해서 filter에서 이용할 수 있다.  NOTRACK을 했다고 해서 그 이후의 filter 규칙을 무시하는 것은 아니다. 단지 stateful inspection을 사용할 수 없을 뿐이다.

이렇게 NOTRACK을 한 패킷을 filter에서 통과시키기 위해서는 다음과 같이 명시적으로 해 줄 수도 있다. 물론 -p tcp –dport 와 같은 IP 헤더 정보를 이용한 filtering도 가능하다.

# iptables -I INPUT -m state –state UNTRACKED -j ACCEPT
# iptables -I OUTPUT -m state –state UNTRACKED -j ACCEPT

4. TIMEOUT 값 변경

Netfilter와 관련해서 변경가능한 값은 아래와 같다. Timeout과 관련한 값을 변경해서 conntrack에 자리 잡고 있는 시간을 조절할 수 있다. 특히 timout_established 의 경우에는 5일이나 된다. 물론 TCP 연결이 종료된 경우에는 그에 부응하여 TTL 값이 줄기는 하지만 만약에 연결이 된 상태에서 클라이언트가 죽는 경우와 같은 경우에는 계속 상태를 잡고 있을 가능성이 있다.

Conntrack related status :/proc/sys/net/ipv4/ip_conntrack_max:32760/proc/sys/net/ipv4/netfilter/ip_conntrack_buckets:4095/proc/sys/net/ipv4/netfilter/ip_conntrack_checksum:1/proc/sys/net/ipv4/netfilter/ip_conntrack_count:3/proc/sys/net/ipv4/netfilter/ip_conntrack_generic_timeout:600/proc/sys/net/ipv4/netfilter/ip_conntrack_icmp_timeout:30/proc/sys/net/ipv4/netfilter/ip_conntrack_log_invalid:0/proc/sys/net/ipv4/netfilter/ip_conntrack_max:32760/proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_be_liberal:0/proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_loose:1/proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_max_retrans:3/proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_close:10/proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_close_wait:60/proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_established:432000/proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_fin_wait:120/proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_last_ack:30/proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_max_retrans:300/proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_syn_recv:60/proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_syn_sent:120/proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_time_wait:120/proc/sys/net/ipv4/netfilter/ip_conntrack_udp_timeout:30/proc/sys/net/ipv4/netfilter/ip_conntrack_udp_timeout_stream:180

현재 conntrack 개수 빨리 알기

ip_conntrack_count 값을 읽으면 빨리 알 수 있다. 전체 리스트를 읽는 것은 시간이 오래 걸릴 뿐만이 아니라 전체 시스템 반응에도 심각한 영향을 줄 수 있다.

[root /proc/sys/net/ipv4/netfilter]# cat ip_conntrack_count4887
[root /proc/sys/net/ipv4/netfilter]# wc -l /proc/net/ip_conntrack4887 /proc/net/ip_conntrack

CONNTRACK_MAX는 커널 메모리 상에서 netfilter가 동시에 처리하는 세션의 수를 이야기 하는 것이며 HASHSIZE는 CONTRACK 엔트리의 리스트를 저장할 해쉬 테이블의 사이즈를 지칭하는 것이었다.

i386 아키텍쳐에서는 CONNTRACK_MAX = RAMSIZE(단위: byte) / 16384 일때 가장 이상적인 사이즈이며, HASHSIZE는 CONNTRACK_MAX = HASHSIZE * 8이 성립될때 가장 이상적인 사이즈가 된다.

더 정확하게는
CONTRACK_MAX = RAMSIZE(단위: byte) / 16384 / ( x / 32)
HASHSIZE = CONNTRAK_MAX / 8 = RAMSIZE(단위: byte) / 131072 / (x / 32)

이다. 여기서 x의 값은 32비트 머신일 경우 32, 64비트 머신일 경우 64가 된다.

리눅스 머신에서는 1GB이상의 메모리일 경우 디폴트로 CONNTRACK_MAX가 65536이 세팅이 되고, HASHSIZE는 8192가 세팅이 된다.

아래의 명령으로 현재 세팅된 CONTRACK_MAX의 값을 알 수 있다.

Linux kernel version 2.4.23 이전의 버전
# cat /proc/sys/net/ipv4/ip_conntrack_max

Linux kernel version 2.4.23 (Linux 2.6 포함) 이후의 버전:
# cat /proc/sys/net/ipv4/netfilter/ip_conntrack_max
  (/proc/sys/net/ipv4/ip_conntrack_max는 더이상 사용하지 않음)

값을 변경하는 법은 위의 설정된 파일들의 숫자를 변경하면 되는데 vi나 에디터를 사용하여 변경을 시도하면 이미 읽고 있는 파일이라 저장이 되지 않을 것이다.
아래와 같이 타이핑하면 CONTRACK_MAX의 값을 변경 할 수 있다.

Linux kernel version 2.4.23 이전의 버전
# echo $CONNTRACK_MAX > /proc/sys/net/ipv4/ip_conntrack_max
Linux kernel version 2.4.23 (Linux 2.6 포함) 이후의 버전:
# echo $CONNTRACK_MAX > /proc/sys/net/ipv4/netfilter/ip_conntrack_max

커널 버전 2.4.21 이전에서는 HASHSIZE의 값이 소수이고 홀수여야만 하며 최적화된 값이 이미 세팅되어 있는 상태이므로 크기의 변경을 추천하지 않는다. 하지만 그 이후의 버전에서는 해쉬 알고리즘의 변경으로 이러한 제약조건이 없어졌다. 그러나 HASHSIZE가 2의 배수일 경우 최대의 효율을 나타낸다고 되어있다.

만일 netfilter contrack가 커널에 static하게 컴파일 되어 있을 경우는 컴파일 시에 값을 변경하거나 부트 옵션에

ip_conntrack.hashsize=$HASHSIZE

를 넣어주면 된다.

모듈로 컴파일 되어 있을 경우는 모듈을 인서트할때 옵션을 주면 된다.

# modprobe ip_conntrack hashsize=$HASHSIZE

커널 버전 2.6.14부터는 런타임에 해쉬사이즈를 변경하는 것이 가능해졌다.

# echo $HASHSIZE > /sys/module/ip_conntrack/parameters/hashsize
커널 버전 2.6.20에서는
# echo $HASHSIZE > /sys/module/nf_conntrack/parameters/hashsize

출처 : http://o5o5o.dyndns.org/

아파치 모듈 DoS 공격 대비 (mod_evasive) apache

출처 : http://blog.pages.kr/83


프로젝트 : http://www.zdziarski.com/blog/?page_id=442

* 설치

특정 URL이나 IP일 경우나 특정한 브라우저를 이용하여 DoS(Denial of Service, 서비스거부)
공격이 들어온다면 httpd.conf 에서 SetEnvIf, SetEnvIfNoCase 등과 Allow, Deny 설정으로
간단히 막을 수 있다.

그러나 일정한 유형이 없다면 Apache용 mod_dosevasive 모듈로 DoS 공격을 막을 수 있다..

1) mod_dosevasive.1.8.tar.gz 파일을 다운받아서 업로드한후 압축을푼다.
    /usr/local/src/mod_dosevasive.1.8.tar.gz에 파일이존재한다고 가정하고
 
#tar xvfz mod_dosevasive.1.8.tar.gz
#cd /usr/local/src/mod_dosevasive/
#ll
---------------------------------------------------------------------------
-rw-r--r--  1 mysql mysql 18103  8¿ù 31  2003 LICENSE
-rw-r--r--  1 mysql mysql   476  8¿ù 31  2003 Makefile.tmpl
-rw-r--r--  1 mysql mysql 11267  9¿ù  2  2003 README
-rw-r--r--  1 mysql mysql 19306  9¿ù  2  2003 mod_dosevasive.c    ==> 아파치 1.3.x 버전용
-rw-r--r--  1 mysql mysql 17777  9¿ù  2  2003
mod_dosevasive20.c  ==> 아파치 2.x 버전용
-rw-r--r--  1 root  root  61369 12¿ù 13  2005 mod_dosevasive20.so
-rw-r--r--  1 mysql mysql   406  8¿ù 31  2003 test.pl
--------------------------------------------------------------------------
#/usr/local/apache2/bin/apachectl stop                     ===> 아파치 정지
#/usr/local/apache2/bin/apxs -cia /usr/local/src/mod_dosevasive/mod_dosevasive20.c
 
모듈 설치가 끝나면 아파치에 httpd.conf 파일안에 아래 내용이 추가된다. 그럼 설치완료.
---------------------------------------------------------------------------------------
LoadModule dosevasive20_module modules/mod_dosevasive20.so     ==> 아파치 1.3.x 버전용
                           -----------------------------------
LoadModule dosevasive_module libexec/mod_dosevasive.so           ==> 아파치 2.x 버전용
...
AddModule mod_dosevasive.c
----------------------------------------------------------------------------

2) httpd.conf에는 다음과 같이 설정을 추가한다.
----------------------------------------------
<IfModule mod_dosevasive20.c>     ===>  아파치 2.x 버전용, 아파치 1.3.x 버전용
IfModule mod_dosevasive.c
  DOSHashTableSize  3097    ==> 접속을 받아들임 정상 접속인지 계산을위한 공간 접속이 많은 사이트는 늘린다.
  DOSPageCount    2   
      DOSPageInterval   1           ==> 지정한 시간(1)동안 같은페이지를 (2번)요청할 경우 403에러.    

  DOSSiteCount    50      ==> 지정한 시간(1)동안 총히트수(html,이미지포함)가 총 (50)을 초과할경우 403에러.    
  DOSSiteInterval   1                  이미지가 많은 사이트는 적절히 조절이 필요함.

  DOSBlockingPeriod  10     ==>서비스 거부공격등으로 필터링된 ip는 이후 (10)초동안 접속이 중지되어 403에러.
                                                   (10)초안에 재접속 하면 다시 (10)초로 리셋됨.
 
      DOSEmailNotify       nforce@nforce6.com           ==>앞에서 지정한 값을 초과할 경우 차단된 ip를 이메일로 통보.
</IfModule>
---------------------------------------------- 
 
#/usr/local/apache2/bin/apachectl stop                     ===> 아파치 재시작
 
3) 실행확인.
로그파일은 기본적으로 /tmp/dos-211.xxx.xxx.xxx 이런 dos-아이피 이름으로 저장된다.
테스트 할려면 웹페이지를 오픈하고 [F5]를 오지게 한번 눌러보자.그럼.. Forbidden 403에러가 웹에 뜨면서
/tmp/폴더에 위에 형식의 파일이름이 생긴다.
  

* 아파치 httpd.conf  사용 예)

<IfModule mod_dosevasive.c>
    DOSHashTableSize    3097 
    DOSPageCount          2
    DOSPageInterval        1

    DOSSiteCount            50
    DOSSiteInterval          1
    DOSBlockingPeriod    10
</IfModule>

- DOSHashTableSize : 클라이언트의 요청을 해석하기 위한 테이블 공간. 크면 클수록 메모리를 많이 잡아먹지만, 해석이 빠르겠죠.
- DOSPageCount : 같은 페이지를 DOSPageInterval (단위 : 초) 동안 DOSPageCount 만큼 요청하면 블럭시킴.
- DOSPageInterval : (위 지시자와 함께 사용)
- DOSSiteCount : 같은 웹사이트에 DOSSiteInterval (단위 : 초) 동안 DOSSiteCount 만큼 요청이 있으면 블럭시킴.
                       : css, js, gif, jpg, png 등 읽혀지는 모든 파일이 Count 됨.
- DOSSiteInterval : (위 지시자와 함께 사용)
- DOSBlockingPeriod : 블럭당한 클라이언트를 접속 거부할 시간. (단위 : 초)

블럭당하게 되면 403 (Forbidden) 에러가 납니다.

* 참고 URL

http://megaz.arbuz.com/archives/2004/08/02/apache-performance/

http://www.theserverpages.com/20303/22/



mod_evasive를 이용한 웹Dos 공격을 막자.

공식 홈페이지 :
http://www.zdziarski.com/projects/mod_evasive/ 

1. mod_evasive이란 무엇인가?

   이것은 HTTP Dos 또는 DDos 스택 또는 저돌적인 공격으로부터 아파치를 보호하는데 있습니다.
   이것은 ipchains, 방화벽, 라우터등으로 쉽게 구성될 수 있도록 디자인 되었습니다.

   탐지는 주소, URI의 IP 내부 동적 해쉬테이블을 생성함으로 수행되고, 각 아이피별로 거부됩니다.
   - 초당 몇번 이상의 같은 페이지를 요청하는 경우
   - 초당 같은 자식노드를 동시에 50번 이상 생성하는 경우
   - 일시적으로 블러킹되는 동안 어떠한 요청을 생성하는 경우

2.  mod_evasive의 설치

# wget http://www.zdziarski.com/projects/mod_evasive/mod_evasive_1.10.1.tar.gz

# 압축해제
# tar xvzf mod_evasive_1.10.1.tar.gz

# 디렉토리 이동
# cd mod_evasive

# 모듈 추가
# /usr/local/apache/bin/apxs -iac mod_evasive.c -> Apache.1.x
# /usr/local/apache/bin/apxs -iac mod_evasive20.c -> Apache.2.x

# 환경설정
# vi /usr/local/apache/conf/httpd.conf

# 아파치 1.X와 2.X에서의 모듈명칭이 약간 차이가 있으므로 주의할 것!
# 아래에 해당하는 내용이 존재하는지 확인 한다. 없으면 추가.
LoadModule evasive_module    modules/mod_evasive.so -> Apache.1.x
LoadModule evasive20_module    modules/mod_evasive20.so -> Apache.2.x

<IfModule mod_evasive.c>
        DOSHashTableSize        3097
        DOSPageCount              3
        DOSSiteCount                50
        DOSPageInterval            1
        DOSSiteInterval              1
        DOSBlockingPeriod        30

        DOSEmailNotify            webmaster@yoursite.com
        DOSLogDir                   "/usr/local/apache/logs/mod_evasive.log"
        DOSSystemCommand      "su - someuser -c '/sbin/... %s ...'"
</IfModule>

# 환경설정 검사
# apachectl configtest
# 재시작
# apachectl -k restart


3. 각 지시자에 대한 설명

- DOSHashTableSize 
    각 자식 해쉬테이블 마다 탑레벨 노드의 수를 지정한다.
    수치가 높으면 높을수록 더 많은 퍼포먼스가 나타나지만 테이블스페이스에 메모리를 남기게 된다
    접속량이 많으면 이 수치를 높혀도 된다.
   
- DOSPageCount
    이것은 같은 페이지 또는 URI, 인터벌당 요청수에 대한 카운트 수이다.
    지정된 값이 초과되면 클라이언트에 대한 IP 정보가 블러킹리스트에 추가된다.

- DOSSiteCount
    지정된 시간동안 같은 페이지를 지정된 수 보다 초과될경우 IP 정보가 블러킹리스트에 추가된다.

- DOSPageInterval
    페이지 카운트 시발점, 디폴트는 1초이다.

- DOSSiteInterval
    사이트 카운트 시발점, 디폴트는 역시 1초이다.

- DOSBlockingPeriod
    클라이언트가 블랙리스트에 추가되어 블러킹되는 총 시간.
    이때 클라이언트는 403 (Forbidden) 에러를 출력하게 된다.

- DOSEmailNotify
    이 값이 지정되면, IP가 블러킹될때마다 지정된 이메일로 발동된다.
주의 : 메일러는 mod_dosevasive.c 에 정확하게 지정되야 한다. 디폴트는 "/bin/mail -t %s" 이다.

- DOSLogDir
   로그 파일 경로

- DOSSystemCommand
    이 값이 지정되면, 시스템은 아이피가 블러킹될때마다 명령행을 실행한다.

- DOSWhitelist
   차단에서 제외될 호스트

   DOSWhitelist    127.0.0.1
   DOSWhitelist    127.0.0.* - (와일드카드는(*) 필요하다면 최대 8진수(xxx.*.*.*)까지 사용할 수 있다.)



4. 테스트하기
# perl test.pl <- 다운받은 파일 안에 포함되어 있다.
   HTTP/1.1 200 OK
   HTTP/1.1 403 Forbidden
   HTTP/1.1 200 OK
   HTTP/1.1 403 Forbidden
   HTTP/1.1 403 Forbidden


Below are tools that I use everyday that help me out a great deal. Feel free to check each of them out as well as their homepages. I have built these RPM/SRPM's with the approval of the authors.

multitail 2.9.1:
http://www.vanheusden.com/multitail/
RPM: multitail-2.9.1-0.i386.rpmSRPM: multitail-2.9.1-0.src.rpm

DNS Flood Detector 1.08: http://www.adotout.com/dnsflood.html
RPM: dnsflood-1.08-1.i386.rpmSRPM: dnsflood-1.08-1.src.rpm

mod_dosevasive 1.8: http://www.nuclearelephant.com/projects/dosevasive/
RPM: mod_dosevasive-1.8-1.i386.rpmSRPM: mod_dosevasive-1.8-1.src.rpm

iftop 0.16: http://www.ex-parrot.com/~pdw/iftop/
RPM: iftop-0.16-0.i386.rpmSRPM: iftop-0.16-0.src.rpm


DoS 공격도 문제지만, 무분별한 로봇들이나 사용자들도 문제이다. 짧은 시간 간격 사이에 많은 요청을 보내와 시스템 리소스를 잡아먹고 결국에는 홈페이지 로딩을 느려지게 만든다.

이런 문제는 apache2.x 상에 mod_evasive 모듈을 올려서 어느 정도 해결할 수 있다. 물론 웹 서비스를 국내에 한정시킬 수도 있다면, iptables 등을 이용해서 원천적으로 막아버리는 것이 속 편한 방법일 것이다.

현재 데비안에서는 apache2.x 버전에 대한 mod_evasive 패키지가 없는 것으로 알고 있다. 그래서 apache2.x 버전을 사용하는 경우에는 소스를 받아 직접 컴파일할 수 밖에 없다.

mod_evasive 모듈의 소스는
제작자 홈페이지에서 다운로드할 수 있다. 현 시점에서 안정 버전은 1.10.1 이다.

소스를 받아 압축을 푼 후에 모듈 컴파일을 해준다. 아파치 모듈 컴파일을 위해서는 apxs가 필요한데, 데비안의 경우 apache2-prefork-dev 패키지를 설치하면 된다.

# tar xvfz mod_evasive_1.10.1.tar.gz
# cd mod_evasive
# apxs2 -iac mod_evasive20.c
/usr/share/apr-1.0/build/libtool --silent --mode=compile --tag=disable-static x86_64-linux-gnu-gcc -prefer-pic -DLINUX=2 -D_GNU_SOURCE -D_REENTRANT -I/usr/include/apr-1.0 -I/usr/include/openssl -I/usr/include/postgresql -I/usr/include/xmltok -pthread     -I/usr/include/apache2  -I/usr/include/apr-1.0   -I/usr/include/apr-1.0 -I/usr/include/postgresql  -c -o mod_evasive20.lo mod_evasive20.c && touch mod_evasive20.slo
/usr/share/apr-1.0/build/libtool --silent --mode=link --tag=disable-static x86_64-linux-gnu-gcc -o mod_evasive20.la  -rpath /usr/lib/apache2/modules -module -avoid-version    mod_evasive20.lo
/usr/share/apache2/build/instdso.sh SH_LIBTOOL='/usr/share/apr-1.0/build/libtool' mod_evasive20.la /usr/lib/apache2/modules
/usr/share/apr-1.0/build/libtool --mode=install cp mod_evasive20.la /usr/lib/apache2/modules/
cp .libs/mod_evasive20.so /usr/lib/apache2/modules/mod_evasive20.so
cp .libs/mod_evasive20.lai /usr/lib/apache2/modules/mod_evasive20.la
PATH="$PATH:/sbin" ldconfig -n /usr/lib/apache2/modules
----------------------------------------------------------------------
Libraries have been installed in:
   /usr/lib/apache2/modules

If you ever happen to want to link against installed libraries
in a given directory, LIBDIR, you must either use libtool, and
specify the full pathname of the library, or use the `-LLIBDIR'
flag during linking and do at least one of the following:
   - add LIBDIR to the `LD_LIBRARY_PATH' environment variable
     during execution
   - add LIBDIR to the `LD_RUN_PATH' environment variable
     during linking
   - use the `-Wl,--rpath -Wl,LIBDIR' linker flag
   - have your system administrator add LIBDIR to `/etc/ld.so.conf'

See any operating system documentation about shared libraries for
more information, such as the ld(1) and ld.so(8) manual pages.
----------------------------------------------------------------------
chmod 644 /usr/lib/apache2/modules/mod_evasive20.so
apxs:Error: Activation failed for custom /etc/apache2/httpd.conf file..
apxs:Error: At least one `LoadModule' directive already has to exist..

한가지 주의할 것은 apache2.x 버전에 대해서는 mod_evasive20.c 파일을 컴파일 해야 한다는 것이다.

컴파일이 성공적으로 마친 후에는 아파치 설정 파일을 수정할려고 하는데, 데비안에서는 아파치 설정 파일이 /etc/apache2/apache.conf 로 되어 있기 때문에 에러가 난다. 그래서, 설정 파일은 직접 만들어줘야 한다.

설정 파일을 만들 때, /etc/apache2/apache.conf 에 저장할 수도 있겠지만, mods-avaiable 디렉토리에 개별 파일로 만들어두는 것이 더 유용할 것이다. 이때 만들어줘야 하는 파일은 설정 파일과 로드 파일 2개이다.

# file /etc/apache2/mods-available/evasive20.load
LoadModule evasive20_module /usr/lib/apache2/modules/mod_evasive20.so

# file /etc/apache2/mods-available/evasive20.conf
<IfModule mod_evasive20.c>
    DOSHashTableSize    3097
    DOSPageCount        3
    DOSPageInterval     1
    DOSSiteCount        50
    DOSSiteInterval     10
    DOSBlockingPeriod   7200
</IfModule>

위 설정 파일에서
  • DOSHashTableSize - 해쉬 테이블의 크기
  • DOSPageCount - 접속 차단할 연속적인 동일 페이지 요청
  • DOSPageInterval - 동일 페이지 요청을 계산할 시간 간격 (단위: 초)
  • DOSSiteCount - 접속 차단할 연속적인 사이트 접속 요청
  • DOSSiteInterval - 사이트 접속 요청을 계산할 시간 간격 (단위: 초)
  • DOSBlockingPeriod - 접속 차단할 시간 간격 (단위: 초)

즉, DOSPageInterval 초 이내에 DOSPageCount 회 이상의 동일 페이지 접속 요청이 있거나 DOSSiteInterval 초 이내에 DOSSiteCount 회 이상의 사이트 접속 요청이 있다면 DoS 공격으로 간주하고 DOSBlockingPeriod 초 동안 접속을 차단한다는 말이다.

이외 설정으로
  • DOSEmailNotify - 접속 차단에 대한 결과를 보낼 이메일 주소
  • DOSLogDir - 로그 파일 경로
  • DOSWhitelist - 접속 차단에서 제외할 주소

이렇게 2개의 파일은 만든 후에 mods-enabled 디렉토리 내에 소프트 링크를 걸어주자.

# ln -s ../mods-available/evasive20.load ./
# ln -s ../mods-available/evasive20.conf ./
# /etc/init.d/apache2 restart

설정 파일을 제대로 설정하고 나서, 아파치를 재기동하면 이제부터 DoS 공격과 무분별한 접속에서 어느 정도 벗어날 수 있을 것이다.

이제 나중에 로그 파일을 보면 이런 내용을 볼 수 있다.

Jan 21 12:08:52 server mod_evasive[6126]: Blacklisting address 121.157.xxx.92: possible DoS attack.
Jan 21 12:08:59 server mod_evasive[5874]: Blacklisting address 61.42.xxx.66: possible DoS attack.


syn 공격 기본 방어 CentOS

출처 : http://www.ysy2080.com/uribury/1193

1. 백로그 큐를 늘려준다.
직관적으로 보았을 때 서비스 거부에 돌입하게 되는 것은 백로그큐(Backlog Queue)가 가득
차서 다른 접속 요구를 받아들이지 못하기 때문이므로 백로그 큐의 크기를 늘려주면 될 것이다. 실제로 리눅스를 포함해서 많은 운영체제들의 백로그큐값을 조사해 보면 이 값이 필요 이상으로 작게 설정되어 있어 적절히 늘려주는 것이 좋다.
현재 시스템에 설정된 백로그큐의 크기는
[root@net /root]# sysctl -a|grep syn_backlog
net.ipv4.tcp_max_syn_backlog = 128
또는
[root@net /root]# cat /proc/sys/net/ipv4/tcp_max_syn_backlog
128
로 확인가능하며 128kb 인 것을 확인할 수 있다.
일반적으로 시스템의 RAM 이 128M 일 경우에는 128 을 설정하고 그 이상일 경우에는 1024 정도로 설정해 주는 것이 좋다. 이 때 주의할 점은 이 값을 무작정 크게 설정한다고 좋은 것은 아니며 1024 이상으로 설정할 경우는 /usr/src/linux/include/net/tcp.h 소스에서 TCP_SYNQ_SIZE 변수를 수정 후 커널을 재컴파일하여야 한다. 이 변수를 설정시 TCP_SYNQ_HSIZE에 16을 곱한 값이 tcp_max_syn_backlog 보다는 작거나 같아야 하는데, 그렇지 않을 경우에는 시스템에 문제가 발생할 수 있으니 1024 보다 높은 값으로 설정하지 말기 바란다. 그리고 이 값을 너무 크게 설정하였을 경우에는 경험적으로 아래 설명할 syncookies 기능이 잘 적용되지 않는 현상이 가끔 확인되었다.
이와는 별개로 시스템의 부하가 많이 걸릴 경우에도 백로그큐를 늘려주면 일정 정도의 효과를 볼 수 있는 것으로 알려져 있다.
백로그큐의 값을 설정하는 방법은 다음과 같다.
[root@net /root]# sysctl -w net.ipv4.tcp_max_syn_backlog=1024
또는
[root@net /root]# echo 1024 > /proc/sys/net/ipv4/tcp_max_syn_backlog
로 해도 된다.
그러나 이 방법은 임시적인 대책일 뿐, 지속적으로 많은 TCP SYN Flooding 공격을 당할 때는 결국 백로크큐가 가득 차게 되므로 근본적인 해결 방안은 아니다.
2. syncookies 기능을 켠다.
Syncookies(“신쿠키” 라고 발음한다.) 는 "Three-way handshake" 진행 과정을 다소 변경하는 것으로 Alex Yuriev 와 Avi Freedman 에 의해 제안되었는데, TCP header 의 특정한 부분을 뽑아내어 암호화 알고리즘을 이용하는 방식으로 Three-way Handshake 가 성공적으로 이루어지지 않으면 더 이상 소스 경로를 거슬러 올라가지 않는다. 따라서 적절한 연결 요청에 대해서만 연결을 맺기 위해 리소스를 소비하게 되는 것이다.
syncookies 기능은 TCP_Syn_Flooding 공격을 차단하기 위한 가장 확실한 방법으로 이 기능을 이용하려면 일단 커널 컴파일 옵션에서 CONFIG_SYN_COOKIES이 Y 로 선택되어 있어야 한다.
자신의 커널 옵션에 이 기능이 설정되어 있는지 확인하려면
/usr/src/linux 디렉토리로 이동후 make menuconfig 후
Networking options --->
[*] IP: TCP syncookie support (disabled per default)
와 같이 확인하면 된다.
만약 설정이 되어 있지 않다면 선택 후 커널 컴파일을 다시 하여야 하지만 대부분 배포판은 기본적으로 이 옵션이 선택되어 있으므로 걱정할 필요는 없다.
그러나 위와 같이 커널 옵션에 설정되어 있다 하더라도 실제 syncookies 적용은 꺼져 있으므로 이 값을 다음과 같은 방법으로 활성화해야 한다.
[root@control src]# sysctl -a|grep syncookie
net.ipv4.tcp_syncookies = 0
0 으로 설정되어 있으므로 현재 syncookies는 적용되지 않는다.
따라서 아래와 같이 1을 설정하여 syncookies 기능을 활성화하도록 한다.
[root@control src]# sysctl -w net.ipv4.tcp_syncookies=1 or echo 1 > /proc/sys/net/ipv4/tcp_syncookies

syncookies는 백로그큐가 가득 찼을 경우에도 정상적인 접속 요구를 계속 받아들일 수 있도록 해 주므로 SYN_Flooding 공격에 대비한 가장 효과적인 방법중 하나이다.
만약 공격을 당해 syncookies 가 작동할 때에는 /var/log/messages 파일에 아래와 같이 SynFlooding 공격이 진행중이라는 메시지가 출력된다.
Jun 11 18:54:08 net kernel: possible SYN flooding on port 80. Sending cookies.
SYN_Flooding 공격이 지속적으로 매우 심하게 진행중일 때에는 syncookies 기능이 작동한다 하더라도 네트워크가 다운되는 현상이 가끔 확인되었다. 따라서 syncookies 기능 외에 몇 가지 설정도 함께 적용하는 것이 시스템의 안정성을 위해 권장하는 방법이다. 아울러 네트워크가 다운되었을 경우에는 /etc/rc.d/init.d/network restart 로 network 를 재설정해 보거나 reboot 를 하여야 한다.

SYN Flooding조치법
http://cafe.naver.com/dnspro.cafe?iframe_url=/ArticleRead.nhn%3Farticleid=9651
connlimit모듈 설치 후 iptables에 설정
iptables -A INPUT -p tcp --dport 80 --syn -m connlimit --connlimit-above 10 -j DROP

1초동안 80포트에 똑같은 IP가 10번 이상의 SYN패킷이 들어오면 드랍시킨다. 즉 정상적인 요청이 아닌 웹서비스 공격으로 간주하여 요청패킷을 폐기시켜 응답하지 않도록 한다.
iptables -A INPUT -p tcp --dport 80 -m recent --update --seconds 1 --hitcount 10 --name HTTP -j DROP

DDOS공격에 대비하기 위한 캐시구성
다수의 위조된 source ip에서 syn flooding 공격이 발생할 때 아래와 같은 메세지가 나오면서 시스템이 정지되는 경우가 있음

#dmesg
kernel : dst cache overflow
kernel : dst cache overflow
kernel : dst cache overflow

리눅스에서는 각각의 소스의ip에 대해 라우팅캐시로 저장해두는데, syn flooding 공격시에는 이 갯수가 미리 지정된 값을 초과하여 접속이 되지 않는 것으로 현재 수치가 높여져 있지만 더 수치를 조정할 필요가 있습니다.

#route -Cn <-- 현재 라우팅 캐시정보

/proc/sys/net/ipv4/route/max_size = 2097152 => 인식 가능한 라우팅 개수
/proc/sys/net/ipv4/route/secret_interval = 600 => 라우팅을 캐시하는 시간 (600초 10분)
2097152/600=3495   => 초당 신규 라우팅 캐시를 3495개까지 인식 가능
따라서, 위의 경우 초당 4000개 이상의 소스ip에서 접속이 들어오면 시스템이 멈추게 됩니다.
따라서, 공격에 대비하여 아래와같이 설정하는것을 권장합니다.

##대응방법
(1) net.ipv4.route.max_size의 값을 최대한 늘리고 (예:8000000)
(2) net.ipv4.route.secret_interval의 값을 줄인다 (예10)
(3) 또는 ip route flush cache로 캐쉬를 즉시 clear시킨다.

get flooding확인
tcpdump -nn -A | grep GET

---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

출처 : 마이위트(miwit.com)

가장 원초적인 리눅스 서버 보안세팅입니다..
결론부터 말하면, 이 설정으로 DDoS 공격 막을수는 없습니다..최소한의 서버 취약점이나 정보 노출을 막는데 의의가 있을 것입니다.
원래는 /etc/sysctl.conf를 하나 하나 추가해줘야 하는 내용임

#기존 sysctl.conf 백업
cp -afp /etc/sysctl.conf /etc/sysctl.conf_save
# sysctl.conf 안의 내용을 초기화
cat /dev/null > /etc/sysctl.conf

# icmp redirects를 보내지 않는다.
net.ipv4.conf.eth0.accept_redirects=0
net.ipv4.conf.lo.accept_redirects=0
net.ipv4.conf.default.accept_redirects=0
net.ipv4.conf.all.accept_redirects=0
net.ipv4.conf.eth0.send_redirects = 0
net.ipv4.conf.lo.send_redirects = 0
net.ipv4.conf.default.send_redirects = 0
net.ipv4.conf.all.send_redirects = 0
# proxy arp를 설정하지 않는다.
net.ipv4.conf.eth0.proxy_arp=0
net.ipv4.conf.lo.proxy_arp=0
net.ipv4.conf.default.proxy_arp=0
net.ipv4.conf.all.proxy_arp=0
# 게이트웨이로부터의 redirect를 허용하지 않음으로써 스푸핑을 막기 위해 설정한다.
net.ipv4.conf.eth0.secure_redirects=0
net.ipv4.conf.lo.secure_redirects=0
net.ipv4.conf.default.secure_redirects=0
net.ipv4.conf.all.secure_redirects=0
# 스푸핑을 막기 위해 source route 패킷을 허용하지 않는다.
# 소스 라우팅을 허용할 경우 악의적인 공격자가 IP 소스 라우팅을 사용해서 목적지의
# 경로를 지정할 수도 있고, 원래 위치로 돌아오는 경로도 지정할 수 있다. 이러한 소스 라우팅이
# 가능한 것을 이용해 공격자가 마치 신뢰받는 호스트나 클라이언트인 것처럼 위장할 수 있는 것이다.
net.ipv4.conf.eth0.accept_source_route=0
net.ipv4.conf.lo.accept_source_route=0
net.ipv4.conf.default.accept_source_route=0
net.ipv4.conf.all.accept_source_route=0
# Broadcast로부터 오는 핑을 차단함(Smurt 공격을 차단함).
net.ipv4.icmp_echo_ignore_broadcasts=1
# IP 나 TCP 헤더가 깨진 bad icmp packet을 무시한다.
net.ipv4.icmp_ignore_bogus_error_responses = 1
# 자신의 네트워크가 스푸핑된 공격지의 소스로 쓰이는 것을 차단한다.
# 모든 인터페이스에서 들어오는 패킷에 대해 reply를 하여 들어오는 인터페이스로 나가지 못하는 패킷을 거부한다.
net.ipv4.conf.eth0.rp_filter=2
net.ipv4.conf.lo.rp_filter=2
net.ipv4.conf.default.rp_filter=2
net.ipv4.conf.all.rp_filter=2
# bootp 패킷을 허용하지 않는다.
net.ipv4.conf.eth0.bootp_relay=0
net.ipv4.conf.lo.bootp_relay=0
net.ipv4.conf.default.bootp_relay=0
net.ipv4.conf.all.bootp_relay=0
# 스푸핑된 패킷이나 소스라우팅, Redirect 패킷에 대해 로그파일에 정보를 남긴다.
net.ipv4.conf.eth0.log_martians=1
net.ipv4.conf.lo.log_martians=1
net.ipv4.conf.default.log_martians=1
net.ipv4.conf.all.log_martians=1
# 1/100초에 받아들이는 igmp "memberships"의 수
net.ipv4.igmp_max_memberships=1
# 매우 복잡한 사이트에서는 이 값을 늘리는 것도 가능하지만 64로 두는 것이 적당하며
# 더 늘렸을 경우에는 큰 문제가 발생할 수도 있다.
net.ipv4.ip_default_ttl=64
# 게이트웨이 서버가 아닌 이상 패킷을 포워딩 할 필요는 없다.
net.ipv4.ip_forward=0
# fragmented packet이 메모리에 존재하는 시간을 15초로 설정한다.
net.ipv4.ipfrag_time=15
# SYN_Flooding 공격에 대한 대비로 백로그큐(Backlog Queue)가 가득차면 다른 접속 요구를 받아들이지 못한다.
net.ipv4.tcp_max_syn_backlog = 1024
# TCP 연결에서 Three-way Handshake가 성공적으로 이루어지지 않으면 더 이상 소스 경로를 거슬러 올라가지 않도록
# 한다.
# 따라서 적절한 연결 요청에 대해서만 연결을 맺는다.
# syncookies가 작동할 때 SYN Flooding 공격이 있으면 messages 파일에 아래와 같은 내용이 출력된다.
# possible SYN flooding on port 80. Sending cookies.
net.ipv4.tcp_syncookies = 1
# 일정한 시간과 IP별로 보내고 받는 SYN 재시도 횟수를 3회로 제한한다.
# 이 옵션은 스푸핑된(위조된) 주소로 오는 SYN 연결의 양을 줄여준다.
# 기본 값은 5(180 초에 대응)이며 255를 넘지 않아야 한다.
net.ipv4.tcp_syn_retries = 3
# passive TCP 접속시도가 재접속을 하기 위한 SYNACKs의 값을 정한다. 255 보다 높
# 게 지정할 수 없다. 기본값은 5이며, 180초에 대응이 된다.
net.ipv4.tcp_synack_retries = 3
# 무언가 문제가 있을 때 연결을 위해 재시도 할 횟수, 최소 값과 기본 값은 3이다.
net.ipv4.tcp_retries1=3
# TCP 연결을 끊기 전에 재시도할 횟수.
net.ipv4.tcp_retries2=7
# 연결을 종료시 소요되는 시간을 줄여준다(기본 설정값: 60).
net.ipv4.tcp_fin_timeout=20
# 동시에 유지 가능한 timewait 소켓의 수이다.
# 만약 지정된 숫자를 초과하였을 경우에는 timewait 소켓이 없어지며 경고 메시지가 출력된다.
# 이 제한은 단순한 DoS 공격을 차단하기 위해 존재하는데, 임의로 이 값을 줄여서는 안되며
# 메모리가 충분하다면 적절하게 늘려주는 것이 좋은데, 64M 마다 180000으로 설정하면 된다.
# 따라서 256M일 경우에는 256/4=4 4*180000=720000
# 64M -> 180000
# 128M -> 360000
# 256M -> 720000
# 512M -> 1440000
# 1G -> 2880000
# 2G -> 5760000
#net.ipv4.tcp_max_tw_buckets = 180000
#
# 연결이 끊어졌다고 판단할 때까지, 얼마나 keepalive probe 를 보낼지 결정. 기본값 9회
# 간단한 DoS 공격을 막아준다.
net.ipv4.tcp_keepalive_probes=2
# keepalive 가 활성되 되어 있을 경우, 얼마나 자주 TCP 가 keepalive 메세지를 보
# 내게 할 것인지를 설정.
net.ipv4.tcp_keepalive_time=30
# keepalive_probes 를 보낼 간격을 정함. probe 를 보낸 후, probes * intvl 의 시
# 간이 지나도록 응답이 없으면 연결이 해제된 것으로 간주하게 됨. 기본 값의 사용
# 시 11분 15초 동안 재시도를 하고 연결을 취소함. 값은 초단위
net.ipv4.tcp_keepalive_intvl = 10
# 서버 쪽에서 닫은 TCP 연결을 끊기 전에 확인하는 횟수를 정한다. 기본 값은 7 로
# RTO 50 초에서 16 분 사이에 해당한다. 웹 서버가 운영 중 이라면 이 값을 줄여서
# 소켓 등이 귀한 리소스를 소비하지 않도록 할 수도 있다.
net.ipv4.tcp_orphan_retries = 2
# SYN 패킷을 전송한 후에 로스가 발생을 하여 ACK 를 일부 받지 못했을 경우, 선택
# 적으로 (selected) 받지못한 ACK 만 받도록 요청하는 것을 허락한다. 로스가 많은
# 네트워크에서는 상당히 중요한 역할을 한다.
net.ipv4.tcp_sack = 1
#설정끝

#sysctl -p

#iptables설정
# 한 ip에서 20개 이상의  syn 요청이 올경우 차단(connlimit설정은 커널에서 모듈이 로드되어 있어야됨)
#/sbin/iptables -A INPUT -p tcp --syn -m connlimit --connlimit-above 20 -j DROP

# syn 20번연결후 초당 10회연결제한
/sbin/iptables -N syn-flood1
/sbin/iptables -A INPUT -p tcp --syn -j syn-flood1
/sbin/iptables -A syn-flood1 -m limit --limit 10/s --limit-burst 20 -j RETURN
/sbin/iptables -A syn-flood1 -j DROP

#한사용자가 열수 있는 파일 수 제한 “too many open files” 오류 예방
ulimit -n 32768

 

# IP당 count수 확인(로그참조)
cat /usr/local/apache/logs/도메인-access_log | grep "list.html"| cut -d" " -f1|sort -n |uniq -c|sort -n |tail -n 100


1 2 3 4 5 6 7