題:
某人正試圖強行(?)我的私人郵件服務器...非常...緩慢...並且IP不斷變化
Heinzi
2017-11-27 13:22:53 UTC
view on stackexchange narkive permalink

這已經進行了大約1-2天:

  heinzi @ guybrush:〜$ less /var/log/mail.log | grep'^ Nov 27。* postfix / submission。* warning'[...] Nov 27 03:36:16 guybrush postfix / submission / smtpd [7523]:警告:主機名bd676a3d.virtua.com.br無法解析為地址189.103.106.61Nov 27 03:36:22 guybrush postfix / submission / smtpd [7523]:警告:未知[189.103.106.61]:SASL PLAIN身份驗證失敗:Nov 27 03:36:28 guybrush postfix / submission / smtpd [7523] ]:警告:未知[189.103.106.61]:SASL登錄身份驗證失敗:VXNlcm5hbWU6Nov 27 04:08:58 guybrush postfix / submission / smtpd [8714]:警告:主機名b3d2f64f.virtua.com.br不能解析為地址179.210。 246.79Nov 27 04:09:03 Guybrush後綴/提交/ smtpd [8714]:警告:未知[179.210.246.79]:SASL PLAIN身份驗證失敗:Nov 27 04:09:09 Guybrush後綴/提交/ smtpd [8714]:警告:未知[179.210.246.79]:SASL登錄身份驗證失敗:VXNlcm5hbWU6Nov 27 05:20:11 guybrush postfix / submission / smtpd [10175]:警告:主機名b3d0600e.virtua.com.br無法解析為地址179.208.96.14Nov 2705:20:16 guybrush postfix / submission / smtpd [10175]:警告:未知[179.208.96.14]:SASL PLAIN身份驗證失敗:11月27日05:20:22 guybrush postfix / submission / smtpd [10175]:警告:未知[ 179.208.96.14]:SASL LOGIN身份驗證失敗:VXNlcm5hbWU6Nov 27 06:42:43 guybrush postfix / submission / smtpd [12927]:警告:主機名b18d3903.virtua.com.br無法解析為地址177.141.57.3Nov 27 06:42 :48 guybrush postfix / submission / smtpd [12927]:警告:未知[177.141.57.3]:SASL PLAIN身份驗證失敗:11月27日06:42:54 guybrush postfix / submission / smtpd [12927]:警告:未知[177.141.57.3 ]:SASL LOGIN身份驗證失敗:VXNlcm5hbWU6Nov 27 08:01:08 guybrush後綴/提交/ smtpd [14161]:警告:主機名b3db68ad.virtua.com.br不能解析為地址179.219.104.173
Nov 27 08:01:13 guybrush postfix / submission / smtpd [14161]:警告:未知[179.219.104.173]:SASL PLAIN身份驗證失敗:11月27日08:01:19 guybrush postfix / submission / smtpd [14161]:警告:未知[179.219.104.173]:SASL LOGIN身份驗證失敗:VXNlcm5hbWU6  

每1-2小時都會有一次失敗的登錄嘗試,總是來自同一域,但是每次都來自不同的IP地址。因此,它不會觸發fail2ban並且logcheck消息開始使我煩惱。 :-)

我的問題:

  1. 這種“攻擊”有什麼意義?速度太慢了,無法進行有效的暴力破解,我真的懷疑有人會專門針對我的小型個人服務器。

  2. 我有什麼辦法可以對付它?除了禁止該提供商的完整IP範圍?我可以不再擔心,並將這些消息添加到我的logcheck ignore config中(因為我的密碼很安全),但這可能會導致我錯過更嚴重的攻擊。

  3. ol>
