태터데스크 관리자

도움말
닫기
적용하기   첫페이지 만들기

태터데스크 메시지

저장하였습니다.

보안사고사례 (4)


또 한건의 대형 개인정보 유출사고가 발생했다. 그런데 해도 해도 너무한다. 이렇게 쉬운 방법으로 거대 통신사의 고객지원 웹사이트가 뚫리다니.... 지금껏 얼마나 많은 해커가 이 통신사의 개인정보를 무단으로 해킹해 유출시켰을지 모른다고 생각하니 참 한심하다 못해 어이가 없다. KT는 보안사고로 개인정보가 유출된 뒤 채 2년도 안돼 또 초대형 개인정보유출사고의 주범이 되는 불명예를 뒤집어 쓰게 되었다.


지금 KT 올레닷컴 사이트의 요금조회 페이지는 굳게 걸어닫혀 있다. 물론 죄송하단 안내 페이지는 열려있다.




굳게 닫혀있는 요금조회 및 개인정보 조회 페이지..



사실 KT 홈페이지가 해킹을 당해 1200만건의 개인정보가 유출되었다고 해서 "설마 올레 닷컴" 웹페이지일까 싶었다. 올레닷컴은 사실상 전국민이 사용하는 요금조회 및 개인정보 조회가 가능한 웹사이트다. 거의 전국민이 사용자다. KT는 유선과 무선의 통신서비스를 하고 있고 유선과 무선의 모든 고객과의 대화창구가 바로 "올레 닷컴"이다. 


그런데 올레 닷컴에 접속해 보니 단번에 "아.. 올레 닷컴이 뚫렸구나.."라는걸 알 수 있었다. 아래의 메뉴들은 모두 접속이 불가능했다.




그렇다면 해커는 어떤 방법으로 올레닷컴에 접속해서 개인정보를 빼내간 것일까..??


경찰에서 발표한 바에 의하면 그 방법은 다음과 같다고 설명하고 있다.



해커들은 파로스 (Paros)라는 프로그램을 이용했다고 한다. 내 눈을 의심했다. paros는 웹 개발자들이 즐겨 사용하는 디버깅 도구이다. 그리고 이 디버깅 도구인 파로스를 이용해 "웹 브라우저에서 웹서버로 전송되는 데이터는 변조가 가능하다"라는 웹 취약점에 대한 공격 방법은 초보 개발자들도 알고 있는 "상식"이기 때문이다.


설마 KT가 그렇게 초보적인 공격에 조차 무방비인 상태로 올레닷컴 웹사이트를 그 오랜 시간동안 운영해 왔다는 말인가?

한심하다 못해 어이가 없어 할말을 잃을 지경이었다. 도대체 몇년 전 보안사고로 인해 새로 투자한 그 많은 돈은 어디로 갔단 말인가?  송소희양을 불러 "어이~없~소~~오~~ 어이~없~소~~~~"를 외치게 하고 싶다.


일부 언론에서 paros를 마치 강력한 해킹툴인 것 처럼 소개하고 있지만 paros는 주방도구인 "칼"과 같은 도구다. 개발에 사용하면 훌륭한 디버깅 도구로서 개발자들의 필수 소프트웨어이고 해킹에 사용하면 해킹을 도와주는 도구가 되는 "그냥 프로그램"일 뿐이다. 


어찌됐든 Paros를 이용하여 해킹을 시도한 과정을 도식화 하면 다음과 같다.



해커의 해킹 과정을 위의 그림을 기준으로 설명하면 다음과 같다.


1. 해커는 올레 닷컴에 로그인 한다. 이때도 물론 남의 계정을 쓰지 않았을까 싶다.


2. 요금조회 및 개인정보 조회 페이지에서 로그인한 계정의 정보를 조회한다.


3. 해커는 미리 paros를 동작 시켜 웹브라우저에서 KT의 서버로 가는 요청(Request)을 가로채도록 설정(proxy)하고 paros에서 요청 (http request (get or post))을 가로채 요청 내에 있는 고객번호를 엉뚱한 고객번호로 변조한다. 경찰에 의하면 이 고객번호는 9자리의 번호로서 해커들은 무작위로 변조해 응답이 오는지를 확인했다고 한다.


4. paros에서 변조된 고객번호는 KT 서버로 넘어가 DB 에서 조회된다.


5. 응답은 웹브라우저로 전송된다. 이때 로그인한 고객 계정의 정보가 아니라 해커가 paros에서 변조한 고객번호의 정보다. 즉 피해자의 이름, 전화번호, 계좌번호 등이 되겠다.


