박종명의 아름다운 개발 since 2010.06

INTRO

불과 '반년 전 즈음(2018.06)에 브루트 포스(Brute Force) 공격이 대형 은행을 겨냥해 시도' 되었습니다.

이 사건은 (적어도 당시에는) 다행히 실제 금전적인 피해로 까지는 이어지지는 않은 것 같네요.

공인인증서나 OTP가 해킹된 것이 아닌만큼 출금/이체와 같은 서비스는 건드리지 못했을 겁니다.

하지만 정보유출이라는 측면에서는 꽤나 성공적이여서 고객 정보 56,000건이 유출되었다고 합니다.

유출된 고객의 개인 정보를 악용해 2차 피해가 어떤 식으로 유발될지는 알 수 없는 노릇이죠.

보다 자세한 내용은, 다음의 KBS 보도 영상과 관련 기사를 참고하기 바랍니다.

80년대 초에 성행 했다던 브루터포스 공격은, 구식 공격기법이라는 인식과 너무 단순한 공격기법이라는 측면에서 기술이 발전한 근래에는 많이 행해지지 않을 것 같지만 드문드문 사례가 보이네요.

아래에 링크는 '2017년에 발생한 워드 프레스를 대상으로한 대규모 분산 무차별 대입 공격'에 대한 기사입니다.

마치 DDoS처럼 공격에 동원된 IP 수도 많고 각 IP가 막대한 수의 공격을 행했다는 기사를 확인할 수 있습니다. 이 기사에는 공격에 대한 대비책도 안내하고 있으니 참고하면 좋을 것 같습니다.

> 워드프레스를 대상으로 대규모 무차별 대입 공격(Brute Force Attack) 발생

그리고 '2014년에는 iCloud 해킹으로 헐리우드 스타들의 사적인 누드 사진들이 인터넷으로 배포'되는 사건이 있었습니다. 이 역시 브루터 포스 공격이 기반이 된 해킹 사례로 언급되는 듯 합니다.

> Apple Patches Brute Force Password-Cracking Security Hole in iCloud

그리고 꽤 오래전 우리나라에서 발생한 재미있는 에피소드가 있는데요...

1993년 '청와대 해킹사건'때 김재열이란 분이 수동으로 브루터포스 공격을 시도해 국제심판소의 PC통신 비밀번호를 알아 내었다고 합니다. (이때 국제심판소의 비밀번호는 무려 '12345'이였다고 하네요.)

> '국내 해커1호' 김재열의 인생유전

브루터 포스 공격은 단순하고 식상한 기법인 듯 하지만, 지금 이순간에도 많이 행해지고 있는 공격 기법입니다. 또한 공격이 성공했을 경우 파급력이 상당하기 때문에(내 계정을 해커가 장악했다고 생각해 보세요 =.=) 보안 개발자가 절대로 간과해서는 안될 것입니다.

브루터 포스 공격의 정확한 원리와 공격 방법, 대응 방안을 잘 숙지하시기 바랍니다.

1. 브루트 포스(Brute Force) 공격이란?

당신은 지금껏 살면서, 

누군가의 비밀번호를 알아 내기 위해 임의로 접근을 시도해 본 적이 없었는가?

그것이 자물쇠 비밀번호이든, 휴대폰 비밀번호이든, 웹사이트 비밀번호이든 말이다. 만일 그런적이 있다면, 당신은 이미 브루트포스 공격을 해 본 경험이 있는 것이다.

컴퓨터 분야의 브루터포스(Brute Force)란 용어는 '억지 기법(무차별 대입해 억지로 문제를 푸는)'이라 해석되며 개념적으로 아주 단순한 공격 기법이다..

특정 암호를 풀기 위해 임의의 문자의 조합을 하나씩 대입해 보는 공격 기법이다.

브루터 포스 공격을 위해, 임의의 문자열을 생성/조합하고 대입하는 방법으로는 다음과 같이 두 가지로 형태로 나눌 수 있다.

1.1 브루터 포스 공격을 위한 문자열 생성 및 대입 방법

1.1.1 무작위 순차 대입

브루터포스의 무차별 대입이라는 특징을 그대로 구현하는 것으로, 조합 가능한 모든 문자열을 순차적으로 하나씩 모두 대입해 보는 것이다. 그야말로 무식하게 암호가 일치할때 까지 모든 경우의 수를 조합해 대입을 시도한다.

이론상으론 공격에 충분한 시간만 주어진다면 (모든 문자에 대한 조합을 시도해 볼 수 있기 때문에) 언젠가는 비밀번호를 맞히게 될 것이다.

다만 현실적으로는 암호의 길이와 복잡도의 증가에 따라 공격에 걸리는 시간이 기하급수적으로 늘어나므로 무조건 성공한다고 보기 어렵다.

무작위 순차 대입의 공격의 소요 시간을 줄이기 위해 미리 정의된 문자열 목록을 이용하기도 하는데, 이어서 알아보자.

1.1.2 사전(Dictionary) 대입

상당한 시간이 소요되는 무작위 순차 대입 방식 단점을 극복/보완하는 방법으로, 미리 정의된 문자열 목록을 대입하는 방법이다.

사전 파일을 이용한 공격이라고 해서 '사전 공격(Dictionary Attack)' 이라 한다..

미리 정의된 비밀번호 사전(Dictionary)을 준비하여 하나씩 대입해 보는 방식이다. 여기서 사전(Dictionary)파일은 그동안 통계적으로 많이 사용되어 오거나, 사람들이 흔히 사용할법한 비밀번호 조합을 미리 목록 형태로 정의해 둔 파일이다.

사람들은 의외로 단순한 비밀번호를 많이 사용하며 또한 여러 서로 다른 사이트에 걸쳐 동일한 비밀번호를 사용하기도 한다.

이런 환경에서, 사전 대입 방식은 브루터 포스 공격에 소요되는 시간을 극적으로 줄이면서도 공격 성공률을 높이는 아주 효율/효과적인 공격 기법이다.

1.2 Brute Force in OWASP TOP 10 2017

OWASP TOP 10에서도 브루터포스 공격과 관련한 보안 위험 항목을 제시하고 있다.

TOP 10의 2위에 포지셔닝한 'A2. 취약한 인증'에서 브루터 포스 위협을 언급하고 있다.

2. 브루트 포스(Brute Force) 공격 실습

앞서 언급한 청와대사건의 김재열씨처럼,
스스로 추측한 비밀번호를 사용해 수동으로 브루터포스 공격을 시도해 볼 수 있다. 즉 직접 사이트에 접속해서 로그인 해 보는 것이다.

아마 공격자는 지인이나 다른 사람의 아이디 몇개 정도는 이미 알고 있을 것이며, 그들에게 의미있는 숫자나 문자(생일 or 전화번호 or 이성친구 이름 등)를 추가로 알고 있다면 이를 바탕으로 직접 로그인을 시도해 볼 수 있다.

또한 흔히 관리자 계정으로 사용되는 admin 이나, master와 같은 아이디와 1234, qwer과 같은 비밀번호로 직접 로그인을 시도해 볼수도 있을 것이다.

