Client server

1. 페이지네이션
   훈련 현황 페이지
   훈련 진행 페이지
   완료 훈련 관리페이지
   기타

2. 훈련 데이터 비즈니스 로직

• 훈련 테이블 > 실시간 로그 > 훈련제목/요약/대상
  • csv업로드/ html 업로드 (Nodejs에서 제공)

3. 훈련 기간 세팅 로직

• 훈련 설정시 훈련기간 시작~끝
• 부서설정
• 리소스 유저 선정
• 훈련이름 , 명세
  

4. 진행중인 훈련조회 시
   • 1. 생성된 피싱 메일 목록
   • 2. 선택된 리소스 유저 목록 (최초 감염 사람)
   • 3. 참조한 원본 메일 body
5. 완료된 훈련 조회 시

• VBA 스크립트가 담긴 XLS 파일
• VBA 스크립트 담긴 HWP 파일
• 특정 C2 서버로 신호를 보내는 첨부파일 샘플을 한 3개만들기
  • BASE64 사용(Agent 에서 전달)

---

Agent

• 네트워크 IMAP(protocol), THUNDER BIRD , MAILX
• 이메일 서버

1. 로직
   데이터 흐름:

클라이언트에서 Base64 인코딩된 데이터 전송
서버에서 디코딩 후 SQLite DB에 저장
GitHub 로그인 페이지로 리다이렉션

• c2 서버

1. 로직
   클릭 추적은 Base64로 인코딩된 URL 파라미터를 통해 이루어집니다.
2. client

# 암호화
json_str = json.dumps(user_data)

base64_encoded = base64.urlsafe_b64encode(json_str.encode()).decode()

3. server

# 복호화
padding = "=" * ((4 - len(user_param) % 4) % 4)
decoded_user_data = base64.urlsafe_b64decode(user_param + padding).decode('utf-8')
user_data = json.loads(decoded_user_data)

4. db -event 저장

phishing_event = PhishingEvent()
phishing_event.log_click_event(user_data)

Backend

• swagger Docs
  flask-swagger gui 사용
• 모델(table) 컴포넌트화
  • 각 테이블 별 모델 만듬.
  • BaseModel 이용해서
  • dict 를 이용해서 최대한 model에서 일단 데이터를 잘 처리하는 쪽으로 진행
• Marshmallow schema
  • slqite3로 가기 중간 단계임.
  • sqlite3 스키마가 아니라 marshmallow가 관리하는 schema 이고 해당 스키마를 객체로 리턴함.
  • 어떤식으로 data를 처리하고, restful api 요청시 어떤식으로 전달할건지를 정함.
  • preload 나 postload로 json 역직렬화 문제를 최대한 풀어내려 애썼음
  • 해당 데코레이터의 역할을 잘 몰라서 AI의 힘을 많이 기댔었다
  • validation 검사도 가능하나 model import시 fk 등 relation 이슈가 많이 발생함
  • 참조키가 많이 없는 독립적인 model부터 import를 해야 순환참조 에러를 막을 수 있음
• SqlAlchemy
  • sqlite 언어 쓰기 싫어서 썼음
  • 근데 sqlalchemy 덕분에 migrate 난이도 급상승^^
  • 대용량 데이터 처리나 코드 유지보수에 편리하다더니 나는 안 편리..
• Flask-migrate / Alembic
  • 이번 프로젝트를 하며 orm을 멋드러지게 써보고 싶었거든요.
  • 가오에 가득찬 나로 인해 추후 미래의 내가 고생을 좀 했음
  • alembic이 sqlite3의 지난 버전 관리에 용이한 것은 맞으나 우리처럼 더미데이터 자체가 불완전한 상태에서 사용하기에는 너무 과한 설정이였다
• SQLITE3
  • 안정된 format의 json 형태의 data 필수
  • data 형태를 잘 결정해야함 (marshmallow schema단계나 모델에서도 dictionary 처리 가능)
    • 이번 json 데이터에 string list가 포함되어있었는데, 이 데이터가 sqlite3에는 인식이 안됨
    • sqlite3 특성때문에 list가 입력이 안됨
    • number list로 일단 수동 코딩해서 바꾸고 입력할때 text로 처리함

