트랙백은 개별 블로그 시스템에 맞게 커스터마이징하기 매우 곤란한 개념입니다. 트랙백은 프로토콜입니다. 서로간에 특정한 입력값(블로그명,주소,제목,내용,요약 정도)을 지정된 트랙백주소로 전송하기만 하면, 바로 접수가 되는게 약속된 행동입니다.

코멘트입력 시스템에선, 스팸봇을 막기 위해 여분의 더미입력필드를 자기 마음대로 삽입할 수도 있고, 숫자코드 입력을 별도로 요구할 수도 있습니다만, 트랙백에선 이런게 허용되질 않기 때문에, 스팸봇을 만드는 입장에선 참으로 편리한 도구인 반면, 블로거 입장에선 일종의 무방비 상태라고도 볼 수 있습니다.

현재까지 트랙백 스팸에 대한 알려진 대처방안을 간단히 살펴보면,

• Trackback Modulation의 도입 - 즉 트랙백도 핑받는 즉시 엔트리에 반영하지 않고, 블로거가 나중에 별도의 승인을 줘야 엔트리에 나타나게 하는 방식. 현재 무버블타입의 경우 코멘팅시스템에 이것이 도입되어 있고, 많은 사용자들이 트랙백에 대해서도 모듈레이션을 할 수 있도록 요구하는 실정.
   
  단점은, 일일이 승인해주는 것도 쉽지 않다는 것. 결국 왕창 몰려온 트랙백을 삭제하는 노력이나 승인 거부/허용을 해주는 노력이나 오십보 백보. 단지, 보여지는 것에만 의미를 둘 정도랄까..
• Blacklist 방식(MT-Blacklist) - 코멘트스팸과 마찬가지로, 스팸을 보내는 특정 IP를 데이터베이스화해 공유함으로써 전성된 트랙백의 IP를 체크해서, 스팸여부를 거름.
   
  단점 - 스패머들이 생각보다 똑똑함. IP변경/프락시이용 등으로 발빠르게 대처함. 고로 블랙리스트만으로 막기엔 좀 역부족.
• Filtering  방식(MT-Bayesian) - 비슷비숫한 개념이지만, IP같은 유동적 개념으로 막는 것이 아니라, 전송되어온 트랙백의 내용에 의해 스팸여부를 판단. sex, casino, 등등의 단어를 계속 추가해줌에 따라 점점 똑똑해(?) 지게 하는 방식.
   
  단점 - 딱히 단점이랄꺼 없다 보이고, 단지 한번 습격을 받은 후에 사후적으로 해당 내용을 입력하게 된다는 것과, 선의의 내용과 혼동으로 막는 경우도 생김.
• 전송한 IP와 트랙백 URL 비교 방식(MT-TrackbackAntiSpam) - 대부분의 스팸봇이 실제 선전하고자 하는 사이트 주소에서 직접 핑하는게 아니라, 자신의 피씨상에서 혹은 프락시서버등을 거쳐 보내는 현실에 착안. 아무리 보내는 주소를 이리 저리 옮겨도(Blacklist 속이기 위해) 결국엔 선전하는 URL과 일치하지 않을 가능성이 크므로 스팸여부 가리는 좋은 아이디어라 봄.
   
  단점 - IP는 핑할때 프로그램적으로 속일수도 있음. 이보다는, 정상적인 사용자의 핑조차도 스팸으로 인지할 가능성이 더 큰 단점. 예를 들어, 피씨상의 블로깅툴을 이용해 트랙백을 날리거나, 프락시를 거치는 회사 등에서 보낼 경우, 혹은 모바일장치에서 보낼 경우 등 비교적 정상적인 사용자도 스팸으로 인지될 가능성이 다분함.
• 트랙백 주소 자체를 알기 어렵게 만드는 방식(MTDisguiseTrackbackURL) - 원초적으로 스팸봇이 스팸을 보낼려면, 당근 트랙백주소를 알아야하는데 이를 스팸봇이 알기 어렵게 만들어서 엔트리에 삽입하는 방식.
   
  단점 - 스팸봇이 알기 어렵게 만드는 것일 뿐, 알기 불가능하게 하는 것이 아님. 고로 편집증적인 스팸봇 프로그래머라면 이론적으로 역알고리즘을 프로그래밍할 수도 있음.

1. 트랙백 스팸봇의 트랙백 주소 수집 및 작동 방식

적을 알아야 대책도 강구될 수 있겠죠. 그런 의미에서 트랙백스팸봇의 수집/작동방식을 간단히 살펴 봅니다.
무버블타입툴을 만든 SixApart사에서 정한 트랙백 Specification을 보면, 트랙백주소는 단지,
트랙백 CGI주소 + 트랙백아이디 와 같은 형식이면 됩니다.일반적으로 생각할 수 있는 가장 심플하면서도 정형적인 형식일 겁니다. 고로 스팸봇의 입장에선 두가지만 알면 됩니다.