그러나 정말 의심되는 아이디와 비밀번호가 있는게 아니라면, 수동 공격은 매우 비효율적이다. 

대부분의 브루터포스 공격은 툴을 이용한 자동화된 공격을 수행한다.

이제부터 툴을 이용해 브루터포스 공격을 실습해 보자.

2.1 무차별 대입 공격 시도

2.1.1 DVWA 사이트 접속

먼저 XAMPP Control Panel을 실행해서 Apache 웹서버와 MySQL 데이터베이스를 시작한다.

서비스가 정상적으로 시작되었다면, http://localhost/dvwa 로 접속하여 DVWA 사이트로 접속한다.

로그인 창이 뜨면 DVWA의 기본 계정인 'admin / password'를 입력하고 로그인 한다.

로그인 후, 좌측 메뉴에서 DVWA Security를 클릭하고 Security Level을 Low로 변경한다.

Security Level 설정을 마쳤으면, 다시 좌측 메뉴에서 Brute Force 를 클릭한다.

이 메뉴에수는 Brute Force 공격을 시도해 볼 수 있도록 개발된 로그인 폼을 제공한다.

2.1.2 Burp Suite 실행

Burp Suite를 실행해서 Temporary project를 기본값으로 하여 생성한다.

DVWA 사이트의 로그인 요청에 대한 패킷을 캡쳐할 것이다.

앞에서, 접속한 DVWA 사이트의 Brute Force 메뉴에서 admin / 1234로 로그인 해 본다.

이 로그인 요청 패킷이 Burp Suite에 의해 캡쳐되었을 것이다. 

Proxy메뉴의 HTTP history 탭에서 해당 요청을 Intruder로 보낸다. (해당 요청을 우클릭하여 'Send to Intruder'를 선택한다.)

그리고 Burp Suite의 Intruder 메뉴를 클릭한다.

Intruder 메뉴의 Positions 탭에서 아래와 같이 password 부분만 § 로 감싸준다.(§로 감싼 부분은 다른 값으로 치환되는 부분임을 지정한다. 일종의 변수인 셈이다.)

처음엔 많은 부분이 §로 감싸져 있을 것이다. 우측의 'Clear §' 버튼을 클릭해서 §로 감싼 부분을 모두 제거하고 password 값(여기서는 1234)만 선택하여 우측의 'Add §' 버튼을 클릭한다. 그러면 password 값만 §로 감싸질 것이며 이 부분의 값이 계속 대입되면서 요청이 전송됨을 의미한다.

다음으로 Payloads 탭으로 가서 Payload type를 Brute forcer로 선택한다.

Brute forcer로 선택하면 아래 화면에 Character set가 자동으로 생성되어 있는 것을 확인할 수 있다.

기본값은 'abcdefghijklmnopqrstuvwxyz0123456789'로 되어 있다. 

Character set에 문자열은 브루터포스 공격의 무작위 순차 대입을 위한 기준 문자이다. 이 기준 문자가 많으면 많을 수록 공격 시도 횟수와 시간은 증가한다. 그만큼 많은 조합을 시도해야 하기 때문이다.

우리는 이미 admin의 비밀번호가 'password'라는 것을 알고 있다.

테스트 시간 단축을 위해서 Character set 값을 'adoprsw'로 변경한다. 그리고 길이를 8으로 변경한다.

(이렇게 기준 문자열을 줄여도 조합의 수는 꽤 크다. Payload count를 보면 5,764,801라고 나와 있는데 총 조합 가능한 문자열의 수이다. 즉 이만큼의 요청이 발생한다는 의미이기도 하다.)

이제 설정이 마무리 되었다. 

우측 상단에 있는 'Start attack' 버튼을 클릭해서 공격을 시작해 본다.

브루터포스 공격을 시작하면 다음과 같이 자동으로 문자열을 조합해서 하나씩 요청을 보내게 된다. 여기서 조합된 문자열은 앞서 설정한 패스워드 값('$로 감싸진 값)에 하나씩 대입된다.

언젠가는 password로 조합된 문자열을 보내게 될 것이며 이때 응답의 상태나 응답의 크기가 상이한 요청이 바로 공격에 성공한 것일 가능성이 크다. 

요청에 대한 응답의 구조는 웹 사이트마다 다를 수 있으므로 그 결과고 획일적이지는 않을 것이다.

DVWA에서는 로그인 성공과 실패시 페이지 내용이 조금 상이하므로 응답의 크기(Length)가 다른 것이 공격에 성공한 요청이 된다.

2.2 사전(Dictonary) 공격

이번에는 미리 정의된 패스워드 목록 파일(사전 파일)을 가지고 공격을 시도해 보자.

패스워드 사전은 인터넷에 많이 있지만, 여기서는 간단하게 테스트 하기 위해 다음과 같이 직접 생성한다.(아래와 같이 입력하고 pass.txt 파일로 저장한다.)

그리고 아래 화면과 같이, Payload type을 'Simple list'로 변경하고 그 아래에 Simple list 파일을 'Load'하여 앞서 생성한 pass.txt 파일을 불러 온다. 

파일을 정상적으로 불러 왔으면 우측 상단의 'Start attack' 버튼을 클릭해서 공격을 시작한다.

공격 결과를 보면 아래와 같이 password 문자열로 보낸 요청의 응답은 다른 요청과 비교해 응답 길이(Length)가 다른것을 확인할 수 있다. 또한 응답된 html 에서도 로그인 성공시 나타나는 문구가 보인다.

즉 해커는 공격이 성공하여 password가 비밀번호 인 것을 알게 된 것이다. 이제 부터 admin 계정의 권한으로 사이트에 해를 입힐 수 있게 된 것이다.

3. DVWA에서 브루터 포스 공격에 대응하는 방법 알아보기

앞서, DVWA에서는 Security Level을 4단계로 구분하여 각 단계별로 강화된 보안성을 제공한다고 하였다. DVWA에서는 브루트포스 공격을 어떤 식으로 방어하는지, 각 단계별로 살펴보자.

3.1 Low 단계

아무런 보안 조치가 이뤄지지 않은 매우 취약한 상태이므로 당연히 어떠한 방어 코드도 구현되어 있지 않다.

3.2 Medium 단계

DVWA Security 메뉴에서 단계를 Medium으로 변경하고 다시 Brute Force 메뉴로 와서 잘못된 정보로 로그인을 시도해 보자. 

로그인 실패시 응답 시간이 (Low 단계에 비해) 좀더 오래 걸린다는 것을 느낄 수 있다.

하단의 'View Source' 버튼을 클릭해서 소스를 보면 아래와 같이 로그인 실패시 약 2초간 시간 지연을 두고 있다. 

이는 자동화된 브루터 포스 공격의 시간을 지연시킴으로써 공격 시간을 더디게 만들기 위해서이다.

3.3 High 단계

이번에는 Security 레벨을 High로 변경하고 다시 시도해 보자. 로그인 실패시 응답시간이 빠르기도 하고 느리기도 할 것이다.

코드를 보면 다음과 같이 구현되어 있다. 

로그인 실패시 시간 지연을 획일적으로 2초로 하지 않고, 0~3초 사이에 랜덤한 값으로 지정하고 있다.

이는 획일된 반응 시간은 해커로 하여금 지연시간을 추측할 수 있게 만들고 해커는 추측된 지연 시간을 감안해 공격을 자동화 할 수 있기 때문이다. 즉 보다 보안성이 강화되었다고 할 수 있겠다.

3.4 Impossible 단계

가장 보안조치가 강력하게 구현된 단계이다.

로그인 실패를 시도해 보면 다음과 같은 안내 문구가 나타난다. 15분 동안 계정이 잠겼다는 내용이다.

소스코드를 보면 High 단계의 랜덤 지연 시간에 더하여, 로그인 횟수와 최종 로그인 시간을 DB에 저장하여 계정 잠금의 기준으로 삼고 있다. 코드 구현은 보다 복잡해 졌지만 사이트의 안전성은 높아졌다.

지금까지 DVWA에서 브루트 포스 공격을 어떻게 대응하는지 살펴 보았다. 이를 포함하여 전방위적인 보안 대첵을 이어서 알아보자.

4. 브루트 포스(Brute Force) 공격 대응 방안

웹 보안을 위한 조치사항은 주로 웹 서비스를 제공하는 기업 입장에서 대응해야 하지만 브루트 포스 공격은 웹 사이트를 이용하는 이용자 역시 주의를 기울일 필요가 있다.

따라서 이용자 관점과 기업 관점의 두 가지 측면에서 대응 방안을 살펴 보자.

4.1 이용자 관점 대응 방안

4.1.1 안전한 패스워드 사용

오랜동안 사람들은 기억하기 편하다는 이유로 허술한 비밀번호를 사용해 왔다.

> '이거 실화냐?' 가장 많이 쓰이는 쉬운 암호 12가지

허술한 자물쇠로 자신의 집이나 금고를 보호하고 싶지는 않을 것이다. 온라인 세상에서 탄탄한 자물쇠를 다는 첫번째 방법은 안전한 비밀번호를 사용하는 것이다.

1) 길고 복잡한 비밀번호 사용

