mix1009.net

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 등이 들어가지 않게하는게 좋을거 같네요.

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

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

최근에 제가 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 플러그인을 제작하면 좋을것 같네요. 찾아보니 없는거 같네요. 그리고 트랙백 받을때도 어떻게 활용할 방법이 없을까하는 생각도 드네요. 가끔 트래백으로 스팸성 댓글이 많이 달리거든요.

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

자세한 내용은 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 파일에 다음 라인을 삽입하고


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_recipent_restrictions 원래 설정된 항목에서 reject_rbl_client들만 원하는 위치에 등록하면 됩니다. 위에서부터 순차적으로 처리하므로 위치는 원하는 위치에 두시면 됩니다.

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

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에서 언급된 내용입니다.