Category Archives: 보안

Linux 방화벽 iptables & DDoS 방어?

PF로 DDoS 공격을 어느정도 막으면서, iptables에서도 가능한지 궁금해졌습니다. PF 처럼 쉽게 공격 IP를 완전하게 차단하는 방법은 찾지 못했지만, IP당 시간당 연결수를 제한하는 방법은 있네요.

iptables -N SSHSCAN
iptables -A INPUT -p tcp –dport 22 -m state –state NEW -j SSHSCAN
iptables -A SSHSCAN -m recent –set –name SSH
iptables -A SSHSCAN -m recent –update –seconds 300 –hitcount 3 –name SSH -j DROP

5분동안 22포트에 똑같은 IP가 3번 이상의 TCP 연결이 들어오면 그 이후로는 막습니다. 즉 5분간 3개의 연결만을 허용합니다. SSH 돌리기 신공은 막을수 있겠지만, DDoS 공격을 차단하기는 부족한 기술인듯하네요.

using-iptables-to-block-brute-force-attacks 문서를 보시면, 자세한 설명이 있고, 공격 아이피에 대해서 로깅을 하는 방법도 있습니다. 로그 분석해서 iptables rule을 등록해주면 공격 아이피에 대해서 차단할수 있을듯하네요. 하지만 이 방법 말고 더 쉬운 방법이 없을까 고민중입니다.

여러가지 로그 파일에서 로그인 실패를 모니터링해서 공격을 막아주는 fail2ban 이라는 툴도 있네요. 설명은 여기를 참고하세요. 역시 DDoS 방어용은 아니지만, 로그 분석을 통해서 방화벽에 IP 등록하는걸 응용할수 있을듯합니다.

최근
Linux Firewalls: Attack Detection and Response with iptables, psad, and fwsnort 책을 보기 시작했는데 좀더 좋은 방어 방법 찾으면 다시 글 올리겠습니다.

BSD 방화벽 PF & DDoS 방어

PF(Packet Filter)는 BSD용 방화벽입니다. 원래 IPF라고 개인이 만든 공개 방화벽이 있어서, 여러 BSD 계열 UNIX에서 주로 사용하였었습니다. 다른 개발자들이 라이센스에 대해 명확하지 않은 부분에 대해서 설명 요구에 대한 응답에 만족하지 못한 오픈소스 개발자들이 새롭게 만든 방화벽이 PF입니다. 정말 너무나도 빠르게, IPF와 기능은 유사하게 만들어졌습니다. IPF는 소스는 공개였지만, 소스 분기는 허용하지 않고 원 개발자가 필요한 패치만 해서 하나의 버전을 유지하겠다고 했었습니다…

하여간 PF가 OpenBSD 개발자들에 의해서 순식간에 만들어지고, 여러개발자들이 참여가 가능했기 때문에 금방 여러가지 추가 기능들이 구현됐습니다. 오픈 소스 최고의 방화벽으로 자리 잡았고, 상용 방화벽이 갖추지 못한 좋은 기능들도 많이 가지고 있습니다.

FreeBSD에서 PF 방화벽을 사용하려면 /etc/rc.conf 에

pf_enable=”YES”
pflog_enable=”YES”

를 추가해야합니다.

정책 설정은 /etc/pf.conf 에서 합니다.

설정 파일에서 가장 중요한 부분은 pass/block이죠…

pass/block in/out (log) on 인터페이스

proto 프로토콜
from 주소/마스크비트 port 포트

to 주소/마스크비트 port 포트

1.2.3.x 에서 오는 모든 udp 패킷을 막고 싶다면…

block in proto udp from 1.2.3.0/24 to any

80포트로 오는 걸 열어주고 로그로 남기고 싶으면,

pass in log proto tcp from any to port 80 keep state

keep state하면 생성된 TCP 세션에 대해서 들어오고 나가는 패킷이 방화벽을 통과합니다.

