자유로운설탕

  하드닝(Hardening) 보안을 "단단하게" 만든다는 의미로 앞에 나온 여러 이슈들을 포괄하면서도 프로그램 이외의 환경이나 설계적인 요소까지도 포괄하는 주제이다. 어찌보면 각종 보안 가이드 문서에 나와있는 ~을 하라는 모든 내용의 시작점 이기도 하다. 너무 포괄적이여서 어떻게 얘기를 풀어가야 할진 잘 모르겠지만, 일단 설명을 시작해 보려한다. 

[목차]

1. 보안을 바라보는 방법

2. 보안에서의 코드 읽기

3. 인젝션(Injection) 살펴보기 #1, #2

4. 암복호화

5. 클라이언트 코드

6. 업로드, 다운로드

7. 스크립트 문제

8. API

9. 하드닝(Hardening)
10. 설계 문제
11. 스캐너 vs 수동 테스트

12. 자동화 잡

13. 리버싱과 포렌식

14. 모니터링 문제

15. 악성코드

16. 보안과 데이터

1. 들어가면서

  하드닝이란 이슈는 꼭 보안 업무에만 관련된 것만은 아니다. 예를 들어 우리가 집에 새로운 와이파이 공유기를 설치 했을때에도 해당 이슈를 마찬가지로 만나게 된다. 공유기 설정을 맘대로 바꾸는게 가능한 admin 계정의 패스워드는 어떻게 할것인지, WIFI 통신의 암호화는 어떤 방식으로 할것 인지, 접속할 수 있는 기기들의 MAC 주소를 지정해 관리할 것 인지 등등 여러가지 설정상의 보안 문제들을 고민하게 된다. 요즘 많이 설치하는 IP 카메라 같은 경우도 마찬가지 이고 말이다. 

  물론 해당 부분을 모두 다 고려한다고 해도 100% 안전하다는 보장은 못하겠지만, 100% 안전하지 못할 상황만은 피할 수 있다고 본다. 마찬가지로 운영등에 사용할 OS, 웹서버 설치, 데이터베이스 설치, 어플리케이션 배포 등에 대해서도 마찬가지로 전문가들이 보안적으로 안전하다고 생각하는 사례들이 있다. 물론 해당 항목은 기술적이나, 보안적 측면으로 내린 근거에 기반한다고 생각하는게 맞고, 해당 부분을 일종의 보안적 패턴이라고 봐도 된다.

2. 몇가지 패턴으로 분류해 보기.

  개인적으로 무언가를 단순히 외우는 것은 아무 의미가 없다고 생각하기 때문에, 의미를 부여하기 위해 많이 권고 되는 몇가지 하드닝 사항들을 특정 패턴으로 한번 묶어 보도록 한다.

2.1 디폴트 배제

  보안에서 최초 기본적으로 나오는 디폴트 설정 문제다. 위에 있는 공유기 어드민 암호도 마찬가지다(바꾸라는데 왜 바꾸어야 하는지 모르거나 귀찮아 하는 사람이 많기 때문에, 근래의 공유기들은 무조건 최초에 기본 admin 패스워드를 변경해야지만 사용할 수 있도록 변경되었다. 하드웨어 적으로 초기화를 시킬수 있는 부분이 있긴 하지만 뭐 패스워드 잃어버려 공유기를 못설정하는 일이 생기면 안되는 부분이니 일종의 현실과의 협상이라고 보면 될듯 하다). 또한 디폴트 패스워드 뿐만 아니라, 프로그램을 처음 설치했을때 정의되어 있는 설정들이 보안적으로 바람직하진 못한 경우도 포함된다.

  이 카테고리에 속하는 것들이 많이들 언급 되는 디렉토리 리스팅, 너무 상세한 에러 페이지, 유추할 수 있는 관리자 페이지 URL 경로, 장비나 오픈소스, 솔루션 어플리케이션의 기본 패스워드, 백업, txt 파일등의 다운로드 문제, 톰캣 관리자 페이지, 패스워드 없이 접근되는 NoSQL 데이터베이스 등이 있을 수 있다. 모의해킹이나 시큐어 코딩, 해킹, 보안 설정 관련된 책들에서 주로 많이 나오는 내용들이다. 웹 검색 등에서 찾아보면 아래의 페이지 들이 그런 주제들을 간단하게 설명하고 있다. OWASP 같은 페이지를 검색해도 될것 이다. 디렉토리 리스팅 같은 문제는 Flask 같은 예제를 보면 전통적인 디렉토리 안에 파일이 있는 방식이 아니기 때문에 기술의 변화에 따라 뭔가 판이 달라지는 측면도 보인다.

[directory listing 취약점 막기(Apache2 보안) - intadd 님 블로그]

https://intadd.tistory.com/97

[톰캣 에러페이지 설정(정보 및 버전 감추기) - Mr.lee 님 블로그]

https://lee-mandu.tistory.com/327

[구글 해킹 유용한 명령어 - 정보보안 기록 저장소 님 블로그]