비밀번호는 길면 길수록 그리고 복잡하면 복잡할수록 알아내기 힘들다. 

무작위 대입 방식의 브루트 포스 공격은 가능한 문자열 조합을 순차적으로 모두 시도해 보는 것이기 때문에 비밀번호가 길고 복잡해 질 수록 공격에 소요되는 시간은 기하급수적으로 늘어난다. 

따라서 가장 기본적인 대응방안은 길고 복잡한 비밀번호를 사용하는 것이다.

아래의 사이트에서 비밀번호의 안전성을 테스트 해 볼 수 있다.

https://howsecureismypassword.net/

아래 화면은 비밀번호 '1234'로 테스트 해 본 결과이다. 암호가 크래킹되는데 걸리는 시간이 'INSTANTLY(즉시)' 이다. 그리고 비밀번호가 숫자로만 이뤄졌고 매우 짧다고 경고하고 있다.

다음으로 비밀번호를 길고 복잡하게 'dnpqqhdks@7#9'로 테스트 해 볼 결과이다. 비밀번호를 알아 내는데 엄청난 시간이 소요되므로 안전하다고 알려 주고 있다.

2) 유추하기 힘든 패스워드 사용

일반적으로 사람들은 자신이 기억하기 쉽게 하기 위해, 자신의 개인 정보와 비밀번호를 연관시키는 경우가 많다.

예를 들어 자신의 생일, 기념일, 차량번호, 휴대전화번호 같은 것들을 비밀번호로 사용한다.

이런 개인적 의미의 비밀번호는, 특히 그(그녀)를 알고 있는 누군가는 쉽게 유추할 수 있는 비밀번호이다. 기억하기 바란다. 가장 흔한 브루터 포스 공격은 당신 지인의 행위일 수도 있다는 것을...

또한 개인정보와 연관되지 않더라도 쉽게 유추할 수 있는 비밀번호가 있는데, 아래와 같이 통계적으로 많이 사용되어온 의미있는 단어들이다.

football, qwertyuiop, 123qwe, iloveyou, rainbow, alaska, ....

이런 단어들의 목록은 인터넷에서 아주 쉽게 구할 수 있다.

'사전 공격'에서 사용되는 파일에는 수천만개 이상의 비밀번호 조합이 존재한다. 따라서 유추하기 힘든 자신만의 비밀번호 조합을 사용하는 것이 좋다.

4.1.2 서로 다른 사이트에는 서로 다른 비밀번호 사용

우리은행 해킹 사례에서도 보듯이 서로 다른 사이트에 동일한(또는 거의 유사한) 비밀번호를 사용하는 것은 피해가 확대되는 결과로 이어진다.

한 사이트에서 탈취한 계정 정보는 다른 사이트의 브루터 포스 공격용 '사전(Dictionary)'으로 사용된다.

따라서 서로 다른 사이트라면 서로 다른 비밀번호 사용을 권장한다.

다만 필자도 이게 얼마나 귀찮은 건지 잘 알고 있다. 서로 다른 비밀번호는 기억하기 쉽지 않다. 필자의 경우에도 서로 다른 비밀번호를 사용하다가 비밀번호를 잊어 먹어 애먹은 적이 한두번이 아니다.

그나마 보완책이라면, 서로 다른 비밀번호를 생성하더라도 일종의 자신만의 규칙과 패턴을 사용하는 것이다. 물론 그 패턴은 쉽게 유추되지 않는 것이어야 한다.

---

결국 이용자들은 스스로 자신을 보호하기 위해 '안전한 비밀번호'를 사용해야 한다.

KISA 에서는 안전한 비밀번호 사용을 위해 안내서를 제공하니 아래 링크를 참조하기 바란다.

패스워드 선택 및 이용 안내서 바로가기

4.2 기업 관점 대응 방안

4.2.1 안전한 패스워드 규칙

앞서 '이용자 관점'에서도 언급한바 있는데, 비밀번호를 길고 복잡하게 만들도록 규칙을 강제하는 것이다. 또한 이용자의 공개된 개인정보가 비밀번호로 사용되는 것을 경고할 필요가 있다.

이용자가 알아서 복잡하고 유추 불가능한 비밀번호를 생성해 주면 고맙겠지만, 그렇지 않은 경우도 많으니 아예 규칙으로 강제하는 것이다. 현재 많은 사이트들에서 비밀번호 복잡성 규칙을 강제하고 있다

4.2.2 로그인 시도 횟수 제한

브루터포스 공격은 임의의 문자열을 무차별 대입해 보는 공격이므로 많은 로그인 시도와 로그인 실패를 반복하게 된다. 따라서 자동화되고 반복적인 시도를 불가능하게 만들기 위해 로그인 실패가 누적될 경우, 특별한 조치를 취하는 것이다. 이때 조치는 다음과 같은 형태가 될 수 있다.

1) 계정 잠금

로그인 실패가 일정 횟수 이상이 되면 더 이상 로그인 시도를 할 수 없도록 계정을 잠그는 것이다.