패킷이 왔을때 위에서 부터 비교가 되며… 맨 마지막 매치가 선택됩니다.
단, quick이 설정되어 있으면 그 매치가 선택됩니다.

아래는 현재 사용중인 설정입니다. 추가적인 보안 관련 설정이 여러가지 있습니다..

ext_if=”em0″

set limit { states 80000, frags 5000 }

set block-policy drop

set skip on lo0

scrub in all
antispoof for $ext_if

block in all
block out all

table <bruteforce> persist
table <sshbruteforce> persist

block in quick log proto tcp from <bruteforce> to port 80
block in quick log proto tcp from <sshbruteforce> to port 22

pass in on $ext_if proto tcp from any to $ext_if port 22 \
            flags S/SA keep state \
            (max-src-conn-rate 10/30, overload <sshbruteforce> flush global)
pass in on $ext_if proto tcp from any to $ext_if port 80 \
        flags S/SA synproxy state
pass in on $ext_if proto tcp from any to $ext_if port 80 \
        flags S/SA keep state \
        (max-src-conn 100, max-src-conn-rate 300/10, \
        overload <bruteforce> flush global)

위에 설정에서 ssh나 http로 하나의 IP에서 여러개의 요청이 한번에 오면 막는 기능이 동작합니다. HTTP의 경우 최대 100개의 동시 연결, 10초간 300개 이상의 연결이 발생하게 되면 공격자로 인식하고 기존 연결을 모두 끊어버리고 연결을 막습니다.

한번 등록되면 방화벽 재시작 전에는 해당 IP에서 연결이 안됩니다. 일정 기간이 지나면 풀리게 하는 방법은 expiretable를 사용하면 가능합니다.

FreeBSD에서는

# cd /usr/ports/security/expiretable
# make install

# /usr/local/sbin/expiretable -t 2h bruteforce

2시간 이상 지난 IP를 풀어주는 명령으로 crontab에 등록해서 사용하면 됩니다.

최신 버전 PF를 사용하면 pfctl로 같은 기능을 할수 있다고 합니다.

# pfctl -t bruteforce -T expire 7200

방화벽 시작, 재시작, 설정 파일 다시 읽기, 종료 방법:

# /etc/rc.d/pf start
# /etc/rc.d/pf restart
# /etc/rc.d/pf reload
# /etc/rc.d/pf stop
# /etc/rc.d/pflog start
# /etc/rc.d/pflog stop

방화벽 로그를 실시간으로 보는 방법

# tcpdump -i pflog0

쌓인 로그를 보는 방법

# tcpdump -r /var/log/pflog

방화벽 상태 보기

# pfctl -s all
# pfctl -vvs all (보다 자세한 정보 보기)

방화벽 공격 IP 보기

# pfctl -t bruteforce -T show

마지막으로… 원격에서 방화벽 잘못 설정하면 IDC로 튀어가야합니다.
신중을 기해야합니다.

한가지 터득한 방법은…

# /etc/rc.d/pf reload; sleep 15; /etc/rc.d/pf stop

restart보다는 reload가 그나마 안전합니다. reload할 때는 세션 테이블이 초기화 되지 않습니다.

DDoS의 공격의 종류가 많고 어디가 bottleneck이 되느냐에 따라 해결방법이 틀려집니다. 서버 자체의 부하를 일으켜 서비스 거부 공격을 받는 경우 PF로 많은 공격을 막을수 있습니다.

pfstat을 설치하면, PF의 여러가지 상황을 모니터링 할수 있습니다.

# cd /usr/ports/sysutils/pfstat
# make install

pfstat 홈페이지의 설정파일을 복사하고, 인터페이스명과 파일 저장 위치들만 바꿔주고
crontab에 아래처럼 등록했습니다.

# crontab -l
* * * * * /usr/local/bin/pfstat -q
*/5 * * * * /usr/local/bin/pfstat -p

nikto 웹서버 보안 점검툴

