디비커넥터의 누출에 관해.. > 자유게시판

자유게시판

디비커넥터의 누출에 관해.. 정보

일반 디비커넥터의 누출에 관해..

본문

이것은 특정 보드의 문제는 아닙니다.

아시는 분은 아시겠지만..
어떤 보드이건 DB와 연결하기위한 정보를 저장해놓고 그것을 가져다 커넥팅을 합니다.

문제는 웹이라는 특성과,  우리나라의 웹호스팅이라는 사업이 맞물려 일어날 문제입니다.
웹호스팅을 사용하는 특정 공개보드의 디비정보를 웹상에서 보지 못하게 막고있습니다만.
여러가지 편법으로 평문화 되어있는 디비정보를 획득할수 있고, 이것을 가지고 웹해킹을 하고있습니다.

근본적인 문제는 웹호스팅의 계정간 보안이 허술하다는데 있으며,
문제의 발달은 디비 패스워드와 계정패스워드가 같다는데 있으며,
더 심한것은 이것을 악용할경우 웹 호스팅의 모든 동일한 보드가 웹 해킹을 당한다는데 있습니다.

일부 상용보드에서는 이미 DB관련 정보는 바이너리화 하는식의 대책을 가지고 있으나,
공개된 보드는 아직 이러한 정보 보안에 대해서 취약한것으로 알고있습니다.

그누보드도 예외가 아닙니다.
이에 대한 토론을 해봤으면 합니다.

즉 쉽게 이야기해서,

웹호스팅을 하는곳에 그누보드를 설치하고있는데,
동일 웹호스팅을 이용하는 악의를 가진 사람이 악의 코드로써 로컬접근을 했을때  디비정보는 무방비가 되며,
이로인해 DB파괴 심지어 웹해킹을 당할수있으며,
WEB 특성상 프록시나 우회경로로 access log 자체를 무력화 시킬수있습니다.
따라서 흔적도 남지 않는다는 이야기입니다.

가장 좋은 방법은 DB접속자를  암호화 하여 저장하는 것인데..
이에 대한 알고리즘이나, 아니면 효과적인 대처 방법등 토론했으면 하는겁니다.

그러면서도 적절하게 실효성이 있어야겠지요..

여러분의 의견을 기다립니다.
추천
0

댓글 8개

그냥 가장 쉬운건 기존 정보를 젠드컴파일하는것으로도 우선 보안은 될수있을꺼 같습니다.
php로 자동 젠트시킬수있는것이 가능할런지...
유료보드는 바이너리 하는것으로 알고있습니다.
install 될때 입력받은 값을 바이너리화 시켜 암호화하고,읽어올때 복호화 하여 접속합니다.
해당 알고리즘 소스는 젠드컴파일로 압축하여버리구요..

뭐 알고리즘이라고 해봐야, 공격자가 알수없다는것 이외에는 큰매리트는 없습니다.

원래 web 특성상 정보를 숨긴다는것이 힘듭니다.
다만 보안등급을 조금더 올릴수있지 않을까 하는 생각인거죠..

Safe 모드는 현실적인 대안이 아닌듯 싶습니다.

제가 생각하는것은 암호키 생성이후 
키파괴로 생성시 1회 만들고 만든 키를 젠드컴파일 시켜 볼수없도록 만드는것입니다.

인스톨시 만들어진 고유한 유일키(uid key)로 디비 정보를 암호화 시키며,

키역시 젠드 컴파일 시키고, DB정보도 젠드컴파일 시켜버립니다.

또한 키를 읽어오는 알고리즘 역시 젠드컴파일 시켜버리면,  만든사람역시 수정할수 없습니다.

이는 영구적으로 DB연결자가 변경이 안된다는 뜻이고, 아무도 볼수 없다는 뜻이 됩니다.
(물론 젠드 디컴파일이 가능한경우 제외)

단점은 해당정보가 바끼는경우 보드를 재설치해야됩니다. (이것은 연결자를 다시생성한다는 의미가 되겠죠)


이러한 알고리즘을 적용시킬려면 인스톨시 자동으로 젠드컴파일러를 구동해야되며,
해당 키 알고리즘과, 그 키를 가지고 해석하는 알고리즘이 필요합니다.

이러한것은 이미 기존에 많이 나와있는 공개키기반의 암호 구조를 이용하면 문제가 되지 않을꺼 같은데..

주로 쓰이는 것들은 DES,ASE,PGP,RSA 정도 되겠네요 (ie에서 쓰는 뭐같은 알고리즘은 빼고)
(문닫고 살 날이 과연 올수 있으련지-_-a 유료쪽은 대체 어찌 운영되나요? 아예 소스수정한php로 돌리나요?)
여전히 safe_mode에서 출발 해야 한다는 생각을 버리진 못했지만...
궁금해 하기말고 다른수가 없으니... 홈 열린건 그냥 내비두더라도...
디비커넥터만이라도 홈에서 떼어 두었으면...