중간 세팅 및 기능

• 중간에 admin용 table을 별도로 만들어달라는 병신같은 요청이 있었고 무시함

• 이유 1: DB 에 employee 메타데이터가 이미 있고

  • 이유 2 : db 내 user account 전용 데이터가 중복된다 / 즉 acid 하지 못함

  • 이유 3: 해당 admin이 jwt 로그인 외 추가 행동이나 로직이 없었음 ,즉 과한 db 설정임.(서버에서 jwt 토큰은 저장 안함)

  • 이유 4: sqlalchemy 와 alembic이 난리남

    • admin 데이터는 기존 user data랑 좀 format이 달라야 했음. 특히 password (default 패스워드랑 다르게 설정하려 했음) , admin 임을 표시하는 is_admin boolean 값을 추가해야 하다보니, 기존 userdata와 형식이 맞지 않아서 다 뜯어 고쳐야했음.

• DB에 admin 계정 추가해서 해당 admin만 다른 비밀번호 + 별도 attribute 적용해서 jwt로 전달함

  • 근데 생각해보니.. 아무리봐도 employee table에서 이 계정 하나만 별도 로직을 관리하는게 여간 성가신 일이 아닐수 없다..

  • 저 별도의 로직때문에 api 별도로 만드는것도 좀 과한 기능 구현이라는 생각이 들었음

    • 그리고 어드민 관리용 페이지가 별도로 존재하는것도 아니지 않나. 프로필이 따로 있는것도 아니더구만.

  • 무엇보다 개발하는 솔루션 자체가 관리자 계정 Superuser만 사용하는거라 좀..(어짜피 일반 계정이나 일반 직원들은 사용 불가)

  • JWT로 구현 했고, password도 admin 만큼은 hash 화 하려했으나 ...으음

  • 아무리 봐도 과한 요청 하시길래 db에서 일반 유저처럼 어드민을 파서 data 만들어 드림.

  • 근데 마지막엔 굳이 필요없다고 client 측에서 갑자기 요구하시길래 삽질만 하고 말았다.

이럴꺼면 니들이 알아서 로직 잘 짜서 쿼리 넣어서 찾으세요

더이상 팀이 아니지.

• 1. 혼자함
     혼자 쓸쓸하게 DB내 모든 더미데이터 (55개) 프롬프트 엔지니어링 해서 시계열 데이터로 다 연동되게 만듬
     

• 2. 어짜피 협동이 되지 않음
     한달 반동안 놀고계신 잉여 자원분들께 제발 협력 요청을 수차례 했으나 개 무시당한 이후로 나 또한 호의적이지 않게 됨.

• 3. 수습 못함 / 내탓 아님 시전
     우리동네 빌런덕분에 db 데이터 날리시고 수습도 안해
     니탓임 내탓아님 이 능지에 진심으로 감탄함.

• 4. 애새끼
     멘토들 앞에서는
     무슨일이든 걍 입닫고 반응도 안하는게
     마치 숙제 미루고 모르는척 혼나기 싫어서 가만히 있는 미취학 청소년 같네요.

• 5. 마무리

문서작업은 정말 쉬운작업이라고 생각함 .
시간이 많이 걸릴 뿐이지.
그래서 잉여자원들이 할 수 있는 마지막 기회이자, 정말 쉬운 작업이라고 생각했는데.

그 마저도
끝까지 협조 하지 않았다.

덕분에 없던 편견도 생기고.

미필 인간 혐오증 걸림.

• 멘토님 템플릿 바꾸라는거 결국 내가 다 바꾸고 내용수정함.

하하
추석내내 복구 방법 찾다가 포기하고
밤 새서 내내 다시 만들었던거 지금 생각해도 분하네^^

대단한 업적 쌓으셨네요

사과할 부분있으면 사과하겠다 이러시던데 디게 뿌듯한가봄.
칭찬이라도 해드릴까요?