pauldotcom.com podcast에서 소개된 툴인데, 직접 돌려보니 생각지도 않게 많은 이슈들이 나오네요. 먼저 홈페이지 소스를 CVS로 관리하는데 CVS/Entries 파일에 접근해 php 이외의 다른 파일들을 확인할수 있던 문제가 발견되었습니다. php 외에도 내부적으로 py나 c 파일들도 CVS에 편의상 등록해서 썼었는데, CVS 하위 디렉토리에 접근하지 못하도록 모두 막았습니다.

그리고, CentOS에서 lighttpd 1.4.13 src rpm을 컴파일해서 사용했었는데, amd x64 머신에서 이유는 모르겠지만 스캔하면 웹서버가 죽는 일이 발생했습니다. 모든 x64 서버에서 그런건 아니고, 중요한 서비스를 하는 두대에서 발생했습니다. 원격에서 lighttpd를 그냥 죽일 수 있더군요. 재빨리 업그레이드 하려고 하는데, src rpm도 찾기 힘들고 (찾긴 찾았느데 의존성 문제때문에…) 해서 소스를 가져다 컴파일해서 make install하고 (/usr/local 밑에).. /etc/init.d/lighttpd에서 실행파일을 /usr/sbin/lighttpd에서 /usr/local/sbin/lighttpd로 변경하고 재시작하니 문제없이 업그레이드가 되었습니다. 정확히 문제가 뭐였는지는 파악하지 못했지만 업그레이드해서 해결은 됐습니다.

또 lighttpd에서 /server-status 를 편의상 열어놨었는데, 이거도 경고가 나와서 접근제한 걸었습니다.

보안 점검툴 돌릴때는 본인이 관리하는 서버나 서버 관리자에게 미리 허락을 맡고 하세요. 흔적이 다 남습니다. 스캔 패턴이 항상 일정한지 응답에 따라 달라지는지 모르겠지만, nikto로 한번 스캔하면 3151번의 요청이 로그에 찍히네요.

이메일 보호하기

유튜브에서 이 비디오를 보고, 상식적으로 생각하던것과 틀려서 글 남겨봅니다.

블로그나 게시판 등에서 자신의 이메일을 보호하기 위해서 userid at gmail dot com 등으로 풀어서 쓰는 경우를 종종 보는데, 이게 오히려 스패머들에게는 도움이 된다는 내용입니다. 구글 등의 검색엔진에서 일반 이메일을 찾기보다 저렇게 풀어쓴 이메일을 찾기가 더 쉽다는 거죠. at이나 dot 대신 한글로 써도 틀리지 않을거라 생각이 되네요.

앞으로는 이메일 쓸일이 있으면 이메일 이미지를 써야겠네요.
http://services.nexodyne.com/email/index.php
저도 예전에 위 사이트에서 만들었던거 같은데.. 이 서비스도 많이 사용하면, 이미지에서 이메일을 추출하는 툴들이 나오지 않을까 걱정됩니다. 혹시를 위해서 파일명에 mail 등이 들어가지 않게하는게 좋을거 같네요.

한글 도메인도 되는 저런 이미지 만들어주는 사이트 만들면 사람들이 좋아할거 같네요. 만들기 어렵지 않을테니 시간나면 ㅎㅎ

CAPTCHA와 reCAPTCHA

웹페이지 돌아다니다가 글 쓰려고 하면 스팸 방지 등을 위해서 그림으로 문자들을 보여주고 문자를 사용자가 입력하여 확인하는 경우가 있습니다.

최근에 제가 rapidshare.com와 badongo.com에서 자료(?)를 받는데 일반 사용자는 다운로드 받을때 그림을 보고 입력하는 부분이 있습니다. 프로그램으로 기계적으로 다운로드해서 네트워크 부하를 많이 일으키지 못하도록 하는거죠. 이미지는 아래와 같이 생겼고, rapidshare에서 사용하는 이미지는 글자의 왜곡이 거의 없네요.


프로그램적으로 저런 이미지를 읽기가 얼마나 어려운지 모르겠지만, 간단히 이미지에서 글을 읽기 힘들기 때문에 조금더 어렵게 하는 의미는 있겠죠.

