Tấn công DDoS bằng PDF Spam
Hôm nay tôi có một case khá thú vị. Một khách hàng gọi điện, báo server của họ đặt ở FPT Telecom (chỗ 64-66 Võ Văn Tần Q.3) bị phía FPT Telecom...tắt mất vì có quá nhiều traffic đi vào server này, có thời điểm lên đến 100Mbs. Họ nhờ tôi đến FPT Telecom trực tiếp kiểm tra xem nguyên nhân tại sao có quá nhiều traffic đến server.
Trên đường đi, tôi được biết server của khách hàng tôi không hề bị treo hay gặp vấn đề gì cả, chỉ có...firewall của FPT Telecom (nếu tôi đoán không lầm là Checkpoint trên Windows) lại bị treo khi phải tiếp nhận và xử lí lượng traffic lớn như thế; thành ra toàn bộ các server nằm phía sau con firewall này coi như bị cách ly với thế giới bên ngoài.
Bên FPT Telecom cũng đã thông báo cho khách hàng của tôi rồi, nhưng khách hàng của tôi lại không biết cách kiểm tra thế nào, thế mới xảy ra chuyện FPT Telecom buộc lòng tắt server và disable cái switch port luôn.
Đến chỗ FPT Telecom, đợi gần 15' đám bảo vệ mới cho vào, rồi leo thang bộ lên đến tận tầng 5, tôi muốn ná thở vì còn phải vác theo cái balo to phía sau lưng. Đám FPT Telecom này đối xử với khách hàng lạ thật, nó bắt phải vào ngồi trong phòng server, chịu lạnh cũng như ồn kinh khủng.
Mở server lên, việc đầu tiên tôi làm là tìm hiểu xem server đang chạy các dịch vụ gì. Đây là server hosting, thành ra nó chạy toàn những dịch vụ phổ biến như named, apache, exim...Do tình trạng traffic đi vào ồ ạt rất giống với việc bị tấn công DDoS, nên tôi thử nhìn vào log của các dịch vụ này xem có gì bất thường không.
Dịch vụ đầu tiên tôi coi là thằng apache. Toàn bộ log của nó chỉ có mỗi 40M; lước sơ qua nội dung log của một số website host trên server này, tôi cũng không thấy có dấu hiệu gì của một cuộc tấn công DDoS nhắm vào web-application.
Dịch vụ thứ hai tôi coi là thằng Exim. Chà, log của thằng này dữ dội hơn, riêng exim_rejectlog đã là hơn 72M chỉ trong ngày hôm đó. Tổng cộng log của nó là hơn 200M. Khách hàng cũng cho biết, mỗi ngày họ nhận được rất nhiều spam mail.
Do switch port của server đã bị disable, nên ngoài mấy cái log này ra, tôi chẳng thể biết được traffic đi đến server này là loại traffic nào. Do đó việc tiếp theo tôi làm là thuyết phục bên phía FPT Telecom enable lại switch port của server này.
Cũng may là tôi có quen với người chịu trách nhiệm ở FPT Telecom (do tôi từng giúp họ khắc phục một sự cố tương tự), nên sau một hồi thương thuyết, họ quyết định enable lại switch port của con server trong vòng 10', rồi sẽ disable tiếp cho đến khi nào tôi tìm ra nguyên nhân.
Hóa ra tôi chẳng cần đến 10'. Ngay khi switch port của server được enable lại, tôi liền chạy tcpdump để bắt các packet gửi đến server. Chà, mới chạy được chưa đầy 10 giây mà thằng tcpdump báo đã chụp được hơn 10.000 packet rồi. Nhiêu đây là đủ để coi rồi, nên tôi dừng tcpdump, và báo bên FPT Telecom disable switch port lại.
Tôi nối laptop vào console của server, download file dump về xem. Hmm mới snifff có chưa đầy 10 giây mà file này đã nặng gần 1,5M rồi. Mở nó lên bằng Wireshark, đập vào mắt tôi đầu tiên là có quá nhiều...ARP broadcast packet. Tiếp theo là SMTP, DNS rồi mới đến HTTP.
Thông tin netstat trên server cũng cho biết các connection chủ yếu đang được đổ dồn dập vào port 53 và port 25 từ nhiều nguồn IP khác nhau.
Hình ở trên là kết quả tôi sử dụng tính năng "Follow TCP Stream" của Wireshark đối với các packet của một SMTP connection. Có vẻ như ai đó đang hối hả gửi mail có attachment rất lớn đến server này.
Thông tin về DNS traffic cũng cho thấy, đa số các query đến named chạy trên server này là hỏi MX record của một số domain được đặt tại đây.
Để hoàn chỉnh, tôi tiếp tục lần theo dấu vết của HTTP traffic. Không có gì bất thường cả, có vẻ như nguyên nhân chính nằm ở SMTP và DNS rồi.
Dựa vào DNS, tôi liệt kê ra danh sách các domain đang bị gửi spam, và đề nghị khách hàng tôi tạm thời disable những domain này, không cho phép nhận mail nữa; rồi tôi yêu cầu bên FPT Telecom mở lại switch port, chạy tcpdump để coi traffic có tăng lên hay không.
May mắn quá, đúng như tôi dự đoán, tôi sniff gần cả phút mà chỉ thu được chưa đầy 500Kb. Tôi chờ thêm 20', bên FPT Telecom cho biết traffic đi đến server đã giảm hẳn. Mọi thứ đã trở lại bình thường.
Lục lọi thông tin trên server và đám packet bắt được bằng tcpdump, tôi thấy rằng attachment mà đám spammer đang cố gửi đến server toàn là mấy file PDF. Cách đây vài ngày Internet Storm Center cũng có cảnh báo về PDF Spam. Bản thân tôi mỗi ngày cũng nhận vài cái PDF spam này. Tuy vậy hệ thống của tôi cũng ổn, không gặp vấn đề gì.
Bài học rút ra từ case này: đừng bao giờ sử dụng Windows làm firewall ;).
Trên đường đi, tôi được biết server của khách hàng tôi không hề bị treo hay gặp vấn đề gì cả, chỉ có...firewall của FPT Telecom (nếu tôi đoán không lầm là Checkpoint trên Windows) lại bị treo khi phải tiếp nhận và xử lí lượng traffic lớn như thế; thành ra toàn bộ các server nằm phía sau con firewall này coi như bị cách ly với thế giới bên ngoài.
Bên FPT Telecom cũng đã thông báo cho khách hàng của tôi rồi, nhưng khách hàng của tôi lại không biết cách kiểm tra thế nào, thế mới xảy ra chuyện FPT Telecom buộc lòng tắt server và disable cái switch port luôn.
Đến chỗ FPT Telecom, đợi gần 15' đám bảo vệ mới cho vào, rồi leo thang bộ lên đến tận tầng 5, tôi muốn ná thở vì còn phải vác theo cái balo to phía sau lưng. Đám FPT Telecom này đối xử với khách hàng lạ thật, nó bắt phải vào ngồi trong phòng server, chịu lạnh cũng như ồn kinh khủng.
Mở server lên, việc đầu tiên tôi làm là tìm hiểu xem server đang chạy các dịch vụ gì. Đây là server hosting, thành ra nó chạy toàn những dịch vụ phổ biến như named, apache, exim...Do tình trạng traffic đi vào ồ ạt rất giống với việc bị tấn công DDoS, nên tôi thử nhìn vào log của các dịch vụ này xem có gì bất thường không.
Dịch vụ đầu tiên tôi coi là thằng apache. Toàn bộ log của nó chỉ có mỗi 40M; lước sơ qua nội dung log của một số website host trên server này, tôi cũng không thấy có dấu hiệu gì của một cuộc tấn công DDoS nhắm vào web-application.
Dịch vụ thứ hai tôi coi là thằng Exim. Chà, log của thằng này dữ dội hơn, riêng exim_rejectlog đã là hơn 72M chỉ trong ngày hôm đó. Tổng cộng log của nó là hơn 200M. Khách hàng cũng cho biết, mỗi ngày họ nhận được rất nhiều spam mail.
Do switch port của server đã bị disable, nên ngoài mấy cái log này ra, tôi chẳng thể biết được traffic đi đến server này là loại traffic nào. Do đó việc tiếp theo tôi làm là thuyết phục bên phía FPT Telecom enable lại switch port của server này.
Cũng may là tôi có quen với người chịu trách nhiệm ở FPT Telecom (do tôi từng giúp họ khắc phục một sự cố tương tự), nên sau một hồi thương thuyết, họ quyết định enable lại switch port của con server trong vòng 10', rồi sẽ disable tiếp cho đến khi nào tôi tìm ra nguyên nhân.
Hóa ra tôi chẳng cần đến 10'. Ngay khi switch port của server được enable lại, tôi liền chạy tcpdump để bắt các packet gửi đến server. Chà, mới chạy được chưa đầy 10 giây mà thằng tcpdump báo đã chụp được hơn 10.000 packet rồi. Nhiêu đây là đủ để coi rồi, nên tôi dừng tcpdump, và báo bên FPT Telecom disable switch port lại.
Tôi nối laptop vào console của server, download file dump về xem. Hmm mới snifff có chưa đầy 10 giây mà file này đã nặng gần 1,5M rồi. Mở nó lên bằng Wireshark, đập vào mắt tôi đầu tiên là có quá nhiều...ARP broadcast packet. Tiếp theo là SMTP, DNS rồi mới đến HTTP.
Thông tin netstat trên server cũng cho biết các connection chủ yếu đang được đổ dồn dập vào port 53 và port 25 từ nhiều nguồn IP khác nhau.
Hình ở trên là kết quả tôi sử dụng tính năng "Follow TCP Stream" của Wireshark đối với các packet của một SMTP connection. Có vẻ như ai đó đang hối hả gửi mail có attachment rất lớn đến server này.
Thông tin về DNS traffic cũng cho thấy, đa số các query đến named chạy trên server này là hỏi MX record của một số domain được đặt tại đây.
Để hoàn chỉnh, tôi tiếp tục lần theo dấu vết của HTTP traffic. Không có gì bất thường cả, có vẻ như nguyên nhân chính nằm ở SMTP và DNS rồi.
Dựa vào DNS, tôi liệt kê ra danh sách các domain đang bị gửi spam, và đề nghị khách hàng tôi tạm thời disable những domain này, không cho phép nhận mail nữa; rồi tôi yêu cầu bên FPT Telecom mở lại switch port, chạy tcpdump để coi traffic có tăng lên hay không.
May mắn quá, đúng như tôi dự đoán, tôi sniff gần cả phút mà chỉ thu được chưa đầy 500Kb. Tôi chờ thêm 20', bên FPT Telecom cho biết traffic đi đến server đã giảm hẳn. Mọi thứ đã trở lại bình thường.
Lục lọi thông tin trên server và đám packet bắt được bằng tcpdump, tôi thấy rằng attachment mà đám spammer đang cố gửi đến server toàn là mấy file PDF. Cách đây vài ngày Internet Storm Center cũng có cảnh báo về PDF Spam. Bản thân tôi mỗi ngày cũng nhận vài cái PDF spam này. Tuy vậy hệ thống của tôi cũng ổn, không gặp vấn đề gì.
Bài học rút ra từ case này: đừng bao giờ sử dụng Windows làm firewall ;).
Comments
Thứ 1 là tại sao trong lần đầu tiên bạn sniff traffic trên server thì lại có rất nhiều ARP broadcast packet ? Theo bài viết bạn tìm được nguyên nhân là do spam mà spam thì đâu liên quan gì đến ARP broadcast packet ?
Thứ 2 là bạn có nói "Dựa vào DNS, tôi liệt kê ra danh sách các domain đang bị gửi spam, và đề nghị khách hàng tôi tạm thời disable những domain này". Vậy cụ thể là bạn đã làm thế nào để xác định được danh sách các domain đang bị gửi spam đó ? Bạn có thể đưa ra để mọi người học hỏi ko ?
Xin cám ơn
Thân
Nếu bạn thử sniff trên một network nào đó, thông thường bạn sẽ nhận được ARP broadcast packet. Trong trường hợp ở hệ thống mạng của FPT Telecom, số lượng ARP broadcast này là nhiều hơn mong đợi, nhưng nó không phải là nguyên nhân của vấn đề bởi nó không xuất phát từ máy chủ mà tôi đang làm việc trên đó.
Tôi lấy được danh sách domain đang bị spam bằng cách nhìn vào DNS traffic, xem domain nào đang bị query MX record nhiều nhất.
-Thái
Mà cho mình góp tý ý kiến là khi bác post những bài có liên quan đến việc phân tích traffic như vậy thì bác nên post luôn file caputre đó luôn để mọi người có thể thấy được rõ hơn (trừ khi traffic có thông tin nhạy cảm thì mình ko nói), mình thấy trang ICS của SANS hay làm như vậy
Thân
Tôi cũng muốn đưa thông tin packet lên đây nhưng đúng như bồ dự đoán, nó chứa thông tin của khách hàng nên tôi không thể tùy tiện công bố được.
Thái nói firewall của FPT bị treo và server đứng đằng sau nó bị cách ly với thế giới bên ngoài... Nhưng tại sao server của khách hàng của Thái lại bị tấn công? Và cũng ở trên thì có nhắc đến "server của khách hàng tôi không hề bị treo hay gặp vấn đề gì cả" trong khi bên dưới lại phải phân tích nó bị tấn công ra sao?!?!
Giải thích giùm với!
--
Chào bạn,
Xin lỗi vì câu chữ của tôi không được rõ ràng cho lắm. Server của khách hàng tôi mặc dầu nhận rất nhiều spam với lượng traffic rất lớn nhưng nó vẫn chạy bình thường. Tuy vậy, do server này đứng ngoài sau một con Checkpoint trên Windows (của FPT Telecom) và do lượng traffic đến lớn quá làm cho con Checkpoint này treo luôn.
Vì lý do này, bên FPT mới tắt server của khách hàng tôi và đề nghị tôi tìm hiểu xem chuyện gì đang diễn ra làm cho server nhận nhiều traffic đến như thế.
Còn lý do tại sao server khách hàng tôi bị tấn công thì tôi không biết. Tôi nghĩ đám spammer cũng chẳng phải cố tình tấn công mà nó chỉ vô tình gửi quá nhiều spam đến một vài domain được host trên server này mà thôi.
Các bạn có thể tham khảo web site này để biết được cách sử dụng Clamav để filter pdf spam
http://www.sanesecurity.co.uk/
Tùng,
Thái có giải pháp nào ko?