【真的假的】因應攻擊討論

2017/5/10 Update

調查結果：https://docs.google.com/spreadsheets/d/1uqhbl2s_vktPAIJiKiu9L0yTD30Kk_B50W1OpDGhrU4/edit#gid=1409443958

3 月底至 4 月中，共有 6 個 LINE user ID 參與 spamming，共發送 1045 篇垃圾訊息。

[3:04 PM]
mrorz http://rumors.hacktabl.org/?orderBy=createdAt&before=WzE0OTA0MjAwODk2MjgsImJhc2ljI0FWc0Q5Y01kdEtwOTZzNjU5Qzk2Il0%3D&after=
資料庫發現大量重複舉報的 article。
但如果是透過 LINE bot，他在搜尋的時候應該不會重複舉報才對。

@ggm @darkbtf 請問你們有沒有空處理這個呢 QQ
由於 elasticsearch 放在 production 機器上沒有 expose 出來（本來就不該 expose @@）所以要連到 production 機器上面操作資料庫來查 article 送出的 user。

[3:04 PM]
我忙著做 rumors-site 的界面把 JSON 弄掉，一時半刻無法處理 orz

[3:28 PM]
mmm90415 joined #rumors

[3:47 PM]
darkbtf 有 ssh key 嗎?

[3:47 PM]
我可以上去看看

[4:55 PM]
darkbtf 軍官那個是兩個 userId 舉報的

[4:55 PM]
等等我 aggregate 一下 XD 確定一下

[4:58 PM]

>     "query": {
>         "match": { "text": "軍官翹班" }
>     },
>     "size": 0,
>     "aggs": {
>         "user": {
>             "terms": { "field": "userId" }
>         }
>     }
> }'
{
 "took" : 18,
 "timed_out" : false,
 "_shards" : {
   "total" : 1,
   "successful" : 1,
   "failed" : 0
 },
 "hits" : {
   "total" : 403,
   "max_score" : 0.0,
   "hits" : [ ]
 },
 "aggregations" : {
   "user" : {
     "doc_count_error_upper_bound" : 0,
     "sum_other_doc_count" : 0,
     "buckets" : [
       {
         "key" : "U9019d71099419ef66cd46a3c1e7c0949",
         "doc_count" : 393
       },
       {
         "key" : "U02aea8403671f6d2a4a2d857524bc69d",
         "doc_count" : 6
       },
       {
         "key" : "",
         "doc_count" : 3
       },
       {
         "key" : "U9fe93c6a9edc19e634e8de1d0c576f32",
         "doc_count" : 1
       }
     ]
   }
 }
}

[5:01 PM]

[5:01 PM]
darkbtf 這個 userid 傳了 393 個，不過不知道這是誰 (edited)

[5:07 PM]
darkbtf 用 LINE 是要怎麼傳這麼多 |||

[6:00 PM]
mrorz shared this file
20170325-1752.bot.log
339KB
Binary
Click to download
2 Comments

[6:00 PM]
mrorz commented:
We've been spammed…

[6:00 PM]
darkbtf 出現惡意攻擊了

[6:01 PM]
mrorz LINE 好像有黑名單功能

[6:01 PM]
我看看

[6:04 PM]
LINE bot 無法

[6:04 PM]
我寫個 blacklist 好了

[6:11 PM]
mrorz 然後資料庫備份可能要先處理了呢
如果要對資料庫做清理，要先有備份機制

[6:13 PM]
darkbtf 好我儘快弄個

[6:18 PM]
mrorz 看起來是有人弄了 sikuli script 一直洗唷

[6:18 PM]
darkbtf 怎麼確定是 sikuli 呀

[6:19 PM]
這人也太無聊

[6:19 PM]
mrorz added this Plain Text snippet: 現在 LINE bot 不會回任何訊息給 'U9019d71099419ef66cd46a3c1e7c0949'，但他繼續送

