블로그 이미지
불쥐의 눈으로 본세상 ㏈ª ☞ β┖υΕJini.κR

카테고리

분류 전체보기 (234)
By β┖υΕJini (131)
㏈ª By β┖υΕJini (103)
Total281,375
Today1
Yesterday46

'㏈ª By β┖υΕJini/서버보안'에 해당되는 글 6건

  1. 2008.11.19 NAS 가 도대체 뭐야?
  2. 2008.11.12 RAID 가 도대체 뭘까?
  3. 2008.09.19 SAN 이 도대체 뭘까?
  4. 2007.10.17 DDoS 공격 방어 방법 없을걸까?
  5. 2007.10.17 SQL 인젝션 이란..?
  6. 2007.10.17 WebKnight 를 이용한 SQL Injection 공격 차단

사용자 삽입 이미지
NAS (Network Attached Storage)란?


이기종간의 파일 공유가 가능한 전용 File서버 
전용 File 서버와 스토리지 또는 일체형 NAS
LAN, WAN 등의 데이터 네크웍을 이용헌 접속
고성능, 고가용성을 위한 전용 OS 및 하드웨어


고성능 파일 서비스
NAS 시스템은 NFS(Network File System)나 CIFS(Common Internet File System)
기반의 클라이언트에게 파일을 서비스 할 수 있다
소형 파일에 있어서는 클라이언트에 직접 연결한 파일과 성능차이가 거의 없는데 이것은 NAS 에 설치된
전용 프로세서와 RAID 기능 덕분이댜
 
파일공유
이기능은 다수의 이기종 클라이언트가 동일한 파일에 접근해 파일을 공유하도록 지원한다
NAS 제품은 보안허가(Permission) 기능을 통해 다수의 클라이언트가 동일 파일에 접근 하는것을
관리한다
 
파일캐싱
캐싱기능은 웹서버나 애플리케이션 서버와 같이 다수의 클라이언트가 대량의 HTTP 접속을 시도하는
경우 효과적으로 활용될 수 있다
일부 로드가 큰 애플리케이션을 NAS 에 설치했을 경우에도 캐싱 기능은 CPU 나 메모리를 사용하지
않고도 고성능의 서비스를 가능하게 한다 

Posted by ㏈ª ☞ β┖υΕJini.κR
TAG NAS

사용자 삽입 이미지



왜 난 맨날 레이드들이 헷깔릴까... 첨에 읽을때는 이해가 되는데 설명 할려면 맨날 헷깔리는 나...

머리가 너무 나쁜것 같다.

많은 서버들이 레이드로 구성하여 사용 되고 있다.

이번 에는 RAID 대해서 정리해 보도록 하자.



RAID란?

 RAID는 Redundant Array of Inexpensive (or Independant) Disks의 약어이다
 RAID 시스템은 여러 드라이브의 집합을 하나의 저장장치처럼 다룰 수 있게 하고, 장애가 발생했을 때
 데이터를 잃어버리지 않게 하며 각각에 대해 독립적으로 동작할 수 있도록 한다
 1988년 버클리의 David Patterson, Garth Gibson, Randy Katz가 SIGMOD에서
 "A Case for Redundant Arrays of Inexpensive Disks (RAID)"라는 논문을 발표했다
 이 논문은 데이터와 패리티 정보를 디스크에 배치하는 방법에 따라 디스크 어레이를 분류하고 있는
 데, 이것이 이후 RAID level이라고 불리게 된다 절대적이지도 않고 가능한 모든 아키텍처를
 수용하고 있는 것도 아니다
 기본적인 RAID의 개념은 작고 값싼 드라이브들을 연결해서 크고 비싼 드라이브 하나
 (SLED: Single Large Expansive Disk)를 대체하자는 것이다
 
 기본정의
  장애 발생요인을 최대로 제거한 고성능의 무정지 대용량 저장장치
  여러 개의 HDD를 하나의 Virtual Disk로 구성하므로 대용량 저장 창치 구축가능 
  다수의 HDD에 Data를 분할하여 병렬 전송함으로써 전송 속도 향상 
  시스템 가동 중 Disk Module 고장 시에도 시스템 정지 없이 새 Disk 로 교체하면서
  원래의 Data 를 자동복구
  기원
  1986년 미국UCBerkely 컴퓨터 공학과
  발표지 : “ A Case for RAID ” 
  연구자
  David a Patterson
  Garth Gibson
  Randyh Kats 공동발표 

목적및 이론의 근거
소량이면서 저가인 PC Type의 Disk Error 에 대한 연구  
중복 구성된 Disk Group에 Data를 Byte, Block, Segment 단위로 나누어 병렬로 동시에 기록  
Disk의 일부용량에 Data가 아닌 Parity정보를 처리하고 기록  
Fail Disk 교체 시 RAID내에서 Parity정보를 이용하여 Data복구기능을 수행  
Data Disk가 파손되어도 Host에 서는 RAID내의 Parity 정보를 이용하여 Read/Write 작업을
지속적으로 수행 

