웹방화벽 올해, 아니 적어도 3년 이내에는 대부분의 업체에 도입되어야 할 물건으로 보입니다. 실제 웹방화벽이라는 말이 생겨난지는 얼마 되지 않았습니다. 국내에 잘 알려지게 된 동기는 바로 2005년 여름에 중국발 웹해킹(SQL Injection)이 널리 알려지면서야 일반인들에게 알려지게 된거죠.
웹방화벽과 일반 네트워크 방화벽은 둘 다 "방화벽"이라는 단어를 사용하지만 둘의 동작 방법이나 목적은 다릅니다. 네트워크 방화벽은 네트워크에 돌아다니고 있는 패킷이 정상이고 올바른 것인지를 판단하며, 웹방화벽은 패킷이 아닌 사용자의 URL이 정상이고 올바른 요청인지를 판단합니다. OSI 7 Layer의 구조에 맞춰서 두 장비를 비교해 본다면, 일반 방화벽은 패킷이 돌아다니게 되는 L3~L4(Network Layer, Protocol Layer) 레벨에서 동작하게 되고, 웹방화벽은 HTTP와 HTTPS 요청이 있는 L7 레벨(Application Layer)에서 동작합니다.
[그림1] TCP/IP에서의 HTTP의 위치
웹서버에서 패킷을 캡춰해보셨거나, 웹로그를 보신 분들은 아시겠지만, 대부분의 접근하는 분들은 정상적인 방법을 통해 접근하는 분들입니다. 하지만, 가끔 로그를 하나하나 뜯어서 분석하다 보면 문제가 되는 로그를 볼 수 있습니다.
예를 들면 다음과 같은 것들이지요..
[그림2] 1분에 같은 페이지의 수십 회 호출
이건 정상인 것으로 보이지만, 시간을 잘 보십시오. 1분에 저만큼의 클릭이 있었습니다. 1시간 동안에 저 정도의 접속이라면? 그리고 다수의 컴퓨터에서 동시에 일어났다면? 위의 로그가 바로 DOS(Deny of Service)공격이 되는거죠.
그리고 웹로그 중에서는 다음과 같은 것들도 심심치 않게 볼 수 있습니다.
[그림3] SQL Injection 공격시 웹로그
위에 언급한 내용은 "Google Analytics"이나 "다음 웹인사이드"와 같은 로그 서비스를 통해서는 얻을 수 없습니다. 웹로그를 직접 보지 않은 분들은 모르는 결과들 입니다. 하지만, 위의 로그들은 웹서버의 입장에서 보면 지극히 정상적인 접근 입니다. 패킷이 손상되지도 않았을 뿐더러, 완전무결한 결과를 보내주었으니까요. 단지 접근자의 PC가 이상했거나, 접속자가 비정상적인 명령을 했을 뿐입니다. 이 비정상적인 명령인지를 판단하는건 내부에 있는 개발자나 사이트 관리자의 몫입니다.
따라서 일반적인 네트워크 방화벽의 도입 목적은 다음과 같습니다
- 비 정상적인 사용자의 접근을 막을 수 있다
- 불필요한 접근을 최소화하여 네트워크 비용을 줄일 수 있다
- 네트워크의 공격을 막을 수 있다 (DOS, Spoofing... ETC)
- 비 정상적인 사용자의 요청(GET, Post... ETC)을 막을 수 있다
- 손쉬운 세션 관리가 가능하다
- 손쉬운 로그 관리가 가능하다
- 개발자의 프로그램 상의 실수를 막을 수 있다
- 웹서버의 부하를 줄일 수 있다
웹방화벽은 개발자가 보안에 충실하여 완벽한 프로그래밍을 했다면 필요가 없습니다. 하지만, 개발자 입장에서 변종되는 다양한 공격 유형을 학습하고 적용할 시간적 여유가 없으며, 이런 프로그래밍을 했다 할지라도 웹페이지를 처리하는 과정에서 서버와 클라이언트 양쪽에 엄청난 부하가 있고, 이미 작성된 모든 페이지에 빠짐없이 이를 적용한다는 것은 사실상 불가능합니다. 그렇기에 우리는 불안에 떨며, 있을지도 모르는 부분의 처리를 위해 웹방화벽을 도입하는 것이 좋지 않을까 싶군요. 다만 불행히도 현재의 하드웨어 기반의 웹방화벽은 상당한 고가이므로, 프리웨어 기반의 IIS라면 WebKnight, Apache라면 ModSecurity를 설치하고 활성화 하는 것이 좋지 않을까 싶군요.
'윈도우 보안' 카테고리의 다른 글
| 마이크로소프트, 오피스 2003용 보안 도구 출시 (0) | 2007/05/23 |
|---|---|
| 마이크로소프트 스파이웨어(AnitSpyware) 퇴치 프로그램 소개 (2) | 2007/04/16 |
| 웹방화벽. 과연 필요한가? (2) | 2007/02/19 |
| 2007년 2월 Microsoft 보안 공지 요약 (0) | 2007/02/14 |
| IIS 에 설치시 생성되는 IUSR_computername 과 IWAM_computername 계정에 대한 암호취득 방법 (4) | 2007/02/14 |
| IPSec 을 통한 웹서비스 보안 정책(필터링편) (0) | 2007/02/14 |
댓글을 달아 주세요
하나의 질문 드립니다.
Snort에 보면 Web 관련 룰들이 존재하는데,
이러한 룰을 기반으로 필터링을 수행하는 부분과,
웹 필터링의 부분에 있어 어느쪽이 효과적이라고 생각하시는지요?
Snort에서 막는 것도 좋지만 그걸 다 콘트롤하기는 사실상 불가능에 가깝습니다. 하루 종일 스노트 로그 보고 있는건 비용적인 부분에서 엄청난 손실이죠. 중소기업에서 그걸 보고 있을 사람을 뽑을리도 없고, 그걸 계속 보고 있는 사람이 있을리도 만무하고.. 그리고 무엇보다 스노트의 필터의 업데이트가 상당히 느린편에 속합니다. (그나마 타 장비에 비하면 빠른 편이긴합니다만..)