위와 같은 기술을 CAPTCHA라고 하는데, 위키피디아에서 많은 정보를 얻을수 있습니다. CAPTCHA는 Completely Automated Public Turing Test to tell Computers and Humans Apart의 약자라고 하는데, 컴퓨터와 사람을 구별하는 완전히 자동화된 테스트 정도 되겠네요. 약자를 그럴듯하게 만들기 위해서 약간 부가적인 단어가 들어간듯 싶습니다. CMU에서 만든 용어고 CMU에서 많이 연구를 했나봅니다.

이미지를 복잡하게 만들면 문자를 읽어내는 프로그램을 만들기가 더 힘들지만, 사람 역시 문자를 판독하기가 어려워진다고 합니다. 일반적인 홈페이지에서는 CAPTCHA를 도입하는 것만으로도 악의적인 사용자의 공격을 어렵게 만들수 있지만, 사이트를 공격할만한 가치가 크다면 문자를 판독하는 알고리즘을 개발할수도 있고, relay 공격으로 CAPTCHA 문제들을 자동화해서 풀수도 있습니다. relay 방법은 알고리즘을 통해서 문자를 읽는것이 아니라, 사용자가 어느정도 있는 사이트를 악의적인 사용자가 운영하고 있다면, 사용자들이 로그인하거나 가입할때 목표로 하는 CAPTCHA 문제를 받아와서 사용자가 풀게하여 목표 사이트에 가입이나 스팸성 글을 올리는 방법입니다. 아무리 CAPTCHA를 어렵게 만들어도 relay 공격 방법은 막을수 없죠.

어떻게 계산했는지 모르겠지만, 전세계적으로 매일 대략 150,000 시간이 CAPTCHA를 푸는데 소비(낭비)된다고 합니다! 이렇게 허비되는 시간을 좀더 유용하게 사용하기 위한 프로젝트가 reCAPTCHA입니다. 역시 CMU 프로젝트이고, CAPTCHA 문제를 만들때 임의로 생성하는 것이 아니라, 오래된 문서에서 OCR로 판독이 안되는 부분을 문제로 내는겁니다. 하나의 문제만 내면 사용자가 정답을 입력했는지 알 방법이 없기 때문에, 두개의 CAPTCHA 문제를 내고, 사용자들의 입력 결과를 통계를 내서 오랜된 문서의 디지털화에 도움을 줍니다. 정말 반짝이는 아이디어네요. 아래는 reCAPTCHA의 예제입니다.


시간이 있으면 Tattertools 플러그인을 제작하면 좋을것 같네요. 찾아보니 없는거 같네요. 그리고 트랙백 받을때도 어떻게 활용할 방법이 없을까하는 생각도 드네요. 가끔 트래백으로 스팸성 댓글이 많이 달리거든요.

화이트도메인, SPF, RBL & Postfix

회사 서비스에서 회원들에게 메일을 보내보면, 메일이 잘 안가고 반송되고 해서, 얼마동안 이메일 발송을 거의 안했었는데, 작년에 화이트 도메인 제도가 포탈 등에 적용되면서 좀 상황이 나아진 것도 같네요.

자세한 내용은 www.kisarbl.or.kr에서 확인할수 있습니다.

자신의 도메인(DNS) 서비스에서 어떤 아이피 주소에서 메일을 보낼수 있는지를 DNS TXT 영역에 등록합니다. 메일 받는 서버에서 메일을 보내는 도메인의 DNS TXT를 확인하여 등록된 아이피 주소와 다르면 메일을 드랍하도록 하는 원리입니다. SPF(Sender Policy Framework)라고 불리는 기술인데 2006년 RFC 4408  표준으로 지정되었으며, KISA에서 발빠르게 도입을 하여 국내 메이저 포탈등에 대부분 적용되었습니다.