RAID의 장점

 고 가용성 / 데이터 보호 
 시스템에 있는 디스크의 수가 증가함에 따라 그중 한 디스크가 장애를 일으킬 가능성도 함께
 함께 증가한다 그러므로 디스크 어레이는 어느 한 디스크의 장애에 면역성을 가져야 한다 
 미러링은 간결하지만 실 저장용량의 두배에 해당하는 디스크를 필요로 한다
 인코딩 기법은 요구되는 여분의 디스크 용량을 감소시키기 위해 사용된다 
  드라이브 접속성의 증대
 운영체제에게 여러개의 물리적 드라이브가 하나의 논리적 드라이브로 보임으로서 논리적 
 드라이브 수의 제한을 피할 수 있다 
  저렴한 비용과 작은 체적으로 대용량 구현
 여러개의 소용량 드라이브로 대용량 드라이브를 대체할 수 있다 
  지능형 콘트롤러에 의한 유연성 
  특정 상황에서의 효율성 증가 
 효율성은 하나의 디스크 입출력 요구에 대하여 여러 디스크에 데이터를 분산시키고 병렬적으로
 입출력을 처리함으로서 증가될 수 있다 
  데이터 분산에 의한 효율성의 재고
 디스크 어레이 (RAID) 의 목적은 데이터 가용성과 총 저장 용량을 증가시키며 여러 물리적
 디스크에 데이터를 적절히 분산시킴으로서 효율성을 재고시키는 것이다 

RAID 의 LEVEL

현재 가장 많이 사용 되는 RAID 는 0+1 , 0 , 1 ,5 에 대해서 알아 보았으면 한다.

RAID 0

RAID level 0은 장애 발생에 대비한 여분의 저장공간을 갖지 않는다. 그러므로 엄밀히 이야기하자면 RAID의 정의에 부합된다고 볼 수 없다. Level 0에서 데이터는 빠른 입출력이 가능하도록 여러 드라이브에 분산된다.
여분의 정보를 기록하지 않기 때문에 성능은 매우 뛰어나지만, 어느 한 드라이브에서 장애가 발생하게 되면 데이터는 손실된다. 이 레벨은 striping이라고 부른다.

RAID 1

RAID level 1은 한 드라이브에 기록되는 모든 데이터를 다른 드라이브에 복사해 놓는 방법으로 복구능력을 제공한다. Level 1 array는 하나의 드라이브를 사용하는 것에 비해 약간 나은 정도의 성능을 제공한다. (읽을때 더 빠르며, 쓸때는 약간 느리다. 하지만 ECC를 계산하지 않기 때문에 RAID4나 5보다는 빠르다.)
이 경우 어느 드라이브가 고장나더라도 데이터의 손상은 일어나지 않는다.
이것은 단 두대의 드라이브만으로 시작할 수 있기 때문에 RAID 시스템을 처음 구축하는 사람에게 입문용으로 적합하다. 하지만 전체 용량의 절반이 여분의 데이터를 기록하기 위해 사용되기 때문에 저장용량당 단가가 비싸다. 이 레벨은 mirroring이라고 부른다.

RAID 5

RAID level 5는 패리티 정보를 모든 드라이브에 나누어 기록한다. 패리티를 담당하는 디스크가 병목현상을 일으키지 않기 때문에, level 5는 멀티프로세스 시스템에서와 같이 작고 잦은 데이터 기록이 있을 경우 더 빠르다. 하지만 읽어들이기만 할 경우 각 드라이브에서 패리티 정보를 건너뛰어야 하기 때문에 level 4 array보다 상당히 느리다. 용량당 비용은 level 4와 같다.

RAID 1+0



..High Data Transfer Performance

Posted by ㏈ª ☞ β┖υΕJini.κR

사용자 삽입 이미지

사회생활 시작 할때 네트워크 관련팀에서  서버실에서 잠깐 일한적이

있었다.손놓은지 오래지만 나에게  시스템 엔지니어쪽 분야도 경험했다는 이유로

일을 시킨다.하지만 그때와 지금은 많은 발전이 있는거 같다.. 하드웨어의 성능은

계속 좋아 지고 새로운 장비는 계속 나오고... 시스템 엔지니어라면 꼭 알아야 하는

SAN 대해 알아 보도록 하자.

SAN(Storage Area Network)이란?

SAN(Storage Area Networks)은 서버와 스토리지 간에 대용량 데이터를 고속으로
전송할 수 있는 네트워크입니다. 즉, 호스트 컴퓨터에서 SCSI를 통한 스토리지
서버와 신속하게 데이터를주고 받을 수 있는 것처럼 네트워크상에서 Fibre
Channel(FC)의 이점인 고속전송과 장거리 연결 및 멀티 프로토콜 기능을
활용하는 기술입니다. 다시 말해서 SAN이라함은 네트워크 환경에서 각각의
 서버나 호스트들에게 사용되는 대량의 Data를 집중시켜 보관하고 이를 구성
 하는 장비들을 이용, 공유하여 사용할 수 있도록 하는 기술을 의미합니다.
최근 Data Warehousing , VOD 등 대용량의 Data를 고속으로 전송해야 하는
업무의 증가와 함께 이를 위한 최선의 해결책으로 크게 대두되고 있습니다.

하지만 SAN 을 구축하기 위해서는 NAS 스토리지에 비해서 많은 비용과 장비들의
투자가 필요하고, 기존 시스템들의 업그레이드가 필수적이므로 몇가지 제약이
있습니다.

SAN 을 이기종간의 여러 서버에서 하나의 스토리지를 공유하기 위해서는 SAN
메니지먼트 소프트웨어가 별도로 필요로 하고 , NAS 와는 달리 SAN 네트워크를
별도로 구축을 해야 한다는 단점이 있습니다.

       SERVER FREE 백업이란
    LAN FREE 백업이란?

Posted by ㏈ª ☞ β┖υΕJini.κR
TAG San