http://coashanee5.blogspot.com/2017/02/blog-post.html

[갈수록 중요해지는 권한 계정 보안 - 보안 뉴스]

http://www.boannews.com/media/view.asp?idx=51321

[홈페이지 보안 취약점 - 취약한 파일 존재 - IT 보물창고님 블로그]

https://skynarciss.tistory.com/29

[MongoDB 인증 모드 설정 - kkd927 님 블로그]

https://itstory.tk/entry/MongoDB-%EC%9D%B8%EC%A6%9D-%EB%AA%A8%EB%93%9C-password-%EC%84%A4%EC%A0%95

  이 하드닝 부분의 애매한 측면 중 하나가, 시간이 점점 지나면서 소프트웨어 보안에 대한 인식이 점점 강화 되고 있기 때문에, 앞의 공유기의 예처럼 새로운 버전의 OS 나 솔루션의 경우 많은 기본적으로 방어되도록 배포 되고 있다는 것이다. 예를 들어 앞에서 설치한 윈도우 10에서 설치되는 IIS 7.5 같은 경우에는 기본적으로 디렉토리 리스팅 기능이 OFF 되어있고, txt나 bak 확장자 파일의 경우도 URL 로 접근하면 예전과는 달리 파일이 실제 있더라도 404.4 에러가 난다. ASP 예제를 위해 IIS 를 설정할때도 생각해 보면 에러 또한 디폴트로 자세한 에러를 내보내지 않도록 설정되어 있다. 또한 기본적으로 웹서버나, FTP 서버가 설치되어 있지 않고 명시적으로 사용자가 설치해야 한다.

  하지만 보안 쪽의 귀찮음은 세상하는 항상 오래된 시스템이 있고, 해당 시스템은 잘 파악도 되지 않는 경우가 많기 때문에, 최신 환경에서는 일어나기 힘든 여러 과거의 취약점 패턴들에 대해서도 인지하여, 돌다리도 두드려 가는 마음으로 체크를 해야한다는 것이다. 다행이 이쪽은 스캐너 같은 도구나 스크립트 등이 도와줄 수 있는 측면이 많다고 본다.

  반대로 해킹을 해야되는 사람들 입장에서도, 모든 장비나 시스템이 최신 OS 로 패치되어있고, 하드닝이나 보안 설계가 잘 되어 있다면, 정말 아무도 모르는 패턴을 먼저 찾아낼 수 있는 소수의 능력자만 먹고 살수 있을지도 모른다. 하지만 세상일은 대부분 사람이 포함되어 하는 일이고 실수나 무지가 존재하기 때문에 항상 적정한 균형이 맞춰 지는 것 같긴하다. 이번 윈도우즈 10 업그레이드 이슈만 봐도 비용과 호환성의 측면이 있기 때문에 XP 처럼 쉬워 보이진 않는다. 아직도 어떨 수 없이 XP 를 쓰는 환경도 가끔 있다. 이런 면에서 보면 모바일 쪽에서는 IOS 쪽이 자유도는 엄청 떨어지긴 하지만 보안이나 유지비용 측면에서는 현명한거 같기도 하다. 

2.2 불필요한 것들 걷어내기

  다음 측면은 보안의 다른 철학 중 하나인 필요없는 사항을 걷어내는 것이다. 업로드 폴더의 실행권한을 제거하거나(또는 업로드 폴더를 웹서버 루트 폴더 바깥으로 빼기도 한다), 서버에 백업이나 테스트 파일을 남겨놓지 않는다든지(개념상 2.1과 겹치기도 한다), 웹게시판 이나 PHP 등의 샘플 파일을 제거한다든지, 사용하지 않는 특정 서비스를 Diable 시킨다든지 하는 주제가 포함된다.

  이 부분도 앞에 얘기했듯이 OS 나 취약점이 있었던 대상 프로그램이 업그레이드 되면서 일어나지 않게될 가능성이 높아져 스캐너에게 임무를 양보해야 할 과거의 지식이 될 가능성이 높다. 위와 같은 예제를 웹에서 찾으면 아래와 같을 것이다.

[파일 업로드 취약점 점검 및 보안 - blackhyuk 님 블로그]

https://bbhyuk.tistory.com/88

[FCKeditor 취약점 + 간단실습 -RedScreen 님 블로그]

https://redscreen.tistory.com/69

[서비스 관리 - 불필요한 서비스 제거 - IT 보물창고님 블로그]

https://skynarciss.tistory.com/190