여기 등록을 하면, 다른 화이트도메인 서비스에 등록한 서버간에는 메일이 원활히 전달되며, 서비스에 등록하고 스팸을 보낼수도 있으므로, 등록한 도메인에 대해서 내부적으로 평가하는 시스템을 갖춰서 스팸을 보내는것으로 판단되면 RBL(Real-time Blackhole List)에 등록되어 메일 전달이 어렵게 됩니다. RBL은 스팸을 보내는 아이피주소인지 알려주는 서비스로 여러곳에서 제공하고 있습니다. 원리는 간단합니다. 아이피주소를 조회하면 그 아이피가 스팸을 보내는지 알려주는 서비스입니다. 서비스를 제공하는 곳에 따라서 다른 아이피 주소 리스트를 관리하기 때문에, 보통 여러 RBL을 참조하도록 메일서버를 설정합니다.

KISA에서 제공하는 RBL이 spamlist.or.kr이며, 여기를 보시면 여러 RBL에 대한 비교가 있습니다.

그럼 화이트 도메인 등록과 메일서버 세팅을 하면서 사용한 방법을 설명드리도록 하겠습니다. 먼저 DNS서버의 해당 도메인의 zone 파일에 다음 라인을 삽입하고

내도메인명.  IN   TXT   “v=spf1 ip4:메일보내는아이피1 -all

named를 재시작했습니다. -all이나 ~all로 지정할수 있는데, -all은 내도메인명에서 발송되는 메일중 아이피가 SPF 리스트에 없으면 무조건 드랍하고, ~all로 지정하면 받는메일서버의 정책에 따라 판단하라 입니다. 여러 아이피를 지정할수 있으며 1.2.3.0/24 형태로 아이피 영역을 지정할수도 있습니다.

이렇게 하고 도메인정보가 어느정도 전파되면, www.kisarbl.or.kr에서 화이트도메인으로 등록을 할수 있습니다. 등록방법도 어렵지 않고, 친절히 잘 설명되어 있습니다.

메일서버는 sendmail, qmail을 거쳐서 postfix를 사용하고 있는데 postfix가 제일 설정이 쉽고 모듈화가 잘 되어있는듯하더군요… 하여튼 postfix에서 RBL 등록하는 방법은 매우 간단합니다. main.cf 파일에서 smtpd_recipent_restrictions에 적당한 위치에 reject_rbl_client 항목을 추가해주면 됩니다. 제 서버 설정입니다:

smtpd_recipient_restrictions =
   permit_sasl_authenticated,
   reject_invalid_hostname,
   reject_non_fqdn_hostname,
   reject_non_fqdn_sender,
   reject_non_fqdn_recipient,
   reject_unknown_sender_domain,
   reject_unknown_recipient_domain,
   permit_mynetworks,
   reject_unauth_destination,
   reject_rbl_client spamlist.or.kr,
   reject_rbl_client cbl.abuseat.org,
   reject_rbl_client list.dsbl.org,
   reject_rbl_client sbl.spamhaus.org,
   reject_rbl_client pbl.spamhaus.org,
  permit

smtpd_recipent_restrictions 원래 설정된 항목에서 reject_rbl_client들만 원하는 위치에 등록하면 됩니다. 위에서부터 순차적으로 처리하므로 위치는 원하는 위치에 두시면 됩니다.

메일서버에 RBL을 지정하고 나니 스팸메일 95% 이상이 걸러지는것 같네요… 안오는 메일이 있으면 문제지만 그건 RBL에 아이피가 등록되면 보내는 측에서 잘못한거니 그쪽에서 해결해야할 문제죠. 예전에 실수로 서버에 프록시를 테스트용으로 잠깐 열어두었다가 해외 RBL에 서버중 하나가 등록된 적이 있었는데 RBL에서 빠른 시간내에 제거하는 게 어렵더군요. 등록되는 RBL에 따라 제거 방법도 다르고요… 관리하는 메일서버에서 스팸이 나가지 않도록 잘 관리해야겠습니다.

Firefox 2.0 & third-party cookie