이렇게 하면, 자동화된 툴로 수 많은 로그인 시도를 할 수 없거나 힘들게 되어 공격 성공율이 엄청 떨어지게 된다.

잠긴 계정을 푸기 위해서는, 일정 시간이 지나면 자동으로 풀어주거나 추가 본인 확인을 거쳐 풀어주는 방식이 있다.

2) 캡챠 요구

앞의 계정 잠금 보다는 조금 완화된 방법이다. 로그인에 반복적으로 실패할 경우, 캡챠를 같이 입력하도록 한다. 아래 화면은 네이버의 로그인 실패 후, 캡챠가 나타나는 상황을 보여준다.

브루터 포스공격의 자동화되고 반복적인 로그인 시도 자체를 불가능하게 하여 이 공격의 기본 매커니즘을 흔들어 버리는 것이다. 이 방식은 공격자의 공격 의지를 상당히 깍아 내리므로 아주 효과적이라 하겠다.

4.2.3 다중 인증

ID, PASSWORD 이외에 추가 인증 수단을 제공하는 방식이다. 이 글에서 말하는 '다중 인증'은 일반적인 보안에서 말하는 '2 factor 인증'과는 그 개념을 구분하고자 한다.

'2 factor 인증'은 지식 기반인 비밀번호외에 소유기반인 휴대전화, OTP, 보안카드 또는 생체기반인 지문과 같은 인증 요소를 둘 이상 결합한 인증 방식을 말한다.

반면 여기서 말하는 '다중 인증'은 ID, PASSWORD외에 추가로(그게 무엇이든) 입력 받도록하는 인증 방식을 말한다.

1) 기기 인증

ID, PASSWORD 뿐만 아니라 로그인을 시도하는 기기도 인증하는 방식이다. 현재 이 블로그 서비스 제공하는 업체인, 티스토리도 기기 인증을 지원한다.

관리자 모드에서 기기인증을 활성화 할 경우, 한번도 접속한적 없는 기기에서 로그인을 시도하면 다음 화면과 같이 기기 인증을 받도록 되어 있다.

해커의 경우, 정상 이용자의 기기와는 다른 기기에서 로그인을 시도 할 것이기 때문에 로그인 시도를 할 수가 없게 될 것이다.

주의할 점은, 기기 인증시 기준값이 되는 기기의 고유값을 HTTP Request 정보에만 의존한다면 (비보안 HTTP 환경에서는) 해커가 얼마든지 그 값을 변조할 수 있으므로 주의를 요한다.

2) 캡차 추가

앞서 계정 잠금 후, 캡챠를 사용할 수도 있지만, 처음부터 로그인 시 캡챠를 같이 요구할 수도 있다.

아래 그림은 워드 프레스의 로그인 폼에 캡챠가 적용된 모습인데, 이와 같이 로그인 할 때 캡챠를 함께 사용하는 것이다.

이 캡챠의 경우, 매번 캡챠의 문자가 바뀌는 형식인데, 브루터포스 공격을 시도할 때 문자가 매번 바뀌기 때문에 공격을 자동화 시키기 아주 힘들어진다. 

물론 캡쟈 자체의 보안성이 높아야 하는 것은 당연하다.

요즘은 네이버나 구글과 같은 대형 인터넷 업체에서 무료로 캡챠를 사용할 수 있도록 제공하니 참고 바란다.

> 네이버 캡챠 API

> 구글 reCAPTCHA

앞서 이 글에서의 '다중인증'과 보안에서의 '2 factor 인증'을 구분하길 원했지만 2 factor 인증을 다중인증 수단으로 사용할 수도 있다.

예를 들어 로그인 시 ID/PASSWORD 외에 OTP 번호를 요구하거나 메일 인증을 추가할 수도 있다.

'2 factor 인증'을 사용하면 브루터 포스 공격을 거의 완전하게 방어 할 수 있을 것이다.

하지만 (정말 보안이 중요한 곳이 아니라면) 사용 편의성이 너무 떨어지기 일반적인 사이트에서 로그인 보안으로는 좀 과한 느낌이 있다.

4.2.4 강력한 로깅과 모니터링

지금까지 알아본 많은 방어책들이 잘 갖춰져 있다 하더라도 운영 중 모니터링은 필수 요소이다. 

모니터링을 하려면 로그인 요청과 실패에 대한 사항을 기록하고 감시해야 한다.

그리고 이상 현상에 대한 임계치를 설정하고 임계치에 도달 할 경우, 관라지에게 자동으로 Alerting 되도록 모니터링 체계를 구축하는 것이 바람직 하다.

또한 이렇게 모니터링해서 이상현상이 감지되면, 공격용으로 의심되는 IP에 대한 조사 및 블럭킹 등 적극적인 조치가 뒤따라야 한다.

INTRO

이 글에서는,
웹보안을 공부하고 해킹을 실습해 볼 수 있는 툴을 알아보고 설치 방법을 간단히 안내 하고자 합니다. 

사실 웹보안 시리즈를 연재하고자 마음을 먹고서는, 개요부터 쭉~ 한번 훓고 가려 했는데요.
개요 작성에는 시간이 좀 더 필요할 것 같아서, 바로 본론으로 들어갑니다.

중간에 틈이 나면 전반적인 개요을 한번 다뤄볼까 합니다.

미리 말씀드리자면,
개요에서는 웹 보안의 중요성이나 해킹사례, OWASP Top 10과 같은 국제적 참고자료와 웹 보안 관련한 국내 현황과 법률 사항 등 전반의 내용을 다룰 예정입니다.

사실 과거(2006년)에 웹 보안 글을 몇개 끄적인 적이 있습니다. 
당시에서 큰 보부를 가지고 웹보안 전반을 다룰려고 했으나, 그러질 못했네요.

이번에는 인생의 숙제(?)라 생각하고 웹 보안 전반을 다뤄보고자 합니다.

과거 글들은 아래 링크를 참고하세요.(지금 다시 보니 글에 미숙한 점이 많이 보이네요 ^^;)

자 이제 본론으로 들어갑니다.

저의 개발 환경은 '64bit 윈도우 10 Pro' 환경입니다. 이 글에서 소개하는 툴들은 다른 환경(Linux, OS X)에서도 동작가능합니다. 다만 여기서는 윈도우 환경만 설명합니다.

많은 툴들이 있겠지만, 여기서는 앞으로 제가 진행할 웹 보안 Article에서 사용될 몇 가지에 대해서만 알아봅니다. 만일 여기서 소개되지 않은 툴을 제 글에서 다룬다면, 툴 설명을 별도로 추가하겠습니다.

참고로 이 글에서는 설치 과정을 세세하게 설명하지는 않습니다. 설치와 관련된 사항은 이미 인터넷에 많은 자료가 있으니 참고 바랍니다. 물론 그럼에도 설치 문제를 해결하지 못한 경우 편하게 댓글로 문의 주세요.

좋은 도구는 높은 생산성과 직결합니다. 아래 소개한 도구를에 익숙해지길 바랍니다.

---------------------------------------------------------------------------------------------------------------

1. XAMPP (Cross-platform Apache, MariaDB, PHP, Perl)