mysql.default_user NULL PHP_INI_ALL
mysql.default_password NULL PHP_INI_ALL

이걸요...
개인홈의 .htaccess 에 넣은건 어차피 다보이니 소용이 없는거구...
httpd.conf에 들어갈까요?
(여기넣은건 하나의 사용자만 가능한건지? 버쳘호스트 설정 안에 넣을수 있는건지...
 이런건 원체 해본적이 없으니 -_-;;;)
http://blog.naver.com/aram96.do?Redirect=Log&logNo=20007646077

저희쪽 테스트 서버에서 safe_mode = On 으로 약간(?)의 테스트를 해 본바 하위 디렉토리에 위치한 파일은 include 하지 못하는것으로 나타났습니다. (자신의 소유임에도 ㅡㅡa)

이 옵션을 사용하여 하위 디렉토리를 include 하지 않는다고 하여도 웹호스팅시에는 설정값을 바꾸기가 용이하지 않은게 가장 큰 문제군요.
perl 등등은 cgi 쪽에서 풀어야 할 문제라고 제껴두고...
/etc/passwd 등등도 웹서버에서 풀어야할 문제라고 역시 제껴두고...

우선 php로 사용자홈만이라도 누가 못들여다 봤으면... 소원이 없겠는데요...

safe_mode on 으로 어찌 안될까요?

무료계정만 다니다보니 safe_mode 가 on 된곳은 도저히 찾을 수 가 없어서,
직접 해보질 못하고 들은 풍월만 있는데...
화일 업로드와 세션사용하는데 문제가 있을꺼라는데...
safe_mode on 일때 이걸 도저히 해결 못하는건가요?

safe_mode 가 꺼져있고, 관련함수(fopen, cat... )를 모조리 막아 놓지 않은...
가지고 있는 계정 서너군데 모두... 같이 사용하는 사람들 홈이 훤히 보이니...

safe_mode로는 정말 못 푸는 건가요?
(이거 켜진 곳 구경이라도 해봤으면 -_-;;)
웹호스팅사에서 지원을 해주는것에는 한계가 있다고 판단됩니다.

http://blog.naver.com/jesuskth.do?Redirect=Log&logNo=20005249691

그누보드도 마찬가지로 여러가지 정보가 유출되고 있음을 확인하였습니다.

조금이라도 보안을 강화하시려면 dbconfig.php 를 다른 이름으로 바꾸신 후 index.php 의 dbconfig.php 를 바꾼 이름으로 대체하면 될것 같습니다.

여기서 조금이라도란 얘기는 100% 자신할 수 없기 때문입니다.

참고로 퍼미션 변경은 전혀 도움이 되지 않네요... ㅜㅜ
음...제 생각으론 사용자들만이 해결하기에는 다소 무리가 있는걸로 생각합니다.
문제는 웹 호스팅사에서 얼마나 적극적으로 공조해 주느냐가 문제인 것 같습니다.
DB 접속정보등을 암호화 하는 방법(혹은 바이너리 화 하는 방법)이 현재로선 가장 효율적일 수 있으나, 일반적인 암호화 알고리즘은 아시다시피 디코딩이 가능하며, 시간만 좀 투자한다면 해독이 불가능한건 아닙니다.
바이너리 방식이 더 효율적일 수 있으나, 이에 대한 알고리즘에 대한 체계(호스팅사에서 연동해줄 수 있는 기준 등)가 전혀 없다보니 사실상 힘들다고 할 수 있습니다.

저도 한 번쯤 생각해본 문제고(실은 많이도 생각했지만), 이 외에도 다른 여러 알고리즘 및 암호화에 대해 연구하고, 방법을 찾아보려 노력중이나 뚜렷한 대안이 없는 것이 좀 안타까울 뿐입니다.
그렇다고 일반 개발자가 오랜 시간을 투자해서 오라클같은 엔진이나, 독특한 알고리즘을 구현하다는 건 생활을 포기해야하는 심각한? 상황이 될 수 있으므로 거의 불가능하다고 생각되구요..

현재로선 여러가지 말은 많으나 아직 명확한 것은 아무것도 없는 것이 씁쓸할 뿐입니다..
해당 협회등에서 의견수렴을 통해 규정을 만든다든가 하면, 그에 맞게 개발하는 것은 문제가 없겠지만...
전체 45 |RSS
자유게시판 내용 검색

회원로그인

(주)에스아이알소프트 / 대표:홍석명 / (06211) 서울특별시 강남구 역삼동 707-34 한신인터밸리24 서관 1402호 / E-Mail: admin@sir.kr
사업자등록번호: 217-81-36347 / 통신판매업신고번호:2014-서울강남-02098호 / 개인정보보호책임자:김민섭(minsup@sir.kr)
© SIRSOFT