우리 웹사이트에는 몇몇 크롤러가 있습니다. 이들이 콘텐츠에 접근할 위험은 있을까요?
경험이 거의 없다면, 차단 조치를 취해야 할 만큼 허용 가능한 크롤러 부하/위험 수준은 어느 정도인가요?
이들은 공개된 웹사이트만 크롤링할 수 있으므로 보안 침해는 아닙니다. 하지만 공개된 콘텐츠에 접근할 수는 있습니다.
부하가 너무 높아 부정적인 영향을 미칠 때는 더 많은 CPU와/또는 RAM을 구매해야 합니다. 솔직히 Discourse에서는 그런 상황이 얼마나 쉽게 발생할지 모르겠습니다. 해결 방법이 다르기 때문이죠. 하지만 PHP 기반의 WordPress는 무릎 꿇게(과부하로 멈추게) 만드는 것이 꽤 쉽습니다. Discourse는 누가 인간이고 누가 아닌가를 구별할 수 있다면 봇에게 정적이고 가벼운 콘텐츠를 제공합니다. 만약 봇이 매우 잘못된 사용자 에이전트를 사용한다면… 어떤 결과를 얻을까요? JSON으로 된 대량의 텍스트일까요?
만약 봇이 로그인, 신뢰 수준 장벽 등을 통과해 들어온다면, 팀은 패닉 모드로 전환되고 모든 사람이 즉시 업무에 복귀해야 할 것이라 짐작합니다 
또한 관리자 설정을 통해 크롤러를 쉽게 차단할 수 있다는 점도 참고하세요.
그렇게 알고 싶을 정도로 감사할 것 같습니다…
그것이 단순히 robots.txt를 편집하는 것만은 아니기를 바랍니다. robots.txt는 규칙을 잘 지키는 봇에만 효과가 있기 때문입니다. 실제로는 효과적이지만 다소 복잡한 해결책이 하나 있습니다. 바로 리버스 프록시입니다.
이 접근 방식은 효과적입니다 – 우리도 직접 사용하며, 저희 호스팅을 이용하는 고객분들에게도 권장합니다.
Discourse가 필터링을 사용한다는 것을 읽어야 하나요?
무엇을 물어보시는지 정확히 모르겠어요. 기본적으로 아무것도 차단하지 않지만, 관리자가 선택적으로 관리할 수 있도록 도구를 제공합니다.
즉, 봇이 a) robots.txt를 읽고 b) 규칙을 따를 것이라고 신뢰하고 계신 거죠. 하지만 문제를 일으키는 봇들은 이 두 가지 중 어느 것도 하지 않습니다. 결국 처음으로 돌아가게 되는데, 봇이 어떤 형태로든 문제가 된다면 리버스 프록시가 최선의 해결책입니다.
감사합니다. 그걸 알고 싶었네요.
아, 무슨 말인지 알겠어요. 아니요, 모든 봇이 크롤러로 자신을 식별하거나 규칙을 따를 것이라고 가정하지는 않아요. 분명히 부정확한 부분이 있는 문제입니다. 저는 단순히 OP에게 첫 단계의 완화 방안을 제시한 것뿐이에요.
현재 우리는 트래픽을 더 구체적으로 제한하는 방법을 연구 중이지만, 쉬운 작업은 아닙니다.
디스코urs 호스팅 사이트의 크롤러 수가 Digital Ocean 서버 사이트보다 훨씬 낮다는 것을 알게 되었습니다. 두 사이트 모두 기본 관리자 설정을 사용하고 있습니다.
호스팅 사이트는 하루에 크롤러가 10개 미만인 경우가 많으며, 평균 약 4개입니다. 가끔 스파이크가 발생하기도 하는데, 최근 1월 마지막 날에는 하루 동안 77개의 크롤러가 기록되었습니다.
거의 활동이 없는 Digital Ocean 사이트는 하루 평균 약 30개의 크롤러가 있습니다. 서버 종류나 도메인 때문에 크롤러가 더 많은 이유가 무엇인지, 그리고 이것이 중요한지 잘 모르겠습니다.
이것들은 일반적으로 검색 엔진이 사이트를 찾을 수 있도록 공개 사이트와 콘텐츠를 검색/인덱싱하는 것입니다. 더 넓은 독자층을 대상으로 하기를 원한다면, 디스코urs 사이트에서 논의되고 있는 주제에 대해 검색을 실행하는 사람들이 사이트를 찾을 수 있으므로 사이트에는 좋은 일이 될 수 있습니다.
크롤러에는 다른 목적도 있을 수 있으며, 모든 용도를 정확히 알지는 못합니다. 이 크롤러들은 기본적으로 설정에서 접근이 거부되며, 이미 알고 계실 가능성이 높습니다:
컴퓨터에 대해 상대적으로 문외한이라, 크롤링에 관한 여러분의 전문적인 의견을 마치 US 오픈 테니스 대회 결승전을 관람하는 장애인 관중처럼 지켜보고 있었습니다. 사이트 보안이라는 이 난해한 부분을 소개해 주셔서 감사합니다.
Discourse가 효율적으로 호스팅해 주는 우리 포럼은 매우 기밀성이 높은 곳입니다. 초대받아 가입한 사용자들은 기밀 유지에 대해 매우 불안해하며, 저는 최대한 그들을 안심시키려 노력하고 있습니다. 크롤러가 그렇게 해롭지는 않을 수도 있지만(?!), 가능하면 완전히 차단하고 싶습니다. 우리의 콘텐츠가 인덱싱되거나 어떤 방식으로든 알려지는 데 전혀 관심이 없기 때문입니다.
이제 설정 최적화가 먼저 해야 할 일임을 깨달았습니다. 해당 사항으로 Communitech 지원 그룹 중 한 명이 제 설정을 검토해 줄 수 있을까요?
관심 가져 주셔서 감사합니다.
좋네요, 그건 반가운 소식입니다. 저는 Discourse가 최근에 렌더링된 콘텐츠를 더 빠르게 서빙하기 위해 Redis에만 의존하는 줄 알았거든요. 말씀하신 대로, 제 포럼이 Drupal로 구동될 때 나쁜 봇들, 때로는 검색 엔진 크롤러조차 간혹 서버를 무너뜨리곤 했었습니다. 하지만 저는 익명으로 접근된 페이지의 정적 HTML 파일 캐시를 생성하고, 이를 위해 Nginx 재작성 규칙을 자동으로 생성하는 플러그인을 설치했습니다. Nginx는 Drupal PHP 코드를 부트스트랩하지 않고도 해당 파일을 서빙했고, 그 속도는 정말 빨랐으며 익명 트래픽 부하를 훨씬 더 많이 처리할 수 있었습니다.
안녕하세요. 이 부분은 보안에 아무런 영향을 미치지 않는다는 점을 꼭 알아두시기 바랍니다. 크롤러는 공개된 사이트에만 접근할 수 있습니다. 로그인 후에만 접근할 수 있는 사이트인 경우 크롤러는 접근할 수 없습니다.
또 하나 명확히 할 점은, Communiteq는 저희와 어떠한 관련도 없다는 것입니다. 따라서 만약 Communiteq가 호스팅 제공업체라면, 당신은 Discourse에 의해 호스팅되는 것이 아닙니다. 
개인적으로 답변하려 했지만, 다른 분들에게도 도움이 될 수 있을 것 같아 여기에 게시합니다.
이들은 여러분의 홈(로그인) 페이지에만 접근하며 콘텐츠에는 접근할 수 없습니다.
해로울 수 있습니다. 크롤러의 종류에 따라 원하지 않는 정보가 공개되게 만들 수 있습니다. 기술적으로 말하면, 크롤러는 공개된 정보에만 접근할 수 있지만, 크롤러(그리고 관련 검색 엔진)는 정보를 발견하고 이를 접근 가능하게 만드는 데 매우 뛰어납니다.
자, 여러분의 상황을 살펴보겠습니다.
여러분의 robots.txt에는 다음과 같이 설정되어 있습니다.
User-agent: *
Disallow: /
즉, 모든 검색 엔진 크롤러의 접근을 거부하도록 설정되어 있습니다. 
그러나 이것만으로는 충분하지 않습니다. robots.txt는 예의에 기반하고 있으며 “악성” 로봇은 이를 준수하지 않기 때문입니다. 악성 로봇은 단순히 robots.txt를 무시할 수 있습니다. 이는 “출입 금지!” 표지판과 같습니다 - 도둑은 이를 준수하지 않을 테니까요.
여러분 포럼의 주요 보안은 로그인 필요가 활성화되어 있다는 사실에 기반합니다. 이는 모든 크롤러를 차단하는 데 충분합니다.
크롤러가 들어올 수 없다는 것이 이미 확인되었지만, 한 단계 더 나아가는 것이 좋을 수도 있습니다.
여러분은 초대 전용과 새로운 가입 허용이 활성화되어 있고, 초대 허용 그룹이 TL2로 설정되어 있습니다. 이는 임의의 사람이 가입할 수 없음을 의미하지만, TL2 이상의 모든 사용자는 커뮤니티에 다른 사용자를 초대할 수 있습니다. 안전장치로 사용자 승인 필요를 활성화해 두셨으니 좋습니다. 여러분의 커뮤니티에 접근할 수 있는 유일한 방법은 이미 커뮤니티의 신뢰할 수 있는 멤버인 누군가에게 초대를 받는 것, 그리고 관리자가 여러분을 들여보내 주는 것입니다.