본문 바로가기

사는 얘기/관심 이슈

나는 꼼수다에서 밝힌 선관위 디도스 공격에 대한 단상(2)

앞의 글인 나는 꼼수다에서 밝힌 선관위 디도스 공격에 대한 단상(1)에서는 로그 파일 공개 거부에 따른 나의 의견을 밝혔다. 이제 디도스 공격에 대한 내용을 얘기해보고자 한다. 이 부분에 대해서는 나는 꼼수다와 약간 다른 의견을 제시하는 부분이 있다.

나는 꼼수다에서 얘기하기로는 메인 화면 접속에는 문제가 없었는데 투표소 조회하는데는 문제가 있었다고 한다. 그래서 이 부분때문에 데이터베이스 연결에 대한 인위적인 연결을 끊었을 것이라는 추측을 한다는 것이다. 이 부분에 대해 나의 프로그래밍 지식에 따른 설명을 해보고자 한다.

앞의 글에서 나는 Java 기반 시스템이라고 가정했기 때문에 이 가정하에서 글을 쓰고자 한다. WAS가 데이터베이스와 연결을 하는 부분에 대해서는 데이터베이스 컨넥션 풀(Database Connection Pool) 이라는 것을 사용한다. 이 기술이 무엇이냐면 어떤 웹페이지가 내용을 보여주기 위해 데이터베이스에서 내용을 가져 올때 데이터베이스와 접속을 시도하게 되는데 한두사람이 아니라 여러사람이 동시에 접속을 하기때문에 그때그때 마다 연결을 생성하고 웹페이지를 보여주는 작업이 끝나면 연결을 종료하는 식으로 구현을 하면 퍼포먼스가 떨어진다. 그래서 이 부분의 퍼포먼스를 올리고자 WAS가 기동을 할때 미리 데이터베이스와의 연결을 미리 정해진 갯수만큼 연결을 해둔뒤 이것을 컨넥션 풀이란 곳에 넣어두고 웹페이지가 데이터베이스의 내용을 보여주는 작업을 진행할 때 컨넥션 풀에 있는 데이터베이스 연결해둔것을 꺼내서 사용한뒤에 웹페이지를 보여주는 작업이 끝나면 이 데이터베이스 연결해 둔것을 컨넥션 풀에 반납함으로써 다른 웹페이지가 이러한 데이터베이스 연결을 다시 재사용해줄수 있게 하는 기술이다.(이게 이해가 안되면 이렇게 생각하면 된다. 공구상자에 망치가 3개 있는데 사용자가 망치를 이용한뒤 이를 공구상자에 넣어두면 다른 사용자가 다시 망치를 꺼내 쓰는것이다. 여기서 공구 상자는 데이터베이스 컨넥션 풀, 망치는 데이터베이스와 미리 연결되어진 것, 사람은 웹페이지 라고 보면 된다. 이렇게 하면 공구상자에서 망치를 동시에 3명이 쓰지 않는 한 여러 사람이 돌아가며 망치를 쓸수 있다)

흔히 이 데이터베이스의 컨넥션풀은 웹사이트의 동시접속자를 가정해서 처음에 WAS가 기동할때 미리 만들어놓는다. 예를 들어 어떤 웹사이트의 동시접속자가 50명이라면 WAS 솔루션이 기동할때 50명이 동시에 붙을수 있기땜에 데이터베이스 컨넥션을 50개를 만들어 놓는다. 물론 이것을 차등화시킬수 있다. 즉 처음에는 20개 만들어놓고 20개가 모두 사용되면 그때그때마다 컨넥션을 하나씩 만들고 컨넥션풀에 넣음으로써 50개까지 가게 할수도 있다. 하지만 이럴 경우 퍼포먼스가 떨어지기 때문에 동시에 활성화되는 데이터베이스 컨넥션 갯수와 최개 데이터베이스 컨넥션 갯수를 같게 설정함으로써 이런 퍼포먼스 떨어지는 부분을 방지한다.

일단 디도스는 특정 페이지만 안보이게 하는 공격기법이 아니다. 디도스 공격은 웹사이트 도메인을 넣고 하는 공격이기 때문에 특정 페이지를 콕 찍어서 하는 공격은 아니다. 도메인으로 접속 시도를 하면 웹서버에 정해진 도메인의 처음 방문 페이지로 접속 시도를 하기 때문에 디도스 공격을 받았다면 처음 보는 페이지 자체를 볼수 없어야 한다.(다음을 예로 든다면 만약 다음이 디도스 공격을 받는다면 다음 메인 화면을 볼수 없어야 한다는 얘기다). 근데 선관위의 이번 공격은 메인 화면은 볼수 있었다. 이것이 디도스 공격이었다면 선관위의 메인 화면을 볼수 없었어야 하는것이 맞다. 하지만 그렇지가 않았다. 투표소 검색 페이지가 안보였다는 것이다. 이것때문에 디도스 공격이 아니라는 추측이 가능하다.

