태터데스크 관리자

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

태터데스크 메시지

저장하였습니다.

보안정책 (4)



최근 발생한 현대캐피탈과 농협 그리고 이번 KBS, MBC, YTN, 신한은행, 농협의 치명적인 보안사고로 인해 금융산업분야 뿐만 아니라  비지니스를 위해 혹은 전산시스템이 비즈니스 그 자체인 많은 기업과 공공기관에 초비상이 걸렸다. 덕분에 나도 너무 많이 바빠진 사람중의 하나가 되었다.

 

하지만 Unix/Linux 운영체제는 자체적인 보안기능이 매우 부족하다. Unix/Linux가 애초부터 보안을 염두에 두고 개발한 운영체제가 아니기 때문에 운영체제 자체적으로 엄청나게 많은 관리적/기술적 취약성을 갖고 있다. 기술적 취약성 중 일부는 운영체제의 설정을 변경하여 보완할 수도 있지만 근본적으로 한계를 갖고 있으며 관리적 취약성은 운영체제 차원에서는 대응할 수 있는 방안이 없다.

 

그래서 공공기관 및 금융부문에서는 RedCastle과 같은 SecureOS S/W를 서버에 설치하여 Unix/Linux 운영체제의 기술적/관리적 취약성을 보완하고 있다. 하지만 보안강화를 위해 RedCastle에 보안정책을 넣어달라는 요청은 많은데 비해 어떤정책을 수립 할 것인가에 대해서는 아무런 생각이 없는 경우가 대부분이다.

 

그래서 Unix/Linux 서버의 운영자 및 보안부서의 IT 담당자분들께 도움이 될만한 서버보안 정책 가이드라인을 제시해본다.


 

I.              계정 통제 정책

 

흔히 계정통제라고 하면 여러 서버에 동시에 계정을 생성하고 패스워드를 일괄 변경하는 것을 생각하기 쉽다. 하지만 서버보안에서 계정통제라 함은 다음을 의미한다.

 

l  계정은 몇 개를 어떤기준에 의해 생성할 것인가

l  각 계정별 로그인 통제는(계정/서비스/IP/시간의 조합에 의한 로그인 통제) 어떻게 할 것인가

l  서버에 로그인한 사용자가 다른 계정으로의 Switch User를 하는 행위에 대해 어떻게 통제할 것인가

l  계정을 이용한 행위 감사(Audit)는 어떻게 할 것인가

 

흔히 계정관리와 혼동하는 패스워드의 일괄 변경은 기본적인 보안정책 즉 서버마다 패스워드를 다르게 설정하여야 한다는 아주 기본적인 보안정책에 위배된다. 이는 하나의 패스워드가 유출되면 전체 서버의 패스워드가 유출되는 끔찍한 결과를 차단하기 위해 권고되는 패스워드 관리 정책이다.

 

금번 농협의 보안사고에서도 단 몇 개의 root 패스워드가 내부자에 유출되었을 것이지만 피해는 275대의 서버에서 발생한 것처럼 어쩌다~ 한번 발생한 사고가 너무도 큰 피해를 유발하게 될 수 있다.

 

1)    계정은 몇 개를 어떤기준에 의해 생성할 것인가
 

서버에 TELNET, FTP, SSH 로그인을 수행하는 개인들은 서버에 혼자만 사용할 개인의 계정을 만들고 서버에 로그온할 때는 자신의 계정을 이용해 로그온 할 것을 권고한다.

 

이것을 굉장히 어려운 일이라거나 서버의 장애를 유발할 것이라는 막연한 두려움을 가진 관리자들이 너무도 많다. 서버의 운영체제는 다수의 사람들이 동시에 접속할 것을 전제로 만들어진 Multi-User, Multi-Tasking 운영체제다. 계정을 100~200 개 생성해도 계정이 많다는 이유로 서버가 느려지거나 장애가 유발되지는 않는다. 그 사람들이 동시에 접속하여 부하가 큰 명령을 동시에 실행하지만 않는다면 말이다


몇개의 계정을 100명이 사용하는 것이나 100개의 계정을 100명이 사용하는 것은 동일한 부하를 유발한다고 생각하면 맞다.

 

