<div id="readability-page-1" class="page"><div id="bo_v_con">
		<p>관리하는 서버 중 한 대의 하루 전송량은 평소 약 12GB였다. 그런데 이날은 24GB를 넘었다. 로그를 따라가 보니 9월 26일 이후 들어오기 시작한 봇 세 개가 증가분 대부분을 차지했다.</p>
<p>게시글까지 막을 생각은 없었다. 세 봇이 받아 가는 무거운 이미지만 막으면 됐다. Apache에서 이미지 폴더를 기준으로 차단한 과정과 확인할 점을 적어 둔다.</p>
<h3>로그에서 이미지 전송량이 늘어난 원인을 찾았다</h3>
<p>GPTBot은 이날 이미지 4.95GB를 받아 갔다. Amazonbot은 3.31GB, AhrefsBot은 2.87GB였다. 세 봇이 요청한 게시판 본문 이미지는 모두 15,596개 파일에 걸쳐 있었다.</p>
<p>파일 중에는 10~23MB짜리 GIF도 여러 개 있었다. 이런 파일을 반복해서 내보내면 전송량이 빠르게 늘어난다. 이 수준이 이어지면 Lightsail의 월 전송 한도를 넘거나 서버가 느려질 수 있었다.</p>
<p>이 이미지 수집은 방문자나 검색 노출에 도움이 되지 않는다고 판단했다. 그래서 세 봇의 게시판 이미지 요청만 차단하기로 했다.</p>
<h3>User-Agent가 일치하면 이미지 접근을 거절했다</h3>
<p>봇은 요청 헤더의 User-Agent에 자기 이름을 넣는다. GPTBot 요청에는 다음처럼 이름과 버전이 들어 있었다.</p>
<pre><code>Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; GPTBot/1.4; +https://openai.com/gptbot)</code></pre>
<p>Apache 설정 파일을 하나 만들었다. 아래 경로는 실제 서버 경로 대신 예시로 바꾼 것이다. 다른 서버에 적용한다면 이미지가 저장된 실제 경로를 넣어야 한다.</p>
<pre><code># /etc/httpd/conf.d/bot-block.conf
&lt;Directory "/var/www/example/forum/data"&gt;
    &lt;If "%{HTTP_USER_AGENT} =~ /GPTBot|Amazonbot|AhrefsBot/"&gt;
        Require all denied
    &lt;/If&gt;
&lt;/Directory&gt;</code></pre>
<p>User-Agent에 세 이름 중 하나가 들어 있으면 403을 돌려준다. 접근 권한 검사가 파일 전송보다 먼저 실행되므로 이미지 본문은 나가지 않는다. 20MB GIF 요청도 작은 403 응답으로 끝난다.</p>
<h3>여러 도메인이 공유하는 폴더에 규칙을 걸었다</h3>
<p>이 서버에서는 도메인 네 개가 같은 게시판 이미지 폴더를 쓴다. 도메인별 가상 호스트 설정에 규칙을 넣으면 네 곳을 각각 관리해야 한다. 한 곳을 빠뜨릴 가능성도 있다.</p>
<p>Apache의 Directory 설정은 요청에 사용한 도메인이 아니라 실제 파일 위치를 기준으로 적용된다. 공유 폴더에 규칙 하나를 두면 네 도메인으로 들어오는 해당 이미지 요청을 함께 막을 수 있다.</p>
<p>설정은 별도 파일로 뒀다. 나중에 규칙을 살피거나 되돌릴 때 해당 파일 하나를 찾으면 된다.</p>
<h3>캐시가 권한 검사를 건너뛰지 않는지 확인했다</h3>
<p>이 서버는 mod_cache로 이미지를 캐시한다. 캐시된 파일이 권한 검사보다 먼저 나가면 새 차단 규칙이 적용되지 않을 수 있다. 적용 전에 캐시 설정을 확인했다.</p>
<pre><code>CacheQuickHandler Off</code></pre>
<p>이 설정에서는 권한 검사가 캐시 응답보다 먼저 실행된다. 같은 규칙을 다른 서버에 옮길 때도 캐시 설정을 확인해야 한다. 설정이 다르면 봇 요청에 403 대신 이미지가 나갈 수 있다.</p>
<p>이미지 폴더 안에는 PHP 실행 파일을 막는 설정도 있었다. 새 규칙이 기존 설정과 충돌하지 않는지도 확인했다.</p>
<pre><code>forum/data/.htaccess</code></pre>
<h3>설정을 다시 읽힌 뒤 응답 코드를 비교했다</h3>
<p>먼저 Apache 설정 문법을 검사했다. 오류가 없다는 것을 확인한 뒤 서비스를 재시작하지 않고 설정만 다시 읽혔다.</p>
<pre><code>apachectl -t
systemctl reload httpd</code></pre>
<p>이어서 curl에서 User-Agent를 바꿔 이미지 요청을 보냈다. GPTBot, Amazonbot, AhrefsBot 요청은 403이었다. Googlebot과 일반 브라우저 요청은 200이었다.</p>
<p>직접 만든 요청만으로 확인을 끝내지 않았다. 실제 접근 로그에서도 세 봇의 이미지 요청이 403을 받는지 확인했다.</p>
<h3>게시글과 일반 방문자의 이미지 접근은 유지했다</h3>
<p>이번 규칙은 게시판 이미지 폴더에만 걸었다. 세 봇은 게시글 페이지를 계속 읽을 수 있다. 글 내용의 AI 검색·답변 노출은 유지하고 무거운 이미지 전송만 막은 셈이다.</p>
<p>Googlebot과 Bingbot도 차단 대상에 넣지 않았다. 일반 방문자의 이미지 요청 역시 그대로 처리된다. 검색과 방문자 이용에 필요한 경로는 유지하려는 판단이었다.</p>
<p>만약 특정 도메인에서만 이미지가 계속 내려온다면 실제 파일 경로를 확인해야 한다. 도메인들이 서로 다른 폴더를 쓰는 환경에서는 이번처럼 규칙 하나로 모두 처리되지 않는다.</p>
<h3>요청이 계속 들어오면 추가 차단 범위를 판단해야 한다</h3>
<p>User-Agent는 요청을 보내는 쪽에서 바꿀 수 있다. 브라우저인 척하는 수집기는 이번 규칙으로 걸러지지 않는다. 그런 요청이 늘면 IP 대역이나 Cloudflare 규칙을 검토해야 한다.</p>
<p>403으로 응답해도 봇의 요청 자체는 계속 들어올 수 있다. 요청 수까지 줄이려면 robots.txt에서 세 봇의 이미지 경로 접근을 따로 제한할 수 있다. 다른 검색 봇의 이미지 접근까지 막지 않도록 대상을 지정해야 하며, 이번에는 적용하지 않았다.</p>
<p>GPTBot의 게시판 목록 크롤링도 이번 작업 범위 밖이다. 그 요청은 하루 약 1.6GB를 쓰고 CPU 부하도 만든다. 우선 전송량이 큰 이미지 요청을 막았고, 목록 요청은 별도로 살펴볼 문제로 남겨 뒀다.</p>	</div></div>

길호넷

관리하는 서버 중 한 대의 하루 전송량은 평소 약 12GB였다. 그런데 이날은 24GB를 넘었다. 로그를 따라가 보니 9월 26일 이후 들어오기 시작한 봇 세 개가 증가분 대부분을 차지했다. 게시글까지 막을 생각은 없었다. 세 봇이 받아 가는 무거운 이미지만 막으면 됐다.…

Apache에서 GPTBot·Amazonbot·AhrefsBot의 게시판 이미지 요청 막기

댓글