근데 여기서 나는 나는 꼼수다에서 제시한 의혹에 반론을 하나 제시할 것이 있다. 이것땜에 이글의 앞머리에서 데이터베이스 컨넥션 풀에 대해 부지런히 설명했던 것인데 만약 데이터베이스가 끊어졌다면 메인 화면에 대한 정상적인 이용을 할 수가 없다. 무슨 말이냐면 어떤 웹사이트든 메인 화면에 데이터베이스와의 연결이 일절 없는 상황은 없다. 하다못해 허접한 웹사이트를 만들때라도 데이터베이스에서 가장 최근의 공지사항 제목을 5개정도 읽어서 보여주는 기능은 있다. 만약 데이터베이스가 끊어졌다면 이것들도 보여지면 안된다. 즉 선관위 메인페이지는 뜨되 정상적으로 표현은 되지 않는다는 것이다. 그때 메인화면의 데이터베이스와의 연결까지 정상이었는지 확인할 길은 없지만 데이터베이스가 끊어진거라면 메인페이지가 정상적으로 표현되지 않는다. 근데 메인 화면은 나왔다고 하고 여기서 데이터베이스와의 연결이 정상적이어서 선관위의 공지사항 제목등을 보는데 지장이 없었다면 데이터베이스 연결은 끊어지지 않았다는 얘기가 된다. 데이터베이스와의 연결이 끊어지면 WAS의 컨넥션 풀에서 관리하는 데이터베이스 연결이 모두 끊어져버린다. 즉 10개 사용중이고 40개가 다른 사용자에게 이용되게끔 대기중인 상황이라 해도 대기중인 연결들도 모두 끊어지기때문에 그것을 받아서 사용하는 웹페이지 모두 데이터베이스와 연결이 안되버린다.

이 시점에서 나는 새로운 가정을 해본다. 데이터베이스와의 연결도 문제는 없었다. 하지만 웹페이지의 프로그램 소스를 수정해서 안보이게 할수도 있다. 흔히 데이터베이스와 연결이 끊어지면 WAS에서는 Exception이라고 하는 예외 상황을 발생시켜서 예외 상황이 발생했으니 문제를 처리하라는 식으로 통보를 하게 된다. 근데 이 Exception이라는 것을 프로그램 내부에서 자체적으로 생성해서 발생시킬수가 있다. 즉 데이터베이스를 연결하고 조회하는 로직이 있는 프로그램 코드에 그 코드 대신 예외 상황을 발생시켜 그 예외 상황을 던지는 코드로 바꿔치기를 하면 데이터베이스와의 연결은 끊어지지 않았지만 데이터베이스에서 조회 작업을 할 수 없다. 이렇게 하면 로그에서는 데이터베이스의 연결이 끊어졌다는 의미의 로그가 아니라 예외 상황 로그가 기록이 된다. 그리고 이 로그 기록은 프로그래머의 실수라고 말할 가능성이 있다. 하지만 프로그래머의 실수가 아니라면 선관위의 직접적인 개입 가능성이 있는 부분이 된다.

그래서 내 나름의 결과를 내린다면 로그를 받아서 이를 꼼꼼히 살펴야 한다는 것이다. 즉 로그 내용을 확인해보면 이게 데이터베이스 연결이 끊어졌는지 아니면 연결은 살아있는데 기타 예외 상황이 발생한건지를 확인할 수가 있다.

정말 일반인이 선관위의 WAS를 꼼꼼히 살펴야 하는 상황이 온것에 대해 개탄을 금하지 않을수 없다. 일단 한나라당 국회의원의 일개 비서가 이런 일을 꾸민다는 것이 상식적으로 말이 안된다. 그래서 경찰이 이번 발표에 대해서는 정말 꼼꼼하게 해야 한다. 이대로 발표하면 말도 안되는 내용을 말이 되니 믿어주세요라는 꼴이 된다. 이걸 누가 믿나? 이런 기술을 나름 알고 있는 나로써는 외부 해킹과 선관위의 직접 개입의 비율을 3:7로 본다

딴지 라디오