시스템관리자, DB관리자, 어플리케이션 관리자 등 수많은 사람들이 Root, oracle, weblogic, jeus, tuxedo 등 공용계정을 공유하여 사용하는 것은 장애 혹은 보안사고 발생 시 원인분석을 어렵거나 불가능하게 만드는 주요 원인이다. 때문에 개인계정을 생성하여 스스로의 관리 책임하에 서버에 로그온 하는 것이 올바른 계정 생성 정책이다.

 

자신만의 계정으로 로그인 한 뒤 root, oracle 등과 같은 수퍼유저 및 애플리케이션 관리자 계정으로 SU하여 사용하도록 하여야 한다.

 

 

2)    계정의 로그인 통제는 어떻게 할 것인가

 

Root, oracle, tmax, weblogic, tuxedo Super-User의 계정과 애플리케이션 관리자 계정등 공용계정으로의 직접 로그인은 차단하여야 한다.

 

Super-user 계정인 root로 여러 사람이 직접 telnet 로그인하는 것을 허용하게 되면 문제 발생 시 도대체 누가 로그인하여 작업했는지에 대한 추적이 불가능해진다. 때문에 서버에 로그온 하여 작업을 수행해야 하는 개인들은 모두 개인계정을 만들어 사용하고 root 이하 공용계정으로는 직접 로그온 하지 못하도록 통제하여야 한다.

 

추가적으로 각 개인별로 사용하는 IP에 대해서만 로그온 할 수 있도록 IP 통제까지 수행한다면 보안성은 대폭 개선될 수 있다.

 

 

3)    서버에 로그인한 사용자가 다른 계정으로의 Switch User를 하는 행위에 대해 어떻게 통제할 것인가

 

계정의 이동(Switch User)통제는 시스템운영에 상당히 민감한 영향을 끼칠 수 있다. 그리고 체계가 잡히지 않은 중구난방~식의 SU 통제는 시간이 지날수록 문제를 유발시킬 가능성이 커지기 때문에 SU를 통제할 때에는 시스템을 운영하는 전산부서 전체에 적용할 수 있도록 정책을 확실하게 수립하는 것이 좋다.

 

계정이동통제(SU) 정책 수립 시 기본 지침은 다음과 같다.

 

-       Super User root 계정으로의 SU를 허용할 개인계정을 그룹핑한다.

-       Oracle, Weblogic 등 애플리케이션 별로 SU를 허용할 계정을 그룹핑한다.

 

위의 두 지침에 의해 계정들이 그룹핑 되면 다음의 기본 SU통제 지침을 적용한다.

 

-       root oracle, weblogic 등 애플리케이션 관리자 계정간의 SU는 차단한다.

-       앞에서 그룹핑된 각 그룹에 속한 내부 사용자간의 SU는 허용한다.

-       서로 다른 그룹간의 SU는 차단한다.

  

 

4)    계정을 이용한 행위 감사(Audit)는 어떻게 할 것인가

 

계정에 대한 행위감사는 사용자가 서버에 telnet, ssh, rlogin 등의 방법으로 서버에 로그온 한 시점부터 로그아웃 시점까지의 모든 명령어 수행에 대해 기록을 남겨야 한다. 운영체제에서 제공되는 Shell History는 모든 명령어 입력에 대해 감사기록을 남겨주지만 세션에 대한 구분 및 하나의 계정으로 여러명이 접속하였을 때 각각의 원래 사용자를 식별하지 못하는 문제가 있기 때문에 큰 의미는 없다.

 

RedCastle과 같이 모든 세션을 식별하여 SU하기 전과 SU한 이후까지도 연결고리가 끊기지 않고 추적이 가능하도록 해야 하며 커널레벨과 TTY레벨의 추적 모두가 가능하도록 하면 최고의 사용자추적(행위감사)이 가능하다.


이상 네가지 기본적인 서버의 계정통제 정책을 적용하면 체계적인 계정관리가 가능하고 Unix/Linux 운영체제에서 제공되는 기본기능인 su 를 통해 타 계정의 권한을 탈취하는 악의적인 행동을 방지할 수 있다.

 