XAMPP는 APM(Apache, PHP, MySql) 환경구축을 한번에 할 수 있도록 하는 패키지 프로그램이다.

아래 설명할 DVWA 사이트가 PHP와 MariaDB로 구현되어 있는데, 이 사이트를 로컬 PC 구동시키기 위해서 APM 환경이 필요하다.

1.1 XAMPP 다운로드 및 설치

아래 사이트로 가서 XAMPP 설치파일을 다운로드 받는다.

www.apachefriends.org

각 OS 별로 설치 프로그램을 제공하는데, 필자의 경우 현재 시점의 최신 버전의 윈도우용 설치파일을 받아서 설치했다.

(현재 시점 최신 버전) XAMPP for Windows 7.3.0 (PHP 7.3.0)

다운받은 파일을 기본 설정으로 하고 '다음 > 다음 ..' 하여 설치한다.

(설치 과정중 Select Components 단계에서, 불필요한 환경을 제외할 수 있다. 필자 역시 Apache, MySQL, PHP외에 불필요한 것은 설치에서 제외 시켰다)

(그리고 설치 경로를 기억해 두자. 기본값으로 설치했다면 'C:\xampp' 일 것이다)

1.2 XAMPP Control Panel 을 통한 서비스 제어

XAMPP 설치가 완료되면 XAMPP Control Panel이라는 관리패널이 실행된다.

XAMPP Control Panel은 서비스들을 컨트롤 할 수 있는 관리 기능을 제공하는 프로그램이다.

(참고로 XAMPP Control Panel이 실행되면 윈도우 트레이 아이콘에 자동 추가 되므로 창을 닫아도 프로그램이 종료되는 것은 아니다. 프로그램을 종료하려면 트레이 아이콘을 우측 클릭하여 Quit 하면 된다.)

(또한 XAMPP Control Panel 프로그램을 종료(quit)한다고 해서 Apache나 MySQL이 같이 종료되는 것은 아니다. 이 프로그램은 말 그대로 편의성을 위해 별도로 제공되는 GUI 기반 프로그램일 뿐이다)

위 화면에서 보는바와 같이, Apache와 MySQL을 구동(Start)시키자.

브라우저에서 http://127.0.0.1 로 접속해보자. 다음 그림과 같이 XAMPP 대시보드가 로딩된다면 성공적이다.

1.3 설치 및 구동 실패 해결

설치 과정이나 설치 후 Apache, MySQL을 구동 시킬때 제대로 동작하지 않는 경우가 종종있다.

이는 대부분 XAMPP가 사용하는 포트와 서비스가 충돌되기 때문이다.

1.3.1 아파치 구동 실패

Apache 웹서버의 경우 기본 80포트를 사용하는데, 이미 로컬 PC에 80포트가 사용되고 있는 경우 Apache 웹 서버를 시작할 수 없다. (필자의 경우에도 로컬 PC에 IIS 웹서버가 동작중인데 80포트를 사용하는 사이트가 있어서 포트를 변경하였다.)

80 포트를 이용하는 서비스를 찾아서 포트를 변경하던지 해당 서비스를 중지 시키던지 한다. 

다음 명령어를 통해 현재 로컬 PC의 포트와 서비스 PID를 확인할 수 있으니 참고하자.

netstat -ano

(XAMPP Control Panel 에서도 바로 포트를 확인할 수 있도록 기능을 제공한다. 관리 패털의 우측 상단에 있는 'Netstat' 버튼을 클릭하면 포트와 PID 확인이 가능하다.)

1.3.2 MySQL 구동 실패

로컬 PC에 MySQL이 이미 설치되어 있는 경우, path 관련 오류(MySQL Service detected with wrong path)가 나면서  MySQL이 구동되지 않을 것이다.

될수 있으면 기존 설치된 MySQL을 제거하는 것이 가장 단순한 해결 방법이다.

관리자 계정으로 cmd(명령프롬프트)를 실행하고 다음의 명령어로 해당 MySQL을 제거하면 된다.
(기존 MySQL에 있는 오브젝트들은 미리 백업 받아 두는 것이 좋다)

sc delete mysql 

만일 기존에 설치된 MySQL과 XAMPP의 MySQL을 동시에 같이 사용하고 싶을 경우, 다음의 글을 참고하자. (포트와 서비스 명을 서로 다르게 하여 두개의 MySQL 인스턴스를 띄우는 방식이다.)

http://emjaywebdesigns.com/xampp-and-multiple-instances-of-mysql-on-windows/

1.4 DVWA를 위한 XAMPP 셋팅

1.4.1 dvwa 데이터베이스 생성

