'대응방법'에 해당되는 글 3건

  1. 2012.03.05 웹 해킹 서버 분석과 웹쉘 대응방법 (1)
  2. 2009.09.14 최신 해킹 기법 분석 및 보안 대책 SQL Injection
  3. 2009.02.03 DDoS에 대응하는 원론적인 방법
2012.03.05 09:26

웹 해킹 서버 분석과 웹쉘 대응방법

가끔 접속 자 수도 많지도 않은데 로드가 높아서 서버 접속이 원활하지 못하다거나 나의 서버가 스팸서버로 지정 되어서 상대방에게 메일을 보냈는데도 차단되었다거나 혹은 idc 보안 관제 센터에서 당신네 서버가 외부로 ddos공격을 하고 있으니 빨리 조치를 취하지 않으면 네트워크를 차단시키겠다는 경고성 전화를 받았을 때 어떻게 조치를 취해야 하는지 막막할 경우가 있다.

 

이럴 경우 웹 해킹에 의해서 서버가 해커에 의해 조종되고 있지 않는지 살펴 볼 필요성이 있다이번에는 실제 사례를 가지고 웹 해킹 침해 사고 시 대처 방법을 소개해 보고자 한다.

 
해킹된 서버는 redhat9를 사용하고 있으며 커널 버전은 2.4.20-8이다웹서버는 apache + php + mysql 기반으로 돌아가고 있으며 앞으로 모든 설명을 여기에 맞추어서 진행 하려고 한다. (윈도우에 asp는 해당 사항이 아니다.) 


pstree

init-+-bdflush

     |-crond

     |-httpd-+-40*[httpd]

     |       `-2*[httpd---read.cgi]

     |-httpd---httpd

     |-httpd

     |-kapmd

     |-keventd

     |-khubd

     |-10*[kjournald]

     |-2*[klogd]

     |-kscand/DMA

     |-kscand/HighMem

     |-kscand/Normal

     |-ksoftirqd_CPU0

     |-kswapd

     |-kupdated

     |-mdrecoveryd

     |-6*[mingetty]

     |-named

     |-nohup---a---sshd---101*[sshd]

     |-perl

     |-rhnsd

     |-safe_mysqld---mysqld

     |-sshd---sshd---bash---pstree

     |-11*[sshd]

     |-syslogd

     |-vsftpd

     |-us1---us1

     |-us10---us11

     |-us12---us12

     |-us13---us13

     |-us14---us14

     |-us15---us15

     |-us16---us16

     |-us17---us17

     |-us18---us18

     |-us19---us19

     |-us2---us2

     |-us21---us21

     |-us22---us22

     `-xinetd

pstree명령어는 현재 돌아가고 있는 서버의 프로세스를 한눈에 파악할 수 있는 아주 중요한 명령어이다리눅스 사용자는pstree명령어에 익숙해 져야 한다그냥 시간 날 때 마다 pstree치면서 나오는 결과를 눈에 익도록 하는 게 낫다.

 

위에 출력 결과를 한번 분석해 보도록 하자.

|-httpd-+-40*[httpd]

