2011년 12월 20일 화요일

특정 페이지 DDoS 공격으로 DB가 죽을 수 없는 이유.

이 글은 선거당일 조회페이지를 확인하지 않고 쓴 글입니다.
그저 재미로 봐주시고 자세한 내용은 다음글의 Chapter3를 통해 확인해 주시기 바랍니다. (현재의 선관위 투표소 조회 페이지에만 적용됩니다)


바쁜 일정과 작업실 이사 덕분에 귀차니즘이 발동할 즈음하여 또다시 글을 쓰게 되었습니다.

제 글을 읽는 분들은 대부분 이길환님 @CauseSquare 이나 박현철님 @hantle 님의 주장을 이미 알고 계신다는 가정하에 글을 시작합니다.

1500대 이상의 좀비의 공격을 받았으며 그중 200여 대가 DDoS 방어장비를 뚫고 들어와 서버의 특정 페이지를 공격 하였다는 이길환님의 주장이 맞다 칩니다. (요즘 좀비는 유산균처럼 장[서버]까지 살아서 오는 특성을 가지고 있다는 가정이 필요합니다.)





DDoS 공격의 타겟 중 투표소가 가장 많은 송파구의 페이지를 캐싱없이 읽었을 때 
234.4KB의 트래픽이 발생합니다.



자... 그렇다면 이렇게 공격할 수 있는 특정 페이지의 갯수는 ?





두둥!


55개 입니다!!
응? 뭐라구???



투표소 조회를 할 수 있는 페이지에서 시.도구.시.군 을 입력하면 자신이 가야할 투표소의 위치를 목록으로 보여줍니다. 이렇게 사용자가 입력할 수 있는 경우의 수는 고작 55개 였다는 겁니다. 물론 사용자에게 보여지는 페이지 또한 55개 이며 특정 페이지를 공격할 수 있는 페이지의 숫자도 55개 정도가 되겠습니다.

이중에서 가장 큰 페이지라 여겨지는 송파구의 경우가 234.4KB 입니다.
뭐... 퉁쳐서 모든 페이지가 256KB라 칩니다.(난 쿨하니까요 +__+) 
(정리하면 장까지 살아서 돌아온 200여 좀비들이 256KB의 페이지를 무한 요청 하여 2Gb의 트래픽을 유발하는 것이 이번에 발표된 신형 DDoS 되시겠습니다.)
더이상 사족을 달지 않는 이유는 여기까지만 봐도 아시는분은 다 아신다는 겁니다.







그럼 앞서 말씀드린 55가지 경우의 수가 무었이 중요한가!!

이미 눈치채신 분들도 있겠지만. 기본적인 DB세팅이라면 55가지(결과물이 가장 큰 것이 135행) 짜리 쿼리를 매번 재실행 하지 않는다는 것입니다. 그저 메모리에 캐시해 놓고있다가 던져주는 것이 전부였을 것입니다. 서버관리자가 "우리의 서버는 캐시따위 하지 않는다", "서버는 조낸 열심히 일하는 것이 진정한 서버다!" 라는 하드코어적 비상식을 이야기 하지는 않으니까요. 물론 저런 비상식을 이야기 하는 사람을 서버관리자라 부르지도 않습니다.

결론적으로 2Gb의 트래픽을 발생시켜 DB서버를 죽이려 해도 DB서버는 열심히 일하기는 커녕 미리 해놓았던 일을 그저 한번씩 보여주고 있었다는 겁니다. 뻗고 싶어도 능력치에 10%도 사용하기 힘든 상황에 놓여 버리는 것 입니다. 이상황에 무기력함을 느껴 자살이라도 했나봅니다.









끝으로...

박현철님 께서는 DB가 그것만 하고 있느냐? 라고 반문을 하셨습니다. 

뭐... 다른것도 하지요. 공지사항을 불러와 준다거나... 로그인 기능을 위해 사용자 테이블을 조회 한다거나... 그런데 그 새벽 시간에 그렇게 많은 일을 했을까요? 게다가 DDoS 라는 녀석은 첫페이지 로딩도 하지 않고 바로 특정 페이지를 공격해 성공적으로 DB를 죽였다 주장하시는데 과연 DB가 정상적인 일처리를 얼마나 할 수 있었을까요? 했다치더라도 과연 얼마나 많은 일을 했을까요?




박현철 님께서는 자신의 블로그를 통해 "입학원서 사이트나 예매 사이트도 종종 디비가 죽는다" 라는 주장도 하십니다.

예매나 입학원서 사이트의 경우에는 Table에 입력과 조회가 동시에 일어납니다. 뭐 이를 피하기 위해 여러가지 기술을 쓰기도 하지만 관계형DB에서는 종종 Lock이 일어나 느려지거나 멈추는 경우가 발생할 수 있습니다. 심지어는 Join이 걸린 Table에 입력이 있을 경우에도 이런 경우가 발생합니다.