XAMPP 웹(http://127.0.0.1)에 접속하여 상단의 phpMyAdmin 메뉴로 이동한다.

phpMyAdmin은 웹으로 MySQL을 관리할 수 있는 프로그램이다. 상단의 '데이터베이스' 메뉴로 이동하여 dvwa라는 이름으로 새 데이터베이스를 만든다.

1.4.2 php.ini 파일 수정

'C:\xampp\php\php.ini' 파일에서 다음 값이 Off로 되어 있다면 On으로 변경하고 저장한다

이 설정이 필요한 이유는, dvwa 사이트에서 url include을 사용하기 때문이다. 

Apache 웹서버를 재기동 하면 변경된 설정 값이 반영된다.

2. DVWA(Damn Vulnerable Web Application)

DVWA는 그 약자에서도 알 수 있듯이 의도적으로 취약하게 만든 웹 사이트이다. 

보통 웹해킹을 공부하고 직접 시도해 볼려면 여의치가 않다. 임의의 공개된 사이트에 테스트로 해킹을 시도 했다가는 법률적 제재를 받을 수도 있다.

그렇다고 직접 개발하기도 만만치가 않다.

DVWA는 PHP/MySQL 기반으로 제작된 웹 애플리케이션으로, 웹 해킹 기술을 직접 실습하고 공격 대응 방안을 학습하기 위한 목적으로 제작되었다.

다음은 DVWA 사이트에서 발췌한 설명이다.

2.1 DVWA 다운로드 및 설치

아래 주소로 이동하여 DVWA-master.zip 파일을 다운로드 받는다

http://www.dvwa.co.uk/

다운 받은 파일의 압축을 풀고 DVWA-master 폴더의 하위 내용물들을 모두 다음의 위치로 옮긴다

C:\xampp\htdocs\dvwa 

(XAMPP 웹으로 접속 가능하도록 htdocs 폴더 하위에 dvwa라는 이름의 폴더를 생성하여 그 아래로  DVWA-master 폴더 내용을 이동(or 복사) 한다.)

파일들이 정상적으로 이동되었다면, 다음의 주소로  dvwa 사이트에 접속할 수 있다.

http://127.0.0.1/dvwa

위 주소로 최초 접근하면 다음과 같은 Setup 화면이 나오고 추가 설정을 해 줘야 한다.

여기서 빨간색으로 나온 부분을 모두 잡아줘야 사용이 가능해 진다.

reCAPTCHA key 가 설정되지 않아서 빨간색으로 표시되어 있다. 키를 발급 받는 방법을 알아보자.

2.2 reCAPTCHA key 발급 받기

DVWA에서 캡챠 관련 공격을 테스트 하기 위해 필요한 설정이다. reCAPTCHA 키를 받기 위해서 다음의 주소로 접속한다

www.google.com/recaptcha/admin

구글 계정으로 로그인해야 키 발급이 가능하다. 로그인 후 다음 그림과 같이 입력하고 폼을 제출한다.

폼을 제출하면 Site Key와 Secret key가 생성된다. 이 두 키 값을 dvwa 설정 파일에 등록해야 한다.

2.3 설정 파일 수정

먼저 config 폴더에 있는 config.inc.php.dist 파일 이름에서 '.dist'을 제거한다.

2.3.1 reCAPTCHA key 설정

config.inc.php 파일을 열어서 다음의 내용을 설정한다. 앞서 발급받은 key들을 다음과 같이 알맞게 지정한다.

2.3.2 DB 접속 패스워드 수정

config.inc.php 파일의 DB 패스워드를 다음과 같이 패스워드를 공백으로 변경한다.

이제 dvwa 설정이 완료되었다. 앞서 접속한 dvwa 설정화면을 새로고침 해보면 reCAPTCHA key 가 녹색으로 표시된것을 확인할 수 있다.

2.4 데이터베이스 생성

마지막으로 dvwa 데이터베이스에 관련 오브젝트들을 생성한다.

설정화면에서 'Create / Reset Database' 버튼을 클릭해서 관련 테이블등을 생성하자

dvwa로 해킹 실습을 해 보다가 데이터를 초기화 하고 싶으면 언제든이 Reset 할 수도 있다.

2.5 DVWA 사이트 접속

이제 DVWA를 위한 모든 설정이 완료되었다.

http://127.0.0.1/dvwa/ 로 접속하여 사이트를 확인해 보자

로그인 창이 뜨면 admin / password로 입력한다. 다음 그림과 같이 DVWA 사이트를 확인할 수 있다.

사이트를 한번 쭉 훓어 보기 바란다.

3. Burp Suite 설치

웹 사이트 테스트 및 해킹 용도로 자주 사용되는 웹 프록시 프로그램이다.웹 요청을 프록시를 경유하도록 만들어서, 중간에 패킷을 가로채어 조사하고 변조해 볼 수 있다.

Burp Suite는 프록시 기능을 넘어, 실제 웹 해킹을 자동화 해서 수행할 수 있는 기능도 제공한다.

유료와 무료 버전이 존재하며 우리는 무료인 커뮤니티 버전을 설치한다.

3.1 Burp Suite 다운로드 및 설치

아래 주소로 이동하여 커뮤니티 버전의 설치 파일을 다운로드 받아서 설치한다.

https://portswigger.net/burp/communitydownload

3.2 브라우저 프록시 설정

3.2.1 프록시 설정 확인

Burp Suite는 기본 8080 포트로 프록시 역할을 수행한다. 다음 그림은 Burp Suite를 실행해서 Proxy 옵션을 확인하는 화면이다. 여기서 프록시 리스닝 포트를 변경할 수 있지만 여기서는 기본값을 사용한다.

3.2.2 브라우저에 프록시 설정하기

필자가 사용하는 구글 크롬 브라우저를 기반으로 프록시 설정을 알아본다.

크롬 브라우저의 설정화면으로 이동한다. 상단의 '설정 검색'에서 '프록시' 라고 검색한다.

'프록시 설정 열기'를 하여 LAN 설정에서 프록시 서버 사용을 활성화하고 IP(localhost)와 포트(8080)를 입력한다.

이렇게 브라우저에 프록시가 설정되면, 이제부터는 모든 웹 요청과 응답은 이 프록시를 경유하게 된다.

이로써 기본적인 툴 설치와 환경 설정이 완료 되었다. 이제부터 본격적으로 웹보안 공부를 시작해 보도록 하자

수고 하셨습니다~~~~~~~~~~~~~~~~

우연히.. 페이스 북을 보다가 다음의 슬라이드를 접하게 되었다.

>> 개발자를 위한 (블로그) 글스기 intro - 변성윤 -

나도 한때 개인사이트 활동 나름 열심히 했었지... 하면서 슬라이드를 읽다가...

'좋은 글 많이 보기'라는 슬라이드에서 '국내 개발자 블로그 모음'이라는 링크를 타고 들어가 본다.

>> 국내 개발자 블로그 모음(awesome-devblog)

혹시나 내 이름도 있을까?.. 하고 찾아보니 (고맙게도) 목록에 추가되어 있었다

그런데.. 설명에 적힌 내용이 '기술사' 다.

다른 사람들의 블로그는 Back-end니, iOS니 빅데이터니 하는 특정 기술 분야를 언급했는데 내 블로그는 '기술사'다

음... 좋은건지.. 나쁜건지.. 하며 스스로 의아해 한다.

이 블로그가 특정 기술분야를 정해 놓지 않고 있는 탓일테다.

...

사실 한때 한창 닷넷 개발자로 일할 때, 적극적으로 글을 쓰곤 했었는데 그때의 사이트는 이 블로그가 아니었다. 

http://mkex.pe.kr

http://mkexdev.net

두 사이트는 아직도 존재하지만 관리하지는 않는다.

아마 그 시기에 이 분이 목록을 정리했다면 닷넷으로 소개 되었으리라.

어쨌던 그리 열심히 글을 적지 않는데도, 목록에 추가해 준 걸 보니 고맙기도 하고 뭔가 책임감이 들기도 하네. (기술사 관련 글을 좀 적어야 하나??)

좀 더 열심히 포스팅 해야 겠다.(내가 누군가의 글에서 도움을 받았듯이..)

12 Factor App 원칙에서는...
애플리케이션의 환경설정 정보를 코드로부터 분리하여 외부화하는 것을 그 원칙 중 하나로 제시하고 있다.

이는 환경에 따라 달라지는 설정 정보를 소스로부터 분리하여 둘 간의 결합도를 낮추어 유지보수성을 좋게하기 위한 설계 원칙이다.

이런 관점에서, 가장 최악의 선택은 설정정보를 소스코드의 상수로 관리하는 것이다.
요즘 왠만한 프로젝트에서는 상수기반 설정정보를 잘 사용하지는 않는다.

* 설정정보를 소스코드에서 분리시키기

설정 정보를 별도의 소스코드와 분리된 별도의 파일로 관리하는 것이 일반적이다.

스프링 부트 기반으로 볼 때, 
application.properties 또는 application.yml 파일에 설정정보를 관리한다.

단, 이 방식도 (설정파일이) 프로젝트에 포함된 경우라면, 설정정보의 변경이 필요할 경우, 애플리케이션 전체를 다시 빌드하고 배포해야 하는 종속성 문제가 생긴다.

(설정정보를 프로파일로 구분할 수 있는 것도 하나의 해결책이긴 하지만, 이는 프로파일의 종류가 정해진 경우에는 유용하나, 동일한 프로파일내에서의 변경사항은 여전히 종속성 문제를 내포하고 있다)

* 설정정보를 배포 패키지에서 분리시키기

설정정보 파일을 애플리케이션 배포 패키지에서 분리시키기 위한 방법이 몇 가지 존재하긴 한다.

자바 기반 프로젝트로 보면,
1) 애플리케이션 실행 시, 설정정보 파일 위치를 옵션에 명시
2) @PropertySource 어노테이션으로 설정정보 파일 위치 명시
3) 시스템 자체의 환경설정 정보를 읽어오는 System.getProperties() 사용하기

