차이
문서의 선택한 두 판 사이의 차이를 보여줍니다.
다음 판 | 이전 판 | ||
tech:webshell [2013/08/24 15:45] – 새로 만듦 V_L | tech:webshell [2017/06/13 18:13] (현재) – [예방 대책] V_L | ||
---|---|---|---|
줄 1: | 줄 1: | ||
+ | {{tag> | ||
+ | ======웹쉘 (Webshell)====== | ||
+ | |||
+ | 웹쉘에 대해서 조금만 파악한다면 방화벽에서 차단이 가능하다 | ||
+ | |||
+ | |||
+ | 공격자는 몇가지 원칙을 갖고있다. | ||
+ | |||
+ | - 윈도우 서버에 주로 삽입한다. | ||
+ | - 방문자 규모가 큰 곳을 노린다. | ||
+ | - 한번 성공한 곳은 왠만해선 포기하지 않는다. | ||
+ | - 주말 낮시간에도 일한다. 공무원은 아닌 것 같다. | ||
+ | - 국내 호스팅 서버를 경유지를 이용한다. | ||
+ | |||
+ | 아웃고잉 정책도 필수다. any 정책으로 운용중이라면 | ||
+ | |||
+ | 아웃고잉포트감시를 통해 특정포트가 중국쪽으로 리슨되어 있다면 당장 차단해야 한다. | ||
+ | |||
+ | 와이어샤크(Wireshark)를 이용한 패킷분석도 가끔 해봐야 한다. | ||
+ | 좋은 결과를 얻을수 있었다. | ||
+ | |||
+ | ======Web Shell====== | ||
+ | |||
+ | Webshell은 악의적인 해커에 의해 설치되는 Web Scribt의 일종으로 자신이 관리중인 | ||
+ | Web Server에 Webshell이 설치되어 있다면 해당 Web Server는 이미 해커에 의해 | ||
+ | 해킹이 완료 되었음을 뜻하며 또한 발견된 Web Server는 해커에게 발견되어 Webshell이 | ||
+ | 업로드 될 정도의 치명적인 보안 결함이 있는 것으로 판단하여야 한다. | ||
+ | |||
+ | 이러한 취약점은 | ||
+ | 대부분 SQL Injection, 또는 upload file에 대한 관리 소흘로 인해 주로 발생되는 것으로 | ||
+ | 알려져 있지만 위 2개의 문제점 만으로 발생하는 것으로 판단하기는 힘들며, 일단 Web Server에 | ||
+ | 설치된 이후에는 해커가 원하는 거의 모든 작업을 Web Server에서 수행할 수 있다고 생각해야 한다. | ||
+ | Web code 열람, Web에 접근하는 사용자들을 대상으로 하는 악성코드배포 ( 여기서 악성코드는 | ||
+ | 해커가 원하는 모든 것들이 가능) 및 삽입, 파일 업로드, 데이터베이스 자료 유출 등 다양한 공격과 | ||
+ | 응용이 가능하여 Webshell을 통한 공격은 피해의 정도가 다른 Web Hacking과 비교가 되지 않을 | ||
+ | 정도이다. | ||
+ | |||
+ | 구버전의 Webshell들은 최근 보안 이슈였던 WAF 일명 웹방화벽으로 해결이 되지만 근래의 | ||
+ | Webshell들은 이러한 방화벽의 os명령어 또는 system 명령어 필터링 기능을 피해가기 위해 | ||
+ | 다양한 변종 명령어를 이용 변형하여 서버에 전송가능하게 하는 Webshell들도 일부 생겨나기 | ||
+ | 시작했다. (대부분 중국산) 모든 부분의 보안이 그러하듯 WebShell 역시 창과 방패의 싸움의 시작일 | ||
+ | 뿐이다. | ||
+ | |||
+ | |||
+ | 웹쉘은 공격자가 악의적인 목적을 가지고 만든 프로그램으로, | ||
+ | (ASP, PHP, JSP등)를 사용하여 제작함. | ||
+ | 일단, 공격자가 만든 웹쉘이 성공적으로 서버에 업로드가 된다면, 공격자는 자신이 서버에서 | ||
+ | 실행시키고자 하는 명령어를 전송하여, | ||
+ | 모든 제어권을 장악하고, | ||
+ | 웹쉘공격은 HTTP서비스를 통하여 통신을 하기 때문에 탐지가 매우 어려우며, | ||
+ | 서버제어 및 관리가 용이하기 때문에 흔히 사용되는 공격방법 이다. | ||
+ | |||
+ | 웹쉘 공격을 예방하기 위해서는 | ||
+ | |||
+ | - 시큐어 코딩 | ||
+ | - 취약점 패치 | ||
+ | - 키워드/ | ||
+ | - 업로드 파일의 확장자 및 실행권한 제한 | ||
+ | |||
+ | Webshell은 기본적으로 소스코드의 일종이다. 일반적인 안티 바이러스 유틸이나 웹쉘 전문 툴이라 하여 | ||
+ | 100% 차단하거나 탐지해내는 것은 불가능하다. 라는 것이 일반적인 상식이다. 이것은 웹방화벽의 기능이 | ||
+ | 아무리 좋아도 웹프로그래머의 실수 또는 미숙으로 인해 발생하는 소스코드 자체가 갖는 보안상의 취약점에 | ||
+ | 대해서는 전혀 대비 할 수 없는 것과 같은 이유이다. 가장 근본적인 부분(코드)이 해결되지 않는 이상 | ||
+ | 이러한 문제점에서 100% 자유롭다고 이야기 할 수 있는 웹서버 또는 보안장비는 없다. | ||
+ | |||
+ | telnet으로 서버에 들어간 것과 같이 스크립트를 만들고 실행시키는 것도 가능하다. 다만 웹서버가 구동중인 계정의 권한만을 갖기 때문에 파일을 만들고 실행하기 위해서는 웹서버가 실행중인 계정이 쓰기, | ||
+ | |||
+ | ASP의 Eval, Execute메소드 등은 원격에 있는 공격자로부터 웹쉘 실행코드를 전달 받아 실행 하는데 많이 이용되고 있 | ||
+ | 다. 이 같은 Eval, Execute 코드는 정상적인 스크립트 파일에도 삽입이 가능해 웹쉘 탐지가 더욱 어려워 지고 있다. | ||
+ | |||
+ | -참고 – | ||
+ | |||
+ | * Eval 메소드 : string(문자열 저장)을 자바스크립트 코드로 변환해 주는 메소드 | ||
+ | * Execute 메소드 : 질의어, SQL 문장, 프로시저 등을 실행시켜 주는 메소드 | ||
+ | |||
+ | =====예방 대책===== | ||
+ | ====웹 서버의 파일 업로드 취약점 제거==== | ||
+ | |||
+ | 파일 업로드가 불필요한 게시판의 경우는 업로드의 기능을 완전히 제거하고, | ||
+ | | ||
+ | ====파일 업로드 폴더의 실행 제한==== | ||
+ | |||
+ | 웹서버의 파일 업로드 전용 폴더를 만들고 전용 폴더의 스크립트 파일 실행을 제한하여 해당 폴더내에 있는 파일이 실행되지 않도록 해야 한다. | ||
+ | 윈도우 서버의 경우 [설정] – [제어판] – [관리도구] – [인터넷서비스관리자] 에서 마우스 오른쪽 버튼을 클릭하여 [등 | ||
+ | 록정보] – [디렉토리]를 선택해 실행권한을 ‘없음’으로 설정한다. | ||
+ | |||
+ | 리눅스의 경우 httpd.conf와 같은 웹서버 설정 파일에서 변경한다. | ||
+ | |||
+ | ====SQL Injection 방지==== | ||
+ | |||
+ | 웹쉘 공격은 파일 업로드 취약점 뿐만 아니라 SQL Injection을 이용해서도 가능 하므로 DB쿼리문에 삽입하여 사용하는 모든 경우에 이러한 필터를 적용하여 단 한 개의 페이지에서라도 SQL Injection의 허점이 존재하지 않도록 주의해야 한다. | ||
+ | |||
+ | 리눅스의 경우에는 암호화된 웹쉘을 검사하기가 까다로울 수 있는데, 이럴 경우에는 한국정보보호진흥원에서 제공하는 휘슬(Whistl: | ||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||
+ | ^ [[http:// | ||
+ | |||
+ | |||