6. 해커는 이과정을 자동화하는 간단한 프로그램을 작성해 매일 수만에서 수십만건씩 개인정보를 빼냈다.


사실 이런 방식의 해킹은 서버보안 관련 업무를 하고 있는 나로서도 참 난감할 수 밖에 없다. 웹페이지와 서버에서 구동되는 응용프로그램 소스코드 상의 취약성을 이용해 서버내의 파일이나 명령 등을 조작하지 않고 정삭적인 경로를 통해 정보만 빼내는 기법이기에 어찌할 도리가 없는 것이다. 서버보안 뿐만 아니다. 이러한 공격은 방화벽, 침입탐지시스템, DB보안솔루션, 웹 방화벽 등 다양한 보안장비를 갖추고 있어도 막을 도리가 없는 것이 현실이다. KT가 이런 보안 시스템을 도입하여 운영하고 있지 않았겠는가..?? (서버보안은 없는 걸로 알고 있지만...&nbs


해법은 개발자들이 시큐어코딩을 생활화 하는 것이다.


이런 공격에 대한 대응 방법은 웹페이지와 서버측의 조회 애플리케이션 소스 내부적으로 취약성을 제거하는 방법 밖에는 없는 것이 현실이다. 그래서 많은 보안 관련 단체나 정부 기관에서는 개발자들이 준수해야할 여러 프로그래밍 보안 기준들을 제시하고 있다.


그것이 바로 Secure Coding 이다. 여러 검색엔진에서 "시큐어코딩" 혹은 "secure coding"을 검색해 보면 다양한 자료들이 쏟아져나온다. 


그리고 이미 정부에서는 시큐어코딩의 중요성을 인지하고 수년전부터 관련 컨퍼런스를 개최하는 등 방안 등을 수립하고 자체적으로 시큐어코딩 가이드 등을 제시하고 있다. 이와 관련하여 정리가 비교적 잘되어있는 블로그를 소개한다. (관련 링크)




2014년 1월 또 한번의 초 대형 보안사고가 발생했다. 이번엔 신용카드사에서 보유하고 있는 신용카드 발급 고객의 개인신상정보와 신용등급, 결제계좌정보 등의 비교적 고급정보 그리고 심지어 일부 고객의 경우 카드번호와 발급일자까지 유출된 것으로 보인다.


내 경우도 다음과 같이 "나도 알지 못하는" 나에 대한 정보가 유출되었다고 나온다. 과연 계속 이 금융사를 "주거래" 은행과 카드사로 이용해야할지를 심각하게 고민하게 만든다.





본격적으로 카드3사의 개인정보 유출사고를 살펴보기 전에 과거의 개인정보유출 보안사고 이력(?)을 한번 보고 넘어가자. 인터넷에서 대충 검색해도 아래 그림처럼 엄청난 양의 개인정보 유출사고 사례를 접할 수 있다.


출처 : http://zalhae.blog.me/30183768858


하지만 이런 많은 개인정보유출사건 중에서도 이번 신용카드3사의 개인정보 유출사고가 심각하게 다루어져야 하는 이유는 단순 개인정보 뿐만 아니라 금융정보까지 함께 유출되었다는 점에 있다. 게다가 이번 개인정보 및 금융정보의 유출이 소위 말하는 해커의 "해킹"에 의한 것이 아니라는 것은 금융사 내부의 모든 구성원이 마음만 먹는다면 얼마든지 개인의 금융정보에 접근하여 "계좌 조작"까지도 가능하다는 매우 치명적인 "위협 시나리오"가 현실로 나타날 수 있다는 것을 의미한다는 점에서 과거처럼 조용히 넘어가서는 안된다는 것을 시사한다. 하지만 사고 이후 금융당국과 정부의 대처는 호들갑만 떨 뿐 소문난 잔치에 먹을 것 없다는 속담을 떠올리게 하고 있어 안타깝기만 하다.


신용카드3사 개인정보/금융정보 유출 시나리오


이번 신용카드3사의 개인/금융정보 유출사고는 모든 금융기관 아니 모든 기업/공공기관의 공통적인 보안 위협인 "개발/운용의 외주"가 불러온 사고라고 볼 수 있다. 신용카드사들은 금융당국의 요구로 "신용카드 불법사용 탐지"를 위해 KCB라는 회사에 외주를 주어 시스템을 개발하고 있다.

그 과정에서 필수적으로 테스트가 필요한데 이때는 실제 신용카드 거래정보를 이용해 테스트를 진행할 수 밖에 없다. 당연히 KCB의 개발담당자는 "당당하게" 테스트를 위해 실제 고객 정보를 요구했고 카드사 IT담당부서에서는 데이터의 접그을 허용해주었다.


이를 바탕으로 아래 그림에 이번 사고 시나리오를 재구성해 보았다.

카드사 개인정보 유출 시나리오


하지만 여러 금융사의 전산실을 드나들어 본 경험을 바탕으로 할 때 의구심이 드는 것은 과연 KCB의 개발자가 어떻게 개인의 노트북을 소지하고 게다가 USB를 연결하여 개인정보를 유출했는가 하는 점이다. 솔직하게 이 점은 현재까지도 이해가 되지 않는다.


그 이유는 다음과 같다. 매우 기본적인 보안 수칙이다.


1. 대부분의 금융사는 이미 개인의 업무용 노트북을 어떠한 경우에도 금융전산네트워크에 접속하도록 허용하지 않는다.

2. 설사 접속하도록 하더라도 USB차단/블루투스 차단, 와이파이차단 등의 기능을 하는 보안SW를 노트북에 설치하여 USB사용을 차단한다.


1번과 2번의 규칙을 준수하지 않았다는 것은 사실 상상하기 힘들다. 이 보안규칙을 지키지 않았다면 이는 책임소재가 분명하기 때문에 대부분의 금융기관에서 비교적 철저하게 준수하고 있기 때문이다.


만약 위의 보안정책을 따르고 있었다면 어떠한 경로를 통해 데이터가 유출될 수 있을까? 이경우의 정보유출 경로는 바로 "서버"다.


요즘의 서버들은 대부분 USB포트를 갖고 있다. 윈도서버는 물론이고 리눅스, Unix 서버도 USB 포트를 갖고 있는 경우가 대부분이다. 서버 운영체제의 지식을 조금만 갖고 있다면 1. 서버에 USB 메모리를 꼽고 2. 마운트를 한 뒤 3. 서버의 DB에 있는 데이터를 파일로 저장한 뒤 4. USB로 복사하면 쉽게 유출이 가능하다. 그리고 이러한 방법은 엔지니어나 내부자에 의해 종종 사용되고 있다.


서버에서의 정보유출 차단을 위한 방안


앞에서 언급한 것 처럼 "개발"이나 "운용"을 위해 내부 IT 부서 직원이나 오퍼레이터 혹은 외부 업체의 직원에게 서버에 Telnet, FTP 등의 방법으로 로그온할 수 있는 권한을 부여하는 경우가 많다. 하지만 Unix/Linux/Windows 서버는 어떠한 계정으로라도 서버에 로그온만 할 수 있다면 해킹이라고 하기에도 유치한 쉬운 방법으로 수퍼유저(root, Administrator) 권한을 얻을 수 있다.


그렇기 때문에 RedCastle과 같은 SecureOS 솔루션을 설치하여 보안대책을 수립해야 한다.


1.  IP , 계정, 시간, 서비스종류(telnet,ftp)조합에 의해 로그온을 통제.

2. 로그온통제에 추가하여 AuthCastle 등을 통한 2중인증(ID/Password + OTP/PKI/ARS) 적용

3. DBA 계정 및 root 계정 등 으로 로그온했다 하더라도 데이터베이스에 접근할 수 있는 명령어 및 실제 데이터가 

   저장된 데이터파일에 접근을 차단.

4. root 계정에서 db관리자 계정(oracle, db2)으로 패스워드 없이 Switch User 하지 못하도록 차단

5. setuid 및 간단한 코딩을 이용해 db관리자 권한 및 수퍼유저 권한 획득 차단

6. 백도어 등 설치를 통한 Bind Shell 등의 차단 (사용하지 않는 통신포트 Bind 차단)

7. 서버내에서의 Race Condition, FIFO Attack, 스니핑 등을 탐지하거나 차단할 수 있는 보호대책 적용

8. 운영체제의 설정파일, 응용프로그램의 설정파일 및 바이너리 파일에 대한 위변조 차단

9. 임시디렉토리에서의 실행(execute) 통제 및 크론탭 파일 등에 대한 무단 위변조 차단

10. 응용프로그램 네에 하드코딩된 ID, 비밀번호에 대한 유출 방지 대책


몇몇 보안대책만 나열해 보았지만 이러한 보안대책을 권고하고 구현해주는 보안컨설팅업체는 아직까지 보지를 못했다. 그만큼 서버내에서의 내부자 및 외부용역업체 개발자/엔지니어에 대한 행위 통제를 수행하는 경우는 아직까지 거의 없다. 그리고 이러한 보안대책을 "제대로~" 구현할 수 있는 솔루션도 RedCastle과 같은 SecureOS 외에는 없다고 봐도 무방하다.


일부 게이트웨이 방식의 제품이나 보안쉘 방식 혹은 PAM에서 가로채는 형태의 제품이 있기는 하나 사실 반쪽자리 솔루션일 뿐이다. 관리자 권한(root)을 얻는다면 간단하게 우회가 가능하기 때문이다.


10년 가까이 서버보안 업무를 하고 있지만 서버에 대한 제대로된 보안 정책을 수립하고 구현한 기업이나 공공기관은 손가락에 꼽을 만큼 찾아보기 어려운 것이 현실이다. 그나마 몇 안되는 고객사의 보안정책 수립과 구현에 기여했다는 것이 소중한 기억으로 느껴지는 것이 현실이다.


내가 서버보안업계에서 은퇴(?)하기 전에 과연 "제대로 된" 서버의 보안대책을 구현하는 것이 보편화될 지 궁금하다.




  • 미세스앤미스깡 2014.01.29 13:53 신고

    헐... 저도 이 머나먼 땅에서 다 털렸어요 ㅠ
    더 화나는건 거소증 만들어 따끈따근한 새 주민번호를 만들었는데 그게 털렸다는 ㅠ
    뭐 이런 일이 있나 싶어요.
    저도 유니센터님 링크 걸고 갑니다 ㅎㅎ


I.       사건 개요

2013 320일 오후 12시 경 방송사와 금융기관의 내부 네트워크에 연결된 모든 PC를 공격하여 PC의 디스크 파괴를 통해 업무 전산망을 마비시키는 대형 보안사고가 발생하였음.

l  발생일시 : 2013 320일 오후 12 ~ 14

l  공격대상기업 : 3개 방송사(공중파 2, 케이블 1) 3개 금융기관(1금융권)

l  공격대상자원 : 기업 내부의 업무전산망에 연결된 모든 PC

l  공격방법 : PC에 악성코드를 유포하여 PC내의 디스크 파괴

l  공격결과 : 기업 내부의 업무 전산망 마비로 인한 업무 마비 및 중요 데이터 파괴

 

II.     사건 분석

320일 발생한 보안사고는 다음과 같은 절차에 의해 수행된 것으로 보임.

l  공격 대상 기업의 내부 전산망에 위치한 PC용 백신의 관리서버(A사 및 H사 개발 및 판매)기업 내의 모든 업무용 PC에 파일을 배포하고 실행할 수 있는 취약성이 있다는 점을 해커가 인지함.

l  APT 공격을 통해 6개 기업의 백신 관리서버(업데이트용)에 백신 업데이트 파일로 위장한 악성코드 파일 설치

l  백신의 관리서버가 업데이트 파일로 위장한 파일을 하위의 업무용 PC에 배포

l  업데이트 파일로 위장한 악성코드 파일을 실행 à 악성코드 감염

l  정해진 시간 (320일 오후 12 ~ 14)에 백신 프로그램을 강제 종료시키고 하드디스크 의 MBR 및 데이터 파괴 시작 (Windows Vista / 7 은 데이터영역도 파괴, XP는 일부 파괴)

l  하드디스크 파괴 후 PC 종료 메시지를 표시한 뒤 PC 강제 종료

l  PC 부팅 안됨.

 

상기 공격 과정을 도식으로 표시하면 다음과 같다.

KBS MBC YTN 해킹

상기 도식을 통해 다음과 같은 중요한 사실을 확인할 수 있다.

l  APT 공격을 통해 기업의 내부 전산망에 위치한 백신관리서버(업데이트 배포서버)에 관리자 계정의 권한을 해커가 획득하였음.

l  해커가 상용 솔루션인 백신관리서버 솔루션의 동작구조를 이해하고 있으며 공격의 설계에 필요한 이 솔루션의 파일배포 취약점을 파악하고 준비하였음.

l  백신업데이트 파일로 위장한 악성코드가 PC에 배포된 뒤 백신 프로그램을 강제 종료하였음.

l  백신이 PC의 디스크를 파괴하는 신규 악성프로그램을 탐지 및 차단하지 못하였음.

 

320일 발생한 이번 보안 사고는 2년 전 이즈음 발생한 농협의 전산망 마비사태와 큰 유사성을 갖고 있다. 그 유사성은 바로 해킹에 악용된 취약점이 상용 시스템 관리 솔루션의 취약점을 악용하여 최종 공격을 수행하는 명령코드를 최종 공격 대상 기기로 보내 실행했다는 점이다.

농협 전산 사고의 경우 업계에서 많이 사용되는 서버 장애 관리 및 모니터링 솔루션의 관리자 권한을 APT 공격을 통해 획득한 뒤 수백 대의 서버에서 동시에 디스크를 파괴하는 명령을 실행한 것으로 추측되며 이번 사고도 백신 업데이트 관리 솔루션이 설치된 서버의 관리자 권한을 획득하여 내부 전산망의 PC의 디스크를 파괴한 것으로 보이는 매우 중대한 공통점이 있다.

 

III.       대응 방안

앞에서 살펴보았듯 전산망이 마비되는 대형 보안사고는 대부분 APT 공격을 통해 자행되는 경향을 보인다.

특히 하나의 침투대상의 관리자권한을 APT 공격을 통해 확보하면 다수의 하위 공격 대상 장비로 공격을 실행하는 악성코드를 유포할 수 있는 중앙 집중 관리 시스템을 해킹하려는 시도가 증가할 것으로 예상된다.

이러한 공격을 차단하기 위해서는 중앙 집중 관리를 위해 도입된 솔루션별 관리서버에 대한 보안 강화가 필요하다.

이번 사고 사례에서도 알 수 있듯 중앙집중관리 솔루션들은 필수적으로 다수의 서버 혹은 PC에 에이전트(Agent)라 불리는 S/W를 설치하게 된다. 그리고 이 에이전트를 통해 서버나 혹은 PC의 다양한 정보를 수집하고 관리한다. 다음과 같이 매니저-에이전트의 구성을 갖는다.

 

농협사태와 320대란에 악용된 상용솔루션들의 매니저-에이전트 구성에서 보안취약성은 바로 매니저가 설치된 서버에 있다. 그리고 두 사건 모두 해커들은 매니저의 취약성을 파고 들었고 해당 취약성에 대한 공격이 성공하면서 모두 대형 보안 사고로 이어졌음에 주목해야 한다.

매니저가 설치된 서버에 대한 보안을 강화하기 위해서는 RedCastle SecureOS를 이용하여 다음과 같은 정책을 적용하여야 한다.

l  Windows의 주요 운영체제 폴더에서 새로운 파일의 생성/수정/삭제의 차단

è  악성프로그램/코드 및 운영체제 파일의 바이러스 감염 차단을 위해 필수적인 정책

l  Windows의 주요 설정 파일에 대한 수정 차단

è  파밍공격차단 및 악성프로그램의 자동 실행 차단 등

l  위협명령어(net.exe, taskkill.exe, cmd.exe, shutdown.exe, nc.exe, telnet.exe, ftp.exe)에 대한 실행 차단

è  악성코드가 주요 서비스 및 백신 강제종료 차단, 해킹시도를 위한 명령어 실행 차단

è  악성코드 유포 및 외부 연결 시도 차단

l  웹브라우저 실행 차단

è  악성 코드 감염을 유도하기 위한 웹 호출 차단

l  방화벽을 이용한 Outgoing 세션 연결시도 차단

è  서버로부터 외부로의 취약한 서비스포트로의 외부접속 차단

l  방화벽을 이용한 netbios 연결 및 Microsoft-DS, SQL Server 서비스 접속 시도 차단

è  공유 접근 및 DB 접속을 통한 관리서버 해킹 시도 차단

l  터미널서비스 접속 제한

è  관리자 이외의 PC에서 원격접속시도 차단

l  관리솔루션이 설치된 폴더 및 관리솔루션의 관리하에 있는 폴더에 대한 타 계정/IP 등에서의 접근 제한

è  원격접속 등을 통해 접근하였을 경우 접근을 제한하여 APT 공격으로 관리 솔루션이 해킹되는 것을 예방.

 

VI.       결론

2년전 발생한 농협과 3 20일 발생한 대형 보안사고를 통해 관리 솔루션의 도입이 대형 보안사고를 유발하는 커다란 취약성이 될 수 있음을 확인하였다. 하지만 관리 솔루션을 도입하지 않고 대형 다수의 시스템을 관리하는 것은 사실상 어렵다.

그렇다면 결론은 관리 솔루션 취약성의 공격으로 인한 대형 보안사고를 예방하기 위해서라도 관리 서버에 대한 보안을 강화하는 방법 밖에는 없다고 볼 수 있다. 특히 APT 공격을 통해 관리서버에 존재하는 관리자 계정의 권한이 탈취될 수 있다는 가정하에 공격을 저지할 수 있는 방법을 찾아야 하며 그에 대한 해답을 제공할 수 있는 보안강화 수단은 RedCastle과 같은 서버보안SW밖에는 없다고 볼 수 있다.



  • 하얀삼치 2013.04.07 22:56

    정보 감사히 봤습니다. 감사합니다.


홈페이지를 운영하는 많은 쇼핑몰들과 인터넷신문사 홈페이지는 수시로 홈페이지 위변조 및 자바스크립트 위변조 공격에 시달린다. 최근 방문했던 한 인터넷 뉴스사이트도 그런 공격이 너무도 많다는 고충을 토로하기도 했다. 때문에 여러 솔루션들을 사용하지만 보안정책 수립의 어려움, 실시간 모니터링의 어려움 등으로 인해 제대로 대응하지 못하는 경우가 많다고 한다.

사고가 발생하면 다음과 같은 사항들을 해킹이 발생한 서버내에서 신속하게 파악하고 취약성을 제거하고 모니터링을 해야지만 솔루션 부재로 인해 대부분 정확한 경로를 파악하지 못하는 경우가 많다. 

- 침입 경로

- 칩입 후 실행한 명령어

- 수정한 파일

- 작업 과정

대부분 서버내에서는 해킹에 성공하여 수정한 파일"만 원상복구하고 네트워크에서 해당 출발지 IP를 차단하는 정도의 응급조치만을 하게된다. 해커는 공격지IP를 변경하여 재공격을 수행할 수 있고 사고는 다시 발생한다.

2013년 1월 5일... 국내의 대형 인터넷서점 홈페이지의 Java Script 파일이 변조되어 악성코드가 해당 인터넷 서점에 접속한 웹브라우저를 통해 접속자의 PC에 감염되는 심각한 보안사고가 발생했다. 

웹페이지 악성코드

이 사고는 해킹당한 홈페이지의 소스파일 위변조를 통해 웹브라우저를 통해 접속한 사용자의 PC가 악성코드에 감영되는 전형적인 사고사례다. 워낙 유명한 대형 인터넷 서점이고 비교적 모니터링 체계가 잘되어 있어 장시간 유표되는 사태는 막을 수 있었지만 사용자의 접속이 많지 않은 홈페이지의 경우 장시간에 걸쳐 많은 PC에 악성코드를 감염시키게 된다.



이러한 사고를 근본적으로 방지하기 위해서는 서버내의 주요 자산인 홈페이지 소스파일에 대한 철저한 보안이 필요하다. 

1. 웹서버의 취약성에 의해 서버내의 계정 권한이 탈취되는 것을 차단해야하고

2. 웹서버 혹은 WAS 서비스에 웹쉘이 업로드되어 운영체제의 명령어를 실행하지 못하도록 해야하며

3. 만에 하나라도 서버의 웹서버 혹은 WAS서비스의 계정 권한이 탈취되더라도 운영체제의 임시디렉토리에 스크립트 파일을 생성하고 실행하는 것을 차단해야하며

4. 홈페이지 소스가 웹서버 혹은 WAS서버의 구동 계정으로 수정되지 않도록 통제하여야 한다.

이 몇가지 보안정책만 준수할 수 있다면 홈페이지 위변조에 의한 보안사고는 대부분 예방할 수 있을 것이다.


관련포스트

웹쉘의 위험성과 서버보안SW를 이용한 웹쉘 실행 차단

서버보안SW를 이용한 웹서버보안 강화 방안

웹해킹방어사례 - 남다른 끈기를 보여준 해커



  • kmk 2013.01.10 21:57

    사기조직동두천경찰 폭파 Naver ckmk1

  • 1 2013.03.27 20:11

    홈페이지개발자와 작업의뢰인의 거래사이트 "오투잡"

    오투잡은 현재 하루 접속자 3000명이 접속하는 재능거래 사이트 입니다.
    오픈한지 얼마되지 않았지만 부업분야 전체 점유율 2위, 국가지원을 받고있습니다.

    오투잡에서 판매자 대모집 중입니다.
    카테고리 활성화가 시작 되니, 많은 판매 등록 바랍니다.
    오투잡은 네이버에서 "오투잡" 으로 검색 하세요.