이 중 1)번 방식을 선호하기는 하지만, 이 또한 설정정보 변경이 발생하면 애플리케이셔을 중지했다가 다시 구동해야 하는 종속성 문제가 발싱한다.

* 설정정보를 원격 서버에서 제공하기

Spring Cloud 프로젝트에서 제공하는 Spring Cloud Config 서버를 활용하면 원격지 서버에서 설정정보를 서비스 할 수 있게 해준다.

그리고 설정정보를 동적으로 변경하여 (애플리케이션의 재빌드나, 재구동 없이) 실시간으로 반영시킬 수 있도록 하는 메커니즘을 제공하며 git이나 svn 기반으로 설정정보의 버전 관리를 지원해 준다.

* Spring Cloud Config 서버-클라이언트 구현

1. git 저장소와 설정파일 생성

1) git 저장소 생성
여기서는 설정정보 저장소로 로컬 git을 사용하기로 한다. git 을 설치하고 git 저장소를 init 명령어로 지정한다.

> git init

2) 설정파일 생성
다음의 규칙으로 설정파일 이름을 지정하고 설정정보를 파일에 입력한다.

3) 설정파일 커밋
생성한 설정파일을 git에 add하고 commit 한다.

> git status

> git add -A

> git commit -m "config file create"

4) Config 서버의 설정정보 확인
Config 서버에서 설정정보를 확인하기 위해서는 다음과 같은 규칙으로 접속한다.

아래는 프로파일이 없는 경우와 dev 프로파일에 접속하는 예를 보여준다

> http://localhost:8888/my-service/default

> http://localhost:8888/my-service/dev

2. Spring Cloud Config 서버 구현

1) Config 서버 프로젝트 생성
스프링 부트 프로젝트로 Config Server와 Actuator을 의존성으로 선택하고 생성한다.
(스프링 부트 2.0은 Spring Cloud Finchley.M9 버전을 사용한다)

2) Config 서버 설정
bootstrap.yml을 resource 폴더에 생성하고 다음과 같이 설정한다.

설정파일이 관리될 로컬 git 저장소를 지정하고, Config 클라이언트를 구분할 목적으로 서브디렉터리를 만들고 searchPaths로 서브디렉터리를 지정해 준다.

2. Spring Cloud Config 클라이언트 구현

1) Config 클라이언트 프로젝트 생성
스프링 부트 프로젝트로 Config Client를 의존성으로 선택하고 생성한다.
(스프링 부트 2.0은 Spring Cloud Finchley.M9 버전을 사용한다)

2) Config 클라이언트 설정
bootstrap.yml을 resource 폴더에 생성하고 다음과 같이 설정한다.

3) 설정 정보 사용하기
@Value 어노테이션을 사용하거나 @ConfigurationProperties 어노테이션을 사용하여 Config 서버로 부터 설정정보를 매핑하여 사용할 수 있다.

* Config 서버의 가용성

Config 서버가 1대 뿐이라면 SPOF(single point of failure, 단일장애지점)가 된다.
SPOF는 라이브환경에서는 언제나 재앙의 대상이 되곤 한다.

하지만 Config 서버의 구동방식을 보면 일반적인 SPOF에 비해 그 부담이 다소 적다.

1) 운영중 가용성
Config 서버와 연동하는 클라이언트는 최초 구동시에만 서버에서 설정값을 읽어온다.
이후 부터는 클라이언트 측에 로컬 캐시되어 더 이상 Config 서버와 통신하지 않는다.

다만, 설정정보가 갱신될 경우 클라이언트의 /actuator/refresh 엔드포인트를 사용해서 서버에서 새로운 값을 다시 읽어 오도록 하는데, 이때도 서버가 응답이 없다면 기존 로컬 캐시값을 사용한다

즉 Config 서버가 다운되었다고 하더라도 클라이언트들은 다운되거나 하지 않는다는 말이다.
(단 서버의 변경 값을 동기화하지 못할 경우, 일관성 문제는 생길 수 있다)

2) 최초 구동시 가용성
그렇다면, 클라이언트가 최초 구동될 때 Config 서버가 다운된 상황이라면 어떨까?
이때의 가용성을 위해서 fail-fast 값을 false(기본값)로 준 것이다.
fail-fast 값이 true로 설정되면, Config 서버와 연결하지 못하면 클라이언트는 구동되지 않게 된다.

어떤 선택이 더 나은지는 환경에 따라 다를 것이다.

만일 Config 서버가 이중화되어 있지 않은 상태에서 최소한의 가용성을 확보하기 위해서는 이 값을 false로 하는 것을 생각해 볼 수 있다.

즉 Config 서버가 다운된 상황에서도 클라이언트 프로그램은 구동되도록 하는 것이다.

물론 이렇게 하면 Config 서버로 부터 설정정보를 받아오지 못하는 문제가 생긴다.

이를 위해서 클라이언트에서는 동일한 설정정보를 자신의 설정파일에도 가지고 있으면 된다

이렇게 되면 Config 서버와 연결이 실패한 클라이언트는 동일한 설정을 자신의 설정파일로 부터 읽어 들이게 된다.

이것은 그야말로 최소한의 가용성 확보를 위한 전략이 될 것이다.

3) 보다 나은 가용성
Config 서버자체를 이중화하는 것이다.
로드밸런서를 두고 Config 서버를 이중화하면 장비 차원에서 가용성 확보가 된다.

이때 생각해 봐야 할 문제는 git 저장소의 동기화와 가용성 문제이다.

Config 서버를 이중화 할 경우에는,
로컬 git 저장소를 사용하지 말고 원격의 중앙 git 저장소를 사용하도록 한다.

 원격 git 저장소의 고가용성을 위해서는 다음 글을 참고 하자

https://about.gitlab.com/high-availability/

* 설정 정보의 실시간 동기화

Config 서버의 설정정보가 변경되면 이를 의존 하고 있는 클라이언트 프로그램들에게 알려줘야 하낟.

이때 사용되는 것이 @RefreshScope 어노테이션과 /actuator/refresh 엔드포인트이다.

이 두 작업은 클라이언트 측에서 수행되어야 한다.

실시간 동기화가 필요한 곳, 즉 설정정보를 엑세스 하는 클래스에 @RefreshScope 어노테이션을 붙여 준다.

그리고 클라이언트의 주소에 /actuator/refresh 엔트포인트로 POST (Body는 빈 값으로) 전송을 하면된다.

이렇게 하면 클라이언트 로컬에 캐시된 설정 정보를 Config 서버에서 가져온 값으로 즉시 갱신한다.

