이상한 스팸 유저 공격을 경험하고 계신 분 계신가요? 차단 방법이 있을까요?

스팸 공격이 너무 만연해서 우리가 겪고 있는 일이 그저 일상적인 일일 수도 있습니다.

우리는 SSO를 사용하지만, 우리 사이트에만 제한적으로 적용됩니다. 외부 인증은 사용하지 않습니다.

패턴이 매우 명확합니다.

  • 그들은 항상 “성별” 필드에 대문자와 소문자가 섞인 랜덤 문자열을 입력합니다.
  • 사용자 이름은 거의 항상 실제처럼 보이는 이름과 성 뒤에 숫자 문자열이 붙어 있습니다.
  • 사용된 이메일은 항상 커스텀 도메인이며, 보통 매우 이례적인 형태입니다. 인기 있는 서비스는 절대 사용하지 않습니다.

우리는 스팸 필터 설정을 변경한 적이 없습니다. 하루에 3~4개, 일주일에 10개 이상 정도가 들어옵니다. 지금까지는 게시할 시간을 주지 않기 위해 그냥 삭제해 왔습니다.

어떤 생각이 있으신가요?

스팸 계정 탐지 방법에 대한 조언을 해주는 스태프의 말을 공유해 드립니다.

‘전형적인 “FirstLast1234” 형식의 이메일 주소’

전형적인 스팸 계정 수법입니다.

아마 그거 때문에 AI가 혼란을 겪는 건가요?

그럴 수도 있겠네요. 어쨌든 AI가 그런 혼란을 겪는다는 사실이 반갑습니다. 성별에 관한 질문에 대해 다음으로合乎邏輯적인 답을 모를 AI 기반 봇이라니, 믿기 어렵거든요.

네, 저도 같은 문제를 겪었는데요, TL0 사용자의 게시물을 수동으로 승인하도록 변경한 이후로 해결되었습니다.

저는 가입하는 사용자가 자신의 운영체제를 선택할 수 있는 사용자 정의 필드를 운영하고 있습니다(저희 커뮤니티는 특정 앱에 관한 것입니다). 그런데 이 봇 계정들은 해당 필드에 무작위 데이터가 입력되어 있었습니다.

저는 사용자 정의 Data Explorer 쿼리를 사용하여 유효하지 않은 운영체제 값, 즉 사용자 정의 사용자 필드의 사전 정의된 옵션 목록에 포함되지 않은 값을 가진 모든 사용자를 나열했습니다.

SELECT 
  u.id, 
  u.username, 
  ucf.value AS user_field_1 
FROM 
  users AS u 
  LEFT JOIN user_custom_fields AS ucf ON u.id = ucf.user_id 
  AND ucf.name = 'user_field_1' 
WHERE 
  ucf.value IS NOT NULL 
  AND ucf.value NOT IN (
    SELECT 
      ufo.value 
    FROM 
      user_field_options AS ufo 
    WHERE 
      ufo.user_field_id = 1
  )

새로운 가입자가 멈춘 건가요? 그게 바로 제 "문제"거든요. 실제로 저희는 이미 TL0 사용자의 게시물을 수동으로 승인하고 있습니다.

네, 멈췄습니다. 하지만 지금 당신의 경험을 읽어보니, 그건 우연이었을 수도 있겠네요.

해당 계정들의 모든 이메일과 IP도 차단했습니다.

네, 저도 IP와 이메일을 함께 차단하고 있습니다. 두 계정이 같은 IP를 사용한 경우는 딱 한 번뿐이었고, 솔직히 이후로는 확인을 멈췄습니다.

너무 많은 IP를 차단해서 실제 사용자들이 차단되는 일이 생길까 봐 조금 걱정됩니다. 가능한 IP의 수나 정당한 사용자가 차단될 확률에 대해 제대로 파악하지 못하고 있는 것 같습니다.

차단하기 전에 항상 공유 IP인지 확인해야 할까요?