바로 트랙백 CGI 까지의 고정적인 주소와 트랙백아이디(유동적 체계)입니다. 제가 본 거의 대부분의 블로그시스템이 이 트랙백 아이디를 숫자형식(주로 엔트리아이디의 증가와 비례하는...) 나타내고 있습니다. 이 트랙백 ID가 숫자로 대부분 표시되는 것은, 결코 트랙백 스펙에 따른 결과가 아니라, 단지 자신의 블로그시스템 내에서 임의로 다른 트랙백 ID와 겹치지 않고 유일무이하게 붙일 수 있는 매우 간단한 방법이기 때문입니다. 그래서 스팸봇은 한 블로그 사이트상의 엔트리 페이지를 여기저기 뒤집고 다닐 필요가 없습니다. 어떤 방식으로든 한 곳에서 그곳의 CGI주소만 알면 이후엔 빠져나온후 로직으로 보내는 방식입니다.

엠티의 경우 그냥 1부터 차례로 증가하면서 트랙백 아이디가 정해집니다만, 다른 블로그틀도 그 초기값이나 증가값은 달라도 유사하리라 봅니다. 고로 스팸봇 프로그래머에게 아이디는 큰 문제가 안됩니다. CGI주소를 알아내기만 하면, 아래와 같은 루틴으로 마구 보낼 것입니다.

for( i= 50; i<500; i+5) {
   result = ping(CGI주소+i);
   if(result is OK) {
      for(j=1; j< 50; j++) {
        ping(CGI주소+i);
        sleep(time); 이건 같은 곳에서 여러번 보내는걸 막는 장치를 가진 블로그를 피하는 겁니다.
      }
   }
}

보통 블로그를 만들면 테스트삼아 엔트리를 만들어 여기저기 테스트로 보내고 또 받은 후에, 그 연습 엔트리는 삭제하는 경우가 많기 때문에 아이디 초기치를 1부터 안하고 적당한 값부터 시작하고 듬성듬성 5정도로 증가시켜서 핑을 보내봅니다. 그 결과로 넘어온 XML이 성공적인 값이 나오면, 그 트랙백주소를 가진 엔트리에 위의 경우 50개를 보내는 군요.

트랙백스팸이던 코멘트스펨이던 한 페이지에 수십개씩 붙는 이유는, 어렵게(?) 찾아 냈기때문에 본전을 뽑겠다는 심보에서 입니다.

그럼 CGI주소는 어떻게 알까요? 아마도 CGI주소 수집기는 시작을 블로그메타사이트에서 출발할 것입니다. 잘 알려진 메타사이트에 시시각각 올라오는 블로그의 새로운 글의 링크를 받아서, 그 해당 페이지를 받습니다. 재수가 좋으면, 페이지 내에 트랙백 데이터가 메타데이터 형식으로 파싱해서 알기 쉽게 박혀 있을 가능성이 클겁니다.

무버블타입의 경우, Bookmarklet 혹은 QuickPost라는 방식을 통해, 다른 블로거의 글에서 쉽게 트랙백을 보내는 자신의 글을 쓸 수 있는 툴이 있는데(다른 툴도 있겠죠) 이때 그 페이지의 트랙백주소를 쉽게 파싱해서 알아내기 위해 엠티는 <MTTrackbackData>라는 태그를 통해 RDF형식의 메타데이터를 페이지에 박습니다. 여기에 트랙백 주소가 잘 나타납니다. 만약 이런 정형화된 메타데이터가 없는 페이지에선 스팸봇이 주소를 찾기가 그리 만만챦을겁니다. 파싱 루틴이 복잡다단해질 수 밖에 없죠.

결국 블로거들이 쉽게 트랙백을 보낼 수 있도록 만든 RDF데이터가 실제로 블로거들이 트랙백을 걸 엔트리를 작성시엔 잘 이용하지 않는데(개인적인 추측입니다만, 상대적으로 좁은 에디팅 칸 등의 문제로 그냥 트랙백 주소만 카피한후에 자신의 블로그나 블로깅툴에서 작성해서 트랙백을 보내는게 더 일반적이지 않나요?)비해, 스팸봇이 주소수집을 편하게 파싱하기 위한 도구로 사용되고 있다는게 제 생각입니다.

어쨋든 이렇게 RDF태그내에서 쉽게 임의의 페이지의 트랙백 주소를 몇몇 블로그 시스템의 트랙백주소생간 패턴에 의해 그곳의 블로그툴을 판별하고 그에 맞게 트랙백아이디를 증가혹은 감소시켜서 대량 전송하는 방식인것입니다.

2. MTDiguiseTrackbackURL 방식