2017-03-25T10:17:29.861237+00:00 heroku[web.1]: State changed from starting to up
2017-03-25T10:17:19+00:00 app[heroku-redis]: source=REDIS sample#active-connections=2 sample#load-avg-1m=0.08 sample#load-avg-5m=0.175 sample#load-avg-15m=0.135 sample#read-iops=0 sample#write-iops=0 sample#memory-total=15664468.0kB sample#memory-free=12561232.0kB sample#memory-cached=1060964.0kB sample#memory-redis=1684080bytes sample#hit-rate=0.8856 sample#evicted-keys=0
2017-03-25T10:17:31.610501+00:00 heroku[router]: at=info method=POST path="/callback" host=rumor-line-bot.herokuapp.com request_id=7e85086e-dc47-4a0a-878a-c6d145d11e00 fwd="203.104.146.153" dyno=web.1 connect=1ms service=68ms status=200 bytes=137 protocol=https
2017-03-25T10:17:31.598400+00:00 app[web.1]: [App:heroku-line-bot] [LOG] Blocked user INPUT =
2017-03-25T10:17:31.598415+00:00 app[web.1]: {"type":"message","userId":"U9019d71099419ef66cd46a3c1e7c0949","timestamp":1490437044861,"message":{"type":"text","id":"5836054878711","text":"澎湖馬公基地軍紀大崩壞，軍官集體“翹...
Add Comment Click to expand inline 36 lines

[6:29 PM]
mrorz 或許需要一個 abnormal 示警機制

[6:29 PM]
但我要先更新網站外觀 orz

[6:29 PM]
darkbtf 最好要有後台就是

[6:30 PM]
mrorz 啊是呢

[6:30 PM]
kibana 嗎 orz

[6:30 PM]
我 google 過 elasticsearch backend

[6:30 PM]
除了 kibana 好像沒啥能用的 Orz

[6:30 PM]
darkbtf 對呀

[6:30 PM]
然後 kibana 要配 searchguard

[6:30 PM]
不然會是裸露的

[6:31 PM]
官方的 auth 機制要付費

[6:31 PM]
mrorz QQ

[7:35 PM]
mrorz 現在有人改試「飯後喝涼水」了⋯⋯

[7:37 PM]
然後我剛剛 deploy 好像有設定跑掉了，現在網頁會一直 cannot fetch
我先 revert 回去囧

mrorz added and commented on this Plain Text snippet: 20170326-0106.log

2017-03-25T13:46:33.333422+00:00 app[web.1]: [App:heroku-line-bot] [LOG] CONTEXT =
2017-03-25T13:46:33.333429+00:00 app[web.1]: {"state":"ASKING_ARTICLE_SUBMISSION","data":{"searchedText":"乾燥劑爆炸"},"issuedAt":1489674835047}
2017-03-25T13:46:33.333430+00:00 app[web.1]:  INPUT =
2017-03-25T13:46:33.333431+00:00 app[web.1]: {"type":"postback","userId":"Ubfeea8662cd34b958b88b9676c465bca","timestamp":1490449592667,"postback":{"data":"{\"input\":\"n\",\"issuedAt\":1489674835047}"}}
2017-03-25T13:46:33.333432+00:00 app[web.1]:  OUTPUT =
2 Comments Click to expand inline 1,502 lines

果不其然換了個 userId ( U13ee837855712f64503bc9676ff9c25c )

[1:15 AM]
ggm commented:
所以他是一直傳同一份文章？看 log 是有不同內容的，LINE 應該是很容易換 id

[1:21 AM]
mrorz 不同內容，但都是傳入 gibberish

[1:21 AM]
仔細看會發現他傳的都像是假文產生器產生的東西

[1:27 AM]
ggm 是產生器出來的還是是那種真的很多人在散播的呀？

[1:28 AM]
往好處想是不是有人有一堆內容想要建檔？

[1:41 AM]
mrorz 不是

[1:41 AM]
「員年：達沃8動·蘇6克運，\n前克球9羅埃西1足亞」

[1:41 AM]
這種是內容嗎 (edited)

[1:42 AM]
基本上這個洗版好像已經很多天了
http://rumors.hacktabl.org/?orderBy=createdAt&before=WzE0OTAwOTkwNjYyMDcsImJhc2ljI0FWcncwMVZrdEtwOTZzNjU5Q3ZyIl0%3D&after=

[1:42 AM]
只是今天才仔細去看

[11:50 AM]
mrorz So here comes the question: do we need captchas on users sending duplicated articles or sending articles too often? (edited)

[11:51 AM]
lucien Hmm…captcha in line bot

[11:51 AM]
mrorz 當然針對後期演化的假文產生攻擊，near-duplicate detection 不會 work

[1:25 PM]
darkbtf 應該用頻率偵測吧

[1:25 PM]
這個頻率高到不太合理

[9:56 PM]
mrorz 他滿間歇性的耶，一段一段的

[9:56 PM]
http://rumors.hacktabl.org/?filter=unsolved&before=WzE0OTA1MTMwNDQzNTUsImJhc2ljI0FWc0pnQ09FdEtwOTZzNjU5REx0Il0%3D&after=&orderBy=createdAt

[9:56 PM]
今日的攻擊，大概是一頁 25 篇產生器假文

[9:57 PM]
我在想要不要

網站介面在文章列表提供多選 + 通通標成Not article 的功能 (類似email app)

[9:59 PM]
2. 統計文章作者 User ID 被標成 not-article 的次數，高的封鎖

[10:01 PM]
3. 需 Review non-rumor 避免有人在多選的時候誤把有意義的回報標成 non-article ( 只要加上rumor 與 non-rumor 的回應，line bot 也能正常回覆這些曾經被標成 not article 的文章) (edited)

[10:02 PM]
大家覺得呢

[10:06 PM]
至於 near-duplicate detection 可能還是要做，因為今天有一個回報長這樣

http://rumors.hacktabl.org/article/AVsIpOUYtKp96s659DLY

[10:06 PM]
往下卷可以看到「相關文章」那裡有一個一模一樣的文章

[10:08 PM]
我覺得 line bot 裡面如果找到的字跟query text 相差真的超小
那就不讓使用者選擇「這裡沒有要找的文章」這個選項，直接給使用者看結果好了。

ggm 1. 網站介面在文章列表提供多選 + 通通標成Not article 的功能 (類似email app)
這個是不是也可以做在我們之前的分類裡面有一個是其他（or 閒聊）
1 reply 8 days ago View thread

[6:36 PM]
ggm 2. 統計文章作者 User ID 被標成 not-article 的次數，高的封鎖
這個應該沒什麼問題，不過正確來說是指高頻率對吧？

[6:38 PM]
ggm 3. 需 Review non-rumor
這個說 Review 的意思是？他被標記後可以被復原？我覺得是需要的，我想到說如果有人會一直傳假內容上來，那麼他會不會也惡意地想要把全部文章標成 non-article 之類的 (edited)
2 replies Last reply 8 days ago View thread

mrorz [Mar 27] 
其實這個「review」具體來說只是提供一個「只被標成『non-article』的文章」列表。這個列表大家都可以看，所以可以與首頁目前的 All / Not replied yet / Replied filter 並列。

ggm [Mar 27] 
嗯嗯那跟我下面講個應該類似，他就是一個標籤

[6:39 PM]
ggm 不過我覺得可以把這個標籤的行為做的跟其他標籤無異，就是變成有 k 個人認為他是 non-article，不見得 non-article 是個 on/off

[6:40 PM]
然後 es 在搜尋的時候在設一個 non-article 的門檻，超過 3 個的不要吐出來

[6:41 PM]
不過搜尋的結果有兩塊，一個是回傳給小編的，一個是回傳給使用者的，給小編的可能門檻高一點？給使用者的門檻低一點？但是這樣也會發生一種情形就是當某篇文章被湊過高的 non-article 標籤之後，就再也看不到他了，那這時候就是使用 revert 機制的時候 (edited)

[6:47 PM]
mrorz 我是覺得實務上，一則測試用簡訊要 3 個人標成 non-article 才會永遠看不到他，好像有點不實用 @@
我原本的想法是這樣的

因為小編通常都會使用「Not replied yet」這個 filter 來過濾出沒人回過的 article，所以被回過 non-article 的文章，自然就不會列出
但如果開放在 list 勾選數則一起標成「non-article」，那有可能會有人誤把有意義的 article 標成 non-article（或惡意地將大片 article 標成 non-article——但是小編是記名的，這個情形應該還好吧）。所以會需要一個 non-article 列表 filter 讓小編偶爾看看 non-article，找出事實上有意義的 non-article 送出新的 rumor / non-rumor reply。
對 LINE bot 使用者來說，只要有 rumor / non-rumor reply，bot 就會顯示有回答，一則 article 有多少 non-article reply 並不會有任何影響。 (edited)

mrorz [Mar 27]
針對「3」具體來說請見程式碼 XDD

https://github.com/MrOrz/rumors-line-bot/blob/master/src/processMessages.js#L159

我只計算 rumorReplies、 notRumorReplies 。「 有人認為您傳送的這則訊息並不是完整的文章內容，或認為「真的假的」不應該處理這則訊息。 」這句話在 if 的很後面，只要有一個 rumorReply 或 notRumorReply，那段話就不會出現。
GitHub
MrOrz/rumors-line-bot
rumors-line-bot - Line bot that checks if a message contains internet rumor.

(edited)

ggm [Mar 27]
哈哈清楚清楚

ggm [Mar 27]
我覺得你這樣做也行，但是要從「non-article」救回來這件事情，因為「non-article」會越來越大，所以可能要輔助靠時間排序，這樣才會比較好救回來，然後時間久的應該就很難再救回來了。

不過呢，救不會來也沒差吧？就少一篇文章而已（也不會很不方便），如果這類的假文章真的很多，應該又會被回報

mrorz [Mar 28]
那按照「最後有人回報」的間來排序「non-article」列表好了，這樣如果真的有 popular message 被誤標，也比較容易能救回來

mrorz [Mar 28]
我會找時間整理一下現在 DB mappings 之間的 relation。
之前為了要讓使用者可以比較好 filter 一些東西，所以 foreign key 擺放得有點奇怪（非傳統 RDBMS 的結構），但當初設計的 foreign key 擺放方式，對『按照「最後有人回報」的間來排序』沒有助益 orz

整理完 mapping 之後，一併整理 query 的需求（例如說要按照啥排序、要做出一個列表來列出「有 non-article」的文章等等），希望能與 @darkbtf 或 @sayuan 一起討論一下要怎麼調整 mapping 比較好 @@

ggm [Mar 28]
一起討論++ (edited)