물론 이 계정통제 만으로 Unix/Linux 서버를 운영하는 전산시스템의 내부보안을 강화하는 것에는 한계가 있다. 추가적으로 파일접근통제 정책을 적용해야 제대로 된 서버보안 정책을 적용했다고 할 수 있다.

 

기회가 되면 파일접근통제에 대한 정책가이드도 올려보도록 하겠다.

 

현대캐피탈과 농협의 보안사고 여파로 인해 요즘살이 다 빠질 지경이다.. ^^




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

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

- 침입 경로

- 칩입 후 실행한 명령어

- 수정한 파일

- 작업 과정

대부분 서버내에서는 해킹에 성공하여 수정한 파일"만 원상복구하고 네트워크에서 해당 출발지 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위, 국가지원을 받고있습니다.

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


많은 포털사이트에서 메일서비스를 제공한다. 파란과 네이버의 경우 5G Byte의 메일저장공간을 제공한다. 나 같은 경우 회사메일을 파란으로 포워딩해서 외부에서 사용하고 노트북의 파손에 대비한 백업도 겸하고 있다.

안드로이드를 채택한 휴대폰을 구입하면서 구글메일에 관심을 갖게 되었다. 휴대폰과의 동기화나 메일 수발신을 기본적으로 제공하기 때문에 무척 편리할 듯 싶어서였다.
그런데..... 결정적으로 gmail 사용을 포기했다.

그 이유는 바로 구글의 너무도 엄격한 보안정책 때문이다. 나도 보안관련 일을 하지만 구글의 일관되지 못한 듯 보이는 보안정책은 동의하기 힘들다.

구글은 브라우저에 자동로그인 기능을 특별한 설정을 해두지 않아도 활성화 시킨다. 이것은 언뜻 사용자의 편의를 위한 것 같지만 누구든 주인이 자리를 비운 사이 브라우저를 실행하여 구글에 접속하면 이메일, 개인정보 등을 인증과정 없이 접근할 수 있다. 무척 치명적인 보안 결함이다.

하지만 내가 gmail 사용을 포기하게 한 첨부파일에 대한 보안정책은 좀 지나치다 싶을 정도로 강력하다.


gmail로 수신/발신되는 메일에 첨부되는 파일에는 exe, dll 등의 확장자를 가진 파일을 첨부할 수 없다. 여기까진 이해가 된다. 하지만 zip 파일 등 압축된 파일 내에도 exe.dll 등의 확장자를 가진 파일을 첨부할 수 없다는 것까지는 이해하기 힘들다.



아무리 이메일의 첨부파일로 위장한 공격도구들이 퍼진다해도 압축된 첨부파일 내부에 exe, dll 등의 확장자를 가진 파일이 포함되는 것을 허가하지 않는 것은 도무지 납득할 수 없다.

혹시 이러한 정책이 gmail의 사용자 수를 조절하기 위한 방법은 아닐까 생각된다.
두개의 상반된 수준의 보안정책.... 그래서 난 gmail 사용을 포기했다.


관련 포스트 : 웹서버 소스파일 위변조 차단을 위한 SecureOS 적용

웹쉘(web-shell)은 서버를 해킹하는 가장 훌륭한 도구 중에 하나다. 웹서버에 웹쉘을 업로드 하고 웹브라우저를 통해 웹쉘을 호출할 수 있다면 해커는 그 서버를 마음대로 조종할 수 있는 권한을 90%쯤 갖게 된다고 볼 수 있다.

많은 서버관리자와 보안관리자들이 웹쉘이 업로드된 서버를 발견하게 된다면... 눈 앞이 캄캄해질 것이다. 웹쉘이 발견되었는데도 눈앞이 캄캄해지지 않는 관리자라면 둘중하나다. 확실한 웹쉘 실행 차단 대책이 이미 적용되어 있는 훌륭한 관리자이거나 웹쉘이 뭔지도 모르는 초보 관리자 둘 중 하나다. 둘다 아니라면..?? 거기까진 말하고 싶지 않다.