Firefox 1.5 까지는 설정에서 third-party cookie를 사용하지 않도록 할수 있었는데, 2.0에서는 이 기능이 도구-설정에서 빠졌다고 하네요. about:config에서 설정이 가능하지만 바꿔야하는 설정값의 이름이 좀 상관없어 보이고, 설정하는것도 bool 값이 아닌 int 값입니다.
주소창에서 about:config를 치고, 필터에 cookieb까지 치면 항목이 하나 남습니다. network.cookie.cookieBehavior를 바꿔주면 됩니다. 디폴트 값이 0인데 더블클릭해서 1로 바꿔주면 third-party cookie를 허용안하도록 바뀝니다.

cookie는 웹서버와 웹브라우저간에 주고 받는 정보로 웹서버에서 임의의 정보를 웹브라우저쪽에 저장을 할수가 있습니다. 예를들면 사용자 로그인 정보, 장바구니 등이 저장됩니다. 웹서버와 웹브라우저가 연결을 유지하면 그 사용자가 누군인지 관리할수 있지만, 웹 프로토콜인 HTTP는 기본적으로 연결을 하고 있는 구조가 아닙니다. 그래서 가상의 세션을 유지하게 위해서 만들어진것이 쿠키라고 생각하면 됩니다. 쿠키는 웹서버가 웹브라우저쪽으로 정보를 저장하고, 다시 조회하는 형태지만, 클라이언트 측에서 악의적으로 쿠키를 변경하면, 로그인 없이 사이트에 접속이 가능할수 있는 가능성이 있죠. 그래서 웹서버에서 웹브라우저에서 쿠키를 변조 못하도록 신경을 써주지 않으면 보안 문제가 발생할수 있습니다. 웹브라우저에서는 사이트별로 쿠키가 저장되도록 하고, 어떤 사이트에서 해당 사이트의 쿠키만 조회하고 변경할수 있도록 하여, 보안 문제가 발생하는 걸 보호합니다.

그럼 third-party cookie가 무엇인지 설명드리겠습니다. 요즘은 웹이 광고로 도배되면서 광고이미지 등은 원래 웹사이트가 아닌 다른 서버(AD서버)에서 주로 가져옵니다. 이미지를 요청할때는 원래 웹사이트의 URL이 referer라는 값으로 전송됩니다. 그래서 AD서버에서 광고를 보는 사용자가 어떤곳을 보고 있는지 모두 저장할수 있습니다. 광고가 나온곳이 검색 사이트면 검색하는 단어들을 다 볼수 있는거죠. 그런데 이렇게 보는것 까지는 보는 사람이 누구인지 모르고 IP정도만 공개되기 때문에 문제가 아주 심각하지는 않습니다. IP는 그래도 가끔씩 바뀌는 정보니 개인의 신원이 바로 드러나지는 않죠. 근데 만약 AD 서버에서 쿠키를 내 PC에 저장할수 있다고 합시다. 그러면 AD 서버를 운영하는 사람은 IP보다 더 정확하게 사용자에 대한 정보를 모을수 있습니다. 만일이라도 광고를 보고 그 쪽 사이트에 개인정보를 입력하여 가입하면, 사용자와 사용자가 자주가는 웹사이트, 검색하는 단어들이 그대로 유출되는거죠. 이런 정보는 돈으로 충분히 거래될수 있는 정보죠.

IE에서는 third-party 쿠키를 사용못하게 하는 방법이 옵션으로 쉽게 설정되지는 않습니다. 근데 익스플로러에서 더 걱정되는건 요즘 많이 설치되는 툴바들과 플러그인들입니다. 대부분 툴바들이 주소에 따라서 부가적인 정보를 보여주거나 하는데 이게 가능하기 위해서는 사용자가 보고있는 사이트에 대한 정보가 유출된다는거죠. 많이 쓰는 구글툴바의 page rank도 사용자 라이센스에 보면 어떤 정보가 어떻게 사용되는지 자세히 설명되어 있습니다.