네, 가입 시 커스텀 필드를 사용하면 이런 유형의 스팸을 자주 잡아낼 수 있습니다. dataexplorer 쿼리를 활용하는 것도 현재 상황에서 이를 포착하려는 좋은 방법이지만, 이 과정을 더 쉽게 만들어 주는 어떤 형태의 자동화 기능을 제공해야 한다고 생각합니다.

메타(Meta)에서는 수년 동안 이 방식을 적용해 왔으며, 신규 계정 가입 건수는 비교적 안정적으로 유지되고 있습니다.

저도 제 웹사이트에 이메일 주소를 올려서 앱 사용자들이 직접 연락할 수 있게 하고 있습니다. 그래서 실제 사용자가 등록하지 못할 경우 아마도 그 사실을 알게 될 텐데 (아직 그런 일은 없었습니다).

그렇게 해야 하는지 확신은 없지만, 저는 그렇게 하지 않습니다 :see_no_evil_monkey:

아니! 정당한 우려라고 생각합니다. 세계의 많은 지역에는 IP 주소가 풍부하지 않으며, 과거보다 IP가 풀(pool) 형태로 공유되는 경우가 훨씬 흔해졌습니다.

음, 그것이 많은 사람들을 소외시키지 않는다는 보장은 아니라고 생각합니다.

스패머의 IP 주소를 차단하는 아이디어는 미국에서, 그리고 개별적인 악성 행위자들과 케이블 인터넷을 통한 가정용 접속이 일반적이던 시대에 나온 전술이라고 봅니다. 지금은 매우 부적절하다고 생각합니다.

잘 관리되는 스톱리스트에 IP 주소를 대조하거나, 해당 주소의 ASN을 클라우드 제공업체와 같은 가능성이 낮은 소스들의 스톱리스트와 대조하는 것은 도움이 될 수 있습니다. 하지만 VPN을 사용하여 가입하는 사람들을 허용하고 싶다면, 그 근거만으로 차단하는 것은 여전히 좋지 않습니다.

네, VPN에는 문제가 될 수 있지만, VPN도 남용의 주요 원인이기도 합니다… 그래서 VPN에 대해 아무 조치도 취하지 않는 것에는 상당한 부담이 따릅니다. 이상적으로는 IP 평판 시스템 같은 것이 있어서, 전부 또는 전무가 아닌 중간 단계의 대응이 가능했으면 좋겠습니다.

Cloudflare로 해결할 수 있습니다. 로그 탐색기를 사용한 후, WAF 설정과 사용자 지정 규칙을 통해 해당 IP를 차단하고 챌린지를 적용하세요:

Discourse의 공식 hCaptcha 플러그인은 여기서 큰 도움이 될 수 있습니다. 이 플러그인은 특히 봇 가입을 완화하는 데 의도되어 있습니다.

(개인적으로 저는 Discourse의 Cloudflare Turnstile 지원도 보고 싶습니다. Turnstile의 무료 플랜에는 마찰 없는 비대화형(non-interactive) 모드가 포함되어 있는 반면, hCaptcha에서 유사한 기능을 사용하려면 월 99달러의 “pro” 요금제로 전환해야 하기 때문입니다. 이는 셀프호스터들에게는 정말 터무니없는 금액입니다.)

저도 잠재적 신규 사용자로서 그런 상황에 부딪히면 아마 그냥 포기했을 것 같습니다.

저는 일반적으로 스팸 사용자를 삭제하지 않습니다. 영구적으로 정지시킵니다. 이렇게 하면 그들의 정보를 더 쉽게 수집하여 패턴을 파악할 수 있고, 전술이 변할 때 빠르게 대응할 수 있습니다.

IP를 차단하면 그들은 단순히 새로운 IP를 얻습니다. 차단하지 않으면, 그중 일부가 같은 IP로 다시 돌아와 제가 빠르게 대응할 수 있습니다.

동시에, 등록 시 IP와 마지막 사용 IP가 다른 새로운 스팸 사용자들도 많이 있습니다.

