시스템 보안 · 취약점 › E. 중요 정보 접근 로그 분석 · 23/50편 (전체 223/450) 학습 단계: DB·대량 데이터 접근 이상 실습 표기: 이 글의 명령어·출력·로그는 로컬 VMware 테스트 VM(Rocky Linux 9 / Ubuntu 22.04) 기준의 「실습 예시」 이며, IP·계정·호스트명은 가상의 값입니다. 선행 학습 222. 중요 정보 접근 — 민감 디렉터리 스캔성 접근 탐지 219. 데이터베이스 파일 직접 접근 탐지 1. 개념 DB 파일 직접 접근(E19)이 엔진 우회라면, 여기서는 DB 엔진을 통한 접근 을 쿼리·감사 로그로 분석합니다. 탈취한 자격증명으로 정상 쿼리처럼 접속해 대량 조회·민감 테이블 접근하는 패턴을 봅니다. DB 쿼리 로그 분석 포인트 general_log(MySQL)·pg audit: 모든 쿼리 기록 대량 SELECT: SELECT * FROM users (전체 조회) 민감 테이블: users, payments, cards (E24) 비정상 접속: 새 IP·계정·시간대 SELECT INTO OUTFILE: 쿼리로 파일 추출(E19 연계) OS 감사(E영역) + DB 로그 결합 → 완전한 접근 가시성 OS 레벨 접근 감사만으로는 DB 내부 쿼리를 못 봅니다. DB 쿼리 로그를 함께 수집해야 엔진 경유 접근이 보입니다. 2. 왜 중요한가 DB 엔진 경유 접근은 OS 파일 감사로는 안 보여, DB 쿼리 로그 수집이 필요합니다. 대량 SELECT·민감 테이블 조회는 정상 앱 쿼리와 패턴이 다릅니다. 탈취 자격증명 접속은 비정상 IP·계정·시간대로 식별합니다. 3. 핵심 명령어 / 설정 쿼리 로그 신호 의미 위험 대량 SELECT * 전체 조회 높음 민감 테이블 조회 개인정보·결제 높음 INTO OUTFILE 파일 추출 매우 높음 새 IP·계정 접속 탈취 자격증명 높음 앱 정상 쿼리 업무 정상 4. 실습 (실습 예시) # DB 쿼리 로그 분석 (분석 방법) # MySQL general/audit log에서 대량 SELECT·민감 테이블(분석용) sudo grep -iE 'SELECT .* FROM (users|payments|cards|accounts)' /var/log/mysql/*.log 2>/dev/null | tail # INTO OUTFILE(쿼리 파일 추출) sudo grep -i 'INTO OUTFILE\|INTO DUMPFILE' /var/log/mysql/*.log 2>/dev/null # 비정상 접속 IP(앱 서버 외) sudo grep -iE 'Connect.*@' /var/log/mysql/*.log 2>/dev/null | grep -vE '127.0.0.1|앱서버IP' | tail 5. 정상 상태 $ (민감 테이블 조회) 앱 서버 IP의 정상 범위 쿼리만 $ (INTO OUTFILE) (없음) $ (비정상 접속) (없음 — 앱 서버에서만 접속) 쿼리가 앱 서버에서의 정상 범위 조회에 그치고, INTO OUTFILE·외부 IP 접속이 없는 상태가 정상입니다. 6. 이상 상태 $ (민감 테이블 조회) Query SELECT * FROM users (전체 사용자 조회) $ (INTO OUTFILE) Query SELECT * FROM cards INTO OUTFILE '/tmp/c.csv' $ (비정상 접속) Connect app@192.0.2.88 (앱 서버 아닌 IP) SELECT * FROM users 전체 조회 + cards INTO OUTFILE 파일 추출 앱 서버가 아닌 IP(192.0.2.88)에서 접속 → 탈취 자격증명 사용 대량 조회·파일 추출·비정상 IP → 데이터 유출 → 정탐 7. 로그 분석 (분석 방법) DB 쿼리 접근 분석 흐름입니다(가상의 예시). [접속] app@192.0.2.88 (비앱 IP, 탈취 자격증명) ↓ [조회] SELECT * FROM users, payments (대량·민감 테이블) ↓ [추출] SELECT ... INTO OUTFILE '/tmp/c.csv' (파일화) ↓ [유출] /tmp/c.csv 외부 전송(E32) 단계 쿼리 로그 접속 비정상 IP 조회 SELECT * 민감테이블 추출 INTO OUTFILE 유출 파일 전송 DB 쿼리 로그 + OS 파일 감사를 결합하면 엔진 경유·우회 접근을 모두 봅니다. 8. SOC 관제 포인트 DB 쿼리·감사 로그 분석은 엔진 경유 접근 (OS 감사 사각지대)을 포착합니다. 대량 SELECT·민감 테이블 조회·INTO OUTFILE·비정상 IP가 핵심 신호입니다. OS 파일 감사(E19)와 DB 쿼리 로그를 결합해 완전한 접근 가시성을 확보합니다. 9. 탐지 규칙 <!-- 실습 예시 룰: 적용 전 wazuh-logtest 및 테스트 환경 검증 필요 --> <group name="local,syssec_e,data_access,"> <!-- DB 로그 파서 전제: 대량 조회·파일 추출 쿼리 --> <rule id="104220" level="12"> <decoded_as>mysql_log</decoded_as> <field name="query" type="pcre2">(SELECT\s+\*\s+FROM\s+(users|payments|cards|accounts))|INTO\s+(OUTFILE|DUMPFILE)</field> <description>DB 대량 조회·파일 추출 쿼리(엔진 경유 유출)</description> <mitre><id>T1005</id></mitre> </rule> </group> DB general/audit log를 Wazuh/ELK로 수집해야 쿼리 탐지가 가능합니다. 로그 활성화는 성능을 고려해 설정합니다. 10. 대응 방법 초기 확인 — DB 쿼리 로그에서 대량 SELECT·민감 테이블·INTO OUTFILE·접속 IP를 확인합니다. 범위 확인 — 앱 서버 외 접속·탈취 자격증명 사용 여부를 확인합니다. 증거 확보 — 쿼리 로그·접속 로그·연계 OS 감사를 보존합니다. 차단/조치 — 유출 정탐이면 DB 세션 차단·자격증명 교체·조회 범위(유출 데이터) 조사를 진행합니다. 재발 방지 — DB 쿼리 로그 수집·분석을 OS 감사와 함께 운영합니다. 11. 핵심 정리 쿼리 신호 위험 SELECT * 대량 전체 조회 민감 테이블 개인정보·결제 INTO OUTFILE 파일 추출 비정상 IP 접속 탈취 자격증명 면접 포인트 "DB 엔진 경유 접근은 쿼리 로그로만 — OS 감사(파일)와 결합해 완전 가시성" 12. 다음 편 예고 다음 편 224. 중요 정보 접근 — 민감 테이블·컬럼 접근 탐지 에서는 민감 테이블·컬럼 접근을 다루는 민감 테이블·컬럼 접근 탐지 를 다룹니다. 이전 편: 222. 중요 정보 접근 — 민감 디렉터리 스캔성 접근 탐지 📚 시리즈 전체 보기: 시스템 보안 · 취약점
시스템 보안 · 취약점 › E. 중요 정보 접근 로그 분석 · 17/50편 (전체 217/450) 학습 단계: 중요 파일 접근 이상 실습 표기: 이 글의 명령어·출력·로그는 로컬 VMware 테스트 VM(Rocky Linux 9 / Ubuntu 22.04) 기준의 「실습 예시」 이며, IP·계정·호스트명은 가상의 값입니다. 선행 학습 216. 중요 정보 접근 — 백업·아카이브 파일 접근 탐지 171. 중요 파일 소유권 탈취 탐지(D영역) 1. 개념 공격자는 권한을 상승한 뒤 다른 사용자의 홈 디렉터리 에서 개인 데이터를 수집합니다. 홈에는 문서·키·설정·히스토리가 모여 있어 교차 접근(자기 홈이 아닌 타인 홈 읽기)이 핵심 이상 신호입니다. 타 사용자 홈 교차 접근 위험 /home/<타인>/문서·데이터 개인정보 수집 /home/<타인>/.ssh 키 탈취(E11) /home/<타인>/.bash_history 명령 이력(자격증명·경로) /home/<타인>/.config 앱 설정·토큰 /root/ root 개인 데이터 핵심: auid와 접근 경로의 소유자 불일치(교차 접근) 정상 사용자는 자기 홈만 접근합니다. auid와 홈 소유자가 다른 교차 접근 이 이상 신호입니다. 2. 왜 중요한가 홈 디렉터리에는 문서·키·이력·토큰이 모여 있어 개인 데이터 수집의 표적입니다. .bash_history는 과거 명령(자격증명·경로·호스트)을 노출해 추가 공격에 쓰입니다. 교차 접근(타인 홈 읽기)은 정상 운영에서 드물어 명확한 이상 신호입니다. 3. 핵심 명령어 / 설정 접근 대상 노출 위험 타인 홈 문서·데이터 개인정보 높음 타인 .ssh 키 탈취 매우 높음 타인 .bash_history 명령·자격증명 이력 높음 타인 .config 앱 토큰·설정 중간 /root/ root 데이터 높음 4. 실습 (실습 예시) # 타 사용자 홈 교차 접근 탐지 (분석 방법) # 접근 경로 소유자와 auid 불일치(교차 접근) sudo ausearch -k sensitive_read,home_access -i --start recent 2>/dev/null | grep -E '/home/|/root/' | grep -E 'comm="(cat|cp|tar|less|grep|find)"' | tail # .bash_history 교차 접근 sudo ausearch -k home_access -i --start recent 2>/dev/null | grep 'bash_history' 5. 정상 상태 $ (홈 접근) comm="cat" auid=alice /home/alice/notes.txt (자기 홈 — 정상) 사용자가 자기 홈(auid=홈 소유자)만 접근하는, 교차 접근이 없는 상태가 정상입니다. 6. 이상 상태 $ (홈 교차 접근) 04:00 comm="tar" auid=devops /home/alice/documents → 수집 04:01 comm="cat" auid=devops /home/bob/.bash_history 04:02 comm="cp" auid=devops /root/.aws/credentials devops가 alice 문서를 tar로 수집 → 타 사용자 개인정보 탈취 bob의 .bash_history 읽기 → 명령 이력(자격증명·호스트) 수집 root의 AWS 자격증명 접근 → 클라우드 키 탈취 auid≠홈소유자 교차 접근 → 정탐 7. 로그 분석 (분석 방법) 홈 교차 접근 흐름입니다(가상의 예시 로그). type=SYSCALL comm="tar" auid=devops key="home_access" type=PATH name="/home/alice/documents/" ouid=alice → devops(auid)가 alice(ouid) 홈 접근 : 교차 접근 [패턴] 여러 사용자 홈 순회 수집 → 대량 개인정보 탈취 관찰 해석 auid=devops 접근 주체 ouid=alice 경로 소유자(타인) 불일치 교차 접근 tar 수집 대량 탈취 auid(주체)와 ouid(경로 소유자) 불일치가 교차 접근의 핵심 판정 기준입니다. 8. SOC 관제 포인트 타 사용자 홈 교차 접근 (auid≠홈 소유자)은 개인 데이터 수집의 핵심 신호입니다. 홈의 .ssh·.bash_history·.config는 키·이력·토큰을 노출합니다. auid와 경로 소유자(ouid) 불일치로 교차 접근을 판정합니다. 9. 탐지 규칙 <!-- 실습 예시 룰: 적용 전 wazuh-logtest 및 테스트 환경 검증 필요 --> <group name="local,syssec_e,sensitive_access,"> <rule id="104160" level="11"> <if_sid>104000</if_sid> <field name="audit.file" type="pcre2">/home/[^/]+/(\.ssh|\.bash_history|\.aws|\.config|documents)|/root/\.</field> <field name="audit.comm" type="pcre2">^(cat|cp|tar|less|grep|find|scp)$</field> <description>타 사용자 홈·개인 데이터 교차 접근(수집)</description> <mitre><id>T1005</id><id>T1552</id></mitre> </rule> </group> auid와 경로 소유자(ouid) 비교로 교차 접근을 정밀 판정합니다. 여러 홈 순회는 상관으로 강화합니다. 10. 대응 방법 초기 확인 — 접근된 홈·개인 데이터와 주체(auid)·경로 소유자(ouid) 불일치를 확인합니다. 범위 확인 — 여러 사용자 홈 순회·.bash_history·키 수집을 확인합니다. 증거 확보 — 홈 교차 접근 이벤트와 수집 범위를 보존합니다. 차단/조치 — 교차 접근 정탐이면 세션 종료·영향 사용자 통지·자격증명 교체를 진행합니다. 재발 방지 — 홈 교차 접근 탐지를 운영합니다. 11. 핵심 정리 접근 대상 노출 타인 홈 문서 개인정보 타인 .ssh 키 탈취 타인 .bash_history 명령·자격증명 이력 /root/ root 데이터 면접 포인트 "교차 접근(auid≠홈 소유자)이 핵심 신호 — 홈에 키·이력·토큰 집중" 12. 다음 편 예고 다음 편 218. 중요 정보 접근 — 중요 파일 접근 이상 종합 분석 에서는 중요 파일 접근 2단계를 마무리하는 중요 파일 접근 이상 종합 분석 을 다룹니다. 이전 편: 216. 중요 정보 접근 — 백업·아카이브 파일 접근 탐지 📚 시리즈 전체 보기: 시스템 보안 · 취약점
시스템 보안 · 취약점 › E. 중요 정보 접근 로그 분석 · 11/50편 (전체 211/450) 학습 단계: 중요 파일 접근 이상 실습 표기: 이 글의 명령어·출력·로그는 로컬 VMware 테스트 VM(Rocky Linux 9 / Ubuntu 22.04) 기준의 「실습 예시」 이며, IP·계정·호스트명은 가상의 값입니다. 선행 학습 210. 중요 정보 접근 — 계정 정보(passwd) 접근 탐지 165. SSH 관련 파일 권한 변경 탐지(D영역) 1. 개념 SSH 키는 비밀번호 없는 인증 수단이라, 탈취되면 다른 시스템 접근(측면 이동) 에 바로 쓰입니다. SSH 인증 파일 읽기 접근은 키 탈취 시도로, 측면 이동의 전조입니다. SSH 인증 파일 접근 위험 ~/.ssh/id_rsa(개인키) 읽기 → 키 탈취 → 다른 서버 접속 ~/.ssh/authorized_keys 읽기 → 허용 키 파악 / 쓰기 → 백도어(D15) /etc/ssh/ssh_host_*_key 읽기 → 호스트키 탈취(MITM) ~/.ssh/known_hosts 읽기 → 접속 이력(대상 식별) 키 탈취 = 측면 이동(T1021)·자격증명 접근(T1552.004) 개인키 읽기는 정상적으로 SSH 클라이언트(ssh)만 하므로, 다른 명령(cat·cp)의 읽기는 탈취 시도입니다. 2. 왜 중요한가 SSH 개인키 탈취는 비밀번호 없이 다른 시스템에 접속(측면 이동)하는 수단입니다. known_hosts는 "어디에 접속했는가"를 알려줘 다음 공격 대상 식별에 쓰입니다. 정상은 ssh 클라이언트만 개인키를 읽으므로, 쉘 명령 읽기는 탈취 신호입니다. 3. 핵심 명령어 / 설정 SSH 파일 접근 위험 악용 id_rsa (개인키) 키 탈취 측면 이동 authorized_keys 허용 키 파악 백도어 식별 ssh_host_*_key 호스트키 탈취 MITM known_hosts 접속 이력 대상 식별 config 접속 설정 대상·계정 4. 실습 (실습 예시) # SSH 키 접근 탐지 (분석 방법) # SSH 인증 파일 읽기(ssh 클라이언트 외) sudo ausearch -k sensitive_read -i --start recent 2>/dev/null | grep -E '\.ssh/(id_|authorized_keys|known_hosts)|ssh_host_' | grep -vE 'comm="(ssh|sshd|scp|sftp)"' | tail # 타 사용자 개인키 접근(교차 접근) sudo ausearch -k sensitive_read -i --start recent 2>/dev/null | grep 'id_rsa' 5. 정상 상태 $ (SSH 키 접근) (없음 또는 ssh 클라이언트만) SSH 개인키 접근이 ssh 클라이언트(정상 접속)에 의해서만 발생하고, 쉘 명령의 키 읽기가 없는 상태가 정상입니다. 6. 이상 상태 $ (SSH 키 접근) 04:00 comm="cat" auid=devops /home/alice/.ssh/id_rsa (타 사용자 키) 04:01 comm="cp" auid=devops /root/.ssh/id_rsa → /tmp devops가 alice의 개인키를 cat → 타 사용자 키 탈취(측면 이동 준비) root 개인키를 /tmp에 복사 → 키 수집(유출·측면 이동) 타 사용자·root 키의 쉘 읽기·복사 → 키 탈취 → 정탐 7. 로그 분석 (분석 방법) SSH 키 탈취 흐름입니다(가상의 예시 로그). type=SYSCALL comm="cat" auid=devops key="sensitive_read" type=PATH name="/home/alice/.ssh/id_rsa" → devops가 alice 개인키 읽기(탈취) [이후] ssh -i 탈취키 alice@other-server (측면 이동, 별도 탐지) 관찰 해석 cat id_rsa(타인) 개인키 탈취 cp → /tmp 키 수집 이후 ssh -i 측면 이동 known_hosts 대상 식별 키 탈취 → 측면 이동(ssh)으로 이어지므로, 아웃바운드 SSH와 연계해 탐지합니다. 8. SOC 관제 포인트 SSH 인증 파일 접근은 키 탈취 → 측면 이동 의 전조입니다. 개인키는 정상적으로 ssh 클라이언트만 읽으므로 쉘 명령 읽기는 탈취 신호입니다. 타 사용자·root 키의 읽기·복사, known_hosts 접근(대상 식별)을 위험으로 봅니다. 9. 탐지 규칙 <!-- 실습 예시 룰: 적용 전 wazuh-logtest 및 테스트 환경 검증 필요 --> <group name="local,syssec_e,sensitive_access,"> <rule id="104100" level="13"> <if_sid>104000</if_sid> <field name="audit.file" type="pcre2">\.ssh/(id_[a-z]+|authorized_keys)|ssh_host_[a-z]+_key</field> <field name="audit.comm" type="pcre2">^(?!(ssh|sshd|scp|sftp|ssh-agent))[a-z]+$</field> <description>비SSH 주체의 SSH 개인키·인증 파일 접근(키 탈취)</description> <mitre><id>T1552.004</id><id>T1021.004</id></mitre> </rule> </group> 정상 ssh 계열 프로세스는 제외합니다. 키 읽기 후 아웃바운드 SSH(측면 이동)를 상관으로 연계합니다. 10. 대응 방법 초기 확인 — 접근된 SSH 키 파일·대상 사용자·주체·방법을 확인합니다. 범위 확인 — 타 사용자·root 키 교차 접근·복사·이후 측면 이동(ssh)을 확인합니다. 증거 확보 — SSH 키 접근 이벤트와 연계 로그를 보존합니다. 차단/조치 — 키 탈취 정탐이면 세션 종료·키 교체(재발급)·측면 이동 조사를 진행합니다. 재발 방지 — SSH 키 접근 탐지를 운영합니다. 11. 핵심 정리 SSH 파일 악용 id_rsa(개인키) 측면 이동 authorized_keys 백도어 식별 ssh_host_key MITM known_hosts 대상 식별 면접 포인트 "SSH 키 탈취는 측면 이동 수단 — 정상은 ssh 클라이언트만, 쉘 읽기는 탈취" 12. 다음 편 예고 다음 편 212. 중요 정보 접근 — 인증서·개인키 파일 접근 탐지 에서는 인증서·개인키 파일 접근을 다루는 인증서·개인키 파일 접근 탐지 를 다룹니다. 이전 편: 210. 중요 정보 접근 — 계정 정보(passwd) 접근 탐지 📚 시리즈 전체 보기: 시스템 보안 · 취약점
[디지털 논리 설계] Chapter 6 - 9. 재귀 함수와 Jump, Pseudoinstruction 지난 편에서는 함수 호출과 Stack을 배웠다. 핵심은 다음과 같았다. 함수 인자 → a0 ~ a7 함수 호출 → jal 복귀 주소 → ra 함수 반환값 → a0 함수 복귀 → jr ra 그리고 함수가 기존 Register 값을 보존해야 할 때는 Stack 을 사용했다. 이번에는 이 내용을 조금 더 확장해서 Non-Leaf Function Recursive Function jal / jalr Pseudoinstruction Label Long Jump 을 공부한다. 1. Leaf Function과 Non-Leaf Function 함수는 다른 함수를 호출하느냐에 따라 구분할 수 있다. Leaf Function 다른 함수를 호출하지 않는 함수이다. 예: f2: 계산 jr ra 자기 할 일만 하고 Caller에게 돌아간다. Non-Leaf Function 다른 함수를 다시 호출하는 함수이다. 예: main ↓ f1 ↓ f2 여기서 f1 은 f2 를 호출한다. 따라서 f1 은 Non-Leaf Function 이다. 2. Non-Leaf Function에서 왜 ra를 저장해야 할까? jal 을 실행하면 돌아올 주소가 ra 에 저장된다. 예: main ↓ jal f1 그러면 ra 에는 f1이 끝난 뒤 main의 어디로 돌아가야 하는지 가 저장된다. 그런데 f1 안에서 다시 jal f2 를 실행하면? jal 은 다시 ra 를 사용한다. 즉 기존 ra 값이 덮어써진다. 3. 그래서 Stack에 ra를 저장한다 다른 함수를 호출하기 전에: addi sp, sp, -4 sw ra, 0(sp) 로 ra 를 Stack에 저장한다. 그다음: jal f2 를 실행한다. f2에서 돌아온 뒤: lw ra, 0(sp) addi sp, sp, 4 로 원래 ra 를 복원한다. 마지막: jr ra 를 통해 원래 Caller로 돌아간다. 4. 전체 흐름 f1 시작 ↓ ra를 Stack에 저장 ↓ f2 호출 ↓ f2에서 복귀 ↓ ra 복원 ↓ 원래 Caller로 복귀 즉 Non-Leaf Function에서는 다른 함수를 호출하면서 복귀 주소가 사라지지 않도록 ra를 보존해야 한다. 5. Function Call 전체 규칙 PDF에서는 함수 호출 과정을 Caller와 Callee로 정리한다. Caller 함수를 호출하는 쪽이다. Caller는 필요하면: Register 저장 ↓ a0 ~ a7에 인자 넣기 ↓ jal로 함수 호출 ↓ a0에서 반환값 받기 ↓ 저장했던 Register 복원 을 수행한다. Callee 호출되는 함수다. Callee는 필요하면: s0 ~ s11 같은 Register 저장 ↓ 함수 실행 ↓ 결과를 a0에 저장 ↓ Register 복원 ↓ jr ra 를 수행한다. 6. Recursive Function 이번에는 재귀 함수다. Recursive Function은 자기 자신을 다시 호출하는 함수 이다. 예: factorial(n) 팩토리얼은 다음과 같이 정의할 수 있다. n! = n × (n-1) × (n-2) × ... × 1 예: 3! = 3 × 2 × 1 = 6 7. 재귀로 factorial 만들기 C 코드: int factorial(int n) { if (n <= 1) return 1; else return n * factorial(n - 1); } 예를 들어: factorial(3) 을 실행하면 factorial(3) = 3 × factorial(2) factorial(2) = 2 × factorial(1) factorial(1) = 1 이다. 그다음 거꾸로 올라온다. factorial(1) = 1 factorial(2) = 2 × 1 = 2 factorial(3) = 3 × 2 = 6 8. 재귀 함수에서 생기는 문제 재귀 함수도 결국 함수가 함수를 호출하는 것 이다. 그런데 이번에는 자기 자신을 호출 한다. 따라서 호출할 때마다 ra a0 같은 값이 계속 바뀔 수 있다. 예를 들어: factorial(3) 에서 a0 = 3 인데, 다음 호출 전에: a0 = 2 가 된다. 그다음 호출에서는: a0 = 1 이 된다. 그런데 나중에 다시 3 × 2 를 계산하려면 이전의 3과 2가 필요하다. 9. 그래서 재귀 함수에서도 Stack이 중요하다 호출하기 전에 필요한 값을 Stack에 저장한다. PDF 예제에서는: addi sp, sp, -8 sw a0, 4(sp) sw ra, 0(sp) 를 사용한다. 즉 Stack에: 현재 n 값 복귀 주소 ra 를 저장한다. 10. 재귀 호출 그다음: addi a0, a0, -1 jal factorial 을 실행한다. 즉: factorial(n - 1) 을 호출한다. 11. 재귀 호출에서 돌아오면 Stack에 저장했던 값을 다시 가져온다. lw t1, 4(sp) lw ra, 0(sp) addi sp, sp, 8 여기서: t1 = 원래 n a0 = factorial(n-1)의 결과 가 된다. 따라서: mul a0, t1, a0 을 하면 a0 = n × factorial(n-1) 이 된다. 12. 재귀에서 Stack이 중요한 이유 재귀 호출은 여러 함수 호출이 겹친다. 예: factorial(3) ↓ factorial(2) ↓ factorial(1) 각 호출마다 자기만의 n ra 값이 필요하다. 그래서 Stack에 각각의 값을 따로 저장한다. 즉: 함수 호출마다 Stack Frame이 하나씩 생긴다. 13. Jump 다시 보기 PDF에서는 이후 Jump를 다시 자세히 설명한다. RISC-V의 무조건 Jump는 크게 jal jalr 두 가지이다. 14. jal 형식: jal rd, imm 동작은: rd = PC + 4 PC = PC + imm 이다. 쉽게 말하면: 현재 다음 명령어 주소를 rd에 저장 ↓ imm만큼 떨어진 위치로 이동 한다. 함수 호출에서 흔히: jal ra, 함수 를 사용한다. 그래서 ra 에 복귀 주소가 저장된다. 15. jalr jalr 는 Jump And Link Register 이다. 형식: jalr rd, rs, imm PDF의 설명대로 개념적으로: rd = PC + 4 PC = rs + SignExt(imm) 이다. 즉 jal 이 현재 PC를 기준으로 이동한다면, jalr 는 Register에 저장된 주소를 기준 으로 이동할 수 있다. 16. 그런데 우리가 전에 j, jr을 사용했는데? 맞다. 우리는 지금까지: j target jr ra 를 많이 사용했다. 그런데 PDF에서는 이들이 Pseudoinstruction 이라고 설명한다. 17. Pseudoinstruction이란? Pseudoinstruction은 프로그래머가 편하게 사용할 수 있도록 만든 가짜 명령어 이다. 여기서 가짜라는 뜻은 CPU가 직접 가지고 있는 실제 명령어가 아니다. 라는 의미다. Assembler가 실제 RISC-V 명령어로 바꿔준다. 18. j는 실제로 무엇일까? 우리가 썼던: j label 은 실제로: jal zero, label 이다. 왜 zero 일까? jal 은 원래 복귀 주소를 destination register에 저장한다. 하지만 j 는 그냥 이동만 하면 되므로 복귀 주소가 필요 없다. RISC-V의 zero 는 항상 0이고, 여기에 값을 써도 버려진다. 따라서: jal zero, label 을 하면 복귀 주소는 버리고 label로 이동만 한다. 19. jr ra는 실제로? jr ra 는 실제로: jalr zero, ra, 0 이다. 의미: ra가 가리키는 주소로 이동 하면서 복귀 주소는 zero 에 써서 버린다. 20. ret도 Pseudoinstruction 함수에서 돌아갈 때: ret 이라고 쓸 수도 있다. 이것도 실제로는: jalr zero, ra, 0 이다. 즉: ret = jr ra = jalr zero, ra, 0 라고 이해할 수 있다. 21. 다른 Pseudoinstruction PDF에는 여러 예가 나온다. 예: mv t5, s3 는 실제로: addi t5, s3, 0 이다. 즉 값을 복사하는 것처럼 보이지만, 실제로는 0을 더한다. not s7, t2 는 실제로: xori s7, t2, -1 이다. nop 은 실제로: addi zero, zero, 0 이다. 아무 변화도 일어나지 않으므로 No Operation 이라는 뜻이다. 22. Label Assembly에서: loop: done: simple: 같은 것을 많이 봤다. 이것이 Label이다. Label은 이동할 위치에 사람이 알아보기 쉬운 이름을 붙인 것 이다. 예: jal simple 이라고 적으면 Assembler는 실제로 simple 의 위치를 계산한다. 23. Label은 실제 Machine Code에 이름으로 저장되지 않는다 CPU는 simple loop done 같은 이름을 이해하지 못한다. Assembler가 Label의 실제 위치를 계산해서 Immediate Offset 으로 바꾼다. 즉: jal simple 은 최종적으로 현재 위치에서 simple까지 얼마나 떨어져 있는가 라는 숫자로 바뀐다. 24. PDF의 Label 예제 예를 들어: 0x00000300 jal simple ... 0x0000051C simple: 이라면 거리: 0x51C - 0x300 = 0x21C 이다. 따라서 Label은 실제 명령어에서는 0x21C만큼 이동 하는 형태로 바뀐다. 25. Long Jump 문제가 하나 있다. jal 이나 jalr 에서 사용할 수 있는 Immediate의 크기는 제한되어 있다. PDF에서는: jal → 20-bit immediate jalr → 12-bit immediate 라고 설명한다. 즉 너무 멀리 있는 곳으로 한 번에 이동할 수 없을 수도 있다. 26. auipc 멀리 이동하기 위해 PDF에서는 auipc 명령어를 소개한다. auipc 는 현재 PC에 큰 Immediate 값을 더할 수 있도록 사용된다. 이를 jalr 와 함께 사용하면 더 먼 위치까지 Jump할 수 있다. 27. call Pseudoinstruction PDF에서는: call 이라는 Pseudoinstruction도 소개한다. 큰 범위로 함수 호출을 할 때 내부적으로: auipc jalr 조합으로 바뀔 수 있다. 즉: call 함수 를 쓰면 프로그래머가 직접 복잡한 Jump 주소 계산을 할 필요가 없다. Assembler가 실제 명령어로 바꿔준다. 이번 편 핵심 정리 Non-Leaf Function 다른 함수를 호출하는 함수 다른 jal 이 ra 를 덮어쓸 수 있으므로: ra를 Stack에 저장 해야 할 수 있다. Recursive Function 자기 자신을 호출하는 함수 호출마다 필요한: 인자 ra 기타 Register 를 Stack에 저장한다. jal Jump + 복귀 주소 저장 jalr Register 주소를 기준으로 Jump Pseudoinstruction 실제 CPU 명령어는 아니지만 프로그래머가 편하게 사용하는 명령어 Assembler가 실제 RISC-V 명령어로 바꾼다. 예: j label → jal zero, label jr ra → jalr zero, ra, 0 ret → jalr zero, ra, 0 mv t5, s3 → addi t5, s3, 0 Label Jump할 위치에 붙이는 이름 Assembler가 실제 거리인 Immediate Offset 으로 변환한다. 가장 중요하게 기억할 것 이번 편을 한 줄로 연결하면: 함수를 여러 번 호출하면 Register와 ra가 덮어써질 수 있다. ↓ 그래서 Stack에 저장한다. 그리고: j, jr, ret 같은 명령어는 실제로는 jal / jalr을 편하게 표현한 Pseudoinstruction이다. 라고 기억하면 된다. 다음 편 다음부터 드디어 PDF의 Machine Language 파트로 들어간다. 다음 편에서는: R-Type I-Type S-Type B-Type U-Type J-Type opcode rs1 rs2 rd funct3 funct7 를 공부한다. 즉 지금까지 사람이 읽었던 add s0, s1, s2 가 실제 CPU 안에서는 0과 1의 32비트 명령어 로 어떻게 바뀌는지를 배우게 된다.
시스템 보안 · 취약점 › E. 중요 정보 접근 로그 분석 · 14/50편 (전체 214/450) 학습 단계: 중요 파일 접근 이상 실습 표기: 이 글의 명령어·출력·로그는 로컬 VMware 테스트 VM(Rocky Linux 9 / Ubuntu 22.04) 기준의 「실습 예시」 이며, IP·계정·호스트명은 가상의 값입니다. 선행 학습 213. 중요 정보 접근 — DB 설정·자격증명 파일 접근 탐지 202. 중요 정보(민감 데이터)의 분류와 식별 1. 개념 현대 애플리케이션은 외부 서비스 연동을 위해 API 키·토큰·시크릿 을 사용합니다. 이들이 탈취되면 외부 서비스(클라우드·결제·메일) 접근 권한, 세션 위조, 데이터 복호화에 악용됩니다. 애플리케이션 비밀 유형과 위험 API 키(AWS·GCP·결제) → 클라우드 자원·과금·데이터 접근 OAuth 토큰·세션 시크릿 → 세션 위조·계정 탈취 암호화 키(app secret) → 저장 데이터 복호화 webhook 시크릿 → 위조 요청 저장 위치: 설정 파일, 코드, 환경변수(E15), 시크릿 매니저 시크릿은 앱이 읽는 것이 정상입니다. 쉘 명령·grep 패턴 검색을 통한 수집은 탈취 시도입니다. 2. 왜 중요한가 API 키 탈취는 클라우드 자원 장악·과금 폭탄·클라우드 데이터 유출로 이어집니다. 세션 시크릿 탈취는 세션 위조(다른 사용자 가장)를 가능하게 합니다. 공격자는 grep으로 시크릿 패턴을 광범위 검색(수집)하므로 이 패턴도 탐지합니다. 3. 핵심 명령어 / 설정 시크릿 유형 악용 위험 클라우드 API 키 자원·데이터 장악 매우 높음 OAuth/세션 토큰 세션 위조 높음 app secret(암호화) 데이터 복호화 높음 webhook 시크릿 요청 위조 중간 grep 패턴 검색 시크릿 수집 높음 4. 실습 (실습 예시) # 애플리케이션 비밀 접근 탐지 (분석 방법) # 시크릿 패턴 광범위 검색(수집 행위) sudo ausearch -k cred_access -i --start recent 2>/dev/null | grep -E 'comm="(grep|rg|ag|find)"' | tail # 시크릿 파일 직접 접근 sudo ausearch -k cred_access -i --start recent 2>/dev/null | grep -E 'secret|api[_-]?key|token|credentials' | grep -vE 'comm="(node|python|ruby|java|php-fpm)"' 5. 정상 상태 $ (시크릿 접근) (없음 또는 앱 프로세스 로드만) 시크릿 접근이 앱 프로세스의 정상 로드에 그치고, grep 패턴 검색·쉘 읽기가 없는 상태가 정상입니다. 6. 이상 상태 $ (시크릿 접근) 04:00 comm="grep" auid=www-data proctitle="grep -rn api_key /var/www" 04:01 comm="cat" auid=www-data /var/www/app/config/secrets.yml grep -rn api_key 로 웹루트 전체 시크릿 검색 → 광범위 수집 secrets.yml 직접 읽기 → API 키·토큰 탈취 시크릿 패턴 검색·수집 → 외부 서비스 장악 전조 → 정탐 7. 로그 분석 (분석 방법) 애플리케이션 비밀 탈취 흐름입니다(가상의 예시 로그). type=SYSCALL comm="grep" auid=www-data key="cred_access" type=PROCTITLE proctitle=grep -rn "api_key\|secret\|token" /var/www → 웹루트 전체 시크릿 패턴 광범위 검색(수집) [이후] 발견한 AWS 키로 클라우드 접근(별도 탐지) 관찰 해석 grep -rn api_key 시크릿 광범위 검색 /var/www 전체 수집 범위 cat secrets.yml 직접 탈취 이후 클라우드 외부 장악 시크릿 패턴 검색(수집) → 외부 서비스 접근으로 이어지므로 아웃바운드와 연계합니다. 8. SOC 관제 포인트 애플리케이션 비밀(API 키·토큰·시크릿) 접근은 외부 서비스 장악·세션 위조·복호화 로 이어집니다. 정상은 앱 로드 — grep 패턴 검색(광범위 수집)·쉘 읽기는 탈취 신호입니다. 시크릿 탈취 후 외부(클라우드·API) 접근 연계가 핵심 탐지 포인트입니다. 9. 탐지 규칙 <!-- 실습 예시 룰: 적용 전 wazuh-logtest 및 테스트 환경 검증 필요 --> <group name="local,syssec_e,sensitive_access,"> <rule id="104130" level="11"> <if_sid>104000</if_sid> <field name="audit.proctitle" type="pcre2">(grep|rg|ag|find).*(api[_-]?key|secret|token|password|aws_|credential)</field> <description>시크릿 패턴 광범위 검색(애플리케이션 비밀 수집)</description> <mitre><id>T1552.001</id></mitre> </rule> </group> 정상 앱 프로세스는 제외합니다. 시크릿 수집 후 외부 접근(클라우드 API)을 네트워크 로그와 상관합니다. 10. 대응 방법 초기 확인 — 접근·검색된 시크릿 유형·범위·주체·방법을 확인합니다. 범위 확인 — grep 패턴 검색(수집)·직접 읽기·이후 외부 접근을 확인합니다. 증거 확보 — 시크릿 접근 이벤트와 연계(외부 접근) 로그를 보존합니다. 차단/조치 — 탈취 정탐이면 세션 종료·시크릿 전면 교체(rotate)·외부 영향 조사를 진행합니다. 재발 방지 — 애플리케이션 비밀 접근·수집 탐지를 운영합니다. 11. 핵심 정리 시크릿 유형 악용 클라우드 API 키 자원·데이터 장악 OAuth/세션 토큰 세션 위조 app secret 데이터 복호화 grep 패턴 검색 광범위 수집 면접 포인트 "시크릿 탈취는 외부 서비스 장악 — grep 패턴 검색(수집)도 핵심 탐지 대상" 12. 다음 편 예고 다음 편 215. 중요 정보 접근 — 환경변수·.env 파일 접근 탐지 에서는 환경변수·.env 파일 접근을 다루는 환경변수·.env 파일 접근 탐지 를 다룹니다. 이전 편: 213. 중요 정보 접근 — DB 설정·자격증명 파일 접근 탐지 📚 시리즈 전체 보기: 시스템 보안 · 취약점
시스템 보안 · 취약점 › E. 중요 정보 접근 로그 분석 · 13/50편 (전체 213/450) 학습 단계: 중요 파일 접근 이상 실습 표기: 이 글의 명령어·출력·로그는 로컬 VMware 테스트 VM(Rocky Linux 9 / Ubuntu 22.04) 기준의 「실습 예시」 이며, IP·계정·호스트명은 가상의 값입니다. 선행 학습 212. 중요 정보 접근 — 인증서·개인키 파일 접근 탐지 202. 중요 정보(민감 데이터)의 분류와 식별 1. 개념 애플리케이션은 DB 접속 정보를 설정 파일에 저장합니다. 이 DB 자격증명 이 탈취되면 공격자가 직접 데이터베이스에 접속해 대량 데이터를 유출할 수 있어, 접근 탐지가 중요합니다. DB 자격증명 파일 접근 위험 app/config/database.yml DB 접속정보(host/user/pass) /etc/my.cnf, .my.cnf MySQL 설정·자격증명 wp-config.php 등 앱 DB 설정 .env (DB_PASSWORD 등) 환경 변수 DB 자격증명(E15) 탈취 → DB 직접 접속 → 대량 데이터 유출(E19·20) DB 자격증명은 앱 프로세스가 읽는 것이 정상입니다. 쉘 명령·웹 계정의 읽기는 탈취 시도입니다. 2. 왜 중요한가 DB 자격증명 탈취는 데이터베이스 직접 접속 → 대량 개인정보·데이터 유출의 관문입니다. 앱 설정 파일은 앱 프로세스만 읽으므로, 쉘·웹 계정의 읽기는 이상입니다. 자격증명 접근 후 DB 접속·덤프(E19·20)로 이어지는 연계가 핵심입니다. 3. 핵심 명령어 / 설정 DB 설정 파일 담긴 정보 위험 database.yml / .php 접속·비밀번호 매우 높음 /etc/my.cnf , .my.cnf MySQL 자격증명 높음 .env DB_* DB 환경변수 매우 높음 pg_service.conf PostgreSQL 높음 앱 secret 세션·암호화 키 높음 4. 실습 (실습 예시) # DB 자격증명 접근 탐지 (분석 방법) sudo ausearch -k cred_access -i --start recent 2>/dev/null | grep -E 'database\.yml|my\.cnf|wp-config|pg_service|\.env' | grep -vE 'comm="(ruby|php-fpm|python|node|mysqld|postgres)"' | tail # 자격증명 접근 후 DB 클라이언트 실행(연계) sudo ausearch -k cred_access,data_access -i --start recent 2>/dev/null | grep -E 'comm="(mysql|psql|mongo)"' 5. 정상 상태 $ (DB 자격증명 접근) (없음 또는 앱 프로세스만) DB 설정 파일 접근이 앱 프로세스(php-fpm·node 등)의 정상 로드에 그치고, 쉘·웹 계정 읽기가 없는 상태가 정상입니다. 6. 이상 상태 $ (DB 자격증명 접근) 04:00 comm="cat" auid=www-data /var/www/app/config/database.yml $ (이후 DB 접속) 04:01 comm="mysql" auid=www-data (탈취 자격증명으로 접속) 웹 계정이 database.yml을 cat → DB 접속 자격증명 탈취 직후 mysql 클라이언트 실행 → 탈취 자격증명으로 DB 직접 접속 자격증명 읽기 → DB 접속 연계 → 데이터 유출 전조 → 정탐 7. 로그 분석 (분석 방법) DB 자격증명 탈취 흐름입니다(가상의 예시 로그). type=SYSCALL comm="cat" auid=www-data key="cred_access" type=PATH name="/var/www/app/config/database.yml" → 웹 계정이 DB 접속정보 읽기(탈취) [이후] mysql -u app -p<탈취비번> → DB 접속 → 대량 SELECT(E19) 관찰 해석 cat database.yml 자격증명 탈취 auid=www-data 비앱 주체 이후 mysql DB 직접 접속 대량 SELECT 데이터 유출 자격증명 읽기 → DB 접속 → 대량 조회로 이어지는 체인을 연계로 탐지합니다. 8. SOC 관제 포인트 DB 설정·자격증명 접근은 DB 직접 접속 → 대량 유출 의 관문입니다. 정상은 앱 프로세스 로드 — 쉘·웹 계정의 읽기는 자격증명 탈취 신호입니다. 자격증명 읽기 → DB 클라이언트 접속(E19·20) 연계가 핵심 탐지 포인트입니다. 9. 탐지 규칙 <!-- 실습 예시 룰: 적용 전 wazuh-logtest 및 테스트 환경 검증 필요 --> <group name="local,syssec_e,sensitive_access,"> <rule id="104120" level="12"> <if_sid>104000</if_sid> <field name="audit.file" type="pcre2">(database\.(yml|php)|my\.cnf|wp-config\.php|pg_service\.conf)$</field> <field name="audit.comm" type="pcre2">^(cat|cp|less|tar|scp|curl|grep|strings)$</field> <description>DB 설정·자격증명 파일 접근(DB 침해 전조)</description> <mitre><id>T1552.001</id></mitre> </rule> </group> 정상 앱 프로세스는 화이트리스트로 제외합니다. 자격증명 접근 후 DB 클라이언트 실행을 상관으로 연계합니다(E42). 10. 대응 방법 초기 확인 — 접근된 DB 설정 파일·주체·방법과 앱 프로세스 여부를 확인합니다. 범위 확인 — 자격증명 읽기 후 DB 접속(mysql·psql)·대량 조회로 이어졌는지 확인합니다. 증거 확보 — DB 자격증명 접근 이벤트와 연계 로그를 보존합니다. 차단/조치 — 탈취 정탐이면 세션 종료·DB 자격증명 교체·DB 접근 조사를 진행합니다. 재발 방지 — DB 자격증명 접근 탐지를 운영합니다. 11. 핵심 정리 DB 설정 파일 위험 database.yml/php 접속·비밀번호 탈취 my.cnf/.my.cnf MySQL 자격증명 .env DB_* DB 환경변수 이후 DB 접속 대량 유출 전조 면접 포인트 "DB 자격증명 탈취는 대량 유출 관문 — 읽기→DB 접속 연계가 핵심" 12. 다음 편 예고 다음 편 214. 중요 정보 접근 — 애플리케이션 비밀(secret) 접근 탐지 에서는 애플리케이션 비밀 접근을 다루는 애플리케이션 비밀(secret) 접근 탐지 를 다룹니다. 이전 편: 212. 중요 정보 접근 — 인증서·개인키 파일 접근 탐지 📚 시리즈 전체 보기: 시스템 보안 · 취약점
시스템 보안 · 취약점 › E. 중요 정보 접근 로그 분석 · 16/50편 (전체 216/450) 학습 단계: 중요 파일 접근 이상 실습 표기: 이 글의 명령어·출력·로그는 로컬 VMware 테스트 VM(Rocky Linux 9 / Ubuntu 22.04) 기준의 「실습 예시」 이며, IP·계정·호스트명은 가상의 값입니다. 선행 학습 215. 중요 정보 접근 — 환경변수·.env 파일 접근 탐지 202. 중요 정보(민감 데이터)의 분류와 식별 1. 개념 백업·아카이브는 한 파일에 대량 데이터 가 모여 있어 공격자에게 매우 효율적인 표적입니다. 개별 파일을 하나씩 수집할 필요 없이 백업 하나로 전체 데이터를 탈취할 수 있습니다. 백업·아카이브 접근 위험 /var/backup/*.tar.gz 전체 시스템·DB 백업 *.sql, *.dump DB 덤프(전체 데이터) *.bak, *.old 설정·데이터 백업 웹루트의 backup.zip 외부 다운로드 가능(노출) 위험: 백업 1개 = 전체 데이터 → 효율적 유출 표적 백업은 정상적으로 백업 프로세스·관리자가 접근합니다. 쉘 명령의 읽기·복사·전송은 탈취 시도입니다. 2. 왜 중요한가 백업 하나에 전체 데이터가 모여 있어, 백업 탈취는 가장 효율적인 대량 유출입니다. 웹루트에 놓인 백업은 외부에서 직접 다운로드 가능해 특히 위험합니다(E02). 정상 백업 접근(백업 프로세스·정기)과 쉘의 읽기·전송을 구분해야 합니다. 3. 핵심 명령어 / 설정 백업 유형 담긴 데이터 위험 시스템 .tar.gz 전체 시스템 매우 높음 DB .sql / .dump 전체 DB 매우 높음 설정 .bak 설정·자격증명 높음 웹루트 백업 외부 노출 매우 높음 정기 백업 접근 정상 정상 4. 실습 (실습 예시) # 백업·아카이브 접근 탐지 (분석 방법) # 백업 파일 읽기·전송(백업 프로세스 외) sudo ausearch -k data_access,exfil -i --start recent 2>/dev/null | grep -E '\.(tar|gz|tgz|sql|dump|bak|zip)$' | grep -vE 'comm="(backup|rsync|mysqldump|tar)"' | tail # 웹루트의 백업 파일(외부 노출 점검) find /var/www -type f \( -name '*.sql' -o -name '*.bak' -o -name '*.tar.gz' -o -name '*.zip' \) 2>/dev/null 5. 정상 상태 $ (백업 접근) (없음 또는 백업 프로세스만) $ (웹루트 백업) (없음) 백업 접근이 정기 백업 프로세스에 그치고, 웹루트에 노출된 백업이 없는 상태가 정상입니다. 6. 이상 상태 $ (백업 접근) 04:00 comm="scp" auid=devops /var/backup/full-2026.tar.gz → 외부 $ (웹루트 백업) /var/www/html/db-backup.sql (외부 다운로드 가능) 전체 백업(full-2026.tar.gz)을 scp로 외부 전송 → 전체 데이터 유출 웹루트의 db-backup.sql → 외부에서 URL로 직접 다운로드 가능 백업 통째 탈취·노출 → 대량 유출 → 정탐(최고 위험) 7. 로그 분석 (분석 방법) 백업 탈취 흐름입니다(가상의 예시 로그). type=SYSCALL comm="scp" auid=devops key="exfil" type=PATH name="/var/backup/full-2026.tar.gz" → 전체 백업을 외부로 전송(대량 유출) [또는] 웹루트 backup.sql을 외부에서 HTTP GET(접근 로그) 관찰 해석 scp full.tar.gz 전체 백업 유출 웹루트 .sql 외부 노출 1파일=전체 효율적 유출 auid=비백업 탈취 주체 백업 1개가 전체 데이터이므로, 백업 전송은 즉시 대량 유출로 간주합니다. 8. SOC 관제 포인트 백업·아카이브는 한 파일에 대량 데이터 가 모여 효율적인 유출 표적입니다. 웹루트의 백업은 외부 직접 다운로드가 가능해 특히 위험합니다. 정상 백업 접근과 쉘의 읽기·전송을 구분하고, 백업 전송은 대량 유출로 간주합니다. 9. 탐지 규칙 <!-- 실습 예시 룰: 적용 전 wazuh-logtest 및 테스트 환경 검증 필요 --> <group name="local,syssec_e,sensitive_access,"> <rule id="104150" level="12"> <if_sid>104000</if_sid> <field name="audit.file" type="pcre2">\.(tar\.gz|tgz|sql|dump|bak)$|/backup/</field> <field name="audit.comm" type="pcre2">^(scp|curl|wget|nc|cp|cat)$</field> <description>백업·아카이브 파일 비정상 접근·전송(대량 유출)</description> <mitre><id>T1005</id><id>T1041</id></mitre> </rule> </group> 정상 백업 프로세스(backup·rsync·mysqldump)는 제외합니다. 백업 외부 전송은 유출(E32)로 즉시 상관합니다. 10. 대응 방법 초기 확인 — 접근·전송된 백업 파일·담긴 데이터 범위·주체를 확인합니다. 범위 확인 — 백업 프로세스 여부·외부 전송·웹루트 노출을 확인합니다. 증거 확보 — 백업 접근·전송 이벤트와 대상 백업을 보존합니다. 차단/조치 — 대량 유출 정탐이면 전송 차단·세션 종료·유출 범위(백업 내용) 조사를 진행합니다. 재발 방지 — 백업·아카이브 접근 탐지를 운영합니다. 11. 핵심 정리 백업 유형 위험 시스템 .tar.gz 전체 시스템 DB .sql/.dump 전체 DB 설정 .bak 설정·자격증명 웹루트 백업 외부 노출 면접 포인트 "백업 1개=전체 데이터 — 백업 전송은 즉시 대량 유출로 간주" 12. 다음 편 예고 다음 편 217. 중요 정보 접근 — 사용자 홈·개인 데이터 접근 탐지 에서는 사용자 홈·개인 데이터 접근을 다루는 사용자 홈·개인 데이터 접근 탐지 를 다룹니다. 이전 편: 215. 중요 정보 접근 — 환경변수·.env 파일 접근 탐지 📚 시리즈 전체 보기: 시스템 보안 · 취약점
Thread 는 프로그램 안에서 코드를 실행하는 하나의 실행 흐름 이다. 하나의 프로그램에서도 여러 Thread를 사용하면 여러 작업을 나누어 처리할 수 있다. 한 줄 요약: Thread는 프로그램 내부에서 독립적으로 코드를 실행할 수 있는 하나의 작업 흐름이다. Thread란? 일반적인 프로그램은 먼저 하나의 Thread에서 실행된다. Main Thread Start() ↓ Update() ↓ Attack() ↓ Move() 코드가 하나의 실행 흐름을 따라 순서대로 실행되는 것이다. 하지만 Thread를 추가하면 Main Thread ├─ 게임 로직 ├─ 입력 처리 └─ 렌더링 관련 작업 Worker Thread └─ 별도의 계산 작업 처럼 서로 다른 실행 흐름을 만들 수 있다. .NET의 Thread 클래스는 Thread를 생성하고 제어하는 역할을 한다. Thread 만들기 Thread를 사용하려면 using System.Threading; 을 추가한다. 간단한 Thread는 다음처럼 만들 수 있다. void Work() { Console.WriteLine("작업 실행"); } Thread thread = new Thread(Work); 하지만 이 상태에서는 아직 실행되지 않는다. 실행하려면 thread.Start(); 를 호출해야 한다. 전체 코드는 다음과 같다. void Work() { Console.WriteLine("작업 실행"); } Thread thread = new Thread(Work); thread.Start(); Thread 생성자는 실행할 메서드를 나타내는 ThreadStart Delegate를 받을 수 있다. Main Thread와 Worker Thread 예를 들어 void Work() { for (int i = 0; i < 5; i++) { Console.WriteLine($"Worker : {i}"); } } Thread thread = new Thread(Work); thread.Start(); for (int i = 0; i < 5; i++) { Console.WriteLine($"Main : {i}"); } 를 실행하면 결과가 반드시 Worker 0 Worker 1 Worker 2 Main 0 Main 1 ... 처럼 일정하게 나오지는 않는다. 상황에 따라 Main 0 Worker 0 Worker 1 Main 1 Worker 2 ... 처럼 섞여서 실행될 수 있다. 즉 여러 Thread의 실행 순서는 항상 동일하다고 보장할 수 없다. Thread.Sleep() 현재 실행 중인 Thread를 일정 시간 동안 멈출 수 있다. Thread.Sleep(1000); 1000 은 밀리초이므로 1000ms = 1초 이다. 예를 들면 void Work() { Console.WriteLine("시작"); Thread.Sleep(1000); Console.WriteLine("1초 후"); } 이 된다. 중요한 점은 Thread.Sleep() 은 해당 Thread 자체를 멈춘다. 는 것이다. Unity에서 Sleep을 주의해야 하는 이유 예를 들어 Unity의 Main Thread에서 Thread.Sleep(3000); 을 실행하면 Main Thread가 3초 동안 멈춘다. 그러면 Update 입력 처리 게임 로직 화면 처리 등도 같이 멈출 수 있다. 즉 게임이 멈춘 것처럼 보일 수 있다. 따라서 Unity의 시간 지연이 목적이라면 보통 yield return new WaitForSeconds(1f); 같은 Coroutine 방식이 더 적절하다. Thread.Join() Join() 은 다른 Thread의 작업이 끝날 때까지 현재 Thread를 기다리게 하는 메서드 이다. 예를 들어 Thread thread = new Thread(Work); thread.Start(); thread.Join(); Console.WriteLine("작업 완료"); 라고 하면 Worker Thread 시작 ↓ Work 실행 ↓ Work 종료 ↓ Join 종료 ↓ 작업 완료 출력 순서가 된다. Thread.Join() 은 대상 Thread가 종료될 때까지 호출한 Thread를 Block 한다. Join 사용 예제 void Work() { Thread.Sleep(1000); Console.WriteLine("Worker 완료"); } Thread thread = new Thread(Work); thread.Start(); Console.WriteLine("기다리는 중"); thread.Join(); Console.WriteLine("모든 작업 완료"); 결과는 기다리는 중 약 1초 Worker 완료 모든 작업 완료 와 같은 흐름이 된다. Thread와 Delegate 앞에서 공부한 Delegate와도 연결된다. Thread 생성자는 실행할 메서드를 전달받는다. void Work() { Console.WriteLine("작업"); } Thread thread = new Thread(Work); 여기서 Work 라는 메서드를 Thread에게 전달한다. 람다식으로도 작성할 수 있다. Thread thread = new Thread(() => { Console.WriteLine("작업 실행"); }); thread.Start(); 즉 지금까지 배운 Delegate ↓ Lambda ↓ Thread에 실행할 코드 전달 이라는 연결도 가능하다. 여러 Thread에서 같은 데이터 사용 Thread에서 가장 중요한 문제 중 하나다. 예를 들어 int count = 0; 을 두 Thread가 동시에 수정한다고 하자. void Add() { for (int i = 0; i < 10000; i++) { count++; } } 그리고 Thread thread1 = new Thread(Add); Thread thread2 = new Thread(Add); thread1.Start(); thread2.Start(); thread1.Join(); thread2.Join(); 두 Thread에서 각각 10000 번 증가시키므로 20000 을 예상할 수 있다. 하지만 실제로는 항상 정확히 20000 이 나온다고 보장할 수 없다. Race Condition 이유는 count++; 가 내부적으로 완전히 하나의 동작만 수행하는 것이 아니기 때문이다. 개념적으로는 count 읽기 ↓ + 1 계산 ↓ count에 저장 순서로 처리된다. 두 Thread가 동시에 접근하면 Thread A : count 읽기 → 10 Thread B : count 읽기 → 10 Thread A : 11 저장 Thread B : 11 저장 처럼 증가가 하나 사라질 수 있다. 이렇게 여러 Thread가 공유 데이터에 동시에 접근하면서 결과가 달라지는 문제를 Race Condition(경쟁 상태) 이라고 한다. lock 공유 데이터를 안전하게 처리해야 할 때 lock 을 사용할 수 있다. private readonly object _lockObject = new(); private int _count; void Add() { lock (_lockObject) { _count++; } } lock 영역에는 한 번에 하나의 Thread만 들어갈 수 있다. Thread A ↓ lock 획득 ↓ count 수정 ↓ lock 해제 ↓ Thread B ↓ count 수정 이를 통해 동시에 같은 데이터를 변경하면서 발생하는 문제를 막을 수 있다. Unity에서 Thread를 사용할 때 Unity에서는 Thread 사용 시 특히 주의해야 한다. 대부분의 Unity API는 Thread Safe하지 않다. 따라서 일반적으로 Unity API는 Main Thread에서 호출해야 한다. Unity 공식 문서 역시 대부분의 Unity API는 thread-safe하지 않으므로 메인 스레드에서 사용해야 한다고 설명한다. 예를 들어 Worker Thread에서 다음과 같은 코드는 피해야 한다. Thread thread = new Thread(() => { transform.position = Vector3.zero; }); Transform , GameObject , Component 등의 Unity API를 Worker Thread에서 직접 접근하면 문제가 발생할 수 있다. Thread에 적합한 작업 Thread는 Unity 객체를 직접 수정하는 작업보다 Unity API와 독립적인 계산 작업 에 적합하다. 예를 들면 대규모 숫자 계산 경로 계산 일부 데이터 처리 파일 처리 압축 / 해제 복잡한 알고리즘 같은 작업이다. 예를 들어 Thread thread = new Thread(() => { int result = HeavyCalculation(); }); 처럼 순수한 C# 계산을 별도의 Thread에서 처리할 수 있다. Coroutine과 Thread의 차이 앞에서 공부한 Coroutine과 Thread는 완전히 다른 개념이다. 구분 Coroutine Thread 실행 주로 Main Thread 별도 Thread 가능 병렬 실행 X 가능 yield 사용 사용하지 않음 Unity API 사용 가능 대부분 직접 사용 불가 주요 목적 여러 프레임에 작업 분산 별도의 실행 흐름에서 작업 예를 들어 IEnumerator AttackRoutine() { yield return new WaitForSeconds(1f); Attack(); } 은 1초 동안 별도 CPU Thread에서 실행되는 것이 아니다. Main Thread에서 실행되다가 yield 에서 중단되고 나중에 이어서 실행된다. 즉 Coroutine은 Thread가 아니다. 이 부분은 반드시 구분해야 한다. 멀티스레딩 하나의 프로그램에서 여러 Thread를 사용하는 것을 Multithreading 이라고 한다. Process │ ├─ Main Thread │ ├─ Thread A │ └─ Thread B 여러 CPU Core를 활용할 수 있는 상황이라면 서로 다른 Thread의 작업이 병렬적으로 실행될 수도 있다. 하지만 Thread가 많다고 항상 성능이 좋아지는 것은 아니다. Thread 생성과 전환에도 비용이 있고 Race Condition Deadlock 동기화 공유 데이터 관리 같은 문제도 생길 수 있다. Unity에서는 Thread를 직접 많이 사용할까? Thread 는 멀티스레딩의 기본 원리를 이해하기 위해 매우 중요한 개념이다. 다만 최신 Unity 개발에서는 항상 직접 new Thread(...) 를 만드는 것만이 정답은 아니다. Unity에는 작업에 따라 Coroutine async / await Awaitable Job System 같은 다른 선택지도 있다. 특히 최신 Unity는 Awaitable 을 제공하며, 무거운 계산을 백그라운드로 넘기는 방법도 제공한다. 따라서 이번 단계에서는 우선 Thread가 무엇이고 멀티스레딩에서 어떤 문제가 생기는지 를 이해하는 것이 중요하다. 질문 포인트 Q. Thread란? 프로세스 내부에서 코드를 실행하는 하나의 실행 흐름이다. 하나의 프로세스는 여러 Thread를 가질 수 있다. Q. Start() 와 Join() 의 차이는? Start() 는 Thread 실행을 시작하고, Join() 은 해당 Thread가 종료될 때까지 현재 Thread를 기다리게 한다. Q. Coroutine은 Thread인가? 아니다. Coroutine은 보통 Main Thread에서 실행되며 yield 를 통해 실행을 여러 프레임으로 나누는 구조이다. Q. Unity에서 Worker Thread로 GameObject를 수정해도 되는가? 대부분의 Unity API는 thread-safe하지 않으므로 일반적으로 Main Thread에서 사용해야 한다. 오늘의 정리 Thread는 하나의 실행 흐름 이다. 프로그램에는 기본적으로 Main Thread가 존재한다. new Thread() 로 별도의 Thread를 만들 수 있다. Start() 는 Thread를 실행한다. Sleep() 은 현재 Thread를 일시적으로 멈춘다. Join() 은 다른 Thread가 끝날 때까지 현재 Thread를 기다린다. 여러 Thread가 같은 데이터를 수정하면 Race Condition 이 발생할 수 있다. lock 으로 공유 데이터 접근을 동기화할 수 있다. Unity API 대부분은 Main Thread에서 사용해야 한다. Coroutine과 Thread는 완전히 다른 개념이다. 마지막으로 이 흐름을 기억하자. Process ↓ Main Thread │ ├─ Thread 생성 │ └─ Start() ↓ Worker Thread ↓ 작업 ↓ 종료 ↓ Join() 기본 코드는 다음과 같다. using System.Threading; Thread thread = new Thread(() => { // 별도의 Thread에서 실행할 작업 }); thread.Start(); thread.Join();
시스템 보안 · 취약점 › E. 중요 정보 접근 로그 분석 · 18/50편 (전체 218/450) 학습 단계: 중요 파일 접근 이상 실습 표기: 이 글의 명령어·출력·로그는 로컬 VMware 테스트 VM(Rocky Linux 9 / Ubuntu 22.04) 기준의 「실습 예시」 이며, IP·계정·호스트명은 가상의 값입니다. 선행 학습 217. 중요 정보 접근 — 사용자 홈·개인 데이터 접근 탐지 208. 중요 정보 접근 이상 징후의 판정 기준 1. 개념 2단계(중요 파일 접근, E09~17)를 종합합니다. 개별 탐지를 대상별 위험 우선순위와 판정 흐름으로 묶어, "무엇을 먼저 보고 어떻게 종합하는가"를 정리합니다. 중요 파일 접근 종합 체계 [대상 우선순위] 최상: shadow·SSH 키·인증서·DB 자격증명 (E09·11·12·13) 상: 시크릿·.env·백업 (E14·15·16) 중: passwd·홈 개인 데이터 (E10·17) [판정] 6축(E08) → 위험 축 수 → 정탐/오탐 [연계] 접근 → 수집 → 유출 (E07·40·42) 개별 편이 "어떻게 탐지"였다면, 이 편은 "어떤 순서로 보고 어떻게 종합"입니다. 2. 왜 중요한가 대상 우선순위가 있어야 수많은 접근 중 치명적인 자격증명 접근을 먼저 처리합니다. 모든 접근은 6축(E08)이라는 공통 판정 틀을 공유합니다. 접근은 그 자체보다 "수집·유출로 이어지는가"(연계)로 공격을 확정합니다. 3. 핵심 명령어 / 설정 단계 핵심 질문 참조 대상 식별 무엇에 접근(우선순위) E09~17 주체·방법 누가·어떻게(서비스/쉘) E05·06 시점·범위 언제·얼마나 E04·08 연계 확인 수집·유출로 이어졌나 E07 종합 판정 위험 축 수 E08 4. 실습 (실습 예시) # 중요 파일 접근 종합 점검 (분석 방법) echo "최상위 자격증명 접근(쉘):" sudo ausearch -k sensitive_read,cred_access -i --start today 2>/dev/null | grep -E 'shadow|\.ssh/|\.key|database\.' | grep -cE 'comm="(cat|cp|tar|scp|curl)"' echo "계정별 중요 파일 접근:" sudo ausearch -k sensitive_read,cred_access -i --start today 2>/dev/null | grep -oE 'auid=[a-z0-9]+' | sort | uniq -c | sort -rn 5. 정상 상태 최상위 자격증명 접근(쉘): 0 계정별 접근: 120 auid=mysqld-svc 14 auid=backup 최상위 자격증명에 대한 쉘 접근이 0이고, 접근이 서비스·백업 계정에 집중된 상태가 정상입니다. 6. 이상 상태 최상위 자격증명 접근(쉘): 5 계정별 접근: 18 auid=devops 9 auid=www-data 자격증명 쉘 접근 5건(shadow·키·DB) → 다중 고위험 접근 비서비스 계정(devops·www-data)에 접근 집중 → 주체 축 위험 2단계 종합 지표가 모두 위험 → 공격 진행(자격증명 수집) 상태 7. 로그 분석 (분석 방법) 중요 파일 접근 종합 판정 흐름입니다(가상의 예시). [수집] sensitive_read/cred_access 접근 이벤트 ↓ [대상 분류] 최상(자격증명)/상(시크릿·백업)/중(홈) ↓ [6축 판정] 주체·대상·방법·시점·범위·연계 ↓ [연계 확인] 수집(tar)·유출(curl)로 이어짐? ↓ [종합] 고위험 대상 수 + 위험 축 → 정탐/오탐 지표 정상 위험 자격증명 쉘 접근 0 1+ 비서비스 주체 적음 집중 유출 연계 없음 있음 지표를 종합하면 개별 접근보다 공격 진행(자격증명 수집)을 정확히 판정합니다. 8. SOC 관제 포인트 중요 파일 접근은 대상 우선순위(최상 자격증명→중 홈) 로 처리 순서를 정합니다. 모든 접근은 6축(E08) 공통 판정 틀로 정탐/오탐을 가립니다. 접근 → 수집 → 유출 연계로 분석을 완성합니다. 9. 탐지 규칙 <!-- 실습 예시 룰: 적용 전 wazuh-logtest 및 테스트 환경 검증 필요 --> <group name="local,syssec_e,sensitive_access,"> <!-- 짧은 시간 내 다중 자격증명 접근 종합 경보 --> <rule id="104170" level="13" frequency="4" timeframe="300"> <if_matched_sid>104080</if_matched_sid> <same_field>audit.session</same_field> <description>동일 세션 내 다중 중요 파일·자격증명 접근(2단계 종합 경보)</description> <mitre><id>T1552</id><id>T1005</id></mitre> </rule> </group> 개별 룰(E09~17) 상위에 종합 상관 룰을 두어 자격증명 수집을 한 경보로 포착합니다. 10. 대응 방법 초기 확인 — 2단계 종합 지표(자격증명 쉘 접근·비서비스 주체·유출 연계)를 확인합니다. 범위 확인 — 다중 고위험 접근이 같은 세션·짧은 시간에 몰렸는지 확인합니다. 증거 확보 — 2단계 전체 접근 이벤트와 연계 로그를 보존합니다. 차단/조치 — 종합 판정이 정탐이면 세션 대응·자격증명 교체·유출 조사를 진행합니다. 재발 방지 — 대상 우선순위·6축·연계를 묶은 종합 분석 체계를 운영합니다. 11. 핵심 정리 단계 내용 대상 우선순위 최상(자격증명)→중(홈) 판정 틀 6축(E08) 공통 연계 접근→수집→유출 종합 룰 다중 자격증명 세션 상관 면접 포인트 "개별 접근을 대상 우선순위·6축·연계로 종합해 자격증명 수집을 판정" 12. 다음 편 예고 다음 편 219. 중요 정보 접근 — 데이터베이스 파일 직접 접근 탐지 에서는 3단계로 넘어가 DB 접근을 다루는 데이터베이스 파일 직접 접근 탐지 를 다룹니다. 이전 편: 217. 중요 정보 접근 — 사용자 홈·개인 데이터 접근 탐지 📚 시리즈 전체 보기: 시스템 보안 · 취약점
시스템 보안 · 취약점 › E. 중요 정보 접근 로그 분석 · 21/50편 (전체 221/450) 학습 단계: DB·대량 데이터 접근 이상 실습 표기: 이 글의 명령어·출력·로그는 로컬 VMware 테스트 VM(Rocky Linux 9 / Ubuntu 22.04) 기준의 「실습 예시」 이며, IP·계정·호스트명은 가상의 값입니다. 선행 학습 220. 중요 정보 접근 — 데이터베이스 덤프 생성 탐지 208. 중요 정보 접근 이상 징후의 판정 기준 1. 개념 개별 파일 접근(E09~17)과 달리, 여기서는 다수 파일을 짧은 시간에 연속 읽는 패턴 을 봅니다. 공격자는 스크립트·도구로 데이터를 자동 대량 수집하므로, 빈도·범위가 정상과 크게 다릅니다. 대량 파일 읽기 패턴 find + cat/cp: find / -name '*.conf' -exec cat 재귀 복사: cp -r /data /tmp 자동 수집 스크립트: 수백 파일 연속 open tar 대량 아카이브: 디렉터리 전체 압축 판정: 단위 시간당 파일 open 수 >> 기준선(E04) 접근 파일 다양성(여러 디렉터리 교차) 핵심은 "속도와 범위"입니다. 사람의 정상 접근은 느리고 좁지만, 자동 수집은 빠르고 넓습니다. 2. 왜 중요한가 대량 읽기는 자동화된 데이터 수집(T1119)의 신호로, 유출 직전 단계입니다. 개별 접근은 정상일 수 있어도, 짧은 시간 대량·광범위 읽기는 명확한 이상입니다. 빈도(단위 시간당 open 수)와 범위(디렉터리 다양성)가 핵심 판정 기준입니다. 3. 핵심 명령어 / 설정 패턴 신호 위험 초당 수십 open 자동 수집 높음 find -exec cat 대량 읽기 높음 cp -r 대량 디렉터리 수집 높음 여러 디렉터리 교차 광범위 수집 높음 느린·좁은 접근 정상(사람) 정상 4. 실습 (실습 예시) # 대량 파일 읽기 탐지 (분석 방법) # 단위 시간당 open 수(주체별) sudo ausearch -k sensitive_read,data_access -i --start recent 2>/dev/null | grep -oE 'auid=[a-z0-9]+' | sort | uniq -c | sort -rn | head # 대량 읽기 명령(find -exec, cp -r) sudo ausearch -k data_access -i --start recent 2>/dev/null | grep -oE 'proctitle=.*(find.*-exec|cp -r|tar).*' | tail 5. 정상 상태 $ (주체별 open 수) 12 auid=mysqld-svc 4 auid=admin1 → 서비스·관리자의 소수 접근(정상 범위) 접근 빈도가 서비스·관리자의 소수(정상 기준선 내)에 머무는, 대량 읽기 패턴이 없는 상태가 정상입니다. 6. 이상 상태 $ (주체별 open 수) 480 auid=www-data (1분간 480 파일 open) $ (대량 읽기 명령) proctitle=find / -name '*.conf' -exec cat {} ; www-data가 1분에 480 파일 open → 자동 대량 수집(빈도 폭증) find -exec cat 로 전체 .conf 읽기 → 광범위 수집 빈도·범위가 기준선 대비 수십 배 → 정탐(자동 데이터 수집) 7. 로그 분석 (분석 방법) 대량 파일 읽기 흐름입니다(가상의 예시). [기준선] 분당 open ~10, 1~2 디렉터리 ↓ (비교) [관측] 분당 open 480, 10+ 디렉터리 교차 ↓ [판정] 빈도 48배·범위 광범위 → 자동 수집 ↓ [연계] 이후 tar 압축(수집)·전송(유출) 지표 정상 대량 수집 분당 open ~10 480 디렉터리 1~2 10+ 방법 단건 find/cp -r 빈도·범위의 급증이 자동 데이터 수집의 핵심 지표입니다. 8. SOC 관제 포인트 대량 파일 읽기는 빈도(단위 시간당 open)+범위(디렉터리 다양성) 로 판정합니다. 자동화된 데이터 수집(find -exec·cp -r·스크립트)이 핵심 패턴입니다. 개별 접근은 정상이어도 대량·광범위 읽기는 유출 직전 수집 신호입니다. 9. 탐지 규칙 <!-- 실습 예시 룰: 적용 전 wazuh-logtest 및 테스트 환경 검증 필요 --> <group name="local,syssec_e,data_access,"> <!-- 짧은 시간 대량 파일 접근(빈도 기반) --> <rule id="104200" level="12" frequency="100" timeframe="60"> <if_matched_sid>104000</if_matched_sid> <same_field>audit.auid</same_field> <description>동일 주체의 대량 파일 읽기(자동 데이터 수집)</description> <mitre><id>T1119</id><id>T1005</id></mitre> </rule> </group> frequency/timeframe 임계는 서비스 특성에 맞게 조정합니다. find -exec·cp -r 명령 패턴도 함께 탐지합니다. 10. 대응 방법 초기 확인 — 주체별 단위 시간당 파일 open 빈도와 접근 디렉터리 범위를 확인합니다. 범위 확인 — 자동 수집 명령(find -exec·cp -r)·기준선 대비 급증을 확인합니다. 증거 확보 — 대량 읽기 이벤트와 접근 파일 목록을 보존합니다. 차단/조치 — 자동 수집 정탐이면 세션 종료·이후 수집·유출 조사를 진행합니다. 재발 방지 — 빈도·범위 기반 대량 읽기 탐지를 운영합니다. 11. 핵심 정리 패턴 신호 초당 수십 open 자동 수집 find -exec cat 대량 읽기 cp -r 대량 디렉터리 수집 디렉터리 교차 광범위 면접 포인트 "대량 읽기는 빈도+범위로 판정 — 자동 수집은 빠르고 넓음" 12. 다음 편 예고 다음 편 222. 중요 정보 접근 — 민감 디렉터리 스캔성 접근 탐지 에서는 민감 디렉터리 스캔성 접근을 다루는 민감 디렉터리 스캔성 접근 탐지 를 다룹니다. 이전 편: 220. 중요 정보 접근 — 데이터베이스 덤프 생성 탐지 📚 시리즈 전체 보기: 시스템 보안 · 취약점
Where to Get Verified Stripe Accounts Online: A Complete Guide Introduction For anyone preparing to accept payments through the internet, Stripe can be an important part of an online payment setup. As a result, searches for verified Stripe accounts have become increasingly common. We’re Always Online — 24/7 Reply/Contact 📲▶ Telegram: @usanovapro 📞▶ WhatsApp: ▶+1(208) 402-6908 🌐Visit Now Link ; infousanovapro@gmail.com A quick search may reveal websites offering pre-verified profiles, aged accounts, ready-to-use accounts, or other shortcuts. At first glance, these offers may appear convenient. However, the important question is not simply whether an account has been labeled “verified.” The real question is whether that account legitimately belongs to the person or organization that intends to operate it. Stripe verification is designed to establish information about an account holder and the organization connected with an account. Depending on the location and account type, Stripe can request identity details, organization information, ownership details, address information, website details, and supporting documentation. For this reason, creating an account directly through Stripe is generally a more appropriate approach than purchasing credentials from an unknown source. This guide explains where legitimate Stripe account information can be found, how the verification process works, what to prepare before registration, and how to avoid common problems associated with third-party offers. Explanation of the Subject The expression “verified Stripe account” is often used loosely on the internet. A legitimate Stripe account goes through Stripe's own onboarding and verification procedures. The exact checks depend on factors such as location, organization type, and the information Stripe needs to confirm. Stripe may be able to verify some information automatically. In other situations, it can request additional documentation. This distinction is important because a third-party seller may advertise an account as “verified,” but that does not mean the account was created for the person who intends to use it. Official Stripe Registration The most appropriate source for a new Stripe account is the official Stripe platform. A user can begin the registration process, select the relevant location, enter accurate information, and follow the instructions displayed during onboarding. This provides a direct connection between the account holder and the profile being created. Stripe Help and Support Stripe's official Support Center is another valuable resource. It provides information about verification requirements, documentation, account configuration, website requirements, regional availability, and other topics. When requirements are unclear, checking official support information is preferable to relying on advice from an anonymous seller. Stripe Documentation Developers can also use Stripe's official documentation when integrating payment features into websites or applications. The documentation covers APIs, Checkout, Connect, webhooks, testing tools, and other technical resources. Using official documentation can help developers avoid outdated or inaccurate implementation advice. We’re Always Online — 24/7 Reply/Contact 📲▶ Telegram: @usanovapro 📞▶ WhatsApp: ▶+1(208) 402-6908 🌐Visit Now Link ; infousanovapro@gmail.com Key Points Choose the Original Source When looking for a verified Stripe account, start with Stripe rather than a marketplace or private seller. The official platform provides the actual registration and verification process. Prepare Before Registration Having the necessary information ready can make registration easier. Depending on the situation, users may need information relating to: Their identity Organization name Organization structure Physical address Website Products or services Ownership details Contact information The exact requirements can differ. Keep Everything Accurate Accuracy is one of the most important parts of the process. The information entered during registration should represent the actual person or organization that will operate the account. If additional documents are requested, those documents should correspond with the information already provided. Review Eligibility Not every type of activity is supported by Stripe. Before investing time in account setup, users should review Stripe's current prohibited and restricted categories. This is particularly important for organizations operating in specialized or regulated areas. Examples Example 1: A Small E-Commerce Website A website owner launches an online store and wants to add Stripe checkout. Instead of purchasing an existing profile, the owner registers directly with Stripe. The owner provides accurate details, adds the store website, describes the products, and completes any verification requests. This approach creates a clear relationship between the store and its Stripe profile. Example 2: A Content Creator A creator sells digital resources through a personal website. The creator opens a Stripe account using their own details and explains what customers receive after purchase. If Stripe asks for additional information, the creator responds through the official Stripe interface. There is no need to obtain an account previously created for somebody else. Example 3: A Software Company A software company wants to add Stripe Checkout to its application. The company first completes the appropriate Stripe onboarding process. Afterward, its development team uses Stripe's official documentation to integrate the required features. The technical integration and account verification are therefore handled through appropriate channels. Example 4: A Questionable Offer Suppose a website claims to sell “fully verified Stripe accounts” and says that the buyer only needs to change the profile details after purchase. This offer should be approached carefully. The original account may have been created using information belonging to another person or organization. Changing selected fields later does not necessarily establish legitimate ownership. Practical Applications Website Checkout Stripe can be integrated into websites to provide online checkout functionality where supported. Website owners can select the appropriate Stripe tools based on their technical requirements. We’re Always Online — 24/7 Reply/Contact 📲▶ Telegram: @usanovapro 📞▶ WhatsApp: ▶+1(208) 402-6908 🌐Visit Now Link ; infousanovapro@gmail.com Digital Services Creators and professional service providers can use approved Stripe features to support online payment collection. The website should clearly explain the services offered and provide accurate contact information. Online Applications Developers can integrate Stripe into web applications using official APIs. This can allow applications to create customized checkout experiences and manage customer-related payment functionality. Marketplace Platforms Organizations building platforms may use Stripe Connect where applicable. Connect provides tools designed for platform-based payment flows, but implementation requirements can vary according to the platform model. International Websites Organizations serving customers across different regions should review Stripe's availability and country-specific requirements. A feature available in one region may not be available in another. Checking current information before development can prevent unnecessary changes later. Common Mistakes Buying an Account From an Unknown Seller A third-party seller may promise a ready-made profile, but there may be no reliable way to determine how the account was originally created. The official registration route avoids this uncertainty. Assuming Older Accounts Are Better Some advertisements emphasize account age as if an older profile automatically provides an advantage. Age alone does not establish whether an account is suitable for a particular operator. Ignoring Verification Requests If Stripe requests additional information, ignoring the request can create problems. Users should review their Dashboard and follow the instructions provided by Stripe. Providing Conflicting Information Differences between registration information and supporting documents can lead to additional checks. Before submitting anything, users should review names, addresses, organization details, and other relevant fields carefully. Using an Inaccurate Website A website associated with an account should accurately represent what the organization offers. A website with little information or content that conflicts with the account description can create unnecessary questions. Sharing Credentials With Strangers Users should not casually provide Stripe login details to people offering unofficial verification services. If assistance is needed, official Stripe support should be the first option. Key Takeaways The main lessons from this guide are simple: Begin with the official Stripe website. Use accurate information throughout registration. Prepare relevant documentation before starting. Check whether your location and activity are supported. Review Stripe's current restricted-category rules. Use the official Dashboard for verification requests. Consult Stripe Support when requirements are unclear. Use official developer documentation for technical integrations. Treat “pre-verified” third-party accounts with caution. Never assume that an account created for another person can simply become yours. Conclusion Finding a verified Stripe account online is not necessarily about locating a seller offering a ready-made profile. The more important objective is establishing an account that genuinely represents the person or organization operating it. We’re Always Online — 24/7 Reply/Contact 📲▶ Telegram: @usanovapro 📞▶ WhatsApp: ▶+1(208) 402-6908 🌐Visit Now Link ; infousanovapro@gmail.com
시스템 보안 · 취약점 › E. 중요 정보 접근 로그 분석 · 25/50편 (전체 225/450) 학습 단계: DB·대량 데이터 접근 이상 실습 표기: 이 글의 명령어·출력·로그는 로컬 VMware 테스트 VM(Rocky Linux 9 / Ubuntu 22.04) 기준의 「실습 예시」 이며, IP·계정·호스트명은 가상의 값입니다. 선행 학습 224. 중요 정보 접근 — 민감 테이블·컬럼 접근 탐지 207. 접근 vs 유출 — 공격 단계의 구분 1. 개념 공격자는 여러 소스에서 수집한 데이터를 한 곳(staging 디렉터리)에 모은 뒤 압축·유출합니다. staging은 접근(E09 24)과 유출(E32 )을 잇는 중간 단계로, 여기서 차단하면 유출을 막을 수 있습니다. 데이터 staging 패턴 집결 위치: /tmp, /dev/shm, /var/tmp, 숨김 디렉터리 모으기: cp 여러 파일 → /tmp/.stage/ 압축: tar czf /tmp/data.tgz /tmp/.stage/ 분할: split -b 10M (크기 제한 우회, E36) 특징: 평소 비어있는 경로에 다양한 소스 파일 집결 staging 디렉터리는 평소 비어있는 임시 경로(/tmp·/dev/shm)에 다양한 소스의 파일이 모이는 것이 특징입니다. 2. 왜 중요한가 staging은 접근과 유출 사이의 차단 기회로, 여기서 막으면 유출을 방지합니다. 여러 소스(설정·DB·홈)의 파일이 한 임시 경로에 모이는 것이 수집의 명확한 신호입니다. 압축·분할은 유출 준비(전송 효율·크기 제한 우회)의 직접 전조입니다. 3. 핵심 명령어 / 설정 staging 신호 의미 위험 임시 경로 파일 집결 데이터 수집 높음 다양한 소스 복사 광범위 수집 높음 tar/zip 압축 유출 준비 높음 split 분할 크기 제한 우회 높음 숨김 디렉터리 은닉 높음 4. 실습 (실습 예시) # 데이터 staging 탐지 (분석 방법) # 임시 경로로의 다중 복사(집결) sudo ausearch -k data_access,exfil -i --start recent 2>/dev/null | grep -E '/tmp/|/dev/shm/|/var/tmp/' | grep 'comm="cp"' | tail # staging 디렉터리의 압축·분할 sudo ausearch -k exfil -i --start recent 2>/dev/null | grep -E 'comm="(tar|gzip|zip|split)"' | grep -E '/tmp/|/dev/shm/' # 현재 임시 경로의 아카이브 find /tmp /dev/shm /var/tmp -type f \( -name '*.tar*' -o -name '*.zip' -o -name '*.gz' \) 2>/dev/null 5. 정상 상태 $ (임시 경로 집결) (없음) $ (압축·분할) (없음) $ (임시 아카이브) (없음) 임시 경로에 데이터 집결·압축·아카이브가 없는, staging 활동이 없는 상태가 정상입니다. 6. 이상 상태 $ (임시 경로 집결) 04:00 cp /etc/shadow /tmp/.s/ 04:00 cp database.yml /tmp/.s/ 04:01 cp -r /home/alice/docs /tmp/.s/ $ (압축·분할) 04:02 tar czf /tmp/.s/all.tgz /tmp/.s/ 04:03 split -b 10M all.tgz shadow·DB 설정·문서를 /tmp/.s/에 집결 → 다양한 소스 수집 tar 압축 + split 분할 → 유출 준비(크기 제한 우회) 임시 경로 집결·압축·분할 → staging 완성 → 정탐(유출 임박) 7. 로그 분석 (분석 방법) 데이터 staging 흐름입니다(가상의 예시 로그). [집결] cp 여러 소스 → /tmp/.s/ (shadow·DB·문서) ↓ [압축] tar czf /tmp/.s/all.tgz (단일 파일화) ↓ [분할] split -b 10M (전송·크기 제한 우회, E36) ↓ [유출] 외부 전송(E32) — staging에서 차단하면 방지 단계 흔적 집결 임시 경로 다중 cp 압축 tar/zip 분할 split 유출 전송 staging(집결·압축) 탐지 시점이 유출 전 마지막 차단 기회입니다. 8. SOC 관제 포인트 staging은 수집한 데이터를 한 임시 경로에 집결·압축 하는 유출 직전 단계입니다. 다양한 소스 파일 집결·tar 압축·split 분할이 핵심 신호입니다. staging 탐지가 유출 전 마지막 차단 기회이므로 즉시 대응합니다. 9. 탐지 규칙 <!-- 실습 예시 룰: 적용 전 wazuh-logtest 및 테스트 환경 검증 필요 --> <group name="local,syssec_e,data_staging,"> <!-- 임시 경로에 중요 정보 접근 후 압축(staging) --> <rule id="104240" level="12"> <if_sid>104000</if_sid> <field name="audit.comm" type="pcre2">^(tar|gzip|zip|7z|split)$</field> <field name="audit.proctitle" type="pcre2">(/tmp/|/dev/shm/|/var/tmp/)</field> <description>임시 경로 데이터 집결·압축(staging — 유출 준비)</description> <mitre><id>T1074.001</id><id>T1560.001</id></mitre> </rule> </group> 접근(E09~24) → staging(여기) → 유출(E32)을 세션 상관해 공격 진행을 포착합니다. staging에서 차단이 최선입니다. 10. 대응 방법 초기 확인 — 임시 경로로의 파일 집결·소스 다양성·압축·분할을 확인합니다. 범위 확인 — 직전 접근(E09~24)·직후 유출(E32)과의 세션 연계를 확인합니다. 증거 확보 — staging 디렉터리 내용·집결·압축 이벤트를 보존합니다. 차단/조치 — 유출 전 차단(staging 삭제·세션 종료·전송 차단)을 진행합니다. 재발 방지 — staging 탐지를 유출 전 차단 지점으로 운영합니다. 11. 핵심 정리 staging 신호 의미 임시 경로 집결 데이터 수집 다양한 소스 복사 광범위 수집 tar/zip 압축 유출 준비 split 분할 크기 제한 우회 면접 포인트 "staging은 유출 전 마지막 차단 기회 — 임시 경로 집결·압축이 신호" 12. 다음 편 예고 다음 편 226. 중요 정보 접근 — 비정상 시간대·주체의 데이터 접근 탐지 에서는 비정상 시간대·주체의 접근을 다루는 비정상 시간대·주체의 데이터 접근 탐지 를 다룹니다. 이전 편: 224. 중요 정보 접근 — 민감 테이블·컬럼 접근 탐지 📚 시리즈 전체 보기: 시스템 보안 · 취약점