위 정보는 Security Now Podcast의 Listener Feedback Q&A #12에서 언급된 내용입니다.

XP에서 (좀더) 안전하게 인터넷 서핑하기

얼마전 발생한 VGXvgx.dll exploitXSS 데모를 보면 인터넷 서핑하기 무서워지네요. IE도 문제지만 FireFox도 보안버그가 많이 발견되고 있습니다. FireFox가 안전하다고 하고, 여러가지 추가 기능들을 모듈(addon)을 통하여 설치할수 있지만… 아직 한국 사이트에서는 제약이 많습니다. IE 외의 브라우저에서는 정상적으로 보이지 않는 사이트들이 아직 많습니다. FireFox에 IE Tab을 설치하여 정상적으로 보이지 않는 페이지를 볼수는 있지만, IE로 볼때 마우스 제스처등이 안되는등 불편한 점이 많습니다. 또한 발표되는 FireFox 버그들을 보면 소스가 공개되서 그런건지 모르지만, 보안 버그들이 자주 발견됩니다.

buffer overflow에 대한 해결책으로 최근 나오는 프로세서들에서 지원하는 데이타 실행 방지(Data Execution Prevention) 기능을 사용하는 방법이 있습니다. 자세한 것은 모르겠지만, 스택 영역을 실행하려고 할때 CPU에서 이에 대한 예외(exception)을 발생시켜주는 것입니다. 많은 버퍼 오버플로우 공격이 이 기능을 통해서 막아지며 이번 dll 공격도 이 기능이 활성화 되어 있다면 영향을 받지 않았다고 합니다. DEP 기능은 XP SP2와 최신 CPU에서만 동작하며, 디폴트는 시스템과 서비스 내에서만 활성화 되어 있습니다. 모든 프로그램에서 실행되도록 변경하기 위해서는 “시스템 등록 정보-고급 탭-성능 설정-데이타 실행 방지(DEP) 탭” 에서 “데이타 실행 방지(DEP)를 …. 모든 프로그램 및 서비스에서 사용”을 선택하면됩니다. 프로그램에 따라서 예외를 등록할수도 있습니다. 옛날에 최적화가 과하게(?) 된 프로그램은 예외를 등록해야 동작되는 프로그램이 있다고 하는군요.

VMware, Parallels, Virtual PC등의 Virtualization 기술을 이용하여, Sandbox 안에서 좀더 안전하게 서핑할수 있는 방법도 있지만, 세팅하기도 힘들고 무겁습니다. 비록 쉐어웨어지만 Sandboxie라는 프로그램을 통하여 IE나 필요한 임의의 프로그램을 Sandbox 내에서 실행할수 있습니다. 라이센스는 30일간 사용 가능하며 등록비도 그리 비싸지는 않습니다. 그리고 아직 30일이 지나지 않았지만 별다른 제약은 없는거 같습니다. Sandbox에서 실행될때는 원래 하드디스크에 쓸수 없기때문에, 악의적인 코드가 실행되더라도 Sandbox 내의 드라이브만 영향을 줄수있습니다.

위에 설명한 방법으로 어느정도 공격은 막을수 있습니다. “IE 대신 XX 브라우저를 쓰면 안전하다”라는건 그냥 선전문구 정도만 될수 있고, 실질적으로 안전한 서핑을 하기 위해서는 좀더 근본적인 접근 방법이 필요할것 같습니다. 위에서 언급한 XSS 공격 데모는 정말 충격적이었습니다. 데모에서 보여진 공격들은 위에서 얘기한 공격방지 방법으로는 모두 해결되지 않습니다.

웹 클라이언트쪽의 보안 분야가 현재까지보다 앞으로 훨씬 더 많은 이슈가 발생할 것이고, 많은 공격이 시도될것이라 생각합니다. 앞으로 어떤 해결책이 나올지 지켜봐야겠네요. 지금으로서는 보안 전문가들 보다 크래커들이 한발 앞서있는 느낌입니다.