서버 로그를 보다 보니 사람이 정상적으로 접속한 게 아닌, 악의적인 목적으로 접근하는 봇 요청 로그들이 계속 보이기 시작했습니다. .env, .config, .yaml 같은 민감한 파일들을 무작위로 읽어보려는 시도 바로 흔히 말하는 스캐닝봇(Scanning Bot) 이죠. 제 서버는 실제로 읽힐 파일이 없도록 이미 설정은 되어 있었지만, 그래도 로그에 계속 남고 찜찜해서 간단하게 차단하는 방법을 시연해봤습니다. 복잡한 보안 설계가 아니라 👉 기본 기능만으로 할 수 있는 방어 방법 위주입니다. 🎯 영상에서 다루는 내용 1️⃣ nginx 설정을 통한 스캐닝봇 1차 방어 .env, .conf, .yaml, .log, .bak 등 민감한 확장자 파일 접근 차단 nginx 전용 상태코드 444 사용 → 아예 응답을 보내지 않아 재시도 자체를 막는 방식 /etc/nginx/snippets에 재사용 가능한 형태로 분리 2️⃣ AWS WAF를 이용한 서버 앞단 방어 CloudFront / ALB 앞단에 WAF 연동 정규식 패턴 세트를 이용한 민감 파일 접근 차단 AWS에서 제공하는 관리형 규칙 그룹(Managed Rule Groups) 활용 🛡️ 적용한 AWS 관리형 규칙 그룹 Amazon IP Reputation List → 이미 악성으로 알려진 IP 대역 차단 (스캐닝봇, DDoS, 스팸봇, 크롤러 등) Core Rule Set → SQL Injection, XSS, Path Traversal, Command Injection 방어 Known Bad Inputs → Log4j, 특정 플랫폼(Java, React 등)에서 실제로 크게 터졌던 공격 패턴 방어 또한 규칙 순서에 따른 성능 영향과 정상 요청인데 오탐이 날 수 있는 룰 (SizeRestrictions_BODY, XSS_BODY)에 대한 주의점도 함께 설명합니다. 💡 이런 분들께 도움이 됩니다 서버 로그에 정체 모를 접근 시도가 계속 보이는 분 nginx를 사용 중인 웹 서버 운영자 AWS WAF를 처음 실무에 적용해보려는 개발자 “보안 어디까지 해야 하지?” 고민 중인 분 🛠️ 사용 기술 - nginx - AWS WAF - CloudFront - Application Load Balancer (ALB) - 정규식 패턴 세트 - AWS 관리형 규칙 그룹 이 영상은 과도한 보안 설정보다는, 운영하면서 부담 없이 적용할 수 있는 기본 방어선에 초점을 맞췄습니다. 도움이 되셨다면 👍 좋아요 & 구독 부탁드립니다. 궁금한 점이나 다음에 다뤘으면 하는 주제는 댓글로 남겨주세요!