앞의 글인 나는 꼼수다에서 밝힌 선관위 디도스 공격에 대한 단상(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로 본다

딴지 라디오


트랙백을 확인할 수 있습니다

URL을 배껴둬서 트랙백을 보낼 수 있습니다

다른 카테고리의 글 목록

사는 얘기/관심 이슈 카테고리의 포스트 목록을 보여줍니다
이번 서울 시장 선거에 선관위 홈페이지와 원순닷컴이 공격을 받아 문제가 발생했었다. 원순 닷컴은 나는 꼼수다 팀에서 로그 파일을 받아 분석한 결과 디도스 공격이 맞다고 확인이 되었다. 그러나 선관위 로그는 정보공개요청에서 거부가 되었다. 정보공개거부 사유에 대해 선관위 담당자는 전화통화에서 로그에 디렉토리 경로가 노출이 되기 때문에 이를 공개할수가 없다는 것이다. 이에 대한 생각을 써보고자 한다.

갠적으로 웹프로그래머란 직업을 가지고 있다보니 이 부분에 대해 아주 문외한은 아니다. 다만 나도 모르는 부분이 있을수 있으니 이럴 경우 지적을 부탁한다. 여기서 하나 가정을 짓고 들어가본다. 일단 선관위 시스템이 무엇으로 구성되어 있는지를 알지 못해서 Java 기반 시스템이라고 가정을 하겠다.(어차피 공공기관 홈피는 대부분 Java로 구축되어있다. 왜냐면 공공기관 프로젝트일경우 행안부에서 전자정부 프레임워크로 개발을 거의 의무화하고 있기 때문에 ASP나 PHP로 구축한 시스템은 요즘 거의 찾기 힘들것이라 생각하기 때문이다)

선관위 같은 경우는 나름 규모가 있는 사이트이기 때문에 이중화도 되어 있을 것이고 L4 스위치를 이용한 분산도 되고 있을것이라고 생각한다. 내가 이제껏 9년여의 경력으로 다뤄봤던 WAS(Web Application Server) 솔루션은 Tomcat, JEUS, Weblogic이었다.(개인적으론 JEUS를 쓸것이라 생각한다. 공공기관 사이트의 경우 조달청에서 운영하는 사이트에서 상용프로그램을 구하는 편인데 JEUS가 국산이라 국산을 애용해야 한다는 논리로 이것을 주로 사용한다) 웹사이트를 개발하는 방법은 프로젝트마다 다르긴 하지만 흔히 2가지중 하나로 하는 편이다. 

1. 실제 운영 WAS 서버에 설치할 WAS와 동일한 WAS를 개발자 PC에 설치해서 개발을 한다.
2. 개발자 PC에는 비교적 가벼운 Tomcat을 설치해서 그걸로 개발을 한뒤에 그 개발 결과를 실제 운영 WAS 서버에 자신이 개발한 결과물을 셋팅한다.



암튼 개발환경에 대한 얘기를 조금 했는데 이 얘기를 하는 이유는 내가 이제껏 개발하면서 WAS 로그에 디렉토리 경로를 남기는 WAS 솔루션을 본 적이 없다는거다. 정확하게는 완전한 절대경로를 얘기하는 것이다. 예를 들어 Tomcat을 예로 든다면 만약 Tomcat이 C:\Tomcat에 설치되어 있고 로그에서 표현해야 할 디렉토리와 파일이 C\Tomcat\log\log1234.log이 있다면 로그파일에 C\Tomcat\log\log1234.log 이렇게 표현하지 않는다는거다. 표현을 한다면 Tomcat 솔루션을 사용하고 있고 이 솔루션이 설치된 위치를 로그 파일을 보는 사람 입장에서는 Tomcat이 설치된 디렉토리를 알고 있기 땜에 \log\log1234.log  이런식으로 표현한다. 이거 노출된다고 무슨 해킹에 악용이 되는것인지 안맞는다. 표현되는 경로는 상대경로인데..

물론 선관위 홈페이지가 운영되는 과정에서 로그 파일이 만들어지고 이걸 보면서 운영된다. 하지만 정부기관 웹사이트 구축의 경우는 프레임워크(정확하게는 전자정부 프레임워크) 기반에서 웹사이트가 설계되고 만들어지기 때문에 선관위 운영을 위해 로그파일을 만들어야 한다면 WAS 솔루션이 솔루션 자체의 관리를 위해 기록되는 로그 파일이 아닌 별도의 로그 파일에 기록을 한다. 그리고 이것을 정보공개요청에서 달라고 하는 것은 아니다. 왜냐면 디도스 공격과 관련된 내용은 앞에서 말한 WAS 솔루션 자체의 관리를 위해 기록되는 로그 파일에 기록되는 것이지 업무때문에 필요한 성격의 로그파일에 기록되지 않기 때문이다. 그런데도 안주고 있다. 그래서 개인적인 결론을 한번 내려 본다면 현재 내세우고 있는 선관위 로그 파일 공개 거부는 말이 안되는 것이라고 본다.


트랙백을 확인할 수 있습니다

URL을 배껴둬서 트랙백을 보낼 수 있습니다

다른 카테고리의 글 목록

사는 얘기/관심 이슈 카테고리의 포스트 목록을 보여줍니다
갠적으로 Spring Framework(스프링 이라 하겠다)를 시작한지는 정말 얼마 안되었다..아니..정확하게는 스프링을 사용하는 프로젝트를 해본 케이스가 딱 한번뿐이었다. 전자정부 프레임워크로 진행했던 프로젝트였는데 전자정부 프레임워크가 스프링 기반이었다.

스프링을 하기 시작한 계기는 프리로 처음 전향하면서 면접을 본 과정이었다. 집이 안양이었던 관계로 마침 평촌에서 진행하는 프로젝트에 지원을 하게 되었다 그래서 면접을 보았는데..기억하기로는 그 프로젝트가 SK C&C에서 만든 프레임워크 기반으로 하는 프로젝트였다.
그 당시에 난 프레임워크의 필요성에 대해선 공감하고 있었지만 그것을 실무에 적용하는 점에 있어서는 약간의 회의적인 시각이 있었다. 유지보수 차원에서는 프레임워크를 적용한 프로젝트가 훨씬 유용하지만 우리나라 프로젝트 성격상 유지보수보단 얼마나 빨리 제작하는 것이었냐였고 그 점에 있어서 프레임워크 기반의 프로젝트는 기존의 Model1 방식의 개발 방법보다는 개발속도가 현저하게 떨어지기 때문이었다. 나 같은 경우는 그런점을 최대한 극복하고자 최대한 클래스로 빼서 유지보수를 극대화하고자 했지만 결국 Model1 방식을 벗어나지는 못했다.
암튼 그때의 내가 프레임워크를 써본것은 Struts 뿐이었고 그것도 1~2개 프로젝트에서만이었다. 당연 면접관은 그런 나의 이력을 보고 Spring을 잘 할수 있겠냐..는 질문을 했고 난 어차피 이력에 있는거니 거짓말은 할수 없어서(또 경력을 가지고 거짓말을 하고 싶은 생각도 없다) Spring 경력은 없지만 프레임워크 적응은 잘 할수 있다(실제로 새로운 프레임워크 적응은 잘하는 편이다. 몇몇 샘플만 보면 가닥을 바로 잡고 나머지 부분은 내가 사비를 들여서라도 책을 사서 찾아보는 성격이다)라고 면접관에게 말을 했다. 하지만 결과는 떨어지고 말았다.

이런 결과를 보고 난 나를 떨어뜨린 면접관보다는 내 자신에게 분한 맘이 들었다. 그리고 한편으로 오기가 생겼다. 그래? 그럼 스프링 까짓거 정복하겠다. 그래서 책을 두권하고 열심히 책의 샘플들을 직접 코딩하며 적응해갔다. 그래서 외워서는 아니더라도 책을 보면 따라갈수 있을 정도로까지 진행되었을때 전자정부 프레임워크 기반 프로젝트 면접을 진행했고 거기에 합격되어서 4개월간 프로젝트에 참여했다. 그 프로젝트에서 몇가지 알은 것들이 있다. Maven과 Hudson인데 그 당시엔 이것에 대해 활용하는 입장이어서 셋팅을 하는 그런것은 몰랐다. 하지만 활용하면서 이것도 공부하고 알아야겠다 하는 생각이 들었고 프로젝트 종료하자마자 전자정부 프레임워크 교육을 4일간 받으면서 좀더 공부하게 되었다.

프로젝트가 끝나고 새로운 프로젝트를 구하는 동안 집 부근 도서관에 노트북을 들고 댕기면서 스프링을 좀더 공부했고 이젠 파일 업로드 기능이 있는 질문/답변 게시판의 기초적인 형태까지 다 잡아놓았다. 이것도 하면서 ajax를 활용하는 파일 업로드도 해보고 그러면서 파일 업로드 진행 현황도 같이 보여줄수 있게끔도 제작하게 되었다. 특별한 형태가 아니라면 대부분의 웹페이지는 게시판 유형이니까..그리고 요즘은 Spring Security를 이용한 웹사이트의 보안적용을 진행하고 있다.

지금 생각해보면 개발 시간이 오래 걸린다는 의견을 가지고 있었던 것도 점점 고쳐가고 있다. 분명 개발시간이 Model1 방식보다는 오래걸리지만 그렇다고 그렇게 많이 차이가 나는 것은 아니다. 차이가 나는 부분을 차후의 쉬운 유지보수를 위한 희생..이라고 생각하면 감내못할 부분이 아니다. 스프링에 대해 회의적인 시각이 있다면 일단 한번 진행해봤음 한다. 해보지 않은 것에 대해 추측성의 부정적인 시각을 가지고 있다면 그것은 알게 모르게 나의 고정관념이 되어서 계속 피하게 되는 것이다. 이 글을 보는 스프링에 대해 회의적인 시각을 가지고 있는 자바 프로그래머가 있다면 게시판 만들기 프로젝트를 해봤음 한다. 단순히 게시판 만들기를 할 것이 아니라 게시판 기능이 완성되면 살을 하나하나 덧붙여가면서 프로젝트를 점점 확장해가면서 적응해보면 스프링에 대해 한결 이해하기 쉬워지리라 본다

Spring Framework

트랙백을 확인할 수 있습니다

URL을 배껴둬서 트랙백을 보낼 수 있습니다

다른 카테고리의 글 목록

프로그래밍/Spring 카테고리의 포스트 목록을 보여줍니다

티스토리 시작..

2011.11.28 00:32

직업이 프로그래머다보니..업무때문에 구글링을 하는 상황이 많이 발생한다..
그래서 사람들이 올린 자료를 보다보면..다들 개인적으로 구한 자료나 자신이 작성한 글들을 티스토리에 올려서 활용하는 경우를 많이 보게 된다..
예전에 티스토리에 대해 이름은 들어봤지만..구체적인 활용을 할 생각은 하질 않았는데..
사람들이 활용하는 것을 보고 욕심이 나서 시작해보기로 했다..
처음이다보니..아직은 헤메는 부분들이 있다..
복잡한 부분이 많지만 하나하나 해결해봐야 할듯 싶다..

이제..시작이다..

트랙백을 확인할 수 있습니다

URL을 배껴둬서 트랙백을 보낼 수 있습니다

다른 카테고리의 글 목록

사는 얘기/나의 흔적 카테고리의 포스트 목록을 보여줍니다