2.3 필요한 정도로만 권한을 부여하기

  다음은 보안에서 가장 전방위로 많이 보이는 권한 제한 부분이다. 웹서버나 어플리케이션 권한을 ROOT 계정이 아닌 적절한 권한을 부여한 계정으로 돌린다든지(비교하자면 전쟁시 쪼랩인 중위에게 핵미사일 장치를 맡기지 않아야 하는 것과 비슷하다), 익명 FTP 를 제공하지 않는다든지(2.2 처럼 필요 없으면 FTP를 아예 설치 안하는게 더 바람직하다),  공용계정을 쓰지 않는다든지(누가 사고 쳤는지 알수 없거나, 어렵게 된다), 필요없이 자세한 로그를 남겨서 아무나 보게 한다든지(개인정보나 사용자의 주요 정보가 익명으로 노출될 수 있다), 어플리케이션에게 필요한 권한만 부여된 DB 계정을 발급한다든지, 루트권한을 안준다든지, everyone 권한의 폴더를 공유한다 든지 이다. 밑에 웹에서 찾은 예제들이 있다.

[리눅스에서 톰캣 일반 계정으로 실행하기 - 기록 > 기억님 블로그]

https://kimyhcj.tistory.com/75

[서버관리 - Anonymous FTP 비활성화 - IT 보물창고님 블로그]

https://skynarciss.tistory.com/125

[리눅스 루트계정을 항상 사용하면 보안에 문제가 되나요? - KLDP]

https://kldp.org/node/152000

[DB 접근제어 설계 - DBGuide.net]

http://www.dbguide.net/db.db?cmd=view&boardUid=152805&boardConfigUid=9&boardIdx=146&boardStep=1

[서버보안 가이드 - 폴더 권한 설정 - IT 보물창고님 블로그]

https://skynarciss.tistory.com/12

  이 부분은 사실 어플리케션 보안 측면도 있지만, 회사에서 많이 얘기되는 보안 정책 부분이기도 하다. 법적인 부분을 꼭 준수하고, 이외에는 사람들의 사용성 측면과 계속 딜을 해가면서 균형을 맞춰야 하는 부분 같다. 

2.4 그 외

  마지막으로 8교시 까지의 여러가지 측면(클라이언트 코드, 암호화, 인젝션, API, 업로드, 다운로드) 측면을 포함하는 포괄적인 영역이다. 해당 부분은 아래와 같이 기관에서 배포한 보안 가이드 문서(모바일, 일반 OS)를 살펴보면 될것 같다. 추가로 10교시에서 얘기할 설계 부분을 고려하여 문제에 접근 하면 어떨까 싶다. 

[소프트웨어 개발 보안 가이드]

http://www.kisa.or.kr/uploadfile/201702/201702140920275581.pdf

  사실 이 글 시리즈에서 목표하던 것 하나가 저런 보안 가이드를 만들때 왜 이런 항목을 구성해서 보안가이드를 만들었는지를 객관적으로 볼수 있도록 하고 싶었다. 뭐 얼마나 공감했을진 모르지만 일단은 1차 고지에는 도착한 기분이다.   

3. 대처 방법

  4. 그외 항목 이외에 위의 요소들의 주요 특징중 하나는 대부분은 좀 과거의 히스토리적으로 모아진 취약점의 경향이 강하고, 정형화되 있다는 것이다. 또한 수동 확인의 경우에도 특정 명령어를 날려 확인 한다든가, 화면을 보면 된다(경험상 화면을 봐서 할수 있는 것은 스크립트 등으로 자동화가 가능하다).

  결국 반복적으로 자동화된 체크를 수행하기 용이하다는 것인데, 이러한 자동화가 집적화된 결과가 여러 보안 스캐너나, 솔루션 들이다. 단순한 작업을 지치도록 수동으로 하기 보다는 적절한 ROI 를 따져서 무료나 유료, 또는 파이썬 등의 여러 언어로 만들어진 프로그램을 만들거나 코드를 구해 체크하면 효율이 나는 부분 같다. 이렇게 아낀 시간을 설계적인 측면이나, 코드 리뷰 등 자동화된 측면으로는 조금 한계가 있는 부분에 투자하는게 좀더 효율적이지 않을까 싶다. 물론 해당 부분을 자동화 하는 것을 스스로 한다면 많은 시행착오와 시간이 투여되는 부분일 수 있긴 한듯 하다.

4. 마무리 하면서

  다른 블로그들을 링크하여, 구렁이 담넘어가듯 써내려간 느낌이지만, 굳이 책이나 블로그에 잘 설명되어 있는 부분을 반복하는건 읽는 사람이나 쓰는 사람 모두 손해라고 생각해서 라고 생각해 줌 좋겠다. 설정 측면에서의 하드닝은 일반적인 어플리케이션 보안 관점보다는 노력이 덜 들고 자동화 할 수 있는 요소가 많은 부분이긴 하지만, 수동으로 할 경우 시간이 꽤 걸리고, 휴먼 에러도 일어날 수 있는 부분이다. 또한 실제 노출됬을경우 생각보다 큰 이펙을 주게 되는 요소라고 본다, 해당 부분은 단발적인 부분이 아니라 보안 쪽의 종합적인 정책과도 연관되어 결정되야 되는 측면도 있어 보인다. 단순해 보이긴 하지만 여러모로 균형을 잘 맞추면서 접근해야할 부분 같다.