2007년 나를 못살게 만들었던 DDOS 공격 생각만 해도... 고개가 절로...

 1.  서비스 거부 (DoS : Denial of Service) 공격

       서비스 거부 공격 (Denial of Service attack)이란 시스템의 정상적인 서비스를 방해하여

       정당한 사용자가 서비스를 제공 받지 못하도록 하는 공격을 말한다. (1:1 공격)

       이 공격은 목표 시스템의 서비스, 하드웨어, 소프트웨어 기능을 저하시켜

       서비스를 원할하게 제공해 주지 못하게 된다.


      [특징]

       (1)  아주 단순하지만 공격자의 추적이 비교적 쉽다.

       (2)  이 공격에 완벽하게 대처할 수 있는 방법이 없다.

       (3)  공격은 즉시 효력을 발휘한다.



      

사용자 삽입 이미지

[그림 21-1] 서비스 거부(DoS) 공격




 2.  분산 서비스 거부 (DDoS : Distribute Denial of Service) 공격

       기존의 DoS 공격과 같이 공격자 한 사람에 의해 공격이 이루어지는 것이 아니라

       지역적으로 널리 분산된 다수 또는 집단으로 형성된 공격자들에 의해

       목표 시스템이 집중적으로 공격하는 형태를 의미한다. (N:1 공격)


      [특징]

       (1)  공격의 원인과 공격자를 추적하기 어려운 특성을 가지고 있다.

       (2)  공격 시 이를 감지하게 되어도 뚜렷한 해결 방안을 만들어 대처하기가 어렵다.

       (3)  매우 다양한 형태의 공격을 취할 수 있다.

       (4)  시스템마다 DoS와 DDoS 공격에 대해 반응이 다르게 나타날 수 있다.



      

사용자 삽입 이미지

[그림 21-2] 분산 서비스 거부(DDoS) 공격  




 3.  분산 반사 서비스 거부 (DRDoS : Distributed Reflection DoS) 공격

       별도의 에이전트를 설치할 필요없이 네트워크 통신 프로토콜 구조의 취약성을 이용해

       정상적인 서비스를 운영하고 있는 시스템을 DDoS 공격의 에이전트로 이용한다.

사용자 삽입 이미지

      [특징]

       (1)  기존 DDoS 공격에 비해 해커들이 사용하기 쉽고,

             공격을 당한 사이트의 복구가 어렵다.

       (2)  피해의 정도와 성공 확률, 피해 결과 측면에서 DDoS 공격과 거의 유사하다.



      

[그림 21-3] 분산 반사 서비스 거부( DRDoS) 공격  

Posted by ㏈ª ☞ β┖υΕJini.κR

1.   SQL Injection 해킹방법 취약점 공격 방식 의 종류 알려주세요~


- sql은 db 쿼리값을 조작하여 db에 잘못된 값을 주입하고 관리자나 등등의 계정으로 접근하여 db 조작등을 하는 해킹입니다.


대표적인 코드는


'or 1=1--

'or 1=1# 등이 있습니다


취약점은 웹 사이트마다 다르기 때문에 말씀드리기가 힘드네요.

 

2.  SQL Injection 해킹 대응책 ?


-

■ 보호 대책


(1) 일반 대책

-데이터베이스와 연동을 하는 스크립트의 모든 파라미터들을 점검하여 사용자의 입력 값이 SQL injection을 발생시키지 않도록 수정한다.