BUT!@
.
.
.
.
.
.
.
.
.
이쯤되면 상상에 맡기겠습니다.








라고 쓰고나니 혹시라도 모르는 분들을 위해 간단히 정리해 드립니다. 투표소 조회 페이지의 경우 그저 "조회"만을 목적으로 만들어진 페이지 입니다.
Lock이 발생할 확률은 0.0000001%도 안된다 할 수 있겠습니다.
게다가 55개의 결과물을 캐싱까지...




이글을 읽으시는 전문가 분들이라면 "이따위 기초적인 논리를 글이라고 쓰느냐!" "우리가 바보로 보이냐!"는 반응을 보이실 수 있습니다. 저도 그러한 반응에서 시작해서 쓰는 글이니까요...ㅡ,.ㅡ;;









첨삭
  1. 이 글은 자신의 주권을 행사하기 위해 새벽부터 발을 동동 구르며 투표소를 조회하신 모든 분들께 바칩니다.
  2. 위 가정은 55가지 경우를 매번 DB에 물어볼 때 일어나는 일입니다. 보통의 개발자라면 저정도 결과물은 페이지자체를 XML 방식으로 캐싱해 놓고 DB는 놀게 놔두지요.
  3. 이길환님이나 박현철님께서 자신들의 프로필에 써놓은대로 훌륭한 일들을 하시길 바랍니다. 별것도 아닌 "저 같은 것" 덕분에 지금까지 지켜오신 명예가 실추되지 않으시길...
  4. 끝까지 두서없는 글 읽어 주셔서 감사합니다.

댓글 7개:

  1. 잘 읽었어요. 올~ 전문가!

    일단 투표소조회의 경우와 대학입학 원서의 경우가 달랐죠.
    투표소조회의 경우엔 서버가 뻗지 않았다. 서버는 살아있고, 한페이지만 블럭당한 상태고, 대학입학원서는 서버자체가 다운됐죠. 그래서 우리가 투표소조회가 디도스만으로 열리지 않을 수 없다고 말하고 있는거고. 내 글에서 "해킹"이라는 말을 자주 사용하는 이길환을 지적하는 이유도 그겁니다.
    그리고 디비에서 캐싱된 자료를 조회만 하는 것과, 일반적으로 sql이 사용되는 관계형DB에 자료를 INSERT하는 것은 엄청난 부하차이가 있죠. SQL Injection 공격들이 왜 INSERT, DELETE, UPDATE 등의 commit이 필요한 공격들을 해대는 지를 생각해 보면 간단합니다.
    하아~ 이런 데이터베이스 하나만 공부해도 평생인데, 네트워크까지 뭐 모르는게 없는 "전문가"들이 왜그리 많으신지.

    전자신문 따위에서 직접 시뮬레이션까지 해보이시며 아니라고 하건만..ㅎㅎㅎ

    답글삭제
  2. 가능하면 아주 상식적인 기초 수준에서 이야기를 풀어가려 합니다. 제 능력밖의 일을 벌이지도 않을 것이고.

    그냥 쉽게 그런건 "해킹"이야 라고 이야기를 해줘도 못알아들으니... ㅎㅎ

    답글삭제
  3. 지금 디도스의 사전적(?) 의미를 바꾸려는 거에요.
    이런 참신한 노력이 우리나라에서 시작되었으니 얼마나 우리나라가 IT강국인지 새삼 느껴요...^^

    답글삭제
  4. 새롭게 쓰여지는 DDoS와 해킹의 융합에 철퇴를 가하는 자료네요. ㅎㅎ

    답글삭제
  5. 오오.. 아주 쉽게 잘 설명이 되어 있네요~~~
    일주일 후면 무릎꿇고 사과하게 될거라고 떵떵거려 놓고서는, 미루다가 막상 블로그에 올린 글은 기술적인 내용과는 관련이 없는 이상한 예나 들어놓고...

    좋은글 감사합니다.

    답글삭제
  6. 댓글 감사합니다.

    전문가라는 분들이 손발이 오그라드는 블로깅을 하시길래

    미천한 제가 몇자 적어보았습니다. >__<

    답글삭제
  7. 선관위 DB는 Oracle입니다만 버전은 아마도 10g로 알고 있습니다.
    의도를 가지고야 한다면 캐싱을 간단한 SQL 힌트추가로 회피할 수도 있긴 합니다. 캐시의 위치를 DB Memory만 한정 한다면요 또한 아무리 간단한 0.05초 수행시간의 SQL이라도 매우 간단한 SQL 수정만으로 엄청 느리게 수행하게 할 수도 있습니다. @doniikim

    답글삭제