먼저 웹쉘의 동작 과정을 시연 화면을 통해 살펴본다.

이 화면은 웹서버에 업로드된 "초 간단" 웹쉘이다. PHP로 작성된 10줄 남짓의 이 웹쉘은 비록 화면은 인터넷에 떠도는 많은 웹쉘에 비해 단순하지만 그 어떤 IPS나 웹 방화벽에 적발되지 않고 실행가능한 "강력한" 웹쉘일 것이다.


웹쉘이 하는 일은 아주 간단하다. 위의 화면과 같이 입력창을 통해 명령어를 입력받아 웹서버를 통해 실행하고 그 결과의 출력화면을 브라우저에 표시해주는 것이다.

웹쉘이 실행할 수 있는 것은 무척 많다. 그래서 웹쉘이 실행할 수 없는 것을 이야기하는 것이 더 빠를 것이다. 웹쉘이 실행하지 못하는 것은 "웹서버가 실행중인 계정이 실행 권한을 갖고 있지 않은 실행파일 및 스크립트"이다. 그 이외에는 모두 실행이 가능하다.

위의 화면에서와 같이 "cat /etc/hosts" 명령을 입력하고 실행하면 다음과 같이 그 결과가 브라우저에 표시된다.


웹쉘은 단순히 명령어 만을 실행하고 그 결과를 보여주는 것만 가능할까?

아니다. 웹쉘의 활용은 거의 무궁무진하다. telnet으로 서버에 들어간 것과 같이 스크립트를 만들고 실행시키는 것도 가능하다. 다만 웹서버가 구동중인 계정의 권한만을 갖기 때문에 파일을 만들고 실행하기 위해서는 웹서버가 실행중인 계정이 쓰기,실행(w,x)을 갖고 있는 디렉토리를 찾아야 한다. 

하지만 해커들이 누군가? 아무도 알려주지 않아도 해커들은 /tmp와 /var/tmp가 trwxrwxrwx 퍼미션으로 되어 있다는 것을 알고 있다.

다음과 같이 /tmp 디렉토리에 hack.sh 스크립트를 만든다. 첫번째 줄이다.


 다음은 두번째 줄이다.


두줄이 들어간 hack.sh 스크립트의 내용을 확인해보자.


ps와 netstat 두줄이 들어간 hack.sh 스크립트가 생성되어 있다. 서버의 umask 설정에 따라 실행퍼미션이 없을 수 있는데 chmod +x 명령으로 실행퍼미션을 부여해주면 된다. 보안 때문에 반드시 설정해야한다는 umask 설정이 무용지물이 되는 이유다.

이 hack.sh를 실행하면 스크립트에 포함된 두개의 명령이 차례대로 실행된다.


/tmp/hack.sh 스크립트가 실행된 것을 확인할 수 있다.
 
웹쉘은 실행파일은 물론 쉘스크립트, 그리고 Perl 스크립트도 실행이 가능하다. 인터넷을 조금만 검색하면 icmp, udp, tcp의 보안 취약성을 이용한 DOS, DDOS 공력용 Perl스크립트를 비롯한 다양한 공격 도구들을 쉽게 구할 수 있다.
또한 자동 ftp 스크립를 만들어 웹쉘로 작성한 뒤 실행하면 외부의 서버로 ftp 접속을 하여 파일을 다운로드 받는 것도 가능하다.

웹쉘로 못할 것이 없는 것이다.

그렇다면 웹쉘을 차단하는 근본적인 방법은 없는 것일까?? IPS와 웹방화벽은 현실적으로 웹쉘을 효과적으로 차단하지는 못한다. 현실적인 여러가지 이유와 오탐의 위험때문에 패킷스니핑방식의 보안솔루션으로는 웹쉘을 차단하는 것은 불가능하다.

하지만 서버보안S/W인 RedCastle을 이용하여 아주 간단한 두개의 정책만 추가해주면 웹쉘의 실행을 완벽하게 차단할 수 있다.

RedCastle이 제공하는 파일접근통제정책에 다음과 같은 정책을 추가해주면 된다.