-사용자 입력이 SQL injection을 발생시키지 않도록 사용자 입력 시 특수문자(' " / \ ; : Space -- +등)가 포함되어 있는지 검사하여 허용되지 않은 문자열이나 문자가 포함된 경우에는 에러로 처리한다.


-SQL 서버의 에러 메시지를 사용자에게 보여주지 않도록 설정한다. 공격자는 리턴 되는 에러 메시지에 대한 분석을 통하여 공격에 성공할 수 있는 SQL Injection 스트링을 알아낼 수 있다. 따라서 SQL 서버의 에러 메시지를 외부에 제공하지 않도록 한다.


- 웹 애플리케이션이 사용하는 데이터베이스 사용자의 권한을 제한한다. 가능하면 일반 사용자 권한으로는 모든 system stored procedures에 접근하지 못하도록 하여 웹 애플리케이션의 SQL Injection 취약점을 이용하여 데이터베이스 전체에 대한 제어권을 얻거나 데이터베이스를 운용중인 서버에 대한 접근이 불가능하도록 한다.


-php.ini 설정 변경

  : php.ini 설정 중 magic_quotes_gpc 값을 On으로 설정한다.


; Magic quotes

;

; Magic quotes for incoming GET/POST/Cookie data.

magic_quotes_gpc = On  ; Off에서 On으로 변경한다.

; Magic quotes for runtime-generated data, e.g. data from SQL, from exec(), etc.

magic_quotes_runtime = Off

; Use Sybase-style magic quotes (escape ' with '' instead of \').

magic_quotes_sybase = Off


■ 개발 언어별 대책

-사용자로부터 입력받은 변수로 SQL 쿼리 구문을 생성하는 CGI는 입력받은 변수를 체크하거나 변경하는 로직을 포함하고 있어야 한다.


-입력받은 변수와 데이터 베이스 필드의 데이터형을 일치 시켜야 하고, 사용 중인 SQL 구문을 변경시킬 수 있는 특수문자가 포함되어 있는지 체크해야 한다.


-검색 부분과 같이 클라이언트로부터 생성된 SQL 구문을 받는 부분이 있다면 이를 제거해야 한다.


□ ASP

-취약한 SQL Injection 예제

prodId = Request.QueryString("productId")

Set conn = server.createObject("ADODB.Connection")

Set rs = server.createObject("ADODB.Recordset")

query = "select prodName from products where id = " & prodId

conn.Open "Provider=SQLOLEDB; Data Source=(local);

Initial Catalog=productDB; User Id=dbid; Password="

rs.activeConnection = conn

rs.open query

If not rs.eof Then

response.write "제품명" & rs.fields("prodName").value

Else

response.write "제품이 없습니다"

End If


-안전한 SQL Injection 예제

prodId = Request.QueryString("productId")

prodId = replace(prodId, "'", "''")' 특수문자 제거

prodId = replace(prodId, ";", "")

set conn = server.createObject("ADODB.Connection")

set rs = server.createObject("ADODB.Recordset")

query = "select prodName from products where id = " & prodId

conn.Open "Provider=SQLOLEDB; Data Source=(local);

Initial Catalog=productDB; User Id=dbid; Password="

rs.activeConnection = conn

rs.open query

If not rs.eof Then

response.write "제품명" & rs.fields("prodName").value

Else

response.write "제품이 없습니다"

End If


□ PHP

-addslashes() 함수 사용

  : 사용자가 입력하는 값들($_GET, $_POST)을 모두 addslashes() 함수를 이용하여 처리하여 준다.

addslashes()

용도 : DB Query와 같이 인용된 부분앞에 역슬래쉬를 붙여서 반환한다. 해당 문자에는 작은 따옴표, 큰 따옴표, 역슬래쉬, NULL이 있다. SQL Injection 공격을 위해서 사용한다.

- 적용 가능한 PHP : PHP 3 이상


-취약한 SQL Injection 예제

$query = "SELECT id, password, username FROM user_table WHERE id='$id'";// 사용자로부터 입력받은 id 값을 사용자 table에서 조회

$result = OCIParse($conn, $query);

if (!OCIExecute($result))

echo "<META http-equiv=\"refresh\" content=\"0;URL=http://victim.com\">";// 메인 페이지로 redirect

OCIFetchInto($result, &$rows);

... 중략 ...


-안전한 SQL Injection 예제

$query = sprintf("SELECT id,password,username FROM user_table WHERE id='%s';",addslashes($id));

// id변수를 문자형으로 받고, id변수의 특수문자를 일반문자로 변환한다.

// @ 로 php 에러 메시지를 막는다.


Posted by ㏈ª ☞ β┖υΕJini.κR

2006년 여름 회사 해외 웹사이트 외주 작업으로 해외에 서버를 구축 하였다.
몇개월간 웹서버게 별다른 자료가 없는데도 계속적인 해킹에 시달려고 했다.
그때 찾아낸 웹방화벽 솔루션을 이용하여 100% 차단은 못했지만 어느정도의 성과를 얻게 되
었다.  어떤 인젝션 파라메터로 해킹이 들어 오는지 어떤 곳에서 해킹이 들어 오는지 로그를
통해 많은 정보와 효과를 볼수 있었다.



1. 개요


단순 홈페이지 해킹이 아닌 홈페이지 방문자들의 정보를 빼내 금전적인 이득을 취하고자 하는 홈페이지 해킹이 심각한 수준에 달하고 있다. 이는 해킹당한 업체가 피해기관이 되기도 하지만 해당 웹사이트를 신뢰하고 방문하는 수많은 네티즌들을 감염시키는 공격사이트이기도 하여 조치가 시급하다.


최근 윈도우즈 웹서버를 대상으로 발생되고 있는 해킹은 대부분 SQL Injection 공격이 그 원인이다. SQL Injection 취약점은 게시판, 공지사항 등에서 URL 인자에 대한 입력값을 검증하지 않음으로 해서 공격이 발생되는 웹 개발과정에서의 오류라고 할 수 있다.


대형 포털, 뉴스 사이트 등 수많은 국내 사이트들이 공격을 당해 웹 방문자들을 감염시키고 있지만, 이러한 악성코드 유포지로 이용되고 있는 사이트들은 취약점이 있음을 알고 있지만 제대로 조치를 하지 못해 수차례 다시 해킹을 당하는 경우를 많이 볼 수 있다.


인터넷침해사고대응지원센터의 분석에 의하면 국내 악성코드 경유지 또는 유포지 사이트 중 약 30% 가량이 2회 이상 재차 해킹을 당하고 있는 것으로 나타났다. 이는 SQL Injection 취약점 자체가 웹 프로그램의 소스 코드를 수정해야만 근본적으로 해결될 수 있는 문제이지만 운영 중인 웹 서버의 프로그램 수정이 쉽지 않기 때문이다.


웹 시스템 구축 이후 문제점을 수정하기 보다는 설계․개발 단계에서 보안을 고려하여 개발되는 것이 바람직하다. 인터넷침해사고대응지원센터에서는 홈페이지 개발시 고려하여야 하는 보안 사항과 웹언어별 사례를 제공하고 있으므로 이를 참고하여 개발하기 바란다.

o 홈페이지 개발 보안 가이드 다운로드 :
http://www.kisa.or.kr/news/2005/announce_20050427_submit.html


향후, 인터넷침해사고대응지원센터에서는 SQL Injection 공격, 업로드/다운로드 공격, XSS 공격등 대표적인 웹공격에 대비할 수 있는 표준 웹애플리케이션 보안 템플릿도 제공할 계획이다.

하지만, 이미 구축되어 있는 웹사이트들은 대부분 보안을 고려하여 개발되지 않았으며, 이를 단기간에 수정하는 것도 쉽지는 않아 많은 국내 웹사이트들이 재차 해킹을 당하고 있다. 따라서, 근본적인 대책인 웹 소스 수정이 어려울 경우, Secure하지 못한 웹서버를 보완할 수 있는 추가적인 방안이 필요하다. MS사에서는 IIS 웹서버의 보안성을 강화시켜 주기 위해 IISLockdown, URLScan 등과 같이 도구를 제공해 주고 있다.

IISLockdown은 웹 서버를 보호하기 위한 과정을 대부분 자동화할 수 있는 도구로 서버의 용도에 따라 유형별로 다양한 보안기능을 해제하거나 보호할 수 있는 사용자 템플릿을 제공해 준다.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/secmod/html/secmod113.asp


URLScan은 웹 사이트 관리자가 서버에서 처리 가능한 웹 요청을 제한할 수 있는ISAPI(Internet Server Application Program Interface) 필터로써 특정 웹 요청을 제한하여 잠재적으로 유해한 웹 요청이 서버에 도달하기 이전에 차단함으로써 공격을 예방한다.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/secmod/html/secmod114.asp


http://www.microsoft.com/technet/security/tools/urlscan.mspx


하지만, 아쉽게도 IISLockdown이나 URLScan도 DB Query 문장을 필터링하지는 못하여 최근 발생되고 있는 SQL Injection 공격을 차단할 수는 없다.

최근 웹 공격이 심각한 수준에 이르러 국내․외 상용 웹방화벽들도 많이 출시되었다. 다양하고 정교한 웹공격을 기존의 네트워크 방화벽이나 침입탐지시스템가 방어하는데 한계가 있다. 웹방화벽은 SQL Injection 등 웹공격에 특화된 보안 솔루션이므로 웹방화벽의 도입도 검토할 필요가 있다. 그러나, 기업에서 경제적인 문제로 인해 상용 웹방화벽 도입이 어려운 경우가 많으므로 본 고에서는 공개 웹방화벽인 WebKnight를 통해 SQL Injection 등 웹공격에 대해 방어하는 방안을 살펴보고자 한다.

WebKnight는 GNU 공개 라이센스 원칙을 따르는 공개 소프트웨어로써 모든 기업이나 개인이 자유로이 사용할 수 있다. 하지만, 대부분의 공개 소프트웨어와 마찬가지로 WebKnight도 상용 웹방화벽에 비해 인터페이스나 메뉴얼 등 사용자 편의성이 부족하고, 지속적인 유지보수도 어렵다는 단점이 있다. WebKnight도 2003년 11월에 v1.3 버전이 릴리즈된 후 업데이트가 없다.

그러나, 이 도구는 SQL Injection을 포함한 다양한 웹공격에 대해 차단할 수 있는 프레임을 제공해주고 있고, 현재 많이 사용되고 있는 IIS5, IIS6에서도 아무런 문제없이 운영이 가능하여 최근의 웹 공격 차단에 상당히 많은 도움을 줄 수 있다. 물론, WebKnight의 잘못된 설정은 정상적인 웹 요청까지 차단할 수 있으므로 충분한 커스트마이징 과정은 웹서버 관리자의 몫임을 명심하여야 할 것이다.

본 고에서는 WebKnight의 주요 기능을 살펴보고 설치 및 커스트마이징 방법을 소개하고, 실제 공격을 얼마나 잘 차단하는지 테스트한 결과를 소개한다.

2. WebKnight 개요


WebKnight는 AQTRONIX사(http://www.aqtronix.com/)에서 개발한 IIS 웹서버에 설치할 수 있는 공개용 웹 방화벽이다.


WebKnight는 ISAPI 필터 형태로 동작하며, IIS 서버 앞단에 위치하여 웹서버로 전달되기 이전에 IIS 웹서버로 들어온 모든 웹 요청에 대해 웹서버 관리자가 설정한 필터 룰에 따라 검증을 하고 SQL Injection 공격 등 특정 웹 요청을 사전에 차단함으로써 웹서버를 안전하게 지켜준다.


이러한 룰은 정기적인 업데이트가 필요한 공격 패턴 DB에 의존하지 않고 SQL Injection, 디렉토리 traversal, 문자 인코딩 공격 등과 같이 각 공격의 특징적인 키워드를 이용한 보안필터 사용으로 패턴 업데이트를 최소화하고 있다. 이러한 방법은 알려진 공격 뿐만 아니라 알려지지 않은 공격으로부터도 웹서버를 보호할 수 있다.


또한, WebKnight는 ISAPI 필터이기 때문에 다른 방화벽이나 IDS에 비해 웹서버와 밀접하게 동작할 수 있어 많은 이점이 있다. MS의 URLScan과 마찬가지로 ISAPI 필터로써 inetinfo.exe 안에서 동작하므로 오버헤드가 심하지 않다.


해킹당한 한 웹사이트에 WebKnight를 적용하여 테스트한 결과 안정적인 웹서버 운영으로 인해 웹서버 속도가 오히려 빨라진 것을 느낄 수 있었다. 하지만 다량의 웹 트래픽이 발생되는 사이트에서는 사전에 충분한 검증을 거친 후에 적용할 필요는 있다.

다음은 WebKnight의 주요 특징이다(http://www.aqtronix.com/?PageID=99 참조).

o 낮은 보유 비용(Total Cost of Ownership)
WebKnight는 윈도우즈 인스톨러 패키지와 원격 설치 스크립트로 설치가능해 사내에서 쉽게 WebKnight를 채택할 수 있다.

또한 WebKnight 설정을 바꾸기 위해 그래픽 사용자 인턴페이스를 제공한다.

o 운영 중 업데이트 가능
일부 설정의 변경을 제외하고 대부분의 설정 변경은 웹서버의 재가동을 요구하지 않아, 웹 사용자들에 대한 어떠한 서비스 장애 없이 설정을 변경할 수 있다. 성능상의 이유로 매 1분마다 이러한 변경을 탐지하여 적용한다.

o SSL 보호(protection)
다른 전통적인 방화벽과는 달리 WebKnight는 ISAPI 형태로 IIS의 일부로 동작하므로 HTTPS 상의 암호화된 세션들도 모니터링 및 차단할 수 있다.

o Logging
기본적으로 차단된 모든 요청에 대해 로그를 남기고, 로깅 전용 모드로 운영할 경우 추가적으로 모든 허용된 요청에 대해서도 로그를 남길 수 있다. 로깅 전용 모드는 공격을 차단하지는 않고 로그 파일에서 공격 사실을 조사하는데 도움을 줄 수 있다.

o HTTP Error Logging
WebKnight는 웹서버로부터 HTTP 에러들을 로그할 수 있도록 설정할 수 있다. 이 방법으로 ‘404 Not Found'와 같은 일반적인 에러나 ’500 Server Error'와 같이 보다 심각한 로그들도 기록할 수 있다. 에러 로그를 이용하여 공격을 탐지하거나 깨진 링크를 발견하거나 잘못된 설정도 쉽게 발견할 수도 있다.

o 웹기반 애플리케이션과의 호환성
WebKnight는 Frontpage Extensions, WebDAV, Flash, Cold Fusion, Outlook Web Access, SharePoint 등과도 호환이 잘 이루어진다.

3. WebKnight 설치 및 제거


가. WebKnight 설치


WebKnight는 윈도우즈 인스톨러를 이용한 설치, install.vbs 스크립트를 이용한 설치, 수동 설치 등 3가지 방법으로 설치할 수 있다.

웹호스팅 서버 등 하나의 웹서버 내에 다수개의 사이트가 운영되는 경우 웹서버 전체에 필터를 적용(글로벌 필터)할 수도 있으며, 개별 웹사이트별로 서로 다른 룰에 의해 필터를 적용(사이트 필터)할 수도 있다.


윈도우즈 인스톨러와 install.vbs 스크립트를 이용한 설치시에는 기본적으로 글로벌 필터가 적용 되는데 설치 과정은 다음과 같다.


① 아래 URL에서 WebKnight 1.3(2003.11.10 릴리즈)을 다운로드 받는다.


http://www.aqtronix.com/downloads/WebKnight/2004.02.01/WebKnight.zip


② 압축을 해제하면 아래와 같은 폴더와 파일이 생성된다.


③ Setup 폴더로 이동하여 설치 방법을 선택할 수 있다.


④ WebKnight.msi 파일을 더블클릭하여 윈도우즈 인스톨러를 동작시켜 WebKnight를 설치할 수도 있고, install.vbs 스크립트를 더블클릭하여 설치할 수도 있다.(삭제시에는 uninstall.vbs 파일 실행) 다음 그림은 IIS 6.0에서 WebKnight.msi 파일 실행하여 윈도우즈 인스톨러에 의해 설치되는 화면이다.


⑤ 라이센스 동의 후 설치 타입 선택화면이 나타나는데, 일반적으로 “Typical"을 선택한다.


⑥ 이후 자동 설치과정이 진행되며 설치가 완료되면 다음과 같은 메시지가 나타난다.


⑦ 기본적으로 C:\\Program Files\AQTRONIX\WebKnight 폴더에 설치가 완료된다.
이 폴더 내에 필터 역할을 하는 DLL파일(WebKnight.dll)과 향후 커스트마이징을 위해 필요한 설정실행 파일(Config.exe), 로그파일(IIS 재가동 후 생성) 등이 위치하고 있으므로 이 폴더의 위치를 기억할 필요가 있다.


⑧ IIS 웹서버를 재가동 한다.
⑨ IIS 웹서버를 재가동 후에 정상적으로 설치가 완료되었을 경우 다음과 같이 웹사이트 동록 정보의 “ISAPI 필터”에 다음과 같이 WebKnight 필터가 정상적으로 적용이 된 것을 확인할 수 있다.


위 과정을 통해 WebKnight의 설치는 간단히 수행할 수 있다. 만일 다수개의 웹사이트가 운영되어 각 사이트마다 필터링 룰을 달리 적용하거나 자동 설치가 어려운 경우 다음과 같이 수동으로 설치할 수 있다.

  • 글로벌 필터로 수동 설치


    ① 압축 해제 후 생성되는 Setup 폴더를 C:\Program Files\AQTRONIX WebKnight와 같은 서버 내의 로컬 폴더를 생성하고 여기에 복사한다.
    ② 인터넷 정보 서비스를 연다.
    ③ 서버 이름(사이트 이름이 아님)에서 우측 마우스를 클릭하여 “등록정보”를 선택한다.
    ④ 마스터 속성 리스트에서 “WWW 서비스”를 선택하고, “편집” 버튼을 누른다.
    ⑤ “ISAPI 필터” 탭을 선택하고 “추가” 버튼을 클릭한다.
    ⑥ “필터 등록 정보”가 나타나면 필터 이름과 실행 파일 경로를 입력한다.
    (예를들어, 필터 이름 : WebKnight, 실행 파일 경로 : C:\Program Files\AQTRONIX WebKnight\WebKnight.dll)
    ⑦ "OK" 버튼을 누르고 대화상자를 빠져 나간다.
    ⑧ IIS를 재 가동한다.

  • 사이트 필터로 수동 설치


    ① 압축 해제 후 생성되는 Setup 폴더를 C:\Program Files\AQTRONIX WebKnight\W3SVC1과 같은 서버내의 로컬 폴더를 생성하여 여기에 복사한다.(단, 각 WebKnight 설치를 위한 unique한 폴더를 가져야 한다.)
    ② 인터넷 정보 서비스를 연다.
    ③ 사이트 이름(서버 이름이 아님)에서 우측 마우스를 클릭하여 “등록정보”를 선택한다.
    ④ “ISAPI 필터” 탭을 선택하고 “추가” 버튼을 클릭한다.
    ⑤ “필터 등록 정보”가 나타나면 필터 이름과 실행 파일 경로를 입력한다.
    (예를들어, 필터 이름 : WebKnight, 실행 파일 경로 : C:\Program Files\AQTRONIX WebKnight\W3SVC1\WebKnight.dll)
    ⑥ "OK" 버튼을 누르고 대화상자를 빠져 나간다.
    ⑦ Setup 폴더 아래의 config.exe 파일을 실행해서 “Global Filter Capabilities" 섹션에서 ”Is Installed As Global Filter“의 체크를 해제한다.


    ⑧ IIS를 재 가동한다.

    나. WebKnight 제거


    만일 WebKnight를 제거하고자 할 경우 다음과 같은 3가지 방법 중 하나를 선택하여 WebKnight를 제거한 후 IIS를 재가동한다.


    ① 윈도우즈 인스톨러를 이용한 자동 제거 (WebKnight.msi 실행)


    디폴트 경로에 설치되어 있는 경우 C:\ProgramFiles\AQTRONIX WebKnight\
    WebKnight.msi를 실행하면 오른쪽 그림과 같이 “Modify", "Repair", "Remove" 화면이 나타나는데, 이 중 ”Remove"를 선택하면 자동으로 WebKnight가 제거된다.


    ② 스크립트를 이용한 자동 제거 (uninstall.vbs 실행)


    디폴트 경로에 설치되어 있는 경우 C:\Program Files\AQTRONIX WebKnight\uninstall.vbs를 실행하면 자동으로 WebKnight가 제거된다.


    ③ 수동 제거


    수동 설치과정과 마찬가지로 인터넷 정보 서비스를 열고 글로벌 필터 또는 사이트 필터
    에 따라 서버 이름 또는 사이트 이름을 선택한 후 우측 마우스를 클릭하여 “등록정보”→
    “편집”→“ISAPI 필터” 탭을 선택하여 WebKnight 항목을 선택한 후 “제거” 버턴을 누른다.


    상기와 같이 WebKnight를 제거한 후 변경사항을 반영하기 위해서는 IIS를 재가동하여야 한다.

    4. 설정 커스트마이징


    WebKnight는 SQL Injection 공격차단, 허용하지 않는 파일 또는 확장자에 대한 접속 차단 등 웹공격에 대해 대단히 다양한 차단기능을 제공해 주고 있다. 또한 기본적으로 이러한 차단기능이 설정되어 설치와 동시에 적용이 되는데 이 차단기능이 정상적인 웹 접속을 차단할 수도 있다.


    따라서 설치이후 자신의 웹사이트 환경에 맞게 적절하게 커스트마이징하는 과정을 반드시 거쳐야 한다. 실제 설치보다는 커스트마이징에 많은 노력과 시간을 들여야만 한다. 설정과정을 통해 오히려 웹 공격의 다양한 패턴을 익힐 수 있는 기회도 될 수 있을 것이다.


    먼저, WebKnight 설치 이후 해당 웹사이트에 방문해서 정상적으로 웹요청 및 응답이 이루어지는지 확인을 하고, 접속이 차단될 경우 WebKnight의 로그를 참조하여 어떠한 룰에 의해 요청이 차단되었는지 찾아 이 룰을 수정하여야 한다.

    디폴트 설치시 로그파일의 위치와 설정프로그램은 다음과 같다.
    o 로그파일 : C:\Program Files\AQTRONIX WebKnight\LogFiles\YYMMDD.log
    o 설정프로그램 : C:\Program Files\AQTRONIX WebKnight\config.exe

    WebKnight 설치 후 웹 접속시 다음과 같은 경고 화면이 뜰 수 있다.


    이 화면은 WebKnight에서 필터 룰에 의해 차단을 시킨 후 웹접속자에게 보내는 기본 경고화면이다.


    정상적인 웹 요청을 했는데도 불구하고 이와같이 차단된다면 로그파일을 열어 “BLOCKED" 메시지를 확인하고 어느 룰에서 차단되었는지 찾아 설정파일에서 이를 해제하여야 한다. 디폴트 설치의 경우 WebKnight의 로그파일은 설치 후 IIS 웹서버를 재가동하게 되면 ”C:\Program Files\AQTRONIX WebKnight\LogFiles“ 폴더가 생성되고 그 하위에 일자별로 로그파일이 생성된다.


    기본적인 로그파일의 각 필드는 다음과 같다.


    정상적인 웹 접속이 차단되어 로그파일을 분석해 보니 다음과 같은 로그가 남았다.

    05:57:42 ; W3SVC31 ; OnPreprocHeaders ; xxx.xxx.207.85 ; ; GET ; /admin/img/deffortune.jpg ;
    BLOCKED: '/admin' not allowed in URL ; HTTP/1.1 ; ASPSESSIONIDAQDBDDAD=NACAJJBAPJACHHPHNIPGDKCH

    위의 로그를 보면 "/admin" 폴드에 대한 접속을 허용하지 않도록 WebKnight 룰이 설정되어 있는데, /admin/img/deffortune.jpg 파일에 접속하고자 하여 웹접속이 차단된 것을 알 수 있다. 이는 홈페이지 초기화면 구성시 /admin 폴드에서 그림파일을 가져오도록 설계되어 있어 발생되었는데, 일반사용자들이 접근하는 화면에 /admin 폴드의 컨텐츠를 포함하지 않도록 변경할 필요가 있다.


    또는, WebKnight의 설정을 변경하여 /admin 폴더에의 접속을 허용할 경우 접속이 차단되는 상황을 막을 수 있다. 이처럼 로그파일을 통한 커스트마이징 과정은 현재의 웹서버 설계상의 문제도 파악하여 개선하도록 도와줄 수도 있다.

    다음 FAQ에는 WebKnight의 설치와 환경설정, 로그파일 분석시 자주 발생될 수 있는 문제와 궁금증에 대해 질의․응답식으로 정리되어 있으므로 참고하기 바란다.

    http://www.aqtronix.com/?PageID=114


    로그파일 해석시 기본 설정의 로그 시간대는 GMT/UTC로 한국 시간대인 GMT+09 보다 9시간 늦으므로 로그 분석시 이를 감안하여야 한다.(설정에서 “USE GMT”를 체크하지 않음으로 시스템 시간과 동기화시킬 수 있다.)

    설정 변경은 config.exe 파일을 실행하여 GUI 인터페이스를 통해 설정할 수 있다.


    config.exe를 통해 WebKnight의 다양한 필터링 기능을 설정할 수 있는데 다음과 같은 설정을 할 수 있다.
    설치경험을 통해 환경설정과정에서 웹서버 관리자가 유심히 확인해야 되는 부분에 대해 “확인 사항”에 의견을 넣었으니 참고하기 바란다.


    위 대부분의 설정 변경 사항은 IIS의 재가동 없이 바로 적용이 되지만 일부 항목은 재가동을 하여야만 적용이 되는 것도 있으므로 IIS의 재가동 여부를 확인할 필요가 있다. 만일 설정을 잘못 변경하여 다시 디폴트 설정으로 바꾸기 위해서는 WebKnight.xml 파일을 삭제한 후에 웹서버를 재시작하면 된다(디폴트 상태의 WebKnight.xml 파일이 새로 생성됨).

    5. 모의 공격 및 공격차단 확인


    WebKnight의 커스트마이징으로 정상적으로 설치가 완료가 되었을 경우 웹 공격이 정상적으로 차단되고 있는지 확인해 볼 필요가 있다.


    다음 그림은 WebKnight 설치 이전에 해당 웹서버가 SQL Injection 공격에 취약하여 공격툴에 의해 DB 접근이 가능하고 DB 계정 및 테이블이 노출되고 있는 화면이다.


    하지만, WebKnight의 설치 이후 동일한 공격툴을 이용하여 테스트한 결과 공격은 실패하였으며, 웹서버의 WebKnight 로그파일에 공격 차단 로그가 남았다.

    06:13:40 ; W3SVC31 ; OnPreprocHeaders ; xxx.xxx.151.24 ; ; GET ; /west/newsvieww.asp ;
    id=37'%20and%20user%2Bchar(124)=0%20and%20''=' ; BLOCKED: possible SQL injection in
    querystring ; HTTP/1.1 ; ASPSESSIONIDAQDBDDAD=EDIAJJBAFOHJCEKKEMBNCEJD
    06:13:40 ; W3SVC31 ; OnPreprocHeaders ;xxx.xxx.151.24 ; ; GET ; /west/newsvieww.asp ;
    id=37%25'%20and%20user%2Bchar(124)=0%20and%20'%25'=' ; BLOCKED: possible SQL injection
    in querystring ; HTTP/1.1 ; ASPSESSIONIDAQDBDDAD=EDIAJJBAFOHJCEKKEMBNCEJD

    SQL Injection 공격이외에도 취약한 CGI 공격, 디렉토리 traversal 공격 등 다양한 웹 공격이 차단되는 것을 확인할 수 있었다. WebKnight가 정상적으로 공격을 차단하고 있음을 확인하면 운영에들어가는데, 운영하는 과정에서도 주기적인 WebKnight의 로그 확인이 필요하다. 로그 확인을 통해 어떠한 공격시도가 일어나고 있는지 확인하고 적절한 대응을 하여야 한다.

    지금까지 공개 웹방화벽인 WebKnight를 이용한 SQL Injection 차단 방안에 대해 소개하였다. WebKnight를 실제 운용되고 있는 취약한 웹서버에 적용시켜 본 결과 훌륭한 공격 차단효과를 확인할 수 있었는데, 상용 웹 보안도구의 도입이 여의치 않은 중소규모의 웹사이트에서 적용하기에 적절할 것으로 보여진다.

    웹 보안의 기본은 안전하게 코딩된 웹 프로그램에 있음을 명심하여야 할 것이다.
    홈페이지 개발보안 가이드, 표준 웹애플리케이션 보안 템플릿 등을 참고하여 웹 애플리케이션 설계단계에서부터 안전하게 개발하는 것이 가장 우선시 되어야 할 것이고, 부가적인 보안 조치로 WebKnight를 활용하기 바란다.



    ※ KISA는 본 문서에서 언급한 WebKnight 및 해당 도구 개발사인 AQTRONIX와 어떠한 관계도 없으며, 국내 웹 해킹 피해 예방을 위해 공개 웹방화벽인 WebKnight를 보안 참고용으로 소개한다

  • Posted by ㏈ª ☞ β┖υΕJini.κR