저는 VPN을 통한 합법적인 사용이 매우 많기 때문에, 실제로 스팸이 아닌 무작위 IP를 계속 차단하면 오히려 랜덤한 실패가 발생하게 됩니다.

스팸 계정을 삭제할 때 이메일은 차단하되 IP는 차단하지 않는 옵션이 있어야 한다고 생각합니다. IP 차단은 직접적으로 측정할 수 없는 숨겨진 비용이 됩니다. 저는 이것이 매우 :see_no_evil_monkey:라고 생각합니다.

동의합니다!

음, 저도 그렇게 해볼까요. 최근 스팸 공격이 심해져서 새 사용자 승인 모드로 운영하고 있는데, 제 규모에서는 관리가 잘 되고 StopForumSpam을 통해 저나 다른 관리자들이 확인을 할 수 있어서 좋습니다.

저도 동일한 문제를 겪고 있습니다. 자체 호스팅 인스턴스에서 발생하며, 숫자가 증가하고 있습니다. 처음에는 주당 1~2건의 Sporadic(불규칙한) 가입이 시작되었습니다. 이번 주에는 10건의 가입이 발생했고, 그중 5건은 어제였습니다.

패턴은 성별(Pronoun) 설정에 랜덤 문자열이 사용되고, 이전에 언급된 이름과 성의 패턴이 나타나는 것입니다.

저는 whois IP 쿼리를 수행했는데, 90% 이상이 미국의 2개 클라우드 제공업체에서 온 것이었습니다. 그래서 IP 대신 네트워크를 차단하기 시작했습니다. 클라우드 제공업체 네트워크를 차단할 때 일반 사용자를 차단할 위험은 매우 낮습니다. 대부분은 /24이며, 일부는 /23 또는 /22 네트워크였습니다.

종종 가입 이메일에 대해 반송(bounce) 메시지를 받는데, 이는 이메일 주소를 사용할 수 없기 때문입니다. 이 주소들에도 패턴이 있습니다. 공통 부분은 서브도메인으로, 도메인 부분이 a, b, c, e와 같은 단일 문자 서브도메인으로 시작되는 형태입니다(예: ...@a.example.com).

이것이 정규식 패턴만 허용하는 경우 차단된 이메일 도메인 설정으로 차단할 수 있는 좋은 속성이 될 수 있습니다. 간단한 @[a-z]\.* 패턴으로 이러한 시도를 막을 수 있습니다.

최근에 이런 것들을 한꺼번에 많이 봤어요. 처음에는 드디어 SEO를 깨뜨린 줄 알았죠 :sweat_smile:

근데 OpenClaw를 떠올렸어요 :sweat_smile:

다행히 새로운 대량 사용자 관리 기능이 있네요! :folded_hands:

이어서 말씀드리자면… 몇 주 전에 hCaptcha를 도입하기 시작했는데, 처음 게시글에서 언급했던 특정 유형의 스팸 사용자는 완전히 사라졌습니다. 전반적인 스팸 양도 줄어들었을 가능성이 있으며, 가입자 수가 눈에 띄게 감소하지는 않았습니다.

그래서 hCaptcha를 한번 사용해 보시길 권합니다.

며칠 전, 인간 모더레이터가 지원서를 승인하는 데 도움이 되도록 지원자에게 필수 텍스트 필드(이름이 "관심사"인 사용자 필드)를 추가했습니다. (“계정 승인을 결정하는 데 도움이 되도록 몇 마디만 적어 주세요.”)

아직 이르지만, 의심스러운 계정 두 개가 무작위 비밀번호 같은 텍스트를 입력하여 쉽게 거부할 수 있었습니다.

모더레이터들이 계정 검토 처리를 도와주길 원하며 실제로도 도와주고 있지만, 이메일 주소나 IP 주소를 볼 수 없어 다소 제한적입니다. Stopforumspam은 꽤 유용한 자원이었습니다.

moderators_view_ipsmoderators_view_emails 사이트 설정을 어떻게 구성하셨나요?