您的個人服務器是否很小並不重要。無論如何,它對於殭屍網絡都將很有用。慢速只是為了避免絆倒任何檢測機制(儘管這只是我的觀點,不會做出任何艱難的陳述)。至於禁止提供者範圍-都不重要。殭屍網絡擁有大量可用的ip,並且它們可能具有欺騙性。
是嘗試使用相同的帳戶還是不同的帳戶?
@schroeder:好的問題。我剛剛啟用了記錄失敗嘗試的用戶名的功能,並將返回報告。
@Heinzi這似乎是至關重要的信息。如果是同一帳戶而不是您擁有的帳戶,則有人錯誤地配置了他們的服務器
@schroeder:在最近兩個小時內嘗試的用戶名是“ info @ ”(1次嘗試),“ admin @ ”(1次嘗試)和“ AB ”(2次嘗試)。在我看來就像是經典的蠻力猜測。
我以前在我的蜜罐上看到過這個。這是“背景輻射”。暴力破解的企圖在非常廣泛的範圍內展開。客人的答案可能是正確的答案。
一個簡單的解決方案:[Fail2Ban](https://www.fail2ban.org/wiki/index.php/Main_Page),其中一個自定義監牢和maxretry設置為1。這就是我使用的方法,效果很好。
有趣的是,它們似乎都起源於巴西Virtua擁有的一個數據中心。這讓我感到奇怪,如果他們還可以使用不花錢且不與信用卡關聯的機器人來購買服務器,誰來為服務器付費?
@Damon Virtua是數據中心嗎?你他媽在說什麼?Virtua以前是http://www.netcombo.com.br/(一家家用有線電視/互聯網提供商)的名稱。您甚至可以看到地址的第一部分似乎是客戶MAC。
這似乎是對默認密碼的掃描,因為提供的LOGIN是用戶名“ Username”和空字符串的密碼。
如果足夠小,則可以將設備可以從中檢查電子郵件的每個ip網絡阻止列入白名單。因此,這將是分配給您的cellco的任何IP塊,並且IP範圍從您可能會無線連接的遠程站點(朋友,工作場所等)或僅保留在蜂窩數據上。除了家庭環境以外,不建議這樣做。
另一個骯髒的緩解措施是禁止IPv4連接,並且假設兩端都允許通過IPv6進行郵件檢查。腳本小子往往只關注IPv4連接。
@Heinzi如果攻擊來自與Virtua連接的主機,這就是您看到不斷變化的IP的原因。該連接因在使用中無故突然更改IP而臭名昭著,並且在某些應用中可能引起頭痛。請注意,這是家庭連接,因此攻擊機可能是試圖做“有趣的事情”的家庭用戶殭屍網絡的一部分。
Google for`fail2ban`。
@peterh:請再次閱讀問題,已經提到了fail2ban。
IIUC正確,攻擊本身成功的機會大約為零,但是主要問題是它們正在填充日誌檢查,並且可能掩蓋了其他更嚴重的攻擊。對?
完全是@smci:。我可以僅將這些消息添加到我的logcheck ignore config中,但是我擔心自己那時可能會錯過更嚴重的攻擊。但是,在閱讀了答案之後,似乎沒有一個簡單的答案可以解決這個問題,我應該過濾掉這些消息並不再擔心。
@Heinzi:好的,但是我要說的是,您想根據上面的解釋來編輯並重新陳述問題。
@smci:已完成。我試圖使更改盡可能小,以避免使現有答案無效。
五 答案:
guest
2017-11-27 13:27:31 UTC
view on stackexchange narkive permalink

這種“攻擊”有什麼意義?速率太慢而無法進行有效的暴力破解,我真的懷疑有人會專門針對我的小型個人服務器。

速率很慢,或者總發送的數據量很小?您可能很少見到連接,但是您如何知道進行暴力破解的殭屍程序並沒有不斷使上行鏈路飽和,而您的站點只是被攻擊的站點之一?與一次攻擊大量服務器(每個服務器只看到很少的連接)相比,攻擊者一次花一個短時間去訪問一個站點(並觸發fail2ban)沒有優勢。兩者都可以具有每秒相同的外發身份驗證嘗試速率。 ?

不太可能。可能來自殭屍網絡或低成本VPS集群。僅通過查看其中的一些,就無法確定正在使用哪些其他IP範圍。如果它們不在同一子網上,則無法預測它們。您可以放心地忽略這些連接。只是互聯網的背景噪音。

以每小時1次嘗試的速度,大約需要4天的時間來嘗試在一個帳戶中使用100個最常用的密碼,而不會絆倒任何東西...對於構築殭屍網絡的人,我可以看到這種攻擊的巨大回報...
也許將管理員密碼更改為他們已經嘗試過的密碼。那會讓他們絆倒。
@Caterpillaraoz因此,您建議我們不要通過從100個最常見的密碼列表中選擇一個密碼來運行防止遠程訪問保護的服務器?
@Caterpillaraoz您不知道它們要攻擊多少台服務器。如果他們在四天內將前100個密碼發送到30,000個郵件服務器,則很可能會加入其中的幾個。
我建議大家都使用“棒球!”作為密碼:P @Qwertie是我的意思,在成千上萬的服務器上“運行緩慢”並擊中了許多很多帳戶,出於好奇,我嘗試以SSH身份作為公司F **** G的默認管理員數據庫並進入...。
如果密碼不好,就不會常用,對嗎?
-1
@James_pic:我永遠不會猜到Password123 !,我通常在Admin,admin和root之後放棄,問一個真正知道密碼的人
可能會帶來少量痛苦的一件事是,是否增加了針對主機的密碼嘗試失敗的響應時間。
@Christian多虧了蘋果公司,如今,在許多Mac上,root都是一個不錯的猜測。
@Daniel作為用戶名
David Rouse
2017-11-27 19:32:18 UTC
view on stackexchange narkive permalink

問題1 –除非配置錯誤(如評論中所述),以我的經驗來看,這些似乎是自動攻擊,旨在尋找可以從中發送未經請求的商業電子郵件(或網絡釣魚嘗試)的帳戶。 p p>

問題2 –如果合法登錄的IP範圍是已知的並且足夠小,則阻止那些範圍之外的所有內容可能會更容易。

我管理一封小型企業電子郵件服務器,這種探測幾乎對我們來說是連續發生的。

Tiberiu-Ionuț Stan
2017-11-28 03:51:13 UTC
view on stackexchange narkive permalink
每1-2小時

1次嘗試?

也許是某人的iPhone的密碼已過期。可能是您的!或者,如果您正在重新使用託管公司的IP地址,則以前的“所有者”可能仍然在某個地方有一些電子郵件客戶端,配置為[現在]輸入IP。

如果您擁有IP地址,那麼您至少可以跟踪它們。

VXNlcm5hbWU6顯然是“用戶名”的base64編碼,顯然Postfix確實將其作為編碼提示發送。與“ AUTH LOGIN”(很多Google匹配)相關的內容
@infixed是的,該字符串是AUTH LOGIN機制的標準部分。在AUTH LOGIN中,所有內容都是以base64編碼的。在該編碼下,交換很簡單:(1)服務器發送“用戶名”(2)客戶端發送用戶名(3)服務器發送“密碼”(4)客戶端發送密碼。(儘管我想知道日誌文件中字符串的存在是否可能表明客戶端實際上正在發送“ Username”作為用戶名...)
如果您每90分鐘命中3萬台服務器,那麼每秒仍然有5.5個請求,是的,這是蠻力的。
蠻力在於進場,而不是速度。所描述的攻擊絕對構成了“蠻力”,儘管這種攻擊方式喚起了“溫柔仁慈”的內涵。
Yakk
2017-11-28 01:58:53 UTC
view on stackexchange narkive permalink

禁止重複嘗試侵入系統的IP的現有標準做法只能抵禦有針對性的攻擊。

殭屍網絡可以找到龐大的服務器列表,並分發造成攻擊的人和誰他們在殭屍網絡中進行攻擊。症狀將是針對您的系統的登錄嘗試失敗的背景級別,直到成功為止,這時他們將部署一些升級到root的工具包並將您的系統添加到殭屍網絡。

強密碼是一種可能的防禦措施,但需要與強密碼配合使用,以確保系統免受非密碼攻擊。假設發現登錄系統上存在緩衝區溢出/下溢攻擊;殭屍網絡可以切換為每分鐘進行一次攻擊,並且每分鐘攻擊1000個系統,包括您的系統。

另一種防禦措施可能是晦澀。這類攻擊是在難以實現的結果之後進行的。將登錄系統修改為(例如)要求對特定端口號執行ping操作,然後才能嘗試登錄。這純粹是晦澀難懂,但是突然間,它似乎停止了登錄,好像在那裡可以登錄。代價是您現在需要設計特定的ping才能遠程登錄。或者,您可以將允許您從其遠程登錄的一些IP地址列入白名單。就像系統跟踪攻擊它們的IP地址一樣,分佈式系統也可以跟踪殭屍網絡攻擊任何人。放入信任系統流程中,您可以構建可檢測到此類密碼破解殭屍網絡並讓所有人阻止它們的基礎架構。但這是您可以做的。

有關更多信息,請閱讀[The Hail Mary Cloud](http://bsdly.blogspot.co.uk/2013/10/the-hail-mary-cloud-and-lessons-learned.html)。
@JdeBP可以從這個簡短評論中做出答案嗎?術語“冰雹瑪麗雲”的答案和給出的參考應該在這裡。
Harry McGovern
2017-11-28 21:03:51 UTC
view on stackexchange narkive permalink

SASL PLAIN身份驗證失敗:andb3db68ad.virtua.com.br不能解析為地址179.219.104.173

只要您沒有為任何用戶啟用PLAIN身份驗證,就可以了。此外,這:b3db68ad.virtua.com.br不能解析為地址179.219.104.173,它告訴您該域是虛假的域,因為它無法解析為所使用的IP。另一個失敗。因此,它甚至可能不是來自該域。您可以花大量時間使用Postfix編寫規則來禁止這種事情,但最終花費的時間遠遠超過系統的負載。

更加安全的身份驗證方法(散列+ -kerberos)只能保護密碼不會在途中或日誌中被竊聽,這意味著它可以保護用戶使用密碼(可能通過集中登錄)在其他系統上進行身份驗證。 所以他不會好起來的!不管密碼測試的安全性如何,即使使用使用某種哈希+挑戰方法(甚至不通過網絡發送可重複使用的哈希)的Kerberos,暴力破解仍然有效。


該問答將自動從英語翻譯而來。原始內容可在stackexchange上找到,我們感謝它分發的cc by-sa 3.0許可。
Loading...