AI 시대 대비
이 태그가 달린 문서 13건
Linux 커널 CVE-2026-98432: 네트워크로 유발되는 TCP use-after-free(CVSS 9.8). 수정된 커널을 설치하고 재부팅하며 MPTCP도 확인하세요
CVE-2026-98432는 2026년 10월 15일에 공개된 Linux 커널 IPv4 TCP 코드의 use-after-free입니다. 커널 프로젝트의 CNA는 CVSS v3.1 9.8(네트워크, 권한 불필요, 사용자 조작 불필요)로 평가했습니다. 한 AI 기업의 연구자들이 자체 보고에서, 실험실 환경에서 Multipath TCP(MPTCP) 리스너가 있는 서버에 대해 root 권한의 원격 코드 실행을 시연했다고 알려졌습니다. BleepingComputer는 일반 TCP 서버에 대한 원격 코드 실행은 공개적으로 시연되지 않았고 실제 악용도 확인되지 않았다고 전하며, 이 사이트는 11월 1일에 이 CVE가 CISA의 KEV 카탈로그에 없음을 확인했습니다. 업스트림 수정은 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10 이후에 들어 있습니다. 11월 1일 기준 Debian은 수정된 커널이 있고, SUSE는 일부가 있으며, Ubuntu와 Red Hat은 수정을 진행 중으로 표시합니다. MPTCP를 끄는 것만으로는 완전한 수정이 아닙니다. 이 사이트의 결론: 인터넷에 노출된 Linux 서버는 수정이 나오는 대로 업데이트하고 재부팅하며, 그때까지만 업체의 임시 완화책을 쓰세요.
AI 시대의 보안: 지금 다잡아야 할 기본기 (우선순위 체크리스트)
AI는 새로운 약점을 만들기보다 기존 약점(패치 안 된 CVE, 재사용된 비밀번호, 노출된 시크릿)에 대한 공격을 주로 증폭한다 — 자동으로, 빠르게, 대규모로 찾아내며. 따라서 가장 좋은 대비는 기본기를 올바른 순서로 다잡는 것이다: CVE 패치 + 의존성 모니터링, 비밀번호 재사용 중지 + MFA, 노출 시크릿 제거, 최소 권한, 공개 표면 축소, 로그/IOC, 백업.
AI 시대에 효과가 있는 보안 대책과 없는 대책: 작은 사이트도 노려지는 이유
AI 시대의 네 가지 오해를 바로잡는다: (1) 너무 작아서 표적이 안 된다 → 자동화된 공격은 사람이 표적을 고를 필요가 없다; (2) 특별한 새 통제가 필요하다 → 여전히 기본기가 가장 효과적이다; (3) 제품이 안전하게 해준다 → 탐지보다 예방 설계가 먼저; (4) AI 코드는 빠르니 안전하다 → 취약점을 포함한 채 출시될 수 있으니 공개 전 검토. 통하는 것은 올바른 순서의 지루한 기본기다.
자기 도메인을 사칭한 이메일 스푸핑: 침해와 구분하는 법, 그리고 SPF·DKIM·DMARC로 막는 법
자기 도메인에서 온 것처럼 보이는 수상한 메일은 보통 침해가 아니라 From 위조다 — SMTP가 누구나 From 줄을 쓰게 허용하기 때문. 헤더(Authentication-Results, Received, Reply-To)를 읽으면 침해와 위조를 구분할 수 있다. 받은편지함에 도달하는 주된 이유는 DMARC 정책 부재. SPF → DKIM → DMARC(p=none → reject) 순서로 고친다.
백업의 핵심: 3-2-1 규칙과 랜섬웨어를 견디는 복구 계획
'백업이 있다'로는 부족하다 — 복원할 수 있음을 검증한 백업만이 쓸모가 있다. 기본: 3-2-1 규칙(사본 3개, 매체 2종, 한 부는 외부). 랜섬웨어에는 '오프라인 또는 불변' 사본이 최소 하나 더 필요하다 — 늘 연결된 백업은 원본과 함께 암호화된다. 클라우드 동기화는 백업이 아니다(삭제와 암호화까지 복제한다). 버전 관리와 주기적 복원 테스트가 실천을 완성한다.
MFA를 제대로 고르기: '피싱 저항'이 무엇이고, SMS가 왜 약한가
MFA는 서로 다른 종류의 요소를 결합한다. 직접 입력하는 코드는 피싱으로 중계될 수 있고 SMS는 전화번호의 통제에도 의존한다. 중요한 계정에는 패스키나 FIDO2 보안 키 같은 피싱 저항 방식을 우선하고, 사용자 확인 요구와 복구 방법도 점검한다.
의존성 CVE를 제대로 고치기: 스캔, 수정, 격리, 그리고 계속 감시
취약점 작업은 '고쳤다'고 끝나는 게 아니다. 완료 = 1) 스캔, 2) 수정, 3) 격리/인계, 4) 모니터링. 모니터링(매일 변화 탐지)이 갖춰지기 전까지는 미완이다 — 의존성은 내일 다시 취약해진다. 다음 배포가 덮어쓰는 완벽한 수정은 가치가 0이다. 소규모 팀은 두 규율로 안전을 지킨다: 자동 변화 탐지와 '로컬→push→배포'.
osv-scanner 설치와 사용법: 의존성의 CVE를 자동으로 찾아내기
osv-scanner는 락파일과 컨테이너를 스캔해 의존성의 CVE를 무료로 드러냅니다. 설치·실행·CI 연동을 짚고, npm/pnpm audit·Dependabot과 언제 쓸지도 비교합니다. 본 사이트의 견해: 어떤 도구가 맞는지는 당신의 환경에 달려 있습니다. 다중 생태계나 GitHub 비사용 프로젝트엔 osv-scanner를, 단일 npm 트리엔 번들된 pnpm audit을 쓰세요.
비밀번호 관리자는 안전한가? 작동 원리, 클라우드 vs 로컬, 선택법
비밀번호 관리자는 서비스마다 강력하고 서로 다른 비밀번호를 쓰도록 돕는 도구입니다. 제로 지식 암호화는 제공자에서 암호화된 데이터가 유출되더라도 내용을 보호하기 위한 설계이지만, 안전성은 마스터 비밀번호 강도, 암호화 설정, 기기 보안에도 달려 있습니다. MFA로 무단 로그인을 방지하고 용도에 따라 클라우드나 로컬을 고르세요.
공개 디렉터리에 시크릿 파일을 남겨두지 않았나요? 웹루트를 점검하라
웹루트의 모든 것은 누구나 URL로 가져갈 수 있습니다. 남겨진 토큰/자격증명 JSON, .env, 백업은 즉각 노출을 뜻하며 — 공유 템플릿에서 왔다면 모든 사이트가 같은 파일을 갖습니다. 해법: 공개 디렉터리엔 공개해도 되는 것만, 시크릿은 웹루트 밖에 권한 600으로, 하나 찾으면 모든 사이트와 호스트를 점검하기.
1인 개발자와 소규모 운영자를 위한 보안 베이스라인: 표준 통제를 우선순위 순으로
베이스라인은 '모두 똑같이 중요'가 아닙니다. 본 사이트의 우선순위: 1) 관리자 계정·도메인·이메일(MFA), 2) 시크릿과 코드, 3) 앱 자체, 4) 패치·탐지·복구. 시간이 유한할 때 위에서부터 채우세요. 심각한 침해는 대부분 새로운 공격이 아니라 이 기본 통제의 빈틈에서 옵니다.
SSH 키 최소 권한: 침해될 수 있는 임시 환경에 프로덕션 루트 키를 두지 마라
임시·침해 가능한 환경(GPU 파드, CI 러너, 일회용 VM)에서 프로덕션에 루트 키를 등록한다는 것은, 그 환경이 침해되는 순간 공격자가 프로덕션의 루트 권한을 얻는다는 뜻입니다. 해법: 임시 환경에 루트 키 금지; 미사용 시 키 제거; 다시 필요하면 비루트 사용자 + 키를 한 작업으로 제한하는 명령 제한 키. 재사용 키를 가장 중요한 자산으로 다루고, 키 하나가 새면 모든 서버가 열리는 구조를 절대 만들지 마세요.
AI가 작성한 코드에서 API 키가 유출돼 부정 과금에 쓰였다: 원인은 패치되지 않은 CVSS 10.0 취약점
요금 급증은 증상이었다. 원인은 패치되지 않은 공개 CVSS 10.0 RCE였다. 익명화한 사례를 방어 교훈으로 정리한다.