이런 스팸봇의 작동방식을 보면, 일단 주소를 수집하는 로봇이 쉽게 파악하지 못하게(단 사람인 블로거는 눈에 나타나는 대로 파악하기 쉬운) 주소를 표현만 해주면, 떨거지 스팸을 크게 차단할 수 있다는 아이디어가 나옵니다. 문제는 어떻게냐죠.

이때 주소를 스팸봇이 알기 어렵다는 것이 어떤 의민지 잠시 설명합니다. 결과적으로 어떻게 어렵게 표현하던 이는 완벽한 암호화방식은 아닙니다. 정상적인 블로거가 의식하지 않고 보낼수 있어야 하기때문입니다. 예를 들어 위에서 소개한 MTDisguiseTrackbackURL 플럭인의 경우엔 http: / /blog.com/tb.cgi/1234를 자바스크립트를 이용해서 화면에 찍어주는 방식입니다. document.write('http: / /blog.com/'); document.write('tb.cgi'); document.write('/1234');

화면에는 정상적인 주소로 나타나지만 소스내에선 한번에 파악은 어렵게 하는 방식입니다. 그럼 과연 이방식은 스팸봇이 CGI주소를 프로그램 로직상으로 알아내는게 불가능할까요?

당근, 가능합니다. 그것도 위 경우에만 특화해보자면, 비교적 간단히 말입니다. 근데 중요한것은 대부분의 스팸봇은 저정도를 파싱하는 노력을 하지 않는다는 것입니다. 이것은 순전히 "현실적"인 고려에서 입니다. 만약 엠티사용자의 많은수가 저 루틴을 이용하는 시점에선, 스팸봇도 적응해서 저걸 파싱하고 조합해서 숨은 CGI를 찾아낼 것입니다. 하지만 지금은 그런 쓸데없는 데 PU/시간 낭비를 하지 않습니다. 왜? 이건 해킹이 아닙니다. 어떤 방지 틴을 사용한 곳에 스팸을 누가 많이 보내나 시합하는게 아니라, 얼마나 정해진 시간에 많은 블로그에 자신의 선전주소를 박아서, 검색엔진 랭킹을 팍팍 올리느냐가 목적인것입니다. 고로 현 블로그에서 디폴트 방식으로 파악하지 못했다면, 다른 대책없는 블로그로 이동합니다. 적어도 이런 방비책이 일반화되지 않은 시점동안엔 말이죠.

그렇게 볼때, 위 MTDisguiseTrackbackURL은 만족할만한 하기도 하면서, 동시에 좀 허술하기도 합니다. 왜냐면 당장에 효과는 볼 수 있겠지만, 그 방식이 너무 심플해서 스팸봇이 마음만 먹으면 손쉽게 파악해버릴수 있는 방식이기에, 머지 않는 후에 다시 새론 방식을 채택하는 번거로움을 맛볼 각오를 해야한다는 것입니다.

또하나 MTDisguiseTrackbackURL이 간과하고 있는것은, 스팸봇이 무질서한 엔트리 페이지에서 단순히 cgi같은 몇몇 키워드로 트랙백주소를 찾는, 모래사장에서 바늘찾기 방식으로 하는게 아니라, 위에서 말한 RDF로 표현된 메타태그값에서 손쉽게 얻어낸다는 것입니다. 고로 이 방식을 사용하기 위해선, RDF 트랙백 데이터를 심으면 안되는 것입니다. 물론 그 태그를 제거하게 하거나, 설정에서 AutoDiscover 기능을 끄도록 권해도 되지만, 플럭인 자체적으로 그런 설정을 미처 못했어도, 관련 데이터를 찍지 않게 해줘야 한다는 것입니다.

혹 엠티를 사용하시는 분들은 자신의 페이지 소스를 한번 보십시요. RDF 로 표현된 트랙백 정보가 보기좋게 박혀 있습니까? 그 데이터는 실제 트랙백을 보내고자 하는 블로거를 돕기 위한 목적이지만, 현실적으로는 그보단 스팸봇을 도와주고 있으니... 알아서 하십시요.
<!--
<rdf:RDF xmlns:rdf="http:/ /www.w3.org/1999/02/22-rdf-syntax-ns#"
         xmlns:trackback="트랙백 주소"
         xmlns:dc="http:/ /purl.org/dc/elements/1.1/">
<rdf:Description
    rdf:about="엔트리 주소"
    trackback:ping="트랙백 주소"
    dc:title="엔트리 제목"
  dc:identifier=""
    dc:subject=""
    dc:description="요약"
    dc:creator="저자"
    dc:date="글쓴 날짜 />
</rdf:RDF>
-->