1. 운영체제의 모든 명령어들을 웹서버 (httpd 및 java 등)을 통해 실행하지 못하도록 한다.
2. /tmp 및 /var/tmp 디렉토리에서 웹서버가 스크립트 및 실행파일을 실행하지 못하도록 한다.
3. 웹서버의 업로드 경로에서 아무도 실행권한을 사용하지 못하도록 한다.

RedCastle SecureOS를 통한 정책의 추가는 아주~~쉽고 그 효과는 100% 확실하다.



  • 질문좀요.. 2010.03.28 13:17

    레드캐슬 저건 어디서 구할수있나요?

  • mizz 2010.04.12 03:13

    저 웹쉘 소스 좀 알 수 있을까요 ㅠㅠ

    mizzzzzz@naver,com 으로 보내주시면 진짜 감사하겠습니다 ㅜㅠㅜ

    • 주인장 2010.04.13 23:33

      더 성능좋은 웹쉘은 인터넷을 조금만 검색해보면 많이 찾을 수 있습니다.
      한번 검색해보세요~

  • proxyolism 2010.08.16 00:21

    퍼갈께요 ^^ 웹해킹공부하고있는데 자료 찾고있었습니다 ㅎㅎ 도움많이됬어요.

  • colroni 2010.08.24 19:10

    웹쉘을 막을려고 하는데 어떻게 설정을 해야하고 웹쉘파일을 찾는 방법도 알려주시면 감사하겠습니다.
    급합니다. colroni@naver.com

    • 주인장 2010.08.25 07:30

      서버보안 S/W가 없는 상태에서 웹쉘의 실행을 차단하는 것은 현실적으로 불가능합니다. IPS나 웹방화벽에서 알려진 웹쉘의 패턴을 인식하여 차단하는 것은 가능할지 모르지만 작정하고 덤비는 해커들이 알려진 웹쉘을 그저 사용만 할 가능성은 별로 없습니다.
      서버보안 S/W 없이 웹쉘을 막기 위해서는 "웹쉘의 업로드"를 차단하는 것이 가장 좋은 방법입니다. 어느 경로에 웹쉘이 생성되는 지를 확인하시고 웹 소스를 분석하여 어떤 취약성을 이용하여 웹쉘을 업로드 하는지를 빨리 찾아내는 것이 좋습니다. 찾아내셨다면 그 취약성을 제거하도록 웹 소스를 수정하셔야 합니다.

  • colroni 2010.08.25 10:37

    발단은 특정페이지 맨 끝단에 자바스크립트가 삽입이 되어있었습니다.
    그래서 ftp log를 살펴보아도 딱히 어떤 파일을 업로드한 흔적이 없습니다.
    어떻게 이런일이 가능한지..이게 자바스크립트 해킹인가요?
    막을 수 있는 방법이 없을까요?

    • 주인장 2010.08.25 21:23

      FTP 이외에도 여러가지 방법으로 홈페이지를 변조할 수 있습니다. 그리고 웹 소스와 플래시, 어도비 모듈 등을 사용하는 웹사이트에 존재하는 모든 취약성을 제거하는 것도 결코 만만한 작업은 아닙니다. 개발자가 취약성을 한개도 없이 웹사이트를 만드는 것은 거의 불가능한 현실이니까요.
      SQL인젝션, PHP인젝션 취약성 제거 그리고 웹서버의 설정, 계정 비밀번호 변경 등 원론적인 대책밖에는 없는 것이 현실입니다.
      SecureOS를 도입하지 않는다면 개발자와 관리자의 노력에 의존해 해커와 싸우는 방법 밖에는 없습니다.

  • 0000 2012.12.30 22:54

    제 서버에서 돌려보니 웹쉘이 업로드는 되고
    클릭을 하니깐 다운로드를 하라고 뜨는데 이런경우는 공격이안되는건가요?

  • Antares 2012.12.31 12:28

    어떻게 올리셨는지..서버는 어떤 서버인지 자세한 정보를 모르니 정확한 답변은 어렵지만..
    웹쉘 파일의 확장자를 뭘로하셨는지..그리고 "클릭"을 어떤 환경에서 하신건지에 따라 가능할 수도 불가능할 수도 있습니다.