일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 | 31 |
- 스케일 큐브
- 스카우터
- 슬랙 파일업로드
- 슬랙 파일업로드 제한
- 카프카
- kafka
- n-gram
- 알림무시
- 머신러닝
- bag of words
- 슬랙
- Tuckman
- 팀 발달 모델
- Spark
- Slack File Upload
- Scale Cube
- FCM
- Rate Limit
- 웹보안
- 파이어베이스
- Slack Limit
- 코어/컨텍스트
- Scouter
- 해킹
- 자연어처리 #konlpy #형태소분석
- 카프카 성능
- 이미지 푸시
- Core/Context
- Slack Rate Limit
- firebase
- Today
- Total
플랫폼 개발팀 기술 블로그
[웹보안] 브루트 포스(BRUTE FORCE) 공격 본문
INTRO
불과 '반년 전 즈음(2018.06)에 브루트 포스(Brute Force) 공격이 대형 은행을 겨냥해 시도' 되었습니다.
이 사건은 (적어도 당시에는) 다행히 실제 금전적인 피해로 까지는 이어지지는 않은 것 같네요.
공인인증서나 OTP가 해킹된 것이 아닌만큼 출금/이체와 같은 서비스는 건드리지 못했을 겁니다.
하지만 정보유출이라는 측면에서는 꽤나 성공적이여서 고객 정보 56,000건이 유출되었다고 합니다. 유출된 고객의 개인 정보를 악용해 2차 피해가 어떤 식으로 유발될지는 알 수 없는 노릇이죠.
보다 자세한 내용은, 다음의 KBS 보도 영상과 관련 기사를 참고하기 바랍니다.
[ 관련 기사 ]
> [단독] 고객정보 5만 6000건 해킹 당해..우리은행 대처 나서
> 우리은행, 무작위 대입 공격 받아... 고객정보 56,000건 유출
> 우리은행, 이미 유출된 개인정보로 무작위 대입 공격 받아… 고객정보 56,000건 유출
80년대 초에 성행 했다던 브루터포스 공격은, 구식 공격기법이라는 인식과 너무 단순한 공격기법이라는 측면에서 기술이 발전한 근래에는 많이 행해지지 않을 것 같지만 드문드문 사례가 보이네요.
아래에 링크는 '2017년에 발생한 워드 프레스를 대상으로한 대규모 분산 무차별 대입 공격'에 대한 기사입니다.
마치 DDoS처럼 공격에 동원된 IP 수도 많고 각 IP가 막대한 수의 공격을 행했다는 기사를 확인할 수 있습니다. 이 기사에는 공격에 대한 대비책도 안내하고 있으니 참고하면 좋을 것 같습니다.
> 워드프레스를 대상으로 대규모 무차별 대입 공격(Brute Force Attack) 발생
그리고 '2014년에는 iCloud 해킹으로 헐리우드 스타들의 사적인 누드 사진들이 인터넷으로 배포'되는 사건이 있었습니다. 이 역시 브루터포스 공격이 기반이 된 해킹 사례로 언급되는 듯 합니다.
> Apple Patches Brute Force Password-Cracking Security Hole in iCloud
그리고 꽤 오래전 우리나라에서 발생한 재미있는 에피소드가 있는데요...
1993년 '청와대 해킹사건'때 김재열이란 분이 수동으로 브루터포스 공격을 시도해 국제심판소의 PC통신 비밀번호를 알아 내었다고 합니다. (이때 국제심판소의 비밀번호는 무려 '12345'이였다고 하네요.)
브루터 포스 공격은 단순하고 식상한 기법인 듯 하지만, 지금 이순간에도 많이 행해지고 있는 공격 기법입니다. 또한 공격이 성공했을 경우 파급력이 상당하기 때문에(내 계정을 해커가 장악했다고 생각해 보세요 =.=) 보안 개발자가 절대로 간과해서는 안될 것입니다.
브루터 포스 공격의 정확한 원리와 공격 방법, 대응 방안을 잘 숙지하시기 바랍니다.
1. 브루트 포스(Brute Force) 공격이란?
당신은 지금껏 살면서,
누군가의 비밀번호를 알아 내기 위해 임의로 접근을 시도해 본 적이 없었는가?
그것이 자물쇠 비밀번호이든, 휴대폰 비밀번호이든, 웹사이트 비밀번호이든 말이다. 만일 그런적이 있다면, 당신은 이미 브루트포스 공격을 해 본 경험이 있는 것이다.
컴퓨터 분야의 브루터포스(Brute Force)란 용어는 '억지 기법(무차별 대입해 억지로 문제를 푸는)'이라 해석되며 개념적으로 아주 단순한 공격 기법이다.
특정 암호를 풀기 위해 임의의 문자의 조합을 하나씩 대입해 보는 공격 기법이다.
브루터포스 공격은 암호를 사용하는 모든 곳에 행해질 수 있다.
암호가 걸린 파일, SSH 접속, FTP 접속, 웹사이트 회원 로그인 등이 그 대상이 될 수 있다.
다만, 이 글에서는 웹 사이트 회원 로그인에 대한 공격과 방어에 초점을 맞출 것이다.
브루터 포스 공격을 위해, 임의의 문자열을 생성/조합하고 대입하는 방법으로는 다음과 같이 두 가지로 형태로 나눌 수 있다.
1.1 브루터 포스 공격을 위한 문자열 생성 및 대입 방법
1.1.1 무작위 순차 대입
브루터포스의 무차별 대입이라는 특징을 그대로 구현하는 것으로, 조합 가능한 모든 문자열을 순차적으로 하나씩 모두 대입해 보는 것이다.
그야말로 무식하게 암호가 일치할때 까지 모든 경우의 수를 조합해 대입을 시도한다.
이론상으론 공격에 충분한 시간만 주어진다면 (모든 문자에 대한 조합을 시도해 볼 수 있기 때문에) 언젠가는 비밀번호를 맞히게 될 것이다.
다만 현실적으로는 암호의 길이와 복잡도의 증가에 따라 공격에 걸리는 시간이 기하급수적으로 늘어나므로 무조건 성공한다고 보기 어렵다.
무작위 순차 대입의 공격의 소요 시간을 줄이기 위해 미리 정의된 문자열 목록을 이용하기도 하는데, 이어서 알아보자.
1.1.2 사전(Dictionary) 대입
상당한 시간이 소요되는 무작위 순차 대입 방식 단점을 극복/보완하는 방법으로, 미리 정의된 문자열 목록을 대입하는 방법이다.
사전 파일을 이용한 공격이라고 해서 '사전 공격(Dictionary Attack)' 이라 한다.
미리 정의된 비밀번호 사전(Dictionary)을 준비하여 하나씩 대입해 보는 방식이다. 여기서 사전(Dictionary)파일은 그동안 통계적으로 많이 사용되어 오거나, 사람들이 흔히 사용할법한 비밀번호 조합을 미리 목록 형태로 정의해 둔 파일이다.
사람들은 의외로 단순한 비밀번호를 많이 사용하며 또한 여러 서로 다른 사이트에 걸쳐 동일한 비밀번호를 사용하기도 한다.
이런 환경에서, 사전 대입 방식은 브루터 포스 공격에 소요되는 시간을 극적으로 줄이면서도 공격 성공률을 높이는 아주 효율/효과적인 공격 기법이다.
비밀번호에 대한 '사전(Dictionary) 파일'은 인터넷에서 아주 쉽게 구할 수 있다.
예를 들어, 구글 검색엔진에 'password dictionary file'이라고 검색하면 수 많은 비밀번호 목록을 얻을 수 있다.
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로 변경한다.
[ DVWA의 Security Level ]
DVWA는 4단계(Low-Medium-High-Impossible)의 Security Level을 제공한다. 보안 조치가 전혀 이뤄지지 않은 Low 단계부터 점차 보안성이 강화되어 취약점으로부터 안전한 Impossible 단계까지 총 4단계로 구성되어 있다.
각 단계별로 방어 전략이 다르며 단계가 높을 수록 더 안전한 코드로 구현되어 있다. 이렇게 단계를 구분하고 각 단계별로 안전한 코드 구현을 안내하여 모의 해킹과 방어에 대한 학습을 보다 용이하도록 지원하고 있는 것이다.
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' 파일로 저장한다.)
123456
qwer1234
password
iloveyou
그리고 아래 화면과 같이, 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 안전한 패스워드 규칙
앞서 '이용자 관점'에서도 언급한바 있는데, 비밀번호를 길고 복잡하게 만들도록 규칙을 강제하는 것이다. 또한 이용자의 공개된 개인정보가 비밀번호로 사용되는 것을 경고할 필요가 있다. 이용자가 알아서 복잡하고 유추 불가능한 비밀번호를 생성해 주면 고맙겠지만, 그렇지 않은 경우도 많으니 아예 규칙으로 강제하는 것이다. 현재 많은 사이트들에서 비밀번호 복잡성 규칙을 강제하고 있다
[ ISMS 인증체계에서의 비밀번화 관리 기준 ]
ISMS 인증체계에서도 '보호대책 요구사항'에 '비밀번호 관리'라는 인증 기준을 두고 있다.
ISMS에서 안내하는 안전한 비밀번호 규칙은 아래와 같다.
- 문자, 숫자, 특수문자 중 2종류 이상을 조합하여 최소 10자리 이상 길이로 구성
- 문자, 숫자, 특수문자 중 3종류 이상을 조합하여 최소 8자리 이상 길이로 구성
- 유추 가능한 비밀번호 설정 제한: 연속된 숫자, 생일, 전화번호 등
4.2.2 로그인 시도 횟수 제한
브루터포스 공격은 임의의 문자열을 무차별 대입해 보는 공격이므로 많은 로그인 시도와 로그인 실패를 반복하게 된다. 따라서 자동화되고 반복적인 시도를 불가능하게 만들기 위해 로그인 실패가 누적될 경우, 특별한 조치를 취하는 것이다. 이때 조치는 다음과 같은 형태가 될 수 있다.
1) 계정 잠금
로그인 실패가 일정 횟수 이상이 되면 더 이상 로그인 시도를 할 수 없도록 계정을 잠그는 것이다. 이렇게 하면, 자동화된 툴로 수 많은 로그인 시도를 할 수 없거나 힘들게 되어 공격 성공율이 엄청 떨어지게 된다.
잠긴 계정을 푸기 위해서는, 일정 시간이 지나면 자동으로 풀어주거나 추가 본인 확인을 거쳐 풀어주는 방식이 있다.
2) 캡챠 요구
앞의 계정 잠금 보다는 조금 완화된 방법이다. 로그인에 반복적으로 실패할 경우, 캡챠를 같이 입력하도록 한다. 아래 화면은 네이버의 로그인 실패 후, 캡챠가 나타나는 상황을 보여준다.
브루터 포스공격의 자동화되고 반복적인 로그인 시도 자체를 불가능하게 하여 이 공격의 기본 매커니즘을 흔들어 버리는 것이다. 이 방식은 공격자의 공격 의지를 상당히 깍아 내리므로 아주 효과적이라 하겠다.
4.2.3 다중 인증
ID, PASSWORD 이외에 추가 인증 수단을 제공하는 방식이다. 이 글에서 말하는 '다중 인증'은 일반적인 보안에서 말하는 '2 factor 인증'과는 그 개념을 구분하고자 한다.
'2 factor 인증'은 지식 기반인 비밀번호외에 소유기반인 휴대전화, OTP, 보안카드 또는 생체기반인 지문과 같은 인증 요소를 둘 이상 결합한 인증 방식을 말한다. 반면 여기서 말하는 '다중 인증'은 ID, PASSWORD외에 추가로(그게 무엇이든) 입력 받도록하는 인증 방식을 말한다.
1) 기기 인증
ID, PASSWORD 뿐만 아니라 로그인을 시도하는 기기도 인증하는 방식이다. 현재 이 블로그 서비스 제공하는 업체인, 티스토리도 기기 인증을 지원한다. 관리자 모드에서 기기인증을 활성화 할 경우, 한번도 접속한적 없는 기기에서 로그인을 시도하면 다음 화면과 같이 기기 인증을 받도록 되어 있다.
해커의 경우, 정상 이용자의 기기와는 다른 기기에서 로그인을 시도 할 것이기 때문에 로그인 시도를 할 수가 없게 될 것이다.
주의할 점은, 기기 인증시 기준값이 되는 기기의 고유값을 HTTP Request 정보에만 의존한다면 (비보안 HTTP 환경에서는) 해커가 얼마든지 그 값을 변조할 수 있으므로 주의를 요한다.
2) 캡차 추가
앞서 계정 잠금 후, 캡챠를 사용할 수도 있지만, 처음부터 로그인 시 캡챠를 같이 요구할 수도 있다.
아래 그림은 워드 프레스의 로그인 폼에 캡챠가 적용된 모습인데, 이와 같이 로그인 할 때 캡챠를 함께 사용하는 것이다.
이 캡챠의 경우, 매번 캡챠의 문자가 바뀌는 형식인데, 브루터포스 공격을 시도할 때 문자가 매번 바뀌기 때문에 공격을 자동화 시키기 아주 힘들어진다. 물론 캡쟈 자체의 보안성이 높아야 하는 것은 당연하다.
요즘은 네이버나 구글과 같은 대형 인터넷 업체에서 무료로 캡챠를 사용할 수 있도록 제공하니 참고 바란다.
앞서 이 글에서의 '다중인증'과 보안에서의 '2 factor 인증'을 구분하길 원했지만 2 factor 인증을 다중인증 수단으로 사용할 수도 있다.
예를 들어 로그인 시 ID/PASSWORD 외에 OTP 번호를 요구하거나 메일 인증을 추가할 수도 있다.
'2 factor 인증'을 사용하면 브루터 포스 공격을 거의 완전하게 방어 할 수 있을 것이다.
하지만 (정말 보안이 중요한 곳이 아니라면) 사용 편의성이 너무 떨어지기 일반적인 사이트에서 로그인 보안으로는 좀 과한 느낌이 있다.
4.2.4 강력한 로깅과 모니터링
지금까지 알아본 많은 방어책들이 잘 갖춰져 있다 하더라도 운영 중 모니터링은 필수 요소이다. 모니터링을 하려면 로그인 요청과 실패에 대한 사항을 기록하고 감시해야 한다.
그리고 이상 현상에 대한 임계치를 설정하고 임계치에 도달 할 경우, 관라지에게 자동으로 Alerting 되도록 모니터링 체계를 구축하는 것이 바람직 하다. 또한 이렇게 모니터링해서 이상현상이 감지되면, 공격용으로 의심되는 IP에 대한 조사 및 블럭킹 등 적극적인 조치가 뒤따라야 한다.
브루터 포스 공격에 대한 방어책을 상세히 알아 보았다. 앞서 장황한 설명의 핵심은 다음 세 가지로 정리할 수 있겠다.
1. 안전한 패스워드 사용 (길고 복잡하고 추측하기 힘든 패스워드)
2. 공격 자동화 저지 (다양한 방법 존재)
3. 공격 시도 탐지 (모니터링과 알림)
지금까지 알아본바와 같이, 기업 입장에서 브루터 포스 공격에 대비해 다양한 방어 수단을 구현할 수 있다. 한가지 생각해 볼 문제는, 웹 사이트의 성격에 맞는 보안성을 제공해야 한다는 것이다.
보안은 항상 트레이드 오프(Trade off)가 존재한다. 대부분 보안성이 올라가면 성능 또는 사용성(편의성)이 떨어지게 마련이다. 기업이 서비스하는 웹 사이트의 성격에 맞는 보안성과 잘 조율된 성능, 사용성을 동시에 만족시키는 것이 필요하다 하겠다.
'보안' 카테고리의 다른 글
해킹 피해에 따른 행정처분 사례 (0) | 2019.02.14 |
---|---|
[웹보안] SQL Injection (0) | 2019.01.31 |
[웹보안] 로컬 환경 셋팅과 툴 설치 (2) | 2019.01.17 |