그러나 Config 서버에 의존하는 클라이언트가 상당히 많은 수일 경우, 모든 클라이언트의 /actuator/refresh 엔트포인트를 명시적으로 호출해 줘야 하기 때문에 유지보수가 까다로워 진다.

 Spring Cloud Bus를 사용하면 메시지 브로커를 통해 변경 이벤트를 구독하여 자동으로 모든 클라이언트에 변경 정보를 자동으로 동기화 할 수 있다.

-------------------------------------------

오랜만에 글을 쓸려니... 느무~~ 귀찮으니무다... 아...

글 쓰기 싫어서 큰일이다. 쩝...

실로 오랜만에 소설책을 완독했다.

1998년도 3개월간 병원에 입원했을 당시, 무라카미 하루키 소설에 매료되어 그의 작품을 꽤나 읽었었다. 그 이후로는 아주 간혹 소설책을 건드려 보긴 했으나 매번 완독하지는 못했다.

주로 전공과 관련된 책이나 자기계발서, 인문학 서적, 역사와 관련된 책을 위주로 읽어 왔었다.

우연히 큰 애가 다 읽고 책장에 꽂아준 것을 보고, 읽게 되었는데 확실히 소설책 답게 흥미롭고 술술 읽혀지는 흥미로운 책이었다.

삼분의 일 정도 읽다가, 늘상 하던데로 어딘가 던져 놓았다가...

어디선가에서 본 소설책을 읽어야 하는 이유라는 글을 보게 되었다.

"한 사람의 일생에서는 다양한 경험을 할 수 없기 때문에 소설책을 통해서 간접경험을 해야 한다"

공감하며, 다시 꺼내어 다 읽게 되었다.

인문학 책은 읽는 속도가 나지 않는데, 이 책은 그야말로 술술 읽힌다.
소설책 특유의 평이한 문체에 내용까지 흥미로우니 한번 읽기 시작하면 좀체 멈추지 않는다.

간만에 소설책을 완독하고 흥미를 가지게 되어 기쁘다.

다시 무라카미 하루키의 소설책을 시작해야 겠다.

작년 11월에 취득한 자격증이 이제서야 도착했다. ㅜ.ㅜ

일주일간 교육을 받고,
마지막 날 이론과 실습 시험을 쳐서 (과락 60점에) 종합 점수 70점 이상이면 합격이다.

교육 수강 요건 자체가 수년 이상의 관련 분야 경력을 요구하고,
시험도 객관식과 주관식, 서술식, 보고서 작성 등 만만치 않게 구성되어 있다.

같이 교육 받은 분들과 이전 교육에서 시험에 떨어져 재시험 본 인원까지 합치면 이번 회차에 적어도 7~80명 이상이 시험에 응시하지 않았나 싶다. 

합격 메일에 수신인으로 되어 있는 사람이 총 4명이었으니,
이를 기준으로 합격자가 4명이라면 합격률이 대략 5% 안밖이라는 계산이 나온다. ㅜㅜ

관련 분야 자격증이 현재와 다른 형태로 재편된다는 얘기가 있던데... 
그래서 그랬는지.... 자격증 발급 시간도 상식 밖으로 오래 걸리고...

이 자격을 어떻게 실무에 자~알 활용할지 고민 좀 해봐야 겠다.

유독 바람이 세차게 불던 날,
부산 본가의 해안 산책로를 걸으며 의미있는 미래가 무엇인지 고민해 본다.

그 고민의 어렴풋한 답은 머릿속을 맴돌지만, 영화나 드라마의 그것처럼 오랜동안 진지하게 생각하지는 못한다.

그리고...

어느 나른한 오후에 별 생각 없이 다시 동네 앞을 나가본다.

여전히 안개 속인 머리속은 찬 바닷바람에도 시원하게 깨어나지 못한다.

매년 명절마다 들러는 여기도 머지않아 뜸해 지겠지 하며 씁쓸해 한다.

언젠가 끝이 있겠지 하면서도 그 언젠가를 영원으로 생각하는 우매함이란...

그대들이여... 더 오래 나와 함께 할 수 있기를 간절히 기원한다.

지난 번 책 버리기(http://m.mkexdev.net/204)에 이어 두 번째로 버릴 책을 엄선(?) 했다.

한번 버려본 경험이 있는지라.... 이번에는 그리 큰 고민 없이 버릴 책을 추려냈다.

애매한 책이 몇 개 있긴 했으나...

그나저나 이 글을 쓰려고, 지난 번의 책 버리기 포스팅을 다시 보니 무려 5년 전 글이 아닌가...

보통 세월보다 기억이 더 멀리 느껴 지는데, 이건 그 반대로구나...

지난번 책 버린 날의 느낌과 그 글을 올린 기억은 아주 가까운데 세월이 한참 흘렸구나 한다.

다음번의 책 버리기는 이 보다는 가까우리라...

지난 일요일에 114회 기술사 시험이 있었다.

1교시 문제를 보고는, 이번 회차는 평이한 수준이 될 것으로 보였다.

2교시도 그럭저럭... 자주 언급되는 토픽들이 대부분이라, 준비 된 사람에게는 그리 어렵지 않은 수준으로 보인다.

3교시는 1문제 정도 선택의 고통이 있었으리라... 예상된다.

4교시도 한 두문제 정도 선택의 고민이 있을 듯 보이고..

중요한 것은 고득점을 노릴 수 있는 유형의 문제가 군데 군데 보인다는 점이다.

전체 문제 중, 두 세 문제 정도에서 고득점을 받는 다면 아주 해피 할 것이다.

<1교시>

<2교시>

<3교시>

<4교시>

(그림출처: LG 사이언스랜드)

주말이면 동네 커피 전문점에 가서 직무와 관련된 공부하거나 책을 읽곤 한다.

얼마전 동네 스타벅스에 가서 자리를 잡고, 커피를 주문하러 갔다.

그 종업원은 왜 앵무새 같이 고객이 알아 듣지도 못하는 말을 반복하며 정확한 사이즈를 원했을까?

(내가 사이즈를 알지 못한다는 것을 그 종업원도 눈치 챘으리라 본다)

예상컨대, 스타벅스 정도 되니 고객응대 메뉴얼이 있을 것이고 그 메뉴얼대로 했을 것이다.

또는 끊임없이 들어오는 고객의 주문을 받다 보니, 정발로 반 로봇이 되어 기계적인 응대을 했을 수도 있다.

아니면, 스타벅스 커피 사이즈도 모르면서 스타벅스 커피를 먹으러 온 내가 괘씸했거나 ㅋㅋ

...

뭐.. 이유야 어찌 되었건 참으로 아쉽다는 생각이 들었다.

커피 전문점은 서비스 업이다.
그리고 스타벅스는 높은 커피 가격의 명분으로 자신들은 '커피'가 아니라 '문화'를 판다고 그럴싸하게 말한다.

그 종업원이 조금만 더 센스가 있었다면 (아니면 조금만 더 주인의식이 있었다면)
얼빵한(?) 고객의 주문에 좀 더 고객 친화적인 대응을 했을 것이다.

이렇게 말이다.