최종 수정: 2024.03.22(금)

목차

  1. Introduction
  2. Plan
  3. Design
  4. Conclusion
  5. Links

1. Introduction

이번 포스트에선 DarkWeb Alert System의 기획, 설계 등을 기록하였습니다.
프로젝트 컨셉, 아이디어, 기능에 대한 간단한 설명을 포함합니다.
사실 한참 전에 임시 기획/설계(요구사항 및 개발설계)가 끝났는데,
직접 구현을 하다보니 추가해야할 기능이 점점 늘어나서 수정에 수정을 거치다보니 늦어졌습니다.😅
(지금도 수정 중인건 안비밀..)
(그리고 TMI이지만 제 생일임! 아니 그냥 그렇다구요..네..개발하러 가보겠습니다..🥲)

2. Plan

기획 부분은 최대한 사용자 입장을 고려해서 작성하였습니다.
(기획서를 적다보니 어째 BM쪽에 더 밝은 것 같ㅇ..)
‘딥웹, 다크웹에서 정보를 크롤링하는 사람은 어떤 것이 필요할까.’ 에서 시작했습니다.

  • 특정 키워드에 대한 유출 정보 존재 유무
  • 유출된 정보의 유형
  • 유출된 정보의 양
  • 위험도 평가
  • 침해사고대응 방법 제시

가 해당 프로젝트의 계략적인 지향점이 아닐까 생각했습니다.
다만 여기서 생기는 문제점이 정량적 수치를 확인하기 위해서는 유출된 정보에 직접 접근할 필요가 있다는 것이었습니다.
문제점인 이유는 여러가지가 있겠지만 꼽아보자면,

  • 안전한 파일인지 점검하는 로직 추가 필요(VirusTotal 이라던가?)
  • 각 정보의 파일 확장자가 다름
  • 각 정보의 형식이 다름

이 대표적인 문제점이었습니다.
위와 같은 이유로 본 프로젝트에선 포럼의 스레드 키워드를 중심으로 위험도를 측정하기로 결정하였습니다.

기획서 Link <- 아직 음서요!(업데이트 예정)

3. Design

설계 부분은 개발자가 보면서 요구사항에 대한 정확한 이해를 할 수 있도록 작성하는데 집중하였습니다.
특히 개발 설계와 관련된 부분은 데이터 타입 힌트와 동작 설명을 추가하여 개발자 입장에서 신경을 많이 썼습니다.
대략적인 프로그램 구성은 이렇습니다.

  • main.py: 메인 파트로 프로그램의 옵션 처리 및 해당하는 함수 호출.
  • clientclass.py: Client 객체를 정의하는 파일로, 객체의 프로필을 업데이트 및 저장.
  • ./sites/{domain}.py: Domain 이름에 해당하는 크롤러 파일. 각 사이트에 대한 크롤링을 수행하고, 데이터를 처리하여 포맷에 맞게 반환.
  • alert.py: Telegram을 기반으로 한 알람 전송 및 보고서 작성 파일.
  • constant.py: 정적으로 사용될 값을 저장한 파일.

여기서 크롤러 부분에서 삽질을 많이 했습니다.(현 시점에서도 삽질하고 있…)
아니 글쎄 팀장이라는 작자가 무식하게 크롤러를 하나만 만들면 되겠거니 생각해서,
각 사이트 별로 분류하지 않고 하나로 통합해버린…
그래서 급하게 노선을 바꿔 폴더안에 도메인 이름으로 각각의 크롤러를 구성하였습니다.
특히 3월 22일 기준 선정한 사이트 중 leakbase라는 포럼을 크롤링하는데,
검색에 대한 url이 일정하지 않은 것을 해결하는 와중에
Client-Side Rendering(CSR)과 Server-Side Rendering(SSR)의 존재에 대해 알게 되었습니다.
또한, 각각의 렌더링 방법에 따라 크롤링 방법도 다르다는 것을 알게 되었습니다. leakbase의 경우 CSR이어서, 동적 크롤링이 필요해, Selenium을 써야했습니다.
이에 반해 SSR같은 경우엔 페이지가 렌더링이 끝난 상태로 클라이언트에 페이지가 주어져
requests로 충분히 크롤링이 가능한 것을 확인했습니다.
CSR도 동적으로 코드를 실행하여 얻는 결과가 아니라면 Selenium을 사용하지 않더라도 크게 문제되지 않을 것으로 예상하고 있습니다.
(requests와 BeautifulSoup면 나는 무적이다! 라고 하던 자신을 반성합니다..)

그리고 이와 별개로 Tor 브라우저를 사용한 Onion Network을 이용하는 사이트에 접근하기 위해선 환경 구성이 먼저 필요했습니다.
이와 관련하여서도 설계 문서에 명시되지 않아 팀원에게 그냥 덤핑해버린 나쁜 설계자.(네, 저 맞습니다.)
일단 접근은 잘 된다고 하니(고수 ㄷㄷ), 이후 포스팅에서 더 자세히 다뤄보도록 하겠습니다.

설계서 Link <- 여기도 음서요!(업데이트 예정)

4. Conclusion

기획 자체는 문제의 본질을 파악하고, 그에 맞는 클라이언트의 니즈를 충족시키는 문서를 작성하는 방향이어서, 크게 문제될 점은 없었던 것 같습니다.
하지만 설계 부분에서 큰 틀은 잘 갖추었다고 생각하고 진행했는데,
지식이 부족하거나, 사전조사가 부족해서 디테일한 부분에 부족함이 드러났습니다.
결과적으로 문서 수정이 불가피하였고, 이로 인해 팀에 혼란이 가중되었던 것 같습니다. 팀원에게 파트를 맡기고 충분한 정보 조사 및 데모 이후에 상의하여 작성할 필요가 있다고 느꼈습니다.
그리고 문서 쪽 문제 외에 다크웹 포럼을 선정하는데, 어려움이 있었습니다.
다크웹은 다크웹인지 DuckDuckGo에선 어림도 없었고, HiddenWiki, OnionLinks 등
서핑을 해봐도 마땅한 포럼이 없었습니다.
(이래서 이전 회차 분들도 LockBit을 선정했나보다아..)
아무튼 넋두리가 되어버렸는데, 3줄 요약하면

  1. 기획/설계 어렵따.
  2. 그래서 제대로 못해따.
  3. 사전 조사를 자라자.

다음 포스트는 드디어 개발 파트…!

1. Wikipedia - Open-source intelligence
https://en.wikipedia.org/wiki/Open-source_intelligence
2. Geeksforgeeks - Windows Forensic Analysis
https://www.geeksforgeeks.org/windows-forensic-analysis/
3. Wikipedia - Onion routing
https://en.wikipedia.org/wiki/Onion_routing
4. ExpressVPN - Dark web VS Deep web
https://www.expressvpn.com/blog/dark-web-vs-deep-web/
5. Hidden Wiki
https://thehiddenwiki.org