이 메타데이터만 지워도 한결 스팸이 줄 것입니다. 무버블타입의 경우 Individual Entry Archive 템플릿에서 <MTEntryTrackbackData>테그가 이 값을 찍는데, 직접 해당 태그 삭제보단, 웹설정 메뉴의 Preference에서 Enable TrackBack Auto-Discovery를 꺼주면 됩니다. 물론 이걸 꺼주면, 향후 자신의 엔트리 페이지 상에서 직접 북마클릿이나 퀵포스트로 글을 써서 별도의 트랙백주소 입력없이 보내고자 하는 경우에 이를 사용하지 못하는 불편은 있습니다.

3. 무버블타입용 TCode플럭인 방식 설명

제가 무버블타입용으로 만든 이 안티스팸 플럭인 TCode도 주소를 흐트리는(Obfuscate)하는 방식입니다. 물론 단순히 주소를 흐트리는 표면적인 방식 외에(CGI주소 습득을 어렵게 하는 목적), CGI를 알았다 하더라도 트랙백주소자체를 위와 같이 단순한 증가방식으로 trial-and-error 방식으로 알기 어렵도록 했습니다.

이 글의 왼편에 있는 트랙백 주소 Copy 버튼을 누리면, 제 트랙백아이디가 좀 독특함을 알 수 있습니다. 예를 들면, http: / /alogblog.com/tb.cgi/1234.567890 머 이런 식으로 소수점으로 표현되어 있고 또 꽤 긴 숫자열입니다.

이걸 스팸봇이 위와 같은 루프문으로 텀을 두고 증가시킨다 해도 맞출수 있을까요? 아마 로또 100번 당첨되길 기대하는게 빠를 겁니다.(물론 루프돌리는 시간으로야 그리 긴 시간이 아닐 수 있지만, 문제는 한번의 루프때마다 http 리퀘스트를 보내고 결과를 받아야 한다는 점입니다.)

이때 소수점 앞의 숫자는 기존의 트랙백 아이디입니다. 뒤의 숫자는 해당 엔트리 고유의 산출된 값입니다. 고로 별도의 파싱없이 아이디를 루프를 통한 증분으로 보내는 경우 날쌥니다.

이게 1차적 방어입니다. 기존의 끽해야 3-4자리인 트랙백 아이디를 좀더 무질서하게 숫자도 키우고 랜덤성도 부가하는 방식으로, 파싱을 하지않고(실제 파싱은 그들에겐 가장 비싼 프로세스입니다.) 아이디 유추에 의한 루프방식으로 보내는 놈들은 걸러 집니다.

2차적으로는 자바스크립트로 된 Obfuscator를 이용해 트랙백 주소자체를 알고리즘으로 역으로 알기 어렵게 만들어 삽입한다는 것입니다. 이 페이지의 소스를 통해 이 글의 트랙백 주소를 볼라치면, 왠 복잡한 자바스크립트문만 보실 수 있습니다. 이 TCode에서 사용된 방식은 http://www.jottings.com/obfuscator/ 에서 제공한,Email주소를 스팸봇의 수집으로 부터 보호하기 위한 자바스크립트입니다.

이 방식이 얼마나 역알고리즘으로부터 강한지는 이론적으로 모르나, 제가 찾아본 이메일 Obfuscator 중에선 가장 진일보한 것이 아닌가...순전히 개인적으로 판단하고 있습니다. (다시 한번 말씀드리는 것은 이 Obfuscator라는 것은 비밀키 혹은 공개키를 이용한 고도의 암호화가 아닙니다.)

3차적인 방어도 있지만 이는 옵션입니다. 바로 코멘트스팸을 방지하기 위한 SCode에서 사용하는 방법을 마지막으로 포함시켰습니다. SCode를 만든 james seng 에게 트랙백 지책도 많은 분들이 요구하셨습니다만, 이에 대해 나온 것은 SCode처럼 어떤 값을 직접 입력하지 않고 위에서 이미 말한 IP와 URL을 비교하는 방식입니다. 왜 그럴까요? 바로 기존의 트랙백 체계로는 사용자가 특별히 별도의 값을 입력할 여지가 없기 때문입니다.

제가 이 방법을 넣은 건, 만약 언젠가(?) 이 Obfuscator에 의한 역 아이디 산출방식이 어떤 편집광에 의해 풀렸을 경우, 한번더 버텨보자는 생각에서입니다.

즉 12.0123456789 라는 트랙백 아이디에서 뒤의 네자리를 제외한 주소부분만 Obfuscator를 이용해 표현하고 끝 네자리는 이미지로 나타냅니다. 그럼, 위 Obfuscator알고리즘을 깨서, 앞 부분의 주소를 알아내도 여전히 숫자로 표현된 4자리는 다시 루프에 의한 추측에 의존해야 합니다. 욜라 타임컨슈밍한 작업이 아닐 수 없습니다. 제가 스팸봇이라면, 에이 18이럼서 딴데 알아볼겁니다.