|       `-2*[httpd---read.cgi]

|-httpd---httpd

|-httpd

 

아파치 웹 서버가 돌아가면 위와 같은 프로세스가 보인다허나 진짜 웹 서버는 첫째 줄 뿐이다나머지는 두번째 줄과 세번째 줄은  웹 서버로 위조된 해킹 프로세스이다.

|-nohup---a---sshd---101*[sshd]

이 부분을 보자 외부로 ssh Login Brute force scan 공격을 하고 있다마찬가지로 us로 시작하는 프로세스도 모두 외부로 공격하는 해킹프로세스이다정상적인 서버에서는 절대 볼 수 없는 프로세스들이다이외에도 perl같은 프로세스도 비정상 프로세스이다.

현재 이 서버는 외부로 공격을 수행하는 해킹 프로세스들이 매우 많이 수행되고 있는 중이다.

 

포트 상태를 점검해서 좀더 자세한 상황을 살펴보자.

# netstat -nlp

Active Internet connections (only servers)

Proto Recv-Q Send-Q Local Address              Foreign Address   State                    PID/Program name  

tcp         0      0 0.0.0.0:3306                        0.0.0.0:*               LISTEN                655/                

tcp         0      0 0.0.0.0:80              0.0.0.0:*               LISTEN                26032/httpd        

tcp         0      0 0.0.0.0:2                             0.0.0.0:*               LISTEN                612/vsftpd         

tcp         0      0 192.168.10.1:53                    0.0.0.0:*               LISTEN                575/               

tcp         0      0 127.0.0.1:53                        0.0.0.0:*               LISTEN                575/               

tcp         0      0 0.0.0.0:22              0.0.0.0:*               LISTEN                588/sshd           

tcp         0      0 127.0.0.1:953                       0.0.0.0:*               LISTEN                575/               

udp        0      0 0.0.0.0:32768                       0.0.0.0:*                                          575/               

udp        0      0 0.0.0.0:37028                       0.0.0.0:*                           25089/sshd         

udp        0      0 0.0.0.0:37029                       0.0.0.0:*                           25479/httpd        

udp        0      0 192.168.10.1:53                    0.0.0.0:*                           575/               

udp        0      0 127.0.0.1:53                        0.0.0.0:*                           575/               

Active UNIX domain sockets (only servers)

Proto RefCnt Flags       Type       State         I-Node PID/Program name    Path

unix  2      [ ACC ]     STREAM     LISTENING     1318   655/                /var/lib/mysql/mysql.sock

 

정상적인 웹 서버는 다음과 같이 나타난다. 80포트가 열려져 있는 것을 알 수 있다. 26032는 실행되고 있는 아파치 프로세스의 pid이다.

tcp         0      0 0.0.0.0:80              0.0.0.0:*               LISTEN                26032/httpd

 

udp        0      0 0.0.0.0:37029                       0.0.0.0:*                           25479/httpd        

위의 프로세스를 보자. pid 25479인 이 프로세스는 아파치 웹서버 프로세스로 위장 되어 있지만 실질적으로는 37029번 포트로 서비스 되고 있는 hack 프로세스이다그리고 tcp가 아니 udp를 사용하고 있는 것도 눈에 띈다. sshd 프로세스도 마찬가지이다. 22번 포트를 LISTEN하고 있는 pid 588 프로세스가 정상적인 sshd 프로세스이다. 25089프로세스는sshd로 위장된 비 정상적인 프로세스이다.

3306포트와 53번 포트를 리슨하고 있는 것은 각각 mysqld named프로세스로 정상적인 프로세스들이다.

 

이제는 좀더 깊이 들어가서 이 프로세스들이 어디서 실행되고 있는지 한 번 살펴 보자.

lsof -p 25479

lsof 명령어는 파일과 프로세스의 입출력 상태를 나타내주는 명령어로 pstree netstat 다음으로 사용법을 잘 익혀둘 필요가 있는 매우 유용한 명령어이다. p옵션은 프로세스 id의 입출력 상태를 나타내주는 옵션으로 다음 부분을 살펴볼 필요가 있다.

 

COMMAND   PID   USER   FD   TYPE    DEVICE    SIZE      NODE NAME

httpd       25479      apache   cwd       DIR         0,8     280 321300582 /dev/shm/bq

httpd       25479      apache   txt          REG       0,8  612470 321300590 /dev/shm/bq/httpd

httpd       25479      apache   0u          IPv4        563618039 TCP 192.168.10.1:48562

->irc2.saunalahti.fi:ircd (ESTABLISHED)

httpd   25479 apache    5u   REG       3,7       0        55 /tmp/ZCUDUzGlho (deleted)

httpd   25479 apache    6u  IPv4 321303856               UDP *:37029

 

일단 이 위장 프로세스가 실행되고 있는 위치는  /dev/shm/bq/httpd라는 것을 알 수 있다.

192.168.10.1:48562->irc2.saunalahti.fi:ircd (ESTABLISHED)

이 부분을 주의 깊게 살펴 보자현재 해킹된 서버에서 irc2.saunalahti.fi 서버의 6667(ircd)포트로 접속 되어 있는 것을 알 수 있다즉 이 서버는 현재 좀비 컴퓨터화 되어 있다한마디로 말해서 해커가 원격에서 irc bot을 이용하여 이 서버를 자신이 원하는 데로 조종할 수 있다는 말이다이러한 좀비 컴퓨터를 대량으로 확보하면 해커는 보통 분산 서비스 거부 공격(DDOS ATTACK)을 하는데 이용하거나 돈을 받고 팔기도 한다특히 IDC에 상주되어 있는 서버가 해커 손에 넘어가면 최대 100M급의 트래픽 공격을 할 수 있는 든든한 무기를 손에 넣게 된다.

 

USER부분을 살펴보자 apache라고 되어 있다현재 이 서버에서 실행되고 있는 웹서버의 권한이 apache로 웹해킹을 통해서 서버의 apache권한을 획득한 것을 볼 수 있다.

 

다음과 같은 명령으로 이서버의 전체적인 입출력 상태를 체크해 볼 수 있다.

lsof –I –n |grep apache

문제가 되는 apache권한만 살펴 보면 다음과 같은 입출력 상태가 2~300개씩 나타나고 있었다.

 

sshd    23901 apache    8u  IPv4 397205096       TCP 192.168.10.1:56970->217.18.114.168:ssh (ESTABLISHED)

외부에 ssh스캔 공격을 하고 있을 때의 대표적 증상이다만약 다량의 스팸 메일을 보낸다면 외부 ip 25번포트(SMTP포트)로 수많은 연결이 보일 것이다이 외에도 ircd로의 접근도 포착 될 것이다.

lsof 명령어는 서버의 입출력 상태를 점검할 때 매우 유용한 명령어이니 잘 익혀두는 것이 좋다.

 

일단 hack process가 설치된 /dev 디렉터리를 좀더 자세히 점검해 보자.

find /dev –type f

일단 정상적인 경우를 살펴보자

 

/dev/.udev.tdb

/dev/MAKEDEV

centos5같은 경우

/dev/.udev 디렉토리와 그 아래 디렉토리만 파일들만 있어야지 정상이다.

 

find 명령어로 살펴보니 아래와 같은 많은 수많은 hack tool들이 설치 되어 있는 것을 확인 할 수 있었다.

/dev/MAKEDEV

/dev/shm/stopex.pl

/dev/shm/bq/raw.session

/dev/shm/bq/Presedinte.seen

/dev/shm/bq/Silvic.seen

/dev/shm/bq/RamonaT.seen

/dev/shm/bq/httpd

/dev/shm/bq/3

/dev/shm/st/src/dcc.c

/dev/shm/st/src/parse.c

/dev/shm/st/src/main.c

/dev/shm/st/src/gencmd.c

/dev/shm/st/src/Makefile

 

웹쉘 권한을 얻었을 때 이와 같은 툴들이 설치되는 이유는 퍼미션 때문이다.

 

ll –ld /dev/shm

drwxrwxrwt 2 root root 40 Nov  6 13:33 /dev/shm

/dev/shm, /var/tmp, /tmp 폴더등은 1777권한을 가지고 있기 때문에 웹쉘을 통해 권한을 얻었을 경우 쉽게 해킹툴들을 업로드 하고 이를 실행 시키는데 사용되는 디렉터리로 평소 주의를 기울여 관리해야 한다이외에도 디렉터리에 apache nobody유저에 쓰기 권한을 주거나 777같은 퍼미션을 주는 경우는 매우 잘못된 습관이라고 할 수 있다.

 

# cd /dev/shm/st

[root@canacom st]# ll

합계 836

-rwxr-xr-x    1 apache   apache       2156  7 11  2005 Makefile

-rwxr-xr-x    1 apache   apache      20358  1  2  2003 configure

-rwxr-xr-x    1 apache   apache     585643  1  4  2007 sshd

-rwxr-xr-x    1 apache   apache      17495  1  4  2007 stealth

 

보면 apache권한을 가지고 있는 것을 알 수 있다.

lsof 명령어로 보여주는 결과 값이 너무 길어서 의미가 있는 것 만 적었다다음 perl명령어는 원격에서 root로 쉘 권한을 가지고 직접 접속해서 명령을 내린 것으로 해커가 어떤 방법을 써서 아파치 권한에서 root로 권한이 상승 된 것을 확인 할 수 있다.

 

lsof -p 6411

COMMAND  PID USER   FD   TYPE    DEVICE     SIZE   NODE NAME

perl    6411 root  cwd    DIR       3,7     4096  87745 /tmp/.tmp

perl    6411 root  rtd    DIR      22,9     4096      2 /

perl    6411 root  txt    REG       3,5    12572  33642 /usr/bin/perl

perl    6411 root    0u   CHR     136,1               3 /dev/pts/1

perl    6411 root    1u   CHR     136,1               3 /dev/pts/1

perl    6411 root    2u   CHR     136,1               3 /dev/pts/1

perl    6411 root    3r   REG       3,7   116030  87748 /tmp/.tmp/bnc

perl    6411 root    4u  IPv4 398045837             TCP *:24338 (LISTEN)

perl    6411 root    5r   DIR       3,7     4096  43873 /tmp/.tmp/logs

perl    6411 root    6u  IPv4 398046908             TCP 192.168.10.1:24338->189.14.64.131:1327 (ESTABLISHED)

perl    6411 root    7u  IPv4 398046908             TCP 192.168.10.1:24338->189.14.64.131:1327 (ESTABLISHED)

perl    6411 root    8u  IPv4 398049150             TCP 192.168.10.1:35825->own.ipapo.org:ircd (ESTABLISHED)

 

다음 부분을 주목해서 보자.

perl    6411 root    0u   CHR     136,1               3 /dev/pts/1

원격 터미널을 통해서 슈퍼유저 권한으로 로그인한 것으로 추정된다이 상태에서 이미 최상위 권한을 탈취했으므로 이 시스템은 완전히 해커에게 장악 당했다고 볼 수 있다.

 

다음과 같은 명령으로 서버에서 실행되는 백 도어 프로세스에 관한 좀더 자세한 정보를 알 수 있다테크노트 게시판의 취약점을 이용해서 원격에서 쉘 명령어를 실행 시킨 것을 알 수 있다.

 

#ps -auxe --cols=3000

/usr/sbin/sshd shd _CMD=cd /dev/shm/n; nohup ./start 217 >>/dev/null & 2>&1;pwd SERVER_SIGNATURE=<ADDRESS>Apache/1.3.31 Server at test.co.kr

Port 80</ADDRESS>?

HTTP_USER_AGENT=Getter/0.1

SERVER_PORT=80

HTTP_HOST=www.test.co.kr

DOCUMENT_ROOT=/home/test/public_html SCRIPT_FILENAME=/home/test/public_html/technote/main.cgi REQUEST_URI=/technote/main.cgi?down_num=784879&board=any&command=down_load&filename=getfile.txt%3Bsh%20-c%20%22%24HTTP_CMD%22| SCRIPT_NAME=/technote/main.cgi

REMOTE_PORT=55507

PATH=/sbin:/usr/sbin:/bin:/usr/bin:/usr/X11R6/bin

HTTP_TE=deflate;q=0.3

PWD=/dev/shm/n

QUERY_STRING=down_num=784879&board=any&command=down_load&filename=getfile.txt%3Bsh%20-c%20%22%24HTTP_CMD%22|

SERVER_ADDR=192.168.10.1

GATEWAY_INTERFACE=CGI/1.1

SERVER_PROTOCOL=HTTP/1.0

REQUEST_METHOD=GET _=./sshd

 

테크노트 cgi 관한 원격 명령어 실행 취약점은 국정원에서 발표한 보안 취약점 8종의 한가지로 반드시 최신 버전의 테크노트로 업그레이드 하여야 한다.

 

또한 php를 사용할 경우는 반드시 php.ini 파일에

allow_url_fopen = Off

register_globals = Off

로 해놓는 것을 명심하자지금까지 경험한 바로 php경우 대부분 저 두 옵션으로 인하여 문제가 발생했다.

또한 php 개발자분들께 당부하고 싶은 것은 위의 두 옵션을 끄고 코딩을 해야 한다는 것이다그렇지 않을 경우 원한 던 그렇지 않던 잠재적인 보안 위협을 가진 소스를 만들어 내게 된다.

 

지금까지 웹 해킹 침해 사고를 당한 시스템을 간단하게 분석해 보았다. pstree, netstat, lsof, ps 명령어등은 리눅스에서 트러블슈팅을 하는데 정말 요긴하게 사용하는 명령어이므로 사용법을 자세하게 알아둘 필요가 있다일단 해커가 웹 쉘 권한을 얻으면 가능한 모든 디렉터리에 웹 쉘을 업로드 하여 하나의 침입경로가 막히면 다른 경로로 들어오기 때문에 대처하는데 어려움이 따른다.

 

그렇기 때문에 다시 한번 강조하지만 allow_url_fopen = Off, register_globals = Off 잊지 말도록 하자.


일단 웹쉘이 서버에 업로드 되면 그 서버는 해커의 수중에 들어 갔다고 보아야 한다이후 해커는 다양한 방법으로 서버의 정보를 취득하고 해킹툴을 이용해서 권한 상승을 노린다.

 

allow_url_fopen = On인 웹 페이지 취약점을 통해 다음과 같이 쉘권한을 얻을 수 있다. 

  
http://www.test.com/Test.php  ----------------->   http://hack.com/webshell.txt
  

타킷서버의 Test.php에 취약점이 존재하는 경우 hack.com에 존재하는 webshell을 불러들여 쉘 권한을 획득 한 다음 내부 서버의 정보를 모으고 백도어를 설치하고 권한 상승을 노린다대표적으로 구 제로보드에서 많이 발생하고 있다.

웹쉘 실행 화면

 

이제부터 이러한 웹쉘에 대한 대응 방법에 대해 몇 가지 알아 보려고 한다.

 

우선 첫째로 당연한 것이겠지만 자신이 운영하고 있는 웹소스에서 보안 취약점을 제거해야 한다하지만 이것은 실제적으로 침해사고를 당하지 않는 한 탐지하기가 어려운 면이 있다특히 자신이 개발자가 아니고 단순히 운영만 하는 입장이라면 더욱 그렇다하지만 널리 알려진 웹 보안 취약점은 modsecurity 같은 무료 웹 방화벽으로 공격을 사전 차단 할 수 있을 뿐 아니라 차단 기능을 꺼 놓고 로그만 기록하게 해도 나중에 사고를 당했을시 로그 분석을 통해 원인을 찾는데 도움이 되므로 가능한 운영하는게 좋다공개 무료 웹방화벽 운영에 관한 자료는 정보보호진흥원에서 운영하는 다음 사이트에서 많은 도움을 받을 수 있다.

http://www.krcert.or.kr/firewall2/index.jsp

 

두번째는 필요없는 php 함수들은 사용 할 수 없게 하는 것도 하나의 방법이다설정은 php.ini  다음과 같은 방법으로 할 수 있다.

 

대부분이 서버의 정보를 보여주는 설정들이다서비스에 별 필요 없는 기능들이고 서버에 어떠한 영향을 주는 함수들은 아니지만 해커에 의해 악용 될 수 있기 때문에 막아 놓은 것이 나을것이다.

disable_functions = php_uname, ini_set, getenv, get_user, phpversion, ini_get, ini_get_all, phpinfo, system, exec, passthru, escapeshellcmd, pcntl_exec, shell_exec

특히 주의할 점은 system, exec, passthru, escapeshellcmd, pcntl_exec, shell_exec 함수들은 서버상에서 운영체제 명령어를 실행 시키는 명령들이다일단 웹쉘이 업로드 되면 위의 함수들로 서버상에서 작업을 할 수 있으므로 막는게 좋으나 실제 운영되고 있는 홈페이지에서도 사용 할 수 있으므로 잘 알아 보고 필요한 함수는 빼고 설정 하는 것이 좋다.

 

세번째는 파일업로드 기능을 사용하지 않는다면 php.ini 에서 file_uploads 기능을 off 시키거나 파일 업로드를 한다면 업로드 디렉터리에 .htaccess을 사용해 업로드 되는 디렉터리에서는 php를 아예 사용 할 수 없게 하는 것이다.

 

파일을 업로드 시키는 디렉터리에 다음과 같이 .htaccess 파일을 작성하자.

 

<FilesMatch "\.(html|htm|php|pl|cgi|inc|lib)">

Order allow,deny

Deny from all

</FilesMatch>

해당 확장자로 끝나는 파일들은 접속이 금지된다.

 

이 방법은 해커가 웹쉘을 업로드 할 때도 사용 할 수 있다.

만약 php확장자를 가진 소스를 업로드 하지 못하게 했다면 해커는 다음과 같이 하여 확장자를 우회할 수 있다.

다음 내용을 가진 .htaccess파일을 업로드 시킨다.

AddType application/x-httpd-php  .txt

이후 txt 파일은 모두 php로 인식한다해커는 웹쉘의 확장자를 txt파일로 변경하여 서버에 올리면 된다.마찬가지 방법으로 다음과 같은 .htaccess 파일을 올려서 바이러스나 해킹툴을 설치하기도 한다.

ErrorDocument 403 http://www.hacktest.co.kr/hack.txt

ErrorDocument 404 http://www.hacktest.co.kr/hack.txt

 

이는 다음과 같은 명령어로 탐지가 가능하다.

find `locate .htaccess` -exec egrep -l -i ‘txt’ {} \; 2>/dev/null

find `locate .htaccess` -exec egrep -l –I ‘http://’ {} \; 2>/dev/null

 

그 다음으로 할 일은 서버에 업로드 된 웹쉘을 제거하는 일이다한국 정보보호진흥원에서 개발한 웹 쉘 탐지 프로그램 Whistl을 이용하여 서버에 업로드 된 웹쉘을 제거 할 수 있다이 프로그램은 리눅스는 물론 윈도우에서도 동작하고 정확성도 높기 때문에 웹쉘 탐지 및 제거에 매우 추천 할 만한 프로그램이다.

프로그램은 다음 사이트의 공지사항에서 신청서를 작성한 후 신청하면 사용 할 수 있다.

http://www.krcert.or.kr/index.jsp

사용방법은 상당히 직관적이고 쉬운편이다보내온 프로그램의 압축을 풀면 프로그램과 함께 설명서에 사용법이 적혀져 있다다음과 같이 간단히 사용 할 수 있다.

./whistl_kernel_2.6 –c

우선 자기 서버에 맞게 환경 설정을 해준다.

whistl Configuration

        [1] Checking Directory : /home/sungon

        [2] Inspection Center directory : /tmp

        [3] Extension of php     : inc,php,php3,php4,php5,ph

        [4] Extension of jsp     : jsp,js

        [s] save

        [q] quit

1번 메뉴를 누르고 검사할 디렉터리를 지정해 준다. /home 폴더 전체를 지정해 줄 수도 있다.

Choose Menu : 1

Checking Directory :/var/www/html

 

        [1] Checking Directory : /var/www/html

        [2] Inspection Center directory : /tmp

        [3] Extension of php     : inc,php,php3,php4,php5,ph

        [4] Extension of jsp     : jsp,js

        [s] save

        [q] quit

3번 메뉴을 누르고 검사할 파일의 확장자를 지정해 준다. txt확장자를 추가해 주었다.

Choose Menu : 3

Extension of php :inc,php,php3,php4,php5,ph,txt

 

        [1] Checking Directory : /var/www/html

        [2] Inspection Center directory : /tmp

        [3] Extension of php     : inc,php,php3,php4,php5,ph,txt

        [4] Extension of jsp     : jsp,js

        [s] save

        [q] quit

Choose Menu : s

 

        [1] Checking Directory : /var/www/html

        [2] Inspection Center directory : /tmp

        [3] Extension of php     : inc,php,php3,php4,php5,ph,txt

        [4] Extension of jsp     : jsp,js

        [s] save

        [q] quit

Choose Menu : q

 

다음과 같이 검사를 하면

./whistl_kernel_2.6

id : testid

pwd : password

Checking the configration

        [Config] Checking directory : /var/www/html

        [Config] Inspection Center directory : /tmp

 

Checking the update status

        [INFO] Pattern Update Finished

 

Checking /var/www/html directory

        [5 Found] /var/www/html/test2.php

        [18 Found] /var/www/html/test.txt

 

Check Result

        [INFO] 2 Files checked

        [INFO] 2 Suspected WebShell

        [INFO] Time cost : 00:00:10

        [INFO] Finish sending the checking result

웹쉘이 탐지되는 것을 알 수 있다. [5 Found]  [18 Found] 같은 숫자는 해당 파일에서 모두 5개의 웹쉘 패턴이 일치되었다는 것을 말한다. 5이상은 웹쉘이 거의 확실하지만 일치되는 패턴 숫자가 1이나 2이라면 정상적인 파일이 아닌지 확인해 봐야 한다경험상 1이나 2는 거의 정상적인 파일이고 패턴대응 숫자가 5이상이면 웹쉘이 확실하다고 보면 된다.

다만 아쉬운 점은 프로그램이 복수의 확장자를 지원하지 않는다는 사실이다아파치(apache)에서는 복수의 확장자를 지원하기 때문에 webshell.php.test 같은 확장자를 가진 프로그램도 모두 php로 인식한다때문에 확장자를 약간만 변경하면 탐지프로그램을 우회할 수 있다.

이 부분은 추후에 개선이 되야 할 사항 같다.

 

리눅스를 사용하는 경우에는 디렉터리나 파일의 퍼미션에도 신경을 써야 한다. 777 퍼미션이나 파일이나 디렉터리에 apache nobody로 소유권을 설정하는 것은 가능한 피해야 한다.

업로드 디렉터리나 세션이 저장되는 디렉터리에는 어쩔 수 없이 707 퍼미션을 주어야 겠지만 그 외의 디렉터리에는 701 퍼미션을 주고 파일에는 644 퍼미션을 준다. cgi같은 경우에는 755퍼미션을 주지 않으면 실행이 되지 않으므로 주의한다.

 

그외에도 /etc/cron.daily에 스크립트를 하나 만들어 다음과 같이 명령어에 제한을 걸어 슈퍼유저외에는 사용을 못하게 할 수도 있다.

 

#!/bin/sh

chmod 701 /

chmod 701 /home

 

cd /etc

chmod 600 fstab

chmod 600 hosts.*

chmod 600 modprobe.conf

chmod 600 sysctl.conf

chmod 600 redhat-release

 

cd /usr/bin

chmod 700 wget

chmod 700 lynx

chmod 700 curl

chmod 700 lwp-*

chmod GET

 

만약 사용되고 있는 서버가 여러 유저들이 모두 같이 사용하는 서버라서 명령어 제한이 자유롭지 못하다며acl 기능을 사용해서 nobody권한의 유저만 제한을 걸 수 도 있다.

acl 기능은 다음과 같이 하면 사용 할 수 있다.

 

vi /etc/fstab

/dev/sda8               /                       ext3    defaults,acl        1 1

/dev/sda7               /usr                    ext3    defaults,acl        1 2

이렇게 acl을 옵션으로 붙여주고 다시 리마운트 한다.

mount -o remount /

mount -o remount /usr

 

다음과 같이 제한하고자 하는 명령어에 nobody유저만 접근이 안되게 한다.

setfacl -R -m u:nobody:- `which find`

setfacl -R -m u:nobody:- `which ls`

setfacl -R -m u:nobody:- `which chmod`

setfacl -R -m u:nobody:- `which echo`

setfacl -R -m u:nobody:- `which cat`

 

정책이 정확하게 적용이 되었는지 확인한다.

ls –al `which find`

-rwxr-xr-x+ 1 root root 52460 Oct 20  2004 /usr/bin/find

끝에 +가 붙어 있으면 acl기능이 작동을 하는 것이다. acl기능을 제거 하려고 하면 다음과 같이 하면 된다.

setfacl -b /usr/bin/find

이상으로 웹 해킹 서버에 대한 간단한 분석 방법과 서버에서의 웹쉘에 대한 대처 방법에 대해 마치려고 한다웹서버 보안은 하나의 보안 어플리케이션으로 모든 것을 완벽하게 막을 수는 없다가능한 알고 있는 모든 방법을 다 적용하여서 조금씩 보안 허점을 줄여 나가는 수밖에 없다또한 리눅스 같은 경우 반드시 방화벽 정책을 수립하여 운영함으로써 해커가 서버를 악의적으로 운영하거나 외부로 공격을 하지 못하게 해야 한다이에 관해서는 차후에 다루어 보도록 하겠다.



by 블루웹 시스템연구개발팀 양선곤 http://blog.blueweb.co.kr/


Trackback 3 Comment 1
  1. 박병권 2012.03.06 09:23 address edit & del reply

    좋은글 감사합니다.

2009.09.14 17:21

최신 해킹 기법 분석 및 보안 대책 SQL Injection

해킹은 유명무명 사이트를 가리지 않고 진행되며 운영체제 역시 가리지 않는다. 문제는 그뿐이 아니다. 아마 리스트에 나타난 사이트를 운영하는 회사 중 대부분은 자신들이 해킹을 당했고, 지금도 계속 해킹을 당하고 있다는 사실조차 인지하지 못하고 있을 것이라는 점이다. 멀쩡한 외양간을 고치는 것은 시간과 비용의 낭비처럼 느껴질지 모르지만, 소를 잃는 것보다는 나은 일이다. 이제부터는 해커들이 그렇게 많은 사이트를 제 집 드나들 듯이 드나들며 유린하는 데 사용하는 해킹 기법과 그에 대한 보안 대책을 통해 우리가 관리하는 외양간을 더욱 튼튼하게 하는 법을 연구해보자.

그만큼 윈도우 운영체제가 외부에 많이 노출되어 있고 공격자들의 대상이 되기도 쉽다는 뜻이다. 물론, 이것은 보는 관점에 따라 달라질 수 있지만 공격대상의 관점에서만 본다면 매력 있는 것임은 분명하다. 악성코드의 관점에서 예를 들어 보자. 악성코드 확산을 효과적으로 막는 방법은 무엇일까? 많이 사용되고 있는 운영체제 또는 응용프로그램을 이용하는 것이 보다 효과적일 것이다. 이러한 이유로 유닉스 시스템의 악성코드보다는 윈도우 환경의 악성코드가 많이 발견되는 것이다.

파일 업로드

파일 업로드(File Upload) 공격은 공격자가 공격 프로그램을 해당 시스템에 업로드하여 공격하는 방법을 말한다. 파일 업로드는 공격이 쉬우면서도 영향력이나 파급 효과는 큰 공격 방법이다. 공격 방식은 공격자가 시스템 내부 명령을 실행할 수 있는 웹 프로그램(ASP, JSP, PHP)을 제작하여 자료실과 같이 파일을 업로드할 수 있는 곳에 공격용 프로그램을 업로드하는 것이다. 그리고 웹 브라우저를 이용해 공격용 프로그램에 접근하면 시스템 내부 명령을 실행시킬 수 있게 되는데, 이를 이용해 공격자는 리버스 텔넷(Reverse Telnet)과 같은 기법으로 자신의 컴퓨터로 피해 대상 시스템의 명령 창을 띄워 편하게 작업할 수도 있다. 쉽게 말해, 원격지에서 공격한 컴퓨터의 전권을 가지게 되는 것이다.
그렇다면 이러한 파일 업로드 공격에 어떻게 대응해야 할까? 가장 간단하고 효과적인 방법으로는 업로드할 때 파일 확장자 이름을 확인하는 것이다. 이때 asp나 jsp같이 업로드되는 확장자를 소문자만 체크하지 않도록 주의해야 한다. 시스템은 aSp나 jSp 같은 대소문자 혼합도 인식하기 때문에 모든 가능한 조합에 대해 필터링해야 한다. 반대로 특정 확장자 이름을 가진 파일만 업로드되도록 하는 것도 좋은 방법이다. 이때 또 한 가지 주의할 점은 필터링을 위해 자바스크립트 같은 클라이언트 스크립트 언어를 사용하지 말아야 한다는 점이다. 어느 정도 숙달된 해커라면 클라이언트 스크립트 언어쯤은 얼마든지 수정할 수 있기 때문에 asp나 jsp 같은 서버 쪽 스크립트 언어에서 필터링해야 한다.
필터링 이외에 파일이 업로드되는 디렉토리의 실행 권한을 없애는 방법이 있다. 이 경우에는 파일이 업로드되더라도 실행되지 않기 때문에 브라우저에 그대로 나타나거나 파일을 다운로드하게 된다.

디렉토리 탐색

디렉토리 탐색(Directory Traversal)은 웹 브라우저에서 확인 가능한 경로의 상위로 올라가서 특정 시스템 파일을 다운로드하는 공격 방법이다. 자료실에 올라간 파일을 다운로드할 때 전용 다운로드 프로그램이 파일을 가져오는데 이때 파일 이름을 필터링하지 않아서 생기는 취약점이다. 특정 파일을 다운로드할 때 다음과 같은 URL을 이용하여 다운로드한다고 하자.

http://www.stsc.co.kr/board/down.jsp?filename=saintsecurity.doc

공격자는 filename 변수에 해당하는 값을 다음과 같이 간단한 조작을 통해 상위 디렉토리로 거슬러 올라가 /etc/passwd 파일을 다운로드할 수 있다.

http://www.stscco.kr/board/down.jsp?filename=../../../../../../../ ../../../../etc/passwd

전용 파일 다운로드 프로그램을 이용할 때는 위의 예에서 보는 바와 같이 ‘..’ 문자열이나 ‘/’ 문자열에 대한 필터링이 없을 경우, 공격자는 상위로 올라가 특정 파일을 열어볼 수 있기 때문에 ‘..’와 ‘/’ 문자를 필터링해야 한다. 파일 업로드의 경우와 마찬가지로 자바스크립트와 같은 클라이언트 스크립트 언어로 필터링하면 공격자가 우회할 수 있기 때문에 반드시 jsp나 asp 등 서버 쪽 스크립트 언어에 필터링을 추가해야 한다.

디렉토리 리스팅

디렉토리 리스팅(Directory Listing)은 웹 브라우저에서 웹 서버의 특정 디렉토리를 열면 그 디렉토리에 있는 모든 파일과 디렉토리 목록이 나열되는 것을 말한다. 이것이 디렉토리 리스팅의 취약점이다. 물론 관리자가 어떤 목적을 위해서 웹 서버의 특정 디렉토리를 리스팅할 수 있도록 설정하기도 하지만, 어쨌든 공격자는 디렉토리 리스팅 취약점을 이용하여 웹 서버에 어떤 파일이 있는지 확인할 수 있고 추가적인 공격 취약점을 찾을 수 있다. 대부분의 웹 서버의 경우 해당 디렉토리 리스팅에 대한 여부를 가능 혹은 불가능하게 하는 옵션이 따로 준비되어 있다. 해당 설정 내용을 적절하게 변경하주면 디렉토리 리스팅을 이용한 공격은 통하지 않는다. 

인증 우회

인증 우회란 관리자 페이지나 인증이 필요한 페이지에 대한 인증을 처리하지 않고 인증을 우회하여 접속할 수 있는 취약점을 말한다. 이 취약점에 노출되면 일반 사용자나 로그인하지 않은 사용자가 관리자 페이지에 접근하여 관리자 권한을 획득한 뒤에 모든 기능을 자신이 원하는 대로 악용할 수 있게 된다. 이런 취약점은 간단하지만 의외로 웹 개발자가 자주 범하는 실수이다. 인증 우회는 아주 간단한 방법으로 공격이 이루어진다. 일반적으로 관리자로 로그인한 뒤 관리자가 이용하는 웹 페이지에 접속해야 하는데 로그인하지 않고 직접적으로 관리자만이 이용할 수 있는 웹 페이지에서 특정 작업을 수행할 수 있도록 만들기 때문이다. 예를 들면 www.stsc.co.kr/admin/login.asp를 통해 관리자로 로그인한 뒤 www.stsc.co.kr/admin/data.asp에 접근할 수 있어야 하는데, 관리자로 로그인하지 않고도 www. stsc.co.kr/admin/data.asp에 바로 접근하여 관리할 수 있는 경우를 말한다.
관리자 페이지나 인증이 필요한 페이지에 대해서는 관리자 로그인 세션에 대한 검사를 수행하는 과정을 넣어야만 이러한 공격의 피해를 막을 수 있다. 따지고 보면 웹 공격의 다수는 관리자의 부주의나 관리 패턴을 악용하는 단순한 방법이다. 이런 약점을 노출시키지 않으려면 관리자는 자신이 좀 더 불편하더라도 안전한 방법을 이용해 사이트나 파일을 관리해야 한다. 

SQL Injection 공격

SQL Injection 공격은 세상에 공개된 지 약 4년이 넘었지만 아직도 수많은 사이트가 이 공격에 취약한 묘한 해킹 방법이다. 이런 일이 가능한 것은 많은 개발자들이 이 부분을 간과한 채 웹 애플리케이션을 개발하고 있기 때문이다. 먼저 SQL Injection 공격의 패턴에 대해 알아본 뒤에 그 대응 방법을 함께 살펴보자

■ 기본 SQL Injection 공격 패턴
웹 애플리케이션에서 사용자에게서 SQL문을 입력받는 부분, 즉 데이터베이스와 연동되는 부분은 크게 로그인, 검색, 게시판으로 나눌 수 있다. 어느 사이트에서든 로그인을 하려면 아이디와 비밀번호를 넣어야 한다. 그리고 웹 애플리케이션 개발자는 정상적인 아이디와 비밀번호로 넣을 것을 기대하고 프로그래밍 한다. 그러나 모든 공격은 언제나 예상치 않은 곳에서 일어난다. 공격자는 아이디와 비밀번호를 정상적인 문자가 아닌 특정 SQL문을 넣어 공격한다. 이렇게 아이디나 비밀번호 부분에 엉뚱한 SQL문이 삽입되면 그것이 그대로 데이터베이스에 전송되어 공격자가 원하는 일이 일어난다.
SQL Injection 공격은 고난도 기술이 아니다. 물론 아주 어려운 SQL Injection 공격도 있지만 1분 만에 쉽게 배울 수 있는 SQL Injection 공격 방법도 있다. 그러면 SQL Injection 공격에 대응하기 위해서 무엇이 필요한지 살펴보자.
로그인 부분에 대한 SQL Injection 공격에 대한 이해를 돕기 위해서 로그인을 처리하는 간략한 웹 프로그래밍 코드를 살펴보자. 다음 코드는 로그인할 때 로그인 아이디와 비밀번호를 검사하여 사용자를 식별하는 ASP 코드의 한 부분이다.
일반 사용자가 웹에 접근하여 아이디와 비밀번호를 입력하면 위의 코드에 아이디와 비밀번호가 입력된다. 위의 코드는 사용자가 입력한 아이디를 strUser_id 변수에 저장하고 사용자가 입력한 비밀번호를 strPassword 변수에 넣는다. 그 뒤에 SELECT 문에서 사용자의 아이디와 비밀번호 입력에 대한 결과를 Query 변수에 저장한다. 그런 다음 GetQueryResult 함수를 이용해 Query 변수에 들어 있는 SQL문을 실행하고 그 결과를 strAuthCheck 변수에 넣는다. 쿼리 결과가 존재하지 않으면 strAuthCheck의 결과 값은 NULL이 되어 boolAuthenticated는 ‘거짓’이 되고 실행 결과 값이 있으면 boolAuthenticated는 ‘참’이 되어서 로그인 인증을 받을 수 있다.
이때 공격자가 아이디와 비밀번호에 ‘ or ‘’=’ 방식으로 입력하면 다음과 같은 결과가 나타난다.

<화면2> 자동화되어 있는 SQL Injection 공격 툴

<화면3> SQL Injection 공격 툴로 가입자 정보를 유츌한 화면

아이디: ‘ or ‘’=’
비밀번호: ‘ or ‘’=’

    ↓

SELECT user_id FROM member WHERE
user_id = ‘’ or ‘’ = ‘’ AND password = ‘’ or ‘’ = ‘’

이와 같은 쿼리문이 만들어지면서 조건문(Where문)은 항상 만족하고, strAuthCheck 값도 항상 ‘참’이 되기 때문에 공격자는 사용자 인증에 성공한다. 이처럼 위의 기법을 이용하면 아주 간단하게 로그인 창의 로그인을 우회하게 된다.
여기에서 설명한 SQL Injection 공격은 아주 기초적인 SQL Injection 공격 개념이라고 할 수 있는데 실제로 이와 같은 SQL Injection 공격을 자동화해놓은 툴들이 많이 있다. 이러한 툴을 이용하면 해당 공격 대상 서버의 시스템 명령까지 내릴 수 있으며 실제 데이터들의 조회와 수정도 가능하게 되어 심각한 문제를 야기할 수 있는 것이다.

■ SQL Injection 공격에 대한 대응 방법
SQL Injection에 대한 가장 훌륭한 해결책은 포괄적인 입력 검증을 수행하는 것이다. 모든 스크립트에 존재하는 모든 변수들을 점검하여 사용자의 입력 값이 SQL Injection을 발생하지 않도록 수정한다. 웹 애플리케이션 코드를 수정하여 사용자 입력이 SQL 문장으로 사용되지 않도록 한다. 모든 사용자 입력의 앞뒤에 따옴표를 붙이고, 사용자 입력에 존재하는 따옴표가 제거되도록 설정한다. 따옴표를 제거하는 것보다 더 확실한 방법은 사용자 입력에 따옴표가 존재하는 경우 이를 에러 처리하도록 하는 것이다. 만약 따옴표가 제거된 사용자 입력을 계속 처리하도록 허용한다면 이를 우회하는 공격에 언제나 노출되어 있는 셈이다.
따옴표에 대한 검증을 수행한 다음에는 사용자 입력으로 사용이 불가능한 스트링을 제거하고, 사용 가능한 문자집합에 포함되지 않은 모든 문자들을 제거하도록 설정한다. 이 경우에도 마찬가지로 허용되지 않은 문자열이나 허용되지 않은 문자가 포함된 경우를 에러로 처리하는 것이 더욱 안전하다.
현재 알려져 있는 공격 패턴을 기반으로 해서 사용자 입력으로 사용이 불가능한 스트링을 결정한다. 또한 새로운 공격 기술에 대비해서 사용자 입력으로 사용 가능한 최소의 문자집합을 결정한다. 사용이 허용된 문자들의 조합으로 공격 스트링을 만들 수 있기 때문에 이 두 가지 방법을 동시에 사용해야 한다. 최소 사용 가능 문자집합에는 가급적 숫자만을 포함하도록 하고 그것이 어렵다면 숫자와 문자만을 포함하도록 해야 한다. 만약 사용자 입력으로 기호문자나 구두문자 같은 문자들을 사용해야 한다면 꼭 필요한 최소의 문자만을 포함하고 허용된 문자를 HTML 문자로 변환해서 처리하도록 한다.
공격자는 리턴되는 에러 메시지에 대한 역공학 분석을 통하여 공격에 성공할 수 있는 SQL Injection 스트링을 알아낸다. 따라서 SQL 서버의 에러 메시지를 외부에 제공하지 않도록 한다. 보통 개발 과정에서 디버깅을 목적으로 에러가 리턴되도록 허용했다가 개발이 끝난 후 그 기능을 제거하는 것을 잊는 경우가 많다. 에러가 발생한 경우 에러 발생 사실을 보여주기보다 메인 페이지로 돌아가도록 하는 것이 좋다. 500 Internal Server Error Page 자체가 그 서버에 대해 SQL Injection 공격이 가능하다는 의미를 제공하는 것이다.
웹 애플리케이션이 사용하는 데이터베이스 유저의 권한을 제한시킨다. 가능하면 일반 유저 권한으로는 모든 system stored procedures에 접근하지 못하도록 한다. 이렇게 하며 웹 애플리케이션의 SQL Injection 취약점을 이용하여 데이터베이스 전체에 대한 제어권을 얻거나 데이터베이스를 운용 중인 서버에 대한 접근이 불가능하도록 한다. 이외에도 데이터베이스에 대한 보안 지침 문서를 참조하여 데이터베이스 서버의 보안 수준을 제고하도록 한다.

SQL Injection 공격 대응 방법

◆ 사용자 입력이 SQL Injection을 발생시키지 않도록 사용자 입력을 필터링한다.
◆ SQL 서버의 에러 메시지를 사용자에게 보여주지 않도록 설정한다.
◆ 웹 애플리케이션이 사용하는 데이터베이스 유저의 권한을 제한시킨다.
◆ 데이터베이스 서버에 대한 보안 설정을 수행한다.


크로스 사이트 스크립팅(XSS) 공격

버퍼 오버플로우는 공격기법의 이름에서도 어느 정도 유추할 수 있듯이 지정된 범위의 버퍼이상의 데이터를 기록할 때 발생된다. 현재 발생하고 있는 취약점 중에 많은 것들이 이 버퍼 오버플로우에 의해 일어나고 있다. 이것은 개발 시 지정된 범위 이상의 값으로 받아들이지 않도록 코딩을 하거나 안전한 함수 등을 사용하여 막을 수 있는 부분임에도 불구하고 여전히 그 피해가 끊이지 않는 대표적인 취약점 중 하나이다. 구글과 같은 검색엔진에서 ‘buffer overflow’로 검색해 보면 상당히 많은 자료를 찾아 볼 수 있다.
간단한 입력을 받는 다음의 코드를 살펴보자. array[30]으로 버퍼의 크기를 지정하였고 받은 내용을 출력하도록 프로그래밍되어 있다. 그런데 만약 사용자가 버퍼 크기 이상의 데이터를 입력하였다면 어떻게 될까? <화면 1>과 같은 화면이 나타날 것이다. * A는 16진수로 41이다.

기본적인 공격 기법 분석

공격자는 XSS 취약점이 존재하는 웹 사이트에 자신이 만든 악의적인 스크립트를 일반 사용자의 컴퓨터에 전달하여 실행시킬 수 있다. 이러한 공격으로 사용자 쿠키를 훔쳐서 해당 사용자 권한으로 로그인하거나 브라우저를 제어하는 것이다.
XSS 취약점은 다음과 같이 동적으로 웹 페이지를 생성하는 사이트에 주로 존재한다.

● 입력한 검색어를 다시 보여주는 검색엔진
● 입력한 스트링을 함께 보여주는 에러 페이지
● 입력한 값을 사용자에게 다시 돌려주는 Form
● 사용자에게 메시지 포스팅이 허용된 웹보드

XSS 취약점이 존재하는 사이트의 특징은 사용자의 입력을 검증하지 않고 그대로 동적으로 생성되는 웹 페이지에 포함해서 다시 보여준다는 점이다. XSS 공격은 <그림 3>과 같이 이루어진다. 공격자는 XSS 취약점이 존재하는 웹 페이지의 사용자 입력으로 ‘test’와 같이 정상적인 스트링을 입력하는 것이 아니라 <script>로 시작하는 악성 스크립트 코드를 입력한다. 그러면 웹 서버는 공격자가 입력한 악성 스크립트 코드가 포함된 웹 페이지를 생성해서 클라이언트에게 되돌려준다. 이 웹 페이지에 포함된 스크립트 코드는 클라이언트 측 브라우저에서 실행된다.
공격자는 웹 메일이나 게시판 등을 이용하여 리턴되는 웹 페이지를 공격 목표가 되는 일반 사용자에게 전달한다. 공격자는 웹 메일에 악성 스크립트 코드를 포함하여 전달하거나 게시판에 악성 스크립트 코드가 포함된 웹 페이지를 생성해서 클라이언트에게 되돌려준다. 이 웹 페이지에 포함된 스크립트 코드는 클라이언트 측 브라우저에서 실행된다.
공격자는 웹 메일이나 게시판 등을 이용하여 리턴되는 웹 페이지를 공격 목표가 되는 일반 사용자에게 전달한다. 공격자는 웹 메일에 악성 스크립트 코드를 포함하여 전달하거나 게시판에 악성 스크립트 코드가 포함된 글을 포스팅한 뒤에 그 글을 읽도록 한다. 일반 사용자가 공격자로부터 수신한 웹 메일을 여는 순간 혹은 공격자가 포스팅한 게시물을 읽는 순간이나 해당 웹 페이지에 읽는 순간 해당 웹 페이지에 포함된 스크립트 코드가 실행된다.
이러한 방법 외에도 악성 스크립트를 URL에 포함시켜서 전달하는 방법도 있다. 공격자는 URL의 변수 값으로 악성 스크립트를 넣은 링크를 공격 대상자에게 전달하여 그 링크를 클릭하도록 유도한다. 공격자는 이 링크를 공격 대상자에게 친숙한 내용의 HTML 메일에 포함시켜 전달하는데 메일은 공격 대상자가 반드시 그 링크를 클릭하도록 내용을 구성한다. 공격 대상자가 그 링크를 클릭함과 동시에 악성 스크립트가 포함된 웹 페이지를 수신하게 된다.

XSS 공격에 대한 대응 방법

XSS 취약점은 대부분 웹 애플리케이션 개발자가 사용자 입력을 받아들이는 부분에서 사용자 입력에 대해 어떠한 검증도 하지 않았기 때문에 일어난다. 그럼 웹 애플리케이션 개발자나 사이트 관리자는 어떤 방식으로 XSS 취약점에 대응해야 할까?

- 사용자를 식별하기 위해서 쿠키에 비밀번호와 같은 민감한 정보는 담지 않아야 한다.

- 스크립트 코드에 사용되는 특수문자에 대해 이해하고 정확한 필터링을 해야 한다. 가장 효과적인 방법은 사용자가 입력 가능한 문자(예를 들면 알파벳, 숫자, 몇몇의 특수문자)만을 정해놓고 그 문자열이 아니면 모두 필터링한다. 이 방법은 추가적인 XSS 취약점에 사용되는 특수문자를 사전에 예방할 수 있다는 장점이 있다.
<표 1> 같은 특수문자 필터링을 적용하기 위해서는 다음과 같은 함수를 이용할 수 있다.

정당화

의미

<
태그의 시작
>
태그의 끝
&
캐릭터 개체 또는 매개변수의 구별자
"
속성 값
'
속성 값
space

tab
속성 값, URL의 끝

URL의 끝
new line
URL의 끝
Non-ASCII
Iso-8859-1일 때, 2바이트 코드
%
HTTP escape sequence
" 안의!
Server Side Script
<script></script> 안의, (), {}, New Line
 

Function RemoveBad(InStr) {
InStr = InStr.replace(/\</g,“”);
InStr = InStr.replace(/\>/g,“”);
InStr = InStr.replace(/\”/g,“”);
InStr = InStr.replace(/\’/g,“”);
InStr = InStr.replace(/\%/g,“”);
InStr = InStr.replace(/\/g,“”);
InStr = InStr.replace(/\(/g,“”);
InStr = InStr.replace(/\)/g,“”);
InStr = InStr.replace(/\&/g,“”);
InStr = InStr.replace(/\+/g,“”);
Return InStr;
}

- 게시판에서 HTML 포맷의 입력은 사용할 수 없도록 설정한다. 최근에 만들어진 게시판들은 대부분 사용자들에게 다양한 효과를 제공하기 위해 HTML Tag 기능을 제공하고 있지만 꼭 필요한 경우가 아니라면 HTML을 사용할 수 없도록 제한해야 한다.

- 스크립트를 대체하여 무효화한다. javascript라고 들어오는 문자열은 무조건 x-javascript와 같이 대체하여 스크립트 실행을 무효화시키는 방법도 있다.


지금까지 살펴본 바와 같이 웹 해킹의 대부분은 웹 설정의 문제나 기본적으로 웹 환경에서 작동하는 웹 애플리케이션 제작 시 보안적인 요소를 고려하지 않고 단순히 목표로 하는 결과만 나올 수 있는 결과 중심의 프로그램 제작이 가져온 결과라고 할 수 있겠다. 더욱이 요즘처럼 웹이라는 환경에서 다루고 있는 각종 정보들이 직·간접적으로 악용되어 2차, 3차까지 이어지는 추가 해킹 사건까지 일어나고 있는 실정인데 웹 개발자들은 이제 단순히 결과만 보여주기 위한 프로그래밍보다는 그 내용 및 프로그램의 퀄리티까지 확보할 수 있는 단계가 될 수 있도록 주의해야 한다.
여기에서 다룬 해킹은 웹 사이트가 크고 웹 애플리케이션이 많을수록 더욱 쉽게 노출된다. 모든 애플리케이션에 여기에서 설명한 내용들을 적용하거나 코드를 수정하는 것이 너무 번거롭고 어렵다면 시중에 나와 있는 웹 애플리케이션 방화벽을 도입하는 것도 좋은 방안이 될 수 있을 것이다. 하지만 자신의 환경에 얼마나 잘 맞는지, 그리고 단순히 불필요한 기능들 때문에 전체 웹 시스템에 영향을 주는 솔루션을 도입을 하는 것은 벼룩 잡기 위해서 초가삼간을 모두 태운 격이 되므로 주의해야 한다.
가장 좋은 보안은 처음 애플리케이션을 개발하는 단계에서 보안에 신경을 쓰는 것이다. 약간만 신경 써서 개발한다면 수많은 개발자가 ‘각종 웹 해킹 보안 위협’에 골머리 썩으며 밤을 새는 일은 없을 것이다.
 
출처 : http://j79sw.tistory.com


Trackback 0 Comment 0
2009.02.03 19:38

DDoS에 대응하는 원론적인 방법

이 문서는 SANS ISC의 How to handle DDoS Incidents?를 번역한 글입니다.

아래 파일로 첨부된 요점 정리 문서는 대다수의 침해 사고에 적용할 수 있습니다. 그러나 몇가지 침해 사고, 특히 DDoS 같은 종류는 별도의 대처 방안이 필요합니다.

원본은 zeltser.com 의 Security Incident Survey Cheat Sheet for Server Administrators 입니다.

원본은 zeltser.com 의 Initial Security Incident Questionnaire for Responders 입니다.


준비

실제 공격을 당하기 이전에 이 단계의 일을 미리 준비해놔야 합니다. 이 단계를 미리 끝내지 않는다면, 공격이 발생했을 때 초기에 대응하지 못 하고 몇 시간을 허비하게 됩니다.

  • ISP에 연락해서 DDoS 공격을 막는 ISP의 지원 서비스가 무료인지, 아니면 돈을 내야 하는지 확인하세요.
  • 서버 접근 권한을 가진 IP의 화이트 리스트를 작성하세요. 공격으로 인해 네트워크 접속을 제한해야 할 때 이 목록을 사용합니다. (고객, 파트너 회사등)
  • 공격당할 가능성이 있는 시스템에 관련된 DNS의 TTL 설정을 확인하세요. TTL을 낮춰 놓으면 시스템이 공격 당할 때 손쉽게 DNS 설정을 바꿀 수 있습니다.
  • ISP, IDS, 방화벽, DNS, 서드파티 보안팀 등 관련된 담당자들의 연락처를 확보하세요. 네트워크 설정(IP 주소, circuit ID등), 장비 목록, 네트워크 구성도를 정리하세요.
  • 회사의 위기 관리팀에 연락해서 DDoS 사고가 미치는 영향에 대해 어떻게 생각하고 있는지 알아두세요.

분석

공격을 탐지하고 사고의 범위를 파악하세요. 어떤 인프라가 영향을 받는지, 공격의 흐름은 어떻게 되는지 확인하세요. 이를 통해 공격을 전반적으로 이해할 수 있습니다.

  • 서버, 라우터, 방화벽 등 영향을 받은 장비들의 부하 상태를 살펴보세요.
  • 가능하다면 tcpdump, ntop과 같은 네트워크 스니퍼를 이용해 영향을 받은 장비들의 트래픽 흐름을 살펴보세요.
  • ISP와 사내의 팀들에게 연락해서 공격자의 출현을 알리고 도움을 요청하세요.
  • 공격 이전에 DDoS 공격자에게 금품 요구를 받은 적이 있는지 확인하세요.
  • NIDS 탐지 패턴을 만들어 정상적인 트래픽과 공격 트래픽을 구분하세요.
  • 회사의 이사와 법률팀을 참여시키고, 법적 대응을 검토하세요.
  • 정상 트래픽과 공격 트래픽의 차이점을 식별하세요. (출발지 IP, 목적지 포트, URI, TCP 플래그 등)

대응

DDoS 공격은 많은 양의 비정상적인 트래픽을 서버로 보내는 것입니다. 아래 항목들은 DDoS 공격의 영향을 줄일 수 있는 방법입니다. 그러나 몇몇 경우에는 ISP의 도움 혹은 특별한 장비의 도움 없이 공격을 막기 어려울 것입니다.

  • 라우터, 방화벽, 로드밸런서, 웹서버 등의 설정을 이용해 공격 트래픽을 차단하세요.
  • 가능하다면 DNS나 다른 방법을 이용해 네트워크, 컴퓨터 자원이 여유가 있는 곳으로 트래픽을 옮기세요. 그리고 원래 IP는 널 라우팅 처리해서 트래픽을 제거하세요.
  • 서버가 병목 지점이면 시스템의 TCP/IP 설정을 바꿔서 더 효율적으로 동작하도록 하세요.
  • 응용 프로그램의 특정 기능이 병목이라면 그 기능을 임시로 막으세요. 가능하다면, 서버와 네트워크 대역폭을 추가하세요. (물론 이건 끝없는 무장 경쟁일 뿐이죠.)
  • DNS와 라우팅 테이블을 이용해서 트래픽을 트래픽 검사 장비로 보내세요.

기타

  • 사고가 발생하면 너무 많은 사람들이 달려드는 경향이 있습니다. 사람이 많아지면 데이터 수집만 더 힘들게 될 뿐입니다.
  • 작업은 한번에 하나씩 진행해야 합니다. 두가지를 동시에 변경하면 어떻게 문제를 해결했는지 알기 힘듭니다.
  • 공격이 오랫동안 진행되는 경우에는 다음날 어떻게 대응을 이어갈지 고민해보세요.
  • 자료는 그리 많이 필요하지 않습니다. 사고 분석에는 로그가 최고입니다.

Trackback 0 Comment 0